WO2013014246A1

WO2013014246A1 - A method for controlling the encoding rate of data traffic and a network

Info

Publication number: WO2013014246A1
Application number: PCT/EP2012/064727
Authority: WO
Inventors: Stefan Schmid; John Fitzpatrick
Original assignee: Nec Europe Ltd.
Priority date: 2011-07-26
Filing date: 2012-07-26
Publication date: 2013-01-31

Abstract

For allowing an efficient resource consumption and providing high quality applications for users a method for controlling the encoding rate of data traffic of an application between two endpoints within a network is claimed. The method is characterized in that a network entity monitors ongoing data traffic or flows between the two endpoints and - based on a definable policy and/or information - controls or modifies an uplink and/or downlink encoding rate at one or both endpoints. Further, an according network is claimed, preferably for carrying out the above mentioned method.

Description

A METHOD FOR CONTROLLING THE ENCODING RATE OF DATA

TRAFFIC AND A NETWORK

The present invention relates to a method for controlling the encoding rate of data traffic of an application between two endpoints within a network. Further, the present invention relates to a network, wherein the encoding rate of data traffic of an application between two endpoints within the network will be controlled.

Existing application source encoding rate adaptations are performed on an end-to- end basis; this is because the codec adaptation mechanisms were designed to deal with changes at any network segment between both endpoints. Furthermore, some codecs such as the AMR (Adaptive Multi-Rate) voice codec are also capable of adapting to the link state between the UE (User Equipment) and the base station.

New mechanisms defined in 3GPP (3^rd Generation Partnership Project) allow a network entity to indicate congestion to a UE using ECN (Explicit Congestion Notification). Although this is specifically targeted at providing feedback for AMR voice sources it also has the potential to be used for any endpoint application with adaptation capabilities. As such the focus of this discussion is on the AMR codec however this does not preclude the mechanisms described from being applied to other applications such as interactive video sessions or video/audio streaming.

During periods of congestion, as media traffic such as AMR voice traverses the IP network ECN is used to mark the IP (Internet Protocol) header to signal impending congestion, this is echoed by the receiver by setting the CE (Congestion Experienced) bits of the upper layer protocol or using alternate signalling so that the transmitter of the original IP packet is informed of the congestion. When a terminal receives a congestion notification it is recommended that the terminal "backs off' by reducing their encoding data rate in an effort to make network resources available and mitigate congestion.

Particularly, codec rate reduction for IP backhauls, as currently defined in 3GPP, is performed using IP based Explicit Congestion Notification which allows a network entity to indicate congestion on a link resulting in the endpoint reducing its coding rate. Both endpoints in a voice session continually monitor their downlink radio conditions and also look for the ECN - which indicates congestion on the e2e path -, and based on these sets the CMR (Codec Mode Request) field of outgoing voice frames or uses RTCP-APP (Real Time Control Protocol-APP) signalling. Each endpoint of the voice call modifies the outgoing encoding rate based on the received request. Increases in source coding rate are performed automatically by the source node based on receiving indications of good channel conditions or after a congestion has been resolved, i.e. when the ECN is no longer used.

In a scenario in which many voice flows are being transported over a common link the automatic rate increases may be undesirable. For example, an operator may want to fix or limit the data rate of calls to increase capacity or reduce bandwidth consumption based on subscription information, e.g. Gold, Silver or Bronze levels. However, with the currently defined approach the adaptation is completely endpoint centric and random to the extent that ECN is only marked when the queue lengths reach a certain threshold. This means that the network is not controlling which specific endpoints are adapting. Related prior art regarding codec rate adaptation and systems and methods for adapting a source rate are disclosed within WO 2006/135334 A2, US 201 1/0032935 A1 and US 2010/0318670 A1 .

The problem with the above mentioned approach is that the network has no control over exactly which encoding rates the endpoints will select or the manner in which they will adapt. Furthermore, when congestion appears a large number of terminals that share the same congested link may simultaneously reduce their encoding rate when in fact only a small decrease in network resource utilization was required. When it appears that the network is no longer congested each terminal will independently attempt to increase the source coding rate after a fixed time period (for AMR voice this is typically 5 seconds); this could be particularly problematic when a large number of sessions are traversing the same link. It is an object of the present invention to improve and further develop a method for controlling the encoding rate of data traffic of an application between two endpoints within a network and an according network for allowing an efficient resource consumption and providing high quality applications for users.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1 and by a network comprising the features of claim 17. According to claim 1 the method is characterized in that a network entity monitors ongoing data traffic or flows between the two endpoints and - based on a definable policy and/or information - controls or modifies an uplink and/or downlink encoding rate at one or both endpoints. According to claim 17 the network is characterized by a network entity for monitoring ongoing data traffic or flows between the two endpoints and - based on a definable policy and/or information - for controlling or modifying an uplink and/or downlink encoding rate at one or both endpoints. According to the invention it has been recognized that it is possible to allow a very efficient resource consumption by means of a network entity which monitors ongoing data traffic or flows between the two endpoints and which controls or modifies an uplink and/or downlink encoding rate at one or both endpoints. Concretely, such a controlling or modifying process is based on a definable policy and/or information. In other words, there can be provided individual regulations by the policy and/or information, e.g. a static configuration, for individually controlling or modifying the encoding rate or source encoding rate at one or both endpoints. Thus, applications for users can be provided which comprise a high quality, preferably for voice and/or video applications. At least one endpoint could be a small cell or a base station.

Within a preferred embodiment the network entity could monitor signalling information or messages related to the application and/or monitor network congestion indications. Thus, a control of encoding rates of endpoint applications can be based on information from signalling flows or information or messages and/or from network congestion indications. A very reliable control or modification of encoding rates will be possible. Concretely, the network entity could monitor ECN and CE flags or bits within the data traffic or flows. Such ECN and CE flags or bits are obtainable in many current situations and applications.

Within a further preferred embodiment the network entity could modify at least one encoding data request in a signalling information or message between the two endpoints. Preferably, the network entity could modify the CMR field of AMR/AM R- WB frames.

Alternatively or additionally the network entity could modify, e.g. set or oppress, at least one congestion indication notification. This provides a method for influencing and modifying individual source encoding rates of one or both endpoints.

Concretely, if deemed beneficial according to the monitoring process the network entity could modify in-band or out-of-band signalling information or messages. Depending on the individual situation an appropriate modification can be performed.

The network entity could be provided in various ways. Within one preferred embodiment the network entity could be centralised on a single entity in the network. Such a network entity could be integrated in or removed from a network very easily. Within another preferred embodiment the network entity could be distributed across different network elements. In this way a separate single entity is not necessary which could reduce hardware costs. Within a further preferred embodiment the network entity and one endpoint could be co-located or the network entity could be provided by an endpoint itself, i.e. the functionality of the proposed network entity would be implemented by the end point or service node/software directly. In this way the management of the network entity could be simplified by a combined management of the network entity and the respective endpoint. Within a further preferred embodiment one individual flow or individual flows within a definable network region could be controlled or modified. Thus, predefined flows could be preferred regarding application quality, for example.

Alternatively, all flows or sets of flows within a definable network region could be controlled or modified. Thus, fairness between different users and applications, load balancing and increase of capacity could be provided. Within a further preferred embodiment the network entity could provide different levels of service or QoS (Quality of Service) to different subscribers or groups of subscribers sharing a common link within the network. This could be performed at random or based on definable subscription information or policies. Such a provision of different levels of service or QoS could be preferably performed during periods of congestion for allowing an efficient resource consumption.

During periods of congestion a set of subscribers whose service level is downgraded due to congestion could be expanded until congestion is resolved or reduced to a definable threshold. Thus, an appropriate response to congestion situations is possible.

Alternatively, during periods of congestion the service level of all subscribers could be downgraded and if congestion is resolved or reduced to a definable threshold, then definable subscribers or sets of subscribers could slowly have increased their encoding rate up to a definable encoding rate by the network entity. In this way, a very effective dealing with congestion situations is possible.

The method according to the invention could be beneficially used to control an amount of bandwidth consumed, to fix/limit encoding rates, to provide fairness during times of congestion and/or to provide higher QoS levels for preferred subscribers. The inventive method can be applied within a wide field of applications in an advantageous way. For example, the application could be a voice and/or video application. Regarding a further preferred application the network could comprise a DSLAM (Digital Subscriber Line Access Multiplexer), a femtocell or smallcell, e.g. 2G/3G/LTE/WiFi, or a macro-cellular base station, e.g. 2G BTS, 3G NodeB, LTE eNodeB, or WiMAX BS or WLAN AP.

Under consideration of preferred embodiments the present invention describes a method and apparatus to enable in-network control of end-to-end applications which incorporates adaptation of voice and video applications, e.g. AMR, H.264. Specifically, the invention allows the network to control the source encoding rates of endpoint applications through a combination of in-network modification of in- band or out-of-band signalling information/messages containing source encoding rate modification requests and dynamic oppression of congestion notification events, e.g. ECN, to prevent independent endpoint adaptation. It provides a mechanism to allow a network operator to provide differentiated levels of service to different subscribers sharing a common link. The method allows the network to control the exact source encoding rate chosen by each endpoint and can prevent any potential oscillation between encoding rates due to the independent adaptation decisions made by each application endpoint. An in-network node continually monitors signalling flows and network congestion indications between two endpoints. During periods of congestion and based on operator defined policies the network can decide to provide different levels of QoS to various groups of subscribers and mitigate congestion in a controlled manner rather than allowing independent endpoint adaptation from occurring. In order to override the endpoint adaptation the in-network node modifies the source encoding rate requests, e.g. CMR in AMR, in signalling messages between the two endpoints and modifies the congestion indication notifications, e.g. ECN-CE.

The method according to the present invention provides high level network centric control over the encoding rates and adaption mechanisms of media streams through in network modification of signalling messages. The advantage of this approach is that the network can control the source encoding rates of media sources regardless of the decisions made by the endpoints and the applications, and does not rely on the functionality available on the end nodes, e.g. if one endpoint entity does not support ECN, the network entity can pretend towards the other endpoint that ECN is supported. This method can be used to control the amount of bandwidth consumed, to fix/limit rates, to provide fairness during times of congestion and to provide higher quality levels for preferred subscribers. It can also prevent congestion from many media sources attempting to increase their source rate simultaneously. The present application documents describe a method for controlling application source rate encoding with a focus on voice call and video streaming in cellular networks including femtocell deployments. Source rate encoding changes can be controlled through "in network" modification of codec modification requests and congestion notifications between the application endpoints or by the end node, e.g. application endpoint or server, directly. For "in network" solutions, these changes can be controlled by a network entity that modifies in-band signalling information such as the Codec Mode Request (CMR) field of AMR/AMR-WB (Adaptive Multi-Rate/Adaptive Multi-Rate Wide-Band) frames or by modifying out- of-band signalling messages/information such as those contained in RTCP/RTSP (Real Time Control Protocol/Real Time Stream Protocol) feedback messages.

The method can target individual voice or video flows but a more realistic approach is to modify all flows or sets of flows to provide fairness, load balancing and increase capacity. This could be based on a number of factors including operator defined policies based on user subscriptions or by grouping sets of users based on their link quality between the UE and the network access point, e.g. eNodeB, Femtocell.

In the voice case the method applies to transmitting CS (Circuit Switched) voice through an IP network or transmitting packet switched VoIP (Voice over IP) over an IP network for macro and femtocell deployments including Multimedia Telephony Service for IMS (MTSI). The proposed approach can aid to improve fairness, overall voice and video quality and increase capacity during bandwidth limited or capacity constraint scenarios. Likewise, the method can be used to increase the codec rates in a controlled manner when there is sufficient resources available, e.g. after a peak hour. Important aspects of the invention can be summarized as follows:

1 ) Network centric policy based control of adaptive audio/video encoding, e.g. for AMR, rates based on: a. monitoring of congestion notifications, e.g. ECN/CE, b. selective requests for encoding changes, e.g. based on CMR, and

c. controlled oppression of congestion notifications, e.g. ECN/CE.

1.1 ) The policy-based control can be centralised on a single entity in the network, e.g. a Femto GW (Gateway), SGSN/S-GW (Serving GPRS (General Packet Radio Service) Support Node/Serving Gateway) or GGSN/P-GW (Gateway GPRS (General Packet Radio Service) Support Node/Packet Data Gateway).

1.2) The policy-based control can be distributed across different network elements, e.g. Femto cell and Femto GW, or GGSN/P-GW.

1.3) The policy-based control can be provided by an end node, e.g. a video streaming server.

2) The policy-based control can take into account subscription information in a way that users with a "better" subscription are treated favorably, e.g. their audio/video encodings would only be reduced once the audio/video encoding of users with a "worse" subscription have been reduced and the overload/congestion situation remains.

3) An intermediate node between two application endpoints can detect congestion by monitoring ECN and CE flags in passing packets. When congestion is detected the intermediate node can change the congestion notifications to hide the congestion from either endpoint and prevent terminal/client controlled source adaptation, but rather trigger the rate adaptation from the network - based on (operator) policies. 4) An end node acting as a server or sending node towards a client can detect congestion by monitoring ECN and CE flags in received packets. When congestion is detected the end node can change the congestion notifications to hide the congestion from the correspondent node and prevent client controlled source adaptation, but rather trigger the rate adaptation from the server side - based on (operator) policies.

Note: Hiding the congestion from endpoints can prevent uncontrolled and distributed simultaneous source encoding changes that occur when many endpoints share the same congested link. This also prevents the congestion from reappearing due to the simultaneous increasing of source encoding rates that would occur when the initial congestion notifications are cleared.

5) When congestion is detected, the intermediate node can "downgrade" the encoding for a set of users (random or based on subscription information). If the congestion continues the set of downgraded users can be expanded until congestion is resolved. Alternatively all users can be downgraded immediately and when the congestion is resolved then specific sets of users, e.g. high priority users first, can slowly have their encoding rates increased in a controlled manner by the intermediate node.

Advantages of the invention together with embodiments include:

• Provides a network/service-side mechanism for application source encoding rate (e.g. AMR) control and QoS differentiation for various subscriber groups.

• Mitigate the potential ping pong effect from distributed codec modifications between terminals transmitting over a shared IP link. • Compatible with all endpoint controlled adaptation mechanisms including those of AMR and AMR-WB for CS calls over femto and MTSI clients.

• Does not require any support from the UE.

• Existing in network CMR modifications are per call and based on using the ECN at each endpoint leading to independent and distributed codec modification which has the potential to cause a ping pong between encoding rates.

• Can be applied to a large number of calls simultaneously for fairness and capacity maximization.

• Provides a mechanism to hide network congestion from terminals/clients in order to prevent uncontrolled source rate encoding changes by the terminals/clients.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end, it is to be referred to the patent claims subordinate to patent claim 1 on the one hand and to the following explanation of preferred examples of embodiments of the invention, illustrated by the drawing on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will we explained. In the drawings

Fig. 1 is showing a generalized flowchart of an algorithm decision process at an embodiment of a network entity according to the invention,

Fig. 2 is showing an example of a CMR modification according to the invention,

Fig. 3 is showing a further example of a CMR modification according to the invention and Fig. 4 is showing an embodiment of a network according to the invention.

Fig. 1 shows a generalized flowchart of the algorithm decision process at a network entity, e.g. an intermediate network node. The proposed method involves modification/oppression of the ECN/ECN-CE notifications and in/out of band codec adaption requests as they pass through a network entity such as a femtocell gateway, see Fig. 4. It is to be noted that in case of a service-side solution implemented on an end node, e.g. a video streaming server, the network entity and correspondent node, i.e. the FGW and UE2, would simply be co-located - as a result, the server would then directly adapt the source encoding rate without explicit signalling via a in-band or out-of-band means. The network entity according to Fig. 1 monitors ongoing flows and can modify both the uplink and downlink encoding rate using the existing in-band signalling mechanism, for example CMR/RTCP-APP in AMR, or RTCP/RTSP signalling for video. The network entity can also modify both the ECN bits and CE bits at the IP packet level and/or in upper layer protocols to prevent each terminal automatically modifying their encoding rates in an uncoordinated and distributed manner.

In order to further clarify the invention an AMR voice adaptation example is provided in Fig. 2 and Fig. 3. These show the mechanisms response to congestion appearing between the UE and the in-network node and after the in-network node, respectively.

In order to modify the source encoding rate in the uplink direction it modifies the CMR field or RTCP field of all frames being transmitted in the opposite direction. On reception of the modified voice frame the uplink node will modify the source encoding rate according to the normal mandatory AMR codec operation. The network entity must continually monitor the CMR being requested by the downlink node and modify it when necessary in order to maintain the desired source encoding rate at the uplink node. Furthermore, the network entity must also continually monitor and modify the ECN and CE flags to prevent each terminal from automatically responding to the congestion. The method allows the network entity, e.g. Femtocell or Femtocell Gateway (FGW), to dynamically modify the codec rates without requiring any support in user terminals. This allows fine granular control over each terminal's data rate and can prevent problems that may be encountered by automatic and distributed codec modifications at each terminal.

Based on factors, e.g. subscriber policy, the intermediate node seamlessly modifies the CMR field of the voice frame or RTCP in the case of MTSI, this results in the UE receiving this voice frame or RTCP message to modify its uplink encoding rate. There are a number of reasons as to why this may be desirable, for example it allows the network to control the encoding rates of all UEs regardless of what codec rate is being requested by either node involved in the voice call. This provides a mechanism to implement a fairness mechanism among all users and/or differentiation among users based on subscription information.

Embodiment 1 :

Many DSLAMs have limited capacity support for voice traffic. The reason for this is that all voice traffic is placed in the limited EF (Expedited Forwarding) queue, once this queue is full packets are dropped resulting in decreased QoS for end users. As the number of VoIP capable terminals or femtocell deployments increase, thereby increasing the amount of voice traffic, this may become a bottleneck. Furthermore, ISPs (Internet Service Provider) may begin charging for, or limiting the amount of femtocell traffic that can be transmitted through each DSLAM. The proposed mechanism allows the network operator to control the encoding rate of all voice calls thereby reducing load in the DSLAM, increase voice call capacity, provide fairness between femtocell users and maximize QoS during periods of high traffic density. Furthermore, it also allows the network operator to control the traffic volume passing through the third party network while minimizing the call blocking probability, see Fig. 4. Embodiment 2:

There are many scenarios in which a large number of voice calls share a common link, for example in femtocell deployments. When this link becomes congested ECN will be set on all/certain IP packets until the congestion is cleared. This will result in each terminal performing independent codec modification in an effort to reduce the congestion. As this mechanism is distributed and performed at each terminal the network operator has no way to control which terminals reduce their data rates. It would be desirable for the operator to be able to specify a subset of terminals to reduce their data rates or indeed to force specific terminals to not reduce their encoding rates and thereby maintain higher call quality. A typical example of this would be having sets of customers with different service subscriptions, e.g. Gold, Silver, Bronze levels; that is subscribers which have differentiated levels of services such that gold subscribers receive the highest level of service and bronze users the lowest. In this scenario individual subscriber groups can be forced to use different data rates with Gold subscribers being provided the best quality. Furthermore, when congestion occurs rather than all terminals reducing their call quality, the operator may want only the bronze users to reduce their quality. If this does not alleviate the congestion the silver users can then be reduced and the gold users are only reduced if the previous two steps do not reduce the congestion. The proposed mechanism allows the operator to implement these types of policies at the FGW or indeed another intermediate node. Embodiment 3:

During busy periods base stations, e.g. (e)NBs or WiMAX, may become overloaded at either the radio link or backhaul link; a typical solution to this is to simply reject any further calls until some of the congestion is alleviated and resources become available to admit more calls. The mechanism proposed here can allow the (e)NB to support an increased number of calls by reducing the encoding data rates of ongoing voice calls. Once again it may be desirable for the MNO (Mobile Network Operator) to provide higher levels of quality to specific sets of subscribers, e.g. Gold subscribers. As such the (e)NB can increase the call capacity by reducing the encoding data rates of specific subscribers while maintaining high quality for others. This can be used to lower the call blocking probability at the expense of reducing call quality for certain subscribers.

Embodiment 4:

Separate from the specific case of voice considered previously, there are also other embodiments. The same mechanism of blocking and hiding the congestion notification messages from the application endpoints can also be used in other applications which perform dynamic source encoding and make modifications due to changes in network conditions. Both streaming and interactive video sessions are such applications and can also leverage the proposed mechanism to prevent video degradation for specific users. In this case the intermediate node would potentially be required to modify congestion indications that are either included inside the transport or application headers of the packets (in-band) or in other control plane protocols such as extended RTCP (out-of-band); as such the intermediate node may be required to understand the internal structure of such video codecs.

Important aspects of the invention together with embodiments include:

1 ) Network controlled oppression and modification of congestion notifications and codec modification requests between two endpoints.

2) Enables network/service-side policy based control of adaptive voice/video encoding rates.

3) Mitigates the potential ping pong effect from distributed codec modifications between terminals transmitting over a shared IP link due to frequent codec state changes [3GPP TS 26.1 14 - V1 1.0.0 (201 1 -06)].

4) Allows controlled and graceful response to network congestion. 5) Provide differentiated levels of QoS for different subscriber groups particularly during periods of congestion.

6) No UE support required.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. A method for controlling the encoding rate of data traffic of an application between two endpoints within a network,

c h a r a c t e r i z e d in that a network entity monitors ongoing data traffic or flows between the two endpoints and - based on a definable policy and/or information - controls or modifies an uplink and/or downlink encoding rate at one or both endpoints.

2. A method according to claim 1 , wherein the network entity monitors signalling information or messages related to the application and/or monitors network congestion indications.

3. A method according to claim 2, wherein the network entity monitors ECN (Explicit Congestion Notification) and CE (Congestion Experienced) flags or bits within the data traffic or flows.

4. A method according to one of claims 1 to 3, wherein the network entity modifies at least one encoding data request in a signalling information or message between the two endpoints.

5. A method according to claim 4, wherein the network entity modifies the CMR field of AMR/AM R-WB frames.

6. A method according to one of claims 1 to 5, wherein the network entity modifies, e.g. sets or oppresses, at least one congestion indication notification.

7. A method according to one of claims 1 to 6, wherein the network entity modifies in-band or out-of-band signalling information or messages.

8. A method according to one of claims 1 to 7, wherein the network entity is centralised on a single entity in the network.

9. A method according to one of claims 1 to 7, wherein the network entity is distributed across different network elements.

10. A method according to one of claims 1 to 7, wherein the network entity and one endpoint are co-located or the network entity is provided by an endpoint.

1 1. A method according to one of claims 1 to 10, wherein the network entity - at random or based on definable subscription information or policies - provides different levels of service or QoS (Quality of Service) to different subscribers or groups of subscribers sharing a common link within the network, preferably during periods of congestion.

12. A method according to one of claims 1 to 1 1 , wherein a set of subscribers whose service level is downgraded due to congestion will be expanded until congestion is resolved or reduced to a definable threshold.

13. A method according to one of claims 1 to 1 1 , wherein during periods of congestion the service level of all subscribers will be downgraded and if congestion is resolved or reduced to a definable threshold, then definable subscribers or sets of subscribers will slowly have increased their encoding rate up to a definable encoding rate by the network entity.

14. A method according to one of claims 1 to 13, wherein the method will be used to control an amount of bandwidth consumed, to fix/limit encoding rates, to provide fairness during times of congestion and/or to provide higher QoS levels for preferred subscribers.

15. A method according to one of claims 1 to 14, wherein the application is a voice and/or video application.

16. A method according to one of claims 1 to 15, wherein the network comprises a DSLAM (Digital Subscriber Line Access Multiplexer), a femtocell or smallcell or a base station, e.g. 2G BTS, 3G NodeB, LTE eNodeB, WiMAX BS or WLAN AP.

17. A network, preferably for carrying out the method according to any one of claims 1 to 16, wherein the encoding rate of data traffic of an application between two endpoints within the network will be controlled,

c h a ra cte r i z e d by a network entity for monitoring ongoing data traffic or flows between the two endpoints and - based on a definable policy and/or information - for controlling or modifying an uplink and/or downlink encoding rate at one or both endpoints.