专利名称：用于应用消息解压缩的配置的制作方法
技术领域：
本发明涉及应用消息的压缩，更具体地说涉及根据SigComp压缩技术压缩应用消息。
背景技术：
许多用于多媒体通信的应用协议，如SIP(会话发起协议)或RTSP(实时流协议)是基于文本的，且是针对具有宽带的链路设计的。因此，它们的消息未在大小方面进行优化。例如，典型的SIP消息的范围从一百多字节到两百字节或更多。随着作为2.5G和3G蜂窝网络的一部分，按规划将这些协议用于无线手持机中时，大的消息大小就成问题了。由于低速率IP连接的原因，传输时延显著。将一些传输流中要求的重传和消息重复度纳入考虑，至少会不利地影响呼叫建立和功能调用。
为消除此问题，已经定义了信令压缩(SigComp)体系结构，以实现对应用消息的稳健且无损的压缩。就OSI模型而言，SigComp体系结构可以解释为对传输层的增强。因此，SigComp为较高层应用同时提供消息的传输和压缩。由于SigComp在移动通信中很有用，第三代伙伴关系项目(3GPP)已经推荐至少将SigComp用于压缩SIP消息。因此，将来的3G移动终端必须支持SigComp。
SigComp体系结构的发送端包括如下实体压缩器调度器、一个或多个压缩器和状态处理器。所述压缩器调度器用作朝向应用的接口。应用向压缩器调度器提供应用消息和消息编组(compartment)标识符(即用于应用特定消息编组的标识符)。压缩器调度器调用特定的压缩器，它返回要转发到远程端点的SigComp消息。状态处理器存储并检索存储在SigComp消息之间的状态信息，以避免逐个消息地上载数据。
SigComp体系结构的接收侧包括如下实体解压缩器调度器、通用解压缩器虚拟机(UDVM)和状态处理器。解压缩器调度器用作朝向应用的接口。解压缩器调度器从传输层接收SigComp消息，并调用UDVM的实例，由其将该SigComp消息解压缩。解压缩器调度器随后将所得到的解压缩消息转发到应用，如果希望允许保存对应于该消息的状态，则可以返回消息编组标识符。在解压缩过程中，UDVM可以调用状态处理器以访问现有状态和创建新状态。
SigComp消息作为数据分组流连同其它应用消息如未压缩的SIP和RTSP消息一起在传输层上传输。SigComp消息以其自己的5位定界符标识，即它们以11111比特开头，而以OxFFFF比特结束。因此，传输层数据流被导向到解压缩器调度器，所述解压缩器调度器必须设为识别要解压缩的SigComp消息并将非SigComp消息传递到特定的应用客户，例如SIP栈和RTSP。
与上述配置相关的缺点之一是，解压缩器调度器必须知道所有应用客户以及它们使用的定界符。因此，每次引入新客户时，必须更新解压缩器调度器逻辑。另一个主要问题与应用消息的二进制内容相关。SigComp消息的定界符也可能出现在应用消息中，例如，可在SIP消息中发现11111比特图案。这可能导致解压缩器调度器中误解释定界符，从而导致调度器故障。
发明简述因此，本发明的目的在于提供一种简化的方法和用于实施所述方法的装置，以便克服上述问题，同时保持与SigComp体系结构兼容。本发明的目的通过特征由独立权利要求所述的系统、方法、终端和软件产品来实现。本发明的优选实施例在从属权利要求中公开。
本发明的第一方面基于如下思想将应用消息解压缩，其中接收包含应用消息的传输层数据分组流，至少所述应用消息之一根据信令压缩方法，例如根据SigComp压缩方法来压缩。所述接收到的传输层数据分组流被传送到至少一个应用客户，其中识别发往所述应用客户的未压缩的应用消息。所述未识别的应用消息被传送到解压缩实体，所述解压缩实体配置为识别根据所述信令压缩方法如SigComp压缩方法压缩的应用消息并将其解压缩。如果发现根据信令压缩方法如SigComp压缩方法压缩的应用消息，则将它们解压缩并回传到所述应用客户。
根据本发明第一方面的优选实施例，按消息定界符来识别所述未压缩的应用消息和根据SigComp压缩方法压缩的应用消息。
根据本发明第一方面的另一个优选实施例，提供从所述解压缩实体朝向仅所述至少一个应用客户的协议层接口。
根据本发明第一方面的另一个优选实施例，在所述至少一个应用客户中，将所述解压缩的应用消息中的每一个链接到消息编组类实例。
根据本发明第一方面的另一个优选实施例，所述解压缩实体在Symbian OS中实现，由此至少提供从所述解压缩实体朝向Symbian OS的如下接口朝向Symbian OS的安全管理功能的API；朝向SymbianOS的应用框架的API和朝向Symbian OS基层的API。
本发明的第二方面基于如下思想压缩应用消息，其中从至少一个应用客户将至少一个应用消息传送到压缩实体，所述压缩实体配置为根据信令压缩方法如SigComp压缩方法压缩应用消息。所述应用消息根据信令压缩方法如SigComp压缩方法来压缩，并被回传到所述应用客户。然后将所述至少一个压缩的应用消息传送到传输层，以形成传输层数据分组流，该传输层数据分组流因此包括根据所述信令压缩方法如SigComp压缩方法压缩的至少一个应用消息。
根据本发明第二方面的优选实施例，所述压缩实体提供引入新压缩器的插件功能。
根据本发明第二方面的另一个优选实施例，在所述至少一个应用客户中，创建消息编组类，以标识用于与特定端点通信的压缩的应用消息，以及为每个压缩的应用消息分配消息编组类实例。
本发明的方法和配置的优点在于不再需要调度器。因此，简化了实现方式，并且绕开了调度器逻辑更新的问题。本发明的另一个优点是，由于监控传输层数据流的责任转移到应用客户，因此应用消息定界符的二进制内容不会引起任何解释混淆。本发明的另一个优点是，由于不使用调度器，也就不会使用消息编组标识符。因此，实现方式得以大大简化。本发明的另一个优点是，由于压缩器的插件式体系结构，可以顺利地引入新压缩器，而不会影响所述应用客户的存在。
附图简介下面将参考附图通过优选实施例来更详细地描述本发明，附图中
图1显示SigComp体系结构的常见功能元素；图2显示SigComp体系结构的简化结构的优选实施例；图3显示应用消息标识和状态信息配置的优选实施例；图4显示协议层上应用消息流的优选实施例；以及图5显示Symbian OS的一般结构。
发明的详细说明下面将以SigComp体系结构作为可借以实施本发明的信令压缩方法的一个实例来讨论本发明。但本发明不限于SigComp体系结构，而是还可以在包括所附权利要求中公开的类似元素的信令压缩结构中实施。
现在参见图1，其中就SigComp体系结构的相关元素对其进行了进一步的描述。有关SigComp体系结构的更详细的描述，可参考IETF文档RFC 3320，“信令压缩(SigComp)”(″Signaling Compression(SigComp)″，January 2003)。
图1显示了设在OSI模型的应用层(140)和传输层(150)之间的SigComp体系结构(100)的功能元素。SigComp所支持的应用包括若干应用协议，包括SIP(会话发起协议，在RFC 3261中公开)和RTSP(实时流传输协议，在RFC 2326中公开)。SigComp所支持的传输协议则包括多种传输，包括TCP、UDP和SCTP(流控制传输协议，在RFC 2960中公开)。SigComp体系结构使用传输层来传送SigComp消息，由此SigComp体系结构可以视为对应用的传输层的增强。要注意，如下进一步公开的本发明的实施方式不限于所用的应用协议或传输协议。
SigComp体系结构是为双向消息传输设计的。因此，消息传送的端点(例如移动网络的用户设备UE)通常包括用于对SigComp消息进行压缩和解压缩的所有必要元素。图1显示了这种SigComp端点的一个概貌。SigComp层(100)分解成压缩器和解压缩器调度器(102，104)、一个或多个压缩器(106，108)、通用解压缩器虚拟机UDVM(110，即解压缩器功能)以及状态处理器(112)。
压缩器调度器(102)用作朝向应用(140)的接口。应用向压缩器调度器提供应用消息和消息编组标识符(142)。消息编组是一组与某个对等端点相关的消息，由此要由应用执行分组。根据信令协议，这种分组可以涉及诸如“会话”、“对话”、“连接”或“关联”等应用概念。所述应用基于每个消息编组分配状态存储器，并确定何时应该创建或关闭消息编组。消息编组标识符唯一地标识消息编组。压缩器调度器包括路由表，其中所述消息编组标识符和压缩器链接在一起。
压缩器调度器(102)调用特定的压缩器(106，108)，由其执行将应用消息转换成SigComp消息的实际转换。利用应用提供的消息编组标识符，基于每个消息编组来调用不同的压缩器。压缩器从压缩器调度器接收应用消息(114，116)，压缩该消息，并将SigComp消息(114，116)返回到所述压缩器调度器。每个压缩器选择某种算法来对数据编码。所选择的压缩器返回SigComp消息，以便通过传输层(150)转发到(118)远程端点。状态处理器(112)可以存储和检索(120，122)状态消息(124，126)，即SigComp消息之间存储的信息，从而避免逐个消息地上载数据的需要。为了安全性目的，只在应用允许的情况下才可以创建新的状态。
解压缩器调度器(104)则形成从传输层(150)朝向应用(140)的接口。该解压缩器调度器从传输层接收SigComp消息(152)，并调用提供SigComp的解压缩功能的UDVM(110)的实例(128)。UDVM是单独为运行解压缩算法设计的虚拟机。UDVM可以配置为理解许多熟知的压缩器如Deflate(公开于RFC 1951)的输出。在解压缩过程中，UDVM可以调用(130)上述状态处理器来访问现有状态和创建新状态。解压缩的应用消息被返回到该解压缩器调度器，以便转发(132)到应用，如果应用希望允许保存对应于该消息的状态，则可以返回消息编组标识符(134)。
当压缩双向应用协议时，可以在两个方向上独立地作出使用SigComp的选择，在一个方向上执行压缩不一定意味着要在反方向上执行压缩。此外，即使两个通信端点在两个方向上发送SigComp消息时，也无需在每个方向上采用相同的压缩算法。
从应用的角度，SigComp层表现为新传输，具有与用于承载未压缩数据的原始传输类似的特性(例如SigComp/UDP的行为与原始UDP类似)。未压缩的应用消息和SigComp消息通常复用在同一个端口上，即便应用可以为SigComp消息专门预留新的端口。
如果特定端点希望是有状态的，则它需要将其解压缩的消息划分到可以保存状态的消息编组中。SigComp依赖应用来提供这种划分。因此对有状态端口而言，需要朝向应用的新接口，以便充分利用本身所用的认证机制。当应用接收到解压缩的消息时，它将该消息映射到某个消息编组，并将消息编组标识符提供给SigComp。每个消息编组分配有一个单独的压缩器和用于存储状态信息的一定数量的存储空间，因此，应用必须将不同的消息编组指配给不同的远程端点。
因此，所述SigComp体系结构为应用和SigComp调度器设置了若干操作和实现要求。虽然旨在确保SigComp操作的稳健性，但这些要求同时妨碍了新应用的引入，期望更新调度器以与应用对应。此外，解压缩器调度器容易对在同一数据分组流上复用的未压缩应用消息的SigComp定界符和位模式进行误解释。这些缺点在可以容易地开发和引入新应用的开放平台环境，如为移动终端设计的Symbian OS中更严重。
根据优选实施例，这些问题可以通过简化的SigComp体系结构来解决，其中，将用于读取传输层数据分组流的主要责任分配给应用，而且仅在应用无法识别数据流内容时，才将这些数据分组馈送到称为SigComp子系统SCSS的简化SigComp实现中。
图2显示了SigComp子系统SCSS的结构。SCSS实现为执行与根据RFC 3320的SigComp体系结构兼容的任务，但SCSS忽略调度器的使用。因此，SCSS不包含朝向传输层的直接接口，而包含仅朝向应用层的接口。因此，SCSS可以视为从属于应用客户。
为了与客户通信(200)，SCSS包括SigComp API(应用编程接口)实现(202)，它负责从客户接收应用消息以便按照SigComp协议进行压缩，以及将SigComp压缩的应用消息馈送到客户，由客户将它们传到传输层以便传输。压缩在SigComp压缩器(204)如Deflate压缩器中进行，压缩器(204)最好作为插件引入SCSS中。因为压缩器的插件式体系结构，可以将新的压缩器动态添加到SCSS中。
为了进行解压缩，SCSS包括UVDM(206)。由此，SigComp API实现负责从客户(客户已从传输层数据流捕获到消息)接收以SigComp压缩的应用消息以及将UDVM解压缩的应用消息反馈给客户。压缩器的插件式体系结构未对UVDM设置任何其它要求，因为无论采用什么压缩器，压缩的数据总是与一组UVDM指令相结合，这允许UVDM提取原始数据。
再者，为了与SigComp完全兼容，SCSS包括作为另一个组件的状态处理器(208)。为了安全性的原因，客户的状态不应在对等方外揭示。因此，状态标识符应该总是采用加密算法予以加密。而且，SCSS还包括接口(210，Crypto API)，以便状态处理器和UVDM访问加密算法。
如果在Symbian OS中实现，则所述Crypto API接口(210)提供对Symbian OS安全管理功能的访问，其中提供多种加密和散列算法。对于Symbian OS实现方案，还可以在SCSS中包括一些附加接口来自Symbian OS的应用框架的插件框架API(212)，由此可以将新的压缩器实现引入到SCSS中(最好作为插件引入)；以及来自Symbian OS基层的文件服务器API(214)，它提供处理应用文件所需的内核、文件服务器、设备驱动器等。
如上所述，SCSS配置中不使用调度器。因此，也不会使用消息编组标识符。客户仅为特定端点的通信创建单独的消息编组类实例。图3说明了此情况，其中客户(300)仅创建CsigComp类(302)的一个实例及所需数量的CsigCompCompartment类(304)的实例。为了创建SigComp消息，CsigCompCompartment类实例知道应该用于压缩的压缩器(306)。该压缩器又知道状态处理器(308)，状态处理器(308)提供为建立有状态的通信端点而请求压缩服务的消息编组的状态。当客户创建CsigComp类实例时，它定义要使用的压缩算法，这加载特定的插件压缩器。客户还定义要使用的SigComp参数，例如存储器大小、每比特周期、解压缩存储器大小以及可选的包括静态字典。
为了进行解压缩，客户将接收到的SigComp消息转发到CsigComp类实例，并请求解压缩。CsigComp类实例调用UDVM(310)的一个实例，由其根据该消息包含的UVDM指令将所述消息解压缩。解压缩的消息被返回给CsigComp类实例，这允许客户保存或拒绝状态。解压缩的消息随后被返回到相应的应用。
因此，可以有利地避免使用调度器和消息编组标识符。可取的是，也不需要压缩器调度器所包括的路由表，该路由表中将消息编组标识符和压缩器链接一起。
下文将参考图4进一步说明SCSS的优点，其中SCSS的操作链接在OSI模型的应用层与传输协议层之间。为简洁起见，图4仅显示从第一端点(例如移动网络的用户设备UE1)到第二端点(例如移动网络的用户设备UE2)的单向应用消息流。显然，这种端点(如移动终端)通常可以采用双向SigComp消息传输。而且，显然在一个方向上使用SigComp压缩不一定意味着可以在反方向上进行压缩。在应用层上，仅显示了两个应用协议SIP和RTSP作为示例。同样地，在传输层上，仅采用TCP来例示实现方式。自然，所述实现方案并不限于这些协议。
所述实现方案基于如下原理应用(非SCSS)负责使用传输层。因此，SIP和RTSP都可以将含有应用特定消息定界符的未压缩应用消息(400，402，虚线箭头)直接传送到TCP层以便传输。但是，如果应用消息需要压缩(这在无线通信中通常是有益的)，则可以采用SigComp压缩。然后，SIP和RTSP均将它们未压缩的应用消息(404，406)传递到SCSS以便传输。SCSS返回含有SigComp定界符的SigComp消息(408，410，实线箭头)返回到客户，由客户将它们转发到TCP，以从第一终端UE1(412，414)发送。
在TCP层上，未压缩的应用消息(416)和SigComp压缩的消息(418)通常复用在同一个TCP流上进行传输。第二终端UE2接收TCP流，并将未压缩的消息(420，422)和以SigComp压缩的消息(424，426)转发到应用层。应用客户如SIP和RTSP知道它们自己的应用特定消息定界符并可以识别属于它们的消息。例如，SIP客户可以识别SIP消息的开始和结束，并确定消息的长度，从而可能混淆SIP消息中的二进制内容并不会导致任何误解释。
如果应用客户无法解释流的内容，则将数据分组流(428，430)转发并缓存到SCSS。SCSS试图识别含有SigComp定界符的任何SigComp消息，如果发现，则尝试将该消息解压缩。解压缩的应用消息(432，434)被返回到特定的应用客户。如果SCSS无法将该消息解压缩，则最可能的是数据流的内容被破坏或错发，即非SigComp消息。作为响应，SCSS将错误消息传递给客户。
要注意的是，上述压缩功能的操作不要求数据流中包含的SigComp消息应该用SCSS压缩，但对于所有SigComp消息的解压缩，SCSS完全兼容，只要这些消息是采用一组UVDM指令正确压缩的即可。
因此，提供了一种用于SigComp实现的既灵活又易于更新的配置。SCSS仅为应用客户提供利用SigComp压缩消息所需的必要元素。即使周围的配置(如应用客户)可能变更，上述核心SCSS配置也无需更新。例如，如果稍后引入了新的应用客户，仍并不需要SCSS的任何变化，因为应用客户配置为知道它们自己的应用特定消息定界符，因此可以读取TCP数据流。另一方面，由于采用了插件式体系结构，因此可以容易地将新的压缩器添加到核心SCSS。
SCSS的实现不受可以实现SCSS的软件操作系统的应用的限制。但是，如上所述，SCSS特别适用于各种开发平台系统，如SymbianOS(它是针对移动电话应用设计的开发操作系统)。无线通信中常常需要另外的应用消息压缩，并且Symbian OS提供灵活的应用开发框架，由此，将来会引入需要应用消息压缩的新应用。
Symbian OS是开放的、具有数据能力的2G、2.5G和3G移动电话的特定需求设计的操作系统。Symbian OS提供由所有Symbian OS电话共享的一组核心的应用编程接口(API)和技术。图5显示了Symbian OS版本7.0的关键特征。Symbian OS基层包括用于SymbianOS的所有其它组件的编程框架，即内核、用户库、文件服务器等。Symbian OS支持各种电话(例如GSM、W-CDMA)和其它通信服务(例如TCP、IP、HTTP)。各API可用于多媒体和安全功能。应用框架提供对用户界面应用的访问。个人局域网框架包括用于蓝牙、IR和USB应用的客户栈。
Symbian OS提供用于联系、调度、消息传送、浏览等的各种应用引擎以及用于数据管理、文本、剪切板和图形的集成API。消息传送功能包括多媒体消息传送(MMS)、增强消息传送(EMS)和SMS、电子邮件、文件附带和传真。Symbian OS的应用开发工具至少包括C++和Java。有关Symbian OS的更详细描述，可参见“Symbian版本7.0，功能描述”(″Symbian OS Version 7.0s，Functional description″，Rev.2.0，April 2003，(www.svmbian.com))。
应该注意，根据本发明的SCSS的功能元素最好可以实现为软件、硬件或它们的组合。SCSS特别适合于计算机软件实现，它包括用于控制例如用户终端的处理器和执行本发明的功能步骤的计算机可读命令。SCSS最好可以实现为存储在存储介质中的程序代码，并利用类计算机设备，如个人计算机(PC)或移动台来执行，以便为所述设备提供必需的SigComp功能。此外，本发明的SCSS功能可以作为软件更新加载到计算机上，由此可以在已知设备中建立根据本发明的功能。
为在Symbian OS兼容的用户设备(移动终端)中实施各种实施例，用于实施本发明的装置最好包括用于接收包含应用消息的传输层数据分组流的软件代码，至少所述应用消息之一根据SigComp压缩方法来压缩；用于将所述接收到的传输层数据分组流传送到至少一个应用客户的软件代码；用于识别发往所述至少一个应用客户的未压缩应用消息的软件代码；用于将未识别的应用消息传送到解压缩实体的软件代码，其中所述解压缩实体配置为识别根据SigComp压缩方法压缩的应用消息并将其解压缩；用于将根据SigComp压缩方法压缩的所述至少一个应用消息解压缩的软件代码；以及用于将解压缩的应用消息传递回所述至少一个应用客户的软件代码。
此外，所述装置最好可以包括如下软件代码用于从至少一个应用客户将至少一个应用消息传送到压缩实体的软件代码，其中所述压缩实体配置为根据SigComp压缩方法压缩应用消息；用于根据SigComp压缩方法压缩所述至少一个应用消息的软件代码；用于将所述至少一个压缩的应用消息传递回所述至少一个应用客户的软件代码；以及用于将所述至少一个压缩的应用消息传送到传输层，以形成传输层数据分组流的软件代码，其中所述传输层数据分组流包括根据SigComp压缩方法压缩的至少一个应用消息。
对本领域技术人员显而易见的是，随着技术进步，本发明的构思可以各种方式实现。因此本发明及其实施例并不限于上述示例，而是可以在权利要求的范围内变化。
权利要求
1.一种将应用消息解压缩的方法，包括接收包含应用消息的传输层数据分组流，至少所述应用消息之一根据信令压缩方法来压缩，所述方法的特征在于将所述接收到的传输层数据分组流传送到至少一个应用客户；识别发往所述至少一个应用客户的未压缩应用消息；将所述未识别的应用消息传送到解压缩实体，所述解压缩实体配置为识别根据所述信令压缩方法压缩的应用消息并将其解压缩；将根据所述信令压缩方法压缩的所述至少一个应用消息解压缩；以及将所述解压缩的应用消息传递回所述至少一个应用客户。
2.如权利要求1所述的方法，其特征在于所述信令压缩方法是SigComp压缩方法。
3.如权利要求1或2所述的方法，其特征在于通过消息定界符来识别所述未压缩的应用消息和根据所述信令压缩方法压缩的应用消息。
4.如权利要求1至3中任一项所述的方法，其特征在于提供从所述解压缩实体朝向仅所述至少一个应用客户的协议层接口。
5.如权利要求1至4中任一项所述的方法，其特征在于在所述至少一个应用客户中将所述解压缩的应用消息中的每一个链接到一个消息编组类实例。
6.如权利要求1至5中任一项所述的方法，其特征在于在Symbian OS中实现所述解压缩实体，由此至少提供从所述解压缩实体朝向Symbian OS的如下接口-朝向Symbian OS的安全管理功能的API；-朝向Symbian OS的应用框架的API；-朝向Symbian OS基层的API。
7.一种压缩应用消息的方法，包括从至少一个应用客户将至少一个应用消息传送到压缩实体，所述压缩实体配置为根据信令压缩方法压缩应用消息；根据所述信令压缩方法压缩所述至少一个应用消息；所述方法的特征在于将所述至少一个压缩的应用消息传递回所述至少一个应用客户；以及将所述至少一个压缩的应用消息传送到传输层，以形成传输层数据分组流，所述传输层数据分组流包括根据SigComp压缩方法压缩的至少一个应用消息。
8.如权利要求7所述的方法，其特征在于使所述压缩实体具备引入新压缩器的插件能力。
9.如权利要求7或8所述的方法，其特征在于在所述至少一个应用客户中创建标识用于与特定端点通信的压缩的应用消息的消息编组类；以及为每个压缩的应用消息分配消息编组类实例。
10.如权利要求7至9中任一项所述的方法，其特征在于所述信令压缩方法是SigComp压缩方法。
11.一种通信系统，包括用于压缩要在传输层上传输的应用消息的第一端点；以及用于将从所述传输层接收到的应用消息解压缩的第二端点；其中所述第一端点配置为，从至少一个应用客户将至少一个应用消息传送到压缩实体，所述压缩实体配置为根据信令压缩方法压缩应用消息；以及根据所述信令压缩方法压缩所述至少一个应用消息；以及所述第二端点配置为接收包含应用消息的传输层数据分组流，至少所述应用消息之一根据所述信令压缩方法来压缩；其特征在于所述第一端点配置为，将所述至少一个压缩的应用消息传递回所述至少一个应用客户；以及将所述至少一个压缩的应用消息传送到传输层，以形成传输层数据分组流，所述传输层数据分组流包括根据SigComp压缩方法压缩的至少一个应用消息；以及所述第二端点配置为，将所述接收到的传输层数据分组流传送到至少一个应用客户；识别发往所述至少一个应用客户的未压缩应用消息；将所述未识别的应用消息传送到解压缩实体，所述解压缩实体配置为识别根据所述信令压缩方法压缩的应用消息并将其解压缩；将根据所述信令压缩方法压缩的所述至少一个应用消息解压缩；以及将所述解压缩的应用消息传递回所述至少一个应用客户。
12.一种通信系统的终端，包括用于接收包含应用消息的传输层数据分组流的装置，至少所述应用消息之一根据信令压缩方法来压缩，其特征在于还包括用于执行如下步骤的装置将所述接收到的传输层数据分组流传送到至少一个应用客户；用于执行如下步骤的装置识别发往所述至少一个应用客户的未压缩应用消息；用于执行如下步骤的装置将所述未识别的应用消息传送到解压缩实体，所述解压缩实体配置为识别根据所述信令压缩方法压缩的应用消息并将其解压缩；用于执行如下步骤的装置将根据所述信令压缩方法压缩的所述至少一个应用消息解压缩；以及用于执行如下步骤的装置将所述解压缩的应用消息传递回所述至少一个应用客户。
13.一种通信系统的终端，包括执行如下步骤的装置从至少一个应用客户将至少一个应用消息传送到压缩实体，所述压缩实体配置为根据信令压缩方法压缩应用消息；用于执行如下步骤的装置根据信令压缩方法压缩所述至少一个应用消息；其特征在于还包括用于执行如下步骤的装置将所述至少一个压缩的应用消息传递回所述至少一个应用客户；以及用于执行如下步骤的装置将所述至少一个压缩的应用消息传送到传输层，以形成传输层数据分组流，所述传输层数据分组流包括根据SigComp压缩方法压缩的至少一个应用消息。
14.一种用于将应用消息解压缩的软件产品，包括用于接收包含应用消息的传输层数据分组流的软件代码，至少所述应用消息之一根据信令压缩方法来压缩，其特征在于还包括用于将所述接收到的传输层数据分组流传送到至少一个应用客户的软件代码；用于识别发往所述至少一个应用客户的未压缩应用消息的软件代码；用于将所述未识别的应用消息传送到解压缩实体，所述解压缩实体配置为识别根据所述信令压缩方法压缩的应用消息并将其解压缩的软代码；用于将根据所述信令压缩方法压缩的所述至少一个应用消息解压缩的软件代码；以及用于将所述解压缩的应用消息传递回所述至少一个应用客户的软件代码。
15.一种用于压缩应用消息的软件产品，包括用于从至少一个应用客户将至少一个应用消息传送到压缩实体的软件代码，其中所述压缩实体配置为根据信令压缩方法压缩应用消息；用于根据所述信令压缩方法压缩所述至少一个应用消息的软件代码；其特征在于还包括用于将所述至少一个压缩的应用消息传递回所述至少一个应用客户的软件代码；以及用于将所述至少一个压缩的应用消息传送到传输层，以形成传输层数据分组流的软件代码，其中所述传输层数据分组流包括根据SigComp压缩方法压缩的至少一个应用消息。
全文摘要
接收包含应用消息的传输层流并将其传递到应用客户，其中所述应用消息包括根据信令压缩方法压缩的应用消息；将未识别的应用消息传送到解压缩实体，所述解压缩实体配置为识别根据所述信令压缩方法压缩的应用消息并将其解压缩；将所述根据信令压缩方法压缩的应用消息解压缩并将其传递回应用客户。
文档编号H04L29/06GK1788420SQ03826583
公开日2006年6月14日 申请日期2003年6月6日 优先权日2003年6月6日
发明者P·梅斯考斯卡斯 申请人:诺基亚有限公司