Wireless multimedia messaging service

ES 2 245 991 T3

DESCRIPTION

Wireless multimedia messaging service.

The present invention relates to wireless multimedia messaging services. It relates particularly, though not exclusively, to streaming in a Multimedia Messaging Service (MMS).

Electronic mail, or e-mail, is a messaging service, which allows fast and economical communication in electronic format. With the use of the Internet, e-mails can be sent all over the world, in many cases practically free of charge. Furthermore, the same email message can be sent to a plurality of recipients. This technique is called multicasting. Because the relay of email messages is fully automated, email messages can arrive in a very short time after they have been sent. E-mail messages can carry computer files such as documents, program files, and various media files such as audio or video clips.

Regular home users who have Personal Computers (PC) prefer not to have a permanent connection with their email system (for example, with the Internet) but rather establish a temporary and remote connection with an email server that stores received messages from a previous e-mail reading session. With the use of this type of connection and an e-mail message reader program, new e-mail messages can be transferred from the e-mail server to the memory or a hard disk of a PC and then can be read either while the connection is still active, or alternatively after the connection has been dropped. Data transmission between the PC and the email server is typically accomplished using a modem built into the PC.

In the following description, the term "sender" refers to a device that sends data intended for a receiver and "receiver" refers to a device that receives the data and to which said data was intended.

Figure 1 shows a schematic diagram of an Internet-based email system 10 comprising a sender 11, a receiver 15, and the Internet 12 with a sender's email server 13 and a recipient's email server 14.

On the Internet, email messages are sent using certain well-known protocols. Simply put, an email message, once compiled, is packaged into a single unit, stamped with a recipient address, and sent to the sender's email server. The sender's email server forwards the message over the Internet to the recipient's email server. The next time the recipient establishes a connection to the recipient's email server via the Internet and checks for new email messages using an email reader program, the recipient can download any email message received back over the connection (eg modem link). When the email message has been fully received, it can be presented to the user. It should be noted that during the various phases of its transmission, the email message is typically divided into numerous smaller packets according to the data transfer protocol (s) used. Upon receipt, the recipient collects all packages together, assembles them in the correct order (if necessary), and reconstructs the email message into its original form, before presenting the email message to a user of the recipient.

An e-mail transmission system as described above is convenient and provides multicast capability, although it is more suitable, and was originally intended for this, to receive e-mail messages and then present them at the user's will. In this way, the content of a given e-mail message can only be accessed after the transmission of the e-mail message to the recipient has been completed. This is not a real problem with email messages in plain text form, although in the case of large media or multimedia content (clip) the fact that the receiver user cannot initiate the presentation of the clip while the itself is being downloaded represents a drawback. Another drawback is that to receive an e-mail message, the recipient must have a memory large enough to accommodate the entire message. Particularly in mobile communication networks, or any other network in which part of the communication link is formed by means of a radio communication connection, it is also problematic to receive a large email message without interruptions or errors, for example, due to a temporary loss or deterioration of radio coverage. Mobile terminals also tend to have limited memory available for storing received e-mail messages, which further accentuates the problem associated with hosting messages at the receiver. These problems are at least partially mitigated by the Multimedia Messaging Service (MMS).

MMS is a new approach to end-to-end messaging for the one-way transmission of multimedia messages having text and / or multimedia content. MMS provides the ability to send multimedia messages between mobile users and between a mobile user and the Internet. There is already an agreed solution for the implementation of MMS in mobile communication networks of 3^to Generation. The currently specified features of the proposed MMS are outlined in the Partnership Project technical specification

ES 2 245 991 T3 of 3^to Generation (3GPP) 23.140 V.3.0.1. "Multimedia Messaging Service (MMS), Functional Description, Stage 2 (Release 1999)". The MMS proposed in 3GPP 23.140 uses a store-and-forward approach for the distribution of multimedia messages. Multimedia messages are constructed in such a way that the media content, the information necessary to describe the media content, and the addressing information, which identifies the intended recipient of the multimedia message, are encapsulated together. The multimedia message is then sent to an MMS MMSC Center, which in turn notifies the recipient about the multimedia message. The multimedia message is downloaded by the receiving terminal in its entirety and is presented only to the user once it has been downloaded and stored in the receiving terminal.

It should be appreciated that although the term "multimedia message" is generally used to describe a message that contains more than one type of content, in the present application, the term is expanded to include messages that contain only one type of media.

As currently specified, MMS suffers from a drawback: the receiving terminal must store the multimedia message before it can be presented to the user. For this reason, the memory size of the receiving terminal sets an upper limit on the size of multimedia messages that can be downloaded. Document WO 99/166746 solves this problem by dividing a message into sub-messages (segments) in the event that the complete message does not fit in the memory of the receiving terminal. These sub-messages are small enough that the receiving terminal can individually download each of them in their entirety. In such a case, the receiving terminal initially downloads a first sub-message. After the first sub-message has completely downloaded, the receiving terminal can present it. After the presentation of the first sub-message, the receiving terminal can download a second sub-message and then present it. Each sub-message is downloaded and then presented autonomously. The size of the sub-messages depends on the memory size of the receiving terminal and must be small enough to fit in memory.

In addition to MMS, there are streaming transmission techniques used on the Internet for transmission over fixed lines. "Streaming transmission" is a term used in general to describe the presentation of a media stream, for example, an audio or video stream, or a combination of different streams, in a continuous fashion as long as said stream or said continuous streams are being transmitted to a client over a data network. A "stream" is a stream of data that typically allows the receiver to present certain streaming data such as a movie, voice, or music. In a typical video stream, about 10-20 video frames are transmitted per second. In practice, the streaming can be either live (real time) or it can be done in an on-demand configuration. As its name suggests, "live streaming" describes creating a streaming media from a live source, for example, a stream of digital images produced by a camcorder, while " on-demand streaming ”describes creating a media stream from, for example, a file stored on a server. Streaming also involves the establishment of a streaming session, during which the stream or streams are transmitted or transmitted to the client.

There are two very important functionalities within the framework of streaming transmission, namely, the control of the streaming transmission and the media transport. Streaming control deals with the establishment, management, and termination of a streaming session using a pre-negotiated or configured set of parameter values. Media transport refers to the transport of media during the established session using an agreed or negotiated transport protocol. For example, on the Internet there are widely agreed protocols to provide both streaming control and media transport functionalities and these can be used as transport protocols in streaming applications.

Although streaming is widely used on the Internet, it has yet to be adapted for use in mobile communication networks. It should be appreciated that the use of streaming is desirable in mobile networks, as mobile terminals typically have limited storage (memory) capacity. However, current mobile communication networks do not support streaming for the reasons described below.

Encapsulating media content, message description, and addressing information into a single entity as proposed in current MMS specifications is incompatible with streaming media content. In order to establish a streaming session, it is necessary for the receiving terminal to have knowledge, in advance, of certain information regarding the content of the media. Such information includes, but is not limited to, the type of media contained in the multimedia message, the way in which the media is encoded, and a suitable transport protocol that can be used to download the content of the media. As the current MMS specifications require information that describes the content of the media to be encapsulated with the multimedia message itself, the receiving terminal cannot have prior knowledge about the properties of the media content and therefore cannot establish any form of streaming session. Thus, according to the present MMS specification, to extract the details of the media content the entire multimedia message must be downloaded at the receiving terminal. Only then can any media content, such as video and / or audio clips, be played to the user of the receiving terminal. This limits the usability of current MMS as media clips are often bulky.

ES 2 245 991 T3 in terms of bits and therefore a receiving terminal, for example a mobile station, would require a comparatively large memory to fully receive the clips. The need to download a complete multimedia message before it can be presented can also lead to significant delays in certain conditions, for example, if the multimedia message is very large, or the data transmission speed of the connection is low. .

It should further be noted that the addressing scheme suggested by the current MMS specifications does not facilitate the implementation of streaming transmission in such a system. Today's MMS can be viewed as a "sender-oriented" system. In other words, the sender decides what media content to send to the recipient, encapsulates the content in the multimedia message, and routes the multimedia message to the intended recipient. On the other hand, streaming transmission is more "receiver-oriented." To establish a streaming session, it is generally necessary for a streaming connection to be formed between the receiver and the sender, for example a network-based server, with content streaming from the server. once the necessary connection has been established. Thus, establishing a streaming session requires that the recipient have knowledge of the location of the media content, but does not necessarily require that the media content be addressed directly to the recipient. For example, EP-A-0 984 584 discloses a method and a system for the reproduction of live or previously recorded multimedia data in real time over a large-scale communication network, such as the global mesh. multimedia. The system architecture provides a "rollout" mechanism that includes a central broadcast process that accepts a continuous multi-stream type of data stream and then distributes the continuous multi-stream type of data stream to essentially every Terminal Information Manager accessible to the user. host. In this way, the burden of providing continuous data flows is spread among a large number of Terminal Information Managers, reducing access latency and providing support for hundreds of thousands of users over a large-scale communications network. .

The present invention provides a new solution in which the problems of the prior art can be avoided or at least mitigated.

According to a first aspect of the invention, a wireless multimedia messaging method is provided as defined in claim 1.

The transmission of the content to the second terminal in the form of a continuous stream allows quick access to the content since it is not necessary for a recipient using the second terminal to wait for the content to be fully received.

Preferably, the content and the information describing the content are sent from the first terminal to the communication server in separate messages. This allows, for example, the independent sending of the content to a communication server entity and the sending of a notification message to the recipients.

Preferably, the information describing the content is sent from the communication server to the second terminal within the notification message.

Preferably, the method further comprises sending, by the communication server to the second terminal, the information describing the content as a media component of a multimedia message.

Sending the description of the streaming component in the form of a media component allows the use of existing multimedia messaging systems with minor variations. In addition, it allows more than one media component to be incorporated into the same multimedia message, where some or all of the media components may be stream-convertible component descriptions.

Preferably, the multimedia message comprises at least one non-streaming component and at least one description of a streaming component.

Preferably, the communication method further comprises the step of presenting at the second terminal, the content received in the form of a stream during the streaming session. The second terminal can start the presentation of the content immediately and can possibly take certain measures (for example, pause or abort the data transmission) during the transmission.

Preferably, the method further comprises the step of deciding in the second terminal whether or not to receive the content, at a given instant of time, and the streaming session is formed only if the decision is to receive the content.

Preferably, the communication server comprises a content server for storing and transmitting the content and a notification server for receiving and transmitting notifications, in which the content server and the notification server have a physical relationship selected from the consistent group in the following: an individual unit, independent units, and independent units distributed in different geographical locations.

ES 2 245 991 T3

Preferably, the communication method further comprises the step of generating the content in the first terminal. Preferably, the content generated in the first terminal is streamed to the content server and content delivery occurs during content generation. By doing so, the content can be made available to the user earlier than if the content was generated in its entirety or to a greater extent in the first terminal and only then streamed to the content server.

Preferably, when streaming content generation is used, the information describing the content is sent before the content generation has been completed, so that the second terminal can start receiving the content before it has been completed. completed his generation.

Preferably, during the streaming session between the communication server and the second terminal, the receiver can issue a cancel command to abort the session. Preferably, the streaming session is aborted in response to the cancel command.

Preferably, the notification message comprises information required by the second terminal to form a streaming session with the content server.

Preferably, the method is implemented as part of the Multimedia Messaging Service (MMS).

Preferably, the method further comprises the step of multicasting the content to at least one other terminal in addition to the second terminal in at least one other streaming session.

In one of the embodiments in which there is a plurality of streaming sessions, each of the streaming sessions can be formed independently of each other, so that the sessions can start and end in moments. different times or at the same time. Preferably, each of the sessions can be mutually independently aborted, in response to each of the respective terminals.

According to a second aspect of the invention, there is provided a wireless messaging system as defined in claim 25.

Preferably, the system further comprises means for generating the content in a first terminal.

Preferably, the system further comprises means for presenting the received content in the form of a stream to the second terminal, during the streaming session.

According to a third aspect of the invention, there is provided a messaging server as defined in claim 17.

According to a fourth aspect of the invention, there is provided a computer program product as defined in claim 39.

According to a fifth aspect of the invention, there is provided a wireless messaging device as defined in claim 28.

According to a sixth aspect of the invention there is provided a computer program product as defined in claim 39.

Preferably, the wireless messaging device is a mobile phone. In an alternative embodiment, the wireless messaging device is a wireless communication adapter adapted to provide wireless communication functionality with an external device such as a laptop PC.

According to a seventh aspect, a method is provided in a communication device as defined in claim 35.

The embodiments of one aspect also apply to various other aspects of the invention. For the sake of brevity, not all embodiments have been repeated in relation to every aspect of the invention. A skilled reader will appreciate the advantages of the various aspects and embodiments based on the advantages of the first aspect and its embodiments.

The invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram of an Internet-based email system;

Figure 2 is a diagram of a communication system according to a preferred embodiment of the invention;

Figure 3 shows the main protocol layers of streaming data transmission in the system of Figure 2;

Figure 4 shows the structure of messages sent during streaming data between a receiver and a media server according to the preferred embodiment of the invention;

Figure 5 shows a block diagram of a mobile communication terminal incorporating a cellular radiotelephone according to a preferred embodiment of the invention; and Figure 6 shows a radio adapter card for a portable PC according to an alternative embodiment of the invention.

Figure 1 has already been described in the previous discussion.

A preferred embodiment of the invention is briefly summarized below and will now be described in detail with reference to Figures 2 to 6.

According to a preferred embodiment of the invention, streaming is incorporated into the Multimedia Messaging Service (MMS). In relation to this, a three-phase approach is adopted. In a first phase (phase 1), a sender (sender terminal) transfers a multimedia message, or more precisely, a media content, to a media server (streaming). In a second phase (phase 2), one or more receivers (receiving terminals) are notified that the media content is available for distribution. In a third phase (phase 3), the media content is transferred to the receiver or receivers. Advantageously, the notification carried out in phase 2 takes place by means of a notification message sent from the sender through a Multimedia Messaging Server (MMS) to the receiver. Typically, the MMS server stores the notification message and then tries to forward it to the recipient. If it fails to forward, it tries to resend the stored notification message at a later time.

Advantageously, the streaming is performed in the first and third phases, namely during the upload of the media content to the media server (streaming) and during the download of the media content. from the media server (streaming). It should be noted that the continuous flow transmission during the loading phase (phase 1) does not constitute an essential characteristic of the method according to the invention. However, the use of streaming in both phase 1 and phase 3 can reduce the delay between the start of streaming media content from the broadcaster and the start of streaming in the receiver. It can also have the effect of reducing the storage requirements on the media server (streaming) and can effectively enable the implementation of real-time or near-real-time streaming in the MMS.

Phase 2 of the method can be considered as a message control phase, which deals with the forwarding of a multimedia message and information related to the transmission of continuous stream to a recipient (a destination receiver of a multimedia message ) through the MMS server. Phases 1 and 2 can be performed sequentially or substantially simultaneously, while phase 3 can be performed automatically upon receipt of the notification message at the receiver, or at some later time at the discretion of a user of the receiver. . Thus, the invention provides the flexibility to play streaming media content on the receiver at any time. The preferred embodiment does not impose any limitation on the size of the media content or the number of recipients in the case of multicasting. The preferred embodiment is based on a store-and-forward approach and is therefore in compliance with other MMS solutions. This allows any media content that is not to be streamed or is not of a type suitable for streaming to be downloaded to the receiver in a conventional manner, i.e. as specified in the MMS specifications. current.

One of the advantages of the present invention is that the implementation of the streaming functionality can improve the proposed MMS in many ways, particularly when the media content is large or must be multicast. The store-and-forward approach to streaming in MMS is efficient and desirable as it provides the receiver with complete flexibility in deciding whether and when to receive and play media content within a multimedia message. The invention also provides streaming functionality within the framework of the proposed MMS and is therefore fully compatible with existing MMS standards.

The embodiments of the invention to be described hereinafter outline the main steps for streaming transmission in the MMS.

Figure 2 is a schematic of a communication system 20 according to a preferred embodiment of the invention. The system 20 comprises a sender 21, an MMS Center (MMSC) having a media server 22 and an MMS server 23, and a receiver 24. The MMSC may also be referred to as a communication server.

In this example of a multimedia message streaming method, sender 21 is a mobile terminal equipped with a video camera 25 and a microphone (not shown) which creates media content (a video clip).

ES 2 245 991 T3 audio / video) to be sent to the receiver 24. The receiver 24 is a mobile terminal equipped with the appropriate presentation software and equipment to allow the presentation of the media content (the audio / video clip) . Typically, the emitter 21 and the receiver 24 are similar devices, with one being the emitter 21 and the other being the receiver 24 solely because of their functions as sending and receiving parties (sending and receiving). The three phases of the method are described in detail below.

In phase 1, sender 21 establishes a streaming session with media server 22 (streaming) which initiates storage of media content at a predetermined location. This phase can be considered as the media loading phase.

In phase 2, the sender 21 sends a notification through the MMS server 23 to the receiver 24 regarding the storage of the media content. The notification includes presentation description information required to establish another streaming session between receiver 24 and media server 22. Presentation description information includes, but is not limited to, the following data: the network address of the media server, details of an access mechanism by which the content of the media can be retrieved from the media server 22, the type of media to be streamed, the method (s) encoding used to encode the content of the media and an indication of the transport protocol (s) to be used for downloading the media.

In phase 3, receiver 24 establishes a streaming session with media server 22, based on the information received in the notification message, and receiver 24 begins to download and play the media. This phase can be considered as the media download phase. Media content is downloaded as a sequence of content sub-parts, each representing a time period of the streaming session. The content subparts can be separate data packets, or a subpart can be composed of more than one data packet, depending on the type of media content encoding and the payload size of the data packets.

The media server 22 and the MMS server 23 can be merged with each other or they can be maintained as different entities in the network depending on the implementation selected by the service provider, by which they are controlled. The media server 22 may be located, for example, in a mobile communication network or may reside on the Internet, possibly under the control of a service provider other than the one responsible for the provision of services in the mobile communication network.

When streaming is used in both phase 1 and phase 3, phase 2 (notification) occurs during phase 1 (media upload) and phase 3 (media download) can also be started during phase 1. Sender 21 continues to send media content to media server 22 while media server 22 simultaneously sends to receiver 24 those parts of media content received earlier. The receiver 24 begins (and continues) with the reproduction of the media content with a total delay that depends on the streaming process, the data transmission delays, and the instant of time in which the phase started. 3. If phase 3 does not start automatically, but only after requesting and receiving permission from the user of receiver 24, typically the total delay is greater than if phase 3 were to start immediately upon receipt of the notification in receiver 24.

In an alternative embodiment, the media content is already stored in the media server 22 and the broadcaster 21 knows the presentation description information of the media content. In this case, phase 1 can be skipped. As mentioned above, streaming media content is not essential for phase 1. For example, a non-streaming approach can be used for phase 1 in relation to sourcing media content from a commercial content provider, such as a news content provider, located on a network of communications, such as the Internet. The content provider updates the media content stored on the media server 22 using a non-streaming transmission over an IP connection and notifies potential recipients of the media content about new clips that may be interesting, using notification messages according to phase 2 of the invention. The recipients of the notification messages would be, for example, users who have a subscription with the specific content provider. Based on the notification message, at appropriate time points for each case, each recipient can decide whether to form a streaming session with the media server 22 to retrieve new media content that has become available from the provider. of specific content. This further represents an example of a multicast approach to streaming using the multimedia messaging system according to the invention.

According to an alternative embodiment of the invention, the presentation description information may be stored on a server other than the MMS server 23 or the media server 22, for example an email or web server. In this embodiment, the notification message sent to receiver 24 identifies the specific server on which presentation description information is stored, and an access mechanism (HTTP GET, WSP GET, IMAP4, POP3, RTSP DESCRIBE) to retrieve the presentation description information from that position. The receiver 24 then retrieves the presentation description information from the server identified in the notification message using the specified access mechanism. Next, the presentation description information thus retrieved guides the receiver 24 to invoke step 3 of the method in order to retrieve and reproduce the stored media content. If the server used for

ES 2 245 991 T3 storing presentation description information is the MMS server 23, the existing MMS solution can be used directly to retrieve presentation description information. In this situation, the MMS notification from sender 21 to MMS server 23 carries presentation description information and presentation description information is stored in MMS server 23. In this case, the notification from the server that stores the presentation description to the receiver 24 conveys the location of the stored presentation description, the address of the server, and other necessary information. Finally, receiver 24 follows MMS to retrieve presentation description from MMS server 23.

Thus, it should be noted that, in certain situations, the information content of the notification message sent from the sender 21 to the MMS server 23 may be different from the corresponding one sent from the MMS server 23 to the receiver 24.

According to a preferred embodiment of the invention, if the senders 21 and receivers 24 are under the authority of different mutually linked MMS servers (that is, they have different "serving" multimedia servers), the notification message is transported through the link between MMS servers. The number of servers that can be linked together between serving MMS servers is not limited for any end-to-end notification.

In the Internet domain there are existing protocols for both streaming control and media transport. Thus, phases 1 and 3 can be implemented on the basis of these existing protocols. In this way, the solution provided by the present invention also guarantees interworking with the Internet, which is also an important objective of current MMS regulations. Phase 2 conforms to existing MMS standards and therefore provides backward compatibility with previously proposed mechanisms for downloading non-streaming media content.

Some practical approaches for carrying out the different phases of the preferred embodiment of the present invention are outlined below by way of example.

The Real Time Streaming Transmission Protocol (RTSP) is a client-server streaming control protocol that enables the controlled distribution of streaming multimedia data over an IP network. It is an application level protocol and can work in conjunction with either the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). RTSP provides coverage to use RTP (Real Time Transport Protocol) / UDP or any other lower level protocol for media transport. RTSP comprises a set of methods / instructions for controlling streaming audio and / or video. In relation to this, the most useful methods / instructions are OPTIONS, DESCRIBE, ANNOUNCE, SETUP, PLAY, PAUSE, TEARDOWN, REDIRECT and RECORD. Media upload and download can be implemented using SETUP, PLAY, RECORD, PAUSE, and TEARDOWN.

The Hypertext Transport Protocol (HTTP) can also be used to allow and control the uploading and downloading of media content according to the invention, using TCP as the transport protocol. HTTP has the PUT and GET methods / instructions, corresponding to RECORD and PLAY in RTSP, which can be used for uploading (phase 1) and downloading (phase 3) of media.

UDP is a connectionless lightweight transport protocol that provides comparatively low latency communication. RTP is specifically designed for real-time communication and is implemented in such a way as to provide timestamps and sequence numbers for data packets above UDP. Multicasting is possible using RTP. RTP is further designed to work in conjunction with the RTCP (Real Time Control Protocol) auxiliary control protocol to obtain feedback on the quality of data transmission and information about participants in an ongoing session. Together, RTP and RTCP provide functionality and control mechanisms necessary to transport real-time content and therefore to allow streaming of media content and for this reason can be used in conjunction with the present invention.

TCP is a connection-oriented transport protocol. It ensures a guaranteed and sequential reception of data packets with the trade-off of increased latency and higher overhead compared to UDP. Multicasting is not possible with TCP, although TCP can be used in streaming applications, if the initial buffering time is not critical and the clips of the media to be streamed are comparatively short.

Message control functionality is required above the streaming and media transport control layers to incorporate streaming into the MMS. Figure 3 shows the main protocol layers of a streaming data transmission system according to Figure 2. A message control layer 31 provides overall control of the messaging functionality. For example, at sender 21, message control layer 31 is responsible for assembling media content into multimedia messages and for forming notification messages containing information describing media content, which are sent subsequently to the intended recipient (s) 24. In the receiver 24, the message control layer 31 is responsible for the interpretation of received notification messages, the extraction of information regarding the location of the content of the media to be transmitted in continuous flow and the information

ES 2 245 991 T3 necessary to form streaming sessions with a view to retrieving media content. The message control layer 31 is also responsible for controlling the transmission and reception of any media content that is not going to be streamed and / or is not of a type suitable for streamed transmission, depending on the existing MMS.

A streaming control layer 32 is controlled by the message control layer 31. It is responsible for the formation of a streaming session for each type of media content to stream, according to the information provided by the message control layer 31, or according to previously defined rules for each type of streaming. media. It is also responsible for controlling / regulating the streaming of media content once a streaming session has been established. At emitter 21, streaming control layer 32 is responsible for streaming media content to a media server 22 and conversely, at receiver 24, is responsible for download control. streaming of media content from media server 22. Alternatively, the streaming control functionality can be provided on the media server 22 in a situation where, for example, the streaming is performed in phase 1 and 3 in such a way as to provide real-time or near-real-time streaming transmission of media content between senders 21 and receivers 24. A media transport layer 33 manages the actual transport of data using a suitable transport protocol. The choice of protocol can be predefined for different types of media or it can be indicated to the media transport layer 33 through the message control and streaming control layers 31, 32 according to information provided in the notification message. In a preferred embodiment, the media streaming control adapts the streaming transmission according to the condition of the data transmission channel reported by the media transport layer 33.

Figure 4 shows the structure of different control messages sent between receiver 24 and an MMSC (or media server 22) during a streaming media content download according to a preferred embodiment of the invention. It illustrates the flow of information to allow playback of a media clip at receiver 24 using an RTSP session while RTP / RTCP is used as the transport protocol. This situation provides an example of an approach that can be used to unload a media clip in phase 3 of the present invention. The control messages sent to receiver 24 are explained below:

Receiver 24 requests the media content of which it has been notified in phase 2. Receiver 24 sends an RTSP setup message (41) to the MMSC to establish a streaming session, and receives a corresponding receipt confirmation (41_ACK). Next, the receiver 24 sends an RTSP play command message (42) to the MMSC, and receives a corresponding acknowledgment (42_ACK). In response to the play instruction, the MMSC begins to send RTP audio (43) and RTP video (44) content to receiver 24, depending on the multimedia message being sent. Receiver 24 may control MMSC delivery of media content via RTSP message (45). Once the user of the receiver 24 wishes to pause the streaming download of the content, he requests the pause of the streaming transmission and, in response, the receiver 24 sends an RTSP pause message (46) to the MMSC, and receives a corresponding receipt confirmation (46_ACK). In response to the RTSP pause message, the MMSC pauses the delivery of the media content (RTP audio and RTP video). An RTSP teardown message (47) is then sent from receiver 24 to the MMSC to end the RTP session, allowing the streaming to continue at a later time. The MMSC returns to the receiver 24 a corresponding acknowledgment message (47_ACK).

By substituting the PLAY instruction for RECORD, a similar session suitable for media loading can be implemented in phase 1 of the invention, in which the transmitter 21 is available instead of the receiver 24.

End-to-end notification is necessary for message control functionality since, as explained above, receiver 24 requires certain information regarding media content to be streamed in order to participate in a streaming session. continuous. According to current MMS specifications, the information describing the content of the media is encapsulated together with the content of the media itself and therefore cannot be independently sent to the receiver 24. In the absence of such information, the Receiver 24 cannot download media content by streaming. By providing independent end-to-end communication of media presentation information, the method according to the invention provides receiver 24 with the information it requires to download media content by streaming. Furthermore, the existing MMS protocol without streaming has coverage to allow communication of media presentation information using end-to-end messaging through an MMS server, so that the method according to the invention is compatible with current MMS standards.

RTSP is believed to be the best way to allow and control streaming in phases 1 and 3. A certain degree of performance compromise is required if RTP / UDP is used as the media transport protocol or the TCP. Specifically, implementations that use TCP do not provide multicast functionality, since TCP is a connection-oriented protocol. However, TCP represents a viable alternative media transport protocol that can be used in connection with the present invention. In fact, its connection-oriented nature can provide advantages in certain situations, particularly if desired

ES 2 245 991 T3 a more reliable streaming connection. According to the preferred embodiment of the invention, the existing MMS protocol is used to provide end-to-end notification of presentation description information from sender 21 to receiver 24 via MMSC in phase 2.

Figure 5 shows a block diagram of a mobile terminal 50 (which can be either the transmitter 21 or the receiver 24) incorporating a cellular radiotelephone. The mobile terminal 50 comprises a display 51, a transceiver 52 for transmitting and receiving radio signals, a digital signal processor (DSP) 53 for processing data and speech by incorporating them into and extracting them from the radio signals, an input device for user such as a numeric or full keyboard 54, and a central processing unit 55, the operation of which is controlled by software. Mobile terminal 50 further comprises memory 56 for storing data and software. The memory is used by the DSP 53 and the CPU 55. The software comprises an operating system and applications to control the operation of the mobile terminal 50 and to provide certain functionality, such as MMS. The mobile terminal 50 also comprises a removable smart card such as a SIM 57 for subscriber identification. The part of the memory 56 that is dedicated to the storage of applications is the so-called non-volatile memory that maintains its content even if the power supply of the mobile terminal runs out. Applications can be stored in any manner known in the art, including factory installation, storage from a personal computer, and download over the air, for example from a server in a communication network. All these techniques are known, for example, from the Nokia® 9110 Communicator.

Figure 6 shows a radio adapter card 61 for a laptop PC 62 according to an embodiment of the invention, capable of acting as a transmitter 21 and a receiver 24. The radio adapter card is installed in a PCMCIA slot of the laptop PC 62 (PCMCIA, International Personal Computer Memory Card Association).

Although the invention has been described in connection with its implementation in a communication network in which at least a part of the network comprises a radio communication link, it should be noted that its use is by no means limited to this type of network. The invention can also be implemented in networks in which the physical connections between the various elements of the network (transmitter 21, receiver 24 and network servers) are partially or totally implemented by means of fixed line connections.

The operation of the servers and terminals involved in the different embodiments of the invention, such as the MMSC, the transmitter 21 and the receiver 24, is preferably controlled by means of computer program products that make these entities work according to the invention.

Specific implementations and embodiments of the invention have been described. It will be apparent to a person skilled in the art that the invention is not limited to the details of the embodiments presented above, but that it can be implemented in other embodiments using equivalent means, without thereby departing from the characteristics of the invention. The scope of the invention is limited only by the appended patent claims.