TW200824386A - Method and apparatus for optimization of sigcomp UDVM performance - Google Patents

Abstract

A signal compression optimization system between a communication network and wireless user equipment advantageously selects an optimized decompressor when feasible for reduced content processing latency and otherwise selects a virtual machine decompressor, such as a Universal Decompressor Virtual Machine (UDVM) that interprets the received decompression bytecode. Since the UDVM is not optimized for any particular decompression algorithm and suffers by the requisite delays associated with analyzing each statement in the bytecode before execution, being able to avoid use of the UDVM whenever possible enhances user experience in presenting wirelessly received signaling messages or media content.

Description

200824386 IX. Description of the Invention: TECHNICAL FIELD OF THE INVENTION The present invention relates to a compression method for wireless communication. [Prior Art] The Session Initiation Protocol (SIP) is an agreement for call control in a third generation mobile network originating from the Third Generation Partnership Project (3GPP) Release 5. SIP uses text-based coding, which makes it easier to build SIP-based services, design extensions to SIP, and debug the protocol. However, SIP's word encoding also has a serious drawback; it is well known that SIP messages are significantly larger than those used for, for example, Global System for Mobile Communications (GSM) call control protocols. Since more information needs to be transmitted via the low frequency wide radio interface, large message sizes result in increased call setup delays. This observation creates a need to develop a solution that reduces call setup time. One such solution is the Signal Compression (SigComp) protocol designed by the Internet Engineering Task Force (IETF). SigComp provides a framework for compressing application layer signals between two network elements. The central part of the SigComp architecture is the Universal Decompression Virtual Machine (UDVM), which is a virtual machine optimized for performing decompression algorithms. Because of UDVM, SigComp supports a wide range of compression algorithms rather than indicating a single algorithm supported by all SigComp endpoints.

SigComp is a mandatory part of the 3GPP Release 5 IP Multimedia Subsystem (IMS). It is applied to the interface between the terminal and the Proxy Call Session Control Function (P-CSCF), which is the first point of contact for the terminal in the IMS. By reducing idle time during call setup, SigComp improves user-awareness. 122807.doc 200824386 also allows for web-based quality. A larger number of users are assisted by reducing the amount of resources each user consumes.

The main target of SigComp is the hive. The nested system, in which the mobile terminal has different performance and can enter undetected errors on the cellular key. s”gC〇mp also handles communication links with limited throughput, including cellular systems. [Summary of the Invention]

The following is presented - a simplified overview to provide a basic understanding of some of the disclosed versions. This Summary is not an extensive overview, and is not intended to identify a singular or singular element, and is not intended to be a limitation of the present invention. : The pattern is intended to convey the data in the valley compressed by one of the large number of compression algorithms. Each compression-derivative method has a corresponding decompression algorithm capable of reproducing the content of the data from the compressed data content. In order to give an added spirit, the byte code that is sufficient to perform the decompression algorithm is used as a data packet protocol. The partial consent is to be used to decompress the virtual machine to interpret the compressed data content of the byte code - from transmission. In order to enhance the user experience by reducing the processing time required to interpret the decompression algorithm, an accessible executable version of the decompression algorithm in the machine code associated with the bit code is located and used for Unpack the data instead of using a virtual machine. In addition, at least one processor is configured to perform decompression of the data content by locating the executable version of the decompressed original code, and detecting the source code. The second module locates one of the 122807.doc 200824386 decompression algorithms associated with the source code to access the executable version. The third module decompresses the compressed data content using the accessible executable version of the decompression method. In an additional aspect, a computer program product has a computer readable medium containing a first set of code codes for causing a computer debt to measure at least one of the source code contained in the message. The second set of codes allows the computer to locate one of the corresponding decompression algorithms associated with the detected source code to access the executable version. Next, the third set of code uses the located accessible executable version of the corresponding decompression algorithm to cause the computer to decompress the compressed data content. In yet another aspect, a component that compiles the bytecode earlier into machine code provides very efficient execution of one of the decompression algorithms. For example, using this method with session initiation protocol/session description protocol (SIP/SDP) messages compressed using signal compression (SigComp) will shorten the processing latency and call setup time of the message. In one implementation, a mechanism is provided to avoid performing a Universal Decompression Virtual Machine (UDVM) interpreter for decompressing each SIP/SDP message received. Avoid performing UDVM interpreters to reduce the computational demands on the mobile station and reduce potential delays in SIP/SDP processing. This method reduces the call setup/disassembly time of the SIP-based call flow.

In another aspect, a method for propagating Internet Protocol (IP) Multimedia Subsystem (IMS) data content to a communication device includes compressing IMS data content using a compression algorithm. The method further includes generating a data structure including a decompressed byte code, and transmitting the compressed IMS 122807.doc 200824386 data content and decompressing the byte code to the communication device. Additionally, the method includes transmitting one of the decompressed byte codes in response to the request from the communication device

Row version to communication device D. In one aspect, at least one processor configured to propagate Internet Protocol (IMS) multimedia content (IMS) data content to the communication device includes using a compression algorithm The first module that compresses the contents of the IMS data. The at least one processor further includes a first module for generating a data structure including a decompressed byte code, and a first module for transmitting the compressed IMs data and the decompressed byte code to the communication device The third module. Additionally, the at least one processor includes a fourth module that transmits an executable version of the decompressed byte code to the communication device in response to a request from the communication device. In another aspect, a computer program product includes a computer readable medium containing a plurality of sets of code. The first set of code is used to cause a computer to compress Internet Protocol (IP) Multimedia Subsystem (IMS) data content using a compression algorithm. The second set of code is used to cause the computer to generate a data structure containing the φ decompressed byte code. The third set of code is used to cause the computer to transmit the compressed IMS data content and decompress the byte code to the communication device. And the 'fourth code set is used to cause the computer to transmit an executable version of the decompressed byte code to the communication device in response to a request from the communication device. In another aspect, an apparatus for propagating Internet Protocol (IP) Multimedia System (IMS) data content to a communication device includes means for compressing IMS data content using a compression algorithm. The apparatus also includes means for generating a data structure containing a decompressed byte code, and transmitting the compressed IMS data content and decompressing the byte code to a universal device using 122807.doc -9-200824386 . Additionally, the apparatus includes means 0 for transmitting the decompressed byte code - the executable version to the communication device in response to the request from the communication device;

To achieve the foregoing and related ends, one or more versions include the features specifically identified in the following description of the patent application. The following description and the annexed drawings set forth some of the various aspects of the various aspects of the various aspects of the embodiments. Other advantages and novel features will be apparent from the following description, which is intended to be included in the following description. [Embodiment] Various aspects will now be described with reference to the drawings. In the following description, numerous specific details are set forth for the purpose of illustration However, it will be apparent that various aspects may be practiced without such specific details. In other instances, well-known structures and devices are shown in block diagram form in a concise description. The apparatus and method are particularly suitable for use in a wireless environment, but are adaptable to any type of network environment, including but not limited to communication networks, public networks such as the Internet, such as virtual private networks (VpN). Private network, regional network, wide area network, long-haul network, or any other type of data communication network. Figure 1 illustrates one aspect of a signal compression optimization system 1 between a communication network 12 and a wireless user equipment (communication device) 14. The media or signals depicted as multimedia content 16 within the communication network (eg, tone 122807.doc 200824386, video, tfl, Braille, etc.) (generally, data) are experienced by a compressor 18 The data compression is performed using a data compression algorithm. The one or two decompression byte codes 22 compress the source code or the byte code in a form suitable for wireless transmission by the wireless communication link 24. The media content "provides to the user a wireless communication link 26 that is not ready 14. A processor 3 有利 responds to the received byte code 22 and advantageously selects a best-fit decompressor 32 when it is convenient to reduce the setup latency to avoid using a virtual machine decompressor in each instance. Alternatively, an implementation may have an example of an inaccessible one optimized decompressor 32. The caller 30 can then select a virtual machine decompressor, which is depicted as a Universal Decompression Virtual Machine (UDVM) 34. The UDVM 34 has a general architecture that flexibly performs a range of decompression algorithms (such as indicated by the received byte code 22'); however, the UDVM 34 is not optimized for any particular decompression algorithm and The necessary delay associated with analyzing each of the sentences in the byte code 22 is experienced prior to execution. To perform the advantageous avoidance of such execution delays, the processor 3 recognizes that the accessible copy of the byte 10 code 22 is the same as the received byte code 22. The machine code 36 as part of the executable decompression algorithm 38 for executing the byte code is then used by the optimized decompressor 32. The machine code 36 and/or the optimized decompressor are optimized for the decompression time of the subtraction compared to the interpretation of the source code in the virtual machine (i.e., the byte code 22). Since the UDVM 34 can be avoided whenever possible, the user device 14 enhances the user experience of presenting the media content 16 on the media content player 38 by avoiding delay establishment. It should be appreciated that the benefit of the present disclosure is that machine code 36 can be accessed as part of the local storage 122807.doc -11-200824386 library, can be locally compiled and can be stored for future use, and can be wireless from a remote library. The access is remotely compiled upon request and can be stored for future use, and/or can be provided as a firmware or other form of circuitry incorporated into an optimized decompressor. The delay in compiling and/or remotely compiling machine code 36 will be offset by the reduced complexity requirements and ongoing decompression efficiency of the wireless consumer device. According to some grievances, the communication device 14 can include any type of computerized communication device. For example, as illustrated in Figure 1, communication device 14 can include a mobile communication device, such as a wireless and/or cellular telephone. Alternatively, the device 14 may include a fixed communication device such as a Proxy Call/Join Control Function (P-CSCF) server, a network device, a server, a computer workstation, and the like. It should be understood that the communication device 14 is not limited to the devices described or illustrated herein, but may further include a number of person assistants (PDAs), a two-way pager, a portable computer having a wired or wireless communication portal, and having a wired and/or Any type of computer platform for wireless communication portals. In addition, the 'pass' δ 14 can be a remote slave device or other similar device that simply communicates data over a wireless or wired network without its end user, such as a remote sensor, a remote server, Diagnostic tools, data repeaters, and the like. In alternate modes, communication device 14 can be a wired communication device such as a landline telephone, a personal computer, a video converter, or the like. Additionally, please note that any number Any combination of a single type or a plurality of communication devices 14 of the foregoing type may be used in the system 1. Accordingly, the apparatus and method may correspondingly be in any form of wired or wireless device or computer module (including a wired or wireless communication portal) , including (but not limited to) wireless 122807.doc •12· 200824386

A data machine, a personal computer memory card (Pcmcia) card, an access terminal, a personal computer, a telephone, or any combination or sub-combination thereof; and, in addition, the communication device 14 can include a user interface 42 It is used for purposes such as requesting multimedia content 16, interacting with multimedia content 16, and/or playing multimedia content 16. The user interface includes - an input device 44 operable to generate or receive - to the input device in the communication device 14, and - operable to generate and/or present an output of information for consumption by a user of the communication device 14 Device 46. For example, input device 44 can include at least one device such as a keypad and/or keyboard, a mouse, a touch-sensitive display, a microphone combined with voice recognition, and the like. In some aspects, input device 44 can provide user input requesting content or requesting additional information. In addition, for example, output device 46 can include a display, an audio speaker, a tactile feedback mechanism, and the like. Output device 46 can generate a graphical user interface, a sound, a feeling such as vibration, and the like, and such outputs can be associated, for example, with the presentation of multimedia content 16 (Fig. 1). In addition, communication device 14 can include a computer platform 48 that is operative to execute an application to provide functionality to the device and that can further interact with input device 44 and output device 46. The computer platform 48 can include a memory 50 that can include volatile and non-volatile memory portions, such as read-only and/or random access memory (RAM and ROM), erasable and programmable read-only memory. Any memory shared by the body (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, and/or computer platform. In addition, the memory 50 can include active memory and storage memory, including an electronic file system and any secondary and/or tertiary storage device. 122807.doc -13- 200824386 [such as magnetic media, optical media, tape , floppy and/or hard disk, and removable memory components. ”

Further, computer platform 48 may also include a processor 52, a processor, an application specific integrated circuit (ASIC), or other chipset, processor, logic circuit, or other data processing device. In some aspects, such as when the signaling device 14 includes a cellular phone, the processor 52 or such as asic: = he can execute a program with any resident software component (such as a voice call, data call, and An application-specific interface (API) layer 54 that establishes an interface with the media-related application. Αρι 54 can be an execution time environment on a respective communication device. This execution time environment Z was developed by Qualcomm of San Diego, Calif."

Runtime Environment for Wireless® (BREW®) software. Other execution time environments that can be used, for example, to control the execution of applications on a wireless computing device. Additionally, processor 52 may include various processing subsystems 56 embodied in hardware, firmware, software, and combinations thereof that enable the functionality of communication device 14 and the communication device on communication network 26 (FIG. 1). The operability. For example, processing subsystem 56 allows for initiating and maintaining communication with other network devices, exchanging data with other network devices, and initiating and maintaining communications within and/or among components of communication device 14 and Data is exchanged within and/or among components of communication device 14. In one aspect, such as in a cellular telephone, processor 52 may include one or a combination of processing subsystems 56, such as sound, non-volatile memory, file system, transmission, reception. , searcher, layer 1, layer 2, layer 3, main control, remote program, handset, power management, 122807.doc -14- 200824386 Disconnect, digital video processor, vocoder, messaging, call Manager, Bluetooth® system, Bluetooth positive LPOS, location determination, location engine, user interface, sleep, data service, security, authentication, USIM/SIM (Universal Subscriber Identity Module/User Identification Module), voice service, Graphics, USB (Universal Serial Bus), Multimedia such as MPEG (Animation Professional Group) Protocol Multimedia, GPRS (Common Packet Radio Service), Short Message Service (SMS), Phrase Voice Service (SVSTM), Web Browser. For the disclosed aspects, processing subsystem 56 of processor 52 may include any subsystem component that interacts with an application executing on computer platform 48. The computer platform 48 can further include a communication module 58 that is capable of communicating among various components of the communication device 14 and operable to exchange content 24 between the communication device 14 and the communication network 26 (FIG. 1). (FIG. 1} and content request. The communication module 58 can be embodied in hardware, firmware, software, and/or combinations thereof, and can further include all protocols for internal and inter-device communication. In the apparatus and method described, the communication module 58 is operative to transmit and/or receive information, such as requesting the multimedia content 16 (FIG. 1) and receiving the compressed media/signal content 28 and the byte code 22 (Fig. 1) In some aspects, the memory 5 of the communication device 14 can further store a user interface module 60, which is operable to be processed in the background process or foreground processing. The multimedia content 16 is captured, stored and played on the communication network 12. The user interface module 4 can include hardware, software, firmware, data and executable fingers 122807.doc - 15-200824386 Order One or any combination includes a media player adapted to the type of multimedia content i6 and the performance of the user interface 42. Referring to Figure 3-6, as an exemplary environment for using the signal i to optimize the system 1(), - The network architecture is revealed for performing a specific type of signal compression (SigComp), which is based on the 3rd Generation Partnership Project (3GPP) and 3GPP2 standards of the Multimedia Subsystem (IMS) network. • Designated and defined in the 1MS2RFC 3320, RFC 3321A3Gpp standard (eg, 3GPP TS 23·228). In Figure 3, the general method is compressed in the mobile communication device (SIP User Agent) and proxy call/session control functions. (P-CSCF) SIp signal message sent over the air. This involves the compression side sending the decompression algorithm as part of the transmitted first message to the decompressor. In the receiving algorithm (byte code 22,) The decompressor (communication device 14) performs the interpretation of the byte code 22 received in the memory 50 and decompresses the Universal Decompression Virtual Machine (UDVM) interpretation of the subsequent message (compressed media/signal content 28). 64. This The advantage of the method is to support the ability of any kind of algorithm to supply its byte code 22 in space φ. In the illustrative version, the call control module in memory 50 is a protocol defined for this communication. Local Session Initiation Protocol (SIP) and Session Description Protocol (SDP) application 66. When interpreting each instruction in the byte code, one is caused by performing decompression of the byte code in the UDVM interpreter Calculating the extra burden induces a delay that can be attributed to prolonging the call setup time and damaging the user experience. The decompression scheduler module 68 in the memory 5 advantageously mitigates this delay by reducing the use of the UDVM interpreter 64 by one or more optimization implementations supported by the computer platform 48 of the communication device 14. 122807.doc -16- 200824386 As a first implementation, compiling the bytecode 22 earlier into a machine code executable by the optimized decompressor module 70 in the memory 50 provides one of the most effective decompression algorithms. Execution and thus shortening the latency of subsequent SIP message processing and call setup time. Therefore, the decompression scheduler module 68 accesses a decompression bank 72 to compare the received byte code 22i with one or more locally accessible byte codes 22", each and each decompressed machine code 36. pair. The decompressed machine code 36 can be executed by the optimized decompressor module 70 instead of the UDVM interpreter 64 after the match is detected. _ As a second implementation, for the newly received byte code 22, (the decompression scheduler module 68 cannot detect the match for it), the decompression scheduler module 68 directs the memory 5 The compiler 74 generates a decompressed machine code 36 which is then stored in conjunction with the byte code 22 in a null code storage record 76 and a blank index 78 in the decompression bank 72, respectively. This compilation can occur in the background - so that future instances of this byte code 22' can be processed by the first implementation. Φ As a second implementation, after the matching cannot be detected as in the second implementation, the 'decompression scheduler module 68 forwards a database for one cycle update of the decompressed machine code for external compilation or for future instances. The requested byte number 22 is requested. As a fourth implementation, computer platform 58 may advantageously include a UDVM hardware processor (e.g., 'Digital Bit Processor (DSP)) 80, which is allowed to be decompressed by The device hardware in the hardware is processed in parallel while the right heat is recognized by $^ & For the local SIP/SDP application 66, the decompression scheduler module 68 uses a proxy UDVM 82 to emulate 122807.doc • 17- 200824386 UDVM 64. In Figures 3-6, communication network 100 is generally identical to the 3GPP Release 5(5) network architecture described in 3GPP TS 23.228, which provides an operating environment for signal compression optimization system 10 of Figures 1-2. . Referring specifically to FIG. 3, communication network 100 is logically divided into a core network (CN) infrastructure 102 and an access network (AN) infrastructure 104. The CN infrastructure 102 is logically divided into a circuit switched (CS) domain 106, a packet switched (PS) domain 108, and an Internet Protocol (IP) Multimedia Subsystem (IMS) 110. The human infrastructure 104, depicted as a UMTS Terrestrial Radio Access Network (UTRAN) interface 104, is formed by a hierarchical radio network subsystem (RNS) 12, the elements of which are Radio Network Controllers (RNC) 114, nodes B element 116 and user equipment (UE) 118. Node B 116 is a logical network component that serves one or more units. It is a radio transmission/reception unit that communicates with the radio unit. RNC 114 is a network component having the function of controlling one or more Node B elements 116. The RNC 114 handles the protocol exchange between the UTRAN interfaces 104. The RNC 114 provides centralized operation and maintenance of the radio network subsystem 112, including access to an operational support system (not shown). Among them, the functions of RNC 114 include radio resource control, admission control, channel allocation and handover control. The entities specific to the circuit switched domain 106 are a Signal Gateway (SGW) 119, a Mobile Switching Center (MSC) 120, and a Gateway Mobile Switching Center (GMSC) 122. The CS switching domain 106 may also include some home subscriber services 123 that are subject to this type of signal. The MSC 120 forms the interface between the radio network subsystem 112 and the fixed network. The GMSC 122 is an MSC 120 that performs the routing to the actual location of the mobile station (User Equipment (UE)) 118. The entity designated for the packet switched domain 108 is a Serving GPRS Support Node (SGSN) 124 and a Gateway GPRS Support Node (GGSN) 126. The SGSN 124 and the GGSN 126 process the packet traffic. The SGSN 124 passes the packet to the mobile station 118 in its service area. The SGSN 124 performs mobility management functions, such as handing over a roaming user from a user device 118 in one unit to a device in another unit. The GGSN 126 is used as an interface to an external IP network such as the public internet 128, other mobile service provider's GPRS service (Home User Service (HSS)) 130, or an intranet (not shown). The GGSN 126 maintains the routing information necessary to tunnel the Protocol Data Unit (PDU) to the SGSN 124 of the Service Specific Mobile Station 122. Introducing the IP Multimedia Subsystem (IMS) entity of the IMS core network 11 into part of the Third Generation Partnership Project (3GPP) Release 5 (5) to form a common platform to develop differently based on a mobile Internet paradigm Multimedia service. The IMS entity includes all core network elements for providing IP Multimedia (IM) services, such as Call Session Control Function (CSCF) 130 (ie, 'Interrogation, Proxy and Service'), IMS Media Gateway Function (MGW) 131, Media Gateway Control Function (MGCF) 132 and Multimedia Resource Function 133. Each 3GPP's IMS CN 110 standardizes the functionality rather than the nodes defined by the standardized interface. The implementer can freely combine the two functions into a single node or divide a single function into two or more nodes. The 1MS CN 110 is a domain that controls voice and multimedia calls and sessions, as well as interconnections with other networks like the Public Switched Telephone Network (PSTN) 134 and other UMTS networks such as the HSS 130. It has a signal plane that traverses different paths and a media plane. 122807.doc •19- 200824386

SigComp is part of IMS CN 110 and is used to compress SIP signal traffic. The IP Multimedia (IM) domain enables cost reduction and the introduction of new services such as voice telephony, video telephony, multimedia conferencing, instant messaging and instant interactive gaming. IMS enables centralized and access to voice, video, messaging, data and network-based technologies for wireless users, combined with the growth of the Internet and the growth of mobile communications. The IP Multimedia Core Network Subsystem (IMS) enables public land mobile network (PLMN) operators to provide their users with multimedia based on Internet applications, services and protocols, and Internet-based applications, services and protocols. service. It uses a packet switched domain to carry multimedia signals and bearer traffic. The packet switched domain maintains the service while the terminal moves and hides the movement relative to the IMS. The IMS is independent of the circuit switched domain. The IM domain enables users and applications to control sessions and calls between multiple parties. It controls and supports network resources to provide the functionality, security, and quality required for calls. The IM domain provides user registration so that users can access their own services from any UMTS network. One of the additional tasks of the IM is to generate a Call Detail Record (CDR) containing information about the call participant, time, duration, and amount of data sent and received. The CDR is used for charging purposes. In FIG. 4, each IMS entity of 3GPP TS 23.228 includes CSCF, MGCF, IMS Media Gateway Function (IMS-MGW), Multimedia Resource Function Controller (MRFC), Multimedia Resource Function Processor (1^1^? ), a predetermined locator function (SLF), an interrupt gateway control function, and an application server (AS), wherein the interface supporting the user service is displayed as a solid line and the interface of the support signal is displayed as dotted line. 122807.doc -20 - 200824386

The task of the IMS entity is described in 3GPP TS 23.228. The CSCF, which is a SIP server, can act as a Proxy CSCF (P-CSCF), a Serving CSCF (S. CSCF) 138, or an Interrogating CSCF (I-CSCF). ? -08€ is the first point of contact for the UE of the ship 8 CN. The P-CSCF is also of particular importance to SigComp because it is the core network component that performs the collapse and decompression of the SigComp message. To this end, the P-CSCF includes a compressor and a decompressor (both IMS terminals also include both). While the task of the I-CSCF is to find the appropriate S-CSCF for a particular user, the S-CSCF handles the session state in the network. The MGCF performs protocol conversion, receives out-of-band information, communicates with the CSCF, selects the CSCF and controls part of the call state. The IMS-MGW terminates the bearer channel from the switched circuit network and the media stream from the packet network. It handles media conversion, bearer control, and payload processing. The task of the MRFC is to control the media stream resources in the MRFP, generate CDRs and interpret the information from the AS and S-CSCF and control the MRFP accordingly. The MRFP provides resources controlled by the MRFC, controls the bearers on the Mb reference point, and mixes, sources, and processes the media stream. When requested by the Ι-CSCF during registration and session establishment, the SLF provides the name of the HSS containing the required user-specific information. During the registration process, the SLF is also queried by the S.CSCF. The BGCF selects the network in which the PSTN interrupt occurs and picks the MGCF used. The AS can provide value-added services for a SIP application server, an open service access (OSA) application server, or a mobile enhanced logic (CAMEL) IP Multimedia Exchange Service (IM-SSF). IM service. The interface between the S-CSCF and the AS is used to provide services resident in the AS. The IP Multimedia Subsystem attempts to comply with the Internet Engineering Task Force (IETF) 122807.doc -21 - 200824386 Internet standards to achieve access independence and maintain smoothness with wired terminals on every 3GPP TS 23.228 internetwork operating. The signal protocol used for registration and call control in the IM domain is the Session Initiation Protocol (SIP). SIP is a single agreement applied between the UE and the CSCF. In Figure 5, the entity that compresses the message sent to a terminal and decompresses the message received from the terminal is the P-CSCF, which is depicted as an 81? signal stream from the UE to the S-CSCF. The radio network controller (RNC) of the radio interface, the base station (BS) and the UMTS terrestrial radio access network (UTRAN) flows through the 818 (1: 〇11^ compressed 81? message). The UTRAN traverses the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (SGSN) - up to the P-CSCF, where the SigComp message is decompressed. From the P-CSCF forward, the SIP message is sent uncompressed. The reason behind the choice of the entity that performs SigComp compression and decompression from the core of the network rather than from the radio access network. First, the location of the encryption and decryption functionality also affects the location of the compression functionality, since compression must be encrypted and decrypted. Applicable outside the boundary of the point and must be transparent. Verify, holistically protect or encrypt the packet content of certain traffic types. Decrypt the traffic from the terminal and encrypt the traffic to the receiver of the terminal at the core of the mobile network If the endpoint is selected from the radio access network, the network design and power will be subject to the added complexity of transferring the message key within the mobile network. Another weight that affects the location of the signal compression. The problem is the handover. In SigComp, a relatively large amount of historical state is established to enable efficient compression. If the endpoint of the decompression is changed, this state will need to be transferred to the new entity to maintain compression efficiency. The solution will increase the complexity of the network. When decompressing in the P-CSCF 122807.doc -22- 200824386

It remained stable during the period. Contrast in the terminal and in the network, which is in the network. Application layer message on the SigComp. It is transmitting 'and leaving routing problems to the IP. Good head. Entities that are only interested in the content of the transport layer protocol payload (i.e., two communication endpoints) need to decompress the SigComp message. It should be emphasized that the reason that the SIP signal is sent compressed between the terminal and the P-CSCF is not to save several bytes on the empty interfacing plane. Saving a few signal locations is not worthwhile when the terminal will establish a multimedia session that will use more bandwidth. The main motivation for compression is to reduce the time required to transmit SIP messages over an empty intermediaries. In IMS, the protocol for performing session control is Session Initiation Protocol (SIP). SIP was originally used to invite users to attend multimedia conferences, but today it is primarily used to create, modify, and terminate multimedia sessions. Although SigComp can be used to compress any text-based protocol, the current main focus is on the compression of SIP messages. SIP is independent of the type of multimedia session being processed and the mechanism used to describe the session. The most common format for describing a multimedia session is the Session Description Protocol (SDP). The SDP is only a text format that is carried in the body of the SIP message. This is why SigComp must be able to effectively compress SIP and SDP. The SIP/SDP static dictionary is defined for this purpose. 122807.doc -23 - 200824386 The SIP protocol defines several entities, which are User Agents (UAs), Redirect Servers, Proxy Servers, Registrars, and Location Servers. All 3G terminals supporting 3GPP Release 5 or later contain a SIP UA. Also, 3GPP2 has adopted SIP. SIP uses a proxy server to help deliver requests to the user's current location, authenticate and authorize the user of the service, implement a provider call-routing strategy, and provide features to the user. The redirect server helps locate the SIP UA by providing an alternate location that the user can reach. The registerer accepts the registration. It is usually co-located with a redirect server or a proxy server. The location server is not a SIP entity, but is an important part of any architecture that uses SIP. The location server stores and returns the user's possible location. SIP is a request/response protocol similar to Hypertext Transfer Protocol (HTTP), and SIP is based on HTTP. The SIP User Agent User (UAC) sends the request and the User Agent Server (UAS) returns a response. The start line of the request declares a method name that indicates the purpose of the request. The layout of the SigComp endpoint is illustrated in Figure 5. It includes the following entities: a compression scheduler, or multiple compressors, a state processor, a Universal Decompression Virtual Machine (UDVM), and a decompression scheduler. The task of the compression scheduler is to receive messages from the application and pass a compressed version of each message to the transport layer. The application must provide a separate compartment identifier along with each message to the compression scheduler. The interval is a special application packet for one of the messages associated with the peer endpoint. In the case of SIP, the interval is formed by all messages belonging to the SIP dialog. The separation identifier uniquely identifies an interval. SigComp calls the compressor on a per-interval basis of 122807.doc -24-200824386, which means that a separator identifier can also be used to identify a compressor. For this purpose, the mapping between the separator identifier and the compressor must be maintained. By providing a split identifier along with the application message, the application ensures that the compression scheduler can locate a suitable compressor. Whenever a new separation identification 旖% is encountered, a new compressor is called. Once the compressor has compressed the application message, the SigComp header is created and attached to the application message. After that, the compression scheduler can pass the SigComp message to the transport layer. When the application wishes to close an interval (for example, after receiving a bye message and sending a final response), this should be indicated to the compression scheduler. The compressor implements a compression algorithm for compressing application messages. One of the basic ideas of SigComp is that the standard does not indicate the use of a compression algorithm that should be used by all endpoints. Instead, the choice of algorithm is left as an implementation decision. Each endpoint of the following system should be able to decompress the output of multiple compression algorithms. This is made possible by using virtual machines to handle decompression functionality. When a decompressor creates a SigComp message containing the compressed application message, it includes a decompression algorithm for the header of the message. This decompression algorithm is called a byte code and it has been compiled into a form that can be executed on a virtual machine. Multiple requirements are placed on the compressor. First, it needs to be transparent (for example, the compressor does not send a bytecode that causes the UDVM to decompress the sigC〇mp message incorrectly). The compressor should provide a holistic check of one form of the application message to ensure that a successful decompression has occurred. You must ensure that the resources available at the remote endpoint are used to decompress the message. If the transmission is message-based (as in the case of User Datagram Protocol (UDP)), the compressor must map each 122807.doc -25-200824386 application message to a SigComp message. The compressor should also accurately map each application message to a SigComp message if the transmission is based on a stream but the application defines its own internal message boundary. The task of the decompression scheduler is to receive a SigComp message from the transport layer, call a new instance of the UDVM to decompress each message, and pass the resulting uncompressed message to the application. Once the application has received the message, it maps the message to an interval and returns the identifier of the interval to the decompressor. The decompression scheduler then passes the identifier to the state processor, which uses the identifier to save state information and forward the feedback to an appropriate compressor. By supplying a delimited identifier, the application grants the scheduler one permission to execute this.

The Universal Decompression Virtual Machine (UDVM) is the entity that decompresses SigC〇mp messages. The decompression process is performed by executing a special compiler called a byte code on the virtual machine. The UDVM is - very similar to the ^ (iv) virtual machine virtual machine, but the difference is that it has been optimized for performing the decompression algorithm. In the case of SigComp, the original code compiled into a byte code is called a UDVM combination and the entity that compiles it is called a udvm interpreter. The byte code can be considered as the machine language of the UDVM. When choosing how to compress—given an application message, the UDVM provides the flexibility that the compression implementer has the freedom to select the algorithm of its choice. The compressed data is combined with the byte code containing the set of UDVM instructions. These instructions are carried in the SigComp message and are extracted at the receiving endpoint. In the header and it allows the execution of the original data, so each SigComp can call a separate instance of the UDVM based on the insecure transport layer 122807.doc -26- 200824386 message to ensure that the damaged message does not affect the message later. Decompression. However, during the decompression process, the UDVM can call the state processor to access an existing state. Therefore, the state of the UDVM instance that decompressed the previous message can be recovered by a later UDVM instance. When the UDVM has been initialized, the UDVM can receive additional compressed data from the decompression scheduler or receive status information from the state processor based only on the request. As decompression proceeds, the UDVM outputs the decompressed data to the decompression scheduler. When it encounters the end of the message, it instructs this to the scheduler, which provides a separator identifier to it. This identifier is passed to the state processor in a state creation request. The state processor uses a split identifier to store the status information in one of the state memories reserved for the respective interval. The UDVM also forwards feedback information that can be piggybacked to the SigComp message to the case. The UDVM cycle is a measure of the amount of CPU power required to execute a UDVM instruction. The UDVM cycle limit is used to define the number of UDVM cycles that can be used to decompress each bit in the SigComp message. Since a malicious user can send a byte code containing a cyclic code, the amount of loop used by the byte code must be monitored. However, the cycle limit only reduces the amount of damage that can be caused, but does not eliminate the problem. In SigComp, the size of the decompressed memory can be negotiated. The decompression side informs the compression side of the size of the decompressed memory. The default is two thousand bytes. To improve compression efficiency, you can use four or eight thousand bytes or even larger memory sizes. The decompressed memory is divided into two parts, the first part of which is used to store the decompressed message. The other part is used by the UDVM to save the bytecode and the ring buffer, which enables the use of states larger than the UDVM memory. This is possible because the UDVM can start overwriting the contents at the beginning of the buffer as soon as the buffer is filled. Because a separate instance of the UDVM is called to decompress each message that arrives, a method is needed to maintain the information between the messages. This is the task of sigC〇rnp-like sputum processing, which stores the information between the received SigC〇mp messages. Due to the state processor, the compression ratio is improved because the message can be compressed relative to the information contained in the previous message. The state processor makes it possible to create a status entry for access when a later message is being decompressed. A status entry typically contains a snapshot of the memory of the UDVM instance or an uncompressed message. The state processor manages state memory on a per-interval basis. It saves the cache entry itself, which in turn maintains a list of state entries created by a particular interval and ensures that there are no gaps beyond its allocated memory. The UDVM interpreter is an entity that translates the UDVM instructions listed in the UDVM combination and its operands into a form of a byte code. The UDVM interpreter takes a file containing the UDVM combined source code as input and compiles it into a group code that can be executed on the virtual machine. In the case of the described operating environment of the signal compression optimization system 10, a signal compression optimization method 400 is depicted in FIG. For clarity, the method is sequentially divided into a communication network (propagation) portion of blocks 4〇2-412 followed by a communication device (reception) portion of blocks 414-42. It should be appreciated that the method can include a plurality of entities and can also transmit the propagation of the compressed SIP/SDP data valleys from a communication device to the communication network. In addition, the communication network 122807.doc -28-200824386 road or communication device may represent a plurality of entities, and initiate, relay, or terminate propagation in various combinations of such entities. Beginning in block 402, the communication network can advantageously maintain the state of the signal compression optimization system by obtaining the hardware/software configuration of the receiving communication device. This may require an extensive database that means that the overall functionality of the device can be kept as a new one or specifically focused on supporting the other aspects of the signal compression optimization system disclosed herein. Like them. This material may be supplied by an original equipment manufacturer (OEM) or interactively via SIP/SDP communication with individual communication devices or hierarchical entities supporting such communication device groups. In block 404, a signal compression algorithm is selected to decompress the original code (byte code). This selection may advantageously be made in the knowledge of whether the receiving communication device is capable of locally accessing an executable version of the bytecode rather than expecting the communication device to invoke a UDVM. In block 4〇6, the communication network compiles a byte code consistent with the obtained hardware/software configuration to produce an executable machine code. This compilation can wait for a request and then transfer it immediately. In the depicted sequence, in block 408, this compilation is performed prior to the request and the compilation is retrieved as requested based on the byte code and configuration used for propagation. Data content (e.g., multimedia content and/or signals) is compressed in block 410 in accordance with a compression algorithm. The compressed data content is then combined with a selected source code ("byte code" adapted to be interpreted at the communication device (mobile terminal) to decompress the data content (eg, multimedia, signal, etc.) according to a data packet protocol. ") transmitted together. In an exemplary implementation, in block 412, the communication network compresses the compressed content with a source code selected by 122807.doc • 29-200824386 according to a data packet protocol (byte code) The wireless transmission is carried out together. In the block, the communication device wirelessly picks up the transmission. In block 416, the transmitted byte code is extracted. In block 418, the location is determined by the debt. The uncompressed code associated with the tuple code—accessible executable version, from (4) free interpretation of the byte code on the virtual side. Accessing the executable version before execution may require local or remote compilation (4) For future versions, the executable version may require digital signal processing or other types of hardware-optimized decompressors to avoid using the UDVM interpreter. In block 42〇, then use the accessible executable version to decompress. Compressed Data content. In Figures 8-11, four specific implementations of the method of Figure 7 are depicted. First, in Figure 8, a signal compression optimization device 5 is placed on a hypothesis that is false The set of compression algorithms to be used is known in advance and the set of algorithms is incorporated into a mobile terminal 502 by providing a machine code implementation for this decompression algorithm. Signal compression performed on the mobile terminal 502 (SigComp) The optimization operation 504 can, in block 506, the detected decompressed byte code along with the SigComp message sent by the proxy call/session control function (P_CSCF) 5 10 on the communication channel 5 〇8. If the SigComp optimization operation 504 determines in block 5 12 that an exact match is detected, then machine code decompression is performed in block 514. However, if an exact match is not determined in block 512, then A Universal Decompression Virtual Machine (UDVM) interpreter is invoked in block 516 for decompressing the byte code. The local SIP/SDP application 518 receives the normal 81?/80? message originally compressed by ?_(:^?? Therefore 'if by P-CSCF 510 (for example, during roaming or at After the road upgrade) sends an algorithm that is not recognized in block 512, the mobile terminal 502 will still be able to execute the standard UDVM interpreter at 122807.doc -30-200824386. In Figure 9, an alternative signal compression optimization Device 600 requires a "just-in-time" compilation by a SigComp optimization operation 604, which will be self-contained on communication channel 608 in block 606.

The decompressed byte code received by the P-CSCF 610 is compared to a list of pre-compiled algorithms. If the byte code is found to be a match in block 612, the associated player code of the pre-compiled algorithm is used in block 614 for decompression. If a mismatch is found in block 612, the byte code is compiled into machine code in block 616 and then block 614 is executed, in which case the normal SIP/SDP message is provided to a local SIp/SDp. Application 618. Therefore, this byte code is compiled once and used for decompression of all subsequent Session Initiation Protocol (SIP) messages. In Figure 9, the use of the UDVM is avoided by waiting until the compilation is performed. This method requires accurate bytecode compilation performance. All messages after the first one are not subject to any processing inefficiencies induced by the rudvm interpreter code. Alternatively, while the udvm interpreter is being called for current communication, compilation can occur in the background for later use. In Fig. 10, another alternate signal compression optimization device 700 extends the use of a compiled version of the bytecode, but instead of accurately compiling the bytecode, a machine (e.g., compiled) code is transmitted by the network. For (4) the machine code is compatible with the mobile body described above... The network (SigC() mp feeder 72()) can be used to check the hardware of the line machine by means of a channel (4) (4) Software version number. In other words, the network selects the appropriate machine to be sent to the mobile station based on the hardware/software information of the mobile station. 122807.doc • 31 · 200824386 The received machine code can be stored on the mobile station's permanent memory to avoid subsequent retransmission of the same-machine code. To this end, the decompressed byte code received from p_CSCF on communication channel 7() 8 is compared at block 706 "igC 〇 最佳 optimization operation 704. Right determines in block 712 that the byte code matches, and the pre-compiled machine code is executed in the block. If a mismatch is found in block 712, a pre-compiled version of the bytecode is requested from the SlgComp server 72 and the bit group code is added to the list (block 716). The machine code is then available in block Μ# for execution to provide decompression to provide normal SIp/SDp messages to a local SIP/SDP application 722. In FIG. 11, yet another additional alternative signal compression optimization device 800 has a mobile terminal 802, and the decompression scheduler 8〇4 of the mobile terminal 8〇2 receives from a P-CSCF 8〇8 via a communication channel 806. Decompress the SlgComp message of the byte code. The mobile terminal 8〇2 uses an optimized hardware processor 810. The proxy UDVM 812 programs the hardware processor 810 with a particular byte code and then sends a message to decompress the hardware processor 810. The hardware processor can be a dedicated accelerator or A general purpose DSP that is programmed for UDVM interpretation. The normal SIP/SDP message is then used by a local SIp/SDp application 812. This system and method can also be applied to the network side to reduce the processing requirements of the p_CSCF server. A variety of implementations are possible. A certain high level implementation of a method such as sending a pre-compiled decompressed binary to a mobile station by the network may require some support from the infrastructure vendor and thus requires some form of standardization. Thus, in some implementations, it may be appropriate to include at least some of the features of the methods and methods disclosed herein, such as by 3GPP/3GPP2 or IETF (Internet Engineering Working Group). Standards recommended by the standards organization. Experimental results. After performing a benchmark marking of UDVM efficacy, the following were observed: (1) UDVM interpreter decompressed SIP Compared with the local decompression algorithm, it is about 20 times slower. (2) During the normal call setup on the QUALCOMM MSM6800 chipset, the time taken by the UDVM to decompress the SIP message is about 100 on a largely idle central processing unit (CPU). Ms. This time rises with advanced call setup conditions, such as the use of PRACK (ie, the SIP method for receiving the receipt of a temporary response) or quality of service (QoS) prerequisites. (3) Introducing a better compression algorithm with improved compression efficiency The method will significantly increase the UDVM decompression time. In summary, the present invention can potentially reduce call setup time by at least 100 ms or even more in the case of CPU load or complex SIP call setup flows. Figure 12-13 depicts the SURF 6800 subscriber unit Refer to the implementation results of the simple UDVM algorithm on the design board. In particular, Figure 12-13 shows the static DEFLATE and Lempel-Ziv-Storer_Szymanski (LZSS) decompression algorithms. The LZSS and DEFLATE algorithms are known to the standard. Compression system. DEFLATE is a lossless data compression algorithm that uses the Lempi-Ziv 1977 (LZ77) algorithm combined with Huffman coding and was originally created by Phil Katz. It is used for version 2 of its PKZIP archiving tool and is described in detail later in RFC 1951. Although LZSS compression is one of the algorithms used for standard learning, the present invention does not require any particular compression algorithm. ~ The exemplary candidate algorithm is dynamic DEFLATE. However, the complexity of the DEFLATE calculus 122807.doc -33- 200824386 is greater than the complexity of LZSS, meaning that the reduction in power efficiency may be greater in the DEFLATE implementation. The various illustrative logic, logic blocks, modules, and circuits described in connection with the aspects disclosed herein may be a general purpose processor, digital signal processor (DSP), or special application designed to perform the functions described herein. An integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, is implemented or executed. A general purpose processor may be a microprocessor, but in an alternative embodiment, the processor may be any conventional processor, controller, microcontroller or state machine. The processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a dsp core, or any other such configuration. Furthermore, the steps of a method or algorithm described in connection with the aspects disclosed herein may be embodied in a hardware, a software module executed by a processor, or a combination of both. For example, the steps of the method can be embodied in one or more processor modules operable to perform the various method steps. The software module can be resident in RAM memory, flash memory, r〇m memory, EPROM memory, EEPROM memory, scratchpad, hard disk, removable disk, CD-ROM or this technology. Know any other form of storage media. An exemplary storage medium is coupled to the processor such that the processor can read information from the storage medium and write the information to the storage medium. In an alternative embodiment, the storage medium may be integral to the processor. The processor and storage media can reside in the ASIC. The ASIC can reside in a user terminal. In an alternate embodiment, the processor and the storage medium may be resident as a discrete component and 122807.doc -34-200824386 resident in a user terminal. Moreover, for example, a method or algorithm step can be embodied in a computer program product comprising a computer readable medium. The computer readable medium has one or more sets of instructions for causing a computer to perform various method steps. Referring back to Figure 1, communication network 12 can include any data and/or voice communication network. For example, communication network 28 may comprise all or a portion of any or any combination of the following: a wired or wireless telephone network; a terrestrial telephone network; a satellite telephone network; such as an infrared-based data association ( IrDA network of infrared; short-range wireless network; Bluetooth® technology network; ZigBee® protocol network; ultra-wideband (UWB) protocol network; home radio frequency (HomeRF) network; shared wireless access Protocol (SWAP) network; broadband network, such as a Wireless Ethernet Compatibility Alliance (WECA) network, a Wireless Fidelity Alliance (Wi-Fi Alliance) network, and an 802. XX network; packet data network; data network; Internet Protocol (IP) Multimedia Subsystem (IMS) network; public switched telephone network; public heterogeneous communication network, such as the Internet; private communication network Multicast networks, such as forward link only (FLO) networks, including the MediaFLOTM system available from Qualcomm, Calif., San Diego; digital video broadcasting (DVB) networks, such as for satellites DVB-S, DVB-C for cable, DVB-T for terrestrial television, DVB·Η for handheld terrestrial television; and terrestrial mobile radio network. Moreover, examples of telephone networks that may be included in certain aspects of communication network 28 include at least a portion of analog or digital network/technology, or any combination, such as ·. Code division multiple access (CDMA) ), wideband code division multiple 122807.doc -35- 200824386 access (WCDMA), Universal Mobile Telecommunications System (UMTS), Advanced Mobile Phone Service (AMPS), Time Division Multiple Access (Tdma), Frequency Division Multiple Access ( FDMA), Orthogonal Frequency Division Multiple Access (〇FdMA), Global System for Mobile Communications (GSM), Single Carrier (IX) Radio Transmission, Evolutionary Data Only (EV-DO), General Packet Radio Service (GpRS), Enhanced Data GSM Environment (EDGE), High Speed Packet Access (HSpA), analog and digital health systems, and any other technology/agreement that can be used in at least one of a wireless communication network and a data communication network. Although various illustrative aspects have been illustrated and described, it should be understood that the subject matter of this document is not limited to such aspects. For example, communication device 14 is depicted as receiving (decompressing) multimedia content 16 for simplicity. An application consistent with the aspect of the present invention may require the transmission of this multimedia content either in reverse or in both directions. For example, multimedia content generated by still images or video cameras or multimedia content otherwise stored on communication device 14 can be uploaded to communication network 12. In addition, communication network 12 may be responsive to detecting the byte code provided by communication device 14 to thereafter use the same group code and corresponding compression algorithm for transmitting multimedia content 16 to communication device 14. Thereby, the communication device 14 can increase the likelihood of receiving the multimedia vault 16 and support the optimized decompression technique for the multimedia content 16 without resorting to the mUDVM interpreter 62. Therefore, while the foregoing disclosure is intended to be illustrative, it is intended that the invention may be modified and modified in the scope of the invention as defined by the appended claims. In addition, elements that are described in the singular form may be described or claimed in the singular, but the singular is not limited to the singular, but the plural is also included. In addition, although a particular feature has been disclosed with respect to only one of several implementations, this feature can be combined with one or more other features that are desirable and advantageous for any given or particular application. The terms "including" and variations thereof are used in the context of the embodiments or claims, and are intended to be inclusive in a manner similar to the term "include". Further, as an embodiment or application The term used in the scope of the patent, or "is intended to be "non-exclusive or π. In addition, although the described aspects and/or versions of the elements may be described or claimed in the singular, the singular In addition, all or a portion of any aspect and/or version may be used with all or a portion of any other aspect and/or version, unless otherwise specified. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of a signal compression optimization system for a wireless device in communication with a 'communication network. 2 is a schematic diagram of one aspect of the components of the wireless device of the system of FIG. 1. 3 is a diagram of the wireless device and communication network of FIG. 1 depicting further features of the Third Generation Partnership Project (3gpp) version five (5) network architecture. 4 is a configuration diagram of an Internet Protocol (Ιρ) Multimedia Subsystem (IMS) entity of the signal compression optimization system of FIG. Figure 5 is a block diagram of the location of the signal compression (SigComp) endpoint. 6 is a block diagram of the architecture of the SigComp endpoint of FIG. 5. Figure 7 is a flow diagram of a method for optimizing signal compression implemented by the system of Figure 1 122807.doc • 37- 200824386. 8 is a diagram depicting a version of a signal compression optimization sequence for operation of the wireless device of FIG. 1. 9 is a diagram depicting a version of a signal compression optimization sequence for operation of the wireless device of FIG. 1. 10 is a diagram depicting a version of the signal compression optimization system of FIG. 1. 11 is a diagram depicting a version of the signal compression optimization system of FIG. 1. Figure 12 is a graph depicting the efficacy of static DEFLATE.

Figure 13 is a graph depicting the power efficiency of the Lempel-Ziv-Storer_Szymanski (LZSS) compression algorithm. [Main component symbol description] 1〇Signal compression optimization system 12 Communication network 14 User equipment/communication equipment 16 Multimedia content 18 Compressor 20 Data compression algorithm 22 Data decompression byte code 22' byte code 22&quot ; byte code 24 wireless communication link 26 wireless communication link 28 compressed media/signal" wireless communication link/communication network 122807.doc -38- 200824386 30 processor 32 optimized decompressor 34 Universal Decompression Virtual Machine (UDVM) 36 Decompressing Machine Code 38 Executable Decompression Algorithm • 40 User Interface Module / Multimedia Content Player 42 User Interface 44 Input Device 46 Output Device 48 Computer Platform 50 Memory 52 Processor 54 Application Program Programming Interface (API) Layer 56 Processing Subsystem 58 Communication Module 60 User Interface Module 62 UDVM Interpreter & Proxy Call/Session Control Function (P-CSCF) 64 Universal Decompression Virtual Machine (UDVM) Interpretation 66 Local Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Application 68 Decompression Scheduler Module 70 Best decompressor module 72 of the decompression 74 compiler library 122807.doc -39- 200824386 76 78 blank space code stored record index 80 external compiler / UDVM hardware processor

82 Proxy UDVM 84 Proxy Universal Decompression Virtual Machine 100 Network Architecture/Communication Network 102 Core Network (CN) Infrastructure 104 Access Network (AN) Infrastructure/UMTS Terrestrial Radio Access Network (UTRAN) Interface 106 Circuitry Switched (CS) Domain 108 Packet Switched (PS) Domain 110 Internet Protocol (IP) Multimedia Subsystem (IMS) / IMS Core Network 112 Hierarchical Radio Network Subsystem (RNS) 114 Radio Network Controller (RNC) 116 Node B Element 118 Mobile Station/User Equipment (UE) 119 Signal Gateway (SGW) 120 Mobile Switching Center (MSC) 122 Gateway Mobile Switching Center (GMSC) / Specific Mobile Station 123 Home User Service 124 Month GPRS Support Node (SGSN) 126 Gateway GPRS Support Node (GGSN) 128 Public Internet 122807.doc -40- 200824386 130 GPRS Service (Home User Service (HSS)) / Call Session Control Function (CSCF) 131 IMS Media Gateway Function (MGW) 132 Media Gateway Control Function (MGCF) 133 Multimedia Resource Function 134 Public Switched Telephone Network (PSTN) 500 Signal Compression Optimizer 502 Mobile Terminal 504 Signal Compression (Sig Comp) Optimized Operation 508 Communication Channel 510 Proxy Call/Session Control Function (P-CSCF) 518 Local SIP/SDP Application 600 Signal Compression Optimizer 602 Mobile Terminal 604 SigComp Optimized Operation 608 Communication Channel

610 P-CSCF 618 Local SIP/SDP Application 700 Signal Compression Optimizer 702 Mobile Terminal 704 SigComp Optimized Operation 708 Communication Channel

710 P-CSCF 718 Decompressed Machine Code 122807.doc -41- 200824386 720 SigComp Server 722 Local SIP/SDP Application 800 Signal Compression Optimizer 802 Mobile Terminal 804 Decompression Scheduler 806 Communication Channel

808 P-CSCF 810 Optimized Hardware Processor

812 Proxy UDVM 814 Local SIP/SDP Application

122807.doc -42-

Claims (1)

200824386 X. Patent application scope: ι_ A method for conveying a data valley compressed by a selected one of a plurality of compression algorithms, each of the compression algorithms having a content that can be reproduced from the compressed data content The corresponding decompression algorithm of the data content & is transferred from the compressed data content transferred to the poor packet protocol of the J-message, a decompressed source code suitable for interpretation to perform the corresponding decompression algorithm, The data packet protocol further includes at least one message including the compressed data content, the method comprising: calling for detecting the original code in the at least one message; and locating the corresponding decompression associated with the detected original code One of the algorithms may access the executable version; and decompress the compressed data content using the located accessible executable version of the corresponding decompression algorithm. 2. The method of claim 1, further comprising responding to the inability to locate an accessible version of the respective decompression algorithm associated with the detected original code with an interpretation of the corresponding source code The virtual machine decompresses the compressed data content. 3. The method of claim 1, further comprising: responsive to one of the corresponding decompression algorithms associated with the corresponding source code, accessing the executable version and compiling the detected source code Forming a machine code; and establishing an accessible data structure containing the machine code retrieved by the detected source code. 4. The method of claim 1, further comprising: 122807.doc 200824386 requesting an executable version of the detected source code from a remote entity; and receiving the detected original from the remote entity The executable version of the code of claim 4, wherein the method of claim 4 further comprises determining a configuration of an intended processor that is assigned the executable version and compiling the source code for the expected processor . 6. The method of claim 1, further comprising: invoking an agent in a first processor that transmits an instruction from the detected source code and the compressed data content to a second processor a virtual machine; and presenting the content of the material decompressed by the second processor. 7. The method of claim 1, further comprising detecting the source code and decompressing the compressed data content comprising receiving and decompressing data packet protocol compatible signal compression (SigComp) as a third generation partnership program (3Gpp) _ The part of the packet data transmission. 8. The method of claim 1, wherein the data content comprises multimedia or signal content, the method further comprising presenting the data content in a form recognizable by a user. 9. The method of claim 1, further comprising receiving the data packet communication wirelessly. 10. The method of claim 1, further comprising receiving a Session Initiation Protocol/Session Description Protocol (SIP/SDP) data packet communication. 11 . An apparatus for receiving compressed Internet Protocol (Ιρ) multimedia 122807.doc 200824386 body subsystem (IMS) data content and attaching a decompressed byte code to a data packet communication channel, The device includes: an executable version of the decompressed byte code; a decompression scheduler that detects the decompressed byte code and accesses the executable version of the decompressed byte code; an optimized decompression Executing the executable version of the decompressed bytecode to process the compressed IMs data content into a normal SIP/SDp message; a local Session Initiation Protocol/Session Description Protocol (SIP/SDP) application It is used to receive these normal SIP/SDP messages. 12. The device of claim 11, further comprising a universal decompression virtual machine (UDVM), wherein the decompression scheduler is invoked in response to receiving a second decompressed byte code not associated with the first executable version The UDvM interprets the decompressed byte code. 13. The apparatus of claim 11, further comprising a compiler, wherein the decompression scheduler directs the compiler in response to detecting a second decompressed byte code instead of the first decompressed byte code A second executable version associated with the second decompressed byte code is generated. 14. The device of claim 11, wherein a network device is in SIP/SDP communication with the device, the decompression scheduler responsive to detecting a second decompressed byte code instead of the first decompressed bit The group code requests and receives a second executable version associated with the second decompressed byte code. 15. The apparatus of claim 11, further comprising: a proxy universal decompression virtual machine (UD VM); and 122807.doc 200824386 a hardware implemented UDVM that interfaces with the proxy UDVM to interpret the decompressed bit Group code and decompress the compressed IMS data content. 16. At least one processor configured to communicate data content compressed by a selected one of a plurality of compression algorithms, each of the compression algorithms having a capability to reproduce from the compressed data content a corresponding decompression algorithm of the data content, the compressed data content transferred via a data packet-contract containing at least one message, a decompressed source code adapted to perform the corresponding decompression algorithm, the data packet The protocol advancement includes at least one message including the compressed data content, the at least one processor comprising: a first module for detecting the original code in the at least one message; a second module One of the respective decompression algorithms for locating the detected source code can access an executable version; and a second module for using the determined φ bit of the corresponding decompression algorithm The executable version can be accessed to decompress the compressed data content. 17. A computer program product comprising: a computer readable medium comprising: - a first set of code for causing a computer to detect at least one message from \| ψ, containing one of the source code, The at least one message is also transmitted as part of a data packet protocol transmission by one of a plurality of compression algorithms: compressed data content, each of the compression algorithms having a suffix from the compressed The data content reproduces a corresponding decompression algorithm of the data content, the 'U source code is adapted to be interpreted to perform the corresponding solution by the computer 122807.doc 200824386 embossing algorithm; a second code set for making the The computer locates one of the corresponding decompression algorithms associated with the detected source code to access the executable version; and a third set of code for causing the computer to use the corresponding decompression method The compressed accessible data content is decompressed by the located accessible executable version. 18. A device comprising: means for detecting a byte code contained in a Session Initiation Protocol/Session Description Protocol (SIP/SDP) data packet communication; for positioning and detecting One of the respective decompression algorithms associated with the source code can access the executable version of the component; and means for decompressing the compressed data content using the positioned accessible executable version of the corresponding decompression algorithm . 19. An apparatus for propagating Internet Protocol (Ip) Multimedia Subsystem (IMS) data_content to a communication device, the apparatus comprising: a compressor that uses a compression algorithm to compress the data content; a data structure comprising a decompressed byte code; a data packet communication channel transmitting the compressed IMs data content and decompressing the byte code to the communication device; and a processor responsive to a source A request by the communication device to obtain an executable version of the decompressed byte code and transmit it to the communication device. The apparatus of claim 19, wherein the processor obtains one of the communication devices configured to select the executable version of the decompressed byte code suitable for the communication device. 21 - A method for propagating Internet Protocol (IP) multimedia subsystem (IMS) data content to a communication device, comprising: compressing the IMS data content using a compression algorithm; generating a decompression bit The data structure of the group code; Transmitting the compressed IMS data content and decompressing the byte code to the communication device; and transmitting an executable version of the decompressed byte code to the communication device in response to a request from the communication device. 22. The method of claim 21, further comprising obtaining one of the communication devices configured to select the executable version of the decompressed byte code suitable for the communication device. 23 to a parent processor configured to propagate Internet Protocol (IP) Multimedia Subsystem (IMS) data content to a communication device, comprising: a brother-one module for using a compression algorithm The method compresses the contents of the ims data; the module is used to generate a data structure containing a decompressed byte code; and the second module is configured to transmit the compressed IMS data content and the decompressed byte code And to the communication device, and a fourth module, and transmitting the decompressed bit for responding to an executable version of one of the request tuple codes from the communication device to the communication device. 122807.doc 200824386 24 - A computer program product comprising: a computer readable medium comprising: a first set of code codes operable to cause a computer to compress an internet protocol using a compression algorithm (Ιρ Multimedia Subsystem (IMS) data content; a second set of code that can be used to cause the computer to generate a data structure containing a decompressed byte code; a second set of code that can be used to cause the computer to transmit The compressed IMS data content and the decompressed byte code to the communication device; and a fourth set of code codes operable to cause the computer to transmit the decompressed byte code in response to a request from the communication device An executable version to the communication device. 25. An apparatus for propagating an Internet Protocol (Ip) Multimedia Subsystem (IMS) data to a device, comprising: means for compressing the content of the IMS data using a compression algorithm; Means for generating a data structure containing a decompressed byte code; means for transmitting the compressed <IMS data content and decompressing byte code to the communication device; and for responding to - from the communication A request to transmit a version of the decompressed bit 7G group code to a component of the communication device upon request by the device. 122807.doc