HK1217592B - Reduction of buffer overflow - Google Patents

Description

Buffer overflow reduction

Related applications

This application claims priority to U.S. Provisional Patent Application No. 61/821,635, filed May 9, 2013, attorney docket No. P56618Z, the entire specification of which is incorporated herein by reference in its entirety for all purposes.

Background Art

Generally speaking, machine-to-machine (M2M) communication or machine-type communication (MTC) refers to technologies that allow wireless and wired systems to communicate with other devices without any human intervention. User equipment (UE) equipped for MTC (also referred to as an MTC device) may include, for example, sensors or meters for collecting information. The UE can communicate with an MTC application server (e.g., a software program) via a mobile network (e.g., a wireless network, a wired network, or a hybrid network), which can use or request data from the UE.

The expansion of mobile networks (e.g., broadband wireless access networks, wide area networks) worldwide and the ever-increasing speed/bandwidth and decreasing power of wireless communications have fueled the growth of MTC. Although the amount of data transmitted by UEs equipped for MTC is very small, a large number of these devices are connected to wireless networks and used simultaneously, which can increase the data load and overhead costs on the network.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the present invention; and wherein:

1 is a block diagram illustrating a 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) architecture, according to an example;

FIG2A illustrates a timing diagram including a short discontinuous reception (DRX) cycle according to an example;

FIG2B shows a timing diagram including a long DRX cycle according to an example;

FIG3 illustrates a scheme for reducing the likelihood of a buffer overflow at a serving gateway (S-GW) by instructing an evolved Node B (eNodeB) to modify a discontinuous reception (DRX) configuration for one or more user equipments (UEs), according to an example;

FIG4 depicts functionality of computer circuitry operable to control a node for discontinuous reception (DRX) configuration for a plurality of user equipments (UEs), according to an example;

5 depicts functionality of computer circuitry of a Third Generation Partnership Project (3GPP) Serving Gateway (S-GW) operable to buffer downlink information for a plurality of user equipments (UEs), according to an example;

6 depicts a flow chart of a method for reducing buffer overflow at a 3rd Generation Partnership Project (3GPP) Serving Gateway (S-GW), according to an example;

FIG7 illustrates a block diagram of a mobile device (eg, user equipment), according to an example.

Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same, but it will be understood that no limitation of the scope of the invention is intended.

DETAILED DESCRIPTION

Before the present invention is disclosed and described, it should be understood that the present invention is not limited to the specific structures, processing steps, or materials disclosed herein, but is extended to equivalent forms thereof that will be recognized by those skilled in the relevant art. It should also be understood that the terminology employed herein is used only for the purpose of describing specific embodiments and is not intended to be limiting.

definition

As used herein, the term "substantially" refers to the complete or nearly complete scope or degree of an action, characteristic, property, state, structure, project or result. For example, an object being "substantially" surrounded will mean that the object is completely surrounded or nearly completely surrounded. The exact permissible degree of deviation from absolute completeness may depend on the specific context in some cases. However, generally speaking, approaching completeness will make it seem as if absolute and completely identical identical overall results have been obtained. When used in a negative implication, the use of "substantially" is equally applicable to the complete or nearly complete absence of a reference action, characteristic, property, state, structure, project or result.

Exemplary embodiments

The following provides a preliminary overview of the technology embodiments, followed by a more detailed description of specific technology embodiments. This preliminary overview is intended to help the reader more quickly understand the technology, but is not intended to identify key features or essential features of the technology, nor is it intended to limit the scope of the claimed subject matter. For clarity of the embodiments and overview described below, the following definitions are provided.

Among the wide range of potential applications, machine type communication (MTC) or machine to machine (M2M) communication has gained significant attention among equipment vendors, mobile network operators, and MTC specialist companies. MTC is a form of data communication between one or more entities that does not necessarily require human interaction. Generally, a user equipment (UE) can be equipped for MTC. A UE equipped for MTC may also be referred to as an MTC device. The UE can communicate locally (e.g., wirelessly, via a personal area network (PAN), or hardwired) with other entities that provide data (e.g., a small data payload) to the UE. Thereafter, the UE can process the data and then transmit the data to an MTC server and/or other UEs equipped for MTC. The UE may include health monitoring devices, smart meters, sensors, and the like.

UEs equipped for MTC are capable of transmitting (i.e., sending or receiving) small amounts of data over the network. This small amount of data typically varies from a few bits to several thousand bits. The network can be a wireless wide area network (WWAN) or a wireless local area network (WLAN) based on the selected radio access network (RAN) technology. WWAN can be configured to operate based on cellular network technologies such as the IEEE 802.16 standard (commonly known as WiMAX (Worldwide Interoperability for Microwave Access)) and the Third Generation Partnership Project (3GPP). Versions of the IEEE 802.16 standard include IEEE 802.16e-2005, 802.16-2009, and 802.16m-2011. Versions of the 3GPP standard include 3GPP Long Term Evolution (LTE) Release 8 in the fourth quarter of 2008, 3GPP Advanced LTE Release 10 in the first quarter of 2011, and 3GPP LTE Release 11 in the third quarter of 2012.

In one example, UE power consumption for MTC and other mobile internet applications can be improved by modifying the discontinuous reception (DRX) configuration of UEs equipped for MTC. As discussed in more detail below, DRX can be used to enable wireless devices such as UEs in a 3GPP LTE network to discontinuously monitor downlink control channels (e.g., physical downlink control channels (PDCCHs) transmitted from transmission stations such as enhanced Node Bs (eNBs)). Discontinuous monitoring using DRX can provide significant power savings at the UE because the receiver at the UE can be turned off during selected periods. In other words, when the UE is not monitoring the downlink control channel, the UE can enter a DRX sleep mode or low power mode.

In one example, the power consumption of a UE may be improved by extending the DRX sleep cycle length of one or more UEs. In other words, the UE may be "sleep" for a longer period of time (i.e., the UE does not monitor the downlink control channel for a longer period of time), thereby reducing the power consumption of the UE. The DRX sleep cycle length may be extended for UEs in connected mode or idle mode (i.e., low power consumption mode). In 3GPP LTE Release 11, the maximum DRX sleep cycle length is 2.56 seconds. Therefore, if a UE performs DRX during idle mode, the UE may attach to a periodic DRX sleep cycle, in which the UE may sleep for up to 2.56 seconds. In one configuration, the UE may sleep according to an extended DRX sleep cycle length (e.g., 10 seconds), thereby reducing the power consumption of the UE. Generally, the term "extended DRX sleep cycle length" may refer to a DRX sleep cycle length greater than 2.56 seconds.

After the UE has been dormant for 2.56 seconds (or longer), the UE may wake up during the on-duration. During the on-duration, the UE can listen to the downlink control channel for Internet Protocol (IP) packets that may be incoming in the downlink. The IP packets may include a header and a payload. While the UE is dormant according to the UE's periodic DRX sleep cycle, the downlink IP packets for the UE are buffered at the network (e.g., at the serving gateway) until the next on-duration. In other words, the IP packets are buffered at the network until the UE wakes up during the next on-duration. The UE may listen to the downlink control channel for IP packets that may be incoming in the downlink. The IP packets buffered at the network may be delivered to the UE.

When the maximum DRX sleep cycle length is 2.56 seconds, the network is sufficient to buffer IP packets until the UE wakes up from idle mode. However, if the DRX sleep cycle length is increased to several minutes or even hours (i.e., the UE sleeps according to this extended DRX sleep cycle length), the network may not be able to buffer all IP packets before the UE wakes up from idle mode. As the DRX sleep cycle length increases (e.g., from 2.56 seconds to 10 seconds), the amount of information to be buffered at the network also increases. In other words, the extended DRX sleep cycle may result in an increase in the number of IP packets buffered at the network. Therefore, the network may not be able to handle the increased amount of information to be buffered, especially when multiple UEs equipped for MTC (e.g., thousands of UEs) are using the extended DRX sleep cycle length simultaneously. Even if a single IP packet of the order of 1 kilobyte (kB) is buffered at the network for each of the multiple UEs (e.g., thousands of UEs) when they are idle, the amount of information may still exceed the network's buffering capacity.

FIG1 is a block diagram illustrating an exemplary 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) architecture 100. 3GPP LTE architecture 100 may include at least one user equipment (UE) 102, an evolved Node B (eNB) 104, a serving gateway (S-GW) 106, and a mobility management entity (MME) 108. S-GW 106 and MME 108 may be included in an evolved packet core (EPC) 110. In one example, UE 102 may be equipped for machine type communication (MTC). The radio interface between UE 102 and eNB 104 is an LTE-Uu interface. Thus, the LTE-Uu interface may handle signaling between UE 102 and eNB 104.

The eNB 104 can communicate with the EPC 110 via an S1 interface. The S1 interface may include an S1-MME interface for the control plane and an S1-U interface for the user plane. In other words, control signaling between the eNB 104 and the MME 108 may be handled by the S1-MME interface, while user data between the eNB 104 and the S-GW 106 may be handled by the S1-U interface. Furthermore, control signaling between the S-GW 106 and the MME 108 may be handled by the S11 interface.

In one example, S-GW 106 can buffer downlink IP packets while UE 102 is idle. In other words, S-GW 106 can store downlink IP packets (or downlink information) while UE 102 is in low power mode during an extended DRX sleep cycle (e.g., a 30-second period). S-GW 106 can buffer downlink IP packets until UE 102 wakes up from idle mode (i.e., low power mode) during the on-duration. In addition, S-GW 106 can initiate a network-triggered service request.

In one configuration, the increased amount of information buffered at the S-GW 106 due to the extended DRX sleep cycle length (e.g., 30 seconds compared to 2.56 seconds) can lead to potential overflow at the S-GW buffer within the S-GW 106. Furthermore, potential overflow at the S-GW buffer can be caused by an increased number of UEs and simultaneous use of the extended DRX sleep cycle length. The number of UEs simultaneously using the extended DRX sleep cycle length can potentially be in the thousands. Furthermore, the likelihood of a buffer overflow at the S-GW can increase when the S-GW is suddenly faced with a high volume of connected users. Consequently, the S-GW 106 can drop IP packets, which cannot be received at the UE 102 when it wakes up from idle mode. The loss of IP packets at the UE can degrade the user experience. As discussed in more detail below, the DRX configuration (e.g., DRX sleep cycle length) for one or more UEs can be modified to reduce the likelihood of a buffer overflow at the S-GW 106.

Figures 2A and 2B are timing diagrams of a discontinuous reception (DRX) short cycle and a DRX long cycle, respectively. The UE can be set in the RRC_IDLE or RRC_CONNECTED state to extend battery life while still ensuring high quality of service (QoS) and connection speed. 3GPP LTE implementations allow the UE to reduce the amount of time spent monitoring a control channel (e.g., PDCCH) for control channel information. Instead of monitoring the PDCCH at each transmission time interval (TTI), the UE can monitor the PDCCH only during specific time intervals set by RRC communication. Active Time is the time associated with DRX operation during which the UE monitors the PDCCH in the PDCCH subframe. This solution can provide benefits in both the downlink and uplink because all scheduling control information is transmitted on the PDCCH. During the inactive state, the UE can be configured to enter a power saving state that can significantly reduce the power consumption of the LTE-configured radio frequency modem at the UE.

RRC signaling can be used to manage the use of DRX by setting various parameters. Examples of parameters that can be set in the RRC_CONNECTED state are shown in Figure 2A. DRX parameters may include, but are not limited to: DRX cycle, on-duration timer, DRX inactivity timer, DRX short cycle, and/or short DRX cycle timer.

The DRX cycle may identify the periodic repetition of an active period (identified as "on-duration") followed by a possible inactive period. There are DRX long cycles and DRX short cycles. The on-duration timer may identify how many subframes the UE will be active in when a new DRX cycle begins (at the start of the DRX cycle). During this time, the UE will listen to PDCCH subframes even if there is no data transmission. The DRX inactivity timer may identify how many consecutive PDCCH subframes the UE will remain active in after successfully decoding the PDCCH. The DRX short cycle may identify the periodic repetition of the activity state of the UE when it is in a short DRX situation. The short DRX cycle timer may specify the consecutive number of subframes that the UE will follow a short DRX cycle after the DRX inactivity timer expires.

When the network configures DRX for a UE, it defines a value for the DRX inactivity timer (called the drx-Inactivity timer in 3GPP LTE Counting Specification (TS) 36.321), which starts running after each data block has been sent. If new data is sent, the timer is restarted. If no data is sent when the timer expires, the device can enter DRX mode with a short DRX cycle. This means that the UE will actually sleep and wake up in a relatively short pattern based on the short DRX cycle. If new data is received, it can be received relatively quickly because the UE only sleeps for a shorter period of time. The short DRX cycle mode also has a configurable short DRX cycle timer (i.e., drxShortCycleTimer) attached. Once this timer expires (i.e., no data is received during the short cycle mode), the UE can enter a long DRX cycle. The long DRX cycle can further reduce power usage, but also increases latency.

During periods of inactivity, the UE can only check the control channel and resources are allocated. In each (short and long) DRX cycle, the RF modem can be turned on to listen to the control channel for a number of consecutive subframes set by the on-duration timer. When data activity is detected in the downlink or uplink, the eNB triggers a short DRX cycle for the UE, thereby increasing the responsiveness and connectivity of the UE. The transition between the long DRX cycle and the short DRX cycle can be triggered directly by the eNB or determined by a timer. The control channel information received on the PDCCH can identify the resource blocks in which data is transmitted to the UE, thereby enabling the UE to receive data transmitted in the downlink.

The inactivity timer may specify a consecutive number of TTIs during which the UE will monitor the PDCCH after successfully decoding a PDCCH indicating an uplink or downlink data transmission for the UE. The inactivity timer can keep the UE awake for a period of time during data transmission, even if the on-duration timer has expired. In the downlink, the inactivity timer is typically triggered during the on-duration period. If the on-duration period is longer, the inactivity timer may start and expire during the awake period. In this example, the inactivity timer will not be counted towards the average awake time of the terminal. The inactivity timer may only be triggered for new transmissions in both the uplink and downlink and not for retransmissions.

In the example shown in FIG2A , a short DRX cycle begins at the start of an OnDuration and ends at the start of the next OnDuration. The inactivity timer is shown overlapping with the StartDuration, as described in the previous paragraph. FIG2B shows an example of a long DRX cycle. In this example, the long DRX cycle is shown with an OnDuration timer and an overlapping Inactivity timer.

Figure 3 shows an exemplary scheme for reducing the possibility of buffer overflow at a serving gateway (S-GW). As previously described, the S-GW may buffer downlink IP packets for multiple UEs when the UEs are in an extended DRX sleep cycle length (e.g., 30 seconds). The downlink IP packets may be delivered to the UE when the UE wakes up from idle mode (i.e., low power mode). An increased number of UEs configured for MTC may increase the possibility of buffer overflow at the S-GW. In other words, the S-GW may not be able to handle a large amount of information for multiple UEs. In one example, the possibility of buffer overflow at the S-GW increases when the DRX sleep cycle length of the UE is increased. As a result of the UE being in idle mode for a longer period of time, an increased amount of downlink information is buffered at the S-GW. Modifications to the DRX configuration associated with the UE may reduce the downlink information stored at the S-GW buffer, thereby reducing the possibility of overflow at the S-GW. In one example, the S-GW may reduce the DRX sleep cycle length (eg, from 30 seconds to 2.56 seconds) via the eNB, thereby reducing the downlink information stored at the S-GW buffer.

The S-GW may determine that a buffer overflow is likely to occur when the S-GW buffer capacity is greater than a predetermined threshold. In other words, the S-GW may determine that a buffer overflow is imminent when the amount of downlink information stored in the S-GW buffer exceeds a predetermined threshold. In one example, the S-GW buffer capacity may be greater than the predetermined threshold due to reasons other than the UE's extended DRX sleep cycle length. The S-GW may transmit a buffer overflow message to a mobility management entity (MME) indicating a potential overflow in the S-GW buffer.

The MME may forward the buffer overflow message to the eNB. In addition, the MME may instruct the eNB to modify the DRX configuration of one or more UEs among the plurality of UEs over a period of time to reduce buffer requirements. For example, the MME may instruct the eNB to modify the DRX configuration of one or more UEs until the overflow risk at the S-GW buffer has substantially subsided. In one configuration, the MME may instruct the eNB to adjust (or limit) the extended DRX sleep cycle length or long DRX sleep cycle length of one or more UEs among the plurality of UEs until the likelihood of buffer overflow at the S-GW has been reduced. In one example, the MME may transmit an indicator or instruction to the eNB requesting the eNB to optimize (i.e., modify) the DRX sleep cycle length or other DRX configuration associated with one or more UEs.

The eNB may receive an indication from the MME to modify the DRX configuration of one or more UEs. In one example, the eNB may reduce the extended DRX sleep cycle length (e.g., 15 seconds) to a defined DRX sleep cycle length. The eNB may reduce the extended DRX sleep cycle length to the maximum DRX sleep cycle length, i.e., 2.56 seconds, as defined in 3GPP LTE Release 11. Alternatively, the eNB may reduce the extended DRX sleep cycle length to a period other than 2.56 seconds. By reducing the DRX sleep cycle length, the amount of downlink information stored in the S-GW buffer when the UE is dormant may be reduced.

In one configuration, the eNB may select one or more UEs (i.e., a subset of UEs) from among a plurality of UEs for which to modify the DRX configuration based on predetermined criteria. For example, the eNB may select a UE with the highest data rate or the longest DRX sleep cycle length compared to the plurality of UEs. The eNB may reduce the DRX sleep cycle length for the UE with the highest data rate or the longest DRX sleep cycle. Additionally, the eNB may select one or more UEs other than those with the highest data rate and the longest DRX sleep cycle length for modification of the DRX configuration based on the criteria.

Generally, a UE can modify the DRX configuration of a UE in connected mode (as opposed to idle mode). The eNB cannot modify the DRX configuration of a UE in idle mode because the UE's extended DRX cycle length would make it unavailable for the UE to receive the modified DRX configuration from the eNB. Therefore, the eNB may wait until one or more UEs transition from idle mode to connected mode, at which point the eNB may modify the DRX dormant cycle length of the one or more UEs in connected mode.

In an alternative configuration, the eNB may modify the DRX configuration of multiple UEs (e.g., reduce the DRX sleep cycle length) rather than the DRX configuration of a subset of UEs in the multiple UEs. For example, the eNB may modify the DRX configuration of the multiple UEs in response to receiving multiple buffer overflow messages with instructions to modify the DRX configuration of the UEs from the S-GW via the MME. When the DRX modification performed by the eNB does not significantly reduce the likelihood of buffer overflow at the S-GW, the S-GW may transmit multiple buffer overflow overload messages to the eNB. For example, the eNB may reduce the DRX sleep cycle length of the UE from 30 seconds to 20 seconds, but if the likelihood of buffer overload is not substantially reduced, the eNB may further reduce the DRX sleep cycle length to 10 seconds. In addition, the multiple buffer overload messages with instructions to modify the DRX configuration of the UE may be transmitted to the eNB within a predefined period of time (e.g., the S-GW may send three consecutive messages in a span of two minutes).

In an additional configuration, the eNB may modify the DRX configuration of one or more UEs to prevent them from entering DRX sleep mode (or low power mode). For example, the eNB may modify the DRX configuration of UEs in the connected state to prevent these UEs from entering DRX sleep mode. The eNB may prevent UEs from entering DRX sleep mode to reduce the amount of downlink information stored in the S-GW buffer. As a result, fewer UEs may be assigned a DRX configuration. After a period of time (e.g., when the possibility of buffer overflow subsides), the UE can enter DRX sleep mode.

As previously described, one or more UEs may have a reduced DRX sleep cycle length (or be unable to enter DRX sleep mode) in response to the eNB modifying the DRX configuration of the one or more UEs. Upon receiving an indication from the S-GW that the risk of a buffer overflow at the S-GW has substantially subsided, the eNB may reconfigure the DRX sleep cycle length of the UE back to the previous DRX configuration. For example, when the likelihood of a buffer overflow at the S-GW exceeds a predetermined threshold, the DRX sleep cycle length of the UE may be reduced from 30 seconds to 10 seconds, but when the risk of a buffer overflow has substantially subsided, the DRX sleep cycle length may be restored to 30 seconds.

As shown in the flowchart of FIG4 , another example provides functionality 400 of a computer circuit of a node operable to control discontinuous reception (DRX) configurations for a plurality of user equipments (UEs). The functionality may be implemented as a method, or the functionality may be executed on a machine as instructions, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. The computer circuit can be configured to: when downlink information stored in an S-GW buffer exceeds a predetermined threshold, receive a buffer overflow message from a serving gateway (S-GW) indicating a potential overflow in the S-GW buffer, as shown in block 410. The computer circuit can also be configured to select one or more UEs from the plurality of UEs based on predefined criteria, as shown in block 410. Furthermore, the computer circuit can be configured to modify the DRX configuration of the one or more UEs to reduce the downlink information stored in the S-GW buffer, thereby reducing the likelihood of an overflow in the S-GW buffer, as shown in block 430.

In one example, downlink information is stored in an S-GW buffer until the UE wakes up from a low power mode during a discontinuous reception (DRX) sleep cycle. Furthermore, the computer circuitry can be configured to receive a buffer overflow message from the S-GW via a mobility management entity (MME). Furthermore, the computer circuitry can be configured to modify the DRX configuration of one or more UEs by reducing the DRX sleep cycle length of the one or more UEs.

In one configuration, the computer circuitry can be further configured to select one or more UEs from the comparison of the plurality of UEs based on a predetermined criterion of the highest data rate or the longest DRX sleep cycle length. Furthermore, the computer circuitry can be further configured to modify the DRX configuration of one or more UEs in connected mode. In one example, the computer circuitry can be further configured to modify the DRX sleep cycle length of one or more UEs when the UE transitions from idle mode to connected mode.

In one configuration, the computer circuitry may be further configured to, in response to receiving a buffer overflow message from an S-GW, prevent one or more UEs from entering a low power mode during a DRX sleep cycle. Furthermore, the computer circuitry may be further configured to, in response to receiving multiple buffer overflow messages from the S-GW, modify the DRX sleep cycle lengths of multiple UEs. The computer circuitry may be further configured to, in response to receiving an indication from the S-GW that the possibility of overflow at the S-GW buffer has ended, reconfigure the DRX sleep cycle lengths of the one or more UEs to a previous DRX configuration. In one example, the node is selected from the group consisting of a base station (BS), a node B (NB), an evolved node B (eNB), a baseband unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), or a remote radio unit (RRU).

As shown in the flowchart of FIG5 , another example provides functionality 500 of computer circuitry of a Third Generation Partnership Project (3GPP) Serving Gateway (S-GW) operable to buffer downlink information for a plurality of user equipments (UEs). The functionality may be implemented as a method, or the functionality may be executed on a machine as instructions, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. The computer circuitry can be configured to receive downlink information for a plurality of UEs, as shown in block 502. The computer circuitry can also be configured to store the downlink information in an S-GW buffer when the plurality of UEs are in a low power mode during a discontinuous reception (DRX) sleep cycle, as shown in block 520. Furthermore, the computer circuitry can be configured to detect a potential overflow at the S-GW buffer when the downlink information stored at the S-GW buffer exceeds a predetermined threshold, as shown in block 530. Additionally, the computer circuit can be further configured to transmit a buffer overflow message to an evolved Node B (eNB) indicating a likelihood of overflow at the S-GW buffer, wherein the buffer overflow message instructs the eNB to modify a DRX configuration associated with one or more UEs of the plurality of UEs, thereby reducing the likelihood of overflow at the S-GW buffer, as represented by block 540.

In one example, the buffer overflow message instructs the eNB to modify the DRX sleep cycle length of one or more UEs, thereby reducing the likelihood of overflow at the S-GW buffer. In an additional example, the one or more UEs are in connected mode. In one configuration, the computer circuitry may be further configured to transmit the buffer overflow message to the eNB via a mobility management entity (MME). In one example, the plurality of UEs include machine type communication (MTC) devices. Furthermore, the plurality of UEs include antennas, touch-sensitive display screens, speakers, microphones, graphics processors, application processors, internal memory, or non-volatile memory ports.

As shown in the flowchart of FIG6 , another example provides a method 600 for reducing buffer overflow at a 3rd Generation Partnership Project (3GPP) Serving Gateway (S-GW). The method may be executed on a machine as instructions, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. The method includes receiving, at an evolved Node B (eNB), from an S-GW, a buffer overflow message indicating a potential overflow of downlink information in a S-GW buffer, wherein the downlink information is stored in the S-GW buffer until a plurality of user equipments (UEs) awaken from a low power mode during a discontinuous reception (DRX) sleep cycle, as shown in block 610. The method may also include selecting one or more UEs from the plurality of UEs based on predefined criteria, wherein the one or more UEs are in connected mode, as shown in block 620. The method may also include modifying the DRX configuration of the one or more UEs to reduce the downlink information stored in the S-GW buffer, thereby reducing the likelihood of overflow in the S-GW buffer, as shown in block 630.

In one example, the method may further include: when the downlink information stored at the S-GW buffer exceeds a predetermined threshold, receiving a buffer overflow message from the S-GW. In addition, the method may further include receiving the buffer overflow message from the S-GW via a mobility management entity (MME).

In one example, the method may further include selecting one or more UEs based on predefined criteria related to data rate or DRX cycle length. In one example, modifying the DRX configuration of the one or more UEs includes reducing the DRX sleep cycle length of the one or more UEs. In an additional example, modifying the DRX configuration of the one or more UEs includes preventing the one or more UEs from entering a low power mode during the DRX sleep cycle.

Figure 7 provides an example illustration of a mobile device (e.g., a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a cell phone, or other type of wireless device). The mobile device may include one or more antennas configured to communicate with a node, macro node, low power node (LPN), or transmitting station (e.g., a base station (BS), an evolved Node B (eNB), a baseband unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), or other type of wireless wide area network (WWAN) access point). The mobile device may be configured to communicate using at least one wireless communication standard, including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The mobile device may use a separate antenna for each wireless communication standard or a shared antenna for multiple wireless communication standards. The mobile device may communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WWAN.

FIG7 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output of a mobile device. The display screen can be a liquid crystal display (LCD) screen or other types of display screens, such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen can use capacitance, resistance, or another type of touch screen technology. An application processor and a graphics processor can be coupled to an internal memory to provide processing and display functions. A non-volatile memory port can also be used to provide data input/output options to the user. The non-volatile memory port can also be used to expand the memory capabilities of a mobile device. A keyboard can be integrated with the mobile device or wirelessly connected to the mobile device to provide additional user input. A virtual keyboard can also be provided using a touch screen.

The various techniques or aspects or portions thereof may take the form of program code (i.e., instructions) embodied in a tangible medium (e.g., a floppy disk, CD-ROM, hard drive, non-transitory computer-readable storage medium, or any other machine-readable storage medium), wherein when the program code is loaded into a machine (e.g., a computer) and executed by the machine, the machine becomes an apparatus for implementing the various techniques. When the program instructions are executed on a programmable computer, the computing device may include: a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be: RAM, EPROM, flash drive, optical drive, hard disk drive, or other medium for storing electronic data. The base station and mobile device may also include: a transceiver module, a counter module, a processing module, and/or a clock module or timer module. One or more programs that can implement or use the various techniques described in this application may use an application programming interface (API), reusable controls, etc. These programs may be implemented in a high-level programming language or an object-oriented programming language to communicate with the computer system. However, if desired, the program(s) may be implemented in assembly language or machine language. In any case, the language may be a compiled or interpreted language and may be combined with hardware implementation.

It should be understood that in order to more particularly emphasize the implementation independence of many of the functional units described in this specification, these units have been labeled as modules. For example, a module can be implemented as a hardware circuit comprising: a custom VLSI circuit or gate array, an off-the-shelf semiconductor, such as a logic chip, a transistor, or other discrete components. A module can also be implemented in a programmable hardware device (e.g., a field programmable gate array, programmable array logic, a programmable logic device, etc.).

Modules can also be implemented in software to be executed by various types of processors. An identified module of executable code may include, for example, one or more physical or logical blocks of computer instructions, which may be organized, for example, as objects, procedures, or functions. However, the executable instructions identifying a module need not be physically located together, but may include different instructions stored in different locations that, when logically connected together, constitute the module and achieve the stated purpose of the module.

In fact, the module of executable code can be a single instruction, or a lot of instructions, or even can be distributed on several different code segments, between different programs and across several memory devices.Similarly, operational data can be identified and illustrated in the application within the module, and can be implemented in any appropriate form and organized within the data structure of any appropriate type.Operational data can be collected as a single data set, or can be distributed on different locations (including on different storage devices), and can only exist as the electronic signal on a system or network at least in part.These modules can be passively or actively include an agent that can be operated to perform a desired function.

Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrase "in one embodiment" or the words "in an embodiment" in various places throughout this application are not necessarily all referring to the same embodiment.

As used herein, for convenience, multiple items, structural elements, constituent elements and/or materials may be presented in a common list. However, these lists should be interpreted as if each component of the list is independently identified as a separate and unique component. Therefore, the independent components of the list should not be interpreted as the substantial equivalents of any other components of the same list simply based on their presentation in a common group without contrary instructions. In addition, various embodiments and examples of the present invention can be referenced together with the alternatives of its various components in this application. It should be understood that these embodiments, examples and alternatives should not be interpreted as substantial equivalents of each other, but should be interpreted as separate and autonomous representations of the present invention.

In addition, the features, structures, or characteristics may be combined in any appropriate manner in one or more embodiments. In the following description, many specific details (e.g., layout examples, distances, network examples, etc.) are provided to provide a comprehensive understanding of the embodiments of the present invention. However, those skilled in the relevant art will recognize that the present invention can be implemented without one or more of the specific details, or with other methods, components, layouts, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the present invention.

Although the above examples illustrate the principles of the present invention in one or more specific applications, it is apparent to those skilled in the art that many modifications may be made to the form, use, and details of the embodiments without the aid of creative personnel and without departing from the principles and concepts of the present invention. Therefore, the present invention is not intended to be limited except by the appended claims.

Claims (20)

1. A node operable to control discontinuous reception (DRX) configuration of multiple user equipments (UEs), the node having computer circuitry configured to perform the following: When the downlink information stored in the Service Gateway (S-GW) buffer exceeds a predetermined threshold, a buffer overflow message indicating a potential overflow in the S-GW buffer is received from the S-GW. One or more UEs are selected from the plurality of UEs based on a predefined criterion of either the highest data rate or the longest DRX sleep cycle length; and By reducing the DRX sleep cycle length of one or more UEs, the DRX configuration of one or more UEs is modified to reduce the downlink information stored in the S-GW buffer, thereby reducing the possibility of overflow in the S-GW buffer. 2. The node as claimed in claim 1, wherein the downlink information is stored in the S-GW buffer until the UE wakes up from a low-power mode during a discontinuous reception (DRX) sleep cycle. 3. The node of claim 1, wherein the computer circuitry is further configured to receive the buffer overflow message from the S-GW via a mobility management entity (MME). 4. The node of claim 1, wherein the computer circuitry is further configured to modify the DRX configuration of the one or more UEs in a connected mode. 5. The node of claim 1, wherein the computer circuitry is further configured to: modify the DRX sleep cycle length of the one or more UEs when the UE transitions from idle mode to connected mode. 6. The node of claim 1, wherein the computer circuitry is further configured to: prevent the one or more UEs from entering a low-power mode during a DRX sleep cycle in response to receiving the buffer overflow message from the S-GW. 7. The node of claim 1, wherein the computer circuitry is further configured to: modify the DRX sleep cycle length of the plurality of UEs in response to receiving a plurality of buffer overflow messages from the S-GW. 8. The node of claim 1, wherein the computer circuitry is further configured to: in response to receiving an indication from the S-GW that the possibility of an overflow at the S-GW buffer has ended, reconfigure the DRX sleep cycle length of the one or more UEs to the previous DRX configuration. 9. A 3GPP Serving Gateway (S-GW) operable to buffer downlink information of multiple User Equipments (UEs), the S-GW having computer circuitry configured to perform the following: Receive downlink information from the plurality of UEs; When the plurality of UEs are in a low-power mode during a discontinuous reception (DRX) sleep cycle, the downlink information is stored in the S-GW buffer; When the downlink information stored in the S-GW buffer exceeds a predetermined threshold, the possibility of overflow in the S-GW buffer is detected; and A buffer overflow message indicating the possibility of overflow at the S-GW buffer is transmitted to the evolved Node B (eNB), wherein the buffer overflow message instructs the eNB to perform the following operations: One or more UEs are selected from the plurality of UEs based on a predefined criterion of either the highest data rate or the longest DRX sleep cycle length; and The DRX configuration associated with the one or more UEs is modified by reducing the DRX sleep cycle length of the one or more UEs in order to reduce the possibility of overflow at the S-GW buffer. 10. The 3GPP S-GW as claimed in claim 9, wherein one or more UEs are in a connected mode. 11. The 3GPP S-GW as claimed in claim 9, wherein the plurality of UEs includes machine type communication (MTC) devices. 12. A method for reducing buffer overflows at a 3GPP Serving Gateway (S-GW), the method comprising: At the evolved Node B (eNB), a buffer overflow message is received from the S-GW, indicating a potential overflow of downlink information at the S-GW buffer, wherein the downlink information is stored at the S-GW buffer until multiple user equipment (UEs) wake up from low-power mode during discontinuous reception (DRX) sleep cycles; One or more UEs are selected from the plurality of UEs based on a predefined criterion of either the highest data rate or the longest DRX sleep cycle length, wherein the one or more UEs are in connected mode; and By reducing the DRX sleep cycle length of one or more UEs, the DRX configuration of one or more UEs is modified to reduce the downlink information stored in the S-GW buffer, thereby reducing the possibility of overflow in the S-GW buffer. 13. The method of claim 12, further comprising: receiving a buffer overflow message from the S-GW when the downlink information stored in the S-GW buffer exceeds a predetermined threshold. 14. The method of claim 12, further comprising: receiving the buffer overflow message from the S-GW via a mobility management entity (MME). 15. The method of claim 12, wherein modifying the DRX configuration of the one or more UEs includes preventing the one or more UEs from entering a DRX sleep cycle. 16. An apparatus for reducing buffer overflows at a 3GPP Serving Gateway (S-GW), the apparatus comprising: A means for receiving a buffer overflow message from the S-GW at an evolved Node B (eNB), the buffer overflow message indicating a potential overflow of downlink information at the S-GW buffer, wherein the downlink information is stored at the S-GW buffer until multiple user equipments (UEs) wake up from a low-power mode during a discontinuous reception (DRX) sleep cycle; A means for selecting one or more UEs from a plurality of UEs based on a predefined criterion of either the highest data rate or the longest DRX sleep cycle length, wherein the one or more UEs are in a connected mode; and An apparatus for modifying the DRX configuration of one or more UEs by reducing the DRX sleep cycle length of the one or more UEs, so as to reduce the downlink information stored at the S-GW buffer, thereby reducing the possibility of overflow at the S-GW buffer. 17. The apparatus of claim 16, further comprising: means for receiving a buffer overflow message from the S-GW when downlink information stored in the S-GW buffer exceeds a predetermined threshold. 18. The apparatus of claim 16, further comprising: means for receiving the buffer overflow message from the S-GW via a mobility management entity (MME). 19. The apparatus of claim 16, wherein the means for modifying the DRX configuration of the one or more UEs includes means for preventing the one or more UEs from entering a DRX sleep cycle. 20. At least one computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform the method for reducing buffer overflows at a 3GPP Serving Gateway (S-GW) as described in any one of claims 12-15.