ICNRG R. Ravindran
Internet-Draft Huawei
Intended status: Informational P. Suthar
Expires: May 2, 2018 Cisco
G. Wang
October 29, 2017

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 within the context of network slicing that allows greater flexibility to handle heterogeneous devices and applications. In this draft, we provide a short description of the proposed 5GC, 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 two service scenarios which include mobile edge computing and support for 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 May 2, 2018.

Copyright Notice

Copyright (c) 2017 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 three core 3GPP specifications [TS23.501][TS23.502][TS23.799] 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). Following ICN features shall benefit MEC deployments in 5G:

To summarize the draft, we first discuss 5GC's design principals that allows the support of new network architectures. Then we summarily discuss 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 and ICN session mobility with aid from 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 allow 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. 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 de-coupling allows policy based inter-connection of RAN flows with slices provisioned in the core network.

SMF handles session management functions including IP address assignment functionality, policy and service capabilities. Furthermore, it manages the data plane state in the user plane through PDU session establishment, modification and termination, and management of RAN (through the AMF) and UPF states related to a particular service or slice.

In the data plane, UE's PDUs are sent 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. The UPF in this case also offers flexibility as a flow classifier and a branching point interconnecting PDUs from diverse services (within UEs) to their respective DNs. Though [TS23.501] follows LTE on using GTP tunnel from NR to the UPF to carry data PDU 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-AP     +--------+  ICN-DN  |
       |                          |              +-----+-----+     |          |   + UPF      |   N6   |          |
+------+--+             +---------+--+           |           |     |          +---+----------+        +----------+
|         |             |RAN         |           |   UL-CL/  +-----+
| ICN-UE  +-------------+            +-----------+ Branching |
|         |             |  +-------+ |    N3     |   Point   +-----+           +------------+
+---------+             |  | UL-CL | |           +-----------+     |           |  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. 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, new/modified functional components are identified to interconnect 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 require five additional control plane extensions, which are discussed as follows.

5.1.1. Normative Interface Extensions

5.2. User Plane Extensions

As explained in detail in [TS23.501], UPFs are service agnostic functions, hence extensions are not required to operate an ICN-DN. The inter-connection of UE to ICN-DN comprises of two segments, one from RAN to UL-CL and the other from UL-CL to ICN-AP. These segments use IP tunneling constructs, where the service semantic check at UL-CL and ICN-AP 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

6. ICN Deployement Use Case Scenarios

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

6.1. Mobile Edge Computing

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.2. 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 ICN-APs as gateways, referred to as ICN-AP-1 and ICN-AP-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 [mas].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-AP 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-AP 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-APs 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.

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

[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-04, October 2017.
[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-03, September 2017.
[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.
[mas] 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.
[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.
[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/
Guoqiang Wang Huawei Research Center 2330 Central Expressway Santa Clara, CA 95050 USA EMail: gq.wang@huawei.com