Method for user identifier activation and authentication

Abstract

Systems, methods, and instrumentalities associated with methods for user identifier activation and authentication are disclosed herein. A wireless transmit / receive unit (WTRU) can include a processor. The WTRU can send a first request message. The first request message can include a request to suspend use of a first user identity (UID) or use of a second UID to a first network node. The WTRU can receive a first response message. The first response message can indicate that the first UID has been suspended. The WTRU can send a second request message to the first network node. The second request message can include a request to use the first UID. The WTRU can receive a second response message from the first network node. The second response message can indicate a data connection resume acceptance for the first UID. The WTRU can allow traffic to be sent on a plurality of resumed protocol data unit (PDU) sessions.

Description

Cross-references to related applications

[0001] This application claims the benefit of U.S. Patent Application 63 / 574,514, filed April 4, 2024, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communications using wireless communication continue to evolve. The fifth generation can be called 5G. For example, the previous generation (traditional) mobile communications could be the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This document discloses systems, methods, and means associated with methods for user identifier activation and authentication. A wireless transmit / receive unit (WTRU) may include a processor. The WTRU may send a first request message. The first request message may include a request to a first network node to suspend the use of a first user identifier (UID) or to use a second UID. The WTRU may receive a first response message. The first response message may indicate that the first UID has been suspended. The WTRU may send a second request message to the first network node. The second request message may include a request to use the first UID. The WTRU may receive a second response message from the first network node. The second response message may indicate that data connection for the first UID has been resumed. The WTRU may allow traffic to be transmitted on multiple resumed Protocol Data Unit (PDU) sessions.

[0004] In the example, the first response message may include multiple paused PDU sessions. The device can avoid sending traffic on the multiple paused PDU sessions.

[0005] A first network node may include a processor. The first network node may determine a first User Identifier (UID) associated with a Radio Transmit / Receive Unit (WTRU). The first network node may receive a first request message from the WTRU. The first request message may include a request to use a second UID from a second network node or to suspend the use of the first UID. The first network node may send a first message to the second network node. The first message may indicate to suspend traffic forwarding on multiple Protocol Data Unit (PDU) sessions for the first UID. The first message may include a suspension duration. The first network node may send a second message to a third network node. The second message may indicate that the first UID has been suspended. The first network node may receive a second request message from the WTRU. The second request message may include the request from the WTRU to use the first UID. The first network node may determine that the use of the first UID has been suspended based on the UID status in a user profile. The first network node may send a third message to the second network node. The third message may indicate to resume traffic on the multiple PDU sessions for the first UID. The first network node may send a fourth message to the third network node. The fourth message can indicate that usage of the first UID has been restored. The first network node can send a fifth message to the WTRU. The fifth message can indicate that data connection for the first UID has been restored.

[0006] A first network node may include a processor. The first network node may receive a first request message from a second network node. The first request message may include a request to suspend traffic forwarding for multiple Protocol Data Unit (PDU) sessions targeting a first User Identifier (UID), multiple PDU session identifiers (IDs), and a suspension duration. The first network node may configure a third network node to disallow data traffic for the multiple PDU sessions. The first network node may send a first response. The first response may confirm the suspension of the multiple PDU sessions. The first network node may receive a first message from the second network node. The first message may indicate the resumption of traffic on the multiple PDU sessions targeting the first UID and provide the multiple PDU session IDs. The first network node may configure the third network node to allow data traffic for the multiple PDU sessions. The first network node may reset the suspension duration. The first network node may send a second response to the second network node. The second response may confirm the resumption of the multiple PDU sessions, or, if the suspension duration expires, initiate the release of the multiple PDU sessions.

[0007] A Wireless Transmit / Receive Unit (WTRU) may include a processor configured to send a first request message to a first network node, wherein the first request message may indicate a request to suspend the use of a first User Identity (UID) or a request to use a second UID. Upon receiving a first response message from the first network node indicating that the first UID has been suspended, the WTRU may send a second request message to the first network node requesting the use of the first UID. The WTRU may receive a second response message from the first network node indicating that a data connection for the first UID has been resumed and, based on the resumption, a data message may be sent using a resumed Protocol Data Unit (PDU) session. In an example, the first response message may identify a plurality of suspended PDU sessions associated with the first UID. If the WTRU determines that a second data message is intended for a suspended PDU session among the plurality of PDU sessions, the WTRU may block the transmission of the second data message until the PDU session has been resumed. In an example, the WTRU may receive an authentication and authorization request from the first network node, wherein the authentication and authorization request indicates that the WTRU may perform an authorization process based on the second UID.

[0008] A first network node may include a processor configured to receive a message from a WTRU requesting the use of a first UID. The first network node may determine that the use of the first UID has been suspended based on the UID state associated with a user profile. The first network node may identify a second network node associated with the first UID. The first network node may send a message to the second network node requesting the resumption of traffic on the PDU session associated with the first UID. The first network node may send a message to the WTRU instructing the resumption of data connection acceptance for the first UID. This message may indicate the PDU session associated with the first UID. In an example, the first network node may determine that the first UID and the second UID of the WTRU are bound to a subscription. The first network node may receive a message from the WTRU requesting the suspension of the first UID (or requesting the use of the second UID), and in response, may send an instruction to the second network node to suspend traffic forwarding on the relevant PDU session. In an example, the first network node may notify the third network node that the first UID has been suspended.

[0009] A first network node can be configured to receive a message from a second network node requesting the resumption of traffic on a PDU session associated with a first UID. The first network node can determine the pause duration of the PDU session and then send a message to a third network node requesting the resumption of data traffic for the PDU session. The first network node can send a message to the second network node indicating whether the PDU session has been resumed, or, if the pause duration has expired, whether the PDU session can be released. The first network node can also receive a message from the second network node requesting the suspension of traffic forwarding for the PDU session. Attached The first network node can specify an appropriate pause duration and can forward the pause request to the third network node. The first network node can also send a message to the WTRU indicating that the PDU session has been paused. Attached Figure Description

[0010] Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments.

[0011] Figure 1B This illustrates the possibility of implementation according to an embodiment. Figure 1A The system diagram shows an exemplary wireless transmit / receive unit (WTRU) used in the communication system.

[0012] Figure 1C This illustrates the possibility of implementation according to an embodiment. Figure 1A The system diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used in the communication system shown.

[0013] Figure 1D This illustrates the possibility of implementation according to an embodiment. Figure 1A The system diagram shows another exemplary RAN and another exemplary CN used in the communication system shown.

[0014] Figure 2 This is a flowchart illustrating the (re)activation of the UID during the registration process (authentication performed outside the registration process).

[0015] Figure 3 This is a flowchart illustrating the (re)activation of the UID during the registration process (which involves authentication within the registration process).

[0016] Figure 4 This is a flowchart illustrating an example of a process for user (re)activation, where the SMF can act as an authenticator to the AAA server.

[0017] Figure 5 This is a flowchart showing the suspension of UIDs during the registration process (which includes authentication within the registration process).

[0018] Figure 6 This is a flowchart illustrating the process of restoring a UID during the registration process (e.g., authentication within the registration process).

[0019] Figure 7 It is a flowchart showing the activity state of a UID, which can show the active state model. Detailed Implementation

[0020] Figure 1A This diagram illustrates 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 that provides 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 by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT-UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0021] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Any of the WTRUs 102a, 102b, 102c, and 102d may 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 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 MiFi 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.

[0022] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly connect to at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs, home NodeBs, home eNodeBs, gNBs, NR NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0023] Base station 114a may be part of RAN 104 / 113, and 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 in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per 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 sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0024] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which 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).

[0025] 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 use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0026] 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 use Long Term Evolution (LTE) and / or LTE-A Advanced (LTE-A) and / or LTE-A Pro Advanced (LTE-A Pro) to establish air interface 116.

[0027] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0028] 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, for instance, use a dual connectivity (DC) principle to implement both LTE and NR radio access. 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).

[0029] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA 2000 1X, CDMA 2000 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), GSMEDGE (GERAN), etc.

[0030] Figure 1ABase station 114b can be, for example, a wireless router, a home NodeB, a home eNodeB, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), 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 yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA 2000, GSM, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0031] RAN 104 / 113 can communicate with CN 106 / 115, which 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 may have varying 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 in Figure 1A Although not shown, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113 which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0032] CN 106 / 115 can also be used 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, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0034] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive 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 peripheral devices 138, etc. It is understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0035] 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 may be integrated together in an electronic package or chip.

[0036] 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, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another 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.

[0037] Although the transmitting / receiving element 122 is in Figure 1B While described as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may use MIMO technology. Therefore, 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.

[0038] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via various RATs, such as NR and IEEE 802.11.

[0039] The processor 118 of WTRU 102 may 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 may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Additionally, the processor 118 may access information from any type of suitable memory and store data in said 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 identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 (e.g., located on a server or home computer (not shown)) and store data in said memory.

[0040] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can 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.

[0041] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) 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 the air interface 116, and / or determine its location based on the timing of signals received from two or more neighboring 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.

[0042] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0043] WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all of the signals (e.g., signals associated with specific subframes for 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 through hardware (e.g., chokes) or through signal processing by a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, WTRU 102 may include a half-duplex radio, for which the transmission and reception of some or all of the signals (e.g., signals associated with specific subframes for uplink (e.g., for transmission) or downlink (e.g., for reception)) are separate.

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

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

[0046] Each of the eNode-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 UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160C can communicate with each other via the X2 interface.

[0047] 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 (or PGW) 166. While each of the foregoing elements is depicted 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.

[0048] The MME 162 can connect to each of the eNodes B160a, 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, 102b, 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).

[0049] The SGW 164 can connect to each of the eNode-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 eNode Bs, triggering paging when DL data is available to WTRUs 102a, 102B, and 102c, managing and storing the context of WTRUs 102a, 102B, and 102c, etc.

[0050] 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) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0051] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with an IP gateway that serves 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.

[0052] Although WTRU is Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0054] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic entering and / or leaving the BSS. Traffic originating outside the BSS destined for a STA can 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. This peer-to-peer traffic can be sent between the source and destination STAs (e.g., directly between the source and destination STAs) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode cannot have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0055] When using 802.11ac infrastructure operating mode or a similar operating 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 bandwidth of 20 MHz) 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 and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

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

[0057] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segmented parser that divides the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0058] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier in 802.11af and 802.11ah 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 whitespace (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 may support instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities including support for certain and / or limited bandwidths (e.g., only support). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0059] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) 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) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and available.

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

[0061] Figure 1D This is a system 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 wireless technology. RAN 113 can also communicate with CN 115.

[0062] RAN 113 may include gNBs 180a, 180b, and 180c; however, 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 includes 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 gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, 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 on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0063] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable set of parameters. For example, the 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 varying lengths or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute times).

[0064] 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 needing to access other RANs (e.g., eNode-Bs 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, and also with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate essentially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can serve as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0065] 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 fragmentation 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, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0066] 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 may include data networks (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0067] 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 act 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 PDU sessions with different needs), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by WTRU 102a, 102b, and 102c. For example, different 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, and services for Machine Type Communication (MTC) access. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies (such as WiFi)).

[0068] 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 them to route traffic 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.

[0069] UPF 184a and 184b can connect to one or more of gNB 180a, 180b, and 180c in RAN 113 via the N3 interface. This provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 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.

[0070] CN 115 can facilitate communication with other networks. For example, CN 115 may include, or 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 may 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 DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and their N6 interfaces with local data networks (DNs) 185a and 185b.

[0071] Given Figures 1A to 1D and Figures 1A to 1D As described herein, one or more of the functions described with respect to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0072] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may 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. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0073] One or more simulation devices can perform one or more functions (including all 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., tested) 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).

[0074] The term "timer" as used herein can refer to time, time period, time tracking, time period tracking, combinations thereof, and / or similar items. The term "timer expiration" as used herein can refer to determining that the time has occurred or that the time period has expired.

[0075] A Wireless Transmit / Receive Unit (WTRU) may include a processor configured to send a first request message to a first network node, wherein the first request message may indicate a request to suspend the use of a first User Identity (UID) or a request to use a second UID. Upon receiving a first response message from the first network node indicating that the first UID has been suspended, the WTRU may send a second request message to the first network node requesting the use of the first UID. The WTRU may receive a second response message from the first network node indicating that a data connection for the first UID has been resumed and, based on the resumption, a data message may be sent using a resumed Protocol Data Unit (PDU) session. In an example, the first response message may identify a plurality of suspended PDU sessions associated with the first UID. If the WTRU determines that a second data message is intended for a suspended PDU session among the plurality of PDU sessions, the WTRU may block the transmission of the second data message until the PDU session has been resumed. In an example, the WTRU may receive an authentication and authorization request from the first network node, wherein the authentication and authorization request indicates that the WTRU may perform an authorization process based on the second UID.

[0076] A first network node may include a processor configured to receive a message from a WTRU requesting the use of a first UID. The first network node may determine that the use of the first UID has been suspended based on the UID state associated with a user profile. The first network node may identify a second network node associated with the first UID. The first network node may send a message to the second network node requesting the resumption of traffic on a PDU session associated with the first UID. The first network node may send a message to the WTRU indicating that data connection acceptance for the first UID has been resumed. The message may indicate the PDU session associated with the first UID. In an example, the first network node may determine that the first UID and the second UID of the WTRU are bound to a subscription. The first network node may receive a message from the WTRU requesting the suspension of the first UID (or requesting the use of the second UID), and in response, may send an instruction to the second network node to suspend traffic forwarding on the relevant PDU session. In an example, the first network node may notify a third network node that the first UID has been suspended.

[0077] A first network node can be configured to receive from a second network node a message requesting the resumption of traffic on a PDU session associated with a first UID. The first network node can determine the pause duration of the PDU session and then send a message to a third network node requesting the resumption of data traffic for the PDU session. The first network node can send a message to the second network node indicating whether the PDU session has been resumed, or, if the pause duration has expired, whether the PDU session can be released. The first network node can receive from the second network node a message requesting the suspension of traffic forwarding for the PDU session along with an applicable pause duration, and can forward the pause request to the third network node. The first network node can also send a message to the WTRU indicating that the PDU session has been paused.

[0078] User ID (UID) activation with rapid reauthorization capability can be provided. The authenticator can perform authentication and / or authorization processes with a wireless transmit / receive unit (WTRU) that requests to use the User ID (UID). After the WTRU subsequently requests to use the UID (e.g., after the UID is exchanged on the WTRU, or after the UID is suspended), the authenticator can perform rapid reauthorization of the UID.

[0079] An authenticator can provide access and mobility management (AMF) or session management (SMF) functions. The authenticator can initiate authentication and authorization of a UID (e.g., during registration or a Protocol Data Unit (PDU) session). The authenticator can receive authentication and authorization validity scope information (e.g., access type, time, time of day, location, Public Land Mobile Network (PLMN), etc.) from an authentication server (e.g., an Authentication Server Function (AUSF) or an Authentication, Authorization, and Accounting (AAA) server). The authenticator can store authorization information in the UID's user profile (e.g., a User Data Management (UDM) or User Data Repository (UDR)). The authenticator can send authorization validity scope information to the WTRU. The authenticator can receive requests from the WTRU to use the UID (e.g., after the WTRU switches to an alternative UID or uses the UID on a different access network). The authenticator can check the user profile (UDM / UDR) for valid authentication and authorization results for the UID before triggering the authentication process. The authenticator can authorize the WTRU to use the UID without authentication based on conditions found in the user profile (e.g., in the UDM / UDR) and on the validity of the validity range information (e.g., the authentication validity timer has not expired). When the authentication validity timer expires, or at the request of the authentication server, the authenticator can refresh the authentication and authorization result information of the UID (e.g., in the UDM / UDR).

[0080] WTRU behavior can be provided. The WTRU can receive authorization configurations for UID usage from the Policy Control Function (PCF) or Application Function (AF). These configurations can indicate validity ranges for each UID, such as the context or time in which the WTRU is authorized to use a particular UID (e.g., geographic region, authorized PLMN list, or indication of whether roaming is allowed, access type, etc.). The WTRU can conditionally send a first request to use the UID based on the authorization configuration. Following successful authentication and authorization for the UID, the WTRU can receive authorization data associated with that UID (including validity range information), thereby overriding any existing authorization configurations (validity ranges) associated with that UID. The WTRU can conditionally send a second request to use the UID based on the authorization configuration (e.g., after the WTRU switches to using another UID or on a different access network). The WTRU can receive authorization to use the UID without performing the authentication and authorization process for that UID.

[0081] The AMF can provide the ability to pause and resume UID usage. When there may be an active UID in the WTRU or network (e.g., after authentication and authorization as described above), the AMF can initiate the pause and resumption of traffic for the PDU session used by the UID based on a request from the WTRU to pause the UID or use another UID.

[0082] The AMF can provide AMF behavior. The AMF can receive requests from the WTRU to use another UID and / or suspend the use of that UID. The AMF can continue authentication and authorization for another (e.g., an alternative) UID. The AMF can mark the UID as suspended in the user profile of the UID profile. The AMF can send a message to the SMF serving the UID to suspend traffic forwarding on the PDU session for that UID. The message may include a suspension timer. The AMF can send a message to the Application Function (AF) or Authentication, Authorization, and Accounting (AAA) server indicating that the use of the UID has been suspended. The AMF can send a response to the WTRU including an indication to suspend the UID. The indication may include a list of IDs of suspended PDU sessions. The AMF can receive requests from the WTRU to use or resume the use of the UID (e.g., after suspension, the WTRU can switch use to another UID, which could be an alternative UID). The AMF can determine that the use of the UID has been suspended based on the UID status in the user profile. The AMF can send a message to the SMF serving the UID to restore traffic on the PDU session for that UID. The AMF can also send a message to the AF / AAA server indicating that usage of the UID has been restored. The AMF can send a response to the WTRU including an indication that data connection restoration for the UID has been accepted. This indication may include a list of IDs of the restored PDU sessions. The WTRU can then resume sending traffic on the restored PDU sessions.

[0083] WTRU behavior can be provided. The WTRU can send a request to the AMF to use another UID (e.g., an alternative UID) and / or suspend the use of said UID. The WTRU can receive a response including an indication to suspend said UID. The indication may include a list of IDs of suspended PDU sessions. The WTRU can avoid sending traffic on PDU sessions marked as suspended. The WTRU can send a request to the AMF to use or resume the use of said UID. The WTRU can receive a response including an indication that data connection resumption is accepted for said UID. The indication may include a list of IDs of resumed PDU sessions. The WTRU can allow traffic to be sent on resumed PDU sessions.

[0084] SMF behavior can be provided. The SMF can receive a request message from the AMF to suspend traffic forwarding for one or more PDU sessions for the UID, providing the PDU session ID and a suspension timer. The SMF can configure the User Plane Function (UPF) or Radio Access Network (RAN) to disallow data traffic for the PDU session; this configuration includes canceling or updating any user plane inactivity timers running in the UPF. The SMF can start a suspension timer and send a response acknowledging the suspension of the PDU session. The SMF can receive a message from the AMF to resume traffic on the PDU session for the UID, providing the PDU session ID. The SMF can configure the UPF / RAN to allow data traffic for the PDU session; this configuration includes configuring or updating user plane inactivity timers in the UPF. The SMF can clear the suspension timer and send a response to the AMF acknowledging the resumption of the PDU session, or initiate the release of the PDU session if the suspension timer expires (e.g., before it is resumed by the AMF).

[0085] In systems such as fifth-generation (5G) systems (5GS), a UID authentication architecture can be provided. The examples provided in this article can provide enhancements to support the use of UIDs in systems such as 5G systems. In the examples, such enhancements can allow operators to leverage user-specific identities to provide service delivery tailored to user identities. In one example, the user identity could be the identity of a human using a WTRU, the identity of an application running on a WTRU, or the identity of a device behind a WTRU gateway.

[0086] Service level parameters (e.g., requirements) related to user profiles and user identity can be provided. The architecture assumes that for a given subscription, only one (e.g., just one) UID may be active at a time, and that the UID can be linked to the subscription under operator control (e.g., via API) prior to access. UID state changes (e.g., explicit UID state changes) can be enabled and / or triggered by the AMF or SMF to notify the Network Open Function (NEF) without specifying or describing other possible actions required for UID exchange (e.g., resource release or authentication). Resources used by the first user can be released upon receiving a request to use a second UID. Requests for the second UID to use the PDU session can be rejected if the PDU session has already been used by the first user.

[0087] A secondary authentication process can be provided. This process can involve authentication of the WTRU by a third-party authentication server via intermediate functions (e.g., SMF, AMF, NEF) in the core network (e.g., 5GC). These processes can be referred to as PDU Session Secondary Authentication and Authorization (A&A) and / or Network Slice Specific Authentication and Authorization (NSSAA). The WTRU can use its user identity and credentials during the authentication and authorization (A&A) process before gaining authorized access to network resources (e.g., PDU session, network slice, data network (DN), etc.).

[0088] UID switching capability can be provided. In the example, in situations where UID switching or changes occur frequently (e.g., a human user switching between a personal user profile and a professional user profile on the WTRU, and / or multiple human users actively sharing the WTRU), denying the WTRU's request to change the UID may not be preferred. When UID switching or changes occur frequently, access data connectivity may be denied or unnecessarily delayed for the use of another (e.g., an alternative) UID if locked to the currently active UID. For user experience, allowing the WTRU to switch active UIDs (implicitly or explicitly) may be preferred (e.g., efficiently and seamlessly).

[0089] For example, the authentication and authorization signaling overhead for UID activation may be redundant. Mechanisms for UID activation (e.g., during registration or PDU session establishment) may require (e.g., require) systematic authentication runs between the WTRU and the network / third party. Since this activation may be triggered when the UID is changed or alternated on the WTRU, reactivating the UID may trigger redundant authentication runs. In the example, if the WTRU requests the use of the same UID, the WTRU may trigger another authentication run. In these examples, redundant authentication runs can be prevented to avoid unnecessary signaling overhead and (e.g., excessive) latency in enabling end-user access (reconnection) to the service.

[0090] The session management signaling overhead used for UID activation can introduce latency for end users. The mechanism may propose releasing the network resources (PDU session) of the swapped-out UID for use with another UID. Switching between UIDs may require (e.g., necessitate) re-establishing the PDU session before the WTRU can resume data communication. In this example, frequent releases and re-establishments of PDU sessions can be prevented to avoid unnecessary signaling overhead and latency, allowing end users to access (reclaim) the services of the initially swapped-out UID.

[0091] The example allows for the activation of a UID in a manner that enables fast and efficient network and data connectivity when switching the use of the UID and / or when the UID is connected via one or more access networks.

[0092] The examples described in this article can leverage systems such as 5GS or 6GS to enable rapid reauthorization of UIDs without re-authentication and restoration of data connectivity for linked UIDs.

[0093] In the example, human users may be allowed to activate the use of a UID when exchanging user profiles (e.g., personal vs. business) or connecting via different and / or additional access networks (e.g., WiFi), which results in faster data connection recovery compared to the initial activation of the UID.

[0094] In the example, operators can be allowed to minimize signaling overhead caused by authentication and session management signaling when a UID is temporarily deactivated (e.g., suspended) and then reactivated, or when accessing via a different and / or (e.g., only) additional access network (e.g., WiFi).

[0095] It can provide UID activation with rapid reauthorization capabilities. Figure 2 and Figure 3 An exemplary process for user (re)activation is shown, in which the AMF acts as the authenticator toward the AAA server, and UID authentication is performed both outside and inside the registration process.

[0096] Figure 2 This shows the (re)activation of the UID during the registration process (authentication performed outside of the registration process).

[0097] At position 0, the UID can be linked to the WTRU subscription in the UDM / UDR. The WTRU can be configured with authorization settings for UID usage (e.g., by PCF, AF). The configuration indicates the context / time for each UID, and the WTRU can be authorized to use the specific UID (e.g., authorized PLMN list or indication of whether roaming is allowed, authorized radio access type, authorization validity information (time and location), etc.).

[0098] At point 1, the WTRU can send a registration request message, which includes the UID to be activated. The WTRU can check the configuration to verify whether the WTRU is allowed to use the UID. For example, if the UID may not be allowed when roaming or accessing a specific PLMN or a specific access network type, the WTRU can avoid activating the UID.

[0099] At point 2, the AMF can retrieve subscription data linked to the UID from the UDM / UDR to check if the WTRU is authorized to use the UID. Based on the authorization data retrieved from the UDM / UDR, the AMF can determine whether to initiate UID authentication and authorization. Valid authorization from a previously activated UID may be available (e.g., the UID was exchanged by the WTRU to use another UID (e.g., a replacement UID), or if the WTRU requests to use the UID via an additional access network).

[0100] At point 3, if no valid authorization is found, the AMF sends a registration acceptance message with an indication that authentication and authorization for the UID may be pending, and the AMF can skip initiation at point 4. If a valid authorization is found, the authorization result information can be included in the message. When UID authentication and authorization may be pending at point 4, the WTRU can avoid requesting network services (e.g., PDU sessions, SMS, etc.) regardless of the access network.

[0101] At four points, the AMF can initiate UID authentication and authorization with the AAA server (AAA-S) via the UID Authentication Function (UIAAF). UIAAF can be co-located with the Network Slice Authentication and Authorization Function (NSAAF). Multiple messages (e.g., Extensible Authentication Protocol (EAP)) can be exchanged between the WTRU and AAA via AMF / UIAAF. The AMF can receive A&A results from the AAA, which may include UID authorization data, including validity scope information (e.g., access type, time, time of day, location, PLMN, etc.).

[0102] At point 5, the AMF can update the UDM / UDR with authorized data and can indicate the activity status of the UID.

[0103] At point 6, the AMF can update the WTRU during the WTRU configuration update (UCU) process, providing UID authorization data and an indication of successful UID activation. The WTRU can overwrite existing authorization data associated with the UID (e.g., at point 6, or at point 3 if unauthenticated authorization was performed). The WTRU can request the use of network services (e.g., PDU sessions, SMS on the NAS) based on the UID authorization data.

[0104] Figure 3 This shows the (re)activation of the UID during the registration process (which involves authentication within the registration process). Figure 3 The process can be similar to Figure 2The process is similar to the one described in the original text, but with a few differences. For example, at point 2, the AMF can initiate authentication and authorization at point 3 before sending the results to the registration acceptance message. The AMF does not need to update the WTRU using the UCU process because the authentication and authorization results can be provided directly as part of the registration process at point 5.

[0105] Figure 4 An example of a process for user (re)activation is shown, where the SMF can act as the authenticator to the AAA server. Figure 4 This shows the (re)activation of the UID during the PDU session establishment process.

[0106] At position 0, the UID can be linked to a WTRU subscription in the UDM / UDR. The WTRU can be configured with authorization settings for the use of the UID (e.g., by PCF, AF). These settings can instruct the WTRU to obtain authorization for the specific UID's context / time (e.g., S-NSSAI, DNN, via WTRU to network relay, location, time of day, etc.) for each UID. For example, a UID can be allowed to use S-NSSAI or DNN, which is a subset of the S-NSSAI or DNN in the WTRU subscription.

[0107] At point 1, the WTRU can send a PDU session establishment request message, which includes the UID to be activated. The WTRU can check the configuration to verify whether the WTRU is allowed to use the UID. For example, if the UID is not allowed for a given S-NSSAI or DNN, the WTRU can avoid activating the UID.

[0108] At point 2, the SMF can retrieve subscription data linked to the UID from the UDM / UDR to check if the WTRU can be authorized to use the UID. Based on the authorization data retrieved from the UDM / UDR, the SMF can determine whether to initiate UID authentication and authorization. Valid authorization from a previous activation may be available (e.g., the UID was successfully authorized to use another PDU session).

[0109] At point 3, if no valid authorization is found, the SMF can initiate a UID A&A with the AAA via the UPF or NEF. Multiple messages (e.g., EAP) can be exchanged between the WTRU and AAA via the SMF. The SMF can receive the A&A result from the AAA, which may include authorization data including validity scope information (e.g., location, time, time of day, etc.). If a valid authorization is found, the A&A for the UID at point 3 and the update of the UDM / UDR at point 4 can be skipped.

[0110] At point 4, the SMF can update the UDM / UDR with authorized data and indicate the activity status of the UID.

[0111] At point 5, the SMF can send a PDU session establishment accept message to the WTRU, which provides authorization data (as described above). The WTRU can then begin exchanging traffic on the PDU session based on the authorization data.

[0112] You can pause and resume the use of UID. Figure 5 and Figure 6 Exemplary procedures for user suspension and resumption during the registration process are shown separately. Traffic on the PDU session for the UID can be implicitly suspended when the WTRU requests the use of an alternative UID while the UID is active. A UID can also be suspended when the WTRU sends an explicit request to suspend it (e.g., to fall back to the default subscription settings, where no specific UID is active). Traffic on the PDU session for the UID (e.g., the suspended UID) can be resumed when the WTRU subsequently sends a request to resume using the UID. Details of the UID activity state model (active, suspended, inactive, etc.) can be provided. In the examples, different procedures (e.g., service requests, PDU session modifications) or messages can be provided, including a list of PDU sessions to be activated / suspended within the message.

[0113] Figure 5 This indicates that the UID is paused during the registration process (which includes authentication within the registration process).

[0114] At point 0, UID1 and UID2 can be linked to a WTRU subscription. UID1 can be active (e.g., as shown in the image). Figure 2-4 (As shown). UID2 can be inactive.

[0115] At point 1, the WTRU may send a registration request message that includes the UID2 to be activated (e.g., instead of UID1). The WTRU may also send a registration request message that includes an explicit instruction to suspend UID1, or may not include an instruction and may not include a UID to suspend the UID (e.g., to use the default subscription settings so as not to link to a specific UID).

[0116] At point 2, the AMF can retrieve authorization data from the UDM / UDR (e.g., user profile) and check whether UID2 is authorized (e.g., linked to a WTRU subscription). The AMF can determine that UID1 is active and UID2 is inactive based on the data retrieved from the UDM / UDR and / or UID activity information stored in the WTRU context. The AMF can then initiate a switchover of the active user as follows.

[0117] At point 3, the AMF can initiate UID authentication and authorization for UID2. If a valid authorization for UID2 is found at point 2, the UID A&A process for UID2 can be skipped at point 3.

[0118] At point 4, the AMF can send a request to one or more SMFs serving a PDU session for UID1, providing the SMF context ID, UID1, and an indication that the PDU session may be paused (including a pause timer). For a PDU session (e.g., per PDU session), the SMF (e.g., per SMF) can configure the UPF to disallow traffic for that PDU session; this configuration includes canceling or updating any user plane inactivity timers running in the UPF. The SMF can start a pause timer for the UID PDU session.

[0119] At point 5, the AMF can send a message to the AAA to provide an indication that UID1 may be suspended. For example, a third-party AAA or AF can subscribe to receive notifications of user activity status via the NEF, which can be triggered when the UID status is updated in the UDM / UDR (e.g., at point 6). The AMF can include an indication that UID2 is active in the same or a separate message.

[0120] At point 6, the AMF can send a message to the UDM / UDR providing UID1 and an indication that UID1 may be suspended. The AMF can include an indication that UID2 is active in the same or a separate message. If UID2 was requested at point 1, an A&A can be provided for said UID. If UID2 authorization fails at points 2 or 3, the AMF can send a registration rejection to the WTRU. Regarding the activity status of UID1 in the event of UID2 authorization failure, two options are available. If the AMF decides to keep UID1 active or suspend UID1, the AMF can skip or continue with steps 4-6 respectively. If UID2 authorization fails, the decision to suspend or keep UID1 active can be based on operator policy. If suspended, the WTRU can restore the use of UID1 as described below.

[0121] Figure 6 This demonstrates how to restore the UID during the registration process (e.g., authentication within the registration process).

[0122] At position 0, UID1 and UID2 can be linked to the WTRU subscription. UID1 may be paused, and UID2 may be active (e.g., Figure 5 ).

[0123] At point 1, WTRU can send a registration request message, which includes the requirement to restore the use of UID1.

[0124] At point 2, the AMF can retrieve authorization data from the UDM / UDR. Based on the data retrieved from the UDM / UDR and / or UID activity information stored in the WTRU context, the AMF can determine that UID1 is paused and UID2 is active. The AMF can then initiate a handover of the active user as follows.

[0125] At point 3, the AMF can send a request to one or more SMFs for a PDU session serving UID2, providing the SMF context ID, UID2, and an indication that the PDU session may have been paused, as described above.

[0126] At point 4, the AMF can send a message to the AAA providing an indication that UID2 may be paused. The AMF can send a message to the UDM / UDR providing an indication that UID2 may be paused. The AMF can send a request to one or more SMFs serving a PDU session for UID1, providing the SMF context ID, UID1, and an indication that the PDU session can be activated. For each PDU session (e.g., per PDU), the SMF (e.g., per SMF) can configure a UPF request to allow traffic for that PDU session; this configuration may include configuring or updating a user plane inactivity timer in the UPF. The SMF can also clear pause timers. If a pause timer expires (before it is resumed by the AMF), the SMF can initiate the release of the PDU session.

[0127] AMF can send a message to AAA, which provides UID1, and UID1 may be an indication of activity.

[0128] AMF can send messages to UDM / UDR, which provide UID1, and UID1 may be an indication of activity.

[0129] Pausing and resuming of UIDs based on service request procedures can be provided. A service request procedure initiated by the WTRU can be defined to pause and resume UIDs. The WTRU can trigger a service request procedure to pause the active UID. The service request message may include a second UID (e.g., an alternative UID), which the WTRU can activate. During this procedure, when the WTRU requests the use of the alternative second UID in the service request message, traffic on the PDU session for that UID can be paused.

[0130] The WTRU may include an instruction in the service request message to selectively activate a PDU session for a UID to be activated. The WTRU may include an instruction to selectively suspend a PDU session for a UID to be suspended. The list of PDU sessions (corresponding to activation or suspension) may include all or a subset of the PDU sessions for that UID. The list of PDU sessions to be activated (e.g., corresponding to suspension) may belong to the associated UID to be activated (e.g., corresponding to suspension). The AMF may verify (e.g., corresponding to activation or suspension) whether the list of PDU sessions (e.g., each list) belongs to (e.g., corresponding to activation or suspension) the associated UID. For example, if the list of PDU sessions to be activated (e.g., corresponding to suspension) includes PDU session IDs associated with a UID different from the UID to be activated (e.g., corresponding to suspension), the AMF may reject the request.

[0131] The network (e.g., AMF) can send a service acceptance message to indicate to the WTRU that an alternative UID is active and that the UID is paused. Information about the activated (e.g., corresponding to the paused) PDU session can be sent to the WTRU in the service acceptance message. After the network receives the service request message from the WTRU, at steps 2 through 5 (e.g.) Figure 6 The execution (as described in the text) can also occur on the network side. If the list of PDU sessions to be paused (corresponding to activation) in the service request message is a subset of the PDU sessions of the UID to be paused (corresponding to activation), then the AMF can request one or more SMFs serving the PDU sessions to be paused (corresponding to activation) for the UID to release the remaining PDU sessions of the UID to be paused (corresponding to activation).

[0132] In one example, the WTRU can use other types of NAS control plane signaling messages instead of the registration request message or service request message used for UID activation / suspension (e.g., a UL NAS transport message with a container containing information about activating / suspension of the UID and associated PDU session, or a PDU session modification message indicating activation or suspension of the UID and associated PDU session).

[0133] UID activation management status can be provided. The following UID activation statuses can be used in WTRU and networks (e.g., AMF, UDM / user profile).

[0134] A UID inactive state can be provided. When a UID is not authenticated or authorized, the WTRU and the network can set the UID to an inactive state. A UID inactive state can be provided when the WTRU is not allowed to access or use the network resources of the UID. A UID inactive state can be provided when the WTRU has not established a PDU session for the UID.

[0135] The UID activity status can be provided. When the UID is authenticated and authorized, the WTRU and the network can set the UID to an active state. The UID activity status can be provided when the WTRU is allowed access to and use of the network resources of the UID. The UID activity status can be provided when the WTRU can have a PDU session established and active for the UID.

[0136] A UID pause state can be provided. A UID pause state can be provided when the UID is authenticated and authorized. A UID pause state can be provided when the WTRU is not allowed to access and use the network resources of the UID. A UID pause state can be provided when the WTRU can have a PDU session established and paused for the UID.

[0137] Figure 7 It displays the activity state of the UID, which can show the active state model. Figure 7 This indicates the UID's activity status. In an inactive state, upon request from the WTRU, the WTRU and network can transition the UID to an active state after a successful A&A process for the UID. Activation events can correspond to the WTRU receiving one or more of the following messages: registration or service acceptance, PDU session establishment / modification acceptance, WTRU configuration update, where the network (e.g., AMF or SMF) indicates successful UID activation, etc.

[0138] In an inactive state, if authentication for the UID fails when requested by the WTRU, the UID can remain inactive. An activation rejection event may correspond to a WTRU receiving message (e.g., registration or service rejection, PDU session establishment / modification rejection, where the network indicates that UID activation was unsuccessful).

[0139] In the active state, after a re-authentication and authorization process for the UID fails, a WTRU deregistration process occurs, or UID authorization is revoked, the WTRU and the network can transition the UID state to an inactive state. A deactivation event may correspond to a WTRU receiving a message (e.g., a NAS transport with a re-authentication failure indication, a PDU session release command, a WTRU configuration update, or a deregistration message), where the network (e.g., AMF or SMF) indicates the deactivation of the UID.

[0140] In the active state, the UID can remain active if re-authentication triggered by the network (AMF or SMF) or authentication server (e.g., AUSF or AAA server) is successful. Activation update events can correspond to WTRU receive messages (e.g., PDU session modification acceptance, WTRU configuration update, etc.), where the network (e.g., AMF or SMF) can indicate a successful activation update of the UID.

[0141] In an active state, the WTRU and the network can implicitly transition the UID state to a suspended state after a successful re-authentication and authorization process for a different UID, or explicitly transition the UID state to a suspended state when the WTRU explicitly requests to suspend the use of the UID. Suspension events can correspond to WTRU receiving messages (e.g., registration or service acceptance, PDU session establishment / modification acceptance, WTRU configuration update, etc.), where the network (AMF or SMF) can indicate successful activation for a different UID, or the WTRU sending a request (e.g., registration, PDU session modification, etc.) to explicitly suspend the use of the UID.

[0142] In a suspended state, after a failed re-authentication and authorization process for the UID, a WTRU deregistration process, or a UID authorization revocation, the WTRU and the network can transition the UID state to an inactive state. A deactivation event can correspond to a WTRU receiving a message (e.g., a PDU session release command, WTRU configuration update, deregistration message, etc.) in which the network (AMF or SMF) indicates the deactivation of the UID.

[0143] In a suspended state, the WTRU and network can transition the UID state to an active state upon request from the WTRU. A recovery event can correspond to a WTRU receiving a message (e.g., registration or service acceptance, PDU session establishment / modification acceptance, WTRU configuration update, etc.), where the network (AMF or SMF) indicates a successful resumption of use of the UID.

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

[0145] While the implementations described herein may take into account 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this scenario and can be applied to other wireless systems. For example, although the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and are equally applicable to other wireless systems.

[0146] The processes described above can be implemented in computer programs, software, and / or firmware, which are incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media (e.g., but not limited to internal hard disks and removable disks), magneto-optical media, and / or optical media (e.g., CD-ROM discs and / or DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: Processor, the processor being configured to: Send a first request message to a first network node, wherein the first request message indicates at least one of the following: a request to suspend the use of a first user ID (UID), and a request to use a second UID; Receive a first response message, wherein the first response message indicates that the first UID has been paused; Send a second request message to the first network node, wherein the second request message indicates a request to use the first UID; Receive a second response message from the first network node, wherein the second response message indicates that the data connection for the first UID has been restored; as well as Based on the acceptance of the data connection recovery for the first UID, data messages are sent using the recovered Protocol Data Unit (PDU) session.

2. The WTRU of claim 1, wherein the first response message indicates a plurality of suspended PDU sessions, wherein the suspended PDU sessions are associated with the first UID, and wherein the first UID and the second UID are associated with a subscription.

3. The WTRU according to any one of claims 2 to 3, wherein the data message is a first data message, and wherein the processor is further configured to: Determine that the second data message is associated with a suspended PDU session from the plurality of suspended PDU sessions; and Prevent the sending of the second data message using the suspended PDU session.

4. The WTRU according to any one of claims 2 to 4, wherein the processor is further configured to: Receive an authorization request message from the first network node, wherein the authorization request message indicates a request to perform an authorization process for the WTRU based on the second UID.

5. A first network node, the first network node comprising: Processor, the processor being configured to: Receive a first message from a wireless transmit / receive unit (WTRU), wherein the first message indicates a request to use a first user identifier (UID); Based on the UID status, it is determined that the use of the first UID has been suspended, wherein the UID status is associated with the user profile; Identify the second network node associated with the first UID; Send a second message to the second network node, wherein the second message indicates a request to resume traffic on the Protocol Data Unit (PDU) session associated with the first UID; Send a third message to a third network node, wherein the third message indicates that use of the first UID has been restored; and A fourth message is sent to the WTRU, wherein the fourth message indicates that the data connection for the first UID has been restored.

6. The first network node of claim 5, wherein the fourth message further indicates the PDU session associated with the first UID.

7. The first network node according to any one of claims 5 to 6, wherein the processor is further configured to determine a first UID associated with the WTRU, wherein the first UID is associated with a subscription, and wherein the second UID is associated with the subscription.

8. The first network node according to any one of claims 5 to 7, wherein the processor is further configured to: A fifth message is received from the WTRU, wherein the fifth message indicates at least one of the following: suspending the request to use the first UID, and a request to use the second UID; and A sixth message is sent to the second network node, wherein the second message indicates a request to suspend traffic forwarding on the PDU session associated with the first UID.

9. The first network node according to any one of claims 5 to 9, wherein the processor is further configured to send a seventh message to the third network node, wherein the second message indicates that the first UID has been paused.

10. A first network node, the first network node comprising: Processor, the processor being configured to: Receive a first message from a second network node, wherein the first message indicates a request to resume traffic on a Protocol Data Unit (PDU) session associated with a first User Identifier (UID); Determine the pause duration associated with the PDU session; Send a second message to a third network node, wherein the second message indicates a request to the third network node to resume data traffic for the PDU session; as well as Send a third message to the second network node, wherein the third message indicates at least one of the following: the resumption of the PDU session and a request to release the PDU session if the pause duration has expired.

11. The first network node of claim 11, wherein the processor is further configured to receive a fifth message from the second network node, wherein the fifth message indicates a request to suspend traffic forwarding for the PDU session and the duration of the suspension.

12. The first network node according to any one of claims 11 to 12, wherein the processor is further configured to send a sixth message to the third network node, wherein the sixth message indicates a request for the third network node to suspend data traffic associated with the PDU session.

13. The first network node according to any one of claims 11 to 13, wherein the processor is further configured to send a seventh message to the WTRU, wherein the seventh message indicates that the PDU session has been paused.

Images