Methods, apparatuses, and systems for user identity-based service delivery

Abstract

Methods, apparatuses, and systems for user identity-based service delivery are described herein. A first network node may receive, from a wireless transmit / receive unit (WTRU), a packet data unit (PDU) session establishment or modification request comprising one or more identifiers. The first network node may transmit, to a second network node, a first identifier of the one or more identifiers. The first network node may receive, from the second network node, one or more policy and charging control (PCC) rules associated with the first identifier. The first network node may determine, based on the one or more PCC rules, one or more characteristics of a data flow associated with the first identifier. The one or more characteristics of the data flow may be used to establish or modify a PDU session with the WTRU. The first network node may transmit, to the WTRU, a PDU session establishment accept or modification command.

Description

METHODS, APPARATUSES, AND SYSTEMS FOR USER IDENTITY-BASED SERVICE DELIVERYCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 595,735, filed November 2, 2023, the contents of which are incorporated herein by reference.BACKGROUND

[0002] Wireless communication systems encompass various technologies, such as 802.11 -based systems, cellular networks, and other similar networking systems. However, existing wireless communication systems lack the capability to identify specific users, applications, or devices that use a wireless transmit / receive unit (WTRU) as a gateway. For example, when a WTRU transmits or receives data traffic, the wireless communication system does not possess the awareness to identify the particular user, application, or device using the WTRU as a gateway, nor can it recognize the user, application, or device associated with the traffic flow. Consequently, methods, apparatuses, and systems that facilitate user, application, or device-specific treatment of network traffic are needed.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

[0004] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0005] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0006] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0007] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0008] FIG. 2 is a diagram illustrating an example procedure;

[0009] FIG. 3A is a diagram illustrating an example signal flow;

[0010] FIG. 3B is a continuation of FIG. 2A;

[0011] FIG. 4 is a diagram illustrating an example signal flow;

[0012] FIG. 5 is a diagram illustrating an example signal flow;

[0013] FIG. 6 is a diagram illustrating an example procedure;

[0014] FIG. 7 is a diagram illustrating an example signal flow;

[0015] FIG. 8 is a diagram illustrating an example signal flow; and

[0016] FIG. 9 is a diagram illustrating an example signal flow.DETAILED DESCRIPTION

[0017] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 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), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0018] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0019] The com munications systems 100 may also incl ude a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a,114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0020] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0021] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0022] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

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

[0024] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using NR.

[0025] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0026] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0027] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0028] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0029] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

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

[0031] FIG. 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0032] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

[0038] 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) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0039] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

[0040] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and DL (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 either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

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

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

[0043] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 10, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0044] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements aredepicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0045] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0046] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0047] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0048] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

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

[0050] In representative embodiments, the other network 112 may be a WLAN.

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

[0052] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0053] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0055] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control / Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limitedbandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

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

[0057] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In 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.11 ah is 6 MHz to 26 MHz depending on the country code.

[0058] FIG. 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

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

[0061] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0062] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0063] The CN 106 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0064] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB)access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 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.

[0065] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

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

[0067] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0068] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-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 device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

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

[0071] In wireless communications systems including 802.11 -based systems, cellular systems, and other such networking systems, devices and / or device users may be identified by unique or semi-unique identifiers. For example, a 3rdGeneration Partnership Project (3GPP) wireless device (sometimes referred to as user equipment (UE), a wireless transmit / receive unit (WTRU), smartphone, or by other terms) may store an identifier associated with a user (e.g., human user) of the device (e.g., user ID, account ID, or similar identifier), an application executed by the device (e.g., app ID, process ID, or similar identifier), or a non-3GPP device behind the wireless device (e.g., WTRU). The identifier may be provided to network devices or nodes to allow operators to utilize user-specific identities or device-specific identities in the 3GPP network, such as to provide a service or services based on the user identity, application running on the device, or a device behind a UE gateway (e.g., a non-3GPP device using a 3GPP device as a gateway).

[0072] 3GPP has defined “secondary” authentication procedures whereby a WTRU is authenticated by a third-party authentication server via intermediate functions in the 5GC (e.g., session management functions (SMF), access and mobility functions (AMF), network exposure functions (NEF), or the like), which may be provided by one or more network nodes, computing devices, base stations (e.g., gNBs), access points, or any other such devices. These procedures are known as PDU Session Secondary Authentication and Authorization (PSSAA), Network Slice-Specific Authentication and Authorization (NSSAA), and USS UAV Authorization and Authentication (UUAA). In some embodiments, the WTRU may use a non-3GPP user identity (e.g., a non- 3GPP device identity) and credentials during an authentication and authorization procedure before being granted access to the network resources (e.g., PDU session, network slice, data network (DN)).

[0073] Embodiments for User Plane Remote provisioning of credentials used for NSSAA or PDU Session Secondary A&A are described in versions of the 3GPP TS 23.501 technical standard, which is incorporated herein by reference. In some embodiments, the WTRU establishes a PDU session to access a provisioning server (PVS) to obtain or update the above-mentioned non-3GPP credentials, transparently to the network.

[0074] Similarly, embodiments for an application function (AF) to influence SMF routing and traffic steering decisions, for example, whether and which service function chain(s) (SFCs) to use are described in version of the 3GPP TS 23.502 and 23.501 technical standards, which are incorporated herein by reference. The AF mayinteract with a policy control function (PCF) directly or via a NEF to provide parameters for user plane traffic routing or steering. The PCF may generate or update related policies (e.g., policy and charging control (PCC) rules) which are provided to the SMF serving the relevant WTRU. The procedures may apply to an individual WTRU as a whole or a group of WTRUs. The AF may also utilize provisioning capabilities provided by the network to configure specific QoS information and / or reserve resources for an AF session for a given WTRU by interacting with a PCF directly or via an NEF. The PCF may determine the QoS parameters of the PCC rules based on the information received from the AF and notify the SMF that needs updated policy information.

[0075] Embodiments of security features and mechanisms to support authentication and key management aspects (AKMA) for applications based on subscription credential(s) in a wireless communication system (e.g., a 5G communication system) are described in versions of the 3GPP TS 33.535 technical standard, which are incorporated by reference herein. An AKMA key (KAKMA) may be derived by an authentication server function (AUSF) or another network node (and may also be derived by the WTRU) from an access key (e.g., key for authentication server function (KAUSF)) following a primary authentication procedure. An AF key (KAF) may be derived from the KAKMA by the WTRU and the network node (e.g., an AKMA Anchor Function (AAnF)) and provided by the network to the AF, to be used for secure application layer communication between the WTRU and the AF. A single KAKMA may be established per WTRU and a single KAF may be established per application per WTRU (e.g., a WTRU executing or interacting with a plurality of applications may have or be associated with a corresponding plurality of KAFs).

[0076] A Subscription Permanent Identifier (SUPI) may identify a subscription of a WTRU. In a wireless communication system (e.g., a 5G system), charging for traffic that is sent and received by a WTRU may be based on the SUPI. An International Mobile Subscriber Identity (IMSI) is an example of a type of SUPI.

[0077] In wireless communication systems, when a WTRU sends or receives traffic, the wireless communication systems may not be aware of the identity of the human user associated with the reception or transmission of the traffic. An identifier that identifies the human user in such a scenario may be referred to as a user identifier or ID.

[0078] Similarly, in wireless communication systems, when a WTRU sends or receives traffic, the wireless communication systems may not be aware of the identity of the application that is associated with the reception or transmission of the traffic (e.g., video conferencing, mail, web browsing, remote desktop applications, video games, productivity applications, Al applications, or the like). An identifier that identifies the application in such a scenario may be referred to as a user identifier or ID, application identifier or ID, or an Application Instance Identifier or ID.

[0079] Similarly, in wireless communication systems, when a WTRU sends or receives traffic, the wireless communication systems may not be aware of the device that is associated with the reception or transmission of the traffic via the WTRU. An identifier that identifies the device in such a scenario may be referred to as a user identifier, device identifier, or ID.

[0080] The terms identifier, identification, identity, ID, user identifier, user identification, user ID, device identifier, device identification, device ID, application identifier, application identification, and application ID may be used interchangeably throughout this disclosure. The WTRU, UE, primary device, cellular device, gateway (e.g., Residential Gateway (RG)), or 3GPP device may have the capability to communicate with a wireless communication system (e.g., primary network, 3GPP network, cellular network, or the like). The terms WTRU, UE, primary device, cellular device, and 3GPP device may be used interchangeably throughout this disclosure. The device that uses the WTRU or UE as a gateway (or the device behind the WTRU or UE) may be referred to as a non-primary device, secondary device, non-cel I ular device, or non-3GPP device. The terms user, nonprimary device, secondary device, non-cellular device, and non-3GPP device may be used interchangeably throughout this disclosure. The terms subscription, 3GPP subscription, mobile network operator (MNO) subscription, UE subscription, and WTRU subscription may be used interchangeably throughout this disclosure.

[0081] Additionally, in many such implementations, when a WTRU sends or receives traffic, the wireless communication system (e.g., cellular network, 3GPP network, or the like) may not be aware of the identity of the non-3GPP device that is using the WTRU as a gateway and is associated with the reception or transmission of the traffic. For example, in a scenario where the WTRU is a residential gateway (RG) and a device such as a home automation device uses the RG to connect to the 3GPP network, the 3GPP network may not be aware of the identity of the device (i.e., a home automation device) that uses the WTRU as a gateway. An identifier that identifies the non-3GPP device in such a scenario may be called a User Identifier or ID, or a non-3GPP device identifier or ID.

[0082] When a WTRU is associated with a single SUPI, services can be enhanced if the wireless communication system (e.g., 5G system) is aware of the user that is associated with each traffic flow from / to the WTRU. For example, if the wireless communication system was aware that a traffic flow(s) of the WTRU were associated with a user identifier that is assigned to a first user who pays for premium service levels, the network of the wireless communication system may configure the traffic flows with high priority and / or enable premium or business-oriented traffic steering options (e.g., VPN, antimalware). In another example, if the wireless communication system was aware that a traffic flow(s) of the WTRU were associated with a user identifier that is assigned to another user who pays for discounted service levels, the network of the wireless communication system may configure the traffic flows with a relatively lower priority and / or activate adapted traffic steering options (e.g., parental controls, lossy or lossless compression, or the like). The wireless communication systems that have no such awareness of user identities may not provide such user-specific services, user-specific traffic, user-specific steering options, or the like.

[0083] In some implementations, user identifiers may enable a system operator or administrator (or network device) to be able to identify the traffic to / from the WTRU based on a user identifier. This may enable the network or network devices to provide user-specific traffic treatment (e.g., QoS, N6-LAN traffic steering, or the like) and / or charge at a user level (e.g., rather than a device or WTRU / UE level). This may be particularlyhelpful in implementations in which multiple users use the same device (e.g., multiple users of the same computer or home automation device, multiple users of devices behind the same RG, or the like). To enable this functionality, implementations of the systems, apparatuses, and methods discussed herein may include, but are not limited to: association of user identifiers and other user-specific attributes / parameters with a 3GPP subscription; consideration of user-specific attributes / parameters when delivering a service; user-specific authentication and authorization by the network, including when interworking with third parties; and control of usage of user identifiers (e.g., while roaming, simultaneously active users, or the like).

[0084] In some aspects, the present disclosure is directed to implementations of systems, apparatuses, and methods for using network exposure functions (NEFs) to provide user profile information (e.g., user identifiers, user-specific service settings, or the like) to be linked with a 3GPP subscription or other account. These implementations enable the network to link or unlink user identifiers with a 3GPP subscription or account, and to provide the AF with network-based user credentials (e.g., security keys bound to 3GPP credentials). Such mechanisms enable the network operator to be aware of and control the usage of user identities under a 3GPP subscription for per-user level service treatment. These implementations can also allow the AF to leverage the 3GPP security framework for a higher level of security by enabling cryptographic linkage between the user IDs and the 3GPP subscription (e.g., verified during user ID authentication and authorization). Such implementations can help alleviate the application function (AF) from the burden of managing user-specific credentials (e.g., provisioning or revocation thereof).

[0085] In another aspect, the present disclosure is directed to implementations of systems, apparatuses, and methods in which the network establishes user-specific QoS flows upon WTRU data connection requests (e.g., during PDU session establishment). Such implementations enable the authentication and authorization of each individual user among the one or more users (e.g., with “user” referring to humans, devices, and / or applications executed by computing devices such as WTRU on behalf of humans, devices, applications, or other similar entities) of the WTRU and to apply user-specific treatment of the associated QoS flow(s). The user service authorization and QoS-specific treatment may be performed based on user-specific service settings (e.g., QoS, N6-LAN, authentication and authorization policies, or the like). Such settings may be established during the user ID linkage with the WTRU 3GPP subscription (e.g., based on AF input and / or the network operator policy) and / or may be based on QoS and traffic routi ng / steering parameters provided by an AF using APIs for external parameters provisioning and influence on traffic routing / steering.

[0086] In some implementations, user identifiers linked to a 3GPP subscription may be stored as part of a user profile. The user profile may be maintained by a user profile management function (UPMF) or linked directly to the subscription data in the unified data management (UDM) or unified data repository (UDR) of the network.

[0087] In some aspects, the present disclosure is directed to the implementations of systems, apparatuses, and methods for user ID setup and linkage to a WTRU subscription. In brief overview, in some implementations,a WTRU may establish credentials for a user ID or a plurality of user IDs linked to a WTRU subscription. This may be done during a registration procedure. Linkage of user I D(s) to the WTRU subscription may be performed in the network via one or more network nodes such as exposure by a NEF to an AF. For example, the NEF providing exposure for user ID setup with linkage to a subscription (e.g., an mobile network operator (MNO) subscription) may receive, from an AF, a request adding, removing, or updating user ID(s) to be linked with or that are linked with a subscription (e.g., a 3GPP subscription). The request may include a 3GPP identifier identifying the 3GPP subscription, a list of one or more user IDs, and one or more user-specific service settings parameters. The request may include a notification address to use to notify an AF about user ID-related events (e.g., registered, connected, suspended / resumed, or the like). The NEF may send, to a user profile management function (UPMF), such as a UDM or UDR, the received user IDs and / or settings parameters. The NEF may receive a user ID event from the UPMF including user-related information (e.g., registration status, network-based user credentials, or the like), and may send the user ID-related information to the AF.

[0088] In some implementations, a network node (e.g., an authentication server function (AUSF)) may establish credentials for a user ID linked to a subscription. In some such implementations, the AUSF may receive, from another network node (e.g., an AMF), an authentication request to initiate a WTRU primary authentication. The request may include a 3GPP identifier or device identifier (e.g., SUPI). The AUSF may send, to a UPMF (or UDM or UDR), the authentication request, and may receive, from the UPMF (or UDM or UDR), an authentication response including authentication vectors, an indication of user identifiers usage, and / or a list of user IDs associated with the 3GPP identifier or subscriber. The AUSF may perform an authentication process (e.g., an authentication algorithm) with WTRU (e.g., handshaking, login, or the like) and may generate a network access key (e.g., KAUSF). The AUSF may, in some implementations, generate credentials for each user ID. Such credentials may be derived from the network access key (e.g., KAUSF). The AUSF may send a message to a UPMF (or UDM, or UDR) including the SUPI, list of one or more user IDs, and respective derived credentials to be registered.

[0089] FIG. 2 illustrates an example procedure 200 for user ID setup and linkage to a WTRU subscription, which may be used in combination with any of other embodiments described herein. In some implementations, a WTRU may establish credentials for one or more user ID(s) linked to a subscription during a registration procedure. For example, at 205, the WTRU may send, to a network node (e.g., an AMF), a registration request message. The registration request message may include a user identifier’s usage capability and a list of user IDs that the WTRU wishes to use in relation to the WTRU subscription. At 210, the WTRU may perform an authentication process (e.g., a primary authentication algorithm) with the network (e.g., AUSF via AMF). At 215, the WTRU may generate or receive a network access key such as KAUSF. At 220, the WTRU may receive, from the network node (e.g., AMF), a registration accept message including a list of allowed user IDs. At 225, the WTRU may generate credentials for each user ID. Such credentials may be derived from the network access key (e.g., KAUSF). At 230, the WTRU may use the credentials and corresponding user ID to authenticate with a network node (e.g., an AF) directly or indirectly via a user plane or a network control plane.

[0090] Still describing implementations of systems, apparatuses, and methods for user ID setup and linkage to a WTRU subscription and in more detail, the following description illustrates some embodiments of procedures whereby the operator provides a network exposure API for a network node (e.g., an AF) to register one or more user IDs to be associated or disassociated (e.g., linked or unlinked) with a particular 3GPP subscription. The network may provide the network node (e.g., the AF) with network-generated credentials (e.g., derived from a 3GPP security key) for each of the registered user ID(s), to further enforce linkage between the user ID(s) and 3GPP subscription cryptographically. The WTRU may request from the network the user I D(s) that it wishes to use and generate credentials for the user I D(s) that are allowed by the network. The user ID(s) are then ready to be used between the WTRU, network and the network node (e.g., the AF).

[0091] FIGs. 3A-B illustrates an example procedure 300 for network user ID(s) setup with linkage to a WTRU subscription, which may be used in combination with any of other embodiments described herein. As illustrated in FIG. 3A, a WTRU 302 may include one or more user IDs or user identifiers (e.g., User #1 and User #2). The WTRU 300 may indicate what user IDs or user identifiers it wants to use when the WTRU registers with the network according to some embodiments. The user IDs or user identifiers may have already been linked to the WTRU’s subscription (or the WTRU’s subscription identifier) by an AF 390. For example, the AF 390 may include one or more user IDs or user identifiers (e.g., User#1 and User #2) linked to the WTRU’s subscription.

[0092] At 304, in some embodiments, one or more user IDs are established between the WTRU 302 and the AF 390 (e.g., multiple users of an application). The WTRU may be configured to be used by multiple human users (e.g., multiple household members, multiple employees in a plant, or the like). The WTRU may be configured with multiple applications to be treated as different users (e.g., with different QoS, traffic steering requirements, or the like). The WTRU may be configured with multiple devices (e.g., multiple home automation devices, multiple non-cellular devices, multiple non-3GPP devices, or the like) that uses the WTRU as a gateway.

[0093] At 306, in some embodiments, the AF 390 may register one or more user IDs associated with a 3GPP identifier (e.g., GPSI / SUPI). The AF 390 may provide per-user settings (e.g., QoS or traffic steering requirements) and common or default settings common to all users. The AF 390 may indicate that it wishes to use network generated-credentials for the user. Examples of AF-provided settings may include any of:• Applicable restrictions on usage of a user ID (e.g., blocked / allowed while roaming, restricted to a geographical area and / or time of day, maximum simultaneous active users). Maximum global simultaneous active users may also be set by the operator for a given WTRU regardless of the applications based on operator policy.• An authentication and authorization policy, which may indicate whether a secondary authentication / authorization via the network is required for a user ID (e.g., a “primary” user (e.g., owner / operator of WTRU) may not be subjected to such authentication while “secondary” users may need to be authenticatedas per policy); and or whether and how a user ID usage may be suspended or resumed (e.g., based on inactivity threshold event and / or WTRU going / coming from an idle state); and• Resources authorized for a user ID (e.g., DNN, network slice, or the like).

[0094] The AF 390 may send its request at 306 via an NEF 388 or directly (e.g., if within the operator trust domain) to a user profile management function (UPMF) 386. The UPMF 386 may be co-located with a UDM / UDR. In other words, data that is associated with the UPMF 386 may be stored in the UDR and access to information that is associated with the UPMF 386 may be provided by the UDM. At 308, in some embodiments, the UDM may store and / or update (e.g., add or remove) the user ID(s) information and link it with the 3GPP subscription identified by the AF-provided 3GPP ID. At 310, in some embodiments, the UPMF 386 may send a response message (e.g., via NEF 388) to the AF 390 confirming successful linkage of the user ID(s) information with the 3GPP subscription. The AF 390 may register for notification for user-related events by providing a notification address (e.g., URL), which the network may use to inform the AF 390 about user ID- related events (e.g., user ID credentials update, user ID registered, connected, suspended / resume, or the like). The WTRU 302 may be informed by the AF 390 of the successful linkage of a user ID(s) with the WTRU subscription.

[0095] In some embodiments, the WTRU 302 may use one or more user IDs configured from 304 and linked to a 3GPP subscription at 306-310, for example, to obtain authenticated services or access to various application functions. At 312, in some embodiments, the WTRU 302 may send a registration request to a network node (e.g., AMF) including its user level identification capabilities and a list of requested user ID(s). Along with the registration request, the WTRU 302 may send its application / service name, location, etc. The list of user ID(s) may be a subset of the user IDs configured on the WTRU 302. The list may be a list of user identifiers for which the WTRU 302 is aware of their existing linkage to its 3GPP subscription (e.g., based on a message from the AF 390 as in 306 and / or from a prior registration procedure as described herein). This registration request may be triggered by the WTRU 302 when it detects uplink application traffic from an application / device (e.g., non-3GPP device) and the application / device is associated with a user ID, at the time of powering up and starting the applications / devices, in response to a change of users of the WTRU 302, in response to a change in location, etc.

[0096] At 314, the AMF 382 may initiate a primary authentication of the WTRU 302 by the AUSF 384. At 316, in some embodiments, the AUSF 384 may request authentication vectors from the UDM. At 318, the AUSF 384 may receive a list or identification of user IDs that are authorized for use by the WTRU 302. The AUSF 384 may receive, from the UDM, a list of authorized user IDs. The AUSF 384 may request the list of authorized user IDs in a separate request to the UDM / UPMF 386. In implementations or situations in which the WTRU 302 is already authenticated, 314-318 may be skipped (or may have been performed at an earlier time).

[0097] Following the successful primary authentication and / or reception of the list of authorized user IDs at 320 and / or 322, in some embodiments, the WTRU 302 and / or AUSF 384 may generate user ID-specificcredentials. For example, for each user ID, a user ID key (KUI) may be derived using KAUSF and the user ID as input. In another embodiment, the KUI may be derived from an AKMA Key (KAKMA). For example, the KUI may be the output of a hash function using an input of the KAUSF and the user ID. In some cases, additional information may be used to derive the KUI, such as a time or date field, a synchronization field, a nonce or any other additional source of cryptographic salt.

[0098] At 324, in some embodiments, the AUSF 384 may register the derived credentials for the authorized user IDs with the UDM / UPMF 386 using the linked WTRU subscription identifier (e.g., SUPI). For example, in some embodiments, the AUSF 384 may use a AKMA Anchor (AAnF) function to register the user IDs. In such embodiments, the AAnF may be in charge of generating the per-user ID credentials described in 320 and 322.

[0099] At 326, in some embodiments, the UDM / UPMF 386 (or AAnF) may send a notification (e.g., via NEF 388) to the AF 390 registered for user ID events to inform the AF 390 of the availability of user credentials. At 328, the AF 390 may store the received credentials with the corresponding user IDs and confirm reception in a response message to the NEF 388 at 330.

[0100] The AF 390 may use the network-provided credentials to authenticate the user / device via the network control plane or at the application layer Over The Top (OTT). In the latter case, the AF 390 may inform the network of successful authentication and authorization and indicate requirements for traffic treatment for the identified AF session. Following reception of the final authentication message from the AUSF 384, at 332, the AMF 382 may request, and at 334, the AMF 382 may receive subscription data and identification of user IDs that are authorized for the WTRU 302 (e.g., a list of authorized user IDs). The UDM / UPMF 386 may update the user profile based on the user context information received as part of the registration message. For example, the AMF 382 may provide the UDM / UPMF 386 with the information about the user IDs that were allowed for the WTRU (e.g., as part of AMF registering as serving AMF 382 in the UDM).

[0101] At 336, in some embodiments, the AMF 382 may send a registration accept message including the allowed user IDs. Non-authorized user IDs may be sent as rejected user IDs in some embodiments. The AMF 382 may include validity scope information for each of the user IDs (e.g., time or location area validity). The AMF 382 may send a registration reject message including a reject code or reason.

[0102] At 338, the WTRU 302 may store the allowed user IDs. In some embodiments, the WTRU 302 may generate the credentials for the allowed user IDs at this stage (instead of at 320 and / or 322).

[0103] FIG. 4 illustrates an example procedure 400 for network user ID setup with linkage to WTRU subscription, which may be used in combination with any of other embodiments described herein. For example, an AF 490 may set up or update the network user ID(s) with linkage or un-linkage from a WTRU subscription. The WTRU 402 may be already registered and allowed to use one or more user IDs, as described above, in connection with FIG. 3A-B.

[0104] At 404, in some embodiments, one or more user IDs are established between the WTRU 402 and the AF 490 and the WTRU 402 has registered the user IDs it wishes to use, as described above in connectionwith FIG. 3A-B. At 406, the AMF may be subscribed with UDM / UPMF 486 to be notified of updates (e.g., add, remove, modify, or the like) related to user IDs linked to the WTRU subscription.

[0105] In some embodiments, the AF 490 may register one or more user IDs associated with a 3GPP identifier (e.g., GPSI / SU PI) as described above. For example, at 408, the AF 490 may request linkage of one or more user ID with a 3GPP subscription identified by the given 3GPP identifier (e.g., GPSI / SUPI). The AF 490 may request to add, update or remove / unlink a user ID with respect to the WTRU subscription. At 410, the UDM / UPMF 486 may update the list of user IDs, and at 412 may respond with a confirmation to the AF 490.

[0106] At 414, in some embodiments, the AMF 482 may receive a notification from UDM / UPMF 486 of the updated list of authorized user IDs. For example, a user ID may have been revoked or removed from the registered / authorized user at 408-412. The AMF 482 may determine that the WTRU 402 needs to be updated accordingly.

[0107] At 416, in some embodiments, the AMF 482 may initiate a WTRU configuration update or WTRU policy update (UPU) procedure indicating a change of user IDs. The AMF 482 may provide an identification or list of updated allowed user IDs and / or non-authorized user IDs (e.g., sent as rejected user IDs). In some embodiments, the AMF 482 may include for each rejected user ID a cause code indicating a reason for rejection (e.g., user not authorized, usage restriction limit, or the like). The AMF 482 may indicate that the WTRU 402 needs to re-register (e.g., to update the list of allowed user IDs).

[0108] At 418, in some embodiments, the WTRU 402 may perform the registration procedure (e.g., as described above in connection with FIG. 3A-B) to obtain a new list of allowed user IDs and establish related credentials.

[0109] In some aspects, the present disclosure is directed to a wireless transmit / receive unit (WTRU), comprising one or more processors, and one or more transceivers configured to communicate via a network. The one or more processors are configured to transmit, via the one or more transceivers to a network node or network device providing an access and mobility function (AMF), a registration request. The registration request may comprise one or more user identifiers associated with the WTRU. The one or more processors and the one or more transceivers may perform an authentication process with an authentication server function (AUSF) provided by the network device or a second network device. The authentication process may generate a network access key. The one or more processors may receive, via the one or more transceivers from the AMF, a registration acceptance message. The registration acceptance message may comprise one or more allowed user identifiers of the one or more user identifiers associated with the WTRU. The one or more processors may generate authentication credentials for a first user identifier of the one or more allowed user identifiers based on the first user identifier and the generated network access key. The one or more processors and the one or more transceivers may exchange data with the network. The data may be protected (e.g., for integrity, confidentiality, or against replay) with keys generated using the authentication credentials for the first user identifier.

[0110] In some implementations, the one or more user identifiers associated with the WTRU are each associated with a different user, device, or application of the WTRU. In a further implementation, the data exchanged with the network is associated with a first user, a first device, or a first application of the WTRU associated with the first user identifier. In some implementations, the registration request may further comprise a user identifier usage capability of the WTRU. In some implementations, the generated network access key may not be transmitted via the network.

[0111] In some implementations, the one or more processors are further configured to generate second authentication credentials for a second user identifier of the one or more allowed user identifiers based on the second user identifier and the generated network access key. The one or more processors and the one or more transceivers may exchange second data with the network. The second data may be protected with keys generated using the second authentication credentials for the second user identifier.

[0112] In another aspect, the present disclosure is directed to a method. The method includes transmitting, by a wireless transmit / receive unit (WTRU) to a network device providing an access and mobility function (AMF), a registration request. The registration request may comprise one or more user identifiers associated with the WTRU. The method also includes performing, by the WTRU, an authentication process with an authentication server function (AUSF) provided by the network device or a second network device. The authentication process may generate a network access key. The method also includes receiving, by the WTRU from the AMF, a registration acceptance comprising one or more allowed user identifiers of the one or more user identifiers associated with the WTRU. The method also includes generating, by the WTRU, authentication credentials for a first user identifier of the one or more allowed user identifiers based on the first user identifier and the generated network access key. The method also includes exchanging data, by the WTRU with at least one other network device. The data may be protected with keys generated using authentication credentials for the first user identifier.

[0113] In some implementations, the one or more user identifiers associated with the WTRU are each associated with a different user, device, or application of the WTRU. In a further implementation, the data exchanged with the at least one other network device is associated with a first user, a first device, or a first application of the WTRU associated with the first user identifier. In some implementations, the registration request may further comprise a user identifier usage capability of the WTRU. In some implementations, the generated network access key may not be transmitted via the network.

[0114] In some implementations, the method includes generating second authentication credentials for a second user identifier of the one or more allowed user identifiers based on the second user identifier and the generated network access key. The method may also include exchanging second data with the at least one other network device. The second data may be protected with keys generated using the second authentication credentials for the second user identifier.

[0115] In another aspect, the present disclosure is directed to a network device or a network node, comprising one or more processors providing a network exposure function (NEF). The one or more processors may be configured to receive, from an application function (AF) provided by the network device or a second network device, a request comprising an account or subscription identifier, one or more user identifiers to be linked with the account identifier, and for each of the one or more user identifiers, one or more user-specific service settings parameters. The one or more processors may record, via a user profile management function (UPMF) in a unified data repository, the received one or more user identifiers. The one or more processors may monitor the UPMF for events related to the one or more user identifiers. Responsive to receipt of an indication of an event comprising a fi rst user identifier of the one or more identifiers, The one or more processors may transmit the first user identifier and associated information corresponding to the event to the AF.

[0116] In some implementations, the one or more processors may be further configured to transmit the indication of the event. In some implementations, the UPMF may be provided by the network device, the second network device, or a third network device. In some implementations, the one or more processors may be configured to transmit a subscription for events related to the one or more user identifiers to the UPMF.

[0117] In another aspect, the present disclosure is directed to a method. The method includes receiving, by a network device providing a network exposure function (NEF) from an application function (AF) provided by the network device or a second network device, a request comprising an account identifier, one or more user identifiers to be linked with the account identifier, and for each of the one or more user identifiers, one or more user-specific service settings parameters. The method also includes recording, by the network device via a user profile management function (UPMF) in a unified data repository, the received one or more user identifiers. The method also includes monitoring, by the network device, the UPMF for events related to the one or more user identifiers. The method also includes responsive to receipt of an indication of an event comprising a first user identifier of the one or more identifiers, transmitting, by the network device, the first user identifier to the AF.

[0118] In some implementations, the method includes transmitting the indication of the event. In some implementations, the UPMF is provided by the network device, the second network device, or a third network device. In some implementations, the method includes transmitting a subscription for events related to the one or more user identifiers to the UPMF.

[0119] In another aspect, the present disclosure is directed to implementations of systems, apparatuses, and methods for authentication and authorization of a user ID linked to a WTRU subscription for user-specific QoS flows establishment or a user-specific data flow establishment. The present disclosure is also directed to implementations of systems, apparatuses, and methods for authentication and authorization of a user ID linked to a WTRU subscription for device-specific QoS flow establishment or a device-specific data flow establishment. The device herein may refer to a non-cellular or non-3GPP device that uses a WTRU as a gateway. The present disclosure is also directed to implementations of systems, apparatuses, and methods forauthentication and authorization of a user ID linked to a WTRU subscription for an application-specific QoS flow establishment or an application-specific data flow establishment. The application herein may refer to an application that operates in a non-cellular or non-3GPP device that uses a WTRU as a gateway. In brief overview, in some embodiments, a network node such as an SMF may establish user-specific QoS flows for a user ID linked to the WTRU subscription during a PDU session establishment or modification procedure. The network node (e.g., the SMF) may assign QoS flow(s) to the user ID following successful authentication and authorization of the user ID by an AF. The terms user-specific QoS flow and user-specific data flow, devicespecific QoS flow, and device-specific data flow may be used interchangeably throughout this disclosure.

[0120] In some embodiments, the network node (e.g., SMF) may establish user-specific QoS flows with user ID authentication by another network node (e.g., AF) during a PDU Session establishment or modification procedure. In some such embodiments, the SMF may receive, from a WTRU, a PDU session establishment / modification request message including one or more user IDs. The SMF may retrieve the subscription data linked to the user ID (e.g., user profile) from UDM / UPMF. The SMF may determine whether the user ID needs to be authenticated and authorized based on user ID linked subscription data (e.g., no valid prior authorization required by authentication policy for User ID). The SMF may initiate authentication and authorization of the user ID by the AF or operator authentication server. The SMF may assign QoS flow indicators (QFI(s)) specific to the user ID or the authorized user ID. The SMF may derive the characteristics of the user’s QoS flow based on the user profile information received from the UDM / UPMF or based on userspecific PCC rules received from a PCF. The SMF may configure the user plane of the PDU session (UPF / RAN) for the user-specific QoS flows. The SMF may send a PDU session establishment accept / modification command message including authentication and authorization result (if any), and / or QoS rules for the user ID traffic handling.

[0121] Still discussing embodiments of authentication and authorization of a user ID linked to a WTRU subscription and user-specific QoS flow establishment, and in more detail, implementations of the systems, apparatuses, and methods illustrate procedures whereby the user ID linked to a WTRU subscription is authenticated and authorized by an authentication server (e.g., AF) via a network function acting as an authenticator (e.g., SMF). The WTRU may request a data connection for a particular user, device, or application in a PDU session establishment or modification procedure. The SMF may verify the network authorization for usage of the user ID from the linked subscription data before initiating the authentication and authorization by the AF. Once the user ID authentication is completed successfully, the SMF may establish one or more QoS flows (e.g., QFIs) dedicated to the user (e.g., a non-cellular device, a non-3GPP device, or the like) within the PDU session. Multiple users may share the same PDU session with each user ID being assigned its unique QFIs and associated packet filtering and traffic steering configurations in the network (e.g., RAN, UPF) and the WTRU, established according to the user-specific service settings. The data traffic received and sent from the WTRU for a particular user (e.g., human, device, or application) may receive the appropriate treatment and any applicable charging.

[0122] FIG. 5 illustrates an example procedure 500 for user-specific QoS flow establishment during a PDU session establishment or modification procedure, which may be used in combination with any of other embodiments described herein. At 504, a WTRU 502 has registered one or more user IDs (e.g., User #1 and User #2) linked with a WTRU subscription, as described above, in connection with FIGs. 3A-B. The user IDs may be linked to the WTRU subscription using a request or assistance from an AF 590. The authorized user IDs may be linked directly by the operator with the 3GPP subscription and configured in the WTRU (e.g., UICC) and / or provisioned via a PCF. Examples of such pre-configured user IDs may be operator-managed user IDs, such as those for multiple household members sharing a common subscription / WTRU or multiple home automation (or security) devices using the WTRU as a gateway.

[0123] The WTRU may wish to establish a data connection for a particular user ID (e.g., triggered by a particular application, device, or human user action on the WTRU). At 506, in some embodiments, the WTRU may send a PDU session establishment / modification request to an SMF 583 including a user ID. The request may include more than one user IDs. In that case, the following processes may be performed for each user ID. The user ID may be included in the NAS message for the AMF (not shown in FIG. 5) to verify whether the user ID is authorized based on the authorization policy (e.g., whether simultaneous active users reached for the WTRU, or WTRU location or roaming policy permits it, or if DNN / slice is authorized for the user ID).

[0124] At 508, in some embodiments, the SMF 583 may retrieve the subscription data linked to the user ID from UDM / UPMF 584 to check the user ID session management authorization and settings for the user ID. At 510, the SMF 583 may determine whether the user IDs need to be authenticated and authorized (e.g., authentication and authorization may be required if no available authorization is found and an authentication policy requires (e.g., secondary) authentication and authorization of the user ID (e.g., by the AF 590)). Based on operator policy and user IDs settings, the SMF 583 may decide to set up a separate PDU session for each user ID (e.g., not mix QoS flows from different users inside the same PDU Session). In that case, user-specific traffic detection and charging can be done based on the PDU session used to transport that traffic. In that scenario, the SMF 583 may reject a PDU session modification for a user ID while another user ID may already be using the PDU session, in some embodiments providing a cause code (e.g., user ID not authorized to use existing PDU session). In response, the WTRU 502 may request a new PDU session to be established for the user ID.

[0125] At 512, in some embodiments, a secondary authentication procedure may be performed where the user ID is sent as the identity to the AF 590. For example, the secondary authentication procedure may be performed on a condition that the SMF 583 determines that the user IDs need to be authenticated and authorized further. Multiple authentication messages may be exchanged between the WTRU 502 and AF 590 via SMF 583 (e.g., via UPF or NEF 586) at 514. The WTRU 502 and AF 590 may use network-based credentials (e.g., cryptographically bound to the 3GPP subscription credentials) during the procedure. Alternatively or additionally, the user ID authentication may be performed by an authentication server residing in the network (e.g., AUSF). For example, an enhanced EAP-AKA’ procedure may be used whereby the user ID and itscredentials are used to authenticate the user (instead of SUPI and WTRU long-term key). At 516, an authentication response may be provided to the SMF 583.

[0126] At 518, in some embodiments, once the user ID is authorized or if authorization is not required, the SMF 583 may assign QFI(s) specific to the user ID. Each QFI being unique in the PDU session for a given QoS flow may allow the network node (e.g., SMF, UPF) to identify the traffic sent to / received from the WTRU 502 associated with the user ID. The SMF 583 may derive the characteristics of the user’s QoS Flow based on the user profile information that was obtained from the UDM / UPMF. Note that the SMF 583 may receive policies from a network node such as a PCF (not shown in FIG. 5) that are associated with the WTRU’s subscription (e.g., SUPI). The SMF 583 may also receive a 5GS subscribed QoS profile from a network node such as a UDM and the 5GS subscribed QoS profile may be associated with the WTRU’s subscription (e.g., SUPI). Since the SMF 583 is notified that the traffic is associated with a user ID, the SMF 583 may choose to derive the QoS rules for the traffic based on information that is received from the UDM / UPMF 584 and associated with the user ID. Since the SMF 583 is notified that the traffic is associated with a user ID, the SMF 583 may also decide not to derive the QoS rules based on the 5GS subscribed QoS profile, which is associated with the WTRU’s SUPI and to not derive the QoS rules based on the policies that were received from the PCF and associated with the SUPI. In other words, in some embodiments, the QoS rules for the traffic may be derived based only on the information that is received from the UDM / UPMF 584 and associated with the user ID corresponding to the traffic, rather than any other rules or policies associated with the user or device or subscriber profile.

[0127] At 520, the SMF 583 may create a policy association with a network node such as a PCF (not shown in FIG. 5). For example, the SMF 583 may provide the user ID to the PCF and receive, from the PCF, corresponding user-specific PCC rules / packet filters for the given user ID. The PCC rules that are obtained from the PCF may also be used to derive the characteristics of the user’s QoS flow and / or traffic routing / steering parameters for the user’s service data flow. The SMF may retrieve the user-specific PCC rules / packet filters at 520. The SMF may assign an associated QFI for the user’s QoS flow at 518. For example, once the user ID is authorized or if authorization is not required, the SMF 583 may initiate a policy association with the PCF as described above. At 522, the SMF 583 may configure the user plane (e.g., RAN, UPF, or the like) for the userspecific QoS flows (e.g., with the QFI). The PCC rules may include the user ID information for the proper user plane detection of and proper charging for a service data flow for the specified user ID. If the AF 590 has subscribed to user-specific events from the network, the AF 590 may be notified by PCF / NEF 586 of the activation of user-specific service data flows (e.g., with applied QoS and traffic steering info).

[0128] At 524, in some embodiments, the SMF 583 may provide, in a PDU session establishment accept / modification command, the authentication and authorization result to the WTRU 502 along with QoS rules adapted for the QoS flows specific to the user ID indicated in step 506. If the WTRU 502 is not authorized to use the user ID, then the SMF 583 may instead send a PDU session establishment rejection message, which may include a cause code indicating reason for rejection (e.g., user not authorized, usage restriction limit, or the like).

[0129] At 526, in some embodiments, data traffic sent to / received from the WTRU 502 may be detected, and per-user ID treatment and charging may be applied.

[0130] FIG. 6 illustrates an example procedure 600 for user-specific data flow establishment during a PDU session establishment or modification procedure, which may be used in combination with any of other embodiments described herein. At 605, a first network node may receive, from a WTRU, a PDU session establishment or modification request. The WTRU may have the capability to communicate with a wireless communication system such as a primary network, a 3GPP network, a cellular network, and a Wi-Fi network. For example, the WTRU may be a cellular device or a 3GPP device. The PDU session establishment or modification request may include one or more identifiers. The one or more identifiers may be associated with one or more devices. The one or more devices may be connected to the WTRU. For example, the one or more device may be connected wirelessly to the WTRU. The one or more devices may use the WTRU as a gateway. The one or more devices may be referred to as non-primaiy devices, secondary devices, non-cellular devices, or non-3GPP devices. The one or more devices may or may not have the capability to communicate directly with a wireless communication system such as a primary network, a 3GPP network, a cellular network, and a Wi-Fi network. The one or more devices may have the capability to communicate with the WTRU. For example, the one or more devices may have network capabilities such as Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Zigbee, Z-Wave, Long Range Wide Area Network (LoRaWAN), Ethernet, RF, Near Field Communication (NFC), or the like.

[0131] The one or more identifiers may be one or more user identifiers associated with human users who share or use the WTRU. The one or more identifiers may be one or more devices identifiers associated with devices that use the WTRU as a gateway. The one or more identifiers may be one or more application identifiers associated with the application running on the WTRU or the devices that use the WTRU as a gateway. The terms identifier, identification, ID, user identifier, user ID, device identifier, device ID, application identifier, and application ID may be used interchangeably throughout this disclosure.

[0132] At 610, the first network node may transmit, to a second network node, a first identifier of the one or more identifiers. The second network node may be responsible for managing and enforcing policies related to network behavior and quality of service (QoS) for user sessions. The second network node may determine how network resources are allocated based on predefined rules, operator policies, and / or specific requirements of users, devices, or applications. For example, the first network node may be an SMF, and the second network node may be a PCF. At 615, the first network node may receive, from the second network node, one or more policy and charging control (PCC) rules associated with the first identifier. The one or more PCC rules may comprise quality of service (QoS) information associated with the first identifier and data flow control information associated with the first identifier. For example, one or more PCC rules may comprise the information that is required to enable the user plane detection, the policy control and proper charging for service data flow associated with the first identifier. The packets detected by applying the service data flow template of a PCC rule may form a service data flow. Two different types of PCC rules may exist: dynamic rules and predefinedrules. The dynamic PCC rules are provisioned by the PCF to the SMF, while the predefined PCC rules are configured into the SMF, and only referenced by the PCF. The one or more PCC rules may include the first identifier information for the proper user plane detection of and proper changing for the data flow associated with the first identifier.

[0133] At 620, the first network node may determine one or more characteristics of a data flow associated with the first identifier. For example, the first network node may determine, based on the one or more PCC rules, the one or more characteristics of the data flow associated with the first identifier. The one or more characteristics of the data flow associated with the first identifier may comprise one or more QoS parameters and packet filtering information. The one or more characteristics of the data flow may be used to establish or modify a PDU session with the WTRU. For example, the first network node may configure the user plane (e.g., RAN, UPF) for the data flow associated with the first identifier. At 625, the first network node may transmit, to the WTRU, a PDU session establishment accept or modification command. The PDU session establishment accept or modification command may comprise one or more QoS rules for the data flow associated with the first identifier. The one or more QoS rules for the data flow associated with the first identifier may be determined based on the one or more characteristics of the data flow associated with the first identifier. The one more QoS rules may comprise the QFI of the associated data flow (or QoS flow), a packet filter information (e.g., a packet filter set) and a precedence value. The one or more QoS rules may also include a QoS rule identifier, which is unique within the PDU session and is generated by the first network node (e.g., SMF). The WTRU may receive the one or more QoS rules and perform the classification and marking of UL user plane traffic, for example, the association of UL traffic to the data flow (or QoS flow), based on the one or more QoS rules.

[0134] Alternatively or additionally, the first network node may transmit, to a third network node, a message comprising the first identifier to retrieve the subscription data linked to the first identifier. The third network node may be UDM / UPMF. The first network node may receive, from the third network node, subscription information associated with the first identifier. The first network node may determine, based on the subscription information, whether a device associated with the first identifier is to be authorized. For example, the first network node may determine that the first identifier needs to be authenticated and authorized if no available authorization information is found and / or authentication policy requires (e.g., secondary) authentication and authorization of the first identifier.

[0135] Alternatively or additionally, the first network node may assign a QoS flow indicator (QFI) to the data flow associated with the first identifier. The QFI may be used to identify the data flow associated with the first identifier by the first network node during the PDU session. For example, the QFI associated with the first identifier is unique in the PDU session for the data flow. The QFI may allow the first network node (e.g., SMF) to identify the traffic sent to or received from the WTRU associated with the first identifier. The first network node may determine, based on the subscription information (e.g., user profile), the one or more characteristics of the data flow associated with the first identifier.

[0136] In an embodiment, a WTRU may transmit, to a network node, a PDU session establishment or modification request. The PDU session establishment or modification request may comprise one or more identifiers. The one or more identifiers may be one or more user identifiers associated with human users who share or use the WTRU. The one or more identifiers may be one or more device identifiers associated with devices that use the WTRU as a gateway. The one or more identifiers may be one or more application identifiers associated with the application running on the WTRU or the devices that use the WTRU as a gateway. The terms identifier, identification, ID, user identifier, user ID, device identifier, device ID, application identifier, and application ID may be used interchangeably throughout this disclosure.

[0137] The WTRU may have the capability to communicate with a wireless communication system such as a primary network, a 3GPP network, a cellular network, and a Wi-Fi network. For example, the WTRU may be a cellular device or a 3GPP device. The one or more identifiers may be associated with one or more devices. The one or more device may be connected to the WTRU. For example, the one or more device may be connected wirelessly to the WTRU. The one or more devices may use the WTRU as a gateway. The one or more devices may be referred to as non-primary devices, secondary devices, non-cellular devices, or non- 3GPP devices. The one or more devices may or may not have the capability to communicate with a wireless communication system such as a primary network, a 3GPP network, a cellular network, and a Wi-Fi network. The one or more devices may have the capability to communicate with the WTRU. For example, the one or more devices may have network capabilities such as Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Zigbee, Z-Wave, Long Range Wide Area Network (LoRaWAN), Ethernet, RF, Near Field Communication (NFC), or the like.

[0138] The WTRU may receive, from the network node, a PDU session establishment accept or modification command. The PDU session establishment accept or modification command may comprise one or more QoS rules. The one or more QoS rules may be used during establishment or modification of a PDU session with the network node for a data flow associated with the one or more identifiers. The one or more QoS rules may indicate one or more characteristics of the data flow associated with the one or more identifiers. The one or more characteristics of the data flow associated with the one or more identifiers may comprise one or more QoS parameters and packet filtering information. The one or more QoS rules for the data flow associated with the one or more identifiers may be determined based on the one or more characteristics of the data flow associated with the one or more identifiers. The one more QoS rules may comprise the QFI of the associated data flow (or QoS flow), a packet filter information (e.g., a packet filter set) and a precedence value. The one or more QoS rules may also include a QoS rule identifier which is unique within the PDU session and is generated by the network node (e.g., SMF). The WTRU may receive the one or more QoS rules and perform the classification and marking of UL user plane traffic, for example, the association of UL traffic to the data flow (or QoS flow), based on the one or more QoS rules.

[0139] FIG. 7 illustrates an example procedure 700 for user ID revocation for user-specific QoS flow established, which may be used in combination with any of other embodiments described herein. For example,network user ID(s) may be revoked by a network node (e.g., an AF 790) with un-linkage from a WTRU subscription. The WTRU may use one or more user IDs with user-specific QoS flows established, as described above.

[0140] At 704, in some embodiments, the WTRU 702 has established user-specific QoS flows for one or more user IDs as described above. The AF 790 may wish to update the list of one or more user IDs for the linkage with a 3GPP subscription. At 706, the AF 790 may request to add, update or remove / unlink a user ID with respect to the WTRU subscription. The UDM / UPMF 786 may update the list at 708, and respond at 710 with a response indicating that the user IDs were correspondingly added, updated, or removed.

[0141] At 712, in some embodiments, the SMF 783 may receive a notification from the UDM / UPMF 786 of the updated list of authorized user IDs. For example, a user ID may have been revoked (or removed) from the registered / authorized user in 704.

[0142] At 714, the SMF 783 may determine, from the received notification and the user ID stored in the PDU session context, that the PDU Session needs to be updated based on matching a user ID being revoked. The SMF 783 may locate the associated QoS flows based on the QFI that was mapped to the user ID as described above.

[0143] At 716, the SMF 783 may initiate a PDU session modification and reconfigure a user plane such as the RAN and UPF to remove the user-specific QoS flows for the revoked user ID.

[0144] At 718, the SMF 783 may send updated QoS rules to the WTRU 702 with the removal of the user ID’s QoS flows. The WTRU 702 can re-register or reauthenticate flows, as discussed above.

[0145] At 720, in some embodiments, the PDU session may be released (e.g., based on RAN release of resources) when all the QoS flows of the PDU session are released. The PDU session release command to the WTRU 702 may indicate a cause code about the user ID being not authorized. The PDU session may be maintained if other user-specific QoS flows for other user IDs remain. For example, the PDU session may be maintained if at least one user-specific QoS flow for at least one user ID remains.

[0146] In some aspects, the present disclosure is directed to a network device comprising one or more processors executing a session management function (SMF). The SMF may be configured to receive, from a wireless transmit / receive unit (WTRU) communicating via a network, a packet data unit (PDU) session establishment or modification request message comprising one or more user identifiers. The SMF may retrieve, from a unified data management (UDM) service of the network, subscription information associated with a first user identifier of the one or more user identifiers. The SMF may assign a quality of service flow indicator (QFI) to the first user identifier. The SMF may derive characteristics of a quality of service flow associated with the first user identifier, based on the retrieved subscription information. The SMF may configure a user plane of a PDU session based on the derived characteristics of the quality of service flow associated with the first user identifier. The SMF may send, to the WTRU, a PDU session establishment or modification acknowledgement message.

[0147] In some implementations, the PDU session establishment or modification acknowledgement message comprises the derived characteristics of the quality of service flow associated with the first user identifier. In some implementations, the one or more user identifiers are associated with the WTRU. In a further implementation, the one or more user identifiers are each associated with a different user, device, or application of the WTRU.

[0148] In some implementations, the one or more processors are further configured to determine that the first user identifier needs to be authenticated or authorized. The one or more processors, responsive to the determination, may authenticate or authorize the first user identifier with an authentication service provided by the network device or a second network device. In some implementations, the one or more processors may be further configured to derive characteristics of the quality of service flow associated with the first user identifier further based on policy rules associated with the first user identifier received from a policy control function (PCF) of the network. In some implementations, the one or more processors may be further configured to assign a quality of service flow indicator (QFI) to a second user identifier of the one or more user identifiers. The one or more processors may derive characteristics of a second quality of service flow associated with the second user identifier, based on the retrieved subscription information associated with the first user identifier; and configure the user plane of the PDU session based on the derived characteristics of the second quality of service flow associated with the second user identifier. In a further implementation, the PDU session may be shared by a user / device / application of the WTRU associated with the first user identifier and a second user / device / application of the WTRU associated with the second user identifier. In some implementations, the one or more processors may further configure the user plane of the PDU session by setting packet filtering and steering configurations in the network based on the derived characteristics of the quality of service flow associated with the first user identifier.

[0149] In another aspect, the present disclosure is directed to a method. The method includes receiving, by a session management function (SMF) of a network device from a wireless transmit / receive unit (WTRU) communicating via a network, a packet data unit (PDU) session establishment or modification request message comprising one or more user identifiers. The method also includes retrieving, by the SMF from a unified data management (UDM) service of the network, subscription information associated with a first user identifier of the one or more user identifiers. The method also includes assigning, by the SMF, a quality of service flow indicator (QFI) to the first user identifier. The method also includes deriving, by the by the SMF, characteristics of a quality of service flow associated with the first user identifier, based on the retrieved subscription information. The method also includes configuring, by the SMF, a user plane of a PDU session based on the derived characteristics of the quality of service flow associated with the first user identifier. The method also includes sending, by the SMF to the WTRU, a PDU session establishment or modification acknowledgement message.

[0150] In some implementations, the PDU session establishment or modification acknowledgement message may comprise the derived characteristics of the quality of service flow associated with the first useridentifier. In some implementations, the one or more user identifiers may be associated with the WTRU. In a further implementation, the one or more user identifiers may be each associated with a different user, device, or application of the WTRU.

[0151] In some implementations, the method includes determining, by the SMF, that the first user identifier needs to be authenticated or authorized. The method also include, responsive to the determination, authenticating or authorizing the first user identifier with an authentication service provided by the network device or a second network device. In some implementations, the characteristics of the quality of service flow associated with the first user identifier are further derived based on policy rules associated with the first user identifier received from a policy control function (PCF) of the network. In some implementations, the method includes assigning a quality of service flow indicator (QFI) to a second user identifier of the one or more user identifiers. The method also includes deriving characteristics of a second quality of service flow associated with the second user identifier, based on the retrieved subscription information associated with the first user identifier. The method also includes configuring the user plane of the PDU session based on the derived characteristics of the second quality of service flow associated with the second user identifier. In a further implementation, the PDU session may be shared by a user of the WTRU associated with the first user identifier and a second user of the WTRU associated with the second user identifier. In some implementations, the method includes setting packet filtering and steering configurations in the network based on the derived characteristics of the quality of service flow associated with the first user identifier.

[0152] In another aspect, the present disclosure is directed to the implementations of systems, apparatuses, and methods for user-specific QoS parameter provisioning and processing of traffic routing and steering by an AF. In brief overview, the PCF may generate or update a user-specific policy based on provisioned QoS parameters or requests by an AF to influence traffic routing and steering. In some embodiments, the PCF may inform the SMF of existing PDU sessions serving the particular user ID of the userspecific policy.

[0153] In some implementations, in response to an AF request to influence traffic routing and steering for a user ID linked to a WTRU subscription, the PCF may subscribe to a UDR for modification of AF requests identified by 3GPP identifier (e.g., SUPI) and user ID(s). The PCF may receive a notification message from UDR indicating the WTRU(s) and the linked user I D(s) being subject to a traffic influence request based on the provided traffic routing / steering info. The PCF may determine whether there are PDU sessions for the WTRU(s) and the PDU sessions are used by the given user I D(s) that may be impacted by the AF request. For example, a user ID may have been provided to the PCF by the SMF in a prior policy association request during a PDU session establishment or modification procedure. For each of the impacted PDU sessions, the PCF may send a notification message to the SMF indicating the PDU session ID, the impacted user ID and the applicable policy information (e.g., SFC enforcement policy). The PCF may notify the AF of the activation of traffic steering for the user ID.

[0154] In some implementations, in response to an AF request to provision QoS parameters for an AF session used by a user ID linked to a WTRU subscription, the PCF may register with a binding support function (BSF) for AF requests identified by 3GPP identifier (e.g., SUPI) and user ID(s). The PCF may receive, from an NEF (or AF), a request to reserve network resources for an AF session used by a given user ID, the request also including the IP or ethernet address of the PDU session and QoS parameters. The PCF may check whether the request is authorized for the user ID is allowed (e.g., based on possible user-specific QoS restrictions). If the request is authorized, in some implementations, the PCF may update the user-specific QoS policy information for the user ID. The PCF may determine whether the SMF serving the PDU session used by the given WTRU / user ID needs to be updated with user-specific QoS policy information. For example, a user ID may have been provided to the PCF by the SMF in a prior policy association request during a PDU session establishment or modification procedure. If the user ID is provided, the PCF may send a notification message indicating the PDU session ID, the impacted user ID and the user-specific QoS information (e.g., requested delay, max bitrate, or the like). The PCF may reply to the NEF confirming or rejecting authorization for QoS parameters provisioning.

[0155] Still discussing implementations of systems, apparatuses, and methods for user-specific QoS parameter provisioning and processing of traffic routing and steering by a network node (e.g., an AF) and in more detail, the following description illustrates implementations in which the network node (e.g., the AF) requests from the network to influence traffic routing or steering for a particular user ID linked to a WTRU subscription. A network node (e.g., PCF) may generate or update a policy for the user ID and inform another network node (e.g., SMF) with existing PDU sessions serving the particular user ID. Another network node (e.g., the SMF) may reconfigure the user plane of the PDU session for the user ID using the provided policy.

[0156] FIG. 8 illustrates an example procedure 800 for AF influence on user-specific traffic routing and steering, which may be used in combination with any of other embodiments described herein. An AF request may be processed to influence user-specific traffic routing and steering, according to some embodiments. For example, the AF may wish to apply some N6-LAN traffic steering (e.g., service function chaining (SFC) such as parental control, firewall, or the like) for the service data flows associated with the user ID.

[0157] At 804, the WTRU 802 is registered one or more user IDs linked with a WTRU subscription. At 806, the WTRU 802 has established one or more PDU sessions with user-specific QoS flows. As discussed above, “user” may refer to a human user, a device, an application or other similar entity. PDU sessions may be on a per-application basis. A PCF 885 may be subscribed to the UDR 884 for modification of AF requests identified by a 3GPP identifier (e.g., SUPI) and user ID(s).

[0158] The AF 890 may wish to influence traffic routing / steering for one or more users (or one or more devices) associated with one or more WTRUs via a NEF 886 (or directly). At 808, in some embodiments, the AF 890 may provide the IP or ethernet address of the PDU session and 3GPP identifier (e.g., GPSI / SUPI) of the WTRU(s) and the respective user ID(s) targeted by the AF request. At 810, in some embodiments, the NEF886 may check AF authorization for traffic influence and initiate the update / storing of traffic routing / steering settings for the given user ID in the UDR 884 (which may be via a UPMF 884). At 812, in some embodiments, the NEF 886 may send a response to the AF 890 confirming traffic influence being created or updated.

[0159] At 814, in some embodiments, the PCF 885 may receive a notification from the UDR 884 indicating the WTRU(s) 802 and the linked user I D(s) being subject to a traffic influence request based on the provided traffic routing / steering info. At 816, the PCF 885 may determine whether there are PDU sessions for the WTRU(s) 802 and used by the given user ID(s) that may be impacted by the AF request (e.g. PDU sessions that will be affected by implementation of packet or flow steering or routing rules associated with the request, or that will be subject to such rules). Each user ID may have been provided to the PCF 885 by the SMF 883 in a prior policy association request during a PDU session establishment or modification procedure.

[0160] For each of the impacted PDU sessions, at 818, the PCF 885 may send a notification message to the SMF 883 indicating the PDU session ID, the impacted user ID and the applicable policy information (e.g., SFC enforcement policy). At 820, the SMF 883 may reconfigure the user plane (e.g., RAN, UPF, or the like) for the user-specific QoS flows. For example, in some embodiments, the SMF 883 may provide the UPF 881 with user-specific N6-LAN traffic steering control parameters such as Network Address Translation (NAT), parental control, or the like. The new rules that are derived by the SMF 883 may be based on policy information that the PCF 885 indicated in the notification message at 818 is associated with the user identifier.

[0161] FIG. 9 illustrates an example procedure 900 for user-specific parameters provisioning and influence on traffic routing and steering by an AF 990, which may be used in combination with any of other embodiments described herein. An AF request may be processed to provision communication characteristics parameters for a particular user ID for an AF session, according to some embodiments. For example, the AF 990 may wish to provide QoS requirements and / or reserve resources for an AF session for a particular user ID.

[0162] At 903, the WTRU 902 is registered one or more user IDs linked with a WTRU subscription. At 904, the WTRU 902 has established one or more PDU sessions with user-specific QoS flows. A PCF 985 is registered with a binding support function (BSF) for AF requests identified by a 3GPP identifier (e.g., SUPI) and user ID(s).

[0163] In some embodiments, the AF 990 may wish to reserve network resources for an AF session. At 906, the AF 990 may provide the IP or ethernet address of the PDU session for the user I D(s) targeted by the AF request and QoS parameters to a NEF 986. The NEF 986 may check for AF authorization for QoS parameters provisioning in some embodiments. In some embodiments, the NEF 986 may discover the relevant PCF (e.g., PCF 985) using a BSF. In some embodiments, the returned PCF may be filtered by the BSF based on matching a user ID(s) as provided by PCF during registration with BSF. In some embodiments at 908, the NEF 986 may send the request to the PCF 985, including the parameters received from the AF 990.

[0164] At 910, the PCF 985 may determine whether the request is authorized. For example, the PCF 985 may check whether the user ID is allowed, or whether the amount or level of requested QoS (e.g., high priority,medium priority, real-time, or the like) is authorized for the AF 990 for the user ID (e.g., based on possible userspecific QoS restrictions). The PCF 985 may update the user-specific QoS policy information for the user ID.

[0165] At 912, the PCF 985 may determine whether the SMF 983 serving the PDU session used by the given WTRU / user ID needs to be updated with user-specific QoS information. Each user ID may have been provided to the PCF 985 by the SMF 983 in a prior policy association request during a PDU session establishment or modification procedure. Responsive to such a determination, at 914, the PCF 985 may send a notification message to the SMF 983 indicating the PDU session ID, the impacted user ID and the userspecific QoS information (e.g., requested delay, max bitrate, or the like). At 916, the SMF 983 may reconfigure the user plane (e.g., RAN, UPF, or the like) for the user-specific QoS flows given the updated QoS policy.

[0166] At 918, in some embodiments, the PCF 985 may reply to the NEF 986 confirming or rejecting authorization. At 920, the NEF 986 may send the response to the AF 990 confirming or rejecting authorization for the QoS provisioning request.

[0167] In some aspects, the present disclosure is directed to a method. The method includes requesting, by a policy control function (PCF) of a network device from a unified data repository (UDR) of a network, information regarding application function (AF) requests associated with a subscriber account and one or more user identifiers associated with the subscriber account. The method also includes receiving, by the PCF from the UDR, a notification identifying a first user identifier of the one or more user identifiers and a first wireless transmit / receive unit (WTRU) associated with the subscriber account that is subject to a traffic steering request from an AF of the network. The method also includes determining, by the PCF, that a packet data unit (PDU) session for the first WTRU and associated with the first user identifier may be affected by implementing or is subject to the traffic steering request. The method also includes, responsive to the determination, transmitting, by the PCF, a notification message to a session management function (SMF) of the network comprising an identifier of the PDU session, the first user identifier, and a policy associated with the first user identifier. The method also includes transmitting, by the PCF to the AF, a notification of activation of traffic steering for the first user identifier.

[0168] In some implementations, the method includes registering with a binding support function (BSF) provided by the network device or a second network device for AF requests associated with the subscriber account and the one or more user identifiers. In some implementations, the method includes determining that the traffic steering request will modify traffic routing parameters of the PDU session. In some implementations, the method includes determining that the first user identifier was included in a previously received notification message from the SMF to the PCF during establishment of the PDU session. In some implementations, the policy associated with the first user identifier further comprises a policy associated with the subscriber account.

[0169] In another aspect, the present disclosure is directed to a network node or a network device, comprising one or more processors executing a policy control function (PCF), and one or more transceivers in communication with a network. The PCF is configured to request, from a unified data repository (UDR) of thenetwork, information regarding application function (AF) requests associated with a subscriber account and one or more user identifiers associated with the subscriber account. The PCF is configured to receive, from the UDR, a notification identifying a first user identifier of the one or more user identifiers and a first wireless transmit / receive unit (WTRU) associated with the subscriber account that is subject to a traffic steering request from an AF of the network. The PCF is configured to determine that a packet data unit (PDU) session for the first WTRU associated with the first user identifier may be affected by implementing or is subject to the traffic steering request. The PCF is configured to, responsive to the determination, transmit a notification message to a session management function (SMF) of the network comprising an identifier of the PDU session, the first user identifier, and a policy associated with the first user identifier. The PCF is configured to transmit, to the AF, a notification of activation of traffic steering for the first user identifier.

[0170] In some implementations, the PCF is further configured to register with a binding support function (BSF) provided by the network device or a second network device for AF requests associated with the subscriber account and the one or more user identifiers. In some implementations, the PCF is further configured to determine that the traffic steering request will modify the traffic routing parameters of the PDU session. In some implementations, the PCF is further configured to determine that the first user identifier was included in a previously received notification message from the SMF to the PCF during the establishment of the PDU session. In some implementations, the policy associated with the first user identifier further comprises a policy associated with the subscriber account.

[0171] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMSWhat is Claimed:

1. A method for use in a first network node, the method comprising: receiving, from a wireless transmit / receive unit (WTRU), a packet data unit (PDU) session establishment or modification request comprising one or more identifiers; transmitting, to a second network node, a first identifier of the one or more identifiers; receiving, from the second network node, one or more policy and charging control (PCC) rules associated with the first identifier; determining, based on the one or more PCC rules, one or more characteristics of a data flow associated with the first identifier, wherein the one or more characteristics of the data flow is used to establish or modify a PDU session with the WTRU; and transmitting, to the WTRU, a PDU session establishment accept or modification command.

2. The method of claim 1, wherein the one or more identifiers are associated with one or more devices connected to the WTRU.

3. The method of claim 1, wherein the one or more PCC rules comprise quality of service (QoS) information associated with the first identifier and data flow control information associated with the first identifier.

4. The method of claim 1, wherein the one or more characteristics of the data flow associated with the first identifier comprise one or more QoS parameters and packet filtering information.

5. The method of claim 1 , wherein the PDU session establishment accept or modification command comprises one or more QoS rules for the data flow associated with the first identifier.

6. The method of claim 5, further comprising: determining, based on the one or more characteristics of the data flow associated with the first identifier, the one or more QoS rules.

7. The method of claim 1 , further comprising: transmitting, to a third network node, a message comprising the first identifier; receiving, from the third network node, subscription information associated with the first identifier; and determining, based on the subscription information, whether a device associated with the first identifier is to be authorized.

8. The method of claim 7, further comprising:determining, based on the subscription information, the one or more characteristics of the data flow associated with the first identifier.

9. The method of claim 1 , further comprising: assigning a QoS flow indicator (QFI) to the data flow associated with the first identifier, wherein the QFI is used to identify the data flow associated with the first identifier by the first network node during the PDU session.

10. The method of claim 1, wherein one or more devices associated with the one or more identifiers are one or more non-cellular devices and the WTRU is a cellular device, and wherein the first network node is a session management function (SMF) and the second network node is a policy control function (PCF).

11. A first network node comprising: a processor; and a transceiver, the processor and the transceiver configured to: receive, from a wireless transmit / receive unit (WTRU), a packet data unit (PDU) session establishment or modification request comprising one or more identifiers; transmit, to a second network node, a first identifier of the one or more identifiers; receive, from the second network node, one or more policy and charging control (PCC) rules associated with the first identifier; determine, based on the one or more PCC rules, one or more characteristics of a data flow associated with the first identifier, wherein the one or more characteristics of the data flow is used to establish or modify a PDU session with the WTRU; and transmit, to the WTRU, a PDU session establishment accept or modification command.

12. The first network node of claim 11 , wherein the one or more identifiers are associated with one or more devices connected to the WTRU, and wherein the one or more devices are one or more non-cellular devices and the WTRU is a cellular device.

13. The first network node of claim 11 , wherein the one or more PCC rules comprise quality of service (QoS) information associated with the first identifier and data flow control information associated with the first identifier.

14. The first network node of claim 11 , wherein the one or more characteristics of the data flow associated with the first identifier comprise one or more QoS parameters and packet filtering information.

15. The first network node of claim 11 , wherein the PDU session establishment accept or modification command comprises one or more QoS rules for the data flow associated with the first identifier, and wherein the one or more QoS rules are determined based on the one or more characteristics of the data flow associated with the first identifier.

16. The first network node of claim 11 , wherein the processor and the transceiver are configured to: transmit, to a third network node, a message comprising the first identifier; receive, from the third network node, subscription information associated with the first identifier; and determine, based on the subscription information, the one or more characteristics of the data flow associated with the first identifier.

17. The first network node of claim 11 , wherein the processor and the transceiver are configured to: assign a QoS flow indicator (QFI) to the data flow associated with the first identifier, wherein the QFI is used to identify the data flow associated with the first identifier by the first network node during the PDU session.

18. A wireless transmit / receive unit (WTRU) comprising: a processor; and a transceiver, the processor and the transceiver configured to: transmit, to a network node, a packet data unit (PDU) session establishment or modification request comprising one or more identifiers; and receiving, from the network node, a PDU session establishment accept or modification command comprising one or more QoS rules, wherein the one or more QoS rules are used to establish or modify a PDU session with the network node for a data flow associated with the one or more identifiers.

19. The WTRU of claim 18, wherein the one or more identifiers are associated with one or more devices connected to the WTRU, and wherein the one or more devices are one or more non-cellular devices and the WTRU is a cellular device.

20. The WTRU of claim 18, wherein the one or more QoS rules are indicative of one or more characteristics of the data flow associated with the one or more identifiers, wherein the one or more characteristics comprise one or more QoS parameters and packet filtering information.

Images