# HNB Gateway in Wireless Network

The Cisco® provides 3GPP wireless carriers with a flexible solution that functions as a Home NodeB Gateway (HNB-GW) in HNB Access Network to connect UEs with existing UMTS networks.

The Home NodeB Gateway works as a gateway for Home NodeBs (HNBs) to access the core networks. The HNB-GW concentrates connections from a large amount of HNBs through IuH interface and terminates the connection to existing Core Networks (CS or PS) using standard Iu (IuCS or IuPS) interface.
This overview provides general information about the HNB Gateway including:

- Product Description
- Network Deployment and Interfaces
- Features and Functionality - Base Software
- Features and Functionality - Optional Enhanced Feature Software
- How HNB-GW Works
- Supported Standards

Product Description

The Home NodeB Gateway is the HNB network access concentrator used to connect the Home NodeBs (HNBs)/Femto Access Point (FAP) to access the UMTS network through HNB Access Network. It aggregates Home Node-B or Femto Access Points to a single network element and then integrates them into the Mobile Operators Voice, Data and Multimedia networks.

Femtocell is an important technology and service offering that enables new Home and Enterprise service capabilities for Mobile Operators and Converged Mobile Operators (xDSL/Cable/FFTH plus Wireless). The Femtocell network consists of a plug-n-play customer premise device generically called a Home NodeB (HNB) with limited range radio access in home or Enterprise. The HNB will auto-configure itself with the Operators network and the user can start making voice, data and multimedia calls.

The figure given describes a high level view of UMTS network with Femtocell and HNB-GW.
Figure 1. HNB-GW Deployment in 3G UMTS Network

Once a secure tunnel has been established between the HNB and the SeGW and the HNB has been configured by the HMS, the Operator has to connect the Femtocell network to their Core Network and services. There are several interworking approaches to Circuit Switch (CS) and Packet Switch (PS) domains. One approach is to make the Femtocell network appear as a standard Radio Access Network (RAN) to the Core Network. In addition to the HNB, SeGW and HMS the RAN approach requires a network element generically called a Femto Gateway (FGW/HNB-GW). The HNB-GW provides interworking and aggregation of large amount of Femtocell sessions toward standard CN interfaces (IuPS/IuCS). In this approach services and mobility are completely transparent to CN elements (e.g. MSC, xGSN).

The other approach is to connect the Femtocell to an IMS Network to provide CS services to subscribers when on the Femtocell and deploy a new network element generically called a Convergence Server to provide service continuity and mobility over standard interfaces at the MSC layer (e.g GSM-MAP, IS-41). These two approaches are clearly different in how CS based services and mobility are achieved.
In accordance with 3GPP standard, the HNB-GW provides following functions and procedures in UMTS core network:

- HNB Registration/De-registration Function
- UE Registration/De-registration Function for HNB
- IuH User-plane Management Functions
- IuH User-plan Transport Bearer Handling
- Iu Link Management Functions

IMPORTANT:

Some of the features may not be available in this release. Kindly contact your local Cisco representative for more information on supported features.

HNB Access Network Elements

This section provides the brief description and functionality of various network elements involved in the UMTS Femto access network. The HNB access network includes the following functional entities:

- Home NodeB
- Security Gateway (SeGW)
- HNB Gateway (HNB-GW)
- HNB Management System (HMS)

Home NodeB

A Home NodeB (HNB) is the a customer premise equipment that offers Uu interface to UE and IuH over IPSec tunnel to HNB-GW for accessing UMTS Core Network (PS or CS) in Femtocell access network.
It also provides the support to HNB registration and UE registration over IuH with HNB-GW. Apart from these functions HNB also supports some RNC like functions as given below:

- RAB management functions
- Radio Resource Management functions
- Iu Signalling Link management
- GTP-U Tunnels management
- Buffer Management
- Iu U-plane frame protocol initialization
- Mobility management functions
- Security Functions
- Service and Network Access functions
- Paging co-ordination functions
- UE Registration for HNB
- IuH user-plane Management functions

Security Gateway (SeGW)

Security Gateway is a logical entity in Cisco HNB-GW.
Basic function of this entity are:

- Authentication of HNB
- Providing access to HMS and HNB-GW

This entity terminates the secure tunnelling for IuH and TR-069 between HNB and HNB-GW and HMS respectively.

In this implementation it is an optional element which is situated on HNB-GW.

HNB Gateway (HNB-GW)

The HNB-GW provides the access to Femto user to UMTS core network. It acts as an access gateway to HNB and concentrates connections from a large amount of HNBs. The IuH interface is used between HNB and HNB-GW and HNB-GW connects with the Core Networks (CS or PS) using the generic Iu (IuCS or IuPS) or Gn interface.

It also terminates Gn and other interfaces from UMTS core networks to provide mobile data services to HNB and to interact with HMS to perform HNB authentication and authorization.

HNB Management System (HMS)

It is a network element management system for HNB access. Management interface between HNB and HMS is based on TR-069 family of standards.
It performs following functions while managing HNB access network:

- Facilitates HNB-GW discovery for HNB
- Provision of configuration data to the HNB
- Performs location verification of HNB and assigns appropriate serving elements (HMS, Security Gateway and HNB-GW)

The HNB Management System (HMS) comprises of the following functional entities:

- File Server: used for file upload or download, as instructed by TR-069 manager
- TR-069 Manager: Performs CM, FM and PM functionality to the HNB through Auto-configuration server (HMS)

Licenses

The HNB-GW is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

Platform Requirements

The HNB-GW service runs on a Cisco® ASR 5x00 chassis running StarOS Rel. 10 or later. The chassis can be configured with a variety of components to meet specific network deployment requirements. For additional information, refer to the Installation Guide for the chassis and/or contact your Cisco account representative.

Network Deployment and Interfaces

This section describes the supported interfaces and deployment scenario of HNB-GW in 3G Femto access network.
The following information is provided in this section:

- HNB Gateway in 3G UMTS Network
- Supported Logical Interfaces

HNB Gateway in 3G UMTS Network

The following figure displays simplified network views of the HNB-GW in an Femto access network accessing UMTS PS or CS Core Network.
Figure 2. HNB-GW in UMTS Network and Interfaces

Supported Logical Interfaces

This section provides the brief information on supported interfaces on HNB-GW node.
In support of both mobile and network originated subscriber UE contexts, the HNB-GW provides the following network interface support:

- IuH Interface: This interface is the reference point for the control plane protocol between Home NodeB and HNB-GW. IuH uses SCTP over IPSec IKEv2 tunnel as the transport layer protocol for guaranteed delivery of signaling messages between HNB-GW and Home NodeB.This is the interface used by the HNB-GW to communicate with HNB on the same Femtocell Access Network. This interface serves as path for establishing and maintaining subscriber UE contexts.One or more IuH interfaces can be configured per system context.
- IuCS: This interface is the reference point in UMTS which links the HNB-GW, which acts as an RNC (Radio Network Controller), with a Mobile Switching Centre (3G MSC) in the 3G UMTS Femtocell Access Network. This interface provides an IuCS over IP or IuCS over ATM (IP over AAL5 over ATM) interface between the MSC and the RNC (HNB-GW) in the 3G UMTS Femtocell Access Network. RAN Application Part (RANAP) is the control protocol that sets up the data plane (GTP-U) between these nodes. SIGTRAN (M3UA/SCTP) or QSAAL (MTP3B/QSAAL) handle IuCS (control) for the HNB-GW.This is the interface used by the HNB-GW to communicate with 3G MSC on the same Public Land Mobile Network (PLMN). This interface serves as path for establishing and maintaining the CS access for Femtocell UE to circuit switched UMTS core networksOne or more IuCS interfaces can be configured per system context.
- IuPS: This interface is the reference point between HNB-GW and SGSN. This interface provides an IuPS over IP or IuPS over ATM (IP over AAL5 over ATM) interface between the SGSN and the RNC (HNB-GW) in the 3G UMTS Femtocell Access Network. RAN Application Part (RANAP) is the control protocol that sets up the data plane (GTP-U) between these nodes. SIGTRAN (M3UA/SCTP) or QSAAL (MTP3B/QSAAL) handle IuPS-C (control) for the HNB-GW.This is the interface used by the HNB-GW to communicate with SGSN on the same Public Land Mobile Network (PLMN). This interface serves as path for establishing and maintaining the PS access for Femtocell UE to packet switched UMTS core networks.One or more IuPS interfaces can be configured per system context.
- Gi: This interface is the reference point between HNB-GW and IP Offload Gateway. It is used by the HNB-GW to communicate with Packet Data Networks (PDNs) through IP Offload Gateway in the H-PLMN/V-PLMN. Examples of PDNs are the Internet or corporate intranets.One or more Gi interfaces can be configured per system context.
- Gn: This interface is the reference point between HNB-GW and GGSN. It is used by the HNB-GW to communicate with GGSNs on the same GPRS/UMTS Public Land Mobile Network (PLMN).One or more Gn interfaces can be configured per system context.
- RADIUS: This interface is the reference point between a Security Gateway (SeGW) and a 3GPP AAA Server or 3GPP AAA proxy (OCS/CGF/AAA/HSS) over RADIUS protocol for AAA procedures for Femto user.In the roaming case, the 3GPP AAA Proxy can act as a stateful proxy between the SeGW and 3GPP AAA Server.The AAA server is responsible for transfer of subscription and authentication data for authenticating/authorizing user access and UE authentication. The SeGW communicates with the AAA on the PLMN using RADIUS protocol.One or more RADIUS interfaces can be configured per system context.
- TR-069: This interface is an application layer protocol which is used for remote configuration of terminal devices, such as DSL modems, HNBs and STBs. TR-069 provides an auto configuration mechanism between the HNB and a remote node in the service provider network termed the Auto Configuration Server. The standard also uses a combination of security measures including IKEv2 (Internet Key Exchange v2) and IPsec (IP Security) protocols to authenticate the operator and subscriber and then guarantee the privacy of the data exchanged.One TR-069 interface can be configured per HNB node.
- DHCP: This is the interface used by the HNB-GW to communicate with a Dynamic Host Control Protocol (DHCP) Server. The system can be configured to dynamically provide IP addresses for HNBs from the DHCP server.

IMPORTANT:

DHCP interface support is available in StarOS Release 14.0 and later only.

Features and Functionality - Base Software

This section describes the features and functions supported by default in base software on HNB-GW service and do not require any additional license to implement the functionality with the HNB-GW service.
Following features and supports are discussed in this section:

- AAA Server Group Support
- AAL2 Establish and Release Support
- Access Control List Support
- ANSI T1.276 Compliance
- ATM VC Management Support
- Congestion Control and Management Support
- DHCP Interface Support on HNB-GW to HMS
- Dynamic RADIUS Extensions (Change of Authorization)
- Emergency Call Handling
- GTP-U Tunnels Management Support
- HNB-UE Access Control
- HNB Management Function
- Hyrbid Access Mode Support
- Intra-Domain Multiple CN Support Through Iu-Flex
- Iu Signalling Link Management Support
- IuH User-Plane Transport Bearer Handling Support
- Multiple HNB-GW Service Support
- Multiple MSC Selection without Iu-Flex
- Network Access Control Functions through SeGW
- Open Access Mode Support
- QoS Management with DSCP Marking
- RADIUS Support
- System Management Features
- UE Management Function for Pre-Rel-8 UEs

AAA Server Group Support

Value-added feature to enable VPN service provisioning for enterprise or MVNO customers. Enables each corporate customer to maintain its own AAA servers with its own unique configurable parameters and custom dictionaries.

This feature provides support for up to 800 AAA (RADIUS and Diameter) server groups and 800 NAS IP addresses that can be provisioned within a single context or across the entire chassis. A total of 128 servers can be assigned to an individual server group. Up to 1,600 accounting, authentication and/or mediation servers are supported per chassis and may be distributed across a maximum of 1,000 nodes. This feature also enables the AAA servers to be distributed across multiple nodes within the same context.

IMPORTANT:

For more information on AAA Server Group configuration, if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.

AAL2 Establish and Release Support

Support to establish and release of ATM adaptation layer 2 (AAL2) channel within an ATM virtual connection by the HNB-GW in complete or partial compliance with the following standards:

- 3GPP TS 25.414 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signalling (Release 9)
- 3GPP TS 25.415 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface user plane protocols (Release 8)
- 3GPP TS 25.467 V8.0.0. (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home NodeB; Stage 2 (Release 8)
- 3GPP TS 25.467 V9.1.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)
- ITU-T Recommendation Q.2630.1: AAL type2 signalling protocol (Capability Set 1)
- ITU-T Recommendation Q.2630.2: AAL type2 signalling protocol (Capability Set 2)
- ITU-T Recommendation I.363.2 B: ISDN ATM Adaptation Layer (AAL) Specification: Type 2 AAL
- ITU-T Recommendation I.366.1: Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2

The HNB-GW connects to core network elements like MSC and SGSN over IuCS and IuPS interfaces respectively. The Iu interface towards core network elements could either by IP based or ATM based. To provide ATM based interface support, Cisco HNB-GW provides AAL2 support on system in order to establish a voice bearer with MSC.

Access Control List Support

Access Control Lists provide a mechanism for controlling (i.e permitting, denying, redirecting, etc.) packets in and out of the system.

IP access lists, or Access Control Lists (ACLs) as they are commonly referred to, are used to control the flow of packets into and out of the system. They are configured on a per-context basis and consist of “rules” (ACL rules) or filters that control the action taken on packets that match the filter criteria

Once configured, an ACL can be applied to any of the following:

- An individual interface
- All traffic facilitated by a context (known as a policy ACL)
- An individual subscriber
- All subscriber sessions facilitated by a specific context

There are two primary components of an ACL:

- Rule: A single ACL consists of one or more ACL rules. As discussed earlier, the rule is a filter configured to take a specific action on packets matching specific criteria. Up to 128 rules can be configured per ACL.Each rule specifies the action to take when a packet matches the specifies criteria. This section discusses the rule actions and criteria supported by the system.
- Rule Order: A single ACL can consist of multiple rules. Each packet is compared against each of the ACL rules, in the order in which they were entered, until a match is found. Once a match is identified, all subsequent rules are ignored.

IMPORTANT:

For more information on Access Control List configuration, refer IP Access Control List chapter in System Administration Guide.

ANSI T1.276 Compliance

ANSI T1.276 specifies security measures for Network Elements (NE). In particular it specifies guidelines for password strength, storage, and maintenance security measures.

ANSI T1.276 specifies several measures for password security.

These measures include:

- Password strength guidelines
- Password storage guidelines for network elements
- Password maintenance, e.g. periodic forced password changes

These measures are applicable to the systems and the Web Element Manager since both require password authentication. A subset of these guidelines where applicable to each platform will be implemented. A known subset of guidelines, such as certificate authentication, are not applicable to either product. Furthermore, the platforms support a variety of authentication methods such as RADIUS and SSH which are dependent on external elements. ANSI T1.276 compliance in such cases will be the domain of the external element. ANSI T1.276 guidelines will only be implemented for locally configured operators.

ATM VC Management Support

Support for Asynchronous Transfer Mode (ATM) virtual circuits (VC) management function of AAL2 and AAL5 protocol by the HNB-GW in accordance with the following standards:

- 3GPP TR 29.814 V7.1.0 (2007-06): 3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals Feasibility Study on Bandwidth Savings at Nb Interface with IP transport (Release 7)

HNBGW supports PVC (permanent virtual circuits) connections with CN nodes for AAL2 and AAL5 type of traffic. The Common Part Sublayer (CPS) payload which is carried out by the AAL2 protocol over ATM is also configurable with this feature. It provides the dynamic Common Part Sublayer (CPS) payload configuration for AAL2 protocol traffic over ATM for negotiation between HNB-GW and MSC during call. Default size for payload is 45 but values may range from 1 to 64 Bytes. This feature makes the operator to choose the CPS payload size dynamically.

Congestion Control and Management Support

Congestion Control monitors the system for conditions that could potentially degrade performance when the system is under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an impact the system’s ability to service subscriber sessions. Congestion control helps identify such conditions and invokes policies for addressing the situation.

Congestion control operation is based on configuring the following:

- Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled and establishes limits for defining the state of the system (congested or clear). These thresholds function in a way similar to operation thresholds that are configured for the system as described in the Thresholding Configuration Guide. The primary difference is that when congestion thresholds are reached, a service congestion policy and an SNMP trap, starCongestion, are generated.A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for the condition to be cleared. An SNMP trap, starCongestionClear, is then triggered.
  - Port Utilization Thresholds: If you set a port utilization threshold, when the average utilization of all ports in the system reaches the specified threshold, congestion control is enabled.
  - Port-specific Thresholds: If you set port-specific thresholds, when any individual port-specific threshold is reached, congestion control is enabled system-wide.
- Service Congestion Policies: Congestion policies are configurable for each service. These policies dictate how services respond when the system detects that a congestion condition threshold has been crossed.

IMPORTANT:

For more information on Congestion Control support, refer Congestion Control chapter in System Administration Guide.

DHCP Interface Support Between HNB-GW and HMS

DHCP interface support at HNB-GW is provided to allocate IP address to HNB using DHCP procedure. Without this support IP address is allocated using locally configured IP pool. HNB connects to HNB Security Gateway (Se-GW) via IPSec tunnel. During IPSec tunnel establishment, HNB Se-GW allocates IP address to HNB. Femtocell provisioning system needs HNB IP address. This is achieved by co-locating this system with DHCP server. HNB Se-GW then uses DHCP procedure to allocate IP address to HNB.
Following is a typical message flow when HNB-GW performs as DHCP proxy:

1. HNB initiates IKE transaction by sending IKE SA INIT message to share encryption parameters.
2. Se-GW on HNB-GW responds with IKE SA INIT to confirm encryption parameters and the nonce.
3. HNB sends IKE Auth Request and includes IDi, IDr and configuration payload to request the IP address. IDi is the IKE ID of HNB-GW.
4. HNB-GW initiates Authentication with AAA Server. HNB and AAA server exchange EAP messages.
5. Finally AAA server confirms successful authentication of HNB to HNB-GW and Subscriber template is selected and aaa-data is returned to SessMGR by AAAMGR which contains necessary configuration and AAA returned values.
6. HNB-GW, as with previous EAP messages, relays EAP success over IKE Auth to HNB. Steps 4, 5 and 6 are not performed in case of certificate based authentication.
7. HNB then initiates IKE Auth request to authenticate the SA. HNB-GW selects the IP address allocation method using the configuration from AAA-data. Method is configured to be DHCP-proxy in subscriber template. To initiate DHCP transaction, DHCP-service is used. A suitable DHCP service is selected using configuration parameters in AAA-data.
8. DHCP-service selects a DHCP servers using local configuration and starts DHCP transaction. DHCP DISCOVER message is unicasted to every configured server. CID (IKE ID of HNB taken from IDi) is sent in DHCP option (61) “Client Identifier”. The GIADDR is the DHCP Relay/Proxy IP, i.e. the IP to which the DHCP service is bound. The GIADDR is used by the DHCP server to select the IP pool while allocating the IP.
9. If one of the DHCP servers responds (DHCP server [9] uses Failover protocol [11]) with DHCP OFFER providing the IP address. HNB-GW validates the provided IP address with local pool to check if the address is already being allotted to some other HNB. If so, DHCP transaction is not continued further and the HNB IKE establishment is rejected.
10. Upon successful IP address validation for uniqueness, HNB-GW sends DHCP REQUEST message providing the same IP address and CID. Note that Every DHCP message is sent to every configured server.
11. DHCP reserves the IP address and sends DHCP ACK confirming the IP address.
12. HNB-GW sends IKE Auth Response with allotted IP address to HNB in configuration response payload.

For this support HNB-GW is configured to communicate with DHCP server at port 61610 only and uses IKE-id of HNB as DHCP clientonly.

IMPORTANT:

For more information on DHCP interface configuration, refer HNB-GW Service Configuration Procedures.

RADIUS Change of Authorization Extensions

IMPORTANT:

Dynamic extensions other than RADIUS Change of Authorization (CoA) and Disconnect Message (DM) are not supported on HNB-GW.

Dynamic RADIUS extension support provide operators with greater control over subscriber sessions by providing the ability to dynamically manage HNB-UE White-List and/or disconnect the subscriber session.

This functionality is based on the RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), July 2003 standard.
The system supports the configuration and use of the following dynamic RADIUS extensions:

- Change of Authorization: The system supports CoA messages from the AAA server to change data filters associated with a subscriber session. The CoA request message from the AAA server must contain attributes to identify NAS and the subscriber session and a data filter ID for the data filter to apply to the subscriber session.
- Disconnect Message: The DM message is used to disconnect subscriber sessions in the system from a RADIUS server. The DM request message should contain necessary attributes to identify the subscriber session.

The above extensions can be used to dynamically re-direct subscriber bearer to an alternate address for performing functions such as provisioning, access control, and/or session disconnect.

IMPORTANT:

For more information on dynamic RADIUS extensions support, refer CoA, RADIUS, And Session Redirection (Hotlining) chapter in System Administration Guide.

Emergency Call Handling

The HNB-GW supports the handling of Emergency call in accordance with the following standards:

- 3GPP TS 25.467 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)
- 3GPP TS 33.102 V9.1.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture Release 9)

The HNB-GW provides access for all UE/HNB when emergency call initiated. In case of non CSG UEs or non CSG HNBs, after Emergency call is finished, the context established between the HNB and operator’s core network entities for UEs, who can not get access over the HNB, will be deregistered to prevent the UE from accessing non-emergency services. However if the UE remains idle for value equal to ue-idle-time, then it will be deregistered.
HNB-GW handles the emergency call in following way:

- Authentication: In case of emergency call, HNB sends a UE REGISTRATION REQUEST message with “Registration cause” as emergency call and excludes the “UE Permanent identity” (i.e IMSI) and HNB-GW does not perform access control for emergency call case.
- Single Iu and Single RAB: In case of emergency call, HNB-GW does not allow multiple RABs for UE. This means that UE must have only one Iu connection, either CS or PS, and have only one RAB on that Iu connection. HNB-GW implements “Single IU, Single RAB policy” when UE registration comes with Emergency. The RUA-CONNECT has an IE called “establishment cause” which can take values as “Normal” or “Emergency”. If UE-registration was due to emergency then RUA-CONNECT must contain “Emergency”. If RUA-CONNECT contains “normal” then HNB-GW rejects it.While rejecting RUA connection or RAB connection the HNB-GW uses following reject cause: RUA - Misc: unspecified RAB - Misc: unspecified
- If UE-registration is normal then both (normal and emergency) RUA-CONNECT is allowed.

GTP-U Tunnels Management Support

Support to manage the GTP-U tunnels between HNB-GW and GSNs by in accordance with the following standards:

- 3GPP TS 25.467 V9.1.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)
- 3GPP TS 25.468 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)
- 3GPP TS 25.469 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 9)
- 3GPP TS 29.060 V9.0.0 (2009-09): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 9)

HNB-GW supports establishment of GTPU tunnels for each RAB over the IuPS interface. HNB-GW terminates the GTP-U teunnels coming from CN (SGSN) and initiates seperate GTP-U tunnel towards HNB.

HNB-UE Access Control

UE/HNB access control support in 3G UMTS HNB Access Network is provided on HNB-GW through IMSI White list database and AAA attribute processing. This feature is in accordance with following standards:

- 3GPP TS 23.003 V8.9.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 8)
- 3GPP TS 25.467 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)
- 3GPP TS 25.469 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B (HNB) Application Part (HNBAP) signalling (Release 9)
- IETF RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000

The HNB-GW provides UE registration and de-registration procedure for the HNB to convey Rel-8 UE identification data to the HNB-GW in order to perform access control for the UE in the HNB-GW. The UE Registration also establishes a UE specific context identifier to be used between HNB and HNB-GW. The procedure triggered when the UE attempts to access the HNB via an initial NAS message and there is no context in the HNB allocated for that UE.

For pre-Release 8 UEs, which do not support CSG and does not listen for CSG-ID, the HNB-GW ensures that a UE is authorized to access a particular Femtocell. To perform access control check for pre-Release 8 UE, HNB-GW maintains a per-HNB Whitelist. This whitelist consists of IMSIs which are allowed to access that particular HNB. The whitelist is stored in the HMS and is downloaded to HNB-GW when HNB-REGISTRATION procedure happens.

HNB Management Function

Support for HNB registration and de-registration in 3G UMTS HNB Access Network accordance with the following standards:

- 3GPP TS 25.469 V8.1.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 8)
- IETF RFC 4960, Stream Control Transmission Protocol, December 2007

The HNB-GW provides HNB registration and de-registration procedure to register the HNB with the HNB-GW. This procedure enables the HNB-GW to provide service and core network connectivity for the HNB. On HNB-GW node this procedure is the first HNBAP procedure triggered after the SCTP association has become operational between HNB and HNB-GW.

HNB management function processes the HNB/UE access control procedure through White-List processing on HNB-GW node. Dynamic update of White-List gives the dynamic HNB management ability to HNB-GW.

Hyrbid Access Mode Support

A Closed HNB provides services only to the mobile subscribers which are member of the associated access control database (IMSI Whitelist). An HNB operating in Hybrid (Semi-Open) access mode provides services to other mobile subscribers along with members of the associated access control database whereas an Open HNB provides its services to any mobile subscriber.

HNB-GW supports Hybrids Access mode for Hybrid HNBs to expand its access control to Open, closed, and Hyrbid HNB access.
This feature provides following procedure for Hyrbid Access HNB registration on HNB-GW:

- Hybrid HNB registration: HNB-GW associates a set of access-controlled IMSIs (whitelist) with every Hybrid-HNB. For a Hybrid HNB, the whitelist is send by AAA-server in the Radius-Access-Accept message to the HNB-GW. The whitelist associated with a Hybrid HNB can also be empty. HNB-GW supports the modification of the whitelists associated with Hybrid HNBs. AAA-Server can send a COA message to the HNB-GW to change the whitelist associated with a Hybrid HNB. HNB-GW doesnot support modification of the cell-access-mode of registered HNBs using RADIUS CoA message. HNB-GW supports Open, Closed and Hybrid access mode HNBs simultaneously. HNB-GW provides a configuration to disable the registration of Hybrid HNBs.
- UE registration: HNB-GW supports guaranteed successful registration of the access-controlled (whitelisted) UEs associated with Hybrid HNBs. A configuration is provided to control the maximum number of simultaneously registered non-access-controlled UEs from a Hybrid HNB.
- Paging: Support paging of UEs simultaneously via Open, Closed and Hybrid HNBs
- Hand-in and Hand-out: HNB-GW supports UEs’ hand-in/hand-out relocation requests towards/from Hybrid HNBs. HNB-GW supports hand-in relocation for access-controlled UEs only.

IMPORTANT:

For more information on Hybrid Access Mode support configuration, refer Hybrid Access Mode Configuration section of HNB-GW Administration Guide.

Intra-Domain Multiple CN Support Through Iu-Flex

Iu-Flex is the routing functionality for intra domain connection of HNB-GW nodes to multiple CN nodes (MSC/SGSN). It provides a routing mechanism and related functionality on HNB-GW to enable it to route information of different Core Network (CN) nodes with in the CS or PS domain. It is implemented in accordance with the following standards:

- 3GPP TS 23.236 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes (Release 9)
- 3GPP TS 25.468 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)

HNB-GW supports Iu-Flex routing mechanism and other applications like many-to-many relation and load-sharing between CN nodes with HNB-GW and CN node pooling. This mechanism provides following benefits to network operator:

- Eliminates the single point of failure between an RNC/HNB-GW and a CN Node.
- Ensures geographical redundancy, as a pool can be distributed across sites.
- Minimizes subscriber impact during service, maintenance, or node additions or replacements.
- Increases overall capacity via load sharing across the MSCs/SGSNs in a pool.
- Reduces the need/frequency for inter-CN node RAUs. This substantially reduces signaling load and data transfer delays.
- Supports load redistribution with the MSC/SGSN offloading procedure.

To incorporate the concept of multiple CN nodes, Iu-Flex introduces the concept of “pool-areas” which is enabled by the routing mechanism in HNB GW. A pool-area is served by multiple CN nodes (MSCs or SGSNs) in parallel which share the traffic of this area between each other. Furthermore, pool-areas may overlap. From a RAN perspective a pool-area comprises all LA(s)/RA(s) of one or more RNC/BSC or HNBGW that are served by a certain group of CN nodes in parallel. One or more of the CN nodes in this group may in addition serve LAs/RAs outside this pool-area or may also serve other pool-areas. This group of CN nodes is also referred to as MSC pool or SGSN pool respectively.

The Iu-Flex enables a few different application scenarios with certain characteristics. The service provision by multiple CN nodes within a pool-area enlarges the served area compared to the service area of one CN node. This results in reduced inter CN node updates, handovers and relocations and it reduces the HLR/HSS update traffic. The configuration of overlapping pool-areas allows to separate the overall traffic into different UE moving pattern, e.g. pool-areas where each covers a separate residential area and all the same city centre. Other advantages of multiple CN nodes in a pool-area are the possibility of capacity upgrades by additional CN nodes in the pool-area or the increased service availability as other CN nodes may provide services in case one CN node in the pool-area fails.

Iu Signalling Link Management Support

Support for Iu signal link management function for HNB-GW in accordance with the following standards:

- 3GPP TS 25.412 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface signalling transport (Release 8)
- 3GPP TS 25.413 V7.9.0 (2008-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signalling (Release 7)
- 3GPP TS 25.414 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signalling (Release 9)

HNBGW supports RANAP protocol for management of IuPS/IuCS connections. The IU connection on the IuPS/IuCS interface is realized using an SCCP connection towards SGSN/MSC. The SCCP could be over SIGTRAN or ATM.

IuH User-Plane Transport Bearer Handling Support

Support for transfer of CS as well as PS data over IP on the IuH interface:

- 3GPP TS 25.467 V8.0.0. (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home NodeB; Stage 2 (Release 8)

HNB-GW supports GTP-U v1 for PS traffic transport and RTP/RTCP for CS traffic transport on IuH interface. HNB-GW terminates the GTPU tunnels and RTP sessions at itself for each tunnel/session between CN and HNB.

Multiple HNB-GW Service Support

Support for multiple HNB-GW service on same chassis in one or multiple context is provided with this feature support.

With support of mulitple HNB-GW service on same chassis operator can utilize the various combination of subscriber access network and connectivity model.
This feature can also be utilized if operator wants to use specific HNB-GW services for residential and enterprise service on the same chasiss.
Figure 3. Multiple HNB-GW Service on Single Chassis

In order to associate multiple HNB-GW services with the same CS/PS network and to associate a particular HNB-GW service with more than one CS/PS network a dynamic association procedure is supported.

A unique logical RNC represents each CS/PS network on chassis and is assigned an RNC-ID as global RNC id.

When RUA Connect Request is received at HNB-GW, CS/PS network is selected based on values of mcc, mnc and rnc-id configured in radio network plmn of HNB-GW service and in CS/PS network.

Multiple HNB-GW services in the same context can share the same RTP Pool however a single GTP-U Service cannot be shared among multiple HNB-GW Services. Similarly, multiple PS networks cannot share a single GTP-U service but multiple CS networks can share the same RTP Pool and ALCAP Service.

IMPORTANT:

For more information on multiple HNB-GW service configuration, refer HNB-GW Administration Guide.

Multiple MSC Selection without Iu-Flex

Support for multiple MSC selection in a CS core network is provided with this feature support.

HNBGW can connect to multiple MSC and SGSN through Iu-Flex or LAC mapping. This feature implements the multiple MSC selection using LAC.

For this support the HNB-GW uses HNB's LAC, received during registration procedure in HNB_REGISTER_REQUEST message, to distribute RANAP-Initial UE message to an MSC. It maps the LAC with MSC point code and a set of LACs configured for each MSC, connected to the HNB-GW.
In the HNBGW, to select an MSC based on the LAC the following algorithm is used:

- If both Iu-Flex and LACs are configured for a MSC, then Iu-Flex is used to select a MSC.
- If only Iu-Flex is configured then Iu-Flex is used for selecting MSC.
- If only LACs are configured then MSC is selected using LAC from HNB.
- If both Iu-Flex and LACs are not configured in the HNBGW, it selects default MSC.

Network Access Control Functions through SeGW

These functions enable secure user and device level authentication between the authenticator component of the HNB-GW and a 3GPP HSS/AuC and RADIUS-based AAA interface support.
This section describes following features:

- Authentication and Key Agreement (AKA)
- 3GPP AAA Server Support
- X.509 Certificate-based Authentication Support

Authentication and Key Agreement (AKA)

HNB-GW provides Authentication and Key Agreement mechanism for user authentication procedure over the HNB Access Network. The Authentication and Key Agreement (AKA) mechanism performs authentication and session key distribution in networks. AKA is a challenge- response based mechanism that uses symmetric cryptography.

The AKA is the procedure that take between the user and network to authenticate themselves towards each other and to provide other security features such as integrity and confidentiality protection.
In a logical order this follows the following procedure:

1. Authentication: Performs authentication by, identifying the user to the network; and identifying the network to the user.
2. Key agreement: Performs key agreement by, generating the cipher key; and generating the integrity key.
3. Protection: When the AKA procedure is performed it protects, the integrity of messages; confidentiality of signalling data; and confidentiality of user data

3GPP AAA Server Support

This interface between the SeGW and AAA Server provides a secure connection carrying authentication, authorization, and related information. in accordance with the following standards:

- 3GPP TS 33.320 V9.1.0 (2010-03): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security of Home Node B (HNB) / Home evolved Node B (HeNB) (Release 9)

This reference point is located between 3GPP AAA Server/Proxy and HNB-GW. The functionality of this reference point is to enable following requirements on SeGW:

- The SeGW shall be authenticated by the HNB using a SeGW certificate.
- The SeGW shall authenticate the HNB based on HNB certificate.
- The SeGW authenticates the hosting party of the HNB in cooperation with the AAA server using EAP-AKA.
- The SeGW shall allow the HNB access to the core network only after successful completion of all required authentications.
- Any unauthenticated traffic from the HNB shall be filtered out at the SeGW

X.509 Certificate-based Authentication Support

HNB-GW supports X.509 Certificate-based authentication to HNB/UE for a public key infrastructure (PKI) for single sign-on (SSO) and Privilege Management Infrastructure (PMI). X.509 specifies the standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.

Open Access Mode Support

An Open HNB provides its services to any mobile subscriber in Femto network. This feature is intended to provide Open access mode support on an UMTS HNB-GW. Open access HNBs can be deployed in public places like airports to increase the indoor coverage or to offload the traffic from the macro cell.
This feature provides following procedure for Open Access HNB registration on HNB-GW:

- OPEN HNB registration: On receiving HNB-REGISTER-REQ from HNB, HNB-GW sends RADIUS-Access-Request to AAA-server. HNB-GW will not care whether HNB has sent cell-access-mode in the register request or not. AAA-server performs authentication and authorization. If this is successful AAA-server sends RADIUS-Access-Accept to HNB-GW. Then AAA-server includes the Whitelist attribute in the response. AAA-server prepare Whitelist attribute in the following manner: Cell-access-mode field in the Whitelist attribute will be set to “Open”. Number-of-IMSIs field in the Whitelist attribute will be set to 0 (zero). IMSIs will not be included in the Whitelist attribute. HNB-GW overrides the cell-access-mode value received from HNB by the one received from AAA-server. HNB-GW discards “IMSI List” received for an Open Access-mode HNB from AAA-server in Access-Accept or COA message. AAA server sends access-mode as 0 (Closed mode) or 1 (Hybrid mode) or 2 (Open mode). If it sends any other value in Access-Accept, then HNB-GW shall send HNB-REGISTER-REJECT with Unauthorised-HNB cause.

  IMPORTANT:

  HNB-GW support both “Open” mode and “Closed” mode HNBs simultaneously. In case HNB registration is disabled the HNB-GW sends HNB-REGISTER-REJECT with O&M Intervention cause.
- UE registration: HNB-GW does not perform access control check of any UE registration request received from an Open Access-mode HNB. HNB-GW also does not perform any check on the UE-identity received in the registration request from an Open Access mode HNB.
- RUA Connect: HNB-GW does not check IMSI received in RANAP-CommonId if the same was not received from HNB in UE-REGISTER-REQ.
- Paging: Paging received without paging-area is sent to all Open HNBs. CS Paging received with paging-area is sent to those Open HNBs whose LAC (received in HNB-REG-REQ) matches with the one received in paging message. PS Paging received with paging-area is sent to those Open HNBs whose LAC and RAC (received in HNB-REG-REQ) matches with those received in paging message. If sending paging towards open HNBs is disabled the paging with or without paging-area will not be sent to any Open HNB.

On receiving a relocation request, relocation proceeds only if target Closed HNB is found. If UE is currently registered via Open HNB, then that registration will be cleaned up.

IMPORTANT:

For more information on Open Access Mode support configuration, refer Open Access Mode Configuration section of HNB-GW Administration Guide.

QoS Management with DSCP Marking

Differentiated Services Code Point (DSCP) marking over IuH interface support in 3G UMTS HNB Access Network is provided on HNB-GW for traffic quality management in accordance with following standards:

- 3GPP TS 25.414 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signalling (Release 9)
- 3GPP TS 25.468 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)
- 3GPP TS 25.469 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B (HNB) Application Part (HNBAP) signalling (Release 9)
- IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
- IETF RFC 4594, Configuration Guidelines for DiffServ Service Classes
- IETF RFC 4960, Stream Control Transmission Protocol

In a fixed line-mobile convergence scenario, the user data and signaling traffic from a UE is forwarded by an HNB to HNB-GW over IuH interface. IP is used as network layer for IuH. RTP/ RTCP or GTP over UDP/IP form transport for user data. SCTP/IP is used for control signaling over IuH.

These data and control packets traverse public Internet before reaching HNB-GW and vice-a-versa for the downlink traffic. RTP typically carries jitter-sensitive real-time media data such as voice and video. RTCP carries media reception/ transmit feedback that is not delay sensitive. GTP carries generic, non-media data. These various traffic types, each, deserve different QoS handling by the IP nodes they traverse between HNB and HNB-GW. Thus DSCP codes are assigned in the IP headers of the traffic such that intermediate IP nodes can provide differentiated QoS treatment to the traffic for an acceptable end-user experience.

HNB-GW supports DSCP marking of the traffic on IuH and Iu interface for downlink traffic towards HNB and for uplink traffic towards CN when IP transport is used for IuCS or IuPS.

IMPORTANT:

For more information on DSCP marking configuration, refer DSCP Marking Configuration section of HNB-GW Administration Guide.

RADIUS Support

In HNB-GW the RADIUS support provides a mechanism for performing authorization and authentication for subscriber sessions based on the following standards:

- RFC-2618, RADIUS Authentication Client MIB, June 1999
- RFC-2620, RADIUS Accounting Client MIB, June 1999
- RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000
- RFC-2866, RADIUS Accounting, June 2000
- RFC-2867, RADIUS Accounting Modifications for Tunnel Protocol Support, June 2000
- RFC-2868, RADIUS Attributes for Tunnel Protocol Support, June 2000
- RFC-2869, RADIUS Extensions, June 2000

Within context configured on the system, there are AAA and RADIUS protocol-specific parameters that can be configured. The RADIUS protocol-specific parameters are further differentiated between RADIUS Authentication server RADIUS Accounting server interaction.

Among the RADIUS parameters that can be configured are:

- Priority: Dictates the order in which the servers are used allowing for multiple servers to be configured in a single context.
- Routing Algorithm: Dictate the method for selecting among configured servers. The specified algorithm dictates how the system distributes AAA messages across the configured AAA servers for new sessions. Once a session is established and an AAA server has been selected, all subsequent AAA messages for the session will be delivered to the same server.

In the event that a single server becomes unreachable, the system attempts to communicate with the other servers that are configured. The system also provides configurable parameters that specify how it should behave should all of the RADIUS AAA servers become unreachable.

IMPORTANT:

For more information on RADIUS AAA configuration, if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.

UE Management Function for Pre-Rel-8 UEs

Support for Pre-Rel-8 UE registration and de-registration in 3G UMTS HNB Access Network in accordance with the following standards:

- 3GPP TS 25.467 V8.0.0. (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home NodeB; Stage 2 (Release 8)
- 3GPP TS 25.469 V8.1.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 8)
- IETF RFC 4960, Stream Control Transmission Protocol, December 2007

The HNB-GW provides UE registration and de-registration procedure for the HNB to convey pre-Rel-8 UE identification data to the HNB-GW in order to perform access control for the UE in the HNB-GW. The UE Registration also establishes a UE specific context identifier to be used between HNB and HNB-GW. The procedure triggered when the UE attempts to access the HNB via an initial NAS message and there is no context in the HNB allocated for that UE.

System Management Features

This section describes following features:

- Management System Overview
- Bulk Statistics Support
- Threshold Crossing Alerts (TCA) Support
- ANSI T1.276 Compliance

Management System Overview

The system's management capabilities are designed around the Telecommunications Management Network (TMN) model for management - focusing on providing superior quality network element (NE) and element management system (Web Element Manager) functions. The system provides element management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems - giving wireless operators the ability to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.
Operation and Maintenance module of chassis offers comprehensive management capabilities to the operators and enables them to operate the system more efficiently. There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces. These include:

- Using the command line interface (CLI)
- Remote login using Telnet, and Secure Shell (SSH) access to CLI through SPIO card's Ethernet management interfaces
- Local login through the Console port on SPIO card using an RS-232 serial connection
- Using the Web Element Manager application
- Supports communications through 10 Base-T, 100 Base-TX, 1000 Base-TX, or 1000
- Base-SX (optical gigabit Ethernet) Ethernet management interfaces on the SPIO
- Client-Server model supports any browser (i.e. Microsoft Internet Explorer v5.0 and above or Netscape v4.7 or above, and others)
- Supports Common Object Request Broker Architecture (CORBA) protocol and Simple Network Management Protocol version 1 (SNMPv1) for fault management
- Provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) capabilities
- Can be easily integrated with higher-level network, service, and business layer applications using the Object Management Group's (OMG’s) Interface Definition Language (IDL)

The following figure demonstrates these various element management options and how they can be utilized within the wireless carrier network.
Figure 4. Element Management System

IMPORTANT:

HNB-GW management functionality is enabled for console-based access by default. For GUI-based management support, refer WEM Installation and Administration Guide.

IMPORTANT:

For more information on command line interface based management, refer Command Line Interface Reference.

Bulk Statistics Support

The system's support for bulk statistics allows operators to choose to view not only statistics that are of importance to them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.

When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.
The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. Following is a partial list of supported schemas:

- System: Provides system-level statistics
- Card: Provides card-level statistics
- Port: Provides port-level statistics
- GTP-U: Provides GPRS Tunneling Protocol - User message statistics
- HNB-AAL2: Provides ATM adaptation layer 2 (AAL2) protocol level-statistics
- HNB-ALCAP: Provides Access Link Control Application Part (ALCAP) service-level statistics
- CS-Network-RANAP: Provides RANAP-level statistics for HNB-CS network
- CS-Network-RTP: Provides RTP protocol-level statistics for HNB-CS network
- HNB-GW-HNBAP: Provides HNBAP-level statistics for HNB-GW service
- HNB-GW-HNBAP-ACCESS-CLOSED: Provides HNBAP-level statistics filtered for HNBs registered for Closed access mode with HNB-GW service
- HNB-GW-HNBAP-ACCESS-HYBRID: Provides HNBAP-level statistics filtered for HNBs registered for Hybrid access mode with HNB-GW service
- HNB-GW-HNBAP-ACCESS-OPEN: Provides HNBAP-level statistics filtered for HNBs registered for Open access mode with HNB-GW service
- HNB-GW-RANAP: Provides RANAP-level statistics for HNB-GW service
- HNB-GW-RANAP-ACCESS-CLOSED: Provides RANAP-level statistics filtered for HNBs registered for Closed access mode with HNB-GW service
- HNB-GW-RANAP-ACCESS-HYBRID: Provides RANAP-level statistics filtered for HNBs registered for Hybrid access mode with HNB-GW service
- HNB-GW-RANAP-ACCESS-OPEN: Provides RANAP-level statistics filtered for HNBs registered for Open access mode with HNB-GW service
- HNB-GW-RTP: Provides RTP protocol-level statistics for HNB-GW service
- HNB-GW-RUA: Provides RUA protocol-level statistics for HNB-GW service
- HNB-GW-RUA-ACCESS-CLOSED: Provides RUA protocol-level statistics filtered for HNBs registered for Closed access mode with HNB-GW service
- HNB-GW-RUA-ACCESS-HYBRID: Provides RUA protocol-level statistics filtered for HNBs registered for Hybrid access mode with HNB-GW service
- HNB-GW-RUA-ACCESS-OPEN: Provides RUA protocol-level statistics filtered for HNBs registered for Open access mode with HNB-GW service
- HNB-GW-SCTP: Provides HNB -SCTP protocol-level statistics
- PS-Network--RANAP: Provides RANAP-level statistics for HNB-PS network
- SCCP: Provides SCCP service-level statistics at system-level
- SS7Link: Provides SS7 link configuration related statistics at system-level
- SS7 Routing Domain: Provides SS7 Routing domain configuration related statistics at system level

The system supports the configuration of up to 4 sets (primary/secondary) of receivers. Each set can be configured with to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the IMG or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.

The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, IMG host name, IMG uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.

When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.

The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a Northbound NMS or an alternate bulk statistics server for further processing.

Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.

Threshold Crossing Alerts (TCA) Support

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage. Typically, these conditions are temporary (i.e high CPU utilization, or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.

The system supports Threshold Crossing Alerts for certain key resources such as CPU, memory, number of sessions etc. With this capability, the operator can configure threshold on these resources whereby, should the resource depletion cross the configured threshold, a SNMP Trap would be sent.
The following thresholding models are supported by the system:

- Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.
- Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

Thresholding reports conditions using one of the following mechanisms:

- SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.
- Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.Logs are supported in both the Alert and the Alarm models.
- Alarm System: High threshold alarms generated within the specified polling interval are considered “outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding” alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.The Alarm System is used only in conjunction with the Alarm model.

IMPORTANT:

For more information on threshold crossing alert configuration, refer Thresholding Configuration Guide.

ANSI T1.276 Compliance

ANSI T1.276 specifies security measures for Network Elements (NE). In particular it specifies guidelines for password strength, storage, and maintenance security measures.
ANSI T1.276 specifies several measures for password security. These measures include:

- Password strength guidelines
- Password storage guidelines for network elements
- Password maintenance, e.g. periodic forced password changes

These measures are applicable to the systems and the Web Element Manager since both require password authentication. A subset of these guidelines where applicable to each platform will be implemented. A known subset of guidelines, such as certificate authentication, are not applicable to either product. Furthermore, the platforms support a variety of authentication methods such as RADIUS and SSH which are dependent on external elements. ANSI T1.276 compliance in such cases will be the domain of the external element. ANSI T1.276 guidelines will only be implemented for locally configured operators.

Features and Functionality - Optional Enhanced Feature Software

This section describes the optional enhanced features and functions support with HNB-GW service.

IMPORTANT:

Some of the following features may require the purchase of an additional license to implement the functionality with the HNB-GW service.

This section describes following features:

- Dynamic RADIUS Extensions (Change of Authorization)
- IP Security (IPSec)
- Session Recovery
- Web Element Management System

Dynamic RADIUS Extensions (Change of Authorization)

Dynamic RADIUS extension support provide operators with greater control over subscriber PDP contexts by providing the ability to dynamically redirect data traffic, and or disconnect the PDP context.

This functionality is based on the RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), July 2003 standard.
The system supports the configuration and use of the following dynamic RADIUS extensions:

- Change of Authorization: The system supports CoA messages from the AAA server to change data filters associated with a subscriber session. The CoA request message from the AAA server must contain attributes to identify NAS and the subscriber session and a data filter ID for the data filter to apply to the subscriber session.
- Disconnect Message: The DM message is used to disconnect subscriber sessions in the system from a RADIUS server. The DM request message should contain necessary attributes to identify the subscriber session.

The above extensions can be used to dynamically re-direct subscriber PDP contexts to an alternate address for performing functions such as provisioning and/or account set up. This functionality is referred to as Session Redirection, or Hotlining.

Session redirection provides a means to redirect subscriber traffic to an external server by applying ACL rules to the traffic of an existing or a new subscriber session. The destination address and optionally the destination port of TCP/IP or UDP/IP packets from the subscriber are rewritten so the packet is forwarded to the designated redirected address.

Return traffic to the subscriber has the source address and port rewritten to the original values. The redirect ACL may be applied dynamically by means of the Radius Change of Authorization (CoA) extension.

IMPORTANT:

For more information on dynamic RADIUS extensions support, refer CoA, RADIUS, And Session Redirection (Hotlining) in this guide.

IP Security (IPSec)

IP Security provides a mechanism for establishing secure tunnels from mobile subscribers to pre-defined endpoints (i.e. enterprise or home networks) in accordance with the following standards:

- RFC 2401, Security Architecture for the Internet Protocol
- RFC 2402, IP Authentication Header (AH)
- RFC 2406, IP Encapsulating Security Payload (ESP)
- RFC 2409, The Internet Key Exchange (IKE)
- RFC-3193, Securing L2TP using IPSEC, November 2001

IP Security (IPSec) is a suite of protocols that interact with one another to provide secure private communications across IP networks. These protocols allow the system to establish and maintain secure tunnels with peer security gateways.

IPSec tunnel supports AAA and DHCP address overlapping. Address overlapping is meant for multiple customers using the same IP address for AAA/DHCP servers. The AAA and DHCP control messages are sent over IPSec tunnels and AAA/DHCP packets required to be encrypted are decided as per the ACL configuration done for specific session.

IMPORTANT:

For more information on IPSec configuration, refer HNB-GW Service Configuration section.

Session Recovery

The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.

Session recovery is performed by mirroring key software processes (e.g. session manager and AAA manager) within the system. These mirrored processes remain in an idle state (in standby-mode), wherein they perform no processing, until they may be needed in the case of a software failure (e.g. a session manager task aborts). The system spawns new instances of “standby mode” session and AAA managers for each active Control Processor (CP) being used.

Additionally, other key system-level software tasks, such as VPN manager, are performed on a physically separate packet processing card to ensure that a double software fault (e.g. session manager and VPN manager fails at same time on same card) cannot occur. The packet processing card used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.

The additional hardware resources required for session recovery include a standby System Processor Card (SPC) and a standby packet processing card.

There are two modes for Session Recovery.

- Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby packet processing card. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active packet processing cards. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager.
- Full packet processing card recovery mode: Used when a packet processing card hardware failure occurs, or when a packet processing card migration failure happens. In this mode, the standby packet processing card is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet processing card perform session recovery.

Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different packet processing cards to ensure task recovery.

IMPORTANT:

For more information on this feature, refer Session Recovery chapter in System Administration Guide.

Web Element Management System

Provides a Graphical User Interface (GUI) for performing Fault, Configuration, Accounting, Performance, and Security (FCAPS) management of the system.

The Web Element Manager is a Common Object Request Broker Architecture (CORBA)-based application that provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) management capability for the system.

For maximum flexibility and scalability, the Web Element Manager application implements a client-server architecture. This architecture allows remote clients with Java-enabled web browsers to manage one or more systems via the server component which implements the CORBA interfaces. The server component is fully compatible with the fault-tolerant Sun® Solaris® operating system.
The following figure demonstrates various interfaces between the Cisco Web Element Manager and other network components.
Figure 5. Web Element Manager Network Interfaces

IMPORTANT:

For more information on WEM support, refer WEM Installation and Administration Guide.

How HNB-GW Works

This section provides information on the function and procedures of the HNB-GW in a wireless network and presents message flows for different stages of session setup.
The following procedures are supported in this release:

- HNB Provisioning and Registration Procedure
- UE Registration Procedure
- Iu Connection Procedures
- Paging and Serving RNS Relocation Procedures
- RANAP Reset Procedures

HNB Provisioning and Registration Procedure

This section describes the call flow for HNB provisioning and registration procedure.
The following figure and the text that follows describe the message flow for HNB provisioning and registration with HNB-GW procedure.
Figure 6. HNB Provisioning and Registration Setup Call Flow

1. HNB initialization is performed to obtain HNB configuration from the HNB Management System (HMS). Similarly, HNB-GW discovery is performed to obtain the initial serving HNB-GW information.
2. A secure tunnel is established from the HNB to the Security Gateway.
3. Location verification shall be performed by the HMS based on information sent by the HNB (e.g. macro neighbor cell scans, global navigational satellite system type of information etc.). HMS determines the serving elements and provides the HNB-GW, HMS and Security Gateway to the HNB. The HMS also provisions configuration parameters to the HNB only after successful location verification in the HMS.
4. Reliable transport setup (SCTP) completed and the HNB sets up a SCTP transport session to a well-defined port on the serving HNB-GW. HNB Registration procedure started.
5. The HNB attempts to register with the serving HNB-GW using a HNB-REGISTER-REQUEST message. This message may contains: HNB Location Information: The HNB provides location information via use of one or more of the following mechanisms: detected macro coverage information (e.g. GERAN and/or UMTS cell information) geographical co-ordinates (e.g. via use of GPS, etc) Internet connectivity information (e.g. IP address). HNB Identity: the HNB has a globally unique and permanent identity. HNB Operating Parameters: Such as the selected LAC, RAC, SAC, etc.
6. The HNB-GW uses the information from the HNB-REGISTER-REQUEST message to perform access control of the HNB (e.g. whether a particular HNB is allowed to operate in a given location, etc). If the HNB-GW accepts the registration attempt the PLMN-ID received in the request shall be used to lookup the PLMN to RNC id mapping table and corresponding RNC-ID shall be returned in the HNB-REGISTER-ACCEPT message else the HNB-GW may reject the registration request (e.g. due to network congestion, blacklisted HNB, unauthorized HNB location, etc). In reject case, the HNB-GW shall respond with a HNB-REGISTER-REJECT indicating the reject cause.

IMPORTANT:

The HNB shall start broadcasting only after successful registration with the HNB-GW.

UE Registration Procedure

This section describes the UE registration procedures for HNB provides means for the HNB to convey UE identification data to the HNB-GW in order to perform access control for the UE in the HNB GW. The UE Registration also informs the HNB-GW of the specific HNB where the UE is located.

The UE registration procedure generally triggers when the UE attempts to access the HNB through an initial NAS message and there is no context id in the HNB for specific UE.
UE Registration procedure is described for following scenarios:

- UE Registration Procedure of Non-CSG UEs or Non-CSG HNBs

UE Registration Procedure of Non-CSG UEs or Non-CSG HNBs

This procedure is applicable for non-CSG UEs or HNBs.
The following figure and the text that follows describe the message flow for UE registration procedure of Non-CSG UEs or Non-CSG HNBs:
Figure 7. UE Registration Call Flow for Non-CSG UEs or Non-CSG HNBs

1. Upon camping on the HNB, the UE initiates an initial NAS procedure (e.g. LU Procedure) by establishing an RRC connection with the HNB. UE capabilities are reported to the HNB as part of the RRC Connection establishment procedure.
2. The UE then transmits a RRC Initial Direct Transfer message carrying the initial NAS message (e.g. Location Updating Request message) with identity (IMSI or TMSI).
3. The HNB checks UE capabilities provided in step 1, if these indicate that CSG is not supported and if the identity of the UE (provided during RRC Connection Establishment) is unknown at the HNB being accessed, i.e. no Context id exists for the UE, the HNB initiates UE registration towards HNB-GW (step 6-8).
4. Before starting the UE Registration procedure, HNB optionally triggers the Identification procedure asking for the UE IMSI, if such identity is not provided during the RRC Connection Establishment. If the HNB has a context id for the UE, the UE registration procedure is not performed nor the Identification procedure.
5. The HNB may optionally perform access control based on IMSI and provided access control list.
6. The HNB attempts to register the UE on the HNB-GW by transmitting the UE-REGISTER-REQUEST. The message contains at a minimum: UE Identity: IMSI of the (U)SIM associated with the UE and the indication about UE capabilities provided in step 1.The UE IMSI provided in the UE-REGISTER message is unauthenticated.
7. The HNB-GW checks UE capabilities and if these indicate that CSG is not supported the HNB-GW shall perform access control for the particular UE attempting to utilize the specific HNB.
8. If the HNB-GW accepts the UE registration attempt it shall allocate a context-id for the UE and respond with a UE-REGISTER-ACCEPT message, including the context-id, to the HNB. If the HNB-GW chooses to not accept the incoming UE registration request then the HNB-GW shall respond with a UE-REGISTRATION-REJECT message.
9. The HNB then sends a RUA (RANAP User Adaptation) CONNECT message containing the RANAP Initial UE message to HNB-GW.
10. The reception of the RUA CONNECT message at the HNB-GW triggers the setup of SCCP connection by the HNB-GW towards the CN. HNB-GW forwards the Initial UE Message to CN.
11. The CN response with a SCCP Connection Confirm message to HNB-GW.
12. The UE then continue with the NAS procedure (e.g. Location Updating procedure) towards the CN, via HNB and the HNB-GW.

Iu Connection Procedures

This section describes call flow for Iu connection procedures on HNB-GW.
Following procedure call flows are described for Iu connection procedures between HNB, HNB-GW, and SGSN/MSC in core network:

- Iu Connection Establishment Procedure
- Network Initiated Iu Connection Release Procedure

Iu Connection Establishment Procedure

This procedure is applicable for establishment of IuH and IuPS/IuCS connection between HNB to HNB-GW and HNB-GW to SGSN/MSC in core network.
The following figure and the text that follows describe the message flow for an Iu connection establishment procedure.
Figure 8. Iu Connection Establishment Call Flow

1. Upon receiving of UE-REGISTER-ACCEPT message from HNB-GW, the HNB then sends a RUA CONNECT message to HNB-GW containing the RANAP Initial UE message.
2. The reception of the RUA CONNECT message at the HNB-GW triggers the setup of SCCP connection by the HNB-GW towards the CN (SGSN/MSC). HNB-GW forwards the Initial UE Message.
3. The CN responses with a SCCP Connection Confirm message.
4. The UE then continue with the authentication and security procedures towards the CN, via HNB and the HNB-GW.
5. The SGSN/MSC performs Direct Transfer procedure with HNB-GW and sends SCCP-DATA-FORM1 REQ to HNB-GW.
6. The HNB-GW uses the information received in Direct Transfer procedure from CN and forwards the same to HNB through RUA-DIRECT-TRANSFER message.
7. On successful acceptance of RUA-DIRECT-TRANSFER message the HNB responds to HNB-GW and sends RUA-DIRECT-TRANSFER Response message to HNB-GW.
8. On reception of successful acceptance of RUA-DIRECT-TRANSFER message from HNB, the HNB-GW sends SCCP-DATA-FORM1 (Direct Transfer) Response message to CN (SGSN/MSC). This completes the establishment of IuH and IuPS/IuCS connection through HNB, HNB-GW, and SGSN/MSC in core network.

Network Initiated Iu Connection Release Procedure

This procedure is applicable for release of IuH and IuPS/IuCS connection between HNB to HNB-GW and HNB-GW to SGSN/MSC in core network.
The following figure and the text that follows describe the message flow for an Iu connection release procedure initiated by CN (SGSN/MSC).
Figure 9. Network Initiated Iu Connection Release Call Flow

1. User session is established between UE and CN via HNB and HNB-GW over Iu interface and CN (SGSN/MSC) starts RANAP Iu Release procedure with HNB-GW and sends SCCP-DATA-FORM1 REQ with RANAP Iu Release command to HNB-GW.
2. The HNB-GW uses the information received in SCCP-DATA-FORM1 REQ with RANAP Iu Release procedure from CN and forwards the same to HNB through RUA-DIRECT-TRANSFER message with RANAP Iu Release command.
3. On reception of RANAP Iu Release command in RUA-DIRECT-TRANSFER message the HNB triggers the RCC Connection Release procedure and responds to HNB-GW with RANAP Iu Release Complete command in RUA-DISCONNECT Response message.
4. On reception of successful RANAP Iu Release Complete command in RUA-DISCONNECT Response message from HNB, the HNB-GW sends RANAP Iu Release Complete command in SCCP-DATA-FORM1 Response message to CN (SGSN/MSC).
5. On reception of RANAP Iu Release Complete command in SCCP-DATA-FORM1 Response message from HNB-GW, CN sends SCCP-RELEASED message to HNB-GW and triggers the associated SCCP connection. On reception of SCCP-RELEASED message from CN, the HNB-GW sends RUA-DISCONNECT message to HNB and disconnect the IuH connection with HNB.
6. After successful completion of RUA-DISCONNECT procedure and IuH connection release, HNB-GW sends SCCP-RELEASE-COMPLETE message to CN and HNB-GW confirms the IuPS/IuCS connection released between HNB-GW and CN.

Paging and Serving RNS Relocation Procedures

This section describes the call flow for network-initiated paging and SRNS relocation procedures on HNB-GW.
Following procedure call flows are described for Paging and SRNS relocation procedures between HNB, HNB-GW, and SGSN/MSC in core network:

- Paging Procedure
- SRNS Relocation Procedure

Paging Procedure

This procedure is applicable for establishment of IuH and IuPS/IuCS connection between HNB to HNB-GW and HNB-GW to SGSN/MSC in core network.
The following text describes the call flow for Paging procedure on HNB-GW:

1. HNB-GW receives Paging from SGSN/MSC. HNB-GW finds out if any UE is registered with that IMSI.
2. If a UE is registered then HNB-GW sends the Paging message to the HNB through which the UE is registered.
3. If no registered UE is found then HNB-GW finds out the list of HNBs which have IMSI received in the message in their respective Whitelist.
4. If one or more HNBs were found, and Paging message contained LAI, then HNB-GW compares the HNB’s PLMN-ID and LAC values against LAI received in the Paging. The HNB which do not have matching values is dropped from this list.
5. If one or more HNBs were found, and Paging message contained RAI, then HNB-GW compares the HNB’s PLMN-ID, LAC and RAC values against RAI received in the Paging. The HNB which do not have matching values is dropped from this list.
6. If Paging message did not have Paging-area then list of HNBs is same as what was found in step 1 otherwise list of HNBs is as found in step 2 or step 3.If this list is empty then Paging message is dropped. Otherwise HNB-GW sends Paging message to these HNBs.

SRNS Relocation Procedure

This procedure is applicable for intra-CN or inter-CN handover procedure between HNB to HNB-GW and HNB-GW to SGSN/MSC in core network.
The following text describes the call flow for SRNS relocation procedure on HNB-GW:

1. HNB-GW receives Relocation-Request from SGSN/MSC in case subscriber moves from Macrocell to Femtocell in a connected mode.
2. If the request does not contain IMSI (i.e. for an emergency call), HNB-GW sends Relocation-Request-Reject with an appropriate cause.
3. . If the request contains IMSI, HNB-GW finds the list of registered HNBs which have this IMSI in their white-list. If there is no such HNB found, HNB-GW sends Relocation-Request-Reject with appropriate cause.
4. If there is only one such HNB found which has this IMSI in its white-list, HNB-GW sends Relocation-Request to this HNB.
5. If there are more than one such HNBs found which have this IMSI in their whitelist, then HNBGW looks for Home-HNB for this IMSI. If there are more than one Home-HNB found then HNB-GW sends Relocation-Request-Reject with appropriate cause.
6. If there are multiple HNBs registered which have this IMSI in their whitelist but only one Home-HNB found, HNBGW sends Relocation-Request to this HNB.

RANAP Reset Procedures

This section describes the call flow for various RANAP Reset procedures supported in HNB-GW.
Following procedure call flows are described for RANAP Reset procedures between HNB, HNB-GW, and SGSN/MSC in core network:

- HNB Initiated RANAP Reset Procedure
- CN Initiated RANAP Reset Procedure
- HNB-GW Initiated RANAP Reset Procedure

HNB Initiated RANAP Reset Procedure

This procedure is applicable for HNB-initiated RANAP Reset procedure between HNB, HNB-GW, and SGSN/MSC in core network.
The following text describes the call flow for HNB-initiated RANAP Reset procedure:

1. HNB sends RANAP-RESET command message to HNB-GW for a session.
2. HNB-GW identifies the all affected Iu connection for particular HNB and sends RESET-ACK message to HNB.
3. HNB-GW sends SCCP_Released (SCCP-RLSD) message to CN to release the SCCP connection for each affected Iu connection for particular HNB.
4. CN (SGSN/MSC) sends the SCCP_Release_Complete (SCCP-RLC) message to HNB-GW and release the SCCP connection for requested HNB.

CN Initiated RANAP Reset Procedure

This procedure is applicable for HNB-initiated RANAP Reset procedure between HNB, HNB-GW, and SGSN/MSC in core network.
The following text describes the call flow for HNB-initiated RANAP Reset procedure:

1. CN (SGSN/MSC) sends RANAP-RESET command message to HNB-GW for a session.
2. On receiving RANAP-RESET from CN, the HNB-GW starts Guard timer for configured timeout duration.
3. HNB-GW identifies the all affected Iu connections and sends RUA-DISCONNECT message to HNB.
4. On expiry of Guard timer the HNB-GW sends the RESET-ACK message to CN.

HNB-GW Initiated RANAP Reset Procedure

This procedure is applicable for HNB-GW-initiated RANAP Reset procedure between HNB, HNB-GW, and SGSN/MSC in core network.
The HNB-GW initiates RESET towards CN node in following scenarios:

- The HNB-GW is reloaded or service restarted and SCCP Subsystem Number (SSN) allowed from CN (SGSN/MSC) node is received.
- The received SSN Prohibited or Point-code Address Inaccessible indication comes for a CN node, HNB-GW start a configurable timer. If SSN allowed indication comes before timer expires, the timer is stopped. On timer expiry HNB-GW deletes all SCCP connections towards the CN node. If SSN Allowed indication comes after timer expiry, HNB-GW sends RANAP-RESET command message to the CN node.

The RANAP-RESET from HNB-GW is sent only if HNB-GW-initiated RANAP-RESET is configured in HNB-GW service.

Supported Standards

The HNB-GW complies with the following standards for 3G UMTS Femto wireless data services.

- 3GPP References
- IETF References
- ITU-T Recommendations
- Object Management Group (OMG) Standards

3GPP References

- 3GPP TS 23.003 V8.9.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 8)
- 3GPP TS 25.412 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface signalling transport (Release 8)
- 3GPP TS 25.413 V7.9.0 (2008-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signalling (Release 7)
- 3GPP TS 25.414 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signalling (Release 9)
- 3GPP TS 25.415 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface user plane protocols (Release 8)
- 3GPP TS 25.467 V8.0.0. (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home NodeB; Stage 2 (Release 8)
- 3GPP TS 25.467 V9.1.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)
- 3GPP TS 25.467 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 9)
- 3GPP TS 25.468 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN IuH Interface RANAP User Adaptation (RUA) signalling (Release 8)
- 3GPP TS 25.468 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)
- 3GPP TS 25.468 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh Interface RANAP User Adaptation (RUA) signalling (Release 9)
- 3GPP TS 25.469 V8.1.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 8)
- 3GPP TS 25.469 V9.0.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 9)
- 3GPP TS 25.469 V9.2.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iuh interface Home Node B (HNB) Application Part (HNBAP) signalling (Release 9)
- 3GPP TS 29.060 V9.0.0 (2009-09): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 9)
- 3GPP TR 29.814 V7.1.0 (2007-06): 3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals Feasibility Study on Bandwidth Savings at Nb Interface with IP transport (Release 7)
- 3GPP TS 33.320 V9.1.0 (2010-13): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security of Home Node B (HNB) / Home evolved Node B (HeNB) (Release 9)
- 3GPP TS 23.236 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Intra-domain connection of Radio Access Network(RAN) nodes to multiple Core Network(CN) nodes (Release 8)

IETF References

- RFC-768, User Datagram Protocol (UPD), August 1980
- RFC-791, Internet Protocol (IP), September 1982
- RFC-793, Transmission Control Protocol (TCP), September 1981
- RFC-894, A Standard for the Transmission of IP Datagrams over Ethernet Networks, April 1984
- RFC-1089, SNMP over Ethernet, February 1989
- RFC-1144, Compressing TCP/IP headers for low-speed serial links, February 1990
- RFC-1155, Structure & identification of management information for TCP/IP-based internets, May 1990
- RFC-1157, Simple Network Management Protocol (SNMP) Version 1, May 1990
- RFC-1212, Concise MIB Definitions, March 1991
- RFC-1213, Management Information Base for Network Management of TCP/IP-based Internets: MIB-II, March 1991
- RFC-1215, A Convention for Defining Traps for use with the SNMP, March 1991
- RFC-1224, Techniques for managing asynchronously generated alerts, May 1991
- RFC-1256, ICMP Router Discovery Messages, September 1991
- RFC-1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis, March 1992
- RFC-1398, Definitions of Managed Objects for the Ethernet-Like Interface Types, January 1993
- RFC-1418, SNMP over OSI, March 1993
- RFC-1570, PPP LCP Extensions, January 1994
- RFC-1643, Definitions of Managed Objects for the Ethernet-like Interface Types, July 1994
- RFC-1701, Generic Routing Encapsulation (GRE), October 1994
- RFC-1850, OSPF Version 2 Management Information Base, November 1995
- RFC-1901, Introduction to Community-based SNMPv2, January 1996
- RFC-1902, Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996
- RFC-1903, Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996
- RFC-1904, Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996
- RFC-1905, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996
- RFC-1906, Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996
- RFC-1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996
- RFC-1908, Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework, January 1996
- RFC-1918, Address Allocation for Private Internets, February 1996
- RFC-1919, Classical versus Transparent IP Proxies, March 1996
- RFC-2002, IP Mobility Support, May 1995
- RFC-2003, IP Encapsulation within IP, October 1996
- RFC-2004, Minimal Encapsulation within IP, October 1996
- RFC-2005, Applicability Statement for IP Mobility Support, October 1996
- RFC-2118, Microsoft Point-to-Point Compression (MPPC) Protocol, March 1997
- RFC 2131, Dynamic Host Configuration Protocol
- RFC-2136, Dynamic Updates in the Domain Name System (DNS UPDATE)
- RFC-2211, Specification of the Controlled-Load Network Element Service
- RFC-2246, The Transport Layer Security (TLS) Protocol Version 1.0, January 1999
- RFC-2328, OSPF Version 2, April 1998
- RFC-2344, Reverse Tunneling for Mobile IP, May 1998
- RFC-2394, IP Payload Compression Using DEFLATE, December 1998
- RFC 2401, Security Architecture for the Internet Protocol
- RFC 2402, IP Authentication Header (AH)
- RFC 2406, IP Encapsulating Security Payload (ESP)
- RFC 2409, The Internet Key Exchange (IKE)
- RFC-2460, Internet Protocol Version 6 (IPv6)
- RFC-2461, Neighbor Discovery for IPv6
- RFC-2462, IPv6 Stateless Address Autoconfiguration
- RFC-2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
- RFC-2486, The Network Access Identifier (NAI), January 1999
- RFC-2571, An Architecture for Describing SNMP Management Frameworks, April 1999
- RFC-2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), April 1999
- RFC-2573, SNMP Applications, April 1999
- RFC-2574, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), April 1999
- RFC-4594, Configuration Guidelines for DiffServ Service Classes
- RFC-2597, Assured Forwarding PHB Group, June 1999
- RFC-2598, Expedited Forwarding PHB, June 1999
- RFC-2618, RADIUS Authentication Client MIB, June 1999
- RFC-2620, RADIUS Accounting Client MIB, June 1999
- RFC-2661, Layer Two Tunneling Protocol “L2TP”, August 1999
- RFC-2697, A Single Rate Three Color Marker, September 1999
- RFC-2698, A Two Rate Three Color Marker, September 1999
- RFC-2784, Generic Routing Encapsulation (GRE) - March 2000, IETF
- RFC-2794, Mobile IP Network Access Identifier Extension for IPv4, March 2000
- RFC-2809, Implementation of L2TP Compulsory Tunneling via RADIUS, April 2000
- RFC-2845, Secret Key Transaction Authentication for DNS (TSIG), May 2000
- RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000
- RFC-2866, RADIUS Accounting, June 2000
- RFC-2867, RADIUS Accounting Modifications for Tunnel Protocol Support, June 2000
- RFC-2868, RADIUS Attributes for Tunnel Protocol Support, June 2000
- RFC-2869, RADIUS Extensions, June 2000
- RFC-4960, Stream Control Transmission Protocol
- RFC-3007, Secure Domain Name System (DNS) Dynamic Update, November 2000
- RFC-3012, Mobile IPv4 Challenge/Response Extensions, November 2000
- RFC-3056, Connection of IPv6 Domains via IPv4 Clouds, February 2001
- RFC-3101 OSPF-NSSA Option, January 2003
- RFC-3143, Known HTTP Proxy/Caching Problems, June 2001
- RFC-3193, Securing L2TP using IPSEC, November 2001
- RFC-3314, Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards, September 2002
- RFC-3316, Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts, April 2003
- RFC-3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, February 2004
- RFC-3543, Registration Revocation in Mobile IPv4, August 2003
- RFC 3588, Diameter Base Protocol, September 2003
- RFC 4006, Diameter Credit-Control Application, August 2005
- RFC-4306, Internet Key Exchange (IKEv2) Protocol, December 2005

ITU-T Recommendations

- ITU-T Recommendation Q.2630.1 - AAL type2 signalling protocol (Capability Set 1)
- ITU-T Recommendation Q.2630.2 - AAL type2 signalling protocol (Capability Set 2)
- ITU-T Recommendation I.361 B-ISDN ATM layer specification
- ITU-T Recommendation I.363.2 B-ISDN ATM Adaptation Layer (AAL) Specification: Type 2 AAL
- ITU-T Recommendation I.366.1 Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2
- ITU-T Recommendation Q.2150.1 AAL type 2 signaling transport converter on broadband MTP
- ITU-T Recommendation E.164 - The international public telecommunication numbering plan
- ITU-T Recommendation E.191 - B-ISDN addressing

Object Management Group (OMG) Standards

- CORBA 2.6 Specification 01-09-35,Object Management Group