IPv6 in the 3G network

1
 IPv6 for mobile - why??
 Address space problem
• Projected over 1 billion mobiles by 2005
• Not enough IPv4 addresses especially in Asia
• Eg-. In China, there 100+ million handsets and far less IP
addresses…
• IPv6 addresses – unique address / addresses
• Eliminate the use of NAT
• Overcome addressing / compatibility problems
 Operational advantages – eg stateless autoconfiguration
 Mobile IPv6 more efficient, can be used in future

2
IPv6 Recap:
New header format
Ver. Traffic Flow Label Ver. Hdr Type of Total Length
Class Len Service

Payload Length Next Hop Identification Flg Fragment

Header Limit Offset

Time to Protocol Header

Live Checksum

Source Address
Source Address
(128 bits)
Destination Address

Options...

IPv4Header
Destination Address
(128 bits)

IPv6 Header

3
IPv6 Recap:
Key changes in IPv6 header

 Addresses increased 32 bits -> 128 bits

 Flow Label field added
 Time to Live -> Hop Limit
 Protocol -> Next Header
 Type of Service -> Traffic Class
 Fragmentation fields moved out of base header
 IP options moved out of base header
 Header Checksum eliminated
 Header Length field eliminated

4
Text Representation of Addresses

“preferred” form: 1080:0:FF:0:8:800:200C:417A

compressed form: FF01:0:0:0:0:0:0:43

becomes FF01::43

IPv4-embedded: 0:0:0:0:0:FFFF:13.1.68.3
or ::FFFF:13.1.68.3

5
 General Format of Unicast Addresses

global routing prefix subnet ID interface ID

n bits m bits 128-n-m bits

 Hierarchical structure in global routing prefix and interface ID (ala CIDR)

 the interface ID is equivalent to the “host field" in an IPv4 address
 if leading bits of address = 000, interface ID may be any width
 if leading bits of address ≠ 000, interface ID is 64 bits wide

6
Configuring Interface IDs

There are several options for configuring the interface ID

of an address:
• DHCPv6 (configures whole address)
• Manual configuration (of interface ID or whole address)
• automatic derivation from 48-bit IEEE 802 address
or 64-bit IEEE EUI-64 address
• pseudo-random generation
“Stateless” autoconfiguration, when combined with high-order part of the
address learned via Router Advertisements

7
 IPv6 for 3G – How?
 Extend GPRS / GTP to handle IPv6 addresses during
PDP setup
 Methods to obtain IPv6 address
• Static
• Dynamic
• Stateless
• Stateful – using DHCPv6 (for increased control)

8
 Dynamic Stateless Autoconfiguration
MT BSS / UTRAN SGSN GGSN

1. Activate PDP Context Request (PDP type = IPv6, PDP Address = empty, …)

2. Create PDP Context request

MT extracts
Interface-ID
from the link 3. Create PDP context response (PDP
local address address = link local address, ..)
4. Activate PDP context accept GGSN configured to
advertise only one
5. Router Solicitation network prefix

6. Router Advertisement (M flag = 0, Network Prefix…)

7. Neighbor Solicitation

8. GGSN initiated PDP context modification procedure

GGSN updates the SGSN and MT

with the full IPv6 address

9
 Recommendations from the IETF
IPv6 WG to 3GPP
 Uniqueness: Each prefix must not be assigned to
more than one primary PDP context
 Allow 3GPP nodes to use multiple identifiers within
those prefixes, including randomly generated
identifiers
 Multiple prefixes may be assigned to each primary
context
 Work in progress…

10
 Types of Transition Mechanisms
 Dual Stacks
• IPv4/IPv6 coexistence on one device
 Tunnels
• For tunneling IPv6 across IPv4 clouds
• Later, for tunneling IPv4 across IPv6 clouds
• IPv6 <-> IPv6 and IPv4 <-> IPv4
 Translators
• IPv6 <-> IPv4

11
Transition Scenario –
Dual IPv4/IPv6 Stack

Native IPv4
Network
IPv4 Host

Native IPv6
Network
IPv6 Host
GGSN
Dual Stack
v4/v6 host

Dual Stack Router

IPv4 / IPv6 PDP

Context Separated approach – simple and efficient
Possible as mobile usually closed system environment
GGSN is a dual stack device
Could be native IP interconnects, and also IPv4 PE and IPv6 PE (6PE))

12
 Tunnel and Transition Types (many!)
 Configured tunnels - Router to router
 Automatic tunnels
• Tunnel Brokers (RFC 3053)
• Server-based automatic tunneling
• 6to4 (RFC 3056)
• Router to router
• ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)
• Host to router, router to host, Maybe host to host
• 6over4 (RFC 2529)
• Host to router, router to host
• IPv64
• For mixed IPv4/IPv6 environments
• DSTM (Dual Stack Transition Mechanism)
• IPv4 in IPv6 tunnels etc….

13
Transition Scenario –
Tunneling Options Diagrams - Gopinath Rao Sinniah, AIMST

IPv6 IPv4
Network Network IPv6
Network
RBS
GGSN
IPv6 IPv6
host host

IPv6 PDP v6/v4

Context Routers

IPv4 IPv6
Network Network IPv4
Network
RBS
GGSN
IPv4 IPv4
host host

v4/v6
IPv4 PDP Routers Practical transition; within backbone constraints
Context

14
 Network Address Translation - Protocol Translation
(NAT-PT)
IPv6 IPv4
IPv4 Pool: 120.130.26/24 Network Network
IPv6 prefix: 3ffe:3700:1100:2/64
Mapping Table
DNS
Inside Outside
3ffe:3700:1100:1:210:a4ff:fea0:bc97 120.130.26.10

Source = 120.130.26.10
Source = 3ffe:3700:1100:1:210:a4ff:fea0:bc97 Dest = 204.127.202.4
Dest = 3ffe:3700:1100:2::204.127.202.4 NAT-PT

Source = 204.127.202.4
Dest = 120.130.26.10
v4host.4net.org
Source = 3ffe:3700:1100:2::204.127.202.4 204.127.202.4
Dest = 3ffe:3700:1100:1:210:a4ff:fea0:bc97

v6host.6net.com Greater complexity

3ffe:3700:1100:1:210:a4ff:fea0:bc97 Limited NAT/FW ALG support today
Must be an interim step only

15
QoS in the Mobile – 3G Network

16
 3GPP Release 5
End-End QoS Framework
 T3.207 – End-end QoS architecture:

 Complements 23.107 describes Quality of Service for the "GPRS Bearer Service“ (main developments in Rel4)

 Introduces a PDF – Policy Decision Function (policy Server) to interwork between applications and IP bearer service (GGSN = Policy Enforcement Point). Also possible mapping between
GPRS and IP bearer services.

 Allows use of either Diffserv or Intserv (or both!)

17
QoS requirements in UE and GGSN

UE GGSN
Capability
DiffServ Edge Function Optional Required
RSVP/IntServ Optional Optional
IP Policy Enforcement Optional Required (*)
Point

18
  
23.107

4 QoS classes are defined in UMTS

refer TS 23.107

Traffic class Conversational Streaming class Interactive class Background

class streaming RT Interactive best Background
conversational RT effort best effort

Fundamental -Preserve time -Preserve time -Request response -Destination is

characteristics relation (variation) relation pattern not expecting
between (variation)   the data within
information between -Preserve payload a certain time
entities of the information content -Preserve
stream entities of the payload
Conversational stream content
pattern (stringent
and low delay )

Example of the - Voice - Streaming - Web browsing - Background

application - VoIP, video calls video - Machine polling download of
emails, non
realtime video
downloads

19
 UMTS bearer attributes defined for each bearer traffic
class
Conversational Streaming class Interactive class Background class
Traffic class class

Maximum bitrate X X X X Note – these map down into Radio

Bearer QoS capabilities, which are
Delivery order X X X X similar in makeup
Maximum SDU size X X X X
SDU format X X
information

SDU error ratio X X X X

Residual bit error X X X X
ratio
Delivery of X X X X
erroneous SDUs
Transfer delay X X

Guaranteed bit rate X X

Traffic handling X
priority

Allocation/Retention X X X X
priority
Source statistics X X
descriptor

Signalling indication X

20
Value ranges for UMTS Bearer Service Attributes
Conversational Streaming class Interactive class Background class
Traffic class class

Maximum bitrate <= 16 000 (2) <= 16 000 (2) <= 16 000 - <= 16 000 -
(kbps) overhead (2) (3) overhead (2) (3)
Delivery order Yes/No Yes/No Yes/No Yes/No
Maximum SDU size <=1 500 or 1 502 (4) <=1 500 or 1 502 (4) <=1 500 or 1 502 (4) <=1 500 or 1 502 (4)
(octets)
SDU format (5) (5)
information

Delivery of Yes/No/- (6) Yes/No/- (6) Yes/No/- (6) Yes/No/- (6)

erroneous SDUs
Residual BER 5*10-2, 10-2, 5*10-3, 5*10-2, 10-2, 5*10-3, 4*10-3, 10-5, 6*10-8 (7) 4*10-3, 10-5, 6*10-8 (7)
10-3, 10-4, 10-5, 10-6 10-3, 10-4, 10-5, 10-6
SDU error ratio 10-2, 7*10-3, 10-3, 10-4, 10-1, 10-2, 7*10-3, 10-3, 10-3, 10-4, 10-6 10-3, 10-4, 10-6
10-5 10-4, 10-5
Transfer delay (ms) 100 – maximum 280 (8) – maximum
value value

Guaranteed bit rate <= 16 000 (2) <= 16 000 (2)

(kbps)

Traffic handling 1,2,3 (9)

priority

Allocation/Retention 1,2,3 1,2,3 1,2,3 1,2,3

priority
Source statistic Speech/unknown Speech/unknown
descriptor

Signalling Indication Yes/No (9)

21
Mapping from R97/98 GPRS QoS attributes to
Release 99 onwards
Resulting R99 Attribute Derived from R97/98 Attribute
Name Value Value Name
Traffic class Interactive 1, 2, 3 Delay class
Background 4
Traffic handling priority 1 1 Delay class
2 2
3 3
SDU error ratio 10 -6
1, 2 Reliability class
10-4 3
10-3 4, 5
Residual bit error ratio 10-5 1, 2, 3, 4 Reliability class
4*10-3 5
Delivery of erroneous SDUs 'no' 1, 2, 3, 4 Reliability class
'yes' 5
Maximum bitrate [kbps] 8 1 Peak throughput class
16 2
32 3
64 4
128 5
256 6
512 7
1024 8
2048 9
Allocation/Retention priority 1 1 Precedence class
2 2
3 3
Delivery order yes' yes' Reordering Required
SGSN and the GGSN(Information in the
PDP Contexts)
'no' 'no'
Maximum SDU size 1 500 octets (Fixed value)

22
IP CoS Basics
Key Functions
Per-flow Rate Traffic
Policing Priority Congestion
Classification
Queuing Avoidance
&
Marking SP
W
R
R

• IP Flow RED
• IP Precedence bits, DSCP Byte
• MPLS CoS bits
100%
• Incoming Physical Interface Stream
• Incoming Logical Interface
• Destination IP address
• Application (stateful) etc…
100% 100%
PLP=1 PLP=0

23
 Converged Network CoS Design
 In a voice / best effort network, three classes (at least) of service are necessary:
• IP network control traffic
• Low bandwidth requirements, not sensitive to latency, jitter
• Must not be starved
• Voice signaling and bearer traffic
• Highest latency and jitter requirements
• Best effort data traffic
• Whatever capacity is left
 More complex configurations may or may not be needed in other network
designs (e.g. with VPN service)
 More classes = more complexity, no way around this.

24
Real World Case Study –
Customer QoS allocations
MPLS Forwarding Behaviour Traffic Type Hardware Drop
EXP Queue Probability
Bits
000 Best Effort IP Traffic Queue 0 -
(UMTS Best Effort Class)
001 Assured Forwarding 12 Queue 2 High

010 Assured Forwarding 11 3G Signalling traffic Low

UMTS Streaming Class
Unified Messaging client
011 Expedited Forwarding 1 Queue 1 High

100 Expedited Forwarding 3G AAL2 traffic Low

(UMTS Conversational Class)
101 Network Control 3 / Queue 3 High
Assured Forwarding 41
110 Network Control 1 / Network Control Low
Assured Forwarding 21 UMTS Interactive Class
111 Network Control 2 / High
Assured Forwarding 31

25
 Real World Case Study –
Customer QoS allocations

 Queue implementation on network routers

Hardware Traffic Type WRR Queue depth

Queue weighting
Queue 0 IP traffic 60% 60 %
Queue 1 3G AAL2 traffic 25 % 10% Expedited
Queue 2 3G Signalling 10 % 10%
traffic
Forwarding
Queue 3 Network Control 5% 20%
(strict
priority for
voice)

26
 What is Diff-Serv TE ?
 Diff-Serv: scheduling/queuing behavior at each node depends on traffic type (indicated by
DSCP/EXP setting ) - hop by hop QoS
 MPLS TE: use of constraints to control placement of LSPs. Typically, various traffic
classes share the same LSP. Bandwidth reservations do not take account of the classes of
traffic involved.
 MPLS Diff-Serv TE:
• Traffic divided into up to eight Class-Types.
• CSPF and RSVP take the Class-Type into account when computing path of LSP.
• Results in More granular bandwidth reservation.
 On each link in network, can have separate bandwidth constraints for each type of traffic
• E.g. limit the bandwidth taken by voice LSPs on a link to a maximum of 40%, data
LSPs take the rest.

27
 CoS / QoS & Forwarding
 Diff-Serv-aware MPLS Traffic Engineering
 Guaranteed bandwidth for MPLS
• Combines MPLS DiffServ and DiffServ TE
• Provides strict point to point QoS guarantees

Aggregated State (DS)

Aggregate Admission Control (DS-TE)
Aggregate Constraint-based Routing (DS-TE)

No state Aggregated state Per-Flow state

MPLS Diff-Serv +
MPLS DS-TE
Best effort Diff-Serv RSVP v1
MPLS & Int-Serv
Guaranteed
Bandwidth

28
 Components of DS-TE
 Three components:
• Per-class admission control – RSVP extensions, IGP
extensions
• Per-class input policing at the edge – LSP Policing
• Per-class scheduling (one queue for all traffic of a given
class) – DiffServ
• Aggregated scheduling: a class queue carries many LSPs
 THE RESULT:
• Admission control + policing at the edge + dedicated
queue = guaranteed bandwidth

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 29

 Layer 2 Migration
VC to MPLS QoS Mapping
VPs
PE to PE E-LSPs
ATM Control Traffic (PSN Tunnel) QoS Flows Based
Queues on EXP Bits
CBR
CBR (10% bw)
VBR rt ->CT3
(CLP0, CLP1)

VBR rt (20% bw)

VBR nrt
->CT2
(CLP0, CLP1)

VBR nrt (20% bw)

ABR/UBR ->CT1
(CLP0, CLP1)

Trunk VPN Label

ABR/UBR (50% bw)
(Pseudo Wire)
CT0

ATM Interface POS Interface

30
Looking into the future
3G Release 6

31
 3G Release 6 TS 23.221

BICC Circuit switched

call control server

H.248
RTP
or
UDP/IP or AAL2 AAL2 TDM
Iu cs ATM
Iu b IP
NodeB
PSTN
Iu ps
USIM IP/AAL5

IMS enhancements for conversational

Internet
Multimedia Broadcast/Multicast Service Corporate
(MBMS) – conferencing etc
SIP IP Multimedia
UMTS/GPRS - WLAN Interworking Service charging CSCF
enhancements
Definition in R6, implementation sooner

32
 Service based charging and control
 Convergence of service differentiation, service specific policies and charging policies
• IP flow-based charging
• Enable differentiated online and offline charging for the traffic flows belonging to different
services (a.k.a. different service data flows) even if they use the same PDP Context.
• Dynamic policy control enhancements (also ties in with QoS)
• Enable service based local policy control over IP bearer resources to evolve separately from
SIP services.

 Requirements:
• Ability to classify IP traffic into services based on content (stateful. Eg- URI)
• Ability to apply flexible charging rules and service based local policy control based on
service classification
• Ability to enforce IP bearer policies for multiple services

33
 Service based charging and control
Online Charging System*

Service Data Service Data Flow

CAMEL AF
SCP Flow Based Based Charging
Credit Control Rules Function Rx

Gy Gx Gq

Traffic Plane Policy Decision

Function Function
Go

 Timescale:
• 3GPP Release 6
• Early realization by some vendors at the GGSN

34
 3G complimentary access technologies
 Access technologies that compliment a 3G FDD network by providing high-speed data
services in hot-spot areas
• 802.11 based WLAN, HSDPA, TDD / portable broadband
 Requirements:
• Existing core networks to support connectivity to WLAN, TDD access networks
• Allow access to PS services (e.g. IMS) from WLAN access networks
• Ability to handle additional transport capacity as a result of higher bandwidth
 Timescale:
• 3GPP Release 6 for basic WLAN inter-working scenarios
• Realization of basic scenarios by many vendors

• HSDPA in 3GPP Release 5

35
 3G complimentary access technologies
Intranet / Internet
3GPP Visited Network
3GPP AAA Wf CGw/CCF
Wr/Wb Proxy
WLAN Access Network
Wg
WLAN Wn Wireless Access

Ws/Wc
UE
Gateway

Scenario 3

Wn
3GPP AAA Wx HSS
Server
Wm

D W
'/
Gr
Wo
HLR

'
f
Packet Data
Gateway
OCS CGw/
CCF
Wi

3GPP Home Network

PS Service Network

36
 Agenda
 Mobile overview and the transition to 3G
 2.5G data networks
 3G - phases of deployment. Focus areas:
• Layer 2/MPLS migration
• IP RAN and transition techniques
• IP Multimedia subsystem and QoS
• ‘Push to Talk’ example
• IPv6
 WLAN integration options
 Case studies

37
 High level Scenarios
 VPN / Network level integration
 Authentication / billing integration
• Web logon: SMS delivered password
• SIM integration
 3GPP work – ongoing (GRPS/WCDMA)
 Real time handover
• Mobile IP

38
 VPN / Network Level integration
eg- Leading Asian Wireless Operator
 Integration of VPN access for mobile corporate users regardless of access type

 Outsource remote access management from corporates, and aggregate users in a layer
3 VPN – common point of subscriber management

 Network diagram:
Mobile users mapped
into corporate VPNs

IPSEC / L2TP
(RFC 3193)
MPLS
MPLS Backbone
WiFi User with native
Windows Client
Native
L2TP
M Series (P)
LAC E Series (PE)
GGSN & Tunnel
3G and PHS users Gateway

39
 Authentication / Billing integration
 First approach: web login approach for WLAN
• Username and password login or/
• One time password delivered by SMS/text message

 Billing integration – WLAN charges appear on normal

mobile bill – backend integration.
• Flat rate or time / usage based

 Examples of this approach: Verizon Wireless, Telstra

40
 GPRS/CDMA Example
Telstra Corp. Australia
 Mobile centric service, launched in August 2003
 Public WLAN access to the Internet and corporate VPNs
 Available in hotspot locations throughout Australia
• Target of 600 hotspot locations in 2004
• International roaming through the Wireless Broadband Alliance
 Use of centralised control functions (E Series + SDX)

The "Wireless Hotspot" service is expected to become our "workhorse" mobile data
network, especially for corporate users, providing greater bandwidth in high traffic
locations than our cellular GPRS and 1xRTT mobile networks.
- Ted Pretty, Telstra Mobile Group Managing Director

41
 Mobile Operator focus –
Simple billing for Telstra mobile customers
 Time based billing; hourly rate

 Login via a password delivered by SMS to a Telstra mobile

• Usage appears on customers normal mobile Bill

 Lowered barriers to uptake

• No special WLAN subscription needed – casual pay-per-user
• Captive portal logon using DHCP – no client software required

 Credit card payment option for non-Telstra post-paid mobile customers

 Inbound roaming also supported (eg with Wireless Broadband Alliance partners), can enable
wholesale offering also

42
 How it works - Step One
• User opens up web
browser and tries
to go to Google
• Session directed
to captive portal
software (SDX)
• Choice to enter
mobile phone
number or
username and
password
• Mobile phone
number entered

43
 Step Two
• One-time password
sent via SMS to
user’s mobile
phone

• Received password
entered into
portal page

44
 Step Three
• Upon successful
authentication,
captive portal is
released and
original web
destination is
loaded.
• Mini-logout
window to
facilitate signoff.
• Usage billed to
user’s mobile
phone bill once finished

45
 Authentication on WLAN using
802.1X and EAP on 802.11 - overview
Access Point

RADIUS
Association Ethernet Server

Access blocked
802.11 Associate-Request 802.11 RADIUS
802.11 Associate-Response
EAPOW-Start EAPOW
EAP-Request/Identity
EAP-Response/Identity Radius-Access-Request
EAP-Request Radius-Access-Challenge

EAP-Response (credentials) Radius-Access-Request

EAP-Success Radius-Access-Accept
EAPOW-Key (WEP) Access allowed
Source: Microsoft

46
Maintaining subscriber control when using
802.1x/EAP environment
“Transparent RADIUS relay” concept
 802.1x access points have Radius client, EAP messages encapsulated in Radius messages
 Host MAC address in the calling-station-attribute
 Radius relay (BRAS) uses @domain name to forward Radius request to an external EAP capable
Radius proxy or server
 BRAS relay stores Host MAC address and awaits authorization data (VR to use, IP pool/address to
use, filters, etc)
 DHCP request, based on the host MAC address, creates subscriber interface in proper context
allocates IP address, assign default policies. SDX with no Web login
 Access point creates Radius authentication and accounting (stop)
IDAS = Integrated
Policy Control
DHCP Access Server
Bridge
d circu
it
802.1x AP Premium Content
IDAS
Internet
Radius
Relay MPLS VPN
GRE, routed, DSL, FR,ATM, LL, MetroE
802.1x AP

47
 PWLAN and Mobile
 3GPP standards org defined five scenarios for PWLAN integration with 3G
• From common authentication to seamless handover of voice service
• Specified 802.1x based authentication
• Part of 3GPP Release 6, specified in TS 23.234

 But, real deployments are occurring well in advance of 3GPP R6……so:

 GSM Association WLAN Task Force issued guidelines for pre Release 6
• Wed based login initially transitioning to 3GPP release 6 spec
 A SIM located in WLAN cards will use authentication based on EAP/SIM
• Eg- Use of SIM dongle
 EAP to SS7 gateways will allow mobile HLR / HSSs to authenticate the WLAN card

48
 Authenticating against the GSM HLR
 Existing database with all mobile subscriber information
 Existing provisioning and customer care systems are used
 EAP/SIM can offer GSM equivalent authentication and encryption
 Gateway between RADIUS/IP and MAP/SS7 is required
• Eg Funk Software Steel Belted Radius/SS7 Gateway
• Ulticom Signalware SS7 software
• Sun server E1/T1 interface card
• An overview of the product is in this attachment:
• Major vendors Ericsson, Siemens, Nokia all have or are developing their own offer

49
 802.1x EAP/SIM authentication from HLR
Transparent RADIUS relay

GW MAP HLR
SS7

BRAS AC, RADIUS/SS-7

Authenticator (RADIUS Relay) HLR
Client GW

EAPoL
RADIUS
RADIUS
Gr Interface
Client -
Authentication

DHCP Discover

Client – DHCP Offer

IP Address
Assignment DHCP Request

DHCP Ack {address = End

User address from GGSN}

50
 Tight integration proposed by 3GPP
HLR

GPRS Tunneling Protocol GGSN

Access Controller, RADIUS/SS-7

Client Authenticator RADIUS Relay HLR GGSN
GW

EAPoL
RADIUS
RADIUS
Gr Interface
Client -
Authentication
Create PDP Context {IP, transparent mode APN,
IMSI/NSAPI, MSISDN, dynamic address requested}
Create PDP Context Response {End User Address}
DHCP Discover

Client – DHCP Offer

IP Address
DHCP Request
Assignment
DHCP Ack {address = End User
address from GGSN} Lease
expiration
Delete PDP Context Request

51
Real time handover…

 Many access types – WLAN, 3G, GPRS…

 Mobile IP could provide reasonable real-time macro roaming between
cellular and WLAN access types (also alternates such as 802.16/WiMax)
 Supported for dual mode CPE/handsets
• Eg- Dual Mode NEC cellphone with WLAN as trialed in DoCoMo
• PDAs with WLAN and CDMA 1x/EVDO or GPRS/WCDMA
• Notebooks with cellular data or dual mode cards
 Off the shelf client software available today – IPUnplugged, Birdstep
 Challenges- VoIP, WLAN automated logon (eg- 802.1x could solve this),
applications/OS can handle address changes

52
 Overview of Mobile IPv4 (RFC2002)
CN

5. 4.

FA HA
Internet
1. and 2. 3.
MN
 1. MN discovers Foreign Agent (FA)
 2. MN obtains COA (FA - Care Of Address)
 3. MN registers with FA which relays registration to HA
 4. HA tunnels packets from CN to MN through FA
 5. FA forwards packets from MN to CN or reverse tunnels through HA (RFC3024)

53
 Mobile IP Interworking with UMTS/GPRS
 Recommends use of FA Care Of Addresses (CoA), not collocated, to conserve IPv4 addresses

Source:
3GPP

54
Registration Process to GGSN FA
IPv4 - Registration UMTS/GPRS + MIP , FA care-of address

TE SGSN GGSN/FA Home

MT
Network
1. AT Command (APN) 2. Activate PDP
Context Request
( APN=MIPv4FA ) 3. Create PDP
Context Request
( APN=MIPv4FA )
A. Select suitable GGSN

4. Create PDP
5. Activate PDP Context Response
Context Accept (no PDP address)
(no PDP address)

6. Agent Advertisement

7. MIP Registration Request

8. MIP Registration Request

9. MIP Registration Reply

10. MIP Registration Reply

55
 Overview of Mobile IPv6
Removes need for external FA in future 3GPP systems
CN

4. 3.

HA
Internet
1. 2.
MN
 1. MN obtains IP address using stateless or stateful autoconfiguration
 2. MN registers with HA
 3. HA tunnels packets from CN to MN
 4. MN sends packets directly to CN or via tunnel to HA
• Binding Update from MN to CN removes HA from path.

56
 3G- Mobile Data Networks
To Summarise…
 Interworking different wireless access types is possible in many ways – benefits to the
end users
 Short term migration of FR and ATM over MPLS infrastructure can help cut network
and operations costs
 Mobile networks are moving to IP both at network transport and
application layer…
• IP UTRAN option – IP out to the base station site
• IP Multimedia subsystem – native IP clients in devices
• Push To Talk is a wildcard; could accelerate IP requirements in the mobile network
before 3G becomes widescale
 MPLS, QoS / DiffServ TE, IPv6 and transition techniques are key
requirements in the new mobile carrier network!

57
Thank you…!

My contact details:

Email snewstead@juniper.net
Mobile +852 6277 1812

58