GTP

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.

The initial address of the P-GW or GGSN can either be provided during authentication, or, in the 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 performs an S-NAPTR lookup with this FQDN.

When multiple gateway 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 gateway 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.

config>router
config>service>vprn
    apn "internet.mno1.apn"
config>service>vprn>dns
    primary-dns 10.1.1.1
    secondary-dns 10.1.1.2
    tertiary-dns 10.1.1.3
    ipv4-source-address 10.1.1.1
exit

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.

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 gateway IP address or subnet per VRF. Most of the per-session/context parameters can be overridden via RADIUS authentication. See the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide for more information.

config>subscr-mgmt>gtp>peer-profile
    no description
    interface-type s2a
    ip-ttl 255
    keep-alive interval 60 retry-count 4 timeout 5
    message-retransmit timeout 5 retry-count 3
    protocol-configuration-options apco
    no python-policy
    rat-type wlan
    no report-wlan-location
    session-hold-time 30
    charging-characteristics
        no home
        no roaming
    exit
    ggsn
        qos
            no ambr
            arp 1
            down-link gbr 2000 mbr 2000
            up-link gbr 5000 mbr 5000
        exit
    exit
    pgw
        qos
            ambr down-link 20000 up-link 10000
            arp 1
            down-link gbr 0 mbr 0
            qci 8
            up-link gbr 0 mbr 0
        exit
    exit

config>router
config>service>vprn
    gtp uplink peer-profile-map 
        address 198.51.100.1/32 "pgw-policy"
        address 239.0.113.0/24 "ggsn-policy"
    exit

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.

config>subscr-mgmt>sla-prof>egress
    report-rate

Other signed QoS IE values are taken from static configuration or values signaled in authentication.

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 is not 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

  Because of SHCV usage, the UE is 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 Wi-Fi-GW to RAN

  In some cases, Wi-Fi 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.

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.

system>config>filter
    ip-filter 10 create
        entry 1 create
            match protocol udp
                dst-port eq 4000
            exit
            action gtp-local-breakout
        exit

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 for 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.

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 gateway 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.

IPoE session shows a sample IPoE session for GTP.

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.

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.

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:FWGW>config>subscr-mgmt>gtp# info
----------------------------------------------
            apn-policy apn_demo create
                apn demo.mnc001.mcc001.gprs create
                    radius-auth-policy "gtp_auth"
                exit
            exit
----------------------------------------------
*A:FWGW>config>service>vprn# info
----------------------------------------------
            gtp
                s11
                    interface gtp_endpoint create
                        apn-policy "apn_demo"
                    exit
                exit
            exit
            interface "gtp_endpoint" create
                description "Tunnel endpoint IP"
                address 192.0.2.10/32
                loopback
            exit
----------------------------------------------

A GTP peer profile defines specific signaling parameters such as TTL values, keepalive timers, retransmit timers, and default values for 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.

*A:FWGW>config>subscr-mgmt>gtp# info
----------------------------------------------
            peer-profile "s11_peers" create
                interface-type s11
                keep-alive interval 180 retry-count 10 timeout 20
                message-retransmit timeout 3 retry-count 1
                mme
                    qos
                        ambr down-link 50000 up-link 10000
                    exit
                exit
            exit
----------------------------------------------
*A:FWGW>config>service>vprn>gtp>s11# info
----------------------------------------------
                    peer-profile-map
                        address 0.0.0.0/0 peer-profile s11_peers
                    exit
----------------------------------------------

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 gateway 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.

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, you can configure both RADIUS and NASREQ 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, the system uses that username and password for authentication; if not, it falls back to the username and password configured in the configure subscriber-mgmt authentication-policy context. 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 toward the eNodeB. If IPv6 is enabled, an unsolicited RA is sent.

High-level example of GTP access setup shows a high-level overview of the setup call flow using RADIUS authentication.

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.

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 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, removes 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 FC to dot1p mapping, therefore 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 FC to dot1p mapping and enable in-profile and de-1-out-of-profile for each FC, therefore 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.

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.

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 does 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).

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.

Call flow for GTP session setup 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).

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.