Patent ID: 12262200

DETAILED DESCRIPTION

FIG.1Ais a diagram of an example communications system100in which one or more disclosed embodiments may be implemented. The communications system100may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system100may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems100may 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.

As shown inFIG.1A, the communications system100may include wireless transmit/receive units (WTRUs)102a,102b,102c,102d, a radio access network (RAN)104, a core network106, a public switched telephone network (PSTN)108, the Internet110, and other networks112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs102a,102b,102c,102dmay be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs102a,102b,102c,102dmay 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.

The communications systems100may also include a base station114aand a base station114b. Each of the base stations114a,114bmay be any type of device configured to wirelessly interface with at least one of the WTRUs102a,102b,102c,102dto facilitate access to one or more communication networks, such as the core network106, the Internet110, and/or the other networks112. By way of example, the base stations114a,114bmay 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 stations114a,114bare each depicted as a single element, it will be appreciated that the base stations114a,114bmay include any number of interconnected base stations and/or network elements.

The base station114amay be part of the RAN104, 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 station114aand/or the base station114bmay 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 station114amay be divided into three sectors. Thus, in one embodiment, the base station114amay include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station114amay employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

The base stations114a,114bmay communicate with one or more of the WTRUs102a,102b,102c,102dover an air interface116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface116may be established using any suitable radio access technology (RAT).

More specifically, as noted above, the communications system100may 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 station114ain the RAN104and the WTRUs102a,102b,102cmay implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface116using 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).

In another embodiment, the base station114aand the WTRUs102a,102b,102cmay implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface116using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station114aand the WTRUs102a,102b,102cmay implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1×, 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.

The base station114binFIG.1Amay 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 station114band the WTRUs102c,102dmay implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station114band the WTRUs102c,102dmay implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station114band the WTRUs102c,102dmay utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown inFIG.1A, the base station114bmay have a direct connection to the Internet110. Thus, the base station114bmay not be required to access the Internet110via the core network106.

The RAN104may be in communication with the core network106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (Vol P) services to one or more of the WTRUs102a,102b,102c,102d. For example, the core network106may 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 inFIG.1A, it will be appreciated that the RAN104and/or the core network106may be in direct or indirect communication with other RANs that employ the same RAT as the RAN104or a different RAT. For example, in addition to being connected to the RAN104, which may be utilizing an E-UTRA radio technology, the core network106may also be in communication with another RAN (not shown) employing a GSM radio technology.

The core network106may also serve as a gateway for the WTRUs102a,102b,102c,102dto access the PSTN108, the Internet110, and/or other networks112. The PSTN108may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet110may 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 networks112may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks112may include another core network connected to one or more RANs, which may employ the same RAT as the RAN104or a different RAT.

Some or all of the WTRUs102a,102b,102c,102din the communications system100may include multi-mode capabilities, i.e., the WTRUs102a,102b,102c,102dmay include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU102cshown inFIG.1Amay be configured to communicate with the base station114a, which may employ a cellular-based radio technology, and with the base station114b, which may employ an IEEE 802 radio technology.

FIG.1Bis a system diagram of an example WTRU102. As shown inFIG.1B, the WTRU102may include a processor118, a transceiver120, a transmit/receive element122, a speaker/microphone124, a keypad126, a display/touchpad128, non-removable memory130, removable memory132, a power source134, a global positioning system (GPS) chipset136, and other peripherals138. It will be appreciated that the WTRU102may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

The processor118may 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 processor118may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU102to operate in a wireless environment. The processor118may be coupled to the transceiver120, which may be coupled to the transmit/receive element122. WhileFIG.1Bdepicts the processor118and the transceiver120as separate components, it will be appreciated that the processor118and the transceiver120may be integrated together in an electronic package or chip.

The transmit/receive element122may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station114a) over the air interface116. For example, in one embodiment, the transmit/receive element122may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element122may 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 element122may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element122may be configured to transmit and/or receive any combination of wireless signals.

In addition, although the transmit/receive element122is depicted inFIG.1Bas a single element, the WTRU102may include any number of transmit/receive elements122. More specifically, the WTRU102may employ M IMO technology. Thus, in one embodiment, the WTRU102may include two or more transmit/receive elements122(e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface116.

The transceiver120may be configured to modulate the signals that are to be transmitted by the transmit/receive element122and to demodulate the signals that are received by the transmit/receive element122. As noted above, the WTRU102may have multi-mode capabilities. Thus, the transceiver120may include multiple transceivers for enabling the WTRU102to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

The processor118of the WTRU102may be coupled to, and may receive user input data from, the speaker/microphone124, the keypad126, and/or the display/touchpad128(e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor118may also output user data to the speaker/microphone124, the keypad126, and/or the display/touchpad128. In addition, the processor118may access information from, and store data in, any type of suitable memory, such as the non-removable memory130and/or the removable memory132. The non-removable memory130may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory132may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor118may access information from, and store data in, memory that is not physically located on the WTRU102, such as on a server or a home computer (not shown).

The processor118may receive power from the power source134, and may be configured to distribute and/or control the power to the other components in the WTRU102. The power source134may be any suitable device for powering the WTRU102. For example, the power source134may 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.

The processor118may also be coupled to the GPS chipset136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU102. In addition to, or in lieu of, the information from the GPS chipset136, the WTRU102may receive location information over the air interface116from a base station (e.g., base stations114a,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 WTRU102may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

The processor118may further be coupled to other peripherals138, 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 peripherals138may 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.

FIG.1Cis a system diagram of the RAN104and the core network106according to an embodiment. As noted above, the RAN104may employ an E-UTRA radio technology to communicate with the WTRUs102a,102b,102cover the air interface116. The RAN104may also be in communication with the core network106.

The RAN104may include eNode-Bs140a,140b,140c, though it will be appreciated that the RAN104may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs140a,140b,140cmay each include one or more transceivers for communicating with the WTRUs102a,102b,102cover the air interface116. In one embodiment, the eNode-Bs140a,140b,140cmay implement MIMO technology. Thus, the eNode-B140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU102a.

Each of the eNode-Bs140a,140b,140cmay 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 inFIG.10, the eNode-Bs140a,140b,140cmay communicate with one another over an X2 interface.

The core network106shown inFIG.10may include a mobility management entity gateway (MME)142, a serving gateway144, and a packet data network (PDN) gateway146. While each of the foregoing elements are depicted as part of the core network106, 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.

The MME142may be connected to each of the eNode-Bs140a,140b,140cin the RAN104via an S1 interface and may serve as a control node. For example, the MME142may be responsible for authenticating users of the WTRUs102a,102b,102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs102a,102b,102c, and the like. The MME142may also provide a control plane function for switching between the RAN104and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

The serving gateway144may be connected to each of the eNode Bs140a,140b,140cin the RAN104via the S1 interface. The serving gateway144may generally route and forward user data packets to/from the WTRUs102a,102b,102c. The serving gateway144may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs102a,102b,102c, managing and storing contexts of the WTRUs102a,102b,102c, and the like.

The serving gateway144may also be connected to the PDN gateway146, which may provide the WTRUs102a,102b,102cwith access to packet-switched networks, such as the Internet110, to facilitate communications between the WTRUs102a,102b,102cand IP-enabled devices.

The core network106may facilitate communications with other networks. For example, the core network106may provide the WTRUs102a,102b,102cwith access to circuit-switched networks, such as the PSTN108, to facilitate communications between the WTRUs102a,102b,102cand traditional land-line communications devices. For example, the core network106may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network106and the PSTN108. In addition, the core network106may provide the WTRUs102a,102b,102cwith access to the networks112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

Other network112may further be connected to an IEEE 802.11 based wireless local area network (WLAN)160. The WLAN 160 may include an access router165. The access router may contain gateway functionality. The access router165may be in communication with a plurality of access points (APs)170a,170b. The communication between access router165and APs170a,170bmay be via wired Ethernet (IEEE 802.3 standards), or any type of wireless communication protocol. AP170ais in wireless communication over an air interface with WTRU102d.

Referring now toFIGS.2A,2B, and2C, network slice instances206,208,210,212,214,218,220,222which are grouped by control plane (CP) and user plane (UP) nodes per network slice are shown. A network slice may have independent CP203,207and UP nodes205,209as shown inFIG.2A. Specifically, the CN Instance #1206may include a CP node203and a UP node205inside the network slice of CN Instance #1206. Similarly, the CN Instance #2208may include a CP node207and a UP node209inside the network slice of CN Instance #2208. The CP nodes203,207in the CN Instance #1206and the CN Instance #2208respectively may receive control plane signaling messages from a WTRU202. The UP nodes205,209in the CN Instance #1206and the CN Instance #2208respectively may receive user plane data from the WTRU202. For example, the WTRU202may transmit registration and authentication requests to the CP node203of CN Instance #1206. The WTRU202may also transmit data packets to the UP node205of CN Instance #1206. Similarly, the WTRU202may transmit its mobility management message to the CP node207of CN Instance #2208and its session management message to the UP node209of CN Instance #2208. The WTRU202may be connected to the CN Instance #1206and CN Instance #2208via the Shared Access Network (AN)204.

Referring now toFIG.2B, a diagram of an embodiment where a network slice may share a CP node210but have partly independent CP211,215and completely independent UP nodes218,216per network slices is shown. Specifically, the CN Instance slice #1212or CN Instance slice #2214may share the shared core network (CN) control plane (CP) functions. The CN Instance slice #1212may include a partly independent CP node211and a completely independent UP node218. The CN Instance slice #2214may include a partly independent CP node215and a completely independent UP node216. The shared CN CP functions210may perform common network functions for the CN Instance slice #1212and CN Instance slice #2214. Such common network functions may include authentication, mobility management, session management, gateway function, and the like.

The partly independent CP nodes211,215may perform slice specific control plane network functions. The completely independent UP nodes213,216may also perform slice specific user plane network functions. The WTRU202may be connected to the CN Instance slice #1212or CN Instance slice #2214without the shared CN CP functions210for a slice specific network function. Such a slice specific network function may include non-shared session management functions.

Referring now toFIG.2C, a diagram of an embodiment where a network slice may share control plane (CP) functions217in a shared CN CP node218and have independent user plane (UP) nodes219,221per network slices is shown. The shared CN CP node218may perform shared control plane functions217for several core network instances such as the UP Instance #1220and UP Instance #2222. The UP Instance #1220and UP Instance #2222may include independent UP nodes219,221, respectively. The Shared CN CP218, UP Instance #1220, and UP Instance #2222may be connected to the WTRU202via the shared access network (AN)204. The UP Instance #1220and UP Instance #2222may have the shared CN CP node218for the control plane functionalities. The shared CN CP functions217may perform common control plane functions for the UP Instance #1220and UP Instance #2222. The common control plane functions performed by the shared CP functions217may include authentication, mobility management, gateway function, and the like. The UP nodes219and221in the UP Instance #1220and UP Instance #2222may perform slice specific user plane network functions such as non-shared session management functions.

Referring now toFIG.3, an example network slicing that includes shared CP functionalities314and independent UP functionalities312,316is shown. The network slicing inFIG.3may be modeled towards the network slice instances shown inFIG.2C. The shared CP functionalities314and independent UP functionalities312may form a network slice (i.e. Core Network Instance #1308). Similarly, the shared CP functionalities314and independent UP functionalities316may form another network slice (i.e. Core Network Instance #2310).

As shown inFIG.3, the Core Network Instance #1308may include a single set of control plane functionalities314(C-Plane functions) and a single set of user plane functionalities312(U-Plane functions). The single set of control plane functionalities314may include multiple functions such as CPF #1320, CPF #2322, and CPF #3324for the common network functions. Such common network functions may include authentication, mobility management, session management, gateway function, and the like. The single set of user plane functionalities312may include multiple functions such as NS-1UPF #1326, NS-1UPF #2328, and NS-1UPF #3330for the slice specific user plane network functions. Similarly, the Core Network Instance #2310may include a single set of control plane functionalities314and a single set of user plane functionalities316. The single set of user plane functionalities316may include multiple functions such as NS-2UPF #1332, NS-2UPF #2334, and NS-2UPF #3336for the slice specific user plane network functions.

In an embodiment, the Core Network Instance #1308or Core Network Instance #2310may be a dedicated network slice for the WTRU302depending on the type of WTRU302. The type of WTRU302may be identified by using specific parameters such as WTRU302usage type, WTRU's302subscription information, and the like.

A set of C-Plane functions, CPF #1320, CPF #2322, and CPF #3324, may be responsible for supporting mobility of the WTRU302if the mobility management is demanded by the WTRU302. In addition, the CPF #1320, CPF #2322, and CPF #3324may be responsible for admitting the WTRU302into the network by performing authentication and subscription verification. For example, the CPF #1320in the CP Functionalities314may provide mobility management to the WTRU302for the Core Network Instance #1308. At the same time, the CPF #1in the CP Functionalities314may provide another mobility management to the WTRU302for the Core Network Instance #2310. Similarly, the CPF #2322in the CP Functionalities314may authenticate the WTRU302for the Core Network Instance #1308. The CPF #2322in the CP Functionalities314may also authenticate the WTRU302for the Core Network Instance #2310.

A set of U-Plane functions (i.e. NS-1UPF #1326, NS-1UPF #2328, NS-1UPF #3330in the Core Network Instance #1308, and NS-2UPF #1332, NS-2UPF #2334, NS-2UPF #3336in the Core Network Instance #2) may be responsible for providing a specific service to the WTRU302. The set of U-Plane functions above may also responsible for transporting U-Plane data of the specific service to the WTRU302. For example, the NS-1UPS #1326in the Core Network Instance #1308may provide an enhanced mobile broadband service to the WTRU302, whereas the NS-2UPF #2334in the Core Network Instance #2310may provide a critical communication service to the WTRU302.

When the WTRU302first connects to an operator's network through the RAN304, a default core network instance that matches to the WTRU302usage type may be assigned to the WTRU302. The assigned default core network instance may be the Core Network Instance #1or Core Network Instance #2depending on the WTRU302usage type. The WTRU302may have multiple U-Plane connections to different sets of U-Plane functions that are available at different core network instances simultaneously. This means that the WTRU302may be connected to user plane functions NS-1UPF #1326, NS-1UPF #2328, NS-1UPF #3330in the UP Functionalities312, and at the same time, the WTRU302may be connected to another user plane functions NS-2UPF #1332, NS-2UPF #2334, NS-2UPF #3336in the UP Functionalities316. Although it is not shown inFIG.3, the connection to user plane functions may not be limited to the UP Functionalities312and UP Functionalities316. The WTRU302may have multiple user plane connections to different user plane functions in core network instances other than the Core Network Instance #1and Core Network Instance #2.

The Core Network Selection Function (CNSF)306may be responsible for selecting a core network instance among the Core Network Instance #1and Core Network Instance #2. The CNSF306may determine the core network slice selection based on WTRU's302subscription and specific parameters such as WTRU302usage types. The CNSF306may also be responsible for selecting control plane functions within the selected core network instance that a base station may communicate with. For example, the CNSF306may select CPF #2322and CPF #3324in the Core Network Instance #1308to communicate with a base station. The selection of control plane functions may be done by using specific parameters such as WTRU302usage types. The CNSF306may be responsible for selecting a set of user plane functions that a base station may establish in the connection for transporting user plane data of different services. For example, the CNSF306may select NS-1UPF #2328in the Core Network Instance #1308to transport user plane data of an enhanced mobile broadband service. The selection of user plane functions among NS-1UPF #1326, NS-1UPF #2328, NS-1UPF #3330, NS-2UPF #1332, NS-2UPF #2334, and NS-2UPF #3336may be done by using specific parameters such as WTRU302usage types, service types and the like. Although it is not shown inFIG.3, the selection of user plane functions may not be limited to the Core Network Instance #1and Core Network Instance #2and the CNSF306may select other user functions located in core network instances other than Core Network Instance #1and Core Network Instance #2.

Referring now toFIG.4, an example of network slice selection per service provided by a network is illustrated. The slice selection and routing function406may be provided by the RAN404, which may be similar to a conventional NAS node selection function. Alternatively, a CN-provided function may perform that task. The slice selection and routing function406may route signaling to CN instances such as General CN Instance A408, General CN Instance B410, Other CN Instance N411, NB CN Instance A412, and NB CN Instance B414, based on WTRU-provided401information, CN-provided information, or the similar.

All network instances of the PLMN402may share radio access, and there may be a need for separating any access barring and (over)load control per slice. This may be accomplished by conventional methods of separated access barring and (over)load control, which is provided per PLMN operator for network sharing. Using this method, there may be CN resources such as transport network resources that cannot be fully separated. For example, the General CN Instance A408and General CN Instance B410may have control plane and user plane functions as their network functions. For example, the General CN Instance A408may include NF1416and NF2418for its control plane functions and NF3420for its user plane function for Data Network1436. Similarly, the General CN Instance B410may include NF1422and NF2424for its control plane functions and NF3426for its user plane function for Data Network2438. Using the NF1s416422, NF2s418424, and NF3s420426, the General CN Instance A408and General CN Instance B may provide full core network functions to the WTRU401.

The NF1428and NF3430in Narrowband (NB) CN Instance A412may provide a narrowband service for the WTRU401for Data Network3440. Similarly, NF1432and NF3434in Narrowband (NB) CN Instance B414may provide another narrowband service to the WTRU401for Data Network4442. The narrow band services may be an Internet of Things (IoT) services. In this case, the WTRU401may be an IoT device. Since an IoT service does not require a full core network functionalities, the NB CN Instance A412and NB CN Instance B414may include fewer number of network functions than the General CN Instance A408and General CN Instance B410may include. This means that, in order to provide narrowband services, the NB CN Instance A412and NB CN Instance B414do not need to include NF2sas the General CN Instance A408and General CN Instance B410do.

Referring now toFIG.5, an example of network slice selection based on a multi-dimensional descriptor is shown. The embodiment shown inFIG.5may use a multi-dimensional descriptor for network slice selection. In order to perform the network slice selection, the selection principle may enable the appropriate selection function to deliver a certain service even within a class of functions designed for a certain use case. In other words, based on selection criteria, a correct network slice and correct network functions within the network slice may be assigned to applications running in WTRUs502,504,506for network services that the applications require. The applications running in WTRUs502,504,506can provide multi-dimensional descriptors. Such multi-dimensional descriptors may contain an application ID, service descriptor (e.g., enhanced mobile broadband service, critical communications, or massive machine type communications), and the like.

As described above, in order to choose the appropriate network slice and network functions, a network may use a multi-dimensional descriptor along with other information (e.g., WTRU's subscription) available in the network. This may be referred to as a multi-dimensional selection mechanism. The following may be possible options to select network slices and functions based on a multi-dimensional descriptor. A first option may be a two-step selection mechanism. Along with information (e.g., WTRU's subscription) available in a network, a selection function507in a RAN508may use an application ID (part of the multi-dimensional descriptor) to select an appropriate core network slice among CN Slice A510, CN Slice B512, and CN Slice C514. The selection function507, then, may use a service descriptor (part of the multi-dimensional descriptor) to select appropriate network functions within the selected network slice. Alternatively, a core network selection function505may use the application ID to select an appropriate core network slice among CN Slice A510, CN Slice B512, and CN Slice C514. The core network selection function505, then, may use a service descriptor to select appropriate network functions within the selected network slice.

In an embodiment, a WTRU1502may run an application that requires an enhanced mobile broadband such as 4K/8K UHD and Hologram. The application may transmit its multi-dimensional descriptor to a RAN508along with its application ID. In this case, the multi-dimensional descriptor may include the enhanced mobile broadband for its service descriptor. A selection function507in the RAN508may use the application ID to select CN Slice A510that provides the enhanced mobile broadband service for its appropriate core network slice. After that, the selection function507in the RAN508may use a service descriptor (i.e. enhanced mobile broadband) to select MM1516, SM1522, and PC1528. MM1516in the CN Slice A510may provide mobility management functions for the WTRU1502among all the mobility management functions (i.e. MM1516, MM2518, MM3520). SM1522and PC1528may provide appropriate session management and packet core functions for the enhanced mobile broadband service among all the session management (i.e. SM1522, SM2524, SM3526) and packet core functions (i.e. PC1528, PC2530, PC3532) in the CN Slice A510. Thus, the selection function507in the RAN508may select the MM1516, SM1522, and PC1528as the appropriate network functions to provide the enhanced mobile broadband service.

In another embodiment, the WTRU2504may run an application that requires critical communications such as motion control, autonomous driving, and factory automation. As described above, the application that runs a critical communication service may transmit its multi-dimensional descriptor to a RAN508along with its application ID. The multi-dimensional descriptor may include critical communications for its service descriptor. A selection function508in the RAN508may use the application ID to select a CN Slice B512that provides a critical communication service for its appropriate core network slice. After that, the selection function507in the RAN508may use the service descriptor, the critical communications, to select MM3538, SM3544, and PC3550. MM3538in the CN Slice B512may provide mobility management functions for the WTRU2504, among all the mobility management functions MM1534, MM2536, MM3538. SM3544and PC3550may provide appropriate session management and packet core functions for the critical communication service among all the session management SM1540, SM2542, SM3544and packet core functions PC1546, PC2548, PC3550. Thus, the selection function507in the RAN508may select the MM3538, SM3544, and PC3550for the critical communications service.

In another embodiment, the WTRU3506may run an application that requires massive machine type communications such as sensor network. As described above, the application that runs massive machine type communication service may transmit its multi-dimensional descriptor to a RAN508along with its application ID. The multi-dimensional descriptor may include massive machine type communications for its service descriptor. A selection function507in the RAN508may use the application ID to select a CN Slice C514that provides a massive machine type communication service for its appropriate core network slice. After that, the selection function507in the RAN508may use the service descriptor, the massive machine type communications, to select SM2558, and PC2564. In this embodiment, the WTRU3506may be an IoT device such as a sensor. Because IoT devices does not require full core network functions like in the CN Slice A510and CM Slice B512, the CN Slice C514may include fewer number of mobility management functions (i.e. MM1552and MM3554) than the CN Slice A510and CN Slice B512include (i.e. MM1516,534, MM2518,536, MM3520,538). In addition, the WTRU3506may not need to connect a mobility management function to receive the massive machine type communication service. Thus, the CM Slice C514may not need to provide MM1552and MM3554to the WTRU506for the massive machine type communication service. The SM2558and PC2564in the CN Slice C514may provide appropriate session management and packet core functions for the massive machine type communication service among all the session management and packet core functions (i.e. SM1556, SM2558, SM3560, PC1562, PC2564, and PC3566). Thus, the selection function507in the RAN508may choose the SM2558and PC2564for the massive machine type communication service.

Another option may be a one-step selection mechanism. Along with information (e.g., WTRU's subscription information) available in a network, a selection function507within a RAN508or a selection function505in a core network may use an application ID and a service descriptor (e.g., the multi-dimensional descriptor) to select an appropriate network slice and its respective network functions in CN Slice A510, CN Slice B512, and CN Slice C514. It may then direct the WTRUs502,504,506to the selected network slice and functions accordingly.

As described above, various embodiments of how CP and UP functions can be grouped per slice or across slices are illustrated inFIGS.2A,2B,2C,3,4, and5. However, specific CP and UP functions may need to be further described. The impact on a 5G communication system, as a result of sharing such functions, may also need to be considered. For example, if paging is a shared network function among different network slices, then it needs to be described how network slices use or trigger the shared paging function to send a page to a WTRU. Conversely, if paging is not a shared network function, then it needs to be described how each network slice can send paging messages to a WTRU. If each network slice sends paging messages to each of WTRU separately, there may be a need to use one or more identities for the WTRU.

There may be particular network services that require different network functions performed by different CP and/or UP nodes. For example, in a 5G system, a device or a WTRU may send IP and/or non-IP data. The non-IP data can take two forms: non-IP PDUs and Ethernet frames. Furthermore, the transport requirement for IP vs non-IP data may be different. Specifically, the type of data that a network supports and transports may have an impact on a network slice selection because different CP and UP functions are required to support the type of data that a WTRU transmits. Another type of data that a network may support is Information Centric Networking (ICN) data, where a different network slice can be used to transport such ICN type data. Embodiments described herein may handle different data support by using independent network slices.

As described above, grouping CP nodes in an independent network slice or as shared functions across network slices, is a high level design. Embodiments how CP nodes and functions operate may need to be further described. More specifically, embodiments such as which nodes perform authentication and paging may need to be listed. More importantly, the impacts on a 5G system by performing actions, for example, paging in an independent or shared node, may also need to be described in detail.

In addition, other embodiments that describe a proper selection of a network function after a network slice is assigned may need to be addressed. For example, where a slice comprises a shared CP and an independent UP node, after a WTRU is assigned to receive services from two different network slices that have independent UP nodes, the selection of a correct UP node (i.e., how data will be forwarded to the correct UP node) may need to be addressed.

Additionally, a location of a responsible node for authentication, authorization, and identification may need to be described. As shown inFIG.2B, there may be several questions about “where” certain important security functions may reside. If an operator would like to have a centralized control plane management, a “Shared CN CP Functions210” may take the registration of WTRU202. Therefore, this Shared CN CP210node may be responsible for authentication as well as identity management. In response to the authentication process performed by the Shared CN CP Functions210, how the CN instance slice #1212and CN instance slice #2214use the authentication information and how the authentication information maps the WTRU202identities (e.g. an external ID) to old identities within a network may need to be addressed.

Handling of a network slice in a multi access network (AN) environment, such as 3GPP and non-3GPP access network, may need to be addressed. The embodiments described above may address cases where the AN corresponds to a 3GPP-based AN. However, 5G systems may include both 3GPP and Non-3GPP access networks. Thus, a 5G system should consider all allowed types of access networks when it manages network slices.

Delayed network slice selection may need to be addressed in certain scenarios. Such a scenario where a network may not select a network slice at initial registration or attach may be illustrated inFIG.2B. For example, a WTRU202may register to shared CN CP functions210. A network slice may then be selected when there is a need to use a particular function from non-shared CP functions in CN Instance #1212and CN Instance #2214. As a result, a network slice selection may take place to utilize the particular non-shared CP functions. Such procedures may need to be detailed, especially with respect to how and which nodes are responsible for the network slice selection.

Referring now toFIG.6, a diagram illustrating an overall architecture for network slicing per data types is shown. As described above, different network slices may be used for different data types that are supported by WTRUs602,604,606. In a 5G system, a network slice may support both IP and non-IP data type. A network slice can be used to carry IP data, and another network slice can be used to carry non-IP data. This may be referred to as a network slice per data type. In addition to the IP and non-IP data type, a network slice may carry different non-IP data types. This means, a network slice can be used to carry non-IP PDU data and another network slice can be used to carry Ethernet frames. This may be referred to as a network slice per non-IP data type. Although the non-IP data may refer to both non-IP PDU and Ethernet frames, in some embodiments these types of non-IP data may be considered to be different.

FIG.6shows an example with three network slices (i.e. Network Slice #1610, Network Slice #2612, and Network Slice #3614) to service and transport different data types. These network slices, Network Slice #1610, Network Slice #2612, and Network Slice #3614, may share a set of CP functions referred to as “Shared CP616.” Each of Network Slice #1610, Network Slice #2612, and Network Slice #3614may have their own independent/isolated set of CP functions referred to as “Non-Shared CP #,” where “#” may refer to the slice ID at least within the CN (i.e. Non-Shared CP1618, Non-Shared CP2620, or Non-Shared CP3622). In this example, the Network Slice #1610, Network Slice #2612, and Network Slice #3614may carry a specific data type, such as IP data type, non-IP data type (e.g., non-IP PDU and/or Ethernet Frames), or data type related to Information-centric Networking (ICN). The ICN data may also be non-IP data, IP data that encapsulates ICN PDUs, or other forms of transporting ICN PDUs.

The Non-Shared CP1618, Non-Shared CP2620, and Non-Shared CP3622may also have interfaces624,626,628with a main or share CP function616, respectively. As shown inFIG.6, WTRUs602,604,606may have access630,632,634,636to Network Slice #1610, Network Slice #2612, and Network Slice #3614. For example, WTRU Z606may have access634to Network Slice #1610for IP data. The WTRU Z606may have access636to Network Slice #3614for non-IP data. The WTRU X602may have access630to Network Slice #1610for IP data. The WTRU Y604may have access632to Network Slice #2620for ICN data.

Moreover, the WTRUs602,604,606may have direct access or interface638with the shared CP616via the RAN608, or indirect access or interface via the Non-Shared CP1618, Non-Shared CP2620, and Non-Shared CP3. When an indirect access or interface is established, the access630,632,636may be used to connect to the shared CP616via Non-Shared CP1618, Non-Shared CP2620, and Non-Shared CP3. For example, the WTRU X602may be connected to the shared CP616via the Non-Shared CP1618using the interface630. The WTRU Y604may be connected to the shared CP616via the Non-Shared CP2620using the interface632. The WTRU Z606may be connected to the shared CP616via the Non-Shared CP3622using the interface636. When a direct access or interface is established, the access638may be used to connect the WTRUs602,604,606to the shared CP616.

The WTRUs602,604,606may have direct contact or interface with the Non-Shared CP1618, Non-Shared CP2620, and Non-Shared CP3in the Network Slice #1610, Network Slice #2612, and Network Slice #3614. For example, when directly connected, the WTRU X602may have direct access630to the Non-Shared CP1618. The WTRU Y604may have direct access632to the Non-Shared CP2620. The WTRU Z602may have direct access636to the Non-Shared CP3622.

In addition, the WTRUs602,604,606may have indirect access or interface to the Non-Shared CP1618, Non-Shared CP2620, and Non-Shared CP3in the Network Slice #1610, Network Slice #2612, and Network Slice #3614via a shared CP node616. When indirectly connected, the WTRU X602may use the access624to the Non-Shared CP1618via the shared CP616. The WTRU Y604may use the access626to the Non-Shared CP2620via the shared CP616. The WTRU Z606may use the access628to the Non-Shared CP3622via the shared CP616.

The following embodiments may include selection of a network slice based on support or need for non-IP data. As explained above, the term “non-IP data” may refer to all forms of non-IP data (e.g., non-IP PDU, Ethernet Frames, ICN data, etc.) It is noted that the term “Non Access Stratum (NAS)” may be used to refer to higher layer messages above the radio, such as the conventional NAS protocol. However, NAS may be any other protocol that runs between WTRUs and

CP functions in a CN and is not necessarily limited to the conventional NAS protocol. The selection of a network slice for a WTRU can be done at a RAN or at a CN.

A WTRU may, upon establishing a radio connection, indicate that the requested service is non-IP data. This indication may be in any form, such as a capability or explicit service type, or it may be inferred from the WTRU type. The WTRU may also indicate the need or request for non-IP service in any of its NAS messages that are either related to mobility or session management procedures.

A RAN may take this information or indication into account and may select a network slice that supports this service. The RAN node may then forward the WTRU's higher layer message (e.g., NAS) to the CP function in that network slice. Alternatively, the RAN may use other information from the WTRU to perform the selection of the most appropriate CP function in the CN. The RAN may then send this information to the CP function.

The CP function in the CN may receive a message from the WTRU with an indication for non-IP data. The CP function may verify if the specific type of non-IP data that is requested can be provided by the CP function. If the CP can provide service for non-IP data, it may continue to process the WTRU request. Otherwise, the CP function may redirect the WTRU message to another network slice using a Dedicated Core Network (DECOR) solution. This embodiment may assume that the CP function has local information or configuration to determine the network slice or the CP address within a network slice that can serve the WTRU for the requested service, in this case, non-IP data. When determining the target network slice to serve the WTRU for non-IP data, the current CP function may input the service type (i.e., in this case “non-IP data”) into its local look-up function.

In an embodiment, a WTRU may already be registered in the network for a particular service (e.g., IP-data service or non-IP data). The WTRU may support service for a secondary data type, and as such, may want to get the service. The WTRU may send a request to get a secondary service for a different data type which may be offered by another network slice. The methods to achieve this such as when a WTRU may need to do so are described herein.

When a WTRU needs to select a secondary service, one network slice may provide support for different services. For example, a network slice may be deployed to provide connectivity for the Internet of Things (IoT), for which there may be different connection or transport modes. One IoT application may require an IP connection, while another may not if the data is encapsulated in a control plane message. Thus, the general service type may be IoT; however the specific service can be “IP for IoT” or “Data over CP for IoT.”

Therefore, one network slice may actually be used to provide at least these two types of transports or connections for the WTRU. It is therefore important for the WTRU to know whether or not the same slice can provide more than one service. If so, the WTRU needs to know what the services are provided by the network slice. This may help the WTRU to determine whether a new network slice has to be selected and registered with, or if the WTRU can simply request the service from the existing network slice. The following embodiments may address this issue.

Referring now toFIGS.7A and7B, a signaling diagram illustrating a network slice selection for service supported by the network slice is shown. The WTRU702may transmit the Registration Request message710to the CP function of the network. The Registration Request message710may include a list of supported services or a list of services that the WTRU702is capable to receive (hereinafter referred to as “supported services”). Alternatively, the WTRU702may simply request to be informed of the list of services that the current network slice (or the current CP within this slice) supports. This indication of supported services, or the solicitation of the network's supported services, may be done or included in the Registration Request message710that is sent to the network.

If the WTRU702is already registered and it wants to determine whether or not the network supports other services, the WTRU702may send a new control message by, for example, NAS signaling or a Supported Service Type Request message714. In this Supported Service Type Request message714, the WTRU702may either indicate its supported and/or desired services, or it may solicit the network to provide the list of services that are supported in the network.

The network (e.g., any CP node or NF in the network) may receive a NAS message with a list of WTRU-supported services, or with a solicitation request to inform the WTRU702about the services that are supported in the network. The network may verify if the WTRU's subscription allows such information to be provided to the WTRU702, which may also be based on the network policy. The network may determine to send a list of supported network services in the Supported Service Type Response message716to the WTRU702. The network may send a NAS message and may indicate the supported services in the NAS message.

Alternatively, if the request from the WTRU702is for a specific service, the network may send a response with a {service type, support} indication, where the “service type” reflects the particular service about which network support is requested, and the “support” indicates if the service is supported or not. The network may send this list in any NAS message, either as part of the registration process, or when the WTRU702sends any NAS message that contains such a request.

For a given network slice with which the WTRU702is registered, the WTRU702may save the supported services in that network slice as determined using the embodiments described above. When the WTRU702requires or needs new services, the WTRU702may check the list of supported services in the network slice that the WTRU702is registered. If the service is indicated to be supported, then the WTRU702may simply send a NAS message to request the service. The NAS message may be sent to this network slice or to the CP/NF within the network slice to which the WTRU702is registered. The lower layer messages (e.g., radio messages) may contain a service indicator that points to this network slice. This may ensure that the service request, or any NAS message that may be used to obtain a new service, may be sent to the appropriate network slice (e.g., the network slice with which the WTRU702is already registered).

On the other hand, if the WTRU702determines that the service needed is not supported in the network slice, the WTRU702may then send another radio message722(e.g. RRC message). This radio message722may encapsulate a NAS message for registration. The radio message722may include a corresponding service descriptor associated with the Slice2708, which can be in any format to indicate the desired service type. The RAN704or the slice selection function may use this parameter to pick the appropriate network slice and may forward the NAS message724to the selected network slice. It should be noted that the NAS registration message may be different from the NAS message used to get a service within the same network slice. The selected network slice, the Slice2708here, may send a Service Response message726to the WTRU702.

Thus, when a required service is supported in the current network slice, the WTRU702may send the Additional Service Request message718. If the WTRU702needs to get the service from another network slice, the WTRU702may then send a registration message to first register in that network. The WTRU702may ensure that the lower layer parameter (e.g., dedicated core network type, “WTRU usage type,” “service descriptor,” etc.) reflects a different service type and/or a different network slice from that which the WTRU702is already registered.

The following embodiments may include a responsible node for security functions and identity management in network slicing. In an embodiment, the “Shared CN CP Functions” may be responsible for the registration (e.g., Attach/TAU) procedure. A Registration (Attach/TAU) Request message from a WTRU may terminate in Shared CN CP Functions. This registration request message may contain important WTRU related parameters such as capabilities, (e)DRX parameters, PSM information or the like.

At this point, depending on whether the WTRU uses IMSI or an alias for identification purpose, the Shared CN CP Functions may retrieve WTRU's IMSI number or the similar either by forcing the WTRU to send it (e.g., through the Identification Procedure in NAS specs) or by simply receiving it from the previous anchor node (e.g., an MME, SGSN or another Shared CN CP Functions) where the WTRU was registered. In order to facilitate some of the following procedures, the Shared CN CP Functions may, once the registration phase has succeeded and completed, send the IMSI number to the CN instance slice #1and slice #2. This may ensure that both slices are made aware of the WTRU's IMSI number or the similar identification information.

Another important factor is that the WTRU may get its “temporary” number, whether it is a GUTI or S-TMSI, allocated from the Shared CN CP Functions. With this mechanism, the slices may be hidden from the WTRU, which may believe that it is communicating with only one node, the Shared CP node.

Upon reception of the “Registration Request” message, the Shared CN CP Functions may contact the Home Subscriber Server (HSS) and ask for Authentication Vectors. After receiving the vectors, the Shared CN CP Functions may start an authentication procedure toward the WTRU based on the current mechanisms. If the WTRU passes this phase, the Shared CN CP Functions may send a message to both instance Slice #1and Slice #2informing them that this WTRU has been successfully authenticated. At this point, both Slice #1and Slice #2may set flags in their corresponding databases and consider the WTRU as completely “valid.” The Shared CN CP Functions may also start a Security Mode Control procedure toward the WTRU and then pass security contexts to the Slice #1and Slice #2to be used for the User Plane security.

A shared RAN may only have a signaling connection to the Shared CN CP Functions, so all communications, even between instance Slice #1/Slice #2and the WTRU, may go through the Shared CN CP Functions. As an example, if the instance Slice #1has something to be sent to the WTRU, it may not need to know the state (e.g., idle/connected mode) of the WTRU. It may just send a request to the Shared CN CP Functions which, in turn, will page the WTRU and establish a signaling connection.

In another embodiment, a mechanism that combats denial of service attacks toward a WTRU may be included. A first authentication message sent from Shared CN CP Functions to the WTRU may have a new parameter (e.g., a “token”) that is derived from the WTRU's IMSI number and RAND. After the authentication process is complete, the Shared CN CP Functions may pass this token to other network slices such as Slice #1and Slice #2for future use. If the operator's configuration is subject to dynamic change in a way that the Slice #2may, for example, take over both Control and User Plane, then Slice #2may include the “token” in the subsequent NAS messages to the WTRU. These (subsequent) messages shall be integrity protected even for the reject cases.

The WTRU may communicate with the Shared CN CP Functions. This means that the Shared CN CP Functions may be aware of any external ID that the WTRU may have. For that reason, the Slice #1and Slice #2may inform the Shared CN CP Functions about any external ID that the WTRU is assigned or is using. The mapping between the external IDs, IMSI and the temporary WTRU ID may be done in the Shared CN CP Functions. When the User Plane bearers are established by the Shared CN CP Functions, the Shared CN CP Functions may inform the corresponding entity of the used identities for User Plane connections.

The following embodiments may include split functionality management. As shown inFIG.2B, the load on Shared CN CP Functions210may increase dramatically based on the number of registered WTRUs and the number of slices that are connected to the Shared CN CP Functions210. In the following embodiments, it may be assumed that a network operator has configured their network according to theFIG.3(i.e., there are only two CN instance slices connected to the Shared CN CP Functions). It may also be assumed that all IP traffic may reside in Core Network Instance #1308and all Non-IP traffic may be in Core Network Instance #2310.

In order to decrease the load on the Shared CN CP Functions, the Shared CN CP Functions may handle “Mobility Management” portion of the chosen protocol between a WTRU and a core network. As an example, assuming that the WTRU can send both Mobility Management (MM) and Session Management (SM) messages in a secured way, the Shared CN CP Functions may deal with the MM messages.

Accordingly, the MM messages may terminate in the Shared CN CP Functions. The SM messages may be passed by the Shared CN CP Functions to either Slice #1or Slice #2. As previously stated, Slice #1may be the terminating node for IP traffic and Slice #2may be the terminating node for the Non-IP traffic

The following embodiments may distinguish between network slices and the routing of data under the assumption that a WTRU has a short packet to send and a network is configured to allow the WTRU to send its data, whether it is IP or Non-IP, over Control Plane.

In an embodiment, a new protocol layer (in-line with the Session Management) may be used to transfer all Non-IP related data. When a WTRU needs to send a short Non-IP packet over the control plane, it may piggy-back the packet in this new protocol message format and may transmit to the Shared CN CP Functions. At the Shared CN CP Functions, the message may be integrity checked and the content of the message, which may be the short Non-IP packet, may be extracted to be forwarded to the Slice #2using appropriate protocol on that interface. The deciphering of the packet may be done in the Shared CN CP Functions. However, to ease the functionality and decrease the load, the deciphering may be performed at the Slice #2.

As for the IP-packets, the WTRU may simply piggy-back them onto certain SM messages and may send them to the Shared CN CP Functions. The Shared CN CP Functions may perform an integrity check on the message. After that, the Shared CN CP Function may extract the IP-Packet and send it to Slice #1. The ciphering/deciphering options may be the same as those discussed above. It should be noted that if the ciphering/deciphering is to take place in the slices, the Shared CN CP Functions may have to pass the Ciphering Keys as well as Algorithms to the slices.

In another embodiment, in the MM and SM protocol discussed above, certain SM messages may be used to carry both IP and Non-IP packets over the Control Plane. The SM message may be piggy-backed onto the MM message. In this example, the WTRU may send an indication, preferably in the MM message, to the Shared CN CP Function. The indication may inform the Shared CN CP Functions that the message is carrying a SM message and whether the content of the message (i.e., the piggy-backed data) is IP or Non-IP. Using this indication, the Shared CN CP Functions may know which node is to be the actual recipient of the packet. As discussed above, the Shared CN CP Functions may check the integrity of the message first. The ciphering/deciphering may follow the same mechanism as discussed above. One major difference is that both Slice #1and Slice #2may support the SM protocol.

Referring now toFIG.8, a signaling diagram illustrating a dedicated slice selection at a shared CP node is shown. A Shared CP806may provide a WTRU802access to a Dedicated Slice808for a specific service provided by the Dedicated Slice808. The WTRU802may transmit a NAS message810(e.g. registration request) that indicates a request to establish a connection for the specific service. As described above, the NAS message810may include MM messages and SM messages. The NAS message may include a user date type indication that indicates an IP data or non-IP data. A RAN804may have a signaling connection to the Shared CP806, so all communications may go through the Shared CP806. Upon receiving the NAS message810, the Shared CP806may authenticate the WTRU802using authentication function in the shared CP network function (NF) at step812.

If the WTRU802is successfully authenticated, at step814, the Shared CP806may select, based on the user data type indication in the NAS message810, a Dedicated Slice808for the specific service. Upon selecting the Dedicated Slice808, the Shared CP806may determine the type of the NAS message802(e.g. MM and/or SM) based on the user data indication at step816, and read MM messages at step816. The Shared CP806then passes SM messages820to the Dedicated Slice808along with the authentication token at step818. Specifically, the Shared CP NF may read the MM messages and send the SM messages820to the CP of Dedicated Slice808. This means that all MM messages may terminate in the Shard CP NF. However, the SM messages may simply be passed to the dedicated network slices by the Shared CP NF.

Upon receiving the SM message with the authentication token820, the Dedicated Slice808may transmit the SM response message822to the Shared CP806to establish a communication link between the WTRU802and the Dedicated Slice808. The Shared CP806may combine the SM response message822with MM response message, and then send the NAS response message824to the WTRU802.

The Shared CP806may select the Dedicated Slice808based on whether the attached request message is for the transmission of the control plane data or an IP connection. The Shared CP806may provide an authentication token to the selected Dedicated Slice808as an indication of authentication by the Shared CP NF. The Shared CP806may connect the WTRU802to the Dedicated Slice808to provide the specific service. Thus, the control plane of the WTRU802may be connected to the Dedicated Slice808through the Shared CP806.

The following embodiments may include multi-access networks and network slice management. Based on the multi-dimensional descriptor described above, a WTRU may provide a descriptor or template to indicate parameters such as the type of service requested from the network. When the request is received through either a TWAN or an ePDG (hereinafter referred to as a “Non-3GPP Access Gateway” or “N3AGW”), the N3AGW may either perform Slice Selection based on the descriptor, or it may forward the request to a CN Slice Selection Node, such as a Central CP entity or even a 3GPP Access Network entity (e.g., a next generation eNB). This node may be a logical node that can be connected to one or more non-3GPP access points. This node may be pre-configured with information such that it can select the appropriate network slices or nodes to match the WTRU's provided service descriptor. This node may contain a mapping between a service descriptor and a network slice or CP/NF associated with a network slice.

The WTRU may include a SSID, a Network Service ID, or an Application ID that may be used to select a particular N3AGW. The WTRU may use network identifiers that are known or broadcast over the air (e.g., SSID) or through a L2 advertisement protocol (e.g., the Generic Advertisement Protocol of 802.11u) to select an AP that is known to connect to network with a particular service type (and hence slice) to connect to a N3AGW.

The selection of a particular network may allow the WTRU to identify networks that are capable of performing Slice Selection Functions. The WTRU may use an APN to signal to the N3AGW Network Nodes that are capable of performing Network Slice Selection. For example, the information provided by the WTRU may lead to the selection of a particular CP Entity that is capable of performing network slice selection. A WTRU may include the required service descriptor in the L2 MAC frame of a non-3GPP access technology.

The Network Slice Selection function may use parameters provided in the descriptor to determine whether the N3AGW is capable of supporting the services requested by the WTRU. If the N3AGW satisfies the requirements of the particular service specified in the descriptor, a CP Entity may proceeds with the selection of other CN specific functions. This may depend on other aspects of the descriptor as well as aspects of the subscriber information. Otherwise, the CP entity may choose to direct the WTRU to reselect to a different AN (e.g., both 3GPP and Non-3GPP based). The CP entity may choose a particular AN for the WTRU or may instruct the WTRU to perform selection of a new AN altogether.

The following description may address delayed network slice selection. As described above, a shared CP function may contain mobility management functionalities, whereas non-shared CP functions in various slices may contain session management functionalities. Accordingly, when a WTRU initially registers (i.e., attaches) with a network, which is a mobility management event, the WTRU may interact with the shared CP for mobility management. The network may not select the network slice at initial registration if the network does not need to select or use CP functions from the shared CP in different slices.

At the registration phase, however, the network may send information to the WTRU about possible network slices with which the WTRU is authorized to connect. As described above, the shared CP function may send the information about possible network slices based on WTRU capability and/or service type along with subscription information from the subscription database (i.e., similar to HSS). The WTRU may use the information during session management procedures with the network (e.g., PDU connection request).

A network slice may be selected during the session management (SM) procedure, which may include PDU connection establishment. During the SM procedure, the WTRU may include slice information that was previously received during attach procedure. With that network slice information, the WTRU may assist the shared CP function to select a slice or to direct the WTRU's SM request to the appropriate network slice. The network slice selection function may either be part of the RAN or the shared CP function. In either case, the session management may be directed to the appropriate slice.

The network slice selection function may consider the information in the SM message and make a decision to route (re-direct) the message to the network slice that can best meet the WTRU's session requirements. The information may include PDU connection type (IP vs. Non-IP), IP version (IPv4 or IPv6), application information (app ID), required quality of service, the network slice information received during attach/registration procedure, and the like.

Referring now toFIG.9, a diagram illustrating network slice selection when there is a session management request is shown. A PDU connection request may be an example of the SM procedure shown inFIG.9. This procedure may extend to other SM call flows.

At step909, the WTRU902may be attached to a non-shared CP but there is no network slice selected for the shared CP. The WTRU902may send the PDU connection request910to the Shared CP906. The message may include one or more of the following parameters: connection type (IP vs. Non-IP), IP version (IPv4 or IPv6), application information (app ID), required quality of service (including but not limited to QCI value, priority, and required bit rate), the slice information (slice ID, type of slice such as enhance mobile broadband, mIoT, critical communications, etc.), Data Network name (similar to APN), and the like.

Upon receiving the PDU connection request910, the Network Slice Selection Function in the Shared CP906may select a network slice based on the received parameters at step911. Additional parameters may be used with the received parameters. Such additional parameters may include network configuration/local policy, and WTRU/user subscription information, which may either be received by the CP node during the initial attach procedure or during the network slice selection procedure. The Shared CP906may also consider congestion level of the control plane and user plane when it performs the slice selection determination.

The Shared CP906may forward the PDU connection request message912to the CP Slice #1908, which is the non-shared CP function of the selected network slice. The non-shared CP function at the CP Slice1908may execute the SM procedure and set up user plane connection based on the parameters received from the WTRU902at step913. The non-shard CP function may transmit a PDU connection accept message914to the shared CP function at the Shared CP906. After that, the PDU connection accept message916may be forwarded to the WTRU902via interface (similar to NAS) between the shared CP906and the WTRU902.

The PDU connection accept message916may include information about the selected network slice for either the base station or the WTRU902. The base station may route user plane messages to the appropriate network slice. The WTRU902may route the user plane data and other following control message (e.g., SM messages) to the selected network slice at step918. Once the WTRU902is aware of the selected network slice, the data may be sent to the UP functions of the selected network slice.

In an embodiment, multiple network slices may be selected by the Shared CP906if the WTRU902sends another PDU connection request to the shared CP function based on the aforementioned parameters and the characteristics of the required data connection.

Referring now toFIG.10, a diagram illustrating an example procedure for providing access to dedicated network slices in a shared CP network function (NF) is shown. At step1002, the shared CP NF in the shared CP node may receive a NAS message from a WTRU. As described above, the NAS message may include a MM message and a SM message. The MM message may include a registration request that indicates a request to establish a communication link between the WTRU and a dedicated network slice for the specific service that is provided by the dedicated network slice. The NAS message may also include a user data type indication that indicates an Internet Protocol (IP) data and a non-IP data. The non-IP data may include a non-IP Protocol Data Unit (PDU), an Ethernet frame, an Information Centric Network (ICN) data, or the like.

Upon receiving the NAS message, the shared CP NF may initiate an authentication function in the shared CP NF to authenticate the WTRU at step1004. If the WTRU is successfully authenticated, the shared CP NF may generate an authentication token for the security and identity management at step1006. At step1008, the shared CP NF may select a network slice among multiple network slices for a user plane (UP) service provided by the network slice. The shared CP NF may select the network slice based on the user data type indication. The selected network slice may be a dedicated network slice to provide the UP service to the WTRU. At step1010, the shared CP NF may determine a type of NAS message based on the user date type indication included in the NAS message.

After determining the type of NAS message, for example, MM or SM, the shared CP NF may transmit the SM part of the message to the non-shared CP NF in the selected network slice along with the authentication token at step1012. The SM message may indicate the UP service provided by the selected network slice. At step1014, the shared CP NF may receive a SM response message from the non-shared CP NF. The SM response message may indicate whether the selected network slice may provide the UP service or not. If the selected network slice provides the UP service, the shared CP NF may transmit a NAS response message that includes both MM and SM part to the WTRU to establish the communication link between the selected network slice and the WTRU for the UP service. The NAS response message transmitted from the shared CP NF may include the SM response received from the non-shared CP NF.

Although features and elements are described above 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.