Cisco Cisco Packet Data Gateway (PDG)

 

▄  HNB-GW Administration Guide, StarOS Release 17 

The MOCN is multiple core network operators sharing the costly radio access network. HNBGW does the functionality 
of selecting CN node for Non-supporting UE. It also does the functionality of routing messages to CN node for both 
Supporting and Non-supporting UE. 

 

Whenever MS is switched on, or has just returned to network coverage after being out of coverage, it would try to select 
a network to register itself and receive network services. Traditionally, each network would broadcast its own PLMN-Id 
on common broadcast channels which is visible to all MS in that area. 

MS would start off by scanning for all the available radio networks in that area and would create an "available PLMN 
list". It would then refer to "Equivalent PLMN list" and "Forbidden PLMN list" (stored on SIM) to prioritize the 
"available PLMN list". Once this prioritized PLMN list is available, it would attempt registration with the PLMN based 
on priority. 

In case of network sharing, single radio network will be shared by more than one network operator. This information 
about availability of multiple operators needs to be propagated to MS so that it can select correct (home or equivalent) 
network out of all available networks. 

To advertise availability of multiple core network operators on a single radio network, broadcast information has been 
modified to contain a list of PLMN-Ids representing core network operators sharing the particular radio network. The 
traditional PLMN-Id broadcasted by radio network before network sharing support was available is now called as 
"common PLMN Id". 

MS not supporting network sharing feature would see only "common PLMN Id", while MS supporting network sharing 
feature would be able to see the list of PLMN-Ids along with "common PLMN Id". 

Supporting MS would be responsible for selecting appropriate core network, while RNC and MSC/SGSN will help 
select appropriate core network for non-supporting MS through redirection procedure. 

 

Selection of the operator for non-supporting UE is the responsibility of HNBGW. HNBGW sets redirect attempt flag in 
Initial UE Message and randomly/intelligently forwards the request to the CN node of the operator. Operator CN Node 
based on redirection attempt flag knows that redirection to different operator is possible for this node. If the current 
operator is ready to accept the call it will send redirection complete in direct transfer message. HNBGW based on the 
redirection complete IE knows that redirection procedure is successful. If operator is not ready to accept the call or it 
thinks that CS/PS co-ordination is required then it sends redirection indication to HNBGW. HNBGW then sends the 
Initial UE message randomly/intelligently to another operator. 

 

When a CN node receives a registration from a subscriber with a non-supporting UE having a P-TMSI/TMSI not 
belonging to the pool, and no IMSI is provided by RNC, it returns a Reroute Command message to the RNC with an 
indication that it is for coordination purposes. The coordination may result in that the registration is sent back to the 
same CN node or CN operator again. 

As HNBGW will not look into MM/GMM messages, it will apply coordination for all RUA Connect/Initial UE 
Messages for non-supported UEs. For supported UEs CS/PS coordination is the responsibility of the UEs. HNBGW 
does not consider whether GS interface is present between SGSN and MSC. Because if GS interface is present UE may 
does combined CS/PS Attach, which inherently will take care of CS/PS coordination. If IMSI is available at HNBGW it 
sends it in Initial UE Message. 

A request from any domain is processed first to select the operator. Once the operator is selected same is stored in UE 
context. If UE Context is active and request from another domain is received then this request is forwarded to the same