WO2016010526A1

WO2016010526A1 - Avoiding congestion in a cellular network via preemptive traffic management

Info

Publication number: WO2016010526A1
Application number: PCT/US2014/046726
Authority: WO
Inventors: Sudhanshu Gaur; Amitav Mukherjee; Joydeep Acharya
Original assignee: Hitachi, Ltd.
Priority date: 2014-07-15
Filing date: 2014-07-15
Publication date: 2016-01-21

Abstract

The present disclosure is directed to ways in which the mobile core network interacts with the end user to control congestion and bring about traffic management, thus improving the overall end-to-end performance. Example implementations described may involve a core network which constructs a database that stores the traffic characteristics in a given geographical region (such as a train station).The traffic characteristics include the spatio-temporal variation in volume and type of application of the traffic from all users. Based on the database the network determines the congestion that a given user would face for a given type of service flow. This depends on the nature of the flow such as the underlying application and also the priority status of the user.

Description

AVOIDING CONGESTION IN A CELLULAR NETWORK

VIA PREEMPTIVE TRAFFIC MANAGEMENT BACKGROUND Field [0001] The present disclosure is generally directed to wireless systems, and more specifically, to avoiding traffic congestion in cellular networks via preemptive traffic management. Related Art [0002] The complete network diagram of a Long Term Evolution (LTE) network is illustrated in FIG. 1. As shown, the various components are as follows. [0003] The user equipment (UE) 101 is the mobile device having an associated user. [0004] The base station 102 is known as the evolved Node B (eNodeB). It is an intelligent node that combines many functionalities of previous Third Generation Radio Network Controllers (3G RNCs). An eNodeB 102 communicates with other eNodeBs 102-1 directly via the X2 interface. The air interface between the UEs 101 and the eNodeB 102, 102-1 is known as the evolved Universal Terrestrial Radio Access Network (E-UTRAN). The protocols operating between the UE and the E-UTRAN (such as CSI feedback, radio resource allocation) are known as the Access Stratum (AS) protocols. [0005] An eNodeB 102 is connected to the core network (CN) which is also called the Evolved Packet Core (EPC) 110. The EPC communicates with the UE 101 through the eNodeB 102. The protocols running between the UE 101 and the EPC (such as paging, initial authentication and session management) are called Non Access Stratum (NAS) protocols. [0006] The Mobility Management Entity (MME) 103 is the main logical entity responsible for all control plane (C-plane) communication. [0007] The Serving Gateway (S-GW) 104 is the mobility anchor of the UEs, and stores and forwards user plane (U-plane) packets. [0008] The Packet Gateway (P-GW) 105 connects to the external internet protocol (IP) networks 106. The P-GW 105 interacts with other entities in the EPC 110 to implement traffic management, user packet filtering, policy and charging, and so forth. [0009] There are other nodes in the EPC 110 such as Home Subscriber Station (HSS) 107 that stores the user profile information. [0010] The EPC can also contain the Traffic Management System (TMS) 108 which interacts with the other nodes mentioned above to implement traffic flow management to avoid congestion in the network. The Policy and Charging Function (PCRF) 109 that stores the policy and charging function rules can also be considered a submodule of the TMS 108. SUMMARY [0011] In LTE networks, congestion may be problematic due to the rapid growth of smartphone usage and service operators offering a wide variety of mobile broadband services. New paradigms for congestion control and traffic management may be needed to maintain the quality of service (QoS) of these services. Data demand these upcoming networks can be localized in nature with places such as major train stations accounting for a large volume. In the present disclosure, example implementations for a UE-interactive method by which the LTE network can perform congestion control in a geographical region is implemented by monitoring the long and short term traffic patterns in that region and providing feedback to the end UE devices. [0012] Aspects of the present disclosure may include a computer device, which involves a memory configured to store traffic congestion control information for a plurality of user equipment (UEs); and a processor, configured to provide corresponding congestion information to one or more of the plurality of UEs from the traffic congestion control information; monitor the one or more of the plurality of UEs for behavior modification and store in the memory as behavior information; and provide UE priority adjustment instructions to one or more base stations based on the behavior information and the traffic congestion control information. The computer device may be in the form of an EPC. [0013] Aspects of the present disclosure may include a computer program containing instructions for executing a process. The instructions may involve storing traffic congestion control information for a plurality of user equipment (UEs); providing corresponding congestion information to one or more of the plurality of UEs from the traffic congestion control information; monitoring the one or more of the plurality of UEs for behavior modification and storing as behavior information; and providing UE priority adjustment instructions to one or more base stations based on the behavior information and the traffic congestion control information.. [0014] Aspects of the present disclosure may include a system, which involves one or more base stations; a plurality of user equipment (UE); and a computer device configured to manage the one or more base stations. The computer device may involve a memory configured to store traffic congestion control information for a plurality of user equipment (UEs); and a processor, configured to provide corresponding congestion information to one or more of the plurality of UEs from the traffic congestion control information; monitor the one or more of the plurality of UEs for behavior modification and store in the memory as behavior information; and providing UE priority adjustment instructions to one or more base stations based on the behavior information and the traffic congestion control information. BRIEF DESCRIPTION OF DRAWINGS [0015] FIG. 1 illustrates a cellular network diagram. [0016] FIG. 2 illustrates an interactive UE traffic management system, in accordance with an example implementation. [0017] FIG. 3 illustrates an example of graphical user interfaces on UE screens for congestion information, in accordance with an example implementation. [0018] FIG. 4 illustrates a UE interaction module, in accordance with an example implementation. [0019] FIG. 5 illustrates an example of a signaling module to inform the UEs with a new radio resource control (RRC) message, in accordance with an example implementation. [0020] FIG. 6 illustrates another example implementation of the Signaling Module where an existing NAS message (e.g. the paging message) is modified for conveying the network congestion information. [0021] FIG. 7 illustrates an example flow diagram for a congestion policy module at the UE, in accordance with an example implementation. [0022] FIG. 8 illustrates an example implementation of the UE reward module. [0023] FIG. 9 illustrates an example implementation of the algorithm for UE and network loads in the form of a network diagram. [0024] FIG. 10 illustrates a timing diagram, in accordance with an example implementation. [0025] FIG. 11 illustrates an example computing environment with an example computer device suitable for use in some example implementations. [0026] FIG. 12 illustrates an example base station upon which example implementations can be implemented. [0027] FIG. 13 illustrates an example user equipment upon which example implementations can be implemented. DETAILED DESCRIPTION [0028] 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. [0029] Example implementations described herein involve a core network which constructs an extensive database that stores the traffic characteristics in a given geographical region (such as a train station).The traffic characteristics include the spatio- temporal variation in volume and type of application of the traffic from all users. Based on the database, the network determines the congestion that a given user would face for a given type of service flow. The congestion depends on the nature of the flow such as the underlying application and also the priority status of the user. [0030] In example implementations, the network transmits the traffic information to some users using methods by which the network can decide which users to transmit the traffic information to, and at what frequency. Further in example implementations, the user can use this information in various ways, such as to switch to a WiFi network or to use service flows that are less congested. The user may also choose to ignore the congestion messages and continue communicating as he or she would have otherwise done. If a user avoids congested flows based on information sent by the network, the network rewards this behavior by reducing congestion for his or her flows after a period of time (e.g., prescribed). [0031] In the related art, the user plane congestion is handled at the EPC. The PCRF or P- GW controls the flow of various service flows being originated and terminated in the UEs. The UEs are never directly involved in congestion control as this was not required for legacy systems. However, with increasing data demand and density of networks, newer avenues should be sought to control congestion and thus ensure QoS to users. Example implementations of the present disclosure therefore involve the UE directly in EPC congestion control. [0032] In example implementations, the network can inform some UEs about the prevailing congestion conditions on a per flow basis and reward UEs that take proactive action based on this information. FIG. 2 illustrates an interactive UE traffic management system, in accordance with an example implementation. [0033] In the example of FIG. 2, the TMS 208 contains a traffic profile module 208-1, a UE interaction module 208-2, a UE behavior monitor module 208-3, and a UE reward module 208-4. The UE 201 may be configured with a Decode NAS signal module 201-1 and a congestion policy module 201-2. [0034] The traffic profile module 208-1 is configured to construct a database of the overall traffic characteristics in a geographical region. The traffic characteristics information can include volume of traffic and types of applications (e.g., internet surfing, logging into company virtual private networks (VPNs), logging into social media websites) being initiated by the UEs. Based on the information stored for this module, the network can predict the congestion that a service flow will see for a given UE. A service flow involves a combination of the evolved packet system (EPS) bearer and the application type. For example, a UE browsing the internet for reading news, logging into a social media website and accessing a company VPN will qualify as three different service flows. Depending on the priority status of the UE, the congestion seen by the UE will change. For example, if a UE is a platinum customer, the network may set aside more resources for the UE and hence the UE would observe less congestion than a regular customer. [0035] The UE interaction module 208-2 is configured to implement various functionalities pertaining to the direct involvement of UEs for congestion control in the network. A graphical example is illustrated in FIG. 3 about what kind of information may be transmitted to the UEs for their direct involvement in the congestion control process. [0036] FIG. 3 illustrates an example of graphical user interfaces on UE screens for congestion information, in accordance with an example implementation. In particular, FIG. 3 shows example of two UEs, UE 1 and UE 2, located close to each other. Hence, the bars in the UE screen that denote the received signal strength is the same (two bars out of five for both in this example). In addition to the signal strength indictor which the UE computes, in example implementations, the UE screen also displays the congestion information for different flows (e.g., as informed by the network). [0037] In an example, suppose that the three flows of FIG. 3 are for accessing the internet for normal websites (Flow 1), for accessing the internet for social media websites (Flow 2), and for accessing the company VPN (Flow 3). As shown in FIG. 3, UE 2 has a higher priority class than UE 1 and hence UE 2 observes‘less’ prevailing congestion conditions for its service flows as characterized by the higher number of bars. [0038] FIG. 4 illustrates a UE interaction module 208-2, in accordance with an example implementations, including a process. At 400, a determination is made as to which UEs are to be chosen for conveying corresponding congestion information. All UEs in a network may be chosen, but this may increase the NAS signaling overhead. Thus, in an example implementation, only those UEs whose service classes are above a level can be chosen. In an example, UEs with QoS Class Identifiers (QCI) having a level of seven and above can be chosen for conveying network congestion information. Other methods for selecting UEs can also be utilized, depending on the desired implementation. [0039] At 401, time instants and periodicities of interaction are calculated when the network informs the UEs about the prevailing network congestion conditions. Should the updates be too frequent, the signaling load may increase. However, too few updates would defeat the purpose of managing the dynamic nature of traffic congestion. [0040] In an example, a new NAS message can be created to convey the network congestion information. The network can decide the time instants and periodicities statically or dynamically for transmitting these NAS messages to all selected UEs to keep the signaling overhead below 10%. [0041] In another example, no new NAS message is created but an existing NAS message is modified for transmitting this information. One of the prominent NAS messages to all UEs is the paging message to idle UEs. In example implementations, the network congestion information can be piggybacked on the paging message information to save extra NAS signaling overhead. However in this example implementation, only RRC_IDLE UEs transitioning to the RRC_CONNECTED state can obtain the information, from which they can use for any subsequent service flows. UEs that are already in RRC_CONNECTED state and actively transmitting and receiving data would not be able to use this network congestion information. [0042] Depending on whether a new NAS message is created or an existing NAS message is modified, the network has to decide the appropriate signaling mechanisms for conveying this information to the UEs. This is performed by the Signaling Module 402. The signaling module 402 depends on whether a new NAS message was created or an existing NAS message was modified. [0043] FIG. 5 illustrates an example of a signaling module to inform the UEs with a new radio resource control (RRC) message, in accordance with an example implementation, and a process. Specifically, FIG. 5 provides an example for when a new NAS message is created and an example of the signaling module to inform the UEs with the new NAS message. At 500, a new NAS message is generated at the EPC. At 501, the corresponding control message format at the E-UTRAN is generated. At 502, to inform the UE of the new NAS message, the corresponding physical downlink control channel (PDCCH) is encrypted with a new radio network temporary identities (RNTI) message, which will allow the UE to understand the nature of this message. [0044] FIG. 6 illustrates another example implementation of the Signaling Module where an existing NAS message (the paging message) is modified for conveying the network congestion information, and a process. Specifically, FIG. 6 illustrates an example of a signaling module 502-1 to inform the UEs with a modified NAS message to include paging. The signaling module 402-1 in the example of FIG. 6 may save on signaling overhead. At 601, the existing NAS message for paging is modified to convey network congestion information. At 602, the corresponding control message format at the E- UTRAN is generated. At 603, to inform the UE of the new NAS message, the corresponding PDCCH is encrypted with a logically modified version paging-RNTI (P- RNTI) where P-RNTI was the initial RNTI for conveying only the occurrence of a paging subframe to a UE. Now the modified P-RNTI indicates the occurrence of a new message (still for the UEs that are being paged) with network congestion information. [0045] Once the network congestion information is conveyed to the UE, the congestion policy module at the UE end decides the course of action. FIG. 7 illustrates an example flow diagram for a congestion policy module at the UE, in accordance with an example implementation. At 700, the UE obtains congestion information and identify flows that are more congested. The UE (the end user) may choose to switch to flows with less congestion, for example Flow 3 in the example shown in FIG. 3. At 701, the UE (the end user) may decide to switch on to a WiFi connection if available. For example, the UE can determine if there is a WiFi connection present that has reliability and signal strength above a threshold. If so (YES), then the UE switches to the WiFi connection as shown at 702. [0046] At 703, the UE (the end user) may choose to ignore the network congestion information and continue communicating over the service flows as the UE would have done in absence of this information. For example, the UE can determine if the congested flow that the UE is connected to is important to the user (e.g., receiving an update for new firmware, company VPN, etc.). If not (NO), then the UE can switch to other flows that are less congested as shown at 704. Otherwise (YES), the UE can ignore the network congestion reports from the EPC as shown at 705. [0047] The network monitors the UE behavior for modification, such as the behavior described at 702 or 704. If many UEs change their behavior based on network congestion information, the overall congestion situation is affected. Thus the output of the decisions made by the UE for the flow diagram of FIG. 7 may be fed back to the traffic profile module which constructs the congestion profile of the network. The configuration policy module of FIG. 7 is an example implementation, and other traffic load reducing behaviors by the UE, such as changing to another base station and so forth. [0048] In example implementations, there can also be a configuration where the network rewards the UEs who take cognizance of the network congestion information and take some action to reduce this congestion. The network reward can be in form of increasing the priority classes of these UEs at least for the context of the concerned flows. [0049] Consider the scenario where UE 1 and UE 2 receive congestion information as shown in FIG. 3. Upon receiving this information, UE 1 stops Flow 2 and Flow 1, i.e. stops surfing the internet and social media websites and focuses on Flow 3, the company VPN. UE 2 chooses to ignore this information. After some time, the network upgrades the congestion status of UE 1 to three bars instead of two for Flow 2. This can also be implemented in a way that does not‘punish’ UE 2. [0050] FIG. 8 illustrates an example implementation of the UE reward module 800, including a process. At 801, the core network identifies UEs that have taken action to reduce congestion based on the congestion information sent by the TMS. At 802, the network creates intermediate priority classes for these UEs. For example, between existing QoS classes 7 and 8, the network creates a new temporary class 7.5 which has higher priority for flows than class 7, but not necessarily as high as class 8. Hence if a UE of class 7 has taken action to reduce congestion based on TMS congestion information, then the network increases its class to 7.5. This can remain for the duration of the congestion condition. At 803, the network can increase the priority class of select UEs based on the examples described above to the nearest intermediate priority class from its existing priority class. Once the congestion of the network reduces to normal level, the priority class of the UE can be reverted back to the original priority class. [0051] FIG. 9 illustrates an example implementation of the algorithm for UE and network loads in the form of a network diagram. In the example of FIG. 9, there are two base stations BS 1 901 and BS 2902 in the core network 900. BS 1 901 has UE 1 903 and UE 2 904 associated with it and BS 2 has UE 3 905 and UE 4 906. UE 1 903 and UE 3 905 are of QoS class 7 (denoted by q7) while UE 2 904 and UE 4 906 are of lower QoS class 6 (denoted by q6). Each UE has two application flows running. These are denoted by f1 and f2. The volume of data transmission in flow j from UE i is denoted by vij. For example the load generated by UE 1 in flow 1 is v11 and that for flow 2 is v12. [0052] The load at a base station is the sum of the loads of the associated UEs. The load at the core network is sum of the loads of all UEs in all base stations. The perceived quality of experience of UE i for flow j is a function of its own load, the total load in the network and its QoS class. For example for UE 1, the QoS is Q1 = f( v11, FT, q7) where FT = FT1 + FT2 where FT1 = v11+v21+v31+v41 and FT2 = v12+v22+v32+v42. In the example of FIG. 9, the network initiated the flow diagrams as described above, when the total load FT is high (e.g. exceeds a threshold). [0053] FIG. 10 illustrates a timing diagram, in accordance with an example implementation. Specifically, FIG. 10 is an example timing diagram of the implementation as applied to the situation of FIG. 9. Assume that the core network via the TMS 208 monitors the total traffic FT1 and FT2 in the Traffic Profile module 208-1 and deems that it is high. In the UE interaction module 208-2, it decides to inform UE 1 and UE 3 as they are of a certain QoS class (q7 in this case), which is decoded by the UE with the decode NAS Signal Module 201-1. [0054] Suppose that UE 1, on receiving the congestion information from the core network, decides to reduce its traffic flow as shown in FIG. 10 based on the congestion policy module 201-2. Accordingly, the UE will generate flow traffic (UL and DL) with a reduced load per the congestion information received from the core network as managed by the TMS 208. The UE flow traffic is passed by the base station 102 to the core network through the TMS 208. In this case the core network reward module 208-4, on observing this behavior through the UE behavior monitor module 208-3 (the base station will inform the core network of the individual UE behavior), decides to upgrade the QoS of the UE based on the observed behavior by providing UE priority adjustment instructions to the base station based on the behavior information received. The priority of the UE is increased and the base station 102 is instructed with the new priority for the UE. [0055] FIG. 11 illustrates an example computing environment with an example computer device suitable for use in some example implementations, such as the TMS 208 configured to manage the CN or EPC. 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. [0056] 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. [0057] 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). [0058] 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. [0059] 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). [0060] 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. [0061] 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). [0062] 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. [0063] 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. [0064] Processor(s) 1110 may be configured to provide corresponding congestion information to one or more of the plurality of UEs from the traffic congestion control information; monitor the one or more of the plurality of UEs for behavior modification and store in the memory as behavior information; and provide UE priority adjustment instructions to one or more base stations as described in the modules and flow diagrams above. Types of behavior that can be monitored can be, for example, as described in FIG. 7. Traffic congestion control information for a plurality of user equipment (UEs) associated with the computing device may be stored and/or managed in memory 1115, and can include traffic flow information from the UEs, time instants and periodicities of interaction, prior behavior information of the UEs, and policies for enforcing priority of UEs as described above. Corresponding traffic congestion information can be sent to corresponding UEs from the traffic congestion control information to inform UEs of the traffic situation. Processor(s) 1110 may also recalculate the traffic congestion control information from feedback of traffic flow information from UEs, as well as creation of new QoS priorities and so forth. [0065] Processor(s) 1110 may also selectively choose a base station from the one or more base stations to interact with specific UEs based on UE traffic load of the one or more base stations to provide the UE priority adjustment instructions. The specific UEs can be selected from the plurality of UEs based on the UE traffic load and based on the UEs associated with the selected base station. [0066] Processor(s) 1110 may create and store into memory 1115 UE class information and calculate the traffic congestion control information based on the UE class information as described for example, in FIG. 8. [0067] FIG. 12 illustrates an example base station upon which example implementations can be implemented. The block diagram of a base station 1200 in the example implementations is shown in FIG. 12, which could be a macro base station, a pico base station, an enhanced node B 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 interface 1204, and the memory 1205. The CPU 1201 is configured to execute one or more modules or flows as described, for example, in FIG 10. 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 NAS signals with 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/or the TMS via a backhaul 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. [0068] 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 FIGS. 2, 7 and 10. 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 PRS for the serving base station to estimate the location of the UE. [0069] 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 most effectively 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. [0070] 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. [0071] 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 non-transitory medium or a storage medium, or a computer-readable signal medium. Non-transitory media or non-transitory computer- readable media can be tangible media such as, but are not limited to, optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible media suitable for storing electronic information. A computer readable signal medium may any transitory medium, 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. [0072] Various general-purpose systems and devices and/or particular/specialized systems and devices 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. [0073] 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. [0074] 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. A computer device, comprising: a memory configured to store traffic congestion control information for a plurality of user equipment (UEs); and a processor, configured to: provide corresponding traffic congestion information to one or more of the plurality of UEs from the traffic congestion control information; monitor the one or more of the plurality of UEs for behavior modification and store in the memory as behavior information; and provide UE priority adjustment instructions to one or more base stations based on the behavior information and the traffic congestion control information.

2. The computer device of claim 1, wherein the processor is configured to select ones of the one or more of the plurality of UEs based on UE traffic load.

3. The computer device of claim 2, wherein the processor is configured to provide the UE priority adjustment instructions to associated ones of the one or more base stations that serve the selected ones of the one or more of the plurality of UEs.

4. The computer device of claim 2, wherein the processor is configured to calculate the traffic congestion control information based on UE behavior and the UE traffic load.

5. The computer device of claim 1, wherein the memory is configured to store UE class information in memory, and wherein the processor is configured to calculate the traffic congestion control information based on the UE class information.

6. The computer device of claim 1, wherein the processor is configured to monitor the one or more of the plurality of UEs for the behavior modification by monitoring for at least one of switching to a less congested flow and switching to a wifi connection by the one or more of the plurality of UEs.

7. A computer program storing instructions for executing a process, the instructions comprising: storing traffic congestion control information for a plurality of user equipment (UEs); providing corresponding traffic congestion information to one or more of the plurality of UEs from the traffic congestion control information; monitoring the one or more of the plurality of UEs for behavior modification and store in the memory as behavior information; and providing UE priority adjustment instructions to one or more base stations based on the behavior information and the traffic congestion control information.

8. The computer program of claim 7, wherein the instructions further comprise selecting ones of the one or more of the plurality of UEs based on UE traffic load.

9. The computer program of claim 8, wherein the instructions further comprise providing the UE priority adjustment instructions to associated ones of the one or more base stations that serve the selected ones of the one or more of the plurality of UEs.

10. The computer program of claim 8, wherein the instructions further comprise calculating the traffic congestion control information based on UE behavior and the UE traffic load.

11. The computer program of claim 7, wherein the instructions further comprise storing UE class information and calculating the traffic congestion control information based on the UE class information.

12. The computer program of claim 7, wherein the monitoring the one or more of the plurality of UEs for behavior modification comprises monitoring for at least one of switching to a less congested flow and switching to a wifi connection by the one or more of the plurality of UEs.

13. A system, comprising: one or more base stations; a plurality of UEs; and a computer device, comprising: a memory configured to store traffic congestion control information for the plurality of user equipment (UEs); and a processor, configured to: provide corresponding traffic congestion information to one or more of the plurality of UEs from the traffic congestion control information; monitor the one or more of the plurality of UEs for behavior modification and store in the memory as behavior information; and provide UE priority adjustment instructions to the one or more base stations based on the behavior information and the traffic congestion control information.

14. The system of claim 13, wherein the processor is configured to select ones of the one or more of the plurality of UEs based on UE traffic load.

15. The system of claim 14, wherein the processor is configured to provide the UE priority adjustment instructions to associated ones of the one or more base stations that serve the selected ones of the one or more of the plurality of UEs.