WO2011127224A1

WO2011127224A1 - System and method for supporting access control in hnb and hnb-gw for legacy and csg user equipments

Info

Publication number: WO2011127224A1
Application number: PCT/US2011/031485
Authority: WO
Inventors: Amit Khetawat; Patrick Tao; Srinivas R. Kadaba
Original assignee: Kineto Wireless, Inc.
Priority date: 2010-04-06
Filing date: 2011-04-06
Publication date: 2011-10-13

Abstract

Some embodiments provide novel techniques for supporting CSG features without mobile operators having to upgrade their core network (CN). To support the CSG features, a home node B (HNB) gateway (HNB-GW) and/or the HNB performs functions (e.g. access control) that would normally be performed by a mobile operator's CN if the CN has been upgraded to support the CSG features. Accordingly, by performing access control the HNB-GW and/or the HNB, the mobile operator does not have to upgrade the CN to support CSG operations.

Description

SYSTEM AND METHOD FOR SUPPORTING ACCESS CONTROL IN HNB AND HNB-GW FOR LEGACY AND CSG USER EQUIPMENTS

BACKGROUND

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, also referred to as user equipment (UE), include cellular telephones, PCS telephones, wireless-enabled personal digital assistants, wireless modems, and the like.

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). In a Universal Mobile Telecommunications System (UMTS), these base stations are system provider controlled and include Node-Bs which use high power and long range radio frequency transmitters and receivers to directly connect with the user equipment. The wireless transport mechanisms and frequencies employed by typical licensed wireless systems limit both data transfer rates and range.

Licensed wireless systems continually upgrade their networks and equipment in an effort to deliver greater data transfer rates and range. However, with each upgrade iteration (e.g., 3G to 4G), the licensed wireless system providers incur substantial costs from licensing additional bandwidth spectrum to upgrading the existing radio network equipment or core network equipment. To offset these costs, the licensed wireless system providers pass down the costs to the user through the licensed wireless service fees. Users also incur equipment costs with each iterative upgrade of the licensed wireless network as new user equipment is needed to take advantage of the new services or improved services of the upgraded network.

Landline (wired) connections are extensively deployed and generally perform at a lower cost with higher quality voice and higher speed data services than the licensed wireless systems. The problem with landline connections is that they constrain the mobility of a user. Traditionally, a physical connection to the landline was required. Home Node B (HNB) systems emerged as one solution to lower costs associated with the licensed wireless systems while maintaining user wireless mobility. A HNB system allows users the ability to seamlessly and wirelessly roam in and out of Node B service regions and HNB service regions where the HNB systems facilitate indoor and low cost access to the mobile operator's network and services. The mobility range associated with such HNB systems is typically on the order of 100 meters or less. A typical HNB communication system includes a wireless access point (AP) (referred to as Home Node B (HNB)) with a physical connection (e.g., coaxial, twisted pair, or optical cable) to a landline -based network. The AP has an RF transceiver to facilitate communication over licensed frequencies with a wireless handset that is operative within a modest distance of the AP.

HNB communication systems allow users to use APs in order to deploy a HNB service region that allows for access to mobile services. In this manner, HNB is able to provide higher quality services at a lower cost than the licensed wireless macro cell. Accordingly, HNBs are low cost versions of the expensive Base Stations that comprise the mobile network but still use the operator's licensed spectrum for communication with licensed devices. The use of consumer and/or enterprise fixed broadband connections to connect HNBs to the mobile operator's network required the HNBs to adopt specialized new messaging and signaling standards that were different than those used by the licensed wireless systems for the expensive macro Base Stations.

However, in legacy HNB standards, there were no special techniques to cause a UE that is camped on a licensed wireless macro cell to preferentially switch over to a HNB cell. That is, when the UE is in a service region of a HNB, the UE may stay on the macro cell without ever switching over to the HNB. To facilitate the switch, different vendors were attempting different techniques. Several of these techniques incurred penalties such as draining UE's battery life.

To solve this problem, 3rd Generation Partnership Project (3GPP) proposed the idea of a

Closed Subscriber Group (CSG) cell. A CSG cell is similar to a wireless local area network (WLAN). In the WLAN, a service set identifier (SSID) that identifies a particular 802.11 WLAN is broadcast by an access point or router. When a device is within the range of the broadcast message, the device may detect the SSID and switch over to the particular WLAN.

Similar to the WLAN, a CSG HNB broadcasts identifying information. However, instead of SSID, the HNB broadcasts a CSG identity (CSG ID). A CSG UE maintains a whitelist that includes one or more CSG IDs associated with CSG cells on which the UE is allowed to access. The UE may use this whitelist to select and preferentially switch over to a CSG cell based a corresponding CSG ID that is broadcast. For example, in timed intervals, the UE may (1) determine whether it can detect one of the CSG IDs in the UE's whitelist and (2) switch over to the CSG cell when the UE detects one.

Another feature of the CSG environment is maintaining user identity confidentiality. To maintain confidentiality, a UE generally does not send its own identity or International Mobile Subscriber Identity (IMSI) in the clear. In other words, a UE that moves around in the cellular network may send its IMSI once when the UE first attaches to the network. However, once the UE sends its IMSI, the user identity is protected or masked by a temporary identity or Temporary Mobile Subscriber Identity (e.g., TMSI, PTMSI). Although the legacy HNB standards broke this model, 3GPP proposed to maintain user identity confidentiality in the CSG environment.

Related to these features, 3GPP's plan proposed that the core network perform access control operations. In particular, the plan called for the Home Location Register (HLR) to maintain a list of CSG IDs that a UE is allowed to use. For example, when a UE switches over to a CSG cell, the plan was for the core network to verify whether the UE is allowed to communicate over the CSG cell by accessing the list of CSG IDs in the HLR. Therefore, in implementing these CSG features, mobile operators had to upgrade their core network (e.g., HLR, Mobile Switching Center or MSC, Serving GPRS Support Node or SGSN).

BRIEF SUMMARY

Some features of the 3GPP CSG solution are more useful to mobile operators than others. Changing the UE behavior to maintain a list of allowed CSG cells and preferentially switch over to camp on CSG cells in the allowed CSG cell list are valuable improvements while upgrading the mobile operator's core network to provide UE access control has limited benefits but incurs high costs. Some embodiments provide novel techniques for supporting preferential CSG cell selection without mobile operators having to upgrade their core network (CN). To support the desirable CSG features, a home node B (HNB) gateway (HNB-GW) and/or the HNB performs access control that would normally be performed by a mobile operator's CN if the CN has been upgraded to support the CSG features. Accordingly, by performing access control at the HNB- GW and/or the HNB, the mobile operator does not have to upgrade the CN to support CSG operations. For example, the mobile operator does not have to upgrade the CN's Home Location Register (HLR), the Visited Location Register (VLR), or the Serving GPRS Support Node (SGSN) to manage the list of CSG IDs that a UE is allowed to use and enforce the CSG access control in the VLRs and SGSNs.

In performing access control, the HNB-GW in some embodiments receives a registration request message from the HNB. In some embodiments, the registration request message includes an international mobile subscriber identity (IMSI) of a CSG UE and a CSG identity that identifies a CSG cell of the HNB. In some embodiments, the HNB is configured to broadcast a Location Area Identifier (LAI) that is different from the LAI of the cells nearby. When the CSG UE (1) detects the CSG identify being broadcast by the HNB and (2) determines that the CSG identity is stored in the CSG UE's whitelist, the CSG UE immediately camps on the CSG cell. Since the CSG cell LAI is different from the LAI of the cell where the UE was previously camped, the CSG UE sends a LAU message to the HNB (the LAU message triggers the HNB to send a Radio Access Network Application Part (RANAP) initial UE message because the LAU message is the initial message of a Non Access Stratum (NAS) procedure). The HNB receives the LAU message from the CSG UE, realizes that the UE is not known to the HNB, and sends an Identity Request to the CSG UE to retrieve the UE's IMSI. The HNB then sends a UE Registration Request to the HNB-GW using the retrieved UE identity.

The HNB-GW then performs access control for the CSG UE by determining whether the

CSG UE is authorized to access the HNB based on the CSG UE's IMSI, the CSG identity, and using a data store (e.g., database) that matches CSG UEs with CSGs that the CSG UEs are authorized to access. When the determination is made that the CSG UE is authorized to access the HNB, the HNB-GW, in some embodiments, sends a registration accept message to the HNB.

In some embodiments, the HNB-GW modifies Radio Access Network Application Part (RANAP) messages sent to the CN by filtering out each information element (IE) related to CSG operation. For example, the HNB-GW in some embodiments filters out a CSG identity IE and a cell access mode IE when sending the initial UE message to the CN. In this manner, the CN is unaware of CSG capabilities of the CSG UE and the HNB. Accordingly, the RANAP messages appear to the CN to be standard, legacy RANAP message prior to the introduction of CSG standard by 3GPP.

Alternatively, in some embodiments, the HNB sends RANAP messages to the CN via the HNB-GW by excluding one or more IEs related to CSG such that the CN servicing the CSG UE is unaware of CSG capabilities of the CSG UE and the HNB.

In conjunction with the HNB-GW or instead of it, some embodiments perform access control at the HNB. In some embodiments, the location update message includes either the IMSI of the CSG UE or temporary mobile subscriber identity of the CSG UE. In these embodiments, the HNB performs an identify request procedure to identity the CSG UE's IMSI when the location update message includes the temporary mobile subscriber identity (e.g., TMSI, PTMSI). In some such embodiments, the HNB sends an identity request the CSG UE and receives an identity response that contains the CSG UE's IMSI. The HNB then performs the access control for the CSG UE by determining whether the CSG UE is authorized to access the HNB based on the CSG UE's IMSI and a list of one or more IMSIs that identifies each UE that is authorized to access the HNB. When the determination is made that the CSG UE is authorized to access the HNB, the HNB sends a registration request message to the HNB-GW. In response to the registration request, the HNB receives a registration accept message from the HNB-GW.

As mentioned above, a feature of the CSG environment is maintaining user identity confidentiality. To maintain this confidentiality, the HNB-GW, in some embodiments, receives a request to register the CSG UE. The request to register includes a temporary mobile subscriber identity of the UE. To resolve the temporary mobile subscriber identity, the HNB-GW sends a Mobile Application Part (MAP) SEND IDENTIFICATION message to a source visitor location register (VLR) to retrieve the UE's IMSI. The VLR is an existing function supported by the CN (e.g., a function within the MSC) prior to introduction of CSG standard. The HNB-GW then performs access control for the CSG UE based on the CSG UE's IMSI. In this manner, the HNB- GW is able to maintain the user identity confidentiality by utilizing an existing function of the CN.

The preceding Summary is intended to serve as a brief introduction to some embodiments of the invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this document. The Detailed Description that follows and the Drawings that are referred to in the Detailed Description will further describe the embodiments described in the Summary as well as other embodiments. Accordingly, to understand all the embodiments described by this document, a full review of the Summary, Detailed Description and the Drawings is needed. Moreover, the claimed subject matters are not to be limited by the illustrative details in the Summary, Detailed Description and the Drawing, but rather are to be defined by the appended claims, because the claimed subject matters can be embodied in other specific forms without departing from the spirit of the subject matters.

BRIEF DESCRIPTION OF THE DRAWINGS

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.

Figure 1 illustrates system architecture for 3G HNB deployments in accordance with some embodiments of the invention.

Figure 2 illustrates elements of the HNB Access Network (HNB-AN) sub-system architecture in accordance with some embodiments.

Figure 3 illustrates the Home Node-B (HNB) system architecture including the HNB-AN of some embodiments integrated with a core network of a second communication system that includes a licensed wireless radio access network.

Figure 4 illustrates the protocol architecture supporting the HNB Application Part (HNBAP) over the Iuh interface, in some embodiments.

Figure 5 illustrates the protocol architecture in support of the HNB control plane (i.e., for both the CS and PS domain), in some embodiments.

Figure 6 illustrates a procedure for registration of a Non-CSG UE.

Figure 7 illustrates a procedure that requires modifications to core network for registration of a CSG UE using temporary identity.

Figure 8 illustrates the HNB registering a legacy or CSG UE with the H B-GW, in some embodiments.

Figure 9 illustrates the HNB registering a CSG UE with the HNB-GW, in some embodiments.

Figure 10 conceptually illustrates a computer system with which some embodiments of the invention are implemented.

DETAILED DESCRIPTION

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.

The HNB-GW then performs access control for the CSG UE by determining whether the CSG UE is authorized to access the HNB based on the CSG UE's IMSI, the CSG identity, and using a data store (e.g., database) that matches CSG UEs with CSGs that the CSG UEs are authorized to access. When the determination is made that the CSG UE is authorized to access the HNB, the HNB-GW, in some embodiments, sends a registration accept message to the HNB.

In some embodiments, the HNB-GW modifies Radio Access Network Application Part (RANAP) messages sent to the CN by filtering out each information element (IE) related to CSG operation. For example, the HNB-GW in some embodiments filters out a CSG identity IE and a cell access mode IE when sending the initial UE message to the CN. In this manner, the CN is unaware of CSG capabilities of the CSG UE and the HNB. Accordingly, the RANAP messages appear to the CN to be standard, legacy RANAP message prior to the introduction of CSG standard by 3 GPP.

Alternatively, in some embodiments, the HNB sends RANAP messages to the CN via the

HNB-GW by excluding one or more IEs related to CSG such that the CN servicing the CSG UE is unaware of CSG capabilities of the CSG UE and the HNB.

Several more detailed embodiments of the invention are described in the sections below. Section I provides a description of a HNB architecture according to some embodiments. The description in Section I is followed by a description of protocol architectures in Section II. Section III describes several registrations procedures for Non-CSG systems and CSG systems that require core network modifications. Section IV describes several registration procedures for CSG systems that support access control at the HNB and/or the HNB GW without requiring modifications to the core network. Section V describes a computer system with which some embodiments of the invention are implemented.

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 VI below.

I. HNB SYSTEM ARCHITECTURE

Figure 1 illustrates system architecture for HNB (or Femtocell) deployments in accordance with some embodiments of the invention. As shown, the system includes a HNB access network (HNB-AN or HNB system) 110. The key features of the 3G HNB system architecture include (a) support for a standard User Equipment (UE) 105 as defined in the 3GPP technical specification TS 23.101 entitled "General UMTS architecture" which is incorporated herein by reference and (b) co-existence with the UMTS Terrestrial Radio Access Network (UTRAN) and interconnection with the existing Core Network (CN) 115 via the standardized interfaces defined for UTRAN.

In some embodiments of the invention, the standardized interfaces include (a) the Iu-cs interface for circuit switched services as overviewed in the 3 GPP technical specification (TS) 25.410 entitled "UTRAN Iu Interface: general aspects and principles" which is incorporated herein by reference, (b) the Iu-ps interface for packet switched services as overviewed in the 3GPP TS 25.410, (c) the Iu-pc interface for supporting location services as described in the 3GPP TS 25.450 entitled "UTRAN Iupc interface general aspects and principles" which is incorporated herein by reference, and (d) the Iu-bc interface for supporting cell broadcast services as described in the 3GPP TS 25.419 entitled "UTRAN Iu-BC interface: Service Area Broadcast Protocol (SABP)" which is incorporated herein by reference. However, it should be apparent to one of ordinary skill in the art that other interfaces may be implemented by the HNB- AN. For instance, the A Gb interfaces of standard Global System for Mobile (GSM) communications systems can be implemented by a HNB-AN to support 2G or GSM/GPRS air interface.

To address specific 3G HNB applications, some embodiments utilize existing Iu and Uu interfaces within the HNB-AN 1 10. The HNB-AN 110 addresses some of the key issues in the deployment of 3G HNB applications, such as the ad-hoc and large scale deployment of 3G HNBs using public infrastructure such as the Internet.

Figure 2 illustrates elements of the HNB Access Network (HNB-AN) 200 architecture in accordance with some embodiments. This figure includes HNB 205, Generic Internet Protocol (IP) Access Network 210 (e.g., Broadband IP Network), HNB-GW 215, HNB Management System 220, Iuh interface 225 that is established between the Generic IP Access Network 210 and the HNB-GW 215, and an interface 230 between the HNB-GW 215 and the HNB Management System 220. In some embodiments, the interface 230 is based on the TR-069 family of standards.

As shown in Figure 2, the Security Gateway (SeGW) 235 is a standalone entity. That is, the SEGW 235 is an entity that is outside the HNB-GW 230 and not a logical entity within the HNB-GW. The SeGW 235 provides the security functions including termination of secure access tunnels from the HNB 205, mutual authentication, encryption and data integrity for signaling, voice and data traffic. In other embodiments, the SeGW 235 is a logical entity within the HNB- GW 215.

Figure 2 and other figures below illustrate a single access point (e.g., HNB 205) communicatively coupled to a network controller (e.g., HNB-GW 215). However, it should be apparent to one of ordinary skill in the art that the network controller (e.g., HNB-GW 215) of some embodiments is communicatively coupled to several HNBs and the network controller communicatively couples all such HNBs to the core network. Also, the HNB of some embodiments is communicatively coupled to several UEs. The figures merely illustrate a single HNB communicatively coupled to the HNB-GW for purposes of simplifying the discussion to interactions between a single access point and a single network controller. However, the same network controller may have several of the same interactions with several different access points.

Figure 3 illustrates the HNB-AN system architecture of some embodiments integrated with a core network of a second communication system that includes a licensed wireless radio access network. Specifically, the basic elements of the HNB system architecture with Iu interfaces towards the CN are illustrated this figure. This architecture supports access control for both legacy and CSG UEs in the Home Node-B Gateway (HNB-GW). Thus, the deployment of this architecture minimizes changes to the CN (e.g., HLR, MSC, SGSN). Accordingly, the CN 335 is marked as a non-CSG CN in the architecture of Figure 3.

The HNB system includes (1) Home Node-B (HNB) 305, (2) Home Node-B Gateway (HNB-GW) 315, (3) Generic IP Access Network 320, (4) Security Gateway (SeGW) 325, (5) HNB Management System 330, and (6) HNB subscriber database 375. The licensed wireless radio access network of the second communication system includes UTRAN which is comprised of Node-Bs and Radio Network Controllers of a UMTS. These well-known elements of the licensed wireless access network are not illustrated in Figure 3.

As shown, the core network of the second communication system includes Mobile

Switching Center (MSC) 365, Serving GPRS Support Node (SGSN) 370, Authorization, Authentication, and Accounting server 355, and Home Location Register 360. Additionally, Service Mobile Location Center (SMLC) and Cell Broadcast Center (CBC) may be components of the core network.

A. User Equipment (UE)

In some embodiments of the invention, UE 310 or 312 is used to access services of the HNB-AN and also access services of the licensed wireless radio access network 385 of a cellular provider. In the example illustrated in Figure 3, the UE 312 represents a legacy UE prior to CSG standards or a non-CSG UE, while the UE 310 represents a UE that supports CSG functionalities. The CSG capability of the UE (and the associated information) may be provisioned from an operator controlled external provision system. In some such embodiments, the UE seamlessly transitions from the HNB-AN to the cellular provider and vice versa without loss of connectivity. In some embodiments, the UE is thus a standard device operating over licensed spectrum of a licensed wireless system provider. Accordingly, the UE wirelessly connects to the HNB 305 using the same signalling and messaging interfaces as it would when connecting to a base station, such as a base transceiver station (BTS) in GSM, or the Node-B 380 of a Universal Mobile Telecommunications System (UMTS).

In some embodiments, UEs include (1) standard licensed wireless handsets and wireless enabled computers that connect through HNBs, (2) devices such as wired telephones and faxes that connect to HNB through terminal adapters, and (3) softmobile enabled devices.

1. Licensed Wireless Handsets

In some embodiments, the UE 310 or 312 includes cellular telephones, smartphones, PDAs, and modem like devices. These devices include any device that wirelessly communicates with a licensed wireless service provider using existing licensed wireless technologies, such as Global System for Mobile (GSM) communications, UMTS, etc.

B. HNB

The Home Node-B (HNB) 305 is an access point that offers a standard radio interface (Uu) for user equipment (UE) connectivity using short range licensed wireless frequencies. The HNB 305 provides the radio access network connectivity to the UE using the Iuh interface towards the HNB-GW 315.

In some embodiments, the HNB is envisioned to support RNC like functions as well as supporting functionality for operating in ad-hoc environment. The HNB may also broadcast a CSG indicator along with a CSG identity. Additionally, the HNB may perform access control for both legacy UEs and CSG UEs. In order to perform access control, the HNB is provisioned with a list of the permanent identities (IMSIs) of UEs, e.g. by the HNB Management System. An example of the HNB performing access control operations is described below by reference to Figure 8.

The HNB 305 differs from the UMTS Node-B in that the range of wireless connectivity supported by the HNB 305 (e.g., tens of meters) is much less than the range supported by the UMTS Node-B (e.g., hundreds or thousands of meters). This is because the HNB 305 is a low power and a short range device similar to wireless access points found within a user's home. The low power and short range requirement ensures that the HNB 305 does not interfere with the service regions of the licensed wireless system providers (e.g., cellular networks) that are established using the wireless frequencies that the licensed wireless system providers licensed from the government at great expense. Moreover, the low power requirement enables the HNB 305 to operate using standard electrical outlets of a user's home or office. In some embodiments of the invention, the low power and short range requirement further facilitates the small scale of the HNB device relative to the radio access network Node-B devices. Unlike the Node-B, which is housed in one or more racks and cabinets and the antennas for its radios are mounted on a tower reaching several meters in height, the HNB is a much smaller device often the size of 802.11 wireless routers commonly found within a user's home.

Conversely, the Node-B is network equipment of a UMTS Terrestrial Radio Access Network (UTRAN). The Node-B is managed and operated by a licensed wireless system provider. The Node-B of the licensed wireless system has to provide service to many more users than the HNB 305 and must do so without loss of connectivity over vast regions (e.g., states and countries). Accordingly, the licensed wireless service provider deploys several Node-Bs that are adjacent to one another in order to create an uninterrupted region of coverage. Conversely, an HNB service region established by a first HNB does not need to be adjacent to any other HNB service region and may or may not offer uninterrupted service between HNB service regions.

In some embodiments, the HNB 305 is user hosted as opposed to the Node-B that is hosted by the licensed wireless system. A user hosted HNB allows a user to specify the location of the HNB, provide the connectivity between HNB and the HNB network or HNB-GW (e.g., the broadband connection), control operation of the HNB, for example, by providing power to the HNB. All such control over the Node-B is tightly managed by the licensed wireless system provider. In other words, the HNB is customer premise equipment (CPE) that a user is able to potentially purchase from an electronics store or from the HNB-AN provider, whereas the Node- B is network equipment that is impractical for a single user to purchase, operate, and maintain.

Additionally, a key characteristic of the HNB architecture of some embodiments is that there are no permanent pre-configured peer adjacencies between HNB and HNB-GW. Instead, there are ad-hoc adjacencies that are initiated from the HNB (as it is usually behind a NAT/firewall, and does not have a permanent IP address in the carrier network). The HNB system therefore offers flexibility in deploying service. The HNBs of an HNB system may be deployed on an ad hoc basis as opposed to the regimented deployment structure of the licensed wireless system.

Accordingly, in some embodiments, the HNB 305 supports enhancements for operating in an ad-hoc environment and the Node-B does not. The ad hoc system allows for individual users to establish HNB service regions based on each user's needs. In some embodiments, each user purchases an HNB and each of the HNBs may be purchased from different vendors with different HNB implementations. In this manner, the ad hoc HNB system creates several individual local coverage areas based on user deployment of each HNB whereas the licensed wireless system deploys its Node-Bs in an effort to provide regional coverage area that is uninterrupted across large areas (e.g., hundreds of miles).

In the architecture illustrated in Figure 3, the HNB 305 is capable of access control for the CSG UE 310. Specifically, the HNB 305 performs the access control for the CSG UE by determining whether the CSG UE is authorized by accessing a list of one or more IMSIs that identities each UE that is authorized to access the HNB. In some embodiments, the HNB is provisioned with the list based on data stored in the HNB Subscriber Database 375. The HNB Subscriber Database 375 will be described in detail below.

1. Terminal Adapters

In some embodiments, the UE function is integrated with the HNB and is combined with a terminal adapter interface that allows fixed-terminal devices such as telephones, faxes, and other equipments that are not wirelessly enabled within the HNB-AN to access telephony services provided by the mobile core network. 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 Voice over IP (VoIP) services, where the fixed-terminal devices are connected to the subscriber's existing broadband (e.g., Internet) service through a modified HNB functioning as a terminal adapter.

2 SoftMobiles

Connecting laptops 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. Accordingly, the UE 310 or 312 of some embodiments includes SoftMobile like devices.

To use a SoftMobile service, a subscriber would run software that complies with the Iuh defined interface and procedures on their laptop and communicate with the HNB-GW via the generic IP access network. The SoftMobile client would emulate the operation of a combined UE and HNB. From that point on, the subscriber would be able to make and receive mobile calls as if she was in her home calling area.

It should be apparent to one of ordinary skill in the art that in some embodiments the HNB system provider deploys the HNBs rather than the users. In some such embodiments, the system remains ad hoc by virtue of the discontinuous nature of the separate and local HNB service regions. Additionally, in some such embodiments, the HNBs remain user hosted since power and broadband connectivity is provided by the user even though the system provider more closely regulates the HNB equipment that is deployed.

The ad hoc nature of the HNB system also allows the system to grow and shrink as its user base grows and shrinks. For example, whenever a new user desires to utilize the HNB service, the user purchases and hosts a HNB at a home or office location. The user hosted HNB provides the user with a HNB-AN service region from which the user access HNB system services. Conversely, the licensed wireless system provider must first deploy several Node-Bs in order to provide extensive large scale regional coverage. Once the service regions are established at great expense to the licensed wireless system provider, users then activate service with the licensed wireless system provider. Accordingly, the HNB system is an unplanned system whereas the licensed wireless system is a planned system. In other words, the HNB system does not need an existing access point infrastructure in order to operate. Rather, the infrastructure is unplanned whereby the infrastructure is built upon with every new user that is added to the system. This is opposite to the planned licensed wireless system. The licensed wireless system requires that there be an existing infrastructure before it can serve new users. The infrastructure of the licensed wireless system is planned in the sense that the infrastructure is built first in a particular region and then the service is marketed to that region after the infrastructure is built.

The HNB 305 also differs from generic access points used in UMA systems. Specifically, in a UMA system the access points act as transparent base stations. In other words, the user equipment and the network controller directly communicate. In the HNB system, however, the HNB 305 includes various Radio Network Controller (RNC) functionality. In some such embodiments, the HNB 305 initiates various messaging procedures and maintains state information regarding user equipment operating within the service region associated with the HNB 305. The HNB 305 is equipped with either a standard 3G Universal Subscriber Identity Module (USIM) or a 2G SIM. The (U)SIM provides the HNB 305 with a unique subscriber identity and allows the HNB 305 to utilize the existing subscriber management infrastructure of an operator. That is, a SIM or USIM provides a unique subscriber identity that can be authenticated using the existing subscriber management infrastructure. In some embodiments, the HNB system utilizes a Public Key Infrastructure (PKI) using public and private certificates that, like the SIM or USIM, can be used for authentication.

It should be apparent to one of ordinary skill in the art that some embodiments of the HNB system utilize a different identification mechanism for the HNB than the (U)SIM. For example, the HNB identity of some embodiments is based on Media Access Control (MAC) address of the HNB or any other globally unique identifier such as the combination of vendor identity and serial number from that vendor.

The access points of some embodiments include circuits for receiving, transmitting, generating, and processing the various messages that cause various physical transformations within the HNB-AN, core network, and licensed wireless radio access network. In some embodiments, the circuits of the access points include processing units (e.g., one or more processors), memory, receiver, and transceiver. In some embodiments, the receiver and/or the transceiver are wireless interfaces that operate using short range licensed wireless frequencies. In some other embodiments, the receiver and/or the transceiver are wired interfaces (e.g., DSL, cable, etc.). These circuits perform various physical transformations on the access point as well as other elements within the HNB-AN, licensed wireless radio access network, and core network. For example, the processor in conjunction with the memory generate a paging message that when sent to a UE using the transceiver causes the UE to prompt the user of an incoming call. As another example, the access point registers a UE by generating a registration message that is sent to the network controller using the transceiver when the access point detects that the UE has camped on the service region of the access point based on a location update message received by the access point on its receiver. These and other physical components of the access points of some embodiments are described with further detail in Figure 10 below. It should be apparent to one of ordinary skill in the art that the HNB is one implementation of an access point that operates using short range licensed wireless frequencies. Some embodiments allow for any access point that operates using short range licensed wireless frequencies to be used in place of or in conjunction with the HNBs.

C. Generic IP Access Network

The HNB 305 provides radio access network connectivity for the UE 310 or 312. The HNB 305 then communicatively couples the UE to the HNB-GW 315 using the luh interface that exists between the HNB 305 and the HNB-GW 315. As shown in Figure 3, the luh interface is established over a Generic Internet Protocol (IP) access network 320 (e.g., a broadband IP network) where, in some embodiments, a customer's broadband connection is utilized. The Generic IP Access Network 320 represents all the elements that collectively, support IP connectivity between the HNB-GW 315 and the HNB 305. The IP network 320 is assumed to be an untrusted public IP network.

In some embodiments, the Generic IP Access Network 320 includes (1) other Customer premise equipment (e.g., Digital Subscriber Line (DSL)/cable modem, Wireless Local Area Network (WLAN) switch, residential gate way s/routers, switches, hubs, WLAN access points), (2) network systems specific to the broadband access technology (e.g., DSL Access Multiplexer (DSLAM) or Cable Modem Termination System (CMTS)), (3) Internet Service Provider (ISP) IP network systems (edge routers, core routers, firewalls), (4) wireless service provider (WSP) IP network systems (edge routers, core routers, firewalls) and Network address translation (NAT) functions, either standalone or integrated into one or more of the above systems.

D. HNB-GW

The HNB-GW 315 is a network controller that provides network connectivity of the HNB 305 to the existing core network (CN) 335. The HNB-GW 315 entity appears as a legacy RNC to the existing CN 335. Specifically, the HNB-GW 315 uses existing Iu interfaces (e.g., lues and Iu-ps) for CN connectivity. In this manner, the HNB system may be integrated into the existing CN 335 with no change to the CN 335. This allows the licensed wireless system providers the ability to provide HNB system functionality to their users with no change to their existing network.

In some embodiments, to provide connectivity of the HNB to the existing CN, the HNB-

GW performs corresponding functions, such as the management of the legacy UTRAN identifiers (LAI, SAI, RND-Id, etc) towards the CN. HNB-GW connects to the HNB using the luh interface, and performs luh interface management. In some embodiments, the HNB-GW performs access control for both non-CSG UEs (e.g., legacy UEs) and CSG UEs. To perform access control for CSG UEs, in some embodiments, the HNB-GW retrieves the permanent identity (IMSI) of the CSG UE using the MAP SEND IDENTIFICATION message (as specified in TS 29.002) from the source VLR. An example of the HNB-GW retrieving a CSG UE's IMSI is described below by reference to Figure 9. In some embodiments, the HNB-GW 315 performs access control operations of a UE by accessing HNB subscriber database using the UE's IMSI as well the HNB identity and CSG identity.

As noted above, the HNB-GW 315 connects to the HNB 305 using the luh interface.

Additional interfaces of the HNB-GW 315 include the Iu-pc interface to the Service Mobile Location Center (SMLC) 340, the Iu-bc interface to the Cell Broadcast Center (CBC) 345, the Wm interface to the Authorization, Authentication, and Accounting (AAA) server (not shown), and an interface that is based on the TR-069 family of standards, as specified by the Broadband Forum technical specifications, to the HNB management system 330. It should be apparent to one of ordinary skill in the art that other interfaces may be used instead of or in addition to the above enumerated interfaces.

In some embodiments, the HNB-GW 315 connects to several different HNBs and services each of the corresponding service regions of each of the several HNBs. In this manner, a single HNB-GW, such as the HNB-GW 315, communicatively couples multiple HNB service regions to the CN 335. Accordingly, the HNB-GW 315 provides call management functionality, mobility management functionality, security functionality, etc. as will be described in greater detail below. The HNB-GW 315 also performs key functionalities, such as the management of the legacy UTRAN identifiers (Location Area Identifiers (LAI), Service Area Identifiers (SAI), RNC-Id, etc.) towards the CN 335, and luh interface management.

In the architecture illustrated in Figure 3, the HNB-GW 315 is capable of access control for the CSG UE 310. Specifically, the HNB-GW 315 accesses a HNB Subscriber Database 375 that stores access data that matches UEs with CSGs that the UEs are authorized to access. As shown in Figure 3, the HNB Subscriber Database 375 includes data related to a HNB and a list of CSG UEs that are able to access the service of the HNB. In some embodiments, the HNB Subscriber Database 375 includes, for each particular HNB, an identity of the particular HNB, the CSG identity that the particular HNB broadcasts, and a list of CSG UEs that are part of the CSG. As shown in Figure 3, the HNB Subscriber Database 375 may include other attributes for each particular HNB. In some embodiments, the UE list of the HNB Subscriber Database 375 contains a list of permanent identities (i.e., IMSIs).

In the example illustrated in Figure 3, the HNB Subscriber database stores a list of UE identifiers for each HNB identity or CSG identity. However, the HNB Subscriber Database, in some embodiments, stores the relationship between UE and CSGs differently. For example, instead of listing different UE identifiers for each HNB identity or CSG identity, the HNB Subscriber Database may list one or more CSG or HNB identifiers for each UE identity.

As described above, in some embodiments HNB 305 also performs access control by accessing a list that identifies each CSG UE that is authorized to access the HNB. In some embodiments, the HNB's list is based on data stored in the HNB Subscriber Database 375.

As illustrated in Figure 3, the HNB subscriber database 375 is stored in the HNB-GW 315. However, the HNB subscriber database is stored external to the HNB-GW in some embodiments.

As mentioned above, a feature of the CSG environment is maintaining user identity confidentiality. To maintain confidentiality, the HNB-GW 315 does not send Identity Request to the UE when it receives the CSG UE's temporary identify (e.g., TMSI, or PTMSI) in the UE Registration Request message. As illustrated in Figure 3, the HNB-GW 315, in some embodiments, queries the source VLR to identity the permanent identity (i.e., IMSI) of the CSG UE. The HNB-GW 315 then performs access control for the UE based on the UE's permanent identity. An example of the HNB-GW 315 querying the source VLR will be described below by reference to Figure 9.

In some embodiments, the HNB-GW 315 includes various software module sub- components and/or various hardware module sub-components that perform some of the above mentioned functionality. For example, in some embodiments, the Security Gateway (SeGW) 325 is a logical entity within the HNB-GW 315. The SeGW 325 provides the security functions including termination of secure access tunnels from the HNB 305, mutual authentication, encryption and data integrity for signaling, voice and data traffic. In other embodiments, SeGW is a standalone entity and is not an entity within the HNB-GW. E. HNB Management System

The HNB Management System 330 (HMS) provides centralized Customer Premise Equipment (CPE) device management for the HNB 305 and communicates with the HNB 305 via the security gateway logical entity. This system is used to manage a large number of HNBs including configuration, failure management, diagnostics, monitoring and software upgrades. In some embodiments, the HNB Management System 330 utilizes existing CPE device management techniques such as those described in the DSL Forum technical specifications TR- 069. In some embodiments, the HMS may also provision the HNBs with a list of the permanent identities (IMSIs) of the UEs that are authorized to access that HNB 305 by referring to a HNB Subscriber Database.

The network controller of some embodiments includes circuits for receiving, transmitting, generating, and processing the various messages that cause various transformations (e.g., information transformation) within the HNB-AN, core network, and licensed wireless radio access network. In some embodiments, the circuits of the network controller include a processor, memory, receiver, and transceiver. These circuits perform various physical transformations on the network controller as well as other elements within the HNB-AN, licensed wireless radio access network, and core network. For example, the processor in conjunction with the memory generate context identifiers that when sent to a UE using the transceiver provide the UE with a unique identifier when operating within the HNB-AN. These and other physical components of the network controller of some embodiments are described with further detail in Figure 10 below.

F. Core Network (CN) and Other Network Elements

As mentioned above, the HNB-GW 315 provides network connectivity of the HNB 305 to the existing CN 335. The CN 335 includes one or more HLRs 360 and AAA servers (not shown) for subscriber authentication and authorization. Once authorized, the UE may access the voice and data services of the CN 335 through the HNB system. As will be described in detail by reference to Figure 8 and 9, some embodiments perform access control at the HNB and/or the HNB-GW.

The CN 335 includes a Mobile Switching Center (MSC) 365 to provide circuit switched services (i.e., voice). The CN also includes a Serving GPRS Support Node (SGSN) 370 to provide packet switched services. Though not shown in Figure 3, the SGSN operates in a conjunction with a Gateway GPRS Support Node (GGSN) in order to provide the packet switched services.

The SGSN 370 is typically responsible for delivering data packets from and to the GGSN and the UE within the geographical service area of the SGSN 370. Additionally, the SGSN 370 may perform functionality such as mobility management, storing user profiles, and storing location information. However, the actual interface from the CN 335 to various external data packet services networks (e.g., public Internet) is facilitated by the GGSN. As the data packets originating from the UE typically are not structured in the format with which to access the external data networks, it is the role of the GGSN to act as the gateway into such packet services networks. In this manner, the GGSN provides addressing for data packets passing to and from the UE 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 to provide a static gateway into the external data networks.

Location services are provided by the SMLC 340. The CBC 345 provides support for cell broadcast services. These and other elements of the CN 335 are primarily intended for use with the licensed wireless systems. In the description below, the licensed wireless system will be described with reference to the UTRAN of a UMTS. However, it should be apparent to one of ordinary skill in the art that any licensed wireless system, such as a GSM/EDGE Radio Access Network (GERAN) may be used to reference the licensed wireless system.

Elements common to a UTRAN based cellular network include multiple base stations referred to as Node-Bs that facilitate wireless communication services for various UE via respective licensed radio links (e.g., radio links employing radio frequencies within a licensed bandwidth). The licensed wireless channel 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 385 typically includes at least one Node-B 380 and a Radio Network Controller (RNC) 375 for managing the set of Node- Bs. Typically, the multiple Node-Bs are configured in a cellular configuration 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. Each RNC communicates with components of the core network through the above described standard radio network controller interface such as the Iu-cs and Iu-ps interfaces. For example, a RNC communicates with MSC via the UTRAN Iu-cs interface for circuit switched services. Additionally, the RNC communicates with SGSN via the UTRAN Iu-ps interface for packet switched services through GGSN. It is through the use of these standardized network interfaces that the HNB system, more particularly the HNB-GW, may be seamlessly integrated to leverage services of the CN and emulate functionality of a legacy RNC of the licensed wireless system.

II. PROTOCOL ARCHITECTURES OF THE HNB SYSTEM

Functionality provided by each of the HNB and the HNB-GW are defined within various protocol stacks. In some embodiments of the invention, the protocol stacks include software layers that are stored to the memory of the HNB and HNB-GW and that are executed by a processing unit of the HNB and HNB-GW. In some embodiments, the protocol stacks are implemented as hardware modules within the HNB and HNB-GW. Additional hardware components of the HNB and HNB-GW are described below in Section V, "Computer System".

In some embodiments, the HNB system separates management functions from control plane functions into two separate protocol stacks. The HNB Application Part (HNBAP) protocol architecture implements the management functions for the HNB system and the RANAP protocol architecture (supported by the RANAP User Adaptation (RUA) protocol for transporting RANAP messages between HNB and HNB-GWs) implements the control functions for the HNB system. Additional protocol architectures are specified for providing other functionality such as user plane functionality. However, it should be apparent to one of ordinary skill in the art that other protocol architectures may be integrated into the components of the HNB system and that the functionality of each of the protocol architectures is scalable to provide more or less functionality than described below.

A. Protocol Architecture over the Iuh Interface

1. HNB Application Part (HNBAP) Protocol Architecture As noted above, the HNBAP protocol architecture supports management functions between the HNB and HNB-GW including, but not limited to, the management of the underlying transport (i.e., the SCTP connection), HNB and UE registration procedures. Figure 4 illustrates the HNBAP protocol architecture in accordance with some embodiments. This figure illustrates (1) HNB 405, (2) SEGW 455, (3) HNB-GW 415, and (4) HNBAP protocol stacks of each of the HNB 405 and the HNB-GW 415. The HNBAP protocol stacks of the HNB 405 include (1) access layers 410, (2) transport IP layer 420, (3) IP Security (IPSec) ESP layer 425, (4) remote IP layer 440, (5) Stream Control Transmission Protocol layer (SCTP) 430, and (6) a HNBAP protocol layer 445. The HNBAP protocol stacks of the HNB-GW 415 include (1) Ethernet layer 450, (2) remote IP layer 440, (3) Stream Control Transmission Protocol layer (SCTP) 430, and (4) a HNBAP protocol layer 445

In some embodiments, a UDP layer 460 exists for the HNB 405 and the SEGW 455. Here, the UDP layer 460 is shown between the transport IP layer 420 and the IPSec layer 425. As shown in Figure 4, the UDP layer 460 is an optional layer and not a mandatory one.

The underlying Access Layers 410 and "Transport IP" layer 420 (i.e., the "outer" IP layer associated with IPSec tunnel mode) provide the generic connectivity between the HNB 405 and the HNB-GW 415 via the SEGW 455. The IPSec layer 425 operates in tunnel mode and provides encryption and data integrity for communications and data that are passed using the upper layers (430, 440, and 445).

The SCTP 430 provides reliable transport between the HNB 405 and the HNB-GW 415. SCTP 430 is transported using the "Remote IP" layer 440 (i.e., the "inner" IP layer associated with IPSec tunnel mode). It should be apparent to one of ordinary skill in the art that other reliable transport protocol layers may be used instead of SCTP 430 to facilitate reliable transport of communications and data between the HNB 405 and the HNB-GW 415.

In some embodiments, the HNBAP protocol 445 provides a resource management layer, registration of the HNB and UE with the HNB-GW, registration updates with the HNB-GW, and support for the identification of the HNB being used for HNB access. It should be apparent to one of ordinary skill in the art that the HNBAP protocol layer of some embodiments implements additional resource management functionality and that the above enumerated list is an exemplary set of such functionality.

2. HNB Control Plane Architecture (RUA)

After performing the management functions defined by the HNBAP protocol, the HNB and HNB-GW utilize a different protocol architecture that specifies the control plane in the HNB system. Figure 5 illustrates the protocol architecture in support of the HNB control plane (i.e., for both the CS and PS domain) in accordance with some embodiments. Figure 5 includes (1) HNB 505, (2) SEGW 575, (3) HNB-GW 515, (4) CN 540, (5) UE 550, and (6) control plane protocol stacks of each of the HNB 505, the SEGW 575, the HNB- GW 515, the CN 540, and the UE 550. The control plane protocol stacks of the HNB 505 include (1) access layers 510, (2) transport IP layer 520, (3) IPSec layer 525, (4) remote IP layer 540, (5) SCTP 530, and (6) RANAP user adaptation (RUA) layer 535.

The control plane protocol stacks of the SEGW 575 include (1) access layers 510, (2) transport IP layer 520, (3) IPSec layer 525, and (4) remote IP layer 540. In some embodiments, a UDP layer 585 exists for the HNB 505 and the SEGW 575. Here, the UDP layer 585 is shown between the transport IP layer 520 and the IPSec layer 525. The UDP layer 585, in some embodiments, is used for Network Address Translation (NAT) traversal. As mentioned above by reference to Figure 4, the UDP layer 585, in some embodiments, is an optional layer and not a mandatory one.

The control plane protocol stacks of the HNB-GW 515 include (1) Ethernet layer 570, (2) remote IP layer 540, (3) SCTP 530, (4) RANAP user adaptation (RUA) layer 535, and (5) interworking functionality (IWF). In some embodiments, the control plane protocol stacks the HNB-GW 515 includes the MM/GMM layer as one or more of these messages are interworked at the HNB-GW. The control plane protocol stack of the CN 540 includes signaling transport layers defined according to the 3GPP technical specification TS 25.412, "UTRAN Iu Interface Signaling Transport", herein incorporated by reference, a RANAP layer, and a Non Access Stratum (NAS) layer 565 and 580 that performs various call management, mobility management, General Packet Radio Service (GPRS) mobility management and session management, and short message services (SMS). The control plane protocol stack of the UE 550 includes a layer 1 signaling transport layer, a Media Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Radio Resource Control (RRC) layer, and the NAS layer 565 and 580.

As described above, the underlying Access Layers 510 and "Transport IP" layer 520 provide the generic connectivity between the HNB 505 and the HNB-GW 515. The IPSec layer 525 provides encryption and data integrity for communications and data that are passed using the upper layers. SCTP 530 provides reliable transport for the RANAP User Adaptation (RUA) layer 535 between the HNB 505 and the HNB-GW 515.

The RANAP protocol is used for CS/PS signaling between the HNB 505 and the CN 540.

RANAP, as is well known in the art, is an established protocol used for UMTS signaling between the CN and the UTRAN of a licensed wireless radio access network. Accordingly, the use of RANAP messages within the control plane of the HNB system, allows for the HNB system to support many of the UTRAN functions in the HNB system. These functions include: Radio Access Bearer (RAB) management, Radio Resource Management (RRM), Iu link management, Iu U-plane Radio Network Layer (RNL) management, mobility management, security, service and network access, and Iu coordination.

The HNB-GW 515 relays the RANAP messages between the HNB 505 and the CN 540. In some embodiments, the HNB-GW 515 terminates and re-originates some RANAP messages. For example, the HNB-GW 515 terminates and re-originates connection-less RANAP messages.

To perform the transparent transfer of RANAP messages, the HNB control plane protocol stacks of the HNB 505 and the HNB-GW 515 include the RUA layer 535. The RUA layer 535 provides a lightweight mechanism to transport RANAP messages 560 and control functions between the HNB 505 and the HNB-GW 515. Specifically, the RUA layer 535 encapsulates the RANAP messages 560 in an RUA layer header for transport between the HNB 505 and the HNB-GW 515. Therefore, through the use of the RUA 535 layer, no changes are made to the RANAP message definitions. Rather, all necessary changes are contained in the RUA header.

It should be apparent to one of ordinary skill in the art to reference the RUA layer with other terminologies such as RANAP Adaptation Layer (RAL) or RANAP Transport Adaptation (RTA), etc. However, the key function of this adaptation layer is to provide the functionality, over the luh interface, of transferring RANAP messages as defined in the 3GPP technical specification TS 25.413 entitled "UTRAN Iu interface Radio Access Network Application Part (RANAP) signaling" which is incorporated herein by reference, and will be referred to as TS 25.413.

Through the RUA header and the encapsulation of the RANAP message, the RUA adaptation layer of some embodiments enables: (1) transport of RANAP messages using SCTP over the luh interface between the HNB and HNB-GW, (2) support for associating and identifying UE specific logical connections (i.e., identifying the RANAP messages belonging to a specific UE via the concept of UE context identifiers), (3) support for routing the establishment of a signalling connection to a CN node within a CN domain (i.e., support for Iu-flex at the HNB-GW), (4) support for indicating the cause for establishing the UE specific logical connection (e.g., for emergency session establishment, etc.), (5) providing a mechanism to transparently relay the RANAP messages from the HNB to CN without the need to decode the encapsulated RANAP message, and (6) support for the indication of service domain (CS or PS) for the RANAP messaging.

The RUA layer 535 minimizes the decoding and processing of RANAP messages 560 at the HNB-GW 515. Specifically, the HNB-GW 515, in many instances, no longer must decode and process the RANAP message 560. Instead, the HNB-GW 515 processes information within the RUA header information in order to determine a destination within the core network to receive a RANAP message 560 sent from a UE operating from a HNB service region communicatively coupled by the HNB-GW 515. The RUA layer 535 also eliminates the need for the HNB-GW 515 to process and decode the NAS layer 565.

In some embodiments, the RUA layer 535 does not duplicate existing RANAP procedures. Accordingly, RUA procedures are minimized. As will be described in further detail below, the HNB control plane protocol architecture of some embodiments simplifies context-ID allocation and associated functional overhead.

The RUA 535 utilizes the same underlying transport (i.e., SCTP connection) as HNBAP.

It should be apparent to one of ordinary skill in the art that it is also possible to use TCP as a reliable transport layer instead of SCTP. The SCTP PPI value used for RUA transport is coordinated between the HNB 505 and the HNB-GW 515.

In some embodiments, a dedicated SCTP stream (e.g., stream id 0 of the underlying SCTP transport association) is used for the transport of connectionless RANAP messages 560 between the HNB 505 and the HNB-GW 515. For the connection oriented messages, the number of SCTP streams to be established at SCTP connection setup and the mapping of UE transactions to the specific SCTP streams is an implementation choice. The use of UE Context-Id allows multiple UE transactions to be multiplexed over the same SCTP stream.

The Inter- working Functionality (IWF) 545 in the HNB-GW 515 switches the RANAP messages 560 between the Iuh interface and the corresponding domain specific (CS/PS) Iu interface. It should be noted that the IWF 545 is a logical entity in the RUA protocol stack. As mentioned above, some RANAP messages 560 are terminated and re-originated in the HNB-GW 515 (e.g., connection-less RANAP messages) and some are modified in the HNB-GW 515 to adapt to the underlying transport towards the CN 540 (e.g., when using ATM interfaces towards the CN 540). Additionally, NAS protocol messages 555 (e.g., CC/MM/SMS, etc) are carried transparently between the UE 550 and the CN 540.

In some embodiments, the relay of RANAP messages 560 between the HNB 505 and the CN by the HNB-GW 515 is achieved using a direct transfer mechanism over the luh interface. This direct transfer mechanism involves encapsulation of the RANAP messages 560 in a DIRECT TRANSFER message exchanged between the HNB 505 and HNB-GW 515 over the luh interface. In some embodiments, this message is referred to as a RUA DIRECT TRANSFER message. In some embodiments, this message is referred to as a HNBAP DIRECT TRANSFER message. In some embodiments, the direct transfer mechanism is used to relay messages from CBC (Iu-bc) (not shown) and SMLC (Iu-pc) (not shown) to HNB 505 and vice-versa via the HNB-GW 515.

The architecture of Figure 5 also supports transfer of the RANAP "Initial UE Message" and support for Iu-flex. Iu-flex functionality is defined in 3GPP TS 23.236, "Intra-Domain Connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes", hereinafter, TS 23.236, with additional functionality such as messaging, etc., described in TS 25.331. Specifically, Iu-flex covers details for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes for GSM and UMTS systems. The first RANAP message (i.e., the RANAP "Initial UE Message") is carried from the HNB 505 in the RUA CONNECT message over the luh interface. The RUA CONNECT message also carries information used to route the establishment of a signalling connection from HNB-GW 515 to a CN node within a CN domain (i.e. support for Iu-flex).

Many of the common or connection-less RANAP messages are terminated and processed in the HNB-GW 515. When there is a need to relay specific connectionless message (e.g. Paging), then the DIRECT TRANSFER message is used to relay the specific connection-less message.

In some embodiments, the direct transfer mechanism for relaying RANAP messages provides a single protocol over the luh interface (i.e., clean architecture) whereby a single interface between HNB and HNB-GW functional entity is used. The direct transfer mechanism of some embodiments eliminates changes to the RANAP specifications for use over the luh interface. If RANAP were to be used directly over the luh interface, then all the specifications which reference RANAP would need to be updated to describe the applicability of existing RANAP messages between the two new nodes (e.g., HNB and the HNB-GW). In some embodiments, the direct transfer mechanism eliminates the need for "RNC-ID" and "Iu signalling connection identifier" attributes on a per HNB basis, carried in the RANAP messages. The "RNC-ID" and "Iu-signalling connection identifier" carried in the downlink RANAP messages are processed by the HNB-GW and can be ignored by the HNB. Similarly, in the uplink RANAP messages, the usage of the RNC-ID and Iu signalling connection identifier attributes can be implementation specific with no impact on the Iuh interface. Additionally, by carrying the RANAP messages in a container, the overhead (management and runtime) and limitations (e.g. size of address space) of the underlying transport layers of RANAP such as SCCP/M3UA are eliminated as well.

III. UE REGISTRATION

After an HNB is registered with a HNB-GW, the HNB establishes a short range licensed wireless service region of the HNB system. When UEs enter the service region, the HNB performs a registration procedure to authenticate and authorize the UE for HNB service for the service region of a particular HNB. UE registration first determines whether the HNB is permitted to access services of the HNB system through the particular service region associated with the HNB on which the UE is camped. UE registration also serves to determine what services the UE is authorized to access from that particular service region. Similar to the HNB registration, UE registration is performed through the HNB-GW.

Based on the service policy of the HNB system provider, UEs may be restricted to service through certain HNBs i.e. the HNBs may have a closed subscriber group (CSG) for allowing access through the particular HNB. In some embodiments, the UE is allowed service through an HNB that is associated with the user's home location. In some embodiments, the UE is allowed HNB service through certain HNB hotspots. By providing registration through the HNB-GW, some embodiments provide a central location whereby access to the HNB services can be controlled.

A. Non-CSG UE Registration

Figure 6 provides a message flow diagram 600 illustrating a HNB 605 registering a UE 610 with a HNB-GW 615. Specifically, in this figure, the UE 610 is a non-CSG UE (e.g., legacy UE), or the HNB does not support CSG functionality or is operating in a mode that does not support CSG functionality. As shown in Figure 6, upon camping on the HNB 605, the UE 610 initiates (at step la) a Location Update procedure by establishing a RRC connection with the HNB 605. Here, to trigger an initial message upon camping on the HNB 605, the HNB 605 has a location area that is distinct from its neighboring HNB and macro cells.

The UE 610 then transmits (at step lb) a NAS message carrying the Location Updating

Request message with some form of identity (IMSI/TMSI). If the (P)TMSI of the UE 610 (provided during RRC Connection Establishment) is unknown at the HNB being accessed (e.g., first access attempt by this specific UE using the (P)TMSI), the HNB requests (at step lc) the IMSI of the UE and the UE replies at step Id.

In some embodiments, where the networks support network mode 1 , the UE could trigger a combined Routing Area and Location Area update request instead of the initial LU request. The HNB may also optionally perform local access control for faster rejection of those UEs not authorized to access the particular HNB. If the HNB performs the local access control, then unauthorized UEs are not attempted to be registered with the HNB-GW.

The HNB 605 attempts (at step 2) to register the UE 610 on the HNB-GW 615 over the

UE specific transport session by transmitting the HNBAP UE REGISTER REQUEST. The message contains location information and the UE identity such as the IMSI of the (U)SIM associated with the UE. The HNB identity over which the UE is attempting access can be inferred or derived by the HNB-GW based on HNB registration and the associated transport session (e.g. SCTP session) since the UE registration is also attempted (by the HNB) using the same transport session.

The HNB-GW 615 performs access control for the particular UE 610 attempting to utilize the specific HNB 605. If the HNB-GW 615 accepts the registration attempt, it responds (at step 3) with a HNBAP REGISTER ACCEPT message back to the HNB 605. In some embodiments, the HNB-GW 615 also assigns information specific to the UE 610 such as SAI specific to the registered UE, UE Context Id (for use in the RUA layer), etc. The UE Context Id provides a unique identifier for each UE within a particular HNB-GW. The UE Context Id is used to identify a logical Iuh signaling connection for a given UE. Additionally, since the UE Context Id is unique within the HNB-GW, it may also be used (e.g. by the HNB) as the "Iu signaling connection identifier" in corresponding RANAP messages for that particular UE. The HNB 605 performs (at step 4) a NAS relay of the Location Updating Request message from the UE 610 to the HNB-GW 615 via the use of RANAP Initial UE Message. The RANAP Initial UE Message is encapsulated in the RUA message header with additional necessary information which enables the HNB-GW 615 to relay RANAP message towards the appropriate CN entity.

The HNB-GW 615 establishes (at step 5) a SCCP connection to the CN 620 and forwards the Location Update request (or the combined RA/LA update request) NAS PDU to the CN 620 using the RANAP Initial UE Message. In this figure and throughout this specification, a box showing CN is used as a simplification of different components (such as MSC, SGSN, etc.) of the core network. Subsequent NAS messages between the UE 610 and core network 620 will be sent between the HNB 605/HNB-GW 615 and the CN 620 using the RANAP Direct Transfer message encapsulated in the RUA header.

The CN 620 authenticates (at step 6) the UE 610 using standard authentication procedures. This is an optional step and depends on the CN 620 deciding whether to perform or not perform the authentication procedures. The CN 620 also initiates the Security Mode Control procedure. The NAS messages are relayed transparently by the HNB-GW 615 and the HNB 605 between the UE 610 and the CN 620. The CN 620 indicates (at step 7) it has received the location update and it will accept the location update using the Location Update Accept message to the HNB-GW 615. The HNB-GW 615 relays (at step 8) the LU Accept NAS message to the HNB 605 via the use of RANAP Direct Transfer message encapsulated in the RUA header. The HNB 605 relays (at step 9) the LU Accept over the air interface to the UE 610 and the procedure is completed.

In some embodiments, the HNB has a location area that is distinct from its neighboring HNB and macro cells in order to trigger an initial message from a UE upon the UE camping on the HNB. The uniqueness of location is with respect to neighbors of a given HNB, which includes other surrounding HNBs and macro cells. It is neither required nor feasible to have a system-wide (i.e., across PLMN) unique location area for each HNB. Multiple HNBs are able to re-use the location area with the above consideration (i.e., non-conflicting with other neighbors). This unique location area is required to trigger an initial UE message and serves to perform access control and rejection of unauthorized UEs upon initial cell reselection and camping on the HNB; and, to track the current serving HNB for each authorized UEs, in order to minimize the impact of paging at the HNB-GW as well as the HNB (via UE registration).

Once the UE has successfully registered with the HNB-GW and performed a successful location update, the HNB may expect a periodic LU for that UE (the enabling and the periodicity of the LU is controlled by the HNB via System Information broadcast from the HNB to the UE). This exchange will serve as a keep-alive between the HNB and the UE and will help the HNB detect idle UEs moving away from the camped HNB without explicit disconnect from the network.

1. Abnormal Cases

When the unauthorized UE is not allowed to camp on the HNB, the HNB-GW responds to the UE registration with a HNBAP REGISTRATION REJECT message to the HNB. The HNB is then expected to reject the corresponding UE using appropriate reject mechanisms. For example, some rejection mechanisms include RRC rejection or redirection to another cell or reject the LU with cause such as "Location Area not allowed", etc.

When the unauthorized UE is allowed to camp in idle mode only, the HNB-GW responds to the UE registration with a HNBAP REGISTRATION ACCEPT message to the HNB and also includes a cause code indicating the limited camping of the UE (i.e., idle mode only). The HNB continues with the Location Update NAS message processing. At the completion of a successful location update procedure, if this unauthorized UE now attempts a subsequent L3 transaction (e.g., a mobile originated service request), the HNB will use the appropriate mechanisms (e.g., RRC redirection or relocation) to redirect the UE to another macro cell for the active call.

B. CSG UE Registration that Requires Modifications to the Core Network

A HNB can be deployed in multiple access modes. When the HNBs are deployed in closed access mode (meaning only a certain group of users are allowed access), a mechanism for access control is implemented via enforcement in the network (either the radio access network or the core network). As a result, the network must reject un-authorized UEs (i.e. UEs not subscribing to a particular HNB). The allowed CSG list stored on the UE or in the subscriber database record (such as in the HLR or HSS) is also known as the white-list.

The CSG capable HNB broadcasts a CSG-Id over the air interface. In some embodiments, the CSG-Id refers to a single cell, and in other embodiments, the CSG-Id may be shared by multiple CSG cells. Additionally, the HNB may also include an indication on whether the cell belongs to a closed subscriber group. The CN elements (MSC/VLR/SGSN) are assumed to be CSG capable i.e. they are able to access the allowed CSG list (i.e. white-list) of a particular UE (i.e. subscriber) and to enforce access control for each subscriber.

Subscribers can be equipped with either a legacy UE or a CSG capable UE. The legacy UE's decision to select a particular HNB may be based on macro NCL (e.g. if moving from macro coverage into HNB coverage area in idle mode) or based on full scan of all available cells for a particular operator PLMN (e.g. if there is no macro coverage in idle mode). CSG capable UEs do not need the macro NCL assistance and are capable of selecting the HNB autonomously based on the White-List or manual selection using the CSG-Id/ "HNB Display Identity" broadcast by the HNB. However, if macro NCL includes HNB neighbors, then a CSG capable UE may use that information for initial scanning of the HNB but the eventual decision to select the particular HNB is based on the white-list or manual selection decision.

Use of UE registration for CSG UEs over Iuh interface requires the HNB to perform UE registration before the HNB can communicate with the CN. The HNB can rely upon any initial L3 transaction (e.g. LAU or Paging Response) to trigger UE registration (similar to UE registration supported for legacy i.e. pre-CSG systems). For the CSG systems case, since the access control is performed in the CN, the HNB must also monitor for successful confirmation of the initial L3 transaction (e.g. LAU Accept). If the HNB detects failure in the L3 procedure, the HNB must trigger deregistration of the CSG UE. The UE registration procedure as defined for legacy systems requires the HNB to know the permanent identity (IMSI) of the UE and the IMSI is obtained via identity request procedure which is considered a breach of the current user confidentiality operation in macro networks.

Figure 7 provides a message flow diagram 700 illustrating a standardized CSG case for registering a UE 705 with a HNB-GW 715. Specifically, in this figure, the UE 705 is a CSG UE and the HNB 710 is operating in a mode that supports CSG features. Also, the CN 720 has been upgraded to support CSG features. For example, the HLR has been modified to maintain a list of CSG IDs that a UE is allowed to use. Accordingly, the access control is performed at the CN 720.

Furthermore, this figure illustrates that in the standardized CSG case, the user identity confidentiality model is maintained with the UE providing its TMSI or PTMSI in its initial layer 3 message. As shown, the HNB-GW 715 subsequently receives the permanent identity (i.e., IMSI) from the core network (CN) and associates the above said UE registration with the permanent identity of the UE.

As shown in Figure 7, UE 705 selects (at step 1) and camps on the HNB 710 using its white-list (or allowed CSG list) and CSG information broadcast by the HNB 710. The UE 705 then sends (at step 2) an initial NAS (L3) message towards the HNB 710 (e.g. LAU request or

Page response) containing only a temporary UE identity such as the TMSI (CS domain) or

PTMSI (PS domain). Here, the initial layer 3 message can be any layer 3 message.

The HNB 710 initiates (at step 3) a UE registration towards the HNB-GW 715 with this temporary UE identity without any further identity request sent to the UE 705 over the air interface. The HNB-GW 715 accepts (at step 4) the UE registration using the temporary identity and includes a unique context id in the UE registration accept message.

The initial NAS message is forwarded (at steps 5-9) towards the CN 720 followed by authentication and other normative procedures. In particular, after receiving the initial UE message from the HNB-GW 715, the CN 720 performs access control (at step 8) for the UE 705. For example, the CN 720 (in particular, the MSC or SGSN) would have obtained a list of CSGs that this particular UE 705 may use. The CN 720 would then enforce access control based on the obtained list. In addition, the CN 720 knows the relationship between the UE's temporary identity (e.g., TMSI or PTMSI) and permanent identity (i.e., IMSI) so the CN 720 can directly perform access control without receiving the UE's permanent identity from the HNB-GW 715.

The CN 720 then sends (at step 10) the RANAP Common Id message containing the

UE's permanent identity i.e. IMSI. The HNB-GW 715 then associates (at step 11) the existing

UE registration and context Id with the IMSI obtained in this manner.

It should be noted that if the RRC "cell update" (or equivalent) procedure is used instead of NAS level messaging for indication of HNB selection by the CSG UE, then IMSI cannot be obtained from the CN. This would then require that the HNB perform an identity request or require that the CSG UE include the IMSI in the RRC "cell update" (or equivalent) procedure.

As described above, the CN is able to access the allowed CSG list (i.e. white-list) of a particular UE (i.e. subscriber). By including target CSG-Id (i.e., the Allowed CSG list, white-list,

CSG identity, etc.) in the Page message from the CN, the HNB-GW can send the page to the correct HNB, and IMSI becomes a non-issue. However, this mechanism does require modification to existing RANAP Page messages from the CN. Additionally, the CN may be required to include the CSG-Id conditionally towards the HNB-GW and never towards a macro RNC.

IV. SUPPORTING CSG ACCESS CONTROL IN HNB AND/OR HNB-GW WITHOUT CORE NETWORK CHANGES

As mentioned above, in the CSG environment, the access control may be performed by the core network with the HLR maintaining a list of CSG IDs that a UE is allowed to use. This requires changes to an existing core network to support CSG features such as UE access control, CSG cell management, and user identity confidentiality. In some embodiments, the access control operations are performed by either or both the HNB and HNB-GW. Accordingly, in these embodiments, no changes to the core network (e.g., HLR, MSC, SGSN) are required to implement one or more of the CSG features.

Several example messages flow diagrams are described below. In these message flow diagrams, the access control operations are performed by the HNB and/or the HNB-GW.

A. UE Registration Message Flow

For some embodiments of the invention, Figure 8 provides a message flow diagram 800 illustrating the HNB 810 registering a UE 805 with the HNB-GW 815. In some embodiments, the registration is triggered when the UE 805 detects a change of Location Area upon re- selecting the HNB cell and sends an initial Non Access Stratum (NAS) message (e.g. Location Updating Request) to the HNB. Specifically, this figure illustrates (1) establishing a RRC connect between a UE 805 and the HNB 810, and (2) the HNB 810 requesting the UE 805 to provide the UE's permanent mobile subscriber identity (i.e., IMSI) when the UE provides the temporary mobile subscriber identity (e.g., TMSI or PTMSI) in the UE's initial message. This figure also illustrates that either or both the HNB 810 and HNB-GW 815 perform access control operations for the UE 805 attempting to utilize the HNB, in some embodiments. In this message flow diagram, the UE 805 is either a CSG UE or a non-CSG UE (e.g., a legacy UE).

As shown in Figure 8, the UE 805 establishes connectivity with the HNB 810 based on the following operations. The UE 805 initiates (at step la) a RRC connection with the HNB 810. In some embodiments, the HNB 810 broadcast a CSG identity (CSG ID). The HNB 810, in some embodiments, also broadcast a CSG Indicator. In some embodiments, the CSG indicator indicates whether the cell that the UE 805 is trying to access is a CSG cell. For example, the presence of the CSG indicator and value of "true" indicates that the cell is a CSG cell. If the HNB 810 operates in a "Closed" cell access mode, a CSG UE first confirms that the CSG ID broadcast by the HNB is included in the UE's whitelist. As mentioned above, the CSG whitelist contains one or more CSG IDs associated with the CSG cells on which the UE is allowed access. When the HNB 810 operates in "Hybrid" or "Open" cell access mode, any UE may camp on the HNB. A hybrid cell is accessed as a CSG cell by a UE whose CSG whitelist contains the cell's CSG ID and as a normal cell by all other UEs (e.g., legacy UEs). In some cases, the absence of the CSG indicator indicates that the cell is a hybrid cell.

The UE 805 then sends (at step lb) an initial message. In particular, the UE 805 establishes a RRC connection with the HNB 810 and sends the initial L3 message (i.e. LAU Request) to the HNB 810. In some embodiments, the UE 805 indicates the UE's CSG capability to the HNB 810 in the message. As shown, the initial L3 message includes a temporary identity (e.g., TMSI or PTMSI) or an IMSI associated with the UE 805.

Different from standardized CSG case, in Figure 8, location update procedure is triggered at step lb. In other words, when the UE 805 comes into the service region of the HNB 810, the location update procedure is forced upon the UE. In some embodiments, the HNB 810 has a location area that is distinct from its neighboring HNBs and macro cells in order to trigger an initial message from a UE upon the UE camping on the HNB. The uniqueness of location area of a given HNB with other surrounding HNBs and macro cells is required to trigger an initial UE message and serves to perform access control and rejection of unauthorized UEs upon initial cell reselection and camping on the HNB 810.

In the standardized CSG case, the triggered location update procedure is not required because the CN performs the access control. The UE can move in to the CSG Cell and stay silent. Only when the UE wants to set up a call or data session, the UE then sends a message to the network. The CN then decides whether the UE is able to perform the call or exchange data at the time the UE wants to perform these operations. Therefore, in the standardized case as illustrated in Figure 7, the initial message from the UE can be any layer 3 message.

If the UE 805 has not already provided (at step lb above) the IMSI, the HNB 810 performs an identity request to identify the UE's IMSI. As shown, the HNB 810 sends an identity request to the UE 805. In response to the request, the UE then sends (at step Id) the identity response that includes the UE's IMSI. As shown in Figure 8, the HNB 810, in some embodiments, performs (at step lc) access control operations. In some embodiments, the access control is performed by the HNB 810 after the HNB 810 has been provisioned with a list of allowed UEs. For example, the HNB 810 may perform the access control by (1) checking the IMSI of the UE 805 against the list of allowed UEs and then (2) deciding whether to allow the UE on the corresponding cell.

In some embodiments, the list of allowed UEs is based on the UE's CSG capability and CSG membership status. The list may also include Quality or Grade of Service parameters. For example, the allowed UE list on a CSG HNB would only include CSG capable UEs that are subscribed to the CSG that matches the HNB. Then, when the accessing CSG UE but not an authorized member of the CSG broadcast the HNB, the HNB can reject the UE RRC connection with an appropriate cause code (e.g., "CSG not allowed").

When the UE is a legacy UE, the HNB (in any access mode), in some embodiments, rejects the UE with a different cause code such as "Location Area Not Allowed". Returning to Figure 8, the HNB 810 sends (at step 2) a UE Registration Request to the HNB-GW 815. Here, the UE Registration Request includes the UE identity (e.g., the UE's IMSI) and the CSG ID.

In conjunction with or instead of the HNB 810, the HNB-GW 815, in some embodiments, performs access control operations. In some embodiments, the HNB-GW 815 performs the access control of the UE 805. To facilitate the access control operations, some embodiments use a HNB subscriber database 375 (as illustrated in Figure 3) using the UE's IMSI as well the HNB identity and CSG ID.

As illustrated in Figure 8, the access control is optionally performed at either the HNB 810 or the HNB-GW 815. However, at least one of these two entities must perform the access control to provide the CSG features and benefits without having to upgrade the CN 825.

When the HNB-GW 815 accepts the registration attempt, the HNB-GW 815 sends (at step 4) a UE registration accept messages (e.g., a HNBAP UE REGISTER ACCEPT message) to the HNB 810. In some embodiments, the register accept message includes a unique UE context identifier (Context ID) for that particular UE 805. As shown, the UE registration accept message also includes the UE identity.

The HNB 810 then performs a NAS relay of the Location Updating Request message from the UE to the HNB-GW via the use of RANAP Initial UE Message. The RANAP Initial UE message is encapsulated in the RUA CONNECT message with additional necessary information that enables the HNB-GW 815 to transparently relay RANAP message to the appropriate CN entity. Specifically, the HNB 810 sends (at step 5) the RUA Connect message to the HNB-GW 815. The RUA Connect message includes a Context ID, CN Domain, IDNNS, and CAUSE. The RUA Connect message also encapsulates the RANAP Initial UE message.

The HNB-GW 815 then establishes (at step 6) a SCCP connection to the CN 825 and forwards the Location Update request (or the combined RA LA update request) NAS PDU to the CN 825 using the RANAP Initial UE message. Subsequently, the NAS messages between the UE 805 and the core network will be sent between HNB/HNB-GW and CN 825 using the RANAP Direct Transfer message that is encapsulated in the RUA DIRECT TRANSFER message.

As shown in Figure 8, the HNB-GW 815, in some embodiments, filters out several IEs related to CSG when sending the RANAP Initial UE message to the CN 825. Specifically, the HNB-GW 815 filters out the CSG ID IE and the Cell Access Mode IE. For example, when the UE Registration Request from the HNB 810 includes the CSG ID IE and the Cell Access Mode IE, the HNB-GW 815 generates the RANAP Initial UE message by excluding or filtering out these IEs. By performing the filtering operation, the HNB-GW 815 excludes any CSG related modifications to RANAP messages on the Iu-cs and Iu-ps interface. In essence, the HNB-GW 815 eliminates any changes brought about by the use of CSG. Therefore, from the point of view of the CN 825, the messages from the HNB-GW are the same as those for a non-CSG UE and non-CSG HNB.

Alternatively, or conjunctively with the filtering performed by HNB-GW 815, the HNB 810 may perform its own filtering operation or exclude CSG related IEs when generating and sending a message (e.g., UE Registration Request) to the HNB-GW 815.

The CN 825 authenticates (at step 7) the UE 805 using standard authentication procedures. The CN 825 also initiates (at step 7) the Security Mode Control procedure. The NAS messages are relayed transparently by the HNB-GW 815 and HNB 810 between the UE 805 and the CN 825.

The CN 825 then indicates (at step 8) that it has received the location update and it will accept the location update by sending the Location Update Accept message to the HNB-GW 815. The HNB-GW 815 relays (at step 9) LU Accept NAS message to the HNB 810 via the use of RANAP Direct Transfer message encapsulated in the RUA DIRECT TRANSFER message. As shown, the RUA Direct Transfer message includes a Context and CN Domain. The RUA Direct Transfer message also encapsulates the RANAP message). The HNB 810 relays (at step 10) the LU Accept over the air interface to the UE 805.

As mentioned above, one of the features of the CSG environment is that a UE preferentially switches over to a CSG cell or HNB when it detects a CSG ID that is in the UE's white list. In other words, instead of camping on a Node B's macro cell, the UE preferentially switches over to a HNB cell that the UE is allowed to use when the UE detects the HNB cell. In the example illustrated in Figure 8, this is achieved without changes to the core network. Specifically, this is achieved by (1) performing the access control at the HNB and/or HNB-GW, (2) deviating from the user identity confidentiality model, (3) requiring the LAI broadcast by the HNB to be distinct from the LAIs broadcast by all other HNBs and macrocells in its neighborhood, and (4) excluding any CSG related modifications to RANAP messages on the lues and Iu-ps interface. For example, the HNB 810 sends (at step lb) an identity request message to the UE when the HNB receives a temporary identity (e.g., TMSI or PTMSI) in the UE's initial message. As such, in the example described above, several features of the CSG environment are implemented by deviating from the user identity confidentiality model.

In the message flow diagram illustrated in Figure 6, there are no special techniques that cause a UE that is camped on a licensed wireless macro cell to preferentially switch over to a HNB cell. This is different from Figure 8. Specifically, in Figure 8, when the UE comes into a vicinity of the HNB, the CSG UE will detect the CSG ID of the HNB and autonomously switch to the HNB when the CSG ID is in the UE's whitelist. As such, Figure 8 shows CSG behavior without having to upgrade the CN.

B. Alternative UE Registration Message Flow

For some embodiments of the invention, Figure 9 provides a message flow diagram 900 illustrating the HNB 910 registering a CSG UE 905 with the HNB-GW 915. In some embodiments, the registration is triggered when the UE 905 attempts to access the HNB 910 for the first time via an initial NAS message (e.g. Location Updating Request). Specifically, this figure illustrates that (1) the UE 905 may only provide its temporary identity (e.g., TMSI or PTMSI) but not the permanent identity (i.e., IMSI) during registration, (2) the HNB-GW 915 retrieves the permanent identity from the source VLR, and (3) the HNB-GW performs access control operations. Different from the previous example, in Figure 9, the user identity confidentiality is maintained with the UE 905 providing its temporary identity and the HNB-GW 915 retrieving the permanent identity from the source VLR 930. Accordingly, the HNB-GW 915 resolves the TMSI by querying the source VLR 930. Also, in the example illustrated in Figure 9, the UE 905 is a CSG UE and not a legacy or non-CSG UE.

As shown in Figure 9, the CSG UE 905 camps on the HNB 910 upon confirming that the CSG identity (CSG ID) broadcast by the HNB 910 is included in the UE's whitelist (i.e. allowed CSG List stored on the UE). The UE 905 then establishes (at step la) a RRC connection. At step lb, the UE then sends an initial message to the HNB 910. Here, the initial message is an initial L3 message (i.e. LU Request) that indicates the UE's CSG capability. The initial message also includes the temporary identity (e.g., TMSI or PTMSI) of the UE 905. Similar to the message flow diagram of Figure 8, the location update procedure is triggered upon the CSG UE 905 entering the service region of the HNB 910.

Based on the indicated CSG capability, the HNB 910 skips the UE identification procedure and proceeds to register (at step 2) the CSG UE 905 with the HNB-GW 915 using the temporary identity (e.g., TMSI or PTMSI) of the UE. In some embodiments, the register request message from the HNB 910 to HNB-GW 915 includes a parameter that indicates the CSG capability of the UE 905.

The HNB-GW 915 recognizes (at step 3) that the registering UE 905 is CSG capable (using the CSG capability information from the UE) and triggers a permanent identity retrieval from the source visitor location register (VLR) 930. In some embodiments, the UE's IMSI is retrieved using the MAP SEND IDENTIFICATION message. The source VLR 930 is the VLR that the UE 905 was obtaining services prior to camping on the HNB 905 and is identified to the HNB-GW by the IE carrying the value of the previous LAI in the Location Area Update message.

The VLR is an existing function supported by the CN 925 (e.g., a function within the MSC) prior to introduction of CSG standards. Accordingly, the CN in Figure 9 does not require an upgrade to support CSG features. This is different from Figure 7 where new functions are introduced into the CN to support CSG features.

The HNB-GW 915 then performs (at step 4) access control of the CSG UE 905. To facilitate the access control operations, the HNB-GW 915, in some embodiments, access a HNB subscriber database using the UE's IMSI (retrieved from the source VLR 930) as well the HNB identity and CSG ID, as illustrated in Figure 3. As mentioned above, some embodiments use a data store (e.g., database) that matches CSG UEs with CSGs that the CSG UEs are authorized to access.

When the HNB-GW 915 accepts the registration attempt, the HNB-GW responds (at step

5) with a register accept message (e.g., a HNBAP UE REGISTER ACCEPT message) back to the HNB 910. In some embodiments, the register accept message includes a unique UE context identifier (UE Context ID) for that particular UE 905.

The HNB 910 then performs a NAS relay of the Location Updating Request message from the UE to the HNB-GW via the use of RANAP Initial UE Message. The RANAP Initial UE message is encapsulated in the RUA CONNECT message with additional necessary information that enables the HNB-GW 915 to transparently relay RANAP message to the appropriate CN entity. Specifically, the HNB 910 sends (at step 6) the RUA Connect message to the HNB-GW 915. The RUA Connect message includes a Context ID, CN Domain, IDNNS, and CAUSE. The RUA Connect message also encapsulates the RANAP Initial UE message.

The HNB-GW 915 then establishes (at step 7) a SCCP connection to the CN 925 and forwards the Location Update request (or the combined RA LA update request) NAS PDU to the CN 925 using the RANAP Initial UE message. Subsequently, the NAS messages between the UE 905 and the core network will be sent between HNB/HNB-GW and CN 925 using the RANAP Direct Transfer message that is encapsulated in the RUA DIRECT TRANSFER message.

As shown in Figure 9, from the point of view of the CN 925, the messages from the HNB-GW are the same as those for a non-CSG UE and non-CSG HNB. The CN 925 authenticates (at step 8) the UE 905 using standard authentication procedures. The CN 925 also initiates (at step 8) the Security Mode Control procedure. The NAS messages are relayed transparently by the HNB-GW 915 and HNB 910 between the UE 905 and the CN 925.

The CN 925 then indicates (at step 9) that it has received the location update and it will accept the location update by sending the Location Update Accept message to the HNB-GW 915. The HNB-GW 915 relays (at step 10) LU Accept NAS message to the HNB 910 via the use of RANAP Direct Transfer message encapsulated in the RUA DIRECT TRANSFER message. As shown, the RUA Direct Transfer message includes a Context and CN Domain. The RUA Direct Transfer message also encapsulates the RANAP message). The HNB 910 relays (at step 10) the LU Accept over the air interface to the UE 905.

V. COMPUTER SYSTEM

Many of the above-described protocol stacks, processes, methods, and functionalities are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more computational or processing element(s) (such as processors or other computational elements like ASICs and FPGAs), they cause the computational element(s) to perform the actions indicated in the instructions. Computer is meant in its broadest sense, and can include any electronic device with computational elements (e.g., HNB and HNB-GW). Examples of computer readable media include, but are not limited to, CD- ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

In this specification, the term "software" includes firmware residing in read-only memory or applications stored in magnetic storage which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as subparts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some embodiments, the software programs when installed to operate on one or more computer systems define one or more specific machine implementations that execute and perform the operations of the software programs.

Figure 10 conceptually illustrates a computer system with which some embodiments of the invention are implemented. The computer system 1000 includes a bus 1005, a processor 1010, a system memory 1015, a read-only memory 1020, a permanent storage device 1025, input devices 1030, and output devices 1035.

The bus 1005 collectively represents all system, peripheral, and chipset buses that support communication among internal devices of the computer system 1000. For instance, the bus 1005 communicatively connects the processor 1010 with the read-only memory 1020, the system memory 1015, and the permanent storage device 1025. From these various memory units, the processor 1010 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) 1020 stores static data and instructions that are needed by the processor 1010 and other modules of the computer system. The permanent storage device 1025, 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 1000 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 1025. Some embodiments use one or more removable storage devices (flash memory card or memory stick) as the permanent storage device.

Like the permanent storage device 1025, the system memory 1015 is a read-and-write memory device. However, unlike storage device 1025, 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.

Instructions and/or data needed to perform processes of some embodiments are stored in the system memory 1015, the permanent storage device 1025, the read-only memory 1020, 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 1010 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.

The bus 1005 also connects to the input and output devices 1030 and 1035. The input devices enable the user to communicate information and select commands to the computer system. The input devices 1030 include alphanumeric keyboards and cursor-controllers. The output devices 1035 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 Figure 10, bus 1005 also couples computer 1000 to a network 1065 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). Any or all of the components of computer system 1000 may be used in conjunction with the invention. For instance, some or all components of the computer system described with regards to Figure 10 comprise some embodiments of the UE, HNB, HNB-GW, and SGSN described above. However, 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.

Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD- ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable blu-ray discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processor and includes sets of instructions for performing various operations. Examples of hardware devices configured to store and execute sets of instructions include, but are not limited to application specific integrated circuits (ASICs), field programmable gate arrays (FPGA), 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.

As used in this specification and any claims of this application, the terms "computer", "server", "processor", and "memory" all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms "computer readable medium" and "computer readable media" are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals. Many of the above figures illustrate a single access point (e.g., HNB 305) communicatively coupled to a network controller (e.g., HNB-GW 315). However, it should be apparent to one of ordinary skill in the art that the network controller (e.g., HNB-GW 315) of some embodiments is communicatively coupled to several HNBs and the network controller communicatively couples all such HNBs to the core network. The figures merely illustrate a single HNB communicatively coupled to the HNB-GW for purposes of simplifying the discussion to interactions between a single access point and a single network controller. However, the same network controller of some embodiments may have several of the same interactions with several different access points.

Additionally, many of the above figures illustrate the access point to be a HNB and the network controller to be a HNB-GW. These terms are used to provide a specific implementation for the various procedures, messages, and protocols described within some of the embodiments described with reference to the figures. However, it should be apparent to one of ordinary skill in the art that the procedures, messages, and protocols may be used with other communication systems and the HNB system was provided for exemplary purposes. For example, such procedures, messages, and protocols may be adapted to function with a Femtocell cell system that includes Femtocell access points and a Femtocell network controller (e.g., Generic Access Network Controller).

Similarly, many of the messages and protocol stacks were described with reference to particular HNB-AN functionality such as control plane functionality or user plane functionality. However, it should be apparent to one of ordinary skill in the art that such functionality may apply across multiple HNB-AN functions or may apply to a different HNB-AN function altogether. Moreover, it should be apparent to one of ordinary skill in the art that the above described messaging may include additional or alternative information elements to those enumerated above.

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. 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. VI. ABBREVIATIONS AND DEFINITIONS

A. Abbreviations

Second Generation of Cellular Wireless Standards 2G

Third Generation of Cellular Wireless Standards 3G

3^rd Generation Partnership Project 3 GPP

Fourth Generation of Cellular Wireless Standards 4G

Authorization, Authentication, and Accounting AAA

Access Network AN

Automatic Number Identification ANI

Advice of Charge AoC

Access Point AP

Asynchronous Transfer Mode ATM

Base Station BS

Base Transceiver Station BTS

Cell Broadcast Center CBC

Call Control CC

Cable Modem Termination System CMTS

Core Network CN

Customer Premise Equipment CPE

Circuit Switched CS

Closed Subscriber Group CSG

Digital Subscriber Line DSL

DSL Access Multiplexer DSLAM

ES Protocol ESP

Encapsulating Security Payload ESP

GSM/EDGE Radio Access Network GERAN

Gateway GPRS Support Node GGSN

General Packet Radio Service GPRS

Global System for Mobile communications GSM

Home Evolved Node B HeNB

Home Location Register HLR Home Node-B HNB

HNB Access Network HNB-AN

HNB Application Part HNBAP

HNB Gateway HNB-GW

Information Element IE

Internet Assigned Numbers Authority IANA

Identifier ID

International Mobile Subscriber Identity IMSI

Internet Protocol IP

IP Security IPSec

Internet Service Provider ISP

Interworking Functionality IWF

Layer 3 L3

Location Area LA

Location Area Code LAC

Location Area Identifier LAI

Location Area Update LAU

Location Update LU

MTP3 User Adaptation Layer M3UA

Media Access Control MAC

Mobility Management MM

Most Significant Bit MSB

Mobile Switching Center MSC

Non Access Stratum NAS

Network Address Translation NAT

Neighbor Configuration List NCL

Personal Communication Services PCS

Packet Control Unit PCU

Protocol Data Unit PDU

Public Land Mobile Network PLMN

Payload Protocol Identifier PPI Packet Switched PS

Public Switched Telephone Network PSTN

Packet-Temporary Mobile Subscriber Identity P-TMSI (or PTMSI)

Either Packet TMSI or TMSI (P)TMSI

Permanent Virtual Circuit PVC

Quality of Service QoS

Routing Area RA

Radio Access Bearer RAB

RANAP Adaptation Layer RAL

Radio Access Network Application Part RANAP

Radio Frequency RF

Radio Link Control RLC

Radio Network Controller RNC

Iu U-Plane RNL

Radio Resource Control RRC

Radio Resource Management RRM

RANAP Transport Adaptation RTA

Real-Time Protocol RTP

RANAP User Adaptation RUA

Service Area Identifier SAI

System Architecture 1 SA1

Signalling Connection Control Part SCCP

Stream Control Transmission Protocol SCTP

Security Gateway SeGW

Serving GPRS Support Node SGSN

Subscriber Identity Module SIM

Serving Mobile Location Center SMLC

Short Message Services SMS

Signaling System 7 SS7

Transmission Control Protocol TCP

Temporary Mobile Subscriber Identity TMSI Traffic Selector TS

User Equipment UE

Unlicensed Mobile Access UMA

Universal Mobile Telecommunications System UMTS

Universal Subscriber Identity Module USIM

Either SIM or USIM (U)SIM

UMTS Terrestrial Radio Access Network UTRAN

Visitor Location Register VLR

Wireless Local Area Network WLAN

Wireless Service Provider WSP

World Zone 1 WZ1

B. Definitions

Allowed CSG List: A list of CSG cells, each of which is identified by a CSG identity, allowed for a particular subscriber.

Access Control: It is the mechanism of ensuring that access to particular HNB is based on the subscription policy of the subscriber as well as that of the HNB.

Closed Subscriber Group (CSG): A list of subscribers which have access to mobile network using a particular HNB (a.k.a HeNB or Femtocell).

CSG Cell: A cell (e.g. HNB) which allows mobile network access to CSG only. A CSG cell may broadcast a specific CSG identifier over the air interface.

CSG Identity: The identity of the CSG cell. A CSG identity may be shared by multiple CSG cells.

CSG UE: A UE which has support for CSG white-list and can autonomously detect and select CSG cells.

E.164: A public networking addressing standard

Femtocell Access Network: The Femtocell access network constitutes of the HNB and the HNB-GW (same as HNB access network)

Legacy UE: A UE which does not have support for CSG white-list (e.g. R99 or pre-release 8 UE).

Operator: Licensed wireless service provider White-List: It is the allowed CSG list stored on the UE or in the subscriber database record (such as in the HLR or HSS).

Claims

CLAIMS What claimed is:

1. A method of registering a closed subscriber group (CSG) user equipment (UE) with a home node B (HNB) gateway (HNB-GW), the method comprising:

receiving, at the HNB-GW, a request to register the CSG UE, the request comprising a unique identity of the CSG UE and a CSG identity that identifies a HNB;

performing, at the HNB-GW, access control for the CSG UE by determining whether the unique identity of the CSG UE and the CSG identity are associated with one another; and

sending a registration accept message from the HNB-GW to the HNB when the determination is made that the CSG UE is authorized to access the HNB.

2. The method of claim 1 , wherein the unique identity of the CSG UE is an international mobile subscriber identity (IMSI).

3. The method of claim 1 further comprising:

modifying, at the HNB-GW, a Radio Access Network Application Part (RANAP) message by filtering out each information element (IE) related to CSG operation such that a core network (CN) is unaware of CSG capabilities of the CSG UE and the HNB; and

sending the modified RANAP message from the HNB-GW to the CN.

4. The method of claim 3, wherein the HNB-GW filters out a CSG identity IE and a cell access mode IE from the RANAP message.

5. The method of claim 3, wherein the CN has not been upgraded to support CSG operations.

6. The method of claim 1 further comprising receiving, at the HNB-GW, a connect message from the HNB, the connect message embedding a RANAP message that includes a location update request.

7. The method of claim 1, wherein the HNB sends RANAP messages from the HNB to the CN via the HNB-GW by excluding one or more IEs related to CSG operation such that the CN servicing the CSG UE is unaware of CSG capabilities of the CSG UE and the HNB.

8. A computer readable medium of a home node B (HNB) storing a computer program for registering a closed subscriber group (CSG) user equipment (UE) with a HNB gateway (HNB-GW), the computer program comprising sets of instructions for: receiving, at the HNB, a location update message from the CSG UE when the CSG UE, said location update message comprising either international mobile subscriber identity (IMSI) or a temporary mobile subscriber identity of the UE;

requesting the UE to provide the IMSI when the location update message comprises the temporary mobile subscriber identity;

performing, at the HNB, access control for the CSG UE by determining whether the CSG UE is authorized to access the HNB based on the CSG UE's IMSI and a list of one or more IMSIs that identities each UE that is authorized to access the HNB; and

sending a registration request message from the HNB to the HNB-GW when the determination is made that the CSG UE is authorized to access the HNB.

9. The computer readable medium of claim 8, wherein the temporary mobile subscriber identity is a temporary mobile subscriber identity (TMSI) for circuit switched (CS) communication.

10. The computer readable medium of claim 8, wherein the temporary mobile subscriber identity is a Packet-Temporary Mobile Subscriber Identity (PTMSI) for packet switched (PS) communication.

11. The computer readable medium of claim 8, wherein the computer program further comprises a set of instructions for broadcasting, at the HNB, a CSG identity,

wherein the location update is triggered when the CSG UE (i) detects the CSG identify being broadcast by the HNB, (ii) determines that the CSG identity is in a list of one or more CSG identities stored on the CSG UE, (iii) camps on the HNB, and (iv) identifies that a location area indenter (LAI) of the HNB is different from a LAI of another HNB or Node-B on which the CSG UE was previously camped.

12. The computer readable medium of claim 8, wherein the computer program further comprises a set of instructions for receiving, at the HNB, a registration accept message from the

HNB-GW.

13. The computer readable medium of claim 8, wherein the computer program further comprises a set of instructions for sending a RANAP message from the HNB to a core network (CN) via the HNB-GW by excluding one or more IEs related to CSG operation such that the CN servicing the CSG UE is unaware of CSG capabilities of the CSG UE and the HNB.

14. The computer readable medium of claim 13, wherein the IEs that are excluded from the RANAP message comprise a CSG identity IE and a cell access mode IE.

15. A method of registering a closed subscriber group (CSG) user equipment (UE) with a home node B gateway (HNB-GW), the method comprising:

receiving, at the HNB-GW, a request to register the CSG UE, said request to register comprising a temporary mobile subscriber identity of the UE;

sending a map send identification message from the HNB-GW to a source visitor location register (VLR) to retrieve the UE's international mobile subscriber identity (IMSI); and performing, at the HNB-GW, access control for the CSG UE by determining whether the CSG UE's IMSI and the CSG identity are associated with one another; and

16. The method of claim 15, wherein the temporary mobile subscriber identity is a temporary mobile subscriber identity (TMSI) for circuit switched (CS) communication.

17. The method of claim 15, wherein the temporary mobile subscriber identity is a

Packet-Temporary Mobile Subscriber Identity (PTMSI) for packet switched (PS) communication.

18. The method of claim 15 further comprising:

sending the modified RANAP message from the HNB-GW to the CN.

19. The method of claim 18, wherein the HNB-GW filters out a CSG identity IE and a cell access mode IE from the RANAP message.

20. The method of claim 15 further comprising receiving, at the HNB-GW, a connect message from the HNB, the connect message embedding a RANAP message that includes a location update request.

21. The method of claim 15, wherein the HNB sends RANAP messages from the HNB to the CN via the HNB-GW by excluding one or more IEs related to CSG operation such that the CN servicing the CSG UE is unaware of CSG capabilities of the CSG UE and the HNB.