CN101102280B

CN101102280B - 一种ip多媒体子系统中优化通讯传输效率的方法

Info

Publication number: CN101102280B
Application number: CN2007101358945A
Authority: CN
Inventors: 吴亚
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2007-08-01
Filing date: 2007-08-01
Publication date: 2010-12-08
Anticipated expiration: 2027-08-01
Also published as: CN101102280A

Abstract

本发明公开了一种IP多媒体子系统中优化通讯传输效率的方法，当通讯发起方需要更新数据内容时，通过向通讯接收方传送变更部分的数据，变更所述通讯接收方的数据内容。其中，所述通讯发起方通过报文中携带原始数据包欲修改处的位置和变更数据，指示通讯接收方接收所述报文后处理变更数据。本发明对减轻通讯网络负荷，节省线路带宽、降低网元设备处理器开销和减少传输时延等都有显著效果。

Description

一种IP多媒体子系统中优化通讯传输效率的方法

技术领域

本发明涉及通讯领域，尤其涉及一种IP多媒体子系统中优化通讯传输效率的方法。

背景技术

IP多媒体子系统IMS(IP Multimedia Subsystem)作为新一代通讯网络的核心，采用会话初始协议SIP(Session Initiation Protocol)、直径协议Diameter、可扩展标识语言XML(Extensible Markup Language)等协议规范。这些协议大量使用文本传输数据，与传统二进制信令流相比，文本码流对通讯带宽、网元处理能力等提出了更高的要求。由此，各种信令压缩、信令处理等优化通讯传输效率的方法不断涌现，3GPP(3rd Generation PartnershipProject，第三代合作伙伴计划)等国际标准组织也采纳了其中一些技术研究的成果。当前，随着IMS的逐步成熟，优化网络信令传输效率已经成为热点议题，受到国内外技术组织和商业机构的关注。

通常，信令压缩算法等技术方式是承载层优化处理方式，其特点是不关心信令内容本身。而大量的应用层协议需要根据信令内容的特点，考虑信令传输机制以保证适当的通信效率。因此，各种针对具体应用协议的改进方法纷纷被提出。例如，3GPP TS(Technology Standard，技术规范)29.328协议所规定的Sh接口信令中，透明数据作为一种超大数据类型被大量传输，常出现传输内容存在重复现象，有国外通讯厂商就提出，将透明数据整块分割为小的数据包进行传输。这种方式避免了不必要的重复数据内容在网络上传输，但也破坏了数据块的完整性，因为小数据包本身没有意义，仅仅是在应用层做了传输层的分包工作，况且事先也无法预知数据包应在何处分段。同时，这种方法也对传输双方的处理网元提出了更高的要求，因为必须存储、检索和管理更小的数据块单元。这导致通讯过程中大数据包信令传输效率低下，尤其是在待传输信令数据包庞大且存在重复数据内容的时候更为明显。

发明内容

本发明提供一种IP多媒体子系统中优化通讯传输效率的方法，以解决通讯过程中大数据包信令传输效率低下的问题。

为了解决上述技术问题，本发明提供一种IP多媒体子系统中优化通讯传输效率的方法，当通讯发起方需要更新数据内容时，通过报文中携带原始数据包欲修改处的位置和变更数据向通讯接收方传送变更部分的数据，指示通讯接收方接收所述报文后处理变更数据，变更所述通讯接收方的数据内容；

所述方法应用于归属用户服务器和应用服务器网元之间时，包括步骤：

(1)所述应用服务器向所述归属用户服务器发送用户数据读取请求，请求获得用户当前数据；

(2)所述归属用户服务器向所述应用服务器返回用户数据读取响应，携带所述用户当前数据；

(3)所述应用服务器执行用户相应业务逻辑后，发现需要更新用户数据，向所述归属用户服务器发送用户数据更新请求，请求更新用户的部分数据内容；所述请求中携带变更位置指示和需变更部分的数据；

(4)所述归属用户服务器接收到更新请求后，根据所述用户数据的初始值，处理其中的变更部分，将变更后的完整用户数据存入数据库中，并向所述应用服务器返回用户数据更新响应。

本发明所述方法，其中，所述位置为偏移位置，所述报文中还携带欲修改原始数据部分的长度。

本发明所述方法，其中，所述通讯发起方在一次报文传输中携带一个或多个变更部分，如果是多个变更部分，则指示通讯接收方接收所述报文后依次处理各个变更数据。

本发明所述方法，其中，所述通讯发起方在报文中携带变更类型指示，所述变更类型指示是新增、或删除，或修改。

本发明所述方法，其中，所述通讯发起方在报文中携带校验字段。

进一步地，所述校验字段为变更数据所属的父一级可扩展标识语言标签。

进一步地，所述方法应用于IP多媒体子系统中归属用户服务器和应用服务器网元之间的Sh接口上时，待传输用户数据为可扩展标识语言格式，传输协议为直径协议。

进一步地，所述报文中携带原始数据包欲修改处的位置和变更数据通过在所述直径协议中通过引入数值-属性对来实现。

本发明实现了通讯效率优化的功能，特别是针对大数据包传送的应用场合。由于在接口上只传输必要的数据，实际应用本发明后，一些通讯接口的传输效率可以明显提高，例如3GPP标准中的Sh接口。这对减轻通讯网络负荷，节省线路带宽、降低网元设备处理器开销和减少传输时延等都有显著效果。

本发明将优化功能定义为可选新特性，例如在Diameter协议中通过引入新的AVP(Attribute Value Pair，数值-属性对)来实现，从而很好的与现有系统兼容。

此外，本发明还具有实现简单，对现有设备改动小的优点。

附图说明

图1是IMS系统中归属用户服务器(HSS，Home Subscriber Server)和应用服务器(AS，Application Server)网元之间连接结构示意图；

图2是现有技术IMS系统中应用服务器和归属用户服务器之间通讯的消息流程示意图；

图3是本发明应用实例应用服务器和归属用户服务器之间通讯的消息流程示意图。

具体实施方式

本发明的一种IP多媒体子系统中优化通讯传输效率的方法，当通讯发起方试图更新数据内容时，不需要传输变更后的全部数据，仅需要传送变更部分，未改变的数据内容无需传送。

通讯发起方通过报文中携带原始数据包欲修改处的偏移位置和欲修改原始数据部分的长度以及变更数据，指示通讯接收方正确处理变更数据。

通讯发起方可以在一次报文传输中携带多个变更部分，指示通讯接收方依次处理各个变更数据，实现对原始数据包的多处修改。

通讯发起方可以在报文中携带变更类型指示，告知通讯接收方变更操作是新增、删除还是修改。

通讯发起方可以在报文中携带校验字段，防止因通讯双方对原始数据理解不一致造成的数据处理错误。

本发明通过指示待传输数据包相对于原始数据包内容的偏移值和长度的方式，减小待传输数据包的长度，从而大大减轻网络负荷和处理器开销。这在通讯双方都已知原始数据内容且数据包庞大时特别有效。当原始数据内容未知时，通过传送偏移值为0的新数据包实现全部覆盖原始数据。

本发明将优化功能定义为可选新特性，例如在Diameter协议中通过引入新的AVP来实现，从而很好的与现有系统兼容。

以下结合附图和具体实施方式对本发明进行详细描述。

如图1所示，IMS系统中归属用户服务器和应用服务器网元之间通过Sh接口相连。在该Sh接口上，待传输用户数据为XML格式，传输协议为Diameter协议。

如图2所示，为现有技术IMS系统中应用服务器和归属用户服务器之间通讯的消息流程示意图，步骤如下：

步骤201，应用服务器向归属用户服务器发送用户数据读取请求(UDR，User-Data-Request)，请求获得用户当前数据；

步骤202，归属用户服务器向应用服务器返回用户数据读取响应(UDA，User-Data-Answer)，携带用户当前数据；

步骤203，应用服务器执行用户相应业务逻辑后，发现需要更新用户数据，向归属用户服务器发送用户数据更新请求(PUR，Profile-Update-Request)，请求更新用户的部分数据内容；请求中携带用户的完整新数据，包括未变更的和期望变更的内容；

步骤204，归属用户服务器接收到更新请求后，以请求中的完整用户数据覆盖原始数据，存入数据库中，并向应用服务器返回用户数据更新响应(PUA，Profile-Update-Answer)，本次通讯过程结束。

以某个传输报文为例，详细描述如下：

上述步骤202中，原始数据包(即User-Data-Answer响应中携带的数据)内容为：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<IMS Subscription

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xsi:noNamespaceSchemaLocation＝″D:\CxDataType.xsd″>

<PrivateID>IMPI@homedomain.com</PrivateID>

<Identity>sip:IMPU@homedomain.com</Identity>

</PublicIdentity>

<SPT>

<Method>INVITE</Method>

</SPT>

<SPT>

<Method>MESSAGE</Method>

</SPT>

<SPT>

</SIPHeader>

</SPT>

</TriggerPoint>

<ServerName>sip:AS1@homedomain.com</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

</ServiceProfile>

</IMSSubscription>

上述步骤203中，应用服务器试图更新数据内容为：(即Profile-Update-Request报文)

<Profile-Update-Request>::＝<Diameter Header:307，REQ，PXY，

16777217>

<Session-Id>

{Vendor-Specific-Application-Id}

{Auth-Session-State}

{Origin-Host}

{Origin-Realm}

[Destination-Host]

{Destination-Realm}

{User-Identity}

{Data-Reference}

{User-Data}

其中User-Data字段携带的内容为：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<IMS Subscription

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xsi:noNamespaceSchemaLocation＝″D:\CxDataType.xsd″>

<PrivateID>IMPI@homedomain.com</PrivateID>

<Identity>sip:IMPU@homedomain.com</Identity>

</PublicIdentity>

<SPT>

<Method>INVITE</Method>

</SPT>

<SPT>

<Method>MESSAGE</Method>

</SPT>

<SPT>

<Content>″susan″</Content>

</SIPHeader>

</SPT>

</TriggerPoint>

<ServerName>sip:AS1@homedomain.com</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

</ServiceProfile>

</IMSSubscription>

也就是应用服务器AS仅试图将用户数据中的From joe更新为To susan，但按照目前协议需要将完整的数据传送到归属用户服务器HSS。

如图3所示，是本发明应用实例应用服务器和归属用户服务器之间通讯的消息流程示意图，步骤如下：

步骤301，应用服务器向归属用户服务器发送用户数据读取请求UDR，请求获得用户当前数据；

步骤302，归属用户服务器向应用服务器返回用户数据读取响应UDA，携带用户当前数据；此时，通讯双方均已知原始数据包内容；

步骤303，应用服务器执行用户相应业务逻辑后，发现需要更新用户数据PUR，向归属用户服务器发送用户数据更新请求，请求更新用户的部分数据内容；请求中仅携带变更位置指示和需变更部分的数据；

步骤304，归属用户服务器接收到更新请求后，根据用户数据的初始值，处理其中的变更部分，将变更后的完整用户数据存入数据库中，并向应用服务器返回用户数据更新响应PUA，本次通讯过程结束。

上述本实例中传输报文的详细描述如下：

原始数据包(即User-Data-Answer响应中携带的数据)内容与上例中所示相同。

应用服务器试图将用户数据中的From joe更新为To susan，向归属用户服务器传送的实际数据报文为：

<Profile-Update-Request>::＝<Diameter Header:307，REQ，PXY，

16777217>

<Session-Id>

{Vendor-Specific-Application-Id}

{Auth-Session-State}

{Origin-Host}

{Origin-Realm}

[Destination-Host]

{Destination-Realm}

{User-Identity}

{Data-Reference}

[User-Data]

*[Modified-User-Data]

Modified-User-Data数值-属性对(AVP)字段是应用本发明思想新增的Diameter协议中的自定义复合类型AVP，该AVP用于承载变更的数据内容，AVP格式为：

Modified-User-Data::＝<AVP header:TBD 10415>

{Modi-Type}

{Data-Offset}

[Data]

[Xml-Tag]

*[AVP]

其中，Modi-Type为Enumerated枚举类型，指示变更类型是增加、删除还是修改。本例中该值为修改。

Data-Offset为Unsigned32 32位无符号类型，表明原始数据欲修改处相对于原始数据起始处的偏移量，该值总是针对原始数据而言。该偏移值指向的数据必须以XML标签开头。本例中该值为846。

Data为OctetString八位组串类型，为变更数据的实际内容，必须以XML标签起止。本例中该值为：<Header>To</Header><Content>″susan″</Content>。

Xml-Tag为OctetString类型，为变更数据所属的父一级XML标签。用于接收方比对校验变更内容是否合法，以免双方原始数据不一致时，修改数据发生错乱。本例中该值为：<SIPHeader>。

由于XML数据均以标签起止，所以接收方可以根据偏移处的标签判断需要更新的原始数据部分的实际长度，因此发送方无需指示待变更部分长度。这在待变更部分长度和变更后长度不同的情况下仍然适用。

需要注意的是，一次更新数据操作允许携带多个Modified-User-Data字段，以便同时更新数据包中的多处数据。接收方必须按照Modified-User-Data字段中Data-Offset数值从小到大的顺序依次处理各个Modified-User-Data字段。

比较可见，PUR(Profile-Update-Request)消息的报文长度显著减小。因此，应用本发明方式可以有效降低通讯中的传输流量，避免不必要的网络带宽浪费。

以上采用XML格式数据作为示例，下面说明不限定格式的更一般数据的传输方法。变更数据描述部分仍采用Diameter协议描述方式，其他通讯协议描述方式均与此类似，例如扩展巴科斯范式ABNF(AugmentedBackus-Naur Form)、抽象语法标记ASN.1(Abstract Syntax Notation One)描述等，仅在于描述文法不同，并不影响对其含义的理解。

Modified-User-Data::＝<AVP header:TBD 10415>

{Origin-Data-Offset}

{Origin-Data-Length}

[New-Data]

*[AVP]

Origin-Data-Offset为Unsigned32类型，表明原始数据欲修改处相对于原始数据起始处的偏移量，该值总是针对原始数据而言。

Origin-Data-Length为Unsigned32类型，表明原始数据欲修改部分的长度。

New-Data为OctetString类型，为变更数据的实际内容。该字段本身含有New-Data的长度，对于不能指示数据长度的某些协议描述文法，应另有一个字段指示新数据的长度。

如果希望删除原始数据某处内容，应将Origin-Data-Offset字段指示为待删除部分起始处的偏移值，Origin-Data-Length指示为待删除部分的长度，且不携带New-Data字段，表明是删除操作。如果希望新增内容，应将Origin-Data-Offset字段指示为待插入处的偏移值，Origin-Data-Length为0指示为插入操作，携带New-Data字段为欲插入内容。如果希望更改内容，应将Origin-Data-Offset字段指示为欲修改处的偏移值，Origin-Data-Length为欲修改部分的长度，并携带New-Data字段为欲修改内容。

例如，欲将字串“123456789”更改为“A1234EE678”，需传输内容为：

Modified-User-Data 1：Origin-Data-Offset＝0，Origin-Data-Length＝0，New-Data＝“A”

Modified-User-Data 2：Origin-Data-Offset＝4，Origin-Data-Length＝1，New-Data＝“EE”

Modified-User-Data 3：Origin-Data-Offset＝8，Origin-Data-Length＝1

接收方依次处理这三个变更指示(分别为新增、修改、删除操作)，即可将原始字串修改为所需字串。

本发明所述方法，并不仅仅限于说明书和实施方式中所列运用。对本发明技术所属领域的普通技术人员来说，可根据本发明作出各种相应的改变和变形，而所有这些相应的改变和变形都属于本发明权利要求的保护范围。

Claims

1.一种IP多媒体子系统中优化通讯传输效率的方法，其特征在于，当通讯发起方需要更新数据内容时，通过报文中携带原始数据包欲修改处的位置和变更数据向通讯接收方传送变更部分的数据，指示通讯接收方接收所述报文后处理变更数据，变更所述通讯接收方的数据内容；

2.如权利要求1所述方法，其特征在于，所述位置为偏移位置，所述报文中还携带欲修改原始数据部分的长度。

3.如权利要求1所述方法，其特征在于，所述通讯发起方在一次报文传输中携带一个或多个变更部分，如果是多个变更部分，则指示通讯接收方接收所述报文后依次处理各个变更数据。

4.如权利要求1所述方法，其特征在于，所述通讯发起方在报文中携带变更类型指示，所述变更类型指示是新增、或删除，或修改。

5.如权利要求1所述方法，其特征在于，所述通讯发起方在报文中携带校验字段。

6.如权利要求5所述方法，其特征在于，所述校验字段为变更数据所属的父一级可扩展标识语言标签。

7.如权利要求1所述方法，其特征在于，所述方法应用于IP多媒体子系统中归属用户服务器和应用服务器网元之间的Sh接口上时，待传输用户数据为可扩展标识语言格式，传输协议为直径协议。

8.如权利要求7所述方法，其特征在于，所述报文中携带原始数据包欲修改处的位置和变更数据通过在所述直径协议中通过引入数值-属性对来实现。