Many application protocols, like SIP (Session Initiation Protocol) or RTSP (Real-Time Streaming Protocol), used for multimedia communications are text-based and engineered for links having wide bandwidth. As a result, their messages have not been optimized in terms of size. For example, typical SIP messages range from a few hundred bytes up to two thousand bytes or more. SIP is defined by the IETF (Internet Engineering Task Force) in RFC (Request for Comment) 3261 and is an application-layer protocol used for (among other things) establishing, handling and releasing end-to-end multimedia sessions. With the planned usage of these protocols in wireless handsets as part of cellular networks, the large message size is problematic. With low-rate IP (Internet Protocol) connectivity the transmission delays are significant. Taking into account retransmissions and the multiplicity of messages that are required in some flows, at least call setup and feature invocation are adversely affected.
To eliminate this problem, a Signaling Compression (SigComp) architecture has been defined for robust, lossless compression of application messages. In terms of the OSI (Open System Interconnection) model, SigComp architecture can be interpreted as an enhancement to transport layer. Thus, SigComp provides the higher layer applications for both transmission and compression of the messages. SigComp is a protocol standardized in IETF which can compress application-layer protocol messages. In particular, it was developed to compress SIP messages which is used for session (call) setup and many other applications such as messaging. The main goal of SigComp is to reduce the size of SIP messages so that they can be transmitted with low latency over bandwidth limited links (e.g. cellular). Without SigComp, the transmission latency will lead to long call setup time that would not be acceptable to end users. SigComp details are defined in the following RFCs in IETF: RFC3320, RFC3321, RFC3322, RFC3485, and RFC3486.
Due to its usefulness in mobile communication, 3rd Generation Partnership Project (3GPP) has recommended the use of SigComp at least for compressing SIP messages. Therefore, the future 3 G mobile terminals must support SigComp.
The transmitting side of the SigComp architecture comprises a compressor dispatcher, one or more compressors and a state handler. The compressor dispatcher serves as the interface from the application. The application supplies the compressor dispatcher with an application message and a compartment identifier (i.e. an identifier that is used for application-specific grouping of messages). The compressor dispatcher invokes a particular compressor, which returns a SigComp message to be forwarded to the remote endpoint. State handler stores and retrieves state information that is stored between SigComp messages in order to avoid the need to upload the data on a per-message basis.
The receiving side of the SigComp architecture comprises a decompressor dispatcher, a Universal Decompressor Virtual Machine (UDVM) (a virtual machine which performs decompression) and a state handler. The decompressor dispatcher serves as the interface towards the application. The decompressor dispatcher receives a SigComp message from the transport layer and invokes an instance of the UDVM, which decompresses the SigComp messages. The decompressor dispatcher then forwards the resulting decompressed message to the application, which may return a compartment identifier if it wishes to allow state to be saved for the message. During the decompression process the UDVM may invoke the state handler to access existing state or create new state.
SigComp messages are transmitted as data packet flow on the transport layer along with other application messages, e.g. uncompressed SIP and RTSP messages. The SigComp messages are identified with own five-bit delimiters, i.e. they start with 11111 bits and end with 0xFFFF bits in case of stream-based transport according to e.g. Transmit Control Protocol (TCP). End-marking is however not needed in message-based transport according to e.g. User Datagram Protocol (UDP). The transport layer data stream is directed to the decompressor dispatcher, which must be arranged to identify the SigComp messages for decompression and to pass the non-SigComp messages to a particular application client, like SIP stack or RTSP.
However, initial requests are not compressed, since according to RFC 3486 compression is not to be started until the next hop URI (Uniform Resource Identifier) includes the parameter “;comp=SigComp,” and the SIP-URI of the outbound proxy does not include that parameter. The proxy address is discovered by a transmitting device during initial registration procedure and does not change afterwards.
SigComp has defined a few parameters such as version number and memory capacity that are supported by an endpoint. For SigComp to work between a message transmitter and receiver, they must agree on the values of those parameters. The current approach is that a SigComp receiver must support the minimum values of SigComp parameters that are defined for each application protocol, e.g. SIP in this case. The receiver may offer more than the minimum. In that case, the receiver can announce the parameter values in a SigComp feedback message sent back to the transmitter, as described for example in document US2005/0086327A1. This poses a few problems:
First, SigComp is not fast enough. When a transmitter sends the first message, it would be desirable to know if the receiver supports a newer version of SigComp or has more capacity than the minimum specified. Of course, the transmitter may wait for the SigComp feedback from the receiver. But that means the first message cannot be compressed in an optimal way. To make the problem even worse, there may be cases where the transmitter has to send more than one message before there is a message on the reverse direction. It means multiple messages—not just the first one—cannot be compressed optimally.
Second, implementation of SigComp is complicated. With the current SigComp announcement approach, it would require an implementation to do a “switch” (e.g. from SigComp version 1 to version 2 or from a small memory buffer to a larger one) after the first message in order to utilize the extra capacity for subsequent messages. Such a “switch” would add significant complexity to the implementation.
Third, SigComp does not work for asymmetric situation, where SigComp is applied on one signaling direction only. That is because the announcement mentioned above has to be carried as part of a SigComp message. Therefore, if SigComp is not applied on the other direction, no SigComp feedback can be sent back to the transmitter. In this respect, it is noted that some radio technologies are asymmetric, e.g. small bandwidth for uplink and large bandwidth for downlink. In that case, only SIP messages transmitted over uplink need to be compressed by SigComp.
Fourth, in SigComp, compression is made using any compression algorithm. The big idea in RFC 3220 is that decompression is always possible, no matter what compression algorithm was used. Decompression is done by using a virtual machine running a bytecode supplied by the endpoint who compresses. However, the size of the bytecode is several hundreds of bytes, so transmitting the bytecode via air interface leads to a reduced compression ratio. Quite often it may happen that there are so few messages (less than 50) compressed during the lifetime of a compression session (compartment life time in RFC 3320), so that using SigComp may actually make the total amount of transmitted bytes larger than without compression. It is noted that the bytecode is usually sent in both directions as both endpoints may choose the compression algorithm freely. Nowadays, sending the bytecode uplink and downlink requires a respective extra payload of 750 bytes.
In addition, the network has no way to effect what algorithm a terminal device uses in compression. It might use a very slow or inefficient algorithm. Or, an efficient algorithm my be used, which however consumes very much processing time and thus limits the number of users the network can serve.
Moreover, each terminal typically always uses the same bytecode and even terminals from the same manufacturer typically use exactly the same bytecode. Thus the same bytecode is sent via air-interface several times an hour, which is reducing the overall capacity and benefit of the compression.
An additional problem on the network side is that when a bytecode is received from many terminals, the network may need to calculate a SHA-1 value to get a state-id for the same bytecodes all the time. This generates unnecessary processing load in the network server and may actually limit the number of users it can serve.
On the other hand, if the network has stored a set of bytecodes, this may optimize the UDVM implementation so that the stored bytecodes can be processed very efficiently. For example if it is a known fact that for some bytecode decompresses using an LZ77 algorithm, network implementation for that bytecode could be such that virtual machine and bytecode is not used at all but decompression is done using more efficient standard methods, e.g. a decompression routine written in some general-purpose programming language. Thereby, much more clients could be served by one server as compared to running the bytecode in the virtual machine.
USPTO Backgrounds
USPTO Backgrounds