WO2011043706A1

WO2011043706A1 - Stream switch using udp checksum

Info

Publication number: WO2011043706A1
Application number: PCT/SE2009/051123
Authority: WO
Inventors: Joacim Halén; Johan KÖLHI; Victor Souza; Jan-Erik MÅNGS
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2009-10-08
Filing date: 2009-10-08
Publication date: 2011-04-14

Abstract

The present invention relates to methods and arrangements to synchronize data streams in a Multicast Services Control System (MSCS) for digital information transport. A first stream (Multicast) and a second stream (Catch-up) are received at a Synchronization Function (6), and the second stream is forwarded to a receiver (3) via a Stream Switch Function (4). The method comprises the following steps: Calculated canonical checksums (CS (i) CANONICAL1) for at least one packet in the first stream is compared with calculated canonical checksums (CS (n) CANONICAL2) for at least one packet in the second stream, when the streams pass the synchronization function. Correspondence between two compared canonical checksums (CS (i) CANONICAL1, CS (n) CANONICAL2) is detected. The Stream Switch Function is switched over from the second stream (Catch-up) to instead forward the first stream (Multicast) to the receiver.

Description

STREAM SWITCH USING UDP CHECKSUM

TECHNICAL FIELD The present invention relates to systems and methods and more particularly, to mechanisms and techniques to synchronize data streams in a Multicast Services Control System for digital information transport.

BACKGROUND

Multicast is well suited for distribution of services as IP- TV or video streaming. Multicast is the way IP TV is typically distributed in broadband networks. Set Top Boxes have an important role of receiving and rendering the TV image for the TV sets. A Set Top Box in broadband networks does this by standardized speaking Internet Group Management Protocol IGMP to the broadband network. The IGMP has been developed by the internet Engineering Task Force IETF as a standard that relates to the communication between router and subscribers.

IPTV solutions of today suffer from long channel switching times, that is, it takes a long time from the moment the end user initiate a channel change on the remote until sound and picture of the selected channel is present on the TV screen. There are many sources to this delay, but the main source is the encoding techniques used to get a balance between picture quality and the bandwidth required. The most commonly used encoding techniques are MPEG2 and MPEG4.

Both of these techniques use an encoding scheme where they at a regular interval send a complete picture called an I- frame and in between these I-frames it send two types, called B- and P-frames, of incomplete pictures describing how the picture changes over time relative to the I-frame. The P and B frames cannot be decoded without the corresponding I-frame. As I-frames contain a lot of information requiring a lot of bandwidth to send a longer interval between I-frames, gives a lower overall bandwidth requirement. However, the encoder in the TV or set-top box cannot start decoding until it receives an I-frame, thus increased I-frame interval (called GOP-length) results in a longer average decode delay. Statistically this delay will be on average of half the GOP-length. A typical GOP-length will be around 1 second. The encoded content is usually sent as a multicast stream allowing many users to share the same stream thereby saving bancwidth in the access network. The delay has been solved by creating a buffering node, called FCC (Fast Channel Change) server. This server acquires packets from all available multicast channels and maintains separate cyclic buffers for each channel, holding all packets from the last N seconds. This buffer always starts with an I-frame. Upon channel change, a unicast burst (so called catch-up stream) will be sent to the client out of that buffer containing appropriate metadata and an I- frame. This catch-up stream will be sent at a speed higher than the transmission speed for the regular multicast stream until it has caught up with the regular multicast stream. Since an end receiver, i.e. the encoder in the TV or set-top box, is unaware of the cyclic buffers, packets arriving from a cyclic buffer must be rewritten before reaching the end receiver in order to simulate that the packets are received from the multicast source and not from a cyclic buffer. In order to change from the catch up stream to the regular multicast stream, stream synchronization must take place.

At synchronization the client will terminate the catch up stream and start receiving content from the regular multicast stream thereby saving bandwidth in the network. The stream switch is a software function that can be placed in different network elements, e.g., set-top-box or residential gateway.

There are two main ways of transporting video over IP today - MPEG2-TS over UDP, and RTP over UDP. The RTP over UDP streams contains sequence numbers that can be used for synchronization. However, the most commonly used transport today is MPEG2-TS over UDP where these sequence numbers are missing. This creates a problem when synchronizing. Since MPEG2-TS do not contain a unique identifier per packet, this makes it hard to synchronize between the regular multicast stream and the catch-up stream.

An existing way of solving this problem is through the application of packet pattern recognition. This method implies that the entire packet needs to be inspected so that patterns can be identified. This operation is rather expensive and involves complex algorithms and heuristics. Byte-by-byte comparison is also possible, but this is also a very labor intensive solution. One possible solution could be to use the UDP checksum for synchronization; however this is not possible due to the fact that this checksum contains the IP source and destination addresses, something that differs between the two streams (i.e., regular multicast and catch up stream).

SUMMARY

An aim of the invention is to overcome above identified limitations of the prior art. The existing UDP checksum consists of three main parts, IP pseudo header, UDP header, and the UDP payload. The two streams (catch-up and regular multicast) have the same payload, but different header information. In order to find matching video information, there is a need to compare the two streams payload parts. To use the UDP checksum for synchronization, it is necessary to eliminate the effect of the two headers in the UDP checksum. One way is byte wise comparison of the payloads, but this is very costly from a processing point and will introduce unnecessary delay. The invention solves the limitations by eliminating the effect of the different headers in the UDP checksum for the two streams, making the new checksum usable for synchronization directly.

The solution more in detail is a system and a method to synchronize data streams in a Multicast Services Control System for digital information transport. A first stream (Multicast) and a second stream (Catch-up) are received at a Synchronization Function. The second stream is forwarded to a receiver via a Stream Switch Function, The method comprises the following steps:

Calculated canonical checksums (CS (i) CANONICALI) for at least one packet in the first stream is compared with calculated canonical checksums (CS (n) CANONICAL2) for at least one packet in the second stream, when the streams pass the synchronization function.

Correspondence between two compared canonical checksums (CS (i) CANONICAL.., CS (n) CANONICAL2) is detected.

The Stream Switch Function is switched over from the second stream (Catch-up) to instead forward the first stream (Multicast) to the receiver.

A object of the invention is to eliminate need of sequence numbers or video content identification when synchronizing. This object and others are achieved by methods, arrangements and nodes. According to one exemplary embodiment a multicast stream is received to a Stream Switch Function at a regular speed and a catch-up stream is received to the Stream Switch Function at a speed that prior to the synchronization is higher than regular. Canonical checksums for packets in the catch-up stream are calculated for rewriting purposes. Canonical checksums for packets in the multicast stream are calculated and compared during a synchronization time interval with calculated checksums for packets in the catch-up stream. When conformity between packets in the two streams is found, switching over from the catch-up stream to the multicast stream occurs.

In another exemplary embodiment the use of a sliding window of adjacent canonical checksums is discussed.

Some advantages of the invention

The invention allows synchronization between different video sources sending the same video stream

No sequence numbers or video content identification is needed

No data is added or changed in order to synchronize, all video streams are unaffected

Protocol agnostic - any UDP stream format can synchronized (video, audio, data, etc)

The invention is much less process intensive than alternative solutions

The invention will now be described more in detail with the aid of preferred embodiments in connection with the enclosed drawings . BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 discloses a block schematic illustration of a multicast services control system wherein a Multicast Source or a Ring Buffer delivers media streams to a receiver, through a Broadband Network.

Figure 2 discloses a block schematic illustration of packet rewriting and packet synchronization units located between stream delivering entities and a receiving Set Top Box.

Figure 3 discloses a signal sequence diagram illustrating rewriting of packets and the method for synchronization of streams according to the invention.

Figure 4 discloses a flowchart illustrating some essential method steps of the invention.

DETAILED DESCRIPTION

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular circuits, circuit components, techniques, etc. in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced and other embodiments that depart from these specific details. In other instances, detailed descriptions of well known methods, devices, and circuits are omitted so as not to obscure the description of the present invention with unnecessary detail.

Figure 1 discloses a block schematic illustration of a Multicast Services Control System MSCS for digital information transport, in this example the information transport is equal to Internet Protocol transport. The system in the example comprises a Broadband Network i.e. an Access/Metro Network A/MNW that comprises Access Nodes AN1- AN5 (e.g. DSLAMs) and a number of concentrators (not shown in the figure) . Each one of the Access Nodes AN1-AN5 is attached to a Television set TV via a Set Top Box STB1-STB5 (only STB2 is shown in the figure) . The Access Node AN2 is attached to a Set Top Box STB2 and concentrators direct an incoming multimedia stream through the network from an Edge Router ER to AN2 and vice versa. The concentrators handle the multimedia stream distribution using multicast routing and forwarding. The STB2 is controlled by a user for example by using a Remote Control RC. The Access/Metro Network is attached to a backbone Network BBNW via the Edge Router ER. A service provider, also referred to as a Server, is attached to the BBNW for providing a range of TV channels to be delivered to the A/MNW. Based upon IGMP join signals and multicast routing and forwarding, selected channels can be directed from the Server through the Broadband Network A/MNW, via the concentrators, to a channel ordering client. The server is responsible for feeding the network with the channel stream (s) . Each client is represented in this example by a High Definition TV set TV1-TV5. To be observed is that any kind of terminal such as for example an ordinary TV set or computer terminal can be used. The server comprises a Multicast source and a Ring Buffer source. The Access Node AN2 comprises in this example a Stream Switch Function SSF. The AN2 and the SSF are vital parts of the invention and will be further explained in the next figures.

Figure 2 discloses the following parts, relevant for the invention : - A Multicast Source 1 that sends the different TV-channels by using multicast.

- An I-frame Ring Buffer 2 that buffers the last few seconds of the each TV-channel in separate ring buffers CH1-CH4, arranged in such a way that an I-frame is always the first element in the buffer. This means that the buffered information is always a few seconds behind the regular stream.

- A Set Top Box STB 3 that receives and render the TV image for a TV set.

- A Stream Switch Function SSF 4 that handles channel changes. To get faster channel change times in an IPTV network, the Stream Switch Function needs to synchronize between two different streams. One stream is the original multicast stream transferred in real time at normal speed (this stream is called the regular stream) . The other stream is called catch-up stream and is used directly after a channel change from a viewer. It is a buffered TV-stream of the regular stream and it is arranged so it always starts with an I-frame. This makes it possible to display a TV- picture directly. At channel change from the Set Top Box the SSF asks for the contents (starting with an I-frame) from the ring buffer to be sent at a higher-than-regular speed. At some point in time, typically at the end of the emptying of the ring buffer and content from the ring buffer arrives to the SSF 4 at regular speed, the SSF synchronizes with the regular stream and terminates the connection with the ring buffer.

- A delay buffer 5 that buffers a stream before reception to the Set Top Box to eliminate the effect when a stream is sent at a speed higher than the regular multicast stream transmission speed. When a stream arrives to the delay buffer 5 from the ring buffer 2 at a speed higher than regular, packets will be stored in the buffer until delivered at a regular speed from the buffer 5 to the Set Top Box 3.

- A Synchronization Function SP 6 that receives streams from both the Multicast Source 1 and the ring buffer 2. The

Synchronization Function SP comprises one buffer for each stream, a Regular Multicast Buffer 6a (RM Buffer) for the multicast stream and a catch-up buffer 6b for the catch-up stream. The streams are buffered in the Synchronization Function before reaching the Stream Switch Function 4. The buffered packets will be used for rewriting and synchronization purposes. In this example the catch-up buffer that receives packets from the catch-up stream is located in the Synchronization Function 6 but the buffer might as well be a part of the delay buffer 5.

- A control unit CTR 7 that handles the control of involved entities during the rewriting and synchronization of packets when the streams pass the Synchronization Function 6. The function of the CTR will be explained more in detail later in the text together with figure 3.

Figure 3 discloses a signal sequence diagram illustrating the method for rewriting of packets according to prior art and the method for synchronizing the streams according to the invention. In this exemplified first embodiment, as can be seen below, the calculations done during the rewriting- phase will be used during the synchronization-phase. The Multicast Source 1, the Ring Buffer 2, the Set Top Box 3, the Stream Switch Function 4, the Synchronization Function 6 and the control unit CTR 7 have all been mentioned in figure 2 and can be found as signaling nodes in figure 3. Signaling from one node to another is shown with arrows. An arrow head at the end of an arrow pointing at a node indicates that the signaling is not just passing the node but is received to and handled in the node. The signal sequence diagram comprises the following method steps: - The Multicast Source 1 sends the different TV- channels by using multicast. In figure 3 a multicast stream 10 is sent from the Multicast Source 1 to the Set Top Box 3 via the Stream Switch Function 4. The Stream Switch Function 4 is set in a position so that the multicast stream is forwarded to the Set Top Box and in this example a Channel 4 is viewed by a user of the television set attached to the Set Top Box 3.

- The user of the television set decides to change channel from channel 4 to channel 1 by using the

Remote Control RC {see figure 1) . The user signals this request to the Set Top Box 3 and the Set Top Box 3 sends an Internet Group Management Protocol IGMP signal 12 to the control unit CTR 7 in the broadband network, indicating the request from the user .

- A signal 14 is sent from the control unit 7 to the Stream Switch Function 4, requesting 4 to prepare to switch over and start forwarding the catch-up stream from the Ring Buffer to the Set Top Box 3, instead of forwarding the Multicast Stream from the Multicast Source.

- A signal 16 is sent from the Stream Switch Function

4 to the Ring Buffer 2, requesting the Ring Buffer to start sending out its buffered channel 1 with a speed higher than the regular speed. A signal 18 is sent from the control unit 7 to the Synchronization Function 6, requesting rewriting of packets as soon as packets starts to arrive from the Ring Buffer 2.

The Ring buffer 2 sends the buffered Channel 1 by using for example unicast. In figure 3 a Stream 20 (Unicast in this example) is sent from the Ring buffer 2 towards the Set Top Box 3 via the Synchronization Function 6. When the stream arrives to the Synchronization Function 6 packets will be buffered in the catch-up buffer in 6b.

Rewriting 22 of packets in the catch-up stream starts as soon as packets in the catch-up stream arrive to the Synchronization Function 6. A canonical checksum for each packet in the second stream (Catch-up) is hereby calculated in 7 as the packet's "Original UDP checksum" minus the packet's "Checksum (IP header) contribution". A checksum for the IP header of the first stream (Multicast) is furthermore calculated in 7, which calculation is a one-time occurrence made only for one packet in the multicast stream since all packets in the first stream has the same IP header. Finally, the header part of the first stream (Multicast) is added to the calculated canonical checksum of second stream

(Catch-up) so that the header parts of packets in the second stream (Catch-up) are exchanged to the header parts of packets in the first stream

(Multicast) . The packet of the second stream has now been rewritten and packets in the second stream appear to arrive to the Set Top Box 3 from the Multicast Source 1 instead of from the Ring Buffer The second Stream 20 is now forwarded in a rewritten format 24 from the Synchronization Function 6 via the Stream Switch Function 4 to the Set Top Box 3. The Stream Switch Function 4 is set in a position so that the rewritten stream is forwarded to the Set Top Box 3 and the Channel 1 can now be viewed by the user of the television set attached to the Set Top Box.

A synchronization time interval is in this example calculated 25 in the control unit 7. By using the known regular speed at which the first stream is sent out and the known speed at which the second stream is sent out it is possible to approximately find an intersection of the two streams when packet pairs having identical payloads pass the Synchronization Function 6. When this approximate intersection has been found a synchronization time interval can be specified pointing out when it is likely to find packets in the two streams with identical payloads. As already indicated the described calculation of the synchronization time interval is just an example and as an alternative instead the ring buffer 2 can send a signal to the control unit 7 when corresponding packets are likely to be found, i.e. at the end of the emptying phase of the ring buffer.

An IGMP message (not shown in the figure) is used to secure that channel 1 is received from the Multicast Stream to the Stream Switch Function 4 in Access Node AN2 and ready to view when synchronization has been finalized.

Packets are sent 28 from the Synchronization Function 6 to the control unit 7. This is a continuous process going on until the correct moment for synchronization has been found. When a new packet in the catch-up stream arrives to the Synchronization Function, packets in the multicast stream that recently have been buffered in the RM Buffer 6a in the synchronization Function are investigated 30 one by one to find a buffered packet in the multicast stream with the same canonical checksums as the newly arrived packet from the catch-up stream. A canonical checksum for the packet in the first stream (Multicast) is calculated as "Original UDP checksum" minus "Checksum (IP header)" when received to the control unit 7, from 6. If no packet was found among the buffered multicast stream packets having a checksum equal to the arrived packet in the second stream, no synchronization takes place. Instead the next packet in the second stream is awaited and when this next packet arrives a new comparison with buffered packets in the multicast stream is performed. This is, as said, a continuous process that goes on until the correct time of synchronization has been found. When a pair of packets have the same canonical checksums, it is clear that the packet pair has identical payloads, and synchronization can occur. When it is time to synchronize, the control unit 7 signals to the Synchronization Function, that it now can "close" it's buffers. The control unit also signals to the Stream Switch Function 4 that it is time to synchronize .

The Stream Switch Function 4 "switches over" 32 and instead of forwarding the catch-up stream to the Set Top Box, the Multicast Stream is forwarded to the Set Top Box. - The Multicast Stream 34 is sent to the Stream Switch Function 4. The Stream Switch Function 4 is now set in a position so that the Multicast Stream is forwarded to the Set Top Box via the delay buffer 5, and the Channel 1 from the Multicast

Stream can be viewed by the user of the television set .

Figure 4 discloses a flowchart illustrating some essential method steps of the invention. The flowchart illustrates calculations done during the rewriting phase and the calculations done during the synchronization phase. Figure 4 also illustrates how the canonical checksum for packets in the second stream (catch-up) calculated during the rewriting phase is used together with the canonical checksum for packets in the first stream (regular multicast) for synchronization purposes in accordance with the first embodiment .

In a block 101 in figure 4 can be seen that a canonical checksum (CS {n) CANONICAL2) for a first packet (n) in the second stream is calculated as the UDP checksum (CS (η)TOTin2 ) minus the checksum for the header part of the first packet in the second stream (CS (n) HEADERin2) . The "minus" sign surrounded by a circle means a subtraction that does a borrow adjustment while "plus" surrounded by a circle means addition that do carry adjustment In the block 101 can also be seen that the checksum for the rewritten first packet (CS(n) ouT2) is calculated as the (just calculated) canonical checksum for the first packet (CS (n) CAHONICAL2) plus the checksum for the header part of the first packet in the first stream (CS (n) HEADERin1) . After this phase, packet (n) has been rewritten. A canonical checksum for next packet (n÷l) (see block 103) in the second stream is calculated. This is a process that goes on until the synchronization time interval has been reached (see block 102) .

When the synchronization time interval has been reached, in a block 104 in figure 4 a canonical checksum (CS (i) CANONICAL1) for a first packet (i) in the first stream is calculated as the UDP checksum (CS (i) τοτ.ηΐ) minus the checksum for the header part of the first packet in the first stream

(CS (Ϊ) HEADERinl) .

In a block 105, the two calculated canonical checksums (CS ( i ) CANONICAL. ) and (CS (n) CANONICAL2) i.e. the last calculated checksum in the second stream are compared and if the canonical checksums are equal, synchronization will occur as shown in block 108. If the two calculated canonical checksums are unequal, no synchronization will occur but instead a check if the RM Buffer 6a is "empty" will occur. If 6a is not empty the next packet (i+1) (see block 107) in the RM Buffer will be investigated according to block 104. If no canonical checksums have been found equal when the RM Buffer is empty, next packet in the second stream (see block 103) will be handled and the rewriting phase and the synchronization phase will again be performed. This goes on until equal packets have been found and synchronization can take place.

In a second embodiment a slight possibility has been assumed that two packets with different video contents have the same canonical checksum. The second embodiment reduces this possible source of synchronization error by using a sliding window of adjacent canonical checksums. That is, the stream switch will compare a number of consecutive canonical checksums from both streams and will only switch if all checksums matches. The possibility of two streams with different video content having the same sequence is however highly unlikely as is obvious to someone skilled in the art. The fast channel change synchronization period is in the order of a fraction of a second.

The invention allows for synchronization of any type of data stream using UDP. Any video, audio or data format is supported since any payload can be used.

Items are shown in the figures as individual elements. In actual implementations of the invention however, they may be inseparable components of other electronic devices such as a digital computer. Thus, actions described above may be implemented in software that may be embodied in an article of manufacture that includes a program storage medium. The program storage medium includes data signal embodied in one or more of a carrier wave, a computer disk (magnetic, or optical (e.g., CD or DVD, or both), non-volatile memory, tape, a system memory, and a computer hard drive.

The invention is not limited to the above described and in the drawings shown embodiments but can be modified within the scope of the enclosed claims. The systems and methods of the present invention may be implemented for example on any of the Third Generation Partnership Project (3GPP), European Telecommunications Standards Institute (ETSI), American National Standards Institute (ANSI) or other standard telecommunication network architecture. Other examples are the Institute of Electrical and Electronics Engineers (IEEE) or The Internet Engineering Task Force (IETF) .

Individual function blocks are shown in one or more figures. Those skilled in the art will appreciate that functions may be implemented using discrete components or multi-function hardware. Processing functions may be implemented using a programmed microprocessor or general-purpose computer. The invention is in other words not limited to the above described and in the drawings shown embodiments but can be modified within the scope of the enclosed claims.

Claims

Method to synchronize data streams in a Multicast Services Control System (MSCS) for digital information transport, wherein a first stream (Multicast) and a second stream (Catch-up) are received at a Synchronization Function (6) , and whereby the second stream is forwarded to a receiver (3) via a Stream Switch Function (4), c h a r a c t e r i z e d in the following steps:

- comparing calculated canonical checksums (CS (i) CANONICAL1) for at least one packet in the first stream with calculated canonical checksums (CS (n) CANONICAL2) for at least one packet in the second stream when passing the synchronization function;

- detecting correspondence between two compared canonical checksums (CS (I)CANONICAL1, CS (n) CANONICAL2) ;

- switching over (32) the Stream Switch Function (4) from the second stream (Catch-up) to instead forward the first stream (Multicast) to the receiver (3) .

Method to synchronize data streams according to claim 1 , which method prior to the comparing of checksums, calculates the canonical checksums (CS (n) CANONICAL2) for packets in the second stream (Catch-up) which checksums are used to rewrite packets in the second stream so that the header parts of packets in the second stream (Catch-up) are exchanged to the header parts of packets in the first stream (Multicast) . Method to synchronize data streams according to claim 1 or 2, whereby packets in the first stream are buffered in a buffer (6a) in the Synchronization Function (6) and wherein the buffered packets are compared one by one with a packet in the second stream until correspondence is detected or all buffered packets have been compared.

Method to synchronize data streams according to any of the claims 1-3 wherein a number of consecutive canonical checksums from both streams are compared and correspondence is detected if all consecutive checksums in both streams matches .

Method to synchronize data streams according to any of the previous claims, wherein the first stream (Multicast) is received at the Synchronization Function (6) at a regular speed and the second stream (Catch-up) , prior to the synchronization, is received at the Synchronization Function at a speed that is higher than the regular speed.

6. Method to synchronize data streams according to any of the previous claims, wherein the comparing of the calculated canonical checksums (CS (n) CANOMICAL1, CS (n) CANONICAL2) is performed during a specified synchronization time interval. Method to synchronize data streams according to claim 6, whereby the specified synchronization time interval is specified after finding an intersection in time between a packet in the first stream and a corresponding packet in the second stream, by using information of the streams (Multicast, Catch-up) speed.

An arrangement for synchronizing data streams in a Multicast Services Control System (MSCS) for digital information transport, wherein a first stream

(Multicast) and a second stream (Catch-up) are received at a Synchronization Function (6), and whereby the second stream is forwarded to a receiver

(3) via a Stream Switch Function (4), which arrangement characterized by:

- means for comparing calculated canonical checksums {CS (i) CANONICAL1.) for at least one packet in the first stream with calculated canonical checksums {CS (n) CANOHICAL2) for at least one packet in the second stream when passing the synchronization function;

- means for detecting correspondence between two compared canonical checksums (CS (i) CANONICAL1,

CS (n) CANONICAL2 ) ;

- means for switching over the Stream Switch Function (4) from the second stream (Catch-up) to instead forward the first stream (Multicast) to the receiver (3) . An arrangement for synchronizing data streams according to claim 8, which arrangement comprises means to calculate the canonical checksums {CS (n) CANONICAL2) for packets in the second stream (Catch-up) , which checksums are used to rewrite packets in the second stream so that the header parts of packets in the second stream (Catch-up) are exchanged to the header parts of packets in the first stream (Multicast) .

An arrangement for synchronizing data streams according to claim 8 or 9, whereby packets in the first stream are buffered in a buffer (6a) in the Synchronization Function (6) and which arrangement comprises means to compare the buffered packets with a packet in the second stream.

An arrangement for synchronizing data streams according to any of the claims 8-10, which arrangement comprises means to compare a number of consecutive canonical checksums from both streams and detect correspondence if all consecutive checksums in both streams matches.

12. An arrangement for synchronizing data streams according to anyone of the previous claims, which arrangement comprises means to specify synchronization time interval by finding an intersection in time between a packet in the first stream and a corresponding packet in the second stream. A node (AN2) for synchronizing data streams in a Multicast Services Control System (MSCS) for digital information transport, wherein a first stream (Multicast) and a second stream (Catch-up) are received to the node and whereby the second stream is forwarded to a receiver (3) via a Stream Switch Function (4) in the node, which node is c h a r a c t e r i z e d by:

- means for comparing calculated canonical checksums (CS (i) CANONICAL.) for at least one packet in the first stream with calculated canonical checksums (CS (n) CANONICAL) for at least one packet in the second stream when passing the synchronization function;

- means for detecting correspondence between two compared canonical checksums (CS (i ) CANONICAL., CS (n) CANONICAL2 ) ;

- means for switching over the Stream Switch Function (4) from the second stream (Catch-up) to instead forward the first stream (Multicast) to the receiver (3) .

A node (AN2) for synchronizing data streams according to claim 13, which node comprises a Regular Multicast Buffer 6a located between the Stream Switch Function (4) and sender of the first stream (Multicast) .

A node (AN2) for synchronizing data streams according to claim 13 or 14, which node comprises a dealy buffer (5) located between the Stream Switch Function (4) and the receiver (3) .