Patent Description:
Quality of Service (QoS) is a mechanism to control network traffic by priority. Using QoS in networking can optimize performance of certain applications by allocating bandwidth, latency, bit rate, delay to achieve the expected service quality. When a network provides a QoS for an application, and the application creates a data flow, a protocol data unit (PDU) session sets up a QoS flow and maps the data flow to the QoS flow. QoS flows provide priority information to different applications, users, or data communications. Upon a change in the data flow by the application, the UE and the network correspondingly update the mapping of the data flow to the QoS flow to continue the QoS for the application. To update this mapping, packet flow description (PFD) management may be utilized.

The following documents are relevant: <CIT> which discusses a communication method and a communication apparatus and <CIT> which discusses a method for applying reflective quality of service in wireless communication system and a device therefor.

The present disclosure is described with reference to the attached figures. The like reference numerals are used to refer to like elements throughout. The figures are not drawn to scale, and they are provided merely to illustrate the disclosure. Several aspects of the disclosure are described below with reference to example applications for illustration. Numerous specific details, relationships, and methods are set forth to provide an understanding of the disclosure. The present disclosure is not limited by the illustrated ordering of acts or events, as some acts may occur in different orders and/or concurrently with other acts or events. Furthermore, not all illustrated acts or events are required to implement a methodology in accordance with the selected present disclosure.

A packet flow description (PFD) describes the packet flow for uplink or downlink application traffic by parameters such as protocol, IP, and port number. A PFD management enables the network to perform accurate application detection for updating QoS flows based on received QoS flow information. In some cases, the QoS flow information may be preconfigured by the network. In some other cases, the QoS flow information may be created dynamically, for example, dynamically assigned by IP addresses. The QoS flow information may also be provided to a user plane function (UPF) of the network by an external data network (DN) that comprises an application server. However, in the interest of enhanced personal security, service providers (e.g., an application, an application server, or a mid-node) may provide data directly to users rather than through a carrier. Hence, a firewall (e.g., network address translation (NAT)) may be disposed between the network and the server. This leads to a difference in the packet address between the DN and the network, preventing the DN from providing valid QoS flow information to the network.

In view of the above, the disclosure is related to methods for a PFD management driven by UE and associated apparatuses. In one aspect, a UE establishes a QoS flow with a core network (CN) for a data flow of an application. Upon a change in the data flow, the UE creates a UE-requested PFD and sends a request to the CN for updating a CN PFD to an updated PFD using the UE-requested PFD. A downlink (DL) packet is then transmitted to the UE from the CN based on the updated PFD. By employing a UE-driven method for PFD management, PFD updates are acquired from the UE, and thus the firewall between the network and the server does not prevent the network from receiving valid QoS flow information.

In some further aspects of the disclosure, an uplink (UL) packet is transmitted to the CN mapped to a QoS flow based on a differentiated services code point (DSCP) mark derived from the updated PFD and received with the DL packet. In one aspect, the DSCP value of the DSCP mark is provided by or derived from the UE-requested PFD. The UE-requested PFD may comprise the same DSCP value. By using the DSCP mark, the UPF is saved from creating reflective QoS packets and also more than one data flow is allowed for configuration. Adopting the DSCP mark may be more beneficial than other alternative approaches such as NAS signaling or using a reflective QoS indicator (RQI) setting transmitted with the DL packet to subsequently update a QoS rule for the UE. In using the NAS signaling, NAS load is added, preventing the CN from updating PFDs frequently. In addition, NAS messages cannot provide data flow authentication information to the CN, preventing the CN from recognizing which application(s) the data flow(s) belong to. In using the RQI setting, the UPF of the network needs to inspect packet flow, such as performing a deep packet inspection (DPI) using packet filters, to create a reflective QoS packet, which consumes UPF resources and reduces UPF capacity. In addition, the packet filters are pre-configured on the UPF, making it difficult to maintain and update. Further, by using the reflective QoS, the UE needs to support service data adaptation protocol (SDAP), and can allow configuration of no more than one data flow.

<FIG> illustrates a block diagram illustrating an architecture of a wireless system <NUM> including a UE <NUM> and a CN <NUM> in accordance with some aspects. The following description is provided in conjunction with <NUM> or NR system standards as provided by 3GPP technical specifications. However, the example aspects are not limited in this regard, and the described aspects can apply to other networks that benefit from the principles described herein, such as other 3GPP systems (e.g., Fourth Generation (<NUM>) or Sixth Generation (<NUM>)) systems, IEEE <NUM> protocols (e.g., WMAN, WiMAX, etc.), or the like.

As shown by <FIG>, the wireless system <NUM> includes UE 101a and UE 101b (collectively referred to as "UEs <NUM>" or "UE <NUM>"). In this example, UEs <NUM> are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but can comprise any mobile or non-mobile computing device, such as consumer electronics devices including headset, handset, cellular phones, smartphones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), pagers, wireless handsets, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, an Instrument Cluster (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDTs), Electronic Engine Management System (EEMS), electronic/engine control units (ECUs), electronic/engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or "smart" appliances, Machine Type Communication (MTC) devices, Machine to Machine (M2M), Internet of Things (IoT) devices, and/or the like.

The UEs <NUM> can be configured to connect, for example, communicatively couple, with a Radio Access Network (RAN) <NUM>. In some aspects, the RAN <NUM> can be a next generation (NG) RAN or a <NUM> RAN, an evolved-UMTS Terrestrial RAN (E-UTRAN), or a legacy RAN, such as a UTRAN or GERAN. As used herein, the term "NG RAN" or the like can refer to a RAN <NUM> that operates in an NR or <NUM> wireless system <NUM>, and the term "E-UTRAN" or the like can refer to a RAN <NUM> that operates in an long term evolution (LTE) or <NUM> system <NUM>. The UEs <NUM> utilize connections (or channels) <NUM> and <NUM>, which respectively comprise a physical communications channel/interface. In this example, the connections <NUM> and <NUM> are illustrated as an air interface to enable communicative coupling and can be consistent with cellular communications protocols, such as a Global System for Mobile communications (GSM) protocol, a Code-Division Multiple Access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over-cellular (POC) protocol, a Universal Mobile Telecommunications Service (UMTS) protocol, a 3GPP LTE protocol, a <NUM> protocol, an NR protocol, and/or any of the other communications protocols discussed herein. In aspects, the UEs <NUM> can directly exchange communication data via a ProSe interface <NUM>. The ProSe interface <NUM> can alternatively be referred to as an SL interface <NUM> and can comprise one or more logical channels, including but not limited to a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), and a physical sidelink broadcast channel (PSBCH).

The RAN <NUM> can include one or more RAN nodes including base stations (BS) 111a and 111b (collectively referred to as "BS <NUM>"), that enable the connections <NUM> and <NUM>. As used herein, the terms "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 BS can be referred to as access nodes, gNBs, RAN nodes, eNBs, NodeBs, RSUs, Transmission Reception Points (TRxPs) or TRPs, and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). According to various aspects, the BS <NUM> 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 for providing femtocells, picocells, or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

The RAN <NUM> is communicatively coupled to a CN <NUM>. The CN <NUM> is configured to offer various data and telecommunications services to customers/subscribers (e.g., users of UEs <NUM>) who are connected to the CN <NUM> via the RAN <NUM>. The CN <NUM> can comprise a network exposure function (NEF) <NUM>, a session management function (SMF) <NUM>, and a UPF <NUM>.

A data network (DN) <NUM> may communicate with the UPF <NUM> via an interface <NUM> (e.g., N6 reference point). In some aspects, the DN <NUM> comprises an application server. In some aspects, the application server of the DN <NUM> communicates with the UPF <NUM> via the interface <NUM>. The DN <NUM> can also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs <NUM> via the CN <NUM>. In some aspects, the UE <NUM> derives uplink traffic related information and collects downlink traffic related information from a peer UE or the DN <NUM> as indicated by arrow <NUM>. For example, the downlink traffic related information may be collected through an application layer protocol. The downlink traffic related information may be per IP flow or per port, and such low-level information may not be directly accessible by the CN <NUM>. In some aspects, the DN <NUM> communicates with and/or comprises an application function (AF) (not shown) that communicates directly with the CN <NUM> to provide QoS flow information.

For the DN <NUM> or the AF to provide QoS flow information (e.g., QoS class of identifier (QCI)) to the UPF <NUM> via the interface <NUM>, the DN <NUM> must communicate directly with the CN <NUM>. However, a firewall (e.g., network address translation (NAT)) may be disposed between the CN <NUM> and the DN <NUM>, leading to a difference in the packet address between the DN <NUM> and the CN <NUM> and preventing the DN <NUM> from providing valid QoS flow information to the CN <NUM>. To provide valid QoS flow information to the CN <NUM>, in one aspect, the UE <NUM> establishes a QoS flow with the CN <NUM> for a data flow of an application. Upon a change in the data flow, the UE <NUM> creates a UE-requested PFD and sends a request to the NEF <NUM> via an interface (e.g., N33 interface) for updating a CN PFD to an updated PFD using the UE-requested PFD as indicated by arrow <NUM>. The NEF <NUM> first distributes the UE-requested PFD to the SMF <NUM> via a second interface <NUM> (e.g., N29 reference point), and the SMF <NUM> distributes the UE-requested PFD to the UPF <NUM> via a third interface <NUM> (e.g., N4 reference point). A DL packet is then transmitted to the UE <NUM> from the CN <NUM> mapping to QoS flows based on the updated PFD. By employing a UE-driven method for PFD management, a firewall between the CN <NUM> and the DN <NUM> does not prevent the CN <NUM> from receiving valid QoS flow information.

<FIG> illustrates a flow diagram showing a method for a PFD management driven by a UE to update mapping a data flow to a QoS flow upon a change in the data flow.

In some aspects, at act <NUM>, a QoS flow is established between the CN <NUM> and the UE <NUM> for a data flow of an application within a PDU session. In some aspects, a plurality of data flows may be created by an application, and a plurality of QoS flows may be correspondingly established between the CN <NUM> and the UE <NUM>. In some aspects, the number of data flows created may be greater than the number of QoS flows established.

In some aspects, at act <NUM>, when the application changes the data flow, the DN <NUM> may notify the UE <NUM> of the change in the data flow via an application programming interface (API), or an operating system (OS) of the UE <NUM> may identify the change in the data flow. In some alternative aspects, the change in the data flow may instead be or comprise a refresh of the data flow by a mid-node, a new data flow added by the application, or a change in the data flow by the server due to load balance, traffic engineering policy, or the like. In some aspects, the DN <NUM> communicates with and/or comprises an AF (not shown) that notifies the UE <NUM> of the change in the data flow.

In some aspects, at act <NUM>, the UE <NUM> creates a UE-requested PFD. In some aspects, the UE-requested PFD may be a <NUM>-tuple of protocol, server-side IP address, and port number. In some aspects, the UE-requested PFD may differ from a CN PFD and may comprise updating information for the CN PFD. In some aspects, the UE-requested PFD may comprise a DSCP mark having a DSCP value.

In some aspects, at act <NUM>, the UE <NUM> sends a request to the NEF <NUM> via a first interface (e.g., N33 reference point) to update the CN PFD using the UE-requested PFD. In some aspects, the request uses HTTP as a 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, after successfully receiving the HTTP request from the UE <NUM>, the NEF <NUM> sends a confirmation that the request was received. In some of such aspects, the confirmation is an HTTP <NUM> response.

In some aspects, at act <NUM>, the NEF <NUM> distributes the UE-requested PFD to the UPF <NUM>. In some aspects, upon receiving the UE-requested PFD, the UPF <NUM> determines whether to accept the UE-requested PFD. If the UE-requested PFD is accepted, the CN PFD is updated to an updated PFD. If the UE-requested PFD is rejected, the CN PFD is maintained.

In some aspects, at act <NUM>, the UPF <NUM> transmits a DL packet mapped to a QoS flow based on the CN PFD or the updated PFD if the UE-requested PFD is accepted. In some further aspects, the DL packet may include information for a reflective QoS for UL packet mapping. In some aspects, an IP header of the DL packet includes a DSCP mark included in or derived from the updated PFD. In one aspect, DL packet has a same DSCP value as the UE-requested PFD. Alternatively, the DL packet may include a RQI setting derived from the updated PFD. However, in using the RQI setting, the UPF <NUM> needs to inspect packet flow, such as performing a DPI using packet filters, to create a reflective QoS packet, which consumes UPF <NUM> resources and reduces UPF <NUM> capacity. In addition, the packet filters are pre-configured on the UPF <NUM>, making it difficult to maintain and update. Further, in using the RQI setting, the UE <NUM> needs to support SDAP and can allow configuration of no more than one data flow. By instead using the DSCP mark, the UE <NUM> does not need to support SDAP, and can thus allow configuration of multiple data flows. Further, the UPF <NUM> does not inspect packet flow using pre-configured packet filters, and hence the UE <NUM> is able to provide QoS flow information to the CN <NUM>. In addition, UPF <NUM> resources are not consumed and UPF <NUM> capacity is not reduced. In some aspects, a QoS profile of the UPF <NUM> is updated based on the UE-requested PFD.

In some aspects, at act <NUM>, after receiving the DL packet from the UPF <NUM>, the UE <NUM> uses information of the DL packet to configure or derive mapping of an UL packet. In some aspects, the updated PFD is utilized to update a QoS rule of the UE <NUM> based on the received DSCP mark or the RQI setting. In some aspects, the UE <NUM> further updates a packet filter based on the received DL packet. By employing a UE-driven method for PFD management, the QoS rule is updated without the CN <NUM> and the DN <NUM> directly communicating, and thus a firewall does not prevent the QoS flow update.

In some aspects, the UE <NUM>, at act <NUM>, the UE transmits the UL packet mapped to a QoS flow using the updated QoS rule and/or the updated PFD to the UPF <NUM>. By employing a UE-driven method for PFD management, the UE <NUM> is able to update a QoS flow between the UE <NUM> and the CN <NUM> for the UL packet, thus a firewall between the CN <NUM> and the DN <NUM> does not prevent the CN <NUM> from receiving valid QoS flow information. In some aspects, the UL packet is mapped to a plurality of QoS flows using a plurality of updated PFDs.

<FIG> illustrates an example system architecture <NUM> in accordance with some aspects. The system <NUM> is shown to include a UE <NUM>, a (R)AN <NUM>, and which may include RAN nodes <NUM> discussed previously, a first DN <NUM> and a second DN <NUM>, which may be, for example, application servers, operator services, Internet access or 3rd party services; an AF <NUM>, and a CN <NUM>. In some aspects, the CN <NUM> may be a <NUM> Core network (e.g., 5GC). The CN <NUM> may include an Authentication Server Function (AUSF <NUM>), an Access & Mobility Management Function (AMF) <NUM>, a first SMF <NUM>, a second SMF <NUM>, a NEF <NUM>, a Network Slice Selection Function (NSSF) <NUM>, a Policy Control Function (PCF) <NUM>, a Unified Data Management (UDM) <NUM>, a first UPF <NUM>, and a second UPF <NUM>.

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

The NEF <NUM> may directly interact with the UE <NUM> via an N33 interface <NUM>. In some aspects, the UE <NUM> may send a request to the NEF <NUM> comprising the UE-requested PFD as described with respect to <FIG> via the N33 interface. The NEF <NUM> may interact with the first SMF <NUM> via an N29 interface. In some aspects, the NEF <NUM> may distribute the UE-requested PFD to the first SMF <NUM> via the N29 interface.

The first UPF <NUM> and the second UPF <NUM> may act as anchor points for intra-RAT and inter-RAT mobility, external PDU session points of interconnect to DN <NUM> and DN <NUM>, respectively, and a branching point to support multi-homed PDU session. The first UPF <NUM> and the second UPF <NUM> may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The first UPF <NUM> and the second UPF <NUM> may include an uplink classifier to support routing traffic flows to a data network.

The first DN <NUM> and the second DN <NUM> may represent various network operator services, Internet access, or third-party services. The first DN <NUM> and the second DN <NUM> may include an application server. The first UPF <NUM> may interact with the first SMF <NUM> via a first N4 reference point between the first SMF <NUM> and the first UPF <NUM>. The second UPF <NUM> may interact with the second SMF <NUM> via a second N4 reference point between the second UPF <NUM> and the second SMF <NUM>. In some aspects, the first SMF <NUM> may distribute the UE-requested PFD to the first UPF <NUM> via the N4 reference point. In some aspects, the first UPF <NUM> comprises a CN PFD and determines whether to accept the UE-requested PFD, and upon accepting the UE-requested PFD, the first UPF <NUM> updates the CN PFD to an updated PFD using the UE-requested PFD. In some aspects, the first UPF <NUM> sends a DL packet with a DSCP mark if there are one or more QoS flows in the UE-requested PFD. In some aspects, the first UPF <NUM> 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 <NUM> is external to the CN <NUM>. In some aspects, the first DN <NUM> communicates with and/or comprises the AF <NUM>.

The AF <NUM> may provide application influence on traffic routing, provide access to the NCE, and interact with the policy framework for policy control. The NCE may be a mechanism that allows the 5GC <NUM> and AF <NUM> to provide information to each other via NEF <NUM>, which may be used for edge computing implementations. In such implementations, the network operator and third-party services may be hosted close to the UE <NUM> access point of attachment to achieve an efficient service delivery through the reduced end-to-end latency and load on the transport network. For edge computing implementations, the 5GC may select a UPF (e.g., the first UPF <NUM> or the second UPF <NUM>) close to the UE <NUM> and execute traffic steering from the first UPF <NUM> to the first DN <NUM> via the N6 interface, and/or from the second UPF <NUM> to the second DN <NUM> via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF <NUM>. In this way, the AF <NUM> may influence UPF (re)selection and traffic routing. Based on operator deployment, when AF <NUM> is considered to be a trusted entity, the network operator may permit AF <NUM> to interact directly with relevant NFs. Additionally, the AF <NUM> may exhibit an Naf service-based interface. In some aspects, a firewall (e.g., network address translation (NAT)) may be disposed between the PCF <NUM> and the AF <NUM>. This leads to a difference in the packet address between the AF <NUM> and the CN <NUM>, preventing the AF <NUM> from providing valid QoS flow information to the CN <NUM>. Hence, by performing UE-driven PFD management, this QoS flow information can be provided by the UE <NUM>, so the firewall does not prevent this information from being provided to the CN <NUM>.

The AUSF <NUM> may store data for authentication of UE <NUM> and handle authentication-related functionality. The AUSF <NUM> may facilitate a common authentication framework for various access types. The AUSF <NUM> may communicate with the AMF <NUM> via an N12 reference point between the AMF <NUM> and the AUSF <NUM>, and may communicate with the UDM <NUM> via an N13 reference point between the UDM <NUM> and the AUSF <NUM>. Additionally, the AUSF <NUM> may exhibit an Nausf service-based interface.

The AMF <NUM> may be responsible for registration management (e.g., for registering UE <NUM>, etc.), connection management, reachability management, mobility management, and lawful interception of AMF-related events, and access authentication and authorization. The AMF <NUM> may be a termination point for N11 reference points between the AMF <NUM> and the first SMF <NUM> and between the AMF <NUM> and the second SMF <NUM>. The AMF <NUM> may provide transport for SM messages between the UE <NUM> and the first SMF <NUM> and between the UE <NUM> and the second SMF <NUM>, and act as a transparent proxy for routing SM messages. AMF <NUM> may also provide transport for SMS messages between UE <NUM> and a Short Message Service Function (SMSF) (not shown by <FIG>). AMF <NUM> may act as a Security Anchor Function (SEAF), which may include interaction with the AUSF <NUM> and the UE <NUM>, receipt of an intermediate key that was established as a result of the UE <NUM> authentication process. Where universal subscriber identity module (USIM) based authentication is used, the AMF <NUM> may retrieve the security material from the AUSF <NUM>. AMF <NUM> may also include a SCM function, which receives a key from the SEA that it uses to derive access-network specific keys. Furthermore, AMF <NUM> may be a termination point of a RAN control plane (CP) interface, which may include or be an N2 reference point between the (R)AN <NUM> and the AMF <NUM>, and the AMF <NUM> may be a termination point of NAS (N1) signaling, and perform NAS ciphering and integrity protection.

The AMF <NUM> may also support NAS signaling with a UE <NUM> over an non-3GPP (N3) interworking function (IWF) interface. The N3IWF may be used to provide access to untrusted entities. N3IWF may be a termination point for the N2 interface between the (R)AN <NUM> and the AMF <NUM> for the control plane, and may be a termination point for the N3 reference points between the (R)AN <NUM> and the first UPF <NUM> and the (R)AN <NUM> and the second UPF <NUM> for the user plane. As such, the AMF <NUM> may handle N2 signaling from the SMF <NUM> and the AMF <NUM> for PDU sessions and QoS, encapsulate/de-encapsulate packets for IPSec and N3 tunnelling, mark N3 user-plane packets in the uplink, and enforce QoS corresponding to N3 packet marking taking into account QoS requirements associated with such marking received over N2. N3IWF may also relay uplink and downlink control-plane NAS signaling between the UE <NUM> and AMF <NUM> via an N1 reference point between the UE <NUM> and the AMF <NUM>, and relay uplink and downlink user-plane packets between the UE <NUM> and first UPF <NUM> and between the UE <NUM> and the second UPF <NUM>. The N3IWF also provides mechanisms for IPsec tunnel establishment with the UE <NUM>. The AMF <NUM> may exhibit an Namf service-based interface, and may be a termination point for an N14 reference point between two AMFs <NUM> and an N17 reference point between the AMF <NUM> and a <NUM>-EIR (not shown by <FIG>).

The UE <NUM> may need to register with the AMF <NUM> in order to receive network services. RM is used to register or deregister the UE <NUM> with the network (e.g., AMF <NUM>), and establish a UE context in the network (e.g., AMF <NUM>). The UE <NUM> may operate in an RM-REGISTERED state or an RM-DEREGISTERED state. In the RM-DEREGISTERED state, the UE <NUM> is not registered with the network, and the UE context in the AMF <NUM> holds no valid location or routing information for the UE <NUM> so the UE <NUM> is not reachable by the AMF <NUM>. In the RM-REGISTERED state, the UE <NUM> is registered with the network, and the UE context in the AMF <NUM> may hold a valid location or routing information for the UE <NUM> so the UE <NUM> is reachable by the AMF <NUM>. In the RM-REGISTERED state, the UE <NUM> may perform mobility Registration Update procedures, perform periodic Registration Update procedures triggered by expiration of the periodic update timer (e.g., to notify the network that the UE <NUM> is still active), and perform a Registration Update procedure to update UE capability information or to re-negotiate protocol parameters with the network, among others.

The AMF <NUM> may store one or more RM contexts for the UE <NUM>, where each RM context is associated with a specific access to the network. The RM context may be a data structure, database object, etc. that indicates or stores, inter alia, a registration state per access type and the periodic update timer. The AMF <NUM> may also store a 5GC MM context that may be the same or similar to the (E)MM context discussed previously. In various aspects, the AMF <NUM> may store a common emitter (CE) mode B Restriction parameter of the UE <NUM> in an associated MM context or RM context. The AMF <NUM> may also derive the value, when needed, from the UE's usage setting parameter already stored in the UE context (and/or MM/RM context).

The connection management (CM) may be used to establish and release a signaling connection between the UE <NUM> and the AMF <NUM> over the N1 interface. The signaling connection is used to enable NAS signaling exchange between the UE <NUM> and the CN <NUM>, and comprises both the signaling connection between the UE and the AN (e.g., RRC connection or UE-N3IWF connection for non-3GPP access) and the N2 connection for the UE <NUM> between the AN (e.g., the RAN <NUM>) and the AMF <NUM>. The UE <NUM> may operate in one of two CM states, CM-IDLE mode or CM-CONNECTED mode. When the UE <NUM> is operating in the CM-IDLE state/mode, the UE <NUM> may have no NAS signaling connection established with the AMF <NUM> over the N1 interface, and there may be (R)AN <NUM> signaling connection (e.g., N2 and/or N3 connections) for the UE <NUM>. When the UE <NUM> is operating in the CM-CONNECTED state/mode, the UE <NUM> may have an established NAS signaling connection with the AMF <NUM> over the N1 interface, and there may be a (R)AN <NUM> signaling connection (e.g., N2 and/or N3 connections) for the UE <NUM>. Establishment of an N2 connection between the (R)AN <NUM> and the AMF <NUM> may cause the UE <NUM> to transition from CM-IDLE mode to CM-CONNECTED mode, and the UE <NUM> may transition from the CM-CONNECTED mode to the CM-IDLE mode when N2 signaling between the (R)AN <NUM> and the AMF <NUM> is released.

The first SMF <NUM> and the second SMF <NUM> may be responsible for SM (e.g., session establishment, modify and release, including tunnel maintain between the UPF and an 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 may refer to management of a PDU session, and a PDU session or "session" may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE <NUM> and the first DN <NUM> and between the UE <NUM> and the second DN <NUM> identified by a Data Network Name (DNN). PDU sessions may be established upon UE <NUM> request, modified upon UE <NUM> and 5GC <NUM> request, and released upon the UE <NUM> and the CN <NUM> request using NAS SM signaling exchanged over the N1 reference points between the UE <NUM> and the first SMF <NUM> and between the UE <NUM> and the second SMF <NUM>. Upon request from an application server, the CN <NUM> may trigger a specific application in the UE <NUM>. In response to receipt of the trigger message, the UE <NUM> may pass the trigger message (or relevant parts/information of the trigger message) to one or more identified applications in the UE <NUM>. The identified application(s) in the UE <NUM> may establish a PDU session to a specific DNN. The first SMF <NUM> and/or the second SMF <NUM> may check whether the UE <NUM> requests are compliant with user subscription information associated with the UE <NUM>. In this regard, the first SMF <NUM> and/or the second SMF <NUM> may retrieve and/or request to receive update notifications on first SMF <NUM> and/or second SMF <NUM> level subscription data from the UDM <NUM>.

The first SMF <NUM> and the second SMF <NUM> may include the following roaming functionality: handling local enforcement to apply QoS SLAs (VPLMN); charging data collection and charging interface (VPLMN); lawful intercept (in VPLMN for SM events and interface to LI system); and support for interaction with an external DN for transport of signaling for PDU session authorization/authentication by the external DN. Additionally, the first SMF <NUM> and/or the second SMF <NUM> may exhibit the Nsmf service-based interface.

The PCF <NUM> may provide policy rules to control plane function(s) to enforce them, and may also support unified policy framework to govern network behavior. The PCF <NUM> may also implement an FE to access subscription information relevant for policy decisions in a UDR of the UDM <NUM>. The PCF <NUM> may communicate with the AMF <NUM> via an N15 reference point between the PCF <NUM> and the AMF <NUM>, which may include a PCF <NUM> in a visited network and the AMF <NUM> in case of roaming scenarios. The PCF <NUM> may communicate with the AF <NUM> via an N5 reference point between the PCF <NUM> and the AF <NUM>; and with the first SMF <NUM> and the second SMF <NUM> via N7 reference points between the PCF <NUM> and the first SMF <NUM> and between the PCF <NUM> and the second SMF <NUM>. The system <NUM> and/or CN <NUM> may also include an N24 reference point between the PCF <NUM> (in the home network) and a PCF <NUM> in a visited network. Additionally, the PCF <NUM> may exhibit an Npcf service-based interface.

In some aspects, a firewall (e.g., network address translation (NAT)) may be disposed at the N5 reference point between the PCF <NUM> and the AF <NUM>, at the N6 reference point between the first UPF <NUM> and the first DN <NUM>, and at the N6 reference point between the second UPF <NUM> and the second DN <NUM>. This leads to a difference in the packet address between the AF <NUM> and the CN <NUM>, between the first DN <NUM> and the CN <NUM>, and between the second DN <NUM> and the CN <NUM>. This prevents the AF <NUM>, the first DN <NUM>, and the second DN <NUM> from providing valid QoS flow information to the CN <NUM>. Hence, by performing UE-driven PFD management, this QoS flow information can be provided by the UE <NUM>, so the firewall does not prevent this information from being provided to the CN <NUM>.

The UDM <NUM> may handle subscription-related information to support the network entities' handling of communication sessions, and may store subscription data of UE <NUM>. For example, subscription data may be communicated between the UDM <NUM> and the AMF <NUM> via an N8 reference point between the UDM <NUM> and the AMF. The UDM <NUM> may include two parts, an application FE and a UDR (the FE and UDR are not shown by <FIG>). The UDR may store subscription data and policy data for the UDM <NUM> and the PCF <NUM>, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs <NUM>) for the NEF <NUM>. The UDM may include a UDM-FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration/mobility management, and subscription management. The UDR may interact with the first SMF <NUM> and/or the second SMF <NUM> via N10 reference points between the UDM <NUM> and the first SMF <NUM> and between the UDM <NUM> and the second SMF <NUM>. UDM <NUM> may also support SMS management, wherein an SMS-FE implements the similar application logic as discussed previously. Additionally, the UDM <NUM> may exhibit the Nudm service-based interface.

The NSSF <NUM> may select a set of network slice instances serving the UE <NUM>. The NSSF <NUM> may also determine allowed network slice selection assistance information (NSSAI) and the mapping to the subscribed single-NSSAIs (S-NSSAIs), if needed. The selection of a set of network slice instances for the UE <NUM> may be triggered by the AMF <NUM> with which the UE <NUM> is registered by interacting with the NSSF <NUM>, which may lead to a change of AMF <NUM>. The NSSF <NUM> may interact with the AMF <NUM> via an N22 reference point between AMF <NUM> and NSSF <NUM>; and may communicate with another NSSF <NUM> in a visited network via an N31 reference point (not shown by <FIG>). Additionally, the NSSF <NUM> may exhibit an Nnssf service-based interface.

As discussed previously, the CN <NUM> may include an SMSF, which may be responsible for SMS subscription checking and verification, and relaying SM messages to/from the UE <NUM> to/from other entities, such as an SMS-GMSC/IWMSC/SMS-router. The SMS may also interact with AMF <NUM> and UDM <NUM> for a notification procedure that the UE <NUM> is available for SMS transfer (e.g., set a UE not reachable flag, and notifying UDM <NUM> when UE <NUM> is available for SMS).

The CN <NUM> may also include other elements that are not shown by <FIG>, such as a Data Storage system/architecture, a <NUM>-EIR, a SEPP, and the like. The Data Storage system may include a SDSF, an UDSF, and/or the like. Any NF may store and retrieve unstructured data into/from the UDSF (e.g., UE contexts), via N18 reference point between any NF and the UDSF (not shown by <FIG>). Individual NFs may share a UDSF for storing their respective unstructured data or individual NFs may each have their own UDSF located at or near the individual NFs. Additionally, the UDSF may exhibit an Nudsf service-based interface (not shown by <FIG>). The <NUM>-EIR may be an NF that checks the status of PEI for determining whether particular equipment/entities are blacklisted from the network; and the SEPP may be a non-transparent proxy that performs topology hiding, message filtering, and policing on inter-PLMN control plane interfaces.

Additionally, there may be many more reference points and/or service-based interfaces between the NF services in the NFs; however, these interfaces and reference points have been omitted from <FIG> for clarity. Other example interfaces/reference points may include an N5g-EIR service-based interface exhibited by a <NUM>-EIR, an N27 reference point between the NRF in the visited network and the NRF in the home network; and an N31 reference point between the NSSF in the visited network and the NSSF in the home network.

<FIG> illustrates a flowchart that describes a UE performing UE-driven packet flow description (PFD) management in accordance with some aspects.

As shown by act <NUM>, the UE establishes one or more QoS flows with a CN upon data flow creation by an application. In some aspects, the UE may establish one or more QoS flows in a PDU session.

As shown by act <NUM>, the UE creates a UE-requested PFD upon a change in the data flow. In some aspects, the UE-requested PFD may comprise updating information. In some aspects, if the UE establishes more than one QoS flows, the UE-requested PFD may comprise a DSCP.

As shown by act <NUM>, the UE sends a request to the CN for an update of a CN PFD using the UE-requested PFD. In some aspects, the UE sends a request to an NEF of the CN over an N33 interface. In some aspects, the request is an HTTP request.

As shown by act <NUM>, the UE receives a DL packet mapping to the QoS flows using the updated PFD and with a DSCP mark. In some aspects the UE-requested PFD may have a DSCP mark with a same DSCP value as the DSCP mark of the DL packet. Alternatively, in some aspects, the DL packet may have an RQI setting rather than a DSCP mark.

As shown by act <NUM>, the UE transmits a UL packet mapping to the QoS flows using an updated PFD based on the received DSCP mark. Alternatively, in some aspects, the UL packet may map to the QoS flows using the updated PFD based on a received RQI setting. In other alternative aspects, instead of mapping to the QoS flows based on a DSCP mark or an RQI setting, the UL packet may be mapped to the QoS flows using NAS signaling.

<FIG> illustrates a flowchart that describes a CN performing UE-driven packet flow description (PFD) management in accordance with some aspects.

As shown by act <NUM>, the CN establishes one or more QoS flows with a UE upon data flow creation by an application. In some aspects, the UE may establish one or more QoS flows in a PDU session.

As shown by act <NUM>, in some aspects, the CN receives a request at a NEF from the UE requesting an update of a CN PFD, the request comprising the UE-requested PFD. In some aspects, the UE receives the request over an N33 interface. In some aspects, the request is an HTTP request.

As shown by act <NUM>, the CN distributes the UE-requested PFD from the NEF to a UPF. In some aspects, the NEF distributes the UE-requested PFD to a SMF via a N29 interface, and the SMF distributes the UE-requested PFD to the UPF via a N4 interface.

As shown by act <NUM>, the CN determines whether to accept the UE-requested PFD. In some aspects, the CN may determine whether to accept the UE-requested PFD based on information included in the UE-requested PFD. In some aspects, the CN may determine whether to accept the UE-requested PFD based on data available only to the CN. In some aspects, a QoS profile of the UPF is updated based on the UE-requested PFD.

As shown by act <NUM>, 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) to notify the UE that the UE-requested PFD was rejected.

As shown by act <NUM>, if the CN determines to accept the UE-requested PFD, the CN PFD is updated to an updated PFD. In some aspects, the updated PFD is based on updating information provided by the UE-requested PFD. In some aspects, the updated PFD differs from both the UE-requested PFD and the CN PFD.

As shown by act <NUM>, in some aspects, the CN transmits a DL packet to the UE mapping to the QoS flows using the updated PFD. In some further aspects, the DL packet is transmitted with a DSCP mark. Alternatively, in some aspects, the DL packet may have an RQI setting rather than a DSCP mark.

As shown by act <NUM>, the CN receives a UL packet mapping to the plurality of QoS flows based on the transmitted DSCP. Alternatively, in some aspects, the UL packet may be mapped to the QoS flows using the updated PFD based on the received RQI setting. In other alternative aspects, instead of mapping to the QoS flows based on a DSCP mark or an RQI setting, the UL packet may map to the QoS flows using NAS signaling.

<FIG> illustrates a diagram illustrating example components of a device <NUM> that can be employed in accordance with some aspects. In some implementations, the device <NUM> can include application circuitry <NUM>, baseband circuitry <NUM>, Radio Frequency (RF) circuitry <NUM>, front-end module (FEM) circuitry <NUM>, one or more antennas <NUM>, and power management circuitry (PMC) <NUM> coupled together at least as shown. The components of the illustrated device <NUM> can be included in a UE or a RAN node. In some implementations, the device <NUM> can include fewer elements (e.g., a RAN node may not utilize application circuitry <NUM> and instead include a processor/controller to process IP data received from a CN. In some implementations, the device <NUM> can include additional elements such as, for example, memory/storage, display, camera, sensor (including one or more temperature sensors, such as a single temperature sensor, a plurality of temperature sensors at different locations in device <NUM>, etc.), or input/output (I/O) interface. In other implementations, the components described below can be included in more than one device (e.g., said circuitries can be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

The application circuitry <NUM> can include one or more application processors. For example, the application circuitry <NUM> can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors can be coupled with or can 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 <NUM>. In some implementations, processors of application circuitry <NUM> can process IP data packets received from an evolved packet core (EPC).

The baseband circuitry <NUM> can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry <NUM> can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry <NUM> and to generate baseband signals for a transmit signal path of the RF circuitry <NUM>. Baseband circuitry <NUM> can interface with the application circuitry <NUM> for generation and processing of the baseband signals and for controlling operations of the RF circuitry <NUM>. For example, in some implementations, the baseband circuitry <NUM> can include a third generation (<NUM>) baseband processor 604A, a fourth generation (<NUM>) baseband processor 604B, a fifth generation (<NUM>) baseband processor 604C, or other baseband processor(s) 604D for other existing generations, generations in development or to be developed in the future (e.g., second generation (<NUM>), sixth generation (<NUM>), etc.). The baseband circuitry <NUM> (e.g., one or more of baseband processors 604A-D) can handle various radio control functions that enable communication with one or more radio networks via the RF circuitry <NUM>. In other implementations, some or all of the functionality of baseband processors 604A-D can be included in modules stored in the memory <NUM> and executed via a Central Processing Unit (CPU) 604E. The radio control functions can include but are not limited to signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some implementations, modulation/demodulation circuitry of the baseband circuitry <NUM> can include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some implementations, encoding/decoding circuitry of the baseband circuitry <NUM> can include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Implementations of modulation/demodulation and encoder/decoder functionality are not limited to these examples and can include other suitable functionality in other implementations.

In some implementations, the baseband circuitry <NUM> can include one or more audio digital signal processor(s) (DSP) 604F. The audio DSP(s) 604F can include elements for compression/decompression and echo cancellation and can include other suitable processing elements in other implementations. Components of the baseband circuitry can be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some implementations. In some implementations, some or all of the constituent components of the baseband circuitry <NUM> and the application circuitry <NUM> can be implemented together such as, for example, on a system on a chip (SOC).

In some implementations, the baseband circuitry <NUM> can provide for communication compatible with one or more radio technologies. For example, in some implementations, the baseband circuitry <NUM> can support communication with an NG-RAN, an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN), etc. Implementations in which the baseband circuitry <NUM> is configured to support radio communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

RF circuitry <NUM> can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various implementations, the RF circuitry <NUM> can include switches, filters, amplifiers, etc., to facilitate communication with the wireless network. RF circuitry <NUM> can include a receive signal path which can include circuitry to down-convert RF signals received from the FEM circuitry <NUM> and provide baseband signals to the baseband circuitry <NUM>. RF circuitry <NUM> can also include a transmit signal path which can include circuitry to up-convert baseband signals provided by the baseband circuitry <NUM> and provide RF output signals to the FEM circuitry <NUM> for transmission.

In some implementations, the receive signal path of the RF circuitry <NUM> can include mixer circuitry 606a, amplifier circuitry 606b, and filter circuitry 606c. In some implementations, the transmit signal path of the RF circuitry <NUM> can include filter circuitry 606c and mixer circuitry 606a. RF circuitry <NUM> 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 <NUM> 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 fband-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 <NUM> 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, mixer circuitry 606a of the receive signal path can comprise passive mixers, although the scope of the implementations is not limited in this respect.

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 <NUM>. The baseband signals can be provided by the baseband circuitry <NUM> and can be filtered by filter circuitry 606c.

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 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 super-heterodyne operation.

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 alternate implementations, the output baseband signals and the input baseband signals can be digital baseband signals. In these alternate implementations, the RF circuitry <NUM> can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and the baseband circuitry <NUM> can include a digital baseband interface to communicate with the RF circuitry <NUM>.

In some dual-mode implementations, a separate radio IC circuitry can be provided for processing signals for each spectrum, although the scope of the implementations is not limited in this respect.

In some implementations, the synthesizer circuitry 606d can be a fractional-N synthesizer or a fractional N/N+<NUM> 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 comprising a phase-locked loop with a frequency divider.

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

In some implementations, frequency input can be provided by a voltage-controlled oscillator (VCO), although that is not a requirement. Divider control input can be provided by either the baseband circuitry <NUM> or the application circuitry <NUM>, depending on the desired output frequency. In some implementations, a divider control input (e.g., N) can be determined from a look-up table based on a channel indicated by the application circuitry <NUM>.

Synthesizer circuitry 606d of the RF circuitry <NUM> 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+<NUM> (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 break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

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 <NUM> can include an IQ/polar converter.

FEM circuitry <NUM> can include a receive signal path which can include circuitry configured to operate on RF signals received from one or more antennas <NUM>, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry <NUM> for further processing. FEM circuitry <NUM> can also include a transmit signal path which can include circuitry configured to amplify signals for transmission provided by the RF circuitry <NUM> for transmission by one or more of the one or more antennas <NUM>. In various implementations, the amplification through the transmit or receive signal paths can be done solely in the RF circuitry <NUM>, solely in the FEM circuitry <NUM>, or in both the RF circuitry <NUM> and the FEM circuitry <NUM>.

In some implementations, the FEM circuitry <NUM> 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 an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry <NUM>). The transmit signal path of the FEM circuitry <NUM> can include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry <NUM>), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas <NUM>).

In some implementations, the PMC <NUM> can manage power provided to the baseband circuitry <NUM>. In particular, the PMC <NUM> can control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC <NUM> can often be included when the device <NUM> is capable of being powered by a battery, for example, when the device is included in a UE. The PMC <NUM> can increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

While <FIG> shows the PMC <NUM> coupled only with the baseband circuitry <NUM>. However, in other implementations, the PMC <NUM> may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry <NUM>, RF circuitry <NUM>, or FEM circuitry <NUM>.

In some implementations, the PMC <NUM> can control, or otherwise be part of, various power saving mechanisms of the device <NUM>. For example, if the device <NUM> is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it can enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device <NUM> can power down for brief intervals of time and thus save power.

If there is no data traffic activity for an extended period of time, then the device <NUM> can transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device <NUM> goes into 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. The device <NUM> may not receive data in this state; in order to receive data, it can transition back to RRC_Connected state.

An additional power saving mode can allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and can power down completely.

Processors of the application circuitry <NUM> and processors of the baseband circuitry <NUM> can be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry <NUM>, alone or in combination, can be used execute Layer <NUM>, Layer <NUM>, or Layer <NUM> functionality, while processors of the baseband circuitry <NUM> can utilize data (e.g., packet data) received from these layers and further execute Layer <NUM> functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer <NUM> can comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer <NUM> can comprise 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 <NUM> can comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.

<FIG> illustrates a diagram illustrating example interfaces of baseband circuitry that can be employed in accordance with some aspects. As discussed above, the baseband circuitry <NUM> of <FIG> can comprise processors 604A-604E and a memory <NUM> utilized by said processors. Each of the processors 604A-604E can include a memory interface, 704A-704E, respectively, to send/receive data to/from the memory <NUM>.

The baseband circuitry <NUM> can further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface <NUM> (e.g., an interface to send/receive data to/from memory external to the baseband circuitry <NUM>), an application circuitry interface <NUM> (e.g., an interface to send/receive data to/from the application circuitry <NUM> of <FIG>), an RF circuitry interface <NUM> (e.g., an interface to send/receive data to/from RF circuitry <NUM> of <FIG>), a wireless hardware connectivity interface <NUM>, and a power management interface <NUM> (e.g., an interface to send/receive power or control signals to/from the PMC <NUM>).

While the methods described within this disclosure are illustrated in and described herein as a series of acts or events, it will be appreciated that the illustrated ordering of such acts or events are not to be interpreted in a limiting sense. For example, some acts can occur in different orders and/or concurrently with other acts or events apart from those illustrated and/or described herein. In addition, not all illustrated acts can be required to implement one or more aspects or aspects of the description herein. Further, one or more of the acts depicted herein can be carried out in one or more separate acts and/or phases. Reference can be made to the figures described above for ease of description. However, the methods are not limited to any particular aspect, aspect or example provided within this disclosure and can be applied to any of the systems / devices / components disclosed herein.

Claim 1:
A baseband processor (604A, 604B, ..., 604D) of a user equipment, UE (<NUM>), the baseband processor configured to perform operations comprising:
establishing a Quality-of-Service, QoS, flow with a core network, CN (<NUM>), 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 for updating a CN PFD to an updated PFD using the UE-requested PFD; and
receiving a downlink, DL, packet mapped to the QoS flow using the updated PFD.