Deploying MobileNext PDF

Juniper Mobile Infrastructure
DAY ONE: CONFIGURING THE MOBILENEXT

BROADBAND GATEWAY
Data traffic is overwhelming todays

mobile networks, but the MobileNext
Broadband Gateway provides a converged user plane function in an open
mobile core. All you need is a MX240
or higher, a few hundred thousand
smartphone subscribers, and this book.
By Joseph Naughton
DAY ONE:
CONFIGURING THE MOBILENEXT BROADBAND GATEWAY
The primary goal of Junipers MobileNext Broadband Gateway (MBG) is to take the industry to a new level in user plane scalability and performance, one focused on supporting the heavy signaling load generated by smartphones. With 100 million smartphones now being sold worldwide every calendar quarter, scalability is a priority.
The MBG can be a Gateway GPRS Support Node (GGSN), a PDN Packet Data Network
Gateway (PGW), or a combination of both running on the MX Series platform. Day One:
Configuring the MobileNext Broadband Gateway is specifically aimed at the Mobile Packet Core, and here the author deftly showcases the MBG in a series of follow-along tutorials that teach you how to configure and troubleshoot a basic MBG setup in a single
day. Get ready for the smartphone-centric future where services, scalibility, and speed
can be tweaked and configured whenever you need to with the MobileNext Broadband
Gateway.
If you are a packet core engineer who wants to understand the Juniper MobileNext products,
or a Junos specialist who likes to get new ideas on how to use Junos and the MX platform in
the mobile world - choose this book as a starting point. Not only will it answer most of your
questions but it also covers the straightforward configuration of the MobileNext BroadBand
Gateway and EPC core. Its the one book you need.
Matti Samuli Penttil, Technology Manager, Elisa Corporation
ITS DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO:
Configure and implement a GGSN/PGW solution on the MX Series platform.
Connect a Mobile UE through your existing Mobilepacket Core setup.
Run a series of commands to verify the health of the system.
Juniper Networks Books are singularly focused on network productivity and efficiency. Peruse the
complete library at www.juniper.net/books.
Published by Juniper Networks Books
ISBN 978-1936779505
51800
07100151
9 781936 779505
Juniper Mobile Infrastructure
Day One: Configuring the MobileNext

Broadband Gateway
By Joseph Naughton
Chapter 1 : MobileNext Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 2 : Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapter 3 : GGSN Mobility Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapter 4: Advanced Configuration Techniques. . . . . . . . . . . . . . . . . . . . . . . . 71
Chapter 5: System Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Chapter 6: Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
ii
2012 by Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, Junos,
NetScreen, and ScreenOS are registered trademarks of
Juniper Networks, Inc. in the United States and other
countries. Junose is a trademark of Juniper Networks,
Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property
of their respective owners.
About the Author

Joseph Naughton has fifteen years experience supporting
solutions in the networking industry. He is the Technical
Lead in JTAC for the MobileNext product portfolio at
Juniper Networks. Prior to supporting the best of breed
Mobile Packet Core products, he has supported policy
solutions, including SRC and Steel Belted RADIUS, the
BRAS line, and in a former life, VPNs, firewalls, and
Shivas Lan Rover products.
Juniper Networks assumes no responsibility for any

inaccuracies in this document. Juniper Networks reserves
the right to change, modify, transfer, or otherwise revise
this publication without notice. Products made or sold by
Juniper Networks or components thereof might be
covered by one or more of the following patents that are
owned by or licensed to Juniper Networks: U.S. Patent
Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051,
6,333,650, 6,359,479, 6,406,312, 6,429,706,
6,459,579, 6,493,347, 6,538,518, 6,538,899,
6,552,918, 6,567,902, 6,578,186, and 6,590,785.
Authors Acknowledgments
I must give accolades to Patrick Ames who had to climb
mountains to help get this book published, and it should
be noted that Guy Davies made many passes through the
technical material and without his insight some errors
may have made it to press.
Published by Juniper Networks Books

Author: Joseph Naughton
Technical Reviewers: Apurva Mehta, Sridhar Mani, Guy
Davies, Venkatesh Gota, and Scott Florence
Editor in Chief: Patrick Ames
Editor and Proofer: Nancy Koerbel
J-Net Community Manager: Julie Wider
Version History: v1 July 2012

2 3 4 5 6 7 8 9 10 #7100151-en
ISBN: 978-1-936779-50-5 (print)

Printed in the USA by Vervante Corporation.
ISBN: 978-1-936779-51-2 (ebook)
This book is available in a variety of formats at: www.

juniper.net/dayone.
Send your suggestions, comments, and critiques by email
to dayone@juniper.net.
Welcome to Day One

Day One books help you to quickly get started in a new topic with just
the information that you need on day one. The Day One series covers
the essentials with straightforward explanations, step-by-step instructions, and practical examples that are easy to follow, while also providing lots of references on where to learn more. A second series, This
Week, which covers more advanced topics that might be presented in a
week-long training session, is also available.
Both the Day One and This Week book series are available at:
Download a free PDF edition at http://www.juniper.net/dayone.
Get the eBook edition for iPhones and iPads from the iTunes Store.
Search for Juniper Networks Books.
Get the eBook edition for any device that runs the Kindle app
(Android, Kindle, iPad, PC, or Mac) by opening your device's
Kindle app and going to the Kindle Store. Search for Juniper
Networks Books.
Purchase the paper edition at either Vervante Corporation (www.
vervante.com) or Amazon (www.amazon.com) for between
$12-$28, depending on page length.
Note that Nook, iPad, and various Android apps can also view
PDF files.
If your device or eBook app uses .epub files, but isn't an Apple
product, open iTunes and download the .epub file from the iTunes
Store. You can then drag and drop the file out of iTunes onto your
desktop and sync with your .epub device.
iii
iv
What You Need to Know Before Reading This Book

Before reading this book, you should be familiar with the basic
administrative functions of the Junos operating system, including the
ability to work with operational commands and to read, understand,
and change Junos configurations.
This book makes a few assumptions about your network knowledge,
your understanding of the MX Platform, and working with Junos. If
you do not meet the following assumptions, portions of this book and
its tutorials may be difficult to comprehend.
Finally, you should have a good understanding of GSM and LTE.
After Reading This Book, Youll Be Able To...

Configure and implement a GGSN/PGW solution on the MX
Series platform.
Connect a Mobile UE through your existing Mobilepacket Core
setup.
Run a series of commands to verify the health of the system.
Chapter 1
MobileNext Architecture
Peering Into the MobileNext Specific Hardware. . . . . . . . . . . . . . . . . . . . . . . . . 7
Mobile MX Processes and Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
How the MBG Handles Subscribers (Steering) . . . . . . . . . . . . . . . . . . . . . . . . . . 11
MBG Resource Management Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Day One: Configuring the MobileNext Broadband Gateway
Welcome to Juniper Networks Mobile Packet Core. If you are new to

this exciting new technology, that many just call Mobility, welcome.
Even if you are not new to Mobility, welcome anyway. There are some
wonderful aspects of Junipers Mobile Packet Core that you should
find most interesting, if not revolutionary.
This book is specifically aimed at Juniper Networks Mobile BroadBand Gateway (MBG) products comprised in the Mobile Packet Core.
The MBG can be a Gateway GPRS Support Node (GGSN), a PDN
Packet Data Network Gateway (PGW), or a combination of both
running on the MX Series platform. The MBG can also be a Serving
Gateway (SGW) node, but that type of deployment goes beyond the
confines of this book.
Figure 1.1 illustrates a general Mobile Packet Core deployment with
the MBG at the center acting as a GGSN.
SGSN
Operations and
management
entity
Internet
Operations and
management
interfaces
Gn
interface
Core
network
Mobile stations
Operations and
management
entity
Gi
interface
Gn
interface
IP networks
GGSN
Gn
interface
Gi
interface
Ga interfaces
Corporate
network
SGSN
Figure 1.1
Charging
gateway
server
Charging
gateway
server
A Typical Deployment for Junipers Mobile Packet Core Solution
By the time youve gone through this book you should be familiar
enough with the configuration, logging, and tools on MBG that you
will be able to configure and troubleshoot a basic MBG setup. To this
end, the book refers to an imaginary operator called Massachusetts
Telecom (Mass Telecom), a small regional mobile service provider who
would like to deliver world-class mobile services. Appropriately,
Chapter 1: MobileNext Architecture
Massachusetts Telecom reviewed the legacy solutions of other vendors

and decided on the Juniper Mobile Broadband Gateway solution. This
book should be interesting enough to hold your attention yet detailed
enough to allow you to understand the design solution and be comfortable setting up the MBG in a day, just like Massachusetts Telecom did.
NOTE
This book refers to the MBG as a GGSN when it is in the 3G-world and
as a PGW when it is in the 4G/LTE-world.
ALERT!
This book assumes you know the basics of the MX platform, the Junos
OS, and 3G/4G technologies. It explains and spells out some of the
basics but is designed to get you familiar with Junipers MBG product
and not as a training manual for the MX, the Junos OS, or the basics of
GSM and LTE mobile technologies.
MORE? The Day One library has over two dozen books about using and
working with the Junos OS, as well as configuring and deploying
Juniper network devices such as the MX Series, freely available at
http://www.juniper.net/books.
MOBILE TIP
While you should understand the basics of GSM and LTE technologies
before you begin this book, tips do show up throughout explaining
mobile standards whenever a technology overview is needed to fully
understand a given section of the material.
Peering Into the MobileNext Specific Hardware

Before setting up the MX chassis, before configuring an APN or setting
up the Gi interface, and before all that other fun mobility stuff, it would
be wise to understand what MobileNext means to the MX from an
architectural perspective, and what the MX means to MobileNext.
What does our mobile code add to the MX? How does it use the MX?
This may seem like a deep dive when you are antsy to roll up your
sleeves and get at the terminal, but its actually a great place to start.
NOTE
This is a good time to reaffirm that the MBG runs only on the MX240,
MX480, and MX960 platforms.
MX Line Cards
It is important to understand that when the MX is acting as a MBG you
cannot use the same old line cards that you may have always used with
an MX chassis. The first supported cards for the Mobile Broadband
Gateway are the enhanced MS-DPC cards, called MX-MOB-SDPC,

which are the service cards. This MS-DPC adds significantly more
memory - 16GB - than the standard MS-DPC, so it can manage a
larger number of subscribers.
The MS-DPCs PICs can be used as a Session PIC (SPIC) from which
the subscriber is stored and managed, or it can be used as a Service
PIC, from which Mobile Applications like HTTP HE (Header Enhancement) are run. When used as a SPIC the MS-DPC cards are the
GTP-C control plane anchor points.
At this time it should also be pointed out that the MBG requires at
least one MS-DPC SPIC to be available to manage subscribers. Without this SPIC the MBG is not a MBG.
NOTE
This book does not go into any details on the Service PIC.
As for the interface cards, the Mobile Broadband Gateway supports
using the enhanced MPCs. There is a fixed 16-port card, with each
port being a 10GE interface. This card has 4 PFEs (Packet Forwarding
Engine). There is also the non-fixed port card that can take a slew of
different MICs (Modular Interface Cards). This type of card has two
PFEs.
The MPCE cards PFEs are the anchor point, also known as anchor pfe
(apfe) for GTP-U traffic off the Gn interface on a GGSN and S5/S8
interface on the P-GW.
Verifying the Cards

So now that you know everything about running Junos MobileNext
code on the MX platform using these enhanced interface and service
cards, how do you know if you have the correct cards? Easy. From
within the Junos CLI run the commandshow chassis hardware to see
ifthe enhanced boards are present.For example, the enhanced MPC
interface card with 16 10GB ports will display as MPCE not MPC:
root@GGSN-960>showchassishardware
ItemVersionPartnumberSerialnumberDescription
....
FPC0 REV06 750-036284 YZ6730MPCE3D16x10GE
TheenhancedMS-DPCservicecards,displayasMS-DPCE:
root@GGSN-960>showchassishardware
....
FPC2 REV05 750-036585ZB9763MS-DPCE
NOTE
The version, part, and serial numbers may differ on the cards seen in
other MX devices, and that is fine, as long as the description shows
them as being enhanced.
If the cards do not show as enhanced they cannot be used in our
Mobile setup. Note that you can still use non-enhanced cards in a MX
chassis being used as a GGSN or PGW that is running the required
number of enhanced cards, as long as the non-enhanced cards are
being used for a non-mobile function.
NOTE
Another component you have the option to use in the MBG is the
Juniper SSD card that installs on the RE. This card is used to store
charging records.
Mobile MX Processes and Terms

Next up, lets look at a few of the processes that run on the MX and
are unique to our mobile solution. This way, when the processes are
mentioned later on in the book youll know what they do, and can
refer back to this section if necessary.
MobileD: This process manages the mobility CLI commands. If
this process dies no mobile commands can be run from the CLI.
It also hosts the AAA and IP assignment functions.
Mobile-SMD: This process runs on the SPICs. All the mobility
applications are managed by this process.
ChargeD: This is the Charging Daemon. It manages the creation
of call detail records (CDRs) and the sending of these records to a
Charging Gateway, AAA server, or even storing them locally on
the Solid State Drive (SSD). It should be mentioned that the SSD
resides on the RE.
rmpsD: This is the Resource Management Process responsible
for the division of resources (IP address pools, GTP TEIDs, etc.)
and their distribution to each of the SPICs and Anchor PFEs.
RCM (Resource Controller Module): This process runs on the
SPICs and PFE Control Processors. It works hand in hand with
the RMM process to obtain resources and to inform the RMM
process of current resource utilization. The RMM takes the
current load information from the RCM process and pushes it to
each SPIC so the local RCM knows which Anchor PFE to use.
RMM (Resource Management Module): This process runs on the
Routing Engine. It manages Mobile Resources and knows the
utilization of each Anchor PFE and Anchor SPIC. It also moni-
10
tors the availability of GTP peers like the SGSN and SGW nodes
in the Mobile Packet Core, and assigns resources like TEIDs and
source ports to SPICs and PFEs.
Fast Path and Slow Path

Two more terms you need to understand and know when they are used
are Fast Path and Slow Path.
Slow Path refers to traffic that is routed through the UP (UserPlane Processor), also known as the SPIC. This is often referred
to as slow path traffic flow.
Fast Path is traffic that is forwarded from the APFE towards the
egress PFE or ingress PFE, without going through the UP. This is
referred to as fast path traffic flow.
So, going through the MS-DPC SPIC is slower than going from MPC
PFE to MPC PFE, but since some actions need to be processed by the
MS-DPC, using the slow path is not always a bad thing. For example,
if GTP packets have been fragmented before they arrived at the MBG,
use the SPIC to rebuild the packet. Also GTPc packets must use the UP
since the subscriber session is managed there.
Inline Charging
An important feature of the MBG is Inline Charging because it is
handled on the PFE of the MPC, not the SPIC. This allows the MBG to
manage the large number of subscribers it is capable of handling and
ensures that the charging for such numbers is accurate. A charging
record is maintained on the Anchor PFE for each PDP Context or EPC
Bearer. The charging data is periodically sent to the SPIC that is the
anchor for the subscribers with whom the PDP context is associated.
NOTE
Inline charging is the task of maintaining data for the mobile subscriber sessions for billing purposes.
Mobile Interface
The last item on this sections agenda is explaining the MIF acronym
that youll encounter in subsequent chapters. The Mobile Interface
(MIF) is just an interpretation of the logical interface architecture
(IFL). Once a packet is associated with a subscriber record, an interface
template (MIF-IFL) consults the subscriber record to identify the
proper packet forwarding, filtering, rate-limiting, queuing, and
accounting behavior.
The MIF is tied to the APN configuration, which is covered in the

configuration section of this book.
How the MBG Handles Subscribers (Steering)

You could call the next two sections How Junipers MBG Manages
Mobile Resources. Suffice it to say this is really important, and please
do review carefully before jumping into configuring your MX.
First, lets discuss why the MBG needs to steer packets. Steering is a key
component in the mobile solution allowing the MBG to efficiently
handle a large number of subscribers without overwhelming the
routing engine.
NOTE
Steering to the MBG involves taking a GTP packet from the Gn or S5/
S8 PFE and redirecting it somewhere internally. Steering is also the act
of taking a non-GTP packet from the Gi PFE and redirecting it somewhere internally when the destination is the mobile subscribers device.
All of this makes more sense in about twenty pages.
For GTPc packets, the MBG uses the steering mechanism so the PFEs
are able to load-balance the PDP context activation messages to all
mobile enabled MS-DPCs. All other GTP messages with TEID 0 will be
delivered, also known as steered, to one designated MS-DPC. GTP
messages with a non-zeroTEID will be assumed to be allocated by a
given MS-DPC and should be sent to the appropriate SPIC, managing
that session by using the TEID found in the PDP context activation.
GTPu traffic steering, on the other hand, allows the PFE managing the
interface to send the traffic to the PFE that is anchoring that session.
From the anchor PFE, the GTP packet will be decapsulated and sent to
the Gi/SGi interface, or in the case of Gi/SGi to Gn/S5/S8, the traffic
will be re-encapsulated. The one exception with GTPu traffic is if the
packet is received as fragmented by the GN or S5/S8 PFE. These
fragmented packets must first be steered to a SPIC for reassembly. This
is the one type of GTPu traffic that takes the slow path.
Now, lets examine Figures 1.2 and 1.3 to help illustrate subscriber
setup.
In the example in Figure 1.2, the MPCs PFE would select a mobilityenabled MS-DPC to manage the subscribers session.
In Figure 1.3, the data traffic arrives on an interface on MPC-1, and
then moves to MPC-2, which hosts the anchor PFE before being routed
out the Gi interface on MPC-4.
11
12
Routing Engines
Fabric
2
3
Session
Control
Session
Control
AAA/
Diameter
AAA/
Diameter
Charging
Firewall
Charging
Firewall
etc.
etc.
Session DPC-1 Session DPC-2 MPC-1

4
Anchor
Anchor
MPC-2
MPC-3
Gn/Gp/S5/S8
IP Network
User Equipment
Figure 1.2
MPC-4
Gi/SGi
IP Network
Servers
Steering Example for a PDP Context Activation
To explain the whole steering model in more detail, we need to start by

identifying the attributes by which the MBG steers traffic to a particular Session PIC, or Anchor PFE, or Create Session Request for LTE.
Note that this steering occurs every time a GTP packet hits an interface
on any MPCe that is setup as a Gn, S5/S8 or Gi Interface. There are
three definable scenarios where the MBG will steer when GTP packets
are involved:
The MBG will steer on the IMSI (a unique identifier that is
associated with a Mobile device ) when the TEID is 0 in a GTP-C
packet.
The MBG will steer on the TEID when the TEID is non 0 in a
GTP-C packet.
The MBG will steer on the TEID in GTP-U packets.
Routing Engines
Fabric
7
6
Session
Control
Session
Control
AAA/
Diameter
AAA/
Diameter
Charging
Firewall
Charging
Firewall
etc.
etc.
Session DPC-1 Session DPC-2 MPC-1
Anchor
Anchor
MPC-2
MPC-3
5
Gn/Gp/S5/S8
IP Network
User Equipment
Figure 1.3
MPC-4
Gi/SGi
IP Network
Servers
Steering Example for GTP-U (aka Data Traffic)
Steering the IMSI When the TEID is 0 in a GTP-c Packet

This scenario is normally the GTP packet type of Create PDP Context
Request or Create Session Request for LTE. This GTP packet type,
Create PDP Context Request, will be steered from the MPC to an
active Session PIC (SPIC) on one of the MS-DPC cards. The selection
of the SPIC is based on an IMSI-based hashing algorithm that has been
added to the Junos mobility code. This algorithm allows an even
distribution among the available SPICs for Create PDP Context
Requests and Create Session Requests.
The SPIC that is now processing the Create PDP Context Request
assigns a TEID for this Subscribers session, if all went well when
processing that request.
13
14
MOBILE TIP For 3G, a GTP packet type of Create PDP Context Request is just the
subscriber attempting to get access to the Mobile Packet Core through
the SGSN. If the subscriber attaches to the SGSN successfully and
wishes to send data, the SGSN will create the GTP Create PDP Context
Request message based on the information it receives from the Radio
Access Network (RAN) and send it to the GGSN over the Gn interface.
MOBILE TIP A TEID is a number created by the MBG and its GTP peers, like the
SGSN or MME, to identify the GTP tunnel for this PDP context. A
subscriber can have multiple PDP contexts, each with a unique TEID.
The TEID for the control plane and the TEID for the data plane may be
different.
Steering the IMSI When the TEID is non-zero in a GTP-C Packet
After the TEID is assigned to a session by the SPIC, if, at a later point, a
GTP-C packet arrives on a Gn or S5/S8 MPC interface with a TEID of
non-zero, the MBG will use the TEID to send the packet from the
current MPCs PFE that has taken the packet off the wire, and forward
it to the SPIC that is managing the session for further session processing
as needed.
Steering the TEID in GTP-U Packets
When a GTPu packet arrives on the GN or S5/S8 interface, the MBG
uses the TEID for the data plane to steer it from the PFE that has taken
the packet off the wire to the assigned anchor for GTP decapsulation.
When data packets arrive on the Gi interface destined for a UEs IP
Address, the system will send it to the assigned anchor PFE for GTP
encapsulation.
Note that the anchor PFE actually does more than just encapsulation or
decapsulation of the data packet it also handles proper packet forwarding, filtering, COS rate-limiting, queuing, and accounting behavior.
NOTE
Steering happens to every single GTP packet that traverses the MBG.
Every GTP packet!
In the next section we will look at these scenarios in more depth.
MBG Resource Management Architecture

Since all the TEIDs the SPICs pass out to each session are considered a
resource to the Mobile Broadband Gateway, and since every Mobile
session uses TEIDs, lets look at the resource management architecture
of the MBG using the TEIDs as our first example. In order to distribute
these TEID resources efficiently, each SPIC on a MS-DPC asks the active
Routing Engine for a chunk of TIEDs, as whimsically shown in Figure

1.4.
MS-DPC
RCM
Figure 1.4
I need some TEIDs!

Here, take 1000 thru 2000.
Routing Engine
RMM
Give Me Some TEIDs
For example, the SPIC at 4/0/0 asks for some TIEDs from the Routing
Engine, and then it receives TEID 122200 through 123200. This
distribution is known by the whole system since the SPICs, mobileenabled PFEs, and the Routing Engines each have a table that notes
which TEID resources have been distributed to which SPIC. Now, in
this example, only the SPIC at 4/0/0 will be able to assign TEIDs
122200 through 123200 to any mobile sessions that it anchors. No
other SPIC on any MS-DPC on this system can use these specific TEIDs
to assign to a new session, not even the other SPIC on this same
MS-DPC. The one exception to this rule would be if redundancy is set
up among SPICs. In this case the secondary SPIC for a pair will use
these resources if the primary SPIC goes away for any reason. Redundancy among SPICs is explained in detail in a later section of this book.
The SPIC requests these TEID blocks through the local process called
Resource Controller Module (RCM) that runs on all mobility-enabled
SPICs. The RCMs communicate to the Resource Manager Module
(RMM) process, which manages the resources globally. Remember the
RMM runs on the active Routing Engine.
In a nutshell, the MGB architecture manages resource assignment by
maintaining tables on the Routing Engine via the RMM, as well as on
each SPIC and mobility-enabled PFE via the RCM. You will see more
of this as the book progresses.
So to review, lets again ask the question: But how does the system
know how to steer based on the TEID? Well, when a TEID range is
assigned to a SPIC by the Routing Engine, the RMM process also
updates another table, which is sent to the mobility-enabled PFEs on
each mobility-enabled MPC. This allows a PFE that receives a GTP-C
packet from the wire with a TEID of non-zero to know which SPIC is
currently managing that session based on the TIED. Remember
steering to a SPIC on the TEID is only for GTPc packets, not GTPu.
GTPu steers to AFPEs. Control versus data.
15
16
Anchoring a Subscriber
By now you should understand how TEIDs are distributed and how
the system steers the GTPc packets based on the TEID value, but how
does the system/SPIC decide which PFE to anchor the subscriber
session that the TEID is also being assigned to? Does the SPIC just
randomly ring certain PFEs, asking them to anchor a mobile subscriber? No, the PFEs are considered a mobile resource, too, and the RCM
process on the SPIC that is bringing up the management of the subscriber chooses which Anchor PFE is used for the given subscriber
session.
Here is how the PFE resource gets handed out:
1. First choice is given to the PFE that is the egress PFE to reach the
peer of the session at the SGSN/S-GW, thus avoiding one extra hop
through the fabric for the downstream traffic to the UE (i.e., traffic
from Gi to Gn). This information is readily available to the SPIC from
the Peer Information Table.
2. If the first choice PFE is already heavily loaded (resources are
exhausted on the PFE), the second choice is the PFE that is the nextbest egress PFE (ECMP or backup next hop for the route) to reach the
session Peer. PFE load information is available to the SPIC via the
RMM.
3. If a suitable Gn-facing Anchor-PFE cannot be found, then it
considers anchoring the subscriber on a Gi-facing PFE, if such a PFE
also serves as an Anchor PFE (APFE). Note that this is only possible if
there are very few Gi-facing PFEs. The primary purpose here is to
avoid traversal of the fabric to reach the Anchor PFE.
4. Finally, if both first and second choice PFEs are heavily loaded and
there is no suitable Gi-facing Anchor PFE, then the least-loaded PFE in
the system is chosen as the anchor PFE.
Remember that each APFE in the system that has load attached to it
has to tell the system about the resources in use. The RCM process on
the PFE tells the RMM process on the Routing Engine about its current
load. The system uses this information to help in determining which
PFE a SPIC should pick next when a new session is coming online.
Peer Information
Okay, so you understand that TEIDs and PFEs are mobility resources
in the eyes of the MBG. Lets now look at a more unique resource type,
called Peer Information, which is another piece of important information distributed by the MBG. The RMM process keeps track of the
reachability of MBG peer nodes, such as SGSNs and SGWs, and it also
notes the egress PFEs that reach the peers. The Peer Information gets
pushed to all the RCMs on the SPICs, allowing the SPICs to use the
table when selecting the most efficient APFE for a new subscriber
sessions PDP contexts, meaning the PFE with the fewest, passes
through the fabric for Gn/S5/S8 to Gi/SGi.
Peer Information works when non-session specific GTP-C messages
with a TEID of zero, called GTP Echo requests, are received from a
peer node. These messages are processed on a Designated SPIC of the
peer. When these messages are received from a new peer (not known to
the MBG yet) the ingress PFE forwards them to a Designated SPIC.
NOTE
The Designated SPIC is one of the SPICs that the system chooses to
handle peer management, otherwise know as path management, to the
known peers such as a SGSN or a SGW. This Designated SPIC is
responsible for doing complete path management of the peer, including
sending and receiving periodic echo messages, and informing all other
SPICs in the system about peer reachability, when a peer has not
replied to x-number of consecutive echo requests.
Source Port Ranges

The now well-known RMM process also handles allocation of source
port ranges, which is another mobility resource of the system, and it
does so in a way similar to how it handles TEIDs. It breaks them into
ranges and then assigns these ranges in groups to different SPICs.
When the SPIC has to communicate with an external mobile application, it uses this source-port information. Thus, when data arrives back
at the MBG from an external mobile application such as a Charging
Gateway, a RADIUS server, or a PCRF server, the PFE that receives the
packet knows which SPIC is handling the subscriber session based on
the source port. This allows the PFE to forward the packet to the
appropriate SPIC for processing.
Managing DHCP Resources

DHCP Servers can be used to assign addresses to subscribers terminating on the MBG, acting as a GGSN or a PGW. Since a DHCP Server
sends replies back to the client (in this case the MBG) on UDP port 68,
and does not use random source ports, the MBG cannot use the source
port pools to steer DHCP traffic from the PFE to the SPIC that manages the session attached to a given DHCP exchange.
Instead, the MBG uses the Transaction ID (XID) in the DHCP header
for steering the reply packets from the DHCP server back to the
anchoring SPIC. The PFE that receives the reply knows which SPIC to
17
18
use because the anchored SPIC managing the users session constructs
the XID from a table it has. This table, like other resource tables, is
created by the RMM process on the Routing Engine and sent to the
SPIC that requires assigning resources at this point in time. The RE
also propagates the table down to the PFEs, so they know which SPIC
the replies should be sent to.
So, to repeat the process, at the time the DHCP module generates
BOOTREQUEST messages, the SPIC relays the message to the DHCP
server with a XID from the unique range assigned to the SPIC. Next, as
the DHCP server reply message is received by the PFE, it can be steered
to the corresponding SPIC based on the XID that is known by each
PFE.
NOTE
One thing to note about all resources that are managed by the RMM
to RCM process is if there is a secondary SPIC configured for the SPIC
managing the session, the unique tables are propagated to the secondary cards. Redundancy can be made to work! We will look at how to
configure redundancy in a later section.
Advanced Request Management

Lets review the basics first. A Create PDP Context Request or Create
Session Request is received for a subscriber, who at this point is now
known to the MBG by their IMSI. The RCM process on every SPIC
and PFE are aware of current resource utilization due to the RMM on
the RE gathering stats from every mobility-enabled line card (MSDPCs and MPCs) and then pushing those stats globally back to all the
mobility enabled line cards. This leads the Ingress PFEs on the receiving MPC to know which SPICs cannot be used to manage a new
session due to resource limitations. The session now gets directed from
the ingress PFE to an available SPIC based on the IMSI hash algorithm.
So the Create PDP Context Request or Create Session Request is off to
a selected SPIC to get processed, meaning TEIDs assigned, APFE
chosen, etc. Nice stuff! But there are other things that can happen
when a Create PDP Context Request or Crate Session Request is
steered.
For example, when the MBG receives a new Create PDP Context
Request for a subscriber, the MBG must be able to delete any existing
sessions for the same IMSI, or NSAPI, since that would mean the
existing session is a stale, or a hung, session.
MOBILE TIP An Access Point Name (APN) is an information element of a GTP
packet providing information on how to reach a network. The NSAPI
is an identifier used to identify a PDP context. It is dynamically selected
by the Mobile Station (MS).
Also, when the SGSN retransmits a Create PDP Context Request

message or the SGW retransmits a Create Session Request, the MBG
needs to drop the retransmitted message if the original request message
was already processed. This can happen if the response to the peer
(SGSN or SGW) was lost, or if the MBG is overloaded and processing
slow at that moment.
In addition, there is also a 3G scenario where the MBG receives a MS
Info Change Notification Request message for a session. This is not a
Create PDP Context Request message, but another type of control
message. When the PFE receives this type of message, and it has a
TEID of 0, the PFE handles this as a new request and sends it to a SPIC
(the PFE does not analyze GTP-C message type, only the TEID).
Now, when a SPIC receives this type of message there is some new
processing performed that is not done when a Create PDP Context
Request or ECHO Request is received. The SPIC has some advanced
GTP processing, it being the service PIC. So the SPIC sees the TEID of
0, but it also sees the message type. The SPIC now looks into its tables
to see where the IMSI in the request is currently be managed and
forwards the request to the SPIC where the IMSI is currently hosted so
the session can get further processing on the correct SPIC.
MOBILE TIP MS Info Change Notification Requests may be sent to the GGSN when
an event occurs where the Mobile Subscriber changes its state in some
manner, such as a location or tracking area change.
An astute reader might ask how the MBG knows where the IMSI is.
The answer is: the data is stored in the IMSI Location Database. On
the MBG, after a subscriber session is distributed to the SPIC and the
Create PDP Context Request or Create Session request message is
processed correctly, the IMSI from the session is then added to the
IMSI Location Database. This database is known to the RMM and
RCMs processes. Now the IMSI is known by the whole system and the
system knows which card is managing the session.
GTP-U Data Sessions

Admittedly, there is a lot to this steering of the GTP-C packets and
mapping of resources, but so far the discussion has been about control
traffic, setting up the GTP-C session, and not about all the data that we
expect the system to pass.
After the subscribers session/bearer has been created on the MBG via
GTP-C steering, GTP-U data sessions will be based on the TEID
assigned for the data plane that was passed back to the peer by the
19
20
MBG. You know that the Ingress PFE can steer incoming GTPc
packets based on the TEID value in the packet, and it also does this for
GTP-U packets. Like the TEIDs for GTP-C packets, each SPIC that is
setup for mobility also requests some TEID ranges for GTP-U setup.
Lets rehash this process, but for GTPu this time. Remember that the
MBG assigns the TEID that is used for data packets, also known as
GTP-U packets. Look at the output for a 3G example in Figure 1.5.
You can see in the Create PDP Context Response that a TEID Data I
value of 0x14240162 has been assigned in the response. The GTP peer
sends this as the TEID in any GTP-U request for this subscriber. It will
not send the TEID for the GTP-C response (0x00000102 in this snoop)
for anything but further GTP-C processing, if that is needed. To drive it
home the TEID is different for GTP-C and GTP-U.
Figure 1.5
GTP-U Snoop
Summary
While it may have seemed like a lot of information to digest, the
MobileNext architecture is very well defined and orderly. It has to be in
order for it to work at the scale needed. If anything, be thankful you
werent trying to copy the whiteboard during the meetings when this
architecture was deduced.
Reread this chapter if you need to remember some of the session
particulars, but if youre moving on to the MX configurations in the
next chapters, it is worth your while to intimately understand how the
MBG processes its subscribers.
Chapter 2
Deployment
Whats In Your MX?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Editing the Chassis Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Setting Up the Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Creating a Routing Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
22
This book assumes you know the basics of how to configure a MX, but
because you are probably new to the GGSN/PGW, it covers as much
setup information as possible. So expect some turbulence ahead if you
have no MX experience the flight attendants will have to check your
seatbelt.
MORE? There are dozens of tutorials on using Junos and on working with the
MX Series in the Day One library at http://www.juniper.net/books.
And the technical documentation for MobileNext products is both
excellent and available online at http://www.juniper.net/techpubs/
en_US/release-independent/mobilenext/information-products/pathway-pages/product/index.html.
Whats In Your MX?

First, lets make sure you know what is in your box. In this books
example you can see that its an MX480 named GGSN-960 because it
wishes to be a larger box with an MPCE (16 10GE ports) in Slot 0 and
1. Slots 2 and 4 have the MS-DPC service cards. Slots 3 and 5 have the
MPCs, with Slot 5 having one MIC (4 10GE ports) and Slot 3 having
no MICs:
root@GGSN-960#runshowchassishardware
Hardwareinventory:
ChassisJN11AC398AFBMX480
RoutingEngine0REV15740-0130639012013202RE-S-2000
CB0REV09710-021523ABBH5083MXSCB
FPC0REV06750-036284YZ6730MPCE 3D 16x 10GE
CPUREV10711-029089ZA3724AMPCPMB
PIC0BUILTINBUILTIN4x10GE(LAN)SFP+
Xcvr0REV01740-031981UHQ057RSFP+-10G-LR
Xcvr0REV01740-01311162561016UNKNOWN
FPC1REV06750-036284YZ6717MPCE 3D 16x 10GE
CPUREV10711-029089ZA3703AMPCPMB
Xcvr0REV01740-031981UHQ082ESFP+-10G-LR
FPC2REV05750-036585ZB9765MS-DPCE
CPUREV02710-036586YZ1651DPCPMB2GB
PIC0BUILTINBUILTINMS-DPCPIC
FPC3REV07750-036286ZA7845MPCE Type 2 3D EQ
CPUREV06711-030884ZA7473MPCPMB2G
QXM0REV05711-028408ZA8286MPCQXM
Chapter 2: Setting Up the MBG
QXM1REV05711-028408ZA8195MPCQXM
FPC4REV05750-036585ZB9763MS-DPCE
CPUREV02710-036586YZ1657DPCPMB2GB
FPC5REV07750-036286ZC3842MPCE Type 2 3D EQ
CPUREV06711-030884ZA6137MPCPMB2G
MIC0REV09750-028387JZ89933D4x10GEXFP
PIC0BUILTINBUILTIN2x10GEXFP
Xcvr0REV01740-014279723019A00068XFP-10G-LR
PIC1BUILTINBUILTIN2x10GEXFP
Xcvr0REV01740-011607AVAA0848M2EDXXFP-10G-LR
QXM0REV05711-028408ZC3632MPCQXM
QXM1REV05711-028408ZC3491MPCQXM
FanTrayEnhancedLeftFanTray
Editing the Chassis Hierarchy

The first step is to edit the chassis hierarchy. For the MPCE cards in
slots 0, 1, 3, and 5, attach the mobility package. If you do not do this,
the cards wont be able to handle the GTP C and GTP U requests from
the SGSN/MME/SGW and RAN GTP-U direct tunnel requests. So, if
you want to be a GGSN or PGW, set this package up on at least one
MPC that will be Gn or S5/S8 facing!
[editchassis]
fpc0{
forwarding-packages{
mobilityggsn-pgw;
}
}
Do you want those MS-DPC/SPICs to be able to handle any mobile

applications? Remember, if you want to be a GGSN or PGW, set up
this configuration on at least one MS-DPC PIC. Well assume you do
want mobile applications, so lets configure the MS-DPC FPC section
as shown here. Note that there are some settings here that can be
adjusted and tweaked based on the performance requirements of your
MX.
[editchassis]
fpc2{
pic0{
adaptive-services{
service-package{
extension-provider{
control-cores1;
data-pollers1;
object-cache-size512;
total-wired-memory14336;
boot-osembedded-junos64;
packagejservices-mobile;
23
24
}
}
}
}
pic1{
adaptive-services{
service-package{
extension-provider{
control-cores1;
data-pollers1;
object-cache-size512;
total-wired-memory14336;
boot-osembedded-junos64;
packagejservices-mobile;
}
}
}
}
}
Here are a few notes on some of the options used here (remember these
values are default and should normally never have to be changed):
control-cores specifies the number of cores used for the Junos
kernel driven control management. The rest of the cores are used
for mobility processing.
data-pollers state how many kernel threads are used for polling
packets.
ALERT!
total-wired-memory in our case of 14336 is out of the 16G

memory on the MS-DPC. We need 14G wired for expected
performance.
data-flow-affinity is how packets are distributed to different

software threads to ensure packet flows are processed in the same
fashion.
package jservices-mobile is for running mobility daemons.
Note that the following error will occur if the MS-DPCs were not
configured correctly under [chassis fpc] hierarchy, causing the
jmobile package to not run on any MS-DPC pics:
root@GGSN-960#runshowunified-edgeggsn-pgwstatus
error:Clientnotpresent
This happens more often than you think when you first configure the
unit. If you run any show unified-edge ggsn-pgw command and get
the error above, go check the MS-DPC configuration under [chassis]
hierarchy first. Then run show chassis fpc x detail to make sure the
MS-DPC is in good health.
Setting Up the Interfaces

The next step is to set up the interfaces in the Junos CLI. Since there are
dozens of physical interfaces and potentially many logical interfaces,
lets start with the basics:
One physical interface for the Gn/S5/S8 Interface
One physical interface for the Gi/SGi Interface
One MIF to map to an IFL that can be tied to an APN
One loopback address on which GTP packets will be received for
the Gn/S5/S8 interface
Also set up a management interface
For the example in this book, all the interfaces of the GGSN/PGW sit
on the same network. That network is 10.3.x.x/16, and it is shown in
Figure 2.1.
SGSN
Gn
201.100.1.5/24
Gi
10.3.2.58/24
Internet
MIF
Lo0.1
201.100.1.6/32
Fxp0
10.3.219.31/16
Figure 2.1
Sample 3G Network for Chapter 2
Under the [edit interfaces] hierarchy lets make Slot 0, pic 0, port 0
the GN interface, like this:
xe-0/0/0{
description"GIinterface";
unit0{
familyinet{
address10.3.2.58/24;
}
}
}
Slot5,pic0,port0willbetheGIinterface:
xe-5/0/0{
description"GNinterface";
25
26
unit0{
familyinet{
address 201.100.1.5/24;
}
}
}
Setting up the management address is one of the most basic MX

actions you will ever perform in your Junos life:
fxp0{
unit0{
familyinet{
address10.3.219.31/16;
}
}
}
Our loopback address:

lo0{
unit1{
familyinet{
address201.100.1.6/32;
}
}
}
And last the MIF interface, which we will tie to our first APN:
mif{
unit16000{
}
}
Now we will finally set up the redundancy of the MS-DPCs.

There is no section under hierarchy such as EDIT> Service Card >
Redundancy, nor is there a Mobile MS-DPC redundancy section.
Instead, this configuration is set under the [interfaces] hierarchy
using logical interfaces you set up for each of the service cards PICs.
There is a Junos feature called Aggregated Multiservice interfaces,
known as AMS. In this example, two AMS interfaces were created.
Remember, the AMS interface is just another logical interface. You
should group the PIC on one MS-DPC with the PIC of another. In this
example, 2/0/0 is matched with 4/0/0, and 2/1/0 is set with 4/1/0. Note
too, that the SPIC interface is called a MAMS under the AMS configuration. This stands for Mobile Aggregated Multiservice interface:
ams0{
load-balancing-options{
member-interfacemams-2/0/0;
high-availability-options{
many-to-one{
preferred-backupmams-2/0/0;
}
}
}
}
ams1{
load-balancing-options{
high-availability-options{
many-to-one{
preferred-backupmams-4/1/0;
}
}
}
}
When this configuration is set up, you can lose a single mobile-enabled
PIC or a whole MS-DPC card without any loss of service. All subscriber states stay on the box, meaning your subscribers continue to exist on
the network. So if you set this configuration upand then go take a
MS-DPC down, you should see that all is well.
You can also set up redundancy on the MPCE line cards for the anchor
PFEs. In the setup we are putting together for Mass Telecom, we will
use the MPCE in FPC 0 as the primary. FPC 1 will be secondary in case
there is a failure on either one:
apfe0{
anchoring-options{
primary-list{
fpc-0;
}
secondaryfpc-1;
warm-standby;
}
}
You can configure anchor pfe redundancy to be even be more granular

than using the whole FPC. You could create apfe groups using a per-pfe
set versus the whole FPC. An example is shown below where one pfe
from the MPCE in FPC0 and one pfe from the MPCE in FPC5 have
been chosen as primaries. The secondary has been chosen from the
MPCE in FPC 2. This PFE will kick in when one of the primaries fail.
Note, that there is no particular reason we chose these specific PFEs
aside from showing you the flexibility the system allows you:
apfe0{
anchoring-options{
27
28
primary-list{
pfe-0/0/0;
pfe-5/1/0;

}
secondarypfe-1/0/0;
warm-standby;
}
}
You can always run the following command to see how the mobilityenabled line cards, which are considered clients to the mobility resource framework, are being used:
root@GGSN-960>showunified-edgeggsn-pgwresource-managerclients
ClientStateRedundancyroleClienttypeGateway
pfe-0/0/0In-ServicePrimaryAnchor-PFEMasst
pfe-1/0/0In-ServiceSecondaryAnchor-PFEMasst
ms-2/0/0In-ServicePrimarySession-PICMasst
ms-2/1/0In-ServicePrimarySession-PICMasst
ms-4/0/0In-ServiceSecondarySession-PICMasst
ms-4/1/0In-ServiceSecondarySession-PICMasst
You can also run this command to get similar information, but here
you also get information on the aggregated groups and what PFEs and
PICs have been assigned:
root@GGSN-960>showunified-edgeggsn-pgwsysteminterfacesgatewayMasst
Gateway:Masst
InterfacesMembersOperationalRedundancy
StateRole
ams0mams-2/0/0ActivePrimary
mams-4/0/0ActiveSecondary
apfe0pfe-0/0/0ActivePrimary
pfe-1/0/0ActiveSecondary
pfe-0/1/0ActivePrimary
Creating a Routing Instance

Its now time to create a routing instance for the GI interface. Note that
using routing instances is recommended to provide traffic separation
and isolation for protection. Simply set the Gi/SGi interface and the
Mobile IP interface under a GI_VR routing-instance:
[editrouting-instancesGI_VR]
interfacexe-0/0/0.0;
interfacemif.16000;
Do not forget to add the instance-type, which is a virtual-router for

this setup:
[editrouting-instancesGI_VR]
instance-typevirtual-router;
Lets see what the routing table looks like for the Gi routing instance:
[edit]
root@GGSN-960#runshowroutetableGI_VR.inet.0
GI_VR.inet.0:4destinations,5routes(4active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
10.3.0.0/16*[Direct/0]03:52:32
>viaxe-0/0/0.0
10.3.2.58/32*[Local/0]03:52:41
Localviaxe-0/0/0.0
11.11.11.11/32*[Direct/0]03:55:32
>viamif.16000
[Local/0]03:55:32
Localviamif.16000
15.1.192.0/22*[Anchor/7]01:13:01
Privateindexed
Now lets compare it to the main routing table:

[edit]
root@GGSN-960#runshowroutetableinet.0
inet.0:6destinations,6routes(5active,0holddown,1hidden)
+=ActiveRoute,-=LastActive,*=Both
0.0.0.0/0*[Static/16]01:13:37
>to10.3.0.1viafxp0.0
10.3.0.0/16*[Direct/0]01:13:37
>viafxp0.0
10.3.219.31/32*[Local/0]03:56:09
Localviafxp0.0
And here is what our whole routing instance looks like:

routing-instances{
GI_VR{
access{
29
30
address-assignment{
mobile-pools{
MassT_Pool{
familyinet{
network{
15.0.0.0/14{
range{
Range_Name{
low15.0.0.1;
high15.3.255.254;
external-assigned;
}
}
}
}
}
default-pool;
}
}
}
}
interfacemif.16000;
}
This routing instance shows something called a mobile-pool. This is

the VR that will anchor the IP addresses the GGSN/PGW assign to the
clients. The next chapter covers the settings and that will tie all of this
together, but now while were at this routing instance, lets put our GN
interface into its own virtual router, too:
GN_VR{
interfacelo0.1;
Summary
Okay! The MX is configured in the most basic way but it is useless
right now, so dont get alarmed if youre following along in your lab or
test bed. You have a few routing instances and some interfaces ready,
and, well, not much else, but you are ready to be set up as a GGSN or
PGW!
Remember, nows the time to go back over Chapter 2, or Chapter 1, if
anything is amiss, or if you dont quite understand something, because
in Chapter 3 youll get into the real mobile configuration.
Chapter 3
GGSN Mobility Configuration
IP Address Assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
The Gateway Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Access Point Name (APN) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
The Charging Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
The RADIUS Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
QOS / COS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
32
Chapter 3 is really just a continuation of Chapter 2, but it makes better

sense as its own entity since its a bit more complex and mobile-focused
than Chapter 2. Chapter 3 also goes a step further than Chapter 2 and
breaks up the mobility configuration sequence into distinct sections,
allowing you to refer to and find those sections at a later time as a
reference points:
IP Address Assignment
The Gateway
APNs
Charging
Radius
QoS
Logs!
One last item before we get started. Remember Mass Telecom? They
currently have 1.1 million subscribers whose average 3G download
speed is 1.3 Mbps, and they are the carrier who will be with us for the
rest of this book.
IP Address Assignment
One of the main features in any basic GGSN, or PGW, is that it can
assign an IP address to mobile units. For instance, heres a reliable
quote from Wikipedia: The GGSN is responsible for IP address
assignment and is the default router for the connected user equipment
(UE).
So, lets begin by setting up an IP Pool range on the MBG for Mass
Telecom. Lets also make it an externally assigned IP range since Mass
Telecom will have their RADIUS server assign the IP Addresses. So,
lets begin by setting up an IP Pool range on the MBG for Mass Telecom. We had just set up that routing instance called GI_VR in the last
chapter and there was a pool added to it.
NOTE
A routing instance is a collection of routing tables, interfaces, and

routing protocol parameters. There can be multiple routing tables for a
single routing instance for example, unicast IPv4, unicast IPv6, and
Multicast IPv4 routing tables can exist in a single routing instance.
Routing protocol parameters and options control the information in
the routing tables.
Here is what the configuration should look like for the IP Pool called
MassT_Pool, with some notes about it directly after:
Chapter 3: GGSN Mobility Configuration
[editrouting-instancesGI_VRaccessaddress-assignment]
root@GGSN-960#show
MassT_Pool{
familyinet{
network{
15.0.0.0/14{
range{
Range_Name{
low15.0.0.1;
high15.3.255.254;
external-assigned;
}
}
}
}
}
}
}
You should note that the external-assigned option has been set. The
external-assigned option just means the MBG is not assigning the IP
Addresses locally, but instead an outside resource such as a RADIUS

server or DHCP will assign them, or they can even be assigned statically
by the UE.
Note, too, the range that the IP Pool will cover: from 15.0.0.1 to
15.3.255.254. You must define the range. If you receive an IP address
from the external source outside of this range, the Create PDP Context/
Create Session request message will be rejected by the MBG.
We should mention the default-pool option here. The default-pool
option labels the pool usage as one of the MBGs default pools, which is
used when the APN configuration on the MBG does not explicitly call
out a specific pool. We will create a default pool called MassT_Pool_2 as
seen below:
[edit routing-instances GI_VR access address-assignment mobile-pools Masst_Pool_2]
root@GGSN-960# show
familyinet{
network{
18.0.0.0/24{
range{
ranger{
low18.0.0.1;
high18.0.0.254;
}
}
}
}
}
default-pool
It should be noted that when setting up an APN you cannot have a

default pool directly tied to it. For example under [edit unified-edge
gateways ggsn-pgw MASST apn-services apns masst.com address-as-
33
34
signment inet-pool] do not set a pool that contains the default-pool

flag or you will receive this error:
[editunified-edgegatewaysggsn-pgwMASSTapn-servicesapnsmasst.comaddressassignment]
'inet-pool'
ForAPNmasst.com,referencedpoolMasst_Pool_2inrouting-instanceGI_
VR,cannotbeadefault-pool
error:configurationcheck-outfailed
You can gather Mobile-IP-Pools in groups to evenly load-balance IP

assignment. If you set up a Mobile-IP-Pool group, add two or more
Mobile-IP-Pools to that group and then tie that group to an APN.
Doing so round-robins the IP Assignment evenly between the pools
when the address assignment is handled locally on the MBG, or you
can have a mobile pool group with only one mobile pool. Its a neat
way to provide the ability to switch address pools around, without
taking the whole APN servicing the pool to maintenance mode. More
on maintenance mode in a later section.
NOTE
You can use an AAA server such as the Juniper Steel Belted Radius
Carrier AAA solution to assign IP addresses. Steel Belted Radius
Carrier AAA can weigh the pools using different modules of distribution. You may even be able to use the JavaScript module on the Steel
Belted RadiusCarrier AAA server to perform even more flexible IP
Pool assignment models. Check the latest Steel Belted Radius Carrier
AAA documents for further details.
So for Mass Telecom lets add a third small pool called MassT_Pool_3,
which will be an internally assigned pool, meaning that the MBG will
be the one assigning the IP Addresses. This should allow you to see if
load balancing works.
Lets also add the Mobile-IP-Pool group called Mobile_Pool_Group_1
in which the two IP pools MassT_Pool and MassT_Pool_3 are placed.
Lets take a peek:
[editrouting-instancesGI_VRaccessaddress-assignment]
root@GGSN-960#show
mobile-pools{
MassT_Pool{
familyinet{
network{
15.0.0.0/14{
range{
Range_Name{
low15.0.0.1;
high15.3.255.254;
external-assigned;
}
}
}
}
}
}
MassT_Pool_3{
familyinet{
network{
10.3.219.200/30{
range{
Range_Name{
low10.3.219.200;
high10.3.219.203;
}
}
}
}
}
}
}
mobile-pool-groups{
Mobile_Pool_Group_1{
MassT_Pool_3;
MassT_Pool;
}
}
The newly added Mobile-IP-Pool Group can now be added to an

APN. Do not worry about the actual APN configuration yet, that
happens in a few more pages. But to take a peek ahead, here is where
you would add the Mobile-IP-Pool Group:
[editunified-edgegatewaysggsn-pgwGGSN1apn-servicesapnsNScotiaaddressassignment]
root@GGSN-960#show
inet-pool{
groupMobile_Pool_Group_1;
}
Pretend for one moment that the Gateway and APN are also configured and Mass Telecom wants to test this and they have six mobile
devices coming online. Use the show unified-edge ggsn-pgw subscriberscommand and you can see that this worked. The six subscribers were evenly load balanced between the two pools also, check
out the IP addresses:
root@GGSN-960#runshowunified-edgeggsn-pgwsubscribers
IMSIMSISDNSubscriberPeerAPN
AddressAddress
3022001122334972673777410.3.219.20110.3.219.32NScotia
3022001122335292673777610.3.219.20210.3.219.32NScotia
3022001122334652673777210.3.219.20010.3.219.32NScotia
3022001122335132673777515.4.9.310.3.219.32NScotia
3022001122334492673777115.4.9.110.3.219.32NScotia
3022001122334812673777315.4.9.210.3.219.32NScotia
35
36
To monitor the state of your pools use the show unified-edge ggsn-pgw
address-assignment pool command. This snippet shows how useful it
is to see how many IP addresses are used in a given pool and if you
have allocated enough to meet your use.
Pool:MassT-Pool-3
Totaladdresses:500
Addressesinuse:250
Addressesskipped:0
Addressusage(percent):50
Addressesinagingperiod:0
Routinginstance:GI_VR
Pool:MassT_Pool_2
Totaladdresses:254
Addressesinuse:0
Addressesskipped:0
Pool:MassT_Pool
Totaladdresses:16777214
Addressesinuse:620
Addressesskipped:336
Addressusage(percent):0.
The Gateway Configuration

Next up is the Gateway configuration, which is the very heart of our
mobile setup.
Lets create a gateway called Masst under which we will configure
APNs, GTP settings, and other fun mobile stuff.
[editunified-edgegatewaysggsn-pgwMasst]
Lets set the maximum-bearers to be 2000000. Remember Masst has just

over 1 million subscribers and they hope to grow their business.
root@GGSN-960#setmaximum-bearers2000000
NOTE
Its generally recommended that you configure a larger number for the
GW-level maximum-bearers than you believe is needed. You can then
configure lower values at the APN-level for maximum-bearers, an
example of which is covered in just a moment. This process allows you
to add new APNs in the future without requiring a configuration
change at the GW level.
Next, lets set up the GTP section using the Gn interface for our
example, which tells the MBG what loopback interface will anchor all
incoming PDP Create Context requests. While some may say, all
roads lead to Rome, all MPC interfaces that handle GTP requests
head to this interface. Note that there are some additional retry/
timeout settings to be left alone for now. Unless there are latent
network issues between the MBG and its GTP peers, the default
settings are typically just fine.
gtp{
gn{
interfacelo0.1v4-address201.100.1.6;
n3-requests5;
t3-response5;
path-managementenable;
echo-n3-requests3;
echo-t3-response5;
}
Junos permits the following flexible options when configuring the

loopback interface under the GTP configuration:
Single IP address for ALL GTP traffic
Different IP address for GTP traffic received on different 3GPP
interfaces (Gn, S5, S8, and even the Gp interface)
Different IP addresses for control/GTP-C and data/GTP-U traffic
on a single interface (say S5 or Gn)
Remember in our example that MassT chose to configure the loopback
on just the 3G GN interface for Control and Data.
Finally, lets review how to label a subscriber as a home subscriber. By
default, every single subscriber that hits the Juniper MBG is seen as
being a visitor. As you will see in a few pages, visitors can be blocked
from using certain APNs.
To label a subscriber as a home subscriber, configure the home public
land mobile network (plmn) section under the gateway. Here is the
MCC and MNC that Mass Telecom considers a home subscriber:
[editunified-edgegatewaysggsn-pgwMassthome-plmn]
root@GGSN-960#show
mcc310mnc909;
The MCC (Mobile Country Code) is 310, which is one of the Mobile
Country codes for the United States. The MNC (Mobile Network
Code) is 909, which is the hypothetical unique Mobile Network Code
for our example carrier Mass Telecom.
37
38
So an IMSI of 310909123456789 will be considered a home subscriber to the MBGs network. An IMSI of 310150123456789 will be
considered a visitor.
Access Point Name (APN) Configuration

Now its time to set up an APN for Mass Telecom. This will be easy. In
our example, lets expect these UEs to all have an APN name hardcoded with the string masst.com. Since the APN will be masst.com, lets
call it masst.com:
apn-services{
apnsmasst.com{
Next since we limited the MBG to 2000000 subscribers/PDP contexts

based on the configuration added under the gateway, this APN, which
is Mass Telecoms main home APN, should be able to use most of those
bearers. So maximum-bearers for this APN will be 1500000:
maximum-bearers1500000;
Mass Telecom does not want any IMSIs, or visitors, that do not belong
to this Mobile Network to have access to this APN. No one is going to
reconfigure their BlackBerry, set the APN-Name to masst.com, and get
on this APN with their non-Mass Telecom sim card! We will set
block-visitors:
block-visitors;
Next configure a type for the APN. Waita what? What is a type?
Okay, good point. Currently you have a few options for types:
Real This type of APN is where a real service is provided. It can
be accessed either by the APN received directly from the UE in
the GTPc PDP Context Request or by a redirection from a virtual
APN as seen below.
This means the APN name sent from the UE is used, so in this
case masst.com.
Virtual This APN type is used when the GTP Create PDP
Context message contains an APN name, but the name must be
mapped to an APN the MBG has configured as a real APN. The
mapping is done by configuring the service selection profile
section (something youll do a little later in this book).
This APN type can also map to a real APN through a RADIUS
server. The RADIUS server may be configured to return the
attribute JNPR-APN-Name in a RADIUS Access Accept packet.
Lets make life simple for Mass Telecom and choose real as our
option. It works for our example because that is the only APN Mass
Telecom wants to use and their RADIUS server is not passing back
the RADIUS Attribute JNPR-APN-Name.
apn-typereal;
Since this is a small regional carrier dealing only in IPV4, the apndata-type is obvious. (One day they may move to IPV6 one day.)
apn-data-typeipv4;
To tie this APN into an IFL, chose a mobile interface, and since there
is only one so far, the choice is easy to make:
mobile-interfacemif.16000;
And its already been decided to use RADIUS to assign the IP addresses to our UEs:
address-assignment{
aaa;
}
And here is the AAA profile for use for this APN. Details for this
Radius profile setup come later:
aaa-profileMASST_AAA_Profile;
Under the APN section, you can configure the MBG to use an
anonymous username, which it will send to the RADIUS server if you
are configuring RADIUS for this APN and the UE does not send a
username in the Create PDP Context Request Message. If you do not
set the anonymous user, and the UE and SGSN do not send over a
username, the subscriber/PDP Context activation will fail unless your
RADIUS Server is configured to not look at the User-Name and
User-Password RADIUS attributes (expect very few RADIUS servers
to be configured this way):
anonymous-user{
user-namewhoami;
password"$9$uj9pOEcrevL7-le";##SECRET-DATA
}
Now lets review what selection mode to use. The selection mode
indicates the origin of the APN and whether or not the Home
Location Register (HLR) has verified the user subscription. The
selection mode type is represented by the values: 0, 1, 2, or 3, as
shown in Table 3.1.
39
40
Table 3.1
Selection Mode Values
Selection Mode Value
Value (Decimal)
MS or network provided AP, subscription verified
MS provided APN, subscription not verified
Network provided APN, subscription not verified
For future use. Shall not be sent. If received, shall be

interpreted as the value 2
Simply put, this field in the Create PDP Context/Create Session request
will tell you if the SGSN/MME or the Mobile Equipment assigned the
APN string and if the subscriber was verified or not verified. By the
way, verified means that the SGSN successfully communicated with the
HLR/HSS and that the HLR/HSS verified the subscriber.
Take a look at this Create PDP Context Request message and you can
see the Selection Mode is 0.
Figure 3.1
Create PDP Context Request
Mass Telecom likes this feature. They do not want to use no-subscribed because they have no desire to reject verified subscribers.
Whats more, their SGSNs do not assign the APN. Their handhelds
assign the APNs, but there are instances where the HLR may not verify
these subscribers, so Mass Telecom still wants to let them in. Here are
the options:
root@GGSN-960#setselection-mode?
Possiblecompletions:
<[Enter]>Executethiscommand
from-msAdmitMSprovidedAPN,subscriptionnotverified
from-sgsnAdmitNetworkprovidedAPN,subscriptionnotverified
no-subscribedRejectsubscribedverifiedUsers
And here is what Mass Telecom wants configured:

selection-mode{
from-ms;
}
Under [edit unified-edge] here is what the whole configuration
would look like so far, based on our example Masst plus some Traceoptions that we will talk about in a later section:
gateways{
ggsn-pgwMassT{
preemption{
enable;
}
gtp{
gn{
n3-requests5;
t3-response5;
echo-n3-requests3;
echo-t3-response5;
}
traceoptions{
filegtp.logsize50m;
levelall;
flagall;
}
}
traceoptions{
filegateway.logsize50m;
levelall;
flagall;
}
apn-services{
apnsmasst.com{
block-visitors;
apn-typereal;
apn-data-typeipv4;
address-assignment{
aaa;
}
aaa-profileMASST_AAA_Profile;
anonymous-user{
user-namewhoami;
}
selection-mode{
41
42
from-ms;
}
}
}
system{
anchor-pfes{
interfacepfe-5/1/0;
interfacepfe-0/0/0;
}
anchor-spics{
interfaceams0;
interfaceams1;
}
}
software-datapath{
traceoptions{
filesoftdatapath.logsize50m;
flagall;
}
}
}
}
Service Selection Profile

This next exercise shows you the Junos feature service selection
profile. The use case is not the greatest, but it is simple and should
show you how to use the feature.
Lets assume Mass Telecom has just signed a roaming agreement with a
Nova Scotia-based service provider called Nova Scotia Telecom, or Nscotia, for short. When subscribers from this telecom head on down to
the Massachusetts area, they can come onboard, meaning they can still
get data service from Mass Telecoms RAN/Packetcore. NScotias UEs
have either the APN of internet123 or Canada. Mass Telecom wants to
use just one APN to manage these subscribers, so this use case is going
to create a service-selection-profile that will grab any IMSI starting
with country code 302 (Canada) and network code 200 (Nscotia
Telecom) visiting from Nova Scotia Telecom, and then apply the
apn-name NScotia to the subscriber session.
To do this requires setting up a service selection profile on the MBG
like this:
[editunified-edgegatewaysggsn-pgwMasstservice-selection-profiles]
root@GGSN-960#show
profileNScotia_profile{
termTerm1{
from{
imsi302200;
}
then{
apn-nameNScotia;
}
}
}
Next you have to have an entry for the APN name internet123 and
Canada that Nscotias UEs send, so lets add an APN type of virtual
and lets call the service-selection-profile. Virtual APNs still need
to use a unique MIF:
apnsinternet123{
apn-typevirtual;
service-selection-profileNScotia_profile;
}
apnsCanada{
apn-typevirtual;
service-selection-profileNScotia_profile;
}
Now lets set up the apn NScotia and remember to go back and attach
the mobile-interface to the GI_VR routing instance. Mass Telecom

expects a low number of roamers from Nscotia, so lets set the maximum-bearers to 250000. Also, lets use a new local pool weve created
called visitor Mass Telecom wants all visiting subscribers to use this
IP range:
apnsNScotia{
maximum-bearers 250000
apn-typereal;
address-assignment{
inet-pool{
poolvisitor;
}
}
}
And, for your reference, here is what the visitor pool looks like:
[editrouting-instancesGI_VRaccessaddress-assignmentmobile-poolsvisitor]
root@GGSN-960#show
familyinet{
network{
15.4.0.0/16{
range{
rangerName{
low15.4.0.1;
high15.4.255.254;
}
}
}
}
}
43
44
The Charging Configuration

The current roaming agreement that Mass Telecom has with its
counterpart up in Nova Scotia is that Mass Telecom will bill NScotia
based on the number of subscribers that hit its network in any given
month. Hence, Mass Telecom has a Charging Gateway they need the
MBG to use for the NScotia APN.
Setting up the Charging Client on the MBG is simple as pie. Take a
look:
[editunified-edgegatewaysggsn-pgwMsstcharging]
root@GGSN-960#show
cdr-profiles{
CDR_profile_ONe{
enable-reduced-partial-cdrs;
exclude-ie-options{
apn-ni;
apn-selection-mode;
cc-selection-mode;
pgw-plmn-identifier;
list-of-service-data;
lrsn;
network-initiation;
node-id;
pdn-connection-id;
pdppdn-type;
rat-type;
record-sequence-number;
served-pdppdn-address;
serving-node-plmn-identifier;
}
}
}
trigger-profiles{
TriggerProfile_One{
exclude{
qos-change;
rat-change;
}
offline{
volume-limit{
10485760;
directionboth;
}
time-limit600;
}
}
}
transport-profiles{
TransportProfileOne{
offline{
charging-gateways{
cdr-releaser8;
peer-order{
peerChargingOne;
}
}
}
}
}
charging-profiles{
ChargingProfile_One{
profile-id101;
transport-profileTransportProfileOne;
cdr-profileCDR_profile_ONe;
trigger-profileTriggerProfile_One;
}
}
gtpp{
n3-requests5;
echo-interval60;
t3-response5;
reconnect-time60;
peerChargingOne{
destination-ipv4-address10.3.219.32;
source-interface{
xe-5/0/1.0;
}
destination-port3386;
transport-protocoludp;
versionv0;
}
}
Okay, so maybe its not so easy. In fact it is quite convoluted, but lets
break it down.
The GTPP section is where you set the GTP prime basics: the reconnect
times, the timeout intervals, the port, protocol, and which GTP version
to use. Mass Telecom happens to use UDP with GTP version 0 for their
GTP Prime connection.
You also set up the CGW (Charging Gateway) under this section.
MOBILE TIP GTP prime uses the same message structure as GTP-C and GTP-U. It is
used for carrying charging data from the Charging Data Function
(CDF), which is the GGSN/PGW to the Charging Gateway Function
(CGF).
And here Mass Telecom has configured a single CGW at 10.3.219.32.
The MBG uses the source-interface xe-5/0/1 on the default VR to reach
this CGW. Port, transport, and GTP version have also been set here:
45
46
gtpp{
n3-requests5;
echo-interval60;
t3-response5;
reconnect-time60;
peerChargingOne{
destination-ipv4-address10.3.219.32;
source-interface{
xe-5/0/1.0;
}
destination-port3386;
transport-protocoludp;
versionv0;
}
}
Next, set up the Transport Profile. There is not much to this section
since currently as of Junos 11.4w2, the MBG only supports offline
charging, but its here that you set up the cdr-release that the CGW
supports and set up the CGW peers that you want to connect to. As
stated previously, Mass Telecom has only one CGW. If they add a
second one, remember the top configured peer in the order is selected
first as the active CGW. When the active CGW goes down, the next
peer is selected. If all the charging gateways are down and you have
configured local persistent storage, then the CDRs are stored on the
Routing Engine if an SSD card is installed.
transport-profiles{
offline{
charging-gateways{
cdr-releaser8;
peer-order{
peerChargingOne;
}
}
}
}
}
MOBILE TIP Offline charging is based on CDR file processing and is a Post Paid
scenario where subscribers are typically billed at a later time. Online
charging is real-time and can tie into service application control. For
example, subscribers can find their data thruput downgraded if they
use too much in a period of time
The trigger-profiles section is where you determine when a CDR is
created for a subscriber session. Mass Telecom has decided to exclude
the events qos-change and rat-change from kicking off a CDR. The
other trackable events Location area update for the mobile subscriber, IP Address update being deferred, mobile equipments time zone
changes, and the Public Land Mobile Network changes for the mobile
subscriber will all create CDR. You can always add these to the
exclude section if Mass Telecom feels they do not want to track them.
Also Mass Telecom has decided when the user has received or sent 10
Megs of data, a CDR will be created. On top of that, if a CDR has not
been created for 10 minutes a CDR will be created. So lots of events
can create a CDR record.
trigger-profiles{
TriggerProfile_One{
exclude{
qos-change;
rat-change;
}
offline{
volume-limit{
10485760;
directionboth;
}
time-limit600;
}
}
}
Next up is the CDR profile. You can do a few things under this section
because Mass Telecom chose to set enable-reduced-partial-cdrs
(RPCs). The RPCs should only contain mandatory fields and information regarding changes in the session parameters relative to the previous CDR. For example, if the user equipment location has not
changed, then this information is excluded from the RPC because this
information has not changed from the previous CDR. This helps make
the CDR records smaller, which Mass Telecom obviously likes, since it
makes dealing with their billing records easier.
Mass Telecom has also decided to exclude numerous options that are
not needed for their charging model from being placed into the CDR
and these exclusions are also configured under the CDR profile, as seen
here:
cdr-profiles{
CDR_profile_ONe{
enable-reduced-partial-cdrs;
exclude-ie-options{
apn-ni;
apn-selection-mode;
cc-selection-mode;
pgw-plmn-identifier;
list-of-service-data;
lrsn;
network-initiation;
node-id;
pdn-connection-id;
pdppdn-type;
47
48
rat-type;
record-sequence-number;
served-pdppdn-address;
serving-node-plmn-identifier;
}
}
}
Heres a full list of options that you can exclude:

apn-niExcludeAPNnetworkidentifierIEintheCDR
apn-selection-modeExcludeAPNselectionmodeIEintheCDR
cc-selection-modeExcludechargingcharacteristicselectionmodeIEintheCDR
dynamic-addressExcludedynamicaddressIEintheCDR
list-of-service-dataExcludelistofservicedataintheCDR
list-of-traffic-volumesExcludelistoftrafficvolumesintheCDR
lrsnExcludelocalrecordsequecenumberIEintheCDR
ms-time-zoneExcludeMStimezoneIEintheCDR
network-initiationExcludenetworkinitiationflagintheCDR
node-idExcludenodeIDIEintheCDR
pdn-connection-idExcludePDNconnectionIDIEintheCDR
pdppdn-typeExcludePDPorPDNtypeIEintheCDR
pgw-plmn-identifierExcludePGWPLMNidentifierIEintheCDR
rat-typeExcludeRATtypeIEintheCDR
record-sequence-numberExcluderecordsequencenumberIEintheCDR
served-imeisvExcludeservedIMEIIEintheCDR
served-msisdnExcludeservedMSISDNIEintheCDR
served-pdppdn-address
ExcludeservedPDPcontextorIPCANbeareraddressIEintheCDR
serving-node-plmn-identifierExcludeservingnodePLMNidentifierIEintheCDR
start-timeExcludestarttimeIEintheCDR
stop-timeExcludestoptimeIEintheCDR
user-location-informationExcludeuserlocationIEintheCDR
Now lets tie all these configurations together under a Charging Profile.
Lets also add a profile-id for this charging profile that well call ChargingProfile_One (note the GTPP settings are global to the gateway, so
while they are tied to Charging, GTPP settings do not go under the
Charging Profile):
charging-profiles{
ChargingProfile_One{
profile-id101;
transport-profileTransportProfileOne;
cdr-profileCDR_profile_ONe;
trigger-profileTriggerProfile_One;
}
}
The charging profile called ChargingProfile_One is ready at this point,

so lets add it to the NScotia APN, using the default profile that covers
Home, Visiting, and Roaming subscribers.
[editunified-edgegatewaysggsn-pgwMasstapn-servicesapnsNScotiacharging]
root@GGSN-960#show
default-profileChargingProfile_One;
You could add additional profiles to meet these additional scenarios if

you need to be granular:
home-profileDefaulthomeprofilefortheapn
roamer-profileDefaultroamerprofilefortheapn
visitor-profileDefaultvisitorprofilefortheapn
You could even offer Mass Telecom the ability to assign the Charging
Profile from RADIUS or from the SGSN/SGW. But Mass Telecom has
chosen to just assign the profile locally, so they do not need to set a
selection order:
[editunified-edgegatewaysggsn-pgwMasstapn-servicesapnsNScotiacharging]
root@GGSN-960#setprofile-selection-order?
[Openasetofvalues
radiusSelectchargingprofilesentbyradius
staticSelectchargingprofilelocallyconfigured
servingSelectchargingprofilesentbySGSNorSGW
Once you have your Charging settings configured you can run a few
commands to make sure everything is working:
root@GGSN-960#runshowunified-edgeggsn-pgwchargingpathstatus
ChargingPathStatus
Peer-AddressPeer-NameLocal-AddressStatusEcho
10.3.219.32ChargingOne10.3.219.72ConnectedEnabled
root@GGSN-960#runshowunified-edgeggsn-pgwchargingpathstatistics
ChargingPathStatistics
CGFAddress:10.3.219.32CGFServerName:ChargingOne
EchoRequestsRx:0EchoResponsesTx:0
EchoResponsesRx:0EchoRequestsTx:4146
Node-AliveRequestsRx:0Node-AliveResponsesTx:0
VersionNotSupportedRx:0VersionNotSupportedTx:0
EchoRequeststimedout:0EchoInterval:60
DownDetectionInterval:10ReconnectTimeInterval:60
DestinationPort:3386PendingQueueSize:0
PathManagerFPCSlot:2PathManagerPICSlot:0
T3ResponseTimeInterval:5PathManagerPort:30241
SourceInterfaceValid:YesGTPPHeaderType:long
N3Requests:5LocalAddress:10.3.219.72
GTPPVersion:V0TransportProtocol:UDP
Before leaving the charging section and moving on, it should be mentioned that you can also store CDRs locally on the SSD card in the RE.
The CDR files are available for transfer from the /opt/mobility/
charging/ggsn/final_log directory. This option may be considered a
must for setups that will not use the GA interface to a Charging Gateway. With this option, you can retrieve the files off the box with a
protocol such as FTP or SCP and then clean the files off the box.
49
50
Edit in the transport-profiles section. Remember this is under:

unified-edge > gateways > ggsn-pgw > Masst > charging
and add a new offline> charging gateway field called persistentstorage-order. Its value will be local-storage. Heres an example:
transport-profiles{
offline{
charging-gateways{
cdr-releaser8;
peer-order{
peerChargingOne;
}
persistent-storage-order{
local-storage;
}
}
}
}
}
Next under unified-edge > gateways > ggsn-pgw > Masst > charging
lets add the options for the local CDR storage. Mass Telecom has the
following options set:
local-persistent-storage-options{
file-age60;
file-size512;
cdrs-per-file25000;
file-format3gpp;
disk-space-policy{
water-mark-level1{
percentage70;
notification-levelboth;
}
water-mark-level2{
percentage85;
notification-levelsnmp-alarm;
}
}
}
Youcanmonitorthestatusofthelocalstoragewiththishelpfulcommand:
root@GGSN-960#runshowunified-edgeggsn-pgwcharginglocal-persistentstoragestatistics
Gateway:Masst
Charginglocal-persistent-storageStatistics
BatchMessagesreceived:131
BatchResponsessent:131
InvalidMessagesreceived:0
Numberoftemplogfilesopened:10
Numberofjournalfilesopened:10
Numberofjournalfilesclosed:9
NumberofCDRlogfilesclosed:10
NumberofCDRfilesclosedduetofile-age:8
NumberofCDRfilesclosedduetofile-size:0
NumberofCDRfilesclosedduetocdr-count:0
Abnormalfileclosures:2
Normalfileclosures:8
NumberofCDRlogfilesclosedinTS_32_297format:0
NumberofCDRlogfilesclosedinrawasn1format:10
TotalnumberofCDRsbackedup:131
DiskFullmessagessent:0
DiskFullresolvemessagessent:0
NumberofasyncIOreqswritten:131
Diskspacestatus:DISK_AVAILABLE
Watermarklevel1at(MB):2276(70%)
TemporaryCDRlogfileStatistics
FileName:/opt/mobility/charging/ggsn/temp_log/templog_file_2.log
Journalfilename:/opt/mobility/charging/ggsn/jrnl/jrnl_2.log
CurrentnumberofCDRs:11
Currentfilesize(bytes):3084
Fileagetrigger(mins):60
Filesizetrigger(bytes):10485760
CDRcounttrigger:0
GlobalStatistics
DiskOfflinemessagessent:0
DiskAvailablemessagessent:0
NumberofCDRstoragefilesondisk:1814
Currentstoragespaceinuse(MB):305
Availablestoragespaceondisk(MB):2947
Totalstoragespaceondisk(MB):3252
Note that Mass Telecom did apply watermarks so they are notified if
disk space is filling in case their file retrieval is not happening, or the
cleanup is not occurring at close enough intervals based on the number
of CDRs that get created during peak hours.
This concludes all the processes of the Charging Configuration.
The RADIUS Configuration

At last you finally get to set up RADIUS on the MBG! Though RADIUS is optional on the MBG, Mass Telecom wants to use their AAA
server, so lets walk through this setup.
The process requires you to first set up a RADIUS server under the [Access] hierarchy, which is at the top of the Junos configuration, and to
then add it to a network-element group. The network-element group
for Mass Telecom uses the same source-interface on the MX as the
Charging Gateway.
51
52
So far, Mass Telecom has only one RADIUS Server; this is not very
practical in the real world but is simple for our testing since you only
need one RADIUS server running in your lab. Heres the configuration:
Access{
radius{
servers{
t1k-16g{
address10.3.219.95;
port1812;
accounting-port1813;
secret"$9$.Pz3/CtOIE9C";##SECRET-DATA
accounting-secret"$9$noT2/p01RhrKMIR";##SECRET-DATA
allow-dynamic-requests;
dynamic-request-secret"$9$B4CISrKM87dbvM";##SECRET-DATA
source-interfacexe-5/0/1;
}
}
network-elements{
Network_Element_1{
servert1k-16gpriority1;
}
}
}
}
Next, head over to [edit unified-edge aaa]. Here you are going to
edit the mobile-profiles and add a profile called Masst_AAA_Profile.

Then add the network-element for both authentication and accounting.
NOTE
This is the first time you have configured anything under the unifiededge hierarchy that was not directly tied to a gateway configuration. So
this configuration would be global to all Gateways configured on this
box. Remember Mass Telecom is only setting up a single gateway in this
book.
root@GGSN-960#show
mobile-profiles{
Masst_AAA_Profile{
radius{
authentication{
network-elementNetwork_Element_1;
}
accounting{
network-elementNetwork_Element_1;
}
}
}
}
Now lets edit the masst.com APN by adding the Masst_AAA_Profile to

aaa-profile so our Authentication and Accounting requests will get sent
to the RADIUS server, and creating an anonymous user. More on the
anonymous user in a minute. First, take a look at the configuration

added here to enable the masst.com APN to use RADIUS:
[unified-edgegatewaysggsn-pgwmasstapn-servicesapnsmasst.com]
root@GGSN-960#show
aaa-profileMasst_AAA_Profile;
anonymous-user{
user-namewhoami;
}
Okay, so about that anonymous user. Why add that account here? This
was discussed earlier when looking at the Virtual APN type, but now
lets go into a bit more detail. In a RADIUS request the user User-Name
must be present.
Per RADIUS RFC 2865: This Attribute indicates the name of the user
to be authenticated. It must be sent in Access-Request packets if
available.
The RFC states the User-Name attribute must be present, only if
available. Yes, most RADIUS servers choke on the lack of the UserName attribute, so as of this writing the MBG code requires the
anonymous-user. What happens if you fail to add it? Well, the GGSN
will reject the PDP Context Create request with an Encoding cause
Authentication failure message added to the GTP log and will not
even try to send a Radius Request out. So please save yourself
another headache.
You might ask why can you only use the user-name in the GTP-C
message sent in the PDP Context Create request. Look at a snoop sent
from the SGSN over the Gn interface to the GGSN and youll see the
MSIDSN and the IMSI, but no username to identify the client. This is
not PPP, or 802.1x, or any other subscriber technology where each
subscriber must be identified by a user. This is a mobile solution where
the IMSI is the identity for the GGSN. In some carriers networks the
UE and SGSN may send a username, but remember it is not required.
In the Create PDP Context request you may see a Protocol Configuration Option with a PAP or CHAP section. For example look at this
snoop in Figure 3.2.
53
54
Figure 3.2
Protocol Configuration Options
Okay, Mass Telecoms SGSN and UEs are using the anonymous user
since the SGSN does not send any value. But what can the MBG send
to RADIUS, just this hardcoded anonymous string? Does this mean
from a GGSN/PGW to RADIUS server point of view, there is only one
user per APN, this hardcoded anonymous user? Its not very flexible,
and theres no ability to utilize different attributes from RADIUS to
provision individual subscribers sessions. Right?
Wait, stop complaining. The MBG does have options to get around the
lack of a RADIUS User-Name being present. You replace the anonymous username sent in the RADIUS request with any one of these
variables:
use-apnnameUseAPNnameforuserauthentication
use-imsiUseimsiforuserauthentication
use-msisdnUsemsisdnforuserauthentication
RADIUS Features
Mass Telecom sells some cool mobile devices. These expensive Mass
Telecom devices have a nice high monthly fee and have a hardcoded
APN masst.bb that needs to be added to the MBG. This APN will be
55
similar to the masst.com APN. But Mass Telecom needs to set up this
APN to use the individual IMSI as the user-name sent to RADIUS in
case they need to return specific RADIUS attributes for a given subscriber for unique services, such as setting Ingress and Egress policies.
So:
[editunified-edgegatewaysggsn-pgwMasstapn-servicesapnsmasst.bb]
root@GGSN-960#show
anonymous-user{
use-imsi;
password"$9$FngmnApO1RSlKB1";##SECRET-DATA
Now Mass Telecom also wants to use their RADIUS server for handling accounting information for the APN masst.com and masst.bb. If
you dig down, there is a trigger section under the aaa mobile-profiles
hierarchy. Mass Telecom wants to send interim accounting updates
every 15 minutes and they do not want updates sent when there is a
QOS change or a RAT change. Other trackable events location area
update for the mobile subscriber, IP Address update being deferred,
mobile equipments time zone changes, and the Public Land Mobile
Network changes for the mobile subscriber will all create a new
interim accounting packet when that event occurs. Remember, Mass
Telecom can always add these as excluded events in the future if they
feel tracking them is an unnecessary creation of an accounting record:
[editunified-edgeaaamobile-profilesMasst_AAA_Profileradiusaccountingtrigger]
root@GGSN-960#show
no-rat-change;
no-qos-change;
interim-interval15;
And here is a snippet of the accounting output from a Juniper Steel

Belted RADIUS Carrier AAA server that receives RADIUS packets
from the MBG. You can see the Accounting START packet shows the
session being created and the Accounting Interims for this session
(based on the Acct-Session-ID) come in 15 minutes later due to the
accounting trigger above. You can see that the subscriber has been
sending GTP-U Data, since the Acct-Input-Octets and Acct-OutputOctets increase.
Acct-
Acct-
Acct-
Acct-
RAS-
Record-
Full-
User-
NAS-IP-
Status-
Delay-
Input-
Output-
Octets
Octets
432674944
13815552
Date
Time
Client
Type
Name
Name
Address
Type
Time
7/20/2011
13:24:44
<ANY>
Start
WHOAMI
whoami
10.3.219.72
7/20/2011
13:39:46
<ANY>
Interim
WHOAMI
whoami
10.3.219.72
Acct-Session-Id
0A03DBFA0C001001
0A03DBFA0C001001
56
QOS / COS
The last item to configure is QoS. No, wait, this is Junos. Its CoS, and
mobile CoS to be exact.
Play along for a moment and assume the engineers at Mass Telecom
are looking at a test subscriber session:
root@GGSN-960#runshowunified-edgeggsn-pgwsubscribersextensive
SubscriberInformation:
IMSI:123456789459595IMEI:None
MSISDN:26737745TimeZone:None(DST):None
Status:Visitor
UserLocationInfo:
MCC:NoneMNC:None
LAC:0x0CI:0x0SAC:0x0RAC:0x0TAC:0x0ECI:0x0
RATType:Unknown
PDNSession:
APNname:masst.com
IPv4Address:15.4.16.1IPv6Address:None
DirectTunnel:DisabledSessionDuration:3:20:32
LocalControladdress:10.3.219.250RemoteControladdress:10.3.219.32
TEIDControlLocal:0xc001547TEIDControlRemote:0x100
Addressingscheme:LocalSelectionmode:subverified
SessionPIC:2/0(FPC/PIC)AnchorPFE:10/0(FPC/PIC)
SessionState:EstablishedGTPVersion:1
Servingnetwork:MCC:NoneMNC:None
Bearer:
NSAPI/EBI:5ChargingID:0xc001547
LocalDataaddress:10.3.219.250RemoteDataaddress:10.3.219.32
LocalTEID:0x3420b6RemoteTEID:0xff
BearerState:EstablishedSubstate:-
IdleTimeout:0min(0-0,0)AAAInterimInterval:0min(0-0,0)
NegotiatedQoSParameters:
TrafficClass:InteractiveARP:1
TrafficHandlingPriority:3TransferDelay:10
MBRUplink:128kbpsMBRDownlink:128kbps
GBRUplink:128kbpsGBRDownlink::128kbps
SignalingIndicator:0
ForwardingClass:-LossPriority:-
RequestedQoSParameters:
TrafficClass:InteractiveARP:1
GBRUplink:128kbpsGBRDownlink:128kbps
Charginginformation:
ProfileID:0
State:InitPreviousState:Init
Profileselectioncriteria:-
Offlinecharginginformation:
Currentservicedatacontainersequencenumber:0
Currentpartialrecordsequencenumber:0
NumberofCDRsclosed:0
Ratinggroupinformation:
Ratinggroup:0Serviceid:0
ActionID:0x0Triggerprofile:0
Changeconditionbitmask:0x0Action-id-bitmask:0x0
Signalbitmask:0x0Lastsignalbitmask:0x0
Laststatisticscollectiontime:Nonecollected
Note the bolded output, which is just what the Mass Telecom engineers are seeing, too. Is that 128 kbps for their MBR (Maximum Bit
Rate)? Is that what QoS is set to? Well actually, on the MBG nothing
has been set yet. Lets look at a snoop in Figure 3.3 to see what is
requested in the Create PDP Context request, received from the SGSN,
since our example is a 3G test.
Figure 3.3
What is Requested in the Create PDP Context Request?
Okay, as you can see from the SGSN, they are requesting a MBR of
128k. The MBR value should be 5 Mbs from what Mass Telecom
requires for this test subscriber who likes HD YouTube videos, which
require a pipe larger than 128k. They call in the SGSN/HLR team and
have them change what is requested for the QoS settings.
After the change, lets test a subscriber again and see how it went:
root@GGSN-960#runshowunified-edgeggsn-pgwsubscribersextensive
IMSI:123456789460360IMEI:1122334455667791
Status:Visitor
UserLocationInfo:
MCC:NoneMNC:None
RATType:Unknown
PDNSession:
APNname:masst.com
57
58
DirectTunnel:DisabledSessionDuration:4
TEIDControlLocal:0x14002d2eTEIDControlRemote:0x106
Bearer:
NSAPI/EBI:5ChargingID:0x14002d2e
LocalTEID:0x143400a8RemoteTEID:0x105
TrafficClass:BackgroundARP:1
ForwardingClass:-LossPriority:-
TrafficClass:BackgroundARP:1
ProfileID:0
From the bolded output you can see that the SGSN is requesting 6MB
and thats great, but from the MBG/GGSN side this needs to be 5MB
as per Mass Telecoms management team. They do not want to give
away too much bandwidth per subscriber. Time for the Mass Telecom
GGSN engineers to take control. Lets go under the unified-edge
hierarchy to set the Mobile COS settings.
NOTE
Its important to point out that the Mobile COS settings can be used
globally across all gateways since they are set under unified-edge
directly, and are not tied directly to a Gateway.
So we will create a simple COS policy profile called Masst_QoS under

cos-cac (Class of Service Call Admission Control). The cos-policyprofile we are creating is simple, since it is just stating any type of
traffic, also known as 3G traffic-class or 4G QCI, for both upstream
and downstream can have a MBR of 5MB. They have also set low
values for GBR (Guaranteed-Bit-Rate) since they are unsure what their
peak subscriber rate will be. So below is what their simple COS policy
profile looks like:
[editunified-edgecos-caccos-policy-profiles]
root@GGSN-960#show
Masst_QoS{
pdp-qos-control{
maximum-bit-rate-uplink5120;
maximum-bit-rate-downlink5120;
guaranteed-bit-rate-uplink256;
guaranteed-bit-rate-downlink256;
}
}
Lets test our new QOS/COS settings by attaching the cos-policy-profile Masst_QoS we just created to a unified-edge local policy we will
call Masst_Policy_One. Unified-edge local policies are just objects that
allow you to tie different policies together to define one policy for the
Gateway or APN. In a bit we will add other policies under Masst_Policy_One to flesh it out, but for now it will only hold our simple Cos
policy:
[editunified-edgelocal-policiesMasst_Policy_One]
root@GGSN-960#show
cos-policy-profileMasst_QoS;
Now under the Masst
apn hierarchy, attach this local policy:
[editunified-edgegatewaysggsn-pgwMasstapn-servicesapnsmasst.com]
root@GGSN-960#show
local-policy-profileMasst_Policy_One;
It should be noted that we could have attached the profile to the

gateway if we wanted the same polices applied to every APN.
root@GGSN-960#setlocal-policy-profileMasst_Policy_One
At this point it should be explained that the default behavior for the
pdp-qos-control setting is to downgrade the requested MBR values if
they exceed the configured values under the pdp-qos-control. If the
requested MBR values are below this configured value, the MBG will
honor the requested value and leave it as it is. If no value is set for
MBR and GBR, then the system will honor the requested value, regardless of how high it is, as long as it is within the QoS 3GPP specifica-
59
60
tions. So be aware that when the pdp-qos-control is not configured on

the MBG you are leaving the bandwidth control in the hands of other
nodes in the packet core, like the HLR/HSS and SGSN/MME.
Looking at a GTPv1 example, the requested QoS parameters arriving
from the SGSN show the MBR uplink and downlink values as being
8640 kbps, but using the configuration that Mass Telecom wants to
apply, the MBG will downgrade the actual negotiated values to 5120
kbps as seen under the negotiated QoS parameters. The GBR value is
only 1kbps and since the upgrade flag was not set we honor the
requested value of 1 kbps.
root@GGSN-960>showunified-edgeggsn-pgwsubscribersextensive
IMSI:123456789463930IMEI:1122334455667805
Status:Visitor
UserLocationInfo:
MCC:NoneMNC:None
RATType:Unknown
PDNSession:
APNname:masst.com
DirectTunnel:DisabledSessionDuration:3
TEIDControlLocal:0xc002d30TEIDControlRemote:0x122
Bearer:
NSAPI/EBI:5ChargingID:0xc002d30
LocalTEID:0x340d5cRemoteTEID:0x121
TrafficClass:ConversationalARP:1
ForwardingClass:NoneLossPriority:None
ProfileID:0
The MBG does allow some advanced control over the pdp-qos-control
feature by allowing the default behavior to be modified. You can
change the default behavior to reject the Create PDP Context Requests
if the requested MBR or GBR value is higher than the value set on the
MBG. You can also allow the MBG to upgrade the requested MBR and
GBR values if they are lower than the configured value on the MBG.
Here are the options:
root@GGSN-960#setmaximum-bit-rate-uplink5120?
rejectRejectcallswithhigheruplinkmaximum-bit-rate
upgradeOverridemaximum-bit-rateuplinkvalue
Remember, for GTPv1 requests the MBR and GBR values can only be
updated if the Upgrade QoS Supported bit is sent by the SGSN in the
Common Flags IE.
MOBILE TIP Per 3GPP 29.060: The Upgrade QoS Supported bit field is relevant
for a Create PDP Context or Update PDP Context procedure and is
used by SGSN to indicate to GGSN whether QoS upgrade in Response
message functionality is supported.
The MBG also allows the administrator of the box to set QoS controls
based on the Traffic Class for 3G subscribers and QCI for 4G subscribers. Below is an example of Mass Telecom expanding on their current
setup by adding a specific setting for qci 5 and qci 9:
[editunified-edgecos-caccos-policy-profilesMASST-QoSpdp-qos-control]
root@GGSN-960#show
maximum-bit-rate-uplink5120;
maximum-bit-rate-downlink5120;
qci9{
maximum-bit-rate-uplink512reject;
maximum-bit-rate-downlink1024reject;
guaranteed-bit-rate-uplink256reject;
guaranteed-bit-rate-downlink256reject;
61
62
}
qci5{
maximum-bit-rate-uplink2560upgradereject;
maximum-bit-rate-downlink5120upgradereject;
}
Now it should be understood that the MBG simplifies the QOS setup
by mapping 3G traffic classes to 4G QCI values. How that mapping
occurs is as follows:
1. The Traffic Class Background will map to QCI 9.
2. The Traffic Class Interactive with the Traffic handling Priority set to
3 will equal QCI 8.
2 will equal QCI 7.
1 will equal QCI 6.
1 and the Signialing Indication value set will equal QCI 5.
6. The Traffic Class Streaming will map to QCI 4.
7. The Traffic Class Conversational with Transfer Delay lower than
150ms will map to QCI 3.
8. The Traffic Class Conversational with Transfer Delay greater than
or equal to 150ms will map to QCI 2.
9. The Traffic Class Conversational with Source Statistics Descriptor
of Speech will map to QCI 1.
Okay, admittedly, that was a simple QoS scenario. So lets dig a bit
deeper and look at a few more features to apply.
The CAC functionality in the MBG, if configured correctly, can help
ensure resources are available for services like VoIP, streaming video,
or whatever else is prioritized by the provider. CAC can look at system
resources availability and the priority of the bearer. Then, using these
facts, the CAC policy can downgrade data requests or even reject new
bearer requests.
With the number of subscribers it plans to sign up, Mass Telecom
expects to be successful enough that a wide-open policy may not be a
good idea. Remember, their maximum-bearers for the whole Gateway
are set to 2 million. If a decent portion of those subscribers has one
bearer active at the same time and their negotiated QoS settings are
5120 for maximum-bit-rate-uplink and maximum-bit-rate-downlink

per the cos-policy-profile they set MASST-QoS, well, then they are in
potential trouble. So lets help them out.
First, under the [unified-edge cos-cac] hierarchy, lets set a bandwidth-pool. The bandwidth pool will be attached to the same localpolicy already bound to the Masst apn, the one that has MASST-QOS
assigned to it. Since this is Mass Telecoms main APN that many of
their home users will use, they want to give it plenty of bandwidth, but
not so much that it potentially starves their other APNs. So put 100 GB
into this pool. Also, lets use the downgrade-gtp-v1-gbr-bearers
option, which means when the bandwidth threshold is reached, any
new create or modify PDP context requests arriving on the MBG are
downgraded to the Background traffic class. If this option is removed,
any new create or modify PDP context requests arriving on the MBG
are rejected when the threshold is reached:
gbr-bandwidth-pools{
BandWidth_Pool{
bandwidth104857600;
downgrade-gtp-v1-gbr-bearers;
}
}
Now lets add this new policy to the local policy so it takes effect on
our Masst.com APN.
root@GGSN-960#show
dl-bandwidth-poolBandWidth_Pool;
Next up, Mass Telecom wants to create a resource threshold profile for
system thresholds to determine which subscribers will actually gain
access to the MBG when resources are becoming scarce. If memory,
CPU, or the number of bearers in use is 80% of the system resources,
then only Create PDP Context Requests with an ARP (Allocation and
Retention Priority) value of 1 for GTPv1 and a priority level of 1 for
GTPv2 will be accepted. If the threshold for any of these resources is
60% then Create PDP Context requests for GTPv1 with an ARP value
of 2 or lower or a GTPv2 request with a priority level value of 6 or
lower will be accepted.
MOBILE NOTE
Allocation and Retention Priority is a value used by GGSNs to determine if a Create PDP Context request with a higher priority can take a
resource from an existing bearer with a lower priority, a reverse Robin
Hood if you will. Note that the Juniper GGSN does not do this,
exactly.
63
64
Okay, lets configure this under [unified-edge cos-cac resourcethreshold-profiles] and create a resource threshold profile called
Masst_threshold:
[editunified-edgecos-cacresource-threshold-profilesMasst_threshold]
root@GGSN-960#show
bearers-load{
low{
percentage60;
priority-level6;
}
high{
percentage80;
priority-level1;
}
}
memory{
low{
percentage60;
priority-level6;
}
high{
percentage80;
priority-level1;
}
}
cpu{
low{
percentage60;
priority-level6;
}
high{
percentage80;
priority-level1;
}
}
Overall the configuration is very simple and straightforward, as you

can see. You can set a high and low threshold, which maps to a priority-level.
To be clear, lets review how the GTPv2 priority level parameters map
to GTPv1 ARP parameters. This is done in the same way the MBG
simplifies the QOS setup by mapping 3G traffic classes to 4G QCI
values:
Priority level value 1 is ARP 1 in GTPv1
And heres an example to help you further understand how this works.
Look at the changes made to the bearer-load:
[editunified-edgecos-cacresource-threshold-profilesMasst_threshold]
root@GGSN-960#show
bearers-load{
low{
percentage60;
priority-level9;
}
high{
percentage80;
priority-level5;
}
}
Now, when the low threshold is reached, GTPv2 Create PDP Context
requests with a priority level of 9 or lower will be admitted by this
profile. Based on the GTPv2 priority level mapping to GTPv1 ARP, a
priority level of 9 does not map directly to any GTPv1 ARP settings.
But since GTPv1 ARP 2 maps to GTPv2s priority level 6, and 6 is
lower than the currently configured priority level 9, GTPv1 Create
PDP Context requests with an ARP value of 2 or 1 will be admitted.
Using the same logic, when the new high threshold for bearers-load is
reached, GTPv2 Create PDP Context requests with a priority level of 5
or lower will be admitted and GTPv1 Create PDP Context requests
with an ARP value of 1 will be admitted.
Time to add this profile to the local profile:
root@GGSN-960#show
resource-threshold-profileMasst_threshold;
Mass Telecom also wants to define the forwarding class and loss
priority for their bearers. Remember how the MBG maps 3G traffic
classes map to 4G QCI values before you begin, and then under
[unified-edge cos-cac classifier-profiles] create a profile called
CLASSIFIER_PROFILE_MBG. Lets take an example using the qci 1
for conversational, QCI 5 for interactive, and QCI 9 for background.
Since a bearer with the traffic class of interactive or the QCI of 5 is
considered a decent high priority by Mass Telecom, they want to set
the loss priority to be low, and the forwarding class to be expedited.
QCI 1, also known as conversational, normally very important for the
forwarding class, is set to VOICE and the loss priority is low. Last is
QCI 9, also known as background, which is the least important type of
traffic. The forwarding class is the lowly BE and loss priority is high.
[editunified-edgecos-cacclassifier-profiles]
root@GGSN-960#show
CLASSIFIER_PROFILE_MBG{
qos-class-identifier1forwarding-classVOICEloss-prioritylow;
65
66
qos-class-identifier5forwarding-classAF11loss-prioritylow;
qos-class-identifier9forwarding-classBEloss-priorityhigh;
}
The forwarding classes that can be chosen are the commonly defined
ones set in DiffServ (Differentiated Services), or mainly:
Best Effort: Typically best-effort traffic
Expedited Forwarding: Dedicated to low-loss, low-latency traffic
Assured Forwarding: Gives assurance of delivery under prescribed conditions
Network Control: Maintains backward compatibility with the IP
Precedence field
Okay, another profile to add to our local policy Masst_Policy_One:
root@GGSN-960#show
resource-threshold-profileMasst_threshold;
classifier-profileCLASSIFIER_PROFILE_MBG;
So the Masst.com apn is not wide open anymore. The system now has
the ability to put on some brakes.
Mass Telecom also wants to enable preemption, which is disabled by
default. Preemption in 3G (GTPv1) allows the MBG using the ARP
value to help decide if it should accept the Create PDP Context request,
or if it should Modify it. In 4G (GTPv2) the PVI and PCI values are
used.
Lets briefly explore preemption and how the MBG works with it. For
example, lets assume that an APN is fully loaded and there is no room
for any new subscribers based on the maximum-bearers value being
exceeded, or maybe the mobile enabled MS-DPCs on the system are all
100% full. When a new Create PDP Context request comes in, there
may be no suitable candidates to be deleted in the bearer pool. If that is
the case, then, the candidate pool is checked to see if there is any about
to be deleted candidate bearers that can be used for this bearer.
And to prove the point, lets assume an end user just roamed out of
Mass Telecom coverage (maybe veering off into New Hampshire) so
there is now a bearer marked for deletion. A new 3G subscriber in
Boston just turned their iPhone on, and the Create PDP Context
Request has an ARP value of 3. Now, just slightly after that request
comes in but before it can be processed, and given the resource from
the bearer pool, another Create PDP Context Request from another
mobile user comes in with an ARP of 2. With preemption enabled, the

candidate who is about to be deleted will yield their bandwidth to the
new create bearer request, the one with the better ARP value of 2.
Since there are no free candidates to associate with the ARP 3 bearer,
the create request (for ARP 3) would be failed.
Preemption support is only at the GW level, meaning the preemption
candidates that will be maintained for preemption will not be per
APN, but will be for the whole gateway. Lets enable this feature now:
root@GGSN-960#setpreemptionenable
There is another useful command that the MBG has, this one will show
you the qos statistics:
root@GGSN-960>showunified-edgeggsn-pgwqosstatistics
Gateway:MASST
Controlplanestatistics:
Sessionestablishmentattempts:100005
Successfulsessionestablishments:100005
MS/peerinitiatedsessiondeactivations:100002
SuccessfulMS/peerinitiateddeactivations:100002
Gatewayinitiatedsessiondeactivations:0
Successfulgatewayinitiateddeactivations:0
Dataplaneglobalstatistics:
Sourceaddressviolationpackets:0
Sourceaddressviolationbytes:0
Totalpacketsrcvdwithnon-existentTEIDs:0
DataplaneGTPstatistics(Gn/S5/S8):
Inputpackets:300438
Inputbytes:423691560
Outputpackets:534
Outputbytes:29904
Discardedpackets:0
DataplaneGTPstatistics(Gi):
Inputpackets:534
Inputbytes:29904
Outputpackets:300438
Outputbytes:423691560
Discardedpackets:0
To really get good information on the type of subscriber settings based

on QOS you can be more granular with the output of the command:
root@GGSN-960>showunified-edgeggsn-pgwqosstatistics?
Possible completions:
apnAPNname
arpGTPv2ARPValue(1..15)
gatewayShowsubscriberforagateway
gtpv1-arpGTPv1ARPValue(1..3)
67
68
qciShowQCIstatisicsinformation(1..9)
traffic-classShowstatisticsforatraffic-classlevel
traffic-handling-priorityTraffichandlingpriority(1..3)
|Pipethroughacommand
root@GGSN-960>showunified-edgeggsn-pgwqosstatisticsarp?
<arp>GTPv2ARPValue(1..15)
root@GGSN-960>showunified-edgeggsn-pgwqosstatisticsarp2
Gateway:MASST
Gn/S5signalingmsgsrcvd:0
Gn/S5signalingmsgssent:11
Gn/S5signalingmsgsdropped:0
Gn/S5signalingbytesrcvd:0
Gn/S5signalingbytessent:0
TotalGTPtunnelscreated:0
SessionEstablishmentsFailed(byGTPcause):
Others0
Serviceunavailable:0
Systemfailure:0
Noresources:0
Noaddress:0
Servicedenied:0
AuthenticationFail:0
APNaccessdenied:0
Inputpackets:630
Inputbytes:0
Outputpackets:0
Outputbytes:0
Discardedpackets:0
Inputpackets:0
Inputbytes:0
Outputpackets:0
Outputbytes:630
Discardedpackets:51062
root@GGSN-960>showunified-edgeggsn-pgwqosstatisticstraffic-handlingpriority2traffic-classinteractive
Gateway:Masst
Gn/S5signalingmsgsrcvd:0
Gn/S5signalingmsgssent:0
Gn/S5signalingmsgsdropped:0
Gn/S5signalingbytesrcvd:0
Gn/S5signalingbytessent:0
TotalGTPtunnelscreated:0
SessionEstablishmentsFailed(byGTPcause):
Others0
Serviceunavailable:0
Systemfailure:0
Noresources:0
Noaddress:0
Servicedenied:0
AuthenticationFail:0
APNaccessdenied:0
Inputpackets:29026
Inputbytes:1546473
Outputpackets:55444
Inputpackets:55444
Inputbytes:75631200
Outputpackets:29026
Outputbytes:1546473
Discardedpackets:0
Summary
Lets take a quick inventory of what has been configured so far on the
MBG for Mass Telecom:
The APN (masst.com) handles all the Mass Telecom home
subscribers and this APN uses a pool that assigns IP addresses
from the 15.0.0.1/14 range.
There are two virtual APNs for Nscotia roamers (internet123
and Canada) that call a service-selection profile. If the IMSI being
used starts with 302200, they are mapped to another APN,
NScotia, which uses a pool with a range of 15.4.0.1/16.
There is another APN, masst.bb, which some Blackberry devices
will use that authenticates to RADIUS using the unique IMSI as
the user-name for potential unique session settings.
All APNs that are not virtual, meaning masst.com, masst.bb, and
NScotia, map to the routing instance GI_VR.
69
70
Masst.com and masst.bb use RADIUS for authentication and

accounting of the session. They also send charging records to the
RADIUS server.
The MBG has been set up to send CDR records to a CGW for the
NScotia APN.
COS and CAC settings have been applied to the masst.com APN.
The NScotia and masst.bb APN are still wide open.
Now, lets really show off MBG running on our MX in Chapter 4.
Chapter 4
Advanced Configuration Techniques
Service Selection Profile with Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Additional Address Assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
GTP Path Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
72
The advanced techniques in Chapter 4 include use-cases, deeper dives

into looking at stats, and analyzing some testing results. Its a nice
quick tour through the MBG, and when done, you should feel very
comfortable driving the MBG around. If youve made it this far, youll
be a master of this solution in no time. Youre almost there.
Service Selection Profile with Redirection

Mass Telecom is interested in analyzing and deciding whether to
off-load subscribers to a Video Optimization solution versus processing the Create PDP Context/Create Session request locally. In addition,
the account wants to send all the UEs, excepting iPhones, to the Video
Optimization solution. So lets use the Service-Selection-Profile feature
to steer traffic to the receiving IP address (10.3.219.60 ) of the Video
Optimization solution by keying off of a variable that distinguishes
other mobile devices from the iPhones.
The Junos options to key off of are:
charging-characteristicsMatchchargingcharacteristics(1..65535)
imeiMatchIMEI
imsiMatchIMSI
maximum-bearersMaximumbearersinthegateway(1..10000000)
msisdnMatchMSISDN
pdn-type
peerIPaddressofthepeercreatingthesession
peer-routing-instanceRoutinginstanceofthepeercreatingthesession
Lets begin by looking at how to leverage these options. If the SGSN/

MME handling iPhones uses a different Gn/S5/S8 source IP address
than the other UEs, then from the MBGs point of view, you could use
the Routing-Instance or peer. But that option will not work since the
Gn/S5/S8 is not selected by the RAN or HLR/HSS, based on the UE
type.
The IMSI could work if the iPhones have a different country code or
network code, but most likely they would not in any setup. If the IMSI
did have any distinguishing numbers for the iPhone you could set up
the service-selection-profile like this:
service-selection-profiles{
profileSelection_Profile_1{
termTerm1{
from{
imsi31011178132;
}
then{
redirect-peer10.3.219.60;
}
}
}
}
Chapter 4: Advanced Configuration Techniques
Here, the example for the country code is 310, the Mobile Network
code is 111, and the MSIN starts with 78132.
Now if their BlackBerrys also had IMSIs that are 31011178132*, then
this would not work, so the SIM cards would need to be specially
pressed for the unit type. And SIM cards are not done like this; you
cant stop a subscriber from moving SIM cards from one mobile UE to
another. You've reached another dead end.
A more valid approach may be to see if you can use RADIUS to
provision the subscribers service, in this case returning the RADIUS
Attribute Jnpr-Redir-GW-Addr. This would redirect the subscribers to
the Video Optimization server. If the User-Name was uniquely hardcoded on the iPhones, or other mobile devices, this would be easy. For
example, if all User-Name attributes that came from iPhones were
iphone, its easy. If the mobiles all have unique users, this would work,
too.
Now lets consider that Mass Telecom and NScotia may want to send
all of the NScotia roaming subscribers back to a GGSN in Nscotias
mobile packet core and Mass Telecom has to redirect from the GGSN,
not the SGSN, for some reason. In the following example, if any IMSI
comes from 302200, its sent back to a NScotia GGSN, or whatever
they want the target to be at the NScotia site. In this example, that
would be 20.20.20.22:
profileSelection_Profile_1{
termTerm1{
from{
imsi302200;
}
then{
}
}
}
}
Mass Telecom could also create a service selection profile that can be
applied to an APN that helps share the load. So if this chassis has
limited MS-DPCs, and you feel Mass Telecom may reach their limits,
you can have the MBG redirect new PDP Create Requests to another
GGSN, for example. Share the load and let the other GGSN establish
and manage the session. Just make sure that the other GGSN is not
configured to send requests back to this one, or you could run into a
scenario where the two GGSNs are passing the same requests back and
forth until the from definition clears. Heres this redirect example:
73
74
profileMasst_Rollover{
termterm1{
from{
}
then{
}
}
}
}
Additional Address Assignment

Now Mass Telecom needs more flexibility for the Masst APN than just
having RADIUS assign the IP addresses. They want the UEs to be able
to come in with a statically assigned address that will be sent to the
MBG in the Create PDP Session Request. For this functionality, add
allow-static-ip-address to the configuration.
To do this, go under unified-edge
> gateways > ggsn-pgw > Masst >

apn-services > apns > masst.com and add:
address-assignment{
inet-pool{
poolroamer;
}
allow-static-ip-address;
}
Lets say Mass Telecom also wants to use a DHCP server to assign IP
addresses to the masst.bb APN. They just need to add a dhcp proxy
section to the Junos configuration and add that to the APN.
To do this, go under the [edit system services dhcp-proxy-client
dhcpv4-profiles masst_dhcp_profile] hierarchy:
lease-time1000;
retransmission-interval4;
dhcp-server-selection-algorithmround-robin;
bind-interfacexe-3/0/2;
servers10.3.2.2{
priority1;
}
Then under [edit unified-edge gateways ggsn-pgw Masst apn-services apns masst.bb] hierarchy:
address-assignment{
dhcp-proxy-client;
dhcpv4-proxy-client-profile{
profile-namemasst_dhcp_profile;
}
}
There you go. DHCP is working for your APN now.
GTP Path Management

GTP Path Management uses GTP echo messages to ensure that the
nodes involved in the GTP tunnel setup are active. And if your MBG is
a GGSN, you care about the SGSN being active. If your MBG happens
to be a PGW, you care about the SGW and MME.
If path management is enabled, the MBG will send echo requests at a
predetermined time to all nodes in its peer list. If the MBG does not get
a response back from the peer after a predetermined time, the MBG
will consider the peer to be down and unavailable.
echo-n3-requests is the number of times that the MBG attempts
to send an echo-request message before it marks the peer as
down.
echo-t3-response is the number of seconds that the MBG waits
for an echo response from a peer gateway before sending the next
echo-request.
echo-interval is the number of seconds the MBG waits before
sending the next echo request message after a response to the
previous echo request is received.
n3-requests sets the maximum number of times that the MBG
sends a GTP request message to create, update, or delete a PDP
context.
t3-response will set the number of seconds that the MBG waits
for a create/update/delete response from a peer before retransmitting the message.
Path management simply enables the MBG to send echo requests to
peers, or disables the MBG from sending echo requests to peers. When
disabled, the MBG still responds to echo requests sent from the peers
themselves.
So Mass Telecom wants the Gp and S8 interfaces to use one set of
values, and the Gn and S5 interfaces to use another. The reason is that
the Gn and S5 interfaces are for nodes that exist in their homePLMN.
It is their equipment and their network, so they trust that packets will
be delivered timely. They have less faith with packet delivery to a
visitingPLMN like NScotias network, so they have created values
there that match traffic results from Mass Telecoms homePLMN to
NScotias visitingPLMN.
Mass Telecom has set the following default. They will affect behavior
on the Gp and S8 interfaces. The Gn and S5 have their own sections
defined by Masst, and those values will override the defaults.
75
76
[editunified-edgegatewaysggsn-pgwMasstgtp]
root@GGSN-960#show
n3-requests5;
t3-response6;
echo-interval120;
echo-n3-requests5;
echo-t3-response6;
gn{
n3-requests5;
t3-response5;
echo-n3-requests3;
echo-t3-response5;
}
S5{
n3-requests5;
t3-response5;
echo-n3-requests3;
echo-t3-response5;
}
If Mass Telecom ever needs to, they can define unique settings for the
S8 and Gp interfaces, too. They can even leverage the MBG to create
different settings for Control versus Data. So, if the SGSN sends all
GTPu traffic through a firewall that may potentially cause packet loss,
they can define more granular settings that increase just GTP data
packets values over GTP control packets. For example:
gn{
n3-requests5;
t3-response5;
control{
echo-n3-requests3;
echo-t3-response5;
}
data{
echo-n3-requests5;
echo-t3-response10;
}
}
Last, but not least, Mass Telecom wants to set the traffic class for
control traffic since they can be sending control traffic to a GGSN in
NScotias network.
For this, go under [unified-edge
add the following:
gateways ggsn-pgw Masst gtp] and
control{
forwarding-classassured-forwarding;
dscp-code-point10;
}
The traffic class can be set to be more granular if you wish, such as
under the [unified-edge gateways ggsn-pgw Masst gtp gn control]
section.
So, what are the default path management settings if Mass Telecom
does not touch this GTP section at all:
echo-n3-requestsThedefaultis8times.
echo-t3-responseThedefaultis15seconds.
echo-intervalThedefaultis60seconds.
n3-requestsThedefaultis3times.
t3-responseThedefaultis5seconds.
path-management
IsenabledbydefaultforGTPcontrolpacketsbutdisabledforGTPdatapackets.
There is just one more little item to cover that might be helpful in your
production network. You see, Mass Telecom has these old SGSNs.
They get overloaded easily and they tend to drop control traffic, which
is a very bad thing. So Mass Telecom wants to change the response/
requests path management settings just for these devices.
Easy enough with the power of the MBG. Just setup a peer-group
under [unified-edge gateways ggsn-pgw Masst gtp] like this:
peer-groupOld_Sgsns{
routing-instance1;
n3-requests5;
t3-response10;
echo-n3-requests5;
echo-t3-response10;
peer{
201.100.1.87/32;
201.100.1.59/32;
201.100.1.201/32;
}
}
If you need to check the status of the GSN peers such as the SGSN,
SGW, or Node bs, run this command:
root@GGSN-960>showunified-edgeggsn-pgwgtppeerdetail
Gateway:Masst
PeerDetail:
--------------RemoteIPAddress:201.100.1.2
LocalIPAddress:201.100.1.6
RoutingInstance:6
InterfaceType:Gn
GTPVersion:1
RCMRegistrationDone:yes
77
78
RestartCounterValid:yes
RestartCounterValue:1
SentRestartCounterValue:7
ControlPathN3Request:3
ControlPathT3Timer:5
ControlPathEchoN3Request:8
ControlPathEchoT3Timer:15
ControlPathEchoInterval:60
ControlPathManagementEnabled:no
ControlPathState:not-tracked
DataPathEchoN3Request:8
DataPathEchoT3Timer:15
DataPathEchoInterval:60
DataPathManagementEnabled:no
DataPathState:not-tracked
GTP-CusingShortSequenceNumber:no
DownlinkdatanotifdelayInterval:0
CSIDSupported:no
Youcanalsogetoverall GTP statistics:

root@GGSN-960>showunified-edgeggsn-pgwgtpstatistics?
detailGTPCauseStatsIncluded
fpc-slotFPCslotnumber
gatewayShowstatisticsforagateway
gtp-allGTPallversionstatistics
gtp-error-indGTPErrorIndicationstatistics
gtp-v0GTPversion0statistics
pic-slotPICslotnumber
root@GGSN-960>showunified-edgeggsn-pgwgtpstatisticsgtp-v1
Gateway:Masst
GlobalPacketStatistics
ReceivedPacketsDropped:0
PacketAllocationFail:0
PacketSendFail:0
IPVersionErrorReceived:0
IPProtocolErrorReceived:0
GTPPortErrorReceived:0
GTPUnknownVersionReceived:0
PacketLengthErrorReceived:0
UnknownMessagesReceived:0
GTPVersion1Statistics:
------------------------ProtocolError:0
UnsupportedMessagesReceived:0
T3ResponseTimerExpires:0
MessageTypeReceivedTransmitted
----------------------------------------------------------------------------Totalnumberofmessages210314210314
Totalnumberofbytes100587259509386
Redirectmessages00
EchoRequest00
EchoResponse00
VersionNotSupported00
CreatePDPContextRequest1101780
CreatePDPContextResponse0110178
UpdatePDPContextRequest00
UpdatePDPContextResponse00
DeletePDPContextRequest1001360
DeletePDPContextResponse0100136
Summary
There are more advanced techniques of course, and many of them are
available at the resources outlined on the last page of this book.
You should now have set up, deployed, configured, and committed
your MBG on your MX Series. Wow! And Mass Telecom is pretty
happy in their imaginary world.
Before you go, however, take a look at the final chapters. The first is
based on general system maintenance focused on the mobile side of the
MX and the second is based on troubleshooting the box as you take
your lab work onto the shop floor.
79
80
Chapter 5
System Maintenance
Maintenance Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Clearing Subscribers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
82
Maintenance Mode is a feature of the MBG that is required when the

administrator of the box needs to make certain changes. What Maintenance Mode does is take certain functions offline, so new requests are
not accepted while changes are made. The idea is to get the system into
a place where no service-affecting changes are made while subscribers
are active on the box. So when in maintenance mode the system will
not take on new subscribers for the object in question. Once all
subscribers have left the system the changes can be made and then you
can bring the MBG out of maintenance mode and it will accept
requests again with the new changes now in effect. Lets dig in and see
it in action.
Maintenance Mode
The following changes can only be made while in maintenance mode:
Delete or modify the addresses of certain GPRS tunneling
protocol (GTP) interfaces
Delete or change the type of an access point name (APN)
Change mobile interface configuration parameters
Change a mobile interface for an APN
Delete a charging profile
Delete or modify a charging data record (CDR) profile or CDR
type
Delete or modify a transport profile
Delete or modify a trigger profile
Delete a mobile pool or modify its parameters
Lets start by putting the whole gateway into maintenance mode:
[edit unified-edge gateways ggsn-pgw Masst]
root@GGSN-960# set service-mode maintenance
root@GGSN-960# commit
Run this command now to see the service-mode status for the Masst
gateway:
root@GGSN-960# run show unified-edge ggsn-pgw service-mode
Maintenance Mode
MM Active Phase - System is ready to accept configuration changes for all attributes
of this object and its sub-hierarchies.
MM In/Out Phase - System is ready to accept configuration changes only for nonmaintenance mode attributes of this object and its sub-hierarchies.
Gateway Name
Masst
Service Mode
Maintenance - In Phase
Chapter 5: System Maintenance
Note the status is In Phase. That means the system is not ready to be in
Maintenance Mode yet.
The first thing to check is to see if any subscribers are still active:
root@GGSN-960#runshowunified-edgeggsn-pgwstatus
Gateway:Masst
ActiveSubscribers:1
ActiveSessions:1
ActiveBearers:1
CPULoad(%):0
MemoryLoad(%):29
You can see there is one subscriber left and you do not have time to
wait for them to stop what they are doing. This whole system is offline
and the web browsing habits of one subscriber cannot get in our way!
So lets clear them from the system:
root@GGSN-960# run clear unified-edge ggsn-pgw subscribers gateway Masst
And lets check to see if the service-mode is now active:

Maintenance Mode
MM In/Out Phase - System is ready to accept configuration changes only for nonmaintenance mode attributes of this object and its sub-hierarchies.
Gateway Name
Masst
Service Mode
Maintenance - Active Phase
Okay, we are now good to go. Make your changes, change GTP
ip-addresses, change IP pools. Delete APNs. Whatever you need to do.
Commit those changes and when you are done with that commit then
you can delete the service-mode parameter from the Gateway and
commit once more:
root@GGSN-960# delete service-mode
root@GGSN-960# commit
commit complete
Now those subscribers can come back and get serviced by this MBG.
Run the show unified-edge ggsn-pgw service-mode command one
more time to verify the Service Mode is operational:
Maintenance Mode
MM In/Out Phase - System is ready to accept configuration changes only for non-
83
84
maintenance mode attributes of this object and its sub-hierarchies.

GatewayNameServiceMode
MasstOperational
The example used here locks down the whole gateway and takes it out
of service. The truth is, when performing maintenance on the MBG,
the operator may not need to take such extreme measures as locking a
whole gateway. For example, they may only need to lock down a given
APN or a Charging Profile.
For each feature that needs to be put into maintenance mode you can
drill down to the section where that feature is enabled, and put only
that feature into maintenance mode:
[edit unified-edge gateways ggsn-pgw Masst apn-services apns masst.com]
[edit unified-edge gateways ggsn-pgw Masst charging charging-profiles CP1]
You can also manually clear the subscribers that use just these features,
thus leaving the rest of the MBG to continue functioning in service as
normal while taking just this one feature and its subscribers offline:
root@GGSN-960# run clear unified-edge ggsn-pgw subscribers apn Masst
root@GGSN-960# run clear unified-edge ggsn-pgw subscribers charging charging-profile
CP1
Clearing Subscribers
There will also be times when subscriber sessions on the box are
considered hung. If session-timeout and/or idle-timeout are not set for
all the APNs or Path-Management is disabled you may see this occur
more frequently. The reason for this is that if the GTPc Delete PDP
Context Request or Delete Session request never makes it to the MBG
when the UE disconnects, the MBG will have no idea the session
should go away.
Check the configuration to see if you have session-timeout and idletimeout set, and if path management is enabled or not. Remember, you
do not need these features to be enabled on the system, but understanding whether or not they are enabled will give you insight into
whether or not your MBG will be susceptible to potential hung
sessions.
[unified-edge gateways ggsn-pgw Masst apn-services apns masst.com]
inactive session-timeout 24;
inactive idle-timeout 60;
Chapter 5: System Maintenance
[unified-edge gateways ggsn-pgw Masst gtp]

path-management disable
gn {
path-management disable;
}
s5 {
}
s8 {
}
When there are subscribers on the MBG that dont belong there, you
can clear them with the clear unified-edge ggsn-pgw subscribers
command. A system administrator can also clear a subscriber that they
know is active but needs to be dropped. Clearing a subscriber does
cause the MBG to send a GTPc Delete PDP Context/Delete Session
Request to the GTP peer, so if the peer is reachable on the network it
will process the packet and drop the subscriber on its side. Normally,
the MBGs subscribers are provisioned and managed by RADIUS or a
PCRF server. These types of solutions can create Disconnect Messages
that are sent to the MBG, which causes the MBG to perform the same
task as running the clear unified-edge ggsn-pgw subscribers
command.
You can disconnect subscriber sessions individually using the clear
unified-edge ggsn-pgw subscribers command, or, if a GTP peer like a
SGSN goes down, you can clear all subscribers that belonged to it:
root@GGSN-960#runclearunified-edgeggsn-pgwsubscribers?
apnClearallthesubscribersinanAPN
chargingClearallsubscribersforachargingattribute
gatewayClearallthesubscriberforthegateway
imsiClearasubscriberwithaspecificimsi
msisdnClearasubscriberwithaspecificmsisdn
peerClearallthesubscribersofaspecificpeer
routing-instanceRoutinginstanceassociatedwiththesubscriber
v4-addrClearasubscriberwithmatchingIPv4address
v6-addrClearasubscriberwithmatchingIPv6address
You can even clear every single subscriber that is connected to your
gateway.
root@GGSN-960# run clear unified-edge ggsn-pgw subscribers gateway MASST
85
86
Chapter 6
Troubleshooting
show unified-edge ggsn-pgw status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
show unified-edge ggsn-pgw gtp peer detail. . . . . . . . . . . . . . . . . . . . . . . . . 90
show unified-edge ggsn-pgw statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
show unified-edge ggsn-pgw charging path status . . . . . . . . . . . . . . . . . . . . 91
show unified-edge ggsn-pgw subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
show unified-edge ggsn-pgw ip-reassembly statistics. . . . . . . . . . . . . . . . 95
clearing statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Logs! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Error: Subscriber Rejected, No Resources Available . . . . . . . . . . . . . . . . . . . 99
Error: Encoding Cause Authentication Failure . . . . . . . . . . . . . . . . . . . . . . . . . 105
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
88
The following troubleshooting techniques are meant to help you get

out of the lab and onto the shop floor, but get used to examining them
as they are worth their weight in GGSN gold.
show unified-edge ggsn-pgw status

First lets look at the show unified-edge ggsn-pgw status output. If
there is any command to run just for the sake of looking at the state of
the box, this is it. You can have someone like Mass Telecom run this to
see how many mobile subscribers are on the MX, how many SPICs are
up and running, the distribution of subscribers across the SPICS, and
what the load is for each SPIC. It is very basic but useful:
[root@GGSN-960#runshowunified-edgeggsn-pgwstatusdetail
Mobilegatewaystatusoffpcslot:2picslot:0
State:Backup
ActiveSubscribers:50
ActiveSessions:50
ActiveBearers:50
CPULoad(%):0
MemoryLoad(%):28
State:Active
ActiveSessions:50
ActiveBearers:50
CPULoad(%):0
MemoryLoad(%):28
State:Active
ActiveSessions:50
ActiveBearers:50
CPULoad(%):0
MemoryLoad(%):28
State:Backup
ActiveSessions:50
ActiveBearers:50
CPULoad(%):0
MemoryLoad(%):28
You can see that there are 100 subscribers on the MX. They have been
evenly load-balanced across two MS-DPC pics and they have been
backed up against two more MS-DPC pics
Lets take a quick look at the configuration and see how these results
came to be. First, under the interfaces hierarchy:
Chapter 6: Troubleshooting
ams0 {
load-balancing-options {
member-interface mams-2/0/0;
high-availability-options {
many-to-one {
preferred-backup mams-2/0/0;
}
}
}
}
ams1 {
load-balancing-options {
high-availability-options {
many-to-one {
preferred-backup mams-4/1/0;
}
}
}
}
You can see that Mass Telecom has two Aggregated Multiservice
(AMS) Interfaces configured, the MS-DPC PIC 2/0/0 and 4/0/0 as one
AMS, and MS-DPC PIC 2/1/0 and 4/1/0 as the second AMS. Both
2/0/0 and 4/1/0 are backups.
The two Aggregated Multiservice interfaces are set under the [unified-edge gateways ggsn-pgw Masst system] hierarchy:
system {
pfes {
interface apfe0;
}
session-pics {
interface ams0;
interface ams1;
}
}
The show unified-edge ggsn-pgw system interfaces gateway Masst

command will show the different mobile interfaces, meaning the SPICs
and APFEs. You can verify if the interface is in an operating state and if
it is a primary or secondary.
root@GGSN-960>showunified-edgeggsn-pgwsysteminterfacesgatewayMasst
Gateway:Masst
InterfacesMembersOperationalRedundancy
StateRole
89
90
apfe0pfe-0/0/0ActivePrimary
Mass Telecom may have other MS-DPCs in this MX, but as far as their
MBG configuration is concerned, they have just the two MS-DPCs and
the four PICs between them in use for servicing mobile subscribers. As
for the MPCEs, they have three in play, each having four PFEs. One of
the MPCEs has been configured as a secondary to the other two
MPCEs.
show unified-edge ggsn-pgw gtp peer detail

Here is another command that shows the current status with the GSN
peers such as the SGSN, eNodeB, or SGW. The show unified-edge
ggsn-pgw gtp peer detail command is very useful!
PeerDetail:
--------------RemoteIPAddress:155.100.1.11
LocalIPAddress:201.100.1.6
RoutingInstance:6
InterfaceType:Gn
GTPVersion:1
RCMRegistrationDone:yes
RestartCounterValid:yes
RestartCounterValue:1
SentRestartCounterValue:3
ControlPathN3Request:3
ControlPathT3Timer:5
ControlPathEchoN3Request:8
ControlPathEchoT3Timer:15
ControlPathEchoInterval:60
ControlPathManagementEnabled:no
ControlPathState:not-tracked
DataPathEchoN3Request:8
DataPathEchoT3Timer:15
DataPathEchoInterval:60
DataPathManagementEnabled:no
DataPathState:not-tracked
GTP-CusingShortSequenceNumber:no
DownlinkdatanotifdelayInterval:0
CSIDSupported:no
show unified-edge ggsn-pgw statistics

The show unified-edge ggsn-pgwstatistics is a useful command that
shows you how many sessions have been established, how many failed,
and how much traffic has been sent.along with the data packets that
have been discarded.
root@GGSN-960#runshowunified-edgeggsn-pgwstatistics
Inputpackets:587322
Inputbytes:75177216
Outputpackets:31968
Outputbytes:4091904
Discardedpackets:0
Inputpackets:31968
Inputbytes:4091904
Outputpackets:587322
As you can see here, 30 GTP-C sessions have been attempted and only
five have succeeded. Plus the Gi interface has discarded some packets
so there is a problem that needs to be examined. You can also see that
no subscribers have deactivated yet.
show unified-edge ggsn-pgw charging path status

Troubleshooting the Charging Gateway is something you may have to
do several times, if only because its connected to revenue. Run show
unified-edge ggsn-pgw charging path status to make sure the status
is connected, like this:
Charging Path Status
Peer-Addr
Peer-Name
Local-Address
Status
10.3.219.32
ChargingOne
10.3.219.72
Connected
Show unified-edge ggsn-pgw charging path statistics
Now, if you run show unified-edge

tics you'll get the nitty gritty:
Echo
Enabled
ggsn-pgw charging path statis-
91
92
Charging Path Statistics

CGF Address
: 10.3.219.32
Echo Requests
Rx: 0
Echo Responses
Rx: 11
Node-Alive Requests
Rx: 1
Version Not Supported Rx: 0
Echo Requests timed out : 8
Down Detection Interval : 10
Destination Port
: 3386
Path Manager FPC Slot
: 4
T3 Response Time Interval : 5
Source Interface Valid
: Yes
N3 Requests
: 3
GTPP Version
: V0
CGF Server Name

: ChargingOne
Echo Responses
Tx: 0
Echo Requests
Tx: 19
Node-Alive Responses
Tx: 1
Version Not Supported Tx: 0
Echo Interval
: 60
Reconnect Time Interval : 60
Pending Queue Size
: 0
Path Manager PIC Slot
: 0
Path Manager Port
: 30275
GTPP Header Type
: long
Local Address
: 10.3.219.72
Transport Protocol
: UDP
A few things to notice that are bolded: the NodeAlive request response
is a good indication that things are working between the two nodes.
There are a few Echo Requests that timed out. You can see the MBG is
using GTPPv0 over UDP, and you can see that the Path Manager Port
is 30275, which means Echo Requests and responses should use that as
the source port (Data Record Transfer Requests will use port 30276 as
the source port).
show unified-edge ggsn-pgw subscribers

The show unified-edge ggsn subscribers command is a useful one to
see the state of an active subscriber on the MBG. Since the system can
be managing millions of subscribers based on the MS-DPC and MPCE
card loadout we also have a slew of options to allow you to see what
types of subscribers are on the box and to narrow down which subscriber types you may want to view out of that potential 8 million.
root@GGSN-960# run show unified-edge ggsn-pgw subscribers ?
apnShowsubscribersforanAPN
briefDisplaybriefoutput(default)
chargingShowsubscribersforchargingattribute
detailDisplaydetailedoutput
extensiveDisplayextensiveoutput
gatewayShowsubscribersforagateway
gtp-versionGTPCversionnumber(0..2)
gtpv1-arpShowsubscribersforspecificGTPv1ARP(1..3)
gtpv2-priority-levelShowsubscribersforspecificGTPv2prioritylevel
imsiShowsubscribersforspecificimsi
msisdnShowsubscribersforspecificmsisdn
pdn-typeShowsubscribersbyPDN-Type
peerShowsubscribersforspecificpeer
qciShowsubscribersforspecificqci(1..9)
roaming-statusShowsubscribersbyroaming-status
routing-instanceNameofroutinginstance
servicesShowsubscribersbyservices
session-stateShowsubscribersbystate
traffic-classShowsubscribersattrafficclasslevel
v4-addrShowsubscribersformatchingaddress
v6-addrShowsubscribersformatchingaddress
Here is an example displaying just the count, or number of GTPv1

suscribers, who have a PDP Context activated with an ARP value of 1:
root@GGSN-960# run show unified-edge ggsn-pgw subscribers gtpv1-arp 1 | count
Count: 15011 lines
The show unified-edge ggsn-pgw subscribers command can show

quite a bit about about a subscribers session when you use the detail
or extensive option (extensive shows you the most information).
root@GGSN-960#runshowunified-edgeggsn
pgwsubscribersimsi50502410174467extensive
IMSI:50502410174467IMEI:None
MSISDN:17962533101TimeZone:GMT(DST):None
RATType:UnknownStatus:Roamer
MCC:NoneMNC:None
PDNSession:
APNname:masst.com
GTPVersion:1SessionDuration:22:26:36
TEIDControlLocal:0xc00f8c5TEIDControlRemote:0xcee1
ServicePIC:None/None(FPC/PIC)
SessionState:Established
DirectTunnel:DisabledServingnetwork:MCC:NoneMNC:None
Bearer:
Bearer:
NSAPI/EBI:5ChargingID:0xc007cc5
LocalTEID:0x3422e5RemoteTEID:0xd2c8
ForwardingClass:NoneLossPriority:None
93
94
GBRDownlink:1kbpsGBRDownlink:1kbps
Charginginformation:ProfileID:0
State:ReadyPreviousState:Accounting
Details:Accountingenabled
Offlinecharginginformation:Disabled
ActionID:0x1007cc5Triggerprofile:0
Details:Bearertrigger
Collectiontime:TueApr1022:00:122012
Uplinkpackets:0Downlinkpackets:0
Uplinkbytes:0Downlinkbytes:0
Now, lets use a show command to help explain a question. Mass

Telecom asks Why are all the subscribers being sent to the same
APFE(Anchor PFE)? They feel there are multiple primary APFEs in
the system. We will answer this and then use the show unified-edge
ggsn subscribers command to show you the truth.
So, if you have a great memory, you will remember from earlier in the
book the first choice of APFE is given by the SPIC to the PFE that is the
Egress PFE to reach the peer of the session. In this example lets say the
peer is a SGSN. Remember the APFE is chosen like this to minimize the
number the of times the fabric has to be traversed.
So we have 19 subscribers active on the MBG, and they all come from
the same SGSN in our example. The SGSN is connected to an interface on FPC 1.
[edit chassis]
root@GGSN-960# run show unified-edge ggsn-pgw subscribers extensive | match "anchor"
Session PIC: 2 /0 (FPC/PIC)
Anchor PFE: 1 /0 (FPC/PIC)
Session
Session
Session
Session
Session
PIC:
PIC:
PIC:
PIC:
PIC:
2
4
4
4
4
/0
/0
/0
/0
/0
(FPC/PIC)
(FPC/PIC)
(FPC/PIC)
(FPC/PIC)
(FPC/PIC)
Anchor
Anchor
Anchor
Anchor
Anchor
PFE:
PFE:
PFE:
PFE:
PFE:
1
1
1
1
1
/0
/0
/0
/0
/0
(FPC/PIC)
(FPC/PIC)
(FPC/PIC)
(FPC/PIC)
(FPC/PIC)
Since each PFE can manage 500,000 subscribers before its resources
are exhausted, you would only see sessions start to be distributed to
other APFEs in the system if you brought up more than 500,000
sessions from the same SGSN.
show unified-edge ggsn-pgw ip-reassembly statistics

No one wants fragmented GTP packets, but it happens. Now we need
to reassemble GTP packets so the system knows how to steer the
packet internally. For fragmented GTP packets, the MBG cannot tell a
GTPc packet from a GTPu packet, what the GTP packet type is, or
what the IMSI may be until reassembly is completed. If you want to see
if GTP reassembly is occurring on the system, run the show unifiededge ggsn-pgw ip-reassembly statistics command. It will show you
the number of GTP packets that have been reassembled since the GTP
statistics were last cleared and it will tell you if the system has dropped
any fragmented GTP packets.
root@GGSN-960#runshowunified-edgeggsn-pgwip-reassemblystatistics
Gateway:Masst
IPreassemblystatistics:
Firstfragments:507526
Non-firstfragments:507524
Totalfragments:1015050
Reassembledpackets:507524
Mergedpackets:507523
Packetspendingreassembly:2
Timedoutpackets:0
Timedoutfragments:0
Exceededmaximumpacketlength:0
FragmentsDropped:
Invalidlength:0
Overlap:0
Duplicate:0
Nobuffers:0
Packetlimitexceeded:0
Totalfragmentsdropped:0
clearing statistics
A quick word on clearing statistics since this action may be required
during the maintenance of the MBG. A system administrator can clear
statistics for several mobile applications such as AAA and Charging.
They may dig down and clear statistics for a whole gateway or even
95
96
individual APNs. There is quite a bit of flexibility on what you can clear
since Juniper knows end users may need to clear statistics for certain
functionalities yet keep the statistics for others so they can see what has
occurred over the lifetime of the box versus what has occurred recently.
Lifetime of the box in this context is considered the system uptime.
root@GGSN-960#runclearunified-edgeggsn-pgw?
aaaClearinformationrelatedtoAAA
address-assignmentClearinformationrelatedtoaddressassignment
chargingClearinformationrelatedtocharging
gtpClearInformationrelatedtoGTP
ip-reassemblyClearinformationrelatedtoIPreassembly
statisticsClearstatistics
subscribersClearsubscribers
root@GGSN-960#runclearunified-edgeggsn-pgwgtpstatisticsgtp-allgatewayMASST
root@GGSN-960#runclearunified-edgeggsn-pgwgtpstatistics?
gatewayClearstatisticsforagateway
gtp-allGTPallversionstatistics
Logs!
There are a few different control points in the Junos code that you
should care about when it comes to enabling logging for that given
section. Lets differentiate between them so you know which section of
the configuration is configured to enable that given log file. Note that
aside from the call trace feature we will show you, it is not recommended
to run the logs we will show you when in production.
GTP Logging
Go under the [edit

hierarchy:
unified-edge gateways ggsn-pgw Masst gtp]
traceoptions {
file masst_gtp.log size 50m;
level all;
flag all;
}
Gateway Logging
Go under the [edit
unified-edge gateways ggsn-pgw Masst] hierarchy:
traceoptions {
file masst_gateway.log size 50m;
level all;
flag all;
}
Charging Logging
Go under the [edit unified-edge gateways ggsn-pgw Masst charging] hierarchy:

traceoptions {
file masst_charging.log size 50m;
level all;
flag all;
}
AAA Logging
Go under the [edit
unified-edge aaa] hierarchy:
traceoptions {
file masst_aaa.log size 50m;
level all;
flag all;
}
If you must enable these logs in production, set the level and flag to
error first. If that is not sufficient, then try the debug all option.
When looking in the /var/logs directory, or wherever you decide to
store the logs, the mobile application log filenames will have the
MS-DPC slot/pic number for the SPIC that handled the processing of
the subscriber appended, as shown here:
-rw-r--r--1rootwheel532492Jan418:03charging_log-ms40
-rw-r--r--1rootwheel6693Jan418:03Masst_ue.log-ms41
-rw-r--r--1rootwheel344285Jan418:04charging_log-ms20
-rw-r--r--1rootwheel71288Jan418:04masst_gateway.log-ms41
Call Trace
The call trace functionality allows you to log all events for a specific
IMSI or MSISDN without having to enable the GTP traceoptions. You
can run several traces for different IMSI/MSISDNs at the same time:
root@GGSN-960>requestunified-edgeggsn-pgwcall-tracestartimsi101313783444554
ServicePICStatus
ms-0/0/0success
ms-10/0/0success
97
98
Here is the command to monitor the trace being run:

root@GGSN-960>requestunified-edgeggsn-pgwcall-traceshowdetail
Calltraceinformation:
Identifier:call_trace_id_1Tracefile:call_trace_id_1_01142012_152946
Status:not-doneCreateMask:0x44CompleteMask:0x0
IMSI:244212003476097
CallsTraced:0
Here is where you stop the trace. If you have more than one trace
running use the all command to stop them all if you need to.
root@GGSN-960>requestunified-edgeggsn-pgwcall-tracestopall
ServicePICStatus
ms-10/0/0
root@GGSN-960>requestunified-edgeggsn-pgwcall-traceshow
IdentifierFilenameStatusSPICMaskSPICMask
createcomplete
call_trace_id_1call_trace_id_1_01142012_152946done0x440x44
{master}
Like all the other files this one will be stored in /var/log. Here is a
snippet from log file call_trace_id_1_01142012_152946 showing a
PDP Conext being rejected due to an authentication failure. Now, if
this call trace was being run for an IMSI that belonged to a subscriber
who was complaining that they could not get data service, this is a
great place to start. It allows you to see data focused on a single
subscriber. In this case, you can start tracing down the issue to see if
RADIUS is failing the subscriber for some reason:
Dec516:12:30.1118022cpu_id:[6]gtid:[9]tid:[2]app_
id:1Encode:EncodingGTPV1Header
id:1Encode:MsgType17SeqNumber584TEID302149215
id:1Encode:EncodingCAUSEIE
id:1Encode:EncodingcauseAuthenticationfailure
id:1Encode:ERROR:Nonsuccessfulcausevalue(208)sent
id:1Encode:ENCODEDErrorResponseoflength14formsg17
Nov2616:20:53.1327494cpu_id:[5]gtid:[8]tid:[1]app_
id:1changereportingactionnotsupported
id:1HandlerreturnedPASS
id:1callingafProcessEventforevent=sessUpdate,state=Established
id:1i=0,size=1,evtProtocolBitmap=19info->cause=0,info->sub_cause=0
Nov2616:20:53.1328068cpu_id:[5]gtid:[8]tid:[1]app_id:1callingsessionevthandler#0forstate=Established,event=sessUpdateinfo->cause=0,info>subcause=0,num_handlers=1
Lets take a look at some common issues that may be seen in the log
files next.
Error: Subscriber Rejected, No Resources Available

Solving issues like this one that may come with scale requires some
expert logging troubleshooting. Lets diverge for a second. Remember
GTP logs and Call Trace logs capture information related to the GTP
service running on the MS-DPCs. As we stated a few pages back, GTP
logs are enabled under the [unified-edge gateways ggsn-pgw Masst
gtp] hierarchy, but Juniper recommends you only use the logs when
the MBG is not in production:
traceoptions {
file Masst_GTP.log size 50m;
level all;
flag all;
}
In the following abridged example from a GTP log, you can see a GTP
V1 message type 16 (Create PDP Context Request) that indicates a
new subscribers bearer request is being sent to the MBG from a SGSN.
The error message found at the tail end of the log Encode: Encoding
cause No resources available indicates that the MBG was unable to
assign an IP address to the subscriber. Take a look:
Jul 14 13:15:46.1218151 gtid: [0] tid: [0] Debug: gtp_dispatcher_parse_rx_pkt is called
Jul 14 13:15:46.1219417 gtid: [16] tid: [9] Debug: gtp_preparse_rx_pkt is called
Jul 14 13:15:46.1219493 gtid: [16] tid: [9] Debug: gtp_preparse_rx_pkt is
complete(success) version(1) msg_type(16)
Jul 14 13:15:46.1219609 gtid: [16] tid: [9] Debug: gtp_fullparse_rx_pkt is called
Jul 14 13:15:46.1221288 gtid: [16] tid: [9] Decode: Parsing GTPV1 Header
Jul 14 13:15:46.1221373 gtid: [16] tid: [9] Track: Rcvd GTPv1 msg type 16 in vrf 6 from
pfe-id 20 vpfe-id 0
Jul 14 13:15:46.1221457 gtid: [16] tid: [9] ReqTrack: V1 msg 16 Not a redirected
response
Jul 14 13:15:46.1221534 gtid: [16] tid: [9] ReqTrack: V1 msg 16 Not a tracked response
Jul 14 13:15:46.1221620 gtid: [16] tid: [9] Track: Received message len 95
Jul 14 13:15:46.1221842 gtid: [16] tid: [9] Track: 32 10 00 57 00 00 00 00 00 04 00 00 02
21 43 65 87 49 06 63
Jul 14 13:15:46.1222027 gtid: [16] tid: [9] Track: f0 0e 01 0f 00 10 00 00 01 05 11 00 00
01 06 14 05 1a 08 00
Jul 14 13:15:46.1222195 gtid: [16] tid: [9] Track: 80 00 02 f1 21 83 00 0a 05 6d 61 73 73
74 03 63 6f 6d 85 00
Jul 14 13:15:46.1222387 gtid: [16] tid: [9] Track: 04 0a 03 db 20 85 00 04 0a 03 db 20 86
00 05 91 62 37 77 84
Jul 14 13:15:46.1222501 gtid: [16] tid: [9] Track: 87 00 0c 01 22 72 0a 73 96 48 48 76 07
48 48
99
100
Jul 14 13:15:46.1222572 gtid: [16] tid: [9] Decode: Parsing GTPv1 Create PDP Request
Message
Jul 14 13:15:46.1222606 gtid: [16] tid: [9] Decode: Parsing GTP IE IMSI (2)
Jul 14 13:15:46.1222636 gtid: [16] tid: [9] Decode: IMSI 123:45:6789460360
Jul 14 13:15:46.1222664 gtid: [16] tid: [9] Decode: Parsing GTP IE RECOVERY (14)
Jul 14 13:15:46.1222693 gtid: [16] tid: [9] Decode: Recovery (Restart Counter) Value =
1
Jul 14 13:15:46.1222721 gtid: [16] tid: [9] Decode: Parsing GTP IE SELECTION_MODE (15)
Jul 14 13:15:46.1222751 gtid: [16] tid: [9] Decode: Selection Mode IE Value 0
Jul 14 13:15:46.1222779 gtid: [16] tid: [9] Decode: Parsing GTP IE ITEID_DATA (16)
Jul 14 13:15:46.1222812 gtid: [16] tid: [9] Decode: TEID Value 261
Jul 14 13:15:46.1222840 gtid: [16] tid: [9] Decode: Parsing GTP IE TEID_SIG (17)
Jul 14 13:15:46.1222869 gtid: [16] tid: [9] Decode: TEID Value 262
Jul 14 13:15:46.1222896 gtid: [16] tid: [9] Decode: Parsing GTP IE NSAPI_IE (20)
Jul 14 13:15:46.1222924 gtid: [16] tid: [9] Decode: NSAPI Value 5
Jul 14 13:15:46.1222951 gtid: [16] tid: [9] Decode: Parsing GTP IE CHARGING_CHAR (26)
Jul 14 13:15:46.1222980 gtid: [16] tid: [9] Decode: Charging Characteristics value 0800
Jul 14 13:15:46.1223010 gtid: [16] tid: [9] Decode: Parsing GTP IE END_USER_ADDR (128)
Jul 14 13:15:46.1223040 gtid: [16] tid: [9] Decode: Parsing GTP IE APN (131)
Jul 14 13:15:46.1223073 gtid: [16] tid: [9] Decode: Received APN masst.com
Jul 14 13:15:46.1223115 gtid: [16] tid: [9] Decode: Parsing GTP IE GSN_ADDRESS (133)
Jul 14 13:15:46.1223147 gtid: [16] tid: [9] Decode: GSN Addr 10.3.219.32
Jul 14 13:15:46.1223527 gtid: [16] tid: [9] Decode: GSN Addr 10.3.219.32
Jul 14 13:15:46.1223566 gtid: [16] tid: [9] Decode: Parsing GTP IE MSISDN (134)
Jul 14 13:15:46.1223599 gtid: [16] tid: [9] Decode: MSISDN IE, length 4 TBCD
2673774800000000
Jul 14 13:15:46.1223631 gtid: [16] tid: [9] Decode: Parsing GTP IE QOS_V1_PROFILE (135)
Jul 14 13:15:46.1223660 gtid: [16] tid: [9] Decode: Decoding V1 Qos IE
Jul 14 13:15:46.1223692 gtid: [16] tid: [9] Decode: QOS: delay = 4, reliability =
2,peak_throughput = 7, precedence_class = 2,mean_throughput = 10, traffic_class = 3,
delvry_order = 2, del_err_sdu = 3,max_sdu_size = 150, max_bitrate_uplink = 72,max_
bitrate_downlink = 72, residual_ber = 7, sdu_err_ratio = 6, transfer_delay = 1,traffic_
handl_priority = 3, guaranteed_bitrate_uplink = 72,guaranteed_bitrate_downlink = 72
Jul 14 13:15:46.1223746 gtid: [16] tid: [9] Decode: GTPV1 Packet successfully decoded
Jul 14 13:15:46.1248436 gtid: [15] tid: [8] Encode: Encoding GTP V1 Header
Jul 14 13:15:46.1248464 gtid: [15] tid: [8] Encode: Msg Type 17 SeqNumber 4 TEID 262
Jul 14 13:15:46.1248491 gtid: [15] tid: [8] Encode: Encoding CAUSE IE
Jul 14 13:15:46.1248517 gtid: [15] tid: [8] Encode: Encoding cause No resources
available
Jul 14 13:15:46.1248544 gtid: [15] tid: [8] Encode: ERROR: Non successful cause
value(199) sent
Jul 14 13:15:46.1248573 gtid: [15] tid: [8] Encode: ENCODED Error Response of length 14
for msg 17
Jul 14 13:15:46.1248612 gtid: [15] tid: [8] Track: Sending message len 42
Jul 14 13:15:46.1248668 gtid: [15] tid: [8] Track: 45 c0 00 2a 00 03 00 00 ff 11 ef de 0a
03 db fa 0a 03 db 20
Jul 14 13:15:46.1248728 gtid: [15] tid: [8] Track: 08 4b 08 4b 00 16 00 00 32 11 00 06 00
00 01 06 00 04 00 00
Jul 14 13:15:46.1248759 gtid: [15] tid: [8] Track: 01 c7
The cause of the error message can be several things. First, lets check
to see if it is an IP pool resource issue.
1. The MBG was misconfigured and does not have an access >
address assignment > mobile pools setup, or it can also mean you do
have the access > address assignment > mobile pools set up, but it
may be in maintenance mode.
The show unified-edge ggsn-pgw address-assignment service-mode
command will let you know what mode each pool is in:
Routing-InstancePoolNameServiceMode
GI_VRMassT-Pool-1Operational
GI_VRdefaultOperational
GI_VRroamerOperational
2. It could be the IP POOL(s) you have configured on the MBG have a

different range than the IP Pool being used by the RADIUS server (if
the APN in use uses RADIUS for authentication and for assigning IP
address). Remember, even if the RADIUS server is assigning the IP
addresses, Junos needs to map that to an internal pool resource.
3. The cause of this message could also be the UE sending over an IP
address that it wants to use, but the APN is not configured to allow
user assigned IP addresses. Here is where you would add the capability
in the MBG configuration so that the UEs could statically assign their
IP Address:
unified-edge gateways ggsn-pgw Masst apn-services apns masst.com]
address-assignment {
allow-static-ip-address;
}
If these three possible scenarios are not the cause of the issue, then you
may have run out of IP addresses, meaning the pool is truly exhausted.
Remember to run the show unified-edge ggsn-pgw address-assignment pool command to see what the state of the pool is resource wise:
root@GGSN-960>showunified-edgeggsn-pgwaddress-assignmentpool
Pool:MassT-Pool-1
Addressesinuse:109
Addressesskipped:0
Pool:default
Totaladdresses:254
Addressesinuse:0
Addressesskipped:0
Pool:roamer
101
102
Addressesinuse:14224
Addressesskipped:0
Addressusage(percent):0.
Now if the pools are not the problem you need to ask yourself: What is
going on when a subscriber gets rejected due to lack of available
resources on the MBG, even though the system has plenty of IP
addresses available?
You should check other resources on the MBG. Remember all those
policies you created under [unified-edge coscac] such as the total
number of bearers you are allowing, or the threshold settings you may
have applied? You can set the bearer total at the gateway level and
lower at the individual APN level. Lets see what Mass Telecom has set:
root@GGSN-960> show configuration unified-edge gateways ggsn-pgw Masst maximum-bearers
maximum-bearers 2000000;
root@GGSN-960> show configuration unified-edge gateways ggsn-pgw Masst apn-services
apns masst.com maximum-bearers
maximum-bearers 1500000;
And you can check the Threshold configuration here:

root@GGSN-960> show unified-edge cos-cac resource-threshold-profiles Masst_threshold
memory
low {
percentage 30;
gtpv1-arp 3;
}
high {
percentage 35;
gtpv1-arp 2;
}
Now you can run the show unified-edge ggsn-pgw status detail
command to see if you have exceeded your maximum-bearer settings

or if you have exceeded the cos-cac thresholds.
Gateway:MASST
Mobilegatewaystatus:
FPCSLOT:2PICSLOT:0
State:Active
ActiveSessions:7101
ActiveBearers:7101
CPULoad(%):2
MemoryLoad(%):31
FPCSLOT:2PICSLOT:1
State:Active
ActiveSessions:7123
ActiveBearers:7123
CPULoad(%):0
MemoryLoad(%):31
FPCSLOT:4PICSLOT:0
State:Backup
ActiveSessions:7101
ActiveBearers:7101
CPULoad(%):2
MemoryLoad(%):31
FPCSLOT:4PICSLOT:1
State:Backup
ActiveSessions:7123
ActiveBearers:7123
CPULoad(%):0
MemoryLoad(%):31
To complete the overview of the Encoding cause No resources available message, lets see what the gateway logs shows when it is encountered in the GTP log.
Here is what you might see in the gateway log if the IP address was sent
successfully from the RADIUS Server to the MX, but the Mobile-Pools
on the MBG have a different range, or are not set up with the externalassigned flag, so the PDP Context is rejected:
Jul 15 14:56:39.1405937 gtid: [15] tid: [8] Enter evthdl acquire_address
Jul 15 14:56:39.1405999 gtid: [15] tid: [8] External address verification: pdn type 1, source - 2, daf - 0, cause - 0, addr[0] - 15.1.194.25, addr[1] - 0:0:0:0:0:0:0:0
Jul 15 14:56:39.1406119 gtid: [15] tid: [8] LAM Assign : lam_find_chunk_in_tree.3983:
<<<<< Chunk: 0x5a5b8c6b8, Start IP: 15.1.192.0, Cnt: 1024
Jul 15 14:56:39.1406200 gtid: [15] tid: [8] smd_verify_external_address:2275 pfe_
index=129
Jul 15 14:56:39.1406368 gtid: [15] tid: [8] LAM Assign : lam_find_chunk_in_tree.3983:
<<<<< Chunk: 0x5a5b8c6b8, Start IP: 15.1.192.0, Cnt: 1024
Jul 15 14:56:39.1406461 gtid: [15] tid: [8] LAM Assign : verify_addr.4138: >>>>> cb_
data: 0xd000003, ds_info: 0x0
Jul 15 14:56:39.1406564 gtid: [15] tid: [8] LAM Assign : verify_addr.4345: <<<<< err:
12
Jul 15 14:56:39.1406728 gtid: [15] tid: [8] smd_verify_external_address:2338 - LAM
status: 12, AppFW cause code: AF_IP_ADDR_UNAVAIL (28)
Jul 15 14:56:39.1406784 gtid: [15] tid: [8] Handler returned ERROR
Notice the bolded items.
103
104
And this is what you would see in the gateway log if the pool that had
the range 15.0.0.0/14 was in maintenance mode:
Aug 4 22:08:20.711296 gtid: [12] tid: [6] Enter evthdl acquire_address
Aug 4 22:08:20.711315 gtid: [12] tid: [6] External address verification: pdn type - 1,
source - 2, daf - 0, cause - 0, addr[0] - 15.0.0.8, addr[1] - 0:0:0:0:0:0:0:0
Aug 4 22:08:20.711353 gtid: [12] tid: [6] LAM Assign : lam_find_chunk_in_tree.4009:
<<<<< Chunk: 0x0, Start IP: (null), Cnt: 0
Aug 4 22:08:20.711380 gtid: [12] tid: [6] smd_verify_external_address:2284 pfe_
index=130
Aug 4 22:08:20.711407 gtid: [12] tid: [6] LAM Assign : lam_find_chunk_in_tree.4009:
<<<<< Chunk: 0x0, Start IP: (null), Cnt: 0
Aug 4 22:08:20.711432 gtid: [12] tid: [6] LAM Assign : lam_find_addr_in_pool_prefix_
tree.3931: >>>>> Searching for: 15.0.0.8
Aug 4 22:08:20.711458 gtid: [12] tid: [6] smd_verify_external_address:2347 - LAM
status: 42, AppFW cause code: AF_NO_SERVICE (5)
Aug 4 22:08:20.711482 gtid: [12] tid: [6] Handler returned ERROR
Error: Encoding cause Missing or unknown APN
Another example of a key logging message is a GTP log showing a

subscriber come in with an APN that is not locally configured on the
MBG:
Jul 18 11:23:28.1566469 gtid: [0] tid: [0]
Jul 18 11:23:28.1567471 gtid: [8] tid: [1]
Jul 18 11:23:28.1567556 gtid: [8] tid: [1]
Jul 18 11:23:28.1567687 gtid: [8] tid: [1]
Jul 18 11:23:28.1568041 gtid: [8] tid: [1]
Jul 18 11:23:28.1568106 gtid: [8] tid: [1]
pfe-id 20 vpfe-id 0
Jul 18 11:23:28.1568151 gtid: [8] tid: [1]
response
Jul 18 11:23:28.1568215 gtid: [8] tid: [1]
Jul 18 11:23:28.1568291 gtid: [8] tid: [1]
Jul 18 11:23:28.1568437 gtid: [8] tid: [1]
21 43 65 87 49 75 03
Jul 18 11:23:28.1568644 gtid: [8] tid: [1]
01 fb 14 05 1a 08 00
Jul 18 11:23:28.1568771 gtid: [8] tid: [1]
40 6d 61 73 73 74 03
Jul 18 11:23:28.1568941 gtid: [8] tid: [1]
0a 03 db 20 86 00 06
Jul 18 11:23:28.1569102 gtid: [8] tid: [1]
73 96 48 48 76 07 48
Jul 18 11:23:28.1569162 gtid: [8] tid: [1]
Jul 18 11:23:28.1569234 gtid: [8] tid: [1]
Message
Jul 18 11:23:28.1569291 gtid: [8] tid: [1]
Jul 18 11:23:28.1569367 gtid: [8] tid: [1]
...
...
...
Jul 18 11:23:28.1570845 gtid: [8] tid: [1]
Debug: gtp_dispatcher_parse_rx_pkt is called

Debug: gtp_preparse_rx_pkt is called
Debug: gtp_preparse_rx_pkt is
Debug: gtp_fullparse_rx_pkt is called
Decode: Parsing GTPV1 Header
Track: Rcvd GTPv1 msg type 16 in vrf 6 from
ReqTrack: V1 msg 16 Not a redirected
ReqTrack: V1 msg 16 Not a tracked response
Track: Received message len 101
Track: 32 10 00 5d 00 00 00 00 00 0b 00 00 02
Track: f0 0e 01 0f 00 10 00 00 01 fa 11 00 00
Track: 80 00 06 f1 21 0a 0a 0a 01 83 00 0b 06
Track: 63 6f 6d 85 00 04 0a 03 db 20 85 00 04
Track: 71 18 23 12 68 f2 87 00 0c 01 22 72 0a
Track: 48
Decode: Parsing GTPv1 Create PDP Request
Decode: Parsing GTP IE IMSI (2)
Decode: IMSI 123:45:6789457300
Decode: Missing or Unknown APN @masst.com.
Jul 18 11:23:28.1570873
Cause 219
Jul 18 11:23:28.1570904
cause(219)
Jul 18 11:23:28.1570941
Jul 18 11:23:28.1570968
Jul 18 11:23:28.1571001
Jul 18 11:23:28.1571028
APN
Jul 18 11:23:28.1571056
value(219) sent
Jul 18 11:23:28.1571085
for msg 17
Jul 18 11:23:28.1571124
Jul 18 11:23:28.1571185
03 db fa 0a 03 db 20
Jul 18 11:23:28.1571242
00 01 fb 00 0b 00 00
Jul 18 11:23:28.1571275
Jul 18 11:23:28.1571340
tracked
Jul 18 11:23:28.1571385
complete(error)
gtid: [8] tid: [1] Decode: GTPV1 Packet Decoding Unsuccessful

gtid: [8] tid: [1] Decode: fullparse: Parse error version(1)
gtid:
gtid:
gtid:
gtid:
[8]
[8]
[8]
[8]
tid:
tid:
tid:
tid:
[1]
[1]
[1]
[1]
Encode:
Encode:
Encode:
Encode:
Encoding
Msg Type
Encoding
Encoding
GTP V1 Header
17 SeqNumber 11 TEID 507
CAUSE IE
cause Missing or unknown
gtid: [8] tid: [1] Encode: ERROR: Non successful cause

gtid: [8] tid: [1] Encode: ENCODED Error Response of length 14
gtid: [8] tid: [1] Track: Sending message len 42
gtid: [8] tid: [1] Track: 45 c0 00 2a 00 05 00 00 ff 11 ef dc 0a
gtid: [8] tid: [1] Track: 08 4b 08 4b 00 16 00 00 32 11 00 06 00
gtid: [8] tid: [1] Track: 01 db
gtid: [8] tid: [1] ReqTrack: Parse error spad type 2 not
gtid: [8] tid: [1] Debug: gtp_fullparse_rx_pkt is
Error: Encoding Cause Authentication Failure

The following GTP log looks fine until you get to the Encoding Cause
Authentication Failure message. So you look at the RADIUS Server
and see no requests reach it. In fact, a trace on the network shows the
MBG is not even sending a RADIUS request:
Jul 20 10:30:13.1700517 gtid: [0] tid: [0] Debug: gtp_dispatcher_parse_rx_pkt is called
Jul 20 10:30:13.1701947 gtid: [11] tid: [4] Debug: gtp_preparse_rx_pkt is called
Jul 20 10:30:13.1702003 gtid: [11] tid: [4] Debug: gtp_preparse_rx_pkt is
Jul 20 10:30:13.1702134 gtid: [11] tid: [4] Debug: gtp_fullparse_rx_pkt is called
Jul 20 10:30:13.1702302 gtid: [11] tid: [4] Decode: Parsing GTPV1 Header
Jul 20 10:30:13.1702371 gtid: [11] tid: [4] Track: Rcvd GTPv1 msg type 16 in vrf 6 from
pfe-id 20 vpfe-id 0
Jul 20 10:30:13.1702442 gtid: [11] tid: [4] ReqTrack: V1 msg 16 Not a redirected
response
Jul 20 10:30:13.1702510 gtid: [11] tid: [4] ReqTrack: V1 msg 16 Not a tracked response
Jul 20 10:30:13.1702580 gtid: [11] tid: [4] Track: Received message len 95
Jul 20 10:30:13.1702668 gtid: [11] tid: [4] Track: 32 10 00 57 00 00 00 00 00 02 00 00 02
21 43 65 87 49 26 19
Jul 20 10:30:13.1702774 gtid: [11] tid: [4] Track: f0 0e 01 0f 00 10 00 00 00 ff 11 00 00
01 00 14 05 1a 08 00
Jul 20 10:30:13.1702846 gtid: [11] tid: [4] Track: 80 00 02 f1 21 83 00 0a 05 6d 61 73 73
74 03 63 6f 6d 85 00
Jul 20 10:30:13.1702970 gtid: [11] tid: [4] Track: 04 0a 03 db 20 85 00 04 0a 03 db 20 86
00 05 91 62 37 77 85
Jul 20 10:30:13.1703075 gtid: [11] tid: [4] Track: 87 00 0c 01 22 72 0a 73 96 48 48 76 07
48 48
105
106
Jul 20 10:30:13.1703126
Message
Jul 20 10:30:13.1703188
Jul 20 10:30:13.1703256
...
...
...
Jul 20 10:30:13.1706551
Jul 20 10:30:13.1706584
complete(success)
Jul 20 10:30:13.1708108
Jul 20 10:30:13.1708133
Jul 20 10:30:13.1708163
Jul 20 10:30:13.1708188
failure
Jul 20 10:30:13.1708216
value(208) sent
Jul 20 10:30:13.1708244
for msg 17
Jul 20 10:30:13.1708283
Jul 20 10:30:13.1708341
03 db fa 0a 03 db 20
Jul 20 10:30:13.1708398
00 01 00 00 02 00 00
Jul 20 10:30:13.1708429
gtid: [11] tid: [4] Decode: Parsing GTPv1 Create PDP Request
gtid: [11] tid: [4] Decode: Parsing GTP IE IMSI (2)
gtid: [11] tid: [4] Decode: IMSI 123:45:6789462910
gtid: [11] tid: [4] Decode: GTPV1 Packet successfully decoded

gtid: [11] tid: [4] Debug: gtp_fullparse_rx_pkt is
gtid:
gtid:
gtid:
gtid:
[11]
[11]
[11]
[11]
tid:
tid:
tid:
tid:
[4]
[4]
[4]
[4]
Encode:
Encode:
Encode:
Encode:
Encoding
Msg Type
Encoding
Encoding
GTP V1 Header
17 SeqNumber 2 TEID 256
CAUSE IE
cause Authentication
gtid: [11] tid: [4] Encode: ERROR: Non successful cause

gtid: [11] tid: [4] Encode: ENCODED Error Response of length 14
gtid: [11] tid: [4] Track: Sending message len 42
gtid: [11] tid: [4] Track: 45 c0 00 2a 00 19 00 00 ff 11 ef c8 0a
gtid: [11] tid: [4] Track: 08 4b 08 4b 00 16 00 00 32 11 00 06 00
gtid: [11] tid: [4] Track: 01 d0
Notice the bolded line in the log. Now check the configuration for the
APN in use. You can see that the anonymous user is inactive within the
APN.
[edit unified-edge gateways ggsn-pgw Masst apn-services apns masst.com]
lab@GGSN-960# show
local-policy-profile LOCAL_POLICY_MBG;
apn-type real;
apn-data-type ipv4;
mobile-interface mif.16001;
address-assignment {
local;
inet-pool {
pool roamer;
}
}
session-timeout 24;
idle-timeout 60;
aaa-profile AAA_profile;
inactive: anonymous-user {
user-name seamus;
password "$9$ZcUk.fTz6Ct5T"; ## SECRET-DATA
}
selection-mode {
from-ms;
}
The UE and SGSNs are not sending any username/password credentials so the MBG will reject the session. Remember the MBG requires a
user name to be sent to the RADIUS server due to the nature of the
RADIUS protocol.
Summary
Theres lots of troubleshooting skills in working with the logs. And
theres more help for you at Juniper when you get your MobileNext
MBG up and running. So go get cracking on this Mobility solution. Its
awesome and easy to tweak.
107
108
What to Do Next and Where to Go

http://www.juniper.net/us/en/products-services/mobile-infrastructure/
These are the Juniper Mobile Infrastructure product portfolio pages.

http://www.juniper.net/us/en/products-services/mobile-infrastructure/packet-core/mobilenextbroadband-gateway/
For more information about the MobileNext Broadband Gateway.

http://www.juniper.net/us/en/local/pdf/datasheets/1000409-en.pdf
And heres the MobileNext Broadband Gateway data sheet.

http://kb.juniper.net/InfoCenter/index?page=content&cat=MOBILENEXT_BROADBAND_GATEWAY&chann
el=KB&smlogin=true
This is the knowledge base link for the MobileNet Broadband Gateway.

Deploying MobileNext PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deploying MobileNext PDF

Uploaded by

Copyright:

Available Formats

Juniper Mobile Infrastructure

DAY ONE: CONFIGURING THE MOBILENEXT

Data traffic is overwhelming todays

Juniper Mobile Infrastructure

Day One: Configuring the MobileNext

2012 by Juniper Networks, Inc. All rights reserved.

About the Author

Juniper Networks assumes no responsibility for any

Published by Juniper Networks Books

Version History: v1 July 2012

ISBN: 978-1-936779-50-5 (print)

This book is available in a variety of formats at: www.

Welcome to Day One

What You Need to Know Before Reading This Book

After Reading This Book, Youll Be Able To...

Day One: Configuring the MobileNext Broadband Gateway

Welcome to Juniper Networks Mobile Packet Core. If you are new to

A Typical Deployment for Junipers Mobile Packet Core Solution

Chapter 1: MobileNext Architecture

Massachusetts Telecom reviewed the legacy solutions of other vendors

Peering Into the MobileNext Specific Hardware

Day One: Configuring the MobileNext Broadband Gateway

Gateway are the enhanced MS-DPC cards, called MX-MOB-SDPC,

Verifying the Cards

Chapter 1: MobileNext Architecture

Mobile MX Processes and Terms

Day One: Configuring the MobileNext Broadband Gateway

Fast Path and Slow Path

Chapter 1: MobileNext Architecture

The MIF is tied to the APN configuration, which is covered in the

How the MBG Handles Subscribers (Steering)

Day One: Configuring the MobileNext Broadband Gateway

Session DPC-1 Session DPC-2 MPC-1

Steering Example for a PDP Context Activation

To explain the whole steering model in more detail, we need to start by

Chapter 1: MobileNext Architecture

Session DPC-1 Session DPC-2 MPC-1

Steering Example for GTP-U (aka Data Traffic)

Steering the IMSI When the TEID is 0 in a GTP-c Packet

Day One: Configuring the MobileNext Broadband Gateway

MBG Resource Management Architecture

Chapter 1: MobileNext Architecture

Routing Engine for a chunk of TIEDs, as whimsically shown in Figure

I need some TEIDs!

Give Me Some TEIDs

Day One: Configuring the MobileNext Broadband Gateway

Chapter 1: MobileNext Architecture

Source Port Ranges

Managing DHCP Resources

Day One: Configuring the MobileNext Broadband Gateway

Advanced Request Management

Chapter 1: MobileNext Architecture

Also, when the SGSN retransmits a Create PDP Context Request

GTP-U Data Sessions

Day One: Configuring the MobileNext Broadband Gateway

Day One: Configuring the MobileNext Broadband Gateway

Whats In Your MX?

Chapter 2: Setting Up the MBG

Editing the Chassis Hierarchy

Do you want those MS-DPC/SPICs to be able to handle any mobile

Day One: Configuring the MobileNext Broadband Gateway

control-cores specifies the number of cores used for the Junos