U.S. patent application number 11/559310 was filed with the patent office on 2008-05-15 for optimizing static dictionary usage for signal compression and for hypertext transfer protocol compression in a wireless network.
This patent application is currently assigned to CINGULAR WIRELESS II, LLC. Invention is credited to Kennie Y. Kwong, William Rosenberg, Matthew Stafford, Mark S. Wunthnow.
Application Number | 20080115125 11/559310 |
Document ID | / |
Family ID | 39402769 |
Filed Date | 2008-05-15 |
United States Patent
Application |
20080115125 |
Kind Code |
A1 |
Stafford; Matthew ; et
al. |
May 15, 2008 |
OPTIMIZING STATIC DICTIONARY USAGE FOR SIGNAL COMPRESSION AND FOR
HYPERTEXT TRANSFER PROTOCOL COMPRESSION IN A WIRELESS NETWORK
Abstract
Methods and apparatus including a virtual machine and a
compression network platform are provided especially for improving
the application of compression algorithms and unique identifiers
for algorithms, bytecode and HTTP common phrases of HTTP messages
utilized to advantage in wireless networks. In particular, a given
virtual machine need only identify to a receiving virtual machine
the unique identifier for one of an algorithm, a static dictionary
or a hash for decompressing a received data signal. Universal
decompressor virtual machines may receive uploaded compression
algorithms, bytecode identifiers or static dictionary identifiers
and the like from proxy call session control functions of a
wireless network, the compressing machine or a compression network
platform resource which in one embodiment may comprise an IANA
database. The methods and apparatus may find particular application
in improving the efficiency of presence/group list management.
Inventors: |
Stafford; Matthew; (Austin,
TX) ; Kwong; Kennie Y.; (Atlanta, GA) ;
Wunthnow; Mark S.; (Austin, TX) ; Rosenberg;
William; (Austin, TX) |
Correspondence
Address: |
POWELL GOLDSTEIN, LLP
901 NEW YORK AVENUE, N.W., 3RD FLOOR
WASHINGTON
DC
20001-4413
US
|
Assignee: |
CINGULAR WIRELESS II, LLC
Atlanta
GA
|
Family ID: |
39402769 |
Appl. No.: |
11/559310 |
Filed: |
November 13, 2006 |
Current U.S.
Class: |
718/1 ;
455/3.06 |
Current CPC
Class: |
H04L 65/1006 20130101;
H04L 69/04 20130101 |
Class at
Publication: |
718/1 ;
455/3.06 |
International
Class: |
G06F 9/455 20060101
G06F009/455; H04H 3/00 20060101 H04H003/00 |
Claims
1. A network platform for maintaining a database registry of at
least one compression and decompression algorithm, a static
dictionary, and respective algorithm and dictionary identifiers for
use at end locations for compression or decompression of data
signals, the network platform comprising: a data transceiver
coupled to a controller for receiving and transmitting data
signals; a memory for storing the compression and decompression
algorithm, static dictionary and algorithm and static dictionary
identifier data for transmission as data signals; and the
controller, responsive to a request for a particular compression
application, for matching the application to an algorithm or a
static dictionary stored in memory to determine algorithm,
corresponding identifier or a static dictionary and corresponding
identifier data for transmission by the data transceiver.
2. A network platform as recited in claim 1 wherein the memory
comprises a bytecode identifier representing a bytecode.
3. A network platform as recited in claim 2 wherein the bytecode
identifier comprises a hash on the bytecode.
4. A network platform as recited in claim 1 wherein the memory
stores an HTTP compression algorithm, the algorithm further
comprises an associated static dictionary for common phrases of a
message portion of HTTP.
5. A network platform as recited in claim 1 shared by a plurality
of wireless networks.
6. A network platform as recited in claim 1 being redundantly
provided within a wireless network.
7. A virtual machine for use in a wireless network comprising: a
decompression controller for controlling decompression of a
received data signal in accordance with one of a static dictionary
or a decompression algorithm; a memory for storing one of a static
dictionary or a decompression algorithm according to a unique
identifier of the static dictionary or decompression algorithm; the
decompression controller, responsive to a received data signal,
determining the unique identifier and retrieving the associated
static dictionary or the decompression algorithm; and if the
decompressing algorithm or static dictionary are not stored in
memory by unique identifier, the controller requesting the unique
identifier and the associated static dictionary or algorithm from a
remote location.
8. The virtual machine as recited in claim 7 wherein the remote
location comprises a proxy call session control function.
9. The virtual machine as recited in claim 7 wherein the remote
location comprises a remote universal decompressor virtual
machine.
10. The virtual machine of claim 7 being a virtual machine of a
mobile device.
11. A method of compressing a HyperText Transfer Protocol message
portion including a common phrase comprising: storing a unique
identifier in a static dictionary in memory of a virtual machine
representing a common message phrase; transmitting toward a remote
virtual machine the identifier for the common message phrase in
conjunction with the application of a compression algorithm, the
compression algorithm also identified by a unique identifier in
place of the common phrase of the message portion of the HTTP
transmission.
12. A method of decompressing HyperText Transfer Protocol message
portion including a common phrase comprising: storing a unique
identifier in a static dictionary in memory of a virtual machine
representing a common message phrase; receiving from a remote
virtual machine the identifier for the common message phrase in
conjunction with the application of a compression algorithm, the
compression algorithm also identified by a unique identifier; and
replacing the identifier in the HTTP data received from the remote
virtual machine with the common phrase of the message portion of
the HTTP stored in memory.
13. A method of establishing a compression method for use at user
equipment comprising transmitting a registration request including
dictionary definition from the user equipment, receiving a response
including a dictionary definition and transmitting subsequent
messages from the user equipment if the dictionary definitions
agree.
14. A method as recited in claim 13 wherein the response comprises
an unauthorized message including an alternative dictionary
definition.
15. A method as recited in claim 13 wherein the dictionary
definition comprises a version number.
16. A method as recited in claim 13 wherein the dictionary
definition comprises a state parameter definition.
17. A method for use in user equipment for obtaining an updated
dictionary comprising establishing a session with a server for
retaining dictionary data via a proxy server, receiving an updated
dictionary responsive to service provider control.
18. A method as recited in claim 17 wherein the session comprises a
message session relay protocol session.
19. A method as recited in claim 17 where the dictionary comprises
an OMA presence dictionary.
20. A method as recited in claim 17 wherein the session comprises a
SIP session with the proxy server.
Description
TECHNICAL FIELD
[0001] The technical field relates to wireless communication
networks and, in particular, to methods and apparatus for
facilitating and optimizing the application of compression, for
example, to data signal compression and in internet applications
including JAVA virtual machine bytecode and hypertext transfer
protocol (HTTP) applications in such networks.
BACKGROUND OF THE INVENTION
[0002] Generally, wireless communication networks suffer a
disadvantage in comparison with wired communication networks
because wireless communication networks must utilize valuable radio
frequency spectrum for the transmission of signals to wireless
mobile devices (including portable terminals such as computer
terminals or personal communication devices). Spectrum is expensive
to purchase as exemplified by the wireless communications RF
spectrum sales of the 1990's. Moreover, the greater the application
of uncompressed signals, power for transmitting signals in the
purchased RF spectrum can be wasted along with the spectrum
utilization increase. Further complicating and making the need for
compression even greater in a wireless communication network, the
applications for such mobile devices have greatly expanded as
wireless communications have, in many instances, replaced wired
communication devices because of the great, almost unbounded
popularity of the devices and the features that such devices may
provide. Consider, for example, currently available mobile devices
providing input/output for taking and receiving digital photographs
(which can be compressed in accordance with known JPEG compression
techniques), receiving downloaded MPEG compressed movie streams for
a subscriber's viewing pleasure, the opportunity to short text
message to "buddy lists" of friends, associates and family members
having mobile devices, download, store and play compressed digital
music in stereo of the subscriber's choice and so on.
[0003] Also consider the differences between text compression, for
example, the compression of a voice message converted to text or a
text document or a text message versus JPEG or MPEG compression.
The former needs to be lossless, that is, the message at the
transmitter ideally should be perfectly reproduced at the receiver
after compression and decompression. On the other hand, JPEG and
MPEG image compression follow a different philosophy. The
compression/decompression process need not be perfect and some
original image data may be lost intentionally but only such that
the received image is practically identical to the transmitted
image and any loss is not perceptible to the viewer.
[0004] In a virtual machine, bytecodes are known for representing
the machine language of, for example, a Java virtual machine. The
bytecode stream represents a sequence of instructions for the
virtual machine. HTTP is a known protocol for internet address and
command processing. In wireless communications involving the
network, there is a need for compression of such data signals.
These types of data streams are akin to text compression where
there is a requirement for lossless compression/decompression
processes.
[0005] Many of the new applications for mobile devices have
centered around an implementation of a session initiation protocol
(SIP) described, for example, by RFC 3261. SIP provides a protocol
for negotiating session parameters between session endpoints, for
example, such as setting up and tearing down Voice over IP sessions
between VoIP phones or sessions in which a camera image is
transmitted from one cell phone to another. Moreover, data signal
transmission and data compression are also known from such well
known compression algorithms as ZLIB (RFC 1950), DEFLATE (RFC 1951)
and GZIP (RFC 1952), and other compression algorithms and
techniques, all of which are well known to the Internet community
at large.
[0006] More recently, progress has been made in the development of
standard compression interfaces and techniques for signal
compression as exemplified by the efforts described by RFC 3320 and
RFC 3321. Also, recently, a session initiation protocol (SIP) and a
session description protocol (SDP) static dictionary has been
described in RFC 3485. Moreover, a so-called universal decompressor
virtual machine (UDVM) has been described, much like a Java virtual
machine, for running decompression algorithms and to provide almost
unlimited flexibility for choosing how to compress/decompress a
given item of data. With UDVM, both terminal ends, for example, two
mobile devices exchanging photographs or a mobile device gaining
access to a video-on-demand movie server must know what
compression/decompression the other end is using for the data
signal; otherwise, the compression/decompression provided by the
UDVM's will not function at an optimum level. On the other hand, in
SigComp as applied in SIP, headers as well as message bodies may be
compressed. Yet, network elements need to read the SIP headers for
routing and other purposes. Consequently, there is a problem with
end-to-end transmission for SIP because a network element may have
to decompress headers along a route to an end point. Consequently,
there may be a problem with the applicability of SigComp end-to-end
as would be required as applied in SIP.
[0007] Also, in accordance with the third generation partnership
project, 3G PP, for the global system for mobile communications
(GSM) and which can be used in related UMTS standards, an internet
protocol (IP) multimedia subsystem (IMS) has been defined for
multimedia applications, for example, per TS 23.228, 24.228 and
related technical specifications. There is proposed, for example, a
proxy call session control function (P-CSCF), an interrogating CSCF
(I-CSCF) and a serving CSCF (S-CSCF). SIP messages between one's
handset and its associated P-CSCF may be compressed as are SIP
messages between another person's handset and its P-CSCF. But
between P-CSCF's, the SIP messages are generally uncompressed
because as explained above the headers are needed for routing and
there is limited motivation to apply SigComp to a portion of a
message and not the whole. These control functions are known for
use in home and visited networks by mobile devices for multimedia
services as an outbound proxy (the first SIP-layer point of contact
for a mobile device in, for example, a general packet radio service
(GPRS) network). These control functions may be accessed by a
mobile device that would want to engage in a real-time interactive
multimedia application with a mobile device in the same or in
another wireless communication network. The virtual machines such
as the UDVM mentioned above are resident in, for example, the
mobile device and the P-CSCF. The capabilities of both ends of a
communication path should be consistent with one another to
successfully restore compressed content to its original form.
[0008] Presence is becoming increasingly important to wireless
network features and services. Presence relates to registration of
a mobile device that is turned on and in a mode for receiving
communications which may be standard voice calls or limited to
receiving, for example, text messages from a "buddy." As alluded to
above, one or more "buddy lists" may be input by a wireless
subscriber for friends, associates and family of the subscriber and
used to signal "presence" information among "buddies." The wireless
subscriber will typically wish to receive updates regarding his/her
buddies' presence status, as presence status is dynamic. For
example, a college student may receive presence information
indicating that a given buddy is currently not available for voice
calls but can receive text messages. Based on this information, the
student signals that "buddy" by text message to meet him/her in the
library at 10:00 AM. In so doing, eXtensible Markup Language (XML)
(not visible to the user) is commonly used to represent contact
information, such as an address book, each of which may be
delimited with the string <contact> at the beginning of the
string of contacts and </contact> at the end of the string.
Inside one of the contact strings, <name> and </name>
may be used to identify a name of a "buddy" or contact. Presence
information, bracketed by additional delimiters, may be stored with
the contact information. SIP has been identified as a suitable
vehicle for publishing one's presence information and for receiving
updates regarding a buddy's presence. HTTP has been identified as a
suitable vehicle for managing one's buddy lists. So for presence
and buddy list management, SIP and HTTP messages are launched and
the message bodies may be XML documents.
[0009] Consequently, even with all these improvements in the art of
providing compression techniques and virtual and other machines for
providing compression/decompression in accordance with alleged
unlimited flexibility, there remains an opportunity to facilitate,
if not to optimize, the use of compression via application, for
example, of static dictionaries and other techniques for
compressing various signals, bytecode, SIP and HTTP messages, XML
document and other data signals used in a wireless communications
network environment where the need for compression is the
greatest.
SUMMARY OF THE INVENTION
[0010] Several embodiments will now be briefly described for
facilitating compression/decompression of various data utilized in
a wireless telecommunications network. According to one embodiment,
a universal compression network platform (CNP) is provided as a
wireless network resource for compression and decompression which
even any UDVM or other virtual machine may use as a resource for
assuring that a given static dictionary or compression or
decompression algorithm are current. In its database may be
maintained the latest version of a compression and associated
decompression algorithm and/or static dictionary or other
compression/decompression tool for universal access in a manner
similar to the manner in which regional databases and servers have
been provided for number portability in the United States.
Alternatively, a compression network platform (CNP) may be
implemented on a wireless communications network basis, for
example, by each public land mobile network (PLMN) internationally
or preferably on a more global basis. In a network by network
implementation, each wireless network may agree to exchange and
maintain their CNP databases by mutual agreement with the latest
revisions and techniques. In this network by network embodiment of
a CNP, there may be a problem with roaming among networks and
whether the visited network needs to decompress SIP messages or in
stead just forward them to a home network via GPRS roaming. On a
more global basis, as was utilized in number portability, a global
CNP may be accessed by all networks. All such CNP's are preferably
provided with redundancy and in different regions of a country for
purposes, for example, of disaster recovery. A UDVM at each end of
a communication channel may have on hand the bytecode and
dictionary or dictionaries that each needs by conducting a dialog
between them, and, in the event of a difference resolve their
difference between them or utilize a CNP.
[0011] In accordance with another embodiment, rather than
uploading/downloading bytecodes to a virtual machine, for example,
associated with a mobile device or a P-CSCF, a compression
application of the bytecode may be applied, for example, to
compress the bytecode for uploading/downloading rather than the
current method of transmitting the bytecode itself to a far end
virtual machine. According to one aspect of this embodiment, the
compression technique may comprise a hash of the bytecode, for
example, in a manner similar to that described as a static
dictionary in RFC 3485 for SIP and SDP or signal compression
generally as described by RFC 3320 and 3321. According to another
aspect, there may be a publicly-available registry for storing the
algorithm, hash or static dictionary for the byte code, for
example, as a universal resource name as would be stored in the
Internet assigned numbers authority (IANA) database registry.
According to the first embodiment, the algorithm, hash or static
dictionary for bytecode may be stored along with its current
version number and a unique identifier in a CNP described above for
universal access by any virtual machine.
[0012] In accordance with yet another embodiment, there is provided
a means for receiving bytecodes and retaining them for long-term
utilization by a virtual machine. If a UDVM, for example, does not
have a copy of a bytecode it needs for receiving a given compressed
data signal transmission, the UDVM receiving the bytecode first
requests the bytecode compression method from the transmitting
compression virtual machine. If it cannot receive the method from
the transmitter machine, according to another aspect, it may
receive a unique identifier for the compression method and refer to
an IANA registry or a CNP registry as suggested above according to
the first and second embodiments and receive the method from them
along with its identifier and version number. According to another
related aspect, a new bytecode, unique identifier and its version
may be propagated generally to virtual machines for long term
storage therewith and subsequently referred to by its unique
identifier at a compression/decompression virtual machine, for
example, by a CNP or via IANA or other registry.
[0013] In accordance with yet another embodiment, consider
hypertext transfer protocol (HTTP) having a header and a message
payload. An example of XML content is contact information such as
an address book in XML in which each contact is delimited by the
string <contact> contact data </contact>. Inside the
XML contact, there may be <name> Ronald Reagan </name>
and email addresses and telephone numbers, home addresses and the
like for Ronald, each delimited by its own tag. In this embodiment,
a static dictionary may be provided for compression of the HTTP
payload or message portion. In particular, this embodiment
recognizes common phrases used in the message portion such as tags
from application-specific XML schema. Known compression algorithms
for HTTP such as DEFLATE and GZIP may be augmented in this
embodiment to provide a static dictionary for such common phrases
which may be stored at the compression and decompression virtual
machine and accessed as above from a CNP or via IANA or other
registry. Consequently, consider the example of presence/group list
management. Presence covers such concepts as online/offline status,
preferred means of communication (for example, voice or text
messaging). Group list management includes the afore-mentioned
contact or "buddy" lists. For example, a user wants to maintain one
or more contact lists. For example, a subscriber's contacts may be
grouped into separate lists (e.g. for colleagues and friends, or
according to a variety of shared interests. So there is a need to
manage a contact list or preferred sub-list of contacts who one
contacts more or less frequently. The virtual machine contained
within the mobile device or its server will have access to and
permanently store the known compression algorithm along with its
added feature of accessing a static dictionary for translating the
common phrases into transmittable address data (in shorter form
than the common phrase data) that may be used at the decompression
end to address a look-up table of the static dictionary for
decompression of the common phrase.
[0014] These and other aspects and embodiments will become clear
from referring to the drawings and the detailed description of the
embodiments which follow.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] FIG. 1 shows an overview of a network connection between a
first mobile device or user equipment visiting a visited wireless
network and a second mobile device or user equipment in a different
visited wireless network with their home networks also shown as a
scenario, for example, of sending a photograph captured by a first
mobile device to the second mobile device, also showing compression
network platform and IANA among other possible network resources of
first and second embodiments for any virtual or other machine for
compressing/decompressing data signals.
[0016] FIG. 2 is a schematic representation of a message transfer
for registration between user equipment UE and a P-CSCF of FIG. 1
as one example for message compression.
[0017] FIG. 3 is a second schematic representation of a message
transfer for registration between user equipment UE and a P-CSCF of
FIG. 1 as a second example for message compression.
[0018] FIG. 4 is a schematic representation of a first message
transfer among an HTTP server, user equipment UE and a P-CSCF of
FIG. 1 by which the user equipment may obtain an updated dictionary
from an HTTP sever or other compression network platform of FIG.
1.
[0019] FIG. 5 is a schematic representation of a second message
transfer among a dictionary server, user equipment UE and an IMS
Core (including a P-CSCF of FIG. 1) by which the user equipment may
obtain an updated dictionary from a dictionary sever or other
compression network platform of FIG. 1.
DETAILED DESCRIPTION OF THE EMBODIMENTS
[0020] Referring first to FIG. 1, and according to one embodiment,
a universal compression network platform (CNP) 150 is provided as a
wireless network resource for compression and decompression which
even any UDVM or other virtual machine may use as a resource for
assuring that a given static dictionary or compression or
decompression algorithm are current according to a version number
and identified by a unique identifier. In its database may be
maintained the latest version of a compression and associated
decompression algorithm and/or static dictionary or other
compression/decompression tool for universal access in a manner
similar to the manner in which regional databases and servers has
been provided for number portability in the United States.
Alternatively, a compression network platform (CNP) may be
implemented on a wireless communications network by network basis,
for example, by each public land mobile network (PLMN)
internationally. As will be further described herein, a compression
network platform may be restricted to a given type of
compression/decompression process and further located as close to
user equipment a possible to reduce latency.
[0021] In FIG. 1, a maximum of four different wireless networks,
110, 120, 130 and 140, are shown which may be interconnected by the
public switched telephone network (PSTN) (not shown to keep the
figure as simple as possible). There may be a telephone, for
example, User A equipment, mobile device 115, that, for example,
wants to publish or subscribe to presence information or create or
edit buddy lists by communicating with server(s) residing, for
example, in A's home network 120. Alternatively, user equipment
(UE) device 115 may wish to share content, (e.g., a photograph or
live video stream, digitized music, computer software, share a
buddy list, contact information or other application) with another
mobile device 125 in a different visited network 140. The
information or content being transmitted may contain text, or the
signaling exchanges that are conducted in order to facilitate
transmission may contain text or content.
[0022] User equipment or mobile device as used herein refers to any
known mobile terminal which may comprise terminals limited to voice
telephony but is not to be considered so limited as user equipment
may include personal computers, personal communications devices and
other devices having, for example, multimedia and computational
capability. Similar reference characters are used throughout the
drawings to designate similar elements and the first number of a
reference character designates where that element first appears.
For example, user equipment 115 first appears in FIG. 1 but is used
to designate similar equipment throughout FIGS. 1-5.
[0023] Preferably, the data signals, for example, text or content,
to be transmitted are to be compressed for transmission through the
wireless medium. Both mobile devices 115 and 125 are assumed to be
visiting different wireless networks. Mobile device A 115 is
visiting network 110 and mobile device B 125 is visiting network
140. Visited network 110 by mobile device 115 has proxy CSCF 135-1
and general packet radio service GPRS 165-1. Mobile 115's home
network 120 has interrogating CSCF 145-1, serving CSCF 155-1 and
optional interrogating CSCF 145-2. Ideally, each wireless network
110, 120, 130, 140 may agree to exchange and maintain their CPN
databases by mutual agreement with the latest revisions and
techniques in accordance with one embodiment. CPN 150 may be shared
by all networks. But, in another embodiment, there may be a
plurality of these CPN platforms and databases, and they may be
redundant within each public land mobile network (PLMN). Such CPN's
150 are preferably provided with redundancy and in different
regions of a country for purposes, for example, of disaster
recovery. Not shown in FIG. 1 are other locations of UDVM's that
may utilize the services of a CPN 150 such as a SIP server, a
video-on-demand application server, a music server, a presence
server and the like. Again, FIG. 1 would be greatly complicated if
each such point of possible signal compression/decompression in or
outside a wireless network were attempted to be drawn within the
boundary of the figure.
[0024] Mobile device 115 in accordance with an aspect of the
invention shares its compression algorithm, static dictionary or
other compression technique by a unique identifier with a network
platform or with another mobile device 125 with which it wishes to
communicate. In the event the far end (i.e. network platform or
mobile device 125) does not understand the unique identifier, it
may request the mobile device 115 to transmit the algorithm or
static dictionary used (along with its identifier) or receive the
compression method and identifier from a UDVM at P-CSCF 135-2 by
identifier look-up. P-CSCF 135-1 may also be a check point to be
sure there is consistency among points of compression and/or
decompression. Also, in accordance with an aspect of the invention,
when all else fails, a CNP 150 may be referred to by a virtual
machine of mobile device 115 and within mobile device 125 for an
appropriate compression/decompression tool that is application
dependent. P-CSCF 135-1, 135-2 or CNP 150 may transmit identifiers
or algorithms and identifiers to mobile devices 115, 125 for
storage therein depending on the needs.
[0025] In accordance with another embodiment which also may be
described with reference to FIG. 1, rather than
uploading/downloading bytecodes to a virtual machine, for example,
a UDVM associated with a mobile device or a P-CSCF 135-1, 135-2, a
compression application of the bytecode may be applied, for
example, to compress the bytecode for uploading/downloading rather
than the current method of transmitting the bytecode itself to a
far end virtual machine. According to one aspect of this
embodiment, the compression technique may comprise a hash of the
bytecode, for example, in a manner similar to that described as a
static dictionary in RFC 3485 for SIP and SDP or signal compression
generally as described by RFC 3320 and 3321.
[0026] According to another aspect which may be described with
reference to FIG. 1, there may be a publicly-available registry for
storing the algorithm, hash or static dictionary for the byte code,
for example, as a universal resource name as would be stored in the
Internet assigned numbers authority (IANA) database registry 160.
According to the first embodiment, the algorithm, hash or static
dictionary for bytecode may be stored along with its current
version number and unique identifier in a CNP 150 described above
for universal access by any virtual machine.
[0027] In accordance with yet another embodiment, consider
hypertext transfer protocol (HTTP) having a header and a message
payload. In this embodiment, a static dictionary may be provided
for compression of the HTTP payload or message portion. In
particular, this embodiment of a compression method recognizes
common phrases used in the message portion such as tags from
application-specific XML schema. Tags may be used, for example, to
delimit name, email address, telephone number, facsimile number and
so on. In order to provide a positive user experience, it may be
expedient to allow each subscriber to have a large number of
contacts and to organize their contacts into multiple buddy lists.
The tags that delimit the data can easily become voluminous.
Consequently, an application of this embodiment is presence/group
list management in a wireless network. As defined above, presence
comprises online/offline status, preferred means of communicating
(such as text message or voice) and other data about the user of a
mobile device such as location of the mobile device. Known
compression algorithms for HTTP such as DEFLATE and GZIP may be
augmented in this embodiment to provide a static dictionary for
such common phrases which may be stored at the compression and
decompression virtual machine and accessed as above from a CNP or
via IANA or other registry. In particular, address data for a
look-up table of the static dictionary may be transmitted in place
of the common phrase. On decompression at the receiving end, the
address data indexes the look-up table of the static dictionary and
retrieves the common phrase. Consequently, the user of a mobile
device may enter a contact list or update a contact list for, for
example, short message services and the virtual machine contained
within the mobile device or its server will have access to and
permanently store a known compression algorithm for delimiting tags
and other data along with its added feature of accessing a static
dictionary for translating other common phrases into transmittable
address data for indexing a look-up table that may be used at the
decompression end for decompression.
[0028] Taken together, FIGS. 2 and 3 are schematic representations
of a message transfer for registration between user equipment UE
and a P-CSCF if FIG. 1 as an example for message compression.
Referring first to FIG. 2, there is shown an example of an
application of message compression during registration of a
cellular phone or, more generalized, user equipment. In this
embodiment, the user equipment 115 and P-CSCF 135 exchange
information about the compression/decompression dictionaries they
each may use for compression/decompression during a registration
process. A first step may be the user equipment 115 sending a
REGISTER request to the P-CSCF 135 providing its authentication
credentials. According to one embodiment of the present invention,
the REGISTER request includes a "state" parameter for defining a
version of an Open Mobile Alliance (OMA) presence dictionary. Such
a dictionary for OMA presence in under consideration by the
Alliance but has not yet been published. Nevertheless, a value for
such a dictionary is depicted as a suggested value for such a
dictionary including a version number v1. The signal flow of FIG. 2
assumes that the initial REGISTER request is sent uncompressed
giving the P-CSCF 135 an opportunity to ascertain which
dictionaries the P-CSCF supports. The REGISTER request may be
compressed using version 1 of the OMA presence dictionary in an
alternative embodiment. For example, before registering with an IMS
core, user equipment must locate a P-CSCF. In third generation 3GPP
networks, on of the P-CSCF discovery procedures utilizes Protocol
Configuration Options which may incorporate "comp" and "state"
parameters. Doing so, would enable the user equipment to compress
an initial REGISTER request.
[0029] The P-CSCF 135 forwards the REGISTER request within an IMS
core, not shown, which may issue an authentication challenge. As
shown, a P-CSCF 135 then forwards the authentication challenge to
the user equipment 115 as the 401 Unauthorized message in FIG. 2.
The P-CSCF 135 inserts the comp and state headers (parameters) and
their values as shown. In accordance with one embodiment, the
"state=" is followed by the definition of an OMA presence
dictionary, which may be a static dictionary. The "state=" from
user equipment 115 alerts P-CSCF 135 of the dictionary in which
"comp=sigcomp," among other message components, may be found. IETF
3486 teaches obtaining a "comp" uniform resource identifier string
from the outbound proxy before the user equipment establishes a
session. The depicted signal flow accomplishes that objective
during registration. In the reply message from P-CSCF 135, a
similar "state=" is followed by a dictionary definition as will be
further explained below. In SIP headers, a string "comp=sigcomp" is
frequently used, for example, as a Uniform Resource Identifier
parameter in an initial REGISTER request and in a Via header field
in the authentication challenge of FIG. 2. This "comp" string, by
way of example may be replaced by a compressed string of characters
representing the string in an alternative or subsequent message. In
a message 1. REGISTER from the user equipment 115 to the P-CSCF
135, as well as in the message 401. Unauthorized, the same comp
string is found. Consequently, static dictionaries at either user
equipment or a P-CSCF may be provided to reconstruct a compressed
string into the transmitted string "comp=sigcomp." In FIG. 2, in
the authentication challenge message, there are shown two "state="
strings indicating that the P-CSCF supports both versions 1 and 2
of, for example, an OMA presence dictionary.
[0030] After a handset (user equipment) successfully attaches to a
wireless network (not shown to keep FIG. 2 simplified), the handset
of UE 115 attempts to register with the IMS by sending a SIP
register message 1. REGISTER, for example, in accordance with IETF
RFC 3486. In reply, there may be the depicted 401.UNAUTHORIZED
authentication challenge message. This 401 message is an
authentication challenge--that is, a request to the handset of UE
115 to provide its authentication credentials. Thereafter, another
1. REGISTER request containing authorization credentials would
follow that may contain compressed data of a static dictionary
alternatively to a given string such as "comp=sigcomp." That is, a
first message may be sent uncompressed as shown in FIG. 2 but
subsequent messages would follow with compressed data replacing the
compressed string in accordance with a mutually agreed to static
dictionary and version defined, for example, by "state=". Clearly,
once a static dictionary is defined at each end of the transmission
path, thereafter, the defined static dictionary may be used for all
such follow-up messages.
[0031] In the 401.Unauthorized challenge message, the receiver, the
P-CSCF 135, tells the user equipment UE 115 what dictionaries it
has on hand in its "state=" parameter definition. In FIG. 2, the
parameter is shown in a "Via:" header portion of the forward
message to P-CSCF 135 and the return 401.Unauthorized message to
signal the user equipment 115. The "state=" parameter definition
considers that the version of the dictionary is v1 at the user
equipment 115 and, further, that a v2 may be identified in the
401.Unauthorized reply as available at the P-CSCF 135. Unless the
user equipment 115 verifies that it possesses version 2, the P-CSCF
135 may be limited to version 1 in its communication with the user
equipment 115. As discussed above, a compression network platform
150 or alternative source (per FIG. 1) may be resorted to for
obtaining a version 2 of a defined static dictionary via an
alternative communication path not shown in FIG. 2. Obtaining
compression/decompression algorithms and dictionaries will be
further described with reference to FIGS. 4 and 5.
[0032] FIG. 3 is a second schematic representation of a message
transfer for registration between user equipment UE 115 and a
P-CSCF 135 of FIG. 1 as a second example for message compression.
In FIG. 3, the user equipment 115 provides its authentication
credentials in a new REGISTER request in response to the
authentication challenge. This request can be compressed based on a
version 1 of an OMA presence dictionary. The P-CSCF 135 replies on
the assumption that "comp=sigcomp" has already been initialized.
Moreover, 200 OK in reply saying to the user equipment 115 that it
is authenticated may be compressed as well. Later messages between
network elements shown or suggested are compressed in both
directions, for example, when user equipment 115 may send an INVITE
message to initiate a session (not shown).
[0033] In FIGS. 2 and 3, it is assumed that all messages are SIP
messages according to present standards. Alternative embodiments of
SIP and alternative forms of session protocols are contemplated
within the scope of the invention. Moreover, while the depicted
environment is IMS, the embodiment may be implemented within a
non-IMS environment. A backslash character in a text box of either
figure should be interpreted as a line continuation character.
[0034] In principle, user equipment 115 in FIGS. 2 and 3 may obtain
version 2 of an OMA presence dictionary from an alternative
location such as a compression network platform or P-CSCF of FIG. 1
and then compress a second REGISTER request according to the
updated version. At present, updating the user equipment dictionary
version in user equipment 115 may not be as practical as may be
possible in the future due to the latency involved in awaiting the
transmission of a version 2 or, perhaps preferably, version
one/version two changes from an alternate site to the user
equipment. The embodiment of FIGS. 1 and 2 is applicable regardless
of whether dynamic (as opposed to static) compression is also used
or regardless of whether SIP runs via Transport Layer Security
(TLS) or not. If TLS is utilized, sip URI's may be replaced with
sips URI's in the figures (where "sips" stands for "secure
SIP").
[0035] FIG. 4 is a schematic representation of a first message
transfer among an HTTP server 400, user equipment UE 115 and a
P-CSCF 135 of FIG. 1 by which the user equipment 115 may obtain an
updated dictionary from an HTTP sever 400 or other compression
network platform of FIG. 1. In FIG. 4, whenever a P-CSCF 135 needs
to obtain an updated dictionary, the signal flow may be coordinated
by an automated administrative process (not shown). Dictionary
updates on user equipment 115 may be handled differently than
P-CSCF updates--an administrative process need not be required.
User equipment 115 is so numerous in comparison to a network
platform such as a P-CSCF 135 that there may be only a limited
means of knowing ahead of time when a given user equipment will be
powered up and make a REGISTER request. FIG. 4 and FIG. 5 show two
dynamic methods by which a given user equipment 115 may obtain an
updated dictionary.
[0036] In FIG. 4, the messages between depicted elements are
numbered to indicate a sequence of message signals. Besides
numbering, the message signals are labeled to indicate which are
SIP messages and which are HTTP messages. In signal 1, the P-CSCF
135 may send a SIP INFO message to the user equipment 115
indicating a preferred HTTP server 400 for updating an updated
dictionary. As alluded to above and to reduce latency, the HTTP
server 400 may be selected to be not busy and as close as possible
to the user equipment 115. As highlighted in the text box, the SIP
INFO message informs the UE 115 that an updated dictionary can be
obtained, by way of example, at http:/[HTTP server
ID]/sigcomp_lexicons/oma_pres_v2.bin. The HTTP server ID in the URI
may be an IP address or domain name that user equipment 115 has
resolved to an IP address or using any known method of identifying
an HTTP server. The HTTP server 400 to which the URI refers may or
may not be in the same service provider's network as the P-CSCF
135. Even though a universal name may be allocated to a dictionary
version, a given service provider may prefer that the dictionary be
downloaded from a platform in its own network and so the URI
appearing in FIG. 4 is depicted to be a different identification
than that provided in FIG. 2. In addition, the service provider may
control latency better if located within its network than in the
public internet. The HTTP URI from this message becomes a request
URI in a subsequent HTTP GET message step 3 discussed below. Next,
P-CSCF 135 transmits a SIP 200 OK message to the user equipment
which results in the HTTP GET request of the HTTP server 400,
step/signal/message 3. The identified HTTP server 400 responds in
sequence with message 4. HTTP 200 OK whereby the message body of a
second version of the OMA presence dictionary is transmitted to the
user equipment 115 or at least the changes between version 1 and
version 2.
[0037] FIG. 5 is a schematic representation of a second message
transfer among a dictionary server 550, user equipment UE 115 and
an IMS Core 500 (including a P-CSCF of FIG. 1) by which the user
equipment 115 may obtain an updated dictionary from a dictionary
server 550 or other compression network platform of FIG. 1. Eight
message signals are shown for accessing a dictionary server 550 in
FIG. 5. As opposed to FIG. 4 where a P-CSCF 135 sent a message to
user equipment 115 telling it where to find an updated dictionary,
in FIG. 5, an application server may push the dictionary to the
user equipment 115 from the dictionary server 550. The dictionary
server 550 initiates an MSRP (Message Session Relay Protocol)
session with the user equipment 115 via the IMS core 500. Messages
1-6 constitute a known or standard session set-up comprising an
INVITE via the IMS Core 500 to the user equipment 115, a 200 OK
return and a SIP ACK (acknowledgement). Once the session is set-up,
the dictionary server 550 exchanges, for example, the dictionary
version two (or the changes between versions) for an MSRP 200 OK
message. As before, if the user equipment 115 already has a version
1, then, only the changes between version 1 and version 2 need be
transmitted. The purpose of the MSRP session having been
accomplished, the session may be torn down in known manner via a
SIP BYE/200 OK exchange between the dictionary server 550 and the
user equipment 115.
[0038] Note that according to both FIGS. 4 and 5, the supporting
network is the instigator for the user equipment obtaining a new
version of a dictionary. For example, if the serving network is
IMS, an IMS service provider may want to control the timing of the
dictionary download, for example, to reduce latency, for example,
avoid a busy hour, avoid performing a download in a roaming
scenario and so on. The depicted dictionary server could be alerted
by the network in a number of ways. For example, the P-CSCF 135 may
alert the server; the IMS core could be configured to forward
copies of registration request transactions to a dictionary server
for review.
[0039] Continuing the discussion of FIGS. 4 and 5 with reference to
FIG. 2, the user equipment 115 now has obtained an updated user
dictionary (which may be a static dictionary or a dynamic
compression/decompression algorithm). Consequently, the user
equipment 115 will indicate the change in status the next time it
dispatches a REGISTER or other request to the IMS core. At that
time, SigComp would be initialized according to the updated
version.
[0040] Thus there has been shown and described several approaches
for the optimized application of static dictionaries which may be
utilized in concert with dynamic compression/decompression
algorithms in a wireless network to considerable advantage for
different purposes such as in so-called presence applications. The
following set of claims should not be deemed to be limited to the
embodiments described above. Alternative embodiments may come to
mind to one of ordinary skill in the art for application in
alternative or later generation wireless networks.
* * * * *