RLC Channel Management for Low-Memory 5G Devices

Abstract

In an approach to RLC channel management for low memory 5G devices, in response to detecting memory overload at an RLC layer of the 5G user equipment, it is determined whether a slice of a plurality of slices is a merger candidate. In response to determining that a slice is a merger candidate, it is determined whether any of the merger candidates are capable of sharing a transport logical entity, and if performance and quality parameters are within predetermined limits, the merger candidates are capable of sharing the transport logical entity. Merger candidates capable of sharing the transport logical entity are marked as allowed candidates. In response to determining that at least one allowed candidate has a workload below a predetermined threshold, the allowed candidates are merged into a merged flow.

Description

[Technical Field]

[0001] The present invention relates generally to the field of wireless communication networks, and more particularly to radio link control (RLC) channel management for low-memory fifth generation (5G) telecommunications (telecom) devices. [Background technology]

[0002] In telecommunications, 5G is the fifth-generation technology standard for broadband cellular networks. 5G enables a new kind of network designed to connect virtually everyone and everything together, including machines, objects, and devices. 5G wireless technology promises to deliver higher, multi-Gbps peak data speeds, extremely low latency, greater reliability, massive network capacity, improved availability, and a more uniform user experience to more users. Higher performance and improved efficiency will power new user experiences and connect new industries. 5G is much more than the next generation of wireless networks. 5G is the connectivity fabric that will bring everything and everyone together.

[0003] 5G is a significant evolution of 4G Long Term Evolution (LTE) networks. 5G is designed to meet the enormous growth in data and connectivity not only from user equipment (UE) such as smartphones, but also from the Internet of Things (IoT) with billions of connected devices and emerging technologies such as driverless cars. 5G will initially operate in conjunction with existing 4G networks, then evolve into a fully standalone network in subsequent releases and coverage expansions. Summary of the Invention

[0004]

[0010] Embodiments of the present invention disclose a method, computer program product, and system for RLC channel management for low-memory 5G devices. In one embodiment, in response to detecting memory overload in an RLC layer of a 5G user equipment, it is determined whether one or more slices of a plurality of slices are one or more merger candidates. It is determined whether any merger candidates can share a transport logical entity, and if performance and quality parameters are within predetermined limits, the merger candidates can share the transport logical entity. The one or more merger candidates that can share the transport logical entity are marked as one or more allowed candidates. In response to determining that at least one of the one or more allowed candidates has a workload below a predetermined threshold, the one or more allowed candidates are merged into one or more merged flows.

[0005] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a functional block diagram illustrating a distributed data processing environment in accordance with an embodiment of the present invention. [Figure 2] FIG. 1 is an illustration of an example of 5G user plane (UP) packet encoding-decoding according to an embodiment of the present invention. [Figure 3] FIG. 10 is a diagram of an example of a structural diagram of a PDCP layer and an RLC channel in the user plane (UP) according to an embodiment of the present invention. [Figure 4] 10 is a diagram of an example of memory swap management on a UE according to an embodiment of the present invention. [Figure 5] FIG. 1 is a block diagram of a system architecture for an embodiment of a 5G channel management program, according to an embodiment of the present invention. [Figure 6]FIG. 10 is an example diagram of virtualized RLC for better traffic flow in a low memory platform on a UE, according to an embodiment of the present invention. [Figure 7] 2 is a flowchart depicting operational steps of a procedure performed by a 5G channel management program for handling mapper classes and polling for UEs in the distributed data processing environment of FIG. 1 in accordance with an embodiment of the present invention. [Figure 8] 2 is a flowchart depicting the operational steps of a procedure performed by the 5G channel manager 142 for dynamic merge management in RLC on a UE in the distributed data processing environment of FIG. 1 in accordance with an embodiment of the present invention. [Figure 9] 10 is a flowchart depicting operational steps of a procedure performed by a 5G channel manager 142 for serving packet flows from a Service Data Adaptation Protocol (SDAP) and Medium Access Control (MAC) on a UE in the distributed data processing environment of FIG. 1 in accordance with an embodiment of the present invention. [Figure 10] FIG. 2 is a block diagram of components of a computing device executing a 5G channel management program within the distributed data processing environment of FIG. 1 in accordance with an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0007] Advancements in the telecommunications industry have become a key enabler for many technologies, including artificial intelligence (AI), by breaking down barriers such as sedentary operation, lower bandwidth, etc. 5G technology is expected to act as a rich enabler to push dependency technologies to even greater heights through 1Gbps mobile bandwidth, integration of IoT devices and access, etc. 5G networks are expected to become a part of the human community through various features including the ability to observe, reason, infer, and make human-like decisions about their surroundings.

[0008] In 5G telecom networks, the New Radio (NR) MAC layer provides services to the RLC layer control in the form of logical channels. These logical channels are virtualized communication network interfaces used to transfer input / output (I / O) commands (network data packets) and control instructions over the air interface and 5G fixed access networks. Logical channels are defined by the type of information they carry and are generally distinguished as control channels, used for the transmission of control and configuration information, or traffic channels, used for user data. 5G New Radio technology enables the creation of multiple logical channels over a single radio bearer network using the 5G network slicing model. These channels are used to carry specialized traffic from UE devices to the 5G network. When multiple channels are created from a single device to the 5G network, the channels achieve parallel processing in packet transmissions, reducing exclusive locking of 5G network resources and achieving performance benefits.

[0009] The creation of multiple dedicated traffic channels (DTCHs) from the UE to the 5G network enables smarter mobile applications to reap the performance benefits of 5G logical channel-based parallelism. Because logical channels are created over the air interface, the E-UTRAN Node B (eNodeB) is the hardware in the cell responsible for managing these DTCHs over the air interface. In the eNodeB, resources are allocated to DTCHs based on their nature (S1, radio, etc.), and parameters are negotiated at channel creation time. The eNodeB manages the logical channels via NR and connects with the 5G telecom network's Serving Gateway (S-GW) to transmit packets collected from all channels using compression, alignment, and multiplexing techniques. Data transmission and reception on bearer channels is transported by the S1 bearer between the S-GW and the eNodeB and by the radio bearer between the UE and the eNodeB.

[0010] 5G will require more memory than previous generations of mobile networks. Current mobile networks are as much about transmitting 4K video as they are about conversations and documents. Connected devices include not only smartphones but also sensors, parking meters, smart cars, wearables, and utility items. Telecom infrastructure is now networking and compute infrastructure, with flash, DRAM, and emerging memories replacing SRAM and TCAM. The proliferation of compute needs across domains from core to edge is driving heterogeneity in terms of memory requirements attached to all the various compute elements.

[0011] Theoretically, a 5G telecom network can support many logical channels that can be created between a UE and an eNodeB. When channel creation is initiated at the first logical endpoint in the 5G network, the necessary resources are allocated to the first logical endpoint so that packets on this RLC channel can be processed at high speed. Additionally, these logical RLC tunnels provide the ability to handle dissimilar traffic from each application or set of applications, and network slicing mode helps define the priority of incoming traffic. Thus, the first logical endpoint can be prioritized over various internal network components. This leads to the creation of multiple RLC tunnels between the UE and the eNodeB entity. These tunnels are then used for parallel packet transmission flows with individual MAC connectors and multiplexers for packet transmission over the radio access network (RAN) interface. In this case, when multiple logical channels are created at the UE, each channel has its own resource demand per logical endpoint. This resource demand includes memory and computational requirements per end to effectively process the workload. When any RLC tunnel is created in the UE, a set of memory pages will be allocated to the RLC tunnel. These are contiguous memory blocks with DMA capabilities at the physical layer; therefore, the pages must be physically contiguous in memory address locations. Because the amount of contiguous memory in UEs and other endpoint devices is finite, a swap partition is used to swap channels across interfaces. In the case of low-memory devices that need to be 5G network-ready, this is a common issue, where the least used or low-workload channels are frequently moved to the swap partition to allocate local memory space for active channels.This will allow 5G networks to operate with lower memory devices while still allowing more channels to operate.

[0012] In the case of a particular RLC channel with little traffic, it is easier to select the channel that needs to be moved to the swap partition for a new set of RLC slices accessing the workload. However, in the case of many more channels, each of which constantly injects a small amount of workload through the lower layers, such as the MAC, selecting a channel as a swap candidate becomes more difficult. When an RLC channel is moved to swap space, all packets common to this channel must be idle until they are swapped back to the node's main memory. In this case, because the channel is performing a small I / O packet workflow, the workflow may be too low to trigger a move from swap to main memory. This creates a performance issue for the 5G RLC layer UP stack. Applications accessing different channels performing workloads lower than full bandwidth cannot share physically contiguous pages, because physically contiguous pages are allocated exclusively for each RLC tunnel for packet transmission. Additionally, even if each slice is not heavily loaded, some of the channel must be firmly moved to the swap partition, which introduces packet latency for applications accessing these RLC channels. All I / O packets from these channels are marked as pending until the channels are resumed, i.e., when the channels are swapped back to main memory. This dramatically degrades system performance, even though CPU, memory, and storage resources are not occupied. This creates channel thrashing at the logical endpoint. For simplicity, we consider this to be a UE device, but this situation could occur in any component, such as an eNodeB or S-GW, due to inappropriate resource consumption in the RLC of the 5G UP stack.

[0013] The present invention provides a method, computer program product, and system operating in a 5G-enabled logical endpoint device, providing a mechanism for mitigating frequent swapping of RLC channels in a swap partition when a selected candidate and other related candidates are not using allocated pages. The present invention provides a scheme in which an RLC channel swap manager detects the total workload on a particular type of logical channel at the RLC protocol layer and, accordingly, decides to merge or de-merge logical channels rather than swapping them across memory locations. The workload manager in the 5G UP RLC protocol stack has a monitoring daemon that collects information about the current workload from all logical channels detected as active. When the system detects that a portion of a slice needs to be moved to the swap disk partition, the QCI and bandwidth characteristics of the channel are determined by an inspection daemon, and a less active channel is selected for merging (if the channel's respective policy allows merging). Information from upper layers, such as SDAP, is collected in advance to obtain the nature of the channel merging and cataloged logical channel security provisioning based on security needs.

[0014] A channel is marked as merge-provisioned if it can share transport logical entities. If the channel is not heavily loaded and its parameters, including but not limited to packet delay, guaranteed bit rate (GBR) / non-guaranteed bit rate (non-GBR) compliance, and QCI value, are within permissible ranges, the channel is capable of sharing transport logical entities, i.e., merging. If an over-allocation of memory resources is detected, a swap trigger is generated by the device's resource manager. Based on the signal received, information about the merger channel is examined from pre-calculated handshake information in the RLC. If a change is selected, the workload inspector is invoked to make a dynamic merge decision based on determining which channel from the merger list has a lower workload. If multiple channels are detected below a specified limit, such as 30%, the multiple channels can be combined or merged to gain performance benefits. When a candidate is selected, the candidate's identity is forwarded to the merge unit, which transparently handles packet flow routing for upper-layer I / O workloads. The RLC controller receives the logical UUIDs of the RLC tunnels that need to be merged, creates a local table for the merge mapper data structure, and selects the channels.

[0015] While making the final merger decision, the QCI category and packet transmission delay tolerance are considered and validated among the candidates, as this directly impacts transmission over the MAC and RLC interfaces. If there is a difference in QCI characteristics, the channel with the better QCI will be selected as the primary and another tunnel will be marked as the secondary. The multiplexer engine will keep track of the primary and secondary candidates for merging, and real-time packet forwarding will then be triggered on the secondary tunnel.

[0016] When any new I / O transmission or receive interrupt is received by the RLC protocol from MAC or SDAP, the identity is mapped to the merger and other normal transmission flows and transport layers are invoked. While assembling the RLC header of the packet, the SDAP identification is invoked and accordingly the RLC_ID is selected for packet embedding. If a packet for a supplementary channel is received, the main RLC_ID is discarded while creating the RLC header for the uplink packet. In the case of downlink flows, the opposite approach is used where the extracted RLC ID is mapped with the SDAP ID, and if the RLC_ID is the ID of the main channel, the SDAP channel selection is used to select the injection of the upper layers.

[0017] As the candidate packet flows are transparently transferred to another RLC_ID, the original memory pages can be moved to the swap partition for a longer period without hibernating the application workload. If the merger main experiences a bandwidth overload, the original policy will be resumed for optimal performance of applications accessing these RLC transmission entities. Additionally, as resources are used in an optimal manner, this further helps to add more application tunnels from the SDAP layer on low-memory platforms, improving low-memory devices to run more applications by optimally utilizing pages in 5G telecom networks.

[0018] FIG. 1 is a functional block diagram illustrating a distributed data processing environment, generally designated 100, suitable for operation of a 5G channel management program 142 in accordance with at least one embodiment of the present invention. As used herein, the term "distributed" refers to a computer system that includes multiple physically separate devices operating together as a single computer system. FIG. 1 illustrates only one implementation and does not suggest any limitations with respect to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by those skilled in the art without departing from the scope of the present invention as recited in the claims.

[0019] The distributed data processing environment 100 includes a computing device 110 and a UE 140, which are connected to a 5G network 130. The computing device 110 is further connected to a core network 120. The core network 120 can be, for example, a telecommunications network, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the three, and can include wired, wireless, or fiber optic connections. The core network 120 can include one or more wired and / or wireless networks capable of receiving and transmitting data, voice, and / or video signals (including multimedia signals including voice, data, and video information). In general, the core network 120 can be any combination of connections and protocols that will support communication between the computing device 110 and other computing devices (not shown) in the distributed data processing environment 100.

[0020] Computing device 110 may be a standalone computing device, an administrative server, a web server, a mobile computing device, or any other electronic device or computing system capable of receiving, transmitting, and processing data. In an embodiment, computing device 110 may be a base station for a cellular communications network, including an eNodeB base station for a 5G telecommunications network. In an embodiment, computing device 110 may be a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, a personal digital assistant (PDA), a smartphone, or any programmable electronic device capable of communicating with other computing devices (not shown) in distributed data processing environment 100 via core network 120. In another embodiment, computing device 110 may represent a server computing system, such as in a cloud computing environment, that utilizes multiple computers as server systems. In yet another embodiment, computing device 110 represents a computing system that utilizes clustered computers and components (e.g., database server computers, application server computers) that function as a single pool of seamless resources when accessed within distributed data processing environment 100.

[0021] UE 140 may be a smartphone, a standalone computing device, a computing device embedded in a vehicle, a mobile computing device, or any other electronic device or computing system capable of receiving, transmitting, and processing data. In an embodiment, UE 140 may be a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, a personal digital assistant (PDA), a smartphone, or any programmable electronic device capable of communicating with other computing devices (not shown) in distributed data processing environment 100 via 5G network 130.

[0022] In an embodiment, the UE 140 includes a 5G channel manager 142. In an embodiment, the 5G channel manager 142 is a program, application, or subprogram of a larger program for RLC channel management for low-memory 5G devices. In alternative embodiments, the 5G channel manager 142 may be located on any other device accessible by the UE 140 via the 5G network 130.

[0023] In an embodiment, the UE 140 includes an information repository 144. In an embodiment, the information repository 144 may be managed by the 5G channel manager 142. In an alternative embodiment, the information repository 144 may be managed by an operating system of the UE 140, either alone or together with the 5G channel manager 142. The information repository 144 is a data repository capable of storing, collecting, comparing, and / or combining information. In some embodiments, the information repository 144 is external to the UE 140 and is accessed through a communications network, such as the 5G network 130. In some embodiments, the information repository 144 is stored on the UE 140. In some embodiments, the information repository 144 may be on another computing device (not shown), provided that the information repository 144 is accessible by the UE 140. The information repository 144 may include 5G system configuration data, UE data, UP data, channel data, merger data, other data received by the 5G channel manager 142 from one or more sources, and data produced by the 5G channel manager 142.

[0024] Information repository 144 may be implemented using any volatile or non-volatile storage medium for storing information, as known in the art. For example, information repository 144 may be implemented using a tape library, an optical library, one or more independent hard disk drives, multiple hard disk drives in a redundant array of independent disks (RAID), a SATA drive, a solid state drive (SSD), or random access memory (RAM). Similarly, information repository 144 may be implemented using any suitable storage architecture, such as a relational database, an object-oriented database, or one or more tables, as known in the art.

[0025] FIG. 2 is an example diagram of 5G user plane (UP) packet encoding-decoding according to an embodiment of the present invention. The example in FIG. 2 includes an SDAP 210. The SDAP sublayer exists solely within the user plane in both the eNodeB and the UE, such as the UE 140 from FIG. 1. The eNodeB interfaces to the upper layers via Quality of Service (QoS) flows and to the Packet Data Convergence Protocol (PDCP) lower layers via Data Radio Bearers (DRBs). Traffic from QoS flows is mapped to the appropriate DRBs, which is an essential role of the SDAP.

[0026] Figure 2 shows the radio bearer RB x 212 and RB y 214. A radio bearer is similar to a logical channel for user control data.

[0027] The PDCP 220 is a layer in the NR protocol stack. It sits above RLC and below SDAP in the 5G NR radio protocol stack. The PDCP 220 in Figure 2 provides services to the SDAP 210, including user plane data transport, control plane data transport, header compression, ciphering, and integrity protection.

[0028] Figure 2 further includes RLC 230 and MAC 240. RLC 230 is the Layer 2 radio link protocol used over the air interface. It sits above MAC 240 and below PDCP 220. MAC 240 is essentially a layer that provides radio resource allocation and data transfer services to the layers above. A transport block for a Protocol Data Unit (PDU) typically consists of a header, a MAC subheader, and a payload. An example MAC PDU is shown in Figure 2 as MAC PDU 242.

[0029] Figure 3 is an example structural diagram of a PDCP layer and RLC channel in the user plane (UP) according to an embodiment of the present invention. In the example of Figure 3, the PDCP sublayer 310 is part of the LTE Layer 2 protocol responsible for IP header compression of user plane data packets to reduce the number of information bits transmitted over the air interface and improve transmission efficiency. The PDCP sublayer 310 includes a Control Service Access Point (C-SAP) 312, which is the logical connection (interface) between the PDCP and the SDAP, such as between the PDCP 220 and the SDAP 210 from Figure 2. The PDCP sublayer 310 further includes a PDCP Service Access Point (SAP) 314, which is the interface between the SDAP and the PDCP.

[0030] The RLC sublayer 320 is a Layer 2 radio link protocol used in UMTS, LTE, and 5G over the air interface, such as RLC 230 from FIG. 2. The RLC sublayer 320 resides above the MAC layer and below the PDCP layer, such as MAC 240 and PDCP 220 from FIG. 2. The RLC sublayer 320 includes an RLC Unacknowledged Mode (UM)-SAP channel 322 and an RLC Acknowledged Mode (AM)-SAP channel 324, which are logical connections (interfaces) between the RLC and PDCP. In acknowledged mode, an ACK signal is transmitted between communicating entities to confirm to the other party whether a message was received. In unacknowledged mode, a packet is assumed to be received as soon as it is sent from the initiator, and no ACK signal is expected.

[0031] Figure 4 illustrates an example of memory swap management on a user equipment (UE) in accordance with an embodiment of the present invention. In the example of Figure 4, three applications, APP1 402, APP2 404, and APP3 406, are connected to the UE's SDAP 420 via connections 412, 414, and 416, respectively. SDAP 420 is, for example, SDAP 210 from Figure 2. The UE has memory organized as memory space 430, which is the UE's main memory, and swap partition 440, which is a section of main memory reserved for swapping data in and out of memory space 430.

[0032] Memory space 430 includes memory block 432, memory block 434, and memory block 436. Memory blocks 432 and 434 are allocated to APP2 404. However, packets from APP3 406 are pending because the allocation for APP3 406's RLC_ID has been moved to swap partition 440. As a result, APP3 406 experiences more latency because swap memory block 442 allocated to APP3 406 must be swapped into memory block 436 in memory space 430 before packets from APP3 406 can be processed. The actual swap of swap memory block 442 into memory block 436 is illustrated by swap connection 450.

[0033] FIG. 5 is a block diagram of a system architecture for an embodiment of a 5G channel management program. The block diagram of FIG. 5 includes an application layer 510, which includes an application instance 512. The application instance 512 may be, for example, APP1 402, APP2 404, and APP3 404 from FIG. 4. The application layer 510 connects to an SDAP 520, which may be, for example, the SDAP 210 from FIG. 2, and connects to a PDCP layer 530, which may be, for example, the PDCP 220 from FIG. 2. The RLC layer 540 may be, for example, the RLC 230 from FIG. 2, and includes a swap manager 542. The swap manager 542 handles memory swaps between a memory space 550 and a swap partition 560. The memory space 550 and the swap partition 560 may be, for example, the memory space 430 and the swap partition 440 from FIG. 4, respectively.

[0034] FIG. 6 is an example of virtualized RLC for improved traffic flow in a low-memory platform on a UE, such as user equipment 140 from FIG. 1, in accordance with an embodiment of the present invention. The example of FIG. 6 illustrates the same memory swap management as FIG. 4, but with the inclusion of the present invention. In the example of FIG. 6, three applications, APP1 602, APP2 604, and APP3 606, are connected to an SDAP 620 of the UE. SDAP 620 is SDAP 420 from FIG. 4. The UE has a memory space 630 and a swap partition 640, which are memory space 430 and swap partition 440, respectively, from FIG. 4. In this example, however, APP3 406 from FIG. 4 was allocated memory in swap memory block 442 of swap partition 440. Here, instead of a swap memory block as in FIG. 4, the present invention merges 5G slices from APP3 606 with slices from APP2 604, as shown by virtualized RLC connection 622 and virtualized RLC connection 624. Thus, using the present invention, packets from APP3 606 utilize memory blocks 632 and 634 in memory space 630, rather than memory block 642 in swap partition 640. Memory space 630 further includes memory block 636, which is memory block 436 from FIG. 4. This avoids the delay associated with swapping between main memory and the swap partition, thus improving overall performance.

[0035] 7 is a flowchart depicting operational steps of a procedure performed by a 5G channel manager for handling mapper classes and polling for UEs in the distributed data processing environment of FIG. 1, in accordance with an embodiment of the present invention. In alternative embodiments, the steps of workflow 700 may be performed by any other program in conjunction with 5G channel manager 142.

[0036] In an embodiment, the 5G channel manager 142 receives user plane 5G protocol stack updates to map classes and polls connected channels. In an embodiment, the 5G channel manager 142 initiates polling for all workloads on the channel. In an embodiment, the 5G channel manager 142 updates the dynamic workload manager structure to accept pre-cooked data. In an embodiment, the 5G channel manager 142 determines the status of connected channels as merged or unmerged.

[0037] It should be appreciated that embodiments of the present invention provide at least the operational steps of a procedure performed by a 5G channel management program that handles mapper classes and polling for UEs in the distributed data processing environment of Figure 1. However, Figure 7 illustrates only one implementation and does not suggest any limitations with respect to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by one skilled in the art without departing from the scope of the present invention as recited in the claims.

[0038] It should be understood that the process depicted in FIG. 7 illustrates one possible iteration of the procedures performed by the 5G channel management program that handles mapper classes and polling for UEs in the distributed data processing environment of FIG. 1, which is executed continuously once the 5G channel management program 142 is started on the UE.

[0039] The 5G channel manager 142 updates the 5G protocol stack (step 702). In an embodiment, the 5G channel manager 142 receives user plane 5G protocol stack updates for mapping classes and polling connected channels. In an embodiment, the 5G channel manager 142 loads local data structures for at least mapping and polling.

[0040] The 5G channel manager 142 begins polling the RLC channel swap manager (step 704). In an embodiment, the 5G channel manager 142 begins polling for all workloads on the channel.

[0041] The 5G channel management program updates the dynamic workload manager (step 706). In an embodiment, the 5G channel management program 142 updates the dynamic workload manager structure to accept pre-falsified data. In an embodiment, the pre-falsified data is processed data in some form. In an embodiment, the 5G channel management program 142 checks the channel workload, collects allocated bandwidth for logical channels, and does this to determine whether the channel is lightly loaded, moderately loaded, or heavily loaded. In an embodiment, to obtain the information, the 5G channel management program 142 monitors channel packet statistics to derive the information.

[0042] The 5G channel management program collects the merge status of the channels (step 708). In an embodiment, the 5G channel management program 142 determines the status of the connected channels as merged or unmerged. In an embodiment, the 5G channel management program 142 remains at step 708 to continuously update the merge status of the channels. In an embodiment, the merge status is updated at an interval determined by a state machine.

[0043] Figure 8 is a flowchart depicting operational steps of a procedure performed by the 5G channel manager 142 for dynamic merge management in RLC on a UE in the distributed data processing environment of Figure 1 in accordance with an embodiment of the present invention. In alternative embodiments, the steps of workflow 800 may be performed by any other program in conjunction with the 5G channel manager 142.

[0044] In an embodiment, the 5G channel manager 142 determines whether a memory overload is detected. In an embodiment, if the 5G channel manager 142 determines that the RLC-allocated memory is overloaded, a portion of the slice needs to be moved to a swap partition, such as swap partition 440 of FIG. 4, and therefore the 5G channel manager 142 activates the swapper function received in step 702 of FIG. 7 above. In an embodiment, the 5G channel manager 142 uses a probe daemon to examine the quality of service (QoS) class identifier (QCI) and bandwidth characteristics of the channel. In an embodiment, the 5G channel manager 142 determines that merging is allowed if the policy sets the allow_merging parameter to true, e.g., ALLOW_MERGE==TRUE. In an embodiment, if the 5G channel manager 142 determines in step 804 above that the slice is a candidate to be merged, the 5G channel manager 142 determines whether the slice can share a transport logical entity. In an embodiment, if the 5G channel manager 142 determines that the slice is mergeable, the 5G channel manager 142 marks the slice as an allowed merger. In an embodiment, the 5G channel manager 142 determines whether memory resources are over-allocated for the RLC UP stack. In an embodiment, if the 5G channel manager 142 determines that memory resources are over-allocated for the RLC UP stack, the 5G channel manager 142 generates a trigger message using a resource manager, such as the resource manager in the RLC layer 540 of FIG. 5 above. In an embodiment, the 5G channel manager 142 determines whether any of the detected channels have a workload below a threshold.In an embodiment, if the 5G channel manager 142 determines that any of the detected channels has a workload below a threshold, the 5G channel manager 142 transfers the identity of the detected channel to a merging unit, which transparently handles packet flow routing for the incoming I / O workload. In an embodiment, the 5G channel manager 142 validates the QCI co-category and packet transmission delay tolerance for all candidate RLC_IDs in the list of merger candidates. In an embodiment, the 5G channel manager 142 keeps track of the main and auxiliary candidates for merging using a multiplexer engine, and real-time packet forwarding is then triggered on the auxiliary tunnel.

[0045] It should be appreciated that embodiments of the present invention provide at least the operational steps of a procedure performed by the 5G channel manager 142 for dynamic merge management in RLC on a UE in the distributed data processing environment of Figure 1. However, Figure 8 illustrates only one implementation and does not suggest any limitation with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by one skilled in the art without departing from the scope of the present invention as recited in the claims.

[0046] It should be understood that the process depicted in FIG. 8 illustrates one possible iteration of the procedures performed by the 5G channel manager 142 for dynamic merge management in RLC on a UE in the distributed data processing environment of FIG. 1, which is executed continuously once the 5G channel manager 142 is started on the UE.

[0047] The 5G channel manager 142 determines whether a memory overload is detected (decision block 802). In an embodiment, if the 5G channel manager 142 determines that the RLC allocated memory is not overloaded ("No" branch, decision block 802), the 5G channel manager 142 proceeds to decision block 806. In an embodiment, if the 5G channel manager 142 determines that the RLC allocated memory is overloaded ("Yes" branch, decision block 802), the 5G channel manager 142 proceeds to step 804.

[0048] The 5G channel manager 142 activates the swapper (step 804). In an embodiment, if the 5G channel manager 142 determines that the RLC allocated memory is overloaded, some of the slices need to be moved to a swap partition, such as swap partition 440 of Figure 4, and therefore the 5G channel manager 142 activates the swapper function received in step 702 of Figure 7 above.

[0049] In an embodiment, the 5G channel manager 142 determines whether a slice is a candidate for merging rather than swapping. In an embodiment, the 5G channel manager 142 uses a test daemon to investigate the QCI and bandwidth characteristics of the channel. In an embodiment, the 5G channel manager 142 collects activation times for RLC channels. In an embodiment, the 5G channel manager 142 uses a monitoring daemon to collect workloads on the channels. In an embodiment, the 5G channel manager 142 selects less active channels as candidates for merging if allowed by the channel's respective policies.

[0050] In an embodiment, the 5G channel manager 142 checks the system policy for the channel's RLC_ID to determine whether the policy allows merging of the channels. In an embodiment, the 5G channel manager 142 determines that merging is allowed if the policy sets the allow-merge parameter to true, e.g., ALLOW_MERGE==TRUE. In an embodiment, if the 5G channel manager 142 determines that the policy allows merging of the channels, the 5G channel manager 142 moves the channels to a merger candidate list. In an embodiment, the 5G channel manager 142 uses platform message queue communication to collect information from the SDAP, and the nature of the security provisioning for the logical channel is selected. In an embodiment, the 5G channel manager 142 makes the merger decision based on a catalog of security requirements.

[0051] The 5G channel manager 142 determines whether the slices are mergeable (decision block 806). In an embodiment, if the 5G channel manager 142 determines in step 804 above that the slices are candidates to be merged, the 5G channel manager 142 determines whether the slices are capable of sharing transport logical entities. In an embodiment, if the 5G channel manager 142 determines that the slices are capable of sharing transport logical entities, the slices are mergeable. In an embodiment, the 5G channel manager 142 determines that the slices are capable of sharing transport logical entities, i.e., mergeable, if the channel is not heavily loaded and parameters, including but not limited to, packet delay, guaranteed bit rate (GBR) / non-guaranteed bit rate (non-GBR) compliance, and QCI value, are within allowed ranges. In an embodiment, the allowed ranges of GBR / non-GBR compliance and QCI value are predetermined. In another embodiment, the allowed ranges of GBR / non-GBR compliance and QCI value are received by the 5G channel manager 142.

[0052] In an embodiment, if the 5G channel manager 142 determines that the slices are not mergeable ("No" branch, decision block 806), the 5G channel manager 142 proceeds to decision block 810. In an embodiment, if the 5G channel manager 142 determines that the slices are mergeable ("Yes" branch, decision block 806), the 5G channel manager 142 proceeds to step 808.

[0053] The 5G channel manager 142 marks the slice as a merger candidate (step 808). In an embodiment, if the 5G channel manager 142 determines that the slice is mergeable, the 5G channel manager 142 marks the slice as an allowed merger. In an embodiment, the 5G channel manager 142 marks the slice as an allowed merger by setting the parameter ALLOW_MERGE==TRUE.

[0054] The 5G channel manager 142 determines whether memory resources are over-allocated (decision block 810). In an embodiment, the 5G channel manager 142 determines whether memory resources are over-allocated for the RLC UP stack. In an embodiment, if the 5G channel manager 142 determines that memory resources are not over-allocated for the RLC UP stack ("No" branch, decision block 810), the 5G channel manager 142 proceeds to decision block 814. In an embodiment, if the 5G channel manager 142 determines that memory resources are over-allocated for the RLC UP stack ("Yes" branch, decision block 810), the 5G channel manager 142 proceeds to step 812.

[0055] The 5G channel manager invokes a workload validator (step 812). In an embodiment, if the 5G channel manager 142 determines that memory resources are over-allocated for the RLC UP stack, the 5G channel manager 142 generates a trigger message using a resource manager, such as the resource manager in the RLC layer 540 of FIG. 5 above. After generating the trigger message, the 5G channel manager 142 examines the mergeable channel information collected in step 804 above and invokes a workload validator to validate the RLC_IDs of workloads eligible for dynamic merger determination.

[0056] The 5G channel manager 142 determines whether any channels are below a threshold (decision block 814). In an embodiment, the 5G channel manager 142 determines whether any of the detected channels have a workload below a threshold. In an embodiment, the threshold is a predetermined value. In another embodiment, the threshold is a system policy. In an embodiment, the channel will be the one selected for merging in step 808 above. In an embodiment, the channel will have a MERGE_STATUS parameter indicating that merging is allowed.

[0057] In an embodiment, if the 5G channel manager 142 determines that none of the detected channels have a workload below the threshold (“No” branch, decision block 814), the 5G channel manager 142 proceeds to step 818. In an embodiment, if the 5G channel manager 142 determines that any of the detected channels have a workload below the threshold (“Yes” branch, decision block 814), the 5G channel manager 142 proceeds to step 816.

[0058] The 5G channel manager creates a list of merger candidates (step 816). In an embodiment, if the 5G channel manager 142 determines that any of the detected channels have a workload below a threshold, the 5G channel manager 142 transfers the identities of the detected channels to a merging unit, which transparently handles packet flow routing for the incoming I / O workload. In an embodiment, the 5G channel manager 142 sends the logical UUIDs of the RLC tunnels to be merged to a controller in the RLC, such as the RLC layer 540 of FIG. 5. In an embodiment, once the RLC controller obtains the logical UUIDs of the RLC tunnels to be merged, the RLC controller creates a local table for a merge mapper data structure and selects the previously created list of RLC_IDs.

[0059] The 5G channel manager evaluates the QCI category and packet delay tolerance (step 818). In an embodiment, the 5G channel manager 142 validates the QCI category and packet transmission delay tolerance for all candidate RLC_IDs in the list of merger candidates. In an embodiment, if the QCI characteristics differ, the 5G channel manager 142 selects the channel RLC_ID with the higher QCI and sets this channel as main.

[0060] The 5G channel manager writes the record (step 820). In an embodiment, the 5G channel manager 142 continues to track the main and auxiliary candidates for merging using the multiplexer engine, and real-time packet forwarding is triggered on the auxiliary tunnel. In an embodiment, the 5G channel manager 142 then returns to decision block 802.

[0061] Figure 9 is a flowchart depicting operational steps of a procedure performed by the 5G channel manager 142 for serving packet flows from the SDAP and MAC on the UE in the distributed data processing environment of Figure 1, in accordance with an embodiment of the present invention. In alternative embodiments, the steps of workflow 900 may be performed by any other program in conjunction with the 5G channel manager 142.

[0062] In an embodiment, the 5G channel manager 142 receives an interrupt indicating that a new packet has been received or that a new packet is ready for transmission. In an embodiment, the 5G channel manager 142 identifies the child slice mapped to the merger using RLC, such as, for example, the RLC layer 540 from FIG. 5 above. In an embodiment, the 5G channel manager 142 invokes the transport layer to inject the child slice into the appropriate SDAP or MAC flow. In an embodiment, if the 5G channel manager 142 determines that the packet is targeted to a supplemental slice, the 5G channel manager 142 creates an RLC header for the uplink packet while simultaneously discarding the main RLC_ID. In an embodiment, the 5G channel manager 142 then completes the cycle. In an embodiment, the 5G channel manager 142 determines whether the packet is for a downlink flow. In an embodiment, if the 5G channel manager 142 determines that the packet is targeted for a downlink flow, the 5G channel manager 142 extracts the RLC_ID and maps it to the SDAP ID. In an embodiment, the 5G channel manager 142 then completes the cycle.

[0063] It should be appreciated that embodiments of the present invention provide, at a minimum, the operational steps of a procedure performed by the 5G channel manager 142 for serving packet flows from the SDAP and MAC on a UE in the distributed data processing environment of Figure 1. However, Figure 9 illustrates only one implementation and does not suggest any limitations with respect to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by one skilled in the art without departing from the scope of the present invention as recited in the claims.

[0064] It should be understood that the process depicted in FIG. 9 illustrates one possible iteration of the procedures performed by the 5G channel manager 142 for serving packet flows from the SDAP and MAC on the UE in the distributed data processing environment of FIG. 1, which repeats each time a new packet I / O transmission or receive interrupt is received from the SDAP or MAC on the UE over the RLC protocol.

[0065] The 5G channel manager 142 receives a packet interrupt (step 902). In an embodiment, the 5G channel manager 142 receives an interrupt indicating that a new packet has been received or that a new packet is ready for transmission.

[0066] The 5G channel manager 142 identifies the child slices mapped to the merger (step 904). In an embodiment, the 5G channel manager 142 identifies the child slices mapped to the merger using RLC, such as, for example, the RLC layer 540 from FIG. 5 above. In an embodiment, if a slice is not mapped to a merger, a normal transmission flow is mapped to the RLC_ID of the slice.

[0067] The 5G channel manager injects the slice into the correct SDAP or MAC flow (step 906). In an embodiment, the 5G channel manager 142 invokes the transport layer to inject the child slice into the appropriate SDAP or MAC flow. In an embodiment, while assembling the RLC header for the packet, the 5G channel manager 142 invokes the appropriate SDAP identity in the packet and selects the selected RLC_ID to embed the packet in based on the SDAP identity.

[0068] The 5G channel manager 142 determines whether the packet is for a supplemental slice (decision block 908). In an embodiment, if the 5G channel manager 142 determines that the packet does not target a supplemental slice ("No" branch, decision block 908), the 5G channel manager 142 proceeds to decision block 912. In an embodiment, if the 5G channel manager 142 determines that the packet does target a supplemental slice ("Yes" branch, decision block 908), the 5G channel manager 142 proceeds to step 910.

[0069] The 5G channel manager replaces the RLC_ID with the ID of the main slice (step 910). In an embodiment, if the 5G channel manager 142 determines that the packet targets the auxiliary slice, the 5G channel manager 142 creates an RLC header for the uplink packet while discarding the main RLC_ID. In an embodiment, the 5G channel manager 142 then ends the cycle.

[0070] The 5G channel management program 142 determines whether the packet is for a downlink flow (decision block 912). In an embodiment, if the 5G channel management program 142 determines that the packet is not targeted for a downlink flow ("No" branch, decision block 912), the 5G channel management program 142 ends the cycle. In an embodiment, if the 5G channel management program 142 determines that the packet is targeted for a downlink flow ("Yes" branch, decision block 912), the 5G channel management program 142 proceeds to step 914.

[0071] The 5G channel manager selects an SDAP channel for upper layer injection (step 914). In an embodiment, if the 5G channel manager 142 determines that the packet is targeted for a downlink flow, the 5G channel manager 142 extracts the RLC_ID and maps it to an SDAP ID. In an embodiment, each layer maintains its own logical ID per channel, and the mapping is typically one-to-one. In an embodiment, each RLC channel is mapped to a single SDAP channel, as modified by the 5G channel manager 142 in FIG. 8 above. In an embodiment, when any packet is injected by the application layer, the 5G channel manager 142 adds the ID of the lower protocol layer so that it can be correctly decoded at the target. In an embodiment, if the RLC_ID indicates that the flow is main, the 5G channel manager 142 will select an SDAP channel based on the upper layer injection. In an embodiment, the 5G channel manager 142 then completes the cycle.

[0072] FIG. 10 is a block diagram depicting components of a computing device 110 suitable for a 5G channel management program 142 in accordance with at least one embodiment of the present invention. FIG. 10 illustrates a computer 1000, one or more processors 1004 (including one or more computer processors), a communications fabric 1002, memory 1006 including random access memory (RAM) 1016 and cache 1018, persistent storage 1008, a communications unit 1012, an I / O interface 1014, a display 1022, and external devices 1020. It should be understood that FIG. 10 is illustrative of only one embodiment and does not suggest any limitation with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

[0073] As depicted, computer 1000 operates via communications fabric 1002, which provides communication between computer processor 1004, memory 1006, persistent storage 1008, communications unit 1012, and I / O interface 1014. Communications fabric 1002 may be implemented with any architecture suitable for communicating data or control information between processor 1004 (e.g., microprocessor, communications processor, and network processor), memory 1006, external device 1020, and any other hardware components in the system. For example, communications fabric 1002 may be implemented with one or more buses.

[0074] Memory 1006 and persistent storage 1008 are computer-readable storage media. In the depicted embodiment, memory 1006 comprises RAM 1016 and cache 1018. In general, memory 1006 can include any suitable volatile or non-volatile computer-readable storage medium. Cache 1018 is a high-speed memory that improves performance of processor 1004 by holding recently accessed and nearly recently accessed data from RAM 1016.

[0075] Program instructions for the 5G channel management program 142 may be stored in persistent storage 1008, or more generally, any computer-readable storage medium, for execution by one or more of the respective computer processors 1004 via one or more memories in memory 1006. Persistent storage 1008 may be a magnetic hard disk drive, a solid-state disk drive, a semiconductor storage device, a read-only memory (ROM), an electronically erasable programmable read-only memory (EEPROM), a flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0076] The media used by persistent storage 1008 may also be removable. For example, a removable hard drive may be used as persistent storage 1008. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer to another computer-readable storage medium, which may also be part of persistent storage 1008.

[0077] Communications unit 1012, in these examples, communicates with other data processing systems or devices. In these examples, communications unit 1012 includes one or more network interface cards. Communications unit 1012 may communicate using either or both physical and wireless communications links. In the context of some embodiments of the present invention, sources of various input data may be physically remote from computer 1000, and thus input data may be received, and output may be transmitted, via communications unit 1012.

[0078] The I / O interface 1014 allows for the input and output of data with other devices that may be connected to the computer 1000. For example, the I / O interface 1014 may connect to an external device 1020, such as a keyboard, keypad, touch screen, microphone, digital camera, or some other suitable input device, or a combination thereof. The external device 1020 may further include a portable computer-readable storage medium, such as a thumb drive, a portable optical or magnetic disk, and a memory card. Software and data used to practice embodiments of the present invention, such as the 5G channel management program 142, may be stored on such a portable computer-readable storage medium and loaded into the persistent storage 1008 via the I / O interface 1014. The I / O interface 1014 further connects to a display 1022.

[0079] Display 1022 provides a mechanism for displaying data to a user and may be, for example, a computer monitor. Display 1022 may further function as a touch screen, such as the display of a tablet computer.

[0080] The programs described herein are identified based on the applications for which they are implemented in particular embodiments of the invention, but it should be understood that any particular program nomenclature herein is used merely as a matter of convenience, and thus the invention should not be limited solely to use with any particular application identified and / or suggested by such nomenclature.

[0081] The present invention may be a system, a method, and / or a computer program product, which may include a computer-readable storage medium (or media) having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0082] A computer-readable storage medium can be any tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures having instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein should not be construed as being signals that are transitory in nature, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted through wires.

[0083] 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 storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may comprise copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in 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.

[0084] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or conventional procedural programming languages, such as object-oriented programming languages ​​such as Smalltalk®, C++, or the like, and traditional procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, 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 through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry devices, including programmable logic devices, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer readable program instructions by utilizing state information of the computer readable program instructions to individualize the electronic circuitry devices to implement aspects of the present invention.

[0085] 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.

[0086] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, to produce a machine, whose instructions, executing on the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium, such that the computer-readable storage medium comprises an article of manufacture containing instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, and can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0087] The computer-readable program instructions may 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-executed process, the instructions executing on the computer, other programmable apparatus, or other device to perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0088] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for performing specified logical functions. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0089] The description of various embodiments of the present invention has been presented for purposes of illustration and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The terminology used herein has been chosen to best explain the principles of the embodiments, practical applications, or technical improvements over technology found in the marketplace, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A computer-implemented method comprising: determining, by one or more computer processors, whether one or more slices of the plurality of slices are one or more merger candidates in response to detecting a memory overload in an RLC layer of the 5G user equipment; determining, by the one or more computer processors, whether any merger candidate of the one or more merger candidates can share a transport logical entity, wherein the merger candidate can share the transport logical entity if performance and quality parameters are within predetermined limits; marking, by the one or more computer processors, the one or more merger candidates that can share the transport logical entity as one or more allowed candidates; merging, by the one or more computer processors, one or more of the allowed candidates into one or more merged flows in response to determining that at least one of the one or more allowed candidates has a workload below a predetermined threshold; 20. A computer-implemented method comprising:

2. determining whether the one or more slices of the plurality of slices are the one or more merger candidates in response to detecting the memory overload in the RLC layer of the 5G user equipment; updating, by the one or more computer processors, a user plane protocol stack in the user equipment, wherein the user plane protocol stack is updated to include one or more additional functions for a channel merger; starting, by the one or more computer processors, a swap manager for the RLC layer of the 5G user equipment, wherein the swap manager polls a total workload for each channel of a plurality of channels; collecting, by said one or more computer processors, a merger status for each channel of said plurality of channels; The computer-implemented method of claim 1 further comprising:

3. 3. The computer-implemented method of claim 2, wherein the swap manager continuously polls the total workload for each channel of the plurality of channels.

4. determining whether the one or more slices of the plurality of slices are the one or more merger candidates in response to detecting the memory overload in the RLC layer of the 5G user equipment; retrieving, by the one or more computer processors, one or more QoS class identifier (QCI) parameters and one or more bandwidth parameters for each allowed candidate of the one or more allowed candidates; adding, by the one or more computer processors, each allowed candidate of the one or more allowed candidates to a list of merger candidates, the list of merger candidates including the one or more QCI parameters and the one or more bandwidth parameters; The computer-implemented method of claim 2 further comprising:

5. merging the one or more allowed candidates into the one or more merged flows in response to determining that the at least one allowed candidate of the one or more allowed candidates has the workload below the predetermined threshold; retrieving, by the one or more computer processors, the one or more QCI parameters and the one or more bandwidth parameters for each allowed candidate of the one or more allowed candidates in response to determining that the at least one allowed candidate of the one or more allowed candidates has the workload below the predetermined threshold; validating, by the one or more computer processors, one or more QCI co-categories and packet transmission delay tolerances for each allowed candidate; selecting, by the one or more computer processors, one or more sets of allowable candidates, each set of the one or more sets of allowable candidates being mergable into one merged flow of the one or more merged flows; merging, by the one or more computer processors, each set of the one or more sets of allowed candidates into the one or more merged flows based on the one or more QCI co-categories and the packet transmission delay tolerance; The computer-implemented method of claim 4, comprising:

6. determining, by the one or more computer processors, in response to selecting the set of allowed candidates, whether one or more allowed candidates in the set of allowed candidates have different QCI parameters than one or more other allowed candidates; in response to one or more allowed candidates of the set of allowed candidates having different QCI parameters than the other allowed candidates of the set of allowed candidates, assigning, by the one or more computer processors, a best allowed candidate as a main candidate and one or more remaining allowed candidates as one or more secondary candidates, wherein the best allowed candidate has the highest QCI parameter; The computer-implemented method of claim 5 further comprising:

7. and in response to receiving a new packet I / O interrupt targeted to an auxiliary candidate, mapping the new packet to the one or more merged flows by the one or more computer processors. The computer-implemented method of claim 4 further comprising:

8. A program for causing a processor to execute a computer-implemented method according to any one of claims 1 to 7.

9. A computer system comprising a processor that executes the computer-implemented method of any one of claims 1 to 7.

Images