CN116158096A - Application reasoning for 5GS network slice policy - Google Patents

Abstract

An apparatus and system for assigning network slices to applications are described. New service requirements are described in which a third party can allocate network slice related information for an application to configure association of network slices with the application for a UE. The list of preferred network operators applied is for sponsor connectivity and takes precedence over roaming steering policies provided by the UE's home public land mobile network. The UE stores user preferences of the applications in a priority order to determine whether to move to a different network when the different applications are activated and use different network slices in the different networks.

Description

Application reasoning for 5GS network slice policy

Priority claim

The present application claims the benefit of priority from U.S. provisional patent application Ser. No.63/092,947, filed on even date 16 at 10/2020, which provisional patent application is incorporated herein by reference in its entirety.

Technical Field

Embodiments relate to fifth generation (5G) wireless communications. In particular, some embodiments relate to roaming guidance for network slice selection based on application information.

Background

The use and complexity of wireless systems, including fourth generation (4G) and fifth generation (5G) networks and the like, has increased due to the increase in the device types of User Equipment (UEs) that use network resources and the amount of data and bandwidth used by various applications (e.g., video streaming) operating on these UEs. As the number and diversity of communication devices has increased substantially, the corresponding network environments (including routers, switches, bridges, gateways, firewalls, and load balancers) have become more and more complex, particularly in the presence of Next Generation (NG) (or new air interface (NR)) systems. As expected, there are a number of problems with the advent of any new technology.

Drawings

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The drawings illustrate generally, by way of example and not by way of limitation, the various embodiments discussed in the present document.

Fig. 1A illustrates a network architecture according to some aspects.

Fig. 1B illustrates a non-roaming 5G system architecture in accordance with some aspects.

Fig. 1C illustrates a non-roaming 5G system architecture in accordance with some aspects.

Fig. 2 illustrates a block diagram of a communication device in accordance with some embodiments.

Fig. 3 illustrates a UE-initiated UE status indication procedure in accordance with some aspects.

FIG. 4 illustrates request/response operations in accordance with some aspects.

Fig. 5 illustrates service specific information provisioning according to some aspects.

Fig. 6 illustrates a UE configuration update procedure for transparent UE policy delivery in accordance with some aspects.

Detailed Description

The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of others. The embodiments set forth in the claims encompass all available equivalents of those claims.

Fig. 1A illustrates a network architecture according to some aspects. Network 140A includes 3GPP LTE/4G and NG network functions that may extend to 6G functions. Thus, although 5G will be mentioned, it should be understood that this will be able to extend to 6G structures, systems and functions. The network functions may be implemented as discrete network elements on dedicated hardware, as software instances running on dedicated hardware, and/or as virtualized functions instantiated on a suitable platform (e.g., dedicated hardware or cloud infrastructure).

Network 140A is shown to include User Equipment (UE) 101 and UE 102. The UEs 101 and 102 are shown as smart phones (e.g., handheld touch screen mobile computing devices connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a portable (laptop) or desktop computer, a wireless phone, a drone, or any other computing device that includes a wired and/or wireless communication interface. The UEs 101 and 102 may be collectively referred to herein as UE 101, and the UE 101 may be configured to perform one or more of the techniques disclosed herein.

Any of the radio links described herein (e.g., as used in network 140A or any other illustrated network) may operate according to any of the example radio communication techniques and/or standards. Any spectrum management scheme may be used including, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (e.g., licensed Shared Access (LSA) in 2.3-2.4GHz, 3.4-3.6GHz, 3.6-3.8GHz, and other frequencies, and Spectrum Access System (SAS) in 3.55-3.7GHz and other frequencies). Different single carrier or Orthogonal Frequency Domain Multiplexing (OFDM) modes (CP-OFDM, SC-FDMA, SC-OFDM, filter bank based multi-carrier (FBMC), OFDMA, etc.), in particular 3GPP NR, may be used by allocating OFDM carrier data bit vectors to corresponding symbol resources.

In some aspects, either of the UEs 101 and 102 may include an internet of things (IoT) UE or a cellular IoT (CIoT) UE, which may include a network access layer designed for low power IoT applications that utilize short term UE connections. In some aspects, either of the UEs 101 and 102 may include Narrowband (NB) IoT UEs (e.g., such as enhanced NB-IoT (eNB-IoT) UEs and further enhanced (FeNB-IoT) UEs). IoT UEs may exchange data with MTC servers or devices via Public Land Mobile Network (PLMN), proximity services (ProSe) or device-to-device (D2D) communications, sensor networks, or IoT networks using technologies such as machine-to-machine (M2M) or machine-type communications (MTC). The M2M or MTC data exchange may be a machine initiated data exchange. The IoT network includes interconnected IoT UEs (which may include (within the internet infrastructure) uniquely identifiable embedded computing devices) with short-term connections. The IoT UE may execute a background application (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network. In some aspects, either of the UEs 101 and 102 may include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

The UEs 101 and 102 may be configured to connect (e.g., communicatively couple) with a Radio Access Network (RAN) 110. RAN 110 may be, for example, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), a next generation RAN (NG RAN), or some other type of RAN.

The UEs 101 and 102 utilize connections 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are shown as implementing communicatively coupled air interfaces and may follow cellular communication protocols, such as global system for mobile communications (GSM) protocols, code Division Multiple Access (CDMA) network protocols, push-to-talk (PTT) protocols, PTT Over Cellular (POC) protocols, universal Mobile Telecommunications System (UMTS) protocols, 3GPP Long Term Evolution (LTE) protocols, 5G protocols, 6G protocols, and so on.

In an aspect, the UEs 101 and 102 may also directly exchange communication data via the ProSe interface 105. ProSe interface 105 may alternatively be referred to as a Side Link (SL) interface, which includes one or more logical channels including, but not limited to, a physical side link control channel (PSCCH), a physical side link shared channel (PSSCH), a physical side link discovery channel (PSDCH), a physical side link broadcast channel (PSBCH), and a physical side link feedback channel (PSFCH).

UE 102 is shown configured to access an Access Point (AP) 106 via a connection 107. Connection 107 may comprise a local wireless connection, such as a connection conforming to any of the IEEE 802.11 protocols, according to which AP 106 may comprise wireless fidelity

And a router. In this example, the AP 106 is shown connected to the internet, rather than to the core network of the wireless system (described in further detail below).

RAN 110 may include one or more access nodes implementing connections 103 and 104. These Access Nodes (ANs) may be referred to as Base Stations (BS), nodebs, evolved nodebs (enbs), next generation nodebs (gnbs), RAN nodes, etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., cell). In some aspects, communication nodes 111 and 112 may be transmission/reception points (TRP). In the case where the communication nodes 111 and 112 are nodebs (e.g., enbs or gnbs), one or more TRPs may function within the communication cell of the NodeB. RAN 110 may include one or more RAN nodes (e.g., macro RAN node 111) for providing macro cells and one or more RAN nodes (e.g., low Power (LP) RAN node 112) for providing femto cells or pico cells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidths than macro cells).

Either of the RAN nodes 111 and 112 may terminate the air interface protocol and may be the first point of contact for the UEs 101 and 102. In some aspects, either of RAN nodes 111 and 112 may implement various logic functions for RAN 110 including, but not limited to, radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling, as well as mobility management. In an example, any of nodes 111 and/or 112 may be a gNB, an eNB, or another type of RAN node.

RAN 110 is shown communicatively coupled to a Core Network (CN) 120 via a Sl interface 113. In aspects, the CN 120 may be an Evolved Packet Core (EPC) network, a next generation packet core (NPC) network, or some other type of CN (e.g., as shown with reference to fig. 1B-1C). In this regard, the S1 interface 113 is divided into two parts: an S1-U interface 114 carrying traffic data between RAN nodes 111 and 112 and a serving gateway (S-GW) 122; and an S1-Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN nodes 111 and 112 and MME 121.

In this regard, the CN 120 includes an MME 121, an S-GW 122, a Packet Data Network (PDN) gateway (P-GW) 123, and a Home Subscriber Server (HSS) 124.MME 121 may be similar in function to the control plane of a legacy serving General Packet Radio Service (GPRS) support node (SGSN). MME 121 may manage mobility aspects in the access such as gateway selection and tracking area list management. HSS 124 may include a database for network users (including subscription related information) to support the handling of communication sessions by network entities. The CN 120 may include one or several HSS 124 depending on the number of mobile subscribers, the capacity of the device, the organization of the network, etc. For example, the HSS 124 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, and the like.

S-GW 122 may terminate S1 interface 113 towards RAN 110 and route data packets between RAN 110 and CN 120. Furthermore, the S-GW 122 may be a local mobility anchor for inter-RAN node handover and may also provide anchoring for inter-3 GPP mobility. Other responsibilities of S-GW 122 may include lawful interception, charging, and some policy enforcement.

The P-GW123 may terminate the SGi interface towards the PDN. The P-GW123 may route data packets between the CN 120 and external networks, e.g., networks including an application server 184 (alternatively referred to as an Application Function (AF)), via an Internet Protocol (IP) interface 125. The P-GW123 may also communicate data to other external networks 131A (which may include the internet, IP multimedia Subsystem (IPs) networks, and other networks). In general, the application server 184 may be an element that provides applications (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.) that use IP bearer resources with the core network. In this regard, P-GW123 is shown to be communicatively coupled to application server 184 via IP interface 125. The application server 184 may also be configured to: one or more communication services (e.g., voice over internet protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UEs 101 and 102 via CN 120 are supported.

The P-GW 123 may also be a node for policy enforcement and charging data collection. Policy and Charging Rules Function (PCRF) 126 is a policy and charging control element of CN 120. In a non-roaming scenario, in some aspects, there may be a single PCRF associated with an internet protocol connectivity access network (IP-CAN) session of the UE in a Home Public Land Mobile Network (HPLMN). In a roaming scenario where traffic is off-home, there may be two PCRFs associated with the IP-CAN session of the UE: a home PCRF (H-PCRF) within the HPLMN and a visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). PCRF 126 may be communicatively coupled to application server 184 via P-GW 123.

In some aspects, the communication network 140A may be an IoT network or a 5G or 6G network, including a 5G new air interface network that uses communication in licensed (5G NR) and unlicensed (5G NR-U) spectrum. One of the current implementations of IoT is the narrowband IoT (NB-IoT). Operations in the unlicensed spectrum may include dual-connection (DC) operations and independent LTE systems in the unlicensed spectrum (accordingly, LTE-based techniques operate only in the unlicensed spectrum without using "anchors" in the licensed spectrum) (referred to as multewire). Further enhanced operation of LTE systems in licensed and unlicensed spectrum may be expected in future releases and 5G systems. Such enhancement operations may include techniques for side link resource allocation and UE processing behavior for NR side link V2X communications.

The NG system architecture (or 6G system architecture) may include RAN 110 and 5G core network (5 GC) 120.NG-RAN 110 may include multiple nodes, such as a gNB and NG-eNB. The CN 120 (e.g., 5G core network/5 GC) may include Access and Mobility Functions (AMFs) and/or User Plane Functions (UPFs). The AMF and UPF may be communicatively coupled to the gNB and the NG-eNB via the NG interface. More specifically, in some aspects, the gNB and NG-eNB may connect to the AMF through a NG-C interface and to the UPF through a NG-U interface. The gNB and NG-eNB may be coupled to each other via an Xn interface.

In some aspects, the NG system architecture may use reference points between various nodes. In some aspects, each of the gNB and NG-eNB may be implemented as a base station, a mobile edge server, a small cell, a home eNB, or the like. In some aspects, the gNB may be a Master Node (MN) in a 5G architecture, and the NG-eNB may be a Secondary Node (SN).

Fig. 1B illustrates a non-roaming 5G system architecture in accordance with some aspects. In particular, fig. 1B illustrates a 5G system architecture 140B in reference point representation, which may be extended to a 6G system architecture. More specifically, UE 102 may communicate with RAN 110 and one or more other 5GC network entities. The 5G system architecture 140B includes a plurality of Network Functions (NF), such as AMF132, session Management Function (SMF) 136, policy Control Function (PCF) 148, application Function (AF) 150, UPF 134, network Slice Selection Function (NSSF) 142, authentication server function (AUSF) 144, and Unified Data Management (UDM)/Home Subscriber Server (HSS) 146.

UPF 134 may provide a connection to a Data Network (DN) 152, and DN 152 may include, for example, operator services, internet access, or third party services. The AMF 132 may be used to manage access control and mobility and may also include network slice selection functionality. The AMF 132 may provide UE-based authentication, authorization, mobility management, etc., and may be independent of access technology. The SMF 136 may be configured to establish and manage various sessions according to network policies. Thus, the SMF 136 may be responsible for session management and assigning IP addresses to UEs. The SMF 136 may also select and control the UPF 134 for data transfer. The SMF 136 may be associated with a single session of the UE 101 or multiple sessions of the UE 101. That is, the UE 101 may have multiple 5G sessions. Each session may be assigned a different SMF. The use of different SMFs may allow each session to be managed separately. Thus, the functionality of each session may be independent of the other.

The UPF 134 can be deployed in one or more configurations depending on the type of service desired and can be connected to a data network. PCF 148 may be configured to: network slicing, mobility management and roaming are used to provide a policy framework (similar to PCRF in 4G communication systems). The UDM may be configured to: store subscriber profiles and data (similar to HSS in 4G communication systems).

AF 150 may provide information about the packet flow to PCF 148 responsible for policy control to support the desired QoS. PCF 148 may set mobility and session management policies for UE 101. To this end, PCF 148 may use the packet flow information to determine the appropriate policies for proper operation of AMF 132 and SMF 136. The AUSF 144 may store data for UE authentication.

In some aspects, the 5G system architecture 140B includes an IP Multimedia Subsystem (IMS) 168B and a plurality of IP multimedia core network subsystem entities (e.g., call Session Control Functions (CSCFs)). More specifically, the IMS 168B includes CSCFs that may act as proxy CSCF (P-CSCF) 162B, serving CSCF (S-CSCF) 164B, emergency CSCF (E-CSCF) (not shown in FIG. 1B), or query CSCF (I-CSCF) 166B. P-CSCF 162B may be configured as a first point of contact for UE 102 within IM Subsystem (IMs) 168B. S-CSCF 164B may be configured to handle session states in the network and E-CSCF may be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. I-CSCF 166B may be configured to act as a contact point within an operator network for all IMS connections destined for subscribers of the network operator or roaming subscribers currently located within the service area of the network operator. In some aspects, I-CSCF 166B may be connected to another IP multimedia network 170E, such as an IMS operated by a different network operator.

In some aspects, the UDM/HSS 146 may be coupled to an application server 160B, which application server 160B may include a Telephony Application Server (TAS) or another Application Server (AS). AS 160B may be coupled to IMS 168B via S-CSCF 164B or I-CSCF 166B.

The reference point representation indicates that there may be interactions between the corresponding NF services. For example, fig. 1B shows the following reference points: n1 (between UE 102 and AMF 132), N2 (between RAN110 and AMF 132), N3 (between RAN110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF148, not shown), N8 (between UDM 146 and AMF 132, not shown), N9 (between two UPF 134, not shown), N10 (between UDM 146 and SMF 136, not shown), N11 (between AMF 132 and SMF 136, not shown), N12 (between AUSF 144 and AMF 132, not shown), N13 (between AUSF 144 and UDM 146, not shown), N14 (between PCF148 and AMF 132 in the case of a non-roaming scenario, or between PCF148 and AMF 132, or between N148 and nsf 132 in the case of a non-roaming scenario, or between N148 and nsf 132, not shown), N14 (between ms 132 and N142, not shown), and N142 between the network(s) and nsf 132. Other reference point representations not shown in fig. 1B may also be used.

Fig. 1C shows a 5G system architecture 140C and a service-based representation. In addition to the network entities shown in fig. 1B, the system architecture 140C may also include a network open function (NEF) 154 and a Network Repository Function (NRF) 156. In some aspects, the 5G system architecture may be service-based, and interactions between network functions may be represented by corresponding point-to-point reference points Ni, or as service-based interfaces.

In some aspects, as shown in fig. 1C, the service-based representation may be used to represent network functions within the control plane that enable other licensed network functions to access their services. In this regard, the 5G system architecture 140C may include the following service-based interfaces: namf 158H (service-based interface shown by AMF 132), nsmf 158I (service-based interface shown by SMF 136), nnef 158B (service-based interface shown by NEF 154), npcf158D (service-based interface shown by PCF 148), nudm 158E (service-based interface shown by UDM 146), naf 158F (service-based interface shown by AF 150), nnrf 158C (service-based interface shown by NRF 156), nnssf 158A (service-based interface shown by NSSF 142), nausf 158G (service-based interface shown by AUSF 144). Other service-based interfaces not shown in fig. 1C (e.g., nudr, N5g-eir, and Nudsf) may also be used.

The NR-V2X architecture may support high reliability low latency side link communications with multiple traffic patterns (patterns), including periodic and aperiodic communications with random packet arrival times and sizes. The techniques disclosed herein may be used to support high reliability in distributed communication systems with dynamic topologies, including side link NR V2X communication systems.

Fig. 2 illustrates a block diagram of a communication device in accordance with some embodiments. The communication device 200 may be a UE, such as a dedicated computer, a personal or laptop computer (PC), a tablet PC or smart phone, a dedicated network device (e.g., eNB), a server running software to configure the server to operate as a network device, a virtual device, or any machine capable of executing instructions (sequentially or otherwise) specifying actions to be taken by the machine. For example, the communication device 200 may be implemented as one or more of the devices shown in FIGS. 1A-1C. Note that the communications described herein may be encoded prior to transmission by a transmitting entity (e.g., UE, gNB) for receipt by a receiving entity (e.g., gNB, UE) and decoded by the receiving entity after receipt.

Examples described herein may include or may operate on logic or multiple components, modules, or mechanisms. Modules and components are tangible entities (e.g., hardware) capable of performing specified operations, and may be configured or arranged in some manner. In an example, the circuitry may be arranged in a specified manner (e.g., internally, or with respect to an external entity (e.g., other circuitry)) as a module. In an example, all or part of one or more computer systems (e.g., stand-alone, client, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) as modules that operate to perform specified operations. In an example, the software may reside on a machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform specified operations.

Thus, the term "module" (and "component") is understood to encompass a tangible entity, whether physically constructed, a concrete configuration (e.g., hardwired), or a temporary (e.g., transient) configuration (e.g., programmed) as an entity that operates in a specified manner or performs some or all of any of the operations described herein. Consider an example where modules are temporarily configured, each of which need not be instantiated at any one time. For example, where a module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as corresponding different modules at different times. Thus, software may configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

The communication device 200 may include a hardware processor (or equivalently, processing circuitry) 202 (e.g., a Central Processing Unit (CPU), GPU, hardware processor core, or any combination thereof), a main memory 204, and a static memory 206, some or all of which may communicate with each other via an interlink (e.g., bus) 208. Main memory 204 may include any or all of removable storage and non-removable storage, volatile memory, or nonvolatile memory. The communication device 200 may also include a display unit 210 (e.g., a video display), an alphanumeric input device 212 (e.g., a keyboard), and a User Interface (UI) navigation device 214 (e.g., a mouse). In an example, display unit 210, input device 212, and UI navigation device 214 may be touch screen displays. The communication device 200 may further include a storage device (e.g., a drive unit) 216, a signal generation device 218 (e.g., a speaker), a network interface device 220, and one or more sensors (e.g., a Global Positioning System (GPS) sensor, compass, accelerometer, or other sensor). The communication device 200 may also include an output controller, such as a serial connection (e.g., universal Serial Bus (USB)), parallel connection, or other wired or wireless connection (e.g., infrared (IR), near Field Communication (NFC), etc.), to communicate with or control one or more peripheral devices (e.g., printer, card reader, etc.).

The storage device 216 may include a non-transitory machine-readable medium 222 (hereinafter referred to simply as a machine-readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 224 may also reside, completely or at least partially, within the main memory 204, within the static memory 206, and/or within the hardware processor 202 during execution thereof by the communication device 200. While the machine-readable medium 222 is shown to be a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 224.

The term "machine-readable medium" can include any medium that can store, encode, or carry instructions for execution by the communication device 200 and that cause the communication device 200 to perform any one or more of the techniques of this disclosure, or that can store, encode, or carry data structures used by or associated with such instructions. Non-limiting examples of machine readable media may include solid state memory, optical and magnetic media. Specific examples of machine-readable media may include: nonvolatile memory such as semiconductor memory devices (e.g., electrically Programmable Read Only Memory (EPROM), electrically Erasable Programmable Read Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as built-in hard disks and removable disks; magneto-optical disk; random Access Memory (RAM); CD-ROM and DVD-ROM discs.

The instructions 224 may also be transmitted or received over a communication network using a transmission medium 226 via the network interface device 220 using any of a variety of Wireless Local Area Network (WLAN) transmission protocols (e.g., frame relay, internet Protocol (IP), transmission Control Protocol (TCP), user Datagram Protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a Local Area Network (LAN), a Wide Area Network (WAN), a packet data network (e.g., the internet), a mobile telephone network (e.g., a cellular network), a Plain Old Telephone (POTS) network, and a wireless data network. The communications over the network may include one or more different protocols, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards (referred to as Wi-Fi), the IEEE 802.16 family of standards (referred to as WiMax), the IEEE 802.15.4 family of standards, the Long Term Evolution (LTE) family of standards, the Universal Mobile Telecommunications System (UMTS) family of standards, point-to-point (P2P) networks, the Next Generation (NG)/fifth generation (5G) standards, and so forth. In an example, the network interface device 220 may include one or more physical jacks (e.g., ethernet jacks, coaxial jacks, or telephone jacks) or one or more antennas to connect to the transmission medium 226.

Note that the term "circuitry" as used herein refers to, is part of or includes the following hardware components: such as electronic circuitry, logic circuitry, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a Field Programmable Device (FPD) (e.g., a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a Complex PLD (CPLD), a high-capacity PLD (hcld), a structured ASIC, or a programmable SoC), a Digital Signal Processor (DSP), etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuitry" may also refer to a combination of one or more hardware elements and program code (or a combination of circuitry and program code for use in an electrical or electronic system), one or more hardware elements being arranged to perform the functions of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as specific types of circuitry.

Thus, the term "processor circuit" or "processor" as used herein refers to a circuit, part of or comprising, that is capable of sequentially and automatically performing a series of arithmetic or logical operations, or recording, storing and/or transmitting digital data. The term "processor circuit" or "processor" may refer to one or more application processors, one or more baseband processors, a physical Central Processing Unit (CPU), a single or multi-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and/or functional processes).

Any of the radio links described herein may operate in accordance with any one or more of the following radio communication technologies and/or standards, including, but not limited to: global system for mobile communications (GSM) radio communications technology, general Packet Radio Service (GPRS) radio communications technology, enhanced data rates for GSM evolution (EDGE) radio communications technology and/or third generation partnership project (3 GPP) radio communications technology, such as Universal Mobile Telecommunications System (UMTS), multimedia free access (FOMA), 3GPP long term evolution (LTE Advanced), code division multiple access 2000 (CDMA 2000), cellular Digital Packet Data (CDPD), mobitex, third generation (3G), circuit Switched Data (CSD), high Speed Circuit Switched Data (HSCSD), universal mobile telecommunications system (third generation) (UMTS (3G)), wideband code division multiple access (universal mobile telecommunications system) (W-CDMA (UMTS)), high Speed Packet Access (HSPA), high Speed Downlink Packet Access (HSDPA), high Speed Uplink Packet Access (HSUPA), high speed packet access Plus (hspa+), universal mobile telecommunications system-time division duplex (UMTS-TDD), time division-code division multiple access (TD-CDMA), time division-synchronous code division multiple access (TD-CDMA), third generation partnership project release 8 (Pre-4 th generation) (3 GPP rel.8 (Pre-4G)), 3GPP rel.9 (third generation partnership project release 9), 3GPP rel.10 (third generation partnership project release 10) 3GPP rel.11 (third generation partnership project release 11), 3GPP rel.12 (third generation partnership project release 12), 3GPP rel.13 (third generation partnership project release 13), 3GPP rel.14 (third generation partnership project release 14), 3GPP rel.15 (third generation partnership project release 15), 3GPP rel.16 (third generation partnership project release 16), 3GPP rel.17 (third generation partnership project release 17) and subsequent releases (e.g., rel.18, rel.19, etc.), 3GPP 5G, 5G new air interface (5G NR), 3GPP 5G new air interface, 3GPP LTE Extra, LTE-Advanced Pro, LTE Licensed Assisted Access (LAA), muLTEfire, UMTS Terrestrial Radio Access (UTRA), evolved UMTS terrestrial radio access (E-UTRA), advanced long term evolution (fourth generation) (LTE Advanced (4G)), cdmaOne (2G), code division multiple access 2000 (third generation) (CDMA 2000 (3G)), evolved data optimized or evolution data only (EV-DO), advanced mobile phone system (first generation) (1G)), full access communication system/extended full access communication system (TACS/ETACS), digital AMPS (second generation) (D-AMPS (2G)), push-to-talk (PTT), mobile phone System (OLTs), advanced mobile phone system (AMTS), MTS (norway Offentlig Landmobil Telefoni, public land mobile phone), MTD (Mobiltelefonisystem D, or mobile telephone system D), public automatic land mobile telephone (Autotel/PALM), ARP (autonomous audiopuhelin, "car radio telephone", finland mobile telephone), NMT (nordic mobile telephone), high capacity version of NTT (japanese telegraph telephone) (Hicap), cellular Digital Packet Data (CDPD), mobitex, dataTAC, integrated Digital Enhanced Network (iDEN), personal Digital Cellular (PDC), circuit Switched Data (CSD), personal Handyphone System (PHS), broadband integrated digital enhanced network (WiDEN), iBurst, unlicensed Mobile Access (UMA) (also known as 3GPP generic access network or GAN standard), zigbee, bluetooth, wireless gigabit alliance (WiGig) standard, generic mmWave standard (wireless system operating at 10-300GHz and above, such as WiGig, IEEE 802.11ad, IEEE 802.11ay, etc.), technologies operating in the higher than 300GHz and THz bands (based on 3GPP/LTE or IEEE 802.11p or IEEE 802.11bd and others), vehicle-to-vehicle (V2V) and vehicle-to-X (V2X) and vehicle-to-infrastructure (V2I) and infrastructure-to-vehicle (I2V) communication technologies, 3GPP cellular V2X, DSRC (dedicated short-range communication) communication systems (e.g., intelligent transportation systems and others (typically operating at or above 5850MHz to 5925MHz (as suggested by the changes in the CEPT report 71, typically up to 5935 MHz)), european ITS-G5 systems (i.e., europe based on DSRC of IEEE 802.11p, including ITS-G5A (i.e., ITS-G5 operates in the european ITS band dedicated to ITS for safety-related applications in the frequency range 5,875ghz to 5,255 ghz), ITS-G5B (i.e., operates in the european ITS band dedicated to ITS non-safety applications in the frequency range 5,855ghz to 5,875 ghz), ITS-G5C (i.e., operates in ITS applications in the frequency range 5,470ghz to 5,725 ghz), DSRC (including 715MHz to 725 MHz) in the 700MHz band in japan, IEEE 802.11 bd-based systems, and the like.

Aspects described herein may be used in the context of any spectrum management scheme, including dedicated licensed spectrum, unlicensed spectrum, licensed exempt spectrum, (licensed) shared spectrum (e.g., lsa=licensed shared access in 2.3-2.4GHz, 3.4-3.6GHz, 3.6-3.8GHz, and further frequencies, and sas=spectrum access system/cbrs=citizen broadband radio in 3.55-3.7GHz and further frequencies). Applicable frequency bands include IMT (international mobile telecommunications) spectrum and other types of spectrum/frequency bands such as frequency bands with national allocations including 450-470MHz, 902-928MHz (note: e.g., FCC Part 15) allocated in the united states), 863-868.6MHz (note: e.g., ETSI EN 300 220) allocated in the european union), 915.9-929.7MHz (note: e.g., allocated in japan), 917-923.5MHz (note: e.g., allocated in korea), 755-779MHz and 779-787MHz (note: e.g., allocated in china), 790-960MHz, 1710-2025MHz, 2110-2200MHz, 2300-2400MHz, 2.4-2.4835GHz (note: it is an ISM band with global availability), and also used by bluetooth in the european union), 2500-2690MHz, 698-790MHz, 610-790MHz, 0-3600MHz, 3800-0 MHz, 3800-3 MHz, 3.7 MHz, and 775.725, and 3.7 MHz (note: e.g., allocated in china), total, which is comprised of the radio frequency bands such as being allocated in the international mobile telecommunications band (note: e.g., allocated in the chinese), 790-960MHz, 1710-2025MHz, 2110-2200MHz, 2300-2.4835 MHz (note: 2.4835GHz (note: i.g., which is an ISM band with global availability), and Wi-5.g., 3405.725) and the radio band (note: 60.725) allocated in the four frequency bands such as the radio bands (e.g., 5.5.5.5.725.5.5.725.5.5.725) which are allocated in the united states) The 5925-7125MHz and 5925-6425MHz bands (note: the next generation Wi-Fi system is expected to include the 6GHz spectrum as the operating band under us and european union considerations, respectively, but note that by the month of 2017, wi-Fi system regulations are not allowed to be completed in the 2019-2020 time frame in this band), IMT-advanced spectrum, IMT-2020 spectrum (which is expected to include 3600-3800MHz, 3800-4200MHz, 3.5GHz band, 700MHz band, frequency bands in the 24.25-86GHz range, etc.), spectrum available under the FCC "spectrum front" 5G initiative (including 27.5-28.35GHz, 29.1-29.25GHz, 31-31.3GHz, 37-38.6GHz, 38.6-40GHz, 42-42.5GHz, 57-64GHz, 71-76GHz, 81-86GHz, 92-94GHz, etc.), the 5.9GHz (typically 5.85-5.925 GHz) and 63-64GHz (smart traffic system) current bands (which are allocated to the wis band, for example, 27.5-28.35GHz, 29.1-29.25GHz, 31-31.3GHz, 38.6GHz, 38.42-42.5 GHz, 42-64 GHz, and 92-94GHz, etc.), wis (which are allocated to the wis band (40.35 g. 40), wis-59, and the wis-band (40.35G) radio band (40) for the almost-59G). A total of 14GHz spectrum is allocated in the united states (FCC part 15), while european union (ETSI EN 302 567 and ETSI EN301 217-2 (for fixed P2P)) allocates a total of 9GHz spectrum), 70.2GHz-71GHz band, any band between 65.88GHz and 71GHz, a band currently allocated to automotive radar applications (e.g., 76-81 GHz), and future bands (including 94-300GHz and above). Furthermore, the scheme may be used in an ancillary manner in a frequency band such as the TV white space frequency band (typically below 790 MHz), where especially 400MHz and 700MHz frequency bands are promising candidates. In addition to cellular applications, specific applications for the vertical market may also be addressed, such as PMSE (program production and special activities), medical, health, surgery, automotive, low latency, drone, etc. applications.

The aspects described herein may also enable hierarchical application of schemes, e.g., by introducing hierarchical prioritization of usage (e.g., low/medium/high priority, etc.) for different types of users based on prioritized access to spectrum, e.g., highest priority to primary users, secondary users, then tertiary users, etc.

Aspects described herein may also be applied to different single carrier or OFDM styles (CP-OFDM, SC-FDMA, SC-OFDM, filter bank based multicarrier (FBMC), OFDMA, etc.), in particular 3GPP NR (new air interface), by assigning OFDM carrier data bit vectors to corresponding symbol resources.

Some features in this document are defined for the network side, e.g. AP, eNB, NR or gnb—note that this term is commonly used in the context of 3GPP fifth generation (5G) communication systems and the like. Still, the UE may also play this role, acting as an AP, eNB or gNB; that is, some or all of the features defined for the network device may be implemented by the UE.

Network slicing has been supported since 3GPP release 15. However, the network slices of the UE are disjoint within the network of a single operator. The UE has no information to access the network slices based on user preferences and active applications, which results in undesirable latency and reduced service experience. In view of enhanced access and support for network slicing, in 3gpp TR22.835 clause 5.7, use case 7, slice access with application preferences, may consider application policies for network slicing, but has not yet been agreed upon service requirements. Note that 3gpp TS 22.261, TS 23.502, TR22.835, studies on enhanced access and support for network slices, TS 22.011 and TS 24.501 are all discussed herein and incorporated by reference.

Based on the service requirements of the network slices of 3gpp TS 22.261 and the solutions for network slices of 3gpp TS 23.501, the 5G network may allocate a list of allowed network slices to the UE based on the UE subscription, UE capabilities, access technology used by the UE, policies of the operator and services provided by the network slices. The following problems remain unsolved:

problem 1: the 5G network (gNB) provides the UE with "operator defined access categories" during the registration procedure. The gNB provides a potential association between the AppID and single network slice selection assistance information (S-NSSAI) for the UE to establish a Packet Data Unit (PDU) session with the allowed S-NSSAI upon receipt of an upper layer request from the AppID identified application. However, the manner in which the network appropriately assigns network slices for the application remains unclear. Note that S-NSSAI uses a slice/service type (SST), which refers to the expected network slice behavior in terms of features and services, and a Slice Discriminator (SD), which supplements the SST to discriminate multiple network slices of the same SST.

Problem 2: the way in which the UE may select the appropriate network slice for an application provided by a third party is not clear, and the third party may have a Service Level Agreement (SLA) with a different network operator and have a preferred Public Land Mobile Network (PLMN) for its application. That is, the third party service provider may provide separate sponsor connections for its subscribers in the preferred PLMN.

Problem 3: the UE makes the way in which the use of network slices used by different applications is prioritized unclear. For example, prioritization between application 1 (which is to use network slice 1 but cannot use network slice 2) and application 2 (which is to use network slice 2 but cannot use network slice 1) is unclear. In this case, when the UE uses network 2 for application 2 and initiates application 1 (which is to use network slice 1 but is not supported in the serving PLMN), a mechanism is added to the UE to determine whether to continue reselection to the new PLMN supporting application 1.

3GPP TS 24.501 describes an operator defined access class to provide access class information related to S-NSSAI, data Network Name (DNN), and OSId+OS App ID. The OSId is sent in a UE STATE INDICATION (UE status indication) message during the registration procedure.

4.5.3 operator defined Access categories

The operator defined access class definitions may be signaled to the UE using non-access stratum (NAS) signaling. Each operator defined access class definition includes the following parameters: a priority value indicating in what order the UE should evaluate the operator defined access class definitions for matching; an operator defined access class number, i.e. an access class number in the range of 32-63, which uniquely identifies the PLMN or an access class in a separate non-public network (SNPN) in which the access class is sent to the UE; and criteria including one or more access category criterion types and associated access category criterion type values. The access category criterion type may be set to: DNN, 5G quality of service (QoS) identifier (5 QI), OS id+os App Id or S-nsai of the application triggering the access attempt. The access category criterion type may be associated with more than one access category criterion value. If the access attempt matches all access category criterion types included in the criterion with any associated access category criterion values, the access attempt matches the operator defined access category defined criterion. Each operator defined access class definition has a different priority value. Several operator defined access class definitions may have the same operator defined access class number.

Fig. 3 illustrates a UE-initiated UE status indication procedure in accordance with some aspects. As shown, the UE transmits a UE status indication message using a registration procedure. During a network-accepted UE-initiated UE status indication procedure, upon receiving a UE status indication message, the PCF operates as described in 3gpp TS 23.502 and 3gpp TS 29.525.

The UE status indication message is sent by the UE to the PCF. The UE status indication message conveys a UE policy part identifier (UPSI) of a UE policy part stored in the UE, indicates whether the UE supports Access Network Discovery and Selection Policies (ANDSP), and conveys one or more OS IDs of the UE.

Table d.5.4.1.1 UE status indication message content

FIG. 4 illustrates request/response operations in accordance with some aspects. Fig. 4 shows the NEF service operation information flow in which, at operation 0, NF subscribes to UDM notifications of UE and/or group subscription data updates. NF can subscribe to group subscription data from UDM in this step and be notified of group subscription data updates in step 7 using shared data features defined in TS 29.503.

At operation 0b, which is conditional on using a network data analysis function (NWDAF) assistance value, AF may subscribe to NWDAF via NEF in order to learn UE mobility analysis and/or UE communication analysis for a UE or a group of UEs by applying the procedure specified in TS 23.288 clause 6.1.1.2. The analysis Id is set to any value specified in TS 23.288 clause 6.7.1.

At operation 0c, which is conditional on using NWDAF assistance values, the AF validates the received data and derives any expected UE behavior parameters defined in TS 23.502 clause 4.15.6.3 for a UE or a group of UEs.

At operation 1, the AF provides one or more parameters to be created or updated to the NEF in an nnef_parameter provision_create or nnef_parameter provision_update or nnef_parameter provision_delete request. A General Public Subscription Identifier (GPSI) identifies the UE and a transaction reference ID identifies a transaction request between the NEF and the AF. For the case of nnef_parameterProvisions_Create, NEF assigns a transaction reference ID to the nnef_parameterProvisions_Create request.

The NEF checks whether the requester is allowed to perform the requested service operation by checking an identifier (i.e., AF ID) of the requester. For a creation request associated with a 5G VN group, the external group ID identifies the 5G VN group. The payload of the nnef_parameterprovision_update request includes one or more of the following parameters: the UE behavior parameters (see TS 23.502 clause 4.15.6.3), network configuration parameters (see TS 23.502 clause 4.15.6.3 a), external group ID and 5G VN group data (i.e. 5G-VN configuration parameters) (see TS 23.502 clause 4.15.6.3 b), 5G VN group membership management parameters (see TS 23.502 clause 4.15.6.3 c) or location privacy indication parameters of "LCS privacy" data subsets of subscription data (see TS 23.502 clause 5.2.3.3.1 and TS 23.273 clause 7.1) are expected. The AF may request deletion of the 5G VN configuration by sending nnef_parameterprovision_delete to the NEF.

At operation 2, if the NEF grants the AF provisioning parameters, the NEF requests creation, updating and storage or deletion of the provisioned parameters as part of the subscriber data via a nudm_parameter provisioning_create, nudm_parameter provisioning_update or nudm_parameter provisioning_delete request message, which includes the provisioned data and the NEF reference ID. If the AF is not authorized to allocate these parameters, then NEF proceeds to operation 6, indicating the reason for the failure in an Nnef_ParameterProvisionCreateUpdate/Deleteresponse message. Operation 7 is not applicable to this case. For non-roaming situations and without authorization or authentication of the UDM, if the request is not associated with a 5G VN group, the NEF can directly forward external parameters to the UDR via a nudr_dm_update request message. In this case, the UDR responds to the NEF via a nudr_dm_update response message.

At operation 3, the UDM may read the corresponding subscription information from the UDR through nudr_dm_query in order to verify the data updates and authorize the changes for the subscriber or group for the corresponding AF.

At operation 4, if the UDM grants the AF to the subscriber provisioning parameters, the UDM parses the GPSI into SUPI and requests creation, update or deletion of the provisioned parameters as part of the subscriber data via a nudr_dm_create/Update/Delete request message, which message includes the provisioned data.

If a new 5G VN group is created, the UDM assigns a unique internal group ID for that 5G VN group and includes the newly assigned internal group ID in the Nudr_DM_Create request message. If the 5G VN group member list is changed, or the 5G VN group data has changed, the UDM updates the UE and/or group subscription data according to the AF/NEF request. The UDR stores the allocated data as part of the UE and/or group subscription data and responds with a nudr_dm_create/Update/Delete response message.

When 5G VN group data is updated (as described in TS 23.502 clause 4.15.6.3b), the UDR notifies the subscribing PCF by sending nudr_dm_notify defined in TS 23.502 clause 4.16.12.2.

If the AF is not authorized to allocate parameters, the UDM proceeds to operation 5, indicates the reason for the failure in a Nudm_ParameterProvision_update response message, and does not perform operation 7.

The UDM classifies the received parameters (i.e. the expected UE behaviour parameters or network configuration parameters or 5G VN configuration parameters or location privacy indication parameters) into AMF-associated parameters and SMF-associated parameters. The UDM may associate the received parameters with the DNN and/or S-nsai of the particular subscription using the AF ID received from the NEF in operation 2. The UDM stores the SMF association parameters under the corresponding session management subscription data type.

Each parameter or set of parameters may be associated with a validity time. The validity time is stored in the UDM/UDR and in each NF to which the parameters are assigned (e.g., in AMF or SMF). After expiration of the validity time, each node autonomously deletes the parameters without explicit signaling.

At operation 5, the UDM responds to the request with a Nudm_ParameterProvisionCreateUpdate/Delete response. If the process fails, the cause value indicates the cause.

At operation 6, the NEF responds to the request with an Nnef_ParameterProvisionCreateUpdate/Deleteresponse. If the process fails, the cause value indicates the cause.

At operation 7 (which is conditional and only occurs after operation 4 is successful), the UDM notifies the subscribed network functions (e.g., AMFs) of updated UE and/or group subscription data via a nudm_sdm_notification Notification message.

a) If NF is an AMF, the UDM performs a Nudm_SDM_Notification (SUPI or internal group identifier, AMF associated parameters, etc.) service operation. The AMF identifies whether there is an overlapping parameter set in the expected UE behavior and merges the parameter sets. The AMF uses the received AMF-associated parameters to derive appropriate UE configurations for the NAS parameters and to derive core network assisted RAN parameters. The AMF may determine the registration area based on parameters Stationary indication (stationary indication) or Expected UE Moving Trajectory (expected UE movement trajectory).

b) If NF is SMF, the UDM performs a Nudm_SDM_Notification (SUPI or internal group identifier, SMF association parameter set, DNN/S-NSSAI, etc.) service operation.

The SMF stores the received SMF association parameters and associates the SMF association parameters with the PDU session based on the DNN and S-nsai included in the message from the UDM. The SMF identifies whether there is an overlapping parameter set in the expected UE behavior and merges the parameter sets. The SMF may use the SMF association parameters as follows:

the SMF configures the UPF accordingly. The SMF may use Scheduled Communication Type (schedule communication type) parameters or Suggested Number of Downlink Packets (suggest downlink packet number) parameters to configure how many downlink packets the UPF is to buffer. The SMF may use the parameter Communication duration time (communication duration) to determine to deactivate the User Plane (UP) connection and perform a Core Network (CN) initiated selective deactivation of the UP connection for the existing PDU session.

The SMF may derive the SMF derived CN assisted RAN information for the PDU session. The SMF provides the SMF-derived CN assisted RAN information to the AMF as described in the PDU session establishment procedure or the PDU session modification procedure. The NEF or UDM may also update the corresponding UDR data as appropriate via the nudr_dm_create/Delete service operation.

The AF request sent to the NEF contains the following information:

1) Service description. The service description is information for identifying a service to which the service parameter is applied. The service description in the AF request may be represented by a combination of DNN and S-nsai, an AF service identifier or an application identifier.

2) Service parameters. The service parameters are service specific information to be allocated in the network and communicated to the UE in order to support the service identified by the service description.

3) A target UE or a group of UEs. The target UE or a group of UEs indicates the UE to which the service parameters are to be delivered. Each UE may be identified by a GPSI or IP address/prefix or MAC address. The UE group may be identified by an external group identifier defined in TS 23.682. If the identifier of the target UE or set of UEs is not provided, the service parameters are passed to any UE using the service identified by the service description.

The NEF grants the AF request received from the AF and stores this information in the UDR as "application data". When the UE is reachable, the PCF delivers the service parameters to the target UE.

Fig. 5 illustrates service specific information provisioning according to some aspects. The AF provides service specific parameters to the PLMN and UE using the nnef_serviceparameters service shown in fig. 5.

At operation 1, to Create a new request, the AF invokes an nnef_serviceparameter_create service operation. To Update or remove an existing request, the AF invokes an Nnef_ServiceParameter_Update or an Nnef_ServiceParameter_Deleteservice operation along with the corresponding transaction reference ID, which is provided to the AF in an Nnef_ServiceParameter_Create response message. The content of the service operation (AF request) includes the information described in TS 23.502 clause 5.2.6.11.

At operation 2, the AF sends its request to the NEF. The NEF grants the AF request. The NEF performs the following mapping: mapping the AF service identifier to a DNN and S-NSSAI combination determined by the local configuration; mapping the GPSI in the target UE identifier into SUPI according to the information received from the UDM; and mapping an external group identifier to an internal group identifier in the target UE identifier according to the information received from the UDM. For the Nnef serviceparameter_create service operation, the NEF assigns a transaction reference ID to the Nnef serviceparameter_create request.

At operation 3, for the nnef_serviceparameter_create or Update service operation, the NEF stores the AF request information as "application data" (set for a subset of data of "service specific information") in the UDR along with the assigned transaction reference ID. For the nnef_serviceparameter_delete service operation, the NEF deletes the AF request information from the UDR.

At operation 4, the NEF responds to the AF. For the Nnef serviceparameter_create response message, the response message includes the assigned transaction reference ID. If the UE registers with the network and the PCF performs subscription for notification of modified data in the UDR by invoking nudr_dm_subscribe (AF service parameter provisioning information, SUPI, data set setting for "application data", data subset setting for "service specific information") at operation 0, the following operations are performed:

at operation 5, the PCF receives a nudr_dm_notify notification of the data change from the UDR. The PCF does not have to subscribe to application specific information for each UE (e.g., if the PCF has received application specific information for a group of UEs or for DNNs through subscriptions of other UEs). The same application specific information is delivered to each UE in the group or DNN.

At operation 6, the PCF initiates UE policy delivery as specified in TS 23.502 clause 4.2.4.3.

When the PCF wants to update the UE policy information in the UE configuration (i.e., the UE policy), a UE configuration update procedure for transparent UE policy delivery is initiated. In the non-roaming case, the V-PCF is not involved and the role of the H-PCF is performed by the PCF. For roaming scenarios, the V-PCF interacts with the AMF and the H-PCF interacts with the V-PCF.

Fig. 6 illustrates a UE configuration update procedure for transparent UE policy delivery in accordance with some aspects. In fig. 6, at operation 0, the PCF decides to update the UE policy based on a trigger condition (e.g., initial registration, registration with 5GS when the UE moves from EPS to 5GS, or in order to update the UE policy), as follows:

for initial registration and registration with 5GS when the UE moves from EPS to 5GS, the PCF compares the list of PSI included in the UE policy information in the npcf_ue policy control_create request and determines whether to update the UE policy information and provides it to the UE via the AMF using a DL NAS TRANSPORT message as described in clause 6.1.2.2.2 of TS 23.503. For network-triggered UE policy updates (e.g., change of UE location, change of subscribed S-nsai, as described in clause 6.1.2.2.2 of TS 23.503), the PCF examines the latest PSI list to decide which UE policies to send to the UE.

The PCF checks whether the size of the resulting UE policy information exceeds a predefined limit. If the size is under the limit, the UE policy information is included in a single Namf_communication_N1N2MessageTransferSuervice operation, as described below. If the size exceeds the predefined limit, the PCF splits the UE policy information into smaller, logically independent UE policy information, thereby ensuring that the size of each piece of information is below the predefined limit. Each piece of UE policy information is then sent in a separate namf_communication_n1n2message transfer service operation, as described below.

NAS messages from AMF to UE do not exceed the maximum size limit allowed in NG-RAN (PDCP layer), so the predefined size limit in PCF is related to this limit. A mechanism for splitting UE policy information is described in TS 29.507.

At operation 1, the PCF invokes the namf_communication_n1n2message transfer service operation provided by the AMF. The message includes SUPI, UE policy container.

At operation 2, if the UE is registered in the 3GPP access or the non-3GPP access and the AMF is reachable to the UE, the AMF transparently transmits the UE policy container to the UE via the registered and reachable access. If the UE is registered in both 3GPP and non-3GPP accesses and the same AMF is reachable and serves the UE on both accesses, the AMF transparently communicates the UE policy container to the UE via one of the accesses based on the AMF local policy. If the AMF is not reachable for the UE on both the 3GPP access and the non-3GPP access, then the AMF reports to the PCF using Namf_communication_N1N2TransferFailureNotification that the UE policy container cannot be delivered to the UE, as in operation 5 in TS 23.502 clause 4.2.3.3.

If the AMF decides to transparently communicate the UE policy container to the UE via the 3GPP access (e.g., the UE is registered only in the 3GPP access and the AMF is reachable to the UE), or if the UE is registered in both the 3GPP and non-3GPP accesses served by the same AMF and the AMF is reachable to the UE via the 3GPP access based on the local policy decision and the UE is in CM-IDLE and the AMF is reachable to the UE in the 3GPP access, the AMF starts the paging procedure by sending the paging message (in TS 23.502 clause 4.2.3.3) described in operation 4b of the network triggered service request. Upon receiving the paging request, the UE initiates a UE-triggered service request procedure (TS 23.502 clause 4.2.3.2).

At operation 3, if the UE is in CM-CONNECTED mode on the 3GPP access or the non-3GPP access, the AMF transparently transmits a UE policy container (UE policy information) received from the PCF to the UE. The UE policy container includes a policy part list described in TS 23.503.

At operation 4, the UE updates the UE policy provided by the PCF and sends the result to the AMF.

At operation 5, if the AMF receives the UE policy container and the PCF subscribes to the receipt of the notified UE policy container, the AMF forwards the response of the UE to the PCF using the namf_communication_n1message notification service operation. The PCF maintains the latest PSI list delivered to the UE and updates the latest PSI list in the UDR by invoking nudr_dm_update (SUPI, policy data, policy set entries, updated PSI data) service operations. If the PCF notifies the UE of the policy delivery failure, the PCF may initiate a UE policy association modification procedure to provide a new trigger "connection state change" to the AMF in the policy control request trigger for the UE policy association, as defined in clause 4.16.12.2 of 23.502.

For backward compatibility, the PCF may subscribe to a "connection state change (IDLE or CONNECTED)" event in the Rel-15 AMF, as defined in clause 5.2.2.3 of 23.502.

SoR list related TS: the purpose of the TS 22.011 sub-clause 3.2.2.8, TS 22.261 sub-clauses 6.30 (for SoR) and 6.1 (for network slice), TS 23.122-control plane solution for roaming steering in 5GS procedure is to allow the HPLMN to update the "operator controlled PLMN selector and access technology" list in the UE by providing the HPLMN protection list of preferred PLMN/access technology combinations via NAS signaling, TS 24.501: the SoR list PLMN IDs and access technology identifiers are provided in descending order of priority, i.e. PLMN ID 1 indicates the highest priority and PLMN ID n indicates the lowest priority.

Based on the association of applications with applicable network slices in the same or different PLMNs, various solutions may be used to solve three pending problems. Solution 1: new service requirements. Solution 2: the AF request may be used for PCF reasoning of application classification and specific parameter updating via UE policy configuration update procedure for application policy. Solution 3 and solution 4: AF request for specific parameter update via UE policy configuration update procedure for applying specific roaming guidance policy (which takes precedence over the roaming guidance policy provided by HPLMN). Solution 5: user preference settings of the application that can be used before triggering PLMN changes are used for network slicing of the application.

The S-NSSAI may have standard values (i.e., such S-NSSAI may contain only SSTs with standardized SST values, see clause 5.15.2.2, and no SDs) or non-standard values (i.e., such S-NSSAI may contain both SSTs and SDs, or only SSTs without standardized SST values and no SDs). The S-nsai having a non-standard value identifies a single network slice within the PLMN with which the S-nsai is associated. The S-nsai with non-standard values is not used by the UE for access layer procedures in any PLMN other than the PLMN with which the S-nsai is associated.

Based on TS23.501, clause 5.15.2.2: normalized SST value: the standardized SST values provide a way to establish global interoperability for slices so that PLMNs can more efficiently support roaming use cases for the most common SSTs. The following table 5.15.2.2-1 provides a standardized SST.

Table 5.15.2.2-1-normalized SST values

Slice/service type	SST value	Characteristics of
			eMBB	1	The slices are suitable for treatment 5G enhances mobile broadband.
URLLC	2	The slices are suitable for handling ultra-reliable low latency communications.
			MIoT	3	Slices are suitable for processing large-scale IoT.
V2X	4	The slice is suitable for handling V2X services.

The solution to the above problem is applicable and extensible to standardized SST values defined in future versions.

Solution 1: new service requirements. The first service requirement is that the 5G network provide a mechanism for third parties to provide their application users with network slice related information (e.g., priority, qoS class, network slice type, etc.) in order for the network to configure the UE with the appropriate association of network slices and applications. The second service requirement is that the 5G network provide a mechanism for configuring the UE with a network slice configuration related to the application's preferred network operator list, which is considered for sponsor connectivity and takes precedence over the roaming control (SoR) policy provided by the HPLMN. A third service requirement is that the 5G system allows the UE to store user preferences for applications in a priority order to determine whether to move to a preferred network when different applications are activated and use different network slices in different networks.

Solution 2: PCF reasoning for application classification and AF request for specific parameter update via UE policy configuration update procedure for application policy. This supports an AF request for provisioning parameters related to the association of an application and SST shown in fig. 4 based on the following procedure:

operation 0: NF is PCF.

Operation 1: the AF provides one or more parameters to be created or updated to the NEF in an nnef_parameter provision_create or nnef_parameter provision_update or nnef_parameter provision_delete request.

The payload of the nnef_parameterprovision_update request includes one or more of the following parameters:

TABLE 1 description of expected application configuration parameters

These parameters are classified in the UDM as PCF-associated parameters and sent to the PCF.

Operations 2, 3, and 7: the message contains the expected application configuration parameters.

Solution 2.1:

according to solution 2, the pcf may further configure the configuration SST for osi+appid for S-nsai using the SST and the parameters of osi+appid, wherein the osi is based on the UE status indication included in the registration request message from the UE. The AMF may include an operator defined access class with both S-nsai and osid+appid in a registration accept message to the UE.

With the operator defined access class information, the UE may determine an association between the osid+appid and the S-nsai and may establish a PDU session with the allowed S-nsai upon receiving an upper layer request from the application identified by the osid+appid.

Solution 2.2:

also in accordance with solution 2, if the preferred QoS service requirement is provided, the PCF may further use the parameters to provide service differentiation to the UE based on the SD between S-nsais with the same SST as the application. Two methods may be used to provide service differentiation for different UEs:

the SD of S-NSSAI can be used to configure S-NSSAI with different QoS requirements. Thus, the 5G network may assign S-nsai#1 with higher QoS requirements to user 1 with platinum membership of the application and assign S-nsai#2 with normal QoS requirements to user 2 with normal membership. Such association may be provided in an operator defined access class. Furthermore, a priority value of an operator defined access class may be set between S-nsai and osid+appid with the same configuration SST. For example, user 1 (platinum membership) may have a higher priority value for one operator-defined access category of S-nsai #1 and osid+appid than user 2 (normal membership), while user 2 may have a higher priority value for one operator-defined access category of S-nsai #2 and osid+appid than user 1.

Solution 3:

this provides a way for the network to properly dispatch network slices for the application. Specifically, the AF issues a request on behalf of an application not belonging to the PLMN of the serving UE by referring to TS 23.502 clause 4.15.6.7, wherein the AF request contains a service description, service parameters and a target UE or set of UEs, and wherein the service parameters are service specific information to be provisioned in the network and delivered to the UEs in order to support the service identified by the service description.

The complement of TS 23.502 clause 4.15.6.7 includes, as shown in fig. 5: the service description includes the SST type for the network slice of the application identified by the osid+appid, or the SST type+the preferred SD of the network slice. The PCF uses the service parameters and service description to configure the association of network slices and applications. During the registration procedure shown in fig. 5, the AMF may configure the operator defined access class information and provide this information to the target UE. The PCF uses the service parameters and service description to configure the association of the network slice and application and assign the association to the target UE. Using both the service parameters and the operator defined access categories, the UE may determine an association between the osid+appid and the S-nsai and may establish a PDU session with the allowed S-nsai upon receiving an upper layer request from the application identified by the osid+appid.

Solution 4:

the AF requests a specific parameter update via a UE policy configuration update procedure for applying a specific SoR policy. These parameters take precedence over SoR policies provided by the HPLMN. According to solution 3, this may allow the UE to select an appropriate network slice for an application provided by a third party having an SLA with a different network operator, and by modifying fig. 5 such that the service parameters include a list of application preferred PLMN IDs with their preferred PLMNs applied.

If the UE stores service parameters with a combination of the SOR list and DNN/SST or S-nsai/application ID of the network slice combination and the application preferred PLMN ID list, the UE selects the preferred PLMN with the highest priority within the overlay based on the application preferred PLMN ID list. That is, the preferred PLMN ID list is applied in preference to the SOR list with network slice combinations.

Solution 4.1:

according to solution 4, the service parameters applying the preferred PLMN ID list are for sponsor connectivity, wherein the sponsor connected billable party is a third party service provider. This allows third parties with SLAs to some network operators to provide sponsor connectivity for their application users. Thus, the UE prioritizes application of the preferred PLMN ID list over the SOR list with network slice combining only when the preferred PLMN ID list is used to initiate a PDU session for the network slice.

Solution 5:

this solution may allow the UE to prioritize the use of network slices for different applications. The UE configures priorities of appid#1, appid#2, etc. for user preferences. When app#x is activated, the UE checks the user preference of the APP preference list and decides whether to stay in the current PLMN if the preferred PLMN ID list of app#x is different from the serving PLMN. Alternatively, if the preferred PLMN ID list of app#x is different from the serving PLMN, the UE presents notification information to obtain user consent before continuing the procedure of changing PLMNs for app#x.

Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the disclosure. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments shown are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The detailed description is, therefore, not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Subject matter may be referred to herein, individually and/or collectively, by the term "embodiment" merely for convenience and without intending to voluntarily limit the scope of this application to any single inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

In this document, the terms "a" or "an" are used to include one or more than one, independent of any other instances or usages of "at least one" or "one or more," as is common in patent documents. In this document, the term "or" is used to refer to a non-exclusive "or" such that "a or B" includes "a but not B", "B but not a" and "a and B" unless otherwise indicated. In this document, the terms "comprise" and "wherein" are used as simple English equivalents of the respective terms "comprising" and "wherein". Furthermore, in the following claims, the terms "comprise" and "comprise" are open-ended, i.e., a system, UE, article, composition, constitution, or process that comprises elements other than those listed after such term in the claims, still be considered to fall within the scope of the claims. Furthermore, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

The abstract is provided to comply with 37c.f.r. ≡1.72 (b), which requires an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the foregoing detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. The disclosed method should not be interpreted as reflecting the intent: the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Claims (20)

1. An apparatus for a User Equipment (UE), the apparatus comprising:

processing circuitry configured to:

decoding network slice related information from a third party of a Public Land Mobile Network (PLMN), the network slice related information comprising an association between a network slice and an application, the application comprising an application of the third party;

activating the application after receiving the network slice related information; and

Selecting a network slice based on the network slice related information in response to activation of the application; and

a memory configured to: and storing the network slice related information.

2. The apparatus of claim 1, wherein:

the network slice related information includes a network slice configuration based on a list of preferred network operators for applications considered for sponsor connectivity, an

The processing circuit is further configured to: the network slice configuration is used in preference to a roaming guidance (SoR) policy provided by a Home PLMN (HPLMN) of the UE.

3. The apparatus of claim 1, wherein:

the processing circuit is further configured to: decoding network slice related information from the serving PLMN,

the serving PLMN is one of a Home PLMN (HPLMN) or a visited PLMN,

the network slice related information is based on service specific information for supporting the service identified by the service description, and

the service specific information is included in a service parameter in an Application Function (AF) request, the AF request including the service description, the service parameter and a target UE or a group of UEs.

4. The apparatus of claim 3, wherein the service description comprises a slice/service type (SST) type for a network slice of an application identified by an Operating System Identifier (OSID) and an application identifier (APPID), or an SST type and a preferred service identifier (SD) for the network slice.

5. The apparatus of claim 3, wherein:

the network slice related information contains an association between a network slice and an application from an Access and Mobility Function (AMF) or Policy and Charging Function (PCF) that configures the association using service parameters and service descriptions in the AF request, an

After registering with the serving PLMN, the processing circuitry is further configured to: -decoding operator defined access class information from said AMF.

6. The apparatus of claim 5, wherein the processing circuit is further configured to:

determining an association between an Operating System Identifier (OSID) of an application and an application identifier (AppID) and single network slice selection assistance information (S-NSSAI) based on the service parameters and operator defined access class information; and

in response to receiving an upper layer request from an application identified by a particular OSID and AppID, a Packet Data Unit (PDU) session is established with the requested S-NSSAI within the allowed S-NSSAI.

7. The apparatus of claim 3, wherein:

the service parameters include applying a list of preferred PLMN IDs, and

the processing circuit is further configured to: the application preferred PLMN ID list is used in preference to a roaming guidance (SoR) list with network slice combinations provided by a Home Public Land Mobile Network (HPLMN) of the UE.

8. The apparatus of claim 7, wherein the processing circuit is further configured to:

based on the application preferred PLMN ID list, the preferred PLMN with the highest priority is selected within the coverage.

9. The apparatus of claim 8, wherein the service parameters applying the preferred PLMN ID list are for sponsor connectivity, wherein the billable party of the sponsor connectivity is a service provider of the third party.

10. The apparatus of claim 1, wherein the processing circuit is further configured to:

activating another application;

determining that the application and the other application are to use different network slices in different PLMNs; and

based on the stored user preferences of the application and the further application in a priority order, it is determined whether to move from the PLMN to a different PLMN.

11. The apparatus of claim 10, wherein the processing circuit is further configured to:

based on the priority of the application identified by the application ID in the application preference list, a determination is made as to whether to move from the PLMN to the different PLMN, and a determination is made as to whether to stay with the PLMN based on whether the preferred PLMN ID of the application is different from the PLMN.

12. The apparatus of claim 11, wherein the processing circuit is further configured to:

In response to determining to switch to the other PLMN, a notification is generated for obtaining user consent to switch to the other PLMN prior to switching to the other PLMN.

13. The apparatus of claim 1, wherein the network slice related information comprises a priority, a quality of service (QoS) level, and a slice/service type (SST).

14. An apparatus for a Policy and Control Function (PCF), the apparatus comprising:

processing circuitry configured to:

encoding the Nudm SDM subscnibe request for transmission to a Unified Data Management (UDM); and

decoding, in response to the nudm_sdm_subscore request, a nudm_sdm_notification from the UDM, the nudm_sdm_notification including an intended application configuration parameter from an Application Function (AF) to a network open function (NEF) in an nnef_parameter provisioning_update request, the intended application configuration parameter comprising:

an Operating System Identifier (OSID) and an application identifier (AppID) that identify applications to which the User Equipment (UE) has subscribed; and

a slice/service type (SST) identifying an associated SST for the application for a network slice of a service network; and

a memory configured to: the expected application configuration parameters are stored.

15. The apparatus of claim 14, wherein:

the processing circuit is further configured to: configuring single network slice selection assistance information (S-nsai) for associated OSID and AppID using the SST, and

the OSID is based on a UE status indication included in a registration request message from the UE and an operator defined access class with S-NSSAI and OSID and APPID in a registration accept message to the UE.

16. The apparatus of claim 14, wherein the expected application configuration parameters further comprise a preferred quality of service (QoS) service requirement that identifies QoS parameters for a UE using the application.

17. The apparatus of claim 16, wherein:

the processing circuit is further configured to: using the expected application configuration parameters, providing service differentiation to the UE based on a service differentiation indicator (SD) between single network slice selection assistance information (S-NSSAI) with the same SST of the application, and

at least some of the S-nsais with different SDs have different QoS requirements associated with different user membership levels for the application.

18. The apparatus of claim 14, wherein:

The processing circuit is further configured to:

decoding AF requests sent on behalf of applications not belonging to a Public Land Mobile Network (PLMN) serving said UE, each request comprising a service description, service parameters and a target UE or a set of UEs, wherein said service parameters are service specific information to be allocated in said PLMN and communicated to said UE to support a service identified by said service description; and

configuring an association of the network slice and application using the service parameters and service description and assigning the association to a target UE, and

the service description includes SSTs of network slices for applications identified by the OSID and AppID, or SSTs and preferred service identifiers (SDs) of the network slices.

19. A non-transitory computer-readable storage medium storing instructions for execution by one or more processors of a User Equipment (UE), the one or more processors configuring the UE to, when executed:

decoding network slice related information from a Public Land Mobile Network (PLMN), the network slice related information comprising an association between a network slice and an application;

activating a first application after receiving the network slice related information;

Selecting a network slice of the PLMN based on the network slice related information and the stored user preferences;

activating a second application after activating the first application; and

in response to activation of the second application:

determining that the preferred PLMN of the second application is different from the PLMN; and

determining which of a preferred PLMN of the second application and the PLMN to use based on the user preference, the user preference comprising an application preference list comprising priorities of the first application and the second application.

20. The medium of claim 19, wherein the instructions, when executed, further configure the one or more processors to configure the UE to:

in response to determining to switch from the PLMN to the preferred PLMN of the second application, user consent to the switch is obtained prior to switching from the PLMN to the preferred PLMN of the second application.

Images