CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U. S. provisional patent application no. 62/337,076, filed May 16, 2016 and U.S. provisional patent application no. 62/355,202, filed June 27, 2016, which are incorporated herein by reference in their entirety.

BACKGROUND

[0002] During the past decade of the mobile phone evolution, the mobile phone has advanced rapidly and drastically. The mobile phone has advanced from a voice centric monochrome device with a minuscule screen and little processing power to one with high resolution, palm sized screen, and data processing power rivaling a laptop. This transformation, coupled with an expanding cache of bandwidth hungry applications, has triggered demands for higher data rates. Mobile data traffic has continued to grow to today' s 4G networks supporting data rates up to 1 Gbit/s on the downlink. Next generation networks - 5G networks - are currently being studied for deployment scenarios which go beyond just higher and higher rates to include use cases that address the emerging Industrial Internet of Things and ultra reliable low latency services.

[0003] A diverse range of services and/or associated network service requirements (e.g., Quality of Service (QoS), speed, latency, and/or security) for each application may be provided in 5G networks. Network Slicing may enable sub-networks (e.g., network slices) to support the diverse services and requirements. A network slice may be isolated from other (e.g., all other) network slices. Virtualization and/or Network Function Virtualization (NFV) may enable a network slice (NS) to offer granular control of performance, for example, based on the application and/or services being delivered. SUMMARY

[0004] Systems, methods, and instrumentalities are disclosed for slice selection and assignment. For example, a WTRU may transmit to a serving network (SN) a request for an attachment to a slice with a service description document (SDD).

[0005] The SN may perform an authorization check, based on the request. The SN may determine whether the WTRU has provided a requested SDD (SDDR). The SN may obtain an SDD identity (SDDId) of an authorized SDD based on subscription associated with that subscriber (e.g. user or users or WTRU). An associated SDD may be received, based on the SDDId. The SDD may be assigned to the WTRU.

[0006] A network device may receive, from a WTRU, a message. The message may be a service request message, or an attach request message. The service request message may be piggybacked with the attach request message. The message may include a first requested SDD. The first requested SDD may be a network slice selection assistance information (NSSAI) message. A NSSAI message may include a collection of various single NSSAI (S-NSSAI) messages. A S-NSSAI message may include a slice/service type (SST) and/or a slice

differentiator (SD). The network device may receive the first requested SDD via the RRC and/or NAS layers. The first requested SDD may be associated with an application. The first requested SDD may indicate one or more service flow requirements. A service flow requirement may indicate a Quality of Service (QoS) requirement characteristic and/or a security characteristic. The QoS requirement characteristic and/or the security characteristic may be associated with the application.

[0007] The network device may determine an offered SDD. The network device may send the offered SDD to the WTRU. The offered SDD may satisfy the service flow requirement. The offered SDD may be associated with a network slice. The network device may determine that the offered SDD is a match for the first requested SDD. The network device may assign a network slice to the WTRU, for example, based on the one or more service flow requirements. For example, the network device may assign the network slice to the WTRU based on the offered SDD being a match for the first requested SDD. The network device may determine that the offered SDD is a match for the first requested SDD when the offered SDD is tailored for the application. The network device may send, to the WTRU, a response message that indicates the assigned network slice.

[0008] The network device may determine that the offered SDD is not a match for the first requested SDD, for example, when the offered SDD is not tailored for the application. The network device may send, to the WTRU, a catalog of services and/or slices available in the SN. The catalog may include services and/or slices provided by the SN itself and/or any 3 ^rd Party Service and/or Slice provider, for example, that are approved by the SN. The network device may receive, from the WTRU, a second requested SDD. The second requested SDD may indicate a second service flow requirement. The second service flow requirement may be part of the offered SDD. The network slice may be assigned based on the second requested SDD. The QoS requirement characteristic may be indicated by a QoS class identifier (QCI) value. The QoS requirement characteristic may indicate one or more of a minimum GBR, a data rate, a latency, a delay, a packet loss error rate, a re-transmission threshold, a RLC mode, a call setup time, a connection density, a traffic density, or a handoff success rate. The first and/or second requested SDD may indicate respective QoS requirement characteristics for one or more of a control plane, a user plane, and/or a management plane. The first and/or second requested SDD may indicate respective QoS requirement characteristics for uplink and/or downlink communications. The first and/or second requested SDD may indicate security characteristics for one or more of a security level, a data integrity requirement, a data confidentiality requirement, a privacy requirement, an algorithm complexity requirement, a key length requirement, or an authorization type.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0010] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A.

[0011] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1 A.

[0012] FIG ID is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1 A. [0013] FIG. IE is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0014] FIG. 2 depicts example Business Models in 5G Networks.

[0015] FIG. 3 depicts example Three Dimensions of Innovation in 5G Networks.

[0016] FIG. 4 depicts an example Network Slicing Conceptual Outline.

[0017] FIG. 5 depicts example Network Function Virtualization (NFV) Layers.

[0018] FIG. 6 depicts an example NFV Management and Orchestration (NFV-MANO)

Architecture.

[0019] FIG. 7 depicts an example overview of a Software Defined Networking (SDN) Layering Concept.

[0020] FIG. 8 depicts an example Schematic Diagram of Slice Composition in different 5G Use Cases.

[0021] FIG. 9 depicts an example 3GPP Architecture for Service Capability Exposure.

[0022] FIG. 10 depicts example Network Service Header Contents.

[0023] FIG. 11 depicts an example table of Quality of Service (QoS) Class Identifiers (QCIs) and Associated Key Performance Indicators (KPIs).

[0024] FIG. 12 depicts

[0025] FIG. 13 depicts

[0026] FIG. 14 depicts

planes.

[0027] FIG. 15 depicts an example Flow-chart Illustrating a Slice Selection Process.

[0028] FIG. 16 depicts an example Call flow depicting slice selection based on subscriber profile.

[0029] FIG. 17 depicts an example Slice Negotiation, Selection and Attachment based on WTRU Request.

[0030] FIG. 18 depicts an example slice assignment based on Application Service Provider (ASP) driven service requirements.

[0031] FIG. 19 depicts an example Architecture for Network Exposure with Slice Selection.

[0032] FIG. 20 depicts an example Determining Static and Dynamic Service Function Paths (SFPs). [0033] FIG. 21 depicts an example Dynamic Service Function Chain (SFC) Determination.

[0034] FIG. 22 depicts an example Routing based on information within packet.

DETAILED DESCRIPTION

[0035] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

[0036] FIG. 1 A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0037] As shown in FIG. 1 A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0038] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0039] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MTMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0040] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).

[0041] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).

WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA). [0042] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0043] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for

Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0044] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[0045] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0046] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless

communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0047] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1 A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0048] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein. [0049] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the

transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0050] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0051] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

[0052] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0053] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0054] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0055] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0056] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like. [0057] FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0058] As shown in FIG. 1C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0059] The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0060] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0061] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0062] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0063] FIG. ID is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0064] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one

embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0065] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0066] The core network 107 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0067] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer

activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0068] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0069] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0070] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0071] FIG. IE is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0072] As shown in FIG. IE, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0073] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication,

authorization, IP host configuration management, and/or mobility management.

[0074] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0075] As shown in FIG. IE, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MTP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be

appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0076] The MTP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0077] Although not shown in FIG. IE, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0078] A 5G mobile network may support one or more of the following network functions. An Access and Mobility Management Function (AMF) may handle registration, connection, and/or mobility management of Next Generation UE (NG-UE). The traditional MME function in EPS may be split between a Security Anchor Function (SEAF) and an Authentication Server Function (AUSF). The SEAF may authenticate a NG-UE while interacting with an AMF. The SEAF may or may not be co-located with the AMF. The AUSF may interact with a Unified Data Management (UDM). The AUSF may include an Authentication, Authorization, and Accounting (AAA) server. The UDM may be the equivalent of a home subscriber server (HSS) in EPS. The Session Management Function (SMF) may be in charge of packet data unit (PDU) session management, which may be shared between the MME and the Control Plane of the Secure Gateway/Packet Gateway (SGW/PGW) in EPS. A User Plane Function (UPF) may include the RAN anchor point for user data in the 5G Core. The UPF may be an external PDU session point of interconnect to a Data Network. The functionality of the UPF may be shared between the User Plane of the SGW and the PGW, e.g., in EPS. A Policy Control Function (PCF) may be the equivalent of EPS PCRF. Separation of Control Plane and User Plane (SMF, UPF) and/or separation of mobility and session management (AMF, SMF) functions may be design features in the evolution from the EPS architecture.

[0079] While descriptions herein may illustrate the functionality for various forms of service delivery in the context of traditional 4G EPS system functions, that functionality may apply equally to 5G systems with the various definitions of the 5G network entities.

[0080] Examples of the use cases that are driving the 5G system architecture may include Enhanced Mobile Broadband (eMBB) connectivity, Massive Machine Type Communications (mMTC), and Ultra-Reliable Critical Communications (URCC) services.

[0081] For example, to meet eMBB design goals, 5G may continue to up the ante on the data rate. For example, 5G may make uplink data throughput as high as, or in excess of, downlink. The focus of 5G may be on coverage and user experience. The interest in 5G technologies may be simmering, and the industry may be funding projects looking into such technologies. While there may not be industry consensus on what 5G will ultimately be, apart from the higher data rate, lower latency, and energy efficiency, there may be some emerging signs of things to come. For example, in the IEEE 802.11 High Efficiency Wireless (HEW) study group, there may be a pronounced increase in the presence of cellular operators. The increase in the presence of cellular operators may indicate growing interests to amalgamate different access technologies developed in different Standards Development Organizations (SDOs) in order to support future connectivity and data rates. 5G may consist of multiple interconnected communication standards, ranging from wireless metropolitan area networks down to wireless personal area networks, and wired networks, providing the required throughput and connectivity.

[0082] A driver of the connectivity concept may be the pervasive presence of a variety of things or objects, such as RFID tags, sensors, actuators, and/or mobile phones in the environment around us. These things or objects may more popularly be known as the Internet of Things (IoT). Most of these objects or devices may interact with each other in a variety of ways and may generate huge amounts of data. A challenge to 5G systems from the convergence of the IoT and the Internet world as we know it may be the multitude and/or variety of service scenarios, many of which may not even have been dreamt of yet. The IoT for 5G systems may require loosely defined smart objects (e.g. M2M / IoT devices) to connect, and/or may enable them to interact with other objects to yield productivity and automation gains through predictive, actionable intelligence. For example, mobile devices may adopt silent mode when entering a meeting room if this is the request of the meeting moderator indicated in the policy, may alert the user and to turn off the radio on his/her mobile phone before entering sensitive medical areas, and/or may detect when the user enters his/her car and automatically to connect to its sound system. Wireless sensors may let people check where their pet is in real-time, as well as control the temperature for each room of their house while they are out. Emergency services may be remotely and automatically alerted if fire is detected in a building or if a patient's medical parameters shift beyond a critical threshold.

[0083] An additional new driver in 5G may be the need for increased service reliability for mission critical communications services, such as intelligent transportation systems. These use cases may drive towards new requirements for resiliency and reliability.

[0084] The latest efforts towards addressing the needs of 5G systems, in order to meet the needs for a multiplicity of often conflicting and new services requirements, may be bringing a paradigm shift that may be rapidly gaining ground. With much of the industry viewing the future wireless standards as focused on data rates, efficiency, and enabling new IoT services, most network vendors and operators may be looking at technologies which may cope with traffic growth of 1000 times but without such a corresponding increase in CAPEX and OPEX costs. The drive to reduce costs from a Mobile Operator and/or Service Provider perspective is a driver for consideration of revolutionary architectural approaches to the deployment of 5G networks. Underlying the revolution may be the notion that cost reduction and flexibility for wireless networks may be achieved by reducing the dependency on dedicated network functions and/or switching to generic commercial off the shelf (COTS) platforms, such as cloud computing utilizing virtualization technologies. The combined effect may be to drive a disruptive architectural revolution for 5G systems, compared to traditional 4G and other legacy systems.

[0085] With such a deep penetration of technology, which may introduce automation and remote interaction (e.g., a new kind of automation and remote interaction), and/or with heightened societal focus on privacy, new security and privacy issues may rise. Security and/or privacy issues associated with 5G networks and/or the new key technologies may be proposed.

[0086] Business Models for 5G Systems may now be described. [0087] 5G networks may be designed to connect industries (e.g., manufacturing and processing, intelligent transportation, smart grids, and/or e-health). Such environments may bring the challenge of speed, latency, and/or heterogeneity. Platforms (e.g., different platforms) interacting may mean different protocols, different interfaces, and different policies (e.g., QoS requirements). The diverse service contexts may introduce security and privacy considerations. For example, an e-health information system may require more privacy than a Home Automation System (HAS), which may need more security for Control Plane (CP) signaling. The sheer amount of data that may be expected to be transported, stored, and processed may mean that the current networks may be upgraded to accommodate the immense increase in data handling capabilities. Radio Network equipment that supports higher frequencies (e.g., Millimeter waves: 30GHz+), core networks that can store, forward, and/or process the data may be designed and deployed, thus creating a great increase in the CAPEX as well as associated OPEX that may be expended by mobile network service providers.

[0088] Different Mobile Network Operators (MNOs) may have different business models and different services rendered to end users. An MNO may be an Asset Provider, Connectivity Provider, and/or Partner service provider, as shown in the FIG. 2. An Asset Provider may be the one who may own a certain function of the network (partially/fully sharing the RAN and/or the core network). A connectivity provider may be an MNO who may not own any infrastructure, but provides a Network (e.g., IP) connectivity that may be offered to a consumer/business or to a wholesale/Mobile Virtual Network Operator (MVNO). A partner service provider may benefit from the service features offered by a 3 ^rd party operator who may own mobile connectivity capabilities. For example, the customers of smart wearable devices with services of a remote health monitoring company.

[0089] An Asset Owner may be a model where the service provider (SP) may own the infrastructure partially or in full. For example, a SP may own the core network while sharing the RAN network with other SPs. A cloud based scenario may be a scenario where an SP may share infrastructure with other SPs. This may introduce business models (e.g., new business models) in 5G networks with implementations ranging from dedicated H/W through to cloud-based services, including Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and/or Software-as-a-Service (SaaS). These scenarios (e.g., each of these scenarios) may give the SP a different level of control over the shared infrastructure and a varying set of privileges over the network. The connectivity provider may be an example of the cloud based ownership model where the SP may not own any infrastructure and the SP may function as a connectivity broker for end SPs.

[0090] Realizing the features of 5G networks may require consideration along three different dimensions: use-cases, service requirements and different business models, as shown in FIG. 3. These dimensions (e.g., each of these dimensions) may vary in such a way as to realize a variety of the 5G network features. The user requirements along with the 5G network features may form different use cases, as shown in FIG 3. The elasticity of the business models in 5G networks may provide an aspect (e.g., a third aspect) that may be considered when designing the 5G network.

[0091] The main features that are envisioned for 5G networks may include Flexibility and Scalability. Flexibility and Scalability may mean that the key connection attributes (e.g. mobility, security, privacy, reliability, latency, etc.) may be enabled, disabled, modified, and/or controlled in a programmable and/or switchable manner. The key connection attributes may be enabled, disabled, modified, and/or controlled in a programmable and/or switchable manner depending on use-cases, subscription details, and/or associated policies defined by operators.

[0092] The main features that are envisioned for 5G networks may include Context- awareness. Context awareness may allow for customization and/or creation of the application to match the preferences of the individual user. For example, context awareness may allow for customization and/or creation of the application to match the preferences of the individual user based on current context (e.g., location, time, activities, and services).

[0093] The main features that are envisioned for 5G networks may include Fixed-Mobile Convergence. 5G may support fixed and/or mobile convergence to ensure a seamless customer experience within the fixed and mobile domains (e.g., a unified user authentication, RAN, and/or CN independence).

[0094] The main features that are envisioned for 5G networks may include Energy and Cost efficiency, Operations awareness and efficiency, and/or Availability and Reliability (e.g., Resilience Networks).

[0095] The main features that are envisioned for 5G networks may include Enhanced Network Security. The security protocols may be improved to adapt to newly introduced use- cases (e.g., Massive Machine Type Communications (mMTC)), and may comply with security requirements defined in 3 GPP standards. [0096] The main features that are envisioned for 5G networks may include Enhanced user security and privacy. The introduction of business models (e.g., new business models) in 5G may make the user vulnerable (e.g., more vulnerable) to security and/or privacy breaches. For example, the introduction of business models in 5G may make the user vulnerable to security and/or privacy breaches due to different levels of trust and/or security required in each model. Protecting user privacy according to different contexts and/or applications may be a cornerstone of 5G security.

[0097] Concepts such as Network Slicing (NS) may be used to offer granular control (e.g., more granular control) of performance and/or network features based on the application and/or services being used, e.g., due to the diversity of applications and associated network service requirements (e.g. QoS, speed, latency, security) for an (e.g., each) application. Network Slicing may include architectures and procedures configured to provide relatively isolated sub-networks, each optimized for specific types of traffic characteristics. Each network slice may have a set (e.g., its own set) of security and QoS requirements and slices (e.g., all slices) may be isolated (e.g., potentially completely isolated) from each other.

[0098] Using a software-centric approach (e.g., a more software-centric approach), network functionalities (e.g., some or all of the network functionalities) may be virtualized and/or shared by mobile network operators using Network Function Virtualization (NFV) and/or other virtualization techniques, which may share the costs and/or optimize network utilization. 5G networks may introduce new architectures and/or technologies in the communications industry and virtualization and NFV are enablers for NSs.

[0099] Network Slicing may be used to support different use cases across business models (e.g., different business models), which may drive the need for enhanced network capabilities (different HAV components for different use cases and business models). This may increase the capital expenditure (CAPEX) and the operating expenditure (OPEX) dramatically in 5G networks. Use of network slicing may be used to effectively provision a wide spectrum of use- cases in 5G. A Slice may be associated with a set of features that may achieve the requirements of a certain use-case taking into consideration the capabilities of the operator(s) who may provide this service. A slice may be realized by taking into account the current 3GPP standard procedures and protocols. [0100] 5G networks may support dedicated vertical use cases, such as intelligent transportation, gaming, remote machinery, and/or virtual reality that may have different service requirements. Virtual slices of one or more networks that may support the requirement may be designed, e.g., in order to be able to support such differentiated application and services. Such virtual Slices may be logical instantiations of the network resources (e.g., required network resources). Using automated management based on NFV technologies, operators/service providers may be able to support such a slicing. A description of network slicing is shown in FIG. 4 according to next generation mobile networks (NGMN) 5G requirements and

architecture. A network operator may use a Network Slice Blueprint to create a Network Slice Instance. A Network Slice Instance may provide the network characteristics (e.g., layers (e.g., all layers) from the Radio Access layer up to the service layer) which may be used (e.g., required) by a Service Instance. A Network Slice Instance may be shared across multiple Service Instances provided by the network operator.

[0101] Network Function Virtualization may be utilized to support network slicing. NFV technology may be a way (e.g., a new way) to build an end-to-end network infrastructure with evolving standard IT virtualization technology to enable the consolidation of heterogeneous network devices onto standard high-volume servers, switches, and/or storage. The virtual network functionality of a network device may be implemented as a software package. A Virtual Network Function (VNF) may run on one Virtual Machine (VM) as a VNF Instance (VNFI) or more than one VM as a VNF Component Instance (VNFCI). The OPEX and CAPEX may be reduced, e.g., because the network functions may be executed on standard servers without requiring expensive function-dedicated devices (e.g., Media Gateways, Firewalls, etc.).

Dedicated Hardware (HW) functionality (e.g., crypto-accelerators) (e.g., some of the currently dedicated Hardware (HW) functionality) may not be efficiently implemented in pure software (SW) and generic architectures, which may accommodate a level of hardware acceleration and/or programmability (e.g. FPGA. Companies (e.g., Intel) may be addressing this limitation, e.g., by including crypto-accelerators and/or FPGA in default COTS HW configurations. It may be easier to introduce and/or test a new network function by installing and/or upgrading a software package, which may be run on the servers.

[0102] An example architecture of NFV may be illustrated in FIG. 5, and the following features may apply. A key feature may include Virtual infrastructure (NFVI), into which virtual machines may be created on generic high-volume hardware servers and/or storage devices, connected by generic high-volume network switches and organized by the orchestration (e.g., Hypervisor). A feature of NFV may include Separation of the software that defines the network functions for network devices from generic hardware. A key feature may include Management and Orchestration (MANO), which may automate installation and/or management of the virtualized network functions on the generic hardware.

[0103] Benefits of NFV technology may include carriers being able to build and/or operate a flexible and/or highly configurable network with reduced equipment costs and/or reduced power consumption. Carriers may be able to build and/or operate a flexible and/or highly configurable network with reduced equipment costs and/or reduced power consumption because consolidating equipment and/or exploiting the economies of scale of the information technology (IT).

[0104] The role of the Management and Orchestration (MANO) within NFV may be to manage the NFV Infrastructure (NFVI) and to perform resource allocations that may be used (e.g., needed) by the various network services and VNFs. The MANO may be involved in the management and/or orchestration of Network Functions Virtualization Infrastructure. The components that may be managed may be virtualized or partially-virtualized resources, such as: (a) Computing infrastructure, that may include computing machines and virtual machines having CPU and/or memory; (b) Storage, that may include Non-volatile secure storage; and (c)

Network, that may include Subnets, ports, networks, etc. The MANO may be involved in the management and/or orchestration of Virtualized Network Functions, that may involve the management and/or orchestration of VNFs pertaining to fault, configuration, accounting, provisioning, and/or security (FCAPS). The ability to instantiate, scale, upgrade, and/or terminate VNFs. The MANO may be involved in the management and/or orchestration of Network Services, that may involve managing the lifecycle of network services (e.g., instantiation of services, scaling (elasticity), termination of services, etc.). The MANO may be involved in the management and/or orchestration of Miscellaneous, that may include Policy management, interactions with legacy or new Operations Support Systems/Business Support Systems (OSS/BSS), etc.

[0105] The NFV Architectural Framework may include one or more functional blocks. The functional blocks may include NFV Orchestrator (NFVO), VNF Manager (VNFM), and/or Virtualized Infrastructure Manager (VIM), as shown in FIG. 6. The NFVO may perform orchestration functions of NFVI resources across VIMs (e.g., multiple VIMs) and/or lifecycle management of network services. The VNFM may perform orchestration and/or management functions of VNFs. The VFM may perform orchestration and/or management functions of NFVI resources within a domain. The NFVO may interact with the OSS/BSS, possibly legacy system, for provisioning, configuration, capacity management, and/or policy-based management. The VNFM may interact with the Element Manager (EM) and the VNF for provisioning,

configuration, and/or fault and/or alarm management. The VIM may interact with the NFVI for the management and/or orchestration of virtualized resources. The term NF, VNF, and/or PNF may be used to refer to a network function.

[0106] Software Defined Networking (SDN) may be a complementary technology to NFV. SDN may enable realization of the control plane user plane and/or management plane for NFV. SDN may be a solution for enabling network function virtualization and/or network

programmability, which may be the protocol building blocks for the next generation of 5G networks. The SDN network architecture may consist of a centralized network controller in the control plane, which may be responsible for allocating traffic to network elements in the separated data plane of the network, as described in FIG. 7. The network controller may maintain (e.g., centrally maintain) the intelligence and/or state of the network (e.g., the entire network). The network controller may output control rules (e.g., the best fine granular flow routing control rules) to the heterogeneous network devices from vendors (e.g., different vendors). The network controller may provide a global united view and/or resources of the network to the upper layer network applications as a single, logical switch. For example, the network controller may provide a global united view and/or resources of the network to the upper layer network applications as a single, logical switch through the northbound interface. Novel network applications may be created, tested, and/or deployed (e.g., may easily be created, tested, and/or deployed). For example, novel network applications may be created, tested, and/or deployed in a short time. SDN protocols may enable control-plane management and may be separated from the data/user plane.

[0107] Open flow is defined by the Open Networking Foundation (ONF) and may be accepted (e.g., broadly accepted) as SDN protocol (e.g., dominating SDN protocol) in the southbound interface between the network controller and network devices. Open flow may be supported by device manufacturers, service providers, and/or operators. For CES and/or PCE, defined by the Internet Engineering Task Force (IETF), may be southbound SDN protocols (e.g., alternative southbound SDN protocols). SDN protocols for the northbound interface may currently be under development.

[0108] Specifying Service Requirements through QoS Class Identifiers may now be described.

[0109] Three use cases (e.g., main uses cases) driving 5G networks may be expanded into a range of QoS Class Identifiers (QCI), which may provide service selectively (e.g., fine grained service selectivity). For example, the eMBB category may be sub-divided into ultra-high speed, high speed, high mobility, and/or low cost, where each of these specific categories may be serviced by slice specifications (e.g., different slice specifications), as shown in FIG. 8.

[0110] Slicing may include architectures and procedures configured to provide isolated subnetworks. The sub-networks (e.g., each of the sub-networks) may be optimized for types (e.g., specific types) of traffic characteristics. A slice may be formed based on the set of requirements needed to provision a certain session (e.g., use-case).

[0111] A slice may map to service characteristics (e.g., a set of service characteristics, such as latency, throughput, etc.) that may be provisioned in the slice. Each of the service

characteristics may be associated with a QoS Class Identifier (QCI). QCIs may be used (e.g., commonly used) to set up data bearers (e.g., different data bearers) that may be assigned to sessions (e.g., different sessions) of a WTRU. For example, in a legacy LTE network, QCI-4 may describe requirements (e.g., a set of requirements) that may be needed to set up a Video Streaming session. The notion of QCI may be extended to support a slice definition. For example, with an expansion of the services to be covered in 5G networks, as well as the flexibility of such networks, it may be natural to extend the notion of QCI to support a slice definition

[0112] Enabling Network Slice Configuration through QoS Class Identifiers may now be described. 3 GPP may define a Service Capability Exposure Function (SCEF) as an enabler for a server side API for 3rd party applications. By exposing network capabilities (e.g., selected network capabilities), the SCEF may enable business opportunities (e.g., new business opportunities) through network optimized services from OTT and/or Vertical industries. FIG. 9 shows the a (e.g., the current) 3GPP architecture. [0113] In 5G networks, a slice (e.g., each individual slice) may be tuned (e.g., optimally tuned) for a use case (e.g., a particular use case), which may enable the realization of networks, which can accommodate simultaneously and/or cost efficiently multiple applications with a wide range of QoS performance and/or security requirements, through provisioning of services over one or more slices.

[0114] There may be an active effort within the IETF in the areas of Virtualization, Function Chaining, etc., that may be carried out within the Service Function Chaining (SFC) working group. A concept (e.g., the general concepts) of SFC and/or the enablers for providing function chaining may be described.

[0115] IETF may define SFC as "an ordered set of abstract service functions and ordering constraints that may be applied to packets and/or frames and/or flows selected as a result of classification." An example of an abstract service function may be "a firewall." At a high level, an SFC may be an abstracted view of a service that may specify the set of required SFs, as well as the order in which they are executed. A logical path may be created that may ensure that a packet is treated at a function (e.g., each of the functions) as specified by the SFC.

[0116] The Network Service Header (NSH) may be an enabler to dynamic SFC deployment. An NSH may be used to define a data plane protocol specifically for the creation of dynamic service chains. NSH may address the limitations of static SFCs that was mentioned herein, including topology dependency, monitoring and troubleshooting a SFC, classification and reclassification realization in SDN Open Flow switches and transport layer protocols dependency (NSH is transport agnostic). The NSH header may include service path information and/or metadata that may be added to a packet and/or frame and/or used to create a service plane, as shown in FIG. 10. The packets (e.g., original packets) preceded by NSH may be encapsulated in an outer header for transport. A part (e.g., the main part) in the NSH may be the Service Path Header. The Service Path Header may constitute the Service Path Identifier (SPI) and/or the Service Index (SI). The SPI may identify a service path (e.g., a certain service path). The SI may provide a location within the SFP. Service index may be decremented, e.g., by service functions and/or proxy nodes, after performing services (e.g., required services) and/or the SI value (e.g., the new decremented SI value) may be reflected in the egress NSH packet.

[0117] Problem Statement: Matching WTRU Services to Network Slices may now be described. [0118] Current 3GPP networks may not have and/or support a notion of slicing. Slicing may be associated with mechanisms to provide isolated sub-networks, each optimized for specific types of traffic characteristics. Support for NS may be required in 5G mobile networks in non- roaming and/or roaming scenarios, in addition to support for 4G WTRUs.

[0119] When a WTRU attaches (e.g., initially attaches) to a network, the WTRU may attach (e.g., attempt to attach) to a slice (e.g., a particular default slice) from which the WTRU may request services that may be supported by the slice. The serving network may communicate with the WTRU to ascertain the type(s) of service and to then provide the services through a particular slice(s), e.g., in order for the serving network to deliver such services. Such awareness may be achievable (e.g., easy to achieve) by pre-provisioning slices used (e.g., required) by the WTRU Subscriber Profile (e.g., provisioning a list of supported slices in the ME or UICC). In a roaming scenario and/or during an ongoing session when a service is added, the serving network may not be pre-provisioned. In a roaming scenario, the Home Network may not control and/or predict which foreign network the WTRU may attempt to attach. Slices realized in the Home Network may be different from slices realized in the Serving Network and/or slices realized in the Home Network may not exist.

[0120] There may be a need to expose the services of a network so that a WTRU's service requirement may be matched with the services available from the 5G network. The exposure may be used (e.g., required) at the WTRU level and/or at the network level to shared network service providers and/or OTT service providers. The exposure may be used (e.g., required) for alignment of services between difference network service providers.

[0121] With the diversity of services envisioned for 5G networks, there may be a use (e.g., need) to provide security mechanisms (e.g., a variety of security mechanisms) from protecting CP signaling (e.g., only CP signaling) through to protecting CP and/or UP traffic in terms of integrity and/or confidentiality protection.

[0122] The communications over the air and/or inside the network may be protected with integrity and/or confidentiality protection for services. For example, a vertical health care application (e.g., remote patient monitoring) may use (e.g., require) that a slice with the highest security/QoS attributes may be selected to provide the health-care data and communications with integrity and/or confidentiality and/or privacy. For example, the health-care application may be used by a medical professional attending to a patient in a moving ambulance. When the application is started by the medical professional, based upon the application within the WTRU using (e.g., requiring) a connectivity service that may satisfy the desire (e.g., need) to "provide a secure and reliable communication channel" in order to report biological data (e.g., frequently and/or reliably small amounts of biological data, such as blood pressure, heart rate, glucose level from a moving ambulance (0-120 km/h)), to an application server. The application server may protect private patient data and may satisfy (e.g., at the same time satisfy) the time criticality aspect of the communications.

[0123] A driver for flexible security in 5G networks may be the need to support a diverse set of devices from smartphones, smart appliances, smart meters, and/or small footprint, battery powered devices. The resources (e.g., limited resources) of such devices (e.g., low power consumption, low memory, and/or low computational capacity) should be taken into account when designing security algorithms for 5G systems. For example, sensors may be resource constrained and may not support cryptography. Deploying cryptographic capabilities may increase the cost per sensor and may be prohibitive to the application. A standard cryptographic hash function, for example, such as SHA-3, may be beyond the capabilities of some sensors. Lightweight authentication protocols and hashing algorithms, which may have been studied during the last decade, may be key enablers for 5G networks.

[0124] Current integrity protection algorithms are inherited (e.g., fundamentally inherited) from legacy 3G networks (e.g., SNOW 3G, Kasumi, Milenage, and/or ZUC) and may provide integrity protection for Signaling Radio Bearers (SRBs). Developing and/or offering a capability to utilize a variety of integrity and/or confidentiality protection algorithms for CP and/or UP data and/or for a diversity of use cases may become a pressing requirement for 5G systems.

[0125] The a WTRU may specify service requirements through QCI, which may be matched to the use cases in 5G systems. Techniques from IETF to facilitate network configuration in a manner suitable for 5G networks to match requested service requirements in a network through propagation of the QCI may be utilized.

[0126] The use of QCI (e.g., a variety of QCI) to provide services to a WTRU, aligned with the capabilities of a NS, is described herein. An application service provider may choose to provide services based on a service descriptor (e.g., High Mobility and/or Legacy Streaming, etc.), which may be interpreted into detailed information that includes the QCI service requirements to include security requirements of the application. A summary of the high-level steps that may be performed in order for the communications and the associated data to be handled in a secure manner may be provided herein. For example, a summary of the high-level steps that may be performed in order for the communications and the associated data to be handled in a secure manner may include Slice Assignment based on Security Requirements, Mapping Slice to Appropriate Path and Functions, and Routing through Assigned SFP.

[0127] A slice assignment may be determined based on security requirements.

[0128] For example, in Slice Assignment based on Security Requirements, a detailed slice request, negotiation, and assignment process may be performed. The representation of a set of service-specific and/or application-specific QCI parameters may be defined by means of a Service Description Document (SDD). Details of the SDD and the Slice request/negotiation processes may be described herein.

[0129] A Service Description Document for network slicing may be utilized.

[0130] An NS's services may be described by a Service Description Document (SDD). An SDD may include a description of the services provided by a particular NS (e.g., latency, throughput, etc.) and/or their corresponding QoS Class Identifier values. QCIs may be used (e.g., commonly be used) as a service characteristic for data bearers (e.g., different data bearers) that may be assigned to sessions (e.g., different sessions). The notion of QCI may be extended to support a slice definition. A SDD may have QCIs for affinities and/or restrictions used (e.g., required) for a slice (e.g., geographical affinity and/or restriction, certain hardware affinity and/or restriction, restriction on the capacity of the slice, etc.).

[0131] Traditional networks may provide a set of services within a single network. The network may be catered for a limited set of service characteristics that may be separated into two or more major classes. The major classes may include real time services and/or non-real time services. The real time services may be a conversational class and/or a streaming class. The non-real time services may be an interactive class and/or a background class. Applications and/or services on a WTRU or in an application serving network may be aligned with the best fitting and/or most suitable NSs. The SDD, which may also be referred to and used

interchangeably herein as a Network Slice Selection Assistance Information (NSSAI), may be sent to a SN, for example, in a service request message. The NSSAI may include one or more single NSSAIs (S-NSSAIs). The network may select a NS based on the NSAAI. An S-NSSAI may identify a NS. The S-NSSAI may include a slice/service type (SST), which may refer to expected NS behavior, for example, in terms of QoS features and/or services. The S-NSSAI may include a Slice Differentiator (SD). The SD may include optional information that complements the SSTs. The SD may enable further differentiation for selecting an NS instance from multiple NS instances that may comply with the indicated SST.

[0132] FIG. 11 illustrates an example mapping 1100 of the QCI and associated key performance indicators (KPIs) to various service categories. For example, an SDD may specify QCI and KPIs that correspond to the QCI may be determined, e.g., derived from the 3GPP standard. The QCI and associated KPI may be non-exhaustive and may illustrate a range of use cases of differing service requirements (e.g., security). QCI may include one or more of data rate, latency, reliability, availability, mobility, density, and/or power. The detailed QCI / Security requirements and associated KPIs may be matched up with the three use cases as described in FIG. 8. Each KPI may have different QCI for the uplink and the downlink. For example, two data rate values may be associated with a KPI. When two data rate values are provided for a KPI, an upper data rate value may be for the downlink and/or a lower data rate values may be for the uplink.

[0133] One or more parameters (e.g., the first three QCI parameters shown in FIG. 11 A, such as Data Rate, Latency, and/or Packet Loss Error Rate) may be inherited from a legacy 3GPP LTE QCI table. Such parameters may not be sufficient to provision the new features and/or requirements in 5G networks. For example, as shown in FIG. 11 A, a low Packet Loss Rate (PLR) value may not guarantee a reliable network. The Radio Link Control (RLC) protocol at the radio link layer (RLC mode - Transparent, Ack, or UnAck.) and/or the Hybrid-ARQ retransmissions (retransmissions threshold) at the MAC layer may be configured in modes (e.g., different modes) to enable reliable (e.g., more reliable) communications.

[0134] Controlling the call/session Success Rate (SR) and/or the call/session setup time may enforce the network availability as a feature (e.g., new feature) in 5G networks. Dense networks may emerge in 5G networks, for example, because of the massive increase in the number of WTRUs and/or the introduction of the new mMTC use case. Connection density may be an indication of the number of connections per unit area. Traffic density may be an indication of total required data rate per unit area. For example, the connection density may be expected to be high (e.g., extremely high) in the mMTC use case, unlike the traffic density, which may not be high in the mMTC use case. Traffic density may be high in the dense BBN use case (e.g., because of high data rates).

[0135] User Mobility may affect the slice composition. As shown in FIG. 1 IB, a Handoff Success Rate (HOSR) of eNBs is a metric that may be used to select an appropriate eNB to serve a session according to the use case's required mobility management.

[0136] The variety of diverse 5G use cases may impose one or more security requirements on the delivered services (e.g., confidentiality, integrity protection, authorization, and/or user privacy). For example, unlike the current 3GPP Radio Resource Control (RRC) protocol, data plane security may be determined by the services being provisioned and/or established for a session. For some 5G use cases, the International Mobile Subscriber Identity (IMSI) and/or the Temporary Mobile Subscriber Identity (TMSI) may be protected in all over-the-air connectivity modes for use cases. The security considerations may be considered for 5G systems by providing mechanisms to tune the security algorithms and/or parameters for services (e.g., different services). Introducing use cases (e.g., new use cases) may impose the use of (e.g., need for) new authorization mechanisms (e.g., multi-level authorization). Such security implications (e.g., new security implications) may introduce (e.g., mandate introducing) security attributes to the QCIs, as shown in FIG. 1 IB and 11C.

[0137] For the mMTC use case and/or the low cost eMBB use case, network security algorithms to may be (e.g., may need to be) power efficient (e.g., highly power-efficient). Low- complexity and/or scalable algorithms may be vital in an mMTC use case. For example, low- complexity and/or scalable algorithms may be vital in an mMTC use case in order to minimize the burden (e.g., processing burden) on devices (e.g., small footprint battery powered devices) expected to be serviced. Privacy (e.g., user privacy) may be of concern in the URLL use case due to the need for critical applications, such as intelligent transportation systems. A security level may indicate a level of authentication strength, a level of integrity protection, a level of confidentiality protection, a level of isolation of functionality from other services, and/or a level of privacy protection. The security level may be indicated for user plane data and/or control plane messages. The level of protection may indicate a strength of the security algorithm, a length of a credential or key, one or more security protocols used, a type of security algorithm (e.g., such as asymmetric keying vs. symmetric keying), etc. A security level may include a security assurance level of the platform and/or a security assurance level of the network(s) that is providing the services including application servers, routers, and the whole infrastructure. A security assurance level may indicate one or more security policies, processes, procedures, and/or best practices that may have been developed and/or used for deployment of the network and services by a serving network or application services provider. Security levels may not be limited to those described herein and may also include other features such as replay protection, protection against breaking of a security algorithm by means of quantum computers, etc.

[0138] FIG. 12 depicts an example simple SDD 1200. When a user initiates a session using an application, the application/WTRU may send a SDD 1200 to the network. This SDD 1200 may include the package of services requested by the user. The SDD 1200 may be associated with an application {e.g., such as whatsapp as shown in FIG. 12). For example, the SDD 1200 may enable the application and/or a WTRU to provide information about the application service characteristics. For example, the SDD 1200 may enable an application and/or a WTRU to provide information about the application service characteristics bundled as part of the application and/or to provide details (e.g., granular details) about security and/or other QoS requirements to a Serving Network (SN). An application and/or underlying application-aware service requirements layer and/or other lower layers may communicate the required service from a WTRU to a Service Network using a SDD 1200.

[0139] The service characteristics (e.g., QoS and/or security requirements) of applications may be communicated from the application to lower layers (e.g., MAC / Logical-link layer) by means of cross-layer messaging. The lower layer protocol may communicate the SDD 1200 to the SN using MAC / Logical-link layer protocols (e.g., RRC/NAS and/or 5G/New Radio (NR) MAC layer protocol). The QoS requirements may be communicated via a service layer which may be used by the WTRU and/or application to communicate the SDD 1200 to the SN using protocols, such as HTTP. The SDD 1200 may be pre-configured at the appropriate layers. For example, the SDD 1200 may be pre-configured at the appropriate layers without the requirement for cross-layer messaging. The QoS and/or security requirements may be provided by means of an API to a user interface. For example, the QoS and/or security requirements may be provided by means of an API to a user interface so that a user may be made aware of the security and/or QoS requirements. The SDD 1200 may indicate a type of application 1204 and/or a class of application 1206. The SDD 1200 may indicate a SDD identifier (ID) 1202 that is associated with the application. For example, the header of the SDD 1200 may include an SDD identifier 1202 (e.g., SDD ID), its associated attributes (e.g., digital signature, date of creation, author, owner, alias, preferred operator, etc.). The header of the SDD 1200 may indicate the type of application 1104 and/or the class of application 1106.

[0140] FIG. 13 depicts an example SDD 1300 with service information 1310. For example, the example SDD 1300 may provide information (e.g., granular information) regarding the services that form part of the application. The SDD 1300 may describe one or more service components of a requested and/or offered Network Slice (NS) (e.g., HD Audio, SD Video, Text 140, store and forward, etc.) and/or their associated QCIs, security requirements etc. The SDD 1300 may indicate one or more of a SDD ID 1302, a type of application 1304, a class of application 1306, a security level 1308, one or more services 1310, or one or more security parameters 1312 associated with the SDD. As shown in FIG. 13, the services 1310 indicated by the example SDD 1300 may include a legacy conversation voice, a low cost video, and/or an SMS. Additional parameters indicated via the services 1310 may include the SST, SD, and security parameters 1312. The security parameters 1312 may include a security algorithm, a confidentiality, an integrity requirement, a privacy requirement, an issuer, a key identifier (KID) or credential identifier, a digital signature, and/or the like.

[0141] FIG. 14 depicts an example SDD 1400 that separates QCI according to different service planes (e.g., user plane and/or control plane) and/or for uplink and downlink. An application may request an SDD 1400 with Security and QoS requirements (e.g., very detailed Security and QoS requirements) by specifying custom QCI for a particular application. The SDD 1400 may specify QCI for discrete services. For example, the SDD 1400 may specify QCI for a first service 1410 (e.g., Service 1), a second service 1420 (e.g., Service 2), a third service 1430 (e.g., Service 3), and a fourth service 1460 (e.g., Service N). The SDD may indicate various QCI for each service. For example, the SDD 1400 may indicate a first QCI 1412, a second QCI 1414, a third QCI 1416, and a fourth QCI 1418 for the first service 1410. The SDD 1400 may indicate a first QCI 1422, a second QCI 1424, a third QCI 1426, and a fourth QCI 1428 for the second service 1420. The SDD 1400 may indicate a first QCI 1462, a second QCI 1464, a third QCI 1466, and a fourth QCI 1468 for the fourth service 1460.

[0142] The SDD 1400 may separate attributes into different service planes. For example, one or more of the services (e.g., the third service 1430 as shown in FIG. 14) may be associated with one or more service planes. The SDD 1400 may specify, for one or more of the services 1410, 1420, 1430, 1460, QCI for a Control Plane (CP) 1402, a User Plane (UP) 1404, and a Management Plane (MP) 1406. The SDD 1400 may indicate a first QCI 1432, a second QCI 1434, a third QCI 1436, and a fourth QCI 1438 for a control plane 1402 of the third service 1430. The SDD 1400 may indicate a first QCI 1442, a second QCI 1444, a third QCI 1446, and a fourth QCI 1448 for a user plane 1404 of the third service 1430. The SDD 1400 may indicate a first QCI 1452, a second QCI 1454, a third QCI 1456, and a fourth QCI 1458 for a management plane 1406 of the third service 1430. Network slice parameters for appropriate service planes may be expressed by a corresponding set of QCI attributes. For example, as depicted in FIG. 14, the CP 1402, the UP 1404, and the MP 1406) for Service 3 may each have a separate set of corresponding service plane attributes.

[0143] Standardized and/or pre-provisioned NS's may be requested by a WTRU by including an SDD ID and/or its alias (e.g., "whatsapp" would be an alias for a NS with a particular SDD ID and/or associated set of services) in a request (e.g., a requested SDD

(SDDR)). The NS requirement may be categorized (e.g., may alternatively be categorized) as a NS with the slice descriptor. For example, the NS requirement may be categorized as an NS with the slice descriptor as shown in FIG. 11. For example, the whatsapp application scenario may include at least one or more of the following services: a Legacy Conv Voice service, a NS with a Low Cost data service, and/or a NS with SMS texting service capability. Each of these services may be associated with one or more unique network slices. The services may be enabled via multiple NSs. Each of the multiple NSs may cater to the different traffic

characteristics specific to the individual service flow and/or a packet data unit (PDU) session. Such an SDD alias translation into NS requirements may work if (e.g., only if) such SDD ID or SDD aliases are standardized. Additional examples may include default NSs (e.g., legacy 4G NS, Emergency Calling NS, credential provisioning NS, etc.), which may be available for selection in home and/or roaming scenarios. A set (e.g., an expanded set) of NSs (e.g., predefined NSs) may be made available by way of a negotiation involving a Request (e.g., a requested SDD (SDDR)) and an Offer (e.g., an offered SDD (SDDo)).

[0144] A network may select one or more NS(s) based on an attempt to match the SDD characteristics with the network's slices, e.g., when a network receives an SDD. An example slice-selection may be summarized by means of the flowchart as illustrated in FIG. 15. [0145] An SDD may be encoded using JSON, XML, CBOR, and/or a compressed data record. The SDD may be protected for integrity and for confidentiality. Integrity of the SDD may be provided by creating a digital signature, for example, by the issuer using asymmetric cryptography. A digital signature on the SDD may be generated by the issuer by using the private key of the "issuer" (e.g., facebook.com). Symmetric keys may also be used to provide integrity for the SDD. A digital signature may be generated by means of asymmetric cryptography (e.g., Elliptic curve digital signature standard (ECCDSA)) that may or may not be quantum computer safe. The SDD may be protected for confidentiality and/or privacy by encrypting the SDD and/or enveloping the SDD into an object (e.g., a secure object, such as Json Web Encryption object (JWE) or an equivalent CBOR object etc). Encryption of the SDD may be achieved by means of symmetric keys that are shared between the application and/or WTRU and the SN. The encryption and privacy of the SDD may also be ensured by encrypting the SDD using the public key (asymmetric cryptography) of the SN. The SN may decrypt the SDD by means of the private key of the SN. One or more public keys associated with the SN may be assumed to be pre-provisioned, obtained by the WTRU during the initial connect / authentication phases, and/or using any other key distribution mechanism.

[0146] A WTRU and/or an application may negotiate a slice assignment with a SN.

[0147] When a particular application on a WTRU requests a service, an SDD may be presented (e.g., sent) to the SN by the WTRU. The SN and/or the WTRU may perform a slice negotiation, followed by a slice assignment to the WTRU. A flow-chart that describes the slice negotiation and/or selection process between the SN and the WTRU is provided in FIG. 15. The WTRU may have performed an attachment with the serving network using the MAC / Link Layer before the Slice Negotiation and/or Assignment occurs.

[0148] The Slice Selection may include one or more of the following messages and/or procedures.

[0149] The WTRU may have performed an attachment and/or authentication prior to slice selection. For example, the WTRU may have performed an attachment and/or authentication to the functional block in the SN that is common for a group or all slices being served by the SN using the MAC / Link Layer before the Slice Negotiation and/or Assignment occurs.

[0150] FIG. 15 depicts a flow-chart of an example slice selection 1500. A Request message that includes an SDD may be received by the SN. For example, a Request message that includes an SDD may be received by the SN from a WTRU. The Request message may include a Requested SDD (SDDR). The SDDR may include zero or more SDDs (e.g., an array of SDDR). The SDDR may be a network slice selection assistance information (NSSAI) message. A NSSAI message may include a collection of various single NSSAI (S-NSSAI) messages. A S-NSSAI may assist the network in selecting a particular Network Slice. For example, a S-NSSAI message may identify a network slice. A S-NSSAI message may include a slice/service type (SST) and/or a slice differentiator (SD). The SST may indicate the expected Network Slice behavior, for example, in terms of features and/or services. The SD may complement the SST and may allow further differentiation for selecting a Network Slice from the potentially multiple Network Slice instances that may comply with the indicated Slice/Service type.

[0151] At one 1502, the Serving Network (SN) may determine whether a lower-layer connection Request may be made by a legacy WTRU (e.g., 4G device). If the WTRU is determined to be a legacy WTRU, the process may move to Step nine and/or, based upon policy, the process may be terminated or a default legacy slice may be assigned. This step may be useful in order to mitigate masquerading attacks (e.g., WTRU pretending to be a 5G device).

[0152] At two 1504, the SN may determine whether the WTRU is authorized to perform a request to obtain a slice by retrieving the WTRU and/or Subscriber Profile (SProf) 1540). The SProf 1540 may include information about the WTRU and/or Subscriber which may be stored in a database within the SN and/or in a trusted third-party network. If the SN determines that the WTRU is not authorized, the flow may move to twelve 1524 to seek WTRU authorization.

[0153] At three 1506, the SN may determine if the WTRU had provided a Requested SDD (SDDR), e.g., if the WTRU has been deemed to be authorized to perform the Request. The SDDR may be a first SDDR. The SN may perform ten 1520 to obtain an SDD from a stored SProf 1540, e.g., if the WTRU did not provide an SDDR within the Request message. As described herein, the SDD may indicate a QoS requirement using a QCI value. The SDD may indicate respective QoS requirements for a control plane, a user plane, and a management plane and/or security requirements of a service.

[0154] At four 1508, the SN may determine if an Offered SDD (SDDo) that fulfills the SDDR, e.g., if an SDDR was present in the Request message. For example, the SN may determine if the SN has an available SDDo that satisfies the SDDR. An SDDR and/or SDDo may be made up of one or more SDDs. An SDDo may satisfy the SDDR when the SDDo includes QoS and security requirement(s) that meet or exceed the QoS and security requirement(s) indicated by the SDDR. The SDDo may be associated with a network slice.

[0155] At five 1510, the SN may determine if there is a match (e.g., an exact match) between the SDDR and the SDDo. For example, the SN may determine that the SDDo is a match for the SDDR. The SN may determine that the SDDo is a match for the SDDR when the SDDo is configured (e.g., tailored) for the application associated with the SDDR. The SDDo may be configured (e.g., tailored) for the application when it indicates the application and includes QoS and/or security requirement(s) associated with the application. The SN may determine that the SDDo is not a match for the SDDR when the SDDo is not configured (e.g., tailored) for the application associated with the SDDR. For example, a match (e.g., an exact match) may include a WTRU sending an SDDR for "MyChatApp" (e.g., whatsapp) application and/or the SN having a slice (e.g., an SDDo) specifically pre-tailored for "MyChatApp." If there is not a match (e.g., an exact match) thirteen 1526 may be performed.

[0156] At six 1512, if there was a match (e.g., an exact match) between the SDDR and the SDDo, authorization checks may be carried out, for example, if the slice service is a high integrity service. Authorization checks may include multi-factor subscriber and/or user authentication. Multi -factor user authentication may include platform attestation. In some cases, an explicit user consent may be obtained (e.g., in case of extra cost associated with access to the particular slice).

[0157] At seven 1514, the SN may determine if the WTRU and/or subscriber has been authenticated (e.g., adequately authenticated), for example, when it determines that additional authorization checks are required. If authorization checks have not been passed (e.g., the WTRU and/or subscriber are not authenticated), the flow may move to eleven 1522 and the SN may send a service request denial to the WTRU.

[0158] At eight 1516, if the authorization checks have been completed (e.g., successfully completed), the SN may determine if the WTRU has requested a catalog (e.g., an entire catalog) of the services offered by the SN.

[0159] At nine 1518, a slice (e.g., network slice) that matches the SDDR may be assigned to the WTRU and/or application, for example, if the WTRU did not Request for a catalog (e.g., an entire catalog) of services offered. For example, the SN may assign the slice to the WTRU based on the QoS and security requirement(s) indicated in the SDDR. The SN may send, to the WTRU, a response message that indicates the successful assignment of a slice that meets or exceeds the

[0160] At ten 1520, the SN may obtain the SDDR from the SProf 1540 and/or the results may be provided to determine a default SDD that may be assigned (e.g., offered) to the WTRU. The subscriber may be authorized to be assigned one or more SDDs. The SDDs identified by associated SDD IDs (e.g., each one of the SDDs identified by associated SDD IDs) may be obtained from the SProf 1540, e.g., if the subscriber is authorized to be assigned one or more SDDs.

[0161] At eleven 1522, if an SDDo does not match the SDDR (e.g., as determined in four 1508) and/or if the WTRU has not been authorized (e.g., based on a determination at seven 1514), a service request denial may be sent by the SN (e.g., sent by the SN to the WTRU).

[0162] At twelve 1524, if a WTRU has not been authorized to perform a Request for a slice (e.g., as determined in two 1504), the WTRU may seek to obtain authorization (e.g. using payment and/or subscriptions options).

[0163] At thirteen 1526, if the SDDo does not match the SDDR, then the WTRU may determine if the SDDo is acceptable. For example, the SDDo may satisfy the QoS and/or security requirement(s) associated with the application but not match the SDDR. The WTRU may determine that the SDDo is acceptable if based on the QoS and/or security requirement(s) indicated by the SDDo.

[0164] At fourteen 1528, if the WTRU determined that the SDDo was acceptable, the WTRU may determine a second SDDR (e.g., a new SDDR) based on the SDDo. In some cases the second SDDR may be the SDDo (e.g., the complete SDDo) and in other cases, the SDDR may be a subset of the SDDo.

[0165] At fifteenl 530, if the WTRU determined that the SDDo was not acceptable, the WTRU may determine to request a catalog of services from the SN.

[0166] At sixteen 1532, the WTRU may send a Request message for obtaining the catalog of services from the SN, for example, if the WTRU determined to request the catalog (e.g., at fifteen 1530).

[0167] At eighteen 1536, the SN may send (e.g., offer) one or more catalogs of services to the WTRU, for example, if the SN determined that a catalog has been requested by the WTRU (e.g., in eight 1516), or if there was no match for the first requested SDDR. [0168] At seventeen 1534, the WTRU may select the second SDDR from based on the catalog, for example, based on the one or more catalog services offered by the SN.

[0169] At nineteen 1538, if a second SDDR has been selected by the WTRU, an SDDR request may be sent by the WTRU (e.g., a request that includes the second SDDR) to the SN. The second SDDR may have been selected by the WTRU using the SDDo (e.g., in fourteen 1528) and/or using the catalog (e.g., at seventeen 1534). The second SDDR may indicate QoS and security requirement(s) that differ from the first SDDR.

[0170] A WTRU may negotiate for a slice based on its current SDD request and/or the network may take into consideration the WTRU/Subscriber's profile with the current SDD request sent by the WTRU. An Application Service Provider (ASP) may perform (e.g., may alternatively perform) the negotiations on behalf of the WTRU with the SN. In some cases, both the WTRU and the application service provider may negotiate (e.g., jointly) with the SN for requesting a service and/or a slice, for example, based on QCI and/or service requirements.

[0171] A slice assignment may be performed based on a WTRU/Subscriber Profile.

[0172] FIG. 16 depicts an example slice assignment based on a WTRU/Subscriber Profile. For example, the network may use the WTRU/Subscriber's profile with the SDD, for example, to assign a slice (e.g., a consistent slice). A consistent slice may be assigned to the WTRU using the subscriber's information in the Subscription Profile Repository (SPR), (e.g., subscriber's allowed services, subscriber category, subscriber's charging related information, etc.). The flow in FIG. 16 may illustrate the network assigning a slice to a subscriber based on the subscriber's profile.

[0173] At zero 1610, a WTRU 1602 may attach to a SN 1606, for example, using a default slice. The WTRU 1602 may have been identified and/or authenticated as part of the attachment process with the default slice.

[0174] At one 1612, the WTRU 1602 may request a slice by sending a SDD _R = NULL, and/or a WTRU-Id to a Slice Determination Function (SDF) 1604. The SDF 1604 may be co- hosted with a VNF and/or may be implemented as a VNF. The WTRU 1602 may send a subscriber identifier (e.g., EVISI) to the SDF 1604. The subscriber identifier may or may not be associated with an MNO. The subscriber identifier may be associated with a third-party Identity Provider (e.g., OTT provider, such as Google and/or a Gmail id may be used, e.g., instead of the IMSI). [0175] At two 1614, The SDF 1604 may send a request to a Subscriber Profile Database (SPD) 1608 to obtain and/or access a subscriber profile associated with the WTRU 1602 and/or IMSI stored in the SPD 1608, for example, if the WTRU 1602 had provided an IMSI.

[0176] At three 1616, the SPD 1608 may send the subscriber profile that was requested by the SDF 1604, for example, if the request from the SDF 1604 has been authenticated and/or if the SDF 1604 has been authorized. The SPD 1608 may send a slice-id (e.g., NSSAI) that identifies (e.g., uniquely identifies) the slice that the WTRU 1602 and/or application that the WTRU is hosting is authorized to attach to.

[0177] At four 1618, the SDF 1604 may check to see if the WTRU 1602 and/or Subscriber has been authorized to perform such a request (e.g., slice request), for example, based upon the information obtained from the subscriber profile.

[0178] At five 1620, the SDF 1604 may communicate with a Slice Database 1601 and/or obtain the information pertaining to the slice that the WTRU 1602 and/or Subscriber is authorized to attach to, for example, if the WTRU 1602 and/or Subscriber has been authorized. The SDF 1604 may obtain a Risk-metric associated with that slice, the Slice-Id, Slice- Attachment-Point-URI, and/or Policies from a Slice Database 1601.

[0179] At six 1622, the SDF 1604 and/or an Authentication/ Authorization/Assessment server may perform a risk-based assessment of the WTRU 1602 and/or the Subscriber. The risk-based assessment may involve one or more of authentication (e.g., involving one or more factors), device attestation, and/or the assessment of the security level of the WTRU 1602 and/or

Subscriber. Assertions about the various authentication, verification, and/or authorizations may be combined and/or assessed at the SDF 1604.

[0180] At seven 1624, the SDF 1604 may assign the slice to the WTRU 1602 and/or Subscriber, for example, if the assessments were successfully completed and/or if the

assessments match or exceed the risk appetite associated with the slice.

[0181] At eight 1626, the SDF 1604 may send details about the slice. The details may include the Slice-Id, Slice- Attachment-Point-URI, Policies, etc. The SDF 1604 may send the details to the WTRU 1602 via a Slice Response message. The SDF 1604 may send one or more policies associated with the slice and/or slice access to the WTRU 1602. The WTRU 1602 may store the information (e.g., all the information) that was provided to it by the SDF 1604 and may use the information to attach to a slice. [0182] Slice Negotiation and Attachment may be performed based on a Slice Request. A slice negotiation and/or assignment may be based on a Slice Request that includes a non-null SDD. A slice negotiation and/or assignment based on a slice request that includes a non-null SDD may include one or more of the following: Slice Negotiation, a Slice Assignment, and/or a Slice Attachment/ Authorization. In Slice Negotiation, a WTRU and/or a SN may negotiate one or more slices (e.g., appropriate slice(s)) for attachment. In Slice Assignment, the SN may authorize attachment to one or more slice(s). Slice Attachment/ Authorization may be the process by which the WTRU is authorized to attach to the one or more slice(s).

[0183] FIG. 17 depicts an example of slice selection 1700.

[0184] At zero 1712, the WTRU 1702 may attach to the SN 1706, for example, using a default slice and similar processes (e.g., authentication and authorization) described herein that may be carried out between the WTRU 1702 and the SN 1706.

[0185] At one 1714, the WTRU 1702 may request a slice by sending a SDDR and/or a WTRU-Id to a SDF 1704. The WTRU 1702 may send a subscriber identifier (e.g., IMSI).

[0186] At two 1716, the SDF 1704 may send a request to obtain and/or access the subscriber profile associated with WTRU 1702 and/or IMSI stored in a SPD 1710, for example, if the WTRU 1702 had provided an FMSI.

[0187] At three 1718, the SPD 1710 may send, to the SDF 1704, the subscriber profile that was requested, for example, if the request from the SDF 1704 has been authenticated and/or if the SDF 1704 has been authorized. The SPD 1710 may send a slice-id that identifies (e.g., uniquely identifies) the slice that the WTRU 1702 and/or application is authorized to attach to. The SDF 1704 may also send a request to the SPD 1710 for obtaining information about the Slice-Id. The SPD 1710 may be assumed to store information about Slice-Id and/or some other network function may store information about the slice IDs.

[0188] At four 1720, the SDF 1704 may check to see if the WTRU 1702 and/or Subscriber has been authorized to perform a request (e.g., a slice request), based upon the information obtained from the subscriber profile.

[0189] At five 1722, the SDF 1704 may communicate with a Slice Database 1701 and/or obtain an offered SDD (SDD ₀ ) that may match (e.g., closely match) the SDDR, for example, if the WTRU 1702 and/or Subscriber has been authorized. The SDD ₀ may include and/or have an indirect link (e.g., URI, URL, IP address) to a catalog that includes the offered list of SDD (e.g., a complete list of SDDo.) The SDF 1704 may compare the SDDR to the SDDo. The SDF 1704 may determine if there is a match (e.g., an exact match) between the SDDR and an SDDo in the catalog. If there is a match (e.g., an exact match) then the SDF 1704 may obtain a Risk-metric that may be associated with the SDDo, the Slice-Id(s), Slice- Attachment-Point-URI(s), and/or associated Policies). If there is a match between the SDDR and an SDDo in the catalog, then the process jumps to ten 1732 to perform a risk-based assessment of the WTRU 1702.

[0190] At six 1724, the SDF 1704 may send a slice response message to the WTRU 1702. The slice response message may include the SDDo, for example, in case if the SDDR does not match the SDDo. As described herein, the SDDo may be a catalog (e.g., an entire catalog) of the SDD. The SDDo may include information (e.g., miscellaneous information) that may enable the WTRU 1702 to make a decision (e.g., a proper decision) on selection of an SDD. Examples of miscellaneous information may include risk metric information associated with each of the SDD within the SDDo, cost associated with each SDD, etc.

[0191] At seven 1726, the WTRU 1702 may select an appropriate SDD (e.g., a second SDDR) from the SDDo based on various criteria that may include requirements associated with the application that is intending to use the slice. The WTRU 1702 may terminate the slice selection 1700, for example, if one or more of the SDDs within the SDDo does not match the requirements associated with application and/or WTRU 1702.

[0192] At eight 1728, the WTRU 1702 may send, to the SDF 1704, a second (e.g., a new) slice request message that may include the second SDDR selected in seven 1726.

[0193] At nine 1730, the SDF 1704 may determine if the second SDDR is one or more of the SDDs within the SDDo and/or if the second SDDR is the complete SDDo. If so, the SDF 1704 may assess the risk associated with the second SDDR. If the second SDDR is not an SDD within the SDDo, the SDF 1704 may reject the slice request and/or initiate a negotiation by performing (e.g., initially performing) a comparison (e.g., such as at five 1722) and/or sending a slice response message (e.g., as in six 1724) that includes a second SDDo that may match the second

[0194] At ten 1732, the SDF 1704 and/or an Authentication / Authorization / Assessment server may perform one or more authentications, authorization checks and/or assessments of the WTRU 1702 and/or the Subscriber, as described herein. [0195] At eleven 1734, the SDF 1704 may assign a slice to the WTRU 1702 and/or

Subscriber, for example, if the assessment is carried out (e.g., carried out successfully).

[0196] At twelve 1736, the SDF 1704 may send, to the WTRU 1702, one or more details about the slice. The details may include one or more of the Slice-Id(s), Slice-Attachment-Point (SAP) (e.g., URI(s), IP address, etc.), Policies, etc. The SDF 1704 may send one or more details about the slice assigned in eleven 1734 to the WTRU 1702, for example, in a slice response message. The WTRU 1702 may store the details sent by the SDF.

[0197] At thirteen 1738, the WTRU 1702 may send a slice request message. The slice request message may include an "acceptance" indication to the SDF 1704. The acceptance indication may be an accept information element. The slice accept message may be in response to the slice response message received from the SDF and may be sent within a slice request message, for example, if the slice(s) assigned to the WTRU 1702 is/are acceptable to the WTRU 1702.

[0198] At fourteen 1740, the SDF 1704 and/or a Token Authority Function and/or an Authorization Server Function may generate and/or send one or more Access Token(s) (e.g., Slice- Access-Token) to the WTRU 1702, for example, in a secure manner. Fourteen 1740 may be performed as part of twelve 1736. If this message fourteen 1740 was performed as part of twelve 1736 then thirteen 1738 may be skipped.

[0199] At fifteen 1742, the WTRU 1702 and/or the SAP 1708 may set up a secure communications channel between one another, for example, using the Slice- Attachment-Point (SAP) information provided to the WTRU 1702 by the SDF 1704. The secure communications channel may be enabled by means of TLS, DTLS, IPSec, EAP, and/or by one or more other means. The secure communications channel may depend upon the layer (OSI layer) where the attachment occurs.

[0200] At sixteen 1744, the WTRU 1702 may send a Slice Attachment Request that includes one or more of the Slice-Id(s), the WTRU-Id, Slice-Access-Token(s), and/or an Application-Id(s) to the SAP(s) 1708.

[0201] At seventeen 1746, the SAP(s) 1708 may verify the Slice-Access-Token(s) and/or generate WTRU-specific policies, security credentials, and/or keying material.

[0202] At eighteen 1748, the SAPs 1708 may send to the WTRU 1702 a Slice Attachment Response message that includes, for example, the policies, keying material, and/or slice details. [0203] On receiving eighteen 1748, at nineteen 1750, the WTRU 1702 may store the policies, keying material, and/or the slice details for future use.

[0204] The authorization (e.g., Slice "Authorization and Attachment") may be carried out using a token-based mechanism (e.g., using a push/pull model) and/or by messaging (e.g., explicit messaging) between the SDF 1704 and/or the SAP 1708. The use of a token is an example for conveying the authorization information between the SDF 1704 and/or the SAP 1708.

[0205] The Slice Selection described herein may be used when a WTRU requests services offered by a 5G network (5 ^th Generation cellular network such as those provided by MNOs such as AT&T or Vodafone), and/or Wireless LAN network providers, Network-access provided by an MVNO, and/or Application Service Providers (e.g., Over-The-Top provider such as Google or Facebook), etc.

[0206] FIG. 18 depicts an example slice assignment based on Application Service Provider (ASP) driven service requirements. In an example, an ASP responsible for serving an application (e.g., client) may be responsible for negotiating the service requirements with an SN. The role of the WTRU may be minimal in this scenario and/or may contrast with the illustration and/or associated description for Figure 15. The negotiations may be handled by an ASP (e.g., on behalf of the WTRU and/or application running on the WTRU).

[0207] Prior to triggering (e.g., activating) an application on the WTRU, the WTRU may have performed an attach procedure with an SN. The WTRU may have been identified, authenticated, and/or authorized to connect to a default slice or to the SN Functional block that is common to most (e.g., all) slices served by the SN, e.g., as part of the attach procedure. The attach procedure may have been carried out by using legacy (e.g., 4G and older) and/or 5G mechanisms. The WTRU may be provided with access to default slice(s), e.g., when the attach procedure has been completed.

[0208] At one 1802, a user may trigger launching (e.g., activate) an application (App) in the WTRU. For example, the user may trigger launching an application by clicking an icon on the WTRU that is associated with the application, by using voice commands, and/or the like. As another example, the application may be triggered without a user, for example, based on policies associated with the application on the WTRU. When the App is launched, the App may set up a connection with an Application Service Provider (ASP) (e.g., an associated ASP) using the default slice.

[0209] At two 1804, the User may be authenticated by the ASP and vice-versa, for example, by using mutual authentication mechanisms (e.g., such as user name / password, FIDO, federated authentication, biometric / multi-factor authentication, etc.).

[0210] At three 1806, a message (e.g., a message that includes a request for attachment to a slice with a particular SDD) may be sent to the Serving Network (SN). The request may be sent by the WTRU to the SN and/or the ASP may send the request on behalf of the WTRU/user. The request may (e.g., may only) be sent by the ASP if the authentication (e.g., performed in Step two) is successful. The Request may include a Requested SDD (SDDR). The SDDR may include an SDD (e.g., S-NSSAI) and/or a plurality (e.g., an array of SDDR, NSSAI) of SDDs and/or may not include an SDD (e.g., may not include an SDD at all, also referred to as SDDR = NULL). The SN may determine if an SDDR is present in the request message and/or may prepare an offered SDDo. The SN may return an SDDo to the ASP, for example, based on the request.

[0211] At four 1808, the ASP may determine if there is a match (e.g., an exact match) between the SDDR and the SDDo. As described herein, the message may include a request for a plurality of SDDs within its SDDR and/or may be matched with a list (e.g., a complete list) of SDDos.

[0212] At five 1810, the ASP may determine whether there is a match (e.g., an exact match) between the SDDR and the SDDo. The ASP may determine that the SDDo is a match for the SDDR when the SDDo is configured (e.g., tailored, pre-configured, etc.) for the application associated with the SDDR. The SDDo may be configured (e.g., tailored, pre-configured, etc.) for the application when it indicates the application and includes QoS and/or security requirement s) associated with the application. The ASP may determine that the SDDo is not a match for the SDDR when the SDDo is not configured (e.g., tailored, pre-configured, etc.) for the application associated with the SDDR. If there is a match, then the flow may move to twelve 1824.

[0213] At six 1812, if there is no match (e.g., no exact match) between the SDDR and the SDDo, the ASP may determine if the SDDo provided is acceptable for the service request despite not being an exact match (e.g., a preconfigured/predetermined match). The ASP may determine that the SDDo may be acceptable for (e.g., satisfies) the SDDR when the SDDo includes QoS and security requirement(s) that meet or exceed the QoS and security requirement(s) indicated by the SDDR. If the SDDo provided is acceptable, the flow may move to twelve 1824.

[0214] At seven 1814, if the ASP makes a determination that the SDDo is not acceptable (e.g., not a good fit) and/or would like to modify the request (e.g., the existing Request), a modification may be carried out. A second (e.g., new) request message may be sent (e.g., sent back) to the SN.

[0215] At eight 1816, the ASP may request for a tailored SDDR, for example, if the ASP determines not to make a new request (e.g., a new request including a modified SDDR). The

ASP may indicate to the SN that the ASP may desire a tailored SDD based upon the earlier requested SDDR and/or a modification of the earlier requested SDDR and/or SDDo.

[0216] At nine 1818, if the ASP determines not to request a tailored SDD, the SN may send a service request denial message to the ASP and/or the WTRU.

[0217] At ten 1820, the example slice assignment 1800 may end.

[0218] At eleven 1822, if an SDDR was not present in the request message and/or if the

WTRU was deemed to be a legacy device, the SN may fetch the SDDR from the WTRU/

Subscriber Profile (SProf) 1832 associated with the WTRU. The SProf may be stored at the ASP and/or the WTRU.

[0219] At twelve 1824, an SDD (e.g., each SDD) may be assessed for risk and/or a

WTRU/subscriber may be authenticated (e.g., further authenticated), for example, based on the risk posed by the WTRU/Subscriber to the NS. The higher the impact when an NS is compromised, the stronger the authentication and/or authorization used for the

WTRU/Subscriber. A platform attestation may be carried out, for example, in addition to device authentication. A platform attestation may be carried out if the risk is deemed to be higher. A multi-factor authentication of the user may be carried out. Authorization checks and/or authentication of WTRU may be performed to match risk aligned with providing a requested

[0220] At thirteen 1826, the SN may assign one or more slices to the WTRU, e.g., based upon the SDDR. The SN may send a confirmation to the ASP and/or the WTRU that may include the details of the assigned one or more slices. The flow may move to ten 1820 and/or may conclude. [0221] At fourteen 1828, the ASP may select a second (e.g., new) SDDR from the offered SDDo, for example, if the ASP determines that the SDD Request should be modified (e.g., at seven 1814). The ASP may generate a response message (e.g., a new Request message) that may include the second SDDR (e.g., the new SDDR). The flow may move to four 1808.

[0222] At fifteen 1830, the SN may request that the ASP and/or the WTRU request for privileges (e.g., additional privileges, such as buying a new subscription and/or payment) that may match the SDDR, for example, if the ASP had requested for a tailored slice (e.g., in eight 1816). The flow may move to four 1808.

[0223] An SCEF may enable network service discovery and/or slice selection by an application service provider. The SCEF may be used to expose the catalog of available slices and/or the slice capabilities to WTRUs and/or to 3 ^rd party entities. The 3 ^rd party entities may be interested in providing a service, leasing a NS, and/or leasing parts of a NS (e.g., the RAN and/or Core Network in conjunction with their own service counterpart). A 5G network may allow for a 3 ^rd party service (and/or WTRU using it) to perform discovery and/or selection of the slice that may be the best fit for its Security Level and/or other QoS parameters for a particular service. The SCEF, for example, in conjunction with an SDD, may enable an application service provider to describe a desired service characteristic for a tailored NS. The tailored NS may meet one or more specific services that the application service provider may provide.

[0224] FIG. 19 illustrates an architecture for slice selection 1900 through a network exposure API (e.g., a SCEF). An application service provider servicing a WTRU may send a request (e.g., a connectivity service discovery request) to the network via the API by specifying one or more specific QCI and/or security requirements. The request may be triggered when a user and/or subscriber initiates an app on a WTRU. The QCI and/or security requirements may be indicated by an SDD as described herein. The SDD may be provided by the WTRU to the network or by the application server on the network side via the SCEF API. The QCI and/or Security requirements may be represented by a service flow identifier, a label, and/or a tag which may be interpreted into more details requirements by for example, reference tables and parameters. The requirements may have a compact form and/or may be represented using quantitative and/or qualitative values (e.g., 1 (Very Low) - 5 (Very High)). The detailed QCI and/or Security requirements may have an elaborate form and/or may be formulated to provide detailed requirements, similar to those shown in FIG. 11 Table 1. Detailed information for one or more of the "confidentiality and integrity", "user privacy", "authentication protocol", "authentication complexity," and/or "authorization" mechanisms may also be provided.

[0225] The network exposure layer may authorize the application request and/or may forward the application request to an orchestration system.

[0226] The orchestration system may map the application QoS and/or Security requirements to an internal representation and/or lookup in Network Service Catalog/Record (ETSI terminology) for the best slice which matches the desired criteria.

[0227] The network exposure may send back a response message (e.g., a positive response message) and/or a network slice reference (e.g., a list of S-NSSAIs with supported QoS/Security levels to the application), for example, if an existing running slice match is found. For example, a lower QoS may be accepted and/or refused by the application. Negotiations as described herein may be performed. Non-real-time slice creation may take place in the background based on demand for a particular NS configuration (e.g., assuming the MNO provides that capability).

[0228] The application may send a binding request via the API to indicate that it will be using that particular slice.

[0229] After authorization and/or application service provider policy checks, the

orchestration system may record the application as a user of the slice in a Network Service Record (NSR) for billing and/or lifecycle management and/or may send back a confirmation to the application.

[0230] Operations may be performed in the context of that slice and may be dispatched through a central entity (e.g., central PCRF to the slice's PCRF).

[0231] The slice selection 1900 through a network exposure API may be separated into two parts, which may be used in tandem. A first part of the slice selection 1900 may not be performed, for example, if the operator has a slice with the required characteristics and/or capacity already available. In the first part a slice may be created and/or modified to

accommodate the requirements using one or more of the following.

[0232] The service provider and/or Application Service Provider (ASP) may request the establishment and/or modification of a slice. The request may be prompted by conditions (e.g., a variety of conditions), that may include WTRU communications with the ASP, demand in a region, etc. The request may be made via an API with the SCEF-like function.

[0233] The orchestration system may create and/or manage the slice as negotiated. [0234] The network (e.g., the AMF, the NSSF, or the RF) may create a slice identifier. The network may assign the slice identifier, for example, using the slice determination function which may be part of a network orchestration, configuration, provisioning and management entity.

[0235] The slice selection 1900 through a network exposure API may be used for roaming NWs, for example, if the compatibility and inter-operability between the visited SCEF and the home SCEF is common.

[0236] In the second part of the slice selection 1900, the ASP may request usage of a specific slice for the WTRU. The ASP may request usage of the specific slice for the WTRU using one of several ways. The user identity may be known to the ASP / ISP (e.g. full name as used by some applications) and may be kept hidden from the MNO. Alternatively, the subscriber identity (e.g., IMSI, MS-ISDN, etc.) may be hidden from the ASP. The request may leave a non- reputable paper trail.

[0237] In an example, the WTRU may receive from a NW function a temporary WTRU identifier. The temporary WTRU identifier may be single use, short term, long term, and/or may be updated and/or replaced as often as desired. The WTRU may send its WTRU identifier, a slice identifier, and/or a description of the desired service to the ASP. The WTRU may require access through a "default" slice, for example, because the WTRU may not be consuming any services or may not currently have access to the desired slice. The ASP may return the WTRU identifier to the NW function which may have issued it or which may be able to identify the user or WTRU, together with the slice identifier, for example, if the ASP agrees to the use of the slice (e.g., if the user/WTRU is recognized by the ASP and/or the requested service warrants use of the slice).

[0238] An example WTRU identifier generation may be carried out in the following manner: WTRU_Slicel_tempid = KDF (KASME, IMSI ||Slice-Id_l || secure_connection_parameters). Note that while KASME may be used in EPS, an analogous root key may be used in 5G Systems. The WTRU temp id may uniquely identify the identity of the WTRU associated with a particular Slice (e.g., as identified by a Slice-Id). The secure_connection_parameters may be parameters that are known (e.g., only known) to the WTRU and the SN when they have established a secure connection (e.g., by means of TLS / DTLS, IKE / IPSEC or EAP protocol). The inclusion of secure connection parameters in the WTRU identifier may be optional, for example, in case of the existence of a valid KASME. In cases where a WTRU may not have been authenticated by the network, the KASME may not be included, for example, since there is either no valid and non- expired KASME nor does a KASME exists since no authentication has occurred. In such cases, the KASME may be replaced by a master key or a derivative of the master key associated with the secure connection (e.g., TLS Master Key or derivative of the TLS Master Key). Examples of secure_connection_parameters may be tlsdata, tls master secret, challenge nonces etc. in the case where TLS / SSL or DTLS was used to create a secure connection. An example Key Derivation Function (KDF) may be HMAC-SHA-256. When the same WTRU had obtained access to another slice, a temporary id generated and used by the WTRU may be different and may be derived in as follows: WTRU_Slice2_tempid = KDF (KASME, IMSI || Slice-Id_2 ||

secure_connection_parameters). The temporary ids used by the WTRU for different slices may be significantly different provided the correct set of KDFs are used in the generation and/or the set of KDFs are unique to each of the slices associated with a single user. Each of the temporary id(s) may have a unique expiration time. The expiration time for a temporary id may be associated with the length of time that the WTRU has been authorized for providing access to that particular slice. The temporary ids may be derived using different

secure connection parameters, for example, since they may have been derived when the WTRU requested access to a slice by means of a different secure connection and possibly at a different date and/or time.

[0239] The same secure connection parameters may be used to generate the temporary ids for the different slices, for example, if a request to access one or more services and/or slices is performed using the same secure connection (e.g., TLS). The temporary ids may be different for each slice since the Slice-Id provides the required variability to the generated temporary ids. A key that is used may have been derived out of an authentication between the WTRU and the Network by means of e.g. an LTE Authentication and Key Agreement (AKA) process. In some cases, the key (e.g., credential) may be the KASME or a Master Session Key (MSK) that may be generated by means of an EAP authentication process. In other cases, the key may be any root key that is generated as part of a 5G authentication process (e.g., KSEAF). Any session key that is generated by the WTRU and/or the SN may be used in the generation of the WTRU Slice- Id tempid(s). [0240] An ASP may generate the tempid(s) as described herein for the network, except that the session key between the ASP and the SN may be used to generate the tempid(s). When the ASP generates the tempid(s), the secure connection parameters may be associated with the secure connection between the ASP and SN (e.g., tlsdata for the TLS connection between the ASP and the SN). The above described WTRU temporary identifier (e.g. WTRU Slicel tempid) generation may be performed by the WTRU and the Network independently on their own. When an ASP requests an SDD on behalf of a WTRU, similar mechanisms to those used by the WTRU and/or the Network may be used with some modifications, wherein, the KASME or KSEAF, which may not be available to the ASP are not used in the generation of the tempids. The Slice-Id information may be assumed to be available apriori to the WTRU or ASP, for example, using a pre-provisioning process by the network, obtained by the WTRU or ASP using an external database hosted outside the network, or provided as part of the SDD negotiation process by the network to the WTRU or ASP.

[0241] The ASP may request a batch of WTRU identifiers, which the ASP may dispense to WTRUs that it agrees to connect through slice. In an example, another Network Operator may initiate a process (e.g., a similar two-step process) of slice creation/selection via the same SCEF like API and/or more directly through a dedicated Interworking function (e.g., with adequate trust level) capable of interfacing with the Slice Management system.

Table 1: QCI with Security Values

[0242] A slice capability selection principle may apply. For example, the slice capability selection principle may apply regardless of the network slice implementation as chaining (e.g., chaining only) Virtual Network Functions and/or dedicated network functions. Slices and/or QoS/Security capabilities may be catalogued in a repository (e.g., central repository).

[0243] When a WTRU attaches (e.g., initially attaches) to a network, the WTRU may attach (e.g., attempt to attach) to one or more NS(s) from which it may wish to request services. Such NS and/or NSs may include such services and/or may be supported by the Serving Network (SN). The SN may communicate with the WTRU to determine the type(s) of services and/or to provide the services through selected slice(s), e.g., in order for the SN to deliver such services. Such awareness may be achievable (e.g., relatively easy to achieve) for a home network, for example, by pre-provisioning slices required by means of the WTRU Subscriber Profile (e.g., provisioning a list of supported slices in the ME or UICC). In a roaming scenario and/or during an ongoing session (e.g., when a service is added), it may not be feasible to rely on pre- provisioned information in the serving network. In a roaming scenario, for example, the home network may not control and/or predict which serving network the roaming WTRU may attempt to attach, and/or slices realized in the home network may be different from slices realized in the serving network and/or may not exist.

[0244] Infrastructure security information may be used as a parameter for the SDD.

[0245] Telecommunication networks may depend upon conventional protection mechanisms to protect against what may be vulnerabilities (e.g., common vulnerabilities) in IT systems. The closed (e.g., proprietary) nature of network devices, their fairly static design, and/or the homogeneity of software may represent defenses against threats (e.g., common threats).

Perimeter defenses (e.g., physical isolation and/or protection, Firewalls, IPS/IDS, DMZs, dedicated communications links, and/or VPNs) may protect a network infrastructure from threats (e.g., external threats) and practices (e.g., best practices) for dealing with threats (e.g., internal threats) may provide protection. The systems (e.g., existing systems) may be under the control of the operator and/or may appear as a black box from the outside (e.g., as far as security is concerned).

[0246] With the deployment of 5G networks, an operator may lose physical control of the parts of the network infrastructure and/or may rely on infrastructure service providers (e.g., IaaS, PaaS, NFVI providers) to provide security based on one or more SLAs (e.g., agreed SLAs). The infrastmcture service providers may support one or more operators that may use an infrastructure (e.g., the same infrastructure) and may be able to assure that the agreed SLAs are being provided to one or more operators (e.g., each of the operators individually). Due to the deployment of business models (e.g., new business models, such as leasing infra-structure from a large number of potential providers, highly diffused geographic placement of equipment), and technologies (e.g., COTS platforms, Network Function Virtualization Infrastructure (NFVI), and Software Defined Networking (SDN)), the operator may rely (e.g., may have to rely) on new trust models.

[0247] Information on the level of security (e.g., for the various network functions that may make up a Slice and/or for the entire network itself) may be provided, for example, since the diversity of deployments and/or business case scenarios in 5G may introduce variability in terms of the infrastructure components. A parameter may be added for one or more (e.g., each) of the services included in the SDD for a requested service. The parameter may be used to assign a network infrastructure security (NIS) level. The NIS level may be interpreted as the minimum acceptable level of security for one or more (e.g., each) of the functions in a network and may be used to route traffic through the network, for example, through trusted and secure infra-structure.

[0248] The network may use mappings between slices to an appropriate path and/or appropriate functions when routing communications.

[0249] The network may translate a Slice and/or an SDD associated with a NS into an SFC, for example, after the network assigns the slice to the user. There may be one or more SFCs that may satisfy a Slice requirement. An SFC may be a chain of NFs that may be needed to be executed for a certain service request, for example, so that the network can meet the service requirements. The network management function may translate an SDD from a WTRU and/or application and/or may assign a slice (e.g., an appropriate slice). The network may determine the SFC, for example, based on the slice information. There may be one or more SFCs that may satisfy a slice requirement. For example, an SFC may be a chain of user plane functions comprising one or more VNFs. The SFC may be applied (e.g., separately applied) to control plane functions, such as handover signaling, authentication signaling, mobility management, etc. The QCI and/or the security level may be input parameters, e.g., when determining the exact VNF instances to be included in a specific SFC.

[0250] A classifier located at the ingress (e.g., an ingress router / switch / server) of the network may classify the SFC, for example, to pre-determine the full service function path (SFP) of the flow. In a static model, the classifier may be part of the MANO and/or may establish (e.g., help establish) a connectivity path through the network.

[0251] In a dynamic SFC deployment, the classifiers may be placed at the network's ingress point and/or the classifiers may be placed throughout the network. When the classifiers are placed at the network's ingress point and/or throughout the network, reclassification of the SFC (e.g., if any V F is congested), V F failure, and/or path failure may be enabled. Re-classifying the SFC may include the insertion, removal, and/or replacement of VNF within the SFC (e.g., redefine and re-route the pre-determined path).

[0252] In a hybrid model, the static and/or the dynamic models may be used. For example, if some parts of the network are designated to be secure (e.g., highly secure), a fixed static predetermined SFP may be used for routing the packets. Dynamic SFPs may be used for other parts of the network, where security may be slightly relaxed. VNFs which may be considered critical for security of the network (e.g., high security) may include the HSS and/or the AAA, which may be made immune (e.g., need to be immune) to one or more risks of compromise and/or may be provided as part of a static SFP, for example, in order to minimize risks to the WTRU and the HSS/AAA.

[0253] An SFP may be determined based on the SFC.

[0254] For example, a logical SFC may be mapped to a physical SFP using a static SFC mapping a dynamic SFC mapping, and/or a hybrid mapping. A static SFC mapping may be topology-dependent (e.g., such that an ingress classifier may be placed at the network entrance to classify the SFC accompanied with the received packet and/or may define the full consistent physical path, such as static SFC deployment model). This type of service function deployment model (e.g., mapping of a logical SFC to a physical SFP) may be static and/or may be bound to a fixed topology. They may not adapt (e.g., adapt well) to elastic service environments enabled by virtualization. A topology-independent approach may enable deploying the classifiers more flexibly across a network (e.g., dynamic SFC and/or hybrid deployment models).

[0255] A SFP may be determined relatively statically from the SFC.

[0256] FIG. 20 depicts example Static and Dynamic SFC deployments 2000. In a Static SFC deployment, a full end-to-end network path may be predetermined at the ingress classifier and/or may not be modified and/or adapted as shown in FIG. 20. A static route may be predetermined at the classifier and may not be modified afterwards (e.g., even if one of the VNFs may be congested, VNF failure, link failure, and/or compromised VNF). A packet that is classified using a static path may traverse the following sequence of functions: classifier A→ V F1→ VNF2a→ VNF3a→ VNF4a→ VNF5→ VNFn. The V Fs beyond the classifier may not have a capability to re-classify an SFP (e.g., an established SFP). In this static model, network service deployments may be coupled to network topology. Such a statically established dependency may impose constraints on service delivery, may inhibit the network operator from optimally utilizing service resources, and/or may reduce flexibility. Topology information may be stored in databases for mapping SFCs to physical paths. The configuration may be performed through SDN controllers.

[0257] In a static configuration model, the configuration and SFP may be facilitated through the use of intelligence (e.g., in the form of NSH included within a packet).

[0258] Dynamic SFP Determination from the SFC may be used.

[0259] In a Dynamic SFC deployment, the SFC may be classified and/or reclassified at instances throughout the network according to the network status (e.g., VNF congestion and/or failure, a link failure, etc.). The Dynamic SFC deployment may be attractive for 5G systems, for example, because static topology information may be less viable due to scaling, tenancy, and/or complexity reasons. As shown in FIG. 20 (e.g., the dynamic SFC deployment), classifiers (e.g., A, VNF3a) may be placed throughout the network to remap some of the SFCs in case one or more of the SFPs are no longer consistent with the QCI of the provisioned slice. For example, if VNF2b and/or VNF4a are degraded (e.g. due to congestion and/or security), the classifier A and/or VNF3a (e.g., that may have a reclassification capability), may re-route packets using a route (e.g., a newer route). A packet may be routed (e.g., may then be routed) using the path (e.g., the newer path) that may traverse the following sequence of functions: classifier A→ VNFl→ VNF2b→ VNF3a→ VNF4b→ VNF5→VNFn.

[0260] As described herein, the NIS may be described as a (e.g., another) service

requirement in 5G networks. An approach to impose NIS as an additional service requirement may be provided. For example, Infrastructure security may be used as another QCI metric. The NIS security level values may be susceptible to change over time, for example, due to attacks, lack of resiliency, and/or another vulnerability. The security level values of such infrastructure entities may be updated (e.g., dynamically updated) over time, for example, to maintain network integrity. Updating the security level values may result in a change in the SFC-physical topology mapping (e.g., redirect flows to alternative routes), for example, due to some network conditions.

[0261] Hop-by-hop QCI may be utilized for routing. Hop-by-hop QCI may enable the network flow to be classified hop-by-hop (e.g., at each switch/entity) to route through the best next hop according to the QCI requirements of the flow (including NIS requirements). For example, instead of preselecting the full path that meets the QCI requirements for the network flow as claimed by a static SFP, the hop-by-hop QCI may enable the network flow to be classified hop-by-hop to route through the best next hop according to the QCI requirements of the flow. This can be attained by placing a number of SFC classifiers through the network.

[0262] FIG. 21 depicts an example Dynamic SFC Determination 2100. In a hop-by-hop QCI solution, an SDN-based network at both the RAN and the Core networks may be assumed, as shown in FIG. 21. An SFC classifier switch may be deployed at the entrance of the Core. The SFC classifier may allocate the full network path that may correspond to the SFC accompanied with the network flow as shown by the thick curvy line. One or more open switches may function as Service Function Forwarders (SFFs). A classifier may have the privilege to update the SFC (e.g., insert and/or remove some functions from the chain).

[0263] Multiple classifiers may exist throughout the SFC path (not only at the entrance of the network) to help update the SFC (insert/remove service functions). The SFFs may forward (e.g., can only forward) the flows (e.g., packets) based on the destination that corresponds to the executing SFC that was predetermined by a former classifier, for example, unlike the classifier. The SFF may lack control to modify the SFC accompanied with the flow. The classifier may alter the SFC, for example, based on the availability of network nodes. The dynamic SFC determination 2100 may include a back-up route for the full network path, for example, if switch A is down. If the next hop is an SFC-unaware service function, the flow may go through an SFC proxy, for example, before being forwarded to a network function.

[0264] Some switches may not be configured to operate as a classifier. For example, classification-capable switches may be strategically placed throughout the network such that the resiliency of the network is assured while minimizing deployment costs. Strategically placing classification-capable switches may provide flexibility in allocating service resources and/or more robust SFPs.

[0265] Routing may be performed via an assigned SFP. [0266] For static path navigation, packets and/or datagrams that originate from a WTRU for a particular application with an associated SDD and for which the SFC and associated SFP have been determined may be routed using routing information/intelligence within the network (e.g. configuration of the SDN controllers). For static path navigation, packets and/or datagrams that originate from a WTRU for a particular application with an associated SDD and for which the SFC and associated SFP have been determined may be routed using routing information incorporated in the packets emanating from the WTRU. In a dynamic routing scenario, the routing information may be provided as high level information attributes (example's., QCI levels as described herein) within the packets and/or datagrams. The two static and dynamic modes and/or a hybrid mode of packet/datagram routing may be considered.

[0267] Routing through an assigned SFP may be performed using a preconfigured static path.

[0268] For example, a classifier may read the packet header to determine a full SFP. The SFC may be classified and/or mapped to an SFP and/or the network path may be determined and/or setup as intelligence in the network. For example, the SDN controllers may be provided with the pre-determined path information that may be used by the SDN controllers to configure the switches and/or routers. The path may not be reclassified.

[0269] Routing through an assigned SFP may be performed using a static path defined within a packet.

[0270] When a Static Path is Defined within Packet, the packet and/or datagram emanating from the application in the WTRU may play a vital role in its routing. Some information may be added to the packet's header to indicate the construction of the SFP, for example, to enable flexibility and/or dynamic function selection for the SFC deployment. The classifier may read the packet header information to determine the full SFP and may construct header information for the packet. This functionality may be included into some of the currently used L2/L3 network protocols (e.g., source-routing headers). An enhancement of the IETF defined NSH may be used, for example, in order to achieve this QCI based routing. As the packet traverses through the network, each VNF may read the NSH header information to determine the next hop (e.g., the next VNF to be executed). As described herein, the packets may include the Slice-Id, which may be used by the classifier and/or router to determine the path. [0271] FIG. 22 depicts an example call flow 2200 illustrating usage of information included within a packet/datagram. At zero 2216, information about slices and/or SFC may be pre- populated from the SFC Routing Information Dissemination Function (SRJDF) to the Classifier Function (CF) 2204 and/or the SDN Controller. The information provided to the CF 2204 may be different from that provided to the SDN Controller. The information sent to the CF 2204 may include the details on the SFC, identified by an SFC-Id for each slice, identified by a Slice-Id. The information sent to the CF 2204 may include policies on the NSH that may be created based upon the SFC for that slice. The information that may be provided to the SDN Controller may be detailed information, for example, on how routing of packets / datagram may be handled. The information may provide details on how the VNFs may be reached and/or default routing information if a VNF may not be reached. The information may include associated routing, QoS, and/or security policies.

[0272] At one 2218, a packet from a WTRU 2202, identified by a WTRU-Id and/or a Slice- Id, may be received by a CF 2204. The CF 2204 may have been pre-configured with

information about Slices, SFCs associated within each slice, and/or connection mechanism (e.g., protocol) from the CF to the next hop (e.g., SDN switch). The initial attachment point with a SAP may be the address of the CF 2204. As part of the "Slice Selection and Assignment process," the WTRU 2202 may be provided with a link to the CF 2204 that may form part of the SAP.

[0273] At two 2220, the CF 2204 may perform a look-up of the list of SFCs that make up the SFP, for example, using the slice-Id as an index to the table that maintains the link(s) between Slice-Id, SFC, and/or the associated SFP.

[0274] At three 2222, the CF 2204 may add an NSH to the packet header and/or may add the list of SFCs or SFP components within the NSH. The SFP components may be addressable as: IP address and/or port number, URL and/or port number, VNF-Id (e.g., which may be translated to addressable endpoints), etc. The CF 2204 may initialize the SI within the NSH. The CF 2204 may identify an NF (e.g., the next NF) that may be targeted for this packet.

[0275] At four 2224, based on the identity of the next NF / VNF, which may be

communicated to a lower layer (e.g., LLC / MAC layer), the lower layer may identify the SDN Switch to which the packet may be forwarded to. The CF may forward the packet to SDN Switch 1 2206. The determination of the forwarding of the packet may be based upon the routing information that may have been populated by the SDN controller at zero 2216.

[0276] At five 2226, based on the information that may have been provided within the NSH, the SDN Switch 1 2206 may determine the NF within the chain. The SDN Switch 1 2206 may determine (e.g., may then determine) the SDN Switch that may lead the packet to the appropriate VNF 2210.

[0277] At six 2228, the SDN Switch 1 2206 may forward the packet and/or datagram to SDN Switch 2 2208.

[0278] At seven 2230, the SDN Switch 2 2208 may inspect the NSH and/or may determine that the next NF (e.g., the next NF that is to service the packet) which may be accessed via it. The SDN switch 2 2208 may translate the SPI and/or the SI into the next-hop (e.g., Next NF to be executed).

[0279] At eight 2232, the SDN switch 2 2208 may send the packet to the VNF 2210. The VNF 2210 may execute an appropriate function to be carried out. In some cases, higher layer protocols may be used, for example, the SDN switch 2 2208 may send the packet to the VNF 2210 using higher-layer protocols (e.g., HTTP, CoAP etc.). In some cases, termination of the packet may occur at a user plane function (e.g. UPF). The UPF may be implemented on an application server.

[0280] At nine 2234, the VNF 2210 may process the packet. Processing the packet may include performing security, session management operations, etc., based on the data within the packet and/or based on the type of network function being performed by the VNF 2210.

[0281] At ten 2236, the VNF 2210 may forward the packet to the SDN Switch 2 2208 and/or to one or more other routing / switches (e.g., a default Switch), for example, once the packet has been processed.

[0282] At eleven 2238, the SDN Switch 2 2208 and/or one or more other routing / switches may modify (e.g., decrement by one) the NSH, for example, in order to indicate the next VNF function to be targeted. The SDN switch 2 2208 may determine the next VNF using the modified NSH.

[0283] In this routing protocol, the NIS information may be taken into consideration when forming the SFC (e.g., NIS-based SFC). No additional information may be embedded and/or carried in the NSH header, for example, to indicate the requested NIS level. The CF 2204 and/or SDN controller may utilize the SFC information to route packets.

[0284] A dynamic path may be used for routing through an assigned SFP.

[0285] When a dynamic path is used for routing, the packet may carry routing

information/intelligence relating to the SFP. The network may determine (e.g., dynamically determine) the SFP navigated, for example, based upon a QCI indication and/or label included within the packet/datagram. The network path may not be pre-determined. The network path may be established at a hop VNF (e.g., each hop VNF) that may be selected and/or that meets and/or exceeds the QCI and/or security requirements as specified. The specific VNF that may satisfy the intent of the QCI may be determined at a hop (e.g., each hop) VNF and/or the SDN controller configured, for example, based on the interpretation of the QCI indication.

[0286] A hybrid path may be used for routing through an assigned SFP.

[0287] When a hybrid path is used for routing, part of the SFP may be performed in a subnetwork (e.g., based on information/intelligence included within the network). When a hybrid path is used for routing, part of the SFP may be performed in a sub-network based on

information included with the packets or datagrams, using a specialized header (e.g., NSH). For example, this may be feasible for separation of RAN and/or Core networks.

[0288] For the same service flow within a given sub-network, a hybrid routing may be applied where the packets (e.g., very first packets) for a particular session (e.g., during session setup) may be routed following a hop by hop classification and/or switching mechanism using NSH insertion and/or lookup. This initial traffic setup after leaving the last switch may lead to the establishment of a new SFP. One or more subsequent packets may follow the new SFP, for example, by regular network based routing (e.g., as soon as a SFP is traced once, normal SDN flow control without the need for the NSH can take over).

[0289] Although features and/or elements are described in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.