WO2006050751A1

WO2006050751A1 - Provision of a multimedia message

Info

Publication number: WO2006050751A1
Application number: PCT/EP2004/012881
Authority: WO
Inventors: Thorsten Lohmar; Ralf Keller; Frank Hundscheidt
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2004-11-13
Filing date: 2004-11-13
Publication date: 2006-05-18

Abstract

The idea of the present invention is to postpone the multimedia message delivery to those terminals, who have activated the download feature, but whose users are not immediately interested in watching the content. It is proposed to fragment a multimedia message into a first segment and in the at least one further segment. For the purpose of the present invention a wait timer is defined for postponing the delivery of the at least one further segment. The first segment is sent to all users and the user decides whether he or she wants to see the remaining parts of the message immediately. The first segment includes attributes allowing the user to make a decision and describing parameters of the waiting process.

Description

Provision of a multimedia message

Technical field of the invention

The present invention relates to provision of multimedia messages for telecommunications networks.

The present application might be used for delivery of messages of a multimedia message service in a wireless telecommunication network with a focus on an efficient usage of the network resources.

Multimedia Messaging Service MMS is a standard that lets users of MMS supportive mobile phones send and receive messages with formatted text, graphics, photographs, audio and video clips. Video sequences, audio clips and high- quality images can be downloaded to the phone from suitable network sides, transferred to the phone in a MMS message. MMS messages can be sent either to another MMS-enabled mobile phone or to an e-mail address and a MMS message can for example be a photo or picture post card annotated with text and/or an audio clip, a synchronized playback of audio, text, photo and video emulating a free-running presentation or a video clip. The Multimedia Messaging area covers both the person-to-person communication as well as the content-to- person mobile media sphere.

Multimedia messaging requires high transmission speeds. In particular the transmission speed is an issue in wireless telecommunication systems. Mobile telecommunications networks, such as the third-generation wireless networks (UMTS Universal Mobile Telecommunication System) or GPRS (General Packet Radio System) aim to provide services such as voice, data, and multimedia via computing devices over network infrastructures. Moreover, existing GSM networks support the MMS technology by means of an additional infrastructure, like a Multimedia Messaging Centre (MMC) .

Nowadays it is common to provide a node like the MMC being responsible for supporting multimedia messaging in a network. The Multimedia Messaging Center (MMC) implements the network side of Multimedia Messaging Service, and makes it possible to offer multimedia messaging to the mobile subscribers. The MMC manages different sources to/from mobile terminals, supporting a range of interfaces.

In addition to the submission and delivery of mobile multimedia MM message, the MMC also offers functionality to store and forward messages, guarantee delivery, provision of subscriber preferences, customize operator constraints, and track billing information.

In the following two nodes of a MMS architecture, which will be further used as an embodiment of the present invention, are described in some details, the MMS User Agent and the MMS Relay/Server.

The MMS User Agent resides on a user side. It is an application layer function that provides the users with the ability to view, compose and handle MMS messages (e.g. submitting, receiving, deleting of MMs) .

The MMS Relay/Server is responsible for storage and handling of incoming and outgoing messages and for transfer of the messages between different messaging systems. Depending on the network model, the MMS Relay/Server may be a single logical element or may be separated into MMS Relay and MMS Server elements. These may be distributed across different locations in a network or even across different domains.

The MMS Relay/Server also provides convergence functionality between External Servers and MMS User Agents and thus enable the integration of different server types across different networks.

Thus, the MMS Relay/Server provides for example the following functionalities: receiving and sending von multimedia messages MM, MM notification to the MMS User Agent; generating delivery reports; routing forward MMs and read- reply reports; address translation; temporary storage of messages; ensuring that messages are not lost until successfully delivered to another MMSE element;

The MMS architecture defines a number of interfaces providing connection to different nodes within the architecture. In the following some interfaces relevant for the present invention are described shortly in respect to Fig.l. Fig.l depicts schematically a network with a MMS User Agent A communicating with a MMS User Agent B over a corresponding MMS Relay/Server A and MMS Relay/Server B nodes. Moreover, the interfaces, MMl and MM4 between the certain nodes are shown.

MMl is an interface between the MMS User Agent and the MMS Relay/Server. It is used to submit multimedia messages from MMS User Agent to MMS Relay/Server. Furthermore, over the MMl the MMS User Agent pulls multimedia messages MM from the MMS Relay/Server. The MMS Relay/Server pushes information about the multimedia messages MMs to the MMS User Agent as part of a multimedia message MM notification. The MMl is also used to exchange delivery reports between MMS Relay/Server and MMS User Agents. The interface between MMS Relay/Server and another MMS Relay/Server is called MM4 and is used to transfer messages between these nodes.

A number of applications in the current telecommunication systems are one-to-many applications, where one or a few sources are sending data to many receivers. This kind of transmission is also foreseen in the MMS, wherein a group of users receiving the same content might be defined. For the purpose of defining the groups of users an interface between the MMS Relay/Server and MMS Value Added Service VAS Applications, the MM7 is used. The responsibility of the VASP is to provide the MMS Relay/Server with group messages which are to be distributed amongst the recipients. In some cases, the list of recipients is given in form of a "group id" (like a virtual MSISDN) and the MMSC need to resolve the individual phone numbers of the list members.

In the following an exchange of multimedia messages is described in respect to Fig.2, which shows an originator MMS User Agent UA communicating over MMl interface with originator MMS Relay/Server, which subsequently communicates with recipient MMS Relay/Server over MM4 interface. The last mentioned node uses MMl interface to transfer the messages to a recipient MMS UA. Fig.2 presents the technical realisation of MMS service features in terms of abstract messages. The abstract messages can be categorised into transactions consisting of requests and responses. The labelling of the MMS abstract messages follows these conventions, wherein the transactions between the MMS UA and MMS Relay/Server are prefixed with "MMl"; the transactions between the MMS Relay/Servers are prefixed with "MM4"; requests are identified with ".REQ" as a suffix and responses are identified with the ".RES" suffix. Multimedia messages are sent from the originator MMS UA to the originator MMS Relay/Server, MMl_submit.REQ, and forwarded to the recipient MMS Relay/Server, MM4_forward.REQ. Before a message is sent to a further node, the reception of the message is acknowledged to the sending node, MMl_submit.RES, MM4_forward.RES. The recipient MMS Relay/Server notifies the recipient MMS UA about the MMS, MMl_notification.REQ, MMl_notification.RES, upon which the recipient MMS UA retrieves the MMS content, MMl_retrieve.REQ. The content retrieval, MMl_acknowledgement.REQ and the read- reply, MMl_read_reply_recipient.REQ are acknowledged by the recipient UA and returned to the originator MMS Relay/Server and eventually to the originator MMS UA.

Hence it appears, that the information exchange according to the MMS architecture is based on the store and forward principle, wherein every node on the transmission way between the communicating nodes stores the received message before said message is forwarded to a subsequent node. This principle ensures a peer-to-peer delivery and in the end a end-to-end delivery of a message. However on the other side said principle is time and resource consuming, in particular in case of transmission of a large-scale multimedia message to a group of users.

Currently, more and more operators offer content to person or application to person messaging services, also called MMS- Push services. Such services are group services, which distribute the same information to a large set of registered terminals.

The penetration rate of MMS compliant terminals is increasing, therefore it is foreseen, that also the number of potentially registered terminals per service is increasing. Also the multimedia capabilities, such as resolution of the displays are increasing, which means that the messages itself can grow in size on average with high peak message sizes. This evolution leads to some problems with resource provision, because an increased amount of data is to be transmitted over the network. If additionally the increasing number of group services is considered, then the issue of resource provision seems to be even more critical.

Currently a number of MMS retrieval modes are defined. MMS allows the retrieval of MMs in a manual or automatic fashion. The retrieval mode is a terminal behavior and is based on different factors. These factors might include message size, MMS User Agent configuration, recommendation from the MMS Relay/Server for retrieval and the originator of a multimedia message.

In manual mode the end user is made aware of the MM notification and is allowed to make a decision whether to download the MM or not. In this mode the end user is aware of an MM notification.

In automatic mode, hereinafter also called auto-download, the retrieval of a multimedia message MM and its storage to local memory is accomplished without any interaction with the end user. Depending on terminal implementation, the MM may be displayed to the end user with or without any pre-notice.

The auto-download provides a more convenient access of the user to the received multimedia messages MMSes since the user get the multimedia message automatically into their terminals. If the user has not recognised the reception of the pre-notice notification, which might be implemented as New-Message Alert, the terminal starts retrieving the message on its own. Unfortunately, this type of download consumes the same network resources as the retrieval procedures of terminals with users who recognised the alert message and requested the downloading immediately. That results in the problem, that the downlink transmission path is loaded with traffic for users, who have recognise the notification message and are waiting for the actual content, but also with traffic for users, who have not recognised the notification message, but have activated the auto-download function, which means that they do not want or they are not able to watch the multimedia message by receiving the notification.

Summary and description of the invention

It is an object of the present invention to provide a solution for an efficient usage of network resources during transmission of multimedia messages.

The invention is disclosed in claims 1, 12, 20 and 21. Advantageous embodiments are described in the dependent claims being disclosed in the corresponding parts of the description.

The basic idea of the present invention is to provide a solution for a delivery of a multimedia message for a communication network having a user part and a network part wherein the network part is responsible for distribution of the multimedia message to at least one user part and the method comprising the following steps to be performed by the network part. At first the network part provides a multimedia message, which is to be distributed. Subsequently a fragmentation procedure is performed for fragmenting a message into a first segment and at least one further segment wherein the first segment includes information about a possibility of time-delayed reception of the at least one further segment of the multimedia message and a reference to the at least one further segment. Subsequently the first segment is sent to the user part and a waiting process is started according to the information about the possibility of the time-delayed reception of the at least one further segment of the multimedia message. Upon an event message is received, the at least one further segment is sent to the user. Herein it is to be emphasized, that the implementation of the event might be performed in any preferably and suitably way. For example it might be a message received form the network side or from the user. Furthermore it might be for example an expiration of a timer.

Further it is proposed to have a solution on the user part in the above-defined network, wherein the user part receives a first fragment of the multimedia message including information about a possibility of time-delayed reception of at least one further segment of the multimedia message and a reference to the at least one further segment. Hereby it is to be mentioned that the information about the possibility of the time-delayed reception means that all users receive the first fragment and the user decides considering said information whether the at least one further segment is to be downloaded immediately or time-delayed.

Subsequently a notification procedure for receiving the at least one further segment of the multimedia message is performed. Said notification procedure is to be performed either user-driven by means of active requesting the downloading of the remaining segments or time-delayed by means of generation an automatically requesting of the downloading of the remaining segments, for example by consideration of a timer. Finally an appending procedure for appending the received fragments into the multimedia message is performed. Furthermore it is proposed to have a network part adapted to deliver a multimedia message for a communication network having a user part and said network part wherein said network part is responsible for distribution of the multimedia message to at least one user part. Said network part has a provision logic providing a multimedia message that is to be distributed. Herein the multimedia message might be either generated in the network part or received from an extern al node, for example a server. Further it has a fragmentation controller for fragmenting a message into a first segment and at least one further segment wherein the first segment is adapted to include information about a possibility of time- delayed reception of the at least one further segment of the multimedia message and a reference to the at least one further segment. The first segment is sent by a sender for sending the first segment to the user part. A processor is used which is adapted to perform a waiting process according to the information about the possibility of the time-delayed reception of the at least one further segment of the multimedia message. Furthermore the network part has a sender for sending the at least one further segment of the fragmented multimedia message upon receiving an event message.

Moreover it is proposed to have a user part adapted to deliver a multimedia message for a communication network having said user part and a network part wherein the network part is responsible for distribution of the multimedia message to at least one user part. Said user part has a receiver for receiving a first fragment of the multimedia message including information regarding a waiting process for a possibility of time-delayed reception of at least one further segment of the multimedia message and a reference to the at least one further segment. Further it has a processor for performing the waiting process according to the information about the possibility of the time-delayed reception of the at least one further segment of the multimedia message. A controller for performing a notification procedure for receiving the at least one further segment of the multimedia message is also a part of the user part. The received fragments are appended into the multimedia message by means of an appendix logic.

The present invention discloses also a system adapted to deliver a multimedia message for a communication network having a user part and a network part wherein the network part is responsible for distribution of the multimedia message to at least one user part and with the network part according to claim 19 performing the method according to claim 1 and communicating with the at least one user part according to claim 20 performing the method according to claim 12.

The advantage of the present invention is that the overall service perception would be increased, because those terminals with waiting users are served first and those terminals with background auto-download mode are served at a later stage, because the download for this group is to be postponed to a later stage.

In the following preferred examples of the present invention shall be described in detail, in order to provide the skilled person with thorough and complete understanding of the invention, but these detailed embodiments only serve as examples of the invention and are not intended to be limiting. The following description shall make reference to the enclosed drawings, in which

Fig.l shows a schematic representation of a multimedia messaging network architecture, Fig.2 shows a schematic representation of messages exchange according to state of the art,

Fig.3 shows a flowchart of an embodiment of the present invention for delivery of a multimedia message in the network part,

Fig.4 shows a flowchart of an embodiment of the present invention for delivery of a multimedia message in the user part,

Fig.5 shows a schematic representation of messages exchange according to one embodiment of the present invention with a timer located in the user part,

Fig.6 shows a schematic representation of messages exchange according to one embodiment of the present invention with a timer located in the network part,

Fig.7 shows a schematic representation of messages exchange according to one embodiment of the present invention with a user's interaction during running timer.

It should be noted that the terms "relay", "user", "server", or generally "node" in the context of the present invention refers to any suitable combination of hardware and software for providing a predetermined functionality in the communication network. In this way, said terms generally refers to a logical entity that can be spread out over several physical nodes of the network, but can also refer to a physical entity located in one physical node.

Furthermore it should be noted that the term multimedia messaging refers to any large-scale message, which might be fragmented in a certain way. A multimedia message refers for example to music, videotext or video-clips, wherein one message can contain a number of multimedia file and the fragmentation is done in respect to the included files. Hence, the invention is not restricted to the Multimedia Message Service, which merely is used as a preferred embodiment.

Preferably, the communication network is a mobile communication network, e.g. is a mobile communication network operating according to GPRS (General Packet Switched Radio) or UMTS (Universal Mobile Telephone System) or GSM. However, the present invention is also applicable in any communication network providing multimedia messaging.

The idea of the present invention is to postpone the multimedia message delivery to those terminals, who have activated the download feature, but whose users are not immediately interested in watching the content. Thus, in the frame of the present invention a new user group is defined. This group includes users, who activated the auto-download feature, but who are not immediately interested in the content. This kind of users activates the auto-download mode, because they want to have the content available in their terminal, although they do not want or can watch it immediately. Since those users have activated the auto- download feature, they also expect some play-out immediately or at least quickly, that means they do not want to spend time for downloading. The difference to users with the manual retrieval mode is that they download the multimedia message by means of an explicit requesting the downloading.

In order to achieve the goal the following solution is presented. Herein a differentiation is made regarding the place of performance certain steps. The differentiation is made between a network part and a user part. The steps to be performed in the network side are described in the following in respect to Fig.3.

The network part might be implemented in any suitable combination of hardware and software being able to perform hereafter described steps. In this way, said terms generally refers to a logical entity that can be spread out over several physical nodes of the network, but can also refer to a physical entity located in one physical node, like for example the MMS Relay/Server.

The user part is to be implemented preferably on the user equipment.

According to Fig.3 a received multimedia message, S31 is to be subdivided into two or more fragments, S32. In the preferred embodiment it is proposed to consider multimedia messages being foreseen for a group of user. However the invention is not restricted to this kind of messages. Thus, the present invention is also applicable to a multimedia message for a single user.

In a preferred embodiment it is proposed that the fragmentation procedure includes the organization of the multimedia components within the message for progressive play-out. The first segment includes further attributes of the multimedia message specifying behaviour of the user part receiving the multimedia message. The receiver behaviour describes the process to get the next fragment. It describes, if the receiver needs to fetch the next fragment by itself or it just needs to wait until the network provides the next fragment. Moreover it might be for example information regarding mechanisms to download the remaining fragments, which are an indication to wait for the network trigger or value or value-range for the user's terminal wait timer or URLs or URL construction rules for the next fragments or optionally a unique identifier to relate further fragments to the first fragments.

Preferably, the message length and a prediction of group size mainly determine the waiting time between the first and the further fragments. In case of subscription services (services, where a terminal needs to register with its identifier with the network) , the network knows exactly the size of the total group. Important for the calculation of the wait timer is share of users, who would like to see the message immediately. For example a following scenario is given: total group size: 100.000 users; expected share of users, who are interested to see the clip immediately: 40%, group estimation to calculate the wait time: 40.000 users, then for this example, the waiting time would depend on "How long does it take, that 40.000 users retrieve the entire message (e.g. 3Mbyte) and 60.000 users only retrieve the first fragment, (e.g. 0.5Mbyte) ."

Preferably it is proposed that the length of the first fragment of the message is chosen in such a way, that the terminal can download a next fragment, while playing-out the first segment. This principle can be repeated for all further parts of the message. It is to be noted that the dimensioning of the first fragment depends also on the capabilities of the access network.

Furthermore it is proposed that the further attributes are included in a header, which is inserted into the first segment. Said header specifies the fragmentation and includes a unique reference to the next message fragment. The result of the fragmentation procedure is a multimedia message being subdivided in a first segment and in at least a further segment. The number of segments might depend on message size, the audience sizes and the operator's preference for this procedure.

Furthermore in case the network part sends a segment during a congestion of the network then the segment might include information that the remaining part is in the subsequent segments. Thus, the description of a previous fragment or the total message may be part of a later fragment.

Upon the fragmentation procedure is finished, the network part sends a first segment to the user, S33. It is to be noted, that preferably the notification message is sent to a group of users being interested in receiving the message. Possible methods of building users' group for a certain kind of multimedia messages are out of scope of the present invention. The notification message in this context might be realised in any suitably way. In one embodiment the notification message is the first segment being sent to the group of users . Alternatively it is proposed that the network part sends a notification message and upon receiving an answer from a user the first fragment of the message is to be sent. The advantage of the last mentioned solution is a simpler integration into systems having a separated notification message implemented.

It is proposed that the network part determines the waiting process and when the first segment is sent out the waiting process is started. In the frame of the waiting process a timer is started and upon elapsing of said timer an event message is generated to trigger sending of the at least one further segment of the multimedia message. In respect to Fig.3 a waiting process is started is step S34. In this phase the network part waits for receiving an event requesting sending of the remaining fragments, S35, wherein the implementation is to be realised in any suitable way. In one embodiment it is proposed to have a timer running on the network side. The elapsing of said timer without receiving any request from the user results in an event for starting with the sending of the remaining segments. In a further embodiment it is proposed that the network part waits for receiving a request message from the user part. Herein the timer is implemented on the user side and upon expire of the timer a request message is sent to the network part unless there is an interaction from the user in the meantime then the request message is sent before the expiration of the timer.

When the network part determines a waiting process this is to be sent with the first segment to the user part. Therefore the first frame must contain a description of the waiting procedure, fixed pre-determined waiting time or random waiting time or the retrieval procedure and the object to retrieve (e.g. URL) . In case a random waiting time procedure, the UE determines the waiting time randomly by itself. A minimal and maximal waiting time (or an offset and a random window) is specified. Further more the time might be a description of a specific trigger message. Preferably the waiting timer is determined by a length of the multimedia message and a prediction of a group size of user parts receiving the multimedia message.

Finally the remaining fragments of the multimedia message are sent to the users, S36.

In the following the steps are described which are to be performed on the user part in respect to Fig.4. On the user part the terminals download the first fragment of a multimedia message, S41, wherein the first fragment includes further attributes of the multimedia message specifying downloading process of said multimedia message. Herein the information regarding downloading process includes an indication to wait for the network trigger or value or value-range for the user's terminal wait timer or URLs or URL construction rules for the next fragments or optionally a unique identifier to relate further fragments to the first fragments .

Further it is proposed that the information regarding downloading process includes information about an implementation of a timer for triggering a downloading of the at least one further segment. Thus, the received first segment includes the information regarding the content of the message and the waiting process .

The proposed timer might be a random wait timer or a description of a specific trigger message. The implementation of the timer might be either on the user part or in the network part and the user part receives a notification about the expiry of the timer.

Furthermore it is proposed that a user part which decides during the waiting process to download the at least one further segment sends an explicit request for downloading the at least one further segment.

Furthermore the first segment might include further information regarding the mechanisms to download the remaining fragments, like for example an indication to wait for the network trigger or value or value-range for the user's terminal wait timer or URLs or URL construction rules for the next fragments or optionally a unique identifier to relate further fragments to the first fragments.

In case a user would like to watch content on a later stage, the users' terminals need to process the received first part to determine the handling of this message. As aforementioned the first part of the message may contain different information. For example regarding the implementation of the timer before downloading the remaining parts . This might be for example either a random wait time or a description of a specific trigger message. In particular the timer is to be set in a way that on one side it does not last to long before a request for downloading is sent. On the other side with the timer delay it should be achieved that a parallel downloading of multimedia messages for users being immediately interested and for those who are not, is avoided.

Returning to Fig.4, a user part receives the first fragment and decides to start the waiting process and according to the current availability of the user, a notification procedure, S42 is started. Herein it is to be distinguished whether the notification is user-driven, S43 or time-delayed, S44. Herein is to be noted, that the user-driven notification might be either performed immediately after receiving the first segment or during a running timer.

The succeeding fragments are downloaded directly only by those terminals, which have users being interested in an immediate viewing of the message, S43. The immediately ability of the user to watch a content is accomplished by performing an interaction with the terminal. Herein it is to be mentioned that preferably upon the receipt of the first fragment the rendering process has been started since the first message includes already parts of the multimedia message. Moreover, a user-driven notification procedure is performed in case a user does not react immediately but delayed during the running timer. That means is proposed that a user, who does not immediately react after receiving the first fragment, has also a possibility to react during the running timer. That means in case a user does not react immediately and a timer has been started the user should not be bound by the running timer, but a possibility is to be provided to request the downloading of the remaining fragments also during the waiting period. Preferably, it is proposed that a user by means of a user interface sends a request message to the network part.

The remaining terminals, which are not interested immediately in view the multimedia message wait with the downloading of the remaining fragments by starting a time-delayed notification procedure, S44 and by waiting until the timer expires. The time-delayed procedure might be realized in any suitably way. In one embodiment it is proposed to have a timer being started on the user side. The elapsing of the timer causes a notification to the user for requesting the remaining fragments. In a further embodiment it is proposed to start a timer in the network part and upon elapsing the timer, the network part might either starts to send the remaining parts of the multimedia message or it might sends a notification message to the user in order the user requests the remaining parts.

In the last step, S45 the user's terminal appends the received fragments of the multimedia message. Herein the appending of a second to a first fragment might happen while the first part is already displayed on the screen.

In the following a description of a preferred embodiment of the present invention in accordance with MMS is provided. In this embodiment it is proposed that a node, called Multimedia Message Service Centre MMSC fragments the Multimedia Message into several fragments. Said MMSC server might receive the MMS message over the MM7 interface from an external network. Each fragment becomes an individual file, which can be addressed via an URL. The MMSC indicates the fragmentation and also the link to the next fragment in the first fragment. The MMS also indicates the trigger mechanism, which might be a part of the first fragment for starting downloading the remaining fragments of the MMS.

It is the task of the user' s terminal to append the received fragments of a message to the first fragment, wherein the appending of a second to a first fragment might happen while the first part is already displayed on the screen. It is preferably that the length of the first fragment is roughly determined by the download time of the next fragment. This approach enables a smooth progressive download since it is possible to finish the download of the next fragment before finishing the play-out of the first segment.

In the following, the individual steps of the distribution process in respect to Fig. 5, Fig.6 and Fig.7 are described in more details. The figures present a chronological exchange of messages between a recipient MMS Relay/Server and a recipient MMS UA.

In the first step the recipient MMS Relay/Server receives the group MMS message. In Fig.5 it is received by means of MM4_forward.REQ and MM4_forward.RES messages, but as mentioned before it can be also by means of the MM7 interface for communication with other domains. Upon receiving the MMS message the recipient MMS Relay/Server fragments the message into several smaller parts. Each fragment may be retrieved by recipient MMS UA via different URL. In a subsequent step the recipient MMS Relay/Server sends a notification message, MMl_notification_REQ and MMl_notification_RES, to all User Agents i_<o that group. The notification message contains a URL to the first fragment of the MMS.

Hence, upon receiving the notification message, the recipient MMS UA starts downloading the first fragment in case the auto-download option is activated. This is done by means of exchanging the messages, MMl_retrieve.REQ and MMl_retrieve_RES. Preferably, the user is notified about the downloading of a first fragment via the User Interface.

In this phase the recipient MMS UA might react in two different ways. In case the user is interested in receiving the entire MMS message immediately it sends directly a request for the remaining fragments. This reaction is shown in Fig. 7 by means of the second the second MMl_retrieve.REQ and MMl_retrieve RES exchange being sent without any time delay. Thereafter the download of fragments 2-N is carried out. Thus, the user agent, recipient MMS UA starts to download the remaining fragments immediately. The fragments may be downloaded one by one before starting the rendering process or even in a progressive download way. The received fragments may be merged locally in the user' s terminal as the user has the ability to append the received information of further fragments to the first file. Optionally, the remaining part of the multimedia message might be streamed to the user. In this case the content is provided via a streaming server and the UE uses automatically the streaming application in the phone to render the next fragments. Optionally, the content download via MMS is completed some time after the streaming transmission. This option (and the configuration) depends on operator preferences. Alternatively before sending a direct request, the user might want to process the header information for finding flags for the fragmented MMS delivery in order to take a decision whether to download directly or time-delayed.

However, if there is no user interaction for a defined time, then the user agent has processed the header information. The header describes available mechanisms to download the remaining fragments of the multimedia message. Herein two different choices might be provided.

The first possibility is that the user's terminal starts a timer. This alternative is depicted in Fig.5 showing a waiting timer on the recipient MMS UA side. After a timer in the user's terminal is expired, the retrieval of the remaining parts is started. The timer value can be random chosen by the user agent or be a part of the header information. In the first case, preferably the upper bound for the random interval is contained in the header. In the later case the timer value is be explicitly contained in the header. In this case, the MMSC or recipient MMS Relay/Server may need to provide each user agents with its own timer-value within the first message fragment.

The header also contains the URL(s) of the next fragments. The URLs may be given explicitly (one or more URLs) or a method is to be provided how to construct the URL, whereby the sequence number is part of the URL.

In an alternatively embodiment it is proposed to have the waiting process being triggered by the network part as it is depicted in Fig.6 showing a waiting timer on the recipient MMS Relay/Server side. In this case the network sends another notification message (i.e. SMS) to trigger the downloading process of the remaining fragments, MMl_notification_REQ and MMl_notification RES. The notification message contains a unique reference to the fragmented message. Since the user keeps track on the received messages, it is known to the user that this is a subsequent fragment. And therefore the user agent appends the received fragment to the previous fragment.

Subsequently in all cases the downloading of the fragments 2- N is performed. Closing, the receipt of the entire message is acknowledged to the recipient MMS Relay/Server,

MMl_acknowledge.REQ and subsequent to the sending node, herein by means of MM4 delivery report.REQ.

The preferred embodiment was based on the MMS although it should not be seen as a restriction to the present invention. In fact the proposed method can be used for any kind of multimedia message which can be fragmented. For instance the method can be used for WAP-Push messages. Moreover the presented embodiments show the applicability of the present invention for submission of multimedia messages to a group of users. However, the same procedure applies also for submission of a multimedia message to a single user.

However these are merely examples showing that by means of interfaces additional information might be queried to ensure a better performance of the resource management procedure according to the present invention.

Claims

1. Method for delivery of multimedia message for a communication network having a user part and a network part wherein the network part is responsible for distribution of the multimedia message to at least one user part and the method comprising the following steps to be performed by the network part - providing a multimedia message to be distributed and, performing a fragmentation procedure for fragmenting a message into a first segment and at least one further segment wherein the first segment includes information about a possibility of time-delayed reception of the at least one further segment of the multimedia message and a reference to the at least one further segment and, sending the first segment to the user part and, - performing a waiting process according to the information about the possibility of the time- delayed reception of the at least one further segment of the multimedia message and, upon receiving an event message sending the at least one further segment of the fragmented multimedia message.

2. Method according to claim 1 wherein the multimedia message consists of one or several data files being constricted in a way to allow progressive playout.

3. Method according to claim 1 wherein the first fragment includes further attributes of the multimedia message specifying behaviour of the user part receiving the multimedia message.

4. Method according to claim 3 wherein a length of the first fragment is determined by the download time of the at least one further segment.

5. Method according to claim 1, 3, 4, 5 or wherein in the fragmentation procedure it is considered that the first fragment contains at least a full header of the multimedia message.

6. Method according to claim 1 wherein the waiting process includes starting of a timer and upon elapsing of said timer an event message is generated to trigger sending of the at least one further segment of the multimedia message.

7. Method according to claim 1 wherein the waiting process is a waiting state for receiving a request message from the user part.

8. Method according to claim 1 wherein the waiting process is a wait timer being determined by a length of the multimedia message and a prediction of a group size of user parts receiving the multimedia message.

9. Method according to claim 3, 6, 7 or 8 wherein the first segment includes information about an implementation of a timer for triggering a downloading of the at least one further segment.

10. Method according to claim 9 wherein the timer is a random waiting timer or a description of a specific trigger message.

11. Method according to claim 9 or 10 wherein the timer is implemented on the network part.

12. Method for delivery of multimedia message for a communication network having a user part and a network part wherein the network part is responsible for distribution of the multimedia message to at least one user part and the method comprising the following steps to be performed by the user part receiving a first fragment of the multimedia message including information regarding a waiting process for a possibility of time-delayed reception of at least one further segment of the multimedia message and a reference to the at least one further segment and, performing the waiting process according to the information about the possibility of the time- delayed reception of the at least one further segment of the multimedia message and, performing a notification procedure for receiving the at least one further segment of the multimedia message and, performing an appending procedure for appending the received fragments into the multimedia message.

13. Method according to claim 12 wherein the first fragment includes further attributes of the multimedia message specifying downloading process of the multimedia message.

14. Method according to claim 12 or 13 wherein the information regarding downloading process includes information about an implementation of a timer for triggering a downloading of the at least one further segment.

15. Method according to claim 14 wherein the timer is a random wait timer or a description of a specific trigger message.

16. Method according to claim 12, 13 or 14 wherein the timer is implemented in the user part.

17. Method according to claim 12, 13 or 14 wherein the timer is implemented in the network part and the user part receives a notification about the expiry of the timer.

18. Method according to one of the claims 12 to 17 wherein during the waiting process a user part sends an explicit request for downloading the at least one further segment.

19. Network part adapted to deliver a multimedia message for a communication network having a user part and said network part wherein said network part is responsible for distribution of the multimedia message to at least one user part and has provision logic providing a multimedia message that is to be distributed and, fragmentation controller for fragmenting a message into a first segment and at least one further segment wherein the first segment is adapted to include information about a possibility of time- delayed reception of the at least one further segment of the multimedia message and a reference to the at least one further segment and, sender for sending the first segment to the user part and, - processor for performing a waiting process according to the information about the possibility of the time-delayed reception of the at least one further segment of the multimedia message and, sender sending the at least one further segment of the fragmented multimedia message upon receiving an event message.

20. User part adapted to deliver a multimedia message for a communication network having said user part and a network part wherein the network part is responsible for distribution of the multimedia message to at least one user part and with receiver for receiving a first fragment of the multimedia message including information regarding a waiting process for a possibility of time- delayed reception of at least one further segment of the multimedia message and a reference to the at least one further segment and, processor for performing the waiting process according to the information about the possibility of the time-delayed reception of the at least one further segment of the multimedia message and, controller for performing a notification procedure for receiving the at least one further segment of the multimedia message and, appendix logic for appending the received fragments into the multimedia message.

21. System adapted to deliver a multimedia message for a communication network having a user part and a network part wherein the network part is responsible for distribution of the multimedia message to at least one user part and with the network part according to claim 19 performing the method according to claim 1 and communicating with the at least one user part according to claim 20 performing the method according to claim 12.