Abstract:
A method of managing congestion in a packet switched access network. The method is performed within a packet core network providing a transit network for a user media stream sent from a sending device via the packet switched access network. Actual or potential congestion in the packet switched access network associated with said user media stream is identified. In response to such identification, the sending device is notified of the actual or potential congestion by inserting a notification of congestion into control signalling of the media stream.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to IP media rate adaptation in respect of end-users in radio access networks. 
       BACKGROUND 
       [0002]    3GPP standards specify Radio Access Network architectures and functionality to allow end-users to access mobile network services. In particular, 3GPP specifies an architecture and functionality that allows users to access high speed and high bandwidth uplink and downlink data services. However, the radio environment for an end-user will inevitably vary due to, for example, the movement of the user and the served load in the cell currently serving the end-user and in other neighbouring cells. This results in the served bit rate to the end-user also varying. This is particularly problematic for the uplink direction which typically has a lower bandwidth than the downlink direction. To address the problems caused by a fluctuating served bit rate for the end-user in question, and for other users and the network, it is desirable to allow for dynamic adaptation of the media bit rate. 
         [0003]    For most IP services, the bit rate of transmitted media is controlled by the sender of the media, generally with feedback from the receiver of the media. For example, a common implementation of bit rate control is monitoring packet losses at the receiver, and communicating the packet losses to the sender. If the packet losses reach an unacceptable value, the sender can reduce the bit rate of the transmission to compensate. The main problem with such solutions is that the adaptation of the bit rate occurs after the connection problems have occurred, and the packet losses may have already caused delays or a significant reduction in service quality. 
         [0004]    Explicit Congestion Notification (ECN) was developed to allow the transport infrastructure to be part of the congestion handling solution. The basic principle, as shown in  FIG. 1 , is that equipment on the path taken by the packets, such as routers, which start to experience rising congestion can set an “ECN bit” on packets passing through the equipment before the congestion reaches a level where service is unacceptably affected. The ECN bit is received by the receiving device  202 , which then notifies the sending device  201 . This allows the sending device  201  to adapt its sending rate such that packet loss is avoided rather than reacting when packet loss starts to appear. If the receiving device  202  does not support ECN, then it will not notify the sending device  201  that the ECN bit has been received, and so the sending device  201  will not adjust the sending rate until a reduced quality of service (e.g. packet loss) occurs. 
         [0005]    ECN was first defined for TCP/IP traffic. In the TCP/IP implementation, the ECN bit values set by the transport infrastructure are detected by the receiving device  202 . The receiving device then includes a congestion notification in the TCP ACK message returned to the sending device  201 . In this way, the sending device  201  is notified about the congestion, and can modify the transmission accordingly. 
         [0006]    Real-time media, for example voice calls, video calls, and video streaming, is commonly sent using the RTP (Real-time Transport Protocol)/UDP/IP protocol suite. ECN has been defined for this protocol suite in IETF RFC 6679. ECN is particularly useful in this implementation as the media stream is typically so sensitive to delays that it is not possible to wait for packets to be resent. Packet loss is especially detrimental to media streams, as a single lost packet containing an I-frame in an MPEG stream will cause the picture to become garbled until a new I-frame is transmitted. 
         [0007]    In the RTP/UDP/IP implementation of ECN, the ECN bits are set by the transport infrastructure in the packet header in a similar way as in the TCP/IP implementation. The primary difference is that the acknowledgement to the sender is done using RTCP (RTP Control Protocol) packets. Unfortunately, the ECN specification for RTP/UDP/IP was defined late, and as such it is not widely supported in user terminals. 
         [0008]    The 3GPP specification 3GPP TS 26.114 specified the use of ECN for RTP/UDP, but only in the isolated case of multimedia telephony over mobile broadband networks, and only as an optional function. As such, this is also not widely supported. The solution is substantially the same as the solution specified by the IETF. 
         [0009]    There is therefore a need to provide a solution for congestion control which does not depend on the sending and receiving end points having specific functionality. 
       SUMMARY 
       [0010]    According to a first aspect of the present invention, there is provided a method of managing congestion in a packet switched access network. The method is performed within a packet core network providing a transit network for a user media stream sent from a sending device via the packet switched access network. Actual or potential congestion in the packet switched access network associated with said user media stream is identified. In response to such identification, the sending device is notified of the actual or potential congestion by inserting a notification of congestion into control signalling of the media stream. 
         [0011]    According to a second aspect of the present invention, there is provided an apparatus configured to act as a node configured to manage congestion in a packet switched access network. The apparatus comprises a congestion detector and a rate controller. The congestion detector is configured to identify actual or potential congestion in the packet switched access network associated with said user media stream sent from a sending device via the packet switched access network. The rate controller comprises a control signalling receiver, a signalling modifier, and a control signalling sender. The control signalling receiver is for receiving the control signalling of the media stream. The signalling modifier is for modifying the signalling to include a notification of congestion in response to the congestion detector identifying actual or potential congestion. The control signalling sender is for sending the modified signalling towards the sending device. 
         [0012]    According to a third aspect, there is provided a computer program comprising computer readable code which, when run on an apparatus, causes it to behave as an apparatus according to the second aspect. The computer program may be stored in a computer program product comprising a non-transitory computer readable medium. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]      FIG. 1  illustrates the basic functioning of the ECN system; 
           [0014]      FIG. 2  illustrates an example network structure according to an embodiment; 
           [0015]      FIG. 3  illustrates schematically a Rate Adaptation Control Function according to an embodiment; 
           [0016]      FIG. 4  illustrates schematically a Rate Adaptation Control Function according to an embodiment; 
           [0017]      FIG. 5  is a flowchart showing a method according to an embodiment; and 
           [0018]      FIG. 6  illustrates possible nodes for implementation of the Rate Adaptation Control Function. 
       
    
    
     DETAILED DESCRIPTION 
       [0019]      FIG. 2  shows an example network structure according to an embodiment. A new Rate Adaptation Control Function (RACF)  100  is added into operator  1 &#39;s network. The RACF  100  receives information about the current congestion in the network  5 , and then indicates to the sending device  201 , based on certain rules, how the sending rate should be adjusted. The RACF  100  is positioned in the path of the packets of the media stream and the control stream ( 1  to  2  and  4  to  3 ) so that it can provide indications to the sending device  201  by modifying the packets of the control stream. The RACF  100  may also monitor the packets of the media stream, e.g. to determine the bit rate of the stream or to check for ECN bits. The indications to the sending device  201  can either be explicit about the reduction in sending rate required, or send an indication of the level of congestion, e.g. how many packets with ECN bits have passed through the RACF  100 . 
         [0020]    The structure of the RACF  100  is shown in  FIGS. 3 and 4 , and its operation is shown in  FIG. 5 . The RACF  100  comprises a Congestion Detector (CD)  101  and a Rate Controller (RC)  102 . The RACF  100  may also comprise a Rate Estimator (RE)  103 . RTP packets sent between the sending device  201  and the receiving device  202  flow past or through the RACF  100  unmodified, while RTCP packets are routed via the RC  102  so that the RC  102  may add, modify or remove packets. 
         [0021]    The access network sends notifications of congestion S 1  which are then received S 2  by the CD  101 . These indications may include ECN bits in the RTP/UDP/IP messages, or some other indication communicated to the CD  101  by the RTP media stream  1  or some other means  5 . The congestion indications may be in the packet stream, in which case the CD  101  comprises a media stream receiver  1011  and a packet inspector  1012 , or they may be sent separately, in which case the CD  101  comprises a congestion indication receiver  1013 . If congestion is detected, then the CD  101  triggers the RC  102 , which adds or modifies an RTCP message towards the sending device  201 , to cause it to reduce the sending rate. The RC  102  comprises a control signalling receiver  1021  for receiving the control signalling of the media stream, a signalling modifier  1022  for modifying the control signalling to cause the sending device to reduce the sending rate S 5 , and a control signalling sender  1023  to send the modified signalling to the sending device S 6 . 
         [0022]    The RTCP message used may include:
       Sender report/Receiver report (SR/RR)   Extended Report (ER)   ECN Feedback Message   Temporary Maximum Media Stream Bit Rate Request (TMMBR) [As described in 3GPP TS 26.114]   Application-defined RTCP packet (RTCP APP) containing codec control requests and/or media rate requests.       
 
         [0028]    In the case where the RC  102  sends a TMMBR or RTCP APP message, the required bit rate and/or codec will be indicated in the message. The RE  103  may be used to monitor the bit rate and/or codec used for the RTP media stream S 3 , which can be communicated to the RC  102  to allow the RC  102  to determine the bit rate and/or codec which should be used to reduce the congestion in the access network S 4 . The required bit rate and/or codec may also be based on internal policies and/or congestion information from the CD  101 . 
         [0029]    The TMMBR message is described in 3GPP TS 26.114. This message must be understood by all mobile telephones implementing video calling over an LTE or HSPA radio access network, as required by GSMA PRD IR.94 v5.0 “IMS Profile for Conversational Video Service”. The message would normally be sent by the receiving device when packet loss and/or congestion are detected. Where a TMMBR message is used, the sending device  201  will respond with a Temporary Maximum Media Stream Bit Rate Notification (TMMBN) message. The RC  102  may be configured not to forward this message to the receiving device. 
         [0030]    If the sending device has support for ECN, then the RC  102  may send the ECN feedback messages as described in the background. In this case, the RC  102  does not indicate a required bit rate and/or codec; it only informs the sending device  201  how many ECN marked packets have been detected by the CD  101 . Alternatively, the CD  101  may be informed of congestion in the access network without the access network setting ECN bits, in which case the RC  102  may respond as if packets sent during the congestion had been marked with ECN bits. 
         [0031]    The RC  102  may instead use the ordinary SR/RR RTCP messages to indicate the congestion situation. These messages do not contain ECN feedback, but the RC  102  may insert messages which indicate packets have been lost so that rate control is triggered on the sending device. These messages may be inserted even if there are in fact no lost packets, to ensure that rate control is triggered before the congestion begins to reduce quality of service. This information may be added to SR/RR messages which are sent from the receiving device. 
         [0032]    The CD  101  may detect congestion in multiple ways. The CD  101  could detect ECN bits on packets travelling through the network. Alternatively, the CD  101  could have an interface  5  to the access network, through which the access network informs the CD  101  of the current load/congestion level, or of an allowed rate for a certain service. The allowed rate could be either a total rate, a required reduction in the bit rate, or a percentage of the current rate. 
         [0033]    The CD  101  may subscribe to updates from the access network over the interface  5 . Alternatively, the CD  101  may request a congestion indication based on some internal trigger. This trigger may be a sudden drop in packet throughput, packet losses, and/or regular updates. 
         [0034]    If the CD  101  is informed of the current congestion level, then the RC  102  requires logic to compute an allowed rate (in the case where the RC  102  reports by TMMBR or RTCP APP) or the congestion level to report to the sending device (in the case where the RC  102  reports by ECN feedback message, SR or RR). This computation may take into account the current bit rate or codec in use for the session (as reported by the RE  103 ). The RE  103  may obtain this information from the control plane (e.g. from the SDP in the session negotiation). The rate can also be estimated by measuring it in the RTP user plane flow  1 - 2  or by the context in the RTCP Sender Reports for the session. 
         [0035]    The RACF may be implemented as either a stateless RACF or a stateful RACF. 
         [0036]    A stateless RACF would not keep a state for the RTP sessions passing through the RACF, but only act on a specific congestion trigger. The stateless RACF is therefore unaware of the current rate, and so can only inform the sender of congestion, or suggest a relative reduction in rate. For example, the stateless RACF may be configured to send an RTCP SR/RR indicating packet loss to the sender (as described above) in response to detecting ECN bits in RTP packets for a session. As a further example, the RACF may be configured to send an RTCP APP packet indicating a percentage bit rate reduction required for a specific service in response to the access network indicating congestion. 
         [0037]    If the stateless RACF is informed of the current bit rate (or codec mode), for example by an interface to the control pane of the access network, then it can calculate the required bit rate and use a TMMBR or RTCP APP message to communicate this to the sending device. 
         [0038]    The stateful RACF can measure the bit rate itself, and therefore use any of the response messages indicated above. However, since the stateful RACF is required to keep a state for the session, it should either be placed above the mobility anchor point, or protocols must be put in place to transfer the state to another RACF in case of a handover. 
         [0039]    The RACF  100  may be implemented as a stand-alone node, which is in the path taken by the packets of the media stream. The CD  101 , RC  102  and RE  103  of the RACF  100  may be implemented in different nodes. Alternatively, the RACF  100  may be integrated with existing nodes of the mobile network. This may be a node on the path of the packets sent from the sending device (other than the sending  201  or receiving  202  device). Examples of nodes in which the RACF may be implemented are shown in  FIG. 6 . For a stateful RACF, possible nodes include the P-GW or border control gateway. For a stateless RACF (or a stateful RACF with handover protocols implemented), possible nodes include those for the stateful RACF, as well as the S-GW or basestation, NodeB or eNodeB. 
         [0040]    If the CD  101 , RC  102 , and RE  103  are implemented in different nodes, the RC  102  has the same restrictions as the single-node RACF above, the CD  101  and RE  103  may be implemented anywhere provided that the RE  103  can monitor the packets of the media stream, and the CD  101  can communicate with the access network and/or monitor the packets or copies of the packets. 
         [0041]    Although the invention has been described in terms of preferred embodiments as set forth above, it should be understood that these embodiments are illustrative only and that the claims are not limited to those embodiments. Those skilled in the art will be able to make modifications and alternatives in view of the disclosure which are contemplated as falling within the scope of the appended claims. Each feature disclosed or illustrated in the present specification may be incorporated in the invention, whether alone or in any appropriate combination with any other feature disclosed or illustrated herein.