CN103354992B - Method and apparatus for synchronizing mobile station media streams during a collaborative session - Google Patents

Abstract

A method and apparatus for synchronizing mobile station (ie, wireless transmit/receive unit (WTRU)) media streams during a collaborative session is described. Inter-WTRU Transmission Request messages, Flow Addition Request messages, and Session Update Request messages may be exchanged between multiple WTRUs and a Session Continuity Control Application Server (SCC-AS). Each message may include a Session Description Protocol (SDP) attribute line that contains time synchronization information (eg, Presentation Time Offset (PTO) Information Element (IE), Media Stream Group Identification (ID), and Synchronization Tolerance IE). The SCC-AS may update the time synchronization information and include the updated information in its messages to the WTRUs, where the WTRUs may resynchronize their respective media streams based on the updated time synchronization information.

Description

Method and apparatus for synchronizing mobile station media streams during a collaborative session

Cross References to Related Applications

This application claims the benefit of US Provisional Application 61/442,008, filed February 11, 2011, the contents of which are incorporated herein by reference.

Background technique

An Internet Protocol (IP) Multimedia Subsystem (IMS) may be configured to deliver multimedia services using collaborative sessions. A collaborative session may consist of a set of two or more access legs and associated on two or more wireless transmit/receive units (WTRUs) with IMS subscriptions that appear to be a remote leg media. One of the WTRUs may be designated as the controller of the collaborative session and may initiate inter-WTRU transmission of media streams in the IMS where the other WTRUs of the collaborative session are targeted.

Packet Switched Streaming (PSS) technology can be integrated within IMS using Real-time Transport Protocol (RTP), Advanced Hypertext Transfer Protocol (HTTP) and adaptive HTTP streaming. PSS technology may provide a platform for delivering on-demand content or live television (TV) programming, for example.

Contents of the invention

A method and apparatus for synchronizing mobile station (ie, wireless transmit/receive unit (WTRU)) media streams during a collaborative session is described. Inter-WTRU Transport Request messages, Flow Addition Request messages, and Session Update Request messages may be exchanged between multiple WTRUs and a Session Continuity Control Application Server (SCC-AS). Each message may include a Session Description Protocol (SDP) attribute line (attribute line), which contains time synchronization information (for example, presentation time offset (PTO) information element (IE), media stream group identification (ID) and synchronization content. (synchronization tolerance) IE). The SCC-AS may update the time synchronization information and include the updated information in its messages to the WTRUs, where the WTRUs may resynchronize their respective media streams based on the updated time synchronization information.

In one embodiment, a first of the WTRUs may transmit a first message including initial time synchronization information and a request to perform an operation on a media stream. A second of the WTRUs may receive a second message including a request to perform an operation on a media stream and either initial time synchronization information or updated time synchronization information. The second WTRU may resynchronize its media stream based on one of the initial time synchronization information, updated time synchronization information, or further updated time synchronization information. The second WTRU may transmit a third message including time synchronization information for resynchronizing its media streams. The first WTRU may receive a fourth message including time synchronization information for resynchronizing the second WTRU's media stream. The first WTRU may update the first WTRU's internal state with time synchronization information used to resynchronize the second WTRU's media stream.

In another embodiment, a first of the WTRUs may transmit a first message requesting an update to the collaborative session. A second of the WTRUs may receive a second message that includes a media stream group identification (ID) information element (IE) and a synchronization tolerance IE. The second of the WTRUs may synchronize the media streams, perform presentation time offset (PTO) measurements on each of the media streams, and generate a combined media stream PTOIE based on the PTO measurements.

Description of drawings

A more detailed understanding can be obtained from the following description given by way of example with reference to the accompanying drawings, in which:

FIG. 1A illustrates an example communication system in which one or more disclosed embodiments may be implemented;

FIG. 1B illustrates an example wireless transmit/receive unit (WTRU) that may be used within the communication system shown in FIG. 1A;

Figure 1C illustrates an example radio access network and an example core network that may be used within the communication system shown in Figure 1A;

Figure 2 illustrates an example communication exchange for inter-WTRU transmissions of a PSS session;

Figures 3A and 3B together illustrate an example communication exchange for moving streams and creating a synchronous collaboration session;

4A and 4B together illustrate an example communication exchange for upgrading an asynchronous collaborative session to a synchronous collaborative session;

5A and 5B together illustrate an example communication exchange for transmitting a stream within a synchronous session;

6A and 6B together illustrate an example communication exchange for correcting a lack of synchronization;

Figure 7 shows an example block diagram of a Session Continuity Control Application Server (SCC-AS); and

8 shows an example block diagram of a WTRU.

detailed description

FIG. 1A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may use one or more channel access methods such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA) and more.

As shown in FIG. 1A, communication system 100 may include WTRUs 102a, 102b, 102c, 102d, radio access network (RAN) 104, core network 106, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, but It should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks and/or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. As examples, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular telephones, personal digital assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, consumer electronics, and more.

The communication system 100 may also include a base station 114a and a base station 114b. Each base station 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, Internet 110 and/or other networks 112. For example, the base stations 114a, 114b may be Base Transceiver Stations (BTS), Node Bs, Evolved Node Bs (eNBs), Home Node Bs (HNBs), Home eNBs (HeNBs), site controllers, access points ( AP), wireless router, etc. Although each of the base stations 114a, 114b is described as a single component, it should be appreciated that the base stations 114a, 114b may comprise any number of interconnected base stations and/or network components.

Base station 114a may be part of RAN 104, which may also include other base stations and/or network components (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. . Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area known as a cell (not shown). A cell may also be divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, one transceiver for each sector of the cell. In another embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology, and thus may use multiple transceivers for each sector in the cell.

A base station 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d via an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultrasonic (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

More specifically, as noted above, communication system 100 may be a multiple access system and may utilize one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a and WTRUs 102a, 102b, 102c in RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish over-the-air Interface 116. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may then include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

In another embodiment, the base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UTRA (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-Advanced ( LTE-A) to establish the air interface 116 .

In other embodiments, base station 114a and WTRU 102a, 102b, 102c may implement such as IEEE802.16 (ie Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000 Evolution Data Optimization (EV-DO), Interim (Interim ) Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM/EDGE RAN ( GERAN) and other radio access technologies.

For example, base station 114b in FIG. 1A may be a wireless router, HNB, HeNB, or AP, and may use any suitable RAT to facilitate wireless connectivity in a local area, such as a business, residence, vehicle, campus, etc. In one embodiment, the base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In another embodiment, the base station 114b and WTRUs 102c, 102d may use a cellular based RAT (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell . As shown in FIG. 1A , the base station 114b may be directly connected to the Internet 110 . Therefore, the base station 114 b does not necessarily need to access the Internet 110 via the core network 106 .

The RAN 104 may be in communication with a core network 106, which may be a network configured to provide voice, data, applications, and/or Voice over Internet Protocol (VoIP ) services any type of network. For example, core network 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet interconnection, video distribution, etc., and/or perform advanced security functions, such as user authentication. Although not shown in FIG. 1A , it should be appreciated that RAN 104 and/or core network 106 may communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104, which may use E-UTRA radio technology, core network 106 may communicate with another RAN (not shown) using GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). Internet 110 may include a system of globally interconnected computer network devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) of the TCP/IP Internet protocol suite. Network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that may use the same RAT as RAN 104 or may use a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multimode capabilities, that is, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers communicating with different wireless networks over different wireless links. letter machine. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that uses cellular-based radio technology, and with a base station 114b that may use IEEE 802 radio technology.

FIG. 1B shows an example WTRU 102 that may be used within the communication system shown in FIG. 1A. As shown in FIG. 1B , WTRU 102 may include processor 118 , transceiver 120 , transmit/receive section 122 , speaker/microphone 124 , keypad 126 , display/touchpad 128 , non-removable memory 130 , removable memory 132 , a power supply 134 , a global positioning system (GPS) chipset 136 , and peripherals 138 . It should be appreciated that the WTRU 102 may include any subcombination of the foregoing components while remaining consistent with the embodiments.

Processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a microprocessor, one or more microprocessors associated with a DSP core, a controller, a microcontroller , application specific integrated circuit (ASIC), field programmable gate array (FPGA) circuit, integrated circuit (IC), state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input/output processing, and/or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120 , which may be coupled to transmit/receive component 122 . Although FIG. 1B depicts processor 118 and transceiver 120 as separate components, processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

Transmit/receive component 122 may be configured to transmit signals to or receive signals from a base station (eg, base station 114a ) via air interface 116 . . For example, in one embodiment, transmit/receive component 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive component 122 may be, for example, an emitter/detector configured to emit and/or receive IR, UV, or visible light signals. In another embodiment, the transmit/receive component 122 may be configured to transmit and receive both RF signals and optical signals. Transmit/receive component 122 may be configured to transmit and/or receive any combination of wireless signals.

Furthermore, although the transmit/receive component 122 is depicted in FIG. 1B as a single component, the WTRU 102 may include any number of transmit/receive components 122 . More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive components 122 (eg, multiple antennas) for transmitting and receiving wireless signals via the air interface 116 .

The transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive component 122 and to demodulate signals received by the transmit/receive component 122 . As noted above, the WTRU 102 may be multimode capable. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate over multiple RATs, such as UTRA and IEEE 802.11.

Processor 118 of WTRU 102 may be coupled to speaker/microphone 124, keypad 126, and/or display/touchpad 128 (such as a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) and may receive user input data. Processor 118 may also output user data to speaker/microphone 124 , keyboard 126 and/or display/touchpad 128 . In addition, processor 118 may access information from, and store information in, any suitable memory (eg, non-removable memory 130 and/or removable memory 132 ). The non-removable memory 130 may include random access memory (RAM), read only memory (ROM), hard disk or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as memory located on a server or home computer (not shown).

Processor 118 may receive power from power supply 134 and may be configured to distribute and/or control power for other components in WTRU 102 . Power source 134 may be any suitable device for powering WTRU 102 . For example, the power source 134 may include one or more dry battery packs (such as nickel cadmium (Ni-Cd), nickel zinc (Ni-Zn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells and more.

Processor 118 may also be coupled with a GPS chipset 136 that may be configured to provide location information (eg, longitude and latitude) regarding the current location of WTRU 102 . In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and/or based on signals received from two or more nearby base stations Timing to determine its position. It should be appreciated that the WTRU 102 may obtain location information by any suitable method of location determination while remaining consistent with the embodiments.

Processor 118 may also be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and videos), Universal Serial Bus (USB) ports, vibrating devices, television transceivers, hands-free headsets, Bluetooth modules, frequency modulation (FM) radio units, digital music players, video game console modules, Internet browsers, and more.

FIG. 1C illustrates an example RAN 104 and core network 106 that may be used within the communication system 100 shown in FIG. 1A. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c via the air interface 116 using E-UTRA radio technology. The RAN 104 can also communicate with a core network 106 .

The RAN 104 may include eNBs 140a, 140b, 140c, although it should be appreciated that the RAN 104 may include any number of eNBs while remaining consistent with the embodiments. Each of the eNBs 140a, 140b, 140c may include one or more transceivers to communicate via the air interface 116 with the WTRUs 102a, 102b, 102c. In one embodiment, eNBs 140a, 140b, 140c may implement MIMO technology. Thus, for example, the eNB 140a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a.

Each eNB 140a, 140b, 140c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in uplink and/or downlink, etc. . As shown in Figure 1C, eNBs 140a, 140b, 140c may communicate with each other via the X2 interface.

The core network 106 shown in FIG. 1C may include a mobility management entity (MME) 142 , a serving gateway 144 and a packet data network (PDN) gateway 146 . While each of the foregoing components has been described as being part of the core network 106, it should be appreciated that any of these components may be owned and/or operated by entities other than the core network operator.

The MME 142 may be connected to each eNB 140a, 140b, 140c in the RAN 104 via the S1 interface and may act as a control node. For example, the MME 142 may be responsible for authenticating the user of the WTRU 102a, 102b, 102c, bearer activation/deactivation, selecting a specific serving gateway during the initial attach procedure of the WTRU 102a, 102b, 102c, and so on. MME 142 may also provide control plane functionality for switching between RAN 104 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

Serving gateway 144 may be connected to each eNB 140a, 140b, 140c in RAN 104 via an S1 interface. Serving Gateway 144 may typically route and forward user data packets to/from WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions such as anchoring the user plane during inter-eNB handover, triggering paging when downlink data is available for the WTRU 102a, 102b, 102c, managing and storing the WTRU 102a, 102b, 102c context etc.

Serving Gateway 144 may also be connected to PDN Gateway 146, which may provide WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the Internet 110, to facilitate communication between WTRUs 102a, 102b, 102c and IP-enabled devices. communication between.

Core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and conventional landline communication equipment. For example, core network 106 may include or may be in communication with an IP gateway (eg, an IP Multimedia Subsystem (IMS) server) serving as an interface between core network 106 and PSTN 108 . Additionally, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

Figure 2 illustrates inter-WTRU transmission operations in system 200 by creating a collaborative session. System 200 may include multiple WTRUs 205 ₁ , 205 ₂ , 205 ₃ and 205 ₄ , a Session Continuity Control Application Server (SCC-AS) 210 and an IP network 215 . System 200 can provide multimedia services using collaborative sessions. As shown in FIG. ₂ , voice and video streams between WTRU 1051 and WTRU ₁₀₅₂ may be moved to WTRU ₁₀₅₃ and WTRU ₁₀₅₄ . A collaborative session may include a set of two or more access legs and related media on two or more WTRUs with IMS subscriptions that appear to be one remote leg. One of the WTRUs may be designated as the controller of the collaborative session and may initiate transmission of inter-WTRU media streams within system 200 targeting the other WTRUs of the collaborative session. A session transfer process may be implemented within system 200 to transfer session control and/or media streams associated with the session.

WTRUs may exchange Information Elements (IEs) to enable media synchronization between devices. These IEs may include a group identification (ID) IE (which can match synchronized streams together), a presentation time offset (PTO) IE, and a synchronization tolerance IE.

The Group ID IE can identify streams that are being synchronized together. A free group ID (eg, specifying a placeholder with a value of 0, or the presence of a flag) may be present in the request to indicate that the network may generate and/or allocate a group ID. When the group is created in response to the request, the time synchronization information may include a valid group ID.

The PTO IE may be used to ensure that simultaneous playback occurs for multiple WTRUs. PTO can be calculated as follows:

PTO = current_playback_time - current_timestamp, equation (1)

where current_playback_time may be based on the wall clock time when playback of the first byte of the segment currently being played is performed, and current_timestamp may be the timestamp of the segment, Associated with the beginning of media emergence. PTO calculations can be performed at intervals, and/or on all media segments. Also, PTO calculation may be performed at a Random Access Point (RAP).

The Sync Tolerance IE may optionally be provided to multiple WTRUs to be able to trigger corrective action when the stream is out of sync.

Timing synchronization between PSS flows terminated by different WTRUs within an IMS collaborative session may also include the use of Session Description Protocol (SDP) attributes to attach the above IEs with media sessions or flows. SDP attributes may, for example, be included in any or any combination of messages used for inter-WTRU transfers.

SDP attributes can be extended to support synchronization between the streams of two different collaboration sessions controlled by the same device. For example, SDP attributes can be used to synchronize related streams from different servers.

A media session description may contain time synchronization information. This information can be set as a general value and sent to the device. The media player on the device can use this information to adjust its playback timing. This information can be set as a placeholder value, such as zero. The receiver can replace the placeholders with actual values, for example, the PTO obtained from a media player.

A collaboration session may be created as synchronous as described below, or may be updated to be synchronous after its creation.

IMS signaling may be used to establish playback timing at the WTRU using the PTO. When this offset is known and used by the WTRU, the WTRU may play the segment with time stamp TS ₀ at a given wall clock time T ₀ =TS ₀ +PTO. During playback, the WTRU is responsible for maintaining a buffer large enough to maintain this offset under different network access conditions. One possible condition to maintain skew may require all WTRUs to use the same wall clock time. Therefore, time synchronization can be based on the Network Time Protocol (NTP).

Processing may be performed in the WTRU's client to measure the PTO on the flow, set the desired PTO on the flow, and generate an event when the measurement may exceed a defined tolerance. For example, if the WTRU is not synchronized, the actual time stamp played at _T0 is _TS1 . When synchronizing, T ₀ is TS ₀ , so the absolute difference can be calculated and compared to the synchronization margin, (difference=ABS(T ₀ -PTO-TS ₁ )). The result can be used to determine whether the time difference is greater than the synchronization tolerance. The WTRU may use an update procedure to indicate this problem. When applicable, (eg, when the WTRU cannot keep up with playback timing), the SCC-AS may decide to use a lagging PTO and send it to the WTRU for synchronization. Alternatively, the SCC-AS may decide to reset the original PTO for a lagging WTRU. Therefore, the SCC-AS can maintain and distribute media synchronization information between devices.

Examples of synchronization types are single shot synchronization and continuous synchronization. Discontinuous synchronization can occur when a PTO is initially determined and can be used to provide a PTO for any new stream. Mechanisms for subsequently updating the PTO are possible. Synchronization information may be carried via IMS signaling, although the possibility exists to send synchronization information with the data.

Media stream synchronization for RTP streams can be achieved using the RTP Control Protocol (RTCP). Inter-Destination Media Synchronization (IDMS) develops RTCP extensions to support synchronization of media streams between devices. This RTCP-based mechanism can provide timing information periodically throughout the streaming session. This enables continuous adjustment of playback. This continuous adjustment may be particularly useful when one of the goals may be to support two-way (eg, Voice over IP (VoIP)) conversations. In this case, it is important to minimize buffering, which in turn may make the stream more sensitive to sudden network slowdowns or losses.

PSS streams can be used to support content on demand playback or live one-way content. Here, minimal buffering is rarely required in these application types based on the WTRU's buffering capabilities. Therefore, different buffer sizes can be used for specific applications. For example, a few seconds of buffering during buffering initiation may be considered acceptable for content-on-demand streaming, when the maximum acceptable delay for conversational voice may be on the order of hundreds of ms.

Since a larger buffer can be used to play PSS streaming content, one sync at the beginning of playback is enough, and this buffer can compensate for most network jitter. Corrective actions can be triggered when a device detects that it is out of sync, but there is a finite amount of time to periodically resync the stream. The discontinuous scheme can reduce the amount of signaling related to time synchronization.

Examples of signaling types are in-band and out-of-band. In the case of an RTP stream, RTCP packets may be sent by the device to the sender. Since RTCP packets generally follow the same network path as RTP streams, this can be referred to as in-band signaling. Also, in the case of RTP streams, the sender has an active part in the synchronization process. Because Advanced HTTP and Adaptive HTTP Streaming can use stock HTTP servers, an out-of-band signaling path for synchronous HTTP Streaming may be preferred.

PSS streams may include HTTP streams and RTP streams. The following embodiments can be applied to any streaming protocol that supports PSS, and can allow synchronization between streams using different protocols.

Figures 3A and 3B together illustrate an example communication exchange for moving a stream and creating a synchronized collaborative session during inter-WTRU transfer operations in a wireless communication system 300 including a Packet Switched Stream (PSS) adapter/server 305 , a Session Control Function (SCF) 310, a Session Continuity Control Application Server (SCC-AS) 315, and WTRUs ₃₂₀₁ and ₃₂₀₂ . Each of the WTRUs 3201 and ₃₂₀₂ may include _a client or application used during a communication session.

As shown in Figure 3A, _a video stream 325 and an audio stream 330' (ie, media streams) are established between the WTRU 3201 and the PSS adapter/server 305, and a bookmark is created (335). Before the inter-WTRU transmission is performed, the WTRU ₃₂₀₁ may obtain time synchronization information, (eg, current PTO, synchronization margin for all flows in the collaborative session) (340). The synchronization margin may be pre-configured or set based on the nature of the flow or type of source and destination WTRU. The time synchronization information may also be set as a placeholder by the WTRU 320 ₁ , (eg with a value of 0), or it may be provided by the SCC-AS 315.

As shown in Figure 3A, WTRU 3201 may transmit Inter _- WTRU Transfer Request message 345 to SCC-AS 315, which includes an SDP Attributes line (i.e., line "a") containing Group ID IE, PTO IE, and Synchronization Tolerance IE, in in the following formats:

a=3gpp_sync_info:idms_http<group_id><PTO><sync_tolerance>.

In the example shown in FIG. 3A, the SDP attribute line in message 345 may indicate that inter-WTRU synchronization is requested, and may additionally provide an IE to achieve this synchronization. The SDP Attributes line may be used to encode the Inter-WTRU Media Synchronization Information element and may appear in all media parts describing media synchronization within a collaborative session.

As shown in the example of Figure 3, the group ID is set to a placeholder value (0) until a new group is created by the SCC-AS 315, the PTO is set to "123456789", and the synchronization tolerance is set to "500" ms. The SCC-AS 315 can then check for authorization to operate, create a collaboration session, and update the Time Synchronization IE as needed, (e.g., generate a unique group ID if not provided by the WTRU, and if it is set as a placeholder ("0"), update the Time Synchronization Tolerance IE) (350). The SCC-AS 315 may then send an Inter-WTRU Transfer Request message 355 to WTRU ₃₂₀₂ (ie, the target WTRU) including the updated time synchronization information. Alternatively, the Inter-WTRU Transmission Request message 355 may include the same initial time synchronization information included in the Inter-WTRU Transmission Request message 345 .

Referring to FIG. 3B, after the WTRU accepts the Inter-WTRU Transfer Request message 355 and establishes the transfer session, a PSS session is established between the target WTRU ₃₂₀₂ and the PSS adapter/server 305 using a bookmark (360). At 365, the WTRU ₃₂₀₂ may change its streaming software client behavior to account for the PTO in the Transport Request message 355. Specifically, the presentation (display) of the stream to the user may be delayed appropriately to match the PTO IE in the Inter-WTRU Transmission Request message 355. The WTRU 3202 may send an Inter _- WTRU Transmission Response message 370 that includes the same Time Synchronization IE to the SCC-AS 315 that was included in the Inter-WTRU Transmission Request message 355 . Alternatively, for example, if PTO cannot be applied in the WTRU 3202 due to limitations of client software or the need for larger buffers, the response message 370 may contain further updates _than those included in message 345 or message 355 including Time synchronization information for different PTO IE values. The SCC-AS 315 may then send an inter-WTRU transmission response message 375 to WTRU _320i , the inter-WTRU transmission response message 375 including initial time synchronization information, updated time synchronization information, or further updated synchronization information. WTRU 3201 may update its internal state (380), (eg, _a data structure representing the state of the collaboration session including WTRU 320's ID) with the updated time synchronization information. In 385, the stream (video stream 325) transmitted between the WTRU ₃₂₀₁ and the PSS adapter/server 305 may be torn down if the operation is a media stream (i.e. stream) transfer, (e.g., if the operation is instead a copy of the stream , this step will be ignored). A video stream 390 may then be established between WTRU ₃₂₀₂ and PSS adapter/server 305, and _an audio stream 395 between WTRU 3201 and PSS adapter/server 305. The synchronous collaboration session 398 may thus be controlled by the WTRU 320 ₁ via the SCF 310 during the inter-WTRU transfer procedure so that the WTRU 320 ₁ acts as the controller of the collaboration session 398 . Collaboration session 398 may be assigned a new "synchronized" attribute to indicate that all its media streams are being synchronized via all WTRUs 320.

For example, in the communication exchange shown in Figures 3A and 3B, the PTO may be obtained by the WTRU ₁ measuring the value on the ongoing playback at this client. The group ID, which is initially unknown to the client, can be set to a value of "unknown", (arbitrarily chosen to be 0 in this example). The synchronization tolerance may be set to a value from configuration, or to an "unknown" value (eg 0), and, in this case, may be determined by the SCC-AS 315 .

The group ID can be set once by the SCC-AS 315 and can be used to determine which streams can be synchronized together. Each collaboration session can have a unique single group ID. However, in some cases, two collaboration sessions can be synchronized together by sharing a group ID. The SCC-AS 315 can collect the PTO from the initial measurement by the user, and can then set this value for all streams of this group ID. Subsequently, the SCC-AS 315 may receive PTO adjustments from the asynchronous clients.

When received by a client, the PTO can be provided to the client media player application and used by the application to decide which media segment can be displayed at a given time. If the playback buffer becomes empty, (for example: due to temporary network insufficiency), client application playback can start to lag. The client may indicate its new PTO to the SCC-AS 315, (eg, when playback starts again after a temporary network insufficiency ends). The SCC-AS 315 may then initiate a resynchronization by updating all WTRUs to use the new PTO, or by requesting a lagging WTRU to use the original PTO again.

If the inter-WTRU operation is flow creation, (ie, flow addition), rather than flow transmission, time synchronization may be applied in a similar manner. The generation process may be similar to that shown in FIGS. 3A and 3B , except that step 385 is not included.

4A and 4B together illustrate an example communication exchange for upgrading an asynchronous collaboration session to a synchronous collaboration session.

As shown in Figure 4A, video stream 425 and audio stream 430 (i.e., media streams) are established between WTRU ₃₂₀₂ and PSS adapter/server 305, while WTRU 3201 maintains control _of collaboration session 435 via SCF 310, which 310 was created during a previous inter-WTRU transfer in which video and audio streams were transferred from WTRU 320 ₁ to WTRU 320 ₂ . Early collaboration sessions may not have any synchronization specified, and thus, the streams may not be well synchronized. As shown in Figure 4A, the streams (streams 425 and 430) are both terminated by WTRU 320 ₂ , and thus, are typically not well synchronized, since video/audio synchronization is typically performed by the stream client software on a single WTRU was handled well. However, in preparation for future operation, the WTRU ₃₂₀₁ may want to change the asynchronous collaborative session 435 to a synchronous collaborative session, (e.g., the audio stream 425 and the video stream 430 can be copied later on another WTRU ). In 440, the WTRU ₃₂₀₁ may decide to mutually synchronize the flow of the collaborative session (ie, change the collaborative session from asynchronous to synchronous). The WTRU 3201 may send _a Session Update Request message 445 that includes a Time Synchronization IE using a dedicated new SDP wire attribute, which may appear within each Media Level Description section of the SDP payload, ( 4), or optionally may appear separately in the session-level description section to indicate that it applies to every media stream in the collaboration session. In the example shown in FIG. 4A, the WTRU ₃₂₀₁ may use the GroupID, PTO, and Synchronization Tolerance IEs with placeholder values _of 0, as these values are unknown to the WTRU 3201 and may be used later. SCC-AS 315 or WTRU 320 ₂ updates. The SCC-AS 315 may then update the collaboration session, and update the Time Synchronization IE as needed, (e.g., generate a unique group ID if not provided by the WTRU, and if the Synchronization Tolerance IE is set as a placeholder ("0"), then update the synchronization tolerance IE) (450). The SCC-AS 315 may then send a Session Update Request message 455 to the WTRU ₃₂₀₂ . WTRU 320 ₂ may proceed to synchronize the media streams, (e.g., by delaying the presentation of one media stream to match the presentation of the other media stream), and then measure the PTO of both media streams, (in this example, since they pass through a single WTRU are used, so both should be the same or very close to each other) (460). The PTO of the combined media stream can be generated from these measurements (eg average or maximum).

Referring to FIG. 4B , the WTRU ₃₂₀₂ may send a Session Update Response message 465 including the Combined Media Stream PTO IE to the SCC-AS 315. The SCC-AS 315 may then send _a Session Update Response message 470 to the WTRU ₃₂₀₁ , which may update its internal state, (ie, representative of the collaboration session) with the updated time synchronization information. Video stream 480 and audio stream 485 may be synchronized. The collaboration session 490 may thus be controlled by the WTRU 320 _{1 via the SCF 310 so that the WTRU 320 1 may} act as the controller of the synchronized collaboration session 490 . Collaboration Session 490 may assign a new "Synchronized" attribute to indicate that all media flows via all WTRUs 320 are synchronized.

The controlling WTRU may control the collaboration session and have a service profile that determines the service on the remote leg. The controlling WTRU may also support media streaming for collaborative sessions and request procedures related to inter-device transfer media control.

A controlled party WTRU may support media streams for collaborative sessions and may request inter-device transfer media control related procedures, but the controlled party WTRU is affiliated with the authorized controller WTRU for these procedures.

For example, a collaboration session can transmit or replicate a synchronized stream on another device. Therefore, the controlling WTRU may first synchronize the session to obtain the PTO. This scheme can also be used when a single flow exists, (termination on the slave WTRU). In this case, any media streams subsequently added to the collaboration session can be synchronized.

Figures 5A and 5B together illustrate an example communication exchange for transporting streams in a synchronous session.

As shown in Figure 5, a video stream 505 and an audio stream 510, (i.e., media streams) are established between WTRU ₃₂₀₂ and PSS adapter/server 305, while WTRU 3201 maintains control of _a synchronous collaboration session 515 via SCF 310, which The SCF 310 was created during a previous inter-WTRU transfer in which video and audio streams were transferred from WTRU 320 ₁ to WTRU 320 ₂ . The WTRU 320 ₁ decides to transmit a stream to itself while keeping the video and audio streams synchronized for stream presentation (520). When the collaboration session is ready to be synchronized, the WTRU ₃₂₀₁ already knows the Time Synchronization IE. WTRU 3201 may send _an Inter-WTRU Transmission Request 525 to SCC-AS 315 including a Time Synchronization IE. The SCC-AS 315 may initiate the flow transmission by sending a Remove Flow message 530, which may or may not include the Time Synchronization IE since the WTRU ₃₂₀₁ already knows the Time Synchronization IE.

Referring to Figures 5A and 5B, but with Time Synchronization IE, they can appear in any of the messages 530, 545, 550, 565 and 570 to implement error checking and possibly update values (535, 540, 545, 550, 560 and 565). Through the inter-WTRU transfer response message 570, the WTRU ₃₂₀₁ may be notified that its initial inter-WTRU transfer request has been successful. At the end _of the process, the video stream 575 is then terminated by WTRU 3201 and the audio stream 580 is terminated by WTRU ₃₂₀₂ . Video stream 575 and audio stream 580 may be synchronized. Therefore, the collaboration session 585 is still synchronous and also controlled by the WTRU ₃₂₀₁ .

Correction for loss of synchronization may be required. For example, there may be an existing synchronous collaboration session where the WTRU may detect that it is out of sync (lagged). Therefore, the WTRU may request a synchronous update. The SCC-AS 315 may accept and update sync on all collaborative session streams, or reset the original PTO on a lagging WTRU (effectively requesting the WTRU to "skip" playback to the current position on the other device).

Figures 6A and 6B together illustrate an example communication exchange to correct for loss of synchronization.

As shown in Figure 6A, _a video stream 625 is established between WTRU ₃₂₀₁ and PSS adapter/server 305 and an audio stream 630 is established between WTRU 3202 and PSS adapter/server 305, while WTRU ₃₂₀₁ maintains synchronization via SCF 310 Control of the collaboration session 635 that the SCF 310 created during a previous inter-WTRU transmission in which an audio stream was transmitted from WTRU 320 ₁ to WTRU 320 ₂ . In 640, WTRU ₃₂₀₁ may detect out-of-sync. For example, this detection may occur when the WTRU ₃₂₀₁ performs its PTO periodic or continuous measurement and compares it to the PTO of the synchronous collaborative session. If the difference is greater than a specified synchronization tolerance, an out-of-synchronization can be detected. The WTRU ₃₂₀₁ may indicate to the SCC-AS 315 that it is out of synchronization by sending a Session Update Request message 645 that includes a Time Synchronization IE that includes an updated PTO. At 650, the SCC-AS 315 may accept the synchronization update message 650. In this example, the SCC-AS 315 may decide to match audio stream presentation with video stream presentation. It should be noted that other strategies may also be implemented, (eg SCC-AS 315 may decide to pause and then restart both flows). The SCC _- AS 315 may send a Session Update Request message 655 including the updated PTO to the WTRU 3202. In 660, the WTRU ₃₂₀₂ may adjust its audio presentation to the new offset, (eg, skip the presentation to a position in the stream).

Referring to Figure 6B, the WTRU ₃₂₀₂ may send back a Session Update Response message 665 to the SCC-AS 315, typically with the same Time Synchronization IE to indicate that the resynchronization was successful. It should be noted that the WTRU ₃₂₀₂ may also send a modified value, eg, to indicate that it cannot resynchronize to the requested position in the stream. If this happens, the SCC-AS 315 may, for example, decide to stop the flow and possibly restart from an earlier point in the flow. In this example, the SCC-AS may send a Session Update Response 670 back to WTRU ₃₂₀₁ to indicate that the updated Time Synchronization IE has been accepted. The WTRU ₃₂₀₁ may store this new value in an internal state for future use, eg, to check synchronization again in the future.

The video stream 675 and audio stream 680 are now correctly synchronized, and the synchronous collaboration session 685 can thus be controlled by the WTRU 320 ₁ via the SCF 310 , so that the WTRU 320 ₁ acts as the controller of the synchronous collaboration session 685 . Collaboration session 490 may be assigned a new "synchronized" attribute to indicate that all its media streams are synchronized via all WTRUs 320.

The SCC-AS 315 may reject synchronous updates. For example, an incorrect (out of range) PTO value, or having too many sync updates, can be valid reasons for rejecting sync updates. Additionally, the SCC-AS 315 may resynchronize by forcing the WTRU 320 ₁ to use the original PTO, (eg, WTRU 320 ₁ playback skips where WTRU 320 ₂ is playing). PTO measurements on lagging streams can only be reported when they are stable. When increasing the buffer does not solve the problem (for example, lost connection, or insufficient bandwidth to keep up with streaming rendering), no reports can be generated.

During a collaboration session, there are situations where streams from different media server streams, different remote legs and synchronization in different collaboration sessions are required to be synchronized together. This can be achieved by synchronizing media sessions between two different collaboration sessions.

A WTRU operating as the current controller of the collaborative session may perform new inter-WTRU transmission operations. The result of this operation may be the creation of a new collaboration session, which may be synchronized with existing collaboration sessions. For example, a current collaboration session may have an audio media stream to an audio system and a video media stream to a smartphone. A WTRU can create a collaborative session by adding new media streams (for audio and video) on a television (TV), streaming the same content from another media server. The controlling WTRU may reuse the time synchronization group ID, (from an existing collaborative session), to create a second collaborative session in an inter-WTRU transmission request.

FIG. 7 shows an example block diagram of the SCC-AS 315 used in the wireless communication system 300 of FIGS. 3A, 4A, 5A, and 6A. SCC-AS 315 may include at least one antenna 705 , receiver 710 , processor 715 and transmitter 720 . Receiver 710 may be configured to receive a first inter-WTRU transmission request message from a first WTRU via at least one antenna 705 . Processor 715 may be configured to create a collaborative session and generate a unique media stream group ID for operational authorization checks based on received inter-WTRU transfer request messages. If the Synchronization Tolerance IE in the first Inter-WTRU Transmission Request message is set to a placeholder (0), the processor 715 may be configured to update the Synchronization Tolerance IE. Transmitter 720 may be configured to transmit through at least one antenna 705 a second inter-WTRU transmission request message including updated time synchronization information to a second WTRU associated with the same collaborative session as the first WTRU. Receiver 715 may also be configured to receive a first inter-WTRU transmission response message from a second WTRU via at least one antenna 705 . Transmitter 720 may also be configured to transmit a second inter-WTRU transmission response message via at least one antenna 705 to the first WTRU.

Receiver 710 may also be configured to receive a first session update request message from a first WTRU via at least one antenna 705 . Processor 715 may be configured to update existing collaboration sessions and generate a unique media stream group ID. If the Synchronization Tolerance IE in the first session update request message is set as a placeholder (0), the processor 715 may be configured to update the Synchronization Tolerance IE. Transmitter 720 may be configured to transmit through at least one antenna 705 a second session update request message including updated time synchronization information to a second WTRU associated with the same collaborative session as the first WTRU. Receiver 715 may also be configured to receive a first session update response message from a second WTRU via at least one antenna 705 . Transmitter 720 may also be configured to transmit a second session update response message via at least one antenna 705 to the first WTRU.

8 shows an example block diagram of WTRU 320 used in wireless communication system 300 of FIGS. 3A, 4A, 5A and 6A. The WTRU 320 includes at least one antenna 805 , receiver 810 , processor 815 and transmitter 820 . Processor 815 may be configured to obtain time synchronization information (e.g., current PTO, Sync Tolerance, Media Group ID) and generate an Inter-WTRU Transmission Request message including an SDP Attribute Line containing the Media Group ID IE , PTO IE and Synchronous Tolerance IE). The transmitter 820 may be configured to transmit an inter-WTRU transmission request message via at least one antenna 805 . The receiver 810 may be configured to receive an inter-WTRU transmission response message via at least one antenna 805 . The processor 815 may also be configured to update its internal state with the updated time synchronization information included in the inter-WTRU transmission response message.

The processor 815 may also be configured to buffer its media stream and subsequently start playback of the media stream upon receipt by the receiver 810 of the PTO provided in the Inter-WTRU Transport Response message.

Processor 815 may also be configured to determine whether to change an existing asynchronous collaborative session to an asynchronous session and generate a session update request message including an SDP attribute line containing a Media Group ID IE, a PTO IE, and a Synchronization Tolerance ie. The transmitter 820 may be configured to transmit the session update request message through at least one antenna 805 . Receiver 810 may be configured to receive a session update response message via at least one antenna 805 . The processor 815 may also be configured to update its internal state with the updated time synchronization information included in the session update response message.

Processor 815 may also be configured to synchronize the media streams of the collaboration session, perform PTO measurements on each media stream, and generate a combined media stream PTO IE based on the PTO measurements.

Example

1. A method of synchronizing media streams of wireless transmit/receive units (WTRUs) during a collaborative session, the method comprising:

a first of the WTRUs transmits a first message including initial time synchronization information and a request to perform an operation on the media stream; and

A second of the WTRUs receives a second message including the request to perform the operation on the media stream and the initial or updated time synchronization information.

2. according to the method described in embodiment 1, this method also comprises:

The second WTRU resynchronizes the second WTRU's media stream based on one of the initial time synchronization information, the updated time synchronization information, or further updated time synchronization information.

3. according to the method described in embodiment 2, this method also comprises:

the second WTRU transmits a third message including time synchronization information for resynchronizing the second WTRU's media streams;

the first WTRU receives a fourth message including time synchronization information for resynchronizing the second WTRU's media stream;

The first WTRU updates the first WTRU's internal state with time synchronization information for resynchronizing the second WTRU's media stream.

4. The method of embodiment 3, wherein the initial time synchronization information, the updated time synchronization information and the further updated time synchronization information comprise a Presentation Time Offset (PTO) Information Element (IE).

5. The method of embodiment 4 wherein the PTO is used to ensure that synchronized playback occurs for the WTRU.

6. The method of embodiment 4, wherein the PTO is the difference between the current playback time and the current timestamp based on wall clock time when playback of the first byte of the current segment being played was performed.

7. The method of embodiment 6, wherein the current timestamp is a timestamp of a segment relative to a start of media presentation.

8. The method according to any one of embodiments 2-7, wherein the initial time synchronization information, the updated time synchronization information, and the further updated time synchronization information include a media stream group identifier ( ID) Information Element (IE).

9. The method according to any one of embodiments 2-8, wherein the initial time synchronization information, the updated time synchronization information and the further updated time synchronization information include when the media streams are not synchronized Synchronization Tolerance Information Element (IE) to trigger corrective actions.

10. The method as in any one of embodiments 3-7, wherein each of the first message, second message, third message, fourth message includes a Session Description Protocol (SDP) attribute line, The Session Description Protocol (SDP) Attribute Line contains a Presentation Time Offset (PTO) Information Element (IE), a Media Stream Packet Identification (ID) IE, and a Synchronization Tolerance IE.

11. The method as in any one of embodiments 1-10 wherein the operation is an inter-WTRU transmission operation.

12. The method as in any one of embodiments 1-11, wherein the media stream comprises a video stream and an audio stream.

13. The method as in any one of embodiments 1-12 wherein the collaborative session is controlled by one of the WTRUs.

14. The method as in any one of embodiments 1-13 wherein the first message and the second message are inter-WTRU transmission request messages or flow addition request messages.

15. The method of embodiment 3, wherein the third message and the fourth message are inter-WTRU transmission response messages or flow addition request messages.

16. A method of synchronizing media streams of various wireless transmit/receive units (WTRUs) during a collaborative session, the method comprising:

a first of the WTRUs transmits a first message of an update to the collaborative session;

a second of the WTRUs receives a second message that includes a Media Stream Group Identification (ID) Information Element (IE) and a Synchronization Tolerance IE; and

The second one of the WTRUs synchronizes the media streams, performs presentation time offset (PTO) measurements on each of the media streams, and generates a combined media stream PTO IE from the PTO measurements.

17. The method of embodiment 16, further comprising:

The second WTRU transmits a third message including a Session Description Protocol (SDP) attribute line containing the combined media stream PTO IE, the group ID, and the The synchronization tolerance IE described above;

the first WTRU receives a fourth message including an SDP attribute line; and

The WTRU uses the combined media stream PTO IE, the group identification ID, and the synchronization tolerance IE to update the WTRU's internal state.

18. The method of embodiment 16 wherein the PTO measurements are used to ensure that synchronized playback occurs for the WTRU.

19. A session continuity control application server (SCC-AS), the SCC-AS comprising:

A processor configured to create a collaborative session comprising a plurality of media streams and generate a message comprising a Session Description Protocol (SDP) attribute line containing a presentation time offset (PTO) information element (IE), a media stream group Group Identification (ID) and Synchronization Tolerance IEs; and

a transmitter configured to transmit the message.

20. The SCC-AS of embodiment 19, wherein the message is an Inter Wireless Transmit/Receive Unit (WTRU) Transfer Request message or a Flow Addition Request message.

21. A session continuity control application server (SCC-AS), the SCC-AS comprising:

A processor configured to update a collaboration session comprising a plurality of media streams and generate a message comprising a Session Description Protocol (SDP) attribute line containing a presentation time offset (PTO) information element (IE), a media stream group Group Identification (ID) and Synchronization Tolerance IEs; and

a transmitter configured to transmit the message.

22. The SCC-AS of embodiment 21, wherein the message is a session update request message or a flow addition request message.

23. A wireless transmit/receive unit (WTRU), the WTRU comprising:

a processor configured to generate a message comprising a Session Description Protocol (SDP) attribute line containing a Presentation Time Offset (PTO) Information Element (IE), a Media Stream Group Identification (ID) and a Synchronization Tolerance IE ;as well as

a transmitter configured to transmit the message.

24. The WTRU of embodiment 23 wherein the message is an Inter-WTRU Transfer Request message or a Flow Addition Request message.

25. The WTRU of embodiment 23 wherein the message is a Session Update Request message.

Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software or firmware incorporated into a computer readable medium and executed by a computer or a processor. Examples of computer readable media include electrical signals (transmitted via wired or wireless connections) and computer readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, Magneto-optical media, and optical media such as CD-ROM discs and digital versatile discs (DVD). A processor associated with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC or any host computer.

Claims (14)

1. for the method synchronizing the Media Stream of multiple wireless transmitter/receiver unit WTRU, the party Method includes:

A WTRU in described WTRU transmits the first message, when this first message includes initial Between synchronizing information and perform the request of operation on described Media Stream, wherein said initial time synchronized letter Difference between breath instruction current playback time and current time stamp, to guarantee to occur for described WTRU The playback synchronized, and the time of the fragment that described current time stamp is the beginning relative to media presentation Stamp；

The 2nd WTRU in described WTRU receives the second message, and this second message is included in described matchmaker The request of described operation and the time synchronization information of renewal is performed on body stream；And

Described 2nd WTRU according to the time synchronization information of described renewal come re-synchronization this second The Media Stream of WTRU, the re-synchronization of wherein said 2nd WTRU updates the synchronization of described Media Stream To provide the playback of the synchronization for the WTRU in described WTRU and described 2nd WTRU.

Method the most according to claim 1, the method also includes:

Described 2nd WTRU transmit the 3rd message, the 3rd message include for re-synchronization this second The time synchronization information of the described renewal of the Media Stream of WTRU；

A described WTRU receives the 4th message, and the 4th message includes the time synchronized of described renewal Information；And

A described WTRU utilizes the time synchronization information of described renewal to update a WTRU's Internal state.

In method the most according to claim 2, wherein said first message and described second message Each includes Session Description Protocol SDP property column.

Method the most according to claim 1, wherein said operation is transmission operation between WTRU.

Method the most according to claim 1, wherein said Media Stream includes video flowing and audio stream.

Method the most according to claim 1, wherein said first message is that between WTRU, transmission please Message or stream is asked to increase request message.

Method the most according to claim 1, wherein said second message is that between WTRU, transmission rings Message or stream is answered to increase request message.

8. for synchronizing a device for the Media Stream of multiple wireless transmitter/receiver unit WTRU, this dress Put and include:

Transmitter, is configured to transmit the first message, and this first message includes initial time synchronization information With on described Media Stream, perform the request of operation, wherein said initial time synchronization information instruction is current Difference between playback duration and current time stamp, to guarantee for the plurality of wireless transmitter/receiver unit There is the playback synchronized, and the sheet that described current time stamp is the beginning relative to media presentation in WTRU The timestamp of section；

Receiver, is configured to receive the second message, and this second message includes by described WTRU One WTRU makes the time synchronization information of the renewal of the Media Stream for this WTRU of re-synchronization；With And

Processor, is configured to use the time synchronization information of described renewal to update the interior of a WTRU Portion's state, the re-synchronization of a WTRU in wherein said WTRU update described WTRU it Between synchronization.

In device the most according to claim 8, wherein said first message and described second message Each includes Session Description Protocol SDP property column.

Device the most according to claim 8, wherein said operation is transmission operation between WTRU.

11. devices according to claim 8, wherein said first message is that between WTRU, transmission please Message or stream is asked to increase request message.

12. devices according to claim 8, wherein said device is that conversation continuity controls application Server S CC-AS.

13. devices according to claim 8, wherein said first message is that session updates request disappears Breath or stream increase request message.

14. devices according to claim 8, wherein said device is WTRU.