U.S. patent application number 11/927599 was filed with the patent office on 2008-12-11 for method and apparatus for performing network based service access control for femtocells.
Invention is credited to Michael D. Gallaghar, Rajeev Gupta, Amit Khetawat, Milan Markovic, Patrick Tao.
Application Number | 20080305792 11/927599 |
Document ID | / |
Family ID | 39225607 |
Filed Date | 2008-12-11 |
United States Patent
Application |
20080305792 |
Kind Code |
A1 |
Khetawat; Amit ; et
al. |
December 11, 2008 |
Method and Apparatus for Performing Network Based Service Access
Control for Femtocells
Abstract
Some embodiments are implemented in a communication system that
includes a first wireless communication system and a second
wireless communication system that includes a Femtocell access
point (FAP) and a network controller that can communicatively
couple the FAP to the first wireless communication system. In some
embodiments, the network controller can communicatively couple to
the first wireless communication system through a UTRAN Iu
interface. Some embodiments provide a resource management method
that determines that a user equipment (UE) has roved in a region
serviced by the FAP. The FAP includes a generic access resource
control (GA-RC) protocol sub-layer. The method creates a separate
GA-RC state dedicated to the UE in the GA-RC protocol sub-layer.
The method also sets the GA-RC state dedicated to the UE to a
deregistered state to indicate that the UE is not registered to use
the services of the second wireless communication system.
Inventors: |
Khetawat; Amit; (San Jose,
CA) ; Markovic; Milan; (Pleasanton, CA) ;
Gallaghar; Michael D.; (San Jose, CA) ; Tao;
Patrick; (San Jose, CA) ; Gupta; Rajeev;
(Sunnyvale, CA) |
Correspondence
Address: |
ADELI & TOLLEN, LLP
1875 CENTURY PARK EAST, SUITE 1360
LOS ANGELES
CA
90067
US
|
Family ID: |
39225607 |
Appl. No.: |
11/927599 |
Filed: |
October 29, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11859762 |
Sep 22, 2007 |
|
|
|
11927599 |
|
|
|
|
60826700 |
Sep 22, 2006 |
|
|
|
60869900 |
Dec 13, 2006 |
|
|
|
60911862 |
Apr 13, 2007 |
|
|
|
60949826 |
Jul 13, 2007 |
|
|
|
60884889 |
Jan 14, 2007 |
|
|
|
60893361 |
Mar 6, 2007 |
|
|
|
60884017 |
Jan 8, 2007 |
|
|
|
60911864 |
Apr 13, 2007 |
|
|
|
60862564 |
Oct 23, 2006 |
|
|
|
60949853 |
Jul 14, 2007 |
|
|
|
60954549 |
Aug 7, 2007 |
|
|
|
Current U.S.
Class: |
455/435.1 |
Current CPC
Class: |
H04W 12/069 20210101;
H04W 92/04 20130101; H04W 12/122 20210101; H04W 88/12 20130101;
H04W 84/045 20130101; H04W 92/02 20130101; H04W 12/041
20210101 |
Class at
Publication: |
455/435.1 |
International
Class: |
H04Q 7/20 20060101
H04Q007/20 |
Claims
1-20. (canceled)
21. A method of authorizing a Femtocell access point (FAP) of a
first communication system, the FAP is for communicatively coupling
a user equipment with a second communication network, the method
comprising: a) receiving a request for registering the FAP with the
first communication system, the request comprising a set of
identifications of the FAP; b) based on said information,
determining whether the FAP is authorized to use services of the
first communication network; and c) registering the FAP with the
first communication network when the FAP is determined to be
authorized to use the services of the first communication
network.
22. The method of claim 21, wherein the set of identifications of
the FAP comprises an international mobile subscriber identity
(IMSI) of the FAP.
23. The method of claim 21, wherein the set of identifications of
the FAP comprises an access point identification (AP-ID) of the
FAP.
24. The method of claim 21, wherein the set of identifications of
the FAP comprises a media access control (MAC) address of the
FAP.
25. The method of claim 21, wherein the set of identifications of
the FAP comprises information identifying a service region of the
second communication network.
26. The method of claim 25, wherein when the FAP detects coverage
of a particular cell of the second communication network, the
information identifying the service region of the second
communication network comprises a location area identification
(LAI) and a cell identification of the particular cell of the
second communication network.
27. The method of claim 26, wherein when the FAP does not detects
coverage of any cell of the second communication network, the
information identifying the service region of the second
communication network comprises a location area identification
(LAI) and a cell identification of a last cell of the second
communication network with which the FAP had successfully
registered.
28. The method of claim 21, wherein request is sent by the FAP to a
network controller of the first communication network, wherein the
network controller is for communicatively coupling the FAP with the
second communication network.
29. A computer readable medium storing a computer for authorizing a
Femtocell access point (FAP) of a first communication system, the
FAP is for communicatively coupling a user equipment with a second
communication network, the computer program comprising sets of
instructions for: a) receiving a request for registering the FAP
with the first communication system, the request comprising a set
of identifications of the FAP; b) based on said information,
determining whether the FAP is authorized to use services of the
first communication network; and c) registering the FAP with the
first communication network when the FAP is determined to be
authorized to use the services of the first communication
network.
30. The computer readable medium of claim 29, wherein the set of
identifications of the FAP comprises an international mobile
subscriber identity (IMSI) of the FAP.
31. The computer readable medium of claim 29, wherein the set of
identifications of the FAP comprises an access point identification
(AP-ID) of the FAP.
32. The computer readable medium of claim 29, wherein the set of
identifications of the FAP comprises a media access control (MAC)
address of the FAP.
33. The computer readable medium of claim 29, wherein the set of
identifications of the FAP comprises information identifying a
service region of the second communication network.
34. The computer readable medium of claim 29, wherein when the FAP
detects coverage of a particular cell of the second communication
network, the information identifying the service region of the
second communication network comprises a location area
identification (LAI) and a cell identification of the particular
cell of the second communication network.
35. The computer readable medium of claim 34, wherein when the FAP
does not detects coverage of any cell of the second communication
network, the information identifying the service region of the
second communication network comprises a location area
identification (LAI) and a cell identification of a last cell of
the second communication network with which the FAP had
successfully registered.
36. The computer readable medium of claim 29, wherein request is
sent by the FAP to a network controller of the first communication
network, wherein the network controller is for communicatively
coupling the FAP with the second communication network.
37. A method of authorizing a Femtocell access point (FAP) of a
first communication system, the FAP is for communicatively coupling
a user equipment with a second communication network, the method
comprising: a) receiving a request for registering the FAP with the
first communication system; and b) rejecting said FAP request for
registering with the first communication network when the FAP is in
a service region of the second communication network where FAP
access is not allowed.
38. The method of claim 37, wherein said rejecting comprises
sending a register reject message from to the FAP, the register
reject message comprising a reject cause.
39. The method of claim 38, wherein the reject cause is location
not allowed.
40. A method of authorizing user equipment (UE) to use services of
a first communication system comprising a Femtocell access point
(FAP), the FAP is for communicatively coupling the UE with a second
communication network, the method comprising: a) receiving at a
server of the first communication network a request for registering
the UE with the first communication system, said request sent from
the FAP to the said server; the request comprising an
identification of the UE; and b) rejecting the request when the UE
is determined not to be authorized to register with the FAP.
41. The method of claim 40, wherein the request comprises an
international mobile subscriber identity (IMSI) of the UE.
42. The method of claim 40, wherein the request comprises an
international mobile subscriber identity (IMSI) of the FAP.
43. The method of claim 40, wherein the request comprises an access
point identification (AP-ID) of the FAP.
44. The method of claim 40, wherein the request comprises a media
access control (MAC) address of the FAP.
Description
CLAIM OF BENEFIT TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application 60/826,700, entitled "Radio Access Network--Generic
Access to the Iu Interface for Femtocells", filed Sep. 22, 2006;
U.S. Provisional Application 60/869,900, entitled "Generic Access
to the Iu Interface for Femtocells", filed Dec. 13, 2006; U.S.
Provisional Application 60/911,862, entitled "Generic Access to the
Iu Interface for Femtocells", filed Apr. 13, 2007; U.S. Provisional
Application 60/949,826, entitled "Generic Access to the Iu
Interface", filed Jul. 13, 2007; U.S. Provisional Application
60/884,889, entitled "Methods to Provide Protection against service
Theft for Femtocells", filed Jan. 14, 2007; U.S. Provisional
Application 60/893,361, entitled "Methods to Prevent Theft of
Service for Femtocells Operating in Open Access Mode", filed Mar.
6, 2007; U.S. Provisional Application 60/884,017, entitled "Generic
Access to the Iu Interface for Femtocell--Stage 3", filed Jan. 8,
2007; U.S. Provisional Application 60/911,864, entitled "Generic
Access to the Iu Interface for Femtocell--Stage 3", filed Apr. 13,
2007; U.S. Provisional Application 60/862,564, entitled
"E-UMA--Generic Access to the Iu Interface", filed Oct. 23, 2006;
U.S. Provisional Application 60/949,853, entitled "Generic Access
to the Iu Interface", filed Jul. 14, 2007; and U.S. Provisional
Application 60/954,549, entitled "Generic Access to the Iu
Interfaces--Stage 2 Specification", filed Aug. 7, 2007. The
contents of each of the above mentioned provisional applications
are hereby incorporated by reference.
FIELD OF THE INVENTION
[0002] The invention relates to telecommunication. More
particularly, this invention relates to a technique for seamlessly
integrating voice and data telecommunication services across a
licensed wireless system and a short-ranged licensed wireless
system.
BACKGROUND OF THE INVENTION
[0003] Licensed wireless systems provide mobile wireless
communications to individuals using wireless transceivers. Licensed
wireless systems refer to public cellular telephone systems and/or
Personal Communication Services (PCS) telephone systems. Wireless
transceivers include cellular telephones, PCS telephones,
wireless-enabled personal digital assistants, wireless modems, and
the like.
[0004] Licensed wireless systems utilize wireless signal
frequencies that are licensed from governments. Large fees are paid
for access to these frequencies. Expensive base station (BS)
equipment is used to support communications on licensed
frequencies. Base stations are typically installed approximately a
mile apart from one another (e.g., cellular towers in a cellular
network). The wireless transport mechanisms and frequencies
employed by typical licensed wireless systems limit both data
transfer rates and range. As a result, the quality of service
(voice quality and speed of data transfer) in licensed wireless
systems is considerably inferior to the quality of service afforded
by landline (wired) connections. Thus, the user of a licensed
wireless system pays relatively high fees for relatively low
quality service.
[0005] Landline (wired) connections are extensively deployed and
generally perform at a lower cost with higher quality voice and
higher speed data services. The problem with landline connections
is that they constrain the mobility of a user. Traditionally, a
physical connection to the landline was required.
[0006] In the past few years, the use of unlicensed wireless
communication systems to facilitate mobile access to landline-based
networks has seen rapid growth. For example, such unlicensed
wireless systems may support wireless communication based on the
IEEE 802.11a, b or g standards (WiFi), or the Bluetooth.RTM.
standard. The mobility range associated with such systems is
typically on the order of 100 meters or less. A typical unlicensed
wireless communication system includes a base station comprising a
wireless access point (AP) with a physical connection (e.g.,
coaxial, twisted pair, or optical cable) to a landline-based
network. The AP has a RF transceiver to facilitate communication
with a wireless handset that is operative within a modest distance
of the AP, wherein the data transport rates supported by the WiFi
and Bluetooth.RTM. standards are much higher than those supported
by the aforementioned licensed wireless systems. Thus, this option
provides higher quality services at a lower cost, but the services
only extend a modest distance from the base station.
[0007] Currently, technology is being developed to integrate the
use of licensed and unlicensed wireless systems in a seamless
fashion, thus enabling a user to access, via a single handset, an
unlicensed wireless system when within the range of such a system,
while accessing a licensed wireless system when out of range of the
unlicensed wireless system. The unlicensed wireless communication
systems, however, require the use of dual-mode wireless
transceivers to communicate with the licensed system over the
licensed wireless frequencies and with the unlicensed system over
the unlicensed wireless frequencies. The use of such dual-mode
transceivers requires the service providers to upgrade the existing
subscribers' transceivers which operate only on licensed wireless
frequencies to dual-mode transceivers. Therefore, there is a need
in the art to develop a system that provides the benefits of the
systems described above, without the need for dual-mode
transceivers.
SUMMARY OF THE INVENTION
[0008] Some embodiments are implemented in a communication system
that includes a first wireless communication system and a second
wireless communication system that includes a Femtocell access
point (FAP) and a network controller that can communicatively
couple the FAP to the first wireless communication system.
[0009] In some embodiments, the network controller can
communicatively couple to the first wireless communication system
through a UTRAN Iu interface. In some embodiments, the FAP can
communicatively couple to a user equipment using a short-range
licensed wireless frequency.
[0010] Some embodiments provide a resource management method that
determines that a user equipment (UE) has roved in a region
serviced by the FAP. The FAP includes a generic access resource
control (GA-RC) protocol sub-layer. The method creates a separate
GA-RC state dedicated to the UE in the GA-RC protocol sub-layer.
The method also sets the GA-RC state dedicated to the UE to a
deregistered state to indicate that the UE is not registered to use
the services of the second wireless communication system.
[0011] Some embodiments provide method that determines whether a UE
has roved-out of the second communication system. The method
receives a periodic message at the FAP from the UE. When the FAP
fails to receive a pre-determined number of the periodic messages,
the method sends a deregister message to the network controller
over a unique connection between the FAP and the network controller
which is dedicated to the UE and also releases the dedicated
connection.
[0012] Some embodiments provide a method of that releases resources
after the loss of connectivity. The method sends a periodic message
from the FAP to the network controller over a connection between
the FAP and the network controller to determine whether the
connection is lost. When the FAP determines that the connection is
lost, the FAP deregisters a user equipment (UE) that is
communicatively coupled with the FAP and forces the UE to perform a
cell reselection.
[0013] Some embodiments provide a method that registers a Femtocell
access point (FAP). The method sends a register request message
that includes a registration type from the FAP to the network
controller. The registration type identifies the FAP as a device to
be registered with the network controller. When the register
request message is acceptable by the network controller, the FAP
receives a register accept message.
[0014] Some embodiments provide a method for performing discovery.
The method sends a discovery request message that includes a
licensed wireless cell information to a provisioning network
controller. The method receives a discovery accept message at the
FAP. The discovery accept message includes identification of a
default network controller determined based on the cell
information. The discovery accept message is sent by the
provisioning network controller when the provisioning network
controller determines that the provisioning network controller can
accept the discovery request message.
[0015] Some embodiments provide a method of performing a user
equipment (UE) registration. The method establishes a unique
connection dedicated to the UE between the FAP and the network
controller. The method receives a register request message at the
network controller from the FAP through the dedicated
connection.
[0016] Some embodiments provide a security control method. The
method receives a security mode command that includes a set of
security keys and a set of security algorithms at the FAP from the
network controller, the set of security keys and the set of
security algorithms are received at the network controller from the
first wireless communication system. The method determines the
integrity of a set of messages that are exchanged between the FAP
and a user equipment (UE) that is communicatively coupled to the
FAP through an air interface by using the set of security keys and
the set of security algorithms.
[0017] Some embodiments provide method of providing security. The
method establishes a secure tunnel between the FAP and the network
controller. The method communicatively couples the FAP and several
user equipments (UEs) to the network controller by using the secure
tunnel. The UEs are communicatively coupled to the FAP through an
air interface.
[0018] Some embodiments provide a method of preventing theft of
service. The method creates an authorized session that includes a
session identity for a first user equipment (UE). The session is
for communicatively coupling the first UE with the first wireless
communication system through the FAP. The first UE is recognized by
the first wireless communication system as an authorized UE to use
the FAP. The method rejects a request by the FAP to register a
second UE when the identity of the second UE does not match any
identity in the set of first UE identities. The rejected request
includes the session identity of the authorized session and the
identity of the second UE. The second UE is not recognized by the
first wireless communication system as an authorized UE to use the
FAP.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] The novel features of the invention are set forth in the
appended claims. However, for purpose of explanation, several
embodiments of the invention are set forth in the following
figures.
[0020] FIG. 1 illustrates an integrated communication system (ICS)
of some embodiments.
[0021] FIG. 2 illustrates several applications of an ICS in some
embodiments.
[0022] FIG. 3 illustrates the overall A/Gb-mode GAN functional
architecture of some embodiments.
[0023] FIG. 4 illustrates the overall Iu-mode GAN functional
architecture of some embodiments.
[0024] FIG. 5 illustrates the Femtocell functional architecture of
some embodiments.
[0025] FIG. 6 illustrates Femtocell network architecture of some
embodiments with an asynchronous transfer mode (ATM) interface
towards the core network.
[0026] FIG. 7 illustrates Femtocell network architecture of some
embodiments with IP interface towards the core network.
[0027] FIG. 8 illustrates CS Domain Control Plane Architecture of
some embodiments.
[0028] FIG. 9 illustrates CS Domain User Plane Protocol
Architecture of some embodiments.
[0029] FIG. 10 illustrates PS Domain Control Plane Architecture of
some embodiments.
[0030] FIG. 11 illustrates PS Domain User Plane Protocol
Architecture of some embodiments.
[0031] FIG. 12 illustrates the state diagram for Generic Access in
the FAP of some embodiments.
[0032] FIG. 13 illustrates the state diagram in some embodiments
for GA-CSR in the FAP for each UE.
[0033] FIG. 14 illustrates the state diagram in some embodiments
for GA-PSR in the FAP for each UE.
[0034] FIG. 15 illustrates FAP initiated GA-CSR connection
establishment in some embodiments.
[0035] FIG. 16 illustrates GA-CSR connection release of some
embodiments.
[0036] FIG. 17 illustrates FAP initiated GA-PSR connection
establishment of some embodiments.
[0037] FIG. 18 illustrates GA-PSR connection release in some
embodiments.
[0038] FIG. 19 illustrates FAP power on discovery procedure of some
embodiments.
[0039] FIG. 20 illustrates FAP power on registration procedure in
some embodiments.
[0040] FIG. 21 illustrates the messages associated with the FAP
initiated synchronization procedure in some embodiments.
[0041] FIG. 22 illustrates UE registration in some embodiments.
[0042] FIG. 23 illustrates UE Rove out in some embodiments.
[0043] FIG. 24 illustrates a scenario where the UE powers down and
performs an IMSI detach in some embodiments.
[0044] FIG. 25 illustrates a scenario for loss of Up interface
connectivity in some embodiments.
[0045] FIG. 26 illustrates FAP-initiated register update scenario
of some embodiments.
[0046] FIG. 27 illustrates INC-initiated register update scenario
in some embodiments.
[0047] FIG. 28 illustrates the FAP initiated synchronization
procedure in some embodiments.
[0048] FIG. 29 illustrates voice bearer establishment procedures
(for MO/MT calls, using Iu-UP over AAL2) in some embodiments.
[0049] FIG. 30 illustrates the mobile originated mobile-to-PSTN
call in some embodiments.
[0050] FIG. 31 illustrates a mobile terminated PSTN-to-mobile call
in some embodiments.
[0051] FIG. 32 illustrates call release by Femtocell subscriber in
some embodiments.
[0052] FIG. 33 illustrates an example of relay of DTAP
supplementary service messages in some embodiments.
[0053] FIG. 34 illustrates FAP initiated GA-PSR Transport Channel
activation in some embodiments.
[0054] FIG. 35 illustrates FAP initiated Transport Channel
deactivation in some embodiments.
[0055] FIG. 36 illustrates network initiated Transport Channel
Activation for user data service in some embodiments.
[0056] FIG. 37 illustrates network initiated Transport Channel
deactivation in some embodiments.
[0057] FIG. 38 illustrates Femtocell User Plane Data Transport
procedures in some embodiments.
[0058] FIG. 39 illustrates Uplink Control Plane Data Transport of
some embodiments.
[0059] FIG. 40 illustrates Downlink Control Plane Data Transport of
some embodiments.
[0060] FIG. 41 illustrates the protocol architecture for CS mode
SMS in some embodiments.
[0061] FIG. 42 illustrates the GAN protocol architecture for packet
mode SMS in some embodiments.
[0062] FIG. 43 illustrates a mobile originated SMS transfer via GAN
circuit mode in some embodiments.
[0063] FIG. 44 illustrates a CS mode mobile terminated SMS transfer
via Femtocell in some embodiments.
[0064] FIG. 45 illustrates a service area based routing scenario of
some embodiments.
[0065] FIG. 46 illustrates GAN Femtocell security mechanisms in
some embodiments.
[0066] FIG. 47 illustrates EAP-SIM authentication procedure in some
embodiments.
[0067] FIG. 48 illustrates EAP-AKA authentication procedure of some
embodiments.
[0068] FIG. 49 illustrates the message flow for security mode
control in some embodiments.
[0069] FIG. 50 illustrates the AKA procedure used for mutual
authentication in some embodiments.
[0070] FIG. 51 illustrates the high level procedure which can
result in theft of service by a rogue FAP.
[0071] FIG. 52 illustrates the Femtocell service theft prevention
approach of some embodiments.
[0072] FIG. 53 illustrates the Femtocell service theft prevention
in some embodiments.
[0073] FIG. 54 illustrates the Service Access Control for new FAP
connecting to Femtocell network in some embodiments.
[0074] FIG. 55 illustrates the Service Access Control for the FAP
getting redirected in Femtocell network in some embodiments.
[0075] FIG. 56 illustrates the Service Access Control for FAP
registering in restricted UMTS coverage area in some
embodiments.
[0076] FIG. 57 illustrates the Service Access Control for
Unauthorized UE accessing authorized FAP in some embodiments.
[0077] FIG. 58 conceptually illustrates a computer system with
which some embodiments are implemented.
DETAILED DESCRIPTION OF THE INVENTION
[0078] In the following detailed description of the invention,
numerous details, examples, and embodiments of the invention are
set forth and described. However, it will be clear and apparent to
one skilled in the art that the invention is not limited to the
embodiments set forth and that the invention may be practiced
without some of the specific details and examples discussed.
[0079] Throughout the following description, acronyms commonly used
in the telecommunications industry for wireless services are
utilized along with acronyms specific to the present invention. A
table of acronyms used in this application is included in Section
XV.
[0080] Some embodiments are implemented in a communication system
that includes a first wireless communication system and a second
wireless communication system that includes a Femtocell access
point (FAP) and a network controller that can communicatively
couple the FAP to the first wireless communication system.
[0081] In some embodiments, the network controller can
communicatively couple to the first wireless communication system
through a UTRAN Iu interface. In some embodiments, the FAP can
communicatively couple to a user equipment using a short-range
licensed wireless frequency.
[0082] Some embodiments provide a resource management method that
determines that a user equipment (UE) has roved in a region
serviced by the FAP. The FAP includes a generic access resource
control (GA-RC) protocol sub-layer. The method creates a separate
GA-RC state dedicated to the UE in the GA-RC protocol sub-layer.
The method also sets the GA-RC state dedicated to the UE to a
deregistered state to indicate that the UE is not registered to use
the services of the second wireless communication system.
[0083] Some embodiments provide method that determines whether a UE
has roved-out of the second communication system. The method
receives a periodic message at the FAP from the UE. When the FAP
fails to receive a pre-determined number of the periodic messages,
the method sends a deregister message to the network controller
over a unique connection between the FAP and the network controller
which is dedicated to the UE and also releases the dedicated
connection.
[0084] Some embodiments provide a method of that releases resources
after the loss of connectivity. The method sends a periodic message
from the FAP to the network controller over a connection between
the FAP and the network controller to determine whether the
connection is lost. When the FAP determines that the connection is
lost, the FAP deregisters a user equipment (UE) that is
communicatively coupled with the FAP and forces the UE to perform a
cell reselection.
[0085] Some embodiments provide a method that registers a Femtocell
access point (FAP). The method sends a register request message
that includes a registration type from the FAP to the network
controller. The registration type identifies the FAP as a device to
be registered with the network controller. When the register
request message is acceptable by the network controller, the FAP
receives a register accept message.
[0086] Some embodiments provide a method for performing discovery.
The method sends a discovery request message that includes a
licensed wireless cell information to a provisioning network
controller. The method receives a discovery accept message at the
FAP. The discovery accept message includes identification of a
default network controller determined based on the cell
information. The discovery accept message is sent by the
provisioning network controller when the provisioning network
controller determines that the provisioning network controller can
accept the discovery request message.
[0087] Some embodiments provide a method of performing a user
equipment (UE) registration. The method establishes a unique
connection dedicated to the UE between the FAP and the network
controller. The method receives a register request message at the
network controller from the FAP through the dedicated
connection.
[0088] Some embodiments provide a security control method. The
method receives a security mode command that includes a set of
security keys and a set of security algorithms at the FAP from the
network controller, the set of security keys and the set of
security algorithms are received at the network controller from the
first wireless communication system. The method determines the
integrity of a set of messages that are exchanged between the FAP
and a user equipment (UE) that is communicatively coupled to the
FAP through an air interface by using the set of security keys and
the set of security algorithms.
[0089] Some embodiments provide method of providing security. The
method establishes a secure tunnel between the FAP and the network
controller. The method communicatively couples the FAP and several
user equipments (UEs) to the network controller by using the secure
tunnel. The UEs are communicatively coupled to the FAP through an
air interface.
[0090] Some embodiments provide a method of preventing theft of
service. The method creates an authorized session that includes a
session identity for a first user equipment (UE). The session is
for communicatively coupling the first UE with the first wireless
communication system through the FAP. The first UE is recognized by
the first wireless communication system as an authorized UE to use
the FAP. The method rejects a request by the FAP to register a
second UE when the identity of the second UE does not match any
identity in the set of first UE identities. The rejected request
includes the session identity of the authorized session and the
identity of the second UE. The second UE is not recognized by the
first wireless communication system as an authorized UE to use the
FAP.
[0091] Several more detailed embodiments of the invention are
described in sections below. Specifically, Section I describes the
overall integrated communication system in which some embodiments
are incorporated. The discussion in Section I is followed by a
discussion of the system architecture of a Femtocell system in
Section II. Next, Section III describes the protocol architecture
of the Femtocell system. Section IV then describes the resource
management procedures of the Femtocell system in some embodiments.
Next, Section V presents the mobility management functions of the
Femtocell system in some embodiments.
[0092] Next, Section VI describes the call management procedures of
the Femtocell system. This section is followed by Section VII which
describes the packet services of the Femtocell system in some
embodiments. Error handling procedures are described in Section
VIII. Lists of messages and information elements used in different
embodiments are provided in Section IX. Short Message Services
support of the Femtocell system is described in Section X followed
by the description of the emergency services in Section XI.
[0093] The Femtocell system security functions are described in
Section XII. This description is followed by Femtocell system
service access control discussed in Section XIII. Next, Section XIV
description of a computer system with which some embodiments of the
invention are implemented. Finally, Section XV lists the
abbreviations used.
I. OVERALL SYSTEM
[0094] A. Integrated Communication Systems (ICS)
[0095] FIG. 1 illustrates an integrated communication system (ICS)
architecture 100 in accordance with some embodiments of the present
invention. ICS architecture 100 enables user equipment (UE) 102 to
access a voice and data network 165 via either a licensed air
interface 106 or an ICS access interface 110 through which
components of the licensed wireless core network 165 are
alternatively accessed. In some embodiments, a communication
session through either interface includes voice services, data
services, or both.
[0096] The mobile core network 165 includes one or more Home
Location Registers (HLRs) 150 and databases 145 for subscriber
authentication and authorization. Once authorized, the UE 102 may
access the voice and data services of the mobile core network 165.
In order to provide such services, the mobile core network 165
includes a mobile switching center (MSC) 160 for providing access
to the circuit switched services (e.g., voice and data). Packet
switched services are provided for through a Serving GPRS (General
Packet Radio Service) Support Node (SGSN) 155 in conjunction with a
gateway such as the Gateway GPRS Support Node (GGSN) 157.
[0097] The SGSN 155 is typically responsible for delivering data
packets from and to the GGSN 157 and the user equipment within the
geographical service area of the SGSN 155. Additionally, the SGSN
155 may perform functionality such as mobility management, storing
user profiles, and storing location information. However, the
actual interface from the mobile core network 165 to various
external data packet services networks (e.g., public Internet) is
facilitated by the GGSN 157. As the data packets originating from
the user equipment typically are not structured in the format with
which to access the external data networks, it is the role of the
GGSN 157 to act as the gateway into such packet services networks.
In this manner, the GGSN 157 provides addressing for data packets
passing to and from the UE 102 and the external packet services
networks (not shown). Moreover, as the user equipment of a licensed
wireless network traverses multiple service regions and thus
multiple SGSNs, it is the role of the GGSN 157 to provide a static
gateway into the external data networks.
[0098] In the illustrated embodiment, components common to a UMTS
Terrestrial Radio Access Network (UTRAN), based cellular network
that includes multiple base stations referred to as Node Bs 180 (of
which only one is shown for simplicity) that facilitate wireless
communication services for various user equipment 102 via
respective licensed radio links 106 (e.g., radio links employing
radio frequencies within a licensed bandwidth). However, one of
ordinary skill in the art will recognize that in some embodiments,
the licensed wireless network may include other components such the
GSM/EDGE Radio Access Network (GERAN). An example of a system using
A and Gb interfaces to access GERAN is shown in FIG. 3 described
further below.
[0099] The licensed wireless channel 106 may comprise any licensed
wireless service having a defined UTRAN or GERAN interface protocol
(e.g., Iu-cs and Iu-ps interfaces for UTRAN or A and Gb interfaces
for GERAN) for a voice/data network. The UTRAN 185 typically
includes at least one Node B 180 and a Radio Network Controller
(RNC) 175 for managing the set of Node Bs 180. Typically, the
multiple Node Bs 180 are configured in a cellular configuration
(one per each cell) that covers a wide service area. A licensed
wireless cell is sometimes referred to as a macro cell which is a
logical term used to reference, e.g., the UMTS radio cell (i.e., 3G
cell) under Node-B/RNC which is used to provide coverage typically
in the range of tens of kilometers. Also, the UTRAN or GERAN is
sometimes referred to as a macro network.
[0100] Each RNC 175 communicates with components of the core
network 165 through a standard radio network controller interface
such as the Iu-cs and Iu-ps interfaces depicted in FIG. 1. For
example, a RNC 175 communicates with MSC 160 via the UTRAN Iu-cs
interface for circuit switched services. Additionally, the RNC 175
communicates with SGSN 155 via the UTRAN Iu-ps interface for packet
switched services through GGSN 157. Moreover, one of ordinary skill
in the art will recognize that in some embodiments, other networks
with other standard interfaces may apply. For example, the RNC 175
in a GERAN network is replaced with a Base Station Controller (BSC)
that communicates with the MSC 160 via an A interface for the
circuit switched services and the BSC communicates with the SGSN
via a Gb interface of the GERAN network for packet switched
services.
[0101] In some embodiments of the ICS architecture, the user
equipment 102 use the services of the mobile core network (CN) 165
via a second communication network facilitated by the ICS access
interface 110 and a Generic Access Network Controller (GANC) 120
(also referred to as a Universal Network Controller or UNC).
[0102] In some embodiments, the voice and data services over the
ICS access interface 110 are facilitated via an access point 114
communicatively coupled to a broadband IP network 116. In some
embodiments, the access point 114 is a generic wireless access
point that connects the user equipment 102 to the ICS network
through an unlicensed wireless network 118 created by the access
point 114. In some other embodiments, the access point 114 is a
Femtocell access point (FAP) 114 communicatively coupled to a
broadband IP network 116. The FAP facilitates short-range licensed
wireless communication sessions 118 that operate independent of the
licensed communication session 106. In some embodiments, the GANC,
FAP, UE, and the area covered by the FAP are collectively referred
to as a Femtocell System. A Femtocell spans a smaller area
(typically few tens of meters) than a macro cell. In other words,
the Femtocell is a micro cell that has a range that is 100, 1000,
or more times less than a macro cell. In case of the Femtocell
system, the user equipment 102 connects to the ICS network through
a short-range licensed wireless network created by the FAP 114.
Signals from the FAP are then transmitted over the broadband IP
network 116.
[0103] The signaling from the UE 102 is passed over the ICS access
interface 110 to the GANC 120. After the GANC 120 performs
authentication and authorization of the subscriber, the GANC 120
communicates with components of the mobile core network 165 using a
radio network controller interface that is the same or similar to
the radio network controller interface of the UTRAN described
above, and includes a UTRAN Iu-cs interface for circuit switched
services and a UTRAN Iu-ps interface for packet switched services
(e.g., GPRS). In this manner, the GANC 120 uses the same or similar
interfaces to the mobile core network as a UTRAN Radio Access
Network Subsystem (e.g., the Node B 180 and RNC 175).
[0104] In some embodiments, the GANC 120 communicates with other
system components of the ICS system through one or more of several
other interfaces, which are (1) "Up", (2) "Wm", (3) "D'/Gr'", (4)
"Gn'", and (5) "S1". The "Up" interface is the standard interface
for session management between the UE 102 and the GANC 120. The
"Wm" interface is a standardized interface between the GANC 120 and
an Authorization, Authentication, and Accounting (AAA) Server 170
for authentication and authorization of the UE 102 into the ICS.
The "D'/Gr'" interface is the standard interface between the AAA
server 170 and the HLR 160. Optionally, some embodiments use the
"Gn'" interface which is a modified interface for direct
communications with the data services gateway (e.g., GGSN) of the
mobile core network. Some embodiments optionally include the "S1"
interface. In these embodiments, the "S1" interface provides an
authorization and authentication interface from the GANC 120 to an
AAA sever 140. In some embodiments, the AAA server 140 that
supports the S1 interface and the AAA server 170 that supports Wm
interface may be the same. More details of the S1 interface are
described in U.S. application Ser. No. 11/349,025, entitled
"Service Access Control Interface for an Unlicensed Wireless
Communication System", filed Feb. 6, 2006.
[0105] In some embodiments, the UE 102 must register with the GANC
120 prior to accessing ICS services. Registration information of
some embodiments includes a subscriber's International Mobile
Subscriber Identity (IMSI), a Media Access Control (MAC) address,
and a Service Set Identifier (SSID) of the serving access point as
well as the cell identity from the GSM or UTRAN cell upon which the
UE 102 is already camped (a UE is camped on a cell when the UE has
completed the cell selection/reselection process and has chosen a
cell; the UE monitors system information and, in most cases, paging
information). In some embodiments, the GANC 120 may pass this
information to the AAA server 140 to authenticate the subscriber
and determine the services (e.g., voice and data) available to the
subscriber. If approved by the AAA server 140 for access, the GANC
120 will permit the UE 102 to access voice and data services of the
ICS system.
[0106] These circuit switched and packet switched services are
seamlessly provided by the ICS to the UE 102 through the various
interfaces described above. In some embodiments, when data services
are requested by the UE 102, the ICS uses the optional Gn'
interface for directly communicating with a GGSN 157. The Gn'
interface allows the GANC 120 to avoid the overhead and latency
associated with communicating with the SGSN 155 over the Iu-ps
interface of the UTRAN or the Gb interface of the GSM core networks
prior to reaching the GGSN 157.
[0107] B. Applications of ICS
[0108] An ICS provides scalable and secure interfaces into the core
service network of mobile communication systems. FIG. 2 illustrates
several applications of an ICS in some embodiments. As shown,
homes, offices, hot spots, hotels, and other public and private
places 205 are connected to one or more network controllers 210
(such as the GANC 120 shown in FIG. 1) through the Internet 215.
The network controllers in turn connect to the mobile core network
220 (such as the core network 165 shown in FIG. 1).
[0109] FIG. 2 also shows several user equipments. These user
equipments are just examples of user equipments that can be used
for each application. Although in most examples only one of each
type of user equipments is shown, one of ordinary skill in the art
would realize that other type of user equipments can be used in
these examples without deviating from the teachings of the
invention. Also, although only one of each type of access points,
user equipment, or network controllers are shown, many such access
points, user equipments, or network controllers may be employed in
FIG. 2. For instance, an access point may be connected to several
user equipment, a network controller may be connected to several
access points, and several network controllers may be connected to
the core network. The following sub-sections provide several
examples of services that can be provided by an ICS.
[0110] 1. Wi-Fi
[0111] A Wi-Fi access point 230 enables a dual-mode cellular/Wi-Fi
UEs 260-265 to receive high-performance, low-cost mobile services
when in range of a home, office, or public Wi-Fi network. With
dual-mode UEs, subscribers can roam and handover between licensed
wireless communication system and Wi-Fi access and receive a
consistent set of services as they transition between networks.
[0112] 2. Femtocells
[0113] A Femtocell enables user equipments, such as standard mobile
stations 270 and wireless enabled computers 275 shown, to receive
low cost services using a short-range licensed wireless
communication sessions through a FAP 235.
[0114] 3. Terminal Adaptors
[0115] Terminal adaptors 240 allow incorporating fixed-terminal
devices such as telephones 245, Faxes 250, and other equipments
that are not wireless enabled within the ICS. As far as the
subscriber is concerned, the service behaves as a standard analog
fixed telephone line. The service is delivered in a manner similar
to other fixed line VoIP services, where a UE is connected to the
subscriber's existing broadband (e.g., Internet) service.
[0116] 4. WiMAX
[0117] Some licensed wireless communication system operators are
investigating deployment of WiMAX networks in parallel with their
existing cellular networks. A dual mode cellular/WiMAX UE 255
enables a subscriber to seamlessly transition between a cellular
network and such a WiMAX network through a WiMax access point
290.
[0118] 5. SoftMobiles
[0119] Connecting laptops 280 to broadband access at hotels and
Wi-Fi hot spots has become popular, particularly for international
business travelers. In addition, many travelers are beginning to
utilize their laptops and broadband connections for the purpose of
voice communications. Rather than using mobile phones to make calls
and pay significant roaming fees, they utilize SoftMobiles (or
SoftPhones) and VoIP services when making long distance calls.
[0120] To use a SoftMobile service, a subscriber would place a USB
memory stick 285 with an embedded SIM into a USB port of their
laptop 280. A SoftMobile client would automatically launch and
connect over IP to the mobile service provider. From that point on,
the subscriber would be able to make and receive mobile calls as if
she was in her home calling area.
[0121] Several examples of Integrated Communication Systems (ICS)
are given in the following sub-sections. A person of ordinary skill
in the art would realize that the teachings in these examples can
be readily combined. For instance, an ICS can be an IP based system
and have an A/Gb interface towards the core network while another
ICS can have a similar IP based system with an Iu interface towards
the core network.
[0122] C. Integrated Systems with A/Gb and/or Iu Interfaces Towards
the Core Network
[0123] FIG. 3 illustrates the A/Gb-mode Generic Access Network
(GAN) functional architecture of some embodiments. The GAN includes
one or more Generic Access Network Controllers (GANC) 310 and one
or more generic IP access networks 315. One or more UEs 305 (one is
shown for simplicity) can connect to a GANC 310 through a generic
IP access network 315. The GANC 310 has the capability to appear to
the core network 325 as a GSM/EDGE Radio Access Network (GERAN)
Base Station Controller (BSC). The GANC 310 includes a Security
Gateway (SeGW) 320 that terminates secure remote access tunnels
from the UE 305, providing mutual authentication, encryption and
data integrity for signaling, voice and data traffic.
[0124] The generic IP access network 315 provides connectivity
between the UE 305 and the GANC 310. The IP transport connection
extends from the GANC 310 to the UE 305. A single interface, the Up
interface, is defined between the GANC 310 and the UE 305.
[0125] The GAN co-exists with the GERAN and maintains the
interconnections with the Core Network (CN) 325 via the
standardized interfaces defined for GERAN. These standardized
interfaces include the A interface to Mobile Switching Center (MSC)
330 for circuit switched services, Gb interface to Serving GPRS
Support Node (SGSN) 335 for packet switched services, Lb interface
to Serving Mobile Location Center (SMLC) 350 for supporting
location services, and an interface to Cell Broadcast Center (CBC)
355 for supporting cell broadcast services. The transaction control
(e.g. Connection Management, CC, and Session Management, SM) and
user services are provided by the core network (e.g. MSC/VLR and
the SGSN/GGSN).
[0126] As shown, the SeGW 320 is connected to a AAA server 340 over
the Wm interface. The AAA server 340 is used to authenticate the UE
305 when it sets up a secure tunnel. Some embodiments require only
a subset of the Wm functionalities for the GAN application. In
these embodiments, as a minimum the GANC-SeGW shall support the Wm
authentication procedures.
[0127] FIG. 4 illustrates the Iu-mode Generic Access Network (GAN)
functional architecture of some embodiments. The GAN includes one
or more Generic Access Network Controllers (GANC) 410 and one or
more generic IP access networks 415. One or more UEs 405 (one is
shown for simplicity) can be connected to a GANC 410 through a
generic IP access network 415. In comparison with the GANC 310, the
GANC 410 has the capability to appear to the core network 425 as a
UMTS Terrestrial Radio Access Network (UTRAN) Radio Network
Controller (RNC). In some embodiments, the GANC has the expanded
capability of supporting both the Iu and A/Gb interfaces to
concurrently support both Iu-mode and A/Gb-mode UEs. Similar to the
GANC 310, the GANC 410 includes a Security Gateway (SeGW) 420 that
terminates secure remote access tunnels from the UE 405, providing
mutual authentication, encryption and data integrity for signaling,
voice and data traffic.
[0128] The generic IP access network 415 provides connectivity
between the UE 405 and the GANC 410. The IP transport connection
extends from the GANC 410 to the UE 405. A single interface, the Up
interface, is defined between the GANC 410 and the UE 405.
Functionality is added to this interface, over the UP interface
shown in FIG. 3, to support the Iu-mode GAN service.
[0129] The GAN co-exists with the UTRAN and maintains the
interconnections with the Core Network (CN) 425 via the
standardized interfaces defined for UTRAN. These standardized
interfaces include the Iu-cs interface to Mobile Switching Center
(MSC) 430 for circuit switched services, Iu-ps interface to Serving
GPRS Support Node (SGSN) 435 for packet switched services, Iu-pc
interface to Serving Mobile Location Center (SMLC) 450 for
supporting location services, and Iu-bc interface to Cell Broadcast
Center (CBC) 455 for supporting cell broadcast services. The
transaction control (e.g. Connection Management, CC, and Session
Management, SM) and user services are provided by the core network
(e.g. MSC/VLR and the SGSN/GGSN).
[0130] As shown, the SeGW 420 is connected to a AAA server 440 over
the Wm interface. The AAA server 440 is used to authenticate the UE
405 when it sets up a secure tunnel. Some embodiments require only
a subset of the Wm functionalities for the Iu mode GAN application.
In these embodiments, as a minimum the GANC-SeGW shall support the
Wm authentication procedures.
II. FEMTOCELL SYSTEM ARCHITECTURE
[0131] FIG. 5 illustrates the Femtocell system functional
architecture of some embodiments. As shown, many components of the
system shown in FIG. 5 are similar to components of FIG. 4. In
addition, the Femtocell system includes a Femtocell Access Point
(FAP) 560 which communicatively couples the UE 505 to the GANC 510
through the Generic IP Access Network 515. The interface between
the UE 505 and the FAP 560 is referred to as the Uu interface in
this disclosure. The UE 505 and the FAP 560 communicate through a
short-range wireless air interface using licensed wireless
frequencies. The GANC 510 is an enhanced version of the GANC 410
shown in FIG. 4. The Security Gateway (SeGW) 520 component of the
GANC 510 terminates secure remote access tunnels from the FAP 560,
providing mutual authentication, encryption and data integrity for
signaling, voice and data traffic.
[0132] The Femtocell Access Point (AP) Management System (AMS) 570
is used to manage a large number of FAPs. The AMS 570 functions
include configuration, failure management, diagnostics, monitoring
and software upgrades. The interface between the AMS 570 and the
FAP 560 is referred to as the S3 interface. The S3 interface
enables secure access to Femtocell access point management services
for FAPs. All communication between the FAPs and AMS is exchanged
via the Femtocell secure tunnel that is established between the FAP
and SeGW 520. As shown, the AMS 570 accesses to the AP/subscriber
databases (Femtocell DB) 575 which provides centralized data
storage facility for Femtocell AP (i.e., the FAP) and subscriber
information. Multiple Femtocell system elements may access
Femtocell DB via AAA server.
[0133] The IP Network Controller (INC) 565 component of the GANC
510 interfaces with the AAA/proxy server 540 through the S1
interface for provisioning of the FAP related information and
service access control. As shown in FIG. 5, the AAA/proxy server
540 also interfaces with the AP/subscriber databases 575.
[0134] A. ATM and IP Based Architectures
[0135] In some embodiments, the Femtocell system uses Asynchronous
Transfer Mode (ATM) based Iu (Iu-cs and Iu-ps) interfaces towards
the CN. In some embodiments, the Femtocell system architecture can
also support an IP based Iu (Iu-cs and Iu-ps) interface towards the
CN.
[0136] A person of ordinary skill in the art would realize that the
same examples can be readily applied to other types of ICS. For
instance, these examples can be used when the ICS access interface
110 (shown in FIG. 1) uses unlicensed frequencies (instead of
Femtocell's licensed frequencies), the access point 114 is a
generic WiFi access point (instead of a FAP), etc. Also, a person
of ordinary skill in the art would realize that the same examples
can be readily implemented using A/Gb interfaces (described above)
instead of Iu interfaces.
[0137] FIG. 6 illustrates the basic elements of the Femtocell
system architecture with Asynchronous Transfer Mode (ATM) based Iu
(Iu-cs and Iu-ps) interfaces towards the CN in some embodiments.
These elements include the user equipment (UE) 605, the FAP 610,
and the Generic Access Network Controller (GANC) 615, and the AMS
670.
[0138] For simplicity, only one UE and one FAP are shown. However,
each GANC can support multiple FAPs and each FAP in turn can
support multiple UEs. As shown, the GANC 615 includes an IP Network
Controller (INC) 625, a GANC Security Gateway (SeGW) 630, a GANC
Signaling Gateway 635, a GANC Media Gateway (MGW) 640, an ATM
Gateway (645). Elements of the Femtocell are described further
below.
[0139] FIG. 7 illustrates the basic elements of the Femtocell
system architecture with an IP based Iu (Iu-cs and Iu-ps) interface
towards the CN in some embodiments. For simplicity, only one UE and
one FAP are shown. However, each GANC can support multiple FAPs and
each FAP in turn can support multiple UEs. This option eliminates
the need for the GANC Signaling gateway 635 and also the ATM
gateway 645. Optionally for IP based Iu interface, the GANC Media
Gateway 640 can also be eliminated if the R4 MGW 705 in the CN can
support termination of voice data i.e. RTP frames as defined in
"Real-Time Transport Protocol (RTP) Payload Format and File Storage
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate
Wideband (AMR-WB) Audio Codecs", IETF RFC 3267, hereinafter "RFC
3267".
[0140] Also shown in FIGS. 6 and 7 are components of the licensed
wireless communication systems. These components are 3G MSC 650, 3G
SGSN 655, and other Core Network System (shown together) 665. The
3G MSC 650 provides a standard Iu-cs interface towards the GANC.
Another alternative for the MSC is shown in FIG. 7. As shown, the
MSC 750 is split up into a MSS (MSC Server) 775 for Iu-cs based
signaling and MGW 780 for the bearer path. R4 MSC 750 is a release
4 version of a 3G MSC with a different architecture i.e. R4 MSC is
split into MSS for control traffic and a MGW for handling the
bearer. A similar MSC can be used for the ATM architecture of FIG.
6. Both architectures shown in FIGS. 6 and 7 are also adaptable to
use any future versions of the MSC.
[0141] The 3G SGSN 655 provides packet services (PS) via the
standard Iu-ps interface. The SGSN connects to the INC 625 for
signaling and to the SeGW 630 for PS data. The AAA server 660
communicates with the SeGW 630 and supports the EAP-AKA and EAP-SIM
procedures used in IKEv2 over the Wm interface and includes a MAP
interface to the HLR/AuC. This system also supports the enhanced
service access control functions over the S1 interface.
[0142] For simplicity, in several diagrams throughout the present
application, only the INC component of the GANC is shown. Also,
whenever the INC is the relevant component of the GANC, references
to the INC and GANC are used interchangeably.
[0143] B. Functional Entities
[0144] 1. User Equipment (UE)
[0145] The UE includes the functions that are required to access
the Iu-mode GAN. In some embodiments, the UE additionally includes
the functions that are required to access the A/Gb-mode GAN. In
some embodiments, the User Equipment (UE) is a dual mode (e.g., GSM
and unlicensed radios) handset device with capability to switch
between the two modes. The user equipment can support either
Bluetooth.RTM. or IEEE 802.11 protocols. In some embodiments, the
UE supports an IP interface to the access point. In these
embodiments, the IP connection from the GANC extends all the way to
the UE. In some other embodiments, the User Equipment (UE) is a
standard 3G handset device operating over licensed spectrum of the
provider.
[0146] In some embodiments, the user equipment includes a cellular
telephone, smart phone, personal digital assistant, or computer
equipped with a subscriber identity mobile (SIM) card for
communicating over the licensed or unlicensed wireless networks.
Moreover, in some embodiments the computer equipped with the SIM
card communicates through a wired communication network.
[0147] Alternatively, in some embodiments the user equipment
includes a fixed wireless device providing a set of terminal
adapter functions for connecting Integrated Services Digital
Network (ISDN), Session Initiation Protocol (SIP), or Plain Old
Telephone Service (POTS) terminals to the ICS. Application of the
present invention to this type of device enables the wireless
service provider to offer the so-called landline replacement
service to users, even for user locations not sufficiently covered
by the licensed wireless network. Moreover, some embodiments of the
terminal adapters are fixed wired devices for connecting ISDN, SIP,
or POTS terminals to a different communication network (e.g., IP
network) though alternate embodiments of the terminal adapters
provide wireless equivalent functionality for connecting through
unlicensed or licensed wireless networks.
[0148] 2. Femtocell Access Point (FAP)
[0149] The FAP is a licensed access point which offers a standard
radio interface (Uu) for UE connectivity. The FAP provides radio
access network connectivity for the UE using a modified version of
the standard GAN interface (Up). In some embodiments, the FAP is
equipped with either a standard 3G USIM or a 2G SIM.
[0150] In accordance with some embodiments, the FAP 610 will be
located in a fixed structure, such as a home or an office building.
In some embodiments, the service area of the FAP includes an indoor
portion of a building, although it will be understood that the
service area may include an outdoor portion of a building or
campus.
[0151] 3. Generic Access Network Controller (GANC)
[0152] The GANC 510 is an enhanced version of the GANC defined in
"Generic access to the A/Gb interface; Stage 2", 3GPP TS 43.318
standard, hereinafter "TS 43.318 standard". The GANC appears to the
core network as a UTRAN Radio Network Controller (RNC). The GANC
includes a Security Gateway (SeGW) 520 and IP Network Controller
(INC) 565. In some embodiments (not shown in FIG. 5), the GANC also
includes GANC Signaling Gateway 635, a GANC Media Gateway (MGW)
640, and/or an ATM Gateway (645).
[0153] The SeGW 520 provides functions that are defined in TS
43.318 standard and "Generic access to the A/Gb interface; Stage
3", 3GPP TS 44.318 standard. The SeGW terminates secure access
tunnels from the FAP, providing mutual authentication, encryption
and data integrity for signaling, voice and data traffic. The SeGW
520 is required to support EAP-SIM and EAP-AKA authentication for
the FAP 560.
[0154] The INC 565 is the kay GANC element. In some embodiments,
the INC is front-ended with a load balancing router/switch
subsystem which connects the INC to the other GAN systems; e.g.,
GANC security gateways, local or remote management systems,
etc.
[0155] The GANC MGW 640 provides the inter-working function between
the Up interface and the Iu-CS user plane. The GANC MGW would
provide inter-working between RFC 3267 based frames received over
the Up interface and Iu-UP frames towards the CN. The GANC
Signaling GW 635 provides protocol conversion between SIGTRAN
interface towards the INC and the ATM based Iu-cs interface towards
the CN. The ATM GW 645 provides ATM/IP gateway functionality,
primarily routing Iu-ps user plane packets between the SeGW (IP
interface) and CN (AAL5 based ATM interface).
[0156] 4. Broadband IP Network
[0157] The Broadband IP Network 515 represents all the elements
that collectively, support IP connectivity between the GANC SeGW
520 function and the FAP 560. This includes: (1) Other Customer
premise equipment (e.g., DSL/cable modem, WLAN switch, residential
gateways/routers, switches, hubs, WLAN access points), (2) Network
systems specific to the broadband access technology (e.g., DSLAM or
CMTS), (3) ISP IP network systems (edge routers, core routers,
firewalls), (4) Wireless service provider (WSP) IP network systems
(edge routers, core routers, firewalls), and (5) Network address
translation (NAT) functions, either standalone or integrated into
one or more of the above systems.
[0158] 5. AP Management System (AMS)
[0159] The AMS 570 is used to manage a large number of FAPs 560
including configuration, failure management, diagnostics,
monitoring and software upgrades. The access to AMS functionality
is provided over secure interface via the GANC SeGW 520.
[0160] Some embodiments of the above mentioned devices, such as the
user equipment, FAP, or GANC, include electronic components, such
as microprocessors and memory (not shown), that store computer
program instructions (such as instructions for executing wireless
protocols for managing voice and data services) in a
machine-readable or computer-readable medium as further described
below in the section labeled "Computer System". Examples of
machine-readable media or computer-readable media include, but are
not limited to magnetic media such as hard disks, memory modules,
magnetic tape, optical media such as CD-ROMS and holographic
devices, magneto-optical media such as optical disks, and hardware
devices that are specially configured to store and execute program
code, such as application specific integrated circuits (ASICs),
programmable logic devices (PLDs), ROM, and RAM devices. Examples
of computer programs or computer code include machine code, such as
produced by a compiler, and files including higher-level code that
are executed by a computer, an electronic component, or a
microprocessor using an interpreter.
III. FEMTOCELL PROTOCOL ARCHITECTURE
A. CS Domain
Control Plane Architecture
[0161] The GAN Femtocell architecture of some embodiments in
support of the CS Domain control plane is illustrated in FIG. 8.
The figure shows different protocol layers for the UE 805, FAP 810,
Generic IP Network 815, SeGW 820, INC 825, and MSC 830. FIG. 8 also
shows the three interfaces Uu 840, Up 845 and Iu-cs 850.
[0162] 1. Up Interface for the CS Domain Control Plane
[0163] The main features of the Up interface 845 for the CS domain
control plane are as follows. The underlying Access Layers 846 and
Transport IP layer 848 provide the generic connectivity between the
FAP 810 and the GANC (which includes SeGW 820 and INC 825). The
IPSec encapsulation security payload (ESP) layer 850 provides
encryption and data integrity.
[0164] The TCP 852 provides reliable transport for the GA-RC 854
between FAP 810 and GANC and is transported using the Remote IP
layer 856. The GA-RC 854 manages the IP connection, including the
Femtocell registration procedures.
[0165] The GA-CSR 858 protocol performs functionality equivalent to
the UTRAN RRC protocol, using the underlying connection managed by
the GA-RC 854. Protocols, such as MM 860 and above, are carried
transparently between the UE 805 and MSC 830. The GANC terminates
the GA-CSR 858 protocol and inter-works it to the Iu-cs 850
interface using Radio Access Network Application Part (RANAP) 862
messaging.
[0166] The Remote IP layer 856 is the `inner` IP layer for IPSec
tunnel mode and is used by the FAP 810 to be addressed by the INC
825. Remote IP layer 856 is configured during the IPSec connection
establishment. In some embodiments, the Iu-cs signaling transport
layers 870 are per "UTRAN Iu interface signalling transport", 3GPP
TS 25.412 standard, hereinafter "TS 25.412".
B. CS Domain
User Plane Architecture
[0167] The GAN Femtocell protocol architecture of some embodiments
in support of the CS domain user plane is illustrated in FIG. 9.
The figure shows different protocol layers for the UE 905, FAP 910,
Generic IP Network 915, SeGW 920, Media GW 925, and MSC 930. FIG. 9
also shows the three interfaces Uu 935, Up 940, and Iu-cs 945.
[0168] The main features of the CS domain user plane are as
follows. The underlying Access Layers 950 and Transport IP layer
952 provide the generic connectivity between the FAP 910 and the
GANC. The IPSec layer 954 provides encryption and data
integrity.
[0169] The FAP 910 frames the CS user data 956 (received over the
air interface) into RFC 3267 defined frames. RFC 3267 user data 958
is transported over the Up interface to the GANC Media GW 925. The
GANC Media GW 925 will provide inter-working function 960 with
Iu-UP (e.g., Support Mode) towards the CN. In some embodiments,
Iu-UP uses ATM as a transport mechanism between the CN and the GANC
Media GW 925. In some embodiments, Iu-Up uses IP as a transport
mechanism between the CN and the GANC Media GW 925. In some
embodiments, the CS domain user plane architecture supports AMR
codec, as specified in "AMR speech codec; General description",
3GPP TS 26.071 standard with support for other codec being
optional. In some embodiments, the Iu-cs Data transport layers 970
are per TS 25.414.
C. PS Domain
Control Plane Architecture
[0170] The GAN Femtocell architecture of some embodiments in
support of the PS Domain Control Plane is illustrated in FIG. 10.
The figure shows different protocol layers for the UE 1005, FAP
1010, Generic IP Network 1015, SeGW 1020, INC 1025, and SGSN 1030.
FIG. 10 also shows the three interfaces Uu 1040, Up 1045, and Iu-ps
1050.
[0171] The main features of the Up interface 1045 for the PS domain
control plane are as follows. The underlying Access Layers 1052 and
Transport IP layer 1054 provide the generic connectivity between
the FAP 1010 and the GANC. The IPSec layer 1056 provides encryption
and data integrity.
[0172] TCP 1058 provides reliable transport for the GA-PSR 1060
signaling messages between FAP 1010 and GANC. The GA-RC 1062
manages the IP connection, including the Femtocell registration
procedures. The GA-PSR 1060 protocol performs functionality
equivalent to the UTRAN RRC protocol.
[0173] Upper layer protocols 1064, such as for GMM, SM and SMS, are
carried transparently between the UE 1005 and CN. The GANC
terminates the GA-PSR 1060 protocol and inter-works it to the Iu-ps
interface 1050 using RANAP 1070. In some embodiments, the Iu-ps
signaling transport layers 1080 are per TS 25.412.
D. PS Domain
User Plane Architecture
[0174] FIG. 11 illustrates the GAN Femtocell architecture for the
PS Domain User Plane of some embodiments. The figure shows
different protocol layers for the UE 1105, FAP 1110, Generic IP
Network 1115, SeGW 1120, Packet Gateway (Packet GW) 1125, and SGSN
1130. FIG. 11 also shows the three interfaces Uu 1135, Up 1140, and
Iu-ps 1145.
[0175] The main features of the Up interface 1140 for PS domain
user plane are as follows. The underlying Access Layers 1150 and
Transport IP layer 1155 provides the generic connectivity between
the FAP 1110 and the GANC. The IPSec layer 1160 provides encryption
and data integrity. The GTP-U 1170 protocol operates between the
FAP 1110 and the SGSN 1130 transporting the upper layer payload
(i.e. user plane data) across the Up 1140 and Iu-ps interfaces
1145.
[0176] The packet GW 1125 provides either ATM GW functionality for
ATM transport or IP GW functionality for IP transport. In some
embodiment, the Packet GW 1125 functionality is combined in the
SeGW 1120. Additionally, in some embodiments, the Packet GW
provides a GTP-U proxy functionality as well, where the GTP-U is
optionally terminated in the Packet GW 1125 on either side. In the
embodiments that the Packet GW 1125 provides ATM GW functionality,
the packet GW 1125 provides transport layer conversion between IP
(towards the FAP 1110) and ATM (towards the CN). User data 1180 is
carried transparently between the UE 1105 and CN. In some
embodiments, the Iu-ps Data transport layers 1180 are per TS
25.414.
E. Alternative Embodiments
[0177] In some embodiments, instead of using separate CSR and PSR
protocols for communication between the FAP and the GANC, as
described in this Specification, a single protocol, Generic Access
Radio Resource Control (GA-RRC) is used. In these embodiments, the
GA-CSR 858 (shown in FIG. 8) and GA-PSR 1060 (shown in FIG. 10)
protocol layers are replaced with one protocol layer GA-RRC.
Details of the GA-RRC protocol architecture and messaging are
further described in the U.S. patent application Ser. No.
11/778,040, entitled "Generic Access to the Iu Interface", filed on
Jul. 14, 2007. This Application is incorporated herein by
reference. One of ordinary skill in the art would be able to apply
the disclosure of the present application regarding the GA-CSR and
GA-PSR protocols to the GA-RRC protocol.
IV. RESOURCE MANAGEMENT
[0178] A. GA-RC (Generic Access Resource Control)
[0179] The GA-RC protocol provides a resource management layer,
with the following functions. (1) Discovery and registration with
GANC, (2) Registration update with GANC, (3) Application level
keep-alive with GANC, and (4) Support for identification of the FAP
being used for Femtocell access.
[0180] 1. States of the GA-RC Sub-Layer
[0181] FIG. 12 illustrates different states of the GA-RC sub-layer
in the FAP in some embodiments. As shown, the GA-RC sub-layer in
the FAP can be in one of two states: GA-RC-DEREGISTERED 1205 or
GA-RC-REGISTERED 1210.
[0182] The FAP creates and maintains a separate state for the GA-RC
sub-layer for each device it registers. For instance, if the FAP
registers three UEs, the FAP creates and maintains three separate
GA-RC sub-layers for these three UEs. Also, the FAP supports
registration for two types of devices i.e. the FAP and the UE.
Based on the type of device, the functionality of the GA-RC
sub-layer can vary.
[0183] a) GA-RC Sub-Layer for Device Type FAP
[0184] For the FAP device type, the GA-RC sub-layer is in the
GA-RC-DEREGISTERED state 1205 upon power-up of the FAP. In this
state, the FAP has not registered successfully with the GANC. The
FAP may initiate the Registration procedure when in the
GA-RC-DEREGISTERED state 1205. The FAP returns to
GA-RC-DEREGISTERED state 1205 on loss of TCP or IPSec connection or
on execution of the De-registration procedure. Upon transition to
GA-RC-DEREGISTERED state 1205, the FAP must trigger an implicit
deregistration all the UEs currently camped on the FAP.
[0185] In the GA-RC-REGISTERED state 1210, the FAP is registered
with the Serving GANC. The FAP has an IPSec tunnel and a TCP
connection established to the Serving GANC through which the FAP
may exchange GA-RC, GA-CSR and GA-PSR signaling messages with the
GANC. While the FAP remains in the GA-RC-REGISTERED state 1210 it
performs application level keep-alive with the GANC.
[0186] b) GA-RC Sub-Layer for Device Type UE
[0187] For the UE device type, the GA-RC sub-layer in the FAP (for
each UE) is in the GA-RC-DEREGISTERED state 1205 upon UE rove-in
and creation of a subsequent TCP connection between the FAP and the
GANC. In this state, the UE has not been registered successfully
(by the FAP) with the GANC. The FAP may initiate the Registration
procedure when UE specific GA-RC sub-layer is in the
GA-RC-DEREGISTERED state 1205. The GA-RC sub-layer returns to
GA-RC-DEREGISTERED state 1205 on loss of TCP or IPSec connection or
on execution of the De-registration procedure. Upon loss of TCP
connection, FAP may attempt to re-establish the corresponding TCP
session and perform the synchronization procedure. A failure to
successfully re-establish the TCP session will result in GA-RC
layer transitioning to GA-RC-DEREGISTERED state 1205. The GA-RC
sub-layer for UE can also transition to the GA-RC-DEREGISTERED
state 1205 if the corresponding GA-RC sub-layer for the FAP is in
GA-RC-DEREGISTERED state 1205.
[0188] In the GA-RC-REGISTERED state 1210, the UE has been
registered successfully (by the FAP) with the Serving GANC. The FAP
has a shared IPSec tunnel and a new TCP connection established to
the Serving GANC through which the FAP may exchange GA-RC, GA-CSR
and GA-PSR signaling messages (for each registered UE) with the
GANC. For each of the UE device types, the FAP will perform an
application level keep-alive with the GANC on the corresponding TCP
session.
[0189] In the GA-RC-REGISTERED state, the UE is camped on the
Femtocell and may either be idle or the UE may be active in the
Femtocell (e.g., a RRC connection may have been established). In
some embodiments, an idle UE is a UE that is not currently engaged
in a voice or data communication.
[0190] B. GA-CSR (Generic Access Circuit Switched Resources)
[0191] The GA-CSR protocol provides a circuit switched services
resource management layer which supports the following functions:
(1) setup of transport channels for CS traffic between the FAP and
GANC, (2) direct transfer of NAS messages between the UE (or the
FAP if the FAP supports local services) and the core network, and
(3) other functions such as CS paging and security
configuration.
[0192] 1. States of the GA-CSR Sub-Layer
[0193] FIG. 13 illustrates the state diagram in some embodiments
for GA-CSR in the FAP for each UE. As shown, the GA-CSR sub-layer
in the FAP (for each UE) can be in two states: GA-CSR-IDLE 1305 or
GA-CSR-CONNECTED 1310.
[0194] The GA-CSR state for each UE enters the GA-CSR-IDLE state
1305 upon rove-in to the FAP and successful registration of the UE
by the FAP with the Serving GANC. This switch may occur only when
the GA-RC state for the UE is in the GA-RC-REGISTERED state
1210.
[0195] The UE GA-CSR moves from the GA-CSR-IDLE state 1305 to the
GA-CSR-CONNECTED state 1310 when the GA-CSR connection is
established and returns to GA-CSR-IDLE state 1305 when the GA-CSR
connection is released. Upon GA-CSR connection release, an
indication that no dedicated CS resources exist is passed to the
upper layers.
[0196] A GA-CSR connection for each UE is typically established by
the FAP when upper layers messages (NAS layer) for the specific UE
need to be exchanged with the network. The GA-CSR connection
release can be triggered by the GANC or the FAP. If a FAP supports
local services (Terminal Adaptor functionality) using the FAP SIM,
there would be similar GA-CSR state for the FAP.
[0197] C. GA-PSR (Generic Access Packet Switched Resources)
[0198] The GA-PSR protocol provides a packet switched services
resource management layer which supports the following functions:
(1) setup of transport channels for PS traffic between the FAP (for
each UE) and network, (2) direct transfer of NAS messages between
the UE and the PS core network, (3) transfer of GPRS user plane
data, and (4) other functions such as PS paging and security
configuration.
[0199] 1. States of the GA-PSR Sub-Layer
[0200] FIG. 14 illustrates the state diagram in some embodiments
for GA-PSR in the FAP for each UE. As shown, the GA-PSR sub-layer
for each UE can be in two states: GA-PSR-IDLE 1405 or
GA-PSR-CONNECTED 1410.
[0201] The GA-PSR state for each UE enters the GA-PSR-IDLE state
1405 upon rove-in to the FAP and successful registration of the UE
by the FAP with the Serving GANC. This switch may occur only when
the GA-RC state for the UE is in the GA-RC-REGISTERED state
1210.
[0202] The UE GA-PSR moves from the GA-PSR-IDLE state to the
GA-PSR-CONNECTED state 1410 when the GA-PSR connection is
established and returns to GA-PSR-IDLE state 1405 when the GA-PSR
connection is released. Upon GA-PSR connection release, an
indication that no dedicated PS resources exist is passed to the
upper layers. A GA-PSR connection for each UE is typically
established by the FAP when upper layers messages (NAS layer) for
the specific UE need to be exchanged with the network. The GA-PSR
connection release can be triggered by the GANC or the FAP.
[0203] The GA-PSR Transport Channel (GA-PSR TC) provides the
association between the FAP (for each UE) and GANC for the
transport of PS user data over the Up interface. It is further
described in "GA-PSR Transport Channel Management Procedures"
Section, below. If a FAP supports local services (Terminal Adaptor
functionality) using the FAP SIM, there would be similar GA-PSR
state and GA-PSR TC for the FAP.
[0204] D. GA-CSR and GA-PSR Connection Handling
[0205] The GA-CSR and GA-PSR connections are logical connections
between the FAP and the GANC for the CS and PS domain respectively.
The GA-CSR (or the GA-PSR) connection is established when the upper
layers in the FAP request the establishment of a CS (or PS) domain
signaling connection and the corresponding GA-CSR (or GA-PSR) is in
GA-CSR-IDLE (or GA-PSR-IDLE) state, i.e. no GA-CSR (or GA-PSR)
connection exists between the FAP and GANC for the specific UE. In
some embodiments, the upper layer in the FAP requests the
establishment of GA-CSR (or the GA-PSR) connection, when the FAP
receives a corresponding higher layer (i.e. NAS layer) message over
the air interface (i.e. over the RRC connection) for the specific
UE. In some embodiments, between the UE and the FAP, a single RRC
connection is utilized for both CS and PS domain.
[0206] When a successful response is received from the network,
GA-CSR (or GA-PSR) replies to the upper layer that the CS (or PS)
domain signaling has been established and enters the corresponding
connected mode (i.e., the GA-CSR-CONNECTED or GA-PSR-CONNECTED
state). The upper layers have then the possibility to request
transmission of a NAS messages for CS (or PS) services to the
network over the corresponding GA-CSR (or GA-PSR) connection.
[0207] 1. FAP Initiated GA-CSR Connection Establishment
[0208] FIG. 15 illustrates successful establishment of the GA-CSR
connection when initiated by the FAP 1505 in some embodiments. As
shown, the FAP 1505 initiates GA-CSR connection establishment by
sending (in Step 1) the GA-CSR REQUEST message to the INC 1510.
This message includes the Establishment Cause indicating the reason
for GA-CSR connection establishment.
[0209] INC 1510 signals the successful response to the FAP 1505 by
sending (in Step 2) the GA-CSR REQUEST ACCEPT and the FAP 1505
enters the GA-CSR-CONNECTED state. Alternatively, the INC 1510 may
return (in Step 3) a GA-CSR REQUEST REJECT indicating the reject
cause. As shown, MSC 1515 plays no role in the FAP initiated GA-CSR
connection establishment.
[0210] 2. GA-CSR Connection Release
[0211] FIG. 16 shows release of the logical GA-CSR connection
between the FAP 1605 and the INC 1610 in some embodiments. As
shown, the MSC 1615 indicates (in Step 1) to the INC 1610 to
release the CS resources (both control and user plane resources)
allocated to the FAP 1605, via the Iu Release Command message. The
INC 1610 confirms (in Step 2) resource release to MSC 1615 using
the Iu Release Complete message.
[0212] The INC 1610 commands (in Step 3) the FAP 1605 to release
resources for the specific UE connection, using the GA-CSR RELEASE
message. The FAP 1605 confirms (in Step 4) resource release to the
INC 1610 using the GA-CSR RELEASE COMPLETE message and the GA-CSR
state in the FAP 1605 changes to GA-CSR-IDLE.
[0213] 3. FAP Initiated GA-PSR Connection Establishment
[0214] FIG. 17 shows successful establishment of the GA-PSR
Connection when initiated by the FAP 1705 in some embodiments. As
shown, the FAP 1705 initiates GA-PSR connection establishment by
sending (in Step 1) the GA-PSR REQUEST message to the INC 1710.
This message includes the Establishment Cause indicating the reason
for GA-PSR connection establishment.
[0215] The INC 1710 signals the successful response to the FAP 1705
by sending the GA-PSR REQUEST ACCEPT and the FAP 1705 enters the
GA-PSR-CONNECTED state. Alternatively, the INC 1710 may return (in
Step 3) a GA-PSR REQUEST REJECT indicating the reject cause. As
shown, SGSN 1715 plays no role in the FAP initiated GA-CSR
connection establishment.
[0216] 4. GA-PSR Connection Release
[0217] FIG. 18 illustrates release of the logical GA-PSR connection
between the FAP 1805 and the GANC in some embodiments. As shown,
the SGSN 1815 indicates (in Step 1) to the INC 1810 to release the
PS resources (both control and user plane resources) allocated to
the FAP, via the Iu Release Command message.
[0218] The INC 1810 confirms (in Step 2) resource release to SGSN
1815 by using the Iu Release Complete message. The INC 1810
commands (in Step 3) the FAP 1805 to release resources for the
specific UE connection, using the GA-PSR RELEASE message. The FAP
1805 confirms (in Step 4) resource release to the GANC using the
GA-PSR RELEASE COMPLETE message and the GA-PSR state in the FAP
1805 changes to GA-PSR-IDLE.
V. MOBILITY MANAGEMENT
[0219] A. UE Addressing
[0220] The IMSI associated with the SIM or USIM in the UE is
provided by the FAP to the INC when it registers a specific UE
attempting to camp on the FAP. The INC maintains a record for each
registered UE. For example, IMSI is used by the INC to find the
appropriate UE record when the INC receives a RANAP PAGING
message.
[0221] B. Femtocell Addressing
[0222] The IMSI associated with the SIM or USIM in the FAP is
provided by the FAP to the INC when it registers. The INC maintains
a record for each registered FAP.
[0223] The Public IP address of the FAP is the address used by the
FAP when it establishes an IPSec tunnel to the GANC Security
Gateway. This identifier is provided by the GANC Security Gateway
to the AAA server. In some embodiments, this identifier is used by
the GANC network systems to support location services (including
E911) and fraud detection. In some embodiments, this identifier is
used by service providers to support QoS for IP flows in managed IP
networks.
[0224] The Private IP address of the FAP (also referred to as the
"remote IP address") is used by the FAP "inside the IPSec tunnel."
This identifier is provided by the INC to the AAA server via the S1
interface when the FAP registers for Femtocell service. This
identifier may be used by the Femtocell network systems in the
future to support location services (including E911) and fraud
detection.
[0225] In some embodiments, the Access Point ID (AP-ID) is the MAC
address of the Femtocell access point through which the UE is
accessing Femtocell services. This identifier is provided by the
FAP to the INC via the Up interface, and by the INC to the AAA
server via the S1 interface, when the FAP registers for Femtocell
service. The AP-ID may be used by the Femtocell network systems to
support location services (including E911, as described in
"Location Based Routing" Section, below), and may also be used by
the service provider to restrict Femtocell service access via only
authorized FAPs (as described in "Femtocell Service Access Control"
Section, below).
[0226] C. Femtocell Identification
[0227] The following points describe the Femtocell Identification
strategy.
[0228] 1. Location Area, Routing Area, Service Area
Identification
[0229] In order to facilitate the Mobility Management functions in
UMTS, the coverage area is split into logical registration areas
called Location Areas (for CS domain) and Routing Areas (for PS
domain). UEs are required to register with the network each time
the serving location area (or routing area) changes. One or more
location areas identifiers (LAIs) may be associated with each
MSC/VLR in a carrier's network. Likewise, one or more routing area
identifiers (RAIs) may be controlled by a single SGSN.
[0230] The LA and the RA are used in particular when the UE is in
idle mode and the UE does not have any active RRC connection. The
CN would utilize the last known LA (for CS domain) and RA (for PS
domain) for paging of the mobile when active radio connection is
not available.
[0231] The Service Area Identifier (SAI) identifies an area
consisting of one or more cells belonging to the same Location
Area. The SAI is a subset of location area and can be used for
indicating the location of a UE to the CN. SAI can also be used for
emergency call routing and billing purposes.
[0232] The Service Area Code (SAC) which in some embodiments is 16
bits, together with the PLMN-Id and the Location Area Code (LAC)
constitute the Service Area Identifier.
[0233] SAI=PLMN-Id.parallel.LAC.parallel.SAC
[0234] In some embodiments, it is necessary to assign a distinct
LAI to each FAP in order to detect UE's mobility from the macro
network to a FAP or from one FAP to another FAP. When a UE moves
from the macro network to a FAP, the UE can camp on a FAP via its
internal cell selection logic. However, if the UE is in idle mode,
there will be no messages exchanged between the UE and the FAP,
thus making it difficult for the FAP to detect the presence of the
UE. In order to trigger an initial message from UE, upon its
camping on a specific FAP, the FAP will need to be assigned
distinct location areas than the neighboring macro cells. This will
result in the UE's MM layer triggering a Location Update message to
the CN via the camped cell i.e. FAP.
[0235] UE's mobility from one FAP to another FAP must also be
detected. The UE's cell selection could select a neighboring FAP
and it will camp on the neighboring FAP without any explicit
messaging. The neighboring FAP's Service Access Control (SAC) may
not allow the camping of that specific UE, but without an initial
explicit messaging there wouldn't be a way for the neighboring FAP
to detect and subsequently to reject the UE.
[0236] Assuming the MCC and MNC components of the LAI remain fixed
for each operator, LAI distinctiveness would be ensured by
allocating a distinct LAC to each FAP, such that the LAC assigned
to the FAP is different from the neighboring macro network cells
and other neighboring FAPs.
[0237] However, the LAC space is limited to maximum of 64K (due to
the limitation of a 16 bit LAC attribute as specified in
"Numbering, addressing and identification"), 3GPP TS 23.003,
hereinafter "TS 23.003". As a result, the LAC allocation scheme
must provide a mechanism to re-use the LACs for a scalable
solution, and at the same time minimize the operational impact on
existing CN elements (MSC/SGSN).
[0238] In some embodiments, the following solution is utilized to
meet the above requirements. The LAC allocation is split into two
separate categories: (1) A pool of LACs managed by the FAP/AMS, and
(2) A small set of LACs (one per "Iu" interface) managed by the
INC.
[0239] The first set of LACs is used by the FAP/AMS to assign a
unique LAC to each FAP such that it meets the following
requirements (at the minimum): (1) Uniqueness with regards to the
neighboring macro cells as well as other FAPs (this will ensure an
initial message from the UE upon Femtocell selection and rove-in),
and (2) Resolve conflicts with shared LACs where multiple FAPs
sharing the same LAC are not neighbors but are accessed by the same
UE (this is to allow the use of "LA not allowed" rejection code for
UE rejection).
[0240] The second set of LACs (a much smaller set) is managed
within each INC as follows, with the following key requirements:
(1) Minimize the impact on the existing CN elements (such as
minimal configuration and operational impact), (2) Seamlessly
integrate the existing functionality for routing of emergency calls
to appropriate PSAPs, and (3) Seamlessly integrate existing
functionality for the generation of appropriate call detail records
(CDRs) for billing purposes.
[0241] To meet the above requirements for the second set of LACs,
each INC represents a "SuperLA" for a given Iu interface (i.e.
MSC+SGSN interface). This implies the MSC/SGSN can be configured
with single Super LAI/Super RAI information for that INC. Note:
this does not limit the operator from configuring multiple Super
LAI/Super RAI if necessary (e.g., to further subdivide the region
served by a single INC into multiple geographic areas).
[0242] In addition, the INC shall utilize the following mapping
functionality for assignment of SuperLA: (1) When macro coverage is
reported by the FAP, INC shall support mapping of the reported
macro coverage to a Super LAC, Super RAC and Service Area Code
(SAC). The number of SACs utilized will be dependent on the
granularity which the operator chooses for regional distribution
(e.g. for emergency call routing, billing, etc), and (2) When no
macro coverage is reported by the FAP, the INC shall have the
following logic for the Super LAC/RAC/SAC assignment: (a) Query the
AAA via the S1 interface for information on the "provisioned macro
coverage" for the given FAP IMSI. If S1 reports macro coverage
(based on information stored in the subscriber DB), INC uses S1
macro information to map Super LAC/RAC/SAC as above, and (b) If
there is no information about the macro coverage from the S1 query,
INC maps the FAP to default Super LAC/RAC/SAC; (this could result
in the INC routing traffic to CN in sub-optimal mechanism). To
prevent this sub-optimal routing of UE traffic to default MSC/SGSN,
the following additional enhancement on the FAP may be utilized:
(i) Upon a UE rove-in to this "no coverage" FAP, the FAP can gather
information from the UE's initial location update (LU) request
(since the UE will report last camped LAI), (ii) The FAP can
collect information from multiple UEs and construct a "derived"
macro coverage information (the number of UEs utilized to derive
macro coverage could be algorithmic), (iii) Using this derived
macro coverage information, the FAP shall send a GA-RC Register
Update Uplink message to the INC, and (iv) The INC shall utilize
the macro coverage information reported via the GA-RC Register
Update Uplink message to map the FAP to an appropriate Super
LAC/RAC/SAC as above.
[0243] A distinct LAI for each FAP also implies a distinct RAI
since the RAI is composed of the LAI and Routing Area Code (RAC).
The LAI and RAI are sent to the FAP via the "System Information"
attribute upon successful registration of FAP. The SAI, on the
other hand, is relayed to the CN in the "Initial UE message" (used
to transfer initial L3 message from UE to the CN).
[0244] The FAP is expected to provide Super LAC/RAC replacement in
the NAS messages from the network to the UE (e.g. LU Accept or RAU
accept). The FAP must replace the "Super LAC/RAC" included in the
relevant NAS messages from the network, with the appropriate
locally assigned LAC/RAC information in messages sent to the UEs
camped on the FAP.
[0245] 2. 3G Cell Identification
[0246] A 3G Cell Id identifies a cell unambiguously within a PLMN.
A 3G cell identifier is composed as below.
[0247] 3G Cell Id=RNC-Id (12 bits)+cell Id (16 bits)
[0248] In some embodiments, the RNC-Id is 12 bits and cell Id is 16
bits, making the 3G Cell ID a 28 bits value. The 3G Cell Id in UMTS
are managed within the UTRAN and are not exposed to the CN. As a
result, the cell assignment logic can be localized to the UTRAN as
long as it can ensure uniqueness within a given PLMN.
[0249] The 3G Cell Id assigned to each FAP must be distinct from
its neighboring Femtocell primarily to avoid advertisement of the
same cell Id in system information broadcast by two adjacent FAPs,
considering the fact the physical deployment of the FAPs are ad-hoc
and not controlled by the operator. In some embodiments, each INC
will be statically provisioned with a unique RNC-Id and the RNC-id
will be conveyed to the FAP via the System Information during
registration. The FAP will be responsible for the assignment of the
16 bit cell Id locally and construct the 3G cell using the
combination of INC supplied RNC-Id and locally assigned cell
Id.
[0250] D. Femtocell Operating Configurations
[0251] Two Femtocell operating configurations are possible: common
core configuration and separate core configuration. In common core
configuration, the Femtocell LAI and the umbrella UTRAN's (e.g.,
the UTRAN that servers the subscriber's neighborhood) LAI are
different, and the network is engineered such that the same core
network entities (i.e., MSC and SGSN) serve both the Femtocells and
the umbrella UMTS cells.
[0252] The primary advantage of this configuration is that
subscriber movement between the Femtocell coverage area and the
UMTS coverage area does not result in inter-system (i.e., MAP)
signaling (e.g., location updates and handovers are intra-MSC). The
primary disadvantage of this configuration is that it requires
coordinated Femtocell and UMTS traffic engineering; e.g., for the
purpose of MSC & SGSN capacity planning.
[0253] In separate core configuration, the Femtocell LAI and
umbrella UTRAN's LAI are different, and the network is engineered
such that different core network entities serve the Femtocells and
the umbrella UMTS cells.
[0254] The advantage of this configuration is that engineering of
the Femtocell and UMTS networks can be more independent than in the
Common Core Configuration. The disadvantage of this configuration
is that subscriber movement between the Femtocell coverage area and
the UMTS coverage area results in inter-system (i.e., MAP)
signaling.
[0255] E. Femtocell Registration
[0256] The Femtocell registration process does not involve any
signaling to the PLMN infrastructure and is wholly included within
the Femtocell system (i.e., between the FAP, INC, and the AAA).
There are two kinds of Femtocell registrations: FAP registration
and UE registration.
[0257] In FAP registration, upon power-up, the FAP registers with
the INC. FAP registration serves the following purposes: (1) It
informs the INC that a FAP is now connected and is available at a
particular IP address. In some embodiments, the FAP creates a TCP
connection to the INC before registration. The TCP connection is
identified by using one or more of the following information:
source IP address, destination IP address, source TCP port,
destination TCP port. The INC can extract the FAP IP address from
the TCP connection, (2) It provides the FAP with the operating
parameters (such as LAI, Cell-Id, etc) associated with the
Femtocell service at the current location. The "System Information"
content that is applicable to the GAN Femtocell service is
delivered to the FAP during the registration process as part of
GA-RC REGISTRATION ACCEPT message sent from the INC to the FAP. The
FAP utilizes the information to transmit system parameters to the
UE over the broadcast control channel and (3) It allows the
Femtocell system to provide the service access control (SAC) and
accounting functions (e.g., AP restriction and redirection). In
some embodiments, the SAC and accounting is done through the S1
interface.
[0258] In UE registration, upon Femtocell selection and cell
camping, the UE initiates a LU message towards the CN via the FAP.
The FAP utilizes this message to detect presence of the UE on that
specific FAP. The FAP then initiates a registration message towards
INC for the camped UE. UE registration by the FAP serves the
following purpose: (1) It informs the INC that a UE is now
connected through a particular FAP and is available at a particular
IP address. The INC keeps track of this information for the
purposes of (for example) mobile-terminated calling, and (2) It
allows the INC to provide SAC functionality (e.g. using the S1
interface, to validate if the specific UE should be allowed
Femtocell services from a specific FAP).
[0259] F. Mobility Management Scenarios
[0260] The following scenarios illustrate the message flows
involved for various mobility management scenarios via the
Femtocell system.
[0261] 1. FAP Power On
[0262] In some embodiments, the FAP is initially provisioned with
information (i.e. an IP address or a FQDN) about the Provisioning
INC and the corresponding Provisioning SeGW related to that INC.
This information can be in the format of either a FQDN or an
IP-address or any combination of these. In case the FAP is not
provisioned with information about the Provisioning SeGW, the FAP
can derive a FQDN of the Provisioning SeGW from the IMSI (as
described in TS 23.003). If the FAP does not have any information
about either the Default INC or the Serving INC and the associated
SeGW stored, then the FAP completes the Discovery procedure towards
the Provisioning INC via the associated SeGW. If the FAP has stored
information about the Default/Serving INC on which it registered
successfully the last time, the FAP skips the discovery procedure
and attempt registration with the Default/Serving INC as described
below.
[0263] a) FAP Discovery Procedure
[0264] FIG. 19 illustrates the case in some embodiments when the
FAP 1905 powers on and does not have stored information on the
Default/Serving INC, and then performs a discovery procedure with
the provisioning GANC 1910. The provisioning GANC 1910 includes a
provisioning INC 1915, a DNS 1920, and a SeGW 1925.
[0265] As shown, if the FAP 1905 has a provisioned or derived (as
described in the FAP power on sub-section, above) FQDN of the
Provisioning SeGW, the FAP 1905 performs (in Step 1) a DNS query
(via the generic IP access network interface) to resolve the FQDN
to an IP address. If the FAP 1905 has a provisioned IP address for
the Provisioning SeGW 1925, the DNS steps (Steps 1 and 2) are
omitted. In some embodiments, the DNS Server 1935 is a public DNS
server accessible from the FAP. The DNS Server 1935 returns (in
Step 2) a response including the IP Address of the Provisioning
SeGW 1925.
[0266] Next, the FAP 1905 establishes (in Step 3) a secure tunnel
(e.g., an IPSec tunnel) to the Provisioning SeGW 1925. If the FAP
1905 has a provisioned or derived FQDN of the Provisioning INC
1915, the FAP 1905 performs (in Step 4) a DNS query (via the secure
tunnel) to resolve the FQDN to an IP address. If the FAP has a
provisioned IP address for the Provisioning INC 1915, the DNS steps
(Steps 4 and 5) are omitted. The DNS Server 1920 of the
provisioning GANC 1910 returns (in Step 5) a response including the
IP Address of the Provisioning INC 1915.
[0267] Next, the FAP 1905 sets up a TCP connection to a
well-defined port on the Provisioning INC. It then queries (in Step
6) the Provisioning INC 1915 for the Default INC, using GA-RC
DISCOVERY REQUEST. The message includes: (1) Cell Info: If the FAP
detects macro network coverage then the FAP provides the detected
UTRAN cell ID and the UTRAN LAI (for GSM, the FAP provides the GSM
cell identification and the GSM LAI). If the FAP does not detect
macro network coverage, the FAP provides the last LAI where the FAP
successfully registered, along with an indicator that identifies
the last GERAN/UTRAN cell (e.g., by including a GERAN/UTRAN
coverage Indicator Information Element (IE) which identifies the
GERAN or UTRAN cell coverage). The cell Info is the information of
neighboring macro cells which can be either GSM or UTRAN cells.
There are multiple ways for the FAP to obtain the neighboring cell
information, e.g. using pre-configuration on the FAP, obtaining the
macro neighbor configuration via AMS, or having the FAP radio scan
the neighboring cells. If the macro coverage is GSM, then for the
scan approach, the FAP must have the capability and mechanism for
scanning GSM cells, (2) FAP Identity: IMSI, and (3) The physical
MAC address of the FAP: AP-ID. Optionally, if the INC 1915 has been
configured for Service Access Control (SAC) over S1 interface, the
INC 1915 will via AAA server 1930 authorize the FAP 1905 using the
information provided in the GA-RC DISCOVERY REQUEST (Steps
6a-6c).
[0268] The Provisioning INC 1915 returns (in Step 7) the GA-RC
DISCOVERY ACCEPT message, using the information provided by the FAP
(e.g. the cell ID), to provide the FQDN or IP address of the
Default INC and its associated Default SeGW. This is done so the
FAP 1905 is directed to a "local" Default INC in the HPLMN to
optimize network performance. The DISCOVERY ACCEPT message also
indicates whether the INC and SeGW address provided shall or shall
not be stored by the FAP 1905.
[0269] If the Provisioning INC 1915 cannot accept the GA-RC
DISCOVERY REQUEST message, it returns (in Step 8) a GA-RC DISCOVERY
REJECT message indicating the reject cause. The secure IPSec tunnel
to the Provisioning SeGW is released (Step 9).
[0270] It is also be possible to reuse the same IPSec tunnel for
FAP Registration procedures. This is the case where a discovery
procedure results in the FAP to successfully find a "default" INC
and a "default" SeGW. If the default SeGW is same as that used for
discovery (i.e. the provisioning SeGW), then the same IPSEC tunnel
can be reused. In this case the IPSec tunnel is not released.
[0271] b) FAP Registration Procedure
[0272] Following the Discovery procedure the FAP establishes a
secure tunnel with the Security Gateway of the Default GANC,
provided by the Provisioning GANC in the Discovery procedure, and
attempts to register with the Default GANC. FIG. 20 illustrates FAP
power on registration procedure of some embodiments. The Default
GANC may become the Serving GANC for that connection by accepting
the registration, or the Default GANC may redirect the FAP to a
different Serving GANC. GANC redirection may be based on
information provided by the FAP during the Registration procedure,
operator chosen policy or network load balancing.
[0273] As shown in FIG. 20, if the FAP 2005 was only provided the
FQDN of the Default or Serving SeGW 2015, the FAP 2005 performs (in
Step 1) a DNS query (via the generic IP access network interface)
to resolve the FQDN to an IP address. If the FAP 2005 has a
provisioned IP address for the SeGW, the DNS steps (Steps 1 and 2)
are omitted. The DNS Server 2010 returns (in Step 2) a response
including the IP address of the Default/Serving SeGW 2015.
[0274] Next, the FAP 2005 sets up (in Step 3) a secure IPSec tunnel
to the SeGW 2015. This step may be omitted if an IPSec tunnel is
being reused from an earlier Discovery or Registration. If the FAP
2005 was provided the FQDN of the Default or Serving INC, the FAP
then perform (in Step 4) a DNS query (via the secure tunnel) to
resolve the FQDN to an IP address. If the FAP 2005 has an IP
address for the INC, the DNS steps (Steps 4 and 5) are omitted. The
DNS Server 2020 returns (in Step 5) a response including the IP
address of the Default/Serving INC 2025.
[0275] The FAP then sets up a TCP connection to the INC 2025. The
TCP port can either be a well-known or one that has been earlier
received from the network during Discovery or Registration. The FAP
attempts to register (in Step 6) on the INC 2025 by transmitting
the GA-RC REGISTER REQUEST. In some embodiment, the message
includes one or more of the following information: Registration
Type, Cell Info, Neighboring FAP Info, the physical MAC address of
the FAP, FAP Identity, and location information.
[0276] The Registration Type indicates that the registering device
is a Femtocell AP. This is indicated using the "GAN Classmark" IE
(IEs are defined further below). The Cell Info is the neighboring
UTRAN/GERAN cell ID retrieved as a result of system scan for
neighbor information. The FAP must determine (using either scan
results or pre-configuration), a single suitable macro cell
information to be sent in the registration.
[0277] Neighboring FAP Info is information about neighboring FAPs
operating in the same PLMN and carrier frequency. This will help
provide the INC with information such as the LAI and cell-ids in
use by neighboring FAPs. In some embodiments, the neighboring FAP
information will not be provided. The physical MAC address of the
FAP is the AP-ID (in some embodiments, AP-ID is the MAC address of
the FAP associated Ethernet port). The FAP Identity is the IMSI of
the FAP. If GPS services are provided, location information is also
supported.
[0278] Optionally, if the INC 2025 has been configured for Service
Access Control (SAC) over S1 interface, the GANC will via AAA
server 2030 authorize the FAP using the information provided in the
REGISTER REQUEST (Steps 6a-6c). If the INC 2025 accepts the
registration attempt it responds (in Step 7) with a GA-RC REGISTER
ACCEPT. The message includes: (1) GAN Femtocell specific system
information (e.g.) (i) Location-area identification comprising the
mobile country code, mobile network code, and location area code
corresponding to the Femtocell, and (ii) 3G Cell identity
identifying the cell within the location area corresponding to the
Femtocell. The message also includes GAN Femtocell Capability
Information indicated via the use of "GAN Control Channel" IE. In
some embodiments, the GAN Femtocell Capability Information include
indications as to whether early Classmark sending is allowed, the
GAN mode of operation, whether GPRS is available, and whether the
GAN supports dual transfer mode.
[0279] In the case the INC 2025 accepts the registration attempt,
the TCP connection and the secure IPSec tunnel are not released and
are maintained as long as the FAP is registered to this GANC. INC
does not provide operation parameters for radio management (such as
carrier frequency, scrambling code, etc) to the FAP. It is expected
that the FAP would obtain this information via the AMS or other
pre-provisioning mechanisms.
[0280] Alternatively, the INC 2025 may reject the request. In this
case, it responds (in Step 8) with a GA-RC REGISTER REJECT
indicating the reject cause. The TCP connection and the secure
IPSec tunnel are released and the FAP 2005 shall act as defined in
the "abnormal cases" Section, below. Alternatively, if the GANC has
to redirect the FAP 2005 to (another) Serving GANC, it responds (in
Step 9) with a GA-RC REGISTER REDIRECT providing the FQDN or IP
address of the target Serving INC and the associated SeGW. In this
case the TCP connection is released (in Step 10) and the secure
IPSec tunnel is optionally released depending on if the network
indicates that the same IPSec tunnel can be reused for the next
registration. The GA-RC REGISTER REDIRECT message includes either a
single Serving SeGW and GANC address or a list of PLMN identities
and associated Serving SeGW and GANC addresses and an indication of
whether GANC address(es) can be stored in the FAP for future
use.
[0281] c) Abnormal Cases
[0282] If the Serving INC rejects the Register Request and does not
provide redirection to another Serving INC, the FAP shall
re-attempt Registration to the Default INC including a cause
indicating the failed registration attempt and the Serving INC and
SeGW with which the Register Request failed. The FAP should also
delete all stored information about this Serving GANC.
[0283] If the Default INC rejects a Registration Request and is
unable to provide redirection to suitable Serving INC, the FAP may
re-attempt the Discovery procedure to the Provisioning INC
(including a cause indicating the failed registration attempt and
the Default INC provided in the last Discovery procedure). The FAP
should also delete all stored information about the Default GANC.
The possible register reject causes for FAP registration attempts
are Network Congestion, Location Not Allowed, Geo-Location not
know, IMSI not allowed, AP not allowed, and Unspecified.
[0284] 2. FAP Initiated FAP Synchronization after TCP Connection
Reestablishment
[0285] In some embodiments, when FAP receives TCP Reset (TCP RST)
after TCP connection failure, the FAP tries to re-establish the
signaling connection using GA-RC Synchronization procedure. FIG. 21
illustrates the messages associated with the FAP initiated
synchronization procedure in some embodiments.
[0286] a) Initiation of the FAP Synchronization Procedure by the
FAP
[0287] In some embodiments, when FAP receives TCP RESET after TCP
connection failure, the FAP attempts to re-establish TCP connection
once. After successfully re-establishing TCP connection, the FAP
2105 sends (in Step 1) GA-RC SYNCHRONIZATION INFORMATION to the
GANC 2110 to synchronize the state information. When the FAP is
unsuccessful in re-establishing the TCP connection, the FAP
releases the related local GA-CSR or GA-PSR resources, and
continues as per sub-section "Handling of Lower Layer faults"
described further below.
[0288] b) Processing of the FAP Synchronization Information Message
by the GANC
[0289] Upon receiving the GA-RC SYNCHRONIZATION INFORMATION message
from the FAP, the GANC updates the FAP state information as
specified in the request. The GANC also verifies that the binding
(IMSI, inner IP address) as received in the GA-RC SYNCHRONIZATION
INFORMATION is the same as the one that the FAP used as identity
for authentication to the GANC-SeGW.
[0290] 3. System Selection
[0291] In some embodiments, in the combined 3G network, both
standard UMTS RNS and UMA Femtocell network coexists within the
same or different PLMN. Standard UMTS UEs utilize both access
options whichever is more optimal in a specific scenario. In these
embodiment, no changes are required to the PLMN selection
procedures in the NAS layers (MM and above) in the UE as described
in "Non-Access-Stratum functions related to Mobile Station (MS) in
idle mode", 3GPP TS 23.122. Also, in these embodiments, no changes
are required to the standard cell selection mechanism as described
in "User Equipment (UE) procedures in idle mode and procedures for
cell reselection in connected mode", 3GPP TS 25.304. The necessary
configuration and the system behavior for rove-in to Femtocell
coverage and rove-out to the macro network coverage are described
in the following paragraphs.
[0292] During the service activation or provisioning update, the
UMA Femtocell Network provides the FAP with radio parameters such
as the operating UARFCN and a list of primary scrambling codes for
the Femtocell. The provisioning parameters will also include the
list of UARFCNs/scrambling codes associated with the neighboring
macro cells.
[0293] The FAP then performs a neighborhood scan for the existence
of macro coverage using the macro UARFCN information. If multiple
macro network cells are detected in the FAP scan, the FAP selects
the best suitable macro cell for the purpose of reporting it to the
Serving INC during FAP registration. The FAP also stores the macro
cell list to be provided as a neighbor list for the camping
UEs.
[0294] The FAP also scans the neighborhood for the existence of
other FAPs within the same PLMN. It then selects unused {UARFCN,
SC} pair from the provisioned list of available pairs such that the
selected {UARFCN, SC} does not conflict with any neighboring FAP's
{UARFCN, SC} combination.
[0295] The FAP attempts to register with the Serving INC (obtained
via Discovery/Registration mechanisms as described in the FAP
discovery procedure and FAP registration procedure Sections above)
and includes information about the selected macro cell and a list
of neighboring FAPs. The Serving INC uses information provided
during registration to assign network operating parameters for the
registering FAP such as the LAI, 3G cell-id, service area, etc.
[0296] The Serving INC returns the network operating parameters to
the registering FAP using the register accept message. The FAP uses
a combination of information obtained through the initial
provisioning and Registration and broadcasts appropriate System
Information to UEs to be able to select Femtocell service and camp
on the FAP.
[0297] The macro network RNCs are provisioned with the list of
{UARFCN, SC} associated with Femtocell neighbors. Since the
Femtocell network has to be able to scale to millions of FAPs and
the deployment location cannot be controlled, the macro network
RNCs are provisioned with a list of 5-10 {UARFCN, SC} combinations
corresponding to the neighboring FAPs. As a result of the
limitations associated with neighbor list provisioning on the macro
RNC, the FAP will need to select one of the 5-10 provisioned
{UARFC, SC} pairs for its operation such that no two neighboring
FAPs (determined via FAPs' scan) shall re-use the same pair for its
operation.
[0298] The macro RNC shall provide the FAP neighbor list
information to the UEs camped on the macro network and using the
specific RNC. This will result in the UEs making periodic
measurements on the FAP neighbor list.
[0299] As the UE comes within the coverage area of the FAP and its
signal level becomes stronger, the UE will select the Femtocell.
The UE cell-reselection i.e. rove-in to FAP cell can be enhanced
via two possible mechanisms: (1) The FAP cell can be in a different
HPLMN (equivalent PLMN list) and will be selected via preferred
equivalent PLMN selection. This assumes that the UE's current
camped macro cell is not in the equivalent PLMN list, and (2) The
FAP will broadcast system information (such as Qqualmin and
Qrxlevmin) so that UE shall prefer the FAP cell in the presence of
other macro cell coverage.
[0300] Upon cell reselection and camping on the FAP cell, the UE
will initiate a location registration since the FAP LAI is
different than the LAI of the previously camped macro cell.
[0301] 4. UE Registration
[0302] The UE, upon camping on the FAP (via its internal cell
selection mechanism), will initiate a NAS layer Location Update
procedure towards the CN via the FAP (The LU is triggered since the
FAP broadcasts a distinct LAI than its neighboring macro cells and
other neighboring Femtocells). The FAP will intercept the Location
Update message and attempt to register the UE with the INC as
illustrated in FIG. 22. A person of ordinary skill in the art would
appreciate that a UE always initiates location update procedure
towards the core network, i.e., the UE uses the upper protocol
layers that are directly exchanged with the core network. As
described in this sub-section and several other sub-sections below,
the disclosed FAP has the capability to intercept this message and
to attempt to register the UE with the INC.
[0303] As shown, the UE 2205 establishes (in Step 1a) a radio
resource control (RRC) connection with the FAP 2210 on which it
camps. The UE 2205 starts (in Step 1b) a Location Update procedure
towards the CN. In some embodiments, for networks supporting
network mode 1, where there is a Gs interface between the MSC and
SGSG, the UE triggers a combined Routing Area (RA)/Location Area
(LA) update instead of the initial LA update upon rove-in to FAP.
The FAP 2210 will intercept the Location Update request (or the
combined RA/LA update request) and attempts to register the UE with
the associated Serving INC over the existing IPSec tunnel.
Optionally, the FAP may request (in Step 1c) the IMSI of the UE if
the Location Update is done (in Step 1d) using the TMSI, since the
initial registration for the UE must be done using the permanent
identity i.e. the IMSI of the UE.
[0304] Next, the FAP 2210 sets up (in Step 2) a separate TCP
connection (for each UE) to a destination TCP port on the INC 2215.
The INC destination TCP port is the same as that used for FAP
registration. The FAP 2210 attempts to register the UE 2205 on the
INC 2215 using the UE specific TCP connection by transmitting (in
Step 3) the GA-RC REGISTER REQUEST. The message includes
Registration Type (which indicates that the registering device is a
UE. This is indicated using the "GAN Classmark" IE), Generic IP
access network attachment point information (i.e., AP-ID), UE
Identity (i.e., UE-IMSI), and FAP identity (i.e., FAP-IMSI). In
some embodiments, the AP-ID is the MAC address of the FAP.
[0305] Optionally, if the INC 2215 has been configured for Service
Access Control (SAC) over S1 interface, the INC 2215 will, via AAA
server 2220, authorize the UE using the information provided in the
REGISTER REQUEST (Steps 3a-3c). The authorization logic on the AAA
server 2220 would also check to see if the UE 2205 is allowed
Femtocell access using the specific FAP.
[0306] If the INC 2215 accepts the registration attempt it responds
(in Step 4) with a GA-RC REGISTER ACCEPT. Next, the FAP 2210
establishes (in Step 5) a GA-CSR connection with the INC 2215. The
FAP 2210 encapsulates (in Step 6) the Location Update NAS PDU
within a GA-CSR UL DIRECT TRANSFER message that is forwarded to the
INC 2215 via the existing TCP connection.
[0307] Next, the INC 2215 establishes a SCCP connection to the CN
2225 and forwards (in Step 7) the Location Update request (or the
combined RA/LA update request) NAS PDU to the CN 2225 using the
RANAP Initial UE Message. Subsequent NAS messages between the UE
2205 and core network 2225 will be sent between INC 2215 and CN
2225 using the RANAP Direct Transfer message.
[0308] Next, the CN 2225 authenticates (in Step 8) the UE 2205
using standard UTRAN authentication procedures. The CN 2225 also
initiates the Security Mode Control procedure described in the
Security Mode Control Subsection under Femtocell Security Section
further below. The CN 2225 indicates (in Step 9) it has received
the location update and it will accept the location update using
the Location Update Accept message to the INC 2215.
[0309] The INC 2215 forwards (in Step 10) this message to the FAP
2210 in the GA-CSR DL DIRECT TRANSFER. The FAP 2210 will relay (in
Step 11) the Location Update Accept over the air interface to the
UE 2205. Once the UE 2205 has been successfully registered (by the
FAP) with the INC 2215 and performed a successful location update,
the FAP 2210 will expect a periodic LU for that UE (the enabling
and the periodicity of the LU is controlled by the FAP via System
Information broadcast from the FAP to the UE). This exchange will
serve as a keep-alive between the FAP 2210 and the UE 2205 and will
help the FAP 2210 detect idle UE's moving away from the camped FAP
2210 without explicit disconnect from the network.
[0310] a) Abnormal Cases
[0311] If the Serving INC rejects the UE specific Register Request,
the FAP shall reject the corresponding "Location update" request
from the UE using appropriate reject mechanisms (example: RRC
redirection to another cell or reject the LU with reject cause of
"Location Area not allowed", etc). The FAP shall tear down the
corresponding TCP session for the specific UE. The possible
register reject causes for UE specific registration attempts are
(1) AP not allowed (implies UE not allowed on FAP for the UE
specific registration), (2) IMSI not allowed, (3) Location not
allowed, (4) Unspecified, and (5) FAP not registered.
[0312] 5. UE Rove Out
[0313] FIG. 23 scenario illustrates the case when the UE leaves the
Femtocell coverage area while idle. As shown, upon successful GAN
registration and location update (LU) of the UE 2305, the FAP 2310
will monitor (in Step 1) the UE 2305 via periodic location updates.
The enabling and the periodicity of the LU is controlled by the FAP
2310 via System Information broadcast from the FAP to the UE. This
exchange will serve as a keep-alive between the FAP and the UE.
[0314] Next, FAP 2310 determines (in Step 2) that the UE 2305 is no
longer camped on the FAP (roved out), as a result of missing a
number of periodic location updates from the UE. Once, the FAP
determines that the UE has roved out, the FAP informs the GANC that
the UE has detached by sending (in Step 3) a GA-RC DEREGISTER
message to the INC 2315 using the associated TCP connection. Since
a TCP connection from the FAP to the GANC is unique for each UE,
sending GA-RC DEREGISTER message on the specific TCP connection
implies deregistration of the specific UE. Next, the GANC removes
(in Step 4) any associated UE context upon receiving the deregister
message on the UE specific TCP connection. In some embodiments, the
context associated with a UE includes states and other information
that the GANC keeps for each UE which is successfully registered.
The FAP 2310 also releases (in Step 4) the UE specific TCP
connection to the INC.
[0315] 6. UE Power Down with IMSI Detach
[0316] FIG. 24 illustrates the case when the UE powers down and
performs an IMSI detach via the GAN network in some embodiments. As
shown, UE 2405 in idle mode initiates (in Step 1) power off
sequence. Next, the UE 2405 establishes (in Step 2) an RRC
Connection with the FAP 2410. The UE send (in Step 3) a MM Layer
IMSI-Detach message over the air interface to the FAP. The FAP 2410
establishes (in Step 4) a GA-CSR connection with the INC 2415.
[0317] The FAP 2410 encapsulates the IMSI-Detach NAS PDU within a
GA-CSR UL DIRECT TRANSFER message that is forwarded (in Step 5) to
the INC 2415 via the existing TCP connection. The INC 2415
establishes a SCCP connection to the CN 2420 and forwards (in Step
6) the IMSI-Detach NAS PDU to the CN 2420 using the RANAP Initial
UE Message. The CN 2420 initiates (in Step 7) a normal resource
cleanup via RANAP Iu Release Command to the INC 2415. The Iu
Release from the CN 2420 results in INC 2415 tearing down (in Step
8) the corresponding GA-CSR connection.
[0318] Next, INC 2415 acknowledges (in Step 9) resource cleanup via
RANAP Iu Release Complete message to the CN. FAP 2410 deregisters
(in Step 10) the UE using the UE specific TCP connection. In some
embodiments, the FAP utilizes the mechanism described in Subsection
"UE rove out" above to detect that the UE has roved and trigger the
UE deregistration. As an optimization, the FAP can also monitors
the IMSI-Detach NAS message from the UE and trigger deregistration
of the UE.
[0319] Next, the FAP 2410 releases (in Step 11) the UE specific TCP
connection. FAP initiates (in Step 12) RRC Connection release
procedure towards the UE. Finally, the UE powers off (in Step
13).
[0320] 7. UE Power Down without IMSI Detach
[0321] The sequence of events is same as UE Roving out of Femtocell
as described in Subsection "UE rove out" above.
[0322] 8. Loss of Up Interface Connectivity
[0323] FIG. 25 illustrates the case when Up interface connectivity
is lost. As shown, the UE 2505 is in idle mode. The FAP 2510
periodically sends (in Step 1) GA-RC KEEP ALIVE message to the INC
2515 to check that the TCP connection exists. In Step 2, the TCP
(or IP) connectivity between the FAP 2510 and INC 2515 is lost
(e.g., due to a broadband network problem).
[0324] If the INC detects (in Step 3) the loss of connectivity, it
releases the resources assigned to the FAP (e.g., TCP connection)
and deletes the subscriber record (i.e., performs a local
deregistration of the FAP). Optionally, the INC implementation may
also delete UE specific connections originating on that FAP.
[0325] If the FAP 2510 detects (in Step 4) the loss of TCP
connectivity and if the loss is on the FAP specific TCP connection,
the FAP 2510 attempts (in Step 5) to re-establish the TCP
connection and re-register with the INC. If the FAP re-establishes
connectivity and re-registers before the INC detects the problem,
the INC must recognize that the FAP is already registered and
adjust accordingly (e.g., release the old TCP connection
resources). In some embodiment, the FAP specific TCP is a unique
TCP connection dedicated to the FAP and is used for FAP IMSI
related signaling to the INC such as FAP registration, FAP call
setup if the FAP offers local calling using the FAP IMSI, etc.
[0326] Different embodiments use different methods for the FAP to
detect the loss of a TCP connection. In some embodiments, the TCP
sub-layer (TCP stack) in the FAP indicates (to the upper layers) if
the connectivity to the other end point (i.e., the INC) is lost.
The notification from the TCP sub-layer on the FAP can happen
either when the upper layers attempt to transmit data over the TCP
connection or the stack can detect connectivity loss via a TCP Keep
Alive mechanism.
[0327] When the FAP is unsuccessful in re-establishing
connectivity, the FAP will do the followings (not shown) to
deregister all the UEs currently camped on the FAP: (1) The FAP
sends a GA-RC DEREGISTER message to the INC using the currently
established TCP connection for each UE, (2) releases the TCP
connection towards the GANC, and (3) releases all resources
associated with the deregistered UE.
[0328] Additionally, the FAP 2510 forces (in Step 6) all the UEs,
currently camped on that FAP, to do a cell-reselection and rove out
of Femtocell coverage. If the TCP connectivity loss is detected on
the UE specific connection, the FAP will deregister the UE and
trigger cell reselection on the UE immediately without attempting
to re-establish the UE specific TCP connection. Finally, the UE
2505, as a result of the cell re-selection, will switch (in Step 7)
to UMTS macro cell 2520 (if UMTS macro network coverage is
available).
[0329] 9. INC-Initiated Deregister
[0330] In some embodiments, the INC deregisters the FAP under the
following error cases: (1) INC receives GA-RC REGISTER UPDATE
UPLINK message, but FAP is not registered, (2) INC receives GA-RC
REGISTER UPDATEUPLINK message, but encounters a resource error and
cannot process the message, (3) INC receives GA-RC REGISTER UPDATE
UPLINK message with new macro network cell information, and the
macro cell is Femtocell-restricted, and (4) INC receives a GA-RC
REGISTER UPDATE UPLINK message and sends a request to the AAA
server for a registered FAP, and one of the following happens: (a)
INC receives an authentication failure for the user from AAA
server, (b) INC doesn't receive a response from AAA server, and
transaction timer expires, or (c) S1 interface is enabled but no
AAA server is configured, so the user couldn't be authenticated. In
some embodiments, the INC deregisters the UE when the INC receives
GA-RC SYNCHRONIZATION INFORMATION message for a UE that is not
registered.
[0331] 10. FAP-Initiated Register Update
[0332] FIG. 26 illustrates a scenario where the FAP initiates a
registration update in some embodiments. As shown, a register
update is triggered (in Step 1) in the FAP 2605 (e.g., Detection of
macro network coverage). The FAP sends (in Step 2) a GA-RC
REGISTER-UPDATE-UPLINK to the INC 2610.
[0333] The INC 2610 exchanges (in Steps 3a-3c) S1 RADIUS messages
with the AAA server 2615 for service access control (SAC). Based on
the outcome of SAC, additional procedures may be triggered (in Step
4) by this operation (e.g., deregistration or register update
downlink).
[0334] 11. INC-Initiated Register Update
[0335] FIG. 27 illustrates a scenario where the INC initiates a
registration update. As shown, a register update is triggered (in
Step 1) in the INC 2715 (e.g. due to change in SAC list for the
FAP, or change in System Information, etc).
[0336] Next, the INC 2715 sends (in Step 2) a GA-RC REGISTER UPDATE
DOWNLINK message to the FAP 2710. As shown, some other procedures
may be triggered (in Step 3) by this operation (e.g. FAP 2710
rejecting UEs 2705 due to updated SAC list received from the
INC).
[0337] 12. FAP Initiated UE Synchronization after TCP Connection
Reestablishment
[0338] In some embodiments, when FAP receives TCP RST after TCP
connection failure, the FAP tries to re-establish the signaling
connection using GA-RC Synchronization procedure. FIG. 28
illustrates the FAP initiated synchronization procedure in some
embodiments.
[0339] a) Initiation of the UE Synchronization Procedure by the
FAP
[0340] In some embodiments, when FAP receives TCP RST after TCP
connection failure, the FAP attempts to re-establish TCP connection
once. As shown in FIG. 28, after successfully re-establishing TCP
connection, the FAP 2805 sends (in Step 1) GA-RC SYNCHRONIZATION
INFORMATION to the GANC 2810 to synchronize the UE's state
information. When unsuccessful, the FAP releases the resources for
the UE and forces the UE to rove-out of the FAP and select an
alternate cell (either a macro cell or another FAP) for camping
[0341] b) Processing of the UE Synchronization Information Message
by the GANC
[0342] Upon receiving the GA-RC SYNCHRONIZATION INFORMATION message
from the FAP on a UE's TCP connection, the GANC updates the UE
state information as specified in the request. The GANC also
verifies that the associated FAP is in the registered state. When
the FAP is not in registered state, the GANC deregisters the UE by
sending a GA-RC-DEREGISTER message (not shown) with reject cause
code "FAP not registered" to the FAP on the UE's TCP connection.
When the GA-RC layer in the GANC has submitted the GA-RC DEREGISTER
message to the TCP layer, it initiates the release of its half of
the bidirectional TCP connection. The GANC also verifies that the
binding (IMSI, TCP connection) as received in the GA-RC
SYNCHRONIZATION INFORMATION is valid.
VI. CALL MANAGEMENT
[0343] A. Voice Bearer Establishment (Using Iu-UP Over AAL2)
[0344] FIG. 29 illustrates the normal procedures associated with
successfully establishing the voice bearer between the UE and MSC
for mobile originated (MO) or mobile terminated (MT) call purposes
in some embodiments. As shown, the signaling for a call origination
or termination is in progress (in Step 1) between UE 2905, FAP
2910, GANC MGW 2915, INC 2920, and MSC 2925. The MSC 2925 sends (in
Step 2) a RANAP Assignment Request (RAB) message to the INC 2920.
The assignment request includes the address for ALCAP signaling (an
ATM E.164 or NSAP address) and also the binding-id.
[0345] Next, the INC 2920 requests (in Step 3) the GANC MGW 2915 to
prepare a bearer connection between the endpoints (VoIP towards the
FAP and Iu-UP over AAL2 towards the MSC). The MGW 2915 initiates
(in Step 4) ALCAP signaling towards the MSC 2925 using the ATM
address and the binding-id.
[0346] Next, the MSC 2925 acknowledges (in Step 5) the AAL2
connection request using the ALCAP Establish confirm message. At
this point (Step 6) an AAL2 connection with appropriate QoS exists
between the GANC MGW and the MSC. The GANC MGW then sends (in Step
7) an Iu-UP control (Iu-INIT) message over this AAL2 connection to
request Iu-UP initialization
[0347] The MSC 2925 responds (in Step 8) with Iu-UP init
acknowledgement (Iu-INIT ACK). Next, the MGW 2915 assigns a MGW IP
address and port for the VoIP side of the connection. The MGW sends
(in Step 9) the VoIP information to the INC using a Prepare Bearer
Ack message. Next, the INC 2920 sends (in Step 10) a GA-CSR
ACTIVATE CHANNEL message to the FAP 2910 and starts a timer (e.g.,
Tqueuing, as described in "UTRAN Iu interface Radio Access Network
Application Part (RANAP) signaling", 3GPP TS 25.413) to ensure that
the RANAP Assignment Response is sent to the MSC on or before the
expiry of Tqueuing. The GA-CSR ACTIVATE CHANNEL message includes
the VoIP connection description created by the GANC MGW.
[0348] The FAP 2910 initiates (in Step 11) appropriate RRC layer
Radio Bearer Setup message towards the UE 2905. The UE confirms (in
Step 12) the setup via Radio Bearer Setup Complete message to the
FAP. The FAP sends (in Step 13) a GA-CSR
ACTIVATE-CHANNEL-ACKNOWLEDGE message to the INC, including the
local IP address and port to be used for the VoIP connection.
[0349] The INC requests (in Step 14a) the GANC MGW, to modify the
previously created connection and send the voice stream to the IP
address and port provided by the FAP. The GANC MGW acknowledges (in
Step 14b) the connection modification. The INC 2920 acknowledges
(in Step 15) completion of the traffic channel establishment to the
FAP 2910 via the GA-CSR ACTIVATE-CHANNEL COMPLETE message.
[0350] The INC 2920 signals (in Step 16) the MSC 2925 about the RAB
assignment completion. At this point (Steps 17a-17c), there is
voice bearer between the UE 2905 and MSC 2925 via the FAP 2910 and
the GANC MGW 2915. The rest of the call establishment continues
after the voice bearer establishment.
[0351] B. Call Management Scenarios
[0352] The following scenarios illustrate the message flows
involved for various call management scenarios via the
Femtocell.
[0353] 1. Mobile Originated Call
[0354] FIG. 30 illustrates a mobile originated call in some
embodiments. The scenario shown is for a mobile-to-PSTN call. As
shown, the UE 3005 in GAN idle mode originates (in Step 1) a call.
The UE 3005 establishes (in Step 2) a RRC connection with the FAP
3010. Upon request from the upper layers, the UE sends (in Step 3)
the CM Service Request to the FAP.
[0355] The FAP performs (in Step 4) the GA-CSR Connection
Establishment procedure with the INC as described in previous
sections. The FAP 3010 then forwards (in Step 5) the CM Service
Request to the INC 3015 using a GA-CSR UL DIRECT TRANSFER message.
Next, the INC 3015 establishes a SCCP connection to the MSC 3020
and forwards (in Step 6) the CM Service Request to the MSC using
the RANAP Initial UE Message. Subsequent NAS messages between the
UE and MSC will be sent between INC and MSC using the RANAP Direct
Transfer message.
[0356] Next, the MSC 3020 authenticates (in Step 7) the UE 3005
using standard UTRAN authentication procedures. The MSC also
initiates (in Step 7) the Security Mode Control procedure described
in previous sections. The UE sends (in Step 8) the Setup message to
the FAP providing details on the call to the MSC and its bearer
capability and supported codecs.
[0357] The FAP forwards (in Step 9) this message within the GA-CSR
UL DIRECT TRANSFER between the FAP and the INC. The INC relays (in
Step 10) the Setup message to the MSC using a RANAP Direct Transfer
message.
[0358] The MSC 3020 indicates (in Step 11) it has received the call
setup and it will accept no additional call-establishment
information using the Call Proceeding message to the INC. The INC
forwards (in Step 12) this message to the FAP in the GA-CSR DL
DIRECT TRANSFER. The FAP then relays (in Step 13) the Call
Proceeding message to the UE over the air interface. At this point
(Step 14) an end to end bearer path is established between the MSC
and UE using one of the procedures shown in previous section.
[0359] The MSC 3020 constructs (in Step 15) an ISUP IAM using the
subscriber address, and sends it towards the called party's
destination exchange 3025. The destination Exchange responds (in
Step 16) with an ISUP ACM message. The MSC then signals to the UE,
with the Alerting message, that the called party is ringing. The
message is transferred (in Step 17) to the INC.
[0360] The INC forwards (in Step 18) the Alerting message to the
FAP in the GA-CSR DL DIRECT TRANSFER. The FAP relays (in Step 19)
the Alerting message to the UE and if the UE has not connected the
audio path to the user, it shall generate ring back to the calling
party. Otherwise, the network-generated ring back will be returned
to the calling party.
[0361] The called party answers and the destination Exchange
indicates this (in Step 20) with an ISUP ANM message. The MSC
signals that the called party has answered, via the Connect
message. The message is transferred (in Step 21) to the INC. The
INC forwards (in Step 22) the Connect message to the FAP in the
GA-CSR DL DIRECT TRANSFER.
[0362] The FAP relays (in Step 23) the Connect message to the UE
and the UE connects the user to the audio path. If the UE is
generating ring back, it stops and connects the user to the audio
path. The UE sends (in Step 24) the Connect Ack in response, and
the two parties are connected for the voice call. The FAP relays
(in Step 25) this message within the GA-CSR UL DIRECT TRANSFER
between the FAP and the INC.
[0363] The INC forwards (in Step 26) the Connect Ack message to the
MSC. The end-to-end two way path is now (Step 27) in place and
bi-directional voice traffic flows between the UE and MSC through
the FAP and the INC. A FAP with local service can support MO using
the FAP IMSI. The necessary message flows would be similar as above
without the FAP-UE message exchanges over the air interface.
[0364] 2. Mobile Terminated Call
[0365] FIG. 31 illustrates a mobile terminated call. The scenario
shown is for a PSTN-to-mobile call. As shown, the MSC (i.e., the
GMSC function) receives (in Step 1) a call from party A intended
for the Femtocell subscriber 3105. The MSC 3120 sends (in Step 2) a
RANAP Paging message to the INC 3115 identified through the last
Location Update received by it and includes the TMSI if available.
The IMSI of the mobile being paged is always included in the
request.
[0366] The INC 3115 identifies the UE registration context using
the IMSI provided by the MSC. It then pages (in Step 3) the
associated FAP 3110 using the GA-CSR PAGING REQUEST message. The
message includes the TMSI, if available in the request from the
MSC, else it includes only the IMSI of the mobile.
[0367] The FAP 3110 relays (in Step 4) the Paging request to the
UE. The FAP may use Paging Type 1 or 2 based on the RRC state of
the UE as described in "Radio Resource Control (RRC) protocol
specification", 3GPP TS 25.331, hereinafter "TS 25.331". The UE
3105 establishes (in Step 4a) a RRC connection with the FAP 3110 if
one doesn't exist. This step is omitted if there is an already
existing RRC connection (e.g. an RRC connection may have been
established for PS domain).
[0368] Next, the UE 3105 processes the paging request and sends (in
Step 5) the Paging response to the FAP 3110. The FAP then performs
(in Step 5a) the GA-CSR Connection Establishment procedure with the
INC as described in previous sections. The FAP responds (in Step 6)
with a GA-CSR PAGING RESPONSE.
[0369] The INC 3115 establishes an SCCP connection to the MSC 3120.
The INC 3115 then forwards (in Step 7) the paging response to the
MSC using the RANAP Initial UE Message. Subsequent NAS messages
between the UE and core network will be sent using the RANAP Direct
Transfer message. The MSC then authenticates (in Step 8) the UE
using standard UTRAN authentication procedures. The MSC also
initiates (in Step 8) the Security Mode Control procedure described
in previous sections.
[0370] The MSC initiates (in Step 9) call setup using the Setup
message sent to the FAP via INC. The INC then forwards (in Step 10)
this message to the FAP in the GA-CSR DL DIRECT TRANSFER message.
The FAP relays (Step 11) the Setup message to the UE
[0371] The UE 3105 responds (in Step 12) with Call Confirmed after
checking it's compatibility with the bearer service requested in
the Setup and modifying the bearer service as needed. If the Setup
included the signal information element, the UE alerts the user
using the indicated signal, else the UE alerts the user after the
successful configuration of the user plane
[0372] The FAP relays (in Step 13) the Call Confirmed to the INC
using the GA-CSR UL DIRECT TRANSFER message. The INC then forwards
(in Step 14) the Call Confirmed message to the MSC using RANAP
direct transfer message. At this point (Step 15) an end to end
bearer path is established between the MSC 3120 and UE 3105 using
the procedure for voice bearer establishment as described in
previous sections.
[0373] The UE signals (in Step 16) that it is alerting the user,
via the Alerting message to the FAP. The FAP relays (in Step 17)
the Alerting message to the INC using the GA-CSR UL DIRECT
TRANSFER. The INC (in Step 18) forwards the Alerting message to the
MSC.
[0374] The MSC 3120 returns (in Step 19) a ISUP ACM message towards
the originating PSTN Exchange 3125. The UE signals (in Step 20)
that the called party has answered, via the Connect message. The
FAP relays (in Step 21) the Connect message to the INC in the
GA-CSR UL DIRECT TRANSFER message.
[0375] Next, the INC forwards (in Step 22) the Connect message to
the MSC. The MSC then returns (in Step 23) an ISUP ANM message
towards the originating PSTN exchange 3125. The MSC acknowledges
(in Step 24) via the Connect Ack message to the INC. The INC
forwards (in Step 25) this message to the FAP in the GA-CSR DL
DIRECT TRANSFER.
[0376] The FAP relays (in Step 26) the Connect Ack to the UE. The
two parties on the call are connected on the audio path. The
end-to-end two way path is now (Step 27) in place and
bi-directional voice traffic flows between the UE and MSC through
the FAP and the INC. A FAP with local service can support MT using
the FAP IMSI. The necessary message flows would be similar as above
without the FAP-UE message exchanges over the air interface.
[0377] 3. Call Release by Femtocell Subscriber
[0378] FIG. 32 illustrates a scenario where a Femtocell call is
released by the Femtocell subscriber in some embodiments. As shown,
the Femtocell subscriber 3205 requests (in Step 1) call release
(e.g., by pressing the END button). Upon request from the upper
layers, the UE sends (in Step 2) the Disconnect message to the FAP
3210. The FAP forwards (in Step 3) the Disconnect message to the
INC (embedded in a GA-CSR UL DIRECT TRANSFER message).
[0379] The INC 3220 relays (in Step 4) the Disconnect message to
the MSC 3225 via RANAP Direct Transfer message. The MSC 3225 sends
(in Step 5) an ISUP RELEASE message towards the other party 3230.
The MSC sends (in Step 6) a Release to the INC using RANAP Direct
Transfer message.
[0380] Next, the INC forwards (in Step 7) the Release message to
FAP using GA-CSR DL DIRECT TRANSFER message. The FAP then sends (in
Step 8) the Release message to the UE over the air interface. The
UE 3205 confirms (in Step 9) the Release via the Release Complete
message to the FAP. The FAP relays (in Step 10) the Release
Complete message to the INC using GA-CSR UL DIRECT TRANSFER
message
[0381] The INC forwards (in Step 11) the message to the MSC using
RANAP Direct Transfer message. At this point, the MSC considers the
connection released. Sometime after Step 5, the MSC receives (in
Step 12) an ISUP RLC message from the other party's exchange.
[0382] The MSC 3225 sends (in Step 13) an Iu Release command to the
INC 3220 indicating a request to release the call resources. The
SCCP Connection Identifier is used to determine the corresponding
call. The INC 3220 requests (in Step 14) the GANC MGW 3215 to
release associated resources with the call. The GANC MGW 3215
confirms (in Step 15) release of associated resources.
[0383] The INC initiates (in Step 16) a GA-CSR Connection Release
procedure towards the FAP (as described in previous sections). The
FAP in turn releases (in Step 17) any radio resource associated for
the specific call. If there is an active PS session for the UE, the
RRC connection may not be released by the FAP, and only the
corresponding CS radio bearers are released. Finally, the INC
acknowledges (in Step 18) the resource release to the MSC using the
Iu Release Complete message to the MSC. The SCCP connection
associated with the call between the INC and the MSC is released as
well
[0384] 4. Other Calling Scenarios
[0385] The following services are supported by the Femtocell
solution: [0386] Calling Line Identification Presentation (CLIP)
[0387] Calling Line Identification Restriction (CLIR) [0388]
Connected Line Identification Presentation (CoLP) [0389] Connected
Line Identification Restriction (CoLR) [0390] Call Forwarding
Unconditional [0391] Call Forwarding Busy [0392] Call Forwarding No
Reply [0393] Call Forwarding Not Reachable [0394] Call Waiting (CW)
[0395] Call Hold (CH) [0396] Multi Party (MPTY) [0397] Closed User
Group (CUG) [0398] Advice of Charge (AoC) [0399] User User
Signaling (UUS) [0400] Call Barring (CB) [0401] Explicit Call
Transfer (ECT) [0402] Name Identification [0403] Completion of
Calls to Busy Subscriber (CCBS)
[0404] These supplementary services involve procedures that operate
end-to-end between the UE and the MSC. Beyond the basic Direct
Transfer Application Part (DTAP) messages already described for MO
and MT calls, the following DTAP messages are used for these
additional supplementary service purposes: [0405] HOLD [0406]
HOLD-ACKNOWLEDGE [0407] HOLD-REJECT [0408] RETRIEVE [0409]
RETRIEVE-ACKNOWLEDGE [0410] RETRIEVE-REJECT [0411] FACILITY [0412]
USER-INFORMATION [0413] CONGESTION-CONTROL [0414] CM-SERVICE-PROMPT
[0415] START-CC [0416] CC-ESTABLISHMENT [0417]
CC-ESTABLISHMENT-CONFIRMED [0418] RECALL
[0419] These DTAP message are relayed between the UE and MSC by the
INC in the same manner as in the other call control and mobility
management scenarios described in this disclosure. A generic
example is illustrated in FIG. 33. As shown (in Step 1), there is
an existing MM connection established between the UE and the MSC
for an ongoing call. The user requests (in Step 2) a particular
supplementary service operation (e.g., to put the call on
hold).
[0420] The UE 3305 sends (in Step 3a) the HOLD message to the FAP
3310 over the air. The FAP in turn forwards (in Step 3b) the
message to INC 3315), embedded in a GA-CSR UPLINK DIRECT TRANSFER
message. The INC relays (in Step 3c) the DTAP HOLD message to the
MSC 3320 over the Iu-interface.
[0421] Next, the DTAP HOLD-ACK message is sent (in Steps 4a-4c)
from MSC 3320 to UE 3305 through the INC and FAP. Later in the
call, the user requests (in Step 5) another supplementary service
operation (e.g., to initiate a MultiParty call).
[0422] The UE sends (in Step 6a) the FACILITY message to the FAP
over the air. The FAP in turn forwards (in Step 6b) the message to
the INC. The INC relays (in Step 6c) the DTAP FACILITY message to
the MSC over the Iu-interface. Finally, the DTAP FACILITY message
including the response is sent (in Steps 7a-7c) from MSC to UE
through the INC and FAP.
VII. PACKET SERVICES
[0423] A. GA-PSR Transport Channel Management Procedures
[0424] The GA-PSR Transport Channel (GA-PSR TC) provides an
association between the FAP and INC for the transport of the user
data over the Up interface. Given that the Femtocell user data
transport is UDP based, the GA-PSR Transport Channel is associated
with corresponding FAP and INC IP addresses and UDP ports used for
user data transfer. The FAP and INC manage the GA-PSR Transport
Channel based on the requests for data transfer and the
configurable GA-PSR TC Timer.
[0425] 1. States of the GA-PSR Sub-Layer
[0426] The GA-PSR Transport Channel (GA-PSR TC) management
procedures are the basic procedures for PS services specified to
facilitate the control of the GA-PSR connection for user data
transfer. Given that the GTP-U user data transport is extended to
the FAP in GAN solution for Femtocell support, these procedures are
tightly integrated with RAB Assignment procedures for user data.
GTP-U based connection between the FAP and the SGSN for user data
transfer is referred to as the GA-PSR Transport Channel.
[0427] The GA-PSR Transport Channel consists of the following: (1)
The IP address and destination UDP port number to be used for user
data transfer at both the SGSN and FAP, and (2) The GA-PSR TC
Timer. The FAP or INC will activate a GA-PSR Transport Channel only
when needed; i.e., when the user data transfer is initiated.
[0428] The GA-PSR maintains a separate PS entity for each PDP
context that is established. Each individual GA-PSR PS entity can
be in two different states, GA-PSR-PS-STANDBY or GA-PSR-PS-ACTIVE
state. The state of the GA-PSR PS entity and the corresponding
transport channel are always synchronized.
[0429] In GA-PSR-PS-STANDBY state the FAP is not able to send or
receive user data associated with the specific PDP context to and
from the SGSN. The INC or the FAP needs to activate the GA-PSR
Transport Channel before sending any user data for that PDP
context. In this state a corresponding GA-PSR Transport Channel
does not exist. When the GA-PSR Transport Channel is activated, the
GA-PSR entity associated with that PDP context enters the
GA-PSR-PS-ACTIVE state.
[0430] In GA-PSR-PS-ACTIVE state the FAP and UE are able to send
and receive user data associated with the specific PDP context to
and from the SGSN. Furthermore there exists a corresponding GA-PSR
Transport Channel for this FAP/UE.
[0431] A GA-PSR TC Timer is also defined to control the transition
from GA-PSR-PS-ACTIVE to GA-PSR-PS-STANDBY state as follows. The
FAP GA-PSR layer implements a timer associated with each GA-PSR
Transport Channel. The timer is started when that entity enters
GA-PSR-PS-ACTIVE state and restarted each time a data packet for
that PDP context is transmitted to or received from the network.
When the timer expires, the FAP deactivates the GA-PSR Transport
Channel and the corresponding PDP service entity enters
GA-PSR-PS-STANDBY state.
[0432] The GA-PSR TC Timer value is provided to the FAP as part of
the Femtocell Registration procedure (i.e., in GA-RC REGISTER
ACCEPT message).
[0433] 2. FAP Initiated GA-PSR Transport Channel Activation
[0434] FIG. 34 depicts the FAP initiated GA-PSR Transport Channel
activation procedure of some embodiments. Initially, the
corresponding GA-PSR PS PDP entity is in GA-PSR-PS-IDLE state when
the uplink data transfer for that PDP context is requested. The FAP
has to establish the GA-PSR Transport channel prior to resuming the
uplink data transfer.
[0435] As shown, if the RRC connection does not exist, the UE 3405
initiates (in Step 1) RRC Connection establishment procedure as per
standard 3GPP procedure. Upon successful RRC Connection
establishment, the UE 3405 forwards (in Step 2) a Service Request
message to the SGSN via the FAP 3410 indicating data transfer. The
FAP performs (in Step 2a) the GA-PSR Connection Establishment
procedure with the INC as described in "FAP initiated GA-PSR
connection establishment" Subsection under "Resource Management"
Section, above.
[0436] The FAP 3410 then encapsulates the request within the
GA-PSR-UPLINK-DIRECT-TRANSFER message and forwards (in Step 3) the
request to the INC 3415. The INC forwards (in Step 4) the Service
Request to the CN (SGSN) 3420 encapsulated within the Initial Iu
Message or within the Direct Transfer message depending on PMM
state. Optionally, the CN (SGSN) may initiate (in Step 5) security
function as specified in "Security Mode Control" Subsection and
"Core network authentication" Subsections under "Femtocell
Security" Section, further below. Optionally, upon receiving the
request and if the UE was in PMM-CONNECTED state, the CN (SGSN)
responds (in Step 6) with a Service Accept message.
[0437] Optionally, if the Service Accept message was received, the
INC 3415 forwards (in Step 7) the message to the FAP 3410. The FAP
then forwards (in Step 8) the message to the UE 3405. The CN (SGSN)
3420 initiates (in Step 9) RAB Assignment procedure and includes
the RAB-ID, the CN Transport Layer Address (IP address) and the CN
Iu Transport Association (GTP-U Terminal Endpoint Identifier
(TEID)) for user data to be used with this GA-PSR Transport
Channel.
[0438] Next, the INC forwards (in Step 10) the GA-PSR ACTIVATE TC
REQ to the FAP to activate the Transport Channel for user data
transfer. The message includes the RAB-ID, and the INC IP Address
and INC TEID. To allow the FAP to send GA-PSR TC packets (i.e.,
GTP-U messages) directly to the SGSN, the INC sets the INC IP
Address to the CN IP Address and the INC TEID to the CN TEID. In an
alternate embodiment, it is possible for the GANC to assume the
role of a GTP-U proxy gateway, where two separate GTP-U tunnels
exist for a given GA-PSR TC i.e. first GTP-U between FAP and GANC
and the corresponding GTP-U between the GANC and the SGSN. The GANC
is responsible for relaying the actual PS data packets between the
two GTP-U tunnels. Next, corresponding Radio Bearers are
established (in Step 11) between the FAP 3410 and UE 3405.
[0439] The FAP then responds (in Step 12) to the INC with
acknowledgment. The message includes the RAB-ID and a GTP-U TEID
assigned by the FAP for the specific PS session. Upon receiving the
acknowledgment, the INC sends (in Step 13) the RAB Assignment Rsp
message to the CN (SGSN) to complete the RAB Assignment procedure.
To allow the SGSN to send GTP-U messages directly to the FAP, the
INC sets the RAN IP Address to the FAP's IP Address and the RAN
TEID to the TEID allocated by the FAP for the UE specific PS
session.
[0440] The INC notifies (in Step 14) the FAP that the procedure is
complete and the FAP modifies the state of the corresponding GA-PSR
PS PDP entity to GA-PSR-PS ACTIVE and starts GA-PSR PS TC Timer.
The UE initiates (in Step 15) uplink user data transfer via the
established transport channel and the SGSN may use the same
transport channel to send downlink user data packets. While the
transport channel is active, both FAP and SGSN can continue sending
user data associated with the same PDP context directly using this
transport channel.
[0441] 3. FAP Initiated Deactivation of the GA-PSR Transport
Channel
[0442] FIG. 35 illustrates the scenario in some embodiments when
the FAP deactivates the GA-PSR Transport Channel after the GA-PSR
TC Timer expires. As shown, GA-PSR TC Timer associated with one of
the active GA-PSR Transport Channels expires (in Step 1). The FAP
3510 sends (in Step 2) GA-PSR DEACTIVATE TC REQ message to the INC
3515 including the RAB-ID to identify the GA-PSR Transport Channel
and indicating the normal release as a cause for deactivation.
[0443] The INC 3515 forwards (in Step 3) RAB Release Req message to
the CN (SGSN) 3520 to request the release of the associated RAB.
The CN (SGSN) responds (in Step 4) with the RAB Assignment Request
indicating release for the requested RAB.
[0444] Next, the INC 3515 responds (in Step 5) to the FAP with a
GA-PSR DEACTIVATE TC ACK message to acknowledge successful
deactivation. Upon receiving acknowledgment message, the FAP
initiates (in Step 6) release of the associated Radio Bearers.
Finally, the INC sends (in Step 7) RAB Assignment Rsp message to
notify the SGSN that the RAB Release procedure is complete.
[0445] 4. Network Initiated Transport Channel Activation for PS
Service
[0446] FIG. 36 depicts a scenario when the CN (SGSN) initiates
activation of a PS Transport Channel for user data service. This
scenario covers the case when the SGSN receives a downlink user
data packet from the GGSN and the RAB for that PDP context is not
established. Initially, the CN (SGSN) received downlink user data
to transfer to the UE and the associated RAB is not established.
The UE is in PMM-IDLE state. The UE 3605 is in PMM-IDLE state and
the CN (SGSN) 3610 sends (in Step 1) the RANAP Paging request to
the UE 3605 via the INC 3615 to locate the user. The paging request
indicates paging for PS Domain. The INC 3615 forwards (in Step 2)
the GA-PSR PAGING message to the FAP 3610.
[0447] Next, the FAP forwards (in Step 3) the PS Page to the UE
3605 as per standard 3GPP procedure. The FAP may use Paging Type 1
or 2 based on the RRC state of the UE as described in TS 25.331.
Next, an RRC connection is established (in Step 4) between the UE
3605 and FAP 3610. This step is omitted if there is an already
existing RRC connection (e.g. a RRC connection may have been
established for CS domain)
[0448] Next, the UE responds (in Step 5) to the SGSN via the FAP
with a Service request indicating PS paging response. The message
is encapsulated within the RRC INITIAL DIRECT TRANSFER message. The
FAP performs (in Step 5a) the GA-PSR Connection Establishment
procedure with the INC as described in Subsection "FAP initiated
GA-PSR connection establishment" under "RESOURCE MANAGEMENT"
Section, above. The FAP forwards (in Step 6) the PS paging response
to the INC using GA-PSR PAGING RESPONSE message.
[0449] The INC forwards (in Step 7) the Service Request message to
the SGSN encapsulated in the RANAP Initial UE Message. Security
function is performed (in Step 8) as specified in "Security mode
control" Subsection and "Core network authentication" under
"FEMTOCELL SECURITY" Section, below. Steps 9 to 15 are same as
described in the "FAP initiated GA-PSR transport channel
activation" Subsection, above.
[0450] 5. Network Initiated Transport Channel Deactivation
[0451] FIG. 37 depicts a network initiated GA-PSR Transport Channel
deactivation procedure that includes Radio Access Barer release in
some embodiments. Initially, active GA-PSR Transport Channel
associated with the UE 3705 that is registered for Femtocell
service is active.
[0452] As shown, optionally, the INC 3715 may initiate (in Step 1)
RAB Release procedure as a result of error handling procedure. This
would trigger CN (SGSN) 3720 to release the corresponding RAB. The
CN (SGSN) 3720 sends (in Step 2) a RAB Assignment Request to
request the release of the associated RAB. The release request may
include one or more RABs.
[0453] The INC 3715 requests (in Step 3) deactivation of the
associated GA-PSR Transport Channel. As a result, the corresponding
Radio Bearers are (in Step 4) released. The FAP 3710 then updates
(in Step 5) the state of the corresponding GA-PSR PS PDP entity to
STANDBY, stops GA-PSR TC Timer and sends the acknowledgment back to
the INC. Steps 3, 4 and 5 are repeated for each additional RAB that
needs to be released. Finally, the INC 3715 notifies (in Step 6)
the CN (SGSN) 3720 that the release was successful.
[0454] B. User Data and Signaling Transport
[0455] 1. User Data Transport Procedures
[0456] FIG. 38 illustrates the transport of user data packets via
Femtocell in some embodiments. As shown, if the corresponding
GA-PSR Transport Channel is not active, the GA-PSR TC activation
procedure is initiated (in Step 1) as specified in the "FAP
initiated GA-PSR transport channel activation" Subsection, above.
Upon the GA-PSR Transport Channel establishment, the FAP 3810
starts (in Step 2) GA-PSR TC Timer.
[0457] The UE 3805 initiates (in Step 3) the transfer of an uplink
user data packet using PDCP Data service. The FAP 3810 forwards (in
Step 4) the packet using the standard GTP-U protocol as specified
in "GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface",
3GPP TS 29.060, and restarts (in Step 5) GA-PSR TC Timer.
[0458] The CN (SGSN) 3820 transfers (in Step 6) downlink user data
packet utilizing the same GA-PSR Transport Channel associated with
the specific PDP context. Downlink user data packets are
transferred using the standard GTP-U protocol as specified in 3GPP
TS 29.060. Upon receiving the downlink data packet, the FAP
restarts (in Step 7) GA-PSR TC Timer associated with the
corresponding GA-PSR Transport Channel and forwards (in Step 8) the
packet to the UE via the PDCP.
[0459] Additional uplink and downlink user data packets are
transferred (in Step 9) via the same GA-PSR Transport Channel as
described in steps 2 and 3 respectively. After the GA-PSR TC Timer
expires (Step 10), the FAP initiates (in Step 11) GA-PSR Transport
Channel deactivation procedure as described in the "FAP initiated
deactivation of the GA-PSR transport channel" Subsection, above. A
FAP with local service can support PS user plane activity using the
FAP IMSI. The necessary message flows would be similar as above
without the FAP-UE message exchanges over the air interface.
[0460] 2. GA-PSR Signaling Procedures
[0461] A single TCP connection per UE is established for the
transport of signaling messages within the Femtocell. This TCP
connection is used to transport all CS and PS related signaling and
SMS messages.
[0462] a) UE Initiated PS Signaling Procedure
[0463] For UE initiated PS related signaling, the UE sends a PS
signaling message to the CN, via the INC which forwards it to the
CN over the Iu-ps interface as per standard UMTS; e.g. the
signaling message may include GMM attach or SM PDP context
activation message. The INC encapsulates the received signaling
message within a RANAP Direct Transfer message that is forwarded to
the SGSN over the Iu-ps interface. FIG. 39 illustrates Uplink
Control Plane Data Transport of some embodiments.
[0464] Initially, the UE 3905 is ready to send an uplink signaling
message for PS services to the CN (SGSN) 3920. This could be any of
the GMM or SM signaling messages. As shown, if the RRC connection
does not exist, the UE 3905 initiates (in Step 1) RRC Connection
establishment procedure as per standard 3GPP procedure.
[0465] Upon successful RRC Connection establishment, the UE
forwards (in Step 2) a Service Request message to the SGSN via the
FAP 3910 indicating PS Signaling message. The FAP performs (in Step
2a) the GA-PSR Connection Establishment procedure with the INC as
described in the "FAP initiated GA-PSR connection establishment"
Subsection under the "RESOURCE MANAGEMENT" Section, above. The FAP
encapsulates the Service Request within the
GA-PSR-UPLINK-DIRECT-TRANSFER message and forwards (in Step 3) the
request to the INC 3910.
[0466] Next, the INC forwards (in Step 4) the Service Request to
the SGSN encapsulated within the Initial Iu Message or within the
Direct Transfer message depending on PMM state. Optionally, the CN
(SGSN) may initiate (in Step 5) security function as specified in
Sections "Security Mode Control" and "Core Network Authentication",
below. The UE 3805 sends (in Step 6) the PS signaling message to
the FAP 3910 using RRC Uplink Direct Transfer service.
[0467] The FAP 3910 forwards (in Step 7) the PS signaling message
to the INC encapsulated within the GA-PSR-UPLINK-DIRECT-TRANSFER
message. Finally, the INC 3915 forwards (in Step 8) the PS
signaling message to the CN (SGSN) 3920 using RANAP Direct Transfer
procedure.
[0468] b) Network Initiated PS Signaling Procedure
[0469] For Network initiated PS related signaling, the Core Network
sends a PS signaling message to the INC via the IuPS interface as
per standard UMTS; e.g. the signaling message may include GMM
attach accept or SM PDP context activation accept message. The INC
encapsulates the received signaling message within a
GA-PSR-DOWNLINK-DIRECT-TRANSFER OR GA-PSR PAGING message that is
forwarded to the FAP via the existing TCP signaling connection.
FIG. 40 illustrates Downlink Control Plane Data Transport of some
embodiments. Initially, the CN (SGSN) 4020 is ready to send a
downlink signaling message for PS services to the UE 4005. This
could be any of the GMM or SM signaling messages. Given that the
signaling procedure is network initiated and if the UE is in
PMM-IDLE state, the SGSN will first page the UE. If the UE is in
PMM-CONNECTED state the SGSN will send the downlink PS signaling
message using RANAP Direct Transfer procedure starting with Step
9.
[0470] As shown, optionally, if the UE 4005 is in PMM-IDLE state,
the CN (SGSN) 4020 sends (in Step 1) the RANAP Paging request to
the UE via the INC 4015 to locate the user. The paging request
indicates paging for PS Domain. Optionally, if the paging request
was received, the INC forwards (in Step 2) the paging request using
the GA-PSR PAGING message to the FAP 4010.
[0471] Also, optionally, if the paging message is received, the FAP
forwards (in Step 3) the PS page to the UE as per standard 3GPP
procedure. Optionally, if the RRC connection does not exist for
that UE, it is established (in Step 4) as per standard 3GPP
procedure. Optionally, if the page for PS services was received,
the UE responds (in Step 5) to the SGSN via the FAP with a Service
Request message indicating PS paging response. The Service Request
message is encapsulated within the RRC INITIAL DIRECT TRANSFER
message.
[0472] The FAP 4010 performs (in Step 5a) the GA-PSR Connection
Establishment procedure with the INC as described in the "FAP
initiated GA-PSR connection establishment" Subsection under the
"RESOURCE MANAGEMENT" Section, above. The FAP forwards (in Step 6)
the response encapsulated within the GA-PSR PAGING RESPONSE message
to the INC.
[0473] Next, the INC 4015 forwards (in Step 7) the Service Request
message to the SGSN 4020 encapsulated in the RANAP Initial UE
Message. Optionally, the CN (SGSN) initiates (in Step 8) Security
Function.
[0474] The CN (SGSN) forwards (in Step 9) the PS signaling message
to the INC using RANAP Direct Transfer procedure. The INC forwards
(in Step 10) the PS signaling message to the FAP encapsulated
within the GA-PSR-DOWNLINK-DIRECT-TRANSFER message. Finally, the
FAP sends (in Step 11) the signaling message to the UE using RRC
Downlink Direct Transfer service. A FAP with local service can
support PS signaling plane activity using the FAP IMSI. The
necessary message flows would be similar as above without the
FAP-UE message exchanges over the air interface.
VIII. ERROR HANDLING PROCEDURES
[0475] In some embodiments, the checks described in this section
are applied to all messages exchanged in the Femtocell system. This
section also specifies procedures for the handling of unknown,
unforeseen, and erroneous protocol data by the receiving entity.
These procedures are called "error handling procedures", but in
addition to providing recovery mechanisms for error situations they
define a compatibility mechanism for future extensions of the
protocols. In some embodiments, Sub-sections A to F, below, are
applied in order of precedence.
[0476] In this section the following terminology is used (1) An
information element (IE) is defined to be syntactically incorrect
in a message if it includes at least one value defined as
"reserved" in the corresponding message, or if its value part
violates rules of any corresponding messages. However it is not a
syntactical error that an IE specifies in its length indicator a
greater length than defined in for the specific message, and (2) A
message is defined to have semantically incorrect contents if it
includes information which, possibly dependent on the state of the
receiver, is in contradiction to the resources of the receiver
and/or to the procedural part of this specification. The procedures
described in this sub-section apply to both GA-CSR and GA-PSR
messages, unless explicitly specified otherwise.
[0477] A. Message Too Short
[0478] When a message is received that is too short to include a
complete message header and all the mandatory information elements,
that message is ignored.
[0479] B. Invalid Message Header
[0480] When the FAP receives a message over UDP with message type
not defined or not implemented, the FAP ignores the message. When
the FAP receives a message over TCP with protocol discriminator not
defined or not implemented, the FAP ignores the message. When the
FAP receives a message with Skip Indicator IE not encoded as 0000
or Length IE greater than 2048, the FAP ignores the message.
[0481] When the FAP receives a message over TCP with message type
not defined for the specific PD (GA-CSR or GA-PSR) or not
implemented, the FAP returns a GA-CSR STATUS or GA-PSR STATUS
respectively, with cause "message type non-existent or not
implemented". When the FAP receives a message not compatible with
the protocol state, the FAP ignores the message and shall return a
(GA-CSR or GA-PSR) STATUS message with cause "Message type not
compatible with protocol state".
[0482] C. Invalid Information Elements
[0483] When the FAP receives a GA-RC OR GA-CSR OR GA-PSR message
with a missing or syntactically incorrect mandatory IE, the FAP
ignores the message and returns a (GA-RC or GA-PSR) STATUS message
with cause "Invalid mandatory information". The FAP also ignores
all unknown IEs in received messages. The FAP further treats all
optional IEs that are syntactically incorrect in a message as not
present in the message.
[0484] When the FAP diagnoses a missing or unexpected conditional
IE or when it receives at least one syntactically incorrect
conditional IE, the FAP ignores the message and returns a (GA-RC or
GA-PSR) STATUS message with cause value "conditional IE error".
When the FAP receives a message with semantically incorrect
contents, the FAP ignores the message and returns a (GA-RC or
GA-PSR) STATUS message with cause value "semantically incorrect
message".
[0485] D. Handling of Lower Layer Faults
[0486] The handling of lower layer failures in the FAP while in the
GA-RC-DEREGISTERED state is as follows. If a TCP connection was
established towards the Provisioning GANC, the FAP releases the
connection. If a secure connection was established towards SeGW of
the Provisioning GANC, the FAP releases the secure connection (as
defined in "Internet Key Exchange (IKEv2) Protocol", IETF RFC 4306.
additionally, when the lower layer failures happen during a
Discovery procedure, the FAP doubles the current timer value for
TU3903 but not exceeding the maximum value (32 minutes). The FAP
also starts timer TU3903.
[0487] When the lower layer failures happen during a Registration
procedure, and if the registration is still unsuccessful after a
number of attempts defined the FAP parameter "Up Connect Attempt
Count" (maximum value of 3), and if the FAP had attempted the
registration towards the Default GANC, then the FAP deletes the
stored information about the Default GANC, increments Redirection
Counter, and initiates the Discovery Procedure. When the lower
layer failures happen during a Registration procedure, the
registration is still unsuccessful after a number of attempts
defined the FAP parameter "Up Connect Attempt Count" (maximum value
of 3), and the FAP had attempted the registration towards a Serving
GANC, then the FAP increments Redirection Counter and initiates
Registration Procedure towards the Default GANC.
[0488] When the lower layer failures happen during a Registration
procedure and the registration is successful before a number of
attempts defined the FAP parameter "Up Connect Attempt Count"
(maximum value of 3), then the FAP starts timer TU3905 and waits
for it to expire.
[0489] The handling of lower layer failures in the FAP while not in
the GA-RC-DEREGISTERED state is as follows. For all lower layer
failures in the FAP (for example related to DNS, IPSec or TCP
failures other than RST) except the TCP connection failure which is
handled as described in the "FAP initiated FAP Synchronization
after TCP connection reestablishment" sub-section described above,
the FAP (1) releases the TCP connection towards the current GANC,
if established, (2) releases the secure connection towards SeGW of
the current GANC, if established, (3) starts timer TU3905 (for FAP
TCP connection) or TU3955 (for UE specific TCP connection), and (4)
enters GA-RC-DEREGISTERED state.
[0490] E. Out of Sequence IEs
[0491] The FAP ignores all out of sequence IEs in a message. In
some embodiments, the GANC also takes the same approach and ignores
all out of sequence IEs in a message.
[0492] F. Unexpected Messages
[0493] The FAP silently discards all unexpected messages (unless
specific behavior is defined for certain messages) which are either
inconsistent with the current state of the device or out of
sequence. The network should take the same approach.
IX. MESSAGE AND INFORMATION ELEMENTS USED
[0494] This section provides a list of messages and Information
elements (IEs) used in some embodiments. IEs are similar to
"attributes" or "parameters" and are used in messages to exchange
information across interfaces.
[0495] Table IX-1 summarizes the messages for Generic Resources
management.
TABLE-US-00001 TABLE IX-1 Messages for Unlicensed Radio Resources
management Discovery messages: GA-RC DISCOVERY REQUEST GA-RC
DISCOVERY ACCEPT GA-RC DISCOVERY REJECT Registration messages:
GA-RC REGISTER REQUEST GA-RC REGISTER ACCEPT GA-RC REGISTER
REDIRECT GA-RC REGISTER REJECT GA-RC DEREGISTER GA-RC REGISTER
UPDATE UPLINK GA-RC REGISTER UPDATE DOWNLINK Miscellaneous message:
GA-RC KEEP ALIVE GA-RC SYNCHRONIZATION INFORMATION
[0496] Table IX-2 summarizes the messages for Generic Access
Circuit Switched Resources (GA-CSR) management
TABLE-US-00002 TABLE IX-2 Messages for GA-CSR management GA-CSR
connection establishment messages: GA-CSR REQUEST GA-CSR REQUEST
ACCEPT GA-CSR REQUEST REJECT Traffic Channel establishment
messages: GA-CSR ACTIVATE CHANNEL GA-CSR ACTIVATE CHANNEL ACK
GA-CSR ACTIVATE CHANNEL FAILURE GA-CSR ACTIVATE CHANNEL COMPLETE
Channel release messages: GA-CSR RELEASE GA-CSR RELEASE COMPLETE
GA-CSR CLEAR REQUEST Paging messages: GA-CSR PAGING REQUEST GA-CSR
PAGING RESPONSE Security Mode messages: GA-CSR SECURITY MODE
COMMAND GA-CSR SECURITY MODE COMPLETE GA-CSR SECURITY MODE REJECT
Miscellaneous messages: GA-CSR UPLINK DIRECT TRANSFER GA-CSR
DOWNLINK DIRECT TRANSFER GA-CSR STATUS
[0497] Table IX-3 summarizes the messages for Generic Access Packet
Services Resource (GA-PSR) management.
TABLE-US-00003 TABLE IX-3 Messages for Generic Access Radio Link
Control management Transport Layer used GA-PSR Connection
Management messages: GA-PSR-REQUEST TCP GA-PSR REQUESTACCEPT TCP
GA-PSR REQUEST REJECT TCP GA-PSR-RELEASE TCP GA-PSR RELEASE
COMPLETE TCP GA-PSR TC Management messages: GA-PSR-ACTIVATE-TC-REQ
TCP GA-PSR-ACTIVATE-TC-ACK TCP GA-PSR-ACTIVATE-TC-CMP TCP
GA-PSR-DEACTIVATE-TC-REQ TCP GA-PSR-DEACTIVATE-TC-ACK TCP GPRS
Tunneling messages: GA-PSR-UPLINK-DIRECT-TRANSFER TCP
GA-PSR-DOWNLINK-DIRECT-TRANSFER TCP GAN Specific Signaling
messages: GA-PSR-PAGING TCP GA-PSR-PAGING RESPONSE TCP
GA-PSR-STATUS TCP Security messages: GA-PSR SECURITY MODE COMMAND
TCP GA-PSR SECURITY MODE COMPLETE TCP GA-PSR SECURITY MODE REJECT
TCP GA-PSR CLEAR REQUEST TCP
TABLE-US-00004 TABLE 9.2.1 IE type and identifiers for Unlicensed
Radio Resources management IE Identifier Mobile Identity (FAP) 1
GAN Release Indicator 2 Access Identity 3 GERAN Cell Identity 4
Location Area Identification 5 GERAN/UTRAN coverage Indicator 6 GAN
Classmark 7 Geographical Location 8 GANC-SeGW IP Address 9
GANC-SeGW Fully Qualified Domain/Host Name 10 Redirection Counter
11 Discovery Reject Cause 12 GAN Cell Description 13 GAN Control
Channel Description 14 Cell Identifier List 15 TU3907 Timer 16 GSM
RR/UTRAN RRC State 17 Routing Area Identification 18 GAN Band 19
GA-RC/GA-CSR State 20 Register Reject Cause 21 TU3906 Timer 22
TU3910 Timer 23 TU3902 Timer 24 L3 Message 26 Channel Mode 27
Mobile Station Classmark 2 28 RR Cause 29 Cipher Mode Setting 30
GPRS Resumption 31 Handover From GAN Command 32 UL Quality
Indication 33 TLLI 34 Packet Flow Identifier 35 Suspension Cause 36
TU3920 Timer 37 QoS 38 GA-PSR Cause 39 User Data Rate 40 Routing
Area Code 41 AP Location 42 TU4001 Timer 43 Location Status 44
Cipher Response 45 Ciphering Command RAND 46 Ciphering Command MAC
47 Ciphering Key Sequence Number 48 SAPI ID 49 Establishment Cause
50 Channel Needed 51 PDU in Error 52 Sample Size 53 Payload Type 54
Multi-rate Configuration 55 Mobile Station Classmark 3 56 LLC-PDU
57 Location Black List indicator 58 Reset Indicator 59 TU4003 Timer
60 AP Service Name 61 GAN Service Zone Information 62 RTP
Redundancy Configuration 63 UTRAN Classmark 64 Classmark Enquiry
Mask 65 UTRAN Cell Identifier List 66 Serving GANC table indicator
67 Registration indicators 68 GAN PLMN List 69 Required GAN
Services 71 Broadcast Container 72 3G Cell Identity 73 FAP Radio
Identity 96 GANC IP Address 97 GANC Fully Qualified Domain/Host
Name 98 IP address for GPRS user data transport 99 UDP Port for
GPRS user data transport 100 GANC TCP port 103 RTP UDP port 104
RTCP UDP port 105 GERAN Received Signal Level List 106 UTRAN
Received Signal Level List 107 Integrity Protection Information 75
Encryption Information 76 Key Status 77 Chosen Integrity Algorithm
78 Chosen Encryption Algorithm 79 Security Mode Reject Cause 80 RAB
ID 81 RAB Parameters 82 GTP TEID 83 Service Handover 84 PDP Type
Information 85 Data Volume Reporting Indicator 86 DL GTP-PDU
Sequence Number 86 UL GTP-PDU Sequence Number 88 DL N-PDU Sequence
Number 89 UL N-PDU Sequence Number 90 Alternate RAB Parameter
Values 91 Assigned RAB Parameter Values 92 Data Volume List 93 DRX
Cycle Length Coefficient 94 Paging Cause 95 URA Identity 110 GA-PSR
State 111 Mobile Identity (UE) 112 RABS Data Volume Report List 113
Allocation/Retention Priority Information 114 NAS Synchronization
Indicator 115
X. SHORT MESSAGE SERVICES
[0498] The Femtocell system provides support for both circuit mode
(CS mode) and packet mode (PS mode) SMS services. CS/PS mode of
operation UEs may be able to send and receive short messages using
either the MM sub-layer or the GMM sub-layer. PS mode of operation
UEs may be able to send and receive short messages using only GMM
sub-layer. Inter-working with Femtocell related to SMS services is
described in the following sections.
[0499] A. Circuit Mode (CS Mode) SMS Services
[0500] The Femtocell protocol architecture related to CS mode SMS
support builds on the circuit services signaling architecture
described in the "CS domain--control plane architecture" Subsection
under the "FEMTOCELL SYSTEM ARCHITECTURE" Section, above. FIG. 41
illustrates the protocol architecture for CS mode SMS in some
embodiments.
[0501] The Femtocell CS mode SMS support is based on the same
mechanism that is utilized for CS mobility management and call
control. On the UE 4105 side, the SMS layers 4110 (including the
supporting CM sub-layer functions) utilize the services of the MM
layer 4115 to transfer SMS messages per standard circuit mode
implementation. The SM-CP protocol is effectively tunneled between
the UE 4105 and the MSC 4115 using the message relay functions in
the GA-CSR protocol. As with CS mobility management and call
control procedures, SMS uses the UE specific TCP signaling
connection between the FAP and the INC 4120, providing reliable SMS
delivery over the Up interface 4125.
[0502] B. Packet Mode (PS Mode) SMS Services
[0503] The Femtocell protocol architecture related to PS mode SMS
support builds on the packet services signaling architecture
described in the "PS domain--control plane architecture" Subsection
under the "FEMTOCELL SYSTEM ARCHITECTURE" Section, above. FIG. 42
illustrates the GAN protocol architecture for packet mode SMS in
some embodiments.
[0504] On the UE 4205 side, the SMS layers 4210 (including the
supporting CM sublayer functions) utilize the services of the GMM
layer 4215 to transfer SMS messages per the standard packet mode
implementation. The SM-CP protocol is effectively tunneled between
the UE 4205 and the SGSN 4220 using the message relay functions in
the GA-PSR protocol. As with the packet services signaling
procedures, SMS uses the UE specific TCP signaling connection
between the FAP and the INC 4225, providing reliable SMS delivery
over the Up interface 4230.
[0505] C. SMS Scenarios
[0506] The following scenarios illustrate the message flows
involved for various SMS scenarios via the Femtocell.
[0507] 1. Circuit Mode Mobile-Originated SMS
[0508] FIG. 43 illustrates a mobile originated SMS transfer via GAN
circuit mode in some embodiments. As shown, the user enters a
message and invokes the mobile-originated SMS function on the UE
4305 in idle mode. Steps 4 to 10 in FIG. 43 are Steps 2 to 7 in the
"Mobile originated call" Subsection under the "CALL MANAGEMENT"
Section, above. Next, the UE 4305 sends (in Step 8) the SMS message
encapsulated in a CP-DATA message to the FAP 4310 over the air
interface.
[0509] The FAP relays (in Step 9) the CP-DATA message encapsulated
in a GA-CSR UL DIRECT TRANSFER message to the INC 4315. The INC
forwards (in Step 10) the CP-DATA message to the MSC 4320 using
RANAP Direct Transfer message. The MSC forwards (in Step 11) the
message to the SMSC via the SMS interworking MSC (IWMSC) 4325 using
the MAP-MO-FORWARD-SM Invoke message.
[0510] The MSC sends (in Step 12) CP-DATA-ACK to acknowledge the
receipt of the CP-DATA message. The SM-CP is designed in a way that
every CP-DATA block is acknowledged on each point-to-point
connection between the UE and SMSC (SM Service Center) to ensure
that the under-laying transport layer (in this case RANAP) works
error free since there is no explicit ack to a RANAP Direct
Transfer message.
[0511] The INC 4315 relays (in Step 13) the acknowledgement to the
FAP 4310. The FAP forwards (in Step 14) the CP-DATA-ACK to the UE
4305 over the air interface. The SMSC sends (in Step 15) a SMS
message in response to the IWMSC and the IWMSC sends the response
to the MSC in the MAP-MO-FORWARD-SM Return Result message.
[0512] Next, the MSC 4320 relays the response (in Step 16) to the
INC 4315 in the CP-DATA message. The INC 4315 relays (in Step 17)
this to the FAP 4310 using GA-CSR DL DIRECT TRANSFER. The FAP
relays (in Step 18) the response to the UE over the air interface
using the existing RRC connections.
[0513] As part of SM-CP ack process, the UE acknowledges (in Step
19) the receipt of CP-DATA to the FAP. The FAP relays (in Step 20)
the acknowledgement to the INC. The INC forwards (in Step 21) the
acknowledgement to the MSC using the RANAP Direct Transfer
message.
[0514] Next, the MSC 4320 sends (in Step 22) Iu Release message to
the INC indicating a request to release the session resources. The
SCCP Connection Identifier is used to determine the corresponding
session. The INC 4315 in turn releases (in Step 23) the GA-CSR
connection to the FAP for the specific session. Also, the FAP 4310
releases (in Step 24) corresponding radio resources towards the UE.
Finally, the INC acknowledges (in Step 25) the release in an Iu
Release Complete message to the MSC. The SCCP connection associated
with the call between the INC and the MSC is released.
[0515] 2. CS Mode Mobile-Terminated SMS
[0516] FIG. 44 illustrates a CS mode mobile terminated SMS transfer
via Femtocell in some embodiments. As shown, the SMSC 4425 sends
(in Step 1) a SMS message destined for the UE 4405 to the SMS
gateway MSC (GMSC) 4420. The GMSC queries the HLR for routing
information using the MAP-SEND-ROUTING-INFO-SM Invoke message.
[0517] The HLR responds (in Step 2) with the MSC number associated
with the serving MSC. The SMS GMSC delivers (in Step 3) the SMS
message to the MSC using the MAP MT-FORWARD-SM Invoke message.
Steps 4 to 10 are the same as Steps 2 to 8 in "Mobile Terminated
Call" Section above, except that the user is attempting to
terminate an SMS message; therefore, only a signaling channel is
necessary.
[0518] Next, the MSC 4420 sends (in Step 11) the SMS message
encapsulated in a CP-DATA message to the INC 4415. The INC relays
(in Step 12) this to the FAP 4410 using GA-CSR DL DIRECT TRANSFER.
The FAP relays (in Step 13) the CP-DATA message to the UE 4405 over
the air interface using the existing RRC connections.
[0519] As part of SM-CP ack process, the UE acknowledges (in Step
14) the receipt of CP-DATA to the FAP. The FAP relays (in Step 15)
the acknowledgement to the INC. The INC forwards (in Step 16) the
acknowledgement to the MSC using the RANAP Direct Transfer
message.
[0520] The SMS entity on the UE acknowledges (in Step 17) the SMS
message via another CP-DATA message (response) which is sent to the
FAP over the air interface. The FAP relays (in Step 18) the
response CP-DATA message encapsulated in a GA-CSR UL DIRECT
TRANSFER message to the INC. The INC forwards (in Step 19) the
response CP-DATA message to the MSC using RANAP Direct Transfer
message.
[0521] Next, the MSC 4420 sends the response (in Step 20) to the
SMS GMSC 4425 in the MAP-MT-FORWARD-SM Return Result message. The
GMSC relays the response to the SMSC. The MSC acknowledges (in Step
21) the receipt of CP-DATA to the INC. The INC 4415 relays (in Step
22) the CP-DATA-ACK to the FAP.
[0522] Next, the FAP 4410 forwards (in Step 23) the CP-DATA-ACK to
the UE 4405 over the air interface. The MSC 4420 sends (in Step 24)
Iu Release message to the INC 4415 indicating a request to release
the session resources. The SCCP Connection Identifier is used to
determine the corresponding session.
[0523] The INC 4415 in turn releases (in Step 25) the GA-CSR
connection to the FAP for the specific session. The FAP releases
(in Step 26) corresponding radio resources towards the UE. The INC
acknowledges (in Step 27) the release in an Iu Release Complete
message to the MSC. The SCCP connection associated with the call
between the INC and the MSC is released XI. EMERGENCY SERVICES
[0524] Transparent support for emergency services is a key
regulatory requirement. Femtocell emergency services support
capabilities include support for flexible UMTS-to-Femtocell SAI
mapping and INC assignment functionality. This allows the FAP to be
assigned to an INC that is, in turn, connected to an MSC that can
route calls to the PSAP in the Femtocell service area. It also
allows the service provider to define Femtocell service areas that
align with macro network service areas, to leverage the existing
service area based PSAP routing approach.
[0525] Femtocell emergency services support capabilities also
include support for the retrieval and storage of FAP location
information from an external database, using the enhanced service
access control functions. Femtocell emergency services support
capabilities further include support for the RANAP Location Report
procedure, by which the INC returns the FAP location information to
the MSC during emergency call processing. Some embodiments do not
support emergency calling from an un-authorized UE over a given FAP
(due to the Service Access Control for the specific FAP).
[0526] One of the functions of the UMTS-Femtocell mapping process
is to assign a Femtocell Service Area for calls made by the UE
using the Femtocell. The FAP, during registration, provides
information on macro coverage (such as macro LAI, macro 3G cell-id,
etc) which can be mapped to a Femtocell Service Area Identification
(SAI). This Femtocell SAI can be used to support the ability to
route emergency calls to the correct PSAP; i.e., based on SAI.
However, to meet the requirement to route the emergency call to the
correct PSAP, there are actually two possible approaches: (1)
Service Area (i.e. SAI) Based Routing, and (2) Location Based
Routing.
[0527] A. Service Area Based Routing
[0528] With Service Area Based Routing, the PSAP routing decision
is based on the Service Area Code (SAC) included within the SAI.
FIG. 45 illustrates a service area based routing scenario of some
embodiments. As shown, the user originates (in Step 1) an emergency
call using the UE 4505 camped on the Femtocell. The UE establishes
(in Step 2) a RRC connection with the FAP with the establishment
cause of emergency call.
[0529] Upon request from the upper layers, the UE sends (in Step 3)
the CM Service Request (with CM Service Type set to "Emergency Call
Establishment") to the FAP 4510. The FAP performs (in Step 4) the
GA-CSR Connection Establishment procedure (with establishment cause
indicating an Emergency call) with the INC 4515 as described in
previous sections.
[0530] The FAP 4510 then forwards (in Step 5) the CM Service
Request to the INC 4515 using a GA-CSR UL DIRECT TRANSFER message.
The INC 4515 establishes a SCCP connection to the MSC 4520 and
forwards (in Step 6) the CM Service Request to the MSC 4520 using
the RANAP Initial UE Message. This initial message includes
information about the location area (LAI) and service area (SAI)
assigned to the specific FAP over which the emergency call was
initiated.
[0531] The MSC 4520, INC 4515 and UE 4505 continue (in Step 7) call
establishment signaling. The MSC determines the serving PSAP based
on the service area of the calling UE and routes (in Step 8) the
emergency call to the appropriate PSAP. Additional signal messages
are exchanged between the UE and PSAP and the emergency call is
established (in Step 9) between the UE and the appropriate serving
PSAP.
[0532] B. Location Based Routing
[0533] One of the drawbacks service area based routing is that it
would require that Femtocell service area be split into multiple
service areas based on PSAP routing requirements. The location
based routing method removes this limitation. Location based
routing is also known as "X/Y routing" or "Routing by position" and
is defined in "Location Services (LCS); Functional description;
Stage 2", 3GPP TS 23.271. Some embodiments support Location based
routing while some other embodiments do not support Location based
routing.
XII. FEMTOCELL SECURITY
[0534] GAN Femtocell supports security mechanisms at different
levels and interfaces as depicted in FIG. 46. As shown, the
security mechanisms over the Up interface 4605 protect signaling,
voice and data traffic flows between the FAP 4610 and the GANC SeGW
4615 from unauthorized use, data manipulation and eavesdropping;
i.e. authentication, encryption and data integrity mechanisms are
supported.
[0535] Authentication of the subscriber by the core network occurs
between the MSC/VLR or SGSN 4620 and the UE 4625 and is transparent
to the GANC 4640. The air interface between the UE 4625 and FAP
4610 is protected via encryption (ciphering) and integrity checks.
In some embodiments the use of ciphering on the air interface is
optional.
[0536] Additional application level security mechanisms may be
employed in the PS domain to secure the end-to-end communication
between the FAP 4605 and the application server 4630. For example,
the FAP may run the HTTP protocol over an SSL session for secure
web access.
[0537] All signaling traffic and user-plane traffic sent between
FAP and GANC over the Up interface 4605 is protected by a secure
tunnel (e.g., an IPSec tunnel) between the FAP 4605 and GANC-SeGW
4615, that provides mutual authentication (using SIM or USIM
credentials), encryption and data integrity using the same
mechanisms as specified in "3G security; Wireless Local Area
Network (WLAN) interworking security", 3GPP TS 33.234 standard,
hereinafter "TS 33.234 standard". The use of a single secure tunnel
between the FAP 4610 and the GANC 4640 enables multiple UEs 4625
(only one is shown in FIG. 46 for simplicity) as well as the
Femtocell itself (e.g., the FAP signaling or when the FAP supports
local service using the FAP IMSI, the signaling and the user plane
for the FAP utilize the same IPSec tunnel). The advantages of using
a single IPSec tunnel between the FAP and the GANC include
relieving the SeGW from supporting a large number of secure
tunnels.
[0538] A. Authentication
[0539] In some embodiments, the Up interface supports the ability
to authenticate the FAP with the GANC (for the purposes of
establishing the secure tunnel) using UMTS credentials.
Authentication between FAP and GANC shall be performed using
EAP-AKA or EAP-SIM within IKEv2.
[0540] The FAP and GANC-SeGW establish a security association for
protecting signaling traffic and user-plane (voice and data)
traffic. The protocol for authentication is IKEv2. Mutual
authentication and key generation is provided by EAP-AKA or
EAP-SIM.
[0541] The basic elements of these procedures are the following.
The FAP connection with the GANC-SeGW is initiated by starting the
IKEv2 initial exchanges (IKE_SA_INIT). The EAP-AKA or EAP-SIM
procedure is started as a result of these exchanges. The EAP-SIM
procedure for FAP with SIM only or FAP with USIM, but not capable
of UMTS AKA, is performed between FAP and AAA server (that has
access to the AuC/HLR/HSS to retrieve subscriber information). The
EAP-AKA procedure for FAP with USIM and the FAP is capable of UMTS
AKA, is performed between FAP and AAA server. The GANC-SeGW acts as
relay for the EAP-SIM/EAP-AKA messages.
[0542] When the EAP-AKA/EAP-SIM procedure has completed
successfully, the IKEv2 procedure can be continued to completion
and the signaling channel between FAP and GANC-SeGW is secured. The
FAP can then continue with the discovery or registration procedure.
Signaling flows for EAP-AKA/EAP-SIM authentication are shown in the
following subsection.
[0543] 1. EAP-SIM Procedure for Authentication
[0544] The EAP-SIM authentication mechanism is specified in
"Extensible Authentication Protocol Method for GSM Subscriber
Identity Modules (EAP-SIM)", IETF RFC 4686. This section describes
how this mechanism is used in Femtocell. FIG. 47 illustrates
EAP-SIM authentication procedure in some embodiments. As shown, the
FAP 4705 connects to the generic IP access network and obtains (in
Step 1) the IP address of the Default or the Serving SeGW via DNS
query. In response, the DNS server 4710 returns (in Step 2) the IP
address of the SeGW.
[0545] Next, the FAP 4705 initializes the IKEv2 authentication
procedure by starting (in Steps 3a-3c) the IKE_SA_INIT exchange. It
indicates the desire to use EAP by leaving out the AUTH payload
from message 3, the first message of the IKE_AUTH exchange, and the
initiator identity is composed compliant with the Network Access
Identifier (NAI) format specified in "The Network Access
Identifier", IETF RFC 2486, hereinafter "IETF RFC 2486", which
includes the IMSI and an indication that EAP-SIM should be
used.
[0546] Next, the GANC-SeGW 4715 sends (in Step 4) an EAP
Response/Identity message to the AAA server 4720, including the
initiator identity included in the third IKE message. The leading
digit of the NAI indicates that the FAP wishes to use EAP-SIM. The
AAA server 4720 identifies the subscriber as a candidate for
authentication with EAP-SIM, based on the received identity, and
verifies that EAP-SIM shall be used based on subscription
information. The AAA then sends (in Step 5) the EAP
Request/SIM-Start packet to GANC-SeGW 4715.
[0547] The GANC-SeGW forwards (in Step 6) the EAP Request/SIM-Start
packet to FAP. The FAP chooses a fresh random number NONCE_MT. The
random number is used in network authentication. The FAP sends (in
Step 7) the EAP Response/SIM-Start packet, including NONCE_MT, to
the GANC-SeGW.
[0548] The GANC-SeGW forwards (in Step 8) the EAP
Response/SIM-Start packet to the AAA Server. The AAA server 4720
requests (in Step 9) authentication data from the HLR 4725, based
on the IMSI. The AAA server could instead use cached triplets
previously retrieved from the HLR to continue the authentication
process.
[0549] Optionally, the AAA 4720 receives (in Step 10) user
subscription and multiple triplets from the HSS/HLR 4725. AAA
server determines the EAP method (SIM or AKA) to be used, according
to the user subscription and/or the indication received from the
FAP. In this sequence diagram, it is assumed that the FAP holds a
SIM and EAP-SIM will be used.
[0550] The AAA server formulates an EAP-SIM/Challenge with multiple
RAND challenges, and includes a message authentication code (MAC)
whose master key is computed based on the associated Kc keys, as
well as the NONCE_MT. A new re-authentication identity may be
chosen and protected (i.e. encrypted and integrity protected) using
EAP-SIM generated keying material. The AAA Server sends (in Step
11) this RAND, MAC and re-authentication identity to the GANC-SeGW
in the EAP Request/SIM-Challenge message. The GANC-SeGW forwards
(in Step 12) the EAP Request/SIM-Challenge message to the FAP.
[0551] The FAP runs (in Step 12) N times the GSM A3/A8 algorithm in
the SIM, once for each received RAND. This computing gives N SRES
and Kc values. The FAP calculates its copy of the network
authentication MAC with the newly derived keying material and
checks that it is equal with the received MAC. If the MAC is
incorrect, the network authentication has failed and the FAP
cancels the authentication. The FAP continues the authentication
exchange only if the MAC is correct. The FAP calculates a new MAC
with the new keying material covering the EAP message concatenated
to the N SRES responses. If a re-authentication ID was received,
then the FAP stores this ID for future authentications.
[0552] The FAP 4705 sends (in Step 14) EAP Response/SIM-Challenge
including calculated MAC to the GANC-SeGW 4715. The GANC-SeGW
forwards (in Step 15) the EAP Response/SIM-Challenge message to the
AAA Server 4720. The AAA Server verifies (in Step 16) that its copy
of the response MAC is equal to the received MAC.
[0553] If the comparison in step 16 is successful, then the AAA
Server sends (in Step 17) the EAP Success message to the GANC-SeGW.
The AAA Server includes derived keying material for confidentiality
and/or integrity protection between FAP and GANC-SeGW, in the
underlying AAA protocol message (i.e. not at EAP level).
[0554] The GANC-SeGW informs (in Step 18) the FAP about the
successful authentication with the EAP Success message. Now the
EAP-SIM exchange has been successfully completed, the IKE signaling
can be completed (in Step 19). The Secure Association between FAP
and GANC-SeGW has been completed and the FAP can continue with the
Femtocell discovery or registration procedure.
[0555] 2. EAP-AKA Procedure for Authentication
[0556] The EAP-AKA authentication mechanism is specified in
"Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA)", IETF RFC 4187. This
section describes how this mechanism is used in Femtocell. FIG. 48
illustrates EAP-AKA authentication procedure of some embodiments.
As shown, the FAP 4805 connects to the generic IP access network
and obtains (in Step 1) the IP address of the Default or the
Serving SeGW via DNS query. The DNS server 4810 returns (in Step
10) the IP address of the SeGW.
[0557] The FAP 4805 initializes the IKEv2 authentication procedure
by starting the IKE_SA_INIT exchange (Steps 3a-3c). It indicates
the desire to use EAP by leaving out the AUTH payload from message
3, the first message of the IKE_AUTH exchange, and the initiator
identity is composed compliant with the Network Access Identifier
(NAI) format specified in the IETF RFC 2486 which includes the IMSI
and an indication that EAP-AKA should be used.
[0558] Next, the GANC-SeGW 4815 sends (in Step 4) an EAP
Response/Identity message to the AAA server 4820, including the
initiator identity included in the third IKE message. The leading
digit of the NAI indicates that the FAP wishes to use EAP-AKA. The
AAA server identifies the subscriber as a candidate for
authentication with EAP-AKA, based on the received identity, and
verifies that EAP-AKA shall be used based on subscription
information, The AAA server requests (in Step 5) the user profile
and UMTS authentication vector(s) from the HSS/HLR 4825, if these
are not available in the AAA server.
[0559] Optionally, the AAA receives (in Step 6) user subscription
and UMTS authentication vector(s) from the HSS/HLR. The UMTS
authentication vector consists of random part (RAND), an
authentication token (AUTN), an expected result part (XRES) and
sessions keys for integrity check (IK) and encryption (CK). The AAA
server determines the EAP method (SIM or AKA) to be used, according
to the user subscription and/or the indication received from the
FAP. In this sequence diagram, it is assumed that the FAP holds a
USIM and EAP-AKA will be used.
[0560] Next, the AAA server 4820 formulates an EAP-Request/AKA
Challenge with RAND, AUTN and includes a message authentication
code (MAC) whose master key is computed based on the associated IK
and CK. A new re-authentication identity may be chosen and
protected (i.e. encrypted and integrity protected) using EAP-AKA
generated keying material. The AAA Server sends (in Step 7) the
RAND, AUTN, MAC and re-authentication identity to the GANC-SeGW
4815 in the EAP Request/AKA-Challenge message.
[0561] The GANC-SeGW forwards (in Step 8) the EAP
Request/AKA-Challenge message to the FAP. The FAP runs (in Step 9)
UMTS algorithm on the USIM. The USIM verifies that the AUTN is
correct and hereby authenticates the network. If AUTN is incorrect,
the FAP rejects the authentication. If AUTN is correct, the USIM
computes RES, IK and CK. The FAP calculates a new MAC with the new
keying material (IK and CK) covering the EAP message. If a
re-authentication ID was received, then the FAP stores this ID for
future authentications.
[0562] The FAP then sends (in Step 10) EAP Response/AKA-Challenge
including calculated RES and MAC to the GANC-SeGW. The GANC-SeGW
forwards (in Step 11) the EAP Response/AKA-Challenge message to the
AAA Server.
[0563] The AAA Server verifies (in Step 12) the received MAC and
compares XRES to the received RES. If the checks in Step 12 are
successful, then the AAA Server sends (in Step 13) the EAP Success
message to the GANC-SeGW. The AAA Server includes derived keying
material for confidentiality and/or integrity protection between
FAP and GANC-SeGW, in the underlying AAA protocol message (i.e. not
at EAP level).
[0564] The GANC-SeGW informs (in Step 14) the FAP about the
successful authentication with the EAP Success message. Now the
EAP-SIM exchange has been successfully completed, the IKE signaling
can be completed (in Step 15). The Security Association between FAP
and GANC-SeGW has been completed and the FAP can continue with the
Femtocell discovery or registration procedure.
[0565] 3. Fast Re-Authentication
[0566] When the authentication process is performed frequently,
especially with a large number of connected Femtocell Access
Points, performing fast re-authentication can reduce the network
load resulting from this authentication. The fast re-authentication
process allows the AAA server to authenticate a user based on keys
derived from the last full authentication process.
[0567] The FAP and GANC-SeGW can use a procedure for fast
re-authentication in order to re-authenticate an FAP e.g. when
setting up a new SA because the IP address of the FAP has changed.
Fast re-authentication is provided by EAP-AKA, and does not make
use of the UMTS algorithms. The FAP may use the re-authentication
ID in the IKE_SA_INIT. The decision to make use of the fast
re-authentication procedure is taken by the AAA server.
[0568] The basic elements of these procedures are the following.
The FAP initiates a new SA with a GANC-SeGW that it was previously
connected to and uses the re-authentication ID (re-authentication
ID received during the previous full authentication procedure) in
the IKE_SA_INIT exchange. The EAP-AKA procedure is started as a
result of these exchanges. The AAA server and FAP re-authenticate
each other based on the keys derived on the preceding full
authentication.
[0569] B. Encryption
[0570] All control and user plane traffic over the Up interface
shall be sent through the IPSec tunnel that is established as a
result of the authentication procedure. Encryption shall use the
negotiated cryptographic algorithm, based on core network policy,
enforced by the GANC-SeGW.
[0571] The FAP and GANC-SeGW set up one Security Association
through which all traffic is sent. A single negotiated ciphering
algorithm is applied to the connection.
[0572] 1. Establishment of a Security Association
[0573] After the authentication procedure, the FAP shall request an
IP address on the network protected by the GANC-SeGW (i.e. the
public IP interface of the INC). The FAP shall set up one IPSec
Security Association (SA) between FAP and GANC-SeGW.
[0574] The FAP shall initiate the creation of the SA; i.e. it shall
act as initiator in the Traffic Selector negotiation. The protocol
ID field in the Traffic Selectors (TS) shall be set to zero,
indicating that the protocol ID is not relevant. The IP address
range in the TSi shall be set to the address assigned to the FAP
(within the network protected by the GANC-SeGW). The IP address
range in the TSr shall be set to 0.0.0.0-255.255.255.255. The FAP
and GANC-SeGW shall use the IKEv2 mechanisms for detection of NAT,
NAT traversal and keep-alive.
[0575] All control and user plane data over the Up interface
between FAP and INC shall be sent through the SA. The ciphering
mode is negotiated during connection establishment. During setup of
the SA, the FAP includes a list of supported encryption algorithms
as part of the IKE signaling, which include the mandatory and
supported optional algorithms defined in the IPSec profile, and
NULL encryption. The GANC-SeGW selects one of these algorithms, and
signals this to the FAP.
[0576] When NULL encryption is applied, both control and user-plane
traffic is sent unencrypted. This configuration can be selected
e.g. when the connection between the generic IP access network and
the GANC is under operator control. The integrity algorithm is the
same as for either configuration i.e. non-ciphered traffic is still
integrity protected.
[0577] C. Profile of IKEv2
[0578] In some embodiments, profile of IKEv2 for Femtocell system
is similar to the profile defined in TS 43.318 standard.
[0579] D. Profile of IPSec ESP
[0580] In some embodiments, profile of IPSEC ESP for Femtocell
system is similar to the profile defined in TS 43.318 standard.
[0581] E. Security Mode Control
[0582] FIG. 49 illustrates the message flow for security mode
control in some embodiments. As shown, the CN (VLR/SGSN) 4920 and
the UE 4905 perform (in Step 1) mutual authentication using AKA
procedures. The CN authentication is initiated by the CN as a
result of the CN processing an initial L3 message from the UE.
[0583] Upon successful authentication, the CN sends (in Step 2)
RANAP "Security Mode Command" message to GANC. This message
includes the integrity key (IK) key, the ciphering (or encryption)
key (CK), the user integrity algorithm (UIA), and the ciphering (or
user encryption) algorithm (UEA) to be used for ciphering.
[0584] In some embodiments, the GANC stores the ciphering and
integrity keys and the algorithms. The GANC sends (in Step 3) a
GA-CSR SECURITY MODE COMMAND with the ciphering and integrity keys
and algorithms associated with the specific UE IMSI to the FAP
4910. The FAP stores the ciphering and integrity keys and algorithm
(in Step 4) for the specific UE. The FAP should ensure that these
keys are not accessible to 3.sup.rd party applications or any other
module on the FAP. Additionally, these keys should not be stored on
any persistent storage. The CK and UEA are used to protect the air
interface between the FAP and the UE by encrypting the traffic
between the FAP and the UE. The IK and the UIA are used to ensure
the integrity of the messages exchanged between the FAP and the UE
over the air interface, for example by determining that the
messages are not changed. In some embodiments, the UIA and the UEA
are software methods executed by a processor.
[0585] The FAP generates a random number (FRESH) and computes the
downlink (i.e., from the FAP to the UE) message authentication code
(MAC) using the integrity key (IK) and integrity algorithms (MAC-I)
and sends (in Step 5) the Security Mode command to the UE 4905
along with the computed message authentication code for integrity
(MAC-I) and the FRESH. The FRESH variable represents a random
number or nonce as defined in "3G Security; Security architecture",
3GPP TS 33.102 standard, hereinafter "TS 33.102 standard". The UE
computes (in Step 6) the MAC-I locally (expected MAC-I or XMAC-I)
and verifies (in Step 6) that the received downlink MAC-I is same.
The UE computes XMAC-I on the message received by using the
indicated UIA, COUNT-I generated from the stored START and the
received FRESH parameter as defined in TS 33.102 standard. The
downlink integrity check is started from this message onwards. For
all subsequent messages sent from the FAP to the UE (the downlink
messages), steps similar to Steps 5 to 6 are used to ensure the
integrity of the messages.
[0586] Upon successful verification of the MAC, the UE responds
back (in step 7) with the Security Mode Complete command and also
sends the MAC-I for the uplink (i.e., from the UE to the FAP)
message. The FAP computes (in Step 8) XMAC-I for the uplink message
and verifies (in Step 8) the received MAC-I is same as that of
computed XMAC-I. The uplink integrity check is started from this
message onwards. For all subsequent messages sent from the UE to
the FAP (the uplink messages), steps similar to Steps 7 to 8 are
used to ensure the integrity of the messages.
[0587] MAC-I is the sender's computed MAC-I and XMAC-I is the
expected MAC-I computed by the receiver. As described above, the
computation is done for a given message using the algorithms and
other variables which are known to the sender and receiver only.
This prevents a man-in-the-middle attack, as the middle entity will
not have the necessary information to compute MAC-I and hence
cannot tamper the message.
[0588] Upon successful verification of the uplink MAC, the FAP
sends (in Step 9) the GA-CSR Security mode complete command to the
GANC. The GANC relays (in Step 10) the Security Mode Complete
command to the CN via corresponding RANAP message.
[0589] F. Core Network Authentication
[0590] The core network AKA based authentication provides mutual
authentication between the user and the network. The AKA procedure
is also used to generate the ciphering keys (encryption and
integrity) which in turn provide confidentiality and integrity
protection of signaling and user data. The basis of mutual
authentication mechanism is the master key K (permanent secret with
a length of 128 bits) that is shared between the USIM of the user
and home network database. The ciphering key (Ck) and the integrity
key (Ik) are derived from this master key K.
[0591] FIG. 50 illustrates the AKA procedure used for mutual
authentication in some embodiments. As shown, when the UE 5005
camps on the Femtocell Access Point 5010, it initiates (in Step 1)
a Location Update Request (or Location Updating Request) towards
the CN. The INC 5015 forwards) in Step 2) the Location Update
request in a RANAP message to the VLR/SGSN 5020.
[0592] This triggers the authentication procedure in the VLR/SGSN
and it sends (in Step 3) an authentication data request MAP message
to the Authentication Center (AuC) in the Home Environment (HE)
5025. The AuC includes the master keys of the UEs and based on the
IMSI, the AuC will generate the authentication vectors for the
specific UE. The vector list is sent back (in Step 4) to the
VLR/SGSN in the authentication data response MAP message.
[0593] The VLR/SGSN selects (in Step 5) one authentication vector
from the list (only 1 vector is needed for each run of the
authentication procedure). The VLR/SGSN sends (in Step 6) user
authentication request (AUTREQ) message to the INC. This message
also includes two parameters RAND and AUTN (from the selected
authentication vector).
[0594] The INC 5015 relays (in Step 7) the AUTREQ message to the
FAP 5010 in a GA-CSR DL DIRECT TRANSFER message. The FAP forwards
(in Step 8) the AUTREQ to the UE over the air interface. The USIM
on the UE includes the master key K and using it with the
parameters RAND and AUTN as inputs, the USIM carries out
computation resembling generation of authentication vectors in the
AuC. From the generated output, the USIM verifies (in Step 9) if
the AUTN was generated by the right AuC.
[0595] The USIM computation also generates (in Step 10) a RES which
is sent towards the CN in an authentication response message to the
CN. The FAP forwards (in Step 11) the Authentication Response to
INC. The INC relays (in Step 12) the response along with the RES
parameter in a RANAP message to the CN.
[0596] The VLR/SGSN verifies (in Step 13) compares the UE response
RES with the expected response XRES (which is part of
authentication vector). If there is a match, authentication is
successful. The CN may then initiate (in Step 14) a Security Mode
procedure (as described in the Subsection "Security mode control",
above) to distribute the ciphering keys to the INC.
[0597] G. Service Theft in Femtocell
[0598] By definition, the FAP has a radio interface (Uu) to
communicate with UEs and a network interface (Up) to the mobile
network. The FAP relays messages between the UE and core network
and can eavesdrop and intercept these messages. The FAP, if
compromised, becomes the infamous `man` of the man-in-the-middle
security exposure.
[0599] In normal operation, the macro cell network directs UEs to
scan for the Femtocell UTRA Absolute Radio Frequency Channel Number
(UARFCN) and scrambling code (SC) so when a UE detects FAP radio
coverage, the UE can attempt to camp on the FAP. The FAP {UARFCN,
SC} is expected to be configured in the macro network RNC's
neighbor cell list so that RNC can provide the UE with this
neighbor cell list, thus resulting in the UE performing the scans
of the neighbors cells and eventual cell selection of a better
neighbor for camping. The UE performs a location update, provides
its identity, whether IMSI or TMSI, expects to be authenticated,
and then proceeds to camp on the Femtocell for mobile service. This
is exactly what is supposed to happen when the UE visits a network
authorized FAP.
[0600] When the FAP is compromised or is a rogue, then the UE could
be exposing itself to theft of service. When the UE provides its
identity to the FAP, the FAP can masquerade as the UE to the mobile
network. Normally, UE authentication would prevent this kind of
identity theft, but being in the middle of the communication
between the core network and the UE, the FAP can relay
authentication requests to the victim UE to defeat
authentication.
[0601] The UE believes it is being authenticated by the network and
provides the correct authentication response to the FAP. The FAP
sends the correct response to the core network and the core network
now believes the FAP has been authenticated. In between network
initiated authentication requests, the FAP can request and receive
service from the mobile network disguised as the victim UE. For
example, calls originated by the FAP would now be charged to the
victim UE. UMTS signaling message integrity mechanisms do not help
in this case because the integrity protection is provided over the
air interface between the UE and the FAP.
[0602] Since the FAP is in the possession of the end user and
communicates with the GANC over the Internet, it is possible for a
compromised or rogue FAP to attempt to circumvent the UMTS security
architecture. A rogue FAP is the classical man-in-the-middle
attacker between the UE and the CN. Without adequate network
security validations and the enforcement of access policies, rogue
FAPs can masquerade as a victim UE and use mobile network services
using the victim UE's identity. A FAP is categorized in the
following three access control modes: closed access, semi-open
access, or open access.
[0603] In a closed access case, access to complete Femtocell
services over a given FAP is restricted to a closed group of
subscribers. In a semi-open access case, limited access is provided
to all subscribers. A subscriber who is not part of the closed
group is allowed to receive incoming calls and SMS over the
semi-open FAP. Additionally, the subscriber is also allowed to make
emergency calls using the FAP operating in semi-open access mode.
All other services, such as outgoing calls, are blocked. Finally,
in an open access case, all subscribers of a given operator are
allowed full service access over a FAP operating in open access
mode. The following techniques are used in some embodiments to
protect against UE masquerade and theft of service at a FAP
operating in one of above mentioned modes.
[0604] 1. Closed Access Points
[0605] In a closed access FAP, UEs that are members of the FAP's
private user group cannot be victimized because the FAP and the UEs
in the private user group are linked by the subscription process.
The GANC can enforce network-based service access controls to
prevent victim UEs from being trapped by a rogue FAP. If the UE is
not a member of the private user group of the rogue FAP, the GANC
will deny service access to the UE. This means the rogue FAP is
prevented from stealing service with the victim UE's identity.
[0606] The GANC also strictly binds transactions performed under
each UE registration context to the original authorized UE identity
to prevent a rogue FAP from piggybacking messages using a victim UE
identity through the authorized UE context. The strict binding
requires the GANC to track the identity of each UE even as it is
assigned TMSI and P-TMSI for User Identity Confidentiality.
Prevention of service theft in a closed access mode is described in
detail further below.
[0607] 2. Semi-Open and Open Access Points
[0608] The potential for a rogue FAP to masquerade as a victim UE
is only available on the semi-open and open access points. The
victim UEs would be the UEs that the network allows to camp on the
rogue FAP but is not a member of the FAP's private user group. For
those UEs, the theft of service potential is real because the rogue
FAP has an incentive to charge its usage to the victim UE
subscription account.
[0609] Note, the theft-of-service scenario is only possible while a
victim UE is camped on the rogue FAP. The rogue FAP can
authenticate to the core network (CN) as the UE and then request
services from the CN masquerading as the UE. So long that the
victim UE remains camped at the rogue FAP, the FAP can continue to
pass authentication requests and carry on the masquerade.
[0610] For semi-open FAPs, by definition, prevents outgoing
services to be initiated by UEs that are not a member of the FAP's
private user group. Network-based enforcement of the semi-open
access controls can prevent rogue FAPs from stealing service by
masquerading as a victim UE. However, a rogue FAP can block
incoming calls to the victim UE or eavesdrop on the conversation
while the victim UE is camped on the rogue FAP. The semi-open FAP
scenario is similar to the open FAP scenario described below.
[0611] For open FAPs, the GANC by definition cannot place
restrictions on the usage of mobile network services for any UE. It
is also not possible to determine on a per call basis whether the
call was legitimately made by the UE or whether the FAP is
masquerading as a victim UE. This makes network enforcement of UE
access controls ineffective for preventing UE masquerade. The
prevention method must focus on ensuring only genuine and
unmodified FAPs are granted open access.
[0612] 3. Enhanced Security Solution for Open Access Points
[0613] Open FAPs can be misused through the following two
scenarios: (1) Complete replacement of a genuine FAP with rogue
equipment and (2) Modification of the existing software executing
on the FAP from an authorized vendor.
[0614] a) Detection of Genuine FAP
[0615] The replacement of a genuine FAP with rogue equipment can be
prevented using a technique based on public and private keys. In
this solution the FAP is required to provide a Message
Authentication Code (MAC), computed from the vendor's private key,
with the UMA Registration message. The GANC, using the AAA, can
verify the MAC on the UMA Registration message by comparing the MAC
with one computed with the FAP vendor's public key. Only genuine
FAPs can provide the correct MAC in the UMA Registration
message.
[0616] Procedure details are as follows. Each FAP vendor generates
a private/public key pair. The public key is stored in a FAP
database in the network. When the FAP registers with the GANC, the
GANC sends a Register challenge message by including a RAND number
in the challenge. The FAP sends the challenge response and includes
the MAC (message authentication code) generated using the vendor's
private key. The MAC is generated using the standard algorithms for
SHA1.
[0617] The GANC relays the random number and the generated MAC to
the AAA via the S1 interface. The AAA retrieves the public key from
the FAP database and computes its expected MAC. If the locally
computed MAC is the same as that received over the network, then
AAA has verified the FAP is genuine. If the MAC check in the AAA
fails, the registration is rejected thus preventing access to
services using the GANC. Note there is one private key for all FAPs
from the same vendor so every FAP has the same image. The private
key should never be stored in an unencrypted fashion. This
detection method must be combined with the following method to
protect the private keys from being extracted from the FAP.
[0618] b) Ensuring Unmodified FAPs
[0619] The FAP hardware may implement a "software authentication"
technique to ensure only authentic, authorized software is allowed
to execute on the FAP hardware. Some embodiments perform the
following software authentication technique. The "bootloader"
software, which is responsible for establishing the initial state
of the system, so that the proper operating system and application
can be loaded, will control the download and authorization of the
software. The "bootloader" software must be implicitly trusted and
therefore needs to be immutable. This requirement can be met, for
example, by implementing the bootloader software in ROM or OTP
flash.
[0620] The software loaded on the FAP is signed using the private
key for each vendor. The bootloader software would be responsible
for verification of this signature using the public key of the
vendor. A failed signature check will prevent the "rogue" software
from executing successfully. Note that the public key can be
delivered to the bootloader software via signed certificates or it
can be stored directly locally in the bootloader.
[0621] The above technique prevents the loading of software onto
the FAP hardware by anyone except the vendor. Only the vendor
possesses the private key necessary to sign the software and pass
the "software authentication."
[0622] 4. High Level Procedure
[0623] FIG. 51 illustrates the high level procedure which can
result in theft of service by a rogue FAP. The following
description of the Femtocell service theft procedure assumes the
following: (1) the Rogue FAP is a closed AP i.e. Femtocell service
access is limited to a trusted list of UEs (in this example, only
UE-1 associated with identity IMSI-1/TMSI-1 is allowed Femtocell
service access using the Rogue FAP), (2) closed AP has implied
security as part of mutual trust between FAP and the associated
UEs. The close AP behavior is ensured by the network using service
access control (SAC) at the time of UE registration, (3) victim UE
is associated with identity IMSI-2/TMSI-2 and is NOT allowed
service on this Rogue FAP, and (4) the `Rogue` FAP has been
compromised and is attempting to steal services using victim UE
identity outside the trust list. Although FIGS. 51 to 53 illustrate
steps related to circuit switched resources (CSR), a person of
ordinary skill in the art would be able to apply the same
techniques to packet switched resources (PSR).
[0624] As shown in FIG. 51, the authorized UE 5110 establishes (in
Step 1a) a RRC connection with the FAP 5115 on which it camps. The
UE 5110 starts (in Step 1b) a Location Update procedure towards the
CN 5130. The FAP 5115 will intercept the Location Update request
and attempts to register the UE 5110 with the associated Serving
GANC 5120 over the existing IPSEC tunnel. The FAP 5115 may request
(in Step 1c) and receive (in Step 1d) the IMSI of the UE 5110 if
the Location Update is done using the TMSI, since the IMSI is
required for the initial registration of the UE.
[0625] Next, the FAP 5115 attempts to register the UE 5110 on the
GANC 5120 using the UE specific TCP connection by transmitting (in
Step 2) the GA-RC REGISTER REQUEST. The message includes: (1)
Registration Type: Indicates that the registering device is a UE,
(2) Generic IP access network attachment point information: AP-ID,
(3) UE Identity: UE-IMSI, and (4) FAP identity: FAP-IMSI. The GANC
5120 will, via AAA server 5125, authorize (in Steps 2a-2c) the UE
5110 using the information provided in the REGISTER REQUEST. The
authorization logic on the AAA server 5125 would also check to see
if the UE 5110 is allowed Femtocell access using the specific FAP
5115.
[0626] When the GANC 5115 accepts the registration attempt, the
GANC responds (in Step 3) with a GA-RC REGISTER ACCEPT. The FAP
5115 encapsulates (in Step 4) the Location Update NAS PDU within a
GA-CSR UL DIRECT TRANSFER message that is forwarded to the GANC
5120 via the existing TCP connection.
[0627] The GANC 5120 establishes a SCCP connection to the CN and
forwards (in Step 5) the Location Update request NAS PDU to the CN
using the RANAP Initial UE Message. Subsequent NAS messages between
the UE and core network will be sent between GANC and CN using the
RANAP Direct Transfer message. The CN 5130 authenticates (in Step
6) the UE 5110 using standard UTRAN authentication procedures. The
CN 5130 also initiates (also in Step 6) the standard Security Mode
Control procedure as described in TS 33.102 standard, which results
in distribution of the security keys {CK, IK} for the specific UE
to the FAP via the GANC.
[0628] Next, the CN 5130 indicates (in Step 7) that it has received
the location update and it will accept the location update using
the Location Update Accept message to the GANC 5120. The GANC 5120
forwards this message to the FAP 5115 in the GA-CSR DL DIRECT
TRANSFER. Next, the FAP relays (in Step 9) the Location Update
Accept over the air interface to the UE 5120.
[0629] At this point, a session authorized for the specific UE-1
using its credentials IMSI-1 is established (in Step 10) between
the FAP 5115 and GANC 5120. Next, a victim UE 5105, in the vicinity
of the rogue FAP 5115, upon discovering the FAP 5115 over the air
interface, will attempt to camp on the rogue FAP 5115 based on its
internal cell selection logic. This will trigger the UE 5105 to
establish (in Step 11a) an RRC connection with the Rogue FAP 5115.
The UE will then start (in Step 11b) a Location Update procedure
towards the CN 5130. The FAP 5115 will intercept the Location
Update request. The FAP will then request (in Step 11c) and receive
(in Step 11d) the IMSI of the victim UE 5105 if the Location Update
is done using the TMSI.
[0630] The rogue FAP instead of attempting a registration of the
victim UE 5105 with the GANC 5120, will re-use the existing
authorized session of UE-1 5110 (as described in step 10) to
transfer messages to the CN 5130 via GANC 5120. It is important to
note that if the registration for the victim UE was attempted by
the rogue FAP using the victim UE credentials (i.e. IMSI-2), the
network based SAC would have rejected the registration request
since the victim UE-2 5105 is not authorized to use Femtocell
service over the specific rogue FAP 5115.
[0631] The FAP 5115 encapsulates the Location Update NAS PDU within
a GA-CSR UL DIRECT TRANSFER message that is forwarded (in Step 13)
to the GANC 5120 via the existing TCP connection of UE-1 5110. The
GANC 5120 establishes a SCCP connection to the CN 5130 and forwards
(in Step 14) the Location Update request NAS PDU to the CN 5130
using the RANAP Initial UE Message. Subsequent NAS messages between
the UE 5105 and core network 5130 will be sent between GANC 5120
and CN 5130 using the RANAP Direct Transfer message.
[0632] Next, the CN 5130 authenticates (in Step 15) the victim UE-2
using standard UTRAN authentication procedures. The authentication
messages are relayed transparently to the UE 5105 by the GANC 5120
and FAP 5115. The CN 5130 also initiates (in Step 15) the standard
Security Mode Control procedure as described in TS 33.102 standard,
which results in distribution of the security keys {CK, IK} for the
victim UE to the FAP via the GANC.
[0633] Upon completion of the authentication, the CN 5130 indicates
(in Step 16) it has received the location update and it will accept
the location update using the Location Update Accept message to the
GANC 5120. The GANC 5120 forwards (in Step 17) this message to the
FAP 5115 in the GA-CSR DL DIRECT TRANSFER. The FAP 5115 relays (in
Step 17) the Location Update Accept over the air interface to the
victim UE.
[0634] The CN 5130 now thinks that the victim UE 5105 has been
authenticated via the FAP 5115 and the GANC 5120 and will accept
service requests from the victim UE 5105 without additional
authentication for a specific time window. This time window, during
which no addition authentication is performed for a given
subscriber, is typically controlled by the CN 5130 based on
specific implementation. The FAP 5115 takes advantage of this
window and can now initiate service requests using the victim UE
5105 credentials and identity e.g. the FAP 5115 can now originate a
Mobile Originated (MO) call using IMSI-2 as the subscriber identity
resulting in fraudulent charge to the victim UE's subscription. It
is important to note that even if the CN 5130 decides to
authenticate every service request from a given subscriber (such as
MO), the FAP 5115 can relay the authentication messages to the
victim UE 5105 and accomplish successful authentication to the CN
5130.
[0635] H. Mechanisms for Preventing Service Theft in Femtocell
[0636] In this sub-section, a GANC is disclosed that protects the
mobile network from the kind of man-in-the-middle theft scenario
described above. The theft-of-service risk is different for
different classes of UEs. For UEs that are affiliated with the FAP
through a linked subscription account such as a family plan, the
theft-of-service risk can be mitigated through the design of the
plan pricing to remove any incentive to mislead the network. The
FAP would only be stealing service from its own account.
[0637] For UEs that are not affiliated with the FAP, the theft of
service potential is real because the rogue FAP now has an
incentive to charge its usage to a victim UE account. The GANC has
the responsibility to prevent non-affiliated UEs from being
captured by the FAP. The GANC does this by restricting each FAP to
serve a defined list of affiliated UEs. The disclosed GANC
AAA-based service access controls provides the decision logic to
enable this UE restriction. Every UE access is individually
authorized through the AAA during the UE UMA registration. The AAA
only authorizes UE access after validating that the UE and the FAP
are affiliated and the UE access originated from the same IP
address, through the same IPSec tunnel as the FAP. The GANC
enforces the AAA authorization decision by accepting or denying the
UMA registration request for the UE.
[0638] In addition, all subsequent communications from the UE are
validated by the GANC to prevent rogue FAPs from attempting to
insert control plane messages for the victim UE into previously
authorized registration contexts. The GANC monitors the allocation
of TMSI and P-TMSI to the UE so it can associate the UE with any of
the UE's identities: IMSI, TMSI, and P-TMSI. This allows the GANC
to enforce the UE-FAP affiliation on communication between the UE
and the core network no matter whether the control plane messages
are addressed with the UE IMSI, TMSI, or P-TMSI. The following two
sub-sections describe the high level procedures with two different
approaches which prevent attempted service theft by a rogue FAP
[0639] 1. Service Theft Prevention--Approach 1
[0640] FIG. 52 illustrates the Femtocell service theft prevention
approach of some embodiments. Steps 1-7 are the same as Step 1-7
described in relation with FIG. 51 above. The GANC 5220 monitors
(in Step 8) allocation of new temporary identity to the UE 5210 by
the CN 5230, i.e. TMSI for CS services and P-TMSI for PS services,
and creates an association between the TMSI or P-TMSI and session
identity for the specific UE. The GANC will utilize this
information to perform security checks on session identity for
subsequent NAS layers messages originating on the UE specific
session.
[0641] The GANC 5220 forwards (in Step 9) the Location Update
information received from the CN 5230 to the FAP 5215 using a
GA-CSR DL DIRECT TRANSFER message. The FAP 5215 relays (In Step 10)
the Location Update Accept over the air interface to the UE
5210.
[0642] At this point, a session authorized for the specific UE-1
using its credentials IMSI-1 is established (in Step 11) between
the FAP 5215 and GANC 5220. Next, a victim UE 5205, in the vicinity
of the rogue FAP 5215, upon discovering the FAP 5215 over the air
interface, attempts to camp on the rogue FAP based on its internal
cell selection logic. This will trigger the UE 5205 to establish
(in Step 12a) a RRC connection with the Rogue FAP. The UE 5205 then
starts (in Step 12b) a Location Update procedure towards the CN
5230. The FAP 5215 intercepts the Location Update request. The FAP
will then request (in Step 12c) and receives (in Step 12d) the IMSI
of the victim UE 5205 if the Location Update is done using the
TMSI.
[0643] The rogue FAP 5215 instead of attempting a registration of
the victim UE 5205 with the GANC 5220, re-uses (in Step 13) the
existing authorized session of UE-1 5210 (as described in Step 11
above) to transfer messages to the CN 5230 via GANC 5220. It is
important to note that if the registration for the victim UE 5205
was attempted by the rogue FAP 5215 using the victim UE 5205
credentials (i.e. IMSI-2), the network based SAC would have
rejected the registration request since the victim UE-2 5205 is not
authorized Femtocell service over the specific rogue FAP 5215.
[0644] Next, the FAP 5215 encapsulates the Location Update NAS PDU
within a GA-CSR UL DIRECT TRANSFER message that is forwarded (in
Step 14) to the GANC 5220 via the existing TCP connection of UE-1
5210. The GANC 5220 performs (in Step 15) a security check on the
session identity. Since the identity carried in the Location Update
messages i.e. IMSI-2 does not match any of the known identities for
the session (IMSI-1 which is the identity used for registration and
authorization or the TMSI learnt by the GANC 5220 as described in
Step 8 above), the GANC 5220 is able to detect the attempted
service theft.
[0645] The GANC prevents the attempted service theft by
deregistering the session for UE-1 5210. The GANC 5220 sends (in
Step 16) a deregistration message to the FAP 5215 on the specific
session (the authorized session for UE-1) on which the service
theft was being attempted.
[0646] 2. Service Theft Prevention--Approach 2
[0647] FIG. 53 illustrates the Femtocell service theft prevention
in some embodiments. Steps 1-15 are the same as Step 1-15 described
in relation with FIG. 52 above. Since the identity carried in the
NAS PDU does not match any of the known identities for that
session, GANC 5320 replaces the identity in the Location Update
message with the original authorized identity for the specific
session i.e., IMSI-2 is replace with IMSI-1 in the NAS PDU. The
GANC establishes a SCCP connection to the CN 5330 and forwards (in
Step 16) the modified Location Update request NAS PDU to the CN
5330 using the RANAP Initial UE message. The CN 5330 receives a
service request with UE-1's identity in the request and will
associate the request with UE-1 5310 subscriber data including
billing, etc.
XIII. FEMTOCELL SERVICE ACCESS CONTROL
[0648] Femtocell service access control (SAC) and accounting
services are based on the S1 interface between the INC and one or
more AAA servers. The S1 interface functions are defined in detail
in the above mentioned U.S. application Ser. No. 11/349,025.
[0649] The objective of Femtocell service access control is to
provide operators with the tools to properly implement their
Femtocell service plans based on real-time information from the
subscriber and non real-time information provisioned within the
operator's IT systems and service databases. Using service
policies, the operator can implement a range of creative services
and controls to be applied on a per individual subscriber basis,
which results in the acceptance or rejection of any discrete
Femtocell session registration request. Primarily, service policies
are used to identify whether a subscriber's current request for
access meets the conditions of the service plan to which they are
subscribed.
[0650] In some embodiments, Femtocell SAC encompasses the
discovery, registration and redirection functions as well as
enhanced service access control functions, such as restricting
Femtocell service access based on the reported FAP MAC address or
neighboring macro network UMTS cell information.
[0651] A local SAC may be performed by the FAP for performance
reasons (example: FAP may use local SAC for faster rejection of UEs
which are not allowed access to either Femtocell services or not
allowed access to Femtocell services via the specific FAP).
[0652] Key elements of the service access control design approach
are as follows: [0653] 1) There are two service access control
configuration options: [0654] a) Basic service access control: The
S1 (INC-AAA) interface is not deployed and a limited set of service
access control capabilities is provided by the INC. [0655] i) The
INC is responsible for the Femtocell discovery, registration and
redirection functions. [0656] ii) The UMTS-to-Femtocell mapping
logic and data is in the INC; i.e., this is used to support the
discovery, registration and redirection functions and to assign
service areas to specific FAPS. [0657] iii) There is no subscriber
or FAP-specific service access control. [0658] b) Enhanced service
access control: The S1 interface is deployed and the AAA provides
expanded service access control features, including custom features
per service provider requirements. [0659] i) The UMA discovery,
registration and redirection functions remain on the INC. [0660]
ii) The UMTS-to-Femtocell mapping logic and data remains in the
INC. [0661] iii) The AAA supports interfaces to external database
servers; e.g., via LDAPv3. [0662] iv) The details of these enhanced
service access control functions are defined in the above mentioned
U.S. application Ser. No. 11/349,025. [0663] 2) Enablement of the
enhanced service access control support functions (i.e., the
service access control functions of the S1 interface) is an INC
configuration option; if enabled, the INC forwards attributes
received in the discovery and registration requests to the AAA
using RADIUS. This allows the AAA to (for example): [0664] a)
Determine when UE registration attempts should be allowed or
rejected (e.g., limiting service to a single FAP) [0665] b)
Retrieve FAP location information from an external database and
send the information to the INC. [0666] c) Provide a billing rate
indicator to the INC that is incorporated in the UMTS-to-Femtocell
SAI mapping process. [0667] d) Indicate that hand-in, hand-out, or
both are enabled or disabled for the subscriber.
[0668] A. UMTS-to-Femtocell Mapping
[0669] The UMTS-to-Femtocell mapping processes include the
following: [0670] 1) UMTS-INC Mapping (or "INC Selection") serves
the following functions: [0671] a) It allows an INC functioning as
a "provisioning INC" to direct a mobile station to its designated
"default INC". [0672] b) It allows an INC functioning as a "default
INC" to direct a mobile station to an appropriate "serving INC"
(e.g., in case the FAP is outside its normal default INC coverage
area). [0673] c) It allows the INC to determine if the UMTS
coverage area is Femtocell-restricted and, if so, to deny service.
[0674] 2) UMTS-Femtocell Service Area Mapping (or "Femtocell
Service Area Selection") serves the following functions: [0675] a)
It allows an INC functioning as a "default or serving INC" to
assign the Femtocell service area that shall be associated with the
FAP registration (and all the UEs camped on that specific FAP). The
service area can then be utilized for emergency call routing as
described in the "Service area based routing" Subsection under the
"EMERGENCY SERVICES" Section, above.
[0676] B. Service Access Control (SAC) Examples
[0677] The following example service access control are described
in this section: (1) new FAP connects to GAN Femtocell network, (2)
FAP connects to GAN Femtocell network (redirected connection), (3)
FAP attempts to connect in a restricted UMTS coverage area, (4)
authorized UE roves into an authorized FAP for Femtocell service,
and (5) unauthorized UE roves into an authorized FAP for Femtocell
service.
[0678] 1. New FAP Connects to GAN Femtocell Network
[0679] FIG. 54 illustrates SAC for new FAP connecting to Femtocell
network in some embodiments. As shown, if the FAP 5405 has a
provisioned or derived FQDN of the Provisioning SeGW, it performs
(in Step 1) a DNS query (via the generic IP access network
interface) to resolve the FQDN to an IP address. If the FAP has a
provisioned IP address for the Provisioning SeGW, the DNS step is
omitted.
[0680] The DNS Server 5410 returns (in Step 2) a response including
the IP Address of the Provisioning SeGW 5415. The FAP 5405
establishes (in Step 15) a secure tunnel to the Provisioning SeGW
5415 using IKEv2 and EAP-AKA or EAP-SIM.
[0681] If the FAP has a provisioned or derived FQDN of the
Provisioning INC, it performs (in Step 4) a DNS query (via the
secure tunnel) to resolve the FQDN to an IP address. If the FAP has
a provisioned IP address for the Provisioning INC, the DNS step
(step 4) will be omitted. The DNS Server 5420 returns (in Step 5) a
response including the IP Address of the Provisioning INC.
[0682] Next, the FAP 5405 sets up (in Step 6) a TCP connection to a
well-defined port on the Provisioning INC 5425. The FAP 5405 then
queries (in Step 7) the Provisioning INC for the Default INC, using
GA-RC DISCOVERY REQUEST. The message includes Cell Info and FAP
Identity. For Cell Info, if the FAP detects macro network coverage,
then it provides the detected UTRAN cell ID and the UTRAN LAI. If
the FAP does not detect macro network coverage it provides the last
LAI where the FAP successfully registered, along with an indicator
stating which one it is. For FAP Identity, the message includes
IMSI.
[0683] The INC 5425 sends (in Step 8) a RADIUS Access-Request
message to the AAA server 5435, including attributes derived from
GA-CSR DISCOVERY REQUEST message. The AAA server 5435 queries (in
Step 9) the Femtocell subscriber database 5440 for a record
matching the IMSI of the FAP. The subscriber record is returned (in
Step 9) to the AAA server. The AAA server verifies that FAP IMSI is
authorized and FAP is allowed (based on AP-ID i.e., MAC address of
the FAP).
[0684] AAA server returns (in Step 10) selected Femtocell location
information based on AP-ID and IMSI to the INC 5425 using the
Access Accept message. The INC 5425 determines (in Step 11) the
default security gateway and INC (e.g., INC #2 5430) using the
UMTS-Femtocell mapping function (see UMTS-to-Femtocell Mapping
Section, above). This is done so the FAP 5405 is directed to a
"local" Default INC in the HPLMN to optimize network
performance.
[0685] The Provisioning INC 5425 returns (in Step 12) the default
INC information in the GA-RC DISCOVERY ACCEPT message. The
DISCOVERY ACCEPT message also indicates whether the INC and SeGW
address provided shall or shall not be stored by the FAP. The FAP
releases (in Step 13) the TCP connection and IPSec tunnel and
proceeds to register on INC #2.
[0686] The FAP performs (in Step 14) a private DNS query using the
assigned Default INC FQDN. The private DNS server 5420 returns (in
Step 15) the IP address of INC #2 5430. The FAP establishes (in
Step 16) a TCP connection to INC #2 5430. The FAP sends (in Step
17) a GA-RC REGISTER REQUEST message to the INC.
[0687] The INC sends (in Step 18) a RADIUS Access-Request message
to the AAA server, including attributes derived from GA-RC REGISTER
REQUEST message. The AAA server queries (in Step 19) the Femtocell
subscriber database for a record matching the FAP IMSI. The
subscriber record is returned (in Step 19) to the AAA server. The
AAA server verifies that IMSI is authorized and FAP is allowed
(based on AP-ID).
[0688] Next, the AAA server returns (in Step 20) selected Femtocell
service attributes to the INC. The INC determines (in Step 21) that
it is the correct serving INC for the mobile current location using
the UMTS-Femtocell mapping function. It also determines (in Step
21) the Femtocell service area to associate with the FAP using the
UMTS-Femtocell mapping functions. The INC returns (in Step 22) a
GA-RC REGISTER ACCEPT message to the MS
[0689] 2. FAP Connects to GAN Femtocell Network (Redirected
Connection)
[0690] FIG. 55 illustrates SAC for the FAP getting redirected in
Femtocell network in some embodiments. Steps 1 to 10 are the same
steps as described in the "New FAP connects to GAN Femtocell
network" Subsection, above. Next, the INC 5525 uses the
UMTS-Femtocell mapping function to determine (in Step 11) that the
FAP 5505 should be served by another INC.
[0691] The INC 5525 sends (in Step 12) the new serving SeGW and INC
FQDNs to the FAP 5505 in the GA-RC REGISTER REDIRECT message. The
FAP releases (In Step 13) the TCP connection and IPSec tunnel and
proceeds to register with the designated INC.
[0692] 3. FAP Attempts to Connect in a Restricted UMTS Coverage
Area
[0693] FIG. 56 illustrates the SAC for FAP registering in
restricted UMTS coverage area in some embodiments. As shown, Steps
1 to 10 are the same steps as described in the "New FAP connects to
GAN Femtocell network" Subsection, above. Next, the INC 5625 uses
the UMTS-Femtocell mapping function to determine (in Step 11) that
the FAP 5605 is in an UMTS area that is Femtocell restricted (i.e.,
Femtocell access is not allowed in the area).
[0694] The INC sends (in Step 12) a GA-RC REGISTER REJECT message
to the FAP, including reject cause "Location not allowed". The FAP
releases (in Step 13) the TCP connection and IPSec tunnel and does
not attempt to register again from the same UMTS coverage area
until powered-off.
[0695] 4. Authorized UE Roves into an Authorized FAP for Femtocell
Service
[0696] The sequence of events is same as described in UE
Registration Section, above.
[0697] 5. Unauthorized UE Roves into an Authorized FAP for
Femtocell Service
[0698] An unauthorized UE (unauthorized for Femtocell service over
the specific FAP), upon camping on the FAP (via its internal cell
selection mechanism), will initiate a NAS layer Location Update
procedure towards the CN via the FAP (The LU is triggered since the
FAP broadcasts a distinct LAI than its neighboring macro cells and
other neighboring Femtocells). The FAP will intercept the Location
Update message and attempt to register the UE with the INC as
described below. FIG. 57 illustrates the SAC for Unauthorized UE
accessing authorized FAP in some embodiments.
[0699] As shown, the UE 5705 establishes (in Step 1a) a RRC
connection with the FAP on which it camps. The UE starts (in Step
1b) a Location Update procedure towards the CN. The FAP 5710 will
intercept the Location Update request and attempts to register the
UE with the associated Serving INC over the existing IPSec tunnel.
Optionally, the FAP may request (in Step 1c) the IMSI of the UE if
the Location Update is done using the TMSI, since the initial
registration for the UE must be done using the permanent identity
i.e. the IMSI of the UE.
[0700] The FAP sets up a separate TCP connection (for each UE) to a
destination TCP port on the INC 5715. The INC destination TCP port
is the same as that used for FAP registration. The FAP attempts to
register the UE on the INC by transmitting (in Step 2) the GA-RC
REGISTER REQUEST. The message includes (1) Registration Type which
indicates that the registering device is a UE, (2) the UE Identity
which is UE-IMSI, and (3) the FAP identity which is FAP-IMSI.
[0701] Optionally, if the INC has been configured for Service
Access Control (SAC) over S1 interface, the INC will (in Step 3),
via AAA server 5420, authorize the UE 5405 using the information
provided in the REGISTER REQUEST. The authorization logic on the
AAA server also checks (in Step 4) to see if the UE is allowed
Femtocell access using the specific FAP. The AAA SAC logic
indicates that the registering UE is not authorized to access
Femtocell service over the specific FAP.
[0702] Next, the AAA 5720 sends (in Step 5) Access Reject (with
reject cause equivalent to "UE not allowed on FAP") to the INC
5715. The INC maps (in Step 6) the Access Reject to a GA-RC
REGISTER REJECT message to the FAP indicating the reject cause.
[0703] The FAP 5710 in turn sends (in Step 7) a Location Updating
Reject to the UE 5705 with cause of "Location Area Not Allowed".
This will prevent the UE from attempting to camp on the specific
FAP again. While some embodiments use "Location Area Not Allowed"
as a mechanism for rejecting unauthorized UEs, other embodiments
may use other appropriate UE rejection mechanisms.
XIV. COMPUTER SYSTEM
[0704] FIG. 58 conceptually illustrates a computer system with
which some embodiments of the invention are implemented. The
computer system 5800 includes a bus 5805, a processor 5810, a
system memory 5815, a read-only memory 5820, a permanent storage
device 5825, input devices 5830, and output devices 5835.
[0705] The bus 5805 collectively represents all system, peripheral,
and chipset buses that support communication among internal devices
of the computer system 5800. For instance, the bus 5805
communicatively connects the processor 5810 with the read-only
memory 5820, the system memory 5815, and the permanent storage
device 5825.
[0706] From these various memory units, the processor 5810
retrieves instructions to execute and data to process in order to
execute the processes of the invention. In some embodiments the
processor comprises a Field Programmable Gate Array (FPGA), an
ASIC, or various other electronic components for executing
instructions. The read-only-memory (ROM) 5820 stores static data
and instructions that are needed by the processor 5810 and other
modules of the computer system. The permanent storage device 5825,
on the other hand, is a read-and-write memory device. This device
is a non-volatile memory unit that stores instruction and data even
when the computer system 5800 is off. Some embodiments of the
invention use a mass-storage device (such as a magnetic or optical
disk and its corresponding disk drive) as the permanent storage
device 5825. Some embodiments use one or more removable storage
devices (flash memory card or memory stick) as the permanent
storage device.
[0707] Like the permanent storage device 5825, the system memory
5815 is a read-and-write memory device. However, unlike storage
device 5825, the system memory is a volatile read-and-write memory,
such as a random access memory. The system memory stores some of
the instructions and data that the processor needs at runtime.
[0708] Instructions and/or data needed to perform processes of some
embodiments are stored in the system memory 5815, the permanent
storage device 5825, the read-only memory 5820, or any combination
of the three. For example, the various memory units include
instructions for processing multimedia items in accordance with
some embodiments. From these various memory units, the processor
5810 retrieves instructions to execute and data to process in order
to execute the processes of some embodiments.
[0709] The bus 5805 also connects to the input and output devices
5830 and 5835. The input devices enable the user to communicate
information and select commands to the computer system. The input
devices 5830 include alphanumeric keyboards and cursor-controllers.
The output devices 5835 display images generated by the computer
system. The output devices include printers and display devices,
such as cathode ray tubes (CRT) or liquid crystal displays (LCD).
Finally, as shown in FIG. 58, bus 5805 also couples computer 5800
to a network 5865 through a network adapter (not shown). In this
manner, the computer can be a part of a network of computers (such
as a local area network ("LAN"), a wide area network ("WAN"), or an
Intranet) or a network of networks (such as the Internet).
[0710] It should be recognized by one of ordinary skill in the art
that any or all of the components of computer system 5800 may be
used in conjunction with the invention. For instance, some or all
components of the computer system described with regards to FIG. 58
comprise some embodiments of the UE, FAP, GANC, and GGSN described
above. Moreover, one of ordinary skill in the art will appreciate
that any other system configuration may also be used in conjunction
with the invention or components of the invention.
XV. DEFINITIONS AND ABBREVIATIONS
[0711] The following is a list of definitions and abbreviations
used: [0712] AAA Authentication, Authorization, and Accounting
[0713] ACL Access Control List [0714] AES Advanced Encryption
Standard [0715] AH Authentication Header (IPSec) [0716] AKA
Authentication and Key Agreement [0717] ALI Automatic Location
Identification [0718] AMS access Point Management System [0719] ANI
Automatic Number Identification [0720] AP Access Point [0721] APN
Access Point Name [0722] ATM Asynchronous Transfer Mode [0723] AuC
Authentication Center [0724] CBC Cell Broadcast Center [0725] CBC
Cipher Block Chaining [0726] CC Call Control [0727] CDR Call Detail
Records [0728] CMDA Code Division Multiple Access [0729] CGI Cell
Global Identification [0730] CgPN Calling Party Number [0731] CLIP
Calling Line Presentation [0732] CK Cipher Key [0733] CM Connection
Management [0734] CM-sub Connection Management sublayer [0735] CN
Core Network [0736] CPE Customer Premises Equipment [0737] CRC
Cyclic Redundancy Code [0738] CRDB Coordinate Routing Database
[0739] CS Circuit Switched [0740] CTM Cellular Text telephone
Modem, as specified in 3GPP 26.226 [0741] DL Downlink [0742] DNS
Domain Name System [0743] EAP Extensible Authentication protocol
[0744] EAPOL EAP over LANs [0745] ECB Electronic Code Book (AES
Mode) [0746] ELID Emergency Location Information Delivery [0747]
E-OTD Enhanced Observed Time Difference [0748] ESN Emergency
Services Number [0749] ESP Emergency Services Protocol or
Encapsulating Security Payload (IPSec) [0750] ESRD Emergency
Services Routing Digits [0751] ESRK Emergency Services Routing Key
[0752] ETSI European Telecommunications Standards Institute [0753]
FCAPS Fault, Configuration, Accounting, Performance, and Security
management [0754] FAP Femtocell Access Point [0755] FCC US Federal
Communications Commission [0756] FQDN Fully Qualified Domain Name
[0757] GA-CSR Generic Access-Circuit Switched Resources [0758] GAN
Generic Access Network [0759] GANC GAN Network Controller [0760]
GA-PSR Generic Access-Packet Switched Resources [0761] GA-RC
Generic Access-Resource Control [0762] GDP Generic Digits Parameter
[0763] GERAN GSM EDGE Radio Access Network [0764] GGSN Gateway GPRS
Support Node [0765] GMLC Gateway Mobile Location Center [0766]
GMM/SM GPRS Mobility Management and Session Management [0767] GMSC
Gateway MSC [0768] GPRS General Packet Radio Service [0769] GPS
Global Positioning System [0770] GMM-sub GPRS Mobility Management
sublayer [0771] GRR-sub GPRS Radio Resource sublayer in GSM [0772]
GSM Global System for Mobile communications [0773] GSN GPRS Support
Node [0774] GTP GPRS Tunnelling Protocol [0775] GTT GSM Global Text
Telephony or SS7 Global Title Translation [0776] HLR Home Location
Register [0777] HMAC Hashed Message Authentication Code [0778]
HPLMN Home PLMN [0779] IAM Initial Address Message [0780] ICMP
Internet Control Message Protocol [0781] IETF Internet Engineering
Task Force [0782] IK Integrity Key [0783] IKEv2 Internet Key
Exchange Version 2 [0784] IMEI International Mobile station
Equipment Identity [0785] IMSI International Mobile Subscriber
Identity [0786] INC IP Network Controller [0787] IP Internet
Protocol [0788] IPSec IP Security [0789] IPv4 Internet Protocol
version 4 [0790] IPv6 Internet Protocol version 6 [0791] ISDN
Integrated Services Digital Network [0792] ISP Internet Service
Provider [0793] ISUP ISDN User Part [0794] Iu Interface UTRAN
[0795] IV Initialization Vector [0796] LA Location Area [0797] LAC
Location Area Code [0798] LAI Location Area Identity [0799] LAU
Location Area Update [0800] LU Location Update [0801] LCS Location
Service [0802] LEAP Lightweight EAP (same as EAP-Cisco) [0803] LLC
Logical Link Control [0804] LLC-sub Logical Link Control sublayer
[0805] LMSI Local Mobile Subscriber Identity [0806] LSB Least
Significant Bit [0807] LSP Location Services Protocol [0808] M
Mandatory [0809] M3UA MTP3 User Adaptation Layer [0810] MAC Media
Access Control or Message Authentication Code (same as MIC) [0811]
MAC Address Media Access Control Address [0812] MAC-I Message
Authentication Code for Integrity [0813] MAP Mobile Application
Part [0814] MDN Mobile Directory Number [0815] ME Mobile Equipment
[0816] MIC Message Integrity Check (same as Message Authentication
Code) [0817] MG or MGW Media Gateway [0818] MM Mobility Management
[0819] MM-sub Mobility Management sublayer [0820] MPC Mobile
Positioning Center [0821] MS Mobile Station [0822] MSB Most
Significant Bit [0823] MSC Mobile Switching Center [0824] MSISDN
Mobile Station International ISDN Number [0825] MSRN Mobile Station
Roaming Number [0826] MTP1/2/3 Message Transfer Part Layer 1/2/3
[0827] NAS Non Access Stratum [0828] NCAS Non Call Associated
Signaling [0829] NDC National Destination Code [0830] NS Network
Service [0831] NSAPI Network layer Service Indoor Base Station
Identifier [0832] NSS Network SubSystem [0833] O Optional [0834]
OCB Offset Code Book (AES Mode) [0835] OTP One Time Programmable
[0836] pANI pseudo-ANI: Either the ESRD or ESRK [0837] PCS Personal
Communications Services [0838] PCU Packet Control Unit [0839] PDCH
Packet Data CHannel [0840] PDE Position Determining Entity [0841]
PDN Packet Data Network [0842] PDP Packet Data Protocol, e.g., IP
or X.25 [0843] PDU Protocol Data Unit [0844] PEAP Protected EAP
[0845] PKI Public Key Infrastructure [0846] PLMN Public Land Mobile
Network [0847] POI Point of Interface [0848] PPF Paging Proceed
Flag [0849] PPP Point-to-Point Protocol [0850] PSAP Public Safety
Answering Point [0851] PSTN Public Switched Telephone Network
[0852] PTM Point To Multipoint [0853] P-TMSI Packet TMSI [0854] PTP
Point To Point [0855] PVC Permanent Virtual Circuit [0856] QoS
Quality of Service [0857] R Required [0858] RA Routing Area [0859]
RAB RANAP Assignment Request [0860] RAC Routing Area Code [0861]
RADIUS Remote Authentication Dial-In User Service [0862] RAI
Routing Area Identity [0863] RAN Radio Access Network [0864] RANAP
Radio Access Network Application Part [0865] RFC Request for
Comment (IETF Standard) [0866] RLC Radio Link Control [0867] RNC
Radio Network Controller [0868] RR-sub Radio Resource Management
sublayer [0869] RSN Robust Security Network [0870] RTCP Real Time
Control Protocol [0871] RTP Real Time Protocol [0872] SAC Service
Access Control [0873] SAC Service Area Code SC Scrambling Code
[0874] SCCP Signaling Connection Control Part [0875] SDCCH
Standalone Dedicated Control Channel [0876] SDU Service Data Unit
[0877] SeGW GANC Security Gateway [0878] SGSN Serving GPRS Support
Node [0879] SK Service Key [0880] SIM Subscriber Identity Module
[0881] SM Session Management [0882] SMLC Serving Mobile Location
Center [0883] SMS Short Message Service [0884] SM-AL Short Message
Application Layer [0885] SM-TL Short Message Transfer Layer [0886]
SM-RL Short Message Relay Layer [0887] SM-RP Short Message Relay
Protocol [0888] SMR Short Message Relay (entity) [0889] SM-CP Short
Message Control Protocol [0890] SMC Short Message Control (entity)
[0891] SM-SC Short Message Service Centre [0892] SMS-GMSC Short
Message Service Gateway MSC [0893] SMS-IWMSC Short Message Service
Interworking MSC [0894] SNDCP SubNetwork Dependent Convergence
Protocol [0895] SN-PDU SNDCP PDU [0896] S/R Selective Router [0897]
SS Supplementary Service [0898] SSID Service Set Identifier (also
known as "Network Name") [0899] SSL Secure Socket Layer [0900] STA
Station (802.11 client) [0901] TA Timing Advance [0902] TCAP
Transaction Capabilities Application Part [0903] TCP Transmission
Control Protocol [0904] TDOA Time Difference of Arrival [0905] TEID
Terminal Endpoint Identifier [0906] TID Tunnel Identifier [0907]
TKIP Temporal Key Integrity Protocol [0908] TLLI Temporary Logical
Link Identity [0909] TLS Transport Layer Security [0910] TMSI
Temporary Mobile Subscriber Identity [0911] TOA Time of Arrival
[0912] TRAU Transcoder and Rate Adaptation Unit [0913] TTY Text
telephone or teletypewriter [0914] UARFCN UMTS Absolute Radio
Frequency Channel Number [0915] UDP User Datagram Protocol [0916]
UE User Equipment [0917] UL Uplink [0918] UMA Unlicensed Mobile
Access [0919] UMTS Universal Mobile Telecommunication System [0920]
USIM UMTS Subscriber Identity Module/Universal Subscriber Identity
Module [0921] USSD Unstructured Supplementary Service Data [0922]
UTC Coordinated Universal Time [0923] UTRAN UMTS Terrestrial Radio
Access Network [0924] VLR Visited Location Register [0925] VMSC
Visited MSC [0926] VPLMN Visited Public Land Mobile Network [0927]
VPN Virtual Private Network [0928] W-CDMA Wideband Code Division
Multiple Access [0929] WEP Wired Equivalent Privacy [0930] WGS-84
World Geodetic System 1984 [0931] WPA Wi-Fi Protected Access [0932]
WZ1 World Zone 1
[0933] The foregoing description, for purposes of explanation, used
specific nomenclature to provide a thorough understanding of the
invention. However, it will be apparent to one skilled in the art
that specific details are not required in order to practice the
invention. Thus, the foregoing descriptions of specific embodiments
of the invention are presented for purposes of illustration and
description. They are not intended to be exhaustive or to limit the
invention to the precise forms disclosed; obviously, many
modifications and variations are possible in view of the above
teachings. The embodiments were chosen and described in order to
best explain the principles of the invention and its practical
applications, they thereby enable others skilled in the art to best
utilize the invention and various embodiments with various
modifications as are suited to the particular use contemplated.
Moreover, while the invention has been described with reference to
numerous specific details, one of ordinary skill in the art will
recognize that the invention can be embodied in other specific
forms without departing from the spirit of the invention.
[0934] In some examples and diagrams, two components may be
described or shown as connected to each other. The connection may
be a direct wire connection or the two components may be
communicatively coupled to each other through other components or
through wireless or broadband links. Thus, one of ordinary skill in
the art would understand that the invention is not to be limited by
the foregoing illustrative details, but rather is to be defined by
the appended claims.
* * * * *