Handoff of data attachment point

(54) Title: DATA ATTACHMENT POINT HANDOFF (51) Int. Cl .: H04W 36/00 (30) Unionist Priority: 06/04/2007 US 60 / 910,628, 04/06/2007 US 60/910, 62811/03/2008 US 12 / 046,062, 04/06/2007 US 60 / 910,62811 / 03/2008 US 12/046, 06212/06/2007 US 60 / 943,459, 04/06/2007 US 60/910, 62811/03/2008 US 12/046, 06212/06/2007 US 60 / 943,45913 / 04/2007 US 60 / 911,858 (73) Holder (s): QUALCOMM INCORPORATED (72) Inventor (s): PEERAPOL

TINNAKORNSRISUPHAP; FATIH ULUPINAR; PARAG ARUN AGASHE; RAGULAN SINNARAJAH; RAVINDRA PATWARDHAN; RAJAT PRAKASH (74) Attorney (s): MONTAURY PIMENTA, MACHADO & LIOCE (86) International Application: PCT US2008059474 of 04/04/2008 (87) International Publication: WO

2008/156895 of 12/24/2008

<img file="BRPI0809985A2_D0001.tif" />

1/22

DATA ATTACHMENT POINT HANDOFF.

Field of the Invention

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

Description of the Prior Art

In telecommunications, especially wireless communications, the communication environments are not static, but slightly dynamic. In a mobile communication configuration, some communication entities, such as an Access Terminal (AT) can move from one location to another at different points in time.

Reference is directed to Figure 1, which presents a simplified scheme showing an exemplary communication system. In the following description, the terminology associated with an Ultra Mobile Broadband (UMB) system is used. The basic terminology and operating principles of the UMB system can be found in a publication of the 2nd Generation 3 Partners Project (3GPP2) established by the Telecommunications Industries Association (TIA), entitled Interoperability Specification, 3GPP2-A. S0020. As shown in Figure 1, within the Radio Access Network (RAN) 12, for example, in an Ultra Mobile Broadband (UMB) system in which an AT 14 is wirelessly accessing a main network (backbone) ) 16 via an evolved Base Station (eBS) 18. eBS 18 serves as a data exchange entity between AT 14 and an Access Portal (AGW, Access Gateway) 20. AGW 20 has direct access to the main network 16 The main network 16 can be the Internet, for example.

In Figure 1, eBS serves as the Data Attachment Point (DAP) for AT 14. More specifically, eBS 18 serving as DAP has traffic on the direct link

2/22 linked to AGW 20, for example, as operated in accordance with the Mobile IP Proxy Protocol (PMIP) promulgated by the Internet Engineering Task Force (IETF). According to the PMIP protocol, AGW 20 sends direct link data traffic to DAP, eBS 18 in this case, which, in turn, directs data traffic to AT 14. EBS 18 acts as the DAP, is the network entity that performs the last link with AGW 20.

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 to a different RAN.

Reference is now directed to Figure 2, which presents another simplified scheme illustrating the mobility of the TA 14.

Suppose, in Figure 2, that the AT 14 originally communicating with eBS 18 now moves away from eBS 18 and starts communicating with eBS 22. eBS 22 is now called the Direct Link Service (FLSE) eBS for the AT 14, since it is eBS 22 that communicates directly and exchanges data with AT 14. However, there has not yet been any link update with AGW 20. In other words, the network entity that carried out the last link with AGW 20 was still eBS 18 and there has been no link update with AGW 20 since then. Therefore, eBS 18 still works like DAP. According to such a scenario, data from AGW 20 is sent to eBS 18, which is DAP in this case, and then routed to AT 14 for eBS 22, which serves as the FLSE. The data packets from AGW 20 to AT 14 are routed according to data path 24, as shown in Figure 2.

Although the AT 14 roamed outside the coverage area served by eBS 18, eBS 18 remains the DAP for the AT 14. The reason is in the wireless configuration,

3/22 since, depending on the mobility of the AT 14, it is possible that eBS 18 will again become the FLSE for AT 14. For example, AT 14 may be on the borderline of the coverage areas provided by both eBS 18 as for eBS 22. Consequently, AT 14 can only communicate with eBS 22 temporarily. However, if the communications between AT 14 and eBS 22 are not temporary, the routing of data packets via the winding data path 24 may not have an efficient use of communication resources, at least from the perspective of using the return shipping. In addition, the latency of packet data is also impacted. Instead, DAP is preferably switched from eBS 18 to eBS 22. For such DAP switching, eBS 22 first needs to link direct link traffic to AGW 20. After the successful completion of the direct link traffic linking process, eBS 22 becomes the current DAP. The data packets are then routed from AGW 20 to AT 14 via eBS 22, as indicated by data path 26 in Figure 2. Switching the DAP from eBS 18 to eBS 22 can be based on certain criteria, for example, after ensuring that the TA communicates with eBS 22 for a predetermined period of time.

So far, DAP switching or selection, called DAP handoff, has in most cases been initiated by the AN. In the handoff initiated by the AN, the handoff process is transparent to AT 14. However, problems can arise if AT 14 is not aware of the handoff. For example, the intended DAP may turn out to be the missed DAP. This is especially true in an asynchronous environment in which the various communication entities are not synchronized with each other. Again with reference to Figure 2, suppose again that the TA is

4/22 at the border of the coverage areas of both eBS 18 and eBS 22. Detecting the presence of AT 14, for example, via signal strength on the downlink, in a handoff initiated by AN, both eBS 18 and eBS 22 try to be the DAP when registering with AGW 20 for direct link binding. Suppose also that AT 14 is well seated within the coverage area provided by eBS 18 and, consequently, eBS 18 must be the most suitable DAP for AT 14. However, if the log messages sent and received between AGW 20 and eBS 22 are faster than those between AGW 20 and eBS 18, eBS 22 can be assigned as the DAP in front of eBS 18, as opposed to that was intended. The recovery of the incorrectly assigned DAP, even if not fatal for the communication session involved, requires signaling and exchange of additional messages, which unnecessarily tie the communication resources.

Therefore, there is a need to provide a DAP allocation scheme with more accuracy and certainty, thus allowing for more efficient use of communication resources.

Summary of the Invention

In a communication system in which a portal entity is connected with a plurality of communication entities which in turn are operable to communicate with an access terminal, the access terminal must first establish a data attachment point (DAP) with one of the communication entities. The DAP handoff from one communication entity to another communication entity is initiated by the access terminal. Before proceeding with the DAP handoff, the access terminal can consider factors such as the link conditions with the various communication entities, the time since the last

5/22 DAP handoff, and the length of time communicating with the current communication entity. To prevent any race conditions for the communication entities to register as the DAP, the access terminal can refer to the time stamps of messages received from the communication entities. In addition, communication entities can also exchange messages with each other regarding the current DAP registration condition.

These and other characteristics and advantages will become evident to those skilled in the art with the following detailed description, considered together with the attached figures, in which the same reference numbers refer to the same elements.

Brief Description of the Figures

Figure 1 - is a simplified schematic design illustrating an exemplary communication system;

Figure 2 - is another simplified schematic project illustrating the mobility of an access terminal in the communication system;

Figure 3 - is a simplified schematic design that shows the relationships of the various communication entities arranged according to an exemplary embodiment of the invention;

Figure 4 - is a diagram of call flows that shows the message flows between the different communication entities operating in an asynchronous system in which the DAP handoff is not assisted by the TA;

Figure 5 - is a diagram of call flows that shows the message flows between the different communication entities operating in a synchronous system in which the DAP handoff is assisted by the TA;

6/22

Figure 6 - is a flowchart showing the procedures that the TA performs in determining the DAP handoff assisted by the TA;

Figure 7 - is a diagram of call flows that shows the message flows between different communication entities operating in a synchronous system in which the DAP handoff is assisted by the TA, however upon request from one of the communication entities;

Figure 8 - is a flowchart showing the procedures that the TA performs in determining the DAP handoff assisted by the TA upon request from one of the communication entities; and

Figure 9 - is a schematic design of part of the hardware implementation of a device to perform the DAP handoff processes according to the exemplary modalities.

Detailed Description of the Invention

The following description is presented to allow anyone skilled in the art to manufacture and use the invention. Details are presented in the description below for explanatory purposes. It should be noted that those skilled in the art would realize that the invention can be put into practice without using these specific details. In other cases, well-known structures and processes are not designed to obscure the description of the invention with unnecessary details. Thus, the present invention is not intended to be limited by the modalities shown, but must be agreed with the broadest scope consistent with the principles and features described herein.

In addition, in the description below, for reasons of brevity and clarity, the terminology associated with the Ultra Mobile Broadband (UMB) technology, as promulgated under the 2nd

7/22

3- Generation Partner Project (3GPP2) by the Telecommunications Industries Association (TIA) is used. It should be emphasized that the invention is also applicable to other technologies, such as the technologies and associated standards related to Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA) and so on.

Reference is now directed to Figure 3, which shows schematically the relationships of the various communication entities arranged according to an exemplary embodiment of the invention.

In Figure 3, the total communication system is generally represented by the reference number 30. In the communication system 30, there is an Access Portal (AGW) 32 connected to a plurality of evolved Base Stations (eBSs), two of which are shown such as eBS 34 and eBS 36. eBS 34 and eBS 36 can be installed in the same Access Network (AN) or in different ANs. In this example, eBSs 34 and 36 are part of an AN 41 and an AN 43, respectively. Each of the AN 41 and AN 43 may include one or more eBSs and other entities. For clarity and conciseness, each NA is

<td>shown</td><td>with just</td><td>an</td><td>eBS</td><td>at</td><td>Figure</td><td> 3.</td><td>At</td><td>modality</td>

<td>shown</td><td>in the figure</td><td>3, the</td><td>eBS</td><td> 34</td><td>provides</td><td colspan="2">access</td><td>wireless a</td>

<td>users</td><td>inside of</td><td>an</td><td>area</td><td>in</td><td colspan="2">roof</td><td> 35.</td><td>Of the same</td>

In this way, eBS 36 provides wireless access within a coverage area 37. The AGW 32 has a connection to a main network 38, which can be the Internet, for example. Primary network 38 can be an intranet on a closed network, as another example.

There is a Session Reference Network Controller (SRNC) 40 connected to AGW 32. The SRNC 40 serves several

8/22 functions. For example, SRNC 40 provides authentication function to an Access Terminal (AT), such as AT 44 shown in Figure 3. In addition, SRNC 40 stores the AT 44 communication session for any new eBS that is prepared to communicate with the AT 44. SRNC 40 also controls alert procedures in the idle state in general.

Suppose the AT 44 is able to move between the various radio networks, including the AN 41 and the AN 43. For the AT 44 to access the main network 38, the AT 44 must first establish a Data Attachment Point (DAP) ) with a communication entity, such as eBS 34 or eBS 36. In this report and in the amended claims, the term data attachment point is interpreted as a communication entity to anchor data, directly or indirectly, to and from a network portal. By way of illustration, for example, as shown in Figure 3, if eBS 34 is designated as the DAP, the data from the main network 38, after passing through a portal entity, the AGW 32 in this case, is anchored by communication entity serving as DAP, eBS 34 in this case, before reaching other communication entities, such as eBS 36, via data path 62. In this example, eBS 34 anchors data directly from AGW 32 via the path of data 62. The same applies to the reverse data flow. That is, the data received from other communication entities are anchored by the DAP before reaching the portal entity.

In a DAP allocation arrangement initiated by the NA, each of the eBS 34 and eBS 36 proceeds with the DAP allocation process if certain criteria are met. For example, when eBS 34 becomes the Direct Link Service (FLSE) eBS for AT 44, this

9/22 can start the DAP assignment process. Thus, if eBS 34 is the current FLSE, eBS 34 sends a registration request message to AGW 32. Then, AGW 32 performs a link update with eBS 34 according to the procedures presented under the IP protocol Mobile Proxy (PMIP) published by the Internet Engineering Task Force (IETF).

established protocol,

Suppose that the communication system 30 is a synchronous system. That is, all communication entities, such as AGW 38, eBS 34 and eBS 36, etc., operate according to a master time reference. The master reference can be the Global Positioning System (GPS) time, for example. In that case, a pre-defined DAP record can be just like allowing the first incoming request to be processed and approved as the DAP until the next approval. However, problems can arise if system 30 is an asynchronous system. Due to the lack of a master time reference, an incorrect DAP assignment may occur.

Reference is now directed to Figure 3 together with Figure 4, which shows the sequence of message flows between the different entities. Suppose that system 30 is a system that uses the DAP handoff scheme initiated by the AN. Suppose also that AT 44 moves into overlapping zone 46 of coverage areas 35 and 37 at this junction. EBS 34, detecting the presence of AT 44, sends a registration request message in time tl to AGW 32, attempting to register with AGW 32 as the DAP for AT 44, as indicated by message flow 48 in the Figure 4. Suppose there is a first rule to come first to serve established in system 30. According to this rule, eBS 34, being the

10/22 first to send the registration request message, intends to be the DAP for AT 44.

With AT 44 in the overlapping coverage zone 4 6, assume 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 Figure 4. Here, t2 is later in time than tl.

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

As for AGW 32, since it receives the registration message from eBS 36 at time t3, according to the first to come first service rule, AGW 32 approves the request and sends a registration success message to eBS 36 at time t4 and search for eBS 36 at time t5. Consequently, eBS 36 is successfully registered as the DAP for AT 44.

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

Depending on the registration protocol implemented in AGW 32, AGW 32 can assume that eBS 34 wants to assume the role of a new DAP, replacing eBS 36 from the current DAP.

11/22

<td>Then,</td><td>The</td><td>AGW</td><td>32 sends</td><td>an answer</td><td>in</td>

<td>registration success</td><td>eBS</td><td> 34</td><td>in time t7</td><td>and search for eBS</td><td> 34</td>

<td>at a t8 time. EBS</td><td> 34</td><td colspan="2">then assume the</td><td>new role as</td><td>The</td>

DAP.

In the example above, eBS 34 intends to be DAP first, that is, without eBS 36 assuming the role of intermediate DAP. Such DAP assignment can create problems. Suppose there is no damage to the communication session data, such as a DAP assignment that can cause persistent and inefficient traffic routing, and consequently unnecessary obstruction of communication resources. Any attempt at error recovery certainly requires additional time and resources with additional complexities.

It should also be noted that although PMIP binding messages sent by eBS 34 and eBS 36 via message flows 48 and 50, respectively, may have time stamps to prevent out-of-order binding updates. However, since system 30 operates asynchronously, time stamps may be inefficient to perform their functions. The reason is that each of the communication entities, such as eBS 34 or eBS 36, operates based on its own time reference in an asynchronous system. The time marks in the linking messages sent to AGW 32 are not related to the master time reference, but to the references of the individual entities. The time references of the entities can have a large amount of displacement, each. Consequently, the problem as mentioned above can still occur.

Figure 5 is a message flow diagram showing a DAP handoff scheme assisted by the TA or a DAP handoff scheme initiated by the TA according to

12/22 with an exemplary embodiment of the invention. In the following, the terms assisted by the TA and started by the TA are used interchangeably.

Reference is now made to Figure 5 together with Figure 3. Suppose that the AT 44 is initially in communication with eBS 34, which is the last entity that made the PMIP link with AGW 32. Therefore, eBS 34 is the current DAP for the AT 44.

The AT 44 has a Set of Routes (RS) in its memory. RS includes a set of communication entities, such as eBS 34 and eBS 36, which have air interface routes with the AT 44, so that each entity in RS can tunnel both link layer packets and packets IP with AT 44, and vice versa. In a DAP handoff assisted by AT or initiated by AT, AT 44 helps communication entities in RS to make the decision about which entity in RS should be DAP.

An AT-assisted handoff prevails over a corresponding AN-initiated handoff in several respects.

First, in an asynchronous system, such as the system shown earlier in Figure 4, running conditions can occur as explained above. The AT-assisted DAP handoff is more capable of avoiding such a problem. For example, the TA does not need to initiate another DAP change until the response from the previous DAP change is received and finalized.

Second, the DAP is the data anchor for the AGW TA in an RAN. It is preferable to have the DAP in the RS of the TA. As a consequence, flexibility and quick updates, when needed, may be possible. For example, suppose the AGW needs to update a policy for the TA and the change is required during the current TA's communication session. The change can be transmitted from AGW to the

13/22

DAP, which in turn relays the change to the AT to update quickly. On the other hand, if the DAP is not in the RS of the TA, the change may possibly not be updated so easily and quickly.

In addition, the AT has a first-hand knowledge of its linkage conditions with the various eBSs in RS. Therefore, the TA is in a better position to determine whether the eBS currently in communication, that is, the FLSE, is stable enough to act as a DAP.

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

Reference is now turned to Figures 3 and 5. Suppose that AT 44 moves to coverage area 37 of eBS 36. AT 44 then communicates with eBS 36. Consequently, eBS 36 acts as the FLSE for AT 44 .

In an AT-assisted handoff as described in this modality, the AT can weigh and evaluate certain criteria and conditions before deciding whether to start the DAP handoff process. Among other things, the TA can consider whether the length of time communicating with the current FLSE has reached a predetermined extent. This is to avoid designating FLSE as DAP if communications with FLSE are only temporary. In addition, the TA may decide whether a predetermined time has elapsed since the last handoff before starting the TA assisted handoff process. The reason is that it is undesirable for the TA to handoff DAPs too frequently, because frequent and unnecessary handoffs can result in inefficient consumption of communication resources. Equally as important, the TA can assess the link conditions of communication with various eBSs to decide whether a DAP handoff is justified. It certainly wouldn't be a good move to

14/22 the TA to carry out the DAP handoff to the FLSE, since the TA is having unfavorable communication conditions communicating with the FLSE.

Suppose in this example, that after determining that a certain amount of time has elapsed and that the radio link conditions are favorable with eBS 36, AT 44 decides to handoff the DAP from eBS 34 to eBS 36. In the following description, eBS 34 is called the original DAP eBS. EBS 36 is called target DAP eBS. The handoff process begins with the AT 44 sending a request message, here called a DAPMoveRequest message, to the target DAP eBS 36. The flow path of the request message is represented by reference number 52, as shown in Figure 5. Target DAP eBS 36 can accept or refuse the request, for example, depending on the level of congestion of the ongoing calls passing through of eBS 36.

If target DAP eBS 36 accepts the request, target DAP eBS 36 updates the data attachment link with AGW 32 by sending a PMIP Registration Request message to AGW 32, for example, via the PMIPv4 protocol. The message flow is designated by reference number 54, as shown in Figure 5.

AGW 32 confirms the link update by sending a PMIP Registration Reply message to target DAP eBS 36, as shown by message flow 56 in Figure 5. Then, a data tunnel can be established between AGW 32 and AT 44 via target DAP eBS 36. In the PMIP Registration Reply message, a data tunnel lifetime parameter can be included. 0 lifetime parameter is to prevent the scenario according to which, when the AT 44 enters standby, the tunnel is still maintained, resulting in unproductive use of

15/22 communication resources. If the AT 44 needs to maintain active communications after reaching the lifetime, the AT 44 must send another DAPMoveRequest message to eBS 36 before the lifetime expires.

Upon completion of the link update process, target DAP eBS 36 responds to AT 44 with a DAPAssignment message, as shown in message flow path 58 shown in Figure 5. The DAPAssignment message informs AT 4 4 if the DAP handoff is successful. In addition, the DAPAssignment message may include, among other things, a time stamp issued by AGW 32 for successful PMIP registration with target DAP eBS 36 and the remaining lifetime of the data tunnel linking. If the time stamp of the DAPAssignment message is set to a lower value than the corresponding time stamp of the previous DAPAssignment message processed by the AT 44, the AT 44 may disregard the DAPAssignment message, that is, the message sent via the flow path. 58. By operating in this way, the race condition described in Figure 4 can be avoided.

On the other hand, if the time stamp in the DAPAssignment message via flow path 58 has the most recent value, that is, a value higher than any of the corresponding time stamps in the DAPAssignment messages previously processed by the AT 44, the AT 44 can mark the data path route to target eBS 36 as the DAP route. In addition, the AT 44 can mark the other data path routes to the other eBS not as the DAP route. At the same time, the AT 44 can start its own timer associated with the newly marked DAP route to regulate the frequency of DAP handoffs. As mentioned earlier, it is preferable not to make handoffs

16/22 DAP too often, as, for example, by slightly changing the link conditions. Frequent and unnecessary DAP handoffs can affect the load on the AGW 32, for example.

The target DAP eBS 36 then notifies all eBSs in the RS 44 of the AT 44 as assuming the role of DAP for the AT 44. The notification is in the form of an Internet Protocol Tunnel Notification (IPT) message for all eBSs and any related entities in the RS of AT 44. One is shown in message path 60 sent by target eBS 36 to the Session Reference Network Controller (SNRC) 40. The IPT Notification message sent via route 60 serves several purposes. First, target DAP eBS 36 informs the other eBSs that target DAP eBS 36 is now the current DAP. In addition, the IPT Notification message may also include the message sequence number and the time stamp that the target DAP eBS 36 previously used to update the data attachment link with AGW 32.

In order for SRNC 40 to confirm that eBS 36 is the current DAP, SRNC 40 sends an IPT Notification Confirmation, as shown by the message flow path 62 in Figure 5.

In addition to notifying other eBSs to assume the role of DAP, as mentioned above, in particular, target eBS 36 informs source DAP 34 to obtain the role as the current DAP by sending an IPT Notification message to the source DAP eBS 34, as shown by the message flow path 66 in Figure 5. The IPT Notification message informs the source DAP eBS 34 that the target eBS 36 is the current DAP eBS. Again, the IPT Notification message can include the sequence number of the

17/22 message and the time stamp that the target DAP eBS 36 used to update the data attachment link with AGW 32.

For the source DAP eBS 34 to confirm that the source DBS 36 is the current DAP, it is necessary for the source DAP eBS 34 to send an IPT Notification Confirmation message, as shown by the message flow path 68 in Figure 5. Optionally, the IPT Notification Confirmation message can indicate whether the sender of which message is the current AT 44 FLSE. After receiving the IPT Notification Confirmation message, target eBS 36 completes the DAP handoff process. Then, the IP packet flow, instead of flowing through eBS 34 via the data packet flow path 62, as shown in Figure 3, flows directly through eBS 36 via the data packet flow path 64 .

Figure 6 shows a flow diagram that summarizes the procedures that the AT 44 performs in determining a DAP handoff assisted by the AT.

Figure 7 is a message flow diagram showing another modality that illustrates another DAP assisted handoff methodology. In this modality, the handoff is initiated by the TA, but at the request of an infrastructure entity.

Reference is now made to Figure 7 together with Figure 3. Suppose eBS 34 is the last entity that made the PMIP link with AGW 32 to AT 44. Therefore, eBS 34 is the current DAP for AT 44.

As previously described in a similar way, in a DAP handoff assisted by the AT or initiated by the AT, the AT 44 helps eBSs in RS to make the decision as to which eBS in RS should be the DAP.

18/22

There may be countless occasions when communications or infrastructure entities request that the AT 44 initiate a DAP handoff. For example, the current DAP, eBS 34 in this case, may be overloaded with calls. To alleviate congestion, any of the infrastructure entities, such as eBS 34 or eBS 36, can make a request to the AT 44 to start the handoff process.

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

Suppose in this case that the target DAP eBS 36 makes a request to the AT 44 to make a handoff from the DBS from eBS 34 to eBS 36. Reference is now made to Figure 7. The DBS eBS target 36 can make a request via a DAPMoveRequestRequest message sent to AT 44, as shown in the message flow path 70 in Figure 7. Included in the DAPMoveRequestRequest message may be the LinkID associated with the IP packet data route associated with eBS 36, for example.

AT 44 can accept or refuse such a request. If the AT 44 refuses the request, the AT 44 sends a refusal message to eBS 36. Alternatively, the AT 44 can refuse the request by allowing a pre-set timer to expire without responding to eBS 36.

In determining whether to accept or refuse the request, as in the previous modality, numerous factors

19/22 can be considered. Suppose eBS 36 is currently the FLSE, but not the DAP for AT 44. If a set of predetermined conditions as described above is satisfied, the AT can accept the DBS handoff request from eBS 34 to eBS 36. For On the other hand, suppose that if the AT 44 is not intended to use eBS 36 as the FLSE for a long time, or if the communication conditions are not favorable, for example, the AT 44 may refuse the request.

If the request is refused, the DAP handoff process ends without changing the DAP. That is, the AT 44 continues to use eBS 34 as the current DAP via the IP 62 flow data path (Figure 3).

Suppose AT 44 accepts the request. Acceptance is driven to target eBS 36 by sending a DAPMoveRequest message, via the message flow path 72 to eBS 36 in this mode.

It should be noted that the AT 44 must not send more than one DAPMoveRequest message within the time limit as fixed in a timer pre-fixed in the message. In addition, in the ATAP assisted DAP handoff process, except at the request of an infrastructure entity as described in this modality, the target eBS 36 must not send any DAPAssignment messages, unless a DAPMoveRequest message, such as the message sent via the message flow path 70, is received by eBS 36.

Figure 8 shows a flow diagram that summarizes the procedures that the AT 44 performs to determine a DAP handoff assisted by the AT upon request from a network entity.

Then, the DAP handoff process is substantially similar to the handoff process described in

20/22 previous mode. For clarity and conciseness, the remaining steps shown in Figure 7 are not elaborated on in more detail.

Figure 9 shows the hardware implementation part of a device to perform the handoff processes described above. The circuit device is indicated by reference number 90 and can be implemented in an AT or in any communication entities, such as, for example, an eBS or an AGW.

Apparatus 90 comprises a central data bus 92 which connects several circuits together. The circuits include a CPU (Central Processing Unit) or a controller 94, a receiving circuit 96, a transmission circuit 98, and a memory unit 100.

If the device 90 is part of a wireless device, the receiving and transmitting circuits 96 and 98 can be connected to an RF (Radio Frequency) circuit, but it is not shown in the figure. The receiving circuit 96 processes and stores (buffered) the received signals before sending them to the data bus 92. On the other hand, the transmission circuit 98 processes and stores the data from the data bus 92 before sending them to the data bus. device 90. The CPU / controller 94 performs the data management function of the data bus 92 and also the general data processing function, including executing the instruction contents of the memory unit 100.

Instead of being arranged separately as shown in Figure 9, as an alternative, the transmission circuit 98 and the receiving circuit 96 can be parts of the CPU / controller 94.

The memory unit 100 includes a set of modules and / or instructions generally represented by the

21/22 reference number 102. In this embodiment, the modules / instructions include, among other things, a handoff function 108. Handoff function 108 includes instructions or computer code to perform the process steps as shown and described in the Figures 5-8. Specific instructions specific to an entity can be selectively implemented in the handoff function 108. For example, if the apparatus 40 is part of an AT, for example, instructions for performing the process steps shown and described in Figures 6 and 8 together with the preparation and processing of messages relevant to the AT, as shown and described in Figures 5 and 7, can be coded in the handoff function 108. Similarly, if the apparatus 40 is part of a communication entity, such as, for example, an eBS, the process steps particular to that communication entity can be coded in the handoff function 108.

In this embodiment, the memory unit 100 is a RAM (Random Access Memory) circuit. Exemplary functions, such as the handoff function 108, are software routines, modules and / or data sets. The memory unit 100 can be connected to another memory circuit (not shown), which can be of the volatile or non-volatile type. Alternatively, memory unit 100 can be made of other types of circuit, such as an EEPROM (Electrically Programmable and Erasable Reading Memory), an EPROM (Electrically Programmable Reading Memory), a ROM (Reading Memory), a ASIC (Specific Application Integrated Circuit), a magnetic disk, an optical disk, and others well known in the art.

It should also be noted that the inventive processes as described can also be coded as computer-readable instructions carried in any readable medium.

22/22 by computer known in the art. In this report and in the appended claims, the term computer-readable medium refers to any medium that participates in providing instructions for any processor, such as CPU / controller 94 shown and described in the image in Figure 9, for execution. Such a medium can be of the storage type and can take the form of a volatile or non-volatile storage medium, as also described above, for example, in the description of memory unit 100 of Figure 9. Such medium can also be of the type transmission and may include a coaxial cable, a copper wire, an optical cable, and an aerial interface carrying acoustic, electromagnetic or optical waves capable of carrying signals readable by machines or computers. The computer-readable medium may be part of a computer product separate from the apparatus 90.

Finally, other changes are possible within the scope of the invention. In addition to those described above, any other blocks, circuits and logical algorithm steps described in relation to the modality 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 can be made without departing from the scope and inventive concept of the invention.

1/8