Hosting Network Access Control and Congestion Handling

Abstract

Systems and methods for hosting network overload and / or congestion handling (e.g., for a closed access group (CAG) cell providing a local service) 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 send 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) including an indication that registration to the first CAG is denied, a cause code, and a back-off value. The device may send a second registration request to the second CAG based on the indication that registration to the first CAG is denied, the cause code, and the back-off value.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 392,473, filed July 26, 2022, the contents of which are hereby incorporated by reference herein. [Background technology]

[0002] Mobile communications using radio communications continues to evolve. The fifth generation is sometimes referred to as 5G. Previous (traditional) generations of mobile communications may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the Invention

[0003] Systems and methods for hosting network overload and / or congestion handling (e.g., for a closed access group (CAG) cell providing a local service) 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 send 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) including an indication that registration to the first CAG is denied, a cause code, and a back-off value. The device may send a second registration request to the second CAG based on the indication that registration to the first CAG is denied, the cause code, and the back-off value.

[0004] The cause code may indicate congestion.

[0005] The device may determine that the backoff value has elapsed based on the time the first message was received. The device may send a third registration request to the first CAG (e.g., after the backoff value has elapsed).

[0006] The first message may further include a redirection indicator indicating that a second CAG is available.

[0007] The device may receive a second message that may indicate that the WTRU is registered with a second CAG.

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

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

[0010] Procedures may be used by the hosting network (e.g., PNI-NPN or SNPN) to implement access control. The hosting network may define access identities for localized services. The hosting network may define access categories (e.g., to bar WTRUs accessing the hosting network via a CAG cell (PNI-NPN)).

[0011] Procedures may be used by the hosting network (e.g., PNI-NPN) to handle overload and / or congestion handling. For example, the hosting network may provide a cause code and / or a back-off timer to the WTRU during the WTRU's initial registration. [Brief explanation of the drawings]

[0012] [Figure 1A]FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] 1A is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2] 1 illustrates an exemplary network architecture for accessing local services via a public network integrated non-public network (PNI-NPN). [Figure 3] 1 illustrates an exemplary access identity for localized services. [Figure 4] 1 illustrates an exemplary hosting network-defined access category. [Figure 5] 1 illustrates an example of overload and congestion handling for a hosting network and initial registration. [Figure 6] Illustrates examples of overload and congestion handling for a hosting network and radio resource control (RRC) connection setup / resume / release procedures. DETAILED DESCRIPTION OF THE INVENTION

[0013] 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. 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 direct Fourier transform (DFT) spread OFDM (zero-tail unique-word DTS-s OFDM, ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multicarrier (FBMC).

[0014] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and / or "STA," may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., a robot and / or other wireless device operating in an industrial and / or automated processing chain context), a consumer electronics device, a device operating on a commercial wireless network and / or an industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0015] The communications 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 configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications 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 eNode B (eNB), a Home Node B, a Home eNode B, a gNode B (gNB), an NR Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0016] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or 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 a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

[0017] 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).

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

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

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

[0021] In one 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 implement both LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions to and from multiple types of base stations (e.g., eNBs and gNBs).

[0022] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology 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), GSM EDGE (GERAN), or the like.

[0023] 1A 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 a local area such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. 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 one 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 establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106 / 115.

[0024] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, mobility, 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 shown in FIG. 1A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, the CN 106 / 115, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0025] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, which use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 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.

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

[0027] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, 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 understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0028] The 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, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0032] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered 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. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

[0034] 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) regarding 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) 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 way of any suitable location-determination method while remaining consistent with an embodiment.

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

[0036] The WTRU 102 may include a full-duplex radio (e.g., where transmission and reception of some or all of the signals associated with a particular subframe for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference through either hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or downlink (e.g., for reception)).

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

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

[0039] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

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

[0041] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. 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.

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

[0043] The SGW 164 may be connected to a 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.

[0044] 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 fixed-line communication devices. For example, the CN 106 may include or communicate 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. Additionally, the CN 106 may provide the WTRUs 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.

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

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

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

[0048] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit 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 that is dynamically set via signaling. The primary channel may be the operating channel of the BSS, but may be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. One STA (e.g., only one station) may transmit in a given BSS at any given time.

[0049] High Throughput (HT) STAs may use 40 MHz wide channels for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

[0051] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 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 may support meter-type control / machine-type communications, such as MTC devices, within a macro coverage area. MTC devices may have limited capabilities, including, for example, support for (e.g., only support for) certain specific and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0052] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, 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 sensing and / or Network Allocation Vector (NAV) configuration can depend on the status of the primary channel. For example, if the primary channel is busy due to a STA (that only supports 1 MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and be available for use.

[0053] In the United States, the available frequency band that can be used by 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.

[0054] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned 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 communicate with the CN 115.

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

[0056] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

[0057] 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 without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize 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 unlicensed spectrum. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles 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 eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0058] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0059] 1D 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 the CN operator.

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

[0061] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 115 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 115 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions such as managing and assigning 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.

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

[0063] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or 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. Additionally, the CN 115 may provide the WTRUs 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. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0064] 1A-1D and the corresponding descriptions thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a and 114b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a and 182b, UPFs 184a and 184b, SMFs 183a and 183b, DNs 185a and 185b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0066] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0067] References herein to a timer may refer to a time (e.g., a value), a period, keeping track of time, keeping track of a period, etc. References herein to a timer expiry may refer to determining that the time has occurred or that the period has expired. A timer may be based on a start time (e.g., a value), such as when a message is sent or received.

[0068] Systems and methods for hosting network access control and / or congestion handling are described herein. Cause codes may be used for overload and congestion handling. For example, upon receiving a registration request from a WTRU, the hosting network (e.g., a closed access group) may send a response including a cause code. The cause code may indicate congestion. The response may deny the WTRU's registration and may include a back-off timer. The back-off timer may be used to improve overload and congestion handling (e.g., by reducing the frequency of requests, such as during periods of congestion). Handling for congestion during initial registration, signaling procedures (e.g., NAS signaling procedures), and / or connection setup / resume / release (e.g., RRC connection setup / resume / release), etc. may be enabled.

[0069] The access identifier may be defined (e.g., by the 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).

[0070] The network may become congested (e.g., due to the number of connected wireless transmit / receive units (WTRUs)). The WTRUs may access the service using a closed access group (CAG) (e.g., a group of local users). Access to the service via a first CAG may become congested, for example, based on the number of connected WTRUs. The WTRU may switch to a different CAG to access the service (e.g., during periods of congestion on the first CAG), for example, to improve access control and congestion handling. Overload and congestion handling for the CAG cells providing local services may be enabled.

[0071] For example, the WTRU may determine that a service is provided by a first CAG and a second CAG. The WTRU may send a registration request message to the first CAG. The WTRU may receive a first indication indicating that registration (e.g., to the first CAG) is denied, e.g., based on congestion. The WTRU may send 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.

[0072] In an example, the first indication that registration to the first CAG was denied may indicate a back-off time (e.g., a value). The back-off time may be a duration for the WTRU to wait before sending another registration request (e.g., the back-off time may be specific to the first CAG for which registration was denied). The back-off time may be specific (e.g., unique) to the WTRU (e.g., different from other WTRUs), e.g., to prevent simultaneous registration requests. The WTRU may determine that the back-off time has elapsed. The WTRU may send another registration request to the first CAG (e.g., based on the determination that the back-off time has elapsed). Providing access to localized services (PALS) may be enabled.

[0073] Systems and methods for hosting network overload and / or congestion handling (e.g., for a closed access group (CAG) cell providing a local service) 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 send 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) including an indication that registration to the first CAG is denied, a cause code, and a back-off value. The device may send a second registration request to the second CAG based on the indication that registration to the first CAG is denied, the cause code, and the back-off value.

[0074] The cause code may indicate congestion.

[0075] The device may determine that the backoff value has elapsed based on the time the first message was received. The device may send a third registration request to the first CAG (e.g., after the backoff value has elapsed).

[0076] The first message may further include a redirection indicator indicating that a second CAG is available.

[0077] The device may receive a second message that may indicate that the WTRU is registered with a second CAG.

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

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

[0080] Procedures may be used by the hosting network (e.g., public network integrated NPN (PNI-NPN) or SNPN) to implement access control. The hosting network may define access identities for localized services. The hosting network may define access categories (e.g., to bar WTRUs accessing the hosting network via a CAG cell (PNI-NPN)).

[0081] Procedures may be used by the hosting network (e.g., PNI-NPN) to handle overload and / or congestion handling. For example, the hosting network may provide a cause code and / or a back-off timer to the WTRU during the WTRU's initial registration.

[0082] A local service may include a service available in a (e.g., limited) area and / or duration. For example, a local network (e.g., a temporary local network) may be set up at a sporting event or outdoor fairground where a cellular network is not available. A local network over which a local service is provided may be referred to as a hosting network. A hosting network may (e.g., typically) not be permanent (e.g., may be a short-term implementation without a permanent infrastructure). A hosting network may be a permanent network. A hosting network may be a Standalone 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 hosting network operator or a third-party service provider.

[0083] A PNI-NPN may be provisioned and / or enabled. The PNI-NPN may be a non-public network made available using PLMN infrastructure / resources, e.g., a PLMN network slice. A group of PLMN users (e.g., who may be authorized to access a certain 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 access the PNI-NPN (e.g., only the PNI-NPN) from a cell that supports CAG access, e.g., which may be referred to as a CAG cell. A CAG cell may broadcast a list of supported CAG identifiers (e.g., that the CAG cell 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). If (e.g., when) a CAG WTRU detects a CAG cell, the CAG WTRU may select / access the CAG cell (e.g., only 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.

[0084] A unified access control may be provided and / or enabled. A WTRU may establish a wireless connection with a radio access network (NG-RAN), for example, to transmit a message (e.g., an initial NAS message). The NAS layer may provide (e.g., RRC) connection establishment-related information to lower layers, which may be used by the RAN to determine the priority of the connection and whether the connection can be established (e.g., whether access can be allowed or blocked). The network may protect itself from overload (e.g., under high network load conditions) by, for example, restricting access attempts from the WTRU using a unified access control function. The network may determine whether an access attempt (e.g., an access attempt) can be allowed or blocked based on classified criteria, for example, depending on the network configuration. The NG-RAN may broadcast barring control information associated with an access category and an access identity.

[0085] The WTRU may perform an access control check to determine whether access is permitted, e.g., whether (e.g., when) the WTRU is attempting to (e.g., needs to) access a network (e.g., 5GS). The access control check may be performed for an access attempt. The NAS layer in the WTRU may map the access attempt to one or more access identities and (e.g., one) access category. The access categories (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 identities and access categories to lower layers. The lower layers may perform an access barring check based on the determined access identities and access categories (e.g., by comparing it with broadcast information from the NG-RAN). The NAS may, for example, initiate a procedure to send an initial NAS message for the access attempt if the lower layers indicate that the access attempt is permitted.

[0086] NAS-level congestion control may be provided and / or enabled and may be applied generally (e.g., for all NAS messages), per data network name (DNN), per Single-Network Slice Selection Assistance Information (S-NSSAI), per DNN and S-NSSAI, and / or for specific groups of WTRUs.

[0087] NAS-level congestion control may be achieved by providing a back-off time to a WTRU (e.g., each rejected WTRU). To avoid a large number of WTRUs initiating deferred requests at (e.g., approximately) the same time, the core network, which may be 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 such that the back-off time is unique to the WTRU (e.g., for each WTRU such that deferred requests cannot be synchronized). The back-off timer may be determined or selected to minimize the number of WTRUs that apply at any time. If (e.g., when) the WTRU receives the back-off time, the WTRU may refrain from (e.g., not initiate) any signaling (e.g., NAS signaling) regarding the applied congestion control. The WTRU may initiate signaling under one or more of the following conditions: when a backoff timer expires; when the WTRU receives a mobile terminated request from the network; when the WTRU initiates signaling for emergency services or high priority access; or when the WTRU enters a (e.g., new) PLMN (which may not be part of the equivalent PLMN list).

[0088] 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, under general overload conditions. The AN may indicate a cause code, such as cause code #22, which may indicate congestion. A mobility management back-off time may be sent by the AMF to the WTRU, for example, if (e.g., when) an NAS request is rejected. The WTRU may refrain from (e.g., not initiate) initiating (e.g., any) NAS request (except, for example, a de-registration procedure and / or a procedure not subject to congestion control, such as, for example, high priority access, emergency services, and mobile terminated services) when (e.g., while) the mobility management back-off time is being tracked (e.g., a back-off timer is running).

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

[0090] The hosting network may control access to various services to alleviate overload and congestion. The hosting network (PNI-NPN or SNPN) may implement access control. The hosting network (PNI-NPN) may handle congestion. For example, the hosting network may send a cause code indicating 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).

[0091] A network architecture may be provided and / or used for the network used herein.

[0092] For example, cause codes may be used for overload and congestion handling. Back-off timers may be used, for example, to improve overload and congestion handling. Handling for congestion during initial registration, signaling procedures (e.g., NAS signaling procedures), and connection setup / resume / release (e.g., RRC connection setup / resume / release) may be enabled.

[0093] For localized services and hosting network-defined access categories, defined access identities may be provided, for example, to perform access control and prohibit wireless transmit / receive units (WTRUs) from accessing the hosting network (e.g., via CAG cells).

[0094] The network may become congested, for example, based on the number of connected wireless transmit / receive units (WTRUs). The WTRUs may access the service using a closed access group (e.g., a group of local users). Access to the service via a first closed access group (CAG) may become congested, for example, based on the number of connected WTRUs. The WTRUs may switch to a different CAG to access the service, for example, to improve access control and congestion handling. Overload and congestion handling may be enabled for CAG cells providing local services.

[0095] For example, the WTRU may determine that a service is provided by a first CAG and a second CAG. The WTRU may send a registration request message to the first CAG. The WTRU may receive a first indication indicating that registration (e.g., to the first CAG) is denied, e.g., based on congestion. The WTRU may send 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.

[0096] In an example, the first indication that registration to the first CAG has been denied may indicate a back-off time. The back-off time may be a duration for the WTRU to wait before sending another registration request (e.g., the back-off time may be specific to the first CAG for which registration has been denied). The back-off time may be specific to the WTRU (e.g., different from other WTRUs), e.g., to prevent simultaneous registration requests. The WTRU may determine that the back-off time has elapsed. The WTRU may send another registration request to the first CAG (e.g., based on the determination that the back-off time has elapsed).

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

[0098] For example, an SNPN may host multiple local services (eg, at the same time).

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

[0100] A CAG cell (e.g., supporting local services) may be dedicated. For example, a WTRU may access local services (e.g., only local services) 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.

[0101] 2 illustrates an example network architecture for accessing local services via a PNI-NPN. Unified access control optimization for WTRUs accessing a local service hosting network may be provided and / or enabled. The access control optimization for the hosting network may include providing the local service via an SNPN or PNI-NPN / CAG cell. An access identity (e.g., a unique access identity) for accessing the local service may be used. The access identity (e.g., a unique access identity) may be (pre-)configured in the WTRU (e.g., via a Universal Subscriber Identity Module (USIM)) or may be configured via signaling (e.g., NAS signaling).

[0102] UISM elementary files such as EF_UAC_AIC may be extended (eg, to include access identity values ​​specific to localized service usage).

[0103] Signaling (e.g., NAS signaling) may be used (e.g., by the AMF, the hosting network, or a third-party service provider) to push the access identity validity (e.g., a determination of whether the access identity is valid / invalid) to the WTRU. The signaling (e.g., NAS signaling) for pushing the access identity validity may be implemented via a network capability support information element (IE) or a new IE, for example, in a message (e.g., a registration accept NAS message). The signaling (e.g., NAS signaling) for pushing the 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).

[0104] The access identity associated with (e.g., unique to) access to the localized service provided by the hosting network may enable the hosting network to perform one or more of the following: Differentiating (e.g., high) priority subscribed WTRUs (e.g., those assigned an access identity) from regular subscribers (e.g., priority access for premium subscribed customers / WTRUs); Differentiating inbound roamers from home subscribers accessing localized services; Prioritizing access for non-dedicated CAG cells based on network priority; Prioritizing access to (e.g., a particular) localized service based on network priority (e.g., when multiple localized services are supported in the network); or cell load balancing and congestion control (e.g., under high load conditions, access control and access barring may be used to redirect WTRUs to a different cell for accessing the localized service).

[0105] The access identity may be used to access localized services and may allow the hosting network to prioritize access for non-dedicated CAG cells based on network priority. For example, if a WTRU may be attempting to access a localized service (e.g., via a non-dedicated CAG cell), it may be prioritized over a WTRU accessing the same CAG cell for regular services, or vice versa.

[0106] In a roaming environment, the WTRU may consider an access identity associated with (e.g., specific to) a localized service to be valid (e.g., if the access identity is provided by a current PLMN, such as a visited PLMN, after registration / NAS signaling and / or if a value stored in the USIM is withheld (e.g., may not be taken into account) for roaming scenarios).

[0107] The hosting network may provide the hosting network-defined access categories to the WTRU, for example, via (e.g., NAS) signaling (e.g., Registration / Mobility / Configuration Update Command, SoR, UE / WTRU Parameter Update Procedure, etc.) The hosting network-defined access categories may be similar to the operator-defined access categories (e.g., with the difference that these access categories may be applicable to (e.g., only to) access attempts for localized services).

[0108] The hosting network access category criteria may include one or more of the following: localized service type (eg, identifier), time validity, and location validity.

[0109] The access category criteria may be used by the WTRU (eg, while selecting an access category for an access attempt to access a localized service).

[0110] Under high network load conditions, the hosting network can protect itself using a (e.g., existing) unified access control mechanism with (e.g., new) updates (e.g., (e.g., specifically) defined access identities (e.g., new access identities) and access categories for accessing localized services).

[0111] FIG. 3 illustrates an exemplary access identity for localized services.

[0112] As shown in FIG. 3, the WTRU may be pre-configured with an access identity for localized services (e.g., in the USIM EF_UAC_AIC). The WTRU may use the localized service access identity for (e.g., all) access attempts for the localized services (e.g., while registered in either the HPLMN or an 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 it is available).

[0113] As shown in FIG. 3, IE Network Capability Support may be extended to include (e.g., optionally) an access identity (e.g., a Boolean flag True / False) for the localized service that is valid. For example, the access identity may be sent by the core network (e.g., 5GC). The access identity may be sent via a message (e.g., signaled, such as including the access identity in a REGISTRATION ACCEPT NAS message). The validity bit of the access identity for the localized service may indicate that the access identity for the localized service is valid and can be used by the WTRU to access the localized service (e.g., in a visited PLMN or in an HPLMN / equivalent HPLMN use case), e.g., if the access identity for the localized service is not configured in the USIM.

[0114] As shown in FIG. 3-2, the IE priority indicator (e.g., the existing IE priority indicator) may be extended to include an access identity (e.g., a Boolean flag True / False) for a valid localized service. The extended IE priority indicator may be sent 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). The validity bit of the access identity for the localized service may indicate that the access identity for the localized service is valid and can be used by the WTRU to access the localized service (e.g., in a visited PLMN or in an HPLMN / equivalent HPLMN use case), e.g., if the access identity for the localized service is not configured in the USIM.

[0115] As shown in 3 of Figure 3, an IE (e.g., a new IE) may be defined to carry the access identity for localized services valid flag via (e.g., NAS) signaling (e.g., registration procedure, SoR, WTRU Configuration Update Command, WTRU Parameter Update, DL NAS Transport, Policy Container, etc.). The validity bit of the access identity for localized services may indicate that the access identity for localized services (e.g., included in the IE) is valid and can be used by the WTRU to access the localized services (e.g., in a visitor PLMN or in an HPLMN / equivalent HPLMN use case), e.g., if the access identity for the localized services is not configured in the USIM.

[0116] As shown in FIG. 3, based on the type of service (e.g., whether 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 identity and applicable access categories. The access identity and / or applicable access categories may be determined or selected from hosting-network-defined access categories (e.g., if the request is for a localized service) and / or standard access categories (e.g., if the request is for a regular service). The WTRU may provide the determined or selected access identity and / or applicable access categories to the AS layer to perform access barring. The WTRU (e.g., the AS layer) may determine applicable access barring information based on access barring information broadcasted (e.g., via the cell). The WTRU (e.g., the AS layer) may use the information provided by the NAS layer to perform the access barring check. The NAS layer may, for example, proceed with its procedure (e.g., registration) with the (e.g., 5G) core network if the access barring is successful and radio access is allowed (e.g., by NG-RAN).

[0117] The localized service may have validity (e.g., based on time and location). A core network such as 5GC may use messages (e.g., NAS signaling) to enable / disable the access identity for the localized service valid flag. Enabling and / or disabling the access identity for the localized service valid flag may ensure that access attempts occurring outside the time window or locations where the localized service does not exist are blocked (e.g., by NG-RAN using unified access control).

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

[0119] FIG. 4 illustrates an exemplary hosting network-defined access category.

[0120] The hosting network-defined access category may be signaled, for example, by the core network (e.g., 5GC), as shown in 1 of Figure 4. The access category may be signaled via NAS signaling (e.g., registration procedure, SoR, WTRU configuration update command, WTRU parameter update, DL NAS transport, policy container, etc.).

[0121] The hosting network-defined access category criteria may include additional information (e.g., in addition to the (e.g., existing) operator-defined access category, such as DNN / Slice / OS Id / App Id), the hosting network-defined access category criteria 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 may allow creating service differentiation on the hosting network side), or time- and / or location-based validity criteria (e.g., may ensure that access attempts for a localized service are allowed within an area and within (e.g., only within) a specific time window).

[0122] As shown in FIG. 4-2, based on the type of service (e.g., whether the service type is a regular service or a localized service), the WTRU (e.g., the NAS layer of the WTRU) may determine an access identity and an applicable access category from the hosting network-defined access category (e.g., if the request is for a localized 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., according to access barring information broadcast over the cell) and use the information provided by the NAS layer to perform an access barring check. The NAS layer may, for example, proceed with its procedure (e.g., registration) with the core network (e.g., 5G) if the access barring is successful and radio access can be granted (e.g., by NG-RAN).

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

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

[0125] Congestion control for the hosting network (e.g., PNI-NPN) may be enabled. The hosting network may support measures to protect itself from conditions where network functions are overloaded (e.g., peak operating hours, extreme overload, number (e.g., large number) of WTRUs requesting access to localized services, performance degradation, etc.). For example, the hosting network may deploy means for controlling congestion and overload to ensure that network functions (e.g., for the hosting network) are operating under their nominal capacity to provide the required localized services to the WTRUs.

[0126] 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 reject AMF may provide a back-off time (e.g., via a back-off timer, such as T3346). The back-off 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 subject to congestion control, such as high priority access, emergency services, and mobile terminated services).

[0127] In an example, the hosting network may be a PNI-NPN (e.g., a CAG cell). If a CAG cell (e.g., a particular CAG cell) is overloaded, the network may decide to redirect the WTRU to another CAG cell that is not overloaded (e.g., another CAG cell that does not reject the WTRU with a general NAS-level congestion cause #22 message). The redirection of the WTRU may not restrict (e.g., any new) NAS requests (e.g., as may occur with a NAS-level congestion cause #22 message) from the WTRU to the complete hosting network and its equivalent hosting networks (ePLMNs). If the WTRU is restricted from maintaining connections to (e.g., not allowed to maintain connections to) other CAG cells, the WTRU may be restricted from triggering NAS requests (registration procedures).

[0128] 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 by backing off the WTRU from an overloaded or congested CAG cell (e.g., by signaling a backoff time).

[0129] FIG. 5 illustrates an example of overload and congestion handling for the hosting network and initial registration.

[0130] As shown in FIG. 5 at 1, the WTRU may perform cell selection for a CAG cell. For example, the cell selection may be performed according to a 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 initial registration with CAG-1. A registration request may be sent to the AMF via CAG-1, for example, including the requested local service identified via LS ID-1.

[0131] As shown at 2 in Figure 5, CAG-1 may be overloaded and congested. Another CAG cell (e.g., CAG-2) may be nearby and may provide access to local services identified via LS ID-1.

[0132] As shown in FIG. 5(c), the AMF of the hosting network may reject the initial registration request with cause code congestion (e.g., new cause code) and may provide a back-off time value (e.g., tracked via a back-off timer). This rejection cause may be applicable to the (e.g., current) maintaining CAG cell (e.g., CAG-1). The AMF may select the back-off time value so that delayed registration requests (e.g., from different WTRUs) are not synchronized, e.g., to avoid a certain amount (e.g., a large number) of WTRUs initiating delayed registration requests at the same time or approximately the same time (e.g., simultaneously).

[0133] As shown in FIG. 5 at 4, CAG-1 may not be suitable for accessing localized services. The WTRU may start tracking a back-off time for each CAG-1 (e.g., via a back-off timer). While the back-off time is being tracked, the WTRU may refrain from initiating a request (e.g., NAS) to the CAG-1 cell (e.g., an NAS request may not be initiated by the WTRU). The WTRU may trigger cell selection to access localized services LS ID-1. CAG-2 may be a possible candidate cell, and the WTRU may stay connected to CAG-2 and trigger initial registration.

[0134] As shown at 5 in FIG. 5, a registration request for local service LS ID-1 may be sent to the hosting network via CAG-2.

[0135] The registration may be accepted by the hosting network, as shown at 6 in Figure 5. The WTRU may be successfully registered for localized services.

[0136] 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 for the WTRU to overcome overload and congestion and may provide the WTRU with a backoff time value per CAG cell.

[0137] FIG. 6 illustrates an example of overload and congestion handling (eg, RRC connection setup / resumption / release) for the hosting network.

[0138] As shown at 0 in Figure 6, CAG-1 may be overloaded and congested. Other CAG cells (e.g., CAG-2) may be nearby and may provide access to local services identified via LS ID-1.

[0139] As shown in 1a / 1b of Figure 6, the WTRU may set up (e.g., attempt to set up) an initial RRC connection with NG-RAN / CAG-1, or the RRC connection may be interrupted and the WTRU may resume (e.g., attempt to resume) the RRC connection. Because CAG-1 may be overloaded, the NG-RAN may reject the RRC connection setup or resumption with an RRC rejection and provide a rejected CAG list (CAG-1), RRC redirection information with nearby available CAG cells, and a local service support identifier and backoff time value for CAG-1.

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

[0141] As shown in FIG. 6, CAG-1 may not be suitable for accessing localized services. The WTRU may start tracking a back-off time for each CAG-1 (e.g., via a back-off timer). While the back-off time is being tracked, the WTRU may refrain from initiating a NAS request to the CAG-1 cell (e.g., no NAS request would be initiated by the WTRU). The WTRU may trigger cell selection for accessing localized services LS ID-1. CAG-2 may be a possible candidate cell according to the provided RRC redirection information, and the WTRU may stay connected to CAG-2 and trigger initial registration.

[0142] As shown at 4 in FIG. 6, a registration request for local service LS ID-1 may be sent to the hosting network, for example, via CAG-2.

[0143] The registration may be accepted by the hosting network, as shown at 5 in Figure 6. The WTRU may be successfully registered for localized services.

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

[0145] While the implementations described herein may consider 3GPP-specific protocols, it will 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 will be understood that the solutions described herein are not limited to this scenario and may be applicable to other wireless systems.

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

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: a processor, the processor comprising: determining a local service identifier associated with a first closed access group (CAG) and a second CAG; sending a first registration request to the first CAG based on the local service identifier; receiving a first message including an indication that the first registration request to the first CAG is denied, a cause code, and a back-off value; and and sending a second registration request to the second CAG based on the indication that the first registration request to the first CAG is rejected, the cause code, and the back-off value.

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

3. The processor: The WTRU of claim 1 or 2, further configured to determine that the back-off value has elapsed based on a time at which the first message is received.

4. The WTRU of claim 1, wherein the first message further includes a redirection indicator indicating that the second CAG is available.

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

6. The processor: The WTRU of any one of claims 1 to 5, further configured to receive a second message indicating that the WTRU is registered with the second CAG.

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

8. The WTRU of claim 7 , wherein the access identification indicates that the WTRU has permission to access a localized service.

9. The WTRU of any preceding claim, wherein the first message further includes a localized service identifier.

10. 1. 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; sending a first registration request to the first CAG based on the first local service identifier; receiving a message from an access and mobility function that includes an indication that the first registration request to the first CAG is denied, a cause code, and a back-off value; sending a second registration request to the second CAG based on the indication that the first registration request to the first CAG is rejected, the cause code, and the back-off value.

11. The method of claim 10 , wherein the cause code indicates congestion.

12. The method of claim 10 or 11, further comprising determining that the backoff value has elapsed based on the time the message was received.

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

14. The method of any one of claims 10 to 13, further comprising sending a third registration request to the first CAG if it is determined that the back-off value has elapsed.

15. The message is a first message, and the method comprises: The method of any one of claims 10 to 14, further comprising receiving a second message indicating that the WTRU is registered with the second CAG.

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

17. The method of claim 16 , wherein the access identity indicates that the WTRU has permission to access a localized service.

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

Images