CN101491054B - 信号压缩udvm性能优化的方法和装置 - Google Patents

Abstract

通信网络和无线用户设备之间的一种信号压缩优化系统，当能够减少内容处理延迟时其有利地选择优化解压缩器，否则选择用于解释所接收的解压缩字节码的虚拟机解压缩器，例如通用解压缩器虚拟机(UDVM)。由于UDVM并没有为任意特定的解压缩算法优化，并且会受到与在执行之前分析字节码中的每个语句相关的必要延迟的影响，所以如果能够尽可能避免使用UDVM，那么在呈现无线接收的信令消息或媒体内容时可增强用户体验。

Description

信号压缩UDVM性能优化的方法和装置

基于35U.S.C.§119要求优先权

本申请要求于2006年7月12日递交的、名称为“Method and Apparatusfor Optimization of SigComp UDVM Performance”、序号为60/830,545的临时申请的优先权，该临时申请已经转让给本申请的受让人，故以引用方式将其明确地并入本文。

背景技术

本发明涉及用于无线通信的压缩方法。

会话发起协议(SIP)是在开始于第三代合作伙伴计划(3GPP)第5版的第三代移动网络中用于呼叫控制的协议。SIP使用文本编码，使其更容易建立基于SIP的服务，设计针对SIP的扩展，以及调试协议。然而，SIP的文本编码还具有严重的缺点；公知的是，SIP消息明显大于例如用于全球移动通信系统(GSM)呼叫控制中的协议的那些消息。由于很多数据需要在低带宽无线电接口上发送，所以较大的消息尺寸会导致呼叫建立延迟增加。这使得需要开发出能够减少呼叫建立时间的方案。一种这样的方案是由互联网工程任务组(IETF)设计的信号压缩(SigComp)协议。SigComp在两个网络要素之间提供用于压缩应用层信令的框架。SigComp架构的中心部分是通用解压器虚拟机(UDVM)，它是为了运行解压缩算法而优化的虚拟机。由于UDVM的原因，SigComp可支持多种压缩算法，而不是指定单个算法由所有SigComp端点支持。

SigComp是3GPP第5版IP多媒体子系统(IMS)的必备部分。它应用于终端和代理呼叫会话控制功能(P-CSCF)之间的接口上，是用于IMS中的终端的第一接触点。SigComp通过减少呼叫建立时的空闲时间来增强用户感觉的服务质量。通过减少每个用户消耗的资源量还允许网络支持更多数量的用户。

SigComp的主要目标是蜂窝系统，在这种系统中移动终端具有变化的各种功能，并且在蜂窝链路上可能引入未被检出的错误。SigComp还对具有有限吞吐量的通信链路(包括蜂窝系统)进行寻址。

发明内容

下文给出对一个或多个实施例的简要概述，以提供对这些实施例的基本理解。该概述不是对全部预期实施例的泛泛概括，也不旨在标识全部实施例的关键或重要元件或者描述任意或全部实施例的范围。其目的仅在于作为后文所提供更详细描述的序言，以简化形式提供一个或多个实施例的一些概念。

本发明的一个方面提供一种传送数据内容的方法，所述数据内容通过多个压缩算法中的一个压缩算法进行压缩。每个压缩算法均具有能够从经压缩的数据内容再现数据内容的相应解压缩算法。为了提供较高的灵活性，将足以执行解压缩算法的字节码作为数据包协议的一部分与用于解压缩虚拟机的经压缩的数据内容一起发送，以解释字节码。为了通过减少解释解压缩算法所需的处理时间来增强用户体验，将与所检测的字节码相关的机器码中的解压缩算法的可访问可执行版本进行定位，并将其用于解压缩数据内容，而并非使用虚拟机。

在另一方面，至少一个处理器通过定位解压缩源代码的可执行版本来执行解压缩数据内容的方法。具体地，第一模块检测源代码。第二模块定位与源代码相关的解压缩算法的可访问可执行版本。第三模块利用所定位的解压缩算法的可访问可执行版本来解压缩经压缩的数据内容。

在另一方面，一种计算机程序产品具有计算机可读介质，其包含第一组代码，使得计算机检测在至少一条消息中包含的源代码。第二组代码使得计算机定位与所检测的源代码相关的相应解压缩算法的可访问可执行版本。然后，第三组代码使得计算机利用所定位的相应解压缩算法的可访问可执行版本来解压缩经压缩的数据内容。

在另一方面，用于先前将字节码编译成机器码的模块提供了非常高效的解压缩算法的执行。例如，利用信号压缩(SigComp)来压缩会话发起协议/会话描述协议(SIP/SDP)消息的这种方法将缩短消息处理及消息呼叫建立时间的延迟。

在一个实施方式中，提供一种机制，避免为解压缩所接收的每个SIP/SDP消息而执行通用解压缩虚拟机(UDVM)解释器。避免执行UDVM解释器减少了移动站上的计算需求，并降低了SIP/SDP处理的潜在延迟。这种方式降低了基于SIP呼叫流的呼叫建立/断开时间。

在另一方面，一种向通信设备传播互联网协议(IP)多媒体子系统(IMS)数据内容的方法包括：通过压缩算法来压缩所述IMS数据内容。该方法还包括：生成包含解压缩字节码的数据结构；向所述通信设备发送经压缩的IMS数据内容和解压缩字节码。此外，该方法包括：响应于来自所述通信设备的请求，向所述通信设备发送所述解压缩字节码的可执行版本。

在一个方面，用于向通信设备传播互联网协议(IP)多媒体子系统(IMS)数据内容的至少一个处理器，包括：第一模块，通过压缩算法来压缩所述IMS数据内容。所述至少一个处理器还包括：第二模块，用于生成包含解压缩字节码的数据结构；第三模块，用于向所述通信设备发送经压缩的IMS数据内容和解压缩字节码。此外，所述至少一个处理器包括：第四模块，响应于来自所述通信设备的请求，向所述通信设备发送所述解压缩字节码的可执行版本。

在又一方面，一种计算机程序产品，包括：具有多组代码的计算机可读介质。第一组代码使得计算机通过压缩算法来压缩互联网协议(IP)多媒体子系统(IMS)数据内容。第二组代码使得计算机生成包含解压缩字节码的数据结构。第三组代码使得计算机向通信设备发送经压缩的IMS数据内容和解压缩字节码。第四组代码使得计算机响应于来自所述通信设备的请求，向所述通信设备发送所述解压缩字节码的可执行版本。

在另一方面，一种向通信设备传播互联网协议(IP)多媒体子系统(IMS)数据内容的装置，包括：通过压缩算法来压缩所述IMS数据内容的模块。该装置还包括：用于生成包含解压缩字节码的数据结构的模块；以及用于向所述通信设备发送经压缩的IMS数据内容和解压缩字节码的模块。此外，该装置还包括：用于响应来自所述通信设备的请求，向所述通信设备发送所述解压缩字节码的可执行版本的模块。

为了实现上述目的和相关目的，一个或多个实施例包括下文将要充分描述和在权利要求中重点列明的各个特征。下文的描述和附图详细阐述了某些示例性方面，并表示可采用实施例原理的几个方式。当结合附图考虑时，其它优点和新颖性特征在以下具体实施方式中变得清楚，并且公开实施例旨在包括所有这些方面及其等同物。

附图说明

图1是用于与通信网络相通信的无线设备的信号压缩优化系统的框图。

图2是图1的系统的无线设备组件的一方面的示意图。

图3是图1的无线设备和通信网络的示图，其描述第三代合作伙伴计划(3GPP)第5版(5)网络架构的其它特征。

图4是用于图1的信号压缩优化系统的互联网协议(IP)多媒体子系统(IMS)实体的配置图。

图5是信号压缩(SigComp)端点的位置的框图。

图6是图5的SigComp端点的架构的框图。

图7是通过图1的系统实现的信号压缩优化方法的流程图。

图8是描述图1中无线设备操作的信号压缩优化序列的实施例示图。

图9是描述图1中无线设备操作的信号压缩优化序列的实施例示图。

图10是描述图1的信号压缩优化系统的实施例示图。

图11是描述图1的信号压缩优化系统的实施例示图。

图12是描述静态DEFLATE性能的图表。

图13是描述Lempel-Ziv-Storer-Szymanski(LZSS)压缩算法性能的图表。

具体实施方式

现在参照附图描述多个实施例。在下文的描述中，为了便于解释，给出了大量具体细节，以便提供对一个或多个实施例的全面理解。然而，很明显，也可以不用这些具体细节来实现所述实施例。在其它例子中，以方框图形式示出公知结构和设备，以便于描述这些实施例。

所述装置和方法特别适用于无线环境中，但是也可适用于任意类型的网络环境中，包括但不限于，通信网络、公共网络(例如因特网)、专用网络(例如虚拟专用网络)、局域网、广域网、远程输送网或任意其它类型的数据通信网络。

图1示出在通信网络12和无线用户设备(通信设备)14之间的信号压缩优化系统10的一个方面。在通信网络12中，压缩器18利用数据压缩算法20对描述成多媒体内容16的媒体或信令(例如音频、图像、视频、盲文等)(通称为“数据”)进行数据压缩。数据解压缩字节码22以适用于无线通信链路24无线传输的形式向用户设备14的无线通信链路28提供源代码或字节码(后面有压缩媒体内容26)。响应于所接收的字节码22，处理器30有利地选择优化的解压缩器32，同时方便于减少建立延迟量，以避免在每个实例中都使用虚拟机解压缩器。作为另一种选择，实施方式可具有优化的解压缩器32的不可访问的实例。然后，处理器30选择虚拟机解压缩器(描述为通用解压缩器虚拟机(UDVM)34)。UDVM 34具有可灵活执行(例如由接收的字节码22’指示的)多个解压缩算法的一般架构；然而UDVM 34并没有为任意特定的解压缩算法而优化，并且受到与在执行之前分析字节码22中的每个语句相关联的必要延迟的影响。

为了有利于避免这种执行延迟，处理器30识别出字节码22”的可访问副本与接收的字节码22’相同。然后，由优化的解压缩器32使用机器码36，机器码36是执行字节码’的可执行解压缩算法38的一部分。与在虚拟机中解释源代码(即字节码22’)相比，为了减少用于解压缩的时间，将机器码36和/或优化的解压缩器优化。由于能够尽可能地避免使用UDVM 34，因此用户设备14通过避免建立延迟，增强了在媒体内容播放器38上呈现媒体内容16时的用户体验。

应当理解的是，本发明的优点在于，机器码36可作为本地存储的程序库的一部分来进行访问，可被本地编译和存储用于以后使用，可以从远程程序库被无线访问，可以在请求时被远程编译并存储用于以后使用，和/或可作为并入优化的解压缩器中的固件或其它形式的电路来提供。在编译和/或远程编译机器码36时的延迟可以通过如下优势来弥补：降低无线用户设备14的复杂性需求和UDVM上的持续解压缩效率。

根据一些方面，通信设备14可包括任意类型的计算机化的通信设备。例如，如图1所示，通信设备14可包括移动通信设备，例如无线和/或蜂窝电话。作为另一种选择，通信设备14可包括固定通信设备，例如代理呼叫/会话控制功能(P-CSCF)服务器、网络设备、服务器、计算机工作站等。应当理解的是，通信设备14不限于本文描述或示出的设备，还可以包括个人数字助理(PDA)、双向文本寻呼机、具有有线或无线通信端口的便携式计算机以及具有有线和/或无线通信端口的任意类型的计算机平台。此外，通信设备14可以是远程从属设备或其它类似设备，例如远程传感器、远程服务器、诊断工具、数据中继器等，它们不具有终端用户，而是简单地在无线或有线网络之间传送数据。在其它方面，通信设备14可以是有线通信设备，例如固定电话、个人计算机、机顶盒等。此外，应当注意的是，可以在系统10中使用单种类型或多种上述类型的任意数量的通信设备14的任意组合。因此，本发明的装置和方法可以在包括有线或无线通信端口的任意形式的有线或无线设备或计算机模块(包括但不限于，无线调制解调器、个人计算机存储卡国际协会(PCMCIA)卡、访问终端、个人计算机、电话或其任意组合或子组合)上执行。

此外，通信设备14可包括用于诸如请求、交互和/或播放多媒体内容16之类目的的用户界面42。这种用户界面42包括：输入设备44，用于生成或接收进入通信设备14的输入；输出设备46，用于生成和/或呈现由通信设备14的用户使用的信息。例如，输入设备44可包括以下设备中的至少一个，例如：小键盘和/或键盘、鼠标、触摸屏显示器、与语音识别模块相关联的麦克风等。在某些方面，输入设备44可提供内容请求的用户输入或附加信息请求的用户输入。此外，例如，输出设备46可包括显示器、音频扬声器、触摸式反馈机构等。输出设备46可生成图形用户界面、声音、例如振动的感觉等，并且这种输出可以与例如多媒体内容16的呈现相关联(图1)。

此外，通信设备14可包括：计算机平台48，用于执行向设备提供功能的应用程序，还可以与输入设备44和输出设备46进行交互。计算机平台48可包括存储器50，包括易失性和非易失性存储器部分，例如只读和/或随机存取存储器(RAM和ROM)、可擦可编程只读存储器(EPROM)、电可擦可编程只读存储器(EEPROM)、闪存、和/或通用于计算机平台的任意存储器。此外，存储器50可包括有源存储器和记忆存储器，包括电子文件系统和任意二级和/或三级存储设备，例如磁介质、光学介质、磁带、软盘和/或硬盘和可移除式存储器组件。

此外，计算机平台48还可包括处理器52，其可以是专用集成电路(ASIC)或其它芯片组、处理器、逻辑电路或其它数据处理设备。在一些方面，例如当通信设备14包括蜂窝电话时，处理器52或其它逻辑设备(例如ASIC)可执行与存储器50中的任意固有软件组件(例如语音呼叫、数据呼叫和媒体相关应用)对接的应用程序接口(API)层54。API 54可以是在各种通信设备上执行的运行环境。一种这样的运行环境是由圣地亚哥，加利福尼亚的高通公司开发的无线二进制运行环境，即Binary RuntimeEnvironment for

软件。可使用其它运行环境，例如用于对无线计算设备上应用程序的执行进行控制。

此外，处理器52可包括以硬件、固件、软件及其组合实现的各种处理子系统56，其在通信网络28上支持通信设备14的功能以及通信设备的操作(图1)。例如，处理子系统56允许发起和保持通信，与其它网络连接设备以及通信设备14的组件中和/或之间交换数据。在一个方面中，例如在蜂窝电话中，处理器52可包括一个处理子系统56或其组合，例如：音响、非易失性存储器、文件系统、发射机、接收机、搜索器、层1、层2、层3、主控制器、远程过程、手机、电源管理、诊断、数字信号处理器、声音合成机、消息发送、呼叫管理器、蓝牙

系统、蓝牙

LPOS、位置确定、位置引擎、用户界面、休眠、数据服务、安全、认证、USIM/SIM(通用用户身份模块/用户身份模块)、语音服务、图形、USB(通用串行总线)、多媒体(例如MPEG(运动图像专家组)协议多媒体)、GPRS(通用分组无线业务)、短消息服务(SMS)、短语音服务(SVS^TM)、web浏览器等。对于公开的方面，处理器52的处理子系统56可包括与计算机平台48上执行的应用程序交互的任意子系统组件。

计算机平台48还包括通信模块58，其支持在通信设备14的各个组件之间的通信，以及用于在通信设备14和通信网络28(图1)之间交换内容24(图1)和内容请求。通信模块58可以在硬件、固件、软件和/或其组合中实现，还可包括用于设备间和设备内通信的所有协议。此外，通信模块58用于根据本文所述的装置和方法来发送和/或接收信息，例如请求多媒体内容16(图1)和接收压缩的媒体/信令内容28和字节码22’(图1)。

在一些方面中，通信设备14的存储器50还可存储用户界面模块60，其用于在后台或前台进程中在通信网络12之间检索、存储和播放多媒体内容16。用户界面模块40包括硬件、软件、固件、数据和用于执行这些功能的可执行指令的一个或任意组合，包括适用于多媒体内容16的类型和用户界面42的功能的多媒体播放器。

参照图3-6，举一个使用信号压缩优化系统10的示例性环境，公开一种网络架构100，用于执行由IP多媒体子系统(IMS)网络的第三代合作伙伴计划(3GPP)和3GPP2标准授权的并且在RFC 3320、RFC 3321和IMS的3GPP标准(例如3GPP TS 23.228)中定义的特定类型信号压缩(SigComp)。在图3中，通用的方法对移动通信设备(SIP用户代理)和代理呼叫/会话控制功能(P-CSCF)之间用无线电发送的SIP信令消息进行压缩。这包括压缩方，所述压缩方向解压缩方发送解压缩算法(作为所发送的第一消息的部分)。算法(字节码22’)接收的解压缩方(通信设备14)执行存储器50中的通用解压缩器虚拟机(UDVM)解释程序64，其解释所接收的字节码22’并解压缩随后的消息(压缩的媒体/信令内容28)。这种方式的优点是能够支持任意类型的算法，只要其字节码22用无线电提供即可。示例性版本的存储器50中的呼叫控制模块是定义用于该通信的协议的本地会话发起协议(SIP)和会话描述协议(SDP)应用66。

由于对字节码中的每个指令进行解释，所以在UDVM解释程序中执行字节码解压缩引起的计算开销导致延迟，这样会因为延长呼叫建立时间而影响用户体验。存储器50中的解压缩器分配模块68通过减少UDVM解释程序64的使用，采用通信设备14的计算机平台48支持的一种或多种优化实现方式来有利地减轻这种延迟。

在第一种实现方式中，通过存储器50中的优化解压缩器模块70执行的从字节码22到机器码的早期编译很高效地进行了解压缩算法，因此缩短了在SIP消息处理和呼叫建立时间以后的延迟。为此，解压缩器分配模块68访问解压缩程序库72，以便将接收的字节码22’与一个或多个本地可访问的字节码22”相比较，每个字节码22”与各自的解压缩机器码36相配对。在检测到匹配时，解压缩机器码36可通过优化的解压缩器模块70来执行，而非UDVM解释程序64执行。

在第二种实现方式中，对于解压缩器分配模块68没有检测到匹配的新接收的字节码22’而言，解压缩器分配模块68指示存储器50中的编译器74生成解压缩机器码36，随后将其连同字节码22’分别存储到解压缩程序库72的空代码存储记录76和空索引78中。这种编译可以在后台进行，从而可通过第一种实现方式来处理这种字节码22’的后续情况。

在第三种实现方式中，在如第二种实现方式所示没有检测到匹配时，解压缩器分配模块68转发字节码22’的请求，以便外部编译解压缩机器码或从周期性更新的数据库检索解压缩机器码用于后续情况。

在第四种实现方式中，计算机平台58有利地包括UDVM硬件处理器(例如数字信号处理器(DSP))80，其通过在为解压缩而优化的设备硬件中允许并行处理来促进快速设置。解压缩器分配模块68利用代理UDVM82，为了本地SIP/SDP应用66的利益来仿真UDVM 64。

在图3-6中，通常符合在3GPP TS 23.228、3GPP TS 23.002中描述的3GPP第五版(5)网络架构的通信网络100提供图1-2的信号压缩优化系统10的运行环境。具体参照图3，将通信网络100逻辑地划分成核心网络(CN)架构102和接入网络(AN)架构104。将CN架构102逻辑地划分成电路交换(CS)域106、分组交换(PS)域108和互联网协议(IP)多媒体子系统(IMS)110。描述为UMTS陆地无线接入网(UTRAN)接口104的AN架构104由分级无线网络子系统(RNS)112构成，其要素是无线网络控制器(RNC)114、节点B元件116和用户设备(UE)118。节点B 116是服务于一个或多个小区的逻辑网络组件。其是在无线电小区中用于通信的无线电发送/接收单元。RNC 114是具有用于控制一个或多个节点B元件116的功能的网络组件。RNC 114处理多个UTRAN接口104之间的协议交换。RNC 114提供无线网络子系统112的集中操作和维护，包括对操作支持系统(未示出)的访问。具体而言，RNC 114的功能包括无线电资源控制、准入控制、信道分配和切换控制。专用于电路交换域106的实体是信令网关(SGW)119、移动交换中心(MSC)120和网关移动交换中心(GMSC)122。CS交换域106还可包括受到这种类型信令限制的某些家庭用户服务123。MSC 120构成无线网络子系统112和固定网络之间的接口。GMSC 122是执行到移动站(用户设备(UE))118的实际地点的路由的MSC 120。专用于分组交换域108的实体是服务GPRS支持节点(SGSN)124和网关GPRS支持节点(GGSN)126。SGSN 124和GGSN 126处理分组流量。SGSN 124将分组传送到其服务区域内的移动站118。SGSN124执行移动管理功能，例如从一个小区中的用户设备118向另一小区中的设备切换漫游用户。GGSN 126用作外部IP网络(例如公共因特网128、其它移动服务提供商的GPRS服务(家庭用户服务(HSS))130或企业内联网(未示出))的接口。GGSN 126保存路由信息，所述路由信息是将协议数据单元(PDU)通过隧道传送到服务于特定移动站122的SGSN 124所必须的。

将IP多媒体子系统(IMS)核心网络110的IMS实体作为第三代伙伴计划(3GPP)第五版(5)的一部分，以创建根据移动互联网规范开发各种多媒体服务的公共平台。IMS实体包括用于提供IP多媒体(IM)服务的所有核心网络元件，例如呼叫会话控制功能(CSCF)130(即询问、代理和服务)、IMS媒体网关功能(MGW)131、媒体网关控制功能(MGCF)132和多媒体资源功能133。根据3GPP的IMS CN 110对功能标准化，而并非是对标准化接口限定的节点标准化。实现方式将两个功能自由组合到一个节点中，或将单个功能分到两个或更多个节点。IMS CN 110是这样的域，其控制语音以及多媒体呼叫和会话，并互连到其它网络(如公共交换电话网(PSTN)134)和其它UMTS网络(例如HSS 130)。它具有穿过不同路径的信令平面和媒体平面。

SigComp是IMS CN 110的一部分，用于压缩SIP信令流量。IP多媒体(IM)域能够降低成本，以及引入新的服务(例如语音电话、视频电话、多媒体会议、即时消息传送和实时互动游戏)。IMS能够为无线用户聚集和访问语音、视频、消息、数据和基于web的技术，以及将互联网的发展与移动通信的发展相结合。IP多媒体核心网络子系统(IMS)使其能够基于互联网应用、服务和协议为公共陆地移动网络(PLMN)操作者的用户提供多媒体服务，并建立于互联网应用、服务和协议上。它利用分组交换域来传送多媒体信令和载体流量。分组交换域在终端移动时维持服务并隐藏IMS的移动。IMS独立于电路交换域。IM域使得用户和应用程序能够控制多方之间的会话和呼叫。它控制和支持网络资源，以提供呼叫所需的功能、安全和质量。IM域提供用户的登记，从而他们可以从任意UMTS网络访问他们自己的服务。IM的一个附加角色是生成呼叫详情记录(CDR)，其包含发送和接收的关于呼叫参与者、时间、持续时间以及数据量的信息。CDR用于计费目的。

在图4中，根据3GPP TS 23.228的IMS实体包括CSCF、MGCF、IMS媒体网关功能(IMS-MGW)、多媒体资源功能控制器(MRFC)、多媒体资源功能处理器(MRFP)、签约定位功能(SLF)、出口网关控制功能(BGCF)和应用服务器(AS)，其中将支持用户业务的接口示为粗线，将支持信令的接口绘成虚线。

在3GPP TS 23.228中描述了IMS实体的角色。作为SIP服务器的CSCF可用作代理CSCF(P-CSCF)、服务CSCF(S-CSCF)138或询问CSCF(I-CSCF)。P-CSCF是对于IMS CN的UE的第一个接触点。P-CSCF对于SigComp也是特别重要，因为它是执行SigComp消息的压缩和解压缩的核心网络元件。为此，P-CSCF包括压缩器和解压缩器(IMS终端也包括两者)。S-CSCF处理网络中的会话状态，同时I-CSCF的角色是找到用于特定用户的适当S-CSCF。MGCF执行协议转换，接收带外信息，与CSCF通信，选择CSCF以及控制呼叫状态的部分。IMS-MGW中止来自交换电路网络的载体信道以及来自分组网络的媒体流。它处理媒体转换、载体控制和有效载荷处理。MRFC的任务是控制MRFP中的媒体流资源，生成CDR和解释来自AS和S-CSCF的信息，并据此控制MRFP。MRFP提供由MRFC控制的资源，控制在Mb基准点上的载体，合成资源，以及处理媒体流。SLF提供在登记和会话建立期间由I-CSCF发出请求时包含所需用户相关数据的HSS的名称。在登记处理期间，还通过S-CSCF来询问。BGCF选择要发生PSTN中断的网络以及选择被使用的MGCF。AS可以是SIP应用服务器、开放式服务存取(OSA)应用服务器或移动增强逻辑的客户化应用(CAMEL)IP多媒体服务交换功能(IM-SSF)。它提供增值IM服务。S-CSCF和AS之间的接口用于提供AS中的服务。

IP多媒体子系统试图符合互联网工程任务组(IETF)互联网标准，以实现存取独立，以及保持与横跨根据3GPP TS 23.228的互联网的多个有线终端的正常运转。在IM域中用于登记和呼叫控制的信令协议是会话发起协议(SIP)。SIP是在UE和CSCF之间采用的单独协议。

在图5中，用于压缩向终端发送的消息以及解压缩从终端接收的消息的实体是P-CSCF，所述消息描述为从UE到S-CSCF的SIP信令流。在UE中用SigComp压缩的SIP消息流经无线电接口、基站(BS)和UMTS陆地无线接入网(UTRAN)的无线网络控制器(RNC)。从UTRAN，这些SIP消息遍历服务GPRS支持节点(SGSN)和网关GPRS支持节点(SGSN)的所有路径到P-CSCF，在所述P-CSCF中对SigComp消息进行解压缩。从P-CSCF起，SIP消息以未压缩的方式发送。以下讨论从网络核心而并非从无线接入网选择用于执行SigComp压缩和解压缩的实体的原因。首先，传输加密和解密功能的位置同样影响压缩功能的位置，因为必须从加密和解密的点向外采用压缩，并且它必须是透明的。对某些传输类型的分组内容进行认证、完整性保护或加密。对来自终端的信息解密以及对到达终端的信息加密的可信方位于移动网络核心中。如果从无线接入网选择了端点，则网络设计和性能将受到在移动网络中传送消息密钥所带来的复杂性的影响。影响信号压缩位置的另一个重要方面是切换。在SigComp中，建立相对大量的历史状态，以支持高效压缩。如果执行解压缩的端点改变，则这个状态需要被传送至新的实体，以保持压缩效率。这种方案将增加网络的复杂性。当在P-CSCF中执行解压缩时，解压缩端点在应用层会话的持续时间内保持稳定。

因此，SigComp功能的位置位于移动终端中以及网络的内部，即在IMS中。这种方式与头部压缩方式形成对照，在所述头部压缩情况下压缩功能位于终端中以及无线接入网中。在SigComp的情况下，消息是不包含路由信息的应用层消息。它们承载于传输层协议的有效载荷中，留下对IP的路由问题。SigComp不压缩传输层协议的头部。仅有与传输层协议有效载荷的内容相关的实体(即两个传送端点)需要解压缩SigComp消息。

应当强调的是，在终端和P-CSCF之间以压缩形式发送SIP信令的原因并不是节省在空中接口上的少量字节。当终端将建立要使用很多带宽的多媒体会话时，并不值得节省少量的信令字节。压缩的主要动机是减少在空中接口上发送SIP消息所需的时间。

在IMS中，执行会话控制的协议是会话发起协议(SIP)。SIP初始用于邀请用户参加多媒体会议，但是如今它主要用于创建、修改和中止多媒体会议。尽管SigComp可用于压缩基于文本的任意协议的消息，但是目前主要集中在SIP消息的压缩。

SIP独立于要处理的多媒体会话的类型以及用于描述会话的机构。描述多媒体会话的最普通格式是会话描述协议(SDP)。SDP是在SIP消息体中承载的简单的文本格式。这是SigComp必须能够高效压缩SIP和SDP的原因。为此，定义SIP/SDP静态字典。

SIP协议定义几个实体，它们是用户代理(UA)、重定向服务器、代理服务器、登记器和位置服务器。支持3GPP第5版或以后版本的所有3G终端包含SIP UA。此外，3GPP2已采用SIP。SIP使用代理服务器来帮助对用户的当前位置的路由请求、认证和授权要服务的用户，实施提供商呼叫路由策略，以及向用户提供特征。重定向服务器通过提供用户可到达的可选位置在SIP UA的定位时提供帮助。登记器接受登记。它通常与重定向服务器或代理服务器是共处一区的。位置服务器不是SIP实体，但是它是使用SIP的任意架构的重要部分。位置服务器存储和返回用户的可能位置。

SIP是请求/响应协议，例如以其为基础的超文本传输协议(HTTP)。SIP用户代理客户端(UAC)发送请求，而用户代理服务器(UAS)返回响应。请求的开始行声明用于表示请求目的的方法名称。

图5中示出SigComp端点的布局。其包括以下实体：压缩器分配器、一个或多个压缩器、状态处理器、通用解压缩器虚拟机(UDVM)和解压缩器分配器。

压缩器分配器的任务是从应用接收消息，以及将每个消息的压缩版本传递至传输层。所述应用必须向压缩器分配器提供隔间标识符(即区块标识符，compartment identifier)以及每个消息。隔间是与对等端点相关的应用特定消息组。在SIP的情况下，隔间由属于SIP对话的所有消息构成。隔间标识符唯一地标识隔间。SigComp逐个隔间地调用压缩器，这意味着隔间标识符还可用于标识压缩器。为此，必须保持在隔间标识符和压缩器之间的映射。通过提供隔间标识符与应用消息，所述应用确保压缩器分配器可定位适当的压缩器。每次遇到新的隔间标识符时，调用新的压缩器。一旦压缩器已经压缩了应用消息，则创建SigComp头部，并将其附加至消息。之后，压缩器分配器将SigComp消息传递至传输层。当应用希望例如在接收BYE消息和发送最终响应之后闭合隔间时，应用向压缩器分配器指示这种情况。

压缩器实施用于压缩应用消息的某个压缩算法。SigComp的一个基本思想是标准不指定使用应该由所有端点使用的一个压缩算法。而是保留算法选择作为执行决定结果。随后是每个端点应该能够对各种压缩算法的输出进行解压缩。这可通过利用虚拟机来实施解压缩功能而实现。当压缩器创建包含压缩的应用消息的SigComp消息时，它包括用于消息头部的解压缩算法。这个解压缩算法称作字节码，并且已经将其编译成可在虚拟机上执行的格式。

对压缩器提出了多种需求。首先，它需要是透明的(例如，压缩器不发送使UDVM无法正确解压缩SigComp消息的字节码)。压缩器应该提供对应用消息的某种完整性格式的检查，以保证进行成功的解压缩。它必须保证可使用在远程端点可用的资源对消息进行解压缩。如果传输是基于消息的，则在用户数据报协议(UDP)的情况下，压缩器必须将每个应用消息精确地映射到一个SigComp消息。在传输是基于流，但是应用定义它自己的内部消息边界的情况下，压缩器同样应该将每个应用消息精确地映射到一个SigComp消息。

解压缩器分配器的角色是从传输层接收SigComp消息，调用UDVM的新实例来解压缩每个消息，以及将得到的未压缩的消息传递至应用。一旦应用接收到消息，则它将消息映射至隔间，并将隔间标识符返回至解压缩器分配器。然后，解压缩器分配器将标识符传递至状态处理器，它使用标识符来保存状态信息，并将反馈信息转发至适当的压缩器。通过提供隔间标识符，应用程序允许分配器进行此操作。

通用解压缩器虚拟机(UDVM)是解压缩SigComp消息的实体。通过在虚拟机上执行称作字节码的特定编译程序来执行解压缩处理。UDVM是特别类似于Java虚拟机的虚拟机，但是区别在于已经对UDVM进行优化，以便运行解压缩算法。在SigComp的情况下，编译成字节码的源代码称作UDVM组件，并且将对其进行编译的实体称作UDVM解释器。字节码可看作是UDVM的机器语言。

UDVM在选择如何压缩给定应用消息时具有灵活性：压缩器执行器具有选择其决定算法的自由。将压缩的数据与包含一组UDVM指令的字节码相组合。在SigComp消息的头部中承载这些指令，并且允许在接收端点提取原始数据。

因为SigComp可以在不安全的传输层上运行，所以逐个消息地调用UDVM的单个实例，以确保损坏的消息不影响以后消息的解压缩。然而，在解压缩处理期间，UDVM可调用状态处理器以访问现有状态。这样，解压缩先前消息的UDVM实例的状态可通过随后的UDVM实例来恢复。

当已经初始化UDVM时，UDVM可仅在请求时从解压缩器分配器接收另外的压缩数据，或从状态处理器接收状态信息。随着解压缩进行，UDVM将解压缩的数据输出至解压缩器分配器。当UDVM遇到消息末端时，向分配器指示这种情况，从而分配器向其提供隔间标识符。在状态创建请求中，将这个标识符传递至状态处理器。状态处理器使用隔间标识符将位置中的状态信息存储到为相应隔间保留的状态存储器中。UDVM还将可附加至SigComp消息的反馈信息转发至状态处理器。

UDVM周期是执行UDVM指令需要的CPU功率量的测量。UDVM周期极限用于限制可压缩SigComp消息中每个比特的UDVM周期的数目。必须监控字节码使用的周期量，因为恶意用户可能发送包含循环码的字节码。然而，周期极限仅减少引起的损害量，并不除去问题。

在SigComp中，解压缩器存储器的大小是可协商的。解压缩端将解压缩器存储器的大小通知给压缩端。默认大小是2千字节。为了提高压缩的效率，可使用4千或8千字节或甚至更大的存储器大小。将解压缩器存储器分成2部分，第一部分用于存储解压缩的消息。另一部分用于保存字节码的UDVM和循环缓冲器，其能够使用比UDVM存储器更多的状态。因为只要缓冲器充满，UDVM就可以开始在缓冲器的起点重写内容。

因为调用UDVM的分别的实例来解压缩到达的每条消息，所以需要一种方式来保留消息之间的信息。这是SigComp状态处理器的任务，其存储接收的SigComp消息之间的信息。通过状态处理器，因为相对于先前消息中包含的信息对消息进行了压缩，所以提高了压缩比。状态处理器能够在解压缩随后消息时创建用于访问的状态项目。状态项目通常包含UDVM实例的存储器的快照或未压缩的消息。

状态处理器逐个隔间地管理状态存储器。除了存储它们的状态项目之外，它还保持通过特定隔间创建的状态项目列表，并保证没有隔间超过其分配的存储器。

UDVM解释器是将UDVM指令和UDVM组件中列出的它们的操作数翻译成字节码格式的实体。UDVM翻译器将包含UDVM组件源代码的文件用作输入，并将其编译成可在虚拟机上执行的字节码。

通过所述的信号压缩优化系统10的运行环境，在图7中示出信号压缩优化方法400。为了清楚起见，将该方法依次分成方框402-412的通信网络(传播)部分，随后是方框414-420的通信设备(接收)部分。应当理解的是，该方法可包括多个实体，并且压缩的SIP/SDP数据内容的传播还可以从通信设备发送到通信网络。此外，通信网络或通信设备可代表具有传播功能的多个实体，在这些实体的各个组合中可发起、中继或中止传播。

在方框402处开始，通信网络可通过获取接收方通信设备的硬件/软件配置来有利地提高信号压缩优化系统10的多个方面。这需要综合数据库，其意味着在一系列的可能通信设备上保持最新，或特别用于支持本文公开的信号压缩优化系统10的其它方面的设备。这种数据可通过原始设备制造商(OEM)提供，或可经由与各个通信设备或分级实体相通信的SIP/SDP交互获得，所述分级实体支持多种这样的通信设备。在方框404，选择信号压缩算法，以及相应的解压缩源代码(字节码)。可以在知道接收方通信设备是否已本地访问字节码的可执行版本时而并非期望通信设备调用UDVM时，有利地做出选择。在方框406，通信网络编译与获取的硬件/软件配置相符合的字节码，以生成可执行机器码。这种编译可等待请求，然后被立即发送。在所示顺序中，在方框408，这种编译在请求之前进行，并且在发出请求时根据用于传播的字节码和配置进行索引。

在方框410，根据压缩算法来压缩数据内容(例如多媒体内容和/或信令)。然后，根据数据分组协议连同适用于在通信设备(移动终端)解释的选择源代码(“字节码”)一起发送经压缩的数据内容，以解压缩数据内容(例如多媒体、信令等)。在示例性实施方式中，在方框412，通信网络根据数据分组协议发送压缩的数据内容以及所选择的源代码(字节码)。

在方框414，通信设备无线地接收该传输。在方框416，检测所发送的字节码。在方框418，对与检测的字节码相关的解压缩码的可访问可执行版本进行定位，避免在虚拟机上使字节码的解释变慢。对可执行版本的访问在利用存储器执行之前需要本地或远程编译，用于以后使用。可执行版本需要利用数字信号处理或其它类型的硬件优化解压缩器，以避免使用UDVM解释器。在方框420，然后使用可访问可执行版本来解压缩经压缩的数据内容。

在图8-11，示出图7的方法的4种特定实施方式。首先，在图8，信号压缩优化装置500建立在这样的假设上，即要使用的一组压缩算法是预先已知的，并通过提供这些解压缩算法的机器码实施方式而合并到移动终端502中。在方框506中，在移动终端502上执行的信号压缩(SigComp)优化运算504将检测的解压缩字节码与通过代理呼叫/会话控制功能(P-CSCF)510在通信信道508上发送的SigComp消息相比较。如果在方框512中，SigComp优化运算504确定检测到精确匹配，则在方框514，执行机器码解压缩。然而，如果在方框512确定没有精确匹配，则在方框516，对用于解压缩的字节码调用通用解压缩器虚拟机(UDVM)解释器。本地SIP/SDP应用518接收初始由P-CSCF压缩的纯SIP/SDP消息。因此，如果(例如在漫游期间或在网络升级之后)由P-CSCF 510发送在方框512中没有识别出的算法，则移动终端502仍旧能够执行标准的UDVM解释器。

在图9，替换的信号压缩优化装置600需要SigComp优化运算604的“实时”编译，SigComp优化运算604在方框606中将从P-CSCF 610通过通信信道608接收的解压缩字节码与预编译算法列表相比较。如果在方框612中发现字节码匹配，则在方框614中使用预编译算法的相关机器码用于解压缩。如果在方框612中没有发现匹配，则在方框616中将字节码编译成机器码，然后执行方框614，在任一情况下将纯SIP/SDP消息提供给本地SIP/SDP应用618。因此，这种字节码被编译一次，并用于对所有随后会话发起协议(SIP)消息进行解压缩。在图9，通过在执行编译前一直等待来避免使用UDVM。该方法需要在目标处的字节码编译功能。在第一消息以后的所有消息都不会受到由执行UDVM解释器代码引起的任意低效处理。作为另一种选择，可在后台进行编译用于以后使用，同时调用用于当前通信的UDVM解释器。

在图10，另一个替换的信号压缩优化装置700扩展了对字节码的编译版本的使用，但是并不在目标处编译字节码，而是通过网络发送机器(例如编译)码。为了确保这种机器码兼容于当前移动设备，网络(SigComp服务器720)首先经由信道708使用SIP消息传送功能来检查移动终端702的硬件/软件版本号。换句话说，网络根据移动站的硬件/软件(HW/SW)信息来选择需要发送至移动站的适当机器码。将接收的机器码存储在移动站的永久存储器上，以避免随后重传相同的机器码。为此，在方框706中，SigComp优化运算704比较从P-CSCF 710通过通信信道708接收的解压缩字节码。如果在方框712确定字节码匹配，则在方框714执行预编译的机器码。如果在方框712中没有发现匹配，则从SigComp服务器720请求字节码的预编译版本，并将字节码添加到列表(方框716)。然后，机器码可用于执行，以在方框714中实现解压缩，从而向本地SIP/SDP应用722提供纯SIP/SDP消息。

在图11，又一替换的信号压缩优化装置800具有移动终端802，后者的解压缩器分配器804经由通信信道806从P-CSCF 808接收具有解压缩字节码的SigComp消息。移动终端802使用优化的硬件处理器810。代理UDVM 812通过特定字节码对硬件处理器810编程，然后发送在硬件处理器810中用于解压缩的SigComp消息。硬件处理器可以是为UDVM解释而编程的专用加速器或通用DSP。然后，由本地SIP/SDP应用812使用纯SIP/SDP消息。

这个系统和方法还可应用于网络端，以减少P-CSCF服务器的处理需求。

实施方式

可具有多种实施方式。可具有一些高级实现方式，例如一种方法，其中：网络将预编译的解压缩二进制码发送到移动站，需要来自架构卖方的一些支持，因此需要一些标准化的形式。因此，在一些实施方式中，可在标准(例如由3GPP/3GPP2或IETF(互联网工程任务组)标准组织创立的标准)中适当包括本文所述的方法和装置的至少某些特征。

实验结果

在运行一些标杆性UDVM性能之后，观察到以下内容：(1)相比于本地解压缩算法，UDVM解释器解压缩SIP消息慢20倍左右。(2)在大部分空闲的中央处理单元(CPU)上，UDVM在QUALCOMM MSM6800芯片组上的正常呼叫建立期间解压缩SIP消息的时间为大约100ms。这个时间随着改进的呼叫建立方案(例如使用PRACK(即，对临时响应的接收作出确认的SIP方法)或服务质量(QoS)先决条件)而增加。(3)提高压缩效率的较好压缩算法的引入将大大增加UDVM解压缩时间。总之，在CPU负载或复杂SIP呼叫建立流的情况下，本发明可潜在地减少呼叫建立时间至少100ms或者更多。

图12-13示出在SURF 6800用户单元基准设计板上的简单UDVM算法的性能结果。具体地，图12-13分别是静态DEFLATE和Lempel-Ziv-Storer-Szymanski(LZSS)解压缩算法的图表。LZSS和DEFLATE算法是标准的、已知的压缩系统。DEFLATE是使用Lempel-Ziv 1977(LZ77)算法和哈夫曼编码组合的数据无损耗压缩算法，并且初始由Phil Katz在他的PKZIP归档工具第2版中定义，随后在RFC 1951中指定。尽管LZSS压缩是基准程序的算法之一，但是本发明不需要任意特定的压缩算法。示例性候选项是动态DEFLATE。然而，DEFLATE算法的复杂性大于LZSS，这意味着性能的降低可能大于DEFLATE的实施。

用于执行本申请所述功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件或者其任意组合，可以实现或执行结合本申请的实施例所描述的各种示例性的逻辑、逻辑框图、模块和电路。通用处理器可以是微处理器，或者，该处理器也可以是任何常规的处理器、控制器、微控制器或者状态机。处理器也可能实现为计算设备的组合，例如，DSP和微处理器的组合、多个微处理器、一个或多个微处理器与DSP内核的结合，或者任何其它此种结构。

此外，结合本申请的实施例所描述的方法或者算法的步骤可直接体现为硬件、由处理器执行的软件模块或两者的组合。例如，方法的步骤可体现在用于执行各个方法步骤的处理器的一个或多个模块中。软件模块可以位于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质连接至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。作为另一种选择，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。该ASIC可以位于用户终端中。作为另一种选择，处理器和存储介质也可以作为分立组件存在于用户终端中。此外，方法或算法的步骤可体现在包括计算机可读介质的计算机程序产品中，计算机可读介质具有用于使得计算机执行各个方法步骤的一组或多组指令。

再参照图1，通信网络12可包括任意数据和/或语音通信网络。例如，通信网络28可包括以下内容的任一个或任意组合中的所有或某部分，即：有线或无线电话网络；陆地电话网络；卫星电话网络；红外网络，例如基于红外数据协会(IrDA)网络；近距离无线网络；蓝牙技术网络；

协议网络、超宽带(UWB)协议网络；家庭射频(HomeRF)网络；共享无线接入协议(SWAP)网络；宽带网络，例如无线以太网兼容联盟(WECA)网络、无线保真联盟(Wi-Fi联盟)网络和802.xx网络；分组数据网络；数据网络；互联网协议(IP)多媒体子系统(IMS)网络；公共交换电话网；公共异构通信网，例如互联网；专用通信网；多播网络，例如仅前向链路(FLO)网络，包括圣地亚哥，加利福尼亚的高通公司的MediaFLO^TM系统；数字视频广播(DVB)网络，例如用于卫星的DVB-S、用于电缆的DVB-C、用于陆地电视的DVB-T、用于手持设备的陆地电视的DVB-H；和陆地移动无线电网络。

此外，在通信网络28的一些方面中包括的电话网络的实例包括模拟和数字网络/技术中的一个或任意组合的至少一部分，例如：码分多址(CDMA)、宽带码分多址(WCDMA)、通用移动电信系统(UMTS)、高级移动电话服务(AMPS)、时分多址(TDMA)、频分多址(FDMA)、正交频分多址(OFDMA)、全球移动通信系统(GSM)、单载波(1X)无线传输技术(RTT)、仅演进数据(EV-DO)技术、通用分组无线业务(GPRS)、增强数据GSM环境(EDGE)、高速分组接入(HSPA)、模拟和数字卫星系统以及可以在无线通信网络和数据通信网络中的至少一个中使用的任意其它技术/协议。

尽管已经示出和描述了各个公开方面，但是应当清楚的是，本申请的主题不仅限于这些方面。

例如，为了简洁起见，通信设备14被描述为接收(解压缩)多媒体内容16。与本发明的多个方面一致的应用需要这种多媒体内容的反向或双向传输。例如，通过通信设备14上存储的静态数码相机或摄像机等生成的多媒体内容可上传到通信网络12。此外，通信网络12可响应于由通信设备14提供的字节码的检测，然后利用相同的字节码和相应的压缩算法，将多媒体内容16发送到通信设备14。因此，在不需要采用UDVM解释器62的情况下，通信设备14可增加接收优化的解压缩技术支持的多媒体内容16的可能性。

因此，尽管以上公开内容示出示例性方面，但是应注意到，在不脱离由所附权利要求书定义的多个方面的范围的情况下，可以进行各种修改和改变。此外，尽管以单数形式描述或主张了所述多个方面的元素，但是也可以假设成复数，除非清楚地陈述了对单数形式的限制。

此外，尽管对于几个实施方式中的仅其中一个公开了特定特征，但是这个特征可以与其它实施方式中的一个或多个其它特征组合，这对于任意给定或指定应用是期望的和有利的。从某种意义上，在具体实施方式或权利要求书中使用了术语“包括”、和“包含”及其变型，这些术语旨在以类似于术语“包含”的方式包括。此外，在具体实施方式或权利要求书中使用的术语“或”意味着“非排他性或”。

此外，尽管以单数形式描述或主张了多个方面和/或版本的要素，但是也可以假设成复数，除非清楚地陈述了对单数形式的限制。此外，任意方面和/或版本的全部或一部分可通过任意其它方面和/或版本的全部或一部分来使用，除非具体陈述了其它情况。

Claims (21)

1.一种传送数据内容的方法，所述数据内容通过多个压缩算法中选择的一个压缩算法加以压缩，所述压缩算法中的每一个压缩算法均具有能够从经压缩的数据内容再现所述数据内容的相应解压缩算法，所述经压缩的数据内容经由数据分组协议传输，所述数据分组协议包括用于传输适用于解释以执行所述相应解压缩算法的解压缩源代码的至少一条消息，所述数据分组协议还包括具有所述经压缩的数据内容的至少一条消息，该方法包括：

检测所述至少一条消息中的源代码；

定位与所检测的源代码相关的相应解压缩算法的可访问可执行版本，其中定位包括访问本地解压缩程序库，以便将接收的字节码与一个或多个本地可访问的字节码相比较，每个本地可访问的字节码与各自的解压缩机器码相配对；以及

利用所定位的相应解压缩算法的可访问可执行版本来解压缩所述经压缩的数据内容。

2.如权利要求1的方法，还包括：

调用虚拟机以解释相应源代码，从而如果没有成功定位与所检测的源代码相关的所述相应解压缩算法的可访问版本，则解压缩所述经压缩的数据内容。

3.如权利要求1的方法，还包括：

如果没有成功定位与相应源代码相关的所述相应解压缩算法的可访问可执行版本，则将所检测的源代码编译成机器码；以及

创建可访问的数据结构，其包含由所检测的源代码来索引的机器码。

4.如权利要求1的方法，还包括：

从远程实体请求所检测的源代码的可执行版本；以及

从所述远程实体接收所检测的源代码的可执行版本。

5.如权利要求4的方法，还包括：

确定可执行版本要发往的预期处理器的配置，以及为所述预期处理器编译所述源代码。

6.如权利要求1的方法，还包括：

在第一处理器中调用代理虚拟机，所述第一处理器将指令从所检测的源代码和所述经压缩的数据内容发送到第二处理器；以及

呈现由所述第二处理器解压缩的数据内容。

7.如权利要求1的方法，还包括：

检测所述源代码和解压缩所述经压缩的数据内容包括接收和解压缩作为第三代合作伙伴计划(3GPP)分组数据传输的一部分、符合数据分组协议的信号压缩(SigComp)。

8.如权利要求1的方法，其中，所述数据内容包括多媒体或信令内容，该方法还包括：以用户能识别的形式呈现所述数据内容。

9.如权利要求1的方法，还包括：

无线地接收数据分组传输。

10.如权利要求1的方法，还包括：

接收会话发起协议/会话描述协议(SIP/SDP)数据分组传输。

11.一种用于接收经压缩的互联网协议(IP)多媒体子系统(IMS)数据内容的装置，在数据分组通信信道中伴随有解压缩字节码，该装置包括：

所述解压缩字节码的可执行版本；

解压缩器分配器，用于检测所述解压缩字节码，访问所述解压缩字节码的可执行版本，其中访问所述可执行版本包括访问本地解压缩程序库，以便将接收的字节码与一个或多个本地可访问的字节码相比较，每个本地可访问的字节码与各自的解压缩机器码相配对；

优化解压缩器，用于执行所述解压缩字节码的可执行版本，以将经压缩的IMS数据内容处理成纯SIP/SDP消息；

本地会话发起协议/会话描述协议(SIP/SDP)应用，用于接收所述纯SIP/SDP消息。

12.如权利要求11的装置，还包括：通用解压缩器虚拟机(UDVM)，其中，如果接收的第二解压缩字节码与第一可执行版本不相关，则所述解压缩器分配器调用所述UDVM，以便解释所述解压缩字节码。

13.如权利要求11的装置，还包括：编译器，其中，如果检测到第二解压缩字节码而非第一解压缩字节码，则所述解压缩器分配器指示所述编译器生成与所述第二解压缩字节码相关的第二可执行版本。

14.如权利要求11的装置，其中，网络设备与所述装置进行SIP/SDP通信，如果检测到第二解压缩字节码而非第一解压缩字节码，则所述解压缩器分配器请求和接收与所述第二解压缩字节码相关的第二可执行版本。

15.如权利要求11的装置，还包括：

代理通用解压缩器虚拟机(UDVM)；和

与所述代理UDVM对接的硬件实现的UDVM，用以解释所述解压缩字节码以及解压缩所述经压缩的IMS数据内容。

16.至少一个处理器，用于传送数据内容，所述数据内容通过多个压缩算法中选择的一个压缩算法加以压缩，所述压缩算法中的每一个压缩算法均具有能够从经压缩的数据内容再现所述数据内容的相应解压缩算法，所述经压缩的数据内容经由数据分组协议传输，所述数据分组协议包括用于传输适用于解释以执行所述相应解压缩算法的解压缩源代码的至少一条消息，所述数据分组协议还包括具有所述经压缩的数据内容的至少一条消息，所述至少一个处理器包括：

第一模块，用于检测所述至少一条消息中的源代码；

第二模块，用于定位与所检测的源代码相关的相应解压缩算法的可访问可执行版本，其中定位包括访问本地解压缩程序库，以便将接收的字节码与一个或多个本地可访问的字节码相比较，每个本地可访问的字节码与各自的解压缩机器码相配对；和

第三模块，利用所定位的所述相应解压缩算法的可访问可执行版本来解压缩所述经压缩的数据内容。

17.一种装置，包括：

用于检测包含在会话发起协议/会话描述协议(SIP/SDP)数据分组通信中的字节码的模块；

用于定位与所检测的源代码相关的相应解压缩算法的可访问可执行版本的模块，其中定位包括访问本地解压缩程序库，以便将接收的字节码与一个或多个本地可访问的字节码相比较，每个本地可访问的字节码与各自的解压缩机器码相配对；和

利用所定位的所述相应解压缩算法的可访问可执行版本来解压缩经压缩的数据内容的模块。

18.一种向通信设备传播互联网协议(IP)多媒体子系统(IMS)数据内容的装置，该装置包括：

压缩器，其利用压缩算法来压缩所述IMS数据内容；

数据结构，包含解压缩字节码；

数据分组通信信道，向所述通信设备发送经压缩的IMS数据内容和解压缩字节码；和

处理器，响应于来自所述通信设备的请求，获取所述通信设备的配置，以选择适用于所述通信设备的所述解压缩字节码的可执行版本并向所述通信设备发送所述解压缩字节码的可执行版本，其中，将与获取的配置相符合的解压缩字节码编译到可执行机器码中以生成所述数据结构。

19.一种向通信设备传播互联网协议(IP)多媒体子系统(IMS)数据内容的方法，包括：

获取所述通信设备的配置，以选择适用于所述通信设备的解压缩字节码的可执行版本；

利用压缩算法来压缩所述IMS数据内容；

生成包含所述解压缩字节码的数据结构，其中，将与获取的配置相符合的解压缩字节码编译到可执行机器码中以生成所述数据结构；

向所述通信设备发送经压缩的IMS数据内容和解压缩字节码；并且

响应于来自所述通信设备的请求，向所述通信设备发送所述解压缩字节码的可执行版本。

20.至少一个处理器，用于向通信设备传播互联网协议(IP)多媒体子系统(IMS)数据内容，包括：

第一模块，用于获取所述通信设备的配置，以选择适用于所述通信设备的解压缩字节码的可执行版本；

第二模块，用于利用压缩算法来压缩所述IMS数据内容；

第三模块，用于生成包含解压缩字节码的数据结构，其中，将与获取的配置相符合的解压缩字节码编译到可执行机器码中以生成所述数据结构；

第四模块，用于向所述通信设备发送经压缩的IMS数据内容和解压缩字节码；和

第五模块，用于响应来自所述通信设备的请求，向所述通信设备发送所述解压缩字节码的可执行版本。

21.一种向通信设备传播互联网协议(IP)多媒体子系统(IMS)数据内容的装置，包括：

用于获取所述通信设备的配置，以选择适用于所述通信设备的解压缩字节码的可执行版本的模块；

用于利用压缩算法来压缩所述IMS数据内容的模块；

用于生成包含所述解压缩字节码的数据结构的模块，其中，将与获取的配置相符合的解压缩字节码编译到可执行机器码中以生成所述数据结构；

用于向所述通信设备发送经压缩的IMS数据内容和解压缩字节码的模块；和

用于响应来自所述通信设备的请求，向所述通信设备发送所述解压缩字节码的可执行版本的模块。

Images