WO2002058359A1 - Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz - Google Patents

Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz Download PDF

Info

Publication number
WO2002058359A1
WO2002058359A1 PCT/EP2001/014617 EP0114617W WO02058359A1 WO 2002058359 A1 WO2002058359 A1 WO 2002058359A1 EP 0114617 W EP0114617 W EP 0114617W WO 02058359 A1 WO02058359 A1 WO 02058359A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
mms
identification signal
message
content
Prior art date
Application number
PCT/EP2001/014617
Other languages
English (en)
French (fr)
Inventor
Andreas Schmidt
Markus Trauberg
Josef Laumen
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to JP2002558717A priority Critical patent/JP4358511B2/ja
Priority to EP01273297A priority patent/EP1352500B1/de
Priority to US10/466,749 priority patent/US8099081B2/en
Publication of WO2002058359A1 publication Critical patent/WO2002058359A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/224—Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support

Definitions

  • the invention relates to a method for data transmission in a mobile network according to the preamble of claim 1 and a mobile telecommunication device according to the preamble of claim 26, a computer program product according to claim 30, and a radio communication system according to claim 32.
  • SMS Short Message Service
  • the invention is based on the problem of simplifying the control of the data transmission for subscribers of a mobile radio network.
  • the invention solves this problem by a method having the features of claim 1, and by a mobile telecommunication device having the features of claim 26, a computer program product having the features of claim 30, and by a radio communication system according to claim 32.
  • a method having the features of claim 1 and by a mobile telecommunication device having the features of claim 26, a computer program product having the features of claim 30, and by a radio communication system according to claim 32.
  • the identification signal (s) indicating the characteristics of the data to be sent is sent in advance, the check is already possible before the actual data is received, with the recipient being particularly advantageously given a choice of whether or not to use the available data now or later don't want to receive at all. If the option of partial reception of a multimedia message (MM) is also provided, the recipient can, for example, only download brief information that is important to him, which requires a short transmission time, and possibly download associated memory-intensive image components or the like later or not at all.
  • MM multimedia message
  • the recipient can use this to determine how much time he has to calculate for the transmission and / or the study of the data and whether he does this now or at a later time or not at all wants to muster.
  • the identification signal contains information about the name of a data record
  • the recipient can use it to determine the subject area from which the data originate.
  • he can advantageously select whether he wants to receive this or these data record or data records now or at a later time or not at all.
  • Information about the data type can also be given particularly advantageously in the identification signal , so that the receiver knows whether it is, for example, image data, text data and / or music data.
  • FIG. 1 shows a schematic illustration of a transmission assigned to data transmissions in accordance with the WAP standard (wireless application protocol) between the level of the sender and that of the provider on the one hand and the level of the provider and that of the recipient on the other.
  • WAP standard wireless application protocol
  • FIG. 2 shows the header fields of a message M-Send.req sent according to the WAP standard shown in FIG. 1, the header fields newly inserted according to the invention being shaded in gray,
  • FIG. 3 shows a specification of the type of the information shown in FIG. 2 and stored in the fields with a gray background, as well as of the additional field in the status report regarding the receipt of the mailed
  • Fig. 4 shows the assignment of the header fields from FIG. 2 to the binary codes, the header fields newly inserted according to the invention being grayed out
  • Fig. 5 is a view similar to Fig. 2 according to the example shown in Fig. 1 WAP standard transmitted by directing ⁇ M-Notification.ind (MNI)
  • FIG. 6 shows a representation similar to FIG. 2 of the message M-Retrieve.conf (MRC) sent according to the WAP standard shown in FIG. 1,
  • FIG. 7 shows a representation similar to FIG. 2 of the message M-Acknowledge.ind (MAI) sent according to the WAP standard shown in FIG. 1,
  • FIG. 8 shows a representation similar to FIG. 2 of the message M-Delivery sent according to the WAP standard shown in FIG. 1. ind. (MDI),
  • FIG. 18 the encoding of a single header field name
  • FIG. 20 assignment of binary codes to the field names of the parameters in the single header field according to FIG. 9,
  • 21A, 21B the only header fields of a multimedia service (MMS) send request (in WAP message M- Send. req; ) , and
  • MMS multimedia service
  • the application of the invention to a data transmission scheme 1 for the WAP standard as it is used in the transmission of, in particular, image data and formatted text data in the UMTS standard (Universal Mobile Telecommunication Standard), is described. It is understood that the invention can also be applied to other standards.
  • the UMTS standard provides, in addition to the previous SMS, a so-called MMS (multimedia messaging service) for the transmission of messages, also known as multimedia messages (MMs). It can also be used to transmit formatted texts and images with and without sound.
  • MMS multimedia messaging service
  • MMs multimedia messages
  • the SMS limit of 160 characters is no longer applicable. A transmission of audio and video messages is possible.
  • MMS can be implemented using WAP.
  • the protocol scheme shown in FIG. 1 (WAP WSP: Wireless Session Protocol) is used for the radio transmission of data, for example multimedia messages (MMs).
  • MMs multimedia messages
  • This comprises a level 2 of a data sender (also referred to as MMS User Agent A), a level 3 of a provider (whose network element that performs the service is also referred to as an MMS relay) and a level 4 of a recipient (also referred to as MMS user Agent B).
  • Level 2 of the data sender comprises at least one telecommunication device 5, and level 4 of the receiver also includes a telecommunication device 6.
  • These telecommunication devices 5, 6 can be designed, for example, as conventional mobile phones or as devices with further input or display functions, such as laptops ,
  • a in the telecommunications device 5 of the sender or abbreviated to this to be forwarded multimedia message can contain one or more units (data records 7), for example individual images, film sequences, texts or the like.
  • the MM is first sent to the provider (level 3) as request 9 (this is called M-Send.req in the WAP protocol).
  • the received shipment 9 is acknowledged with the return shipment 10 (M-send. Conf) to the sender (level 2).
  • the provider (level 3) sends information 11 (M-Notification. Ind) to the recipient (level 4), with which the recipient is informed that a message from provider 3 is available for downloading.
  • the provider 3 automatically receives the acknowledging feedback 12 (M-NotifyResp. Req) from the telecommunication device 6 of the recipient (level 4).
  • the final message 16 (M-Delivery. Ind) returns an acknowledgment of receipt to the sender 2.
  • the management of mailings 9, 10, 11, 12, 14, 15, 16, the so-called. Header fields are used, so the actual MM vorange Kings ⁇ set fields that contain information about the origin, transmission time, file size and other details - no.
  • the number of header fields is increased in order to be able to inform at least one further field 17, 18, 19, 20, 21, 22, 23 as information field (s) about characterizing parameters of the MM and to contain one or more identification signal (s) to be able to send the receiver 4 for these parameters.
  • the fields 17, 18, 19, 20, 21, 22, 23 addressed with 0x80 to 0x86 in the hexadecimal system are provided for this (see FIG. 4) in order to provide information about the parameters, which will be described in more detail below. take.
  • a different number and / or addressing of the additional header fields is also possible.
  • the additional header fields 17, 18, 19, 20, 21, 22, 23 mentioned are at least included in message 11 (M-Notification.ind), with which the recipient 4 is informed about the availability of an MM.
  • the message 9 (M-Send.req) can also contain the additional header fields 17, 18, 19, 20, 21, 22, 23 if the additional parameters are generated by the sender 2 (FIG. 2), likewise the actual MM delivery 14 (M-Retrieve. conf) (see FIG. 5) or further messages 10, 12, 13, 15, 16.
  • a data record 7 of an MM is understood to mean an individual component of an MM which is defined by its type (for example still picture) and its format (for example JPEG), a format conversion by the MMS relay 3 also being provided in the MMS, which ensures that also Telecommunication devices 6 of a receiver 4, which only support certain formats of one type, are also only operated with these formats.
  • a telecommuni ⁇ can cation device 6 to display only still images in JPEG format, which it has communicated in its application to the MMS Relay 3rd
  • the MMS Relay 3 then converts all still images received for this recipient into JPEG format, which generally changes the file size. This aspect is relevant for a later consideration of the header fields which are new according to this invention.
  • the following information about a data record 7 can be contained as an identification signal.
  • the information is optionally made available to the recipient of an MM when using the WAP standard (FIG. 1) in the notification 11 (M-Notification. Ind), and thus before the actual data is transmitted in the multimedia message.
  • Possible parameters of data to be transmitted, in particular an MM, about which the recipient is informed in advance are:
  • the respective content ID (content IDentification) of a data record may also be relative to the content
  • the "detailed notification" method can be implemented in the MMS and the convenience of the MMS for the user can be significantly increased. Even before an MM is loaded and therefore probably before costs arise for the user, the user is informed in detail about the content and the composition of the MM and can act accordingly, for example by only downloading individual data records 7 of the MM and refusing further ones.
  • An MM basically consists of a header and, depending on the type of MM, also a data part (WAP: Body).
  • the header contains general information about the MM and is made up of defined header fields.
  • the data part of the message contains one or more elements of any type (e.g. texts, images, sounds ...) that follow the header in any order. If a presentation description is contained in the data section, a so-called start parameter should indicate this presentation description in a WAP message at the beginning of the data section.
  • Each header field consists of a field name, followed by a field value that consists of at least one octet.
  • the assignment of hexadecimal values to the field names is shown in Fig. 4.
  • the information is extracted from the MMS Relay 3 with the post-Judges 9 incoming MM, that is partly of Hea ⁇ the fields unchanged and in part from the data part of the MM is calculated (for example, the indication of the size of Da ⁇ tensatzes 7).
  • An advantage of this procedure is the expected consistency between the descriptive header information of the message 11 and the actual content 14 (in WAP: M-Retrieve. Conf), which are transmitted to the recipient 4 (user agent B) on request become.
  • the implementation effort for sender 2, and therefore usually in the mobile device, remains low.
  • Another advantage is the accuracy of the size specification when format conversion takes place.
  • the content is adapted to, for example, the capabilities of the receiving MMS user agent 4 (such as supported codecs, display size of the terminal, etc.) or preferences of the recipient (such as automatic limitation to a maximum size) ) can take place through the service provider 3.
  • the MMS relay 3 can inform the recipient 4 of the size of the content after data adjustment. This is information that the sender 2 does not have.
  • a disadvantage of the MMS relay 3 is the additional effort to generate the information for this "detailed notification", which arises from the necessary "parsing" of the MM and the extraction of the corresponding information.
  • the information can already be generated by the sender 2 and used as header fields 17; 18; 19; 20; 21; 22; 23 can be explicitly integrated into message 9 for sending an MM (in WAP: M-Send.req).
  • WAP M-Send.req
  • the realization of the new Hea ⁇ the fields 17; 18; 19; 20; 21; 22; 23 possibilities opened in the terminal 5 can be determined by the manufacturer. There is also the option of offering end devices with different convenience features.
  • the MM can be sent station 2 his knowledge of the internal and external ⁇ ne linking the MM-elements the MM-receiver in the form of detailed information notified, which are merely forwarded from the MMS Relay. 3
  • a disadvantage is the expansion of header fields with partially redundant information.
  • the information is therefore advantageously generated partly in the sending user agent 2 and partly in the MMS relay 3, which on the part of the MMS relay 3 also requires the updating of existing header fields generated by the sender 2.
  • X-Mms-Content-Type denotes the type and format of the data record 7. These should already be entered when sending, since the data record 7 does not necessarily receive a file name as in an email and then does not have the file extension (extension ) can be assigned to a format. An update of this field by the MMS Relay 3 is only necessary for a format and / or type conversion.
  • the X-Mms content type is displayed and determined by the value or the signal CTV.
  • • X-Mms content name Name of the data record 7. This name is only known to the sending user agent 2 and must therefore be used by him. The CNV content is assigned to it. • X-Mms-External-Link-Flag: Indicates that data record 7 contains a link to content outside the MM. If this information is from the sending User Agent 2 is turned ⁇ , a content analysis of the data set 7 by the MMS Relay 3 is unnecessary. The content or the string ELF is assigned to it.
  • X-Mms-External-Link-Size This specifies the size of a linked content outside the MM. This is indicated by the content of ELS. Since the amount of data of an external content cannot be read from the link itself, this information is of great interest to a user. It can be generated directly when the MM is generated in the sending MMS User Agent 2. Alternatively, generation by the MMS relay 3 is possible, but in addition to the analysis of the entire MM, it also requires access to the object specified in the reference for the purpose of size determination.
  • X-Mms-Content-Related-URI The CRV information in this field shows the location of another element to which data record 7 refers.
  • a data record 7 contains a presentation description that relates to other elements with audio, video or other contents of the MM.
  • the generation of this information on the one hand requires knowledge of the internal relationships of the elements of an MM, on the part of the sending MMS user
  • Agents 2 is present, and on the other hand knowledge regarding the positions of the MM elements at the MMS relay / server 3 or at the receiver 4.
  • the information can be coded in header fields on the part of the sending MMS user agent 2 and is complete by correct / update the MMS relay 3 on the basis of the then current positions and then evaluate it in the receiving MMS user agent 4.
  • X-Mms-Content-Size Size of data record 7, specified in octets. The information relating to the content size is only updated if the MMS Relay 3 changes the type and / or format of the data record.
  • the selection switch 25 implemented, for example, in the software on the software side and to be operated via an input means, for example a keyboard, is used. Access to individual data records 7 is also possible. A partial download can be initiated in WAP with the command 13: WSP GET.req by a download request with the content ID of a desired data record 7 (for example, a photo without simultaneous transmission of the accompanying text).
  • the order of the header fields is basically irrelevant in the WAP standard. A change in the order of the information, name, size, type and / or URI of several data records 7 would thus cause a change or falsification of the descriptions of the data records 7 if the assignment made the information dependent on the order of the header elements, which is the only feasible way, since a hierarchical structure of the header elements is not provided in WAP.
  • the statement of irrelevance of the header element order contradicts the statement that HTTP headers that contain lists are to be converted into several WSP headers, each with only a single element, the order of the entries being retained , In order to resolve this contradiction, a system is designed that presupposes the significance of the order of the header elements.
  • a defined header field must begin the description of a data record 7 to which all subsequent header fields are assigned until either the end of the message header is reached or a next header field of the defined type begins the description of a further data record 7 is marked.
  • the field 17: X-Mms-Content-ID serves as the defined header field for the description of a data record 7, since it contains the unique address of the element.
  • the description of a data record 7 is generally initiated by this field, whereupon the further fields can appear optionally and in any order.
  • the sender (level 2) can use his or her telecommunication device 5 to operate an input option on the hardware or in particular software and via the keyboard, which is already present, in order to use this to provide the additional information in the header fields 17, 18, 19, 20, 21, 22, 23 or to deposit part of this information (see above). These are sent to the provider (level 3) as part of an identification signal for one or more data records 7 of the MM with the shipment 9 (in WAP: M-Send.req) (FIG. 1). The confirmation of the dispatch by the MMS relay 3 (in WAP with the message 10: M-Send.conf) remains unchanged, since the only essential information is the message ID optionally assigned by the MMS relay 3.
  • the recipient 4 then receives the message 11 (in WAP M-Notification. Ind) that an MM with one or more data records 7 is available for download.
  • This notification 11 in turn contains all additional header fields 17, 18, 19, 20, 21, 22, 23 for describing the data records 7 from the header of the message 9 for sending them (in WAP: M-Send.req).
  • This information can be communicated to the receiver optically (via the display means 24, for example the display) or acoustically.
  • the confirmation 12 (WAP: M-NotifyResp. Ind) of the receipt of the notification 11 remains unchanged.
  • the recipient 4 of the MM After the recipient 4 of the MM has been informed in detail about its content, he can read the entire MM (in WAP: through the Command 13: WSP Get.req) download. Alternatively, access to a single element of the MM is also possible according to this invention. For this purpose, for example, the content ID of a data record 7 of the MM is used as the URI in the command for downloading . Without the consent of the recipient 4, a download of the MM (transmission of the item 14 to the recipient) will not be released. It is also possible that the receiver 4 only wants to receive the MM at a later, cheaper time.
  • the actual data transmission 14 can contain the descriptive header fields 17, 18, 19, 20, 21, 22, 23. However, this is not mandatory, as shown in FIG. 7.
  • the MMS relay 3 sends a message 16 about the status of the delivery of the MM (in WAP: M-Deliver. Ind) to the latter.
  • M-Deliver. Ind M-Deliver. Ind
  • “Expired” expired
  • ⁇ Retrieved (delivered)
  • Rejected Rejected
  • Deffered (delayed)
  • Partially-retrieved can also be used Status field occur.
  • the display shows which data record 7 was delivered.
  • the corresponding section of message 16 could be as follows:
  • Header shows the field 22: X-Mms-External-Link-Flag a link to external content within the entire MM or within a specific data record 7 of the MM.
  • the method presented can be integrated into software for operating the respective communication standard, such as UMTS.
  • the telecommunication devices 5, 6 are then provided with appropriate software.
  • Sender 2 (Markus Trauberg) sends an MM with a text with several data records 7, namely an MP3 audio, a JPEG image, an MPEG-4 video and a SMIL presentation description two receivers 4 (Andreas Schmidt and Josef Laumen).
  • a SMIL presentation description two receivers 4 (Andreas Schmidt and Josef Laumen).
  • the receiver 4 For convenient and differentiated use by the receiver 4, he adds descriptions of parameters of the data records 7 of the MM to their header.
  • the data are in the
  • the message protocol can be as shown in FIG. 9.
  • the additional information blocks about the MM elements are coded in the MM in the header. This also describes the relationships between data records 7 of the MM:
  • the description of the presentation_description contains references to the external elements image / jpeg, audio / mp3 and video / mpeg4 in the form of the corresponding content IDs.
  • the description of the text contains the information that it contains a reference to an external object that contains 8245 bytes of data.
  • the MMS relay 3 confirms with message 10 that the request 9 has been transmitted to the MMS relay 3 without errors.
  • the transaction ID # 1 is used to clearly assign the message 10 at the sender 2 to the associated request 9 (M-Send.req) and thus to the sent MM. Because a delivery report was requested in message 9 in the X-Mms-Delivery-Report field, the MMS Relay 3 assigns a message ID to the MM and transmits this here to the sender 2.
  • message 11 is transmitted to recipient 4:
  • M-Notification. ind MMS Relay -> MMS User Agent B: The MMS provides to inform a recipient of an MM about new messages that are available to him.
  • the post ⁇ reporting 11 (M-Notification. Ind) is used to notify the addressee about lying ready for download MM. Consequently e- xistieren in this example, two notifications to the recipient Andreas Schmidt and Josef Laumen.
  • the information about the storage space of the MM is in the field X-Mms-Content-Location.
  • Figure 11 gives an example of the content of the M-Notification-ind.
  • the correct receipt of the notification is then confirmed by the recipient 4 of the MM with the message 12 (M-Notif Resp. Ind) by sending the corresponding transaction ID of the message 11 back to the MMS relay 3 together with a status message.
  • the MM download is initiated by command 13 (WSP GET.req).
  • the MM is then sent from MMS relay 3 in message 14 (M-Retrieve.conf) to recipient 4. Since the information transmitted over the individual elements already with the message 11, the download of the entire ge ⁇ MM as before can be done with the news 14 must be inserted without additional fields in the header of this message 14th
  • the additional information in the headers of the individual data records 7, on the other hand, should also be contained in the message 14, since they contain important information about the MM data records 7.
  • message 14 is encoded as shown in FIG. 12:
  • the receiver 4 Andreas Schmidt then acknowledges the successful receipt of the MM message 15 (M-Acknowledge. Ind). With the transaction ID contained therein, the assignment to the sent MM on the MMS relay 3 is in accordance with the information signal M-acknowledge. possible from Figure 13.
  • message 16 (M-Delivery. Ind) corresponding to FIG. 14 'is transmitted from MMS relay 3 to sender 2:
  • the second recipient decides to load only the text part of message 14. To do this, he enters the content ID of the text part in message 13 (WSP GET.req): "000714.1412. Lmarkus .trauberg”. He receives this part of the text with message 14 (M-Retrieve. Conf), which above the version to Andreas Schmidt has been significantly changed and the content of which is shown as an example in Figure 15.
  • the message 14 has been reduced by the undesired data records 7 compared to its complete version as it was sent to Andreas Schmidt. In addition, the field nEntries has been adjusted accordingly.
  • the sender 2 is again informed about the status of the delivery. It contains the status of the partial delivery ("partially retrieved") and is shown in FIG. 17 in terms of content.
  • the core of this modification is the realization of the idea of informing the respective recipient in detail about the content of the respective MM, using only a single, newly defined header field for which new parameters are introduced.
  • the new header field contains all parameters, ie information about an element of the MM to be described.
  • JPEG Joint photographics expert group
  • Variants proposed information that the recipient of an MM optionally in a recipient notification in the MMS
  • M-Nind in WAP: M-Notlf ication. Ind
  • WAP M-Notlf ication. Ind
  • the number of the contained elements of the MM (also implicitly by the description of the individual elements of the MM),
  • connection of one element to one or more other elements of the MM
  • M-Nind in WAP: M-Notif ication. Ind
  • M-Sreq MMS sending request
  • M-Rconf MMS delivery message
  • An MM basically consists - as shown in the previous exemplary embodiments - of a header and, depending on the type of the message, possibly also of a data part (WAP: body).
  • the header contains general information about the message and is made up of one or more defined header fields.
  • the possible data part of the Messa- ge contains one or more elements of any type that follow the header in any order. If a presentation description is contained in the data section, a so-called start parameter should, for example, expediently refer to this presentation description in a WAP message at the beginning of the data section.
  • Header fields in WAP are shown for the message types considered here in the tables corresponding to FIGS. 21A / 21B and 22. These were WAP-209-MMS Encapsulation, Release 2000; Wireless application protocol; WAP multimedia messaging service; Message encapsulation; MMS Proposed SCD
  • each header field consists of a field name, followed by a field value consisting of at least one octet.
  • the assignment of hexadecimal values to the field names of the WAP messages is shown in the table corresponding to FIG. 20.
  • This further option is based on the definition of a header field for the unique identification of an element of an MM, the header field X-Mms-Content-ID, which was introduced in the body of the MM and the element of the MM as a header field and clearly identifies the element.
  • the description of an element of the MM is based on a single header field X-Mms-Content-ID, which is integrated in the header of the MM to notify the recipient, and which contains the necessary information (for the notification the recipient describes, for example, the number, type, size, format of the MM data records available for him) using one or more parameters from the following list.
  • Name describes the name of the MM element
  • Type describes the type and format of the MM element
  • Size describes the size of the MM element in bytes
  • External Link Size specifies the additional data volume that must be downloaded to resolve the external reference
  • the identification signal for one or more assigned data records is now transmitted in a single, additional header field from the respective transmitter, such as a first mobile radio device and / or responsible server, coded in an MMS receiver notification to the receiver, such as to a second mobile radio device.
  • the respective transmitter such as a first mobile radio device and / or responsible server
  • coded in an MMS receiver notification to the receiver, such as to a second mobile radio device.
  • Original type describes the type of the MM element before transcoding by the MMS connection unit (M-SR);
  • Original size describes the size of the MM element before transcoding by the MMS connection unit (M-SR) in bytes;
  • FIG. 18 shows the only header field newly introduced for the purpose of detailed notification of the recipient of an MM in accordance with WAP, including the coding of field name and field value.
  • the table corresponding to FIG. 20 contains the assignment of hexadecimal values to the field names.
  • the table corresponding to FIG. 19 contains the assignment of hexadecimal values to the parameter names and also the types to be used for coding the parameter values.
  • the WAP messages supplemented by the corresponding header fields are listed in tables 21A / 21B and 22. All changes and additions in the tables on the current state of the art are framed.
  • M-UA_A Markus Trauberg
  • M-UA_B Multimedia Message MM A consisting of a text, an MP3 audio, a JPEG picture, an MPEG-4 video and an SMIL (synchronized multimedia integration language) - presentation description to a recipient M-UA_B (Andreas Schmidt).
  • M-UA_B synchronized multimedia integration language
  • MM A is sent to an addressee. Their content is shown as an example in FIG. 23.
  • the additional information blocks are in the header, i.e.
  • the one or more parameters are encoded via the MM elements.
  • This also describes the relationships between the elements of the MM:
  • the description of the presentation description (* .smil) contains references to the elements i age / jpeg, audio / mp3 and video / mpeg4 referenced therein in the form of the corresponding content IDs.
  • the description of the text contains the information that it contains a reference to an external object that contains 8245 bytes of data.
  • the send request (WAP: M-Send. Req) from the MMS User Agent A is acknowledged by the M-SR with a message (in WAP: M-Send. Conf).
  • WAP M-Send. Conf
  • M-Nind (M-SR ⁇ M-U ⁇ -B): In MMS (multi edia Services) according to 3G TS 23.140 Versi ⁇ on 3.0.1, Release 1999; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia messaging service (MMS); Functional description; Stage 2 and WAP-209 MMS Encapsulation, Release 2000; Wireless application protocol ; WAP multimedia messaging service; Message encapsulation; MMS Proposed SCD 1.0 is intended to inform a recipient of an MM about new messages that are available to him.
  • the message M-Nind (in WAP: M-Notif ication. Ind) serves to notify the addressees of MMs available for download. Their content is shown by way of example in FIG. 24. Consequently, in this example there is a recipient notification to the recipient Andreas Schmidt.
  • the information about the storage space of the MM A is in the field X-Mms-Content-Location.
  • the M-SR also generates the Type and Size information from the information in the body of the M-Sreq message, or the image / type image / jpeg image is converted to the image / bmp type, since the terminal does not have JPEG images can display.
  • the corresponding information about the original type and the original file size have been added to the corresponding header field.
  • the recipient After receiving the detailed notification, the recipient knows both the address of the MM (as before) and the composition of the individual elements and their content IDs. It is therefore also possible to access individual elements of the MM separately.
  • the correct receipt of the notification can then be confirmed by the recipient of the MM A with the message MN ind, in that the corresponding transaction ID of the M-Nind together with a status message is sent back to the MMS Relay. Then the download of the MM A is initiated by the command W-Greq. The MM is then sent from the M-SR to the MM-UA A in the M-Rconf message.
  • the message M-Rconf is encoded, for example, as in FIG. 25.
  • a method for transmitting additional information for a detailed description of a multimedia message and the MM elements contained therein is thus provided in the multimedia messaging service (MMS).
  • This information is in particular provided with a single or several additional header fields in the respective MMS recipient notification from the respective responsible server, e.g. Transfer M-SR to the receiving user agent.
  • the necessary information is preferably generated by the sending user agent and transmitted in coded form in the MMS send request to the responsible server.
  • the necessary information can also be extracted by the responsible switching / provisioning server from the data part of the MM to be sent in each case and transmitted to the receiving user agent in coded form in the MMS recipient notification.
  • the receiving user agent can receive one or more of the following information about the content or individual elements of the content of the information e.g. the following message is available in the server responsible:
  • the identification of the element forms the first entry in the single header field or the content of the first header field if several header fields are used per element or data record.
  • an element of an MM can preferably be carried out with a single field which refers to the element in the data part of the multimedia message by means of a unique identification number or identifier and which also contains the further information as parameters and not in separate header fields.
  • the recipient of an MM can preferably also load individual elements of the MM onto his end device. It is also possible that the additional information according to this invention
  • the MMS recipient notification (M-Nind) can also be added to the header of the MMS delivery message (M-Rconf).
  • the additional header field can preferably be coded as follows if only one header field is used per data record:
  • the information as parameters in this single header field can be encoded in particular according to the table in FIG. 19.
  • WAP-203-WSP version 4-May-2000; Wireless application protocol, wireless session protocol specification; Chapter 8.4: “Header Encoding”.
  • WAP forum "WAP MMS Interworking with Internet E-mail; WAP-207-MmsInetInterworking"; Draft version
  • RFC2045 "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bo-dies", Freed N., November 1996.
  • RFC2047 "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", Moore K., November 1996.

Abstract

Bei einer Datenübertragung in einem Mobilfunknetz, insbesondere einer Übertragung von Text- und/oder Bilddaten mit und ohne Ton innerhalb Multimedia messages (MM), wird den Daten zumindest ein Identifikationssignal für einen Datensatz oder mehrere Datensätze zugeordnet und dieses oder diese Identifikationssignal(e) an den Empfänger der Daten übertragen.

Description

Beschreibung
VERFAHREN UND MOBILTELEKOMMUNIKATIONSGERÄT ZUR DATENÜBERTRAGUNG IN EINEM MOBILFUNKNETZ
Die Erfindung betrifft ein Verfahren zur Datenübertragung in einem Mobilfunknetz nach dem Oberbegriff des Anspruchs 1 sowie ein mobiles Telekommunikationsgerät nach dem Oberbegriff des Anspruchs 26, ein Computerprogrammerzeugnis nach Anspruch 30, sowie ein Funkkommunikationssystem nach Anspruch 32. ■
Bisherige Mobilfunknetze, wie etwa das nach dem GSM-Standard arbeitende Netz, eröffnen noch recht eingeschränkte Möglichkeiten zur Übertragung von Textdaten. So können etwa bis zu 160 Zeichen umfassende Kurznachrichten übertragen werden. Diese Einrichtung wird als SMS (Short Message Service) bezeichnet. Für die Kosten des Versands derartiger Textnachrichten hat der Datenversender aufzukommen.
Zukünftig soll auch eine Übertragung von Multimediadaten, insbesondere stehenden oder bewegten Bildern mit oder ohne Ton, möglich sein. Es ist mit einer erheblichen Ausweitung der Datenübertragungsmengen und der Datentypen innerhalb solcher Übertragungen zu rechnen, was mit erhöhter Übertragungszeit und einer Kostensteigerung einhergeht.
Der Erfindung liegt das Problem zugrunde, die Kontrolle der Datenübertragung für Teilnehmer eines Mobilfunknetzes zu vereinfachen.
Die Erfindung löst dieses Problem durch ein Verfahren mit den Merkmalen des Anspruchs 1, sowie durch ein Mobiltelekommuni- kationsgerät mit den Merkmalen des Anspruchs 26, ein Compu- terprogrammerzeugnis mit den Merkmalen des Anspruchs 30, sowie durch ein Funkkommunikationssystem nach Anspruch 32. Hin- sichtlich vorteilhafter Ausgestaltungen wird auf die Ansprü¬ che 2 bis 25, 27 bis 29 und 31 verwiesen.
Mit dem erfihdungsgemäßen Verfahren ist eine Information an den Datenempfänger über Charakteristika der zum Empfang be- reitstehenden Daten möglich, was diesem die Kontrolle hierüber erleichtert.
Bei Vorabzusendung des oder der Charakteristika der zu übersendenden Daten angebenden Identifikationssignal (e) ist die Kontrolle bereits vor Empfang der eigentlichen Daten ermöglicht, wobei besonders vorteilhaft dem Empfänger anhand der so erhaltenen Information eine Auswahlmöglichkeit eröffnet ist, ob er die bereitstehenden Daten jetzt oder später oder gar nicht empfangen möchte. Wenn auch die Wahlmöglichkeit ei- nes teilweisen Empfangs einer Multimedia message (MM) vorgesehen ist, kann der Empfänger beispielsweise nur für ihn wichtige Kurzinformationen, die eine kurze Übertragungszeit benötigen, herunterladen und eventuell zugehörige speicherintensive Bildbestandteile oder ähnliches später oder gar nicht herunterladen.
Wenn das dafür eingesetzte Identifizierungssignal Information über die Größe eines zu empfangenden Datensatzes enthält, kann der Empfänger daran ermitteln, wieviel Zeit er für die Übertragung und/oder das Studium der Daten rechnen muß und ob er diese Zeit jetzt oder zu einem späteren Zeitpunkt oder gar nicht aufbringen will.
Wenn das Identifizierungssignal Information über den Namen eines Datensatzes enthält, kann der Empfänger daran ermitteln, aus welchem Themenkomplex die Daten stammen. Auch daran kann er vorteilhaft auswählen, ob er diesen oder diese Datensatz oder Datensätze jetzt oder zu einem späteren Zeitpunkt oder gar nicht empfangen will. Besonders vorteilhaft kann im Identifikationssignal auch In¬ formation über den Datentyp gegeben sein, so daß der Empfänger weiß, ob es sich beispielsweise um Bilddaten, Textdaten und/oder Musikdaten handelt.
Kontrolle und Transparenz sind damit entscheidend verbessert.
Weitere Vorteile und Merkmale der Erfindung ergeben sich aus in den Zeichnungen neu dargestellten und nachfolgend be- schriebenen Ausführungsbeispielen des Gegenstandes der Erfindung.
Es zeigen:
Fig. 1 eine schematische Abbildung von einer Datenübertragung zugeordneten Sendungen gemäß dem WAP-Standard (Wireless application protocoll) zwischen der Ebene des Versenders und der des Providers einerseits und der Ebene des Providers und der des Empfängers an- dererseits,
Fig. 2 die Header-Felder einer nach dem in Fig. 1 gezeigten WAP-Standard gesendeten Nachricht M-Send.req, wobei die erfindungsgemäß neu eingefügten Header- Felder grau unterlegt sind,
Fig. 3 eine Spezifizierung des Typs der in Fig. 2 gezeigten und in den grau unterlegten Feldern abgelegten Informationen sowie des zusätzlich im Statusbericht auftretenden Feldes über den Erhalt der versandten
Daten, Fig. 4 eine Darstellung der Zuweisung der Header-Felder aus Fig. 2 zu den binären Codes, wobei die erfindungsgemäß neu eingefügten Header-Felder grau un- terlegt sind, Fig. 5 eine ähnliche Darstellung wie Fig. 2 der nach dem in Fig. 1 gezeigten WAP-Standard gesendeten Nach¬ richt M-Notification.ind (MNI),
Fig. 6 eine ähnliche Darstellung wie Fig. 2 der nach dem in Fig. 1 gezeigten WAP-Standard gesendeten Nachricht M-Retrieve.conf (MRC) ,
Fig. 7 eine ähnliche Darstellung wie Fig. 2 der nach dem in Fig. 1 gezeigten WAP-Standard gesendeten Nachricht M-Acknowledge.ind (MAI),
Fig. 8 eine ähnliche Darstellung wie Fig. 2 der nach dem in Fig. 1 gezeigten WAP-Standard gesendeten Nachricht M-Delivery . ind. (MDI) ,
Figuren
9-17 und 23-25 jeweils exemplarisch den. Inhalt verschiedener Informationssignale für die Übertragung von Multimedianachrichten zwischen mehreren Komponenten eines FunkkommunikationsSystems nach dem erfindungsgemäßen Verfahren,
Figur 18 das Encoding eines einzigen Header-Feld-Namens,
Figur 19 Encoding (Kodierung) der neuen Parameternamen und
Parameterwerte im einzigen Headerfeld nach Figur 9,
Figur 20 Zuweisung binärer Codes zu den Feldnamen der Parameter im einzigen Headerfeld nach Figur 9,
Figur 21A, 21B das einzige Header-Felder einer Multimedia Service (MMS) Sendeanfrage (in WAP Message M- Send. req; ) , und
Figur 22 das zur Sendeanfrage MSreq nach Figur 12A, 12B zuge¬ hörige Header-Felder der MMS Empfängerbenachrichti- gung (M-Nind; in WAP Message M-Notlfi cation . ind ;)
Elemente mit gleicher Funktion und Wirkungsweise sind in den Figuren 1 mit 13 jeweils mit denselben Bezugszeichen versehen.
Im Ausführungsbeispiel ist die Anwendung der Erfindung auf ein Datenübertragungsschema 1 für den WAP-Standard, wie es in der Übertragung von insbesondere Bilddaten und formatierten Textdaten im UMTS-Standard (Universal mobile telecommunicati- on Standard) Verwendung finden wird, beschrieben. Es versteht sich, daß die Erfindung auch auf andere Standards übertragbar • ist.
Im UMTS-Standard ist vorgesehen, zusätzlich zum bisherigen SMS einen sogenannten MMS (Multimedia Messaging Service) für die Übertragung von Nachrichten, auch als Multimedia messages (MMs) bezeichnet, vorzusehen. Damit können auch formatierte Texte und Bilder mit und ohne Ton übertragen werden. Die im SMS vorhandene Beschränkung auf eine Nachrichtenlänge von 160 Zeichen entfällt. Eine Übertragung von Audio- und Videonachrichten ist möglich.
MMS ist über die Nutzung von WAP realisierbar. Dabei wird für die Funkübertragung von Daten, etwa von Multimedia Messages (MMs), das in Fig. 1 dargestellte Protokollschema (WAP WSP: Wireless Session Protocoll) angewandt. Dieses umfaßt eine E- bene 2 eines Datenversenders (auch als MMS User Agent A bezeichnet) , eine Ebene 3 eines Providers (, dessen Netzelement, das den Service ausführt, auch als MMS Relay bezeichnet wird) und eine Ebene 4 eines Empfängers (auch als MMS User Agent B bezeichnet) . Die Ebene 2 des Datenversenders umfaßt zumindest ein Telekommunikationsgerät 5, ebenso umfaßt die Ebene 4 des Empfängers ein Telekommunikationsgerät 6. Diese Telekommunikationsgeräte 5, 6 können beispielsweise als übli- ehe Handies oder als Geräte mit weiteren Eingabe- oder Anzeigefunktionen, wie etwa Laptops, ausgebildet sein.
Eine im Teleko munikationsgerät 5 des Versenders verfaßte o- der über dieses weiterzuleitende Multimedia message abgekürzt (MM) kann einen oder mehrere Einheiten (Datensätze 7) , beispielsweise einzelne Bilder, Filmsequenzen, Texte oder ähnliches, enthalten. Die MM wird zunächst als Anfrage-Sendung 9 (diese trägt im WAP-Protokoll den Namen M-Send.req) an den Provider (Ebene 3) versandt.
Von dort wird die eingegangene Sendung 9 mit der Rücksendung 10 (M-send. conf) an den Versender (Ebene 2) quittiert.
Zeitlich darauffolgend wird vom Provider (Ebene 3) die Infor- mation 11 (M-Notification. ind) an den Empfänger (Ebene 4) gesandt, mit der dieser darüber informiert wird, daß für ihn eine Nachricht beim Provider 3 zum Herunterladen bereitliegt.
Hierüber erhält der Provider 3 beispielsweise automatisch die quittierende Rückmeldung 12 (M-NotifyResp. req) vom Telekommunikationsgerät 6 des Empfängers (Ebene 4) .
Erst auf Anforderung durch den Empfänger mit der Sendung 13 (WSP GET.req) wird vom Provider die MM mit der Sendung 14 (M- retrieve.com) an den Empfänger weitergeleitet.
Die Nachricht 15 (M-Acknowledge . ind) quittiert den Empfang der MM.
Die abschließende Nachricht 16 (M-Delivery. ind) gibt eine Empfangsbestätigung an den Versender 2 zurück. Zur Verwaltung der Sendungen 9, 10, 11, 12, 14, 15, 16 dienen die sog. Header-Felder, also der eigentlichen MM vorange¬ stellte Felder, in denen Informationen über die Herkunft, Sendezeit, Dateigröße und weitere Details enthalten sein kön- nen.
Erfindungsgemäß ist die Anzahl der Header-fields erhöht, um zumindest ein weiteres Feld 17, 18, 19, 20, 21, 22, 23 als Informationsfeld (er) über charakterisierende Parameter der MM informieren zu können und darin ein oder mehrere Identifizierungssignal (e) für diese (n) Parameter dem Empfänger 4 zusenden zu können.
Im Ausführungsbeispiel sind dafür (sh. Fig. 4) die mit 0x80 bis 0x86 im Hexadezimalsystem adressierten Felder 17, 18, 19, 20, 21, 22, 23 vorgesehen, um die Information über die Parameter, die weiter unten noch näher beschrieben werden, aufzunehmen. Auch eine andere Anzahl und/oder Adressierung der zusätzlichen Header-Fields ist möglich.
Die zusätzlichen genannten Header-Fields 17, 18, 19, 20, 21, 22, 23 sind zumindest in der Nachricht 11 (M- Notification.ind) , mit der der Empfänger 4 über das Bereitstehen einer MM informiert wird, beigefügt. Auch die Nach- rieht 9 (M-Send.req) kann, wenn die zusätzlichen Parameter vom Versender 2 generiert werden, die zusätzlichen Header- Fields 17, 18, 19, 20, 21, 22, 23 enthalten (Fig. 2), ebenso die eigentliche MM-Zustellung 14 (M-Retrieve . conf) (sh. Fig. 5) oder weitere der Nachrichten 10, 12, 13, 15, 16.
Unter einem Datensatz 7 einer MM wird im folgenden ein einzelner Bestandteil einer MM verstanden, der durch seinen Typ (z.B. Standbild) und sein Format (z.B. JPEG) definiert ist, wobei im MMS auch eine Formatkonvertierung durch das MMS Re- lay 3 vorgesehen ist, durch die gewährleistet wird, daß auch Telekommunikationsgeräte 6 eines Empfängers 4, die nur be¬ stimmte Formate eines Typs unterstützen, auch nur mit diesen Formaten bedient werden. Beispielsweise kann ein Telekommuni¬ kationsgerät 6 nur Standbilder im JPEG-Format anzeigen, was es im Rahmen seiner Anmeldung dem MMS Relay 3 mitgeteilt hat. Das MMS Relay 3 konvertiert dann alle für diesen Empfänger eingehenden Standbilder in das JPEG-Format, wodurch sich im allgemeinen die Dateigröße ändert. Dieser Aspekt ist für eine spätere Betrachtung der nach dieser Erfindung neuen Header- Felder relevant.
Als Identifikationssignal können beispielsweise die folgenden Informationen über einen Datensatz 7 enthalten sein. Auch eine andere Anzahl von Informationen, etwa nur eine Auswahl aus den aufgeführten, kann vorgesehen sein. Die Informationen werden dem Empfänger einer MM optional bei Verwendung des WAP-Standards (Fig. 1) in der Benachrichtigung 11 (M- Notification. ind) , und damit vor Übertragung der eigentlichen Daten in der Multimedia message, zur Verfügung gestellt.
Mögliche Parameter von zu übertragenden Daten, insbesondere einer MM, über die der Empfänger vorab informiert wird, sind:
1. die Anzahl der enthaltenen Datensätze 7 der MM (auch implizit durch die Beschreibung der einzelnen Elemente der MM) ,
2. die jeweilige Größe (in Octets) eines Datensatzes 7,
3. der jeweilige Typ und das Format eines Datensatzes 7,
4. die jeweilige Content ID (Content IDentification) eines Datensatzes eventuell auch relativ zu der Content
ID/Message ID der gesamten MM,
5. der jeweilige Name eines Datensatzes,
6. das Subjet der gesamten MM,
7. die Verbindung eines Elements zu einem oder mehreren anderen Datensätzen 7 der MM, 8. die Verbindung der gesamten MM oder eines/mehrerer Datensätze 7 zu einer oder mehreren URLs/URIs außerhalb der MM und bei einem solchen externen Link optional die Größe der zu ladenden Daten des/der aufgelösten externen Links .
Mit Hilfe der neuen Header-Felder 17, 18, 19, 20, 21, 22, 23 kann die Methode der "detailed Notification" im MMS umgesetzt und der Komfort des MMS für den Benutzer deutlich erhöht wer- den. Schon vor dem Laden einer MM und damit voraussichtlich schon bevor Kosten für den Benutzer entstehen, wird dieser über die Inhalte und die Zusammensetzung der MM detailliert informiert und kann entsprechend handeln, etwa dadurch, daß er nur einzelne Datensätze 7 der MM herunterlädt und weitere ablehnt.
Eine MM besteht grundsätzlich aus einem Header und abhängig vom Typ der MM zusätzlich aus einem Datenteil (WAP: Body) . Der Header umfaßt allgemeine Informationen der MM und setzt sich aus definierten Header-Feldern zusammen. Der Datenteil der Message enthält ein oder mehrere Elemente beliebigen Typs (z. B. Texte, Bilder, Töne...), die in beliebiger Reihenfolge dem Header folgen. Falls eine Präsentationsbeschreibung im Datenteil enthalten ist, soll in einer WAP-Message zu Beginn des Datenteils ein sogenannter Start-Parameter auf diese Präsentationsbeschreibung hinweisen.
Jedes Header-Feld besteht aus einem Feld-Namen, gefolgt von einem Feld-Wert, der aus mindestens einem Octet besteht. Die Zuweisung von hexadezimalen Werten zu den Feld-Namen ist in Fig. 4 aufgeführt.
Um die Benachrichtigung 11 an den Empfänger 4 mit den gewünschten Informationen anzureichern, bestehen grundsätzlich zwei Möglichkeiten: Entweder werden die Informationen vom Provider 3 oder vom Versender 2 erstellt. Auch eine Mischform ist möglich. Im einzelnen sind hierfür die folgenden Abläufe möglich:
Die Informationen werden aus der am MMS Relay 3 mit der Nach- rieht 9 eintreffenden MM extrahiert, d.h. teilweise aus Hea¬ der-Feldern unverändert übernommen und teilweise aus dem Datenteil der MM berechnet (z.B. die Angabe der Größe eines Da¬ tensatzes 7) . Vorteilhaft bei diesem Vorgehen ist die zu erwartende Konsis- tenz zwischen den beschreibenden Header-Informationen der Nachricht 11 und den tatsächlichen Inhalten 14 (in WAP: M- Retrieve. conf) , die auf Anforderung des Empfängers 4 (User Agent B) an diesen übertragen werden. Der Realisierungsaufwand beim Versender 2, und damit i.d.R. im mobilen Endgerät, bleibt gering. Ein weiterer Vorteil besteht hinsichtlich der Genauigkeit der Größenangabe, wenn Formatkonvertierung stattfindet. Bei MMS ist vorgesehen, daß vor Auslieferung der Daten eine Anpassung des Inhalts an z.B. Fähigkeiten des empfangenden MMS User Agents 4 (wie unterstützte Codecs, Dis- play-Größe des Endgeräts etc.) oder Vorlieben des Empfängers (wie automatische Beschränkung auf eine maximale Größe) durch den Service Provider 3 stattfinden kann. Das MMS Relay 3 kann dem Empfänger 4 die Größe des Inhalts nach Datenanpassung mitteilen. Dies ist eine Information, die der Versender 2 nicht besitzt. Nachteilig ist der beim MMS-Relay 3 zusätzliche Aufwand zur Generierung der Informationen für diese "detailed Notification" , der durch das notwendige "Parsen" der MM und die Extraktion der entsprechenden Informationen entsteht.
Die Informationen können statt dessen bereits vom Versender 2 generiert und als Header-Felder 17; 18; 19;20; 21; 22;23 in die Nachricht 9 zum Versenden einer MM (in WAP: M-Send.req) explizit integriert werden. Vorteilhaft ist die unveränderte Verarbeitung der MM im MMS Relay 3, das nicht den Inhalt der MM analysieren muß. Die Realisierung der mit den neuen Hea¬ der-Feldern 17;18;19;20;21;22;23 eröffneten Möglichkeiten im Terminal 5 kann vom Hersteller bestimmt werden. Es besteht darüber hinaus die Möglichkeit, Endgeräte mit unterschiedli- chen Komfortmerkmalen anzubieten. Weiterhin kann der MM- sendende Teilnehmer 2 sein Wissen über die interne und exter¬ ne Verknüpfung der MM-Elemente dem MM-Empfänger in Form von detaillierten Informationen mitteilen, welche vom MMS-Relay 3 lediglich weitergeleitet werden. Eine Generierung der Header- Felder im MMS Relay 3, die Wissen über die interne und externe Verknüpfung der Datensätze 7 erfordert, wäre dort nur durch aufwendiges Parsen der MM möglich. Nachteilig ist die Erweiterung von Header-Feldern mit teilweise redundanten Informationen.
Vorteilhaft werden die Informationen daher teilweise im sendenden User Agent 2 und teilweise im MMS Relay 3 generiert, was auf Seiten des MMS Relay 3 auch die Aktualisierung bereits vorhandener, vom Versender 2 generierter Header-Felder erfordert.
Für diese Mischform der Generierung zusätzlicher Informationen kann folgende Aufteilung der im folgenden erklärten Informationen vorgesehen sein:
Generierung im sendenden User Agent 2:
• X-Mms-Content-ID: In der bisherigen WAP-Spezifikation fehlen die Möglichkeiten, den Datensätzen 7 eigene zu- sätzliche Header-Felder zuzuordnen (z.B. mit jeweiligem Namen und Typ) und mehrere Datensätze 7 hierarchisch anzuordnen. Für eine transparente Konvertierung einer MM in eine Internet-Mail (Format gemäß RFC 822 mit Erweiterungen gemäß MIME (Multipurpose Internet Mail Extensions) ) werden daher die hier folgenden Voraussetzungen vorge- schlagen: Die zu jeder Extension einer E-Mail möglicher¬ weise zusätzlich im Datenteil der E-Mail codierten Informationen (Name, Typ, ... ) sind transparent auch in einer MM enthalten. Eine Content-ID im Header der MM, die jedem Datensatz 7 eindeutig zugeordnet ist, kann als Verweis genutzt werden. Der Start-Parameter im Message-Body (= Datenstrukturabschnitt, der eigentliche Mitteilungsinformation (en) enthält) muß als Feld definiert sein, das die Content-ID (= Inhaltsidentifikator) CI des Präsentations- beschreibungsobjektes enthält und damit den Zugriff auf dieses Objekt ermöglicht. Mit diesen Vereinbarungen ist eine transparente Übertragung einer MM von einem MMS- Relay zu einem beliebigen Empfänger sowohl direkt über ein anderes MMS-Relay als auch über das Internet per E- Mail möglich. Eine eindeutige Zuordnung zu dem Datensatz oder den Datensätzen 7 in der MM ist unbedingt für die erste Übertragung vom sendenden User Agent 2 zum MMS Relay 3 erforderlich.
• X-Mms-Content-Type: bezeichnet den Typ und das Format des Datensatzes 7. Diese sollten bereits beim Versenden eingetragen werden, da der Datensatz 7 nicht unbedingt einen Dateinamen wie in einer E-Mail erhält und dann nicht über die Dateierweiterung (Extension) einem Format zugeordnet werden kann. Eine Aktualisierung dieses Feldes durch das MMS Relay 3 ist nur bei einer Format- und/oder Typkonvertierung erforderlich. Der X-Mms-Content-Type wird durch den Wert oder das Signal CTV angezeigt und bestimmt.
• X-Mms-content-Size: Größe des Datensatzes 7. Dieser wird durch Wert bzw. Inhalt CSV angezeigt und bestimmt.
• X-Mms-Content-Name: Name des Datensatzes 7. Dieser Name ist nur dem sendenden User Agent 2 bekannt und muß daher von ihm eingesetzt werden. Ihm ist der Inhalt CNV zugeordnet . • X-Mms-External-Link-Flag: Zeigt an, daß der Datensatz 7 eine Verknüpfung auf Inhalte außerhalb der MM enthält. Wenn diese Information vom sendenden User Agent 2 einge¬ setzt wird, ist eine Inhaltsanalyse des Datensatzes 7 durch das MMS Relay 3 entbehrlich. Ihm ist inhaltlich der Wert oder die Zeichenfolge ELF zugeordnet.
• X-Mms-External-Link-Size: Damit wird die Größe eines verknüpften Inhalts außerhalb der MM angegeben. Dies wird durch den Inhalt ELS angezeigt. Da der Datenumfang eines externen Inhalts nicht an der Verknüpfung selbst abzulesen ist, ist diese Information für einen Nutzer von großem Interesse. Sie kann direkt bei der Generierung der MM im sendenden MMS User Agent 2 erzeugt werden. Alternativ ist eine Generierung durch das MMS-Relay 3 möglich, er- fordert jedoch neben der Analyse der gesamten MM auch den Zugriff auf in Referenz angeführte Objekt zwecks Größenbestimmung.
• X-Mms-Content-Related-URI : Die Information CRV dieses Feldes zeigt den Ort eines anderen Elements, auf das der Datensatz 7 Bezug nimmt, an. Beispielsweise enthält ein Datensatz 7 eine Präsentationsbeschreibung, die sich auf andere Elemente mit Audio-, Video- oder anderen Inhalten der MM bezieht. Die Generierung dieser Informationen erfordert einerseits Wissen über die internen Bezüge der E- lemente einer MM, das auf Seiten des sendenden MMS User
Agents 2 vorhanden ist, und andererseits Wissen bezüglich der Positionen der MM-Elemente beim MMS-Relay/Server 3 bzw. beim Empfänger 4. Die Informationen können auf Seiten des sendenden MMS User Agents 2 in Header-Feldern co- diert werden und sind durch das MMS-Relay 3 auf Basis der dann aktuellen Positionen zu korrigieren/aktualisieren und anschließend im empfangenden MMS User Agent 4 auszuwerten.
Generierung bzw. Aktualisierung im MMS Relay 3: • X-Mms-Content-ID: Wird bei Veränderungen Content-ID durch das MMS Relay angepaßt.
• X-Mms-Content-Type: Falls das MMS Relay 3 den Typ und/oder das Format eines Datensatzes 7 ändert, erfolgt die entsprechende Aktualisierung des Content-Type.
• X-Mms-Content-Size: Größe des Datensatzes 7, angegeben in Octets. Nur falls das MMS Relay 3 Typ und/oder Format des Datensatzes ändert, erfolgt eine Aktualisierung der die Content-Size betreffenden Information.
Mit den differenzierten Informationen, die ein Benutzer 4 mit der Nachricht 11 (WAP: M-Notification. ind) erhalten hat, ist über den beispielsweise softwareseitig in einem Menü imple- mentierten und über ein Eingabemittel, etwa eine Tastatur, zu bedienenden Auswahlschalter 25 ein Zugriff auch auf einzelne Datensätze 7 möglich. So kann ein partielles Download durch eine Downloadanforderung mit der Content-ID eines jeweils gewünschten Datensatzes 7 (beispielsweise eines Fotos ohne gleichzeitige Mitübertragung des Begleittextes) in WAP mit dem Befehl 13: WSP GET.req veranlaßt werden.
Um dieses zu ermöglichen, muß das grundsätzliche Problem gelöst werden, daß die zusätzlichen Header-Felder teilweise in einer MM mehrfach verwendet werden müssen (WAP: z.B. X-Mms- Content-Name für jeden Datensatz 7 der MM) . Stehen mehrere Header-Felder in einem inhaltlichen Zusammenhang, was bei der Beschreibung eines Datensatzes der Fall ist, muß auch eine syntaktische Zuordnung definiert sein.
Grundsätzlich ist im WAP-Standard die Reihenfolge der Header- Felder unerheblich. Eine Veränderung der Reihenfolge der Informationen Name, Größe, Typ und/oder URI mehrerer Datensätze 7 würde damit eine Veränderung bzw. Verfälschung der Be- Schreibungen der Datensätze 7 bewirken, wenn man die Zuord- nung der Informationen von der Reihenfolge der Header- Elemente abhängig machte, was der einzig gangbare Weg ist, da eine hierarchische Struktur der Header-Elemente in WAP nicht vorgesehen ist. Andererseits steht die Aussage der Irrelevanz der Header- Element-Reihenfolge im Widerspruch zu der Aussage, daß HTTP- Header, die Listen enthalten, in mehrere WSP-Header mit jeweils nur einem einzigen Element umgewandelt werden sollen, wobei die Reihenfolge der Einträge erhalten bleiben soll. Um ' diesen Widerspruch aufzulösen, wird eine Systematik entworfen, die die Signifikanz der Reihenfolge der Header-Elemente voraussetzt.
Zur Abgrenzung der Beschreibungen einzelner Datensätze 7 muß ein definiertes Header-Feld die Beschreibung eines Datensatzes 7 beginnen, der alle nachfolgenden Header-Felder zugeordnet werden, bis entweder das Ende des Headers der Message erreicht ist oder ein nächstes Header-Feld des definierten Typs den Beginn der Beschreibung eines weiteren Datensatzes 7 mar- kiert.
Als definiertes Header-Feld für die Beschreibung eines Datensatzes 7 dient das Feld 17: X-Mms-Content-ID, da es die eindeutige Adresse des Elements enthält. Die Beschreibung eines Datensatzes 7 wird grundsätzlich durch dieses Feld eingeleitet, worauf die weiteren Felder optional und in beliebiger Reihenfolge erscheinen können.
Alternativ zu der Systematik mit eindeutigen Marken für die Message-Elemente - den Content-IDs - und den entsprechenden Verweisen im Header ist auch eine Systematik möglich, die mit der Angabe eines Offsets bis zu dem beschriebenen Datensatz im Datenteil der MM arbeitet. Nachteilig sind dabei allerdings zum einen die Gefahr, den Offset nicht korrekt zu be- rechnen bzw. bei einer möglichen Formatkonvertierung im MMS Relay 3 nicht korrekt anzupassen, und zum anderen die fehlen¬ de Möglichkeit, eine logische Beziehung zwischen einer Be¬ schreibung eines Datensatzes 7 in der Benachrichtigung 11 und in der tatsächlichen Übersendung 14 der MM herzustellen. Die Informationen müßten dann in der zugestellten Multimedia Mes¬ sage noch einmal enthalten sein.
Der Versender (Ebene 2) kann an seinem Telekommunikationsgerät 5 eine hardwareseitig oder insbesondere softwareseitig und über die ohnehin vorhandene Tastatur zu bedienende Eingabemöglichkeit betätigen, um damit in den Header-Feldern 17, 18, 19, 20, 21, 22, 23 die zusätzlichen Informationen oder einen Teil dieser Informationen (s.o.) zu hinterlegen. Diese werden als Bestandteil eines Identifizierungssignals für ei- nen oder mehrere Datensätze 7 der MM mit der Sendung 9 (in WAP: M-Send.req) (Fig. 1) an den Provider (Ebene 3) gesandt. Die Bestätigung des Versands durch das MMS-Relay 3 (in WAP mit der Nachricht 10: M-Send.conf) bleibt unverändert, da die einzige wesentliche Information die optional vom MMS-Relay 3 vergebene Message-ID ist.
Der Empfänger 4 erhält dann die Nachricht 11 (in WAP M- Notification. ind) , daß für ihn eine MM mit einem oder mehreren Datensätzen 7 zum Herunterladen bereitliegt. Diese Be- nachrichtigung 11 enthält wiederum alle zusätzlichen Header- Felder 17, 18, 19, 20, 21, 22, 23 zur Beschreibung der Datensätze 7 aus dem Header der Nachricht 9 zu ihrem Versenden (in WAP: M-Send.req). Diese Information kann dem Empfänger optisch (über das Anzeigemittel 24, beispielsweise das Display) oder akustisch mitgeteilt werden.
Die Bestätigung 12 (WAP: M-NotifyResp. ind) des Empfangs der Notification 11 bleibt unverändert.
Nachdem der Empfänger 4 der MM detailliert über deren Inhalt informiert ist, kann er die gesamte MM (in WAP: durch das Kommando 13: WSP Get.req) herunterladen. Alternativ ist nach dieser Erfindung auch ein Zugriff auf ein einzelnes Element der MM möglich. Hierzu wird beispielweise als URI die Content-ID eines Datensatzes 7 der MM in das Kommando zum Down¬ load eingesetzt. Ohne Zustimmung des Empfängers 4 wird ein Herunterladen der MM (Übersendung der Sendung 14 an den Empfänger) nicht freigegeben. Auch ist es möglich, daß der Empfänger 4 die MM erst zu einem späteren, billigeren Zeitpunkt übermittelt bekommen will.
Die eigentliche Datensendung 14 kann die beschreibenden Header-Felder 17, 18, 19, 20, 21, 22, 23 enthalten. Dies ist jedoch nicht zwingend , wie in Fig. 7 dargestellt.
Schließlich schickt das MMS-Relay 3, wenn vom Versender 2 gewünscht, eine Mitteilung 16 über den Status der Zustellung der MM (in WAP: M-Deliver . ind) an diesen. Neben den bisher schon bekannten Möglichkeiten "Expired" (verfallen) , λRetrie- ved" (zugestellt), Rejected" (abgelehnt), λDeffered" (verzö- gert)" kann erfindungsgemäß auch "Partly-retrieved" (partiell zugestellt) im Statusfeld auftreten. Es wird angezeigt, welcher Datensatz 7 zugestellt wurde. Der entsprechende Abschnitt der Nachricht 16 könnte wie folgt lauten:
>»»
7.2.22 Status field (Status-Feld)
Status-value = Expired | Retrieved | Rejected | Deferred | Partly-retrieved Expired = <Octet 128> Retrieved = <Octet 129> Rejected = <Octet 130> Deferred = <Octet 131 > Partly-retrieved = <Octet 132> <««
Die ebenfalls neuen Felder 22, 23 X-Mms-External-Link-Flag (optional) und X-Mms-External-Link-Size (optional) können in den Nachrichten 9 zum Versand der MM (WAP: M- Send.req) und in der Nachricht 11 an den Empfänger 4 (WAP: M- Notification. ind) die im Inhalt der MM enthaltenen Links auf Inhalte außerhalb der MM anzeigen. Je nach Position im MM
Header zeigt das Feld 22: X-Mms-External-Link-Flag einen Link auf externe Inhalte innerhalb der gesamten MM oder innerhalb eines bestimmten Datensatzes 7 der MM an. Das Feld 23: X-Mms- External-Link-Size beschreibt optional die Größe des Inhalts in Octets. Damit kann der Empfänger der Notification bereits abschätzen, welches zusätzliche Datenvolumen zu dem der MM selbst noch herunterzuladen ist.
Das vorgestellte Verfahren kann in eine Software zum Betrei- ben des jeweiligen Kommunikationsstandards, etwa UMTS, integriert sein. Die Telekommunikationsgeräte 5, 6 sind dann mit einer entsprechenden Software versehen.
Im folgenden ist ein konkreter Ablauf der erfindungsgemäßen Übermittlung einer MM nach dem WAP-Standard (Fig. 1) dargestellt:
Es wird beispielhaft folgendes Szenario angenommen: Versender 2 (Markus Trauberg) verschickt eine MM mit einem Text mit mehreren Datensätzen 7, nämlich einem MP3-Audio, einem JPEG- Bild, einem MPEG-4-Video und einer SMIL-Präsentationsbe- schreibung, an zwei Empfänger 4 (Andreas Schmidt und Josef Laumen) . Zur komfortablen und differenzierten Nutzung durch die Empfänger 4 fügt er Beschreibungen von Parametern der Da- tensätze 7 der MM ihrem Header bei. Die Daten werden in den
Nachrichten 9 (M-Send.req) und 11 (M-Notification. ind) an die Empfänger übertragen. Empfänger 4 Andreas Schmidt lädt die komplette MM auf sein Endgerät 6, während Empfänger 4 Josef Laumen nur an dem Text interessiert ist und nur diesen auf sein Endgerät 6 lädt. Die folgenden MMs werden zwischen den Einheiten übertragen:
MM wird an zwei Adressaten verschickt. Dann kann das Nach- richtenprotokoll wie in Figur 9 abgebildet sein.
In der MM sind im Header die zusätzlichen Informationsblöcke über die MM-Elemente codiert. Darin werden auch die Beziehungen zwischen den Datensätzen 7 der MM beschrieben: So enthält die Beschreibung der presentation_description Verweise auf die darin externen Elemente image/jpeg, audio/mp3 und vi- deo/mpeg4 in Form der entsprechenden Content-IDs. Die Beschreibung des Textes enthält die Information, daß ein Verweis auf ein externes Objekt enthalten ist, das 8245 Byte Daten umfaßt.
Die Quittierung der oben aufgeführten Sendeanfrage 9 (M- Send.req) des Versenders 2 erfolgt mit der Nachricht 10 (M- Send.conf) vom MMS Relay 3. Diese Nachricht 10 enthält keine zusätzlichen neuen Felder, wie an ihrer folgenden Aufstellung sichtbar ist, die in Figur 10 abgebildet ist.
Das MMS Relay 3 bestätigt mit Nachricht 10, daß die Anfrage 9 fehlerfrei zum MMS Relay 3 übertragen worden ist. Es wird die Transaction-ID#l benutzt, um die Nachricht 10 beim Versender 2 eindeutig der dazugehörigen Anfrage 9 (M-Send.req) und damit der gesendeten MM zuzuordnen. Weil in der Nachricht 9 in dem Feld X-Mms-Delivery-Report ein Zustellungsreport angefordert wurde, weist das MMS Relay 3 der MM eine Message-ID zu und übermittelt diese hier an den Versender 2.
Im weiteren wird die Nachricht 11 an die Empfänger 4 übertragen:
M-Notification. ind (MMS Relay -> MMS User Agent B) : Im MMS ist vorgesehen, einen Empfänger einer MM über neue Nachrichten, die für ihn vorliegen, zu informieren. Die Nach¬ richt 11 (M-Notification. ind) dient der Benachrichtigung der Adressaten über zum Download bereitliegende MM. Folglich e- xistieren in diesem Beispiel zwei Benachrichtigungen an die Empfänger Andreas Schmidt und Josef Laumen. Jede enthält eine eigene Transaction-ID. Die Information über den Speicherplatz der MM steht bei beiden in dem Feld X-Mms-Content-Location.
Figur 11 gibt den Inhalt der M-Notification-ind exemplarisch wieder.
Neben den üblichen Feldern zu Beginn der Nachricht 11 können nun alle beschreibenden Elemente der Nachricht 9 in die Nachricht 11 übernommen werden. Zusätzlich werden, wie oben anhand der Mischform beschrieben, durch das MMS Relay 3 noch die Informationen X-Mms-Content-Type und X-Mms-Content-Size aus den Informationen des Body der Nachricht 9 generiert. Der Empfänger 4 kennt nach Erhalt der Nachricht 11 sowohl die Adresse der MM (wie bisher) als auch die Zusammensetzung aus den einzelnen Datensätzen 7 und deren Content-IDs. Ein Zugriff ist daher auch separat auf einzelne Datensätze 7 der MM möglich.
Der korrekte Empfang der Benachrichtigung wird anschließend von dem Empfänger 4 der MM mit der Nachricht 12 (M- Notif Resp. ind) bestätigt, indem die entsprechende Transaction-ID der Nachricht 11 zusammen mit einer Statusmeldung zu- rück zum MMS Relay 3 geschickt wird.
Der Download der MM wird durch das Kommando 13 (WSP GET.req) veranlaßt. Die MM wird darauf vom MMS Relay 3 in der Nachricht 14 (M-Retrieve.conf) zum Empfänger 4 gesendet. Da die Informationen über die einzelnen Elemente bereits mit der Nachricht 11 übertragen wurden, kann der Download der ge¬ samten MM wie bisher mit der Nachricht 14 erfolgen, ohne daß zusätzliche Felder im Header dieser Nachricht 14 eingefügt werden müssen. Die zusätzlichen Informationen in den Headern der einzelnen Datensätze 7 hingegen sollten auch in der Nachricht 14 enthalten sein, da sie wichtige Informationen über die MM-Datensätze 7 enthalten.
Im folgenden sind zwei mögliche Reaktionen der Empfänger 4 beispielhaft dargestellt:
Empfänger Andreas Schmidt lädt die gesamte MM. Empfänger Josef Laumen lädt nur den Textteil der MM auf sein Empfangsgerät 6.
Im ersten Fall wird die Nachricht 14 wie in Figur 12 abgebildet codiert:
Der Empfänger 4 Andreas Schmidt quittiert den erfolgreichen Empfang der MM anschließend Nachricht 15 (M-Acknowledge . ind) . Mit der darin enthaltenen Transaction-ID ist am MMS Relay 3 die Zuordnung zu der gesendeten MM entsprechend dem Informationssignal M-Acknowledge. ind von Figur 13 möglich.
Als letzter Schritt der Transaktion wird schließlich die Nachricht 16 (M-Delivery. ind) entsprechend Figur 14' vom MMS Relay 3 an den Versender 2 übermittelt:
Der zweite Empfänger Josef Laumen hingegen entscheidet sich dafür, nur den Textteil der Nachricht 14 zu laden. Dazu setzt er in die Nachricht 13 (WSP GET.req) die Conteht-ID des Textteils ein: " 000714.1412. lmarkus .trauberg" . Er erhält diesen Textteil mit der Nachricht 14 (M-Retrieve. conf) , die gegen- über der Version an Andreas Schmidt deutlich verändert ist und deren Inhalt in Figur 15 exemplarisch wiedergegeben ist.
Die Nachricht 14 wurde gegenüber ihrer kompletten Version, wie sie an Andreas Schmidt geschickt wurde, um die nicht erwünschten Datensätze 7 reduziert. Außerdem wurde das Feld nEntries entsprechend angepaßt.
Die Nachricht 15 (M-Acknowledge . ind) , die in Figur 16 darge- stellt ist, entspricht fast komplett der Version an Andreas Schmidt, enthält aber eine eigene Transaction-ID:
Als letzter Schritt erfolgt wieder die Benachrichtigung des Versenders 2 über den Status der Zustellung. Sie enthält den Status der partiellen Zustellung ("Partly-retrieved") und ist inhaltlich in Figur 17 dargestellt.
Neben den vorstehend beschriebenen Möglichkeiten zur detaillierten Benachrichtigung von Empfängern von Multimedia Nach- richten (MMs) im Multimedia Messaging Service (MMS) besteht eine weitere, zweckmäßige Option, die Vorteile gegenüber den bereits vorgestellten Varianten hat. Diese vorteilhafte Option wird nachfolgend beschrieben.
Kern dieser Modifikation ist die Realisierung der Idee, den jeweiligen Empfänger detailliert über den Inhalt der jeweiligen MM zu informieren, wobei lediglich ein einziges, neu definiertes Header-Feld genutzt wird, für das neue Parameter eingeführt werden. Das neue Header-Feld enthält dabei alle Parameter, d.h. Informationen über ein zu beschreibendes Element der MM. Unter Element bzw. Datensatz einer MM wird in dieser Erfindungsmeldung ein einzelner Bestandteil einer MM verstanden, der insbesondere durch seinen Typ (z.B. Standbild) und sein Format (z.B. JPEG (= Joint photographics ex- pert group) ) definiert ist. Die folgende Liste enthält die bereits zu den vorausgehenden
Varianten vorgeschlagenen Informationen, die dem Empfänger einer MM optional in einer Empfängerbenachrichtigung im MMS
(M-Nind; in WAP: M-Notlf ication . ind) zur Verfügung gestellt werden können. Dazu gehören:
• die Anzahl der enthaltenen Elemente der MM (auch implizit durch die Beschreibung der einzelnen Elemente der MM) ,
• die Größe (in Octets) eines Elements,
• der Typ und das Format eines Elements, • die Content ID (Content IDentification) eines Elements (= Name bzw. Bezeichner des jeweiligen Headerfeldes des jeweiligen Identifikationssignals) ,
• der Name eines Elements,
• die Verbindung eines Elements zu einem oder mehreren ande- ren Elementen der MM,
• die Verbindung der gesamten MM oder eines/mehrerer Elemente zu einer oder mehreren URLs/URIs (uniform resource link/identifier) außerhalb der MM und bei einem solchen externen Bezug optional die Größe der zu ladenden Objekte des/der aufgelösten externen Bezüge.
Die Definition der entsprechenden Header-Felder zur optionalen Erweiterung der MMS Empfängerbenachrichtigung (M-Nind; in WAP: M-Notif ication . ind) und gegebenenfalls auch der MMS Sen- deanfrage (M-Sreq; in WAP: M-Send. req) und der MMS- Zustellnachricht (M-Rconf; in WAP: M-Retrieve . conf ) sind im beim nachfolgenden Ausführungsbeispiel beschrieben.
Eine MM besteht grundsätzlich - wie in den vorausgehenden Ausführungsbeispielen aufgezeigt - aus einem Header und abhängig vom Typ der Nachricht ggf. zusätzlich aus einem Datenteil (WAP: Body) . Der Header umfasst allgemeine Informationen der Nachricht und setzt sich aus ein oder mehreren, definierten Header-Feldern zusammen. Der etwaige Datenteil der Messa- ge enthält ein oder mehrere Elemente beliebigen Typs, die in beliebiger Reihenfolge dem Header folgen. Falls eine Präsen- tationsbeschreibung im Datenteil enthalten ist, soll z.B. in einer WAP-Nachricht zu Beginn des Datenteils ein so genannter Start-Parameter auf diese Präsentationsbeschreibung zweckmäßigerweise hinweisen.
Figur 1 zeigt dabei in einem Nachrichtenflussdiagram den prinzipiellen Ablauf einer Nachrichtenübermittlung von der Nutzerapplikation des sendenden Nutzers 2 (User Agent A = M- UA_A) über die MMS Verbindungseinheit 3 (MMS Relay=M-SR) zur Nutzerapplikation des empfangenden Nutzers 4 (User Agent B =(M-UA_B) ) .
Die je nach Nachrichten-Typ möglichen bzw. erforderlichen
Header-Felder in WAP sind für die hier betrachteten Nachrichten-Typen in den Tabellen entsprechend der Figuren 21 A/21B und 22 dargestellt. Diese wurden WAP-209-MMSEncapsulation, Release 2000; Wireless Application Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD
1.0 entnommen. Nach WAP-203-WSP, Version 4-May-2000; Wireless Application Protocol, Wireless Session Protocol Specificati- on; Chapter 8.4: "Header Encoding" besteht jedes Header-Feld aus einem Feld-Namen, gefolgt von einem Feld-Wert, der aus mindestens einem Octet besteht. Die Zuweisung von hexadezimalen Werten zu den Feld-Namen der WAP Messages ist in der Tabelle entsprechend Figur 20 aufgeführt.
Diese weitere Option beruht auf der zu den vorausgehenden Ausführungsbeispielen eingeführten Definition eines Header- Feldes zur eindeutigen Kennzeichnung eines Elementes einer MM, dem Header-Feld X-Mms -Content-ID, das im Body der MM dem Element der MM als Header-Feld voransteht und das Element eindeutig kennzeichnet. Abweichend von den vorausgegangenen Vorschlägen basiert die Beschreibung eines Elementes der MM hier auf einem einzigen Header-Feld X-Mms-Content-ID, das in den Header der MM zur Benachrichtigung des Empfängers integriert wird, und das die nötigen Informationen (für die Benachrichtigung des Empfängers z.B. über Anzahl, Typ, Größe, Format der für ihn bereitgehaltenen Datensätze der MM) durch einen oder mehrere Para¬ meter aus der folgenden Liste beschreibt.
• Name beschreibt den Namen des MM-Elements; • Type beschreibt den Typ und das Format des MM-Elements;
• Size beschreibt die Größe des MM-Elements in Bytes;
• External -Link zeigt an, dass das Element eine Verknüpfung auf Inhalte außerhalb der MM enthält;
• External -Link-Size gibt an, welches Datenvolumen zum Auf- lösen der externen Referenz zusätzlich heruntergladen werden muß;
• Related-ID gibt an, welches Element der MM mit dem Element in Bezug steht und bei einem partiellen Herunteralden der MM ebenfalls geladen werden sollte (Mehrfachverwendung möglich.
Allgemein ausgedrückt wird also jetzt das Identifikationssignal für einen oder mehrere zugeordnete Datensätze in einem einzigen, zusätzlichen Headerfeld vom jeweiligen Sender wie z.B. einem ersten Mobilfunkgerät und/oder zuständigen Server in einer MMS Empfängerbenachrichtigung zum Empfänger wie z.B. zu einem zweiten Mobilfunkgerät codiert übertragen. Dadurch sind Reihenfolgen- und Zuordnungsprobleme, wie sie etwaig bei der Verwendung mehrerer Headerfelder zwischen diesen selbst und/oder den zugeordneten Datensätzen auftreten könnten, von vornherein vermieden. Weiterhin sollen zusätzlich zu den bereits zu den vorausge¬ henden Ausführungsbeispielen beschriebenen auch folgende In¬ formationen als Parameter codiert werden können:
1. Original -Type beschreibt den Typ des MM-Elements vor der Transcodierung durch die MMS Verbindungseinheit (M- SR) ;
2. Original -Size beschreibt die Größe des MM-Elements vor der Transcodierung durch die MMS Verbindungseinheit (M- SR) in Bytes;
Durch die Zusammenfassung aller für ein MM-Element relevanten Informationen in einem einzigen Header-Feld, kann auf eine Einhaltung der Header-Reihenfolge, wie sie bei den vorhergehenden Ausführungsbeispielen vorausgesetzt wird, verzichtet werden.
In Figur 18 ist das zum Zwecke der detaillierten Benachrichtigung des Empfängers einer MM gemäß WAP neu eingeführte, einzige Header-Feld einschließlich der Codierung von Feld- Name und Feld-Wert aufgeführt. Die Tabelle entsprechend Figur 20 enthält die Zuweisung von hexadezimalen Werten zu den Feld-Namen. Die Tabelle entsprechend Figur 19 enthält die Zuweisung von hexadezimalen Werten zu den Parameternamen und weiterhin die zur Codierung der Parameterwerte zu verwenden- den Typen. Die um die entsprechenden Header-Felder ergänzten WAP Nachrichten sind in den Tabellen 21A/21B und 22 aufgelistet. Alle Veränderungen und Ergänzungen in den Tabellen zum heutigen Stand der Technik sind dabei eingerahmt.
Ausführungsbeispiel:
Im nun folgenden Ausführungsbeispiel, das auf der Definition der beschriebenen Nachrichten durch das WAP-Forum basiert, wird detailliert auf die in den WAP Nachrichten benutzten Header-Felder eingegangen. Dabei wird beispielhaft folgendes Szenario angenommen: M-UA_A (Markus Trauberg) verschickt eine Multimedia Message MMA bestehend aus einem Text, einem MP3- Audio, einem JPEG-Bild, einem MPEG-4-Video und einer SMIL (synchronized multimedia Integration language)- Präsentationsbeschreibung an einen Empfänger M-UA_B (Andreas Schmidt) . Zur komfortablen und differenzierten Nutzung durch den Empfänger werden Beschreibungen der Elemente der MM dem Header der MM gemäß dieser Erfindungsmeldung zugefügt. Die Daten werden in den Nachrichten M-Sreq und M-Nind an den Empfänger übertragen. Empfänger Andreas Schmidt lädt die kom- plette MM auf sein Endgerät. Die folgenden Nachrichten werden zwischen den Einheiten übertragen.
MMA wird an einen Adressaten verschickt. Deren Inhalt ist in Figur 23 beispielhaft abgebildet.
In der Message sind im Header die zusätzlichen Informationsblöcke, d.h. allgemein ausgedrückt die ein oder mehreren Parameter über die MM-Elemente codiert. Darin werden auch die Beziehungen zwischen den Elementen der MM beschrieben: So enthält die Beschreibung der Präsentationsbeschreibung (*.smil) Verweise auf die darin referenzierten Elemente i age/jpeg, audio/mp3 und video/mpeg4 in Form der entsprechenden Content-IDs. Die Beschreibung des Textes enthält die Information, dass ein Verweis auf ein externes Objekt enthalten ist, das 8245 Byte Daten umfasst.
Nach dem Stand der Technik wird die Sendeanfrage (WAP: M- Send. req) des MMS User Agent A mit einer Nachricht (in WAP:M- Send. conf) vom M-SR quittiert. Im Rahmen dieser EM wird diese Message nicht modifiziert und daher hier nicht aufgeführt.
M-Nind (M-SR → M-UÄ-B) : Im MMS (multi edia Services) entsprechend 3G TS 23.140 Versi¬ on 3.0.1, Release 1999; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS) ; Functional Description; Stage 2 und WAP-209- MMSEncapsulation, Release 2000; Wireless Application Proto¬ col; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD 1.0 ist vorgesehen, einen Empfänger einer MM über neue Nachrichten, die für ihn vorliegen, zu informieren. Die Nachricht M-Nind (in WAP: M-Notif ication . ind) dient der Benachrichtigung der Adressaten über zum Herunterladen bereitliegende MMs. Ihr Inhalt ist beispielhaft in Figur 24 abgebildet. Folglich existiert in diesem Beispiel eine Empfängerbenachrichtigung an den Empfänger Andreas Schmidt. Die Information über den Speicherplatz der MMA steht dabei in dem Feld X-Mms-Content-Location .
Neben den üblichen Feldern zu Beginn der Nachricht können nun alle beschreibenden, nach dieser Variante neuen Elemente der Nachricht M-Sreq in die Nachricht M-Nind übernommen werden. Zusätzlich werden durch die M-SR noch die Informationen Type und Size aus den Informationen des Body der Nachricht M-Sreq generiert bzw. wird das enthaltene Bild vom Typ image/jpeg in den Typ image/bmp konvertiert, da das Endgerät JPEG-Bilder nicht anzeigen kann. Die entsprechenden Informationen über den ursprünglichen Typ (Original-Type) und die ursprüngliche Dateigröße (Original-Size) sind im entsprechenden Header-Feld ergänzt worden. Der Empfänger kennt nach Erhalt der detailed Notification sowohl die Adresse der MM (wie bisher) als auch die Zusammensetzung aus den einzelnen Elementen und deren Content-IDs . Ein Zugriff ist daher auch separat auf einzelne Elemente der MM möglich.
Der korrekte Empfang der Benachrichtigung kann anschließend von dem Empfänger der MMA mit der Nachricht M-N ind bestätigt werden, indem die entsprechende Transaction-ID der M-Nind zu- sammen mit einer Statusmeldung zurück zum MMS Relay geschickt wird. Dann wird das Herunterladen der MMA durch den Befehl W- Greq veranlasst. Die MM wird darauf vom M-SR in der Nachricht M-Rconf zum MM-UA A gesendet.
Im Folgenden wird die Nachricht von dem Empfänger Andreas Schmidt komplett auf sein Endgerät heruntergeladen. Die Nachricht M-Rconf wird beispielsweise wie in Figur 25 codiert.
Der Empfänger M-UA B quittiert den erfolgreichen Empfang der MMA anschließend gemäß Stand der Technik mit der Nachricht
Zusammenfassend betrachtet wird somit ein Verfahren zur Übertragung zusätzlicher Informationen zur detaillierten Be- Schreibung einer Multimedianachricht und der darin enthaltenen MM-Elemente im Multimedia-Messaging-Service (MMS) bereitgestellt. Diese Informationen werden insbesondere mit einem einzigen oder mehreren zusätzlichen Header-Feldern in der jeweiligen MMS Empfängerbenachrichtigung vom jeweilig zuständi- gen Server wie z.B. M-SR zum empfangenden User Agent übertragen. Die nötigen Informationen werden vorzugsweise vom sendenden User Agent generiert und in der MMS Sendeanfrage von diesem codiert zum zuständigen Server übertragen. Zusätzlich oder unabhängig hiervon können die nötigen Informationen auch vom zuständigen Vermittlungs-/Bereitstellungs-Server aus dem Datenteil der jeweilig zu versendenden MM extrahiert und dem Empfangenden User Agent in der MMS Empfängerbenachrichtigung codiert übertragen werden. Vorzugsweise kann dem empfangenden User Agent eine oder mehrere der folgenden Informationen über den Inhalt oder einzelne Elemente des Inhalts der zur Zustellung z.B. im zuständigen Server bereitliegenden Nachricht mitgeteilt werden:
• Anzahl der in der MM enthaltenen Elemente
• Größe des Elements der MM (in Octets) • Typ und Format des Elements der MM • Kennzeichnung des Elements (Content-ID bzw. URI)
• Name des Elements
• die Verbindung eines oder mehrerer Elemente zu einem o- der mehreren anderen Elementen innerhalb der MM (z.B. zwischen Präsentationsbeschreibung und Präsentationselement)
• die Verbindung eines oder mehrerer Elemente zu Inhalten beliebiger Natur außerhalb der MM (z.B. zu HTML/WML- Seiten) • die jeweilige Größe der verknüpften externen Elemente, die zusätzlich zur MM selbst geladen werden können (in Octets)
• der Typ und das Format des Elements vor einer Transcodierung durch die M-SR • die Größe des Elements vor einer Transcodierung durch die M-SR (in Octets)
Insbesondere bildet dabei die Kennzeichnung des Elements (Content -ID bzw. URI) den ersten Eintrag im einzigen Header- feld oder den Inhalt des ersten Headerfeldes bei mehreren benutzten Headerfeldern pro Element bzw. Datensatz.
Bevorzugt kann die Beschreibung eines Elements einer MM jeweils mit einem einzigen Feld ausgeführt werden, das per ein- deutiger Identifikationsnummer bzw. Bezeichner auf das Element im Datenteil der Multimedianachricht verweist, und das die weiteren Informationen als Parameter auch noch und nicht in separaten Headerfeldern enthält.
Der Empfänger einer MM kann vorzugsweise, nachdem er eine detaillierte Benachrichtigung erhalten hat, auch nur einzelne Elemente der MM auf sein Endgerät laden. Genauso ist es ggf. möglich, dass die nach dieser Erfindung zusätzlichen Informa- tionen der MMS Empfängerbenachrichtigung (M-Nind) auch im Header der MMS Zustellnachricht (M-Rconf) ergänzt werden.
Vorzugsweise kann das zusätzliche Header-Felder - wenn nur ein einziges Headerfeld pro Datensatz verwendet wird - in WAP wie folgt codiert werden:
Codierung des Feld-Namens X-Mms-Content-ID im Wertebereich zwischen 00X00 bis 0X7F, insbesondere als 0x19 gemäß der Tabelle nach Figur 20. Codierung des Feld-Wertes von X-Mms-Content-ID gemäß Figur 9.
Die Informationen als Parameter in diesem einzigen Header- Feld können insbesondere nach der Tabelle von Figur 19 codiert werden.
Hintergrundangaben zu WAP und MMS, insbesondere zu deren einschlägiger Normenliteratur finden sich beispielsweise an folgenden Stellen:
[1] 3G TS 23.140 ersion 3.0.1, Release 1999; Third Ge- neration Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS) ; Functional Description; Stage 2 [2] WAP-209-MMSEncapsulation, Release 2000; Wireless
Application Protocol; WAP Multimedia Messaging Ser- vice; Message Encapsulation; MMS Proposed SCD 1.0
[3] WAP-203-WSP, Version 4-May-2000; Wireless Application Protocol, Wireless Session Protocol Specifica- tion; Chapter 8.4: "Header Encoding". [4] WAP-Forum:" WAP MMS Interworking with Internet E- mail; WAP-207-MmsInetInterworking" ; Draft Version
Ol-Jun-2000. [5] 3G TS 22.140 v.4.0.1 (Juli 2000) : 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Aspects; Stage 1 Multimedia Messaging Service. [6] RFC822: "Standard for the Format of ARPA Internet Text Messages", Crocker D., August 1982. URL: ftp ϊ //ftp . isi . edu/in-notes/rfc822. txt .
[7] RFC2045: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bo- dies", Freed N., November 1996. URL: ftp : //ftp . isi . edu/in-notes/rfc2045. txt .
[8] RFC2046: "Multipurpose Internet Mail Extensions
(MIME) Part Two : Media Types", Freed N., November 1996. URL: ftp://ftp.isi.edu/in-notes/rfc2046.txt.
[9] RFC2047: "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non- ASCII Text", Moore K., November 1996. URL: ftp : //ftp . isi . edu/in-notes/rfc2047. txt .
Im Rahmen der Erfindungsbeschreibung ist der einfacheren
Schreibweise halber im Kontext auf folgende, gängigen Akronyme Bezug genommen wurden, die zum besseren Verständnis mit ihrer vollständigen Bedeutung nachfolgend aufgelistet sind:
GSM Global System for Mobile Communication
MM Multimedianachricht (Multimedia Message)
MMS Multimedia Messaging Service
SMS Short Message Service
UMTS Universal Mobile Telecommunication System WAP Wireless Application Protocol
WSP Wireless Session Protocol
MMS spezifische Abkürzungen:
M-UA MMS Nutzer Applikation
M-SR MMS Verbindungseinheit
M-Sreq MMS Sendeanfrage
M-Sconf MMS Sendebestätigung
M-Nind MMS Empfängerbenachrichtigung M-NRind MMS Empfängerbenachrichtigungsbestätigung W-Greq MMS Zustellanfrage
M-Rconf MMS Zustellnachricht
M-Aind MMS Zustellungsbestätigung
M-Dind MMS Zustellstatusbenachrichtigung

Claims

Patentansprüche
1. Verfahren zur Datenübertragung in einem Mobilfunknetz, insbesondere von Text- und/oder Bilddaten mit und ohne Ton, d a d u r c h g e k e n n z e i c h n e t , daß den Daten zumindest ein Identifikationssignal für einen Datensatz oder mehrere Datensätze zugeordnet und dieses oder diese Identifikationssignal (e) an den Empfänger der Daten ü- bertragen wird oder werden.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifikationssignal (e) vor Übertragung des oder der durch diese (s) charakterisierten Datensatzes oder Datensätze übertragen wird und optisch oder akustisch anzeigbar ist.
3. Verfahren nach Anspruch 2, d a d u r c h- g e k e n n z e i c h n e t , daß der Empfänger des oder der Identifikationssignal (e) auswählen kann, ob er die Übertragung der durch diese charakterisierten Daten ganz oder teilweise zuläßt.
4. Verfahren nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über die Art eines Datensatzes, insbesondere dessen Datenformat, enthält.
5. Verfahren nach einem der Ansprüche 1 bis4, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über den Namen eines Datensatzes enthält.
6. Verfahren nach einem der Ansprüche 1 bis 5, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über den Inhalt ei¬ nes Datensatzes enthält.
7. Verfahren nach einem der Ansprüche 1 bis 6, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über die Größe ei¬ nes Datensatzes enthält.
8. Verfahren nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über die Anzahl von Datensätzen innerhalb von übertragenen Daten enthält.
9. Verfahren nach einem der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über eine Verknüpfung mit zumindest einem Datensatz innerhalb der gesendeten Daten enthält.
10. Verfahren nach einem der Ansprüche 1 bis 9, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über eine Verknüpfung mit zumindest einem Datensatz außerhalb der gesendeten Daten enthält.
11. Verfahren nach einem der Ansprüche 9 oder 10, d a d u r c h g e k e n n z e i c h n e t , daß das Identifikationssignal Information über die Größe desjenigen Datensatzes oder derjenigen Datensätze, mit denen ein übertragener Datensatz verknüpft ist, enthält.
12. Verfahren nach einem der Ansprüche 1 bis 11, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über die Kennzeich- nung eines Datensatzes enthält.
13. Verfahren nach einem der Ansprüche 1 bis 12, d a d u r c h g e k e n n z e i c h n e t , daß das Verfahren im Mobile Messaging Service (MMS) angewandt wird und die übertragenen Daten als Mobile Messages (MM) aus- gebildet sind.
14. Verfahren nach einem der Ansprüche 1 bis 13, d a d u r c h g e k e n n z e i c h n e t , daß das Verfahren im Übertragungsstandard UMTS (Universal Mo- bile Telecommunication System) , im GSM (Global System for mo¬ bile communication) , im GPRS (General packet radio service) und/oder im EDGE (Enhanced Data Rates for GSM enviroments angewandt wird.
15. Verfahren nach einem der Ansprüche 1 bis 14, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifikationssignal (e) einem oder mehreren Header-Feldern der übertragenen Daten zugeordnet wird oder werden.
16. Verfahren nach einem der Ansprüche 1 bis 15, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifkationssignal in zumindest einem zusätzlichen Header-Feld abgelegt wird.
17. Verfahren nach einem der Ansprüche 1 bis 16, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifizierungssignal (e) zumindest teilweise vom Versender generiert und bei Übermittlung einer Multi- media message vom Versender (MMS user agent A) zum Service Provider (MMS relay) übersandt werden.
18. Verfahren nach Anspruch 17, d a d u r c h g e k e n n z e i c h n e t , daß der Versender eines oder mehrere der Header-Felder, X- MMS-Content-ID, X-MMS-Content-Name, X-MMS-Content-Type, X- MMS-External-Link-Flag, X-MMS-External-Link-Size' generiert.
19. Verfahren nach einem der Ansprüche 1 bis 18, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifizierungssignal (e) zumindest teilweise aus dem vom Service Provider (MMS Relay) empfangenen Da¬ tensatz selbständig ermittelt wird oder werden
20. Verfahren nach Anspruch 19, d a d u r c h g e k e n n z e i c h n e t , daß das MMS Relay eines oder mehrere der Header-Felder X-MMS- Content-ID, X-MMS-Content-Size, X-MMS-Content-Type generiert oder aktualisiert.
21. Verfahren nach einem der Ansprüche 1 bis 20, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifizierungssignal (e) jeweils in der Benachrichtigung an den Empfänger (MMS user agent B) durch das MMS Relay des Service Providers über das Vorhandensein eines oder mehrerer neuen Datensätze einer Multimedia message übertragen wird.
22. Verfahren nach einem der Ansprüche 1 bis 21, d a d u r c h g e k e n n z e i c h n e t , daß dem Telekommunikationsgerät des Empfängers eine Wahleinrichtung zugeordnet ist, mittels der dieser nach zumindest teilweiser Kenntnisnahme des oder der Identifikationssignal (e) eine Bestätigung der Empfangsbereitschaft für den Da- tensatz geben kann, und die Übertragung zum Empfänger erst nach Auslösung der Wahleinrichtung ermöglicht ist.
23. Verfahren nach Anspruch 22, d a d u r c h g e k e n n z e i c h n e t , daß sich die Empfangsbereitschaft nur auf einen Teil der Da- ten bezieht und die Übertragung nur dieses Teils des Daten¬ satzes freigeschaltet wird.
24. Verfahren nach einem der Ansprüche 1 bis 23, d a d u r c h g e k e n n z e i c h n e t , daß das oder die zusätzlichen Identifizierungssignal (e) der
Benachrichtigung über bereitstehende Daten (M-
Notification. ind) und der eigentlichen Datensendung (M-
Retrieve.conf) zugefügt werden.
25. Verfahren nach einem der Ansprüche 1 bis 24, d a d u r c h g e k e n n z e i c h n e t , daß die Bereitschaft zum zumindest teilweisen Empfang der bereitstehenden Daten der vom Empfänger an den Provider gesand- ten Nachricht WSP Get.req zugeordnet ist.
26. Mobiltelekommunikationsgerät (5; 6) zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 25, d a d u r c h g e k e n n z e i c h n e t , daß dem Mobiltelekommunikationsgerät (5; 6) ein Auswahlschalter (25) zur völligen oder teilweisen Bestätigung oder Ablehnung der Empfangsbereitschaft für einen oder mehrere identifizierten Datensatz oder Datensätze (7) zugeordnet ist.
27. Mobiltelekommunikationsgerät nach Anspruch 26, d a d u r c h g e k e n n z e i c h n e t , daß dem Mobiltelekommunikationsgerät (5; 6) ein Anzeigemittel (24) zur optischen oder akustischen Anzeige des oder der I- dentifizierungssignale eines oder mehrerer Datensätze (7) zu- geordnet ist.
28. Mobiltelekommunikationsgerät nach einem der Ansprüche 26 oder 27, d a d u r c h g e k e n n z e i c h n e t , daß der Auswahlschalter (25) softwareseitig implementiert und über ein Eingabemittel anwählbar ist.
29. Mobiltelekommunikationsgerät (5;6), d a d u r c h g e k e n n z e i c h n e t , daß diesem eine Software zur Belegung von Header-Feldern (17;18;19;20;21;22;23) von Datensendungen mit zumindest einem Identifikationssignal zugeordnet ist.
30. Computerprogrammerzeugnis, das ein computerlesbares
Speichermedium umfaßt, auf dem ein Programm gespeichert ist, das es einem Computer ermöglicht, nachdem es in den Speicher des Computers geladen worden ist, innerhalb von Datenübertragung in einem Mobilfunknetz den zu übertragenden Daten zumin- dest ein Identifizierungssignal mit charakterisierenden Angaben zu einem Datensatz (7) oder mehreren Datensätzen (7) an den jeweiligen Empfänger (4) weiterzuleiten.
31. Computerprogrammerzeugnis nach Anspruch 30, d a d u r c h g e k e n n z e i c h n e t , daß dieses ein Verfahren nach einem der Ansprüche 1 bis 25 bei Datenversand in einem Mobilfunknetz durchführt.
32. Funkkommunikationssystem, bei dem mindestens eine Kompo- nente nach einem Verfahren der vorhergehenden Ansprüche arbeitet.
PCT/EP2001/014617 2001-01-18 2001-12-12 Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz WO2002058359A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2002558717A JP4358511B2 (ja) 2001-01-18 2001-12-12 移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置
EP01273297A EP1352500B1 (de) 2001-01-18 2001-12-12 Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz
US10/466,749 US8099081B2 (en) 2001-01-18 2001-12-12 Method and mobile telecommunications device for transmitting data in a mobile radio network

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
EP01101057.6 2001-01-18
EP01101057 2001-01-18
EP01102229.0 2001-01-31
EP01102229 2001-01-31
EP01107278.2 2001-03-23
EP01107278 2001-03-23

Publications (1)

Publication Number Publication Date
WO2002058359A1 true WO2002058359A1 (de) 2002-07-25

Family

ID=27224113

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2001/014617 WO2002058359A1 (de) 2001-01-18 2001-12-12 Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz

Country Status (3)

Country Link
US (1) US8099081B2 (de)
JP (2) JP4358511B2 (de)
WO (1) WO2002058359A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1303090A2 (de) 2001-10-09 2003-04-16 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten
WO2003105425A1 (de) * 2002-06-07 2003-12-18 Siemens Aktiengesellschaft Übertragung vno mms-nachrichten mit konvertierung von datai-typen und/oder -formaten
DE10325889A1 (de) * 2003-06-06 2004-12-23 Siemens Ag Verfahren zum Übertragen von Nachrichten
EP1531639A2 (de) * 2003-11-12 2005-05-18 Vodafone Holding GmbH Verfahren zur Übertragung von Daten auf ein mobiles Endgerät in Mobilfunknetzen
JP2006501705A (ja) * 2002-08-02 2006-01-12 シーメンス　アクチエンゲゼルシヤフト ユーザデータメッセージを伝送するための方法、加入者機器並びに無線通信システム
US7010790B2 (en) * 2002-11-20 2006-03-07 Cegetel Modular method and device for the tracing of a multimedia message through a telecommunications network

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10230897A1 (de) * 2002-07-09 2004-01-29 Siemens Ag Nachrichtenübertragungsverfahren und -system
EP1387539A1 (de) * 2002-08-02 2004-02-04 Siemens Aktiengesellschaft Verfahren und System zum Blockieren von unerwünschten Nachrichten
EP1424860A3 (de) * 2002-11-05 2006-01-25 Siemens Aktiengesellschaft Verfahren zur Steuerung eines Multimedia-Nachrichtendienstes zwischen einem Telekommunikationsgerät und einem Telekommunikationsnetz, übereinstimmende Chipkarte und Telekommunikationsgerät
US20040176114A1 (en) * 2003-03-06 2004-09-09 Northcutt John W. Multimedia and text messaging with speech-to-text assistance
KR100517988B1 (ko) * 2003-04-16 2005-09-30 엘지전자 주식회사 Ｇｓｍ 단말기의 문자메시지 수신 방법
US7865181B1 (en) 2004-03-19 2011-01-04 Single Touch Interactive, Inc. Searching for mobile content
US20060031369A1 (en) * 2004-07-01 2006-02-09 Marc Caron Method, system, and edge multimedia messaging service (MMS) relay/server for multi-staged MMS
KR101048432B1 (ko) * 2004-10-05 2011-07-11 엘지전자 주식회사 이동통신 단말기의 파일을 이용한 메시지 전송 방법
AU2004324519B2 (en) * 2004-11-02 2010-06-10 Core Wireless Licensing S.A.R.L. Informing recipient device of message content properties
KR101155335B1 (ko) * 2005-01-07 2012-06-11 엘지전자 주식회사 이동통신 단말기의 멀티미디어 메시지 동작방법
KR100764787B1 (ko) * 2005-09-14 2007-10-11 엘지전자 주식회사 액티브 콘텐츠를 송수신하기 위한 방법 및 단말기
US8050660B2 (en) * 2006-03-07 2011-11-01 Motorola Mobility, Inc. Apparatus and method for handling messaging service message adaptation
WO2009116053A2 (en) * 2008-03-18 2009-09-24 Nowpos Online Services Pvt. Ltd. An invention for dispatch of opacity-controlled 'always-on-top' formats on telecommunication devices
EP2175378A1 (de) * 2008-10-13 2010-04-14 Vodafone Holding GmbH Bereitstellung von auf einer Speicherkarte gespeicherten Daten für eine Benutzervorrichtung
US20120149339A1 (en) * 2010-12-10 2012-06-14 MobileIron, Inc. Archiving Text Messages
CN102164353B (zh) 2011-04-13 2013-08-28 青岛海信移动通信技术股份有限公司 一种解析mms信息的方法和设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000064110A1 (en) * 1999-04-19 2000-10-26 Nokia Networks Oy Method for delivering messages

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07175710A (ja) * 1993-12-20 1995-07-14 Canon Inc データ管理方法及び装置
CA2216533C (en) * 1995-12-19 2002-05-07 Motorola, Inc. Method and apparatus for rate governing communications
US5724412A (en) * 1996-10-07 1998-03-03 U S West, Inc. Method and system for displaying internet identification on customer premises equipment
US5850511A (en) * 1996-10-28 1998-12-15 Hewlett-Packard Company Computer implemented methods and apparatus for testing a telecommunications management network (TMN) agent
US5987100A (en) * 1997-04-23 1999-11-16 Northern Telecom Limited Universal mailbox
FI108982B (fi) 1998-06-15 2002-04-30 Nokia Corp Sanomapalvelu langattomassa tietoliikennejärjestelmässä
US20010012286A1 (en) * 1999-01-29 2001-08-09 Emmanuel L. Huna Method and apparatus for computer alert of device independent messages
US6647409B1 (en) * 1999-07-13 2003-11-11 Microsoft Corporation Maintaining a sliding view of server based data on a handheld personal computer
US6865609B1 (en) * 1999-08-17 2005-03-08 Sharewave, Inc. Multimedia extensions for wireless local area network
FI111314B (fi) 1999-11-05 2003-06-30 Nokia Corp Multimediasanomanvälityspalvelu
FI111780B (fi) * 1999-12-23 2003-09-15 Nokia Corp Sanomanvälityspalvelu
US7039678B1 (en) * 2000-09-07 2006-05-02 Axis Mobile, Ltd. E-mail proxy
US7031968B2 (en) * 2000-12-07 2006-04-18 Prev-U Israel Ltd. Method and apparatus for providing web site preview information

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000064110A1 (en) * 1999-04-19 2000-10-26 Nokia Networks Oy Method for delivering messages

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
KERVELLA B ET AL: "MHEGAM - A MULTIMEDIA MESSAGING SYSTEM", IEEE MULTIMEDIA,US,IEEE COMPUTER SOCIETY, vol. 4, no. 4, 1 October 1997 (1997-10-01), pages 22 - 29, XP000726939, ISSN: 1070-986X *
MOELLER E ET AL: "The BERKOM multimedia-mail teleservice", COMPUTER COMMUNICATIONS,NL,ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM, vol. 18, no. 2, 1 February 1995 (1995-02-01), pages 89 - 102, XP004032505, ISSN: 0140-3664 *
N. BORENSTEIN, N. FREED: "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", NETWORK WORKING GROUP, RFC 1521, XP002170350 *
N. BORENSTEIN; N. FREED: "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", NETWORK WORKING GROUP, RFC 1521

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1303090A2 (de) 2001-10-09 2003-04-16 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten
EP1303090B1 (de) * 2001-10-09 2016-03-09 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten
WO2003105425A1 (de) * 2002-06-07 2003-12-18 Siemens Aktiengesellschaft Übertragung vno mms-nachrichten mit konvertierung von datai-typen und/oder -formaten
US8731097B2 (en) 2002-06-07 2014-05-20 Siemens Aktiengesellschaft Transmission of mms messages with the conversion of data types and/or data formats
JP2006501705A (ja) * 2002-08-02 2006-01-12 シーメンス　アクチエンゲゼルシヤフト ユーザデータメッセージを伝送するための方法、加入者機器並びに無線通信システム
US7010790B2 (en) * 2002-11-20 2006-03-07 Cegetel Modular method and device for the tracing of a multimedia message through a telecommunications network
DE10325889A1 (de) * 2003-06-06 2004-12-23 Siemens Ag Verfahren zum Übertragen von Nachrichten
US8924578B2 (en) 2003-06-06 2014-12-30 Siemens Aktiengesellschaft Method for transmitting messages in an MMS-based communication system
EP1531639A2 (de) * 2003-11-12 2005-05-18 Vodafone Holding GmbH Verfahren zur Übertragung von Daten auf ein mobiles Endgerät in Mobilfunknetzen
EP1531639A3 (de) * 2003-11-12 2007-11-21 Vodafone Holding GmbH Verfahren zur Übertragung von Daten auf ein mobiles Endgerät in Mobilfunknetzen

Also Published As

Publication number Publication date
JP2009105931A (ja) 2009-05-14
US8099081B2 (en) 2012-01-17
US20040097248A1 (en) 2004-05-20
JP2004517587A (ja) 2004-06-10
JP5006864B2 (ja) 2012-08-22
JP4358511B2 (ja) 2009-11-04

Similar Documents

Publication Publication Date Title
WO2002058359A1 (de) Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz
AT411312B (de) Verfahren zum übermitteln von kurznachrichten (sms) zwischen rechnern im internet
DE69913953T2 (de) Verfahren und vorrichtung zur verarbeitung von elektronischen post
DE602004005319T2 (de) Nachrichtenverwaltung
EP1256241B1 (de) Verfahren zur übertragung von nachrichten in einem telekommunikationsnetzwerk
DE602005004721T2 (de) Verfahren zur Verwaltung von verdoppelten Nachrichtenmeldungen in multimedialen Benachrichtigungsdiensten
EP1632065B1 (de) Verfahren zum übertragen von nachrichten in einem auf mms basierten kommunikationssystem
EP1358742A2 (de) Verfahren zur nachrichtenversendung aus einem mms-system und einrichtung hierfür
EP1774805B1 (de) Verfahren zum übertragen applikationsspezifischer registrier-oder deregistrierdaten sowie system, server und kommunikationsendgerät hierfür
WO2003015429A1 (de) Verfahren zur übertragung von daten
EP1320984B1 (de) Kostenabrechnung bei datenübertragung in einem mobilfunknetz
EP1680903B1 (de) Verfahren zum bertragen von verschl sselten nutzdateno bjekten
DE102006001503A1 (de) Verfahren und System zum Übermitteln von Zusatzdaten und Kommunikationsendgerät
WO2002100063A1 (de) Verfahren zur handhabung einer nachricht mit multimedialem bezug
DE10117895A1 (de) Benachrichtigung im Multimedia Messaging Service (MMS)
DE10215567A1 (de) Verfahren zur Übertragung von Daten, insbesondere mit multimedialen Inhalten, in einem Mobilfunknetz
EP1352500B1 (de) Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz
WO2004086675A1 (de) Verfahren zur übertragung von nutzdaten inklusive kostenübernahme-informationen in einem kommunikationsnetz
EP1508228B1 (de) Verfahren und Vorrichtungen zur Nachrichtenübertragung
EP1520438A1 (de) Mms-nachrichten bertragungsverfahren und -system
EP2027685B1 (de) Verfahren zur steuerung und benutzerspezifischen anpassung eines multimedia messaging dienstes
EP1303090B1 (de) Verfahren zur Übertragung von Daten
EP1263178A2 (de) Verfahren und Vorrichtung zur Präsentation von Multimedianachrichten
EP1878181B1 (de) Verfahren und kommunikationseinrichtung zur handhabung eines mms-versionskonflikts
DE10150130A1 (de) Verfahren zur Übertragung von Daten

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN IN JP KR US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2001273297

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10466749

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2002558717

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2001273297

Country of ref document: EP