User equipment (UE) route selection policy (URSP) rule enhancements for user plane transmission of UE data

Abstract

The present disclosure relates to User Equipment (UE) Routing Selection Policy (URSP) rule enhancements for user plane transmission of UE data. The present disclosure provides a method performed by a User Equipment (UE) comprising: receiving, from a Core Network (CN), a request for the UE to update policy information of the UE to include a User Equipment Routing Selection Policy (URSP) rule to be used by the UE for routing data over a Protocol Data Unit (PDU) session on a user plane between the UE and the CN. The URSP rule indicates at least one of a data identifier (ID) associated with the data or a data type associated with the data. The method comprises verifying the URSP rule to determine that the UE supports implementation of the URSP rule. The method comprises storing the URSP rule in the policy information of the UE based on the verification. And the method comprises sending a response to the request to the CN.

Description

Technical Field

[0001] This disclosure relates generally to telecommunications, and more specifically to data collection and reporting in telecommunications systems. Background Technology

[0002] A telecommunications system can be viewed as a facility that enables communication between two or more entities, such as between two user equipments (UEs), between a UE and a base station, between two base stations, between a UE and the network functions of a communication network, and / or between a base station and other nodes. A telecommunications system may include a communication network and one or more UEs. Communication sessions may include, for example, data communications used to carry communications such as voice, video, email, text messaging, multimedia, and / or content data. Non-limiting examples of the services provided include two-way or multiplexed calls, data communication or multimedia services, and access to data network systems such as the Internet.

[0003] In telecommunications systems that include wireless communication networks, at least a portion of a communication session between at least two stations occurs over a wireless link. Examples of wireless communication networks include Public Land Mobile Networks (PLMNs), satellite-based communication networks, and various wireless local area networks, such as Wireless Local Area Networks (WLANs). Some wireless communication networks can be divided into cells and are therefore often referred to as cellular networks.

[0004] Users can access the telecommunications system through appropriate communication equipment or terminals. The user's communication equipment may be referred to as user equipment (UE) or user device. The communication equipment is provided with appropriate signal receiving and transmitting means to enable communication, for example, to enable access to a communication network or to communicate directly with other users. The communication equipment can access a carrier provided by, for example, a base station in a cell, and transmit and / or receive communication on that carrier.

[0005] Telecommunications systems have evolved through multiple generations, each bringing advancements in speed, capacity, and functionality. Evolved Packet System (EPS) represents the 4G architecture, which includes Long Term Evolution (LTE) and LTE-Advanced (LTE-A) as its radio access technologies. 5G systems (5GS) are built on EPS, introducing 5G New Radio (5G NR) for enhanced mobile broadband, massive machine-type communications, and ultra-reliable low-latency communications. Future 6G systems (6GS) are expected to further transform telecommunications with even more advanced capabilities. These systems are interconnected, with 5GS designed to interact with EPS for seamless service continuity. The 3rd Generation Partnership Project (3GPP) plays a crucial role in developing and maintaining standards for these telecommunications systems, ensuring global interoperability, and the evolution from Universal Mobile Telecommunications System (UMTS) (3G) to the ongoing development of 6G technologies. Summary of the Invention

[0006] The example implementations disclosed herein are geared toward telecommunications, and more specifically toward data collection in telecommunications systems. This disclosure includes, but is not limited to, the following example implementations.

[0007] The first example implementation provides a method comprising: receiving from a core network (CN) a request to update policy information for a UE to include UE routing policy (URSP) rules, which will be used by the UE to route data on a Protocol Data Unit (PDU) session on the user plane between the UE and the CN, wherein the URSP rules indicate at least one of a data identifier (ID) associated with the data or a data type associated with the data; verifying the URSP rules to determine that the UE supports the implementation of the URSP rules; storing the URSP rules in the UE's policy information based on the verification; and sending a response to the request to the CN.

[0008] In the first example implementation, the URSP rule includes a business descriptor that indicates at least one of a data ID or a data type.

[0009] In the first example implementation, the URSP rule includes information describing the PDU session on which the UE will route data, and the information describing the PDU session indicates the PDU session type of the PDU session.

[0010] In the first example implementation, the URSP rule includes a routing descriptor that indicates the PDU session type of the PDU session.

[0011] In the first example implementation, the PDU session type indicates at least one of the following: data ID or data type.

[0012] In the first example implementation, the PDU session type indicates the purpose associated with the data.

[0013] In the first example implementation, the information describing the PDU session also indicates at least one of the following: the data network name (DNN) associated with the PDU session on which the UE will route data, or the network slice associated with the PDU session on which the UE will route data.

[0014] In the first example implementation, verifying the URSP rule includes determining that the UE supports: the collection of data from one or more layers in the radio protocol stack; and the transmission of data to a higher-level function above one or more layers in the radio protocol stack, where the URSP rule is implemented.

[0015] In the first example implementation, the data includes data measured by the UE or measurement data.

[0016] The second example implementation provides a method comprising: determining, based on a configuration used by a user equipment (UE) to collect and report data, to trigger an update of the UE's policy information to include a UE routing policy (URSP) rule, which the URSP rule will be used by the UE to route data on a Protocol Data Unit (PDU) session on the user plane between the UE and the core network (CN); sending a request to a Protocol Control (PC) Network Function (NF) in the CN to perform the update of the UE's policy information to include the URSP rule; and receiving a response from the PC NF to the request, wherein the response indicates whether the update of the policy information has been acknowledged.

[0017] In the second example implementation, the request includes information describing the data, and the information describing the data indicates at least one of a data identifier (ID) associated with the data or a data type associated with the data.

[0018] In the second example implementation, the request includes information describing the PDU session on which the UE will route data, and the information describing the PDU session indicates the PDU session type of the PDU session.

[0019] In the second example implementation, the information describing the PDU session also indicates at least one of the following: the data network name (DNN) associated with the PDU session on which the UE will route data, or the network slice associated with the PDU session on which the UE will route data.

[0020] In the second example implementation, the method is performed by a network function (NF) in the CN, where the NF is an NF dedicated to the management of data collected by the UE, or a user equipment data management function (UEDMF), and the method further includes: constructing a configuration for the UE to use to collect and report data.

[0021] In the second example implementation, the method is performed by the Mobility Management (MM) Network Function (NF) in the CN, wherein the method further includes receiving a notification from the Radio Access Network (RAN) node serving the UE for configuration used by the UE to collect and report data.

[0022] In the second example implementation, the data includes data measured by the UE or measurement data.

[0023] A third example implementation provides a user equipment (UE) with a method comprising: collecting data according to a configuration used by the UE to collect and report data; determining a UE routing policy (URSP) rule for the data based on at least one of a data identifier (ID) associated with the data or a data type associated with the data, wherein the URSP rule will be used by the UE to route the data on a Protocol Data Unit (PDU) session on the user plane between the UE and the core network (CN); and routing the data on an existing PDU session or a new PDU session based on the URSP rule.

[0024] In the third example implementation, the URSP rule includes a business descriptor that indicates the data ID associated with the data or the data type associated with the data.

[0025] In the third example implementation, the URSP rule includes information describing the PDU session on which the UE will route data, and the data routing includes: routing data on the existing PDU session when the matching information exists, or routing data on the new PDU session when the existing PDU session for the matching information does not exist.

[0026] In the third example implementation, the information describing the PDU session indicates the PDU session type.

[0027] In the third example implementation, the URSP rule includes a routing descriptor that indicates the PDU session type of the PDU session.

[0028] In the third example implementation, the PDU session type indicates at least one of the data ID associated with the data or the data type associated with the data.

[0029] In the third example implementation, the PDU session type indicates the purpose associated with the data.

[0030] In the third example implementation, the information describing the DPU session also indicates at least one of the following: the data network name (DNN) associated with the PDU session on which the UE will route data, or the network slice associated with the PDU session on which the UE will route data.

[0031] In the third example implementation, data is collected from layers in the radio protocol stack, wherein the method further includes: transmitting data from the layers toward higher-level functions above the layers in the radio protocol stack; wherein URSP rules are determined at the higher-level functions, and wherein data is routed from the higher-level functions, on existing PDU sessions or new PDU sessions.

[0032] In the third example implementation, the data includes data measured by the UE or measurement data.

[0033] A fourth example implementation provides an apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform a method according to any one of the first to third example implementations.

[0034] A fifth example implementation provides an apparatus including components for performing a method according to any one of the first to third example implementations.

[0035] A sixth example implementation provides a computer-readable medium including instructions that, in response to execution by at least one processor, cause a device to perform a method according to any one of the first to third example implementations.

[0036] A seventh example implementation provides a computer-readable storage medium including instructions that, in response to execution by at least one processor, cause a device to perform a method according to any one of the first to third example implementations.

[0037] The eighth example implementation provides a computer program including instructions that, in response to execution by at least one processor, cause the apparatus to perform a method according to any one of the first to third example implementations.

[0038] These and other features, aspects, and advantages of this disclosure will become apparent from the following detailed description and the accompanying drawings, which are briefly described below. This disclosure includes any combination of two, three, four, or more features or elements set forth herein, whether or not such features or elements are explicitly combined or otherwise referenced in the particular example implementations described herein. This disclosure is intended to be read holistically, such that any separable feature or element of this disclosure, in any aspect and example implementation, should be considered composable unless the context of this disclosure clearly indicates otherwise.

[0039] Therefore, it should be understood that this invention is provided merely to outline some exemplary implementations in order to provide a basic understanding of some aspects of this disclosure. Consequently, it should be understood that the above-described exemplary implementations are merely examples and should not be construed as limiting the scope or spirit of this disclosure in any way. Other exemplary implementations, aspects, and advantages will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate by way of example the principles of some of the described exemplary implementations. Attached Figure Description

[0040] Having thus broadly described an example implementation of this disclosure, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and in which:

[0041] Figure 1 The illustration depicts a telecommunications system comprising one or more Public Land Mobile Networks (PLMNs) coupled to one or more external data networks, according to some example implementations of this disclosure;

[0042] Figure 2 The diagram illustrates a PLMN based on some example implementations;

[0043] Figure 3 The diagram illustrates a portion of the radio protocol stack architecture based on some example implementations;

[0044] Figure 4 The illustration shows the implementation of User Equipment (UE) Routing Policy (URSP) rules according to some example implementations;

[0045] Figure 5 The diagram illustrates a process for updating policy information for a UE to include URSP rules, based on some example implementations.

[0046] Figure 6 It is a flowchart illustrating the various steps in a method executed by the UE according to various example implementations;

[0047] Figure 7 It is a flowchart illustrating the various steps in the method implemented according to various examples;

[0048] Figure 8 It is a flowchart illustrating the various steps in a method executed by the UE according to various example implementations; and

[0049] Figure 9 The diagram illustrates a device implemented according to some examples. Detailed Implementation

[0050] Some implementations of this disclosure will now be described more fully below with reference to the accompanying drawings, which illustrate some, but not all, implementations of this disclosure. In fact, various implementations of this disclosure may be implemented in many different forms and should not be construed as limiting oneself to the implementations set forth herein; rather, these exemplary implementations are provided so that this disclosure will be thorough and complete and will fully convey the scope of this disclosure to those skilled in the art. The same reference numerals always refer to the same elements. Unless otherwise specified or clearly apparent from the context, references to first, second, etc., should not be construed as implying a particular order, but are used only to distinguish one item or operation from another.

[0051] As used herein, unless otherwise specified or clearly indicated from the context, an "OR" of a set of operands is an "inclusive OR," and is therefore true if and only if one or more of the operands are true, as opposed to an "exclusive OR," which is false if all operands are true. Thus, for example, "[A] OR [B]" is true if [A] is true, or if [B] is true, or if both [A] and [B] are true. Furthermore, the articles "a" and "one" mean "one or more," unless otherwise specified or clearly indicated from the context in the singular form. Additionally, it should be understood that, unless otherwise specified, the terms "data," "content," "digital content," "information," and similar terms are sometimes used interchangeably. The term "network" can refer to a set of interconnected computers including clients and servers; and within a network, these computers can be interconnected directly or indirectly in various ways, including via one or more switches, routers, gateways, access points, etc.

[0052] This disclosure discusses telecommunications systems and mobile or cellular networks and their user equipment, and while specific terminology may be used, it is broadly applicable to a wide range of technologies. For example, while this disclosure may refer to radio access technologies such as 5G NR and Advanced 5G, it is equally relevant to next-generation radio access technologies such as 6G. The exemplary implementations of this disclosure described herein also refer to Public Land Mobile Networks (PLMNs) and Mobile Network Operators (MNOs), but the exemplary implementations are similarly applicable to Standalone Non-Public Networks (SNPNs).

[0053] While some examples and figures focus on radio access networks (RANs), particularly radio access networks operating according to the 3GPP standards for 5G NR (often referred to as 3GPP access or 3GPP access network), the example implementations can be used with any type of access network. Applicability to any type of access network includes not only 3GPP access networks but also non-3GPP access networks, such as wired access, untrusted non-3GPP access networks, and trusted non-3GPP access networks that use Wireless Access Gateway Functions (W-AGF), Non-3GPP Interoperability Functions (N3IWF), or Trusted Non-3GPP Gateway Functions (TNGF) to connect to the core network of a mobile or cellular network (e.g., a 5G core network (5GC) or a 6G core network (6GC)).

[0054] Furthermore, as used in this application, the term "circuit system" may refer to one or more or all of the following: (a) a hardware circuit implementation only (such as an implementation only in analog and / or digital circuit systems); and (b) a combination of hardware circuits and software, such as (if applicable): (i) a combination of (multiple) analog and / or digital hardware circuits having software / firmware, and (ii) any part of (multiple) hardware processors having software (including (multiple) digital signal processors, software, and (multiple) memories, which work together to enable a device (such as a mobile phone or a server) to perform various functions); and (c) (multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g., firmware) to operate, but may be absent when operation is not required.

[0055] This definition of circuit system applies to all uses of the term in this application (including in any claim). As another example, as used in this application, the term circuit system also covers only hardware circuitry or a processor (or multiple processors) or portions of hardware circuitry or a processor and its accompanying software and / or firmware implementation. For example, and if applicable to a particular claim element, the term circuit system also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices or other computing or network devices.

[0056] Figure 1 The illustration depicts a telecommunications system 100 according to various example implementations of this disclosure. Examples of suitable telecommunications systems include UMTS, EPS, and 5GS, as well as future 6GS. A telecommunications system (also referred to as a system) typically includes one or more mobile or cellular networks that can interoperate between the telecommunications systems. As shown, for example, the system includes one or more PLMNs 102 coupled to one or more other external data networks 104, particularly wide area networks (WANs) such as the Internet. It should be understood that the PLMN can be a standalone PLMN including a 5GC, or a non-standalone PLMN including an evolved packet core (EPC) and a 5GC connected to a RAN.

[0057] Each PLMN 102 includes a core network (CN) 106, such as EPC, 5GC, or 6GC; and each CN is coupled to one or more RANs 108 implementing one or more Radio Access Technologies (RATs). Examples of these RANs include the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) for 4G LTE, the Next Generation Radio Access Network (NG-RAN) for 5G NR, and 6G RAN. As used herein, “network equipment” refers to any suitable equipment in the RAN or core network of a telecommunications system. Examples of suitable network equipment are described in more detail below.

[0058] Examples of RATs include 3GPP radio access technologies such as GSM, CDMA2000 1xEV-DO (HRPD), CDMA2000 1x (1xRTT), UTRA, E-UTRA, 5G NR, 5G Advanced, and 6G. Other examples of RATs include IEEE 802 technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.15 (including 802.15.1 (WPAN / Bluetooth), 802.15.4 (Zigbee), and 802.15.6 (WBAN)), Bluetooth, Bluetooth Low Energy (BLE), Ultra Wideband (UWB), etc. Generally, a RAT can refer to any 2G, 3G, 4G, 5G, 6G, or higher generation RAT and its different versions, as well as any other RAT that can be assigned to work with such a RAT to provide access to CN 106 of the MNO.

[0059] Telecommunication system 100 also includes one or more communication devices, which may be referred to differently as user equipment (UE) 110, terminal equipment, terminal device, mobile station, etc. A UE is typically a device configured to communicate with network equipment (e.g., an access node of a RAN node such as RAN 108) or another UE in the telecommunications system. A UE may be a portable computer (e.g., a laptop computer, notebook computer, tablet computer), a mobile phone (e.g., a cellular phone, smartphone), a wearable computer (e.g., a smartwatch), etc. In other examples, a UE may be an Internet of Things (IoT) device, an industrial equipment (IIOT device), a vehicle equipped with vehicle-to-everything (V2X) communication technology, etc. In some examples, as referenced by 3GPP, a UE may be a narrowband (NB-IoT) device, an enhanced machine-type communication (eMTC) device, a redcap device, an environmental IoT device, etc.

[0060] In operation, these UEs 110 can connect to one or more RAN nodes of RAN 108 based on their specific RAT, thereby accessing a specific CN 106 of PLMN 102, or accessing one or more external data networks 104 (e.g., the Internet) or services provided by the PLMN. External data networks can provide Internet access or third-party services. For example, the International Telecommunication Union (ITU) has categorized 5G mobile network services (e.g., services provided by 5G mobile networks) into three classes: enhanced mobile broadband (eMBB), ultra-reliable and low-latency communications (URLLC), and massive machine-type communications (mMTC) or massive Internet of Things (MIoT).

[0061] In various examples, RAN 108 can be configured to provide one or more macro cells, micro cells, pico cells, femto cells, etc. RAN typically includes one or more RAN nodes that interact with UE 110. In various examples, RAN nodes can be referred to as base stations (BS), access points (AP), base transceiver stations (BTS). Examples of RAN nodes include node B (NB), evolved NB (eNB), macro BS, NB (MNB) or eNB (menb), home BS, NB (HNB) or eNB (HeNB), next-generation NB (gNB), enhanced gNB (en-gNB), next-generation eNB (ng-eNB), 6G NB (6gNB), etc. The term “gNB” in 5G NR can correspond to eNB in ​​4G LTE. In addition, NG-RAN node can refer to gNB or ng-eNB. And unless otherwise specified, gNB in ​​5G NR or 6g NB in ​​6G can sometimes be more commonly referred to as (6) gNB or simply gNB.

[0062] RAN 108 may include several types of network control / management entities responsible for controlling the RAN nodes. The network control / management entities and RAN nodes may be separate or integrated into a single device. The network control / management entities may include processing circuitry configured to perform various management functions for controlling the RAN nodes. The processing circuitry may be associated with memory, computer-readable storage media, or a data storage device including a database for maintaining the information required for the various management functions.

[0063] Figure 2The illustration shows an example of a PLMN 102 communicating with a UE 110 of a telecommunications system 100 and an external data network 104, such as a 4G LTE, 5G NR, or 6G PLMN. As shown, a RAN 108 (e.g., E-UTRAN, NG-RAN, 6G RAN) includes one or more RAN nodes 202 configured to connect one or more UEs to the RAN for access to a CN 106 (e.g., EPC, 5GC, 6GC). In 4G LTE, the UE, E-UTRAN, and EPC constitute the EPS. Similarly, in 5G NR, the UE, NG-RAN, and 5GC constitute the 5GS. And in 6G, the UE, 6G RAN, and 6GC constitute the 6GS.

[0064] In some implementations, the operation of the gNB or other RAN node 202 can be distributed or functionally divided into components including one or more Remote Radio Heads (RRHs) or Radio Units (RUs) and Baseband Units (BBUs); and in some implementations, the BBU can be divided into Central Units (CUs) (central nodes) and Distributed Units (DUs) (distributed nodes). A CU can be, for example, a server, host, or node. In some implementations, RRHs / RUs and DUs can be co-located at network devices. It is also possible for the operation of the gNB or RAN node to be distributed across multiple servers, hosts, or nodes.

[0065] It should also be understood that the distribution of operations between core network operations and RAN node operations can vary depending on the implementation. For example, 5G or 6G network architectures can be based on so-called CU-DU partitioning. One gNB-CU (CU) can control one or more gNB-DU (DU). A gNB-CU can control multiple spatially separated gNB-DUs, at least acting as transmit / receive (Tx / Rx) nodes. However, in some example implementations, a gNB-DU may include, for example, the Radio Link Control (RLC), Media Access Control (MAC) layer, and Physical (PHY) layer, while a gNB-CU may include layers above the RLC layer, such as the Packet Data Convergence Protocol (PDCP) layer, Radio Resource Control (RRC), and Internet Protocol (IP) layer. Other functional partitioning is also possible. Those skilled in the art are believed to be familiar with the Open Systems Interconnection (OSI) model and the functions within each layer.

[0066] In some example implementations, the server or CU can generate a virtual network through which the server communicates with the wireless nodes. Typically, virtual networking can involve the process of combining hardware and software network resources and functions into a single software-based management entity (virtual network). This virtual network can provide flexible distribution of operations between the server and the wireless heads / nodes. In practice, any digital signal processing task can be performed in the CU or DU, and the boundaries of responsibility transferred between the CU and DU can be chosen depending on the implementation.

[0067] Similarly, Figure 2 As shown, CN 106 may include multiple network functions (NFs) partitioned between the control plane (CP) and the user plane (UP). Specifically, for example, CN may include NFs for access and mobility management (MM) (sometimes referred to as MMNF) and session management (SM) (sometimes referred to as SM NF), as well as UPNFs for receiving and sending UP traffic (e.g., data).

[0068] MM NF can be, for example, the Mobility Management Entity (MME) in EPS, the 5G MM or Access and Mobility Management Function (AMF) 204 in 5GS, or the 6G MM in 6GS. Similarly, SM NF can be, for example, the Serving Gateway (SGW) Control Plane Function (SGW-C) and / or the Packet Data Network Gateway (PGW) Control Plane Function (PGW-C) in EPS, the 5G SM or Session Management Function (SMF) 206 in 5GS, or the 6G SM in 6GS. UP NF can be, for example, the SGW User Plane Function (SGW-U) and / or the PGW User Plane Function (PGW-U) in EPS, the User Plane Function (UPF) 208 in EPS, etc.

[0069] Another example of a suitable NF in CN 106 is a Policy Control (PC) NF, such as Policy and Charging Function (PCF) 210, Policy and Charging Rule Function (PCRF), etc. Another example is an NF responsible for user aggregation and network-related data, such as Unified Data Repository (UDR) 212, Home Subscriber Server (HSS), etc. As yet another example, CN 106 may include (at least one) UE Data Management Function (UEDMF) 214, which may be a separate, dedicated NF or integrated with another NF in the CN. In some examples, the CN may include more than one UEDMF, such as in cases where a UEDMF can be provided for each of multiple UE vendors, etc.

[0070] Figure 3The diagram illustrates a portion of the architecture of the radio protocol stack 300 between UE 110 and RAN node 202, according to some example implementations. As shown, depending on the data types processed by the stack, the radio protocol stack has two distinct stacks. User data passes through the UP stack 302, and signaling messages pass through the CP stack 304. Both the UP and CP stacks consist of a common structure including Layer 1 (L1) with a PHY layer 306 and Layer 2 (L2) with sublayers including MAC 308, RLC 310, and PDCP 312. Layer 3 (L3) sits above PHY / MAC / RLC / PDCP and includes distinct sublayers between the CP and UP. In the UP, L3 includes a sublayer called Serving Data Adaptation Protocol (SDAP) 314, which can connect to other suitable NFs in UPF 208 or CN 106. In the CP, L3 includes two sublayers called RRC 316 and Non-Access Stratum (NAS) 318, and the NAS layer connects to AMF 204 in CN.

[0071] Typically, each layer of the radio protocol stack 300 performs specific data communication tasks, destined for and used by the layers preceding it. For example, RLC 310 provides its services to PDCP 312. Similarly, PDCP provides its services to SDAP 314 (in UP 302) or RRC 316 (in CP 304). PDCP's main services or functions include, for example, header compression and decompression, transmission of user data, encryption and decryption, and timer-based Service Data Unit (SDU) discarding.

[0072] The processing of the layers of the radio protocol stack 300, which performs specific data communication tasks, can be likened to placing a letter in a series of envelopes before sending it through a postal system. Each subsequent envelope adds another layer of processing or overhead information required to process the transaction. All envelopes together help ensure that the letter arrives at the correct address and that the received message is the same as the sent message. Once the entire envelope has been received at its destination, it is opened one by one until the letter itself appears in full written form.

[0073] The data flow between the source and destination (such as UE 110 and RAN node 202) is from top to bottom across the communication line in the source, and then from bottom to top in the destination. Each time user data is passed down from one layer in the source to the next, more processing information is added. When this information is removed and processed by the peer layer in the destination, it enables various tasks (error correction, flow control, etc.) to be performed.

[0074] For some time, data in PLMN 102 has been transmitted in small cells called “packets,” which serve as discrete blocks of information carrying data from one point to another. In 3GPP, data is transmitted in Protocol Data Units (PDUs). Data packets (such as PDUs) are transmitted between UE 110 and external data network 104 in a communication session called a PDU session, which is a communication channel established to facilitate data exchange. A PDU session can be anchored at UPF 208 in CN 106.

[0075] UE 110 can be pre-configured or provided with UE policies that include policy information managing UE behavior. For example, the UE can be provided with UE policies including policy information by the PCF 210 of its home PLMN 102 (HPLMN). These UE policies include UE routing policies (URSPs), which include a prioritized list of URSP rules that the UE uses to determine how to route outgoing traffic to, for example, an existing PDU session or a new PDU session. When the UE is both pre-configured and provided with URSP rules, the UE can use the provided URSP rules on top of the pre-configured URSP rules. Similarly, when the UE is pre-configured with URSP rules in both its Universal Subscriber Identity Module (USIM) and Mobile Equipment (ME), the UE can use the URSP rules in the USIM on top of the URSP rules in the ME.

[0076] In URSP, each URSP rule can include multiple parameters, such as rule priority, service descriptor, and a list of routing descriptors. Rule priority determines the order in which URSP rules are enforced in UE 110. Service descriptors describe the outgoing traffic to which the URSP rule applies. Each routing descriptor includes: a routing descriptor priority, which determines the order in which routing descriptors will be applied; and one or more routing components that describe how outgoing traffic matching the service descriptor should be routed.

[0077] When UE 110 has outgoing traffic for an application, the UE can evaluate URSP rules in order of rule priority to determine if any URSP rules are available. That is, the UE can evaluate URSP rules to determine if the application matches the traffic descriptor of any URSP rule. When it is determined that a URSP rule applies to the application, the UE can select a routing descriptor within the URSP rule in order of routing descriptor priority. The UE can then determine if there is an existing PDU session that matches the routing component in the selected routing descriptor.

[0078] UE 110 can compare the routing components of a selected routing descriptor with multiple existing PDU sessions in several different ways. For example, for a routing component containing only one value (e.g., Selection and Service Continuity (SSC) mode), the value of the PDU session should be the same as the value specified in the routing descriptor. On the other hand, for a routing component containing a list of values ​​(e.g., Network Slice Selection), the value of the PDU session should be the same as one of the values ​​specified in the routing descriptor. When some routing components (multiple) are not present in the routing descriptor, a PDU session can be considered a match if the PDU session is established without including the missing routing components (multiple) in the PDU session establishment request used for the PDU session. Furthermore, when the routing descriptor includes a time window or location criterion, a PDU session can be considered a match if it is associated with a routing descriptor that has the same time window or location criterion validity conditions.

[0079] If an existing PDU session exists that matches the routing component of the routing descriptor, UE 110 can associate the application with the existing PDU session. That is, the UE can route outbound traffic for applications on existing PDU sessions. In the case of multiple existing PDU sessions that match the routing component, the UE can select one of the existing PDU sessions to use. If no existing PDU session matches the routing component, the UE can attempt to establish a new PDU session using the value specified by the routing descriptor; and if the PDU session is accepted, the UE can associate the application with that new PDU session. At this point, as before, the UE can route outbound traffic for applications on the new PDU session.

[0080] In the context of data collection, the Minimum Drive Test (MDT) framework is a feature widely used by MNOs, which seek feedback on coverage in specific areas of their network (management-based MDT) or on radio conditions experienced by a particular(several) UE(s) in a given coverage area of ​​a PLMN (signaling-based MDT). In this context, the MDT framework may include, for example, a management system and a Tracking Collection Entity (TCE). The management system and TCE may be components of Operations, Administration, and Maintenance (OAM).

[0081] Therefore, 3GPP has existing mechanisms that enable the management system to configure RAN node 202 to collect data from UE 110 and then provide that data back to the management system. 3GPP also agrees on various use cases where artificial intelligence (AI) / machine learning (ML) models need to be executed only in the RAN node, only in the UE, or partially in the UE and partially in the RAN node. For AI / ML models that will be executed (partially or entirely) in the UE, functionality is needed to train these AI / ML models. To train these AI / ML models, data needs to be collected from the UE and used to train the functionality. The MNO can require that the data used for training is visible to the MNO. Thus, the MNO can include at least one UEDMF 214 in CN 106, and the UEDMF can be responsible for managing the data collected by the UE.

[0082] In 3GPP, several options have been identified for collecting data for UE 110 to train AI / ML models intended for use in the UE (so-called UE-side AI / ML models and corresponding UE-side data collection). In one or more of these options, data collection can be initiated by UEDMF 214, which can be a standalone dedicated NF or integrated with another NF in CN 106, depending on the use case and the data to be collected.

[0083] The existing MDT framework can be enhanced for UE 110 to collect data and report it to the UEDMF; however, such enhancements may be insufficient. For some AI / ML use cases, large amounts of data are required to train one or more AI / ML models, and this data can be transmitted from UE 110 to RAN 108 via RAN node 202. However, the MDT framework is designed to use CP messages on the air interface between the UE and the RAN node, and the capacity of CP messages is quite limited. Therefore, using CP messages to collect bandwidth-intensive data may be impractical for these use cases requiring large amounts of data.

[0084] Since the existing MDT framework (and the corresponding CP reporting MDT measurements via RAN node 202) may be insufficient for UE data collection, UE 110 can be instructed to report data via UP, which terminates at CN 106. However, currently, there is no way for CN to instruct how the UE routes data across (multiple) PDU sessions via UP between the UE and CN.

[0085] In light of the foregoing, the example implementations of this disclosure provide solutions in which URSP rules can be extended to be used by UE 110 to route data over multiple PDU sessions. In some example solutions, at least one URSP rule may include information such as identifying the data to be reported by a data identifier (ID) associated with the data and / or the data type associated with the data. The data may include measurements performed by the UE or other data collected by the UE. Examples of suitable data types include MDT measurement types (e.g., M1 to M9), standard measurements / data, non-standard measurements / data, etc. The information identifying the data to be reported enables the UE to differentiate between network or outgoing traffic used for applications, and between measurements or other data collected by the UE.

[0086] In 3GPP, MDT measurement types include L3 measurements. These measurements can be used for a variety of purposes, such as AI / ML models used to perform mobility management. Another example is L1 measurements, which can be used for purposes such as beam management, mobility, deep transmitters, and receivers. These measurements can be used to deploy AI / ML models at RAN 108, UE 110, or both RAN and UE (also known as network-side, UE-side, and both-side models). This data can be used at different stages of AI / ML, such as for training, inference, and / or monitoring of AI / ML models.

[0087] As currently defined in 3GPP, the service descriptor in URSP rules includes an application descriptor, where the application is identified by the ID of the operating system running on the UE (OSId) and the ID of the application running on the UE's OS (OSAppId). In some examples, the service descriptor can be extended to indicate the data ID associated with the data to be reported and / or the data type associated with the data. In some other examples, the data ID associated with the data and / or the data type associated with the data can be indicated by another rule or parameter of the URSP rule.

[0088] In some examples, URSP rules include information describing the PDU session on which UE 110 will route the data to be reported, such as by indicating the PDU session type. In some of these examples, URSP rules may include a routing descriptor indicating the PDU session type. The PDU session type can be indicated in several different ways, such as by indicating the PDU session type that associates the data with the data ID and / or the data type associated with the data. For example, different PDU session types can be indicated for reporting standard data and proprietary data (e.g., PDU session type = UE Dataset – Standard Data, PDU session type = UE Dataset – Proprietary Data). In another example, different PDU session types can indicate a more specific type of standard data to be reported (e.g., PDU session type = Data Collection – Standard Data – M1 – M2).

[0089] In some examples, the PDU session type can indicate the purpose associated with the data to be reported. For instance, the PDU session type can indicate the stage of AI / ML for which the data will be reported (e.g., training, inference, or monitoring). Different PDU session types can be applied based on the stage and the requirements of that stage(s). For example, the data to be reported for AI / ML training may be large in size and have little or very high latency budget, while the data to be reported for AI / ML monitoring may have a relatively small latency budget.

[0090] In addition to the PDU session type, in some examples, the information describing the PDU session may also indicate the Data Network Name (DNN) and / or network slice associated with the PDU session on which the UE 110 will route data. In some of these examples, the DNN may be indicated as different data collection points distinguished for different data types (e.g., standard or proprietary data). When reporting data on a dedicated slice for different types of data (e.g., standard or proprietary data), the network slice may be indicated as a single value or a list of values ​​for a single Network Slice Selection Auxiliary Information (S-NSSAI).

[0091] In some examples, UE 110 may support the implementation of URSP rules, which the UE will use to report data on PDU sessions, such as through extensions in UE capabilities. The UE may also support notifying CN 106 whether the UE can implement URSP rules. As indicated above, the data collected and reported by the UE may include L3 measurements, L1 measurements, etc. These measurements may be collected from the appropriate layers(s) in the radio protocol stack 300 and transmitted to higher-level functions(s) above the appropriate layers(s) implementing the URSP rules. In some examples, the higher-level functions may be application layers or include application layers. In some examples involving the cellular modem protocol stack, measurements may be transmitted using at least one Attention (AT) command that allows the protocol stack to transmit data from the lower layers(s) to higher-level functions.

[0092] Figure 4 The illustration shows the implementation of multiple URSP rules in the radio protocol stack 300 of UE 110 according to some example implementations. As shown, the UE can receive multiple URSP rules from CN 106 at NAS layer 318, and each of the multiple URSP rules can include a service descriptor and a routing descriptor indicating multiple data IDs associated with data and / or multiple data types associated with the data to be reported. The Session Management (SM) sublayer of the NAS layer (referred to as NAS-SM) can configure the multiple URSP rules at a higher-level function above SDAP layer 314.

[0093] UE 110 can collect data from layers of the radio protocol stack 300 (e.g., RRC 316, PHY 306) and transmit data to higher-layer functions above that layer. For example, the UE can be configured to perform L1 measurements to train an AI / ML model for beam management, or to perform L3 measurements to train an AI / ML model for mobility management. Measurements may include, for example, measurements of at least one MDT measurement type (e.g., M1 to M9). Higher-layer functions can determine URSP rules applicable to the data and implement URSP rules for data (e.g., data ID, data type) that can be associated with (multiple) PDU sessions based on the service descriptor and routing descriptor in the URSP rules. The data associated with (multiple) PDU sessions can then be routed over (multiple) PDU sessions.

[0094] Several example implementations of the solution can offer multiple benefits. In this respect, the solution can enable early classification of the data to be reported and disjoint data reporting to different endpoints (via different PDU sessions), which is particularly useful for reporting data to different owners or interested parties. Several example implementations of the solution can facilitate control over access permissions for data, such as in the case of proprietary data, which can be reported separately from standard data to the same endpoint (with potentially different permissions for storing or accessing the data). The solution can also enable applications with different Quality of Service (QoS) levels for reporting different types of data or for different purposes. For example, if some measurement types are used only for monitoring, measurements associated with those measurement types can be reported with a lower latency budget (on one PDU session), unlike measurements associated with other measurement types used for training AI / ML models (on another PDU session).

[0095] To further illustrate some example implementations Figure 5 The diagram illustrates a process for updating policy information for a UE to include URSP rules. In some examples, this process can be an extension of the UE configuration update process for transparent UE policy delivery, as described in Section 4.2.4.3 of 3GPP TS 23.502. As shown, the process may involve a network-triggered service request that includes triggering a UE policy on PCF 210 to update policy information for UE 110. Among various options, UEDMF 214 or AMF 204 may determine to trigger an update of the UE's policy information to include URSP rules that the UE will use to report data on the PDU session between the UE and CN 106, based on the configuration used by the UE to collect and report data. At this point, the presence of the configuration can trigger an update of the policy information to include URSP rules. UEDMF / AMF may send a request to PCF 210 to trigger the update of the UE policy at steps 501A and 501B.

[0096] In some examples, the request may include information describing the data, and this information may indicate the data ID associated with the data and / or the data type associated with the data. Additionally or alternatively, in some examples, the request may include information describing the PDU session on which the UE 110 will route data, such as by indicating the PDU session type. In some examples, the information describing the PDU session may also indicate the DNN associated with the PDU session on which the UE will route data, and / or the network slice associated with the PDU session on which the UE will route data.

[0097] More specifically, in some examples of the first option, UEDMF 214 can construct a configuration for the UE to use to collect and report data. In some examples of these examples, UEDMF can trigger PCF 210 to update the URSP for the UE to include URSP rules to be used by the UE to route data (collected according to the configuration) on the PDU session on the UP between the UE and CN 106. In the request sent at step 501A, UEDMF may include characteristics or other information describing the PDU session(s), and may also include data(s) of data reported on the PDU session(s). For example, data related to AI / ML training and AI / ML monitoring may have different latency characteristics, standards, and proprietary data may have different endpoints, etc.

[0098] In some examples of the second option, AMF 204 may receive a notification from RAN 108 (e.g., RAN node 202) serving the UE, regarding the configuration for the UE to use and report data. In some examples of these examples, the notification itself may include the configuration, or the notification may include parameters(s) or other information from the configuration. Also in some examples of these examples, the configuration may be an MDT configuration used by the UE to collect and report MDT measurements. The MDT configuration may indicate, for example, the MDT measurement(s) types(s) used for MDT measurements. In the request sent at step 501B, AMF may indicate, for example, whether different MDT measurement types should be carried on different PDU sessions, and what characteristics they should have, etc.

[0099] PCF 210 may determine at step 502 that the request received from UEDMF 214 / AMF 204 at steps 501A / 501B triggers an update to the UE policy. At this point, PCF may update the UE's policy information to include URSP rules based on information included in the request, such as information describing the data (e.g., data ID, data type) and / or information describing the PDU session (e.g., PDU session type, DNN, network slice). In some examples, as described above, PCF may update the policy information to include URSP rules with a service descriptor describing the data and a routing descriptor describing the PDU session.

[0100] If PCF 210 has not yet subscribed to the response from AMF 204 regarding updates to policy information about the UE, then PCF may subscribe to the AMF that will be notified about the UE's response at step 503.

[0101] PCF 210 may invoke a service operation (e.g., Namf_Communication_N1N2MessageTransfer) at step 504 to send a message to AMF 204. This message may include a Subscription Permanent Identifier (SUPI) associated with UE 110, and a UE policy container including URSP rules. If the UE is registered and reachable by the AMF in 3GPP or non-3GPP access, the AMF may transparently transmit the UE policy container to the UE via the registered and reachable access at step 505. At this point, PCF (via AMF) may request the UE to update its policy information to include URSP rules.

[0102] UE 110 can receive the request, and at step 506, the UE can verify the URSP rules to determine whether the UE has the capability to implement or supports the implementation of the URSP rules. In some examples, the UE can determine that it supports the collection of data from multiple layers in the radio protocol stack, and the transmission of data to higher-layer functions above the multiple layers in the radio protocol stack that implement the URSP rules. When the verification indicates that the UE supports the implementation of the URSP rules, the UE can store the URSP rules in the UE's policy information. Then, at step 507, the UE can send a response to the request indicating the result of the UE policy update to AMF 204 in CN 106. At step 508, the AMF can forward the response to PCF 210, such as by using an AMF service operation (e.g., Namf_Communication_N1MessageNotify).

[0103] PCF 210 can maintain a list of the latest Policy Part Identifiers (PSIs) passed to UE 110. PCF can update the list of latest PSIs in UDR 212 by invoking a service operation (e.g., Nudr_DM_Update) at step 509. At this point, the list of latest PSIs can be updated using the URSP rules used by the UE to route data on the PDU session.

[0104] PCF 210 can send a response at step 510 to the request that triggered the update (received at steps 501A / 501B). The response to the request can indicate whether the policy information update was acknowledged (ACK) or not acknowledged (NACK). In some examples where the policy information update fails, the response to the request can indicate that the update was not acknowledged. In these examples, the response can indicate the reason for the update failure, such as the UE's inability to implement URSP rules (e.g., URSP rule implementation is not supported).

[0105] In some examples, UEDMF 214 may consider at step 511 information about the UE’s inability / ability to implement (multiple) URSP rules for routing data on (multiple) PDU sessions, in order to update the UE’s policy information for future triggers of PCF 210, such as by redefining (multiple) triggers to request updates only for UEs with the necessary capabilities or support.

[0106] As indicated above, UE 110 can therefore be configured to implement (multiple) URSP rules to be used by the UE for routing data over a PDU session on the UP between the UE and CN 106. The UE can collect data according to the configuration it uses to collect and report data. The UE can determine the URSP rules applicable to the data based on the data ID and / or data type associated with the data. The UE can then route the data over an existing PDU session or a new PDU session based on the URSP rules. At this point, the URSP rules may include information describing the PDU session on which the UE will route data, and can route data over an existing PDU session if a matching existing PDU session exists, and can route data over a new PDU session if a matching existing PDU session does not exist.

[0107] In some further examples, data can be collected from layers on the radio protocol stack on UE 110. Data can be transmitted from a layer to higher-level functions above that layer in the radio protocol stack. URSP rules available for the data can be determined at the higher-level functionality. And data can be routed from higher-level functions on existing or new PDU sessions.

[0108] Figure 6 This is a flowchart illustrating various steps in method 600 performed by a user equipment (UE) according to various example implementations. The method includes: receiving from the core network (CN) a request to update the UE's policy information to include a UE Routing Policy (URSP) rule, which the UE will use to route data on a Protocol Data Unit (PDU) session on the user plane between the UE and the CN, as shown in box 602. The URSP rule indicates at least one of a data identifier (ID) associated with the data or a data type associated with the data. The method includes: verifying the URSP rule to determine if the UE supports the implementation of the URSP rule, as shown in box 604. The method includes: based on the verification, storing the URSP rule in the UE's policy information, as shown in box 606. The method includes: sending a response to the request to the CN, as shown in box 608.

[0109] In some examples, URSP rules include a business descriptor that indicates at least one of a data ID or a data type.

[0110] In some examples, the URSP rule includes information describing the PDU session on which the UE will route data. In some of these examples, the information describing the PDU session indicates the PDU session type.

[0111] In some examples, URSP rules include a routing descriptor that indicates the PDU session type of the PDU session.

[0112] In some examples, the PDU session type indicates at least one of the following: data ID or data type.

[0113] In some examples, the PDU session type indicates the purpose associated with the data.

[0114] In some examples, the information describing the PDU session also indicates at least one of the following: the data network name (DNN) associated with the PDU session on which the UE will route data, or the network slice associated with the PDU session on which the UE will route data.

[0115] In some examples, validating the URSP rule at box 604 includes determining whether the UE supports: the collection of data from one or more layers in the radio protocol stack; and the transmission of data to a higher-level function above one or more layers in the radio protocol stack, where the URSP rule is enforced.

[0116] In some examples, the data includes data measured by the UE or measurement data.

[0117] Figure 7 This is a flowchart illustrating various steps in method 700 according to various example implementations. The method includes: determining, based on the configuration used by the user equipment (UE) to collect and report data, to trigger an update of the UE's policy information to include a UE routing policy (URSP) rule, which will be used by the UE to route data on the user plane of the user plane in a Protocol Data Unit (PDU) session between the UE and the core network (CN), as shown in box 702. The method includes: based on the determination to trigger an update of the policy information, sending a request to the Protocol Control (PC) Network Function (NF) in the CN to perform the update of the UE's policy information to include the URSP rule for the PC NF, as shown in box 704. And the method includes: receiving a response from the PC NF to the request, wherein the response indicates whether the update of the policy information has been acknowledged, as shown in box 706.

[0118] In some examples, the request includes information describing the data. In some of these examples, the information describing the data indicates at least one of a data identifier (ID) associated with the data or a data type associated with the data.

[0119] In some examples, the request includes information describing the PDU session on which the UE will route data. In some of these examples, the information describing the PDU session indicates the PDU session type.

[0120] In some examples, the information describing the PDU session also indicates at least one of the following: the data network name (DNN) associated with the PDU session on which the UE will route data, or the network slice associated with the PDU session on which the UE will route data.

[0121] In some examples, method 700 is performed by a network function (NF) in the CN. In some of these examples, the NF is a dedicated NF for managing data collected by the UE, or a User Equipment Data Management Function (UEDMF). In some of these examples, the method also includes: constructing a configuration for the UE to use to collect and report data.

[0122] In some examples, method 700 is performed by the Mobility Management (MM) Network Function (NF) in the CN. In some of these examples, the method also includes receiving a notification from the Radio Access Network (RAN) node serving the UE for configurations used by the UE to collect and report data.

[0123] In some examples, the data includes data measured by the UE or measurement data.

[0124] Figure 8 This is a flowchart illustrating various steps in method 800 performed by a user equipment (UE) according to various example implementations. The method includes: collecting data according to a configuration used by the UE to collect and report data, as shown in box 802. The method includes: determining UE routing policy (URSP) rules applicable to the data based on at least one of a data identifier (ID) associated with the data or a data type associated with the data, as shown in box 804. The URSP rules will be used by the UE to route data on Protocol Data Unit (PDU) sessions on the user plane between the UE and the core network (CN). The method also includes: routing data on existing PDU sessions or new PDU sessions based on the URSP rules, as shown in box 806.

[0125] In some examples, URSP rules include a business descriptor that indicates at least one of the data ID or the data type associated with the data.

[0126] In some examples, the URSP rule includes information describing the PDU session on which the UE will route data. In some of these examples, routing data at box 806 includes: routing data on the existing PDU session if a matching information exists, or routing data on a new PDU session if a matching information does not exist.

[0127] In some examples, the information describing the PDU session indicates the PDU session type.

[0128] In some examples, URSP rules include a routing descriptor that indicates the PDU session type of the PDU session.

[0129] In some examples, the PDU session type indicates at least one of the data ID associated with the data or the data type associated with the data.

[0130] In some examples, the PDU session type indicates the purpose associated with the data.

[0131] In some examples, the information describing the DPU session also indicates at least one of the following: the data network name (DNN) associated with the PDU session on which the UE will route data, or the network slice associated with the PDU session on which the UE will route data.

[0132] In some examples, data is collected from layers in the radio protocol stack. In some of these examples, method 800 also includes transmitting data from a layer to a higher-level function above that layer in the radio protocol stack. Also in some of these examples, at box 804, URSP rules are determined at the higher-level function. And at box 806, data is routed from the higher-level function, on an existing PDU session, or on a new PDU session.

[0133] In some examples, the data includes data measured by the UE or measurement data.

[0134] According to the example implementations of this disclosure, the telecommunications system 100 or PLMN 102 and its components, such as UE 110, CN 106, RAN 108, RAN node 202, AMF 204, SMF 206, UPF 208, PCF 210, UDR 212, and / or UEDMF 214, can be implemented in various ways. Components used to implement the system and its components may include hardware, firmware, software, or combinations thereof. In some examples, one or more devices may be configured to function as or otherwise implement the system and its components shown and described herein. In examples involving more than one device, the respective devices may be connected or communicate with each other in a variety of different ways, such as directly or indirectly via wired or wireless networks.

[0135] Based on some example implementations, regarding Figure 6 At least some of the described methods 600 can be performed by means including components for performing functions corresponding to the steps of the method. Similarly, regarding Figure 7 At least some of the described methods 700 can be performed by means including components for performing functions corresponding to the steps of the method. And regarding... Figure 8 At least some of the described methods 800 can be performed by means including components for performing functions corresponding to the steps of the method. Examples of suitable means may include user equipment, user devices, user terminals, etc. Other examples of suitable means may include stand-alone computers containing UEDMF and / or AMF, such as servers, hosts, or nodes, distributed computing systems containing UEDMF and / or AMF, or cloud computing systems containing UEDMF and / or AMF. UEDMF and / or AMF may be implemented as virtual machines or containers by the distributed computing system or cloud computing system.

[0136] Figure 9 The illustration shows an apparatus 900 according to some example implementations of the present disclosure, wherein components for performing various operations include hardware, either independently or under the guidance of one or more computer programs from a computer-readable storage medium or other memory such as computer memory. The apparatus may include one or more of each of a plurality of components, such as a processing circuitry system 902 connected to a computer-readable storage medium or other memory 904.

[0137] The processing circuitry system 902 may consist of a single processor or a combination of one or more computer-readable storage media. A processing circuitry system is generally any computer hardware component capable of processing information, such as, for example, data, computer programs, computer code, and / or other suitable electronic information. A processing circuitry system consists of a collection of electronic circuits, some of which may be packaged as integrated circuits or multiple interconnected integrated circuits (sometimes more commonly referred to as "chips"). The processing circuitry system may be configured to execute a computer program, which may be stored on the processing circuitry or otherwise stored in memory 904 (of the same or another device).

[0138] The processing circuitry system 902 may include multiple processors, multi-core processors, or other types of processors, such as central processing units, graphics processing units, tensor processing units, or accelerators, depending on the specific implementation. Furthermore, the processing circuitry system may be implemented using multiple heterogeneous processor systems, where the main processor resides on a single chip along with one or more auxiliary processors. As another illustrative example, the processing circuitry system may be a symmetric multiprocessor system containing multiple processors of the same type. In yet another example, the processing circuitry system may be implemented as or otherwise include one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), etc. Therefore, while the processing circuitry system may be able to execute computer programs to perform one or more functions, the various example processing circuitry systems may be able to perform one or more functions without the assistance of a computer program. In any instance, the processing circuitry system may be appropriately programmed to perform functions or operations according to the example implementations of this disclosure.

[0139] Memory 904 is typically any computer hardware component capable of storing data, computer programs, instructions 906 (e.g., computer-readable program code), and / or other suitable information on a temporary and / or permanent basis. Memory may include volatile and / or non-volatile memory and may be fixed or removable. Examples of suitable memory include recording media, random access memory (RAM), read-only memory (ROM), hard disk drives, flash memory, USB flash drives, removable computer disks, optical disks, or combinations thereof.

[0140] Memory 904 is a non-transitory device capable of storing information. An example of a suitable memory is a computer-readable storage medium, distinguishable from a computer-readable transmission medium capable of carrying information from one location to another. Examples of suitable computer-readable transmission media include electronic carrier signals, telecommunication signals, or some combination thereof. As used herein, the term "non-transitory" is a limitation on the medium itself (i.e., tangible, not a signal), not a limitation on the persistence of data storage (e.g., RAM versus ROM). The computer-readable medium described herein generally refers to a computer-readable storage medium or a computer-readable transmission medium. A computer-readable medium is any entity or device capable of storing and carrying information such as one or more computer programs or portions thereof.

[0141] In addition to memory 904 (e.g., a computer-readable storage medium), processing circuitry 902 may also be connected to one or more interfaces for displaying, sending, and / or receiving information. Interfaces may include communication interface 908 and / or one or more user interfaces. Communication interfaces may be configured to send and / or receive information, such as to other devices(s), networks(s), etc. Communication interfaces may be configured to send and / or receive information via physical (wired) and / or wireless communication links. Examples of suitable communication interfaces include network interface controllers (NICs), wireless NICs (WNICs), etc.

[0142] The user interface may include a display 910 and / or one or more user input interfaces 912. The display may be configured to present or otherwise display information to a user; suitable examples include liquid crystal displays (LCDs), light-emitting diode (LED) displays, organic LED (OLED) displays, active-matrix OLEDs (AMOLEDs), etc. The user input interface may be wired or wireless and may be configured to receive information from the user into the device, such as for processing, storage, and / or display. Suitable examples of the user input interface include microphones, image or video capture devices, keyboards or keypads, joysticks, touch-sensitive surfaces (separate from or integrated into the touchscreen), biometric sensors, etc. The user interface may also include one or more interfaces for communicating with peripheral devices, such as printers, scanners, etc.

[0143] The processing circuitry 902 executes the instructions 906, or stores the instructions in the memory 904, supporting combinations of operations for implementing exemplary implementations of this disclosure. In this manner, the apparatus 900 may include at least one processing circuitry and at least one memory coupled to the at least one processing circuitry, wherein the at least one processing circuitry is configured to execute instructions stored in the at least one memory. It should also be understood that one or more functions, and combinations of functions, may be implemented by a dedicated hardware-based computer system and / or processing circuitry that performs the specified functions, or by a combination of dedicated hardware and program code instructions.

[0144] Some exemplary implementations of this disclosure can also be executed as a computer process defined by one or more computer programs or portions thereof. Exemplary implementations of this disclosure can be executed by executing at least a portion of a computer program including instructions. The computer program can be in source code form, object code form, or some intermediate form. The computer program can be stored on a computer-readable medium that can be read by a computer, processing circuitry system, or other suitable means. As indicated above, for example, the computer program can be stored in memory such as a computer-readable storage medium. Additionally or alternatively, for example, the computer program can be stored on a computer-readable transmission medium. The coding of software used to perform exemplary implementations of this disclosure is entirely within the scope of those skilled in the art.

[0145] It should be understood that any suitable instructions can be loaded from memory or a computer-readable medium (e.g., a computer-readable storage medium, a computer-readable transmission medium) onto a computer, processor, processing circuitry system, or other programmable means to produce a particular machine, such that particular machine becomes a component for implementing the functions specified herein. The instructions can also be stored in a computer-readable medium that can instruct a computer, processor, processing circuitry system, or other programmable means to function in a particular manner, thereby producing a particular machine or a particular article of manufacture. In some examples, instructions stored in a computer-readable medium can produce an article of manufacture, wherein the article of manufacture becomes a component for implementing the functions described herein. Instructions can be retrieved from a computer-readable medium and loaded onto a computer, processor, processing circuitry system, or other programmable means to configure the computer, processor, processing circuitry system, or other programmable means to perform, or to perform, operations that will be performed on, the computer, processor, processing circuitry system, or other programmable means.

[0146] The retrieval, loading, and execution of instructions, including program code instructions, can be performed sequentially, such that one instruction is retrieved, loaded, and executed at a time. In some example implementations, the retrieval, loading, and / or execution can be performed in parallel, such that multiple instructions are retrieved, loaded, and / or executed together. The execution of program code instructions can produce computer-implemented processes, such that the instructions, executed by a computer, processor, processing circuitry system, or other programmable device, provide operations for implementing the functions described herein.

[0147] Benefiting from the teachings presented in the foregoing description and associated drawings, those skilled in the art to which this disclosure pertains will conceive of numerous modifications and other implementations of the disclosure set forth herein. Therefore, it should be understood that this disclosure is not limited to the specified implementations disclosed, and that modifications and other implementations are intended to be included within the scope of the appended claims. Furthermore, although the foregoing description and associated drawings describe exemplary implementations in the context of certain example combinations of elements and / or functions, it should be understood that different combinations of elements and / or functions can be provided by alternative implementations without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and / or functions other than those explicitly described above are also considered, as may be set forth in some of the appended claims. Although specified terminology is used herein, it is used only in a general and descriptive sense and not for limiting purposes.

Claims

1. A method performed by a user equipment (UE), the method comprising: The request is received from the core network (CN) to update the policy information of the UE to include UE routing policy URSP rules, which will be used by the UE to route data on the user plane of the Protocol Data Unit (PDU) session between the UE and the CN, wherein the URSP rules indicate at least one of a data identifier ID or a data type associated with the data. Verify the URSP rule to determine if the UE supports the implementation of the URSP rule; Based on the verification, the URSP rule is stored in the policy information of the UE; as well as Send a response to the request to the CN.

2. The method of claim 1, wherein the URSP rule includes a service descriptor indicating at least one of the data ID or the data type.

3. The method of claim 1, wherein the URSP rule includes information describing the PDU session, the UE routes the data on the PDU session, and wherein the information describing the PDU session indicates the PDU session type of the PDU session; and The URSP rule includes a routing descriptor that indicates the PDU session type of the PDU session.

4. The method of claim 3, wherein the PDU session type indicates at least one of the data ID or the data type.

5. The method of claim 3 or claim 4, wherein the PDU session type indicates a purpose associated with the data.

6. The method of claim 3 or claim 4, wherein the information describing the PDU session further indicates at least one of the following: a data network name (DNN) associated with the PDU session on which the UE will route the data, or a network slice associated with the PDU session on which the UE will route the data.

7. The method according to any one of claims 1 to 4, wherein verifying the URSP rule includes determining that the UE supports: The collection of data from one or more layers in the radio protocol stack; and The data is transmitted to a higher-level function above one or more layers in the radio protocol stack, where the URSP rules are enforced; or The data mentioned therein includes data or measurement data measured by the UE.

8. A device for communication, comprising: At least one processor; as well as At least one memory, the at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to perform the method according to any one of claims 1 to 9.

9. A method for communication, comprising: Based on the configuration used by the User Equipment (UE) to collect and report data, it is determined to trigger an update of the UE's policy information to include UE routing policy URSP rules, which will be used by the UE to route the data on the Protocol Data Unit (PDU) session on the user plane between the UE and the core network (CN). Based on the decision to trigger the update of the policy information, a request is sent to the Protocol Control PC Network Function (NF) in the CN to perform the update of the policy information of the UE for the PC NF to include the URSP rules; as well as Receive a response to the request from the PC NF, wherein the response indicates whether the update of the policy information has been acknowledged.

10. A device for communication, comprising: At least one processor; as well as At least one memory, the at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the apparatus to perform the method according to claim 9.

Images