RU2446628C2 - Transfer of data attachment point servicing - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: in communication system, where gateway object (32) is connected with multiple infrastructure objects which in turn function to implement connection with access terminal (44), access terminal at first needs to establish data attachment point (DAP) with one of infrastructure objects (34). DAP service transfer from one infrastructure object (34) to other infrastructure object (36) is initiated by access terminal (44). The access terminal weights factors such as status of communication lines with various infrastructure objects, time after the last DAP service transfer and time length of interacting with current infrastructure object before DAP service transfer.

EFFECT: accuracy and reliability of DAP assignment scheme providing, which leads to effective utilisation of communication resources.

35 cl, 9 dwg

Description

This patent application claims the priority of provisional patent applications US No. 60/910628, 60/911858 and 60/943459, filed April 6, 2007, April 13, 2007 and June 12, 2007, respectively, and all rights to which are assigned to the assignee of this application and which are expressly incorporated herein by reference.

FIELD OF THE INVENTION

The present invention generally relates to communication systems, and more particularly, to handover of data attachment points in wireless communication systems.

State of the art

In communications, especially wireless communications, communications are not static, but rather dynamic. When setting up mobile communication, some communication objects, such as an access terminal (AT), can move from one position to another at different points in time.

In FIG. 1 is a simplified schematic illustration of a typical communication system. The following description uses terminology associated with the UMB (Ultra-Mobile Broadband) system. The basic terminology and principles of the UMB system can be found in the publication of the Third Generation Partnership Project 2 (3GPP2), established by the Telecommunications Industry Association (TIA), entitled “Interoperability Specification”, 3GPP2-A.S0020. As shown in FIG. 1, in a radio access network (RAN) 12, for example in a UMB system in which an AT 14 connects to a core network 16 through a developed base station (eBS) 18 wirelessly, eBS 18 serves as a communication object between the AT 14 and the gateway 20 Access (AGW). AGW 20 has direct access to core network 16. Core network 16 may be, for example, the Internet.

In FIG. 1, eBS 18 serves as a data attachment point (DAP) for AT 14. More specifically, eBS 18 serves as a DAP having forward link traffic binding to AGW 20, for example, Proxy Mobile IP (PMIP) distributed Internet Engineering Support Team (IETF). The AGW 20 sends forward link traffic to the DAP via PMIP, in this case eBS 18, which in turn directs traffic to the AT 14. eBS 18, acting as the DAP, is the network entity that performs the last binding to the AGW twenty.

In a wireless environment, the AT 14 is mobile. That is, the AT 14 can move from one location to another within the same RAN 12 or in the direction of another RAN.

In FIG. 2 is another simplified diagram illustrating the mobility of the AT 14.

In FIG. 2, it is understood that AT 14, which initially communicates with eBS 18, is now moving away from eBS 18 and begins to communicate with eBS 22. eBS 22 is now called eBS serving the forward link (FLSE) for AT 14, as it is eBS 22, which directly communicates and communicates with AT 14. However, there has been no update to the binding to AGW 20. That is, the network entity that performed the last binding to AGW 20 still remains eBS 18, and since then no AGW 20 binding updates. As such, eBS 18 all e it serves as a DAP. In this scenario, data from AGW 20 is sent to eBS 18, which in this case is a DAP, and then sent to AT 14 to eBS 20, which serves as the FLSE. Data packets from the AGW 20 to the AT 14 are routed along the data path 24, as shown in FIG. 2.

Even if the AT 14 has moved away from the service area served by the eBS 18, the eBS 18 remains as the DAP for the AT 14. The reason is in the wireless configuration, depending on the mobility of the AT 14, it is possible that the eBS 18 can again become FLSE for the AT 14. For example , AT 14 can be located on the boundary line of service areas supported by both eBS 18 and eBS 22. Thus, AT 14 can only communicate with eBS 22 temporarily. However, if the communication between the AT 14 and eBS 22 is not temporary, directing data packets through the indirect data path 24 may not be an efficient use of communication resources, at least from the point of view of relaying. In addition, data packet delay is also affected. Instead, the DAP preferably switches from eBS 18 to eBS 22. For such a DAP, eBS 22 switch, you must first bind the forward link traffic to AGW 20. After the successful completion of the bind process, the forward link data eBS 22 becomes the current DAP. Data packets are then routed from AGW 20 to AT 14 via eBS 22, as shown by data path 26 in FIG. 2. Switching the DAP from BS 18 to eBS 22 can be based on certain criteria, for example, after it has been verified that the AT has been interacting with eBS 22 for a predetermined period of time.

Previously, switching or selecting a DAP, called a DAP handover, was mainly initiated by the AN. In AN initiated handover, the handover process is transparent to AT 14. However, problems may arise if AN 14 does not have handover information. For example, a prospective DAP may not be a prospective DAP. This is mainly true in an asynchronous environment in which various communication objects are not synchronized with each other. With reference to FIG. 2, it is again assumed that the AT 14 is located at the boundary of the service areas of both eBS 18 and eBS 22. Recognizing the presence of the AT 14, for example, from the downlink signal strength in the AN-initiated handoff, both eBS 18 and eBS 22 try be DAP, by registering with AGW 20 for direct link binding. Moreover, it is assumed that the AT 14 is well fixed in the service area provided by the eBS 18, and thus the eBS 18 should be the most suitable DAP for the AT 14. However, if registration messages are sent and received between the AGWs 20 and eBS 22 are faster than registration messages between AGW 20 and eBS 18, eBS 22 may be designated as a DAP before eBS 18, contrary to what was expected. Recovering an erroneously assigned DAP, even if it is not fatal to the involved communication session, requires additional signaling and messages that unnecessarily use the communication resources.

Thus, there is a need to provide a DAP assignment scheme with increased accuracy and reliability, thereby making more efficient use of communication resources possible.

SUMMARY OF THE INVENTION

In a communication system in which a gateway object is connected to many communication objects, which, in turn, function to interact with an access terminal, the access terminal must first establish a data access point (DAP) with one of the communication objects. A DAP handoff from one communication entity to another communications entity is initiated by the access terminal. Before continuing with the DAP handoff, the access terminal may consider factors such as link state with various communication objects, time since the last DAP service transmission, and length of time to communicate with the current communication object. In order to prevent any competition for communication objects for registration as a DAP, the access terminal may rely on time stamps in messages received from communication objects. In addition, communication objects can exchange messages with each other regarding the current DAP registration status.

These and other features and advantages will be apparent to those skilled in the art from the following detailed description, provided in conjunction with the accompanying drawings, in which like reference numbers refer to like parts.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified schematic diagram illustrating a typical communication system;

FIG. 2 is another simplified schematic diagram illustrating the mobility of an access terminal in a communication system;

FIG. 3 is a simplified schematic diagram that shows the relationships of various communication objects configured in accordance with a typical embodiment of the invention;

FIG. 4 is a block diagram of a call sequence that shows message flows that pass between various communication entities operating in an asynchronous system in which DAP handoff is not supported by the AT;

FIG. 5 is a block diagram of a call sequence that shows message flows that pass between various communication entities operating in a synchronous system in which a DAP handoff is supported by an AT;

FIG. 6 is a flowchart that shows the procedures that the AT uses in determining the DAP handoff supported by the AT;

FIG. 7 is a block diagram of a call sequence that shows message flows between various communication entities operating in a synchronous system in which a DAP handoff is supported by an AT, but at the request of one of the communication entities;

FIG. 8 is a flowchart that shows the procedures that the AT uses in determining the DAP handoff supported by the AT at the request of one of the communication entities; and

FIG. 9 is a schematic diagram of a hardware portion of a device for implementing a DAP handoff process in accordance with typical embodiments.

DETAILED DESCRIPTION

The following description is presented in order to enable any person skilled in the art to make and use the invention. In the following description, details are set forth for purposes of explanation. One skilled in the art will appreciate that the invention may be practiced without these specific details. In other cases, well-known structures and processes are not described in detail in detail, so as not to obscure the description of the invention with unnecessary details. Thus, it is not intended that the present invention be limited to these embodiments, but it should correspond to the broadest possible scope consistent with the principles and features described herein.

In addition, for the sake of brevity and clarity, the following description uses terminology related to the terminology of Ultra Mobile Broadband (UMB), distributed by the Telecommunications Industry Association (TIA) as part of the Third Generation 2 Partnership Project (3GPP2). It should be emphasized that the invention is also applicable to other technologies, such as technologies and related standards related to code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), multiple access orthogonal frequency division (OFDMA) and so on.

In FIG. 3 schematically shows the relationships of various communication objects configured in accordance with a typical embodiment of the invention.

In FIG. 3, the communication system is generally indicated by the reference numeral 30. In the communication system 30, an access gateway (AGW) 32 is connected to many developed base stations (eBS), two of which are shown as eBS 34 and eBS 36. eBS 34 and eBS 36 can be installed on the same access network (AN) or on different ANs. In this example, eBS 34 and 36 are parts of AN 41 and AN 43, respectively. Each of AN 41 and AN 43 may contain one or more eBS and other entities. For purposes of clarity and conciseness, each AN is shown with only one eBS in FIG. 3. In the embodiment shown in FIG. 3, eBS 34 provides wireless access to users within the service area 35. Similarly, the eBS 36 provides wireless access within the coverage area 37. AGW 32 is connected to a core network 38, which may be, for example, the Internet. As another example, core network 38 may be an intranet in a closed network.

The reference network session controller (SRNC) 40 is connected to the AGW 32. The SRNC 40 performs several functions. For example, the SRNC 40 provides an authentication function to an access terminal (AT), such as the AT 44 shown in FIG. 3. In addition, the SRNC 40 stores an AT 44 communication session for any new eBS that is ready to communicate with the AT 44. Also, the SRNC 40 mainly manages paging procedures in an idle state.

Assume that the AT 44 has the ability to move between different radio networks including the AN 41 and AN 43. In order for the AT 44 to gain access to the core network 38, the AT 44 first needs to establish a data attach point (DAP) with a communication entity such as eBS 34 or eBS 36. In this description of the invention and in the amended claims, the term “data attachment point” is understood as a communication entity that connects data either directly or indirectly to and from a network gateway. By way of illustration, for example, as shown in FIG. 3, if the eBS 34 is designated as DAP, data from the core network 38, after passing through the gateway entity, in this case AGW 32, are connected by the communications entity serving as the DAP, in this case the eBS 34, before they reach other communications entities, such as eBS 36, via data path 62. In this example, eBS 34 binds data directly from AGW 32 via data path 62. The same is true for backward data flow. That is, data received from other communication entities is communicated through DAP before it reaches the gateway entity.

In the AN-initiated DAP assignment configuration, each of the eBS 34 and eBS 36 continues the DAP assignment process if certain criteria are met. For example, when the eBS 34 becomes the forward link serving eBS (FLSE) for the AT 44, it may begin the DAP assignment process. Thus, if the eBS 34 is the current FLSE, the eBS 34 sends a registration request message to the AGW 32. After that, the AGW 32 updates the binding to the eBS 34 in accordance with the procedures set forth in the Proxy Mobile IP Protocol (PMIP) distributed IETF.

Assume that the communication system 30 is a synchronous system. That is, all communication objects, for example AGW 38, eBS 34 and eBS 36, etc., operate in accordance with a basic time reference. The main reference may be, for example, global positioning system (GPS) time. In this case, the predefined DAP registration protocol can be configured, for example, allowing the processing and approval of the first arriving request as a DAP until the next approval. However, problems may arise if system 30 is an asynchronous system. Lack of a basic time reference can result in the erroneous assignment of a DAP.

Reference is now made to FIG. 3 in conjunction with FIG. 4, which shows message flows between various objects. Assume that system 30 is a system using an AN-initiated DAP handoff scheme. Moreover, suppose that the AT 44 is moving in the overlapping area 46 of the service areas 35 and 37 at that moment. eBS 34, having detected the presence of AT 44, sends a registration request message to AGW 32 at time t1, trying to register with AGW 32 as a DAP for AT 44, as shown by message flow 48 in FIG. 4. Assume that in the system 30 there is a rule "first come - first served." According to this rule, eBS 34, being the first to send a registration request message, assumes DAP for AT 44.

With AT 44 in overlapping coverage area 46, suppose that eBS 36 also detects the presence of AT 44. In this example, eBS 36 also sends a registration request message to AGW 32 at time t2, as shown by message flow 50 in FIG. 4. Here t2 is a later point in time than t1.

For some reason, a message sent in message flow 50 arrives at AGW 32 earlier than a message in message flow 48. More specifically, a message sent with eBS 36 arrives at AGW 32 at time t3, while a corresponding message sent with eBS 34 arrives at AGW 32 at time t6. In this case, time t6 is later than time t3. The above scenario may occur, for example, in a communication environment in which the eBS 36 has better communication states than the eBS 34 communication states.

As for AGW 32, after it received the registration message from eBS 36 at time t3, according to the “first come, first served” rule, AGW 32 confirms the request and sends a message about successful registration to eBS 36 at time t4 and reaches eBS 36 at time t5. Thus, eBS 36 was successfully registered as a DAP for AT 44.

Suppose that the AGW 32 also receives a registration request message from the eBS 34 at time t6. The time t6 is a later time than the time t5, which is the time at which the eBS 36 is successfully registered in the AGW 32 as a DAP for the eBS 34.

Depending on the registration protocol implemented in the AGW 32, the AGW 32 may suggest that the eBS 34 seeks to take on the role of the new DAP, replacing the current eBS 36 DAP.

After that, AGW 32 sends a successful registration response to eBS 34 at time t7 and reaches eBS 34 at time t8. EBS 34 then takes on a new role as a DAP.

In the above example, it is assumed that eBS 34 will be the priority DAP, that is, without eBS 36, which assumes the mediation role of DAP. Such a DAP assignment can cause problems. Even assuming that the session data is not corrupted, such a DAP assignment can cause a steady and inefficient redirection of the data stream, and, thus, excessive use of communication resources. Any attempt to recover from errors undoubtedly requires additional time and resources with additional difficulties.

In the future, it should be noted that although PMIP binding messages sent by eBS 34 and eBS 36 in message flows 48 and 50, respectively, may contain time stamps to prevent extraordinary binding updates, however, since system 30 operates asynchronously, the time stamps may be ineffective in performing their functions. The reason is that each of the communication objects, such as eBS 34 or eBS 36, operates on its own time reference in an asynchronous system. The time stamps on the binding messages sent to the AGW 32 are not related to the main time reference, but rather are related to their individual objects. The time references of objects can have large values of displacement relative to each other. Thus, as indicated above, the problem can still occur.

FIG. 5 is a message flow diagram that illustrates a DAP handoff scheme supported by an AT or initiated by an AT, in accordance with an exemplary embodiment of the invention. Hereinafter, the terms “supported AT” and “triggered AT” are used interchangeably.

The following are references to FIG. 5 in conjunction with FIG. 3. Assume that AT 44 initially interacts with eBS 34, which is the last entity that performed PMIP binding with AGW 40. Essentially, eBS 34 is the current DAP for AT 44.

AN 44 has a set of routes (RS) in its memory. An RS contains a set of communication objects, such as eBS 34 and eBS 36, that have wireless routes with AT 44, whereby each object in RS can tunnel packets at both the connection level and IP packets with AT 44, and vice versa. In a DAP handoff performed by an AT or initiated by an AT, the AT 44 helps the communication entities in the RS decide which entity in the RS should be the DAP.

A handoff supported by the AT prevails over a corresponding handoff initiated by the AN in several aspects.

First, in an asynchronous system, such as the system previously depicted in FIG. 4, competition conditions may occur, as explained above. The AT supported DAP handoff is better suited to avoid such problems. For example, an AT does not need to initiate another DAP move until a response to an earlier DAP move is received and completed.

Secondly, DAP is a data anchor for AT from AGW to RAN. It is preferable to have a DAP in RS AT. As a result of this, if necessary, flexible and quick updates may become possible. For example, suppose that the AGW needs to update the policy for AT and that a change is required during the current AT session. The change can be transferred from AGW to the DAP, which in turn will transfer the change to AT for a quick update. On the other hand, if DAP is not in the AT route set, the change cannot be updated so easily and quickly.

In addition, the AT has its own state of communication information with various eBS in RS. Thus, the AT is in a better position to determine whether the current communicating eBS is sufficiently stable, i.e. FLSE, for functioning as a DAP.

In addition, AT-supported DAP handoff is simpler than AN-initiated DAP handoff, both in the number of messages transmitted and in execution.

With reference to FIG. 3 and 5, suppose that the AT 44 moves to the eBS 36 service area 37. Then the AT 44 interacts with the eBS 36. Thus, the eBS 36 acts as a FLSE for the AT 44.

In a handoff supported by the AT, as described in this embodiment, the AT may weight and evaluate certain criteria or conditions before deciding whether to start the DAP handover process. In particular, the AT may decide whether the communication time with the current FLSE has reached a predetermined value. This avoids designating the FLSE as a DAP if interactions with the FLSE are only temporary. In addition, the AT may decide whether a predetermined period of time has elapsed since the last handover before starting the handover process supported by the AT. The reason is that it is undesirable for an AT to transfer DAP service too often, since frequent and unnecessary handoffs can lead to inefficient use of communication resources. It is equally important that the AT can evaluate link states with different eBSs to decide if DAP handoff is acceptable. Undoubtedly, AT will not be a good move DAP handoff to the FLSE, with which the AT has unfavorable communication conditions with the FLSE.

Assume in this example that, after determining the expiration of a sufficient period of time and the favorable state of the radio link with eBS 36, the AT 44 decides to transfer the DAP service from eBS 34 to eBS 36. In the following description, eBS 34 is called the original eBS DAP. eBS 36 is called the target eBS DAP. The handover process begins with the AT 44 sending a request message, here referred to as a DAP move message, to the target DAP eBS 36. The request message flow path is indicated at 52, as shown in FIG. 5. The target DAP eBS 36 may accept or reject the request, for example, depending on the level of congestion with current calls passing through eBS 36.

If the target DAP eBS 36 receives the request, the target DAP eBS 36 updates the binding of the attached data to the AGW 32 by sending a PMIP registration request message to the AGW 32, for example, using the PMIPv4 protocol. The message flow is indicated at 54, as shown in FIG. 5.

AGW 32 confirms the binding update by sending a PMIP registration response message to the target eBS 36 DAP, as shown using the message flow path 56 of FIG. 5. Then, a data tunnel can be established between the AGW 32 and the AT 44 through the target DAP eBS 36. A data tunnel lifetime parameter can be included in the PMIP registration response message. The lifetime parameter is introduced to prevent a scenario in which, when the AT 44 is idle, the tunnel is still saved, resulting in inefficient use of communication resources. If the AT 44 needs to maintain active communication after the specified lifetime, the AT 44 must send another message about the movement of the DAP with a request to the eBS 36 before the expiration of the lifetime.

Upon completion of the binding update process, the target eBS 36 DAP responds to AT 44 in the form of a DAP assignment message, as shown in message flow path 58 of FIG. 5. The DAP Assignment Message informs the AT 44 whether the DAP handover was successful. In addition, the DAP assignment message may include, in particular, a timestamp set by the AGW 32 for successful PMIP registration in the target DAP eBS 36 and support for the remaining lifetime of the data binding tunnel. If the time stamp of the DAP assignment message is set to a value smaller than the corresponding time stamp of the previous DAP assignment message processed in the AT 44, the AT 44 may ignore the DAP assignment message, i.e. a message sent via path 58 of the message flow. By functioning in this way, the competition condition as shown in FIG. four.

On the other hand, if the time stamp in the DAP assignment message via path 58 of the message flow has a later value, i.e. higher than any of the corresponding timestamps of the pre-processed DAP assignment messages by AT 44, the AT 44 can mark the data path to the target eBS 36 as a DAP route. In addition, the AT 44 may mark other data path routes to other eBS as a non-DAP route. At the same time, the AT 44 can initiate its own timer associated with the newly tagged DAP route to adjust the frequency of the DAP handoff. As mentioned earlier, it is preferable not to perform DAP handoffs too often, for example, with a small change in link state. Frequent and excessive DAP handoffs can affect congestion on the AGW 32, for example.

The eBS 36 destination DAP then notifies all eBS in the AT 44 route set of the adoption of the DAP role for AT 44. The notification is in the form of a notification message over the Internet Protocol (IPT) tunnel to all eBS and any associated objects in the AT 44 route set. One of them is shown in a message path 60 sent by an intended eBS 36 to a reference network session controller (SRNC) 40. An IPT notification message sent via a path 60 serves several purposes. First, the target DAP eBS 36 informs other eBS that the target DAP eBS 36 is now the current DAP. In addition, the IPT notification message may also include the message sequence size and timestamp that the target eBS 36 DAP previously used when updating the data attach binding with the AGW 32.

For the SRNC 40, in order to confirm that the eBS 36 is the current DAP, the SRNC 40 sends an IPT notification acknowledgment, as shown by the message flow 62 in FIG. 5.

In addition to notifying other eBS of the assumption of the DAP role, as indicated above, in particular, the target eBS 36 informs the source DAP 34 of the assumption of the role of the current DAP by sending an IPT notification message to the original eBS 34 DAP, as shown by 66 message flow on FIG. 5. The IPT notification message informs the source eAP 34 DAP that the target eBS 36 is the current eBS DAP. Again, the IPT notification message may contain the message sequence size and timestamp that the target eAP 36 DAP used to update the data attach binding with the AGW 32.

For the original eBS 34 DAP, in order to confirm that the eBS 36 is the current DAP, the original eBS 34 DAP needs to send an IPT notification confirmation message, as shown by 68 message flow 68 in FIG. 5. Optionally, the IPT notification confirmation message may indicate whether the sender of this message is the current FLSE for AT 44. After receiving the IPT notification confirmation message, the target eBS 36 completes the DAP handover process. After that, the IP packet stream, instead of an indirect route through eBS 34, along the path 62 of the packet data stream, as shown in FIG. 3, passes directly through eBS 36 along path 64 of the data packet stream.

FIG. 6 shows a flowchart that summarizes the procedures that the AT 44 uses in determining the DAP handoff supported by the AT.

FIG. 7 is a message flow diagram that shows another embodiment that illustrates another AT-supported DAP handoff method. In this embodiment, the handover is initiated by the AT, but at the request of the infrastructure entity.

Next, reference is made to FIG. 7 in conjunction with FIG. 3. Assume that eBS 34 is the last entity to perform PMIP binding with AGW 40 for AT 44. Essentially, eBS 34 is the current DAP for AT 44.

Similar to the previous description, in a DAP handoff supported by an AT or initiated by an AT, the AT 44 facilitates the decision of an eBS in RS about which eBS in RS should be a DAP.

There may be many possibilities for communications or infrastructure entities to request the AN 44 to initiate a DAP handover. For example, the current DAP, in this case eBS 34, may be overloaded with calls. To facilitate congestion, any infrastructure, such as an eBS 34 or eBS 36, may request the AT 44 to initiate a handover process.

As another example, suppose an AT moves in a service area, communicating with a new eBS that is associated with a new AGW, a new eBS may need to establish a PMIP connection through an AGW handoff, regardless of whether the new eBS is FLSE for AT or not. In this scenario, any of the above network or infrastructure can also request AT 44 to initiate the DAP handoff process.

Assume, in this case, that the target DAP eBS 36 makes such a request to the AT 44 for handover of the DAP from eBS 34 to eBS 36. Referring to FIG. 7, the target DAP eBS 36 may request through a DAPMoveRequestRequest message (DAP move request request) sent to the AT 44, as shown in message flow path 70 of FIG. 7. A LinkID (Link Identifier) associated with the IP data packet path associated with, for example, eBS 36 may be included in the DAP relocation request request message.

The AT 44 may accept or reject such a request. If the AT 44 rejects the request, the AT 44 sends a denial message to the eBS 36. Alternatively, the AT 44 rejects the request, allowing the expiration of the pre-set unresponsive timer for eBS 36.

In determining whether to accept or reject a request, as in the previous embodiment, many factors can be considered. Assume that eBS 36 is currently a FLSE, but not a DAP for AT 44. If a set of predefined states is found as described above, the AT can accept a DAP handover request from eBS 34 to eBS 36. On the other hand, if AT 44 does not plan to use eBS 36 as FLSE for a long time, or, for example, communication conditions are not favorable, AT 44 may reject the request.

If the request is denied, the DAP handover process ends without changing the DAP. That is, the AT 44 continues to use the eBS 34 as the current DAP through the IP data stream 62 (FIG. 3).

Suppose the AT 44 accepts the request. The acceptance is transmitted to the target eBS 36 by sending a request DAP move message via the message flow path 72 to the eBS 36 in this embodiment.

It should be noted that the AT 44 should not send more than one DAP move message with a request within the deadline set in the preset timer in the message. In addition, during the DAP handover performed by AT, but upon request of the infrastructure object, as described in this embodiment, the target eBS 36 should not send any DAP assignment messages until a request for DAP move message, for example, a message sent through message flow path 70 will not be accepted on eBS 36.

FIG. 8 shows a flowchart that summarizes the procedures that the AT 44 uses in determining the DAP handoff performed by the AT at the request of a network entity.

After that, the DAP handover process is mainly similar to the handover process, as described in the previous embodiment. For purposes of clarity and conciseness, the remaining steps shown in FIG. 7 are not specified hereinafter.

FIG. 9 shows part of a hardware implementation of a device for executing handover processes, as described above. The device as a whole is indicated by 90 and may be implemented in AT or any communication entities such as eBS or AGW.

The device 90 comprises a main data bus 92 connecting 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 device 90 is part of a wireless device, the transmit and receive circuits 96 and 98 may be connected to the radio frequency circuit, but this is not shown in the drawing. The receive circuit 96 processes and buffers the received signals before sending it to the data bus 92. On the other hand, the transmission circuit 98 processes and buffers data from the data bus 92 before sending it from the device 90. The CPU / controller 94 performs the data management function of the data bus 92 and further the general data processing function, including the execution of the control contents of the memory unit 100.

Instead of the separate arrangement shown in FIG. 9, alternatively, the transmission circuit 98 and the reception circuit 96 may be parts of a CPU / controller 94.

The memory unit 100 includes a set of modules and / or instructions, typically denoted by a numerical reference 102. In this embodiment, the modules / instructions include, in particular, a handover function 108. The handover function 108 comprises machine instructions or code for performing process steps, as shown and described in FIG. 5-8. Specific object-specific commands may be selectively implemented in handover function 108. For example, if the device 40 is part of an AT, instructions for executing the steps of the process shown and described in FIG. 6 and 8, along with the arrangement and processing of messages related to AT, as shown and described in FIG. 5 and 7 may be programmed in handover function 108. Similarly, if the device 40 is part of a communication object, such as an eBS, process steps specific to that communication object can be programmed in handover function 108.

In this embodiment, the memory unit 100 is a RAM (random access memory) circuit. Typical functions, such as handover function 108, are software routines, modules, and / or data sets. The memory unit 100 may be associated with another memory circuit (not shown), which may be of a volatile or non-volatile type. Alternatively, the memory unit 100 may be made of other types of circuits, such as EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM (Electrically Programmable Read-Only Memory), ROM (Read-Only Memory), ASIC (Specialized Integrated Circuit), Magnetic a disk, an optical disk, and others well known in the art.

It should be further noted that the patentable process, as described, can also be programmed as machine-readable instructions transferred to any computer-readable medium known in the art. In this description of the invention and the appended claims, the term “computer-readable medium” refers to any medium that is involved in providing instructions to any processor, such as a CPU / controller 94, shown and described in FIG. 9, for execution. Such a medium may be a type of storage device and may take the form of a volatile or non-volatile storage medium also described previously, for example, in the description of the memory unit 100 in FIG. 9. Such an environment may also be of a transmitting type and may include a coaxial cable, a copper wire, an optical cable and a wireless interface transmitting acoustic, electromagnetic or optical waves capable of carrying signals read by machines or computers. Computer-readable media may be part of a computer product separate from device 90.

Ultimately, other changes are possible within the scope of the invention. Other than those described above, any other logic blocks, circuits, and algorithm steps described in connection with the embodiment may be implemented in hardware, software, firmware, or a combination thereof. Those skilled in the art will understand that these and other changes in form and detail can be made herein without departing from the scope and spirit of the invention.

Claims (35)

1. A communication method performed by an access terminal operating in a communication system, comprising:
communicating with a first developed base station, wherein the first developed base station is configured to directly communicate with the access terminal, and the first developed base station is further configured as a data attachment point for the access terminal;
communicating with a second developed base station, wherein the second developed base station is configured to directly communicate with the access terminal and directly communicate with said data attachment point;
providing an assessment of the state of the communication lines of the aforementioned first and second developed base stations; and
initiating by said access terminal a handover of said access terminal from said first developed base station to said second developed base station, based on said estimate, the handover includes a first time period when the access terminal receives data transmissions from the second developed base station through the first developed base station, as well as the second period of time when the access terminal receives data transmissions from the second developed base station without The first developed base station. 2. The method according to claim 1, further comprising communicating with said second developed base station after a predetermined period of time before initiating said handover. 3. The method according to claim 1, further comprising waiting for the expiration of a sufficient period of time after the last handover before initiating said handover. 4. The method according to claim 1, further comprising providing a set of criteria for said link states, and initiating said handover after satisfying said set of criteria. 5. The method according to claim 1, further comprising sending a request message to said second developed base station when initiating said handover. 6. The method according to claim 1, further comprising receiving a handover request from said second developed base station before initiating said handover. 7. The method according to claim 1, further comprising receiving a notification about the designation of a data attachment point from said second developed base station before said handover. 8. The method according to claim 7, further comprising a time stamp in said notification of the designation of a data attachment point. 9. A communication method performed by a target developed base station configured to directly communicate with an access terminal in a communication system that includes a source developed base station configured to directly communicate with an access terminal and a target developed base station, the method comprising :
receiving a handover request message for handover of said access terminal from a source developed base station to a target developed base station;
receiving the first data transmissions intended for the access terminal from the original developed base station after receiving the handover request message;
redirecting the first data transmissions to the access terminal;
receiving second data transmissions intended for the access terminal without the participation of the original developed base station; and
redirecting second data transmissions to the access terminal. 10. A communication device operating in a communication system, comprising:
means for communicating with a first developed base station, wherein the first developed base station is configured to directly communicate with the access terminal, and the first developed base station is further configured as a data attachment point for the access terminal;
means for communicating with a second developed base station, wherein the second developed base station is configured to directly communicate with the access terminal and directly communicate with said data attachment point;
means for providing an assessment of the state of communication lines of said first and second developed base stations; and
means for initiating, by the access terminal, handoff of said access terminal from said first developed base station to said second developed base station, based on said estimate, the handover includes a first time period when the access terminal receives data transmissions from the second developed base stations through the first developed base station, as well as the second time period when the access terminal receives data transmissions from the second developed base station AI developed without the participation of the first base station. 11. The device of claim 10, further comprising means for communicating with said second developed base station after a predetermined time period for initiating said handover. 12. The device according to claim 10, further comprising means for waiting for the expiration of a sufficient period of time after the last handover before initiating said handover. 13. The device of claim 10, further comprising means for providing a set of criteria for said link states and initiating said handover after satisfying said set of criteria. 14. The device of claim 10, further comprising means for sending a request message to said second developed base station when initiating said handover. 15. The device of claim 10, further comprising means for receiving a handover request from said second developed base station before initiating said handover. 16. The device of claim 10, further comprising means for receiving notification of the designation of a data attachment point from said second developed base station before said handover. 17. The device according to clause 16, in which the said notification about the appointment of the data attachment point further includes a time stamp. 18. The target developed base station configured to directly communicate with an access terminal in a communication system that includes a source developed base station configured to directly communicate with an access terminal and a target developed base station, wherein the target developed base station includes yourself:
means for receiving a handover request message for handover of said access terminal from a source developed base station to a target developed base station;
means for receiving first data transmissions intended for an access terminal from an original developed base station after receiving a handover request message;
means for redirecting the first data transmissions received from the original developed base station to the access terminal;
means for receiving second data transmissions intended for the access terminal without the participation of the original developed base station; and
means for redirecting second data transmissions to the access terminal. 19. An access terminal operating in a communication system, comprising:
CPU; and
a circuit associated with said processor and configured to:
communicating with the first developed base station, wherein the first developed base station is configured to directly communicate with the access terminal, and the first developed base station is further configured as a data attachment point for the access terminal;
communicating with a second developed base station, wherein the second developed base station is configured to directly communicate with the access terminal and directly communicate with said data attachment point;
providing an assessment of the state of the communication lines of said first and second developed base stations; and
initiating, by said access terminal, handoff of said access terminal from said first developed base station to said second developed base station, based on said estimate, the handover includes a first time period when the access terminal receives data transmissions from the second developed base station through the first developed base station, as well as the second time period when the access terminal receives data transmissions from the second developed base station without Asthia of the first developed base station. 20. The access terminal of claim 19, wherein said circuit and said processor are further configured to communicate with said second developed base station after a predetermined period of time before initiating said handover. 21. The access terminal according to claim 19, wherein said circuit and said processor are further configured to wait for a sufficient period of time after the last handover to elapse before initiating said handover. 22. The access terminal according to claim 19, wherein said circuit and said processor are further configured to provide a set of criteria for said link states and to initiate said handover after satisfying said set of criteria. 23. The access terminal according to claim 19, wherein said circuit and said processor are further configured to send a request message to said second developed base station when initiating said handover. 24. The access terminal of claim 19, wherein said circuit and said processor are further configured to receive a handover request from said second developed base station before initiating said handover. 25. The access terminal according to claim 19, wherein said circuit and said processor are further configured to receive notification of a data attachment point designation from said second developed base station before said handover. 26. The access terminal of claim 25, wherein said notification of designating a data attachment point further comprises a time stamp. 27. The target developed base station configured to directly communicate with an access terminal in a communication system that includes a source developed base station configured to directly communicate with an access terminal and a target developed base station, the target developed base station comprising:
CPU; and
a circuit associated with the processor and configured to:
receiving a handover request message for handover of said access terminal from a source developed base station to a target developed base station;
receiving first data transmissions intended for the access terminal from the original developed base station after receiving a handover request message;
redirecting the first data transmissions received from the original developed base station to the access terminal;
receiving second data transmissions intended for the access terminal without the participation of the original developed base station; and
redirecting second data transmissions to the access terminal. 28. A computer-readable medium that contains computer-readable instructions for:
communicating with the first developed base station, wherein the first developed base station is configured to directly communicate with the access terminal, and the first developed base station is further configured as a data attachment point for the access terminal;
communicating with a second developed base station, wherein the second developed base station is configured to directly communicate with the access terminal and directly communicate with said data attachment point;
providing an assessment of the state of the communication lines of said first and second developed base stations; and
initiating, by said access terminal, handoff of said access terminal from said first developed base station to said second developed base station, based on said estimate, the handover includes a first time period when the access terminal receives data transmissions from the second developed base station through the first developed base station, as well as the second time period when the access terminal receives data transmissions from the second developed base station without Asthia of the first developed base station. 29. The computer-readable medium of claim 28, further comprising computer-readable instructions for communicating with said second developed base station after a predetermined period of time before initiating said handover. 30. The computer-readable medium of claim 28, further comprising computer-readable instructions to wait for a sufficient period of time after the last handover to elapse before initiating said handover. 31. The computer-readable medium of claim 28, further comprising computer-readable instructions for providing a set of criteria for said link states and initiating said handover after satisfying said set of criteria. 32. The computer-readable medium of claim 28, further comprising computer-readable instructions for sending a request message to said second developed base station when initiating said handover. 33. The computer-readable medium of claim 28, further comprising computer-readable instructions for receiving a handover request from said second developed base station before initiating said handover. 34. The computer-readable medium of claim 28, further comprising computer-readable instructions for receiving notification of a data attachment point designation from said second developed base station before said handover. 35. The computer-readable medium of claim 34, wherein said notification of designating a data attachment point further includes a time stamp.

Images