Patent Description:
Handover process is of major importance within any cellular telecommunications network. It is necessary to ensure that the handover is performed reliably and without disruption to any ongoing data transfer or calls. In particular, the handover is an inevitable process in <NUM> cellular networks, since the <NUM> cellular network is coupled with Wi-Fi™ in most of the areas and is expected to work hand-in-hand with the mobile network. Therefore, a frequent handover between Wi-Fi™ and the mobile network may be expected in <NUM> networks. Also, pre-<NUM> cellular networks foresee ubiquitous ultra-broadband with faster seamless handover to Wi-Fi™ backhaul.

Moreover, the transmission control protocol/user datagram protocol (TCP/UDP) is network address sensitive and any change in the internet protocol (IP) or the route might create disconnection from a previous session. On the other hand, hyper text transfer protocol (HTTP) may use "range request" concept to recover the data, because of which the "download" recovers after every Wi-Fi™-to-mobile network handover. However, the "download" process is not the widely used option for the users. Consequently, other widely used activities such as gaming, chat and messaging use either encrypted TCP/UDP or their own application level protocol. This results in connectivity disconnections during network handover.

One of the existing handover methods provided performing handover at application layer, independent of the path (except in transport layer security TLS REUSE) and requires no hardware changes. However, this method cannot be applied on any plain connection, that is, in real-time data transmission scenarios such as gaming. Also, handover at the application layer may make the handover application specific and may not have an impact on the entire operation of the user equipment (UE).

Another existing method of handover suggests performing handover on the transport layer and uses multipath transmission control protocol (MPTCP), independent of the application and the data path. However, this method requires server-side changes. That is, the server must support MPTCP. But, most of the servers may not support the MPTCP. Also, these methods may be best suited only for selected protocols like TCP. Other protocols such as UDP, stream control transmission protocol (STCP) and internet control message protocol (ICMP) may not be supported by the handover in the transport layer.

On the other hand, performing handover at the lower layers may be more efficient than above methods. For example, if the handover is performed on layer <NUM> (i.e., the network layer), the transport layer and the application layer may be enriched with seamless experience. Even then, handover at the lower layers may not support heterogeneous handover. That is, the heterogeneous handover may be possible only if long term evolution (LTE) and Wi-Fi™ have same path deployed by the same network operator. Also, handover on the lower layers may require hardware level changes.

Thus, there is need for an efficient and reliable network handover method.

The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

<CIT> discloses a method and apparatus for transmitting data from a source device to a destination device in a communications system. <CIT> discloses a system, method and computer program product for implementing network connection failover during application service interruption. <CIT> discloses a method for communication by a device using a multipath transmission control protocol (MPTCP) connection. <CIT> discloses that a client application running on a WTRU is configured to communicate data traffic over a TCP session with an MPTCP stack running on the WTRU. <NPL>, discloses that several existing IP mobility solutions use invasive approaches, when adjustments in legacy protocols from the TCP/IP stack are necessary, or rely on specific network infrastructures. <NPL>, discloses that the dynamically changing set of multimedia capable devices in the vicinity of a user can be leveraged to create new ways of experiencing multimedia applications through migrating parts of running multimedia applications to the most suited devices.

Disclosed herein is a method for handling a data session in a user equipment (UE) as recited in claim <NUM>.

Further, disclosed herein is a network handover system for handling a data session in a user equipment (UE). The network handover system comprises a layer <NUM> network handover (NH4) module configured to comprise a connection tracker module and a NH4 migrator module. The connection tracker module configured to initiate a data session of at least one application from a plurality of applications with a first communication interface using a first socket of the UE having a first socket file descriptor (SOCKFD) for the data session. The network handover system comprises a switchboard module configured to detect a deterioration in a network connection of the first communication interface and identify a second communication interface. The layer <NUM> NH4 module configured to establish a second socket having a second SOCKFD associated with the second communication interface, and the NH4 Migrator module configured to migrate the data session from the first communication interface to the second communication interface by mapping the first SOCKFD corresponding to the first socket to the second SOCKFD corresponding to the second socket.

Advantages of the embodiments of the present disclosure are illustrated herein.

In an embodiment, the method of present disclosure effectively handles an ongoing data session in a user equipment (UE) by seamlessly switching between available networks.

In an embodiment, the method of present disclosure dynamically detects a deteriorating condition in the network and automatically switches to a second network, thereby eliminating chances of disconnection and/or network drop.

In an embodiment, the method of present disclosure provides an optimized network management technique, which minimizes latency on Wi-Fi™ networks and reduces unnecessary data consumption on the long term evolution (LTE) network.

Evidently, the present disclosure has a practical application and provides a technically advanced solution to the technical problems associated with existing techniques for cellular network handover. The aforesaid technical advancements and practical applications of the disclosed method may be attributed to the aspect of dynamically detecting the deteriorating network condition and identifying and mapping a second communication interface in place of the deteriorated communication interface for continuing a data session.

In light of the technical advancements provided by the disclosed method and system, the claimed steps, as discussed above, are not routine, conventional, or well-known aspects in the art, as the claimed steps provide the aforesaid solutions to the technical problems existing in the conventional technologies. Further, the claimed steps clearly bring an improvement in the functioning of the UEs itself, as the claimed steps provide a technical solution to a technical problem.

<FIG>, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the claims.

It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether such computer or processor is explicitly shown.

While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the specific forms disclosed.

The terms "comprises," "comprising," "includes," or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by "comprises. a" does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.

The terms "an embodiment," "embodiment. " "embodiments," "the embodiment," "the embodiments," "one or more embodiments," "some embodiments," and "one embodiment" mean "one or more (but not all) embodiments of the disclosure" unless expressly specified otherwise.

The terms "including," "comprising," "having" and variations thereof mean "including but not limited to," unless expressly specified otherwise. The enumerated listing of items does not imply that any or all the items are mutually exclusive, unless expressly specified otherwise.

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the disclosure.

When a single device or article is described herein, it will be clear that more than one device/article (whether the device/article cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether the device and article cooperate), it will be clear that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the disclosure need not include the device itself.

Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the disclosed subject matter. It is therefore intended that the scope of the claims be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present disclosure are intended to be illustrative, but not limiting, of the scope of the claims.

The present disclosure relates to a method and a network handover system for handling a data session in a user equipment (UE). Initially, the network handover system initiates a data session of at least one application from a plurality of applications with a first communication interface using a first socket of the UE having a first socket file descriptor (SOCKFD) for the data session. Further, the network handover system detects a deterioration in a network connection of the first communication interface. In an embodiment, when the deterioration in the network connection is detected, the network handover system identifies a second communication interface. Subsequently, the network handover system establishes a second socket having a second SOCKFD associated with the second communication interface and migrates the data session from the first communication interface to the second communication interface by mapping the first SOCKFD corresponding to the first socket to the second SOCKFD corresponding to the second socket Thereafter, the data session is continued and/or carried out on the second network communication interface using the second socket, thereby handling the data session on the UE.

In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the claims. The following description is, therefore, not to be taken in a limiting sense.

<FIG> illustrate environment for handling a data session in a user equipment (UE) <NUM> in accordance with some embodiments of the present disclosure.

As shown in <FIG>, the environment <NUM> may include a User Equipment (UE) <NUM> and a destination server <NUM>. In an embodiment, the UE <NUM> may be a computing device such as, without limitation, a smartphone, a laptop, a desktop computer or a similar computing device. In an embodiment, the UE <NUM> may be configured with the network handover system <NUM> for ensuring a seamless network connectivity to the UE <NUM>. Further, the UE <NUM> may comprise a first socket <NUM> and a second socket <NUM>, which are respectively interface with a first communication interface <NUM> and a second communication interface. The UE <NUM> may connect to the destination server <NUM> using at least one of the first socket <NUM> and the first communication interface <NUM> or the second socket <NUM> and the second communication interface.

In an embodiment, the first socket <NUM> and the second socket <NUM> are the network sockets that enable the UE <NUM> to connect to an external entity, such as the destination server <NUM>, via a selected communication network. As an example, the first communication interface <NUM> may be Wi-Fi™. Similarly, the second communication interface <NUM> may be long term evolution (LTE) cellular network interface. As another example, the first communication interface <NUM> may be LTE cellular network interface and the second communication interface <NUM> may be Wi-Fi™. The first communication interface <NUM> and the second communication interface <NUM> may be different communication networks. The first communication network <NUM> and the second communication network <NUM> may be at least one of <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or a non-3GPP network.

In an embodiment, the network handover system <NUM> may be configured for effectively handling a data session <NUM> in the UE <NUM>. As an example, the data session <NUM> may include, without limiting to, a call service, a chat/messaging service, a live content streaming or an application running in the UE <NUM>. Suppose the data session <NUM> is being carried out between the UE <NUM> and the destination server <NUM>. Further, suppose that the default network interface for establishing the data session <NUM> is the first communication interface <NUM> accessed via the first socket <NUM> of the UE <NUM>, as shown in <FIG>. Here, when the data session <NUM> is established through the first communication interface <NUM>, the second socket <NUM> and the second communication interface <NUM> may be maintained in an "inactive" state. In other words, the second socket <NUM> and the second communication interface <NUM> are operated as a fallback configuration to the first socket and the first communication interface.

As shown in <FIG>, in an embodiment, the network handover system <NUM> may continuously monitor the data session <NUM> through the first communication interface <NUM> connecting the UE <NUM> and the destination server <NUM> for detecting any abnormal and/or deteriorating network condition <NUM> in the first communication interface <NUM>.

In an embodiment, when a deteriorating network condition <NUM> is detected in the first communication interface <NUM>, the network handover system <NUM> may instantly map configuration details of the first communication interface <NUM> to the second network communication interface <NUM> to seamlessly switch/handover the data session <NUM> from the first communication interface <NUM> to the second communication interface <NUM>. In an embodiment, mapping the configuration details may include mapping a first socket File Descriptor (SOCKFD) corresponding to the first socket <NUM> to a second SOCKFD corresponding to the second socket <NUM>. Additionally, information stored in a socket buffer associated with the first communication interface <NUM> may be replicated on the second communication interface <NUM> to avoid any interruption to the data session <NUM>.

In an embodiment, handover of the data session <NUM> between the first communication interface <NUM> and the second communication interface <NUM> may be performed on an abstract network communication layer of the data session using communication protocols such as, without limiting to, user datagram protocol (UDP), transmission control protocol (TCP) and cross-layer quick UDP internet connections (C-QUIC) protocol. Handing over the data session <NUM> using the above communication protocols is explained in detail in the following sections of the instant disclosure.

<FIG> illustrate a block diagram of a network handover system 103disclosed herein. Hereinafter the detailed block diagram of a network handover system <NUM> of the present disclosure with reference to <FIG>.

In an embodiment, the network handover system <NUM> may include an I/O interface <NUM>, a processor <NUM>, a memory <NUM>, a classifier module <NUM>, an event blocker module <NUM>, a layer <NUM> network handover (NH4) module <NUM> and a switchboard module <NUM>.

In an embodiment, the I/O interface <NUM> may include one or more input/output interfaces of the network handover system <NUM> that enable the network handover system <NUM> to interface with the first socket <NUM> and the second socket <NUM> and also monitor the data session <NUM>. The processor <NUM> may be configured to perform each function of the network handover system <NUM> in accordance with various methods and embodiments of the present disclosure. The memory <NUM> may be communicatively coupled to the processor <NUM> and may store data and modules required for performing various operations of the processor <NUM>. In an implementation, the network handover system <NUM> may have dedicated I/O interface <NUM>, processor <NUM> and memory <NUM>. In an alternative implementation, the network handover system <NUM> may use the I/O interface, processor/control unit and memory/storage space of the UE <NUM> in which the network handover system <NUM> is configured.

In an embodiment, the classifier module <NUM> may be configured for classifying various applications running on the UE <NUM> into different classes/categories based on runtime requirements and/or network connectivity information associated with the applications. In an embodiment, the classifier module <NUM> may comprise two sub-modules, namely, a whitelist classifier <NUM> and a protocol classifier <NUM>.

In an embodiment, the whitelist classifier <NUM> may be configured for classifying applications into a "whitelist" and a "blacklist". In other words, the whitelist classifier <NUM> helps in deciding whether an application needs to be controlled or not. In an embodiment, when an application is blacklisted, the application may be allowed to use TCP or UDP. That is, the blacklisted applications may not use the multipath TCP (MPTCP) since kernel of the UE <NUM> does not support MPTCP as a default configuration. In an embodiment, after classifying the applications into "whitelist" and "blacklist", the whitelist classifier <NUM> may communicate the classified list of applications to the NH4 module (layer <NUM> NH4 module) <NUM>. The classifier module <NUM> classifies a plurality of applications running on the UE <NUM> as at least one of handover-sensitive applications (i.e., whitelist applications) and handover insensitive applications (i.e., blacklist applications). The classification of the plurality applications running on the UE <NUM> as at least one of handover-sensitive applications and handover insensitive applications is done based on at least one of nature of application, latency requirement and communication protocol used. The examples for handover sensitive applications may be, but not limited to, gaming applications, latency sensitive applications, UDP-based applications, vehicle-to-everything (V2X) related applications and applications having real-time updates. The examples handover insensitive application may be, but not limited to, messaging application, browsing applications, etc..

In an embodiment, the protocol classifier <NUM> is configured for checking or determining the communication protocol requirements associated with each of the whitelisted applications and may be configured to forward or notify each of the whitelisted applications to the NH4 module <NUM>. As an example, if a whitelisted application is determined to operate over UDP, a data session for the whitelisted application may be established over 0UDP. Similarly, if the whitelisted application is determined to operate over TCP or quick UDP internet connections (QUIC), then the data session for the whitelisted application may be established over seamless TCP (S-TCP) or cross-layer QUIC (CQUIC) respectively. In an embodiment, the protocols 0UDP, S-TCP and CQUIC may be configured on the NH4 module <NUM> of the network handover system <NUM>. In brief, the protocol classifier <NUM> of the classifier module <NUM> determines a communication protocol corresponding to the handover-sensitive applications and may notify the determined communication protocol to the NH4 module. The communication protocol may be at least one of UDP, TCP and C-QUIC protocol.

In an embodiment, the event blocker module <NUM> may be configured for controlling notifications from the system framework of the UE <NUM> to the whitelisted applications. In other words, the event blocker module <NUM> limits the number of system-generated notifications when the whitelisted application is being actively run on the UE <NUM>. By default, a connectivity manager (CM) in the UE <NUM> android framework may indicate the change in the connectivity (i.e., activities such as connecting, disconnecting or modification) to the applications via broadcast mechanism. However, if an application is looking for this connectivity broadcast event, the application may decide to provide pop-up or even try to reconnect with the modified interface. Further, if the applications, which are whitelisted, are reacting to this event, then, irrespective of the handover mechanism and the deployed network abstractions, the user might be notified with the network changes, which affects the user experience. Therefore, the event blocker module <NUM> is configured on top of the CM to restrict the broadcast of events to the whitelisted applications. This, in turn, helps the network handover system <NUM> to work smoothly and abstract only required events to the user. The event blocker module <NUM> may perform at least one of block sending of at least one notification from a plurality of notifications to a connection tracker module <NUM> regarding the migration of the data session if the data session is for the handover sensitive application, and sending of at least one notification from a plurality of notifications to the connection tracker module <NUM> regarding the migration of the data session if the data session is for the handover insensitive application. The at least one notification may indicate at least one of a disconnection with the first communication interface <NUM>, new connection establishment with the second communication interface <NUM>, socket change and signal strength deterioration. The at least of one notification of a plurality of notifications may be sent by one of the network, the first communication interface <NUM>, the second communication interface <NUM>, or lower layers of the UE <NUM>. The lower layers of the UE <NUM> may comprise service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), radio link control (RLC), medium access control (MAC), and physical layer (PHY).

In an embodiment, the switchboard module <NUM> is configured for detecting a deterioration in a network connection of the first communication interface <NUM> and for identifying a second communication interface <NUM>. The detection of the deterioration in the network connection may be based on at least one of low data throughput, low data rate, lost signal, frame loss, high jitter, and broken connectivity between the UE <NUM> and the destination server <NUM>. Here, the term "jitter" may refer to variance in the network connection i.e., pit and fall in network connection. For example, average speed may be <NUM> Mbps but suppose the speed is <NUM> Mbps for long time in between during the network connection, then it is considered to be high jitter network.

In an embodiment, the NH4 module <NUM> may be the core module of the network handover system <NUM>. The NH4 module <NUM> hosts the communication protocols like 0UDP, S-TCP and the CQUIC. Further, the NH4 module <NUM> uses one of the above communication protocols for establishing a data session <NUM> for the whitelisted application based on the application's preference on the communication protocol. Additionally, the NH4 module <NUM> may be configured with other network frameworks such as Netfiler® and Iptables® and program libraries such as "C" standard library (LIBC). In an embodiment, the NH4 module <NUM> may comprise a communication tracker module <NUM> and a migrator module <NUM>.

In an embodiment, 0UDP protocol ensures that the stateless properties of the UDP are leveraged while establishing a data session <NUM> for the whitelisted application. Similarly, S-TCP ensures seamless TCP handover. S-TCP may make use of an abstraction layer over the user application layer during handover of the data session. The abstraction network communication layer may be a software layer that logically resides between application layer and transport layer of the communication interface. The abstraction layer may manage the establishment of connection and data activities (i.e., addition/deletion/modification) of applications (APPs). The abstraction network communication layer may, also, be referred as an abstraction layer. Further, CQUIC makes use of a unique connection ID (CID) to uniquely identify the connection. In the case of CQUIC, any changes in the internet protocol (IP) number does not affect QUIC configuration. That is, CQUIC serves as a cross layer technique to handover the QUIC improving the latency. The connection tracker module <NUM> of the NH4 module <NUM> initiates a data session of at least one application from a plurality of applications with the first communication interface <NUM> using the first socket <NUM> of the UE <NUM> having a first socket file descriptor (SOCKFD) for the data session. When the switchboard module <NUM> identifies the second communication interface <NUM> due to detection of deterioration in a network connection of the first communication interface <NUM>, the NH4 module <NUM> establishes the second socket <NUM> having a second SOCKFD associated with the second communication interface <NUM>. In the subsequent step, the migrator module <NUM> of the NH4 module <NUM> migrates the data session from the first communication interface <NUM> to the second communication interface <NUM> by mapping the first SOCKFD corresponding to the first socket <NUM> to the second SOCKFD corresponding to the second socket <NUM>. The mapping of the first SOCKFD of the first socket <NUM> to the second SOCKFD of the second socket <NUM> may be on an abstract network communication layer for the data session. The mapping of the first SOCKFD corresponding to the first socket <NUM> to the second SOCKFD corresponding to the second socket <NUM> ise based on the communication protocol determined by the classifier module <NUM> corresponding to the handover-sensitive applications. One or more applications, running on the UE <NUM> and using the data session, may not be aware of the migration of the data session. The migrator module <NUM> of the NH4 module <NUM> may migrate the data session back to the first communication interface <NUM> upon detecting a deterioration in a network connection in the second communication interface <NUM>.

In detail, the initiation of a data session of at least one application from a plurality of applications by the NH4 module <NUM> may include following steps. The connection tracker module <NUM> may receive a socket establishment request from the at least one application from among a plurality of handover-sensitive application on the UE <NUM>. In the next step, the connection tracker module <NUM> may request a network by the first communication interface <NUM> for a plurality of network resources based on the received socket establishment request. In subsequent step, the NH4 module <NUM> may establish a socket having the first SOCKFD on receiving the requested network resources. The connection tracker module <NUM> may initiate the data session on the requested network resources by transmitting a plurality of data packets via the first socket <NUM> having a first SOCKFD on the first communication interface <NUM> to the network.

In detail, the migration of the data session from the first communication interface <NUM> to the second communication interface <NUM> by mapping the first SOCKFD corresponding to the first socket <NUM> to the second SOCKFD corresponding to the second socket <NUM> by the NH4 module <NUM> may include following steps. The connection tracker module <NUM> may detect the first socket <NUM> being used by a handover-sensitive application and may migrate the first socket <NUM> from the first communication interface <NUM> to the second communication interface <NUM>. The NH4 module <NUM> may detect the data session is for one of the handover-sensitive application and the handover insensitive application.

In an embodiment, when the migration of the data session is using UDP, the NH4 module <NUM> may receive a notification from the protocol classifier <NUM> indicating communication protocol to be UDP. In the next step, the NH4 module <NUM> may determine application data pending for transmission on the first communication interface <NUM> and may fetch the application data from a socket buffer associated with the first socket <NUM> of the UE <NUM> and clone header information of the application data. In subsequent step, the NH4 module <NUM> may map the cloned header information to the second socket <NUM> of the UE <NUM> for continuing the data session through the second communication interface <NUM>.

In an embodiment, when the migration of the data session is using TCP, the NH4 module <NUM> may receive a notification from the protocol classifier <NUM> indicating communication protocol to be TCP. In the next step, the NH4 module <NUM> may create an abstract network communication layer corresponding to the first socket <NUM> of the UE <NUM>. In subsequent step, the NH4 module <NUM> may map SOCKFD associated with the first socket <NUM> to a pseudo socket corresponding to the abstract network communication layer and may continue the data session through the pseudo socket file descriptor.

In an embodiment, the NH4 module <NUM> may be configured for managing network services with the network sockets and the communication interfaces of the UE <NUM>. In an embodiment, the NH4 module <NUM> may include network manager frameworks such as a network connectivity manager, a telephony service, a Wi-Fi™ manager and a radio interface layer.

In an embodiment, the network handover system <NUM> may be set-up in communication with the kernel of the UE <NUM> while managing the data session on the UE <NUM>. In an embodiment, in addition to having control over all the hardware and software components of the UE <NUM>, the kernel space <NUM> of the UE <NUM> may allow the network handover system <NUM> to access the communication protocols like TCP, TCP/IP stack <NUM> and the UDP <NUM> while handing over data sessions for the whitelisted applications.

In an embodiment, the handover operation performed using the network handover system <NUM> may be different from the handover on MPTCP in the following ways. In an embodiment, network handover system <NUM> is a client-only solution. That is, the network handover system does not require any server-side modifications to initiate the handover. As a result, the network handover system <NUM> only requires simpler changes in the user-space only. Whereas handover over MPTCP requires kernel-level changes and hence, takes a lot of time. In other words, the provided network handover is a light-weight approach when compared to that of the MPTCP. Moreover, the network handover system <NUM> not only enhances TCP, but also enhances UDP and other protocols like QUIC. Also, the provided handover introduces a transient layer, where LTE is brought up and/or engaged only when the Wi-Fi™ is predicted to be weak. This saves power consumption on the UE <NUM>. On the other hand, in the existing implementation of the MPTCP, both LTE and Wi-Fi™ are engaged and running always.

In an embodiment, the network handover system <NUM> also uses the event blocker module <NUM> to effectively block the events from connectivity manager to the application. On the other hand, MPTCP lacks this framework component, and may react to connectivity events while the application layer is still looking for a handover. Thus, the provided network handover system <NUM> is more effective and optimized than the handover using MPTCP.

<FIG> illustrates a flowchart of a method for a network handover using user datagram protocol (UDP) in accordance with some embodiments of the present disclosure.

In an embodiment, step <NUM> indicates start of a data session <NUM> between the UE <NUM> and the destination server <NUM> through a first channel consisting the first socket <NUM> and the first communication interface <NUM>. During the data session <NUM>, the network handover system <NUM> continuously monitors the data session <NUM> and wait for a "handover signal", as shown in step <NUM>. The "handover signal" may be generated when the UE <NUM> experiences a deteriorating network condition <NUM> during the data session <NUM>. When a "handover signal" is received, the network handover system <NUM>, at step <NUM>, checks whether there are any data packets pending for transmission in the data session <NUM>. For example, if handover signal received, the 0UDP checks for previous data queued. Generally, the handover may happen when: a) the application has sent the packet out and b) application has sent the packets to the kernel, but the kernel has not placed those packets to the external network. So, at step <NUM>, the network handover system <NUM> checks whether the kernel still holds some packets to be sent to the external server.

In an embodiment, if there are pending data packets, then, at step <NUM>, the network handover system <NUM> fetches the pending data packets from a socket buffer associated with the first socket <NUM> and copies them on to the socket buffer or a memory space associated with a second socket <NUM>. However, if there are no pending packets, then the network handover system <NUM> may simply create a UDP socket buffer with "<NUM>" Bytes to be used for the rest of the data session, as indicated in step <NUM>. Thereafter, at step <NUM>, the UDP header may be copied and rehashed for using in the re-established data session. Once the UDP header and the socket buffer are ready, the network handover system <NUM>, at step <NUM>, checks whether the destination (i.e., the destination server <NUM>) is still reachable for completing the data session.

Sometimes, due to firewall, the destination may not be reachable. So, the network handover system <NUM> checks whether the destination is still reachable for completing the data session. For example, LTE packet may reach a server A. The UDP header changes and checks if a packet may reach the server A when the network handover system <NUM> move from LTE to Wi-Fi™.

If the destination is reachable, the network handover system <NUM> may map the file descriptor of the application to a new file descriptor corresponding to the UDP socket and continue the data session, as indicated in step <NUM>. However, if the destination is not reachable, then the handover process may be terminated, as indicated in step <NUM>. The aforesaid process is repeated each time the UE <NUM> experiences a deteriorating network condition <NUM> during a data session <NUM>.

<FIG> illustrate a network handover using user datagram protocol (UDP) in accordance with some embodiments of the present disclosure.

<FIG> illustrates a data session <NUM> between the UE <NUM> and the destination server <NUM> using the first socket "<NUM>" and the first communication interface <NUM>. Here, the first communication interface <NUM> may be Wi-Fi™, such that the UE <NUM> connects to the destination server <NUM> over Wi-Fi™. At this instance, the second socket "<NUM>" and the second network communication interface <NUM> may be configured and available but placed in a "wait" state. That is, the second socket "<NUM>" and the second network communication interface <NUM> takeover the data session only when there is a deteriorating network condition <NUM> on the first communication interface <NUM>.

<FIG> illustrates the scenario in which there is a deteriorating network condition <NUM> on first communication interface <NUM> and the data session between the UE <NUM> and the destination server <NUM> has been interrupted. As an example, the deteriorating network condition <NUM> may include without limiting to, low data throughput, low data rate, lost signal or broken connectivity between the UE <NUM> and the destination server <NUM>. Further, as indicated in <FIG>, the deteriorating network condition <NUM> may arise at the first socket "<NUM>," an interface between the first socket "<NUM>" and the first communication interface <NUM> or on the communication channel connecting to the destination server <NUM>.

In an embodiment, the destination server <NUM> may attempt to push one or more data packets to the UE <NUM> even in the deteriorated network condition, until the destination server <NUM> becomes aware of the deteriorating network condition <NUM> on the first communication interface <NUM>. At this point, the network handover system <NUM> detects the deteriorating network condition <NUM> and transmits a <NUM>-UDP handover message to the destination server <NUM>, indicating the destination server <NUM> that a deteriorating network condition <NUM> has occurred on the first communication interface <NUM>. Simultaneously, the network handover system <NUM> may map and/or replicate the pending packets and socket buffer information related to the first communication interface <NUM> on the second socket "<NUM>" and the second communication interface <NUM> and handovers the data session to the second communication interface <NUM>. By doing so, the application running on the UE <NUM> is unaware of the socket migrations. Thereafter, the data session <NUM> is re-established over the UDP-driven second communication interface <NUM> and the second socket "<NUM>. " Here, the destination server <NUM> continues to participate in the data session <NUM> as if the destination server is communicating with the UE <NUM> over the first communication interface <NUM>.

That is, the network handover system <NUM> seamlessly hands over the data session from the first communication interface <NUM> to the second communication interface <NUM>. Here, it may be noted that <NUM>-UDP is a client-only solution that detects the need for handover and intelligently handovers the server connection without any changes in the server. Suppose the application running on the UE <NUM> opens a file descriptor "X. " During handover, "X" may be first mapped to a default file descriptor, say "Y. " Subsequently, when a new connection is opened using the second communication interface <NUM>, if all the requisite conditions are met, a new file descriptor "Z" may be created and mapped to the original application descriptor "X. " That is, X -> Z. Here, the original file descriptor "X" is not aware of "Y" and "Z. " Hence, the handover may be seamless.

In an embodiment, the data session may be handed over back to the first communication interface <NUM> upon determining a deteriorating network condition <NUM> on the second communication interface <NUM>. That is, the network handover system <NUM> may dynamically decide which of the available communication interfaces (i.e., either first or second) is best suited for carrying out the data session.

<FIG> illustrate a network handover using transmission control protocol (TCP) in accordance with some embodiments of the present disclosure.

In an embodiment, the S-TCP protocol may create an abstraction layer for carrying out the handover. Further, during the handover, the file descriptor of the application may be mapped to the abstraction layer. The abstraction layer may be always up and running, and the application would be unaware of the connectivity changes (i.e., the handover) and failures in the communication channel. In an embodiment, the S-TCP may open multiple sockets and map file descriptors of one of the sockets to the file descriptor of the application. The socket mapping may be dynamic and changed anytime during the data session as well. Essentially, the S-TCP may identify the best interface based on the network parameters and use the best interface for the handover at any point of time. This ensures that the application is enriched with seamless connectivity experience even during weak network conditions. The network parameters may include, but not limited to, received signal strength indicator (RSSI), reference signal received power/quality (RSRP/RSPQ), signal to interference noise ratio (SINR), current data rate, peak data rate, current latency, probability of packet loss and round-trip-time (RTT).

As indicated in <FIG>, suppose, the first communication interface <NUM> be the default communication interface for the UE <NUM> and the data session between the UE <NUM> and the destination server <NUM> may be established on the first communication interface <NUM>. At this point, the application socket "<NUM>" of the application running on the UE <NUM> may be mapped to the first socket "<NUM>" associated with the first communication interface <NUM>. At the same time, the second socket "<NUM>" and the second communication interface may be set-up and put in the "wait" state.

Further, as indicated in the <FIG>, suppose the strength of the Wi-Fi™ signal on the first communication interface <NUM> gets weaker during the data session <NUM>, resulting in an increase in the latency. At this point, the network handover system <NUM> detects a deteriorating network condition <NUM> on the first communication interface <NUM> and may dynamically decide to handover the data session to the second communication interface <NUM>. Consequently, the network handover system <NUM> in the UE <NUM> may map the application socket "<NUM>" to the second socket "<NUM>" through the abstraction layer. In other words, the abstraction layer maps to the LTE socket on the UE <NUM>. Once the second communication interface is up and running, the data session <NUM> continues on the second communication interface. In addition, the data session may be returned to the first communication interface <NUM> when there is a deteriorating network condition <NUM> on the second communication interface <NUM>. The application running on the UE <NUM> and the destination server <NUM> are unaware of the handover and continue to participate in the data session seamlessly.

The series of actions that take place during the handover are illustrated in detail in the sequence diagram of <FIG>. In an embodiment, the network handover system <NUM> is an intermediary between the application <NUM> running on the UE <NUM> and the network interfaces (i.e., the first communication interface <NUM> and the second communication interface <NUM>). First, the application <NUM> queries the DNS to the DNS server <NUM>. In steps <NUM> and <NUM>, the application <NUM> inquires of the DNS server <NUM> address information (i.e., IP address) via the network handover system <NUM> (i.e., the NH4 module). In step <NUM>, the DNS server <NUM> returns list of IP addresses. In steps <NUM> & <NUM>, the network handover system <NUM> stores the server details and returns the list to the application <NUM>. The application <NUM> tries to establish the connection with the end server using CONNECT system call (FD <NUM>). The network handover system <NUM> taps the CONNECT system call and check if the IP address (DESTINATION) is from the list of previously saved address.

Step <NUM> indicated start and/or running instance of the application <NUM>, where the application <NUM> has to connect with the destination server <NUM>. Accordingly, at step <NUM>, the application <NUM> transmits a "connect" request to the network handover system <NUM>. At step <NUM>, the network handover system <NUM> fetches details of the connection requested by the application <NUM> and transmits the connection requested by the application to the default first communication interface <NUM>, which is Wi-Fi™. At step <NUM>, the first communication interface <NUM> connects to the destination server <NUM>. The destination server <NUM>, upon receiving the "connect" request, validates the request and returns a "success" message to the first communication interface <NUM> after a successful validation of the "connect" request at step <NUM>. Further, at step <NUM>, the first communication interface <NUM> forwards the "success" signal to the network handover system <NUM>. At this point, the first communication interface <NUM> also notifies a socket identifier of the first socket (i.e., <NUM>) to the network handover system <NUM>, which in turn, maps the first socket "<NUM>" to the application socket "<NUM>" of the application <NUM>. Further, at step <NUM>, the network handover system <NUM> returns details of the mapped application socket "<NUM>" to the application <NUM>, indicating successful connection with the destination server <NUM>. Consequently, the application <NUM> initiates a data session <NUM> with the destination server <NUM> at steps <NUM>, <NUM>, and <NUM>.

Suppose, at step <NUM>, the signal on the first communication interface <NUM> gets weaker during the data session. This condition may be treated as a deteriorating network condition <NUM> and the same may be notified to the network handover system <NUM> and the network interfaces <NUM> and <NUM>. Consequently, at step <NUM>, the network handover system <NUM> fetches details such as socket identifier and pending data packets in the socket buffer from the first communication interface <NUM>. Further, at step <NUM>, the network handover system <NUM> initiates the handover by trying to establish the connection over the second communication interface <NUM>. At steps <NUM> and <NUM>, the second communication interface <NUM> complete validation with the destination server <NUM> by exchanging the "connect" and success" signals. Once the validation is complete, at step <NUM>, the second communication interface <NUM> returns the ID of the second socket "<NUM>" to the network handover system <NUM>. Then the network handover system <NUM> maps the second socket "<NUM>" to the application socket "<NUM>" and establishes a connection with the destination server <NUM> using the second communication interface <NUM>. Thereafter, the application <NUM> seamlessly completes the data session with the destination server <NUM> using the second communication interface <NUM> as indicated in steps <NUM>, <NUM> and <NUM>. Here, the application <NUM> is unaware of the migration of the data session from Wi-Fi™ to LTE, since for the application <NUM>, the socket <NUM> still remains undisturbed and does not feel disconnected.

<FIG> illustrates a flowchart of a method for handling a data session in a user equipment (UE) <NUM>.

As illustrated in <FIG>, the method <NUM> may include one or more steps illustrating a method for handling data session in the UE <NUM>. The order in which the method <NUM> is described is not intended to be construed as a limitation, and any number of the described method steps can be combined in any order to implement the method. Additionally, individual steps may be deleted from the methods without departing from the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.

Step <NUM> in <FIG> can be illustrated as: Initiate a data session of at least one application from a plurality of applications with a first communication interface using a first socket of the UE having a first Socket File Descriptor (SOCKFD) for the data session. In particular, at step <NUM>, the method <NUM> includes initiating, by the connection tracker module of the <NUM> network handover system <NUM>, a data session <NUM> of at least one application from a plurality of applications with the first communication interface <NUM> using the first socket <NUM> of the UE <NUM> having a first socket file descriptor (SOCKFD) for the data session. In an embodiment, the data session <NUM> may be a communication session that connects the UE <NUM> with a first communication interface <NUM>, and in turn with a destination server <NUM>, using a first socket <NUM> of the UE <NUM>. As an example, the first communication interface <NUM> may be Wi-Fi™.

Step <NUM> in <FIG> can be illustrated as: Detect a deterioration in a network connection of the first communication interface. In particular, at step <NUM>, the method <NUM> includes detecting, by the switchboard module <NUM> of the network handover system <NUM>, a deterioration in a network connection (or network condition) <NUM> of the first communication interface <NUM> during the data session <NUM>. In an embodiment, the deteriorating network connection <NUM> may interrupt or disrupt the data session <NUM>. The detection of the deterioration in the network connection may be based on at least one of low data throughput, low data rate, lost signal, frame loss, high jitter, and broken connectivity between the UE <NUM> and the destination server <NUM>. In an implementation, the deteriorating network condition <NUM> may be detected by at least one of the UE <NUM> and the abstract network communication layer. Here, the abstract network communication layer may be transport layer in between application layer and transport layer of the communication interface. A connection notification or broadcast events indicating the deterioration in the network connection may be sent to the abstract network communication layer by the switchboard module <NUM>.

Step <NUM> in <FIG> can be illustrated as: Identify a second communication interface. In particular, at step <NUM>, the method <NUM> includes identifying, by the switchboard module <NUM> of the network handover system <NUM>, a second communication interface <NUM>.

Step <NUM> in <FIG> can be illustrated as: Establish a second socket having a second SOCKFD associated with the second communication interface. In particular, at step <NUM>, the method <NUM> includes establishing, by the layer <NUM> Network Handover (NH4) module <NUM> of the network handover system <NUM>, a second socket <NUM> having a second SOCKFD associated with the second communication interface <NUM>. Here, the second socket <NUM> may be network socket corresponding to the second communication interface <NUM>. In an embodiment, the second communication interface <NUM> may be different from the first communication interface <NUM>. As, an example, the second communication interface <NUM> may be long term evolution (LTE) cellular network interface.

Step <NUM> in <FIG> can be illustrated as: Migrate the data session from the first communication interface to the second communication interface by mapping the first SOCKFD corresponding to the first socket to the second SOCKFD corresponding to the second socket. In particular, at step <NUM>, the method <NUM> includes migrating, by the NH4 migrator module <NUM> network handover system <NUM>, the data session from the first communication interface <NUM> to the second communication interface <NUM> by mapping the first SOCKFD corresponding to the first socket <NUM> to the second SOCKFD corresponding to the second socket <NUM> for seamlessly handing over or migration of the data session <NUM> to the second communication interface <NUM>. In an embodiment, the mapping of the first SOCKFD of the first socket <NUM> to the second SOCKFD of the second socket <NUM> may be performed on an abstract network communication layer for the data session. Also, in an implementation, an application, running on the UE <NUM> and using the data session, may not be aware of the migration of the data session <NUM>.

The network handover system <NUM> may continue the data session <NUM> on the second communication interface <NUM> using the second socket <NUM>, thereby handling the data session on the UE <NUM>. Thereafter, the data session may be concluded as if the data session was originally carried out on the first communication interface <NUM>.

In an embodiment, prior to migration of the data session, the network handover system <NUM> performs one or more actions in the UE <NUM>. Initially, the classifier module <NUM> of the network handover system <NUM> classifies, a plurality of applications running on the UE <NUM> as at least one of handover-sensitive applications (i.e., whitelist applications) and handover insensitive applications (i.e., blacklist applications). The classification of the plurality applications running on the UE <NUM> as at least one of handover-sensitive applications and handover insensitive applications is done based on at least one of nature of application and latency requirement of the application. Further, a communication protocol corresponding to the handover-sensitive applications is determined by the classifier module <NUM> and the determined communication protocol may be notified to the NH4 module <NUM> by the classifier module <NUM>. Subsequently, the first SOCKFD corresponding to the first socket <NUM> of the UE <NUM> is mapped to the second SOCKFD corresponding to the second socket <NUM> of the UE <NUM> based on the determined communication protocol by the NH4 migrator module <NUM>. After mapping, a plurality of notifications related to the handover-sensitive applications may be controlled during migration of the data session by the event blocker module <NUM>.

In an embodiment, the communication protocol may be at least one of user datagram protocol (UDP), transmission control protocol (TCP) and cross-layer quick UDP internet Connections (C-QUIC) protocol. In an implementation, handing over the data session using the UDP may include determining application data pending for transmission on the first communication interface <NUM>. Once the pending data has been determined, the application data may be fetched from a socket buffer associated with the first socket <NUM> of the UE <NUM> and header information of the application data may be cloned. Thereafter, the cloned header information may be mapped to the second socket <NUM> of the UE <NUM> for continuing the data session through the second communication interface <NUM>.

On the other hand, handing over the data session using the TCP may follow a slightly different procedure and may comprise creating an abstraction layer corresponding to the first socket <NUM> of the UE <NUM> and mapping SOCKFD associated with the first socket <NUM> to a pseudo socket corresponding to the abstraction layer. Thereafter, the data session may be continued and/or re-established through the pseudo socket file descriptor.

In an embodiment, during handover using the QUIC, the CQUIC model dynamically predicts the signal-to-interference-noise-ratio (SINR) and models the handover decision pro-actively. This helps in improving the latency by initiating handover well-ahead of the possible connection termination or deteriorating condition in the interface.

In an embodiment, with the configuration of the network handover system <NUM> in the UE <NUM>, a transient layer may be introduced in the network configurations of the UE <NUM>. In the transient layer, the Wi-Fi™ and the mobile data/LTE may be enabled only when ? a) it is predicted that Wi-Fi™ has a weak signal and/or b) when there is a probability that the Wi-Fi™ may be disconnected. The above operation of the transient layer in the network handover system <NUM> is different from the way it is operated in the existing default network management strategy or the MPTCP. A comparison in the behavior of the handover in each of these techniques is illustrated in Table A below.

<FIG> illustrates a comparison between existing handover techniques and the provided handover method in accordance with some embodiments of the present disclosure.

<FIG> provides an exemplary overview of the network handover in the Android® framework, MPTCP and using the provided network handover system <NUM>. In the case of Android®, the handover may not be seamless. Thus, the application and/or the users go through a poor quality of experience during the handover, specifically, when there is a handover from weak and/or disconnected Wi-Fi™ to the LTE and vice-versa. In the case of MPTCP, both the LTE and the Wi-Fi™ are always up and running. Though the handover is seamless in MPTCP, it is a resultant of higher power consumption and higher data consumption. On the other hand, the handover on the provided network handover system <NUM> is both seamless and optimized. This is because, the network handover system <NUM> pro-actively classifies the applications into "whitelist" and "blacklist" applications and ensures that only the "whitelist" applications switch to the LTE in case of an interruption on the Wi-Fi™ network. Also, as explained in the earlier sections, the handover using the network handover system <NUM> is seamless and optimized since only the whitelisted applications use the LTE.

Claim 1:
A method (<NUM>) for handling a data session in a user equipment, UE, the method comprising:
initiating (<NUM>), by a connection tracker module of the UE, a data session of at least one application from a plurality of applications with a first communication interface using a first socket of the UE including a first socket file descriptor, SOCKFD, for the data session;
classifying, by a classifier module of the UE, the plurality of applications running on the UE as handover-sensitive applications or handover insensitive applications based on at least one of a nature of the application or a latency requirement of the application;
determining, by the classifier module of the UE, a communication protocol corresponding to a handover-sensitive application of the plurality of applications running on the UE;
detecting (<NUM>), by a switchboard module of the UE, a deterioration in a network connection of the first communication interface;
identifying (<NUM>), by the switchboard module of the UE, a second communication interface responsive to detecting the deterioration in the network connection;
establishing (<NUM>), by a layer <NUM> network handover, NH4, module of the UE, a second socket including a second SOCKFD associated with the second communication interface; and
migrating (<NUM>), by a NH4 migrator module of the UE, the data session from the first communication interface to the second communication interface by mapping, based on the determined communication protocol, the first SOCKFD corresponding to the first socket to the second SOCKFD corresponding to the second socket.