WO2018064479A1

WO2018064479A1 - Switching a ran connection with a core network slice

Info

Publication number: WO2018064479A1
Application number: PCT/US2017/054307
Authority: WO
Inventors: Mahmoud Watfa; Guanzhou Wang; Christopher R. Cave; Saad Ahmad; Ulises Olvera-Hernandez
Original assignee: Idac Holdings, Inc.
Priority date: 2016-09-29
Filing date: 2017-09-29
Publication date: 2018-04-05

Abstract

Systems, procedures, and instrumentalities are disclosed for switching a RAN connection with a core network slice A radio access network (RAN) node may receive a first non-access stratum (NAS) message from a wireless transmit/receive unit (WTRU). The first NAS message may comprise information for a requested slice. The RAN node may send the first NAS message to a first common control network function (CCNF)/access and mobility management function (AMF). The RAN node may receive a connection switch request from the first CCNF/AMF. The connection switch request may comprise an address associated with a second CCNF/AMF. The RAN node may send a request to the second CCNF/AMF to serve the WTRU for the requested slice. The RAN node may receive a second NAS message from the second CCNF/AMF. The RAN node may send the second NAS message to the WTRU.

Description

SWITCHING A RAN CONNECTION WITH A CORE NETWORK SLICE

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Patent Application 62/544, 153, filed on August 1 1 , 2017, United States Provisional Patent Application 62/418,557, filed on November 7, 2016, and United States Provisional Patent Application 62/401 ,785, filed on September 29, 2016, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Mobile communications continue to evolve. A fifth generation may be referred to as 5G. A previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).

SUMMARY

[0003] Systems, procedures, and instrumentalities are disclosed for switching a RAN connection with a core network slice. A radio access network (RAN) node may receive a first non-access stratum (NAS) message from a wireless transmit/receive unit (WTRU). The first NAS message may comprise information for a requested slice. The RAN node may send the first NAS message to a first common control network function (CCNF) (e.g., also referred to a access and mobility management function (AMF)). The RAN node may receive a connection switch request from the first CCNF/AMF. The connection switch request may comprise an address associated with a second CCNF/AMF. The RAN node may send a request to the second CCNF/AMF to serve the WTRU for the requested slice. The RAN node may receive a second NAS message from the second AMF. The RAN node may send the second NAS message to the WTRU .

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Furthermore, like reference numerals in the figures indicate like elements, and wherein:

[0005] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented. [0006] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0007] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0008] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0009] FIG. 2 shows an example of initial access by a WTRU.

[0010] FIG. 3 shows an example of a CCNF switch initiated by a RAN .

[001 1] FIG. 4 shows an example of a CCNF switch initiated by a target CCNF.

[0012] FIG. 5 shows an example of an NG2 switch initiated by a RAN with WTRU assistance.

[0013] FIG. 6 shows an example of an NG2 switch initiated by a RAN with WTRU assistance.

[0014] FIG. 7 shows an example of an NG2 switch initiated by a source CCNF and a RAN .

DETAILED DESCRIPTION

[0015] 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.

[0016] FIG. 1 A is a diagram illustrating 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), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0017] As shown in FIG. 1 A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 1 10, and other networks 1 12, 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, any of which may be referred to as a "station" and/or a "STA", may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or i-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0018] The communications systems 100 may also include a base station 114a and/or a base station 1 14b. Each of the base stations 1 14a, 1 14b 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 CN 106/115, the Internet 1 10, and/or the other networks 112. By way of example, the base stations 1 14a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 1 14b are each depicted as a single element, it will be appreciated that the base stations 114a, 1 14b may include any number of interconnected base stations and/or network elements.

[0019] The base station 114a may be part of the RAN 104/113, 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 on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 1 14a may be divided into three sectors. Thus, in one embodiment, the base station 1 14a may include three transceivers, i .e., one for each sector of the cell . In an embodiment, the base station 114a may employ multiple-input multiple output (M IMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.

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

[0021] 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 1 14a in the RAN 104/113 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 1 15/1 16/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 (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).

[0022] In an embodiment, the base station 1 14a 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 1 16 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).

[0023] In an embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).

[0024] In an embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., a eNB and a gNB).

[0025] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i .e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1 X, 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.

[0026] The base station 1 14b 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, an industrial facility, an air corridor (e.g. , for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.1 1 to establish a wireless local area network (WLAN). In an 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 1 14b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g. , WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 1 14b may have a direct connection to the Internet 1 10. Thus, the base station 1 14b may not be required to access the Internet 1 10 via the CN 106/1 15.

[0027] The RAN 104/1 13 may be in communication with the CN 106/1 15, 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. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/1 15 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. 1A, it will be appreciated that the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/1 13 or a different RAT. For example, in addition to being connected to the RAN 104/1 13, which may be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0028] The CN 106/1 15 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 1 10, and/or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS). The Internet 1 10 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/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 1 12 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/1 13 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., 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. [0030] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, 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/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0031] The processor 1 18 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 Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 1 18 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 1 18 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip.

[0032] 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 1 16. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an 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/or 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.

[0033] Although the transmit/receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ M IMO 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 1 16.

[0034] 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 NR and IEEE 802.11 , for example. [0035] The processor 1 18 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 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 1 18 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 1 18 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).

[0036] The processor 1 18 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.

[0037] The processor 1 18 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 1 16 from a base station (e.g., base stations 1 14a, 1 14b) 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.

[0038] The processor 1 18 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 and/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, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor. [0039] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g. , for reception) may be concurrent and/or simultaneous. The full duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 1 18). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g. , associated with particular subframes for either the UL (e.g. , for transmission) or the downlink (e.g. , for reception)).

[0040] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 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 1 16. The RAN 104 may also be in communication with the CN 106.

[0041] 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 1 16. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement M IMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0042] 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 UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

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

[0044] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 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 provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

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

[0046] The SGW 164 may be connected to the PGW 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.

[0047] The CN 106 may facilitate communications with other networks. For example, the CN 106 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 CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0048] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g. , temporarily or permanently) wired communication interfaces with the communication network.

[0049] In representative embodiments, the other network 112 may be a WLAN.

[0050] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11 e DLS or an 802.1 1 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad- hoc" mode of communication.

[0051] When using the 802.1 1 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width {e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.1 1 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0052] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel .

[0053] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 M Hz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0054] Sub 1 GHz modes of operation are supported by 802.11 af and 802.1 1 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.1 1 ah relative to those used in 802.11 η, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.1 1 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.1 1 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g. , only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g. , to maintain a very long battery life).

[0055] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 η, 802.11 ac, 802.11 af, and 802.1 1 ah, include a channel which may be designated as the primary channel . The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.1 1 ah, the primary channel may be 1 MHz wide for ST As (e.g. , MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 M Hz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0056] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.1 1 ah is 6 MHz to 26 MHz depending on the country code.

[0057] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 1 15 according to an embodiment. As noted above, the RAN 1 13 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 16. The RAN 113 may also be in communication with the CN 115.

[0058] The RAN 1 13 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 1 13 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16. In one embodiment, the gNBs 180a, 180b, 180c may implement M IMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

[0059] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time). [0060] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0061] Each of the gNBs 180a, 180b, 180c 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 UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0062] The CN 1 15 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SM F) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 1 15, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0063] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AM F 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and/or the like. The A F 162 may provide a control plane function for switching between the RAN 1 13 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

[0064] The SMF 183a, 183b may be connected to an AM F 182a, 182b in the CN 115 via an N 1 1 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet- based, and the like.

[0065] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0066] The CN 1 15 may facilitate communications with other networks. For example, the CN 1 15 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 1 15 and the PSTN 108. In addition, the CN 1 15 may provide the WTRUs 102a, 102b, 102c with access to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0067] In view of Figures 1 A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 1 14a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SM F 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0068] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.

[0069] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g. , which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0070] FIG. 2 is an example of initial access by a WTRU. Slicing may be performed, for example, based on assistance information provided by a WTRU to a RAN. A RAN may use the information to route the WTRU's non-access stratum (NAS) message to the appropriate network slice. A network slice may (or may not) have common control plane (CP) network functions, which may be referred to as CCNF. A CCNF may be responsible to select other CN CP functions that may reside behind the CCNF, which (e.g. , together with the CCNF and the RAN) may make up a network slice. Thus, the CCNF may be a control function that performs one or more procedures related to network slice selection and/or configuration of a network slice for one or more WTRUs. A CCNF may also be referred to equivalently as an Access and mobility management function (AMF). The terms CCNF and AMF may be used interchangeably in this document and examples described with respect to a CCNF may be equally applicable to an AMF and vice versa.

[0071] A WTRU may attempt to register with a network. WTRU assistance information (e.g. , multidimensional descriptor (MDD)) included in a registration message or the lack of assistance information may cause a WTRU's NAS message to be forwarded to a default CCNF/AMF. A CCNF/AMF node that receives slice assistance information for a WTRU may determine that the WTRU should be served by another CCNF/AMF and may (e.g. , therefore) forward the WTRU's message to a serving CCNF/AMF. The term MDD may refer to the network slice selection assistance information provided to and/or from a WTRU to a CCNF/AMF.

[0072] An example of this procedure is shown in FIG. 2. At 202, a WTRU may send an attach request, which may include the IMS I, for example, when a Temporary ID for the WTRU may not be available.

[0073] A WTRU may request one or a set of Network Slice Instance(s) (NSIs) to be allocated for use by the WTRU (e.g. , initially). A WTRU may do so, for example, by including a Requested MDD in an Attach Request. The Requested MDD may indicate one or more network slices that the WTRU is requesting be assigned/allocated for use to the WTRU . A Requested MDD may (e.g. , also) be included in an RRC layer, e.g. , to further enhance the routing to an initial default/target CCNF/AMF of the NAS message, e.g. Attach Request message, for example, when the Temporary ID may not be available to the WTRU or the Temporary ID may not have assigned by the same PLMN of the current network that may serve the WTRU . An MDD in an RRC layer may (e.g., also) be included, e.g. , to enable access to a suitable RAN resources. A RAN may maintain an MDD-based table, for example, to route/forward an attach request message to a (e.g., proper) CCNF/AMF, for example, when the Temp ID may be missing.

[0074] A WTRU may include a temporary ID (e.g., when it may be available) in an RRC layer message that may be used to establish the RRC connection, for example, so that the RAN may route the message to the CCNF/AMF in the core that may have generated or allocated it.

[0075] At 204, a RAN may forward an Attach Request to a Core node, for example, based on one or more routing criteria (e.g., as described herein). At 206, a CCNF/AMF may proceed with procedures for 3GPP system authentication and authorization for the WTRU .

[0076] At 208, a WTRU may be successfully authenticated. WTRU subscription data may be checked. Allowed MDD vectors may be determined (e.g. , which may form the Accepted MDD that may be returned to the WTRU in the Attach Accept). Compatibility of one or more CCNFs/AMFs for the slices indicated by MDD vectors may be determined to ensure that a CCNF/AMF capable of serving the accepted slices is properly assigned to the WTRU.

[0077] A procedure may proceed with CCNF/AMF redirection (e.g. , at 210) without binding of NSIs to MDD vectors occurring in this CCNF/AMF, for example, when the CCNF/AMF may detect that it is not an appropriate handler for the WTRU .

[0078] A CCNF/AMF (e.g. , that may be an appropriate handler for a WTRU) may decide an initial set of NSI(s) for a WTRU, e.g., based on an evaluation of one or more of a Requested MDD, Subscribed MDD (e.g., when available), WTRU capabilities, WTRU's subscription policy, WTRU's serving RAN type, etc. A network may assign a WTRU to the default NSI(s), for example, when the WTRU did not provide the Requested MDD. The network may assign the WTRU to the NSI(s) for which the WTRU may be authorized, for example, when the WTRU did provide the Requested MDD. The WTRU may (e.g., still) be assigned to these NSI(s) and the corresponding MDD vector(s) may be added in the Accepted MDD, for example, when one or more Default NSI(s) were missing from the requested MDD. An Accepted MDD may be passed to the WTRU in the Attach Accept message. Mapping of DNNs to MDD vectors may be recorded in the WTRU context in the CCNF/AMF, for example, when one or more DNNs may be specific to one or more MDD vectors (e.g., based on subscription data). The procedure may proceed, for example, to 216, at which the Serving CCNF/AMF may send to the RAN the Attach Accept, for example, in an NAS message.

[0079] At 210, a (e.g., default/target) CCNF/AMF may redirect a WTRU to a Serving CCNF/AMF that may be more optimal (or less loaded) for the selected slices, for example, when the WTRU is not suitably handled by the (e.g., Default/Target) CCNF/AMF where the Attach Request was routed to. A (e.g., Default/Target) CCNF/AMF may forward the attach request to a Serving CCNF/AMF with an indication that it is a forwarded attach request. The CCNF/AM F may also provide other information to the new Serving CCNF/AM F, such as an IMSI, MM context including the NAS key and Accepted MDD (which may have been determined to evaluate CCNF/AMF compatibility at 208), for example, to indicate that the WTRU may have been authenticated for NSI(s) Assignment (e.g., at 208).

[0080] At 212, the Selected Serving CCNF/AMF may perform the NSI selection (e.g., as described in connection with 208). At 214, a Selected Serving CCNF/AMF may bind the WTRU to the selected NSI(s), for example, by creating a related context associating the Accepted MDD vectors to the NSI(s) for the WTRU and may send back the Forwarded Attach Accept message with Temporary ID and Accepted MDD for subsequent usage by the WTRU. Mapping may be passed to the WTRU, for example, when there may be one or more DNNs that may be specific to one or more MDD vectors.

[0081] At 216, the Serving CCNF/AMF may (e.g., in connection with 210, 212, and/or 214) send to the RAN the Attach Accept, for example, in an NAS message, which may include the content as described in the message in connection with 214. The Default/Target CCNF/AMF, which may now be the Serving CCNF/AMF, may (e.g., otherwise) bind the WTRU to the selected NSI(s), for example, by creating a related context that may associate the Accepted MDD vectors with the NSI(s) and/or may send an Attach Accept message with Temporary ID and the Accepted DD for usage by the WTRU and any DNN to DD vector mappings. The Serving CCNF/AMF may include the Accepted MDD in the NG2 transport.

[0082] At 218, the RAN may forward the Attach Accept received in connection with 214 and/or 216 to the WTRU . An Attach Request may include an SM container, e.g., so that PDU sessions may be established for all or a subset of Active NSIs for a WTRU. A subsequent SM message exchange may (e.g., alternatively) be used to establish PDU sessions for the NSIs that may use or need these.

[0083] A default CCNF/AMF (e.g., as indicated in connection with 206) may (e.g., first) attempt to serve a WTRU. The default CCNF/AMF may forward the WTRU's NAS message to another CCNF/AMF that may be more suitable to serve the WTRU (e.g., in connection with 210). A WTRU may be considered registered with a target CCNF/AMF (e.g., at 210).

[0084] An interface between the RAN and the core network (CN), e.g., CCNF/AM F, may be implemented. A RAN node may have a signaling connection (e.g., over an NG2 reference point) with a default CCNF/AMF, e.g., even after the WTRU's NAS message may be forwarded and processed by a serving CCNF/AMF. The RAN may forward the message over to the default CCNF/AM F, for example, when the WTRU sends an NAS message, given that the NG2 signaling connection may be between the RAN and the default CCNF/AMF.

[0085] An NG2 connection between a RAN and a serving CCNF/AMF (e.g., the CN node that may actually serve the WTRU) may be switched .

[0086] Network slicing may be performed to provide dedicated core network interworking capabilities. 5G networks may provide tailored networking capabilities based on different user demands, including support for vertical applications and more general on-demand support for a multiplicity of services that may include, for example, enhanced mobile broadband, ultra-reliable communication, and critical communication, among others. This on-demand networking capability may be addressed through network slicing. Network slicing may enable the mobile network operator to provide (e.g., bespoke) network capabilities to satisfy a particular service. In dedicated core networks, network operators may assign WTRUs to networks matching a particular usage type, where a WTRU may be connected to a dedicated core network at a time.

[0087] A WTRU may move between two networks with different capabilities. For example, the WTRU may move between a network that supports dedicated core network functionality and a network that support network slicing capabilities. Network slices and/or network slice instances may be mapped to dedicated one or more core networks and/or one or more types of core network nodes. A dedicated core network may map to a network slice instance or a set of network slice instances. When a single network slice instance may be mapped to a dedicated core network, a network slice instance may be selected among multiple network slice instances.

[0088] A RAN may have an NG2 signaling connection with the wrong CN node (e.g. , the wrong CCNF/AMF). This may arise, for example, when a source (e.g., default) CCNF/AMF may forward a WTRU's NAS message to a serving CCNF/AMF transparently (e.g., without the RAN knowing about it). A RAN's NG2 connection may be switched from a source CCNF/AMF to a serving CCNF/AMF. The switch may be performed, for example, by one or more of the source CCNF/AMF and/or the serving CCNF/AMF. A switch may (e.g., also) involve the RAN. An NG2 connection may exist between the RAN and the actual CCNF/AMF that may be serving the WTRU (e.g., the serving CCNF/AMF). A NAS message from the WTRU may be forwarded to the correct CCNF/AM F via the appropriate NG2 connection .

[0089] A WTRU may use NAS level indications to inform the RAN about the change of the

CCNF/AMF. The RAN may use this indication from the WTRU, for example, to establish a connection with a target CCNF/AM F and release the previous connection with a first CCNF/AM F. [0090] FIG. 3 illustrates an example of a RAN initiating a CCNF/AMF switch . A CCNF/AMF switch may be initiated by a RAN . A source CCNF/AMF may trigger a switch of an NG2 signaling connection so that the RAN may connect to the serving CCNF/AMF.

[0091] A source CCNF/AMF may take one or more actions to switch an NG2 connection so that the RAN may connect to the serving CCNF/AMF.

[0092] A source CCNF/AMF may generate a random sequence number (RSN) that may be associated with (e.g., unique for) a WTRU . At 310, the source CCNF/AMF may send the generated RSN to the serving CCNF/AMF, e.g., as part of a message that may be used to forward the attach message to the serving CCNF/AMF. The source CCNF/AMF may (e.g., also) include the address of the RAN node that may be currently serving a WTRU .

[0093] At 314, the source CCNF/AMF may send a message, e.g., an NG2 Connection Switch Request message, to the RAN node. The source CCNF/AMF may include the same RSN that may have been sent to the serving CCNF/AM F. The source CCNF/AMF may (e.g. , also) include the address of a network function (e.g., the core network CP node that may be in the serving CCNF/AMF). This may be, for example, the address of an (e.g., any) NF that may reside in the serving CCNF/AMF or it may be the address of a routing function that may connect or may route to the CCNF/AMF or the NF that may process the WTRU's attach message (e.g. , to which the WTRU's attach message may have been forwarded by the source CCNF/AMF). The source CCNF/AMF may start a timer, for example, after sending the message to the RAN node. The timer may guard the end of the procedure. The timer may be stopped, for example, by the source CCNF/AMF, e.g., when a response may be received from the RAN node. The timer may expire before receiving a response. The source CCNF/AMF may (e.g., when the timer expires before receiving a response) re-initiate the procedure or may release the NG2 connection that may already be established with the RAN node

[0094] A RAN may engage in behavior (e.g. , take one or more actions) in support of switching an NG2 connection from a source CCNF/AMF to a serving CCNF/AMF.

[0095] At 314, a RAN node may receive a request (e.g., from a source CCNF/AMF) to switch an NG2 connection from one CCNF/AMF to another. The request may contain one or more of an RSN and/or CP NF address. The RAN node may (e.g., immediately) acknowledge receipt of the request at 316, for example, by sending an acknowledgement message, e.g., an NG2 Connection Switch Acknowledge message, to the source CCNF/AMF.

[0096] At 318, the RAN node may generate a (e.g., dummy) NAS message, which may be an empty container. The RAN node may send a request to establish (e.g. , and switch) an NG2 connection with a target CCNF/AMF whose address may have been previously received from a source CCNF/AMF. The RAN may include the dummy NAS message and an RSN . The RAN node may start a timer, e.g., after sending the message. The timer may guard the end of the procedure. The timer may be stopped (e.g., by the RAN), for example, when a response may be received from the serving or target CCNF/AMF. The RAN may reinitiate the procedure or may abort the procedure, for example, when the timer expires before receiving a response.

[0097] At 320, the RAN node may receive a response to the message sent. The RAN may stop a timer that may be associated with this procedure. The RAN may verify whether an RSN in the message corresponds to a previous RSN that may have been sent by the RAN towards the serving CCNF/AMF. The RAN may update its context for the NG2 connection that may be associated with the WTRU, for example, when the RSN matches. The RAN may verify the response to determine whether an NAS message may be included. The RAN may forward the NAS message to the WTRU, for example, when the NAS message was included.

[0098] A serving CCNF/AMF node may engage in behavior (e.g., take one or more actions).

[0099] At 310, the serving CCNF/AMF may receive (e.g., from a default or target CCNF/AMF) an NAS message for a WTRU (e.g. , in a Forward Attach Request message). The serving CCNF/AM F may save the RSN that may be included in the message and may (e.g., also) save the RAN address, e.g., as part of the WTRU context.

[0100] The serving CCNF/AMF may start a timer to guard a period during which a message may be expected to be received from a RAN node.

[0101] At 318, the serving CCNF/AMF may receive a message from a RAN node, e.g. , to establish an NG2 connection for a WTRU. The serving CCNF/AMF may stop a timer, for example, when such a message may be received. The serving CCNF/AMF may verify whether an RSN may be included in the message and whether it matches an RSN that may have been (e.g., previously) received from a source CCNF/AMF for the WTRU in question. The serving CCNF/AMF may (e.g., also) verify whether the RAN address received from the source CCNF/AM F matches that of the RAN node that may be communicating with it. The serving CCNF/AMF may update the WTRU's context or the context of the NG2 connection associated with the WTRU and the RAN, for example, when at least the RSN matches.

[0102] At 320, the serving CCNF/AMF may send a response message to the RAN node, e.g., to acknowledge the establishment of the NG2 connection. The serving CCNF/AMF may send an NAS message to the RAN node, e.g. , over an NG2 message. The NAS message may be forwarded to the WTRU, e.g. , by the RAN . The CCNF/AMF may send the NAS message as part of the NG2 message. The CCNF/AMF may send the NAS message in another NG2 message.

[0103] FIG. 4 illustrates an example of a target CCNF/AMF initiating a CCNF/AMF switch. For example, a serving CCNF/AMF may initiate switching of an NG2 connection .

[0104] The behavior of a source CCNF/AMF may be, for example, as described herein. [0105] At 410, a serving CCNF/AMF node may receive (e.g., from a default or target CCNF/AMF) an NAS message for a WTRU (e.g., in a Forward Attach Request message). The serving CCNF/AMF node may save the RSN that may be included in the message and may (e.g., also) save the RAN address, e.g. , as part of a WTRU context. At 412, the Serving CCNF/AMF may perform NSI selection based on the Attach Requests forward from the Default/Target CCNF/AMF. At 414, the Default/Target CCNF/AMF may send an NG2 Connection Switch Request to the RAN.

[0106] At 416, the serving CCNF/AMF may send an NG2 message to a RAN node, e.g. , to switch a connection from a source CCNF/AMF to the serving CCNF/AMF. The serving CCNF/AMF may include an RSN in the message. The RSN may have been previously received from a source CCNF/AMF, e.g., as part of a Forward Attach Request message or other (e.g., equivalent) message. The message may be called, for example, an NG2 Connection Switch Request. The serving CCNF/AMF may start a timer, for example, to guard when a response may be received from the RAN .

[0107] The serving CCNF/AMF may (e.g., also) include an NAS message that may be intended for the WTRU . The NAS message may be included in the same message that may be sent, e.g., as described herein.

[0108] At 418, the serving CCNF/AMF may receive a response message from the RAN node (e.g. , an NG2 Connection Switch Response). The serving CCNF/AMF may stop a timer associated with the procedure. The timer may have been started, for example, when the serving CCNF/AMF sent a switch request message to the RAN, e.g., as described herein .

[0109] At 422, the CCNF/AMF may send an NAS message over the established NG2 interface towards the RAN. The NAS message may be intended for the WTRU, e.g., and may be sent to the WTRU at 424.

[01 10] A RAN node may engage in one or more actions related to a CCNF/AMF switch that may be initiated by a target CCNF/AMF (e.g., serving CCNF/AMF).

[01 11 ] At 414, a RAN node may receive a request, e.g., from a source CCNF/AMF, to switch an NG2 connection from one CCNF/AMF to another. The request may contain one or more of an RSN and/or CP NF address. The RAN node may (e.g., immediately) acknowledge receipt of the request, for example, by sending an acknowledgement message to the source CCNF/AMF at 420. The message may be called, for example, an NG2 Connection Switch Acknowledge.

[01 12] The RAN node may start a timer, e.g., to guard a period during which a message may be expected to be received from a RAN node.

[01 13] At 416, the RAN node may receive a request from a serving CCNF/AMF, for example, to establish (or switch) an NG2 connection that may be associated with a WTRU. The message may be called, for example, an NG2 Connection Switch Request. The message may contain one or more of an RSN and/or a CN CP NF address. The RAN node may check for a match, e.g., at least between the RSN in the message and an RSN that may have been received from a source CCNF/AMF. The RAN node may stop a timer (e.g., which may have been previously started as described herein), for example, when there may be a match or (e.g., optionally) when the CN NF CP address may match. The RAN node may update its NG2 connection context accordingly. The RAN node may send an acknowledgement message to the serving CCNF/AMF at 418.

[01 14] At 420, the RAN may (e.g. , also) send an acknowledgement message to the source

CCNF/AMF, for example, to confirm completion of a switch of the NG2 connection. The RAN node may release its connection with the source CCNF/AMF.

[01 15] At 424, the RAN may forward the NAS message to the WTRU, for example, when the NG2 Connection Switch Request or other (e.g. , equivalent) message may contain an NAS message for the WTRU .

[01 16] Although examples may be recited in an order, other examples or implementations may implement other orders and may omit described actions and/or add other actions that may not be described in examples herein .

[01 17] FIG. 5 illustrates an example of a RAN, with WTRU assistance, initiating or triggering an NG2 switch.

[01 18] A WTRU's connection may be released, for example, so the WTRU may start another connection, e.g., using an NAS Temp ID that may point to a serving CCNF/AMF. The RAN may send an NAS message to the CCNF/AMF. The connection may be released. Risk may be reduced or removed for subsequent messages that may come from the WTRU while the RAN may have an NG2 connection with the source CCNF/AMF.

[01 19] A source CCNF/AMF may engage in behavior (e.g. , one or more actions) for a switch initiated by the RAN with WTRU assistance.

[0120] At 514 and 516, the source CCNF/AMF may send a NAS message, such as an Attach Accept that may be generated by the serving CCNF/AMF (e.g., as discussed herein in connection with FIG. 2), in the NG2 signaling towards the RAN. The source CCNF/AMF may (e.g., also) include an indicator for the RAN to release the WTRU's radio connection . The source CCNF/AMF may (e.g., also) include a NAS release indicator that may be forwarded to the WTRU in the RRC message. The serving or source CCNF/AMF may include a NAS release indicator as part of an NAS message (e.g. , the Attach Accept). The NAS release indicator may (e.g. , also) be an indicator that may inform the WTRU about a CCNF/AMF change in the CN . This may help the WTRU take other actions (e.g., described herein).

[0121] A RAN may engage in behavior (e.g. , one or more actions) for a switch initiated by the RAN with WTRU assistance. [0122] At 516, the RAN node may receive an NG2 message that may include an NAS container and (e.g., at least) an indicator to release the WTRU's radio connection . The RAN may forward the NAS message to the WTRU at 518.

[0123] The RAN node may (e.g. , immediately) release the WTRU's radio connection (e.g. , after receiving an acknowledgement from the radio protocol in the WTRU that may confirm receipt of the NAS message over a radio message). The RAN may (e.g. , also) send a radio release message that may include the NAS message at 522.

[0124] The RAN may (e.g. , also) include an NAS release indicator in the radio message, e.g., the radio release message, that may be sent to the WTRU. The RAN may release the WTRU's connection and the NG2 connection for the WTRU and may release or discard the WTRU's context.

[0125] A WTRU may engage in behavior (e.g., one or more actions) for a switch initiated by the RAN with WTRU assistance.

[0126] At 518, the WTRU may receive an NAS message that may include a NAS release indicator. The WTRU may (e.g. , also) receive an NAS release indicator from the RAN node over a radio protocol message.

[0127] At 520, the WTRU may consider itself to be in NAS idle state, for example, even when the radio connection may still be running.

[0128] The WTRU may wait for its RRC or radio connection to be released.

[0129] The WTRU may (e.g. , alternatively) start a well-known or signaled timer (e.g., in the NAS message or radio message). The timer may expire. The WTRU may (e.g., autonomously) enter NAS idle or

RRC idle (e.g. , the WTRU may consider itself to be in idle state with regard to the radio protocol) or the

WTRU may consider itself to be both NAS and RRC idle (e.g. , idle at the NAS and radio levels).

[0130] At 524, the WTRU may initiate a new NAS connection, for example, using the Temp ID that may be received in the last Attach Accept of an NAS Accept message.

[0131 ] FIG. 6 is an example of an NG2 switch initiated by a RAN with WTRU assistance.

[0132] An NG2 switch may be initiated by a RAN with WTRU assistance. This example may be an alternative to the previous example shown in FIG. 5.

[0133] A WTRU may engage in behavior (e.g., one or more actions) for a switch initiated by the RAN with WTRU assistance.

[0134] At 620, the WTRU may verify whether a NAS release indicator (which may also be an indicator that the CN CP function or the CCNF/AMF may have changed) is received in the NAS or radio message at 618. At 622, the WTRU may (e.g., when the NAS indicator is received) send an RRC message, which may contain an NAS message, to the RAN node. The WTRU may include an indication that the CCNF/AMF (or the CN node or the CN CP NF) may have changed. The WTRU may (e.g., also) include its NAS Temp ID that may point to a new CCNF/AMF.

[0135] A RAN may engage in behavior (e.g., one or more actions) for a switch initiated by the RAN with WTRU assistance.

[0136] The RAN may receive a message from the WTRU at 622. The RAN may verify whether the message contains an indication about a CN node change. At 624, the RAN may (e.g., when the message contains an indication of a CN node change) use the included NAS Temp ID of the WTRU to determine a new CCNF/AMF that may serve the WTRU.

[0137] The RAN may update the NG2 context for this WTRU accordingly (e.g., with the new CN CP NF or new serving CCNF/AMF address).

[0138] At 626, the RAN may forward the NAS message to the serving CCNF/AMF, e.g., as determined from the WTRU's NAS Temp ID.

[0139] The RAN may send an NG2 connection release request to a source CCNF/AM F at 628. The source CCNF/AMF may (e.g., also) send an NG2 release request to the RAN. The RAN may respond to the message.

[0140] FIG. 7 illustrates an example of an NG2 switch that may be initiated by a source CCNF/AMF and the RAN . This may reduce or minimize messages between the CN nodes and the RAN. The Attach Accept may (e.g., still be) forwarded from the serving CCNF/AMF to the source CCNF/AMF. The source CCNF/AMF may send the message to the RAN, for example, as described herein with respect to FIG. 2. The source CCNF/AM F, e.g., as part of sending the NAS message to the RAN, may (e.g., also) include the random sequence ID and the CCNF/AMF address.

[0141 ] The NG2 connection may be switched so that the RAN may connect to the serving

CCNF/AMF.

[0142] A source CCNF/AMF may engage in behavior (e.g., one or more actions) for an NG2 switch initiated by a source CCNF/AMF and a RAN.

[0143] A source CCNF/AMF may generate a random sequence number (RSN) that may be unique for the WTRU . The source CCNF/AMF may send the generated RSN to the serving CCNF/AMF at 710, e.g., as part of the message that may be used to forward the attach message to the serving CCNF/AMF. The source CCNF/AMF may (e.g., also) include the address of the RAN node that may be currently serving the WTRU .

[0144] At 714, the source CCNF/AMF may receive the Attach Accept from the serving CCNF/AMF. The source CCNF/AMF may send the Attach Accept over an existing NG2 connection with the RAN at 716. The source CCNF/AMF may include the (e.g., same) RSN that may have been sent to the serving CCNF/AMF, e.g. , as described herein. The source CCNF/AMF may (e.g., also) include the address of the network function (e.g., the core network CP node that may be in the serving CCNF/AMF).

[0145] The source CCNF/AMF may release its connection with the RAN node.

[0146] A RAN node may engage in behavior {e.g. , one or more actions) for an NG2 switch initiated by a source CCNF/AMF and the RAN.

[0147] The RAN may receive the NAS message from the source CCNF/AMF at 716. The RAN may verify whether there is an RSN and a new CCNF/AMF address. At 718, the RAN may (e.g., when there is an RSN and new CCNF/AMF address) update the NG2 context accordingly, for example, so that it points to the new CCNF/AMF. The RAN may acknowledge the message, for example, by sending an

acknowledgement to the source CCNF/AMF. The RAN may release its connection with the source CCNF/AMF. The RAN may maintain the RRC connection with the WTRU.

[0148] The RAN may forward the NAS message to the WTRU at 720.

[0149] The RAN may start a timer, for example, with a configured value or length (e.g., as indicated by the source CCNF/AM F in the first message). The RAN may release the WTRU's radio connection, for example, when the timer expires without receiving an NAS message from the WTRU .

[0150] At 722, the RAN may receive an NAS message from the WTRU while the timer is still running or may receive an NAS message without ever starting a timer. The RAN may use the updated NG2 connection information to send the NAS message to the serving CCNF/AMF at 724. The RAN may include the RSN that may have been received from the source CCNF/AMF in the NG2 message towards the serving CCNF/AMF.

[0151] A serving CCNF/AMF node may engage in behavior (e.g., one or more actions) for an NG2 switch initiated by a source CCNF/AMF and the RAN.

[0152] At 710, the serving CCNF/AMF may receive (e.g., from a first CCNF/AMF, such as a default or target CCNF/AMF) an NAS message for a WTRU (e.g., in a Forward Attach Request message). The serving CCNF/AMF may save the RSN that may be included in the message and may (e.g., also) save the RAN address, e.g., as part of a WTRU context.

[0153] The serving CCNF/AMF may start a timer to guard a period during which a message may be expected to be received from a RAN node.

[0154] At 724, the serving CCNF/AMF may receive a message from a RAN node, e.g. , to establish an NG2 connection for a WTRU. The serving CCNF/AMF may stop a timer, for example, when the message is received. The serving CCNF/AM F may verify whether an RSN may be included in the message and whether it matches an RSN that may have been previously received from a source CCNF/AMF for the WTRU in question. The serving CCNF/AM F may (e.g. , also) verify whether the RAN address received from the source CCNF/AMF matches that of a RAN node that may be communicating with it. The serving CCNF/AMF may (e.g., when at least the RSN matches) update the WTRU's context or the context of the NG2 connection that may be associated with the WTRU and the RAN.

[0155] At 726, the serving CCNF/AMF may send a response message to the RAN node to acknowledge the establishment of the NG2 connection.

[0156] The serving CCNF/AMF may send an NAS message to the RAN node, e.g., over an NG2 message. The NAS message may be forwarded to the WTRU by the RAN at 728. The CCNF/AMF may send the NAS message, for example, as part of the previous NG2 message or in another NG2 message.

[0157] Ordering or sequencing (e.g. , of messages or other interactions) presented in examples may be different in other examples or implementations. The number and type of nodes presented in examples may be different in other examples and implementations. Actions (e.g., messages) may occur sequentially and/or in parallel.

[0158] The source CCNF/AMF may send the same RSN to a RAN and to a serving CCNF/AMF. The source CCNF/AMF may generate a pair of (e.g., different) RSNs. One of the values may indicate what a RAN node may use when it contacts a serving CCNF/AMF. The other value may indicate what the CCNF/AMF may use when it contacts the RAN node. The source CCNF/AMF may generate a pair of RSNs and may send them, for example, to the RAN node and/or to the serving CCNF/AMF node.

[0159] The source CCNF/AMF may send an RSN pair to the RAN . The RAN may use one of the RSN to send to the serving CCNF/AMF. The other value may be used by the RAN to compare with an RSN that may be received from the serving CCNF/AMF.

[0160] The source CCNF/AMF may send an RSN pair to the serving CCNF/AMF. The serving

CCNF/AMF may use one of the RSNs to send to the RAN. The other value may be used by the serving

CCNF/AMF to compare with an RSN that may be received from the serving RAN.

[0161] The pair of RSNs may allow the RAN and the serving CCNF/AMF to mutually authenticate each other or to ensure that they are the right entities that should serve the WTRU in question .

[0162] Any whole or partial combination of signaling and/or examples may be used to develop another sequence of messages for the same or similar purpose.

[0163] Systems, procedures, and instrumentalities have been disclosed for switching a RAN connection with a core network slice. A source CN slice (e.g., source CCNF/AMF) may initiate a switch of a RAN connection, for example, by generating random sequences and forwarding them to the RAN and a target CN slice. A RAN and target CN slice may communicate with each other to establish a connection for a WTRU in question, e.g., to switch an old connection from the RAN and the source CCNF/AMF). A RAN and target CCNF/AMF may use received sequences to identify a connection associated with a WTRU. A WTRU may use a NAS release indicator or a CCNF/AMF change indicator to send a radio message to a RAN, e.g., to inform the RAN about a change to a WTRU's CN slice. A RAN may use a CN change indicator from a WTRU, for example, to determine a new or target CCNF/AMF with which the RAN may establish a connection for the WTRU in question .

[0164] Handover from a network slicing (NS) capable network to a dedicated core network (DCN) capable network may be performed. The CCNF/AMF providing the logical common portion of the slice instances allocated to the WTRU may house the mobility management function (MMF). The MMF may execute the handover towards the DCN . Prior to executing the handover operation, the MMF within the CCNF/AMF may map slice-specific parameter(s) into DCN-specific parameter(s). The mapping may be performed such that the level of service provided by the slice may be maintained. For example, in order to select an appropriate DCN during handover, the one or more parameters may be mapped prior to executing a relocation request (or a 5G equivalent message). A temporary ID used to select the

CCNF/AMF may be mapped to a globally unique temporary identity (GUTI). The tenant ID may be mapped to the access point name (APN). The service descriptor may be mapped to the usage type. Upon receipt of the relocation Request command (possibly over the interface defined between CCNF/AMF and the EPC MM E), the MME executes SGW and PGW selection functions to allocate appropriate SGW and PGW or a combined SGW/PGW based on the APN and usage type provided by the CCNF/AMF. Separate usage type-APN pairs may lead to the selection of different PGW or SGW/PGW pairs matching the network slicing instance (NSI).

[0165] The CCNF/AMF may derive DCN ID using the inputs described herein before or during the handover procedure. The DCN ID may be sent to the WTRU during the handover by the CCNF/AMF (e.g., over the NG1 interface or RRC message) by the RAN node. RAN may receive the DCN ID by the CCNF/AMF via NG2 interface. The WTRU may include that DCN ID in the initial NAS message (e.g. Attach Request or Tracking Area Update request) to the EPC system. The EPC system may select the appropriate DCN based on the received DCN ID from the WTRU.

[0166] When the WTRU performs registration or a tracking area update (TAU) for the WTRU-based mobility scenario (e.g., idle mode mobility) from NS capable network to EPC network, the WTRU may include the DCN ID of the dedicated core network that the WTRU wants to register to in the NAS message (registration or TAU). The WTRU may be configured with and/or provisioned with a list of DCN IDs by the network corresponding to each network slice ID [e.g., MDD or network slice selection assistance information (NSSAI)). The WTRU may select the one or more DCN IDs from the list. The selection may be based on one or more of the PLMN ID of the target EPC operator. For example, the EPC network may be from a different PLMN than the Next Gen network. The WTRU may select the DCN ID(s) based on whether the WTRU was connected to single slice or multiple slices before in the Next Gen system . A different DCN ID may be included by the WTRU for each of these cases. The inclusion of a specific/different slice ID for the scenario when the WTRU was connected to multiple slices in the Next Gen system or (5G Core Network) may enable the network to select the dedicated core network (DCN) in the EPC that may best meet the requirements of multiple network slices.

[0167] While the WTRU is attached to the Next Gen system, the CP-Function (e.g., Mobility management function or AMF) in the Next Gen system may provide the WTRU with the DCN ID to prepare for the case if the WTRU moves to the EPC system. The DCN ID may be included in an attach accept message sent to the WTRU, a tracking area update accept message sent to the WTRU, a SM message sent to the WTRU, or any other message exchanged over the NG1 interface. The Next Gen network may update the provided DCN ID during the time the WTRU is attached to the Next Gen system. The DCN ID may be updated by the network when the WTRU connects to multiple slices, changes tenants or PLMNs or is moved from one CCNF/AMF to another CCNF/AMF node as an example. When the WTRU connects to the EPC network, the WTRU may include the latest DCN ID received from the network.

[0168] The WTRU may include an indication of the connection to multiple slices in the NAS message to the M ME. This indication may include an inclusion of NSSAI or MDD of every network slice the WTRU was connected, a flag in the NAS message [e.g., TAU) informing the MME whether the WTRU was connected to multiple network slices and/or an indication of number of slices (e.g., 1 , 2 or 3, etc.) as a separate IE in the tracking area request or registration request message to the MME.

[0169] The network may select the DCN when the WTRU moves to the EPC system. The WTRU NAS message (e.g., TAU/Attach request) may include multiple DCN IDs from the list of available DCN IDs corresponding to the network slices it was connected to. The MME may choose a DCN ID from the list. The decision at the MME may be based on WTRU subscription information, local policies, information received in the tracking area update message (e.g., WTRU capabilities, service information), and/or WTRU context retrieved from the CCNF/AMF over during the relocation procedure. The selected DCN ID may be communicated back to the WTRU is the NAS response message.

[0170] The WTRU may include the slice ID (e.g., NSSAI or MDD) in the NAS message to the MME. It may be the same ID that the WTRU might have used to perform slice selection. When the MM E receives this slice ID, the M ME may communicate with the last serving CCNF/AMF to get the mapping to a particular DCN ID. For example, a temporary ID may be included in the NAS message for the MME to establish communication with the last serving CCNF/AMF. The CCNF/AMF may provide the mapping based on the information described herein. The CCNF/AMF may provide a DCN ID or a list of DCN IDs to the MME. The MME may select a DCN ID based on local policies/subscription and/or information received from the WTRU in the initial WTRU NAS message. When the WTRU sends the NAS message to the MME, the WTRU may include a DCN ID in the RRC message to enable the eNB to redirect the NAS message to an initial MME. The DCN ID included in the MME may be pre-configured DCN ID or DCN ID last used by the WTRU when it was connected to the EPC system. There may be a MME reselection after the DCN ID selection is performed by the MME. The MME reselection may happen for the case when the WTRU provides DCN ID to network. Based on the described inputs from CCNF/AMF, HSS and the WTRU, the MME may redirect the WTRU to a different MME that may be more suitable for the WTRU. If a redirection happens, a different DCN ID may be sent back to the WTRU in the NAS response message.

[0171] A DCN ID may be provided to the WTRU at PDU session establishment, e.g. , by the AMF or SMF. Access and mobility management function (AMF) terminology is used to illustrate this example, however, as noted above, the concepts are equally applicable to the common control network function (CCNF/AMF) or mobility management function (MMF) as described herein . A DCN ID for an EPC based dedicated core network may be provided to the WTRU via a PDU session establishment procedure. The AMF (or the SMF) may send the DCN ID in a PDU session response message to the WTRU.

[0172] A WTRU may send a PDU session request message for the PDU session establishment, and may include an explicit indication in the PDU session request message requesting the network to send the DCN ID associated with the NSSAI or S-NSSAI in the PDU session request message.

[0173] An indication to establish a PDU session may be sent in the mobility management part (the part of a session management (SM) NAS message which can be processed by the AMF) of the PDU session request NAS message. The AMF may provide the DCN ID to the WTRU in the MM part of the PDU session accept message. The AMF may query various network functions or nodes (e.g., NSSF (Network Slice Selection Function), NRF (Network Repository Function), etc.) to get the mapping between the S- NSSAI and the DCN ID as described herein. The AMF may (e.g., may also) check the UDM for subscription information and/or PCF for WTRU policy related information . Based on the information received from the various nodes, the AMF may include the DCN ID in the MM part of the PDU session accept message.

[0174] An indication to request the DCN ID from the WTRU may be sent in the session management part (the part of NAS message which is transparent to the AMF and may be processed by the SMF), and the SMF may provide the DCN ID to the WTRU in the SM part of the PDU session accept message. The SMF may query various network functions or nodes (e.g., NSSF, NRF, etc.) to retrieve the mapping between the S-NSSAI and the DCN ID as described herein. The SMF may (e.g., may also) check the UDM for subscription information and/or PCF for WTRU policy related information. Based on the information received from the various nodes, the SMF may include the DCN ID in the SM part of the PDU session accept message.

[0175] The AMF or SMF may send the DCN ID to the WTRU without receiving any explicit request from the WTRU.

[0176] The WTRU may receive the DCN ID (e.g., either from the AMF or the SMF) and may store the DCN ID in the context information for that PDU session. If a WTRU decides to move that PDU session from the 5GS to EPC system, the WTRU may use the stored DCN ID (e.g., received from the network during PDU session establishment) to request the connection to a dedicated core network on the EPC side. The stored DCN ID will be included by the WTRU in the attach request or TAU request message on the EPC system .

[0177] A WTRU may have multiple PDU sessions in the 5G system. The network (AMF/SMF, efc.) may associate a priority level with the DCN ID. The associated priority level may be sent to the WTRU with the DCN ID in the PDU session accept message as described herein . If a WTRU decides to transfer multiple PDU sessions to EPC system, the WTRU may use the DCN ID with the highest priority. This DCN ID may be included in the attach request or TAU request message on the EPC side. A WTRU may be able to connect to one DCN at a particular time in the EPC system. A WTRU may be able to simultaneously connect to multiple network slices in the 5G system.

[0178] A WTRU may request connection to a particular slice, e.g., by including a specific S-NSSAI in the PDU session establishment request message. The network slice may not be available to serve the WTRU or the network may not be able to establish connection to that network slice. The network

(AMF/SMF, efc.) may send a PDU session reject message to the WTRU . The network may include the appropriate reject cause (e.g., network slice not available or redirect to EPC, efc.) along with the DCN ID in the PDU session reject message.

[0179] A WTRU, upon receiving the PDU session reject message with the cause value (e.g., appropriate reject cause), may trigger the attach request or TAU procedure in EPC with the DCN ID received in the reject message. The WTRU may then establish the same PDN connection in the EPC system (e.g., the PDU session for which the WTRU was rejected in the 5G system due to slice unavailability).

[0180] The processes and instrumentalities described herein may apply in any combination, may apply to other wireless technologies, and for other services.

[0181] A WTRU may refer to an identity of the physical device, or to the user's identity such as subscription related identities, e.g. , MSISDN, SIP URI, efc. WTRU may refer to application-based identities, e.g. , user names that may be used per application.

[0182] The processes described above may be implemented in a computer program, software, and/or firmware incorporated in a computer-readable medium for execution by a computer and/or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and/or wireless connections) and/or 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, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as CD-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.

Claims

CLAIMS What is Claimed:

1 . A method implemented in a radio access network (RAN) node, the method comprising: receiving a first non-access stratum (NAS) message from a wireless transmit/receive unit (WTRU), the first NAS message comprising information for a requested slice;

sending the first NAS message to a first common control network function (CCNF);

receiving a connection switch request from the first CCNF, the connection switch request comprising an address associated with a second CCNF;

sending a request to the second CCNF to serve the WTRU for the requested slice;

receiving a second NAS message from the second CCNF; and

sending the second NAS message to the WTRU.

2. The method of claim 1 , wherein the connection switch request comprises a random sequence number associated with the first CCNF.

3. The method of claim 2, wherein the random sequence number identifies a RAN connection.

4. The method of claim 2, wherein the random sequence number is sent to the second

CCNF.

5. The method of claim 1 , wherein the first NAS message comprises a dedicated core network (DCN) identifier (ID).

6. The method of claim 1 , further comprising receiving a message from the WTRU relating to a change to the DCN ID associated with the WTRU .

7. The method of claim 1 , further comprising determining the second CCNF based on information in the first NAS message.

8. The method of claim 1 , further comprising sending a connection switch acknowledgement to the first CCNF.

9. The method of claim 1 , wherein the first CCNF corresponds to a default access and mobility management function (AMF) and the second CCNF corresponds to a serving AMF.

10. The method of claim 1 , further comprising establishing a connection between the WTRU and the second CCNF for the requested slice.

1 1 . A radio access network (RAN) node comprising:

a memory storing processor-executable instructions; and

a processor to execute the processor-executable instructions to:

receive a first non-access stratum (NAS) message from a wireless transmit/receive unit (WTRU), the first NAS message comprising information for a requested slice;

send the first NAS message to a first common control network function (CCNF);

receive a connection switch request from the first CCNF, the connection switch request comprising an address associated with a second CCNF;

send a request to the second CCNF to serve the WTRU for the requested slice;

receive a second NAS message from the second CCNF; and

send the second NAS message to the WTRU .

12. The RAN node of claim 1 1 , wherein the connection switch request comprises a random sequence number associated with the first CCNF.

13. The RAN node of claim 12, wherein the random sequence number identifies a RAN connection.

14. The RAN node of claim 12, wherein the random sequence number is sent to the second

CCNF.

15. The RAN node of claim 1 1 , wherein the first NAS message comprises a dedicated core network (DCN) identifier (ID).