阅读说明：本技术 用于无线通信中的安全接入控制的方法和装置 (Method and apparatus for secure access control in wireless communications ) 是由 S·费尔迪 A·布鲁斯洛夫斯基 王冠宙 于 2020-03-27 设计创作，主要内容包括：公开了用于无线通信中的安全接入控制的方法和装置。在一个示例中,一种方法包括：接收包括系统信息的广播消息,基于系统信息,识别第一集合散列标识符(ID)和第一随机数,并且所述第一集合散列ID中的每个ID使用至少第一随机数来单独散列。该方法还包括：使用至少所述第一随机数来计算第二集合ID的每个ID的第一散列值,确定所述第二集合ID的至少一散列ID是否与所述第一集合散列ID的散列ID匹配,以及基于确定所述第二集合ID的至少一散列ID与所述第一集合散列ID的散列ID匹配来发送请求消息。(Methods and apparatus for secure access control in wireless communications are disclosed. In one example, a method comprises: a broadcast message including system information is received, a first set of hash Identifiers (IDs) and a first random number are identified based on the system information, and each of the first set of hash IDs is separately hashed using at least the first random number. The method further comprises the following steps: the method further includes calculating a first hash value of 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 determining that at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs.)

1. A method for wireless communication, comprising:

receiving a broadcast message including system information;

identifying, based on the system information, a first set of hash Identifiers (IDs) and first random numbers, wherein each ID of the first set of hash IDs is separately 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; and

sending a request message based on determining that at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs.

2. The method of claim 1, further comprising:

based on determining that at least one hash ID of the second set of IDs matches a hash ID of the first set of IDs, calculating a second hash value for the hash ID of the second set of IDs that matches the hash ID of the first set of IDs using at least a second random number.

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

4. The method of claim 3 wherein the WTRU ID assigned by the network is a cell radio network temporary identifier (C-RNTI).

5. The method of claim 2, wherein the request message is a Radio Resource Control (RRC) message, and wherein the RRC message includes any of: information of the second random number, and the ID hashed by at least the second random number.

6. The method of claim 1, wherein determining whether at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs comprises: comparing each hash ID of the second set of IDs to each hash ID of the first set of hash IDs.

7. The method of claim 1, wherein each ID in the first set of hashed IDs is hashed separately using the first random number and a cell ID.

8. The method of claim 1, wherein the first set of hashed IDs comprises one or more hashed Closed Access Group (CAG) IDs.

9. The method of claim 1, wherein the second set of IDs comprises one or more pre-configured allowed CAG IDs.

10. The method of claim 1, further comprising:

identifying a second random number based on the system information; and

calculating a second hash value for at least the ID associated with the hash ID of the second set of IDs that matches the hash ID of the first set of hash IDs using at least the second random number.

11. The method of claim 1, wherein the request message is a registration request message, and the method further comprises:

receiving a registration response message including a set of allowed CAG IDs; and

replacing the stored set of allowed CAG IDs with the set of allowed CAG IDs received in the registration response message.

12. The method of claim 11, wherein the registration response message is a registration accept message or a registration reject message.

13. A method implemented in a wireless transmit/receive unit (WTRU) for wireless communication, the method comprising:

receiving a first message comprising a temporary single network slice selection assistance information (T-S-NSSAI) set supported by a network and a wireless transmit/receive unit (WTRU) Identifier (ID) assigned by the network during a registration procedure;

after receiving the first message, calculating one or more hash values for the requested set of T-S-NSSAIs using the WTRU ID and a random number assigned by the network; and

transmitting a second message including at least the one or more hash values and the random number.

14. The method according to claim 13, wherein the requested set of T-S-NSSAIs includes one or more of the set of T-S-NSSAIs supported by the network.

15. The method of claim 13, wherein the first message is a registration accept message.

16. The method of claim 13, wherein the second message is a Radio Resource Control (RRC) message.

17. A wireless transmit/receive unit (WTRU), comprising:

a receiver configured to receive a broadcast message including system information;

a processor configured to:

identifying a first set of hash Identifiers (IDs) and first random numbers based on the system information, wherein each ID of the first set of hash IDs is separately 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; and

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

a transmitter configured to transmit a request message based on determining that at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs.

18. A wireless transmit/receive unit (WTRU) comprising a processor, a transceiver, and a memory that implement the method of any of claims 1-16.

Disclosure of Invention

Embodiments disclosed herein relate generally to methods and apparatus for secure access control in wireless communications, e.g., for secure access control of a next generation radio access network (NG-RAN) as part of a 5G New Radio (NR) system.

Drawings

A more particular understanding can be obtained from the following detailed description taken in conjunction with the accompanying drawings. Similar to the detailed description, the drawings in these figures are examples. Accordingly, the drawings and detailed description are not to be taken in a limiting sense, and other equivalent examples are possible and possible. Further, like reference numerals in the figures denote like elements, and wherein:

FIG. 1A is a system diagram of an exemplary communication system in which one or more disclosed embodiments may be implemented;

figure 1B is a system diagram of an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in figure 1A, according to an embodiment;

fig. 1C is a system diagram of an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A, according to an embodiment;

figure 1D is a system diagram of another exemplary RAN and another exemplary CN that may be used within the communication system shown in figure 1A, according to an embodiment;

fig. 2 is a signal flow diagram of an example of a registration process with Closed Access Group (CAG) access control in accordance with one or more embodiments;

figure 3 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;

fig. 4 is a signal flow diagram of an example of a registration procedure with Radio Resource Control (RRC) -based CAG access control in accordance with one or more embodiments;

fig. 5 is a signal flow diagram of an example of a registration process with non-access stratum (NAS) based CAG access control in accordance with one or more embodiments;

fig. 6 is a signal flow diagram of an example of a process of using hashed (hashed) temporary S-NSSAI (T-S-NSSAI) during Access Stratum (AS) connection establishment in accordance with one or more embodiments;

FIG. 7 is a signal flow diagram illustrating an example of a first CAG ID protection mechanism in accordance with one or more embodiments;

FIG. 8 is a signal flow diagram illustrating an example of a second CAG ID protection mechanism in accordance with one or more embodiments; and

fig. 9 is a signal flow diagram of an example of a handover procedure between CAG cells in accordance with one or more embodiments.

Detailed Description

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. It will be understood, however, that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the description below. Moreover, embodiments and examples not specifically described herein may be implemented in place of, or in combination with, embodiments and other examples that are described, disclosed, or otherwise explicitly, implicitly, and/or inherently (collectively, "provided") provided herein. Although various embodiments are described and/or claimed herein in which an apparatus, system, device, etc. and/or any element thereof performs an operation, a process, an algorithm, a function, etc. and/or any portion thereof, it should be appreciated that any embodiment described and/or claimed herein assumes that any apparatus, system, device, etc. and/or any element thereof is configured to perform any operation, process, algorithm, function, etc. and/or any portion thereof.

Representative communication network

The methods, apparatus and systems provided herein are well suited for communications involving both wired and wireless networks. Wired networks are well known. An overview of various types of wireless devices and infrastructures is provided in relation to fig. 1A-1D, wherein various elements of a network may utilize, execute, be arranged and/or adapted and/or configured in accordance with the methods, apparatuses and systems provided herein for the methods, apparatuses and systems provided herein.

Fig. 1A is a diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to a plurality of wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may use one or more channel access methods such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), orthogonal FDMA (ofdma), single carrier FDMA (SC-FDMA), zero-tail unique word DFT-spread OFDM (ztwdts-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), among others.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104/113, CNs 106/115, Public Switched Telephone Networks (PSTNs) 108, the internet 110, and other networks 112, although it should be appreciated that any number of WTRUs, base stations, networks, and/or network components are contemplated by the disclosed embodiments. The WTRUs 102a, 102b, 102c, 102d may each be any type of device configured to operate and/or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a "station" and/or a "STA," which may be configured to transmit and/or receive wireless signals, and may include a User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an internet of things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., tele-surgery), an industrial device and application (e.g., a robot and/or other wireless device operating in an industrial and/or automated processing chain environment), a consumer electronics device, a wireless transceiver, or a wireless device, or a wireless device, a wireless transceiver, a wireless device, or a wireless device, a wireless device, And devices operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as a WTRU.

The communication system 100 may also include a base station 114a and/or a base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., the CN106/115, the internet 110, and/or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102 d. For example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node B, e node bs, home e-nodes B, gNB, New Radio (NR) node bs, site controllers, Access Points (APs), and wireless routers, among others. Although each of the base stations 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network components.

The base station 114a may be part of the RAN 104/113, and the RAN may also include other base stations and/or network components (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, known as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area that is relatively fixed or may vary over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of a cell. In an embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of a cell. For example, using beamforming, signals may be transmitted and/or received in desired spatial directions.

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, millimeter-wave, Infrared (IR), Ultraviolet (UV), visible, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as described above, communication system 100 may be a multiple-access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a and the 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 use wideband cdma (wcdma) to establish the air interface 116. 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).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-Pro (LTE-a Pro).

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

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may collectively implement LTE radio access and NR radio access (e.g., using Dual Connectivity (DC) principles). As such, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., eNB and gNB).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (e.g., Wireless high fidelity (WiFi)), IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA 20001X, CDMA2000 EV-DO, interim standard 2000(IS-2000), interim standard 95(IS-95), interim standard 856(IS-856), Global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), and GSM EDGE (GERAN), among others.

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 facilitate wireless connectivity in a local area using any suitable RAT, such as a business, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by a drone), and a road, among others. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a Wireless Local Area Network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d may establish a Wireless Personal Area Network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish the pico cell or the femto cell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A, LTE-a Pro, NR, etc.). As shown in fig. 1A, the base station 114b may be directly connected to the internet 110. Thus, base station 114b need not access the internet 110 via CN 106/115.

The RAN 104/113 may communicate with a CN106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements, among others. CN106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, internet connectivity, video distribution, etc., and/or may perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RAN 104/113 and/or CN106/115 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113 using NR radio technology, the CN106/115 may communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.

The CN106/115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a system of globally interconnected computer network devices that utilize common communication protocols, such as transmission control protocol/internet protocol (TCP), User Datagram Protocol (UDP), and/or IP in the TCP/IP internet protocol suite. The network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104/113 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers that communicate 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 using a cellular-based radio technology and with a base station 114b, which may use an IEEE 802 radio technology.

Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive component 122, a speaker/microphone 124, a keypad 126, a display/touch pad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or peripherals 138. It should be appreciated that the WTRU 102 may include any subcombination of the foregoing components while maintaining consistent embodiments.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. 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 a transceiver 120 and the transceiver 120 may be coupled to a transmit/receive component 122. Although fig. 1B depicts processor 118 and transceiver 120 as separate components, it should be understood that processor 118 and transceiver 120 may be integrated together in an electronic component or chip.

The transmit/receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit/receive component 122 may be an antenna configured to transmit and/or receive RF signals. As an example, in another embodiment, the transmit/receive component 122 may be an emitter/detector configured to emit and/or receive IR, UV or visible light signals. In yet another embodiment, the transmit/receive component 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive component 122 may be configured to transmit and/or receive any combination of wireless signals.

Although transmit/receive component 122 is depicted in fig. 1B as a single component, WTRU 102 may include any number of transmit/receive components 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive components 122 (e.g., multiple antennas) that transmit and receive wireless signals over the air interface 116.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and to demodulate signals received by transmit/receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touch pad 128, such as 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. Further, processor 118 may access information from and store information in any suitable memory, such as non-removable memory 130 and/or removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and so forth. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located in the WTRU 102, such memory may be located, for example, in a server or a home computer (not shown).

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

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) related to the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information via any suitable positioning method while maintaining consistent embodiments.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and/or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, BluetoothModules, Frequency Modulation (FM) radio units, digital music players, media players, video game modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, and activity trackers, among others. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographic position sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor, among others.

The WTRU 102 may include a full duplex radio for which reception or transmission of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous. The full-duplex radio may include an interference management unit 139 that reduces and/or substantially eliminates self-interference via signal processing by hardware (e.g., a choke coil) or by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception)).

Figure 1C is a system diagram illustrating the RAN 104 and the CN106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using E-UTRA radio technology over the air interface 116. The RAN 104 may also communicate with a CN 106.

RAN 104 may include enodebs 160a, 160B, 160c, however, it should be appreciated that RAN 104 may include any number of enodebs while maintaining consistent embodiments. The enodebs 160a, 160B, 160c may each include one or more transceivers that communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enodebs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enodeb 160a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or to receive wireless signals from the WTRU 102 a.

The enodebs 160a, 160B, 160c may each be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and so forth. As shown in FIG. 1C, eNode Bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN106 shown in fig. 1C may include a Mobility Management Entity (MME)162, a Serving Gateway (SGW)164, and a Packet Data Network (PDN) gateway (or PGW) 166. While each of the foregoing components are described as being part of the CN106, it should be understood that any of these components may be owned and/or operated by an entity other than the CN operator.

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, performing bearer activation/deactivation processes, and selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, among other things. MME 162 may provide a control plane function for switching between RAN 104 and other RANs (not shown) that use other radio technologies (e.g., GSM and/or WCDMA).

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/from the WTRUs 102a, 102b, 102 c. The SGW 164 may also perform other functions such as anchoring the user plane during inter-eNB handovers, triggering paging processing when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

The SGW 164 may be connected to a PGW 146, which may provide packet-switched network (e.g., internet 110) access for the WTRUs 102a, 102b, 102c to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The CN106 may facilitate communications with other networks. For example, the CN106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), and the IP gateway may serve as an interface between the CN106 and the PSTN 108. In addition, the CN106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments, such a terminal may use a (e.g., temporary or permanent) wired communication interface with a communication network.

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

A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may access another type of wired/wireless network that is either interfaced to a Distribution System (DS) or that carries traffic into and/or out of the BSS. Traffic originating outside the BSS and destined for the STAs may arrive through the AP and be delivered to the STAs. Traffic originating from the STAs and destined for destinations outside the BSS may be sent to the AP for delivery to the respective destinations. Traffic between STAs that are inside the BSS may be transmitted through the AP, for example, in the case where the source STA may transmit traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and/or referred to as point-to-point traffic. The point-to-point traffic may be transmitted between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In certain representative embodiments, DLS may use 802.11e DLS or 802.11z channelized DLS (tdls)). For example, a WLAN using an Independent Bss (IBSS) mode has no AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "Ad-hoc" communication mode.

When using the 802.11ac infrastructure mode of operation or similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., 20MHz bandwidth) or a width that is dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some representative embodiments, implemented may be carrier sense multiple access with collision avoidance (CSMA/CA) (e.g., in 802.11 systems). For CSMA/CA, STAs (e.g., each STA) including the AP may sense the primary channel. A particular STA may back off if it senses/detects and/or determines that the primary channel is busy. In a given BSS, there is one STA (e.g., only one station) transmitting at any given time.

High Throughput (HT) STAs may communicate using 40MHz wide channels (e.g., 40MHz wide channels formed by combining a20 MHz wide primary channel with 20MHz wide adjacent or non-adjacent channels).

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels or by combining two discontinuous 80MHz channels (this combination may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, the data may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped on two 80MHz channels and data may be transmitted by STAs performing the transmissions. At the receiver of the STA performing the reception, the above-described operations for the 80+80 configuration may be reversed, and the combined data may be transmitted to the medium access control layer.

802.11af and 802.11ah support operating modes below 1 GHz. The use of channel operating bandwidths and carriers in 802.11af and 802.11ah is reduced compared to 802.11n and 802.11 ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. In accordance with a representative embodiment, 802.11ah may support meter type control/Machine Type Communication (MTC) (e.g., MTC devices in a macro coverage area). MTC devices may have certain capabilities, such as limited capabilities including supporting (e.g., supporting only) certain and/or limited bandwidth. The MTC device may include a battery, and the battery life of the battery is above a threshold (e.g., to maintain a long battery life).

For WLAN systems (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) that can support multiple channels and channel bandwidths, these systems contain channels that can be designated as primary channels. The bandwidth of the primary channel may be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA that is sourced from all STAs operating in the BSS supporting the minimum bandwidth operating mode. In an example for 802.11ah, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes, the width of the primary channel may be 1MHz for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy (e.g., because STAs (which support only 1MHz mode of operation) transmit to the AP), the entire available band may be considered busy even though most of the available band remains free and available for use.

In the united states, the available frequency band available for 802.11ah is 902MHz to 928 MHz. In korea, the available frequency band is 917.5MHz to 923.5 MHz. In Japan, the available frequency band is 916.5MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, in accordance with the country code.

Figure 1D is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c using NR radio technology over the air interface 116. RAN 113 may also communicate with CN 115.

RAN 113 may include gnbs 180a, 180b, 180c, but it should be appreciated that RAN 113 may include any number of gnbs while maintaining consistent embodiments. The gnbs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gnbs 180a, 180b, 180c may implement MIMO techniques. For example, the gnbs 180a, 180b may use beamforming processing to transmit and/or receive signals to and/or from the gnbs 180a, 180b, 180 c. Thus, for example, the gNB180a may use multiple antennas to transmit wireless signals to the WTRU 102a and to receive wireless signals from the WTRU 102 a. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In an embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive a cooperative transmission from gNB180a and gNB180 b (and/or gNB180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may be different 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) having different or scalable lengths (e.g., including different numbers of OFDM symbols and/or lasting different absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with WTRUs 102a, 102b, 102c in independent configurations and/or non-independent configurations. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c without accessing other RANs (e.g., enodebs 160a, 160B, 160 c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using signals in unlicensed frequency bands. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate/connect with the gnbs 180a, 180B, 180c while communicating/connecting with other RANs (e.g., enodebs 160a, 160B, 160 c). For example, the WTRUs 102a, 102B, 102c may communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c in a substantially simultaneous manner by implementing DC principles. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput to serve the WTRUs 102a, 102B, 102 c.

The gnbs 180a, 180b, 180c may each be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and/or DL, support network slicing, dual connectivity, implement interworking processing between NR and E-UTRA, route user plane data to User Plane Functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, among other things. As shown in fig. 1D, the gnbs 180a, 180b, 180c may communicate with each other over an Xn interface.

The CN 115 shown in fig. 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, 185 b. While each of the foregoing components are depicted as being part of the CN 115, it should be appreciated that any of these components may be owned and/or operated by an entity other than the CN operator.

The AMFs 182a, 182b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as control nodes. For example, the AMFs 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 specific SMFs 183a, 183b, managing registration areas, terminating NAS signaling, and mobility management, among others. The AMFs 182a, 182b may use network slicing to customize the CN support provided for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. As an example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced large-scale mobile broadband (eMBB) access, and/or services for Machine Type Communication (MTC) access, among others. The AMF 182 may provide control plane functionality for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (e.g., LTE-A, LTE-a Pro, and/or non-3 GPP access technologies such as WiFi).

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 UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b, and may configure traffic routing through the UPFs 184a, 184 b. The SMFs 183a, 183b may perform other functions such as managing and assigning WTRU (or UE) IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification, among others. The PDU session type may be IP-based, non-IP-based, and ethernet-based, among others.

The UPFs 184a, 184b may connect one or more of the gnbs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network (e.g., the internet 110) to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices, and the UPFs 184, 184b may perform other functions, such as routing and forwarding packets, implementing user-plane policies, supporting multi-homed PDU sessions, processing user-plane QoS, buffering downlink packets, providing mobility anchoring processing, and so forth.

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

In view of fig. 1A-1D and the corresponding description with respect to fig. 1A-1D, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-B, enode bs 160a-c, MME 162, SGW 164, PGW 166, gNB180 a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DN185a-B, and/or any other device(s) described herein. These emulation devices can be one or more devices configured to simulate one or more or all of the functions described herein. These emulation devices may be used, for example, to test other devices and/or to simulate network and/or WTRU functions.

The simulated device may be designed to conduct one or more tests with respect to other devices in a laboratory environment and/or in a carrier network environment. For example, the one or more simulated devices may perform one or more or all functions while implemented and/or deployed, in whole or in part, as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices can perform one or more or all functions while temporarily implemented/deployed as part of a wired and/or wireless communication network. The simulation device may be directly coupled to another device to perform testing and/or may perform testing using over-the-air wireless communication.

The one or more emulation devices can perform one or more functions, including all functions, while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test scenario of a test laboratory and/or a wired and/or wireless communication network that is not deployed (e.g., tested) in order to conduct testing with respect to one or more components. The one or more simulation devices may be test devices. The simulation device may transmit and/or receive data using direct RF coupling and/or wireless communication via RF circuitry (e.g., the circuitry may include one or more antennas).

One or more embodiments disclosed herein relate to methods and apparatus for a non-public network (NPN) integrated with a Public Land Mobile Network (PLMN). In various embodiments, a NPN (e.g., a NPN integrated with a PLMN) may use one or more Closed Access Group (CAG) for identification, cell selection, and/or Access control. In various embodiments, it is contemplated that other types of NPNs are equally possible using one or more of the processes, mechanisms, or embodiments discussed herein. For example, a standalone NPN (snpn) may use a set/list of NPN ID(s) for identification, cell selection, and/or access control, and may use one or more of the processes, mechanisms, or embodiments disclosed herein.

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

Representative procedures for PLMN Integrated NPN Access

In some embodiments (e.g., in 3 GPP), NPN is supported or deployed. NPN can be deployed or implemented using a Closed Access Group (CAG) and/or network slice in support of one or more PLMNs, and in some examples, this type of NPN can be referred to as a PLMN-integrated NPN. In some cases, the PLMN integrated NPN may be part of a non-standalone (NSA) communication network or implemented as one or more NSA communication networks. In some cases, the NPN may be implemented as a stand-alone NPN (snpn). In one example, the SNPN may be a private network that does not rely on network functions of the public PLMN.

In various embodiments, CAG may be used to enable the network to prevent the WTRU from attempting to access the network slice. In one example, the network slice may be dedicated to the NPN, and the NPN may be located in an area where the WTRU is not allowed to use the network slice.

Referring to fig. 2, an example of a process 200 for network and cell selection and access control is provided. In this example, the WTRU may compare the allowed CAG (allowed CAG) list from the WTRU's local configuration to a set of CAG IDs that are broadcast as clear text by the CAG cell before attempting to access the CAG cell (e.g., operations 0-2 shown in fig. 2). The WTRU may use a subscription hidden identifier (sui) of or associated with the WTRU for the registration procedure if the WTRU finds at least a matching CAG ID. For example, the WTRU may send a registration request (e.g., with sui) message to the NG-RAN and/or an access and mobility management function (AMF). In various embodiments, the WTRU may select a matching CAG ID and may include the selected CAG ID in RRC layer signaling (e.g., in a UL RRC message). The WTRU may undergo full primary authentication so that the AMF may 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 or matches the cell supported CAG ID(s) and/or the CAG ID(s) selected by the WTRU. For example, the AMF may determine or verify whether the at least one CAG ID from the WTRU subscription corresponds to or matches any CAG ID(s) (e.g., selected one or more CAG IDs) forwarded by the NG-RAN in the N2 message (e.g., operations 4 and 7 as shown in fig. 2). In the case where the AMF finds a matching CAG ID, the WTRU may be allowed to access the CAG cell, e.g., registration is accepted. In one example, the registration may be accepted via a registration accept message sent from the AMF to the WTRU. In the case where the AMF does not find a matching CAG ID, the WTRU may not be allowed to access the CAG, e.g., registration is denied. In one example, the registration may be rejected via a registration reject message sent from the AMF to the WTRU.

In various embodiments, the SNPN(s) identification(s), cell selection(s), and/or access control may follow operations similar to those described above for the NPN with integrated PLMN (e.g., the process shown in fig. 2). The SNPN may be identified by a unique NPN ID. The cell providing access to the SNPN(s) may broadcast a set or list of NPN IDs of these SNPNs in clear text. When the WTRU discovers subscriber identifiers and/or certificates corresponding to the broadcasted set or list of 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 user identifiers in the form of Network Access Identifiers (NAIs), where the realm part may include NPN IDs. With respect to the PLMN integrated NPN, the WTRU may need to undergo full primary authentication before the network can determine whether to allow the WTRU access.

In various embodiments, CAG cell access may be reserved exclusively for one or more WTRUs supporting CAG. In one example, the cells discussed herein may be conventional PLMN cells or CAG cells. In some cases, emergency services may be supported in a CAG cell.

In various embodiments, the PLMN integrated NPN may be referred to as an NSA communication network, an NSA NPN, or a public network integrated NPN, and these terms referring to the PLMN integrated NPN may be interchangeable.

Representative procedures for security and/or privacy for NPN access integrated with PLMN

In various embodiments, security aspects of vertical services and/or NPN access integrated with PLMNs are discussed. For example, some aspects relate to potential (distributed) denial of service ((D) DOS) attacks in PLMN integrated NPN that may be made to a 5G system when a large number of malicious WTRUs attempt to register with a network (e.g., a CAG cell) and one or more of the WTRUs may not be allowed to access the network (e.g., a CAG cell). Potential security requirements may be implemented to mitigate such (D) DoS attacks on the NPN integrated PLMN (caused by registration requests from WTRUs not allowed to access CAG cells).

In various embodiments, the WTRU may include the CAG ID as plain text in the initial NAS registration request message. The AMF may send an authentication request to a home plmn (hplmn), the authentication request including a CAG ID provided by the WTRU. Upon receiving the request, the UDM may determine or verify that the provided CAG ID matches the CAG ID from the WTRU subscription data. For example, the UDM may determine (or verify) whether the provided CAG ID matches a CAG ID from WTRU subscription data after de-hiding (de-concealing) the sui into a valid subscription permanent identifier (SUPI). In one example, if no match is found, the UDM may reject the authentication request and the AMF may reject the WTRU registration.

Representative methods Using a cryptographic hash function and salt (salt)

In various embodiments, for example, cryptographic hash functions (e.g., SHA-3, PBKDF2, BCRYPT) are referred to as one-way functions (cannot be restored). For example, a cryptographic salt may be referred to as random non-secret data, which is used by a hash function as an additional parameter to defend against (e.g., pre-computed) dictionary attacks by randomizing (e.g., effectively randomizing) the output of the hash function. In various embodiments, a cryptographic hash function and/or a cryptographic salt may be used to protect a password as a randomized hash string, for example, in storage or transmission.

In an example, a user reusing the same password across different services may have different hashed passwords (e.g., in storage) at the services, assuming the services are using different random salts. In another example, two users using the same or a common password in the context of the same service may have different hashed passwords (e.g., in storage), assuming that the service uses a different random salt for each user.

Representative procedure Using Diffie-Hellman Key Agreement

In various embodiments, the shared secret derived using any of 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. The session key may be used to encrypt or integrity protect subsequent communications using symmetric key cryptography.

The DH protocol provides a key exchange that may be used to allow two parties (e.g., a WTRU and a gNB) that are not known to each other in advance to jointly establish a shared secret key over an insecure channel. The ECDH protocol (a variant of the DH protocol) uses elliptic curve cryptography. ECDH is an anonymous key agreement protocol that allows two parties to establish a shared secret over an insecure channel, where each party has a public-private parameter pair of an elliptic curve.

Representative procedure Using an encryption scheme (ECIES) integrating elliptic curves

In various embodiments, ECIES may refer to an integrated encryption scheme that uses multiple cryptographic functions: a key agreement function, a key derivation function, a symmetric encryption mechanism/function, and/or a Message Authentication Code (MAC) function. ECIES combines a key encapsulation mechanism with a data encapsulation mechanism. Systems using ECIES may derive encryption keys and MAC keys independently from a common secret. ECIES has been standardized in, for example, ANSI X9.63, IEEE1363a, ISO/IEC 18033-2, and SECG SEC-1.

ECIES has been specified for the 5G security architecture as a standard mechanism for SUPI privacy protection. For example, using ECIES, the WTRU is able to protect the confidentiality/integrity of the SUPI by using a derived symmetric ciphering key and/or MAC key obtained by running a key derivation function that follows a key agreement function using a public key pre-provisioned by the home network and a generated ephemeral public/private key pair.

Representative procedure for CAG access control for NPN access integrated with PLMN- (distributed) denial of service ((D) DOS)

In various embodiments, WTRUs (e.g., NPN WTRUs) and networks supporting CAG access control for NPN access integrated with PLMNs may mitigate or reduce the risk of (distributed) denial of service ((D) DOS) attacks on CAG cells, networks, UDMs, and/or Subscription Identifier Decondensation Functions (SIDFs).

Referring to fig. 2, when a WTRU initially accesses a CAG cell, the network (e.g., AMF) may check (or have to check) the CAG ID(s) supported by the cell provided by the gNB (and/or selected by the WTRU) against a list of CAG IDs from WTRU subscription information before allowing access. The WTRU may or must perform a complete master authentication run/check with the network. Such a process may first use or require UDM/SIDF to un-conceal the SUCI so that the AMF can obtain SUPI to retrieve CAG related subscription information. Such privacy enhancements (e.g., privacy enhancements) may increase the processing load in the home network because the UDM/SIDF needs to perform public key operations (e.g., SUPI de-concealment at the SIDF). The AUSF may be referred to as an authentication server function and the VPLMN may be referred to as a visited PLMN.

In one example, an attacker may attempt to flood the network with registration requests through one or more CAG cells, forcing the UDM/SIDF to handle many forged or fake suis while consuming radio resources in the CAG cell(s), causing a (D) DOS attack on the network (e.g., UDM/SIDF). In another example, a group of legitimate or genuine WTRUs may create a registration request storm while not being allowed to join a CAG cell (e.g., a particular caged-enabled cell). In SNPN(s), a large number of WTRUs that are not allowed to access the SNPN cell may attempt to register with the SNPN cell, in which case a similar risk of DoS attacks may be encountered.

In various embodiments, with respect to (D) DOS mitigation or reduction, during the identification phase, the WTRU and/or the network may reduce the window of opportunity for (D) DOS attacks by verifying the validity of the CAG ID before the primary authentication occurs (e.g., during identification or verification of the WTRU identity by the UDM). Since the UDM may need or may un-hide the SUCI, the threat of a potential (D) DOS attack on the UDM may be addressed. For example, the processing load of the UDM may increase compared to the process in fig. 2, because the UDM may or must perform CAG ID verification as part of the identification process.

In some implementations, the CAG ID(s) expected to be supported by the cell from the gNB may not be included in the authentication message (e.g., the authentication message sent by the AMF to the UDM). In one example, the UDM may check (e.g., only check) that the CAG ID provided by the WTRU is part of the WTRU subscription and may not check whether the WTRU is allowed to access the CAG cell. In some cases, the WTRU (which supports CAG) may be allowed to access any CAG cell, breaking the access control envisioned by the procedure in fig. 2.

Representative procedure for CAG access control for NPN access integrated with PLMN-privacy of NPN and/or WTRU

In various embodiments, a WTRU (e.g., an NPN WTRU or UE) and a network supporting CAG access control for NPN access integrated with a PLMN may maintain privacy of the NPN served by the CAG cell and/or the NPN WTRU allowed to access the CAG cell(s).

In various embodiments, Network Slice Selection Assistance Information (NSSAI) or a set of individual NSSAIs (S-NSSAIs) may be considered private information (e.g., in a 5G NR). For example, enhancements may be implemented to enable NSSAI to be protected in the Access Stratum (AS) (e.g., RRC) layer and/or the NAS layer during the initial registration procedure. In one example, a CAG ID assigned to a network slice dedicated to a particular NPN may reveal not only information related to a particular S-NSSAI, but also to a particular enterprise that has allocated or has allocated a CAG cell and/or network slice. For example, the CAG ID may be considered private information.

In various embodiments (e.g., the process in fig. 2), NPN and/or WTRU privacy is implemented. In one example, a CAG cell may broadcast the set or list of supported CAG IDs (e.g., supporting a total of twelve CAG IDs). In some cases, broadcasting the set or list of supported CAG IDs may be a privacy risk. For example, an attacker may identify and/or map a particular cell(s) serving a particular NPN based on the CAG ID(s) broadcast in clear text. The attacker can use this information to target and/or disrupt the operation of the NPN (e.g., using the (D) DOS attack discussed above). In the case of SNPN(s), where a set/list of one or more NPN IDs are broadcast in clear text by the cells providing access to these SNPN(s), similar privacy risks may be encountered.

In one example, an attacker can track users of the NPN and/or NPN slice(s) by eavesdropping on the communication exchanges on certain cells. For example, by detecting that a particular WTRU is allowed to access the CAG cell (e.g., by eavesdropping on the registration accept message (s)), an attacker can link the user to one of the NPN or NPN slices served by the CAG cell and link the privacy-protected temporary identities (e.g., SUCI (s)) of multiple WTRUs. In some cases, the attacker may even more specifically track the user, as the WTRU may send the (e.g., selected) CAG ID in the clear in the initial registration message, revealing accurate information about the particular NPN slice that the WTRU wants to access, and providing the attacker with information for identifying the link and/or traffic analysis attack.

In another example, an attacker may obtain clear text one or more cell support CAG IDs from broadcasted system information, and the attacker may request and obtain access to the cell by including one of the cell support CAG IDs in one or more RRC messages. In this case, the legacy access control procedure performed by the network (e.g., the gNB) using the CAG ID transmitted by the WTRU may be ineffective for the attack. For example, conventional access control procedures present a vulnerability that an attacker can exploit to make an attack (e.g., a (D) DOS attack as described above).

Representative procedures for WTRU configuration when moving to a new CAG cell

In some examples, the WTRU configuration (e.g., NSSAI allowed) may be incorrect when moving to a new CAG cell. For example, when a WTRU accessing an NPN integrated with a PLMN is served by a particular PLMN network slice, the WTRU may be in a CAG cell from which the WTRU is allowed to access the network slice. In this example, the WTRU's allowed NSSAI configuration may include the network slice when the WTRU moves to the corresponding CAG cell.

In one example, the WTRU's allowed CAG list may contain 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 on and/or access the corresponding NPN. Referring to fig. 3, for example, as shown in the wireless communication network 300, a WTRU (e.g., WTRU 102) may have a configured allowed CAG list that may contain or include any number of CAG IDs (e.g., "CAG-1", "CAG-2"). The WTRU may move from a CAG cell of "CAG-1" to a CAG cell of "CAG-2". When the WTRU is in a CAG-1 cell, the WTRU may have received an allowed NSSAI configuration with an S-NSSAI (e.g., S-NSSAI-1) that may already 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 a CM-IDLE (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.

In one example, if a user attempts to initiate a service (e.g., send a request) to an NPN associated with CAG-2, for example, to trigger establishment and/or reactivation of a PDU session to an 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 PDU session establishment or reactivation towards S-NSSAI-1, which may be related to CAG-1 but will 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.

Representative procedure for synchronizing WTRU CAG ID configuration(s) after CAG ID subscription update

In some examples, when a WTRU is configured with a single allowed CAG ID, a CAG ID misconfiguration problem may occur in the event that the UE cannot access the network (or cannot access the network anymore). For example, a WTRU may be configured with a single allowed CAG ID (CAG ID _ a), and the WTRU may be configured with and/or receive an indication that the WTRU is only able to access the network through the CAG cell(s). In some cases, the AMF may receive updated subscription data when the WTRU has registered with the network, where no CAG ID _ a exists (e.g., CAG ID _ a may have been replaced by CAG ID _ B). In this case, the AMF may send a registration reject message with the appropriate cause, and the WTRU may remove the CAG ID _ a from its allowed CAG ID list. Therefore, the WTRU does not have an allowed CAG ID in its list of allowed CAG IDs, and the WTRU can only access the network through the CAG cell, and thus the WTRU cannot access the network.

Representative procedures for mitigating DoS attacks on CAG cell(s) and network using RRC signaling

Referring to fig. 4, a representative process 400 can be used to mitigate or reduce (D) DoS attacks on the CAG cell(s) and/or one or more networks (e.g., UDM/SIDF for NPN integrated PLMNs) using AS or RRC signaling. In various embodiments, a WTRU (e.g., WTRU 102) may compare the hash value of its locally configured CAG ID(s) to the hash value of the CAG ID(s) broadcast by the CAG cell to find one or more matching CAG IDs. The WTRU may register with the network and/or cell while providing one or more new hash values matching the CAG ID in the RRC layer. The WTRU may be allowed to access the CAG cell (and/or the NPN slice) if the following conditions are met: i) at least one WTRU-provided hashed CAG ID matches one or more hashed CAG IDs supported by the CAG cell, and/or the WTRU-provided hashed CAG ID matches one or more hashed CAG IDs supported by the CAG cell; or ii) according to policy (e.g., emergency access using a default DN/slice). In some embodiments, the WTRU may be denied access to the CAG cell (and/or NPN slice). In one example, the process may include any of the following.

In various embodiments, the WTRU may be configured with a list of allowed CAGs from the HPLMN, for example, in operation 0. The gNB may be configured with supporting CAG ID(s). This provisioning may be done out-of-band and/or at any time prior to operation 1.

Operation 1. a WTRU may read one or more CAG Identifiers (IDs) from CAG CELL broadcast system information (e.g., SIB1), wherein the CAG identifiers are individually hashed using a random number (e.g., a quasi-random number, a pseudo-random number, RAND CELL) as a basis for SALT (e.g., SALT CELL). For example, the SALT may combine RAND CELL and the current CELL ID (e.g., SALT CELL or RAND CELL ID) to bind the resulting hash value to the unique CELL ID. The cell id may be included in the broadcast system information. The 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 common CAG ID(s) (e.g., serving the same NPN slice (s)) may broadcast an entirely different hashed CAG ID(s). By randomizing the broadcasted CAGID(s), an eavesdropper cannot link any two CAG cells to each other based on hashed CAG ID information alone. Whenever the configured support CAG ID(s) is updated for a given CAG CELL, a new RAND CELL may be generated and used to generate a new hash value for the new support CAG ID(s) to be broadcast. It should be understood that, to avoid repetition herein, the term "pseudo-random number" may be used interchangeably and/or with the term "pseudo-random number".

Operation 2. the WTRU may compute a hash for each of the CAG IDs in its locally configured allowed CAG list using SALT _ CELL (e.g., refer to operation 0).

Operation 3. before sending the initial registration request, the WTRU may compare the locally generated hashed CAG ID to the hashed CAG IDs broadcast by the CAG cells and may determine whether there is at least one matching hashed CAG ID.

Operation 4. the WTRU may calculate a new hash for each of the configured allowed CAG IDs that match the cell broadcast hashed CAG IDs using the newly generated random value (RAND _ UE) as a basis for the SALT (SALT _ UE). For example, the WTRU may 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(s) to the specific RRC connection and transmission resources allocated by the gNB for the WTRU. RAND _ UE may increase freshness to prevent replay attacks. RAND _ UE may be supplemented by including a timestamp parameter for CAG ID replay protection(s). Including the C-RNTI as a component of the WTRU salt may enable the gNB to detect malicious WTRUs (e.g., based on differences in cell and WTRU salt formats) attempting to replay the broadcasted CAG cell CAG ID and cell salt. In one example, RAND _ UE may bind to RAND _ CELL (e.g., concatenated, XOR) and/or CELL Id to construct SALT (SALT _ UE), e.g., hashed CAG Id(s) transmitted by the WTRU may bind to the particular CELL broadcasting the CAG Id. This may enable the gNB to detect a malicious WTRU attempting to replay another WTRU hashed CAG ID(s) transmitted on a different cell.

Operation 5. the WTRU may send a registration request including a SALT _ UE and a separate hashed CAG ID matching a cell broadcast CAG ID in an Access Stratum (AS) layer (e.g., in a RRCSetupComplete message).

Operation 6. the gNB may compute a hash using each CAG ID in the list of CAG IDs for which the SALT _ UE is configured.

Operation 7. the gNB may check that there is at least one match between the WTRU provided hashed CAG ID(s) and the computed hashed CAG ID(s) (e.g., in operation 6).

Operation 8. the gNB may decide (e.g., based on operator policy and/or depending on local regulations):

operation 8a. if no matching hashed CAG ID is found, then the RRC connection is immediately discarded; or

Operation 8b. if such matching hashed CAG ID(s) are found, a message is sent to the AMF, e.g., over the N2 interface, including a) cell supported CAG ID(s), b) an indication as to whether the WTRU has at least one CAG ID matching the CAG ID(s) of the cell, and c) a NAS registration request message from the WTRU.

The gNB may determine that WTRUs that do not have a matching CAG ID (e.g., the WTRU does not provide any CAG ID) may be in a limited service state and/or may attempt registration for emergency services only. For example, the gNB may perform "emergency registration" by setting the RRC establishment cause to emergency. According to local regulations and/or operator policies, the gNB may decide to send an N2 message to the AMF for further access control checks.

Operation 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.

Operation 10a. if the indication from the gNB indicates that no matching CAG ID was found and/or if non-NPN access is not allowed (e.g., registration for emergency services is not allowed on the CAG cell) based on operator policy/local rules, the AMF may send a registration reject message to the WTRU (subsequently releasing any AS or NAS connection); or

Operation 10b. if the indication from the gNB indicates that at least one matching CAG ID is found, the network and WTRU may continue the remainder of the registration procedure (e.g., as shown in fig. 2, operations 5-8); or

Operation 10c. if the indication from the gNB does not find a matching CAG ID, and/or non-NPN access is allowed (e.g., the WTRU is allowed to make an emergency call) based on the operator's policy/local rules, the network and the WTRU may continue the emergency registration procedure or the exception handling procedure according to the operator's policy/local rules.

In various embodiments, representative procedures (e.g., including one or more alternative call/signal flow operations AS compared to fig. 4) may be used to mitigate or reduce (D) DoS attacks on the CAG cell(s) and/or network (e.g., UDM/SIDF for NPN integrated PLMN) using AS or RRC signaling. Such representative processes may include any of the following:

operations 0 to 1: the gNB may broadcast a random number (e.g., a quasi-random number, RAND CELL), and may hash the CELL supporting CAG ID using a salt based on RAND CELL. The gNB may broadcast another random number (e.g., RAND _ UE) that the WTRU will use to hash its matching allowed CAG ID(s) when the WTRU attempts to access the network. The RAND _ UE may be assigned a limited lifetime that is short enough to reduce the likelihood of WTRU hash CAG ID replay attacks and long enough to allow legitimate RRC connection completion (e.g., as multiple RRC connection timers, T300 and/or T352)

Operation 2-4: as discussed above in fig. 4, the WTRU may select a CAG CELL based on a matching of hashed CAG IDs (e.g., using a salt based on RAND CELL). For example, the WTRU may use the salt value based on RAND CELL to calculate a hash value of its CAG ID(s). The WTRU may check if there are one or more matching hashed CAG IDs.

Operation 5: the WTRU may register with the network. In one example, the WTRU may use the RAND _ UE based salt to calculate a hash value of the matching CAG ID(s) in its allowed CAG ID list. The WTRU may construct a salt (e.g., salt-RAND _ UE XOR C-RNTI) by combining the RAND _ UE with the C-RNTI. The WTRU may send the CAG ID(s) hashed using the salt based on RAND _ UE in a message (e.g., a RRCSetupComplete message). The WTRU may include a RAND _ UE in the message. As discussed above in fig. 4, the WTRU may combine the RAND CELL and/or CELL Id with the RAND UE/C-RNTI to construct a salt to enable binding of the generated hashed CAG Id(s) with the WTRU and the CELL.

Runs 6-8 a: the gNB may verify that the WTRU is allowed to access the CAG cell based on a match of the hashed CAG ID(s) (e.g., using a salt based on RAND _ UE). In one example, if the received RAND _ UE is included in an RRC message, the gNB may check that the received RAND _ UE is valid. If the RAND _ UE is invalid (e.g., expired), the gNB may drop the RRC connection. If the RAND _ UE is not included in the RRC message, the currently broadcasted RAND _ UE may be used. In one example, the gNB may calculate a hash value of its configured CAG Id(s) using RAND _ UE based salt (e.g., RAND _ UE XOR C-RNTI, and/or combined with RAND _ CELL/CELL Id) and may check that there is at least one match with the WTRU-provided hashed CAG Id(s).

Operations 8b-10 (which may include operations 10a, 10b, or 10 c): the same procedure as described above in fig. 4.

Representative procedures for using non-access stratum (NAS) signaling, e.g., to mitigate (D) DOS attacks on CAG cells and/or networks

Referring to fig. 5, a representative process 500 can be used, for example, to mitigate or reduce (D) DoS attacks on the CAG cell(s) and/or the network (e.g., UDM/SIDF for NPN integrated PLMN) using NAS signaling. In various embodiments, a WTRU using the representative procedure may send and/or receive hashed CAG ID(s) in the NAS layer, and the CAG ID(s) verification may be performed by, for example, a network entity (e.g., AMF), as compared to procedures using RRC layer signaling. In various embodiments, in contrast to the process in fig. 2, the gNB may broadcast a hashed CAG ID. The process may include any of the following:

operation 0. the WTRU may be configured with a list of allowed CAGs from the HPLMN. The gNB may be configured with a set and/or list of supported CAG IDs. Such configuration or provisioning operations may be implemented out-of-band and/or at any time prior to operation 1.

Operation 1. as described above in fig. 4, the gNB may broadcast a hash value of the supported CAG IDs and one or more random numbers (e.g., quasi-random numbers, RAND CELL, and/or RAND UE). The WTRU may select a CAG CELL based on a matching of the hashed CAG IDs (e.g., using a salt based on RAND CELL).

Operation 2. the WTRU may register with the network. As described above, the WTRU may use the RAND _ UE based salt to calculate a hash value for its matching CAG ID(s). The WTRU may send the CAGID(s) using a salt hash based on RAND _ UE in the NAS registration request message. The WTRU may include the salt (e.g., with a timestamp-based component for replay detection of the AMF) in a NAS message.

Operation 3. the gNB may send a message to the AMF over the N2 interface that includes i) cell supported CAG ID(s), ii) salt (e.g., current RAND _ UE XOR C-RNTI) for/required to verify the WTRU-provided hashed CAGID, and/or iii) a NAS registration request message from the WTRU.

Operation 4. the AMF may calculate a hash value of the cell supported CAG ID(s) using the salt provided by the gNB (e.g., and/or using the salt provided by the WTRU).

Operation 5. the AMF may check that there is at least one match between the cell supported CAG ID(s) and the WTRU provided hashed CAG ID(s).

Operation 6. if a match is found, the AMF may continue the conventional registration process. If no match is found, the registration may be rejected. In one example, if the registration request is for emergency registration, the AMF may allow the WTRU to access the network for emergency service, e.g., based on one or more operator policies and/or one or more local regulations.

Representative procedures for protecting NPN confidentiality and/or NPN user privacy

In various embodiments, to protect CAG ID privacy, mechanisms may be implemented, for example, using one or more of the previously described procedures. In various embodiments, the mechanism may be based on an exchange of randomized CAG IDs between or among WTRUs, gnbs, and/or AMFs (e.g., using a hash function with a random salt). Privacy considerations may depend on local regulations. The network can control whether a randomized CAG ID based access is active in the cell. The PLMN and/or NPN operator may provide the WTRU with appropriate guidance (e.g., by provisioning or otherwise) as to whether CAG cell selection is allowed without enabling CAG ID randomization.

In various embodiments, the CAG cell may broadcast an indication that the broadcasted CAG ID(s) are randomized to inform CAG enabled WTRUs to: whether the cell supports randomized CAG ID based access. In certain embodiments, the presence of hashed random number(s) (e.g., quasi-random numbers) (e.g., RAND _ CELL, RAND _ UE) as described above may inform a CAG-enabled WTRU to: the cell has enabled access based on randomized CAG IDs.

In various embodiments, a CAG cell may broadcast a randomized CAG ID(s) for cell selection and an indication of whether a WTRU may send (match) the randomized CAG ID for CAG cell access control. If the indication instructs the WTRU to send the hashed CAG ID(s) during registration, the WTRU may perform a procedure to register with the network (e.g., the procedures shown in fig. 4 and/or fig. 5). If the indication instructs the WTRU not to send hashed CAG ID(s) during registration, the WTRU may perform a procedure (e.g., the procedure shown in fig. 2) that may include randomized CAG ID(s) that may only be broadcast for cell (re) selection procedures and may not be transmitted (e.g., by the WTRU) for access control operations.

In various embodiments, a CAG cell may broadcast a mixture of randomized (e.g., with associated random number (s)) and non-randomized CAG IDs. In one example, a CAG enabled WTRU may select a cell using a cell selection process or procedure (e.g., procedure 400 shown in fig. 4, or procedure 500 in fig. 5) and/or matching a clear text CAG ID(s) as shown in fig. 2 after matching a hashed CAG ID. The WTRU may register with the network according to the procedure shown in fig. 2 (e.g., without transmitting any CAG ID in RRC or registration message). In some exemplary embodiments, the WTRU may register according to the process 400 shown in fig. 4 or the process 500 in fig. 5. In one example, for the case where the CAG ID is broadcast as a hash value or in the clear (e.g., the procedures shown in fig. 4 and/or fig. 5), the WTRU may transmit all matching CAG IDs as hash values.

In various embodiments, a WTRU (e.g., WTRU 102) supporting randomized CAG ID based access may be configured by the HPLMN with a CAG access "privacy mode" that may indicate whether the WTRU allows selection of a cell for which randomized CAG ID not enabled access. The default value for the privacy mode may be configured to instruct (or instruct) the WTRU to select only cells that enable randomized CAG ID based access. The WTRU may be configured by the serving PLMN/HPLMN after successful registration in different modes (e.g., to allow selection of cells 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 basis). If the privacy mode is set to "off," the WTRU may be allowed to select a CAG cell that does not enable randomized CAG ID based access. For example, the process 200 shown in fig. 2 may be performed to register with a network. If the privacy mode is set to "on," the WTRU may be allowed to select only CAG cells that enable randomized CAG ID based access. One or more processes (e.g., process 400 shown in fig. 4 or process 500 in fig. 5) may be performed to register with the network.

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 the CAG ID being associated with a particular S-NSSAI assigned for the NPN). In some examples, access layer connection establishment NSSAI inclusion mode (re-) use may be implemented, for example to enable CAG access privacy mode while ensuring consistent enforcement of network slice privacy policies. In some cases, with NSSAI including mode "a", the WTRU may include NSSAI in the AS layer during AS connection establishment, and with NSSAI including mode "d", the WTRU may not include (e.g., never include) NSSAI in the AS layer during AS connection establishment. For example, a CAG-capable WTRU may be allowed to select a CAG cell that disables randomized CAG ID based access when the NSSAI inclusion mode is set to mode "a", and may select only a CAG cell that enables randomized CAG ID based access when the NSSAI inclusion mode is set to mode "d".

NSSAI sent during AS connection establishment (e.g., in the RRC layer) may be randomized using hash-based operations (e.g., similar to the hash-based mechanism set forth herein for CAG ID (s)). For example, the WTRU may use the random number provided by the cell broadcast AS a basis for a salt for separately hashing the requested S-NSSAI sent during AS connection establishment (e.g., in 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 specified serving AMF. If no match is found, the gNB may forward the request to the default AMF.

In various embodiments, a hash-based mechanism may be used to broadcast an S-NSSAI that is randomized for a given cell or for a given gNB support. When the WTRU detects a change in supported S-NSSAI (e.g., S-NSSAI that does not support connectivity in the target cell) while moving (e.g., in a CM-IDLE state) to another cell, the WTRU may use this information to assist the cell selection procedure or trigger a registration update to synchronize its allowed NSSAI with the network.

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

In various embodiments, this mechanism/procedure may work with one or more of the mechanisms/procedures discussed above, for example, when assigning a T-S-NSSAI to each WTRU and/or S-NSSAI, providing protection against WTRU link capability attacks. In one example, referring to fig. 6, the WTRU may transmit one or more hash values of the requested T-S-NSSAI (instead of the plaintext T-S-NSSAI) in the AS layer during AS connection establishment. The one or more T-S-NSSAI hash values may be determined and/or calculated using the S-TMSI, forcing a change in T-S-NSSAI hash and mitigating WTRU link capability attacks each time the S-TMSI changes. The NG-RAN may identify the WTRU-requested slice (S) by matching the WTRU-requested hashed T-S-NSSAI with the hashed value of the T-S-NSSAI provided by the core network (e.g., 5G core (5 GC)). The representative mechanism/process 600 may include any of the following:

operation 1-2.NG-RAN may obtain a list of supported T-S-NSSAIs from AMF (e.g., a list of supported T-S-NSSAIs in addition to or instead of S-NSSAIs).

Operation 3. the WTRU may perform an initial registration procedure with the network. For example, the WTRU may obtain a list of allowed T-S-NSSAIs (one or more) in a registration accept message, which may be protected by NAS security, for example.

Operation 4. the WTRU may use its S-TMSI to determine and/or calculate the requested T-S-NSSAI hash value. The WTRU may transmit the T-S-NSSAI hash value in an RRC message (e.g., an RRCConnectionSetupComplete message). The WTRU may include an indication of a nature or type IE of the slicing assistance information (e.g., hashed T-S-NSSAI) to assist the NG-RAN in distinguishing between a first WTRU that is capable of NSSAI privacy protection and a second WTRU that is not capable of NSSAI privacy protection (e.g., so that the second WTRU may transmit S-NSSAI as plaintext).

In various embodiments, the WTRU may automatically transmit a fresh T-S-NSSAI hash value during AS connection establishment after a new S-TMSI has been allocated in accordance with or using one or more of the procedures discussed herein (or any existing procedure).

In various embodiments, two WTRUs requesting the same T-S-NSSAI may transmit different T-S-NSSAI hash values using the S-TMSI, e.g., to mitigate WTRU link capability attacks using the same T-S-NSSAI hash value. In some cases, the likelihood that the same S-TMSI will eventually be reassigned to a new WTRU requesting/using the same slice over time may be negligible for link capability attacks.

Operation 5. the NG-RAN may use the S-TMSI to compute a hash for each of the supported T-S-NSSAIs (S) received from the AMF. The NG-RAN may select an appropriate AMF based on a match of the received T-S-NSSAI and the supported hashed T-S-NSSAI.

Operation 6. the NG-RAN may route the WTRU initial NAS message to the selected AMF.

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

In various embodiments, it should be understood that this randomization and security mechanism/procedure shown herein for 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).

Representative procedure for protecting NPN confidentiality and/or NPN user privacy using Diffie-Hellman based key agreement protocol

In various embodiments, mechanisms, methods, devices, and systems are disclosed for protecting the confidentiality of one or more lists of CAG IDs for use in NPN and/or the privacy of NPN users (e.g., WTRUs). In one example, a WTRU may be configured to perform one or more of the following operations.

For example, the WTRU may compare a hash value of a locally configured set or list of allowed CAG ID(s) of the WTRU with a hash value of the CAG ID(s) supported by the CAG cell (e.g., in a broadcast message and/or system information broadcast by the CAG cell, or in a unicast message sent by the CAG cell) to find one or more matching CAG IDs. The WTRU may obtain, for example, a broadcast message from the received message that includes system information with key parameters (e.g., the gNB 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 decode the key parameter (e.g., the gNB 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 the secret key using the exchanged key parameters (e.g., one or more of the gNB ephemeral public key(s) and the WTRU ephemeral public key (s)) and the WTRU or UE identity (e.g., C-RNTI). The WTRU may register with the network (e.g., a CAG cell or a gNB) while providing one or more matching CAG IDs in the RRC layer (e.g., RRC portion of the registration message) protected for confidentiality and integrity using a secret key (e.g., as in the Advanced Encryption Standard (AES) algorithm). In some cases, the remainder of the registration process may be performed in a manner similar to that described in one or more embodiments discussed herein (e.g., the processes shown in fig. 2, 4, and/or 5).

Fig. 7 is a signal flow diagram illustrating an example CAG ID protection mechanism 700 in connection with an example registration process. The CAG ID protection mechanism of fig. 7 may use a Diffie-Helman based key agreement protocol. The CAG ID protection mechanism and/or representative procedures may be used, for example, to address confidentiality of one or more lists of CAG IDs used in an NPN (e.g., CAG cell or gNB) and/or privacy of an NPN user (e.g., WTRU). The CAG ID protection mechanism and/or representative procedure may include one or more of the following features (e.g., as shown in fig. 7):

the WTRU may be configured with a list of allowed CAGs from the HPLMN and the gNB may be configured with a list of supported CAG ID(s).

The gNB may perform one or more of the following operations:

for example, the gNB may generate an ephemeral private key a. The gNB may generate an ephemeral public key a using a (e.g., a ═ g)^amod p, where g and p are prime numbers, where p may be a large prime number (e.g., 2048 bits, 3072 bits, or greater), 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 ID(s) using RAND CELL.

The WTRU may obtain key configuration parameters from system information (e.g., SIB 1). The key configuration parameters may include any of the list(s) of p, g, a, RAND CELL, and hashed CAG IDs.

The WTRU may perform one or more of the following operations (e.g., after obtaining the key configuration parameters). For example, the WTRU may generate the temporary secret b. The WTRU may generate an ephemeral public key B using B (e.g., B-g)^bmod p). The WTRU may generate a shared secret K using a and b_ab(e.g., K)_ab＝A^bmod p). The WTRU may be from K_abA secret key K is derived (e.g., using a and B). The WTRU may select one or more CAG IDs from the list of allowed CAG IDs whose hash value(s) (determined/calculated using RAND CELL) at least match fromHash value of CAG ID of the gNB (configured or supported by the gNB). For each matching CAG ID, the WTRU may use K to calculate a hidden CAG ID (e.g., hidden CAG ID)_K＝CAG ID XORK)。

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: b, and one or more hidden CAGIDs_K。

The gNB can perform one or more of the following operations. For example, the gNB can generate a shared secret K using B and a_ab(e.g., K)_ab＝B^amod p). For one or more hidden CAG IDs_KThe gNB may compute a plaintext CAG ID (e.g., plaintext CAG ID — hidden CAG ID)_K XORK)。

6. A complete registration process may be performed in the same or similar manner as a similar type of process in one or more embodiments disclosed herein (e.g., the process disclosed herein in connection with fig. 2, 4, and/or 5). In various embodiments, the gNB may check whether the WTRU is allowed to access the CAG cell. The gNB may, for example, determine whether at least one clear-text CAG ID from the WTRU matches the gNB-configured CAG ID. For example, the gNB may determine to allow the WTRU to access the CAG cell if the gNB verifies that at least one clear text CAG ID from the WTRU matches the gNB configured/supported CAG ID.

Fig. 8 is a signal flow diagram illustrating a CAG ID protection mechanism 800 in conjunction with an example registration process. 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 representative procedures may be used, for example, to address confidentiality of one or more lists of CAG IDs used in an NPN (e.g., CAG cell or gNB) and/or privacy of an NPN user (e.g., WTRU). The CAG ID protection mechanism 800 may implement protection of CAG IDs transmitted by a WTRU (or UE) in a manner similar to the CAG ID protection mechanism 800 and/or the representative procedure 700 of fig. 7. In the CAG ID protection mechanism 800, EC curve 25519 is used as an example, and other curves may be used.

The CAG ID protection mechanism 800 may include one or more of the following features (e.g., as shown in fig. 8):

the WTRU may be configured with an allowed CAG list from the HPLMN. The RAN (e.g., the gNB) may be configured with a list of supporting CAG ID(s). In this example, the WTRU and RAN/gNB may be configured with EC domain parameters (e.g., curve 25519).

The gNB can perform one or more of the following operations. For example, the gNB may generate an ephemeral private key a (e.g., a 32-byte random number). The gNB may use a to generate an ephemeral public key K _ a (e.g., K _ a ═ X25519(a,9), where 9 is the base point of the curve). The gNB may generate a pseudo-random number (e.g., the n least significant bits of RAND _ CELL ═ K _ a). The gNB may calculate a respective hash value for each of its configured CAG ID(s) using RAND CELL.

In various embodiments, the hash value(s) of the configured CAG ID(s) may be bound to the ephemeral public key K _ a by calculating RAND _ CELL as a function of K _ a (e.g., truncation). This may enable protection of the DH key agreement from 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 to establish a shared secret with the WTRU (e.g., to obtain the plaintext CAG ID (s)).

New K _ as may be generated periodically (e.g., frequently) in order to reduce the likelihood of replay attacks on the WTRU hashing the CAG ID(s) (e.g., in the RRCSetupComplete message). The gNB may include, for example, a nonce (e.g., a pseudo-random number) in the broadcast message that may change independently of K _ a. For example, a new a and a new K _ a may be used for a given period of time (e.g., every few hours), and a new tentative value may be generated and used: i.) independent of K _ a generation, and ii.) for different time periods (e.g., shorter time periods, every few minutes). As such, this procedure may provide additional freshness (e.g., policy based) and may be used to save K _ a processing costs while providing protection against replay attacks requested using the WTRU connection.

The WTRU may obtain key configuration parameters from system information (e.g., SIB 1). The key configuration parameters may include any of the following: k _ a, and a list of hashed CAG IDs that the gNB is configured and/or supports. The WTRU may obtain a tentative value if the tentative value is included in (e.g., broadcast) System Information (SI).

The WTRU may perform one or more of the following operations (e.g., after obtaining the key configuration parameters). For example, the WTRU may generate an ephemeral private key b. The WTRU may generate an ephemeral public key B using B (e.g., K _ B ═ X25519(B, 9)). The WTRU may generate a shared secret S using K _ a and b (e.g., S ═ X25519(b, K _ a)). The WTRU may derive the secret key K from S using a key derivation function, K _ A, K _ B, and/or a WTRU or UE identity (e.g., K ═ HMAC-SHA256(S, K _ a | | K _ B | | C-RTNI)). If a tentative value is included in the broadcasted SI, the WTRU may use the tentative value 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(s) (determined/calculated using RAND _ CELL) at least match the hash value of the CAG ID 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, and all of the matched CAG IDs, the WTRU may calculate a hidden CAG ID using K (e.g., a hidden CAG ID)_KCAG ID for ciphering/integrity protection using K and AES algorithms).

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 hidden CAG IDs_K. In one example, the WTRU may include a nonce received from the broadcast SI (e.g., for session synchronization between feature 1, feature 2, and/or feature 4 discussed above, where the registration request message may need to be synchronized with the broadcast message discussed above in feature 1 and/or feature 2).

The gNB can 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 hidden CAGs_KThe gNB may compute a plaintext CAG ID (e.g., plaintext CAG ID ═ check integrity protection), decrypt the CAG ID using the K and AES algorithms_K). The gNB can pass the verificationThe included nonce corresponds to the current nonce in the broadcasted SI to verify the freshness of the WTRU request(s). The gNB may consider the WTRU request as valid using a previous tentative value (e.g., based on policy). In some cases, checking validity using the previous nonce may avoid the gNB rejecting WTRUs attempting to connect to the gNB using the previous nonce (the previous nonce was just replaced by the new nonce in the broadcasted SI).

6. A complete registration process may be performed in the same or similar manner as a similar type of process in one or more embodiments disclosed herein (e.g., processes 200, 400, 500, and/or 700 disclosed herein in connection with fig. 2, 4, 5, and/or 7).

Various embodiments disclosed herein illustrate mechanisms to protect the CAG ID(s) during the RRC connection establishment procedure. It is contemplated that the protection mechanism may also be used for confidentiality, integrity and replay protection that other procedures and/or Information Elements (IEs) may not be sent as clear text, e.g., during initial connection setup and/or in the absence of any existing/valid security context.

In various embodiments, the WTRU may use secret K AS disclosed herein to protect NSSAI during AS connection establishment. The WTRU may apply security protection to the NSSAI during AS connection establishment based on the NSSAI including mode parameters (AS described above). For example, when the NSSAI inclusion pattern is "d," the WTRU may use the secret K to protect the transmitted NSSAI. The protection mechanism may cause the gNB to decrypt the NSSAI during AS connection establishment to forward the initial WTRU request to a designated serving AMF, instead of the default AMF, even when the WTRU is configured with NSSAI inclusion mode "d". In some embodiments, when the WTRU is operating in mode "d", the gNB may forward the WTRU request(s) to the default AMF, possibly subsequently resulting in additional AMF reallocation procedures.

In various embodiments, where "cold start" data transfer is used with over-the-air data protection (e.g., data transfer during initial registration and/or during AS connection establishment procedure (s)), other IEs such AS user data may be transferred with confidentiality, integrity, and replay protection using the mechanism(s) disclosed herein.

Among the types of IEs that may be protected using the protection mechanisms disclosed herein are IEs used during AS connection establishment, including, for example, WTRU or UE identities. Examples of the WTRU or UE identity (identifier) may include a System Architecture Evolution (SAE) temporary Mobile subscriber identity (S-TMSI) and/or a 5G globally unique temporary UE identity (5G-GUTI). In one example, confidentiality and replay protection of the protection mechanisms disclosed herein may prevent an adversary attempting to establish an RRC connection spoofed using a target WTRU or UE identity (e.g., S-TMSI) from causing a DoS attack on the target WTRU. In the attack scenario example, the target WTRU is in RRC IDLE, while after the malicious RRC connection attempt(s), the target WTRU is considered to be RRC CONNECTED in the network or gNB. In such an attack, the target WTRU may stop receiving paging messages because the target WTRU is deemed to have connected to the network or the gNB.

Representative Process for protecting NPN confidentiality and/or NPN user privacy Using ECIES

In various embodiments, the WTRU may use ECIES to protect one or more CAG IDs transmitted when establishing AS connections.

In one example, the WTRU may obtain the RAN (e.g., gNB) public key from the broadcasted SI. The WTRU may use the RAN public key and an ephemeral public/private key pair generated in ECIES to derive a symmetric ciphering key and a Message Authentication Code (MAC) key. The WTRU may use one or more of these keys to protect one or more (e.g., selected) CAG IDs. In one example, the WTRU may transmit a WTRU-generated ephemeral public key, and/or a CAG ID that is ciphered and integrity protected (e.g., a CAG ID cipher with its MAC tag) during RRC connection establishment (e.g., in a RRCSetUpComplete message). After receiving the message containing the protected CAG ID, the RAN (e.g., the gNB) may perform an ECIES key agreement function using the RAN's private key and the WTRU's provided ephemeral public key to derive symmetric ciphering and MAC keys. Using these keys, the RAN can verify the CAG ID integrity and decrypt the CAG ID cryptogram.

It is contemplated that the RAN may support different types of CAG ID protection mechanisms to accommodate WTRUs having different capabilities or to 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 transmit and/or provide the selected protection mechanism to the RAN along with the protected CAG ID information (e.g., as a specific code in the RRCSetup message). In various embodiments, a gNB supporting ECDH (as described above) and ECIES mechanisms can decide whether the received ephemeral public key is for the ECDH mechanism or the ECIES mechanism based on protected CAG ID information (e.g., a specific code) provided by the WTRU.

In various embodiments, the WTRU may obtain the RAN (e.g., gNB) public key after successful registration using confidentiality, integrity, and replay protected unicast messages (e.g., rrcreeconfiguration messages). The WTRU may use the RAN public key to protect the transmitted CAG ID 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 setup (e.g., during a service request and/or registration procedure). One or more CAG ID protection mechanisms supported by the WTRU (e.g., any of those employing key agreement, ciphering, and/or integrity algorithms) 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 an AS Security Mode Command (SMC) procedure, or transmitted by the RAN to the WTRU in a different message (e.g., rrcreeconfiguration message). In subsequent RRC connection setup, if the WTRU has a RAN public key, the RAN may or may not provide a fresh or new public key (e.g., based on its security policy). To enable RAN public key revocation, it is contemplated that the RAN may transmit an identifier (e.g., a unique index) of the public key to the WTRU. The WTRU may transmit an identifier of the public key (being used for CAG ID protection) during RRC connection establishment (e.g., in the RRCSetupComplete message). The RAN may detect that the public key used to protect the CAG ID is revoked based on the provided key identifier, and may decide to provide the WTRU with a new public key.

In various embodiments, upon detecting a key revocation condition or in accordance with serving network security policies, the WTRU may replace a previously stored public key with a new public key (or remove an old key or a previously stored public key).

Although one or more of the above-described embodiments may be used in an independent manner, they may also be combined. For example, the WTRU may use Diffie-Hellman based procedures/mechanisms for initial registration and ECIES based procedures/mechanisms for subsequent registrations.

Various embodiments disclosed herein provide CAG ID(s) protection during RRC connection establishment procedures using ECIES. It is contemplated that these protection mechanisms may also be used for confidentiality, integrity, and replay protection of other processes and/or IEs that may not be sent as clear text, e.g., during initial connection establishment and/or in the absence of any existing/valid security context.

Representative procedures for using WTRU configuration related to CAG cell location

In various embodiments, the WTRU configuration (e.g., based on allowed NSSAI, or associated with CAG cell location) may be incorrect when moving to a new CAG cell. When a WTRU in a CM-IDLE state (e.g., an NPN enabled WTRU) moves from one CAG cell to another CAG cell, the WTRU may compare a list of CAG IDs broadcast in the new CAG cell with a list of CAG IDs broadcast in the previous CAG cell. If the common and/or overlapping CAG ID(s) of the WTRU's allowed CAG ID list and the CAG ID list broadcast in the new cell are different from the CAG ID(s) of the WTRU's allowed CAG ID list and the CAG ID list broadcast in the previous cell, the WTRU may initiate a registration and/or service request procedure with the network, such as synchronizing its current CAG cell location with the network, and/or receive an appropriate configuration for the new CAG cell (e.g., allowed NSSAI). To perform the comparison of the CAG IDs described above, the WTRU may store a list of CAG IDs of previous cells and/or a common portion of the list of CAG IDs of previous cells.

In various embodiments, the WTRU may have a list of allowed CAG IDs, which may contain or include "CAG-1" and "CAG-2", and the WTRU may camp on a CAG cell broadcasting a list of CAG IDs with "CAG-1" and "CAG-3". The common part of the WTRU's allowed CAG ID list and broadcasted CAG ID list (e.g., the overlap between them) is "CAG-1". When the WTRU moves to a new CAG cell broadcasting a CAG ID list with "CAG-2" and "CAG-4", the common part of the WTRU's allowed CAG ID list and the broadcasted CAG ID list may be changed to "CAG-2".

Upon determining/observing such a change (e.g., such a change), the WTRU may initiate a registration and/or service request procedure. During or after the registration/service request procedure, the network may be aware that the CAG location of the WTRU has changed, and the network may send the relevant configuration (e.g., NSSAI allowed) to the WTRU during the same registration or service request procedure, or the network may initiate another NAS procedure (e.g., UE Configuration Update (UCU) procedure) to update the configuration.

In various embodiments, if mobility between various CAG cells occurs while the WTRU is in RRC _ INACTIVE (RRC _ INACTIVE) state, the WTRU may initiate an RRC connection recovery procedure when the WTRU observes that the common part of the CAG ID has changed. In the RRC recovery 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 may be aware that the CAG location of the WTRU has changed and may send an updated configuration to the WTRU. For example, a RAN announcement area (RNA) configured for a WTRU in RRC _ INACTIVE mode may only contain or include cells of the same CAG ID(s), so that a change in CAG cells may automatically trigger an RNA update procedure, which may, for example, enable the network to update the configuration.

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

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

In the handover procedure 900, the WTRU reports the CAG ID of the measured cells, so the source RAN may select one or more handover target cells in consideration of the CAG ID. The WTRU may trigger registration to receive the updated configuration after handover and check the active PDU session against the updated NSSAI (e.g., allowed NSSAI) and take appropriate action (e.g., initiate PDU session release).

Representative procedure for WTRU allowed CAG ID configuration after subscription update

In various embodiments, representative mechanisms/procedures may be used to prevent the system or network from causing the WTRU's allowed CAG ID list to be exhausted and subsequently blocking the WTRU from network access or further network access. For example, the mechanism/procedure may be implemented to prevent the WTRU from having an incorrect or outdated allowed CAG ID configuration after a subscription update at the network (e.g., AMF), for example, the WTRU may not be registered with the network. The representative mechanism/process may include any of the following operations.

For example, when the WTRU registers with the network, the WTRU may include its allowed CAG ID list in the full initial NAS message sent in the NAS SMC complete message. In another example, the WTRU may include a flag indicating that the WTRU allows the CAG ID list to include or include only one CAG ID or a number of CAG IDs. The CAG ID selected by the WTRU for accessing the cell may be provided or sent by the NG-RAN to the AMF via an N2 message (e.g., an N2 message as shown in fig. 2). The WTRU may provide an indication indicating whether the WTRU is only able to access the network through the CAG cell.

In various embodiments, the AMF may detect that the subscription data is not synchronized based on a list of allowed CAG IDs received from the WTRU. For example, the subscription may have been updated when the WTRU is 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 list 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.

In various embodiments, the AMF may determine that the WTRU may only access the network through the CAG cell. The AMF may use a corresponding indication (e.g., an indication value) provided by the WTRU because the indication (e.g., an indication value) in the subscription (e.g., subscription data) may have been updated with the allowed CAG ID list. The AMF may update the WTRU CAG configuration information (e.g., allow CAG ID list and/or optional indication indicating whether the WTRU is only allowed to access the network via CAG cells). In one example, the AMF may send a new list of allowed CAG IDs and/or provide a new (or updated) indication to indicate whether the WTRU can only access the network through CAG cells, which may be done by sending a message (e.g., a UE configuration update message) to the WTRU to update its configuration. In another example, the AMF may provide the new CAG configuration information in a protected registration response (e.g., registration reject message).

In various embodiments, the WTRU may update its allowed CAG ID list (e.g., based on updated information and/or indications received from the network). For example, the WTRU may remove the obsolete CAG ID(s) and add one or more new CAG IDs. After the CAG information configuration update, the WTRU may perform new CAG cell selection and/or network registration, for example, using its new (or updated) allowed CAG ID list. In various embodiments, the WTRU may update its allowed CAG ID list based on existing WTRU configuration update (e.g., UE configuration update) procedures and/or new CAG configuration information provided to the WTRU (e.g., through any other protected message or messages).

In some examples, an adversary may attempt to have the WTRU clear its allowed CAG ID list. For example, an adversary may send a spoofed registration reject message(s) with an appropriate cause of CAG ID rejection, resulting in the removal of one or more or all CAG IDs. In various embodiments, to protect the WTRU from this type of attack(s), the WTRU may remove one or more CAG IDs from its allowed CAG ID list, for example, only if the registration reject message is at least integrity protected.

Representative procedures for secure access control mechanisms

In various embodiments, methods and apparatus are provided for secure access control in wireless communications, e.g., a secure access control mechanism (e.g., for NG-RAN). For example, a method for wireless communication (e.g., implemented in the WTRU 102) may include: a broadcast message including system information is received, and based on the system information, a first set of hash IDs and a first random number are identified, each ID of the first set of hash IDs being separately hashed using at least the first random number. The method may further comprise: the method further includes calculating a first hash value of 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/transmitting a request message based on determining that at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs.

In various embodiments, the method may include: based on determining that at least one hash ID of the second set of IDs matches a hash ID of the first set of IDs, calculating a second hash value using at least a second random number 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 WTRU ID assigned by a network. In various embodiments, the WTRU ID assigned by the network 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 at least information of the ID hashed by the second random number.

In 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 comprise: comparing each hash ID of the second set of IDs to each hash ID of the first set of hash IDs.

In various embodiments, each ID in the first set of hashed IDs is separately hashed using the first random number and a cell ID. In various embodiments, the first set of hash IDs includes one or more hash CAG IDs. In various embodiments, the second set ID comprises one or more preconfigured allowed CAG IDs.

In various embodiments, the method may comprise: based on the system information, a second random number is identified, and a second hash value is calculated using at least the second random number as at least one ID associated with a hash ID of the second set of IDs that matches the hash ID of the first set of hash IDs.

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 allowed CAG IDs, and replacing the stored set of allowed CAG IDs with the set of allowed 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.

In various embodiments, on a condition that the network entity (e.g., the gNB) does not find a matching ID, the method may include: receiving a registration rejection message after transmitting the registration request message. In various embodiments, on condition that the network finds at least one matching ID, the method may comprise: after sending the registration request message, receiving a registration accept message. In various embodiments, the first hash of each ID in the second set of IDs may be computed using the first random number and a cell ID.

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

In various embodiments, the method may comprise: receive a message (e.g., a broadcast message or a unicast message including system information) from a network entity (e.g., a gNB), and identify the one or more key configuration parameters and the second set of hash IDs based on the received message.

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

In various embodiments, when establishing the shared secret with the network entity, the method may include: the shared secret with the network entity is generated using the one or more key configuration parameters and the private key, and the one or more key configuration parameters may include a public key associated with the network entity.

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

In various embodiments, the one or more key configuration parameters may include any of: a public key associated with the network entity, and a nonce 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 an example, the function includes a truncation of the public key associated with the network entity.

In various embodiments, the ID of the WTRU (or WTRU ID) is a cell radio network temporary identifier (C-RNTI) or a designated RNTI assigned by a network (e.g., NG-RAN).

In various embodiments, the hash ID set may include one or more preconfigured allowed CAG IDs, or one or more subscriber IDs including one or more NPN IDs.

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.

In various embodiments, performing the registration process may include: a registration request message is sent that includes one or more hidden IDs.

In various embodiments, the method may identify a public key associated with the network entity from the one or more key configuration parameters, and deriving the secret key comprises: deriving any of a symmetric encryption key and a Message Authentication Code (MAC) key using the identified public key associated with the network entity.

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

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

In various embodiments, the network entity may be any of the following: AMF entity, base station, gNB and network node.

In various embodiments, the public or private key disclosed herein may be an ephemeral key.

In various embodiments, a method (e.g., implemented in a WTRU 102) for wireless communication may comprise: the method may include determining that a WTRU (e.g., WTRU 102) is in IDLE mode, identifying a set of preconfigured 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 on a condition that one or more preconfigured IDs common to the first set of IDs is different from one or more preconfigured IDs common to the second set of IDs.

In various embodiments, any of the first set of IDs or the second set of IDs may include one or more CAG IDs or NPN IDs. The set of preconfigured IDs may comprise one or more preconfigured allowed CAG IDs, or one or more subscriber IDs comprising one or more NPN IDs.

In various embodiments, a method (e.g., implemented in a WTRU 102) for wireless communication may comprise: determining that a WTRU (e.g., WTRU 102) is in RRC INACTIVE mode, identifying a set of preconfigured Identifiers (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 recovery procedure on a condition that one or more preconfigured IDs common to the first set of IDs is different from one or more preconfigured IDs common to the second set of IDs.

In various embodiments, a method (e.g., implemented in a WTRU 102) for wireless communication may comprise: the method includes reporting one or more measured sets of cell IDs to a first cell, initiating a registration procedure after handover to a second cell, receiving an updated configuration including an updated allowed NSSAI, and determining whether to initiate a Protocol Data Unit (PDU) session release according to whether one or more single NSSAIs (S-NSSAIs) associated with one or more active PDU sessions are in the updated allowed NSSAI.

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

In various embodiments, the CAG information may include a flag indicating that the stored list of allowed CAG IDs includes only one CAG ID, a plurality of CAD IDs, or a number of CAG IDs.

In various embodiments, a method (e.g., implemented in a WTRU 102) for wireless communication may comprise: a first message is received that includes a set of T-S-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 include: calculating one or more hash values of the requested set of T-S-NSSAIs using the WTRU ID and a random number assigned by a network, and sending a second message including at least the one or more hash values and the random number. In one example, the requested set of T-S-NSSAIs includes one or more of the set of T-S-NSSAIs supported by the network.

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.

In various embodiments, an apparatus (e.g., 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 nonce based on the system information, and each ID of the first set of hash IDs may be separately hashed using at least the first nonce. The apparatus may calculate a first hash value for each ID of a second set of IDs using at least the first random number and determine whether at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs. The apparatus may also include a transceiver/transmitter configured to transmit a request message based on determining that at least one hash ID of the second set of IDs matches a hash ID of the first set of hash IDs.

In various embodiments, a WTRU (e.g., WTRU 102) may include a processor, a transceiver, and a memory that implement any of the methods disclosed above.

Each of the following references is incorporated herein by reference: (1)3GPP S2-1902898, "Introducing support for Non-Public Networks"; (2)3GPP TS 23.122, "NAS functions related to MS in idle mode", V16.0.0; (3)3GPP TR 33.819, "Study on security for 5GS enhanced support of Vertical and LAN Services"; (4)3GPP S3-190994, "Key issue on CAG access control in Non-persistent one NPNs"; (5)3GPP TR 33.846, "Study on authentication enhancements in the 5G System"; (6)3GPP S3-190995, "New solution of CAG access control in Non-standalone NPNs"; (7)3GPP TS 23.501, "System Architecture for the 5G System", V15.4.0; (8)3GPP TS 23.502, "Procedures for the 5G System", V15.4.1; (9)3GPP TS 33.501, "Security architecture and procedures for 5G system", v15.2.0; (10)3GPP SA2 TR 23.734, "Study on enhancement of 5G System (5GS) for vertical and Local Area Network (LAN) services"; (11)3GPP S2-1902810, "TS 23.502: Introducing Non-public network-CAG"; (12) whitfield Diffie and Martin E.Hellman, "New directions in cryptography", IEEE Transactions on Information Theory,22(6): 644-; (13) IETF RFC 7748, "electrolytic solutions for Security"; (14)3GPP TR 33.813, "student on Security attachments of Enhanced Network sliding", V0.4.0; and (15)3GPP TS 38.300, "NR; NR and NG-RAN Overall Description ", V15.4.0.

Although features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with 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 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 associated with software may be used to implement a radio frequency transceiver for use in a WTRU 102, UE, terminal, base station, RNC, or any host computer.

Furthermore, in the above embodiments, reference is made to processing platforms, computing systems, controllers, and other devices that contain processors. These devices may contain at least one central processing unit ("CPU") and memory. Reference to acts and symbolic representations of operations or instructions that can be performed by various CPUs and memories according to practices by those skilled in the art of computer programming. These acts and operations or instructions may be referred to as being "executed," computer-executed, "or" CPU-executed.

Those of skill in the art will understand that the acts and symbolic representations of operations or instructions include the manipulation of electrical signals by the CPU. An electrical system representation may identify data bits that cause a transformation or restoration of an electrical signal and the maintenance of a storage location of the data bits in a storage system to thereby reconfigure or otherwise alter the operation of the CPU and other processing of the signal. The storage locations where data bits are maintained are those that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the representative embodiments are not limited to the platforms or CPUs described above and that other platforms and CPUs may support the provided methods.

The data bits may also be maintained on a computer readable medium, which includes magnetic disks, optical disks, and any other large storage system that is volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read-only memory ("ROM")) readable by a CPU. The computer readable medium may include cooperating or interconnected computer readable media that reside exclusively on the processor system or are distributed among multiple interconnected processing systems, which may be local or remote to the processing system. It is to be appreciated that the representative embodiments are not limited to the above-described memory and that other platforms and memories may support the described methods.

In the illustrated 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.

There is a little difference between hardware and software implementations of aspects of the system. The use of hardware or software is generally (e.g., but not always, because the choice between hardware and software may be important in some environments) a design choice that takes into account cost and efficiency tradeoffs. Various tools (e.g., hardware, software, and/or firmware) that can affect the processes and/or systems and/or other techniques described herein, and the preferred tools can vary with the context of the deployed processes and/or systems and/or other techniques. For example, if the implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and/or firmware implementation. If flexibility is paramount, the implementer may opt to have a mainly software implementation. Alternatively, an implementation may choose some combination of hardware, software, and/or firmware.

The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, or firmware, or virtually any combination thereof. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs); a Field Programmable Gate Array (FPGA) circuit, any other type of Integrated Circuit (IC), and/or a state machine.

Although features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited to the particular embodiments described herein, which are intended as examples of various aspects. Many modifications and variations may be made without departing from the spirit and scope thereof, as would be known to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, including the full scope of equivalents thereof. It should be understood that the present disclosure is not limited to a particular method or system.

It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, when referring to the term "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" herein may mean: (i) a wireless transmit and/or receive unit (WTRU), such as described below; (ii) any of a number of embodiments of a WTRU, such as described below; (iii) a wireless and/or wireline (e.g., wireless-communicable) device configured with some or all of the structure and functionality of a WTRU, such as described below; (iii) a wireless-capable and/or wired-capable device configured to have less than all of the structure and functionality of a WTRU, such as described below; or (iv) an analog. Details of an example WTRU, which may represent any of the UEs described herein, are provided below with reference to fig. 1A-1D.

In certain representative embodiments, 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 appreciate that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and/or firmware would be well within the skill of one of skill in the art in light of this disclosure. Moreover, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media such as floppy disks, hard disks, CDs, DVDs, digital tape, computer memory, etc., and transmission type media such as digital and/or analog communication media (e.g., fiber optic cables, waveguides, wired communications links, wireless communication links, etc.).

The subject matter described herein sometimes illustrates different components contained within, or connected to, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. Conceptually, any arrangement of components which performs the same function is effectively "associated" such that the desired function is performed. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable," to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.

With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. Various singular/plural permutations may be explicitly set forth herein for clarity.

It will be understood by those within the art that terms used herein, in general, and in the claims, in particular, that such terms are used 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 "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, if only one item is to be represented, the term "single" or similar language may be used. To facilitate understanding, the following claims and/or the description herein may contain usage of the introductory phrases "at least one" or "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the antecedent phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. Furthermore, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation "two recitations," without other modifiers, means at least two recitations, or two or more recitations).

Further, in these examples using conventions similar to "at least one of A, B and C, etc.," such conventions are generally understood by those of skill in the art (e.g., "the system has at least one of A, B and C" may include, but is not limited to, the system having only a, only B, only C, A and B, A and C, B and C, and/or A, B and C, etc.). In these examples using conventions similar to "at least one of A, B or C, etc." such conventions are generally those understood by those of skill in the art (e.g., "a system has at least one of A, B or C" may include, but is not limited to, a system having only a, only B, only C, A and B, A and C, B and C, and/or A, B and C, etc.). Virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should also be understood by those skilled in the art as including the possibility of including one, either, or both of the terms. For example, the phrase "a or B" is understood to include the possibility of "a" or "B" or "a" and "B". Furthermore, as used herein, the recitation of "any" followed by a plurality of items and/or a plurality of items is intended to include "any," "any combination," "any plurality of" and/or "any combination of" the plurality of items and/or the plurality of items, alone or in combination with other items and/or items. Further, the term "set" or "group" as used herein is intended to include any number of items, including zero. Furthermore, the term "number" as used herein is intended to include any number, including zero.

Furthermore, if features or aspects of the disclosure are described in terms of markush groups, those skilled in the art will appreciate that the disclosure is also described in terms of any individual member or subgroup of members of the markush group.

It will be understood by those skilled in the art that all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof for any and all purposes, such as for providing a written description. Any listed ranges may be readily understood as being sufficient to describe and implement the same ranges divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range described herein may be readily divided into a lower third, a middle third, an upper third, and the like. Those skilled in the art will also appreciate that all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and to the extent that such subranges are subsequently broken down into the above recited subranges. Finally, as will be understood by those of skill in the art, a range includes each individual member. Thus, for example, a group and/or set of 1-3 cells refers to a group/set of 1, 2, or 3 cells. Similarly, a group/set of 1-5 cells refers to a group/set of 1, 2, 3, 4, or 5 cells, and so on.

Furthermore, the claims should not be read as limited to the order or elements provided unless stated to that effect. Furthermore, use of the term "means for …" in any claim is intended to refer to 35 u.s.c. § 112,claim format for 6 or device + function, any claim without the term "means for …" does not have such intent.

A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit/receive unit (WTRU), User Equipment (UE), terminal, base station, Mobility Management Entity (MME), or Evolved Packet Core (EPC), or any host computer. The WTRU may incorporate modules, including a Software Defined Radio (SDR), implemented in hardware and/or software, and other components, such as a camera, a video camera module, a video phone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, bluetoothA module, a Frequency Modulation (FM) radio unit, a Near Field Communication (NFC) module, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) module.

Although the present invention has been described in terms of a communications system, it is contemplated that the system may be implemented in software on a microprocessor/general purpose computer (not shown). In some embodiments, one or more of the functions of the various components may be implemented in software that controls a general purpose computer.

Furthermore, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.

Throughout the disclosure, a skilled person understands that certain representative embodiments may be used alternatively or in combination with other representative embodiments.

Although features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented as a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer readable 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 a WTRU, UE, terminal, base station, RNC, and any host computer.

Further, in the embodiments described above, processing platforms, computing systems, controllers, and other devices that contain a processor are noted. These devices may contain at least one central processing unit ("CPU") and memory. Reference to acts and symbolic representations of operations or instructions may be performed by various CPUs and memories according to practices by those skilled in the art of computer programming. Such acts and operations or instructions may be referred to as being "executed," computer-executed, "or" CPU-executed "

Those of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation by the CPU of electrical signals. Electrical systems represent data bits that can cause transformations or reductions in electrical signals and the maintenance of data bits at memory locations in a memory system to reconfigure or otherwise alter the operation of the CPU and other processing of the signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits.

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

Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs); a Field Programmable Gate Array (FPGA) circuit, any other type of Integrated Circuit (IC), and/or a state machine.

Although the present invention has been described in terms of a communications system, it is contemplated that the system may be implemented in software on a microprocessor/general purpose computer (not shown). In some embodiments, one or more of the functions of the various components may be implemented in software that controls a general purpose computer.

Furthermore, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.