WO2011022613A1

WO2011022613A1 - High availability design for iuh

Info

Publication number: WO2011022613A1
Application number: PCT/US2010/046112
Authority: WO
Inventors: Amit Khetawat; Patrick Tao; Satish Agrawal
Original assignee: Kineto Wireless, Inc.
Priority date: 2009-08-20
Filing date: 2010-08-20
Publication date: 2011-02-24

Abstract

A method of providing high availability for an Iuh based communication system is described. The communication system includes a first communication system with a core network and a licensed radio access network and a wireless second communication system with a short range access point and a network controller that communicatively couples the access point to the core network to establish a set of user plane sessions. When a set of ongoing user plane sessions exists, the method determines that there is a loss of signaling connectivity between the access point and the network controller. The method maintains resources assigned to the access point for the set of ongoing sessions after the loss of the signaling connectivity and reestablishes the signaling connectivity between the access point and the network controller. The method restores one or more of the ongoing sessions over the reestablished connectivity using the maintained resources.

Description

HIGH AVAILABILITY DESIGN FOR IUH

BACKGROUND

[0001] 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.

[0002] 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.

[0003] 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.

[0004] 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.

[0005] Home Node Bs (HNBs) emerged as one solution to lower costs associated with the licensed wireless systems while maintaining user wireless mobility. HNB 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 base station comprising a wireless access point (AP) with a physical connection (e.g., coaxial, twisted pair, or optical cable) to a landline-based network. The AP has an RF transceiver to facilitate communication with a wireless handset that is operative within a modest distance of the AP.

[0006] HNB communication systems allow users to purchase ordinary off-the-shelf access points in order to deploy a HNB service region that allows for access to HNB service. In this manner, HNB is able to provide higher quality services at a lower cost than the licensed wireless macro cell.

[0007] 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.

BRIEF SUMMARY

[0008] Some embodiments include a method of providing high availability for an Iuh based communication system. The communication system includes (i) a first communication system that includes a core network and a licensed radio access network and (ii) a wireless second communication system that includes a short range access point for establishing service regions of the second network using short range licensed wireless frequencies and a network controller that communicatively couples the access point to the core network to establish a set of user plane sessions for circuit switched and packet switched sessions. A set of ongoing user plane sessions exist between the access point and the network controller. The method determines that there is a loss of signaling connectivity between the access point and the network controller. The method maintains resources assigned to the access point for the set of ongoing sessions after the loss of the signaling connectivity. The method reestablishes the signaling connectivity between the access point and the network controller. The method restores one or more of the ongoing user plane sessions over the reestablished connectivity using said maintained resources.

[0009] Some embodiments provide a computer readable medium that stores a program for execution by a processing unit. The program is for providing high availability for an Iuh based communication system. The communication system includes (i) a first communication system that includes a core network and a licensed radio access network and (ii) a wireless second communication system that includes a short range access point for establishing service regions of the second network using short range licensed wireless frequencies and a network controller for communicatively coupling the access point to the core network to establish a set of user plane sessions for circuit switched and packet switched sessions. The program includes several sets of instructions. The program includes a set of instructions for determining that there is a loss of signaling connectivity between the access point and the network controller. The program includes a set of instructions for maintaining resources assigned to the access point for a set of ongoing user plane sessions after the loss of signaling connectivity. The program includes a set of instructions for reestablishing the signaling connectivity between the access point and the network controller. The program includes a set of instructions for determining whether one or more ongoing sessions between the access point and the network controller are interrupted after the loss of connectivity. The program includes a set of instructions for sending a set of commands to reset one or more maintained resources when one or more ongoing sessions are interrupted. [0010] 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

[0011] 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.

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

[0013] Figure 2 illustrates elements of the HNB Access Network (HNB-AN) subsystem architecture in accordance with some embodiments.

[0014] 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.

[0015] Figure 4 illustrates the protocol architecture supporting the HNB Application

Part (HNBAP) over the Iuh interface, in some embodiments.

[0016] 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.

[0017] Figure 6 illustrates the protocol architecture in support of the CS domain user plane over the Iuh interface in some embodiments.

[0018] Figure 7 illustrates the PS Domain User Plane Protocol Architecture in some embodiments.

[0019] Figure 8 illustrates a typical behavior in the HNB system resulting from loss of Iuh interface connectivity.

[0020] Figure 9 conceptually illustrates a process for performing re -initialization in some embodiments.

[0021] Figure 10 illustrates re-initialization by the HNB in some embodiments.

[0022] Figure 11 illustrates re-initialization by HNB-GW in some embodiments.

[0023] Figure 12 illustrates partial re-initialization by the HNB in some embodiments.

[0024] Figure 13 illustrates partial re-initialization by the HNB-GW in some embodiments. [0025] Figure 14 conceptually illustrates a process for performing recovery of ongoing user plane sessions after loss of control signalling plane connectivity in some embodiments.

[0026] Figure 15 illustrates ongoing session recovery upon failure in some embodiments.

[0027] Figure 16 conceptually illustrates a computer system with which some embodiments are implemented.

DETAILED DESCRIPTION

[0028] 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.

[0029] 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.

[0030] Some embodiments include a method of providing high availability for an Iuh based communication system. The communication system includes (i) a first communication system that includes a core network and a licensed radio access network and (ii) a wireless second communication system that includes a short range access point for establishing service regions of the second network using short range licensed wireless frequencies and a network controller that communicatively couples the access point to the core network to establish a set of user plane sessions for circuit switched and packet switched sessions. A set of ongoing user plane sessions exist between the access point and the network controller. The method determines that there is a loss of signaling connectivity between the access point and the network controller. The method maintains resources assigned to the access point for the set of ongoing sessions after the loss of the signaling connectivity. The method reestablishes the signaling connectivity between the access point and the network controller. The method restores one or more of the ongoing user plane sessions over the reestablished connectivity using said maintained resources.

[0031] In some embodiments, the method starts a timer after determining that signaling connectivity is lost. In these embodiments, maintaining resources assigned to the access point includes maintaining the resources until the timer has expired. In some embodiments, maintaining the resources includes determining that one or more of the ongoing sessions between the access point and the network controller are uninterrupted after the loss of connectivity. Reestablishing the signaling connectivity in some embodiments includes sending a register request message from the access point to the network controller and receiving a register accept message at the access point from the network controller. [0032] Some embodiments provide a computer readable medium that stores a program for execution by a processing unit. The program is for providing high availability for an Iuh based communication system. The communication system includes (i) a first communication system that includes a core network and a licensed radio access network and (ii) a wireless second communication system that includes a short range access point for establishing service regions of the second network using short range licensed wireless frequencies and a network controller for communicatively coupling the access point to the core network to establish a set of user plane sessions for circuit switched and packet switched sessions. The program includes several sets of instructions. The program includes a set of instructions for determining that there is a loss of signaling connectivity between the access point and the network controller. The program includes a set of instructions for maintaining resources assigned to the access point for a set of ongoing user plane sessions after the loss of signaling connectivity. The program includes a set of instructions for reestablishing the signaling connectivity between the access point and the network controller. The program includes a set of instructions for determining whether one or more ongoing sessions between the access point and the network controller are interrupted after the loss of connectivity. The program includes a set of instructions for sending a set of commands to reset one or more maintained resources when one or more ongoing sessions are interrupted.

[0033] The set of commands to reset one or more maintained resources in some embodiments includes one reset command to reset all maintained resources for the circuit switched sessions and one reset command to reset all maintained resources for the packet switched sessions. In some embodiments, the ongoing user plane sessions are for a set of user equipments that have a set of circuit switched sessions and a set of packet switched sessions. In these embodiments, the set of commands to reset one or more maintained resources includes one reset resource command per user equipment per each circuit switched session and one reset resource command per user equipment per each packet switched session to selectively reset maintained resources for the one or more interrupted sessions while maintaining resources for a set of uninterrupted ongoing sessions. The set of instructions for reestablishing the signalling connectivity in some embodiments includes sets of instructions for sending a register request message from the access point to the network controller and receiving a register accept message at the access point from the network controller. In some embodiments, the program further includes a set of instructions for starting a timer after determining that the signalling connectivity is lost. In these embodiments, the set of instructions for maintaining resources assigned to the access point includes a set of instructions for maintaining the resources until the timer has expired. The loss of signalling connectivity in some embodiments is a loss of Stream Control Transmission Protocol (SCTP) connectivity.

[0034] Several more detailed embodiments of the invention are described in sections below. Specifically, Section I discusses the HNB system architecture. Section II describes various protocol architectures of the HNB system, including protocol architectures for the Home Node-B Application Part (HNBAP) and the Radio Access Network Application Part (RANAP) User Adaption (RUA) layer. Section III describes connections between HNB and HNB-GW. Next, Section IV discusses different embodiments for providing high availability Iuh interface. Section V provides a description of a computer system with which some embodiments of the invention are implemented. Lastly, Section VI lists the abbreviations for terms found herein.

I. HNB SYSTEM ARCHITECTURE

[0035] 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.

[0036] In some embodiments of the invention, the standardized interfaces include (a) the Iu-cs interface for circuit switched services as overviewed in the 3GPP 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.

[0037] To address specific 3G HNB applications, some embodiments utilize existing

Iu and Uu interfaces within the HNB-AN 110. 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 3 G HNBs using public infrastructure such as the Internet.

[0038] Figure 2 illustrates elements of the HNB Access Network (HNB-AN) 200 architecture in accordance with some embodiments. This figure includes (3G) HNB 205, Generic Internet Protocol (IP) Access Network 210, 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 3GPP TR- 069 family of standards. In some other embodiments, the interface 230 is the Iuhm interface. These elements are described in further detail below with reference to Figure 3.

[0039] 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.

[0040] 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. The HNB system includes (1) Home Node-B (HNB) 305, (2) Home Node-B Gateway (HNB-GW) 315, (3) Broadband IP Network 320, (4) Security Gateway (SeGW) 325, and (6) HNB Management System 330. The licensed wireless radio access network of the second communication system includes UTRAN 385 which is comprised of a Node-B 380 and a Radio Network Controller 375 of a UMTS. 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) 340 and Cell Broadcast Center (CBC) 345 may be components of the core network.

A. User Equipment (UE)

[0041] In some embodiments of the invention, UE 310 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 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 310 is thus a standard device operating over licensed spectrum of a licensed wireless system provider. Accordingly, the UE 310 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).

[0042] 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

[0043] In some embodiments, the UE 310 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.

2. Terminal Adaptors

[0044] In some embodiments, the UE 310 includes a terminal adaptor device that allows incorporating fixed-terminal devices such as telephones, faxes, and other equipments that are not wirelessly enabled within the HNB-AN. 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 a UE is connected to the subscriber's existing broadband (e.g., Internet) service. 3. SoftMobiles

[0045] 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 of some embodiments includes SoftMobile like devices.

[0046] To use a SoftMobile service, a subscriber would place a USB memory stick with an embedded SIM into a USB port of their laptop. A SoftMobile client would automatically launch and connect over IP to the mobile service provider. From that point on, the subscriber would be able to make and receive mobile calls as if she was in her home calling area.

B. HNB

[0047] 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.

[0048] 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. [0049] 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 need not offer uninterrupted service between HNB service regions.

[0050] 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 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.

[0051] 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.

[0052] 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).

[0053] 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.

[0054] 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 new users can be added. 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.

[0055] 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 3 G 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. 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.

[0056] 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 14 below.

[0057] 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. Broadband IP Network

[0058] The HNB 305 provides radio access network connectivity for the UE 310. The

HNB 305 then communicatively couples the UE to the HNB-GW 315 using the Iuh interface that exists between the HNB 305 and the HNB-GW 315. As shown in Figure 3, the Iuh interface is established over a broadband Internet Protocol (IP) network 320 where, in some embodiments, a customer's broadband connection is utilized. The broadband IP 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 without any Asynchronous Transfer Mode (ATM) or Signaling System 7 (SS7) infrastructure.

[0059] In some embodiments, the broadband IP network 320 includes (1) other

Customer premise equipment (e.g., Digital Subscriber Line (DSL)/cable modem, Wireless Local Area Network (WLAN) switch, residential gateways/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

[0060] 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., Iu-cs 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.

[0061] As noted above, the HNB-GW 315 connects to the HNB 305 using the Iuh 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 355, and an interface that is based on the 3GPP TR-069 family of standards, as specified by the DSL Forum technical specifications, to the HNB management system 330. In some embodiments, the interface to the HNB management system 330 is the Iuhm interface. In some such embodiments, the Iuhm interface carries information related to customer premise equipment (CPE) device management functionality between the HNB and HNB Mgmt System. 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.

[0062] 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 Iuh interface management.

[0063] 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, 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 an standalone entity and is not an entity within the HNB-GW.

[0064] The HNB Management System 330 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.

[0065] The network controller of some embodiments includes 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 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 14 below.

E. Core Network (CN) and Other Network Elements

[0066] 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 355 for subscriber authentication and authorization. Once authorized, the UE may access the voice and data services of the CN 335 through the HNB system. To provide such services, 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.

[0067] 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.

[0068] 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.

[0069] 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 (one per each cell) that covers a wide service area. A licensed wireless cell is sometimes referred to as a macro cell which is a logical term used to reference, e.g., the UMTS radio cell (i.e., 3G cell) under Node-B/RNC which is used to provide coverage typically in the range of tens of kilometers. Also, the UTRAN or GERAN is sometimes referred to as a macro network.

[0070] 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

[0071] 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 IV, "Computer System". [0072] 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 User Adaptation (RUA) protocol architecture implements the control functions for the HNB system. As will be described below, 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

[0073] 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) HNB-GW 415, and (3) HNBAP protocol stacks of each of the HNB 405 and the HNB-GW 415. The HNBAP protocol stacks 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.

[0074] 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. 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).

[0075] 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). Further details of SCTP are provided in Section III below. 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. [0076] 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)

[0077] 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.

[0078] Figure 5 includes (1) HNB 505, (2) HNB-GW 515, (3) CN 540, (4) UE 550, and (5) control plane protocol stacks of each of the HNB 505, the HNB-GW 515, the CN 540, and the UE 550. The control plane protocol stacks of the HNB 505 and the HNB-GW 515 include (1) access layers 510, (2) transport IP layer 520, (3) IPSec layer 525, (4) remote IP layer 540, (5) SCTP 530, (6) RANAP user adaptation (RUA) layer 535, and (7) interworking functionality (IWF) 545. 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 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.

[0079] 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.

[0080] 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.

[0081] 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 connectionless RANAP messages.

[0082] 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.

[0083] 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 Iuh 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.

[0084] 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 Iuh 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.

[0085] 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.

[0086] 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.

[0087] 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 (e.g., the RUA PPI value should be registered with IANA).

[0088] 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.

[0089] 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.

[0090] 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 Iuh 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 Iuh 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.

[0091] 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 INITIAL DIRECT TRANSFER message over the Iuh interface. The INITIAL DIRECT TRANSFER 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).

[0092] 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.

[0093] In some embodiments, the direct transfer mechanism for relaying RANAP messages provides a single protocol over the Iuh 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 Iuh interface. If RANAP were to be used directly over the Iuh 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) of the underlying transport layers of RANAP such as SCCP/M3UA are eliminated as well.

3. HNB Circuit Switched (CS) Domain - User Plane Architecture

[0094] Figure 6 illustrates the protocol architecture in support of the CS domain user plane over the Iuh interface in accordance with some embodiments of the invention. This figure includes (1) HNB 605, (2) UE 610, (3) HNB-GW 615, (4) MSC 620, and (5) CS user plane protocol stacks for each of the devices.

[0095] The user plane of the HNB 605 and HNB-GW 615 includes the access, transport IP, IPSec, and remote IP layers described above with reference to Figure 5. The protocol stacks include the User Datagram Protocol (UDP) layer 630 to perform connectionless transfer of Real-Time Protocol (RTP) layer 635 messages. The HNB 605 also includes an Iu-UP protocol layer 625 that operates directly with the MSC 620 of the CN.

[0096] The Iu-UP 625 protocol transports CS user data across the Iuh and Iu-cs interfaces. The HNB-GW 615 provides either a transport layer conversion between IP (towards the HNB 605) and ATM (towards the MSC 620) or transport layer routing when IP transport is used on Iuh as well as the Iu-cs interfaces. In this manner, CS user data is carried transparently between the UE 610 and the MSC 620. In some embodiments, for example when IP transport is used on Iu-cs interface, the RTP 635 and the UDP layers 630 operate directly between the HNB and the MSC (not shown).

4. HNB Packet Switched (PS) Domain - User Plane Architecture

[0097] Figure 7 illustrates the PS Domain User Plane Protocol Architecture in accordance with some embodiments. This figure includes (1) HNB 705, (2) UE 710, (3) HNB-GW 715, (4) SGSN 725, and (5) PS user plane protocol stacks for each of the devices. [0098] The user plane of the HNB 705 and HNB-GW 715 includes the access transport IP, IPSec, and remote IP layers described above with reference to Figure 5. The protocol stack of the HNB 705 also includes the User Datagram Protocol (UDP) layer 735 to perform connectionless transfer of GPRS Tunneling Protocol (GTP) User (GTP-U) data messages.

[0099] The GTP-U protocol 730 operates between the HNB 705 and the SGSN 725, transporting the PS user data across the Iuh and Iu-ps interfaces. The HNB-GW 715 provides either a transport layer conversion between IP (towards the HNB 705) and ATM (towards the CN) or transport layer routing when IP transport is used on Iuh as well as the Iu-ps interfaces. PS user data is carried transparently between the UE 710 and CN (SGSN 725/GGSN). In an alternate embodiment (not shown in the Figure 7), the GTP-U protocol from the HNB and the SGSN terminates in the HNB-GW and the HNB-GW provides interworking of GTP-U protocol between the Iuh and Iu-cs interface.

III. CONNECTION BETWEEN HNB AND HNB GATEWAY

[00100] In some embodiments of the invention, HNBs are connected over the Iuh interface to a HNB Gateway (HNB-GW) which provides the interface to the core network elements via standard Iu interfaces; i.e., the Iu-cs interface to the MSC/VLR and the Iu-ps interface to the SGSN/GGSN. The UE performs a cell selection of a particular HNB and uses the standard radio interface Uu for communication with the HNB. There may be more than one UE camped on a particular HNB. Similarly, there may be multiple UEs having ongoing CS and/or PS sessions via a particular HNB.

[00101] In some embodiments, HNB and the HNB-GW have the following logical functions: (1) control plane functionality, (2) user plane functionality, and (3) security functions. In some embodiments, control plane functionality uses HNBAP, RUA, RANAP protocols as described above. Further details of control plane functionality are described in the following documents. 3GPP TS 25.467: "UTRAN architecture for 3G Home NodeB; Stage 2", hereinafter "3GPP TS 25.467"; 3GPP TS 25.468: "UTRAN Iuh Interface RANAP User Adaption (RUA) signalling", hereinafter "3GPP TS 25.468"; 3GPP TS 25.469: "UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling", hereinafter "3GPP TS 25.469"; and 3GPP TS 25.413: "UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling", hereinafter "3GPP TS 25.413". The contents of 3GPP TS 25.467, 3GPP TS 25.468, 3GPP TS 25.469, and 3GPP TS 25.413 are herein incorporated by reference.

[00102] In some embodiments, user plane functionality uses RTP/UDP/IP (CS domain) or GTP-U/UDP/IP (PS domain) as described above. Further details of user plane functionality are described in 3GPP TS 25.467, 3GPP TS 25.413, 3GPP TS 25.415: "UTRAN Iu interface user plane protocols", hereinafter "3GPP TS 25.415", and 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface", hereinafter "3GPP TS 29.060". The contents of 3GPP TS 25.415 and 3GPP TS 29.060 are herein incorporated by reference.

[00103] In some embodiments, security functions support of IPSec and related security protocol. Further details of security functions are described in "3GPP TS 25.467" and 3GPP TR 33.820: "Security of H(e)NB", hereinafter "3GPP TR 33.820". The contents of 3GPP TR 33.820 are herein incorporated by reference.

[00104] In some embodiments, the Iuh interface between the FINB and FINB-GW utilizes the Stream Control Transmission Protocol (SCTP). Further details are described in RFC 4960, "Stream Control Transmission Protocol", hereinafter "RFC 4960"; and "Signaling System No. 7 (SS7/C7) - Protocol, Architecture and Services", Lee Dryburgh and Jeff Hewett, hereinafter "Signaling System No. 7". In the FINB system there is an IPSec tunnel between the FINB and FINB-GW for secure communications and the SCTP is tunnelled inside the IPSec transport. A brief description of SCTP follows in order to set the problem in perspective.

A. Stream Control Transmission Protocol (SCTP)

[00105] SCTP was originally designed to transport Public Switched Telephone

Network (PSTN) signalling messages over IP networks, but its design enables it to support a broader set of applications including as a replacement for the ubiquitous Transmission Control Protocol (TCP). SCTP is a reliable transport protocol that operates on connectionless packet switched networks such as IP networks, and can be used between any two endpoints that support SCTP in the protocol stack by initiating an "association". The two endpoints go through a four-way "handshake" initialization procedure in which they exchange certain state information to set up the association. Multiple communication entities that connect through the endpoints may use this SCTP association to communicate. In order to distinguish the communication entities from the association, SCTP provides for independent "streams" that share the association - the streams are set up during initialization of the SCTP association, and each stream is provided with a stream identifier.

[00106] In the context of the HNB system, multiple UEs may use a HNB to access the mobile operator's network for services. Therefore, the HNB and the HNB-GW set up an SCTP association that is then shared by the UE-associated streams to exchange HNBAP and RUA control messages. The actual user plane data (voice frames, web content packets etc) do not use SCTP. Since each UE has its own identifier to begin with, it is also possible to set up the SCTP association with a single stream, and messages from all UEs can share the single stream. However, the use of the multiple streams is useful to prevent the head-of-line blocking that can occur until the most recent message in the stream is reliably transmitted from sender to receiver.

[00107] Referring back to Figure 4, in the embodiments that the SCTP 430 establishes a single SCTP association between the HNB 405 and HNB-GW 415, the same SCTP association is used for the transport of both the HNBAP messages as well as the RANAP messages (using RUA protocol), over the Iuh interface 435. The SCTP Payload Protocol Identifier (PPI) value is used to identify the protocol being transported in the SCTP data chunk (e.g., 20 for HNBAP and 19 for RUA as assigned by the Internet Assigned Numbers Authority (IANA)). Each SCTP association contains a number of "streams" which are used to support multiple flows across the Iuh interface. In some embodiments, a dedicated SCTP stream (i.e., stream id 0 of the underlying SCTP transport association) is used for the transport of HNBAP messages across the Iuh interface.

[00108] SCTP is quite different from TCP, which is initiated on demand by the communicating entities (UEs) even though they may use the same endpoint IP addresses. In the case of TCP, it is left to the application which uses TCP for transport to initialize and manage the TCP connection. In contrast, SCTP handles the initialization and connection management and the application mainly needs to convey its messages to SCTP, which then handles reliable transport.

[00109] Unlike TCP, SCTP also provides two mechanisms for failure detection and protection: heartbeat and multihoming. First, a SCTP parameter called Path.Max.Retrans threshold can be combined with SCTP 's message retransmission and heartbeat mechanisms. For instance, for a specific path between two SCTP peer entities, each entity could (independently) create a counter that is updated as follows: (i) for an active SCTP connection, increment the counter whenever retransmissions of a message go unacknowledged; or (ii) for idle connections, increment every time a heartbeat goes unacknowledged. If the value of the counter reaches the Path.Max.Retrans threshold, the SCTP connection is deemed to have failed. Second, SCTP multihoming allows an endpoint to use multiple transport addresses (e.g. IP address). Therefore, if both peers support multihoming, a multitude of links can be set up simultaneously between them, thus enabling uninterrupted communication even if some (but not all) of the links fail. However, HNBs are consumer premise equipment devices that are highly unlikely to support multihoming.

B. Loss of Connectivity

[00110] The control plane function of some embodiments, as mentioned above, utilizes

SCTP as the reliable transport mechanism. It is conceivable that the control plane network or the transport layer can have failures whilst there are ongoing CS/PS sessions (e.g. voice calls or web browsing sessions) between the UE and CN via the HNB and HNB-GW. Similarly there may be failures in the logical components of the HNB or HNB-GW which host the control plane functionality (e.g., a software component, such as a software engine that deals with the control plane only). A similar effect may be caused by a hardware component failure that only disrupts the control plane functionality. However, even under such control plane failures, it is possible that the ongoing CS/PS user plane sessions of UE(s) may not be disrupted by the failure as the user plane functionality may be on a separate logical or physical component (e.g., independent software process, different CPU, processor board, or even different computer in a cluster) or a separate network.

[00111] Different methods of failure detection are possible. One example is described herein. The underlying carrier protocol, i.e. SCTP, itself provides some path failure detection and protection mechanisms as described in the above mentioned "Signaling System No. 7".

[00112] Despite usage of SCTP failover capabilities, the SCTP association between a

HNB and the HNB-GW can experience failure, and it is highly desirable to ensure that ongoing user sessions are preserved and continue uninterrupted through failure and recovery of the control plane. The following describes the typical behavior in the HNB system resulting, for example, from loss of Iuh interface connectivity. The HNB-GW and HNB both perform Iuh failure detection, as well as take remedial action, independently. Therefore, as described below, the outcome depends on which entity first detects disruption and takes remedial action that pre-empts that taken by the other entity. [00113] Figure 8 illustrates a typical behavior in the HNB system resulting, for example, from loss of Iuh interface connectivity. As shown, UE 805 has an ongoing CS/PS session (in Step 1) via the HNB system (i.e., HNB 810 and HBN-GW 815) to core network 820 (which includes e.g., MSC and SGSN). The SCTP protocol layer on the HNB 810 periodically sends (in Step 2) SCTP HEARTBEAT message to the HNB-GW 815 to check (e.g., based on whether or not an acknowledgment message is received from the HNB-GW) that the SCTP connection exists.

[00114] As shown, IP connectivity between the control planes of HNB 810 and HNB-

GW 815 is lost (at Step 3), e.g., due to a component failure in either the HNB or HNB-GW or a broadband network problem. Next, the HNB-GW and HNB can detect Iuh connectivity failure independently. When HNB 810 detects (in Step 4a) the loss of SCTP connectivity, HNB 810 cleans up (in Step 6a) all previous resources associated with this SCTP session including the UE registrations records, HNBAP, RUA, and RANAP control records, and ongoing UE CS/PS session records. Furthermore, HNB 810 may also force UE 805 to reselect a different cell than itself, since it is no longer able to provide service. The UE, as a result of the cell re-selection, will switch to UMTS macro cell (if UMTS macro network coverage is available).

[00115] When HNB-GW 815 detects (in Step 4b) the loss of connectivity, HNB-GW

815 releases (in Step 4b) the resources assigned to HNB 810 (e.g., SCTP connection) and deletes the subscriber record (i.e., performs a local deregistration of HNB 810). Optionally, HNB-GW 815 also deletes UE specific connections and contexts originating from that HNB 810. This could result in HNB-GW 815 deleting ongoing CS/PS sessions in HNB-GW 815 as well as towards MSC/SGSN. Steps 4a and 4b are performed independently.

[00116] The HNB 810 then attempts to re-establish (in Step 5) the SCTP connection and re-register itself with the HNB-GW. HNB 810 and HNB-GW 815 exchange (in Steps 6a and 6b) the re -registration messages. When the HNB re-establishes connectivity and reregisters before the HNB-GW detects the problem, the HNB-GW recognizes that the HNB is already registered and adjusts accordingly (e.g., release the old SCTP connection resources).

IV. HIGH AVAILABILITY OF IUH INTERFACE

[00117] Some embodiments of the invention use a combination of register message

(e.g., HNBAP register message) and full or partial re-initialization messages to provide high availability for the control plane failures which are described above. In some embodiments, full re -initialization is done by sending a reset message (such as a RANAP Reset message) from either HNB to HNB-GW or HNB-GW to HNB. In some embodiments, partial reinitialization is done by sending a reset resource messages (such as a RANAP Reset Resource message) from either HNB to HNB-GW or HNB-GW to HNB. Specifically, some embodiments use reception of a reset (e.g., an explicit RANAP Reset, or Reset Resource) message to cleanup ongoing sessions and resources associated with the sending entity. In these embodiments, upon control plane failure (e.g. loss of Iuh connectivity), the HNB and HNB-GW continue to maintain the ongoing sessions (i.e. not cleanup upon failure detection) until a reset or a reset resource message (e.g., an explicit RANAP Reset or Reset Resource message) is received.

A. Use of Reset and Reset Resource Procedures to Do Full or Partial Reinitialization

[00118] Some embodiments perform full initialization after the loss of connectivity. In these embodiments, the HNB-GW initiates a timer after detecting a loss of control plane connectivity, and maintains user plane session states until the expiration of this timer. The lost control plane connectivity is recovered if the HNB successfully re -registers with the HNB-GW prior to the expiration of the timer.

[00119] If either side sends a reset message (e.g., a RANAP Reset message) after restoration of the control plane by HNB Registration, it is taken as an indication that there was a loss of user plane connectivity as well, and both sides synchronize to a known initial reset state. All user plane session states are cleared by both the HNB and HNB-GW. If neither side sends a reset message (e.g., a RANAP Reset message), then it is taken as an indication that there was no loss of user plane connectivity. The control plane state was successfully recovered due to HNB re -registration.

[00120] The RANAP Reset message (from either the HNB or the HNB-GW) serves to reinitialize the recipient's RANAP control plane signaling associated with all UEs communicating through the entity. For instance, if the HNB-GW were to send the RANAP Reset message to a HNB, it would reinitialize the sessions of all UEs communicating through the HNB.

[00121] In some situations, it may not be desirable to affect the communication of all

UEs, or it is possible that some of the UEs that were registered prior to control plane loss have now disconnected. Thus, a partial reset is needed that can reinitialize the sessions of some specific UEs. This is possible in an alternative embodiment that uses the UE-specific RANAP Reset Resource message instead. Therefore, in order to accomplish partial reinitialization, the sender (e.g. HNB-GW) can send a number of RANAP Reset Resource messages (one per UE that should be reset).

[00122] Figure 9 conceptually illustrates a process 900 for performing re -initialization in some embodiments of the invention. As shown, the process determines (at 905) that there is loss of connectivity between the access point and the network controller. The process maintains (at 910) resources assigned to the access point for a set of ongoing user plane sessions after the loss of the signaling connectivity. Next, the process reestablishes (at 915) the signaling connectivity between the access point and the network controller. Finally, the process sends (at 920) a set of commands to reset one or more maintained resources when one or more ongoing user plane sessions between the access point and the network controller are interrupted. Several examples giving more details are described in subsections 1-4 below. However, one of ordinary skill in the art would recognize that process 900 can be performed without the specifics of those examples.

[00123] Furthermore, one of ordinary skill in the art will recognize that process 900 is a conceptual representation of the operations used for performing re -initialization. The specific operations of process 900 may not be performed in the exact order shown and described. The specific operations may not be performed in one continuous series of operations, and different specific operations may be performed in different embodiments. Furthermore, the process could be implemented using several sub-processes, or as part of a larger macro process.

[00124] The use of the RANAP Reset (or Reset Resource) message in some embodiments is to explicitly reset the UE 's registration records, UE contexts, and ongoing CS/PS session records to a known initial state. UE registration records include information relevant to the UE 's initial registration with the HNB-GW through the HNB with identifiers such as the IMSI or (P)TMSI, and a "UE Context id" that is assigned as an identifier to separate its associated messages from a shared SCTP stream. UE contexts may include all HNBAP, RUA, and RANAP control information and parameters. UE call/session records may include all information related to ongoing voice calls such as the core network node (MSC/SGSN) serving it, the nature of the call/session, etc. In case there were active calls/sessions for the UE (or UEs), they are dropped as a result of such an action. If the RANAP Reset (or Reset Resource) messages are not received following re-registration by the HNB, different embodiments use different methods to re-create the UE 's registration contexts and call/sessions records in the new HNB registration. While the specific method is left to implementation in the HNB and HNB-GW, two possible options used in some embodiments are the following: (i) the HNB explicitly re-registers the UEs involved in the reset procedure, and the HNB and HNB-GW "re-associate" the existing call/session records of these UEs with their respective new UE registration contexts, or (ii) the HNB does not explicitly re-register the UEs, but the HNB and HNB-GW implicitly register the UEs by simply re-associating the UE' s existing registration contexts and call/session records with the new HNB registration.

[00125] On the Iuh interface between the HNB and HNB-GW, all RANAP messages are carried within RUA messages. In particular, the RANAP Reset, RANAP Reset Acknowledge, RANAP Reset Resource, and RANAP Reset Resource Acknowledge messages are all carried within the RUA CONNECTIONLESS TRANSFER message. Henceforth, when one of these RANAP messages is referred to, it is understood that it is carried between the HNB and HNB-GW encapsulated in the RUA CONNECTIONLESS TRANSFER message. In the interest of clarity and brevity, the RUA encapsulation may not be explicitly mentioned.

1. Full Re-initialization by the HNB

[00126] Figure 10 illustrates re-initialization by the HNB in some embodiments.

Specifically, Figure 10 illustrates a scenario where the HNB detects loss of Iuh connectivity and triggers re -initialization of all its resources in the HNB-GW by sending a reset message (e.g., an explicit RANAP Reset message). As shown, UE 1005 has (in Step 1) an ongoing UE CS/PS session via the HNB system.

[00127] The SCTP protocol layer on HNB 1010 periodically sends (in Step 2) SCTP

HEARTBEAT message to HNB-GW 1015 to check (e.g., based on whether or not an acknowledgment message is received from the HNB-GW) that the SCTP connection exists. Next, IP connectivity between the control planes of HNB 1010 and HNB-GW 1015 is lost (in Step 3), e.g., due to a component failure in either the HNB or HNB-GW.

[00128] Next, HNB 1010 detects (in Step 4) loss of SCTP connectivity. In some embodiments, the HNB cleans up all previous resources associated with this SCTP session including ongoing UE CS/PS sessions. Furthermore, in some embodiments, the HNB also forces the UE to reselect a different cell than itself, since the HNB is no longer able to provide service. The UE, as a result of the cell re-selection, will switch to UMTS macro cell (if UMTS macro network coverage is available).

[00129] The HNB then attempts (in Step 5) to re-establish the SCTP connection and re-register (in Steps 6a-6c) with the HNB-GW. HNB 1010 sends a register request message (e.g., a HNBAP HNB REGISTER REQUEST message) to HNB-GW 1015.

[00130] The HNB-GW 1015 may independently detect (in Step 6b) loss of Iuh connectivity after receiving the register request (e.g., the HNBAP HNB REGISTER REQUEST) from HNB 1010. If so, HNB-GW gives precedence (in Step 6b) to the recovery procedure initiated by the HNB, and maintains the resources assigned to the HNB including all the associated UE registrations, contexts, and ongoing CS/PS sessions. The HNB-GW sends (in Step 6c) a register accept message (e.g., a HNBAP HNB REGISTER ACCEPT message) to the HNB.

The following steps describe the reset procedure that encompasses all UEs registered by the HNB 1010 with the HNB-GW 1015. These steps are performed when the HNB determines that the user plane (as well as the control plane which was determined to be lost in Step 3) is lost. The scenario where the user plane connectivity is not lost and all existing sessions between the HNB and the HNB-GW are restored is described in subsection 5, "Ongoing Session Recovery upon Failure", below. The HNB sends (in Step 7a) one reset message per domain (e.g CS and PS) to HNB-GW 1015. In some embodiments, the reset message is an explicit RANAP Reset message encapsulated in RUA CONNECTIONLESS TRANSFER message. This is best done only after successful HNB re-registration, and indicates to the HNB-GW that the HNB has lost/cleaned up all existing transaction reference information including all the associated UE registrations, contexts and ongoing CS/PS sessions. In some embodiments, HNB may initiate timers (e.g., T RANAPResetCS and T RANAPResetPS) on sending the reset messages, the use of which is described below.

[00131] HNB-GW 1015 as a result of receiving the reset messages (e.g., explicit

RANAP Reset messages for Cs and PS domains) performs (in Step 7b) a cleanup of the local resources maintained for the old registration of the HNB 1010 including all the associated UE registrations, contexts, and ongoing CS/PS sessions between the HNB-GW and the CN. HNB-GW 1015 also informs the CN of the same over the Iu interface.

[00132] Upon completion and clearing of resources, HNB-GW 1015 responds back (in

Step 7c) with corresponding reset acknowledgment messages (e.g., RANAP Reset Acknowledge messages, one per CS or PS domain, encapsulated in RUA Connectionless Transfer messages) to the HNB. If the HNB does not receive the reset acknowledgement (e.g., the RANAP Reset Acknowledge) messages, for instance before the timers (e.g., T RANAPResetCS and T RANAPResetPS) expire (if the timers have been initiated), the HNB may retry the RANAP Reset procedure for a maximum of n times, where n is decided based on operator and deployment considerations.

2. Full Re-initialization by the HNB-GW

[00133] Figure 11 illustrates re-initialization by HNB-GW in some embodiments.

Specifically, Figure 11 illustrates the scenario where the HNB-GW detects loss of Iuh connectivity and triggers re-initialization of all its resources in the corresponding HNB by sending an explicit RANAP Reset.

[00134] As shown, UE 1105 has (in Step 1) an ongoing CS/PS session via the HNB system. The SCTP protocol layer on HNB 1110 periodically sends (in Step 2) SCTP HEARTBEAT message to the HNB-GW 1115 to check (e.g., based on whether or not an acknowledgment message is received from the HNB-GW) that the SCTP connection exists. IP connectivity between the control planes of HNB 1110 and HNB-GW 1115 is lost (in Step 3), e.g., due to a component failure in either the HNB or HNB-GW.

[00135] HNB-GW 1115 detects (in Step 4a) loss of connectivity. HNB-GW 1115 initiates (in Step 4b) procedures to reset HNB specific resources towards the CN (e.g., MSC/SGSN) 1120. The HNB-GW cleans up all existing transaction reference information including all the associated UE registrations, contexts and ongoing CS/PS sessions for that HNB.

[00136] HNB 1110 detects (in Step 5) loss of Iuh connectivity and attempts to reestablish the SCTP connection and re-register with the HNB-GW. The HNB attempts (in Step 5) to establish a new connection with the HNB-GW. The HNB sends (in Step 7a) a register request (e.g., a HNBAP HNB REGISTER REQUEST) message to the HNB-GW. The HNB- GW sends (in Step 7b) a register accept (e.g., a HNBAP HNB REGISTER ACCEPT) message to the HNB.

[00137] Next the reset procedure encompassing all UEs registered by the HNB is performed as follows. The HNB-GW sends (in Step 8a) reset messages (e.g., RANAP Reset messages), one message per domain, to the HNB to inform that HNB-GW did not find any transaction reference information including UE registrations, contexts, and CS/PS sessions associated with the HNB. As a result, all Radio Access Bearers that were set up for the CS/PS sessions are released. The HNB responds (in Step 8b) with reset acknowledge (e.g., a RANAP Reset Acknowledge) messages (one per domain), and performs a cleanup of its local resources.

3. Partial Re-initialization by the HNB

[00138] Figure 12 illustrates partial re-initialization by the HNB in some embodiments. Specifically, Figure 12 illustrates the scenario where the HNB detects loss of Iuh connectivity and triggers partial re-initialization of some of its resources in the HNB-GW by sending an explicit RANAP Reset Resource. As shown, UE 1205 has (in step 1) an ongoing CS/PS session via the HNB system.

[00139] The SCTP protocol layer on HNB 1210 periodically sends (in Step 2) SCTP

HEARTBEAT message to HNB-GW 1215 to check (e.g., based on whether or not an acknowledgment message is received from the HNB-GW) that the SCTP connection exists. IP connectivity between the control planes of the HNB and HNB-GW is lost (in Step 3), e.g., due to a component failure in either the HNB or HNB-GW.

[00140] The HNB detects (in Step 4) loss of SCTP connectivity. In some embodiments, the HNB cleans up all previous resources associated with this SCTP session including ongoing UE CS/PS sessions. Furthermore, the HNB in some embodiments forces the UE to reselect a different cell than itself, since the HNB is no longer able to provide service. The UE, as a result of the cell re-selection, will switch to UMTS macro cell (if UMTS macro network coverage is available).

[00141] HNB 1210 then attempts (in Step 5) to re-establish the SCTP connection and re-register with HNB-GW 1215. The HNB sends (in Step 6a) a register request (e.g., a HNBAP HNB REGISTER REQUEST) message to the HNB-GW.

[00142] HNB-GW 1215 may independently detect (in Step 6b) loss of Iuh connectivity after receiving the register request (e.g., the HNBAP HNB REGISTER REQUEST) message from the HNB. If so, the HNB-GW gives precedence to the recovery procedure initiated by the HNB, and maintains the resources assigned to the HNB including all the associated UE registrations, contexts, and ongoing CS/PS sessions. The HNB-GW sends (in Step 6c) a register accept (e.g., a HNBAP HNB REGISTER ACCEPT) message to the HNB. [00143] Next, HNB 1210 performs reset resource procedure that is targeted to specific

UEs at that HNB. The HNB then sends (in Step 7a) reset resource (e.g., explicit RANAP Reset Resource encapsulated in RUA Connectionless Transfer) messages (one per UE per domain, e.g., one per UE per CS domain and one per UE per PS domain) to the HNB-GW. The specific UE information is indicated by the HNB 1210 to the HNB-GW 1215 via the existing RANAP Reset Resource message attribute "Iu signaling connection identifier" (which may also be same as the UE context Id). This is best done only after successful HNB re-registration, and indicates to the HNB-GW that the HNB has lost/cleaned up all existing transaction reference information including all the associated UE registrations, contexts and ongoing CS/PS sessions. In some embodiments, the HNB 1210 initiates timers (e.g., T_RANAPResetCS-UE and T_RANAPResetPS-UE) on a per UE basis after sending the RANAP Reset Resource message to govern the completion of the reset resource procedure.

[00144] The HNB-GW as a result of receiving these reset resource (e.g., the explicit

RANAP Reset Resource) messages performs (in Step 7b) a cleanup of the local resources maintained between the HNB-GW and the CN for those specific UEs on the HNB including all the associated UE registrations, contexts, and ongoing CS/PS sessions. The HNB-GW also informs (in Step 7b) the CN of the same over the Iu interface.

[00145] Upon completion and clearing of resources, HNB-GW 1215 responds back (in

Step 7c) with corresponding reset acknowledge (e.g., RANAP Reset Resource Acknowledge encapsulated in RUA Connectionless Transfer) messages (one per UE per domain) to the HNB. If the HNB does not receive RANAP Reset Resource Acknowledge messages - for instance before the timers (e.g., T_RANAPResetCS-UE and T_RANAPResetPS-UE) expire, if they have been initiated - it may retry the reset resource procedure for a maximum of n times, where n is decided based on operator and deployment considerations.

4. Partial Re-initialization by the HNB-GW

[00146] Figure 13 illustrates partial re-initialization by the HNB-GW in some embodiments. Specifically, Figure 13 illustrates the scenario where the HNB-GW detects loss of Iuh connectivity and triggers partial re-initialization of some of its resources in the corresponding HNB by sending an explicit RANAP Reset Resource. As shown, UE 1305 has an ongoing CS/PS session via the HNB system.

[00147] The SCTP protocol layer on the HNB 1310 periodically sends (in Step 2)

SCTP HEARTBEAT message to HNB-GW 1315 to check (e.g., based on whether or not an acknowledgment message is received from the HNB-GW) that the SCTP connection exists. IP connectivity between the control planes of the HNB and HNB-GW is lost (in Step 3), e.g., due to a component failure in either the HNB or HNB-GW.

[00148] HNB-GW 1315 detects (In Step 4) loss of connectivity. The HNB-GW initiates (in Step 4b) procedures to reset HNB specific resources towards the CN 1320. The HNB-GW cleans up all existing transaction reference information for the specifically identified UEs on that HNB including all the associated UE registrations, contexts and ongoing CS/PS sessions.

[00149] HNB 1310 independently detects (in Step 5) loss of Iuh connectivity. The

HNB attempts (in Step 6) to establish a new connection with the HNB-GW. The HNB sends (in Step 7a) a register request (e.g., a HNBAP HNB REGISTER REQUEST) message to the HNB-GW.

[00150] HNB-GW 1315 sends (in Step 7b) a register accept (e.g., a HNBAP HNB

REGISTER ACCEPT) to the HNB. Next, the reset resource procedure targeted to specific UEs at that HNB is performed as follows. The HNB-GW sends (in Step 8a) reset resource (e.g., RANAP Reset Resource) messages (one per UE per domain) to the HNB to inform that the HNB-GW did not find any transaction reference information including UE registrations, contexts, and CS/PS sessions associated with the HNB. The HNB responds (in Step 8b) with reset resource acknowledgment (e.g., RANAP Reset Resource Acknowledge) messages (one per UE per domain), and performs a cleanup of its local resources.

5. Ongoing Session Recovery upon Failure

[00151] Figure 14 conceptually illustrates a process 1400 for performing recovery of ongoing user plane sessions after loss of control signalling plane connectivity in some embodiments of the invention. As shown, the process determines (at 1405) that there is loss of connectivity between the access point and the network controller. The process maintains (at 1410) resources assigned to the access point for a set of ongoing user plane sessions after the loss of the signaling connectivity. Next, the process reestablishes (at 1415) the signaling connectivity between the access point and the network controller. Finally, the process restores one or more of the ongoing user plane sessions over the reestablished connectivity by using the maintained resources. An example giving more details is described below. However, one of ordinary skill in the art would recognize that process 1400 can be performed without the specifics of the example. [00152] Furthermore, one of ordinary skill in the art will recognize that process 1400 is a conceptual representation of the operations used for performing recovery of ongoing user plane sessions after loss of control signalling plane connectivity. The specific operations of process 1400 may not be performed in the exact order shown and described. The specific operations may not be performed in one continuous series of operations, and different specific operations may be performed in different embodiments. Furthermore, the process could be implemented using several sub-processes, or as part of a larger macro process.

[00153] Figure 15 illustrates ongoing session recovery upon failure in some embodiments. Specifically, Figure 15 illustrates the scenario where the FINB or the HNB- GW detect loss of Iuh connectivity but are able to maintain all ongoing CS/PS sessions as a result of not exchanging explicit RANAP Reset or RANAP Reset Resource messages. As shown, UE 1505 has (in Step 1) an ongoing CS/PS session via the HNB system.

[00154] The SCTP protocol layer on HNB 1510 periodically sends (in Step 2) SCTP

HEARTBEAT message to HNB-GW 1515 to check (e.g., based on whether or not an acknowledgment message is received from the HNB-GW) that the SCTP connection exists. IP connectivity between the control planes of the HNB and HNB-GW is lost (in Step 3), e.g., due to a component failure in either the HNB or HNB-GW.

[00155] HNB 1510 detects (in Step 4) loss of SCTP connectivity, but also detects ongoing CS/PS sessions uninterrupted by the failure event. The HNB then attempts (in Step 5) to re-establish the SCTP connection and re-register with the HNB-GW 1515.

[00156] HNB 1510 sends (in Step 6a) a register request (e.g., a HNBAP HNB

REGISTER REQUEST) message to the HNB-GW. The HNB-GW may independently detect (in Step 6b) loss of Iuh connectivity after receiving the HNBAP HNB REGISTER REQUEST from the HNB. If so, HNb-GW gives precedence to the recovery procedure initiated by the HNB, and maintains the resources assigned to the HNB including all the associated UE registrations, contexts, and ongoing CS/PS sessions.

[00157] The HNB-GW sends (in Step 6c) a register accept (e.g., a HNBAP HNB

REGISTER ACCEPT) to the HNB. There is an ongoing UE CS/PS session via the HNB system.

[00158] The HNB does not send RANAP Reset or RANAP Reset Resource messages.

Therefore, the HNB and HNB-GW re-associate (in Step 7) all existing transaction reference information including all the associated UE registrations, contexts and ongoing CS/PS sessions for that HNB with the new Iuh connection (i.e. SCTP transport).

[00159] All ongoing CS/PS sessions from all the UEs are maintained and continue uninterrupted (in Step 8) through the HNB system. The HNB does not attempt to register any UE with ongoing calls/sessions again since doing so implies that there was no context for the UE, and would trigger call tear down.

V. COMPUTER SYSTEM

[00160] 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.

[00161] In this specification, the term "software" is meant to include 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 sub-parts 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.

[00162] Figure 16 conceptually illustrates a computer system with which some embodiments of the invention are implemented. The computer system 1600 includes a bus 1605, a processor 1610, a system memory 1615, a read-only memory 1620, a permanent storage device 1625, input devices 1630, and output devices 1635. [00163] The bus 1605 collectively represents all system, peripheral, and chipset buses that support communication among internal devices of the computer system 1600. For instance, the bus 1605 communicatively connects the processor 1610 with the read-only memory 1620, the system memory 1615, and the permanent storage device 1625.

[00164] From these various memory units, the processor 1610 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) 1620 stores static data and instructions that are needed by the processor 1610 and other modules of the computer system. The permanent storage device 1625, 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 1600 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 1625. Some embodiments use one or more removable storage devices (flash memory card or memory stick) as the permanent storage device.

[00165] Like the permanent storage device 1625, the system memory 1615 is a read- and-write memory device. However, unlike storage device 1625, 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.

[00166] Instructions and/or data needed to perform processes of some embodiments are stored in the system memory 1615, the permanent storage device 1625, the read-only memory 1620, 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 1610 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.

[00167] The bus 1605 also connects to the input and output devices 1630 and 1635.

The input devices enable the user to communicate information and select commands to the computer system. The input devices 1630 include alphanumeric keyboards and cursor- controllers. The output devices 1635 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 16, bus 1605 also couples computer 1600 to a network 1665 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).

[00168] Any or all of the components of computer system 1600 may be used in conjunction with the invention. For instance, some or all components of the computer system described with regards to Figure 16 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.

[00169] 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.

[00170] 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.

[00171] Many of the above figures 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. 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.

[00172] 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 other Femtocell systems that include Femtocell access points other than HNB and Femtocell network controllers other than HNB-GW (e.g., a Home enhanced Node B (HeNB) instead of HNB or a Generic Access Network Controller (GANC) instead of HNB-GW). One of ordinary skill in the art realizes that Femtocell access point is the generic term for small base stations that can be installed at consumer premises. "HNB" is a specific Femtocell access point that supports 3 G UMTS.

[00173] 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. [00174] 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

Second Generation of Cellular Wireless Standards 2G

Third Generation of Cellular Wireless Standards 3G

3^rd Generation Partnership Project 3GPP

Fourth Generation of Cellular Wireless Standards 4G

Access Link Control Application Part ALCAP

Adaption Layer 2 AAL2

Authorization, Authentication, and Accounting AAA

Access Network AN

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

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

Generic Access Network Controller GANC

Global System for Mobile communications GSM

Home enhanced Node B HeNB

Home Location Register HLR

Home Node-B HNB

HNB Access Network HNB-AN

HNB Application Part HNBAP

HNB Gateway HNB-GW

Identifier ID

International Mobile Subscriber Identity IMSI

Information Element IE

Internet Assigned Numbers Authority IANA

Internet Protocol IP

IP Internet Protocol

IP Security IPSec

Internet Service Provider ISP

Interworking Functionality IWF

Location Area LA

Location Area Identifier LAI

Location Area Update LAU

MTP3 User Adaptation Layer M3UA

Media Access Control MAC

Mobility Management MM

Mobile Switching Center MSC

Message Transfer Part Level 3 MTP3b

Non Access Stratum NAS

Network Address Translation NAT

Personal Communication Services PCS

Payload Protocol Identifier PPI Packet Switched PS

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

Either Packet TMSI or TMSI (P)TMSI

Public Switched Telephone Network PSTN

Radio Access Bearer RAB

PvANAP Adaptation Layer RAL

Radio Access Network RAN

Radio Access Network Application Part RANAP

Radio Frequency RF

Radio Link Control RLC

Radio Network Controller RNC

Radio Network Controller Id RNC-Id

Radio Network Layer RNL

Radio Resource Control RRC

Radio Resource Management RRM

RANAP Transport Adaptation RTA

Real-Time Transport Protocol RTP

RANAP User Adaptation RUA

Service Area Identifier SAI

Signalling Connection Control Part SCCP

Stream Control Transmission Protocol SCTP

Security Gateway SeGW

Serving GPRS Support Node SGSN

Subscriber Identity Module SIM

Service Mobile Location Center SMLC

Short Message Services SMS

Service-Specific Coordination Function Network to Node Interface SSCF-NNI

Specific Connection Oriented Protocol SSCOP

Signaling System 7 SS7

Temporary Mobile Subscriber Identity TMSI Transmission Control Protocol TCP

User Equipment UE

Unlicensed Mobile Access UMA

Universal Mobile Telecommunications System UMTS

Universal Subscriber Identity Module USIM

Either SIM or USIM (U) SIM

User Datagram Protocol UDP

UMTS Terrestrial Radio Access Network UTRAN

Visitor Location Register VLR Worldwide Interoperability for Microwave Access WiMax

Wireless Local Area Network WLAN

Wireless Service Provider WSP

Claims

CLAIMS What is claimed is:

1. A method of providing high availability for an Iuh based communication system, the communication system comprising (i) a first communication system comprising a core network and a licensed radio access network and (ii) a wireless second communication system comprising a short range access point for establishing service regions of the second network using short range licensed wireless frequencies and a network controller for communicatively coupling the access point to the core network to establish a set of user plane sessions for circuit switched and packet switched sessions, wherein a set of ongoing user plane sessions exists between the access point and the network controller, the method comprising:

determining that there is a loss of signaling connectivity between the access point and the network controller;

maintaining resources assigned to the access point for the set of ongoing user plane sessions after the loss of the signaling connectivity;

reestablishing the signaling connectivity between the access point and the network controller; and

restoring one or more of the ongoing user plane sessions over the reestablished connectivity using said maintained resources.

2. The method of claim 1 further comprising starting a timer after determining that signaling connectivity is lost, wherein maintaining resources assigned to the access point comprises maintaining the resources until the timer has expired.

3. The method of claim 1, wherein maintaining the resources comprises determining that one or more of the ongoing sessions between the access point and the network controller are uninterrupted after the loss of connectivity.

4. The method of claim 1, wherein reestablishing the signaling connectivity comprises:

sending a register request message from the access point to the network controller; and

receiving a register accept message at the access point from the network controller.

5. The method of claim 1, wherein the loss of connectivity is caused by a component failure in the access point.

6. The method of claim 1, wherein the loss of connectivity is caused by a component failure in the network controller.

7. The method of claim 1, wherein the loss of connectivity is caused by disruption in the wireless second communications system.

8. The method of claim 1, wherein the network controller is a Home Node B Gateway (HNB-GW) and the access point is a Home Node B.

9. The method of claim 1, wherein the resources assigned to the access point comprises user equipment registration records, user equipment contexts and ongoing Circuit Switched and Packet Switched session records.

10. The method of claim 1, wherein the ongoing user plane sessions comprise voice calls and browsing sessions.

11. The method of claim 1 , wherein the loss of connectivity is a loss of Stream Control Transmission Protocol (SCTP) connectivity.

12. The method of claim 1, wherein the ongoing user plane sessions are for a set of user equipments, wherein restoring one or more of the ongoing user plane sessions comprises:

the access points explicitly re-registering the user equipments; and re-associating the resources maintained for the user equipments sessions with the reregistered user equipments.

13. The method of claim 1, wherein the ongoing user plane sessions are for a set of user equipments, wherein restoring one or more of the ongoing user plane sessions comprises:

without explicitly re-registering the user equipments with the network controller, re-associating the resources maintained for the ongoing user plane sessions with the access point.

14. The method of claim 1, wherein the reestablishing signaling connectivity comprises associating the resources assigned to the access point with a new Iuh connection.

15. A method of providing high availability for an Iuh based communication system, the communication system comprising (i) a first communication system comprising a core network and a licensed radio access network and (ii) a wireless second communication system comprising a short range access point for establishing service regions of the second network using short range licensed wireless frequencies and a network controller for communicatively coupling the access point to the core network to establish a set of user plane sessions for circuit switched and packet switched sessions, wherein a set of ongoing user plane sessions exists between the access point and the network controller, the method comprising:

maintaining resources assigned to the access point for the set of ongoing user plane sessions after the loss of signaling connectivity;

reestablishing the signaling connectivity between the access point and the network controller;

determining whether one or more ongoing user plane sessions between the access point and the network controller are interrupted after the loss of connectivity; and sending a set of commands to reset one or more maintained resources when one or more ongoing user plane sessions are interrupted.

16. The method of claim 15, wherein the set of commands to reset one or more maintained resources comprises one reset command to reset all maintained resources for the circuit switched sessions and one reset command to reset all maintained resources for the packet switched sessions.

17. The method of claim 15, wherein the ongoing user plane sessions are for a set of user equipments having a set of circuit switched sessions and a set of packet switched sessions.

18. The method of claim 17, wherein the set of commands to reset one or more maintained resources comprises one reset resource command per user equipment per each circuit switched session and one reset resource command per user equipment per each packet switched session to selectively reset maintained resources for said one or more interrupted sessions while maintaining resources for a set of uninterrupted ongoing sessions.

19. The method of claim 15, wherein reestablishing the signalling connectivity comprises:

20. The method of claim 15 further comprising starting a timer after determining that the signalling connectivity is lost, wherein maintaining resources assigned to the access point comprises maintaining the resources until the timer has expired.

21. The method of claim 15, wherein the loss of signalling connectivity is a loss of Stream Control Transmission Protocol (SCTP) connectivity.

22. A computer readable medium storing a program for execution by a processing unit, the program for providing high availability for an Iuh based communication system, the communication system comprising (i) a first communication system comprising a core network and a licensed radio access network and (ii) a wireless second communication system comprising a short range access point for establishing service regions of the second network using short range licensed wireless frequencies and a network controller for communicatively coupling the access point to the core network to establish a set of user plane sessions for circuit switched and packet switched sessions, the program comprising sets of instructions for:

maintaining resources assigned to the access point for a set of ongoing user plane sessions between the access point and the network controller after the loss of signaling connectivity;

23. The computer readable medium of claim 22, wherein the set of commands to reset one or more maintained resources comprises one reset command to reset all maintained resources for the circuit switched sessions and one reset command to reset all maintained resources for the packet switched sessions.

24. The computer readable medium of claim 22, wherein the ongoing user plane sessions are for a set of user equipments having a set of circuit switched sessions and a set of packet switched sessions.

25. The computer readable medium of claim 24, wherein the set of commands to reset one or more maintained resources comprises one reset resource command per user equipment per each circuit switched session and one reset resource command per user equipment per each packet switched session to selectively reset maintained resources for said one or more interrupted sessions while maintaining resources for a set of uninterrupted ongoing sessions.

26. The computer readable medium of claim 22, wherein the set of instructions for reestablishing the signalling connectivity comprises sets of instructions for:

27. The computer readable medium of claim 22, wherein the program further comprises a set of instructions for starting a timer after determining that the signalling connectivity is lost, wherein the set of instructions for maintaining resources assigned to the access point comprises a set of instructions for maintaining the resources until the timer has expired.

28. The computer readable medium of claim 22, wherein the loss of signalling connectivity is a loss of Stream Control Transmission Protocol (SCTP) connectivity.