Mechanism for identifying traffic of devices behind the rg

Abstract

A WTRU residential gateway (RG) is configured to detect what PDU session to use for traffic associated with a user identity of a connected / tethered device based on traffic descriptor(s) in a provisioned user equipment route selection policy (URSP). The RG then provides information to the network so that the network can detect what traffic is associated with a user identity of the connected device. The network manages the IP address allocation and port combinations of the device that is associated with the traffic and provides the information to the RG to effectively use as packet filters in managing traffic from / to the connected device. Additional variants and embodiments are disclosed.

Description

MECHANISM FOR IDENTIFYING TRAFFIC OF DEVICES BEHIND THE RGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 588,216, filed October 5, 2023, and U.S. Provisional Application No. 63 / 588,230, filed October 5, 2023, the contents of which are incorporated herein by reference.BACKGROUND

[0002] Methods are desired to enhance the 5G System to allow for the creation and utilization of userspecific identities. A user-specific identity identifies the user of a user equipment (UE). The user of a UE is an entity that sends or receives traffic with a network. A user may be a human, application or device.

[0003] If network operators are able to identify users, then operators will be able to provide a user specific experience. For example, special services may be offered to some users, the traffic of some users may be given preferential treatment, and / or traffic that is associated with certain users might be charged / accounted differently.

[0004] In a scenario wherein the device(s) (UE) (i.e., tethered UE) are connecting to the 5GS via a residential gateway (RG), the traffic is relayed by the RG to an external data network (DN), which could belong to different mobile operators / subscriptions The control and user plane packets of the UE are transported using an RG IP PDU session. A single PDU session can be used to serve multiple UEs connected to the RG. There is currently no mechanism for the 3GPP system to identify the device(s) and traffic originating from the device(s) behind the RG / Relay.

[0005] Accordingly, solutions are needed to be able networks to authenticate and authorize a tethered device (a device behind the RG), and identify what traffic comes from the tethered device in order to differentiate services / policies to the traffic that comes from the tethered device compared to the services / policies that are applied to the traffic that is generated by applications that are hosted on the RG / Relay.SUMMARY

[0006] According to one aspect of the embodiments, the RG may be provisioned with URSP rules that are enhanced to help the RG determine the characteristics of a packet data unit (PDU) session to use to route traffic to and / or from a device. For example, the traffic descriptor (TD) of a user equipment route selection policy (URSP) rule may include a user identifier or part of a user identifier (e.g. the realm part). As used herein, a UE may be alternatively referred to as a wireless transmit receive unit (WTRU). A URSP rule that is formatted in this way can be used to indicate the PDU session characteristics that are necessary to route traffic from a device whose user identity matches the traffic descriptor in the URSP rule. Thus, such a URSP rule can be used to ensure that the RG uses a PDU session for the tethered device’s traffic that will send the data from thedevice to a data network that can be used to reach the non-3GPP interworking function (N3IWF) of the device’s home network (i e. mobile network operator (MN0)#2).

[0007] According to another aspect, once the RG uses the URSP rule to select the characteristics of a PDU session to use to route traffic to and from the device, the RG will execute a PDU Session Establishment procedure to establish a new PDU session or a PDU Session Modification procedure if an existing PDU session is selected. In some aspects, the PDU Session Establishment or PDU Session Modification procedure will trigger an Extensible Authentication Protocol (EAP) Authentication and Authorization procedure between the device and an authentication, authorization, and accounting (AAA) Server of the device’s home network. Upon completion of the EAP Authentication and Authorization procedure, a session management function (SMF) that serves the PDU session will send the RG packet filters that are associated with the PDU session and the device. The RG will only route traffic to / from the device if the traffic matches the packet filters One advantage of this procedure is that the network will be able to recognize that all traffic that matches the packet filter is associated with the user identity and user specific policies can be configured by configuring policies for traffic that matches the filter.

[0008] According to another aspect, the RG / WTRU may receive information from the network that indicates that the number of user identities that can be associated with a PDU session is limited or should be rejected / not permitted. The RG uses this information to determine whether to block traffic or whether to route traffic from a device via a PDU session that is not associated with user identifiers, e.g. , a PDU session of the RG.

[0009] In one example, a method implemented by a wireless transmit receive unit (WTRU) serving as a residential gateway (RG) for a network may include receiving at least one user equipment route selection policy (URSP) rule and a related traffic descriptor (TD) associated with one or more user identifiers. The RG determines or receives a user identity (UID) of a connected device requesting traffic in the network through the RG and associates the traffic with the UID. The RG may determine a data network name (DNN) and single network slice assistance information (S-NSSAI) combination to associate with the traffic based on the UID corresponding to the related TD of the at least one URSP rule.

[0010] Next, the RG may send, to the network, a non-access stratum (NAS) request message including the UID to establish or modify a packet data unit (PDU) session associated with the determined DNN and S-NSSAI combination and receive a NAS response message indicating at least one internet protocol (IP) address and port combination assigned for the traffic of the connected device. The RG may then route the traffic between the connected device and the network based on the indicated IP address and port combination.

[0011] According to one aspect, the NAS request message may be a PDU Session Establishment request indicating the determined DNN and S-NASSAI combination. In another aspect, the NAS request message may be a PDU Session Modification request for a PDU session already associated with the determined DNN and S-NSSAI combination. In one example, the UID relates to an identity of the connected device and the related TD includes, at least part of the UID. In another example aspect, the UID relates to a destination IP address ofthe traffic and the TD includes an IP address of a non-3GPP interworking function (N3IWF) or a trusted non- 3GPP gateway function (TNGF) and an IP address / port combination.

[0012] In some aspects, the UID may be determined based on a medium access control (MAC) address of the connected device in a configured layer mapping corresponding to the UID. In another aspect, the NAS response message further indicates one or more of a precedence value, a time validity, a location validity, one or more packet filters linked with the UID and / or if usage of the one or more packet filters should be reported to the network. A further aspect may include the NAS response message further indicating if network address translation (NAT) should be performed for the traffic of the connected device.

[0013] In another aspect, a method for a network, e.g., a session management function (SMF), may include receiving, from a WTRU serving as a RG of a network, a NAS message request to establish or modify a PDU session for transporting traffic of a device connected to the RG through the network, where the NAS message request indicates a UID for the traffic of the device. The SMF may determine whether the UID is permitted for a DNN and S-NSSAI combination and whether the UID is authenticated and authorized by the AAA server of the device’s home network. Next; based on determining whether the UID is permitted and whether the UID is authenticated and authorized, the SMF sends a NAS message response to the RG indicating whether the PDU session will or will not be established or modified

[0014] In one example, the NAS message request is a PDU Session Establishment request indicating the UID and the DNN and S-NASSAI combination. In another example, the NAS message request is a PDU Session Modification request for a PDU session already associated with the DNN and S-NSSAI combination. The NAS message response may indicate the PDU session will be established or modified, and further indicate at least one internet protocol (IP) address and port combination to assign to transport the traffic of the device through the network. In certain cases, when receiving the PDU modification / establishment request from the RG, the SMF may initiate an authentication and authorization procedure between the device and an AAA server. In other examples, the NAS message response indicates the PDU session will not be established or modified and further includes a 5G session management (5GSM) cause information element indicating a reason the connected device is not permitted. Additional aspects, features and advantages will become apparent from the disclosed embodiments that follow.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0018] 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;

[0019] FIG. 1D 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;

[0020] FIG. 2 is a block diagram of a generic Extensible Authentication Protocol (EAP) architecture;

[0021] FIG. 3 is a network diagram showing a WTRU accessing its subscription behind the residential gateway (RG);

[0022] FIG. 4 is a network sequence diagram for embodiments where a Traffic Descriptor in a UE route selection policy (URSP) Rule is a User Identify;

[0023] FIG. 5 is a network sequence diagram for embodiments where a Traffic Descriptor in a URSP Rule is an identify of a non-3GPP internetworking function (N3IWF) or trusted WLAN interworking function (TWIF);

[0024] FIG. 6 is a flow chart detailing a method for a residential gateway (RG) / relay WTRU providing a tethered device traffic flows authorized by a mobile network operator (MNO) according to one embodiment; and

[0025] FIG. 7 is a flow chart detailing a method for a session management function (SMF) in providing access to tethered device traffic according to an embodiment.DETAILED DESCRIPTION

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

[0027] 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 (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though itwill 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 whichmay 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.

[0028] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, 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.

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

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

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

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

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

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

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

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

[0037] 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 ormore 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.

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

[0039] 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. 1 A 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.

[0040] FIG. 1 B 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.

[0041] 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 thetransmit / receive element 122. While FIG. 1 B 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.

[0042] 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 may be 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.

[0043] Although the transmit / receive element 122 is depicted in FIG. 1 B 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.

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

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

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

[0047] 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

[0048] 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 handsfree 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.

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

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

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

[0052] 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. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

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

[0054] 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

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

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

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

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

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

[0060] 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 aDistribution 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 (IBSS) 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.

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

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

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

[0064] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. 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.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS)spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah 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 limited bandwidths The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0065] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802 11 n, 802.11ac, 802.11af, and 802.11 ah, 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 STAs 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.11 ah, 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.

[0066] 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.11ah is 6 MHz to 26 MHz depending on the country code.

[0067] FIG. 1 D 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.

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

[0069] 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 wireless transmission 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).

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

[0071] 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. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0072] The CN 106 shown in FIG. 1 D 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.

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

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

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

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

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

[0078] 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 may be directly coupled to another device for purposes of testing and / or performing testing using over-the-air wireless communications.

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

[0080] In the following embodiments, solutions that apply to sending traffic to, and / or receiving traffic from, a non-3GPP interworking function (N3IWF) equally apply to a trusted WLAN interworking function (TNGF). Conversely, solutions that apply to sending traffic to, and / or receiving traffic from, a TNGF equally apply to a N3IWF. As used herein, a residential gateway (RG) is a type of UE or WTRU.

[0081] RG / WTRU actions in a successful scenario are described. Example actions that a RG / WTRU may take to associate a user identity with a traffic flow of a PDU session may be as follows. A RG / WTRU first receives at least one user equipment route selection (URSP) rule from the network and an indication that the URSP rule is associated with one or more user identities. The indication may be the presence of a user identity, or part of a user identity, in the traffic descriptor of the URSP Rule. The RG next receives traffic from a connecting / connected device and associates the traffic with a user identity (UID). The RG / WTRU knows the association between the device and the user identity because the RG / WTRU received the user identity from the device during connection to the RG In other solutions, the RG knows the association between the device and the user identity because the RG was configured with a mapping between a lower layer identity of the device and the UID. For example, a graphic user interface (GUI) may have been used to configure the RG with information that indicates that the medium access control (MAC) address of the device is associated with the user identity.

[0082] Reception of the traffic triggers the RG to perform URSP rule evaluation in order to determine what PDU session to send the traffic over. The user identifier is used in the URSP rule evaluation procedure to determine a data network name (DNN) and single network slice selection assistance information (S-NSSAI) combination to associate with the traffic In other solutions, the destination internet protocol (IP) address of the traffic is used in the URSP rule evaluation procedure to determine a DNN and S-NSSAI combination with which to associate with the traffic.

[0083] The RG next sends a non-access stratum session management (NAS-SM) request message to the network. The NAS-SM message requests that the UID be associated with a packet data unit (PDU) sessionthat is associated with the DNN and S-NSSAI combination. In one example, the NAS-SM message is a PDU Session Establishment Request and includes the DNN and S-NSSAI combination In another example, the NAS-SM message is a PDU Session Modification Request and the PDU session is already associated with the DNN and S-NSSAI combination.

[0084] The RG then receives a NAS-SM response message from the network. The received NAS-SM message may include at least one IP address and port number combination The IP address / port number combination(s) indicate to the RG that the device is only allowed to send and receive data using the indicated IP address / port number combination(s). Inclusion of the IP address / port number combination(s) that were received from the authentication, authorization and accounting (AAA) server may cause the RG to block any traffic that originates from the device and is sent towards an IP address and port number that does not match the allowed IP address / port number combination(s).

[0085] The NAS-SM response message that is received from the network may include an IP address to assign to the device. The WTRU / RG may send the IP address to the device in a dynamic host configuration protocol (DHCP) procedure. In some embodiments, the IP address / port number combination(s) may have additional attributes e.g., precedence value, validity information (i.e. time validity (start / stop time, day of the week, etc.), location validity information (linked with tracking area identity (TAI) of the RG or geo-fencing location)), linkage of the packet filters with the user identity (UID) (this information may be used to differentiate between multiple WTRUs behind the RG and application of the packet filters / precedence for the traffic matching the user identity) and / or an indication if the usage of the packet filters shall be reported back to the session management function (S M F) / policy control function (PCF) (e g., a flag). The NAS-SM response message that is received from the network may also optionally include an indication to the RG if network address translation (NAT) should be performed by the RG for traffic that is associated with the device. This indication may trigger the RG / WTRU to perform a network address translation (NAT) operation on traffic that is sent to and from the device.

[0086] RG / WTRU actions in an example rejection scenario are described. The scenario described previously mentions four steps that a WTRU / RG may take in a procedure where a user identity is successfully associated with a PDU session There may be other scenarios where the user identity is not successfully associated with a PDU session In this type of rejection scenario, the NAS-SM response message that is received from the network may indicate to the RG that the user identity may not be associated with the PDU session. The WTRU / RG may use the information in the NAS-SM response message to determine whether to attempt to associate the device’s traffic with a different PDU session. The RG may use the indication that the user identity may not be associated the PDU session to trigger a new URSP rule evaluation procedure, or continue an existing URSP rule evaluation procedure, to attempt to determine a different DNN and S-NSSAI combination to associated with the device’s traffic.

[0087] Limiting the use of user identities may be utilized by the network. In certain embodiments, example actions that a RG / WTRU may take to allow the network to control how many devices, or user identities, areassociated with a PDU session are as follows. A RG / WTRU first receives a message from the network and the message may include information that indicates that the number of user identities that can be associated with a PDU session is limited. In one example, the message may include the size of the limit and the size maybe expressed in a numberof user identities. In one example, the message may be a PDU Session Establishment Accept or a PDU Session Modification Command message and the information may be in a protocol configuration option (PCO) information element. In one example, the message may be a NAS-SM rejection message. In one example, the message may be a NAS-MM message and the information may be part of a URSP rule.

[0088] The RG / WTRU may receive a message from a device in which the RG may detect that the device is associated with a user identity. The RG / WTRU may detect that traffic is associated with the device and the user identity should be sent via the PDU session. In one example, the RG / WTRU may detect that the PDU session that should carry the user identity traffic is already associated with a number of other devices that is equal to the max limit that was provided by the network, e.g., based on previously receiving the limit value from the network. In another example, detecting that the PDU session that should carry the traffic of the detected user identify, is already associated with a number of other devices that is equal to the limit, may be based on receiving a NAS-SM rejection message that indicates that the PDU session is already associated with the maximum number of devices / user identities. In these examples, the message from the device may include the user identity or the RG / WTRU may determine the device’s user identity based on configuration information that was provided, e.g., via a GUI.

[0089] Based on detecting that the PDU session that should carry the traffic of the device / user identity is already associated with a number of other devices equal to the limit that was provided by the network, the RG / WTRU may decide to: (1) block traffic from the device (i.e. not send the traffic via a PDU session); or (2) trigger a new URSP Rule evaluation procedure, or continue an existing URSP Rule evaluation procedure, in order to send the traffic to the network via a second PDU session. For example, the second PDU session might not be associated with user identities (i e., send the traffic via a PDU session that is only associated with the RG / WTRU and is not associated with the device’s identity). The decision to block the traffic or send the traffic to the network via the second PDU session may be based on configuration information that was received via a GUI and / or ATtention (AT) command

[0090] Use of Extensible Authentication Protocol (EAP) is disclosed. EAP is not an authentication method but rather a common authentication framework that can be used to implement specific authentication methods. In other words, EAP is a protocol that allows the Peer, Authenticator, and Authentication server to negotiate what authentication method will be used. The selected authentication method is then run inside of the EAP protocol which describes the EAP packet format, procedures, as well as basic functions such as negotiation of the desired authentication mechanism. FIG. 2 shows a block diagram of the basic EAP architecture 200. EAP may use Radius or Diameter protocols. When used in conjunction with RADIUS, EAP requires the following participants (the names used are from the IEEE 802.1X standard merely by example):

[0091] -Supplicant: The supplicant is the machine that requests network access to a wireless network It contains the credentials used for authentication, and it is one end of the EAP exchange.

[0092] -Authenticator: The EAP authenticator is the Access Point (AP) or switch that controls access to the wireless network. It allows or denies network access based on the status returned by the EAP procedure. However, it does not directly authenticate the user itself. Instead, it hands the authentication over to the RADIUS server by encapsulating EAP inside of RADIUS.

[0093] -RADIUS server: The RADIUS server receives the Access-Request from the NAS and decodes the EAP data. It performs authentication and returns an EAP Success or Fail message, which is encapsulated in a RADIUS packet In theory, the system performing the EAP authentication is an EAP server, denoted as authentication server in the generic EAP architecture 200 of FIG. 2.

[0094] Note that it is not sufficient to describe an authentication mechanism as EAP as there is always some underlying authentication method. There are many EAP methods defined by Internet Engineering Task Force (IETF). This disclosure assumes that the selected EAP method is EAP-authentication and key agreement (AKA) which is based on universal mobile telecommunications service (UMTS)-AKA, however, the embodiments disclosed herein may be used regardless of the selected EAP authentication method.

[0095] Userequipment / WTRU Route Selection Policy (URSP) rules are policies that are used by the WTRU to determine how to route outgoing traffic. Traffic can be routed to an established PDU session, can be offloaded to non-3GPP access outside a PDU session, or can trigger the establishment of a new PDU session. The rules are provided by the policy control function (PCF) in the 5G core network (5GC) to the WTRU.

[0096] URSP Rules have two main parts: (1 ) A traffic descriptor (TD) part is used by the WTRU to determine what traffic to which the rule applies; and (2) A route selection descriptors (RSD) part that includes descriptions of route(s) (i.e. S-NSSAI, DNN, Access Type, etc.) that may be used to route the data that matches the traffic descriptor. The WTRU may also have local preferences that can be used to determine how to treat traffic. In some examples, local preferences take precedence over network URSPs.

[0097] A PDU session is associated to an S-NSSAI and a DNN In a PDU Session Establishment request sent to the network, the WTRU may provide a PDU Session Identifier (ID). The PDU Session ID is unique per WTRU and is the identifier used to uniquely identify one of a WTRU's PDU sessions. The PDU Session ID may be stored in the universal data management (UDM) to support handover between 3GPP and non-3GPP access when different public land mobile networks (PLMNs) are used for the two accesses.

[0098] Secondary authorization / authentication by an DN-AAA server during the PDU session establishment is optionally triggered by the SMF during a PDU Session Establishment and performed transparently via a user plane function (UPF), or directly with the DN-AAA server without involving the UPF if the DN-AAA server is located in the 5GC and reachable directly.

[0099] A residential gateway (RG) is a device that provides other devices with access to services in a network, including for example, voice, data, broadcast video, video on demand, etc In various embodiments,a RG may be a WTRU and thus, may have a NAS (i.e. N1) connection to a mobile core network. The RG may provide the devices with services by sending and receiving traffic for service via the 5GC. The devices that the RG provides service access to may also be WTRU(s) or non-3GPP devices.

[0100] Turning to FIG. 3, an example RG deployment scenario 300 is shown The following observations may be made about example scenario 300 in FIG. 3:

[0101] -The RG 315 is a WTRU and is subscribed to mobile network operator (MNO) #1 310;

[0102] -The WTRU(s) 325 that connects to the RG 315 is subscribed to MNO #2 320;

[0103] -The WTRU 325 establishes an IPSec tunnel 327 to the non-3GPP internetworking function (N3IWF) of MNO#2 320. The WTRU 325 uses the RG 315 to send and receive traffic from the IPSec tunnel;

[0104] -The connection between the WTRU 325 and RG 315 may be a non-3GPP access technology such as Wi-Fi; and

[0105] -When the WTRU’s IPSec traffic is routed through the core network of MNO#1 , the core network or MNO#1 cannot distinguish between traffic that originated in the RG 315 and traffic that originated in a different device such as the WTRU 325.

[0106] It should be noted that there may be scenarios where the WTRU 325 and RG 315 are subscribers of the same network. In such a scenario, it may still be the case that IPSec traffic of the WTRU 325 is sent through an PDU session of the RG 315 before it is sent to the N3IWF.

[0107] The user identifiers refer to the user specific identities, which are different from the subscription identifier that is being used by the user to establish the connection with the 5GC. The user to be identified could be an individual human user using a WTRU with a certain subscription, an application running on or connecting via a WTRU, or a device (e.g., a personal loT network (PIN) element (PINE)) behind a gateway WTRU (e g., a PINE with gateway capability (PEGG)) or a WLAN access point (AP).

[0108] Some of the use cases with respect to the users include: One or more users (i.e., humans) sharing one WTRU, one or more users (i.e., devices) behind one gateway WTRU, and / or one or more users (i.e., gaming applications) running on the same WTRU and each is treated as a different user.

[0109] According to various embodiments, the user identity could be something similar to the Network Access Identifier (NAI), wherein the NAI would have the form of username@realm, e g. bob@mno#2.com The realm part of the NAI may include mobile country code (MCC), mobile network code (MNC) and the network identification (NID) in case of the private networks (SNPN) of the Mobile network operator (MNO).

[0110] As previously mentioned, it is desirable to identify traffic of devices behind the RG. Methods disclosed herein are desired to enhance the 5G System (5GS) to allow for the creation and utilization of userspecific identities. A user-specific identity identifies the user of a WTRU. The user of a WTRU is the entity that generates traffic that a RG / WTRU sends or receives with a network. In this respect, according to various embodiments, a user maybe a human, an application, or device.

[0111] If operators are able to identify users, then operators will be able to provide a user-specific experience. For example, special services may be offered to some users, the traffic of some users may be given preferential treatment, and / or traffic that is associated with certain users might be charged differently.

[0112] As illustrated in FIG. 3 scenario 300, when a WTRU 325 sends data via an RG 315, the core network that the RG 315 is subscribed to cannot distinguish between traffic that originated at the RG 315 and traffic that originated in the device / WTRU 325. This is problematic in situations where the mobile network operator (MNO) that the RG 315 subscribes to (i.e. MNO#1 ) desires to distinguish between traffic that originated at the RG 315 and traffic that originated in a remote device / WTRU 325. For example, the core network of MNO#1 is able to identify the WTRU 325, then the treatment of traffic from the WTRU 325 can be based on the identity of the WTRU 325 instead of the identity of the RG 315. This may be desirable in scenarios where MNO#1 wishes to give preferential treatment to WTRUs that are subscribers of certain networks. The 3GPP system needs to be enhanced to be able to authenticate and authorize a tethered device’s (i.e., a device behind the RG), identify and what traffic comes from the tethered device so that it can apply different policies and forwarding treatment to the traffic that comes from the tethered device as compared to the policies and forwarding treatment that are applied to the traffic that is generated by applications that are hosted on the RG.

[0113] The following embodiments provide different mechanisms for the network to identify, authenticate and authorize users of devices (e.g. WTRU(s)) behind the RG. By enabling the identification, authentication, and authorization of device users behind the RG, the core network is able to configure policies and for the device’s traffic that are dependent on the identity that is associated with the device.

[0114] The device that connects via the RG may be configured with a user identity and / or credentials that are associated with the user identity. The credentials and user identity may be provided by a mobile network operator that the device subscribes to. For example, MNO#2 320 in the example of FIG 3 scenario 300 may have configured the user identity and credentials in a SIM card of the device. The user identity and credentials may also be provisioned in an AAA server (not shown) of MNO#2 320.

[0115] In one example procedure the RG is provisioned with URSP rules containing the traffic descriptor (TD) as the user identity (UID). The device while connecting to the RG will provide it’s UID, which will be used by the RG to either trigger PDU session establishment or modification. Upon reception of the UID, the SMF will be triggered to select the AAA server for authentication and authorization to authenticate the device behind the RG. During the authentication and authorization procedure, the RG may be provided with the IP address(es) of the N3IWF / TNGF via EAP messages. Once authentication and authorization is successful, the RG will be provided with the device-specific packet filters which will be applied by the RG to the UL traffic originating from the device.

[0116] In another example procedure the RG is provisioned with the URSP rules containing the traffic descriptor (TD) that aligned with the IP address of the N3IWF, e.g., the destination IP address. The device provides the UL traffic (IP packets) to the RG when the destination address matches the N3IWF. The IP addressmay be used by the RG to either trigger PDU session establishment or PDU session modification. The SMF will select the AAA server for authentication and authorization of the WTRU behind the RG based on the user identity that was provided in the PDU Session Establishment or PDU Session Modification message. Once authentication and authorization is successful, the RG will be provided with the device-specific packet filters which will be applied by the RG to the uplink traffic originating from the device and downlink traffic destined for the device.

[0117] Embodiments for using the traffic descriptor in the URSP rule as a user identity are now described. Referring to FIG. 4., an example method 400 is shown using a traffic descriptor in the URSP rules as a user identify for a device (e.g., WTRU#2) behind a residential gateway (e.g., WTRU#1). Entities shown in FIG 4 method 400 may include a WTRU / device (labeled WTRU#2), a residential gateway (RG) (labeled WTRU#1), an access and mobility management function (AMF)Zsession management function (SMF), a user plane function (UPF), an authentication, authorization and accounting (AAA) server and a data network (DN).

[0118] In method 400, the RG may be provisioned 402 with URSP rules that are enhanced to help the RG determine the characteristics of a PDU session to use to route traffic between a device and network For example, the traffic descriptor (TD) of a URSP Rule may include a user identifier or part of a user identifier (e.g. the realm part). A URSP rule that is formatted in this way can be used to indicate the PDU session characteristics that are necessary to route traffic from a device whose user identity matches the traffic descriptor. Thus, such a URSP rule can be used to ensure that the RG uses a PDU session for the device’s traffic that will send the data from the device to a data network that can be used to reach the N3IWF of the device’s home network (i.e. MNO#2 of FIG. 3).

[0119] Another principle of the example embodiment of FIG. 4, is that once the RG uses the URSP rule to select the characteristics of a PDU session to use to route traffic from the device, the RG will execute a PDU Session Establishment procedure to establish a new PDU session or a PDU Session Modification procedure if an existing PDU session is selected. In some embodiments, the PDU Session Establishment or PDU Session Modification procedure will trigger an EAP authentication and authorization procedure between the device and a AAA server of the device’s home network. Upon completion of the EAP authentication and authorization procedure, the SMF that serves the PDU session will send the RG packet filters that are associated with the PDU session and the device. The RG will only route traffic to / from the device if the traffic matches the packet filters. One advantage of this procedure is that the network will be able to recognize that all traffic that matches the packet filter is associated with the user identity and user specific policies can be configured by configuring policies for traffic that matches the filter.

[0120] As mentioned previously, in FIG. 4 method 400, the RG may be provisioned / configured 402 with one or more URSP rules. In one example, the URSP rules may have been received in a NAS message from the 5GC or the URSP rules may have been pre-configured in the RG via operations, administration and management (GAM) procedures. As described above, the traffic descriptor corresponding to the one or more of the URSP rules may include a user identifier or part of a user identifier (e.g., the realm or domain identifierpart). In one example, a policy control function (PCF) in the network (not shown) may have triggered sending the URSP rules to the RG. The PCF may have triggered the URSP rule update based on service parameters that were received from an application function (AF) (not shown). For example an AF of the MNO that the WTRU#2 subscribes to may have provided the service parameters to the PCF.

[0121] Next, the RG determines 404 the user identity (UID) of a device that is connected to the RG, e.g. in receiving a connection request from the device In this example, the device may be WTRU#2. In one example, WTRU#2 transmits its UID to the RG. For example, WTRU#2 may send the user identity to the RG as part of a procedure to gain access to data services via the RG. Alternatively, the RG may be configured with the user identity of WTRU#2. For example, a GUI maybe used to provide the RG with a mapping between a non-3GPP network identifier of WTRU#2 and a user identity. For example, the GUI may indicate that the MAC address of WTRU#2 is associated with a certain user identity.

[0122] In step 406, the RG determines to initiate a PDU Session Establishment procedure or a PDU Session Modification procedure. The RG determines to initiate a PDU Session Establishment procedure or a PDU Session Modification procedure based on detecting a connected device (i.e. WTRU#2) and that the device is associated with a user identity. In one example, the RG uses the URSP rules that were provisioned in step 402 of method 400 to determine whether a PDU Session Establishment procedure or a PDU Session Modification procedure should be initiated. If the URSP rules indicate that traffic that is associated with the user identity can be sent via an already established PDU session, then a PDU Session Modification procedure will be executed. If the URSP rules indicate that traffic that is associated with the user identity cannot preferably be sent via an already established PDU session, then a PDU Session Establishment procedure may be executed.

[0123] PDU Session Establishment and PDU Session Modification are examples of Session Management (SM) procedures. When the RG sends the NAS-SM request message to initiate the PDU Session Establishment / Modification, the RG may include a DN-Specific-ldentity information element and set the DN- Specific-ldentity information element equal to the user identity received from the WTRU#2, or derived for WTRU#2. Setting the DN-Specific-ldentity information element equal to the user identity indicates to the network that the PDU session will be used by the user that is associated with the user identity and WTRU#2. The NAS-SM request message may also indicate that the RG requests an IP address for the device that is associated with the user identity (i.e., WTRU#2).

[0124] Note that the URSP rule would have been configured so that the PDU session that was selected by the RG is associated with a DNN / S-NSSAI combination that is intended to serve a user that is identified by the user identifier. For example, all, or a sub-set, of subscribers of MNO#2 may have user identifiers that are associated with the same realm or domain-identifier. Thus, the URSP rule may be configured such that the RG will send all traffic that is from users that share a certain domain identifier to the same PDU session. Thus, all traffic that needs to reach the N3IWF of MNO#2 may be routed to a specific DNN / S-NSSAI combination. The S-NSSAI may be associated with a slice of MNO#1 that is used to handle traffic that goes to and / or from the N3IWF of MNO#2.

[0125] In FIG. 4 method 400, the SMF receives the NAS-SM request message and uses the user identity to select an AAA server. Alternatively, the SMF may have been configured to select an AAA server based on the DNN / S-NSSAI combination that is associated with the PDU session. The SMF will then send 408 an authentication / authorization request to the AAA server. In the example shown in FIG. 4, the AAA server may be the AAA server of MNO#2, whereas the remaining network entities shown are in MNO#1 .

[0126] In step 410, the WTRU#2 and AAA server may execute an EAP based authentication and authorization procedure. EAP messages are sent between WTRU#2 and the AAA server via the RG. In an example, EAP messages from the AAA server are received in a NAS message by the RG and the RG sends the EAP message to WTRU#2. EAP messages from WTRU#2 are received by the RG and the RG may send the EAP message to the AAA server via NAS messaging.

[0127] In Step 412, the AAA server indicates to the SMF that authentication and authorization of the user identity was successful. In an example, this message from the AAA server to the SMF may include data network (DN) authorization data. The DN authorization data may include one or more IP address and port number combinations. In one example, the combinations may be the IP address / port number combinations that the AAA server of MNO#2 authorizes the user to send data to and receive data from. For example, referring back to FIG. 3, the combinations may be the IP address / port number combinations that can be used by WTRU#2 to communicate with the N3IWF of MNO#2.

[0128] In FIG. 4 method 400, the SMF may allocate an IP address for the device (i e. WTRU#2). The SMF may send the allocated IP address to the AAA server. The AAA server may configure the N3IWF to accept traffic from the allocated IP address. This interaction between the SMF, AAA server, and N3IWF to share the allocated IP address is not separately shown.

[0129] The allocated IP address and IP address / port number combination(s) effectively form packet filters that screen the traffic that is allowed to be routed to and from WTRU#2 by the RG. In certain examples, the SMF may use these packet filters to create quality of service (QoS) rules, QoS profiles, and / or N4 rules to configure how WTRU#2’s traffic should be handled (the N4 interface in the 5GS architecture is responsible for the interaction between the SMF and UPF). The QoS rules may be sent to the WTRU, the QoS profiles may be sent to a radio access network (RAN) Node (e.g., base station) or wireline 5G access network (W-5GAN), and the N4 rules may be sent to a UPF. The allocated IP address and IP address / port number combination(s) may also be stored in a call data record (CDR) so that the user of WTRU#2 may be charged for traffic that is sent to and from WTRU#2 and so that the subscription of the RG will not be charged.

[0130] In FIG. 4 step 414, the SMF sends a PDU Session Establishment Accept message or a PDU Session Modification Command message in a response to the RG request PDU Session Establishment Accept or PDU Session Modification Command messages are both types of NAS-SM messages. The NAS-SM message from the SMF may indicate to the RG that the user of the device was successfully authorized and authenticated. The NAS-SM message from the SMF may include the user identity and the IP address / port numbercombination(s) that were received from the AAA server. Including the IP address / port number combination(s) that were received from the AAA server indicates to the RG that the device is only allowed to send and receive data using the indicated IP address / port number combination(s).

[0131] Inclusion of the IP address / port number combination(s) that were received from the AAA server may cause the RG to block any traffic that originates from the device and is sent towards an IP address and port number that does not match the allowed IP address / port number combination(s). In this regard, blocking traffic means that it will not be sent to the 5GC.

[0132] Inclusion of the IP address / port number combination(s) that were received from the AAA server may cause the RG to block any traffic that is sent to the device and originates from an IP address and port number that does not match the allowed IP address / port number combination(s) In this regard, blocking traffic means that it will not be sent to the device

[0133] The NAS-SM response message from the SMF at step 414 may include an IP address that should be assigned to the device (i.e. the allocated IP address) In certain embodiments, the IP address / port number combination(s) may have additional attributes e.g. precedence value, validity information (i.e. time validity (start / stop time, day of the week etc.), location validity information (linked with tracking area identities (TAIs) of the RG or geo-fencing location)), linkage of the packet filters with the UID (this information may be used to differentiate between multiple WTRUs behind the RG and application of the packet filters / precedence for the traffic matching the user identity) and / or an indication if the usage of the packet filters shall be reported back to the SMF / PCF (e.g., a flag) The SMF may remove / update these packet filters at any time using the PDU Session Modification procedure or other NAS Layer 3 signaling messages.

[0134] At step 416, the RG may send a message to WTRU#2 to indicate that the RG is able to provide WTRU#2 with data services, i.e., a connection response success message. In various embodiments the connection response message may include the allocated IP address. The message may include the IP address / port number combination(s). Alternatively, WTRU#2 and the RG may perform a DHCP procedure and the RG may provide the allocated IP address to WTRU#2 in this procedure.

[0135] When the RG receives UL traffic from WTRU#2, the traffic may target the IP address / port number combination. For example, the traffic maybe IPSec traffic that targets a N3IWF or TNGF, which may be associated with the IP address / port number combination. Since the traffic is aligned with the IP address / port number combination, the RG will permit the traffic and send it in the PDU session. If the RG receives traffic from WTRU#2 that is not aligned with the IP address / port number combination, then the RG may not permit the traffic to be sent in the PDU session.

[0136] In certain embodiments, the NAS-SM response message that was received in FIG 4 step 414 may have indicated to the RG that the RG should periodically report information about traffic that is originated by WTRU#2. The report may be sent to the SMF. Thus, the RG may trigger UL NAS signaling toward the SMF (e g. PDU session modification, UL NAS transport or other signaling messages) to inform the SMF about theUL traffic traversing through the RG A new or existing information element (IE) can be used to report this information. In certain examples, the reported information can include the user identifier, the data volume, the time when the data was generated, and / or the destination IP address.

[0137] It should be noted that the RG may perform the FIG 4 procedure 400 with multiple WTRUs. In one example, all the WTRUs may be subscribers of MNO#2. In this example, all the traffic to and from all the WTRUs may be sent via the same PDU Session. However, each WTRU may be associated with a different user identity. Each WTRU may execute a separate authentication and authorization procedure with the AAA server and the RG may be provided with different IP address / port number combinations for each WTRU. An advantage of this approach is that the WTRUs can share a PDU session. Another advantage of this approach is, when traffic from the WTRUs traverses the network, the network can recognize that the traffic is associated with each WTRU, record the information in CDRs, and configure QoS treatment based on the user identity.

[0138] In another example, some WTRUs may be subscribers of MNO#2 and other WTRUs behind the RG may be subscribers of a different MNO (e.g.,. MNO#3). In this example, all the traffic to and from all the WTRUs that are subscribers of MNO#2 may be sent via a first PDU session and all the traffic to and from all the WTRUs that are subscribers of MNO#3 may be sent via a second PDU session. An advantage of this approach includes that the WTRUs that are subscribers of MNO#2 would be associated with a PDU session that is associated with an AAA server of MNO#2 and the WTRUs that are subscribers of MNO#3 would be associated with a PDU session that is associated with an AAA server of MNO#3. Another advantage of this approach is traffic that is associated with different MNOs, would be separated into different PDU sessions. This may be advantageous because it may be necessary to send the traffic to different data networks since the traffic needs to be sent to a different respective N3IWF or TNGF.

[0139] Referring to FIG. 5, an example method 500 is shown for embodiments where the traffic descriptor (TD) in the URSP rule is associated with an identity of a non-3GPP InterWorking Function (N3IWF) or a trusted non-3GPP gateway function (TNGF). Entities shown in the example of FIG. 5 may be the same as those shown FIG. 4. In the example method 500, the RG may be provisioned 502 with URSP rules that are used by the RG to help determine the characteristics of a PDU session to use to route traffic to and from a remote / tethered device, e g., WTRU#2. For example, the TD of a URSP rule may include an IP address of a N3IWF or a TNGF (or portion thereof). A URSP rule that is formatted in this way can be used to indicate the PDU session characteristics that are necessary to route traffic from a device whose destination IP address matches the traffic descriptor. Thus, such a URSP rule can be used to ensure that the RG uses a PDU session for the device’s traffic that will send the data between the device and a data network that can be used to reach the N3IWF of the device’s home network (e.g., MNO#2 of FIG. 3).

[0140] Another principle of the example embodiment of FIG. 5, is that once the RG uses the URSP rule to select the characteristics of a PDU session to use to route traffic for the device, the RG will execute a PDU Session Establishment procedure to establish a new PDU session or a PDU Session Modification procedure if an existing PDU session is selected. In certain embodiments, the PDU Session Establishment or PDU SessionModification procedure may trigger an EAP authentication and authorization procedure between the device and an AAA serve of the device’s home network. Upon completion of the EAP authentication and authorization procedure, the SMF that serves the PDU session may send the RG packet filters that are associated with the PDU session and the device. The RG may only route traffic to / from the device if the traffic matches the packet filters. An advantage of this procedure is that the network will be able to recognize that all traffic that matches the packet filter is associated with the user identity and user-specific policies can be configured by configuring policies for traffic that matches the filter.

[0141] As mentioned, in method 500, the RG may be provisioned / configured 502 with URSP rules. In one example, the URSP rules may have been received in a NAS message from the 5GC or the URSP rules may have been pre-configured in the RG via OAM procedures. As described above, the traffic descriptor (TD) of one or more of the URSP rules may include IP address / port number combinations which could be associated with a N3IWF or TNGF

[0142] In one example, a PCF in the network (not shown) may have triggered sending the URSP rules to the RG. The PCF may have triggered the URSP rule update based on service parameters that were received from an AF For example, an AF of the MNO that the WTRU#2 subscribes to may have provided the service parameters to the PCF.

[0143] In example embodiments, the URSP rule may also be enhanced to indicate that the URSP rule only applies for certain specific user identity value(s) or certain user identity realm values. For example, a route selection descriptor (RSD) of the URSP rule may include a user identity or user identity realm value to indicate to the RG / WTRU that the route that is described by the RSD is only valid for traffic that is associated with the device whose user identity matches the value in the RSD.

[0144] In method 500, the WTRU#2 sends 504 a traffic request to provide UL traffic (IP packets) to the RG, and the traffic request may target a N3WIF or TNGF. The IP address / port number of the IP packet may be the IP address / port number of the N3IWF or TNGF and may match the IP address / port number of a traffic descriptor of a URSP rule that was provisioned in step 502. For example, the traffic may be IPSec traffic that targets a N3IWF or TNGF. The RG determines the user identity of the device that sent the IP packet. In the example of FIG.5, the device may be WTRU#2. In this example, WTRU#2 transmits WTRU#2’s user identity to the RG. For example, WTRU#2 may send the user identity to the RG as part of a procedure to gain / request access to network data services via the RG.

[0145] Alternatively, the RG may be configured with the user identity of WTRU#2. For example, a GUI maybe used to provide the RG with a mapping between a non-3GPP network identifier of WTRU#2 and a user identity. For example, the GUI may indicate that the MAC address of WTRU#2 is associated with a certain user identity.

[0146] In method 500, the RG determines to initiate 506 a PDU Session Establishment procedure or a PDU Session Modification procedure. The RG determines to initiate a PDU Session Establishment procedure or aPDU Session Modification procedure based on detecting a connected device (i.e. WTRU#2) and UL traffic (IP packets) have the target IP address / port number combination equal to one which is configured in the TD part of the URSP rules associated with the N3IWF / TNGF. The remaining portion of initiating 506 the PDU Session Establ ish ment / Modification procedure is similar to that of FIG. 4 method step 406.

[0147] In FIG. 5 method 500 steps 508, 510 and 512 may be similar to FIG 4 method 400 steps 408 through 418. In these steps, a PDU session is established or modified. Also, the device identity is authenticated and authorized. As described in the FIG 4 method 400, the IP address / port number combination(s) that were received from the AAA server indicate to the RG that the device is only allowed to send and receive data from the indicated IP address / port number combination(s). The RG will apply the traffic filters to the traffic originating from the WTRU#2 For example, if the traffic is aligned with the IP address / port number combination, the RG will permit the traffic and send it in the PDU session. If the RG receives traffic from WTRU#2 that is not aligned with the IP address / port number combination, then the RG may not permit the traffic and will not send it in the established / modified PDU session.

[0148] IP address management considerations according to the disclosed embodiments will now be described. As explained in the previous embodiment of FIG 4, in step 510 of FIG. 5, the NAS-SM message (e g., PDU Session Accept message from the SMF) may include an IP address that should be assigned to the device (i.e., the allocated IP address). The RG may assign the allocated IP address to the device in a DHCP procedure, and the allocated IP address may be used by the device in the local network of the RG.

[0149] Alternatively, the RG may perform a network address translation (NAT) operation. When performing a NAT operation, the RG may not send the allocated IP address to the device and instead send a private IP address to the device. For example, the RG may send the private IP address to the tethered device in a DHCP procedure. Furthermore, when the RG receives an uplink IP packet from the device, the RG may change a source IP address of the packet from the private IP address to the allocated IP address When the RG receives a downlink IP packet for the device, the RG may change a destination IP address of the packet from the allocated IP address to the private IP address. Similarly, the RG may instead map between an allocated IP address and port number combination and a private IP address and port number combination.

[0150] In certain example embodiments, the NAS-SM response message of step 510 of FIG. 5, may be further enhanced to indicate to the RG if NAT should be performed by the RG for traffic that is associated with the device. The SMF may determine whether to send this indication to the RG based on policy and charging control (PCC) rules that were received from the PCF. In this way, the PCF (and therefore the network) is able to control to what degree network assigned IP addresses are visible. For example, as described above a DNN / S-NSSAI combination may be dedicated to carrying traffic to a certain N3IWF or TNGF. The network operator may then configure a policy in the PCF to indicate that PDU sessions that are associated with the DNN / S-NSSAI combination should have NAT enabled Alternatively, the indication that NAT should be enabled for PDU sessions that are associated with the DNN / S-NSSAI combination may be stored in the WTRU’ssubscription information in the unified data management ( UD M) / u nified data repository (UDR). In one example, this information may be retrieved from the UDM / UDR by the SMF or PCF.

[0151] In certain cases, rejection may occur during PDU session establishment. As described above, for example in FIG. 4, method 400 step 406, the WTRU may send a PDU Session Establishment Request message to the network. The SMF may determine that the user identity that was provided in the PDU Session Establishment Request message is not permitted to be associated with the DNN and S-NSSAI combination provided in the PDU Session Establishment Request message. For example, the SMF may determine that the realm part of the provided user identity is not associated with a network operator whose traffic should be sent over the DNN and S-NSSAI combination. In one example, the SMF may receive an indication from the AAA server that authentication and authorization of the user identity failed. The indication from the AAA server may cause the SMF to determine that traffic that is associated with the user identity should not be sent over a PDU session that is associated with the DNN and S-NSSAI combination. When the SMF determines that the user identity that was provided in the PDU Session Establishment Request message is not permitted to be associated with the DNN and S-NSSAI combination that was provided in the PDU Session Establishment Request message, the SMF may: (i) send, to the WTRU, a PDU Session Establishment Reject Message with a 5GSM cause information element that, to the WTRU, indicates that the user identity is not permitted to be associated with the requested PDU session; or (ii) send, to the WTRU, a PDU Session Establishment Accept Message with an information element that indicates that the user identity is not permitted to be associated with the requested PDU session. For example, the NAS-SM message (i.e. PDU Session Establishment Accept) from the SMF to the RG / WTRU may include a list of user identities that are permitted to be associated with the PDU session.

[0152] In certain cases, rejection may occur during PDU session modification. As described above, for example in step 406 of the procedure 400 of FIG. 4, the WTRU may send a PDU Session Modification Request message to the network. The SMF may determine that the user identity that was provided in the PDU Session Modification Request message is not permitted to be associated with the PDU session (e.g., the user identity is not permitted to be associated with the DNN and S-NSSAI combination of the PDU session). For example, the SMF may determine that the realm part of the provided user identity is not associated with a network operator whose traffic should be sent over the DNN and S-NSSAI combination. For example, the SMF may receive an indication from the AAA server that authentication and authorization of the user identity failed.

[0153] The indication from the AAA server may cause the SMF to determine that traffic that is associated with the user identity should not be sent over a PDU session that is associated with the DNN and S-NSSAI combination. When the SMF determines that the user identity that was provided in the PDU Session Modification Request message is not permitted to be associated with the DNN and S-NSSAI combination of the PDU session, the SMF may: (i) send, to the RG, a PDU Session Modification Reject with a 5GSM cause information element that indicates that the user identity is not permitted to be associated with the requested PDU session; or (ii) send, to the RG, a PDU Session Modification Command message with an informationelement that indicates that the user identity is not permitted to be associated with the requested PDU session. For example, the NAS-SM response message (i.e. PDU Session Modification Command message) from the SMF to the RG / WTRU may include a list of user identities that are permitted to be associated with the PDU session.

[0154] When a 5GSM cause information element is sent to the WTRU that indicates that the user identity is not permitted to be associated with the requested PDU session, the information element may indicate if the user identity authentication and authorization failed, or user identity is not permitted to be associated with the PDU session but may be associated with a different PDU session. The WTRU / RG may use the information in the 5GSM cause information element to determine whether to attempt to associate the device’s traffic with a different PDU session.

[0155] URSP rule evaluation considerations are disclosed. As described in the procedures above, URSP rule evaluation may trigger the WTRU to transmit a PDU Session Establishment or PDU Session Modification message to request that a user identity be associated with a PDU session.

[0156] If the WTRU receives a PDU Session Modification Reject message or a PDU Session Establishment Reject message from the network, the WTRU may use the 5GSM cause information element in the message to determine whether to: (i) attempt to associate the device’s traffic with a different existing PDU session; (ii) attempt to establish a new PDU session and associate the device’s traffic with the new PDU session; (iii) block the device’s traffic; or (iv) route the traffic via a PDU session that is associated with the RG

[0157] For example, receiving an indication that authentication and authorization of the user identity failed may cause the RG to determine to block the device’s traffic or route the traffic via a PDU session that is associated with the RG. Routing the traffic via a PDU session that is associated with the RG means that the traffic is sent such that the network associates the traffic with the RG / WTRU and not the device Whether the RG blocks the traffic or routes the traffic via a PDU session that is associated with the RG may be determined based on local policies. In an example, the local policies may be configured via ATtention (AT) commands or a GUI.

[0158] For example, receiving an indication that the user identity cannot be associated with the DNN and S-NSSAI combination may cause the WTRU to attempt to associate the user identity with a different PDU session by repeating, for example, step 406 / 506 of the respective procedures of FIG. 4 or FIG. 5. In a similar way, the RG / WTRU may receive a PDU Session Establishment Accept message or a PDU Session Modification Command that lists user identities that may be associated with the PDU session. If the RG / WTRU does not receive an indication that a first device’s user identity may be associated with the PDU session, the RG / WTRU may continue with URSP rule evaluation for the device’s traffic or begin a new URSP rule evaluation.

[0159] Limiting the use of user identities may be included in certain embodiments. The RG / WTRU may receive a message from the network that indicates that the number of user identities that can be associated with a PDU session is limited. The size of the limit may be expressed in a number of user identities and maybe sent to the RG in a URSP rule. For example, a PCF may use local policies to determine a limit of user identities, and the limit may be included in URSP rule. In an example, the PCF may include the limit in the URSP rule used to route traffic to an N3IWF or a TNGF.

[0160] In certain solutions, the limit may be sent to the WTRU in a protocol configuration option (PCO) information element of a NAS-SM message (e.g. PDU Session Establishment Accept or PDU Session Modification command) from an SMF For example, a PCF may use local policies to determine a limit and the limit may be included in the PCC rules that the PCF sends to the SMF. The PCF may include the limit in the PCC rule based on the DNN and S-NSSAI combination of the PDU session being known to route traffic to an N3IWF or a TNGF

[0161] When a device is associated with a user identity and the device attempts to send traffic, the RG / WTRU may detect that the PDU session that should carry the traffic is already associated with a number of other devices that is equal to the limit that was provided by the network. In such a scenario, the RG / WTRU may decide, based on the PDU session having reached its limit, to block the device’s traffic or route the traffic via a PDU session that is associated with the RG. Routing the traffic via a PDU session that is associated with the RG means that the traffic is sent as traffic associated with the RG / WTRU, and not the device. Whether the RG blocks the traffic or routes the traffic via a PDU session that is associated with the RG may be determined based on local policies. As examples, the local policies may be configured via AT Commands or a GUI.

[0162] Referring to FIG. 6, a method 600 for a WTRU serving as a residential gateway (RG) for one or more devices is shown Method 600 may generally include the WTRU being provisioned / configured 605 with one or more URSP rules having traffic descriptors (TDs) associated with user identifiers (UIDs) or part of a UID. Next the RG / WTRU receives or determines 610 the user identify of a device wirelessly connecting / connected to the RG / WTRU, e.g., a WTRU that is using the RG / WTRU as a relay or tethered non- 3GPP device, denoted as WTRU#2. The RG / WTRU may determine to initiate 615 a PDU Session Establishment procedure or a PDU Session Modification procedure based on detecting WTRU#2 and its user identify. The RG / WTRU may use the URSP rules that were provisioned in step 605 to determine if a PDU Session Establishment procedure or a PDU Session Modification procedure should be initiated. If the URSP rules indicate that traffic associated with the user identity can be sent via an already established PDU session, then a PDU Session Modification procedure will be executed. If the URSP Rules indicate that traffic that is associated with the user identity cannot preferably be sent via an already established PDU Session, then a PDU Session Establishment procedure will be executed.

[0163] The RG / WTRU enables 620 WTRU#2 to connect with the AAA server of the corresponding MNO to perform an EAP procedure and get data network authorization. The network may allocate IP address and port number combinations for WTRU#2. User identity and IP address / port number combinations may then be received 625 by the RG / WTRU from the network, e.g., as part of a PDU Session Establishment Accept or PDU Session Modification Command, which effectively form packet filters that screen the traffic allowed to be routed to and from WTRU#2 as previously discussed The RG / WTRU may then route traffic 630 between WTRU#2and the network using the received information. Also, as described previously, if DN authorization is denied, the RG / WTRU may block traffic flow from WTRU#2 or use its own PDU session to deliver WTRU#2 traffic depending on local policies.

[0164] Referring to FIG. 7, an example method 700 is shown for a network accepting or rejecting traffic flows from a device connected to a residential gateway (RG). As described in previous embodiments, for example in step 406 of the procedure of FIG. 4, the RG / WTRU may send a PDU Session Establishment Request / Modification message to the network, e.g , a session management function (SMF), including a DN- specific ID, e.g., domain identifier or IP address, as the UID or part of the UID The SMF receives 705 the PDU session request and may determine 710 whether the user identity that was provided in the PDU Session Establishment / Modification Request message is permitted to be associated with the DNN and S-NSSAI combination provided in the PDU Session Establishment / Modification Request message and, if so, determines 715 whether the AAA server authentication and authorization of the user identity has failed. If 710, the UID is not permitted or if 715, authentication and authorization failed, the network, e.g., the SMF, will notify 720 the RG / WTRU that the PDU session cannot be established or modified for the connected device traffic. In preferred embodiments, a PDU session rejection response message may be sent to the RG / WTRU including reasons for rejection. On the other hand, if 710, the UID is permitted and if 715, authentication and authorization has not failed (i.e., was successful), the network, e.g., the SMF, will send 725 a PDU session response to the RG / WTRU establishing / modifying the PDU session. In an example the PDU session response may indicate the UID and IP address / port number combinations which may be used as packet filters by the RG in routing traffic between the RG and DN for the device. As in other embodiments discussed, IP address translation, e.g., NAT, may be indicated enabled or disabled by the PDU session response. In optional embodiments, the network may alternatively decline PDU session modification if the number of user identifies associated with the PDU session has reached the limited number of users, as described previously

[0165] 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 by a wireless transmit receive unit (WTRU), the method comprising: receiving, from a network, at least one user equipment route selection policy (URSP) rule and a related traffic descriptor (TD); determining a user identity (UID) of a connected device requesting to send traffic in the network through the WTRU; based on the UID corresponding to the related TD of the at least one URSP rule, determining a data network name (DNN) and single network slice assistance information (S-NSSAI) combination; sending, to the network, a non-access stratum (NAS) request message including the UID to establish or modify a packet data unit (PDU) session associated with the determined DNN and S-NSSAI combination; receiving, from the network, a NAS response message indicating at least one internet protocol (IP) address and port combination assigned for the traffic of the connected device; and routing the traffic between the connected device and the network based on the indicated at least one IP address and port combination.

2. The method of claim 1, wherein the NAS request message comprises a PDU Session Establishment request indicating the determined DNN and S-NASSAI combination.

3. The method of claim 1, wherein the NAS request message comprises a PDU Session Modification request for a PDU session already associated with the determined DNN and S-NSSAI combination.

4. The method of claim 1, wherein the related TD includes, at least part of the UID.

5. The method of claim 1, wherein the UID relates to a destination IP address of the traffic and wherein the related TD includes an IP address of a non-3GPP interworking function (N3IWF) or a trusted non-3GPP gateway function (TNGF) and an IP address and port number combination associated with the N3IWF or the TNGF.

6. The method of claim 1, wherein the UID is determined based on a medium access control (MAC) address of the connected device and a configuration that maps the MAC address to the UID.

7. The method of claim 1 , wherein the NAS response message further indicates one or more of a precedence value, a time validity, a location validity, one or more packet filters linked with the UID and if usage of the one or more packet filters should be reported to the network.

8. The method of claim 1, where the NAS response message further indicates if network address translation (NAT) should be performed for the traffic of the connected device.

9. A wireless transmit receive unit (WTRU) comprising: a transceiver and a processor operatively coupled with the transceiver, wherein the transceiver and processor are configured to: receive, from a network, at least one user equipment route selection policy (URSP) rule and a related traffic descriptor (TD); determine a user identity (U ID) of a connected device requesting to send traffic in the network through the WTRU; based on the UID corresponding to the related TD of the at least one URSP rule, determine a data network name (DNN) and single network slice assistance information (S-NSSAI) combination; send, to the network, a non-access stratum (NAS) request message including the UID to establish or modify a packet data unit (PDU) session associated with the determined DNN and S-NSSAI combination; receive, from the network, a NAS response message indicating at least one internet protocol (IP) address and port combination assigned for the traffic of the connected device; and route the traffic between the connected device and the network based on the indicated at least one IP address and port combination.

10. The WTRU of claim 9, wherein the NAS request message comprises a PDU Session Establishment request indicating the determined DNN and S-NASSAI combination.

11. The WTRU of claim 9, wherein the NAS request message comprises a PDU Session Modification request for a PDU session already associated with the determined DNN and S-NSSAI combination.

12. The WTRU of claim 9, wherein the related TD includes, at least part of the UID.

13. The WTRU of claim 9, wherein the UID relates to a destination IP address of the traffic and wherein the related TD includes an IP address of a non-3GPP interworking function (N3IWF) or a trusted non-3GPP gateway function (TNGF) and an IP address / port number combination associated with the N3IWF or the TNGF.

14. The WTRU of claim 9, wherein the UID is determined based on a medium access control (MAC) address of the connected device and a configuration that maps the MAC address to the UID.

15. The WTRU of claim 9, wherein the NAS response message further indicates one or more of a precedence value, a time validity, a location validity, one or more packet filters linked with the UID and if usage of the one or more packet filters should be reported to the network.

16. A method for a session management function (SMF), the method comprising: receiving, from a wireless transmit receive unit (WTRU), a non-access stratum (NAS) message request to establish or modify a packet data unit (PDU) session for transporting traffic of a device connectedto the WTRU through a network, wherein the NAS message request indicates a user identify (U ID) for the traffic of the device; determining whether the UID is permitted for a data network name (DNN) and single network slice selection assistance information (S-NSSAI) combination and whether the UID is authorized; and based on determining whether the UID is permitted and whether the UID is authorized, sending a NAS message response to the WTRU indicating whether the PDU session will or will not be established or modified.

17. The method of claim 16, wherein determining whether the UID is permitted further comprises determining whether the UID is authenticated.

18. The method of claim 16, wherein the NAS message request comprises a PDU Session Modification request for a PDU session already associated with the DNN and S-NSSAI combination.

19. The method of claim 16, wherein the NAS message response indicates the PDU session will be established or modified, and further indicates at least one internet protocol (IP) address and port combination to transport the traffic of the device.

20. The method of claim 16, wherein the NAS message response indicates the PDU session will not be modified and further includes a 5G session management (5GSM) cause information element indicating a reason the connected device is not permitted because the PDU Session is already associated with a maximum number of connected devices.

Images