IETF Network Slice for 5G and its characteristics

Network slicing offers network operators a mechanism to allocate dedicated infrastructure, resources and services from a shared operator's network to a customer for specific use-case. As discussed in draft , there are a number of use-cases benefiting from network slicing including: 5G network slicing (See ) Network wholesale services Network sharing among operators NFV connectivity and Data Center Interconnect It is important to note that the concept of network slicing is not only limited to 5G but other use-cases can also benefit from it as shown above. However, the 5G use case is one of the important use cases for network slicing. This memo will discuss the 5G use-case in more details. In specific, 5G network slicing is a mechanism which a mobile network operator can use to allocate dedicated infrastructures, resources and services from a shared mobile and transport network to a 5G customer for specific 5G use-case. A 5G network slice is inherently an E2E concept and is composed of multiple logical independent networks in a common operator's network from a user equipment to various 5G applications. In particular, 5G network slicing receives attention due to factors such as diversity of services and devices in 5G each with its own SLA requirements. Each 5G E2E network slice consists of multiple 5G RAN, 5G Core and transport network domains each with its own controller (See . To enable automation, assurance and optimization of 5G network slices, an E2E network slice orchestrator is needed which interacts with 5G RAN, 5G Core and Transport network controllers. The interfaces between the E2E network slice orchestrator and RAN and Core slice controllers are defined in various 3GPP technical specifications. However, 3GPP has not defined the same interface towards the transport network. Draft addresses the object model of such interface for all network slice use-cases. However, for 5G network slicing, the current model shall be augmented to address the specific characteristics of the 5G network slices. The aim of this document is to provide characteristics of 5G network slices and how it relares to "IETF network slice". It also provides the IETF network slice interface specifications and its information model to be used for automation, monitoring and optimization of IETF network slices for 5G. See .

Please refer to and as well. Also known as Customer. A network slice tenant is a person or group that rents and occupies an instance of the network slice from network provider. A logical end-to-end network provided by a 5G network slice provider that has the functionality and performance to support a specific 5G service. It spans multiple network domains (e.g. radio, transport and core) and in some cases more than one administrative domain. It may well support dynamic modification or it might be long-lasting i.e. only change on commercial timescales. We will use the term "5G IETF network slice" throughout this draft. It simply refers to IETF network slice define in applicable to 5G. Also known in 3GPP as RAN Sub-Slice or RAN Slice-Subnet. The context and personality created on RAN network functions to address the 5G radio portion of a 5G E2E network slice. Also known in 3GPP as Core Sub-Slice or Core Slice-Subnet. The context and personality created on Core network functions to address the 5G Core portion of a 5G E2E network slice. Single-Network Slice Selection Assistance Information, defined by 3GPP which is the identification of a 5G E2E Network Slice The radio portion of a 5G E2E network slice and in a distributed radio deployment (called Cloud-RAN), it incorporates two major modules; Central Unit (CU) and Distribute Unit (DU) Distributed Unit: This logical unit includes a subset of gNB real-time functions. Its operation is controlled by the CU. Central Unit: It is a logical unit that includes the gNB non-realtime functions. User Equipment such as vehicle infotainment unit, cell phone, IoT sensor and etc. Radio Access Network is the part of a mobile system that connects individual devices to other parts of a network through radio connections. It provides connection between user equipment (UE) and mobile core network. Transport domain is a network domain implemented by the deployment of IETF network technologies.

To demonstrate the concept of 5G E2E network slice and the role of various controllers, consider a typical 5G network shown in where a mobile network operator Y has two customers C1 and C2. The boundaries of administrative domain of the operator includes RAN, transport, Core and mobile application domains. Customer C1 and C2 request to have one or more logical independent E2E networks from UEs (e.g. vehicle infotainment, mobile phone, IoT meters etc.) to the 5G application servers, each with its own distinct SLO. Each of these independent networks is called a 5G E2E network slice. Each E2E network slice comprised of three componets RAN slice, IETF network slice, and Core slice, respectively representing RAN, transport and core domain portions of the slice.

<-- RAN --> <-- IETF Network --> <- Core -> <-- IETF Network --> Slice Slice 1 Slice Slice 2 ......... ................... ............ ................. : : : : : : : : : : : : : : : : NS1 ---------------------------------------------------------------- NS2 ================================================================ NS3 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ : : : : : : : : NS4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : : : : : : : : : : : : : : : : :.......: :.................: :..........: :...............: RAN Transport Core Transport App Network Network 1 Network Network 2 Servers Legend: ----- NS1: 5G E2E NS 1 for customer C1, service type Infotainment ===== NS2: 5G E2E NS 2 for customer C1, service type Autonomous Driving +++++ NS3: 5G E2E NS 3 for customer C1, service type HD Map - - - NS4: 5G E2E NS 4 for customer C2, service type CCTV ]]> In mobile network operator Y has created four 5G E2E network slices, NS1, NS2, NS3 and NS4, each with its own RAN, Core and IETF network slices. To create a RAN slice, the RAN network function s such as eNB and gNB should be programmed to have a context for each 5G E2E network slice. This context means that the RAN network functions should allocate certain resources for each 5G E2E network slice they belong to such as air interface, various schedulers, policies and profiles to guarantee the SLO requirement for that specific network slice. By the same token, the Core slices will be created which means that the mobile network operator will create the context for each 5G E2E network slice on Core network functions. For each 5G E2E network slice NS1, NS2, NS3 and NS4, after creation of RAN and Core slices, they should be connected to each other and be connected to mobile application servers to form the 5G E2E network slice. As defined in , the set of connections are referred to "IETF Network Slices" and specifically for 5G they are referred to "5G IETF Network Slices". Referring to , for each 5G E2E network slice, the following 5G IETF network Slices are needed: 5G IETF Network Slice 1: To connect RAN slice to Core slice in Transport Network 1 5G IETF Network Slice 2: To connect Core slice to Mobile Application Servers in Transport Network 2. This might be needed if the mobile application servers are connected to core network functions through a transport network. For example, if the Core slice, which is realized on VNFs, and mobile application servers are in the same data center, the 5G IETF Network Slice 2 is not needed. In this case the transport network 2 does not exist. Note that as we will see later in , and , the number of "5G IETF network slices" might be more than two which depends on some factors such as RAN deployment: After creation of RAN, Core and 5G IETF network slices, they will be associated together to form a working 5G E2E network slice identified by an ID referred as to S-NSSAI. Please refer to for more info on S-NSSAI. To support fully automated enablement and assurance of 5G E2E network slices, multiple controllers are needed to perform the life cycle of 5G E2E network slices in RAN, Core and Transport domains. As shown in each RAN, Core and Transport domain needs its own controller called RAN Slice Controller, Core Slice Controller and IETF Network Slice Controller. In addition, an E2E network slice orchestrator is needed to provide coordination and control of network slices from an E2E perspective. In summary, a 5G E2E network slice will involve several domains, each with its own controller; 5G RAN, 5G Core and transport domains need to be coordinated in order to deliver an E2E mobile service. Note that in this context a service is not an IP/MPLS service but rather customer facing services such as CCTV service, eMBB service, Infotainment service and so on.

provides a typical flow across various controllers, orchestrator, NFVO and RAN/Transport/Core networks to achieve the automatic creation of a 5G E2E network slices such as NS1, NS2, NS3 or NS4 shown in . Below are typical steps from the time a customer sends its request for a 5G E2E network slice creation to the operators network until the network slice is created and ready to be used by the customer. It is important to note that in practice some of these steps can be combined or re-ordered. The customer C1 requests, from operator Y, the creation of a 5G E2E network slice NS1 for Infotainment service type and SLO of 10 [Mbps] The 5G E2E network slice orchestrator receives this request and using its pre-defined network slice blueprints (a.k.a. network slice templates), creates a network slice profile (a.k.a. network slice instance) containing all the network functions in RAN and core which should be part of this E2E network slice. It then goes through decomposition of this profile and triggers various actions towards RAN, Core and transport domains. A request for creation of 5G RAN slice will be sent to RAN Slice Controller. If new instances of virtual RAN network functions are needed, the RAN Slice Controller triggers the creation of new VNFs in RAN (using for example ETSI interface Os-Ma-nfvo) NFVO manages the life cycle of virtual RAN network functions Since both physical and virtual RAN network functions which are part of 5G E2E network functions are known to the RAN slice controller, it triggers the creation of a RAN slice by programming 5G RAN network functions Similary to previous step (3), a request for creation of a Core slice will be sent to the Core Slice Controller. If new instances of virtual Core network functions are needed, the Core Slice controller triggers the creation of new 5G core VNFs (using for example ETSI interface Os-Ma-nfvo) and NFVO manages the life cycle of virtual Core network functions Since both physical and virtual 5G Core network functions as components of 5G E2E network functions are known to the Core slice controller, it triggers the creation of Core slice by programming 5G Core network functions In this step, the creation of various 5G IETF network slices will be triggered. Each 5G IETF network slice contains one or more connections between RAN network functions, Core network functions and 5G mobile applications. For example, connectivity between 5G RAN and 5G Core slices, connectivity between 5G RAN network functions (such as DU to CU) or connectivity between 5G core slice and mobile applications. Note that this step can be triggered by E2E network slice orchestrator, RAN slice controller, Core slice controller, or a combination of them. [Optional] If the realization of a 5G IETF network slice involves creation of new VNFs (e.g. Firewall, security gateway etc.), 5G IETF network slice controller triggers the creation of those VNFs (using for example ETSI interface Os-Ma-nfvo) Various 5G IETF network slices will be realized in transport network. Note that interface (10) is technology-agnostic whereas interface (12) is technology-specific The E2E network slice orchestrator associates RAN slice, Core slice and 5G IETF network slices together to form a single 5G E2E network slice NS1 At the end, when the E2E network slice is created, the E2E network slice orchestrator will allocate a unique network slice id (called S-NSSAI) and eventually, during the UE network attach, UEs will be informed about the existence of this newly created E2E network slice. UEs can request it using the 3GPP 5G signaling procedures. Note that the interfaces 3 and 7 between 5G E2E network slice orchestrator and RAN and Core slice controllers along with their information models are defined in various 3GPP technical specifications. However, 3GPP has not defined the same interface for transport network (i.e. interface 10). The aim of this document is to define specific attributes related to 5G network slices which will be used later to augment .

Referring to , the IETF network slice is define as follows: An IETF network slice is a logical network topology connecting a number of endpoints with a set of shared or dedicated network resources. These resources are used to satisfy specific Service Level Objectives (SLOs). The 5G IETF Network slice specification is technology-agnostic. Using the above-mentioned definition, the 5G IETF network slice is define as follows: 5G IETF network slices are sets of connections among the following network functions and mobile applications: 5G RAN slice and 5G Core slice 5G Core slice and mobile application server Among 5G RAN network functions DU to CU Among 5G RAN network functions RU to DU In , and , the details of various 5G IETF network slices for following RAN deployment will be provided: Distributed RAN Centralized RAN Cloud RAN (C-RAN)

Distributed RAN is the most common deployment of 4G and 5G RAN networks whereas shown in , the RAN network is connected to Core network using the transport network 1. Optionally the mobile applications can be also connected to the Core network using another transport network 2. In this case, a single 5G E2E network slice contains not only 5G RAN and 5G Core slices but two 5G IETF network slices INS_1 and INS_2. INS_1 connects the RAN slice to Core slice and INS_2 connects Core slice to mobile application servers (if needed).

<--- RS --> <-- CS --> <--- INS_1 --> <--- INS_2 ---> .................. : RAN : : : ............. ............. : |----| |-----| : : : |------| : : |-----| : | RU | | BBU | : : Transport : | Core | : Transport : | App | : |----| |-----| : : Network 1 : |------| : Network 2 : |-----| : : :...........: :...........: :................: Legend INS: 5G IETF Network Slice RS: RAN Slice CS: Core Slice RU: Radio Unit BBU: BaseBand Unit App: Mobile Application Servers ]]>

The RAN consists of two functional units: the baseband unit (BBU) and the radio unit (RU). The BBU processes the signal and is connected to the transport network. The RU transmits and receives the carrier signal that is transmitted over the air to the end user equipment (UE). In Centralized RAN as depicted in , the RU and BBU are separated by a network called fronthaul network. In this deployment a single 5G E2E network slice contains not only 5G RAN and 5G Core slices but three 5G IETF network slices INS_1, INS_2 and INS_3 where INS_1 and INS_2 are identical to their counterparts in distributed RAN deployment case (see ) and a new INS_3 connects the Radio Units (RU) to the BBUs.

<-------- RS --------> <-- CS --> <--- INS_3 ---> <--- INS_1 ---> <---- INS_2 ----> ........................... : RAN : : ........ : ............. ............. : |----| : : |-----| : : : |------| : : |-----| : | RU | : FN : | BBU | : : Transport : | Core | : Transport : | App | : |----| : : |-----| : : Network 1 : |------| : Network 2 : |-----| : :......: : :...........: :...........: : : :.........................: Legend INS: 5G IETF Network Slice RS: RAN Slice CS: Core Slice FN: Fronthaul network RU: Radio Unit BBU: BaseBand Unit App: Mobile Application Servers ]]>

In Cloud-RAN deployment, the baseband unit (BBU) is further disaggregated into real-time and non-real-time components. The former is deployed close to antenna to manages the real-time air interface resources while the non-real-time control functions are hosted centrally in the cloud. In 5G, BBU is split into two parts called CU (Central Unit) and DU (Distributed Unit) as shown in where these entities are connected by a new network called Midhaul network. In this deployment a single 5G E2E network slice contains not only 5G RAN and 5G Core slices but four 5G IETF network slices INS_1, INS_2, INS_3 and INS_4 where INS_1, INS_2 and INS_3 are identical to their counterparts in centralized RAN deployment case (see ) and a new 5G IETF network slice INS_4 connects the DUs to CUs.

<-------------- RS ---------------> <- CS -> <--- INS_3 ---> <-- INS_4 --> <-- INS_1 --> <--- INS_2 ---> ...................................... : RAN : : ...... ...... : ........ ...... :|----| : : |----| : : |----| : : : |------| : : |-----| :| RU | : FN : | DU | : MN : | CU | : : TN1 : | Core | :TN2 : | App | :|----| : : |----| : : |----| : : : |------| : : |-----| : :....: :....: : :......: :....: : : :....................................: Legend INS: 5G IETF Network Slice RS: RAN Slice CS: Core Slice FN: Fronthaul network MN: Midhaul network TN: Transport network DU: Distributed Unit CU: Central Unit RU: Radio Unit App: Mobile Application Servers ]]>

As discussed in , an IETF network slice contains one or more connections between various network functions, application and devices. These connections can be grouped into various Connection Groups where each group has its own SLA/SLO. To further explore this concept in 5G E2E network slicing, consider , where the details of 5G IETF network slice INS_1 introduced in is illustrated. The 5G IETF network slice INS_1 is between 5G RAN and Core slices and has multiple connections between 5G RAN network functions BBU1 and BBU2 and 5G Core network functions AMF1 and UPF1. In particular, it contains the following connection groups, each with its own SLO where SLO-C and SLO-U might be different (e.g. they might be control and user plans SLOs): "Connection group C" connects BBU1 and BBU2 to AMF1 with SLO-C "Connection group U" connects BBU1 and BBU2 to UPF1 with SLO-U The combination of two connection groups will form the 5G IETF network slice INS_1. Note that the definition of 5G IETF network slice INS_1 does not specify how these connections should be realized in transport network 1. Although it is optionally possible, it is not necessarily mandatory for the definition of a 5G IETF network slice to state which technology (e.g. IP, MPLS, Optics, PON etc.) or tunnel type (e.g. RSVP-TE, SR-TE etc.) should be employed for realization. As discussed in [, any of these technologies may be used by the IETF Network Slice Controller (NSC) to realize an IETF network slice. In summary, a 5G IETF network slice is a distinct set of technology-agnostic connection groups between various 5G network functions, 5G devices or 5G applications each with its own deterministic SLO which can be realized by any suitable technology, tunnel type and service type.

...................... ..................... ................... : : : : : : : --------- NSE1 : : : : NSE1 --------- : : | | <---------------------------------------> | | : : | BBU1 | <+++++ : : /------------> | AMF1 | : : | | NSE2 + : : / : : | | : : --------- +: : / : : --------- : : :+ : / : : : : : + : / : : : : --------- NSE1 : + / : : : : | | <-----------+--------/ : : NSE1 --------- : : | BBU2 | : +++++++++++++++++++++++++++> | | : : | | <+++++++++++++++++++++++++++++++++++++++> | UPF1 | : : --------- NSE2 : : : : | | : : : : : : --------- : :....................: ....................: :.................: RAN Transport Core Network Network 1 Network 5G IETF Network Slice INS_1: {"Connection group C" + "Connection group U"} Connection Group C {from BBU1.NSE1, BBU2.NSE1 to AMF1.NSE1 with SLO-C} Connection Group U {from BBU1.NSE2, BBU2.NSE2 to UPF1.NSE1 with SLO-U} Legend BBU: BaseBand Unit AMF: Access and Mobility Management Function UPF: User Plane Function NSE: 5G IETF Network Slice Endpoint ---- Connection group C ++++ Connection group U ]]>

As discussed in and , to fulfill (i.e. create, modify, delete) any IETF network slice and perform monitoring on it, an entity called IETF Network Slice Controller (NSC) is required to take abstract requests for 5G IETF network slices and realize them using suitable underlying technologies. An IETF Network Slice Controller is the key building block for control and management of the transport slice. It provides the creation/modification/deletion, monitoring and optimization of transport Slices in a multi-domain, a multi-technology and multi-vendor environment. shows the NSC and its NBI interface for 5G. Draft addresses the base data model of the NSC NBI interface for all network slicing use-cases. However, for 5G network slicing, the current model shall be augmented to include the specific characteristics of the 5G network slices for this interface. The details of NSC NBI interface for 5G provided in .

As discussed in , the main task of the IETF Network Slice Controller is to map abstract IETF network slice requirements from NBI to concrete technologies on SBI and establish the required connectivity, and ensure that required resources are allocated to IETF network slice. There are a number of different technologies that can be used on SBI including physical connections, MPLS, TSN, Flex-E, PON etc. If the undelay technology is IP/MPLS/Optics, any IETF models can be used during the realization of IETF network slice. There are no specific mapping requirements for 5G. The only difference is that in case of 5G, the NBI interface contains additional 5G specific attributes such as customer name, mobile service type, 5G E2E network slice ID (i.e. S-NSSAI) and so on (See ). These 5G specific attributes can be employed by IETF Network Slice Controller during the realization of 5G IETF network slices on how to map NBI to SBI. They can also be used for assurance of 5G IETF network slices. shows the mapping between NBI to SBI for 5G IETF network slices.

Based on the definition of 5G IETF Network slices (see ), the high-level information model of northbound interface of IETF Network Slice Controller (NSC) for 5G IETF network slices should conform with :

The proposed information model should include the following building blocks: 5g-ietf-network-slice-info: All attributes related to 5G IETF Network Slice. It contains information such as 5G IETF network slice name, 5G IETF network slice ID, PLMN and hierarchical tenant ID etc. 5g-network-slice-info: A list of all E2E network slices mapped to this 5G IETF network slice. As discussed in , a request for creation of a 5G IETF network slice is sent from 5G E2E network slice orchestrator to IETF Network Slice Controller (NSC) for a customer and certain service type (e.g. CCTV, Infotainment, URLLC, etc.). It is NSC's decision to either create a new transport slice or use one of the existing ones. As a result, the mapping between 5G E2E network slice and IETF network slice is many to one, i.e. one 5G IETF network slice can be used with multiple 5G E2E network slices. The attributes of each 5G E2E network slices are included here. The 5g-network-slice-info contains the list of E2E network slices which are mapped to a 5G IETF network slice with all relevant attributes such as S-NSSAI, customer name and service type. 5g-connection-group: A 5G IETF network slice contains one or more connection groups each with its own SLA/SLO. Each connection group contains: connection-group-attributes: A list of attributes for each 5g-connection-group such as connection-group-id, connection-group-name and connection-group-status connection-group-member: A list of members. Each member is a connection between two endpoints. A connection group can contain one or more members. For example, the connections BBU1-UPF1 and BBU2-UPF1 are 2 members of "connection group U" in . connection-group-slo-policy: This is a mandatory policy. The connection-group-slo-policy represents in a generic and technology-agnostics fashion the SLO requirement needed to realize members of a connection group. It contains SLOs such as bounded latency, bandwidth, reliability, security etc. Note that all members of a connection group must have the same SLO. connection-group-realization-policy: This is an optional policy. In some scenarios, the 5G E2E network slice orchestrator might be able to influence the IETF Network Slice Controller on how to realize a 5G IETF network slice by providing some technology-specific information. connection-group-monitoring-policy: This is an optional policy. The 5G E2E network slice orchestrator can influence the IETF Network Slice Controller on how to perform monitoring, analytics and optimization on 5G IETF Network Slices. It contains, the type of assurance needed, time interval, frequency of how often to inform the 5G E2E Network Slice Orchestrator etc. 5g-ietf-network-slice-endpoint: It contains the list of all endpoints along with their attributes which belong to a 5G IETF network slice. See 5G-ietf-connection-group-member: It contains the list of all members of connectin groups along with their attributes which belong to a 5G IETF network slice.

This memo includes no request to IANA.

TBD

The authors would like to thank the following people for their contribution to this draft: Ryan Hoffman, Telus