Application reasoning for 5GS network slicing strategy

Abstract

Apparatus and systems for assigning network slices to applications are described. New service requirements are described, in which a third party can assign network slice-related information to an application to configure the association between the network slice and the application for the UE. A preferred network operator list for the application is used for sponsor connection and takes precedence over the roaming guidance policy provided by the UE's home public terrestrial mobile network. The UE stores user preferences for applications in a priority order, which is used to determine whether to move to a different network when different applications are activated and using different network slices in different networks.

Description

[0001] Priority requirements

[0002] This application claims the benefit of priority to U.S. Provisional Patent Application Serial No. 63 / 092,947, filed October 16, 2020, which is incorporated herein by reference in its entirety. Technical Field

[0003] The embodiments relate to fifth-generation (5G) wireless communication. Specifically, some embodiments involve roaming guidance for network slice selection based on application information. Background Technology

[0004] The use and complexity of wireless systems (including fourth-generation (4G) and fifth-generation (5G) networks) increase due to the increasing types of user equipment (UEs) using network resources and the increasing data volume and bandwidth used by various applications operating on these UEs (e.g., video streaming). With the massive increase in the number and diversity of communication devices, the corresponding network environment (including routers, switches, bridges, gateways, firewalls, and load balancers) becomes increasingly complex, especially with the emergence of next-generation (NG) (or new radio (NR)) systems. As expected, with the emergence of any new technology, numerous challenges arise. Attached Figure Description

[0005] In accompanying drawings that are not necessarily drawn to scale, similar reference numerals may describe similar parts in different views. Similar numbers with different letter suffixes may indicate different instances of similar parts. The accompanying drawings generally illustrate the various embodiments discussed in this document by way of example rather than limitation.

[0006] Figure 1A The network architecture is shown based on several aspects.

[0007] Figure 1B The non-roaming 5G system architecture is shown based on some aspects.

[0008] Figure 1C The non-roaming 5G system architecture is shown based on some aspects.

[0009] Figure 2 A block diagram of a communication device according to some embodiments is shown.

[0010] Figure 3 The process of UE status indication initiated by the UE based on some aspects is shown.

[0011] Figure 4 This illustrates the actions based on requests / responses from several aspects.

[0012] Figure 5This illustrates the allocation of services based on specific information from several aspects.

[0013] Figure 6 The process of updating UE configuration based on several aspects of transparent UE policy delivery is illustrated. Detailed Implementation

[0014] The following description and accompanying drawings fully illustrate specific embodiments to enable those skilled in the art to implement them. Other embodiments may incorporate structural, logical, electrical, process, and other variations. Parts and features of some embodiments may be included or substituted with parts and features of other embodiments. The embodiments set forth in the claims cover all available equivalents of those claims.

[0015] Figure 1A The network architecture is illustrated based on several aspects. Network 140A includes 3GPP LTE / 4G and NG network functions that can be extended to 6G capabilities. Therefore, although 5G will be mentioned, it should be understood that this will be able to be extended to 6G architecture, systems, and functions. Network functions can be implemented as discrete network elements on dedicated hardware, as software instances running on dedicated hardware, and / or as virtualized functions instantiated on an appropriate platform (e.g., dedicated hardware or cloud infrastructure).

[0016] Network 140A is shown as including user equipment (UE) 101 and UE 102. UE 101 and 102 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect 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 cordless phone, a drone, or any other computing device that includes wired and / or wireless communication interfaces. UE 101 and 102 may be collectively referred to herein as UE 101, and UE 101 may be used to perform one or more of the techniques disclosed herein.

[0017] Any radio link described herein (e.g., a radio link used in Network 140A or any other network shown) can operate according to any exemplary radio communication technology and / or standard. Any spectrum management scheme can be used, including, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (e.g., Licensed Shared Access (LSA) in 2.3–2.4 GHz, 3.4–3.6 GHz, 3.6–3.8 GHz and other frequencies, and Spectrum Access System (SAS) in 3.55–3.7 GHz and other frequencies). Different single-carrier or orthogonal frequency domain multiplexing (OFDM) modes (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multicarrier (FBMC), OFDMA, etc.), especially 3GPP NR, can be used by allocating OFDM carrier data bit vectors to corresponding symbol resources.

[0018] In some aspects, either UE 101 or 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 utilizing short-lived UE connections. In some aspects, either UE 101 or 102 may include a narrowband (NB) IoT UE (e.g., enhanced NB-IoT (eNB-IoT) UE and further enhanced (FeNB-IoT) UE). The IoT UE may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with an MTC server or device via a Public Land Mobile Network (PLMN), ProSe or Device-to-Device (D2D) communication, sensor network, or IoT network. M2M or MTC data exchange may be machine-initiated data exchange. The IoT network includes interconnected IoT UEs with short-lived connections (which may include uniquely identifiable embedded computing devices within the Internet infrastructure). The IoT UE may execute background applications (e.g., keep-alive messages, state updates, etc.) to facilitate connectivity within the IoT network. In some respects, either UE 101 or 102 may include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0019] UEs 101 and 102 can be configured to connect (e.g., communications coupled) to a radio access network (RAN) 110. RAN 110 can be, for example, an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN), a next-generation RAN (NGRAN), or some other type of RAN.

[0020] UEs 101 and 102 utilize connections 103 and 104 respectively, each connection including a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are shown as air interfaces for implementing communication coupling and can comply with cellular communication protocols such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, PTT protocol, PTT on Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, 5G protocol, 6G protocol, etc.

[0021] In one aspect, UEs 101 and 102 can also directly exchange communication data via ProSe interface 105. ProSe interface 105 may also be referred to as a sidelink (SL) interface, which includes one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), Physical Sidelink Broadcast Channel (PSBCH), and Physical Sidelink Feedback Channel (PSFCH).

[0022] UE 102 is shown configured to access access point (AP) 106 via connection 107. Connection 107 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, according to which AP 106 may include Wi-Fi. Router. In this example, AP 106 is shown connected to the Internet, but not to the core network of the wireless system (described in further detail below).

[0023] RAN 110 may include one or more access nodes that implement the connection between 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., a cell). In some aspects, communication nodes 111 and 112 may be transmit / receive points (TRPs). When communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may operate 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 femtocells or picocells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro cells).

[0024] Either RAN node 111 or 112 can terminate the air interface protocol and can be the first contact point for UEs 101 and 102. In some aspects, either RAN node 111 or 112 can implement various logical 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, data packet scheduling, and mobility management. In the example, either node 111 and / or 112 can be a gNB, eNB, or another type of RAN node.

[0025] RAN 110 is shown as being communicatively coupled to core network (CN) 120 via S1 interface 113. In various respects, 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 referenced). Figure 1B-1C (As shown). In this respect, the S1 interface 113 is divided into two parts: the S1-U interface 114, which carries service data between RAN nodes 111 and 112 and the serving gateway (S-GW) 122; and the S1-Mobility Management Entity (MME) interface 115, which is the signaling interface between RAN nodes 111 and 112 and the MME 121.

[0026] In this regard, CN 120 includes MME 121, S-GW 122, Packet Data Network (PDN) Gateway (P-GW) 123, and Home Subscriber Server (HSS) 124. MME 121 can functionally resemble the control plane of a Legacy Service General Packet Radio Service (GPRS) Support Node (SGSN). MME 121 can manage mobility aspects of access, such as gateway selection and tracking area list management. HSS 124 can include a database (including subscription-related information) for network users to support network entities in handling communication sessions. CN 120 can include one or more HSS 124s, depending on the number of mobile subscribers, equipment capacity, network organization, etc. For example, HSS 124 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc.

[0027] The S-GW 122 can terminate the S1 interface 113 toward RAN 110 and route data packets between RAN 110 and CN 120. Furthermore, the S-GW 122 can serve as a local mobility anchor for handover between RAN nodes and can also provide anchoring for inter-3GPP mobility. Other responsibilities of the S-GW 122 may include lawful interception, charging, and some policy enforcement.

[0028] P-GW 123 can terminate the SGi interface toward the PDN. P-GW 123 can route data packets between CN 120 and external networks (e.g., networks including application server 184 (alternately referred to as application function (AF)) via Internet Protocol (IP) interface 125. P-GW 123 can also pass data to other external networks 131A (which may include the Internet, IP Multimedia Subsystem (IPS) networks, and other networks). Typically, application server 184 can be an element that provides IP bearer resources for use with the core network (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.). In this respect, P-GW 123 is shown communicatively coupled to application server 184 via IP interface 125. Application server 184 can also be configured to support 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.

[0029] P-GW 123 can also be a node for policy enforcement and charging data collection. The Policy and Charging Rule Function (PCRF) 126 is the policy and charging control element of CN 120. In non-roaming scenarios, in some aspects, a single PCRF associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session may exist in the Home Public Land Mobile Network (HPLMN). In roaming scenarios where services are not local, two PCRFs associated with the UE's IP-CAN session may exist: the Home PCRF (H-PCRF) within the HPLMN and the Visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). PCRF 126 can be communicatively coupled to the application server 184 via P-GW 123.

[0030] In some aspects, the communication network 140A can be an IoT network or a 5G or 6G network, including 5G NR networks using licensed (5G NR) and unlicensed (5G NR-U) spectrum for communication. One current implementer of IoT is narrowband IoT (NB-IoT). Operation in unlicensed spectrum can include dual connectivity (DC) operation and a standalone LTE system in unlicensed spectrum (therefore, LTE-based technologies operate only in unlicensed spectrum without using “anchors” in licensed spectrum) (referred to as MulteFire). Further enhanced operation of LTE systems in licensed and unlicensed spectrum can be expected in future versions and 5G systems. Such enhanced operation can include technologies for sidelink resource allocation and UE processing behavior for NR sidelink V2X communication.

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

[0032] In some aspects, the NG system architecture can use reference points between nodes. In some aspects, each of the gNB and NG-eNB can be implemented as a base station, mobile edge server, small cell, home eNB, etc. In some aspects, the gNB can be the master node (MN) in a 5G architecture, while the NG-eNB can be a secondary node (SN).

[0033] Figure 1B The non-roaming 5G system architecture is illustrated based on several aspects. Specifically, Figure 1B The 5G system architecture 140B is illustrated with reference points and can be extended to a 6G system architecture. More specifically, UE 102 can communicate with RAN 110 and one or more other 5GC network entities. The 5G system architecture 140B includes multiple network functions (NFs), such as AMF 132, 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.

[0034] UPF 134 can provide connectivity to data network (DN) 152, which may include, for example, operator services, internet access, or third-party services. AMF 132 can be used to manage access control and mobility, and may also include network slice selection functionality. AMF 132 can provide UE-based authentication, authorization, mobility management, etc., and can be independent of the access technology. SMF 136 can be configured to establish and manage various sessions according to network policies. Therefore, SMF 136 can be responsible for session management and IP address allocation to the UE. SMF 136 can also select and control UPF 134 for data transmission. SMF 136 can be associated with a single session of UE 101 or multiple sessions of UE 101. That is, UE 101 can have multiple 5G sessions. Different SMFs can be assigned to each session. Using different SMFs allows for individual management of each session. Therefore, the functionality of each session can be independent of each other.

[0035] UPF 134 can be deployed in one or more configurations according to the desired service type and can connect to a data network. PCF 148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to PCRF in 4G communication systems). UDM can be configured to store subscriber profiles and data (similar to HSS in 4G communication systems).

[0036] AF 150 can provide information about packet flows to PCF 148, which is responsible for policy control, to support desired QoS. PCF 148 can set mobility and session management policies for UE 101. To this end, PCF 148 can use packet flow information to determine appropriate policies for appropriate operations of AMF 132 and SMF136. AUSF 144 can store data used for UE authentication.

[0037] In some aspects, the 5G system architecture 140B includes an IP Multimedia Subsystem (IMS) 168B and multiple IP Multimedia Core Network Subsystem entities (e.g., Call Session Control Function (CSCF)). More specifically, the IMS 168B includes a CSCF that can act as a proxy CSCF (P-CSCF) 162B, a serving CSCF (S-CSCF) 164B, and an emergency CSCF (E-CSCF). Figure 1B(Not shown in the image) or query the CSCF (I-CSCF) 166B. The P-CSCF 162B can be configured as the first contact point for UE 102 within the IM subsystem (IMS) 168B. The S-CSCF 164B can be configured to handle session states in the network, and the E-CSCF can be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. The I-CSCF 166B can be configured as the contact point within the operator's network for all IMS connections to subscribers whose destination is that network operator or roaming subscribers currently located within that network operator's service area. In some aspects, the I-CSCF 166B can connect to another IP multimedia network 170E, such as an IMS operated by a different network operator.

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

[0039] Reference points indicate that interaction is possible between corresponding NF services. For example, Figure 1B The following reference points are shown: N1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF 148, not shown), N8 (between UDM 146 and AMF 132, not shown), N9 (between the 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 AMF 132, not shown). N14 (between PCF 144 and UDM 146, not shown), N14 (between the two AMF 132s, not shown), N15 (between PCF 148 and AMF 132 in non-roaming scenarios, or between PCF 148 and the visited network and AMF 132 in roaming scenarios, not shown), N16 (between the two SMFs, not shown), and N22 (between AMF 132 and NSSF 142, not shown). Alternatively, you can use... Figure 1B Other reference points not shown in the text are indicated.

[0040] Figure 1C The 5G system architecture 140C and its service-based representation are shown. In addition... Figure 1B In addition to the network entities shown, system architecture 140C may also include Network Open Function (NEF) 154 and Network Repository Function (NRF) 156. In some aspects, the 5G system architecture may be service-based, and the interaction between network functions may be represented by corresponding point-to-point reference points Ni, or represented as service-based interfaces.

[0041] In some aspects, such as Figure 1C As shown, service-based representation can be used to represent network functions within the control plane that enable other authorized 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), Npcf 158D (service-based interface shown by PCF 148), Nudm 158E (service-based interface shown by UDM 146), Naf 158F (service-based interface shown by AF150), Nnrf 158C (service-based interface shown by NRF 156), Nnssf 158A (service-based interface shown by NSSF 142), and Nausf 158G (service-based interface shown by AUSF 144). Alternatively, it can also use... Figure 1C Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf).

[0042] The NR-V2X architecture can support highly reliable, low-latency sidelink communication with various service patterns, including periodic and aperiodic communication with random packet arrival times and sizes. The techniques disclosed herein can be used to support high reliability in distributed communication systems with dynamic topologies, including sidelink NR V2X communication systems.

[0043] Figure 2 A block diagram of a communication device according to some embodiments is shown. Communication device 200 may be a UE, such as a dedicated computer, personal or laptop computer (PC), tablet PC or smartphone, dedicated network device (e.g., eNB), server running software to configure a server to operate as a network device, virtual device, or any machine capable of (sequentially or otherwise) executing instructions specifying actions to be taken by that machine. For example, communication device 200 may be implemented as... Figure 1A-1COne or more devices are shown. Note that the communications described herein may be encoded before being transmitted by a sending entity (e.g., UE, gNB) for reception by a receiving entity (e.g., gNB, UE) and decoded by the receiving entity after reception.

[0044] The examples described herein may include logic or components, modules, or mechanisms, or on which operations may be performed. Modules and components are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain way. In the examples, circuitry may be arranged as a module in a specified manner (e.g., internally, or relative to external entities (e.g., other circuitry)). In the examples, all or part of one or more computer systems (e.g., standalone, 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) to operate to perform specified operations. In the examples, the software may reside on a machine-readable medium. In the examples, the software causes the hardware to perform the specified operations when executed by the underlying hardware of the module.

[0045] Therefore, the terms "module" (and "component") are understood to encompass tangible entities, whether physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transiently) configured (e.g., programmed) to operate or perform any of the operations described herein in a specified manner. Consider the example of a module being temporarily configured, where each module does not need to be instantiated at any given time. For example, in the case where a module comprises a general-purpose hardware processor configured using software, the general-purpose hardware processor can be configured as different modules at different times. Thus, software can configure the hardware processor, for example, to constitute a specific module at one time instance and different modules at different time instances.

[0046] Communication device 200 may include a hardware processor (or equivalent, processing circuitry) 202 (e.g., a central processing unit (CPU), GPU, hardware processor core, or any combination thereof), main memory 204, and static memory 206, some or all of which may communicate with each other via an interconnect (e.g., a bus) 208. Main memory 204 may contain any or all removable and non-removable memory, volatile or non-volatile memory. 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 this example, display unit 210, input device 212, and UI navigation device 214 may be a touchscreen display. Communication device 200 may also 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 GPS sensor, a compass, an accelerometer, or other sensors). The communication device 200 may also include an output controller, such as a serial connection (e.g., Universal Serial Bus (USB)), a 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., printers, card readers, etc.).

[0047] Storage device 216 may include a non-transitory machine-readable medium 222 (hereinafter referred to as machine-readable medium) on which one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more technologies or functions described herein may be stored. Instructions 224 may also reside wholly or at least partially within main memory 204, static memory 206, and / or hardware processor 202 during execution by communication device 200. While machine-readable medium 222 is shown as 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 one or more instructions 224.

[0048] The term "machine-readable medium" can include any medium capable of storing, encoding, or carrying instructions executed by the communication device 200 and causing the communication device 200 to perform any one or more technologies of this disclosure, or any medium capable of storing, encoding, or carrying data structures used by or associated with those instructions. Examples of non-limiting machine-readable media can include solid-state memory as well as optical and magnetic media. Specific examples of machine-readable media can include: non-volatile 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 internal hard disks and removable disks; magneto-optical disks; random access memory (RAM); and CD-ROM and DVD-ROM disks.

[0049] Instruction 224 can also utilize any of a variety of wireless local area network (WLAN) transport protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.) to send or receive over a communication network via network interface device 220 using transmission medium 226. Example communication networks may include local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), mobile phone networks (e.g., cellular networks), common-use telephone (POTS) networks, and wireless data networks. Communication over the network may include one or more different protocols, such as the IEEE 802.11 series of standards (known as Wi-Fi), the IEEE 802.16 series of standards (known as WiMax), the IEEE 802.15.4 series of standards, the Long Term Evolution (LTE) series of standards, the Universal Mobile Telecommunications System (UMTS) series of standards, point-to-point (P2P) networks, next-generation (NG) / fifth-generation (5G) standards, etc. In the example, network interface device 220 may include one or more physical jacks (e.g., Ethernet jack, coaxial jack, or telephone jack) or one or more antennas to connect to transmission medium 226.

[0050] Note that the term "circuit" as used herein refers to, is part of, or includes, the following hardware components: such as electronic circuits, logic circuits, processors (shared, dedicated, or grouped) and / or memories (shared, dedicated, or grouped), application-specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or programmable SoCs), digital signal processors (DSPs), etc., configured to provide the described functions. In some embodiments, a circuit may execute one or more software or firmware programs to provide at least some of the described functions. The term "circuit" may also refer to a combination of one or more hardware elements and program code (or a combination of circuitry and program code used in an electrical or electronic system), wherein one or more hardware elements are used to perform the functions of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit.

[0051] Therefore, as used herein, the term "processor circuit" or "processor" refers to, or includes, a circuit 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-core 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).

[0052] Any radio link described herein may operate according to 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 communication technology, General Packet Radio Service (GPRS) radio communication technology, Enhanced Data Rate GSM Evolution (EDGE) radio communication technology, and / or 3rd Generation Partnership Project (3GPP) radio communication technologies, such as Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), and 3GPP Advanced Long Term Evolution (LTE). Advanced, Code Division Multiple Access 2000 (CDMA2000), Cellular Digital Packet Data (CDPD), Mobitex, 3rd Generation (3G), Circuit Switched Data (CSD), High-Speed ​​Circuit Switched Data (HSCSD), Universal Mobile Telecommunications System (3G) (UMTS(3G)), Wideband Code Division Multiple Access (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), 3GPP Rel.8 (Pre-4th Generation), 3GPP Rel.9 (3GPP Rel.9), 3GPP Rel.10 (3GPP Rel.10), 3GPP Rel.11 (3rd Generation Partner Program Version 11), 3GPP Rel.12 (3rd Generation Partner Program Version 12), 3GPP Rel.13 (3rd Generation Partner Program Version 13), 3GPP Rel.14 (3rd Generation Partner Program Version 14), 3GPP Rel.15 (3rd Generation Partner Program Version 15), 3GPP Rel.16 (3rd Generation Partner Program Version 16), 3GPP Rel.17 (3rd Generation Partner Program Version 17) and subsequent versions (e.g., Rel.18, Rel.17).19, etc.), 3GPP 5G, 5G, 5G New Radio (5G NR), 3GPP 5G New Radio, 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 (4th Generation) (LTE Advanced (4G)), cdmaOne (2G), Code Division Multiple Access 2000 (3rd Generation) (CDMA2000 (3G)), Evolved Data Optimized or Evolved Data Only (EV-DO), Advanced Mobile Telephone Systems (1st Generation) (AMPS (1G)), Total Access Communication System / Extended Total Access Communication System (TACS / ETACS), Digital AMPS (2nd Generation) (D-AMPS (2G)), Push-to-Talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), OLT (Norwegian: Offentlig Landmobil) Telefoni (public land mobile phone), MTD (Swedish abbreviation Mobiltelefonisystem D, or mobile phone system D), public automatic land mobile phone (Autotel / PALM), ARP (Finnish Autoradiopuhelin, "vehicle radio phone"), NMT (Nordic mobile phone), NTT (Japan Telegraph and Telephone) high-capacity version (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handheld Telephone System (PHS), Broadband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA) (also known as 3GPP Universal Access Network or GAN standard), Zigbee, Bluetooth, Wireless Gigabit Alliance (WiGig) standard, Universal mmWave standard (wireless systems operating at 10-300GHz and above, such as WiGig, IEEE 802.11ad, IEEE Technologies that operate in frequency bands above 300 GHz and THz (based on 3GPP / LTE or IEEE 802.11p or IEEE 802.11).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 5850MHz to 5925MHz or higher (typically up to 5935MHz as recommended in CEPT Report 71), European ITS-G5 systems (i.e., based on IEEE) European-style DSRC based on 802.11p includes ITS-G5A (i.e., operation of ITS-G5 in European ITS bands dedicated to security-related applications in the frequency range of 5,875 GHz to 5,905 GHz), ITS-G5B (i.e., operation of ITS in European ITS bands dedicated to non-security applications in the frequency range of 5,855 GHz to 5,875 GHz), ITS-G5C (i.e., operation of ITS applications in the frequency range of 5,470 GHz to 5,725 GHz), Japanese DSRC in the 700 MHz band (including 715 MHz to 725 MHz), and systems based on IEEE 802.11bd, etc.

[0053] The aspects described herein can be used in the context of any spectrum management scheme, including dedicated licensed spectrum, unlicensed spectrum, license-exempt spectrum, and (licensed) shared spectrum (e.g., LSA = Licensed Shared Access in 2.3-2.4 GHz, 3.4-3.6 GHz, 3.6-3.8 GHz and beyond, and SAS = Spectrum Access System / CBRS = Citizen Broadband Radio System in 3.55-3.7 GHz and beyond). Applicable frequency bands include IMT (International Mobile Telecommunications) spectrum and other types of spectrum / bands, such as those with nationally allocated bands (including 450-470 MHz, 902-928 MHz (note: e.g., allocated in the US (FCC Part 15)), 863-868.6 MHz (note: e.g., allocated in the EU (ETSI EN 300)). 220), 915.9-929.7MHz (Note: e.g., allocated in Japan), 917-923.5MHz (Note: e.g., allocated in South 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: This is a globally available ISM band and is used by the Wi-Fi technology family (11b / g)). / n / ax) and also used by Bluetooth), 2500-2690MHz, 698-790MHz, 610-790MHz, 3400-3600MHz, 3400-3800MHz, 3800-4200MHz, 3.55-3.7GHz (Note: for example, allocated to civilian broadband radio services in the United States), 5.15-5.25GHz and 5.25-5.35GHz and 5.47-5.725GHz and 5.725-5.85GHz bands (Note: for example, allocated to the United States (FCC) Part 15, consisting of four U-NII bands totaling 500MHz of spectrum: 5.725-5.875GHz (Note: e.g., allocated in the EU (ETSI EN301 893)), 5.47-5.65GHz (Note: e.g., allocated in South Korea), 5925-7125MHz, and 5925-6425MHz (Note: under consideration in the US and EU respectively). Next-generation Wi-Fi systems are expected to include 6GHz spectrum as an operating band; however, note that as of December 2017, Wi-Fi systems were not permitted in this band.The regulations are expected to be completed within the 2019-2020 timeframe, including IMT-advanced spectrum, IMT-2020 spectrum (expected to include the 3600-3800MHz, 3800-4200MHz, 3.5GHz band, 700MHz band, and bands in the 24.25-86GHz range), and spectrum available under the FCC's "Spectrum Frontier" 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, and 71-76GHz). The ITS (Intelligent Transportation Systems) bands, including 81-86GHz and 92-94GHz, 5.9GHz (typically 5.85-5.925GHz) and 63-64GHz, the bands currently allocated to WiGig (e.g., WiGig band 1 (57.24-59.40GHz), WiGig band 2 (59.40-61.56GHz), WiGig band 3 (61.56-63.72GHz) and WiGig band 4 (63.72-65.88GHz)), and 57-64 / 66GHz (Note: This band is almost globally designated for Multi-Gigabit Wireless Systems (MGWS) / WiGig). In the US (FCC Part 15), a total of 14 GHz of spectrum has been allocated, while in the EU (ETSI EN 302 567 and ETSI EN 301 217-2 (for fixed P2P)), a total of 9 GHz of spectrum has been allocated. Other available bands include the 70.2 GHz-71 GHz band, any band between 65.88 GHz and 71 GHz, bands currently allocated for automotive radar applications (e.g., 76-81 GHz), and future bands (including 94-300 GHz and above). Furthermore, this scheme can be used supplementarily in bands such as TV whitespace (typically below 790 MHz) (of which, in particular, the 400 MHz and 700 MHz bands are promising candidates). Beyond cellular applications, specific applications targeting vertical markets can also be addressed, such as PMSE (program production and special events), medical, health, surgical, automotive, low latency, and drone applications.

[0054] The aspects described in this article can also enable the layered application of the scheme. For example, by prioritizing access to the spectrum, a layered priority system (e.g., low / medium / high priority) can be introduced for different types of users. For example, the highest priority is given to Tier 1 users, followed by Tier 2 users, then Tier 3 users, and so on.

[0055] The aspects described in this article can also be applied to different single-carrier or OFDM styles (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multicarrier (FBMC), OFDMA, etc.), especially 3GPP NR (New Radio), by assigning OFDM carrier data bit vectors to corresponding symbol resources.

[0056] Some features in this document are defined for the network side, such as AP, eNB, NR, or gNB—note that this term is typically used in the context of 3GPP fifth-generation (5G) communication systems, etc. However, the UE can also play this role, acting as an AP, eNB, or gNB; that is, some or all of the features defined for network devices can be implemented by the UE.

[0057] Network slicing has been supported since 3GPP Release 15. However, network slices for a UE are disjoint within a single operator's network. UEs lack information on user preferences and active applications when accessing network slices, leading to unwanted latency and a degraded service experience. Considering enhanced access and support for network slicing, Use Case 7 – Slice Access with Application Preferences – in 3GPP TR 22.835 Clause 5.7 can be considered for application strategies related to network slicing, but service requirements have not yet been agreed upon. Note that 3GPP TS 22.261, TS 23.502, TR 22.835 – Research on Enhanced Access and Support for Network Slicing, TS 22.011, and TS 24.501 are discussed and incorporated herein by reference.

[0058] Based on the service requirements for network slicing in 3GPP TS 22.261 and the solutions for network slicing in 3GPP TS 23.501, 5G networks can assign a list of allowed network slices to a UE based on the UE's subscription, UE capabilities, the access technology used by the UE, the operator's policies, and the services provided by the network slice. The following issues remain unresolved:

[0059] Question 1: During registration, the 5G network (gNB) provides the UE with an "operator-defined access category." The gNB provides the UE with a potential association between the AppID and a single network slice selection assistance information (S-NSSAI) to establish a Packet Data Unit (PDU) session with the allowed S-NSSAI when an application identified from the AppID receives an upper-layer request. However, the method by which the network appropriately assigns network slices to applications remains unclear. Note that S-NSSAI uses Slice / Service Type (SST) and Slice Distinguisor (SD) to identify network slices. The SST refers to the expected network slice behavior in terms of characteristics and services, and the SD supplements the SST to distinguish multiple network slices of the same SST.

[0060] Question 2: It is unclear how the UE can select the appropriate network slice for third-party applications. The third party may have service level agreements (SLAs) with different network operators and a preferred public terrestrial mobile network (PLMN) for its application. In other words, the third-party service provider may provide its users with a separate sponsored connection in the preferred PLMN.

[0061] Question 3: The way the UE prioritizes the use of network slices for different applications is unclear. For example, the priority between application 1 (which needs to use network slice 1 but cannot use network slice 2) and application 2 (which needs 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 needs to use network slice 1 but is not supported in the serving PLMN), a mechanism needs to be added for the UE to determine whether to continue reselecting to a new PLMN that supports application 1.

[0062] 3GPP TS 24.501 describes operator-defined access categories to provide access category information associated with S-NSSAI, Data Network Name (DNN), and OSId+OS App ID. The OSId is sent in the UE STATEINDICATION message during the registration process.

[0063] 4.5.3 Access categories defined by operators

[0064] Non-Access Stratum (NAS) signaling can be used to signal operator-defined access category definitions to the UE. Each operator-defined access category definition includes the following parameters: a priority value, indicating the order in which the UE should evaluate operator-defined access category definitions for matching; an operator-defined access category number, i.e., an access category number in the range of 32-63, which uniquely identifies the PLMN or the access category in which the access category is sent to the UE; and a criterion including one or more access category criterion types and associated access category criterion type values. Access category criterion types can be set to: DNN, 5G Quality of Service (QoS) Identifier (5QI), OS Id+OS App Id of the application that triggered the access attempt, or S-NSSAI. An access category criterion type can be associated with more than one access category criterion value. If an access attempt matches all access category criterion types included in the criterion with any associated access category criterion value, then the access attempt matches the operator-defined access category definition's criterion. Each operator-defined access category definition has a different priority value. Several operator-defined access category definitions can have the same operator-defined access category number.

[0065] Figure 3 The diagram illustrates a UE status indication procedure initiated by the UE based on several aspects. As shown, the UE sends a UE status indication message using the registration procedure. During the UE status indication procedure initiated by the UE and accepted by the network, upon receiving the UE status indication message, the PCF operates as described in 3GPP TS 23.502 and 3GPP TS 29.525.

[0066] The UE Status Indication message is sent by the UE to the PCF. The UE Status Indication message transmits the UE Policy Part Identifier (UPSI) stored in the UE Policy Part, indicates whether the UE supports the Access Network Discovery and Selection Policy (ANDSP), and transmits one or more OS IDs of the UE.

[0067] Table D.5.4.1.1: UE Status Indication Message Content

[0068]

[0069] Figure 4 This illustrates the actions based on requests / responses from several aspects. Figure 4 The NEF service operation information flow is illustrated, in which, at operation 0, the NF subscribes to the UE and / or group subscription data update UDM notification. The NF can subscribe to data from the UDM subscription group in this step and, using the shared data features defined in TS 29.503, is notified of the group subscription data update in step 7.

[0070] At Operation 0b (conditional on the use of Network Data Analysis Function (NWDAF) auxiliary value), the AF can subscribe to the NWDAF via the NEF to learn UE mobility analysis and / or UE communication analysis for a UE or a group of UEs by applying the procedures specified in Clause 6.1.1.2 of TS 23.288. The analysis ID is set to any value specified in Clause 6.7.1 of TS 23.288.

[0071] At operation 0c (which is conditional on using NWDAF auxiliary values), the AF verifies the received data and derives any expected UE behavior parameters defined in Clause 4.15.6.3 of TS 23.502 for a UE or a group of UEs.

[0072] At operation 1, the AF provides the NEF with one or more parameters to be created or updated in the Nnef_ParameterProvision_Create, Nnef_ParameterProvision_Update, or Nnef_ParameterProvision_Delete request. The Common Public Subscription Identifier (GPSI) identifies the UE, and the Transaction Reference ID identifies the transaction request between the NEF and AF. In the case of Nnef_ParameterProvision_Create, the NEF assigns the Transaction Reference ID to the Nnef_ParameterProvision_Create request.

[0073] NEF checks whether the requester is permitted to perform the requested service operation by examining the requester's identifier (i.e., AF ID). For creation requests 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: expected UE behavior parameters (see TS 23.502 Clause 4.15.6.3), network configuration parameters (see TS 23.502 Clause 4.15.6.3a), External Group ID and 5G VN group data (i.e., 5G-VN configuration parameters) (see TS 23.502 Clause 4.15.6.3b), 5G VN group membership management parameters (see TS 23.502 Clause 4.15.6.3c), or location privacy indication parameters for a subset of the "LCS privacy" data of the subscription data (see TS 23.502 Clause 5.2.3.3.1 and TS 23.273 Clause 7.1). AF can request the deletion of the 5G VN configuration by sending Nnef_ParameterProvision_Delete to NEF.

[0074] At Operation 2, if the NEF authorizes the AF to assign parameters, the NEF requests the creation, updating, storage, or deletion of the assigned parameters as part of the subscriber data via the Nudm_ParameterProvision_Create, Nudm_ParameterProvision_Update, or Nudm_ParameterProvision_Delete request message. This message includes the assigned data and the NEF reference ID. If the AF is not authorized to assign these parameters, the NEF proceeds to Operation 6, indicating the reason for the failure in the Nnef_ParameterProvision_Create / Update / Delete response message. Operation 7 does not apply to this situation. For non-roaming scenarios where UDM authorization or authentication is not required, if the request is not associated with a 5G VN group, the NEF can directly forward the external parameters to the UDR via the Nudr_DM_Update request message. In this case, the UDR responds to the NEF via the Nudr_DM_Update response message.

[0075] At operation 3, the UDM can read the corresponding subscription information from the UDR through Nudr_DM_Query in order to verify data updates and authorize these changes for the subscriber or the group used for the corresponding AF.

[0076] At operation 4, if UDM authorizes AF to assign parameters to the subscriber, UDM resolves GPSI to SUPI and requests the creation, update or deletion of the assigned parameters as part of the subscriber data via Nudr_DM_Create / Update / Delete request message, which includes the assigned data.

[0077] If a new 5G VN group is created, the UDM assigns a unique internal group ID to 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 using the Nudr_DM_Create / Update / Delete response message.

[0078] When 5G VN group data is updated (as described in Clause 4.15.6.3b of TS 23.502), the UDR notifies the subscribed PCF by sending Nudr_DM_Notify as defined in Clause 4.16.12.2 of TS 23.502.

[0079] If AF is not authorized to be assigned parameters, UDM continues with operation 5, indicating the reason for the failure in the Nudm_ParameterProvision_Update response message, and does not perform operation 7.

[0080] The UDM categorizes received parameters (i.e., expected UE behavior parameters, network configuration parameters, 5G VN configuration parameters, or location privacy indication parameters) into AMF-associated parameters and SMF-associated parameters. The UDM can use the AF ID received from the NEF in Operation 2 to associate the received parameters with the specific subscribed DNN and / or S-NSSAI. The UDM stores the SMF-associated parameters under the corresponding session management subscription data type.

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

[0082] At operation 5, UDM responds to the request with a Nudm_ParameterProvision_Create / Update / Delete response. If the procedure fails, the reason value indicates the cause.

[0083] At operation 6, NEF responds to the request with an Nnef_ParameterProvision_Create / Update / Delete response. If the procedure fails, the reason value indicates the cause.

[0084] At operation 7 (which is conditional and occurs only after operation 4 is successful), the UDM notifies the subscribed network function (e.g., AMF) of the updated UE and / or group subscription data via the Nudm_SDM_Notification notification message.

[0085] a) If the NF is an AMF, the UDM performs the Nudm_SDM_Notification (SUPI or internal group identifier, AMF association parameters, etc.) service operation. The AMF identifies whether there are overlapping parameter sets in the expected UE behavior and merges the parameter sets. The AMF uses the received AMF association parameters to derive the appropriate UE configuration for the NAS parameters and derives the core network auxiliary RAN parameters. The AMF can determine the registration area based on the parameters Stationary indication or Expected UE Moving Trajectory.

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

[0087] SMF stores the received SMF association parameters and associates them with the PDU session based on the DNN and S-NSSAI included in the message from UDM. SMF identifies whether there are overlapping parameter sets in the expected UE behavior and merges these sets. SMF can use SMF association parameters as follows:

[0088] SMF configures UPF accordingly. SMF can use the Scheduled Communication Type parameter or the Suggested Number of Downlink Packets parameter to configure how many downlink packets the UPF should buffer. SMF can use the Communication duration time parameter to determine when to disable user plane (UP) connections and perform core network (CN)-initiated selective disabling of UP connections for existing PDU sessions.

[0089] The SMF can export CN auxiliary RAN information for use in PDU sessions. The SMF provides this CN auxiliary RAN information to the AMF, as described during the PDU session establishment or modification process. The NEF or UDM can also update the corresponding UDR data as appropriate via the Nudr_DM_Create / Delete service operation.

[0090] The AF request sent to NEF contains the following information:

[0091] 1) Service Description. A service description is information used to identify the service to which service parameters are applied. The service description in an AF request can be represented by a combination of DNN and S-NSSAI, an AF service identifier, or an application identifier.

[0092] 2) Service parameters. Service parameters are service-specific information that is assigned to and passed to the UE in the network to support the services identified by the service description.

[0093] 3) Target UE or group of UEs. The target UE or group of UEs indicates the UE to which the service parameters are to be passed. Each UE can be identified by its GPSI, IP address / prefix, or MAC address. UE groups can be identified by the external group identifier defined in TS 23.682. If no identifier for the target UE or group of UEs is provided, the service parameters are passed to any UE that uses the service description to identify the service.

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

[0095] Figure 5 This illustrates allocation based on service-specific information from several aspects. AF uses Figure 5 The Nnef_ServiceParameter service shown provides service-specific parameters to the PLMN and UE.

[0096] At operation 1, to create a new request, the AF invokes the Nnef_ServiceParameter_Create service operation. To update or remove an existing request, the AF invokes the Nnef_ServiceParameter_Update or Nnef_ServiceParameter_Delete service operation along with the corresponding transaction reference ID, which is provided to the AF in the Nnef_ServiceParameter_Create response message. The content of this service operation (AF request) includes the information described in Clause 5.2.6.11 of TS23.502.

[0097] At operation 2, the AF sends its request to the NEF. The NEF authorizes the AF request. The NEF performs the following mappings: mapping the AF service identifier to the DNN and S-NSSAI combination determined by the local configuration; mapping the GPSI in the target UE identifier to the SUPI based on the information received from the UDM; and mapping the external group identifier in the target UE identifier to the internal group identifier based on the information received from the UDM. For the Nnef_ServiceParameter_Create service operation, the NEF dispatches the transaction reference ID to the Nnef_ServiceParameter_Create request.

[0098] At operation 3, for the Nnef_ServiceParameter_Create or Update service operation, NEF stores the AF request information as "application data" (a subset of the data set for "service-specific information") in the UDR along with the assigned transaction reference ID. For the Nnef_ServiceParameter_delete service operation, NEF removes the AF request information from the UDR.

[0099] At operation 4, the NEF responds to the AF. The Nnef_ServiceParameter_Create response message includes the assigned transaction reference ID. If the UE is registered to the network, and the PCF subscribes to notifications of data modifications in the UDR by calling Nudr_DM_Subscribe(AF service parameter allocation information, SUPI, dataset settings for "Application Data", data subset settings for "Service Specific Information") at operation 0, the following actions are performed:

[0100] At operation 5, the PCF receives a Nudr_DM_Notify notification of data changes from the UDR. The PCF does not need to subscribe to application-specific information for each UE (e.g., if the PCF has already received application-specific information for a group of UEs or for the DNN through subscriptions from other UEs). The same application-specific information is passed to each UE in the group or DNN.

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

[0102] When the PCF wants to update the UE policy information (i.e., UE policy) in the UE configuration, it initiates a UE configuration update process for transparent UE policy transmission. In non-roaming scenarios, the V-PCF is not involved, and the role of the H-PCF is performed by the PCF. In roaming scenarios, the V-PCF interacts with the AMF, and the H-PCF interacts with the V-PCF.

[0103] Figure 6 This illustrates the UE configuration update process based on several aspects of transparent UE policy delivery. Figure 6 In operation 0, the PCF determines to update the UE policy based on triggering conditions (e.g., initial registration, registration to 5GS when the UE moves from EPS, or to update the UE policy), as follows:

[0104] For initial registration and registration to 5GS when the UE moves from EPS, the PCF compares the list of PSIs included in the UE policy information in the Npcf_UEPolicyControl_Create request and, as described in Clause 6.1.2.2.2 of TS 23.503, determines whether the UE policy information should be updated and provides it to the UE via the AMF using a DL NAS TRANSPORT message. For network-triggered UE policy updates (e.g., changes in UE location, changes in subscribed S-NSSAI, as described in Clause 6.1.2.2.2 of TS 23.503), the PCF checks the latest PSI list to determine which UE policies to send to the UE.

[0105] The PCF checks whether the size of the obtained UE policy information exceeds a predefined limit. If the size is within the limit, the UE policy information is included in a single Namf_Communication_N1N2MessageTransfer service 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 messages, ensuring that the size of each message is within the predefined limit. Each UE policy information message is then sent in a separate Namf_Communication_N1N2MessageTransfer service operation, as described below.

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

[0107] At operation 1, the PCF invokes the Namf_Communication_N1N2MessageTransfer service provided by the AMF. This message includes SUPI and the UE policy container.

[0108] At Operation 2, if the UE is registered in either a 3GPP or non-3GPP access and is reachable by the AMF, 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 transmits the UE policy container to the UE via one of the accesses based on its local AMF policy. If the AMF is unreachable by the UE on both 3GPP and non-3GPP accesses, the AMF reports to the PCF using Namf_Communication_N1N2TransferFailureNotification that it cannot transmit the UE policy container to the UE, as in Operation 5 of Clause 4.2.3.3 of TS 23.502.

[0109] If the AMF decides to transparently transmit the UE policy container to the UE via 3GPP access (e.g., the UE is registered only in 3GPP access and the AMF can reach the UE), or if the UE is registered in both 3GPP and non-3GPP access served by the same AMF and the AMF can reach the UE, and the AMF decides to transparently transmit the UE policy container to the UE via 3GPP access based on its local policy, and the UE is in CM-IDLE and the AMF can reach the UE in 3GPP access, then the AMF initiates a paging procedure by sending a paging message as described in Operation 4b of the Network-Triggered Service Request (in Clause 4.2.3.3 of TS 23.502). Upon receiving the paging request, the UE initiates a UE-Triggered Service Request procedure (Clause 4.2.3.2 of TS 23.502).

[0110] At Operation 3, if the UE is in CM-CONNECTED mode on 3GPP access or non-3GPP access, the AMF will transparently transmit the UE policy container (UE policy information) received from the PCF to the UE. The UE policy container includes a list of policy portions as described in TS 23.503.

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

[0112] At operation 5, if the AMF receives the UE policy container and the PCF has subscribed to receiving the notified UE policy container, the AMF forwards the UE's response to the PCF using the Namf_Communication_N1MessageNotify service operation. The PCF maintains the latest PSI list passed to the UE and updates the latest PSI list in the UDR by calling the Nudr_DM_Update(SUPI, policy data, policy set entry, updated PSI data) service operation. If the PCF notifies the UE of policy delivery failure, the PCF may initiate a UE policy association modification procedure to provide the AMF with a new trigger "connection state change" in the policy control request trigger for UE policy association, as defined in Clause 4.16.12.2 of 23.502.

[0113] For backward compatibility, PCF can subscribe to the "Connection State Change (IDLE or CONNECTED)" event in Rel-15 AMF, as defined in Clause 5.2.2.3 of 23.502.

[0114] SoR list related TS: TS 22.011 sub-clause 3.2.2.8, TS 22.261 sub-clauses 6.30 (for SoR) and 6.1 (for network slicing), TS 23.122—The purpose of the control plane solution for roaming guidance during 5GS is to allow the HPLMN to update the “Operator-Controlled PLMN Selector and Access Technology” list in the UE by providing an HPLMN protection list of preferred PLMN / access technology combinations via NAS signaling, TS 24.501: SoR list PLMN ID and access technology identifier are provided in descending order of priority, i.e., PLMN ID 1 indicates the highest priority and PLMN ID n indicates the lowest priority.

[0115] Based on the association between the application and the applicable network slices in the same or different PLMNs, various solutions can be used to address three outstanding issues. Solution 1: New service requirements. Solution 2: AF requests can be used for application classification PCF inference and specific parameter updates via the UE policy configuration update process for application policies. Solutions 3 and 4: AF requests for specific parameter updates via the UE policy configuration update process for applying specific roaming guidance policies (which take precedence over roaming guidance policies provided by the HPLMN). Solution 5: User preference settings for the application that can be used before triggering PLMN changes for the application's network slices.

[0116] S-NSSAI can have a standard value (i.e., such S-NSSAI may contain only SSTs with normalized SST values, see Clause 5.15.2.2, and no SD) or a non-standard value (i.e., such S-NSSAI may contain both SSTs and SDs, or only SSTs without normalized SST values ​​and no SDs). S-NSSAIs with non-standard values ​​identify a single network slice within the PLMN associated with the S-NSSAI. S-NSSAIs with non-standard values ​​are not used by the UE in access stratum procedures in any PLMN other than the PLMN associated with the S-NSSAI.

[0117] Based on TS23.501, Clause 5.15.2.2: Standardized SST Values: Standardized SST values ​​provide a way to establish global interoperability for slices, enabling PLMNs to more efficiently support roaming use cases for the most commonly used SSTs. Table 5.15.2.2-1 below provides the standardized SSTs.

[0118] Table 5.15.2.2-1 - Standardized SST Values

[0119] Slice / Service Type SST value characteristic eMBB 1 Slicing is suitable for processing 5G enhanced mobile broadband. URLLC 2 Slicing is suitable for handling ultra-reliable low-latency communication. MIoT 3 Slicing is suitable for handling large-scale IoT. V2X 4 Slices are suitable for processing V2X services.

[0120] The solution to the above problem is applicable to and can be extended to the standardized SST values ​​defined in future versions.

[0121] Solution 1: New Service Requirements. The first service requirement is that the 5G network provide a mechanism for third parties to provide network slice-related information (e.g., priority, QoS level, network slice type, etc.) to their application users, so that the network can configure appropriate network slices and application associations for the UE. The second service requirement is that the 5G network provide a mechanism for configuring network slice configurations for the UE associated with a list of preferred network operators for the application. This network slice configuration is considered for sponsor connections and takes precedence over the roaming control (SoR) policy provided by the HPLMN. The third service requirement is that the 5G system allows the UE to store user preferences for applications in a priority order, which is used to determine whether to move to a preferred network when different applications are activated and using different network slices in different networks.

[0122] Solution 2: PCF inference for application classification and AF requests updated with specific parameters via the UE policy configuration update procedure for application policy. This supports allocation to applications based on the following procedures. Figure 4 The AF request for the associated parameters of the SST shown:

[0123] Operation 0: NF is PCF.

[0124] Operation 1: In the Nnef_ParameterProvision_Create, Nnef_ParameterProvision_Update, or Nnef_ParameterProvision_Delete request, AF provides NEF with one or more parameters to be created or updated.

[0125] The payload of the Nnef_ParameterProvision_Update request includes one or more of the following parameters:

[0126] Table 1: Description of Expected Application Configuration Parameters

[0127]

[0128] These parameters are categorized as PCF associated parameters in the UDM and sent to the PCF.

[0129] Operations 2, 3, and 7: The message contains the expected application configuration parameters.

[0130] Solution 2.1:

[0131] According to Solution 2, the PCF can further configure the SST for the OSID+APPID using the parameters of SST and OSID+APPID, where the OSID is based on the UE status indication included in the registration request message from the UE. The AMF can include the operator-defined access category with both S-NSSAI and OSID+APPID in the registration acceptance message given to the UE.

[0132] Using the access category information defined by the operator, the UE can determine the association between OSID+AppID and S-NSSAI, and can establish a PDU session with the allowed S-NSSAI when it receives an upper-layer request from the application identified by OSID+AppID.

[0133] Solution 2.2:

[0134] Following Solution 2, if preferred QoS service requirements are provided, the PCF can further use parameters to provide service differentiation to the UE based on the SD between S-NSSAIs with the same SST of the application. Two methods can be used to provide service differentiation for different UEs:

[0135] The S-NSSAI's SD can be used to configure S-NSSAIs with different QoS requirements. Therefore, a 5G network can assign S-NSSAI#1 with higher QoS requirements to User 1, who has Platinum membership, and S-NSSAI#2 with normal QoS requirements to User 2, who has regular membership. This association can be provided within operator-defined access categories. Furthermore, operator-defined access category priority values ​​can be set between S-NSSAIs and OSID+APPIDs with the same configured SST. For example, User 1 (Platinum membership) can have a higher S-NSSAI#1 and OSID+APPID priority value for an operator-defined access category than User 2 (Regular membership), while User 2 can have a higher S-NSSAI#2 and OSID+APPID priority value for an operator-defined access category than User 1.

[0136] Solution 3:

[0137] This provides a way for the network to appropriately allocate network slices for applications. Specifically, the AF issues a request on behalf of an application of the PLMN that is not a serving UE, by referring to Clause 4.15.6.7 of TS23.502, in which the AF request includes a service description, service parameters, and a target UE or a group of UEs, and in which the service parameters are service-specific information to be allocated and passed to the UE in the network to support the service identified by the service description.

[0138] The supplement to Clause 4.15.6.7 of TS 23.502 includes, for example, Figure 5 As shown: The service description includes the SST type for the network slice used to identify the application by OSID+APPID, or the preferred SD for the network slice by SST type. PCF uses service parameters and service descriptions to configure the association between network slices and applications. Figure 5 During the registration process shown, the AMF can configure operator-defined access category information and provide this information to the target UE. The PCF uses service parameters and service descriptions to configure the association between network slices and applications and assigns this association to the target UE. Using both service parameters and operator-defined access category information, the UE can determine the association between OSID+AppID and S-NSSAI, and can establish a PDU session with the allowed S-NSSAI when it receives an upper-layer request from the application identified by OSID+AppID.

[0139] Solution 4:

[0140] The AF requests specific parameter updates via the UE policy configuration update procedure to apply a specific SoR policy. These parameters take precedence over the SoR policy provided by the HPLMN. According to Solution 3, this allows the UE to select the appropriate network slice for applications provided by third parties with SLAs with different network operators, and to modify... Figure 5 This allows the service parameters to include a list of preferred PLMN IDs for the application, and the preferred PLMN for that application.

[0141] If the UE stores service parameters consisting of a SOR list with network slice combinations and a combination of DNN / SST or S-NSSAI / application ID and application preferred PLMN ID lists, then the UE selects the preferred PLMN with the highest priority within the coverage area based on the application preferred PLMN ID list. In other words, the application preferred PLMN ID list takes precedence over the SOR list with network slice combinations.

[0142] Solution 4.1:

[0143] According to Solution 4, the service parameters for the preferred PLMN ID list are for sponsored connections, where the payable party for the sponsored connection is a third-party service provider. This allows third parties with SLAs with some network operators to provide sponsored connections for their application users. Therefore, the UE prioritizes the preferred PLMN ID list over the SOR list with network slice combinations only when the preferred PLMN ID list is used to initiate a PDU session for network slicing.

[0144] Solution 5:

[0145] This solution allows the UE to prioritize the use of network slices for different applications. The UE configures priorities such as APPID#1, APPID#2, etc., for user preferences. When APP#X is activated, the UE checks the user's preferences in the APP preference list, and if the preferred PLMN ID list for APP#X differs from the serving PLMN, it decides whether to remain in the current PLMN. Alternatively, if the preferred PLMN ID list for APP#X differs from the serving PLMN, the UE presents a notification message to obtain the user's consent before proceeding with the process of changing the PLMN for APP#X.

[0146] Although embodiments have been described with reference to specific example examples, it will be apparent that various modifications and changes can be made to these embodiments without departing from the wider scope of this disclosure. Therefore, the specification and drawings are to be considered illustrative rather than restrictive. The drawings, which form part of this specification, illustrate specific embodiments from which the subject matter can be practiced by way of illustration rather than limitation. The illustrated embodiments have been described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments can be utilized and derived therefrom, allowing structural and logical substitutions and changes to be made without departing from the scope of this disclosure. Therefore, this detailed description should not be construed as limiting, and the scope of the various embodiments is defined only by the appended claims together with the full scope of their equivalents.

[0147] The subject matter may be referred to herein individually and / or collectively by the term "embodiment," merely for convenience, and is not intended to intentionally limit the scope of this application to any single inventive concept (if more than one is actually disclosed). Therefore, although specific embodiments have been shown and described herein, it should be understood that any arrangement considered 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 the various embodiments. Combinations of the above embodiments, as well as other embodiments not specifically described herein, will be apparent to those skilled in the art upon reading the above description.

[0148] In this document, as is common in patent documents, the terms “a” or “an” are used to include one or more, independent of any other instances or uses of “at least one” or “one or more.” 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 “comprising” and “therein” are used as simple English equivalents to the corresponding terms “including” and “wherein.” Furthermore, in the following claims, the terms “comprising” and “including” are open-ended, meaning that a system, UE, article, composition, structure, or process that includes elements other than those listed after such terms in a claim is still considered to fall within the scope of that claim. 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.

[0149] The abstract provided is intended to comply with 37C.FR §1.72(b), which requires that an abstract allow the reader to quickly determine the nature of the technical disclosure. It is understood at the time of filing that it should not be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen from the foregoing detailed description, various features have been combined together in a single embodiment for the purpose of simplifying the disclosure. This method of disclosure should not be construed as reflecting an intention that the claimed embodiment requires more features than expressly recited in each claim. Rather, as reflected in the following claims, the subject matter of the invention lies in fewer than all the features of a single disclosed embodiment. Therefore, the following claims are hereby incorporated into the detailed description, each claim representing a separate embodiment in itself.

Claims

1. An apparatus for a user equipment (UE), the apparatus comprising: The processing circuit is configured as follows: Decode network slice information from a third party in a public terrestrial mobile network (PLMN), the network slice information including the association between network slices and applications, the applications including the third party's applications; After receiving the network slice information, the application is activated; as well as In response to the activation of the application, a network slice is selected based on the network slice information. and The memory is configured to store information related to the network slice; in, The association between the network slice and the application is configured by the Policy Control Function (PCF) using service parameters and service descriptions; The service description includes a slice / service type (SST) for a network slice used by an application identified by an operating system identifier (OSID) and an application identifier (APPID), or the SST type of the network slice and a preferred service distinguisher (SD).

2. The apparatus of claim 1, wherein: The network slicing related information includes network slice configurations based on a list of preferred network operators considered for applications used for sponsor connections, and The processing circuit is also configured to use the network slice configuration over the roaming guidance SoR policy provided by the UE's Home Public Land Mobile Network (HPLMN).

3. The apparatus of claim 1, wherein: The processing circuit is also configured to decode network slice-related information from the serving PLMN. The serving PLMN is either a Home Public Land Mobile Network (HPLMN) or an Access PLMN. The network slice-related information is based on service-specific information used to support services identified by the service description, and The service-specific information is included in the service parameters of the application function (AF) request, which includes the service description, the service parameters, and the target UE or a group of UEs.

4. The apparatus of claim 3, wherein: The network slice-related information includes associations between network slices and applications from the Access and Mobility Function (AMF) or Policy Control Function (PCF). The PCF configures these associations using service parameters and service descriptions from the AF request. After registering with the service PLMN, the processing circuit is further configured to decode operator-defined access category information from the AMF.

5. The apparatus of claim 4, wherein, The processing circuit is further configured to: Based on the service parameters and the access category information defined by the operator, the association between the application's operating system identifier (OSID) and application identifier (AppID) and the single network slice selection assistance information (S-NSSAI) is determined. as well as In response to receiving an upper-layer request from an application identified by a specific OSID and AppID, a Packet Data Unit (PDU) session is established with the requested S-NSSAI within the allowed S-NSSAI.

6. The apparatus of claim 3, wherein: The service parameters include a list of preferred PLMN IDs for the application, and The processing circuit is also configured to use the application-preferred PLMN ID list, taking precedence over the roaming guidance SoR list with network slice combinations provided by the UE's HPLMMN.

7. The apparatus of claim 6, wherein, The processing circuit is further configured to: Based on the application's preferred PLMN ID list, the preferred PLMN with the highest priority is selected within the coverage area.

8. The apparatus of claim 7, wherein, The application's preferred PLMN ID list service parameters are used for sponsor connections, where the payable party for the sponsor connection is the third-party service provider.

9. The apparatus of claim 1, wherein, The processing circuit is further configured to: Activate another application; Determine that the application and the other application will use different network slices in different PLMNs; as well as Based on the user preferences of the application and the other application stored in priority order, it is determined whether to move from the PLMN to a different PLMN.

10. The apparatus of claim 9, 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, it is determined whether to move from the PLMN to the different PLMN, and whether to stay in the PLMN is determined based on whether the application's preferred PLMN ID is different from the PLMN.

11. The apparatus of claim 10, wherein, The processing circuit is further configured to: In response to determining to switch to the different PLMN, a notification is generated to obtain the user's consent to switch to the different PLMN before the switch is initiated.

12. The apparatus of claim 1, wherein, The network slice-related information includes priority, Quality of Service (QoS) level, and Slice / Service Type (SST).

13. An apparatus for a policy control function (PCF), the apparatus comprising: The processing circuit is configured as follows: Encode the Nudm_SDM_Subscribe request for transmission to the Unified Data Management UDM; as well as In response to the Nudm_SDM_Subscribe request, the Nudm_SDM_Notification from the UDM is decoded. The Nudm_SDM_Notification contains expected application configuration parameters from Application Functionality (AF) to Network Open Functionality (NEF) in the Nnef_ParameterProvision_Update request. These expected application configuration parameters include: Operating system identifier (OSID) and application identifier (AppID) identify the applications that the user equipment (UE) has subscribed to; and Slice / Service Type (SST), which identifies the network slice of the service network associated with the application; and The memory is configured to store the expected application configuration parameters; The processing circuit is also configured to: use the SST to configure a single network slice selection auxiliary information S-NSSAI for the associated OSID and AppID.

14. The apparatus of claim 13, wherein: The OSID is based on the UE status indication included in the registration request message from the UE and the operator-defined access category with S-NSSAI, OSID, and APPID in the registration acceptance message to the UE.

15. The apparatus of claim 13, wherein, The expected application configuration parameters also include preferred QoS service requirements, which identify QoS parameters for the UE using the application.

16. The apparatus of claim 15, wherein: The processing circuit is further configured to: provide service differentiation to the UE based on the service distinguisher SD between the auxiliary information S-NSSAI and the single network slice selection auxiliary information S-NSSAI with the same SST having the application, using the expected application configuration parameters, and At least some S-NSSAIs with different SDs have different QoS requirements, which are associated with different user membership levels used for the application.

17. The apparatus of claim 13, wherein: The processing circuit is further configured to: Decoding represents AF requests sent by applications that do not belong to the Public Land Mobile Network (PLMN) serving the UE. Each request includes a service description, service parameters, and a target UE or a group of UEs, wherein the service parameters are service-specific information to be assigned to the PLMN and transmitted to the UE to support the service identified by the service description; and The service parameters and service descriptions are used to configure the association between the network slice and the application, and this association is assigned to the target UE. The service description includes the SST for the network slice used by the application identified by the OSID and AppID, or the SST of the network slice and the preferred service distinguisher SD.

18. A non-transitory computer-readable storage medium storing instructions executable by one or more processors of a user equipment (UE), said one or more processors configuring the UE such that, when said instructions are executed: Decode network slice information from a public terrestrial mobile network (PLMN), the network slice information including the association between network slices and applications; After receiving the network slice information, the first application is activated; Based on the network slice information and the stored user preferences, the network slice of the PLMN is selected; After activating the first application, activate the second application; as well as In response to the activation of the second application: It is determined that the preferred PLMN for the second application is different from the PLMN mentioned above; as well as Based on the user preferences, a preferred PLMN for the second application and which of the PLMNs to use are determined, wherein the user preferences include an application preference list, and the application preference list includes the priorities of the first application and the second application; in, The association between the network slice and the application is configured by the Policy Control Function (PCF) using service parameters and service descriptions; The service description includes a slice / service type (SST) for a network slice used by an application identified by an operating system identifier (OSID) and an application identifier (APPID), or the SST type of the network slice and a preferred service distinguisher (SD).

19. The medium as claimed in claim 18, wherein, When the instructions are executed, they further configure the one or more processors to configure the UE as follows: In response to determining a switch from the PLMN to the preferred PLMN of the second application, the user's consent to the switch is obtained before the switch is made.

Images