ICNRG R. Ravindran
Internet-Draft Huawei
Intended status: Informational P. Suthar
Expires: January 3, 2019 Cisco
D. Trossen
InterDigital Inc.
G. White
July 2, 2018

Enabling ICN in 3GPP's 5G NextGen Core Architecture


The proposed 3GPP's 5G core nextgen architecture (5GC) offers flexibility to introduce new user and control plane function, considering the support for network slicing functions, that allows greater flexibility to handle heterogeneous devices and applications. In this draft, we provide a short description of the proposed 5GC architecture, followed by extensions to 5GC's control and user plane to support packet data unit (PDU) sessions from information-centric networks. The value of enabling ICN in 5GC is discussed using multiple service scenarios in the context of mobile edge computing such as smart mobility and VR use case, and to enable network services such as seamless mobility for ICN sessions.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 3, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

The objective of this draft is to propose an architecture to enable information-centric networking (ICN) in the proposed 5G Next-generation Core network architecture (5GC) by leveraging its flexibility to allow new user and associated control plane functions. The reference architectural discussions in the 5G core network 3GPP specifications [TS23.501][TS23.502] form the basis of our discussions. This draft also complements the discussions related to various ICN deployment opportunities explored in [I-D.rahman-icnrg-deployment-guidelines], where 5G technology is considered as one of the promising alternatives.

Though ICN is a general networking technology, it would benefit 5G particularly from the perspective of mobile edge computing (MEC). The following ICN features shall benefit MEC deployments in 5G:

In this document, we first discuss 5GC's design principals that allows the support of new network architectures. Then we summarize the 5GC proposal, followed by control and user plane extensions required to support ICN PDU sessions. We then discuss specific network services enabled using ICN data networks, specifically MEC use case scenarios and ICN session mobility with aid from the 5GC control plane.

2. Terminology

Following are terminologies relevant to this draft:

3. 5G NextGen Core Design Principles

The 5GC architecture is based on the following design principles that allows it to support new service networks like ICN efficiently compared to LTE networks:.

4. 5G NextGen Core Architecture

In this section, for brevity purposes, we restrict the discussions to the control and user plane functions relevant to an ICN deployment discussion in Section 5. More exhaustive discussions on the various architecture functions, such as registration, connection and subscription management, can be found in[TS23.501][TS23.502].

                                   +---------+             +--------+
                        +--------+ | PCF/UDM |    +------+ |  AF-2  |
                        | NSSF   | |         |    | AF-1 | +-----+--+
                        +---+----+ +-----+---+    +--+---+       |
                            |            |           |        +--+--------+
                        +---+------------+-+   +-----+------+ |           |
                        |                  |N11|            | |   SMF-2   |
                        |     AMF          +---+   SMF-1    | |           |
                        |                  |   |            | +---------+-+
                        +--------+-+-------+   +----+-------+           |
                                 | |                |-----------------------------------+
              +------------------+ |                |                   |N4             |N4
           N1 |                    |N2              |N4                 |      +--------+-----------+
              |                    |                |                +---------+        UPF         | N6 +------+
+-------------+-+       +----------+------+     +---+-----------+    |  |      |(PDU Session Anchor)+----+  DN  |
|               |       |                 |     |               | N9 |  |      |                    |    |      |
|     UE        |       |      RAN        | N3  |    UL-CL      +----+  |      +--------------------+    +------+
|               +-------+                 +-----+               |       |
|               |       |                 |     |               +----+  +-----------------+
+---------------+       +-----------------+     +---------------+ N9 |                    |
                                                                     |         +----------+---------+
                                                                     +---------+                    |    +--------+
                                                                               |        UPF         | N6 |  DN    |
                                                                               |(PDU Session Anchor)+----+        |
                                                                               |                    |    +--------+

Figure 1: 5G Next Generation Core Architecture

In Figure 1, we show one variant of a 5GC architecture from [TS23.501], for which the functions of UPF's branching point and PDU session anchoring are used to support inter-connection between a UE and the related service or packet data networks (or PDNs) managed by the signaling interactions with control plane functions. In 5GC, control plane functions can be categorized as follows:

AMF serves multiple purposes: (i) device authentication and authorization; (ii) security and integrity protection to non-access stratum (NAS) signaling; (iii) tracking UE registration in the operator's network and mobility management functions as the UE moves among different RANs, each of which might be using different radio access technologies (RAT).

NSSF handles the selection of a particular slice for the PDU session request from the user entity (UE) using the Network Slice Selection Assistance Information (NSSAI) parameters provided by the UE and the configured user subscription policies in PCF and UDM functions. Compared to LTE's evolved packet core (EPC), where PDU session states in RAN and core are synchronized with respect to management, 5GC decouples this using NSSF by allowing PDU sessions to be defined prior to a PDU session request by a UE (for other differences see [lteversus5g] ). This decoupling allows policy based inter-connection of RAN flows with slices provisioned in the core network. This functionality is useful particularly towards new use cases related to M2M and IOT devices requiring pre-provisioned network resources to ensure appropriate SLAs.

SMF is used to handle IP anchor point selection and addressing functionality, management of the user plane state in the UPFs (such as in uplink classifier (UL-CL), IP anchor point and branching point functions) during PDU session establishment, modification and termination, and interaction with RAN to allow PDU session forwarding in uplink/downlink (UL/DL) to the respective DNs. SMF decisions are also influenced by AF to serve application requirements, for e.g., actions related to introducing edge computing functions.

In the data plane, UE's PDUs are tunneled to the RAN using the 5G RAN protocol[TS-5GNR]. From the RAN, the PDU's five tuple header information (IP source/destination, port, protocol etc.) is used to map the flow to an appropriate tunnel from RAN to UPF. Though the current 5GC proposal[TS23.501] follows LTE on using GPRS tunneling protocol (GTP) tunnel from NR to the UPF to carry data PDUs and another one for the control messages to serve the control plane functions; there are ongoing discussions to arrive upon efficient alternatives to GTP.

5. 5GC Architecture with ICN Support

In this section, we focus on control and user plane enhancements required to enable ICN within 5GC, and identify the interfaces that require extensions to support ICN PDU sessions. Explicit support for ICN PDU sessions within access and 5GC networks will enable applications to leverage the core ICN features while offering it as a service to 5G users.

                                                               |     5G     |
                                                               | Services   |
                                                               |   (NEF)    |         +----------------+
                                                               +-------+----+         |      ICN       |
                                                                       |   +----------+    Service     |
                                                                       |   |          |  Orchestrator  |
                                                                       |   |          +-----------+----++
               +-------+  +---------+           Npcf++/Nudm++         ++------+                   |
               | NSSF  |  | PCF/UDM +---------------------------------+ ICN-AF|                   |
               +----+--+  |         |                                 |       |               +---+--------------+
                    |     +--+------+                                 +---+---+               |       ICN        |
                    |        |                                            |            +------+  Service/Network |
                  +-+--------+--+           +---------------+      +------+-------+    |      |    Controller    |
                  |             |   N11++   |               |Naf++ |              +----+      +------------+-----+
                  |   AMF++     +-----------+   SMF++       +------+    ICN-SMF   |                        |
                  |             |           |               |      |              |                        |
                  +------+-+----+           +----+-----+----+      +------------+-+                        |
                         | |                           |                        | NIcn                     |
       +-----------------+ |                           |                        +----------+               |
       |                   |                           |                                   |               |
       |                   +------+                 N4 |                                   |               |
  N1++ |                          |                    |                                   |               |
       |                          | N2                 |                      +------------+-+        +----+-----+
       |                          |                    |           +----------+              |        |          |
       |                          |                    |           |   N9     |   ICN-GW     +--------+  ICN-DN  |
       |                          |              +-----+-----+     |          |   + UPF      |   N6   |          |
+------+--+             +---------+--+           |           |     |          +---+----------+        +----------+
|         |             |RAN +-----+ |           |   UL-CL/  +-----+
| ICN-UE  +-------------+    |UPF  | |           | Branching |
|         |             |    +-----+ +-----------+   Point   |
|         |             |  +-------+ |    N3     |           +-----+           +------------+
+---------+             |  | ICN-GW| |           +-----------+     |           |  Local     |
                        |  +-------+ |                             |    N9     |  ICN-DN    |
                        +------------+                             +-----------+            |

Figure 2: 5G Next Generation Core Architecture with ICN support

For an ICN-enabled 5GC network, the assumption is that the UE may have applications that can run over ICN or IP, for instance, UE's operating system offering applications to operate over ICN [Jacobson] or IP-based networking sockets. There may also be cases where UE is exclusively based on ICN. In either case, we identify an ICN enabled UE as ICN-UE. Different options exist to implement ICN in UE as described in [I-D.suthar-icnrg-icn-lte-4g] which is also applicable for 5G UE to enable formal ICN session handling, such as, using a transport convergence layer above 5G-NR, through IP address assignment from 5GC or using 5GC provision of using unstructured PDU session mode during the PDU session establishment process, which is discussed in Section 5.2.2. Such convergence layer would implement necessary IP over ICN mappings, such as those described in [TROSSEN], for IP-based applications that are assigned to be transported over an ICN network. 5G UE can also be non-mobile devices or an IOT device using radio specification which can operate based on [TS-5GNR].

5GC will take advantage of network slicing function to instantiate heterogeneous slices, the same framework can be extended to create ICN slices as well [Ravindran]. This discussion also borrows ideas from[TS23.799], which offers a wide range of architectural discussions and proposals on enabling slices and managing multiple PDU sessions with local networks (with MEC) and its associated architectural support (in the service, control and data planes) and procedures within the context of 5GC.

Figure 2 shows the proposed ICN-enabled 5GC architecture. In the figure, the new and modified functional components are identified that interconnects an ICN-DN with 5GC. The interfaces and functions that require extensions to enable ICN as a service in 5GC can be identified in the figure with a '++' symbol. We next summarize the control, user plane and normative interface extensions that help with the formal ICN support.

5.1. Control Plane Extensions

To support interconnection between ICN UEs and the appropriate ICN DN instances, we consider the following additional control plane extensions to orchestrate ICN services in coordination with 5GC's control components.

5.1.1. Normative Interface Extensions

5.2. User Plane Extensions

The interconnection of a UE to an ICN-DN comprises of two segments, one from RAN to UL-CL and the other from UL-CL to ICN-GW. These segments use IP tunneling constructs, where the service semantic check at UL-CL is performed using IP's five tuples to determine both UL and DL tunnel mappings. We summarize the relevant UPFs and the interfaces for handling ICN PDU sessions as follows.

5.2.1. Normative Interface Extensions

5.2.2. ICN over non-IP PDU

5GC accommodates non-IP PDU support which is defined for Ethernet or any unstructured data[TS23.501]. This feature allows native support of ICN over 5G RAN, with the potential enablement of ICN-GW in the BS itself as shown in Figure 2. Formalizing this feature to recognize ICN PDUs has many considerations:

6. 5G/ICN Deployment Scenarios

Here we discuss two relevant network services enabled using ICN in 5G.

6.1. Smart Mobility

We consider here a radio edge service requiring low latency, high capacity and strict quality of service. For the discussion in this draft, we analyze connected vehicle scenario, where the car's navigation system (CNS) uses data from the edge traffic monitoring (TM-E) service instance to offer rich and critical insights on the road conditions (such as real-time congestion assisted with media feeds). This is aided using traffic sensing (TS) information collected through vehicle-to-vehicle (V2V) communication over dedicated short-range communications (DSRC) radio by the TS-E, or using road-side sensor units (RSU) from which this information can be obtained. The TS-E instances then push this information to a central traffic sensing instance (TS-C). This information is used by the central traffic monitoring service (TM-C) to generate useable navigation information, which can then be periodically pushed to or pulled by the edge traffic monitoring service (TM-E) to respond to requests from vehicle's CNS. For this scenario, our objective is to compare advantages of offering this service over an IP based MEC versus one based on ICN. We can generalize the following discussion to other MEC applications as well.

6.1.1. IP-MEC Scenario

Considering the above scenario, when a vehicle's networking system comes online, it first undergoes an attachment process with the 5G-RAN, which includes authentication, IP address assignment and DNS discovery. The attachment process is followed by PDU session establishment, which is managed by SMF signaling to UL-CL and the UPF instance. When the CNS application initializes, it assumes this IP address as its own ID and tries to discover the closest service instance. Local DNS then resolves the service name to a local MEC service instance. Accordingly, CNS learns the IP service point address and uses that to coordinate between traffic sensing and monitoring applications.

CNS is a mission critical application requiring instant actions which is accurate and reliable all the time. Delay of microsecond or non-response could result in fatalities. Following are main challenges with the IP-MEC design:

6.1.2. ICN-MEC Scenario

If the CNS application is developed over ICN either natively or as an overlay over IP, ICN shall allows the same named data logic to operate over heterogeneous interfaces (such as DSRC radio, and IP transport-over-5G, unlicensed radio over WiFi etc. link), thereby avoiding the need for application layer adaptations.

We can list the advantages of using ICN-based MEC as follows:

6.1.3. IP-over-ICN MEC Scenario

The above application can also be realized in the context of an IP-over-ICN deployment scenario discussed in Section 5.2. In this case, we assume the operation of the IP-based MEC application over the ICN bearer. The ICN-based methods being used for service registration ensure that routing of CNS service requests reach the 'nearest' service instance (near in topological distance), while utilizing path updates at the CNS endpoint to handle mobility of the vehicle. If assuming HTTP-level (or similar CoAP-level) access to the sensing data, the same TM-E instance can return a single Layer 2 level multicast (assuming a SDN-based L2 sub-system) response to all CNS of passing car that have been requesting the sensing data within a configurable time interval. The ICN-based registration of the TM-E service also allows for secure content delegation being implemented where secured content is being diffused to in-network caching points while the original HTTP/CoAP-level sensing request is directed to the secure content server rather than the origin server, avoiding inefficient triangular routing when doing so.

6.2. Multi-viewer Virtual Reality

VR services are nowadays implemented as HTTP-based file chunk retrieval systems where the file chunk is determined by the viewing angle of the VR headset. Hence, within the same content scenario, consumers exhibiting the same viewing angle relative to the content will exhibit the same access patterns towards the content storage. Nonetheless, IP-based delivery of the VR service will result in separate HTTP unicast sessions being established to each VR headset. When running instead the headset in IP-over-ICN mode (with a dual-stack realization or a single stack UE with the convergence layer as outlined in [I-D.suthar-icnrg-icn-lte-4g], we can now utilize the multicast capabilities of the underlying ICN system to deliver any access to the same file chunk as a multicast message from the content storage to the individual headset UEs using L2 multicast. When viewing angles diverge among headsets, the degree of overlap will do the same and the multicast efficiency will change accordingly albeit in an ad-hoc, instantaneous manner, i.e., not requiring any reconfiguration of underlying transport resources (such as multicast groups). Such multi-viewer VR capability can be utilized in a number of use cases, such as for events at specific site, e.g., stadiums, in an MEC-like deployment. Other use cases could foresee utilizing such capability for remote education scenarios from a single VR server, e.g., provisioned by a school, towards a class of students located at 5G-connected homes or premises This capability of improving on existing HTTP-based VR services via such convergence layer based IP-over-ICN mechanisms has been successfully demonstrated at trade-shows in 2017.

6.3. ICN Session Mobility

Mobility scenario assumes a general ICN-UE handover from S-RAN to T-RAN, where each of them is served by different UPFs, i.e., UL-CL-1 and UL-CL-2. We also assume that UL-CL-1 and UL-CL-2 use different gateways, referred to as ICN-GW-1 and ICN-GW-2. From an ICN perspective, we discuss here the producer mobility case, which can be handled in multiple ways, one of which is proposed in [ICNMOB].However, the details of the ICN mobility solution are orthogonal to this discussion. Here, ICN-UE refers to an application producer (e.g., video conferencing application, from which ICN consumers request real-time content. Here we also assume the absence of any direct physical interface, Xn, between the two RANs. The current scenario follows the handover procedures discussed in [TS23.502], with focus here on integrating it with an ICN-GW and ICN-DN, where mobility state of the ICN sessions are handled.

The overall signaling overhead to handle seamless mobility also depends on the deployment models discussed in Section 4. Here we consider the case when RAN, UL-CL and ICN-GW are physically disjoint; however in the case where RAN and UL-CL are co-located then a part of the signaling to manage the tunnel state between the RAN and UL-CL is localized, which then improves the overall signaling efficiency. This can be further extended to the case when ICN-GWs are co-located with the RAN and UL-CL, leading to further simplification of the mobility signaling.

Next, we discuss the high-level steps involved during handover.

Note that, inter-RAN handover mapping to the same UL-CL represents a special case of the above scenario.

6.4. Cloud-native (mobile) Operator Environments

At the recent NGMN (next generation mobile networks) Forum in Paris in April 2018, a so-called 'cloud-native environment' for mobile operators was presented. This view on the realization of both the control and eventually also the data plane in 5G networks foresees the use of regionalized data centres over a software-defined wide area network. Here, traditional network control functions are re-interpreted as 'services' over an HTTP application layer protocol, i.e., moving the network function view (based on peer relations) to a fully fledged service-based architecture. The NGMN presentation included a demonstration of a first fully SDN-based realization of such view, utilizing IP-over-ICN [TROSSEN] routing capabilities for HTTP-based control plane service invocations. The benefits of utilizing such capabilities lie in the flexible and fast redirection capability to the nearest service instance, for which the demo used container-based virtualization techniques. Although the demo itself was not (yet) integrated into the 5G sub-system according to Figure 2, it showed the capabilities of utilizing ICN as an underlay. Although the focus of the demonstration lied on control plane service, the same solution has successfully demonstrated data plane services, such as those discussed in Section 6.1.3 and Section 6.2.

7. Conclusion

In this draft, we explore the feasibility of realizing future networking architectures like ICN within the proposed 3GPP's 5GC architecture. Towards this, we summarized the design principles that offer 5GC the flexibility to enable new network architectures. We then discuss 5GC architecture along with the user/control plane extensions required to handle ICN PDU sessions formally. We then apply the proposed architecture to two relevant services that ICN networks can enable: first, mobile edge computing over ICN versus the traditional IP approach considering a connected car scenario, and argue based on architectural benefits; second, handling ICN PDU session mobility in ICN-DN rather than using IP anchor points, with minimal support from 5GC.

8. IANA Considerations

This document requests no IANA actions.

9. Security Considerations

This draft proposes extensions to support ICN in 5G's next generation core architecture. ICN being name based networking opens up new security and privacy considerations which have to be studied in the context of 5GC. This is in addition to other security considerations of 5GC for IP or non-IP based services considered in [TS33.899].

10. Acknowledgments


11. Informative References

[Guilio] Grassi, G., Pesavento, D., Pau, G., Vayyuru, R., Wakikawa, Ryuji., Wakikawa, Ryuji. and Lixia. Zhang, "Vehicular Inter-Networking via Named Data", ACM Hot Mobile (Poster), 2013.
[I-D.rahman-icnrg-deployment-guidelines] Rahman, A., Trossen, D., Kutscher, D. and R. Ravindran, "Deployment Considerations for Information-Centric Networking (ICN)", Internet-Draft draft-rahman-icnrg-deployment-guidelines-05, January 2018.
[I-D.suthar-icnrg-icn-lte-4g] suthar, P., Stolic, M., Jangam, A. and D. Trossen, "Native Deployment of ICN in LTE, 4G Mobile Networks", Internet-Draft draft-suthar-icnrg-icn-lte-4g-04, November 2017.
[I-D.white-icnrg-ipoc] White, G., Shannigrahi, S. and C. Fan, "Internet Protocol Tunneling over Content Centric Mobile Networks", Internet-Draft draft-white-icnrg-ipoc-01, June 2018.
[ICNMOB] Azgin, A., Ravidran, R., Chakraborti, A. and G. Wang, "Seamless Producer Mobility as a Service in Information Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 2016.
[IEEE_Communications] Trossen, D. and G. Parisis, "Designing and Realizing an Information-Centric Internet", Information-Centric Networking, IEEE Communications Magazine Special Issue, 2012.
[Jacobson] Jacobson, V. and et al., "Networking Named Content", Proceedings of ACM Context, , 2009.
[lteversus5g] Kim, J., Kim, D. and S. Choi, "3GPP SA2 architecture and functions for 5G mobile communication system.", ICT Express 2017, 2017.
[NFN] Sifalakis, M., Kohler, B., Christopher, C. and C. Tschudin, "An information centric network for computing the distribution of computations", ACM, ICN Sigcomm, 2014.
[Ravindran] Ravindran, R., Chakraborti, A., Amin, S., Azgin, A. and G. Wang, "5G-ICN : Delivering ICN Services over 5G using Network Slicing", IEEE Communication Magazine, May, 2016.
[RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T. and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016.
[TROSSEN] Trossen, D., Reed, M., Riihijarvi, J., Georgiades, M. and G. Xylomenos, "IP Over ICN – The Better IP ?", EuCNC, European Conference on Networks and Communications , July, 2015.
[TS-5GNR] 3GPP-38-xxx, "Technical Specification series on 5G-NR (Rel.15)", 3GPP , 2017.
[TS23.501] 3gpp-23.501, "Technical Specification Group Services and System Aspects; System Architecture for the 5G System (Rel.15)", 3GPP , 2017.
[TS23.502] 3gpp-23.502, "Technical Specification Group Services and System Aspects; Procedures for the 5G System(Rel. 15)", 3GPP , 2017.
[TS23.799] 3gpp-23.799, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Architecture for Next Generation System (Rel. 14)", 3GPP , 2017.
[TS33.899] 3gpp-33.899, "Study on the security aspects of the next generation system", 3GPP , 2017.
[VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X. and G. Wang, "Towards software defined ICN based edge-cloud services", CloudNetworking(CloudNet), IEEE Internation Conference on, IEEE Internation Conference on CloudNetworking(CloudNet), 2013.

Authors' Addresses

Ravi Ravindran Huawei Research Center 2330 Central Expressway Santa Clara, 95050 USA EMail: ravi.ravindran@huawei.com URI: http://www.Huawei.com/
Prakash Suthar Cisco Systems 9501 Technology Blvd. Rosemont, 50618 USA EMail: psuthar@cisco.com URI: http://www.cisco.com/
Dirk Trossen InterDigital Inc. 64 Great Eastern Street, 1st Floor London, EC2A 3QR United Kingdom EMail: Dirk.Trossen@InterDigital.com URI: http://www.InterDigital.com/
Greg White InterDigital Inc. 858 Coal Creek Circle Louisville, CO 80027 USA EMail: g.white@cablelabs.com