Cisco Cisco Packet Data Gateway (PDG)

Página de 163
  HNB Gateway in Wireless Network 
Features and Functionality - Base Software  ▀   
 
HNB-GW Administration Guide, StarOS Release 18  ▄  
 
   
25 
 
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 de-registered 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 de-registered. 
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. 
Femto to Femto Handoff via CN 
Cisco HNB-GW supports the Femto to Femto Handoff via Core Network (CN) feature where a mobile in connected 
mode moves from the coverage area of one Home NodeB (HNB) to another HNB connected to the same chassis 
(ASR5x00). 
Earlier, the HNB-GW supported hand-in for closed mode HNBs. In such case, hand-in is allowed for an IMSI if it is the 
owner (i.e. it is the first IMSI in the whitelist of the HNB) of the target HNB. Also, handin is allowed if the IMSI is not 
the owner of the target HNB but is not present in the whitelist of any other HNB known to the HNB-GW. Now, the 
HNB-GW is modified to select a target HNB using the target Cell ID information. In this case, hand-in is therefore 
supported for open and hybrid mode HNBs as well along with closed mode HNBs. 
The HNB-GW support for the Femto to Femto Handoff via CN is in accordance with the following standards: 
 
3GPP TS 23.060 Section 6.9.2.2.2: 3rd Generation Partnership Project; Technical Specification Combined Hard 
Handover and SRNS Relocation Procedure 
Feature description can be understood using following points: 
Cell ID based lookup
 
Earlier, the HNB-GW employed whitelist-based target HNB selection during handin procedure.Therefore the hand-in 
was limited to the closed mode HNBs. The better way to IDentify target HNB is to use the cell ID of the HNB which is 
a unique IDentifier for an HNB within a particular PLMN.