UE-driven packet flow description management

Abstract

In some aspects, the disclosure relates to a method for performing packet flow description (PFD) management, the method comprising: establishing, for an application's data flow, a quality of service (QoS) flow between a user equipment (UE) and a core network (CN); creating, by the UE, a UE-requested packet flow description (PFD) when the data flow changes; sending, from the UE to the CN, a request to update a CN PFD to an updated PFD using the UE-requested PFD; receiving, at the UE from the CN, downlink (DL) packets mapped to the QoS flow using the updated PFD.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to wireless data transmission techniques, and to Quality of Service (QoS). BACKGROUND

[0002] Quality of Service (QoS) is a mechanism to control network traffic by priority. Using QoS in networking can optimize the performance of certain applications by allocating bandwidth, latency, bit rate, delay to achieve the expected quality of service. When the network provides QoS for an application and the application creates a data flow, a Protocol Data Unit (PDU) session sets up QoS flows and maps the data flow to the QoS flows. QoS flows provide priority information to different applications, users, or data communications. When the application changes the data flow, the UE and the network update the mapping of the data flow to the QoS flows accordingly to continue the QoS for the application. The mapping can be updated with Packet Flow Description (PFD) management. BRIEF DESCRIPTION OF DRAWINGS

[0003] Figure 1 A block diagram illustrating an architecture of a wireless system including a user equipment (UE) and a core network (CN) is shown.

[0004] Figure 2 A flow diagram illustrating a method for UE-driven packet flow description (PFD) management to update a mapping of a data flow to QoS flows when the data flow changes is shown.

[0005] Figure 3 An exemplary system architecture is shown in accordance with some aspects.

[0006] Figure 4 A flow diagram describing a UE performing UE-driven packet flow description (PFD) management is shown in accordance with some aspects.

[0007] Figure 5 A flow diagram describing a CN performing UE-driven packet flow description (PFD) management is shown in accordance with some aspects.

[0008] Figure 6 FIG. 1 is a diagram illustrating exemplary components of a device that can be employed in accordance with some aspects.

[0009] Figure 7 FIG. 2 is a diagram illustrating exemplary interfaces of a baseband circuit that can be employed in accordance with some aspects. DETAILED DESCRIPTION

[0010] The present disclosure is described with reference to the accompanying drawings. The same reference numbers are used throughout the drawings to refer to like elements. The drawings are not to scale and are provided merely to illustrate the present disclosure. Several aspects of the disclosure are described below with reference to example implementations. Numerous specific details, relationships, and methods are set forth to provide a full understanding of the present disclosure. The present disclosure may, however, be embodied without one or more of the specific details or with other methods. One skilled in the art can readily recognize that the fundamental principles of the present disclosure can be applied to other examples without departing from the scope of the present disclosure.

[0011] A packet flow description (PFD) describes a packet flow for uplink or downlink application traffic by parameters such as protocol, IP, and port numbers. PFD management enables a network to perform accurate application detection to update QoS flows based on received QoS flow information. In some cases, QoS flow information can be pre-configured by the network. In some other cases, QoS flow information can be dynamically created, for example, dynamically assigned per IP address. QoS flow information can also be provided by an external data network (DN), including an application server, to a user plane function (UPF) of the network. However, for enhanced personal security, a service provider (e.g., an application, an application server, or an intermediate node) can provide data directly to a user instead of through a carrier. As a result, a firewall (e.g., network address translation (NAT)) can be set up between the network and the server. This causes a difference in packet addresses between the DN and the network, preventing the DN from providing valid QoS flow information to the network.

[0012] In view of the above, the present disclosure relates to methods for UE-driven PFD management and associated apparatuses. In one aspect, a UE establishes a QoS flow with a core network (CN) for a data flow of an application. When the data flow changes, the UE creates a UE-requested PFD and sends a request to the CN to update a CN PFD to an updated PFD using the UE-requested PFD. Downlink (DL) packets are then transmitted from the CN to the UE based on the updated PFD. By employing a UE-driven PFD management method, PFD updates are obtained from the UE, and thus a firewall between the network and the server does not prevent the network from receiving valid QoS flow information.

[0013] In some additional aspects of the disclosure, uplink (UL) packets of a QoS flow that are transmitted to the CN based on a differentiated services code point (DSCP) marking derived from the updated PFD and received with the DL packet are mapped. In one aspect, the DSCP value of the DSCP marking is provided by or derived from the PFD requested by the UE. The PFD requested by the UE can include the same DSCP value. By using the DSCP marking, the UPF does not need to create reflective QoS packets and also allows more than one data flow to be configured. Employing the DSCP marking can be more beneficial than other alternative methods, such as NAS signaling, or using a reflective QoS indicator (RQI) transmitted with the DL packet to set the QoS rules of the UE subsequently. In using NAS signaling, a NAS payload is added, preventing the CN from updating the PFD frequently. Further, the NAS message cannot provide data flow authentication information to the CN, preventing the CN from identifying the application to which the data flow belongs. In using RQI setting, the UPF of the network needs to inspect the packet flow, such as performing deep packet inspection (DPI) using packet filters, to create reflective QoS packets, which consumes UPF resources and reduces UPF capacity. Further, the packet filters are pre-configured on the UPF, making it difficult to maintain and update. Additionally, by using reflective QoS, the UE needs to support service data adaptation protocol (SDAP), and can allow no more than one data flow to be configured.

[0014] Figure 1 A block diagram illustrating an architecture of a wireless system 100 including a UE 101 and a CN 120, in accordance with some aspects, is shown. The following description is provided in conjunction with the 5G or NR system standards provided by the 3GPP Technical Specifications. However, the example aspects are not limited in this regard and the aspects described can apply to other networks that benefit from the principles described herein, such as other 3GPP systems (e.g., fourth generation (4G) or sixth generation (6G)) systems, IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), etc.

[0015] As Figure 1As shown, the wireless system 100 includes UE 101a and UE 101b (collectively referred to as the “UEs 101”). In this example, UEs 101 are shown as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but can include any mobile or non-mobile computing device, such as consumer electronics devices (including headphones, handheld devices), cellular phones, smartphones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, instrument cluster (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashboard multimedia devices, mobile data terminals (MDTs), electronic engine management systems (EEMS), electronic / engine control units (ECUs), electronic / engine control module (ECM), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or “smart” appliances, machine-type communication (MTC) devices, machine-to-machine (M2M) devices, Internet of Things (IoT) devices, etc.

[0016] The UEs 101 can be configured to connect (e.g., communicatively couple) with a Radio Access Network (RAN) 110. In some aspects, the RAN 110 can be a Next Generation (NG) RAN or 5G RAN, an evolved UMTS Terrestrial Radio Access Network (E-UTRAN), or a legacy RAN, such as a UTRAN or a GERAN. As used herein, the term “NG RAN” or the like can refer to a RAN 110 that operates in an NR or 5G wireless system 100, while the term “E-UTRAN” or the like can refer to a RAN 110 that operates in a Long-Term Evolution (LTE) or 4G system 100. The UEs 101 utilize connections 102 and 104 to communicate with the RAN 110. The connections (or channels) 102 and 104 are illustrated as wired connections to an interface for the implementations, but can represent wireless connections in other implementations. The connections 102 and 104 provide the UEs 101 with access to the services of the RAN 110. In some aspects, the connections 102 and 104 are dedicated physical links between the UEs 101 and the RAN 110. In some aspects, the connections 102 and 104 are shared by the UEs 101 and the RAN 110. In the illustrated aspects, the UEs 101 utilize the connections 102 and 104 to access and exchange data with the core network 106. In some aspects, the UEs 101 can utilize the ProSe interface 105 to directly exchange data with each other.

[0017] The RAN 110 can include one or more RAN nodes that enable the connections 102 and 104, including base stations (BSs) 111a and 111b (collectively referred to as“BSs 111” or“access nodes 111”). As used herein, the term“access node,”“access point” or the like can describe equipment that provides the radio baseband functions for data and / or voice connectivity between a network and one or more users. These BSs can be referred to as access nodes, gNBs, RAN nodes, eNBs, NodeBs, RSUs, transmit receive points (TRxPs), or TRPs, among other examples, and can include ground stations (e.g., land-based access points) or satellite stations providing coverage over a geographic area (e.g., a cell) or region. In various aspects, a BS 111 can be implemented as one or more of a dedicated physical device such as a macrocell base station and / or a low-power (LP) base station configured to provide macrocells, femtocells, or other similar types of cells within a macrocell.

[0018] The RAN 110 is communicatively coupled to the CN 120. The CN 120 is configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UEs 101) who are connected to the CN 120 via the RAN 110. The CN 120 can include a network exposure function (NEF) 122, a session management function (SMF) 124, and a UPF 126.

[0019] A data network (DN) 130 can communicate with the UPF 126 via an interface 127 (e.g., an N6 reference point). In some aspects, the DN 130 includes an application server. In some aspects, the application server of the DN 130 communicates with the UPF 126 via the interface 127. The DN 130 can also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, and the like) for the UEs 101 via the CN 120. In some aspects, the UE 101 derives uplink traffic related information and collects downlink traffic related information from a peer UE or the DN 130, as indicated by arrow 107. For example, the downlink traffic related information can be collected over an application layer protocol. The downlink traffic related information can be per IP flow or per port, and such low power information is not directly accessible by the CN 120. In some aspects, the DN 130 communicates with and / or includes an application function (AF) (not shown) that communicates directly with the CN 120 to provide QoS flow information.

[0020] For a DN 130 or AF that provides QoS flow information (e.g., QoS class identifier (QCI)) to the UPF 126 via the interface 127, the DN 130 must communicate directly with the CN 120. However, a firewall (e.g., network address translation (NAT)) can be set between the CN 120 and the DN 130, resulting in a difference in packet addresses between the DN 130 and the CN 120 and preventing the DN 130 from providing valid QoS flow information to the CN 120. To provide valid QoS flow information to the CN 120, in one aspect, the UE 101 establishes a QoS flow with the CN 120 for an application’s data flow. When the data flow changes, the UE 101 creates a UE-requested PFD and sends a request to the NEF 122 via an interface (e.g., N33 interface) to update the CN PFD to an updated PFD using the UE-requested PFD, as indicated by arrow 106. The NEF 122 first distributes the UE-requested PFD to the SMF 124 via a second interface 123 (e.g., N29 reference point), and the SMF 124 distributes the UE-requested PFD to the UPF 126 via a third interface 125 (e.g., N4 reference point). DL packets mapped to the QoS flow based on the updated PFD are then transmitted from the CN 120 to the UE 101. By employing the UE-driven PFD management method, the firewall between the CN 120 and the DN 130 does not prevent the CN 120 from receiving valid QoS flow information.

[0021] Figure 2 A flow diagram illustrating a method for conducting UE-driven PFD management to update a mapping of data flows to QoS flows when a data flow changes is shown.

[0022] In some aspects, at action 202, a QoS flow between the CN 120 and the UE 101 is established for an application’s data flow within a PDU session. In some aspects, the application can create multiple data flows, and a corresponding number of QoS flows can be established between the CN 120 and the UE 101. In some aspects, the number of data flows created can be greater than the number of QoS flows established.

[0023] In some aspects, at action 204, when the application changes the data flow, the DN 130 can notify the UE 101 of the change in the data flow via an application programming interface (API), or an operating system (OS) of the UE 101 can identify the change in the data flow. In some alternative aspects, the change in the data flow can alternatively or include a refresh of the data flow by an intermediary node, a new data flow added by the application, or a change in the data flow by a server due to load balancing, traffic engineering policies, or the like. In some aspects, the DN 130 communicates with and / or includes an AF (not shown) that notifies the UE 101 of the change in the data flow.

[0024] In some aspects, at act 206, the UE 101 creates a UE-requested PFD. In some aspects, the UE-requested PFD can be a triple of protocol, server-side IP address, and port number. In some aspects, the UE-requested PFD can be different from the CN PFD and can include updated information of the CN PFD. In some aspects, the UE-requested PFD can include a DSCP marking with a DSCP value.

[0025] In some aspects, at act 208, the UE 101 sends, to the NEF 122 via a first interface (e.g., the N33 reference point), a request to update the CN PFD using the UE-requested PFD. In some aspects, the request uses HTTP as the transport layer protocol, and thus the request is an HTTP request. In some aspects, the HTTP request is an HTTP PUT function. In some of such aspects, the UE-requested PFD is a parameter of the HTTP PUT function. In some aspects, upon successfully receiving the HTTP request from the UE 101, the NEF 122 sends an acknowledgement of receipt of the request. In some of these aspects, the acknowledgement is an HTTP 200 response.

[0026] In some aspects, at act 210, the NEF 122 distributes the UE-requested PFD to the UPF 126. In some aspects, upon receiving the UE-requested PFD, the UPF 126 determines whether to accept the UE-requested PFD. If the UE-requested PFD is accepted, the CN PFD is updated to the updated PFD. If the UE-requested PFD is rejected, the CN PFD is maintained.

[0027] In some aspects, at action 212, if the UE-requested PFD is accepted, the UPF 126 transmits DL packets mapped to QoS flows based on the CN PFD or the updated PFD. In some further aspects, the DL packets can include information for reflective QoS for UL packet mapping. In some aspects, the IP header of the DL packets includes the DSCP marking included in or derived from the updated PFD. In one aspect, the DL packets have the same DSCP value as the UE-requested PFD. Alternatively, the DL packets can include RQI settings derived from the updated PFD. However, in using the RQI settings, the UPF 126 needs to inspect the packet flow, such as performing DPI using packet filters, to create reflective QoS packets, which consumes UPF 126 resources and reduces UPF 126 capacity. Further, the packet filters are pre-configured on the UPF 126, making it difficult to maintain and update. Additionally, in using the RQI settings, the UE 101 needs to support SDAP and can allow configuration of no more than one data flow. By instead using the DSCP marking, the UE 101 does not need to support SDAP and thus can allow configuration of multiple data flows. Additionally, the UPF 126 does not use pre-configured packet filters to inspect the packet flow, and thus the UE 101 is able to provide QoS flow information to the CN 120. Further, UPF 126 resources are not consumed and UPF 126 capacity is not reduced. In some aspects, the QoS profile of the UPF 126 is updated based on the UE-requested PFD.

[0028] In some aspects, at action 214, after receiving the DL packets from the UPF 126, the UE 101 uses the information of the DL packets to configure or derive the mapping of UL packets. In some aspects, the QoS rules of the UE 101 are updated with the updated PFD based on the received DSCP marking or RQI settings. In some aspects, the UE 101 further updates the packet filters based on the received DL packets. By employing the UE-driven PFD management method, the QoS rules are updated without the CN 120 and the DN 130 directly communicating, and thus the firewall does not block the QoS flow updates.

[0029] In some aspects, at action 216, the UE 101 transmits UL packets mapped to QoS flows using the updated QoS rules and / or the updated PFD to the UPF 126. By employing the UE-driven PFD management method, the UE 101 is able to update the QoS flows between the UE 101 and the CN 120 for the UL packets, thus the firewall between the CN 120 and the DN 130 does not block the CN 120 from receiving valid QoS flow information. In some aspects, multiple updated PFDs are used to map the UL packets to multiple QoS flows.

[0030] Figure 3 An example system architecture 300 is shown in accordance with some aspects. The system 300 is shown to include a UE 101; a (R)AN 110, and the (R)AN can include the RAN node 111 discussed previously, a first DN 130, and a second DN 304, which can be, for example, application servers, operator services, Internet access, or 3rd party services; an AF 308; and a CN 120. In some aspects, the CN 120 can be a 5G core network (e.g., 5GC). The CN 120 can include an Authentication Server Function (AUSF) 314, an Access and Mobility Management Function (AMF) 312, a first SMF 124, a second SMF 306, a NEF 122, a Network Slice Selection Function (NSSF) 318, a Policy Control Function (PCF) 316, a Unified Data Management (UDM) 310, a first UPF 126, and a second UPF 302.

[0031] The NEF 122 can provide means for securely exposing services and capabilities offered by 3 GPP network functions to third parties, internal exposure / re- exposure, application functions (e.g., AF 308), edge computing or fog computing systems, and the like. In such aspects, the NEF 122 can authenticate, authorize, and / or throttle an AF. The NEF 122 can also translate information exchanged with the AF 308 and information exchanged with internal network functions. For example, the NEF 122 can translate between an AF service identifier and an internal 5GC information. The NEF 122 can also receive information from other network functions (NFs) based on exposure capabilities of other network functions. This information can be stored at the NEF 122 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 122 to other NFs and AFs, and / or used for other purposes such as analytics. Additionally, the NEF 122 can exhibit an Nnef service-based interface.

[0032] The NEF 122 can interact directly with the UE 101 via an N33 interface 106. In some aspects, the UE 101 can send a request including a UE requested PFD to the NEF 122 via the N33 interface, as described with respect to FIG. 3B. Figure 2 The NEF 122 can interact with the first SMF 124 via an N29 interface. In some aspects, the NEF 122 can distribute the UE requested PFD to the first SMF 124 via the N29 interface.

[0033] The first UPF 126 and the second UPF 302 can act as an anchor point for intra- and inter-RAT mobility, an external PDU session point of interconnection to the DN 130 and the DN 304, respectively, and a branching point for multi-homed PDU sessions. The first UPF 126 and the second UPF 302 can also perform packet routing and forwarding, perform packet inspection, enforce user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, enforce QoS for user plane (e.g., packet filtering, gating, UL / DL bitrate enforcement), perform Uplink Traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in uplink and in downlink, and perform downlink packet buffering and downlink data notification triggering. The first UPF 126 and the second UPF 302 can include an uplink classifier to support routing traffic flows to a data network.

[0034] The first DN 130 and the second DN 304 can represent various network operator services, Internet access, or third party services. The first DN 130 and the second DN 304 can include application servers. The first UPF 126 can interact with the first SMF 124 via a first N4 reference point between the first SMF 124 and the first UPF 126. The second UPF 302 can interact with the second SMF 306 via a second N4 reference point between the second UPF 302 and the second SMF 306. In some aspects, the first SMF 124 can distribute a UE requested PFD to the first UPF 126 via the N4 reference point. In some aspects, the first UPF 126 includes a CN PFD and determines whether to accept the UE requested PFD, and upon accepting the UE requested PFD, the first UPF 126 updates the CN PFD to an updated PFD using the UE requested PFD. In some aspects, the first UPF 126 sends a DL packet with a DSCP marking if there is one or more QoS flows in the UE requested PFD. In some aspects, the first UPF 126 sends a DL packet with an RQI setting if there is a single QoS flow in the UE requested PFD. In some aspects, the first DN 130 is external to the CN 120. In some aspects, the first DN 130 communicates with and / or includes the AF 308.

[0035] AF 308 can provide application influence on traffic routing, provide access to NCEs, and interact with the policy framework for policy control. The NCEs can be a mechanism that allows 5GC 120 and AFs 308 to provide information to each other via the NEF 122, which can be used for edge computing implementations. In such implementations, network operators and third-party services can be hosted close to the UE 101 access points to enable efficient service delivery with reduced end-to-end latency and load on the transport network. For edge computing

[0036] The AUSF 314 can store data for authentication of UE 101 and handle authentication-related functionality. The AUSF 314 can facilitate a common authentication framework for various access types. The AUSF 314 can communicate with the AMF 312 via an N12 reference point between the AMF 312 and the AUSF 314, and can communicate with the UDM 310 via an N13 reference point between the UDM 310 and the AUSF 314. Additionally, the AUSF 314 can exhibit an Nausf service-based interface.

[0037] AMF 312 can be responsible for registration management (e.g., registering UE 101, etc.), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. AMF 312 can be the termination point of the N11 reference point between AMF 312 and the first SMF 124, and between AMF 312 and the second SMF 306. AMF 312 can provide delivery of SM messages between UE 101 and the first SMF 124, and between UE 101 and the second SMF 306, and acts as a transparent proxy for routing SM messages. AMF 312 can also provide delivery of SM messages between UE 101 and the Short Message Service Function (SMSF). Figure 3 SMS messages are delivered between (not shown). AMF 312 can act as a Security Anchor Function (SEAF), which may include the reception of an intermediate key established due to the UE 101 authentication process, in the case of authentication using the Universal User Identity Module (UMTS). AMF 312 may retrieve security material from AUSF 314. AMF 312 may also include an SCM function that receives a key from SEA for deriving a network-specific key for access. Furthermore, AMF 312 may be the termination point of the RAN Control Plane (CP) interface, which may include or may be the N2 reference point between (R)AN 110 and AMF 312, and AMF 312 may be the termination point of NAS (N1) signaling, performing NAS encryption and integrity protection.

[0038] AMF 312 can also support NAS signaling with UE 101 via a non-3GPP (N3) Interoperability Function (IWF) interface. The N3IWF can be used to provide access to untrusted entities. The N3IWF can be the termination point of the N2 interface between (R)AN 110 and AMF 312 for the control plane, and can be the termination point of the N3 reference point between (R)AN 110 and the first UPF 126 for the user plane, and between (R)AN 110 and the second UPF 302. Therefore, AMF 312 can process N2 signaling from SMF 624 and AMF 312 for PDU sessions and QoS, encapsulate / decapsulate packets for IPSec and N3 tunneling, mark N3 user plane packets in the uplink, and implement QoS corresponding to the marking of N3 packets received via N2, taking into account the QoS requirements associated with such marking. The N3IWF can also relay uplink and downlink control plane NAS signaling between UE 101 and AMF 312 via the N1 reference point between UE 101 and AMF 312, and relay uplink and downlink user plane packets between UE 101 and the first UPF 126, and between UE 101 and the second UPF 302. The N3IWF also provides a mechanism for establishing IPsec tunnels using UE 101. AMF 312 can present an interface based on Namf services and can be the N14 reference point between two AMF 312s and the 5G-EIR ( Figure 6 The endpoint of the N17 reference point (not shown).

[0039] The UE 101 can need to register with the AMF 312 in order to receive network services. RM is used to register or deregister the UE 101 with the network (e.g., AMF 312) and establish a UE context in the network (e.g., AMF 312). The UE 101 can operate in an RM-REGISTERED state or an RM-DEREGISTERED state. In the RM-DEREGISTERED state, the UE 101 is not registered to the network, and the UE context in AMF 312 holds no valid location or routing information for the UE 101 so the AMF 312 cannot reach the UE 101. In the RM-REGISTERED state, the UE 101 is registered to the network, and the UE context in AMF 312 can hold a valid location or routing information for the UE 101 so the AMF 312 can reach the UE 101. In the RM-REGISTERED state, the UE 101 can perform mobility registration update procedures, perform periodic registration update procedures triggered by expiration of a periodic update timer (e.g., to notify the network that the UE 101 remains active), and perform a registration update procedure to update UE capability information or to re-negotiate protocol parameters with the network, among other examples.

[0040] The AMF 312 can store one or more RM contexts for the UE 101, where each RM context is associated with a specific access to the network. The RM context can be a data structure, database object, or the like, that indicates or stores, among other things, a registration state per access type and a periodic update timer. The AMF 312 can also store a 5GC MM context that can be the same as or similar to the (E)MM context previously discussed. In various aspects, the AMF 312 can store a common emitter (CE) mode B restriction parameter for the UE 101 in an associated MM context or RM context. The AMF 312 can also derive a value, when needed, from a UE’s usage setting parameter already stored in the UE context (and / or MM / RM context).

[0041] Connection Management (CM) can be used for establishment and release of a signaling connection between the UE 101 and the AMF 312 over the N1 interface. The signaling connection is used for implementation of NAS signaling exchange between the UE 101 and the CN 120 and includes signaling connection between the UE and the AN (e.g., RRC connection or UE-N3IWF connection for non-3GPP access) and the N2 connection between the UE 101 and the AMF 312 by the AN (e.g., RAN 110). The UE 101 can operate in one of two CM states (CM-IDLE mode or CM-CONNECTED mode). When the UE 101 is operating in the CM-IDLE state mode, the UE 101 can not have NAS signaling connection established with the AMF 312 over the N1 interface, and there can be a (R)AN 110 signaling connection (e.g., N2 and / or N3 connection) for the UE 101. When the UE 101 is operating in the CM-CONNECTED state mode, the UE 101 can have a NAS signaling connection established with the AMF 312 over the N1 interface, and there can be a (R)AN 110 signaling connection (e.g., N2 and / or N3 connection) for the UE 101. Establishment of an N2 connection between the (R)AN 110 and the AMF 312 can cause the UE 101 to transition from the CM-IDLE mode to the CM-CONNECTED mode, and the UE 101 can transition from the CM-CONNECTED mode to the CM-IDLE mode when the N2 signaling between the (R)AN 110 and the AMF 312 is released.

[0042] The first SMF 124 and the second SMF 306 can be responsible for SM (e.g., session establishment, modify, and release, including tunnel maintain between UPF and AN node); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at the UPF to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF over N2, to AN; and determining SSC mode of a session. SM can refer to management of a PDU session, and a PDU session or “session” can refer to a PDU connectivity service that provides or enables exchange of PDUs between a UE 101 and a first DN 130 and between the UE 101 and a second DN 304, identified by a data network name (DNN). A PDU session can be established upon a request by the UE 101 using NAS SM signaling exchanged over an N1 reference point between the UE 101 and the SMF 124, modified upon a request by the UE 101 and the 5GC 120, and released upon a request by the UE 101 and the CN 120. Upon a request from an application server, the CN 120 can trigger a specific application in the UE 101. In response to receiving the trigger message, the UE 101 can pass the trigger message (or relevant parts / information of the trigger message) to one or more identified applications in the UE 101. The identified application(s) in the UE 101 can establish a PDU session to a specific DNN. The first SMF 124 and / or the second SMF 306 can check whether the UE 101 requests are compliant with user subscription information associated with the UE 101. In this regard, the first SMF 124 and / or the second SMF 306 can retrieve and / or request to receive update notifications about first SMF 124 and / or second SMF 306 level subscription data from the UDM 310.

[0043] The first SMF 124 and / or the second SMF 306 can include the following roaming functionality: handling local enforcement to apply QoS SLAs (VPLMN); charging data collection and charging interface (VPLMN); lawful intercept (for SM events and interface to LI system, in VPLMN); and support for interaction with external DN to transfer signaling for PDU session authorization / authentication by external DN. In addition, the first SMF 124 and / or the second SMF 306 can exhibit an Nsmf service based interface.

[0044] The PCF 316 can provide control plane functions to implement their policy rules, and can also support unified policy framework for managing network behavior. The PCF 316 can also implement an FE to access subscription information relevant for policy decisions in the UDR of UDM 310. The PCF 316 can communicate with the AMF 312 via an N15 reference point between the PCF 316 and the AMF 312, which can include a PCF 316 in a visited network and the AMF 312 in case of roaming scenarios. The PCF 316 can communicate with the AF 308 via an N5 reference point between the PCF 316 and the AF 308; and with the first SMF 124 and the second SMF 306 via an N7 reference point between the PCF 316 and the first SMF 124 and the PCF 316 and the second SMF 306. The system 300 and / or the CN 120 can also include an N24 reference point between the (home network) PCF 316 and the PCF 316 in a visited network. Additionally, the PCF 316 can exhibit an Npcf service-based interface.

[0045] In some aspects, a firewall (e.g., network address translation (NAT)) can be disposed at the N5 reference point between the PCF 316 and the AF 308, at the N6 reference point between the first UPF 126 and the first DN 130, and at the N6 reference point between the second UPF 302 and the second DN 304. This results in a difference in packet addresses between the AF 308 and the CN 120, the first DN 130 and the CN 120, and the second DN 304 and the CN 120. This prevents the AF 308, the first DN 130, and the second DN 304 from providing valid QoS flow information to the CN 120. Thus, by performing UE-driven PFD management, the QoS flow information can be provided by the UE 101, and thus the firewall does not prevent the information from being provided to the CN 120.

[0046] The UDM 310 can handle subscription-related information to support the handling of communication sessions by network entities, and can store subscription data for the UE 101. For example, subscription data can be conveyed between the UDM 310 and the AMF 312 via an N8 reference point between the UDM 310 and the AMF. The UDM 310 can include two parts: an application FE and a UDR Figure 3(FE and UDR are not shown). The UDR may store subscription data and policy data of UDM 310 and PCF 316, and / or structured data for exposure of NEF 122, as well as application data (including PFD for application detection, application request information of multiple UEs 101). The UDM may include UDM-FE, which is responsible for handling credentials, location management, subscription management, etc. Several different front-ends may serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration / mobility management, and subscription management. The UDR may interact with the first SMF 124 and / or the second SMF 306 via the N10 reference point between UDM 310 and the first SMF 124 and between UDM 310 and the second SMF 306. UDM 310 may also support SMS management, where SMS-FE implements similar application logic as previously discussed. In addition, UDM 310 may present an interface based on Nudm services.

[0047] NSSF 318 can select a set of network slice instances to serve UE 101. If needed, NSSF 318 can also determine the allowed network slice selection assistance information (NSSAI) and the mapping to the subscribed individual NSSAI (S-NSSAI). The selection of a set of network slice instances for UE 101 can be triggered by AMF 312, where UE 101 registers by interacting with NSSF 318, which can cause AMF 312 to change. NSSF 318 can interact with AMF 312 via the N22 reference point between AMF 312 and NSSF 312; and via the N31 reference point (…). Figure 3 (Not shown) Communicates with another NSSF 318 in the visited network. Additionally, the NSSF 318 may present an interface based on the Nnssf service.

[0048] As previously discussed, CN 120 may include an SMSF responsible for SMS subscription checks and authentication, as well as relaying SM messages to / from UE 101 to / from other entities such as SMS-GMSC / IWMSC / SMS routers. SMS may also interact with AMF 312 and UDM 310 to provide notification procedures for when UE 101 is available for SMS delivery (e.g., setting a UE unreachable flag and notifying UDM 310 when UE 101 is available for SMS).

[0049] CN 120 may also include Figure 3Other elements not shown include data storage systems / architecture, 5G-EIR, SEPP, etc. Data storage systems may include SDSF, UDSF, etc. Any NF can be transmitted via any NF and UDSF ( Figure 3 The N18 reference points (not shown) between NFs store unstructured data in or retrieve it from the UDSF (e.g., UE context). Individual NFs may share a UDSF for storing their respective unstructured data, or each NF may have its own UDSF located at or near the individual NF. Additionally, the UDSF may present an interface based on the Nudsf service (…). Figure 3 (Not shown). 5G-EIR can be an NF that checks the status of PEI to determine whether to blacklist a specific device / entity from the network; and SEPP can be a non-transparent agent that performs topology hiding, message filtering, and policing on the control plane interface between PLMNs.

[0050] Furthermore, there can be more reference points and / or service-based interfaces between NF services; however, for clarity, Figure 3 These interfaces and reference points have been omitted. Other example interfaces / reference points may include the interface presented by 5G-EIR based on N5g-EIR services, the N27 reference point between the NRF in the visited network and the NRF in the home network; and the N31 reference point between the NSSF in the visited network and the NSSF in the home network.

[0051] Figure 4 A flowchart is shown that describes the UE-driven Packet Flow Description (PFD) management performed by the UE based on some aspects.

[0052] As shown in Action 402, the UE establishes one or more QoS flows with the CN when the application creates a data flow. In some aspects, the UE can establish one or more QoS flows within a PDU session.

[0053] As indicated by action 404, the UE creates a UE-requested PFD when the data flow changes. In some aspects, the UE-requested PFD may include update information. In some aspects, if the UE establishes more than one QoS flow, the UE-requested PFD may include DSCP.

[0054] As shown in Action 406, the UE sends a request to the CN to update the CN PFD using the PFD requested by the UE. In some cases, the UE sends the request to the CN's NEF via the N33 interface. In other cases, the request is an HTTP request.

[0055] As shown in act 408, the UE receives DL packets mapped to a QoS flow using the updated PFD with a DSCP marking. In some aspects, the UE requested PFD can have a DSCP marking with the same DSCP value as the DSCP marking of the DL packets. Alternatively, in some aspects, the DL packets can have an RQI setting instead of a DSCP marking.

[0056] As shown in act 410, the UE transmits UL packets mapped to a QoS flow using the updated PFD based on the received DSCP marking. Alternatively, in some aspects, the UL packets can be mapped to a QoS flow using the updated PFD based on the received RQI setting. In other alternative aspects, instead of being mapped to a QoS flow based on a DSCP marking or RQI setting, the UL packets can be mapped to a QoS flow using NAS signaling.

[0057] Figure 5 A flow diagram illustrating CN performing UE-driven packet flow description (PFD) management is shown in accordance with some aspects.

[0058] As shown in act 502, the CN establishes one or more QoS flows with the UE when the data flow is created by the application. In some aspects, the UE can establish one or more QoS flows in a PDU session.

[0059] As shown in act 504, in some aspects, the CN receives a request from the UE at the NEF requesting an update to the CN PFD, the request including a UE requested PFD. In some aspects, the UE receives the request over an N33 interface. In some aspects, the request is an HTTP request.

[0060] As shown in act 506, the CN distributes the UE requested PFD from the NEF to the UPF. In some aspects, the NEF distributes the UE requested PFD to the SMF via an N29 interface, and the SMF distributes the UE requested PFD to the UPF via an N4 interface.

[0061] As shown in act 508, the CN determines whether to accept the UE requested PFD. In some aspects, the CN can determine whether to accept the UE requested PFD based on information included in the UE requested PFD. In some aspects, the CN can determine whether to accept the UE requested PFD based on data that is only available to the CN. In some aspects, a QoS profile of the UPF is updated based on the UE requested PFD.

[0062] As shown in act 510, if the CN determines not to accept the UE requested PFD, the CN PFD is maintained. In some aspects, the CN sends a message (e.g., an HTTP response) informing the UE that the UE requested PFD was rejected.

[0063] As shown in act 512, if the CN determines to accept the UE requested PFD, the CN PFD is updated to the updated PFD. In some aspects, the updated PFD is based on the update information provided by the UE requested PFD. In some aspects, the updated PFD is different from both the UE requested PFD and the CN PFD.

[0064] As shown in act 514, in some aspects, the CN transmits DL packets to the UE using the updated PFD mapped to QoS flows. In some further aspects, the DL packets are transmitted with a DSCP marking. Alternatively, in some aspects, the DL packets can have an RQI setting instead of a DSCP marking.

[0065] As shown in act 516, the CN receives UL packets mapped to multiple QoS flows based on the transmitted DSCP. Alternatively, in some aspects, the UL packets can be mapped to QoS flows using the updated PFD based on a received RQI setting. In other alternative aspects, instead of being mapped to QoS flows based on a DSCP marking or RQI setting, the UL packets can be mapped to QoS flows using NAS signaling.

[0066] Figure 6 FIG. 6 is a diagram illustrating exemplary components for a device 600 that can be employed within a system according to some aspects. In some implementations, the device 600 can include application circuitry 602, baseband circuitry 604, Radio Frequency (RF) circuitry 606, front-end module (FEM) circuitry 608, one or more antennas 610, and power management circuitry (PMC) 612 coupled together as shown in the figure. The components of the device 600 can include, for example, one or more processors and / or other components of the device 600. The components of the device 600 can be included in a UE or a RAN node. In some implementations, the device 600 can include fewer elements (e.g., a RAN node can not utilize application circuitry 602, and instead include a processor / controller to process IP data received from a CN). In some implementations, the device 600 can include additional elements such as, for example, memory / storage, displays, cameras, sensors (including one or more temperature sensors, such as a single temperature sensor located in different places in the device 600, multiple temperature sensors, etc.), or input / output (I / O) interfaces. In other implementations, the components described below can be included in multiple devices (e.g., the

[0067] The application circuitry 602 can include one or more application processors. For example, the application circuitry 602 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors can include general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors can be coupled with, or include, memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on the device 600. In some implementations, the processors of the application circuitry 602 can process IP data packets received from an Evolved Packet Core (EPC).

[0068] The baseband circuitry 604 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 604 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 606 and to generate baseband signals for a transmit signal path of the RF circuitry 606. The baseband circuitry 604 can interface with the application circuitry 602 for generation and processing of the baseband signals and for control of the RF circuitry 606. For example, in some implementations, the baseband circuitry 604 can include third generation (3G) baseband processor 604A, fourth generation (4G) baseband processor 604B, fifth generation (5G) baseband processor 604C, or other baseband processor(s) 604D for other existing generations, generations in development or future generations of communication protocols (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 604 (e.g., one or more of baseband processors 604A-D) can handle various radio control functions

[0069] In some implementations, the baseband circuitry 604 can include one or more audio digital signal processors (DSP) 604F. The audio DSP(s) 604F can be incorporated in a speaker 604B. The audio DSP(s) 604F can be used for digital sound processing, such as for speaker and / or microphone

[0070] In some implementations, the baseband circuitry 604 can provide communication compatible with one or more radio technologies. For example, in some implementations, the baseband circuitry 604 can support communication with a NG-RAN, an evolved universal terrestrial radio access network (EUTRAN), or other wireless metropolitan area networks (WMANs), wireless local area networks (WLANs), wireless personal area networks (WPANs), and so on. Implementations of the baseband circuitry 604 configured to support wireless communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

[0071] The RF circuitry 606 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various implementations, the RF circuitry 606 can include switches, filters, amplifiers, etc. to facilitate the communication with wireless networks. RF circuitry 606 can include a receive signal path, which can include circuitry to down-convert and amplify the received signal and provide the baseband circuitry 604 with baseband signals. RF circuitry 606 can also include a transmit signal path, which can include circuitry to up-convert and amplify the baseband signals provided by the baseband circuitry 604 and provide the FEM circuitry 608 with RF output signals for transmission.

[0072] In some implementations, the receive signal path of the RF circuitry 606 can include mixer circuitry 606a, amplifier circuitry 606b and filter circuitry 606c. In some implementations, the transmit signal path of the RF circuitry 606 can include filter circuitry 606c and mixer circuitry 606a. The RF circuitry 606 can also include synthesizer circuitry 606d for synthesizing a frequency for use by the mixer circuitry 606a of the receive signal path and the transmit signal path. In some implementations, the mixer circuitry 606a of the receive signal path can be configured to down-convert RF signals received from the FEM circuitry 608 based on the synthesized frequency provided by synthesizer circuitry 606d. The amplifier circuitry 606b can be configured to amplify the down-converted signals, and the filter circuitry 606c can be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals can be provided to the baseband circuitry 604 for further processing. In some implementations, the output baseband signals can be zero-frequency baseband signals, although this is not a requirement. In some implementations, the mixer circuitry 606a of the receive signal path can include passive mixers, although the scope of the implementations is not limited in this respect.

[0073] In some implementations, the mixer circuitry 606a of the transmit signal path can be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 606d to generate RF output signals for the FEM circuitry 608. The baseband signals can be provided by the baseband circuitry 604 and can be filtered by filter circuitry 606c.

[0074] In some implementations, the mixer circuitry 606a of the receive signal path and the mixer circuitry 606a of the transmit signal path can include two or more mixers and can be arranged for quadrature downconversion and upconversion, respectively. In some implementations, the mixer circuitry 606a of the receive signal path and the mixer circuitry 606a of the transmit signal path can include two or more mixers and can be arranged for image rejection (e.g., Hartley image rejection). In some implementations, the mixer circuitry 606a of the receive signal path and the mixer circuitry 606a of the transmit signal path can be arranged for direct downconversion and direct upconversion, respectively. In some implementations, the mixer circuitry 606a of the receive signal path and the mixer circuitry 606a of the transmit signal path can be configured for superheterodyne operation.

[0075] In some implementations, the output baseband signals and the input baseband signals can be analog baseband signals, although the scope of the implementations is not limited in this respect. In some alternative implementations, the output baseband signals and the input baseband signals can be digital baseband signals. In these alternative implementations, the RF circuitry 606 can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 604 can include a digital baseband interface to communicate with the RF circuitry 606.

[0076] In some dual-mode implementations, separate radio ICs can be provided to process the signals for each spectrum, although the scope of the implementations is not limited in this respect.

[0077] In some implementations, the synthesizer circuitry 606d can be a fractional-N synthesizer or a fractional N / N+1 synthesizer, although the scope of the implementations is not limited in this respect as other types of frequency synthesizers can be suitable. For example, synthesizer circuitry 606d can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer that includes a phase-locked loop with a frequency divider.

[0078] The synthesizer circuitry 606d can be configured to synthesize an output frequency for use by the mixer circuitry 606a of the RF circuitry 606 based on a frequency input and a divider control input. In some implementations, synthesizer circuitry 606d can be a fractional N / N+1 synthesizer.

[0079] In some implementations, the frequency input can be provided by a voltage controlled oscillator (VCO), although this is not a requirement. The divider control input can be provided by the baseband circuitry 604 or the application circuitry 602 as required for the output frequency. In some implementations, the divider control input (e.g., N) can be determined from a look-up table based on a channel indicated by the application circuitry 602.

[0080] The synthesizer circuitry 606d of the RF circuitry 606 can include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some implementations, the divider can be a dual modulus divider (DMD) and the phase accumulator can be a digital phase accumulator (DPA). In some implementations, the DMD can be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example implementations, the DLL can include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these implementations, the delay elements can be configured to divide the VCO period into Nd equal phase segments, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help assure that the total delay through the delay line is one VCO cycle.

[0081] In some implementations, synthesizer circuitry 606d can be configured to generate a carrier frequency as the output frequency, while in other implementations, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some implementations, the output frequency can be a LO frequency (fLO). In some implementations, the RF circuitry 606 can include an IQ / polar converter.

[0082] FEM circuitry 608 can include a receive signal path, which can include circuitry configured to operate on RF signals received from one or more antennas 656, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 606 for further processing. FEM circuitry 608 can also include a transmit signal path, which can include circuitry configured to amplify signals for transmission provided by the RF circuitry 606 as well as to filter out unwanted signals from the amplified versions of the signals for transmission. In various implementations, the amplification through the transmit or receive signal paths can be done solely in the RF circuitry 606, solely in the FEM circuitry 608, or in both the RF circuitry 606 and the FEM circuitry 608.

[0083] In some implementations, the FEM circuitry 608 can include a TX / RX switch, to switch between transmit mode and receive mode operation. The FEM circuitry can include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry can include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 606). The transmit signal path of the FEM circuitry 608 can include a power amplifier (PA) to amplify signals for transmission provided by the RF circuitry 606, as well as one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 656).

[0084] In some implementations, the PMC 612 can manage power provided to the baseband circuitry 604. In particular, the PMC 612 can control power selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 612 can also

[0085] Although Figure 6The PMC 612 is shown coupled only to the baseband circuitry 604. However, in other implementations, the PMC 612 can be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, the application circuitry 602, the RF circuitry 606, or the FEM 608.

[0086] In some implementations, the PMC 612 can control, or otherwise be part of, various power-saving mechanisms of the device 600. For example, if the device 600 is in an RRC_Connected state, where it expects to receive traffic shortly, after a period of inactivity, it can transition to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. While in this state, the device 600 can power down for extended periods of time, thus saving power. To receive traffic, the device 600 can transition back to the RRC_Connected state.

[0087] If there is no data traffic activity for an extended period of time, the device 600 can transition into an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 600 enters a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. While in this state, the device 600 can not receive data; to receive data, it can transition back to an RRC_Connected state.

[0088] An additional power saving mechanism is "deep sleep" or "idle mode DRX", in which the device 600 can enter a very low power state for long periods where it does not monitor any downlink communication from the network. In some implementations, the device 600 can also enter this state after it has completed any currently running background applications and has made any previously promised data transfers.

[0089] The processors of the application circuitry 602 and the processors of the baseband circuitry 604 can be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 604 can be used to execute layer 3, layer 2, or layer 1 functions individually or collectively, while the processors of the baseband circuitry 604 can utilize data (e.g., packet data) received from these layers and further execute layer 4 functions (e.g., transport communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, layer 3 can include a radio resource control (RRC) layer, described in further detail below. As referred to herein, layer 2 can include a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, layer 1 can include a physical (PHY) layer of a UE / RAN node, described in further detail below.

[0090] Figure 7is an illustration of an example interface of baseband circuitry that can be employed in accordance with some aspects. As discussed above, Figure 6 The baseband circuitry 604 can include processors 604A-604E and memory 604G utilized by the processors. Each of the processors 604A-604E can include a memory interface 704A-704E for sending / receiving data to / from the memory 604G, respectively.

[0091] The baseband circuitry 604 can also include one or more interfaces, such as a memory interface 712 (e.g., an interface to send / receive data to / from memory external to the baseband circuitry 604), an application circuitry interface 714 (e.g., an interface to send / receive data to / from the application circuitry 602), an RF circuitry interface 716 (e.g., an interface to send / receive data to / from the RF circuitry 606), a wireless hardware connectivity interface 718, and a power management interface 720 (e.g., an interface to send / receive power or control signals to / from the PMC 612). Figure 6 Figure 6 The baseband circuitry 604 can further include one or more interfaces, such as a memory interface 712 (e.g., an interface to send / receive data to / from memory external to the baseband circuitry 604), an application circuitry interface 714 (e.g., an interface to send / receive data to / from

[0092] While the methods described by the present disclosure are illustrated and described herein as a series of acts or events, it will be understood that the illustrated ordering of such acts or events should not be construed as a requirement, and that one or more of the acts or events can occur in different order, concurrently, or be omitted altogether. Further, not all illustrated acts or events can be required to implement one or more aspects of the specification. Additionally, one or more of the acts or events depicted herein can be carried out in one or more separate acts or phases. For ease of illustration, reference can be made to the above-described figures. The methods, however, are not limited to any particular aspect, feature, or example provided within this disclosure, and can be applied to any of the systems / devices / components disclosed herein.

[0093] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled in a way to minimize risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0094] ​As employed in this specification, the term "processor" can refer generally to any computing processing unit or device, including without limitation a single-core processor; a multi-core processor; a single processor with software multithread execution capability; a multi-processor system; a multiple-instruction set computer (MISC) with software multithread execution capability; a parallel computer; and a parallel computer with distributed shared memory. Additionally, a processor can refer to integrated circuits, application specific integrated circuits, digital signal processors, field programmable gate arrays, programmable logic controllers, complex programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions and / or processes described herein. A processor can utilize nano- scale architectures such as, but not limited to, molecular and quantum-dot based transistors, switches and gates, in order to optimize space usage or enhance performance of mobile devices. A processor can also be implemented as a combination of computing processing units.

[0095] Additional Embodiments

[0096] Examples herein can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including executable instructions that, when performed by a machine (e.g., a processor with memory (e.g., a processor), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or the like) cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to aspects and examples described.

[0097] Embodiment 1 is a baseband processor of a user equipment (UE) configured to perform operations comprising: establishing a quality of service (QoS) flow with a core network (CN) for an application's data flow; creating a packet flow description (PFD) requested by the UE when the data flow changes; sending a request to the CN to update a CN PFD to an updated PFD using the PFD requested by the UE; and receiving downlink (DL) packets mapped to the QoS flow using the updated PFD.

[0098] Embodiment 2 includes the subject matter of any variation of any of the embodiments of embodiment 1, wherein the DL packets are received with a differentiated services code point (DSCP) marking derived from the updated PFD, and wherein uplink (UL) packets mapped to the QoS flow based on the DSCP marking are transmitted to the CN.

[0099] Embodiment 3 includes the subject matter of any variation of any of the embodiments of embodiment 2, wherein the DSCP marking is provided by the PFD requested by the UE.

[0100] Example 4 includes the subject matter of any variation of any of Examples 2 or 3, wherein the UL packet is mapped to the plurality of QoS flows using a plurality of updated PFDs.

[0101] Example 5 includes the subject matter of any variation of any of Examples 2, 3, or 4, further comprising updating the QoS rules based on the DSCP marking after receiving the DL packet, wherein the UL packet is mapped to the QoS flow using the updated QoS rules.

[0102] Example 6 includes the subject matter of any variation of any of Examples 1, wherein the DL packet is received with a reflective QoS indicator (RQI) setting derived from the updated PFD, and wherein an uplink (UL) packet mapped to the QoS flow based on the derived RQI setting is transmitted to the CN.

[0103] Example 7 includes the subject matter of any variation of any of Examples 1-6, wherein the request uses hypertext transfer protocol (HTTP) as a transport layer protocol.

[0104] Example 8 includes the subject matter of any variation of any of Examples 1-7, wherein the request is sent to a network exposure function (NEF) of the CN via an N33 reference point.

[0105] Example 9 includes the subject matter of any variation of any of Examples 1-8, wherein the change to the data flow is notified by an application from an API.

[0106] Example 10 includes the subject matter of any variation of any of Examples 1-8, wherein the change to the data flow is identified by the UE.

[0107] Example 11 is a network entity configured to perform operations comprising: establishing a quality of service (QoS) flow with a user equipment (UE) for a data flow of an application; receiving, at a network exposure function (NEF), a request from the UE to request an update to a core network (CN) packet flow description (PFD) upon a change to the data flow, the request including a UE requested PFD; distributing the UE requested PFD from the NEF to a user plane function (UPF); determining whether to accept the UE requested PFD, and if the UE requested PFD is accepted, updating the CN PFD to an updated PFD using the UE requested PFD; transmitting a downlink (DL) packet with a differentiated services code point (DSCP) if there are multiple QoS flows in the UE requested PFD, or a reflective QoS indicator (RQI) setting if there is a single QoS flow in the UE requested PFD; and receiving an uplink (UL) packet mapped to the QoS flow using the updated PFD, the updated PFD based on the DSCP or the RQI setting.

[0108] Example 12 includes the subject matter of any variation of any of the examples of 11, wherein distributing the UE requested PFD from the NEF to the UPF comprises distributing the UE requested PFD from the NEF to a session management function (SMF), and distributing the UE requested PFD from the SMF to the UPF.

[0109] Example 13 includes the subject matter of any variation of any of the examples of 11 or 12, wherein the request is received at the NEF over an N33 reference point.

[0110] Example 14 includes the subject matter of any variation of any of the examples of 11-13, wherein the request uses hypertext transfer protocol (HTTP) as a transport layer protocol.

[0111] Example 15 includes the subject matter of any variation of any of the examples of 11-14, wherein the UL packet is mapped to multiple QoS flows using multiple updated PFDs.

[0112] Example 16 is a method for packet flow description (PFD) management, the method comprising: establishing a first quality of service (QoS) flow between a user equipment (UE) and a core network (CN) within a protocol data unit (PDU) session upon creation of a first data flow by a first application; creating, by the UE, a first UE requested packet flow description (PFD) upon a change in the first data flow, the first UE requested PFD comprising update information; sending, from the UE to a network exposure function (NEF) of the CN, a request for an update of the CN PFD, the request comprising the first UE requested PFD; distributing the first UE requested PFD from the NEF to a user plane function (UPF); receiving, by the UE from the CN, a downlink (DL) packet with a differentiated services code point (DSCP) or a reflective QoS indicator (RQI) setting; updating QoS rules of the UE based on the DSCP or RQI setting; and transmitting, from the UE to the CN, an uplink (UL) packet using a first updated PFD mapped to the first QoS flow, the first updated PFD created based on the DSCP or RQI setting.

[0113] Example 17 includes the subject matter of any of Example 16, further comprising: establishing a second QoS flow between the UE and the CN within the PDU session upon creation of a second data flow by a second application; creating, by the UE, a second UE requested PFD upon a change in the second data flow, the second UE requested PFD comprising update information, wherein the UL packet is mapped to the second QoS flow using a second updated PFD, the second updated PFD created based on the received DSCP.

[0114] Example 18 includes the subject matter of any variation of any of the Examples 17, wherein the request comprises a PFD requested by the second UE.

[0115] Example 19 includes the subject matter of any variation of any of the Examples 17 or 18, wherein the QoS profile of the UPF is updated based on a PFD requested by the second UE.

[0116] Example 20 includes the subject matter of any variation of any of the Examples 16-19, wherein the request is sent to the NEF over an N33 reference point.

[0117] Example 21 is a method for performing packet flow description (PFD) management, the method comprising: establishing a quality of service (QoS) flow between a user equipment (UE) and a core network (CN) for an application’s data flow; creating, by the UE, a UE requested PFD when the data flow changes; sending, from the UE to the CN, a request to update a CN PFD to an updated PFD using the UE requested PFD; and receiving, by the UE from the CN, a downlink (DL) packet mapped to the QoS flow using the updated PFD.

[0118] Example 22 includes the subject matter of any variation of any of the Examples 21, wherein the DL packet is received by the UE with a differentiated services code point (DSCP) marking derived from the updated PFD, and wherein an uplink (UL) packet mapped to the QoS flow based on the DSCP marking is transmitted to the CN.

[0119] Example 23 includes the subject matter of any variation of any of the Examples 22, wherein the DSCP marking is provided by the UE requested PFD.

[0120] Example 24 includes the subject matter of any variation of any of the Examples 22 or 23, wherein the UL packet is mapped to multiple QoS flows using multiple updated PFDs.

[0121] Example 25 includes the subject matter of any variation of any of the Examples 22, 23, or 24, further comprising: updating a QoS rule based on the DSCP marking after receiving the DL packet, wherein the UL packet is mapped to the QoS flow using the updated QoS rule.

[0122] Example 26 includes the subject matter of any variation of any of the Examples 21, wherein the DL packet is received by the UE with a reflective QoS indicator (RQI) setting derived from the updated PFD, and wherein an uplink (UL) packet mapped to the QoS flow based on the derived RQI setting is transmitted from the UE to the CN.

[0123] Example 27 includes the subject matter of any variation of any of Examples 21-26, wherein the request uses Hypertext Transfer Protocol (HTTP) as a transport layer protocol.

[0124] Example 28 includes the subject matter of any variation of any of Examples 21-27, wherein the request is sent by the UE to a Network Exposure Function (NEF) of the CN via an N33 reference point.

[0125] Example 29 includes the subject matter of any variation of any of Examples 21-28, wherein the change of the data flow is notified by an application from an API.

[0126] Example 30 includes the subject matter of any variation of any of Examples 21-28, wherein the change of the data flow is identified by the UE.

[0127] Example 31 includes a product comprising one or more tangible computer- readable non-transitory storage media comprising computer-executable instructions operable to, when executed by at least one computer processor, enable the at least one processor to perform the method of any of the above Examples.

Claims

1. A baseband processor of a user equipment (UE), the baseband processor configured to perform operations comprising: establishing a quality of service (QoS) flow with a core network (CN) for a data flow of an application; creating a UE-requested packet flow description (PFD) upon a change in the data flow; sending a request to the CN to update a CN PFD to an updated PFD using the UE-requested PFD; and receiving downlink (DL) packets mapped to the QoS flow using the updated PFD.

2. The baseband processor of claim 1, wherein the DL packets are received with a differentiated services code point (DSCP) marking derived from the updated PFD; and wherein uplink (UL) packets mapped to the QoS flow are transmitted to the CN based on the DSCP marking.

3. The baseband processor of claim 2, wherein the DSCP marking is provided by the UE-requested PFD.

4. The baseband processor of claim 2, wherein the UL packets are mapped to multiple QoS flows using multiple updated PFDs.

5. The baseband processor of claim 2, further comprising: updating a QoS rule based on the DSCP marking after receiving the DL packets, wherein the UL packets are mapped to the QoS flow using the updated QoS rule.

6. The baseband processor of claim 1, wherein the DL packets are received with a reflective QoS indicator (RQI) setting derived from the updated PFD; and wherein uplink (UL) packets mapped to the QoS flow are transmitted to the CN based on the derived RQI setting.

7. The baseband processor of claim 1, wherein the request uses hypertext transfer protocol (HTTP) as a transport layer protocol.

8. The baseband processor of claim 1, wherein the request is sent to a network exposure function (NEF) of the CN via an N33 reference point.

9. The baseband processor of claim 1, wherein the change in the data flow is notified by the application from an API.

10. The baseband processor of claim 1, wherein the change in the data flow is identified by the UE.

11. A network entity configured to perform operations comprising: establishing a quality of service (QoS) flow with a user equipment (UE) for a data flow of an application; receiving a request from the UE at a network exposure function (NEF) to request an update to a core network (CN) packet flow description (PFD) upon a change in the data flow, the request including a UE-requested PFD; distributing the UE-requested PFD from the NEF to a user plane function (UPF); determining whether to accept the UE-requested PFD, and if so, updating the CN PFD to an updated PFD using the UE-requested PFD; ​ transmitting downlink, DL, packets with a differentiated services code point, DSCP, if there is a plurality of QoS flows in the UE requested PFDs, or with a reflective QoS indicator, RQI, setting if there is a single QoS flow in the UE requested PFDs; and receiving uplink, UL, packets mapped to the QoS flows using updated PFDs, the updated PFDs being based on the DSCP or the RQI setting.

12. The network entity of claim 11, wherein distributing the UE requested PFDs from the NEF to the UPF comprises: distributing the UE requested PFDs from the NEF to a session management function, SMF; and distributing the UE requested PFDs from the SMF to the UPF.

13. The network entity of claim 11, wherein the request is received at the NEF over an N33 reference point.

14. The network entity of claim 11, wherein the request uses hypertext transfer protocol, HTTP, as a transport layer protocol.

15. The network entity of claim 11, wherein the UL packets are mapped to a plurality of QoS flows using a plurality of updated PFDs.

16. A method for packet flow description, PFD, management, the method comprising: establishing a first quality of service, QoS, flow between a user equipment, UE, and a core network, CN, within a protocol data unit, PDU, session upon creation of a first data flow by a first application; creating a first UE requested packet flow description, PFD, by the UE upon a change in the first data flow, the first UE requested PFD comprising update information; sending a request for an update of a CN PFD from the UE to a network exposure function, NEF, of the CN, the request comprising the first UE requested PFD; distributing the first UE requested PFD from the NEF to a user plane function, UPF; receiving, by the UE, downlink, DL, packets from the CN with a differentiated services code point, DSCP, or a reflective QoS indicator, RQI, setting; updating QoS rules of the UE based on the DSCP or the RQI setting; and transmitting uplink, UL, packets from the UE to the CN mapped to the first QoS flow using a first updated PFD, the first updated PFD being created based on the DSCP or the RQI setting.

17. The method of claim 16, further comprising: establishing a second QoS flow between the UE and the CN within the PDU session upon creation of a second data flow by a second application; and creating a second UE requested PFD by the UE upon a change in the second data flow, the second UE requested PFD comprising update information, wherein the UL packets are mapped to the second QoS flow using a second updated PFD, the second updated PFD being created based on the received DSCP.

18. The method of claim 17, wherein the request comprises the second UE requested PFD.

19. The method of claim 17, wherein the QoS profile of the UPF is updated based on the second UE request.

20. The method of claim 16, wherein the request is sent to the NEF over an N33 reference point.

Images