3G Americas IPv6 LTE

8/8/2019 3G Americas IPv6 LTE

1/26

TableOfContents


2/26

3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 2

TableofContents

1. ExecutiveSummary............................................................................................................................3

2. Introduction.......................................................................................................................................4

2.1

EPSArchitecture

......................................................................................................................................

4

2.1.1 Simultaneousdualstacksupport.......................................................................................................5

2.1.2 Addressassignmentmechanisms......................................................................................................6

2.1.3 EvolvingpacketcoretoEPCandIPv6................................................................................................7

3. VoiceCoreNetwork............................................................................................................................8

3.1 IPAddressUsageintheDistributedMSC...............................................................................................8

3.1.1 MSCtoSS7NetworkSIGTRAN........................................................................................................9

3.1.2 MSCServertoMediaGatewayMcinterface................................................................................11

3.1.3 MSCtoRNCforUMTSAccesssupportIuCSInterface.................................................................13

3.1.4 MSCtoMSCInterfaces....................................................................................................................16

3.1.5 SIPI..................................................................................................................................................18

3.2 MigratingtheVoiceCorefromIPv4andIPv6.......................................................................................18

4. ImpactoftheIntroductionofIPv6onSecurityinUMTS....................................................................19

4.1 IPv6SecurityIssuesOverview...............................................................................................................19

4.1.1 SecurityissuescommontoIPv4andIPv6........................................................................................19

4.1.2 SecurityissuesinvolvedintransitiontoIPv6...................................................................................20

4.1.3 SecurityissuesspecifictoIPv6.........................................................................................................21

4.2 OverviewofUMTSSecurityandIPv6...................................................................................................23

4.2.1 IPv6ImpactstoUMTSEndUserSecurity.........................................................................................23

4.2.2 IPv6ImpactstoUMTSPacketNetworkSecurity..............................................................................23

4.3 IPv6ImpactsonLTESecurityImplementation.....................................................................................24

4.4 IPv6SecurityRecommendations..........................................................................................................24

5. Conclusions......................................................................................................................................25

6. Acknowledgements..........................................................................................................................25

7. References.......................................................................................................................................25

8. Glossary...........................................................................................................................................26


3/26


1. EXECUTIVE SUMMARY

As the wireless networks grow and evolve, the dependency on IP addresses becomes a vital

ingredientto

rolling

out

services.

At

the

same

time

IPv4

addresses

are

being

depleted,

always

on

services(SIPbasedapplications)arealreadybeingdeployedatanincreasingrate;hence,theurgency

tomovetoIPv6continuestobeamajorissueforoperatorsandvendorsinthewirelessindustry.

ThepurposeofthispaperistobuildontheIPv6recommendationspresentedinthefirstiterationof

3GAmericasIPv6WhitePaperpublishedin2008. Thefocusofthispaperincludescommonareasof

interestthatwillaffectinteroperabilityandotherappropriateissues. Thispapercoversthefollowing

areas:

TheevolutiontotheEvolvedPacketCore

Assess

impact

of

IPv6

to

existing

Voice

Core

EnsurenetworkSecurityduringtransitiontoIPv6


4/26


2. INTRODUCTION The Evolved Packet Core is the mobility core solution associated with the Evolved Universal

Terrestrial Radio Access Network (EUTRAN),whichwas formally known as Long Term Evolution

(LTE).EPCandEUTRANaredefinedby3GPPsRelease8specifications, inparticular[1],[2]and[3].

Thecombination

of

EUTRAN

and

EPC

is

called

Evolved

Packet

System

(EPS).

2.1 EPS ARCHITECTURE

TheEPSarchitectureisdepictedinthefollowingfigure.

Figure1:EvolvedPacketSystem

EUTRAN introduces a new radio interface technology. A base station that supports this radio

interfacetechnologyiscalledEvolvedNodeB(eNB).

TheEPCarchitectureconsistsofaMobilityManagementEntity(MME)andtwogateways,theServing

Gateway(SGW)andthePacketDataNetworkGateway(PDNGWorPGW).

TheMME is responsible for controlplane functions:authentication,mobilitymanagement,paging

and signaling security.Manyof the functionsandprotocols supportedby theMMEare similar to

thosesupportedbySGSNsinUMTSdeployments.IncontrasttotheSGSN,theMMEsolelydealswith

control

protocols.

User

plane

traffic

flows

directly

between

the

eNB

and

the

gateways.

Thetwogatewaysmaybecombined inasinglenetworkelement.InthecasethatSGWandPGW

areseparatenetworkelements, thereare twooptions for theprotocolusedbetween them:GPRS

TunnelingProtocol(GTP)andProxyMobileIPv6(PMIPv6).


5/26


2.1.1 SIMULTANEOUS DUALSTACKSUPPORT

Similar to the concept of PDP Context, which is defined in 3GPPs R7 specifications, the R8

specifications identify EPS bearers. An EPS bearer is a logical connection between a UE and a

gateway,associatedwithaspecificQoSClass.AnEPSbearercancarrymultipleServiceDataFlows

(SDF),as

long

as

these

SDFs

belong

to

the

same

QoS

class

IncontrasttothePDPContextdefinition in3GPPR7,anEPSbearercancarrybothnative IPv4and

IPv6 traffic. Therefore, a UE can support simultaneously an IPv4 and an IPv6 stack while being

connectedthroughasingleEPSbearer.

Inaprevious3GAmericaswhitepaperonIPv6([4]),itwasarguedthatinUMTSdeployments,support

ofsimultaneousdualstackwasimpractical,becausethenumberofPDPContextthatwouldneedto

be setupwouldbeunacceptablyhigh. SinceEPCallowsboth IPv4and IPv6 trafficona singleEPS

bearer,supportofsimultaneousdualstackinEPCdoesnotsufferfromthesameproblem.

Ofcourse,

allocating

both

IPv6

and

IPv4

addresses

to

adevice

does

not

solve

the

problem

of

IPv4

exhaustion.AserviceprovidermaythereforedecidetoassignonlyIPv6addressestocertaindevices,

evenwhenthedeviceisabletosupportIPv4andIPv6simultaneously. Inthatcase,NATPT(seeRFC

2766) or IPv6toIPv4 httpproxy functionalitymay be required to connect these IPv6onlydevices

with legacyIPv4endpoints.Suchadecisionneedscarefulconsiderationandthe issues identifiedin

RFC4966(NATPTIssuesAnalysis)needtobetakenintoaccount.

Note that the 3GPP R8 specs also provide updates to UMTS specifications. An R8based UMTS

networkcancarrybothIPv4andIPv6trafficoverasinglePDPContext.


6/26


2.1.2 ADDRESSASSIGNMENT MECHANISMS

AUserEquipmentdevice(UE)obtainsanIPaddressinoneoftwoways:

- aspartoftheattachmentprocedure

- viasseparateassignmentprocedure,suchasDHCPorIPv6StatelessAddress

Autoconfiguration

Theattachmentprocedureisdepictedinthefollowingfigure:

Figure2:Attachmentprocedure

Theattachmentprocedureconsistsofthefollowingsteps:

1. The User Equipment (UE) requests attachment by sending amessage to theMME. This is

followedbyanauthenticationprocedurethat involvestheHSS.Aspartofthisprocedure,the

HSSsendssubscriptiondataassociatedwiththeusertotheMME.

2. TheMME is,witha fewexceptions, responsible forselecting theServingandPDNGateways

thatwillbeusedforthisUE.Itsendsarequestfortheestablishmentofthedefaultbearerto

theSGW,whichforwardsittothePGW.Thismessageexchangeresultsintheestablishment

ofaGTPtunneloraMobileIPtunnelsegmentbetweenSGWandPGW.Thissegmentremains

up,aslongastheuserisattached,evenwhentheUEenterstheidlestate.

3. Asalaststep,theMMEorchestratestheestablishmentoftheGTPtunnelsegmentbetweenS

GWand

eNB

and

the

(default)

radio

bearer

between

eNB

and

UE.

The

bearer

between

SGW

andUE is torn downwhenever theUE goes to idle state. If the SGW receives IP packets

destined fortheUEwhile it is in idlestate,theSGWtriggerstheMMEwhichstartsapaging

procedure.

In the case IP addressassignment ispartof theattachmentprocedure, thePGWallocatesan IP

addresstotheUEaspartofstep2.ThisaddressisconveyedtotheUEintheGTPcontrolmessages

thatareusedtoestablishtheEPSbearerinstep3.


7/26


Onceadefaultbearer isestablished (withorwithout IPaddressassignment), theUE canperform

DHCPorIPv6StatelessAddressAutoconfiguration(SLAAC)toobtainanIPaddress.Thus,forexample,

aUEcouldobtainanIPv4addressaspartoftheattachmentprocedureandanIPv6addressthrough

anadditionalIPv6SLAACprocedure.

2.1.3

EVOLVINGPACKET

CORE

TO

EPC

AND

IPV6

Introduction of LTE requires new or upgraded NodeBs and new mobility gateways in the core

network.Manyserviceproviders,however,willgraduallyupgradetheirnetworkstoLTE.Therefore,

LTEandUMTS(andprevioustechnologies)willbedeployedsimultaneously.

ThefollowingfigureshowshowLTEandUMTSnetworksinterface.

Figure3:CombinedLTEandUMTSnetworkarchitecture

WhenaUE,afterattaching throughanLTE radio link,movesoutof the reachofLTEeNBs, itmay

havetofallbacktoUMTS.ThehandovertoUMTSisorchestratedbytheMME,whichinterfaceswith

thetargetSGSN.ThePDPContextisroutedviatheSGSNtotheSGWtowhichtheUEwaspreviously

connected.

If theUE isadualstackdevicewith its IPv4and IPv6stacksimultaneouslyactive,ahandovermay

haveimpactonitsoperations.IftheUEishandedovertoanR8compliantUMTSnetwork,thereare

noconsequences,astheR8PDPContextcancarryboth IPv4and IPv6traffic.However, iftheUE is

handedover to anR7compliantUMTSnetwork (which is themore likely scenario), thisdoesnot

work,sinceanR7PDPContextcarrieseitherIPv4trafficorIPv6traffic,butnotboth.

3GPPstandards

specify

aone

to

one

mapping

between

EPS

bearers

and

PDP

contexts.

This

implies

thatanoperatoreitherneedstoupgradeallSGSNs(connectedtotheEPC)toRel8,ordisabledual

stackoperationovertheEPSnetwork.Inthe lattercase,aUEthatrequestsdualstackoperationat

attachment to the EPS network will only receive a singlestack bearer, say for IPv4, and it will

subsequentlyneedtoinitiateasecondbearerestablishmenttowardsthesameAPNforIPv6.


8/26


3. VOICECORENETWORKVoicetelephonyservicesina3GPPnetworkaretraditionallyprovidedbyaMobileservicesSwitching

Centre(andsupportinginfrastructure)and/oranIPMultimediaSystem.

Asthe

name

implies,

IP

Multimedia

Subsystems

(IMS)

rely

heavily

on

IP

protocol.

Per

3GPPP

standards,IMSequipmentshouldbedeployedusingIPv6therebyavoidingtheneedforafutureIPv4

toIPV6migration.

WhereasnewIMSequipmentwilltypicallybedeployedwithIPv6,existingvoicecoreequipmentwill

stillbeutilizing IPv4. Since theMSC is at theheartof any existing 3GPP voice core, this section

focuses on the use of IP in the Mobileservices Switching Centre (MSC). As part of the MSC

discussion,IPinterfacestosubtendingvoicecorenetworkelementsarealsocovered.

3.1 IP ADDRESSUSAGE IN THE DISTRIBUTED MSC

The Mobileservices Switching Centre (MSC) performs all CS domain switching and signalling

functionsforGSMandUMTSmobilestations located inaspecificgeographicalarea. TheMSCcan

beimplementedinanintegratedplatformorintwodistinctphysicalentities.

WhendividedintotwophysicalentitiestheMSCconsistsofanMSCServer,handlingonlysignalling,

andaMGW,handlinguserdata. Thisarchitectureofdividing the signalling server from thedata

planeissometimesreferredtoasadistributedMSC.

Figure4. GSM/UMTSVoiceCorewithaDistributedMSC

STP HLR

NodeB

BTS

BSC

BTSBaseTransceiverStation

BSCBaseStationController

HLRHomeLocationRegister

MSCMobileSwitchingCentre

MSCSMSCServer

Distributed MSC

MSCS

MGW

TCUBTS

RNC

MSCS

Distributed MSC

MGW

NodeB

SIGTRANorSS7

Network

Mc

(H.248)

SIP-I or

Nc

Iu-CSMc

(H.248)

A Interface


9/26


Dependentonthevendor implementation,thedistributedMSCmaybeenhancedtofunction inan

IMS environment as a Telephony Application Server (TAS), MGCF/IMMGW, IMSSF, MRF, MSC

enhancedforICS,MSCenhancedforSRVCCetc.,ormaybeextendedtoserviceSIPuserequipment

directly.

Forinterconnect,

adistributed

MSC

will

typically

utilize

amix

of

packet

or

cell

based

protocols

including IP and/or ATM. Since IP interfaces in a distributedMSC environment are generally a

supersetofanintegratedMSC,thispaperassumesadistributedMSCasthereferencepoint.

EveryinstanceofanIPaddressmustbeconsideredwhenmigratingfromIPv4toIPv6oroperatingin

a dualstack environment. The following subsections identifywhere IP addresses are typically

utilizedwithinthedistributedMSC.

3.1.1 MSC TO SS7 NETWORK SIGTRAN

InaGSM,UMTS,or4Gnetwork,theMSCmayconnecttootherSSPs,STPs,orSCPs(suchastheHLR)

viaatraditionalSS7protocolstackorviaSIGTRAN.

SIGTRAN, as defined in RFC 2719 and RFC 4166, is a set of protocols that allow circuit switch

telephonymessages,suchasMediaGatewaycontrolandSS7messages, tobe reliably transported

overanIPnetwork. SIGTRANconsistsofthreecomponents: astandardIPlayer,anSCTPlayer,and

useradaptationlayer(s).

When migrating networks from IPv4 to IPv6, all three of the SIGTRAN components must be

considered. Components above SIGTRAN are also relevant when migrating from IPv4 to IPv6;

however,discussionforupperlayersignalingcomponentsisreservedforsubsequentsections.

SignalingProtocols

(maycontainembeddedIP@)

UserAdaptationLayer: M2PA,M2UA,M3UA,SUA

(SUAmaycontainembeddedIP@)

SCTP(embeddedIP@)

IP

L1

Figure5.

SIGTRAN


10/26


3.1.1.1 SCTP

TomeettheperformancerequirementsofatelephonynetworkinanIPenvironment,SIGTRANuses

theSCTPprotocoldefined inRFC3257. SCTP isaconnectionorientedprotocolthatoffersmultiple

servicesincluding:Multihoming,Multistreaming,Heartbeat,amongothers.

Whenmigrating from IPv4to IPv6,ofparticularnote isSCTPsmultihomingservice. Multihoming

allowsanassociationtosupportmultiple IPaddressesatagivenendpoint. Theuseofmorethan

one IPaddressatanendpoint increasesnetworkrobustnessbyprovidinganalternatepathforre

transmissionsorallowingreroutingofpacketsduringfailurescenarios.

AspartofSCTPsmultihomingservice,SCTPcontrolpacketscarryembeddedIPaddressesduringthe

connectionsetupprocess. ThisallowstheendpointstoexchangeIPaddresslists.

Although SCTPsmultihoming service canprovide increasednetwork resiliency, the embedded IP

addresses exchanged during connection setup complicate the use of aNATPT and the potential

interworking

between

IPv4

and

IPv6

network

elements.

AsdiscussedinRFC4966section2.6[5],useofNATPTwithSCTPshouldgenerallybeavoided.

3.1.1.1 USERADAPTATION(UA)LAYERS

AbovetheSCTPlayer,SIGTRANoffersmultipleuseradaptationlayersincluding:M2PA,M2UA,M3UA

andSUA. TheuseradaptationlayersmimictheservicesofthelowerlayersofSS7andISDN.

Among the adaptation layers,M3UA and SUA are IP aware and require special attention when

migratingfromIPv4toIPv6.

3.1.1.2.1 M3UA

M3UAisdefinedinRFC4666. M3UAisIPawareinthatittranslatespointcodestoIPaddressesand

viceversausingaRoutingKey. However,M3UAdoesnotexchange IPaddress informationwithin

any of its messages. Rather, M3UA relies on point codes to identify end points and defines

boundariesbetweenitselfandMTP3,SCTP,andLayerManagement.

BecauseM3UAdoesnotexchangeIPaddressinformationwithinanyofitsdefinedmessages,address

translatorswilloperatetransparentlywithinthenetworkwithrespecttoM3UAthereisnoneedfor

an

application

layer

gateway

for

M3UA.

Still,

IPv4

and

IPv6

must

be

considered

at

the

M3UA

end

points:attheIPprotocolportandwithintheM3UAsoftware.

3.1.1.2.2 SUA

SUAisdefinedinRFC3868. SUAsupportsbothconnectionlessandconnectionorientedoperations.

SUAmaydeterminethenexthopIPaddressbasedonGlobalTitleinformation(e.g.E.164number),IP

addressorpointcodecontainedinthecalledpartyaddress. Accordingly,someSUAmessagessuchas


11/26


CLDT (Connectionless Data Transfer), CLDR (Connectionless Data Response), Connection Request

(CORE),ConnectionRefused (COREF),andCOAK (ConnectionAcknowledge)mayembed IPaddress

informationasaparameter.

3.1.2 MSC SERVER TOMEDIA GATEWAYMC INTERFACE

InadistributedMSCenvironment,theMSCServerusesH.248ontheMcinterfacetocontrolaMedia

Gateway. Whenplanningamigration from IPv4to IPv6ontheMc interface,aminimumofthree

layersmustbeconsidered: thenetwork/transportlayer,theSCTPlayer,andtheH.248layer.

3.1.2.1 NETWORK/TRANSPORTLAYER

Atthenetwork/transportlayer,the3GPPstandardsallowforthefollowingMcinterfaceoptions:

1.) AmixedIP&ATMconnectionH.248/M3UA/SCTP/IP/AAL5/ATMasanexample

2.)

Apure

IP

connection

H.248/M3UA/SCTP/IP

with

M3UA

as

an

optional

layer.

3.) ApureATMconnection H.248/MTP3b/SSCF/SSCOP/AAL5/ATM

ThefirsttwointerfaceoptionsbothutilizeIPandmustbeconsideredwhenmigratingfromIPv4and

IPv6. ThethirdoptioninvolvesnoIPaddressingandisthereforeexcludedfromthispaper.

In the first twooptions, theMc interface IP connectionsmaybeeither IPv4or IPv6.Thediagram

belowprovidesaprotocol stack for theMc interface in thepure IPconnectionandmixed IP&

ATMconnectioncases. NotethattheM3UAlayerisanoptionallayerinthepureIPcase. [3GPP

TS29.232V4.17.0(200706)page11].

H.248(embeddedIP@)

M3UA (optionallayer)

SCTP(embeddedIP@)

IP

L1

Figure6.


12/26


3.1.2.2 SCTPANDM3UA

TheMc interfaceuses the SCTPprotocol andmayoptionallyuse theM3UA layer asdiscussed in

section6.1.1. TheSCTP layerembeds IPaddressesduringconnectionsetupwhichcomplicatesthe

useofNATPTforIPv4toIPv6migrations. FormoreinformationonSCTPandM3UArefertosection

6.1.1.

3.1.2.2 H.248LAYER

Above the network/transport and SCTP layers, and within H.248 layer, IP addresses are also

embedded.

For example, during a call setup across an IP backbone, theMSC serverwill send anH.248 Add

requesttothelocalMGWtocreateacontext. ThelocalMGWrespondstotheMSCserverwithan

H.248 Replymessage. Inside the Replymessage is the local descriptorwhich contains the local

MGWsbearer IPaddress. The localdescriptormakestheMSCserverawareofthe IPtermination

pointforwhichitmustdirecttheincomingIPmediastream.

Similarly, the remoteMGWprovides itsbearer IPaddress to its controllingMSC serverwithin the

H.248messaging. ThisIPaddress(partoftheRemoteDescriptor)isrelayedtothelocalMGW. The

localMGWusesthisRemoteDescriptorIPtoappropriatelyaddresstheoutgoingmediastream.

ThisexchangeofIPaddresseswithintheH.248layerallowsforthedynamicswitchingofVoIPpackets

betweenMGWcontexts.

Asmentionedintheexampleabove,H.248commandsmayspecifyanIPv4orIPv6addressanywhere

aLocal,Remoteand/oraLocalControlDescriptorareutilized[ITUTRec.H.248.1(09/2005)Annex

C].

3.1.2.3 H.248.37

BecauseH.248messagingbetweenthecallserverandMGWeffectivelyrelaysIPaddressinformation

betweenMGWs,H.248byitselfdoesnotallowforNAPTtraversalbetweenMGWs. Toovercomethis

limitation,H.248.37wasdeveloped.

H.248.37allowstheMSCServerto instructaMGWto latchtoanaddressprovidedbyan incoming

InternetProtocol (IP)applicationdata stream rather than theaddressprovidedby the call/bearer

control.This

enables

the

MGW

to

open

apinhole

for

data

flow.

It

also

allows

the

MGW

to

ignore

theRemoteDescriptorMGWIPaddressinformationprovidedintheH.248messaging.

When the NAPT parameter on a termination/stream is set to LATCH, the MGW ignores the IP

addresses received in the RemoteDescriptor. Instead, theMGWwilluse the source address and

sourceport from the incomingmedia stream (i.e., from theother termination)as thedestination

addressanddestinationportoftheoutgoingapplicationdata.


13/26


Ignoring theRemoteDescriptor IPaddresses in theH.248messaging,makes IPaddress translation

within thenetwork transparent tobasicMGWoperations. Thus,H.248.37couldbeused toallow

interworkingofanIPv4MGWwithanIPv6MGW,allowtwoIPv4MGWstocommunicateacrossan

IPv6backbone,and/orhelpfacilitateanIPv4toIPv6migration.Still,H.248.37hasaseriouslimitation

asdiscussedbelow.

H.248.37assumes that themedia streamhas alreadybeen establishedandVoIP traffic is already

flowingbetweenMGWs. ForH.248.37andNATPTtobeeffectiveinallowinginterworkingofIPv4to

IPv6capableMGWs,themediastreammustfirstbeestablishedwithan IPaddressprovided inthe

H.248messaging. This implies thateither the call server includesanApplication LevelGateway

ControlFunction(ALGCF)tocontroladynamicNAT[6],oritimpliesthatstaticaddresstranslationis

usedbetweentheMGWs.

3.1.3 MSC TO RNC FOR UMTS ACCESSSUPPORT IUCS INTERFACE

The

UMTS

access

network

is

connected

to

the

MSC

via

the

Iu

CS

interface.

Standards

allow

for

Iu

CS

tobetransportedoverATMorIP.Witheithertransportoption,IuCSoverIPorIuCSoverATM,the

IuCSinterfacecanbelogicallydividedintothreeareas:

1. ControlPlane

2. BearerControlPlane

3. Bearer(orUser)Plane

3.1.3.1 IU CS CONTROL PLANE

TheIuCScontrolplanecarriesRANAPsignalingbetweentheUTRANandMSCS.


14/26


3.1.3.2 IU CS OVERIP

For the IuCSover IP controlplane, three layersmustbe consideredwhenmigrating from IPv4 to

IPv6:the

network/transport

layer,

the

SCTP

layer,

and

the

RANAP

layer.

Notice

the

protocol

stack

showninthefigurebelow(3GPPTS25.412section5.2.3).

RANAP(embeddedIP@)

SCCP

M3UA

SCTP(embeddedIP@)

IP

DataLinkLayer(e.g.GigE,FE)

PhysicalLayer

Figure7.

Asdiscussedinsection6.1.1,SCTPoffersamultihomingservicewhichprovidesredundancybetween

twoSCTPendpoints. Aspartofmultihoming,SCTPmessagesexchangeIPtransportlayeraddresses

duringconnection

setup

[8].

IntheRANAPlayer,transportlayerIPaddressareexchangedbetweentheRNCandMGWusingthe

Prepare_IP_Transportprocedure.

InthePrepare_IP_Transportprocedure,theMSCserverrequeststheMGWtoprovide IPTransport

AddressandanIuUDPPortandprovidestheMGWwiththebearercharacteristics.AftertheMGW

has repliedwith the IPaddressandUDPPort, theMSC server requestsaccessbearerassignment

usingtheprovidedIPaddressandUDPPortinaccordancewith3GPPTS25.413.

TheIPaddressesandUDPPortsoftheMGWandtheRNCareexchangedviatheRANAPprocedures.

Ifthe

bearer

transport

is

IP

and

IuUP

mode

is

Transparent,

when

the

MSC

receives

the

RANAP

RAB

assignment response it sends the RNC IP address and UDP Port to the MGW Access bearer

terminationusingtheModify_IP_Transport_Addressprocedure.

IfthebearertransportisIPandIuUPmodeisSupport,theMGWusesthesourceIPaddressandUDP

Portof the IuUP Initpacket received from theradioaccessnetworkasthedestinationaddress for

subsequentdownlinkpackets. TheRNC isalreadyawareof theMGW IPaddressbecause theCall

ServerprovidestheRNCtheMediaGatewaysIPaddressintheRABAssignmentRequestmessage.


15/26


3.1.3.3 IU CS OVERATM

IntheIuCSoverATMconfiguration,thecontrolplaneusesbroadbandSS7signalingwhichdoesnot

requireIP.

It

should

be

noted

however

that

some

vendors,

in

particular

those

who

have

an

all

IP

MSC

server,

mayconvertM3UA/IPtobroadbandSS7inaSignalingGateway(SGW)orMGW. Becausethistypeof

implementation isvendor specific, IPv4 to IPv6migrationconcerns shouldbeworkeddirectlywith

thevendorfortheIuCSoverATMinterface.

3.1.3.4 IU CS BEARER CONTROLPLANE

ThebearercontrolplaneisonlyapplicableforIuCSoverATM,anddoesnotneedtobeconsidered

whenplanninganIPv4toIPv6migration.

3.1.3.5

IU

CS

BEARER

(OR

USER)

PLANE

TheIuCSbearercanutilizeATMorIPatthetransportlayer. InanATMconfiguration,thebeareris

transportedoverAAL2virtualcircuitconnections. Inan IPconfiguration,bearer istransportedover

RTP/UDP/IP[9].

AprotocolstackoftheIuCSBearerusingIPtransportisprovidedbelow.

RTP

UDP

IP

DataLinkLayer(e.g.GigE)

PhysicalLayer

Figure8.

MSCtoTCU/BSCforGSMAccesssupportAInterface

At the timeof thewritingof thisdocument, standards forAinterfaceover IP standardswere still

beingdevelopedby3GPP. Previously,theA interfaceimplementationdidnotutilizeorsupportIP.

AInterfaceisthereforeexcludedfromthispaper.


16/26


3.1.4 MSC TO MSC INTERFACES

3.1.4.1 BICCARCHITECTURE

Bearer Independent Call Control (BICC) is a signaling protocol used to support narrowband ISDN

serviceindependent

of

the

bearer

technology

and

signaling

message

transport

technology

used.

BICCwasdeveloped tobe interoperablewithany typeofbearer, suchasATM, IP,andTDM.The

followingsectionfocusesonBICCwhenusedinanIPnetwork.

ThreeinterfacesaredefinedinaBICCarchitecture:

NbMGWtoMGW

Mc (G)MSCServertoMGW

Nc MSCServerto(G)MSCServer

3.1.4.2 NB INTERFACE

TheNb interfacetransportsbearer informationbetweenMGWs.The3GPPstandardssupportTDM,

IP,andATMtransportontheNbinterface. TheprotocolstackoftheNbinterfaceusingIPtransport

isprovidedbelow:

G.711 UMTSAMR/AMR2

NbUP[29.415]

RTP[RFC3550]

UDP[RFC768]

IP

L1

Figure9.


17/26


3.1.4.3 TUNNELING ACROSSTHEMC ANDNC INTERFACES

Because BICC is Bearer Independent it utilizes other protocols for exchanging media stream

characteristics.

In

an

ATM

network,

BICC

uses

ALCAP/Q.2630

signaling

for

bearer

control

of

Nb.

The

ATM

bearer

controliscarrieddirectlybetweenMGWsalongsidethebearertraffic.

In IPnetworks, the IP bearer control isnot carrieddirectly betweenMGWs alongside the bearer

traffic.Nbbearercontrol istunneledbetweenMGWsvia theMcandNc interfacesusing IPBCP (IP

BearerControlProtocolQ.1970). ThefigurebelowillustratesthepathforIPBCP.

Figure10.

IPBCP protocol allows the establishment and modification of IP bearers on theMGWs. IPBCP

exchangesmediacharacteristicssuchasportnumbersand IPaddressesofthesourceandsinkofa

mediastream.Theexchangeof informationwith IPBCP isdoneduringBICCcallestablishmentand

afteracall

has

been

established.

IPBCP

uses

asubset

of

the

Session

Description

Protocol

(SDP)

definedin3GPP29.414toencodetheinformation.

Although the transport layers for theMc andNc interfacesmay consistof variousprotocols, the

figurebelowprovidestheprotocolstackforIPBCPwhenIPisthetransporttype.

MGW

Nb

MSCMSC

MGW

McMc

Nc

IPBCP


18/26


IPBCP(embeddedIP@)

BCTP[Q.1990]

BICC

IP

L1

Figure11.

3.1.5 SIP I

SIPIisanextensionoftheSIPprotocol. SIPIisusedtotransportISUPmessagesacrossaSIPnetwork

asattachmentstotheSIPmessages.

SimilartoBICC,SIPIprovidesamechanismbywhichtwoMSCscanbeconnectedoveranIPnetwork.

ThoughBICCwas the firstprotocolstandardizedby3GPP for interMSCVoiceover IPconnectivity,

BICCislimitedtooperationinaGSM/UMTSenvironment. Thus,manyoperatorshaveoptedtouse

SIPIforMSCinterconnect.

To exchange media stream information between MGWs, SIPI utilizes the Session Description

Protocol(SDP).

3.2 MIGRATING THE VOICE CORE FROMIPV4 ANDIPV6

Asdescribed in thepreceding section,migrationof the voice core from IPv4 to IPv6 isa complex

activityrequiringconsiderationofnumerousprotocolsandlayersabovetheIPnetworklayer.

Oneoftheprimarydriversforamigrationfrom IPv4toIPv6 istoalleviateIPaddressconsumption.

SincethemajorityofIPaddressesareconsumedbyenduserdevices,andafullmigrationofthevoice

corefromIPv4toIPv6ishighlycomplex,inmostcasesitwillnotbefeasibletomigrateanoperators

entire3GPPvoicecore to IPv6. Instead, it ismuchmoreprobablethatamigrationof IPv4to IPv6

withinthe

voice

core

will

only

be

targeted

at

specific

interfaces.

Forexample,anoperatormayopttoleaveallIuCS/IPandintracallserverMGWtoMGWtrafficas

IPv4whilemakingall intercall serverMGW toMGW traffic IPv6.This typeofarchitecturewould

allow thenetworkoperator toonly requiredual stack capableMGWson thenetworkbound (vs.

access)interfacesandwouldavoidtheneedforanIPv6capableRNC.


19/26


4. IMPACT OF THEINTRODUCTION OF IPV6 ONSECURITY IN UMTS IPv6currentlyhas relatively limiteddeployments, thus fewvulnerabilitieshavebeenexploited. As

adoptionexpands,likeinIPv4,attacksontheprotocolwillemergeunlesssufficientlyprotected. IPv6

security issueshave implicationsdirectly for the IP layer,and indirectly forapplicationsupportand

thelink

layer.

And

these

security

issues

can

be

examined

with

respect

to

end

to

end

security,

end

togatewayandgatewaytogatewayconnections. TheimplementationofIPv6requiresextensionsto

theexistingsecuritypolicyaswellas introducingnewsecuritypoliciesspecifictoIPv6. Thesecurity

concerns (threatsandvulnerabilities)andspecific solutionscomprise those issuescommon to IPv4

andIPv6,thosesecurityissuesspecifictothetransitiontoIPv6,andthosespecifictoIPv6. IPv6must

bemanagedtoprovideanequivalentlevelofsecurityasisprovidedforIPv4.

Thefollowingsubsectionprovidesaconcisesummaryofsecurity issuesrelatedtoIPv6. Sections0

and0provideanoverviewofhowtheseissuesimpactordonotimpact3GPPandLTE.

4.1

IPV6SECURITY

ISSUES

OVERVIEW

4.1.1 SECURITYISSUES COMMON TO IPV4AND IPV6

ManysecurityissuesandsolutionscommoninIPv4implementationsprojectforwardintoIPv6.

FirewallsarerequiredtobeupdatedtosupportfirewallrulesspecifictoIPv6,aswellasupdatesfor

SSH(SecureShellprotocolforremotelogin/filetransfer).

IPsec,AH (authenticationheader)andESP (encapsulatingsecuritypayload) functionessentially the

sameforbothIPv4andIPv6. IPseccanbeusedtosupporttheroutingprotocols,RoutingInformation

Protocol(RIP)

&

Open

Shortest

Path

First

(OSPFv3),

ifrequired.

The

Virtual

Private

Network

(VPN)

model inusemustbeupdated toadd IPv6 support. The IPv6 configuration in IKEv2 is stillbeing

worked on in the IETF and currently is defined with limitations with respect to IKEv2 and IPv6

functionality. RefertoIETFdraft,IPv6ConfigurationinIKEv2.

ForDomainNameSystem(DNS)andDNSSECthesamesecurityconcernsapplytoIPv6asIPv4. There

is no new impact to Transport Layer Security (TLS) functionality with the introduction of IPv6.

Applicationlayer attacks have the same vulnerabilities. No new security concerns for Border

GatewayProtocol(BGP)areintroducedwithIPv6.

UpdatesarerequiredtosupportIPv6for:IntrusionDetectionSystems(IDS)andIntrusionPrevention

Systems(IPS).

With respect to the benefits of Network Address Translation (NAT), IPv6 provides alternative

mechanisms. NAT isoftenusedtoperformthetasksofafirewallbyestablishingdynamicstatefor

connections to protect againstunauthorized, ingress traffic, and also to perform topology hiding.

NATshouldnotbeusedasasubstituteforafirewall. NATisnotinvulnerableandoncecompromised

itiseasyforattackerstoscantheprivateaddressspaceontheinsideoftheNATforopenports. It


20/26


shouldalsobenotedthatNATcomplicatestheuseofIPsecforendtoendencryption. Forexample,

thereisadditionaloverheadrequiredtosupportUDPencapsulationandNATkeepalivemessaging.

IPv6providesseveralmechanismstosupporttopologyhiding. ThesizeofasingleIPv6subnetmakes

ping sweepsandport scanning fornetworkvulnerabilitiesunprofitable. Simplyassigningmultiple

IPv6addresses

to

ahost,

difficult

in

IPv4

due

to

the

limited

address

space

and

on

some

hosts

not

supported, can aid in concealing the nodes in the internal network. Unique Local IPv6 Unicast

Addressingcanbeusedforaddressallocationwithinasite thistrafficisforcommunicationwithina

siteandshouldneverberoutedoutsidetheinternalnetwork. UntraceableIPv6addressing(random

prefixallocationwithina subnet)canbeused toconceal thesizeand topologyof thenetwork,as

opposed tosequentialnumberingwithina subnet,commonlyemployed in IPv4due to the limited

numberofavailableaddresses.

RefertoLocalNetworkProtectionforIPv6(RFC4864),foramorecompleteunderstanding.

4.1.2

SECURITY

ISSUES

INVOLVED

IN

TRANSITION

TO

IPV6

TheintroductionofIPv6hasimpactsonsecurityrelatingtothetransitionmechanismsofdualstack,

tunneling,andtranslation.

Dualstack

Active IPv4onlynetworksmayalreadybevulnerable to IPv6attacks if IPv6capabledevices (dual

stack) are included. The security policy should determinewhether IPv6 packets in the IPv4only

network should be blocked as IPinIP packets (41 in protocol field of IPv4 header) thatmay be

concealingIPv6inIPv4attacks.

RefertoRFC4942,IPv6Transition/CoexistenceSecurityConsiderations,foracompletedescriptionof

issueswithsupportingadualstackenvironment.

Tunneling

There are several tunneling mechanisms proposed to allow IPv6 traffic to traverse IPv4only

networks. Some are based on static configuration and some support automatic tunneling. In

general,statictunnelingismoresecurethanautomatictunneling,butdoesnotscalewell. Tunneling

mechanisms thatareconstructedusing IPinIP,as6in4 staticor6to4automatic tunneling,cannot

traverse a NAT when port translation is required (NAPT). Many of the automatic tunneling

mechanisms,as

6to4,

ISATAP

and

Teredo,

use

embedded

IPv4

addresses

within

the

128

bits

of

the

IPv6address.

Dependinguponthetunnelingmechanismsemployed,filteringmayberequiredatfirewallstoblock

IPinIP or IPv6 addresseswith embedded IPv4 addresses. Embedded addressingmay introduce

vulnerabilitiesthatareabletotraversefirewalls.


21/26


Refer to IPv6OperationsandSoftwires IETFworkinggroups foradditionalRFCsanddraftson IPv6

securitymechanismsrelatedtotunneling,www.ietf.org.

Translation

Referto IETFdraft,AComparisonofProposalstoReplaceNATPT,forcurrentstatusofpossibleco

existencemechanisms.

RefertothefollowingreportsforamorecompleteunderstandingofIPv6securityissues:

NorthAmericanIPv6TaskForce(NAv6TF)TechnologyReport,

http://www.6journal.org/archive/00000287/01/nav6tf.analysis_ipv6_features_and_usabilit

y.pdf

IPv6andIPv4ThreatComparisonandBestPracticeEvaluation,

http://www.seanconvery.com/v6v4threats.pdf

4.1.3 SECURITYISSUES SPECIFICTO IPV6

IPv6addressselectionalgorithm(sourceanddestination)securityhasimpactswithrespecttoingress

filtering and attempts at session hijacking. This concern also applies for dualstack nodes and

tunnelingenvironments.

IPv6privacyextensions,whichareusedtovarytheInterfaceIdentifybytheendnode,canbeusedto

thwartdeviceprofiling.

New firewall rules for IPv6are required to supportpolicy for ICMPv6and IPv6extensionheaders:

which

ICMP

messages

to

allow

or

deny,

e.g.,

Packet

Too

Large

for

PMTU,

which

extension

headers

to

allowordeny,e.g.,denyRoutingHeaderType0,whethertoallowRoutingHeaderType2forMIPv6

RouteOptimization. RefertoRFC4890,RecommendationsforFilteringICMPv6MessagesinFirewalls

andRFC4942,IPv6Transition/CoexistenceSecurityConsiderations.

IPv6 stateless address autoconfiguration uses new ICMP messages in Router Advertisements

(RA)/Router Solicitations (RS) and Neighbor Advertisements (NA)/Neighbor Solicitations (NS) that

assistanIPv6node inconstructinganIPv6address. Newvulnerabilitiesare introduced ifthelink is

compromised. NA/NS and RA/RS can be protected using a linklevel securitymechanism, as, for

example,theSecureNeighborProtocol(SEND)andCryptographicallyGeneratedAddresses(CGA)to

determinewhethera routeron the link isa trusted router. However,deploymentofCGAmaybe

limiteddue to IntellectualPropertyRights issuesand some technical concerns. Refer to the IETF

workinggroup,Cga&Sendmaintenance(csi)forcurrentstatus.

Certain IPv6addresses shouldbe filteredat the firewall, forexample: IPv6 loopback, IPv4mapped

address, unique local address, site local address, certain multicast addresses. The IPv6 use of

multicastaddressing introduces thepotential fornewvulnerabilities. Certainresources internal to

the network are identifiable bymulticast addressing. These addresses should be filtered at the


22/26


networkboundary,dependingupon their scope. Theseaddressesalso introduce thepotential for

DoS attacks. Also, IPv6 anycast addresses, such asMobile IPv6Home Agent anycast or Subnet

Routeranycast,canpotentiallybeusedinDoSattacks.

IPsec support is builtin to IPv6, which will allow for more instances of endtoend encryption,

consistentwith

the

design

of

IPv6

to

move

more

of

the

responsibility

for

the

session

to

the

end

users.

However,enduserencryptionmakesexecutionofIDSmoredifficult. Ingeneral,consistentwiththe

designofIPv6,somelevelofsecuritymaybemoveddowntotheendnodes,eitherforencryptionor

attheapplicationlevel. Securitymaybetransitionedfromaperimetermodeltoadistributedmodel.

PerformanceconsiderationsofIPv6securitymechanismsmustbebalancedagainstrisk.

MIPv6

Severalsecurityissues/mechanismsareintroducedwithMIPv6.

IPseccanbeusedtosecurecommunicationbetweenthemobilenodeandthehomeagent. Asan

alternative to IPsec,securingofbindingupdatesandbindingacknowledgementscanbeperformed

usingMIPv6signalingmessagingbetweentheMobileNode(MN)andtheHomeAgent(HA). Referto

RFC4285.

InMIPv6,packet lossdue toegress filteringat theaccess router ispreventedbyplacing the IPv6

mobilenodescareofaddressintheexternalIPheaderwheninaforeignnetwork.

DynamicHomeAgentAddressDiscovery reliesupon special ICMPmessaging,which is required to

passthroughthenetworkfirewalls.

Routeoptimizationallows themobilenode and the correspondentnode to communicatedirectly

(ratherthanviathehomeagent),withoutprearrangedsecurityassociations. Additionalmessaging

isrequiredtoperformreturnroutabilityforrouteoptimization. Inrouteoptimization,amobilenode

reveals its careofaddress (currentpointof attachment) to the correspondentnode. The careof

addresscanbetraceabletoaparticularlocation. Itisaconcernthatamobileuserslocationcanbe

compromisedwhenrouteoptimizationisused.

HierarchicalMIPv6canbeusedtomitigatelocationprivacyissueswithrouteoptimization.

IssueswithMobileIPv6securityhaveconsiderableimplicationsforendusersandthenetwork,andis

toolargeatopictoduejusticetohere. RefertotheIETFMobilityEXTensionsforIPv6(mext)working

grouprelated

RFCs

for

additional

information.


23/26


SecuritySupportTools

Additionalconsiderationsincludethestatusofcommon,securitysupporttools:Nessus(vulnerability

scanner), Nmap (port scanner), Wireshark (packet analyzer), netcat (packet read/write), hping

(packet generator), Snort (packet sniffer), to list only few of the open source and commercial

productswhich

all

have

varying

levels

of

support

for

IPv6.

The

Status

of

commercial

firewalls,

IDS

andIPStosupportIPv6isnotmature. RefertoNationalInstituteofStandardsandTechnology(NIST)

report,FirewallDesignConsiderationsforIPv6.

4.2 OVERVIEW OFUMTS SECURITY ANDIPV6

4.2.1 IPV6IMPACTSTO UMTSENDUSER SECURITY

InPacketDateProtocol(PDP)ContextactivationusingIPv6statelessaddressautoconfiguration,the

GatewayGPRSSupportNode (GGSN)assignsbothan IPv6 Interface Identifierand/64prefixtothe

MobileStation(MS). Theprefixisuniquewithinitsscope. TheGGSNandMSaretheonlynodeson

the local link, thusDuplicateAddressDetection is not required. TheMS is authenticated by the

network and the PDP Context is tunneledwithin the network. The need for additional security

measures,suchasSENDandCGAarenotrequiredforthePDPContextwithinthe3GPPnetwork.

TheGGSNactsasananchorforthePDPContext,eliminatingtheneedforMIPv6,priortorelease8

(LTE).

3GPPsupportsIPv6privacyextensionsforthePDPAddress. ThePDPContextisidentifiedbytheIPv6

prefixat

the

Serving

GPRS

Support

Node

(SGSN)

and

GGSN

and

not

by

the

full

128

bit

PDP

Address.

ForIMS,theGGSNprovidestheaddressofthePCSCFtotheMSforProxyDiscovery. TheMS,GGSN

and PCSCFmust support the same IP version. TheMS point of attachment is at the external

interfaceoftheGGSN. IMSreliesuponSIPsignalingbetweenenduserandPCSCFIMS. SIPsignaling

is protected by IPsec or TLS. This protection is independent of the Access Network protection

mechanisms.

For IMS security, refer to IMS TS 33.203. For IPv4IPv6 interworking scenarios, refer to 3GPP TS

23.981.

4.2.2 IPV6IMPACTSTO UMTSPACKETNETWORK SECURITY

SecurityprotectionisspecifiedforGTPcontroltraffic. Protectionofusertrafficisconsideredoutside

thescopeofthestandards.

TS32.210describestheminimumsecurityfeaturesinsupportofdataintegrity,originauthentication,

antireplay protection, and confidentiality. 3GPP Network Domain Security provides hopbyhop

protection,whichallowsforseparatesecuritypoliciesdependinguponwhetheralinkisintradomain


24/26


or interdomain and whether between trusted or untrusted domains. Security Gateways are

stationedatthenetworkboundary alltrafficbetweensecuritydomains isviaaSecurityGateway.

Authentication and integrity protection are mandatory between two security domains and

encryptionusingESP intunnelmode isoptional. ProtectionoftrafficwithintheSecurityDomain is

optional.

Firewallsatnetworkboundariesarerequiredtoprotectagainstunauthorizedtraffic.

TheIMSnetworktopologycanbehiddenbyencryptingtheIMSnetworkelementIPaddressesinSIP

messages.

RefertoTS33.102,33.203,33.210and33.310fordetailsofNetworkDomainSecurityandTS33.234

forWLANinterworkingsecurity.

4.3 IPV6 IMPACTSON LTESECURITY IMPLEMENTATION

TheLTE

specification

supports

aflat

IP

network

based

upon

TCP/IP

protocols.

General

security

and

enduserprivacyprinciplesfortheEPSarespecified inTS22.278. LTEspecificsecurityisdetailedin

TS33.203,33.401,33,402and33.178.

TheLTEUEsupportsdualstack,whichmayusesimultaneous IPv4and IPv6addresses,overanEPS

Bearer(MIPbetweenSGWandPGW)orPDPContext(GTPtunneling).

LTE supports interworking between 3GPP EPS and UTRAN, WLAN, CDMA, WIMAX and GERAN.

Securehandover is supportedbetweenEPS andnonEPSaccessnetworks. This incursadditional

complexitywithrespecttosecuritytosupportmobility,keytransferandalgorithmnegotiation,DS

MIPv6orPMIPv6,andsupportforIPv4privateaddressing.

4.4 IPV6 SECURITY RECOMMENDATIONS

ItisobviousbutsignificanttostresstheimportanceoftrainingandplanningfortheadoptionofIPv6

with respect to security. Oncea securitypolicy isestablished, it isnecessary to stay currentand

vigilant with security vulnerabilities and with IPv6specific updates and vulnerabilities, as IPv6

continuestobeadopted.

Notallsecuritysupport isequal knowthecapabilities/limitationsofhostsandrouters innetwork:

IPv6stacksupport,privacyextensions,IPsec,andfilteringcapabilities.

Determineabalanceacrossrisk,overheadandperformanceofsecuritymechanisms.


25/26


5. CONCLUSIONS ThegrowthofalwaysonalwaysreachableservicesandthedepletionofIPv4addressesaretwokey

driversmovingcarrierstoconsidertransitioningtoIPv6. IPv4willcoexistwithIPv6forseveralyears;

therefore,transitionmechanismsandcoexistencetechniqueswillbeusedasthecarrierstransition

toIPv6.

CarriersevolvingtheirnetworkstoLTEshouldconsidermakingIPv6arequirementfromday1. Since

LTEEPCdoesnotsupportaCircuitSwitchedCoreaspartofthe3GPPstandard,nativesupport for

voicewillbesupportedby the IMScore. Becausethe transition to IMSbasedVoIPwill likely take

severalyears,itiscriticalforthecarrierstounderstandtheimpactsofIPv6ontheexistingVoiceCore

and signaling infrastructure. Lastly, it is absolutely critical that the transition to IPv6 consider

networksecurity.

6. ACKNOWLEDGEMENTS Themissionof3GAmericas is topromoteand facilitate the seamlessdeployment throughout the

Americas of the GSM family of technologies, including LTE. 3G Americas' Board of Governor

membersincludeAlcatelLucent,AT&T(USA),Cable&Wireless(WestIndies),Ericsson,Gemalto,HP,

Huawei,Motorola,NokiaSiemensNetworks,NortelNetworks,Openwave,ResearchInMotion(RIM),

RogersWireless(Canada),TMobileUSA,Telcel(Mexico),TelefonicaandTexasInstruments.

Wewould like to recognize the significantproject leadershipand important contributionsof Paul

SmithofAT&Taswellastheothermembercompaniesfrom3GAmericasBoardofGovernorswho

participatedin

the

development

of

this

white

paper.

7. REFERENCES[1] GPRSenhancementsforEUTRANaccess(Release8);3GPPTS23.401;inprogress

[2] ArchitectureEnhancementsfornon3GPPaccesses(Release8);3GPPTS23.402;inprogress

[3] EvolvedUniversalTerrestrialRadioAccess(EUTRA)andEvolvedUniversalTerrestrialRadio

AccessNetwork

(E

UTRAN),

3GPP

TS

36.300;

in

progress

[4] TransitioningtoIPv6;3GAmericas;February2008


26/26

8. GLOSSARY

AAA Authentication,AuthorizationandAccounting

ALG ApplicationLevelGateway

APN AccessPointName

CDR CallDetailRecord

DAD DuplicateAddressDetection

DHCP DynamicHostConfigurationProtocol

DNS DomainNameServer

EMS ElementManagementSystem

GGSN GatewayGPRSSupportNode

GPRS GeneralPacketRadioService

GTP GPRSTunnelingProtocol

HSS

HomeSubscriber

Server

HTTP HyperTextTransferProtocol

IANA InternetAssignedNumberAuthority

ICE InteractiveConnectivityEstablishment

IMS IPMultimediaSubsystem

ICID IMSChargingIdentity

NAT NetworkAddressTranslation

NOC NetworkOperationCenter

PCRF PolicyandChargingRulesFunction

PCSCF ProxyCallSessionControlFunction

PDP PacketDataProtocol

QoS

Qualityof

Service

RAB RadioAccessBearer

RAN RadioAccessNetwork

RIM ResearchinMotion

RIR RegionalInternetRegistry

RNC RadioNetworkController

RTCP RealTimeControlProtocol

RTP RealTimeProtocol

SCSCF ServingCallSessionControlFunction

SDP SessionDescriptionProtocol

SLAAC StatelessAddressAutoConfiguration

SIP SessionInitiationProtocol

SGSN ServingGPRSSupportNode

UE UserEquipment

UMTS UniversalMobileTelecommunicationsSystem

URI UniversalResourceIdentifier

VPN VirtualPrivateNetwork

3G Americas IPv6 LTE

Documents

Transcript of 3G Americas IPv6 LTE