EP2247086A1 - Method, device and software program for expanding the information flow when transferring a message - Google Patents

Abstract

The method involves situating an originator network unit (1) and a recipient network unit (2) in a domain of service providers (3, 4) for transmission, where the originator network unit and the recipient network unit are identical or different than one another. A multimedia message is utilized to request a particular functionality in the domain of one of the service providers. The requested functionality supporting information is transmitted from one of the originator network and the recipient network unit to one of data interchange applications or units. Independent claims are also included for the following: (1) a network unit including a multimedia message transmitting part (2) a subscriber unit for communication in a network (3) a software program including a set of instruction to perform a method for transmitting a multimedia message.

Description

The invention relates to a method for information flow extension in the transmission of a message, in particular a multimedia message, via a mobile network, in particular UMTS network, corresponding devices and corresponding software programs.

In addition to voice telephony, the GSM (Global System for Mobile Communications) GSM system also offers the possibility of sending and receiving short text messages of up to 160 characters in length. This service is called SMS (SMS - Short Message Service). More details can be found in GSM 03.40 Version 7.4.0, Release 1998; Digital Cellular Telecommunications System; Technical realization of the Short Message Service (SMS).

For the next generation mobile radio system UMTS (Universal Mobile Telecommunications System UMTS), a multimedia-capable variant of a mobile news service is currently being standardized, the so-called MMS (Multimedia Messaging Service). 3GPP TS 22.140 Version 4.1.0, Release 4; Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Aspects; Stage 1; Multimedia Messaging Service (MMS), as well as 3GPP TS 23.140 Version 4.3.0, Release 4; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description; Stage 2.

Messages with multimedia content are referred to below for better delimitation of the text messages of the SMS just short MMs (MM - Multimedia Message, the end-s stands for the plural). In contrast to SMS, the restriction to pure text content is eliminated. With MMS, it will be possible to format texts according to individual tastes, as well as embed audio and video content in a message.

In Fig. 1 the state of the art MMS network architecture is shown from the perspective of 3GPP (Third Generation Partnership Project). An MMS user agent (abbreviated to UA, plural: UAs) is understood to mean an application, for example, on a mobile telephone or on a device connected to a mobile telephone (eg laptop, or the like) that implements MMS. The application from which a message is sent out is referred to below as a send application, in particular MMS Agent A (here abbreviated to UAA), the receiving application as a receive application, in particular MMS User Agent B (here abbreviated to UAB). According to the Fig. 1 A transmission application UAA 1 uses a radio network 7, using an air interface designated MM1, to specify an MM for the network unit 5 designated MMS relay / server A (here abbreviated to RSA, hereinafter MMS relay / server abbreviated RS, plural: RSs) which provides the MMS functionality to the UAs within the area of responsibility of an MMS service provider 3, the so-called MMSE (Multimedia Messaging Service Environment MMSE). The message is then forwarded to an MMS Relay / Server B (abbreviated RSB) network unit 6 in the area of responsibility of a receiving-side MMS service provider 4 (MMS Service Providers B) via an interface MM4, which in turn The message is transmitted to the receiving application UAB 2 via a radio network 8 using an interface MM1.

In the Fig. 1 the general case is shown that the transmitting-side network unit RSA 1 and the receiving-side network unit RSB 2 are not identical. However, the specific case of only one MMSE involved is also known in the art, as is the fact that the interface MM1 need not necessarily be designed as an air interface.

A feature of the MMS described in the above specification 3GPP TS 23.140 Version 4.3.0, Release 4 for the mentioned specific case of identity of transmitting and receiving RSs is the so-called reply charging, which is generally referred to as reply charging and according to which When sending an MM, the sender can express his willingness to accept the costs of a reply message, in particular a multimedia response (answer MM), from the recipient. In addition, a deadline can be specified by the sender. If an MM with the corresponding answer charge flag is available for download on the network element RS, the latter is first notified and can then download the MM to his terminal. Here he is informed both in the notification and when downloading the MM that a response message to this so-called original MM is free for him. If he wants to make use of it, he only has to mark and send an MM compiled on his terminal as an answer MM to the previously received original MM. The answer billing functionality has hitherto been defined only within a MMSE. A detailed description can be found in Appendix E of 3GPP TS 23.140 Version 4.3.0, Release 4.

All the information required for the transport of a MM, as well as the supplementary information for the answer-billing functionality, are used as information elements, so-called information elements, in the abstract messages defined in 3GPP TS 23.140 Version 4.3.0, Release 4, the so-called abstract messages. entered. If a device involved in the data exchange (application UA or network element RS) does not recognize an information element, this is passed on unchanged. This behavior can be problematic for the answer-billing functionality because the prior-art answer-billing functionality described above only works if all the devices involved in the data exchange (ie, both UAs and the RS) support the answer-billing functionality. For example, if only the sending application UAA and the receiving application UAB support the answer charging functionality and the participating network element RS is not (because it may support an outdated MMS version), a response MM can not be recognized by the network element RS and may not be rejected, ie the sender of the answer MM (= recipient of the original MM) is erroneously left to believe that the costs of the answer MM sent by him are taken over by the recipient (= sender of the original MM).

In the standardization bodies 3GPP and WAP Forum, neither a solution to the compatibility problem described above (network element RS does not support response charging functionality) nor to the extension of the response charging functionality to several MMSEs is known.

The described problem also exists for other similar cases in which a sender requests a particular functionality from a service provider without the sender and / or the receiver knowing whether the corresponding network units involved in the area of responsibility of one or more service providers will have the requested functionality support. For example, it is planned to introduce further new functions in the future, such as "callback of MMS" in the MMS, which are indeed supported by the transmitting and receiving units, but possibly not by participating network units.

Another problem in the prior art is that the sender of an original message with a reply billing notice can not protect himself from being sent an overly long and thus very expensive reply message back to him.

It is an object of the present invention to make the transmission of information when sending / receiving a message containing a request for a specific functionality of a participating network unit in the area of responsibility of a service provider more user-friendly.

This object is achieved with respect to the method by the features of independent claim 1. With regard to the devices, the object is solved by the features of independent claims 3 and 5. With regard to the software programs, the object is solved by the features of independent claims 7 and 8.

The compatibility problem occurring in the prior art is achieved according to the invention by creating the possibility in the case of mutually different transmitting and receiving network units, additional information from the transmitting side to the receiving side network unit, in particular the advice to the recipient on the possibility of answer billing, the answer billing identification number which preferably corresponds to the original message identification number and a deadline for Answering the original message and / or transmitting the maximum allowed size for the reply message.

Part of the invention, in addition to the method, the corresponding devices involved, ie the network units with the corresponding control units and the mobile subscriber devices, which are equipped with the appropriate receiving and / or transmitting applications. Here it is - as stated above - irrelevant whether these applications directly on a mobile phone or a laptop, notebook or similar. are installed. The term "mobile subscriber device" also encompasses these embodiments. In addition, the corresponding software programs are part of the invention.

Advantageous developments of the invention are specified in the subclaims.

• Fig. 1 die MMS Netzwerk-Architektur nach den Spezifikationen des 3GPP;
• Fig. 2 das Transaktionsflussdiagramm für den Fall des Versendens einer MM von einer Sendeapplikation (UAA) an eine Empfangsapplikation (UAB) unter Beteiligung nur eines Netzwerkelements RS;
• Fig. 3 das Transaktionsflussdiagramm für den Fall des Versendens einer MM von einer Sendeapplikation (UAA) an eine Empfangsapplikation (UAB) unter Beteiligung zweier Netzwerkelemente (RSs), und
• Fig. 4 das Transaktionsflussdiagramm im WAP für den Fall des Versendens einer MM von einer Sendeapplikation (CA) an eine Empfangsapplikation (CB) unter Beteiligung zweier Netzwerkelemente (PRs).

In the following the invention will be explained in more detail with reference to FIGS. Show it:

• Fig. 1 the MMS network architecture according to the 3GPP specifications;
• Fig. 2 the transaction flow diagram in the case of sending a MM from a send application (UAA) to a Receive application (UAB) involving only one network element RS;
• Fig. 3 the transaction flow diagram in the case of sending a MM from a sending application (UAA) to a receiving application (UAB) involving two network elements (RSs), and
• Fig. 4 the transaction flow diagram in WAP in the case of sending a MM from a sending application (CA) to a receiving application (CB) involving two network elements (PRs).

In the following, the specific functionality "reply charging" or "reply charging" describes how the compatibility problem mentioned above within an MMSE can be eliminated by exchanging additional information on the interface MM1 (case 1). Subsequently, an extension of the presented method to the general case is presented in which MMs are exchanged between two different MMSEs of different MMS service providers (case 2). Changes in addition to the interface MM1 and the interface MM4 affected. Finally, a possible implementation of the method described in general case 2 (exchange of MMs between two MMSEs) for the air interface interface MM1 in WAP (WAP - Wireless Application Protocol) is presented.

I. Case 1: Answer billing within a single MMSE

First, based on the Fig. 2 the case considered that both the sending application UAA 1 (MMS User Agent A) and the receiving application UAB 2 (MMS User Agent B), the MMS from the same MMS service provider to complete, ie the MM is transported only within a MMSE. Fig. 2 shows the corresponding so-called transaction flow diagram according to 3GPP, in which the Abstract messages defined in 3GPP TS 23.140 version 4.3.0, Release 4 are shown. User A creates an MM, marks it with "Reply-Charging" and sends it via the abstract message N1 ( MM1_submit.REQ ) via the interface MM1 to the network element RS in the MMSE of its MMS service provider. This RS is at the same time transmitting and receiving network element and is therefore marked with the two reference numerals 5 and 6 (see. Fig. 1 ). The network element RS 5, 6 confirms the correct reception of the MM from the transmission application UAA 1 with the abstract message N2 ( MM1_submit.RES ) and notifies the receiver B about the downloadable MM with the abstract message N3 ( MM1_notification.REQ ). The abstract message N4 ( MM1_notification.RES ) serves merely as confirmation for the correct receipt of the notification by the receiving application UAB 2. With the abstract message N5 ( MM1_retrieve.REQ ), user B can download a MM which is provided on the network element RS 5, 6 initiate. The delivery of the MM from the network element RS 5, 6 to the receiving application UAB 2 by means of the abstract message N6 ( MM1_retrieve.RES ). The confirmation for this is then carried out by means of the abstract message N7 (MM1_acknowledgement.REQ).

According to the invention the two abstract messages from a network element RS will be supplemented N3 (MM1_notification.REQ = notification of a MM) and / or N6 (MM1_retrieve.RES = delivery of the MM) by a further information element, if the network element RS the required Antwortvergebührung functionality supported. The new information element could, for example, be called "Reply Charging Support". It provides information about whether the network element RS (or more generally, the MMS service provider) supports the answer charging functionality. Tables 1 and 2 show the inventive additives, ie the new information element "Reply-Charging-Support" in the abstract messages N3 (MM1_notification.REQ) and N6 (MM1_retrieve.RES), in either case, preferably behind the known information element " Reply-Charging "is inserted. Table 1: Additional information element in the abstract message N3 (<i> MM1_notification.REQ </ i>) and N6 (<i> MM1_retrieve.RES </ i>) according to case 1. information element presence description "Reply-Charging-Support" optional Information that the MMS
Service provider supports the answering charge functionality.

A network element RS, which does not support the required Answervergebühr- functionality, preferably continues to pass through all information elements unknown to him unchanged, without supplementing the information element "Reply Charging Support". In this way, the receiving application UAB of the recipient can recognize whether the answer charging functionality in the MMSE of its MMS service provider is supported or not and react accordingly. In other words, only if the information element "Reply Charging Support" set by the network element RS is included in the abstract messages N3 ( MM1_notification.REQ ) and / or N6 ( MM1_retrieve.RES ) is present, the recipient of the original MM can be sure, when sending an appropriately marked answer MM, that the answer billing functionality is supported by the MMS service provider.

In order to increase the convenience of the answering charge functionality, the above-defined information element "Reply Charging Support" is preferably also inserted in the abstract message N2 ( MM1_submit.RES ), with which the correct receipt of an MM after sending from the network element RS is confirmed (see Fig. 2 ). In this way, the sending application UAA 1 can be informed after sending an original MM with answer billing identifier as well as the receiving application UAB 2 after sending an answer MM with appropriate labeling whether the MMS service provider supports the required answer billing functionality or Not. Table 2 shows the additional information element "Reply Charging Support" for the abstract message N2 ( MM1_submit.RES ), which is preferably inserted after the known information element "Message ID". Tab. 2: Additional information element in the abstract message N2 (<i> MM1_submit.RES </ i>) according to case 1. information element presence description "Reply-Charging-Support" optional Information that the MMS
Service provider supports the answering charge functionality.

II. Case 2: Answer billing between two different MMSEs

In the following, the case is considered that the sending application UAA and the receiving application UAB use the MMS of different MMS service providers, i. an answer-bill-ID MM is transported between two MMSEs. In this case, response charging only works properly if, in addition to the send and receive application, both the network element RSA of the sender and the network element RSB of the receiver support the response charging functionality. The compatibility problem with the response charging between different MMSEs is hereby made possible by transmitting additional information when transporting an MM, which provides information about whether the response accounting functionality is supported by the corresponding network element (RSA, RSB).

Fig. 3 shows a corresponding extension of the transaction flow chart of Fig. 2 , In addition to the abstract messages presented there, the abstract messages for the MM4 interface are also included here (see also Fig. 1 ).

1. 1. die Bereitschaft des Absenders, die Kosten für eine Antwort-MM vom Empfänger zu übernehmen (Informationselement "Reply-Charging"),
2. 2. eine Frist für das Abschicken einer kostenlosen Antwort-MM (Informationselement "Reply-Charging-Deadline"),
3. 3. die maximale Größe für eine Antwort-MM (Informationselement "Reply-Charging-Size"),
4. 4. die Information, dass bzw. ob der MMS Dienstanbieter des Absenders die geforderte Antwortvergebührung-Funktionalität unterstützt (Informationselement mit dem beispielhaften Namen "Reply-Charging-Support-At-Originator-MMSE"),
   oder (falls es sich bei der übertragenen MM um eine Antwort-MM handelt; in diesem Fall gilt die Antwort-MM als eine neue Original-MM):
5. 5. die Message-ID der (ursprünglichen) Original-MM (Informationselement "Reply-Charging-ID").

According to the Fig. 3 user A creates an MM, marks it with "Reply-Charging" and sends it over the interface MM1 to the network element RSA 5 in the MMSE of his MMS service provider A. If this supports the required answer charging functionality, according to the invention the network element RSA 5 derives in the Abstract message N8 ( MM4_forward.REQ ) - to the message N9 ( MM4_forward.RES ) in the Fig. 3 does not need to be discussed here - together with the MM following information to the network element RSB 6 in the MMSE of the receiver continue:

1. 1. the willingness of the sender to assume the costs for an answer MM from the recipient (information element "reply charging"),
2. 2. a deadline for sending a free reply MM (information element "Reply Charging Deadline"),
3. 3. the maximum size for an answer MM (information element "reply-charging-size"),
4. 4. the information that the MMS service provider of the sender supports the required answer charging functionality (information element with the exemplary name "Reply Charging Support At Originator MMSE"),
   or (if the transmitted MM is an answer MM, in which case the answer MM is considered a new original MM):
5. 5. the message ID of the (original) original MM (information element "Reply-Charging-ID").

Table 3 shows the invention additional information elements in the abstract message N8 (MM4_forward.REQ), the new information element "Reply-Charging-ID" preferably behind the known information element "Message ID" and the other four new pieces of information behind the known information element "Content be inserted. Table 3: Additional information elements in the abstract message N8 (<i> MM4_forward.REQ </ i>) according to case 2. information element presence description "Reply-Charging-ID" optional In the case of answer billing, this is the identification of the original MM that is being answered. "Reply-Charging" optional Information that the answer to this specific original MM is free of charge. "Reply-Charging-Deadline" optional In the case of the answering charge, the last time the task is given an answer granted to the recipient. "Reply-Charging-Size" optional In the case of answer billing, the maximum size of a response MM granted to the recipient. "Reply-Charging-Support-at-Originator-MMSE" optional Information that the answer charging functionality is supported by the transmitting network element (RS).

The information elements "Reply-Charging", "Reply-Charging-Deadline" and "Reply-Charging-ID" not listed in Table 3 do not need to be redefined at this point. As is well known, they are already used on the interface MM1 and, according to the invention, are transferred here to the new interface MM4. On the information element "Reply-Charging-Support-at-Originator-MMSE" is described in more detail below:

The assumption of the information element "Reply Charging Support" defined above in case 1 for the transmission of the information that the MMS service provider supports the required response charging functionality is no longer sufficient for the case described here, since the network element RSB 6 The information element "Reply Charging Support" set by the network element RSA 5 would continue to pass on to the receiving application UAB 2 unchanged when the MM is notified or delivered, if it does not support the response charging functionality. This behavior could be misinterpreted by the receiving application UAB 2. He needs the information that or whether both involved in the transmission of the MM network elements 5, 6 (RSA, RSB) support the required Answervergebühr functionality. For this reason, according to the invention, another information element is defined on interface MM4 between network element RSA 5 and network element RSB 6 than on interface MM1 between network element RSB 6 and receive application UAB 2. The two new pieces of information could include, for example, "Reply Charging Support at Originator MMSE" and "Reply Charging Support at Recipient MMSE" (Answer Billing Support on the part of the MMSE) receiving MMSE). They are shown in Tables 3, 5 and 6. In the abstract messages N3 (Tab. 5) and N6 (Tab. 6), the information element "Reply-Charging-Support-at-Recipient-MMSE" is preferably inserted after the information element "Reply-Charging".

If the network element RSB supports the response charging functionality, it must check before the notification of the recipient or before the delivery of the MM whether in the abstract message N8 ( MM4_forward.REQ ) the corresponding information element "Reply Charging Support at Originator -MMSE "is included. If this is the case, then the network element RSB must in turn have the corresponding information element "Reply-Charging-Support-at-Recipient-MMSE" in the abstract message N3 ( MM1_notification.REQ = notification about the downloadable MM) or in Insert the abstract message N6 ( MM1_retrieve.RES = delivery of the MM). Optionally, he can delete the information element "Reply-Charging-Support-at-Originator-MMSE" set by the network element RSA after checking, if and to the extent that he can recognize it, to relieve the precious air interface. The receiving application UAB of the recipient can easily recognize with this method by evaluating the existence or absence of the information element "Reply-Charging-Support-at-Recipient-MMSE" whether sending an answer MM to the original MM of both participating MMS service providers can be processed or not.

The information element "Reply-Charging-Size", which designates the permissible size of the Antort-MM, is also the subject of this invention disclosure. It is preferably supplemented in the abstract messages N1 ( MM1_submit.REQ ), N8 ( MM4_forward.REQ ), N3 ( MM1_notification.REQ ), and N6 ( MM1_retrieve.RES ) to increase the convenience of the answer charging functionality. With this new information element, the sender of an original MM has the option of specifying not only the time limit for the response MM but also its maximum size. Alternatively or in addition, it could also be of one the MMS service providers involved in the transmission of the MM are used to limit the size of a response MM. In Tables 3 to 6, the newly defined information element "Reply-Charging-Size" is shown in the corresponding abstract messages, this information element is preferably inserted in the abstract messages N1, N3 and N6 respectively behind the known information element "Reply-deadline" , Table 4: Additional information element in the abstract message N1 (<i> MM1_submit.REQ </ i>). information element presence description "Reply-Charging-Size" optional In the case of answer billing, the maximum size of a response MM granted to the recipient. information element presence description "Reply-Charging-Support-At-Recipient-MMSE" optional Information that the answer-billing functionality is supported by the receiving-side network element. ... ... ... "Reply-Charging-Size" optional In the case of Answervergebührung
the maximum size of a response MM granted to the recipient. information element presence description "Reply-Charging-Support-At-Recipient-MMSE" optional Information that the answer-billing functionality is supported by the receiving-side network element. ... ... ... "Reply-Charging-Size" optional In the case of answer billing, the maximum size of a response MM granted to the recipient.

Analogously to the procedure described in Case 1, the information element "Reply-Charging-Support-At-Originator-MMSE" introduced here is advantageously also included in the abstract message N2 ( MM1_submit.RES ), with which the correct reception of an MM from a network element RS is confirmed, inserted. This remarkably enhances the convenience of the answering charge function, because in this way, both the sending application UAA after sending an original MM with the answer-billing identifier and the receiving application UAB after sending a correspondingly-marked answer MM (in this case, the Receive application UAB the "originator" of the response MM) to be informed whether the respective MMS service provider supports the required Answervergebühr functionality or Not. Table 7 shows the additional information element "Reply-Charging-Support-At-Originator-MMSE" in the abstract message N2 (MM1_submit.RES), which is preferably inserted after the information element "Message ID". Table 7: Additional information element in the abstract message N2 (<i> MM1_submit.RES </ i>) according to case 2. information element presence description "Reply-Charging-Support-At-Originator-MMSE" optional Information that the answer-billing functionality is supported by the network element RS when an original MM or a response MM has been abandoned.

III. Implementation of the invention in WAP

According to the prior art, an implementation of MMS is only possible via WAP (WAP - Wireless Application Protocol). To bridge the air interface (in 3GPP: MM1) between an MMS-enabled device and the WAP gateway, 3GPP TS 22.140 Version 4.1.0, Release 4 (see above) and WAP-209.102-MMSEncapsulation, 8-February-2001 (Wireless Application Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Draft SCD) provides for the use of the WAP WSP Transfer Protocols. Therefore, in the following section, we will describe how the redefined 3GPP abstract message information elements above can be applied to the WAP messages of the WAP implementation. In this case, by way of example, the embodiment according to Case 2 (answer billing between two MMSEs) because it reflects the more general case and should be given greater opportunities for implementation in 3GPP and WAP; After all, with it the restriction to only one MMSE is eliminated.

Fig. 4 shows a so-called transaction flow diagram in WAP according to the current state of the art according to WAP-209.102-MMSEncapsulation (see above), in which the exchange of WAP messages between the four participating entities transmission application 1a (MMS Client A, abbreviated CA), transmitting network element 5a (MMS Proxy -Relay A, abbreviated PRA), receiving-side network element 6a (MMS Proxy Relay B, abbreviated PRB) and receiving application 2a (MMS Client B, abbreviated CB) in the transmission of an MM is shown. Affected by this invention disclosure WAP message N1a (M-Send.req), N2a (M-Send.conf) N3a (M-Notification.ind) and N6A (M-Retrieve.conf) are highlighted in bold. In this case, the WAP message N1a corresponds to the above-mentioned message N1, the WAP message N2a to the above-mentioned message N2, etc. In addition, the known message N10a ( M-Delivery.ind ) is shown. It should be noted here that the terms defined in 3GPP MMS User Agent, MMS Relay / Server and MMSE do not exist in WAP. Therefore, only the terms MMS Client and MMS Proxy Relay or their abbreviations are used in this section, but they mean the same instances. There is no analogous expression in WAP for the 3GPP term MMSE.

According to WAP-209.102-MMSEncapsulation (see above), a header field in a WAP message consists of a field name followed by a field value consisting of at least one octet (8-bit word). The assignment of hexadecimal values to the field names is listed in Table 8. Currently there are 24 field names. The field names newly defined in this invention disclosure therefore preferably start at number 25 (hexadecimal: 0x19). They are shown in Table 9. Tab. 8: Assignment of field names (according to the state of the art). Surname Assigned number Bcc 0x01 cc 0x02 Content-Location 0x03 Content-Type (content type) 0x04 Date (date) 0x05 Delivery report (delivery report) 0x06 Delivery-Time 0x07 Expiry 0x08 From 0x09 Message-Class (message class) 0x0A Message ID (message identification number) 0x0B Message type (message type) 0x0C MMS version 0x0D Message size (message size) 0x0E Priority 0x0F Read-Reply 0x10 Report-Allowed 0x11 Response status (response status) 0x12 Response text (answer text) 0x13 Sender Visibility 0x14 status 0x15 Subject 0x16 To 0x17 Transaction Id 0x18 (Transmission number) Surname Assigned number Reply-Charging-Support-At-Originator-MMS proxy relay
(Antwortvergebührung support-In-origin MMS proxy relay) 0x19 Reply-Charging-Support-At-Recipient MMS proxy relay
(Antwortvergebührung support-In-receive MMS proxy relay) 0x1A Reply-Charging-Size
(Antwortvergebührung size) 0x1B

Since, according to WAP-209.102-MMSEncapsulation (see above), a header field in a WAP message always consists of a field name and a field value, at least one field value must be defined for each of the newly defined header fields. This is explained in more detail below:

There are a total of four ways to encode the field value of a header field, with the first octet deciding the type and length of the encoding (see Table 10). Tab. 10: The four possibilities for coding the field value (state of the art). First octet of the field value Possible combinations Number of subsequent octets 0 ... 30 31 0 ... 30 31 1 > 30 32 ... 127 (text) 96 > 0 128 ... 255 128 0

In order to minimize the amount of data to be transmitted on the air interface, the field values for the two newly defined header fields "Reply-Charging-Support-At-Originator-MMS-Proxy-Relay" and "Reply-Charging-Support- At-Recipient MMS Proxy Relay "prefers exclusively from the fourth value range (128 to 255). A possible definition of the new header fields "Reply-Charging-Support-At-Originator-MMS-Proxy-Relay" and "Reply-Charging-Support-At-Recipient-MMS-Proxy-Relay" could look like this: Field name : Reply-Charging-Support-At- Originator MMS Proxy Relay (Antwortvergebührung support-Beim- Origin MMS proxy relay) Field values : Reply-Charging-Support-At-Originator-MMS-Proxy Relay-value = Yes | No (Antwortvergebührung support-Beim- Source MMS Proxy Relay Value = Yes | No) Yes = <Octet 128> (Yes = <Octet 128>) No = <Octet 129> (No = <Octet 129>) Field name : Reply-Charging-Support-At- Recipient MMS proxy relay (Antwortvergebührung support-Beim- Receive MMS proxy relay) Field values : Reply-Charging-Support-At-Recipient-MMS-Proxy Relay-value = Yes | No (Antwortvergebührung support-Beim- Receive MMS Proxy Relay Value = Yes | No) Yes = <Octet 128> (Yes = <Octet 128>) No = <Octet 129> (No = <Octet 129>)

• Feld-Name: Reply-Charging-Size (Antwortvergebührung-Größe)
• Feld-Werte: Reply-Charging-Size-value = 200 | 400 | 600 | 800
  (Antwortvergebührung-Größe-Wert = 200 | 400 | 600 | 800)

$$200=<\mathrm{Octet}128>\left(200=<\mathrm{Oktett}128>\right)$$

$$400=<\mathrm{Octet}129>\left(400=<\mathrm{Oktett}129>\right)$$

$$600=<\mathrm{Octet}130>\left(600=<\mathrm{Oktett}130>\right)$$

$$800=<\mathrm{Octet}131>\left(800=<\mathrm{Oktett}131>\right)$$

The field value for the newly defined header field "Reply-Charging-Size" could either be incremental (Answer-MM may be up to X, Y or Z kilo-byte in size) or concrete (Answer-MM may only be X kilo Bytes become large). A possible definition of the new header field "Reply-Charging-Size" with a gradation of the possible size of a response message might look like this (value range 4):

• Field Name : Reply-Charging-Size
• Field values : Reply-Charging-Size-value = 200 | 400 | 600 | 800
  (Answer Billing Size Value = 200 | 400 | 600 | 800)

$$200=<\mathrm{Octet}128>\left(200=<\mathrm{octet}128>\right)$$

$$400=<\mathrm{Octet}129>\left(400=<\mathrm{octet}129>\right)$$

$$600=<\mathrm{Octet}130>\left(600=<\mathrm{octet}130>\right)$$

$$800=<\mathrm{Octet}131>\left(800=<\mathrm{octet}131>\right)$$

• Feld-Name: Reply-Charging-Size (Antwortvergebührung-Größe)
• Feld-Wert: Reply-Charging-Size-value = Long-integer
  (Antwortvergebührung-Größe-Wert)

A possible definition of the new header field "Reply-Charging-Size" with a concrete indication of the possible size of a response message might look like this (value range 1):

• Field Name : Reply-Charging-Size
• Field value: Reply-Charging-Size-value = Long-integer
  (Antwortvergebührung size value)

On further coding options will not be discussed here. It is obvious that different coding possibilities exist within the scope of this invention.

The supplements according to the invention in the WAP messages N1a ( M-Send.req ), N2a ( M-Send.conf ), N3a ( M-Notification.ind ) and N6a (M-Retrieve.conf) are shown in Tables 11 to 14 , The other header fields necessary for the realization of the response charging functionality within an MMSE are not shown there because the exact implementation of the information elements defined in 3GPP in the WAP forum is currently not yet completed. In the WAP message N1a (M- Send.req) , the header field "Reply-Charging-Size" - preferably inserted after the header field "Content-Type" - has been added, with which the application CA 1a, which generates the response fee -Functionality, when sending the MM in addition to specifying a deadline and the size of the response MM can restrict. Table 11: Newly defined header field in the WAP message N1a (<i> M-Send.req </ i>). Surname content comment "X-Mms-Reply-Charging-Size" Antwortvergebührung-size value Optional.
Specifies the size of a
Reply-MM.

In the WAP message N2a (M-Send.conf) the header field "Reply-Charging-Support-At-Originator-MMS-Proxy-Relay" - preferably inserted after the header field "Message-ID" - has been added, with the sending application CA 1a, who has sent a MM, can be informed whether the corresponding network element PRA 5a the willingness of the sender to take over the costs for a response MM or a response MM to a previously received and correspondingly marked original MM understood / accepted. Tab. 12: Newly defined header field in the WAP message N2 (<i> M-Send.conf </ i>). Surname content comment "X-Mms-Reply-Charging-Support-At-Originator-MMS proxy relay" Antwortvergebührung support-In-origin MMS Proxy Relay value Optional.
Note whether the answer billing on the sending side is supported.

The WAP messages N3a (M-Notification.ind) and N6a (M-Retrieve.conf) contain (in addition to any information that the sender's network element PR 5a supports the answer-billing functionality) the header set by the recipient's network element PR 6a Field "Reply-Charging-Support-At-Recipient-MMS-Proxy-Relay". For the receiving application CB 2a of the recipient, however, only the existence or absence of the header field "Reply Charging Support At Recipient MMS Proxy Relay" is of importance. This is preferably set only if both the transmission-side network element PRA 5a and the reception-side network element PRB 6a support the response charging functionality. If it exists, then the receiving application CB 2a can be certain that a response MM is understood to be a previously received original MM from both participating MMS service providers. The header field "X-Mms-Reply-Charging-Support-At-Recipient-MMS-Proxy-Relay" is preferably behind the known header field "M-Mms-Content-Location" and in the WAP message in the WAP message N3a N6a preferably inserted behind the known header field "Content Type". The header field "X-Mms-Reply-Charging-Size" is preferably behind the known header "X-Mms-Expiry" in the WAP message N3a and preferably behind the known header "X-Mms-Read" in the WAP message N6a -Reply "inserted. Table 13: Newly defined header field in the WAP message N3a (<i> M-Notification.ind </ i>). Surname content comment "X-Mms-Reply-Charging-Size" Antwortvergebührung-size value Optional. Specifies the size of a response MM. ... ... ... "X-Mms-Reply-Charging-Support-At-Recipient MMS proxy relay" Antwortvergebührung support-In-receive MMS proxy relay value Optional. Note whether the answer billing is supported on the receiving side. Surname content comment "X-Mms-Reply-Charging-Size" Antwortvergebührung-size value Optional. Specifies the size of a response MM. ... ... ... "X-Mms-Reply-Charging-Support-At-Recipient MMS proxy relay" Antwortvergebührung support-In-receive MMS proxy relay value Optional. Note whether the answer billing is supported on the receiving side.

The invention according to its first aspect has been explained in detail on the basis of the response charging functionality, but can also be used for other functionalities requested by mobile radio subscribers.

Furthermore, the invention can be used not only for multimedia messages, but also, for example, when sending or receiving SMS messages.

LIST OF REFERENCE NUMBERS

1

Send application (MMS User Agent A = UAA)

1a

Send application (MMS Client A = CA)

2

Receive application (MMS User Agent B = UAB)

2a

Receive application (MMS Client B = CB)

3

MMS Service Provider (MMS Service Provider A)

4

MMS service provider (MMS service provider B)

5

send-side network unit (MMS Relay Server A = RSA)

5a

transmitting-side network unit (MMS Proxy-Relay A = RPA)

6

Receive-side network unit (MMS Relay Server B = RSB)

6a

Receiving Network Unit (MMS Proxy Relay B = PRB)

7

Wireless Network

8th

Wireless Network

MM1

interface

MM4

interface

N1

Message MM1_submit.REQ

N1a

WAP message M-Send.req

N2

Message MM1_submit.RES

N2a

WAP message M-Send.conf

N3

Message MM1_notification.REQ

N3a

WAP message M-Notification.ind

N4

Message MM1_notification.RES

N4a

WAP message M-NotifyResp.req

N5

Message MM1_retrieve.REQ

N5A

WAP message WSP GET

N6

Message M_retrieve.RES

N6A

WAP message M-Retrieve.conf

N7

Message MMI_acknowledgement.REQ

n7a

WAP message M-Acknowledge.ind

N8

Message MM4_forward.REQ

N9

Message MM4_forward.RES

n10a

WAP message M-Delivery.ind

Claims (8)

Method for the reply-charging functionality in the transmission of a message, in particular a multimedia message, via a communication network from a transmission application (MMS User Agent A, MMS Client A) via a transmission-side network unit (MMS Relay / Server A, MMS Proxy Relay A) and one of these different receiver-side network unit (MMS Relay / Server B, MMS proxy relay B) to a receiving application (MMS User Agent B, MMS Client B), wherein the transmitting and the receiving side network unit in the area of responsibility of two service providers (MMS Service provider), wherein the message comprises information regarding the willingness of the sender to assume the costs for the reply message from the recipient (reply charging), characterized in that
in that at least one of the following information is transmitted from or received by the sending-side network entity to the receive-side network entity: • the willingness of the sender to pay the costs for the reply message from the recipient ("Reply-Charging" information element); • a deadline for sending the free reply message (information element "Reply Charging Deadline"); The maximum size of the reply message (information element "Reply-Charging-Size"); The message identification number (message ID) of the original message (information element "Reply-Charging-ID") during the transmission of the response message. Method according to claim 1,
characterized,
that at mutually different send and receive side Network unit at least one of said information in the message MM4_forward.REQ is transmitted or received. Network unit (MMS relay / server, MMS proxy relay) in the area of responsibility of a service provider (MMS service provider), a transmission application (MMS User Agent A, MMS Client A) and / or a receiving application (MMS User Agent B, MMS Client B) is assigned, in particular network unit of a UMTS network, in particular for performing method steps according to one of the preceding claims, wherein via the network unit messages, in particular multimedia messages, from a send application to a receiving application can be transmitted, with the message a Reply Charging Functionality is requested in the area of responsibility of a service provider,
characterized,
in that the network unit is designed in such a way that it can transmit with the message information regarding its support of the requested reply charging functionality to the receiving application (MMS User Agent B, MMS Client B) or receive it from the latter. Network unit (MMS relay / server, MMS proxy relay) according to claim 3, in the area of responsibility of a service provider (MMS service provider), wherein the network unit of a transmitting application (MMS User Agent A, MMS Client A) and / or a receiving application (MMS User Agent B, MMS client B), in particular network unit of a UMTS network, in particular for performing method steps according to claim 1 or 2, wherein via the network unit messages, in particular multimedia messages, from a send application to a receiving application can be transmitted, a message includes information regarding the willingness of the sender to accept the costs of the reply message from the recipient (reply charging),
characterized,
that the network unit is designed such that they transmit or receive and evaluate at least one of the following information may be: Transmission to the receiving application: the readiness of the sender to accept the costs for a reply message from the recipient (information element "reply charging") in the event of a difference between the sending and receiving network units; Transmission by the transmission-side network unit or reception by the reception-side network unit in the case of dissimilarity of the transmitting and receiving network unit: a deadline for sending a free reply message (information element "reply charging deadline"); • Transmission to or reception by another device involved in the data exchange (MMS Client B, MMS Client B, MMS Relay Server A, MMS Proxy Relay A, MMS Relay Server B, MMS Proxy Relay B): the maximum size for one Response message (information element "Reply-Charging-Size"); Transmission to or reception by the network entity receiving the response message: the message identification number (message ID) of the original message (information element "Reply Charging ID") when the response message is transmitted. Subscriber device for communication in a communication network, in particular for carrying out method steps according to claim 1 or 2, with at least one receiving application (MMS user agent A, MMS client A, MMS user agent B, MMS client B) for receiving messages, in particular multimedia messages, from a network unit (MMS relay / server, MMS proxy relay) in the area of responsibility of a service provider (MMS service Provider), in particular a network unit according to claim 3 or 4, wherein the message contains a request for a reply-charging functionality in the area of responsibility of a service provider,
characterized,
in that the device is designed such that it can receive and evaluate information inserted in the message with regard to the support of the requested reply-charging functionality by the involved network unit. Subscriber device, in particular according to Claim 5, for communication in a communication network, in particular for carrying out method steps according to Claim 1 or 2, with a transmitting and / or receiving application (MMS User Agent A, MMS Client A, MMS User Agent B, MMS Client B ) for sending and / or receiving messages, in particular multimedia messages, from a network unit (MMS relay / server, MMS proxy relay) in the area of responsibility of a service provider (MMS service provider), in particular a network unit according to claim 3 or 4, wherein the Messages may include information regarding the willingness of the sender to pay for the reply message from the recipient (Reply-Charging),
characterized,
in that the device is designed such that it can transmit or receive at least one of the following information: Receiving and evaluating information regarding the willingness of the sender to assume the costs for a reply message from the receiver (information element "reply charging") in the event of a difference between the sending and receiving network units; • Transmission and / or reception of information on the maximum size of the response message ("Reply-Charging-Size" information element); Receiving and evaluating information with regard to the support of the reply-charging functionality by the transmission unit (information element "Reply-Charging-Support-At-Originator-MMSE") relating to the original message or the response message; • Receipt and evaluation of information regarding the support of the reply-charging functionality by the original message receiving side network unit (information element "Reply-Charging-Support-At-Recipient-MMSE"). Software program which can run on a device with a processor, in particular a network unit according to claim 3, such that the software program together with the device performs the method steps on the side of the device according to claim 1 or 2. Software program which can be loaded into a device having a processor, in particular a network unit according to claim 3, so that the device thus programmed, including the processor, is capable or adapted to carry out the method steps according to claim 1 or 2.

Images