WO2014064496A1

WO2014064496A1 - Method of performing stream thinning and explicit congestion notification in combination

Info

Publication number: WO2014064496A1
Application number: PCT/IB2013/002229
Authority: WO
Inventors: Hua Chao
Original assignee: Alcatel Lucent
Priority date: 2012-10-22
Filing date: 2013-09-23
Publication date: 2014-05-01
Also published as: CN103780954A; TW201427452A; CN103780954B

Abstract

The invention provides a method of performing stream thinning and explicit congestion notification in combination for a scalable-based video service. With a preferred technical solution of the invention, ECN and stream thinning can be applied in combination to a scalable-based video service, and a reliable explicit congestion notification and/or periodical explicit congestion notification summary report can be generated. Thus an RTP receiver can achieve a good effect of code rate or congestion control upon reception of the explicit congestion notification and/or periodical explicit congestion notification summary report. And ECN of the invention can be performed also taking into account temporal variability over a radio network. Moreover in the invention a network device can set different congestion events for the same scalable-based video service as needed, which will also be very beneficial to accurate congestion control performed at the RTP sender.

Description

Method of Performing Stream Thinning and Explicit Congestion Notification in Combination

Field of the invention

The present disclosure relates to the field of mobile communications and particularly to a method of performing stream thinning and explicit congestion notification in combination for a scalable-based video service.

Background of the invention

In the document IETF RFC 3168(09/2001) "The Addition of Explicit

Congestion Notification (ECN) to IP", it is proposed Explicit Congestion Notification (ECN) in which when incoming congestion is identified, this will be indicated in an IP data packet which would otherwise have been discarded directly. Specifically an ECN field is set in a header of the IP data packet. As illustrated in Fig.l , the ECN field includes two bits which are an ECN-Capable Transport (ECT) bit and a Congestion Experienced (CE) bit. When a sender sets these two bits to 00, respective routers will be instructed not to use ECN. When the sender sets these two bits to 01 or 10, the respective routers will be instructed to use ECN, and prior to this, of course, there is also an initialization procedure between the sender and a receiver to determine whether ECN is supported by a transmission path between them. When a router over the transmission path between them changes the bits from 01 or 10 to 11 , it indicates the presence of congestion over a network, so that upon reception of the IP packet carrying the IP data header with 11 , the receiver will generate and send an explicit congestion notification feedback report to the sender.

On the other hand, an application scalable video-coding video service or an application multi-view video-coding video service is generally transmitted based upon a Real-time Transport Protocol (RTP) stream which is carried by the User Datagram Protocol (UDP).

At present, the Transmission Control Protocol (TCP), the Stream Control Transmission Protocol (SCTP) and the Datagram Congestion Control Protocol (DCCP) have been capable of supporting ECN. However, since the User Datagram Protocol (UDP) lacks a feedback mechanism, there remains a problem of how to apply ECN to an RTP stream which is carried by the UDP.

In view of the foregoing problem, in the document IETF RFC 6679 (08/2012) "Explicit Congestion Notification (ECN) for RTP over UDP", it is proposed a new feedback message carried by the RTP Control Protocol (RTCP), where by the value of a specific field a data packet of the message indicates that it includes an explicit congestion notification feedback report so that when the explicit congestion notification field in the received IP data packet is 11 , a congestion notification feedback report is instantly generated and sent to an RTP receiver. Moreover, there is further proposed a new extended report block transmitted by the RTCP, which is used to periodically transmit an explicit congestion notification summary report. And in the foregoing document, it is proposed to include the following parameters in these parameters: Extended Highest Sequence Number to indicate the highest RTP sequence number related to the report, ECT (0) Counter to count the number of RTP data packets with ECT (0), ECT (1) Counter to count the number of RTP data packets with ECT (1), ECN-CE Counter to count the number of RTP data packets with CE, non-ECT Counter to count the number of RTP data packets with non-ECT, Lost Packets Counter to count the number of lost RTP data packets, and Duplication Counter to count the number of RTP data packets, each of which is identical to a received RTP data packet. The definitions of the parameters to be included in the explicit congestion notification feedback report and the periodical explicit congestion notification summary report are merely presented in brief, and reference can be made to the foregoing document for details thereof.

For a scalable-based video service, stream thinning can also be applied, that is, a Media- Aware Network Element (MANE) will perform stream thinning on an RTP data packet based upon a congestion control principle. Fig.2 illustrates an implementation process of such stream thinning in the prior art. With stream thinning, one or more full RTP data packets or a part of an RTP data packet is removed, and header information of the RTP data packet(s) is modified dependent upon a particular situation. In the stream thinning process, a related network device over a transmission path, e.g., a router, etc., will also indicate incoming congestion by ECN. In this case, since the RTP receiver is not aware that the MANE has removed the one or more full RTP data packets, the RTP data packet(s) removed by the MANE will not be counted in calculation of the parameters, e.g., ECT (0) Counter, ECT (1) Counter and Lost Packets Counter, to generate the explicit congestion notification feedback report and/or the periodical explicit congestion notification summary report. Consequently, the explicit congestion notification feedback report and/or the periodical explicit congestion notification summary report, carried by the RTCP, fed back to the RTP sender will not be reliable any longer. Here, since these removed RTP data packets can be calculated to greatly assist the RTP receiver in achieving a good effect of code rate adaptation or congestion control, the reliability and the accuracy of the feedback report(s) will be lowered by not counting these RTP data packets. In summary, a reliable explicit congestion notification feedback report and/or periodical explicit congestion notification summary report is impossible in the prior art with an application of stream thinning.

Moreover, as video services, particularly scalable-based video services (e.g., application scalable video-coding video services and application multi-view video-coding video services), are being constantly proliferated, there has been a higher requirement imposed on the design of ECN. There remains a problem desirable to be addressed of how to perform ECN for a scalable-based video service in respective network devices over an RTP transmission path. Particularly, in 3GPP TS 36.300, va300 and E-UTRAN, it is proposed to have ECN as described hereinbefore applied to a base station to control an encoding/decoding rate, but no detailed implementation solution is suggested for this proposal. Thus, for example, how to perform ECN for a scalable-based video service in a base station and how a user equipment sends a feedback to an RTP sender are also problems desirable to be addressed.

Summary of the invention

As can be apparent, the existing solution as mentioned in the background of the invention can not ensure the reliability of an explicit congestion notification feedback report and/or a periodical explicit congestion notification summary report for a scalable-based video service in an application of stream thinning. And no definite solution has been given in the prior art to how to perform ECN for a scalable-based video service based upon an RTP stream carried by the UDP.

In order to address the problems in the prior art, according to a first aspect of the invention, there is proposed a method, in a network element, of performing stream thinning and explicit congestion notification in combination for a scalable-based video service, wherein the network element receives from an RTP sender the scalable-based video service, which is based on an RTP stream carried by the UDP, and a bit stream of the scalable-based video service includes a basic layer and one or more non-basic layers, and IP data packets of the scalable-based video service are transmitted through the basic layer and the one or more non-basic layers, and the method including the steps of: A. determining whether the stream thinning needs to be performed on RTP data packets in the IP data packets of the scalable-based video service on the one or more non-basic layers; B. when the stream thinning needs to be performed on the RTP data packets in the IP data packets of the scalable-based video service on the one or more non-basic layers, judging whether one or more full RTP data packets need to be removed; and C. when one or more full RTP data packets need to be removed, replacing the RTP data packet with a dummy RTP data packet, wherein the dummy RTP data packet reserves RTP header information of the RTP data packet, and all NAL units in a payload of the RTP data packet are replaced with a null NAL unit in the dummy RTP data packet.

Preferably, the scalable-based video service includes an application scalable video-coding video service or an application multi-view video-coding video service.

Preferably, when the scalable-based video service is the application scalable video-coding video service, the basic layer is a base layer of a bit stream of the application scalable video-coding video service, and the non-basic layer is an enhancement layer of the bit stream of the application scalable video-coding video service. When the scalable-based video service is the application multi-view video-coding video service, the basic layer is a base view of the application multi-view video-coding video service, and the non-basic layer is a non-base view of a bit stream of the application multi-view video-coding video service.

Preferably, the network element includes a media-aware network element and a base station, and when the network element is the media- aware network element, the method further includes the step of D: sending the IP data packets of the scalable-based video service which have been stream- thinned and/or which have not been stream- thinned to a network device over a network, and the network device includes a base station and a router.

According to a second aspect of the invention, there is proposed a method, in a network device, of performing stream thinning and explicit congestion notification in combination for a scalable-based video service, wherein the scalable-based video service is based on an RTP stream carried by the UDP, and a bit stream of the scalable-based video service includes a basic layer and one or more non-basic layers, and IP data packets of the scalable-based video service are transmitted through the basic layer and the one or more non-basic layers, and the method including the steps of: b. determining whether explicit congestion notification fields in IP data headers of the IP data packets need to be set to 11 , the IP data packets having or having not been stream-thinned according to a predetermined condition; c. when it is determined that the explicit congestion notification fields in the IP data headers need to be set to 11 , determining the numbers of non-basic layers for which the explicit congestion notification field in the IP data headers needs to be set to 11, and determining non-basic layers for which the explicit congestion notification fields in the IP data headers need to be set to 11 in a descending order according to the numbers of non-base layers; and d. for each non-basic layer for which the explicit congestion notification fields in the IP data headers need to be set to 11 , setting the explicit congestion notification field in the IP data header of at least one IP data packet in the non-base layer to 11, and generating an updated IP data packet.

Preferably ,the predetermined condition includes an available resource state, a buffer state, a channel quality and/or a link quality.

Preferably, the network device includes a base station and a router.

Preferably, before the step b, the method further includes step a of: a. receiving from a network the IP data packets of the scalable-based video service which have been stream-thinned by a media-aware network unit and/or which have not been stream-thinned by the media-aware network unit.

Preferably, the step d further includes: for each non-basic layer for which the explicit congestion notification fields in the IP data headers need to be set to 11 , setting the explicit congestion notification fields in the IP data headers of two or three consecutive IP data packets in time domain in the non-basic layer to 11 , and generating updated IP data packets.

Thus the loss of an IP data packet due to, for example, a time-varying radio channel can be avoided to thereby further ensure that the IP data packet carrying an IP data header with an explicit congestion notification field set to 11 can be sent reliably to an RTP receiver.

Preferably, the method further includes step e of: sending the updated and/or non-updated IP data packets of the scalable-based video service to an RTP receiver.

According to a third aspect of the invention, there is proposed a method, in an RTP receiver, of performing stream thinning and explicit congestion notification in combination for a scalable-based video service, wherein the scalable-based video service is based on an RTP stream carried by the UDP, and a bit stream of the scalable-based video service includes a basic layer and one or more non-basic layers, and IP data packets of the scalable-based video service are transmitted through the basic layer and the one or more non-basic layers, and the method including the steps of: XI . receiving from a network device the IP data packets of the scalable-based video service which have been updated by the network device and/or which have not been updated by the network device; X2. according to values of explicit congestion notification fields in IP data headers, counting the numbers of RTP data packets in the IP data packets per category for different values, and when RTP data packets in an IP data packet received from the network device are dummy RTP data packets, precluding the RTP data packets from video decoding, and counting the number of dummy RTP data packets; and X3. when the explicit congestion notification field in the received IP data packet is 11 , generating and sending to an RTP sender an explicit congestion notification feedback report carried by RTCP.

Preferably, when the explicit congestion notification field in the received IP data packet is 11, the step X3 further includes: X31. if the IP data packet is a first IP data packet with the explicit congestion notification field being 11 , recording a reception time of the IP data packet, and generating and sending to the RTP sender the explicit congestion notification feedback report carried by the RTCP; and X32. if the IP data packet is not the first IP data packet with the explicit congestion notification field being 11 , judging whether the IP data packet and a previously received IP data packet with the explicit congestion notification field being 11 belong to a same non-basic layer, and when they do not belong to the same non-base layer, recording a reception time of the IP data packet, and generating and sending to the RTP sender the explicit congestion notification feedback report carried by the RTCP, or when they belong to the same non-basic layer, judging whether the reception time of the IP data packet is below a sum of a reception time of the previously received IP data packet, belonging to the same non-basic layer, with the explicit congestion notification field being 11 and a round trip time between the RTP sender and the RTP receiver, and if not, then recording and updating the reception time, and generating and sending to the RTP sender the explicit congestion notification feedback report carried by RTCP, or if so, then only recording and updating the reception time.

Thus upon reception of an IP data packet carrying an IP data header with an explicit congestion notification field set to 11, the RTP receiver can determine that the IP data packet belongs to an existing congestion event or a new congestion event and send an explicit congestion notification feedback report only in the latter case to thereby avoid an unnecessary explicit congestion notification feedback report.

Preferably, the step X3 further includes: sending a periodical explicit congestion notification summary report carried by the RTCP to the RTP sender, and when the explicit congestion notification feedback report and a processing time thereof are above a predetermined time at which the periodical explicit congestion notification summary report is sent, precluding the explicit congestion notification feedback report from sending.

With the technical solution of the invention, ECN and stream thinning can be applied in combination to a scalable-based video service, and a reliable explicit congestion notification and/or a periodical explicit congestion notification summary report can be generated. Thus upon reception of the explicit congestion notification and/or the periodical explicit congestion notification summary report, an RTP receiver can achieve a good effect of code rate adaptation or congestion control. And ECN in the invention takes temporal variability in a wireless network into account. Moreover in the invention, a network device (e.g., a router and a base station) can set different congestion events for the same scalable-based video service as needed, which will also be very beneficial to accurate congestion control performed at the RTP sender.

The respective aspects of the invention will become more apparent from the following description of particular embodiments thereof.

Brief description of drawings

Other features, objects and advantages of the invention will become more apparent upon review of the following detailed description of non-limiting embodiments there of taken with reference to the drawings in which:

Fig.l illustrates a schematic diagram of four settings of an ECN field in an IP data header;

Fig.2 illustrates a flow chart of a method of performing stream thinning in the prior art;

Fig.3 illustrates a schematic diagram of a system of performing an explicit congestion notification for a scalable-based video service according to an embodiment of the invention;

Fig.4 illustrates a flow chart of a method of performing stream thinning in an MANE according to an embodiment of the invention;

Fig.5 illustrates a flow chart of a method of performing an explicit congestion notification for a scalable-based video service in a network device according to an embodiment of the invention;

Fig.6 illustrates a flow chart of a method of performing an explicit congestion notification for a scalable-based video service in an RTP receiver according to an embodiment of the invention;

Fig.7 illustrates a flow chart of an implementation of the step S603 in Fig.6 according to another embodiment of the invention;

Fig.8 illustrates a schematic structural diagram of an example of an IP data packet;

Fig.9 illustrates a structural diagram of an RTP dummy data packet according to an embodiment of the invention; or

Fig.10 illustrates a schematic diagram of determining a congestion event according to an embodiment of the invention.

Throughout the different figures in the drawings, identical or similar reference numerals denote identical or corresponding components or features.

Detailed description of embodiments

Fig.3 illustrates a schematic diagram of a system of performing an explicit congestion notification for a scalable-based video service according to an embodiment of the invention. Fig.4 illustrates a flow chart of a method of performing stream thinning in an MANE according to an embodiment of the invention. Fig.5 illustrates a flow chart of a method of performing an explicit congestion notification for a scalable-based video service in a network device according to an embodiment of the invention. Fig.6 illustrates a flow chart of a method of performing an explicit congestion notification for a scalable-based video service in an RTP receiver according to an embodiment of the invention.

The system in Fig.3 will be described below with reference to Fig.4 to Fig.6. As illustrated in Fig.3, the system includes an RTP receiver, a network element, a network device and an RTP receiver.

The RTP sender can be, for example, a video server. The network element can be, for example, a media-aware network element MANE and a base station. The network element can be, for example, a base station and a router. The RTP receiver can be, for example, a mobile terminal. The invention will be set forth below in Fig.3 in which the network element is an MANE and the network device is a base station by way of an example.

In another embodiment of the invention, the function of the MANE can alternatively be performed definitely at the base station side. Thus in this case, the system will include the RTP sender, the network device (e.g., a base station) and the RTP receiver.

Moreover, although a direct connection between the MANE and the network device is simply illustrated in Fig.3, those skilled in the art shall appreciate that the MANE can be connected with the network device via a number of network elements in other scenarios. Alike although the RTP sender is connected directly with the MANE, those skilled in the art shall appreciate that the RTP can be connected with the MANE via a number of network elements in other scenarios.

Here, we assume that an initialization procedure has been performed for the RTP sender and the respective elements in the network, that is, they have negotiated about and determined the use of ECN.

In operation, the RTP sender will initially send to the MANE a scalable-based video service based upon an RTP stream carried by the UDP. Fig.8 illustrates a schematic structural diagram of an example of an IP data packet. As illustrated in Fig.8, the IP data packet includes an IP data header, a UDP data header and one or more RTP data packets. Here the IP data header includes a 2-bit explicit congestion notification field (not illustrated).

In the invention, a bit stream of the scalable-based video service includes a basic layer and one or more non-basic layers, and IP data packets of the scalable-based video service will be transmitted through the basic layer and the one or more non-basic layers.

Here, the scalable-based video service can include but will not be limited to an application scalable video-coding video service or an application multi-view video-coding video service.

When the scalable-based video service is the application scalable video-coding video service, the basic layer refers to a base layer of a bit stream of the application scalable video-coding video service, and the non-basic layer refers to an enhancement layer of the bit stream of the application scalable video-coding video service.

When the scalable-based video service is the application multi-view video-coding video service, the basic layer refers to a base view of the application multi-view video-coding video service, and the non-basic layer refers to a non-base view of a bit stream of the application multi-view video-coding video service.

Now a method of performing stream thinning in the MANE will be described with reference to Fig.4. And in another embodiment of the invention, the method can alternatively be performed at the base station side.

In the step S401, the MANE determines whether the stream thinning needs to be performed on RTP data packets in the IP data packets of the scalable-based video service on the one or more non-basic layers

If no stream thinning needs to be performed, then the flow proceeds to the step S407. In the step S407, the MANE sends the IP data packets of the scalable-based video service that have not been stream-thinned to the network device over the network.

If the stream thinning needs to be performed on the RTP data packets of the scalable-based video service on the one or more non-basic layers, then the flow proceeds to the step S402. In the step S402, it is judged whether one or more full RTP data packets need to be removed.

When no one or more full RTP data packets need to be removed, that is, one or more NAL units in an RTP data packet need to be removed, then the flow proceeds to the step S405. In the step S405, the one or more NAL units in the RTP data packet are selectively removed, and RTP header information of the RTP data packet is updated. In the document IETF RFC 6190 (05, 2011) "RTP Payload Format for Scalable Video Coding", the update procedure has been described in details, and reference can be made to this document for details thereof.

When one or more full RTP data packets need to be removed, the flow proceeds to the step S406. In the step S406, the RTP data packet(s) to be removed is replaced with a dummy RTP data packet. Here, Fig.9 illustrates a schematic structural diagram of a dummy RTP data packet according to an embodiment of the invention. As illustrated in Fig.9, the dummy RTP data packet reserves RTP header information of the RTP data packet to be removed, and all NAL units in a payload of the RTP data packet to be removed are replaced with a null NAL unit in the dummy RTP data packet.

Here, fields in the null NAL unit can be set to F=0, NRI=3, Type=31 , Subtype=l , J=0, K=0 and L=0.

With the dummy RTP data packet, sequence numbers of the RTP data packets of the scalable-based video service will remain in a consecutive state prior to stream thinning to thereby prevent the RTP receiver from not counting the RTP data packet(s) which would have been removed, so an accurate explicit congestion notification feedback report and/or periodical explicit congestion notification summary report can be performed. On the other hand, this will still maintain an original intention and effect of stream thinning because all the original NAL units have been replaced with a dummy NAL unit.

Then the flow proceeds from both the step S405 and the step S406 to the step S407 in which the MANE sends the IP data packets of the scalable-based video service which have been stream- thinned and/or which have not been stream-thinned to the network device over the network. It shall be noted that the method will skip the step S407 in the case that the function of the MANE can alternatively be performed at the base station side.

Next a method of performing an explicit congestion notification for a scalable-based video service in the network device will be described with reference to Fig.5. As illustrated in Fig.5, in the step S501 , the network device receives, from the network, IP data packets of a scalable-based video service which have been stream- thinned by the MANE and/or which have not been stream-thinned by the MANE. It shall be noted that the method will skip the step S501 in the case that the function of the MANE can alternatively be performed at the base station side. That is, the base station will apply ECN directly to the scalable-based video service after performing stream thinning.

In the step S502, the network device determines whether explicit congestion notification fields in IP data headers of the IP data packets need to be set to 11, that is, indicate incoming congestion, according to a predetermined condition.

Here the predetermined condition can include an available resource state, a buffer state, a channel quality and/or a link quality.

When it is determined that no explicit congestion notification fields in the IP data headers need to be set to 11, then no IP data packets of the scalable-based video service need to be updated, and the method proceeds to the step S505. In the step S505, the IP data packets of the scalable-based video service which have not been updated are sent to the RTP receiver.

When it is determined that the explicit congestion notification fields in the IP data headers need to be set to 11 , then the method proceeds to the step S503.

In the step S503, the network device determines the numbers of non-basic layers for which the explicit congestion notification field in the IP data headers needs to be set to 11. Here, for example, the numbers of non-basic layers for which the explicit congestion notification field in the IP data headers needs to be set to 11 can be determined dependent upon the extent of incoming congestion of which the network device intends to notify the RTP sender. The number of non-basic layers means the number of congestion events, and this will result in a corresponding number of subsequent explicit congestion notification feedback reports of the RTP receiver. Furthermore a number of explicit congestion notification feedback reports will be generated for the same scalable-based video service. Thus the RTP sender will enforce rapid congestion control more precisely.

Moreover in the step S503, non-basic layers for which the explicit congestion notification fields in the IP data headers need to be set to 11 are further determined in a descending order according to the numbers of non-base layers.

Specifically, for an application scalable video-coding video service, a basic layer and an enhancement layer(s) of the application scalable video-coding video service are determined by { dependency_id, quality_id, temporal_id} located in header information of an NAL unit, where { 0, 0, x} represents the basic layer with x indicating an arbitrary value of temporal_id, and the other combinations represent enhancement layers. There is a higher value of dependency_id for an enhancement layer with a higher layer number. For enhancement layers with the same value of dependency_id, there is a higher value of quality_id for an enhancement layer with a higher layer number. For the same values of dependency_id and quality_id, there is a higher value of temporal_id for an enhancement layer with a higher layer number. Thus for the application scalable video-coding video service, the network device can determine enhancement layers for which the explicit congestion notification fields in the IP data headers need to be set to 11 in a descending order according to the foregoing principle

For an application multi-view video-coding video service, a non-basic view of the application multi-view video-coding video service is determined by {view_id} located in header information of an NAL unit, where there is a higher value of view_id for an enhancement layer with a higher layer number. Thus for the application multi-view video-coding video service, the network device can determine non-basic views for which the explicit congestion notification fields in the IP data headers need to be set to 11 in a descending order according to the foregoing principle.

In the step S504, for each non-basic layer for which the explicit congestion notification fields in the IP data headers need to be set to 11 , the explicit congestion notification field in at least one IP data header in the non-base layer is set to 11 , and an updated IP data packet is generated.

Specifically for the application scalable video-coding video service, the explicit congestion notification field in the IP data header of at least one IP data packet in each of the enhancement layers for which the explicit congestion notification fields in the IP data headers need to be set to 11 is set to 11 , and an updated IP data packet is generated.

For the application multi-view video-coding video service, the explicit congestion notification field in the IP data header of at least one IP data packet in each of the non-basic views for which the explicit congestion notification fields in the IP data headers need to be set to 11 is set to 11 , and an updated IP data packet is generated.

Preferably in this step, for each non-basic layer for which the explicit congestion notification fields in the IP data headers need to be set to 11 , the explicit congestion notification fields in the IP data headers of two or three consecutive IP data packets in time domain in the non-basic layer are set to 11, and updated IP data packets are generated. Thus an adverse influence due to, for example, a time-varying radio channel can be avoided.

Subsequently in the step S505, the network device sends the updated IP data packets of the scalable-based video service to the RTP receiver.

Next a method of performing an explicit congestion notification for a scalable-based video service in the RTP receiver will be described with reference to Fig.6. As illustrated in Fig.6, in the step S601 , the RTP receiver receives, from the network device, IP data packets of a scalable-based video service which have been updated by the network device and/or which have not been updated by the network device.

In the step S602, the RTP receiver, according to values of explicit congestion notification fields in IP data headers, counts the numbers of RTP data packets in the IP data packets per category for different values. Here RTP packets in each IP data packet will be counted upon reception of the IP data packet, that is, for RTP data packets in an IP data packet with an explicit congestion notification field being 00, 01 , 10 and 11 respectively, as illustrated in Fig. l , the RTP data packets will be counted cumulatively regardless of whether they are dummy RTP data packets or not so as to be used for an explicit congestion notification feedback and/or a periodical explicit congestion notification summary report, which are possibly to be sent. Specifically, the number of RTP data packets will be counted for the four parameters of ECT (0), ECT (1), ECN-CE and non-ECT. And in this step, when RTP data packets in an IP data packet received from the network device are dummy RTP data packets, the RTP data packets are precluded from video decoding, and the number of dummy RTP data packets is counted. Here the number of dummy RTP data packets is counted into the parameters of Lost Packets Counter and Duplication Counter.

In the step S603, when the explicit congestion notification field in the received IP data packet is 11, an explicit congestion notification feedback report carried by the RTCP is generated and sent to an RTP sender.

Here, Fig.7 illustrates a flow chart of an implementation of the step S603 in Fig.6 according to another embodiment of the invention. As illustrated in Fig.7, when the explicit congestion notification field in the received IP data packet is 11 , the RTP receiver judges whether the IP data packet is a first IP data packet with the explicit congestion notification field being 11 in the step S 1.

If so, then a congestion event is triggered, and the method proceeds to the step S3 in which the RTP receiver records a reception time of the IP data packet and generates and sends to the RTP sender the explicit congestion notification feedback report carried by the RTCP.

If not so, then the method proceeds to the step S2. In the step S2, the RTP receiver judges whether the IP data packet and a previously received IP data packet with the explicit congestion notification field being 11 belong to a same non-basic layer. For the application scalable video-coding video service, this judgment can be made by { dependency_id, quality _id, temporal_id} in the header of the NAL unit. For the application multi-view video-coding video service, this judgment can be made by {view_id} in the header of the NAL unit.

If they do not belong to the same non-basic layer, then a congestion event is triggered, and the method proceeds to the step S. In the step S3, the RTP receiver records a reception time of the IP data packet and generates and sends to the RTP sender the explicit congestion notification feedback report carried by the RTCP.

If they belong to the same non-basic layer, then the method proceeds to the step S4. In the step S4, the RTP receiver judges whether the reception time of the IP data packet is below a sum of a reception time of the previously received IP data packet, belonging to the same non-basic layer, with the explicit congestion notification field being 11 and a Round Trip Time (RTT) between the RTP sender and the RTP receiver.

If not so, then a congestion event is triggered, and the method proceeds to the step S5. In the step S5, the RTP receiver records and updates the reception time and generates and sends to the RTP sender the explicit congestion notification feedback report carried by the RTCP.

If so, then the method proceeds to the step S6. In the step S6, the RTP receivers records and updates the reception time.

Now the foregoing process will be described by way of an example. Fig.10 illustrates a schematic diagram of determining a congestion event according to an embodiment of the invention. As illustrated in Fig.10, upon reception a first IP data packet (with a sequence number of SN=N) with an explicit congestion notification field being 11 , the RTP receiver will trigger a congestion event, that is, the RTP receiver will generate and send to the RTP sender an explicit congestion notification feedback report carried by the RTCP, and here further recodes a reception time of the IP data packet as a reception time T_old associated with a non-basic layer x.

Thereafter, when a next new IP data packet SN=N+1 with an explicit congestion notification field being 11 is received and it is judged that this new IP data packet SN=N+1 with the explicit congestion notification field being 11 and the IP data packet SN=N belong to the same non-basic layer x, the RTP receiver will judge for a reception time of the IP data packet SN=N+1 whether the relationship T_new < T_old + RTT holds true. In this embodiment, this relationship holds true. Thus only T_new is recorded, and the value of T_old replaced with the value of T_new as a new reception time T_old associated with the non-basic layer x. And here no congestion event will be triggered, that is, no explicit congestion notification feedback report carried by the RTCP will be sent to the RTP sender.

Next as illustrated in Fig.10, the RTP receiver further receives of a new IP data packet SN=M with an explicit congestion notification field being 11 at a non-basic layer x-1 and judges that this new IP data packet SN=M with the explicit congestion notification field being 11 and the IP data packets SN=N and SN=N+1 do not belong to the same non-basic layer. In this case, a congestion event will be triggered, that is, the RTP receiver will generate and send an explicit congestion notification feedback report carried by the RTCP to the RTP sender. Here a reception time of the IP data packet SN=M is further recorded as a reception time T_old associated with the non-basic layer x-1.

Thereafter, when a next new IP data packet SN=M+1 with an explicit congestion notification field being 11 is received and it is judged that this new IP data packet SN=M+1 with the explicit congestion notification field being 11 and the IP data packet SN=M belong to the same non-basic layer x-1 , the RTP receiver will judge whether for a reception time of the IP data packet whether the relationship T_new SN=M+1 < T_old + RTT holds true. In this embodiment, this relationship holds true. Thus only T_new is recorded, and the value of T_new subsitutes the value of T_old as a new reception time T_old associated with the non-basic layer x-1. And here no congestion event will be triggered, and no explicit congestion notification feedback report carried by the RTCP will be sent to the RTP sender.

Preferably here the RTP receiver further sends a periodical explicit congestion notification summary report carried by the RTCP to the RTP sender and will not send the explicit congestion notification feedback report when the explicit congestion notification feedback report and a processing time thereof are above a predetermined time at which the periodical explicit congestion notification summary report is sent. Here the processing time refers to a period it takes for the RTP receiver to process the various parameters in the feedback report, a delay, etc.

Here when the explicit congestion notification feedback report and/or the periodical explicit congestion notification summary report is generated, the parameters of ECT (0), ECT (1), ECN-CE, non-ECT, Lost Packets Counter, Extended Highest Sequence Number, Duplication Counter, etc., will be processed and reported in the report(s).

Finally as illustrated in Fig.3, the RTP receiver will perform accurate congestion control in a congestion control algorithm upon reception of the explicit congestion notification feedback report and/or the periodical explicit congestion notification summary report.

It shall be noted that the foregoing embodiments are merely exemplary but not intended to limit the invention. Any technical solutions without departing from the spirit of the invention shall fall into the scope of the invention and include the use of different technical features appearing in different embodiments and the combination of an apparatus and a method to advantage. Moreover any reference numerals in the claims shall not be construed as limiting the claims in which they appear; and the "comprising" shall not preclude other devices or steps which are not listed in the claims or the description.

Claims

1. A method, in a network element, of performing stream thinning and explicit congestion notification in combination for a scalable-based video service, wherein the network element receives from an RTP sender the scalable-based video service, which is based on an RTP stream carried by UDP, and a bit stream of the scalable-based video service includes a basic layer and one or more non-basic layers, and IP data packets of the scalable-based video service are transmitted through the basic layer and the one or more non-basic layers, and the method comprising the steps of:

A. determining whether the stream thinning needs to be performed on RTP data packets in the IP data packets of the scalable-based video service on the one or more non-basic layers;

B. when the stream thinning needs to be performed on the RTP data packets in the IP data packets of the scalable-based video service on the one or more non-basic layers, judging whether one or more full RTP data packets need to be removed; and

C. when one or more full RTP data packets need to be removed, replacing the RTP data packet with a dummy RTP data packet, wherein the dummy RTP data packet reserves RTP header information of the RTP data packet, and all NAL units in a payload of the RTP data packet are replaced with a null NAL unit in the dummy RTP data packet.

2. The method according to claim 1 , wherein the scalable-based video service includes an application scalable video-coding video service or an application multi-view video-coding video service.

3. The method according to claim 2, wherein when the scalable-based video service is the application scalable video-coding video service, the basic layer is a base layer of a bit stream of the application scalable video-coding video service, and the non-basic layer is an enhancement layer of the bit stream of the application scalable video-coding video service; and when the scalable-based video service is the application multi-view video-coding video service, the basic layer is a base view of the application multi-view video-coding video service, and the non-basic layer is a non-base view of a bit stream of the application multi-view video-coding video service.

4. The method according to any one of claims 1 to 3, wherein the network element includes a media-aware network element and a base station, and when the network element is the media-aware network element, the method further comprises the step of D:

sending the IP data packets of the scalable-based video service which have been stream-thinned and/or which have not been stream-thinned to a network device over a network, and the network device includes a base station and a router.

5. A method, in a network device, of performing stream thinning and explicit congestion notification in combination for a scalable-based video service, wherein the scalable-based video service is based on RTP stream carried by UDP, and a bit stream of the scalable-based video service includes a basic layer and one or more non-basic layers, and IP data packets of the scalable-based video service are transmitted through the basic layer and the one or more non-basic layers, and the method comprising the steps of:

b. determining whether explicit congestion notification fields in IP data headers of the IP data packets need to be set to 11 , the IP data packets having or having not been stream-thinned according to a predetermined condition; c. when it is determined that the explicit congestion notification fields in the IP data headers need to be set to 11, determining the numbers of non-basic layers for which the explicit congestion notification field in the IP data headers needs to be set to 11, and determining non-basic layers for which the explicit congestion notification fields in the IP data headers need to be set to 11 in a descending order according to the numbers of non-base layers; and d. for each non-basic layer for which the explicit congestion notification fields in the IP data headers need to be set to 11 , setting the explicit congestion notification field in the IP data header of at least one IP data packet in the non-base layer to 11, and generating an updated IP data packet.

6. The method according to claim 5, wherein the predetermined condition includes an available resource state, a buffer state, a channel quality and/or a link quality.

7. The method according to claim 5, wherein the network device includes a base station and a router.

8. The method according to claim 5, wherein before the step b, the method further comprises step a of:

a. receiving from a network the IP data packets of the scalable-based video service which have been stream-thinned by a media-aware network unit and/or which have not been stream- thinned by the media-aware network unit.

9. The method according to claim 5, wherein the step d further comprises:

for each non-basic layer for which the explicit congestion notification fields in the IP data headers need to be set to 11, setting the explicit congestion notification fields in the IP data headers of two or three consecutive IP data packets in time domain in the non-basic layer to 11, and generating updated IP data packets.

10. The method according to claim 5, wherein the method further comprises step e of:

sending the updated and/or non-updated IP data packets of the scalable-based video service to an RTP receiver.

11. The method according to any one of claims 5 to 10, wherein the scalable-based video service includes an application scalable video-coding video service or an application multi-view video-coding video service.

12. The method according to claim 11 , wherein when the scalable-based video service is the application scalable video-coding video service, the basic layer is a base layer of a bit stream of the application scalable video-coding video service, and the non-basic layer is an enhancement layer of the bit stream of the application scalable video-coding video service; and

when the scalable-based video service is the application multi-view video-coding video service, the basic layer is a base view of the application multi-view video-coding video service, and the non-basic layer is a non-base view of a bit stream of the application multi-view video-coding video service.

13. A method, in an RTP receiver, of performing stream thinning and explicit congestion notification in combination for a scalable-based video service, wherein the scalable-based video service is based on RTP stream carried by UDP, and a bit stream of the scalable-based video service includes a basic layer and one or more non-basic layers, and IP data packets of the scalable-based video service are transmitted through the basic layer and the one or more non-basic layers, and the method comprising the steps of:

XI . receiving from a network device the IP data packets of the scalable-based video service which have been updated by the network device and/or which have not been updated by the network device;

X2. according to values of explicit congestion notification fields in IP data headers, counting the numbers of RTP data packets in the IP data packets per category for different values, and when RTP data packets in an IP data packet received from the network device are dummy RTP data packets, precluding the RTP data packets from video decoding, and counting the number of dummy RTP data packets; and

X3. when the explicit congestion notification field in the received IP data packet is 11 , generating and sending to an RTP sender an explicit congestion notification feedback report carried by RTCP

14. The method according to claim 13, wherein when the explicit congestion notification field in the received IP data packet is 11 , the step X3 further comprises:

X31. if the IP data packet is a first IP data packet with the explicit congestion notification field being 11 , recording a reception time of the IP data packet, and generating and sending to the RTP sender the explicit congestion notification feedback report carried by RTCP; and

X32. if the IP data packet is not the first IP data packet with the explicit congestion notification field being 11, judging whether the IP data packet and a previously received IP data packet with the explicit congestion notification field being 11 belong to a same non-basic layer, and when they do not belong to the same non-base layer, recording a reception time of the IP data packet, and generating and sending to the RTP sender the explicit congestion notification feedback report carried by RTCP, or when they belong to the same non-basic layer, judging whether the reception time of the IP data packet is below a sum of a reception time of the previously received IP data packet, belonging to the same non-basic layer, with the explicit congestion notification field being 11 and a round trip time between the RTP sender and the RTP receiver, and if not, then recording and updating the reception time, and generating and sending to the RTP sender the explicit congestion notification feedback report carried by RTCP, or if so, then only recording and updating the reception time.

15. The method according to claim 13 or 14, wherein the step X3 further comprises: sending a periodical explicit congestion notification summary report carried by RTCP to the RTP sender, and when the explicit congestion notification feedback report and a processing time thereof are above a predetermined time at which the periodical explicit congestion notification summary report is sent, precluding the explicit congestion notification feedback report from sending.