专利名称：在传输消息时扩充信息流的方法、装置和软件程序的制作方法
技术领域：
本发明涉及在经由移动无线网络、尤其是经由一个UMTS网络传输尤其是多媒体消息的消息时扩充信息流的方法，和相应的装置和软件程序。
背景技术：
除了语音电话，移动无线系统GSM(GSM-全球移动通信系统)还提供发送和接收160字长以内的文本短消息的可能性。该业务叫做SMS(SMS-短消息业务)。在GSM 03.40版本7.4.0、1998年版；数字蜂窝电信系统；短消息业务(SMS)的技术实现中可以找到更准确详细的资料。
对于下一代UMTS(UMTS-通用移动电信系统)移动无线系统，现在正在标准化另一种移动消息业务，其具有多媒体功能性，叫做MMS(MMS-多媒体消息业务)，参见3GPP TS 22.140版本4.3.0第4版；第三代合伙项目；集群业务和系统方面的技术规范；业务方面；第1阶段；多媒体消息业务(MMS)，也可参见3GPP TS 23.140版本4.3.0第4版；第三代合伙项目；群终端的技术说明；多媒体消息业务(MMS)；功能性描述；第2阶段。
具有多媒体内容的消息在下文被仅仅称为短MMs(MM-多媒体消息，词尾s表示复数)，为的是与SMS的文本消息更好地区分开。与SMS相比，这里不再有纯文本内容的限制。MMS将允许根据个人品位定制文本，允许将音频和视频内容嵌入消息中。
图1示出了从3GPP(第3代合伙项目)角度看的在现有技术基础上MMS的网络体系结构。MMS用户代理(缩写UA)可被理解为例如位于移动无线电话上、或位于与移动无线电话相连的且实现MMS的设备上(譬如膝上型电脑，或类似的)的应用。发送消息的应用在下文被称作发送应用，它在特定的MMS代理A中(在此缩写为UAA)，而进行接收的应用被称作接收应用，它在特定的MMS用户代理B中(在此缩写为UAB)。如图1所示，发送应用UAA1采用空中接口-记为MM1-通过无线网络7发送一个MM到网元5，该网元5被记为MMS中继/服务器A(在此缩写为RSA；以下MMS中继/服务器缩写为RS)，其在MMS业务提供商3(MMS业务提供商)的职责范围内、也即所谓的“MMSE”(MMSE-多媒体消息业务环境)内为UAs提供MMS功能性。然后利用MM4接口把消息传送给被记为MMS中继/服务器B(缩写为RSB)的网元6，该网元6位于接收侧MMS业务提供商4(MMS业务提供商B)的职责范围内，业务提供商4再利用MM1接口通过无线网络8向接收应用UAB2发送消息。
图1示出了发射侧网元RSA1和接收侧网元RSB2是不同的的一般情况。然而现有技术中已经知道只包括一个MMSE的特殊情况，同样，实际上并不需要MM1接口一定是空中接口的形式。
在上述发射侧和接收侧RSs相同的特殊情况下，在以上3GPP TS23.140版本4.3.0、第4版中所描述的MMS的一个特征是所谓的“应答-计费”，在此基础上，始发方发送一条MM来表示它准备接受来自接收方的应答-消息的费用，尤其是多媒体应答(应答-MM)。在此，始发方此外还可以规定时限。如果带有相应的应答计费-标识的MM提供在网元RS上给接收方下载，则首先通知接收方，然后下载这条MM到它的终端。此时，在通知中和在下载MM时都告诉所述的接收方其可以免费地对该所谓的“始发-MM”发送一条应答-消息。如果他想利用这一点，则只需要将一条在他的终端上编译的MM标识为前一个接收的始发MM的应答-MM，并将其发送出去。迄今只在MMSE中定义了应答计费-功能性。具体的描述可以在3GPP TS23.140版本4.3.0，第4版附录E中找到。
为发送MM而需要的所有信息同样象应答计费-功能性的补充信息一样被作为信息元素而录入到在3GPP TS 23.140版本4.3.0、第4版所定义的抽象消息中。如果参与数据交换的设备(应用UA或网元RS)不识别信息元素，则该信息元素将被不变地进行传送。这种特性对于应答计费-功能性可能是有问题的，因为上述的应答计费-功能性只有在参与数据交换的所有设备(即UAs和RS)都支持应答计费-功能性时才基于现有技术进行工作。譬如，如果只有发送应用UAA和接收应用UAB都支持应答计费-功能性，而所参与的网元RS不支持(可能是因为它支持一个老的MMS版本)，那么网元RS将不能识别应答-MM，甚至也不能拒绝它，也就是说，应答-MM的始发方(＝始发-MM的接收方)仍错误地认为他所发送的应答-MM的费用将被接收方(＝始发-MM的始发方)接受。
在标准化委员会3GPP和WAP的论坛中，既没有公开一种方法来解决以上所述的兼容问题(网元RS不支持应答计费-功能性)，也没有公开一种解决方法来把应答计费-功能性扩大到多个MMSE。
对于其它相似的情况也存在上述问题，其中，始发方请求业务提供商提供特殊的功能性，而发送方和/或接收方不知道在一个或多个业务提供商的职责范围内所相应参与的网元是否支持所请求的功能性。例如考虑今后在MMS中引入其它新的功能性-如“MMS的回叫”-，这些功能性虽然得到发送和接收单元的支持，但可能不受所参与的网元的支持。
现有技术的另一个问题在于，含有应答-计费-指示的始发-消息的始发方不能防止接收方给他发送回过长的、因而非常昂贵的应答-消息。
发明内容
本发明的目的在于，当发送/接收一条消息而该消息包含有在业务提供商职责范围中所参与的网元的特定功能性的请求时，使信息传输对用户更友好。
就方法而言，该目的是这样实现的，即本发明的第一个方面通过独立权利要求1的特征，本发明的第二个方面通过独立权利要求11的特征，以及本发明的第三个方面通过独立权利要求13的特征来实现。就装置而言，该目的是通过权利要求17到20的特征来实现的。就软件程序而言，该目的是通过权利要求21和22的特征来实现的。
本发明以如下方式解决了在现有技术所产生的兼容问题，即根据本发明的第一个方面，在参与数据交换的设备之间传输所述的信息，以支持所请求的、发射侧和/或接收侧网元的应答计费-功能性。在此处的第一种情况下，发射侧和接收侧网元、即尤其是MMS业务提供商的职责范围内的相关网元RS是相同的。根据本发明，尤其把涉及相关网元的应答的信息传送到接收应用。同样，给发送应用的确认也是本发明的一部分。在发送和/或接收应用的那一方接收该信息同样也是本发明的组成部分。
基于第一方面，本发明还允许对所请求的功能性进行扩充，也即譬如应答计费-功能性或在始发方请求回叫时的消息回叫-功能性，也利用需要不同MMS业务提供商的MMS(即在两个MMSE之间)的发送应用和接收应用。通过传送附加的数据-即关于网元RS支持或是否支持所请求的功能性的信息-，当在两条子链路上从发射侧网元RS(始发方的MMS中继/服务器)向接收侧网元RS(接收方的MMS中继/服务器)、或从接收侧网元RS向接收应用UAB传送MM时，也允许在不同的MMSE之间所请求的功能性，并解决了上述的兼容问题。
因此，通过传送如下信息，即网元RS是否支持所请求的功能性以作为对子链路上从网元RS向接收应用UAB发送MM的直接反应，便可以显著地提高有关功能性的灵活性。
基于第二方面，本发明提供了这样的可能性，即当发射侧和接收侧网元不同时，从发射侧网元可以向接收侧网元传送附加的信息，尤其是给接收方指示出可以进行应答计费的指示、应答计费的标识码-其优选地对应于始发-消息的标识码-、用于应答始发-消息的时限和/或应答-消息的最大允许长度。
基于本发明的第三方面，通常规定始发方可以在应答计费时给出应答-消息大小的最大限制。例如利用多个上限可以做到这一点，由始发消息的始发方从中选择一个。作为选择方案，始发方可以确定其自己选定的、应答-消息的最大长度。这样，始发方就保证了应答-消息将不会产生超过始发方自己选定的费用。
除了这些方法外，本发明还涉及一些相应参与的装置，即带有相应控制单元的网元，还涉及一些采用相应接收和/或发送应用的移动无线用户设备。在此，这些应用-如上已述-是直接安装在移动无线电话上，还是安装在膝上型电脑、笔记本或同类设备上，这并不重要。概念“移动无线用户设备”也覆盖了这些实施方案。此外，相应的软件程序也是本发明的一部分。
下面参照附图进一步解释本发明，其中图1示出了依照3GPP规范的MMS网络体系结构；图2示出了只利用一个网元RS从发送应用(UAA)向接收应用(UAB)发送MM的情况下的事务流程图；图3示出了利用两个网元(RSs)从发送应用(UAA)向接收应用(UAB)发送MM的情况下的事务流程图，和图4示出了在WAP中利用两个网元(PRs)从发送应用(CA)向接收应用(CB)发送MM的情况下的事务流程图。
具体实施例方式
下面将借助特定的功能性“应答-计费”来以例子讲述，如何在MMSE内利用MM1接口上的附加信息交换来解决上面提到的兼容问题(情形1)。接下来介绍了覆盖一般情况的本方法的扩展，其中在不同的MMS业务提供商的两个不同MMSEs之间交换MMs(情形2)。在此，变化不仅涉及到MM1接口而且还涉及MM4接口。最后，针对被实施为空中接口的WAP(WAP-无线应用协议)接口MM1而讲述了在一般情形2(在两个MMSE间的MMs交换)中所述的方法的一种可能实现。
I.情形1单个MMSE中的应答计费首先，借助图2考虑这样的情况，即发送应用UAA1(MMS用户代理A)和接收应用UAB2(MMS用户代理B)都使用同一个MMS业务提供商的MMS，即MM仅在一个MMSE内传送。图2示出相关的符合3GPP的“事务流程图”，其中给出了在3GPP TS 23.140版本4.3.0、第4版中定义的抽象消息。由A用户建立MM，标识其为“应答-计费”，并利用抽象消息N1(MM1提交.REQ)通过MM1接口将其发送到他的MMS业务提供商的MMSE中的网元RS。该RS是一个发射侧网元，同时也是接收侧网元，因此被标识为两个不同的参考符号5和6(参看图1)。网元RS5，6利用抽象消息N2(MM1_提交.RES)确认正确接收来自发送应用UAA1的MM，并利用抽象消息N3(MM1_通知.REQ)把准备下载的MM通知给接收方B。抽象消息N4(MM1_通知.RES)只是被用作接收应用UAB2正确接收到该通知的确认。抽象消息N5(MM1_检索.REQ)可以被用户B用来启动下载一条在网元RS5，6上提供的MM。网元RS5，6利用抽象消息N6(MM1_检索.RES)发送MM到接收应用UAB 2。然后利用抽象消息N7(MM1_确认.REQ)进行确认。
根据本发明，如果网元RS支持所请求的应答计费-功能性，则网元RS增加另一个信息元素到两个抽象消息N3(MM1_通知.REQ＝通知MM)和/或N6(MM1_检索.RES＝发送MM)中。例如新的信息元素可以称为“应答-计费-支持”。它指示了网元RS(或更一般地MMS业务提供商)是否支持应答计费-功能性。表1和2示出了发明的补充项，即在抽象消息N3(MM1_通知.REQ)和N6(MM1_检索.RES)中的新信息元素“应答-计费-支持”，它在两种情况下被优选地插入到已知的信息元素“应答-计费”之后。
表1按照情形1在抽象消息N3(MM1_通知.REQ)和N6(MM1_检索.RES)中增加的信息元素。
不支持所请求的应答计费-功能性的网元RS优选继续不变地传送其未知的所有信息元素，而不补充信息元素“应答-计费-支持”。这样，接收方的接收应用UAB便能识别在它的MMS业务提供商的MMSE中是否支持应答计费-功能性，并相应地作出反应。也就是说，只有当抽象消息N3(MM1_通知.REQ)和/或N6(MM1_检索.RES)中存在所述由网元RS设定的信息元素“应答-计费-支持”时，始发-MM的接收方才能在发送被适当标识的应答-MM时确信MMS业务提供商支持应答计费-功能性。
为提高应答计费-功能性的灵活性，以上重新定义的信息元素“应答-计费-支持”优选地也被插入到抽象消息N2(MM1_提交.RES)中，以用于在网元RS发送MM后来确认正确地接收到它(参见图2)。这样，在发送包含应答计费-标识符的始发-MM之后，可以通知发送应用UAA1关于MMS业务提供商是否支持请求的应答计费-功能性，正如在发送带有相应标识的应答-MM之后的接收应用UAB2一样。表2示出了抽象消息N2(MM1_提交.RES)中增加的信息元素“应答-计费-支持”，该信息元素被优选地插入到已知的信息元素“消息ID”之后。
表2按照情形1在抽象消息N2(MM1_提交.RES)中增加的信息元素。
II.情形2两个不同MMSE之间的应答计费以下来考虑这种情况，即发送应用UAA和接收应用UAB使用不同的MMS业务提供商的MMS，也就是说在两个MMSE间传送一条包含应答计费-标识符的MM。在这种情况下，只有除发送和接收应用以外发送方的网元RSA和接收方的网元RSB也都支持应答计费-功能性，那么应答计费才正常工作。在此，本发明通过在传输MM时伴随传输附加信息来解决不同MMSE之间的应答计费时的兼容问题，该附加信息指示了相应的网元(RSA，RSB)是否支持应答计费-功能性。
图3示出了图2的事务流程图的相应扩展。除在那儿所示的抽象消息之外，图3在此还示出了用于MM4接口(也参见图1)的抽象消息。
依照图3，由用户A建立一条MM，标识其为“应答-计费”，并通过MM1接口将其发送到他的业务提供商A的MMSE中的网元RSA5。依照本发明，如果MMS业务提供商A支持所请求的应答计费-功能性，则由网元RSA5在抽象消息N8(MM4_发送.REQ)中把如下的信息与MM一起发送到接收方的MMSE中的网元RSB6-在本情形中不需要解释图3中的消息N9(MM4_发送.RES)-1.始发方准备接受来自接收方的应答-MM的费用(信息元素“应答-计费”)，2.用于发送免费应答-MM的时限(“应答-计费-期限”)，3.应答-MM的最大长度(信息元素“应答-计费-大小”)，4.关于始发方的MMS业务提供商支持或是否支持所请求的应答计费-功能性的信息(典型被称为“应答-计费-支持-在-始发方-MMSE”的信息元素)，或(如果传输的MM是应答-MM；这种情况下，应答-MM被视为是一个新的始发-MM)5.(初始的)始发-MM的消息-ID(“应答-计费-ID”)。
表3示出了本发明的抽象消息N8(MM4_发送.REQ)中的附加信息元素，其中新的信息元素“应答-计费-ID”优选地是插入到已知的信息元素“消息-ID”之后，且其它四个新的信息元素插入到已知的信息元素“内容”之后。
表3依照情形2在抽象消息N8(MM4_发送.REQ)中的附加信息元素。
在表3中没有提到的信息元素“应答-计费”、“应答-计费-期限”和“应答-计费-ID”在此不需要重新定义。它们已经以公知的方式在MM1接口上采用，并在此依照本发明被传送到新的MM4接口。信息元素“应答-计费-支持-在-始发方-MMSE”将在下面详细描述由于在告知或传送MM期间，如果不支持应答计费-功能性，则网元RSB6将把网元RSA5所设定的信息元素“应答-计费-支持”不变地传递到接收应用UAB2，所以，在此处所描述的情形中采取在上面情形1中为传送关于MMS业务提供商支持或是否支持所请求的应答计费-功能性的信息而定义的信息元素“应答-计费-支持”将是不够的。这一特性可能被接收应用UAB2错误地解释。它需要关于参与MM传输的两个网元5，6(RSA，RSB)支持或是否支持所请求的应答计费-功能性的信息。由于该原因，本发明在网元RSA5和网元RSB6之间的MM4接口上定义了一个不同于网元RSB6和接收应用UAB2之间的MM1接口上的信息元素。作为例子，这两个新的信息元素可以被称作“应答-计费-支持-在-始发方-MMSE”(在发射侧的MMSE方支持应答计费)和“应答-计费-支持-在-接收方-MMSE”(在接收侧的MMSE方支持应答计费)。在表3，5和6中示出了它们。在抽象消息N3(表5)和N6(表6)中，信息元素“应答-计费-支持-在-接收方-MMSE”被优选地插入到信息元素“应答-计费”之后。
如果网元RSB支持应答计费-功能性，则它必须在通知接收方之前或在发送MM之前检验抽象消息N8(MM4_发送.REQ)是否包含相应的信息元素“应答-计费-支持-在-始发方-MMSE”。如果是这样，则网元RSB必须在此时把相应的信息元素“应答-计费-支持-在-接收方-MMSE”插入到抽象消息N3(MM1_通知.REQ＝通知准备下载的MM)或抽象消息N6(MM1_检索.RES＝发送MM)中。可选地，如果或只要网元RSB能识别它，则他还可以在完成检验之后再删除由网元RSA设置的信息元素“应答-计费-支持-在-始发方-MMSE”，以减轻空中接口的负载。接收方的接收应用UAB可以利用这种方法、并通过分析信息元素“应答-计费-支持-在-接收方-MMSE”的有无来简单地识别所参与的两个MMS业务提供商是否都能处理一个对始发-MM的应答-MM的发送。
信息元素“应答-计费-大小”标示了应答-MM所允许的大小，其也是本发明申请的主题。为了增强应答计费-功能性的灵活性，优选地补充了抽象消息N1(MM1_提交.REQ)，N8(MM4_发送.REQ)，N3(MM1_通知.REQ)和N6(MM1_检索.RES)。利用该新的信息元素，始发-MM的始发方不仅可以规定应答-MM的时限，而且还可以规定其最大长度。可选择地或额外地，它也可以被所述参与MM传输的MMS业务提供商之一用来限制应答-MM的大小。表3～6示出了在相应的抽象消息中新定义的信息元素“应答-计费-大小”，其中该信息元素在抽象消息N1，N3和N6中被优选地分别插入到已知的信息元素“应答-期限”之后。
表4在抽象消息N1(MM1_提交.REQ)中的附加信息元素。
表5依照情形2的抽象消息N3(MM1_通知.REQ)中的附加信息元素。
表6依照情形2的抽象消息N6(MM1_检索.RES)中的附加信息元素。
类似于在情形1中所描述的方案，在此处引入的信息元素“应答-计费-支持-在-始发方-MMSE”也可优选地被插入到抽象消息N2(MM1_提交.RES)中，由网元RS利用它来确认正确地接收一条MM。这明显增强了应答计费-功能性的灵活性，因为利用该方法，可以在带有应答计费-标识符的始发-MM被发送之后告知发送应用UAA、以及在相应标识的应答-MM被发送之后告知接收应用UAB(在此，接收应用UAB是应答-MM的“始发方”)关于各个MMS业务提供商是否支持所请求的应答计费-功能性的信息。表7示出了在抽象消息N2(MM1_提交.RES)中的附加信息元素“应答-计费-支持-在-始发方-MMSE”，其优选地被插入到信息元素“消息ID”之后。
表7依照情形2的在抽象消息N2(MM1_提交.RES)中的附加信息元素。
III.在WAP中实现本发明在现有技术基础上，可以只使用WAP(WAP-无线应用协议)实现MMS。为在适用于MMS的终端和WAP网关之间搭建空中接口(在3GPP中MM1)，按照3GPP TS 22.140版本4.1.0，第4版(见上面)和WAP-209.102-MMS封装，2001年2月8日，(无线应用协议；WAP多媒体消息业务；消息封装；MMS草案SCD)而规定使用WAP WSP传输协议。因此，在接下来的章节中来讲述如何能把在上面为应答计费而重新定义的3GPP抽象-消息的信息元素转变成所述WAP实现中的WAP消息。在此作为例子，依照情形2(两个MMSE间的应答计费)来实现该实施方案变型，这是因为它描绘了更一般的情况，而且提供了更大的机会以在3GPP和WAP中实现；最后还因为它消除了对只有一个MMSE的限制。
图4示出了WAP中基于现有技术的、依照WAP-209.102-MMS封装(见上面)的“事务流程图”，其中给出了当传送MM时在四个参与的实例之间的WAP消息交换，这四个实例是发送应用1a(MMS客户A，缩写为CA)，发射侧网元5a(MMS代理-中继A，缩写为PRA)，接收侧网元6a(MMS代理-中继B，缩写为PRB)和接收应用2a(MMS客户B，缩写为CB)。本发明申请所涉及的WAP消息，也即N1a(M-发送.req)、N2a(M-发送.conf)、N3a(M-通知.ind)和N6a(M-检索.conf)在此是用粗体示出的。在此，WAP消息N1a对应于前面提到的消息N1，WAP消息N2a对应于前面提到的消息N2，等等。此外还给出了已知的消息N10a(M-传送.ind)。作为指示符，这里可以注意到在WAP中不存在那些在3GPP中定义的概念MMS用户代理，MMS中继/服务器和MMSE。由于该原因，在该章节中只使用MMS客户和MMS代理-中继这样的概念或它们的缩写，而这些缩写指的是同样的实例。对于3GPP概念MMSE，在WAP中不存在类似的表达。
依照WAP-203.102-MMS封装(见上面)，在WAP消息的首字段包含一个字段名，其后接着一个至少包含一个字节(8-比特-字)字段值。表8中给出了十六进制数值至字段名之间的分配关系。当前有24个字段名。因此，在本发明申请中重新定义的字段名优选地在第25号开始(十六进制0x19)。它们在表9中给出。
表8字段名的分配(根据现有技术)。
表9根据本发明新定义的字段名。
由于根据WAP-209.102-MMS封装(见上面)，WAP消息的首字段总是包含一个字段名和一个字段值，所以需要为这里每一个重新定义的首字段定义至少一个字段值。下面给出更详细的解释对首字段的字段值进行编码共有四种可能性，其中首字节决定了编码的类型和长度(见表10)。
表10字段值编码的四种可能性(现有技术)。
为降低在空中接口上传输的数据量，两个新定义的首字段“应答-计费-支持-在-始发方-MMS-代理-中继”和“应答-计费-支持-在-接收方-MMS-代理-中继”的字段值优选地专门是来自于第四个数值范围(128到255)。新的首字段“应答-计费-支持-在-始发方-MMS-代理-中继”和“应答-计费-支持-在-接收方-MMS-代理-中继”的一个可能定义可以是以下的形式字段名应答-计费-支持-在-始发方-MMS-代理-中继字段值应答-计费-支持-在-始发方-MMS-代理-中继-值＝是|否是＝<字节128>
否＝<字节129>
字段名应答-计费-支持-在-接收方-MMS-代理-中继字段值应答-计费-支持-在-接收方-MMS-代理-中继-值＝是|否是＝<字节128>
否＝<字节129>
新定义的首字段“应答-计费-大小”的字段值可以逐级地(应答-MM可大到X，Y或Z千字节)或具体地(应答-MM可能大小只为X千字节)给定。对于带有应答-消息可能大小等级的新首字段“应答-计费-大小”，其一种可能的定义可以具有如下的形式(数值范围4)字段名应答-计费-大小字段值应答-计费-大小-值＝200|400|600|800
200＝<字节128>
400＝<字节129>
600＝<字节130>
800＝<字节131>
带有应答-消息可能大小具体数据的新首字段“应答-计费-大小”的一种可能的定义可以具有下面的形式(数值范围1)字段名应答-计费-大小字段值应答-计费-大小-值＝长-整型在此不再更详细地讨论其它的编码可能性。很明显，本发明的范围内存在不同的编码可能性。
按本发明对WAP消息N1a(M-发送.req)，N2a(M-发送.conf)，N3a(M-通知.ind)和N6a(M-检索.conf)的补充在表11到14中给出。因为在3GPP中定义的信息元素的精确实现至今在WAP论坛中还没有完成，所以为在一个MMSE内实现应答计费-功能性所需要的其余首字段在那里未给出。在WAP消息N1a(M-发送.req)中补充了首字段“应答-计费-大小”-优选地被插入到首字段“内容-类型”之后-，而且可以被那个想使用应答计费-功能性的应用CA1a用来在发送MM时给出时限和限制应答-MM的大小。
表11在WAP消息N1a(M-发送.req)中新定义的首字段。
在WAP消息N2a(M-发送.conf)中已补充了首字段“应答-计费-支持-在-始发方-MMS-代理-中继”-优选地被插入到首字段“消息-ID”之后，并可以被用来告知已发送一条MM的发送应用CA1a相应的网元PRA5a是否已知道/接受所述始发方准备接受应答-MM的费用，或对前面所接收的和相应标识的始发-MM而作出的应答-MM的费用。
表12在WAP消息N2中新定义的首字段(M-发送.conf)。
WAP消息N3a(M-通知.ind)和N6a(M-检索.conf)还包含有(除了可能存在的关于始发方的网元PR5a支持应答计费-功能性的信息之外)由接收方网元PR6a设置的首字段“应答-计费-支持-在-接收方-MMS-代理-中继”。然而，对于接收方的接收应用CB2a，只是有无“应答-计费-支持-在-接收方-MMS-代理-中继”是非常重要的。只有发射侧网元PRA5a和接收侧网元PRB5a都支持应答计费-功能性，才优选地对此进行设定。如果它存在，则接收应用CB2a便能确信所参与的两个MMS业务提供商得知了对前面所接收的始发-MM的应答-MM。在WAP消息N3a的情况下，首字段“X-Mms-应答-计费-支持-在-接收方-MMS-代理-中继”优选地插入到已知的首字段“X-Mms-内容-位置”之后，并在WAP消息N6a的情况下插入到已知的首字段“内容类型”之后。在WAP消息N3a的情况下，首字段“X-Mms-应答-计费-大小”优选地插入到已知的首字段“X-Mms-期限”之后，并在WAP消息N6a情况下优选地插入到已知的首字段“X-Mms-读-应答”之后。
表13在WAP消息N3a(M-通知.ind)中新定义的首字段。
表14在WAP消息N6a(M-检索.conf)中新定义的首字段。
借助应答计费-功能性已经详细解释本发明的第一方面，然而本发明也可以用在其他移动无线用户所请求的功能性上。
此外，本发明不仅可以用于多媒体消息，而且例如还可以相应地应用于SMS消息的发送和接收。
参考符号清单1发送应用(MMS用户代理A＝UAA)1a 发送应用(MMS客户A＝CA)2接收应用(MMS用户代理B＝UAB)2a 接收应用(MMS客户B＝CB)3MMS务提供商(MMS业务提供商A)4MMS业务提供商(MMS业务提供商B)5发射侧网元(MMS中继服务器A＝RSA)5a 发射侧网元(MMS代理-中继A＝RPA)6接收侧网元(MMS中继服务器B＝RSB)6a 接收侧网元(MMS代理-中继B＝PRB)7无线网络8无线网络MM1 接口MM4 接口N1 消息MM1_提交.REQN1a WAP消息M-发送.reqN2 消息MM1_提交.RESN2a WAP消息M-发送.confN3 消息MM1_通知.REQN3a WAP消息M-通知.indN4 消息MM1_通知.RESN4a WAP消息M-通知Resp.reqN5 消息MM1_检索.REQN5a WAP消息WSP GETN6 消息MM_检索.RESN6a WAP消息M-检索.confN7 消息MM1_确认.REQN7a WAP消息M-确认.indN8 消息MM4_发送.REQN9 消息MM4_发送.RESN10a WAP消息M-传送.ind
权利要求
1.在经移动无线网络、尤其是经UMTS网络利用发射侧网元(5，5a)和接收侧网元(6，6a)从发送应用(1，1a)向接收应用(2，2a)传输尤其是传输多媒体消息的消息时扩充信息流的一种方法，其中发射侧网元和接收侧网元可以是相同的，或可以是不同的，并位于一个或两个业务提供商(3，4)的职责范围内，以及其中，所述的消息被用来在至少一个业务提供商的职责范围内请求一个特殊的功能性，例如应答计费或消息回叫，其特征在于所述一个或多个网元(5，5a；6，6a)的关于其支持所请求的功能性的信息被传输给参与数据交换的其它设备(1，1a；2，2a；5，5a；6，6a)，或由后者接收它。
2.如权利要求1的方法，其特征在于所述的消息包含关于始发方准备接受来自接收方的应答-消息的费用的信息(应答-计费)，其中，所述一个网元或多个网元(5，5a；6，6a)的关于其支持应答计费-功能性(信息元素“应答-计费-支持”；信息元素“应答-计费-支持-在-始发方-MMSE”；信息元素“应答-计费-支持-在-接收方-MMSE”)的信息被传输给至少一个参与数据交换的其它设备(1，1a；2，2a；5，5a；6，6a)，或由后者接收它。
3.如权利要求1或2的方法，其特征在于关于所述相对于始发-消息或应答-消息为发射方的网元(5，5a；6，6a)支持所请求的功能性的信息被发送到接收侧的网元(6，6a；5，5a)，或由后者接收和分析它(信息元素“应答-计费-支持-在-始发方-MMSE”)。
4.如上面的权利要求之一的方法，其特征在于在两个彼此不同的网元(5，5a；6，6a)支持所请求的功能性的情况下，相应的信息(信息元素“应答-计费-支持-在-接收方-MMSE”)被传输给接收应用(2，2a；1，1a)，或由该接收应用进行接收。
5.如上面的权利要求之一的方法，其特征在于在两个网元(5，5a；6，6a)支持所请求的功能性的情况下，关于所述发射侧网元(5，5a)支持所请求的功能性的信息(信息元素“应答-计费-支持-在-始发方-MMSE”)被接收侧网元(6，6a)删除，且不传送到接收应用(2，2a)。
6.如上面的权利要求之一的方法，其特征在于用于支持所请求的功能性的信息在消息MM1_提交.RES(N2)或M-发送.conf(N2a)中被所述相对于始发-消息或应答-消息为发射方的网元(5，5a；6，6a)一同传输给相应的发送应用(1，1a；2，2a)，或由该发送应用接收它。
7.如权利要求6中的方法，其特征在于在WAP消息M-发送.conf(N2a)中使用一个新的、采用字段名十六进制编码的首字段(“应答-计费-支持-在-始发方-MMSE-代理-中继”)，如果支持所请求的功能性，所述字段名的字段值则优选地包含字节<字节128>，如果不支持，则包含字节<字节129>。
8.如上面的权利要求之一的方法，其特征在于用于支持所请求的功能性的信息在消息MM1_通知.REQ(N3)或M-通知.ind(N3a)和/或MM1检索.RES(N6)或M-检索.conf(N6a)中被接收侧网元(6，6a)一同传输给接收应用(2，2a)，或由后者进行接收。
9.如权利要求8中的方法，其特征在于在WAP消息M-通知.ind(N3a)和/或M-检索.conf(N6a)中使用一种具有十六进制字段名编码的首字段(“应答-计费-支持-在-接收方-MMSE-代理-中继”)，如果支持所请求的功能性，所述字段名的字段值则优选地包含字节<字节128>，如果不支持，则包含字节<字节129>。
10.如上面的权利要求之一的方法，其特征在于由所述的接收应用(2，2a)分析是否存在关于所述发送和/或接收侧网元(5，5a；6，6a)支持所请求的功能性的信息，并促使或禁止为操作员输出相应的信息。
11.尤其是如上面的权利要求之一所述的，用于在经移动无线网络、尤其是经UMTS网络利用发射侧网元(5，5a)和与该发射侧网元不同的接收侧网元(6，6a)从发送应用(1，1a)向接收应用(2，2a)传输尤其是传输多媒体消息的消息时为应答计费-功能性扩充信息流的一种方法，其中所述的发射侧网元和接收侧网元位于两个业务提供商(3，4)的职责范围内，以及其中，所述的消息包含关于始发方准备接受来自接收方的应答-消息的付费的信息(应答计费)，其特征在于下面的信息中的至少一个从发射侧网元(1，1a)被传输到接收侧网元(2，2a)或被后者接收·始发方准备接受来自接收方的应答-消息的付费(信息元素“应答-计费”)；·发送免费应答-消息的时限(信息元素“应答-计费-期限”)；·应答-消息的最大长度(信息元素“应答-计费-大小”)；·当传送应答-消息时的始发-消息(信息元素“应答-计费-ID”)的消息-标识号(消息-ID)。
12.如上面的权利要求之一的方法，其特征在于如果发送和接收侧网元(5，5a；6，6a)是彼此不同的，则所述信息中的至少之一在消息MM4_发送.REQ(N8)中被一同传送或接收。
13.在经移动无线网络、尤其是经UMTS网络利用发射侧网元(5，5a)和接收侧网元(6，6a)从发送应用(1，1a)向接收应用(2，2a)传输尤其是传输多媒体消息的消息时为应答计费-功能性扩充信息流的一种方法，其中所述的发射侧网元和接收侧网元是相同或不同的，并且位于一个或两个业务提供商(3，4)的职责范围内，以及其中，所述的消息包含关于始发方准备接受来自接收方的应答-消息的付费的信息(应答计费)，其特征在于由所述的发送应用(1，1a)、发射侧网元(5，5a)、接收侧网元(6，6a)和/或接收应用(2，2a)传送或接收用于应答-消息最大允许长度的信息。
14.如权利要求13中的方法，其特征在于所述用于最大允许长度的信息在消息MM1_提交.REQ(N1)或M-发送.req(N1a)中从发送应用(1，1a)被一同传输给发射侧网元(5，5a)，或由该发射侧网元进行接收。
15.如权利要求13或14中的方法，其特征在于所述用于最大允许长度的信息在消息MM1_通知.REQ(N3)或M-通知.ind(N3a)和/或MM1检索.RES(N6)或M-检索.conf(N6a)中从接收侧网元(6，6a)被一同传输给接收应用(2，2a)，或由该接收应用进行接收。
16.如权利要求14或15中的方法，其特征在于在WAP消息M-发送.req(N1a)、M-通知.ind(N3a)和/或M-检索.conf(N6a)中使用新的、采用十六进制字段名编码的首字段(“应答-计费-大小”)，该字段名的字段值优选地包含多个可能的分级最大值之一，或包含一个由始发方为该应答-消息允许的长度所选择的具体值。
17.在一个业务提供商的职责范围内的网元(5，5a；6，6a)，它被分配给一个发送应用(1，1a)和/或一个接收应用(2，2a)，而且尤其是UMTS网络中的网元，尤其被用来执行如上面权利要求之一所述的方法，其中，这种网元(5，5a；6，6a)可以被用来从一个发送应用(1，1a)向一个接收应用(2，2a)传输尤其是多媒体消息的消息，以及其中，所述的消息被用来在至少一个业务提供商的职责范围内请求一个特殊的功能性，例如应答计费或消息回叫，其特征在于所述的网元(5，5a；6，6a)被设计成这样，使得它能把关于其支持所请求的功能性的信息传送给另一参与数据交换的设备(1，1a；2，2a；5，5a；6，6a)，或由后者接收该信息。
18.尤其是如权利要求17中所述的在一个业务提供商(3，4)的职责范围内的网元(5，5a；6，6a)，其中，该网元被分配给一个发送应用(1，1a)和/或一个接收应用(2，2a)，而且尤其是UMTS网络中的网元，尤其被用来执行如权利要求1～16之一所述的方法，其中，这种网元可以被用来从一个发送应用(1，1a)向一个接收应用(2，2a)传输尤其是多媒体消息的消息，以及其中，所述的消息包含关于始发方准备接受来自接收方的应答-消息的费用的信息(应答计费)，其特征在于所述的网元(5，5a；6，6a)被设计成这样，使得它能传输或接收和分析以下信息中的至少一个·在发射侧和接收侧网元(5，5a；6，6a)不同的情况下向接收应用(2，2a)传输始发方准备接受来自接收方的应答-消息的费用(信息元素“应答-计费”)；·在发射侧网元和接收侧网元不同的情况下，由发射侧网元(5，5a)传输或由接收侧网元(6，6a)接收用于发送免费应答-消息的时限(信息元素“应答-计费-期限”)；·向或由另一参与数据交换的设备(1，1a；2，2a；5，5a；6，6a)传输或接收应答-消息的最大长度(信息元素“应答-计费-大小”)；·当传输应答-消息时，向或由所述相对于应答-消息为接收方的网元传输或接收始发-消息(信息元素“应答-计费-ID”)的消息-标识号(消息-ID)。
19.用于在尤其为UMTS网络的移动无线网络中进行通信的移动无线用户设备，尤其用于执行如权利要求1到16之一所述的方法步骤，它具有至少一个接收应用(2，2a)以用于从一个业务提供商(3，4)的职责范围内的一个网元(5，5a；6，6a)接收尤其是多媒体消息的消息，所述的网元尤其是如权利要求17或18所述的网元，其中，所述的消息包含在业务提供商的职责范围内对特殊功能性的请求，例如应答计费或消息回叫(应答-计费)，其特征在于将所述的设备设计成这样，使得它可以接收和分析关于所参与的网元支持所请求的功能性的信息。
20.尤其如权利要求19所述的、用于在尤其为UMTS网络的移动无线网络中进行通信的移动无线用户设备，尤其用于执行如权利要求1到16之一所述的方法步骤，它具有用于从一个业务提供商(3，4)的职责范围内的一个网元(5，5a；6，6a)发送和/或接收尤其是多媒体消息的消息的发送应用和/或接收应用(1，1a；2，2a)，所述的网元尤其是如权利要求17或18所述的网元，其中，所述的消息可以包含关于始发方准备接受来自接收方的应答-消息的费用的信息(应答-计费)，其特征在于将所述的设备设计成这样，使得它能传输或接收至少以下信息之·在发射侧和接收侧网元(5，5a；6，6a)不同的情况下，接受并分析关于始发方准备接受来自接收方的应答-消息的费用的信息(信息元素“应答-计费”)；·传送和/或接收用于应答-消息最大允许长度的信息(信息元素“应答-计费-大小”)；·接收并分析关于所述相对于始发-消息或应答-消息为发射方的网元(1，1a或2，2a)支持应答计费-功能性的信息(信息元素“应答-计费-支持-在-始发方-MMSE”)；·接收并分析关于所述相对于始发-消息或应答-消息为接收方的网元(2，2a)支持应答计费-功能性的信息(信息元素“应答-计费-支持-在-接收方-MMSE”)。
21.能够在一个带有处理器的设备上运行的软件程序，所述的设备尤其是权利要求17或18的网元或权利要求19或20的移动无线用户设备，该软件程序被如此地运行，使得它同所述的设备一起在该设备方执行如权利要求1到16之一所述的方法步骤。
22.能被装载到带有处理器的设备的软件程序，所述的设备尤其是权利要求17或18的网元或权利要求19或20的移动无线用户设备，使得被如此编程的、且包括处理器在内的设备能够或被匹配用来执行如权利要求1到16之一所述的方法步骤。
全文摘要
本发明提出了一些方法、装置和软件程序，用来在至少一个业务提供商的职责范围内在功能性方面简化信息流，尤其是对UMTS中的多媒体消息，其中，该功能性已由用户进行请求。这样功能性的例子有应答计费或消息回叫。本发明尤其提出了传输如下信息的方法，即从该信息可以得出在业务提供商职责范围内的网元是否支持所请求的功能性。本发明还提出了在应答计费时对应答－消息的最大尺寸进行限制。
文档编号H04L12/58GK1402469SQ0212855
公开日2003年3月12日 申请日期2002年8月9日 优先权日2001年8月10日
发明者J·劳门, A·施密德特, M·特劳贝格, S·范尼克尔克 申请人:西门子公司