HK1162091B - Synchronizing bearer context - Google Patents

Description

Synchronizing bearer contexts

Require priority

This patent application claims priority benefits from commonly owned U.S. provisional patent application No.61/100,598, filed on 26.9.2008, assigned attorney docket No.082856P1, the disclosure of which is incorporated herein by reference.

Technical Field

The present invention relates generally to wireless communications, and more particularly, but not exclusively, to synchronizing bearer contexts (bearercontext).

Background

Wireless communication networks are widely deployed to provide various types of communication content (e.g., voice, data, multimedia services, etc.) to multiple users. In a typical network, an access terminal (e.g., a cellular telephone) is connected to the network via an access point, such that traffic flows between the access terminal and a desired endpoint (e.g., a server or a telephone) through several network nodes. To facilitate such traffic flows, the network sets up one or more bearers that provide quality of service (QoS) for the traffic flows. Thus, once a bearer is set, both the access terminal and the network maintain a bearer context for the bearer. Such bearer context includes, for example, information that may be used in connection with identifying and processing packets of a given traffic flow. In particular, the bearer context includes a bearer identifier, packet filter information, and QoS information.

In some cases, the network sets up the bearer in response to a resource request initiated by the access terminal. For example, when a user initiates a call with an access terminal, the access terminal may send a message to the network requesting the network to set up resources for the call. In response, the network may set up a bearer for the traffic flow for the call. Once the access terminal no longer requires resources (e.g., the user ends the call), the access terminal sends a resource release request to the network. The network can then deactivate the bearer, thereby synchronizing the bearer context state (e.g., deactivated state) between the network and the access terminal.

However, in some cases, the network may not receive a resource release request from the access terminal. For example, the access terminal may have temporarily moved out of the coverage area of the network. Thus, the bearer context maintained by the access terminal and the network cannot be properly synchronized under these conditions. For example, the network is unaware that these resources should be released.

Disclosure of Invention

The following is a summary of exemplary aspects of the invention. In the discussion herein, any reference to the term "aspect" may refer to one or more aspects of the present invention.

In some aspects, the present invention relates to local deactivation (local deactivation) of bearer contexts. For example, if the access terminal determines that resources previously requested by the access terminal are no longer needed, the access terminal can locally deactivate the bearer context. Such local deactivation may be employed, for example, in the event that the access terminal is unable to communicate with the network.

In some aspects, the present invention relates to synchronizing bearer context between an access terminal and a network. Herein, an access terminal locally deactivates a bearer context after losing communication with a network, and once the access terminal reestablishes communication with the network, the access terminal can synchronize its bearer context with the network. For example, the access terminal may send a message to the network indicating that the access terminal deactivated the bearer context. Based on the message, the network may update the state of the respective bearer context maintained at the network. In some aspects (e.g., in a Long Term Evolution (LTE) network), the message may comprise a tracking area update message.

Drawings

These and other exemplary aspects of the present invention will be described in the detailed description and appended claims that follow, as well as in the accompanying drawings, in which:

fig. 1 is a simplified block diagram of several exemplary aspects of a communication system configured to support bearer context synchronization.

Fig. 2A and 2B are flow diagrams of several exemplary aspects of operations that may be performed to synchronize bearer contexts.

Fig. 3 is a simplified block diagram of several exemplary aspects of components that may be employed in a communication node.

Fig. 4 is a simplified call flow diagram illustrating several exemplary operations that may be performed for synchronizing bearer contexts.

Fig. 5 is a simplified call flow diagram illustrating several exemplary operations that may be performed for synchronizing bearer contexts.

FIG. 6 is a simplified block diagram of several exemplary aspects of a communications component;

fig. 7 and 8 are simplified block diagrams of several exemplary aspects of an apparatus for providing bearer context synchronization as disclosed herein.

In accordance with common practice, the various features shown in the drawings may not be drawn to scale. Accordingly, the dimensions of the various features may be arbitrarily expanded or reduced for clarity. Moreover, some of the drawings may be simplified for clarity. Accordingly, the drawings may not show all of the components of a given apparatus (e.g., device) or method. Finally, the same reference numerals may be used throughout the specification and drawings to refer to the same or like features.

Detailed Description

Various aspects of the invention are described below. It should be understood that the present disclosure may be embodied in various forms and that any specific structure, function, or both being disclosed herein is merely exemplary. Based on the disclosure herein, one of ordinary skill in the art will appreciate that an aspect disclosed herein may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented or a method may be practiced using any of the aspects set forth herein. In addition, such an apparatus may be implemented or such a method may be practiced using other structure, functionality, or structure and functionality in addition to or other than one or more of the aspects set forth herein. Furthermore, an aspect may comprise at least one element of a claim.

Fig. 1 illustrates several nodes (e.g., portions of a communication network) of an exemplary communication system 100. For purposes of illustration, various aspects of the invention may be described in the context of one or more access terminals, access points, and network entities in communication with one another. However, it should be understood that the teachings herein may be applied to other types of devices that are referred to using other terms or other similar devices. For example, in various aspects, an access point may be referred to or may be implemented as a base station or eNodeB, an access terminal may be referred to or may be implemented as a user equipment or mobile device, and so on.

An access point in system 100 provides one or more services (e.g., network connections) to one or more wireless terminals that may be installed within the coverage area of system 100 or may roam between the coverage areas of system 100. For example, at a different point in time, the access terminal 102 may connect to the access point 104 or some other access point (not shown). Each access point in system 100 may communicate with one or more network entities (represented for convenience by network entity 106) to facilitate wide area network connectivity. These network entities may take various forms, such as one or more radio and/or core network entities. Thus, in various aspects, the network entity 106 may represent functionality such as at least one of: network management (e.g., via an operations, enforcement, management, and provisioning entity), call control, session management, mobility management, gateway functions, interworking functions, or some other appropriate network function.

The access terminal 102 and the network entity 106 (e.g., mobility management entity MME) maintain information (bearer contexts 108 and 110, respectively) about bearers set by the network entity 106 for traffic flows to and/or from the access terminal 102. In some cases, the network entity 106 may set this bearer in response to a resource request from the access terminal. At some later point in time, the access terminal 102 may send a request to release these resources and thus trigger the release of the relevant bearer context. The access terminal 102 may locally deactivate the bearer context 108 when the access terminal 102 is unable to communicate with the network entity 106 (e.g., because the access terminal 102 is out of network coverage when sending the request). Subsequently, when the access terminal 102 is able to communicate with the network entity 106 again (e.g., the access terminal 102 returns to network coverage), the access terminal 102 synchronizes the bearer context 108 with the network entity 106. For example, the access terminal 102 may send a message (represented by dashed line 112) to the network entity 106 indicating that the bearer context 108 has been deactivated.

Bearer context synchronization may be implemented in various ways in accordance with the teachings herein. For example, in an Evolved Packet System (EPS) of an LTE network, a user equipment (e.g., access terminal 102) sends a BEARER RESOURCE MODIFICATION REQUEST non-access stratum (NAS) message to an MME (e.g., network entity 106) to modify certain aspects of a given BEARER (e.g., a release REQUEST for RESOURCEs). A timer T3481 is then started, which is used to determine whether an appropriate response has been received within a given period of time. At the first expiration of the timer T3481, the User Equipment (UE) should retransmit the BEARER RESOURCE MODIFICATION REQUEST and reset and restart the timer T3481. This retransmission is repeated four times, i.e., at the fifth expiration of timer T3481, the UE should abort the PROCEDURE, release the PROCEDURE TRANSACTION Identifier (PTI) assigned for this activation and enter the PROCEDURE TRANSACTION INACTIVE state. Furthermore, if the UE initiates a resource release for all traffic flows of the bearer, the UE locally deactivates the EPS bearer context in case no end-to-end signaling is performed between the UE and the MME. To synchronize the EPS bearer context state with the MME, the UE shall send TRACKING AREA UPDATE REQUEST message to the MME, according to the indication from the lower layer "return E-UTRAN coverage area". This message may include, for example, an indication (explicit or implicit indication) that the bearer context was deactivated at the UE.

Exemplary operations that may be employed by the system 100 are now described in detail in conjunction with fig. 2A and 2B. For convenience, the operations of fig. 2A and 2B (or any other operations discussed or taught herein) may be described as being performed by specific components. However, it should be understood that these operations may be performed by other types of components, and may be performed using a different number of components. It should also be understood that one or more of the operations described herein may not be employed in a given scenario.

As shown in block 202 of fig. 2A, at some point in time, an access terminal sends a resource request to a network (e.g., a network entity such as a packet data network gateway, PGW). Such access terminal-initiated resource requests may be triggered, for example, by a user of the access terminal or an application initiating a traffic flow (e.g., call, download, etc.) at the access terminal.

Herein, the resource request may include a request for Internet Protocol (IP) flow resources from the network. Thus, the request may include IP packet filter information and QoS information for the traffic flow.

In some aspects, the QoS information specifies how traffic for a traffic flow is to be handled. For example, the QoS information may specify at least one of: a desired or required level of information loss (e.g., maximum packet loss), a desired or required delay (e.g., maximum packet delay), a desired or required data rate, priority, or some other quality-related characteristic. In LTE-based networks, QoS information may include a Quality Class Identification (QCI) that indicates, for example, the type of delay or packet loss expected for an IP packet flow and the type of priority given for the IP packet flow.

In some aspects, IP packet filter information is used to identify a given IP traffic flow (e.g., packet flow) associated with a particular bearer. To this end, the IP packet filter contains information that can be compared to packet IP header information used to identify the packet. For example, the IP packet filter information may include at least one of: source address, destination address, source port, destination port, or protocol (e.g., higher layer protocol being used, such as UDP or TCP). In some cases, the packet filter may include a wildcard address defined to match an arbitrary address and/or a wildcard port defined to match an arbitrary port. Typically, a packet filter includes a 5-tuple (5-tuple) containing a source address, a destination address, a source port, a destination port, and a protocol.

As shown in block 204, as a result of the resource request, the network entity (e.g., MME) will allocate the requested resources and set up the associated bearers (e.g., dedicated bearers). In some aspects, a bearer defines a logical conduit that specifies how a network handles traffic flow to and/or from an access terminal (e.g., specifies a QoS to apply to the traffic). Here, the network entity maps the packet filter associated with the resource request to the bearer by setting a new bearer or by modifying an existing bearer. As an example of the latter case, where a bearer with the requested QoS has been set (e.g., for another packet filter), the network entity may modify the bearer to include the packet filter provided by the request.

After the bearer is set, the network entity maintains a bearer context for the bearer, as shown at block 206. For example, the network entity may store the bearer context in a data store and update the bearer context, if desired. Herein, the bearer context includes a bearer identifier, QoS information, and at least one packet filter.

As shown at block 208, in connection with bearer setup, the access terminal obtains a bearer context for the bearer. For example, the access terminal can store a bearer identifier for the bearer (e.g., sent by the network entity in connection with the setup bearer), QoS information, and packet filters in a data store. The access terminal may then maintain the bearer context for the bearer (e.g., update the bearer context as needed). Herein, an access terminal may employ various techniques to associate a resource request (e.g., a packet filter for the request) to a bearer allocated by a network entity.

As one example, the association may be based on a process transaction id (pti). Herein, an access terminal may compare a PTI included in a resource request to a PTI provided in a bearer setup (e.g., bearer setup or modification) message received from a network entity to determine whether to associate a corresponding bearer with the resource request.

As another example, the association may be based on packet filter identification information. Herein, an identifier associated with a packet filter may be sent to a network via a resource request. The network entity may then include the packet filter identifier in a bearer setup message directed to the access terminal. Accordingly, the access terminal can compare the transmitted identifier with the received identifier to determine whether to associate the corresponding bearer with the resource request.

As another example, the association may be based on a comparison of the packet filter to a traffic filter template for the bearer. Herein, when a network entity sends a message to an access terminal in connection with setting up a bearer, the network entity may indicate which packet filter is associated with this bearer. The access terminal may then compare the packet filter sent with the resource request to a packet filter sent by a network entity to determine whether to associate the corresponding bearer with the resource request.

Once the bearer is set, the bearer context is used to facilitate communications between the access terminal and some other node (e.g., phone, server, etc.) via the network, as shown at block 210. For example, when a network (e.g., PGW) receives packets from other nodes, the network compares the packet header information to the packet filters and assigns the packets to the appropriate bearers based on the comparison. In this way, the network can employ an appropriate QoS when routing packets to the access terminal.

At some point in time, the access terminal may lose connection with the network entity (e.g., be unable to communicate with the MME), as shown at block 212. For example, an access terminal may move out of the wireless coverage area of the network, may be subject to excessive interference, may experience a coverage outage, and so on.

The access terminal may also attempt to send a message to the network entity requesting release of the previously requested resources, as shown at block 214 of fig. 2B. For example, a user of the access terminal or an application executing on the access terminal may choose to terminate the traffic flow initiated at block 202 (e.g., the user may end a cellular telephone call or data feed). In this case, the access terminal may send a message indicating that the packet filter and associated QoS should be released.

Herein, the access terminal initiates a resource release so that the network entity can update its status accordingly (e.g., update status information for existing bearers). For example, in the normal case where the network entity receives a release request, the network entity may deactivate (e.g., release or delete) the allocated bearer.

However, in the event that the access terminal loses connectivity with the network, the network entity will not receive the resource release message from the access terminal. Thus, the access terminal will not receive a message (e.g., a resource release message) from the network entity in response to the resource release request (e.g., no message received within a predetermined timeout period). In such a case, the access terminal can deactivate (e.g., release or delete) the bearer context associated with the release of resources locally, as indicated at block 216, by invalidating (e.g., marking as invalid, deleting, releasing, etc.) the packet filter associated with the bearer context. As will be described in detail in connection with fig. 5, in general, an access terminal locally deactivates a bearer context only when all packet filters associated with the bearer context are deactivated at the access terminal. In either case, the access terminal maintains a record that the bearer context is deactivated so that it can report as described below.

At some point in time, the access terminal regains a connection with the network entity, as shown in block 218. For example, the access terminal may return to the wireless network coverage area, interference may be reduced, a power down may pass, and so on. In some cases, connection reacquisition may be identified by processing an indication back to radio coverage from a lower layer (e.g., layer 2).

The access terminal may then synchronize the bearer context with the network entity, as shown at block 220. For example, an access terminal may send a message to a network entity indicating (explicitly or implicitly) which bearer context is deactivated locally by the access terminal. In this way, the network can determine which resources need to be released. As will be discussed in detail in connection with fig. 4, in some cases, this message may comprise a Tracking Area Update (TAU) message.

In some aspects, the message may explicitly indicate which bearer context to deactivate. For example, if the bearer context for bearer a is deactivated, the message may indicate that this particular bearer context is deactivated.

In some aspects, the message may implicitly indicate which bearer context was deactivated. For example, the network entity may know that the access terminal used bearers A, B and C before the access terminal lost coverage. After returning to the coverage area, the access terminal may send a message indicating that bearers B and C are currently active. Thus, the network entity can determine that the access terminal deactivated the bearer context for bearer a.

In conjunction with synchronizing the bearer context, the network entity updates the state of the bearer context maintained at the network entity, as shown at block 222. For example, the network entity may deactivate the appropriate bearer context, deactivate (e.g., release or delete) the corresponding bearer, and release the corresponding resources.

Herein, a network entity may determine which bearer context is deactivated at an access terminal based on a message received from the access terminal. As described above, in some cases, this involves reading a display indication from the message, while in other cases, this involves inferring which bearer context was deactivated based on information received in the message and other information maintained by the network entity (e.g., a list identifying each bearer context maintained for the access terminal).

The above-described scheme advantageously provides an efficient mechanism for synchronizing bearer contexts. In particular, when the network is not reachable, the access terminal may simply delete the appropriate bearer context. This scheme may therefore be implemented more efficiently than alternatives such as the access terminal tracking whether it receives a message in response to a resource release request and, if not, retransmitting the resource release request to release resources after the access terminal returns to coverage. In this alternative, the NAS layer needs to maintain a longer timer for NAS message expiration and may require undesirable NAS status layer management (e.g., to remember the NAS message status).

Fig. 3 illustrates several exemplary components that may be incorporated into nodes, such as the access terminal 102 and the network entity 106, to perform bearer context synchronization operations in accordance with the teachings herein. The described components may also be incorporated into other nodes of a communication system. For example, other nodes in the system may include components similar to those described for the access terminal 102 and the network entity 106 to provide similar functionality. Further, a given node may include one or more of the described components. For example, an access terminal may include multiple transceiver components that enable the access terminal to operate on multiple frequencies and/or communicate via different technologies.

As shown in fig. 3, the access terminal 102 includes: a transceiver 302 for communicating with other nodes. The transceiver 302 includes: a transmitter 304 for transmitting signals (e.g., resource requests, resource release requests, and synchronization messages); a receiver 306 for receiving a signal (e.g., a bearer setup message).

The network entity 106 includes: a network interface 308 for communicating with other network nodes (e.g., sending bearer setup messages and receiving resource requests, resource release requests, and synchronization messages). For example, network interface 308 may be used to communicate with one or more network nodes via a wired or wireless backhaul.

The access terminal 102 and the network entity 106 include other components that may be used in conjunction with the bearer context synchronization operations taught herein. For example, the access terminal 102 and the network entity 106 may each include: communication controllers 310 and 312 for managing communications with other nodes (e.g., sending and receiving messages, requests, and indications) and for providing other related functions (e.g., as disclosed herein). Further, the access terminal 102 and the network entity 106 may include: bearer context managers 314 and 316 for managing bearer contexts (e.g., setting, obtaining, maintaining, deactivating, and determining bearer contexts and updating states) and for providing other related functionality (e.g., as disclosed herein). Further, the access terminal 102 may include: synchronizer 318 to synchronize bearer contexts (e.g., in cooperation with or as part of bearer context manager 314) and to provide other related functionality (e.g., as disclosed herein).

Referring now to fig. 4, for purposes of illustration, exemplary bearer management operations will be described in the context of an LTE network. Therefore, LTE terminology will be used in this example. It should be understood that these operations may be applicable to other types of networks.

As shown, signals to and from a UE are routed through a plurality of network entities including an enhanced node b (enb), an MME, a Serving Gateway (SGW), and a PGW. The illustrated operational flow begins at block 402, for example, by the launching of an application on the UE. The UE requests resources from the network, as shown in block 404, which triggers the network to set up the bearer, in block 406. In this example, the resource request identifies two packet filters designated as PF1 and PF 2. As described above, when the UE requests resources from the network, the UE maintains association information between the packet filter and the assigned bearer in block 408. For this particular example, PF1 and PF2 are associated with bearer context a.

The UE application terminates at some point in time, as shown in block 410. It should be noted herein that this termination may be active (e.g., ending the call) or inactive (e.g., losing coverage). Once the UE application is terminated, the UE sends a resource release REQUEST (e.g., BEARER resource modification REQUEST), as shown in block 412. However, herein, if the network is unreachable at the time the UE sends the request, the request cannot reach the network, as shown by "X" 414 (e.g., after the fifth expiration of timer T3481). In this case, the UE may abort the PROCEDURE, release the PTI allocated for the activation, and enter a PROCEDURE TRANSACTION INACTIVE state. The UE marks the packet filter associated with the resource release as invalid, as shown in block 416, and may locally deactivate the bearer context if all packet filters associated with the bearer context become invalid in this process (e.g., the UE initiated the resource release for all traffic flows of the bearer). It should be understood herein that the UE deactivates the bearer context in case no end-to-end signaling is performed between the UE and the MME. After the UE returns to coverage (e.g., upon an indication from the lower layer of "return to E-UTRAN coverage"), at block 418, the UE synchronizes the bearer context state with the MME by sending a TAU request or equivalent message to the MME, at block 420. The information carried by this message indicates which bearer was deleted, as described herein, so that the network can release the resources appropriately at block 422.

As described above, in some cases, more than one packet filter may be associated with a given bearer (e.g., with a related bearer context). In these cases, the access terminal may not locally deactivate the bearer context until all packet filters associated with the bearer context have been deactivated (e.g., marked as invalid, deleted, released, etc.). Thus, in the case where the UE is out of coverage and releases IP resources, but only a portion of the packet filters associated with the bearer are marked as invalid (e.g., PF1 is invalid, but PF2 is still valid), bearer context a may not be deleted. Fig. 5 illustrates exemplary operations that may be employed in these situations. For purposes of illustration, these operations may also be described in the context of an LTE-based network.

As shown, messages to and from the UE are re-routed through a plurality of network entities including eNB, MME, SGW and PGW. Further, blocks 502, 504, 506, and 508 are similar to blocks 402, 404, 406, and 408 of FIG. 4. At some point in time, the UE loses coverage, as shown in block 510. When out of coverage, assume that the user or some other stimulus initiates a change to the UE application, as shown in block 512.

The UE sends a resource release request to release resources that are no longer used by the application, block 514. In this example, the UE sends a resource release request only for PF 1. When the network is not reachable, the resource release request does not successfully reach the network, as shown by "X" 516. Upon detecting this failure, the UE marks PF1 as inactive at block 518, but keeps the bearer context a active since PF2 is still active. When the UE again obtains coverage, the bearer context a is still active, block 520.

The UE application is terminated at some point in time, as shown in block 522. After terminating the application, the UE sends a request resource release for PF2 at block 524. At block 526, the network modifies bearer a to remove resources associated with PF 2.

The UE deactivates bearer context a, as shown in block 528. Herein, in general, when the UE or the network removes the remaining packet filters for bearer a, the UE may find that all packet bearers related to the bearer context are invalid and thus deactivate the bearer context. In this particular example, when PF2 is removed, the UE finds that all packet filters are invalid for bearer context a, and this causes the UE to deactivate the bearer context for bearer a.

The UE then sends a TAU or equivalent message to the network, block 530. As described above, the message contains information indicating which bearer context is deactivated so that the network may release resources appropriately at block 532.

The bearer context synchronization scheme taught herein may be implemented in various ways. For example, when multiple bearers are used, the techniques described herein may be employed. In some cases, different bearers may be used to support different traffic flows for a given access terminal. Further, the network may support different bearers for different access terminals. In such a case, the entities discussed herein (e.g., the access terminal and the MME) may synchronize the bearer context for each of these bearers in accordance with the teachings herein.

The teachings herein may be used in a wireless multiple-access communication system that simultaneously supports communication for multiple wireless access terminals. In this context, each terminal may communicate with one or more access points via transmissions on forward and reverse links. The forward link (or downlink) refers to the communication link from the access points to the terminals, and the reverse link (or uplink) refers to the communication link from the terminals to the access points. Such a communication link may be established via a single-input single-output (SISO) system, a multiple-input multiple-output (MIMO) system, or some other type of system.

MIMO systems employing multiple (N)_T) Transmitting antenna and a plurality of (N)_R) And the receiving antenna is used for data transmission. From N_TA transmitting antenna and N_RMIMO channel formed by multiple receiving antennas can be decomposed into N_SA separate channel, which may also be referred to asSpatial channels of which N_S≤min{N_T，N_R}。N_SEach of the individual channels corresponds to a dimension. MIMO systems may provide enhanced performance (e.g., higher throughput and/or greater reliability) if the additional dimensionalities created by the multiple transmit and receive antennas are utilized.

MIMO systems may support Time Division Duplexing (TDD) and Frequency Division Duplexing (FDD). In a TDD system, the forward and reverse link transmissions are on the same frequency region, so the reciprocity principle allows the estimation of the forward link channel from the reverse link channel. This allows the access point to extract transmit beamforming gain on the forward link when multiple antennas are available at the access point.

Fig. 6 illustrates a wireless device 610 (e.g., an access point) and a wireless device 650 (e.g., an access terminal) of an exemplary MIMO system 600. At the device 610, traffic data for a number of data streams is provided from a data source 612 to Transmit (TX) data processor 614. Each data stream is then transmitted over a respective transmit antenna.

TX data processor 614 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data. The coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data is typically a known data pattern that is processed in a known manner and used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream is then modulated (e.g., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QSPK, M-PSK, or M-QAM) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions performed by processor 630. A data memory 632 may store program code, data, and other information used by the processor 630 or other components of the device 610.

The modulation symbols for all data streams are then provided to a TX MIMO processor 620, which may further process the modulation symbols (e.g., for OFD)M). TX MIMO processor 620 then forwards to N_TA plurality of transceivers (XCVR)622A through 622T provide N_TA stream of modulation symbols. In some embodiments, TX MIMO processor 620 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

Each transceiver 622 receives and processes a respective symbol stream to provide one or more analog signals, and also conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. Then, respectively from N_TThe antennas 624A-624T transmit N from the transceivers 622A-622T_TA modulated signal.

At device 650, by N_RThe transmitted modulated signals are received by antennas 652A through 652R and the received signal from each antenna 652 is provided to a respective transceiver (XCVR)654A through 654R. Each transceiver 654 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding "received" symbol stream.

Then, a Receive (RX) data processor 660 from N_RA transceiver 654 receives N_ROne symbol stream and process the N based on a particular receiver processing technique_RA stream of symbols to provide N_TA "detected" symbol stream. The RX data processor 660 then demodulates, deinterleaves, and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor 660 is complementary to that performed by TX MIMO processor 620 and TX data processor 614 at device 610.

A processor 670 periodically determines which precoding matrices to use (discussed below). Processor 670 formulates a reverse link message comprising a matrix index portion and a rank value portion. A data memory 672 may store program code, data, and other information used by the processor 670 or other components of the device 650.

The reverse link message may comprise various types of information regarding the communication link and/or the received data stream. The reverse link message is then processed by a TX data processor 638, which also receives traffic data for a number of data streams from a data source 636, modulated by a modulator 680, conditioned by transceivers 654A through 654R, and transmitted back to the device 610.

At the device 610, the modulated signals from the device 650 are received by the antennas 624, conditioned by the transceivers 622, demodulated by a demodulator (DEMOD)640, and processed by a RX data processor 642 to extract the reverse link message transmitted by the device 650. Processor 630 then determines which pre-coding matrices to use for determining the beam-program weights then processes the extracted message.

Fig. 6 also illustrates communication components that may include one or more components taught herein to perform bearer context related operations. For example, bearer control component 692 may cooperate with processor 670 and/or other components of device 650 to send/receive signals to/from another device (e.g., device 610) using the bearer context, or to manage the bearer context. It should be understood that for each device 610 and 650, the functionality of two or more of the described components may be provided by a single component. For example, a single processing component may provide the functionality of the bearer control component 692 and the processor 670.

The teachings herein may be incorporated into various types of communication systems and/or system components. In some aspects, the teachings herein may be used in multiple-access systems capable of supporting communication with multiple users by sharing available system resources (e.g., by specifying one or more of bandwidth, transmit power, coding, interleaving, etc.). For example, the teachings herein may be applied to any one or combination of the following technologies: code Division Multiple Access (CDMA) systems, multi-carrier CDMA (MCCDMA), wideband CDMA (W-CDMA), high speed packet access (HSPA, HSPA +) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, single carrier FDMA (SC-FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, and other multiple access techniques. A wireless communication system employing the teachings herein may be designed to implement one or more standards such as IS-95, CDMA2000, IS-856, W-CDMA, TDSCDMA, and others. CDMA network realiableRadio technologies such as Universal Terrestrial Radio Access (UTRA), cdma2000, or some other technology are known. UTRA includes W-CDMA and Low Chip Rate (LCR). cdma2000 technology covers IS-2000, IS-95 and IS-856 standards. TDMA systems may implement radio technologies such as global system for mobile communications (GSM). OFDMA systems may implement radio technologies such as evolved UTRA (E-UTRA), IEEE 802.11, IEEE 802.16, IEEE 802.20, flashAnd the like. UTRA, E-UTRA and GSM are part of the Universal Mobile Telecommunications System (UMTS). The teachings herein may be implemented in a 3GPP Long Term Evolution (LTE) system, an Ultra Mobile Broadband (UMB) system, and other types of systems. LTE is a UMTS release using E-UTRA. UTRA, E-UTRA, UMTS and LTE are described in documents from an organization named "third generation partnership project" (3GPP), and cdma2000 is described in documents from an organization named "third generation partnership project 2" (3GPP 2). Although various aspects of the present invention may be described using 3GPP terminology, it is understood that the teachings herein may be applied to 3GPP (e.g., Rel99, Rel5, Rel6, Rel7) technologies as well as 3GPP2 (e.g., 1xRTT, 1xEV-DO RelO, RevA, RevB) technologies and other technologies.

The teachings herein may be incorporated into (e.g., implemented in or performed by) various apparatuses (e.g., nodes). In some aspects, a node (e.g., a wireless node) implemented in accordance with the teachings herein may comprise an access point or an access terminal.

For example, an access terminal may comprise, be implemented as, or known as user equipment, a subscriber station, a subscriber unit, a mobile station, a mobile node, a remote station, a remote terminal, a user agent, user equipment, or some other terminology. In some aspects, an access terminal may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or smart phone), a computer (e.g., a laptop), a portable communication device, a portable computing device (e.g., a personal digital assistant), an entertainment device (e.g., a music device, a video device, or a satellite radio), a global positioning system device, or any other suitable device for communicating via a wireless medium.

An access point may include, be implemented as, or known as a node B, eNodeB, a Radio Network Controller (RNC), a Base Station (BS), a Radio Base Station (RBS), a Base Station Controller (BSC), a Base Transceiver Station (BTS), a Transceiver Function (TF), a radio transceiver, a radio router, a basic service set (BSs), an Extended Service Set (ESS), a macrocell, a home enb (henb), a femtocell, a femtonode, a pico node, or some other similar terminology.

In some aspects, a node (e.g., an access point) may comprise an access node for a communication system. Such an access node may provide a connection for or to a network (e.g., a wide area network such as the internet or a cellular network), for example, via a wired or wireless communication link to the network. Thus, an access node may enable another node (e.g., an access terminal) to access a network or some other functional unit. Further, it should be understood that in some cases one or both of the nodes may be portable, or relatively non-portable.

Further, it should be understood that a wireless node may be capable of sending and/or receiving information in a non-wireless manner (e.g., via a wired connection). Thus, the receivers and transmitters discussed herein may include appropriate communication interface components (e.g., electronic or optical interface components) that communicate via a non-wireless medium.

The wireless nodes may communicate via one or more wireless communication links based on or supporting any suitable wireless communication technology. For example, in some aspects a wireless node may be associated with a network. In some aspects, the network may comprise a local area network or a wide area network. The wireless device may support or use one or more of various wireless communication technologies, protocols, or standards (e.g., CDMA, TDMA, OFDM, OFDMA, WiMAX, Wi-Fi, etc.) as discussed herein. Similarly, the wireless node may support or use one or more of various respective modulation or multiplexing schemes. Accordingly, the wireless node may include appropriate components (e.g., air interfaces) to establish and communicate via one or more wireless communication links using the above-described or other wireless communication techniques. For example, a wireless node may include a wireless transceiver with associated transmitter and receiver components, which may include various components (e.g., signal generators and signal processors) that facilitate communication over a wireless medium.

In some aspects, the functionality described herein (e.g., with respect to one or more of the figures) may correspond to the functionality "modules" similarly indicated in the appended claims. Referring to fig. 7 and 8, the devices 700 and 800 are shown as a series of interrelated functional modules. Herein, at least in some aspects, bearer context obtaining module 702 may correspond to, for example, a bearer context manager as discussed herein. In at least some aspects, bearer context deactivation module 704 may correspond to, for example, a bearer context manager as discussed herein. In at least some aspects, bearer context synchronization module 706 may correspond to, for example, a synchronizer discussed herein. In at least some aspects, the sending module 708 may correspond to, for example, a communication controller as discussed herein. In at least some aspects, bearer context maintenance module 802 may correspond to, for example, a bearer context manager as discussed herein. In at least some aspects, the receiving module 804 may correspond to, for example, a communication controller as discussed herein. In at least some aspects, bearer context state update module 806 may correspond to, for example, a bearer context manager as discussed herein. In at least some aspects, the deactivated bearer context determination module 808 may correspond to, for example, a bearer context manager as discussed herein. In at least some aspects, bearer context setup module 810 may correspond to, for example, a bearer context manager as discussed herein.

The functionality of the modules of fig. 7 and 8 may be implemented in a variety of ways consistent with the teachings herein. In some aspects, the functionality of these modules may be implemented as one or more electronic components. In some aspects, the functions of these blocks may be implemented as a processing system including one or more processor components. In some aspects, the functionality of these modules may be implemented using, for example, at least a portion of one or more integrated circuits (e.g., an ASIC). As described above, an integrated circuit may include a processor, software, other related components, or some combination thereof. The functionality of these modules may also be implemented in some other way than as taught herein. In some aspects, one or more of any of the dashed boxes of fig. 7 and 8 are optional.

It will be understood that any reference herein to elements using, for example, "first," "second," etc., does not generally limit the number or order of such elements. Rather, these designations may be used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, references to first and second elements do not imply that only two elements may be employed or that the first element must somehow precede the second element. Further, unless stated otherwise, a set of elements may include one or more elements. Furthermore, the term "at least one of the forms A, B or C" as used in the specification or claims means "a or B or C or any combination of these elements".

Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of skill would further appreciate that the various illustrative logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which may be designed using source coding or some other technique), various forms of program or design code incorporating instructions (which may be referred to herein, for convenience, as "software" or a "software module"), or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits described in connection with the aspects described herein may be implemented or performed in an Integrated Circuit (IC), an access terminal, or an access point. The IC may include a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electronic components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute code or instructions that reside within the IC, external to the IC, or both. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may 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.

It is understood that any particular order or hierarchy of steps in any disclosed process is an example of an exemplary approach. It is understood that the specific order or hierarchy of steps in the processes may be rearranged based on design preferences, while remaining within the scope of the present invention. The figures and claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination. If implemented in software, the functions may be stored on a computer-readable medium or transmitted as one or more instructions or code thereon. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one location to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store other program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media. It should be appreciated that the computer-readable medium may be implemented in any suitable computer program product.

The previous description of the disclosed examples is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these examples will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other examples without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the examples shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (41)

1. A method for communication, comprising the steps of:

obtaining a bearer context at an access terminal;

deactivating the bearer context at the access terminal, wherein the deactivating is triggered if the access terminal is unable to communicate with a network entity;

re-acquiring a connection with the network entity; and

after the deactivating step, synchronizing the bearer context with the network entity.

2. The method of claim 1, wherein:

triggering the deactivating step by the access terminal initiating a resource release for all traffic flows related to the bearer context;

performing the deactivating step locally at the access terminal in the absence of end-to-end signaling between the access terminal and the network entity; and

the synchronizing step comprises sending a tracking area update request to the network entity.

3. A method as recited in claim 2, wherein the tracking area update request is sent in response to an indication provided by lower layer processing to return to wireless coverage.

4. The method of claim 1, further comprising the steps of:

sending a resource release request to the network entity, wherein the deactivating step is triggered if the access terminal does not receive a resource release message from the network entity in response to the resource release request.

5. The method of claim 1, wherein the deactivating step is triggered if each packet filter associated with the bearer context is indicated as invalid.

6. The method of claim 1, wherein the synchronizing step comprises: sending a message indicating that the bearer context has been deactivated.

7. The method of claim 6, wherein the message is transmitted if the access terminal returns to radio coverage.

8. The method of claim 6, wherein the message identifies any bearer context that is active at the access terminal.

9. The method of claim 1, wherein the bearer context comprises packet filter information and quality of service information.

10. The method of claim 1, wherein the bearer context is obtained as a result of a resource request initiated by the access terminal.

11. The method of claim 1, wherein the network entity comprises a mobility management entity.

12. An apparatus for communication, comprising:

a bearer context manager to obtain a bearer context at an access terminal and further to deactivate the bearer context at the access terminal, wherein the deactivation is triggered if the access terminal is unable to communicate with a network entity; and

a synchronizer to synchronize the bearer context with the network entity after the deactivating, wherein the synchronizing is performed after regaining connectivity with the network entity.

13. The apparatus of claim 12, wherein:

triggering the deactivation by the access terminal initiating a resource release for all traffic flows related to the bearer context;

performing the deactivation locally at the access terminal without end-to-end signaling between the access terminal and the network entity; and

the synchronizing comprises sending a tracking area update request to the network entity.

14. The apparatus of claim 13, wherein the tracking area update request is sent in response to an indication to return to wireless coverage provided by a lower layer process.

15. The apparatus of claim 12, wherein the deactivation is triggered if each packet filter associated with the bearer context is indicated as invalid.

16. The apparatus of claim 12, wherein the synchronizing comprises: sending a message indicating that the bearer context has been deactivated.

17. An apparatus for communication, comprising:

means for obtaining a bearer context at an access terminal;

means for deactivating the bearer context at the access terminal, wherein the deactivating is triggered if the access terminal is unable to communicate with a network entity;

means for retrieving a connection with the network entity; and

means for synchronizing the bearer context with the network entity after the deactivating.

18. The apparatus of claim 17, wherein:

triggering the deactivation by the access terminal initiating a resource release for all traffic flows related to the bearer context;

performing the deactivation locally at the access terminal without end-to-end signaling between the access terminal and the network entity; and

the synchronizing comprises sending a tracking area update request to the network entity.

19. The apparatus of claim 18, wherein the tracking area update request is sent in response to an indication provided by lower layer processing to return to wireless coverage.

20. The apparatus of claim 17, wherein the deactivation is triggered if each packet filter associated with the bearer context is indicated as invalid.

21. The apparatus of claim 17, wherein the synchronizing comprises: sending a message indicating that the bearer context has been deactivated.

22. A method for communication, comprising:

maintaining a bearer context for an access terminal at a network entity;

receiving a message from the access terminal indicating that the bearer context has been deactivated at the access terminal, wherein the deactivation is triggered if the access terminal is unable to communicate with the network entity, and wherein the message is received after the access terminal regains connection with the network entity; and

the state of the maintained bearer context is updated in response to the received message.

23. The method of claim 22, wherein the message comprises a tracking area update request.

24. The method of claim 22, wherein the message identifies any bearer context that is active at the access terminal.

25. The method of claim 24, further comprising:

determining that the maintained bearer context has been deactivated by comparing any bearer context identified by the message to a list of at least one bearer context maintained for the access terminal.

26. The method of claim 22, wherein updating the state comprises: the maintained bearer context is deactivated.

27. The method of claim 22, wherein updating the state comprises: any resources associated with the maintained bearer context are released.

28. The method of claim 22, further comprising:

setting the bearer context in response to a resource request from the access terminal.

29. The method of claim 28, wherein the receipt of the message is not a result of a resource release message being sent to the access terminal.

30. The method of claim 22, wherein the bearer context comprises packet filter information and quality of service information.

31. The method of claim 22, wherein the bearer context is maintained at a mobility management entity.

32. An apparatus for communication, comprising:

a bearer context manager for maintaining a bearer context for an access terminal; and

a communication controller to receive a message from the access terminal indicating that the bearer context has been deactivated at the access terminal, wherein the deactivation is triggered if the access terminal is unable to communicate with the apparatus, wherein the message is received after the access terminal regains connection with the apparatus, wherein the bearer context manager is further to update a state of the maintained bearer context in response to the received message.

33. The apparatus of claim 32, wherein the message comprises a tracking area update request.

34. The apparatus of claim 32, wherein the message identifies any bearer context that is active at the access terminal.

35. The apparatus of claim 32, wherein updating the state comprises: the maintained bearer context is deactivated.

36. The apparatus of claim 32, wherein updating the state comprises: any resources associated with the maintained bearer context are released.

37. An apparatus for communication, comprising:

means for maintaining, at a network entity, a bearer context for an access terminal;

means for receiving a message from the access terminal indicating that the bearer context has been deactivated at the access terminal, wherein the deactivation is triggered if the access terminal is unable to communicate with the network entity and the message is received after the access terminal regains connection with the network entity; and

means for updating a state of the maintained bearer context in response to the received message.

38. The apparatus of claim 37, wherein the message comprises a tracking area update request.

39. The apparatus of claim 37, wherein the message identifies any bearer context that is active at the access terminal.

40. The apparatus of claim 37, wherein updating the state comprises: the maintained bearer context is deactivated.

41. The apparatus of claim 37, wherein updating the state comprises: any resources associated with the maintained bearer context are released.