Patent Application
20250106680
Wireless communication service providers continue to develop and expand available services and their delivery networks. Data-intensive applications like augmented reality (AR), virtual reality (VR), cloud gaming, and video conferencing demand very low communication latency. Next generation networks, such as Fifth Generation (5G) and Sixth Generation (6G) mobile networks, are incorporating a variety of technologies to meet demands for network efficiency and performance. However, certain Internet protocols, such as Transmission Control Protocol (TCP) congestion control algorithms, prevent full realization of these mobile network improvements.
The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
Systems and methods described herein enable a mobile network to determine when Low-Latency, Low-Loss Scalable-Throughput (L4S) service may be enabled for a data flow. L4S is a technology to reduce latency in networks. L4S addresses queue delay problems that are particularly relevant to Transmission Control Protocol (TCP), by relying on Explicit Congestion Notification (ECN). ECN is a mechanism that marks packets to signal congestion in the network, preventing packets from being dropped. Senders are expected to respond to this congestion marking by adapting the transmission rate, avoiding the possibility of buffering in the network.
The LAS architecture may include three main components: (a) network support to isolate LAS traffic from classic traffic and to provide appropriate congestion signaling to both types of traffic; (b) protocol features that allow network elements to identify L4S traffic and allow for communication of congestion signaling; and (c) host (e.g., application) support for immediate congestion signaling with an appropriate congestion response that enables scalable performance. Implementations described herein are directed to network support for enabling L4S service. From a network service provider standpoint, L4S may be considered a premium service that provides lower latency to specific traffic. Enabling L4S service for all traffic is not currently feasible due to incomplete adaptation of LAS at the end-device/host level, such as user equipment (UE) operating systems (OS) and application servers. Furthermore, in some instances, LAS service may need to be enabled based on application server requests to the network (in contrast with, for example, a request from a UE), which is not currently supported.
According to an implementation, a network device (e.g., a Policy Control Function (PCF) device) in a mobile network may determine to enable L4S service for a specific subscriber and data flow (e.g., also referred to herein as a quality of service (QOS) flow) based on a subscription as well as capabilities of the corresponding UE device and server device. In one implementation, core network devices may dynamically enable the L4S marking capability in a radio access network (RAN) based on the foregoing determination. In another implementation, core network devices may enable L4S marking in a transport/backhaul network through selection of a tunnel (e.g., a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) tunnel) or virtual local area network (VLAN). According to another implementation, the mobile network may support L4S for a specific set of groups or services, identified by QoS flow, as well as a subscriber's UE identifiers (subscriber profile identifier (SPID)/radio access technology (RAT) frequency selection priority (RFSP)), and network identifications, such as a network slice identifier.
UE devices 110-1 through 110-N (referred to herein individually as UE device or UE 110, and collectively as UE devices or UEs 110) may include any computing device, such as a personal computer (PC), a laptop computer, a server, a tablet computer, a notebook, a mobile device, such as wireless or cellular telephone device (e.g., a conventional cell phone with data processing capabilities), a smart phone, a personal digital assistant (PDA) that can include a radiotelephone, any type of mobile computer device or system, a game playing device, a music playing device, a home appliance device, a home monitoring device, a virtualized system, an Internet of Things (IoT) device, a machine type communication (MTC) device, etc., that includes communication functionality. UE device 110 may connect to access network 120 via access station 122-1 and UE device 110-N may connect to access network 120 via Access station 122-N. UE devices 110 may also connect to other devices in environment 100 via other techniques, such as techniques for establishing wired, wireless, optical connections or a combination of these techniques. UE device 110 and a person that may be associated with UE device 110 (e.g., the party holding or using UE device 110) may be referred to collectively as UE device 110 or UE 110 in the description below.
Access network 120 may provide access to core network 130 for wireless devices, such as UE devices 110. Access network 120 may enable UE device 110 to connect to core network 130 for Internet access, non-Internet Protocol (IP) data delivery, cloud computing, mobile telephone service, Short Message Service (SMS) message service, Multimedia Message Service (MMS) message service, and/or other types of data services. Access network 120 may provide access to core network 130, a service or application layer network, a cloud network, a multi-access edge computing (MEC) network, a fog network, etc. Furthermore, access network 120 may enable a device in core network 130 to exchange data with UE device 110 using a non-IP data delivery method such as Data over Non-Access Stratum (DoNAS).
Access network 120 may also include a Fifth Generation (5G) access network or another advanced network, such as a Fourth Generation (4G) Long Term Evolution (LTE) access network. For example, access network 120 may include the functionality of a 5G network, such as 5G Radio Access Network (RAN) communicating via mmWave technology, a 5G RAN communicating via C-band technology or other types of 5G networks. Access network 120 may also include a 4G RAN.
Access stations 122 (referred to collectively as access stations 122 and individually as access station 122) may be included in access network 120. Access station 122 may include a 5G New Radio (NR) base station (e.g., a gNodeB) and/or a Fourth Generation (4G) Long Term Evolution (LTE) base station (e.g., an eNodeB). According to an implementation, an access station 122 may include a gNodeB or its equivalent with multiple distributed components, such as a central unit (CU), a distributed unit (DU), a remote unit (RU or a remote radio unit (RRU)), or another type of component to support distributed arrangements. Each access station 122 may include devices and/or components configured to enable cellular wireless communication with UE device 110. For example, access station 122 may include a radio frequency (RF) transceiver configured to communicate with UE devices using a 5G NR air interface, a 4G LTE air interface, and/or using another type of cellular air interface.
Core network 130 may include one or more wired, wireless, and/or optical networks that are capable of receiving and transmitting data (e.g., voice and/or video) and signals. In an exemplary implementation, core network 130 may be associated with a telecommunications service provider (e.g., a service provider providing cellular wireless communication services and wired communication services) and may manage communication sessions of UE devices 110 connecting to core network 130 via access network 120. Core network 130 may include one or multiple networks of different types and technologies. For example, core network 130 may be implemented to include a next generation core (NGC) network for a 5G network, an Evolved Packet Core (EPC) of an LTE or LTE Advanced network, a sixth generation (6G) network, and/or a legacy core network. Core network 130 may provide packet-switched services and wireless Internet Protocol (IP) connectivity to various components in environment 100, such as UE devices 110, to provide, for example, data, voice, and/or multimedia services.
Core network 130 may include various network devices 140. Depending on the implementation, network devices 140 may include 5G core network components (e.g., a User Plane Function (UPF), an Access and Mobility management Function (AMF), a Session Management Function (SMF), a Unified Data Management (UDM), a Unified Data Repository (UDR), a Policy Control Function (PCF), an Authentication Server Function (AUSF), a Charging Function (CHF), a Network Exposure Function (NEF), an application function (AF), etc.), 4G core network components, or another type of core network components (e.g., future 6G network components). In other implementation, network devices 140 may include combined 4G and 5G functionality, such as a session management function with Packet Data Network (PDN) Gateway-control plane (SMF+PGW-C) and a user plane function with PGW-user plane (UPF+PGW-U).
Data network 150 may include, for example, a packet data network. In an exemplary implementation, UE device 110 may connect to data network 150 via core network 130. Data network 150 may also include and/or be connected to a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an autonomous system (AS) on the Internet, an optical network, a cable television network, a satellite network, a wireless network, an ad hoc network, a telephone network (e.g., the Public Switched Telephone Network (PSTN) or a cellular network), an intranet, or a combination of networks.
Network environment 100 may be configured to support a variety of traffic, such as traffic between a UE 110 and data network 150. According to implementations described herein, one or more networks or network segments, may support Explicit Congestion Notification (ECN) used for the L4S service. ECN/L4S may be set up with a negotiation process between endpoints (e.g., a UE device 110 and an application server, which may be in data network 150). L4S markings may be carried in IP packet headers. Once a QoS flow with LAS service is set up, ECN-capable nodes may monitor for congestion and report, via ECN bits in the IP header, when congestion is detected at a network node. According to implementations described herein, network devices in core network 130 may determine when or if the LAS service can be used for a particular QoS flow and provide parameters to define which nodes/network segments in access network 120 and/or core network 130 will provide congestion monitoring and markings for the L4S service.
The exemplary configuration illustrated in
Various functions are described below as being performed by particular components in environment 100. In other implementations, various functions described as being performed by one device may be performed by another device or multiple other devices, and/or various functions described as being performed by multiple devices may be combined and performed by a single device.
CU 222 and DU/RU 224 may include portions of access station 122, such as a gNodeB. CU 222 may connect with core network 130 (e.g., UPF 254) via a backhaul (“BH”) transport domain. CU 222 may connect with DU/RU 224 via a midhaul (“MH”) transport domain located, for example, in far edge network. The BH and MH transport domains may include intermediate links (not shown). In some implementations, the DU and RU of DU/RU 224 may be connected by a fronthaul (“FH”) transport domain (not shown). CU 222 may receive instructions from AMF 244 regarding enabling L4S service. For example, CU 222 may be directed to map a QoS flow to a L4S or non-L4S dedicated radio bearer (DRB), as indicated at reference 270. Upon initiation of LAS service for a flow, CU 222 may perform congestion detection and marking of packets (reference 278).
SMF 242 may perform session establishment, session modification, and/or session release; perform IP address allocation and management; perform Dynamic Host Configuration Protocol (DHCP) functions; perform selection and control of a UPF (not shown); configure traffic steering at the UPF to guide the traffic to the correct destinations; terminate interfaces toward PCF 246; perform lawful intercepts; charge data collection; support charging interfaces; control and coordinate charging data collection; terminate session management parts of NAS messages; perform downlink data notification; manage roaming functionality; and/or perform other types of control plane processes for managing user plane data. According to implementations described herein, SMF 242 may notify access station 122 (e.g., CU 222) via AMF 244 to create the QoS flow and enable LAS marking. SMF 242 may also instruct UPF 254 to enable L4S marking.
AMF 244 may perform registration management, connection management, reachability management, mobility management, lawful intercepts, Short Message Service (SMS) transport between UE device 110 and other network functions; session management messages transport between UE device 110 and SMF 242, access authentication and authorization, location services management, functionality to support non-3GPP access networks, and/or other types of management processes.
PCF 246 may support policies to control network behavior, provide policy rules to control plane functions (e.g., to SMF 242), access subscription information relevant to policy decisions, perform policy decisions, and/or perform other types of processes associated with policy enforcement. According to systems and methods described herein, PCF 246 may store/access L4S policies and non-LAS policies (i.e., policies 272) that may be applied to a session or QoS flow. PCF 246 can make decisions (i.e., LAS enablement decision 274) to use L4S on a QoS flow based on factors including, a subscription to L4S, UE 110 operating system capability (if known), application function 258's L4S adaptiveness (e.g., based on monitoring of responsiveness to congestion marking), specific requests from NEF 252, and/or the subscriber's spending limits. Upon a positive determination to use L4S, PCF 246 may notify SMF 242 to create a QoS Flow and enable the L4S service.
UDM/UDR 248 may maintain subscription information for UE devices 110, manage subscriptions, generate authentication credentials, handle user identification, perform access authorization based on subscription data, perform network function (NF) registration management, maintain service and/or session continuity by maintaining assignment of SMF 242 for ongoing sessions, and/or perform other processes associated with managing user data. According to implementations described herein, UDM/UDR 248 may provide L4S service subscription data (i.e., L4S service subscription 276) to PCF 246, for example, as part of a UE registration process.
NEF 252 may expose network component capabilities and events internal to corresponding core network 130 and/or data networks 150 to devices and network functions external to network 130. Furthermore, NEF 252 may secure provisioning of information from external applications to core network 130, translate information between core network 130 and devices/networks external to core network 130, support a Packet Flow Description (PFD) function, and/or perform other types of network exposure functions. According to an implementation, NEF 252 may provide an application programming interface (API, i.e., LAS Exposure API 280) to receive L4S requests from application function 258. Upon receiving an L4S request, NEF 252 may store information in UDM/UDR 248 and/or invoke PCF 246 to dynamically initiate LAS service in a QOS flow.
UPF 254 may maintain an anchor point for intra/inter-radio access technology (RAT) mobility (e.g., mobility across different radio access technologies); maintain an external Packet Data Unit (PDU) point of interconnect to a data network (e.g., an IP network, etc.); perform packet routing and forwarding; perform the user plane part of policy rule enforcement; perform packet inspection; perform lawful intercept; perform traffic usage reporting; perform QoS handling in the user plane; perform uplink traffic verification; perform transport level packet marking; perform downlink packet buffering; send and forward an “end marker” to a RAN node (e.g., access station 122); and/or perform other types of user plane processes. According to an implementation, a user plane (UP) tunnel (e.g., a GTP User Plane (GTP-U) tunnel) may carry a QoS flow between access station 122 and UPF 254. UPF 254 and access station 122 may also use specific VLAN or tunnel IP addresses to indicate on what flows to enable L4S marking.
Application function 258 (also referred to as an application server, or simply an application) may provide services for a program or an application running on UE device 110 and may establish communication sessions with UE device 110 via core network 130. Application function 258 may generally be considered outside of (e.g., not part of) core network 130. Application function 258 may be included within data network 150 or outside of data network 150 (as shown in
Based on the instructions from SMF 242, access station 122, UPF 254, and any selected transport domain devices/components may monitor a QoS flow and, if there is congestion in those domains, the devices/components may mark the traffic with congestion indications. These indications may then be utilized by the application function 258 and/or UE 110 to shape the application traffic.
Network portion 200 illustrated in
Bus 310 may provide communication paths between components of device 300. Processor 320 may include one or more processors, microprocessors, or processing logic that may interpret and execute instructions. Memory 330 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor 320. Memory 330 may also include a read only memory (ROM) device or another type of static storage device that may store static information and instructions for use by processor 320. Memory 330 may further include a solid state drive (SSD). Memory 330 may also include a magnetic and/or optical recording medium (e.g., a hard disk) and its corresponding drive.
Input device 340 may include a mechanism that permits a user to input information, such as a keypad, a keyboard, a mouse, a pen, a microphone, a touch screen, voice recognition and/or biometric mechanisms, etc. Output device 350 may include a mechanism that outputs information to the user, including a display (e.g., a liquid crystal display (LCD)), a speaker, etc. In some implementations, device 300 may include a touch screen display may act as both an input device 240 and an output device 350.
Communication interface 360 may include one or more transceivers that device 300 uses to communicate with other devices via wired, wireless or optical mechanisms. For example, communication interface 360 may include one or more radio frequency (RF) transmitters, receivers and/or transceivers and one or more antennas for transmitting and receiving RF data. Communication interface 360 may also include a modem or an Ethernet interface to a LAN or other mechanisms for communicating with elements in a network.
In an exemplary implementation, device 300 performs operations in response to processor 320 executing sequences of instructions contained in a computer-readable medium, such as memory 330. For example, the instructions may support dynamic enablement of LAS service as described herein. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read into memory 330 from another computer-readable medium (e.g., a hard disk drive (HDD), SSD, etc.), or from another device via communication interface 360. Alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the implementations described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
A decision to enable L4S for a QoS flow may be initiated in at least two different ways. As shown in
In response to either signal 404a or 404b, PCF 246 may query UDM/UDR 248 to verify that a UE has a subscription for L4S (signal 406). PCF 246 may then check the subscription, determine whether UE 110 has the capability to support L4S, review if any subscription spending limits are in place, and review server responsiveness metrics that may indicate whether AF 258 can support L4S (reference 408). Determining by PCF 246 whether to enable LAS is described further in connection with
Assuming PCF 246 determines to activate LAS for the QoS flow, PCF 246 may activate L4S with the QoS flow over the RAN or both the RAN and the transport network. To activate the QoS flow with LAS, PCF 246 may send a message to SMF 242 to activate the QoS flow with the L4S QoS parameters and transport indicators (e.g., RAN-only, RAN+transport network, etc.) (signal 410). L4S QoS parameters may define queue limits (e.g., that indicate congestion at network nodes), marking requirements, etc. Transport indicators may identify network segments (RAN, transport, etc.) where L4S will be implemented. For example, signal 410 may indicate to SMF 242 that the LAS service is to be enabled for a flow in the transport domain, or that the L4S service is to be enabled for a flow based on specific design option, such as a Tunnel IP address or virtual local area network (VLAN) address.
SMF 242 may receive the activation message from PCF 246. To activate the QoS flow with LAS over the transport network, SMF 242 may send a message to UPF 254 to enable the QoS flow with the L4S marking (signal 412). The message to UPF 254 may include QoS parameters and the transport indicators. To activate the QoS flow with L4S over the RAN, SMF 242 may send a message to AMF 244 to enable the QoS flow with the L4S marking (signal 414). The message to AMF 244 may include the L4S QoS parameters, a tunnel endpoint identifier (TEID), and the transport indicators (signal 414). AMF 244 may forward the L4S instructions to wireless station 122 for implementation (signal 416).
Upon receiving signal 412, UPF 254 may monitor the QOS flow and, if there is congestion in the transport domain, UPF 254 may mark the traffic with congestion indications. Similarly, upon receiving signal 416, access station 122 may monitor the QOS flow and, if there is congestion in the RAN domain, access station 122 may mark the traffic with congestion indications. These indications may then be utilized by the application (e.g., executing on UE 110 and AF 258) to shape the application traffic.
Process 500 may include receiving a request for a QoS flow (block 510) and obtaining L4s subscription information (block 520). For example, as described in connection with
Process 500 may also include determining whether to enable LAS for the QoS flow (block 530). For example, PCF 246 may apply a variety of factors to determine if LAS can be effectively applied for the requested QoS session. Factors for determining whether to enable LAS (i.e., are described further in connection with
As shown in
Determining whether to enable L4S may also include confirming that LS4 is with a subscriber's service limits (block 630) and confirming that the application server is responsive (block 640). For example, a subscriber may have certain spending limits (e.g., for premium level services) that may prevent/limit use of LAS if a spending threshold is reached. PCF 246 may confirm (e.g., from a local database or from UDM/UDR 248) that a user's subscription spending threshold allows LAS for a current session (e.g., that current service limits are not exceeded). Also, PCF 246 may retrieve historical records of AF 258's responsiveness to congestion marking. For example, if recent history for AF 258 shows no congestion marking during congestion periods, PCF 246 may determine that AF 258 cannot support LAS. Conversely, PCF 246 may determine that AF 258 can support L4S based on consistent use of congestion marking during previous congestion periods.
Determining whether to enable L4S may also include determining if L4S has been specifically requested (block 650) and compiling and/or weighing the decision factors (block 660). For example, PCF 246 may consider the source of an LAS trigger (e.g., AF 258 via NEF 252, or a session setup request initiated by UE device 110). In determining whether to enable LAS, certain factors in blocks 610-650 may or may not be determinative. For example, if PCF 246 confirms that the current UE OS does not support L4S (e.g., in block 620), PCF 246 may not enable LAS for a QoS flow even if a user has a subscription that includes L4S. As another example, if L4S is specifically requested by AF 258 (e.g., block 650), a UE device 110 without a premium subscription may still be approved to receive LS4 (e.g., assuming an entity associated with AF 258 has a billing arrangement with the service provider of core network 130). In other implementations, one or more factors of blocks 610-650 may be excluded.
Returning to
If L4S is not to be enabled (block 530-Yes), process 500 may include sending, to an SMF, QOS flow setup information with non-L4S QoS parameters (block 550). For example, PCF 246 may send non-L4S (classic) QoS parameters for SMF 242 to initiate a QoS flow.
Systems and methods are provided to enable mobile network operators to dynamically determine when a LAS service is to be enabled for a data flow. A network device (e.g., a PCF or similar function) in a core network may receive a request for a QoS flow associated with a user equipment (UE) device; determine whether to enable a LS4 service for the QoS flow; and notify, based on the determining, a Session Management Function (SMF) to create the QoS flow with LAS service enabled.
The foregoing description of example implementations provides illustration and description but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the embodiments.
For example, features have been described above with PCF 246 generating a LAS enablement decision based on provisioned policy and information provided other network functions. In other implementations, other network functions/elements or variations of network functions (e.g., a split core PCF) may provide a LAS enablement decision.
In addition, features have been described with respect to generating L4S enablement decisions using elements in core network 130. In other implementations, similar processing may be performed in other portions of environment 100, such as in a Multi-access Edge Computing (MEC) platform located, for example, between access network 120 and core network 130. In still other implementations, a number of PCFs 246 may be distributed in environment 100 to generate LAS enablement decisions, as described above.
Further, while a series of signal flows have been described with respect to
Certain features described above may be implemented as “logic” or a “unit” that performs one or more functions. This logic or unit may include hardware, such as one or more processors, microprocessors, application specific integrated circuits, or field programmable gate arrays, software, or a combination of hardware and software.
To the extent the aforementioned embodiments collect, store or employ personal information of individuals, it should be understood that such information shall be collected, stored and used in accordance with all applicable laws concerning protection of personal information. Additionally, the collection, storage and use of such information may be subject to consent of the individual to such activity, for example, through well known “opt-in” or “opt-out” processes as may be appropriate for the situation and type of information. Storage and use of personal information may be in an appropriately secure manner reflective of the type of information, for example, through various encryption and anonymization techniques for particularly sensitive information.
Use of ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another, the temporal order in which acts of a method are performed, the temporal order in which instructions executed by a device are performed, etc., but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.
No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
In the preceding specification, various preferred embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.
