Selective compression of packet payload data in 5G networks

Selective packet payload data compression in 5G networks addresses radio link congestion by leveraging UE resources, enhancing network efficiency and reducing infrastructure costs through intelligent congestion management.

JP7763328B2Active Publication Date: 2025-10-31INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2024507138
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2021-08-31
Filing Date
2022-07-27
Publication Date
2025-10-31
Estimated Expiration
2042-07-27

AI Technical Summary

Technical Problem

Current 5G networks face radio link congestion due to inefficient payload data compression, leading to packet transmission delays and increased infrastructure costs during peak usage, with existing methods failing to selectively utilize UE resources for congestion mitigation.

Method used

Implementing selective packet payload data compression in the PDCP layer based on congestion signals and processor utilization, allowing intelligent compression decisions to alleviate radio link congestion by leveraging UE computational resources.

Benefits of technology

Reduces radio link congestion and infrastructure costs by optimizing packet transmission latency and resource utilization, improving user experience and network efficiency in 5G networks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007763328000001
    Figure 0007763328000001
  • Figure 0007763328000002
    Figure 0007763328000002
  • Figure 0007763328000003
    Figure 0007763328000003
Patent Text Reader

Abstract

Selective compression of packet payload data in a 5G network includes receiving a congestion signal by a user equipment (UE) connected to a broadband cellular network based on network traffic congestion in hardware of the network, indicating network traffic congestion, determining a current processor utilization of the UE, determining whether to automatically enable selective packet payload data compression on the UE based on the received congestion signal, the determined current processor utilization, and a known time for data compression and decompression, compressing payload data of a data packet generated by the UE based on the determination to automatically enable selective packet payload data compression, and forwarding the data packet having the compressed payload data for transmission on the broadband cellular network.
Need to check novelty before this filing date? Find Prior Art

Description

[Background technology]

[0001] Advances in the communications industry, through improved bandwidth and other factors, have been a key enabler of many on-demand technologies, such as artificial intelligence (AI) processing and web-delivery technologies. 5G technology, which refers to the fifth generation technology standard for broadband cellular networks, is expected to further advance interdependent technologies through higher bandwidth (e.g., 1 gigabit per second), convergence of access to Internet of Things (IoT) devices, and other advancements. Summary of the Invention

[0002] The shortcomings of the prior art are overcome and further advantages are provided by providing a computer-implemented method. The method wirelessly receives a congestion signal by a user equipment (UE) wirelessly connected to a broadband cellular network. The congestion signal is received based on network traffic congestion in hardware of the broadband cellular network and indicates network traffic congestion. The method determines a current processor utilization rate of the UE. The method then determines whether to automatically enable selective packet payload data compression on the UE based on the received congestion signal, the determined current processor utilization rate, and a known time for data compression and decompression. Based on determining to automatically enable selective packet payload data compression, the method compresses payload data of data packets generated by the UE and forwards the data packets with the compressed payload data for transmission over the broadband cellular network.

[0003] Viewed from one aspect, the present invention provides a computer-implemented method that includes wirelessly receiving a congestion signal by a user equipment (UE) wirelessly connected to a broadband cellular network, the congestion signal being received based on network traffic congestion in hardware of the broadband cellular network and indicating network traffic congestion; determining a current processor utilization rate of the UE; determining whether to automatically enable selective packet payload data compression on the UE based on the received congestion signal, the determined current processor utilization rate, and a known time for data compression and decompression; compressing payload data of one or more data packets generated by the UE based on the determination to automatically enable selective packet payload data compression; and forwarding the one or more data packets having the compressed payload data for transmission over the broadband cellular network.

[0004] Viewed from another aspect, the present invention further provides a computer system including a memory and a processor in communication with the memory, the computer system configured to execute a method. The method includes wirelessly receiving a congestion signal by a user equipment (UE) wirelessly connected to a broadband cellular network. The congestion signal is received based on network traffic congestion in hardware of the broadband cellular network and indicates network traffic congestion. The method includes determining a current processor utilization rate of the UE. The method determines whether to automatically enable selective packet payload data compression on the UE based on the received congestion signal, the determined current processor utilization rate, and a known time for data compression and decompression. Based on determining to automatically enable selective packet payload data compression, the method compresses payload data of data packets generated by the UE and forwards one or more data packets having the compressed payload data for transmission over the broadband cellular network.

[0005] Viewed from yet another aspect, the present invention further provides a computer program product including a computer-readable storage medium readable by a processing circuit and storing instructions executed by the processing circuit provided to perform a method. The method wirelessly receives a congestion signal by a user equipment (UE) wirelessly connected to a broadband cellular network. The congestion signal is received based on network traffic congestion in hardware of the broadband cellular network and indicates network traffic congestion. The method determines a current processor utilization rate of the UE. The method determines whether to automatically enable selective packet payload data compression on the UE based on the received congestion signal, the determined current processor utilization rate, and a known time for data compression and decompression. Based on determining to automatically enable selective packet payload data compression, the method compresses payload data of data packets generated by the UE and forwards the data packets with the compressed payload data for transmission over the broadband cellular network.

[0006] Further features and advantages are realized through the concepts described herein.

[0007] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings: [Brief explanation of the drawings]

[0008] [Figure 1] An example of a conceptual diagram of data transmission over a 5G broadband cellular network is shown. [Figure 2] Shows the components of the 5G user plane protocol stack. [Figure 3] An example of a conceptual diagram of congestion in a 5G broadband cellular network is shown. [Figure 4] 1 illustrates a conceptual representation of a physical network function for incorporating and using aspects described herein. [Figure 5] 1 illustrates a conceptual representation of a mobile equipment (UE) for incorporating and using aspects described herein. [Figure 6] FIG. 1 illustrates wireless communication messages between a user endpoint and a 5G user plane protocol stack in a base station device according to aspects described herein. [Figure 7] FIG. 2 illustrates communications in a user plane protocol stack of a user endpoint device according to aspects described herein. [Figure 8A] FIG. 2 illustrates an example process for selective packet payload data compression according to aspects described herein. [Figure 8B] FIG. 2 illustrates an example process for selective packet payload data compression according to aspects described herein. [Figure 9] FIG. 1 illustrates an example of a computer system and related devices for incorporating and / or using aspects described herein. [Figure 10] FIG. 1 illustrates a cloud computing environment according to one embodiment of the present invention. [Figure 11] FIG. 2 illustrates abstraction model layers according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0009] Described herein is an approach for selective compression of data packet payloads in telecommunications networks, e.g., 5G broadband cellular networks. FIG. 1 illustrates an exemplary high-level conceptual diagram of data transmission over a 5G broadband cellular network and the components that exist between a client / user equipment and a communication endpoint, such as a target cloud endpoint in a core cloud. With reference to FIG. 1, a core cloud 102 is a cloud environment with which user equipment (UE) endpoints (e.g., cellular-based endpoints such as smartphones, not shown) interact. Typically, this interaction is to access services provided by computing devices in the core cloud, e.g., data-related services or cellular calling services, or both.

[0010] A UE is a user wireless device that resides in what is known as the "last mile" (104). The "last mile" is a term that refers to the link between the UE and a telecommunications provider's core network. In 5G telecommunications technology, the "last mile" typically encompasses hardware and software that facilitates wireless communication between the UE and individual base stations / wireless endpoints (106). These devices communicate via a front / backhaul network 108 with an optical access network 110 that provides connectivity to other networks (e.g., an edge cloud network 112 for 5G management and other services). The edge cloud 112 system provides a 5G service and programmability plane 114 with an infrastructure management plane 116 that works in close coordination with a service orchestration 118 to orchestrate 5G connectivity services provided to the UE.

[0011] The optical access network 110 provides connectivity and access to the core cloud 102, in this example, via an optical metropolitan network 120, which communicates with an optical core network 122 to the core cloud 102. Links / lines between components / networks represent wired / wireless communication paths for communicating data and may encompass additional / other intervening systems / networks. 5G-related data transmission occurs between the UEs and the edge cloud 112 via links 124, 126, 128. Control commands 130 may also be communicated between the wireless endpoints 106 and connected UEs.

[0012] 5G telecommunications technology, also referred to herein as 5G, "5G NR," "New Radio," or simply "NR," refers to the fifth-generation radio access technology overseen by the 3rd Generation Partnership Project (3GPP®). Figure 2 illustrates aspects of the 5G user plane protocol stack, both in a high-level view (as stack 202) and in a more detailed view 220. The NR medium access control (MAC) layer 204 provides services to the radio link control (RLC) layer 206 in the form of logical channels 224. These logical channels are virtualized communication network interfaces used to transfer input / output (IO) commands (e.g., network data packets) and control instructions over the air interface and the 5G fixed access network. Logical channels are defined by the type of information they carry and are generally distinguished as either (i) control channels, used to transmit control and configuration information, or (ii) traffic / transmission channels, used to transmit user data. 5G NR technology allows the creation of multiple logical channels over a single radio bearer network using the 5G network slicing model. Logical channels are used to transmit specialized traffic from a UE device to the 5G network. Multiple channels are created from a single device to the 5G network, which provides performance benefits by enabling parallelism in packet transmission and reducing exclusive locking of 5G network resources.

[0013] In particular, downlink packet flows 214 for two UEs (UR1, UEn) via the user plane stacks 202 / 220 of the UE devices proceed via a Quality-of-Service (QoS) flow 222 to a QoS flow processing component 223 of the Service Data Adaptation Protocol (SDAP) layer 210. The packets enter the Packet Data Convergence Protocol (PDCP) layer 208 via a radio bearer 226 for Robust Header Compression (ROHC) 228 and security processing 230 (e.g., encryption). The packets are then forwarded via an RLC channel 232 for segmentation automatic repeat request (ARQ) 234 in the RLC layer 206. The packets are transmitted via a logical channel 224 to the MAC layer 204 for scheduling / priority processing 236. The MAC layer multiplexes 238 packets destined for each UE for Hybrid Automatic Repeat Request (HARQ) 240 error control / correction, then down to the physical layer 212 via transmission channel 242 and references the physical device hardware for transmission over the network.

[0014] The PDCP layer traditionally performs header compression, encryption, and other data convergence activities such as packet alignment for packet transmission over the physical infrastructure. In typical PDCP processing, the packet headers of 5G data packets are compressed, but the packet payload, i.e., the packet's payload data, is not. However, the ability to compress the payload of 5G data packets exists. In such an implementation, PDCP includes a compression mechanism that captures data packets from higher-layer protocols (e.g., SDAP in the UE stack) and compresses the entire packet using existing compression techniques / algorithms such as Huffman coding or LZ77 before transmitting the packet over the radio link interface. Because the complete payload is compressed (potentially in addition to separate, optional ROHC compression), it reduces the traffic load on the RLC, MAC, and PHY radio link layers, potentially providing better congestion control in NR technology. This further helps improve the capacity of the radio interface and also benefits NR multiplexing.

[0015] A payload compression mechanism may be injected into the 5G UE's PDCP to collect received packets and perform data (packet payload) compression and convergence for each packet coming from higher layers of the system. Advances in next-generation telecommunications networks and application software will increase the number of dedicated logical channels from the application layer to E-UTRAN Node B devices (also known as "Evolved Node B," "eNodeB," or "eNB" devices) used for data transmission over the cellular network interface. E-UTRAN Node B devices are referred to as "eNodeBs." In the context of 5G technology, eNodeBs may be referred to as "5G Evolved Node Bs," "5G eNodeBs," "gNodeBs," "Next Generation eNodeBs," "NG eNBs," or "5G eNB" devices to transmit data over NR. For brevity, "eNodeB" is used to encompass any of the aforementioned devices, i.e., devices capable of traditional 3G, 4G / LTE, or 5G technology, or a combination thereof, and references to eNodeBs herein may encompass 5G Evolved Node B devices.

[0016] In these implementations, all application channels send packets to PDCP, after which the lower protocols that process the packets forward the data to its destination over the radio link. Once the data is sent to the PDCP layer, PDCP handles alignment and data convergence before forwarding it to RLC control. As 5G enables a software-defined network slicing model, user plane protocols need to be optimized to adopt software-defined control of logical channels (Dedicated Traffic Channels, or DTCHs) that take into account NR congestion situations.

[0017] Introducing PDCP processing to incorporate packet payload data (and ROHC header) compression into NR introduces latency and increases the time and space complexity of the compression algorithm, making it unsuitable for use in some situations. This is one of the reasons why many applications and logical channels do not adopt PDCP-based payload compression as the default for UE devices. When PDCP is used to compress payloads / full packets, the time required for that compression (and subsequent decompression at the receiving device) can significantly impact radio and network latency. For all mobile applications, using full-payload data compression to reduce network load is not practical. For this reason, applications typically prefer to send uncompressed packets over the radio link (which are further converted to S1 bearers), which contributes to increased data transmission over the radio. 5G is expected to support real-time data transmission for speed-sensitive applications like augmented reality and many other data-intensive applications, where data transmission over the radio link represents a relatively large load.

[0018] During peak network access periods, NR technology radio links can become congested due to unavailable packet data transmission slots in radio link multiplexing. NR logical channels, called dedicated traffic channels (DTCHs), use multiplexing to share available radio link resources. Provisioning the necessary virtual infrastructure (VI) for eNodeBs and UEs to support end-user devices requires hardware elements, either directly supporting the traffic multiplexing over the shared infrastructure or emulating it through software. This can lead to radio link congestion during peak periods when many users access the same set of resources. One common scenario is when many additional users begin connecting to the eNodeB and creating DTCHs. The physical network function (PNF), implemented in software on dedicated PNF hardware elements and responsible for controlling the eNodeB, can become a bottleneck.

[0019] FIG. 3 illustrates an example of a conceptual diagram of congestion in a 5G broadband cellular network. The 5G network 300 includes a core network portion 302, also referred to as a "fixed access network" (FAN), and a radio access network (RAN) portion 304, including an eNodeB 306 and a UE 308. In a practical application, the 5G network includes multiple eNodeBs and respective UEs connected to each such eNodeB. A UE is a mobile device or any wireless device that connects to a 5G cellular network. The UE 308 communicates with the eNodeB 306 via the RAN using established RAN protocols. The eNodeB 306 converts RAN traffic to FAN traffic (e.g., public switched telephone network (PSTN) traffic). The channels between the RAN and the FAN are called S1 bearer links / channels. One such channel is the S1u to the serving gateway (S-GW) 310 for communication via a packet data network gateway (P-GW 312) and S5 / S8 links to a core cloud (not shown). Another such channel is S1c to a mobility management entity (MME) 314, which also connects to the S-GW 310 via an S11 link.

[0020] Although only a single eNodeB of the RAN is shown in FIG. 3, there are typically multiple eNodeBs, each with its own communication path to the back-end component, i.e., the core network 302.

[0021] A PNF bottleneck situation could occur, for example, at the eNodeB 306, S-GW 310, MME 314, or P-GW 312, or a combination thereof. Applications utilizing 5G connectivity will experience packet transmission delays, resulting in unpredictable behavior and impaired real-time usability. Tagged DTCHs have a Quality-of-Service Class Identifier (QCI) mechanism to aid in radio split scheduling, but congestion may exceed the capabilities of traditional QCI handlers. This can result in dropped / lost packets, a degraded user experience for affected applications, or even application crashes.

[0022] Current approaches fail to provide a way to address this situation, such as making compression decisions based on the available computational bandwidth of the "last mile" device (e.g., UE) or interacting with the PDCP layer for selective payload compression of packets transmitted on the NR DTCH path. Because payload compression adds additional latency to data transmission rates due to the complexity of the compression algorithm, it is desirable to provide selectivity in enabling data compression. Such selectivity can be based on actual or predicted PNF / radio link congestion and delivery statistics, as described herein. In the event of radio link and / or PNF congestion, conventional approaches lack a way to leverage UE resources (if available) to minimize radio link traffic (which reduces PNF processing) and reduce radio resource congestion. Furthermore, there is no way to select which PDCP channels to compress, for example, based on QCI values ​​and application packet tagging, to reduce the impact of additional compression / decompression processing and provide better performance in congested 5G cellular networks.

[0023] Accordingly, aspects described herein provide an approach operating in a 5G user plane protocol stack for communicating with a DTCH controller and PDCP layer of the user plane protocol stack to address radio resource congestion at the eNodeB or PNF level of a 5G fixed access network by providing intelligent and selective data packet payload compression at the PDCP layer. Specifically, when transmitting packets over a physical link from a UE to a 5G network, packet compression is selectively triggered and performed prior to data convergence. This provides an optimized method of selective packet payload compression, optionally in combination with ROHC and PDCP encryption, for traffic of designated UE applications that rely on a 5G connection. Some aspects provide for selective payload compression at the UE instance and communication of the compressed packets to a 5G eNodeB / PNF device for packet decompression, thereby providing RAN traffic and congestion mitigation, for example, during DTCH overloads ("DTCH storms"). Further aspects provide observation of existing and tolerable packet delays in combination with computational processing delays based on QCI indexing and application mappers to facilitate determining when to selectively enable PDCP processing to perform payload compression of data packets, thereby reducing RAN congestion in 5G networks and further saving reserved infrastructure costs for handling RAN and PNF congestion in 5G networks.

[0024] Selective compression is applied to packets flowing between the UE and the eNodeB device, which in some embodiments, encompasses, by way of example, compression of packets from the UE for the uplink to the eNodeB / Radio Access Network endpoint, and in other embodiments, compression of packets from the RAN endpoint (e.g., a PNF device or eNodeB) for the downlink to the UE. Also, note that selective compression of packet payload data can refer to compressing the entire data packet or the portion thereof that includes the payload data of the data packet.

[0025] One aspect includes a software instance running on a PNF of the 5G stack (e.g., on hardware providing a portion of the PNF). This instance monitors resource utilization and traffic congestion of eNodeBs and, optionally, other components of the link to the core network (e.g., S-GWs including S1 bearer channels, located in front of MMEs), where such components implement the PNF. By way of example, one or more eNodeBs may be congested, or the PNF device itself may be overloaded, or both. More generally, resource utilization and congestion levels from a network traffic routing perspective may be evaluated for any component of the RAN. In this regard, resource monitoring tools and notification components may be deployed on physical components (e.g., eNodeBs and PNF devices) to detect resource consumption and potential traffic congestion. The monitoring tools may notify PNF instances running on physical devices (eNodeBs or otherwise) when congestion reaches / exceeds a configurable threshold. When a RAN radio link (over-the-air) resource component becomes overloaded / congested, a congestion signal is generated, for example, by a software instance of a PNF running in the eNodeB or elsewhere, and provided to downstream components, such as UEs connected to the eNodeB controlled by the PNF, to notify the UE that selective packet compression may be possible. Additionally, the eNodeB may use the determination to identify that selective packet compression may be implemented to compress packets flowing down to the UE, for example, if the UE indicates that it can tolerate an increased workload due to compression / decompression activity.

[0026] The PNF formulates a congestion signal and provides it as a command in a Broadcast Control Channel (BCCH) frame to the eNodeB, which can then transmit it over the air link interface to connected UEs. The congestion signal is provided as a broadcast frame and is received, for example, by all 5G-enabled devices currently communicating with the eNodeB. A software instance running on the client / UE device uses this as a network congestion hinting signal from the 5G upper layer stack to determine whether to automatically enable selective packet payload data compression on the UE.

[0027] The client instance monitors BCCH events that indicate congestion on the radio link / PNF. When a BCCH event is received with a congestion signal indicating congestion, an embodiment can monitor the packet latency experienced over the NR and monitor the UE's resource utilization to determine whether implementing packet compression is worthwhile, i.e., whether the additional computational processing to compress transmitted packet payload data, for example, will result in a net reduction in the detected congestion. This may depend on the packet delay budget, which indicates how much latency the affected endpoint application can tolerate. If an application can tolerate a maximum delay of 20 milliseconds (ms), and PDCP processing requires 10 ms to compress and decompress packets of application data, and the network latency is 5 ms, the overall processing delay would be 10 ms compression time + 5 ms network latency + 10 ms decompression time = 25 ms, which exceeds the 20 ms packet delay budget and therefore compression is not a viable option.

[0028] Furthermore, if packet transmission latency (congestion traffic latency) is 20 ms, PDCP compression requires 10 ms, and network latency with compression enabled (i.e., congestion alleviated) is 5 ms, the overall processing latency will still be 25 ms, which is greater than the 20 ms congestion latency. In this case, there is no benefit to performing additional PDCP processing for compression / decompression. However, if compression / decompression alleviates congestion so that the overall latency for compression / decompression is less than the current congestion latency, it may be desirable to compress packets in that situation until the congestion is sufficiently alleviated. Eventually, if congestion is sufficiently low or nonexistent, compression / decompression is expected to begin adding to the overall latency of packet transmission. Therefore, such predicted latency insights can guide the decision to perform additional PDCP processing for compression / decompression accordingly.

[0029] Based on the occurrence and provision of congestion signals, a decision can be made as to whether to apply packet payload data compression. One factor that determines whether to actually compress packet payload data in a congested network situation is the current CPU utilization / consumption of the relevant endpoint / node. Therefore, the current CPU utilization of the UE can be determined and used to determine whether to perform PDCP payload data compression. In situations where CPU utilization is below a certain threshold (which may be a user-configured threshold or a threshold configured based on PDCP processing requirements), additional PDCP processing that compresses packet payload data can be enabled to alleviate network congestion. In situations where CPU utilization is above a threshold and additional CPU resources to compress packet payload data may lead to excessive utilization of processing resources, a decision can be made to refrain from payload compression.

[0030] When selective compression is enabled, all packets transmitted by the UE or only some packets can be compressed. Which packets are compressed can be a function of the logical channel (DTCH) that transports the packets. In an embodiment that allows compression on a per-logical channel (DTCH) basis, a process collects a list of DTCHs established between the eNodeB and the UE and their respective QCI values. This is done to understand the channel characteristics between the channels. The QCI values ​​are categorized based on guaranteed bit rate (GBR) and non-GBR modes, as well as by the associated packet delay budget of the DTCH. DTCHs with larger packet delay budgets (PDBs) and, optionally, larger packet error loss rates are identified to determine which DTCHs are mapped to low-budget applications. Typically, these DTCHs are mapped to applications that can tolerate data loss and delayed packet delivery over the network. As an example, a QCI of 66 indicates GBR for non-mission-critical user plane push-to-talk voice traffic, and a QCI of 75 indicates GBR for V2X traffic. Non-GBR traffic uses other dedicated QCI indices. This information can be provided to the PDCP data convergence layer by the protocol frame transmission for packet payload compression by the PDCP component.

[0031] Therefore, when selective compression is enabled, whether or not to compress received payload data can be a function of the DTCH transmitting the packet data. In this regard, whether or not to compress a given packet can be determined per logical channel (e.g., the channel ID of each packet). If compression is performed for packets on a given channel, packets on that channel are compressed from the SDAP layer.

[0032] Selective compression may remain enabled until a compression disable signal is generated / received (e.g., by / from the eNodeB) indicating that selective compression should be disabled, which may occur in some instances when it is determined that the threshold level of network congestion (which triggered selective compression) has been resolved.

[0033] When a packet enters the PDCP layer from higher layers in the 5G user plane protocol stack, additional PDCP congestion control information can be tracked by the PDCP payload compression module. If selective compression is enabled for the DTCH / data stream associated with the packet, software in the PDCP layer performs payload compression and sends the packet to the RLC layer for transmission over the radio link. This may be performed at the UE endpoint, for example, for transmission to the eNodeB.

[0034] The compression state of a packet (i.e., via a compression state indicator that indicates whether the packet payload is compressed) can be fixed to the packet in transit. The indicator can then be checked by any one or more components / devices, such as, for example, a device responsible for decompressing the packet payload data. The indicator can be checked, for example, by a Virtual Network Function (VNF) of an eNodeB or S-GW responsible for decompressing the packet payload data.

[0035] Furthermore, if CPU utilization rises above a threshold even when selective compression is enabled and running, the UE's OS or other component, aware of the above-threshold utilization, can send a stop signal to processes / services in the UE and / or eNodeB to stop additional compression processing and prevent further increases in CPU utilization due to compression / decompression activity. Similarly, if CPU utilization is already above a threshold when the UE receives a congestion signal from the eNodeB, the UE can automatically decide not to take action to enable payload data compression and, optionally, respond that the UE is unable to selectively compress packets due to high CPU utilization. As yet another example, the UE's CPU utilization can be provided by the UE to the eNodeB or other control entity, which can determine whether the UE device should undergo additional processing to compress payload data of transmitted packets or decompress payload data of received packets.

[0036] When the congestion causing the congestion signal decreases below some threshold, such that selective compression is disabled, the PNF instance can transmit a BCCH frame to the eNodeB / UE to indicate that the radio link is no longer congested. The receiving UE can decode the frame to see the congestion-cleared indicator and return to its normal operating mode, where packet payload data is not compressed. Note that the general compression of the entire payload data / packet according to the selective compression described herein may be independent of the compression of packet headers performed by the PDCP layer. Headers can optionally be compressed according to conventional PDCP header compression techniques, regardless of whether selective packet payload data compression is enabled or disabled.

[0037] This allows for the utilization of available CPU resources to help alleviate radio link congestion at the eNodeB, for example, when a surge in user access is expected or detected in a certain area. Furthermore, the process can selectively apply compression to packets only if it is determined that this will improve latency to the application layer of the UE device. Because the QCI can be verified before making a decision to compress a given packet, selective compression can be applied to packets that can tolerate transmission delays at an acceptable application impact level, while not being applied to other packets. In some examples, selective compression to alleviate network congestion can be enabled by eNodeB and PNF devices in 5G networks to handle bursts of UE connection activity, thereby reducing the cost of additional infrastructure buffers.

[0038] The described aspects address radio link congestion in NR technologies through intelligent packet data processing, reducing infrastructure and hardware costs for buffer resource pooling at the eNodeB by using the computational bandwidth available at the "last mile" UE to handle radio link congestion on multiplexed channels. The aspects intelligently select packets to compress so that the impact of additional PDCP processing to compress the packet's payload data does not exceed the tolerance of the affected application. This improves the PDCP compression approach for efficient utilization of mobile resources. The aspects also improve packet transmission latency from the application to the network, leading to an improved user experience in situations where 5G resources are congested.

[0039] 4 shows a conceptual representation of a Physical Network Function for incorporating and using aspects described herein. The 5G radio link architecture encompasses Physical Network Functions (PNFs) and Virtual Network Functions (VNFs), where the PNFs include the hardware infrastructure that controls multiple base transceiver stations / eNodeBs.

[0040] 4, the radio access network 402 includes, by way of example, client UEs, dedicated and non-dedicated sensing devices, and different types of base stations communicating with each other and communicating with a control entity (control center 404) via data flows (e.g., including power measurements) toward the control center 404. The control center 404 includes components for data collection, storage, and updating (406), radio map estimation 408 for providing radio map functions 412 to the component 406, and spectrum management 410, and performs data flow communication therebetween. Additionally, the control center 400 communicates control flows, such as, for example, proactive radio resource allocation, spectrum monitoring, and other control, to the RAN 402 devices, which can be received by the base stations for propagating the control flows to the individual devices.

[0041] The control center 404 controls the S1 bearer link on the physical access network. 420The physical access network is connected to the PNF 430 via a 5G orchestration service 450 that communicates with the PNF 430 and provides multi-domain orchestration 452 and a service programmability framework 454. The PNF 430 includes a BCCH framer 432 for generating and forwarding frames as discussed herein to signal congestion to the UE, a resource monitor 434 for monitoring network equipment resources and receiving indications of utilization / overutilization of network equipment such as eNodeBs, PNFs, and bearer links, congestion detection logic 436 for determining when network congestion exists, an eNodeB connector API 438 for communicating / talking with eNodeBs, a resource configuration map 440 having inventory and configuration information of network resources including an indication of which devices access which eNodeBs, a compression and decompression engine 442 for compressing / decompressing packets according to aspects described herein, a threshold policy 444 for identifying network congestion conditions and triggering congestion signals, and a PDCP status extractor 446 for decoding the current levels of PDCP-based data and payload compression settings.

[0042] If congestion exists with respect to only one or more (but not all) eNodeBs controlled by a given PNF, congestion signals may be propagated via those congested eNodeBs to the UEs at those eNodeBs, which may decide whether to enable selective compression of packets flowing from those UEs to one or more eNodeBs.

[0043] If a congestion problem exists within the PNF itself, it will affect all eNodeBs served by that PNF, in which case a congestion signal may be sent to all eNodeBs. Selective compression may be enabled for all packets flowing to or from all such eNodeBs. In this regard, where congestion exists, the paths carrying packets that may be eligible for selective compression are notified.

[0044] The historical data 414 can be used to identify a timeline of congestion and potentially identify patterns / features that can predict when congestion is likely to occur. The time frame in which congestion is predicted to occur can inform a time to proactively send congestion signals to enable selective packet compression / decompression at the UE, even before congestion materializes. In this regard, selective compression can be automatically and proactively triggered to address predicted congestion based on historical trends. Additionally / alternatively, selective compression can also be enabled based on actual congestion observed / detected in real time, as described above.

[0045] An example flow in a PNF function according to aspects described herein is as follows: First, resource monitoring begins in the Physical Network Function (PNF) of the 5G stack, monitoring resources such as the eNodeB, PNF, and other resources in front of the S-GW for overload conditions. A notification generator may also be deployed on the resources to provide a vehicle for notifying the PNF of congestion. The flow polls the utilization of the eNodeB, S1 bearer link, and PNF resources and checks whether any utilization is above a configurable threshold. If so, the flow identifies the type of resource congestion (e.g., PNF or eNodeB) from the resource mapper (#440 in Figure 4). The PNF generates a congestion signal command on a BCCH frame. The BCCH framer (#432 in Figure 4) generates messages for the eNodeB and the radio access network. The BCCH framer sends a STRUCT FRAME to the PNF, and the PNF receives the frame using the BCCH controller API. The broadcast frame is sent to 5G-enabled devices communicating with the eNodeB via the radio access network's multiplexing framework. Software on the client device (UE) uses this as a network congestion hinting signal from the 5G upper layer stack. The flow then reverts to re-polling resource utilization to determine if congestion still exists. Once congestion falls below the appropriate threshold, selective compression can be disabled using a similar process, but the compression disable signal indicates that the network is no longer congested.

[0046] 5 illustrates a conceptual representation of a mobile device (e.g., UE) for incorporating and using aspects described herein. The UE 500 executes the above-described operating system (OS) 502 upon which applications execute. The UE 500 includes a BCCH decoder 504 for decoding received frames, such as frames providing congestion signals for network congestion (i.e., potentially enabling selective compression of packet payload data) and / or disabling selective compression. The UE 500 also includes a compression daemon 506 for performing packet payload data / full packet compression, a resource monitor 508 for monitoring the resources of the UE 500, a PDCP connector API 510 for communicating with the PDCP layer, a CPU monitor and real-time statistics collector 512 (a specialized form of the resource monitor 508), a loan threshold policy 514, a latency calculator 516, a savings monitor 518, a congestion monitor 520 for detecting congestion in a RAN connection 526 to an eNodeB 524, and a device OS connector interface 522. The loan threshold policy 514 indicates the limit of local CPU that the mobile device's CPU can use for compression and decompression activities. The limit can be collected as a defined, user-configurable input. The latency calculator 516 is a latency management process that calculates packet transmission latency and packet round-trip time. The savings monitor 518 is a process that calculates transmission time savings based on the overall round-trip time and the device's compression latency requirements. The congestion monitor 520 detects 5G network congestion, and the device OS connector interface 522 is a low-level application programming interface for querying CPU, memory, and other system resources.

[0047] An example flow in a UE device according to aspects described herein is as follows: The client / UE software polls for BCCH events with congestion signals indicating congestion on the radio link / PNF. When a BCCH event is received, the flow extracts the function opcode, and if it indicates a congestion signal, the flow monitors the packet latency experienced on the NR connection. If the packet transmission delay is shorter than the processing time for packet compression and packet decompression, selective compression is not activated. Otherwise, if this overall processing delay is smaller than the existing delay, an appropriate message is sent to PDCP, and the flow obtains the CPU utilization (e.g., by sending a message to a platform message queue) and derives the CPU utilization threshold from a configuration file or STRUCT CONFIG MAP (e.g., a configuration map loaded at the start of the process, which can include any necessary user-defined values ​​such as CPU thresholds), which indicates which CPU core utilization threshold must be below to activate selective compression, and compares the current CPU utilization with the threshold. If the current CPU utilization is less than the threshold, selective PDCP payload data compression is enabled; otherwise, it is not enabled. The flow starts collecting established logical channels (COLLECT_DTCH) and associated QCI values, classifies QCI values ​​as GBR or non-GBR, and identifies the packet delay budgets of various channels. Logical channels with larger packet delay budgets and, optionally, larger packet error losses are identified, and the DTCHs to be mapped to low-budget applications are determined. This information is sent to the PDCP data convergence layer. When data is received at the PDCP layer, the channel ID for that data is identified, and if compression is enabled for that channel ID, PDCP packet payload data compression is applied. The compressed data packets are sent to the RLC layer and transmitted over the radio link. The compression status is also fixed to the packet, allowing downstream components to know when to decompress the packet data.If the CPU utilization exceeds the utilization threshold for enabling selective compression, the UE OS sends a signal to disable selective compression to reduce the UE CPU load. Additionally, the PNF can send a BCCH frame to notify the UE when the congestion is resolved to disable selective compression and resume normal UE operation without compressing packet payload data.

[0048] 6 illustrates wireless communication messages between 5G user plane protocol stacks of a UE 602 and a gNodeB 650 in accordance with aspects described herein. Based on congestion detection, the SDAP layer 652 of the gNodeB 650 sends a congestion signal 612 indicating the congestion to the SDAP layer 604 of the UE 602. The SDAP layer 604 returns an acknowledgement 614 that it received the congestion message. The PDCP layer 606 of the UE 602 communicates compressed payload data 616 with a compression status indicator to the PDCP layer 654 of the gNodeB 650. The RLC layer 608 of the UE 602 sends a packet payload message 618 to the RLC layer 656 of the gNodeB 650, which acknowledges receipt by sending back an acknowledgement message 620. The MAC layer 610 / 658 can exchange MAC-based VNF commands, and the physical layer 611 / 660 is for transmitting / receiving packets on the physical link.

[0049] FIG. 7 illustrates communications in a user plane protocol stack of a UE device in accordance with aspects described herein. An application instance 706 in the application layer 708 communicates a STRUCT_TYPE message 710 to a resource monitor in the SDAP layer 704, where the STRUCT_TYPE indicates what type of packet (e.g., compressed or uncompressed) is being transferred. The resource monitor 712 determines whether selective compression is enabled and sends a compression_enable(packet / DTCH_ID) message 714 to the PDCP layer 716, indicating the packet / logical channel ID for compression. The resource monitor can utilize the QCI locator 713 in determining whether a particular logical channel passing payload data is enabled for selective payload data compression. Meanwhile, a compression type message 702 is provided to the application instance by the SDAP 704 to indicate the compression type to be applied, if applicable. The PDCP layer 716 provides compressed payload data (STRUCT COMP) 718 to the RLC layer 720 for transmitting the converged packet over the 5G network via physical hardware.

[0050] 8A-8B illustrate example processes for selective packet payload data compression according to aspects described herein. Aspects of the processes are performed by a processing / computer system, such as one that includes or is incorporated in a UE, an eNodeB, a PNF device, or one or more other computer systems, or a combination thereof. Example process FIG. 8A includes aspects performed by a PNF device.

[0051] Referring to FIG. 8A, a process monitors 802 for network traffic congestion on a radio link of a broadband cellular network, where the radio link congestion is congestion in a radio base station (e.g., a gNodeB / eNodeB device) of the broadband cellular network, a PNF device (either a PNF executing the process of FIG. 8A for another PNF), or both. The broadband cellular network is, for example, a 5G new radio network. In some examples, this monitoring 802 is performed by monitoring resources and modifying the PNF when resources are overloaded. The process determines 804 whether congestion is observed, and if congestion is observed (804, Y), transmits a congestion signal to one or more UE devices 806, for example, as a BCCH broadcast frame if a congestion signal notifying this congestion has not already been transmitted. Each UE communicates directly with a radio base station (e.g., an eNodeB) of the broadband cellular network. After 806, the process returns to 802 to further monitor for traffic congestion.

[0052] If congestion was not observed in 804 (804,N), the process determines (808) whether a congestion signal was previously transmitted indicating a congestion condition that was not known to have been resolved until it was determined that the congestion had been resolved (804,N). If no (808,N), the network remains uncongested, and the process returns to 802. If yes (808,Y), a congestion signal was previously transmitted to indicate congestion, but the network has now recovered and is no longer congested. Therefore, the process transmits a compression disable signal to the UE (810), and then returns to 802 and repeats.

[0053] Process FIG. 8B illustrates an aspect performed by a UE according to aspects described herein. The process is triggered, for example, by receiving a congestion signal from a PNF device (per 806 in FIG. 8A). The UE is wirelessly connected to a broadband cellular network, such as a 5G network.

[0054] The process wirelessly receives a congestion signal indicating network traffic congestion based on network traffic congestion in broadband cellular network hardware (e.g., an eNodeB or PNF device, or both). The process determines a current processor utilization rate of the UE (822) and monitors packet transmission latency over a wireless radio link between the UE and the broadband cellular network (824). At this point, having received the congestion signal, determined the current processor utilization rate, and knowing the time it takes for data compression (e.g., at the UE) and decompression (e.g., at the receiving network device) to be performed, the process determines whether to automatically enable selective packet payload data compression on the UE. Accordingly, the process compares the current CPU utilization rate with a utilization rate threshold configured for the UE and determines whether the utilization rate is at or below the threshold (826). If NO (826, N), the process ends. If YES (826, Y), the process proceeds by determining 828 whether selective packet payload data compression results in a net reduction in the time to transfer payload data over the broadband cellular network compared to the packet transmission latency. As an example, query 828 determines that selective packet payload data compression results in a net reduction in the time to transfer payload data over the broadband cellular network based on the sum of (i) the known time to compress the payload data, (ii) the known time to decompress the payload data, and (iii) the known time to transmit the payload data if compressed being less than the packet transmission latency.

[0055] If query 828 is answered negatively (828,N), the process ends. If yes (828,Y), the process determines and enables (830) selective packet payload data compression automatically. Based on determining to automatically enable selective packet payload data compression, the process compresses (832) payload data of one or more data packets generated by the UE and forwards the one or more data packets with the compressed payload data for transmission over the broadband cellular network. In an embodiment, the compression is performed at a Packet Data Convergence Protocol (PDCP) layer of the UE's user plane stack. The PDCP layer can be configured to perform compression of header data of one or more packets regardless of whether selective packet payload data compression is enabled or disabled. Additionally, as part of the compression of the packet payload data, the process can pin a compression status indicator to each of the one or more data packets that indicates to other devices in the broadband cellular network that the payload of the data packet has been compressed.

[0056] Optionally, whether payload data is actually compressed when selective compression is enabled may be a function of the particular dedicated logical channel involved. For example, one or more packets are for transmission on a particular dedicated logical channel associated with a quality of service class identifier (QCI) that the UE has established with the broadband cellular network. The process in this example may optionally check whether compression is enabled for the dedicated logical channel, which may be based on the QCI associated with the dedicated logical channel. Compression (832) may be performed based on such a check indicating that compression is enabled for that dedicated logical channel. If it is not enabled for that channel, the process may terminate (or may continue processing more received payload data for selective compression).

[0057] Payload data compression continues, but periodic or aperiodic checks are made to determine whether it should continue. For example, the process determines (834) whether CPU utilization has increased to exceed a utilization threshold. If yes (834, Y), the process disables (836) selective packet payload data compression on the UE and terminates. Alternatively, if CPU utilization has not exceeded the threshold (843, N), the process determines (838) whether a compression disable signal has been received from the PNF device. If no (838, N), the process returns to 832 to continue applicable payload data compression. Otherwise, a disable signal has been received (838, Y), and the process disables (836) selective packet payload data compression on the UE and terminates thereafter.

[0058] Although various embodiments are provided, variations are possible without departing from the scope of the claimed invention.

[0059] The processes described herein may be performed by one or more computer systems, singly or collectively. Such computer systems may be or be incorporated into one or more devices of a telecommunications network, such as, by way of example, one or more PNF devices, gNodeB devices, or UE devices, or a combination thereof. Figure 9 shows an example of such a computer system and related devices for incorporating and / or using aspects described herein. A computer system may also be referred to herein as a data processing device / system, a computing device / system / node, or simply a computer.

[0060] FIG. 9 illustrates a computer system 900 in communication with an external device 912. The computer system 900 includes one or more processors 902, such as, for example, a central processing unit (CPU). A processor may include functional components used to execute instructions, such as functional components that fetch program instructions from a location such as a cache or main memory, decode the program instructions, execute the program instructions, access memory for instruction execution, and write results of executed instructions. The processor 902 may also include registers used by the one or more functional components. The computer system 900 also includes memory 904, input / output (I / O) devices 908, and I / O interfaces 910, which may be coupled to the processor 902 and each other via one or more buses and / or other connections. The bus connections may represent any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and without limitation, such architectures include Industry Standard Architecture (ISA), Micro Channel Architecture (MCA), Enhanced ISA (EISA), Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI).

[0061] The memory 904 may be or include a main memory or system memory (e.g., random access memory) used to execute program instructions, a storage device such as, for example, a hard drive, flash media, or optical media, or a cache memory, for example, or a combination thereof. The memory 904 may include a cache, such as, for example, a shared cache that may be coupled to a local cache (e.g., an L1 cache, an L2 cache, etc.) of the processor(s) 902. Additionally, the memory 904 may be or include at least one computer program product having a set (e.g., at least one) of program modules, instructions, code, etc., configured to perform the functions of the embodiments described herein when executed by one or more processors.

[0062] The memory 904 can store an operating system 905 and other computer programs 906, such as one or more computer programs / applications that execute to perform aspects described herein. In particular, the programs / applications can include computer-readable program instructions that can be configured to perform the functions of embodiments of the aspects described herein.

[0063] Examples of I / O devices 908 include, but are not limited to, microphones, speakers, global positioning system (GPS) devices, cameras, lights, accelerometers, gyroscopes, magnetometers, sensor devices configured to sense light, proximity, heart rate, body and / or ambient temperature, blood pressure and / or skin resistance, and activity monitors. While the I / O devices can be incorporated into the computer system as shown, in some embodiments, the I / O devices can be considered external devices (912) coupled to the computer system via one or more I / O interfaces 910.

[0064] The computer system 900 can communicate with one or more external devices 912 via one or more I / O interfaces 910. Exemplary external devices include a keyboard, a pointing device, a display, or any other device that allows a user to interact with the computer system 900, or a combination thereof. Other exemplary external devices include any device that allows the computer system 900 to communicate with one or more other computing systems or peripheral devices, such as a printer. A network interface / adapter is an exemplary I / O interface that allows the computer system 900 to communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, to provide communication with other computing devices or systems, storage devices, etc. Ethernet-based interfaces (e.g., Wi-Fi) and Bluetooth® adapters are examples of network adapters currently available for computer systems (BLUETOOTH is a registered trademark of Bluetooth SIG, Inc., Kirkland, Washington, USA).

[0065] Communication between I / O interface 910 and external device 912 may occur via a wired and / or wireless communication link 911, such as an Ethernet-based wired or wireless connection. Exemplary wireless connections include cellular, Wi-Fi, Bluetooth, proximity-based, short-range wireless, or other types of wireless connections. More generally, communication link 911 may be any suitable wireless and / or wired communication link for communicating data.

[0066] A particular external device 912 may include one or more data storage devices that may store one or more programs, one or more computer-readable program instructions, or data, or a combination thereof. Computer system 900 may include, or be coupled to and in communication with (e.g., as an external device to the computer system), removable / non-removable, volatile / non-volatile computer system storage media, or both. For example, it may include, or be coupled to, a non-removable, non-volatile magnetic medium (typically called a "hard disk"), a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), or an optical disk drive for reading from and writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM, or other optical media, or a combination thereof.

[0067] The computer system 900 is operational with numerous other general purpose or special purpose computing system environments or configurations. The computer system 900 may take any of a variety of forms, well-known examples of which include, but are not limited to, personal computer (PC) systems, server computer systems such as messaging servers, mobile devices / computers such as thin clients, thick clients, workstations, laptops, handheld devices, smartphones, tablets, and wearable devices, multiprocessor systems, microprocessor-based systems, telephony devices, network appliances (such as edge devices), virtualization devices, storage controllers, set-top boxes, programmable appliances, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0068] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the present invention may be practiced in conjunction with any other type of computing environment now known or later developed.

[0069] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five characteristics, at least three service models, and at least four implementation models.

[0070] The characteristics are as follows: On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider. Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, PDAs). Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated based on demand. Consumers generally have no control or knowledge of the exact location of the resources they are provided with, resulting in a sense of location independence. However, consumers may be able to determine location at a higher level of abstraction (e.g., country, state, data center). Rapid Elasticity: Computing capacity can be provisioned quickly and elastically, sometimes automatically, to instantly scale out and quickly release to instantly scale in. To the consumer, the computing power available for provisioning often appears unlimited, and can be purchased at any time and in any quantity. Metered Services: Cloud systems leverage measurement capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of utilized services.

[0071] The service model is as follows: Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure that can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functionality, except for limited user-specific application configuration settings. Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of their hosting environment. Infrastructure as a Service (IaaS): The functionality offered to consumers is the provisioning of processors, storage, networking, and other basic computing resources on which they can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, and deployed applications, and in some cases partial control over some network components (e.g., host firewalls).

[0072] The deployment model is as follows: Private Cloud: This cloud infrastructure is dedicated to a specific organization and can be managed by that organization or a third party, and can exist on-premise or off-premise. Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by those organizations or a third party and can exist on-premises or off-premises. Public cloud: This cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services. Hybrid cloud: This cloud infrastructure combines two or more cloud models (private, community, or public), each of which retains its inherent nuances but is bound by standards or specific technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0073] A cloud computing environment is a service-oriented environment that emphasizes statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0074] Referring to FIG. 10 , an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers (e.g., a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as, for example, a private, community, public, or hybrid cloud, or combinations thereof, as described above. This enables the cloud computing environment 50 to provide infrastructure, platform, or software as a service, or combinations thereof, for which cloud consumers are not required to maintain resources on their local computing devices. It should be understood that the types of computing devices 54A-N shown in FIG. 10 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device via any type of network or network-addressable connection (e.g., using a web browser), or both.

[0075] Referring to Figure 11, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 10) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 11 are merely exemplary, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided: Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, reduced instruction set computer (RISC) architecture-based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68. The virtualization layer 70 provides an abstraction layer from which the following virtual entities can be provided, for example: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0076] By way of example, the management layer 80 may provide the following functions: Resource provisioning 81 enables dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment; Metering and pricing 82 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources; By way of example, these resources may include application software licenses; Security enables identification and verification of cloud consumers and tasks, as well as protection for data and other resources; User portal 83 provides consumers and system administrators with access to the cloud computing environment; Service level management 84 enables allocation and management of cloud computing resources so that requested service levels are met; Service level agreement (SLA) planning and fulfillment 85 enables advance arrangement and procurement of anticipated future cloud computing resources required in accordance with SLAs.

[0077] The workload layer 90 provides examples of functionality available to a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and selective packet compression in 5G networks 96.

[0078] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium having stored thereon computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0079] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, by way of example only, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM or flash memory, SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, punch cards, or mechanically encoded devices having instructions recorded thereon, such as ridge structures in grooves, and suitable combinations thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0080] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, a wireless network, or a combination thereof). The network may be comprised of copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, edge servers, or a combination thereof. A network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0081] Computer-readable program instructions for carrying out operations of the present invention may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk, C++, etc., and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, as a standalone software package, or partially on the user's computer. Alternatively, the computer may be executed partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the computer-readable program instructions in order to carry out aspects of the present invention.

[0082] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0083] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing apparatus to create a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions can also be stored in a computer-readable storage medium connectable to a computer, programmable data processing apparatus, or other device, or combination thereof, that functions in a particular way, such that the computer-readable storage medium on which the instructions are stored constitutes one of several products including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0084] Computer-readable program instructions, such as instructions to perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams on a computer, other programmable apparatus, or other device, can also be loaded into a computer, other programmable data processing apparatus, or other device to perform a series of operational steps on the computer, other programmable apparatus, or other device to produce a computer-implemented process.

[0085] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of executable implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which constitute one or more executable instructions for implementing the specified logical function(s). In some alternative embodiments, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be accomplished as a single step, executed concurrently, substantially concurrently, partially, or fully in a time-overlapping manner, or the blocks may be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0086] In addition to the above, one or more aspects may be provided, offered, deployed, managed, serviced, etc. by a service provider that offers management of a customer environment. For example, a service provider may create, maintain, support, etc., computer code and / or computer infrastructure that implements one or more aspects for one or more customers. In return, the service provider may receive payments from customers based, by way of example, on a subscription or fee agreement or both. Additionally or alternatively, the service provider may receive payments from the sale of advertising content to one or more third parties.

[0087] In one aspect, an application may be deployed to perform one or more embodiments. By way of example, deploying an application includes providing a computer infrastructure operable to perform one or more embodiments.

[0088] As a further aspect, a computing infrastructure may be deployed that includes integrating computer-readable code into a computing system, which code, in combination with the computing system, is capable of executing one or more embodiments.

[0089] In yet another aspect, a process for integrating a computing infrastructure may be provided, the process comprising integrating computer-readable code into a computer system, the computer system including a computer-readable medium, the computer medium including one or more embodiments, the code in combination with the computer system capable of executing one or more embodiments.

[0090] Although various embodiments have been described above, these are merely examples.

[0091] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will be further understood that as used herein, the terms "comprises" and / or "comprising" specify the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0092] Corresponding structure, materials, acts, and equivalents of all means or step-plus-function expressions in the following claims are intended to include any structure, material, or acts for performing the function in combination with the elements of other claims as specifically claimed. The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosed form. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described to best explain various aspects and applications, and to enable those skilled in the art to recognize various embodiments with various modifications as suited to the particular use contemplated.

Claims

1. receiving wirelessly a congestion signal by a user equipment (UE) wirelessly connected to a broadband cellular network, the congestion signal being received based on network traffic congestion in hardware of the broadband cellular network and indicating the network traffic congestion; determining a current processor utilization of the UE; determining whether to automatically enable selective packet payload data compression on the UE based on the received congestion signal, the determined current processor utilization, and a known time for data compression and decompression; compressing payload data of one or more data packets generated by the UE based on determining to automatically enable selective packet payload data compression and forwarding the one or more data packets with the compressed payload data for transmission over the broadband cellular network; 11. A computer-implemented method comprising:

2. 2. The method of claim 1, wherein the broadband cellular network is a 5G new wireless network, the UE is in direct wireless communication with a radio base station of the broadband cellular network, the radio base station comprises one selected from the group consisting of a gNodeB device and an eNodeB (Next Generation Evolved Node B) device, and the network traffic congestion comprises congestion of at least one selected from the group consisting of the radio base station and a Physical Network Function (PNF) device of the broadband cellular network.

3. The method of claim 1 , wherein the compression is performed at a Packet Data Convergence Protocol (PDCP) layer of a user plane stack of the UE.

4. whether said selective packet payload data compression is enabled or disabled; The method of claim 3 , wherein the PDCP layer performs compression of header data of the one or more data packets.

5. determining whether to automatically enable selective packet payload data compression includes comparing the current processor utilization to a configured utilization threshold for the UE; The method of claim 1 , wherein the determining comprises determining to enable selective packet payload data compression based on the current processor utilization being less than or equal to the utilization threshold.

6. The method of claim 5, further comprising disabling selective packet payload data compression on the UE based on determining that processor utilization is greater than or equal to the utilization threshold after deciding to enable selective packet payload data compression.

7. 2. The method of claim 1, further comprising monitoring packet transmission latency over a wireless radio link between the UE and the broadband cellular network, and wherein the determining whether to automatically enable selective packet payload data compression is further based on determining whether selective packet payload data compression results in a net reduction in time to transfer the payload data over the broadband cellular network as compared to the packet transmission latency.

8. The method of any one of claims 1 to 7, wherein the determining whether to automatically enable selective packet payload data compression based on the sum of (i) a known time to compress the payload data, (ii) a known time to decompress the payload data, and (iii) a known time to transmit the payload data if compressed being less than a packet transmission latency, determines to enable selective packet payload data compression and compress the payload data.

9. 2. The method of claim 1, wherein the one or more data packets are for transmission on a particular dedicated logical channel associated with a Quality of Service Class Identifier (QCI) that the UE has established with the broadband cellular network, the method further comprising checking whether compression is enabled for the dedicated logical channel, wherein whether compression is enabled for the dedicated logical channel is based on the QCI associated with the dedicated logical channel, and wherein the compression is performed based on the check indicating that compression is enabled for the dedicated logical channel.

10. 10. The method of claim 1, further comprising: receiving a compression disable signal from a physical network function (PNF) device of the broadband cellular network; and disabling selective packet payload data compression on the UE based on receipt of the compression disable signal.

11. 10. The method of claim 1, further comprising, as part of the compression, fixing a compression status indicator to each of the one or more data packets to indicate to other devices of the broadband cellular network that the payload data of the data packets has been compressed.

12. 1. A computer system comprising: Memory and a processor in communication with the memory, the computer system configured to execute a method, the method comprising: receiving wirelessly a congestion signal by a user equipment (UE) wirelessly connected to a broadband cellular network, the congestion signal being received based on network traffic congestion in hardware of the broadband cellular network and indicating the network traffic congestion; determining a current processor utilization of the UE; determining whether to automatically enable selective packet payload data compression on the UE based on the received congestion signal, the determined current processor utilization, and a known time for data compression and decompression; compressing payload data of one or more data packets generated by the UE based on determining to automatically enable selective packet payload data compression and forwarding the one or more data packets with the compressed payload data for transmission over the broadband cellular network; 2. A computer system comprising:

13. The broadband cellular network is a 5G new wireless network, the UE is in direct wireless communication with a radio base station of the broadband cellular network, the radio base station includes one selected from the group consisting of a gNodeB device and a next generation evolved NodeB (eNodeB) device, and the network traffic congestion is 13. The computer system of claim 12, wherein the congestion includes at least one selected from the group consisting of the radio base station and a physical network function (PNF) device of the broadband cellular network, and the compression is performed at a Packet Data Convergence Protocol (PDCP) layer of a user plane stack of the UE.

14. 13. The computer system of claim 12, wherein the determining whether to automatically enable selective packet payload data compression compares the current processor utilization to a utilization threshold configured for the UE, and the determining determines to enable selective packet payload data compression based on the current processor utilization being less than or equal to the utilization threshold.

15. 13. The computer system of claim 12, wherein the method further includes monitoring packet transmission latency over a wireless radio link between the UE and the broadband cellular network, and wherein the determining whether to automatically enable selective packet payload data compression is further based on determining whether selective packet payload data compression results in a net decrease in time to transfer the payload data over the broadband cellular network compared to the packet transmission latency, and wherein the determining whether to automatically enable selective packet payload data compression determines to enable selective packet payload data compression and compress the payload data based on the sum of (i) a known time to compress the payload data, (ii) a known time to decompress the payload data, and (iii) a known time to transmit the payload data if compressed being less than the packet transmission latency.

16. 13. The computer system of claim 12, wherein the one or more data packets are for transmission on a particular dedicated logical channel associated with a Quality of Service Class Identifier (QCI) that the UE has established with the broadband cellular network, the method further comprising checking whether compression is enabled for the dedicated logical channel, wherein whether compression is enabled for the dedicated logical channel is based on the QCI associated with the dedicated logical channel, and wherein the compression is performed based on the check indicating that compression is enabled for the dedicated logical channel.

17. A computer program for causing a computer to execute a method, the method comprising: receiving wirelessly a congestion signal by a user equipment (UE) wirelessly connected to a broadband cellular network, the congestion signal being received based on network traffic congestion in hardware of the broadband cellular network and indicating the network traffic congestion; determining a current processor utilization of the UE; determining whether to automatically enable selective packet payload data compression on the UE based on the received congestion signal, the determined current processor utilization, and a known time for data compression and decompression; compressing payload data of one or more data packets generated by the UE based on determining to automatically enable selective packet payload data compression and forwarding the one or more data packets with the compressed payload data for transmission over the broadband cellular network; a computer program comprising:

18. 18. The computer program product of claim 17, wherein the broadband cellular network is a 5G new wireless network, the UE is in direct wireless communication with a radio base station of the broadband cellular network, the radio base station comprises one selected from the group consisting of a gNodeB device and an eNodeB (next generation evolved NodeB) device, the network traffic congestion comprises congestion of at least one selected from the group consisting of the radio base station and a physical network function (PNF) device of the broadband cellular network, and the compression is performed at a Packet Data Convergence Protocol (PDCP) layer of a user plane stack of the UE.

19. 18. The computer program product of claim 17, wherein the determining whether to automatically enable selective packet payload data compression compares the current processor utilization to a utilization threshold configured for the UE, and the determining determines to enable selective packet payload data compression based on the current processor utilization being less than or equal to the utilization threshold.

20. 20. The computer program product of claim 17, wherein the one or more data packets are for transmission on a particular dedicated logical channel associated with a Quality of Service Class Identifier (QCI) that the UE has established with the broadband cellular network, the method further comprising checking whether compression is enabled for the dedicated logical channel, wherein whether compression is enabled for the dedicated logical channel is based on the QCI associated with the dedicated logical channel, and wherein the compression is performed based on the check indicating that compression is enabled for the dedicated logical channel.

Citation Information

Patent Citations

  • Congestion handling in communication networks

    JP2013524589A

  • Method and apparatus for providing intelligent codec rate adaptation for wireless users

    JP2015509349A

  • Content compression in mobile network

    US20160127240A1

  • Techniques for flow control for data compression algorithms

    US20160337255A1