Patent Description:
Conventional wireless communications systems are made up of multiple base stations that generate wireless signals at prescribed frequencies and encoding schemes, over which wireless communication devices within reach of the wireless signals (i.e., within a wireless coverage area) can connect and communicate with a terrestrial communications network, enabling communications to other devices, systems, computers, networks and so forth. These conventional wireless communications systems are very inefficient in several ways. Notably, the base stations are individually engineered to accommodate a peak concurrent number of wireless communication devices and their corresponding connections. A wireless coverage area often includes multiple base stations generating signals at the same, and at different, frequency bands, to accommodate such peak concurrent usage. However, while serving the same wireless coverage areas, each base station is individually engineered to meet a fixed peak capacity level. Furthermore, peak concurrent usage often occurs for only a brief period on any given day or week. In addition, usage patterns often vary widely from one wireless coverage area to another. For example, peak concurrent usage within an office building in a commercial business district might occur at <NUM>:<NUM> pm, while peak concurrent usage within an apartment building in a residential community might occur at <NUM>:00pm. In each case, the wireless base stations serving each of those locations are engineered to serve peak usage capacity, even though the system operates substantially below the peak levels for the vast majority of the time. The result is a network of base stations that are individually over-engineered at fixed peak capacity levels resulting in significantly higher than necessary costs for each individual base station as well as for the entire wireless communication system as a whole.

There are certain small cell baseband solutions that are said to optimize base station connections within a given local wireless coverage area such as single building. However, none of these solutions can balance concurrent connections across many base stations serving multiple disparate and geographically dispersed wireless coverage areas or locations.

There are other solutions that are configured such that the baseband processor portion of the solution is separated physically from the radio portion of the solution by a network referred to as a fronthaul. In these cases, the baseband processor is a physical embedded hardware device with physical interface connections to multiple radios (typically <NUM> physical connections). In some cases radios can be "daisy chained" to support multiples of <NUM> (for example: <NUM>(6x2), <NUM>(6x3), <NUM>(6x24)) radios per baseband processor device. In this case, a single physical baseband processor device can connect over a dedicated physical fronthaul connection (typically a fiber optic medium) to the radios that are physically located elsewhere. Each embedded baseband processor can support multiple concurrent device connections (e.g., <NUM> device connections) whereby the actual connections may be spread across the various physical sites where the radios are located. Furthermore, some solutions allow for more than one baseband processor device (typically <NUM>) to be pooled within a common on equipment chassis or sub rack. Due to very rigid and short latency requirements mandated by relevant standard specifications, the geographic distance that can be accommodated by such fronthaul solutions is limited to a few kilometers.

Deficiencies of these solutions include the following. First, these known solutions are limited to sharing capacity between a fixed and finite number of physical embedded baseband processors that are collocated at the same physical site. Second, shared capacity is limited to a few thousand device connections.

Other known technologies include Call Admission Control (CAC) systems, which are designed to prevent oversubscription of Voice Over IP (VoIP) networks, or other "real time" communications solutions where oversubscription can degrade overall performance for users of the system. Such real-time media traffic is very sensitive to network latency and congestion, as opposed to data traffic, such as a connection to an email server, which is very tolerant over latency. These CAC solutions are used in the set-up phase of a call or connection and as such can be considered as a preventive congestion control procedure such that a connection will be prevented if and when it is expected to result in a congestion condition. Typically, CAC procedures can be completed within a relatively long response cycle, which may be as high as <NUM> milliseconds or even greater.

Deficiencies of CAC solutions include the following. As noted above, CAC solutions evaluate connection requests at the time of access and either allow or disallow access based on service conditions at that point in time. These admission requests can take a relatively long time to complete, for instance more than <NUM> milliseconds, depending on various network conditions. For example, the call admission control "service" may not be physically collocated with the network access components, but is reachable across a shared network such as an IP network. An asynchronous solution such as Voice over IP can easily tolerate such long duration requests. However, this approach is not feasible for wireless mobile communications where connection operations have strict timing constraints measured in low milliseconds and microseconds.

Accordingly, what is needed is a system for a wireless network that can efficiently accommodate for temporal and geographic fluctuations in peak concurrent demand for wireless device connections, served by a network of base stations that may be dispersed across a wide geography. The system must conform to the very demanding latency constraints of advanced wireless communications standards, while more accurately measuring and accounting for actual system wide concurrent connections of the wireless communication system to wireless communication devices. What is further needed is a system that balances and rebalances concurrent connection capacity, ensuring the most optimal and efficient use of the wireless communication system.

<CIT> describes a virtualization system comprising a baseband processing arrangement. The virtualization system is configured to provide a plurality of virtual machines, each virtual machine having an allocation of baseband processing capacity provided by the baseband processing arrangement for serving remote radio units. The virtualization system is configured to dynamically re-allocate baseband processing capacity between virtual machines based on at least one parameter related to radio domain requirements of the remote radio units.

<CIT> describes an apparatus including a monitor module configured to monitor a set of performance indicators associated with a first network topology of a wireless network provider system. In the first network topology, a set of virtual baseband units services a set of remote radio heads. The apparatus includes a detector module configured to detect an operational condition of the wireless network provider system based on at least one value associated with the set of performance indicators at a first time. The apparatus further includes an optimization module configured to define, based on the operational condition, a second network topology for the set of virtual baseband units. The optimization module is further configured to send a signal to a virtual baseband unit pool manager to configure the wireless network provider system in the second network topology at a second time after the first time.

An aspect of the present invention involves a system for allocating capacity in a wireless communication network, according to claim <NUM>.

Another aspect of the present invention involves a method of dynamically allocating connection capacity in a wireless communication system, according to the independent claim <NUM>.

Further embodiments are specified in the dependent claims.

Disclosed is an Adaptive Connection Control System (ACCS) that may be integrated into a wireless communications system infrastructure. The ACCS has a hierarchy of at least four tiers of subsystems: a plurality of baseband-level capacity processors within a given wireless base station of a plurality of wireless base stations dispersed across a broad geographical area; a plurality of client-level capacity processors (also referred to as "ACCS Clients"), each of which may be integrated into a given wireless base stations whereby each client-level capacity processor sits above, and is coupled to, the baseband-level capacity processors within a given wireless base station; a plurality of server-level capacity processors (also referred to as "ACCS Servers"), each of which sits above, and is coupled to, a given plurality of client-level capacity processors; and a master-level capacity processor (also referred to as an "ACCS Master"), which sits above, and is coupled to, the server-level capacity processors and responds to the needs and coordinates the actions of the server-level capacity processors and client-level capacity processors. The server-level capacity processors and the master-level capacity processor may be deployed within a wireless network operator's terrestrial network or may be deployed in a cloud computing environment.

The disclosed ACCS creates a distinction between physical capacity of the wireless communications infrastructure and the logical capacity of the wireless communications system. In conventional systems these are one and the same, whereby for the wireless communications infrastructure all of the wireless base stations must be designed for peak capacity and thus over-engineered. The wireless network operator must pay for that extra capacity, whether it is being used or not. With the physical capacity severed from the logical capacity, the wireless network operator need only pay for the logical capacity that is being used. Further, the geographic distribution of the logical capacity may vary greatly and dynamically over time.

The ACCS identifies connections that are reflective of real world user activity or usage of the wireless network, which is important because the nature of wireless communications is wide ranging and volatile. For example, voice calls impose a very different network load from text message exchanges, which are different from emails with attachments. Video streaming is different than interactive two-way video, etc. Furthermore, devices continuously send and receiving "background" communications, unknown to the users, such as message count updates for new social media posts, or file backups to cloud storage sites. Consequently, it is typical that wireless devices are "connected" to the network even when there is no user-initiated or user-involved communications.

Also, with the advent of Internet of Things and machine-to-machine communications, connections are often short in terms of duration and small in terms of information conveyed. It is highly desirable to identify the types of devices and characterize their impact on network capacity.

The ACCS dynamically allocates wireless connection capacity throughout the wireless network by maintaining an access pool of a predetermined number of connection tokens. As used herein, a connection token is a logical representation of a single active connection between a wireless base station and a given wireless device. A connection token may represent a number of wireless resources required for a single active connection (e.g., number of DL-SCH/CCH or UL-SCH/CCH transport block bits, etc.) of one or more bearers (e.g., across one or more aggregated carriers) for a single UE. Accordingly, for example, a given baseband processor (via its corresponding baseband-level capacity processor) has a given wireless capacity that may be quantized in connection tokens and managed accordingly. The logical representation of a connection token may be implemented in memory as a single value that is counted (incremented and decremented) as the number of connection tokens changes, as wireless capacity increases and decreases. For example, an ACCS may have a certain allocation of connection tokens in its master access pool that it allocates (via each server-level capacity processor and client-level capacity processor) to its individual baseband-level capacity processors. As each new wireless device gets connected to each baseband processor, the number of connection tokens allocated to its corresponding baseband-level capacity processor gets decremented by one. Once the connection terminates, the connection is released back to the baseband processor's corresponding baseband-level capacity processor, and the number of connection tokens is re-incremented. This may be done regardless of the type of wireless device, such as smartphone, tablet, vehicle, or fixed or stationary IoT appliance (e.g., gas meter, water valve, parking meter, building security system, etc.). Further, the access pool may have a specific allocation of connection tokens for each different device category, such as 3GPP-defined Device Category (e.g., Cat <NUM>-<NUM>, Cat M, etc.). Alternatively, a connection token may be implemented as a software object or data object that includes information about device category, etc. As used herein, an "allocation" may refer to an aggregate of connection tokens that are allocated to, or transmitted to and held by, a given baseband-level capacity processor, client-level capacity processor, or server-level capacity processor.

Under exemplary operation, each baseband-level capacity processor keeps track of the number of wireless devices to which its corresponding baseband processor is currently actively connected, the number of wireless devices that are connected but are otherwise inactive, and the number of connection tokens currently allocated to it.

Each component of the ACCS (baseband-level capacity processor, client-level capacity processor, server-level capacity processor, and master-level capacity processor) may perform a "look ahead" function to anticipate upcoming demand. In doing so, each component executes its own local look-ahead functionality appropriate in scope and time to its level of the system.

Further, in order to meet the stringent latency requirements of modern telecommunication standards, the responsiveness to requests for additional connections, and the time horizon of each look-ahead function, differs with each layer of the system. In other words, at the baseband processor level, responses to UE connection requests must be immediate and any additional allocation of connection tokens must be very agile. Conversely, transactions between the server-level capacity processor and master-level capacity processor levels may take place at a slower rate, for example, at <NUM> minute intervals. Accordingly, at the server-level capacity processor and master-level capacity processor levels, accuracy in prediction is very important, but latency is not a top consideration.

Given its current and/or anticipated demand for connections, each client-level capacity processor may place an allocation request with its corresponding server-level capacity processor for additional wireless capacity in the form of additional connection tokens. The server-level capacity processor may then respond to this request, and depending on logic implemented (including the status of its own allocation and its configured policy rules) within the server-level capacity processor, may allocate additional connection tokens from its active connection access pool. In doing so, the server-level capacity processor may take one of the following actions in response to a request for additional allocation: (<NUM>) grant the full allocation request, (<NUM>) grant a partial allocation request, or (<NUM>) reject the allocation request. In all cases, the server-level capacity processor will account for and report device connections to facilitate usage analysis. The client-level capacity processor then balances its allocation between its own active connection access pool and the baseband-level active connection allocations of its baseband-level capacity processors, and performs its own look-ahead function to anticipate future demand.

At designated intervals, and based on changing connection conditions, each client-level capacity processor may make requests for an additional active connection allocation from its server-level capacity processor. Similarly, over time, each client-level capacity processor may also release active connection tokens from its active connection reservation, thereby returning them to the active connection access pool of its corresponding server-level capacity processor. Through this process, the server-level capacity processor will account for the number of connection tokens granted to each of its client-level capacity processors, which it has allocated from its active connection access pool as well as any outstanding demand for connection tokens beyond the capacity of its connection access pool.

The master-level capacity processor orchestrates the allocation of connection tokens, based on its awareness of current and future demand throughout the wireless network (based on data reported upward from its client-level capacity processors and server-level capacity processors as well as its own internal look-ahead function) as well as policies configured into the master-level capacity processor. Further, the master-level capacity processor may instruct its client-level capacity processors (via its corresponding server-level capacity processors) to selectively terminate low-priority active connections to specific wireless devices.

The master-level capacity processor measures actual peak concurrent connections across many physical sites associated with the active connection access pools of its server-level capacity processors over time and identifies adjustments needed for each server-level capacity processor to accommodate the actual usage as it varies (up or down) over time. Each server-level capacity processor may perform similar analytics based on the reports it receives from its associated client-level capacity processors. Accordingly, the server-level capacity processors and client-level capacity processors may each have adaptive characteristics to optimize how connection tokens are requested and granted.

Further, through reporting mechanisms implemented by the client-level capacity processors and server-level capacity processors, whereby each reports upward its activity and events in which demand was in excess of its allocation, the master-level capacity processor maintains historical data regarding overages and shortages of connection tokens throughout the wireless network. Given this, the ACCS disclosed herein is a technical solution that enables a new business model for network operators, whereby a network operator only buys needed capacity from infrastructure providers or neutral hosts. As demand grows or diminishes, the network operator has the option of obtaining additional connection tokens. Further, the network infrastructure providers and neutral hosts can scale their deployed networks in response to demand, mitigating the problem of "stranded capacity" resulting from deploying over-engineered wireless base stations that are designed to meet peak demand that may only happen very rarely.

The ACCS supports flexible policy-defined access enforcement whereby different policies and actions can be programmatically applied when a new connection exceeds a given allocation. For example, a connection resulting in excess connections can be denied, or allowed and accounted for in order to facilitate post event actions such as billing for additional connections. Different enforcement actions can be assigned to different pools existing within one distributed wireless system.

<FIG> illustrates an exemplary Adaptive Connection Control System (ACCS) <NUM> integrated into a distributed wireless network. The wireless system includes a plurality of wireless base stations <NUM>, each of which may be coupled to a plurality of Distributed Antenna Systems (DAS) <NUM>, whereby each DAS <NUM> has a master unit <NUM> that communicates with wireless base station <NUM> via a fronthaul network <NUM>. Each master unit <NUM> may be connected to a plurality of remote units <NUM> over a distribution network <NUM>. Each of the remote units <NUM> may include a radio transceiver that is connected to at least one antenna <NUM> over one or more RF cables, through which it can communicate with in-range wireless devices <NUM>. Among the in-range wireless devices <NUM> are a plurality of active wireless devices <NUM>, a separate plurality of inactive wireless devices <NUM>, and a plurality of present wireless devices <NUM>.

Each wireless base station <NUM> has a plurality of baseband processors <NUM> that are coupled to the plurality of DAS master units <NUM> via interface <NUM>. Interface <NUM> may employ Common Public Radio Interface (CPRI) or a packetized digital protocol such as Internet Protocol (IP) for communication of digital baseband signals for both uplink and downlink. In an exemplary embodiment, each wireless base station <NUM> is an LTE eNodeB, and each of the plurality of baseband processors <NUM> implements the four protocol stack layers (PHY, MAC, RLC, and PDCP) for an individual band. It would be understood that the baseband processors <NUM> may be implemented in dedicated embedded hardware, or they may be implemented in software as virtual baseband processors. Wireless base station <NUM> further includes a backhaul bus <NUM> for communicating with a wireless provider terrestrial network <NUM> within an IP network <NUM>. In an exemplary LTE implementation, backhaul bus <NUM> is an S1 interface.

Elements of the wireless network from the antennas <NUM> through the wireless base station <NUM> may be collectively referred to as the Radio Access Network (RAN) <NUM>.

Typical operation of RAN <NUM> is as follows.

Uplink: One or more antennas <NUM> receives an RF electromagnetic signal from a given active wireless device <NUM>. The remote unit <NUM> receives the signal from antenna <NUM>, along with the entire RF environment within range of the antenna. Remote unit <NUM> performs the following functions: first, it amplifies the entire received RF signal for further processing; then it modulates the RF signal onto an optical signal that it then transmits over fiberoptic distribution bus <NUM>. DAS master unit <NUM> receives the RF modulated optical signal being transmitted over fiberoptic distribution bus <NUM> line, demodulates the optical signal to extract and isolate the different RF component signal bands; applies digital attenuation to each of the RF component signal bands; separately amplifies each of the RF component signal bands; performs RF downconversion on each of the RF component signal bands to convert them into analog baseband signals; digitizes each of the analog baseband signals, and then either packetizes the digitized baseband signals for transmission over a packet-based protocol such the Internet Protocol (IP) or serializes the data for transmission according to a Common Pubic Radio Interface (CPRI) protocol. It will be understood that other types of transmission are possible and within the scope of the invention. The DAS master unit <NUM> then transmits the digitized baseband signals to wireless base station <NUM> over fronthaul network <NUM>. Fronthaul network <NUM> may be implemented using Ethernet cabling, fiberoptic lines, or a wireless transmission medium.

Wireless base station <NUM> receives the uplink digital baseband signals and routes the band-specific data to its corresponding baseband processor <NUM>. As mentioned earlier, each baseband processor <NUM> processes the digitized baseband signals for each band by implementing the four LTE protocol stack layers (PHY, MAC, RLC, and PDCP) to produce user data and control data. Wireless base station <NUM> then transmits the resulting user and control data to the Evolved Packet Core (EPC) (not shown) in the wireless provider terrestrial network <NUM>.

Downlink: This is similar to uplink in reverse, but with a few differences. First, LTE specifies distinctions in modulation and processing between uplink and downlink, which will be understood to one with knowledge of LTE implementations. Second, master unit <NUM> and remote unit <NUM> process the downlink signals differently. For example, master unit <NUM> combines each of the band specific RF signals (from each of the baseband processors) into a single RF signal that it transmits by means of optical fiber to the remote units <NUM>. Further, remote unit <NUM> converts the optical signal into RF and amplifies the merged RF signals to power each antenna <NUM> connected to it. It would be readily understood that these differences do not alter the nature of the disclosed invention and need not be elaborated further.

Through these processes, RAN <NUM> may be connected to thousands of mobile devices. These connections may take one of three forms: active wireless devices <NUM> are in the LTE RRC Connected State and are sending and/or receiving user plane information; inactive wireless devices <NUM> are in the LTE RRC Connected State but are not currently sending or receiving user plane information; and present wireless devices <NUM> are in the LTE RRC Idle State, are located within the coverage area, but are not currently connected to wireless base station <NUM>.

Although exemplary wireless system is described with a DAS-based RAN, it will be readily understood that ACCS <NUM> may be integrated into any of a variety of wireless systems, including variations in which one or more wireless base stations <NUM> are directly coupled to one or more cellular macro antennas via conventional radio remote units, and may include a combination of DAS subsystems, macro cell base stations, and small cell base stations, and/or any additional wireless communications technologies.

Returning to <FIG>, ACCS <NUM> includes components that are integrated into a wireless system at various levels: a baseband-level capacity processor coupled to each baseband processor <NUM>; a client-level capacity processor <NUM> coupled to each baseband-level capacity processor within a given wireless base station <NUM>; a plurality of server-level capacity processors <NUM>, each of which is coupled to a distinct plurality of client-level capacity processors <NUM>; and a master-level capacity processor <NUM> coupled to each of the plurality of server-level capacity processors <NUM>.

Each wireless base station <NUM> includes a client-level capacity processor (ACCS Client) <NUM>. Client-level capacity processor <NUM>, as mentioned earlier, interacts with the baseband-level capacity processor within each baseband processors <NUM> to track wireless capacity usage and interact with server-level capacity processor <NUM>. Functions of the client-level capacity processor <NUM> is described in further detail below. As illustrated, each client-level capacity processor <NUM> is connected to server-level capacity processor <NUM> over connection <NUM>.

Elements of wireless system <NUM> are described in more detail below.

<FIG> illustrates further detail within wireless base station <NUM>. As illustrated, each baseband processor <NUM> has a protocol stack implementation <NUM>, which may be a software instantiation that implements the four protocol stack layers (PHY, MAC, RLC, and PDCP) for an individual band among the LTE bands used by wireless base station <NUM>. In this case, the software for protocol stack <NUM> may be encoded as instructions in a machine-readable memory within wireless base station <NUM> and executed on hardware therein. Baseband processor <NUM> further comprises baseband-level capacity processor <NUM>. Baseband-level capacity processor <NUM> has four software modules: connection measurement module <NUM>; configuration and policy module <NUM>; connection control module <NUM>, and look-ahead module <NUM>. Baseband-level capacity processor <NUM> communicates with client-level capacity processor <NUM> via API <NUM>.

Connection measurement module <NUM> executes instructions to determine the number of active wireless devices <NUM> and inactive wireless devices <NUM> among in-range wireless devices <NUM>. In-range wireless devices <NUM> may be in various communication states at any given time. For example, some of these devices may be idle or inactive, some may be actively transmitting information, the nature of the transmissions may be symmetrical or asymmetrical in terms of quantity of information or speed of transmission, etc. Connection measurement module <NUM> distinguishes between wireless communication devices that are "utilizing" capacity on the network, and those that are not, regardless of whether they are actively connected. To accomplish this, connection measurement module <NUM> identifies the communication state of each of the in-range wireless devices <NUM> served by wireless base station <NUM>.

The following is an exemplary logic by which connection measurement module <NUM> obtains the Radio Resource Control (RRC) state and the Enhanced-Radio Access Bearer (E-RAB) state for each device bearer represented in each baseband processor <NUM>. The RRC and E-RAB parameters are 3GPP KPIs and are identifiable and available to wireless base station <NUM> running a baseband processor <NUM>. Using the E-RAB parameter, connection measurement module <NUM> executes instructions to obtain the Tx/Rx buffer states and/or timer states for each corresponding device bearer. Using this information, it identifies a given device bearer as active or inactive using the following logic.

An active E-RAB per 3GPP TS32. <NUM> may be defined as follows:.

Connection measurement module <NUM> may have a range of memory allocated to it with which it populates a table of data corresponding to the states of each of the active wireless devices <NUM> and inactive wireless devices <NUM>, along with additional information corresponding to each active and inactive device pertaining to its type of connection.

<FIG> illustrates an exemplary process <NUM> executed by connection measurement module <NUM> in implementing the above logic table according to the disclosure. In step <NUM>, connection measurement module <NUM> executes instructions to extract the RRC and E-RAB states for each in-range wireless device <NUM>. With this information, connection measurement module <NUM> executes the remaining steps of process <NUM> for each in-range wireless device <NUM>.

In steps <NUM> and <NUM>, connection measurement module <NUM> examines the RRC state of the wireless device in question. If the RRC state is Idle, then there is no connection to that wireless device. If the state is Connected, then process <NUM> proceeds to step <NUM>, in which connection measurement module <NUM> examines the state of the E-RAB parameter of the wireless device. If the state indicates a Guaranteed Bit Rate QoS Class Identifier (GBR QCI), then connection measurement module <NUM> classifies this device as having an Active Connection (i.e., an active wireless device <NUM>). If, however, the E-RAB state indicates a non-Guaranteed Bit Rate QCI, then the device might be an Active Connection, but additional information is needed. In this case, process <NUM> proceeds to step <NUM>.

In step <NUM>, connection measurement module <NUM> executes instructions to determine if there is downlink data buffered for this device in the PDCP, RLC, or MAC sublayers of protocol stack <NUM>. If so, then the device is identified as an active wireless device <NUM>. If not, process <NUM> proceeds to step <NUM>, in which connection measurement module <NUM> determines if protocol stack <NUM> has received a non-zero buffer status from the given wireless device for any logical channel for an E-RAB with non-GBR QCI. If so, then the device is identified as an active wireless device <NUM>. If no, process <NUM> proceeds to step <NUM>, in which connection measurement module <NUM> determines whether the RLC reordering timer (t-Reordering, cf. 3GPP TS <NUM>) is running for the given wireless device. If so, then the device is identified as an active wireless device <NUM>. If not, then process <NUM> proceeds to step <NUM>.

In step <NUM>, connection measurement module <NUM> executes instructions to determine if Control Plane CIoT EPS (Cellular Internet of Things Evolved Packet System) optimizations are being used in connection with the given wireless device. This is to test if the given wireless device is an IoT UE that is transmitting data using the signaling radio bearer instead of the user data radio bearer. This mechanism may be used by IoT devices that transmit or receive infrequent and small data packets. However, this information alone is not sufficient, therefore process <NUM> includes a further step (step <NUM>) of determining if the give wireless device also has any data pending in any of its Signaling Radio Bearers (ERB). If both of these conditions are true, then the given wireless device is an IoT device that is an active wireless device <NUM>.

If none of the logic conditions of steps <NUM> - <NUM> are true, then the given wireless device is identified as having an Inactive Connection (i.e., an inactive wireless device <NUM>). Even though the given wireless device is "connected" (RRC being in the connected state), it is not, at the time of measurement, consuming resources of the wireless radio network <NUM>.

Returning to step <NUM>, if the E-RAB state for the given in-range wireless device <NUM> is such that there is no established E-RAB, then process <NUM> proceeds to step <NUM>, in which connection measurement module <NUM> executes similar instructions to those of step <NUM>. However, the logical result is different in that, if the given wireless device has no established E-RAB, but CIoT EPS optimization is being used, and (in step <NUM>) if there is data pending in any of the Signaling Radio Bearers (ERB), then the device is an IoT active wireless device <NUM>. Otherwise, the device is an IoT inactive wireless device <NUM>.

Accordingly, through process <NUM>, baseband-level capacity processor <NUM> may gain a much more substantive awareness of how many devices are occupying capacity on wireless network (using active connections), than would be possible if simply relying on the RRC and E-RAB KPIs. Further, connection measurement module <NUM> also takes into account devices that use network resources very infrequently and at low data volumes. This provides for a much more comprehensive awareness of the actual usage of network resources by a given baseband processor <NUM> at any given time.

One will recognize that the conditions tested in steps <NUM>, <NUM>, <NUM> are OR conditions (and further OR'ed with the AND combination of steps <NUM> and <NUM>), and that the specific order of steps <NUM> - <NUM> may be rearranged without deviating from the function of process <NUM>.

Also, although the RRC and E-RAB states are existing 3GPP KPIs corresponding to each wireless device and that this information is readily available as implemented the standard, this is not the case for all of the specific information required in each of steps <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. This information must be obtained by enhancing the protocol stack <NUM> to "instrument" the code so that this information may be made visible to an API <NUM> or a similar software-implemented mechanism to extract and buffer this information so that it is accessible to the executing software of connection measurement module <NUM>.

Connection measurement module <NUM> may be further configured to determine the types of connections for each of its active wireless devices <NUM> and inactive wireless devices <NUM>. Generally, there are wide ranging types of wireless communications devices with different capabilities and purposes. Common types include mobile phones, smart phones and tablets. Characteristics which vary widely include: speed and throughput, mobility or fixed operation, radio interface such as WiFi and LTE, etc. One example of device type differentiation is to use a device category (e.g., the LTE Device Category). Particularly with the advent and expected growth of the Internet of Things (IoT), the variances will be even more pronounced and new categories of devices are being introduced to address the wide ranging IoT use cases. Each of the various wireless communication device categories will impose a different usage load on the wireless communication system. By identifying the device category and anticipating the type of demands the device will impose on the wireless communication system, connection measurement module <NUM> may apply administrator-defined policy rules (stored in configuration and policy module <NUM> described below) to handle connection requests for various device categories, or combination of categories, that are accessing the network concurrently.

For example, the following table offers a simple illustration of LTE device categories and their supported peak data rates. ( http://www. org/keywords-acronyms/<NUM>-ue-category")
<IMG>.

Uplink physical layer parameter values set by the field UE-Category (<NUM> table <NUM>-<NUM>):
<IMG>.

In addition to the above device categories, ACCS <NUM> may also accommodate LTE Narrow Band (NB) and Cat-M IoT devices.

Connection measurement module <NUM> may store data corresponding to each active wireless device <NUM> and inactive wireless device <NUM> as follows. For each active wireless device <NUM>, it may store a device identifier, device category (Cat <NUM>-<NUM>, Cat-M, or NB), and the state of each bearer of the device (e.g., "bursty" or "continuous").

Another function of connection measurement module <NUM> is to report status to client-level capacity processor <NUM> via API <NUM>. It may do so periodically (e.g., once per measurement period) and/or in response to a request from client-level capacity processor <NUM> via API <NUM>. Reporting may include the following information as of most recent measurement: the number of active wireless devices <NUM> and the device category of each, and the number of inactive wireless devices <NUM> and the device category of each. , the number of connection requests from in-range wireless devices <NUM> that were granted by baseband-level capacity processor <NUM>, and the number of connection requests from in-range wireless devices <NUM> that were denied by baseband-level capacity processor <NUM>. The latter two figures may be the number since the previous reporting instance.

At each iteration of process <NUM>, connection measurement module <NUM> may track instances in which a given device that was previously identified as an active wireless device <NUM> now has an inactive connection and is thus now an inactive wireless device <NUM>, and vice versa. In the case of identifying a transition from active to inactive, connection measurement module <NUM> may increment the number of connection tokens in the baseband-level active connection allocation stored in configuration and policy module <NUM>, indicating that an active connection has become available. Conversely, if a given device and transitioned from inactive to active (i.e., transitioned from being an inactive wireless device <NUM> to an active wireless device <NUM>), connection measurement module <NUM> may decrement the number of connection tokens in the baseband-level active connection allocation. By doing this, the number of connection tokens in the baseband-level active connection allocation is regularly refreshed and updated.

Configuration and policy module <NUM> comprises a machine-readable memory that stores data pertaining to baseband-level capacity processor's <NUM> current allocation of connection tokens (i.e., its baseband-level active connection allocation), a flag indicating whether baseband-level capacity processor <NUM> is authorized to exceed its current allocation of connection tokens (i.e., "hard limit" vs. "soft limit"), and a value corresponding to the number of connections by which baseband-level capacity processor <NUM> may exceed its allocation in case of a soft limit (referred to herein as its overflow limit). In an example, configuration and policy module <NUM> may be implemented as a shared memory that can be accessed by connection measurement module <NUM>, connection control module <NUM>, and API <NUM> for read and write access.

Connection control module <NUM> performs the following functions: it receives requests for connections from various in-range wireless devices <NUM> seeking a connection to wireless base station <NUM>; it retrieves the current number of active wireless devices <NUM> from connection measurement module <NUM>; it retrieves the number of available connection tokens (i.e., its baseband level active connection allocation) from configuration and policy module <NUM>; it compares the number of current connection requests, with the current number of available connection tokens; and it grants or denies connection requests based on the result of the comparison. If the number of requests exceeds the number of available connection tokens, then connection control module <NUM> may poll configuration and policy module <NUM> to determine whether connection control module <NUM> is authorized to exceed its allocation of available connection tokens (hard or soft limit), and the overflow limit (in case of a soft limit), and grants or denies the requests accordingly. Further, connection control module <NUM> may discriminate in granting or denying connections based on the device category determined by connection measurement module <NUM>.

Connection control module <NUM> may periodically, or on request, report the following information to client-level capacity processor <NUM> via API <NUM>: the number of active wireless devices <NUM> and the device category of each; the number of inactive wireless devices <NUM> and the device category of each; the number of connection requests from in-range wireless devices <NUM> that were granted and their device categories; and the number of connection requests from in-range wireless devices <NUM> that were denied, and their device categories. The reporting may be numbers integrated since the previous report.

Baseband processor look-ahead module <NUM> performs the following functions: it stores results of each recent iteration of process <NUM> executed by connection measurement module <NUM>, along with a time stamp, to build a history of active connections and inactive connections of wireless devices to baseband processor <NUM>; it implements a machine learning algorithm to identify patterns of high and low demand; and extrapolates recent usage patterns (using the stored history data) to calculate near-term demand for connections, and particularly whether the current active connection allocation stored in configuration and policy module <NUM> is sufficient to meet the extrapolated demand. It may do this in a sliding time window fashion. It will be understood that, for all instances of machine learning implementation disclosed herein, various algorithms may be employed and that one skilled in the art could identify the type of algorithm that would be needed and how to implement it in the context of the disclosure.

Baseband processor look-ahead module <NUM> may comprise a sector of memory, originating from a non-volatile machine-readable memory, that is encoded with instructions to perform the functions listed above. In particular, it may include instructions for executing a machine learning algorithm, and a sector of volatile and/or non-volatile memory for buffering/storing historical data of previous iterations of process <NUM> executed by connection measurement module <NUM>.

<FIG> illustrates an exemplary baseband Initialization process <NUM> that would be executed by each baseband-level capacity processor <NUM> and client-level capacity processor <NUM> on system start. In step <NUM>, the processor(s) executing baseband processor <NUM> power up, and spawn and initialize each of the baseband processor <NUM> modules <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, illustrated in <FIG>. In step <NUM>, configuration and policy module <NUM> executes instructions to request its allocation from client-level capacity processor <NUM>, at which point client-level capacity processor <NUM> executes instructions to retrieve configuration data transmitted to it by server-level capacity processor <NUM>, which may include a pre-determined baseband-level active connection allocation for the given baseband-level capacity processor <NUM>.

In step <NUM>, client-level capacity processor <NUM> may perform its own client look-ahead function to determine if the baseband-level active connection allocation designated for baseband-level capacity processor <NUM> is sufficient. If not sufficient, client-level capacity processor <NUM> may execute instructions to supplement the designated baseband-level active connection allocation from its own connection reservation <NUM>. Further, in step <NUM>, client-level capacity processor <NUM> may further execute instructions to request additional allocation from server-level capacity processor <NUM>, and server-level capacity processor <NUM> may respond to the request in step <NUM>. In another variation, depending on the sequence of the startup process for the entire ACCS, client-level capacity processor <NUM> may not have been pre-configured by server-level capacity processor <NUM> with the designated baseband-level active connection allocations for baseband-level capacity processors <NUM>. In this case, when configuration and policy module <NUM> wakes up and requests its baseband-level active connection allocation from client-level capacity processor <NUM> in step <NUM>, client-level capacity processor <NUM> may not have a designated baseband-level active connection allocation for it stored in its memory, in which case client-level capacity processor <NUM> may have to relay the allocation request to server-level capacity processor <NUM>. Either way, server-level capacity processor responds to the request in step <NUM>.

In step <NUM>, client-level capacity processor <NUM> transmits the allocation of connection tokens (baseband-level active connection allocation) to the configuration and policy module <NUM> in baseband-level capacity processor <NUM>. This may also include configuration and policy settings, such as whether the allocation limit is a hard limit or a soft limit, and if it's a soft limit, the value of the overflow limit.

<FIG> illustrates an exemplary process <NUM> by which connection control module <NUM> may respond to a UE connection request. In step <NUM>, connection control module <NUM> receives a connection request from a UE. This may be done according to the LTE standard or via other communication technologies. In step <NUM>, connection control module <NUM> invokes connection measurement module <NUM> to execute process <NUM>, to determine the number of active connections, inactive connections, and their respective device categories. In step <NUM>, connection control module <NUM> may then retrieve the data products of process <NUM> (e.g., the number of active wireless device <NUM> and inactive wireless devices <NUM>, as well as their respective device categories), and retrieve the number of connection tokens corresponding to the allocation stored in configuration and policy module <NUM>. Running process <NUM> in response to a UE request has the effect of updating (or refreshing) the current state of device connections and updating the current count of connection tokens in the allocation stored in configuration and policy module <NUM>. With this done, the number of available connection tokens accurately reflects the current capacity usage of baseband processor <NUM>, and how many more connections may be made before exceeding its limit.

Given this information, in step <NUM>, connection control module <NUM> executes instructions to determine whether granting the connection request will exceed the limit determined by the current number of connection tokens (or baseband-level active connection allocation). This may be a simple as determining if there is at least one remaining connection token in the allocation, or it may involve determining the device category of the requesting device and comparing this to a look-up table stored in configuration and policy module <NUM> that lists connection priority by device category. If there is an available connection token in the allocation, connection control module <NUM> may proceed via the "no" branch of step <NUM> to step <NUM> in which connection control module <NUM> grants the connection request, and in step <NUM>, decrements the number of connection tokens in the allocation.

If, however, there are no more connection tokens in the baseband-level active connection allocation, connection control module <NUM> may then proceed to step <NUM> to query configuration and policy module <NUM> to determine if this is a hard limit or a soft limit. If the former, then connection control module <NUM> may not exceed the current limit and proceeds to step <NUM> in which it denies the connection request. Alternatively, if the limit is a soft limit, then connection control module <NUM> is pre-authorized to exceed its baseband-level active connection allocation and proceeds to step <NUM>, in which it determines if granting the current UE connection request would result in connection control module <NUM> exceeding its overflow limit. If so, then connection control module <NUM> proceeds to step <NUM> in which it denies the connection request. Otherwise, if granting the connection request will not exceed the overflow limit, then connection control module <NUM> proceeds to step <NUM> and <NUM> as described above.

In step <NUM>, connection control module <NUM> executes instructions to update its status and may transmit its status to client-level capacity processor <NUM> in the form of a transaction report. Alternatively, connection control module <NUM> may store the transaction record for each iteration of process <NUM> and report the statistics of the accumulated iterations to client-level capacity processor <NUM> in a periodic manner.

<FIG> illustrates a periodic update process <NUM> executed by connection control module <NUM>. This process is not done in response to a UE request and may be performed at a predefined interval, for example, every <NUM> minutes. Additionally, or alternatively, connection control module <NUM> may execute process <NUM> in response to a command from client-level capacity processor <NUM>.

In step <NUM>, connection control module <NUM> invokes connection measurement module <NUM> to execute process <NUM>, and in step <NUM> it invokes the same module to check availability. Steps <NUM> and <NUM> may be the done in the same manner as steps <NUM> and <NUM> of process <NUM>, which is done in response to UE connection request.

In step <NUM>, baseband processor look-ahead module <NUM> executes instructions to estimate near-term upcoming demand for connections, as described above. In particular, look-ahead module <NUM> provides an estimate of the probability that connection demand will exceed the baseband-level active connection allocation between the time of execution of process <NUM> and the next, subsequent iteration of process <NUM>.

In step <NUM>, connection control module <NUM> executes instructions to retrieve the results of steps <NUM>-<NUM> and compare the estimated demand for connections to the baseband-level active connection allocation stored in configuration and policy module <NUM>. If the demand is estimated to exceed the allocation, process <NUM> proceeds to step <NUM>, in which connection control module <NUM> computes (from the results of steps <NUM>-<NUM>) the number of additional connection tokens needed to meet anticipated demand, and requests for the additional allocation of connection tokens from client-level capacity processor <NUM> in step <NUM>.

Alternatively, if the estimated demand does not exceed the baseband-level active connection allocation, then process <NUM> proceeds to step <NUM>, in which connection control module <NUM> determines if the baseband-level active connection allocation has a surplus of connection tokens. Configuration and policy module <NUM> may store a parameter that is a connection token surplus threshold. This threshold is a number that, if the available connection tokens exceeds its value, then the connection tokens exceeding this number may be released to client-level capacity processor <NUM>. If the number of available connection tokens exceeds the surplus threshold, then process <NUM> may proceed to step <NUM>, in which connection control module <NUM> may release the surplus connection tokens via API <NUM> to client-level capacity processor <NUM>. It may do so by decrementing its allocation and transmitting to client-level capacity processor <NUM> the number corresponding to its decremented allocation, thereby "transferring" the connection tokens up to the client-level capacity processor <NUM>.

Further to step <NUM>, if the estimated number of connection tokens does not exceed the surplus threshold, then process <NUM> proceeds to step <NUM>.

Accordingly, connection control module <NUM> determines if the baseband processor is over-burdened (its baseband-level active connection allocation is insufficient and thus more connection tokens are needed), or under-burdened (its baseband-level active connection allocation has a surplus of connection tokens).

In step <NUM>, connection control module <NUM> updates its statistics and estimates, stores it in its local memory, and transmits the updates in the form of a report to client-level capacity processor <NUM>.

In an exemplary embodiment, connection control module <NUM> executes process <NUM> once every <NUM> minutes. However, one skilled in the art will readily recognize that longer periods between iterations will likely encompass a larger sample set of statistics on UE connection requests, but may suffer from reduced fidelity of look-ahead estimation.

Each Wireless Base Station <NUM> has a client-level capacity processor <NUM>, which may be implemented in dedicated embedded hardware or may be instantiated in software executed on computing infrastructure within - or associated with - wireless base station <NUM>. In either case, the software for client-level capacity processor <NUM> would be encoded as machine instructions in a non-volatile computer-readable medium, which may be embedded within wireless base station <NUM> or at a remote site within IP network <NUM>. Client-level capacity processor <NUM> has, or has allocated to it, a section of memory on which its active connection reservation <NUM> is stored. Client-level capacity processor <NUM> communicates with server-level capacity processor <NUM> over connection <NUM>, which may be integrated within backhaul bus <NUM> or may be a separate dedicated connection.

Client-level capacity processor <NUM> performs the following functions: it interacts with each baseband-level capacity processor <NUM>, via API <NUM>, to obtain and derive information about current connections; it maintains history data regarding past connections, including a time record of connection token allocations to each baseband-level capacity processor <NUM>, data regarding times in which demand for connections exceeded the baseband-level active connection allocations of each baseband-level capacity processor <NUM>, data regarding each time a baseband-level capacity processor <NUM> requested additional connection tokens, and data regarding each time a baseband-level capacity processor <NUM> released surplus connection tokens; it performs a look-ahead function to determine upcoming need across its baseband processors <NUM> based on current connections and history; it maintains an active connection reservation <NUM> of connection tokens; it makes requests to server-level capacity processor <NUM> for additional connection tokens as needed; it releases surplus connection tokens to server-level capacity processor <NUM>; and it reports current and historical data to server-level capacity processor <NUM>.

As illustrated in <FIG> and <FIG>, client-level capacity processor <NUM> maintains an active connection reservation <NUM>. Active connection reservation <NUM> may comprise a section of memory allocated to client-level capacity processor <NUM>, in which it maintains a reserve of connection tokens. Server-level capacity processor <NUM> provides the active connection reservation <NUM> with its connection tokens, either directly, or in response to a request from the client-level capacity processor <NUM>. Client-level capacity processor <NUM> may also have dedicated memory for storing history data of its interactions with, and reporting from, its baseband-level capacity processors <NUM> via API <NUM>, with which it performs its look-ahead function, and from which it reports to server-level capacity processor <NUM>.

<FIG> illustrates an exemplary process <NUM> by which client-level capacity processor <NUM> responds to requests from each baseband-level capacity processor <NUM> to dynamically provide wireless capacity (in the form of connection tokens) for connections to the in-range wireless devices <NUM> in the vicinity of wireless base station <NUM>. Process <NUM> may be executed in a loop, or at a prescribed interval (e.g., every <NUM> minutes), or in response to certain events such as prompting by server-level capacity processor <NUM> or an incoming allocation request from a baseband-level capacity processor <NUM>. Client-level capacity processor <NUM> performs process <NUM> by executing machine readable instructions that are stored in non-volatile memory embedded within wireless base station <NUM> or at a remote site in IP network <NUM>.

In step <NUM>, client-level capacity processor <NUM> executes instructions to retrieve all of the requests for additional active connection allocations received from its baseband-level capacity processors <NUM> (as executed by each baseband-level capacity processor <NUM> in step <NUM> of process <NUM>) since the last time client-level capacity processor <NUM> executed process <NUM>. In step <NUM> client-level capacity processor aggregates the number of requested connection tokens from each baseband-level capacity processor <NUM> and compares it to its own allocation in its active connection reservation <NUM>.

In step <NUM>, client-level capacity processor <NUM> performs its own look-ahead function to extrapolate the demand for additional active connection allocation (in the form of connection tokens) from its baseband-level capacity processors <NUM> between the current time and the next time process <NUM> will be executed. In doing so, client-level capacity processor <NUM> may execute instructions implementing a machine learning algorithm that looks at the history of additional active connection allocation requests (and surplus connection token releases) from each of its baseband-level capacity processors <NUM>. This may differ from the look-ahead function performed by the baseband-level capacity processors <NUM> in the following ways: <NUM>) it aggregates the demand patterns across all of its baseband-level capacity processors <NUM> to assure that it can meet demand across all of them; <NUM>) extrapolates the demand for additional allocation that is integrated across all of its baseband-level capacity processors <NUM> (in other words, some baseband-level capacity processors <NUM> may see a spike in demand when others may be releasing surplus connection tokens); <NUM>) it identifies cross-correlation patterns between baseband-level capacity processors <NUM> and thus has a more global view of demand patters and may thus provide a more accurate extrapolation than at the baseband-level capacity processor <NUM> level; and <NUM>) it can buffer released connection tokens in its connection reservation <NUM> in anticipation of extrapolated demand increases from other baseband-level capacity processors <NUM>.

In step <NUM>, client-level capacity processor <NUM> combines the currently available connection token allocation in its connection reservation <NUM> with the extrapolated demand computed in step <NUM> and determines whether the combined demand will exceed the limit imposed by its allocation in connection reservation <NUM>. If not, client-level capacity processor <NUM> may proceed to step <NUM> in which it grants the allocation requests from each baseband-level capacity processor <NUM> and transmits, via API <NUM>, corresponding connection tokens to each of the configuration and policy modules <NUM> in its baseband-level capacity processors <NUM>.

If extrapolated demand does exceed the connection token allocation in active connection reservation <NUM>, then client-level capacity processor <NUM> may proceed to step <NUM> in which it determines if this is a hard or a soft limit. This information may take the form of a parameter stored in client-level capacity processor <NUM> memory and would have been set by server-level capacity processor <NUM>. If it is a soft limit, process <NUM> proceeds to step <NUM>, in which client-level capacity processor <NUM> determines whether providing the requested connection tokens will exceed its overflow limit. If not, then the process proceeds to steps <NUM> and <NUM> as described above. If it does exceed the overflow limit, then process <NUM> proceeds to step <NUM> in which client-level capacity processor <NUM> requests additional connection tokens from server-level capacity processor <NUM>.

In step <NUM>, client-level capacity processor receives a response from server-level capacity processor, which may be a complete grant of the request issued in step <NUM>, a partial grant, or a denial of the request. If the response is a complete or partial grant of the request, then client-level capacity processor <NUM> may proceed to step <NUM> as described above and allocate connection tokens to the appropriate baseband-level capacity processors <NUM>. If the response is a denial, then client-level capacity processor <NUM> proceeds to step <NUM>.

In step <NUM>, client-level capacity processor <NUM> updates its status, including its own active connection reservation <NUM>, and may report its status (along with the status reports of each of its baseband-level capacity processors <NUM>) to server-level capacity processor <NUM>.

NOTE: process <NUM> described above may be enhanced to factor in device category. In this case, each baseband-level capacity processor <NUM> may have requested a specific number of connection tokens for a specific set of device categories, and client-level capacity processor <NUM> may check availability and perform its look-head function on a device category by device category basis. Accordingly, connection tokens may be requested and transmitted in the form of a vector, with each basis being a device category.

Client-level capacity processor <NUM> interacts with server-level capacity processor <NUM> in the following ways: it issues requests to server-level capacity processor <NUM> for additional active connection token allocations; it receives connection tokens from server-level capacity processor <NUM>, either in response to a request or directly from server-level capacity processor <NUM> based on analysis it has performed; it releases surplus connection tokens from active connection reservation <NUM>; and it reports status and history (e.g., current status as well as history since last report) to the server-level capacity processor <NUM>.

Referring to <FIG>, server-level capacity processor <NUM> (also referred to as ACCS Server) is connected to a plurality of client-level capacity processors <NUM> and has an active connection access pool <NUM> for storing its allocation of connection tokens. Server-level capacity processor <NUM> may be instantiated in IP network <NUM> as a cloud application, or it may be deployed within the wireless provider terrestrial network <NUM>, where it may run on dedicated hardware and be stored in executable instructions encoded in non-volatile memory. Active connection access pool <NUM> may be a sector of memory allocated to server-level capacity processor <NUM>, with which server-level capacity processor <NUM> stores connection tokens that it may allocate to each of its client-level capacity processors <NUM>. Active connection access pool <NUM> may store the connection tokens as a simple count of active connections allocated to each client-level capacity processor <NUM>, or it may be a logical representation of the allocated connection tokens. Active connection access pool <NUM> may be implemented in a similar fashion to active connection reservation <NUM>, or may be implemented differently given its position in the system hierarchy of ACCS <NUM>.

Server-level capacity processor <NUM> performs the following functions: it receives requests from each client-level capacity processor <NUM> for an additional allocation of connection tokens; it performs analytics to decide whether to deny, partially grant, or fully grant requests from each client-level capacity processor <NUM> and grants or denies accordingly; it receives reports from each client-level capacity processor <NUM> regarding the status reported in step <NUM> of process <NUM>; it performs analytics on the historical data reported from each client-level capacity processor <NUM> to determine how to adaptively or proactively distribute connection tokens to its client-level capacity processors <NUM>, and whether to request additional connection tokens from master-level capacity processor <NUM> (and how many to request); it requests additional connection tokens from master-level capacity processor <NUM>; it determines whether it has a surplus of connection tokens, and if so, how many; and it releases connection tokens to master-level capacity processor <NUM> if it identifies a surplus.

<FIG> illustrates and exemplary process <NUM> by which server-level capacity processor <NUM> may adaptively allocate connection tokens to its client-level capacity processors <NUM> as well as interact with master-level capacity processor <NUM>. It will be appreciated that variations in sequence of steps in process <NUM> are possible and within the scope of the disclosure.

In step <NUM>, server-level capacity processor <NUM> executes instructions to retrieve historical data from its client-level capacity processors <NUM>, which would include the most recent information reported in step <NUM> of process <NUM> by each. This may include server-level capacity processor <NUM> querying a shared memory between it and client-level capacity processors <NUM>, or by other known methods for inter-task data communication.

In step <NUM>, server-level capacity processor <NUM> executes instructions to perform analytics on the historical data to determine trends and anticipate near-future changes in usage of connection tokens. In doing so, server-level capacity processor <NUM> computes if the current number of connection tokens in connection access pool <NUM> is sufficient, and if an increase in demand is anticipated, including when and how many connection tokens will be needed, and of which device category or other form of device type. Analytics as described here may include executing a machine learning algorithm similar to the look-ahead algorithms implemented at the baseband processor level and the client-level capacity processor level. The difference here is that at the level of the server-level capacity processor <NUM>, the look-ahead will include a broader data set comprising data from multiple client-level capacity processors <NUM> (and their respective baseband-level capacity processors <NUM>) dispersed over a broader geographic area. Further, given the broader data set, it is likely that surges in demand for additional connection tokens, and instances of surplus connection token releases (from the client-level capacity processors <NUM>) may somewhat integrate out over the broad distribution of client-level capacity processors <NUM>. Accordingly, server-level capacity processor <NUM> may maintain its connection reserve pool <NUM> so that it is sufficiently deep to substantially even out these surges.

Server-level capacity processor <NUM> may, given its perspective in the wireless network in which ACCS <NUM> is deployed, be able to identify geographic and temporal demand patterns on a broader geographic scale, e.g., over the multiple city blocks and over the course of months. As such, unlike the look-ahead function performed by baseband-level capacity processor <NUM>, which may be done over a shorter duration sliding window and at a tactical level, the look-ahead function performed by server-level capacity processor <NUM> may be done at the strategic level.

In steps <NUM> and <NUM>, server-level capacity processor <NUM> queries its connection access pool <NUM> to determine, given the results of step <NUM>, if it has sufficient connection tokens to provide for current and near-term foreseeable demand from its client-level capacity processors <NUM>. This may include an assessment of device category. For example, connection reserve pool <NUM> may have a sufficient number of low-demand connection tokens (e.g., corresponding to device categories Cat <NUM> or Cat <NUM> vs. Cat <NUM>) but not enough high demand connection tokens. If not, in step <NUM>, server-level capacity processor <NUM> issues a request to master-level capacity processor <NUM> for additional connection tokens, which may include specific device categories.

In step <NUM>, if master-level capacity processor <NUM> grants the request in step <NUM>, fully or in part, server-level capacity processor <NUM> receives up to the requested number of connection tokens, at which stage server-level capacity processor <NUM> updates its connection access pool <NUM> accordingly in step <NUM>.

Returning to step <NUM>, if server-level capacity processor <NUM> determines that it has a sufficient number of connection tokens, as determined in step <NUM>, then server-level capacity processor <NUM> determines if it has a surplus number of connection tokens in its active connection access pool <NUM>. In doing so, server-level capacity processor <NUM> proceeds to step <NUM> and executes instructions to retrieve a configuration parameter corresponding to a surplus threshold value as dictated by policy set by master-level capacity processor <NUM>. Server-level capacity processor <NUM> then compares this surplus threshold to the results of step <NUM>. If the number of connection tokens determined in step <NUM> exceeds the surplus threshold, then server-level capacity processor <NUM> proceeds to step <NUM> where it computes the number of connection tokens to be released, and then in step <NUM>, releases the surplus connection tokens to master-level capacity processor <NUM>. With step <NUM> completed, server-level capacity processor <NUM> updates the number of connection tokens in its active connection access pool <NUM> in step <NUM>. However, in step <NUM>, if server-level capacity processor <NUM> determines that it does not have an excess number of connection tokens (i.e., a number exceeding the surplus threshold), then it proceeds to step <NUM>.

In step <NUM>, server-level capacity processor <NUM> receives a request from a client-level capacity processor <NUM> for additional active connection allocation, in the form of additional connection tokens. It will be apparent that step <NUM> is an independent event from the above-described steps of process <NUM> and may occur at any time during the process, and that server-level capacity processor <NUM> may respond to this request in an interrupt fashion (suspending its current state in process <NUM> to service the request), or it may continue is its execution of process <NUM> until it is ready to respond to the request. Either way, once server-level capacity processor <NUM> receives the request from a client-level capacity processor <NUM>, it executes instructions in step <NUM> to query its active connection access pool <NUM> to determine if it has a sufficient number of connection tokens to grant the request.

In step <NUM>, server-level capacity processor <NUM> decides whether to either deny the request, grant the request in full, or grant the request in part. Server-level capacity processor <NUM> compares the nature of the request (e.g., requested number of connection tokens and device category for each) to its active connection access pool <NUM> to see if there are sufficient connection tokens to service the request. The sub-process performed in step <NUM> may be substantially similar to steps <NUM>-<NUM> described above. If there are sufficient connection tokens to at least partially grant the request, then process <NUM> proceeds to step <NUM>.

In step <NUM>, server-level capacity processor <NUM> updates its status, including any revised status of its active connection reserve pool <NUM>, store the updates in its memory, and report the new status to master-level capacity processor <NUM>. In addition to reporting its own internally-generated information, server-level capacity processor <NUM> may also relay reports generated by each of its client-level capacity processors <NUM> and reported in step <NUM> of process <NUM>.

Server-level capacity processor <NUM> may interact with master-level capacity processor <NUM> in the following ways: it receives data from master-level capacity processor <NUM> regarding configuration and policy, both for itself and for it to relay to client-level capacity processors <NUM>; it makes request to master-level capacity processor <NUM> for additional connection tokens; it releases surplus connection tokens to master-level capacity processor <NUM>; and it provides reports to master-level capacity processor <NUM>, both its own internally-generated report as well as relaying reports from client-level capacity processors <NUM>.

Variations to process <NUM> are possible and within the scope of the disclosure. For example, process <NUM> may be executed in a single loop solely in response to an allocation request from one or more client-level capacity processors <NUM>. In this case, the process would operate similarly to process <NUM> executed by the client-level capacity processors <NUM>. In this case, process <NUM> may include the analytics and other functions performed in steps <NUM>-<NUM> may be executed in place of step <NUM>.

Referring again to <FIG>, master-level capacity processor <NUM> (also referred to as ACCS Master) is coupled to a plurality of server-level capacity processors <NUM> and has a master active connection access pool <NUM>. Master-level capacity processor <NUM> may be instantiated in IP network <NUM> as a cloud application, or it may be deployed within wireless provider terrestrial network <NUM> where it may run on dedicated hardware and be stored in executable instructions encoded in non-volatile memory. Master active connection access pool <NUM> may be a sector of memory allocated to master-level capacity processor <NUM>, with which master-level capacity processor <NUM> stores connection tokens that amount to the total number of connection tokens obtained by the wireless provider and may include reserve connection tokens that have not been allocated to the server-level capacity processors <NUM>. In other words, the master active connection access pool <NUM> represents the total number of connection tokens that are available to the wireless provider, and which the master-level capacity processor <NUM> may allocate adaptively to each of its wireless base stations <NUM> via the server-level capacity processors <NUM> and client-level capacity processors <NUM>. It is from master access pool <NUM> that master-level capacity processor <NUM> draws connection tokens for allocating to each of its server-level capacity processors <NUM>.

Master-level capacity processor <NUM> performs the following functions: it receives requests from each of its server-level capacity processors <NUM> for additional active connection allocation in the form of connection tokens; it performs analytics to decide whether to deny, partially grant, or fully grant requests from each server-level capacity processor <NUM> and grants or denies accordingly; it receives reports from each of its server-level capacity processors <NUM>, reported in step <NUM> of process <NUM>, which it uses in performing the analytics; it dynamically allocates connection tokens among its server-level capacity processors <NUM> based on the results of the analytics it performs; it generates reports on patterns of occurrences in which each client-level capacity processor <NUM> exceeded its allocation, including whether requests or connection tokens were partially or fully denied due to the client-level capacity processor <NUM> exceeding its overflow limit. Master-level capacity processor <NUM> may perform each of these functions as a function of device category.

<FIG> illustrates an exemplary process <NUM> by which master-level capacity processor <NUM> may adaptively allocate connection tokens to each of its server-level capacity processors <NUM>, as well as determine whether the current number of connection tokens in its master active connection access pool <NUM> is insufficient, sufficient, or too high.

In step <NUM>, master-level capacity processor <NUM> executes instructions to retrieve reports provided by server-level capacity processors <NUM> in step <NUM> of process <NUM>. These reports may be those that were received since the previous iteration of process <NUM>. These reports may include reports generated by each server-level capacity processor's client-level capacity processors <NUM> in step <NUM> or process <NUM>, or information that each server-level capacity processor <NUM> has synthesized from those lower reports. Alternatively, master-level capacity processor <NUM> may execute instructions to retrieve from its allocated memory select information from each of the reports that have already been received and stored in its memory.

In step <NUM>, master-level capacity processor <NUM> executes instructions to perform analytics on the current, recent, and historical use of connection tokens by the wireless system in which the ACCS <NUM> is deployed. In doing so, master-level capacity processor <NUM> may maintain a table or buffer of data corresponding to the allocations made to each server-level capacity processor <NUM> and client-level capacity processor <NUM> to quantify the number of connection tokens (and potentially the device categories corresponding to each connection token) allocated to each at any given time, identify which of the client-level capacity processors exceeded their respective overflow limit during that time, and decide if more connection tokens are needed for the master access pool <NUM>.

<FIG> illustrates a timeline demonstrating process <NUM> being executed over time. For the purposes of explaining step <NUM>, the discussion will focus on the first time period <NUM>. As stated above, in step <NUM>, master-level capacity processor <NUM> executes instructions to sum the allocations to each server-level capacity processor <NUM> (to their respective active connection access pools <NUM>) for each day within the time period, wherein each server-level capacity processor <NUM>'s allocation may be illustrated as a different shade in a given day's allocation <NUM>. Accordingly, each day's allocation <NUM> may represent the partitioning of the master active connection access pool <NUM>, representing how many connection tokens were allocated to each server-level capacity processor <NUM>. Additionally, each shade band in each day's allocation <NUM> may also include the total requests made by each server-level capacity processor <NUM> above its allocation. The total number of connection tokens in the master active connection access pool <NUM> may be represented by limit line <NUM>. Additionally, master-level capacity processor <NUM> may include not only report data from each server-level capacity processor <NUM>, but may also include information regarding one or more client-level capacity processors <NUM>, if those particular clients were experiencing an inordinate amount of demand at any given time.

One will appreciate that the use of four week time periods <NUM>, and quantizing usage by daily allocations <NUM>, are exemplary and that other time divisions and time periods are possible and within the scope of the disclosure.

Returning to <FIG>, further to step <NUM>, master-level capacity processor <NUM> may identify the instances in which the number of requested connection tokens exceeded the number in the master active connection access pool <NUM> (represented by limit line <NUM>). Each instance is referred to herein as an overage <NUM>. In this case, as illustrated, master-level capacity processor <NUM> may have executed instructions to exceed the overflow limit corresponding to the master active connection access pool <NUM> in response to overage <NUM>. This information may include the device types and/or device categories corresponding to the overage <NUM>.

In step <NUM>, master-level capacity processor <NUM> executes instructions to adjust the policies of each server-level capacity processor <NUM> and optionally each client-level capacity processor <NUM>. An example of this is to increase or decrease the overflow limit (or set the hard/soft limit parameter) corresponding to each, depending on overages <NUM> observed during the most recent time period <NUM>, or across multiple such time periods. Another example of adjusting policy is to provide a preferential overflow limit depending on device category.

Further to step <NUM>, master-level capacity processor <NUM> may execute instructions to determine whether its current master active connection access pool <NUM> is sufficient to meet the aggregate demand experienced in the most recent time period <NUM>, or if it has excess capacity to meet the demand. In doing so, master-level capacity processor <NUM> may have an upper and lower configurable threshold of the number of overages <NUM> during a given time period. If the number of overages <NUM> exceeds the upper threshold, master-level capacity processor <NUM> may transmit a notification to the network operator customer indicating that additional connection tokens are needed. This may provide the network operator the option of purchasing additional connection tokens for its master active connection access pool <NUM>. Alternatively, if the number of overages <NUM> is below the lower threshold, master-level capacity processor may transmit a notification to the network operator indicating that it has an excess of connection tokens and provide the option of buying back (or getting a rebate) on a certain number of connection tokens in its master active connection access pool <NUM>. In doing so, master-level capacity processor <NUM> may execute instructions to calculate the number of connection tokens necessary to purchase or return to get the estimated number of overages <NUM> to be between the upper and lower thresholds. This process may include consideration of the device categories corresponding to the connection tokens, whether they are lacking or in excess.

In step <NUM>, master-level capacity processor <NUM> executes instructions to transmit the revised policies to server-level capacity processors <NUM>, which may include transmitting further policies directly to client-level capacity processors <NUM>. Alternatively, the server-level capacity processors <NUM> may interpret or derive policies for each of its client-level capacity processors <NUM>, based on its respective policy from master-level capacity processor <NUM>.

In step <NUM>, given the number of server-level capacity processors <NUM> that requested for additional connection tokens beyond their own allocations, as stored in their respective active connection reserve pools <NUM>, master-level capacity processor <NUM> may reallocate connection tokens by repartitioning its master active connection access pool <NUM> from those server-level capacity processors <NUM> that appear have reserve connection tokens in their respective active connection access pools <NUM>. This may be graphically depicted in <FIG> as a change in proportion of each shade band within the day's allocation <NUM>. In doing so, master-level capacity processor <NUM> may execute instructions to simply redistribute connection tokens by increasing or decreasing (or by transmitting or retrieving) connection tokens to/from the active connection access pools <NUM> of each of its server-level capacity processors <NUM>. Alternatively, master-level capacity processor <NUM> may further redistribute connection tokens at the client-level capacity processor <NUM> level by increasing or decreasing (or, again, by transmitting or retrieving) connection tokens to/from the active connection reservation <NUM> of each client-level capacity processor <NUM>, or directly to the configuration and policy module <NUM> of each baseband processor <NUM> via API <NUM>.

Steps <NUM>-<NUM> and <NUM> may be seen as a subprocess of process <NUM>. These steps may be executed in a loop, at a regular interval, or in response to a signal from outside ACCS <NUM>, e.g., from a user interface (not shown). Further, steps <NUM>-<NUM> may be seen as a separate subprocess, which may be executed at any time in response to a request from a server-level capacity processor <NUM>. This subprocess is described below.

In step <NUM>, master-level capacity processor <NUM> receives a request from one or more of its server-level capacity processors <NUM>, according to step <NUM> of process <NUM>. By issuing the request, server-level capacity processor <NUM> is asking or an increase in its allocation from the master active connection access pool <NUM>. In response, in step <NUM>, master-level capacity processor <NUM> executes instructions to determine whether there are enough connection tokens (and in corresponding device type or device category if applicable) by retrieving the relevant data from its master active connection access pool <NUM>. If there are enough connection tokens in master active connection access pool <NUM>, then master-level capacity processor <NUM> may proceed to step <NUM>, in which it transmits the requested connection tokens to the requesting server-level capacity processor <NUM>.

If there are not enough connection tokens in master active connection access pool <NUM>, it may be because there are no connection tokens available, or there are connection tokens available but not enough to satisfy the requested number. In the former case, master-level capacity processor <NUM> proceeds to step <NUM>. In the latter case, master-level capacity processor <NUM> may partially grant the request and proceed to step <NUM> to transmit the connection tokens that are available, and additionally proceed to step <NUM> with respect to the remaining connection tokens requested beyond the capacity of the master active connection access pool <NUM>.

In step <NUM>, master-level capacity processor executes instructions to determine if the requested connection tokens (or remaining requested connection tokens) are greater than its configured overflow limit. If not, then master-level capacity processor <NUM> may proceed to step <NUM> in which it transmits the requested connection tokens to the requesting server-level capacity processor <NUM>. Otherwise, if fulfilling the request will exceed the overflow limit, then master-level capacity processor <NUM> proceed to step <NUM>.

In step <NUM>, master-level capacity processor <NUM> may retrieve information regarding its configured policy to determine if it may proceed, issue the requested connection tokens, and log the overflow event in its memory for subsequent analytics processing in step <NUM>. The configured policy may set a limit to the number of times the overflow limit may be exceeded in one time period <NUM>. If master-level capacity processor <NUM> determines that it has permission to exceed its overflow limit, it then proceeds to step <NUM> and transmits the requested connection tokens. Otherwise, it proceeds to step <NUM>, denies the request. In either case, master-level capacity processor <NUM> may log the event in its memory for subsequent processing of analytics in step <NUM>.

Further, in the example illustrated, master-level capacity processor <NUM> sums the allocation for each day over a four week time period to identify days in which the requests from server-level capacity processors <NUM>, may have exceeded the total overflow limit of the master active connection access pool <NUM>.

One will understand that variations to the above disclosure are possible and within the scope of the invention. For example, baseband processors <NUM>, instead of being deployed in hardware on board wireless base station <NUM>, may be implemented as virtual baseband processor that may be instantiated in IP network <NUM>. In this case, baseband-level capacity processor <NUM> (and its components connection measurement module <NUM>, configuration and policy module <NUM>, connection control module <NUM>), and API <NUM> may also be implemented as virtualized software components that are instantiated and executed in conjunction with virtual baseband processor <NUM>. The same may be true for client-level capacity processor <NUM>, in which case its connection reservation <NUM> may be stored in dedicated memory in IP network <NUM>.

Also, it will be understood that variations to the partitioning of software modules described above are possible and within the scope of the disclosure.

Further, process <NUM> may be executed in a single loop whereby the master-level capacity processor <NUM> begins process <NUM> at step <NUM>, in which it retrieves requests from its server-level capacity processors <NUM>. Alternatively, the starting step of a single loop implementation of process <NUM> may be step <NUM>, in which case step <NUM> would be executed after completion of step <NUM>. In an additional possible variation, in step <NUM>, master-level capacity processor <NUM> may receive requests in real-time from each server-level capacity processor <NUM>. In this interrupt-driven approach, process <NUM> may be divided into two sub-processes: steps <NUM>-<NUM> and <NUM> as a background task, and steps <NUM>-<NUM> as an interrupt-driven task.

In addition to the above variation, ACCS System <NUM> may include additional layers of server-level capacity processors <NUM>. In this case, ACCS System <NUM> may be a multi-tiered implementation whereby the structures and functions described above will involve additional layers of configuring policies, requesting connection tokens, and reporting, and other functions.

Claim 1:
A system (<NUM>) for allocating capacity in a wireless communication network, the system comprising:
a plurality of baseband-level capacity processors (<NUM>), each coupled to a corresponding baseband processor (<NUM>), wherein each of the plurality of baseband-level capacity processors is adapted to determine a number of actively connected wireless devices (<NUM>) and a number of inactively connected wireless devices (<NUM>), connected to the corresponding baseband processor, adapted to maintain a baseband-level active connection allocation indicating a number of available active connections, between the corresponding baseband processor and a wireless device, for the baseband-level capacity processor, and adapted to respond to a request for an active connection from at least one requesting wireless device; and
a plurality of client-level capacity processors (<NUM>), each corresponding to an individual wireless base station (<NUM>), and each coupled to a distinct subset of baseband-level capacity processors within the plurality of baseband-level capacity processors, wherein each of the plurality of client-level capacity processors is adapted to maintain an active connection reservation (<NUM>) indicating a number of additional baseband-level active connection allocations that can be made available for its corresponding baseband-level capacity processors, adapted to provide the baseband-level active connection allocation to each of its corresponding baseband-level capacity processors, adapted to perform a client-level look ahead function to estimate or anticipate a future demand for active connections, and adapted to respond to requests for a baseband-level additional active connection allocation from its corresponding baseband-level capacity processors.