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.
How It Works
An HENBGW Access
service is defined in a VPN context. A minimum of the following critical
parameters must beconfigured in an access service to move the service to
SCTP bind port
MME group id and
GTPU services if
S1U is enabled
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.
Configuring QCI to
DSCP Mapping Templates
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.