Mobile VPNs for Next Generation
GPRS and UMTS Networks
The concurrent evolution of computing, microelectronics, wireless data technologies, and the Internet
have given rise to a new trend in global telecommunications - data mobility. There are now about 100
million hosts connected to the Internet, and this number is almost doubling yearly. With mobile sub-
scribers expected to surpass one billion by 2003 (about half of which will be worldwide business users),
wireless data is definitely a communications technology whose time is fast approaching.
These skyrocketing subscriber numbers combined with recent technology advances are generating fast
growing interest in the emerging Third Generation (3G) wireless data standards, which among other
things specify the higher data rates necessary for wireless traffic. As this technology converges with the
exponential growth of the Internet, network-based, Mobile Virtual Private Networks (VPNs) will become
the major enabling technology for communicating business information via public networking infra-
structures. Indeed businesses today already are looking to wireless carriers for Mobile VPNs (and other
value-added IP services) as they attempt to cope with global on-demand communications, complex appli-
cations, productivity requirements, and shortages of IT talent. In the next few years, an enormous mar-
ket opportunity clearly awaits wireless carriers who can meet demands for such advanced services.
Two wireless packet data technologies — General Packet Radio Service (GPRS), a packet data overlay to
the existing GSM and TDMA networks and Universal Mobile Telecommunication System (UMTS), the
next generation of GSM/GPRS technologies — are central to the ability to provide high speed Mobile
VPNs. These technologies provide necessary architectural framework for private mobile communications
through the public Internet. This paper will focus on Mobile VPN services, comparing and contrasting cir-
cuit and packet approaches to wireless data. It also will examine the design and implementation of Mobile
VPNs within GPRS and UMTS cellular systems.
Wireless Data Concepts: Packet vs. Circuit
Existing Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), and Global
System for Mobile Communications (GSM) cellular systems supporting circuit-based data, provide users
with low-speed data connectivity. These technologies have a number of drawbacks including poor uti-
lization of air-interface resources, limited availability, use of wasteful dial-up connection technology, and
limited infrastructure integration. Packet technologies such as GPRS and UMTS were designed to over-
come these limitations.
With traditional, circuit-switched wireless data services, dedicated circuits at the physical layer are allo-
cated to subscribers whether or not they are being used. In contrast, wireless packet data services allow
subscribers to send and receive data without maintaining dedicated circuits.
Figure 1. Wireless Packet Data Concepts
Existing wireless packet data technologies that address these and other problems largely are conceptual-
ly similar and based on various tunneling mechanisms. (See Figure 1.) In all of them tunnels are dynam-
ically established between the mobile node’s temporary point of attachment to the Internet and its home
network (where the user is logically assigned the IP address). An alternative approach terminates tunnels
at an Intermediate Gateway node that acts as an anchor point. User packets then may either be tunneled
back to the home network (using another tunnel or a Link Layer technology) or directly delivered to a
local interface for forwarding. As mobile nodes dynamically change their points of attachment to the net-
work (traveling through certain area of the country from Mobile Switching Center (MSC) to MSC for
example), tunnels are dynamically established between the home and visited networks.
Today’s growing mobile workforce — and its attendant requirements for remote data access — is forever
changing the telecommunications industry. Telemetry and other un-tethered equipment, traveling sales
forces, field maintenance crews, telecommuters, and other mobile professionals are driving demands for
secure, anytime/anywhere access to corporate intranets, databases and e-mail servers. In this new envi-
ronment, productivity gains (or losses) will be directly linked to the information delivery process.
In the roughly ten years since their emergence, data VPNs typically have been implemented at the data
link layer using Frame Relay and ATM networking technologies. Now VPN services based on IP and the
use of the Internet are quickly gaining public interest and market acceptance. VPNs are evolving from
voice to data services and from wireline to wireless data networks. Like traditional VPNs, IP VPNs utilize
shared facilities to emulate private networks and deliver reliable, secure services to end users.
Mobile IP VPNs, which must provide these services over wireless media, also use IP tunneling technolo-
gies. (See Figure 2.) GPRS and UMTS-based VPNs use a combination of GPRS Tunneling Protocol (GTP)
on the dynamic “mobile” tunnel side and IETF-defined tunneling protocols on the “fixed” side. The busi-
ness benefits of deploying Mobile VPNs (MVPNs) are numerous. MVPNs provide remote workers with
constant, media-independent connectivity to corporate sites or to the ISPs and ASPs of their choice.
MVPNs also enable businesses and ISPs to outsource mobile remote access — thereby eliminating the costs
of purchasing and supporting the infrastructure while maintaining full control over address assignments
and user authentication and security. In this way, corporations can leverage the Internet to provide any-
time/anywhere, secure connectivity to remote offices, SOHOs, mobile employees, e-commerce and
extranet business partners over public network infrastructure. By enabling always on connectivity, there
is the potential to enhance relationships with customers, business partners, and suppliers by sharing in real
Figure 2. Mobile VPN
© 2000 Lucent Technologies, Inc.
Figure 3. Mobile VPN: Voluntary Tunnel
Implementing Mobile VPNs
IP tunneling is central to implementing MVPN. In addition to traditional wireline VPN features, MVPN
includes a set of mechanisms that use dynamic IP tunneling to support user mobility.
IP tunnels are paths that IP packets follow while encapsulated within the payload portion of another packet.
These encapsulated packets are sent to destination endpoints from originating endpoints via public (non-secure)
channels. Tunnels also can exist on a link layer (similar to the Frame Relay model), providing encapsulation for
non-routable protocols, such as Layer 2 Tunneling Protocol (L2TP) for Point-to-Point Protocol (PPP).
There are two basic tunneling methods for implementing IP VPNs — end-to-end or “voluntary;” and net-
work-based or “compulsory”. MVPNs based on voluntary tunneling are implemented by providing users
with public Internet access, and subsequently with access behind corporate firewalls via available tun-
neling techniques that allow secure data transmission. (See Figure 3.) The end-to-end tunnel used in this
case must exist for the duration of the session only.
Figure 4. Mobile VPN: Compulsory Tunnel
While voluntary tunneling provides a simple, secure end-to-end solution for access to private networks,
it also leads to extra encapsulation overhead over last-hop wireless links. Also, this is a less efficient, more
costly use of radio resources. In volume-based charging scenarios for instance, such overhead could sig-
nificantly increase corporate costs for remote connectivity.
Voluntary tunneling carries a number of other drawbacks as well. For example, it requires that mobile
nodes be given public addresses allowing end-to-end transparent IP connectivity. In addition, it requires
complex encryption and decryption algorithms, which can increase the complexity and cost of mobile
devices, which typically have low processing power and are often battery power consumption limited.
Also, with voluntary tunneling, applications that need to inspect or modify encapsulated packets will be
unable to get access to user traffic. This means that QoS solutions, traffic-shaping mechanisms, monitor-
ing equipment and firewalls will fail to perform their functions, and encapsulated (secured) packets can-
not be modified by the Network Address Translation (NAT) protocol.
Network-based “compulsory tunneling,” on the other hand, provides a more optimal foundation for
MVPN solutions. (See Figure 4.) This tunneling approach assumes that not mobile devices, but the wire-
less operator’s network infrastructure itself features the intelligence and functionality necessary for the
deployment of MVPNs. This approach assumes that the air interface owned by the wireless carriers is
secure. With “compulsory tunneling,” network components such as access servers, gateways, etc. (not the
mobiles) initiate tunnels, which typically terminate at the private network.
Compulsory tunnels can be used by multiple subscribers and can remain active even if no subscriber
transactions are in progress (thus placing less burden on the computing and routing infrastructure). The
compulsory approach to tunneling also assumes the existence of proper agreements between corporations
or ISPs and wireless operators. Service Level Agreements (SLAs) address the business relationships
between service providers and corporations, while the Security Associations (SAs) or shared secrets used
to generate IP Security (IPSec) session keys address the technical relationships. IPSec is a group of RFCs
(RFC 2401 and companion documents) dealing with the secure encapsulation of IP traffic.
Compulsory tunnels established through the public Internet require protection through authentication
and encryption. This protection, however, need not be extended through the radio link but can be imple-
mented between the tunnel end points only. Security in this scenario is likely to be based on IPSec, and
will include mechanisms for distributing keys such as the Internet Key Exchange (IKE - RFC 2409).
Figure 5. 3GPP Release 99 interface reference model
To implement MVPNs capable of supporting services on a large scale, wireless data infrastructures will
require a new class of platforms that fully comply with 3G and 2.5G wireless standards. Such systems will
provide the critical ability to rapidly address demands for business-class IP services. SpringTide 7000 Wireless
IP Service Switch addresses these requirements by leveraging a service-intelligent architecture, multi-pro-
tocol tunnel switching and true virtual routing. This powerful platform will enable wireless carriers to deliv-
er the industry’s broadest portfolio of highly available IP services including Mobile Virtual Private Networks.
GPRS and UMTS Networks
GPRS and UMTS wireless packet data technologies provide the higher speed data rates and the support for
standard mobile protocols necessary for secure MVPN service offerings for private corporate customers. By
enabling secure mobile data access, these technologies allow wireless carriers to meet the expectations of
corporations and ISPs whishing to enable traveling professional with constant on-demand data access.
The European Telecommunications Standards Institute (ETSI) defined GPRS as the standard for provid-
ing packet data services in GSM networks. UMTS, the Universal Mobile Telecommunication Systems
specified by 3GPP, represents the 3rd generation of mobile communication systems. UMTS is an evolu-
tion of current GSM and GPRS standards, which is based on Wideband CDMA radio interface. A UMTS
network is logically divided into a UMTS Terrestrial Radio Access Network (UTRAN) and a Core Network
(CN) connected via an open Interface (the Iu interface). Both GSM GPRS and UMTS systems allow wire-
less service providers to offer bi-directional packet data over both air interfaces and backbone networks.
As a result, both GPRS and UMTS CN allow for more efficient use of network resources for many types
of applications. [a1]3GPP reference model defines the elements and interfaces of both GPRS and UMTS
CN (See Figure 5.).
GPRS defines radio channels with flexible allocation. From one to eight radio-interface timeslots can be
allocated per TDM frame. Active users share timeslots and up and downlinks are allocated separately.
Radio-interface resources can be shared dynamically between speech and data services as a function of
service load and operator preference. EGPRS, an enhancement of GPRS, allows even higher bit rates on
the radio interface. It achieves these rates by using new modulation and coding.
The main elements of the GPRS and UMTS CN are the System GPRS Support Node (SGSN) and Gateway
GPRS Support Node (GGSN). The GPRS SGSN performs mobility management, implements authentica-
tion procedures and routes packet data. SGSN is the node to which mobile devices attach via the base sta-
tion when making data calls. The SGSN performs session management and state control. It also handles
data packet routing on the downlink to the mobile station, including location tracking and authentica-
tion between the network and the mobile device and its peers. SGSN sends queries to the Home Location
Register (HLR) to obtain profile data on GPRS subscribers. It detects new GPRS mobile devices in a given
service area, processes new subscriber registrations, and keeps records of their locations in that area.
The GGSN is the gateway node between PLMN (Public Land Mobile Network) GPRS Backbone Systems
(also known as UMTS Packet Switched Domain Backbone System in UMTS) and external data networks.
In order to support data-user mobility, the GGSN acts as an anchor point for mobile session. It terminates
the GPRS Tunneling Protocol (GTP) tunnels running over IP-based backbones between the GGSN and the
SGSN to which the user is currently attached. GTP encapsulates user packets over IP/UDP transport paths
and provides the set of control messages needed to set up and modify tunnels.
The GGSN also provides functions including:
• Address management (i.e. DHCP relay, static, dynamic address pool)
• Authentication, Authorization, Accounting (AAA)
• Client screening
• Traffic control
• Service performance measurements
• Accounting data collection
• Advanced IP services (i.e. MVPNs, directory services, per-flow accounting, etc.)
Wireless data platforms such as GGSN can be implemented on general-purpose non-real time computers
platforms with software routing capability such as Unix-based solutions or dedicated routing platforms
such as Remote Access Servers (RAS), Routers, and IP Service Switches.
© 2000 Lucent Technologies, Inc.
RAS devices are used to aggregate low-speed connections such as modem or ISDN calls from the PSTN and
a small number of T1’s or T3’s. Typical RAS is designed to handle specific numbers of sessions, which are
physically limited by a known number of interfaces with a known maximum throughput. RAS’s are rela-
tively costly in that they employ resource allocation strategies and operating systems that generally are not
optimized for efficient routing and tunneling support. In turn general-purpose routers traditionally have
been designed to dynamically communicate with large numbers of networks via a limited number of indi-
vidual connections. In today’s networks, IP router designs are optimized for use in dynamic clustered topolo-
gies that scale overall system performance by adding interconnected routers, rather than by scaling the num-
ber of connections to a specific router. Router designs were never intended to terminate tens (or even hun-
dreds) of thousands of simultaneous individual connections, PPP sessions, tunnels or tunneling sessions.
SpringTide 7000 Wireless for Mobile VPN Services
Lucent’s GGSN implementation is based on the industry-leading SpringTide 7000 IP Service Switch platform.
By incorporating the strengths of the existing wireline platform with newly designed wireless capabilities, the
Lucent GGSN will enable wireless operators to provide business-quality IP services for mobile users.
The SpringTide 7000 architecture uses virtual routing to deliver carrier-class scalability and services for
wireless carriers. It supports a flexible mix of tunneling protocols at both layer 2 and layer 3. These proto-
cols can be mixed and matched on the access or backbone side of the device so that flows may be switched
between one tunneling format and another as they traverse the switch. The service software within the
7000 dynamically creates the encapsulation and protocol stacks required to terminate, authenticate, route,
and mediate policy for all of the supported tunneling technologies — all under policy control.
As a state-of-the-art IP Service Switch, the SpringTide 7000, is designed to address the general short-
comings of routing solutions for wireless data and MVPN’s in that it can terminate and switch hundreds
of thousands individual tunnels while applying the necessary service processing functions to each user
traffic flow. Traffic enters and exits over any high-speed interfaces (i.e. ATM, Frame Relay) deployed with-
in the wireless carrier GPRS and UMTS core network.
The SpringTide 7000 can handle multiple tunnels over each of its interfaces and is equipped with carri-
er-class features such as NEBS 3 certification and full redundancy. The number of tunnels supported is
limited only by the amount of memory and processing power of the routing/tunneling engines available.
The SpringTide 7000 conveys traffic flows in virtual connections (i.e. virtual circuits, PPP sessions, IP tun-
nels) that are aggregated over its interfaces. It also is capable of aggregating and terminating hundreds or
thousands of user communication (PPP) sessions.
The SpringTide 7000 enables flexible, high-performance Mobile VPN services. It is equipped with all the
necessary hardware and software to terminate, authenticate, encrypt, and route a multitude of VPN tun-
neling technologies including GTP, Mobile IP, IPSec, IP in IP, L2TP, PPTP, PPPoE, and PPPoA and GRE.
Wireless carriers can use the tunneling technology of their choice and easily scale their MVPN services as
they grow their businesses.
The “Virtual Router” Approach
Like other products in the SpringTide family, the SpringTide 7000 Wireless is based on a switch architec-
ture that uses a virtual router concept in which services are dynamically created across “virtual”-rather
than physical-routers (GGSNs). Virtual routers provide the secure, segregated environments required for
delivering business-quality IP services.
Within the virtual router (GGSN), individualized service definitions for bandwidth, priority, and securi-
ty are retrieved from policy directories and provisioned on either a per-subscriber or per-traffic flow
basis. Virtual routers have their own routing tables and separate code address space with memory, which
prevents any one virtual router from affecting other virtual routers. Each virtual router within the
SpringTide 7000 Wireless has dedicated resources including allocated memory and instruction cycles
that handle updates, make necessary changes to forwarding tables, and send them to be stored on —
and utilized from — the local virtual router.
Virtual routers also employ highly efficient methods of calculating and maintaining routing and forwarding
tables. When the Route Processor Engine (RPE) gets the route update, it inserts it into the memory that has
been allocated for that virtual router. The RPE then executes the correct algorithm unique to that virtual
router. Several algorithms can be executed simultaneously within this architecture, each running individ-
ually without affecting the other since each virtual router is also allocated its own dedicated CPU cycles.
© 2000 Lucent Technologies, Inc.
In contrast, general routing is a time-consuming, complex process in which devices map each packet to
a specific context, based on the identity of the ingress port. The packet is marked with a label describing
it as a member of a particular context. It is then handed off to a general-purpose processor through a
shared PCI bus that recognizes the packet as a routing update. The processor then runs an algorithm to
rebuild the entire routing table for every routing context within the entire switch, paying attention to the
GPRS and UMTS VPN Implementation
GPRS and UMTS CN VPNs share most of the requirements for VPNs in general — such as authentication
and data integrity, security and confidentiality, and non-repudiation and robustness. Often, MVPN users
must be authenticated by both wireless access networks (through mechanisms such as HLR and VLR) and
private IP networks (through AAA servers such as Remote Authentication Dial In User Service
(RADIUS)). To prevent eavesdropping on data flowing between mobile users and corporate private net-
works and alteration of data by a third party, GPRS and UMTS Radio Access Network technologies pro-
tect packet data traffic by encryption over the air. This provides better performance than end-to-end
encryption methods which add extra bytes to each packet sent over the air.
It must be noted that there are a number of obstacles to VPN support in GPRS and UMTS CN systems
frameworks. Standards require that both the initiating and terminating nodes of the GTP tunnels sup-
porting mobility (SGSN and GGSN) must be located within private GPRS or UMTS CN networks owned
by wireless operators. To provide VPN services in such environments, carriers must provision new tun-
nels between GTP tunnel termination points (GGSN) and corporate networks. This would require GGSN
systems to perform tunnel switching, which places great demands on their processing power and tun-
neling capabilities. This also limits the VPN implementation options due to security considerations (more
on this later). Extending GTP tunnels into corporate domains by placing a GGSN at or behind the corpo-
rate firewall is a possible remedy. But because this would force wireless carriers to open their private
GPRS networks, it raises even more security issues. Although this model would allow corporations greater
control over their data traffic, they would have responsibility for maintaining and administering wireless
data networking equipment at their premises. Other issues with such scenarios would include the secu-
rity of the whole GPRS infrastructure, and premises access when outsourcing GGSN management back
to wireless carriers.
The GPRS Technical Specification provides for transparent and non-transparent modes of interconnection
between private GPRS networks and external IP networks. Transparent Mode supports only IP-based com-
munication and creation of IP-type Packet Data Protocol (PDP) contexts at the GGSN. Non-transparent
mode supports both IP and PPP modes of operation with IP or PPP-type PDP contexts created at GGSN.
With Transparent GPRS access mode:
• GPRS operators offer connectivity to IP networks without any user access authentication
• Mobile devices do not send any authentication request at PDP context activation
• GGSNs do not take part in the user authentication or authorization process
• Authentication is applied only at the wireless level between mobile devices and SGSNs by utilizing
HLR , VLR, and other physical layer elements.
• GPRS operators issue public IP addresses to GPRS users
Wireless operator in this scenario has an option to assign dynamic IP address to mobiles, using DHCP relay
mechanism. In this scenario GGSN will relay requests on to a DHCP server and responses to the mobile
station. Once the IP address has been established, GGSN will update its routing tables and send a GTP
Update context message to the SGSN.
The transparent mode provides at least a basic ISP service. It may also provide a bearer service for an end-
to-end tunnel (for example IPSec) to a private intranet (See Figure 6).
Non-transparent access mode can be utilized for providing network-based VPN services. With non-
transparent GPRS access:
• The MS is allocated (statically or dynamically) a private IP address belonging to the ISP or corporation
• GGSNs request user RADIUS authentication based on user authentication requests made at PDP
• Tunneling protocols, such as IPSec or L2TP, are used between GGSNs and ISPs or corporate private
network to transmit user traffic to a final destination point
© 2000 Lucent Technologies, Inc.
Figure 6. Transparent Internet access; Voluntary Tunnelling
In this mode the GGSN can perform authentication and obtain a dynamic IP address for the mobile sta-
tion. A Non-transparent IP session will rely on PPP CHAP and IPCP messages being in the protocol options
during session negotiation for authentication and IP address assignment or validation.
The Lucent GGSN enables a number of efficient approaches based on IPSec tunneling, IP/MPLS RFC
2547, L2TP, etc. for building network-based GPRS VPNs in Non-transparent mode. It also features unique
capabilities to dynamically create virtual routers (GGSNs) that enable highly scalable Mobile VPNs.
IPSec based MVPN
The IPSec protocol suite (RFC 2401) specifies a set of IP extensions that provide security services at the
network layer. IPSec technology is based on standard cryptographic technologies that enable very strong
data integrity and privacy guarantees. As IPSec secures the network layer connectivity, the IPSec proto-
col suite guarantees security for any application using it. Security services offered include connectionless
integrity, data origin authentication, confidentiality (encryption), and traffic flow confidentiality. These
services are accomplished via two traffic security protocols, Authentication Header (AH) and
Encapsulating Security Payload (ESP). Each protocol supports two modes: transport mode and tunnel
mode. In transport mode, the protocols provide protection primarily for upper layer protocols. In tunnel
mode, the protocols are applied to tunneled IP packets.
IPSec normally is associated with end-to-end voluntary tunneling approaches, but also can be used in a
network-to-network, compulsory tunneling context and for security at the transport layer when com-
bined with an L2TP based solution. This solution requires that the GGSN directly associate the mobile
device’s IP address with the IPSec tunnel so that packets to/from the mobile traverse only that tunnel.
Corporations may use private IP addresses that conflict with public Internet address assignments, as
described in RFC1918.
Figure 7 depicts the session flow of a PDP context establishment in which users are authenticated for pri-
vate network access via highly-trusted, third-party Private Key Exchange (PKI) service providers. This
scenario may be viable for corporations seeking to lower the cost of internal security systems, while
avoiding full trust in their wireless carrier. Wireless carriers could, themselves, offer to provide the PKI as
part of a value-added service, which might also include wireless e-commerce transaction services for hor-
izontal services/markets. In such cases, each VPN would be defined by filtering rules in a managed fire-
wall, with trusted GPRS HLR look-ups used to authenticate mobile subscribers to “VPN groups” for access
behind the corporate firewall.
When implementing and using IPSec, the security and system requirements of users, applications, and
sites must be carefully considered. Service providers also need to be aware that IPSec, if deployed incor-
rectly, can adversely affect users, hosts, and other Internet components. For this reason, corporations
© 2000 Lucent Technologies, Inc.
Figure 7. Transparent Access, IPSec in tunnel mode
using IPSec for wireless remote access and Mobile VPN connectivity might require professional services
to provide the necessary expertise for deployment.
IPSec based VPN is the most likely scenario for the wireless operators whose GGSNs can not support PPP
mode of operation in a required scale. Non-transparent IP based mode do not allow for access challenges
to be generated by RADIUS servers. Instead, challenges are generated locally by the Mobile Termination
(MT) component of the mobile phone. Because it is possible for impostors to tweak mobile phones to gen-
erate replayed challenge/response pairs, AAA mechanisms are weaker (in terms of anti-replay protection)
than PPP-based systems, such as the ones obtained using PPP PDP types. This limits the ability of corpo-
rations and ISPs to administer users through AAA and IP address assignment. Instead, corporations, ISPs
and their customers must trust wireless carriers to perform all these functions. In today’s security-con-
scious environment, offering services to ISPs and corporations experienced in handling PPP based com-
munications without supporting PPP-based PDP contexts (or only small numbers of them), severely lim-
its service provider ability to offer business-quality IP services.
MPLS based MVPN
Because of its traffic engineering capabilities, MPLS (Multi-Protocol Label Switching) is fast emerging as
an attractive option for forwarding IP packets over multi-service backbones in wireline networks. MPLS-
based VPNs are relatively easy to implement on GGSN based on routing platforms and, for this reason,
are being heavily promoted by traditional router manufacturers (whose products lacking the scaleable
support for other types of tunneling) trying to enter the wireless market. In contrast Lucent is offering
the unique solution that leverages two of VPN technologies - virtual router and MPLS, to offer the busi-
ness quality MVPN.
MPLS labels include distinct VPN identifiers that associate packets with private routing domains. This
maintains both address secrecy, and the ability to handle duplicate or overlapping addresses. MPLS label-
set-up protocols such as RSVP (Resource Reservation Protocol) or CR-LDP (Label Distribution Protocol)
can communicate dynamic reachability information through the MPLS network
The fundamental building block for SpringTide 7000 Wireless MPLS based VPN is Virtual Router (VR).
Virtual routers provide the secure, segregated environments required for delivering business-quality IP serv-
ices. Each virtual router has its own routing information base (RIB), forwarding information base (FIB) and
a separate MPLS data forwarding engine with its own code address space with memory, which prevents any
one virtual router from affecting other virtual routers. Within each virtual router, individualized service def-
initions for bandwidth, priority, and security are retrieved from policy directories and provisioned on either
a per-subscriber or per-traffic flow basis. Since virtual router is not run as a separate task in the underlying
operating system, CPU resources and memory utilization are independent of other virtual routers in the
same system. The performance of one virtual router does not affect other virtual routers in the system.
© 2000 Lucent Technologies, Inc.
Figure 8. Non-Transparent Access, MPLS-based VPN
The Lucent MPLS MVPN architecture consists of two logical layers - Service layer and Network layer. The
virtual customer equipment (VCE) supports the service layer. The provider router acts as a virtual label
edge router (VLER) and interfaces with the SP backbone. The VLER supports the network layer. These two
layers are tightly integrated and provide an elegant solution to building VPN. The beauty of this architec-
ture is in its flexibility and scalability. The flexibility is provided in the VPN management. The VR main-
tains separate route, forwarding and MIB database. The database separation of each VR allows the wire-
less carrier and/or its corporate customers to monitor traffic statistics, configure policies to build dynamic
on-the-fly extranets to corroborate with their business partners.
One method for deploying GPRS VPNs is using a combination of BGP-4 and MPLS protocols defined in
RFC 2547. This implementation is relatively straightforward when GGSN supports both BGP-4 and MPLS.
GGSNs (or Provider Edge (PE) devices) are tasked with associating Customer Edge (CE) devices into a
VPN group by virtue of common MPLS labels that combine the VPN ID with address prefixes used with-
in each private routing domain. The GGSN PE has knowledge of all of the networks to which it is direct-
ly connected via CE devices. This includes knowledge of which networks belong to which private domain.
Using that information, each GGSN (PE) builds and maintains its forwarding table. The information is
then shared with other PE routers by using techniques (attributes, communities, new address “families,”
etc.) supported by the BGP-4 standard. With a complete set of reachability information, as well as the
knowledge of which networks belong to which VPN, the PE routers can label packets with the informa-
tion necessary to forward them through the MPLS core over LSPs. Although MPLS can be combined with
IPSec for security and with L2TP to utilize the advantages of PPP, this approach can significantly degrade
L2TP based MVPN
Standardized L2TP (RFC 2661) evolved from various proprietary protocols such as layer 2 forwarding
(L2F) and point-to-point tunneling protocol (PPTP). It specifies improved interoperability between multi-
vendor tunneling equipment by extending PPP connections over different devices in separate networks,
as well as over multiple links and networks. L2TP in and of itself, is not fully secure. Although it can pro-
vide secure CHAP-like authentication of the L2TP control connection, the potential for tunnel hijacking
by expert hackers remains a possibility. To fully secure L2TP tunnels, service providers can use standard
IPSec mechanisms independently developed by IETF. Manually configured static security associations
could be part of an SLA between the corporation and the wireless network operator. Or, dynamic nego-
tiation procedures could be used, if a PKI is deployed and trusted by both parties.
L2TP operates in compulsory mode in which tunnels are supported by service provider network equip-
ment. It also can operate in voluntary mode with tunnels initiated by mobile devices. L2TP compulsory
service operation is made possible in GRPS and UMTS CN by the R’98 and RR ‘99 standards (PPP-relay
case). To support this option, GGSN must support PPP-based PDP contexts on a significant scale. In this
© 2000 Lucent Technologies, Inc.
case, mobile VPN users access corporate networks by first attaching to the GPRS network and then initiat-
ing PPP sessions and specifying Access Point Names (APNs). Once the PDP context is active, control of the
communication session is passed to the L2TP Access Concentrator (LAC) supported by GGSN, which trig-
gers the establishment of a L2TP connection to the corporate L2TP Network Server (LNS) and performs
GTP-to-L2TP tunnel switching. Newly-attached users can share previously established L2TP tunnels by cre-
ating new L2TP sessions within those pre-established tunnels. If the tunnel does not exist, a new tunnel
will be created. The GGSN/LAC then uses the L2TP control connection to establish an L2TP call (L2TP tun-
nel to carry PPP) between the LAC and the LNS. Using the services of the corporate AAA system (e.g.
RADIUS), the LNS performs the authentication of the mobile user. Following authentication, an IP address
is assigned to the mobile using IPCP or other address assignment mechanisms. For corporate network man-
agement purposes, using private corporate intranet IP addresses is preferable. It also saves carrier’s limited
number of public Internet addresses. Such communications, like security arrangements, are governed by
SLAs or defined between a GGSN/LAC and corporate-based LNS. (See Figure 9.)
In compulsory service operations, the wireless operator assigns APN network identifiers to corporations
according to certain rules. The APNs are used by the SGSN to select the GGSN to be addressed for a spe-
cific group of corporate mobile users. Using data stored locally or IP roaming mechanisms requiring LACs
to query AAA subsystems using the mobile user’s Network Access Identifier (NAI), the GGSN determines
the IP addresses of the GGSNs/LACs to which mobile users will be attached.
Figure 9. Non-Transparent Access, L2TP-based VPN
L2TP-based GPRS VPNs carry a number of advantages over other MVPN technologies. For example,
because L2TP is the only GPRS VPN technology supporting full RADIUS authentication of mobile users,
it provides extra levels of security beyond handset authentication by cellular systems. L2TP also can be
used in remote access solutions that allow ISPs and corporations (possessing extensive experience in
deploying L2TP based networks) to effectively combine their wireless and wireline access by outsourcing
the mobile access to wireless carriers. In addition, value-added services (i.e. load sharing, backup support)
will be available from any access server vendor supporting L2TP and corporations with L2TP based VPNs
can retain full control over IP address assignments and AAA functions.
The Virtual Router Approach
The virtual GGSNs, as implemented on SpringTide 7000 Wireless platform, are essentially a collection of
individual logical GGSNs upon which a variety of advanced IP services can be built. With the virtual
router approach, customers essentially lease network resources that are located on the GGSN owned by
the wireless operator. The Mobile VPN behaves, and is managed, in much the same way as an actual
physical private router network.
© 2000 Lucent Technologies, Inc.
The services and functions of virtual routers — available individually to each of hundreds of virtual
GGSNs provisioned in the SpringTide 7000 Wireless — include:
• IP routing over varied protocols (RIP, OSPF, BGP-4, etc.)
• Route policies over high-speed cell or packet media
• GTP/PPP session termination
• GTP/IP session termination
• PPP tunneling (PPTP and L2TP) initiation and termination
• RADIUS client
• LDAP client (for directory-enabled policy and service attainment)
• QoS-enabled forwarding (both DiffServ and ATM CoS)
• Stateful firewall (as well as basic packet filtering)
• IPSec tunnel initiation and termination
• MPLS LER
• DHCP Relay Agent
• VLAN (802.1Q)
Some of the advantages of Springtide 7000 Wireless - based VPN solution are:
• Management Flexibility: The VR model provides complete separation of software stack, manage-
ment MIBs, routing and forwarding tables. This approach provides complete privacy for network
management functionality-an important feature for wireless carriers serving business customers.
Since each virtual GGSN has it’s own SNMP MIB, administrative access to individual virtual GGSNs
can be isolated.
• Directory Driven Model: The Springtide’s service definition is directory based. The directory-based
approach is highly scalable and easy to deploy since if changes need to be made it has to be done
in a single place.
• Customized Services: The directory based policy model and fine grain identification of the user
and/or application flows allows SP to customize services not only per VPN customers but also per
applications for a VPN customer. For example, the SP can offer additional services to VPN customers
such that certain traffic flows (applications) get strongly encrypted
In addition, wireless carrier can leverage other Lucent GGSN features such as traffic engineering
capabilities, directory based model, subscriber management features etc. to increase revenue and
reduce operational cost (See Figure 10.)
Figure 10. Virtual Routing; Reduced Complexity, Higher Profits.
In summary, virtual router approaches provide the multiple functions of traditional GGSN, B-RAS, ATM
edge routers, customer premises VPN appliances, firewalls, and QoS/MPLS-enabled routers, among others.
Virtual routing-based MVPNs utilizing the SpringTide 7000 Wireless effectively allow wireless operators to
deploy any of the existing GPRS and UMTS VPN options without the drawbacks associated with the
3G . . . . . . . . . . . . . . . . .Third Generation
3GPP . . . . . . . . . . . . . . .3rd-Generation Partnership Project
AAA . . . . . . . . . . . . . . . .Authentication Authorization, Accounting
ATM . . . . . . . . . . . . . . . .Asynchronous Transfer Mode
AuC . . . . . . . . . . . . . . . .Authentication Center
BLST . . . . . . . . . . . . . . . .Board Level Self Test
BS . . . . . . . . . . . . . . . . .Base Station
BTS . . . . . . . . . . . . . . . . .Base station Transceiver System
CDMA . . . . . . . . . . . . . .Code Division Multiple Access
CGF . . . . . . . . . . . . . . . .Charging Gateway Function
EDGE . . . . . . . . . . . . . . .Enhanced Data rates through Global Evolution
EIR . . . . . . . . . . . . . . . . .Equipment Identity Register
ETSI . . . . . . . . . . . . . . . .European Telecommunications Standards Institute
GGSN . . . . . . . . . . . . . . .Gateway GPRS Support Node
GPRS . . . . . . . . . . . . . . .General Packet Radio Service
GSM . . . . . . . . . . . . . . . .Global System for Mobile Communications
GTP . . . . . . . . . . . . . . . .GPRS Tunneling Protocol
HLR . . . . . . . . . . . . . . . .Home Location Register
IETF . . . . . . . . . . . . . . . .Internet Engineering Task Force
IMEI . . . . . . . . . . . . . . . .International Mobile Equipment Identity
IMSI . . . . . . . . . . . . . . . .International Mobile Subscriber Identity
IMT-2000 . . . . . . . . . . . .International Mobile Telecommunications 2000
IPSec . . . . . . . . . . . . . . .IP security
ISP . . . . . . . . . . . . . . . . .Internet Service Provider
ITU . . . . . . . . . . . . . . . . .International Telecommunication Union
LCS . . . . . . . . . . . . . . . . .Location Services
L2TP . . . . . . . . . . . . . . . .Layer 2 Tunneling Protocol
LAC . . . . . . . . . . . . . . . .L2TP Access Concentrator
LAN . . . . . . . . . . . . . . . .Local Area Network
LNS . . . . . . . . . . . . . . . .L2TP Network Server
MAN . . . . . . . . . . . . . . .Metropolitan Area Network
MAP . . . . . . . . . . . . . . . .Mobile Application Part
MSC . . . . . . . . . . . . . . . .Mobile-services Switching Center
NodeB . . . . . . . . . . . . . .UMTS BaseStation
OA& M . . . . . . . . . . . . . .Operations, Administration and Maintenance
PLMN . . . . . . . . . . . . . . .Public Land Mobile Network
PDP . . . . . . . . . . . . . . . .Packet Data Protocol
PSTN . . . . . . . . . . . . . . .Public Switched Telephone Network
PVC . . . . . . . . . . . . . . . .Permanent Virtual Circuit
QoS . . . . . . . . . . . . . . . .Quality of Service
RA . . . . . . . . . . . . . . . . .Routing Area
RADIUS . . . . . . . . . . . . .Remote Authentication Dial-in User Service
RAS . . . . . . . . . . . . . . . .Remote Access Server
RNC . . . . . . . . . . . . . . . .Radio Network Control
RNS . . . . . . . . . . . . . . . .Radio Network Subsystem
SGSN . . . . . . . . . . . . . . .Serving GPRS Support Node
SIM . . . . . . . . . . . . . . . .Subscriber Identity Module
SMS . . . . . . . . . . . . . . . .Short Message Service
SRNS . . . . . . . . . . . . . . .Serving RNS
SVC . . . . . . . . . . . . . . . .Switched Virtual Circuit
© 2000 Lucent Technologies, Inc.
TCP . . . . . . . . . . . . . . . . .Transmission Control Protocol
TIA . . . . . . . . . . . . . . . . .Telecommunication Industry Association
TDD . . . . . . . . . . . . . . . .Time Division Duplex
TDM . . . . . . . . . . . . . . . .Time Division Multiplex
TDMA . . . . . . . . . . . . . . .Time Division Multiple Access
UCR . . . . . . . . . . . . . . . .UTRA/ cdma2000 Radio
UCU . . . . . . . . . . . . . . . .UTRA Channel Unit
UDP . . . . . . . . . . . . . . . .User Datagram Protocol
UE . . . . . . . . . . . . . . . . .User Equipment
URC . . . . . . . . . . . . . . . .Universal Radio Controller
USIM . . . . . . . . . . . . . . .User Service (or Subscriber) Identity Module
UMTS . . . . . . . . . . . . . . .Universal Mobile Telecommunications System
UTRA . . . . . . . . . . . . . . .UMTS Terrestrial Radio Access
UTRAN . . . . . . . . . . . . . .UMTS Terrestrial Radio Access Network
VLR . . . . . . . . . . . . . . . .Visitor Location Register
VPN . . . . . . . . . . . . . . . .Virtual Private Network
WAN . . . . . . . . . . . . . . .Wide Area Network
WAP . . . . . . . . . . . . . . . .Wireless Access Protocol
WCDMA . . . . . . . . . . . . .Wideband Code Division Multiple Access
SpringTide 7000 is a trademark of SpringTide
All other trademarks, registered trademarks,
service names, product and/or brand names are
the sole property of their respective owners.
This document is for planning purposes only
and is not intended to modify or supplement
any specifications or warranties relating to these
products and services.
Entire contents copyrighted by Lucent
Technologies, Inc. Unauthorized redistribution
electronic or otherwise, without prior written
approval of Lucent Technologies, Inc. is prohibit-
ed by law. Requests for permission to copy or
distribute, Lucent Technologies, Inc. Three Clock
Tower Place, Maynard, MA 01754.
To learn more, contact your Lucent Technologies
representative, authorized reseller or sales
agent. Or, visit our Web site at www.lucent.com.
Specifications subject to change without notice.
05-GPRS601 © 2001 Lucent Technologies, Inc.