Method and apparatus for enhancing air-interface information exchange during a dormant packet data session

ES 2 305 807 T3

DESCRIPTION

Method and apparatus for enhancing air interface information exchange during a latent packet data session.

Field

The present invention relates to the exchange of information in wireless communication systems. More specifically, the present invention relates to methods and apparatus for increasing the exchange of air interface information with a latent target communication device in a wireless communication network.

Background

When the packet data service in a wireless communication system is active, the infrastructure resources, for example, the base transceiver station subsystem (BTS), the base station controller (BSC), the control function of packets (PCF) and the radio link are actively assigned to the devices participating in the communication. After a period of inactivity in a communication device, the corresponding traffic channel can go into a latent packet data session to conserve system capacity, reduce service cost, and conserve battery life. However, the act of reverting from the latent packet data session to an active packet data session is accompanied by a considerable delay in system response time. S. Manning, A. Gutierrez, M. Wang, "A short data burst mechanism for third generation cdma wireless packet data", IEEE 1999 describes a mechanism for exchanging information with a communication device latent that includes a call message and a call answer. The data is exchanged using short data bursts SDB ("Short Data Bursts") when the mobile is in latent state, by common channels.

There is thus a need for mechanisms to exchange information with a latent communication device efficiently.

Summary

The described embodiments provide new and improved methods and apparatus for exchanging information with a latent target communication device in a wireless communication network in accordance with the features of the appended claims.

Brief description of the drawings

The characteristics and advantages of the present invention will become more evident in the detailed description of the embodiments indicated below:

Fig. 1 illustrates a group communication system;

Fig. 2 to Fig. 9 illustrate call flows for exchanging information with a latent communication device; Y

Fig. 10 illustrates an embodiment for a communication device and a base station.

Detailed description

Before explaining various embodiments in detail, it must be understood that the scope of the invention should not be limited to the details of construction and arrangement of the components proposed in the following description or illustrated in the drawings. It should also be understood that the phraseology and terminology used serve the purpose of description and should not be considered limiting.

Fig. 1 illustrates a functional block diagram of a group communication system 100, to implement one embodiment. The group communication system 100 is also known as a push-totalk system (PTT), network broadcast service (NBS), broadcast system, or point-to-multipoint communication system. In one embodiment, the group communication system 100 includes a group call server 102 that can be used in both a centralized deployment and a regionalized deployment.

Group communication devices (CDs) 104 and 106 that can be used as cdma2000 terminals, for example, can request packet data sessions using a data service option. Each CD can use the session to register its Internet Protocol (IP) address with the group call server to perform group call initiations. In one embodiment, the group call server 102 connects to the service provider's packet data service nodes (PDSNs) through the service provider's network 116. The CDs 104 and 106, after having requested packet data sessions from the wireless infrastructure, they can have IP connectivity with the group call server 102 through the PDSNs

ES 2 305 807 T3

114. Each PDSN can interact with a base station controller (BSC) through a packet control function (PCF) 108 and a network 112. The PCF can be co-located with the BSC in a base station (BS) 110.

A packet data serving node can fall into one of several states, for example, active or connected state, dormant state, and null or inactive state. In the active or connected state, there is an active traffic channel between the participating CD and the BS or BSC, and either end can send data. In the dormant state, there are no active traffic channels between the participating CD and the BSC, but a point-to-point protocol (PPP) link is maintained between the participating CD and the PDSN. In the null or idle state, there is no active traffic channel between the participating CD and the BSC, and no PPP link is maintained between the participating CD and the PDSN.

After booting, CDs 104 and 106 can request packet data sessions. As part of establishing a packet data session, each CD can be assigned an IP address. Each CD may go through a registration process to inform the group call server 102 of the CD's IP address. Registration can be done using an IP protocol, such as Session Initiation Protocol (SIP) over User Datagram Protocol (CTDP). The IP address of a CD can be used to contact the CD when the corresponding user is invited to the group call.

Once a group call has been established, the CDs 104 and 106 and the group call server 102 can exchange media messages and signaling messages. In one embodiment, the participating CDs and the group call server can exchange media messages using Real Time Protocol (RTP) over UDP. Signaling messages can also be exchanged using a signaling protocol over UDP.

Group communication system 100 performs several different functions in order to handle group call services. Functions that refer to the user part include user registration, group call start, group call end, send alerts to group participants, late join a group call, talker arbitration, add members to a group, drop members from a group, delete a member, and authenticate. Features that relate to system setup and operation include provisioning and management, scalability, and reliability.

PTT latency

In one embodiment, when the packet data service is active, the infrastructure resources, for example, the base station transceiver subsystem (BTS), the base station controller (BSC), the packet control function (PCF) and the radio link are actively assigned to the participating CDs. In an IP-based broadcast service, while an active conversation is taking place between group members, the packet data connection of each participating CD is kept active. However, after a period of inactivity, ie a "hang time", the traffic channels assigned to the participating CDs can be activated and the participating CDs can go dormant.

The transition to dormancy preserves system capacity and reduces service cost and battery drain. When packet data sessions are active, even though packets are not being exchanged, participating CDs can still transmit radio frequency (RF) energy, albeit at a low level, to maintain synchronization and power control with the station base. These transmissions can cause significant power drain on participating DCs. In the latent state, however, the participating CDs may not carry out RF transmissions. To conserve power and increase battery life, the timeout should be programmed so that participating CDs go into dormant mode when no data is transmitted for long periods of time.

In the case of an active group call, while the packet data services of all participating CDs are active, new PTT requests have very low latency. However, if the participating CDs have previously gone into latency, the PTT latency time can be much longer. During the latency state of the data packets, information associated with the packet data session can be maintained which may include the IP address of the CDs. However, the state information associated with the layers under PPP, such as the active traffic layers, can be released and / or de-assigned.

In some infrastructures, to activate latent data packet sessions, traffic channels must be reallocated, resources must be reallocated, and the radio link protocol (R.LP) layer must be reset. The effect of this is that after a group has not spoken for a while, when a group member presses the PTT button to request call control, the PTT latency for the first voice broadcast is generally much longer. than for the following broadcasts. Although this is relatively rare, it can affect the usefulness of the group call service and should be minimized.

To reduce PTT latency, group call signaling, such as floor-control requests (floor-control requests), call control announcements, and latency wake-up messages, should be transmitted by some common channels available. This eliminates the wait for dedicated traffic channels to be re-established. Common channels should always be available, regardless of the status of the participating CDs, and should not need to be requested and reassigned every time a group member starts up.

ES 2 305 807 T3 a group call. Consequently, group call signaling messages can be exchanged even when participating CDs are latent. In one embodiment, the dedicated traffic channels of the calling CDs and the listening CDs can be restored in parallel.

In one embodiment, a latent calling CD can send a space usage request to the wireless infrastructure on some available reverse common channel, such as reverse access channel and enhanced reverse access channel. The calling CD may also receive a response to the space usage request on some available common direct channel, such as the notification direct channel and the common control direct channel. In one embodiment, the latent listening CDs may receive latency trigger messages on some available common forward channel, such as the notification forward channel and control common forward channel.

Call signaling messages in short data bursts

In one embodiment, a significant reduction in latency activation time can be achieved by using Short Data Burst Messages (SDB), as outlined in the TIA / EIA / IS2000 standards for "cdma2000 Spread Spectrum Systems" , such as the TIA / EIA / IS-707-A-2 “Data Service Option Standard for Spread Spectrum Systems, Addedum 2”, June 2000 and the TIA / EIA / IS-2001-A “Interoperability Specification (IOS) for cdma2000 Access Network Interfaces ”, August 2001, which will be named from now on "the cdma2000 standards". In one embodiment, the SDB messages can be sent on a dedicated active channel, such as the Fundamental Forward Channel (FCIT) or the Dedicated Forward Common Control Channel (F-DCCH). SDB messages can also be sent on a common active channel, such as Reverse Access Channel (R-ACH), Enhanced Reverse Access Channel (R-EACH), Common Control Forward Channel (F-CCCH), or notification channel (PCH). SDB messages can be carried by Radio Burst Protocol (RBP) which maps the messages to an appropriate and available active layer channel. As SDB messages can carry arbitrary IP traffic and can be sent over common active channels, SDB messages provide a mechanism for exchanging group call signaling when participating CDs do not have any dedicated traffic channels available.

Mobile originated call signaling messages

In one embodiment, the signaling media messages may carry IP datagrams over the reverse link or mobile originated link. The talker CD can quickly alert the group call server whenever a talker requests space and a reverse dedicated traffic channel is not immediately available. Assuming the talker CD has activated all dedicated traffic channels, the talker CD can immediately deliver the space usage request over a common reverse channel of a wireless infrastructure, which can delay the request to the group call server . For example, both the reverse access channel and the enhanced reverse access channel can be used to send such messages when a reverse dedicated channel is not available. In one embodiment, the talker CD can transmit a space usage request to the group call server as the SDB messages.

Network originated call signaling messages

In one embodiment, upon receiving the space usage request, the group call server can broadcast media signaling messages to a group of latent target CDs and activate the latent target CDs to re-establish their dedicated traffic channels. In one embodiment, the packet control function (PCF) receives a small amount of information, for example data packets, from the packet data serving node (PDSN) that can be allocated to latent target CDs. The PCF may decide to send the information to the base station controller (BSC) in a special way. In one embodiment, the special form includes the short data burst (SDB) format as specified in TIA / EIA / IS-707-A-2, "Data Service Option Standard for Spread Spectrum Systems" Addendum 2, dated June 2000 (IS-707-A-2). The TIA / EIA / IS2001-A standard "Interoperability Specification (IOS) for cdma2000 Access Network Interfaces", dated August 2001 (IS2001-A) defines several options for the BSC to deliver SDB messages to the target CDs.

According to the IS-2001-A standard, for example, when the PCF receives a small amount of data destined for latent target CDs, the PCF may decide to send the received data to the BSC in SDB format. If the BSC determines that short bursts of data should be used to deliver the data to the latent target CD, the BSC may send the data directly to the latent target CD over a signaling channel. The BSC may also send the data to the MSC for delivery to the latent target CD via an application data delivery service (ADDS) call. The data can be delivered to the MSC using a request / response procedure BSC service. If the BSC is unsuccessful in delivering the SDB data to the latent target CD on its own, the BSC may decide to send the data to the MSC for delivery to the latent target CD through an ADDS call procedure.

Fig. 2 shows a call flow procedure for exchanging information with a latent target CD, according to one embodiment. The packet data session is dormant with the PPP connected. The PDSN sends the data packet 202 to the BSC / PCF on the existing PPP connection associated with the latent target CD. The BSC / PCF determines, in step 204, whether the received data packet should be sent to the latent target CD in the form of short data bursts (SDB). In the case where the BSC / PCF determines that the received data packet can be sent to the latent target CD in SDB form, the BSC / PCF locates the latent target CD. BSC / PCF locates

ES 2 305 807 T3 the latent target CD by sending a general call message 206 to the CD or by using the location information already obtained. The call message can be based on a service option (SO) such as “SO 33”. After the BSC / PCF has received a call response 208 and sent an acknowledgment message (ACK command) 210 to the latent target CD, the BSC / PCF sends the received data packet to the latent target CD in SDB form 212 . The BSC / PCF indicates in message 212 to the latent target CD whether the latent target CD should send an Ack command upon receipt of message 212. If Ack command is required, and if an Ack command 214 is received from the latent target CD, the BSC / PCF may also send an Ack command 216 confirming that the BSC / PCF has received the Ack command 214 from the latent target CD.

In one embodiment, after the Ack command 216 has been sent to the latent target CD, the BCS / PCF sets a timer 218, timer T42, upon expiration of which the latent target CD can go from access state to state. inactivity and start forwarding information in an SDB 220 message to the BSC / BCF. If the mobile initiated message 220 requires an Ack command, the BSC / PCF sends an Ack command 222 to the latent target CD.

Fig. 3 shows a call flow procedure for exchanging information with a latent target CD according to one embodiment. The packet data session is dormant with the PPP connected. The PDSN sends the data packet 302 to the BSC / PCF on the existing PPP connection associated with the latent target CD. The BSC / PCF determines, in step 304, whether the received data packet should be sent to the latent target CD in the form of short data bursts (SDB). In the event that the BSC / PCF determines that the received data packet can be sent to the latent target CD in SDB form, the BSC / PCF sends a general call message 306 to locate the latent target CD. The call message can be based on a service option (SO) such as “SO 33”. After the BSC / PCF has received a call response 308 and sent an acknowledgment message (ACK command) 310 to the latent target CD, the BSC / PCF sends the received data packet to the latent target CD in SDB 312 form. The BSC / PCF indicates in message 312 to the latent target CD whether the latent target CD should send an Ack command upon receipt of message 312. If Ack order is required, and if the Ack order 314 is received from the latent target CD, the BSC / PCF may also send an Ack order 316 confirming that the BSC / PCF has received the Ack order 314 from the latent target CD.

In one embodiment, after the Ack command 316 has communicated with the latent target CD, the BSC / PCF sends a "release command" 318 to the latent target CD to allow the CD to cancel its timer. Upon receipt of the release command 318, the latent target CD cancels the timer T42m 320 and goes from the access state to the idle state, allowing the latent target CD to send an SDB 322 message to the BSC / BCF. The latent target CD may go from the system access state to the idle state after it has gone through the system determination substate. However, the latent target CD can go from the system access state to the idle state without going through the system determination substate, to reduce the wait time. If the SDB mobile initiated message 322 requires an Ack command message, the BSC / PCF sends the Ack command 324 to the dormant target CD.

Fig. 4 shows a call flow procedure for exchanging information with a latent target CD according to one embodiment. In this embodiment, the call flow procedure, illustrated 402 to 422, is similar to the call flow procedure described in Fig. 2, but call message 406 is based on an unused service option (SO), rather than “SO 33”, such as a registered SO, so that other BSC / PCF call processing that is designated based on to “SO 33” does not need to be modified for SDB delivery.

Fig. 5 shows a call flow procedure for exchanging information with a latent target CD according to one embodiment. In this embodiment, the call flow procedure, illustrated 502 to 524, is similar to the call flow procedure described in Fig. 3 but the 506 call message is based on an unused service option (SO), instead of “SO 33”, such as a registered SO, so that other BSC / PCF call processing that is designated based on the "SO 33" does not need to be modified for SDB delivery.

Fig. 6 shows a call flow procedure for exchanging information with a latent target CD according to one embodiment. The packet data session is dormant with the PPP connected. The PDSN sends the data packet 602 to the BSC / PCF over the existing PPP connection associated with the latent target CD. The BSC / PCF determines whether the received data packet can be sent to the latent target CD in the form of short data bursts (SDB). In case the BSC / PCF determines that the received data packet can be sent to the latent target CD in SDB form, the BSC / PCF sends a general call message 606 to locate the latent target CD. The call message can be based on a registered service option (SO), such as “SO 0x8026”.

The BSC / PCF uses the registered SO to call the latent target CD to indicate to the latent target CD that there is an SDB message that should be delivered to the latent target CD. Using the registered OS allows the latent target CD to go into idle state independently, without the need for the BSC / PCF to send a release order. Messages 606 to 616 are similar to those shown in Fig. 3 with all implementation variations. Upon receiving the Ack command 616 on the latent target CD, the latent target CD cancels timer T42m 618 and goes from the access state to the idle state, allowing the latent target CD to send an SDB 620 message to the BSC / BCF. The latent target CD can transition from the system access state to the idle state after going through the system determination substate. However, the latent target CD can go from the system access state to the idle state without going through the system determination substate.

ES 2 305 807 T3 to reduce waiting time. If the mobile initiated SDB message 620 requires an Ack command message, the BSC / PCF sends the Ack command 622 to the dormant target CD.

Fig. 7 shows a call flow procedure for exchanging information with a latent target CD according to one embodiment. In this embodiment, the illustrated call flow stages 702 to 708 are similar to the call flow stages 502 to 508 described in connection with Fig. 5. However, in step 710, the BSC / PCF superimposes the Ack command 510 for call answer 508 on the SDB message 512 that the BSC / PCF sends to the latent target CD. This eliminates the need to send the Ack command as a separate signaling message, thus reducing the wait time. If the mobile terminated SDB message is a message requiring acknowledgment, the latent target CD sends the Ack command 712 to the BSC / PCF to indicate that it has successfully received the SDB message. To further benefit from the overlap, the Ack command 516 is overlaid on the trigger command 518, at step 714. Steps 716 to 720 are similar to steps 520 to 524 discussed in connection with Fig. 5.

Fig. 8 shows a call flow procedure for exchanging information with a latent target CD according to one embodiment. In this embodiment, the illustrated call flow stages 802 to 808 are similar to call flow stages 602 to 608 described in connection with Fig. 6. However, in step 810, the BSC / PCF superimposes the Ack command 610 for the call response 608 to the SDB message 612 that the BSC / PCF sends to the latent target CD. This eliminates the need to send the Ack command as a separate signaling message, thus reducing the wait time. Upon receiving the SDB from the BSC / PCF in step 810, the latent target CD cancels its timer, in step 812, and puts itself into an idle state. If the mobile terminated SDB message is an acknowledgment request, the latent target CD sends an acknowledgment to the BSC / PCF to indicate that it has successfully received the SDB message. To benefit from the overlap on the reverse link as well, the latent target CD can wait a predetermined period of time to see if there are any mobile originated SDBs to send to the BSC / PCF. If the latent target CD determines during the predetermined period of time that there is an SDB message to send, the Ack command 614 from the SDB message 612 is superimposed on the SDB message 620, in step 814. Otherwise, the Ack command 614 is sent. separately. If the mobile initiated SDB message sent in step 814 requires an Ack command message, the bSc / PCF sends the Ack command 816 to the dormant target CD.

Fig. 9 shows a call flow procedure for exchanging information with a latent target CD according to one embodiment. In this embodiment, the illustrated call flow stages 902 to 910 are similar to the call flow stages 802 to 810 described in connection with FIG. 8. However, step 812 is postponed and the latent target CD transmits the SDB message upon receipt of the SDB message, while the latent target CD is in the system access state. In step 912, the latent target CD superimposes the Ack command for SDB message received from the BSC / PCF on the SDB message to be sent to the BSC / PCF. In this approach, the latent target CD does not need to cancel its timer and go into idle state, thus further reducing the wait time. If the mobile initiated SDB message sent in step 912 requires an Ack command message, the bSc / PCF sends an Ack command 914 to the dormant target CD. The dormant target CD enters the idle state after its timer 916 has expired or for other causes that cause the CD to enter the idle state.

FIG. 10 is a simplified block diagram of one embodiment of a BSC / PCF 1004 and a communication device 1006 capable of implementing various described embodiments. For particular communication, voice, data, data packet and / or alert messages can be exchanged between the BSC / PCF 1004 and the communication device 1006 via an air interface 1008. Various types of messages can be transmitted, such as messages used to establish a communication session between the base station and the communication device, registration and notification messages, and messages used to control a data transmission (for example, power control, data type information, acknowledgment, and more). Some of these types of messages will be described in more detail below.

For the reverse link, at communication device 1006, voice and / or data packets (eg, from a data source 1010) and messages (eg, from a controller 1030) are provided to a transmitting data processor. (TX) 1012 that formats and encodes data and messages with one or more encoding schemes to generate encoded data. Each encoding scheme can include any combination of cyclic redundancy test (CRC), convolutional, turbo, block, and other encodings or no encoding. Voice, data packet and messages can be encoded using different schemes and different types of messages can be encoded differently.

The encoded data is then sent to a modulator (MOD) 1014 and further processed (eg, covered, separated with short PN sequences, and mixed with a long PN sequence assigned to the user terminal). The modulated data is then sent to a transmitter unit (TMTR) 1016 and conditioned (eg, converted to one or more analog signals, amplified, filtered, and quadratically modulated) to generate a reverse link signal. The reverse link signal is routed through a duplicator (D) 1018 and transmitted via an antenna 1020 to the BSC / PCF 1004.

In the BSC / PCF 1004, the reverse link signal is received by an antenna 1050, routed through a duplicator 1052 and sent to a receiver unit (RCVR) 1054. Alternatively, the antenna can be part of the Wireless carrier network and the connection between the antenna and the BS / BSC can be routed through the Internet. The BSC / PCF 1004 can receive media information and alert messages from the remote access device 1006. The receiver unit 1054 conditions (e.g., filters, amplifies, downconverts, and digitizes) the

ES 2 305 807 T3 received signal and provides samples. A demodulator (DEMOD) 1056 receives and processes (eg, distributes, discovers, and pilot demodulates) the samples to provide recovered symbols. The demodulator 1056 may implement a "Rake" type receiver that produces multiple instances of the received signal and generates combined symbols. A receiver data processor (RX) 1058 then decodes the symbols to retrieve the data and messages transmitted on the reverse link. The retrieved audio / data packet is sent to a data collector 1060 and the retrieved messages can be sent to a controller 1070. Controller 1070 may include instructions to receive and send information, receive and send Ack command messages, receive and send responses to Ack command messages, send information, send notification messages and receive responses thereto, and interpret and send numbers. of service options. Processing by demodulator 1056 and RX data processor 1058 are complementary to that performed by remote access device 1006. The demodulator 1056 and RX data processor 1058 can also be used to process multiple transmissions received over the multi-channel path, eg, a reverse fundamental channel (R-FCH) and a reverse supplemental channel (R-SCH). Also, the transmissions can be from multiple mobile stations simultaneously, each of which can be transmitting on a reverse fundamental channel, a reverse supplementary channel, or both.

On the direct link, in the BSC / PCF 1004, voice and / or packet data (for example, from a data source 1062) and messages (for example, from controller 1070) are processed (for example, are formatted and encoded) by a transmitting data processor (TX) 1064, further processed (for example, covered and separated) by a modulator (MOD) 1066, and conditioned (for example, converted to analog signals , are amplified, are filtered and quadratically modulated) by a Transmitter Unit (TMTR) 1068 to generate a forward link signal. The forward link signal is routed through a duplicator 1052 and transmitted via an antenna 1050 to the remote access device 1006. The forward link signals include notification signals.

In communication device 1006, the forward link signal is received by antenna 1020, routed through duplicator 1018, and sent to receiver unit 1022. Receiver unit 1022 conditions (for example, downconverts frequency, filters, amplifies, quadratically modulates and digitizes) the received signal and provides samples. The samples are processed (eg, distributed, discovered, and pilot demodulated) by a demodulator 1024 to provide symbols, and the symbols are further processed (eg, decoded and verified) by a receiving data processor 1026 to retrieve the data and messages transmitted on the direct link. The retrieved data is transmitted to a data collector 1028, and the retrieved messages can be sent to a controller 1030. Controller 1030 may include instructions to receive and send information, receive and send Ack command messages, receive and send responses to Ack command messages, send information, receive notification messages and send responses thereto, move to and from a state. inactivity, and receive and interpret service option numbers. Accordingly, the described embodiments provide a significant reduction in information exchanged with target CDs that are latent and have no active traffic channel.

The described methods and apparatus provide an efficient mechanism for exchanging information with latent target CDs, using service option numbers that signify that information is being communicated in the form of short data bursts (SDB).

Those skilled in the art will understand that information and signals can be represented using any of several different technologies and protocols. For example, data, instructions, commands, information, signals, bits, symbols and chips that may appear in the present description can be represented by voltages, currents, electromagnetic waves, magnetic particles or fields, optical particles or fields, or any combination. thereof.

Those skilled in the art will also note that the various illustrative steps of logic blocks, modules, circuits, and algorithms described in connection with the embodiments described herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular design and application restrictions imposed on the entire system. Those skilled in the art can implement the described functionality in various ways for each particular application, but such implementation decisions should not be construed as departing from the scope of the present invention.

The various logic blocks, modules and circuits described in connection with the embodiments discussed herein can be implemented or carried out with a general application processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC ), a field programmable gate array (FPGA) or other programmable logic device, discrete port or logic transistor, discrete hardware components, or any combination thereof designed to carry out the functions described herein. A general processor can be a microprocessor but, alternatively, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, for example, 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 similar configuration.

ES 2 305 807 T3

The steps of a procedure or algorithm described in relation to the embodiments described herein can be performed directly in hardware, in a software module executed by a processor, or in a combination of both. A software module can reside in a RAM memory, in a flash memory, in a ROM memory, in an EPROM memory, in an EEPROM memory, in registers, on a hard disk, on a removable disk, on a CDROM, or on any another type of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read the information from, and write the information to, the storage medium. Alternatively, the storage medium can be integrated into the processor. The processor and storage medium can reside in an ASIC. The ASIC can be in a user terminal. Alternatively, the processor and storage medium can be included in a user terminal as discrete components.

The description of the described embodiments is made to enable any person skilled in the art to make or use the present invention. Various modifications of these embodiments may be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments, for example, for an instant messaging service or any data communication application. general wireless. The word "exemplary" is used exclusively to mean "serving as an example, case or illustration." Any embodiment described herein as "exemplary" should not necessarily be considered preferred or advantageous over other embodiments.