13. GTP
13.1. GTP Uplink
SR OS supports subscriber traffic forwarding over an uplink GTP tunnel towards a GGSN or P-GW. This requires a per-subscriber GTP tunnel based on authentication to be configured. Each subscriber may access only a single APN. Both GTPv1 (Gn) and GTPv2 (S2a/S2b) are supported. A single primary PDP context per subscriber is supported on the Gn interface (3GPP TS 29.060 Release 8) from SR OS to the GGSN. A single default-bearer per subscriber is supported on the S2b interface (3GPPTS 29.274 Release 10), and S2a interface (3GPP TS 29.274 Release 11) from SR OS to the P-GW.
13.1.1. Identification Attributes
GTP requires at least an IMSI and an APN to set up a connection. The IMSI is required to identify the user, and the APN is required to identify the network the user is connecting to.
There is a 1:1 relationship between IMSI and subscriber ID. It is possible to provision only one of these and the other will be accepted as the same value. If both are provisioned, they must be equal. Therefore, it is not possible to set up more than one GTP tunnel per subscriber.
APN can be provisioned explicitly per subscriber, or a default APN can be provisioned per VRF. If this APN does not contain an Operator Identifier (OI), it will be added automatically based on the IMSI.
13.1.2. P-GW/GGSN Selection
The initial address of the P-GW or GGSN can either be provided during authentication, or, in absence of authentication, resolved dynamically via DNS. For DNS, a FQDN is generated based on the APN as specified in 3GPP 29.303. This FQDN always consists of both the Network-ID (NI) portion and the OI portion, and is formatted as NI.apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org. The system will perform an S-NAPTR lookup with this FQDN.
When multiple GW addresses are returned as part of this lookup, load-balancing is performed according to regular NAPTR and SRV rules. If no addresses are returned, or the S-NAPTR lookup failed, the system tries a regular A host lookup with the same FQDN. In this case, SR OS load-balances over multiple GW addresses using a round-robin mechanism. DNS servers can be configured per VPRN, except for the base router where the servers defined in the BOF are used.
After initial GTP setup, it is possible for the P-GW or GGSN to return another address as a GTP-C or GTP-U destination. All data plane traffic is sent using the signaled GTP-U address. All subsequent control plane traffic is forwarded to the new GTP-C address.
The VRF used for GTP tunneling can be selected via provisioning a retain service ID for the subscriber. The source IP for GTP tunneling is taken from a loopback interface with the name system in that VRF. If no such interface is present, the tunnel setup fails.
13.1.3. Configuration
Profiles with signaling-related configuration per mobile gateway can be created locally on the SR OS router. These profiles include configuration for the interface type used between the router and the mobile gateway, path management parameters, retransmission parameters, and default values for GTP information elements such as AMBR. Each profile can be mapped to a specific GW IP address or subnet per VRF. Most of the per-session/context parameters can be overridden via RADIUS authentication. Refer to the 7750 SR and VSR RADIUS Attributes Reference Guide for more information.
13.1.4. QoS Support
SR OS provides appropriate traffic treatment and remarking based on DSCP bits in the outer and inner header in GTP packets.
Downstream from PGW/GGSN, the DSCP bits from the outer header in a GTP packet can be mapped to a forwarding class on network ingress, which can be preserved through the chassis as the packet passes to the egress IOM. On egress, reclassification can be done based on either the inner or outer DSCP bits, depending on the configuration value of the use-ingress-l2tp-dscp option in the SLA profile.
In the upstream direction, regular ESM FC classification is used. This FC is carried through the IOM to the egress complex. In the egress complex, this FC can be used for remarking of the outer DSCP values.
DSCP and default FC values for egress GTP-C packets can be configured under sgt-qos.
It is possible to signal the subscriber’s aggregate rate or the rate of a specific scheduler in the downlink AMBR IE in both GTPv1-C and GTPv2-C. This uses the report-rate configuration of the SLA profile; the pppoe-actual-rate and rfc5515-actual-rate values are not applicable for GTP. This value can be subtracted with a value signaled during authentication to consider an average use for selective breakout.
Other signed QoS IE values are taken from static configuration or values signaled in authentication.
13.1.5. GTP Session Hold
Deletion of an IPoE or PPPoE session also triggers deletion of any corresponding GTP sessions. This deletion is subject to a configurable hold time. When the subscriber returns with the same GGSN/P-GW parameters within the hold time, the GTP connection will not be re-signaled. This avoids releasing resources (such as IP addresses) too quickly on the GGSN/P-GW. This is useful in the following cases:
- Non-seamless control plane mobility with WLAN-GW. Due to SHCV usage, the UE will be completely removed, but should reconnect quickly, preferably with the same IP address. Having a short hold time avoids the P-GW releasing the IP address.
- IP handover from WiFi-GW to RAN. In some cases, WiFi connectivity is lost before wireless data connectivity is established. By holding the GTP session active on the WLAN-GW, the IP address is also held on the GGSN/P-GW until the RAN connection is complete.
While a GTP session is in hold, all downstream traffic is dropped, but no error indication messages are sent.
13.1.6. Selective Breakout
This feature adds support for selecting a subset of traffic from a host (via IP filter) for local forwarding, while tunneling the remaining traffic to GGSN/PGW. This allows selected traffic to bypass the mobile packet core. The IP address for the host still comes from the GGSN/PGW during GTP session setup. Therefore, the selected traffic for local breakout from SR OS requires NAT functionality to draw the return traffic back to the router. To support address overlap within GTP, the NAT functionality is L2-aware. The selection of traffic for local breakout (local forwarding and NAT) is based on a net action in an upstream Ip filter applied to the host.
Selective breakout can be enabled on a per-host basis via RADIUS VSA (Alc-GTP-Local-Breakout) in access-accept. It is not possible to change this during a host’s lifetime, such as via CoA. AA functionality is supported for local breakout traffic. Also, LI (after NAT) is supported for local breakout traffic, and is enabled via existing secure CLI, as stated in the OAM and Diagnostics Guide.
On traffic ingress from the host UE, normal ESM host lookup and CAM lookup with the ingress host filter is performed. If there is a match in the filter indicating “gtp-local-breakout”, the traffic is forwarded within the chassis to an ISA-BB, where is it subjected to L2-aware NAT function, and afterwards is forwarded using regular routing in the NAT outside VRF. The inside IP address is the address returned in GTP, and may not match a NAT L2-aware inside prefix. The outside IP is an address belonging to the NAT outside IP address range on the ISA. If the filter action results in a “forward” action (default), the traffic is GTP-tunneled without performing NAT functionality. The traffic received from the network can be a normal L3 packet or a GTP encapsulated packet. The normal Layer 3 packet is expected to be destined to the NAT outside IP and is normally routed to the NAT ISA.
By default, per-host accounting includes counters that are aggregated across GTP and local breakout traffic. Separate counters can be obtained by directing the GTP and local breakout traffic into different queues associated with the corresponding ESM host based on QoS IP classification. NAT information (outside IP and port range) associated with an ESM host subjected to selective breakout is included in accounting-updates.
Selective breakout is supported for IPv4 only.
13.1.7. IPoE Support
A GTPv2 session or GTPv1 PDP context is set up when IPoE session authentication includes any GTP parameters. The GTP session provides the IPv4 and IPv6 address used for the connecting host. Currently only DHCPv4 and SLAAC are supported to deliver these addresses back to the client. If DHCP is used, SR OS automatically derives a standards-compliant subnet mask and default GW from the signaled IP address. It is important that all GTP subscribers are in a shared split-horizon domain and that there is no Layer 2 switching between GTP subscribers. Only a single IPoE session is supported per GTP subscriber. Additionally, DNS and NBNS can be signaled via GTP (A)PCO and reflected in DHCP, SLAAC, and stateless DHCPv6. Control plane packets such as DHCP and ICMPv6 RS are always terminated on the BNG and are not forwarded over GTP.
Figure 178 shows a sample IPoE session for GTP.
Figure 178: IPoE Session
GTP without an IPoE session is available for IPv4 DHCP leases only for backwards compatibility. It may not be used for new deployments; existing deployments should move to the IPoE session concept.
13.1.8. PPPoE Support
A GTPv2 session or GTPv1 PDP context is set up when PPPoE session authentication includes any GTP parameters. The GTP session provides the IPv4 and IPv6 address to be used for the connecting host. IPCP and IPv6CP with SLAAC are supported to signal these addresses to the client. Only a single PPPoE session is supported per GTP subscriber. Additionally, DNS and NBNS can be signaled via GTP (A)PCO and reflected in IPCP, SLAAC, and stateless DHCPv6. Control plane packets such as ICMPv6 RS are always terminated on the BNG and are not forwarded over GTP.
13.2. GTP Access
SR OS supports TPSDA functionality over GTP access funnels towards eNodeBs using the S11 (GTPv2-C) and S1-U (GTP-U) interfaces toward MME and eNodeB. In this setup, as shown in Figure 179, the SR OS router performs the roles of BNG, SGW, and PGW. Both IPv4 and IPv6 connectivity over GTP is supported. GTP session authentication can be performed using LUDB, RADIUS, or NASREQ. GTP access termination is built on top of forwarding path extensions.
Figure 179: GTP Access
13.2.1. GTP Termination
GTP S11 termination can be enabled on interfaces in the base router and VPRNs. The configuration is linked to an APN policy that lists all supported APNs and the authentication mechanism (for example, LUDB or RADIUS) to be used per APN. The configured APN string should match the value signaled in GTP; however, fallback configuration is supported for any unknown APNs.
A GTP peer profile defines certain signaling parameters such as TTL values, keepalive timers, retransmit timers, and default values for certain information elements. By default, an automatically-created profile with the name “default_s11” is used. A more specific profile can be configured and mapped to a peer by a per-VRT mapping of IP address or prefix to that profile. To map all peers within the same VRF to the same profile, it is possible to use prefix 0.0.0.0/0.
When an S11 session is set up, the accompanying S1-U bearer is terminated in the same VRF, but it is directly linked to a group interface in either the same or a different VRF. A default group interface can be configured per APN, which can be overridden during S11 session authentication. The group interfaces are of type gtp and require an FPE construct to operate. The traffic takes two passes through the forwarding plane. For upstream data, in the first pass, the GTP-U header is stripped; in the second pass, it is inserted into the group interface for regular ESM processing, based on existing IPoE functionality. For downstream data, in the first pass, regular ESM processing is performed and traffic egresses over the group interface; in the second pass, GTP-U encapsulation occurs.
Active GTP sessions support the S1 Release, UE triggered service request, and network-triggered service request procedures as defined in TS 23.401 to support connection idling and paging.
Both IPv4 and IPv6 are supported for GTP termination. GTP is enabled for the primary IPv4 and IPv6 addresses configured on the S11 interface. If both IPv4 and IPv6 address are configured, GTP supports dual-stack operations as follows:
- For GTP-C, a stack is chosen based on the stack of the incoming GTP-C message. Any subsequent GTP-C transactions initiated by the FWA GW uses this stack. Subsequent GTP-C transactions initiated by the MME may change the IP stack.
- For GTP-U, a downstream peer is selected based on the information in the S1 eNodeB F-TEID IE. If that peer also contains two addresses, IPv6 is preferred. Upstream traffic can be received on both the IPv4 and IPv6 address simultaneously.
13.2.1.1. Multiple APNs
SR OS supports multiple APN connectivity for the same IMSI. When an additional session setup with a different APN is triggered, the system treats this as a completely new session that goes through APN selection and authentication again. PDN session user plane can be instantiated in the same VRF as previous sessions or in different VRFs. Sessions for the same IMSI can belong to the same ESM subscriber by using the same subscriber-id, but are not required to do so. S11 messages defined with UE granularity in 3GPP TS 29.274 will apply to all sessions of the same IMSI.
13.2.2. GTP Session Setup
When a GTPv2 Create Session Request message arrives, SR OS looks up the required authentication mechanism in the applicable APN policy. To aid in the identification process, both RADIUS and NASREQ can be configured with GTP specific include attributes such as IMSI, MSISDN, and IMEI. If a PAP message is present in the PCO IE of the Create Session request, that username and password is used for authentication; otherwise the system falls back to IMSI as the username and password configured in the policy.For LUDB-based authentication, it is recommended to use derived-id for identification values.
Authentication is performed per GTP session and not per IP stack (host). Therefore, the initial authentication returns parameters for all stacks that need to be set up.
After a successful authentication, a Create Session Response message is sent, which includes all relevant parameters including assigned addresses, DNS servers, and applicable QoS values. The Create Session Response message is followed by an initial Modify Bearer Request message. When the host setup is completed with a Modify Bearer Response message, downstream data can then flow towards the eNodeB. If IPv6 is enabled, an unsolicited RA is sent.
Figure 180 shows a high-level overview of the setup call flow using RADIUS authentication.
Figure 180: High-level Example of GTP Access Setup
13.2.2.1. Supported IP Stacks
IPv4 and IPv6 SLAAC are supported via dual-stack bearers. IP addresses can be provisioned during authentication or through Local Address Assignment. Any DNS (IPv4 and IPv6) and NBNS (IPv4 only) addresses are signaled in the PCO IE. An unsolicited RA is sent after the first Modify Bearer Request message is received. An RS-triggered RA is also supported and either RA can be configured to contain DNS servers. Stateless DHCPv6 can also be used to retrieve the DNS configuration.
13.2.3. Mobility and Location Tracking
GTP access supports X2 handover and Tracking Area Update (TAU) without SGW relocation procedures as defined in TS 23.401.
GTP also supports subscriptions to location reporting. The required level of location reporting (for example, ECGI, TAI, ECGI+TAI) can be configured and overridden by AAA. Location reporting is only enabled if support is signaled by an MME. If an MME changes as part of a TAU procedure, change reporting is disabled unless the new MME also explicitly signals support.
Updated ULI can be learned in any regular procedure such as X2 handover, TAU, and UE-triggered service request. Additionally, the Location Change Reporting procedure, as defined in TS 23.401, is supported to signal location changes in absence of any other change.
Any AAA messages sent by the router always contain the latest ULI for the related GTP session. Additionally, RADIUS Accounting and Gx support triggered updates whenever the ULI changes. For RADIUS, this support is configured locally in the radius-accounting-policy. For Gx, the PCRF needs to subscribe to the USER_LOCATION_CHANGE, RAT_CHANGE, or ECGI_CHANGE event as specified in TS 29.214. In case of RAT/ECGI event subscription, this is directly reflected in GTP Change Reporting Action, overriding any local configuration. If only a generic USER_LOCATION_CHANGE subscription is requested, the GTP signaled action depends on the local configuration, requiring change-reporting-action to be configured in the applicable peer-profile.
13.2.4. QoS
ESM QoS using subscriber and SLA profiles also applies to GTP hosts. SR OS provides various methods to align internal QoS objects with 3GPP signaling of UL/DL APN-AMBR values:
- The incoming APN-AMBR from GTP can be reflected in radius and/or diameter. Additionally, this can be mapped to an SR OS QoS override using the command configure subscriber-mgmt gtp apn-policy apn ambr-qos-mapping. This uses generic QoS overrides, meaning that a subsequent QoS-override from AAA, for example, will remove this mapping again.
- The APN-AMBR IE signaled in Gx can similarly be mapped to QoS overrides using the command configure subscriber-mgmt diameter-application-policy gx 3gpp-qos-mapping. This has precedence over the similar GTP command.
- The APN-AMBR IE signaled in outgoing GTP messages is derived from either local QoS objects, a Gx/radius signaled value, the incoming GTP APN-AMBR, or default values under configure subscriber-mgmt gtp peer-profile mme qos ambr, in that priority order. The mapping of local QoS objects to APN-AMBR is done with the command configure subscriber-mgmt sla-profile egress/ingress report-rate.
Values for QCI and ARP can be reflected from AAA or default values can be configured under configure subscriber-mgmt gtp peer-profile mme qos arp/qci. There is no interaction with local QoS objects.
SR OS maintains the FC classification and in- and out-of-profile markings consistent over the two dataplane passes. The egress and ingress QoS policies in the SLA profile should be configured with the following considerations.
- Enable de-mark for access egress and map each FC to the dot1p as defined in Table 51, thus ensuring that the GTP-U encapsulated packet uses the same classification as the ESM context.
- Perform classification for access ingress based on dot1p as defined in Table 51 and enable in-profile and de-1-out-of-profile for each FC, thus ensuring that the ESM context uses the same classification as determined for the GTP-U packet. However, a different classification scheme can be used, if required; for example, based on DSCP or IP criteria.
Table 51: FC to dot1p Mapping
FC | dot1p |
be | 0 |
l2 | 1 |
af | 2 |
l1 | 3 |
h2 | 4 |
ef | 5 |
h1 | 6 |
nc | 7 |
13.2.5. Multicast
GTP supports the reception of MLD and IGMP, with either a redirect-interface or per-host replication enabled. Per-SAP replication is not applicable and is ignored.
13.3. DHCP over GTP-u
A routed gateway (RG) with a fixed-wireless WAN link can get an IPv4 address and an IPv6 /128 address using DHCPv4 and DHCPv6 IA_NA, respectively. The RG can also get an IPv6 prefix using DHCPv6 PD for its LAN. A fixed-wireless RG can be an RG with integrated LTE or 5G modem, or connected to an external 5G modem using Ethernet or WLAN. Once the default bearer and PDU session is created using NAS signaling, DHCP messages can be forwarded by the RG (with integrated modem), or the standalone modem (referred to as user equipment (UE)), over the default bearer towards the BNG, which functions as fixed-wireless gateway and terminates the GTP tunnel. DHCP messages are received and sent by the BNG over the GTP tunnel.
13.3.1. Address Management Related PCOs
Without DHCPv4, the fixed-wireless RG can only get an IPv4 address during initial attach using NAS SM (session management) procedures. As part of NAS signaling, the BNG acting as a fixed-wireless gateway allocates an IPv4 address and returns it in a PDN address allocation (PAA) IE in the GTP session creation response.
- If an RG requires IPv4 address allocation using DHCPv4 instead of address allocation during initial attach using NAS signaling, then it can signal a PCO "deferred address allocation" (value 0x000b) in GTP session setup. If this PCO is present in GTP setup request, then the BNG will not allocate an IPv4 address during GTP session setup. The GTP setup completes with IPv4 address of 0.0.0.0 returned in a PAA to the RG. The BNG only allocates and assign an IPv4 address using subsequent DHCPv4 from the RG, which is received over the GTP-u tunnel (S1-U interface) on the BNG.
- If PCO “allocation via NAS” (value 0x000a) is present in a GTP setup request, then the IPv4 address is allocated during GTP setup and returned in a GTP session creation response.
- If neither PCO is present, then by default, anIPv4 address is allocated on the GTP setup, and returned in the GTP session creation response. This can be overridden using the skip-gtp-ipv4-alloc CLI command. In this case, no IPv4 address is allocated during GTP setup and is only allocated using a subsequent DHCPv4 exchange.
The skip-gtp-ipv4-alloc configuration is a per-APN configuration. This can be overridden on a per-subscriber basis using a RADIUS VSA (Alc-Gtp-Skip-Ipv4-Alloc-Override).
13.3.2. Address Allocation Modes
DHCPv6 IA_NA can be used for IPv6 WAN address assignment. IPv6 WAN prefix can also be supported using SLAAC.
For DHCPv4, the following address allocation modes are supported.
- DHCPv4 proxy. The IPv4 address offered in DHCPv4 from the RG can be provided from AAA during initial authentication in the framed-IP-address RADIUS attribute.
- DHCPv4 relay to a local or external DHCPv4 server for IPv4 address allocation. The pool can be provided from AAA during initial authentication in the framed-pool RADIUS attribute, and can be added in the relayed DHCP packets with a DHCP Option 82 vendor-specific sub-option.
For DHCPv6, the following address allocation modes are supported.
- DHCPv6 proxy. The /128 IPv6 address for RG WAN using DHCPv6 IA_NA can be provided from AAA during initial authentication in Alc-IPv6-address VSA. The PD prefix requested by RG using DHCPv6 IA_PD can be provided from AAA in the Delegated-IPv6-Prefix RADIUS attribute.
- DHCPv6 relay to a local or external DHCPv6 server for IPv6 address and prefix allocation. The pool for /128 IPv6 address allocation for DHCPv6 IA_NA can be provided by AAA during initial authentication in the framed-ipv6-pool attribute. Pool for PD prefix can be provided by AAA during initial authentication in the Alc-Delegated-IPv6-Pool VSA. These are signaled by DHCPv6 relay to the server.
Authentication is performed only during GTP session setup. All the RADIUS attributes related to DHCP and IP stack (host) setup are received during this authentication. No subsequent authentication is performed on the receiving DHCP. A single IPoE session containing all the hosts (DHCPv4, DHCPv6 IA_NA, and SLAAC) are created per GTP session. PD prefix should be configured to be added as a managed-route if both DHCPv6 IA_NA and SLAAC are in use and creating respective hosts.
Figure 181 shows the call flow for GTP session setup, subsequent DHCP exchange, and host creation in case of RG with a standalone modem (user equipment is noted as UE in the diagram).
Figure 181: Call Flow for GTP Session Setup
DHCP over GTP-u tunnel is not supported in conjunction with bonding (hybrid-access).
DHCP over GTP-u tunnel is supported in conjunction with multiple APNs. The APNs can have different address management (for example, in case of two APNs). It is possible to use WAN address assignment using NAS for one APN and DHCPv4 for another APN.
Broadcast flag should not be set in DHCP messages from the client.
13.4. GTP Peering
SR OS tracks each GTP-C peer for which it has at least a single GTP session or PDP context active. It tracks the peer’s operational state with the following mechanisms:
- Regular GTP echo messages and parameters are configurable on a per-mgw-profile basis. When the echo mechanism fails, the peer is considered down.
- Active route entries towards the peer are monitored. If no route towards the peer is available, the peer is considered down.
- The Restart counter value of the peer is monitored. This is initially learned when the first active session or context is created. If the value is not available in regular messaging, an echo request is sent out immediately to learn the correct value. If the Restart counter is incremented during any later messaging exchange, the peer is considered rebooted.
When a peer is considered down or rebooted, all active GTP sessions and PDP contexts are forcefully removed.
SR OS also keeps a recovery counter in a persistent state, and increments this value on every reboot. This value is kept in the restcntr.txt file on CF3 and may not be modified or removed. This value is included in every control plane message.
SR OS responds to GTP echo messages for both active peers and unknown sources. This can be restricted using CPM filters if required. An incoming echo request from an unknown source will not create a peer; this can only be done by setting up GTP sessions or PDP contexts.