Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Understanding the MobileNext Broadband Gateway Anchors

    The MobileNext Broadband Gateway processes GPRS tunneling protocol (GTP) and IP packets as they make their way upstream from mobile device to IP network or downstream from IP network to mobile device. Both control and data GTP packets are processed by an anchor session Dense Port Concentrator (DPC) or Packet Forwarding Engine (which are part of an interface DPC or Modular Port Concentrator [MPC] inside the broadband gateway). Anchor session PICs or Packet Forwarding Engines can be configured in a redundant manner to provide a failover data path in case of hardware problems.

    Session DPCs use 1:1 redundancy and the component PICs (session DPCs have two PICs) are essentially configured in pairs to provide backup. For example, you can configure ams0 so that PIC 1 in FPC slot 5 backs up PIC 1 in FPC slot 4. In other words, mams-5/1/0 backs up mams-4/1/0. However, this configuration alone does not make ams0 (or mams-4/1/0) an anchor session DPC. A separate configuration step is required for that. This “anchor or not” capability allows session DPCs to be used for services other than mobility.

    The same logic applies to interface DPCs or MPCs (Packet Forwarding Engines), except that the redundancy is N:1. In this case, you can configure apfe0 so that pfe-9/0/0 is a warm standby for pfe-7/0/0 and pfe/8/0/0. However, another configuration step is required to make the Packet Forwarding Engines in FPC slot 7 and 8 anchor Packet Forwarding Engines.

    Figure 1: Upstream GTP-U Traffic

    Upstream GTP-U Traffic

    Figure 1 shows how all GPRS tunneling protocol, user plane (GTP-U) traffic traverses an anchor Packet Forwarding Engine upstream from a Gn or S5 interface to a Gi or SGi interface:

    • The arriving GTP-U packet is filtered by the outer IP address and associated with the proper Virtual Routing and Forwarding (VRF) table .
    • The packet is sent to the anchor Packet Forwarding Engine associated with that group tunnel endpoint identifier (TEID) in the GTP header.
    • The packet is decapsulated and the TEID is processed. The correct charging and quality-of-service (QoS) parameters are applied and the inner IP address is used for a route table lookup. The packet is sent to the correct egress interface.
    • The packet is sent out on the correct Gi or SGi interface (other service functions such as network address translation [NAT] might be applied).

    The downstream GTP-U packet process is a mirror of the upstream process.

    Figure 2: Downstream GTP-U Traffic

    Downstream GTP-U Traffic

    Figure 1 shows how all GTP-U traffic traverses an anchor Packet Forwarding Engine downstream from a Gi or SGi interface to a Gn or S5 interface:

    • The arriving IP packet is looked up in the route table associated with the proper virtual routing and forwarding table (VRF).
    • The packet is sent to the anchor Packet Forwarding Engine associated with that route.
    • The TEID associated with the packet is processed and the correct charging and QoS parameters are applied. The packet is then encapsulated with the TEID and the outer IP address. The outer IP address in the GTP header is used for a route lookup for the SGSN or S-GW. The packet is sent to the egress interface.
    • The packet is sent from the correct Gn or S5 interface.

    Published: 2011-11-22