In a recent discussions with our ARCFIRE EAB member Sue Rudd, the topic of complexity in 5G comes up time and again, and it’s becoming a common theme in the chatter about 5G. As Sue points out,
“Many Mobile Network Operators (MNOs) and their vendors view 5G as becoming increasingly complex since 5G focuses both on a major evolution of the Radio Access Network(RAN), backhaul and core of mobile networking as well as on essential interoperability if not compatibility with legacy 3G and 4G/LTE networks. Some vendors even hope to exploit and escalate this complexity with hybrid solutions that have led recently to some inefficient examples of ‘kitchen sink’ architectures. Some doomsayers are even forecasting that Next Generation 5G could consume all the benefits of its new technology with its massive inefficiency.”
Just the other month at MWC 2017 Deutsche Telekom’s CTO Bruno Jacobfeuerborn commented that :
“We have to collaborate as an industry to drive the (5G) cost down”
in particular to reduce the cost of the dense 5G small cells and the complexity of HetNets or Multi-Access Fixed/Mobile Services.
Now as Winston Churchill once said “Out of intense complexities intense simplicities emerge“. RINA brings simplicity to networking by exploiting the invariance of the many replicated functions in a network. RINA’s recursively layered architecture of Distributed IPC Facilities (DIFs) are layers of different scope that manage networking resources rather than hand-crafted stacks that have to reduplicated over and over again. The emphasis on invariance means that RINA layers work together, rather than stacks that have to work around each other.
So in talking to Sue, we have provided some pointers on how to tame this 5G complexity problem, with the assistance of RINA. In the RINA DIF structure we do NOT need to provide separate layer diagrams for the control and the data plane, since each DIF already integrates the data transfer and layer management protocols. This feature alone greatly simplifies the network structure. The usage of the same building block (the DIF) configured with different policies also simplifies the network design, and makes it more flexible: more layers can be introduced anywhere by the network designer to help the network scale. Following a strict layering approach also eliminates the need for protocol conversion.
One of the benefits of RINA is that applications are not restricted to use a specific “top-level DIF”, they can use whatever DIF provides the scope and quality that fulfils the application’s requirements.
Arcfire D22 Application to DIF examples: VPN by neighboring customers (left) and access to service-provider content deployed at the network edge (right)
The figure above shows two use cases that make use of this feature. The diagrams show that RINA DIFs can simplify:
- Use Case 1.(left): VPN for Customer Home Networks and Service Provider’s Residential Services and
- Use Case 2.(right): Optimized Content deployed on platforms at the edge of the Network.
In the first use case, left diagram, shows two customers that are physically close to each other (they are both present at the same Access Router), and therefore the operator can take advantage of this approach to provide flows with minimal latency between the CPEs of both customers (in the Figure these flows are supported by the residential customer service DIF). Customers can then use this flow to – for example – setup a VPN DIF for private communication on top of it.
The second use case where the aforementioned RINA DIF feature is exploited is presented by the right side of the figure. The diagram depicts a Multi-Access Edge Computing (MEC) use case, in which the operator has deployed processing power at key locations close to the ‘edge’ of the network – at P/GW, Edge Router or even eNodeB – that we can refer to as a ‘Micro Data Centre (Micro-DC).
MEC Micro-DC server platforms may host applications provided by the operator that benefit from the minimal latency towards customers, or may contain cached content from a CDN. When customers allocate a flow to the destination application name, the DIF Allocator will locate the closest instance of the application within the micro-datacenter and – if required – interact with the operator Network Management System to setup a DIF that supports the requested IPC service (in case no suitable DIF had already been setup, such as the blue DIF in the figure).
We believe this solution is cleaner and simpler than what’s out there today !
Want to read more detail on this, take a look at Section 3 of the ARCFIRE deliverable “D2.2 Converged service provider network design report arcfire_D2.2”