WO2016118166A1

WO2016118166A1 - Method and apparatus for ran-aware flow control in cellular networks

Info

Publication number: WO2016118166A1
Application number: PCT/US2015/012750
Authority: WO
Inventors: Sudhanshu Gaur; Jeremy OSTERGAARD
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2015-01-23
Filing date: 2015-01-23
Publication date: 2016-07-28
Anticipated expiration: 2017-07-23

Abstract

Example implementations of the present disclosure are directed to a flow control mechanism that utilizes channel conditions of UEs as well as prevailing and predictive traffic patterns in addition to the QoS class of the UEs. The flow control mechanism is presented as part of the Evolved Packet Core (EPC) which can adjust the bit rate of traffic sent to one or more UEs based on certain metrics. Radio Access Networks (RAN) are selected based on load or other criteria.

Description

METHOD AND APPARATUS FOR RAN-AWARE FLOW

CONTROL IN CELLULAR NETWORKS BACKGROUND Field [0001] The present disclosure relates generally to wireless systems and more specifically, to methods and apparatuses for Radio Access Network (RAN) aware flow control in cellular networks. Related Art [0002] With the adoption of smartphones and tablets, the related art has seen more usage of mobile data traffic carried over cellular networks. Video streaming applications can consume large portions of mobile data traffic and can be major cause of congestion at the air interface (i.e. base station to mobile unit) of the related art cellular networks. [0003] A related art cellular network such as Long Term Evolution (LTE) allows flow control mechanisms at the core network (CN) to manage congestion at the air interface. In related art LTE networks, application flow rates for User Equipment (UEs) are managed by the Policy and Charging Enforcement Function (PCEF) and are based on the quality of service (QoS) class of the UEs. Such flow control approaches may not consider the prevailing radio channel conditions between a UE and the serving base station and can therefore be inefficient. SUMMARY [0004] Example implementations of the present disclosure are directed to a flow control mechanism that utilizes channel conditions of UEs as well as prevailing and predictive traffic patterns in addition to the QoS class of the UEs. [0005] Aspects of the present disclosure include an Evolved Packet Core (EPC) apparatus, which can include an interface configured to receive information associated with a Radio Access Network (RAN) and to communicate with the RAN, the RAN associated with one or more User Equipment (UEs); a memory configured to store information relating the one or more UEs to one or more metrics related to the RAN, based on the received information associated with the RAN; and a processor, configured to for a load of the RAN meeting a criteria, select at least a subset of the one or more UEs based on the associated one or more metrics in the memory; and adjust a bit rate of the selected at least the subset of the one or more UEs. [0006] Aspects of the present disclosure includes a method, which can include storing information relating one or more User Equipment (UEs) associated with a Radio Access Network (RAN) to one or more metrics related to the RAN, based on received information associated with the RAN; for a load of the RAN meeting a criteria, selecting at least a subset of the one or more UEs based on the associated one or more metrics; and adjusting a bit rate of the selected at least the subset of the one or more UEs. [0007] Aspects of the present disclosure includes a computer program storing instructions for executing a process, the instructions can include storing information relating one or more User Equipment (UEs) associated with a Radio Access Network (RAN) to one or more metrics related to the RAN, based on received information associated with the RAN; for a load of the RAN meeting a criteria, selecting at least a subset of the one or more UEs based on the associated one or more metrics; and adjusting a bit rate of the selected at least the subset of the one or more UEs. BRIEF DESCRIPTION OF DRAWINGS [0008] FIG. 1 illustrates the RAN and Evolved Packet Core EPC components of an LTE network. [0009] FIG. 2 illustrates an example where cell-edge UEs require more PRBs compared to cell-center UEs to support video streaming. [0010] FIG. 3 illustrates a RAN-aware and predicted traffic-aware congestion control solution for avoiding congestion in the downlink of the RAN, in accordance with an example implementation. [0011] FIG. 4 illustrates a RAN-aware and Predicted Traffic-aware congestion control solution in accordance with an example implementation. [0012] FIG. 5 illustrates a RAN-aware and Predicted Traffic-aware congestion control solution in accordance with an example implementation [0013] FIG. 6 illustrates a flow diagram for the flow control mechanism in a LTE network, in accordance with an example implementation. [0014] FIG. 7 illustrates example hardware configurations for a PCEF, in accordance with an example implementation. [0015] FIG. 8 illustrates a functional diagram of the flow control mechanism, in accordance with an example implementation. [0016] FIG. 9 shows another example implementation of the flow control mechanism where the RAN statistic‘average number of PRBs used’ is utilized instead of ‘spectral efficiency’. [0017] FIG. 10 illustrates management information for the EPC, in accordance with an example implementation. [0018] FIG. 11 illustrates an example computing environment with an example computer device suitable for use in some example implementations. [0019] FIG. 12 illustrates an example base station upon which example implementations can be implemented. [0020] FIG. 13 illustrates an example user equipment upon which example implementations can be implemented. DETAILED DESCRIPTION [0021] The following detailed description provides further details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term “automatic” may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. The terms enhanced node B (eNodeB), small cell (SC), base station (BS) and pico cell may be utilized interchangeably throughout the example implementations. The terms traffic and data may also be utilized interchangeably throughout the example implementations. The implementations described herein are also not intended to be limiting, and can be implemented in various ways, depending on the desired implementation. [0022] In example implementations, there is an application flow control mechanism at the core network (CN) to alleviate congestion at the radio access network (RAN) of a LTE cellular system. In addition to UE class, the flow control is based on additional statistics including UE-specific RAN statistics and predicted traffic patterns. The UE-specific RAN statistics can include spectral efficiency, average number of physical resource blocks (PRBs) assigned, pathloss, packet error rate (PER), channel quality indicator (CQI), mobility information, battery status and so on. The predicted traffic patterns can include traffic patterns in the immediate future for the geographical area served by the base station. [0023] Example implementations determine RAN congestion at selected eNodeBs and then selects target UEs for flow control. The UEs with a lowest QoS class and worst radio conditions can be prioritized for flow control and higher flow rate reduction. In an example implementation, the order for flow control for target UEs can be as follows in decreasing order of priority: [0024] UEs with lowest QoS class (from worst radio conditions, to average radio conditions, to best radio conditions). [0025] UEs with medium QoS class (from worst radio conditions, to average radio conditions, to best radio conditions). [0026] UEs with highest QoS class (from worst radio conditions, to average radio conditions, to best radio conditions). [0027] The degree of flow rate reduction for a given UE can be based on the QoS requirements, RAN resources required to support the reduced flow, and the severity of RAN congestion. In general, UEs which have bad channel conditions and/or lowest QoS requirements can be targeted for higher flow rate reduction compared to UEs that have good channel conditions and/or belong to the highest QoS class. [0028] FIG. 1 illustrates the RAN and Evolved Packet Core (EPC) components of an LTE network. The EPC facilitates the connection from the RAN to the internet. EPC can include elements such as PCEF, Policy and Charging Rules Function (PCRF), Mobility Management Entity (MME), Packet Data Network Gateway (P-GW), and Serving Gateway (S-GW). Such elements can be implemented in hardware, or a combination of hardware and software. The serving gateway (SGW) routes and forwards user data packets, and may also function as a mobility anchor for the user plane during handovers. The packet data network gateway (PGW) is configured to conduct policy enforcement, packet filtering for each user, and packet screening functions. RAN may include one or more associated base stations such as eNodeBs 100, each having a cell to server one or more UEs 101. [0029] In particular, FIG. 1 illustrates RAN congestion caused by heavy video traffic 102 in the downlink. In the event of RAN congestion, the PCEF performs flow control to bring down the downlink data rate at the victim eNodeB 100. The degree of flow rate reduction for a given UE 101 is solely based on its QoS class and current congestion level. In contrast to the related art, example implementations utilize UE-specific RAN awareness while deciding the degree of flow control reduction needed for alleviating RAN congestion. [0030] FIG. 2 illustrates an example where cell-edge UEs require more PRBs compared to cell-center UEs to support video streaming. As FIG. 2 illustrates, the amount of physical resource blocks (PRBs) needed to support a particular application flow rate (such as video streaming) depends upon the radio channel conditions of the UE. For example, to support a video streaming application at a given bit-rate 202, a cell-center UE 201 that is closer to the eNodeB 100 will need fewer PRBs compared to a cell-edge UE 203. This implies that a given reduction in the application flow rate will free up more PRBs if the UE is on the cell-edge compared to when the UE is closer to the cell-center. Thus in the event of RAN congestion, PCEF can be configured to penalize bandwidth heavy UEs not only on the basis of their flow-rates and QoS classes but also in consideration of whether the UEs are on the cell-edge or closer to the base station. Example implementations are directed to a flow control mechanism that utilizes UE-specific RAN information such as spectral efficiency, average number of physical resource blocks (PRBs) assigned, pathloss, packet error rate (PER), channel quality indicator (CQI), and mobility. [0031] In addition to the RAN-Aware aspect, example implementations utilize traffic history patterns to predict traffic in the immediate future while deciding application flow rates for various UEs. FIG. 3 illustrates a RAN-aware and predicted traffic-aware congestion control solution for avoiding congestion in the downlink of the RAN, in accordance with an example implementation. As illustrated in FIG. 3, a traffic prediction module 300 collects traffic history patterns from the traffic database 301 and utilizes the history patterns with current traffic conditions to predict traffic in near future. For example, the traffic prediction module may utilize spatio-temporal patterns of the past traffic, such as traffic in certain geographical areas during office commute hours, to predict traffic in different geographical locations at certain times. The traffic database 301 is a database containing the traffic history of some or all of the eNodeBs associated with the EPC. This information is utilized by the PCEF while deciding upon the degree of flow control needed for each UE in order to guarantee congestion-free operation of eNodeBs. [0032] FIG. 4 illustrates a RAN-aware and Predicted Traffic-aware congestion control solution in accordance with an example implementation. Specifically, FIG. 4 illustrates a situation where traffic information is provided by a probe 400 either connected to eNodeB or placed near the eNodeB to monitor over-the-air transmissions. The traffic probe may either be a software agent co-located with the eNobdeB hardware or may be a separate hardware module programmed to passively listen to over-the-air transmissions. The probe may be able to extract LTE PHY information such as packet errors, location of the users, modulation & encoding scheme that may be used to compute spectral efficiency of specific UEs. [0033] FIG. 5 illustrates a RAN-aware and Predicted Traffic-aware congestion control solution in accordance with an example implementation. UE RAN information such as location information is provided by a third party database 500 or a probe 400 which monitors over-the-air transmissions to estimate spectral efficiencies of the UEs. The database 500 may contain the latest known location of all UEs. For example, the database 500 can include information such as the latest known location of all UEs associated with the EPC. [0034] As shown, FIG. 4 and FIG. 5 are example implementations where instead of an eNodeB, a probe is used to provide traffic information and UE RAN information. Alternatively, a third party database may also be utilized to determine the latest location for the UE. [0035] FIG. 6 illustrates a flow diagram for the flow control mechanism in a LTE network, in accordance with an example implementation. Specifically, FIG. 6 illustrates the signaling between different entities for the RAN-aware and Traffic-aware congestion control mechanism. [0036] At 601, the PCRF sends UE subscription information to the PCEF for the UEs associated with the EPC. Such information can include the guaranteed QoS information for the associated UEs. At 602, the traffic prediction module sends the traffic prediction to the PCEF for the geographical area served by the eNodeB. At 603, the eNodeB transmits UE RAN information to the PCEF. Example of UE RAN information can include Spectral Efficiency, Average number of PRBs assigned, Pathloss, Long term channel output information (COI), PER, Mobility, and so on, depending on the desired implementation. At 604, the PCEF determines if RAN congestion exists or likely to exist in immediate future. Based on the determination, the PCEF can apply UE-specific flow control for the downlink traffic accordingly. At 605, the PCEF sets the data bearer for the downlink traffic with appropriate flow control to the UE. [0037] As illustrated in FIG. 6, example implementations of the PCEF collects information from the following sources: • Policy and Charging Rules Function (PCRF), which is configured to provide the subscription information and thus the QoS class of all connected UEs • Traffic Prediction Module which is configured to provide the likely traffic pattern in near future • eNodeB which is configured to provide UE-specific RAN information such as spectral efficiency, average number of PRBs used, pathloss, long term CQIs, PER, mobility information etc. [0038] Based on the above information, the PCEF determines whether RAN congestion exists or is likely to exist in near future. In the event of RAN congestion, PCEF adjusts the flow rates for a selected subset of UEs. The degree of flow control for the UEs’ is based on their QoS class, current flow rates, current congestion level, and RAN statistics, respectively. [0039] FIG. 7 illustrates example hardware configurations for a PCEF, in accordance with an example implementation. In FIG.7, there is a motherboard 700 having a random access memory (RAM) 701 and central processing unit (CPU) 702, storage 703 and network interface 704. Network interface 704 can be configured to communicate with the internet and other elements of the EPC. Storage 703 may be configured with instructions to facilitate the functionality of the PCEF, which is loaded into memory 701 and executed by CPU 702. Note that PCEF and P-GW functionality can be combined into single hardware device. For example, P-GW functionality can also be stored into storage 703, and executed by CPU 702 when loaded into memory 701. [0040] FIG. 8 illustrates a functional diagram of the flow control mechanism, in accordance with an example implementation. Specifically, FIG. 8 illustrates an example implementation of the RAN-aware and Traffic-aware congestion control mechanism implemented by a Policy and Charging Enforcement Function (PCEF) entity. In the event of RAN congestion, K UEs with the highest flow rates are identified for flow control. These UEs are ordered according to their QoS classes as well as their spectral efficiencies. The UEs with lowest QoS class and worst radio conditions are prioritized for flow control and higher flow rate reduction. An example of UE ordering for the proposed flow control is as follows in decreasing order of priority: [0041] 1) UEs with lowest QoS class and worst radio conditions [0042] 2) UEs with lowest QoS class and average radio conditions [0043] 3) UEs with lowest QoS class and best radio conditions [0044] 4) UEs with medium QoS class and worst radio conditions [0045] 5) UEs with medium QoS class and average radio conditions [0046] 6) UEs with medium QoS class and best radio conditions [0047] 7) UEs with highest QoS class and worst radio conditions [0048] 8) UEs with highest QoS class and average radio conditions [0049] 9) UEs with highest QoS class and best radio conditions [0050] Flow control is applied to the UEs picked from the sub-categories within the ordered list in a successive manner until RAN congestion is relieved. The degree of reduction in flow control for a given UE can be based upon one or more of the following criteria: • UE QoS class • UE spectral efficiency • Current application flow rate for the UE • Current level of RAN congestion • Number of targeted UEs in each sub-category (for example there are 9 sub- categories in the above ordered list) [0051] Such criteria can be compared to a threshold depending on the desired implementation. For example, a threshold for a level of RAN congestion can be set for the EPC, wherein RAN associated with the EPC having a congestion exceeding the threshold can be selected for bit rate adjustment. For example, parameters such as UEs’ spectral efficiencies can be used to determine radio resource usage at the eNodeB as where X represents the bitrate of the application such as video

streaming, BW is the LTE operating bandwidth (e.g., expressed in Hz), the parameter α represents the spectral efficiency of the given UE, and β is based on LTE PHY parameters such as operating bandwidth, control channel bandwidth etc. Once the UE specific mapping between a UE application and its impact on the eNodeB radio resources is established, the PCEF may use this information to determine flow control for targeted UEs based on their QoS classes. [0052] At 800, the EPC obtains information about predicted downlink traffic in the cell served by eNodeB. At 801, the EPC determines the current downlink traffic served by the eNodeB. At 802, the EPC determines if the cell is congested or likely to be congested in immediate future. If not (NO), then the process ends, otherwise (YES), the process proceeds to 803. [0053] At 803, the EPC determines a subset of K UEs having the highest application flow rates (bit-rates). At 804, the EPC orders the target UEs in the following categories: QoS- Low, QoS-Medium, QoS-High in the given order. At 805, the EPC further orders the UEs in each category according to their spectral efficiency (bits/sec) with most spectrally efficient UEs towards the end, in the manner as described in the order of priority above. At 806, a counter i is initiated and set to 1 in accordance with the listed UEs. At 807, the EPC reduces the application flow rate (bit-rate) for the ith UE in the list from Ri to Ri’. [0054] At 808, the EPC determines if the cell is still congested or likely to be congested in immediate future. If so (YES), then the flow proceeds to 809 to increment the counter to move to the next UE in the list for rate adjustment. Otherwise (NO), the flow ends. [0055] FIG. 9 shows another example implementation of the flow control mechanism where the RAN statistics‘average number of PRBs used’ is utilized instead of‘spectral efficiency’. The flow is the same as that of FIG.8, with the change as shown at the flow at 905. At 905, for each of the QoS categories, the UEs are ordered according to their spectral efficiency (bits/sec) with most spectrally efficient UEs towards the end: That is, the ordering is conducted from the largest number of PRBs to the smallest number of PRBs. [0056] FIG. 10 illustrates management information for the EPC, in accordance with an example implementation. In the scenario depicted in the example of FIG. 10, an eNodeB requests downlink traffic to be reduced by 20% which corresponds to X = 20/100 x 71 = 14.2 Mbps. The example implementations as applied to the scenario identify target UEs (UE-2, UE-4, UE-6) for flow control reduction based on an overall desired reduction (X), application rates of UEs, QoS class, and spectral efficiencies. Next, the UEs are ordered as in the flowchart illustrated in FIG. 8 and flow rate reduction is applied as illustrated in FIG. 10. The reduced rates can be chosen based on UE’s current application rate, desired overall reduction, UEs’ spectral efficiency and QoS class. The calculation for the reduced rate can be conducted based on the operation of the eNodeB, or by other methods depending on the desired implementation. For example, parameters such as UEs’ RSSI or spectral efficiencies can be used to determine radio resource usage at the eNodeB as where X represents the bitrate of the application such as video

streaming, BW is the LTE operating bandwidth (expressed in Hz), the parameter α represents the spectral efficiency of the given UE, and β is based on LTE PHY parameters such as operating bandwidth, control channel bandwidth etc. Once the UE specific mapping between a UE application and its impact on the eNodeB radio resources is established, the PCEF may use this information to determine flow control for targeted UEs based on their QoS classes. [0057] FIG. 11 illustrates an example computing environment with an example computer device suitable for use in some example implementations, such as an EPC apparatus to facilitate the functionality of the EPC or one or more elements of the EPC. Alternatively, elements such as the PCEF and P-GW can be implemented in a switch configuration as illustrated in FIG. 7 and communicatively coupled to the computing environment as illustrated in FIG. 11. Computer device 1105 in computing environment 1100 can include one or more processing units, cores, or processors 1110, memory 1115 (e.g., RAM, ROM, and/or the like), internal storage 1120 (e.g., magnetic, optical, solid state storage, and/or organic), and/or I/O interface 1125, any of which can be coupled on a communication mechanism or bus 1130 for communicating information or embedded in the computer device 1105. [0058] Computer device 1105 can be communicatively coupled to input/user interface 1135 and output device/interface 1140. Either one or both of input/user interface 1135 and output device/interface 1140 can be a wired or wireless interface and can be detachable. Input/user interface 1135 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, optical reader, and/or the like). Output device/interface 1140 may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input/user interface 1135 and output device/interface 1140 can be embedded with or physically coupled to the computer device 1105. In other example implementations, other computer devices may function as or provide the functions of input/user interface 1135 and output device/interface 1140 for a computer device 1105. [0059] Examples of computer device 1105 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like). [0060] Computer device 1105 can be communicatively coupled (e.g., via I/O interface 1125) to external storage 1145 and network 1150 for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configuration. Computer device 1105 or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label. [0061] I/O interface 1125 can include, but is not limited to, wired and/or wireless interfaces using any communication or I/O protocols or standards (e.g., Ethernet, 802.11x, Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and/or from at least all the connected components, devices, and network in computing environment 1100. Network 1150 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like). [0062] Computer device 1105 can use and/or communicate using computer-usable or computer-readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory. [0063] Computer device 1105 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others). [0064] Processor(s) 1110 can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit 1160, application programming interface (API) unit 1165, input unit 1170, output unit 1175, and inter-unit communication mechanism 1195 for the different units to communicate with each other, with the OS, and with other applications (not shown). The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided. [0065] In some example implementations, when information or an execution instruction is received by API unit 1165, it may be communicated to one or more other units (e.g., logic unit 1160, input unit 1170, output unit 1175). In some instances, logic unit 1160 may be configured to control the information flow among the units and direct the services provided by API unit 1165, input unit 1170, output unit 1175, in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 1160 alone or in conjunction with API unit 1165. The input unit 1170 may be configured to obtain input for the calculations described in the example implementations, and the output unit 1175 may be configured to provide output based on the calculations described in example implementations. [0066] I/O interface 1125 may be configured to receive information associated with a RAN and to communicate with the RAN, including the eNodeBs and associated UEs. Memory 1115 is configured to store information relating the one or more UEs to one or more RAN related metrics based on the information received through the I/O interface 1125. [0067] Processor(s) 1110 are configured to select at least a subset of the one or more UEs based on the associated metrics from memory 1115, and adjust the bit rate of the selected subset of the one or more UEs. The selection is conducted for RANs having a load that meet the criteria for bit rate adjustment. Such metrics can include PRB usage and spectral efficiency as illustrated in FIGS.8 and 9. The criteria used by the processor(s) 1110 can be based on the predicted traffic congestion for the RAN in comparison to a threshold and can be used to compute the predicted traffic congestion for the RAN. Processor(s) 1110 are also configured to adjust the bit rate of the selected subset of the one or more UEs based on the one or more metrics in the memory 1115, or even based on the number of the UEs associated with the RAN. [0068] FIG. 12 illustrates an example base station upon which example implementations can be implemented. The block diagram of a base station 1200 in the RAN of the example implementations is shown in FIG. 12, which could be a macro base station, a pico base station, an eNodeB and so forth. The base station 1200 may include the following modules: the Central Processing Unit (CPU) 1201, the baseband processor 1202, the transmission/receiving (Tx/Rx) array 1203, the X2/Xn, S1-MME, and S1-U interfaces 1204, and the memory 1205. The CPU 1201 is configured to execute one or more modules or flows as described, for example, in FIG 6 to provide UE RAN information to the EPC apparatus. The baseband processor 1202 generates baseband signaling including the reference signal and the system information such as the cell-ID information. The Tx/Rx array 1203 contains an array of antennas which are configured to facilitate communications with associated UEs. The antennas may be grouped arbitrarily to form one or more active antenna ports. Associated UEs may communicate with the Tx/Rx array to transmit signals containing congestion information, flow traffic information, and so forth. The X2/Xn interface 1204 is used to exchange traffic and interference information between one or more base stations, and S1-MME & S1-U interfaces are used to exchange information with the EPC apparatus to transmit instructions for UE flow traffic and UE priority as described above. The memory 1205 can be configured to store and manage traffic information, traffic load, and so forth. Memory 1205 may take the form of a computer readable storage medium or can be replaced with a computer readable signal medium as described below. [0069] FIG. 13 illustrates an example user equipment upon which example implementations can be implemented. The UE 1300 may involve the following modules: the CPU module 1301, the Tx/Rx array 1302, the baseband processor 1303, and the memory 1304. The CPU module 1301 can be configured to perform one or more functions, such as execution of the flows or modules as described, for example, in FIG. 6 to have bitrate control imported onto the UE by the data bearer. The Tx/RX array 1302 may be implemented as an array of one or more antennas to communicate with the one or more base stations. The memory 1304 can be configured to store congestion information and flow traffic. The baseband digital signal processing (DSP) module can be configured to perform one or more functions, such as to conduct measurements to generate the position reference signal for the serving base station to estimate the location of the UE. [0070] Finally, some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result. [0071] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,”“computing,”“calculating,”“determining,”“displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system’s registers and memories into other data similarly represented as physical quantities within the computer system’s memories or registers or other information storage, transmission or display devices. [0072] Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation. [0073] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers. [0074] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format. [0075] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.

Claims

CLAIMS What is claimed is: 1. An Evolved Packet Core (EPC) apparatus, comprising: an interface configured to receive information associated with a Radio Access Network (RAN) and to communicate with the RAN, the RAN associated with one or more User Equipment (UEs); a memory configured to store information relating the one or more UEs to one or more metrics related to the RAN, based on the received information associated with the RAN; a processor, configured to: for a load of the RAN meeting a criteria, select at least a subset of the one or more UEs based on the associated one or more metrics in the memory; and adjust a bit rate of the selected at least the subset of the one or more UEs.

2. The EPC of claim 1, wherein the one or more metrics comprises at least one of physical resource block (PRB) usage and spectral efficiency.

3. The EPC of claim 1, wherein the criteria is based on predicted traffic congestion for the RAN in comparison to a threshold, wherein the processor is configured to compute the predicted traffic congestion for the RAN.

4. The EPC of claim 1, wherein the processor is configured to adjust the bit rate of the selected at least the subset of the one or more UEs based on the one or more metrics in the memory.

5. The EPC of claim 1, wherein the processor is configured to adjust the bit rate of the selected at least the subset of the one or more UEs based on a number of the one or more UEs associated with the RAN.

6. A method, comprising: storing information relating one or more User Equipment (UEs) associated with a Radio Access Network (RAN) to one or more metrics related to the RAN, based on received information associated with the RAN; for a load of the RAN meeting a criteria, selecting at least a subset of the one or more UEs based on the associated one or more metrics; and adjusting a bit rate of the selected at least the subset of the one or more UEs.

7. The method of claim 6, wherein the one or more metrics comprises at least one of physical resource block (PRB) usage and spectral efficiency.

8. The method of claim 6, wherein the criteria is based on predicted traffic congestion for the RAN in comparison to a threshold, wherein the method further comprises computing the predicted traffic congestion for the RAN.

9. The method of claim 6, wherein the adjusting the bit rate of the selected at least the subset of the one or more UEs is based on the one or more metrics.

10. The method of claim 6, wherein the adjusting the bit rate of the selected at least the subset of the one or more UEs is based on a number of the one or more UEs associated with the RAN.

11. A computer program storing instructions for executing a process, the instructions comprising: storing information relating one or more User Equipment (UEs) associated with a Radio Access Network (RAN) to one or more metrics related to the RAN, based on received information associated with the RAN; for a load of the RAN meeting a criteria, selecting at least a subset of the one or more UEs based on the associated one or more metrics; and adjusting a bit rate of the selected at least the subset of the one or more UEs.

12. The computer program of claim 11, wherein the one or more metrics comprises at least one of physical resource block (PRB) usage and spectral efficiency.

13. The computer program of claim 11, wherein the criteria is based on predicted traffic congestion for the RAN in comparison to a threshold, wherein the method further comprises computing the predicted traffic congestion for the RAN.

14. The computer program of claim 11, wherein the adjusting the bit rate of the selected at least the subset of the one or more UEs is based on the one or more metrics.

15. The computer program of claim 11, wherein the adjusting the bit rate of the selected at least the subset of the one or more UEs is based on a number of the one or more UEs associated with the RAN.