Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Enabling GTP Interoperability between 2G and 3G Networks

The GPRS Tunneling Protocol (GTP) is defined by the third-generation partnership project (3GPP) standards to carry General Packet Radio Service (GPRS) within third generation (3G) or fourth generation (4G) networks. The information elements (IEs) provide information about GPRS tunneling protocol (GTP) tunnels, such as creation, modification, deletion, and status. The IEs are included in all GTP control message packets.

Understanding GTP Information Elements

Information elements (IEs) are included in all GPRS tunneling protocol (GTP) control message packets. IEs provide information about GTP tunnels, such as creation, modification, deletion, and status. Junos OS supports IEs consistent with Third–Generation Partnership Project (3GPP) Release 6, Release 7, Release 8, and Release 9. If you have contractual agreements with operators running earlier releases of 3GPP, you can reduce network overhead by restricting control messages containing unsupported IEs.

If a new information element (IE) is introduced, there will be no drop in GTP messages because GTP passes the messages even if it encounters unknown new IEs.

Understanding R6, R7, R8, and R9 Information Elements Removal

The Third-Generation Partnership Project (3GPP) R6, R7, R8, and R9 information elements (IEs) removal feature allows you to retain interoperability in roaming between Second-Generation Partnership Project (2GPP) and 3GPP networks. You can configure the GPRS tunneling protocol (GTP)-aware Juniper Networks device, residing on the border of a public land mobile network (PLMN) and a GPRS Roaming Exchange (GRX) and acting as a Gp firewall, to remove 3GPP-specific attributes from the GTP packet header when the packet passes into a 2GPP network. You can configure the device to remove the RAT, RAI, Common Flags, ULI, MS Time Zone, IMEI-SV, and access point name (APN) restriction IEs from GTP messages prior to forwarding these messages to the gateway GPRS support node (GGSN).

Supported R6, R7, R8, and R9 Information Elements

Junos OS supports all 3GPP R6 IEs for GTP), as listed in Table 1.

Table 1: Supported Information Elements

IE Type Value

Information Element

1

Cause

2

International Mobile Subscriber Identity (IMSI)

3

Routing Area Identity (REI)

4

Temporary Logical Link Identity (TLLI)

5

Packet TMSI (P-TMSI)

8

Reordering Required

9

Authentication Triplet

11

MAP Cause

12

P-TMSI Signature

13

MS Validated

14

Recovery

15

Selection Mode

16

Tunnel Endpoint Identifier Data I

17

Tunnel Endpoint Identifier Control Plane

18

Tunnel Endpoint Identifier Data II

19

Teardown ID

20

NSAPI

21

RANAP Cause

22

RAB Context

23

Radio Priority SMS

24

Radio Priority

25

Packet Flow ID

26

Charging Characteristics

27

Trace Reference

28

Trace Type

29

MS Not Reachable Reason

127

Charging ID

128

End User Address

129

MM Context

130

PDP Context

131

Access Point Name

132

Protocol Configuration Options

133

GSN Address

134

MS International PSTN/ISDN Number (MSISDN)

135

Quality of Service Profile

136

Authentication Quintuplet

137

Traffic Flow Template

138

Target Identification

139

UTRAN Transparent Container

140

RAB Setup Information

141

Extension Header Type List

142

Trigger Id

143

OMC Identity

144

RAN Transparent Container

145

PDP Context Prioritization

146

Additional RAB Setup Information

147

SGSN Number

148

Common Flags

149

APN Restriction

150

Radio Priority LCS

151

RAT Type

152

User Location Information

153

MS Time Zone

154

IMEI-SV

155

CAMEL Charging Information Container

156

MBMS UE Context

157

Temporary Mobile Group Identity (TMGI)

158

RIM Routing Address

159

MBMS Protocol Configuration Options

160

MBMS Service Area

161

Source TNC PDCP context Information

162

Additional Trace Information

163

Hop Counter

164

Selected PLMN ID

165

MBMS Session Identifier

166

MBMS2G/3G Indicator

167

Enhanced NSAPI

168

MBMS Session Duration

169

Additional MBMS Trace Information

173

BSS Container

174

Cell Identification

175

PDU Numbers

176

BSSGP Cause

178

RIM Routing Address Discriminator

179

List of setup PFCS

180

PS Hand-over XID Parameters

188

Reliable INTER RAT HANDOVER INFO

251

Charging Gateway Address

255

Private Extension

Junos OS supports all 3GPP R7 IEs for GTP, as listed in Table 2.

Table 2: Supported Information Elements

IE Type Value

Information Element

172

PS Handover Request Context

181

MS Info Change Reporting Action

182

Direct Tunnel Flags

183

Correlation-ID

184

Bearer Control Mode

Junos OS supports all 3GPP R8 IEs for GTP, as listed in Table 3.

Table 3: Supported Information Elements

IE Type Value

Information Element

189

RFSP Index

Junos OS supports all 3GPP R9 IEs for GTP, as listed in Table 4.

Table 4: Supported Information Elements

IE Type Value

Information Element

190

Fully Qualified Domain Name (FQDN)

191

Evolved Allocation/Retention Priority 1

192

Evolved Allocation/Retention Priority 2

193

Extended Common Flags

194

User CSG Information (UCI)

195

CSG Information Reporting Action

196

CSG ID

197

CSG Membership Indication (CMI)

198

Aggregate Maximum Bit Rate (AMBR)

Example: Removing R6, R7, R8, and R9 Information Elements from GTP Messages

This example shows how to remove R6 information elements from GTP messages.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you configure the Gp interface of the security device to remove newly added R6 IEs (RAT, Common Flags, ULI, IMEI-SV, MS Time Zone, and APN restrictions) from the GTP message.

Configuration

Procedure

Step-by-Step Procedure

To remove R6 information elements from GTP messages:

  1. Specify the GTP profile.

  2. Specify the information element.

  3. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security gprs command.

Understanding GTPv1 Information Element Removal

The number of network elements in a mobile network is expanding with the introduction of multiple releases of 3GPP specifications. Every release introduces newer information elements (IEs) that are not defined in the prior releases. Therefore mobile networks have diverse set of network elements creating inter operability problems between different releases of the devices. You can configure the GPRS tunneling protocol (GTP) firewall to remove information elements (IE) by release with the following command.

set security gprs gtp profile gtp1 remove-ie.

However newer IEs that will be introduced in the future releases might also cause inter operability problems. Each information element has a unique ID, the IE number. IE numbers range from 1 to 255. You can configure the GTP firewall to remove specific IEs using the user-configured IE number.

When you configure the IE removal, the GTP firewall deletes the corresponding IEs of the GTPv1 messages; updates the length of the GTP, the UDP, and the IP; and then passes the GTPv1 message. The GTP firewall also updates the cyclic redundancy check (CRC) code. IE removal by IE number supports all IEs, ranging from 1 to 255.

You can remove the IE removal configuration with the following commands:

delete security gprs gtp profile gtp1 remove-ie—Deletes the IE removal configuration for the GTP profile GTP1.

delete security gprs gtp profile gtp1 remove-ie version v1 number 4—Deletes the IE removal configuration for GTP profile with version v1 and IE number 4.

Starting from Release 20.2R1, Junos OS supports IE removal feature for both GTPv1-C and GTPv2-C.

Example: Removing GTPv1 Information Elements Using IE Number

This example shows how to configure the GPRS tunelling protocol (GTP) interface of the security device to remove user-configured IEs from GTP messages.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you configure IE removal for the GTP profile called gtp1. The IEs are removed using the user-configured IE number 4.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure the GTP interface of the security device to remove user-configured IEs from the GTP message:

  1. Specify the GTP profile.

    [edit]

    user@host# set security gprs gtp profile gtp1

  2. Specify the IE number.

    [edit security gprs gtp profile gtp1]

    user@host# set remove-ie version v1 number 4

Results

From configuration mode, confirm your configuration by entering the show security gprs command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Understanding GTPv2 Information Elements

Information elements (IEs) are included in all GPRS tunneling protocol version 2 (GTPv2) control message packets. IEs provide information about GTPv2 tunnels, such as creation, modification, deletion, and status. The Junos operating system (Junos OS) supports IEs consistent with the Third-Generation Partnership Project (3GPP) Release 8.

Starting from Junos OS Release 20.2R1, a new IE enforcement function, Must-IE check is supported to check the presence of IEs that should be contained in a GTP message. Support for an existing feature IE removal is extended from GTPv1-C to both GTPv1-C and GTPv2-C.

Must-IE check—You can use this function to check the presence of IEs that should be contained in a GTP message. It is a function to verify the GTP message integrity. Must-IEs are not limited to the Mandatory IEs in 3GPP TS. You can define any IE as a Must-IE in a message in accordance with your GTPv1 or GTPv2 versions and GTPv1 or GTPv2 interfaces. The device checks the presence of Must-IEs of specific GTP messages and forwards the messages only if Must-IEs are present. We’ve implemented Must-IE check with flexible message profile configurations, which helps you to define must IEs of interested messages. Along with appropriate message profile configurations, Must-IE check can easily accommodate any GTP releases, message format, or IE status.

IE removal—You can use this functionality to retain interoperability between Second-Generation Partnership Project (2GPP) and Third-Generation Partnership Project (3GPP) networks. You can remove IEs of specific types from all messages for GTPv1 and GTPv2. Each information element has a unique ID, the IE number. IE numbers range from 1 to 255. You can use the IE removal to configure the GTP firewall to remove specific IEs using the user-configured IE number. It enables the communication between GTP entities whose GTP protocols are of different releases. IE removal helps to remove all instances of specified IEs such as supporting IE, Grouped IE, Embedded IE, or embedded grouped IE.

Example: Configure Must-IE check for GTPv1 and GTPv2

SUMMARY You can enable this function to verify the presence of IEs in GTPv1 and GTPv2 message. This helps to verify message integrity. You can define any IE as a Must-IE in a message in accordance with your GTPv1 or GTPv2 versions and GTPv1 or GTPv2 interfaces. The device checks the presence of Must-IEs of specific GTP messages and forwards the messages only if Must-IEs are present.

Requirements

This example uses the following hardware and software components:

  • An SRX Series Firewall.

  • Junos OS Release 20.2R1.

Overview

Information elements (IEs) are included in all GPRS tunnelling protocol (GTP) control message packets. Every GTP-C message is constructed by a GTP header and multiple GTP Information Elements (IE). Each IE type is identified by a number between 1 – 255. Third-Generation Partnership Project (3GPP) TS defines an IE list, for every GTP message, some of them are mandatory, others are optional or conditional.

IEs of GTPv1 are encoded in TV or TLV format. Therefore, GTPv1 use IE number to identify IEs. IEs of GTPv2 are encoded in TLIV format. Therefore, GTPv2 use IE number and instance number to identify IEs.

Must-IE check is a function to check the presence of IEs that should be contained in a GTP message, which helps to verify the GTP message integrity. Must-IEs are not limited to the Mandatory IEs in 3GPP TS. You can define any IE as a Must-IE in a message in accordance with your GTPv1 or GTPv2 versions and GTPv1 or GTPv2 interfaces. The device checks the presence of Must-IEs of specific GTP messages and forwards the messages only if Must-IEs are present.

We’ve implemented Must-IE check with flexible message profile configurations, which helps you to define must IEs of interested messages. We call it as interested messages because IEs are not defined as mandatory in TS. Along with appropriate message profile configurations, Must-IE check can easily accommodate any GTP releases, message format, or IE status.

Configuration

Configure Must-IE check for GTPv1

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. If you need help, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Configure a GTPv1 message-ie profile msgie-v1. In this example, we have created a profile named msgie-v1.

  2. Create a message-ie-profile-v1 and add interested messages and IEs in message-ie-profile-v1. GTPv1 use IE number to identify IEs. In this example, in 3GPP TS 29.060, message type 2 is an Echo response and message type 16 is a Create PDP Context request. For message type 2, IE 14 is a recovery IE, which is mandatory in Echo response. For message type 16, the IEs provided are mandatory IEs in Create PDP Context request.

  3. Bind the message-ie profile to GTP profile as Must-IE. Must-IE check is implemented with message profile configurations, which helps you to define must IEs of interested messages.

Configure Must-IE check for GTPv2

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Configure a GTPv2 message-ie profile msgie-v2. In this example, we have created a profile named msgie-v2.

  2. Define a grouped-ie-profile and link to the IEs. A grouped IE is a group of IEs, or a group of grouped IEs. For example, Bearer Context is a grouped IE containing multiple IEs. PDN Connection is another grouped IE containing multiple instances of Bearer Context and other IEs. You must link a grouped-ie-profile only to a grouped IE, otherwise you will receive an error: “Error: IE %d is not a grouped-ie”.

  3. Create a message-ie-profile-v2 and add interested messages and IEs in message-ie-profile-v2. We call the messages as interested messages because IEs are not defined as mandatory in TS. GTPv2 use IE number and instance number to identify IEs. Instance is defined in 3GPP TS 29.274 for only GTPv2. If more than one IEs of the same type are sent with a message for different purpose, these IEs will have different instance values. If you do not specify the instance value, the device will automatically take the default value as 0.

  4. Bind the message-ie profile to GTP profile as Must-IE. Must-IE check is implemented with message profile configurations, which helps you to define must IEs of interested messages.

Results

From configuration mode, confirm your configuration by entering the show security gprs gtp command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Verification

To confirm that the configuration is working properly, perform these tasks:

Verify the GTPv1 Message-IE Profile

Purpose

To verify GTPv1 Message-IE profile.

Action

From operational mode, enter the show security gprs gtp message-ie-profile-v1 (all | <msgie-prf-v1-name>) command.

Meaning

The output displays the details of GTPv1 Message-IE profile.

Verify the GTPv2 Message-IE Profile

Purpose

To verify the GTPv2 Message-IE profile.

Action

From operational mode, enter the show security gprs gtp message-ie-profile-v2 (all | <msgie-prf-v2-name>) command.

Meaning

The output displays the details of GTPv2 Message-IE profile.

Verify the grouped-ie profile

Purpose

To verify grouped-ie profile.

Action

From operational mode, enter the show security gprs gtp grouped-ie-profile (all | <grpie-prf-name>) command.

Meaning

The output displays the details of grouped-IE profile.

Example: Configure IE removal for GTPV1 and GTPv2

SUMMARY You can enable this function to remove IEs of specific types from all messages for GTPv1 and GTPv2. This helps to retain interoperability between Second-Generation Partnership Project (2GPP) and Third-Generation Partnership Project (3GPP) networks.

Requirements

This example uses the following hardware and software components:

  • An SRX Series Firewall.

  • Junos OS Release 20.2R1.

Overview

The number of network elements in a mobile network is expanding with the introduction of multiple releases of 3GPP specifications. Every release introduces newer information elements (IEs) that are not defined in the prior releases. Therefore, mobile networks have diverse set of network elements creating interoperability problems between different releases of the devices. .

Each information element has a unique ID, the IE number. IE numbers range from 1 to 255. You can configure the GTP firewall to remove specific IEs using the user-configured IE number.

In this example, you can remove IEs of specific types from all messages for GTPv1 and GTPv2. It enables the communication between GTP entities whose GTP protocols are of different releases. This configurations helps to remove all instances of specified IEs such as supporting IE, Grouped IE, Embedded IE, or embedded grouped IE.

The IE removal support is already available for GTPv1-C. Starting in Junos OS Release 20.2R1, IE removal function is extending support for both GTPv1-C and GTPv2-C. You can use this functionality to retain interoperability between Second-Generation Partnership Project (2GPP) and Third-Generation Partnership Project (3GPP) networks.

Configuration

Configure IE removal for GTPv1

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Configure an ieset for GTPv1. In this example, we have created an ieset named ieset-v1-r7.

  2. Add interested IEs in the ieset-v1-r7.

  3. Bind the ieset to GTP profile as remove-ie. In this example, bind ieset-v1 as remove-ie-v1.

Configure IE removal for GTPv2

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Configure an ieset for GTPv2. In this example, we have created an ieset named ieset-v2.

  2. Add interested IEs in the ieset-v2.

  3. Bind the ieset to GTP profile as remove-ie. In this example, bind ieset-v2 as remove-ie-v2.

Results

From configuration mode, confirm your configuration by entering the show security gprs gtp command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Verification

Verify GTPv1 and GTPv2 IE removal Profile

Purpose

To verify GTPv1 and GTPv2 IE removal profile.

Action

From operational mode, enter the show security gprs gtp ie-set (all | <ieset-name>) command.

Meaning

The output displays the details of GTPv1 and GTPv2 IE removal profile.

Understanding GTP APN Filtering

An access point name (APN) is an information element (IE) included in the header of a GPRS tunneling protocol (GTP) packet that provides information about how to reach a network. An APN comprises two elements:

  • Network ID—Identifies the name of an external network such as example.com.

  • Operator ID—Uniquely identifies the operators’ public land mobile network (PLMN) such as mnc123.mcc456.

By default, the device permits all APNs. However, you can configure the device to perform APN filtering to restrict access to roaming subscribers to external networks.

To enable APN filtering, you must specify one or more APNs. To specify an APN, you need to know the domain name of the network (for example, example.com) and, optionally, the operator ID. Because the domain name (network ID) portion of an APN can potentially be very long and contain many characters, you can use the wildcard (*) as the first character of the APN. The wildcard indicates that the APN is not limited only to example.com but also includes all the characters that might precede it.

You may also set a selection mode for the APN. The selection mode indicates the origin of the APN and whether or not the Home Location Register (HLR) has verified the user subscription. You set the selection mode according to the security needs of your network. Possible selection modes include the following:

  • Mobile Station—Mobile station-provided APN, subscription not verified.

    This selection mode indicates that the mobile station (MS) provided the APN and that the HLR did not verify the user’s subscription to the network.

  • Network—Network-provided APN, subscription not verified.

    This selection mode indicates that the network provided a default APN because the MS did not specify one, and that the HLR did not verify the user’s subscription to the network.

  • Verified—MS or network-provided APN, subscription verified.

    This selection mode indicates that the MS or the network provided the APN and that the HLR verified the user’s subscription to the network.

APN filtering applies only to create-pdp-request messages. When performing APN filtering, the device inspects GTP packets to—look for APNs that match APNs that you set. If the APN of a GTP packet matches an APN that you specified, the device then verifies the selection mode and only forwards the GTP packet if both the APN and the selection mode match the APN and the selection mode that you specified. Because APN filtering is based on perfect matches, using the wildcard (*) when setting an APN suffix can prevent the inadvertent exclusion of APNs that you would otherwise authorize.

Additionally, the device can filter GTP packets based on the combination of an International Mobile Subscriber Identity (IMSI) prefix and an APN. When you filter GTP packets based on an IMSI prefix, you must also specify an APN.

An APN string is case-insensitive. For instance, in the following example you set two APN strings, WWW.EXAMPLE.COM and www.example.com, with the same IMSI prefix value. In this configuration, the lowercase string will display after the uppercase string, and the packet will be dropped.

user@host# show configuration security gprs gtp | display set

set security gprs gtp profile test apn WWW.EXAMPLE.COM imsi-prefix * action pass

set security gprs gtp profile test apn www.example.com imsi-prefix * action drop

If an APN is configured with two IMSI prefix entries, then the IMSI prefix with the longest match takes priority. For example, see the following configuration:

user@host# show configuration security gprs gtp | display set

set security gprs gtp profile test apn WWW.EXAMPLE.COM imsi-prefix 12345678 action pass

set security gprs gtp profile test apn www.example.com imsi-prefix 12345 action drop

If an incoming packet value matches the IMSI prefix value 12345678, then the packet will pass. The IMSI prefix value 12345678 takes precedence over the IMSI prefix value 12345, as the longest matched IMSI prefix takes priority.

Example: Setting a GTP APN and a Selection Mode

This example shows how to set a GTP APN and a selection mode.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you set a GTP APN as example.com.mnc123.mcc456.gprs and use the wildcard (*) character. You also set the IMSI prefix and set the selection mode as network.

Configuration

Procedure

Step-by-Step Procedure

To configure a GTP APN and a selection mode:

  1. Specify the GTP profile.

  2. Set a selection mode for the APN.

  3. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security gprs command.

Understanding IMSI Prefix Filtering of GTP Packets

A GPRS support node (GSN) identifies a mobile station (MS) by its International Mobile Station Identity (IMSI). An IMSI consists of three elements: the mobile country code (MCC), the mobile network code (MNC), and the Mobile Subscriber Identification Number (MSIN). The MCC and MNC combined constitute the IMSI prefix and identify the mobile subscriber’s home network, or public land mobile network (PLMN).

By setting IMSI prefixes, you can configure the device to deny GPRS tunneling protocol (GTP) traffic coming from nonroaming partners. By default, a device does not perform IMSI prefix filtering on GTP packets. By setting IMSI prefixes, you configure the device to filter create-pdp-request messages and permit only GTP packets with IMSI prefixes that match the ones you set. The device allows GTP packets with IMSI prefixes that do not match any of the IMSI prefixes that you set. To block GTP packets with IMSI prefixes that do not match any of the IMSI prefixes set, use an explicit wildcard for the IMSI filter, and the drop action should be the last IMSI prefix filtering policy.

When you filter GTP packets based on an IMSI prefix, you must also specify an APN.

Example: Setting a Combined IMSI Prefix and APN Filter

This example shows how to set and combine IMSI prefix and APN filter.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you set example.com.mnc123.mcc456.gprs as an APN and use the wildcard(*). You permit all selection modes for this APN. You also set the IMSI prefix for a known PLMN, which is 246565. The MCC-MNC pair can be five or six digits.

Configuration

Procedure

Step-by-Step Procedure

To set and combine IMSI prefix and APN filter:

  1. Set the GTP profile.

  2. Set the selection mode for APN.

  3. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security gprs command.

Understanding GTPv2 IMSI Prefix and APN Filtering

A GPRS support node (GSN) identifies a Mobile Station (MS) by its International Mobile Subscriber Identity (IMSI). An IMSI comprises three elements: the mobile country code (MCC), the mobile network code (MNC), and the Mobile Subscriber Identification Number (MSIN). The MCC is a three-digit number, and the MNC is a two-digit or three-digit number. The MCC and MNC combined constitute the IMSI prefix and identify the mobile subscriber’s home network or public land mobile network (PLMN). Therefore, the IMSI prefix acts as the PLMN identifier and is used to identify valid roaming partners.

By default, a device does not perform IMSI prefix filtering on GPRS tunneling protocol version 2 (GTPv2) packets. By setting IMSI prefixes, you configure the device to filter create-session-request messages and permit only GTPv2 packets with IMSI prefixes that match the ones you set.

When you filter GTPv2 packets based on an IMSI prefix, you must also specify an access point name (APN).

An APN is an information element (IE) included in the header of a GTPv2 packet that provides information about how to reach a network. An APN comprises two elements:

  • Network ID—Identifies the name of an external network, such as example.com.

  • Operator ID—Uniquely identifies the operators’ PLMN, such as mnc123.mcc789.gprs.

For example, example.com.mnc123.mcc789.gprs is an APN for reaching the example.com network through the mnc123.mcc789.gprs operator.

By default, a device does not perform APN filtering on GTPv2 packets. However, you can configure the device to perform APN filtering to restrict access to roaming subscribers to external networks.

You can use the set security gprs gtp profile profile name apn pattern-string imsi-prefix imsi-prefix-digits action (pass |drop |selection) configuration statement to filter packets based on the combination of an IMSI prefix and an APN.

To specify an APN, you need to know the network ID or the domain name of the network (for example, example.com) and, optionally, the operator ID. Because the network ID portion of an APN can be very long, you can use the wildcard (*) as the first character of the APN string. For example, if you use *.example.com as the network ID, the wildcard indicates that the APN is not limited only to example.com but also includes all the characters that might precede it.

You can use the selection option to set a selection mode for the APN. The selection mode indicates the origin of the APN and whether or not the Home Location Register (HLR) has verified the user subscription. You set the selection mode according to the security needs of your network. Possible selection modes include the following:

  • ms—MS-provided APN, subscription is not verified.

  • net—Network-provided APN, subscription is not verified.

  • vrf—MS-provided or network-provided APN, subscription is verified.

You can use the drop option to drop all APNs and the pass option to pass all APNs for any selection mode.

When performing APN filtering, the device inspects packets to look for APNs that match APNs that you set. If the APN of a packet matches an APN that you specified, then the device verifies the selection mode and forwards the GTPv2 packet.

The device only forwards the GTPv2 packet if both the APN and the selection mode match the APN and the selection mode that you specified.

Because APN filtering is based on perfect matches, using the wildcard (*) when setting an APN suffix can prevent the inadvertent exclusion of APNs that you would otherwise authorize.

IMSI prefix and APN filtering apply to create-session-request messages only.