Handoff of data attachment point

“METHOD FOR ACCESS TERMINAL AND ACCESS TERMINAL

OPERABLE IN A COMMUNICATION SYSTEM AND LEGIBLE MEMORY BY

COMPUTER"

FIELD OF THE INVENTION

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

DESCRIPTION OF THE PREVIOUS TECHNIQUE

[002] 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.

[003] 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 principles of operation of the UMB system can be found in a publication of the 2nd 3rd Generation Partnership 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 the AT 14 and an Access gateway (AGW) 20. The AGW 20 has direct access

Petition 870200057028, of 05/08/2020, p. 5/12

2/25 to the main network 16. The main network 16 can be the Internet, for example.

[004] 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 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 the AT 14. EBS 18, acting as DAP, is the network entity that carries out the last link with AGW 20.

[005] 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.

[006] Reference is now directed to the Figure

2, which presents another simplified scheme illustrating the mobility of the TA 14.

[007] Suppose, in Figure 2, that AT 14 originally communicating with eBS 18 now moves away from eBS 18 and starts communicating with eBS 22. eBS 22 is now called eBS Direct Link Service (FLSE ) for 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. Thus, eBS 18 still works like DAP. According

Petition 870190122055, of 11/22/2019, p. 7/43

3/25 In such a scenario, AGW 20 data 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 to AT 14 are routed according to data path 24, as shown in Figure 2.

[008] 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, 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 and eBS 22. Consequently, AT 14 can only communicate with eBS 22 temporarily. However, if the communications between the 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 the communication resources, at least from the perspective of using the communication channel. 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 example, after being

Petition 870190122055, of 11/22/2019, p. 8/43

4/25 ensured that the TA communicates with eBS 22 for a predetermined period of time.

[009] Until now, the 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 become the unwanted 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 AT is 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 the 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, therefore, eBS 18 must be the most suitable DAP for AT 14. However, if log messages sent and received between AGW 20 and eBS 22 are faster than these between AGW 20 and eBS 18, eBS 22 can be assigned as the DAP in front of eBS 18, contrary to what 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.

Petition 870190122055, of 11/22/2019, p. 9/43

5/25

[0010] Therefore, there is a need to provide a DAP assignment scheme with more accuracy and certainty, thus allowing the most efficient use of communication resources.

SUMMARY OF THE INVENTION

[0011] In a communication system in which a gateway 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 DAP handoff, and the length of time communicating with the current communication entity. . In order 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.

[0012] 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

Petition 870190 122055, of 11/22/2019, p. 10/43

6/25

[0013] Figure 1 - is a simplified schematic project illustrating an exemplary communication system;

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

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

[0016] 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 AT;

[0017] 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;

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

[0019] 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 at the request of one of the communication entities;

[0020] Figure 8 - is a flow chart 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

Petition 870190122055, of 11/22/2019, p. 11/43

7/25

[0021] 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

[0022] 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 practiced 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.

[0023] In addition, in the description below, for reasons of conciseness and clarity, the terminology associated with the Ultra Mobile Broadband (UMB) technology, as promulgated under the 2nd 3rd Generation Partnership Project (3GPP2) by the Association of Telecommunication Industries (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.

Petition 870190122055, of 11/22/2019, p. 12/43

8/25

[0024] Reference is now directed to the Figure

3, which schematically shows the relationships of the various communication entities arranged according to an exemplary embodiment of the invention.

[0025] In Figure 3, the total communication system is generally represented by the reference number 30. In the communication system 30, there is an Access Gateway (AGW) 32 connected to a plurality of evolved Base Stations (eBSs), two of which are shown 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 shown with only one eBS in the Figure

3. In the modality shown in Figure 3, eBS 34 provides wireless access to users within a coverage area

35. In the same way, eBS 36 provides wireless access within a coverage area 37. 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.

[0026] There is a Session Reference Network Controller (SRNC) 40 connected to AGW 32. The SRNC 40 serves several functions. For example, SRNC 40 provides authentication function to an Access Terminal (AT), such as the AT 44 shown in Figure 3. In addition, the SRNC 40 stores the AT 44 communication session for any new eBS that is prepared to communicate with the AT 44. The SRNC 40

Petition 870190122055, of 11/22/2019, p. 13/43

9/25 also controls alert procedures in the idle state in general.

[0027] Suppose that 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 an Attachment Point of Data (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 gateway. 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 gateway 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 gateway entity.

[0028] In a DAP allocation provision initiated by the AN, 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, it can start the DAP assignment process. So, if eBS 34 is the current FLSE, eBS 34 sends a

Petition 870190122055, of 11/22/2019, p. 14/43

10/25 AGW 32 registration request message. Then, AGW 32 performs a link update with eBS 34 according to the procedures presented under the Mobile IP Proxy Protocol (PMIP) published by the Internet Engineering Task Force (IETF).

[0029] Suppose that the communication system 30 is a synchronous system. In other words, 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 registration protocol can be established, such as 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.

[0030] 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 overlap zone 46 of coverage areas 35 and 37 at this junction. EBS 34, detecting the presence of AT 44, sends a registration request message at time t1 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 come first serve” rule set out in the

Petition 870190122055, of 11/22/2019, p. 15/43

11/25 system 30. According to this rule, eBS 34, being the first to send the registration request message, intends to be the DAP for AT 44.

[0031] With AT 44 in coverage overlap zone 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 Figure 4. Here, t2 is later in time than t1.

[0032] For some reasons, the message sent via message flow 50 arrives at AGW 32 earlier than that of message flow 48. More specifically, the message sent by eBS 36 arrives at AGW 32 at time t3, while the message correspondent 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.

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

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

Petition 870190122055, of 11/22/2019, p. 16/43

12/25

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

[0036] AGW 32 then sends a registration success response to eBS 34 at time t7 and fetches eBS 34 at time t8. EBS 34 then takes on the new role as DAP.

[0037] 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 error recovery attempt certainly requires additional time and resources with additional complexities.

[0038] It should also be noted that although the 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

Petition 870190122055, of 11/22/2019, p. 17/43

13/25 of the individual entities. The time references of the entities can have a large amount of displacement, each one. Consequently, the problem as mentioned above can still occur.

[0039] Figure 5 is a diagram of message flows showing a DAP handoff scheme assisted by the AT or a DAP handoff scheme initiated by the AT according to an exemplary embodiment of the invention. In the following, the terms “assisted by the TA” and “initiated by the TA” are used interchangeably.

[0040] 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, the eBS 34 is the current DAP for AT 44.

[0041] 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.

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

[0043] First, in an asynchronous system, such as the system shown previously in Figure 4, running conditions can occur as explained

Petition 870190122055, of 11/22/2019, p. 18/43

14/25 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.

[0044] Second, the DAP is the data anchor for the AGW TA in a RAN. It is preferable to have the DAP in the RS of the TA. As a result, 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 communication session. The change can be transmitted from AGW to 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.

[0045] 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.

[0046] 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.

[0047] 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 the AT 44.

Petition 870190122055, of 11/22/2019, p. 19/43

15/25

[0048] In a TA assisted handoff as described in this modality, the TA 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 often, because frequent and unnecessary handoffs can result in inefficient consumption of communication resources. Equally just as important, the TA can assess the link conditions of communication with various eBSs to decide whether a DAP handoff is justified. It would certainly not be a good move to the TA to do the handoff from DAP to the FLSE, since the TA is having unfavorable communication conditions communicating with the FLSE.

[0049] 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 starts with the AT 44 by 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 the number of

Petition 870190122055, of 11/22/2019, p. 20/43

16/25 reference 52, as shown in Figure 5. Target DAP eBS 36 can accept or reject the request, for example, depending on the level of congestion of the ongoing calls that pass through eBS 36.

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

[0051] 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 the AGW 32 and AT 44 via target DAP eBS 36. In the PMIP Register Reply message, a data tunnel lifetime parameter can be included. The parameter of useful life is to prevent the scenario according to which, when the AT 44 enters standby, the tunnel is still maintained, resulting in unproductive use of 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.

[0052] After the link update process is completed, the target DAP eBS 36 responds to the AT 44 with a DAPAssignment message, as shown in the message flow path 58 shown in Figure 5. The DAPAssignment message informs the AT 44 whether the DAP handoff is successful. In addition, the DAPAssignment message can

Petition 870190122055, of 11/22/2019, p. 21/43

17/25 include, among other things, a time stamp issued by AGW 32 for successful PMIP registration with target DAP eBS 36 and also the remaining lifetime of the link data tunnel. If the time stamp of the DAPAssignment message is set to a value lower than the corresponding time stamp of the previous DAPAssignment message processed by the AT 44, the AT 44 can 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.

[0053] On the other hand, if the time stamp in the DAPAssignment message via flow path 58 has the most recent value, that is, a higher value than any of the corresponding time stamps of the DAPAssignment messages previously processed by the AT 44 , the AT 44 can mark the data path route to the 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 carry out DAP handoffs too often, for example, by slightly changing link conditions. Frequent and unnecessary DAP handoffs can affect the load on the AGW 32, for example.

[0054] Next, the target DAP eBS 36 notifies all eBSs in the RS of AT 44 as assuming the role of DAP for AT 44. The notification is presented under the

Petition 870190122055, of 11/22/2019, p. 22/43

18/25 form of an Internet Protocol Tunnel Notification (IPT) message to all eBSs and any related entities in the RS of AT 44. One of them is shown in message path 60 sent by target eBS 36 to the Network Controller Session Reference (SNRC) 40. The IPT Notification message sent via route 60 serves several purposes. First, target DAP eBS 36 informs 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 time stamp that the target DAP eBS 36 previously used to update the data attachment link with AGW 32.

[0055] For SRNC 40 to confirm that eBS is the current DAP, SRNC 40 sends an IPT Notification Confirmation, as shown by the message flow path 62 in Figure 5.

[0056] In addition to notifying other eBSs as assuming the role of DAP, as mentioned above, in particular, target eBS 36 informs source DAP 34 to obtain the role as the current DAP when sending an IPT Notification message to eBS of Source DAP 34, as shown by the message flow path 66 in Figure 5. The IPT Notification message informs source DAP eBS 34 that target eBS 36 is the current DAP eBS. Again, the IPT Notification message can include the message sequence number and the time stamp that the target DAP eBS 36 used to update the data attachment link with AGW 32.

Petition 870190122055, of 11/22/2019, p. 23/43

19/25

[0057] For the source DAP eBS 34 to confirm that eBS 36 is the current DAP, it is necessary that the source DAP eBS 34 send an IPT Notification Confirmation message, as presented by the message flow path 68 on Figure 5. Optionally, the message Confirmation of IPT Notification can indicate whether the sender of which message is the current FLSE of AT 44. After receiving the message Confirmation of IPT Notification, 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 .

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

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

[0060] 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.

[0061] 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.

Petition 870190122055, of 11/22/2019, p. 24/43

20/25

[0062] There may be numerous occasions when communication 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 mitigate congestion, any of the infrastructure entities, such as eBS 34 or eBS 36, can make a request to AT 44 to start the handoff process.

[0063] As another example, suppose 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 whether the new eBS is the FLSE for TA. According to this scenario, any of the infrastructure or network entities mentioned above can also request that the AT 44 start the DAP handoff process.

[0064] 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 do 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.

[0065] AT 44 can accept or refuse such a request. If AT 44 refuses the request, AT 44 sends a refusal message to eBS 36. Alternatively, the

Petition 870190122055, of 11/22/2019, p. 25/43

21/25

AT 44 can refuse the request by allowing a pre-set timer to expire without responding to eBS 36.

[0066] In determining whether to accept or refuse the request, as in the previous modality, numerous factors 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 eBS 34 DAP handoff request for eBS 36. 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.

[0067] 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).

[0068] 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.

[0069] 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, target eBS 36 must not send any DAPAssignment messages, unless a DAPMoveRequest message, such as

Petition 870190122055, of 11/22/2019, p. 26/43

22/25 as the message sent via the message flow path 70, is received by eBS 36.

[0070] 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.

[0071] Next, the DAP handoff process is substantially similar to the handoff process described in the previous modality. For clarity and conciseness, the remaining steps shown in Figure 7 are not elaborated on in more detail.

[0072] 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.

[0073] The apparatus 90 comprises a central data bus 92 that 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.

[0074] If the device 90 is part of a wireless device, the reception and transmission 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

Petition 870190122055, of 11/22/2019, p. 27/43

23/25 stores data from data bus 92 before sending it to device 90. The CPU / controller 94 performs the data management function of data bus 92 and also the function of general data processing, including content execution instruction manual of memory unit 100.

[0075] 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.

[0076] The memory unit 100 includes a set of modules and / or instructions generally represented by the reference number 102. In this embodiment, the modules / instructions include, among other things, a handoff function 108. The handoff function 108 includes instructions or computer code to perform the process steps as shown and described in 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.

Petition 870190122055, of 11/22/2019, p. 28/43

24/25

[0077] In this mode, the memory unit

100 it 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.

[0078] It should also be noted that the inventive processes as described can also be encoded as computer-readable instructions carried in any computer-readable medium 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 the CPU / controller 94 shown and described in the image in Figure 9, for execution. Such a medium may be of the storage type and may 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 may also be of the type transmission line and may include a coaxial cable, a copper wire, an optical cable, and an air interface carrying acoustic, electromagnetic or optical waves

Petition 870190122055, of 11/22/2019, p. 29/43

25/25 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.

[0079] 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.