1 copyright © 2003 juniper networks, inc. confidential ipv6 in the 3g network

1Copyright © 2003 Juniper Networks, Inc. CONFIDENTIAL www.juniper.net

IPv6 in the 3G network


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


IPv6 Recap:New header format

Ver.

Time toLive

Source Address

Total LengthType ofService

HdrLen

Identification FragmentOffsetFlg

Protocol HeaderChecksum

Destination Address

Options...

Ver. TrafficClass

Source Address(128 bits)

Payload Length NextHeader

HopLimit

Destination Address(128 bits)

Flow Label

IPv6 Header

IPv4Header


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

IPv6 Recap:Key changes in IPv6 header


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


General Format of Unicast Addresses

interface IDglobal routing prefix subnet 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


Configuring Interface IDs

There are several options for configuring the interface IDof an address:

• DHCPv6 (configures whole address)

• Manual configuration (of interface ID or whole address)

• automatic derivation from 48-bit IEEE 802 addressor 64-bit IEEE EUI-64 address

• pseudo-random generation

“Stateless” autoconfiguration, when combined with high-order part of the address learned via Router Advertisements


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)


Dynamic Stateless Autoconfiguration

MT BSS / UTRAN SGSN GGSN

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

2. Create PDP Context request

3. Create PDP context response (PDP address = link local address, ..)

4. Activate PDP context accept

MT extracts Interface-ID from the link local address

5. Router Solicitation

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

7. Neighbor Solicitation

8. GGSN initiated PDP context modification procedure

GGSN configured to advertise only one

network prefix

GGSN updates the SGSN and MT with the full IPv6 address


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…


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


Transition Scenario – Dual IPv4/IPv6 Stack

Dual Stackv4/v6 host

GGSN

IPv4 / IPv6 PDPContext

Native IPv4Network IPv4 Host

Native IPv6Network IPv6 Host

Dual Stack Router

Separated approach – simple and efficientPossible as mobile usually closed system environmentGGSN is a dual stack deviceCould be native IP interconnects, and also IPv4 PE and IPv6 PE (6PE))


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….


Transition Scenario – Tunneling Options

RBSGGSN

IPv6Network

IPv4Network IPv4

Network

IPv4host

IPv4host

v4/v6RoutersIPv4 PDP

Context

RBSGGSN

IPv4Network

IPv6Network IPv6

Network

IPv6host

IPv6host

v6/v4Routers

IPv6 PDPContext

Practical transition; within backbone constraints

Diagrams - Gopinath Rao Sinniah, AIMST


Network Address Translation - Protocol Translation (NAT-PT)

IPv6Network

IPv4Network

v6host.6net.com3ffe:3700:1100:1:210:a4ff:fea0:bc97

v4host.4net.org204.127.202.4

NAT-PT

DNS

IPv4 Pool: 120.130.26/24IPv6 prefix: 3ffe:3700:1100:2/64

Source = 3ffe:3700:1100:1:210:a4ff:fea0:bc97Dest = 3ffe:3700:1100:2::204.127.202.4

Source = 120.130.26.10Dest = 204.127.202.4

Source = 204.127.202.4Dest = 120.130.26.10

Source = 3ffe:3700:1100:2::204.127.202.4Dest = 3ffe:3700:1100:1:210:a4ff:fea0:bc97

Mapping Table

Inside Outside 3ffe:3700:1100:1:210:a4ff:fea0:bc97 120.130.26.10

Greater complexityLimited NAT/FW ALG support todayMust be an interim step only


QoS in the Mobile – 3G Network


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!)


QoS requirements in UE and GGSN

CapabilityUE GGSN

DiffServ Edge Function

Optional Required

RSVP/IntServ Optional Optional

IP Policy Enforcement

Point

Optional Required (*)


4 QoS classes are defined in UMTSrefer TS 23.107

Traffic class Conversational class

conversational RT

Streaming classstreaming RT

Interactive classInteractive best

effort

BackgroundBackground best effort

Fundamental characteristics

-Preserve time relation (variation) between information entities of the stream Conversational pattern (stringent and low delay )

-Preserve time relation (variation) between information entities of the stream

-Request response pattern -Preserve payload content

-Destination is not expecting the data within a certain time-Preserve payload content

Example of the application

- Voice- VoIP, video calls

- Streaming video

- Web browsing- Machine polling

- Background download of emails, non realtime video downloads

23.107


UMTS bearer attributes defined for each bearer traffic class

Traffic classConversational

classStreaming class Interactive class Background class

Maximum bitrate X X X X

Delivery order X X X X

Maximum SDU size X X X X

SDU format information

X X

SDU error ratio X X X X

Residual bit error ratio

X X X X

Delivery of erroneous SDUs

X X X X

Transfer delay X X

Guaranteed bit rate X X

Traffic handling priority

X

Allocation/Retention priority

X X X X

Source statistics descriptor

X X

Signalling indication X

Note – these map down into Radio Bearer QoS capabilities, which are similar in makeup


Value ranges for UMTS Bearer Service Attributes

Traffic classConversational

classStreaming class Interactive class Background class

Maximum bitrate (kbps)

<= 16 000 (2) <= 16 000 (2) <= 16 000 - overhead (2) (3)

<= 16 000 - overhead (2) (3)

Delivery order Yes/No Yes/No Yes/No Yes/No

Maximum SDU size (octets)

<=1 500 or 1 502 (4) <=1 500 or 1 502 (4) <=1 500 or 1 502 (4) <=1 500 or 1 502 (4)

SDU format information

(5) (5)

Delivery of erroneous SDUs

Yes/No/- (6) Yes/No/- (6) Yes/No/- (6) Yes/No/- (6)

Residual BER 5*10-2, 10-2, 5*10-3, 10-3, 10-4, 10-5, 10-6

5*10-2, 10-2, 5*10-3, 10-3, 10-4, 10-5, 10-6

4*10-3, 10-5, 6*10-8 (7) 4*10-3, 10-5, 6*10-8 (7)

SDU error ratio 10-2, 7*10-3, 10-3, 10-4, 10-5

10-1, 10-2, 7*10-3, 10-3, 10-4, 10-5

10-3, 10-4, 10-6 10-3, 10-4, 10-6

Transfer delay (ms) 100 – maximum value

280 (8) – maximum value

Guaranteed bit rate (kbps)

<= 16 000 (2) <= 16 000 (2)

Traffic handling priority

1,2,3 (9)

Allocation/Retention priority

1,2,3 1,2,3 1,2,3 1,2,3

Source statistic descriptor

Speech/unknown Speech/unknown

Signalling Indication Yes/No (9)


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 (Information in the SGSN and the GGSN PDP Contexts)'no' 'no'

Maximum SDU size 1 500 octets (Fixed value)


IP CoS BasicsKey Functions

WWRRRR

REDRED

PLP=0100%100%

PLP=1

Stream100%

• IP Flow

• IP Precedence bits, DSCP Byte

• MPLS CoS bits

• Incoming Physical Interface

• Incoming Logical Interface

• Destination IP address

• Application (stateful) etc…

Priority Priority QueuingQueuing

Traffic Traffic ClassificationClassification

& & MarkingMarking

Per-flow Per-flow Rate Rate PolicingPolicing Congestion Congestion

AvoidanceAvoidance

SSPP


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.


Real World Case Study – Customer QoS allocations

MPLS EXP Bits

Forwarding Behaviour Traffic Type Hardware Queue

Drop Probability

000 Best Effort IP Traffic(UMTS Best Effort Class)

Queue 0 -

001 Assured Forwarding 12 Queue 2 High

010 Assured Forwarding 11 3G Signalling trafficUMTS Streaming ClassUnified Messaging client

Low

011 Expedited Forwarding 1 Queue 1 High

100 Expedited Forwarding 3G AAL2 traffic(UMTS Conversational Class)

Low

101 Network Control 3 / Assured Forwarding 41

Queue 3 High


Network ControlUMTS Interactive Class

Low


High


Queue implementation on network routers

Hardware Queue

Traffic Type WRR weighting

Queue depth

Queue 0 IP traffic 60% 60 %

Queue 1 3G AAL2 traffic 25 % 10%

Queue 2 3G Signalling traffic

10 % 10%

Queue 3 Network Control 5 % 20%

Real World Case Study – Customer QoS allocations

ExpeditedForwarding(strict priority for voice)


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.


Diff-Serv-aware MPLS Traffic Engineering

Guaranteed bandwidth for MPLS• Combines MPLS DiffServ and DiffServ TE• Provides strict point to point QoS guarantees

MPLS Diff-Serv + MPLS DS-TE

Aggregated State (DS)Aggregate Admission Control (DS-TE)

Aggregate Constraint-based Routing (DS-TE)

MPLSGuaranteedBandwidth

No state Aggregated state Per-Flow state

Best effort Diff-Serv RSVP v1& Int-Serv

CoS / QoS & Forwarding


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

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


Layer 2 MigrationVC to MPLS QoS Mapping

Queues

CBR (10% bw)->CT3

VBR rt (20% bw)->CT2

VBR nrt (20% bw)->CT1

ATM Control Traffic

VPs

CBR

VBR rt(CLP0, CLP1)

ABR/UBR(CLP0, CLP1)

VBR nrt(CLP0, CLP1)

ABR/UBR (50% bw) CT0

QoS Flows Basedon EXP Bits

POS InterfaceATM Interface

PE to PE E-LSPs(PSN Tunnel)

Trunk VPN Label(Pseudo Wire)


Looking into the future

3G Release 6


3G Release 6

PSTN

InternetCorporate

IP/AAL5USIM

NodeB

BICC Circuit switchedcall control server

H.248

TDMATMIP

SIP IP MultimediaCSCF

IMS enhancements for conversational

UDP/IP or AAL2

Iu b

Iu ps

Iu cs

RTPor

AAL2

UMTS/GPRS - WLAN Interworking

Definition in R6, implementation sooner

TS 23.221

Multimedia Broadcast/Multicast Service (MBMS) – conferencing etc

Service charging enhancements


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


Service based charging and control

Timescale:

• 3GPP Release 6

• Early realization by some vendors at the GGSN

Traffic Plane Function

Gx

Online Charging System*

Service Data Flow Based

Credit Control

Based Charging Service Data Flow

Rules Function

CAMEL SCP

Gy

Rx

AF

Gq

Policy DecisionFunction Go


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


3G complimentary access technologies

3GPP Home Network

WLAN Access NetworkWLAN

UE

3GPP AAAServer

Packet DataGateway

HSS

HLR

CGw/CCFOCS

D' / Gr'WfW

o

Intranet / Internet3GPP Visited Network

3GPP AAAProxy CGw/CCF

Wireless AccessGateway

Wn

Wr/Wb Wf

Ws/

Wc

Wn

WmW

i

Wx

Sce

nari

o 3

Wg

PS Service Network


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


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


VPN / Network Level integrationeg- 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:

E Series (PE)& TunnelGateway

M Series (P)

WiFi User with native Windows Client

IPSEC / L2TP (RFC 3193)

3G and PHS users

MPLS Backbone

LACGGSN

NativeL2TP

Mobile users mapped into corporate VPNs

MPLS


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


GPRS/CDMA ExampleTelstra 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


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


• User opens up webbrowser and triesto go to Google

• Session directedto captive portalsoftware (SDX)

• Choice to entermobile phone number or username andpassword

• Mobile phonenumber entered

How it works - Step One


• One-time passwordsent via SMS touser’s mobilephone

• Received password entered into portal page

Step Two


• Upon successfulauthentication,captive portal isreleased andoriginal webdestination isloaded.

• Mini-logout window to facilitate signoff.

• Usage billed to user’s mobile phone bill once finished

Step Three


Authentication on WLAN using802.1X and EAP on 802.11 - overview

Ethernet

Access Point

RADIUSServerEthernet

EAPOW-Start

EAP-Response/Identity

Radius-Access-Challenge

EAP-Response (credentials)

Access blockedAssociation

Radius-Access-Accept

EAP-Request/Identity

EAP-Request

Radius-Access-Request

Radius-Access-Request

RADIUS

EAPOW

802.11802.11 Associate-Request

EAP-Success

Access allowedEAPOW-Key (WEP)

802.11 Associate-Response

Source: Microsoft


Internet

MPLS VPN

Premium Content

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)

802.1x AP

Policy Control

GRE, routed, DSL, FR,ATM, LL, MetroE

RadiusRelay

Bridged circuit

IDAS802.1x AP

IDAS = Integrated DHCP Access Server


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


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


802.1x EAP/SIM authentication from HLRTransparent RADIUS relay

BRAS AC, (RADIUS Relay)Authenticator

RADIUS/SS-7 GW HLR

EAPoLRADIUS

RADIUSGr Interface

DHCP Discover

Client

DHCP Request

DHCP Offer

DHCP Ack {address = End User address from GGSN}

Client - Authentication

Client – IP Address Assignment

GW HLRMAPSS7


Tight integration proposed by 3GPP

GGSNAccess Controller,

RADIUS RelayAuthenticatorRADIUS/SS-7

GW HLR

EAPoL RADIUS

RADIUS Gr Interface

Create PDP Context {IP, transparent mode APN, IMSI/NSAPI, MSISDN, dynamic address requested}

Create PDP Context Response {End User Address}

DHCP Discover

Client

DHCP Request

DHCP Offer

DHCP Ack {address = End User address from GGSN} Lease

expiration

Delete PDP Context Request

Client - Authentication

Client – IP Address Assignment

GGSN

HLR

GPRS Tunneling Protocol


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


Overview of Mobile IPv4 (RFC2002)

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)

HA FA

1. and 2.1. and 2. 3.3.

MN

CN

5.5. 4.4.

Internet


Mobile IP Interworking with UMTS/GPRS

Recommends use of FA Care Of Addresses (CoA), not collocated, to conserve IPv4 addresses

Source:3GPP


Registration Process to GGSN FA

5. Activate PDPContext Accept

(no PDP address)

4. Create PDPContext Response(no PDP address)

2. Activate PDP Context Request

( APN=MIPv4FA )

IPv4 - Registration UMTS/GPRS + MIP , FA care-of address

TE MTHome

NetworkSGSN GGSN/FA

3. Create PDPContext Request

( APN=MIPv4FA )

6. Agent Advertisement

7. MIP Registration Request

9. MIP Registration Reply10. MIP Registration Reply

1. AT Command (APN)

8. MIP Registration Request

A. Select suitable GGSN


Overview of Mobile IPv6Removes need for external FA in future 3GPP systems

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.

HA

1. 1. 2.2.MN

CN

4.4. 3.3.

Internet


3G- Mobile Data NetworksTo 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!


Thank you…!

My contact details:

Email [email protected] +852 6277 1812

1 copyright © 2003 juniper networks, inc. confidential ipv6 in the 3g network

Documents