Manual

Architecture
This section describes the call flow of RUA connect with Establishment type "Emergency"
Figure 7: RUA connect with Establishment type "Emergency"
1
UE1 is registered in HNBGW with HNB1.
2
HNBGW receives RUA connect with "Attach Request" from UE1. Establishment cause IE has value
Emergency.
3
Both normal and emergency registered UEs are allowed to accept RUA connects with cause Emergency.
4
HNBGW will not subject RUA connect request with cause Emergency to congestion control checks or
newcall policies. So the RUA connect is allowed to proceed and Emergency IU is established.
Assumptions & Limitations
This section describes HNBGW Emergency call behavior overhaul features assumptions and limitations
•
From release 18.0 HNBGW supports single IU and single RAB for a UE registered with cause Emergency.
As part of this enhancement, multi-IU and multi-RAB support is be provided.
•
Presently HNBGW does not store IMSI for UEs with registration cause Emergency. As part of this
enhancement, HNBGW shall store IMSI if it is received in the HNBAP UE Register Request message.
This will help for reaching out to the UE during paging.
•
There is no change in HNBGW policy of not performing Access control validation on UEs with
Registration cause Emergency.
•
Currently HNBGW does not put any restrictions of simultaneously registered emergency UEs. This
could lead to scenarios where a rogue HNB might end up using too much of the HNBGW's resources.
HNBGW will restrict the number of simultaneously registered UEs such that the sum of emergency and
normal UEs does not cross (100 + x) of the MAX_REGISTERED_UE limit. (where "x" is a configurable
value that can be set in test-mode, with default value 50).
•
During intra-HNBGW SRNS relocation, relocation of an emergency UE was not recognized as
intra-HNBGW, and was treated like a macro to femto SRNS relocation. Since IMSI of the emergency
HNB-GW Administration Guide, StarOS Release 19
34
HNB Gateway in Wireless Network
HNBGW Emergency Call behavior overhaul