HK1141395A - Handoff of data attachment point - Google Patents

Description

Handover of data attachment points

Claiming priority in accordance with 35U.S.C. § 119

This patent application claims priority to U.S. provisional applications nos. 60/910,628, 60/911,858, and 60/943,459, filed on 6/2007, 4/2007, 13/2007, and 12/2007, respectively, which are assigned to the assignee of the present application and are hereby expressly incorporated by reference.

Technical Field

The present invention relates generally to communication, and more specifically to switching data attachment points in a wireless communication system.

Background

In telecommunications, especially wireless communications, the communication environment is not static, but dynamic. In a mobile communication setting, some communication entities, such as Access Terminals (ATs), may move from one location to another AT different points in time.

Referring to fig. 1, a simplified diagram illustrating an exemplary communication system is shown. In the following description, terminology associated with Ultra Mobile Broadband (UMB) systems is used. The basic terminology and principles of operation of UMB systems can be found in a publication entitled "Interoperability Specification" 3GPP2-a.s0020 published by the third generation partnership project 2(3GPP2) established by the Telecommunications Industry Association (TIA). As shown in FIG. 1, within a Radio Access Network (RAN)12, for example, in an Ultra Mobile Broadband (UMB) system, an AT 14 wirelessly accesses a backbone network 16 in the system via an evolved base station (eBS) 18. The eBS18 acts as a data exchange entity between the AT 14 and an Access Gateway (AGW) 20. The AGW 20 has direct access to the backbone network 16. For example, the backbone network 16 may be the Internet.

In FIG. 1, the eBS18 serves as the Data Attachment Point (DAP) for the AT 14. More specifically, the eBS18, which is the DAP, and the AGW 20 have forward link traffic binding (binding), for example, as in operating in accordance with the Proxy Mobile IP (PMIP) protocol promulgated by the Internet Engineering Task Force (IETF). According to the PMIP protocol, the AGW 20 sends forward link data traffic to the DAP (the eBS18 in this example), which then conveys the data traffic to the AT 14. The eBS18, acting as the DAP, is the network entity that performs the last binding with the AGW 20.

In a wireless environment, the AT 14 is mobile. That is, the AT 14 may move from one location to another location within the same RAN 12, or to a different RAN.

Referring now to fig. 2, another diagram illustrating mobility of the AT 14 is shown.

In FIG. 2, assume that the AT 14, which originally communicated with the eBS18, now leaves the eBS18 and begins communicating with the eBS 22. The eBS22 is now referred to as the Forward Link Serving EBS (FLSE) for the AT 14 because the eBS22 communicates and exchanges data directly with the AT 14. However, there has not been any binding update with the AGW 20. That is, the network entity that made the last binding with the AGW 20 is still the eBS18, and has not had any binding updates with the AGW 20 since then. Likewise, the eBS18 still acts as the DAP. In this case, the data from the AGW 20 is sent to the eBS18, which in this case is the DAP, and then routed to the AT 14 to the eBS 20, which is the FLSE. Data packets from the AGW 20 to the AT 14 are routed according to the data path 24 shown in fig. 2.

Even though the AT 14 has roamed outside of the coverage area serviced by the eBS18, the eBS18 is still the DAP for the AT 14. The reason for this is that in a wireless setting, depending on the mobility of the AT 14, the eBS18 may become the FLSE for the AT 14 again. For example, the AT 14 may be located on the boundary line of the coverage areas provided by both the eBS18 and the eBS 22. As such, the AT 14 may only temporarily communicate with the eBS 22. However, if the communication between the AT 14 and the eBS22 is not temporary, routing the data packets through the tortuous data path 24 is not an efficient use of communication resources, AT least from a backhaul utilization perspective. In addition, this also affects packet data delay. Instead, the DAP is preferably handed off from the eBS18 to the eBS 22. For this DAP handoff, the eBS22 first needs to forward link traffic bind with the AGW 20. After the forward link traffic binding process is successfully completed, the eBS22 becomes the current DAP. The data packet is then routed from the AGW 20 to the AT 14 via the eBS22, as shown by the data path 26 in FIG. 2. The DAP is handed off from the BS18 to the eBS22 based on certain criteria, for example, after determining that the AT is in communication with the eBS22 for a predetermined period of time.

Heretofore, the handoff or selection of the DAP (referred to as DAP handoff) has been mostly AN initiated. In AN initiated handoff, the handoff procedure is transparent to the AT 14. However, problems can arise where the AN 14 is not aware of the handoff. For example, the expected DAP result may be an undesirable DAP. This is especially true in an asynchronous environment, where the various communicating entities are not synchronized with each other. Returning to FIG. 2, it is again assumed that the AT 14 is located AT the boundary of the coverage areas of both the eBS18 and the eBS 22. In AN AN-initiated handoff, sensing the presence of the AT 14, e.g., via downlink signal strength, both the eBS18 and the eBS22 attempt to be the DAP by registering with the AGW 20 for a forward link binding. It is also assumed that the AT 14 is fully within the coverage area provided by the eBS18, and thus the eBS18 should be the best suited DAP for the AT 14. However, if the registration messages sent and received between the AGW 20 and the eBS22 are faster than the registration messages between the AGW 20 and the eBS18, the eBS22 may be designated as the DAP in preference to the eBS18, as opposed to being expected. Recovery of the wrongly assigned DAP, even if not fatal to the communication session involved, requires additional signaling and messaging, unnecessarily blocking communication resources.

Accordingly, there is a need to provide DAP assignment schemes with greater accuracy and certainty so that communication resources can be more efficiently utilized.

Disclosure of Invention

In a communication system, a gateway entity is linked to a plurality of communication entities that are operable to communicate with an access terminal that first needs to establish a Data Attachment Point (DAP) with one of the communication entities. The access terminal initiates a handoff of the DAP from one communication entity to another communication entity. Before the DAP handoff is performed, the access terminal may consider a number of factors, such as: link conditions with multiple communication entities, time since last DAP handoff, and duration of communication with the current communication entity. To avoid any race condition where multiple communication entities register as the DAP, the access terminal may reference timestamps of messages received from the multiple communication entities. In addition, multiple communication entities may also exchange messages with each other for the current DAP registration state.

The features and advantages of the present invention will become apparent to those skilled in the art from the following detailed description, taken in conjunction with the accompanying drawings, in which like reference numerals refer to like parts.

Drawings

FIG. 1 is a diagram illustrating an exemplary communication system;

fig. 2 is another diagram illustrating mobility of an access terminal in a communication system;

FIG. 3 is a diagram illustrating the relationship of various communication entities arranged in accordance with an exemplary embodiment of the present invention;

FIG. 4 is a call flow diagram illustrating the flow of messages between different communication entities operating in an asynchronous system in which DAP handoff is without AT assistance;

FIG. 5 is a call flow diagram illustrating the flow of messages between different communication entities operating in a synchronous system in which DAP handoff is AT-assisted;

FIG. 6 is a flow chart illustrating a process performed by an AT in determining an AT-assisted DAP handoff;

FIG. 7 is a call flow diagram illustrating message flow between different communication entities operating in a synchronous system with DAP handoff assisted by an AT but AT the request of one of the communication entities;

FIG. 8 is a flow diagram illustrating a process performed by an AT in determining an AT-assisted DAP handoff AT the request of one of a plurality of network entities; and

FIG. 9 is a schematic diagram of a portion of a hardware implementation of an apparatus for performing a DAP handoff procedure in accordance with exemplary embodiments.

Detailed Description

The following description is presented to enable any person skilled in the art to make or use the invention. In the following description, for purposes of explanation, numerous details are set forth. It will be understood by those of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and processes are not set forth in detail in order to not obscure the present invention with unnecessary detail. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Furthermore, in the following description, for the sake of brevity and clarity, terminology associated with Ultra Mobile Broadband (UMB) technology published by the Telecommunications Industry Association (TIA) through the third generation partnership project 2(3GPP2) is used. It should be emphasized that the present invention is also applicable to other technologies, such as those involving Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), etc., and associated standards.

Reference is now made to fig. 3, which schematically illustrates a relationship between a plurality of communication entities, arranged in accordance with an exemplary embodiment of the invention.

In fig. 3, the overall communication system is generally indicated by reference numeral 30. In the communication system 30, an Access Gateway (AGW)32 is linked to a plurality of evolved base stations (eBSs), two of which are shown as eBSs 34 and eBSs 36. The eBS34 and the eBS36 may be installed in the same Access Network (AN) or in different ANs. In this example, the eBSs 34 and 36 are part of the AN 41 and AN 43, respectively. Each of the AN 41 and the AN 43 may include one or more eBSs and other entities. For clarity and simplicity, only one eBS is shown for each AN in FIG. 3. In the embodiment shown in FIG. 3, the eBS34 provides wireless access to users within the coverage area 35. Likewise, the eBS36 provides wireless access within the coverage area 37. The AGW32 has a link to a backbone network 38, and the backbone network 38 can be, for example, the internet. In another example, the backbone network 38 may be an intranet in a closed network.

The Session Reference Network Controller (SRNC)40 is linked to the AGW 32. The SRNC 40 has multiple functions. For example, the SRNC 40 provides authentication functionality for an Access Terminal (AT), such as the AT44 shown in fig. 3. In addition, the SRNC 40 stores the communication session of the AT44 for any new eBS that is ready to communicate with the AT 44. In general, the SRNC 40 also controls the paging procedure for the idle state.

Assume that the AT44 is capable of moving between multiple radio networks, including AN 41 and AN 43. In order for the AT44 to access the backbone network 38, the AT44 first needs to establish a Data Attachment Point (DAP) with a communication entity (e.g., the eBS34 or the eBS 36). In this description and in the following claims, the term "data attachment point" is to be interpreted as a communication entity that anchors data directly or indirectly to or from a network gateway. As shown in FIG. 3, for example, if the eBS34 is designated as the DAP, data from the backbone network 38, after passing through the gateway entity (in this case the AGW 32), is anchored by the communication entity (in this case the eBS 34) acting as the DAP before reaching other communication entities (e.g., the eBS 36) via the data path 62. In this example, the eBS34 anchors data directly from the AGW32 via the data path 62. Which is also true for the reverse data stream. That is, data received from other communication entities is anchored by the DAP before reaching the gateway entity.

In AN AN-initiated DAP assignment configuration, each of the eBS34 and the eBS36 performs a DAP assignment procedure if certain criteria are met. For example, when the eBS34 becomes the Forward Link Serving EBS (FLSE) for the AT44, it can start the DAP assignment process. Thus, if the eBS34 is the current FLSE, the eBS34 sends a registration request message to the AGW 32. Thereafter, the AGW32 performs binding updates with the eBS34 according to procedures set forth in the Proxy Mobile IP (PMIP) protocol published by the Internet Engineering Task Force (IETF).

The communication system 30 is assumed to be a synchronous system. That is, all communication entities (such as the AGW 38, the eBS34, the eBS36, etc.) operate according to a master time reference. For example, the master reference may be Global Positioning System (GPS) time. In this case, a predefined DAP registration protocol can be set up, for example, by allowing the first arrived request to be processed and approved as the DAP until the next approval. However, problems can arise if the system 30 is an asynchronous system. Because of the lack of a master time reference, an erroneous DAP assignment may result.

Reference is now made to fig. 3 in conjunction with fig. 4, which illustrates a sequence of message flows between different entities. Assume that system 30 is a system that uses AN AN-initiated DAP handoff scheme. Assume also that the AT44 moves to an overlap region 46 where the coverage areas 35 and 37 are AT their juncture. The eBS34 senses the presence of the AT44, sends a registration request message to the AGW32 AT time t1 attempting to register with the AGW32 as the DAP for the AT44, as shown by message flow 48 in FIG. 4. Assume that a "first come first served" rule is employed in system 30. Under this rule, the eBS34, which first sends the registration request message, expects to be the DAP for the AT 44.

When the AT44 is located in the coverage overlap area 46, it is assumed that the eBS36 also senses the presence of the AT 44. In this example, the eBS36 also sends a registration request message to the AGW32 at time t2, as shown by message flow 50 in FIG. 4. Here, t2 is later than t 1.

For some reason, messages sent via the message flow 50 arrive at the AGW32 earlier than the messages of the message flow 48. More specifically, messages sent by the eBS36 arrive at the AGW32 at time t3, and messages sent by the corresponding eBS34 arrive at the AGW32 at time t 6. In this case, time t6 is later than time t 3. For example, the foregoing situation may occur in a communication environment where the eBS36 has better communication conditions than the eBS 34.

For the AGW32, since it receives the registration message from the eBS36 at time t3, according to the "first come first served" rule, the AGW32 approves the request and sends a registration success message to the eBS36 at time t4 and arrives at the eBS36 at time t 5. Thus, the eBS36 successfully registers as the DAP for the AT 44.

Assume that the AGW32 also receives a registration request message from the eBS34 at time t 6. The time t6 is later than the time t5, where t5 is the time when the eBS36 successfully registers with the AGW32 as the DAP for the eBS 34.

Depending on the registration protocol implemented in the AGW32, the AGW32 may assume that the eBS34 wants to replace the current DAP eBS36 as a new DAP.

The AGW32 then sends a registration success reply to the eBS34 at time t7, which arrives at the eBS34 at time t 8. The eBS34 then acts as the new DAP.

In the previous example, the eBS34 is initially intended to be the DAP, i.e., the eBS36 is not intended to assume an intermediate DAP role. Such DAP assignment may create problems. Even assuming no harm to the data of the communication session, such DAP designations can cause persistent and inefficient traffic routing, thereby unnecessarily tying up communication resources. Any attempt to recover from errors necessarily requires additional time and resources, as well as additional complexity.

It should also be noted that although PMIP binding messages sent by the eBS34 and the eBS36 via message flows 48 and 50, respectively, may have timestamps to prevent out-of-order binding updates. However, since system 30 operates asynchronously, the timestamps may be ineffective for performing their functions. The reason is that in an asynchronous system each communication entity (e.g., the eBS34 and the eBS 36) operates according to its own time reference. The timestamp on the binding message sent to the AGW32 is not for the master time reference but for a reference for a single entity. The time references of multiple entities may have large offsets from each other. Therefore, the problems described above still occur.

FIG. 5 is a message flow diagram illustrating an AT-assisted or AT-initiated DAP handoff scheme in accordance with an exemplary embodiment of the invention. Hereinafter, the terms "AT-assisted" and "AT-initiated" are used interchangeably.

Reference is now made to fig. 5 in conjunction with fig. 3. Assume that the AT44 initially communicates with the eBS34, where the eBS34 is the last entity to perform PMIP binding with the AGW 40. Thus, the eBS34 is the current DAP for the AT 44.

The AN 44 has a Route Set (RS) in its memory. The RS includes a set of communication entities, such as the eBS34 and the eBS36, that have air interface routes with the AT44, whereby each entity in the RS can tunnel link layer packets and IP packets with the AT44, and vice versa. In an AT-assisted or AT-initiated DAP handoff, the AT44 assists communication entities in the RS to decide which entity in the RS should be the DAP.

AT-assisted handoff is superior to a corresponding AN-initiated handoff in several respects.

First, as previously described, a race condition may occur in an asynchronous system (such as the system previously shown in FIG. 4). AT-assisted DAP handoff is more likely to avoid this problem. For example, the AT need not initiate another DAP migration until a response from an earlier DAP migration is received and the response ends.

Second, the DAP is the data anchor for the AT from the AGW in the RAN. The DAP is preferably in the RS of the AT. Thus, flexibility and fast updates can be obtained when needed. For example, assume that the AGW needs to update the policy for the AT and that the change needs to be made during the AT's current communication session. The change can be sent from the AGW to the DAP, which then relays the change to the AT for quick update. On the other hand, if the DAP is not in the AT's RS, the change will not likely be updated as easily and quickly.

In addition, the AT has first hand information on its link status with each eBS in the RS. Accordingly, the AT has the advantage of determining whether the currently communicating eBS (i.e., FLSE) is stable enough to act as the DAP.

In addition, AT-assisted DAP handoff is simpler than AN-initiated DAP handoff, both in the number of messages exchanged and in the implementation.

Reference is now made to fig. 3 and 5. Assume that the AT44 moves to the coverage area 37 of the eBS 36. The AT44 then communicates with the eBS 36. Thus, the eBS36 acts as the FLSE for the AT 44.

In the AT-assisted handoff described in this embodiment, the AT may evaluate and evaluate certain criteria or conditions before deciding whether to begin the DAP handoff process. Primarily, the AT may consider whether the duration of communication with the current FLSE has reached a predetermined length. This is to avoid designating the FLSE as the DAP if communication with the FLSE is only temporary. Further, the AT may determine whether a predetermined time has elapsed since the last handoff before starting the AT-assisted handoff procedure. The reason for this is that it is undesirable for the AT to switch the DAP too frequently, as frequent and unnecessary switching can result in inefficient consumption of communication resources. It is also important that the AT can evaluate the communication link conditions of the various eBSs to determine whether a DAP handoff is warranted. Of course, it is not advisable for the AT to switch the DAP to the FLSE with which the AT has adverse communication conditions.

In this example, assume that the AT44 decides to switch the DAP from the eBS34 to the eBS36 after determining that a certain amount of time has elapsed and that the radio link conditions of the eBS36 are favorable. In the following description, the eBS34 is referred to as the source DAP eBS. The eBS36 is referred to as the target DAP eBS. The handoff process begins with the AT44 sending a request message (referred to herein as a DAPMoveRequest message) to the target DAP eBS 36. The flow path of the request message is denoted by reference numeral 52 shown in fig. 5. The target DAP eBS36 may accept or reject the request, for example, as determined by the congestion level of the incoming call through the eBS 36.

If the target DAP eBS36 accepts the request, the target DAP eBS36 updates the data attachment binding with the AGW32 by sending a PMIP-registration request message to the AGW32, for example, using the PMIPv4 protocol. The message flow is represented by reference numeral 54 shown in fig. 5.

The AGW32 acknowledges the binding update by sending a PMIP-registration reply message to the target DAP eBS36, as shown by message flow 56 in FIG. 5. Thereafter, a data tunnel may be established between the AGW32 and the AT44 via the target DAP eBS 36. The lifetime parameter of the data tunnel is included in the PMIP-registration reply message. The lifetime parameter is used to prevent the situation where the tunnel is maintained while the AT44 is stationary, resulting in inefficient use of communication resources. If the AT44 needs to maintain active communication after the lifetime is reached, the AT44 needs to send another DAPMoveRequest message to the eBS36 before the lifetime expires.

After the binding update process is complete, the target DAP eBS36 responds to the AT44 with a DAPASssignment message, as shown by message flow path 58 in FIG. 5. The DAPASssignment message informs the AT44 whether the DAP handoff is successful. In addition, the DAPASssignment message may mainly include a timestamp issued by the AGW32 for successful PMIP registration with the target DAP eBS36, and also the remaining lifetime of the bonded data tunnel. If the timestamp of the DAPASssigmnennt message is set to a value that is lower than the timestamp of the DAPASssignment message that was previously processed by the corresponding AT44, the AT44 may discard the DAPASssignment message, i.e., discard the message sent via the flow path 58. Operating in this manner, the race condition previously described in FIG. 4 may be avoided.

On the other hand, if the timestamp of the DAPASssignment message via the flow path 58 has the most recent value, i.e., a value that is higher than any corresponding timestamp of the DAPASssignment message previously processed by the AT44, the AT44 may mark the data path route to the target eBS36 as the DAP route. In addition, the AT44 can mark other data path routes to other eBSs as non-DAP routes. AT the same time, the AT44 can start its own timer associated with the newly marked DAP route to adjust the frequency of DAP handoffs. As previously mentioned, it is desirable not to make DAP handoffs too frequently, such as when there is only a slight change in link conditions. For example, frequent and unnecessary DAP handoffs can affect the loading of the AGW 32.

Thereafter, the target DAP eBS36 informs all eBSs in the RS of the AT44 that the role of the DAP for the AT44 is taken over. The notification is sent in an Internet Protocol Tunnel (IPT) -Notification message to all eBSs and related entities in the RS of the AT 44. One of which is shown in the message path 60 sent by the target eBS36 to the Session Reference Network Controller (SRNC) 40. The IPT-notification message sent via path 60 has multiple uses. First, the target DAP eBS36 informs the other eBSs that the target DAP eBS36 is now the current DAP. In addition, the IPT-Notification message also includes the message sequence number and the timestamp used by the target DAP eBS36 in updating the data attachment binding previously with the AGW 32.

For the SRNC 40 to confirm that the eBS36 is the current DAP, the SRNC 40 sends an IPT-Notification confirmation, as shown by message flow path 62 in FIG. 5.

In particular, as shown by the message flow path 66 in FIG. 5, the target eBS36 informs the source DAP 34 of assuming the role of the current DAP by sending an IPT-Notification message to the source DAP eBS34, as opposed to the aforementioned informing of other eBSs of assuming the DAP role. The IPT-Notification message informs the source DAP eBS34 that the target eBS36 is the current DAP eBS. Likewise, the IPT-Notification message may include the message sequence number and the timestamp that the target DAP eBS36 used in updating the data attachment binding with the AGW 32.

In order for the source DAP eBS34 to acknowledge that the eBS36 is the current DAP, the source DAP eBS34 needs to send an IPT-Notification acknowledgement message, as shown by message flow path 68 in FIG. 5. Optionally, the IPT-Notification acknowledgement message may indicate whether the message sender is the current FLSE for the AT 44. Upon receiving the IPT-Notification acknowledgement message, the target eBS36 completes the DAP handoff process. Thereafter, as shown in FIG. 3, the IP packet stream flows directly through the eBS36 via a data packet flow path 62 rather than meandering through the eBS34, as in FIG. 3.

FIG. 6 illustrates a flowchart that summarizes the procedures performed by the AT44 in determining the AT-assisted DAP handoff.

FIG. 7 is a message flow diagram illustrating another embodiment of another method of AT-assisted DAP handoff. In this embodiment, the handoff is initiated by the AT but is performed upon request by the infrastructure entity.

Reference is now made to fig. 7 in conjunction with fig. 3. Assume that the eBS34 is the last entity for the AT44 to perform PMIP binding with the AGW 40. Thus, the eBS34 is the current DAP for the AT 44.

Similar to the foregoing, in an AT-assisted or AT-initiated DAP handoff, the AT44 assists the eBSs in the RS to decide which eBS in the RS should be the DAP.

There are a variety of scenarios where a communication or infrastructure entity requests the AN 44 to initiate a DAP handoff. For example, the current DAP (in this case, the eBS 34) may be overloaded with calls. To alleviate congestion, any infrastructure entity (e.g., the eBS34 or the eBS 36) may request initiation of a handoff procedure from the AT 44.

As another example, assume that the AT roams into a coverage area communicating with a new eBS associated with a new AGW that requires a PMIP connection to be established via AGW handoff, regardless of whether the new eBS is an FLSE for the AT. In this case, any of the infrastructure or network entities previously described can also request the AT44 to initiate the DAP handoff process.

Assume in this case that the target DAP eBS36 requests the AT44 to handoff the DAP from the eBS34 to the eBS 36. Reference is now made to fig. 7. The target DAP eBS36 may request via a DAPMoveRequestRequest message sent to the AT44, as shown by the message flow path 70 in FIG. 7. For example, a link ID associated with an IP packet data route associated with the eBS36 may be included in the DAPMoveRequestRequest message.

The AT44 may accept or reject the request. If the AT44 denies the request, the AT44 sends a deny message to the eBS 36. Alternatively, the AT44 may deny the request by expiring a preset timer without responding to the eBS 36.

As in the previous embodiment, several factors may be considered in determining whether to accept or reject the request. Assume that the eBS36 is currently the FLSE for the AT44 and is not the DAP for it. If the aforementioned set of predetermined conditions is met, the AT can accept the DAP handoff request from the eBS34 to the eBS 36. On the other hand, assume, for example, that the AT44 may deny the request if the AT44 does not want to use the eBS36 as the FLSE for long periods of time, or if the communication conditions are unfavorable.

If the request is denied, the DAP handoff process ends without a change in the DAP. That is, the AT44 continues to use the eBS34 as the current DAP through the IP flow data path 62 (FIG. 3).

Assume that the AT44 accepts the request. In this embodiment, the acceptance is communicated to the target eBS36 by sending a DAPMoveRequest message to the EBS36 via message flow path 72.

It should be noted that the AT44 should not send more than one DAPMoveRequest message within the time limit set by the timer preset in the message. In addition, during the AT-assisted DAP handoff process AT the request of the infrastructure entity described in this embodiment, the target eBS36 should not issue any DAPASssignment message unless the eBS36 receives a DAPMoveRequest message (e.g., a DAPMoveRequest message sent via the message flow path 70).

FIG. 8 illustrates a flowchart that outlines the procedures performed by the AT44 in determining an AT-assisted DAP handoff AT the request of a network entity.

The DAP handoff process thereafter is substantially similar to the handoff process described in the previous embodiment. For the sake of clarity and brevity, the remaining steps shown in fig. 7 will not be described in further detail.

Fig. 9 shows a part of a hardware implementation of an apparatus for performing a handover procedure as described above. The circuitry, which may be implemented in the AT or any communication entity (e.g., eBS or AGW), is designated by the reference numeral 90.

The device 90 includes a central data bus 92 linking several circuits together. The circuits include a CPU (central processing unit) or controller 94, a receive circuit 96, a transmit circuit 98, and a memory unit 100.

If the apparatus 90 is part of a wireless device, the receive and transmit circuits 96 and 98 may be connected to RF (radio frequency) circuitry, but are not shown in the figure. The receive circuit 96 processes and buffers the received signal before transmission to the data bus 92. On the other hand, the transmit circuit 98 processes and buffers data from the data bus 92 before being transmitted out of the device 90. The CPU/controller 94 performs data management functions of the data bus 92 and also performs general data processing functions, including executing the instructional contents of the memory unit 100.

Alternatively, the transmit circuit 98 and the receive circuit 96 may be integral parts of the CPU/controller 94, as opposed to the separate arrangement shown in fig. 9.

The memory unit 100 includes a set of modules and/or instructions generally represented by reference numeral 102. In this embodiment, the modules/instructions primarily include the switching function 108. The switching function 108 comprises computer instructions or code for performing the process steps shown and described in fig. 5-8. Specific instructions specific to an entity may be selectively implemented in the handoff function 108. For example, if the apparatus 40 is part of an AT, instructions for performing the process steps shown and described in fig. 6 and 8, and the AT-related message preparation and processing shown and described in fig. 5 and 7, may be encoded into the handoff function 108. Similarly, if the apparatus 40 is part of a communication entity (e.g., an eBS), processing steps specific to that communication entity may be encoded into the handoff function 108.

In this embodiment, the memory unit 100 is a RAM (random access memory) circuit. Exemplary functions, such as the switching function 108, are software routines, modules and/or data sets. The memory unit 100 may be connected to another memory circuit (not shown), which may be of a volatile or non-volatile type. Alternatively, the memory cell 100 may be comprised of other circuit types, such as: EEPROM (electrically erasable programmable read only memory), EPROM (electrically programmable read only memory), ROM (read only memory), ASIC (application specific integrated circuit), magnetic disks, optical disks, and other devices known in the art.

It should also be noted that the inventive methods as described may also be encoded as computer readable instructions carried on any computer readable medium known in the art. In this specification and the appended claims, the term "computer-readable medium" refers to any medium that participates in providing instructions to any processor (such as the CPU/controller 94 shown and described in the illustration of FIG. 9) for execution. As previously mentioned, the medium may be of the storage type and may also take the form of the volatile or non-volatile storage medium described previously, for example in the description of the memory unit 100 in fig. 9. The medium may also be of the transmission type and may include coaxial cables, copper wire, fiber optic cables, air interfaces carrying acoustic, electromagnetic or light waves capable of carrying signals read by machines or computers. The computer readable medium may be part of a computer product separate from the apparatus 90.

Finally, other modifications may be made within the scope of the invention. In addition to the above, any other logical blocks, circuits, and algorithm steps described in connection with the embodiments can be implemented in hardware, software, firmware, or combinations thereof. It will be understood by those skilled in the art that these and other changes in form and details may be made therein without departing from the scope and spirit of the invention.

Claims (41)

1. A method operational by an access terminal in a communication system, comprising:

establishing a data attachment point with a first communication entity;

communicating with a second communication entity;

providing an evaluation of a set of predetermined conditions of the first and second communication entities; and

initiating a handoff of the data attachment point from the first communication entity to the second communication entity based on the evaluation.

2. The method of claim 1, further comprising communicating with the second communication entity after a predetermined time before initiating the handoff.

3. The method of claim 1, further comprising allowing sufficient time to elapse since a last handover prior to initiating the handover.

4. The method of claim 1, further comprising providing a set of criteria for the set of communication conditions, and initiating the handover after the set of criteria is met.

5. A method as in claim 1 further comprising sending a request message to said second communication entity in initiating said handoff.

6. The method of claim 1 further comprising receiving a handoff request from the second communication entity prior to initiating the handoff.

7. The method of claim 1, further comprising receiving a notification from the second communication entity specifying a data attachment point prior to the handoff.

8. The method of claim 7, further comprising a timestamp in the notification of a specified data attachment point.

9. A method performed by a communication entity in a communication system comprising another communication entity and a user terminal, the method comprising:

receiving a request message from the access terminal for handing over a data attachment point from the other communication entity;

notifying the other communication entity of the handover; and

replacing the other communication entity as the data attachment point.

10. The method of claim 9, further comprising communicating with a gateway entity in the communication system to replace the other communication entity as the data attachment point.

11. The method of claim 9, further comprising sending a notification message with a timestamp thereon to the other communication entity.

12. An apparatus operable in a communication system, comprising:

means for establishing a data attachment point with a first communication entity;

means for communicating with a second communication entity;

means for providing an evaluation of a set of predetermined conditions of the first and second communication entities; and

means for initiating a handoff of the data attachment point from the first communication entity to the second communication entity based on the evaluation.

13. The apparatus of claim 12, further comprising means for communicating with the second communication entity after a predetermined time before initiating the handoff.

14. The apparatus of claim 12, further comprising means for allowing sufficient time to elapse since a last handover prior to initiating the handover.

15. The apparatus of claim 12, further comprising means for providing a set of criteria for the set of communication conditions and initiating the handover after the set of criteria is met.

16. The apparatus of claim 12 further comprising means for sending a request message to the second communication entity in initiating the handoff.

17. The apparatus of claim 12 further comprising means for receiving a handoff request from the second communication entity prior to initiating the handoff.

18. The apparatus of claim 12 further comprising means for receiving a notification from the second communication entity specifying a data attachment point prior to the handoff.

19. The apparatus of claim 18, wherein the notification of the specified data attachment point further comprises a timestamp.

20. A communication entity operable in a communication system comprising a further communication entity and a user terminal, the communication entity comprising:

means for receiving a request message from the access terminal for handing over a data attachment point from the other communication entity;

means for notifying the other communication entity of the handover; and

means for replacing the other communication entity as the data attachment point.

21. The communication entity of claim 20, further comprising means for communicating with a gateway entity in the communication system to replace the other communication entity as the data attachment point.

22. The communication entity of claim 21, further comprising means for sending a notification message with a timestamp thereon to the other communication entity.

23. An access terminal operating in a communication system, comprising:

a processor; and

circuitry, coupled to the processor, to: establishing a data attachment point with a first communication entity, communicating with a second communication entity, providing an evaluation of a set of predetermined conditions of the first and second communication entities; and initiating a handover of the data attachment point from the first communication entity to the second communication entity based on the evaluation.

24. The access terminal of claim 23 wherein said circuitry and said processor are further configured to communicate with said second communication entity after a predetermined time prior to initiating said handoff.

25. The access terminal of claim 23, wherein the circuitry and processor are further configured to allow sufficient time to elapse since a last handoff prior to initiating the handoff.

26. The access terminal of claim 23, wherein the circuitry and processor are further configured to provide a set of criteria for the set of communication conditions and to initiate the handover after the set of criteria is met.

27. The access terminal of claim 23 wherein the circuitry and processor are further configured to send a request message to the second communication entity in initiating the handoff.

28. The access terminal of claim 23 wherein the circuitry and processor are further configured to receive a handoff request from the second communication entity prior to initiating the handoff.

29. The access terminal of claim 23 wherein said circuitry and said processor are further configured to receive a notification from said second communication entity specifying a data attachment point prior to said handoff.

30. The access terminal of claim 29, wherein the notification of the designated data attachment point further comprises a timestamp.

31. A communication entity operable in a communication system comprising a further communication entity and a user terminal, the communication entity comprising:

a processor; and

circuitry, coupled to the processor, to: receiving a request message from the access terminal for a handover of a data attachment point from the other communication entity, notifying the other communication entity of the handover, and replacing the other communication entity as the data attachment point.

32. The communication entity of claim 31, wherein the processor and the circuitry are further configured to communicate with a gateway entity in the communication system to replace the other communication entity as the data attachment point.

33. The communication entity of claim 31, wherein the processor and the circuitry are further configured to send a notification message with a timestamp thereon to the other communication entity.

34. A computer product having a computer-readable medium, the computer-readable medium comprising computer-readable instructions for:

establishing a data attachment point with a first communication entity;

communicating with a second communication entity;

providing an evaluation of a set of predetermined conditions of the first and second communication entities; and

initiating a handoff of the data attachment point from the first communication entity to the second communication entity based on the evaluation.

35. The computer product as in claim 34 wherein said computer readable medium further comprising computer readable instructions for communicating with said second communication entity after a predetermined time before initiating said handoff.

36. The computer product of claim 34, wherein the computer-readable medium further comprises computer-readable instructions for allowing sufficient time to elapse since a last handover prior to initiating the handover.

37. The computer product of claim 34, wherein the computer-readable medium further comprises computer-readable instructions for providing a set of criteria for the set of communication conditions and initiating the handover after the set of criteria is met.

38. The computer product as in claim 34 wherein said computer readable medium further comprising computer readable instructions for sending a request message to said second communication entity in initiating said handoff.

39. The computer product as in claim 34 wherein said computer readable medium further comprising computer readable instructions for receiving a handoff request from said second communication entity prior to initiating said handoff.

40. The computer product as in claim 34 wherein said computer readable medium further comprising computer readable instructions for receiving a notification from said second communication entity specifying a data attachment point prior to said handoff.

41. The computer product of claim 34, the notification of the specified data attachment point further comprising a timestamp.