Scaling subscriber handling capacity and throughput in cloud-native radio access network

Abstract

To provide a method, a device, and a computer program product for scaling subscriber capacity in a cloud-native radio access network (RAN).SOLUTION: In a cloud-native radio access network, to provide communication to at least one user device of a plurality of user devices, processing capacity allocated to one or more containers in a plurality of containers is determined, the determined processing capacity is compared with at least one predetermined threshold of a plurality of predetermined thresholds, and it is determined whether to change the allocation of the processing capacity based on the comparison.SELECTED DRAWING: Figure 12

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is the subject of Indian Patent Application No. 202241020000 to Bhaskaran et al., filed on April 1, 2022, entitled "Scaling Subscriber Handling Capacity and Throughput in a Cloud Native Radio Access Network," the entire disclosure of which is incorporated herein by reference.

[0002] In some implementations, the present subject matter relates to telecommunications systems, particularly to scaling subscriber capacity and / or data throughput in cloud-native radio access networks (RANs), and particularly to scaling in and / or out subscriber handling capacity in cloud-native RANs. [Background technology]

[0003] In today's world, cellular networks provide on-demand communication capabilities to individuals and businesses. Typically, cellular networks are wireless networks that can be distributed over a land area, called a cell. Each such cell is served by at least one fixed-location receiver, called a cell site or base station. Each cell may use a different set of frequencies from its neighboring cells to avoid interference and provide improved service within each cell. When cells are coupled together, they provide wireless coverage over a wide geographic area, allowing numerous mobile phones and / or other wireless devices or portable receivers to communicate with each other and with fixed receivers or phones located anywhere within the network. Such communication is performed through base stations, even when a mobile receiver is moving through two or more cells during transmission. Major wireless communication providers have deployed such cell sites worldwide, enabling mobile phones and mobile computing devices to connect to the public switched telephone network and the public Internet.

[0004] A mobile phone is a portable telephone that can receive and / or transmit telephone and / or data communications through a cell site or transmission tower by transmitting signals to and from the mobile phone using radio waves. Given the large number of mobile phone users, current mobile phone networks offer limited and shared resources. In that regard, cell sites and handsets may use different frequencies and low-power transmitters to reduce interference and allow simultaneous use of the network by multiple callers. The coverage area provided by a cell site may depend on the particular geographic location and / or the number of users that can potentially use the network. For example, in urban areas, a cell site may have a range of up to about 1 / 2 mile, while in rural areas, the range may be as much as 5 miles, and in some areas, users may receive signals from cell sites as far away as 25 miles.

[0005] The following are some examples of digital cellular technologies used by communications providers: Global System for Mobile Communications ("GSM"), General Packet Radio Service ("GPRS"), cdmaOne, CDMA2000, Evolution-Data Optimized ("EV-DO"), Enhanced Data Rates for GSM Evolution ("EDGE"), Universal Mobile Telecommunications System ("UMTS"), Digital Enhanced Cordless Telecommunications ("DECT"), Digital AMPS ("IS-136 / TDMA"), and Integrated Digital Enhanced Network ("iDEN"). Long Term Evolution, or 4G LTE, was developed by the 3rd Generation Partnership Project ("3GPP®") standards organization and is a standard for high-speed data wireless communications for mobile phones and data terminals. 5G standards are currently being developed and deployed. 3GPP cellular technologies such as LTE and 5G NR are evolutions of earlier generations of 3GPP technologies such as GSM / EDGE and UMTS / HSPA digital cellular technologies, allowing for increased capacity and speeds by using a different air interface along with core network improvements.

[0006] A cellular network may be divided into a radio access network and a core network. The radio access network (RAN) may include network functions capable of handling radio layer communication processing. The core network may include network functions capable of handling higher layer communications, such as Internet Protocol (IP), transport layers, and application layers. In some cases, the RAN functions may be divided into baseband unit functions and radio unit functions; for example, a radio unit connected to a baseband unit via a fronthaul network may be responsible for lower layer processing of the radio physical layer, and the baseband unit may be responsible for higher layer radio protocols, such as MAC, RLC, etc.

[0007] Traditional radio access networks (RANs) are typically configured for peak wireless subscriber processing capacity demands. When processing capacity falls below a predetermined peak, the RAN's computational resources are underutilized. Cloud-native RANs use cloud technologies to dynamically scale in (i.e., decrease) and scale out (i.e., increase) the processing capacity needed when subscriber demand decreases or increases. To fully utilize cloud-native dynamic scaling, it is necessary to determine when to trigger scale-in and scale-out operations. Summary of the Invention

[0008] In some implementations, the present subject matter relates to a method for subscriber capacity scaling in a cloud-native radio access network (RAN), the method including determining a processing capacity allocated to one or more containers within a plurality of containers of the cloud-native radio access network for providing communications to at least one user equipment within a plurality of user equipments, comparing the determined processing capacity to at least one predetermined threshold within a plurality of predetermined thresholds, and determining, based on the comparison, whether to change the allocation of processing capacity.

[0009] In some implementations, the present subject matter can include one or more of the following optional features: In some implementations, the method can also include changing the allocation of processing capacity.

[0010] In some implementations, the containers may be associated with at least one of at least one control plane component and at least one user plane component of a centralized unit of the base station. The determination of whether to change the allocation of allocated processing capacity may include at least one of: increasing the number of user equipments being processed by the at least one control plane component by increasing the number of containers that provide communications to the user equipments; decreasing the number of user equipments being processed by the at least one control plane component by decreasing the number of containers that provide communications to the user equipments; increasing the throughput capacity of the at least one user plane component by increasing the number of containers that provide communications to the user equipments; decreasing the throughput capacity of the at least one user plane component by decreasing the number of containers that provide communications to the user equipments; and any combination thereof.

[0011] In some implementations, at least one of determining the processing capacity, comparing, and determining whether to change the processing capacity may be performed by at least one base station in the wireless communication system. The base station may include at least one of a base station, an eNodeB base station, a gNodeB base station, a radio base station, a wireless access point, and any combination thereof. The base station may be a base station operating in at least one of the following communication systems: a long-term evolution communication system, a new wireless communication system, a wireless communication system, and any combination thereof. The base station may include at least one centralized unit, the centralized unit including at least one of a control plane component, a user plane component, and any combination thereof.

[0012] In some implementations, one or more user equipments of the plurality of user equipments may be associated with a radio resource control (RRC) state. The RRC state may include at least one of the following: an RRC inactive state, no RRC inactive state, an RRC connected state, and any combination thereof. One or more predetermined weights may be assigned to one or more user equipments of the plurality of user equipments based on the RRC state. The at least one predetermined threshold may be selected from a plurality of predetermined thresholds based on the RRC state of the one or more user equipments. Comparing may include comparing a decision processing capacity determined for one or more user equipments assigned the one or more predetermined weights with the predetermined threshold selected based on the RRC state of the one or more user equipments.

[0013] In some implementations, the method may further include transitioning at least one user equipment assigned to the at least one container to at least another container among the plurality of containers based on the determination of whether to change the processing capacity allocation, and providing communications to the transitioned user equipment using the at least another container. The method may also include preventing the at least one container from providing communications to at least another user equipment among the plurality of user equipment after the transition. The method may also include modifying at least one identifier of the transitioned user equipment. The method may further include preventing modification of the at least one identifier of the transitioned equipment. The identifier may include at least one of a user equipment identifier, a user equipment bearer identifier, at least one user plane endpoint address, an internet protocol (IP) address, a GPRS tunneling protocol user data tunneling endpoint identifier (GTP-U TEID), and any combination thereof associated with the at least one user equipment. The identifier may be stored in at least one database. The at least one container can be configured to retrieve an identifier from a database and assign the retrieved identifier to the transitioned user equipment. The database can store a mapping between the retrieved identifier and the at least one container.

[0014] In some implementations, the at least one predetermined threshold may include at least one of a first threshold associated with an increase in processing capacity, a second threshold associated with a decrease in processing capacity, and any combination thereof. Comparing may include comparing at least one of the first and second thresholds to at least one of the following: one or more user equipment having a predetermined radio resource control (RRC) state and associated with a first predetermined weight; a number of communications from one or more user equipment processed by the one or more containers per predetermined time period; a throughput associated with the one or more containers; and any combination thereof. In some implementations, changing the allocation of processing capacity may include at least one of increasing the processing capacity when the first threshold is exceeded based on the comparison and decreasing the processing capacity when the second threshold is not exceeded based on the comparison.

[0015] Non-transitory computer program products (i.e., physically embodied computer program products) storing instructions that, when executed by one or more data processors of one or more computing systems, cause at least one data processor to perform the operations described herein are also described. Similarly, computer systems are described that may include one or more data processors and memory coupled to the one or more data processors. The memory may store, either temporarily or permanently, instructions that cause at least one processor to perform one or more of the operations described herein. Furthermore, methods may be implemented by one or more data processors within a single computing system or distributed across two or more computing systems. Such computing systems may be connected via one or more connections and may exchange data and / or commands or other instructions, etc., including, but not limited to, connections over a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, etc.), such as via a direct connection between one or more of the computing systems.

[0016] The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims. [Brief explanation of the drawings]

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate certain aspects of the subject matter disclosed herein and, together with the description, serve to explain some of the principles underlying the disclosed implementations.

[0018] [Figure 1a] 1 illustrates an exemplary conventional Long Term Evolution ("LTE") communication system. [Figure 1b]1 shows further details of the exemplary LTE system shown in FIG. 1a. [Figure 1c] 1 illustrates further details of the evolved packet core of the exemplary LTE system shown in FIG. 1a. [Figure 1d] 1 illustrates an exemplary evolved Node B for the exemplary LTE system illustrated in FIG. 1a. [Figure 2] 1 shows further details of the evolved Node B shown in FIGS. 1a to 1d. [Figure 3] 1 illustrates an exemplary virtual radio access network in accordance with some implementations of the present subject matter. [Figure 4] 1 illustrates an exemplary 3GPP split architecture for providing users with access to higher frequency bands. [Figure 5a] 1 illustrates an exemplary 5G wireless communication system. [Figure 5b] 1 illustrates an example layer architecture for a split gNB and / or a split ng-eNB (e.g., a next-generation eNB that may be connected to 5GC). [Figure 5c] 5a-5b illustrate an exemplary functional division in the gNB and / or split ng-eNB architecture. [Figure 6] 1 illustrates an example architecture for routing messages accompanying transmission of data to and from one or more user equipments in a centralized unit control plane (CU-CP). [Figure 7] 1 illustrates an exemplary architecture for routing messages attached to the transmission of data to and from one or more user equipments in a centralized unit user plane (CU-UP). [Figure 8] 1 illustrates an example process for determining one or more capacity scaling triggers and / or performing capacity scaling within one or more pods, according to some implementations of the present subject matter. [Figure 9a] 7 illustrates an example process for performing a scale-in of one or more SM pods shown in FIG. 6 according to some implementations of the present subject matter. [Figure 9b] 7 illustrates an example process for performing a scale-in of one or more SM pods shown in FIG. 6 according to some implementations of the present subject matter. [Figure 9c] 7 illustrates an example process for performing a scale-in of one or more SM pods shown in FIG. 6 according to some implementations of the present subject matter. [Figure 10a] 8 illustrates an example process for performing a scale-in of one or more UP pods shown in FIG. 7 according to some implementations of the present subject matter. [Figure 10b] 8 illustrates an example process for performing a scale-in of one or more UP pods shown in FIG. 7 according to some implementations of the present subject matter. [Figure 10c] 8 illustrates an example process for performing a scale-in of one or more UP pods shown in FIG. 7 according to some implementations of the present subject matter. [Figure 11] 1 illustrates an exemplary system according to some implementations of the present subject matter. [Figure 12] 1 illustrates an exemplary method according to some implementations of the present subject matter. DETAILED DESCRIPTION OF THE INVENTION

[0019] The present subject matter can provide systems and methods that can be implemented in wireless communication systems. Such systems can include various wireless communication systems, including 5G new radio communication systems, long-term evolution communication systems, etc.

[0020] In some implementations, the present subject matter relates to scaling in and / or scaling out user equipment handling capacity in a cloud-native radio access network (RAN). Such scaling of user equipment capacity can be performed while the user equipment may and / or may not include a radio resource control (RRC) inactive state.

[0021] In some example implementations, the present subject matter may be configured to implement one or more trigger mechanisms for scaling (out / in) user equipment handling capacity in one or more portions of base stations (e.g., gNodeB / gNB, eNodeB / eNB) in a cloud radio access network communications system, including when there is no user equipment in an RRC inactive state.

[0022] In some example implementations, the present subject matter may be configured to implement one or more trigger mechanisms for scaling (out / in) user equipment handling capacity in one or more portions of base stations (e.g., gNodeB / gNB, ng-eNodeB / ng-eNB) in a cloud radio access network communications system, wherein one or more user equipments include an RRC inactive state.

[0023] In some example implementations, the present subject matter may be configured to implement one or more trigger mechanisms for scaling (out / in) user equipment handling capacity in one or more portions of base stations (e.g., gNodeB / gNB, eNodeB / eNB) in a cloud-native radio access network communications system, where one or more user equipments include an RRC inactive state and / or do not include an RRC inactive state, and one or more states of such user equipments (e.g., include an RRC inactive state, do not include an RRC inactive state) may be assigned one or more predetermined weights.

[0024] In some example implementations, the present subject matter may be configured to implement one or more trigger mechanisms for scaling (out / in) user equipment handling capacity in one or more portions of base stations (e.g., gNodeB / gNB, eNodeB / eNB) in a cloud-native radio access network communications system, and the one or more trigger mechanisms may be associated with one or more thresholds that may be used to determine when to perform the scaling (out / in) of the user equipment handling capacity.

[0025] In some example implementations, the assigned predetermined weights may be used in determining the above thresholds.

[0026] In some example implementations, the present subject matter relates to scaling user equipment handling capacity in one or more control planes (CPs) of one or more centralized units (CUs) of base stations (e.g., gNodeB / gNB, eNodeB / eNB) in a cloud-native radio access network (RAN).

[0027] In some example implementations, the present subject matter relates to scaling user equipment processing capacity in one or more user planes (UPs) of one or more centralized units (CUs) of base stations (e.g., gNodeB / gNB, eNodeB / eNB) in a cloud-native radio access network (RAN).

[0028] In some example implementations, the subject matter relates to scaling in and / or scaling out user equipment handling capacity in a cloud-native radio access network (RAN), where the cloud-native RAN is implemented in a cloud clustered computing environment having one or more processing pods capable of processing one or more user equipment, and upon scaling, one or more user equipment (e.g., user equipment identifiers and / or bearer context identifiers) may be transitioned from one such processing pod (e.g., a pod whose capacity may be scaled in (e.g., reduced), as described above) to another processing pod.

[0029] In some example implementations, one or more user equipment identifiers and / or their bearer context identifiers may be changed during such a transition.

[0030] In some example implementations, one or more user plane endpoint addresses that may be associated with one or more user equipment may change during such a transition.

[0031] In some example implementations, the one or more user plane endpoint addresses may include an Internet Protocol (IP) address and a GPRS Tunneling Protocol User Data Tunneling Endpoint Identifier (GTP-U TEID).

[0032] In some example implementations, one or more user plane endpoint addresses that may be associated with one or more user equipment may not change during such a transition.

[0033] In some example implementations, one or more of the user equipments may be assigned one or more subscriber identifiers and / or bearer context identifiers from the shared database during such a transition without changing its associated user plane endpoint address.

[0034] In some example implementations, a mapping of subscriber identifiers and / or bearer context identifiers to pods handling one or more user equipment associated with the assigned subscriber identifiers and / or bearer context identifiers may be maintained (and stored, for example, in a database), and the mapping may be updated during each such transition.

[0035] In some example implementations, changes and / or assignments of subscriber identifiers and / or bearer context identifiers during such transitions may be indicated and / or signaled to one or more peer network functions. Such signaling may include extending one or more existing messages and / or generating new messages for transmission over one or more communication interfaces (e.g., F1, W1, E1, NG, S1, Xn, X2, etc.).

[0036] One or more aspects of the present subject matter may be incorporated into transmitter and / or receiver components of base stations (e.g., gNodeB, eNodeB, etc.) in such communication systems. The following is a general description of Long Term Evolution and 5G new radio communication systems.

[0037] I. Long Term Evolution Communication System 1a-1c and 2 illustrate an exemplary conventional Long Term Evolution ("LTE") communication system 100 along with its various components. The LTE system, or 4G LTE, as it is commercially known, is governed by a standard for high-speed data wireless communication for cellular and data terminals. The standard is an evolution of GSM / EDGE ("Global System for Mobile Communications" / "Enhanced Data rates for GSM Evolution") and UMTS / HSPA ("Universal Mobile Telecommunications System" / "High Speed ​​Packet Access") network technologies. The standard was developed by 3GPP ("3rd Generation Partnership Project").

[0038] As shown in FIG. 1a, system 100 may include an evolved universal terrestrial radio access network (“EUTRAN”) 102, an evolved packet core (“EPC”) 108, and a packet data network (“PDN”) 101, where EUTRAN 102 and EPC 108 provide communications between user equipment 104 and PDN 101. EUTRAN 102 may include multiple evolved NodeBs (“eNodeB” or “ENODEB” or “enodeb” or “eNB”) or base stations 106(a, b, c) (shown in FIG. 1b) that provide communications capabilities to multiple user equipment 104(a, b, c). User equipment 104 may be a mobile phone, a smartphone, a tablet, a personal computer, a personal digital assistant (“PDA”), a server, a data terminal, and / or any other type of user equipment, and / or any combination thereof. User equipment 104 can connect to the EPC 108 and ultimately to the PDN 101 through any eNodeB 106. Typically, user equipment 104 can connect to the eNodeB 106 that is closest in terms of distance. In the LTE system 100, the EUTRAN 102 and the EPC 108 work together to provide connectivity, mobility, and services to the user equipment 104.

[0039] Figure 1b shows further details of the network 100 shown in Figure 1a. As mentioned above, the EUTRAN 102 includes multiple eNodeBs 106, also known as cell sites. The eNodeBs 106 provide radio functionality and perform key control functions, including air link or radio resource management, active mode mobility or handover, and scheduling admission control for services. The eNodeBs 106 are responsible for selecting which mobility management entity (MME shown in Figure 1c) will serve the user equipment 104 and for protocol functions such as header compression and ciphering. The eNodeBs 106 that make up the EUTRAN 102 cooperate with each other for radio resource management and handover.

[0040] Communication between the user equipment 104 and the eNodeB 106 occurs over an air interface 122 (also known as the “LTE-Uu” interface). As shown in FIG. 1b, the air interface 122 provides communication between the user equipment 104b and the eNodeB 106a. The air interface 122 uses Orthogonal Frequency Division Multiple Access (“OFDMA”) and a variant of OFDMA, Single Carrier Frequency Division Multiple Access (“SC-FDMA”), on the downlink and uplink, respectively. OFDMA enables the use of multiple known antenna technologies, such as Multiple Input Multiple Output (“MIMO”).

[0041] The air interface 122 uses various protocols, including radio resource control ("RRC") for signaling between the user equipment 104 and the eNodeB 106 and non-access stratum ("NAS") for signaling between the user equipment 104 and the MME (shown in FIG. 1c). In addition to signaling, user traffic is transferred between the user equipment 104 and the eNodeB 106. Both signaling and traffic in the system 100 are carried by physical layer ("PHY") channels.

[0042] Multiple eNodeBs 106 may be interconnected with each other using X2 interfaces 130(a, b, c). As shown in FIG. 1a, the X2 interface 130a provides interconnection between the eNodeBs 106a and 106b, the X2 interface 130b provides interconnection between the eNodeBs 106a and 106c, and the X2 interface 130c provides interconnection between the eNodeBs 106b and 106c. The X2 interfaces may be established between two eNodeBs to provide an exchange of signals, which may include not only handover-related information but also load-related or interference-related information. The eNodeBs 106 communicate with the evolved packet core 108 via S1 interfaces 124(a, b, c). The S1 interface 124 can be split into two interfaces: one for the control plane (illustrated in Figure 1c as control plane interface (S1-MME interface) 128) and one for the user plane (illustrated in Figure 1c as user plane interface (S1-U interface) 125).

[0043] The EPC 108 establishes and enforces quality of service ("QoS") for user services and enables user equipment 104 to maintain a consistent Internet Protocol ("IP") address while moving. Note that each node in the network 100 has its own IP address. The EPC 108 is designed to interwork with legacy wireless networks. The EPC 108 is also designed to separate the control plane (i.e., signaling) and user plane (i.e., traffic) in the core network architecture, which allows for greater flexibility in implementation and independent scalability of control and user data functions.

[0044] The EPC 108 architecture is dedicated to packet data and is shown in more detail in Figure 1c. The EPC 108 includes a Serving Gateway (S-GW) 110, a PDN Gateway (P-GW) 112, a Mobility Management Entity ("MME") 114, a Home Subscriber Server ("HSS") 116 (the EPC 108's subscriber database), and a Policy Control and Charging Rules Function ("PCRF") 118. Several of these (e.g., S-GW, P-GW, MME, HSS) are often combined into a node according to manufacturer implementation.

[0045] The S-GW 110 functions as an IP packet data router and is the user equipment's bearer path anchor in the EPC 108. Thus, when a user equipment moves from one eNodeB 106 to another eNodeB 106 during mobility operation, the S-GW 110 remains the same, and the bearer path towards the EUTRAN 102 is switched to communicate with the new eNodeB serving the user equipment 104. If the user equipment 104 moves into the domain of a different S-GW 110, the MME 114 forwards all of the user equipment's bearer paths to the new S-GW. The S-GW 110 establishes bearer paths from the user equipment to one or more P-GWs 112. When downstream data is received for an idle user equipment, the S-GW 110 buffers the downstream packets and requests the MME 114 to find and re-establish a bearer path through it towards the EUTRAN 102.

[0046] The P-GW 112 is the gateway between the EPC 108 (and the user equipment 104 and EUTRAN 102) and the PDN 101 (shown in Figure 1a). The P-GW 112 not only acts as a router for user traffic, but also performs functions on behalf of the user equipment. These include IP address allocation to the user equipment, packet filtering of downstream user traffic to ensure that it is placed on the appropriate bearer path, and enforcement of downstream QoS, including data rate. Depending on the services a subscriber is using, there may be multiple user data bearer paths between the user equipment 104 and the P-GW 112. A subscriber may use services on the PDN provided by different P-GWs, in which case the user equipment has at least one bearer path established to each P-GW 112. During handover of user equipment from one eNodeB to another, if the S-GW 110 is also changing, the bearer path from the P-GW 112 is switched to the new S-GW.

[0047] The MME 114 manages the user equipment 104 within the EPC 108, including managing subscriber authentication, maintaining the context of authenticated user equipment 104, establishing a data bearer path within the network for user traffic, and tracking the location of idle mobiles that have not detached from the network. For idle user equipment 104 that needs to reconnect to the access network to receive downstream data, the MME 114 initiates paging to locate the user equipment and reestablishes a bearer path with the EUTRAN 102. The MME 114 for a particular user equipment 104 is selected by the eNodeB 106 through which the user equipment 104 initiates system access. The MME is typically part of a collection of MMEs within the EPC 108 for load sharing and redundancy purposes. In establishing a user's data bearer path, the MME 114 is responsible for selecting the P-GW 112 and S-GW 110 that constitute the termination of the data path through the EPC 108.

[0048] The PCRF 118 is responsible for policy control decision making and control of flow-based charging functions in the policy control enforcement function ("PCEF") residing in the P-GW 110. The PCRF 118 provides QoS authorization (QoS Class Identifier ("QCI") and bit rate) that determines how a particular data flow is treated in the PCEF, ensuring that this is in accordance with the user's subscription profile.

[0049] As mentioned above, IP services 119 are provided by PDN 101 (shown in FIG. 1a).

[0050] 1d illustrates a typical structure of an eNodeB 106. The eNodeB 106 may include at least one remote radio head (“RRH”) 132 (typically, there may be three RRHs 132) and a baseband unit (“BBU”) 134. The RRH 132 may be connected to an antenna 136. The RRH 132 and BBU 134 may be connected using an optical interface compliant with the common public radio interface (“CPRI”) / enhanced CPRI (“eCPRI”) 142 standard specification, using RRH-specific custom control and user plane framing methods, or using O-RAN Alliance-compliant control and user plane framing methods. The operation of the eNodeB 106 may be characterized using the following standard parameters (and specifications): radio frequency band (Band 4, Band 9, Band 7, etc.), bandwidth (5, 10, 15, 20 MHz), access method (OFDM downlink, SC-OFDMA uplink), antenna technology (single-user and multi-user MIMO downlink, single-user and multi-user MIMO uplink), number of sectors (up to 6), maximum transmission rate (150 Mb / s downlink, 50 Mb / s uplink), S1 / X2 interface (1000Base-SX, 1000Base-T), and mobile environment (up to 350 km / h). The BBU 134 may be responsible for digital baseband signal processing, S1 line termination, X2 line termination, call processing, and monitoring control processing. IP packets received from the EPC 108 (not shown in FIG. 1d) may be modulated into digital baseband signals and transmitted to the RRH 132. Conversely, digital baseband signals received from the RRH 132 may be demodulated into IP packets for transmission to the EPC 108.

[0051] The RRH 132 can transmit and receive wireless signals using an antenna 136. The RRH 132 can convert digital baseband signals from the BBU 134 (using a converter (“CONV”) 140) to radio frequency (“RF”) signals and power amplify them (using an amplifier (“AMP”) 138) for transmission to the user equipment 104 (not shown in FIG. 1d). Conversely, RF signals received from the user equipment 104 are amplified (using AMP 138) and converted to digital baseband signals (using CONV 140) for transmission to the BBU 134.

[0052] 2 illustrates further details of a typical eNodeB 106. The eNodeB 106 includes multiple layers: LTE Layer 1 202, LTE Layer 2 204, and LTE Layer 3 206. LTE Layer 1 includes the physical layer (“PHY”). LTE Layer 2 includes medium access control (“MAC”), radio link control (“RLC”), and packet data convergence protocol (“PDCP”). LTE Layer 3 includes various functions and protocols, including radio resource control (“RRC”), dynamic resource allocation, eNodeB measurement configuration and provisioning, radio admission control, connection mobility control, and radio resource management (“RRM”). The RLC protocol is an automatic repeat request (“ARQ”) fragmentation protocol used over the cellular air interface. The RRC protocol handles LTE Layer 3 control plane signaling between user equipment and EUTRAN. RRC includes functions for connection establishment and release, system information broadcast, radio bearer establishment / reconfiguration and release, RRC connection mobility procedures, paging notification and release, and outer loop power control. PDCP performs IP header compression and decompression, user data transfer, and radio bearer sequence number maintenance. The BBU 134 shown in Figure 1d may include LTE layers L1 to L3.

[0053] One of the eNodeB 106's primary functions is radio resource management, which includes scheduling both uplink and downlink air interface resources for user equipment 104, control of bearer resources, and admission control. As an agent of the EPC 108, the eNodeB 106 is responsible for forwarding paging messages used to locate mobiles when they are idle. The eNodeB 106 also conveys common control channel information over the air, performs header compression and encryption and decryption of over-the-air transmitted user data, and establishes handover reporting and trigger criteria. As mentioned above, the eNodeB 106 can cooperate with other eNodeBs 106 over the X2 interface for handover and interference management purposes. The eNodeB 106 communicates with the MME of the EPC over the S1-MME interface and with the S-GW using the S1-U interface. Furthermore, the eNodeB 106 exchanges user data with the S-GW over the S1-U interface. The eNodeBs 106 and the EPC 108 have a many-to-many relationship to support load sharing and redundancy between MMEs and S-GWs. The eNodeB 106 selects one MME from a group of MMEs so that the load can be shared by multiple MMEs to avoid congestion.

[0054] II. 5G NR wireless communication network In some implementations, the present subject matter relates to 5G new radio ("NR") communication systems. 5G NR is the next communication standard beyond the 4G / IMT-Advanced standard. 5G networks offer higher capacity than current 4G, enabling a greater number of mobile broadband users per area unit and consuming more and / or unlimited gigabytes of data per month and per user. This allows users to stream high-resolution media for hours per day using their mobile devices, something that is not possible with Wi-Fi networks. 5G networks have improved end-to-end communication support, reduced costs, reduced latency compared to 4G devices, reduced battery consumption, etc. Such networks have data rates of tens of megabits per second for many users, data rates of 100 Mb / s for large metropolitan areas, simultaneous 1 Gb / s for users within a limited area (e.g., an office floor), many simultaneous connections for wireless sensor networks, improved spectral efficiency, improved coverage, improved signaling efficiency, and latencies of 1-10 ms, reduced latency over existing systems.

[0055] 3 illustrates an exemplary virtual radio access network 300. The network 300 can provide communication between various components, including a base station (e.g., eNodeB, gNodeB) 301, radio equipment 307, a centralized unit 302, a digital unit 304, and wireless devices 306. The components in the system 300 may be communicatively coupled to a core using a backhaul link 305. The centralized unit ("CU") 302 may be communicatively coupled to a distributed unit ("DU") 304 using a midhaul connection 308. The radio frequency ("RU") component 306 may be communicatively coupled to the DU 304 using a fronthaul connection 310.

[0056] In some implementations, the CU 302 can provide intelligent communication capabilities to one or more DU units 308. The units 302, 304 can include one or more base stations, macro base stations, micro base stations, remote radio heads, etc., and / or any combination thereof.

[0057] In a lower layer split architecture environment, the CPRI bandwidth requirements for NR can be several hundred Gb / s. CPRI compression can be implemented in the DU and RU (shown in Figure 3). In 5G communication systems, compressed CPRI over Ethernet frames, called eCPRI, is the recommended fronthaul network. This architecture can enable standardization of fronthaul / midhaul, which can include upper layer splitting (e.g., Option 2 or Option 3-1 (upper / lower RLC split architecture)) and fronthaul with an L1 split architecture (Option 7).

[0058] In some implementations, the lower layer split architecture (e.g., Option 7) can include a receiver in the uplink, joint processing across multiple transmission points (TPs) in both DL / UL, and transport bandwidth and latency requirements to facilitate development. Additionally, the subject lower layer split architecture can include splitting between cell-level processing and user-level processing, which can include cell-level processing in a remote unit ("RU") and user-level processing in a DU. Furthermore, using the subject lower layer split architecture, frequency-domain samples can be transmitted over the Ethernet net fronthaul, and the frequency-domain samples can be compressed to reduce the fronthaul bandwidth.

[0059] 4 illustrates an example communication system 400 that can implement 5G technology and provide users with access to higher frequency bands (e.g., greater than 10 GHz). The system 400 can include a macro cell 402 and small cells 404 and 406.

[0060] The mobile device 408 may be configured to communicate with one or more of the small cells 404, 406. The system 400 can enable control plane (C-plane) and user plane (U-plane) splitting between the macrocell 402 and the small cells 404, 406, with the C-plane and U-plane utilizing different frequency bands. In particular, the small cells 402, 404 may be configured to utilize higher frequency bands when communicating with the mobile device 408. The macrocell 402 can utilize existing cellular bands for C-plane communications. The mobile device 408 may be communicatively coupled via the U-plane 412, and the small cells (e.g., the small cell 406) can provide higher data rates and more flexible / cost / energy-efficient operation. The macrocell 402 can maintain good connectivity and mobility via the C-plane 410. Furthermore, in some cases, LTE and NR may be transmitted on the same frequency.

[0061] FIG. 5a illustrates an exemplary 5G wireless communication system 500 according to some implementations of the present subject matter. The system 500 may be configured to have a lower layer split architecture according to Option 7-2. The system 500 may include a core network 502 (e.g., 5G Core) and one or more gNodeBs (or gNBs), where the gNBs may have a centralized unit (gNB-CU). The gNB-CU may be logically divided into a control plane portion (gNB-CU-CP) 504 and one or more user plane portions (gNB-CU-UP) 506. The control plane portion 504 and the user plane portion 506 may be configured to be communicatively coupled using an E1 communication interface 514 (as defined in the 3GPP standards). The control plane portion 504 may be configured to be responsible for executing the RRC and PDCP protocols of the radio stack.

[0062] The control plane and user plane portions 504, 506 of the centralized unit of the gNB may be configured to be communicatively coupled to one or more distributed units (DUs) 508, 510 according to an upper layer split architecture. The distributed units 508, 510 may be configured to execute RLC, MAC, and upper portions of PHY layer protocols of the radio stack. The control plane portion 504 may be configured to be communicatively coupled to the distributed units 508, 510 using an F1-C communication interface 516, and the user plane portion 506 may be configured to be communicatively coupled to the distributed units 508, 510 using an F1-U communication interface 518. The distributed units 508, 510 may be coupled to one or more remote radio units (radio units (RUs)) 512 via a fronthaul network 520 (which may include one or more switches, links, etc.), which in turn communicate with one or more user equipment (not shown in FIG. 5a). The remote radio unit 512 may be configured to execute lower portions of the PHY layer protocol and to provide antenna capabilities to the remote unit for communication with user equipment (similar to the description above in connection with Figures 1a-2).

[0063] Figure 5b shows an example layer architecture 530 for a split gNB. The architecture 530 may be implemented in the communications system 500 shown in Figure 5a, which may be configured as a virtualized distributed radio access network (RAN) architecture, whereby layers L1, L2, L3 and radio processing may be virtualized and distributed among centralized, distributed, and radio units. As shown in Figure 5b, the gNB-DU 508 may be communicatively coupled to the gNB-CU-CP control plane portion 504 (also shown in Figure 5a) and the gNB-CU-UP user plane portion 506. Each of the components 504, 506, 508 may be configured to include one or more layers.

[0064] The gNB-DU 508 may include RLC, MAC, and PHY layers, as well as various communication sublayers. These may include an F1 application protocol (F1-AP) sublayer, a GPRS tunneling protocol (GTPU) sublayer, a stream control transmission protocol (SCTP) sublayer, a user datagram protocol (UDP) sublayer, and an Internet Protocol (IP) sublayer. As described above, the distributed unit 508 may be communicatively coupled to the control plane portion 504 of the centralized unit, which may also include the F1-AP, SCTP, and IP sublayers, as well as a radio resource control and PDCP control (PDCP-C) sublayer. Furthermore, the distributed unit 508 may also be communicatively coupled to the user plane portion 506 of the centralized unit of the gNB. The user plane portion 506 may include the service data adaptation protocol (SDAP), PDCP User (PDCP-U), GTPU, UDP, and IP sublayers.

[0065] Figure 5c shows an example functional division in the gNB architecture shown in Figures 5a-5b. As shown in Figure 5c, the gNB-DU 508 may be communicatively coupled to the gNB-CU-CP 504 and the GNB-CU-UP 506 using an F1-C communication interface. The gNB-CU-CP 504 and the GNB-CU-UP 506 may be communicatively coupled using an E1 communication interface. An upper portion of the PHY layer (or Layer 1) may be performed by the gNB-DU 508, while a lower portion of the PHY layer may be performed by the RU (not shown in Figure 5c). As shown in Figure 5c, the RRC portion and the PDCP-C portion may be performed by the control plane portion 504, and the SDAP portion and the PDCP-U portion may be performed by the user plane portion 506.

[0066] Some of the functions of the PHY layer in a 5G communication network include error detection on transport channels and indication to higher layers, FEC encoding / decoding of transport channels, hybrid ARQ soft combining, rate matching of coded transport channels to physical channels, mapping of coded transport channels to physical channels, power weighting of physical channels, modulation and demodulation of physical channels, frequency and time synchronization, radio characteristic measurement and indication to higher layers, MIMO antenna processing, digital and analog beamforming, RF processing, and other functions.

[0067] The MAC sublayer of Layer 2 may perform beam management, random access procedures, mapping between logical channels and transport channels, concatenation of multiple MAC service data units (SDUs) belonging to one logical channel into transport blocks (TBs), multiplexing / demultiplexing of SDUs belonging to logical channels to / from TBs passed to / from the physical layer on transport channels, scheduling information reporting, error correction via HARQ, priority handling between logical channels for one UE, priority handling between UEs via dynamic scheduling, transport format selection, and other functions. The RLC sublayer's functions may include forwarding upper layer packet data units (PDUs), error correction via ARQ, reordering of data PDUs, duplication and protocol error detection, reestablishment, etc. The PDCP sublayer may be responsible for forwarding user data, various functions during reestablishment procedures, SDU retransmission, SDU discarding in the uplink, forwarding of control plane data, etc.

[0068] The RRC sublayer of Layer 3 may perform the broadcasting of system information to the NAS and AS, the establishment, maintenance, and release of RRC connections, the security, establishment, configuration, maintenance, and release of point-to-point radio bearers, mobility functions, reporting, and other functions.

[0069] III. Scaling Subscriber Capacity in Cloud-Native Radio Access Networks In some implementations, to address various shortcomings of conventional systems, the present subject matter may be configured to perform subscriber capacity scaling in a cloud-native radio access network (RAN), and in particular, may be configured to perform scale-in (or decrease) and / or scale-out (or increase) of subscriber handling capacity in a cloud RAN.

[0070] Traditional Radio Access Networks (RANs) do not elastically scale in or out subscriber and / or throughput capacity as user equipment (or, as used interchangeably herein, "mobile subscribers," "subscribers," "mobile users," or "users") demand increases or decreases. Traditional RAN solutions are typically sized for peak capacity demands, and when capacity drops below such peaks, the RAN's computing resources can become very underutilized.

[0071] In some implementations, the subject cloud-native RAN may use cloud-based technologies to enable dynamically scaling up and / or down the processing capacity of various cloud-based processing components (e.g., containers, pods, etc.) that may be needed as subscriber demand increases and / or decreases. The subject matter may also be configured to execute processes that may determine when to trigger scale-in and / or scale-out operations.

[0072] The Next Generation RAN (NG-RAN) is defined by the Third Generation Partnership Project ("3GPP") standardization organization as a radio access network that can connect to a 5G core communications network. NG-RAN includes the following radio access networks: NR and EUTRAN. Furthermore, 3GPP defines a new state for user equipment connected to the NG-RAN: "RRC-INACTIVE." In existing systems, it is difficult to determine when to trigger scale-out / in for user equipment that includes / has an RRC-inactive state. This is because one or more contexts associated with user equipment in the RRC-inactive state may need to be retained even if they remain dormant within the RAN for a certain period of time without signaling. Furthermore, this lack of signaling to / from the user equipment is not considered a trigger for scaling and releasing cloud resources (e.g., computing resources, memory resources, etc.). In some implementations, the present subject matter solves these problems by providing a mechanism for determining when to trigger scaling of subscriber handling capacity, regardless of whether a particular user equipment is associated with an RRC inactive state.

[0073] In some implementations, the subject cloud-native RAN may be configured to include one or more base stations (e.g., gNodeB or gNB, eNodeB or eNB, ng-eNodeB or ng-eNB) and / or portions thereof, which may be configured to support the operation of one or more subscriber handling pods (or subscriber manager (SM) pods) that can provide wireless communication capabilities to one or more user equipment. The pods may be part of a clustered cloud computing environment, such as a Kubernetes cluster (e.g., available from the Cloud Native Computing Foundation).

[0074] Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management. It defines a set of building blocks (or "primitives") that provide deployment, maintenance, and scaling mechanisms based on CPU, memory, and / or various other metrics. To accommodate various workloads, a Kubernetes environment is extensible, and its internal components, extensions, and containers rely on various Kubernetes application programming interfaces (APIs). Cloud networks control computing and storage resources by defining resources as manageable objects. In Kubernetes, a pod may be defined as a basic scheduling unit and contains one or more containers that are guaranteed to be co-located on the same node. Each pod is assigned a unique IP address within the cluster, allowing applications to use ports without risk of conflict. Additionally, pods define volumes, such as local disk directories or network disks, and expose them to containers within the pod. In the subject cloud-native RAN, such pods may be scaled horizontally as user equipment capacity changes (e.g., increases, decreases, etc.).

[0075] 6 illustrates an example architecture 600 for routing messages associated with the transmission of data to and / or from one or more user equipment (UEs) within a centralized unit control plane (CU-CP). The architecture 600 may include a transport manager component 602, a protocol handler component 604, and one or more subscriber manager pods (SM pods) 606 (a, b, c, d). Each SM pod 606 may be associated with a predetermined user equipment handling capacity, such as, for example, a predetermined number of user equipment (e.g., 1250, but not limited to, other values ​​are possible / configurable) that it can handle during a particular period and / or at a particular time. The number of user equipment may be adjustable or may be predetermined based on the particular configuration, processing capacity, and / or any other factors of the communication system.

[0076] Using architecture 600, one or more incoming subscriber-related messages, such as F1 / W1 / NGC / S1 / Xn / X2 messages 601 (and / or any other subscriber context and / or identifiers), may be processed and multiplexed for transmission to one or more subscriber manager pods 606. The messages may be transmitted, for example, via a 3GPP-defined F1 / Xn / NGC / S1 / X2 interface. In particular, message 601 may be processed by transport manager 602 (e.g., an F1 / W1 / NGC / S1 / Xn / X2 transport manager that may include an SCTP termination) and provided at 603 to protocol handler 604. Protocol handler 604 may be configured to coordinate with a load balancer (e.g., as shown in FIG. 7) to determine the appropriate SM pod 606 to route the received message to. Processed messages 603 may include, but are not limited to, RRC message transfers, handover requests, etc., or messages that do not include an incoming application protocol (AP)-specific user equipment gNB / eNB identifier. If an incoming message includes an application protocol-specific user equipment gNB / eNB identifier, such message may be routed to a particular SM pod 606 at 607 (e.g., message 607a may be routed to SM pod 606a, message 607b may be routed to SM pod 606b, etc.).

[0077] Then, at 605, based on the message 603 received from the transport manager 602, the protocol handler 604 may be configured to determine a particular SM pod 606 to route the message to (e.g., message 605a may be routed to SM pod 606a, message 605b may be routed to SM pod 606b, etc.). The handler 604 may be configured to select the SM pod 606 that may be least loaded (e.g., least assigned user equipment and / or least processing user equipment). When a particular user equipment identifier is sent to an SM pod 606, the identifier may be configured to incorporate (e.g., using a few bits) an identifier of the SM pod 606 to which the user equipment identifier is sent for processing of the associated user equipment.

[0078] FIG. 7 illustrates an example architecture 700 for routing messages associated with transmitting data to / from one or more user equipment (UEs) in a centralized unit user plane (CU-UP). The architecture 700 may include a transport manager component 702, a load balancer component 704, and one or more user plane pods (UP pods) 706(a, b). Each UP pod 706 may be associated with a predetermined processing capacity (e.g., 3 Gbps, but not limited thereto; other values ​​are possible / configurable). The processing capacity may be adjustable or may be predetermined based on the particular configuration, processing capacity, and / or any other factors of the communication system.

[0079] Using architecture 700, one or more incoming subscriber-related messages, such as E1 messages 701, may be processed and multiplexed for transmission to one or more subscriber manager pods 706. Message 701 is processed by transport manager 702 (e.g., an E1 transport manager that may include an SCTP termination) and, assuming message 701 includes an E1 bearer context setup request, is provided at 703 to load balancer 704 to determine the appropriate UP pod 706 to route the received message to. If an incoming message includes an application protocol-specific user equipment identifier, such message may be routed at 707 to a particular UP pod 706 (e.g., message 707a may be routed to UP pod 706a, message 707b may be routed to UP pod 706b, etc.).

[0080] Based on the message 703 received from the transport manager 702, the load balancer 704 may then be configured to determine 705 a particular UP pod 706 to route the message (e.g., a bearer context for a particular user equipment) to (e.g., message 705a may be routed to UP pod 706a, message 705b may be routed to UP pod 706b). The load balancer 704 may be configured to select the UP pod 706 that is least loaded in terms of throughput. If a particular user equipment identifier is sent to a UP pod 706, the particular user equipment identifier can be assigned to the UP pod 706 (that receives the user equipment identifier), and the identifier may be configured to incorporate the identifier of that UP pod 706 (e.g., using a few bits).

[0081] In some implementations, the subject matter may be configured to determine when to trigger scale-in and / or scale-out of a particular capacity (e.g., the subscriber capacity of an SM pod 606 in the control plane of a centralized unit and / or the throughput capacity of a UP pod 706 in the user plane of a centralized unit). The subject matter may be configured to analyze various factors associated with a particular user equipment, such as, for example, whether the particular user equipment is associated or not associated and / or whether it includes / does not include an RRC inactive state. Furthermore, if a scale-out / in process is triggered, the subject matter may be configured to send an appropriate message / signal to one or more peer network functions (e.g., an eNB / gNB-DU and / or an EPC and / or a 5GC core network).

[0082] The RRC inactive state may be characterized by one or more of the following parameters (defined in 3GPP standard specifications) that do not change once the user equipment enters this state: in CU-UP: F1 UL GTPU TEID, N3 DL GTPU TEID, gNB-CU-UP UE E1AP ID, gNB-CU-CP UE E1AP ID; and in CU-CP: gNB-CU-CP UE E1AP ID, gNB-CU-UP UE E1AP ID, RAN UE NGAP ID, F1 UL GTPU TEID, I-RNTI. Thus, suspending a particular user equipment context (e.g., its current state, security-related information, user of a particular network slice, etc.) while saving computing resources, does not remove the user equipment's association with the corresponding subscriber manager pod (in the CU-CP) and user plane pod (in the CU-UP) (shown in Figures 6 and 7, respectively).

[0083] To address the above, in some implementations, the subject matter may be configured to determine when to subsequently scale one or more SM pods to accommodate additional user equipment in the CU-CP as the number of user equipment in connected mode changes. This allows new user equipment connecting to a gNB / eNB to be assigned to one or more new SM pods, thereby eliminating the need to move existing user equipment that may currently be anchored / assigned to a particular SM pod to the new SM pod. Furthermore, the subject matter may be configured to scale in (reduce) SM pods as the number of user equipment in connected mode decreases. If a particular SM pod is not completely depleted of user equipment, any remaining user equipment may be released and / or transitioned to other SM pods. When an SM pod is scaled in, any RRC inactive contexts previously associated with that SM pod may be released and / or transitioned to other SM pods.

[0084] Additionally, the subject matter may be configured to determine when to subsequently scale one or more UP pods to accommodate additional user equipment in a CU-UP as the number of user equipment in connected mode changes. When the throughput processed per UP pod approaches its predetermined threshold (e.g., 2 Gbps for downlink connections and 1 Gbps for uplink connections), the subject matter may be configured to scale out another UP pod. Additionally, new bearer creation may be assigned to the new UP pod, without necessarily redistributing existing bearers on existing UP pods to the new UP pod. UP pods may be scaled in as the number of bearers on a UP pod approaches zero.

[0085] In some implementations, the subject matter may be configured to analyze one or more of the following factors in either the control plane and / or user plane of a centralized unit for the purpose of performing auto-scaling of pods (e.g., SM pods, UP pods): In the control plane and / or user plane, one or more configurable thresholds (as described below) may be defined to determine when scale-out / in should be performed. The subject matter may define specific requirements for user equipment transition between SM pods and / or bearer transition between UP pods during capacity scale-in. In the control plane, the subject matter may be configured to transition (to a new SM pod) and / or release any RRC inactive context when a particular SM pod associated with that context is scaled in. Similarly, in the user plane, the subject matter may be configured to address any RRC inactive bearer context when a UP pod associated with that context is scaled in.

[0086] FIG. 8 illustrates an example process 800 for determining one or more capacity scaling triggers and / or performing capacity scaling in one or more pods (e.g., SM pod 606 and / or UP pod 706) according to some implementations of the present subject matter. Process 800 may be performed in one or more components of a base station (e.g., eNB, gNB), for example, as shown in and described above with respect to FIGS. 1a-7. At 802, one or more user equipment information (e.g., data packets, messages (e.g., F1, W1, NGC, S1, Xn, X2, E1, etc.), etc.) may be received. For example, the messages may be received by the transport controller components 602, 702 of the base station as shown in FIGS. 6 and 7, respectively.

[0087] At 804, the information received from the user equipment may be used to determine a plane associated with each user equipment communication, e.g., a control plane, a user plane. At 806, the state of each user equipment may also be determined. For example, it may be determined that a particular user equipment is in an RRC inactive state. Alternatively, or additionally, it may be determined that no user equipment is in an RRC inactive state. Process 800 may then proceed, at 804-806, to determining one or more triggers for when to perform capacity scaling in one or more pods based on the determination.

[0088] In particular, at 808, the subject matter may be configured to determine one or more triggers for performing capacity scale-out / in of a CU-CP of a base station (e.g., eNB / gNB) when no user equipment is in an RRC inactive state. For this determination, the subject matter may use the following configurable threshold values ​​in the CU-CP: a weight W (having a value between 0 and 1) assigned to one or more RRC connected user equipments, a weight W (having a value between 0 and 1) assigned to the number of handled calls per second, and a threshold Th for performing capacity scale-out. o , and the threshold(s) for performing capacity scale-in Th i Assuming the current number of RRC connected user equipments is Rn and the average number of calls per second is C, the subject matter may define 808 a scale-out trigger using the following: TIFF2025186462000002.tif13160, where the total exceeds the weighted RRC connected users and calls per second across all available instances of SM Pod 606.

[0089] The subject matter may define a scale-in trigger at 808 using: TIFF2025186462000003.tif13160, where the total is over the weighted RRC connected users and calls per second across all available instances of SM pod 606.

[0090] Alternatively, or in addition, the present subject matter may be configured to, at 808, determine one or more triggers for performing capacity scale-out / in of a CU-CP of a base station (e.g., eNB / gNB) when one or more user equipments are in an RRC inactive state. For this determination, the present subject matter may use the following configurable thresholds in the CU-CP: W of weights assigned to one or more RRC connected user equipments; R a weight W (having a value between 0 and 1) assigned to one or more RRC inactive user equipments; I (having a value between 0 and 1), the weight assigned to the number of calls processed per second Wc (having a value between 0 and 1), and the threshold Th for performing capacity scale-out. o , and the threshold Th for performing capacity scale-in i Assuming that the current number of RRC connected user equipment is Rn, the current number of RRC inactive user equipment is Ri, and the average number of calls per second is C, the subject matter may define 808 a scale-out trigger using the following: TIFF2025186462000004.tif13160, where the total is over the weighted RRC connected users, RRC inactive users, and calls per second across all available instances of SM pod 606.

[0091] Similarly, the present subject matter may define 808 a trigger for scaling in the capacity of the SM pod 606 using: TIFF2025186462000005.tif13160 and the totals are over weighted RRC connected users, RRC inactive users, and calls per second across all available instances of the subscriber manager pod.

[0092] Further, at 808, the subject matter can be configured to determine one or more triggers for performing capacity scale-out / in of a CU-UP of a base station (e.g., eNB / gNB) when no user equipment is in an RRC inactive state. For this determination, the subject matter can use the following configurable thresholds in the CU-UP: weights W assigned to one or more RRC connected user equipments; R (having a value between 0 and 1), the threshold Th for executing capacity scale-out o , and the threshold Th for performing capacity scale-in i Assuming the current throughput in CU-UP is TPR, the subject matter may define 808 a scale-out trigger using the following: TIFF2025186462000006.tif13160, and the total exceeds the weighted throughput across all available instances of UP pod 706.

[0093] Additionally, the present subject matter may also define a scale-in trigger at 808 using: TIFF2025186462000007.tif13160, and the total exceeds the weighted throughput across all available instances of UP pod 706.

[0094] Similar to the CU-CP processing, the present subject matter may be configured to determine 808 one or more triggers for performing capacity scale-out / in of the CU-UP of a base station (e.g., eNB / gNB) when one or more user equipments are in an RRC inactive state. In this case, the present subject matter may determine ... R a weight W (having a value between 0 and 1) assigned to one or more RRC inactive user equipments; I (having a value between 0 and 1), the threshold Th for executing capacity scale-out o , and the threshold Th for performing capacity scale-in i , where the current throughput observed in the CU-UP is TRR and the expected throughput of the suspended bearer (e.g., for a user equipment in an RRC inactive state) is TP I Assume that , This value may be determined by summing the session aggregate maximum bit rate (AMBR) values ​​of all paused packet data unit (PDU) sessions. Using the above value, the subject matter may define 808 a scale-out trigger using the following: TIFF2025186462000008.tif13160, the sum exceeding the weighted throughput of RRC connected users and the weighted expected throughput of RRC inactive users across all available instances of UP pod 706.

[0095] The scale of the trigger can be defined using: TIFF2025186462000009.tif13160, the sum exceeding the weighted throughput of RRC connected users and the weighted expected throughput of RRC inactive users across all available instances of UP pod 706.

[0096] 8, at 810, scaling may be performed according to one or more triggers as defined at 808. In this case, the execution of scaling may depend on a particular plane (e.g., control plane, user plane) as well as a pod (SM pod 606, UP pod 706 shown in FIGS. 6 and 7, respectively).

[0097] Thus, if it is determined that one or more SM pods 606 associated with a CU-CP of a base station (e.g., gNB, eNB) may need to be scaled in based on one or more triggers defined above being met, the present subject matter may be configured to perform one or more of the following processes, as shown in Figures 9a-9c:

[0098] In some implementations, the present subject matter may be configured to wait for all RRC-connected user equipment contexts handled by a particular SM pod 606 to self-release (e.g., when the user equipment enters an idle state), and then release the capacity of that SM pod 606, which may include making various resources (e.g., computing, memory, etc.) available for consumption / use. Figure 9a shows an example process 900 for performing scale-in of one or more SM pods 606 in accordance with some implementations of the present subject matter. As shown in Figure 9a, SM pod 606a may have, by way of non-limiting example, 600 RRC-connected user equipment, and SM pod 606b may have, by way of non-limiting example, 0 RRC-connected user equipment.

[0099] Thus, as soon as the defined scale-in trigger for SM pod 606b is met (e.g., as determined according to one or more of equations (1)-(4)), SM pod 606b may be marked for scale-in and removed. As a result, no new user equipment contexts (e.g., identifiers, etc.) may be allocated to and / or created on SM pod 606b. Furthermore, protocol handler 604 and load balancer may ensure that no new user equipment contexts are routed to SM pod 606b.

[0100] Alternatively, or additionally, in some implementations, the present subject matter may be configured to wait for all RRC connected and RRC inactive user equipment contexts addressed by a particular SM pod 606 to release on their own (e.g., when the user equipment enters an idle state), and then release the capacity of that SM pod 606. Figure 9b shows an example process 902 for performing scale-in of one or more SM pods 606 in accordance with some implementations of the present subject matter. As shown in Figure 9b, SM pod 606a may have, by way of non-limiting example, 600 RRC connected user equipment and 500 RRC inactive user equipment, and SM pod 606b may have, by way of non-limiting example, 0 RRC connected user equipment and 0 RRC inactive user equipment.

[0101] Thus, as soon as the defined scale in the trigger for SM pod 606b is met (e.g., again defined according to one or more of equations (1)-(4)), SM pod 606b may be marked for scale-in and removed. Thus, no new user equipment contexts are created on SM pod 606b, and load balancer and protocol handler 604 may ensure that no new user equipment contexts are routed to that SM pod.

[0102] Further alternatively (or in addition), the present subject matter may be configured to move user equipment context from the SM pod 606 being scaled in to other SM pods 606. FIG. 9c illustrates an example process 904 for performing scale-in of one or more SM pods 606 in accordance with some implementations of the present subject matter. As shown in FIG. 9c, SM pod 606a may have, by way of non-limiting example, 600 RRC-connected user equipment and 500 RRC-inactive user equipment, and SM pod 606b may have, by way of non-limiting example, 80 RRC-connected user equipment and 20 RRC-inactive user equipment. User equipment assigned to SM pod 606b may be transitioned 907 to SM pod 606a. When a user equipment context transitions (and / or moves) from one SM pod 606 (e.g., SM pod 606a) to another SM pod 606 (e.g., SM pod 606b), one or more of the following user equipment identifiers (UE IDs) may be configured to change and may be sent to one or more peer nodes (e.g., DU, MME, AMF, etc.): gNB- / eNB-CU-CP UE E1AP ID, gNB- / eNB-CU-CP UE F1AP and / or W1AP ID, gNB- / eNB-CU-CP UE NGAP and / or S1AP ID, and / or any combination thereof.

[0103] In some implementations, one or more custom message extensions to one or more of the following messages may or may not be implemented to support such identifier changes: ·UE CONTEXT MODIFICATION REQUEST for F1 and W1, New user equipment level NGAP messages for signaling NGAP PDU SESSION RESOURCE MODIFY INDICATION and / or UE ID changes, · UE CONTEXT MODIFY INDICATION for S1AP, BEARER CONTEXT MODIFICATION REQUEST for E1AP, and / or SGNB MODIFICATION REQUIRED for X2AP (this is applicable for 5G deployed in ENDC mode).

[0104] When the user equipment context is transitioned from another SM pod 606a to SM pod 606b, the UE ID does not change. In this case, the UE ID may be assigned from the shared database 908 and / or any other storage location that may be accessible by the base station. The mapping of the UE ID to the SM pod (to which the user equipment is transitioned) may be updated in the database 908 with the new SM pod (i.e., SM pod 606a) information. Thus, the transport manager 602 fails (905) to deliver the new message 601 received by the SM pod 606b to the SM pod 606b.

[0105] Referring back to FIG. 8, if it is determined based on one or more triggers defined in 808 that one or more UP pods 706 associated with the CU-UP of a base station (e.g., gNB, eNB) may need to be scaled in, the present subject matter may be configured to perform one or more of the following processes, as shown in FIGS. 10a-10c:

[0106] In some implementations, the present subject matter can be configured to wait for all RRC-connected user equipment bearer contexts handled by a particular UP pod 706 to self-release (e.g., when the user equipment enters an idle state) before releasing the capacity of that UP pod 706, which may include making various resources (e.g., computing, memory, etc.) available for consumption / use. Figure 10a shows an example process 1000 for performing scale-in of one or more UP pods 706 in accordance with some implementations of the present subject matter. As shown in Figure 10a, UP pod 706a can have, as a non-limiting example, 1 Gbps of capacity for processing throughput associated with the user equipment, and UP pod 706b can have, as a non-limiting example, 0 Gbps of capacity.

[0107] Thus, as soon as the defined scale-in trigger for UP pod 706b is met (e.g., as determined according to one or more of equations (5)-(8)), UP pod 706b may be marked for scale-in and removed. As a result, for example, during an E1 bearer context setup procedure, no new user equipment bearer contexts may be allocated to UP pod 706b and / or no new user equipment bearer contexts may be created on UP pod 706b. Furthermore, protocol handler 604 and load balancer 704 may ensure that no new user equipment contexts are routed to UP pod 706b.

[0108] Alternatively, or additionally, in some implementations, the present subject matter may be configured to wait for all RRC connected and RRC inactive user equipment bearer contexts handled by a particular UP pod 706 to self-release (e.g., when the user equipment enters an idle state) before releasing the capacity of that UP pod 706. Figure 10b shows an example process 1002 for performing scale-in of one or more UP pods 706 in accordance with some implementations of the present subject matter. As shown in Figure 10b, a currently used UP pod 706a may, by way of non-limiting example, include 1 Gbps of throughput capacity and 500 RRC inactive user equipment, while UP pod 706b may, by way of non-limiting example, have 0 Gbps of throughput capacity and 0 RRC inactive user equipment.

[0109] Thus, as soon as the defined trigger-in-scale for UP pod 706b is met (e.g., again defined according to one or more of equations (5)-(8)), UP pod 706b may be marked for scale-in and removed. Thus, there may be no new user equipment bearer contexts allocated to and / or created on UP pod 706b, for example, during the E1 bearer context setup procedure. Furthermore, protocol handler 604 and load balancer 704 may ensure that no new user equipment contexts are routed to UP pod 706b.

[0110] Further alternatively (or in addition), the present subject matter may be configured to move user equipment contexts from the UP pod 706 being scaled in to other UP pods 706. FIG. 10c illustrates an example process 1004 for performing scale-in of one or more UP pods 706 in accordance with some implementations of the present subject matter. As shown in FIG. 10c, the currently used UP pod 706a may include, by way of non-limiting example, 1 Gbps throughput capacity and 500 RRC inactive user equipment, while the UP pod 706b may have, by way of non-limiting example, 500 Mbps throughput capacity and 20 RRC inactive user equipment and have 50 RRC connected user equipment bearer contexts. The user equipment bearer contexts assigned to the UP pod 706b may be transitioned to the UP pod 706a at 1007. This may result in the F1-U / NG-U (N3) and / or S1-U endpoints being changed for the bearers being transitioned. The F1-U / NG-U(N3) / S1-U endpoint information may include at least one of the F1-U / NG-U(N3) / S1-U GTP-U tunnel TNL address (IP address), the GTP-U TEID, and any combination thereof.

[0111] In some implementations, the CU-UP can signal the change in endpoint address using the E1 BEARER CONTEXT MODIFICATION REQUIRED message. Once the endpoint address has changed and signaled to the CU-CP, the CU-CP can be configured to notify the peer node via F1 / W1 / NGC / S1 signaling using one of the following messages: ·F1AP / W1AP UE CONTEXT MODIFICATION REQUEST ·NGAP PDU SESSION RESOURCE MODIFY INDICATION UE CONTEXT MODIFY INDICATION for S1AP X2AP SGNB MODIFICATION REQUIRED (applicable to 5G deployed in ENDC mode)

[0112] In the E1 BEARER CONTEXT MODIFICATION REQUIRED message (defined in 3GPP TS 38.463), it may be possible to modify the GTP endpoints on the N3 and S1U sides, but not the uplink endpoints on the F1-U side. Therefore, the present subject matter may be configured to generate a custom extension (e.g., a new IE) for this message to allow modification of the F1-U UL GTPU endpoint.

[0113] In some implementations, the present subject matter can be configured to be implemented in a system 1100, as shown in FIG. 11 . The system 1100 can include one or more of a processor 1110, a memory 1120, a storage device 1130, and an input / output device 1140. Each of the components 1110, 1120, 1130, and 1140 can be interconnected using a system bus 1150. The processor 1110 can be configured to process instructions for execution within the system 600. In some implementations, the processor 1110 can be a single-threaded processor. In alternative implementations, the processor 1110 can be a multi-threaded processor. The processor 1110 can be further configured to process instructions stored in the memory 1120 or the storage device 1130, including receiving or transmitting information via the input / output device 1140. The memory 1120 can store information within the system 1100. In some implementations, the memory 1120 can be a computer-readable medium. In alternative implementations, memory 1120 may be a volatile memory unit. Additionally, in some implementations, memory 1120 may be a non-volatile memory unit. Storage device 1130 may be capable of providing mass storage for system 1100. In some implementations, storage device 1130 may be a computer-readable medium. In alternative implementations, storage device 1130 may be a floppy disk device, a hard disk device, an optical disk device, a tape device, a non-volatile solid-state memory, or any other type of storage device. Input / output device 1140 may be configured to provide input / output operations to system 1100. In some implementations, input / output device 1140 may include a keyboard and / or a pointing device. In alternative implementations, input / output device 1140 may include a display unit for displaying a graphical user interface.

[0114] FIG. 12 illustrates an example method 1200 for scaling subscriber capacity in a cloud-native radio access network (RAN) in accordance with some implementations of the present subject matter. Method 1200 may be performed using one or more implementations illustrated in FIGS. 6-10c. At 1202, a processing capacity allocated to one or more containers (e.g., SM pod, UP pod, etc.) within a plurality of containers of a cloud-native radio access network to provide communications for at least one user equipment (UE) within a plurality of user equipments may be determined. The capacity may be determined based on the number of UEs a particular container serves (e.g., in the control plane) and / or the throughput of that container (e.g., in the user plane). At 1204, the determined processing capacity may be compared with at least one predetermined threshold within a plurality of predetermined thresholds (e.g., as described in connection with one or more of Equations (1)-(8)). At 1206, based on the comparison, a determination may be made as to whether to change the allocation of processing capacity (e.g., whether to scale out / in such capacity in either the control plane and / or the user plane by transitioning one UE to another container). The change in the allocation of processing capacity may be based on one or more of increasing the number of containers and / or decreasing the number of containers that service user equipment.

[0115] In some implementations, the present subject matter can include one or more of the following optional features: In some implementations, the method can also include changing the allocation of processing capacity.

[0116] In some implementations, the containers may be associated with at least one of at least one control plane component and at least one user plane component of a centralized unit of the base station. The determination of whether to change the allocation of allocated processing capacity may include at least one of: increasing the number of user equipments being processed by the at least one control plane component by increasing the number of containers that provide communications to the user equipments; decreasing the number of user equipments being processed by the at least one control plane component by decreasing the number of containers that provide communications to the user equipments; increasing the throughput capacity of the at least one user plane component by increasing the number of containers that provide communications to the user equipments; decreasing the throughput capacity of the at least one user plane component by decreasing the number of containers that provide communications to the user equipments; and any combination thereof.

[0117] In some implementations, at least one of determining the processing capacity, comparing, and determining whether to change the processing capacity may be performed by at least one base station in the wireless communication system. The base station may include at least one of a base station, an eNodeB base station, a gNodeB base station, a radio base station, a wireless access point, and any combination thereof. The base station may be a base station operating in at least one of the following communication systems: a long-term evolution communication system, a new wireless communication system, a wireless communication system, and any combination thereof. The base station may include at least one centralized unit, the centralized unit including at least one of a control plane component, a user plane component, and any combination thereof.

[0118] In some implementations, one or more user equipments of the plurality of user equipments may be associated with a radio resource control (RRC) state. The RRC state may include at least one of the following: an RRC inactive state, no RRC inactive state, an RRC connected state, and any combination thereof. One or more predetermined weights may be assigned to one or more user equipments of the plurality of user equipments based on the RRC state. The at least one predetermined threshold may be selected from a plurality of predetermined thresholds based on the RRC state of the one or more user equipments. The comparing may include comparing a decision processing capacity determined for one or more user equipments assigned the one or more predetermined weights with the predetermined threshold selected based on the RRC state of the one or more user equipments.

[0119] In some implementations, the method may further include transitioning at least one user equipment assigned to the at least one container to at least another container among the plurality of containers based on the determination of whether to change the processing capacity allocation, and providing communications to the transitioned user equipment using the at least another container. The method may also include preventing the at least one container from providing communications to at least another user equipment among the plurality of user equipment after the transition. The method may also include modifying at least one identifier of the transitioned user equipment. The method may further include preventing modification of the at least one identifier of the transitioned equipment. The identifier may include at least one of a user equipment identifier, a user equipment bearer identifier, at least one user plane endpoint address, an Internet Protocol (IP) address, a GPRS Tunneling Protocol User Data Tunneling Endpoint Identifier (GTP-U TEID), and any combination thereof associated with the at least one user equipment. The identifier may be stored in at least one database. The at least one container may be configured to retrieve the identifier from the database and assign the retrieved identifier to the transitioned user equipment. The database may store a mapping between the retrieved identifier and the at least one container.

[0120] In some implementations, the at least one predetermined threshold may include at least one of a first threshold associated with an increase in processing capacity, a second threshold associated with a decrease in processing capacity, and any combination thereof. Comparing may include comparing at least one of the first and second thresholds to at least one of the following: one or more user equipment having a predetermined radio resource control (RRC) state and associated with a first predetermined weight; a number of communications from one or more user equipment processed by the one or more containers per predetermined time period; a throughput associated with the one or more containers; and any combination thereof. In some implementations, changing the allocation of processing capacity may include at least one of increasing the processing capacity when the first threshold is exceeded based on the comparison and decreasing the processing capacity when the second threshold is not exceeded based on the comparison.

[0121] The systems and methods disclosed herein may be embodied in various forms, including, for example, a data processor such as a computer, which may also include a database, digital electronic circuitry, firmware, software, or combinations thereof. Furthermore, the above-described features and other aspects and principles of the implementations of the present disclosure may be implemented in various environments. Such environments and associated applications may be specially constructed to perform the various processes and operations in accordance with the disclosed implementations, or they may include general-purpose computers or computing platforms selectively activated or reconfigured by code to provide the required functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, but may be implemented by any suitable combination of hardware, software, and / or firmware. For example, various general-purpose machines may be used with programs written in accordance with the teachings of the disclosed implementations, or it may be more convenient to construct specialized apparatus or systems to perform the required methods and techniques.

[0122] The systems and methods disclosed herein may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., a machine-readable storage device, or in a propagated signal, for execution by or control of the operation of a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. The computer program may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. The computer program may be deployed to be executed on one computer, on multiple computers at one site, or distributed across multiple sites and interconnected by a communications network.

[0123] As used herein, the term "user" can refer to any entity, including a person or a computer.

[0124] Although ordinal numbers such as first, second, etc. may relate to order in some circumstances, ordinal numbers as used in this document do not necessarily imply ordering. For example, ordinal numbers may be used simply to distinguish one item from another, e.g., to distinguish a first event from a second event, but do not necessarily imply a chronological order or a fixed system of reference (such as the first event in one paragraph of a description being different from the first event in another paragraph of the description).

[0125] The foregoing description is intended to illustrate, but not to limit, the scope of the invention, which is defined by the appended claims. Other implementations are within the scope of the following claims.

[0126] These computer programs, which may also be referred to as programs, software, software applications, applications, components, or code, contain machine instructions for a programmable processor and may be implemented in a high-level procedural and / or object-oriented programming language and / or assembly / machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus, and / or device used to provide machine instructions and / or data to a programmable processor, such as, for example, magnetic disks, optical disks, memory, and programmable logic devices (PLDs), and includes a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor. A machine-readable medium may non-transitory store such machine instructions, such as, for example, a non-transitory solid-state memory or a magnetic hard drive or any equivalent storage medium. Alternatively or additionally, a machine-readable medium may temporarily store such machine instructions, such as, for example, a processor cache or other random access memory associated with one or more physical processor cores.

[0127] To provide for interaction with a user, the subject matter described herein may be implemented on a computer having a display device, such as a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user, and a keyboard and pointing device, such as a mouse or trackball, by which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user. For example, feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including, but not limited to, acoustic, speech, or tactile input.

[0128] The subject matter described herein may be implemented in a computing system including back-end components, such as, for example, one or more data servers, or middleware components, such as, for example, one or more application servers, or front-end components, such as, for example, one or more client computers having a graphical user interface or web browser through which a user can interact with an implementation of the subject matter described herein, or any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication, such as, for example, a communications network. Examples of communications networks include, but are not limited to, a local area network ("LAN"), a wide area network ("WAN"), and the Internet.

[0129] A computing system may include clients and servers. Clients and servers are generally, though not exclusively, remote from each other and typically interact through a communication network. The relationship of client and server is mediated by computer programs running on the respective computers and having a client-server relationship to each other.

[0130] The implementations set forth in the foregoing description do not represent all implementations consistent with the subject matter described herein. Instead, they are merely some examples consistent with aspects related to the described subject matter. While some variations have been described in detail above, other modifications or additions are possible. In particular, additional features and / or variations may be provided in addition to those described herein. For example, the implementations described above may be directed to various combinations and subcombinations of the disclosed features and / or combinations and subcombinations of certain additional features described above. Furthermore, the logic flow illustrated in the accompanying drawings and / or described herein does not necessarily require the particular order shown, or sequential order, to achieve desirable results. Other implementations may be within the scope of the following claims.

Claims

1. determining processing capacity allocated to one or more containers within a plurality of containers of a cloud-native radio access network for providing communications to at least one user equipment within a plurality of user equipments; comparing the determined processing capacity with at least one predetermined threshold of a plurality of predetermined thresholds; determining whether to change the processing capacity allocation based on the comparing; and modifying the allocation of processing capacity; The method, wherein the at least one predetermined threshold comprises at least one of a first threshold associated with an increase in the processing capacity and a second threshold associated with a decrease in the processing capacity.

2. 2. The method of claim 1, wherein the one or more containers are associated with at least one of at least one control plane component and at least one user plane component of a centralized unit of a base station, and wherein determining whether to change the allocation of the allocated processing capacity comprises at least one of: increasing a number of user equipments being processed by the at least one control plane component by increasing a number of containers that provide communications to the user equipments; decreasing the number of user equipments being processed by the at least one control plane component by decreasing the number of containers that provide communications to the user equipments; increasing a throughput capacity of the at least one user plane component by increasing a number of containers that provide communications to the user equipments; decreasing a throughput capacity of the at least one user plane component by decreasing the number of containers that provide communications to the user equipments; or any combination thereof.

3. 10. The method of claim 1, wherein at least one of determining processing capacity, comparing, and determining whether to change the allocation of processing capacity is performed by at least one base station in a wireless communication system.

4. 4. The method of claim 3, wherein the base station includes at least one centralized unit, the centralized unit including at least one of a control plane component, a user plane component, and any combination thereof.

5. The method of claim 1 , wherein modifying the allocation of the processing capacity comprises increasing the processing capacity when the first threshold is exceeded based on the comparing.

6. The method of claim 1 , wherein altering the allocation of the processing capacity comprises decreasing the processing capacity when the second threshold is not exceeded based on the comparing.

7. 2. The method of claim 1, wherein one or more user equipments of the plurality of user equipments are associated with a radio resource control (RRC) state, the RRC state comprising at least one of an RRC inactive state, no RRC inactive state, an RRC connected state, and any combination thereof.

8. The method of claim 7 , wherein one or more predetermined weights are assigned to the one or more user equipments of the plurality of user equipments based on the RRC state.

9. The method of claim 8 , wherein the at least one predetermined threshold is selected from a plurality of predetermined thresholds based on the RRC state of the one or more user equipments.

10. 10. The method of claim 9, wherein the comparing comprises comparing the determined processing capacity determined for the one or more user equipments assigned the one or more predetermined weights with the at least one predetermined threshold selected based on the RRC state of the one or more user equipments.

11. 2. The method of claim 1, further comprising: transitioning the at least one user equipment assigned to the one or more containers to at least another container of the plurality of containers based on the determination of whether to change the processing capacity; and providing communications to the transitioned at least one user equipment using the at least another container.

12. The method of claim 11 , further comprising preventing the one or more containers from providing communications to at least another user equipment of the plurality of user equipment after the transition.

13. The method of claim 11 , further comprising: changing at least one identifier of the transitioned at least one user equipment.

14. The method of claim 11 , further comprising: preventing modification of at least one identifier of the transitioned at least one user equipment.

15. 14. The method of claim 13, wherein the at least one identifier comprises at least one of a user equipment identifier, a user equipment bearer identifier, at least one user plane endpoint address, an Internet Protocol (IP) address, a GPRS Tunneling Protocol User Data Tunneling Endpoint Identifier (GTP-U TEID), and any combination thereof associated with the at least one user equipment.

16. 16. The method of claim 15, wherein the at least one identifier is stored in at least one database, and the one or more containers are configured to retrieve the at least one identifier from the at least one database and assign the retrieved at least one identifier to the transitioned at least one user equipment.

17. 17. The method of claim 16, wherein the at least one database stores a mapping between the retrieved at least one identifier and the one or more containers.

18. The comparing step comprises: one or more user equipments having a predetermined radio resource control (RRC) state and associated with a first predetermined weight; a number of communications from the one or more user devices per predetermined time period that are handled by the one or more containers; and a throughput associated with the one or more containers; and Any combination of these, and at least one of The method of claim 1 , comprising comparing to at least one of the first threshold and the second threshold.

19. at least one processor; at least one non-transitory storage medium storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the operations of any one of claims 1 to 18; and 1. An apparatus comprising:

20. 19. At least one non-transitory storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform the operations of any one of claims 1 to 18.

Images