Method and apparatus for secure access control in wireless communication

Abstract

To disclose a method and apparatus for secure access control in wireless communications.SOLUTION: A method includes: receiving a broadcast message including system information; and identifying a first set of hash IDs and a first random number based on the system information. Each ID of the first set of hash IDs is individually hashed using at least the first random number. The method also includes: calculating a first hash value for each ID of a second set of IDs using at least the first random number; determining whether at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs; and sending a request message based on a determination that at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs.SELECTED DRAWING: Figure 4

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Patent Application No. 62 / 826,926, filed in the U.S. Patent and Trademark Office on March 29, 2019, U.S. Provisional Patent Application No. 62 / 839,553, filed in the U.S. Patent and Trademark Office on April 26, 2019, and U.S. Provisional Patent Application No. 62 / 861,773, filed in the U.S. Patent and Trademark Office on June 14, 2019, the entire contents of each of which are incorporated by reference herein as if fully set forth below in their entirety and for all applicable purposes. [Prior art documents] [Non-patent literature]

[0002] [Non-Patent Document 1] 3GPP S2-1902898, “Introducing support for Non-Public Networks” [Non-Patent Document 2] 3GPP TS 23.122, “NAS functions related to MS in idle mode”, V16.0.0 [Non-Patent Document 3] 3GPP TR 33.819, “Study on security for 5GS enhanced support of Vertical and LAN Services” [Non-Patent Document 4] 3GPP S3-190994, “Key issue on CAG access control in Non-standalone NPNs” [Non-Patent Document 5] 3GPP TR 33.846, “Study on authentication enhancements in the 5G System” [Non-Patent Document 6] 3GPP S3-190995, “New solution of CAG access control in Non-standalone NPNs”

Non-licensed Document 7

Non-licensed literature 9

Non-licensed literature 10

Non-licensed Document 11

Non-licensed Document 12

Non-licensed Document 13

Non-licensed Document 14

[0003] The embodiments disclosed herein relate generally to methods and apparatus for secure access control in wireless communications, such as for secure access control for Next Generation Radio Access Networks (NG-RANs) that are part of 5G New Radio (NR) systems. [Brief description of the drawings]

[0004] A more detailed understanding may be had from the following detailed description, given by way of example in conjunction with the drawings attached hereto. The figures in such drawings, like the detailed description, are examples. Thus, the figures and the detailed description should not be considered as limiting, as other equally effective examples are possible and may occur. Moreover, like reference numbers in the figures indicate like elements.

[0005] [Figure 1A] FIG. 1 is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1A is a system diagram of an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to an embodiment. [Figure 1C] FIG. 1B is a system diagram of 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 an embodiment. [Figure 1D] 1B is a system diagram of a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to an embodiment. [Diagram 2] FIG. 1 is a signal flow diagram of an example registration procedure with Closed Access Group (CAG) access control, according to one or more embodiments. [Diagram 3] 1 is a diagram of an example of a WTRU moving between CAG cells having different CAG identifiers (IDs) in accordance with one or more embodiments. [Figure 4] 1 is a signal flow diagram of an example registration procedure with radio resource control (RRC) based CAG access control, according to one or more embodiments. [Diagram 5] FIG. 1 is a signal flow diagram of an example registration procedure with non-access stratum (NAS) based CAG access control, according to one or more embodiments. [Figure 6] A signal flow diagram of an example procedure for using a hashed temporary S-NSSAI (TS-NSSAI) during Access Stratum (AS) connection establishment according to one or more embodiments. [Figure 7] A signal flow diagram illustrating an example of a first CAG ID protection mechanism according to one or more embodiments. [Figure 8] A signal flow diagram illustrating an example of a second CAG ID protection mechanism according to one or more embodiments. [Figure 9] 1 is a signal flow diagram of an example handover procedure between CAG cells, according to one or more embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details described herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of or in combination with these embodiments, as well as other examples described, disclosed, or otherwise explicitly, implicitly, and / or inherently provided herein (collectively "provided"). Although various embodiments are described and / or claimed herein in which apparatus, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any portions thereof, it should be understood that any embodiment described and / or claimed herein may be configured to perform any apparatus, system, device, etc., and / or any elements thereof perform any operations, processes, algorithms, functions, etc., and / or any portions thereof.

[0007] Representative communication networks The methods, apparatus, and systems provided herein are well suited for communications involving both wired and wireless networks. Wired networks are well known. With reference to Figures 1A-1D, an overview of various types of wireless devices and infrastructures is provided, in which various elements of the networks may utilize, execute, be arranged and / or adapted and / or configured in accordance with the methods, apparatus, and systems provided herein.

[0008] 1A illustrates 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, broadcasts, 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 schemes, 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-Tailed Unique Word DFT Spread OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multi-Carrier (FBMC), etc.

[0009] 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 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 the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d, all of which may be referred to as “stations” and / or “STAs,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, notebooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, IoT devices, watches or other wearables, 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 the context of industrial and / or automated processing chains), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. The WTRUs 102a, 102b, 102c, and 102d may all be referred to interchangeably as WTRUs.

[0010] 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 configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, a New Radio (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 understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0011] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services in a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a 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, e.g., 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 for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

[0013] 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, SC-FDMA, etc. For example, the base stations 114a and WTRUs 102a, 102b, 102c 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 116 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

[0014] 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-A) and / or LTE Advanced Pro (LTE-A Pro).

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

[0016] 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 LTE and NR radio access together, for example, using a 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 sent to and from multiple types of base stations (e.g., eNBs and gNBs).

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

[0018] The base station 114b in FIG. 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 workplace, a home, a vehicle, a premises, 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 utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 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 via the CN 106 / 115.

[0019] 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, application, and / or VoIP services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error resilience requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location 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 be in direct or indirect communication with other RANs employing 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.

[0020] 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 providing 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 TCP, UDP, and / or IP in the TCP / IP Internet protocol suite. The networks 112 may include wired 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 that may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0021] 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 with a base station 114b, which may employ an IEEE 802 wireless technology.

[0022] Figure 1B is a system diagram illustrating an example WTRU 102. As shown in Figure 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 GPS chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may comprise any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0023] 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, other types of integrated circuits (ICs), 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. Although 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.

[0024] The transmit / receive element 122 may be configured to transmit and receive signals to and 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, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0025] 1B depicts the transmit / receive element 122 as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More particularly, 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.

[0026] 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 mentioned 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.

[0027] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or 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 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 RAM, ROM, a hard disk, or any other type of memory storage device. The removable memory 132 may include a SIM card, a memory stick, a secure digital (SD) memory card, or the like. In other embodiments, the processor 118 may access information and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

[0029] 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 a 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 over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by way of any suitable location determination method while remaining consistent with an embodiment.

[0030] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for 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 modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and / or the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0032] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned 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 be in communication with the CN 106.

[0033] The RAN 104 may include eNodeBs 160a, 160b, 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, 160c may each comprise one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0034] 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 each other via an X2 interface.

[0035] 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 above elements is shown 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.

[0036] The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act 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 attachment 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.

[0037] 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 handover between eNodeBs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

[0039] 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 communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. 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.

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

[0041] In an exemplary embodiment, the other network 112 may be a WLAN.

[0042] A WLAN in infrastructure basic service set (BSS) mode has an access point (AP) for the 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 from the BSS. Originating traffic to the STA may arrive through the AP and be sent to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP and delivered to the respective destination. Traffic between STAs in the BSS may be sent through the AP, e.g., a source STA may send traffic to the AP, which in turn may deliver the traffic to the destination STA. Traffic between STAs in the BSS may be considered or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between the source and destination STAs 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 STAs) may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad-hoc" communication mode.

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

[0044] High throughput (HT) STAs may use 40 MHz wide channels for communication, for example, via combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0045] A Very High Throughput (VHT) STA can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. The 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, the latter sometimes referred to as an 80+80 configuration. For the 80+80 configuration, the data can be passed through a segment parser after channel encoding, which can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing can be performed on each stream separately. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control layer.

[0046] Sub-1 GHz operation modes are supported by 802.11af and 802.11ah. In 802.11af and 802.11ah, the channel operating bandwidth and carriers are reduced relative 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, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including specific functions, for example, support (e.g., support only) of specific and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., maintain a very long battery life).

[0047] A WLAN system may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, including a channel that may be designated as a primary channel. 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 the STA from among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) 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) setting may depend on the status of the primary channel. For example, if the primary channel is busy because a STA (that only supports a 1 MHz mode of operation) is transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band may remain idle and available for use.

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

[0049] 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 be in communication with the CN 115.

[0050] The RAN 113 may include gNBs 180a, 180b, 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, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit and / or receive signals to and from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit and / or receive wireless signals to and from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, and the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multipoint (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

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

[0052] 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 any other RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more 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 bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an 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 at approximately the same time. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as a mobility anchor 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.

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

[0054] 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. Although each of the above elements is shown 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.

[0055] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and 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 being utilized by the WTRUs 102a, 102b, 102c. Different network slices may be established for different use cases, for example, services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communications (MTC) access, etc. The AMF 182 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that use other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0057] The UPFs 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which provides the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, and facilitates 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 policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing a mobility anchor, etc.

[0058] 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 an 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.

[0059] 1A-1D and the corresponding description 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-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, 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 to simulate network and / or WTRU functions.

[0060] The emulation device 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 be fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to implement one or more or all of the functions to test other devices in the communication network. One or more emulation devices may be temporarily implemented / deployed as part of a wired and / or wireless communication network to implement one or more or all of the functions. The emulation device may be directly coupled to another device for testing purposes and / or may use wireless communication to perform the tests.

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

[0062] One or more embodiments disclosed herein relate to methods and apparatus for a public land mobile network (PLMN) integrated non-public network (NPN). In various embodiments, an NPN (e.g., a PLMN integrated NPN) may use one or more closed access groups (CAGs) for identification, cell selection, and / or access control. In various embodiments, it is contemplated that other types of NPNs may equally use one or more procedures, mechanisms, or embodiments discussed herein. For example, a standalone NPN (SNPN) may use a set / list of NPN IDs for identification, cell selection, and / or access control, and may use one or more procedures, mechanisms, or embodiments disclosed herein.

[0063] In various embodiments, the term "random number" disclosed herein may refer to a pseudorandom number, a quasi-random number, or any other type of random number.

[0064] Typical Procedures for PLMN Integrated NPN Access In some implementations (e.g., in 3GPP), an NPN is supported or deployed. An NPN may be deployed or implemented with support of one or more PLMNs using a closed access group (CAG) and / or network slicing, and in some examples, this type of NPN may represent a PLMN aggregated NPN. In some cases, a PLMN aggregated NPN may be part of a non-standalone (NSA) communication network or may be implemented as one or more NSA communication networks. In some cases, an NPN may be implemented as a standalone NPN (SNPN). For example, an SNPN may be a private network that does not rely on network functions of a public PLMN.

[0065] In various embodiments, the CAG may be used to enable the network to prevent a WTRU from attempting to access a network slice, for example, the network slice may be dedicated to an NPN, and the NPN may be in an area where WTRUs are not allowed to use the network slice.

[0066] With reference to FIG. 2, an example of a procedure 200 for network and cell selection and access control is provided. In this example, before attempting to access a CAG cell, the WTRU may compare an allowed CAG list from the WTRU's local configuration with a set of CAG IDs broadcasted as plaintext by the CAG cell (e.g., operations 0-2 shown in FIG. 2). If the WTRU finds at least one matching CAG ID, the WTRU may proceed with the registration procedure using a subscription concealed identifier (SUCI) of or associated with the WTRU. For example, the WTRU may send a registration request (e.g., with SUCI) message to the NG-RAN and / or the Access and Mobility Management Function (AMF). In various embodiments, the WTRU may select a matching CAG ID and include the selected CAG ID in the RRC layer signaling (e.g., in a UL RRC message). The WTRU may go through a full primary authentication so that the AMF can obtain CAG-related subscription information from a unified data management (UDM). The AMF may determine or verify whether at least one CAG ID from the WTRU subscription corresponds to or matches a CAG ID of the cell support and / or a CAG ID selected by the WTRU. For example, the AMF may determine or verify whether at least one CAG ID from the WTRU subscription corresponds to or matches any of the CAG IDs (e.g., selected CAG IDs) forwarded by the NG-RAN in the N2 message (e.g., operations 4 and 7 shown in FIG. 2). On the condition that the AMF finds a matching CAG ID, the WTRU may be allowed to access the CAG cell, e.g., registration may be accepted. For example, registration may be accepted via a registration accept message sent from the AMF to the WTRU.Provided that the AMF does not find a matching CAG ID, the WTRU may not be allowed to access the CAG, e.g., registration may be rejected, e.g., registration may be rejected via a registration reject message sent from the AMF to the WTRU.

[0067] In various embodiments, SNPN identification, cell selection, and / or access control may follow similar operations (e.g., procedures illustrated in FIG. 2) as for the PLMN integrated NPN described above. The SNPN may be identified by a unique NPN ID. A cell providing access to an SNPN may broadcast a set or list of NPN IDs for these SNPNs as plain text. When the WTRU finds a subscriber identifier and / or credentials that correspond to the set or list of broadcasted NPN IDs, the WTRU may select and attempt to register with one or more SNPNs. For example, the WTRU may have a list / set of subscriber identifiers in the form of a network access identifier (NAI), where the realm portion may include the NPN ID. For a PLMN integrated NPN, the WTRU may need to go through a full primary authentication before the network can determine if the WTRU is authorized to access.

[0068] In various embodiments, the CAG cell access may be reserved exclusively for one or more WTRUs that support CAG. For example, the cells discussed herein may be normal PLMN cells or CAG cells. In some cases, emergency services may be supported in the CAG cell.

[0069] In various embodiments, a PLMN integrated NPN may represent an NSA communications network, an NSA NPN, or a public network integrated NPN, and these terms referring to a PLMN integrated NPN may be interchangeable.

[0070] Representative Security and / or Privacy Procedures for PLMN Integrated NPN Access In various embodiments, security aspects for vertical services and / or PLMN integrated NPN access are discussed. For example, some aspects relate to potential (distributed) denial of service ((D)DoS) attacks in the PLMN integrated NPN that may be imposed on a 5G system when a large number of malicious WTRUs attempt to register on the network (e.g., CAG cell), and one or more of the number of WTRUs may not be authorized to access the network (e.g., CAG cell). Potential security requirements may be implemented to mitigate such (D)DoS attacks on the PLMN integrated NPN (resulting from registration requests from WTRUs that are not authorized to access the CAG cell).

[0071] In various embodiments, the WTRU may include the CAG ID as plaintext in an initial NAS registration request message. The AMF may send an authentication request including the CAG ID provided by the WTRU to the Home PLMN (HPLMN). Upon receiving the request, the UDM may determine or verify if the provided CAG ID matches the CAG ID from the WTRU subscription data. For example, the UDM may determine (or verify) if the provided CAG ID matches the CAG ID from the WTRU subscription data after deciphering the SUCI to a valid Subscription Persistent Identifier (SUPI). For example, if no match is found, the UDM may reject the authentication request and the AMF may reject the WTRU registration.

[0072] A typical procedure using a cryptographic hash function and salt In various embodiments, for example, cryptographic hash functions (e.g., SHA-3, PBKDF2, BCRYPT) are referred to as one-way functions (infeasible to reverse). A cryptographic salt may be referred to as random non-secret data used as an additional parameter by a hash function to defend against (e.g., pre-computed) dictionary attacks, for example, by randomizing (e.g., effectively randomizing) the output of the hash function. In various embodiments, cryptographic hash functions and / or cryptographic salts may be used to protect passwords, for example, in storage or in transmission, as randomized hash strings.

[0073] For example, a user who reuses the same password across different services may have different hashed passwords (e.g., in storage) at those services, assuming those services use different random salts. In another example, two users who use the same or common password in the context of the same service may have different hashed passwords (e.g., in storage), assuming the services use different random salts for each user.

[0074] A typical procedure using Diffie-Hellman key agreement In various embodiments, a shared secret derived using either Diffie-Hellman (DH), Elliptic Curve Diffie-Hellman (ECDH), and similar types of protocols may be used directly as a session key or as a master key to derive a session key, which may be used to encrypt or integrity protect subsequent communications using symmetric key cryptography.

[0075] The DH protocol provides a key exchange that can be used to allow two parties (e.g., a WTRU and a gNB) that do not have prior knowledge of each other to jointly establish a shared secret key over an unsecure channel. The ECDH protocol, a variation of the DH protocol, uses elliptic curve cryptography. ECDH is an anonymous key agreement protocol that allows two parties, each with an elliptic curve public-private parameter pair, to establish a shared secret over an unsecure channel.

[0076] Representative Procedures Using Elliptic Curve Integrated Encryption Scheme (ECIES) In various embodiments, ECIES can refer to an integrated encryption scheme that uses multiple cryptographic functions, namely, key agreement functions, key derivation functions, symmetric encryption mechanisms / functions, and / or message authentication code (MAC) functions. ECIES combines a key encapsulation mechanism with a data encapsulation mechanism. A system using ECIES can independently derive encryption and MAC keys from a common secret. ECIES is standardized, for example, in ANSI X9.63, IEEE 1363a, ISO / IEC 18033-2, and SECG SEC-1.

[0077] ECIES is specified for the 5G security architecture as a standard mechanism for SUPI privacy protection. Using ECIES, for example, the WTRU may be able to protect the confidentiality / integrity of the SUPI by using derived symmetric encryption and / or MAC keys obtained by performing a key derivation function followed by a key agreement function that uses the home network's pre-provisioned public key and a generated ephemeral public / private key pair.

[0078] PLMN Integrated NPN Access - Representative Procedures for CAG Access Control for (Distributed) Denial of Service ((D)DoS) In various embodiments, a WTRU (e.g., an NPN WTRU) and network supporting CAG access control for PLMN integrated NPN access may mitigate or reduce the risk of (distributed) denial of service ((D)DoS) attacks on the CAG cell, the network, the UDM, and / or the Subscription Identifier Deciphering Function (SIDF).

[0079] With reference to FIG. 2, when the WTRU first accesses a CAG cell, the network (e.g., AMF) may (or must) verify the cell-supported CAG ID provided by the gNB (and / or selected by the WTRU) against the CAG ID list from the WTRU subscription information before allowing access. The WTRU may (or must) perform a full primary authentication with the network. Such a procedure may first decipher the SUCI using or requesting the UDM / SIDF so that the AMF can obtain the SUPI and retrieve the CAG-related subscription information. This privacy enhancement (e.g., privacy enhancement) may increase the processing load in the home network since it requires the UDM / SIDF to perform a public key operation (e.g., SUPI deciphering in the SIDF). The AUSF may represent an authentication server function, and the VPLMN may represent a visited PLMN.

[0080] For example, an attacker may attempt to flood the network with registration requests through one or more CAG cells, forcing the UDM / SIDF to process many fake or forged SUCIs, while simultaneously consuming radio resources in the CAG cells, causing a (D)DoS attack on the network (e.g., UDM / SIDF). In another example, a set of legitimate or genuine WTRUs may create a storm of registration requests while not authorized to join a CAG cell (e.g., a particular CAG-enabled cell). A similar (D)DoS attack risk may be encountered in the case of an SNPN, where a large number of WTRUs that are not authorized to access the SNPN cell may attempt to register on the SNPN cell.

[0081] In various embodiments, with regard to (D)DoS mitigation or reduction, during the identification phase, the WTRU and / or network may reduce the window of opportunity for a (D)DoS attack by verifying the validity of the CAG ID before primary authentication occurs (e.g., while identifying or verifying the WTRU identity with the UDM). Because the UDM may be asked to or can decipher the SUCI, potential (D)DoS attack threats on the UDM may be addressed. Because the UDM may or must perform CAG ID verification as part of the identification procedure, the processing load of the UDM may be increased, for example, when compared to the procedure in FIG. 2.

[0082] In some implementations, the CAG ID of the cell support expected from the gNB may not be included in the authentication message (e.g., the authentication message sent by the AMF to the UDM). For example, the UDM may check (e.g., only check) if the WTRU-provided CAG ID is part of the WTRU subscription and may not check if the WTRU is authorized to access the CAG cell. In some cases, a WTRU (that supports CAG) may be authorized to access any CAG cell, bypassing the access control foreseen by the procedure in FIG. 2.

[0083] CAG Access Control for PLMN Integrated NPN Access - Representative Procedures for NPN and / or WTRU Privacy In various embodiments, a WTRU (e.g., an NPN WTRU or UE) and a network supporting CAG access control for PLMN integrated NPN access may ensure privacy of an NPN served by a CAG cell and / or privacy of an NPN WTRU that is authorized to access the CAG cell.

[0084] In various embodiments, the network slice selection assistance information (NSSAI), or a set of single NSSAIs (S-NSSAIs), may be considered private information (e.g., in 5G NR). For example, enhancements may be implemented to enable protection of the NSSAI at the Access Stratum (AS) (e.g., RRC) layer and / or NAS layer during the initial registration procedure. For example, a CAG ID assigned to a network slice dedicated to a particular NPN may not only reveal information associated with a particular S-NSSAI, but may also reveal information to a particular enterprise to which a CAG cell and / or network slice is or has been allocated. For example, a CAG ID may be considered private information.

[0085] In various embodiments (e.g., the procedure in FIG. 2), privacy of the NPN and / or WTRU is implemented. For example, a CAG cell may broadcast a set and / or list of supported CAG IDs (e.g., supporting a total of 12 CAG IDs). In some circumstances, broadcasting a set or list of supported CAG IDs may be a privacy risk. For example, an attacker may identify and / or map a particular cell serving a particular NPN based on the CAG ID broadcast in the clear. An attacker may use this information to target and / or disrupt the operation of the NPN (e.g., using a (D)DoS attack as described above). Similar privacy risks may be encountered in the case of SNPNs where a set / list of one or more NPN IDs are broadcast in the clear by cells providing access to these SNPNs.

[0086] For example, an attacker may be able to track users of NPNs and / or NPN slices by eavesdropping on communication exchanges on certain cells. For example, by detecting that a particular WTRU is authorized to access a CAG cell (e.g., by eavesdropping on a registration accept message), an attacker may be able to link the user to one of the NPNs or NPN slices served by the CAG cell and link the privacy-protected pseudo identities (e.g., SUCIs) of multiple WTRUs. In some cases, an attacker may track users even more specifically, since the WTRU may send a (e.g., selected) CAG ID in the clear in the initial registration message, revealing the exact information about the particular NPN slice the WTRU wants to access, providing the attacker with information for identity linking and / or traffic analysis attacks.

[0087] In another example, an attacker can obtain one or more cell-supported CAG IDs in plaintext from broadcasted system information, and the attacker can request and gain access to the cell by including one of the cell-supported CAG IDs in one or more RRC messages. In this case, a conventional access control procedure implemented by the network (e.g., gNB) using the CAG ID transmitted by the WTRU may be vulnerable to the attack. The conventional access control procedure exhibits, e.g., vulnerabilities that can be exploited by an attacker to perform an attack, e.g., a (D)DoS attack as described above.

[0088] Representative Procedure for WTRU Configuration When Moving to a New CAG Cell In some examples, the WTRU configuration (e.g., allowed NSSAI) may not be correct when moving to a new CAG cell. For example, when a WTRU accessing a PLMN aggregated NPN is served by a specific PLMN network slice, the WTRU may be in a CAG cell from which the WTRU is allowed to access that network slice. In this example, the WTRU's allowed NSSAI configuration may accommodate that network slice when the WTRU moves to the corresponding CAG cell.

[0089] For example, the WTRU's allowed CAG list may accommodate multiple CAG IDs, and the WTRU may move between two CAG cells with different CAG IDs, and both CAG cells may allow the WTRU to camp and / or access the corresponding NPN. With reference to FIG. 3, for example, as shown in wireless communication network 300, a WTRU (e.g., WTRU 102) may have a configured allowed CAG list that may accommodate or include any number of CAG IDs (e.g., "CAG-1", "CAG-2"). The WTRU may move from a "CAG-1" CAG cell to a "CAG-2" CAG cell. When the WTRU was in the CAG-1 cell, the WTRU may have received an allowed NSSAI configuration with an S-NSSAI (e.g., S-NSSAI-1) that may correspond to CAG-1, and may not have any S-NSSAI associated with CAG-2. When a WTRU moves to a CAG-2 cell in CM-IDLE state, the WTRU's allowed NSSAI configuration may not be updated before the WTRU accesses the network. There may be a mismatch between the WTRU's allowed NSSAI and the WTRU's CAG location.

[0090] For example, if a user attempts to initiate a service (e.g., send a request) toward an NPN associated with CAG-2, e.g., to trigger establishment and / or reactivation of a PDU session toward S-NSSAI-2 serving the NPN, the WTRU may block the request because the associated S-NSSAI may not be in the WTRU's current allowed NSSAI configuration. In some cases, the WTRU may allow establishment or reactivation of a PDU session toward S-NSSAI-1, which may be associated with CAG-1, to be initiated in CAG-2, and the request may be rejected by the network because the WTRU's current location (e.g., CAG-2) does not allow the WTRU to access S-NSSAI-1.

[0091] Exemplary Procedure for Synchronizing WTRU CAG ID Configuration Following CAG ID Subscription Update In some examples, when a WTRU is configured with a single authorized CAG ID, a CAG ID misconfiguration issue may occur when the UE cannot (or can no longer) access the network. For example, the WTRU may be configured with a single authorized CAG ID (CAG ID_A), and the WTRU may be configured and / or receive an indication that the WTRU can only access the network through a CAG cell. In some cases, when the WTRU is registering with the network, the AMF may receive updated subscription data in which CAG ID_A is not present (e.g., CAG ID_A may have been replaced with CAG ID_B). In this case, the AMF may send a registration reject message with an appropriate cause, and the WTRU may remove CAG ID_A from its authorized CAG ID list. As a result, the WTRU does not have an authorized CAG ID in its authorized CAG ID list, the WTRU can only access the network through a CAG cell, and thus the WTRU cannot access the network.

[0092] Representative Procedures Using RRC Signaling to Mitigate (D)DoS Attacks on CAG Cells and Networks 4, an exemplary procedure 400 may be used to mitigate or reduce a (D)DoS attack on a CAG cell and / or one or more networks (e.g., UDM / SIDF for PLMN integrated NPN) using AS or RRC signaling. In various embodiments, a WTRU (e.g., WTRU 102) may compare a hash value of its locally configured CAG ID with a hash value of a CAG ID broadcasted by a CAG cell to find one or more matching CAG IDs. The WTRU may register with the network and / or cell while providing a new hash value of the one or more matching CAG IDs at the RRC layer. A WTRU may be allowed access to a CAG cell (and / or NPN slice) if i) at least one WTRU-provided hashed CAG ID matches and / or is matched by one or more hashed CAG IDs supported by the CAG cell, or ii) by policy (e.g., emergency access using default DN / slice). In certain embodiments, a WTRU may be denied access to a CAG cell (and / or NPN slice). For example, the procedure may include any of the following:

[0093] In various embodiments, for example, in operation 0, the WTRU may be configured with an allowed CAG list from the HPLMN. The gNB may be configured with supported CAG IDs. Such provisioning may be accomplished out-of-band and / or at any time prior to operation 1. Operation 1. The WTRU may retrieve one or many CAG identifiers (IDs) from the CAG cell broadcast system information (e.g., SIB1) that are individually hashed using a random number (e.g., pseudo-random number, RAND_CELL) as a base for a salt (e.g., SALT_CELL). The salt may, for example, combine RAND_CELL with the current cell ID (e.g., SALT_CELL=RAND_CELL XOR cell ID or RAND_CELL|| cell ID) to bind the resulting hash value to a unique cell ID. The cell ID may be included in the broadcast system information. RAND_CELL may also be included in the broadcast information. Each CAG cell may use a different RAND_CELL / salt so that two CAG cells supporting a common CAG ID (e.g., serving the same NPN slice) may broadcast entirely different hashed CAG IDs. By randomizing the broadcasted CAG ID, any two CAG cells cannot be linked to each other by an eavesdropper based on the hashed CAG ID information alone. Each time the configured supported CAG IDs for a given CAG cell are updated, a new RAND_CELL may be generated and used to produce a new hash value for the new supported CAG ID to be broadcast. To avoid repetition herein, it should be understood that the term "pseudo-random number" may be used interchangeably and / or in addition to the term "quasi-random number." Action 2. The WTRU may compute a hash using the SALT_CELL for each of the CAG IDs in its locally configured allowed CAG list (eg, see action 0). Action 3. Prior to sending the initial registration request, the WTRU may compare the locally generated hashed CAG ID with the hashed CAG ID broadcast by the CAG cell and may determine whether there is at least one matching hashed CAG ID. Action 4. For each CAG ID from the configured allowed CAG that matches the hashed CAG ID of the cell broadcast, the WTRU can calculate a new hash using the newly generated random value (RAND_UE) as a base for the salt (SALT_UE). For example, the WTRU can include a Cell Radio Network Temporary Identifier (C-RNTI) assigned by the gNB as part of the salt in the RRC setup message to bind the hashed CAG ID to the transmission resources allocated by the gNB for the particular RRC connection and WTRU. The RAND_UE can add novelty to protect against replay attacks. The RAND_UE may be supplemented by including a timestamp parameter for CAG ID replay protection. Including the C-RNTI as a component of the WTRU salt can enable the gNB to detect malicious WTRUs attempting to replay the broadcasted CAG cell CAG ID and cell salt (e.g., based on differences in the format of the cell and WTRU salt). For example, RAND_UE may be bound to RAND_CELL (e.g., concatenation, XOR) and / or a cell ID for constructing a salt (SALT_UE), such as a hashed CAG ID transmitted by the WTRU, may be bound to that particular cell broadcasting the CAG ID. This may allow the gNB to detect when a malicious WTRU attempts to replay another WTRU hashed CAG ID transmitted on a different cell. Action 5. The WTRU may send a registration request at the Access Stratum (AS) layer (eg, in an RRCSetupComplete message) including the SALT_UE and the individually hashed CAG ID that matches the CAG ID in the cell broadcast. Action 6. The gNB may compute a hash using the SALT_UE for each CAG ID in its configured CAG ID list. Action 7. The gNB may verify whether there is at least one match between the WTRU-provided hashed CAG ID and the hashed CAG ID calculated (e.g., in action 6). Operation 8. The gNB may decide (e.g., based on operator policy and / or in response to local regulations) to do the following: Action 8a. If no matching hashed CAG ID is found, immediately drop the RRC connection, or Action 8b. If such a matching hashed CAG ID is found, send a message to the AMF, e.g., over the N2 interface, including: a) the CAG ID of the cell support, b) an indication of whether the WTRU has at least one CAG ID that matches the CAG ID of the cell, and c) a NAS registration request message from the WTRU. The gNB may determine that a WTRU without a matching CAG ID (e.g., the WTRU does not provide any CAG ID) may be in a limited service state and / or may be attempting to register for emergency services only. For example, the gNB may perform an "emergency registration" by setting an RRC establishment cause for emergency. Depending on local regulations and / or operator policies, the gNB may decide to send an N2 message to the AMF for further access control confirmation. Action 9. Using the indication from the gNB and the operator's policy, the AMF determines whether to allow the WTRU to access the CAG cell. Action 10a. If the indication from the gNB states that no matching CAG ID is found and / or non-NPN access is not allowed based on operator policy / local regulations (e.g., registration for emergency services is not allowed on the CAG cell), the AMF may send a registration reject message to the WTRU (followed by the release of any AS or NAS connections), or Action 10b. If the indication from the gNB states that at least one matching CAG ID was found, the network and the WTRU may proceed with the remaining registration procedures (e.g., as shown in FIG. 2, actions 5-8); or Action 10c. If the indication from the gNB indicates that a matching CAG ID is not or could not be found and / or non-NPN access is permitted based on operator policy / local regulations (e.g., permitting the WTRU to make an emergency call), the network and WTRU may proceed with an emergency registration procedure or an exception handling procedure per operator policy / local regulations.

[0094] In various embodiments, an exemplary procedure (e.g., including one or more alternative call / signal flow operations compared to FIG. 4) may be used to mitigate or reduce (D)DoS attacks on a CAG cell and / or network (e.g., UDM / SIDF for PLMN integrated NPN) using AS or RRC signaling. The exemplary procedure may include any of the following: Action 0-1: The gNB may broadcast a random number (e.g., a pseudo-random number, RAND_CELL), and the cell-supported CAG ID may be hashed using a RAND_CELL-based salt. The gNB may broadcast another random number (e.g., RAND_UE) to be used by the WTRU to hash its matching authorized CAG ID when attempting to access the network. RAND_UE may be assigned a limited duration that is short enough to reduce the likelihood of a WTRU-hashed CAG ID replay attack, and long enough to allow a legitimate RRC connection to complete (e.g., as a multiple of the RRC connection timers T300 and / or T352). Action 2-4: As described above in FIG. 4, the WTRU may select a CAG cell based on a match of hashed CAG IDs (e.g., using a RAND_CELL-based salt). For example, the WTRU may calculate a hash value of the CAG ID using a RAND_CELL-based salt. The WTRU may check whether there is one or more matching hashed CAG IDs. Action 5: The WTRU may register with the network. For example, the WTRU may calculate a hash value of its matching CAG ID from its allowed CAG ID list using the RAND_UE-based salt. The WTRU may construct the salt by combining the RAND_UE with the C-RNTI (e.g., salt=RAND_UE XOR C-RNTI). The WTRU may send the CAG ID hashed using the RAND_UE-based salt in a message (e.g., an RRCSetupComplete message). The WTRU may include the RAND_UE in the message. As described above in FIG. 4, the WTRU may construct a salt by combining the RAND_CELL and / or cell ID with the RAND_UE / C-RNTI to enable binding of the generated hashed CAG ID with the WTRU and the cell. Action 6-8a: The gNB may enable the WTRU to be allowed to access a CAG cell based on a match of a hashed CAG ID (e.g., using a RAND_UE-based salt). For example, the gNB may check if the received RAND_UE is valid if included in the RRC message. If the RAND_UE is not valid (e.g., expired), the gNB may drop the RRC connection. If the RAND_UE is not included in the RRC message, the current broadcasted RAND_UE may be used. For example, the gNB may calculate a hash value of its configured CAG ID using a RAND_UE-based salt (e.g., combined with the RAND_UE XOR C-RNTI, and / or RAND_CELL / cell ID) and check if there is at least one match with the WTRU-provided hashed CAG ID. Actions 8b-10 (which may include actions 10a, 10b, or 10c): Same as above in FIG.

[0095] Representative procedures using non-access stratum (NAS) signaling, e.g., to mitigate (D)DoS attacks on a CAG cell and / or network. With reference to FIG. 5, an exemplary procedure 500 may be used to mitigate or reduce (D)DoS attacks, for example, on a CAG cell and / or network (e.g., UDM / SIDF for PLMN integrated NPN) using NAS signaling. In various embodiments, compared to a procedure using RRC layer signaling, a WTRU using this exemplary procedure may send and / or receive a hashed CAG ID at the NAS layer, and CAG ID verification may be performed, for example, by a network entity (e.g., AMF). In various embodiments, compared to the procedure in FIG. 2, the gNB may broadcast a hashed CAG ID. This procedure may include any of the following: Action 0. The WTRU may be configured with an allowed CAG list from the HPLMN. The gNB may be configured with a set and / or list of supported CAG IDs. This configuration or provisioning action may be accomplished out-of-band and / or at any time prior to action 1. Operation 1. As described above in Figure 4, the gNB may broadcast hash values ​​of supported CAG IDs and one or more random numbers (e.g., pseudo-random numbers, RAND_CELL, and / or RAND_UE). The WTRU may select a CAG cell based on a match of the hashed CAG IDs (e.g., using a RAND_CELL-based salt). Action 2. The WTRU may register with the network. As described above, the WTRU may calculate a hash value of its matching CAG ID using a RAND_UE-based salt. The WTRU may send the CAG ID hashed using the RAND_UE-based salt in a NAS registration request message. The WTRU may include the salt in the NAS message (e.g., along with a timestamp-based component for replay detection by the AMF). Action 3. The gNB may send a message to the AMF on the N2 interface including: i) the cell-supported CAG ID, ii) the salt used / required to validate, for example, the WTRU-provided hashed CAG ID (e.g., current RAND_UE XOR C-RNTI), and / or iii) a NAS registration request message from the WTRU. Action 4. The AMF may calculate a hash value of the cell-supported CAG ID using a gNB-provided salt (e.g., and / or using a WTRU-provided salt). Action 5. The AMF may check whether there is at least one match between the cell-supported CAG ID and the hashed CAG ID provided by the WTRU. Action 6. If a match is found, the AMF may proceed with normal registration procedures. If no match is found, the registration may be rejected. For example, if the registration request is for emergency registration, the AMF may allow the WTRU to access the network for emergency services based on, for example, one or more operator policies and / or one or more local regulations.

[0096] Representative procedures for protecting the confidentiality of the NPN and / or the privacy of NPN users In various embodiments, a mechanism may be implemented to protect CAG ID privacy, for example, using one or more of the previously described procedures. In various embodiments, the mechanism may be based on the exchange of a randomized CAG ID (e.g., using a hash function with a random salt) between or among the WTRU, the gNB, and / or the AMF. Privacy considerations may depend on local regulations. The network may be able to control whether randomized CAG ID based access is active in a cell. The PLMN and / or NPN operator may provide the WTRU with appropriate guidance (e.g., by provisioning or by other means) on whether to allow selection of a CAG cell without CAG ID randomization being enabled.

[0097] In various embodiments, to inform a CAG-supporting WTRU whether the cell supports randomized CAG ID based access, the CAG cell may broadcast an indication that the broadcasted CAG ID is randomized. In certain embodiments, the presence of a hashing random number (e.g., a pseudo-random number) as described above (e.g., RAND_CELL, RAND_UE) may inform a CAG-supporting WTRU that the cell has enabled randomized CAG ID based access.

[0098] In various embodiments, the CAG cell may broadcast a randomized CAG ID for cell selection and an indication of whether the WTRU can send a (matching) randomized CAG ID for CAG cell access control. If the indication indicates to the WTRU to send a hashed CAG ID during registration, the WTRU may perform a procedure for registering with the network (e.g., the procedure illustrated in FIG. 4 and / or FIG. 5). If the indication indicates to the WTRU not to send a hashed CAG ID during registration, the WTRU may perform a procedure (e.g., the procedure illustrated in FIG. 2) that may include a randomized CAG ID that may be broadcast only for the cell (re)selection process and may not be transmitted (e.g., by the WTRU) for access control operations.

[0099] In various embodiments, a CAG cell may broadcast a mix of randomized (e.g., having a random number associated with it) and non-randomized CAG IDs. For example, a WTRU supporting CAG may select a cell using a cell selection process or procedure (e.g., procedure 400 illustrated in FIG. 4, or procedure 500 in FIG. 5) after matching the hashed CAG IDs and / or the matching plaintext CAG IDs illustrated in FIG. 2. The WTRU may register with the network according to the procedure illustrated in FIG. 2 (e.g., without sending any CAG IDs in the RRC or registration messages). In certain representative embodiments, the WTRU may register according to procedure 400 illustrated in FIG. 4, or procedure 500 in FIG. 5. For example, in the case where the CAG IDs are broadcast as hashed values ​​or in plaintext (e.g., the procedures illustrated in FIG. 4 and / or FIG. 5), the WTRU may send all matching CAG IDs as hashed values.

[0100] In various embodiments, a WTRU (e.g., WTRU 102) supporting randomized CAG ID based access may be configured with a CAG access "privacy mode" by the HPLMN, which may indicate to the WTRU whether it is permitted to select a cell without randomized CAG ID based access being enabled. A default value for this privacy mode may be configured to instruct (or indicate) the WTRU to select only cells with randomized CAG ID based access enabled. The WTRU may be configured by the serving PLMN / HPLMN after successful registration with a different mode (e.g., to allow cell selection without CAG ID randomization). The CAG access privacy mode may be set on a per PLMN basis. The same or different privacy modes may be set on a per NPN basis (e.g., per CAG ID). If the privacy mode is set to "off", the WTRU may be permitted to select a CAG cell without randomized CAG ID based access being enabled. For example, the procedure 200 illustrated in FIG. 2 may be performed to register with the network. If the privacy mode is set to "on", the WTRU may be allowed to select only CAG cells that are enabled for randomized CAG ID based access. One or more procedures (e.g., procedure 400 illustrated in FIG. 4 or procedure 500 in FIG. 5) may be performed to register with the network.

[0101] In various embodiments described above, the privacy sensitivity of the CAG ID may be linked to the privacy sensitivity of the NSSAI (e.g., by virtue of the CAG ID being associated with a particular S-NSSAI allocated to the NPN). In some examples, (re)use of the access stratum connection establishment NSSAI inclusive mode may be implemented, e.g., to enable the CAG access privacy mode while ensuring consistent enforcement of network slicing privacy policies. In some cases, in NSSAI inclusive mode 'a', the WTRU can include the NSSAI at the AS layer during AS connection establishment, and in NSSAI inclusive mode 'd', the WTRU cannot (e.g., never includes) the NSSAI at the AS layer during AS connection establishment. For example, a CAG-supporting WTRU may be permitted to select CAG cells for which randomized CAG ID-based access is disabled when the NSSAI inclusive mode is set to 'a', and can only select CAG cells for which randomized CAG ID-based access is enabled when the NSSAI inclusive mode is set to 'd'.

[0102] The NSSAI sent during AS connection establishment (e.g., at the RRC layer) may be randomized using a hash-based operation (e.g., similar to the hash-based mechanism described herein for the CAG ID). For example, the WTRU may use the random number provided by the cell broadcast as the base for the salt used to individually hash the requested S-NSSAI sent during AS connection establishment (e.g., at the RRC layer). The gNB may be configured with an S-NSSAI for routing registration requests from the WTRU to the appropriate AMF. The gNB may calculate a hash of its configured S-NSSAI to match the hashed S-NSSAI sent by the WTRU. If a match is found, the gNB may forward the request to the designated serving AMF. If no match is found, the gNB may forward the request to the default AMF.

[0103] In various embodiments, the supported S-NSSAI for a given cell or a given gNB may be randomized and broadcast using a hash-based mechanism. When a WTRU detects a change in the supported S-NSSAI while moving (e.g., in CM-IDLE state) to another cell (e.g., the connected S-NSSAI is not supported in the target cell), the WTRU can use this information to assist in the cell selection process or trigger a registration update to synchronize its allowed NSSAI with the network.

[0104] In various embodiments, the mechanism and / or procedure may be based on a temporary S-NSSAI (TS-NSSAI). For example, a WTRU (e.g., WTRU 102) may obtain one or more TS-NSSAIs from a network (e.g., AMF) during a registration procedure, e.g., in a registration accept message. For example, an NG-RAN may obtain a list of TS-NSSAIs supported by a PLMN from an AMF during an NG setup procedure, e.g., in an NG setup response message. In one embodiment, a TS-NSSAI may be generated and / or maintained per PLMN (e.g., for a PLMN or for each respective PLMN). In another embodiment, the network may maintain one or more TS-NSSAIs per WTRU and / or per S-NSSAI (e.g., for a WTRU or for each respective WTRU and / or for an S-NSSAI or for each respective S-NSSAI).

[0105] In various embodiments, the mechanism / procedure can work with one or more of the mechanisms / procedures described above, for example, when a TS-NSSAI is assigned per WTRU and / or per S-NSSAI to provide protection against WTRU linkability attacks. For example, with reference to FIG. 6, the WTRU can send one or more hash values ​​of the requested TS-NSSAI (instead of the cleartext TS-NSSAI) at the AS layer during AS connection establishment. The one or more TS-NSSAI hash values ​​may be determined and / or calculated using the S-TMSI, forcing a change in the TS-NSSAI hash every time the S-TMSI changes to mitigate WTRU linkability attacks. The NG-RAN can identify the slice of the WTRU request by matching the hashed TS-NSSAI requested by the WTRU with a hash value of the TS-NSSAI provided by the core network (e.g., 5G Core (5GC)). This representative mechanism / procedure 600 can include any of the following: Action 1-2. The NG-RAN may obtain a list of supported TS-NSSAIs (e.g., a list of supported TS-NSSAIs in addition to or instead of the S-NSSAI) from the AMF. Action 3. The WTRU may perform an initial registration procedure with the network. For example, the WTRU may obtain a list of allowed TS-NSSAIs in a registration accept message, which may be protected by NAS security, for example. Action 4. The WTRU may use its S-TMSI to determine and / or calculate the requested TS-NSSAI hash value. The WTRU may send the TS-NSSAI hash value in an RRC message (e.g., an RRCConnectionSetupComplete message). The WTRU may include an indication on the nature or type of the slice assistance information IE (e.g., hashed TS-NSSAI) to help the NG-RAN distinguish between a first WTRU capable of NSSAI privacy protection and a second WTRU not capable of NSSAI privacy protection (e.g., so that the second WTRU can send the S-NSSAI as clear text). In various embodiments, after the new S-TMSI is allocated, the WTRU may automatically send the new TS-NSSAI hash value during AS connection establishment as per or using one or more procedures discussed herein (or any existing procedures). In various embodiments, the use of an S-TMSI allows two WTRUs requesting the same TS-NSSAI to transmit different TS-NSSAI hash values ​​to mitigate, for example, a WTRU linkability attack using the same TS-NSSAI hash value. In some cases, the likelihood that the same S-TMSI will eventually be reallocated to a new WTRU requesting / using the same slice over time may be negligible in the case of a linkability attack. Operation 5. The NG-RAN may calculate a hash using the S-TMSI for each supported TS-NSSAI received from the AMF. The NG-RAN may select an appropriate AMF based on a match between the received TS-NSSAI and the supported hashed TS-NSSAI. Action 6. The NG-RAN can route the WTRU initial NAS message to the selected AMF.

[0106] In various embodiments, the NG-RAN may receive an AMF configuration update message containing an updated list of TS-NSSAIs at any time (e.g., following an update of the list of S-NSSAIs supported by the PLMN). For example, the network may maintain one set of TS-NSSAIs per PLMN, e.g., with a direct one-to-one mapping between the S-NSSAI and the TS-NSSAI.

[0107] It is understood that in various embodiments, the randomization and security mechanisms / procedures illustrated herein for the CAG ID or NSSAI information elements (IEs) may be used for confidentiality, integrity, and replay protection of other IEs that should not be sent as clear text (e.g., during initial connection establishment and / or in the absence of any existing security context).

[0108] Representative procedures for protecting the confidentiality of NPNs and / or the privacy of NPN users using a Diffie-Hellman-based key agreement protocol In various embodiments, mechanisms, methods, apparatus, and systems are disclosed for protecting the confidentiality of one or more lists of CAG IDs used in an NPN and / or the privacy of an NPN user (e.g., a WTRU). For example, a WTRU may be configured to perform one or more of the following operations:

[0109] For example, the WTRU may compare a hash value of the WTRU's locally configured set or list of allowed CAG IDs with hash values ​​of CAG IDs supported by the CAG cell (e.g., in a broadcast message and / or system information broadcast by the CAG cell, or a unicast message sent by the CAG cell) to find one or more matching CAG IDs. The WTRU may obtain, from the received message, for example, a broadcast message including system information with keying parameters (e.g., the gNB's ephemeral public key) to establish a shared secret with the RAN (e.g., the CAG cell or the gNB). For example, the WTRU may obtain, identify, and / or decrypt the keying parameters (e.g., the gNB's ephemeral public key) in the received system information to establish a shared secret with the RAN (e.g., the gNB) using a Diffie-Hellman-based key agreement protocol. The WTRU may derive a secret key using the exchanged keying parameters (e.g., one or more of the gNB's ephemeral public key and the WTRU's ephemeral public key) and the WTRU or UE identity (e.g., the C-RNTI). The WTRU may register with a network (e.g., a CAG cell or a gNB) while providing one or more matching CAG IDs that are confidentiality and integrity protected at the RRC layer (e.g., the RRC portion of the registration message) using a secret key (e.g., as in the Advanced Encryption Standard (AES) algorithm). In some cases, the remainder of the registration procedure may be accomplished in a manner similar to that described in one or more embodiments discussed herein (e.g., the procedures illustrated in FIG. 2, FIG. 4, and / or FIG. 5).

[0110] FIG. 7 is a signal flow diagram illustrating an example CAG ID protection mechanism 700 in connection with an example registration procedure. The CAG ID protection mechanism of FIG. 7 may use a Diffie-Hellman-based key agreement protocol. The CAG ID protection mechanism and / or the exemplary procedure may be used, for example, to address confidentiality of one or more lists of CAG IDs used in an NPN (e.g., a CAG cell or gNB) and / or privacy of an NPN user (e.g., a WTRU). The CAG ID protection mechanism and / or the exemplary procedure may include one or more of the following features (e.g., as shown in FIG. 7): 0. The WTRU may be configured with an allowed CAG list from the HPLMN, and the gNB may be configured with a list of supported CAG IDs. 1. The gNB may perform one or more of the following operations. For example, the gNB may generate a temporary private key a. The gNB may use a to generate a temporary public key A (e.g., A=g a mod p, where g and p are prime numbers, p may be a large prime number (e.g., 2048 bits, 3072 bits, or larger) and g is a generator (e.g., g=2). The gNB may generate a pseudo-random number (e.g., RAND_CELL). The gNB may calculate a respective hash value for each of its configured CAG IDs using RAND_CELL. 2. The WTRU may obtain keying configuration parameters from system information (e.g., SIB1). The keying configuration parameters may include any of p, g, A, RAND_CELL, and a list of hashed CAG IDs. 3. The WTRU may perform one or more of the following actions (e.g., after obtaining keying configuration parameters): For example, the WTRU may generate a temporary private key b. The WTRU may use b to generate a temporary public key B (e.g., B=g bmod p). The WTRU uses A and b to obtain the shared secret K ab (e.g., K ab =A b mod p). The WTRU then calculates K ab The WTRU may derive a secret key K from K. The WTRU may select one or more CAG IDs from the list of allowed CAG IDs whose hash value (determined / calculated using RAND_CELL) matches the hash value of at least one of the CAG IDs from the gNB (configured or supported by the gNB). For each matching CAG ID, the WTRU may use K to calculate an anonymized CAG ID (e.g., an anonymized CAG ID K =CAG ID XOR K). 4. The WTRU may send a registration request message and include the following parameters (e.g., in the RRC portion of the message): B, and one or more concealed CAGs. ID(S)K It may include any of the following: 5. The gNB may perform one or more of the following operations. For example, the gNB may use B and a to obtain a shared secret K ab (e.g., K ab =B a For one or more concealed CAG(S)K, the gNB may compute a cleartext CAG ID (e.g., cleartext CAG ID = concealed CAG ID K XORK). 6. The complete registration procedure may be accomplished in the same or similar manner as similar types of procedures in one or more embodiments disclosed herein (e.g., procedures disclosed herein in connection with FIG. 2, FIG. 4, and / or FIG. 5). In various embodiments, the gNB may verify whether the WTRU is authorized to access the CAG cell. The gNB may, for example, determine whether at least one cleartext CAG ID from the WTRU matches a CAG ID configured by the gNB. For example, if the gNB verifies that at least one cleartext CAG ID from the WTRU matches a CAG ID configured / supported by the gNB, the gNB may determine that the WTRU is authorized to access the CAG cell.

[0111] FIG. 8 is a signal flow diagram illustrating a CAG ID protection mechanism 800 in connection with an exemplary registration procedure. The CAG ID protection mechanism 800 may use an Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) based key agreement protocol. The CAG ID protection mechanism and / or the exemplary procedure may be used, for example, to address confidentiality of one or more lists of CAG IDs used in an NPN (e.g., a CAG cell or a gNB) and / or privacy of an NPN user (e.g., a WTRU). The CAG ID protection mechanism 800 may enable protection of a CAG ID transmitted by a WTRU (or UE) in a manner similar to the CAG ID protection mechanism 800 and / or the exemplary procedure 700 in FIG. 7. In the CAG ID protection mechanism 800, an EC curve 25519 is used as an example, and other curves may also be used.

[0112] This CAG ID protection mechanism 800 may include one or more of the following features (eg, as shown in FIG. 8): 0. The WTRU may be configured with an allowed CAG list from the HPLMN. The RAN (e.g., gNB) may be configured with a list of supported CAG IDs. In this example, the WTRU and the RAN / gNB may be configured with EC domain parameters (e.g., curve 25519). 1. The gNB may perform one or more of the following operations: For example, the gNB may generate a temporary private key a (e.g., a 32-byte random number). The gNB may generate a temporary public key K_A using a (e.g., K_A=X25519(a,9), where 9 is the curve base point). The gNB may generate a pseudo-random number (e.g., RAND_CELL=least significant n bits of K_A). The gNB may calculate a respective hash value for each of its configured CAG IDs using RAND_CELL. In various embodiments, a hash value of the configured CAG ID may be bound to a temporary public key K_A by computing RAND_CELL as a function (e.g., truncation) of K_A. This can enable protection of the DH key agreement against attacks (e.g., man-in-the-middle (MiTM) attacks) where an attacker attempts to replace K_A (generated by the gNB) with its own key and establish a shared secret with the WTRU (e.g., to obtain the cleartext CAG ID). A new K_A may be generated periodically (e.g., frequently) to reduce the likelihood of a replay attack on the WTRU hashed CAG ID (e.g., in the RRCSetupComplete message). The gNB may, for example, include a nonce (e.g., a pseudorandom number) in the broadcast message, which may vary independently of K_A. For example, a new a and a new K_A may be used for a given time period (e.g., every few hours), while a new nonce may be generated and used i) independent of K_A generation, and ii) for a different time period (e.g., a shorter time period, every few minutes). Thus, this process may provide additional novelty (e.g., based on a policy) and may be used to save on K_A processing costs while providing protection against replay attacks using the WTRU connection request. 2. The WTRU may obtain keying configuration parameters from system information (e.g., SIB1). The keying configuration parameters may include any of the K_A configured and / or supported by the gNB and a list of hashed CAG IDs. If a nonce is included in the (e.g., broadcasted) system information (SI), the WTRU may obtain the nonce. 3. The WTRU may perform one or more of the following operations (e.g., after obtaining keying configuration parameters): For example, the WTRU may generate a temporary private key b. The WTRU may use b to generate a temporary public key B (e.g., K_B=X25519(b,9)). The WTRU may use K_A and b to generate a shared secret S (e.g., S=X25519(b,K_A)). The WTRU may use a key derivation function, K_A, K_B, and / or a WTRU or UE identity to derive a private key K from S (e.g., K=HMAC-SHA256(S,K_A||K_B||C-RTNI)). If a nonce is included in the broadcasted SI, the WTRU may use the nonce in the calculation of K (e.g., by concatenation with one or more other parameters). The WTRU may select one or more CAG IDs from the list of allowed CAG IDs whose hash value (determined / calculated using RAND_CELL) matches the hash value of at least one of the CAG IDs from the gNB (configured or supported by the gNB), where RAND_CELL is obtained from K_A as described in Feature 1 and / or Feature 2. For each, some, or all of the matched CAG IDs, the WTRU may use K to calculate a masked CAG ID (e.g., a masked CAG ID K =K and the CAG ID encrypted / integrity protected using the AES algorithm). 4. The WTRU may send a registration request message and may include (e.g., in the RRC portion of the message) any of the following parameters: K_B and one or more concealed CAG ID(S)K. For example, the WTRU may include the received nonce from the broadcast SI (e.g., for session synchronization between Feature 1, Feature 2, and / or Feature 4 described above, in the case when the registration request message may need to be synchronized with the broadcast message described above in Feature 1 and / or Feature 2). 5. The gNB may perform the following operations: For example, the gNB may generate a shared secret S using K_B and a (e.g., S=X25519(a,K_B)). For one or more concealed CAG(S)K, the gNB may calculate a cleartext CAG ID (e.g., cleartext CAG ID=CAG ID using K (verifying integrity protection) and the AES algorithm). K (decode the WTRU request). The gNB can verify the novelty of the WTRU request by validating that the included nonce corresponds to the current nonce in the broadcasted SI. The gNB may consider a WTRU request that uses a previous nonce valid (e.g., based on policy). In some cases, using the previous nonce to check the validity can avoid the gNB rejecting a WTRU that attempts to connect to the gNB using a previous nonce that has just been replaced with a new one in the broadcasted SI. 6. The complete registration procedure may be performed in the same or similar manner as similar types of procedures in one or more embodiments disclosed herein (e.g., procedures 200, 400, 500 and / or 700 disclosed herein in connection with Figures 2, 4, 5 and / or 7).

[0113] Various embodiments disclosed herein illustrate mechanisms for protecting the CAG ID during the RRC connection establishment procedure. It is contemplated that the protection mechanisms may also be used for confidentiality, integrity, and replay protection of other procedures and / or of information elements (IEs) that cannot be sent as clear text, e.g., during the initial connection establishment and / or in the absence of any existing / valid security context.

[0114] In various embodiments, the WTRU may protect the NSSAI during AS connection establishment using a secret K as disclosed herein. The WTRU may apply security protection to the NSSAI during AS connection establishment based on the NSSAI inclusion mode parameter (as described above). For example, when the NSSAI inclusion mode is 'd', the WTRU may protect the transmitted NSSAI using a secret K. This protection mechanism may enable the gNB to decrypt the NSSAI during AS connection establishment in order to forward the initial WTRU request to the designated serving AMF instead of the default AMF, even when the WTRU is configured with NSSAI inclusion mode 'd'. In some implementations, when the WTRU operates in mode 'd', the gNB may forward the WTRU request to the default AMF, possibly leading to additional AMF redistribution procedures.

[0115] In various embodiments, in cases where "cold start" data transmission is used together with over-the-air data protection (e.g., data transmission during initial registration and / or during AS attachment establishment procedures), other IEs such as user data may be transmitted with confidentiality, integrity, and replay protection using the mechanisms disclosed herein.

[0116] Among the types of IEs that may be protected using the protection mechanisms disclosed herein are those used during AS connection establishment, including, for example, WTRU or UE identities. Examples of WTRU or UE identities (identifiers) may include a System Architecture Evolution (SAE) Temporary Mobile Subscriber Identity (S-TMSI) and / or a 5G Globally Unique Temporary UE Identity (5G-GUTI). For example, the confidentiality and replay protection of the protection mechanisms disclosed herein may protect against an adversary attempting to establish a spoofed RRC connection using a target WTRU or UE identity (e.g., S-TMSI) to cause a DoS attack on the target WTRU. In an example attack scenario, the target WTRU is in RRC_IDLE while the target WTRU is considered RRC_CONNECTED in the network or gNB after a malicious RRC connection attempt. In such an attack, the target WTRU may stop receiving paging messages because it is considered already connected to the network or gNB.

[0117] Representative procedures for protecting the confidentiality of NPN and / or the privacy of NPN users using ECIES In various embodiments, the WTRU may use ECIES to protect one or more CAG IDs transmitted while establishing an AS connection.

[0118] For example, the WTRU may obtain a RAN (e.g., gNB) public key from the broadcasted SI. The WTRU may use the RAN public key and the generated temporary public / private key pair in the ECIES to derive symmetric encryption and message authentication code (MAC) keys. The WTRU may use one or more of these keys to protect one or more (e.g., selected) CAG IDs. For example, the WTRU may send a WTRU-generated temporary public key and / or a cryptographically written and integrity-protected CAG ID (e.g., a CAG ID ciphertext with its MAC tag) during RRC connection establishment (e.g., in an RRCSetupComplete message). After receiving a message containing the protected CAG ID, the RAN (e.g., gNB) may perform an ECIES key agreement function using the RAN private key and the WTRU-provided temporary public key to derive the symmetric encryption and MAC keys. Using these keys, the RAN may verify the CAG ID integrity and decrypt the CAG ID ciphertext.

[0119] It is contemplated that the RAN may support different types of CAG ID protection mechanisms to accommodate WTRUs with different capabilities or may support the introduction of different protection mechanisms. The RAN may broadcast (e.g., as a predefined code) one or more supported key agreement and protection mechanisms (e.g., ECDH, ECIES, encryption, and / or integrity algorithms). The WTRU may select a protection method based on its security capabilities. The WTRU may convey and / or provide the selected protection mechanism to the RAN along with the protected CAG ID information (e.g., as a unique code in an RRC Setup message). In various embodiments, a gNB that supports both ECDH and ECIES mechanisms (described above) may be able to determine whether a received ephemeral public key is to be used in the ECDH mechanism or the ECIES mechanism based on the protected CAG ID information (e.g., a unique code) provided by the WTRU.

[0120] In various embodiments, the WTRU may obtain the RAN (e.g., gNB) public key after successful registration using a confidentiality, integrity, and replay protected unicast message (e.g., RRC Reconfiguration message). The WTRU may protect the transmitted CAG ID using the RAN public key during RRC connection establishment (e.g., similar to the procedures disclosed herein). The WTRU may store the RAN public key and may reuse the RAN public key in subsequent RRC connection establishments (e.g., during service request and / or registration procedures). One or more CAG ID protection mechanisms (e.g., any of those employing key agreement, encryption, and / or integrity algorithms) supported by the WTRU may be transmitted as part of the WTRU (or UE) security capabilities. The (e.g., selected) protection mechanism may be negotiated between the WTRU and the RAN during the AS Security Mode Command (SMC) procedure or may be conveyed to the WTRU by the RAN in a different message (e.g., RRC Reconfiguration message). In a subsequent RRC connection establishment, if the WTRU has the RAN public key, the RAN may or may not provide a new or fresh public key (e.g., based on its security policy). To enable RAN public key revocation, it is contemplated that the RAN may send an identifier (e.g., a unique index) of the public key to the WTRU. The WTRU may send an identifier of the public key (used for CAG ID protection) during the RRC connection establishment (e.g., in the RRCSetupComplete message). Based on the provided key identifier, the RAN may detect that the public key used to protect the CAG ID has been revoked and may decide to provide a new public key to the WTRU.

[0121] In various embodiments, upon detection of a key revocation condition or per serving network security policy, the WTRU may replace a previously stored public key with a new one (or remove the old key or previously stored public key).

[0122] One or more of the above embodiments may be used in a standalone manner, but they may also be combined, for example, a WTRU may use a Diffie-Hellman based procedure / mechanism for initial registration and an ECIES based procedure / mechanism for subsequent registrations.

[0123] Various embodiments disclosed herein use ECIES to provide CAG ID protection during the RRC connection establishment procedure. It is contemplated that these protection mechanisms may also be used for confidentiality, integrity, and replay protection of other procedures and / or of IEs that cannot be sent as clear text, e.g., during initial connection establishment and / or in the absence of any existing / valid security context.

[0124] Representative Procedure with WTRU Configuration Associated with CAG Cell Location In various embodiments, when moving to a new CAG cell, the WTRU configuration (e.g., based on the allowed NSSAI or associated with the CAG cell location) may not be correct. When a WTRU in CM-IDLE state (e.g., a WTRU that supports NPN) moves from one CAG cell to another CAG cell, the WTRU may compare the broadcasted CAG ID list in the new CAG cell with the broadcasted CAG ID list in the previous CAG cell. If the common and / or overlapping CAG IDs of the WTRU's allowed CAG ID list and broadcasted CAG ID list in the new cell are different from the CAG IDs of the WTRU's allowed CAG ID list and broadcasted CAG ID list in the previous cell, the WTRU may initiate a registration and / or service request procedure with the network, e.g., to synchronize its current CAG cell location with the network and / or receive the appropriate configuration (e.g., allowed NSSAI) for the new CAG cell. To perform the above-mentioned CAG ID comparison, the WTRU may store the CAG ID list of the previous cell and / or a common portion of the CAG ID list of the previous cell.

[0125] In various embodiments, a WTRU may have an allowed CAG ID list that can accommodate or include "CAG-1" and "CAG-2," and the WTRU may camp on a CAG cell that broadcasts a CAG ID list of "CAG-1" and "CAG-3." The common (e.g., overlapping) portion of the WTRU's allowed CAG ID list and the broadcasted CAG ID list is "CAG-1." When the WTRU moves to a new CAG cell that broadcasts a CAG ID list of "CAG-2" and "CAG-4," the common portion of the WTRU's allowed CAG ID list and the broadcasted CAG ID list may be changed to "CAG-2."

[0126] Upon determining / observing such a change (e.g., this change), the WTRU may initiate a registration and / or service request procedure. During or after the registration / service request procedure, the network may recognize that the WTRU's CAG location has changed, and the network may send an associated configuration (e.g., an allowed NSSAI) to the WTRU during the same registration or service request procedure, or the network may initiate another NAS procedure, such as a UE Configuration Update (UCU) procedure, to update the configuration.

[0127] In various embodiments, if mobility occurs between different CAG cells while the WTRU is in RRC_INACTIVE state, the WTRU may initiate an RRC connection resumption procedure when the WTRU observes that the common part of the CAG ID has changed. In the RRC resumption request message, the WTRU may indicate that the reason for the request is "CAG cell change / update". The serving RAN may include the CAG ID list of the current cell in the N2 path switch request message sent to the network so that the network can recognize that the WTRU's CAG location has changed and can send an updated configuration to the WTRU. For example, a RAN notification area (RNA) configured for a WTRU in RRC_INACTIVE mode may contain or include only cells with the same CAG ID, such that a change in CAG cell may automatically trigger an RNA update procedure that may enable the network to update the configuration, for example.

[0128] 9, a handover procedure 900 between CAG cells is provided. In various embodiments, for a WTRU (e.g., WTRU 102) in CONNECTED mode, the WTRU may include the CAG IDs of neighboring CAG cells in its measurement report, for example, as illustrated in handover procedure 900. When a serving RAN (or serving cell / gNB) chooses a target cell for handover, the serving RAN (or serving cell / gNB) may consider CAG cells that have at least one common CAG ID with itself.

[0129] In various embodiments, after the WTRU completes the handover procedure, if the common part of the CAG ID in the target cell has changed, the WTRU may initiate a registration procedure in connected mode from the target cell. The WTRU may receive a new configuration (e.g., an allowed NSSAI) from the network. If the S-NSSAI associated with the WTRU's currently active PDU session is not in the updated allowed NSSAI, the WTRU may initiate a PDU session release procedure for the PDU session.

[0130] In the handover procedure 900, the WTRU reports the CAG IDs of the measured cells so that the source RAN can take the CAG IDs into account for choosing one or more handover target cells. The WTRU can trigger registration after the handover to receive updated configurations, check active PDU sessions against updated NSSAIs (e.g., allowed NSSAIs), and take appropriate actions (e.g., initiate PDU session release).

[0131] Representative Procedure for WTRU Authorized CAG ID Configuration Following Subscription Renewal In various embodiments, exemplary mechanisms / procedures may be used to prevent a system or network from causing exhaustion of an allowed CAG ID list for a WTRU and subsequently barring the WTRU from network access or further network access. For example, a mechanism / procedure may be implemented to prevent a WTRU from having an incorrect or expired allowed CAG ID configuration following a subscription update with the network (e.g., AMF), while the WTRU may not, for example, be registered with the network. Exemplary mechanisms / procedures may include any of the following actions:

[0132] For example, when the WTRU registers with the network, the WTRU may include its allowed CAG ID list in the complete initial NAS message sent in the NAS SMC Complete message. In another example, the WTRU may include a flag indicating that the WTRU's allowed CAG ID list accommodates or includes only one CAG ID or several CAG IDs. The CAG ID selected by the WTRU to access the cell may be provided or sent by the NG-RAN to the AMF via an N2 message (e.g., the N2 message shown in FIG. 2). The WTRU may provide an indication of whether the WTRU can access the network only through the CAG cell.

[0133] In various embodiments, the AMF may detect that the subscription data is not synchronized based on the allowed CAG ID list received from the WTRU. For example, the subscription may have been updated while the WTRU was not registered in the network. If the WTRU sends its allowed CAG ID list to the AMF, the AMF may identify (and / or determine) that the list is different from the one in the subscription data. If the WTRU does not send its allowed CAG ID list to the AMF, the AMF may identify (and / or determine) that the CAG ID received from the NG-RAN is not part of the allowed CAG ID list from the subscription data.

[0134] In various embodiments, the AMF may determine that the WTRU can access the network only through a CAG cell. An indication (e.g., an indication value) in the subscription (e.g., subscription data) may have been updated with the allowed CAG ID list, so that the AMF can use the corresponding indication (e.g., an indication value) provided by the WTRU. The AMF can update the WTRU CAG configuration information (e.g., the allowed CAG ID list and / or an optional indication indicating whether the WTRU is allowed to access the network only through a CAG cell). For example, by sending a message to update its configuration (e.g., a UE Configuration Update message) to the WTRU, the AMF can send a new allowed CAG ID list and / or provide a new (or updated) indication to indicate whether the WTRU can access the network only through a CAG cell. In another example, the AMF can provide the new CAG configuration information in a protected registration response (e.g., a registration reject message).

[0135] In various embodiments, the WTRU may update its allowed CAG ID list (e.g., based on the update information and / or an indication received from the network, as described above). For example, the WTRU may remove outdated CAG IDs and add one or more new CAG IDs. Following this CAG information configuration update, the WTRU may, for example, perform new CAG cell selection and / or network registration using its new (or updated) allowed CAG ID list. In various embodiments, the WTRU may update its allowed CAG ID list based on an existing WTRU configuration update (e.g., UE configuration update) procedure and / or new CAG configuration information provided to the WTRU (e.g., through any other protected message).

[0136] In some examples, an adversary may attempt to force a WTRU to empty its allowed CAG ID list. For example, the adversary may send a spoofed registration rejection message with a suitable reason for the CAG ID rejection, causing removal of one or more, or all, CAG IDs. In various embodiments, to protect the WTRU against this type of attack, for example, the WTRU may remove one or more CAG IDs from its allowed CAG ID list only if the registration rejection message is at least integrity protected.

[0137] Representative steps for a secure access control mechanism In various embodiments, methods and apparatuses for secure access control in wireless communications, e.g., secure access control mechanisms (e.g., for NG-RAN) are provided. For example, a method for wireless communications (e.g., implemented in a WTRU 102) may include receiving a broadcast message including system information, and identifying a first set of hash IDs and a first random number based on the system information, where each ID in the first set of hash IDs may be individually hashed using at least the first random number. The method may also comprise calculating a first hash value for each ID in a second set of IDs using at least the first random number, determining whether at least one hash ID in the second set of IDs matches a hash ID in the first set of hash IDs, and sending / transmitting a request message based on a determination that at least one hash ID in the second set of IDs matches a hash ID in the first set of hash IDs.

[0138] In various embodiments, the method may include, based on a determination that at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs, calculating, using at least one second random number, a second hash value for at least one ID associated with a hash ID of the second set of IDs that matches a hash ID of the first set of hash IDs. In various embodiments, the second hash value is calculated using the second random number and a network-assigned WTRU ID. In various embodiments, the network-assigned WTRU ID is a Cell-Radio Network Temporary Identifier (C-RNTI). In various embodiments, the request message is a Radio Resource Control (RRC) message, and the RRC message may include information of the second random number or an ID hashed by at least the second random number.

[0139] In various embodiments, when determining whether at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs, the method may include comparing each hash ID of the second set of IDs to each hash ID of the first set of hash IDs.

[0140] In various embodiments, each ID in the first set of hashed IDs is hashed individually using the first random number and the cell ID. In various embodiments, the first set of hashed IDs includes one or more hashed CAG IDs. In various embodiments, the second set of IDs includes one or more pre-configured authorized CAG IDs.

[0141] In various embodiments, the method may include identifying a second random number based on the system information and calculating a second hash value for at least one ID associated with a hash ID of the second set of IDs that matches a hash ID of the first set of hash IDs using at least the second random number.

[0142] In various embodiments, the request message may be a registration request message and the method may include receiving a registration response message including a set of permitted CAG IDs and replacing the stored set of permitted CAG IDs with the set of permitted CAG IDs received in the registration response message. In various embodiments, the registration response message is a registration accept message or a registration reject message.

[0143] In various embodiments, on the condition that no matching ID is found by the network entity (e.g., gNB), the method may include receiving a registration reject message after sending the registration request message. In various embodiments, on the condition that at least one matching ID is found by the network, the method may include receiving a registration accept message after sending the registration request message. In various embodiments, a first hash of each ID in the second set of IDs may be calculated using the first random number and the cell ID.

[0144] In various embodiments, a method for wireless communication (e.g., implemented in the WTRU 102) may comprise establishing a shared secret with a network entity based on one or more keying configuration parameters and a secret key associated with the WTRU; deriving a secret key based on the shared secret and any of the one or more keying configuration parameters, a public key associated with the WTRU, and an ID of the WTRU; generating a concealed ID for each hash ID of a first set of hash IDs associated with the WTRU based on the secret key that matches a hash ID of a second set of hash IDs associated with the network entity; and performing a registration procedure based on the one or more concealed IDs generated by the WTRU.

[0145] In various embodiments, the method may comprise receiving a message (e.g., a broadcast message including system information or a unicast message) from a network entity (e.g., a gNB) and identifying a set of one or more keying configuration parameters and a second hash ID based on the received message.

[0146] In various embodiments, when performing the registration procedure, the method may include transmitting one or more hidden IDs generated by the WTRU.

[0147] In various embodiments, when establishing a shared secret with a network entity, the method may include generating the shared secret with the network entity using one or more keying configuration parameters and a private key, where the one or more keying configuration parameters may include a public key associated with the network entity.

[0148] In various embodiments, the method may include generating a public key associated with the WTRU using the private key, and performing the registration procedure may include transmitting one or more hidden IDs and the public key associated with the WTRU.

[0149] In various embodiments, the one or more keying configuration parameters may include either a public key associated with the network entity and a random number associated with the network entity. In various embodiments, the random number may be bound to the public key associated with the network entity. In various embodiments, the random number may be determined based on a function of the public key associated with the network entity. In one example, the function includes truncation of the public key associated with the network entity.

[0150] In various embodiments, the WTRU's ID (or WTRU ID) is a Cell Radio Network Temporary Identifier (C-RNTI) or a designated RNTI assigned by the network (eg, NG-RAN).

[0151] In various embodiments, the set of hashed IDs may include one or more pre-configured authorized CAG IDs, or one or more subscriber IDs including one or more NPN IDs.

[0152] In various embodiments, the set of hashed IDs may include one or more hashed CAG IDs or hashed NPN IDs supported by the network entity.

[0153] In various embodiments, performing a registration procedure may include sending a registration request message that includes one or more hidden identities.

[0154] In various embodiments, the method may identify a public key associated with the network entity from the one or more keying configuration parameters, and deriving the private key includes deriving one of a symmetric encryption key and a Message Authentication Code (MAC) key using the identified public key associated with the network entity.

[0155] In various embodiments, the set of hashed IDs may be a locally generated set of hashed CAG IDs or a locally stored set of hashed CAG IDs.

[0156] In various embodiments, generating the one or more hidden IDs may include selecting at least one hash ID of a second set of hash IDs that matches a hash ID of the first set of hash IDs.

[0157] In various embodiments, the network entity may be any of an AMF entity, a base station, a gNB, and a network node.

[0158] In various embodiments, the public or private keys disclosed herein may be temporary keys.

[0159] In various embodiments, a method for wireless communication (e.g., implemented in a WTRU 102) may comprise determining that a WTRU (e.g., a WTRU 102) is in an idle mode, identifying a set of pre-configured IDs associated with the WTRU, identifying a first set of IDs associated with a first cell and a second set of IDs associated with a second cell, and initiating a registration procedure or a service request procedure with the condition that one or more pre-configured IDs common to the first set of IDs are different from one or more pre-configured IDs common to the second set of IDs.

[0160] In various embodiments, either the first set of IDs or the second set of IDs may include one or more CAG IDs or NPN IDs. The preconfigured set of IDs may include one or more preconfigured authorized CAG IDs or one or more subscriber IDs including one or more NPN IDs.

[0161] In various embodiments, a method for wireless communication (e.g., implemented in a WTRU 102) may comprise determining that a WTRU (e.g., the WTRU 102) is in an RRC inactive mode, identifying a set of pre-configured IDs associated with the WTRU, identifying a first set of IDs associated with a first cell and a second set of IDs associated with a second cell, and initiating an RRC connection resumption procedure with a condition that one or more pre-configured IDs common to the first set of IDs are different from one or more pre-configured IDs common to the second set of IDs.

[0162] In various embodiments, a method for wireless communication (e.g., implemented in a WTRU 102) may comprise reporting a set of IDs of one or more measurement cells to a first cell, initiating a registration procedure after handing over to a second cell, receiving an updated configuration including an updated authorized NSSAI, and determining whether to initiate a PDU session release depending on whether one or more single NSSAIs (S-NSSAIs) associated with one or more active protocol data unit (PDU) sessions are in the updated authorized NSSAI.

[0163] In various embodiments, the set of IDs may include one or more subscriber IDs, including one or more CAG IDs, or one or more NPN IDs.

[0164] In various embodiments, the CAG information may include a flag indicating whether the stored authorized CAG ID list includes only one CAG ID, multiple CAD IDs, or several CAG IDs.

[0165] In various embodiments, a method for wireless communication (e.g., implemented in a WTRU 102) may include receiving a first message including a set of TS-NSSAIs supported by a network (e.g., a gNB) and a WTRU ID assigned by the network during a registration procedure. After receiving the first message, the method may comprise calculating one or more hash values ​​for the set of requested TS-NSSAIs using the WTRU ID assigned by the network and a random number, and transmitting a second message including at least the one or more hash values ​​and the random number. In one example, the set of requested TS-NSSAIs includes one or more TS-NSSAIs from the set of TS-NSSAIs supported by the network.

[0166] In various embodiments, the first message may be a registration accept message. In various embodiments, the second message may be a radio resource control (RRC) message.

[0167] In various embodiments, an apparatus (e.g., the WTRU 102) may comprise a receiver configured to receive a broadcast message including system information. The apparatus may also include a processor configured to identify a first set of hash IDs and a first random number based on the system information, where each ID in the first set of hash IDs may be hashed individually using at least the first random number. The apparatus may calculate a first hash value for each ID in a second set of IDs using at least the first random number and determine whether at least one hash ID in the second set of IDs matches a hash ID in the first set of hash IDs. The apparatus may also comprise a transceiver / transmitter configured to transmit a request message based on a determination that at least one hash ID in the second set of IDs matches a hash ID in the first set of hash IDs.

[0168] In various embodiments, a WTRU (eg, WTRU 102) may include a processor, a transceiver, and a memory to implement any of the methods disclosed above.

[0169] Each of the following documents is incorporated herein by reference: (1) Non-Patent Document 1, (2) Non-Patent Document 2, (3) Non-Patent Document 3, (4) Non-Patent Document 4, (5) Non-Patent Document 5, (6) Non-Patent Document 6, (7) Non-Patent Document 7, (8) Non-Patent Document 8, (9) Non-Patent Document 9, (10) Non-Patent Document 10, (11) Non-Patent Document 11, (12) Non-Patent Document 12, (13) Non-Patent Document 13, (14) Non-Patent Document 14, and (15) Non-Patent Document 15.

[0170] Although features and elements are described above in certain combinations, one skilled in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of non-transitory 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 internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in the WTRU 102, UE, terminal, base station, RNC, or any host computer.

[0171] Further, in the above embodiments, processing platforms, computing systems, controllers, and other devices including processors are described. These devices may include at least one central processing unit (CPU) and memory. In accordance with the practices of those skilled in the art of computer programming, references to acts and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "executed by a computer," or "executed by a CPU."

[0172] Those skilled in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents the data bits which may cause the resulting transformation or reduction of the electrical signals and the maintenance of the data bits in memory locations within a memory system, thereby reconfiguring or altering the operation of the CPU and other processing of the signals. The memory locations in which the data bits are maintained are physical locations that have specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that representative embodiments are not limited to the above platforms or CPUs, and that other platforms and CPUs may support the provided methods.

[0173] The data bits may also be maintained on computer readable media including magnetic disks, optical disks, and other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read only memory (ROM)) CPU readable mass storage systems. The computer readable media may include cooperative or interconnected computer readable media that reside exclusively on a processing system or that are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It will be appreciated that representative embodiments are not limited to the above memories and that other platforms and memories may support the described methods.

[0174] In an example embodiment, any of the operations, processes, etc. described herein may be implemented as computer readable instructions stored on a computer readable medium. The computer readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0175] There is little difference between hardware and software implementations of aspects of a system. The use of hardware or software is generally (though not always, the choice between hardware and software may be significant in certain contexts) a design choice that represents a trade-off between cost and efficiency. There may be a variety of media (e.g., hardware, software, and / or firmware) in which the processes and / or systems and / or other techniques described herein may be effected, and the preferred media may vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may select a primarily hardware and / or firmware media. If flexibility is paramount, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0176] The foregoing detailed description illustrates various embodiments of devices and / or processes by using block diagrams, flow charts, and / or examples. To the extent that such block diagrams, flow charts, and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation in such block diagrams, flow charts, or examples, individually and / or collectively, can be implemented by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include, for example, general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application specific integrated circuits (ASICs), application specific standard products (ASSPs), field programmable gate array (FPGA) circuits, other types of integrated circuits (ICs), and / or state machines.

[0177] Although features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure should not be limited with respect to the specific embodiments described in this application, which are intended as examples of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from its spirit and scope. No element, act, or instruction used in the description of this application should be construed as critical or essential to the invention unless expressly provided as such. In addition to those enumerated herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to be included within the scope of the appended claims. The present disclosure should be limited only by the terms of the appended claims, and the full scope of equivalents to which such claims are entitled. It is understood that this disclosure is not limited to any particular method or system.

[0178] It should also be understood that the terms used herein are for the purpose of describing certain aspects only and are not intended to be limiting. As used herein, the terms "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" when referred to herein, mean (i) a wireless transmit / receive unit (WTRU), as described below, (ii) any of several embodiments of a WTRU, as described below, (iii) a wireless-enabled and / or wired-enabled (e.g., tetherable) device configured with some or all of the structure and functionality of a WTRU, as described below, (iv) a wireless-enabled and / or wired-enabled device configured with less than all of the structure and functionality of a WTRU, as described below, or (iv) the like. Details of an exemplary WTRU that may represent any UE enumerated herein are provided below with respect to Figures 1A-1D.

[0179] In certain representative embodiments, some portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will understand that some aspects of the embodiments disclosed herein may be implemented in whole or in part within an integrated circuit as one or more computer programs (e.g., multiple programs running on one or more computer systems) running on one or more computers, as one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), as firmware, or virtually any combination thereof, and that designing circuitry and / or writing code for software and / or firmware is within the skill of those skilled in the art in light of this disclosure. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein may be distributed as program products in various forms, and that the exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually perform the distribution. Examples of signal bearing media include, but are not limited to, recordable type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission type media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.).

[0180] The subject matter described herein may depict different components that are included in or connected with different other components. It should be understood that such depicted architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. In a conceptual sense, an arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality can be achieved. Thus, any two components herein that are combined to achieve a particular functionality may be considered to be "associated" with each other such that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated may also be considered to be "operably connected" or "operably coupled" with each other to achieve the desired functionality, and any two components that may be so associated may also be considered to be "operably coupled" with each other to achieve the desired functionality. Specific examples of operably coupleable include, but are not limited to, physically coupleable and / or physically interacting components, and / or wirelessly interacting and / or wirelessly interacting components, and / or logically interacting and / or logically interacting components.

[0181] With respect to the use of virtually any plural and / or singular term herein, one of ordinary skill in the art can translate from plural to singular and / or from singular to plural as appropriate to the context and / or application. For clarity, various singular / plural permutations may be expressly set forth herein.

[0182] In general, the terms used herein, and particularly in the appended claims (e.g., the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," etc.). Where a particular number of introduced claim recitations are intended, such intent will be expressly set forth in the claim, and in the absence of such recitation, it will be further understood by those skilled in the art that no such intent exists. For example, where only one item is intended, the term "single" or similar language may be used. However, use of such phrases should not be construed to mean that the introduction of a claim recitation by the indefinite article "a" or "an" limits a particular claim that includes such introduced claim recitation to embodiments that include only one such recitation. The same claim may include the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as "at least one" or "one or more"). This also applies to the use of definite articles used to introduce claim recitations. Moreover, even if a specific number of introduced claims is explicitly recited, one of ordinary skill in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations" without other qualifiers means at least two recitations, or more than two recitations).

[0183] Furthermore, when a convention similar to "at least one of A, B, C, etc." is used, such a configuration is generally intended in the sense that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems of A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, C together). When a convention similar to "at least one of A, B, or C, etc." is used, such a configuration is generally intended in the sense that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems of A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, C together). It will be further understood by those skilled in the art that virtually all disjunctive words and / or phrases presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either term, or both terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B." Additionally, as used herein, the term "any of" following a list of multiple items and / or multiple categories of items is intended to include "any of," "any combination," "any more than one," and / or "any combination of more than one" of the items and / or categories of items, individually or in combination with other items and / or items of other categories. Additionally, as used herein, the term "set" or "group" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

[0184] Furthermore, when features or aspects of the disclosure are described in terms of a Markush group, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual members or subgroups of members of the Markush group.

[0185] As will be understood by those skilled in the art, for all purposes, including with respect to providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any range listed can be easily recognized as being sufficiently descriptive to allow the same range to be divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be easily broken down into a lower third, middle third, and upper third, etc. As will also be understood by those skilled in the art, all language such as "up to," "at least," "greater than," "less than," etc. refers to a range that includes the recited numbers and can then be broken down into subranges as described above. Finally, as will be understood by those skilled in the art, a range includes individual members. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, etc.

[0186] Moreover, the claims should not be construed as limited to the order or elements provided unless stated to that effect. Moreover, use of the term "means for" in the claims is intended to invoke 35 U.S.C. 112, paragraph 6 or means-plus-function claim format, and claims without the term "means for" are not so intended.

[0187] A processor in association with software may be used to implement a radio transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME) or evolved packet core (EPC) or radio frequency transceiver for use in any host computer. The WTRU may be used in combination with modules implemented in hardware and / or software including software defined radios (SDRs), as well as cameras, video camera modules, videophones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth modules, frequency modulation (FM) radio units, near field communications (NFC) modules, liquid crystal display (LCD) display units, organic light emitting diode (OLED) display units, digital music players, media players, video game player modules, Internet browsers, and / or wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0188] Although the invention has been described with respect to a communications system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In particular embodiments, one or more of the functions of the various components may be implemented in software controlling a general purpose computer.

[0189] Although the invention has been illustrated and described herein with reference to specific embodiments, it is not intended to limit the invention to the details shown, but rather various changes in details may be made within the scope and range of equivalents of the claims without departing from the invention.

[0190] Throughout this disclosure, those skilled in the art will understand that certain representative embodiments may be used in the alternative or in combination with other representative embodiments.

[0191] Although features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of non-transitory 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 internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in conjunction with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0192] Further, in the above embodiments, processing platforms, computing systems, controllers, and other devices including processors are described. These devices may include at least one central processing unit (CPU) and memory. In accordance with the practices of those skilled in the art of computer programming, references to acts and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "executed by a computer," or "executed by a CPU."

[0193] Those skilled in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents the data bits which may cause the transformation or reduction of the resulting electrical signals and the maintenance of the data bits in memory locations within the memory system, thereby reconfiguring or altering the operation of the CPU and other processing of the signals. The memory locations in which the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits.

[0194] The data bits may also be maintained on computer readable media including magnetic disks, optical disks, and other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read only memory (ROM)) CPU readable mass storage systems. The computer readable media may include cooperative or interconnected computer readable media that reside exclusively on a processing system or that are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It will be appreciated that representative embodiments are not limited to the above memories and that other platforms and memories may support the described methods.

[0195] Suitable processors include, for example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), an application specific standard product (ASSP), a field programmable gate array (FPGA) circuit, other types of integrated circuits (ICs), and / or state machines.

[0196] Although the invention has been described with respect to a communications system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In particular embodiments, one or more of the functions of the various components may be implemented in software controlling a general purpose computer.

[0197] Although the invention has been illustrated and described herein with reference to specific embodiments, it is not intended to limit the invention to the details shown, but rather various changes in details may be made within the scope and range of equivalents of the claims without departing from the invention.

Claims

1. 1. A method of wireless communication performed by a wireless transmit / receive unit (WTRU), comprising: sending a first registration request to a network entity via a first Closed Access Group (CAG) cell, the first registration request indicating CAG capabilities; receiving a registration reject message having new CAG identifier (CAG ID) information; updating a CAG configuration using the new CAG ID information; selecting a second CAG cell based on the new CAG ID information; sending a second registration request to the network entity via the selected second CAG cell; A method for providing the above.

2. The method of claim 1 , wherein updating the CAG configuration includes deleting stored CAG ID information and adding the new CAG ID information.

3. The method of claim 1 , wherein receiving a registration reject message with new CAG ID information comprises receiving the registration reject message as integrity protected.

4. The method of claim 1 , wherein receiving a registration reject message with new CAG ID information includes receiving the new CAG ID information from an access and mobility management function.

5. prior to sending the first registration request; identifying a first set of hashed IDs and a first random number based on received system information, each ID in the first set of hashed IDs being individually hashed using at least the first random number; calculating a first hash value for each ID in a second set of IDs using at least the first random number; determining whether at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs; The method of claim 1 , further comprising:

6. 6. The method of claim 5, further comprising: based on a determination that at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs, calculating a second hash value for at least one ID associated with a hash ID of the second set of IDs that matches a hash ID of the first set of hash IDs using at least one second random number, wherein the first registration request is a message including information of the second random number and any of the IDs hashed by the second random number.

7. 7. The method of claim 6, wherein the second hash value is calculated using the second random number and a wireless transmit / receive unit (WTRU) ID assigned by a network.

8. 6. The method of claim 5, wherein the first set of hashed IDs includes one or more hashed CAG IDs and the second set of IDs includes one or more pre-configured authorized CAG IDs.

9. 1. A wireless transmit / receive unit (WTRU) comprising circuitry including a transmitter, a receiver, a processor, and a memory, the WTRU comprising: sending a first registration request to a network entity via a first Closed Access Group (CAG) cell, the first registration request indicating CAG capabilities; receiving a registration reject message having new CAG identifier (CAG ID) information; updating a CAG configuration using the new CAG ID information; selecting a second CAG cell based on the new CAG ID information; sending a second registration request to the network entity via the selected second CAG cell; A WTRU configured to perform the following:

10. The WTRU of claim 9 , wherein the WTRU updating the CAG configuration includes deleting stored CAG ID information and adding the new CAG ID information.

11. The WTRU of claim 9 , wherein the WTRU is configured to receive a registration reject message that is integrity protected.

12. The WTRU of claim 9 , wherein the WTRU is configured to receive the registration reject message from an access and mobility management function.

13. Prior to sending the first registration request, the WTRU: identifying a first set of hashed IDs and a first random number based on received system information, each ID in the first set of hashed IDs being individually hashed using at least the first random number; calculating a first hash value for each ID in a second set of IDs using at least the first random number; determining whether at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs; Based on a determination that at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs, calculating a second hash value for at least one ID associated with a hash ID of the second set of IDs that matches a hash ID of the first set of hash IDs using at least one second random number, wherein the first registration request is a message including information of the second random number and any of the IDs hashed by the second random number; The WTRU of claim 9 , further configured to:

14. The WTRU of claim 13 , wherein the second hash value is calculated using the second random number and a network-assigned wireless transmit / receive unit (WTRU) ID.

15. 14. The WTRU of claim 13, wherein the first set of hashed IDs includes one or more hashed CAG IDs and the second set of IDs includes one or more pre-configured allowed CAG IDs.

16. When executed by a computer, sending a first registration request to a network entity via a first Closed Access Group (CAG) cell, the first registration request indicating CAG capabilities; receiving a registration reject message having new CAG identifier (CAG ID) information; updating a CAG configuration using the new CAG ID information; selecting a second CAG cell based on the new CAG ID information; sending a second registration request to the network entity via the selected second CAG cell; A non-transitory computer-readable storage device having instructions that cause a computer to perform a method comprising:

17. 17. The apparatus of claim 16, wherein updating the CAG configuration includes deleting stored CAG ID information and adding the new CAG ID information.

18. 17. The apparatus of claim 16, wherein receiving a Registration Reject message with new CAG ID information includes receiving the Registration Reject message as integrity protected.

19. 17. The apparatus of claim 16, wherein receiving a registration reject message with new CAG ID information includes receiving the new CAG ID information from an access and mobility management function.

20. prior to sending the first registration request; identifying a first set of hashed IDs and a first random number based on received system information, each ID in the first set of hashed IDs being individually hashed using at least the first random number; calculating a first hash value for each ID in a second set of IDs using at least the first random number; determining whether at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs; 20. The apparatus of claim 16, further comprising:

Images