This chapter describes Multi HeNBGW Service support, below are the links to the main sections of the document:
Currently a single HeNBGW Access service is supported in StarOS. As part of this feature, multiple HeNBGW Access services will be supported. There will be no change in the number of HeNBGW Network services. All HeNBGW Access services will continue to interface with the single HeNBGW Network service instance.
Below are the features of the Multi HeNBGW Service support.
Upto 16 Henbgw Access services in the same or different VPN contexts can be configured. Each Henbgw Access service will have a unique SCTP IP address and port combination.
Each HENBGW Access service have a provision to configure a DSCP value per QCI value. Separate values can be specified in uplink and downlink direction. This DSCP value shall be applied to GTPU packets of eRABs with the given QCI value.
GTPU packets of eRABs coming from or sent to HENBs registering with a particular HENBGW Access service are treated as per the DSCP configuration of that HENBGW Access service.
In scenarios where HENBGW does not know the QCI value for a particular eRAB, a configurable default DSCP value is used. Also configurable pass through mode is available where the DSCP marking will be unaltered by the HENBGW before relaying the packet to the other side.
No additional license is required to enable this feature on StarOS.
A maximum of 16 HENBGW Access services in the same or different VPN contexts can be configured. There will be a single instance of HENBGW Network service. All the access services share all the logical ENodeB's configured in the HENBGW Network service. The logical ENodeB will be selected based on the TAI sent by the HENB.
Each HENBGW Access service wil have its own unique SCTP bind address and port combination. Any attempt to reuse these parameters across Access Services will be rejected while validating the configuration from CLI commands.
Each HENBGW Access service wil have its own unique security gateway bind address. Any attempt to reuse this address across access services shall be rejected while validating the configuration from CLI commands.
User can now define QCI to DSCP marking mapping templates under the lte-policy configuration mode. A maximum of 32 such templates can be defined.
HENBGW Access service can refer to two such mapping templates, one for DSCP marking of uplink GTPU packets and other for downlink GTPU packets.
The template also has a provision to configure a default DSCP marking to be used in case DSCP marking is not defined for a particular QCI value or if QCI value is not known for a particular eRAB.
If no QCI to DSCP mapping template is referenced in an HENBGW Access service, then HENBGW acts in a pass through mode where it does not alter the DSCP marking of GTPU packets before forwarding to the peer node.
Feedback