WO2013172648A1

WO2013172648A1 - A method and system for buffering background data in a user equipment (ue)

Info

Publication number: WO2013172648A1
Application number: PCT/KR2013/004295
Authority: WO
Inventors: Satish Nanjunda Swamy Jamadagni; Nitin Jain
Original assignee: Samsung Electronics Co., Ltd.
Priority date: 2012-05-15
Filing date: 2013-05-15
Publication date: 2013-11-21

Abstract

A method and system for handling background data in the User Equipment (UE) is disclosed. The method decides to buffer the background data based on load in the network. The network sends an indication to the UE to buffer the background data based on one or more parameters. The UE isolates the background data from the non-background data to buffer and send the buffered background data to the network when one or more parameters are satisfied. The proposed method shapes the background traffic in the UE. Three explicit mechanisms are proposed for specifying the buffering requirement are by specifying relaxed QCI, by specifying background data specific Logical Channel Group (LCG) and based on an explicit network order on when and traffic type to buffer.

Description

A METHOD AND SYSTEM FOR BUFFERING BACKGROUND DATA IN A USER EQUIPMENT (UE)

The present invention relates to background data or low priority data in a User Equipment (UE) and more particularly relates to handling background data by buffering background data based on the parameters.

Currently 3rd Generation Partnership Project (3GPP) Radio Access Network forum discusses on the methods to handle background data in Long Term Evolution (LTE) radio access networks. Background data (traffic) refers to the autonomous exchange of user plane data packets between User Equipment (UE) and the network. Generally in the absence of a specific user interaction with the device, such packets are due to open applications and keep alive messages which require communication on an intermittent basis. Such traffic is generally low in volume (approximately 5 Bytes/s to 250 Bytes/s) and may be widely dispersed in time.

There have also been discussions related to selecting the Radio Resource Control (RRC) state for UEs. RRC state control may be based on inactivity timers within the network (eNB) and depending on the configured values, for shorter timer values, the frequency of RRC state transitions can become high resulting in high Uu and S1 signaling overheads. For longer timer values, the background traffic tends to keep the UE in an RRC connected state. It has also been observed that the cost of mobility in RRC connected state is higher than the cost of mobility in RRC Idle State. The UE-controlled mobility applies only in idle mode, then from the point of view of mobility signaling alone; it is desirable to place the UE in RRC Idle State as much as possible. However, frequent transitions between RRC idle and connected states are also undesirable.

One existing solution is use of Full connected Discontinuous Reception (DRX), i.e. not having any transitions to RRC idle state can eliminate the RRC connection setup and release signaling. However, this may lead to increased mobility signaling events. Use of network initiated RRC Release based on fixed inactivity timers can result in a high number of RRC Connection Setup (and Release) events, while maintaining a number of mobility events that is dependent on the length of the timer.

Thus in order to achieve optimization between handover signaling overheads and RRC state transition overheads, it would be best to balance between full connected i.e. long inactivity timer effects and frequent idle to connected transitions due to short inactivity timer values.

In another aspect in a typical network scheduler, in the Downlink, the allocations are decided per UE level based on the buffered data. However the scheduler maintains fairness across Radio Bearers (RB) and the applications is subject to implementation. It cannot be ensured that the applications that are mapped to an RB in the UE are served well by multitude of scheduler implementations.

Existing QCI (QoS Class Indicator) mechanism is found to be insufficiency in handling such background traffic. Quality of Service (QoS) involves the delivery of data while meeting a combination of latency, jitter, error rate and maximum/guaranteed bit rate requirements. Currently even though the Background data are latency tolerant, they are treated in accordance with the available QCI latency requirement. The background traffic can easily masquerade in one of the 9 QCIs so that Medium Access Control (MAC) level scheduler has no way of knowing (or isolating) any background level traffic and de-prioritizing such background traffic.

Due to above mentioned reasons, it is evident that the existing methods fails to balance between the UE in full connected state and frequent idle to connected transitions in LTE radio access networks.

The principal object of the embodiments herein is to provide a method and system to buffer background data at the User Equipment (UE) based on the parameter send by a network.

Another object of the invention is to provide a method to isolate non-background data and background data to buffer.

Another object of the invention is to provide UE application based Quality of Experience (QoE) feedback to the scheduler to correct data rates for that Radio Bearer.

Accordingly the invention provides a method for handling background data in a User Equipment (UE) by the network, wherein the method comprises receiving an indication with at least one parameter to buffer said background data by said UE from said network. The method further comprises sending the buffered background data to the network by the UE when at least one parameter is satisfied.

Accordingly the invention provides a network for handling background data in a User Equipment (UE), wherein the network is configured to indicate the UE to buffer the background data based on at least one parameter.

Accordingly the invention provides a User Equipment (UE) for handling background data, wherein the UE comprises an integrated circuit. Further the integrated circuit comprises at least one processor and at least one memory. The memory comprises a computer program code within the circuit. At least one memory and the computer program code with at least one processor cause the UE to receive an indication with at least one parameter to buffer the background data from a network. The UE is further configured to send the buffered background data to the network when at least one parameter is satisfied.

These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

This invention is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

FIG. 1 illustrates an overview of the typical wireless cellular network;

FIG. 2 illustrates a flow diagram explaining the process of sending indication to User Equipment (UE) to buffer background data by the network, according to embodiments as disclosed herein;

FIG. 3 illustrates the flow diagram explaining the process buffering background data by the UE, according to embodiments as disclosed herein;

FIG. 4 illustrates the flow diagram explaining the process of sending Quality of Experience (QoE) to the network, according to embodiments as disclosed herein; and

FIGs. 5a and 5b illustrate the overview of the Scheduling Feedback Reporting (SFR) message for grouping the background data, according to embodiments as disclosed herein.

The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

The embodiments herein achieve a method and system for handling background data in a User Equipment (UE) by the network. The proposed method decides to buffer background data based on load in the network. Further the network sends an indication to the UE to buffer the background data based on one or more parameters. Further the UE isolates the background data from the non-background data to buffer and send the buffered background data to the network when one or more parameters are satisfied. The proposed method shapes the background traffic in the UE.

The proposed method shapes the background traffic. By shaping the background traffic, there can be a predictable behavior from UEs and this will help in setting appropriate DRX values and achieve network optimization. This can also help in mitigating network load due to background traffic. Optimal DRX parameters also help in battery saving on the UE side.

In order to articulate the embodiments of the invention it is also good to understand the concept on QoS in LTE. According to 3GPP, LTE organizes the different types of traffic flows into logical traffic pipes named bearer services. Each bearer service has certain QoS attributes associated with it, depending on the type of traffic it carries. Accordingly, traffic bearers are categorized into four QoS classes based on the QoS constraints of the bearer's traffic: Conversational class, Streaming class, Interactive class, Background class.

Logical Channel Group (LCG) is defined as a group of Radio bearers (RBs) that exhibit similar QoS characteristics. The MAC header may consist of multiple sub-headers. Each sub-header corresponds to a MAC control element, a MAC SDU, or padding and provides more information of the respective field in terms of the content and length. MAC SDUs can belong to different logical channels (indicated by the logical channel identifier (LCID) field in the sub header) is possible.

Buffer Status Reporting (BSR) mechanism is used by the UE to communicate its buffer information to the network. BSR mechanism plays an important role in the uplink scheduler's QoS provisioning where the scheduler gets a status report on how much data await transmission at the UE's uplink buffer.

In an embodiment, the parameter can be volume of the background data, time to send the buffered background data and latency to send the buffered background data or the like.

In an embodiment, the User Equipment (UE) can be a mobile phone, a smart phone, a Personal Digital Assistant (PDA), tablet or the like.

The network referred herein in the description refers to wireless cellular network.

Referring now to the drawings, and more particularly to FIGS. 1 through 5b, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.

FIG. 1 illustrates an overview of the typical wireless cellular network. The figure depicts plurality of User Equipments (UEs) such as UE 100a, UE 100b, UE 100c, UE 100d, UE 100e and UE 100f. The plurality of UEs is connected to a network (eNb) 101. The UEs and eNB 101 comprises several layers in their protocol stack such as PHY (physical) layer forms the layer 1, and layer 2 comprises MAC (Medium Access Control) layer, Radio Link Control. (RLC) Layer and PDCP (Packet Data Convergence Protocol) layer. The UE 100a is installed with multiple applications which includes but not limited to weather update, news update, mail sync, social networking update. Whenever, these applications wants to check for any new data, the UE has to moved to connected state from idle state and receive the data. These applications may be designed without specific consideration on the characteristics of mobile networks. The following aspects of the services affect the diverse data applications: Always on line, relative sparse arriving data and then inactive transmitting and receiving activity over the air, small packets, variable packet arrival interval, several applications running in parallel in one UE and so on. Whenever, UE comes to connected mode the battery power is consumed to send or receive data. Another aspect is handling background data is a big concern as it leads to frequent idle to connected mode signaling transitions. Selecting the Radio Resource Control (RRC) state for mobile UEs is a concern and it may be based on inactivity timers within the eNB and depending on the configured values. Discontinuous Reception (DRX) pattern sent by the network informs UE about when to start transmitting packets to the network. So, every UE connected to the network has to utilize the set DRX pattern received by the network to send/receive data. It is observed that very high percentage of background data originating from open applications are non critical in nature.

FIG. 2 illustrates a flow diagram explaining the process of sending indication to User Equipment (UE) to buffer background data by the network, according to embodiments as disclosed herein. As depicted in the flow diagram 200, initially the network 101 indicates (201) the UEs to start buffering background data. This decision is based on the load in the network.

In an embodiment, the network 101 sends an indication to buffer background data along with one or more parameters.

In an embodiment, the network 101 parameters includes but not limited to the volume of buffered background data, time to send buffered background data or both to the UE in the indication.

In an embodiment, the indication is sent to the UEs in a dedicated message or in a System Information Block (SIB) message.

In an embodiment, the network 101 indicates to the UE when to start and stop buffering background data through an RRC message or through MAC level indication (MAC CE).

Further the network 101 receives (202) the acknowledgement for buffering the background data from the UEs which accepts the network indication to buffer the background data.

In an embodiment, the network 101 configures the DRX setting for all UEs connected to the network to send the buffered background data.

Further, after receiving the acknowledgement from the UEs the network prepares (203) resource allocation for the UEs to transmit the buffered background data. Such resources may be allocated in real time or they may be semi statically fixed.

In an embodiment, the network 101 can also buffer data to send to the UEs.

In an embodiment, the network sends the buffering requirements for background traffic to the UEs.

As the MAC scheduler cannot know of the background traffic, the proposed method introduces a new “relaxed QCI class”. In an embodiment, the new QCI with a relaxed latency requirement can be for example 5 to 10 seconds.

In an embodiment, along with the relaxed latency requirement in the new QCI, a very low Guaranteed Bit Rate (GBR) and non Guaranteed Bit Rate (non-GBR) figures are also specified. The UEs and the network 101 would then buffer such background data in accordance with the relaxed QCI requirement.

In an embodiment, even with the introduction of a relaxed QCI class, there is a need for introducing a new Logical Channel Group (LCG) type, and the proposed method introduces a new LCG type along with the LCG characteristics. This helps in mapping the background data QCI to the new relaxed LCG for better background data shaping at the radio access network.

In an embodiment, the network 101 specifies the LCG in the RRC reconfiguration message.

In another embodiment, when such a background data application (when the application is idle) can be regrouped into another LCG once the application becomes active (foreground application). Such a change in the grouping could be triggered based on the packet inter arrival statistics (IAS). The various actions in flow diagram 200 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 2 may be omitted.

FIG. 3 illustrates the flow diagram explaining the process buffering background data by the UE, according to embodiments as disclosed herein. As depicted in the flow diagram 300, initially UE receives (301) an indication from the network to buffer background data. Further the UE based on the Inter Arrival Statistics (IAS) isolates the background data.

Different applications are mapped to different TCP (Transmission Control Protocol) ports of UE and different applications could have regular data and background data.

In an embodiment, the UE isolates the background data as described below:

Monitor the different application ports

Based on the traffic characteristics, isolate the applications/ports that are sending background traffic

Group all such background traffic from multiple ports into one logical grouping so that any resource request or scheduling decision could be based on that new logical grouping or buffer of data.

In an embodiment, the background data from different ports could be isolated and buffered. In an embodiment, the UE buffer the background data at the PDCP level of the protocol stack.

In an embodiment, the UE buffer the background data at the MAC level or at the RLC level or in combination of MAC and RLC.

In another embodiment, the treatment behavior for each port when they are sending actual application data and when they are handling background could be specified differently.

In an embodiment, the network 101 could specify the time based treatment or volume based treatment of an application based on whether they are sending the actual data or background data in the Traffic Flow Templates (TFTs) that are sent to the UEs.

In an embodiment, packet filtering can be used to isolate the background data so that such data could be buffered. Packet filtering into different bearers is based on Traffic Flow Templates (TFTs).

The TFTs use IP header information such as source and destination IP addresses and TCP port numbers to filter packets such as VoIP from web browsing traffic so that each can be sent down the respective bearers with appropriate QoS.

An UpLink TFT (UL TFT) associated with each bearer in the UE filters IP packets to EPS bearers in the uplink direction. A DownLink TFT (DL TFT) in the P-GW (PDN Gateway) is a similar set of downlink packet filters.

In an embodiment, the TFT filter could filter the background data based on the IAS. In an embodiment, the network 101 could instruct the UE to buffer based on the IAS or some statistics of the inter arrival rate of the packets. The Inter Arrival Statistics characteristics could be specified by the network 101 for buffering.

Further after isolating the non-background data from the background data, the UE buffers (303) the background data. Further the UE checks (304) whether the volume or time specified to send the buffered background data criteria is satisfied. If the criteria are not satisfied, then the UE again buffer the background data. If the criteria are satisfied, then the UE sends (305) the buffered background data to the network 101. The various actions in flow diagram 300 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 3 may be omitted.

FIG. 4 illustrates the flow diagram explaining the process of sending Quality of Experience (QoE) to the network, according to embodiments as disclosed herein. In an embodiment, when the background data are shaped at the network101, it is proposed to provide a mechanism for the UE to report the Quality of Experience (QoE) of the end user/applications to the network 101 as a feedback to the scheduling operation. This facilitates utilization of these feedback parameters to more efficiently schedule the concerned UE(s) and/or their service(s). As depicted in the flow diagram 400, initially the UE determines (401) the QoE of the applications based on pre-defined applicable parameters and thresholds. The application QoE calculation involves averaging the experience factor for some time in order to avoid any false triggers. Further the UE compares (402) the determined QoE against pre-defined thresholds. Further, the UE passes (403) the indication to the MAC layer.

In an embodiment, the cumulative or individual collection of QoE parameters from different applications will be provided to the MAC layer. This indication can be in the form of a bit indication or can be in any other format. The UE can then indicate the QoE indicator to the network 101 in a MAC message. The QoE indication can be on a per LCG basis or generically for the UE. Further at the UE, upon receiving the QoE trigger or indicator from the application, the MAC will form a Scheduling Feedback Report (SFR) message. This SFR message structure could be of fixed size with defined group e.g. logical channel group of the applications or variable size with information either from active LCG or logical channel level.

Further the MAC layer in the UE checks (404) whether the trigger condition is satisfied for SFR reporting. If the trigger condition is not satisfied, then again the UE pass the indication to the MAC layer. If the trigger condition is satisfied, then the MAC layer builds (405) the SFR which could be any MAC message and then transmits (406) the SFR to the network 101. The QOE based scheduling feedback information received at network 101 scheduler is applied in a closed loop fashion to suitably moderate the scheduled allocations. “No satisfaction” feedback would tend to increase the scheduling allocations for respective UE(s) and/or application(s). It should be possible to average out or consider N consecutive feedbacks before to derive corrective actions. Further, it can be applied in conjunction with other factors e.g. existing channel conditions or the like. The various actions in flow diagram 400 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 4 may be omitted.

FIGs. 5a and 5b illustrate the overview of the Scheduling Feedback Reporting (SFR) message for grouping the background data, according to embodiments as disclosed herein. The figure shows the SFR structure for a LCG group ID. This SFR is accumulated together for the UE or indicated individually e.g. as a bitmap to indicate “satisfaction” or “no satisfaction”.

FIG. 5b depicts the SFR structure for multiple LCGs.

In an embodiment, the SFR can be placed in the header field in a MAC PDU utilizing reserved or unused field/bits or conveyed with extended or new field/bits.

When the application constructs the QoE indicator one or more QoE parameters can be considered. For example, the QoE parameters includes but not limited to Distortion as in video or audio streaming, Lip-sync loss, jitter, buffering delay, buffer overflows, play out delays or the like.

The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements shown in Figs. 1 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

Claims

A method for handling background data in a User Equipment (UE) by the network, wherein said method comprises:

receiving an indication with at least one parameter to buffer said background data by said UE from said network; and

sending said buffered background data to said network by said UE when said at least one parameter is satisfied.
The method as in claim 1, wherein said at least one parameter comprises at least one of: volume of said background data, time to send said buffered background data and latency to send said buffered background data.
The method as in claim 1, wherein said method further comprises isolating non-background data and said background data to buffer said background data based on said at least one parameter.
The method as in claim 1, wherein said method further comprises indicating said UE to start and stop buffering said background data using Traffic Flow Templates (TFTs), wherein said TFT is used to isolate said background data based on arrival of packets in said background data.
The method as in claim 1, wherein said method further comprises:

determining Quality of Experience (QoE) after buffering said background data based on said at least one parameter by said UE; and

sending said determined QoE to said network by said UE.
A system for handling background data in a User Equipment (UE) by the network, wherein said system is configured to perform at least one step as claimed in claims 1 to 5.
A network for handling background data in a User Equipment (UE), wherein said network is configured to:

indicate said UE to buffer said background data based on at least one parameter.
The network as in claim 7, wherein said network is configured to indicate said UE to start and stop buffering said background data using Traffic Flow Templates (TFTs), wherein said TFT is used to isolate said background data based on arrival of packets in said background data.
The network as in claim 7, wherein said at least one parameter comprises at least one of: volume of said background data, time to send said buffered background data and latency to send said buffered background data.
The network as in claim 7, wherein said network is configured to allocate resources for said UE to transmit said buffered background data.
A User Equipment (UE) for handling background data, wherein said UE comprises:

an integrated circuit further comprising at least one processor;

at least one memory having a computer program code within said circuit;

said at least one memory and said computer program code with said at least one processor cause said UE to:

receive an indication with at least one parameter to buffer said background data from a network; and

send said buffered background data to said network when said at least one parameter is satisfied.
The UE as in claim 11, wherein said UE is further configured to isolate non-background data and said background data to buffer said background data based on said at least one parameter.
The UE as in claim 11, wherein said at least one parameter comprises at least one of: volume of said background data, time to send said buffered background data and latency to send said buffered background data.
The UE as in claim 11, wherein said UE is further configured to start and stop buffering said background data using an information provided in said indication, wherein said indication comprises Traffic Flow Templates (TFTs) which is used to isolate said background data based on arrival of packets in said background data.
The UE as in claim 11, wherein said UE is further configured to:

determine Quality of Experience (QoE) after buffering said background data based on said at least one parameter; and

send said determined QoE to said network.