> PDN Gateway Configuration
> This chapter provides configuration information for the PDN Gateway (P-GW).
> Important: Information about all commands in this chapter can be found in the Command Line Interface Reference.
> Because each wireless network is unique, the system is designed with a variety of parameters allowing it to perform in various wireless network environments. In this chapter, only the minimum set of parameters are provided to make the system operational. Optional configuration commands specific to the P-GW product are located in the Command Line Interface Reference.
> The following procedures are located in this chapter:

> • | Configuring the System as a Standalone eGTP P-GW

> • | Configuring the System as a Standalone PMIP P-GW Supporting an eHRPD Network

> • | Configuring Optional Features on the P-GW

> Configuring the System as a Standalone eGTP P-GW
> This section provides a high-level series of steps and the associated configuration file examples for configuring the system to perform as a eGTP P-GW in a test environment. For a complete configuration file example, refer to the Sample Configuration Files appendix. Information provided in this section includes the following:

> • | Information Required

> • | How This Configuration Works

> • | eGTP P-GW Configuration

> Information Required
> The following sections describe the minimum amount of information required to configure and make the P-GW operational on the network. To make the process more efficient, it is recommended that this information be available prior to configuring the system.
> There are additional configuration parameters that are not described in this section. These parameters deal mostly with fine-tuning the operation of the P-GW in the network. Information on these parameters can be found in the appropriate sections of the Command Line Interface Reference.
> Required Local Context Configuration Information
> The following table lists the information that is required to configure the local context on an P-GW.
> Required Information for Local Context Configuration

> Required Information | Description
> Management Interface Configuration
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface will be recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the management interface(s) to a specific network.
> Security administrator name | The name or names of the security administrator with full rights to the system.
> Security administrator password | Open or encrypted passwords can be used.
> Remote access type(s) | The type of remote access that will be used to access the system such as telnetd, sshd, and/or ftpd.

> ‌
> Required P-GW Context Configuration Information
> The following table lists the information that is required to configure the P-GW context on a P-GW.
> Required Information for P-GW Context Configuration

> Required Information | Description
> P-GW context name | An identification string from 1 to 79 characters (alpha and/or numeric) by which the P-GW context will be recognized by the system.
> Accounting policy name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the accounting policy will be recognized by the system. The accounting policy is used to set parameters for the Rf (off-line charging) interface.
> S5/S8 Interface Configuration (To/from S-GW)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface will be recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 or IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> GTP-U Service Configuration
> GTP-U service name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the GTP-U service will be recognized by the system.
> IP address | S5/S8 interface IPv4 address.
> P-GW Service Configuration
> P-GW service name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the P-GW service will be recognized by the system. Multiple names are needed if multiple P-GW services will be used.
> PLMN ID | MCC number: The mobile country code (MCC) portion of the PLMN’s identifier (an integer value between 100 and 999). MNC number: The mobile network code (MNC) portion of the PLMN’s identifier (a 2 or 3 digit integer value between 00 and 999).
> eGTP Service Configuration
> eGTP Service Name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the eGTP service will be recognized by the system.

> ‌
> Required PDN Context Configuration Information
> The following table lists the information that is required to configure the PDN context on a P-GW.
> Required Information for PDN Context Configuration

> Required Information | Description
> PDN context name | An identification string from 1 to 79 characters (alpha and/or numeric) by which the PDN context is recognized by the system.
> IP Address Pool Configuration
> IPv4 address pool name and range | An identification string between 1 and 31 characters (alpha and/or numeric) by which the IPv4 pool is recognized by the system. Multiple names are needed if multiple pools will be configured. A range of IPv4 addresses defined by a starting address and an ending address.
> IPv6 address pool name and range | An identification string between 1 and 31 characters (alpha and/or numeric) by which the IPv6 pool is recognized by the system. Multiple names are needed if multiple pools will be configured. A range of IPv6 addresses defined by a starting address and an ending address.
> Access Control List Configuration
> IPv4 access list name | An identification string between 1 and 47 characters (alpha and/or numeric) by which the IPv4 access list is recognized by the system. Multiple names are needed if multiple lists will be configured.
> IPv6 access list name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the IPv6 access list is recognized by the system. Multiple names are needed if multiple lists will be configured.
> Deny/permit type | The types are:
> • | any
> • | by host IP address
> • | by IP packets
> • | by source ICMP packets
> • | by source IP address masking
> • | by TCP/UDP packets
> Readdress or redirect type | The types are
> • | readdress server
> • | redirect context
> • | redirect css delivery-sequence
> • | redirect css service
> • | redirect nexthop
> SGi Interface Configuration (To/from IPv4 PDN)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> SGi Interface Configuration (To/from IPv6 PDN)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.

> ‌
> Required AAA Context Configuration Information
> The following table lists the information that is required to configure the AAA context on a P-GW.
> Required Information for AAA Context Configuration

> Required Information | Description
> Gx Interface Configuration (to PCRF)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 or IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> Gx Diameter Endpoint Configuration
> End point name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the Gx Diameter endpoint configuration is recognized by the system.
> Origin realm name | An identification string between 1 through 127 characters. The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.
> Origin host name | An identification string from 1 to 255 characters (alpha and/or numeric) by which the Gx origin host is recognized by the system.
> Origin host address | The IP address of the Gx interface.
> Peer name | The Gx endpoint name described above.
> Peer realm name | The Gx origin realm name described above.
> Peer address and port number | The IP address and port number of the PCRF.
> Route-entry peer | The Gx endpoint name described above.
> Gy Interface Configuration (to on-line charging server)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 or IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> Gy Diameter Endpoint Configuration
> End point name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the Gy Diameter endpoint configuration is recognized by the system.
> Origin realm name | An identification string between 1 through 127 characters. The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.
> Origin host name | An identification string from 1 to 255 characters (alpha and/or numeric) by which the Gy origin host is recognized by the system.
> Origin host address | The IP address of the Gy interface.
> Peer name | The Gy endpoint name described above.
> Peer realm name | The Gy origin realm name described above.
> Peer address and port number | The IP address and port number of the OCS.
> Route-entry peer | The Gy endpoint name described above.
> Gz Interface Configuration (to off-line charging server)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> Rf Interface Configuration (to off-line charging server)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 or IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> Rf Diameter Endpoint Configuration
> End point name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the Rf Diameter endpoint configuration is recognized by the system.
> Origin realm name | An identification string between 1 through 127 characters. The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.
> Origin host name | An identification string from 1 to 255 characters (alpha and/or numeric) by which the Rf origin host is recognized by the system.
> Origin host address | The IP address of the Rf interface.
> Peer name | The Rf endpoint name described above.
> Peer realm name | The Rf origin realm name described above.
> Peer address and port number | The IP address and port number of the OFCS.
> Route-entry peer | The Rf endpoint name described above.

> ‌
> How This Configuration Works
> The following figure and supporting text describe how this configuration with a single source and destination context is used by the system to process a subscriber call originating from the GTP LTE network.

> 1. | The S-GW establishes the S5/S8 connection by sending a Create Session Request message to the P-GW including an Access Point name (APN).

> 2. | The P-GW service determines which context to use to provide AAA functionality for the session. This process is described in the How the System Selects Contexts section located in the Understanding the System Operation and Configuration chapter of the System Administration Guide.

> 3. | The P-GW uses the configured Gx Diameter endpoint to establish the IP-CAN session.

> 4. | The P-GW sends a CC-Request (CCR) message to the PCRF to indicate the establishment of the IP-CAN session and the PCRF acknowledges with a CC-Answer (CCA).

> 5. | The P-GW uses the APN configuration to select the PDN context. IP addresses are assigned from the IP pool configured in the selected PDN context.

> 6. | The P-GW responds to the S-GW with a Create Session Response message including the assigned address and additional information.

> 7. | The S5/S8 data plane tunnel is established and the P-GW can forward and receive packets to/from the PDN.

> eGTP P-GW Configuration
> To configure the system to perform as a standalone eGTP P-GW:

> Step 1 | Set system configuration parameters such as activating PSCs by applying the example configurations found in the System Administration Guide.

> Step 2 | Set initial configuration parameters such as creating contexts and services by applying the example configurations found in the Initial Configuration section of this chapter.

> Step 3 | Configure the system to perform as an eGTP P-GW and set basic P-GW parameters such as eGTP interfaces and IP routes by applying the example configurations presented in the P-GW Service Configuration section.

> Step 4 | Configure the PDN context by applying the example configuration in the P-GW PDN Context Configuration section.

> Step 5 | Enable and configure the active charging service for Gx interface support by applying the example configuration in the Active Charging Service Configuration section.

> Step 6 | Create a AAA context and configure parameters for policy by applying the example configuration in the Policy Configuration section.

> Step 7 | Verify and save the configuration by following the steps found in the Verifying and Saving the Configuration section.

> Initial Configuration

> Step 1 | Set local system management parameters by applying the example configuration in the Modifying the Local Context section.

> Step 2 | Create the context where the eGTP service will reside by applying the example configuration in the Creating and Configuring a P-MIP P-GW Context section.

> Step 3 | Create and configure APNs in the P-GW context by applying the example configuration in the Creating and Configuring APNs in the P-GW Context section.

> Step 4 | Create and configure AAA server groups in the P-GW context by applying the example configuration in the Creating and Configuring AAA Groups in the P-GW Context section.

> Step 5 | Create an eGTP service within the newly created context by applying the example configuration in the Creating and Configuring an eGTP Service section.

> Step 6 | Create and configure a GTP-U service within the P-GW context by applying the example configuration in the Creating and Configuring a GTP-U Service section.

> Step 7 | Create a context through which the interface to the PDN will reside by applying the example configuration in the Creating a P-GW PDN Context section.

> Modifying the Local Context
> Use the following example to set the default subscriber and configure remote access capability in the local context:
> configure
> context local
> interface <lcl_cntxt_intrfc_name>
> ip address <ip_address> <ip_mask>
> exit
> server ftpd
> exit
> server telnetd
> exit
> subscriber default
> exit
> administrator <name> encrypted password <password> ftp
> ip route <ip_addr/ip_mask> <next_hop_addr> <lcl_cntxt_intrfc_name>
> exit
> port ethernet <slot#/port#>
> no shutdown
> bind interface <lcl_cntxt_intrfc_name> local
> end
> Creating and Configuring an eGTP P-GW Context
> Use the following example to create a P-GW context, create an S5/S8 IPv4 interface (for data traffic to/from the S-GW), and bind the S5/S8 interface to a configured Ethernet port:
> configure
> gtpp single-source
> context <pgw_context_name> -noconfirm
> interface <s5s8_interface_name>
> ip address <ipv4_address>
> exit
> gtpp group default
> gtpp charging-agent address <gz_ipv4_address>
> gtpp echo-interval <seconds>
> gtpp attribute diagnostics
> gtpp attribute local-record-sequence-number
> gtpp attribute node-id-suffix <string>
> gtpp dictionary <name>
> gtpp server <ipv4_address> priority <num>
> gtpp server <ipv4_address> priority <num> node-alive enable
> exit
> policy accounting <rf_policy_name> -noconfirm
> accounting-level {level_type}
> accounting-event-trigger interim-timeout action stop-start
> operator-string <string>
> cc profile <index> interval <seconds>
> exit
> exit
> subscriber default
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <s5s8_interface_name> <pgw_context_name>
> end
> Notes:

> • | gtpp single-source is enabled to allow the system to generate requests to the accounting server using a single UDP port (by way of a AAA proxy function) rather than each AAA manager generating requests on unique UDP ports.

> • | The S5/S8 (P-GW to S-GW) interface IP address can also be specified as an IPv6 address using the ipv6 address command.

> • | Set the accounting policy for the Rf (off-line charging) interface. The accounting level types are: flow, PDN, PDN-QCI, QCI, and subscriber. Refer to the Accounting Profile Configuration Mode Commands chapter in the Command Line Interface Reference for more information on this command.

> • | Set the GTPP group setting for Gz accounting.

> Creating and Configuring APNs in the P-GW Context
> Use the following configuration to create an APN:
> configure
> context <pgw_context_name> -noconfirm
> apn <name>
> accounting-mode radius-diameter
> associate accounting-policy <rf_policy_name>
> ims-auth-service <gx_ims_service_name>
> aaa group <rf-radius_group_name>
> dns primary <ipv4_address>
> dns secondary <ipv4_address>
> ip access-group <name> in
> ip access-group <name> out
> mediation-device context-name <pgw_context_name>
> ip context-name <pdn_context_name>
> ipv6 access-group <name> in
> ipv6 access-group <name> out
> active-charging rulebase <name>
> end
> Notes:

> • | The IMS Authorization Service is created and configured in the AAA context.

> • | Multiple APNs can be configured to support different domain names.

> • | The associate accounting-policy command is used to associate a pre-configured accounting policy with this APN. Accounting policies are configured in the P-GW context. An example is located in the Creating and Configuring an eGTP P-GW Context section above.

> Use the following configuration to create an APN that includes Gz interface parameters:
> configure
> context <pgw_context_name> -noconfirm
> apn <name>
> bearer-control-mode mixed
> selection-mode sent-by-ms
> accounting-mode gtpp
> gtpp group default accounting-context <aaa_context_name>
> ims-auth-service <gx_ims_service_name>
> ip access-group <name> in
> ip access-group <name> out
> ip context-name <pdn_context_name>
> active-charging rulebase <gz_rulebase_name>
> end
> Notes:

> • | The IMS Authorization Service is created and configured in the AAA context.

> • | Multiple APNs can be configured to support different domain names.

> • | The accounting-mode gtpp and gtpp group commands configure this APN for Gz accounting.

> Creating and Configuring AAA Groups in the P-GW Context
> Use the following example to create and configure AAA groups supporting RADIUS and Rf accounting:
> configure
> context <pgw_context_name> -noconfirm
> aaa group <rf-radius_group_name>
> radius attribute nas-identifier <id>
> radius accounting interim interval <seconds>
> radius dictionary <name>
> radius mediation-device accounting server <address> key <key>
> diameter authentication dictionary <name>
> diameter accounting dictionary <name>
> diameter accounting endpoint <rf_cfg_name>
> diameter accounting server <rf_cfg_name> priority <num>
> exit
> aaa group default
> radius attribute nas-ip-address address <ipv4_address>
> radius accounting interim interval <seconds>
> diameter authentication dictionary <name>
> diameter accounting dictionary <name>
> diameter accounting endpoint <rf_cfg_name>
> diameter accounting server <rf_cfg_name> priority <num>
> Creating and Configuring an eGTP Service
> Use the following configuration example to create the eGTP service:
> configure
> context <pgw_context_name>
> egtp-service <egtp_service_name> -noconfirm
> interface-type interface-pgw-ingress
> validation mode default
> associate gtpu-service <gtpu_service_name>
> gtpc bind address <s5s8_interface_address>
> end
> Notes:

> • | Co-locating a GGSN service on the same ASR 5x00 requires that the gtpc bind address command uses the same IP address the GGSN service is bound to.

> Creating and Configuring a GTP-U Service
> Use the following configuration example to create the GTP-U service:
> configure
> context <pgw_context_name>
> gtpu-service <gtpu_service_name> -noconfirm
> bind ipv4-address <s5s8_interface_address>
> end
> Notes:

> • | The bind command can also be specified as an IPv6 address using the ipv6-address command.

> Creating a P-GW PDN Context
> Use the following example to create a P-GW PDN context and Ethernet interface, and bind the interface to a configured Ethernet port.
> configure
> context <pdn_context_name> -noconfirm
> interface <sgi_ipv4_interface_name>
> ip address <ipv4_address>
> interface <sgi_ipv6_interface_name>
> ipv6 address <address>
> end
> P-GW Service Configuration

> Step 1 | Configure the P-GW service by applying the example configuration in the Configuring the P-GW Service section.

> Step 2 | Specify an IP route to the eGTP Serving Gateway by applying the example configuration in the Configuring a Static IP Route section.

> Configuring the P-GW Service
> Use the following example to configure the P-GW service:
> configure
> context <pgw_context_name>
> pgw-service <pgw_service_name> -noconfirm
> plmn id mcc <id> mnc <id>
> associate egtp-service <egtp_service_name>
> associate qci-qos-mapping <name>
> end
> Notes:

> • | QCI-QoS mapping configurations are created in the AAA context. Refer to the Configuring QCI-QoS Mapping section for more information.

> • | Co-locating a GGSN service on the same ASR 5x00 requires the configuration of the associate ggsn-servie name command within the P-GW service.

> Configuring a Static IP Route
> Use the following example to configure an IP Route for control and user plane data communication with an eGTP Serving Gateway:
> configure
> context <pgw_context_name>
> ip route <sgw_ip_addr/mask> <sgw_next_hop_addr> <pgw_intrfc_name>
> end
> P-GW PDN Context Configuration
> Use the following example to configure an IP Pool and APN, and bind a port to the interface in the PDN context:
> configure
> context <pdn_context_name> -noconfirm
> interface <sgi_ipv4_interface_name>
> ip address <ipv4_address>
> exit
> interface <sgi_ipv6_interface_name>
> ip address <ipv6_address>
> exit
> ip pool <name> range <start_address end_address> public <priority>
> ipv6 pool <name> range <start_address end_address> public <priority>
> subscriber default
> exit
> ip access-list <name>
> redirect css service <name> any
> permit any
> exit
> ipv6 access-list <name>
> redirect css service <name> any
> permit any
> exit
> aaa group default
> exit
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <sgi_ipv4_interface_name> <pdn_context_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <sgi_ipv6_interface_name> <pdn_context_name>
> end
> Active Charging Service Configuration
> Use the following example to enable and configure active charging:
> configure
> require active-charging optimized-mode
> active-charging service <name>
> ruledef <name>
> <rule_definition>
> .
> .
> <rule_definition>
> exit
> ruledef default
> ip any-match = TRUE
> exit
> ruledef icmp-pkts
> icmp any-match = TRUE
> exit
> ruledef qci3
> icmp any-match = TRUE
> exit
> ruledef static
> icmp any-match = TRUE
> exit
> charging-action <name>
> <action>
> .
> .
> <action>
> exit
> charging-action icmp
> billing-action egcdr
> exit
> charging-action qci3
> content-id <id>
> billing-action egcdr
> qos-class-identifier <id>
> allocation-retention-priority <priority>
> tft-packet-filter qci3
> exit
> charging-action static
> service-identifier <id>
> billing-action egcdr
> qos-class-identifier <id>
> allocation-retention-priority <priority>
> tft-packet-filter qci3
> exit
> rulebase default
> exit
> rulebase <name>
> <rule_base>
> .
> .
> <rule_base>
> exit
> rulebase <gx_rulebase_name>
> dynamic-rule order first-if-tied
> egcdr tariff minute <minute> hour <hour>(optional)
> billing-records egcdr
> action priority 5 dynamic-only ruledef qci3 charging-action qci3
> action priority 100 ruledef static charging-action static
> action priority 500 ruledef default charging-action icmp
> action priority 570 ruledef icmp-pkts charging-action icmp
> egcdr threshold interval <interval>
> egcdr threshold volume total <bytes>
> end
> Notes:

> • | A rule base is a collection of rule definitions and associated charging actions.

> • | As depicted above, multiple rule definitions, charging actions, and rule bases can be configured to support a variety of charging scenarios.

> • | Charging actions define the action to take when a rule definition is matched.

> • | Routing and/or charging rule definitions can be created/configured. The maximum number of routing rule definitions that can be created is 256. The maximum number of charging rule definitions is 2048.

> • | The billing-action egcdr command in the charging-action qc13, icmp, and static examples is required for Gz accounting.

> • | The Gz rulebase example supports the Gz interface for off-line charging. The billing-records egcdr command is required for Gz accounting. All other commands are optional.

> Policy Configuration

> Step 1 | Configure the policy and accounting interfaces by applying the example configuration in the Creating and Configuring the AAA Context section.

> Step 2 | Create and configure QCI to QoS mapping by applying the example configuration in the Configuring QCI-QoS Mapping section.

> Creating and Configuring the AAA Context
> Use the following example to create and configure a AAA context including diameter support and policy control, and bind Ethernet ports to interfaces supporting traffic between this context and a PCRF, an OCS, and an OFCS:
> configure
> context <aaa_context_name> -noconfirm
> interface <gx_interface_name>
> ipv6 address <address>
> exit
> interface <gy_interface_name>
> ipv6 address <address>
> exit
> interface <gz_interface_name>
> ip address <ipv4_address>
> exit
> interface <rf_interface_name>
> ip address <ipv4_address>
> exit
> subscriber default
> exit
> ims-auth-service <gx_ims_service_name>
> p-cscf discovery table <#> algorithm round-robin
> p-cscf table <#> row-precedence <#> ipv6-address <pcrf_ipv6_adr>
> policy-control
> diameter origin endpoint <gx_cfg_name>
> diameter dictionary <name>
> diameter host-select table <#> algorithm round-robin
> diameter host-select row-precedence <#> table <#> host <gx_cfg_name>
> exit
> exit
> diameter endpoint <gx_cfg_name>
> origin realm <realm_name>
> origin host <name> address <aaa_ctx_ipv6_address>
> peer <gx_cfg_name> realm <name> address <pcrf_ipv4_or_ipv6_addr>
> route-entry peer <gx_cfg_name>
> exit
> diameter endpoint <gy_cfg_name>
> origin realm <realm_name>
> origin host <name> address <gy_ipv6_address>
> connection retry-timeout <seconds>
> peer <gy_cfg_name> realm <name> address <ocs_ipv4_or_ipv6_addr>
> route-entry peer <gy_cfg_name>
> exit
> diameter endpoint <rf_cfg_name>
> use-proxy
> origin realm <realm_name>
> origin host <name> address <rf_ipv4_address>
> peer <rf_cfg_name> realm <name> address <ofcs_ipv4_or_ipv6_addr>
> route-entry peer <rf_cfg_name>
> exit
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <gx_interface_name> <aaa_context_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <gy_interface_name> <aaa_context_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <gz_interface_name> <aaa_context_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <rf_interface_name> <aaa_context_name>
> end
> Notes:

> • | The p-cscf table command under ims-auth-service can also specify an IPv4 address to the PCRF.

> • | The Gx interface IP address can also be specified as an IPv4 address using the ip address command.

> • | The Gy interface IP address can also be specified as an IPv4 address using the ip address command.

> • | The Rf interface IP address can also be specified as an IPv6 address using the ipv6 address command.

> Configuring QCI-QoS Mapping
> Use the following example to create and map QCI values to enforceable QoS parameters:
> configure
> qci-qos-mapping <name>
> qci 1 user-datagram dscp-marking <hex>
> qci 3 user-datagram dscp-marking <hex>
> qci 9 user-datagram dscp-marking <hex>
> exit
> Notes:

> • | QCI values 1 through 9 are standard values and are defined in 3GPP TS 23.203. Values 10 through 32 can be configured for non-standard use.

> • | The above configuration only shows one keyword example. Refer to the QCI - QOS Mapping Configuration Mode Commands chapter in the Command Line Interface Reference for more information on the qci command and other supported keywords.

> Verifying and Saving the Configuration
> Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
> Configuring the System as a Standalone PMIP P-GW Supporting an eHRPD Network
> This section provides a high-level series of steps and the associated configuration file examples for configuring the system to perform as a P-MIP P-GW supporting an eHRPD test environment. For a complete configuration file example, refer to the Sample Configuration Files appendix. Information provided in this section includes the following:

> • | Information Required

> • | How This Configuration Works

> • | P-MIP P-GW (eHRPD) Configuration

> Information Required
> The following sections describe the minimum amount of information required to configure and make the P-GW operational on the network. To make the process more efficient, it is recommended that this information be available prior to configuring the system.
> There are additional configuration parameters that are not described in this section. These parameters deal mostly with fine-tuning the operation of the P-GW in the network. Information on these parameters can be found in the appropriate sections of the Command Line Interface Reference.
> Required Local Context Configuration Information
> The following table lists the information that is required to configure the local context on an P-GW.
> Required Information for Local Context Configuration

> Required Information | Description
> Management Interface Configuration
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface will be recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the management interface(s) to a specific network.
> Security administrator name | The name or names of the security administrator with full rights to the system.
> Security administrator password | Open or encrypted passwords can be used.
> Remote access type(s) | The type of remote access that will be used to access the system such as telnetd, sshd, and/or ftpd.

> ‌
> Required P-GW Context Configuration Information
> The following table lists the information that is required to configure the P-GW context on a P-GW.
> Required Information for P-GW Context Configuration

> Required Information | Description
> P-GW context name | An identification string from 1 to 79 characters (alpha and/or numeric) by which the P-GW context will be recognized by the system.
> Accounting policy name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the accounting policy will be recognized by the system. The accounting policy is used to set parameters for the Rf (off-line charging) interface.
> S2a Interface Configuration (To/from HSGW)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface will be recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> P-GW Service Configuration
> P-GW service name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the P-GW service will be recognized by the system. Multiple names are needed if multiple P-GW services will be used.
> PLMN ID | MCC number: The mobile country code (MCC) portion of the PLMN’s identifier (an integer value between 100 and 999). MNC number: The mobile network code (MNC) portion of the PLMN’s identifier (a 2 or 3 digit integer value between 00 and 999).
> LMA Service Configuration
> LMA Service Name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the LMA service will be recognized by the system.

> ‌
> Required PDN Context Configuration Information
> The following table lists the information that is required to configure the PDN context on a P-GW.
> Required Information for PDN Context Configuration

> Required Information | Description
> P-GW context name | An identification string from 1 to 79 characters (alpha and/or numeric) by which the P-GW context is recognized by the system.
> IP Address Pool Configuration
> IPv4 address pool name and range | An identification string between 1 and 31 characters (alpha and/or numeric) by which the IPv4 pool is recognized by the system. Multiple names are needed if multiple pools will be configured. A range of IPv4 addresses defined by a starting address and an ending address.
> IPv6 address pool name and range | An identification string between 1 and 31 characters (alpha and/or numeric) by which the IPv6 pool is recognized by the system. Multiple names are needed if multiple pools will be configured. A range of IPv6 addresses defined by a starting address and an ending address.
> Access Control List Configuration
> IPv4 access list name | An identification string between 1 and 47 characters (alpha and/or numeric) by which the IPv4 access list is recognized by the system. Multiple names are needed if multiple lists will be configured.
> IPv6 access list name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the IPv6 access list is recognized by the system. Multiple names are needed if multiple lists will be configured.
> Deny/permit type | The types are:
> • | any
> • | by host IP address
> • | by IP packets
> • | by source ICMP packets
> • | by source IP address masking
> • | by TCP/UDP packets
> Readdress or redirect type | The types are
> • | readdress server
> • | redirect context
> • | redirect css delivery-sequence
> • | redirect css service
> • | redirect nexthop
> SGi Interface Configuration (To/from IPv4 PDN)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> SGi Interface Configuration (To/from IPv6 PDN)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.

> ‌
> Required AAA Context Configuration Information
> The following table lists the information that is required to configure the AAA context on a P-GW.
> Required Information for AAA Context Configuration

> Required Information | Description
> Gx Interface Configuration (to PCRF)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 or IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> Gx Diameter Endpoint Configuration
> End point name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the Gx Diameter endpoint configuration is recognized by the system.
> Origin realm name | An identification string between 1 through 127 characters. The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.
> Origin host name | An identification string from 1 to 255 characters (alpha and/or numeric) by which the Gx origin host is recognized by the system.
> Origin host address | The IP address of the Gx interface.
> Peer name | The Gx endpoint name described above.
> Peer realm name | The Gx origin realm name described above.
> Peer address and port number | The IP address and port number of the PCRF.
> Route-entry peer | The Gx endpoint name described above.
> S6b Interface Configuration (to 3GPP AAA server)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 or IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> S6b Diameter Endpoint Configuration
> End point name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the S6b Diameter endpoint configuration is recognized by the system.
> Origin realm name | An identification string between 1 through 127 characters. The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.
> Origin host name | An identification string from 1 to 255 characters (alpha and/or numeric) by which the S6b origin host is recognized by the system.
> Origin host address | The IP address of the S6b interface.
> Peer name | The S6b endpoint name described above.
> Peer realm name | The S6b origin realm name described above.
> Peer address and port number | The IP address and port number of the AAA server.
> Route-entry peer | The S6b endpoint name described above.
> Rf Interface Configuration (to off-line charging server)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 or IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the management interface(s) to a specific network.
> Rf Diameter Endpoint Configuration
> End point name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the Rf Diameter endpoint configuration is recognized by the system.
> Origin realm name | An identification string between 1 through 127 characters. The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.
> Origin host name | An identification string from 1 to 255 characters (alpha and/or numeric) by which the Rf origin host is recognized by the system.
> Origin host address | The IP address of the Rf interface.
> Peer name | The Rf endpoint name described above.
> Peer realm name | The Rf origin realm name described above.
> Peer address and port number | The IP address and port number of the OFCS.
> Route-entry peer | The Rf endpoint name described above.
> Gy Interface Configuration (to on-line charging server)
> Interface name | An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system. Multiple names are needed if multiple interfaces will be configured.
> IP address and subnet | IPv4 or IPv6 addresses assigned to the interface. Multiple addresses and subnets are needed if multiple interfaces will be configured.
> Physical port number | The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Gateway IP address | Used when configuring static IP routes from the interface(s) to a specific network.
> Gy Diameter Endpoint Configuration
> End point name | An identification string from 1 to 63 characters (alpha and/or numeric) by which the Gy Diameter endpoint configuration is recognized by the system.
> Origin realm name | An identification string between 1 through 127 characters. The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.
> Origin host name | An identification string from 1 to 255 characters (alpha and/or numeric) by which the Gy origin host is recognized by the system.
> Origin host address | The IP address of the Gy interface.
> Peer name | The Gy endpoint name described above.
> Peer realm name | The Gy origin realm name described above.
> Peer address and port number | The IP address and port number of the OCS.
> Route-entry peer | The Gy endpoint name described above.

> ‌
> How This Configuration Works
> The following figure and supporting text describe how this configuration with a single source and destination context is used by the system to process a subscriber call originating from the GTP LTE network.

> 1. | The S-GW establishes the S5/S8 connection by sending a Create Session Request message to the P-GW including an Access Point name (APN).

> 2. | The P-GW service determines which context to use to provide AAA functionality for the session. This process is described in the How the System Selects Contexts section located in the Understanding the System Operation and Configuration chapter of the System Administration Guide.

> 3. | The P-GW uses the configured Gx Diameter endpoint to establish the IP-CAN session.

> 4. | The P-GW sends a CC-Request (CCR) message to the PCRF to indicate the establishment of the IP-CAN session and the PCRF acknowledges with a CC-Answer (CCA).

> 5. | The P-GW uses the APN configuration to select the PDN context. IP addresses are assigned from the IP pool configured in the selected PDN context.

> 6. | The P-GW responds to the S-GW with a Create Session Response message including the assigned address and additional information.

> 7. | The S5/S8 data plane tunnel is established and the P-GW can forward and receive packets to/from the PDN.

> P-MIP P-GW (eHRPD) Configuration
> To configure the system to perform as a standalone P-MIP P-GW in an eHRPD network environment, review the following graphic and subsequent steps.

> Step 1 | Set system configuration parameters such as activating PSCs by applying the example configurations found in the System Administration Guide.

> Step 2 | Set initial configuration parameters such as creating contexts and services by applying the example configurations found in the Initial Configuration section of this chapter.

> Step 3 | Configure the system to perform as a P-MIP P-GW and set basic P-GW parameters such as P-MIP interfaces and an IP route by applying the example configurations presented in the P-GW Service Configuration section.

> Step 4 | Configure the PDN context by applying the example configuration in the P-GW PDN Context Configuration section.

> Step 5 | Enable and configure the active charging service for Gx interface support by applying the example configuration in the Active Charging Service Configuration section.

> Step 6 | Create a AAA context and configure parameters for AAA and policy by applying the example configuration in the AAA and Policy Configuration section.

> Step 7 | Verify and save the configuration by following the instruction in the Verifying and Saving the Configuration section.

> Initial Configuration

> Step 1 | Set local system management parameters by applying the example configuration in the Modifying the Local Context section.

> Step 2 | Create the context where the P-GW service will reside by applying the example configuration in the Creating and Configuring a P-MIP P-GW Context section.

> Step 3 | Create and configure APNs in the P-GW context by applying the example configuration in the Creating and Configuring APNs in the P-GW Context section.

> Step 4 | Create and configure AAA server groups in the P-GW context by applying the example configuration in the Creating and Configuring AAA Groups in the P-GW Context section.

> Step 5 | Create an eGTP service within the newly created context by applying the example configuration in the Creating and Configuring an LMA Service section.

> Step 6 | Create a context through which the interface to the PDN will reside by applying the example configuration in the Creating a P-GW PDN Context section.

> Modifying the Local Context
> Use the following example to set the default subscriber and configure remote access capability in the local context:
> configure
> context local
> interface <lcl_cntxt_intrfc_name>
> ip address <ip_address> <ip_mask>
> exit
> server ftpd
> exit
> server telnetd
> exit
> subscriber default
> exit
> administrator <name> encrypted password <password> ftp
> ip route <ip_addr/ip_mask> <next_hop_addr> <lcl_cntxt_intrfc_name>
> exit
> port ethernet <slot#/port#>
> no shutdown
> bind interface <lcl_cntxt_intrfc_name> local
> end
> Creating and Configuring a P-MIP P-GW Context
> Use the following example to create a P-GW context, create an S2a IPv6 interface (for data traffic to/from the HSGW), and bind the S2a interface to a configured Ethernet port:
> configure
> context <pgw_context_name> -noconfirm
> interface <s2a_interface_name> tunnel
> ipv6 address <address>
> tunnel-mode ipv6ip
> source interface <name>
> destination address <ipv4 or ipv6 address>
> exit
> exit
> policy accounting <rf_policy_name> -noconfirm
> accounting-level {level_type}
> accounting-event-trigger interim-timeout action stop-start
> operator-string <string>
> cc profile <index> interval <seconds>
> exit
> subscriber default
> exit
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <s2a_interface_name> <pgw_context_name>
> end
> Notes:

> • | The S2a (P-GW to HSGW) interface must be an IPv6 address.

> • | Set the accounting policy for the Rf (off-line charging) interface. The accounting level types are: flow, PDN, PDN-QCI, QCI, and subscriber. Refer to the Accounting Profile Configuration Mode Commands chapter in the Command Line Interface Reference for more information on this command.

> Creating and Configuring APNs in the P-GW Context
> Use the following configuration to create an APN:
> configure
> context <pgw_context_name> -noconfirm
> apn <name>
> accounting-mode radius-diameter
> associate accounting-policy <rf_policy_name>
> ims-auth-service <gx_ims_service_name>
> aaa group <rf-radius_group_name>
> dns primary <ipv4_address>
> dns secondary <ipv4_address>
> ip access-group <name> in
> ip access-group <name> out
> mediation-device context-name <pgw_context_name>
> ip context-name <pdn_context_name>
> ipv6 access-group <name> in
> ipv6 access-group <name> out
> active-charging rulebase <name>
> Notes:

> • | The IMS Authorization Service is created and configured in the AAA context.

> • | Multiple APNs can be configured to support different domain names.

> • | The associate accounting-policy command is used to associate a pre-configured accounting policy with this APN. Accounting policies are configured in the P-GW context. An example is located in the Creating and Configuring a P-MIP P-GW Context section above.

> Creating and Configuring AAA Groups in the P-GW Context
> Use the following example to create and configure AAA groups supporting RADIUS and Rf accounting:
> configure
> context <pgw_context_name> -noconfirm
> aaa group <rf-radius_group_name>
> radius attribute nas-identifier <id>
> radius accounting interim interval <seconds>
> radius dictionary <name>
> radius mediation-device accounting server <address> key <key>
> diameter authentication dictionary <name>
> diameter accounting dictionary <name>
> diameter authentication endpoint <s6b_cfg_name>
> diameter accounting endpoint <rf_cfg_name>
> diameter authentication server <s6b_cfg_name> priority <num>
> diameter accounting server <rf_cfg_name> priority <num>
> exit
> aaa group default
> radius attribute nas-ip-address address <ipv4_address>
> radius accounting interim interval <seconds>
> diameter authentication dictionary <name>
> diameter accounting dictionary <name>
> diameter authentication endpoint <s6b_cfg_name>
> diameter accounting endpoint <rf_cfg_name>
> diameter authentication server <s6b_cfg_name> priority <num>
> diameter accounting server <rf_cfg_name> priority <num>
> Creating and Configuring an LMA Service
> Use the following configuration example to create the LMA service:
> configure
> context <pgw_context_name>
> lma-service <lma_service_name> -noconfirm
> no aaa accounting
> revocation enable
> bind address <s2a_ipv6_address>
> end
> Notes:

> • | The no aaa acounting command is used to prevent duplicate accounting packets.

> • | Enabling revocation provides for MIP registration revocation in the event that MIP revocation is negotiated with a MAG and a MIP binding is terminated, the LMA can send a revocation message to the MAG.

> Creating a P-GW PDN Context
> Use the following example to create a P-GW PDN context and Ethernet interfaces.
> configure
> context <pdn_context_name> -noconfirm
> interface <sgi_ipv4_interface_name>
> ip address <ipv4_address>
> exit
> interface <sgi_ipv6_interface_name>
> ipv6 address <address>
> end
> P-GW Service Configuration

> Step 1 | Configure the P-GW service by applying the example configuration in the Configuring the P-GW Service section.

> Step 2 | Specify an IP route to the HRPD Serving Gateway by applying the example configuration in the Configuring a Static IP Route section.

> Configuring the P-GW Service
> Use the following example to configure the P-GW service:
> configure
> context <pgw_context_name>
> pgw-service <pgw_service_name> -noconfirm
> associate lma-service <lma_service_name>
> associate qci-qos-mapping <name>
> authorize external
> fqdn host <domain_name> realm <realm_name>
> plmn id mcc <id> mnc <id>
> end
> Notes:

> • | QCI-QoS mapping configurations are created in the AAA context. Refer to the Configuring QCI-QoS Mapping section for more information.

> • | External authorization is performed by the 3GPP AAA server through the S6b interface. Internal authorization (APN) is default.

> • | The fqdn host command configures a Fully Qualified Domain Name for the P-GW service used in messages between the P-GW and a 3GPP AAA server over the S6b interface.

> Configuring a Static IP Route
> Use the following example to configure static IP routes for data traffic between the P-GW and the HSGW:
> configure
> context <pgw_context_name>
> ipv6 route <ipv6_addr/prefix> next-hop <hsgw_addr> interface <pgw_hsgw_intrfc_name>
> end
> Notes:

> • | Static IP routing is not required for configurations using dynamic routing protocols.

> P-GW PDN Context Configuration
> Use the following example to configure IP pools and IP Access Control Lists (ACLs), and bind ports to the interfaces in the PDN context:
> configure
> context <pdn_context_name> -noconfirm
> ip pool <name> range <start_address end_address> public <priority>
> ipv6 pool <name> range <start_address end_address> public <priority>
> subscriber default
> exit
> ip access-list <name>
> redirect css service <name> any
> permit any
> exit
> ipv6 access-list <name>
> redirect css service <name> any
> permit any
> exit
> aaa group default
> exit
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <pdn_sgi_ipv4_interface_name> <pdn_context_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <pdn_sgi_ipv6_interface_name> <pdn_context_name>
> end
> Active Charging Service Configuration
> Use the following example to enable and configure active charging:
> configure
> require active-charging optimized-mode
> active-charging service <name>
> ruledef <name>
> <rule_definition>
> .
> .
> <rule_definition>
> exit
> ruledef <name>
> <rule_definition>
> .
> .
> <rule_definition>
> exit
> charging-action <name>
> <action>
> .
> .
> <action>
> exit
> charging-action <name>
> <action>
> .
> .
> <action>
> exit
> rulebase default
> exit
> rulebase <name>
> <rule_base>
> .
> .
> <rule_base>
> end
> Notes:

> • | Active charging in optimized mode enables the service as part of the session manager instead of part of ACS managers.

> • | As depicted above, multiple rule definitions, charging actions, and rule bases can be configured to support a variety of charging scenarios.

> • | Routing and/or charging rule definitions can be created/configured. The maximum number of routing rule definitions that can be created is 256. The maximum number of charging rule definitions is 2048.

> • | Charging actions define the action to take when a rule definition is matched.

> • | A rule base is a collection of rule definitions and associated charging actions.

> AAA and Policy Configuration

> Step 1 | Configure AAA and policy interfaces by applying the example configuration in the Creating and Configuring the AAA Context section.

> Step 2 | Create and configure QCI to QoS mapping by applying the example configuration in the Configuring QCI-QoS Mapping section.

> Creating and Configuring the AAA Context
> Use the following example to create and configure a AAA context including diameter support and policy control, and bind ports to interfaces supporting traffic between this context, a PCRF, a 3GPP AAA server, an on-line charging server, and an off-line charging server:
> configure
> context <aaa_context_name> -noconfirm
> interface <s6b_interface_name>
> ip address <ipv4_address>
> exit
> interface <gx_interface_name>
> ipv6 address <address>
> exit
> interface <rf_interface_name>
> ip address <ipv4_address>
> exit
> interface <gy_interface_name>
> ipv6 address <address>
> exit
> subscriber default
> exit
> ims-auth-service <gx_ims_service_name>
> p-cscf discovery table <#> algorithm round-robin
> p-cscf table <#> row-precedence <#> ipv6-address <pcrf_adr>
> policy-control
> diameter origin endpoint <gx_cfg_name>
> diameter dictionary <name>
> diameter host-select table <#> algorithm round-robin
> diameter host-select row-precedence <#> table <#> host <gx_cfg_name>
> exit
> exit
> diameter endpoint <s6b_cfg_name>
> origin realm <realm_name>
> origin host <name> address <aaa_ctx_ipv4_address>
> peer <s6b_cfg_name> realm <name> address <aaa_ip_addr>
> route-entry peer <s6b_cfg_name>
> exit
> diameter endpoint <gx_cfg_name>
> origin realm <realm_name>
> origin host <name> address <aaa_context_ip_address>
> peer <gx_cfg_name> realm <name> address <pcrf_ipv6_addr>
> route-entry peer <gx_cfg_name>
> exit
> diameter endpoint <rf_cfg_name>
> origin realm <realm_name>
> origin host <name> address <aaa_ip_address>
> peer <rf_cfg_name> realm <name> address <ofcs_ip_addr>
> route-entry peer <rf_cfg_name>
> exit
> diameter endpoint <gy_cfg_name>
> use-proxy
> origin realm <realm_name>
> origin host <name> address <aaa_ip_address>
> connection retry-timeout <seconds>
> peer <gy_cfg_name> realm <name> address <ocs_ip_addr>
> route-entry peer <gy_cfg_name>
> exit
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <s6b_interface_name> <aaa_context_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <gx_interface_name> <aaa_context_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <gy_interface_name> <aaa_context_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <rf_interface_name> <aaa_context_name>
> end
> Notes:

> • | The p-cscf table command under ims-auth-service can also specify an IPv4 address to the PCRF.

> • | The S6b interface IP address can also be specified as an IPv6 address using the ipv6 address command.

> • | The Gx interface IP address can also be specified as an IPv4 address using the ip address command.

> • | The Gy interface IP address can also be specified as an IPv4 address using the ip address command.

> • | The Rf interface IP address can also be specified as an IPv6 address using the ipv6 address command.

> Configuring QCI-QoS Mapping
> Use the following example to create and map QCI values to enforceable QoS parameters:
> configure
> qci-qos-mapping <name>
> qci 1 user-datagram dscp-marking <hex>
> qci 3 user-datagram dscp-marking <hex>
> qci 9 user-datagram dscp-marking <hex>
> exit
> Notes:

> • | QCI values 1 through 9 are standard values and are defined in 3GPP TS 23.203. Values 10 through 32 can be configured for non-standard use.

> • | The above configuration only shows one keyword example. Refer to the QCI - QOS Mapping Configuration Mode Commands chapter in the Command Line Interface Reference for more information on the qci command and other supported keywords.

> Verifying and Saving the Configuration
> Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
> Configuring Optional Features on the P-GW
> The configuration examples in this section are optional and provided to cover the most common uses of the P-GW in a live network. The intent of these examples is to provide a base configuration for testing.
> The following optional configurations are provided in this section:

> • | Configuring ACL-based Node-to-Node IP Security on the S5 Interface

> • | Configuring APN as Emergency

> • | Configuring Dynamic Node-to-Node IP Security on the S5 Interface

> • | Configuring Local QoS Policy

> • | Configuring X.509 Certificate-based Peer Authentication

> Configuring ACL-based Node-to-Node IP Security on the S5 Interface
> The configuration example in this section creates an IKEv2/IPSec ACL-based node-to-node tunnel endpoint on the S5 interface.
> Important: Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
> The following configuration examples are included in this section:

> • | Creating and Configuring a Crypto Access Control List

> • | Creating and Configuring an IPSec Transform Set

> • | Creating and Configuring an IKEv2 Transform Set

> • | Creating and Configuring a Crypto Map

> Creating and Configuring a Crypto Access Control List
> The following example configures a crypto ACL (Access Control List), which defines the matching criteria used for routing subscriber data packets over an IPSec tunnel:
> configure
> context <pgw_context_name> -noconfirm
> ip access-list <acl_name>
> permit tcp host <source_host_address> host <dest_host_address>
> end
> Notes:

> • | The permit command in this example routes IPv4 traffic from the server with the specified source host IPv4 address to the server with the specified destination host IPv4 address.

> Creating and Configuring an IPSec Transform Set
> The following example configures an IPSec transform set, which is used to define the security association that determines the protocols used to protect the data on the interface:
> configure
> context <pgw_context_name> -noconfirm
> ipsec transform-set <ipsec_transform-set_name>
> encryption aes-cbc-128
> group none
> hmac sha1-96
> mode tunnel
> end
> Notes:

> • | The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IPSec transform sets configured on the system.

> • | The group none command specifies that no crypto strength is included and that Perfect Forward Secrecy is disabled. This is the default setting for IPSec transform sets configured on the system.

> • | The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IPSec transform sets configured on the system.

> • | The mode tunnel command specifies that the entire packet is to be encapsulated by the IPSec header including the IP header. This is the default setting for IPSec transform sets configured on the system.

> Creating and Configuring an IKEv2 Transform Set
> The following example configures an IKEv2 transform set:
> configure
> context <pgw_context_name> -noconfirm
> ikev2-ikesa transform-set <ikev2_transform-set_name>
> encryption aes-cbc-128
> group 2
> hmac sha1-96
> lifetime <sec>
> prf sha1
> end
> Notes:

> • | The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IKEv2 transform sets configured on the system.

> • | The group 2 command specifies the Diffie-Hellman algorithm as Group 2, indicating medium security. The Diffie-Hellman algorithm controls the strength of the crypto exponentials. This is the default setting for IKEv2 transform sets configured on the system.

> • | The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

> • | The lifetime command configures the time the security key is allowed to exist, in seconds.

> • | The prf command configures the IKE Pseudo-random Function which produces a string of bits that cannot be distinguished from a random bit string without knowledge of the secret key. The sha1 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

> Creating and Configuring a Crypto Map
> The following example configures an IKEv2 crypto map:
> configure
> context <pgw_context_name>
> crypto map <crypto_map_name> ikev2-ipv4
> match address <acl_name>
> peer <ipv4_address>
> authentication local pre-shared-key key <text>
> authentication remote pre-shared-key key <text>
> ikev2-ikesa transform-set list <name1> . . . name6>
> payload <name> match ipv4
> lifetime <seconds>
> ipsec transform-set list <name1> . . . <name4>
> exit
> exit
> interface <s5_intf_name>
> ip address <ipv4_address>
> crypto-map <crypto_map_name>
> exit
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <s5_intf_name> <pgw_context_name>
> end
> Notes:

> • | The type of crypto map used in this example is IKEv2/IPv4 for IPv4 addressing. An IKEv2/IPv6 crypto map can also be used for IPv6 addressing.

> • | The ipsec transform-set list command specifies up to four IPSec transform sets.

> Configuring APN as Emergency
> The configuration example in this section configures an emergency APN for VoLTE based E911 support.
> In APN Configuration Mode, specify the name of the emergency APN and set the emergency inactivity timeout as follows. You may also configure the P-CSCF FQDN server name for the APN.
> configure
> context <pgw_context_name> -noconfirm
> apn <name>
> emergency-apn
> timeout emergency-inactivity <seconds>
> p-cscf fqdn <fqdn>
> end
> Notes:

> • | By default, an APN is assumed to be non-emergency.

> • | The timeout emergency-inactivity command specifies the timeout duration, in seconds, to check inactivity on the emergency session. <seconds> must be an integer value from 1 through 3600.

> • | By default, emergency inactivity timeout is disabled (0).

> • | The p-cscf fqdn command configures the P-CSCF FQDN server name for the APN. <fqdn> must be a string from 1 to 256 characters in length.

> • | P-CSCF FQDN has more significance than CLI-configured P-CSCF IPv4 and IPv6 addresses.

> Configuring Dynamic Node-to-Node IP Security on the S5 Interface
> The configuration example in this section creates an IPSec/IKEv2 dynamic node-to-node tunnel endpoint on the S5 interface.
> Important: Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
> The following configuration examples are included in this section:

> • | Creating and Configuring an IPSec Transform Set

> • | Creating and Configuring an IKEv2 Transform Set

> • | Creating and Configuring a Crypto Template

> • | Binding the S5 IP Address to the Crypto Template

> Creating and Configuring an IPSec Transform Set
> The following example configures an IPSec transform set, which is used to define the security association that determines the protocols used to protect the data on the interface:
> configure
> context <pgw_context_name> -noconfirm
> ipsec transform-set <ipsec_transform-set_name>
> encryption aes-cbc-128
> group none
> hmac sha1-96
> mode tunnel
> end
> Notes:

> • | The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IPSec transform sets configured on the system.

> • | The group none command specifies that no crypto strength is included and that Perfect Forward Secrecy is disabled. This is the default setting for IPSec transform sets configured on the system.

> • | The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IPSec transform sets configured on the system.

> • | The mode tunnel command specifies that the entire packet is to be encapsulated by the IPSec header, including the IP header. This is the default setting for IPSec transform sets configured on the system.

> Creating and Configuring an IKEv2 Transform Set
> The following example configures an IKEv2 transform set:
> configure
> context <pgw_context_name> -noconfirm
> ikev2-ikesa transform-set <ikev2_transform-set_name>
> encryption aes-cbc-128
> group 2
> hmac sha1-96
> lifetime <sec>
> prf sha1
> end
> Notes:

> • | The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IKEv2 transform sets configured on the system.

> • | The group 2 command specifies the Diffie-Hellman algorithm as Group 2, indicating medium security. The Diffie-Hellman algorithm controls the strength of the crypto exponentials. This is the default setting for IKEv2 transform sets configured on the system.

> • | The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

> • | The lifetime command configures the time the security key is allowed to exist, in seconds.

> • | The prf command configures the IKE Pseudo-random Function, which produces a string of bits that cannot be distinguished from a random bit string without knowledge of the secret key. The sha1 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

> Creating and Configuring a Crypto Template
> The following example configures an IKEv2 crypto template:
> configure
> context <pgw_context_name> -noconfirm
> crypto template <crypto_template_name> ikev2-dynamic
> ikev2-ikesa transform-set list <name1> . . . <name6>
> ikev2-ikesa rekey
> payload <name> match childsa match ipv4
> ipsec transform-set list <name1> . . . <name4>
> rekey
> end
> Notes:

> • | The ikev2-ikesa transform-set list command specifies up to six IKEv2 transform sets.

> • | The ipsec transform-set list command specifies up to four IPSec transform sets.

> Binding the S5 IP Address to the Crypto Template
> The following example configures the binding of the S5 interface to the crypto template:
> configure
> context <pgw_ingress_context_name> -noconfirm
> gtpu-service <gtpu_ingress_service_name>
> bind ipv4-address <s5_interface_ip_address> crypto-template <sgw_s5_crypto_template>
> exit
> egtp-service <egtp_ingress_service_name>
> interface-type interface-pgw-ingress
> associate gtpu-service <gtpu_ingress_service_name>
> gtpc bind ipv4-address <s5_interface_ip_address>
> exit
> pgw-service <pgw_service_name> -noconfirm
> plmn id mcc <id> mnc <id> primary
> associate egtp-service <egtp_ingress_service_name>
> end
> Notes:

> • | The bind command in the GTP-U and eGTP service configuration can also be specified as an IPv6 address using the ipv6-address command.

> Configuring Local QoS Policy
> The configuration examples in this section creates a local QoS policy. A local QoS policy service can be used to control different aspects of a session, such as QoS, data usage, subscription profiles, or server usage, by means of locally defined policies.
> Important: Local QoS Policy is a licensed feature and requires the purchase of the Local Policy Decision Engine feature license to enable. it.
> The following configuration examples are included in this section:

> • | Creating and Configuring a Local QoS Policy

> • | Binding a Local QoS Policy

> • | Verifying Local QoS Policy

> Creating and Configuring a Local QoS Policy
> The following configuration example enables a local QoS policy on the P-GW:
> configure
> local-policy-service <name> -noconfirm
> ruledef <ruledef_name> -noconfirm
> condition priority <priority> <variable> match <string_value>
> condition priority <priority> <variable> match <int_value>
> condition priority <priority> <variable> nomatch <regex>
> exit
> actiondef <actiondef_name> -noconfirm
> action priority <priority> <action_name> <arguments>
> action priority <priority> <action_name> <arguments>
> exit
> actiondef <actiondef_name> -noconfirm
> action priority <priority> <action_name> <arguments>
> action priority <priority> <action_name> <arguments>
> exit
> eventbase <eventbase_name> -noconfirm
> rule priority <priority> event <list_of_events> ruledef <ruledef_name> actiondef <actiondef_name>
> end
> Notes:

> • | A maximum of 16 local QoS policy services are supported.

> • | A maximum 256 ruledefs are suggested in a local QoS policy service for performance reasons.

> • | The condition command can be entered multiple times to configure multiple conditions for a ruledef. The conditions are examined in priority order until a match is found and the corresponding condition is applied.

> • | A maximum of 256 actiondefs are suggested in a local QoS policy service for performance reasons.

> • | The action command can be entered multiple times to configure multiple actions for an actiondef. The actions are examined in priority order until a match is found and the corresponding action is applied.

> • | Currently, only one eventbase is supported and must be named “default”.

> • | The rule command can be entered multiple times to configure multiple rules for an eventbase.

> • | A maximum of 256 rules are suggested in an eventbase for performance reasons.

> • | Rules are executed in priority order, and if the rule is matched the action specified in the actiondef is executed. If an event qualifier is associated with a rule, the rule is matched only for that specific event. If a qualifier of continue is present at the end of the rule, the subsequent rules are also matched; otherwise, rule evaluation is terminated on first match.

> Binding a Local QoS Policy
> The following configuration example binds the previously configured local QoS policy:
> configure
> context <pgw_context_name> -noconfirm
> apn <name>
> ims-auth-service <local-policy-service name>
> end
> Notes:

> • | A maximum of 16 authorization services can be configured globally in the system. There is also a system limit for the maximum number of total configured services.

> Verifying Local QoS Policy
> The following configuration example verifies if local QoS service is enforced:
> logging filter active facility local-policy level debug
> logging active
> show local-policy statistics all
> Notes:

> • | Please take extreme caution not to use logging feature in console port and in production nodes.

> Configuring X.509 Certificate-based Peer Authentication
> The configuration example in this section enables X.509 certificate-based peer authentication, which can be used as the authentication method for IP Security on the P-GW.
> Important: Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
> The following configuration example enables X.509 certificate-based peer authentication on the P-GW.
> In Global Configuration Mode, specify the name of the X.509 certificate and CA certificate, as follows:
> configure
> certificate name <cert_name> pem url <cert_pem_url> private-key pem url <private_key_url>
> ca-certificate name <ca_cert_name> pem url <ca_cert_url>
> end
> Notes:

> • | The certificate name and ca-certificate list ca-cert-name commands specify the X.509 certificate and CA certificate to be used.

> • | The PEM-formatted data for the certificate and CA certificate can be specified, or the information can be read from a file via a specified URL as shown in this example.

> When creating the crypto template for IPSec in Context Configuration Mode, bind the X.509 certificate and CA certificate to the crypto template and enable X.509 certificate-based peer authentication for the local and remote nodes, as follows:
> configure
> context <pgw_context_name> -noconfirm
> crypto template <crypto_template_name> ikev2-dynamic
> certificate name <cert_name>
> ca-certificate list ca-cert-name <ca_cert_name>
> authentication local certificate
> authentication remote certificate
> end
> Notes:

> • | A maximum of 16 certificates and 16 CA certificates are supported per system. One certificate is supported per service, and a maximum of four CA certificates can be bound to one crypto template.

> • | The certificate name and ca-certificate list ca-cert-name commands bind the certificate and CA certificate to the crypto template.

> • | The authentication local certificate and authentication remote certificate commands enable X.509 certificate-based peer authentication for the local and remote nodes.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883