Cross-referencing service delivery related applications for multi-user mobile terminals

Abstract

The invention discloses cross-referencing service delivery related applications for multi-user mobile terminals. An electronic device according to an embodiment is configured to transmit a link request message to a wireless network, the link request message requesting to associate a user identifier with an identifier corresponding to the electronic device; receiving a registration response from the wireless network, the registration response confirming that the user identifier has been associated with the identifier corresponding to the electronic device; and receiving updated configuration information of the electronic device from the wireless network, wherein at least part of the configuration information is associated with the user identifier.

Description

[0001] This application is a divisional application of an invention patent application with an application date of June 5, 2020, application number 202080051321.8, and invention name “Cross-reference to related applications for service delivery for multi-user mobile terminals”.

[0002] Citation of Related Applications

[0003] This application claims priority to U.S. Provisional Application No. 62 / 858,565, filed on June 7, 2019, and U.S. Provisional Application No. 62 / 899,202, filed on September 12, 2019, which are incorporated herein by reference in their entirety. Technical Field

[0004] The present disclosure relates generally to wireless communications and, more particularly, to wireless communications systems, devices, methods, and computer-readable media having computer-readable instructions for authenticating a user and linking the user with a subscription of a mobile terminal. Background Art

[0005] The "background technology" description provided herein is intended to generally present the context of the present disclosure. To the extent described in this background technology section, the work of the presently named inventors, as well as various aspects of the description that may not constitute prior art at the time of filing this application, are neither explicitly nor implicitly admitted to be prior art against the present invention.

[0006] Reference [1], 3GPP TR 22.904 describes a use case in which it is advantageous for a 3GPP system to identify a user of a UE.

[0007] A use case in reference [1] describes a scenario where two children, Lucy and Linus, sometimes use their mother's UE. It is desirable to enhance the 3GPP system so that the network can identify when Lucy or Linus is using the UE so that the network provides different services to the UE depending on who is using the UE. For example, the network can provide web filtering when Lucy or Linus is using the UE. In addition, the network can apply different time limits for each user. This scenario means that the network maintains a profile for each user, and the profile contains information about what UE (i.e., subscription) the user can use to access the network and what services each user is allowed to access.

[0008] Thus, the network should consider who is using the UE before granting access to a service. Summary of the invention

[0009] An example embodiment of the present disclosure provides an electronic device (e.g., UE), which is configured to send a link request message to a wireless network, the link request message requesting to associate a user identifier with an identifier corresponding to the electronic device; receive a registration response from the wireless network, the registration response confirming that the user identifier has been associated with the identifier corresponding to the electronic device; and receive updated configuration information of the electronic device from the wireless network, wherein at least part of the configuration information is associated with the user identifier.

[0010] This summary is provided to introduce some concepts in a simplified form, which will be further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to limitations that solve any or all deficiencies mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The scope of the present disclosure may be better understood from the following detailed description of example embodiments when read in conjunction with the accompanying drawings, in which:

[0012] Figure 1A is a system diagram representing an example 3GPP architecture;

[0013] Figure 1B is a system diagram showing an example of a radio access network (RAN) architecture and a core network architecture;

[0014] Figure 1C is a system diagram showing an example of a radio access network (RAN) architecture and a core network architecture;

[0015] Figure 1D is a system diagram showing an example of a radio access network (RAN) architecture and a core network architecture;

[0016] Figure 1E is a system diagram representing an example 3GPP architecture;

[0017] Figure 1F is a system diagram of an example apparatus or device configured for wireless communication;

[0018] Figure 1G is a system diagram showing an example of a computing system for use in a communications network;

[0019] Figure 2 represents a 5G UE authentication process according to an example embodiment;

[0020] Figure 3 represents a policy set entry according to an example embodiment;

[0021] Figure 4 represents an EAP architecture according to an example embodiment;

[0022] Figure 5 represents a network slice-specific authentication and authorization process according to an example embodiment;

[0023] Figure 6 represents a UE initiated linking procedure according to an example embodiment;

[0024] Figure 7 represents a process of obtaining user-aware permission NSSAI according to an example embodiment;

[0025] Figure 8 represents policy set entry association information according to an example embodiment; and

[0026] Fig. 9 Shown is a GUI for linking and unlinking user IDs according to an example embodiment.

[0027] Fig.10 Indicates the process of establishing authentication / authorization through the PDU session of the DN-AAA server.

[0028] Fig.11 Represents the procedure for PDU session establishment requested by non-roaming and local breakout roaming UEs.

[0029] Fig.12 Indicates the procedure for PDU session modification (non-roaming and local-guided roaming) requested by the UE or the network.

[0030] Fig.13 Indicates the QoS rule information element.

[0031] Fig.14 Indicates QoS rule (u=m+2).

[0032] Fig.15 Indicates the format of the User-centric QoS Rule IE.

[0033] Fig.16 Represents the format of a User-centric QoS Rules IE with multiple User IDs.

[0034] Fig.17 Represents the enhanced procedure for UE-requested PDU session establishment with UCQR delivery for non-roaming and local breakout roaming.

[0035] Fig.18 Represents the enhanced procedure for UE or network requested PDU Session Modification (for non-roaming and local breakout roaming) with UCQR delivery.

[0036] Fig.19Represents an enhanced network slice-specific authentication and authorization process with UCQR delivery.

[0037] Fig. 20 Represents the enhanced procedure for PDU session establishment authentication / authorization of DN-AAA server with UCQR delivery.

[0038] Fig.21 Represents the format of the User-centric QoS Rules IE with implicit User ID indication.

[0039] Fig. 22 A GUI showing a multi-user UE receiving a UCQR according to an example embodiment.

[0040] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of the example embodiments is for illustration only, and thus is not necessarily intended to limit the scope of the present disclosure. DETAILED DESCRIPTION

[0041] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also referred to as "5G". 3GPP NR standards development is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new non-backwards compatible radio access in new spectrum below 7 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with sub-7 GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0042] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which can include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and communications between vehicles and other entities. Specific services and applications within these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud office, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and aerial drones, to name a few. All of these use cases and others are contemplated in this article.

[0043] The following is a list of acronyms related to service levels and core network technologies that may appear in the description below. Unless otherwise stated, the acronyms used in this article refer to the corresponding terms listed below.

[0044] Table 1. Abbreviations

[0045] Example Communication Systems and Networks

[0046] Figure 1A An example communication system 100 is illustrated in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, generally or collectively referred to as WTRUs 102. The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. 113. The network services 113 may include, for example, a V2X server, a V2X function, a ProSe server, a ProSe function, an IoT service, video streaming, and / or edge computing, etc.

[0047] It should be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figure 1A In the example of Figures 1A-1E . It should be understood that, for various use cases contemplated for wireless communication, each WTRU may include or be included in any type of device or apparatus configured to send and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, a bus or a truck, a train, or an airplane, etc.

[0048] The communication system 100 may also include a base station 114a and a base station 114b. Figure 1A In the example of FIG. 1 , each base station 114 a and 114 b is depicted as a single element. In practice, the base stations 114 a and 114 b may include any number of interconnected base stations and / or network elements. The base station 114 a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 a, 102 b, and 102 c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. Similarly, the base station 114 b may be any type of device configured to interface wired and / or wirelessly with at least one of the remote radio heads (RRHs) 118 a, 118 b, the transmit and receive points (TRPs) 119 a, 119 b, and / or the roadside units (RSUs) 120 a and 120 b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. The RRHs 118 a, 118 b may be any type of device configured to interface wirelessly with at least one of the WTRUs 102, such as the WTRU 102 c, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112.

[0049] The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node-Bs, eNode Bs, Home Node Bs, Home eNode Bs, next generation Node-Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, and the like.

[0050] The base station 114a may be part of the RAN 103 / 104 / 105, 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), a relay node, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a BSC, an RNC, a relay node, etc. The base station 114a may be configured to send and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to send and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may include three transceivers, eg, one transceiver for each sector of the cell. The base station 114a may employ multiple-input multiple-output (MIMO) technology and thus, for example, may use multiple transceivers for each sector of the cell.

[0051] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0052] The base station 114b may communicate with one or more of the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable RAT.

[0053] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c may be established using any suitable RAT.

[0054] The WTRUs 102 may communicate with each other via a direct air interface 115d / 116d / 117d, such as a sidelink communication, and the air interface 115d / 116d / 117d may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d may be established using any suitable RAT.

[0055] The communication 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, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0056] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c and 102g, or the RRHs 118a and 118b, TRPs 119a and 119b and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c and 102d may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish an air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using, for example, Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communications, etc.). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0057] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g, or the RRHs 118a and 118b, the RPs 119a and 119b, and / or the RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, 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) etc.

[0058] Figure 1A The base station 114c in the example may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a train, an airplane, a satellite, a factory, a campus, and the like. The base station 114c and the WTRU 102, such as the WTRU 102e, may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102, such as the WTRU 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102, such as the WTRU 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a pico cell or a femto cell. Figure 1A As shown in FIG, the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0059] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0060] Although not in Figure 1A 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM or NR radio technology.

[0061] The core network 106 / 107 / 109 may also serve as a gateway for the WTRU 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. Other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include any type of packet data network (e.g., IEEE 802.3 Ethernet) or another core network connected to one or more RANs, which may use the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

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

[0063] Although not in Figure 1A 106 / 107 / 109. It is shown in the figure, however, it is appreciated that the user equipment can establish a wired connection to the gateway. The gateway can be a residential gateway (RG). The RG can provide connectivity with the core network 106 / 107 / 109. It is appreciated that many of the concepts contained herein can be equally applied to a UE that is a WTRU and a UE that uses a wired connection to connect to the network. For example, the concepts applied to the wireless interfaces 115, 116, 117 and 115c / 116c / 117c can be equally applied to wired connections.

[0064] Figure 1B 1 is a system diagram of an example RAN 103 and a core network 106. As described above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Figure 1B As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, and 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and radio network controllers (RNCs).

[0065] like Figure 1BAs shown in , Node-B 140a, 140b can communicate with RNC 142a. In addition, Node-B 140c can communicate with RNC 142b. Node-B 140a, 140b and 140c can communicate with corresponding RNC 142a and 142b via Iub interface. RNC 142a and 142b can communicate with each other via Iur interface. Each of RNC 142a and 142b can be configured to control the corresponding Node-B 140a, 140b and 140c connected thereto. In addition, each of RNC 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0066] Figure 1B The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the above elements is depicted as part of the core network 106, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0067] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices.

[0068] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0069] The core network 106 may also be connected to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0070] Figure 1C1 is a system diagram of an example RAN 104 and a core network 107. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

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

[0072] Each of the eNode-Bs 160a, 160b, and 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 uplink and / or downlink, etc. Figure 1C As shown in FIG. 1 , eNode-Bs 160a , 160b , and 160c may communicate with each other via an X2 interface.

[0073] Figure 1C The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the above elements is depicted as part of the core network 107, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0074] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c 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, and 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

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

[0076] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 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.

[0077] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices. For example, the core network 107 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0078] Figure 1D 1 is a system diagram of an example RAN 105 and a core network 109. The RAN 105 may employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A non-3GPP interworking function (N3IWF) 199 may employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

[0079] The RAN 105 may include gNode-Bs 180a and 180b. It is to be appreciated that the RAN 105 may include any number of gNode-Bs. The gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When an integrated access and backhaul connection is used, the same air interface may be used between the WTRUs and the gNode-Bs, which may be a core network 109 via one or more gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the gNode-B 180a may, for example, use multiple antennas to send wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. It is to be appreciated that the RAN 105 may employ other types of base stations, such as an eNode-B. It is also to be appreciated that the RAN 105 may employ more than one type of base station. For example, the RAN may employ both eNode-Bs and gNode-Bs.

[0080] The N3IWF 199 may include a non-3GPP access point 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c over the air interface 198 using the 802.11 protocol.

[0081] The gNode-Bs 180a and 180b may each be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink or downlink, etc. Figure 1D As shown in FIG. , gNode-Bs 180a and 180b may communicate with each other via an Xn interface, for example.

[0082] Figure 1D The core network 109 shown in the figure can be a 5G core network (5GC). The core network 109 can provide numerous communication services to customers interconnected by a radio access network. The core network 109 includes multiple entities that perform the functions of the core network. The terms "core network entity" or "network function" as used herein refer to any entity that performs one or more functions of the core network. It should be understood that such a core network entity can be a logical entity implemented in the form of computer executable instructions (software) stored in a device configured for wireless and / or network communications, or a computer system, such as Figure 1GThe system 90 shown in the diagram is stored in a memory and executed on a processor thereof.

[0083] exist Figure 1D In the example of , the 5G core network 109 may include access and mobility management function (AMF) 172, session management function (SMF) 174, user plane function (UPF) 176a and 176b, user data management function (UDM) 197, authentication server function (AUSF) 190, network open function (NEF) 196, policy control function (PCF) 184, non-3GPP interworking function (N3IWF) 199, user data repository (UDR) 178. Although each of the above elements is depicted as part of the 5G core network 109, it is to be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator. It is also to be appreciated that the 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. Figure 1D The network functions are shown as being directly connected to each other, although it will be appreciated that they may communicate via a routing agent, such as a diameter routing agent, or a message bus.

[0084] exist Figure 1D In the example of , the connectivity between network functions is achieved via a set of interfaces or reference points. It is to be appreciated that network functions can be simulated, described or implemented as a set of services that are invoked or called by other network functions or services. The invocation of network function services can be achieved via direct connections between network functions, exchange of messages on a message bus, calling software functions, etc.

[0085] The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to and from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not used in Figure 1D Shown in.

[0086] The SMF 174 may be connected to the AMF 172 via an N11 interface. Similarly, the SMF may be connected to the PCF 184 via an N7 interface and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

[0087] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be Ethernet or any type of network that switches data packets. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to the packet data network by connecting to the packet data network using the N6 interface, or by connecting to each other and to other UPFs via the N9 interface. In addition to providing access to the packet data network, UPF 176 may also be responsible for packet routing and forwarding, policy rule enforcement, quality of service processing for user plane traffic, and downlink packet buffering.

[0088] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates connectivity between, for example, the WTRU 102c and the 5G Core Network 170, via a radio interface technology not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0089] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to application function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not implemented in Figure 1D1. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to implement these rules. The PCF 184 may send the policy to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF may deliver the policy to the WTRUs 102a, 102b, and 102c via the N1 interface. The policy may then be implemented or applied at the WTRUs 102a, 102b, and 102c.

[0090] The UDR 178 may serve as a repository for authentication credentials and subscription information. The UDR may be connected to a network function so that the network function can add data to, read data from, and modify data in the repository. For example, the UDR 178 may be connected to the PCF 184 via an N36 interface. Similarly, the UDR 178 may be connected to the NEF 196 via an N37 interface, and the UDR 178 may be connected to the UDM 197 via an N35 interface.

[0091] The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may authorize network functions to access the UDR 178. For example, the UDM 197 may be connected to the AMF 172 via the N8 interface, and the UDM 197 may be connected to the SMF 174 via the N10 interface. Similarly, the UDM 197 may be connected to the AUSF 190 via the N13 interface. The UDR 178 and the UDM 197 may be tightly integrated.

[0092] AUSF 190 performs authentication-related operations, is connected to UDM 178 via an N13 interface, and is connected to AMF 172 via an N12 interface.

[0093] NEF 196 opens capabilities and services in 5G core network 109 to application function (AF) 188. The opening can occur on the N33 API interface. NEF can be connected to AF 188 via the N33 interface, and it can be connected to other network functions to open capabilities and services of 5G core network 109.

[0094] The application function 188 may interact with the network functions in the 5G core network 109. The interaction between the application function 188 and the network functions may occur via a direct interface or may occur via the NEF 196. The application function 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by an enterprise having a business relationship with a mobile network operator.

[0095] Network slicing is a mechanism that can be used by mobile network operators to support one or more 'virtual' core networks behind the operator's air interface. This involves 'slicing' the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios with diverse requirements in terms of functionality, performance and isolation, for example.

[0096] 3GPP has designed the 5G core network to support network slicing. Network slicing is a good tool that network operators can use to support a diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) that require very diverse and sometimes extreme requirements. Without the use of network slicing technology, when each use case has its own specific set of performance, scalability, and availability requirements, it is likely that the network architecture will not be flexible and scalable enough to effectively support a wider range of use case requirements. In addition, the introduction of new network services should be made more efficient.

[0097] See again Figure 1D In a network slicing scenario, the WTRU 102a, 102b, or 102c may be connected to the AMF 172 via the N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more UPFs 176a and 176b, SMF 174, and other network functions. Each of the UPFs 176a and 176b, SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in terms of the different computing resources, security credentials, etc. that they may utilize.

[0098] The core network 109 may facilitate communications with other networks. For example, the core network 109 may include an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the 5G core network 109 and the PSTN 108, or may communicate with the IP gateway. For example, the core network 109 may include a short message service (SMS) service center that facilitates communications via a short message service, or may communicate with the short message service (SMS) service center. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and a server or application function 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0099] Described in this article and Figure 1A , 1C The core network entities illustrated in 1D and 1E are identified using the names given to these entities in certain existing 3GPP specifications, but it should be understood that in the future, these entities and functions may be identified with other names, and in future specifications released by 3GPP, including future 3GPP NR specifications, some entities or functions may be combined. Figure 1A , 1B The specific network entities and functions described and illustrated in 1C, 1D and 1E are provided as examples only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system (whether currently defined or defined in the future).

[0100] Figure 1E The diagram illustrates an example communication system 111 in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One or several or all of the WTRUs A, B, C, D, E, and F may be outside the range of the access network coverage 122. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members.

[0101] WTRUs A, B, C, D, E, and F may communicate with each other via gNB 121 over the Uu interface 129b if they are within the coverage of the access network (in Figure 1E , only B and F are shown within network coverage). WTRUs A, B, C, D, E, F may communicate directly with each other via sidelink (PC5 or NR PC5) interfaces 125a, 125b, 128 if they are within or outside the access network coverage (WTRUs A, B, C, D, E, F may communicate with each other, e.g., within Figure 1E In the figure, A, C, D and E are indicated outside the network coverage).

[0102] WTRUs A, B, C, D, E, and F may communicate with the RSU 123a or 123b via the vehicle-to-network (V2N) interface 126 or the sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate with the V2X server 124 via the vehicle-to-infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with other UEs via the vehicle-to-pedestrian (V2P) interface 128.

[0103] Figure 1F is an example apparatus or device WTRU 102 that may be configured for wireless communication and operation in accordance with the systems, methods, and apparatus described herein, such as Figure 1A , 1B , 1C, 1D, or 1E. Figure 1F As shown in the example WTRU 102, the example 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 / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It is to be appreciated that the WTRU 102 may include any sub-combination of the above elements. In addition, the base stations 114a and 114b and / or the base stations 114a and 114b may represent nodes such as, but not limited to, a transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, a next generation node-B (gNode-B), and a proxy node, etc., and may include Figure 1F Some or all of the elements depicted in and described herein.

[0104] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1F The processor 118 and the transceiver 120 are depicted as separate components, although it is appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0105] The transmit / receive element 122 of the UE may be configured to transmit data to a base station (eg, Figure 1A 114a) to send signals to or from a base station (e.g., Figure 1A The base station 114a) receives signals from the base station 114a), or sends signals to other UEs or receives signals from other UEs through the air interface 115d / 116d / 117d. For example, the send / receive element 122 can be an antenna configured to send and / or receive RF signals. The send / receive element 122 can be, for example, a transmitter / detector configured to send and / or receive IR, UV or visible light signals. The send / receive element 122 can be configured to send and receive both RF signals and optical signals. It should be appreciated that the send / receive element 122 can be configured to send and / or receive any combination of wireless signals or wired signals.

[0106] In addition, although the transmit / receive element 122 is Figure 1F Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, 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 115 / 116 / 117.

[0107] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 or NR and E-UTRA, or to communicate using the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

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

[0109] The processor 118 may obtain power from the power source 134 and may be configured to distribute power to and / or control 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, solar cells, fuel cells, etc.

[0110] 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 from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method.

[0111] The processor 118 may also 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 various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0112] The WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. The WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0113] Figure 1G is a block diagram of an example computing system 90 in which Figure 1A , 1C , 1D and 1E, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112 or network services 113. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or how such software is stored or accessed. Such computer-readable instructions may be executed within the processor 91 to enable the computing system 90 to work. The processor 91 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 associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0114] In operation, processor 91 retrieves, decodes and executes instructions and transfers information to and from other resources via the computing system's main data transfer path, system bus 80. Such a system bus connects components in computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0115] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes is set, it cannot access memory within the virtual address space of another process.

[0116] In addition, the computing system 90 may include a peripheral device controller 83 , which is responsible for communicating instructions from the processor 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0117] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0118] In addition, the computing system 90 may include a plurality of components that can be used to connect the computing system 90 to external communication networks or devices (such as Figure 1A , 1B, RAN 103 / 104 / 105 of 1C, 1D and 1E, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102 or other network 112) to enable the computing system 90 to communicate with other nodes or functional entities of these networks, such as communication circuits such as wireless or wired network adapter 97. The communication circuits can be used alone or in combination with the processor 91 to perform the sending and receiving steps of certain devices, nodes or functional entities described herein.

[0119] It should be understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor, such as processor 118 or 91, causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-temporary (e.g., tangible or physical) method or technology for storage of information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical media that can be used to store the desired information and can be accessed by a computing system.

[0120] Detailed Description

[0121] The present disclosure relates to a configuration in which a UE is configured to detect certain events that cause the UE to request the network to authenticate the user and to link the user with the UE's subscription. This may cause the network to provide updated configured NSSAI to the UE. Each of the updated configured NSSAIs is associated with one or more user identifiers.

[0122] The present disclosure also describes how the UE can determine to send a new Requested NSSAI and receive a new Allowed NSSAI once a user is linked to the UE's subscription, where the S-NSSAI in the new Requested NSSAI and the Allowed NSSAI are associated with the user identifier.

[0123] The present disclosure also describes an efficient way to associate a user ID with policy information. A user identifier can be associated with a PSI so that the format and content of the PSI and URSP policy can remain largely unchanged, and changes in user activity, associations, or links do not result in the network needing to send a new PSI to the UE.

[0124] This disclosure also describes what events may cause the UE to request updated PSI / user association information from the network.

[0125] Subscription Identifier

[0126] In 3GPP system, IMSI (International Mobile Subscriber Identity) is a subscription identifier. IMSI consists of 3 fields.

[0127] MCC (Mobile Country Code)

[0128] MNC (Mobile Network Code)

[0129] MSIN (Mobile Subscription Identification Number)

[0130] IMSI is a type of SUPI.

[0131] Device identifier

[0132] In the 3GPP system, IMEI (International Mobile Equipment Identity) is a device identifier used to identify a UE.

[0133] In the IEEE 802 system, a MAC (Media Access Control) address is a device identifier for identifying a network interface controller.

[0134] User Identifiers, User Profiles, and Subscriptions

[0135] 3GPP has studied how 3GPP should be enhanced to support a user-centric authentication layer on top of the existing subscription authentication. The results of this study have been collected in reference [1].

[0136] The study evaluated how the 3GPP system can provide customized services to different users using the same UE, how to identify users with devices behind a gateway that have a 3GPP subscription (but not devices with dedicated 3GPP subscriptions), and how to access 3GPP services via non-3GPP access using user identifiers linked to subscriptions.

[0137] The user identification code in the 3GPP system should identify the user and the mobile network operator (MNO) associated with the user. The MNO has a business relationship with the user and is responsible for authenticating and authorizing user requests and maintaining information records associated with the user.

[0138] Since the 3GPP user identifier identifies at least 2 entities (i.e., the user and the MNO), it may have 2 fields. For example, it may be formatted as: "user-name@mno-name", where the user-name portion of the identifier may be an alphanumeric string that resolves to the user identifier.

[0139] There may be different formats of 3GPP user identification codes. For example, an external format may be used on an interface external to 5GC, while an internal format may be used on an interface internal to 5GC.

[0140] There may also be different types of 3GPP user identifiers. One type of 3GPP user identifier may identify a person (e.g., a name or alias). Another type of 3GPP user identifier may identify a non-3GPP device. For example, an application identifier that identifies a smart watch. It is expected that the 5GC will maintain user profiles for each user it may know. The user profile may contain details about the user in the UE, and the UE subscription may include the user ID of the user of the UE. The user profile may be linked to the subscription, where there may be a many-to-many relationship between the user profile and the subscription. The user ID may be represented as a key between the UE / user subscription to the user profile. The linking operation may be based on events in the network, such as an administrator or third party creating / updating a user profile or subscription. The fact that the user profile is linked to the subscription is an indication in the 5GC that the user can access the system using the UE associated with the subscription. The user ID may vary based on the system in which the user is registered.

[0141] Registration, configuration update and PDU session related processes

[0142] 5G Registration, PDU Session Establishment and Service Request procedures are used to activate, reactivate and deactivate PDU sessions. Table 2 shows information about these three procedures and the configuration update procedure.

[0143] Table 2. Registration, PDU creation, service request, and configuration update process

[0144] 5GC Certification Process

[0145] The 5G UE authentication process is described in Section 5.2.10.2.3 of Reference [6]. A copy of the process is shown in Figure 2 The AMF may invoke the Nausf_UEAuthentication_Authenticate procedure during UE registration to authenticate the UE using the UE's SUPI (i.e., IMSI).

[0146] Identifying network slices

[0147] Network slices are identified by S-NSSAI (Single Network Slice Selection Assistance Information). S-NSSAI consists of Slice / Service Type (SST) and Slice Differentiator (SD).

[0148] NSSAI is a collection of S-NSSAI. There are three types of NSSAI.

[0149] Configuration NSSAI is the NSSAI configured in the UE, containing a list of S-NSSAIs that the UE can use. The UE may have a different Configuration NSSAI for each PLMN. The configuration may include instructions on how to map the Configuration NSSAI to the HPLMN Configuration NSSAI.

[0150] The Request NSSAI is provided by the UE to the network when it registers. The network will use it to determine what network node should serve the UE, and what network slice the UE should be allowed to connect to.

[0151] When registration is complete, the network provides the UE with the Allowed NSSAI, which is a list of S-NSSAIs (i.e., slices) that the UE is allowed to access.

[0152] PDU Session

[0153] The PDU Session is associated to the S-NSSAI and the DNN.

[0154] In the PDU Session Establishment Request sent to the network, the UE provides a PDU Session Identifier. The PDU Session ID is unique to each UE and is an identifier used to uniquely identify one of the UE's PDU Sessions. The PDU Session ID is stored in the UDM to support handover between 3GPP access and non-3GPP access when different PLMNs are used for 3GPP access and non-3GPP access.

[0155] URSP Rules

[0156] URSP (UE Routing Selection Policy) rules are policies used by the UE to determine how to route outbound traffic. Traffic can be routed to an established PDU session, can be diverted to a non-3GPP access outside of a PDU session, or can trigger the establishment of a new PDU session. The rules are provided to the UE by the PCF in the 5GC.

[0157] URSP rules have two main parts. The traffic descriptor part is used by the UE to determine what traffic the rule applies to. The routing descriptor (RSD) part includes a description of the routes that can be used to route data matching the traffic descriptor (i.e., S-NSSAI, DNN, access type, etc.).

[0158] The UE may also have local preferences that can be used to determine how to handle traffic. Local preferences take precedence over the URSP.

[0159] Organization of UE policy information

[0160] The UE's subscribed policy information portion is organized in the UDR as a policy set entry 300 (eg, Figure 3 ). A policy set entry consists of one or more PSIs. Each PSI consists of zero or more ANDSP and / or URSP policies. This is documented in reference [5] and shown in Figure 7 middle.

[0161] Figure 7 It can also be considered as a representation of how policy information is stored on the UE. The network sends policy information to the UE at PSI granularity. In other words, a single PSI is the minimum amount of policy information that the network can send to the UE and the minimum amount of policy information that the UE can reject. A PSI can contain as few as one ANDSP rule or one URSP rule.

[0162] Extensible Authentication Protocol (EAP)

[0163] EAP is not an authentication method, but a common authentication framework that can be used to implement a specific authentication method. In other words, EAP is a protocol that allows peers, authenticators, and authentication servers to negotiate what authentication method to use. The selected authentication method then operates within the EAP protocol. EAP is defined in RFC 3748 [9]. [9] describes the EAP packet format, procedures, and basic functions such as negotiation of the desired authentication mechanism. Figure 4 Block diagram showing a basic EAP architecture 400. EAP may use either the Radius or Diameter protocol.

[0164] Note that describing the authentication mechanism as EAP is not sufficient. There is always some underlying authentication method. There are many EAP methods defined by the IETF. For example, this document assumes that the chosen EAP method is, for example, EAP-AKA based on UMTS-AKA and defined in RFC4187

[10] . However, the concepts presented in this document can be used regardless of the chosen EAP authentication method.

[0165] Slice-specific authentication and authorization

[0166] In Release 16 of the 5G system, 3GPP agreed to add a procedure to support slice-specific authentication and authorization. This procedure allows the network to initiate an EAP-based procedure to the UE when the UE attempts to register with certain slices (i.e., S-NSSAI). The EAP-based authentication procedure is based on the UE providing a user ID and associated network credentials in order to be authorized to access the slice. This new procedure is documented in references [7] and [8] and is shown in Figure 5 middle. Figure 5 Reproduced from reference [8].

[0167] Secondary authorization / authentication of DN-AAA server during PDU session establishment

[0168] PDU session establishment authentication / authorization is optionally triggered by the SMF during PDU session establishment and performed transparently via the UPF, or directly with the DN-AAA server without involving the UPF if the DN-AAA server is located in the 5GC and is directly reachable. Fig.10 is reproduced from reference [6], Fig.10 Describes the authentication / authorization process performed by the DN-AAA server during PDU session establishment.

[0169] PDU session establishment and modification

[0170] UE-requested PDU session establishment in non-roaming and local breakout roaming

[0171] Fig.11 is reproduced from reference [6], Fig.11 The PDU Session establishment process in non-roaming case and local guided roaming case is shown. This process is used by the UE to establish a new PDU Session.

[0172] PDU session modification requested by UE or network (non-roaming and local guided roaming)

[0173] Fig.12 The PDU session modification procedure requested by the UE or the network (non-roaming and local roaming scenarios) is described in. Fig.12 Copied from reference [6]. This procedure is used by the UE or the network to modify a PDU session. QoS.

[0174] QoS Flow

[0175] QoS Flow is the finest granularity of QoS differentiation within a PDU Session. QoS Flow ID (QFI) is used to identify QoS Flows in the 5G system. User plane traffic with the same QFI within a PDU Session receives the same traffic forwarding treatment (e.g., scheduling, admission thresholds). Within 5GS, QoS Flows are controlled by the SMF and can be pre-configured or established via the PDU Session Establishment process.

[0176] Any QoS flow is characterized by:

[0177] • QoS profile provided to the AN by the SMF via the AMF over the N2 reference point, or pre-configured in the AN;

[0178] • one or more QoS rules and optionally QoS flow-level QoS parameters associated with these QoS rules, provided by the SMF via the AMF to the UE over the N1 reference point, and / or derived by the UE by applying Reflective QoS Control; and

[0179] •One or more UL or DL ​​PDRs provided by the SMF to the UPF.

[0180] QoS Profile

[0181] For each QoS flow, the QoS profile shall include the QoS parameters:

[0182] • 5G QoS Identifier (5QI); and

[0183] • Allocation and Retention Priority (ARP).

[0184] For each non-GBR QoS flow only, the QoS profile may also include QoS parameters:

[0185] • Reflective QoS Attribute (RQA).

[0186] For each GBR QoS flow only, the QoS profile shall also include the QoS parameters:

[0187] • Guaranteed Streaming Bit Rate (GFBR) - UL and DL; and

[0188] • Maximum Flow Bit Rate (MFBR) - UL and DL; and

[0189] • In case of GBR-only QoS flows, the QoS profile may also include one or more QoS parameters:

[0190] • Notification control;

[0191] • Maximum Packet Loss Rate - UL and DL.

[0192] Each QoS Profile has a corresponding QoS Flow Identifier (QFI) that is not contained in the QoS Profile itself.

[0193] QoS Rules

[0194] Signaled QoS rules

[0195] The UE performs classification and marking of UL user plane traffic based on QoS rules, i.e. association of UL traffic with QoS flows. QoS rules may be explicitly provided to the UE (i.e. QoS rules explicitly signaled using the PDU session establishment / modification procedures), pre-configured in the UE, or implicitly derived by the UE by applying reflective QoS.

[0196] QoS rules include:

[0197] a) an indication of whether the QoS rule is a default QoS rule;

[0198] b) the QoS Flow Identifier (QFI) of the associated QoS flow;

[0199] c) QoS Rule Identifier (QRI);

[0200] d) optional group filter groups; and

[0201] e) Priority value.

[0202] An explicitly signaled QoS rule contains a QoS rule identifier which is unique within a PDU Session and is generated by the SMF. There can be more than one QoS rule associated with the same QoS Flow, i.e. associated with the same QFI.

[0203] For each PDU session establishment, the default QoS rules need to be sent to the UE and are associated with the QoS flow.

[0204] For a PDU session of unstructured type, the default QoS rule does not contain a packet filter group, and in this case, the default QoS rule defines the processing of all packets in the PDU session.

[0205] Exported QoS rules

[0206] The exported QoS rules apply only to PDU sessions of IPv4, IPv6, IPv4v6, or Ethernet PDU session type.

[0207] Reflective QoS in the UE creates derived QoS rules associated with a PDU session based on DL user data packets received via the PDU session.

[0208] Each exported QoS rule contains:

[0209] a) QoS Flow Identifier (QFI);

[0210] b) packet filters for the UL direction; and

[0211] c) The priority value is 80 (decimal).

[0212] Note: On the network side, the corresponding QoS rules can be associated with different priority values ​​in the range of 70 to 99 (decimal).

[0213] Within a PDU session:

[0214] a) there may be zero, one or more derived QoS rules associated with a given QFI; and

[0215] b) There may be up to one derived QoS rule associated with a given packet filter for the UL direction.

[0216] When a QoS rule is derived by the UE, the UE will start a timer (T3583) and delete the rule when the timer expires. The UE will then be triggered to create a new rule the next time it receives a DL packet for which it does not have a rule.

[0217] Structure of QoS rules

[0218] The purpose of the QoS rules information element is to indicate a set of QoS rules to be used by the UE, where each QoS rule is a set of parameters as described in 3GPP TS 24.501

[11] .

[0219] The QoS Rules Information Element is a Class 6 Information Element with a minimum length of 7 octets. The maximum length of this Information Element is 65538 octets.

[0220] QoS rule information element 1300 is as follows Fig.13 , QoS rule 1400 is as follows Fig.14 As shown in:

[0221] QoS Flow Mapping

[0222] The SMF assigns a QFI to the new QoS flow and derives the QoS profile, corresponding UPF instructions and QoS rules of the new QoS flow from the PCC rules and other information provided by the PCF.

[0223] For each SDF, when applicable, the SMF generates explicitly signaled QoS rules following the following principles and provides them to the UE along with the add operation:

[0224] • assign a unique (for a PDU session) QoS rule identifier;

[0225] • Set the QFI in the QoS rule to the QFI of the QoS flow to which the PCC rule is bound;

[0226] • Generate a packet filter set for QoS rules from the UL SDF filters of the PCC rules and optionally the DL SDF filters (but only from those SDF filters with an indication for signaling to the UE);

[0227] • Set the QoS rule priority value to the priority value of the PCC rule for which the QoS rule is generated;

[0228] • For dynamically assigned QFI, in addition to the QoS rules associated with the QoS flow, the QoS flow level QoS parameters (e.g., 5QI, GFBR, MFBR, averaging window, see TS 24.501

[11] ) are signaled to the UE.

[0229] In UL:

[0230] •For IP or Ethernet type PDU sessions, the UE evaluates the UL packet against the UL packet filters in the packet filter group in the QoS rule in ascending order based on the priority value of the QoS rule until a matching QoS rule is found (i.e., its packet filter matches the UL packet).

[0231] • If no matching QoS rule is found, the UE shall discard the UL data packet.

[0232] • For unstructured type PDU sessions, the default QoS rule contains no packet filter group, thus allowing all UL packets.

[0233] •UE binds the UL packets to the QoS flow using the QFI in the corresponding matching QoS rule.

[0234] •The UE uses the stored QoS rules to determine the mapping between UL user plane traffic and QoS flows.

[0235] • The UE marks the UL PDU with the QFI of the QoS rule containing the matching packet filter and sends it using the corresponding access specific resources for that QoS flow based on the mapping provided by the (R)AN.

[0236] Problem Statement

[0237] Reference [1], 3GPP TR 22.904 describes a use case in which it is advantageous for a 3GPP system to identify a user of a UE.

[0238] A use case in reference [l] describes a scenario where two children, Lucy and Linus, sometimes use their mother's UE. It is desirable to enhance the 3GPP system so that the network can identify when Lucy or Linus is using the UE so that the network provides different services to the UE depending on who is using the UE. For example, the network can provide web filtering when Lucy or Linus is using the UE. In addition, the network can apply different time limits for each user. This scenario means that the network maintains a profile for each user, and the profile contains information about what UE (i.e. subscription) the user can use to access the network, and what services each user is allowed to access. It also means that each user can use different applications or services in the device that may require or need different QoS (e.g., games, video streaming, etc.), different users can expect different user experiences, or different users can enjoy different user experiences based on their agreements with the MNO.

[0239] The use cases described above clearly show that the network should take into account who is using the UE when granting access to services (including network slicing).

[0240] Furthermore, based on the scenario in question, reference [1] suggests that the 3GPP system should be able to save user specific service settings and parameters such as QoS parameters for a user together with the user ID.

[0241] URSP rules are used to configure information for UEs about what network slices and PDU sessions and data networks should be used for a given type of application traffic. One of the issues to be addressed in this disclosure is how to enhance URSP rules to take into account or include the user of the UE. In addition, this disclosure will address how and when to update the URSP rules of a UE based on who is using or may use the UE.

[0242] Returning to the use case described earlier in this section, it is also clear that the person who is using the UE may change dynamically. For example, when Lucy finishes web surfing, Lucy may put the phone on the table, and Linus may pick up the device later to start playing a game. This scenario clearly shows that the network needs to be able to detect when the user changes, and the user of the UE needs to be able to deactivate and suspend, i.e. temporarily deactivate their account on the UE. The network also needs to be able to change what services the UE can access when the user changes. In terms of what services the UE can access when the user changes, the present disclosure will explore how this change affects the UE's configured NSSAI and allowed NSSAI.

[0243] In the aforementioned use case, Lucy and Linus can use different user accounts and user IDs. Thus, Lucy and Linus can log into different user accounts and launch different applications that may have different QoS requirements. It should also be noted that users can subscribe to customized QoS and compensate the MNO for the subscribed services. For each user to experience the appropriate quality of service in the UE, the QoS rules must be linked or stored with the user's ID, possibly in the user's profile, and sent to the UE. The network then needs to be able to configure the QoS rules in the UE so that the UE can associate certain rules.

[0244] In scenarios where the network is "user aware", it may be the case that the network determines that a user is no longer allowed to access the network from the UE. This may happen, for example, if Lucy and Linus's mother calls the network operator and terminates or changes their permissions so that they are only allowed to use the UE in certain locations, at certain times of the day, etc. In scenarios like this, the network needs to be able to deactivate or suspend, i.e. temporarily disable, the user's account on the UE.

[0245] As mentioned earlier in this document, the size of the User ID may not be consistent. Sending longer names over the air may increase the amount of over-the-air signaling resources. Therefore, it is desirable to represent the User ID with a consistent IE size to achieve optimal computation.

[0246] summary

[0247] In Rel-17, 3GPP is studying how to enhance the 5G system to know what the user data plane traffic is associated with. This disclosure focuses on the following aspects:

[0248] - How the network configures the UE with policies or routes for routing data based on the user (i.e., capillary device, application, or person) generating the traffic.

[0249] - Enhancement of the User / User ID based QoS rules IE; and delivery of the resulting user-specific QoS rules to the UE.

[0250] This disclosure outlines how a UE can detect certain events that cause it to request the network to authenticate the user and request the network to link the user with the UE's subscription. This may cause the network to provide the UE with updated configuration NSSAI. Each S-NSSAI in the updated configuration NSSAI is associated with one or more user identifiers.

[0251] The present disclosure also describes how the UE may determine to send a new request NSSAI and receive a new allow NSSAI once a user is linked to the UE's subscription, wherein the S-NSSAI in the new request NSSAI and allow NSSAI are associated with a user identifier.

[0252] Once the UE is connected to a network slice that can be accessed by a user associated with the UE, the UE will need to determine what traffic should be routed to each slice. The present disclosure also describes how the network provides the UE with a URSP policy associated with a user identifier, so that the UE can apply different policies based on the user responsible for the traffic. Specifically, the present disclosure proposes an efficient way to associate a user ID with policy information. The user identifier can be associated with the PSI so that the format and content of the PSI and the URSP policy can remain largely unchanged, and changes in user activity, associations, or links will not cause the network to need to send a new PSI to the UE. The present disclosure also describes what events will cause the UE to request updated PSI / user association information from the network.

[0253] In addition, the present disclosure describes new user-centric QoS rules (UCQRs), how UCQRs can be encoded into NAS information elements, what processes can be enhanced to deliver the new information elements to the UE, and how the UE can associate user traffic with user-centric QoS rules.

[0254] This disclosure describes how a user ID alias can be assigned by the network, provided to the UE, and used in subsequent message exchanges between the UE and the network to reduce information element size.

[0255] Detailed description

[0256] The present disclosure focuses on how the network detects that a new user is associated with a UE (or is no longer associated with the UE), how the network reconfigures the UE to make it aware of what services are available when there is a change in user association, and how the UE requests the network to allow it to access services when a user is associated with it.

[0257] Section 1 describes how the UE's configured NSSAI is affected when a user logs in and out of the UE and when a user links and unlinks from the UE.

[0258] Section 2 describes how the allowed NSSAI of the UE may be updated when the user logs in and out of the UE and when the user links and unlinks from the UE.

[0259] Section 3 describes how to update a URSP rule or information associated with a URSP rule to take into account which user generated the traffic that caused the URSP rule to be evaluated.

[0260] Section 4 describes the proposed structure of User-Centric QoS Rules (UCQR) and new information elements that can be used to signal User-Centric QoS Rules to the UE.

[0261] Section 5 describes various 3GPP procedures such as PDU session establishment during which the UCQR is delivered to the UE.

[0262] 1. Configuring NSSAI during user events

[0263] The set of services (i.e., slices) that a UE can access in a PLMN is called a configured NSSAI. The configured NSSAI is provided to the UE during the registration and configuration update procedures. When the 3GPP system is enhanced to be "user-aware", it may be necessary for the 3GPP system to modify the configured NSSAI of the UE based on which user is using the UE or which users may use the UE.

[0264] It is expected that 5GC will maintain user profiles for each user it may know. User profiles can be linked to subscriptions. The linking operation can be based on events in the network, such as an administrator or a third party updating a user profile or subscription. The fact that a user profile is linked to a subscription is an indication in 5GC that a user can access the system using a UE associated with a subscription. When a user profile becomes linked to a subscription, the network can send a configuration update message as described above to the UE. The configuration update message can be enhanced to indicate to the UE that the user is linked to a subscription. In addition, the configuration update message may include a configuration NSSAI that has been updated based on what user is linked to the subscription. For example, a separate configuration NSSAI may be provided for each user, a configuration NSSAI may be provided for traffic that is not associated with the user, a configuration NSSAI may be provided for traffic associated with all users, or a single configuration NSSAI may be provided, and a user identifier may be associated with each S-NSSAI within the configuration NSSAI.

[0265] In some cases, the linking operation may be based on an event local to the UE. For example, a user may access a GUI on the UE and request to link with the UE's subscription. The user's call to the GUI may trigger the UE to send a request to the network, and the request may trigger an authentication process to authenticate the user. The request may be a NAS request, such as a registration update message that includes a user identification code. The registration update message may trigger a separate EAP-based authentication process in which the user is authenticated. The EAP authentication process may interact with the GUI. For example, the EAP authentication process may result in the GUI requesting and receiving a password or other authentication information. An example of a GUI is shown in FIG. Fig. 9and discussed below. If the user is successfully authenticated, the network may send a UE Configuration Update (UCU) message to the UE. The UCU message may include an indication that the user has been authenticated, and an updated Configuration NSSAI based on the fact that the user is now linked to a subscription. The UCU message may also provide the UE with a new Allowed NSSAI. The format of the Allowed NSSAI may be enhanced so that the network can indicate to the UE which user(s) are allowed to access each S-NSSAI using the Allowed NSSAI. The process is shown in Figure 6 in step 7.

[0266] Figure 6 The process represents how the UE indicates to the network that the user is now associated with the UE. The process can be similarly used by the UE to indicate to the network that the user is no longer logged into the UE. Of course, the authentication process can be skipped, but the event can still cause the network to update the UE's configuration NSSAI and / or allow NSSAI. The indication from the UE to the network may indicate that the user should be unlinked from the UE's subscription, or it can indicate to the network that the user no longer exists, but the user's profile may still be linked to the UE's subscription. Whether the UE indicates that the user should still remain linked to the subscription depends on input from the GUI. For example, the GUI can be used to indicate to the UE that the user no longer wishes to be associated with the UE, or that the user no longer wishes to be associated with the subscription (i.e., unlinked). If the UE indicates that the user should no longer be associated with the UE or that the user is no longer linked to the subscription, the network can provide the UE with a new configuration NSSAI, which will be updated to take into account the fact that the user no longer uses the UE or is no longer linked to the UE's subscription.

[0267] Figure 6 The procedure of UE.NET represents how the UE requests the network to associate a subscriber identifier with the UE, resulting in the network sending a new configuration NSSAI to the UE. The new configuration NSSAI includes S-NSSAI that was not previously in the UE's NSSAI because the subscriber is now linked to the UE's subscription. Since the subscriber is now linked to the UE's subscription, the new configuration NSSAI may also no longer include certain S-NSSAI that were previously in the UE's NSSAI.

[0268] 1. In Figure 6 In step 1, a local event on the UE causes the UE to determine that a new user needs to be associated with the UE. Examples of local events include someone entering a new username in a GUI (i.e., a web browser, application, etc.), and the UE receiving a user identification code from another device after the other device is paired, connected, or communicating with the UE via Bluetooth or Wi-Fi. The event may also involve the UE receiving a password or credential along with the user identifier. The UE may derive a user ID and associated credentials to be sent to the 3GPP system based on the entered or received information.

[0269] 2. In Figure 6 In step 2, the UE sends a registration update request to the AMF to indicate that it wishes to associate a user identifier with the UE's subscription. The request includes the user ID.

[0270] 3. In Figure 6 In step 3, the UE sends a link update request to the UDM. The request indicates the SUPI of the UE and the user ID of the user. The UDM accesses the UDR, which is a repository storing the subscription of the UE and a repository storing the profile of the user. If the subscription of the UE and the profile information of the user indicate that the linking is permitted, the UDM will respond to the UE that the user ID can be linked with the subscription of the UE.

[0271] 4. Optionally, Figure 6 In step 4, the AUSF may perform an authentication process with the UE to authenticate the user. Messages between the AUSF and the UE are sent to and from the NAS layer of the UE via the AMF. The authentication process may involve the UE sending the password or a hash of the password received via the GUI in step 1 to the AUSF.

[0272] 5. In Figure 6 In step 5, the AMF sends a registration response to the UE.

[0273] a. If the authentication process of step 4 is performed, the response indicates to the UE whether the user ID has been linked to the UE's subscription. If the response indicates that the user ID is not linked, the response includes a reason code indicating the reason for the failure (e.g., authentication failure or unrecognized user ID or user does not allow linking or subscriber does not allow linking). If the linking is successful, the registration response may include a new configuration NSSAI. The new configuration NSSAI may include an S-NSSAI that may be associated with the user ID. The process stops here.

[0274] b. If the authentication procedure of step 4 is not performed, the response indicates to the UE that authorization of the user ID linked to the UE's subscription is pending. The flow continues to step 6.

[0275] 6. In Figure 6 In step 6, the UE performs an authentication process with the network. The process may be EAP-based and may be similar to the network slice-specific authentication and authorization process described above. The authentication process may involve the UE sending the password or a hash of the password received via the GUI in step 1 to the network, or it may involve the UE prompting the user to enter a password.

[0276] 7. In Figure 6In step 7, the AMF sends a configuration update request to the UE, which includes a new configuration NSSAI. The new configuration NSSAI may include an S-NSSAI that may be associated with the user ID. The UE responds to the configuration update with an indication of whether the configuration update was successful.

[0277] Notice, Figure 6 The process described in involves the NAS layer of the UE sending a registration request to the network. Alternatively, other NAS messages may be used to send the request to the network.

[0278] 2. Allow NSSAI to process

[0279] Once a user successfully authenticates with the network, the UE can request permission to access different NSSAIs. Successful user authentication or receipt of an updated Configuration NSSAI with a new user ID can trigger the UE to send a Registration Update message. The Registration Update message can provide the network with the Request NSSAI that has been updated based on the user ID. The format of the Request NSSAI can be updated to allow the UE to indicate to the network which user(s) wish to be allowed access to each S-NSSAI. The network can use the user's profile to check which S-NSSAIs they should be allowed to access and use this information to send the Allow NSSAI to the UE. The format of the Allow NSSAI can indicate to the UE which user is allowed access to each S-NSSAI. The process is shown in Figure 7 middle.

[0280] 1. In Figure 7 In step 1, a local event on the UE causes the UE to determine that it should send a new request NSSAI to the network. Examples of local events include Figure 6 that is, the receipt of a new configuration NSSAI associated with a user ID. Other examples of local events include different users unlocking the UE, logging into the UE, generating application traffic, other devices after other devices pair, connect or communicate with the UE via Bluetooth or Wi-Fi.

[0281] 2. In Figure 7 In step 2, the UE sends a registration update request to the network. The request includes a request NSSAI, which has been updated to indicate whether each S-NSSAI in the NSSAI is associated with one or more user IDs, and further indicates which user ID(s) is associated with each S-NSSAI. The UE may indicate that some S-NSSAIs are not associated with specific user IDs, but only with subscriptions. When no user ID is indicated as being associated with an S-NSSAI, the network may interpret the indication as the UE wishing the S-NSSAI to be associated only with the UE's subscription.

[0282] 3. In Figure 7 In step 3, the AMF queries the UE's subscription and the profile of the user indicated in step 1 to determine which S-NSSAI(s) the UE can be allowed to access. This step may consist of multiple queries; for example, a UDM query to obtain the UE's subscription S-NSSAI, where the data key is the UE's SUPI, and a UDM query to obtain the user's subscription S-NSSAI, where the data key is the user's Id.

[0283] 4. In Figure 7 In step 4 of , the AMF responds to the UE with an allowed NSSAI. The message also indicates to the UE whether each S-NSSAI can be associated with a user linked to the UE's subscription. For example, the message may provide a list of user IDs that can access each S-NSSAI from the UE. The message may also provide a list of user IDs that are prohibited from accessing each S-NSSAI from the UE. The message may also indicate that certain S-NSSAIs may be associated only with the UE's subscription or with any user. Note that the consequence of indicating that the S-NSSAI may be associated only with the UE's subscription is that the traffic exchanged between the UE and the associated slices will be billed to the UE's subscription and user.

[0284] 3. Application traffic processing

[0285] As described above, when an application generates traffic, the UE will compare the traffic with the traffic descriptor in the URSP rule to determine which URSP rule should be associated with the traffic. When a matching rule is found, the UE will further evaluate the RSD of the rule to determine what route (e.g., DNN and S-NSSAI) the traffic should take.

[0286] The traffic descriptor in the URSP rule can be updated to include a user ID field. The UE can then use this new field to recognize that the rule only applies to traffic generated by one of the user IDs indicated in the user ID field. If no user ID is associated with the URSP rule, the UE can interpret the rule as only applicable to traffic that is not associated with the user. However, this approach may complicate the UE's evaluation of the URSP rule. Complications may arise when a user generates traffic that does not match the URSP rule. When this scenario occurs, a match-all URSP rule is typically applied to the traffic. However, some RSDs in the match-all URSP rule may include slices that are allowed to be accessed by the UE but not allowed to be accessed by the associated user. Thus, the UE needs to check whether the route is a valid choice for the user.

[0287] Another approach to handling the provision and evaluation of URSP rules is to enhance the system so that the network can provide a different set of URSP rules that will be associated with each user, and a set of URSP rules that can be associated with a UE (i.e., no specific user). However, the disadvantage of this approach is that the network may need to send more data and signaling to the device (e.g., the URSP rules used by some users and UEs may be very similar or identical).

[0288] Another approach that may slightly reduce the amount of data and signaling required between the UE and the network is that the network may provide 2 sets of URSP rules to the UE. One set may not be associated with a specific user, while the second set may include a user identifier. However, this approach still suffers from the fact that some RSDs matching all URSP rules may include slices that are allowed access by one user, but not by the user that generated the traffic being evaluated. Thus, the UE needs to check whether the route is a valid choice for the user.

[0289] The format of the RSD could also be updated to include the user ID, but this would also complicate URSP evaluation in that the UE could detect that traffic matches a URSP rule, only to find that no route is applicable to the user. The UE would then have to check other URSP rules until a match is found, and the current URSP evaluation rules would dictate that match all rules cannot be applied.

[0290] A preferred method may be to not modify the URSP rules to include user IDs, but to enable the network to indicate to the UE which (which) users are associated with each URSP rule. One advantage of this method is that when a new user is associated with the UE, the URSP rules do not need to be sent to the UE, and when a new user is associated with the UE, the URSP rules do not need to be modified. Instead, the network can simply inform the UE which (which) users are associated with each URSP rule or are no longer associated with it. Thus, the amount of information that needs to be sent to the UE will be less. Alternatively, the PSI may be associated with a user identification code. When the network provides the PSI to the UE, it may also indicate to the UE whether the PSI is associated with a certain (certain) user ID or UE. When the UE indicates to the network (i.e., during registration) which PSIs are installed on the UE, the UE may also indicate which (which) user IDs it thinks are associated with each PSI. If the network indicates that the PSI is not associated with any user ID, the UE may assume that the PSI will be used for traffic that is not associated with any user. Alternatively, the PSI may be updated to include URSP rules and user IDs. The user ID will be associated with all URSP rules in the PSI. The NAS procedures may then be updated so that the network can update which user ID(s) are included in the PSI without updating the URSP rules contained in the PSI.

[0291] Figure 8 A scenario 800 is described, where the policy set entries for a UE contain 6 PSIs, and the UE is associated with 3 different users (users A, B, and C). The policies within PSI #1 are for traffic from users A and B. The policies within PSI #2 and PSI #3 are only for traffic from user A. The policies within PSI #4 are only for traffic from user B. The policies within PSI #5 are only for traffic that is not associated with any user (i.e., traffic that will be billed to a subscription). The policies within PSI #6 may be applied to all traffic (i.e., all users and all traffic associated with a subscription).

[0292] The policy set association information may be sent by the network to the UE in the same NAS message used to send the PSI to the UE (e.g., a registration response or any NAS message including a UE policy container or PSI). The network may send this information to the UE in order to install or configure the information on the UE.

[0293] The policy set association information may be sent from the UE to the network in the same NAS message used to send the PSI to the network (e.g., a registration request or any NAS message including a UE policy container or PSI). The UE may send this information to the network in order to inform the network what rules or association information are installed or configured on the UE.

[0294] Note that when an ANDSP rule is associated with a user identity code, the UE may interpret the policy as being effective only when the user is logged into the UE, associated with the UE, or generating traffic on the UE.

[0295] Section 1 describes various events that may cause the network to update the UE's configured NSSAI. These same events may cause the network to send a new or updated PSI to the UE along with updated or new policy set entry association information. The new or updated PSI will include or be associated with the user ID so that the UE can know what URSP rules are associated with the user ID.

[0296] 4. User-Centric QoS Rules (UCQR)

[0297] The QoS Rule Identifier (QRI) can be part of the user profile, which links it to the corresponding QoS rules. The user profile can be stored in the UDR. Alternatively, the user's QoS rules can be stored in some other database. User-centric QoS rules can be sent to the UE. This section describes a new information element that can be used to send user-centric QoS rules to the UE. During processes such as PDU session establishment, registration, UE configuration update, etc., the system can be triggered to send this new IE to the UE. Enhancements to these processes will be discussed below.

[0298] The QoS Rules IE is described in TS 24.501

[11] . A new IE may be created for user-centric QoS rules. The new IE may be based on the QoS Rules IE. The new IE may be referred to as User-Centric QoS Rules (UCQR). The structure or format of a UCQR IE (e.g., UCQR IE 1500) is shown in FIG. Fig.15 middle.

[0299] Note Fig.15 In the UCQR IE, a new IE called User ID is included. The format of the User ID can be an alphanumeric string and its length can vary. The length of the User ID IE can be used to indicate to the UE how long the string is.

[0300] Fig.16 It shows how the User-centric QoS Rules IE (eg, UCQR IE 1600) can be further enhanced to carry rules for multiple users. It shows the corresponding UCQRs for user 1 to user m.

[0301] Alternatively, the length of the user ID may be fixed length and may be represented within an octet. It should be appreciated that the UCRQ IE may be formatted such that multiple user ID IEs are included therein. Thus, QoS rules applicable to multiple users may be provided to the UE in one IE.

[0302] Alternatively, instead of creating a new UCQR IE to provide user-centric QoS rules to the UE, the format of the existing QoS rule IE can be enhanced to include the user ID. Alternatively, a new user-centric QoS rule can be created to include the user ID and be carried in the QoS rule IE.

[0303] Another alternative could be to enhance Fig.13 The structure of the QoS Rules IE in the QoS Rules IE can be modified to provide a mapping of user IDs to QoS rules, possibly at the bottom of the QoS Rules IE structure. This approach can make only a limited number of changes to the existing format.

[0304] The presence of a user ID in the QoS IE may be an indication to the UE that the set of QoS rules should be applied to traffic generated by the user with the corresponding user ID.

[0305] 5. User-centric QoS rule delivery and enforcement

[0306] This section describes the various 3GPP procedures in which the UCQR may be delivered to the UE.

[0307] UCQR delivery during UE requested PDU session establishment procedure

[0308] Fig.17 Represents the PDU session establishment process requested by the UE.

[0309] 1. Fig.17 Step 1 - From UE to AMF: A user or application may trigger a NAS message for PDU session establishment using a user ID. The message from the UE to the network includes a NAS message (S-NSSAI, DNN, PDU session ID, request type, old PDU session ID, N1 SM container (PDU session establishment request)). The message may be enhanced to include one or more user IDs. The user ID may be part of the NAS SM container (PDU session establishment request). The presence of the user ID may indicate to the network that the PDU session will be used by the identified user. In the event that the UE does not provide any specific user ID in the request in the NAS message, the process may fall back to the PDU session establishment process described in TS 23.502 Rel 16 [6], where the PDU session is relative to the UE and the same QoS rules may apply to all users involved in the PDU session from the UE.

[0310] Note that the User ID may also be included in the SM PDU DN Request container. The User ID may be required for secondary authentication and authorization with the DN-AAA server.

[0311] 2. Fig.17 Step 2-AMF selects the appropriate SMF.

[0312] 3. Fig.17 Step 3 - From AMF to SMF: AMF calls Nsmf_PDUSession_ CreateSMContext request or Nsmf_PDUSession_UpdateSMContext request and includes the user ID provided by the UE.

[0313] 4. Fig.17Step 4 - If the session management subscription data corresponding to the S-NSSAI of the SUPI, DNN and HPLMN is not available, the SMF retrieves the session management subscription data. If the user profile information is not available for the identified user, the SMF retrieves the information from the UDR. The SMF may call Nudm_SDM_Get (SUPI, User ID, Session Management Subscription Data, DNN, S-NSSAI of the HPLMN) and subscribe using Nudm_SDM_Subscribe (SUPI, User ID, Session Management Subscription Data, DNN, S-NSSAI of the HPLMN) to be notified when the subscription data is modified.

[0314] Note that a subscription can be linked to a user's profile, as described in Section 5.2. Thus, in the processes Nudm_SDM_Get, Nudm_SDM_Subscribe, Nudr_DM_Query, the SMF can request information from the user's profile based on the user ID. The response can include user-centric QoS rules obtained from the user's profile and subscription relationship present in the UDM / UDR.

[0315] If the UE request is considered invalid, the SMF decides not to accept the establishment of the PDU Session.

[0316] 5. Fig.17 Step 5 - From SMF to AMF: Depending on the request received in step 3, the SMF provides either a Nsmf_PDUSession_CreateSMContext Response (Cause, SM Context ID or N1 SM Container (PDU Session Reject (Cause))) or a Nsmf_PDUSession_UpdateSMContext Response.

[0317] If the SMF receives the Nsmf_PDUSession_CreateSMContext request in step 3 and the SMF is able to process the PDU session establishment request, the SMF creates an SM context and responds to the AMF by providing the SM context ID.

[0318] The response may include a UCQR created by the SMF based on information retrieved from the user profile via the UDM / UDR.

[0319] 6. Fig.17 Step 6 - Optional secondary authentication / authorization. The UCQR may be delivered to the UE after secondary authentication and authorization are completed. This process is described in Section 5.5.4.

[0320] 7a. Fig.17Step 7a - If a dynamic PCC is to be used for the PDU Session, the SMF performs PCF selection as described in TS 23.501

[12] , clause 6.3.7.1. If the request type indicates "existing PDU Session" or "existing emergency PDU Session", the SMF shall use the PCF already selected for the PDU Session.

[0321] Otherwise, the SMF may apply local policy.

[0322] 7b. Fig.17 Step 7b - The SMF may perform the SM Policy Association Establishment Procedure to establish the SM Policy Association with the PCF and obtain the default PCC rules for the PDU Session. The GPSI will be included if available at the SMF. If the Request Type in step 3 indicates "Existing PDU Session", the SMF may provide information about the Policy Control Request Trigger Conditions that have been satisfied for the SM Policy Association Modification Procedure initiated by the SMF.

[0323] The PCF may associate the PCC rules with a user subscription and / or user profile, which may include a QoS Rule Identifier (QRI) belonging to the user's UCQR. This may optionally allow PCC rules to be enforced for each user based on the UCQR.

[0324] Alternatively, if the PDU session requires re-authentication / re-authorization, the SMF may request a new UCQR from the UDM after successful authentication and authorization.

[0325] Note: The purpose of step 7 is to receive PCC rules before selecting UPF. If PCC rules are not required as input for UPF selection, step 7 can be performed after step 8.

[0326] 8-10. Fig.17 Steps 8-10 in may correspond to 4.3.2.2.1-1 in TS 23.502 [6].

[0327] 11. Fig.17 Step 11 - SMF to AMF: AMF calls Namf_Communication_NlN2MessageTransfer.

[0328] Namf_Communication_N1N2MessageTransfer may be enhanced to include user-centric QoS rules. User-centric QoS rules may be included in the PDU Session Setup Accept message.

[0329] The N2 SM message carries information that the AMF will forward to the (R)AN.

[0330] The N1 SM container contains the PDU Session Establishment Accept that the AMF will provide to the UE.

[0331] Multiple user-centric QoS rules, QoS flow-level QoS parameters (if required by the QoS flows associated with these user-centric QoS rules) and QoS profiles may be included in the PDU Session Establishment Accept in the N1 SM and in the N2 SM information.

[0332] 12. Fig.17 Step 12 - AMF to (R)AN: N2 PDU Session Request (N2 SM Information, NAS Message (PDU Session ID, N1 SM Container (PDU Session Establishment Accept)), [CN Assisted RAN Parameters Adjustment]).

[0333] The AMF sends a NAS message containing the PDU Session ID and PDU Session Establishment Accept targeted to the UE in an N2 PDU Session Request to the (R)AN, and the N2 SM information received from the SMF.

[0334] 13. Fig.17 Step 13 - (R)AN to UE: The (R)AN may initiate AN specific signaling exchanges with the UE related to the information received from the SMF.

[0335] The (R)AN forwards the NAS message (PDU Session ID, N1 SM Container (PDU Session Establishment Accept)) provided in step 12 to the UE. The (R)AN only provides the NAS message to the UE if the AN-specific signaling exchange with the UE includes (R)AN resource addition associated with the received N2 command.

[0336] If the N2 SM information is not included in step S11, the following steps 14 to 20 are omitted.

[0337] 14. Fig.17 Steps 14 to 20 in Fig.12 Compared to no change.

[0338] Note that there may be situations where a user may trigger the UE to establish a PDU Session with the core network, while a second user may initiate data traffic from the UE which may be sent via the same PDU Session. If these two users share a PDU Session, this event may trigger the PDU Session modification process. A common scenario may be that the UE has established a PDU Session to which UCQR applies, and when another user initiates data traffic to be sent from the existing PDU Session, then depending on how UCQR is defined per section 5.4, one of the following may be delivered to the UE:

[0339] 1. The same new UCQR for both users (UCQR with the user IDs of both users).

[0340] 2. New UCQR for the second user only.

[0341] 3. A different new UCQR for each user.

[0342] 4. Updated mapping of user ID to QoS rules via new UCQR IE.

[0343] User-centric QoS rule delivery during PDU session modification procedure

[0344] Fig.18 The PDU session modification procedure requested by the UE or the network (non-roaming and local roaming scenarios) is described in

[0345] Several occasions or conditions may trigger a session modification and thus the delivery of a new UCQR to the UE. Some of the conditions may be:

[0346] •Changes in users.

[0347] •Increase in users.

[0348] • A new user joins an existing PDU session.

[0349] •Changes in applications.

[0350] ○ Add an application session to an existing PDU session.

[0351] ○ End the app session.

[0352] • Policy and billing changes due to subscription modifications (e.g., upgrading QoS for application traffic).

[0353] 1. The process can be triggered by the following events:

[0354] Fig.18 Step 1a. (Modification initiated by user or application in UE) A user or application may initiate a PDU session modification procedure, where the message may be enhanced to include one or more user IDs in the transmission of a NAS message. The NAS message is forwarded by the (R)AN to the AMF along with an indication of the user location information. The AMF calls Nsmf_PDUSession_UpdateSMContext.

[0355] The PDU session modification process triggered by the user can initiate the user authentication process.

[0356] Fig.18Step 1b. (Modification requested by SMF) The PCF performs a PCF initiated SM policy association modification procedure to notify the SMF of the policy modification. This may be triggered by a policy decision or based on an AF request, for example, the impact of application functions on traffic routing. This scenario may involve the PCF consulting the UDM for user subscription and user profile information, where the user's UCQR may be considered for the PCC policy or its modification. In the PCF notification, the PCF may include an indication to the SMF that the change in policy involves the required UCQR in the modified PDU session, and the SMF may retrieve the new UCQR from the UDM. Alternatively, the PCF may trigger the UDM to send the UCQR to the SMF.

[0357] Fig.18 Step 1c. (Modification requested by SMF) UDM updates the subscription data of SMF through Nudm_SDM_Notification (SUPI, Session Management Subscription Data). This notification can be enhanced to include the new UCQR of the UE. SMF updates the session management subscription data and confirms UDM by returning an Ack with (SUPI).

[0358] Fig.18 Step 1d. (SMF Requested Modification) The SMF may decide to modify the PDU Session. This procedure may also be triggered based on locally configured policies or from the (R)AN. This procedure may also be triggered if the UP connection is activated (as described in the Service Request procedure) and the SMF has marked the status of one or more QoS flows as deleted in the 5GC but has not yet been synchronized with the UE.

[0359] Fig.18 Step 1d-1. PDU Session modification may require new QoS rules to be considered in the new PDU Session. The SMF may request new information from the user subscription and user profile from the UDM and implement the PCC rules on the modified PDU Session at the same time, or vice versa.

[0360] If the SMF receives one of the triggers in steps 1b-1d, the SMF initiates the SMF-Requested PDU Session Modification procedure.

[0361] Fig.18 Step 1e. (AN initiated modification) When the AN resources to which the QoS flow is mapped are released, the (R)AN shall indicate this to the SMF regardless of whether notification control is configured.

[0362] Fig.18Step 2. The SMF may need to report some subscribed events to the PCF by performing an SMF initiated SM policy association modification procedure. This process can be enhanced with the user ID and associate the corresponding subscription / profile information with the PCC rules, which may involve information exchange between the PCF and the UDM. This step can be skipped if the PDU session modification procedure is triggered by step 1b or 1d. If dynamic PCC is not deployed, the SMF can apply local policies to decide whether to change the QoS profile.

[0363] Fig.18 Step 2a. If redundant transmission is not activated for the PDU session and the SMF decides to perform redundant transmission for the new QoS flow, if the CN tunnel information is allocated by the SMF, then the SMF allocates additional CN tunnel information. The additional CN tunnel information is provided to the UPF via the N4 session modification request. The SMF also instructs the UPF to perform packet duplication and elimination for the QoS flow.

[0364] If redundant transmission is activated on a PDU session and the SMF decides to stop redundant transmission, the SMF instructs the UPF to release the CN tunnel information used as the redundant tunnel for the PDU session, and also instructs the UPF to stop packet duplication and deletion for the corresponding QoS flow.

[0365] Fig.18 Step 2b. UPF responds to SMF. If redundant transmission is not activated for the PDU session, and in step 2a, SMF indicated to UPF that packet duplication and elimination should be performed for the QoS flow, then if the CN tunnel information is allocated by UPF, then UPF allocates additional CN tunnel information. The additional CN tunnel information is provided to SMF.

[0366] If redundant transmission is not activated for the PDU session, and in step 2a, the SMF decides to use two I-UPFs for redundant transmission for the new QoS flow, then if the CN tunnel information is allocated by the UPF, the UPF allocates the CN tunnel information. The CN tunnel information of the two I-UPFs is provided to the SMF.

[0367] Fig.18 For modifications initiated by the UE or AN, the SMF responds to the AMF through Nsmf_PDUSession_UpdateSMContext, which includes the user-centric QoS rules in both the N1 SM container and the N2 SM information.

[0368] For signaled QoS, a new UCQR may be delivered to the UE for the modified PDU Session.For AN initiated signaled QoS, the SMF may request a new UCQR from the UDM / UDR for the modified PDU Session.

[0369] The N2 SM information carries information that the AMF should provide to the (R)AN. It may include a QoS profile and a corresponding QFI to notify the (R)AN that one or more QoS flows have been added or modified. It may include only the QFI to notify the (R)AN that one or more QoS flows have been removed. The SMF may indicate for each QoS flow whether redundant transmission should be performed by a corresponding redundant transmission indicator. If the PDU session modification is triggered by the (R)AN release in step 1e, the N2 SM information carries confirmation of the (R)AN release. If the PDU session modification is requested by the UE for a PDU session for which no user plane resources are established, the N2 SM information provided to the (R)AN includes information for establishing user plane resources.

[0370] The N1 SM container carries the PDU session modification command that the AMF will provide to the UE. It may include user-centric QoS rules, flow-level QoS parameters (if required for the QoS flow associated with the UCQR), and corresponding QoS rule operations and QoS flow-level QoS parameter operations to notify the UE that one or more user-centric QoS rules have been added, removed or modified.

[0371] Fig.18 Step 3b. For the modification of the SMF request, SMF calls Namf_Communication_NlN2MessageTransfer including the N2 SM message enhanced with UCQR and the N1SM container.

[0372] For SMF requested modifications, it can be assumed that the SMF has consulted the UDM regarding the user subscription and user profile for the UCQR, thereby indicating the new UCQR in the Namf_Communication_NlN2MessageTransfer message.

[0373] Fig.18Step 3c. For the SMF requested modification caused by the updated SMF associated parameters from the UDM, the SMF may provide the SMF-derived CN-assisted RAN parameter adjustment to the AMF. In addition, for the corresponding user, the SMF may receive a new UCQR from the UDM. The SMF calls Nsmf_PDUSession_SMContextStatusNotify (SMF-derived CN-assisted RAN parameter adjustment) including the new UCQR to the AMF. The AMF stores the SMF-derived CN-assisted RAN parameter adjustment in the associated PDU session context of the UE.

[0374] Fig.18 Step 4. The AMF may send a N2 PDU Session Request (N2 SM Information received from the SMF, NAS Message (PDU Session ID, N1 SM Container (PDU Session Modification Command))) message to the (R)AN. The PDU Session Modification Command may contain a new UCQR for the UE.

[0375] Fig.18 Step 5. The (R)AN may initiate an AN specific signaling exchange with the UE related to the information received from the SMF. As a signaled QoS procedure, the (R)AN may deliver the UCQR for the user it receives from the SMF / UDM to the UE.

[0376] Step 6-13 may correspond to 4.3.3.2.1-1 in TS 23.502 [6].

[0377] UCQR delivery during network slice specific secondary authentication process

[0378] Once the user has been authenticated and authorized, the UCQR may be delivered to the UE for the authenticating user during the network slice specific authentication and authorization (SSAA) process. Fig.19 It is described that the UCQR is delivered to the UE together with the SSAA success message.

[0379] The S-NSSAI may be associated with the user ID and this association may be saved in the UDM / UDR and / or AAA-S server. In case the configuration of the user in the UE that allows S-NSSAI changes, the UDM / UDR via the SMF / AUSF may trigger the SSAA procedure. On the other hand, there may be cases where the AAA-S may belong to a third party. If the S-NSSAI to user configuration is updated in the AAA-S, the AAA-S may trigger SSAA for the user.

[0380] It should be understood that the network slice specific secondary authentication process does not involve the SMF in the CN as the PDU session establishment process does. However, the scope of third-party entities with control over network functions (e.g., in a network slice) may involve AAA servers or other network functions that may have the capability to facilitate UCQR delivery.

[0381] Fig.19 Step 1. For S-NSSAI that requires network slice specific authentication and authorization, based on the change of subscription information or triggered by AAA-S, AMF may trigger the initiation of network slice specific authentication and authorization process.

[0382] Fig.19 Step 2. The AMF may request the UE for a user ID (EAP ID) for EAP authentication for the S-NSSAI in the NAS MM transport message including the S-NSSAI. This is the S-NSSAI of the H-PLMN, not the locally mapped S-NSSAI value.

[0383] Fig.19 Steps 3-17 of TS 23.502 [6]. Part of the EAP-based SSAA procedure in clause 4.2.9.2 of TS 23.502 [6].

[0384] Fig.19 Step 18. If the user of the UE has been successfully authenticated, the AMF may send a query Nudm_SDM_Get(UCQR) to the UDM. The UDM may negotiate with the UDR to extract the UCQR specific to the queried user from the user's profile and user subscriptions. The UDM may deliver the required UCQR back to the AMF. The UCQR may be placed in the UDR by the SMF or PCF.

[0385] Fig.19 Step 19. As part of the authentication and authorization process, the AMF may send a NAS MM transfer message (user-centric QoS rules [success], EAP success / failure) to the UE. This message means that the AMF may send user-centric QoS rules only if the authentication process is successful, otherwise it sends a NAS MM transfer message (EAP failure).

[0386] Fig.19 This step may correspond to step S19 in clause 4.2.9.2 of TS 23.502 [6].

[0387] UCQR rule delivery during the secondary PDU session authentication process

[0388] Fig. 20Indicates the method by which the UCQR can be delivered to the UE after the secondary PDU session authentication succeeds.

[0389] The SMF determines that it needs to contact the DN-AAA server. The SMF, based on local configuration, may use the SM PDU DN Request container provided by the UE in its NAS request to identify the DN-AAA server. The SM PDU DN Request container may be enhanced to include the User ID during the PDU Session Establishment Request.

[0390] 1. Fig. 20 Step 1 - If there is no existing N4 session available to carry DN related messages between SMF and DN, then SMF selects UPF and triggers N4 session establishment.

[0391] 2. Fig. 20 Step 2 - The SMF provides the enhanced SMPDU DN request container received from the UE in the NAS message to the DN-AAA via the UPF. The SM PDU DN request container IE contains information about the PDU session authorization by the external DN. The SM PDU DN request container includes its DN specific identifier in the Network Access Identifier (NAI) format and the PDU Session ID [9]. When available, the SMF provides the GPSI in the signaling exchanged with the DN-AAA. The UPF transparently relays the message received from the SMF to the DN-AAA server.

[0392] 3. Fig. 20 Step 3 - Step 3 is the exchange of messages between the UE and the DN-AAA server. The DN-AAA server may consider the user ID of the user in authentication and authorization decisions and may determine the DN authorization profile index.

[0393] 4. Fig. 20 Step 4—DN-AAA server confirms successful authentication / authorization of the PDU session. The DA-AAA server may:

[0394] - Provide an SM PDU DN response container to the SMF to indicate successful authentication / authorization;

[0395] - provide DN Authorization Data as defined in clause 5.6.6 of TS 23.501

[12] ;

[0396] - providing a request to be notified of the IP address allocated to the PDU session and / or the N6 traffic routing information or MAC address used by the UE for the PDU session; and

[0397] - Provides the IP address (or IPV6 prefix) of the PDU session.

[0398] - Provides an indication that the UE may require a new set of UCQRs for the corresponding user ID.

[0399] N6 traffic routing information is defined in clause 5.6.7 of TS 23.501

[12] .

[0400] After successful DN authentication / authorization, the session is maintained between the SMF and DN-AAA. If the SMF receives DN Authorization Data, the SMF applies Policy and Charging Control using the DN Authorization Profile Index (see clause 5.6.6 of TS 23.501

[12] ).

[0401] The DN Authorization Profile Index refers to policy and charging control data that may meet the needs of the corresponding user.

[0402] 5. Fig. 20 Step 5 - The SMF or the SMF via the PCF may request the UCQR for the user of the UE authenticated and authorized by the DN-AAA from the UDM. The UDM / UDR provides the UCQR to the SMF.

[0403] 6. Fig. 20 Step 6 - SMF delivers the new UCQR to the UE via the AMF.

[0404] 7. Fig. 20 Step 7 - There is no change in steps 7 and 8 except that the UE may establish and initiate a PDU session based on the newly received user-centric QoS rules.

[0405] Further optimize UCQR rule delivery

[0406] As described earlier in this document, the size of user IDs may not be consistent (e.g., Person HYPERLINK "mailto:name@mno.net" name@mno.net, HYPERLINK "mailto:Person-name.domain-id@mno.net, etc." Person-name.domain-id@mno.net, etc.). Continuously sending longer names over the air may increase the amount of wireless signaling resources. Thus, it is desirable to represent user IDs with IEs of consistent size to achieve optimal computation. One way to represent a user ID for a user in a UE is to have a conversion table that would contain user IDs with corresponding numeric aliases. For example, a user ID of person-name@mno-name.net could be converted to the number 76.

[0407] When the subscription and user profile are linked, the network may send an alias number for the user ID to the UE.

[0408] The benefit of receiving an alias is that the alias can be a UE-local id with a small size (e.g., 1 octet), so that all subsequent signaling can use the alias, resulting in a reduction in the amount of OTA signaling.

[0409] It will be appreciated that in all messages described herein as being sent from the network to the UE and including a user ID, a user ID alias may be used instead.

[0410] Or, if Fig.21 As shown in , the user ID can be implicitly indicated in the UCQR IE (e.g., UCQR IE 2100) by virtue of the position of each user-centric QoS rule in the list. In this case, the user ID is preferably an index of the UE in the list of UEs that have been (individually) configured in the UE. For example, the index of the user can be an alias previously signaled to the UE. The implicit nature of the user ID can further save signaling resource consumption.

[0411] GUI

[0412] Fig. 9 An example GUI 900 is shown that may be used by a person operating a cellular device to request linking and unlinking of a user ID and a subscription associated with the cellular device. This is further described in Section 5.1.

[0413] Fig. 22 GUI 2200 shows an example when a user logs into a multi-user UE and the UE receives a UCQR. Multiple users can have their accounts in the UE. Each user can access multiple applications within their account. Fig. 22 In the example, when a user logs into the UE with user ID User4523, it can trigger the enhanced PDU session establishment or modification process.

[0414] It should be noted that the concepts described in the present disclosure may be applied to non-public networks (NPNs). When the concepts are applied to NPNs, the format of the user identifier may be such that the identification code of the NPN is part of the user identifier, or the user identifier may include a field that can be resolved by the network to the identification code of the NPN. This is necessary so that the network can determine which UDM / UDR is responsible for storing the associated user profile. Alternatively, all messages and processes proposed by the present disclosure that include a user identifier may also include an NPN identifier to indicate that the user identifier is associated with a non-public network.

[0415] It should be understood that any method and process described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium, and when executed by a machine, such as a computer, a server, an M2M terminal device, an M2M gateway device, etc., the instructions perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described above may be implemented in the form of such computer executable instructions. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage device, tape cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other physical medium that can be used to store the desired information and can be accessed by a computer.

[0416] In describing the preferred embodiments of the subject matter of the present disclosure as illustrated in the figures, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

[0417] Thus, it will be appreciated by those skilled in the art that the disclosed systems and methods may be embodied in other specific forms without departing from their spirit or essential characteristics. Thus, the embodiments disclosed at present are considered to be illustrative in all respects, rather than restrictive. It is not exhaustive, nor does it limit the disclosure to the precise form disclosed. In view of the above teachings, various modifications and changes are possible, or various modifications and changes may be obtained from the practice of the disclosure without departing from the breadth or scope of the disclosure. Thus, although specific configurations are discussed herein, other configurations may also be adopted. The disclosure enables numerous modifications and other embodiments (e.g., combinations, rearrangements, etc.), and the numerous modifications and other embodiments are within the scope of ordinary technicians in the art and are considered to fall within the scope of the disclosed subject matter and any equivalents thereof. The features of the disclosed embodiments may be combined, rearranged, omitted, etc. within the scope of the present invention to produce additional embodiments. In addition, certain features are sometimes advantageous when used without corresponding use of other features. Thus, the applicant intends to include all such substitutions, modifications, equivalents, and changes within the spirit and scope of the disclosed subject matter.

[0418] Unless explicitly stated, reference to an element in the singular does not mean "one and only one," but rather "one or more." Furthermore, where a phrase similar to "at least one of A, B, or C" is used in the claims, it is intended that the phrase be interpreted to mean that A may exist alone in an embodiment, B may exist alone in an embodiment, C may exist alone in an embodiment, or any combination of elements A, B, and C may exist in an embodiment; for example, A and B, A and C, B and C, or A and B and C.

[0419] Unless a claim element is expressly referred to herein using the phrase "means for...", that claim element is not to be construed under the provisions of 35 USC 112(f). As used herein, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to the process, method, article, or apparatus. The scope of the invention is indicated by the appended claims, rather than by the foregoing description, and all changes within the meaning and range and equivalents thereof are intended to be embraced therein.

[0420] References

Claims

1. An electronic device, comprising a processor, wherein the processor is configured to: sending a link request message to a wireless network, the link request message requesting that a user identifier be associated with an identifier corresponding to a subscription, the identifier corresponding to the subscription being associated with the electronic device; receiving a registration response from the wireless network, the registration response confirming that the user identifier has been associated with the subscription identifier associated with the electronic device; performing a process of authenticating the user with the wireless network based on the user identifier; and Updated configuration information for the electronic device is received from the wireless network. 2 . The electronic device according to claim 1 , wherein the process of authenticating the user with the wireless network comprises a process based on the Extensible Authentication Protocol (EAP).

3. An electronic device according to claim 1, wherein at least part of the updated configuration information is associated with the user identifier and includes network slice selection assistance information NSSAI for the electronic device, wherein the NSSAI includes at least one single network slice selection assistance information S-NSSAI associated with the user identifier.

4. The electronic device according to claim 1, wherein The processor is configured to determine, based on information input into a graphical user interface (GUI) of the electronic device, that the user identifier is to be associated with the subscription identifier associated with the electronic device.

5. The electronic device of claim 1 , wherein the processor is configured to: wirelessly pairs with another electronic device, and Based on receipt of the user identifier from the other electronic device, it is determined that the user identifier is to be associated with the subscription identifier associated with the electronic device.

6. The electronic device of claim 1, wherein the processor is further configured to receive an alias for the user identifier.

7. The electronic device according to claim 6, wherein The subscription identifier associated with the electronic device is an International Mobile Subscriber Identity (IMSI) of the electronic device.

8. The electronic device according to claim 1, wherein The updated configuration information indicates at least one additional service available for the electronic device and associated with the user identifier.

9. The electronic device according to claim 1, wherein The processor is configured to update configuration information linking the user identifier to available services that are allowed to be accessed by the user identifier upon receiving the updated configuration information.

10. The electronic device according to claim 1, wherein The processor is configured to send a registration update request to the wireless network requesting access to a service based on at least one of the user identifier and the subscription identifier associated with the electronic device.

11. The electronic device according to claim 1, wherein The processor is configured to send a registration update request to the wireless network requesting access to a service based on the user identifier and a subscription identifier corresponding to the electronic device.

12. The electronic device according to claim 1, wherein The processor is configured to send a registration update request to the wireless network requesting access to services based on the user identifier.

13. The electronic device according to claim 10, wherein The processor is configured to receive information identifying one or more services that the electronic device is permitted to access based on the registration update request.

14. The electronic device according to claim 1, wherein The processor is configured to store information linking each of a plurality of user identifiers with one or more services that are permitted to be accessed by the user identifier.

15. The electronic device according to claim 1, wherein The processor is configured to receive and store information corresponding to policy segments that identify how traffic generated at the electronic device is to be handled, wherein at least one of the policy segments is associated with the user identifier.

16. The electronic device according to claim 15, wherein The processor is configured to receive information indicating that a policy segment is no longer associated with the user identifier.

17. The electronic device according to claim 1, wherein: The processor is configured to send a PDU session establishment request, wherein the request indicates that a PDU session is to be associated with a user identifier, and receive a PDU session establishment response having a QoS rule associated with the PDU session.

18. The electronic device according to claim 17, wherein The QoS rules indicate whether they are associated with a user identifier.

19. A method performed by an electronic device, the method comprising: sending a link request message to a wireless network, the link request message requesting an association between a user identifier and a subscription identifier associated with the electronic device; receiving a registration response from the wireless network, the registration response confirming that the user identifier has been associated with the subscription identifier associated with the electronic device; performing a process of authenticating the user with the wireless network based on the user identifier; as well as Updated configuration information for the electronic device is received from the wireless network.

20. A non-transitory computer-readable medium comprising computer program instructions that, when executed by an electronic device, cause the electronic device to: sending a link request message to a wireless network, the link request message requesting an association between a user identifier and a subscription identifier associated with the electronic device; receiving a registration response from the wireless network, the registration response confirming that the user identifier has been associated with the subscription identifier associated with the electronic device; performing a process of authenticating the user with the wireless network based on the user identifier; as well as Updated configuration information for the electronic device is received from the wireless network.

21. A wireless transmit / receive unit WTRU, comprising: The processor is configured as: comparing the traffic generated by the application with the traffic descriptors in one or more UE routing policy URSP rules; Determining URSP rules associated with traffic generated by the application; evaluating a routing descriptor RSD of URSP rules associated with traffic generated by the application; Routing of traffic generated by the application is determined based on the evaluated RSD.

22. The WTRU of claim 21 wherein the traffic descriptor in the one or more URSP rules includes a user ID field.

23. The WTRU of claim 22, wherein the processor is further configured to: Use the User ID field to identify that the URSP rule applies only to traffic generated by one or more User IDs indicated in the User ID field.

24. The WTRU of claim 22, wherein, in a case where a user ID indicated in the user ID field is not associated with the URSP rule, the processor is further configured to interpret the URSR rule as applicable only to traffic not associated with a user.

25. A wireless transmit / receive unit WTRU, comprising: The processor is configured as: receiving first configuration information including an indication of one or more policy segment identifiers (PSIs), wherein each PSI is associated with a policy including one or more UE routing policy (URSP) rules, and wherein each PSI is associated with a plurality of identifiers including a network identifier; storing first configuration information; receiving second configuration information indicating a first PSI associated with a first network identifier, wherein the first PSI indicates one or more new policies; receiving updated configuration information indicating a second PSI associated with a second network identifier, wherein content of the one or more new policies is not updated in response to the updated configuration information; as well as The uplink data is sent based on a determination that the uplink data satisfies a condition in the new policy and based on the second network identifier.

26. The WTRU of claim 25, wherein the content of the policy section includes URSP rules for the policy section.

27. The WTRU of claim 25, wherein the policy segment comprises a plurality of policies, and wherein each policy of the plurality of policies comprises a URSP rule associated with the policy.

28. The WTRU of claim 25 wherein: The updated information changes the conditions for using the policy segment but does not change the URSP rules associated with the policy segment or the policy associated with the policy segment.

29. The WTRU of claim 25, wherein the plurality of identifiers further comprises a user identifier.

Images