Systems and methods associated with dynamic mobile network selection

Abstract

Systems, methods, and instrumentalities associated with dynamic policy updates are described herein. A wireless transmit / receive unit (WTRU) (e.g., a roaming WTRU) may receive roaming steering (SoR) information and / or information about a mobile network search timer. The SoR information may indicate at least a first mobile network and a second mobile network. The WTRU may receive, from a first mobile network, a first message indicating a congestion condition associated with the first mobile network and a fallback timer. The WTRU may start a mobile network search timer and a fallback timer. Based on a determination that the mobile network search timer has expired before the rollback timer expires, the WTRU may initiate a mobile network selection procedure, where a second mobile network may be selected as a result of the mobile network selection procedure.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 530,189, filed August 1, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Technology

[0002] A large number of wireless transmit / receive units (WTRUs) (e.g., roaming WTRUs) can cause congestion in wireless communication networks such as the public terrestrial mobile network (VPLMN) being visited, and the WTRU may be stuck in the congested network, while other networks in the visited location may be available to provide services to the WTRU. Systems and methods are intended to handle these situations. Summary of the Invention

[0003] This document describes systems, methods, and means associated with slice-based mobile network selection. A radio transmit / receive unit (WTRU) as described herein can be configured to receive information indicating that a network slice is available via at least a first mobile network and a second mobile network. The WTRU can be further configured to send a message to the first mobile network and receive a response from the first mobile network. The message sent to the first mobile network can indicate the network slice, and the response received from the first mobile network can indicate congestion in the first mobile network. The response can further indicate a fallback period associated with access to the first mobile network. Upon receiving the response, the WTRU can be configured to begin monitoring for the expiration of both the fallback period and the network search period. After the network search period expires but before the fallback period expires, the WTRU can send a registration request associated with the network slice to the second mobile network.

[0004] In the example, the information received by the WTRU indicating network slice availability can further indicate the network search period. In the example, the information received by the WTRU can further indicate that the first mobile network has a higher priority than the second mobile network, and the WTRU can send a message to the first mobile network based on this indication.

[0005] In the example, the message sent to the first mobile network may include a request to register with the first mobile network or establish a Protocol Data Unit (PDU) session via the first mobile network. In the example, after the fallback period expires, the WTRU can be configured to resend the request to register with the first mobile network or establish a PDU session via the first mobile network.

[0006] In the example, the information indicating network slice availability received by the WTRU can be received from the Home Public Land Mobile Network (HPLMN) and may include Roaming Direction (SoR) information. In the example, at least one of the first mobile network or the second mobile network may be the Visitor Public Land Mobile Network (VPLMN).

[0007] In the example, the registration request sent by the WTRU to the second mobile network may include auxiliary information associated with a network slice (e.g., the auxiliary information may include single network slice selection auxiliary information (S-NSSAI)). In the example, the WTRU can monitor the expiration of the fallback period and the network search period by starting a first timer associated with the fallback period and a second timer associated with the network search period.

[0008] In the example, the WTRU can be further configured to search for the second mobile network after the network search period expires and before the fallback period expires. In the example, the registration request sent to the second mobile network may include information about the rejection reason associated with the first mobile network (e.g., a rejection reason code).

[0009] A network device as described herein (e.g., a mobile network device such as a VPLMN device) can be configured to receive a first request from a WTRU for access to a network slice provided by the mobile network, and to determine that the mobile network may be congested with respect to the network slice. The network device can then send a response to the WTRU, which may indicate that the mobile network is congested and further indicate a period of time during which the WTRU will prohibit access to the mobile network for the network slice. After the expiration of this period, the network device can receive a second request from the WTRU for access to the network slice provided by the mobile network. Attached Figure Description

[0010] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments can be implemented; Figure 1B The illustration based on one embodiment can be seen in Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) used within a communication system shown; Figure 1C The illustration based on one embodiment can be seen in Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used within the communication system shown. Figure 1D The illustration based on one embodiment can be seen in Figure 1AThe system diagram shows another example RAN and another example CN used in the communication system shown; Figure 2 The illustration shows an example of configuring and using PLMN to search for time periods.

[0011] Figure 3 The illustration shows an example of using PLMN to search for a time period.

[0012] Figure 4 The illustration shows an example operation associated with registration rejection in VPLMN. Detailed Implementation

[0013] A more detailed understanding can be obtained from the following description, which is given by way of example in conjunction with the accompanying drawings.

[0014] Figure 1A This diagram illustrates an example communication system 100 that may implement one or more of the disclosed embodiments. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 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 Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0015] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments are contemplated to 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. For example, WTRU 102a, 102b, 102c, and 102d—any of which can be referred to as a “station” and / or “STA”—can be configured to transmit and / or receive wireless signals and can include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRU 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0016] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NRNode B, site controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be appreciated that base stations 114a and 114b may include any number of interconnected base station and / or network elements.

[0017] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (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 radio services to a specific geographic area, which may be relatively fixed or may change over time. The cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0018] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0019] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0020] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0021] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

[0022] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0023] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), and the like.

[0024] Figure 1ABase station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0025] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1A Although not shown, it will be understood that RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

[0027] One or more (e.g., all) of WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multimode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0028] Figure 1B This is a system diagram illustrating the example WTRU 102. (Example: ...) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0029] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0030] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 can be, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It will be appreciated that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0031] Despite Figure 1B While the transmit / receive element 122 is described as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0032] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers for example enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0033] The processor 118 of WTRU 102 can be coupled to and receive user input data from: a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information from and store data in any suitable type of memory (such as non-removable memory 130 and / or removable memory 132). 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. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, and the like. In other embodiments, the processor 118 can access information from and store data in memory that is not physically located on WTRU 102 (such as a server or home computer (not shown)).

[0034] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 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.

[0035] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0036] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

[0037] WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with a specific subframe for both 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 to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with a specific subframe for UL (e.g., for transmission) or downlink (e.g., for reception) may be concurrent and / or simultaneous.

[0038] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0039] RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0040] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, and the like. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0041] Figure 1C The CN 106 shown 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 is depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0042] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, and so on. The MME 162 can provide control plane functions for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0043] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, and so on.

[0044] The SGW 164 can be connected to the PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0045] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between WTRU 102a, 102b, 102c and conventional landline communication equipment. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0046] Despite WTRU in Figures 1A-1D While described as a wireless terminal, it is envisioned that in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0047] In a representative embodiment, another network 112 may be a WLAN.

[0048] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access to or interfacing with a Distributed System (DS) or carry services within and / or out of the BSS to another type of wired / wireless network. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA (e.g., directly between the source STA and the destination STA) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the "self-organizing" communication mode in this document.

[0049] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can listen on the primary channel. If the primary channel is listened to / detected by a particular STA and / or determined to be busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0050] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0051] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels—this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0052] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to the operating modes used in 802.11n and 802.11ac, the channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities (e.g., limited capabilities), including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0053] WLAN systems that support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs that support the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and can be available.

[0054] In the United States, the available frequency bands for 802.11ah are from 902 MHz to 928 MHz. In South Korea, the available bands are from 917.5 MHz to 923.5 MHz. In Japan, the available bands are from 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0055] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0056] RAN 113 may include gNBs 180a, 180b, and 180c, although it should be understood that RAN 113 may include any number of GNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, GNBs 180a and 108b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0057] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute durations).

[0058] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without access to other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0059] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, and the like. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0060] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0061] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and so on. AMF 162 can provide control plane functions for switching between RAN 113 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.

[0062] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure service routes through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and so on. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0063] UPF 184a and 184b can be connected via the N3 interface to one or more of gNB 180a, 180b, and 180c in RAN 113. This N3 interface provides WTRU 102a, 102b, and 102c with access to a packet-switched network (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and so on.

[0064] CN 115 can facilitate communication with other networks. For example, CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) acting as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to local DNs 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and data networks (DNs) 185a and 185b.

[0065] Given Figures 1A-1D and Figures 1A-1D The corresponding descriptions herein regarding one or more of the functions of WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0066] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communication.

[0067] One or more emulation devices may perform one or more functions (including all functions) but are not implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios in a test laboratory and / or in non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test equipment. Emulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0068] As described herein, a WTRU may include a Terminal Equipment (TE) component and / or a Mobile Terminal (MT) component. The TE component of the WTRU may run applications that can use a mobile network to send and receive data. The MT component of the WTRU may include modem logic that can be used to communicate with the mobile network. The functionality in the TE component of the WTRU can communicate with the logic in the MT component of the WTRU using AT (Attention) commands.

[0069] The registration area associated with a WTRU and / or network device may include a set of tracking areas. The registration area may be defined by a list of Tracking Area Identities (TAIs), such as a tracking area list. If a WTRU registers with the network (e.g., by sending a registration request to the AMF), the network (e.g., the AMF) may assign a registration area to the WTRU (e.g., a set of tracking areas in the TAI list) and may obtain information about the WTRU, such as its expected mobility patterns (e.g., when the AMF assigns the TAI list).

[0070] When mentioned herein, the Network Slice Selection Auxiliary Information (NSSAI) configured for the WTRU can indicate a list and / or set of slices that the WTRU can access. The WTRU may receive such a configured NSSAI in registration accept / response messages, configuration update messages, etc. When mentioned herein, a requested NSSAI may include or indicate a list and / or set of slices that the WTRU may want to access. The WTRU may send such a requested NSSAI to a network device (e.g., to register with one or more slices indicated in the requested NSSAI). For example, the WTRU may send the requested NSSAI to a network device in a registration request message.

[0071] When referred to herein, an allowed NSSAI may indicate a list and / or set of slices that the WTRU can access (e.g., use) in its registration area. When referred to herein, a rejected NSSAI (e.g., a single NSSAI (S-NSSAI)) may indicate that the WTRU has been included in the requested NSSAI, but has been determined by the network device to be a slice that the WTRU cannot access. Such a rejected NSSAI may be included in the information element sent from the network device to the WTRU (e.g., in a registration acceptance message or configuration update message).

[0072] When mentioned herein, attempting to register with a slice can mean including or indicating the slice in the requested NSSAI (e.g., an S-NSSAI such as that associated with the slice). Furthermore, the terms "slice" and "S-NSSAI" are used interchangeably herein. The terms "slice" and "network slice" are also used interchangeably herein.

[0073] The WTRU may provide one or more S-NSSAIs in the requested NSSAI, which may not be part of an allowed or rejected NSSAI. In such a case, the WTRU may not treat one or more S-NSSAIs as rejected S-NSSAIs(one or more), and may request the registration of (one or more) S-NSSAIs(one or more) (e.g., when the WTRU sends the requested NSSAI).

[0074] If a WTRU registers with a slice, it can use the resources associated with that slice. For example, a WTRU can send periodic NAS messages to an AMF that may be a part of the slice. A WTRU may or may not use the slice's user plane resources or other resources of that slice (e.g., resources associated with SMS and / or location services).

[0075] The WTRU can select one or more slices from the configured NSSAI and register them with said slices (e.g., up to eight slices associated with an NSSAI). When selecting slices to register with, the WTRU can send a registration request to the network (e.g., to network devices such as SMFs). The requested NSSAI information element of the registration request can include the slices selected by the WTRU for registration.

[0076] Various events can trigger a WTRU to send a registration request associated with a slice. As examples, triggering events may include one or more of the following: A WTRU can be configured to always attempt to register with a slice unless the WTRU detects that the slice is unavailable. A WTRU can be configured to attempt to register with a slice after power-on (e.g., immediately or shortly after power-on). A WTRU can be configured to attempt to register with a slice when it is registered with a specific PLMN. A WTRU can be configured to attempt to register with a slice when a specific application service begins. A WTRU can be configured to attempt to register with a slice if it is in a specific location. A WTRU can be configured to attempt to register with a slice if a specific application is installed and / or running on the WTRU. A WTRU can be configured to attempt to register with a slice when prompted (e.g., by a user via a user interface such as a graphical user interface or GUI). For example, if a user requests a specific service via a GUI, the WTRU can attempt to register with the slice.

[0077] Various events can trigger the establishment of a PDU session. For example, after a WTRU registers with a slice, it can establish a PDU session within that slice. A WTRU can establish a PDU session by sending a PDU session establishment request to the network. This request (e.g., a NAS-SM message) can be sent to the Segment Management Function (SMF) of the slice (which may be referred to herein as a slice). The PDU session establishment request may include an S-NSSAI that can be associated with the PDU session and / or a DNN that can be associated with the PDU session. If the S-NSSAI is not included in the PDU session establishment request, the network can determine the S-NSSAI of the PDU session. If the DNN is not included in the PDU session establishment request, the network can determine the DNN of the PDU session.

[0078] Various events can trigger the WTRU to send a PDU session establishment request to the network. As an example, triggering events may include one or more of the following: An application hosted by the WTRU may request the WTRU to establish a PDU session. Requests from WTRU-hosted applications may include DNN and / or S-NSSAI, and the WTRU may send DNN and / or S-NSSAI to the network in the PDU session establishment request. For example, a component hosted in the TE part of the WTRU may invoke an AT command (e.g., +CGDCONT) to request a component hosted in the MT part of the WTRU to send a PDU session establishment request to the network.

[0079] The application managed by the WTRU can generate uplink traffic, which allows the WTRU to evaluate UE Routing Policy (URSP) rules to determine the characteristics of the requested PDU session that the uplink traffic can be sent to the network via. As a result of the URSP evaluation, the WTRU can determine whether to use an existing PDU session or establish a new PDU session to send the uplink traffic to the network. If the WTRU determines to establish a new PDU session, it can send a PDU session establishment request to the network, and the URSP rules can be used to determine what DNN and / or S-NSSAI should be included in the PDU session establishment request.

[0080] A WTRU can be configured with a combination of DNN / S-NSSAI, and if the WTRU registers with the S-NSSAI in the DNN / S-NSSAI combination, the WTRU can establish a PDU session associated with the DNN / S-NSSAI combination. In some examples, the WTRU can choose to establish a PDU session even if it is not used by any WTRU application to send or receive traffic.

[0081] The WTRU can receive device triggers for establishing a PDU session. These device triggers can be included in NAS messages and / or SMS messages, and may include a DNN and / or S-NSSAI. The WTRU can include the DNN and / or S-NSSAI in the PDU session establishment request.

[0082] The Network Slice Admission Control Function (NSACF) can monitor and / or control the number of registered WTRUs and / or the number of PDU sessions per network slice that may be subject to Network Slice Admission Control (NSAC). The NSACF can be configured with the maximum number of WTRUs and / or PDU sessions that each S-NSSAI can serve (e.g., for network slices subject to NSAC). The NSACF can be configured with information indicating one or more applicable access types for the S-NSSAI (e.g., one or more 3GPP access types and / or one or more non-3GPP access types). The NSACF can keep track of the current number of WTRUs registered for a network slice to ensure that the number of registered WTRUs does not exceed the maximum number of WTRUs allowed to register with a network slice.

[0083] If the registration status of those WTRUs undergoing NSAC in a network slice is changing, network devices or functions such as the AMF can trigger an NSAC request to the NSACF for the number of WTRUs (e.g., the maximum number of WTRUs). This operation can occur, for example, during a WTRU registration procedure, a WTRU deregistration procedure, a network slice-specific authentication and / or authorization procedure, a network slice-specific re-authentication and re-authorization procedure triggered by an AAA (Authentication, Authorization, and Accounting) server, a slice-specific authorization revocation procedure triggered by an AAA server, and / or a WTRU configuration update procedure.

[0084] If the maximum number of slice registrations has been reached, the NSACF can indicate to the AMF that a request to register the slice may be rejected. A reason code can be provided to the WTRU indicating that its slice registration was rejected because the maximum number of registrations for that slice has been reached. Information regarding the rollback period (e.g., implemented via a rollback timer) can be sent to the WTRU and used by the WTRU to determine whether the WTRU can attempt to register the slice again.

[0085] NSACF can keep track of the current number of PDU sessions for each network slice to ensure that it does not exceed the maximum number of PDU sessions allowed to be served by the network slice. If an event related to WTRU causes an increase in the current number of PDU sessions established within a network slice, NSACF can check whether the maximum number of PDU sessions per network slice for that network slice has been reached, and if so, NSACF can apply an admission control policy.

[0086] If the maximum number of PDU sessions in a slice has been reached, the NSACF can instruct other network devices or functions, such as the SMF, to reject the PDU session establishment request and can provide a reason code to the WTRU. Such a reason code indicates that the PDU session was rejected because the maximum number of PDU sessions for that slice has been reached. Information about the rollback period (e.g., implemented via a rollback timer) can be sent to the WTRU, and the rollback period can be used by the WTRU to detect when it can attempt to establish a PDU session in that slice again. During the PDU session establishment / release procedure, the anchor SMF can request information from the NSACF regarding the maximum number of PDU sessions controlled for each network slice.

[0087] Congestion control can be performed at the NAS level. Congestion control can be applied generally (e.g., for all NAS messages), according to DNN and / or S-NSSAI, or for specific WTRU groups. Congestion control can be implemented by providing WTRUs with a rollback period (e.g., via timer T3346). To avoid a large number of WTRUs simultaneously initiating delay requests, the network (e.g., the core network) can select (e.g., for each WTRU) a rollback period (e.g., a rollback timer value) such that delay requests (e.g., from multiple WTRUs) can be spaced out rather than synchronous. If a WTRU receives a rollback period value, it may not initiate NAS signaling regarding the applied congestion control until the rollback period expires, until the WTRU receives a mobility termination request from the network, until the WTRU initiates signaling for emergency services or high-priority access, or until the WTRU enters a new PLMN that may not be equivalent to the PLMN list.

[0088] Under overload conditions, the AMF may reject NAS messages from a WTRU that is using the access network (e.g., this rejection may be associated with congestion reason code #22). If a NAS request is rejected, the AMF may provide the corresponding WTRU with a mobility management rollback period (e.g., a rollback timer value). During the rollback period (e.g., when the mobility management rollback timer is running on the WTRU), the WTRU may not initiate a NAS request, for example, except for deregistration procedures and / or procedures that may not be affected by congestion control (e.g., for high-priority access, emergency services, and / or mobile termination services). If the WTRU receives a paging request or NAS notification message from the AMF while the mobility management rollback timer is running, the WTRU may stop the mobility management rollback timer and, where applicable, initiate a service request procedure or mobility registration update procedure on 3GPP access and / or non-3GPP access.

[0089] DNN-based congestion control can be designed and / or implemented to avoid and / or manage congestion in the WTRU (e.g., NAS session management signaling congestion). DNN-based congestion control may involve configuring a fallback period and / or sending a fallback period from the network to the WTRU (e.g., via a fallback timer value). The fallback period can be associated with the DNN. The fallback period can indicate how long the WTRU should wait before generating NAS session management signaling associated with the DNN. DNN-based congestion control can be applied regardless of whether S-NSSAI is present in the NAS SM signaling message sent from the WTRU.

[0090] Network devices or functions such as the SMF can apply DNN-based congestion control to the WTRU by rejecting PDU session establishment request messages and / or PDU session modification request messages from the WTRU (e.g., in addition to request messages sent for the purpose of reporting changes in the 3GPP packet switching (PS) data shutdown state of a specific DNN using a running backoff timer). The SMF can release one or more PDU sessions belonging to a congested DNN by sending a PDU session release command message to the WTRU with a DNN backoff period (e.g., timer T3396). If the DNN backoff timer is included in the PDU session release command message, a reason value indicating "reactivation request" may not be set.

[0091] If DNN-based congestion control is activated at the AMF (e.g., via Operation, Administration and Maintenance (OAM) configuration), the AMF can provide NAS transport error messages for NAS transport messages that can carry SM messages. NAS transport error messages may include or indicate a DNN rollback period (e.g., timer T3396).

[0092] S-NSSAI-based congestion control can be designed and / or implemented to avoid and / or handle congestion (e.g., NAS signaling congestion) of WTRUs that may or may not be associated with S-NSSAI, regardless of the presence of the DNN. This can be accomplished, for example, by configuring and / or using a fallback period (e.g., a fallback timer). If S-NSSAI-based congestion control is activated at the AMF (e.g., via OAM configuration) and S-NSSAI is determined to be congested, the AMF can apply S-NSSAI-based congestion control to the WTRU in response to a session management request initiated by the WTRU. In this case, the AMF can provide a NAS transport error message for NAS transport messages that may carry SM messages. The NAS transport error message may include / indicate a fallback period (e.g., for timers T3584 and / or T3585) and / or one or more rejection reasons (e.g., insufficient resources for a specific slice and / or DNN #67, insufficient resources for a specific slice #69, etc.).

[0093] The WTRU can associate the configured / received backoff period (e.g., for timers T3584 and / or T3585) with S-NSSAI and / or DNN (e.g., the WTRU may not have S-NSSAI or DNN, may not have S-NSSAI, may have only S-NSSAI, or may have both S-NSSAI and DNN). S-NSSAI and / or DNN may have been indicated / included in an uplink NAS mobility management (MM) message carrying a NAS session management (SM) request message for congesting the PLMN (e.g., congesting S-NSSAI or DNN). For example, the backoff period value can be received in a downlink NAS mobility management (MM) message sent from the AMF to the WTRU.

[0094] A WTRU, such as a roaming WTRU, can register with a VPLMN. The WTRU can request access to network slices that may not be provided by the VPLMN or may be unavailable via that VPLMN (e.g., to access services and / or applications). The HPLMN can send information (e.g., slice-aware SoR information) to the WTRU (e.g., a roaming WTRU). This information (e.g., slice-aware SoR information) may include / indicate one or more (e.g., preferred) PLMNs for one or more specific S-NSSAIs. A specific S-NSSAI may be part of the WTRU's subscription.

[0095] If the WTRU is stationed in a VPLMN and attempts to access a network slice that may be unavailable via the VPLMN, the WTRU can perform a PLMN selection procedure. The WTRU can use information such as slice-aware SoR information to determine which PLMN(s)(s) to prioritize in the PLMN search procedure. For example, the WTRU can prioritize PLMNs associated with the network slice, as indicated by the slice-aware SoR information. As a result of the PLMN selection procedure, the WTRU can perform a registration procedure with a PLMN that supports the network slice. The WTRU can attempt to establish a PDU session in the network slice (e.g., simultaneously with or after PLMN registration).

[0096] During the registration or PDU establishment process, the WTRU may receive an indication or response from the network suggesting potential network congestion. In response to being notified of congestion, the WTRU may deny network access for a fallback period (e.g., by running a fallback timer). In the example approach, the WTRU may not perform a PLMN search during the fallback period. However, such an approach can be inefficient because it may result in a situation where slice-aware SoR information could guide the WTRU to register with the PLMN, expecting the slice to be available in the PLMN, but the WTRU may be forced to wait for the fallback period to expire before it can perform a PLMN search. The WTRU may still be trapped in this situation even if the slice-aware SoR information includes / indicates the identity of another PLMN that may not be congested and / or may provide access to the network slice.

[0097] In scenarios where a large number of WTRUs (e.g., roaming WTRUs) are configured to apply slice-based PLMN selection, overload may occur in the VPLMN (e.g., considering that WTRUs can pre-occupy the VPLMN using slice-aware SoR information), and WTRUs may be rejected by the VPLMN for congestion-related reasons (e.g., reason #22 for congestion, reason #67 for insufficient resources for a specific slice and DNN, reason #69 for insufficient resources for a specific slice, etc.). This can result in a large number of WTRUs (e.g., roaming WTRUs) being stuck in a congested VPLMN, and congestion may limit uplink services associated with the slice (e.g., uplink signaling), while downlink (DL) signaling from the slice may still be possible. Similar issues may exist for VPLMN selection based on SoR information (e.g., provided by HPLMN / UDM) and / or for updating the operator-controlled PLMN priority list (OPLMN list). For example, if congestion occurs, a WTRU (e.g., a roaming WTRU) may be stuck by a congested VPLMN without the HPLMN being aware of it, even if another VPLMN in the visited area may not be congested and may be able to provide service to the WTRU.

[0098] The WTRU can use information (e.g., slice-aware SoR information) provided by other devices or entities (e.g., network devices) to perform slice-based network (e.g., VPLMN) selection. The WTRU can select the action to take in congestion situations (e.g., congestion associated with the PLMN) based on information that can be included in the provided information (e.g., slice-aware SoR information). Such information (e.g., slice-aware SoR information) can be provided by HPLMN, UDM, and the like.

[0099] A network (e.g., an HPLMN) can provide guidance-related information, such as slice-aware SoR information, to a WTRU (e.g., a roaming WTRU). Slice-aware SoR information can indicate one or more PLMNs (e.g., preferred PLMNs) that can be included in the WTRU's subscription to an S-NSSAI (e.g., a network slice). The WTRU can be configured to support slice-based PLMN selection and can ensure that during cell selection processes (e.g., initial cell selection at power-on or recovery processes due to lack of coverage), the WTRU can select a suitable (e.g., highest priority) network for one or more selected slices based on the received slice-aware SoR information. In the example, if the most suitable network (e.g., the highest priority network) is unavailable, the WTRU can pre-empt the next suitable (e.g., lower priority) network based on a specific order (e.g., priority order) of available networks. One or more selected network slices can be a subset of network slices listed in a configured NSSAI. The WTRU can determine one or more selected slices based on configuration information.

[0100] HPLMN or UDM can provide the WTRU with additional information (e.g., along with slice-aware SoR information) that can assist the WTRU in selecting a VPLMN (e.g., if the WTRU's registration request to a particular VPLMN is rejected by that VPLMN). This additional information may include information about the PLMN search start time period (e.g., a PLMN search start timer). If the WTRU receives an indication of a fallback time period (e.g., a fallback timer value) from a network (e.g., a congested network the WTRU is attempting to access), the WTRU can initiate that PLMN search start time period. If the WTRU determines that the fallback time period has expired (e.g., if the WTRU stops the fallback timer), the WTRU can stop the PLMN search start time period (e.g., the PLMN search start timer). The expiration of the fallback time period can prompt the WTRU to resend the request to register with the congested network or establish a PDU session via the congested network.

[0101] When a PLMN search start period begins (e.g., by starting a corresponding timer) and it is determined that the search start period has expired (e.g., before the fallback period described herein expires), the WTRU can initiate a PLMN search procedure (e.g., the PLMN search start timer can be used to control the WTRU's behavior regarding the PLMN search). For example, if the WTRU attempts to register with a PLMN (e.g., a VPLMN) based on slice-aware SoR information, the WTRU may be rejected by the PLMN due to congestion conditions in the PLMN (e.g., congestion conditions related to mobility management or session management). In this scenario, the WTRU can be allowed to search for another PLMN (e.g., another VPLMN) to gain access to a network slice (e.g., the requested network slice), and the PLMN search start period can be used by the network (e.g., the home network) to control the amount of time the WTRU can wait before attempting to search for another PLMN (e.g., if the WTRU is also running a fallback timer associated with a congested PLMN, and the fallback timer has not yet expired).

[0102] Figure 2 An example program is shown to configure WTRU using the PLMN search start time period (e.g., PLMN search start timer). Figure 3 An example is shown (e.g., by WTRU) using a PLMN search start time period (e.g., a PLMN search start timer). Figure 2 As shown, at point 1, the WTRU can be configured to support slice-aware SoR information and / or PLMN search start timeout periods, which can be achieved via a PLMN search start timer. For example, if the WTRU receives an indication of a fallback timeout period from the network (e.g., a fallback timer value), the WTRU can start the PLMN search start timer. The WTRU can stop the PLMN search start timer when the fallback timeout period expires (e.g., if the WTRU stops running the fallback timer). The WTRU can start the PLMN search procedure when the PLMN search start timer is started and when it is determined that the timer has expired.

[0103] like Figure 2 As shown, at point 2, the WTRU can send a registration request message to network devices such as the AMF. The registration request message can indicate (e.g., in a Mobility Management (MM) Capability IE) that the WTRU can support the PLMN search start time period (e.g., a PLMN search start timer). The WTRU can use other NAS and / or MM procedures to notify the network that the WTRU can support the PLMN search start time period. Such NAS / MM procedures can include, for example, UL NAS transfer procedures, service request procedures, mobility registration procedures, etc.

[0104] Similarly, Figure 2 As shown, at point 3, the AMF can utilize a registration accept message to respond to a registration request from the WTRU. The registration accept message can include slice-aware SoR information (e.g., related to the PLMN, Independent Non-Public Network (SNPN), and / or managed network). The registration accept message can include information about the PLMN search start time period, which can be included in the SoR information container. Other NAS messages and / or procedures can also be used to provide slice-aware SoR information and / or information about the PLMN search start time period. These other procedures and / or messages can include, for example, DL NAS transport procedures, configuration update commands, SoR, WTRU parameter update procedures, etc. The AMF can cooperate with the SoR Application Function (SoR-AF) to obtain slice-aware SoR information and / or information about the WTRU's PLMN search start time period. This method can differ from other methods where the WTRU can remain on the current PLMN until the rollback period expires based on a rejection received for a congestion-related reason.

[0105] In the example, information about the start time period of the PLMN search can be configured in a general-purpose integrated circuit card with a SIM (USIM) element file (EF), which can be provided by the AMF at point 4 via a NAS signaling procedure. In the example, the WTRU can update the stored USIMEF at point 5 based on the receipt of updates to the USIM EF (e.g., via a NAS signaling procedure).

[0106] Figure 3 The illustration shows how a PLMN search start period (e.g., a search start timer) can be used by a WTRU (e.g., a roaming WTRU) if, for example, a WTRU receives a rejection from a VPLMN due to mobility management or session management congestion (e.g., reasons #22, #67, #69, etc.). In response to receiving a rejection, the WTRU can start a PLMN search start timer (e.g., indicate a search start period), and when the PLMN search start timer expires (e.g., but before the fallback timer described herein expires), it can select the next available VPLMN (e.g., based on slice-aware SoR information) to obtain access to the requested network slice. In some examples, the selected VPLMN may be associated with a lower priority than the rejected VPLMN. In some examples, the PLMN search start timer can be configured locally by the WTRU, in which case the locally configured information associated with the PLMN search start timer can override the information provided by the network. In some examples, information about the PLMN search start timer value can be received from the network, and the information provided by the network can override the locally configured information.

[0107] like Figure 3 As shown, the WTRU can obtain slice-aware SoR information, which can be associated with one or more networks (e.g., preferred networks) for each slice or S-NSSAI. The SoR information can be pre-configured, provided by the home network, or provided by the accessing network. Information about slices required by or prioritized by the WTRU can be determined based on previous information (e.g., previous requests) received from a PLMN (e.g., the last serving PLMN that has rejected information about the WTRU regarding that slice). Information about slices required by or prioritized by the WTRU can also be provided by applications running on the WTRU. In either case, the WTRU can select a VPLMN (e.g., the VPLMN with the highest priority) based on information about slices requested or desired by the user.

[0108] As by Figure 3As shown in Figure 1, the WTRU can be located in the visited location (e.g., the WTRU can be roaming) and can select a VPLMN based on slice-based PLMN selection (SbPS) information received from the HPLMN / UDM. At Figure 2, the WTRU can send a registration request message (or session management layer message, such as a PDU session establishment request, PDU session modification request, or other UL NAS signaling message) to the network device associated with the first VPLMN (e.g., VPLMN-1). Before sending the registration request message, the WTRU may have already received a registration rejection message or session management rejection message from another VPLMN. The rejection from the other VPLMN may have already indicated a congestion condition (e.g., as a reason for the rejection). Accordingly, the registration message (or session management layer message) sent to the network at Figure 2 may include rejection reason information (e.g., reason code), retry indicator information, the identifier (ID) of the VPLMN that sent the rejection message to the WTRU, and an S-NSSAI (e.g., indicating the network slice desired by the WTRU) that can be associated with the rejection message from the other VPLMN. For example, information included in the registration message may indicate the current Access Type Backoff Timer (CATBO) and / or all PLMN Backoff Timers (ABO). At 2a, information provided by the WTRU (e.g., a registration request) may be passed (e.g., transparently) to the HPLMN, UDM, and / or SoR-AF, and may assist the receiving device (e.g., UDM / SoR-AF / H-PCF) in reconstructing slice-aware SoR information and / or UE routing policy (URSP) (e.g., by taking into account congestion conditions at the visited locations). For example, the HPLMN / UDM may de-prioritize a VPLMN, or remove a congested VPLMN from the reconstructed slice-aware SoR information, or reconstruct new URSP rules that may de-prioritize one or more congested slices(s) in the visited locations of the congested VPLMN.

[0109] If VPLMN-1 is experiencing overload and / or congestion, a registration request from the WTRU (e.g., indicating a desired network slice) can be rejected by VPLMN-1 at point 3. This rejection may include a reason code (e.g., #22 for congestion, #67 for insufficient resources for a specific slice and / or DNN, or #69 for insufficient resources for a specific slice), indicating the reason for the rejection or congestion. Information about the rollback period can be sent to the WTRU by the AMF (e.g., via a mobility management rollback timer). Using the rollback period (e.g., when a mobility management rollback timer such as T3396 / T3584 / T3585 is running), the WTRU may not initiate a NAS request to VPLMN-1 except to perform deregistration procedures, procedures that may not be subject to congestion control (e.g., procedures associated with high-priority access, emergency services, etc.), and / or mobility termination services. Procedures that may not be accepted by the network may include session management procedures (e.g., PDU session establishment requests or PDU session modification requests). Responses from a congested network can be sent via session management rejection messages, such as PDU session establishment rejection messages or PDU session modification rejection messages. Responses from the network (e.g., including rejection information) can also be provided to the WTRU via other NAS signaling messages, such as WTRU configuration update commands, service rejection messages, etc.

[0110] like Figure 2As shown, the WTRU may have been configured with a PLMN search start time period (e.g., a PLMN search start timer) by the HPLM / UDM. The WTRU may use a value provided by the HPLM / UDM (e.g., as part of the SoR configuration information) to start the PLMN search start time period (e.g., the corresponding timer). When the PLMN search start time period expires (e.g., but before the fallback timer described herein expires), the WTRU may trigger a PLMN selection procedure at point 4 based on the user-requested slice and / or configured slice-aware SoR information. In an example implementation of the PLMN selection procedure, the WTRU may consider the congested network (e.g., VPLMN-1) as having the lowest network selection priority and may pre-claim another available network (e.g., VPLMN-2) that can provide access to the slice requested by the user. In an example implementation of the PLMN selection procedure, the WTRU may consider the congested network (e.g., VPLMN-1) as having the lowest priority for network selection, select a second network (e.g., VPLMN-2, which may be indicated by SoR information as having a lower priority than VPLMN-1), and perform a registration procedure to the second network. WTRU can pre-book a second network (e.g., VPLMN-2) and can use registration with the second network to access slices requested by the user.

[0111] In an example implementation of the PLMN selection procedure, at point 5, in response to receiving a rejection message with a reason code indicating a congestion condition from the first network (e.g., VPLMN-1), the WTRU can send a deregistration message, a service request message, or another UL NAS message to the AMF of the first network (e.g., the AMF can pass this message to the HPLM / UDM). At point 5a, the WTRU can provide additional information to the AMF of the first network. Such additional information may include the rejection reason from the first network (e.g., VPLMN-1), the retry indicator IE (e.g., indicating whether the backoff period applies to the registered PLMN or all PLMNs), and / or an indication of whether the backoff period applies to the current access type (e.g., either a 3GPP access type or a non-3GPP access type, or both). The additional information may also include the ID and / or S-NSSAI of the first network (e.g., VPLMN-1). For example, in Figure 3The information sent at point 5 or 5a can indicate one or more timer values ​​(e.g., CATBO and / or ABO values, which can be part of the congestion retry indicator IE of the rejection message). Such an IE can indicate whether the fallback timer can be applied to a registered PLMN, all PLMNs, a registered SNPN, or all equivalent SNPNs. The IE can additionally indicate whether the fallback timer can be applied to the current access type, or to both 3GPP and non-3GPP access types.

[0112] At point 6, the AMF in the first network (e.g., VPLMN-1) can forward information received from the WTRU to the HPLMN / UDM / H-PCF. At point 7, the HPLMN / UDM can forward the received information to the SoR-AF, which can use (e.g., received from the WTRU via VPLMN-1) this information to reconstruct slice-aware SoR information (e.g., by considering congestion conditions, network slices, and / or VPLMN availability). The UDM can share the received information with the H-PCF, which can use the shared information to reconstruct the updated URSP at point 8 (e.g., by considering user-requested slices and their availability or unavailability in VPLMN-1). The updated slice-aware SoR information and / or URSP can be delivered back to the WTRU. In response to receiving the updated information, the WTRU can take actions, including, for example, selecting a different VPLMN or initiating a session with a different S-NSSAI that may not be congested in the VPLMN. After notifying HPLM / UDM of a rejection experienced in VPLMN-1, and if WTRU is configured as follows Figure 2 If the PLMN search starts within the time period shown in the diagram, then WTRU can continue execution. Figure 3 The actions shown in the four places.

[0113] The WTRU can be configured to perform one or more of the following: The WTRU can receive Roaming Direction (SoR) information and / or information about the PLMN search start time period (e.g., a PLMN search start timer) from a first network (e.g., from an HPLMN). The SoR information can indicate that at least a second PLMN (e.g., a first VPLMN) and a third PLMN (e.g., a second VPLMN) can be associated with a network slice (e.g., associated with a corresponding S-NSSAI). The SoR information can indicate that the second PLMN can have higher priority than the third PLMN. The WTRU can send a NAS message to the second PLMN to initiate a PDU session establishment or registration procedure. The NAS message may include the S-NSSAI associated with the second PLMN. The WTRU can receive a NAS response message from the second PLMN, which may include information about the fallback time period (e.g., a fallback timer) and / or a rejection reason code (e.g., the rejection reason code may indicate that the rejection reason is congestion).

[0114] The WTRU can monitor rollback periods (e.g., by initiating a rollback timer) and / or PLMN search start periods (e.g., by initiating a search start timer). Based on the determination that the PLMN search start period has expired (e.g., before the rollback period expired), the WTRU can initiate a PLMN selection procedure. The WTRU can select a third PLMN during the PLMN selection procedure and can send a registration message to the third PLMN. The registration message may include the S-NSSAI associated with the third PLMN.

[0115] Information about the PLMN search start time period (e.g., the corresponding timer) can be received in the SoR container. Information about the PLMN search start time period can also be received in NAS messages. This information about the PLMN search start time period can be stored in the WTRU's USIM. The WTRU can send an indication to the network that it can support the PLMN search start time period. Registration messages sent to the third PLMN may include information about the rejection reason code received from the second PLMN. The WTRU can receive a registration response from the third PLMN, which may include SoR information (e.g., new or updated SoR information).

[0116] Figure 4 The illustration shows examples of actions (e.g., core network actions) that can be associated with congestion management at the visited location. Figure 4As shown, the WTRU can obtain slice-aware SoR information associated with a network (e.g., the preferred network) for each slice (e.g., each S-NSSAI). Slice-aware SoR information can be pre-configured or provided by the home or accessing network. Information about slices required by or prioritized by the WTRU can be determined based on prior requests from PLMNs (e.g., the last PLMN that served the WTRU regarding that slice may have been rejected). Information about slices required by or prioritized by the WTRU can also be provided by applications running on the WTRU. In either case, the WTRU can use this information to select the highest-priority VPLMN based on the slice requested by the user.

[0117] Similarly, Figure 4 As shown, as by Figure 4 As shown in 1, the WTRU can be located at the visited location and can send a registration request message to the selected VPLMN at 2, as well as information that can instruct the WTRU to support slice-based PLMN selection (e.g., a flag such as the SbPS flag) (e.g., the selection of VPLMN can be based on slice-aware SoR information from the HPLMN).

[0118] If the VPLMN is experiencing overload and / or congestion, a registration request from the WTRU can be rejected by the VPLMN at three points. The rejection response from the VPLMN (e.g., from the VPLMN's AMF) may include a reason code indicating the congestion condition (e.g., #22 for congestion, #67 for insufficient resources for a specific slice and / or DNN, or #69 for insufficient resources for a specific slice). The AMF may send information to the WTRU about a fallback period (e.g., a mobility management fallback timer). During the fallback period (e.g., when a mobility management fallback timer such as T3396 / T3584 / T3585 is running), the WTRU may deny access to the VPLMN. For example, the WTRU may not initiate a NAS request to the VPLMN except to perform deregistration procedures and / or procedures that may not be subject to congestion control (e.g., these procedures may be associated with high-priority access, emergency services, and / or mobility termination services). The VPLMN AMF can use information received from the WTRU (e.g., the SbPS flag) to determine whether to notify the HPLMN / UDM / H-PCF of overload and / or congestion conditions experienced by the VPLMN. Such information can be shared by the VPLMNs without relying on information received from the WTRU (e.g., the SbPS flag).

[0119] The VPLMN AMF can notify the HPLMN UDM / H-PCF of registration rejection at four points. The VPLMN AMF can also send additional information to the UDMH PLMN / H-PCF. Such information may include the reason for rejection from the VPLMN, a retry indicator IE (e.g., indicating whether the backoff timer applies to the registered PLMN or all PLMNs), and / or an indication of whether the backoff period applies to the current access type (e.g., one of the 3GPP access types and non-3GPP access types, or both). This information may also include a Subscription Permanent Identifier (SUPI), access type, VPLMN ID, and / or S-NSSAI.

[0120] At point 5, the HPLMN / UDM can forward the received information to the SoR-AF. At point 6, the SoR-AF can use the updated information received from the VPLMN to reconstruct the slice-aware SoR information, for example, by taking into account congestion experienced at the reported VPLMN, and / or the availability of network slices and / or other VPLMNs. For example, the HPLMN / UDM can lower the priority of a VPLMN or remove congested VPLMNs from the reconstructed slice-aware SoR information. The UDM can share this information with the H-PCF, which can use it to construct an updated URSP. The URSP can take into account slices requested by the user and the availability or unavailability of slices in the VPLMN. For example, the reconstructed URSP rules can lower the priority of slices that may be congested at the visited location (e.g., for a congested VPLMN).

[0121] Updated / reconstructed slice-aware SoR information and / or URSP rules can be delivered back to the WTRU via the VPLMN at point 7. In response to receiving the updated information, the WTRU can take actions such as, for example, selecting a network associated with a different VPLMN, performing session establishment with a different S-NSSAI that may not be congested in the VPLMN, re-evaluating the URSP (e.g., this could lead to the selection of a non-congested slice or S-NSSAI), etc.

[0122] Network devices such as VPLMN AMFs can be configured to perform one or more of the following operations: The network device can receive information from the WTRU (e.g., the SbPS flag) indicating that the WTRU can support slice-based PLMN selection and / or VPLMN selection can be based on slice-aware SoR information provided by the HPLMN. The network device can determine that an overload or congestion condition may have occurred in the VPLMN and can use reason codes indicating the congestion condition to reject registration requests from the WTRU (e.g., #22 for congestion, #67 for insufficient resources for a specific slice and / or DNN, or #69 for insufficient resources for a specific slice). The network device can use information provided by the WTRU (e.g., the SbPS flag) to determine whether it can notify the HPLMN / UDM / H-PCF of the congestion condition. The network device can notify the HPLMN UDM / H-PCF of the registration rejection along with additional information. For example, the additional information may include the rejection reason, a Session Management (SM) Retry Indicator Information Element (IE) (e.g., which may indicate whether a backoff timer can be applied to the registered PLMN or all PLMNs). Additional information may also indicate whether the rollback period can be applied to the current access type (e.g., one or both of 3GPP and non-3GPP access types). Additional information may also include SUPI, access type, VPLMN ID, and / or S-NSSAI. SoR-AF can use updated information received from the VPLMN to reconstruct slice-aware SoR information, for example, by taking into account congestion conditions, slice availability, and VPLMN availability. The UDM can share the reconstructed information with the H-PCF, which can use this information to construct an updated URSP that may take into account the availability or unavailability of slices requested by the user and / or slices in the VPLMN.

[0123] Network devices can receive updated slice-aware SoR information and / or URSP rules, and can send slice-aware SoR information and / or URSP rules to the WTRU. In response to receiving updated information, the WTRU can take specific actions, such as, for example, selecting a different VPLMN, performing session establishment with a different S-NSSAI that may not be congested in the VPLMN, re-evaluating URSP rules (e.g., this could lead to the selection of a less congested slice or S-NSSAI), etc.

[0124] While the features and elements described above are presented in specific combinations, each feature or element may be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without the other features and elements. Although the implementations described herein may be considered for 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and may also be applicable to other wireless systems.

[0125] The above processes can be implemented in computer programs, software, and / or firmware incorporated in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, 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-ROMs and / or DVDs. The processor associated with the software can be used to implement a radio frequency transceiver for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive information indicating that a network slice is available via at least a first mobile network and a second mobile network; Send a message to a first mobile network, wherein the message indicates a network slice; Receive a response from a first mobile network, wherein the response indicates that the first mobile network is congested with respect to a network slice, and the response further indicates a backoff period associated with access to the first mobile network for the network slice; Begin monitoring for the expiration of rollback periods and web search periods; and After the network search period expires but before the rollback period expires, a registration request associated with the network slice is sent to the second mobile network.

2. The WTRU of claim 1, wherein the information received by the WTRU further indicates the network search time period.

3. The WTRU according to claim 1 or 2, wherein the information received by the WTRU further indicates that the first mobile network has a higher priority than the second mobile network, and wherein the processor is configured to send a message to the first mobile network based on the indication that the first mobile network has a higher priority than the second mobile network.

4. The WTRU according to any one of claims 1-3, wherein the message sent to the first mobile network includes a request to register with the first mobile network or to establish a Protocol Data Unit (PDU) session via the first mobile network.

5. The WTRU of claim 4, wherein after the rollback period expires, the processor is further configured to resend a request to register with the first mobile network or to establish the PDU session via the first mobile network.

6. The WTRU according to any one of claims 1-5, wherein the information is received from a Home Public Land Mobile Network (HPLMN) and includes Roaming Direction (SoR) information, and wherein at least one of the first mobile network or the second mobile network is a Visitor Public Land Mobile Network (VPLMN).

7. The WTRU according to any one of claims 1-6, wherein the registration request sent to the second mobile network includes auxiliary information associated with the network slice.

8. The WTRU of claim 7, wherein the auxiliary information includes single network slice selection auxiliary information (S-NSSAI).

9. The WTRU according to any one of claims 1-8, wherein the processor is configured to begin monitoring for the expiration of a rollback period and the expiration of a network search period, including the processor being configured to start a first timer associated with the rollback period and a second timer associated with the network search period.

10. The WTRU according to any one of claims 1-9, wherein the processor is further configured to perform a search for the second mobile network after the network search period expires and before the fallback period expires.

11. The WTRU according to any one of claims 1-10, wherein the registration request sent to the second mobile network includes information about a rejection reason code associated with the first mobile network.

12. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: Receive information indicating that a network slice is available via at least a first mobile network and a second mobile network; Send a message to a first mobile network, wherein the message indicates a network slice; Receive a response from a first mobile network, wherein the response indicates that the first mobile network is congested with respect to a network slice, and the response further indicates a backoff period associated with access to the first mobile network for the network slice; Begin monitoring for the expiration of rollback periods and web search periods; and After the network search period expires but before the rollback period expires, a registration request associated with the network slice is sent to the second mobile network.

13. The method of claim 12, wherein the received information further indicates a network search time period.

14. The method of claim 12 or 13, wherein the received information further indicates that the first mobile network has a higher priority than the second mobile network, and wherein the message is sent to the first mobile network based on the indication that the first mobile network has a higher priority than the second mobile network.

15. The method according to any one of claims 12-14, wherein the message sent to the first mobile network includes a request to register with the first mobile network or to establish a Protocol Data Unit (PDU) session via the first mobile network.

16. The method of claim 15, further comprising, after the rollback period expires, resending the request to register with the first mobile network or to establish the PDU session via the first mobile network.

17. The method according to any one of claims 12-16, wherein the information is received from a Home Public Land Mobile Network (HPLMN) and includes Roaming Direction (SoR) information, and wherein at least one of the first mobile network or the second mobile network is a Visitor Public Land Mobile Network (VPLMN).

18. The method according to any one of claims 12-17, wherein the registration request sent to the second mobile network includes auxiliary information associated with the network slice.

19. The method according to any one of claims 12-18, wherein starting monitoring for the expiration of the rollback period and the expiration of the network search period includes starting a first timer associated with the rollback period and a second timer associated with the network search period.

20. The method according to any one of claims 12-19, further comprising performing a search for the second mobile network after the network search period expires and before the fallback period expires.

21. A device associated with a mobile network, comprising: The processor is configured as follows: Receive a first request from the wireless transmit / receive unit (WTRU) to access a network slice provided by the mobile network; It was determined that the mobile network was congested regarding the network slice; Send a response to the WTRU, wherein the response indicates that the mobile network is congested with respect to the network slice, and the response further indicates the time period during which the WTRU will prohibit access to the mobile network for the network slice; and After the time period expires, a second request to access a network slice provided by the mobile network is received from the WTRU.

22. The device of claim 21, wherein the mobile network is a visitor public land mobile network of the WTRU.

Images