Seamless continuity of PS-services in WLAN/3G interworking

Computer Communications 29 (2006) 1055–1064
www.elsevier.com/locate/comcom
Seamless continuity of PS-services in WLAN/3G interworking
Paulo Pinto a, *, Luis Bernardo a , Pedro Sobral b
a Universidade Nova de Lisboa, Lisboa, Portugal
b Universidade Fernando Pessoa, Porto, Portugal
Received 13 December 2004; revised 18 May 2005; accepted 3 June 2005
Available online 28 June 2005
Abstract
The seamless continuity of services between 3G networks and WLANs will give users the feeling of a common environment towards the
wireless technology. Three main aspects must be considered to obtain seamless continuity: an enabling interworking architecture, fast intersystem
handovers (they must be fast enough in terms of human senses), and, in the case of real-time services, a similar quality of service
(QoS) in both networks. This paper focuses on the two first issues. It presents an interworking architecture based on a 3G core-level
integration of the WLANs. The GPRS network is available all the time forming a primary network, and WLANs are used as a complement
when they are available. The switching times between networks are very low and the transitions are lossless. Our proposal does not disrupt
with the current 3GPP standardization efforts making it viable in a medium time frame. This paper presents an overview of the architecture,
describes the relevant events in the switching process (where the authentication and authorization procedures have an important role), and
gives simulated values for the switching times.
q 2005 Elsevier B.V. All rights reserved.
Keywords: 4G networks; Interconnection 3G/WLAN; Seamless continuity of services
1. Introduction
The integration of wireless LANs (WLANs) and thirdgeneration
(3G) mobile networks, such as Global System for
Mobile Communication/General Packet Radio Service
(GSM/GPRS) and Universal Mobile Telecommunications
Systems (UMTS) is opening up a broad range of
possibilities due to the successful deployment of both
technologies. This range begins with low-level issues of
radio access integration until fulfilling one of the
characteristics identified by the Wireless World Research
Fund, namely the definition of a component-based
architecture that will enable users, application developers,
service and content providers, and manufacturers to
efficiently and flexibly create new services [1]. The main
subject of this paper is dedicated to the first issue but having
the second in mind.
The interconnection of 3G systems with WLAN in
general is being defined by 3GPP in a series of 6 scenarios
* Corresponding author. Tel.: C21 294 9642; fax: 21 294 8532.
E-mail address: pfp@uninova.pt (P. Pinto).
0140-3664/$ - see front matter q 2005 Elsevier B.V. All rights reserved.
doi:10.1016/j.comcom.2005.06.002
[2]. The various scenarios describe an increasing level of
integration between the two systems: (1) common billing,
with the objective of having a single customer relationship;
(2) 3G based access control, where the 3G provides the
AAA procedures to WLAN users with an equal security
level (although a single sign-in approach is not yet an
objective); (3) access to 3G packet-switched (PS) services,
to allow an operator to extend these services to the WLAN
(this is the current state of the art in the standards); (4)
access to 3G PS services with service continuity, with the
objective that the services of scenario 3 would survive a
change of access between the two systems; (5) the same
as scenario (4) with seamless continuity, the services not
only survive but there is seamless continuity. By
seamless continuity it is meant minimizing aspects such
as data loss and break time; and (6) access to 3G circuitswitched
(CS) services with mobility, which means access
to services provided by the entities of the Circuit
Switched Core Network over WLAN with seamless
continuity.
Currently, [3] describes the architecture for scenarios 2
and 3. Its approach to scenario 3 is to interconnect both
systems at IP-level following an interconnection architecture
known as loosely coupled approach [4]. Although [3]

1056
P. Pinto et al. / Computer Communications 29 (2006) 1055–1064
provides an answer to scenario 3 there is the feeling that
higher scenarios raise low-layer considerations [5].
In this paper we present an architecture that can handle
scenarios 4 and 5 based on a core-level coupling of the
systems. Extensions of this architecture might handle
scenario 6 as well but this is out of the scope of the paper.
The paper begins with a description of the core-level
approach introducing the innovative aspects of the
architecture. Section 4 presents the authentication, authorization
and accounting (AAA) procedures. They are critical
to the handover times. Our AAA procedures follow very
closely the 3GPP standard (which is already at an advanced
state). However, they show a different perspective, not so
3G centric, for the inter-relation between the networks. The
application of our architecture to scenarios 3, 4, and 5
precede the presentation of the simulations results and the
conclusions.
2. Initial assumptions
Throughout the paper we assume that mobile stations
(MS) will have two (or more) wireless interfaces that can
work simultaneously. We also assume that the security
control provided by the smart card called UMTS Subscriber
Identity Module (USIM) and the global roaming agreements
amongst 3GPP operators form the largest operational AAA
system in the world to date. This system could be used by
organizations not interested on setting up and manage a
system of their own. Finally, we assume that WLANs are
owned by any business organizations that rely on the 3G
operators for just authentication (therefore excluding
authorization). The organizations must trust each other up
to the point of user identification and validation but remain
independent in other aspects (for instance, user data directed
to one network must not be understood by the other). A good
example of such an organization is a University. It has
already a WLAN installed and has a community that can use
the local facilities for free at the sole discretion of the
University services; and visitors that can use the WLAN to
access 3G systems but not local services. For each access to
the 3G system the University should be paid a fee.
3. Overview of the architecture
In our architecture the user is always connected to the
GPRS network. Any use of a WLAN is complementary.
There are two major consequences: all the control features
(paging, compulsory registration update, user location, etc.)
remain as they are today and are only needed in the GPRS
network; and there is no need for total inter-system vertical
handovers such as they are defined in [6] (only a data-part
handover is performed). A similar approach of a primary
network was taken by MIRAI [7]. In their case there is a
controlling network (not for data) that has mainly the
controlling functionality of the GPRS (with some add-ons
such as choosing a data RAN - Radio Access Network). Our
approach of having the GPRS as the primary network makes
sense for two main reasons: if users want to use WLANs to
interconnect to the 3G systems they are obviously 3G users
and have access to GPRS; and GPRS is already ubiquitous.
This section provides an overview of the architecture. A
thorough description and some discussion can be found
in [8].
A WLAN RAN is a set of islands. Each island is formed
by a set of cells and is controlled by an Island Manager (IM).
Islands do not cover the entire space (i.e. there will be dark
areas). All islands of a certain technology are seen by the
primary network as a Hotspot Network (HN) - a secondary
network. The IM has the functionality of an access gateway
to the 3G system, AAA server for the WLAN, and AAA
proxy towards the 3G system.
A user is connected to the GPRS network and can be
connected to other HN networks simultaneously. Each HN
supports the notion of a session (i.e. IEEE 802.11 has one,
HiperLan has another, etc.). A session is a high level
concept to allow the maintenance of context during
disconnection periods when the user is moving in a dark
area of a certain HN. As the GPRS is always active this
concept of session is useful, and is not seen in other systems.
For instance, the user began a 802.11 session at the airport,
took a taxi to a hotel, and when he is in the hotel, the same
session is still on using the WLAN infrastructure of the hotel
(it is assumed that both have agreements with the users’
3GPP operator). On the way from the airport to the hotel, if
the user needs to be contacted in the context of that session
the primary network can be used.
Fig. 1 shows the architecture for the data traffic (no
access control, billing, etc.). All elements of the current 3G
core work unchanged except the SGSN (Serving GPRS
Support Node) and the HSS (Home Subscriber Server) that
must have its database enlarged to store the new type of
locations of MSs. Two new components are added: the
HNAC (Hotspot Network Area Controller) which controls
one (or more) island, and the GHSN (Gateway Hotspot
network Support Node) which is responsible for context
management and Internet access (here ‘context’ has a
similar meaning as used for the PDP context in GPRS). The
thicker lines belong to the core but they are not present in
the current 3G core. So, all high speed traffic goes through
them not overloading the current 3G infrastructure. The
HNAC interfaces the other components of the core behaving
as a SGSN. Therefore, no changes on the other components
are needed. The only exception is the SGSN itself that must
have a physical interface to the HNAC and must
communicate with it for the purpose of inter-system
handovers (see below). The GHSN has the functionality
similar to the GGSN. It could even be included in the
current GGSN. The connection to the WLAN is performed
by the IM that interacts with the HNAC at IP level and
interfaces the WLAN Access Point at L2 or L3. The Local

P. Pinto et al. / Computer Communications 29 (2006) 1055–1064 1057
MS
UTRAN radio
interface
BS
WLAN
AP
WLAN radio
interface
IMSI IP 1
3G
GGSN
SGSN
IP 2
L2/L3
distribution
network
IPa
IM
A
HNAC
core
network
HSS
GHSN
IP 3
Local
Router
Fig. 1. Data traffic paths in the hybrid network.
Router enables local users to use the Internet directly if
they wish.
Our core-level approach to wireless systems integration
has subtle but important differences when compared to the
tightly approach referred in the literature [4]. First of all the
control part never leaves the UMTS. Therefore there is no
need for control procedures in WLAN (paging, assignment
of cell or routing area identifiers); second, no core interfaces
are exposed to the exterior of the core creating possible
security and operational problems; third, the AAA
procedures are exactly similar to the current standard (no
vectors leave the core).
The solution in [3] is not directly comparable to our work
because they connect both networks at IP level. In their
system a new component is also installed in the core—PDG
(Packet Data Gateway). The PDG allows for the introduction
of the user into the system at IP level providing IP
access to 3G services. It is more comparable to our GHSN
than to our HNAC. Furthermore, the WLAN traffic goes
directly into the core in our solution whereas in [3] it goes
via an external IP network to the PDG.
As shown in Fig. 1, applications can use one out of three
IP addresses: IP 1 address uses the standard GPRS; IP 2
address uses the HN network; and IP 3 address uses the local
internet access of the LAN. Applications just choose the
address related to the network they want to use preferably.
IP 1 and IP 2 addresses work all the time: for the case of IP 1
the UTRAN is used but the SGSN can use the HNAC,
sending the packets via WLAN when a WLAN is available;
for the case of IP 2 the WLAN is used. When the MS is
outside of WLAN coverage the traffic goes via UTRAN and
via the SGSN to the HNAC. This is done automatically but
applications can receive signals and halt the transmission of
packets momentarily. In the sequel it will become clear how
the data and control paths are established, and the different
communication possibilities between the core and the MS.
The GPRS part of the system is conform to the standard:
the MS has its identification at core level in the form of the
IMSI (International Mobile Subscriber Identity) and the
attachment procedure for GPRS is the standard one
(with temporary identifiers). In the GPRS part the IP 1
session is established after a PDP context creation with the
GGSN.
The WLAN part has two authentication phases (Fig. 2).
The WLAN authentication gives access to local services
(including direct Internet access). The MS is given a local IP
address (IPa), and a routable IP address IP 3 . Traffic using IP 3
uses the Local Router (Fig. 1) only. The 3G authentication
gives access to the 3G core via WLAN. The MS is identified
at the core by IPa, instead of the IMSI. When it creates a
context with the GHSN it is given the address IP 2 for
external Internet access. When the user moves from one
island to another the IPa changes but the IP 2 remains
the same.
An important feature in our architecture is the connection
between the HNAC and the SGSN (interface A in Fig. 1). It
allows each of these components to communicate with the
MS via the other one. It can be used, for instance, to
maintain IP sessions in HN dark areas; to access SMS (Short
Message Service) via WLAN, etc. - the MS identified by the
IMSI can be contacted via UTRAN (Universal Terrestrial
Radio Access Network) using the IMSI, or via WLAN
using the IPa.
In terms of data path GTP-U (GPRS Tunneling Protocol -
for User Plan) tunnels are used. Currently in GPRS a
tunnel is established between the GGSN and the SRNC
MS AP (a) (b)
B
1. authentication
2. association
3. WLAN authentication / authorization
4. 3G authentication / authorization / etc.
(a) – IM and WLAN AAA Server
(b) – 3GPP AAA Server
HSS HNAC GHSN
Fig. 2. Four phases for AAA procedures.

1058
P. Pinto et al. / Computer Communications 29 (2006) 1055–1064
(Serving Radio Network Controller). In our architecture this
tunnel is replaced by two half tunnels: one from GGSN to
SGSN and another from SGSN to SRNC (and similarly for
the WLAN - one from GHSN to HNAC and another from
HNAC to IM). This half tunnel definition is pretty much a
return to the first standardization phase of GPRS. The reason
for the partition is to allow the SGSN (or HNAC) to use
other radio networks through interface A.
Note that the MS never leaves the UMTS for control
purposes. The handovers are just performed for the data
part. The consequence is that the GPRS radio interface must
always be active. This is the price to pay for not having
control procedures in secondary networks (it is not obvious
how paging, cell or routing area identifiers etc., would be
defined in secondary networks and how their coexistence
with the 3G network would be). Nevertheless, the power
consumption is not so dramatic and is comparable to the
current situation of a MS when it is in standby.
4. Associations and context creation
Before a new secondary radio access becomes ready to
be used there are two operations that take some time:
security associations and QoS guarantees (for real-time
services). The latter one is out of the scope of this paper. The
former is probably longer and [3] contains a very clear
definition of the process that we will follow very closely
here. The major change here is a greater autonomy of the
WLAN owner to authorize its users. [3] is, naturally, very
3G centric.
Fig. 2 shows the four main phases. We assume that we
are using an IEEE 802.11 WLAN.
After a Beacon frame is received, the MS authenticates
using the standard open-system authentication. This is a
very weak procedure just to give free access to some trivial
local services (announcements, etc.). The second phase is an
association to the SSID in order to exchange data packets.
These are standard procedures and the packets involved are
shown in Fig. 3.
The third phase is initiated by the MS and the purpose is
to identify itself and get authorization to use the local
facilities. This phase is the one that deviate the most from
MS
Beacon
AP
[3]. We use the AKA method [9] supported by the EAP
(Extensible Authentication Protocol) mechanism [10].
Fig. 4 shows the various packets. The MS initiates an
authentication procedure selecting a 3G PLMN (Public
Land Mobile Network). The way to identify the PLMN is by
using a network address identifier (NAI) in the form of
username@realm (the username is the user identification
and realm is a domain name [11] identifying the PLMN).
We assume that the WLAN has an agreement with the user’s
PLMN. If it has not, an advertisement and a selection phases
have to exist (see [3]). Another aspect we do not treat here is
the differences between Home and Visiting PLMNs (again,
see [3]). The IM behaves as an AAA proxy relaying the
information to the 3GPP AAA Server (the HNAC, for
instance). The outcome of the operation is an indication via
the secure channel between the IM and the 3GPP AAA
Server that the MS is what it claims to be. A possible piece
of information can be the MSISDN (Mobile Subscriber
ISDN Number) because it is not compromising to the 3G
system. This is conveyed in the EAP-Success packet just
before point 1. At point 1 the IM consults its data base and
two things can happen: the user is a member of the
community (student, teacher, etc.), or he is not.
If he is a member, the IM provides the MS with IP
addresses: IPa, IP address IP 3 , the IP address of the HNAC
to pursue authentication if the user wants to use the so called
‘WLAN 3GPP Access’, and session keys for the purpose of
radio interface integrity protection and encryption in the
WLAN session. As it was stated before, IP 3 is a routable
address that enables the MS to use all the services of the
local network.
If he is not a member (e.g., he is a visitor at the
University) the IM simply indicates the IPa and the IP
MS
EAPOL Start
EAP Req/Ident
EAP Res/Ident
EAP Req/AKA
IM
EAP Res/Ident
EAP Req/AKA
3GPP AAA
Server
Auth info Req
Auth info Reply
Subs Prof Req
Subs Profile
Profile Ack
HSS
1.
2.
Authenti. Alg. 0 – Seq 1
Authent. Alg. 0 – Seq 2
Association Request
Association Response
EAP Res/AKA EAP Res/AKA
EAP Success
1
EAP Success + keys + IP
Fig. 3. Open-system Authentication and Association.
Fig. 4. WLAN user authentication and authorization.

P. Pinto et al. / Computer Communications 29 (2006) 1055–1064 1059
address of the HNAC. This MS can use the WLAN to reach
the 3G system but cannot use local services.
Note that the authorization decision to use local facilities
is performed by the University and the 3G system is only
used to authenticate users, making the overall WLAN AAA
management in the University simpler.
Every user, recognized or not by the University, can use
the WLAN to access the 3G system - it is now up to the 3G
operator to allow it or not. This is the purpose of the last
phase showed in Fig. 5. The MS initiates the procedure
requesting an attach procedure to the HN. If the user was
previously attached and went through a dark area, a reattach
procedure should have been done instead. The packet
starts a similar procedure as before.
We assumed here that the HNAC behaves as AAA server
getting information from the HSS. The HNAC issues the
AKA challenge and if the response is valid it creates a
context with GHSN the same way a context is created in
GPRS with the GGSN. The final packet has the indication of
success, session keys to be used by the MS without the
knowledge of the IM or WLAN, temporary identification,
and the IP 2 address to be used by the MS.
Phase 3 and phase 4 are very similar but they must both
exist to keep the two systems as independent as possible (for
instance, a user might not want to have ‘WLAN 3GPP
Access’, not performing phase 4).
5. Interconnection of the different systems
If the user gets authorization to use the three networks the
three possible data flows together with the main components
involved are depicted in Fig. 6(a). Legacy applications that
MS
HN Attach
EAP Req/Ident
EAP Res/Ident
EAP Req/AKA
EAP Res/AKA
HNAC
HN Attach Ack + keys + IP
HSS
Retrieve authentication
information and user profile
as in fig. 4
Get HN Context
Send New HN Context
WLAN Regist
Regist Confirm
GHSN
MS
MS
MS
WLAN
WLAN
UTRAN
UTRAN
UTRAN
IM
IM
SGSN
HNAC
LR
SGSN
A
SGSN
A
want to use the 3G services will use either IP 1 or IP 2 (the
system will use WLAN preferably when available). New
applications can explicitly use one or the other and control
when they want to send packets. The interface A between
the SGSN and the HNAC allows other interesting scenarios.
When the user is in an HN dark area communication using
IP 2 can still be done using the GPRS, as showed in part (b).
The usage of IP 1 continues to use the UTRAN, obviously.
Part (c) shows the case when the user is under HN coverage
and decides (or the network decides automatically) that an
MMS, for instance, can be delivered via WLAN. Note that
the control part (paging, etc.) uses always the GPRS
network (the control parts are not shown in Fig. 6).
Fig. 7 shows the protocol stack used to manage the
communication and these various possibilities. The full
stack exists in the MS. The SGSN and HNAC have only the
three lower layers (up to IP). The two higher layers in the
network side exist only for applications that know how to
work with secondary networks and reside in application
servers. The session control and application layers are part
(a)
HNAC
HNAC
LR
(b)
(c)
GGSN IP 1
GHSN
IP 2
IP 3
GGSN
GHSN
IP 1
IP 2
GGSN IP 1
GHSN
IP 2
IP 3
Fig. 6. Different possibilities for the data flows.
Applicat. A
L1/L2
Applicat. B
Session Control
IP
Delivery Service
L1/L2
Connection
Manager
(CM)
WLAN
UTRAN
Fig. 5. 3G user authentication and authorization
Fig. 7. Protocol Stack at the MS/HNAC/SGSN.

1060
P. Pinto et al. / Computer Communications 29 (2006) 1055–1064
of the component-based architecture referred in the
introduction and allow, among other things, to maintain
user sessions between WLAN contacts. The focus in this
paper is on the lower layers. The IP layer in the MS can be
working with one of three IP addresses: IP 1 and the
communication is with SGSN, IP 2 and the peer is the
HNAC, or IP 3 and the peer is the IM. The Delivery Service
(DS) is used in the first two cases to allow an otherwise IP
direct communication between the MS and one of the
elements of the core (SGSN or HNAC) to go via the other.
The DSs in the two core components cooperate to offer
alternative paths for data packets - e.g., the DS in HNAC can
give an IP 2 packet to the DS in the SGSN to be delivered to
the MS. The IP in the MS just receives it without knowing
that it came through the SGSN. Between the MS and HNAC
it offers a confirmed service of packet delivery because the
WLAN path can fail in dark areas (it is assumed that the
UTRAN is ubiquitous). When the WLAN path fails there is
an indication upwards to the service or application (similar
to a control plane indication) to inform it. The application is
free to keep sending data (that is sent through the UTRAN)
or pause until an indication of availability is received,
meaning that the user reappeared at another HN island.
Each time data is sent for delivery by the service or
application it can carry a control indication stating the radio
path to be used. The DS will use this information to deliver
the packets. If no control indication exists (legacy
applications, for instance) then the default radio path is
chosen (UTRAN for IP 1 and WLAN for IP 2 ), or an
automatic decision is made (if WLAN is available always
use the WLAN). In the case of the WLAN, if the path is not
available the UTRAN is used automatically. In summary,
applications can stop sending data if they know the MS is
out of coverage, but any data sent will be delivered.
For services that do not use the IP stack the choice of the
radio path is performed by the core identification of the MS -
either the IMSI or the IPa.
When a user attaches to an island its profile at the HSS is
updated. Entities delivering 3G services, such as SMS, can
query the HSS for information and decide to use the WLAN
instead of the UTRAN. The HNAC can also run an event
service to notify any other core entity that a particular MS
entered in an island.
As stated above the WLAN part of the DS is confirmed to
detect when users leave WLAN coverage. If an acknowledgement
of a packet is not received at the DS in the HNAC
it forces a kind of handover. The packet that failed is sent via
SGSN and the originator is signaled that the user is no
longer reachable by WLAN (legacy applications are not
able to catch these signals, obviously). Note that no
information is ever lost in handovers because the HNAC
will transmit the packet again through the other interface. A
confirmed service means that the HNAC has to buffer
packets. However this mechanism is equivalent to a Logical
level mechanism (the timer is very small - about 40 ms). At
a rate of 2 Mbps a 10 Kbyte buffer is needed per flow. Once
a first packet fails, all subsequent packets will be sent by
UTRAN without buffering (see below).
A final point refers to the communication at DS level
between the HNAC and the MS. There are several
possibilities: one is to establish an IP tunnel (not shown in
the protocol stack in Fig. 7). The DS in HNAC establishes
an IP-tunnel directly to the MS using the IPa address;
another possibility is to establish an IP-tunnel to the IM and
use VLANs after that (in this case IPa is just an identifier);
still another possibility is to use layer 2 switching all over.
6. Use of the architecture for scenario 3
The option in [3] was to ‘provide WLAN MSs with IP
bearer capability to access PS based services which are
provided by PLMN’. Our approach is completely different -
the WLAN MSs have the capability to join the 3G core and
access any PS service at core level, and not at IP level.
However, it is interesting to see how PS services can be
accessed using our architecture. We will see that some
procedures defined in [3] are not needed and the whole
process becomes much simpler. Fig. 8, taken from [3] shows
the necessary components for the case of SMS (Short
Message Service). The IP-SM-Gateway:
† must maintain an association between the users’
MSISDN and its IP address;
† must interface the GMSC behaving as an SGSN or MSC;
† must support registration and authentication of the MS
for SMS services;
† must support security associations between the MS and
itself; and communicates with the MS using IP based
protocols.
In our architecture the SGSN is contacted by the MS (via
WLAN) and the SMS is just delivered. There are, of course,
changes in the current logic of the components (SGSN and
MS) to make them aware of different radio possibilities of
SME
HSS /
(HLR)
C
E
MSC
UE
SM-SC
GMSC / SMS-IWMSC
Gd
SGSN
E’ or Gd’
IP-SM-GW
UE
Fig. 8. Architecture for SMS support with an IP terminal.
??

P. Pinto et al. / Computer Communications 29 (2006) 1055–1064 1061
delivery but there are no extra authentications or registrations.
These changes were also felt as needed in the
architecture of Fig. 8 (they were left for further study).
7. Interworking architecture for scenarios 4 and 5
With our architecture, scenarios 4 and 5 of [2] are
indistinguishable because new RANs take some time to get
ready but the activation is instantaneous (strictly speaking in
scenario 5 there is also some bandwidth and delay
guarantees that must be satisfied, but this is out of the
scope of this paper).
There are two situations to analyze: (a) Find Coverage - a
user is connected to the UTRAN and a WLAN becomes
active, and (b) Lose Coverage - a user using a WLAN walks
out of coverage and the UTRAN has to be used.
In the first situation the user is running a service/application
(using either the IP 1 or IP 2 addresses) and the terminal
receives a Beacon frame. The situation is depicted in Fig. 9.
Since the moment the user enters the WLAN cell until it
receives the Beacon it lasts Dt1 s. The procedures described
in Section 4 are then performed and will last Dt2 s.
Alternatively, a re-attach procedure would have been
performed if the user had already done an attach procedure
previously (the elapsed times are similar). In either case,
once the procedures are done there is an indication from the
DS in the HNAC upwards to the applications and to the DS
in the SGSN signaling that the connection is ON. Services/
applications using either the SGSN or the HNAC can deliver
their packets through the WLAN. So, the continuity of the
services is seamless. It is just the time from the reception of
the indication and the delivery of the packet. Both Dt1 and
Dt2 are not in the critical time path because the user is using
the UTRAN. As the attachment to secondary networks does
not involve the control part it can be performed outside the
critical part (another very important difference towards the
tightly coupled approach). An interesting time interval is
how long it takes since the Beacon frame is received until
the first packet arrives to the MS via WLAN.
In the second situation the user walks out of coverage
without making a disassociation (the worst and probably the
most common case). The DS in the HNAC transmits a
packet and does not receive an acknowledgment. At that
Find coverage
UTRAN
WLAN
Lose coverage
WLAN
UTRAN
sense
∆t1
AAA
∆t2
Fig. 9. Handovers between RANs.
moment it declares the interface as OFF, signals upwards,
and also to the DS in the SGSN. If the packet belongs to an
application using the HNAC, the packet goes to the DS of
the SGSN for delivery, and all subsequent packets after that.
In more general terms, all packets of this kind will go via
SGSN after the first failure. If the packet belongs to a service
using the SGSN it is transmitted back to the DS in the SGSN
and delivered. The SGSN was already signaled and will not
send any more packets.
The retransmission timeout for the WLAN is the critical
time to consider if we want the change of networks to be
seamless. It should be noted, however, that its value can be
short because it is a low-level timer. A failure of a single
packet turns the link to OFF and triggers the recovery
described in the previous paragraph.
After a failure and a declaration of the link to OFF, a
WLAN disconnection procedure for the MS must be
initiated. But the failure could be due to transient
disturbances and the MS might still be contacted after a
while, initiating a re-attachment procedure. To avoid this
kind of instability, after the link is declared OFF the DS in
the HNAC tries to send k echo packets to the DS in the MS.
If they fail the user has moved away and the disconnection
procedure is initiated. If there are replies the link comes
back to ON again and indications are sent to the DS in the
SGSN and upwards in the HNAC.
The disconnection procedures in our architecture are
much lighter than in the approach followed in [3]. The
tunnel from the GHSN to the HNAC, for instance, is not
disconnected because the application can still use the
UTRAN. The main operation is the update of the WLAN
user status at the HSS (applications are already aware
because of the signaling), and the disconnection of the
tunnel between the DS in the HNAC and the DS in the IM (if
it exists).
8. Simulation results
We simulated the exchange of packets using the ns-2
with add-ons for PCF (Point Coordination Function) in 802.
11 [12], and for UMTS [13]. Our choice of PCF was to
consider a longer delay due to having to wait for the time
slot, and to use a mode that can provide certain resource
guarantees. PCF was never popular but an equivalent mode
is appearing in 801.11e.
Due to incompatibilities in the address types of both addons,
simulations had to run separately but the correspondent
times for switching between simulators were registered for a
complete story. The radio interface was DSSS (Direct
Sequence Spread-Spectrum) with a bandwidth of 10Mbps in
the band of 914 MHz. This band is an ISM (Industrial,
Scientific, Medical) window in USA and the ns-2 uses it.
Taking into account the size of our packets, the difference
between using this window or the 2,49 GHz window, or
between using 10 Mbps or 11 Mbps is irrelevant. The radio

1062
P. Pinto et al. / Computer Communications 29 (2006) 1055–1064
AP
propagation model was Free-space attenuation at near
distances and two ray ground approximation at far
distances. For the cell dimension configuration the default
values were used.
In the PCF setting, agents were created in the ns-2 to
represent the real components as shown in Fig. 10. The link
between the IM and the HNAC was the longer one (around
30 Km) with a delay of 10 ms. All the other wired links had
a delay of 0.1 ms. The bandwidth on all wired links was
10 Mbps (again, this is not so relevant because the traffic is
low). To simulate data base accesses a value of 20 ms was
used. There are four of these periods in the situation of find
coverage (these periods could be reduced if the AAA server
and the HNAC were the same component). The timeout
value to recover from a failed packet from HNAC to MS via
WLAN was 40 ms.
The simulations focused on the handover process. There
was no particular application but the analysis of the
handover situations. We assumed that there were always
packets to be sent (otherwise the handover is even more
seamless). When moving from the WLAN to the UMTS
(find coverage) the SGSN is signaled after the user has
performed the AAA procedures. It then starts to send
packets via WLAN. The time starts when the signal is
received and ends when the packet reaches the MS via
HNAC. The move from UMTS to WLAN (lose coverage) is
a little bit more complex. The system is using the WLAN
and a packet is sent via HNAC (the time starts here).
Meanwhile, the MS leaves the WLAN and the transmission
of this packet will fail. The packet is then sent to the SGSN
and to the MS (the time stops when the MS gets the packet.)
Table 1 shows the values obtained. Cases labeled as 1 are
services running over SGSN (e.g. SMS). Cases labeled as 2
are new applications running over HNAC. There are some
minor differences because for instance in the situation of
lose coverage for case 1 the packet has to be sent back to
SGSN. In all other situations and cases only signaling
packets travel from HNAC to SGSN. Basically the
simulations proved that these differences can be reduced
to packet dimension differences and are very small (in one
case the PCF slot synchronization compensate them
entirely).
Table 1
Values for handovers
IM
SGSN
HNAC
Fig. 10. Components in the ns-2 setting.
HSS
Find Coverage
Lose Coverage
Case 1 Case 2 Case 1 Case 2
216.5 ms 216.5 ms 40.5C56.0 40.2C56.0
16.7 ms 16.7 ms
In the situation of find coverage the first line shows the
time between the moment the EAPOL Start packet was sent
(start of the first phase), and finished when the attach reply is
received by the MS. The second line shows the real
switching time (described above):
† for case 1 it starts when the SGSN receives a signal
indicating that the WLAN via is ON and finishes when
the MS receives a packet via HNAC (we assumed that a
data packet was immediately available to be sent);
† for case 2 it starts when the HNAC receives the attachreply
(a packet is already there to be sent) and finishes
when the MS receives the data packet.
In the situation of lose coverage the times presented are
the failing part in the WLAN plus the recover via UTRAN.
As a first comment it is important to note that for the
situation of find coverage the values of 216.5 ms are not in
the critical path. The MS starts these procedures but is still
communicating using the UTRAN (or other WLANs). The
real switching time is 16.7 ms. Secondly, the overall times
are very small and show that the architecture is viable.
Thirdly, 37% of the preparation time in the situation of find
coverage (216.5) is due to processing times (four times
20 ms). In some situations 20 ms can be too long and if
the 3GPP AAA server is inside the HNAC half of the
interactions with HSS could disappear. Lastly, 41% of the
time in the situation of lose coverage is due to the timeout.
This situation is the real critical one in this system but the
overall time (less than 100 ms) is promising. Note however
that this is the real critical situation in all systems [6], and
our architecture behaves better due to the absence of a real
vertical (fully inter-system) handover. In these types of
handovers AAA procedures to the new RAN have to be
done in the critical path.
9. Related work
Apart from the tightly and loosely coupled approaches, a
hybrid approach is described in [14]. There is a component
called APGW (Access Point Gateway) that is responsible
for the integration. The APGW behaves like a tightly
coupled device for real-time traffic and loosely coupled for
non real-time traffic. The APGW does not belong to the core
but because tightly coupled is used core interfaces have to
be available to the outside of the core. This is potentially
dangerous and is a characteristic of the tightly coupled
systems. If someone tampers with this information the
network will suffer greatly. Another disadvantage of the
tightly coupled approach is that WLAN cells must behave
exactly as cellular cells. The MS moves to these cells
leaving the UMTS cells. All control procedures have to be
implemented such as cell identifiers and routing area
identifiers. Also paging must be supported, and IEEE 802.
11 does not provide it at physical/link level. All these

P. Pinto et al. / Computer Communications 29 (2006) 1055–1064 1063
concerns are missing in [14]. Another important missing
issue is a description of the context creation/update towards
the HSS (making it difficult to infer when the switching
moment happens). A last disadvantage is that the APGW
behaves exactly as an SGSN but it is not in the core (again
there is a potential security danger). To save time in
handovers they keep the PDP context and keep the signaling
connection active in UMTS when the MS goes to the
WLAN. This is a non-standard procedure that can interfere
with data forwarding and control procedures (where is the
MS in fact?). The current core (specially the SGSN) has to
be deeply changed to support radio bearers active but
dormant. [14] uses Mobile IP. This choice prevents fast
handovers because packets have to be sent to the Internet
and can also cause packet losses. In order to have a single IP
address the MS has to belong to two Foreign Agents (one in
the UMTS and another in the WLAN). The numerical
analysis in [14] uses signaling costs to refer to the exchange
of signaling messages. The problem is not so much how
many messages are exchanged but when (if in the critical
path) and the time they take (update a Home Agent takes a
very long time). They propose full (control and data) intersystem
handover. Therefore, all signaling must be done in
the critical time path. As they did not consider the times
involved it is difficult to assess whether their system support
seamless handovers. A final remark is related to the way
they differentiate traffic. A field at IP level (e.g. TOS - Type
of Service) is used. This is a new interpretation for this field
and might complicate the interaction with the signaling of
the network.
A second work is reported in [15]. A component called
VGSN (Virtual GPRS Supporting Node) is used to perform
the interworking. Mobile IP was avoided due to its latency
and packet losses and applications use only one IP address to
access the Internet. The interworking is based on the rules of
roaming. I.e., the VGSN behaves as if it belongs to a visitor
operator but several described functions of the VGSN are not
possible between roaming operators nowadays. When a user
moves from UMTS to WLAN the incoming packets from the
Internet come through the GGSN to the VGSN to the MS.
This means that a tunnel has to be established between the
GGSN to the VGSN (in a foreign operator). The VGSN is
behaving as a SGSN (outside the core). Traffic to the Internet
goes directly without passing through the VGSN (this can
cause problems with filtering devices because the IP address
does not belong to the WLAN). [15] does not cover control
aspects (cell id, routing area id, paging) when the user is
outside UMTS. They also propose a standby command to be
added to the standards to place a PDP context in standby
mode at the old SGSN when the MS moves to the WLAN.
When a MS moves from the WLAN to the UMTS the traffic
goes via SGSN and VGSN to the Internet (in this case the
VGSN is behaving as a GGSN with a tunnel to the SGSN).
The handover of a MS into UMTS is performed by a RA
(routing area) update. Again this is an overload of the
functionality of the current RA update procedure. The MS
has to store information about the original SGSN which goes
against the current standards. This handover is actually rather
complex because the MS starts by using the VGSN to inform
the SGSN that it wants to continue to use the WLAN IP
address. The SGSN will then send packets to its local VGSN
that can be different from the original VGSN (creating more
complexity about the IP address). To solve these inconsistencies
about the IP address and routing tables the authors
propose the usage of a proxy ARP. Finally, if the MS wants to
use UMTS addresses it has to create another PDP context,
this time with the GGSN.
As a conclusion of these descriptions we can see that the
current core must be changed. Either implicitly by saying that
we will not add new components but create new interfaces
and expose core interfaces to the exterior, or assuming that a
new component must be added with very little changes to the
core, and to the current procedural practices, as we propose.
Second, Mobile IP cannot provide seamless handovers.
Either we try to maintain the same IP address as in [15] with
great complexity, or we have different IP addresses managed
by the applications but always accessible through any
network as we do. By choosing a certain IP, applications
are choosing the preferred network they want to use. When
they are outside of coverage of that network they are signaled
and can continue to use it (passing via the other network) or
wait until the MS gains coverage again. Working below IP
(as the DS does) keeps the system very neat and totally
conformant with the current IP standards.
10. Conclusions and further work
In this paper we have shown that seamless continuity of
services and applications between 3G networks and
WLANs can be achieved in a very easy way if a proper
interworking architecture is considered. We consider a
primary network and introduce HN management components
in the 3G core. The system does not need complete
inter-system vertical handovers because the user never
leaves the primary network for control purposes making the
switching times very small. There is only data vertical
handovers and consequently no need for control procedures
in secondary networks.
The introduction of a new component in the core does not
disrupt the standardization work done so far because it
interacts with the existent components following the same
behavior as the SGSN does today. The major modifications
are a physical interface at the SGSN, an update of software
to enable it to use the HNAC, and the enlargement of
possible MS status in the HSS database.
As issues for further work it is important to study which
QoS parameters might be important to help in the decision
of using a certain HN for a certain service; and which
services/applications could be interesting to build on higher
layers of the HNAC to manage the intermittent appearances
of MS in WLAN islands.

1064
P. Pinto et al. / Computer Communications 29 (2006) 1055–1064
Acknowledgements
The authors would like to thank João Reis and Bernardo
Alves for their work in helping simulating the system.
References
[1] W. Lu, et al., 4G mobile communications: toward open wireless
architecture, IEEE Wireless Communication 11 (2004) 4–6.
[2] GPP TR 22.934 v6.2.0, Feasibility study on 3GPP system to WLAN
interworking (Release 6), 2003.
[3] GPP TR 23.234 v6.1.0, 3GPP system to WLAN interworking, System
description (Release 6), 2004.
[4] A. Salkintzis, et al., WLAN-GPRS integration for next-generation
mobile data networks, IEEE Wireless Communication 9 (2002) 112–
124.
[5] A. Salkintzis, Interworking techniques and architectures for
WLAN/3G integration toward 4G mobile data networks, IEEE
Wireless Communication 11 (2004) 50–61.
[6] M. Steem, R. Katz, Vertical Handoffs in wireless overlay networks,
Mobile Networks and Applications 3 (1998) 335–350.
[7] G. Wu, MIRAI architecture for heterogeneous network, IEEE
Communications Magazine (2002) 126–134.
[8] Pinto, P., Bernardo, L., Sobral, P., UMTS-WLAN Service Integration
at Core Network Level, Third European Conference on Universal
Multiservice Networks (ECUMN’04), LNCS, Springer, Heidelberg,
vol 3262/2004, DOI: 10.1007/b101785.
[9] J. Arkko, H. Haverinen, EAP AKA Authentication, Internet Draft,
draft-arkko-pppext-eap-aka-12.txt, 2004.
[10] L. Blunk, J. Vollbrecht, PPP extensible authentication protocol, IETF
RFC 2284 (1998).
[11] P. Mockapetris, Domain names—implementation and specification,
IETF RFC 1035 (1987).
[12] A. Lindgren, Support for the PCF mode of IEEE 802.11 for ns-2.1b8,
http://www.sm.luth.se/~dugdale/index/software.shtml/.
[13] EURANE—Enhanced UMTS Radio Access Network Extensions for
ns-2 home page, http://www.ti-wmv.nl/eurane/.
[14] J. Song, S. Lee, D. Cho, Hybrid coupling scheme for UMTS and
wireless LAN interworking, Vehicular Technology Conference 4
(2003) 2247–2251.
[15] S. Tsao, C. Lin, “VGSN: a gateway approach to interconnect
UMTS/WLAN networks”, the 13th IEEE Int, Symp. on Personal,
Indoor and Mobile Radio Communications, 1, Sept. 2002 (2002)
275–279.