Hosted network access control and congestion handling

Abstract

Systems and methods for hosting network overload and / or congestion handling (e.g., for closed access group (CAG) cells providing local services) are described herein. A device (e.g., a wireless transmit / receive unit (WTRU)) may include a processor configured to perform one or more actions. The device may determine a local service identifier associated with a first closed access group (CAG) and a second CAG. The device may transmit a first registration request to the first CAG based on the local service identifier. The device may receive, (e.g., in response to the first registration request), a first message including an indication that registration with the first CAG is rejected, a cause code, and a fallback value. The device may transmit a second registration request to the second CAG based on the indication that the registration with the first CAG is denied, the cause code, and the fallback value.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 392,473, filed on July 26, 2022, the contents of which are hereby incorporated by reference into this document. Background Art

[0003] Mobile communications using wireless communications continue to evolve. The fifth generation may be referred to as 5G. Previous (legacy) mobile communications may be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the invention

[0004] Systems and methods for managed network overload and / or congestion handling (e.g., for a closed access group (CAG) cell providing local services) are described herein. A device (e.g., a wireless transmit / receive unit (WTRU)) may include a processor configured to perform one or more actions. The device may determine a local service identifier associated with a first closed access group (CAG) and a second CAG. The device may transmit a first registration request to the first CAG based on the local service identifier. The device may receive a first message (e.g., in response to the first registration request), the first message including an indication that registration to the first CAG was rejected, a reason code, and a fallback value. The device may transmit a second registration request to the second CAG based on the indication that registration to the first CAG was rejected, the reason code, and the fallback value.

[0005] This reason code may indicate congestion.

[0006] The device may determine that the backoff value has elapsed based on the time when the first message was received.The device may transmit a third registration request to the first CAG (eg, after the backoff value has elapsed).

[0007] The first message may also include a redirection indication indicating that the second CAG is available.

[0008] The device may receive a second message, which may instruct the WTRU to register with the second CAG.

[0009] The first registration request may include an access identifier associated with the WTRU, and the first message may be based on the access identifier. The device may receive the access identifier. The access identifier may indicate that the WTRU has permission to access localized services.

[0010] The first message may include a localized service ID.

[0011] A hosted network (e.g., a PNI-NPN or SNPN) may use procedures to implement access control. The hosted network may define access identities for localized services. The hosted network may define access categories (e.g., for prohibiting a WTRU from accessing the hosted network (PNI-NPN) via a CAG cell).

[0012] The hosting network (eg, PNI-NPN) may use procedures to handle overload and / or congestion handling. For example, the hosting network may provide a cause code and / or a backoff timer to the WTRU during the WTRU's initial registration. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0014] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system.

[0015] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within an illustrated communication system.

[0016] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of a further example RAN and a further example CN for use within the illustrated communication system.

[0017] Figure 2 An example network architecture for accessing local services via a Public Network Integrated Non-Public Network (PNI-NPN) is illustrated.

[0018] Figure 3 An example access identifier for a localized service is illustrated.

[0019] Figure 4 An example managed network defined access category is illustrated.

[0020] Figure 5 Examples of overload and congestion handling for a hosted network and initial registration are illustrated.

[0021] Figure 6 Examples of overload and congestion handling and Radio Resource Control (RRC) connection establishment / recovery / release procedures for a hosted network are illustrated. DETAILED DESCRIPTION

[0022] Figure 1A1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of 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 discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0023] like Figure 1A As 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, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the UEs 102a, 102b, 102c, 102d (any of which WTRUs may be referred to as “stations” and / or “STAs”) may be configured to send and / or receive wireless signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smart phones, 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 process chain environments), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the UEs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0024] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is configured to interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an evolved Node B (eNB), a Home Node B, a Home evolved Node B, a next generation Node B (gNB), an NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0025] 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 (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further 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 for each sector of the cell. In an 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 may be used to send and / or receive signals in a desired spatial direction.

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

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

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

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

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

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

[0032] Figure 1A The base station 114b in may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0033] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the text and video, the CN 106 / 115 may be configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0034] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0035] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0036] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0037] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0038] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, IR, UV or visible light signals. In another embodiment, the send / receive element 122 may be configured to send and / or receive both RF signals and optical signals. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

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

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

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

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

[0043] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the 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 appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0044] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device and activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

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

[0046] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0047] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0048] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

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

[0050] The MME 162 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

[0053] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0054] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

[0055] In a representative embodiment, the other network 112 may be a WLAN.

[0056] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the target STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0057] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0058] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0059] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0060] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0061] WLAN systems that can 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 primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only the 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

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

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

[0065] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths over time).

[0066] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0067] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0068] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0069] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling and mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 182 may provide a control plane function for switching between the 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.

[0070] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

[0073] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0075] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0076] References to timers herein may refer to a time (e.g., a value), a time period, tracking a time, tracking a time period, etc. References to expiration of a timer herein may refer to determining that a time has occurred or a time period has expired. A timer may be based on a start time (e.g., a value), such as when a message is transmitted or received.

[0077] Systems and methods for managed network access control and / or congestion handling are described herein. Overload and congestion handling may be performed using cause codes. For example, upon receiving a registration request from a WTRU, a managed network (e.g., a closed access group) may transmit a response including a cause code. The cause code may indicate congestion. The response may deny the registration of the WTRU and include a backoff timer. The backoff timer may be used to improve overload and congestion handling (e.g., by, for example, reducing the frequency of requests during congested periods). Congestion handling during initial registration, signaling procedures (e.g., NAS signaling procedures), and / or connection establishment / recovery / release (e.g., RRC connection establishment / recovery / release), etc. may be enabled.

[0078] An access identifier may be defined (e.g., by a hosting network). The access identifier may be used to control access to localized services. The access identifier may include an access category. For example, the access identifier may be used to implement access control. The access identifier may prohibit a wireless transmit / receive unit (WTRU) from accessing the hosting network (e.g., via a CAG cell).

[0079] A network may be congested (e.g., due to the number of wireless transmit / receive units (WTRUs) being connected). A WTRU may access a service using a closed access group (CAG) (e.g., a local user group). For example, based on the number of WTRUs connected, access to a service via a first CAG may be congested. A WTRU may switch to a different CAG (e.g., during a period of congestion on a first CAG) to access a service, e.g., to improve access control and congestion handling. Overload and congestion handling may be enabled for a CAG cell providing a local service.

[0080] For example, the WTRU may determine that service is provided by a first CAG and a second CAG. The WTRU may transmit a registration request to the first CAG. For example, based on congestion, the WTRU may receive a first indication indicating that registration (e.g., to the first CAG) was rejected. The WTRU may transmit a second registration request to the second CAG (e.g., based on the received indication). The WTRU may receive a second indication indicating that registration (e.g., to the second CAG) was successful.

[0081] In an example, the first indication indicating that the registration to the first CAG was rejected may indicate a backoff time (e.g., a value). The backoff time may be a duration of time that the WTRU waits before transmitting another registration request (e.g., where the backoff time may be specific to the first CAG for which the registration was rejected). The backoff time may be specific to (e.g., unique to) the WTRU (e.g., different for other WTRUs), for example, to prevent simultaneous registration requests. The WTRU may determine that the backoff time has elapsed. The WTRU may transmit another registration request to the first CAG (e.g., based on determining that the backoff time has elapsed). Providing access to local services (PALS) may be enabled.

[0082] Systems and methods for managed network overload and / or congestion handling (e.g., for a closed access group (CAG) cell providing local services) are described herein. A device (e.g., a wireless transmit / receive unit (WTRU)) may include a processor configured to perform one or more actions. The device may determine a local service identifier associated with a first closed access group (CAG) and a second CAG. The device may transmit a first registration request to the first CAG based on the local service identifier. The device may receive a first message (e.g., in response to the first registration request), the first message including an indication that registration to the first CAG was rejected, a reason code, and a fallback value. The device may transmit a second registration request to the second CAG based on the indication that registration to the first CAG was rejected, the reason code, and the fallback value.

[0083] This reason code may indicate congestion.

[0084] The device may determine that the backoff value has elapsed based on the time when the first message was received.The device may transmit a third registration request to the first CAG (eg, after the backoff value has elapsed).

[0085] The first message may also include a redirection indication indicating that the second CAG is available.

[0086] The device may receive a second message, which may instruct the WTRU to register with the second CAG.

[0087] The first registration request may include an access identifier associated with the WTRU, and the first message may be based on the access identifier. The device may receive the access identifier. The access identifier may indicate that the WTRU has permission to access localized services.

[0088] The first message may include a localized service ID.

[0089] A hosted network (e.g., a public network integrated NPN (PNI-NPN) or SNPN) may use procedures to implement access control. The hosted network may define access identities for localized services. The hosted network may define access categories, for example, to prohibit a WTRU from accessing the hosted network (PNI-NPN) via a CAG cell.

[0090] The hosting network (eg, PNI-NPN) may use procedures to handle overload and / or congestion handling. For example, the hosting network may provide a cause code and / or a backoff timer to the WTRU during the WTRU's initial registration.

[0091] Local services may include services that are available in a (e.g., limited) area and / or time duration. For example, a local network (e.g., a temporary local network) may be established at a sporting event or fairground where a cellular network is not available. The local network by which local services are provided may be referred to as a hosted network. A hosted network may (e.g., typically) not be permanent (e.g., may be a short-term specific implementation without permanent infrastructure). A hosted network may be a permanent network. A hosted network may be a stand-alone non-public network (SNPN), or a public network integrated non-public network (PNI-NPN), or a public land mobile network (PLMN). A local service provider may be a hosted network operator or a third-party service provider.

[0092] A PNI-NPN may be provided and / or enabled. A PNI-NPN may be a non-public network provided using PLMN infrastructure / resources (e.g., a PLMN network slice). A group of PLMN users (e.g., that may be allowed to access a particular PNI-NPN) may be referred to as a closed access group (CAG). A CAG may be identified by a CAG identifier. A CAG user may (e.g., only) access a PNI-NPN, for example, from a cell that supports CAG access (which may be referred to as a CAG cell). A CAG cell may broadcast a list of supported CAG identifiers (e.g., that it supports). A CAG WTRU may be configured by the network with a list of CAGs that it may access (e.g., an allowed CAG list). When (e.g., when) a CAG WTRU detects a CAG cell, the CAG WTRU may (e.g., only) select / access the CAG cell, for example, if at least one of the broadcasted CAG identifiers matches one of the CAG identifiers in its allowed CAG list.

[0093] Unified access control may be provided and / or enabled. A WTRU may establish a radio connection with a radio access network (NG-RAN), for example, for the WTRU to send a message (e.g., an initial NAS message). The NAS layer may provide (e.g., RRC) connection establishment related information to lower layers, and this information may be used by the RAN to determine the priority of the connection and whether the connection may be established (e.g., access may be allowed or blocked). For example, by limiting access attempts from WTRUs using unified access control functionality, the network may protect itself from overload (e.g., in high network load conditions). The network may determine whether an access attempt (e.g., a certain access attempt) may be allowed or blocked based on classification criteria (e.g., depending on the network configuration). The NG-RAN may broadcast barring control information associated with an access class and an access identity.

[0094] The WTRU may perform an access control check to determine, for example, whether access is allowed when (e.g., when) the WTRU attempts (e.g., needs) to access a network (e.g., 5GS). An access control check may be performed on an access attempt. The NAS layer in the WTRU may map the access attempt to one or more access identifiers and (e.g., one) access category. The access category (e.g., each access category) may be selected from a set of standardized access categories and / or operator-defined access categories. The NAS layer may provide the access identifier and access category to lower layers. The lower layers may perform an access barring check based on the determined access identifier and access category (e.g., comparing it to broadcast information from the NG-RAN). For example, if the lower layers indicate that the access attempt is allowed, the NAS may initiate a process for transmitting an initial NAS message for the access attempt.

[0095] NAS level congestion control may be provided and / or enabled. NAS level congestion control may be applied generally (e.g., for all NAS messages), per data network name (DNN), per individual network slice selection assistance information (S-NSSAI), per DNN and S-NSSAI, and / or for a specific set of WTRUs.

[0096] NAS-level congestion control may be achieved by providing a back-off time to the WTRU (e.g., each rejected WTRU). To avoid a large number of WTRUs initiating delay requests (e.g., almost) simultaneously, the core network (which may be a 5GC) may determine or select a back-off time for the WTRU (e.g., each WTRU). The back-off time may be determined or selected so that the back-off time is unique to the WTRU (e.g., unique to each WTRU so that the postponement requests cannot be synchronized). The back-off timer may be determined or selected to minimize the number of WTRUs applied at any time. When (e.g., when) the WTRU receives the back-off time, the WTRU may refrain from initiating (e.g., not initiating) (e.g., any) signaling (e.g., NAS signaling) regarding the applied congestion control. The WTRU may initiate signaling in one or more of the following conditions: the back-off timer expires; the WTRU receives a mobile termination request from the network; the WTRU initiates signaling for emergency services or high priority access; or the WTRU enters a (e.g., new) PLMN that may not be part of the equivalent PLMN list.

[0097] An access and mobility function (AMF) may reject NAS messages from a WTRU using (e.g., any) access network (AN) (such as a 5G-AN) in a general overload condition. The AN may indicate a reason code, such as reason code #22, which may indicate congestion. For example, upon (e.g., when) a NAS request is rejected, the AMF may communicate a mobility management backoff time to the WTRU. (e.g., except for deregistration procedures and / or procedures that are not congestion controlled, such as, for example, high priority access, emergency services, and mobile terminated services), for example, the WTRU may refrain from initiating (e.g., not initiating) (e.g., any) NAS request if (e.g., while) the mobility management backoff time is being tracked (e.g., the backoff timer is running).

[0098] Multiple local services may be hosted (e.g., simultaneously). For example, when the hosted network is a stand-alone non-public network (SNPN), multiple local services may be hosted. A CAG cell (e.g., when the hosted network is a PNI-NPN) may support access to local services and / or regular services. There may be many WTRUs within the coverage of a hosted network (e.g., an SNPN cell or a CAG cell). The number of WTRUs may cause congestion in the hosted network. A network operator (e.g., an SNPN operator or a PLMN operator) may prioritize service users (e.g., prioritize certain service users when congestion occurs in the hosted network). For example, in an SNPN hosted network, a network operator may prioritize access to local service A while restricting access to local service B. For example, in a PNI-NPN hosted network, a PLMN operator may prioritize access to regular services and may restrict access to local services.

[0099] The hosted network may control access to various services to alleviate overload and congestion. The hosted network (PNI-NPN or SNPN) may implement access control. The hosted network (PNI-NPN) may handle congestion. For example, the hosted network may transmit a cause code to indicate the reason for rejecting the WTRU and / or a back-off time to reduce the frequency of access requests (e.g., repeated access requests from the WTRU).

[0100] A network architecture may be provided and / or used for networks used herein.

[0101] For example, for overload and congestion handling, cause codes may be used. For example, backoff timers may be used to improve overload and congestion handling. Congestion handling during initial registration, signaling procedures (e.g., NAS signaling procedures), and connection establishment / recovery / release (e.g., RRC connection establishment / recovery / release) may be enabled.

[0102] Defined access identities for localized services and access categories defined by the hosting network may be provided, for example, to perform access control and prohibit wireless transmit / receive units (WTRUs) from accessing the hosting network (eg, via a CAG cell).

[0103] A network may be congested, for example, based on the number of wireless transmit / receive units (WTRUs) connected. A WTRU may access a service using a closed access group (e.g., a local user group). For example, access to a service via a first closed access group (CAG) may be congested based on the number of WTRUs connected. A WTRU may switch to a different CAG to access a service, for example, to improve access control and congestion handling. Overload and congestion handling may be enabled for a CAG cell providing a local service.

[0104] For example, the WTRU may determine that service is provided by a first CAG and a second CAG. The WTRU may transmit a registration request to the first CAG. For example, based on congestion, the WTRU may receive a first indication indicating that registration (e.g., to the first CAG) was rejected. The WTRU may transmit a second registration request to the second CAG (e.g., based on the received indication). The WTRU may receive a second indication indicating that registration (e.g., to the second CAG) was successful.

[0105] In an example, the first indication indicating that the registration to the first CAG was rejected may indicate a back-off time. The back-off time may be a duration of time that the WTRU waits before transmitting another registration request (e.g., where the back-off time may be specific to the first CAG for which the registration was rejected). The back-off time may be specific to the WTRU (e.g., different for other WTRUs), for example, to prevent simultaneous registration requests. The WTRU may determine that the back-off time has elapsed. The WTRU may transmit another registration request to the first CAG (e.g., based on determining that the back-off time has elapsed).

[0106] Local services may be provided, for example, via a PNI-NPN or SNPN.

[0107] For example, a SNPN may host multiple local services (eg, simultaneously).

[0108] For example, the PNI-NPN may include one or more CAG cells (e.g., within the PLMN). Local services may be provided by the PLMN operator itself or by a third-party service provider (e.g., having signed a service agreement with the PLMN operator). Potential local service users may include PLMN subscribers (e.g., including roaming users). Users may or may not have a subscription to the PLMN operator for accessing local services.

[0109] A CAG cell (e.g., supporting local services) may be dedicated. For example, a WTRU may access local services (e.g., only) from a CAG cell. A CAG cell may be non-dedicated. For example, a WTRU may access local services and other PLMN services from a CAG cell.

[0110] Figure 2An example network architecture for accessing local services via a PNI-NPN is illustrated. Unified access control optimization may be provided and / or enabled for a WTRU accessing a local service hosted network. Access control optimization for a hosted network may include providing local services via an SNPN or a PNI-NPN / CAG cell. An access identifier (e.g., a specific access identifier) ​​may be used to access local services. The access identifier (e.g., a specific access identifier) ​​may be (pre-)configured within the WTRU (e.g., via a Universal Subscriber Identity Module (USIM)) or may be configured via signaling (e.g., NAS signaling).

[0111] UISM base files (such as EF_UAC_AIC) may be enhanced (eg, to include access identification values ​​specific to use by localized services).

[0112] Signaling (e.g., NAS signaling) may be used to push access identity validity (e.g., a determination of whether the access identity is valid / invalid) to the WTRU (e.g., by an AMF, a hosting network, or a third party service provider). Signaling (e.g., NAS signaling) for pushing access identity validity may be implemented via a network feature that supports an information element (IE) or a new IE, for example, within a message (e.g., a Registration Accept NAS message). Signaling (e.g., NAS signaling) for pushing access identity validity may be implemented via a Priority Indicator IE or a new IE, for example, as part of a message (e.g., a Configuration Update NAS message).

[0113] An access identifier associated with (e.g., specific to) access to a local service provided by a hosted network may allow the hosted network to perform one or more of the following: differentiate between (e.g., high) priority subscribing WTRUs (e.g., WTRUs that have been assigned an access identifier) ​​from regular subscribers (e.g., providing priority access to premium subscription customers / WTRUs); differentiate between inbound roamers and home subscribers accessing localized services; prioritize access to non-dedicated CAG cells based on network priority; prioritize access to (e.g., certain) local services based on network priority (e.g., when multiple local services are supported in the network); or perform cell load balancing and congestion control (e.g., in high load conditions, access control and barring may be used to redirect WTRUs to different cells for accessing local services).

[0114] The access identifier may be used to access local services and may enable the hosting network to prioritize access to non-dedicated CAG cells based on network priority. For example, if a WTRU may be attempting to access localized services (e.g., via a non-dedicated CAG cell), the WTRU may be given priority over a WTRU that is accessing the same CAG cell for regular services, or vice versa.

[0115] In a roaming environment, the WTRU may consider an access identifier associated with (e.g., specific to) a localized service to be valid (e.g., if the current PLMN provides the access identifier, for roaming scenarios, consideration of (e.g., may not be considered) such as a visitor PLMN after registration / sending NAS signaling and / or the value is stored in the USIM).

[0116] The hosting network may provide the WTRU with a hosted network defined access class, e.g., via (e.g., NAS) signaling (e.g., registration / mobility / configuration update commands, SoR, UE / WTRU parameter update procedures, etc.). The hosted network defined access class may be similar to the operator defined access class (e.g., except that these access classes may be applicable (e.g., only) to access attempts for localized services).

[0117] Managed network access category criteria may include one or more of: localized service type (eg, identifier); time validity; and location validity.

[0118] The WTRU may use access class criteria (eg, when selecting an access class for an access attempt to access a localized service).

[0119] Under high network load conditions, the hosted network may protect itself using a (e.g., existing) unified access control mechanism with (e.g., new) updates (e.g., access identifiers (e.g., new access identifiers) and access categories defined (e.g., specifically) for access localization services).

[0120] Figure 3 An example access identifier for a localized service is illustrated.

[0121] like Figure 3 As shown, at 0, the WTRU may be pre-configured with an access identity for localized services (e.g., in a USIM EF_UAC_AIC). The WTRU may attempt to use the access identity for localized services for (e.g., all) accesses with respect to localized services (e.g., when attempting to register with the HPLMN or equivalent HPLMN). The access identity may be used in (e.g., any) PLMN. For example (e.g., in a visitor PLMN scenario), the WTRU may monitor a validity flag from the network (e.g., if the validity flag is available).

[0122] like Figure 3As shown at 1, IE network feature support may (e.g., optionally) be extended to include a valid access identifier for localized services (e.g., a Boolean flag true / false). For example, the access identifier may be transmitted by the core network (e.g., 5GC). The access identifier may be transmitted via a message (e.g., signaling, such as including the access identifier in a registration accept NAS message). For example, if the access identifier for localized services is not configured in the USIM, (e.g., in a visitor PLMN or in an HPLMN / equivalent HPLMN use case) the access identifier validity bit for localized services may indicate that the access identifier for localized services is valid and may be used by the WTRU to access the localized services.

[0123] like Figure 3 As shown at 2, an IE priority indicator (e.g., a pre-existing IE priority indicator) may be extended to include a valid access identifier for localized services (e.g., a Boolean flag true / false). The extended IE priority indicator may be transmitted by the core network (e.g., 5GC). The extended IE priority indicator may be signaled (e.g., included in a WTRU configuration update command NAS message). For example, if the access identifier for localized services is not configured in the USIM, (e.g., in a visitor PLMN or in an HPLMN / equivalent HPLMN use case) the access identifier validity bit for localized services may indicate that the access identifier for localized services is valid and can be used by the WTRU to access the localized services.

[0124] like Figure 3 As shown at 3, an IE (e.g., a new IE) may be defined to carry an "access identity for localized services" validity flag via (e.g., NAS) signaling (e.g., registration procedure, SoR, WTRU configuration update command, WTRU parameter update, DL NAS transmission, policy container, etc.). For example, if the access identity for localized services is not configured in the USIM, (e.g., in a visitor PLMN or in an HPLMN / equivalent HPLMN use case) the access identity for localized services validity bit (e.g., included in the IE) may indicate that the access identity for localized services is valid and can be used by the WTRU to access the localized services.

[0125] like Figure 3As shown at 4, based on the service type (e.g., if the service type is a regular service or a localized service), the WTRU (e.g., the NAS layer of the WTRU) may determine or select an access identifier and an applicable access category. The access identifier and / or the applicable access category may be determined or selected from the access categories defined by the hosting network (e.g., if the request is for a local service) and / or the standard access categories (e.g., if the request is for a regular service). The WTRU may provide the determined or selected access identifier and / or the applicable access category to the AS layer to perform access barring. The WTRU (e.g., the AS layer) may determine the applicable access barring information based on the access barring information broadcasted (e.g., via the cell). The WTRU (e.g., the AS layer) may perform an access barring check using the information provided by the NAS layer. For example, if the access barring is successful and radio access is allowed (e.g., by the NG-RAN), the NAS layer may continue its process (e.g., registration) with the (e.g., 5G) core network.

[0126] Localized services may have validity (e.g. based on time and location). The core network (such as 5GC) may use (e.g. NAS signaling) messages to enable / disable the "access identity for localized services" validity flag. Enabling and / or disabling the "access identity for localized services" validity flag may ensure (e.g. by NG-RAN using unified access control) that access attempts occurring outside of a time window or location where there is no localized service are blocked.

[0127] In a home environment (e.g., a WTRU registered with the HPLMN or Equivalent HPLMN (EHPLMN)), the access identity value for localized services configured in the USIM may take precedence over the validity flag provided by the network (e.g., via NAS signaling). If the network wants to disable / enable or remove / add the access identity for localized services in the USIM, the network may trigger a SIM refresh procedure, for example, to update the contents of the USIM EF_UAC_AIC, thereby removing / adding the access identity for localized services.

[0128] Figure 4 An example managed network defined access category is illustrated.

[0129] like Figure 4 As shown at 1, for example, the access category defined by the hosting network may be signaled by the core network (e.g., 5GC). The access category may be signaled via NAS signaling (e.g., registration procedure, SoR, WTRU configuration update command, WTRU parameter update, DL NAS transmission, policy container, etc.).

[0130] The access category criteria defined by the hosted network may include additional information (e.g., in addition to (e.g., existing) operator-defined access categories, such as DNN / slice / OS Id / application Id)). The access category criteria defined by the hosted network may include one or more of the following: a localized service type identifier (e.g., an access category applicable to a specific localized service, which access category may enable service differentiation to be created on the hosted network side); validity criteria based on time and / or location (e.g., the validity criteria may ensure that access attempts to localized services are allowed (e.g., only) within a region and within a specific time window).

[0131] like Figure 4 As shown at 2, based on the service type (e.g., if the service type is a regular service or a localized service), the WTRU (e.g., the NAS layer of the WTRU) may determine the access identity and the applicable access category in the access category defined by the hosting network (e.g., if the request is for a local service) or the standard access category (e.g., if the request is for a regular service). The WTRU (e.g., the NAS layer of the WTRU) may provide this information (e.g., to the AS layer) to perform access barring. The WTRU (e.g., the AS layer) may determine the applicable access barring information (e.g., based on the access barring information broadcast via the cell) and perform an access barring check using the information provided by the NAS layer. For example, if the access barring is successful and radio access is allowed (e.g., by the NG-RAN), the NAS layer may continue its process (e.g., registration) with the core network (e.g., 5G).

[0132] In an example, the hosting network may apply service-specific access barring in its cell. For example, a CAG cell that supports both local services and regular services may broadcast access barring information for local services and regular services, respectively (e.g., two access barring information sets). The WTRU (e.g., the NAS layer in the WTRU) may determine whether the WTRU is accessing the cell for local services or regular services. The WTRU may indicate (e.g., to the AS layer) whether the WTRU is accessing the cell for local services or regular services. The WTRU (e.g., the AS layer) may determine which access barring information set may be applied. For example, a cell that supports multiple local services (e.g., an SNPN cell or a CAG cell) may broadcast multiple access barring information sets (e.g., where each barring information set is associated with one or more services). The WTRU (e.g., the NAS layer in the WTRU) may indicate (e.g., to the AS layer) the desired service identifier. The WTRU (e.g., the AS layer) may determine the access barring information set associated with the requested service (e.g., based on the access identity of the service identifier selected by the NAS layer / user / application layer and the access category defined by the applicable hosting network).

[0133] The hosting network may prioritize access to certain services and block access to other services (e.g., by adjusting information in various sets of access barring information) to alleviate congestion in the network. This method may be used in combination with assigning (e.g., new) access identifiers or access categories to local service users (e.g., as described herein).

[0134] Congestion control for a hosted network (e.g., PNI-NPN) may be enabled. The hosted network may support measures to protect itself from conditions where network functions are overloaded (e.g., peak operating times, extreme overload, number of WTRUs requesting access to local services (e.g., large numbers), performance degradation, etc.). For example, the hosted network may deploy measures to control congestion and overload to ensure that network functions (e.g., for the hosted network) operate at nominal capacity for providing necessary localized services to the WTRUs.

[0135] The hosting network (e.g., 5GC) may implement (e.g., NAS-level) congestion control. For example, the hosting network may implement general NAS-level congestion control, where the AMF may reject a NAS request from the WTRU with a cause code (e.g., cause code #22, which may indicate congestion), and the rejecting AMF may provide a backoff time (e.g., via a backoff timer, such as, for example, T3346). The backoff time may (e.g., temporarily) restrict the WTRU from making any further NAS requests (e.g., except for deregistration procedures and procedures that are not congestion controlled, such as, for example, high priority access, emergency services, and mobile terminated services).

[0136] In an example, the hosted network may be a PNI-NPN (e.g., a CAG cell). If a CAG cell (e.g., a specific CAG cell) is overloaded, the network may determine to redirect the WTRU to other CAG cells that are not overloaded (e.g., other CAG cells that will not reject the WTRU using a general NAS-level congestion cause #22 message). The redirection of the WTRU may not restrict (e.g., any new) NAS requests from the WTRU to the full hosted network and its equivalent hosted network (ePLMN) (e.g., the restriction may occur using a NAS-level congestion cause #22 message). If the WTRU is restricted from camping on other CAG cells (e.g., not allowed to camp), it may be restricted from triggering a NAS request (registration procedure).

[0137] The hosting network may handle an overload condition of a CAG cell (e.g., a CAG cell) by redirecting the WTRU to a different CAG cell that provides access to localized services, and / or backing off the WTRU from an overloaded or congested CAG cell (e.g., by signaling a backoff time).

[0138] Figure 5Examples of overload and congestion handling for a hosted network and for initial registration are illustrated.

[0139] like Figure 5 As shown at 1, the WTRU may perform cell selection for a CAG cell. For example, it may do so based on the requested local service (e.g., local service identifier-1). The WTRU may find CAG cells CAG-1 and CAG-2 that provide the requested local service. The WTRU may perform an initial registration with CAG-1. A registration request may be transmitted to the AMF via CAG-1, for example, including the requested local service identified via LS ID-1.

[0140] like Figure 5 CAG-1 may be in an overloaded and congested condition, shown at 2. Other CAG cells (eg, CAG-2) may be nearby and may provide access to local services identified via LS ID-1.

[0141] like Figure 5 As shown at 3, the AMF of the hosting network may reject the initial Registration Request using a "congestion" cause code (e.g., a new cause code) and may provide a back-off time value (e.g., tracked via a back-off timer). The rejection cause may apply to the (e.g., currently) residing CAG cell (e.g., CAG-1). The AMF may select the back-off time value so that deferred Registration Requests (e.g., from different WTRUs) are not synchronized, for example to avoid a certain amount (e.g., a large number) of WTRUs initiating deferred Registration Requests at the same time or close to the same time (e.g., at the same time).

[0142] like Figure 5 As shown at 4, CAG-1 may not be applicable for accessing local services. The WTRU may start tracking the backoff time for each CAG-1 (e.g., via a backoff timer). While tracking the backoff time, the WTRU may refrain from initiating (e.g., NAS) requests for CAG-1 cells (e.g., the WTRU may not initiate any NAS requests). The WTRU may trigger cell selection for accessing local services LS ID-1. CAG-2 may be a possible candidate cell and the WTRU may camp on and trigger an initial registration on CAG-2.

[0143] like Figure 5 As shown at 5, a registration request for local service LS ID-1 may be transmitted to the hosting network via CAG-2.

[0144] like Figure 5 The hosting network may accept the registration as shown at 6. The WTRU may successfully register for local services.

[0145] In an example, the overload and congestion handling specified for initial registration may be extended to other NAS procedures (e.g., mobility registration update procedure, service request procedure, etc.). The hosting network may trigger deregistration to the WTRU to overcome overload and congestion, and may provide the WTRU with a backoff time value for each CAG cell.

[0146] Figure 6 Examples of overload and congestion handling (eg, RRC connection establishment / recovery / release) for a hosted network are illustrated.

[0147] like Figure 6 CAG-1 may be in an overloaded and congested condition, shown at 0. Other CAG cells (eg, CAG-2) may be nearby, which may provide access to local services identified via LS ID-1.

[0148] like Figure 6 As shown at 1a / 1b, the WTRU may (e.g., attempt to) establish an initial RRC connection with the NG-RAN / CAG-1, or the RRC connection is suspended and the WTRU may (e.g., attempt to) resume the RRC connection. Since CAG-1 may be in an overload condition, the NG-RAN may use "RRC Reject" to reject the RRC connection establishment or resumption, and provide a rejected CAG list (CAG-1), RRC redirection information containing nearby available CAG cells, and a local service support identifier and a backoff time value for CAG-1.

[0149] like Figure 6 As shown at 2, (e.g., alternatively) the WTRU may be in RRC connected mode, and (e.g., to handle overload / congestion) the hosting network may decide (e.g., via an RRC release message) to release the RRC connection and provide a rejected CAG list (CAG-1), RRC redirection information containing nearby available CAG cells, and a local service support identifier and a backoff time value for CAG-1.

[0150] like Figure 6 As shown at 3, CAG-1 may not be applicable for accessing local services. The WTRU may start tracking the backoff time for each CAG-1 (e.g., via a backoff timer). While tracking the backoff time, the WTRU may refrain from initiating NAS requests for CAG-1 cells (e.g., the WTRU may not initiate NAS requests). The WTRU may trigger cell selection for accessing local services LS ID-1. Based on the provided RRC redirection information, CAG-2 may be a possible candidate cell and the WTRU may camp on and trigger an initial registration on CAG-2.

[0151] like Figure 6As shown at 4, a registration request for local service LS ID-1 may be transmitted to the hosting network, for example, via CAG-2.

[0152] like Figure 6 The hosting network may accept the registration as shown at 5. The WTRU may successfully register for local services.

[0153] Although the above features and elements are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without the other features and elements.

[0154] Although the implementation described herein may consider 3GPP specific protocols, it should be understood that the implementation described herein is not limited to such scenarios and is applicable to other wireless systems. For example, although the solution described herein considers LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solution described herein is not limited to such scenarios and is also applicable to other wireless systems.

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

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: A processor, the processor being configured to: determining a local service identifier associated with a first closed access group (CAG) and a second CAG; transmitting a first registration request to the first CAG based on the local service identifier; receiving a first message, wherein the first message includes an indication that the first registration request for the first CAG is rejected, a reason code, and a fallback value; as well as A second registration request is transmitted to the second CAG based on the indication that the first registration request to the first CAG was rejected, the reason code and the backoff value.

2. The WTRU of claim 1 , wherein the cause code indicates congestion.

3. The WTRU of any one of claims 1 to 2, wherein the processor is further configured to: The backoff value is determined to have elapsed based on a time when the first message is received.

4. The WTRU according to any one of claims 1 to 3, wherein the first message also includes a redirection indication indicating that the second CAG is available.

5. The WTRU of any one of claims 1 to 4, wherein the processor is further configured to: Transmit a third registration request to the first CAG.

6. The WTRU of any one of claims 1 to 5, wherein the processor is further configured to: Receive a second message, wherein the second message indicates that the WTRU is registering with the second CAG.

7. A WTRU according to any one of claims 1 to 6, wherein the first registration request includes an access identifier associated with the WTRU, wherein the first message is based on the access identifier, and wherein the processor is further configured to receive the access identifier.

8. The WTRU of claim 7, wherein the access identifier indicates that the WTRU has permission to access localized services.

9. The WTRU of any one of claims 1 to 8, wherein the first message further comprises a localized service identifier.

10. A method performed by a wireless transmit-receive unit (WTRU), the method comprising: determining a first local service identifier associated with a first closed access group (CAG) and a second CAG; transmitting a first registration request to the first CAG based on the first local service identifier; receiving a message from an access and mobility function, wherein the message includes an indication that the first registration request for the first CAG is rejected, a reason code, and a fallback value; as well as A second registration request is transmitted to the second CAG based on the indication that the first registration request to the first CAG was rejected, the reason code and the backoff value. The method of claim 10 , wherein the cause code indicates congestion.

12. The method according to any one of claims 10 to 11, further comprising: The backoff value is determined to have elapsed based on a time when the message is received.

13. The method according to any one of claims 10 to 12, wherein the message further comprises a redirection indication indicating that the second CAG is available.

14. The method according to any one of claims 10 to 13, further comprising: In a case where it is determined that the backoff value has elapsed, a third registration request is transmitted to the first CAG.

15. The method according to any one of claims 10 to 14, wherein the message is a first message, and wherein the method further comprises: Receive a second message, wherein the second message indicates that the WTRU is registering with the second CAG.

16. A method according to any one of claims 10 to 15, wherein the first registration request includes an access identifier, wherein the access identifier is associated with the WTRU, wherein the message is based on the access identifier, and wherein the method further comprises receiving the access identifier associated with the WTRU.

17. The method of claim 16, wherein the access identifier indicates that the WTRU has permission to access localized services.

18. The method according to any one of claims 10 to 17, wherein the message further comprises a localized service ID.

Images