Enhancement for scheduling request triggering based on traffic condition

ES 2 644 263 T3

DESCRIPTION

Enhancement for scheduling request activation based on traffic condition

Technical field

The disclosed embodiments and examples relate generally to mobile communication networks, and more particularly, to speed information and traffic-related information that a UE provides to the network and that triggers the traffic-based scheduling request.

Background

The exponential growth of mobile subscribers requires a substantial increase in network capacity. Currently, network congestion is a problem on many third generation (3G) networks in a number of markets throughout the United States and the world. Congested networks cause dropped calls or failed calls, low data rates, and low response times. Simultaneously with this problem of rapid growth in the number of users, there has been a rapid uptake of Smartphone subscribers, such as iPhone users, Android phone users and Blackberry phone users.

The long-term evolution (LTE) system, which offers high peak data rates, low latency and improved system capacity, is adopted by many operators to overcome the capacity problem. In the LTE system, an evolved universal terrestrial radio access network (E-UTRAN) includes a plurality of evolved node-Bs (eNBs) that communicate with a plurality of mobile stations, referred to as user equipment (EU), through of the LTE-Uu interface. The radio access network additionally connects to a core network (CN), including mobility management entity (MME) service portal (S-GW) and packet data network portal (P-GW), to provide end-to-end services.

Although the LTE network increases the capacity of the system, it is projected that the LTE network may soon face capacity problems. In both traditional and LTE networks, operators always prioritize real-time voice traffic over data traffic. Resources are held in reserve across the network for circuit-switched voice traffic. New wireless data networks, such as 3G and LTE networks, also optimize support for large amounts of data traffic, such as video conferencing. However, such a design does not work well for applications with infrequent, short data sessions, such as chat applications and keeping live messages. Many common applications such as news, weather, social networks, periodically connect and disconnect to / from networks for updates. These applications contain small amounts of user data, yet still require large amounts of signaling traffic to establish and break the session. It is estimated that, with the increasing number of smartphone applications on the network, signaling overhead exceeds data traffic by 30% to 50%, if not more. Therefore, using data networks efficiently is essential to improve network capacity.

Despite improving network efficiency, maintaining quality of service (QoS) is an important area for the successful growth of wireless networks. Applications over wireless networks have different requirements in terms of delay, bandwidth and error rate that they want for optimal performance or user experience. The LTE system has defined a group of QoS class identifier (QCI) values, each corresponding to characteristics of a required service. The goal of standardizing QCI values ​​is to ensure application / service mapping so that the same QCI receives the same minimum level of QoS in multi-vendor network deployments, as well as in roaming scenarios. In access networks, it is the responsibility of the eNBs to ensure the necessary QoS for a bearer over the radio interface. Each bearer has an associated QCI and a hold and assign priority (ARP).

Traditionally, an application is associated with a QoS because it has a predefined QoS requirement. Unlike traditional applications, for today's popular interactive applications, the QoS requirement is dynamic in nature. Many smartphone applications regularly generate traffic even when the smartphone is in background mode, such as when the user is not actively using the device. Therefore, it is desirable to have different QoS partners with an application. For example, the system can associate a QoS with an application that runs when the user is in interactive mode and the lowest QoS requirement when the user is not using the device. Such a dynamic QoS scheme enables the system to reduce resource usage for back-end applications, resulting in less core network signaling overhead and improved LTE-Uu efficiency. On the EU side, the EU power consumption is reduced, mainly by allowing the EU to use sleep cycles to the maximum extent, in which the hardware can be turned off or is in standby mode. Using large idle cycles or large DRX affects QoS performance by introducing additional latency.

ES 2 644 263 T3

In addition to rapidly increasing data and signaling volume putting pressure on the LTE-Uu interface, the amount of core network signaling is also a concern for operators. Operators are strongly hopeful that LTE will efficiently support true "always-on", which enables application upgrade. Such a feature can lead to most of the US being in connected mode, which is quite different from today's wireless network. Especially for smartphones, operators who need to keep the core network load in control. Most of the overhead in Core Network signaling is due to the initial connection establishment. We also observe that, although an EU is always kept in connected mode, the necessary signaling for the connection configuration is reduced, this would instead generate additional signaling for handover, and additionally uses a long DRX in connected mode for good battery consumption that comes with the downside of poor handover performance, due to low EU measurement periodicity of neighboring cells in long DRX. Thus, the problem of controlling and optimizing network signaling, resource usage and EU battery consumption for typical smartphones is complex. To reduce additional configuration overhead, the network must be assisted in identifying “intricate” EUs, which use “always-on” services, which move, and frequently switch between connected and idle modes. An efficient way of identifying such UEs allows the operator to apply special algorithms with high complexity to these UEs to reduce the Core Network traffic, while applying simpler algorithms to the non-problematic UEs.

In light of the exploding growth in the amount of mobile data from various mobile applications, coupled with the widespread adoption of LTE by wireless network operators, it becomes important to find ways to improve network efficiency and maintain QoS for various applications. Embodiments of the present invention overcome various areas such as improving LTE-Uu interface efficiency, reducing Core Network signaling overhead, and reducing EU battery drain. WO2005 / 050851 A2, Interdigital Tech Corp, Publishing Date 2.0.6.2005, discloses a method and apparatus for transferring buffered uplink data (EU) from a WTRU to a node-B. Document Ep 2 211 585 A1 discloses a method for improving a reconfiguration procedure for Schedule Request.

Document WO2007 / 024120 A1, publication date 03.01.2007, discloses a resource request and packet scheduling method for uplink traffic in a mobile communication system. Document NC 101 980 575 A, publication date 02.23.2011, discloses a processing method and a random access terminal including SR-related parameters.

Resume

The object of the invention is achieved by the method for a user equipment as defined in independent claim 1 and by a user equipment as defined in independent claim 12. In a first novel aspect, a method is proposed for a user equipment (EU) to indicate information related to traffic to a network. The method comprises determining a traffic indicator and transmitting the traffic indicator to a base station.

In a disclosed example, the traffic indicator indicates that a predetermined power consumption is preferred or a low power consumption is preferred. For example, when the EU is in background traffic, low power consumption is preferred. Background traffic detection involves at least one of detecting background traffic from a specific application, activation of EU screen power saving, no running application is displayed on EU screen, and no interaction is detected of the users.

In another reported example, the traffic indicator indicates a time pattern of traffic history. In one example, the traffic indicator comprises a history of time periods in which the EU is in a RRC_IDLE mode or in a RRC_CONNECTED mode. In another example, the traffic indicator comprises a number of transactions between the RRC_IDLE mode and the RRC_CONNECTED mode. In yet another example, the traffic indicator comprises a history of packet inter arrival times and packet sizes for a radio bearer or a group of radio bearers. The UE can transmit the traffic indicator to the base station on RRC connection establishment, on RRC connection reestablishment, or when the EU changes cells.

From the network perspective, after receiving and evaluating information contained in the traffic indicator, the network activates a QoS modification procedure by applying one or more QoS modification algorithms. In one example, one or more QoS modification algorithms comprise at least one of the QoS requirements for reduction, scheduling priority reduction, higher DRX cycle configuration, sparse or no uplink resource configuration, and directing the EU to go to RRC_IDLE mode.

In a second novel aspect, a method is provided for determining a modified schedule request trigger based on the detected traffic condition. The method comprises detecting a traffic condition indicating whether the UE is in background traffic mode in the RRC_CONNECTED state, determining a modified scheduling request (SR) trigger based on the traffic condition, and transmitting the scheduling request. to a base station based on the modified SR trigger. The scheduling request is transmitted over a physical uplink channel (PUCCH) or a random access channel (RACH).

ES 2 644 263 T3

In one embodiment, the modified SR trigger is a data buffer or data generation index that exceeds a threshold. In one embodiment, the threshold is determined by the UE based on the QoS requirement that is related to a Prioritized Bit Rate (PBR), or Bucket Size Duration (BSD), or both. In another embodiment, the threshold is set by a base station, based on the size of the smallest grant under the traffic condition.

In an advantageous aspect, the method comprises detecting a traffic condition, in which the EU is configured for the DRX mode and in which the traffic condition indicates whether the EU is in the DRX inactivation time. The EU determines a modified schedule request trigger based on the detected DRX status and then transmits the schedule request via the PUCCH or RACH.

In one embodiment, the threshold used in the modified SR trigger is updated when the DRX detected state changes. In another embodiment, the modified SR trigger is applied to a longer SR period for a logic during the DRX inactivation time. In another embodiment, the modified SR trigger stops the SR during the DRX inactivation time.

In a third novel aspect, a method is provided for providing speed information from the UE to the network. The method supports obtaining speed information from the UE, detecting a trigger event and providing the speed information to the network by one or more predefined means. The speed information is taken from a group consisting of a physical speed, a physical speed mapped onto a predefined speed group, and a virtual speed. The virtual rate comprises a cell change count or a number of cells that the UE has requested for RRC connection during a specified period. The EU can send the rate information to an eNB via RRC connection establishment, RRC connection reestablishment, new RRC measurement report in IE or new RRC message.

In a reported example, the triggering event is the EU changes from the RRC_IDEL state to the RRC_CONNECTED state. In another reported example, the triggering event is the detection of the background traffic mode in the RRC_CONNECTED state. In another disclosed example, the trigger event is a periodic timer expiration or a periodic timer expiration when the UE is in background traffic mode.

In one disclosed example, the triggering event is the UE that detects a speed that exceeds a speed threshold. In another disclosed example, the trigger event is the UE that detects a speed that exceeds a speed threshold when the UE is in background traffic mode. In yet another disclosed example, the trigger event is regulated by a ban timer to limit signaling overhead, in which no speed information is sent over the UE until the ban timer expires.

Other disclosed examples and advantages are described in the detailed description below. This summary is not intended to define the invention. The invention is defined by the claims.

Brief description of the drawings

Figure 1 schematically shows a diagram of a wireless communication system according to embodiments of the invention.

Figure 2 shows a block diagram of an EU and its different function modules according to an embodiment of the invention.

Figure 3 shows main components of a communication network and example blocks of their corresponding functions according to embodiments of the invention.

Figure 4A shows a flow chart of a disclosed example in which a UE detects traffic conditions and sends flags to an eNB.

Figure 4B shows, according to a disclosed example, a UE including traffic information and / or indication in messages to the eNB in ​​Radio Resource Control (RRC) connection or reset configuration.

Figure 5 shows a flow chart of a disclosed example in which traffic information is collected by an eNB to identify "difficult" UEs and the eNB modifies the QoS requirements accordingly.

Figure 6 shows a flow chart of a disclosed example in which a UE informs an eNB of its preference for battery consumption level and the eNB adjusts the QoS of the UE accordingly.

ES 2 644 263 T3

Figure 7 shows a flowchart of a disclosed example in which an eNB monitors the conditions of the bearer EU and modifies the QoS after detecting background traffic on the bearer.

Figure 8 shows a flow chart of a disclosed example in which a Core Network identifies background traffic on EU bearers and the eNB modifies the QoS of the Eu accordingly.

Figure 9A shows a flow chart of a disclosed example in which a UE determines a traffic indicator that is sent to an eNB.

Fig. 9B shows a flow chart of a disclosed example in which an EU detects a traffic history and determines a traffic indicator that is sent to an eNB.

Figure 10 shows a flowchart of a disclosed example in which an eNB receives a traffic indicator, determines whether to activate a QoS modification, and applies QoS modification algorithms when necessary.

Figure 11 shows a flowchart, according to embodiments of the invention, in which a EU and / or a CN identify a traffic condition and send the traffic condition to an eNB, and the EU sets the new trigger of scheduling request (SR) accordingly.

Figure 12A shows a flow chart of an embodiment of the invention in which a UE applying a modified SR trigger sends the SR after detecting buffer data greater than a threshold.

Figure 12B shows a flow chart of an embodiment of the invention in which a UE applying a modified SR trigger sends the SR after detecting the generation rate of a threshold.

Figure 13A shows a flow chart according to embodiments of the invention in which after detecting a discontinuous reception (DRX) state change, it updates a threshold and applies one of the modified SR triggers.

Figure 13B shows a flow chart of an embodiment of the invention in which after detecting the XRD state changes for inactivation, an Eu applies one of the modified SR algorithms.

Figure 14 shows a flow chart of an embodiment of the invention in which a UE detects a traffic condition, determines whether to adopt a modified SR trigger, and transmits an SR to an eNB after the modified trigger is satisfied.

Figure 15 is a flowchart in accordance with one aspect of the invention, in which a UE detects a DRX mode traffic condition to save power, determines a modified SR trigger based on the condition, and transmits an SR to a eNB based on modified SR activator.

Figure 16 shows a flow chart according to the disclosed examples where speed information is collected and sent to an eNB.

Figure 17A shows a flow chart according to a disclosed example in which an eNB keeps a non-mobile UE in a connected state longer.

Figure 17B shows a flow chart according to a disclosed example in which an eNB releases a mobile UE to idle state faster.

Fig. 18 shows a flow chart according to a disclosed example, in which a UE obtains speed information, detects a trigger event and provides the speed information to a network by one or more predefined means.

Detailed description

Reference will now be made in detail to some embodiments of the invention, the examples of which are illustrated in the accompanying drawings.

Figure 1 schematically shows a diagram of a wireless communication system according to embodiments of the invention. The wireless system 100 includes a radio access network 110, a core network 120, and an external network 130. EU 111 and EU 112 connected to eNB 113 and eNB 114 respectively via radio interface. eNB 113 and eNB 114 are connected via interface X2. According to embodiments of the invention, when EU 111 switches from eNB 113 to eNB 114, eNB 113 forwards information from EU 111 pertinent to eNB 114 via

ES 2 644 263 T3 of interface X2. The eNB 113 and the eNB 114 connect with the Mobility Management Entity (MME) 121 and the Service Portal (S-GW) 122 through the S1 interfaces. The MME 121 connects to the S-GW 122 through the S11 interface. The S-GW 122 additionally connects to the P-GW 124 via the S5 / S8 interface. The P-GW 124 connects the Policy and Load Rule Function (PCRF) 123 through the S7 interface. The PCRF 123 controls the network QoS functions. In accordance with embodiments of the invention, entities such as the P-GW 124 collect traffic information. The PCRF 123 makes certain QoS modification accordingly. The P-GW 124 connects to the external network 130 through the SGi interface. Figure 1 further shows an LTE carrier path. Both the EU and the network can initiate a bearer configuration. An end-to-end bearer for an LTE channel includes a radio bearer 141 that connects the EU and the eNB, a 142 S1 bearer that connects the eNB to the MME 121 or S-GW 122, and a 143 S5 / S8 bearer that connects the S -GW 122 to P-GW 124.

Figure 2 shows an example block diagram of the EU 200 EU that supports some embodiments of the present invention. The antenna 201 transmits and receives RF signals. The RF transceiver module 211, coupled with an antenna 201, receives RF signals from the antenna 201, converts them to baseband signals and sends them to the processor 212. The RF transceiver 211 also converts the baseband signals received from the processor 212, converts them RF signals, and sends them to antenna 201. The processor 212 processes the received baseband signals and invokes different functional modules to perform the features in the EU 200. The memory 213 stores program instructions and data to control the operations of the EU 200.

Figure 2 also shows five functional modules 221, 222, 223, 224, and 225, which carry out the embodiments of the present invention. The detection module 221 detects traffic conditions on the EU 200. The traffic indication module 222 evaluates various traffic conditions and other information on the EU 200 and decides to set or update some traffic indicators. The event detection module 223 detects some predefined event triggers. The EU 200 triggers corresponding actions based on the event triggers detected by the event detection module 223. The schedule request (SR) module 224 performs the function of sending SR to an eNB. In accordance with one embodiment of the invention, the SR module 224 performs a modified SR activation for scheduling request. This modified algorithm is activated by the predefined traffic condition in the UE. The speed estimation module 225 collects speed information and estimates the speed EU. This speed information can be used by the EU 200 or an eNB.

A similar configuration exists in an eNB in ​​which one or more antennas transmit and receive RF signals. The RF transceiver module, coupled with the antenna, receives RF signals from the antenna, converts them to baseband signals, and sends them to a processor. The RF transceiver also converts baseband signals received from the processor to RF signals, and sends them to the antenna. The processor processes the received baseband signals and invokes different functional modules to perform features on the eNB. A memory stores program instructions and data to control the operations of the eNB. The eNB also includes various functional modules to carry out some embodiments of the invention.

Embodiments of the current invention improve network efficiency, reduce UE battery while maintaining QoS for various applications. According to some of the realizations, the UE, the eNB and the CN carry out different functions to make improvements to the system. In some embodiments of the invention, the UE collects information and makes decisions for the modification without the participation of other network elements. Still, in other embodiments of the invention, an eNB collects information from a EU and / or CN, modifies the QoS algorithms, and sends the modified information to the UE.

Figure 3 shows main components of a wireless communication network and example blocks of their corresponding functions according to embodiments of the invention. The EU 301 connects to the eNB 302, which connects to the Core Network 303. Function block 311 lists example functions of the EU 301 according to some embodiments of the invention. The EU 301 can perform functions such as identifying special EUs, obtaining speed information; detect background information; and modify the SR trigger. In some embodiments of the invention, after detecting certain traffic conditions, the EU 301 informs the eNB 302 in step 1. Function block 315 lists example functions of the Core Network 303 in accordance with some embodiments of the invention. The 303 Core Network can perform identification functions of the special EU and id background traffic for an UE or UE carrier. After detecting certain traffic conditions, the Core Network 303 informs the eNB 302 in Step 2. The function block 312 lists example functions of the eNB 302. The eNB 302 can identify the special EU and monitor the bearer. In accordance with embodiments of the invention, the eNB 302 modifies the programmer as listed in function block 313. After passing the UE to another target eNB, the eNB 302 will forward the information related to the UE to the target eNB as listed in function block 314.

Figure 3 also shows that the eNB 302 performs the programmer modification as the function block 313 based on the output of the eNB itself as in the function block 312, or by analyzing the information received from the EU 301 through the step 1 or when analyzing the information received from CN 303 through stage 2. Additionally, the eNB302 can modify the programmer as in function block 313 based on one or more of the information mentioned above, from the EU 301, detected on the eNB 302, or from the CN 303. For example, the

ES 2 644 263 T3 special EU identification can be done in EU 301 by collecting the inactivation transition count for a predefined period. The EU 301 can then identify the EU as special if the count exceeds a threshold. The EU decision is a special EU that can be made in the eNB 302 when the eNB collects information from the EU 301 and / or CN303. The eNB 302 can collect inactivation-activation and mobility transition information and labels the UE. Similarly, the 303 Core Network, which includes entities such as MME, S-GW, and P-GW, collects EU statistics and identifies the EU as a special EU. The statistics collected by the CN 303 can be at the granularity of a carrier level.

As shown in Figure 3, each network entity can carry out some functions in accordance with embodiments of the invention. Such functions include detecting information related to traffic, such as identifying the special UE or detecting background traffic; modifying QoS algorithms, such as modifying Scheduling Request and DRX triggers; and the EU provides speed information to the network such that the network can perform further optimization. The following sections discuss embodiments of the invention in detail.

EU Indication of Traffic Related Information

The wide adoption of smartphones and the growing number of downloadable applications continue to increase the volume of signal and data on the mobile network. To efficiently use network resources while maintaining QoS, a more flexible or dynamic QoS scheme is desired. Unlike traditional applications, for today's popular mobile applications, the QoS requirements for the same application may vary depending on some related traffic conditions. Therefore, the first major problem is identifying and relating such traffic-related information.

Figure 4A shows a flow chart of the disclosed example in which a UE detects traffic conditions and sends flags to an eNB. The EU 401 connects to the eNB 402. For some applications, the QoS requirement is different for interactive mode from background mode. Therefore, such information detected in the UE is very useful for the network in order to decide whether to adjust the QoS policy. At point 411, the EU 401 detects that the EU 401 is in interactive mode. In step 1, the EU 401 sends an indication to the eNB 402 indicating that a predetermined power consumption is preferred. Upon receipt, the eNB 402 evaluates whether it needs to adjust the QoS for the EU 401. Normally, while the EU is in interactive mode, the current QoS for the application would apply and there would be no need to modify the existing QoS requirements. At point 412, however, the EU 401 detects that the EU enters the screen power saving mode, or a specific application is running in the background, or an application communication / execution is not displayed on the EU screen. or no user interaction. Although such power saving mode happens, the application is running in background mode. The EU 401 therefore, in step 2, sends an indication to the eNB 402 indicating that low power consumption is preferred. The eNB 402, upon receiving this indication, understands that the application is running in the background mode, and therefore a modified QoS request can be used. By reducing the QoS requirement, the Uu efficiency is improved, and the EU battery is saved. Although the application is running in a background mode, such reduced QoS with higher latencies would be acceptable to a user. At point 413, the EU 401 detects some other traffic condition changes. After detecting these traffic conditions, in step 3, the EU 401 sends the eNB 402 an indication that there is a change in traffic state. In one disclosed example, the EU 401 sends traffic information directly to the eNB 402. Such traffic information includes packet size, average packet size, or inter-arrival times.

As shown in Figure 4A, the EU 401 can send traffic related indication to the eNB 402 such that the eNB 402 can make decisions whether to reduce or change the QoS requirements. Certain traffic condition, background traffic of a specific application, activation of EU screen power saving, a running application is not displayed on the EU screen, and detection of no user interaction, is closely related to the EU's preferences about its energy consumption. Possibly when an application is running in a non-interactive mode, more DRX can be used for background traffic. The purpose of DRX in LTE is to reduce power consumption. As such, a low power consumption preference indication is equivalent to a background mode.

Figure 4B shows, according to a disclosed example, a UE including traffic information and / or indication in messages to the eNB in ​​the Radio Resource Control (RRC) connection or reset configuration. The EU 451 connects to the eNB 452. At point 461, the EU 451 collects traffic information. Such traffic information includes information such as packet sizes, average packet sizes, and inter-arrival times. In step 1, the Eu 451 sends the RRC_CONNECTION_REQEuSt message to the eNB 452. The eNB 452, in step 2, responds with the RRC_CONNECTION_SETUP message. The EU 451 then connects with the eNB 452, in Step 3, it sends the RRC_CONNECTION_SETUP_COMPLETE message to the eNB 452. In a reported example, based on the history of collected traffic information, the EU 451 transmits a traffic indicator indicating a time pattern of traffic history. The EU 451 includes the traffic indicator in the RRC_CONNECTION_SETUP_COMPLETE message. Said traffic indicators are one or more of: a history of time periods in which the EU was in RRC_IDLE mode or in RRC_CONNECTED mode, a transaction count between RRC_IDLE mode and RRC_CONNECTED mode, a history of inter-arrival time of packets for a radio bearer or a group of bearers

ES 2 644 263 T3, a history of packet sizes for a radio bearer or a group of radio bearers. Typically, the EU 451 transmits one or more of these indicators at RRC connection establishment, RRC connection reestablishment, or when the EU changes cells.

Identifying a traffic condition for certain applications, as shown in Figure 4, is an important way to enable modified QoS. In addition to identifying the applications in each EU, it is sometimes important to identify certain “difficult” EUs. In fact, in today's wireless networks, for internet application, the most sophisticated operators keep it simple and discriminate mainly between different subscribers, such as gold, silver and bronze. Operators then bundle the entire category of user traffic onto a single carrier. These carriers can have different QCIs depending on the user's subscription. An example of a "difficult" UE is a UE that has an "always-on" application that runs and moves. This EU causes large amounts of traffic to the core network. Successfully identifying such a EU is important. Once identified, the operators or the system can apply different QoS to the “difficult” UE.

Figure 5 shows such a scheme. Shows a flow chart of a disclosed example in which traffic information is collected by an eNB to identify “difficult” EUs and the eNB modifies the QoS requirements accordingly. The EU 501 connects to the eNB-1 502 and the core 504 network. At point 511 the EU 501 enters the RRC_connected state while connecting to the eNB-1 502. It is observed in Step 521, that the EU 501 connects to the eNB-1 502. In a reported example, then the EU 502 EU enters a state connected to the eNB-1 502, eNB-1 502, at stage 1, it sends a message to the EU 501 requesting the EU 501 to collect traffic statistics for the eNB -1 502. The eNB-1 502 may indicate that the collection of statistics refers to one or more applications, or is specific to certain carriers, or both. In a disclosed example, in Step 2, the eNB-1 502 also sends a message to the core network 504 requesting collection of traffic information statistics for the EU 501. The eNB-1 502 can, at the same time, maintain a label for EU 501 or labels for certain carriers in EU 501.

At point 512, after receiving messages in stage 1 of the eNB-1 502, the EU 501 begins to collect traffic information. The EU 501 can collect statistics of inactivity-activity information, such as the inactive-active transition count for a predefined period. It can also collect average packet sizes, inter-arrival times, and other traffic-related information. The EU can also categorize your pattern as a predefined pattern. At point 514, after receiving the stage 2 message from the eNB-1 502, the core network 504 begins to collect traffic information. The MME, S-GW or P-GW can collect statistics from the EU 501. Such statistics can be in the granularity of the carrier level. The information is presented as a value from a pre-identified range and passed to the eNB-1 502. In a disclosed example, at Step 522, the EU 501 establishes or re-establishes the RRC connection with the eNB-1 502. After such activation events, such as RRC connection or CRR reset, the EU 501 sends traffic indication to the eNB-1 502 indicating that there is traffic information ready to recover. In another disclosed example, said indicator may be sent at other times or is sent periodically. In Step 4, after receiving said traffic state change indication from the EU 501, the eNB-1 502 retrieves traffic information from the EU 501. In step 5, the core network 504 can also send traffic information to the eNB-1 502.

After receiving the traffic information, at point 515, the eNB-1 502 uses the information to optimize the Uu efficiency of the EU 501, such as changing the scheduling priority for the EU 501. The eNB-1 502 can determine to apply a different or relaxed QoS requirement after detecting or determining one or more traffic indicators, such as a traffic history evaluated as being background traffic or sparse traffic, low power consumption is preferred. The eNB-1 502 can apply at least one relaxed or different QoS requirements, such as reducing the QoS requirement, reducing the scheduling priority, configuring larger DRX cycles, configuring sparse or no uplink resources, and ordering the EU to go. to RRC_IDLE mode. The eNB-1 502 restores the default QoS requirement, in which the default QoS requirement is oriented to be satisfied in the connection configuration and the bearer configuration. Restoring the default QoS requirement can be activated after the eNB-1 502 detects one or more traffic indicators such as traffic that is evaluated to be talk traffic, interactive traffic, data stream traffic, or traffic where significant volumes of data are transferred.

In one disclosed example, the eNB-1 502 can evaluate the collected traffic information along with some speed information from the EU 501 to identify the EU 501 as a "difficult" EU. It will then allow the operator to apply special algorithms with high complexity for said UEs to reduce the Core Network traffic, while applying simpler algorithms to the non-problematic UE. In the disclosed example, in Step 6, the eNB-1 502 sends messages to the EU 501 to modify the Programming Request and / or the DRX for the EU 501. In Step 523, the EU 501 goes to the new target eNB- 2 503. After passing, in step 7, the eNB-1 502 forwards the traffic information from the EU 501 to the eNB-2503.

Figure 6 shows a flow chart of a disclosed example in which a UE informs an eNB of its preference for the battery consumption level and the eNB adjusts the QoS of the UE accordingly. The EU 601 connects to the eNB 602. At point 611, the EU 601 detects that the EU 601 is in interactive mode. In Stage 1, the EU 601

ES 2 644 263 T3 sends a message to the eNB 602 indicating that the predetermined power consumption is preferred. After receiving the message, at point 612, the eNB 602 sets the use of normal QoS for the EU 601. At point 613 the EU 601 detects that the EU 601 is not in interactive mode. In Stage 2, the EU 602 sends a message to the eNB 602 indicating that low power consumption is preferred. Similarly, at point 614, the EU 602 detects that the EU 601 enters the display power save mode. In Stage 2, the EU 601 sends messages to the eNB 602 indicating that low power consumption is preferred. At point 615 another event trigger is shown when the EU 601 detects background traffic. In Stage 2, the EU 601 sends a message to the eNB 602 indicating that low power consumption is preferred. After receiving the message in Stage 2, at point 616, the eNB 602 modifies the scheduler for the EU 601. In Stage 3 and Stage 4, the eNB 602 sends modification DRX modification and modifies the request configuration messages programming to EU 601, respectively. In this scenario, the EU 601 collects information and sends it to the eNB who makes the decision to modify the QoS for the EU 601.

Figure 7 shows a flow chart of a disclosed example in which an eNB monitors the conditions of the EU bearers and modifies the QoS depending on the background traffic on the bearer. The EU 701 connects to the eNB 702. At point 711, the eNB 702 begins to monitor the traffic conditions of the EU 701 or EU 701 carriers. At point 712, the eNB 702 detects background traffic from the EU 701. The eNB 702, at point 713, modifies the EU 701 programmer accordingly. In stage 1 and stage 2, the eNB 702 sends modify programming request configuration and modification DRX configuration messages to the EU 701, respectively.

Despite detecting traffic conditions on the eNB, or collecting traffic conditions from the EU, the Core Network can also provide traffic information. Figure 8 shows a flow chart of a disclosed example in which a Core Network identifies background traffic on EU bearers and an eNB modifies the QoS of the EU accordingly. The EU 801 connects to the eNB 802 and the Core Network 803. At point 811, the CN 803 identifies bearers with background traffic from the EU 801. In Step 1, the CN 803 sends new QoS information for the background traffic from the EU 801 to the eNB 802. The CN 803 detects certain background information by means of such inspection of ip headers. Some of the information may not be readily available to identify background traffic. However, the CN 803 can send such information to the eNB 802. The eNB 802 can then combine the information from the CN 803 with other available information to make a decision. After receiving this message, the eNB 802, at point 812, modifies the programmer. In Stage 2 and Stage 3, the eNB 802 sends modify scheduling request configuration and modification DRX configuration messages to the EU 701, respectively.

Figure 9A shows a flow chart of a disclosed example in which the UE determines a traffic indicator that is sent to an eNB. In Step 901, the EU determines a traffic indicator. In Step 902, the UE transmits the traffic indicator to a base station. The traffic indicator indicates that a predetermined power consumption is preferred or a low power consumption is preferred. In one example, for the EU in background traffic, low power consumption is preferred.

Fig. 9B shows a flow chart of a disclosed example in which an EU detects a traffic history and determines a traffic indicator that is sent to an eNB. In step 911, the EU detects a traffic history. In Step 912, the EU determines a traffic indicator based on the traffic history. In Step 913 the UE transmits the traffic indicator to a base station. The traffic indicator indicates a time pattern of the traffic history.

Figure 10 shows a flow chart of a disclosed example in which an eNB receives a traffic indicator, determines whether to trigger a QoS modification, and applies QoS modification algorithms when needed. In step 1001, an eNB receives a traffic indicator. The eNB can receive the information from an EU or a Core Network. In Step 1002, the eNB evaluates the received information contained in the traffic indicator and determines if it triggers a QoS modification procedure. In Step 1003, based on the evaluation in Step 1002, the eNB applies one or more predefined QoS modification algorithms as needed.

Traffic-based scheduling request trigger

Identifying background traffic and applying the modified QoS requirement for that traffic helps improve network efficiency. This section discusses embodiments of the invention that modify the SR trigger for such identified background traffic.

With the increasing number of chat applications on wireless data networks, small data applications periodically connect and disconnect to / from the network for updates. Each connection / disconnection attempt requires several signal message exchanges between the EU and the eNB. This signaling burden is expensive. Additionally, from the user's point of view, for background traffic, while the user is not searching the screen and not interacting, energy saving should take higher priority than performance. Special handling of this small data traffic in background mode helps reduce battery consumption as well as improve network efficiency.

ES 2 644 263 T3

Traditionally, when new data arrives in a data buffer, an EU transmits a scheduling request (SR) through the physical uplink control channel (PUCCH) or a random access channel (RACH). An eNB after receiving such a request would grant resources to the EU. For background traffic, the QoS requirement can be relaxed in order to increase network efficiency and reduce EU battery consumption. Therefore, it is desirable to design an SR trigger algorithm that can aggregate the small requests. The following describes in detail some embodiments of the invention that activate a modified SR based on traffic information.

Figure 11 shows a flow chart, according to embodiments of the invention, in which a EU and / or a CN identify a traffic condition and send a traffic condition to an eNB and the EU sets a new Request Activation Programming (SR) accordingly. The EU 1101 connects to the eNB 1102 and the Core network 1103. At point 1111, the EU 1101 identifies the traffic condition for a bearer. In one embodiment of the invention, after identifying background traffic or a predefined traffic condition, the EU 1101 moves to a point 1115 and sets a new SR trigger. In one embodiment of the invention, said new SR trigger is to stop SR during RACH scheduling request during background mode. In one embodiment of the invention, after configuring the new SR trigger, the EU 1101 sets the corresponding SR trigger threshold value. Said trigger threshold value SR refers to the Prioritized Bit Rate (PBR) and / or Bucket Size Duration (BSD).

In another embodiment of the invention, however, the EU 1101, after identifying the traffic condition at point 1111, sends the traffic condition information to the eNB 1102 in Step 1. The eNB 1102 can also get traffic information Network 1103 Core. At point 1112, core network 1103 identifies background traffic for EU 1101, or for one or more EU 1101 bearers. In Step 2, Core Network 1103 sends traffic condition information to eNB 1102. In one embodiment of the invention, the eNB 1102, after receiving traffic information from the EU 1101 and / or Core Network 1103, determines whether to apply a modified SR trigger at point 1113. If the eNB 1102 determines that an SR trigger is needed Modified, in Step 3, the eNB 1102 sends the modification trigger SR message to the EU 1101. In one embodiment of the invention, the eNB sends configured threshold values ​​to the EU 1101 along with the modified SR trigger message. The eNB sets a threshold value based on the size of the smallest grant under the traffic condition. After receiving said threshold value configured in EU 1101, it uses the threshold as conditions to activate the SR. At point 1114, after receiving the modified SR message from NB 1102, the EU 1101 sets a new SR trigger at point 1115. At point 1116, the EU 1101 checks to see if the modified SR trigger condition is met . If met, at point 1117, the EU 1101 sends a Programming Request to the eNB 1102. The following describes in detail some specific embodiments of the modified SR trigger algorithms.

Figure 12A shows a flow chart of an embodiment of the invention in which a EU applies a modified SR trigger, sends an SR after detecting buffer data greater than a threshold. In Step 1201, a UE receives new data in the transmission buffer. In Step 1202, an EU checks if a modified trigger threshold SR is configured. If a modified SR trigger threshold is not configured, which happens when the traffic condition does not indicate a condition to trigger the SR trigger modification, the UE sends an SR at Step 1205 in the traditional way. If in Step 1202, a modified SR trigger threshold is configured, the EU queues the data in step 1203. In Step 1204, the EU checks whether the current data buffer exceeds a threshold. The threshold, in one embodiment of the invention, refers to a QoS requirement, which is related to a Prioritized Bit Rate (PBR) and / or cube size duration (BSD). In another embodiment of the invention, this threshold is configured through the network. The network sets the threshold value based on the smallest grant size under the traffic condition. The EU after receiving the configuration updates its threshold value. If in Step 1204, the UE detects that the data buffer exceeds the threshold, the UE sends an SR through the PUCCH or RACH. If in step 1204, the UE detects that the data buffer size does not exceed the threshold, the data is queued and the UE goes back to step 1201 to wait for more data to reach the queue such that you can aggregate the data for a single SR.

Fig. 12B shows a flow chart of an embodiment of the invention in which a EU applies a modified SR trigger, sends an SR after detecting the generation rate of a threshold. An EU receives data in the buffer in step 1211. In step 1212, the EU checks if a modified trigger threshold SR is configured. If a modified SR trigger threshold is not configured, which happens when the traffic condition does not indicate a condition for trigger SR modification, the UE sends an SR at step 1215 in the traditional way. In Step 1212, a trigger threshold SR is set, the EU calculates a generation index in Step 1213. The generation index is an indicator of the EU that is a background mode or interactive mode. In step 1214, the EU checks if the generation rate exceeds a threshold. The threshold, in one embodiment of the invention, refers to the prioritized bit rate (PBR) and / or cube size duration (BSD). In another embodiment of the invention, this threshold is configured by the network. If in step 1214, the EU detects that the generation rate exceeds the threshold, the EU sends an SR. If in step 1214, the EU detects that the generation rate does not exceed the threshold, the data is held in the queue and the EU goes back to step 1211 to wait for more data to arrive in the queue in order to aggregate the data for a single SR. Despite the above the receive data can activate the modified SR algorithm, the DRX state can also be used for the modified SR as shown below.

Figure 13A shows a flow chart according to embodiments of the invention in which after detecting a change in the discontinuous reception state (DRX), it updates a threshold and applies one of the SR triggers.

ES 2 644 263 T3 modified. In step 1301, a UE detects the DRX state change. In step 1302, the EU checks if it can apply a modified SR. If a modified SR trigger does not apply, what happens when the traffic condition does not indicate a condition to trigger the SR trigger modification; the EU does nothing for this state change event. If in step 1302, a modified SR trigger is required, the EU, in step 1303, updates the threshold for a modified SR trigger algorithm. A threshold_1 is set for the DRX idle state, and a threshold_2 is set for the duration state. In one embodiment of the invention, threshold_2 can be zero, which will trigger immediate SR sending. Depending on the modified SR trigger algorithms, the EU moves to step 1304 if the DE uses the data buffer size as modified by the SR trigger or 1305 if the EU uses the generation index as modified by the SR trigger . In step 1304, the EU compares the data buffer with the modified threshold. If the data buffer exceeds the modified threshold, the EU, in step 1306, sends an SR. If in step 1304, the UE detects that the data buffer does not exceed the modified threshold, no SR is sent until more data arrives on the queue. In step 1305, the EU compares the generation rate with the modified threshold. If the generation rate exceeds the modified threshold, the EU, in step 1306, sends an SR. If in step 1305, the UE detects that the generation rate does not exceed the modified threshold, no SR is sent until more data arrives in the queue.

Figure 13B shows a flow chart of an embodiment of the invention in which after detecting the DRX state changes to inactive, an EU applies one of the modified SR algorithms. In step 1311, a UE detects a DRX status change to inactive. In step 1312, the EU checks to see if it can apply a modified SR trigger. If a modified SR trigger does not apply, it happens that when the traffic condition does not indicate a condition for trigger SR modification; the EU does nothing for this state change event. If at step 1312, a modified SR is required, the EU can move to step 1313, which increases the SR period or moves to step 1314 which stops the SR.

Figure 14 shows a flow chart of an embodiment of the invention in which the UE detects a traffic condition, determines whether to adopt a modified SR trigger, and transmits an SR to an eNB once the modified trigger is fulfilled. In step 1401, a UE detects a traffic condition, in which the traffic condition indicates whether the UE is in background traffic mode in the RRC_Connected state. At step 1402, the UE determines whether to use a modified Schedule Request Trigger based on the traffic condition. In step 1403, the UE transmits the Schedule Request to an eNB based on the modified SR trigger as needed. Said modified SR trigger is the data buffer that exceeds a predefined threshold or a generation rate that exceeds a predefined threshold.

Figure 15 is a flowchart in accordance with one aspect of the invention, in which a UE detects a DRX mode traffic condition to save power, determines a modified SR trigger based on the condition, and transmits an SR to an eNB based on the modified SR activator. In step 1501, an EU detects a traffic condition, in which the EU is set to DRX mode for power saving and the traffic condition indicates whether the EU is in the DRX inactivation state. In step 1502, the UE determines whether to use a modified SR trigger based on the traffic condition. In step 1503, the EU transmits an SR to an eNB based on the modified SR trigger, where the SR is transmitted via PUCCH or RACH.

EU provides speed information to the network

Another area to improve network efficiency is to reduce network overhead by avoiding frequent passthrough. An important parameter to identify the potential frequent passage of the UE is the speed information of the UE. Currently, most of the US can calculate your speed and get its own speed information. However, such information is quite useful for the network. For example, the network can release the high-speed UE and rely on idle mobility. This form of data traffic is due to the fact that the passage to the network can be reduced. Another example is keeping a qualified EU in a higher connected state, based on the speed information obtained by the network. In some cases, when the network relies on speed information it detects that the UE is moving at high speed and has only background traffic, the network can send said UE to idle faster avoid passing load.

Figure 16 shows a flow chart according to embodiments of the invention in which speed information is collected and sent to an eNB. The speed can be physical speed, a physical speed mapped onto a predefined speed group, or virtual speed. The predefined speed group consists of the different speed group, such as the high speed group in which the EU speed is greater than a threshold_1; The average speed group in the EU speed is smaller than threshold_1 and greater than threshold_2; and the low speed group in which the EU speed is smaller than threshold_2. The virtual rate comprises a cell change count or a number of cells in which the UE has RRC connection requested during a certain period. Flowchart 1610, 1620, and 1630 show various embodiments of the invention that trigger such rate information by sending it to an eNB from an EU.

In one embodiment of the invention, as shown in flowchart 1610 in FIG. 16, a capable EU sends rate information to the eNB after entering the connected state. At point 1611, the EU 1601 is in an idle state. At point 1612, the EU 1601 collects speed information. At point 1613, the EU 1601 enters

ES 2 644 263 T3 the connected state, i.e. RRC connection or RRC reset. After going from the idle state to the connected state, the EU 1601, in stage 1, sends speed information to the eNB-1 1602.

In another embodiment of the present invention, the EU 1601 sends rate information to the eNB-1 1602 periodically based on a periodic timer. As shown in flow chart 1620 in FIG. 16, at 1621, the EU 1601 obtains speed information. At point 1622, the EU 1601 sets a periodic timer. At point 1623, the periodic timer expires. After the expiration of the periodic timer, in step 2, the EU 1601 sends its speed information to the eNB-1 1602.

In another embodiment of the invention, the EU 1601 sends speed information based on predefined trigger events, such as the speed of the EU 1601 exceeds a predefined threshold. As shown in flowchart 1630 in Figure 16, in one embodiment of the invention, at step 3, the eNB-1 1602 sends messages to the EU 1601 to set a speed threshold. At point 1631, the EU 1602 gets speed information. To avoid frequent updating of speed information from the EU 1601 to the eNB-1 1602, in one embodiment of the invention, the EU 1601 sets a forbidden timer at point 1632. The EU 1601, at point 1633, checks whether a forbidden timer expires. If the timer has not expired, there is no action from the EU 1601, even if the speed trigger is presented. At point 1634, after expiration of the forbidden timer, the EU 1601 checks if its speed exceeds the configured speed threshold. If the speed of the EU 1601 exceeds the speed threshold configured in step 4, the EU 1601 sends the speed information to the eNB-1 1602.

In step 1640, the EU 1601 passes to the target eNB-2 1603. After the passage of the EU, in step 5, the eNB-1 1602 forwards the speed information of the EU 1601 to the eNB-2 1603.

In the stages where the EU 1601 sends the speed information to the eNB 1602, the EU 1601 can use a predefined means. Such predefined means include RRC connection establishment, RRC connection reestablishment, a new RRC message or a new IE in the RRC measurement report.

Additionally, it is taken into account that the most valuable use of the speed information is for the background traffic that the EU executes. Therefore, the flowchart triggers 1620 and 1630 can be further conditioned on detecting background traffic or triggering the sending of speed information. An EU indicator indicating low power consumption is preferred and is related to the background traffic condition. Therefore, low power consumption which can also send speed information trigger is preferred.

Once an eNB receives the speed information from an EU, it can optimize its process to avoid frequent steps. Figures 17A and 17B show example embodiments of the invention.

Figure 17A shows a flow chart according to an embodiment of the invention in which an eNB maintains a non-mobile UE in higher connected state. In step 1701, an eNB receives speed information from a UE. In step 1702, the eNB checks to see if the speed of the EU is smaller than a predefined speed threshold. If the speed of the EU is less than the predefined speed threshold, the eNB, in step 1703, keeps the EU in a connected state. If the speed of the UE is greater than the predefined speed threshold, the eNB, in step 1704, releases the UE has been inactive.

Figure 17B shows a flow chart according to an embodiment of the invention in which an eNB releases a mobile UE to a faster idle state. In step 1711, an eNB receives speed information from a UE. In step 1712, the eNB checks to see if the speed of the UE is greater than a predefined speed threshold. If the speed of the UE is greater than the predefined speed threshold, the eNB, in step 1713, the eNB modifies the scheduler or releases the UE to the earliest idle state.

Figure 18 shows a flow chart according to an embodiment of the invention, in which a UE obtains speed information, detects a trigger event and provides the speed information to a network by one or more predefined means. In step 1801, a UE obtains speed information from the UE in a mobile communication network. In step 1802, the UE detects a trigger event. A typical trigger event can be the UE changing from idle to connected state, or an expiration of a periodic timer or some trigger events pass. In step 1803, the UE provides the speed information to a network by one or more predefined means in which the trigger event is detected.

Although the present invention has been described in connection with certain specific embodiments for instructional purposes, the present invention is not limited thereto. In accordance with the foregoing, various modifications, adaptations, and combinations of various features of the described embodiments can be predicted without departing from the scope of the invention as set forth in the claims.