This is not exactly what Qualcomm was describing in the article I linked to;
they were talking about real-time hand-offs between Wi Fi hot spots. But yes,
this is the technology that is currently being deployed by most carriers.
I would add that Apple offers a feature they call WiFi handoff between devices
that are connected to the same WiFi router. The call typically originates on
the cellular network the phone is connected to, but the call can be answered on
any Mac or iPad, as designated by the user.
Regards
Craig
On Jan 31, 2017, at 9:54 PM, Manfredi, Albert E
<albert.e.manfredi@xxxxxxxxxx> wrote:
Here, Craig. This is most likely what the cellcos are using, for seamless 3G
or 4G and WiFi handover. It is accomplished at layer 4, turns out. This
occurs above the WiFi layer and also above the 3G or 4G connection. The
article is dated 2012, so it's likely that this is what is being deployed for
this specific purpose.
Note: That's why VoIP is the topic, and not just old style voice handover
over 1G-3G. It is because, in order to achieve this seamlessness between the
cell schemes and WiFi, the easy expedient was to leverage off TCP/IP
handover. Hence, VoIP.
http://dl.acm.org/citation.cfm?doid=2342468.2342476
Click on the pdf at the top of the box you see at this site.
Bert
------------------------------------------
1. INTRODUCTION
Despite the huge investments, 3G mobile data networks have difficulties in
supporting the growing bandwidth consumed by recent smartphones and tablets.
Industry experts expect that these bandwidth requirements will continue to
grow in the future and the deployment of new cellular technologies such as 4G
or LTE may not be sufficient to sustain the demand.
In parallel with cellular data networks, WiFi is being deployed continuously:
most enterprise and schools provide WiFi services to their employees and
students, some cities have started to deploy WiFi services for their
citizens, and many homes use WiFi networks to connect to cable or ADSL
modems. Some operators, including BT in the UK or Belgacom in Belgium, have
deployed managed WiFi services on most of their clients' ADSL routers. This
allows services like FON to aggregate more than 3 million access points in
the UK alone [1].
The widespread availability of 3G and WiFi creates obvious opportunities for
end-users and operators alike. User experience can be improved if devices use
multiple links either simultaneously or alternatively while moving. Mobile
network operators would like to be able to "steer" the network their clients
are using depending on 3G occupancy, etc.
Meanwhile, the devices themselves use either the 3G or WiFi network at any
given point in time, and any handover between the two causes TCP connections
to be restarted which disgruntles users.
Multipath TCP (MPTCP) [10] is a TCP extension being standardized at the IETF
that enables a single TCP to use multiple interfaces on the client and/or the
server. MPTCP works with unmodified applications and runs over today's
Internet. In our previous work, we have described why MPTCP is a promising
solution for mobility [9] and used simulations to assess the possible
benefits.
In this paper we describe our experimental study of MPTCP handover. Our aim
is to understand how MPTCP will behave in practice, on real wireless networks
and with real
applications. To perform such evaluation we had to optimize the Linux MPTCP
stack in order to better support WiFi/3G handover.
A key concern for running MPTCP on mobiles is energy usage: we measure energy
consumption of MPTCP on the Nokia N950 to understand this aspect. Our results
show that using multiple interfaces provides better throughput but at higher
energy cost (Section 4.4). To capture this tradeoff, we first choose three
handover modes and test their performance in practice while handing traffic
from WiFi over to 3G (Section 4). We then show that MPTCP allows smooth
handovers from WiFi to 3G while maintaining connectivity for applications.
Finally, we propose minor changes to the MPTCP protocol that significantly
reduce handover delays in certain practical cases (Section 5).
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
