Method, architecture, device and system for authentication and identification management of environment energy supply internet of things equipment

Abstract

A method implemented in a wireless transmit receive unit (WTRU) is described herein. The method may include (i) sending a first message to a first network element of the cellular network, the first message indicating an Extensible Authentication Protocol (EAP) boot request and a network access identifier of the WTRU, (ii) receiving a second message from the first network element of the cellular network, the second message indicates one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers, (iii) determining that a pseudo-identifier of the one or more pseudo-identifiers may be valid based on the valid time period, and (iv) sending a request message to a second network element of the cellular network based on the pseudo-identifier being valid, the pseudo identifier is indicated as a WTRU identifier in the request message.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Patent Application No. 63 / 540,982, filed September 28, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure is generally directed toward the fields of communications, software, and coding, including methods, architectures, apparatuses, and systems for the authentication and identification management of IoT devices for ambient energy supply. Background Technology

[0003] An IoT device that supports environmental power can be considered as an IoT device that can harvest energy from the environment, such as from radio waves, motion, vibration, piezoelectricity, solar energy, and wind energy. The embodiments described herein are designed with the above considerations in mind. Summary of the Invention

[0004] This document describes methods, architectures, apparatuses, and systems for authentication (e.g., authorization) and identification management of IoT devices powered by environmental conditions. In one embodiment, a Wireless Transmit / Receive Unit (WTRU) is described. The WTRU may include circuitry comprising any one of a transmitter, a receiver, a processor, and a memory. The WTRU may be configured to send a first message to a first network element of a cellular network. In various embodiments, the first message may indicate an Extensible Authentication Protocol (EAP) bootstrapping request and a network access identifier for the WTRU. In various embodiments, the network access identifier may be forwarded to an EAP server. The WTRU may be configured to receive a second message from the first network element of the cellular network. In various embodiments, the second message may indicate one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers. The WTRU may be configured to determine, based on the valid time period, that one of the one or more pseudo-identifiers may be valid. The WTRU may be configured to send a request message to a second network element of the cellular network based on the validity of the pseudo-identifier, in which the pseudo-identifier is indicated as a WTRU identifier.

[0005] In one embodiment, a method implemented in a Wireless Transmit / Receive Unit (WTRU) is described. The method may include sending a first message to a first network element of a cellular network. In various embodiments, the first message may indicate an Extensible Authentication Protocol (EAP) bootstrapping request and a network access identifier for the WTRU. In various embodiments, the network access identifier may be forwarded to an EAP server. The method may include receiving a second message from the first network element of the cellular network. In various embodiments, the second message may indicate one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers. The method may include determining, based on the valid time period, that one of the one or more pseudo-identifiers may be valid. The method may include sending a request message to a second network element of the cellular network based on the validity of the pseudo-identifier, in which the pseudo-identifier is indicated as a WTRU identifier.

[0006] In one embodiment, a network element of a cellular network is described. The network element may include circuitry comprising any one of a transmitter, receiver, processor, and memory. The network element may be configured to receive a first message from a Wireless Transmit / Receive Unit (WTRU). In various embodiments, the first message may indicate an Extensible Authentication Protocol (EAP) bootstrapping request and a network access identifier for the WTRU. The network element may be configured to send an EAP message to an EAP server. In various embodiments, the EAP message may indicate the network access identifier for the WTRU. The network element may be configured to send a second message to the WTRU. In various embodiments, the second message may indicate one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers. The network element may be configured to receive a request message from the WTRU. In various embodiments, the request message may indicate one of the one or more pseudo-identifiers as a WTRU identifier.

[0007] In one embodiment, a method implemented in a network element of a cellular network is described. The method may include receiving a first message from a Wireless Transmit / Receive Unit (WTRU). In various embodiments, the first message may indicate an Extensible Authentication Protocol (EAP) bootstrapping request and a network access identifier for the WTRU. The method may include sending an EAP message to an EAP server. In various embodiments, the EAP message may indicate the network access identifier for the WTRU. The method may include sending a second message to the WTRU. In various embodiments, the second message may indicate one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers. The method may include receiving a request message from the WTRU. In various embodiments, the request message may indicate one of the one or more pseudo-identifiers as a WTRU identifier. Attached Figure Description

[0008] A more detailed understanding can be obtained from the detailed description given below by way of example in conjunction with the accompanying drawings. The figures in these drawings, like the detailed description, are illustrative. Therefore, the individual figures (FIG.) and the detailed description should not be considered limiting, and other equivalent examples are possible and applicable. Furthermore, the same reference numerals ("ref.") in the figures denote the same elements, and wherein: Figure 1A This is a system schematic diagram illustrating an example communication system; Figure 1B It shows that it can be shown Figure 1A A system schematic diagram of an example wireless transmit / receive unit (WTRU) used in a communication system shown; Figure 1C It shows that it can be shown Figure 1A The diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system. Figure 1D It shows that it can be shown Figure 1A A system schematic diagram showing another example RAN and another example CN used in the communication system shown; Figure 2 This is a schematic diagram illustrating an example method for cellular network authentication and authorization; Figure 3 This is a schematic diagram illustrating an example of Extensible Authentication Protocol (EAP) bootstrapping via intermediate network elements; Figure 4 This is a schematic diagram illustrating an example of EAP guidance via the control plane of a cellular network; Figure 5 This is a schematic diagram illustrating an example of EAP guidance via the control plane of a cellular network; Figure 6 This is a schematic diagram illustrating an example of pseudonym and session key insertion in a cellular network; Figure 7 This is a schematic diagram illustrating an example of network access authorization and uplink data transmission using device pseudonyms; Figure 8 This is a schematic diagram illustrating an example method for authentication and identification management of environmentally powered IoT devices; Figure 9 This is a schematic diagram illustrating an example method for authentication and identification management of environmentally powered IoT devices implemented in WTRU; and Figure 10 This is a schematic diagram illustrating an example method for authentication and identification management of ambient-powered IoT devices implemented in network elements. Detailed Implementation

[0009] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, processes, components, and circuits are not described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of or in combination with the embodiments or other examples expressly, implicitly, and / or inherently described, disclosed, or otherwise provided herein (collectively, the “Provided”). Although various embodiments are described and / or claimed herein, in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any part thereof, it should be understood 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 part thereof.

[0010] Example Communication System The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Regarding... Figure 1A-1D An overview of various types of wireless devices and infrastructures is provided, in which various elements of the network can be utilized, performed, arranged, and / or adapted and / or configured for use with the methods, apparatuses, and systems provided herein.

[0011] Figure 1A This is a system schematic illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail (ZT) Unique Word (UW) Discrete Fourier Transform (DFT) Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0012] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments take into account any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include / or include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0013] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d, for example, to facilitate access to one or more communication networks such as CN 106 / 115, Internet 110, and / or Network 112. For example, base stations 114a and 114b may be any of a base transceiver station (BTS), a node-B (NB), an evolved node-B (eNB), a home node-B (HNB), a home evolved node-B (HeNB), a next-generation node-B (gNB), an NR node-B (NRNB), a site controller, an access point (AP), a wireless router, etc. Although base stations 114a and 114b are depicted as single elements, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0014] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells may provide coverage for a specific geographic area that may be relatively fixed or may vary over time. Cells 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, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

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

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

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

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

[0020] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0021] For example, Figure 1ABase station 114b can be a wireless router, home node-B, home evolution node-B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, home, vehicle, campus, industrial facility, (e.g., for drone use) air corridor, road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of small cells, pico cells, or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

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

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

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

[0025] Figure 1B This is a system schematic diagram illustrating example WTRU 102. (See attached diagram.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other components / peripherals 138, etc. It should be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the above-described components.

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

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

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

[0029] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Thus, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via various RATs such as NR and IEEE 802.11.

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

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

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

[0033] Processor 118 may be further coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units providing additional features, functions, and / or wired or wireless connectivity. For example, component / peripheral 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (e.g., for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, FM radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Component / peripheral 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0034] WTRU 102 may include a full-duplex radio for which some or all of the transmissions and receptions of signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which some or all of the transmissions and receptions of signals (e.g., associated with specific subframes for either uplink (e.g., for transmission) or downlink (e.g., for reception) may be concurrent and / or simultaneous.

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

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

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

[0038] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While each of the above elements is described as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

[0041] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks such as Internet 110, thereby facilitating communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

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

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

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

[0045] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more sites (STAs) associated with that AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent (e.g., directly) between a source STA and a destination STA using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using Standalone BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication pattern may sometimes be referred to as the "ad-hoc" communication pattern in this paper.

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

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

[0048] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which is referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segmented parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. These streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC) layer, entities, etc.

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

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

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

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

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

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

[0055] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node-B 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as Evolved Node-B 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement the DC principle to communicate essentially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more Evolved Node-B 160a, 160b, and 160c. In a non-standalone configuration, Evolved Node-B 160a, 160b, and 160c can be used as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRU 102a, 102b, and 102c.

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

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

[0058] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. Network slices can be used by AMF 182a and 182b to customize CN support for WTRU 102a, 102a, and 102c, for example, based on the service types used by WTRU 102a, 102b, and 102c. For example, network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, etc. AMF 182a and 182b can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as Wi-Fi.

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

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

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

[0062] Given Figure 1A-1D as well as Figure 1A-1D As described herein, one or more of the functions associated with any of the WTRU 102a-d, base station 114a-b, evolved Node-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other element / device described herein may be performed by one or more emulation elements / devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0064] One or more simulation devices can perform one or more functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in test scenarios within a test laboratory and / or an undeployed (e.g., testing) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices can be test equipment. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0065] Throughout the embodiments described herein, the terms “base station,” “network,” and “gNB” (collectively, “the network”) are used interchangeably to designate any network element, such as a network element that acts as a serving base station. The embodiments described herein are not limited to gNBs and are applicable to any other type of base station.

[0066] For clarity, throughout the embodiments described herein, the terms "satisfied condition," "unsatisfied condition," and "configured condition parameter" are described as being related to a threshold (e.g., greater than or less than a certain value, such as a threshold), configuring that value, etc. For example, satisfying a condition may be described as being above a certain value, such as a threshold, and not satisfying a condition may be described as being below a certain value, such as a threshold. The embodiments described herein are not limited to threshold-based conditions. Any other kind of conditions and parameters (e.g., belonging to or not belonging to a certain value range) may be applied to the embodiments described herein.

[0067] Throughout the embodiments described herein, (e.g., configuration) information can be described as being received by the WTRU from the network, for example, via system information or via any kind of protocol message. Although not explicitly mentioned throughout the embodiments described herein, the same (e.g., configuration) information can be pre-configured in the WTRU (e.g., via any kind of pre-configuration method, such as via factory settings) so that this (e.g., configuration) information can be used by the WTRU without being received from the network.

[0068] Throughout the embodiments described herein, the statements "the WTRU can be configured with a set of parameters" and "the WTRU can (e.g., from another network element (e.g., a gNB)) receive configuration information indicating a set of parameters" are equivalent or can be used interchangeably. Throughout the embodiments described herein, the statements "the WTRU can report something" and "the WTRU can be configured to report something" are equivalent or can be used interchangeably with "the WTRU can transmit (e.g., report) information indicating something." Throughout the embodiments described herein, the statements "the WTRU can provide ( / be provided with) a set of parameters ( / something)" and "the WTRU can transmit ( / receive) information indicating a set of parameters ( / something)" are equivalent or can be used interchangeably.

[0069] In the embodiments described herein, “a” and “an”, and similar phrases, will be interpreted as “one or more” and “at least one”. Similarly, any term ending with the suffix “(s)” will be interpreted as “one or more” and “at least one”. The term “may” will be interpreted as “may, for example”.

[0070] In this article, the symbol " / " (e.g., a forward slash) can be used to represent "and / or", where, for example, "A / B" may mean "A and / or B".

[0071] Overview Ultra-low-complexity devices, such as Ambient Energy IoT (A_IoT) devices, can use a lightweight EAP process to initiate an Extensible Authentication Protocol (EAP) bootstrapping process with an EAP server. The A_IoT device obtains a pseudonym and / or session key through the bootstrapping process. Either the obtained pseudonym or session key can be inserted into the cellular network by the EAP server and can be associated with any genuine identifier of the A_IoT device. When the A_IoT device accesses the cellular network, it can identify itself using (e.g., based on) the pseudonym. If the received pseudonym exists in the network database (e.g., matching an existing record), the network can grant access.

[0072] Throughout the embodiments described herein, the terms "ambient-powered IoT device," "ambient-powered IoT device," and "A_IoT device" are used interchangeably to refer to low-complexity devices that can be powered by ambient energy. This document describes embodiments using A_IoT devices as an example. The embodiments described herein are not limited to A_IoT devices and can be applied to any type of WTRU.

[0073] Throughout the embodiments described herein, the terms “pseudo-identifier” and “pseudo-identifier” are used interchangeably to refer to any kind of identifier that can be used to identify (e.g., A_IoT) devices.

[0074] Throughout the embodiments described herein, the terms “real identifier” and “device identifier” (e.g., for an A_IoT device) may be used interchangeably with either the “first (e.g., physical) identifier” or the “second (e.g., logical) identifier” (e.g., for an A_IoT device).

[0075] For simplicity, this document describes an embodiment for A_IoT authentication or authorization. The embodiments described herein can be applied to A_IoT authentication, A_IoT authorization, and any of A_IoT authentication and authorization.

[0076] IoT (A_IoT) devices that support ambient power supply Environmentally powered IoT devices can be considered as IoT devices that can harvest energy from the environment, such as from radio waves, motion, vibration, piezoelectricity, solar energy, and wind energy. A_IoT devices can be battery-free or have limited energy storage (e.g., using capacitors). Environmentally powered IoT devices can be used in industrial wireless sensor networks where the environment may be harsh (e.g., extremely high or low temperatures), and for such networks, battery-free operation, maintenance-free operation, and long service life may be appropriate. A_IoT devices can be present in smart logistics and / or smart warehousing. Low cost, small size, battery-free operation, and durability may make them suitable for attachment to large quantities of goods, and can facilitate more efficient goods identification, sorting, tracking, and inventory management.

[0077] The 3rd Generation Partnership Project (3GPP) has launched a research project to investigate potential service requirements for Ambient Powered Internet of Things (IoT) devices within 3GPP wireless networks. This research project is described in 3GPP Work Item Description SP-220085, “Study on Ambient Powered Internet of Things,” and in 3GPP Technical Report TR22.840, “Study on Ambient Powered Internet of Things (Release 19),” V2.0.0, 2023-09.

[0078] In 3GPP TR 38.848 “Study on Ambient IoT (Internet of Things) in RAN”, V1.0.0, 2023-09, three types of A_IoT devices can be identified (e.g., they may be referred to as device A, device B and device C in this document).

[0079] Device A may have no energy storage, no independent signal generation and / or amplification, such as backscatter transmission.

[0080] Device B may include energy storage without independent signal generation, such as backscatter transmission. The stored energy can be used, for example, to amplify the reflected signal.

[0081] Device C may include energy storage and may have independent signal generation capabilities, such as an active RF component for transmission.

[0082] Ultra-low complexity A_IoT devices may not support 3GPP Authentication and Key Agreement (AKA), Universal Integrated Circuit Card (UICC), or Embedded Subscriber Identity Module (eSIM) functionality. A_IoT devices may not have a cellular network subscription. Such devices may not possess any of the 3GPP identities, such as Subscription Permanent Identifier (SUPI), International Mobile Subscriber Identity (IMSI), International Mobile Station Equipment Identity (IMEI), or Mobile Station International Subscriber Directory Number (MSISDN). A_IoT devices may not support the primary authentication and authorization processes used in cellular networks (e.g., 5G-AKA, EAP-AKA, etc.). To serve A_IoT devices, cellular networks can implement one or more simplified authentication and authorization (A&A) mechanisms that can be supported by the A_IoT device.

[0083] Reduced-complexity authentication and authorization (A&A) mechanisms may not generate secure keys that can be used to protect (e.g., encrypt) any of the transmitted data, received data, and device identity. Regarding master A&A, the embodiments described herein allow A_IoT devices to securely transmit / receive data and protect their identity even when they cannot rely on secure keys generated from the master authentication process.

[0084] Some processes, such as paging, can be based on 3GPP identifiers. For example, the 5G Service Temporary Mobile Subscriber Identity (5G S-TMSI) can be used in paging timing calculations and can be included in paging records. The embodiments described herein illustrate whether and how 3GPP identifiers can be assigned, how 3GPP identifiers can be associated with the (e.g., their own) identifiers of A_IoT devices, and how 3GPP identifiers can be used in one or more service processes.

[0085] The embodiments described herein illustrate how ultra-low complexity A_IoT devices can be authenticated and authorized by cellular networks if the 3GPP standard's main A&A process is not supported.

[0086] The embodiments described herein illustrate mechanisms for protecting application data and device identity in A_IoT device communication.

[0087] The embodiments described herein illustrate a mechanism for allocating and managing identifiers to enable cellular network processes, such as paging, device triggering, data transmission / reception, etc.

[0088] In the embodiments described herein, an A_IoT device may have its own device identifier (e.g., which may differ from a 3GPP identifier). For example, an A_IoT device may have a first (e.g., physical) identifier (e.g., a serial number) and a second (e.g., logical) identifier associated with its hardware, the second identifier being able to identify (e.g., associated with) any of the following (e.g., an application name, product name, software fragment, etc., such as an electronic product code).

[0089] EAP-guided cellular network access authorization In one embodiment, cellular network access authorization can be based on EAP bootstrapping. The A_IoT device can initiate an EAP bootstrapping process with either an Authentication, Authorization, and Accounting (AAA) server or an Extensible Authentication Protocol (EAP) server through either the control plane or the user plane of the cellular network. The A_IoT device can obtain a session key and / or one or more temporary identifiers through EAP bootstrapping. The obtained session key and / or one or more temporary identifiers can be transmitted (e.g., broadcast) to the cellular network by the EAP (e.g., AAA) server. The A_IoT device and the cellular network can use the session key and / or one or more temporary identifiers to either perform reduced-complexity A&A or secure data transmission.

[0090] Cellular network access authorization may include: (1) lightweight EAP bootstrapping via either the control plane or the user plane of the cellular network; (2) insertion of identifiers and session keys generated by the bootstrapping process in the cellular network; and (3) the use of identifiers and session keys in the network A&A and various service processes.

[0091] Figure 2 This is a schematic diagram illustrating an example method for cellular network authentication and authorization.

[0092] As shown in Figure 21, the A_IoT device can perform lightweight EAP bootstrapping to obtain a session key and any one of one or more identifiers, which can be stored in the A_IoT device. As shown in Figure 22, the 5G network can insert either the generated identifier or the session key. As shown in Figure 23, the A_IoT device can use either the session key or the identifier for A&A and any one of one or more service processes.

[0093] Example of EAP boot Before an A_IoT device can access a cellular network (e.g., including either a public or non-public network) to obtain services, it can initiate an EAP bootstrapping process with an EAP server. The EAP bootstrapping process may be designed to generate any of the following in the A_IoT device and network: a pseudo-identifier, a session key, and a certificate. These identifiers, keys, and certificates can later be used for network A&A and any other processes. The A_IoT device may support (e.g., may be able to execute) one or more EAP methods (e.g., Extensible Authentication Protocol Transport Layer Security (EAP-TLS), etc.) and may include credentials associated with the supported EAP methods (e.g., any of pre-shared keys, certificates, etc.).

[0094] A_IoT devices can execute the EAP bootstrapping process according to any of the three example methods described in this article.

[0095] In the first example method, the EAP initiation process can be executed through an intermediate network element or entity (such as, for example, either a WTRU or a RAN network element). The intermediate network element can act as an EAP authenticator and can forward EAP messages between the A_IoT device and the EAP server.

[0096] Figure 3 This is a schematic diagram illustrating an example of EAP booting via an intermediate network element.

[0097] As shown in Figure 31, the A_IoT device can negotiate the EAP method used for guidance. For example, the internal EAP method can be pre-provisioned, and online negotiation may not be performed. For instance, if the intermediate network element is a WTRU, the WTRU can transmit broadcast information indicating its support for EAP guidance (e.g., via a PC5 broadcast channel). The A_IoT device and the WTRU can exchange supported EAP methods (e.g., information indicating the EAP method) on a PC5 unicast link and can select the EAP method used for guidance. If the intermediate node is a RAN network element (e.g., a gNB), negotiation can be performed on a Radio Resource Control (RRC) link. The RAN network element can, for example, transmit broadcast information indicating its support for EAP guidance in a System Information Broadcast (SIB) transmission.

[0098] As shown in Figure 32, an A_IoT device can initiate EAP initiation by sending an EAP initiation request (e.g., a first message indicating the EAP initiation request) to an intermediate network element, for example, on either the PC5 or RRC link. The A_IoT device can provide (e.g., include) either its device identifier or application identifier in the initiation request. The device identifier can include either the A_IoT device's first (e.g., physical) identifier or its second (e.g., logical) identifier. The application identifier can be any identifier that identifies any application or service. An application identifier can be shared by more than one A_IoT device. The A_IoT device can provide an EAP server address (e.g., including information indicating the EAP server address), for example, if the address is pre-configured in the A_IoT device. In another example, the intermediate network element may already have an EAP server address configured (e.g., either an IP address or a Uniform Resource Identifier (URI)). The intermediate network element may already have WTRU Routing Policy (URSP) rules configured. The service descriptor of the URSP rule can indicate that the URSP rule can be associated with (e.g., all) EAP services and (e.g., all) Environmental IoT services. In one example, the intermediate network element can use this URSP rule to determine which PDU sessions can be used to transmit EAP messages 34. In another example, the intermediate network element can use this URSP rule to determine the characteristics of the PDU sessions to be established, making the PDU sessions usable for transmitting EAP messages 34.

[0099] As shown in Figure 33, an intermediate network element can construct a Network Access Identifier (NAI) in the form of "device-identifier@network-id" using a received device identifier and the identifier of a cellular network to which the intermediate network element may connect. In the embodiments described herein, the NAI may be referred to as a device identifier associated with a network identifier. The selected network ID can be either the home network of the intermediate network element or the identity of a network to which the intermediate network element can currently register. In another example, the selected network ID can be derived from a received A_IoT device identifier. For example, a portion of the A_IoT device identifier may represent the owner of the A_IoT device (e.g., associated with it). The intermediate network element can be configured with rules that can be used to map portions of the A_IoT device identifier to either a network ID or a realm value. Either the network ID or the realm can be used by the network to determine the identity of the AAA server to which the A_IoT device can perform authentication and authorization.

[0100] As shown in 34, the intermediate network element can locate the EAP server (e.g., by using the received EAP server address and querying the Domain Name System (DNS) server) and can send the EAP message 34 to the EAP server via a cellular network (through either the control plane or the user plane). The EAP message 34 may include the constructed NAI.

[0101] As shown in Figure 35, an intermediate network element can relay EAP message exchanges between the A_IoT device and the EAP server. The details of the EAP exchange may depend on the selected EAP method. If EAP authentication is successful, the intermediate network element can receive a pseudonym and / or session key generated by the EAP server, along with other parameters such as, for example, a timestamp and any of the information indicating the validity period of the pseudonym and session key, the encryption algorithm to be used, etc. In the embodiments described herein, the timestamp may refer to the time of successful WTRU authentication. The validity period may indicate the time during which any of the associated information (pseudonym, session key, etc.) may be valid. The intermediate network element may, for example, forward the information received from the EAP server to the A_IoT device in a second message. The format of the generated pseudonym may approximate the format of 3GPP identifiers, such as either SUPI or Subscription Hidden Identifier (SUCI). The pseudonym received by the A_IoT device may include a list (e.g., a set) of multiple pseudonyms. This list may later be available for the A_IoT device to use with the network. When the A_IoT device (e.g., each time) contacts the network, such as during a service request process as described herein, the A_IoT may use pseudo-identifiers different from the pseudo-identifier list.

[0102] As shown in 36, an A_IoT device can store any of the received pseudo-identifiers, session keys, and other parameters.

[0103] In the second example method, the EAP initiation process can be executed through the control plane of the cellular network. A_IoT devices can establish a non-access stratum (NAS) link with the network. Network functions (such as Access and Mobility Functions (AMF)) can be used as EAP authenticators and can forward EAP messages between the device and the EAP server.

[0104] Figure 4 This is a schematic diagram illustrating an example of EAP guidance via the control plane of a cellular network.

[0105] As shown in 41, an A_IoT device can establish a NAS link with (e.g., a selected) cellular network by sending a NAS request (such as either a registration request or a service request) to the cellular network (e.g., a first message indicating a NAS request). The A_IoT device may include a bootstrap request indication in the NAS request and may provide (e.g., include) its NAI (e.g., "Device-Identifier@Network-id"). For this NAS request, the usual primary A&A can be skipped.

[0106] As shown in 42, the AMF network element can locate the EAP server (e.g., by either (i) receiving the address directly from the A_IoT device, or (ii) deriving the address from either the device identifier or the application identifier). The AMF network element can initiate a bootstrapping process and can send an EAP message 42 to the EAP server containing the NAI (e.g., information indicating the NAI).

[0107] As shown in Figure 43, the AMF network element can relay EAP message exchanges between the A_IoT device and the EAP server. The details of the EAP exchange may depend on the chosen EAP method. If EAP authentication is successful, the AMF network element can receive any one of the pseudonym, session key, and other parameters generated by the EAP server, such as a timestamp (e.g., the timestamp of successful WTRU authentication) and information indicating the valid time period of either the pseudonym or the session key. These parameters can be forwarded to the A_IoT device, for example, via the NAS link in a second message. The pseudonym received by the A_IoT device can be a list (e.g., a set) of multiple pseudonyms. This list can later be used by the A_IoT device itself with the network. When (e.g., each time) the A_IoT device contacts the network, such as during a service request process as described herein, the A_IoT can use a different (e.g., pseudo) identifier than the list.

[0108] As shown in 44, an A_IoT device can store any of the received pseudo-identifiers, session keys, and other parameters.

[0109] In the third example method, the EAP bootstrapping process can be executed via the user plane of the cellular network. A_IoT devices can establish a PDU session in the network for bootstrapping purposes and can exchange EAP messages with the EAP server via the user plane. Network functions (such as Session Management Function (SMF)) can be used as EAP authenticators.

[0110] Figure 5 This is a schematic diagram illustrating an example of EAP guidance via the user plane of a cellular network.

[0111] As shown in Figure 51, an A_IoT device can request a PDU session from an SMF. The A_IoT device can send a first message to the SMF network element indicating a request for a PDU session. The first message may include, for example, a PDU session establishment request. The first message may indicate (e.g., an EAP) a bootstrapping request and any one or more identifiers of the A_IoT device, such as its NAI (e.g., "device-identifier@network-id"). As shown in 52, 53 and 54, SMF, UPF and EAP servers can participate in EAP protocol exchange.

[0112] As shown in 55, the SMF network element can (e.g. in the second message) send an EAP success message to the A_IoT device. The EAP success message includes information indicating any one of the assigned pseudonym, session key, and other parameters, such as a timestamp (e.g., WTRU successful authentication) and information indicating the valid time period of either the pseudonym or the session key.

[0113] The pseudonyms received by the A_IoT device can be a list (e.g., a set) of multiple pseudonyms. This list can later be used by the A_IoT device itself with the network. When the device contacts the network (e.g., each time), such as during a service request process as described herein, the A_IoT device can use a different (e.g., pseudo) identifier than the list.

[0114] As shown in 56, an A_IoT device can store any of the assigned pseudonym, session key, and other parameters.

[0115] In the three bootstrapping example methods described herein, although any of the intermediate network element, AMF network element, and SMF network element can perform the role of an EAP authenticator and can receive any of the assigned pseudonyms and session keys generated from the bootstrapping process, they may not store this information and may not use it at a later point in time (e.g., in the future) to authorize network access for A_IoT devices. As described herein, any of the pseudonyms and session keys generated from the bootstrapping process can be inserted into a central network element in the cellular network (e.g., Unified Data Management (UDM)) and can be retrieved by other network functions (e.g., AMF) for use in network access A&A.

[0116] After an A_IoT device has likely successfully completed the EAP bootstrapping process, it can initiate a new EAP process based on one or more rules to refresh either its pseudonym or key. For example, an A_IoT device can initiate a new bootstrapping process when the validity period (e.g., the indicated period) of either its currently active pseudonym or key may have expired. In another example, an A_IoT device can initiate bootstrapping processes periodically, etc.

[0117] Example of pseudonym and session key insertion in cellular networks A_IoT devices can initiate an EAP bootstrapping process, which can be successfully completed. The EAP server can send a request to the cellular network to insert either a generated pseudonym or a session key into the network. The EAP can send the request (e.g., information indicating the request) via any of the cellular network's open services and other application programming interfaces (APIs) that the cellular network can provide (e.g., to network elements of the cellular network). As described herein, if the pseudonym includes a list (e.g., a set), the EAP server can send this list to core network functions, such as... Figure 6 As shown.

[0118] Figure 6 This is a schematic diagram illustrating an example of pseudonym and session key insertion in a cellular network.

[0119] As shown in Figure 61, the A_IoT device can execute a device-initiated EAP bootstrapping process. As shown in Figure 62, the EAP server can send information to the Network Open Function (NEF) network element indicating a data insertion request. This information can indicate any of the following parameters: device identifier, pseudonym, session key, and other parameters such as, for example, timestamp and valid time period. As shown in Figure 63, the NEF network element can verify (e.g., determine) that the requesting server is trustworthy. As shown in Figure 64, the data insertion request message can be sent from the NEF network element to the UDM network element.

[0120] A data insertion request (e.g., it may be sent by an EAP server) may indicate any of the following: (i) whether the A_IoT device may have been successfully authenticated, (ii) the timestamp of successful authentication (e.g., a time value indicating when authentication was successful), (iii) the generated pseudonym and / or session key, (iv) the timestamp and / or valid time period of the pseudonym and session key, (v) the A_IoT device identifier (physical identifier and / or logical identifier) ​​associated with the pseudonym and session key, (vi) the application or service identifier that the A_IoT device may be associated with, (vii) the address of the application server (e.g., either an IP address or a fully qualified domain name (FQDN), and (viii) the valid area (e.g., a geographical region) that may allow the A_IoT device to access the network.

[0121] Cellular networks can store received information in a database (e.g., a centralized database), such as either a UDM or a Unified Data Repository (UDR). Other network functions that can handle network access for A_IoT devices in the future (e.g., either an AMF or an SMF) can query information from a database (e.g., a centralized database) and can verify whether the A_IoT device is legitimate as described herein.

[0122] Examples of the use of pseudonyms and / or session keys in network access authorization This article describes an example of using either a pseudonym or a session key in any of the network access authorization and other processes.

[0123] The A_IoT device can successfully complete the EAP bootstrapping process and may have already obtained a pseudonym and / or session key (e.g., in the second message). The A_IoT device can initiate access to the cellular network by sending a request message for (e.g., accessing, receiving) services. This request message may include (e.g., indicating) a NAS request. For example, the A_IoT device can initiate (e.g., NAS) connection establishment by sending (e.g., in the request message) any of the following requests: a registration request or a service request. The request message may indicate the type of the A_IoT device (e.g., indicating that the A_IoT device can be of a certain type, such as, for example, either an ultra-low complexity or low-power IoT device). This type may indicate that the A_IoT device may not support (e.g., normal master) A&A, making any of the minimum and / or reduced security protections applicable. The request message may indicate that the A_IoT device may have been successfully authenticated through the EAP bootstrapping process. The request message may indicate either the identifier (e.g., FQDN) or address of the EAP server that may have authenticated the A_IoT device. The request message may indicate (e.g., the time of a previous successful EAP authentication, such as a timestamp).

[0124] In one example, the pseudonym generated from the EAP bootstrapping process may be available and, for example, valid (e.g., indicated based on a valid time period if available). The A_IoT device may include the pseudonym in the request message as its primary identifier. If a list (e.g., a set) of more than one pseudonym is available (e.g., received from the EAP server), the A_IoT device may determine one of the pseudonyms based on one or more rules used for the current (e.g., NAS) request (e.g., a message). In one example, the A_IoT device may randomly determine a pseudonym from the list (e.g., the set). In another example, the A_IoT device may determine (e.g., select) a pseudonym that is different from (e.g., any) a pseudonym that may have been indicated in a previous (e.g., NAS) request (e.g., a message).

[0125] The request message may indicate either the application identifier or the service identifier associated with the A_IoT device. Either the application identifier or the service identifier can be used by the network to determine: (i) the destination of the application data, if it is included in the request message, and / or (ii) the format of the application data packets. For example, the network can use the format information to perform deep packet inspection of the data and replace one or more fields.

[0126] The request message may indicate (e.g., inserted by an A_IoT device) an application data container. The application data container may include any of the pseudonyms used as the A_IoT device identifier and other application information. In one example, the format of the application data container (e.g., the location of the device pseudonym) may be known to the network. In one example, the A_IoT device may encrypt its (e.g., real) identifier using a session key (if available), and may include the encrypted identifier in the application data container.

[0127] The request message can indicate whether an A_IoT device can request an acknowledgment of the response to the request. If the A_IoT device is power-constrained, it can enter a sleep state after sending the request and data, for example, without waiting for any response from the network.

[0128] In one example, a cellular network can receive (e.g., NAS) requests (e.g., messages) from an A_IoT device and can determine that the A_IoT device may be using a reduced (e.g., minimal) type of security protection. Based on the determination that the A_IoT device can use reduced security protection, the network can skip the usual main A&A process and can perform any of the following actions in the example: In the first action example, a cellular network function (e.g., AMF) capable of handling NAS requests can query a UDM network element to determine if a received alias is valid. If the received alias is available in either the UDM or UDR database and if the received alias is within the valid time period associated with the alias, the received alias can be determined to be valid, and the A_IoT device can be granted network access. The network function can retrieve other information associated with the alias from the UDM network element, including (i) (e.g., real) device identifiers (e.g., including physical and / or logical identifiers), (ii) session keys, (iii) the valid time period of the alias, (iv) application identifiers, and (v) service identifiers. The network function can store this information, for example, as device context, until the valid time period may have expired. The network function (e.g., AMF) can report location information (e.g., any of the cell / gNB ID, AMF identifier, etc., indicating from which a request (e.g., a message) may have been received (e.g., NAS)) in the query request, and the UDM can store the location information associated with the A_IoT device.

[0129] In the second action example, the cellular network (e.g., AMF) can allocate a dedicated network slice for A_IoT devices, which is designed to reduce security. This dedicated network slice can be securely isolated from other network resources, so that any security breaches within the dedicated network slice do not affect other network resources.

[0130] In the third action example, the application data container can be included in the request. A network function (such as AMF) can verify the data and can take any of the following actions: If the A_IoT device identifier in the data container is encrypted, the network function can decrypt the identifier using a session key and replace the original encrypted identifier with the decrypted identifier. If a pseudonym is used as the A_IoT device identifier in the data container, the network function can replace the pseudonym with the real identifier of the A_IoT device. After replacing the identifier, the network function can locate the destination address (e.g., based on the application identifier and the local network configuration) and can send the application data to the destination (e.g., sending the data as unstructured data via a NEF network element).

[0131] In the fourth action example, for instance, if the device has not yet indicated that it may not expect any response, the network function may send an acknowledgment message to the requesting A_IoT device. The acknowledgment message may indicate that the application data may have been successfully sent to its destination. The acknowledgment message may include information indicating, for example, the network slice assigned to the A_IoT device.

[0132] Figure 7This is a schematic diagram illustrating an example of network access authorization and uplink data transmission using the pseudonym A_IoT device.

[0133] As shown in 70, the A_IoT device can successfully complete the EAP bootstrapping process with the EAP server and obtain information indicating the pseudonym, session key, and any of the other parameters.

[0134] As shown in 71, an A_IoT device can send request messages for sending application data, such as NAS request messages (e.g., service requests). The request message can indicate that the A_IoT device can be of a type using reduced (e.g., minimal) security protections (e.g., specific). The A_IoT device can use (e.g., insert) its pseudonym as a device identifier in the (e.g., NAS) request message.

[0135] As shown in Figure 72, the AMF network element can query the UDM for A_IoT devices identified by pseudonyms. The AMF network element can also report information indicating the location of the A_IoT devices to the UDM.

[0136] As shown in 73, the UDM network element can store the received information indicating the location of the A_IoT device.

[0137] As shown in 74, the UDM network element can respond to whether information associated with the pseudonym exists (e.g., in a database) (e.g., sending an indication to the AMF network element indicating whether information associated with the pseudonym exists in a database), and if so, can send the information associated with the pseudonym of the A_IoT device to the AMF. This information may include any one of the A_IoT device's real identifier, session key, valid time period, negotiated security algorithm, etc.

[0138] As shown in 75, the AMF network element can examine the query results. If the information associated with the pseudonym is available, the AMF network element can determine that the A_IoT device may be legitimate and can store the A_IoT device information.

[0139] As shown in 76, if a request (e.g., a NAS) includes an application data container, the AMF network element can verify that data container and can replace either the encrypted device identifier or the pseudonym with the unencrypted real device identifier. The AMF network element can then locate the destination address of the application data.

[0140] As shown in 77 and 78, AMF network elements can send application data to their destination address via NEF.

[0141] In the downlink, a pseudonym can (e.g., may also) be used for either A_IoT device triggering or data transmission. The cellular network can receive device triggering requests from an application server, and the actual identifier of the A_IoT device can be included in the device triggering request. The cellular network can query its database (e.g., either UDM or UDR) to obtain information associated with the A_IoT device, such as the A_IoT device's location, pseudonym, etc. The cellular network can replace the actual device identifier with a pseudonym and can send device triggering requests through entities that can communicate with the A_IoT device (e.g., any of a backscatter device, gNB, and WTRU).

[0142] Example methods for A_IoT device authentication / authorization and identification management Figure 8 This is a schematic diagram illustrating an example method 800 for authentication and identification management of A_IoT devices. Method 800 can be implemented in an A_IoT device, such as a WTRU. As shown in 810, the WTRU can send a first message indicating an EAP bootstrapping request to an Extensible Authentication Protocol (EAP) server. As shown in 820, the WTRU can receive a second message indicating any one of one or more pseudo-identifiers, a session key, and a certificate. As shown in 830, the WTRU can send a request message to a first network element of the cellular network, in which the pseudo-identifier of one or more pseudo-identifiers is indicated as the WTRU identifier.

[0143] In various embodiments, the first message may be sent to an intermediate network element for forwarding to the EAP server.

[0144] In various embodiments, the intermediate network element may include any of the other WTRU and base station of the cellular network.

[0145] In various embodiments, the first message may be sent to a first network element of the cellular network for forwarding to the EAP server.

[0146] In various embodiments, the first message may be sent to a second network element of the cellular network for forwarding to the EAP server.

[0147] In various embodiments, the first message may indicate either the first identifier of the WTRU or the second identifier of the WTRU.

[0148] In various embodiments, the first identifier may include the physical identifier of the WTRU, while the second identifier may include the logical identifier of the WTRU.

[0149] In various embodiments, the second message may indicate any one of the timestamps and valid time periods associated with any one of one or more pseudo-identifiers, session keys, and certificates.

[0150] In various embodiments, the second message may indicate more than one pseudo-identifier.

[0151] In various embodiments, the WTRU may send a follow-up request message to the first network element of the cellular network after sending the request message. The request message and the follow-up request message may indicate different pseudo-identifiers among more than one pseudo-identifier.

[0152] In various embodiments, the first network element may include cellular network access and mobility functions.

[0153] In various embodiments, the second network element may include session management functionality of a cellular network.

[0154] In various embodiments, the request message may include a non-access stratum request message.

[0155] In various embodiments, the WTRU may include an environmentally powered Internet of Things (IoT) device.

[0156] In one embodiment, the WTRU may include circuitry comprising any one of a transmitter, a receiver, a processor, and a memory. This circuitry may be configured to perform method 800 according to any of the various embodiments.

[0157] Figure 9 This is a schematic diagram illustrating an example method 900 for authentication and identification management of A_IoT devices. Method 900 can be implemented in a WTRU (e.g., an A_IoT device). As shown in 910, the method may include sending a first message to a first network element of a cellular network. In various embodiments, the first message may indicate an EAP bootstrapping request and a network access identifier of the WTRU. In various embodiments, the network access identifier may be forwarded to an EAP server. As shown in 920, the method may include receiving a second message from the first network element of the cellular network. In various embodiments, the second message may indicate one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers. As shown in 930, the method may include determining, based on the valid time period, that one of the one or more pseudo-identifiers may be valid. As shown in 940, the method may include sending a request message to a second network element of the cellular network based on the validity of the pseudo-identifier, in which the request message indicates the WTRU identifier as the pseudo-identifier.

[0158] In various embodiments, the first network element and the second network element can be the same network element of a cellular network.

[0159] In various embodiments, the first network element and the second network element can be different network elements of a cellular network.

[0160] In various embodiments, the second message may indicate the timestamp of successful WTRU authentication.

[0161] In various embodiments, the second message may indicate more than one pseudo-identifier.

[0162] In various embodiments, method 900 may further include sending a follow-up request message to a first network element of the cellular network after sending the request message. In various embodiments, the request message and the follow-up request message may indicate different pseudo-identifiers among more than one pseudo-identifier.

[0163] In various embodiments, the first network element may include the AMF of a cellular network.

[0164] In various embodiments, the second network element may include an SMF of a cellular network.

[0165] In various embodiments, the request message may include a Non-Access Stratum (NAS) request message.

[0166] In various embodiments, the WTRU may include an environmentally powered Internet of Things (IoT) device.

[0167] Figure 10 This is a schematic diagram illustrating an example method 1000 for A_IoT device authentication and identification management. Method 1000 can be implemented in network elements (e.g., infrastructure) of a cellular network. As shown in 1010, the method may include receiving a first message from a WTRU. In various embodiments, the first message may indicate an EAP bootstrapping request and a network access identifier for the WTRU. As shown in 1020, the method may include sending an EAP message to an EAP server. In various embodiments, the EAP message may indicate a network access identifier for the WTRU. In various embodiments, sending the EAP message to the EAP server may include forwarding the network access identifier of the WTRU to the EAP server. As shown in 1030, the method may include sending a second message to the WTRU. In various embodiments, the second message may indicate one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers. As shown in 1040, the method may include receiving a request message from a WTRU. In various embodiments, the request message may indicate one of the one or more pseudo-identifiers as a WTRU identifier.

[0168] In various embodiments, the network element of a cellular network may include an AMF.

[0169] In various embodiments, the network element of a cellular network may include an SMF.

[0170] In various embodiments, the second message may indicate the timestamp of successful WTRU authentication.

[0171] In various embodiments, the second message may indicate more than one pseudo-identifier.

[0172] In various embodiments, method 1000 may further include receiving a subsequent request message from the WTRU after receiving the request message. In various embodiments, the request message and the subsequent request message may indicate different pseudo-identifiers among more than one pseudo-identifier.

[0173] In various embodiments, the request message may include a non-access stratum request message.

[0174] In various embodiments, the WTRU may include an environmentally powered Internet of Things (IoT) device.

[0175] In various embodiments, method 1000 may further include sending a query request to a unified data management network element. In various embodiments, the query request may indicate any one of a pseudo-identifier that identifies the WTRU and location information associated with the WTRU.

[0176] In various embodiments, method 1000 may further include receiving a query response from a unified data management network element. In various embodiments, the query response may include information associated with a pseudo-identifier of the WTRU.

[0177] In various embodiments, the information associated with the pseudo-identifier of the WTRU may include any one of the device identifier, session key, validity period, and negotiated security algorithm.

[0178] Although not explicitly described, the embodiments described herein can be used in any combination or sub-combination. For example, the principles are not limited to the described variations, and any arrangement of variations and embodiments can be used.

[0179] Furthermore, any features, variations, or embodiments described with respect to the method are compatible with apparatuses including components for processing the disclosed method, with devices including circuitry configured to process the disclosed method comprising any one of a transmitter, receiver, processor, or memory, with computer program products including program code instructions, and with non-transient computer-readable storage media storing program instructions. Additionally, any features, variations, or embodiments described with respect to the WTRU are compatible with network elements of cellular networks (e.g., infrastructure).

[0180] While features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in arbitrary combination with other features and elements. This disclosure is not limited to the specific embodiments described herein, which are intended as illustrative of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from its spirit and scope. Unless expressly stated otherwise, no element, action, or instruction used in the description herein should be construed as essential or indispensable to the invention. Functionally equivalent methods and apparatus within the scope of this disclosure, in addition to those listed herein, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims and the full scope of their equivalents. It should be understood that this disclosure is not limited to any particular method or system.

[0181] For simplicity, the above embodiments are discussed in terms of the terminology and structure of devices with infrared functionality (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0182] It should also 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, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or multiple images displayed on a time base. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE," the term "remote," and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include: (i) a wireless transmit and / or receive unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device equipped with wireless and / or wired (e.g., tetherable) capabilities, configured with some or all of the structure and functions of a WTRU, among other things; (iii) a device equipped with wireless and / or wired capabilities, configured with less than all the structure and functions of a WTRU; or (iv) a similar device. This document refers to Figure 1A-1D Details of exemplary WTRUs that may represent any WTRU described herein are provided. As another example, the various embodiments disclosed above and below are described using a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be used, and that some or all of this disclosure and the various disclosed embodiments can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information for providing an adaptive reality experience.

[0183] Furthermore, the methods described herein can be implemented in computer programs, software, or firmware contained in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to: read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in WTRUs, UEs, terminals, base stations, RNCs, or any host computer.

[0184] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the wide variety of applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include, or be used with, any suitable voltage source such as a battery and the like that provides or can be used with any suitable voltage.

[0185] Furthermore, in the embodiments provided above, note the processing platform, computing system, controller, and other devices including a processor. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions may be referred to as “executed,” “computer-executed,” or “CPU-executed.”

[0186] Those skilled in the art will understand that the behavior and symbolic representation of operations or instructions include manipulation of electrical signals by the CPU. Electrical systems represent data bits, which may result in electrical signal transformations or attenuation and the retention of data bits at their storage locations in memory systems, thereby reconfiguring or otherwise altering the operation of the CPU and other processing of signals. The memory location in which the data bits are held is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that these embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may also support the methods provided.

[0187] Data bits can also be stored on computer-readable media, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems. Computer-readable media can include cooperative or interconnected computer-readable media that exist only on the processing system or distributed across multiple interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that embodiments are not limited to the aforementioned memories, and other platforms and memories may support the provided methods.

[0188] In the illustrative embodiments, any of the operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0189] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software is often (but not always, as the choice between hardware and software may become important in certain contexts) a design choice representing a cost-efficiency trade-off. Various vehicles may exist through which the processes and / or systems and / or other technologies described herein can be implemented (e.g., hardware, software, and / or firmware), and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are critical, the implementer may choose to primarily use a hardware and / or firmware vehicle. If flexibility is critical, the implementer may choose to primarily use a software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0190] The foregoing detailed description has illustrated various embodiments of the apparatus and / or process through the use of block diagrams, flowcharts, and / or examples. Wherever such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will understand 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, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that certain aspects of the embodiments disclosed herein can be equivalently implemented, in whole or in part, in an integrated circuit as: one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing the circuits and / or writing the software and / or firmware code according to this disclosure is entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as a program product in various forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.; and transmission media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0191] Those skilled in the art will recognize that describing devices and / or processes as set forth herein and subsequently integrating such described devices and / or processes into data processing systems through engineering practice is common in the art. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through modest experimentation. Those skilled in the art will recognize that a typical data processing system typically includes one or more of the following: a system unit housing, a video display device, memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, drivers, a graphical user interface, and applications, one or more interactive devices such as a touchpad or touchscreen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or quantities). Typical data processing systems can be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0192] The topics described herein sometimes illustrate different components contained within or connected to different other components. It should be understood that the architectures depicted are merely examples, and many other architectures can in fact be implemented to achieve the same functionality. Conceptually, any arrangement of components used to achieve the same functionality is effectively “associated” so that the desired functionality can be achieved. Therefore, any two components combined in this document to achieve a specific function can be considered “associated” with each other so that the desired functionality can be achieved, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operably coupled components include, but are not limited to: physically pairable and / or physically interacting components, and / or wirelessly interactable and / or logically interactable components.

[0193] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art can convert from plural to singular and / or from singular to plural as needed by the context and / or application. For clarity, various singular / plural permutations may be explicitly described herein.

[0194] Those skilled in the art will understand that, in general, the terminology used herein, and particularly in the appended claims (e.g., the body of the appended claims), is intended to be “open” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will further understand that if the intent is to introduce a particular number of claim statements (recitations), such intent will be explicitly stated in the claims, and without such a statement, such intent does not exist. For example, “single” or similar language may be used where the intent is to include only one item. To aid understanding, the appended claims and / or the description herein may include the use of introductory phrases “at least one” and “one or more” to introduce the claim statements. However, the use of such phrases should not be construed as implying that the introduction of the indefinite article “a” or “an” limits any particular claim that includes such an introduction to only one embodiment of such a claim, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” and “an” (e.g., “a” and / or “an” should be interpreted as meaning “at least one” or “one or more”). This also applies to the use of definite articles used to introduce claim statements. Furthermore, even when a specific number of introduced claim statements is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the number stated (e.g., in the absence of other modifiers, a simple statement of “two statements” means at least two statements, or two or more statements). Furthermore, in cases where conventional expressions such as "at least one of A, B, and C" are used, this construction is generally intended to be interpreted in the sense that a person skilled in the art would understand the conventional expression to be (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). In cases where conventional expressions such as "at least one of A, B, or C" are used, this construction is generally intended to be interpreted in the sense that a person skilled in the art would understand the conventional expression to be (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). A person skilled in the art will further understand that, whether in the specification, claims, or drawings, virtually any extractive terms and / or phrases presenting two or more alternative terms should be understood to consider the possibility of including one, any, or both of the terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Furthermore, the term “any one” preceding a list of multiple items and / or multiple categories of items, as used herein, is intended to include, alone or in combination with other items and / or other categories of items, “any one,” “any combination,” “any number,” and / or “any combination of multiples”. Furthermore, the term “set” 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. And, the term “multiple” as used herein is intended to be synonymous with “a plurality.”

[0195] Furthermore, where features or aspects of this disclosure are described in a Markush group manner, those skilled in the art will recognize that this disclosure is therefore also described in a manner that applies to any individual member or subgroup of that Markush group.

[0196] As those skilled in the art will understand, for any and all purposes, such as providing a written description, all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be decomposed into at least two equal halves, three equal parts, four equal parts, five equal parts, ten equal parts, etc. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “up to,” “at least,” “greater than,” “less than,” etc., includes the listed numbers and refers to a scope that can subsequently be decomposed into subscopes as discussed above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group with 1-3 cells refers to a group with 1, 2, or 3 cells. Similarly, a group with 1-5 cells refers to a group with 1, 2, 3, 4, or 5 cells, and so on.

[0197] Furthermore, unless otherwise stated, the claims should not be construed as limited to the order or elements provided. Additionally, the use of the term "means for" in any claim is intended to invoke 35 USC §112, paragraph 6, or the means-plus-function claim format, and any claim without the term "means for" is not intended to be interpreted in this way.

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: A first message is sent to a first network element of the cellular network, wherein the first message indicates an Extensible Authentication Protocol (EAP) bootstrap request and a network access identifier of the WTRU, and wherein the network access identifier will be forwarded to the EAP server; A second message is received from the first network element of the cellular network, wherein the second message indicates one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers; Based on the effective time period, it is determined that the pseudo-identifier among the one or more pseudo-identifiers is valid; as well as Based on the validity of the pseudo-identifier, a request message is sent to the second network element of the cellular network, in which the pseudo-identifier is indicated as a WTRU identifier.

2. The method according to claim 1, wherein the first network element and the second network element are the same network element of the cellular network.

3. The method according to claim 1, wherein the first network element and the second network element are different network elements of the cellular network.

4. The method according to any one of claims 1 to 3, wherein the second message indicates a timestamp of successful authentication of the WTRU.

5. The method according to any one of claims 1 to 4, wherein the second message indicates more than one pseudo-identifier.

6. The method of claim 5, further comprising sending a follow-up request message to a first network element of the cellular network after sending the request message, wherein the request message and the follow-up request message indicate different pseudo-identifiers among the more than one pseudo-identifier.

7. The method of claim 1, wherein the first network element includes access and mobility functions of the cellular network.

8. The method of claim 1, wherein the second network element includes session management functionality of the cellular network.

9. The method according to any one of claims 1 to 8, wherein the request message includes a non-access stratum request message.

10. The method according to any one of claims 1 to 9, wherein the WTRU comprises an environmentally powered Internet of Things (IoT) device.

11. A wireless transmit / receive unit (WTRU) comprising circuitry including any one of a transmitter, a receiver, a processor, and a memory, wherein the WTRU is configured to: Send a first message to a first network element of the cellular network, wherein the first message indicates an Extensible Authentication Protocol (EAP) bootstrapping request and a network access identifier of the WTRU, and wherein the network access identifier will be forwarded to the EAP server; Receive a second message from the first network element of the cellular network, wherein the second message indicates one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers; Based on the effective time period, it is determined that the pseudo-identifier among the one or more pseudo-identifiers is valid; as well as Based on the validity of the pseudo-identifier, a request message is sent to the second network element of the cellular network, in which the pseudo-identifier is indicated as a WTRU identifier.

12. The WTRU of claim 11, wherein the first network element and the second network element are the same network element of the cellular network.

13. The WTRU of claim 11, wherein the first network element and the second network element are different network elements of the cellular network.

14. The WTRU according to any one of claims 11 to 13, wherein the second message indicates a timestamp of successful authentication of the WTRU.

15. The WTRU according to any one of claims 11 to 14, wherein the second message indicates more than one pseudo-identifier.

16. The WTRU of claim 15, further configured to: after sending the request message, send a subsequent request message to the first network element of the cellular network, wherein the request information and the subsequent request information indicate different pseudo-identifiers among the more than one pseudo-identifier.

17. The WTRU of claim 11, wherein the first network element includes access and mobility functions of the cellular network.

18. The WTRU of claim 11, wherein the second network element includes session management functionality of the cellular network.

19. The WTRU according to any one of claims 11 to 18, wherein the WTRU includes an environmentally powered Internet of Things (IoT) device.

20. A method implemented in a network element of a cellular network, the method comprising: Receive a first message from a Wireless Transmit / Receive Unit (WTRU), wherein the first message indicates an Extensible Authentication Protocol (EAP) bootstrapping request and the network access identifier of the WTRU; Send an EAP message to the EAP server, wherein the EAP message indicates the network access identifier of the WTRU; Send a second message to the WTRU, wherein the second message indicates one or more pseudo-identifiers and a valid time period associated with the one or more pseudo-identifiers; as well as Receive a request message from the WTRU, wherein the request message indicates one or more pseudo-identifiers as a WTRU identifier.

Images