Cisco Cisco Packet Data Interworking Function (PDIF)

Page de 163
HNB Gateway in Wireless Network   
▀  Features and Functionality - Base Software 
 
 
▄  HNB-GW Administration Guide, StarOS Release 18 
26 
   
The target cell ID is present in the source RNC to target RNC transparent container IE in the Relocation Request 
message received from SGSN/MSC. HNB sends its cell ID and PLMN ID in the HNBAP-HNB Register Request 
message. HNBMGR stores this information and maintains a lookup for hnb context based on the global cell ID. On 
receiving Relocation Request, HNBMGR uses the target cell ID to IDentify the HNB context.The global cell ID consist 
of PLMN ID and Cell ID. 
 GLOBAL CELL ID = PLMN ID + CELL ID 
Following the introduction of this lookup, on receiving a HNB Register Request message with a certain cell ID, if an 
HNB already exists with same cell ID, the existing HNB is deregistered. 
Identifying PLMN ID from Relocation Request
 
A Relocation Request message coming in an SCCP CR message comes directly to HNBMGR from LinkMGR. Earlier 
the HNBMGR did not have CS/PS network configuration and therefore it did not have the capability to identify the 
CS/PS network and the plmn id of the request too. 
HNBMGR has been enhanced to store the CS/PS network configuration. Linkmgr now provides SCCP network ID and 
originating point code of the relocation request message. HNBMGR uses this info to find out the CS/PS network and 
therefore the PLMN ID from it. 
A Relocation Request coming in an SCCP DT message comes to session manager first. Session manager finds out 
CS/PS network and then the PLMN ID and sends this information to HNBMGR. 
Access Control
 
If the identified target HNB is a closed mode HNB, HNB-GW verifies that the IMSI mentioned in the Relocation 
Request message belongs to the whitelist of the target HNB before allowing the hand-in procedure to continue. 
For a hybrid mode HNB, the existing limit checks for max non-access controlled UEs per hybrid mode HNB are 
performed. 
For an open mode HNB, the existing limit checks for max number of UEs per open mode HNB are performed. 
If any of the above access control checks fail, a Relocation Failure Message is sent back to the CN node. 
Redundancy
 
In addition to existing information, the Cell ID of an HNB is backed up in CRR. For HNBMGR, the global Cell ID 
based lookup is recreated on recovering an HNB in HNBMGR. 
Assumptions
 
Following assumptions to be considered for this feature implementation: 
 
 It is assumed that a CELL ID (MCC+MNC+CellID) assigned to an HNB is not assigned to another HNB 
connecting to the same ASR5K via the same or via another HNB-GW Service. 
 
It is assumed that source HNB holds information about RNC ID and CELL ID of neighboring target HNB which 
it fills as TARGET RNC ID and TARGET CELL ID respectively in Relocation Required message. 
 
It may happen that both, the source HNB and the target HNB, share the same RNC ID. It is assumed that the CN 
(SGSN/MSC) nodes continue with relocation in spite of this and they are able to send the Relocation Request 
to the right HNBGW 
 
 
Emergency UE Handoff
 
RANAP Relocation Request may come without IMSI if the permanent UE identity is not known to the Core Node. This 
is possible in case of UE Registered for an Emergency Call and no SIM was inserted at the UE. if Relocation Request 
comes without IMSI for a single domain, then it is allowed at the HNB-GW.