This invention relates to network transmission, especially to method and apparatus using multicast-over-unicast transmission scheme in a WLAN.
In wireless local area networks or WLANs based upon the IEEE 802.11 standards, which define intermediate devices such as access points(APs), bridges, routers and that provide access for mobile devices and to other networks, video transmissions—in particular real time transmissions—require broadcast/multicast transmissions. However, broadcast/multicast transmissions suffer from an inherent lack of an error correction mechanism. When a data packet is sent to a group of receivers (broadcast/multicast), it is extremely difficult, if not impossible for the transmitter to manage the retransmission protocol for each receiver.
Several mechanisms exist to overcome data packet loss, in particular Forward Error Correction (FEC), multicast automatic Repeat Request (ARQ) etc. All of these mechanisms, however, suffer from significant added complexity and limitations in certain networks. For example, some WLAN intermediate devices like Access Point (AP) or a bridge, where bridge and/or AP are used herein to include router and/or brouter or any device having equivalent functionality, have an inherent limit in the transmission rate for WLAN multicast data packets on the premise that multicast quality should be limited by the client, e.g., mobile terminal with the poorest reception. Another mechanism is to transmit all the multicast packets using the multicast-over-unicast scheme, which definitely causes a scalability problem, since because the bandwidth is limited, if all the multicast packets are transmitted using multicast-over-unicast scheme, then the number of terminals which can concurrently receive the multicast packets will be limited by the bandwidth.
In a first aspect, a method for transmitting a packet stream containing a first set of packets in a network is provided. The method comprises steps of: sending said first set of packets to a plurality of receivers in multicast mode; and sending in unicast mode a second set of packets to at least one receiver among said plurality of receivers, wherein the second set of packets are a subset of the packets of the first set.
In detail, the first set of packets are capsulated into multicast packets with a multicast IP address and a corresponding multicast MAC address for a multicast group, and when sending the second set of packets to at least one receiver, the multicast MAC address contained therein is changed to the MAC address of the at least one receiver.
Further, the second set of packets are transmitted to a receiver in response to a request by the at least one receiver for joining the multicast group.
In addition, the second set of packets are selected as a function of importance for decoding the payload data of the first set of packets.
In above method said second set of packets are packets necessary for decoding I frames or base layer packets of a video stream.
In a second aspect, a method for receiving a packet stream containing a first set of packets in a network is described. The method comprises steps of: receiving the first set of packets in multicast mode; receiving the second set of packets in unicast mode, wherein the packets of the second set are a subset of the packets of the first set; and using packets from the second set to replace lost or uncorrectable packets from the first set of packets.
In the method of the second aspect, the first set of packets are capsulated into multicast packets whit a multicast IP address and a corresponding multicast MAC address for a multicast group, and the multicast MAC address contained in second set of packets is changed to a unicast MAC address when they are sent.
Further, the second aspect comprises steps of: joining a multicast group corresponding to the first set of packets; and for triggering the unicast transmission of the second set of packets, joining a second multicast group.
In addition, said subset of packets are packets necessary for decoding I frames or base layer packets of a video stream.
a is an exemplary format of an Ethernet frame,
b is an exemplary format of multicast packet,
c is an exemplary format of the multicast packet of
In the exemplary
Prior to a multicast transmission, e.g. transmission of multicast video stream A, an appropriate announcement containing a session description is made by the media server 1. Standard session descriptions are generated using a Session Description Protocol (SDP), as defined in the Internet Engineering Task Force's draft RFC 2327. SDP is a simple ASCII text based protocol that is used to describe real time multimedia sessions and their related scheduling information. A SDP message conveys information about each media stream in the multicast session to allow the recipients to participate in the session. The media information contained in the SDP information includes the type of media (e.g. video, audio), the transport protocol (e.g. RTP, UDP, or IP), the format of the media (e.g. MPEG video), the multicast address for media, the transport port for media, etc. The multicast address for media are the destination address and destination port of the multicast stream. The address SDP information being sent is 224.2.2.2, and the UDP port is 4000. A host which wants to know the multicast session can join this special multicast session and receive the SDP information. For the multicast video stream A at the media server 1, the multicast address for the stream A is the multicast IP address A2′ (230.1.1.1) and the corresponding MAC address A2 (01-00-5e-01-01-01).
By analyzing the SDP (Service Description Protocol) information, the QoS (Quality of Service) server 3 knows there is media content A to be multicast to multicast group A1 in the media server 1 and sends a request to the router 6 and shows the intention to join the multicast group A1. The request is sent for example, according to IGMP (Internet Group Management Protocol). The Internet Group Management Protocol (IGMP) is a communications protocol used to manage the membership of Internet Protocol multicast groups. IGMP is used by IP hosts (e.g. the QoS server 3, or the mobile station 2) and adjacent multicast routers to establish multicast group memberships. The QoS server 3 issues messages (JOIN) to the router 6 as an IGMP router for joining the multicast group A1 for the multicast video stream A. The router 6 responds the JOIN messages with a QUERY message to determine which group the QoS server is a member of. The QoS server feeds back the query with a membership report to inform that it wants to join the multicast group A1. The multicast video stream A can be received by the QoS server 3.
When the QoS server 3 catches the multicast video stream A, analyzes e.g. frame format, of every RTP/IP packet in the video stream, and reconstructs another multicast QoS stream B which includes only a few of important packets duplicated/copied from the video stream A. As shown in
For example, the QoS server 3 analyzes the frame format of every RTP/IP packet in video stream A, duplicates those packets containing I frames (e.g. in a MPEG-2 encoded video stream) and stores them, because in MPEG-2 stream, B frames and P frames are generated with respect to the I frames. If a packet contains not only I frames but also other frames, e.g. B frames and/or P frames, the packet is still considered to be an important packet and stored at the QoS server 3. In another example, for a spatially scalable video stream, important packets can be base layer packets. That is because in a scalable encoded/decoded stream, the base layer relates to low resolution images, and from this base layer encodes/decodes at least one enhancement layer relating to high resolution images. The QoS server 3 also sends a request through the router 6 to the video server 1 to request it to update the SDP information for video stream A. The updated SDP information will indicate the destination multicast address A2 and A2′ for video stream A and the destination multicast address B2 and B2′ for the supplementary video stream B. The video stream A also contains the packets of the video stream. In addition, the QoS server 3 can be integrated into the video server 1 or be separated therefrom as shown herein.
When a mobile station 2 in the WLAN, for example MS1 with the IP address being (10.11.72.64) and the MAC address being (00-1c-23-3B-83-5A), issues a request to the video server 1 for SDP information, it will receive SDP (Service Description Protocol) information related to the video stream A from the video server 1. By analyzing this SDP information, it learns that it can get the original video stream A by joining the multicast group A1 with multicast MAC address A2 (01-00-5e-01-01-01) and multicast IP address A2′ (230.1.1.1), and get the supplementary QoS video stream B by joining the multicast group B1 with multicast MAC address B2 (01-00-5e-01-01-02) and multicast IP address B2′ (230.1.1.2).
The QoS agent 5 at the wireless Access Point (AP) 4 blocks the packets of multicast stream A from the video server 1 and the supplementary QoS video stream B from the QoS server 3 until it gets a request from a mobile station 2 for the packets of stream A and/or B. The request sent by a mobile station 2 is an IGMP (Internet Multicast Protocol) JOIN message.
When the mobile station 2 joins the multicast group A1 or the multicast group B1 by sending a message, e.g. an IGMP JOIN message (Internet Group Management Protocol), to the router 6 via the AP 4, the multicast video stream A and/or video stream B will be forwarded to the mobile station 2 via the AP4.
The wireless Access Point (AP) 4 monitors IGMP messages sent from the mobile stations 2. Upon receipt of an IGMP Join request MS1 to join multicast group A1 from a mobile station 2 such as, the AP 4 forwards the original multicast video stream A to MS1 directly. If the video stream A has been sent before and the mobile station 2 has got the content, the mobile station 2 will not ask for the video stream again. If the AP 4 receives an IGMP request to join multicast group B1, the QoS agent 5 will encapsulate the IP multicast data packets in the multicast stream B into unicast IEEE 802.11 frames with a destination MAC address corresponding to the source address of the received IGMP packet, i.e., MS1's MAC address (00-1c-23-3B-83-5A) in this case and send it out by using a multicast-over-unicast scheme. While the IP multicast data packets contain the unchanged IP multicast group address B2′ (230.1.1.2), as shown in
A mobile station 2, e.g. MS1 continuously receives the multicast stream A and the multicast-over-unicast stream in which the multicast stream B is encapsulated. It will store and analyze the received RTP packets from multicast stream A, and if it finds a RTP packet has been lost in the multicast stream A by counting the sequence number field in the RTP header, it will look for a RTP packet with the same sequence number in the received RTP packets queue of the multicast-over-unicast stream. If there is a RTP packet in received RTP packets queue of the multicast-over-unicast stream having the same sequence number as the lost RTP packet in the received RTP packets queue of the multicast stream A, it will copy or move the corresponding RTP packet from the queue in a buffer 8 of the multicast-over-unicast stream into the queue of the multicast stream A in buffer 7. Then the mobile station 2 will use these RTP packets in the queue of the multicast stream A to compose the frames for the video, decode the frames and play it.
During the process, the AP 4 will monitor the IGMP messages sent from the mobile stations 2 all the time, and it will stop transmitting the multicast-over-unicast stream B to a mobile station 2, once it detects that the mobile station 2 quits the multicast group B by issuing an IGMP leave message.
Accordingly, at the AP 4, there is an input 41 for receiving packets from the QoS server 3 and the media server 1. There is also a QoS agent 5 for analyzing whether a received packet is a packet from the media server 1 or a packet of the QoS stream from the QoS server 3. If the received packet is a packet from the media server 1, it will be sent via output 43 to the mobile stations 2 in multicast way directly. And if the received packet is a packet of the QoS stream from the QoS server 3, it will be sent via output 43 to the mobile stations 2 in multicast-over-unicast mode.
In above description, though the apparatus of the media server 1 and the QoS server 3 are put separately, they can be put together too. In addition, although the above processes of the whole system or at a specific device are illustrated in sequence, it shouldn't be construed as a limitation to the present principle, the sequences can be changed.
A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made. Additionally, one of ordinary skill will understand that other structures and processes may be substituted for those disclosed and the resulting implementations will perform at least substantially the same function(s), in at least substantially the same way(s), to achieve at least substantially the same result(s) as the implementations disclosed. Accordingly, these and other implementations are contemplated by this application and are within the scope of the following claims.
Number | Date | Country | Kind |
---|---|---|---|
08305994.9 | Dec 2008 | EP | regional |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP2009/066730 | 12/9/2009 | WO | 00 | 6/21/2011 |