In a previous post, we discussed a view on 5G Architecture from the European 5G PPP Architecture Working Group, and now its worth considering recommendations for End-to-end 5G systems from the US perspective.
The 5G Americas (formerly known as 4G Americas) whitepaper “5G Technology Evolution Recommendations” discusses a selected set of scenarios and technologies for 5G. The final recommendations group its scenario views as: devices, radio, core, applications, and regulatory.
For RINA as a network architecture the following scenarios are of special interest (the views appear in brackets):
- Security (radio, core, application): is a fundamental property especially for mission critical 5G verticals, namely smart grids (and other infrastructure), telemedicine, industrial control, public safety and automotive. The main aspects of security identified are integrity and confidentiality. Integrity ensures that information is not tampered with in transmission, including authorisation and authentication of sender and receiver. Confidentiality ensures that information is not accessible for unauthorised elements. It is important that both security properties are maintained end-to-end (horizontal) as well as through the whole network stack (vertical). A possible breach in any place will compromise a complete vertical service. RINA with built-in (architectural) security and added secure key management (as developed in PRISTINE) already addresses this scenario without the introduction of new mechanisms or protocols. Any other case that requires new mechanisms in the network will increase complexity and introduce new potential attack vectors.
- Context-aware networking (devices, applications): this is a fundamental scenario to ensure that a 5G network provides the right resources (at the right time and space) to “meet the unique needs of each application and device”. The study looks at mobility support first, but that is a standard RINA feature. More important are other aspects such as energy efficiency (e.g. extending battery life by limiting signalling to a bare minimum), low latency (e.g. for a telemedicine service of remote operation), high reliability (for instance for communication in public safety services) or general operational cost related scenarios. Most information for those scenarios cannot be found in the network (since they are rather device or service specific), but they can be considered by the network to optimise its configuration. One approach is to supply all context information to the network. Another approach is to supply context information to the multi-layer coordination (the DMS in RINA terms). Since context-aware networking must be provided on all layers, the multilayer coordination seems to be the right place. It is in the position to configure all network layers (DIFs) according to business goals with given information, now extended by context information about devices and services, including non-functional yet important information for network configurations.
- Cloud RAN (radio, core): is identified in the report as an important scenario but not further detailed. It is however known as Mobile Edge Computing (MEC) or Open Mobile Edge Computing (OMEC). It aims to provide for cloud computing capabilities and an Information Technology (IT) environment at the edge of a mobile network, i.e. close to the radio base stations. MEC might move the central office (CO) even closer to the edge. Combined with radio split (various scenarios on splitting the radio interface and moving split functionality to a local cloud), MEC can be a powerful tool for localised services in the mobile network, such as Self Organising Networks (SON), autonomic control (of a set of radio nodes, including local analytics) and user-centric radio control (if a user can be identified at the edge). RINA is ideally positioned to realise OMEC. A carefully designed DIF structure can cover the communication between radio nodes and the MEC, while providing all desired network features (here typically focusing on aspects such as latency). If the mobile network changes (nodes are added or removed) or requires a more drastic reconfiguration, all existing services of higher-level DIFs will be supported without change on those higher-level DIFs.
- Flexible networks (radio, core): the report looks at the flexibility of networks above OpenFlow and other basic SDN technologies. Instead, it states that “the emphasis is on network programmability through open northbound interfaces, a configurable policy framework, resource discovery and optimisation and an SDN control framework that is separate from the forwarding plane”. We have already discussed the advantages of RINA over SDN, including this type of advanced SDN. However, the flexibility of networks (based on programmability) will be a very important scenario for 5G networks. Once some different verticals are deployed, the need for extended flexibility in and of the network will increase. It will be very important to demonstrate that RINA is a solution for this coming requirement.
- NFV (core): While the report puts NFV into the core network in its recommendations, it also states that NFV can facilitate an evolution of SON functions: “In a virtualised network, VNFs may be running in different Network Function Virtualisation Infrastructure (NFVI) domains (e.g., for different levels of Radio Access Network (RAN) centralisation). For example, Core Network (CN) VNF may be running in the central data center of the network operator while RAN VNFs may be running in regional or local data centers to provide for lower latency.” This is an important aspect of virtual functions: since they can be deployed were needed, associated functions (such as SON functions) will need to be deployed in an equally flexible way. Combining a virtual function and a SON function in RINA terms means to add them to the same DIF, then use the DIF for all required functionality (allocation, re-allocation, move of location of functions, adding functions, removing functions, plus management for instance for function stability).
- Ubiquitous Storage and Computing (core): This scenario is closely related to flexible networks (see above) and also MEC. Since 5G services require compute and storage capabilities, and the services can be deployed almost anywhere in the network, compute and storage capabilities should be able to follow the services (or be where they needed, shortly before they are needed). While we cannot deploy hardware on-demand, we can provide for flexible mechanisms to provide access to available compute and storage capabilities with guaranteed quality of service on-demand and in real-time. In today’s world this could be realised with the on-demand creation of virtual private networks. However, this is a non-trivial operation with impacts on all other services already operating in the network. RINA DIFs can be a viable alternative and our current understanding of on-demand creation and extension of DIFs as well as reconfiguration support that.