RADIOACCESSNETWORK

ARCHITECTURE
5.1SystemArchitecture
5.2UTRANArchitecture
5.3GeneralProtocolModelforUTRANTerrestrial
Interfaces
5.4Iu,TheUTRANCNInterface
5.5UTRANInternalInterfaces
5.6UTRANEnhancementsandEvolution
5.7UTRANCNArchitectureandEvolution
5.1SYSTEMARCHITECTURE
Functionalnetworkelements
UserEquipment(UE)
interfaceswithuserandradiointerface
RadioAccessNetwork(RAN,UMTSTerrestrialRAN
=UTRAN)
handlesallradiorelatedfunctionality
CoreNetwork
switchesandroutescallsanddataconnections
toexternalnetworks
 PLMN(PublicLandMobileNetwork)
operatedbyasingleoperator
distinguishedfromeachotherwithuniqueidentities
operationaleitherontheirownortogetherwithother
subnetworks
connectedtootherPLMNsaswellastoothertypesof
network,suchasISDN,PSTN,theInternet,etc.
 UEconsistsoftwoparts
MobileEquipment(ME)
theradioterminalusedforradiocommunication
overUuinterface
UMTSSubscriberIdentityModule(USIM)
asmartcardthatholdsthesubscriberidentity
performsauthenticationalgorithms

storesauthenticationandencryptionkeys

somesubscriptioninformationthatisneededatthe

terminal
 UTRANconsistsoftwoelements
NodeB
convertsdataflowbetweenIubandUuinterfaces
participatesinradioresourcemanagement

RadioNetworkController(RNC)
ownsandcontrolsradioresourcesinitsdomain
theserviceaccesspoint(SAP)forallservicesthat

UTRANprovidestheCN
e.g.,managementofconnectionstoUE
 MainelementsofCN
a) HLR(HomeLocationRegister)
b) MSC/VLR(MobileServicesSwitchingCentre/Visitor
LocationRegister)
c) GMSC(GatewayMSC)
d) SGSN(ServingGPRS(GeneralPacketRadioService)
SupportNode)
e) GGSN(GatewayGPRSSupportNode)
(a)HLR(HomeLocationRegister)
adatabaselocatedinusershomesystemthatstores
themastercopyofusersserviceprofile
serviceprofileconsistsof,e.g.,
informationonallowedservices,forbidden
roamingareas
supplementaryserviceinformationsuchas

statusofcallforwardingandthecall
forwardingnumber
 itiscreatedwhenanewusersubscribestothe
system,andremainsstoredaslongasthe
subscriptionisactive
forthepurposeofroutingincomingtransactionsto
UE(e.g.callsorshortmessages)
HLRalsostorestheUElocationonthelevelof
MSC/VLRand/orSGSN
(b)MSC/VLR(MobileServicesSwitching
Centre/VisitorLocationRegister)
theswitch(MSC)anddatabase(VLR)thatservethe
UEinitscurrentlocationforCircuitSwitched(CS)
services
thepartofthenetworkthatisaccessedviaMSC/VLR
isoftenreferredtoasCSdomain
MSC
usedtoswitchCStransactions
VLR
holdsacopyofthevisitingusersservice
profile,aswellasmorepreciseinformationon
theUEslocationwithintheservingsystem
(c)GMSC(GatewayMSC)
theswitchatthepointwhereUMTSPLMNis
connectedtoexternalCSnetworks
allincomingandoutgoingCSconnectionsgothrough
GMSC
(d)SGSN(ServingGPRS(GeneralPacketRadio
Service)SupportNode)
functionalityissimilartothatofMSC/VLRbutis
typicallyusedforPacketSwitched(PS)services
thepartofthenetworkthatisaccessedviaSGSNis
oftenreferredtoasPSdomain
(e)GGSN(GatewayGPRSSupportNode)
functionalityisclosetothatofGMSCbutisin
relationtoPSservices
 Externalnetworkscanbedividedintotwogroups
CSnetworks
providecircuitswitchedconnections,liketheexistingtelephony
service
ISDNandPSTNareexamplesofCSnetworks

PSnetworks
provideconnectionsforpacketdataservices
InternetisoneexampleofaPSnetwork
 Mainopeninterfaces
Cuinterface
theelectricalinterfacebetweenUSIMsmartcard
andME
Uuinterface
theWCDMAradiointerface
theinterfacethroughwhichUEaccessesthefixed

partofthesystem
themostimportantopeninterfaceinUMTS
 Iuinterface
connectsUTRANtoCN
Iurinterface
allowssofthandoverbetweenRNCs
Iubinterface
connectsaNodeBandanRNC
5.2UTRANARCHITECTURE
5.2.1RadioNetworkController
5.2.2NodeB(BaseStation)
 UTRAN
consistsofoneormoreRadioNetworkSubsystems(RNS)

RNS
asubnetworkwithinUTRAN
consistsofoneRadioNetworkController(RNC)andoneor
moreNodeBs
 RNCs
maybeconnectedtoeachotherviaIurinterface
RNCsandNodeBsareconnectedwithIubinterface
MaincharacteristicsofUTRAN
supportofUTRAandallrelatedfunctionality
supportsofthandoverandWCDMAspecificRadioResource
Managementalgorithms
useofATMtransportasthemaintransportmechanismin
UTRAN
useofIPbasedtransportasthealternativetransport
mechanisminUTRANfromRelease5onwards
5.2.1RADIONETWORK
CONTROLLER

RNC(RadioNetworkController)
thenetworkelementresponsibleforradioresourcescontrol
ofUTRAN
itinterfacesCN(normallytooneMSCandoneSGSN)
terminatesRRC(RadioResourceControl)protocolthat
definesthemessagesandproceduresbetweenmobileand
UTRAN
itlogicallycorrespondstotheGSMBSC
 RADIO
RESOURCE
CONTROL

RadioResourceControl(RRC)messages
themajorpartofthecontrolsignalingbetweenUEand
UTRAN
carryallparametersrequiredtosetup,modifyandrelease
Layer2andLayer1protocolentities
Themobilityofuserequipmentintheconnectedmode
iscontrolledbyRRCsignaling
measurements,handovers,cellupdates,etc.
3GPPBEARERSFORSUPPORTING
PACKETSWITCHEDSERVICES

UTRAN CN
TRAFFICBEARERSSTRUCTURESUPPORTING
PACKETSWITCHEDSERVICES
3GPPBearer
adedicatedpathbetweenmobileanditsservingGGSN
foramobiletosendorreceivepacketsovera3GPPPSCN
a3GPPBearerinaUMTSnetworkwouldbeaUMTS
Bearer
 Constructedbyconcatenating
RadioAccessBearer(RAB)
connectsamobileoveraRANtotheedgeof

CN(i.e.,aSGSN)
CNBearer

carriesusertrafficbetweentheedgeofCN

andaGGSN
 SIGNALINGANDTRAFFIC
CONNECTIONSBETWEENMOBILE
ANDSGSN
 ThesignalingconnectionbetweenmobileandSGSNis
constructedbyconcatenating
SignalingRadioBearer
betweenmobileandRAN(e.g.,theRNCinUTRAN)

IuSignalingBearer
betweenRANandSGSN

SignalingandtrafficconnectionsbetweenmobileandSGSN
RadioResourceControl(RRC)connection
RadioAccessNetworkApplicationPart(RANAP)
connection
 RadioResourceControl(RRC)connection
includesSignalingRadioBearersandTrafficRadio
Bearersforthesamemobile
usedtoestablish,maintain,andreleaseRadio
Bearers
amobilewilluseacommonRRCconnectiontocarry
signalingandusertrafficforbothPSandCSservices
 RadioAccessNetworkApplicationPart(RANAP)
connection
includesIuSignalingBearersandIuTrafficBearers
forthesamemobile
usedtoestablish,maintain,modify,change,and
releasealltheseIuBearers
5.2.1.1LOGICALROLEOFTHERNC
TheRNCcontrollingoneNodeBisindicatedas
theControllingRNC(CRNC)ofNodeB
ControllingRNC
responsibleforloadandcongestioncontrolofitsown
cells
executesadmissioncontrolfornewradiolinks
 IncaseonemobileUTRANconnectionuses
resourcesfrommorethanoneRNS(dueto
handover),theRNCsinvolvedhavetwoseparate
logicalroles
ServingRNC(SRNC)
DriftRNC(DRNC)
 ServingRNC
SRNCforonemobileistheRNCthatterminates
boththeIulinkforthetransportofuserdataandthe
correspondingRANAP(RANApplicationPart)
signalingto/fromthecorenetwork
SRNCalsoterminatestheRadioResourceControl
Signaling,thatisthesignalingprotocolbetweenthe
UEandUTRAN
itperformsL2processingofthedatato/fromthe
radiointerface
 basicRadioResourceManagementoperationsare
executedinSRNC
mapRadioAccessBearer(RAB)parametersinto

airinterfacetransportchannelparameters
handoverdecision

outerlooppowercontrol

oneUEconnectedtoUTRANhasoneandonlyone
SRNC
 DriftRNC
DRNCisanyRNC,otherthantheSRNC,that
controlscellsusedbythemobile
DRNCdoesnotperformL2processingoftheuser
planedata,butroutesthedatatransparently
betweenIubandIurinterfaces
oneUEmayhavezero,oneormoreDRNCs
5.2.2NODEB(BASESTATION)
MainfunctionofNodeB
performtheairinterfaceL1processing,e.g.,
channelcodingandinterleaving

rateadaptation

spreading

alsoperformssomebasicRadioResource
Managementoperations,e.g.
innerlooppowercontrol

ItlogicallycorrespondstotheGSMBaseStation
 INTERLEAVING
Thetransmissionofpulsesfromtwoormore
digitalsourcesintimedivisionsequenceovera
singlepath
 5.3GENERALPROTOCOLMODEL
FORUTRANTERRESTRIAL
INTERFACES
5.3.1General
5.3.2HorizontalLayers
5.3.3VerticalPlanes
5.3.1GENERAL
ThegeneralprotocolmodelforUTRAN
terrestrialinterfaces
thelayersandplanesarelogicallyindependentof
eachother
partsoftheprotocolstructuremaybechangedinthe
futurewhileotherpartsremainintact
5.3.2HORIZONTALLAYERS
Theprotocolstructureconsistsoftwomain
layers
Radionetworklayer
Transportnetworklayer
5.3.3VERTICALPLANES
5.3.3.1ControlPlane
5.3.3.2UserPlane
5.3.3.3TransportNetworkControlPlane
5.3.3.4TransportNetworkUserPlane
5.3.3.1CONTROLPLANE
ControlPlane
usedforallUMTSspecificcontrolsignaling
includestwoparts
applicationprotocol

RANAP(RANapplicationpart)inIu

RNSAP(RNSapplicationpart)inIur

NBAP(NodeBapplicationpart)inIub

signalingbearer

transporttheapplicationprotocolmessages
 Applicationprotocolisusedfor
settingupbearerstoUE,i.e.
radioaccessbearerinIu
radiolinkinIurandIub
5.3.3.2USERPLANE
UserPlane
transportallinformationsentandreceivedbythe
user,suchas
codedvoiceinavoicecall

packetsinanInternetconnection

includestwoparts
datastream(s)

databearer(s)fordatastream(s)
5.3.3.3TRANSPORTNETWORK
CONTROLPLANE
Usedforallcontrolsignalingwithintransportlayer
Doesnotincludeanyradionetworklayerinformation

IncludesALCAP(AccessLinkControlApplication
Part)protocolusedtosetupthetransportbearers
(databearer)foruserplane
 IncludessignalingbearerneededforALCAP
Transportnetworkcontrolplane
actsbetweencontrolplaneanduserplane
makesitpossibleforapplicationprotocolinradio
networkcontrolplanetobecompletelyindependent
ofthetechnologyselectedfordatabearerinuser
plane
5.3.3.4TRANSPORTNETWORKUSER
PLANE
TransportNetworkUserPlane
databearer(s)inuserplane
signalingbearer(s)forapplicationprotocol
5.4IU,THEUTRANCNINTERFACE
5.4.1ProtocolStructureforIuCS
5.4.2ProtocolStructureforIuPS
5.4.3RANAPProtocol
5.4.4IuUserPlaneProtocol
5.4.5ProtocolStructureofIuBC,andtheSABP
Protocol
 Iuinterface
anopeninterfacethatdividesthesystemintoradio
specificUTRANandCN
handlesswitching,routingandservicecontrol
 Iucanhavetwomaindifferentinstancesandone
additionalinstance
IuCS
connectUTRANtoCircuitSwitched(CS)CN
IuPS
connectUTRANtoPacketSwitched(PS)CN

IuBC(Broadcast)
supportCellBroadcastServices

connectUTRANtotheBroadcastdomainofCN
5.4.1PROTOCOLSTRUCTUREFORIU
CS
5.4.1.1IuCSControlPlaneProtocolStack
5.4.1.2IuCSTransportNetworkControlPlane
ProtocolStack
5.4.1.3IuCSUserPlaneProtocolStack

Thefollowingfigure
depictstheIuCSoverallprotocolstructure
thethreeplanesintheIuinterfaceshareacommon
ATM(AsynchronousTransferMode)transport
physicallayeristheinterfacetophysicalmedium
opticalfiber

radiolink

coppercable
5.4.1.1IuCSCONTROLPLANE
PROTOCOLSTACK
ControlPlaneprotocolstackconsistsofRANAP,
ontopofBroadband(BB)SS7(SignalingSystem
#7)protocols
Theapplicablelayersare

SignalingConnectionControlPart(SCCP)
MessageTransferPart(MTP3b)
SAALNNI(SignalingATMAdaptationLayer
forNetworktoNetworkInterfaces)
 SAALNNIisfurtherdividedinto
ServiceSpecificCoordinationFunction
(SSCF)
ServiceSpecificConnectionOriented
Protocol(SSCOP)
ATMAdaptationLayer5(AAL)layers
SSCFandSSCOPlayers
designedforsignalingtransportin
ATMnetworks
takecareofsignalingconnection
management
AAL5isusedforsegmentingthedatato
ATMcells
 ATM IN BRIEF
 AAL2 AND AAL5

AbovetheATMlayerweusuallyfindanATM
adaptationlayer(AAL)
AAL
processthedatafromhigherlayersforATM
transmission
segmentthedatainto48bytechunksand
reassembletheoriginaldataframesonthereceiving
side
 FivedifferentAALs(0,1,2,3/4,and5)
AAL0
noadaptationisneeded
theotheradaptationlayershavedifferentproperties
basedonthreeparameters
realtimerequirements
constantorvariablebitrate

connectionorientedorconnectionlessdata
transfer
 Iu interface uses two AALs
AAL2
(connection-oriented
services) (real-time data streams)
(variable bit rate VBR)

AAL2
AAL5

5.4.1.2IUCSTRANSPORTNETWORK
CONTROLPLANEPROTOCOLSTACK
TransportNetworkControlPlaneprotocol
stackconsistsof
SignalingProtocolontopofBBSS7
protocolsforsettingup
AAL2connections(Q.2630.1[Q.aal2

CS1])
adaptationlayer(Q.2150.1[AAL2

SignalingTransportConverterfor
MTP3b])
BBSS7arethosedescribedabove
withoutSCCPlayer
5.4.1.3IUCSUSERPLANE
PROTOCOLSTACK
AdedicatedAAL2connectionisreservedforeach
individualCSservice
IuUserPlaneProtocolresidingdirectlyontopof
AAL2
5.4.2PROTOCOLSTRUCTUREFORIU
PS
5.4.2.1IuPSControlPlaneProtocolStack
5.4.2.2IuPSTransportNetworkControlPlaneProtocol
Stack
5.4.2.3IuPSUserPlaneProtocolStack
 Thefollowingfigure
depictsIuPSprotocol
structure
acommonATMtransportis
appliedforbothUserPlane
andControlPlane
thephysicallayerisas
specifiedforIuCS
5.4.2.1IUPSCONTROLPLANE
PROTOCOLSTACK
ControlPlaneprotocolstack
consistsof
RANAP
signalingbearers
BBSS7basedsignalingbearer

analternativeIPbased

signalingbearer
SCCPlayerisusedforboth
bearer
 IPbasedsignalingbearerconsists
of
M3UA(SS7MTP3User
AdaptationLayer)
SCTP(StreamControl
TransmissionProtocol)
designedforsignaling

transportintheInternet
ensurereliable,insequence

transportofmessageswith
congestioncontrol
IP(InternetProtocol)
AAL5(commontoboth
alternatives)
5.4.2.2IUPSTRANSPORTNETWORK
CONTROLPLANEPROTOCOLSTACK
TransportNetworkControlPlaneisnotapplied
toIuPS
SettingupofGTPtunnel
requiresanidentifierforthetunnelandIPaddresses
forbothdirections
thesearealreadyincludedinRANAPRAB
Assignmentmessages
5.4.2.3IUPSUSERPLANE
PROTOCOLSTACK
IuPSUserPlane
multiplepacketdataflowsare
multiplexedononeorseveralAAL5
PVCs(PermanentVirtualCircuit)
GTPU(UserPlanepartofGPRS
TunnelingProtocol)isthe
multiplexinglayerthatprovides
identitiesforindividualpacketdata
flow
eachflowusesUDPconnectionless
transportandIPaddressing
5.4.3RANAPPROTOCOL
RANAP
definesinteractionsbetweenRNSandCN
thesignalingprotocolinIuthatcontainsallthe
controlinformationspecifiedforRadioNetwork
Layer
implementedbyvariousRANAPElementary
Procedures(EP)
eachRANAPfunctionmayrequireexecutionofone
ormoreEPs
 threeclassesofEP
class1EP
requestandresponse(failureorsuccess)

class2EP

requestwithoutresponse

class3EP

requestandpossibilityforoneormore

responses
 RANAPfunctions
relocation
RAB(RadioAccessBearer)management
Iurelease
reportunsuccessfullytransmitteddata
commonIDmanagement
paging
 managementoftracing
UECNsignalingtransfer
securitymodecontrol
managementofoverload
reset
locationreporting
RANAPFUNCTION

Relocation handlesbothSRNSrelocationand
hardhandover(includingintersystemcase
to/fromGSM)
SRNSrelocation
theservingRNSfunctionalityisrelocated
fromoneRNStoanotherwithoutchangingthe
radioresourcesandwithoutinterruptingthe
userdataflow
prerequisite allRadioLinksarealreadyin

thesameDRNCthatisthetargetforthe
relocation
 InterRNShardhandover
relocatetheservingRNSfunctionalityfrom
oneRNStoanotherandtochangetheradio
resourcescorrespondinglybyahardhandover
inUuinterface
prerequisite UEisattheborderofthe

sourceandtargetcells
RANAPFUNCTION
RAB(RadioAccessBearer)management combines
allRABhandling
RABsetup
modificationofthecharacteristicsofanexisting
RAB
clearinganexistingRAB
Iurelease
releasesallresources(SignalinglinkandUPlane)
fromagiveninstanceofIurelatedtothespecified
UE
RANAPFUNCTION
Reportingunsuccessfullytransmitteddata
allowsCNtoupdateitschargingrecordswith
informationfromUTRANifpartofthedatasentwas
notsuccessfullysenttoUE
CommonIDmanagement
thepermanentidentificationoftheUEissentfrom
CNtoUTRANtoallowpagingcoordinationfrom
possiblytwodifferentCNdomains
RANAPFUNCTION
Paging
usedbyCNtopageanidleUEforaUEterminating
servicerequest,suchasavoicecall
apagingmessageissentfromCNtoUTRANwith
theUEcommonidentification(permanentId)and
thepagingarea
UTRANwilleitheruseanexistingsignaling
connection,ifoneexists,tosendthepagetoUEor
broadcastthepagingintherequestedarea
RANAPFUNCTION
Managementoftracing
CNmay,foroperationandmaintenancepurposes,
requestUTRANtostartrecordingallactivityrelated
toaspecificUEUTRANconnection
RANAPFUNCTION
UECNsignalingtransfer
transferofthefirstUEmessagefromUEtoUTRAN
example
aresponsetopaging

arequestofaUEoriginatedcall

aregistrationtoanewarea

italsoinitiatesthesignalingconnectionforIu

directtransfer
usedforcarryingallconsecutivesignaling

messagesovertheIusignalingconnectioninboth
uplinkanddownlinkdirections
RANAPFUNCTION
Securitymodecontrol
usedtosetthecipheringorintegritycheckingonor
off
whencipheringison
thesignalinganduserdataconnectionsinthe

radiointerfaceareencryptedwithasecretkey
algorithm
 whenintegritycheckingison
anintegritychecksum,furthersecuredwitha
secretkey,isaddedtosomeoralloftheRadio
Interfacesignalingmessages
thisensuresthatthecommunicationpartnerhasnot
changed,andthecontentoftheinformationhasnot
beenaltered
RANAPFUNCTION
Managementofoverload
controltheloadoverIuinterfaceagainstoverload
due
example,toprocessoverloadattheCNorUTRAN
asimplemechanismisappliedthatallows
stepwisereductionoftheloadanditsstepwise
resumption[( ) ],triggeredbyatimer
RANAPFUNCTION
Reset
resettheCNortheUTRANsideofIuinterfacein
errorsituations
oneendoftheIumayindicatetotheotherendthatit
isrecoveringfromarestart,andtheotherendcan
removeallpreviouslyestablishedconnections
RANAPFUNCTION
Locationreporting
allowsCNtoreceiveinformationonthelocationofa
givenUE
includestwoelementaryprocedures
controlthelocationreportinginRNC

sendtheactualreporttoCN
 5.4.4IUUSERPLANEPROTOCOL
IuUserPlaneprotocol
intheRadioNetworkLayerofIuUser
Plane
definedtobeindependentofCN
domain
purpose
carryuserdatarelatedtoRABsover

Iuinterface
theprotocolperformseitherafully
transparentoperation,orframingfor
userdatasegments
theprotocolalsoperformssomebasic
controlsignalingtobeusedfor
initializationandonlinecontrol
 theSDUsizestypicallycorrespondto
AMR(AdaptiveMultirateCodec)speech
frames,or
theframesizesderivedfromthedatarateofa
CSdatacall
controlproceduresforinitializationandrate

controlaredefined,andafunctionalityis
specifiedforindicatingthequalityoftheframe
based,forexample,onCRCfromradiointerface
5.4.5PROTOCOLSTRUCTUREOFIU
BC,ANDTHESABPPROTOCOL
IuBCinterface
connectsRNCinUTRANwiththebroadcastdomain
ofCoreNetwork,namelywithCellBroadcastCentre
usedtodefineCellBroadcastinformationthatis
transmittedtomobileuserviaCellBroadcastService
e.g.nameofcity/regionvisualizedonthemobile
phonedisplay
 IuBCisacontrolplaneonlyinterface
theprotocolstructureofIuBCisshownasfollows
 SABP(ServiceAreaBroadcastProtocol)
providesthecapabilityforCellBroadcast
CentreinCNtodefine,modifyand
removecellbroadcastmessagesfromRNC
SABPhasthefollowingfunctions
messagehandling
broadcastofnewmessages

amendment
[ ]ofexistingbroadcast
messages
preventionofbroadcastingofspecific

messages
 loadhandling
responsiblefordeterminingtheloadingofthebroadcast
channelsatanyparticularpointintime
reset
permitsCBCtoendbroadcastinginoneormoreService
Areas
5.5UTRANINTERNALINTERFACES
5.5.1RNCRNCInterface(IurInterface)andthe
RNSAPSignaling
5.5.2RNCNodeBInterfaceandtheNBAP
Signaling
5.5.1RNCRNCINTERFACE(IUR
INTERFACE)ANDTHERNSAP
SIGNALLING
5.5.1.1Iur1 SupportoftheBasicInterRNC
Mobility
5.5.1.2Iur2 SupportofDedicatedChannel
Traffic
5.5.1.3Iur3 SupportofCommonChannelTraffic
5.5.1.4Iur4 SupportofGlobalResource
Management
 ThefollowingfigureshowstheprotocolstackofRNC
toRNCinterface(Iurinterface)
Iurinterfaceprovidesfourdistinctfunctions
supportofbasicinterRNCmobility(Iur1)
supportofdedicatedchanneltraffic(Iur2)
supportofcommonchanneltraffic(Iur3)
supportofglobalresourcemanagement(Iur4)
5.5.1.1IUR1 SUPPORTOFTHE
BASICINTERRNCMOBILITY
Thisfunctionalityrequiresthebasicmoduleof
RNSAPsignaling
providesthefunctionalityneededforthemobilityof
theuserbetweentwoRNCs
doesnotsupporttheexchangeofanyuserdatatraffic
 Ifthismoduleisnotimplemented
theonlywayforauserconnectedtoUTRANvia
RNS1toutilizeacellinRNS2istodisconnectitself
temporarilyfromUTRAN(releasetheRRC
connection)
ThefunctionsofferedbyIurbasicmoduleinclude
supportofSRNCrelocation
supportofinterRNCcellandUTRANregistration
areaupdate
supportofinterRNCpacketpaging
reportingofprotocolerrors
 Sincethisfunctionalitydoesnotinvolveuser
datatrafficacrossIur
UserPlaneandTransportNetworkControlPlane
protocolsarenotneeded
5.5.1.2IUR2 SUPPORTOF
DEDICATEDCHANNELTRAFFIC
Thisfunctionality
requiresdedicatedchannelmoduleofRNSAPsignaling
allowsdedicatedandsharedchanneltrafficbetweentwo
RNCs
 Thisfunctionalityrequiresalso
UserPlaneFrameProtocol(FP)fordedicatedand
sharedchannel
TransportNetworkControlPlaneprotocol(Q.2630.1
[Q.aal2CS1])usedforthesetupoftransport
connections(AAL2connections)
 FrameProtocolfordedicated
channels(DCHFP)definesthe
structureof
thedataframescarryingtheuser
data
thecontrolframesusedto
exchangemeasurementsand
controlinformation
FrameProtocolforcommon
channels(CCHFP)describes
theUserplaneprocedureforthe
sharedchannel
 ThefunctionsofferedbyIurDCHmodule
establishment,modificationandreleaseofthededicated
andsharedchannelinDRNCduetohandoversindedicated
channelstate
setupandreleaseofdedicatedtransportconnectionsacross
Iurinterface
transferofDCHTransportBlocksbetweenSRNCand
DRNC
managementoftheradiolinksinDRNSvia
dedicatedmeasurementreportprocedures

powersettingprocedures

compressmodecontrolprocedures
5.5.1.3IUR3 SUPPORTOF
COMMONCHANNELTRAFFIC
Thisfunctionality
allowsthehandlingofcommonchannel(i.e.RACH,
FACHandCPCH)datastreamsacrossIurinterface
Note
CPCH CommonPacketCHannel

RACH RandomAccessCHannel

FACH ForwardAccessCHannel
 Itrequires
CommonTransportChannelmoduleofRNSAP
protocol
IurCommonTransportChannelFrameProtocol
(CCHFP)
IfsignaledAAL2connectionsareused
Q.2630.1[Q.aal2CS1]signalingprotocolofthe
TransportNetworkControlPlaneisneeded
 ThefunctionsofferedbyIurcommontransport
channelmodule
setupandreleaseofthetransportconnectionacross
Iurforcommonchanneldatastreams
splittingoftheMAClayerbetweenSRNC(MACd)
andDRNC(MACc)
flowcontrolbetweenMACdandMACc
5.5.1.4IUR4 SUPPORTOFGLOBAL
RESOURCEMANAGEMENT
Thisprovidessignalingtosupportenhanced
radioresourcemanagementandO&Mfeatures
acrossIurinterface
Thefunctionisconsideredoptional
Thisfunctionhasbeenintroducedinsubsequent
releasesforthesupportof
commonradioresourcemanagementbetweenRNCs
advancedpositioningmethods
Iuroptimization
 ThefunctionsofferedbyIurglobalresource
module
transferofcellinformationandmeasurements
betweentwoRNCs
transferofpositioningparametersbetweencontroller
transferofNodeBtiminginformationbetweentwo
RNCs
5.5.2RNCNODEBINTERFACE
ANDTHENBAPSIGNALING
5.5.2.1CommonNBAPandtheLogicalO&M
5.5.2.2DedicatedNBAP
 Figure5.10showstheprotocolstackofRNC
NodeBinterface(Iubinterface)
 Figure5.11showsthelogicalmodelofNodeB
seenfromthecontrollingRNC
Figure 5.11 Logical Model of Node B
 LogicalmodelofNodeBincludes
thelogicalresourcesprovidedbyNodeBtoUTRAN(via
ControllingRNC)depictedas"cells"whichincludethe
followingphysicalchannelresources
DPCH(DedicatedPhysicalChannel)

PDSCH(PhysicalDownlinkSharedChannel)

PUSCH(PhysicalUplinkSharedChannel)

thededicatedchannelswhichhavebeenestablishedonNode
B
thecommontransportchannelsthatNodeBprovidestoRNC
 Elementsofthelogicalmodel
1. NodeBCommunicationContextsfordedicated
andsharedchannels
correspondstoallthededicatedresources
thatarenecessaryforauserindedicated
modeandusingdedicatedand/orshared
channelsasrestrictedtoagivenNodeB
 attributes(notexhaustive)
listofCellswherededicatedand/orshared

physicalresourcesareused
listofDCHwhicharemappedonthe

dedicatedphysicalresourcesforthatNodeB
CommunicationContext
listofDSCHandUSCH[TDD]whichare

usedbytherespectiveUE
 thecompleteDCHcharacteristicsforeach
DCH,identifiedbyitsDCHidentifier
thecompleteTransportChannel

characteristicsforeachDSCHandUSCH,
identifiedbyitsSharedChannelidentifier
listofIubDCHDataPorts

listofIubDSCHDataportsandIubUSCH

dataports
FDDuptooneIubTFCI2DataPort
 foreachIubDCHDataPort,the
correspondingDCHandcellswhichare
carriedonthisdataport
foreachIubDSCHandUSCHdataport,the

correspondingDSCHorUSCHandcells
whichservethatDSCHorUSCH
physicallayerparameters(outerlooppower

control,etc)
2. CommonTransportChannel
configuredinNodeB,onrequestofCRNC
attributes(notexhaustive)
Type(RACH,CPCH[FDD],FACH,DSCH,
USCH[TDD],PCH)
AssociatedIubRACHDataPortfora
RACH,IubCPCHDataPortforaCPCH
[FDD],IubFACHDataPortforaFACH,
IubPCHDataPortforPCH
Physicalparameters
3. Transportnetworklogicalresources
3.1NodeBControlPort
Functionality
exchangethesignalinginformationfor
thelogicalO&MofNodeB
thecreationofNodeBCommunication
Contexts
 theconfigurationofthecommontransport

channelsthatNodeBprovidesinagiven
cell
PCHandBCHcontrolinformation

betweentheRNCandtheNodeB
NodeBControlPortcorrespondstoone

signalingbearerbetweenthecontrolling
RNCandtheNodeB
ThereisoneNodeBControlPortperNodeB
3.2CommunicationControlPort
usedtosendtheproceduresforcontrollingthe

connectionsbetweenradiolinksandIubDCH
dataportsfromRNCtoNodeBforcontrolofNode
BCommunicationContexts
onesignalingbearerbetweenRNCandNodeB

canatmostcorrespondtooneCommunication
ControlPort
NodeBmayhavemultipleCommunication

ControlPorts(oneperTrafficTerminationPoint)
3.3TrafficTerminationPoint
representsDCH,DSCHandUSCH[TDD]data

streamsbelongingtooneormoreNodeB
CommunicationContexts(UEcontexts),whichare
controlledviaoneCommunicationControlPort
3.4IubRACHDataPort
3.5IubCPCHDataPort[FDD]
3.6IubFACHDataPort
3.7IubPCHDataPort
3.8IubFDDTFCI2DataPort
3.9IubDSCHDataPort
3.10IubTDDUSCHDataPort
3.11IubDCHDataPort
5.5.2.1COMMONNBAPANDTHE
LOGICALO&M
Iubinterfacesignaling(NBAP,NodeB
ApplicationPart)isdividedintotwoessential
components
commonNBAP
definesthesignalingproceduresacrossthe
commonsignalinglink
dedicatedNBAP
usedinthededicatedsignalinglink
 UserPlaneIubframeprotocols
define
thestructuresoftheframes
thebasicinbandcontrol
proceduresforeverytypeof
transportchannel(i.e.for
everytypeofdataportofthe
model)
Q.2630.1[Q.aal2CS1]signaling
usedfordynamic
managementofAAL2
connectionsusedinUser
Plane
 CommonNBAP(CNBAP)procedures
usedforthesignalingthatisnotrelatedtoone
specificUEcontextalreadyexistinginNodeB
definesalltheproceduresforthelogicalO&M
(OperationandMaintenance)ofNodeB
suchasconfigurationandfaultmanagement
 MainfunctionsofCommonNBAP
setupofthefirstradiolinkofoneUE,andselection
ofthetrafficterminationpoint
cellconfiguration
handlingoftheRACH/FACH/CPCHandPCH
channels
initializationandreportingofCellorNodeBspecific
measurement
LocationMeasurementUnit(LMU)control
faultmanagement
5.5.2.2DEDICATEDNBAP
WhentheRNCrequeststhefirstradiolinkfor
oneUEviaCNBAPRadioLinkSetupprocedure
NodeBassignsatrafficterminationpointforthe
handlingofthisUEcontext
everysubsequentsignalingrelatedtothismobileis
exchangedwithdedicatedNBAP(DNBAP)
proceduresacrossthededicatedcontrolportofthe
givenTrafficTerminationPoint
 MainfunctionsoftheDedicatedNBAP
addition,releaseandreconfigurationofradiolinks
foroneUEcontext
handlingofdedicatedandsharedchannels
handlingofsoftercombining
initializationandreportingofradiolinkspecific
measurement
radiolinkfaultmanagement
5.6UTRANENHANCEMENTS
ANDEVOLUTION
5.6.1IPTransportinUTRAN
5.6.2IuFlex
5.6.3StandAloneSMLCandIupcInterface
5.6.4InterworkingbetweenGERANandUTRAN,
andtheIurgInterface
 Release99UTRANarchitecture
definesthebasicsetofnetworkelementsand
interfaceprotocolsforthesupportofRelease99
WCDMAradiointerface
EnhancementoftheRelease99UTRAN
architecture
supportnewWCDMAradiointerfacefeaturesto
provideamoreefficient,scalableandrobust3GPP
systemarchitecture
FourmostsignificantadditionstotheUTRAN
architectureintroducedinRelease5are
describedinthesubsequentsections
5.6.1IPTRANSPORTINUTRAN
ATM
thetransporttechnologyusedinthefirstreleaseof
UTRAN
IPtransport
introducedinRelease5
Inadditiontotheinitiallydefinedoptionof
AAL2/ATM,userplaneFPframescanalsobe
conveyed
overUDP/IPprotocolsonIur/Iub
overRTP/UDP/IPprotocolsinIuCSinterface
5.6.2IUFLEX
Release99architecturepresented
inFigure5.3
onlyoneMSCandoneSGSN
connectedtoRNC
i.e.onlyoneIuPSandIuCS
interfaceintheRNC
Iuflex(flexible)
allowsoneRNCtohavemore
thanoneIuPSandIuCS
interfaceinstanceswiththe
core
Mainbenefitsofthisfeature
possibleloadsharingbetween
corenetworknodes
5.6.3STANDALONESMLCAND
IUPCINTERFACE
Locationbasedservices
expectedtobeaveryimportantsourceof
revenueformobileoperators
anumberofdifferentapplicationsare
expectedtobeavailableandlargelyused
UTRANarchitectureincludesastandalone
ServingMobileLocationCentre(standalone
SMLC,or,simply,SAS)
anewnetworkelementforhandlingof
positioningmeasurementsandcalculationof
themobilestationposition
 SAS
connectedtoRNCviaIupcinterface
PositioningCalculationApplicationPart(PCAP)is
theL3protocolusedforRNCSASsignaling
SASperformsthefollowingprocedures
providespositioning(GPSrelated)datato
RNC
performsthepositioncalculationfunctionfor

UEassistedGPS
 SASandIupcinterfaceareoptionalelements
Iupc
thefirstversion,supportedonlyAssistedGPS
laterversions,supportforotherpositioningmethods
5.6.4INTERWORKINGBETWEEN
GERANANDUTRAN,ANDTHEIURG
INTERFACE
Iuinterface
scheduledtobepartoftheGSM/EDGERadioAccess
Network(GERAN)inGERANRelease5
allowsreusing3GCoreNetworkalsoforGSM/EDGEradio
interface(andfrequencyband),butalsoallowsamore
optimizedinterworkingbetweenthetworadiotechnologies
 Effect
RNSAPbasicmobilitymoduleisenhancedtoallow
themobilitytoandfromGERANcellsinthetarget
andthesource
RNSAPglobalmoduleisenhancedinordertoallow
GERANcellsmeasurementstobeexchanged
betweencontrollers
allowsaCommonRadioResourceManagement
(CRRM)betweenUTRANandGERANradios
 Iurginterface
refertotheabovementionedsetofIurfunctionalities
thatareutilizedalsobyGERAN
5.7UMTSCORENETWORK
ARCHITECTUREANDEVOLUTION
5.7.1Release99CoreNetworkElements
5.7.2Release5CoreNetworkandIPMultimedia
Subsystem
 UMTSradiointerface,WCDMA
abiggerstepinradioaccessevolutionfromGSM
networks
UMTScorenetwork
didnotexperiencemajorchangesin3GPPRelease99
specification
Release99structurewasinheritedfromGSM
corenetwork
bothUTRANandGERANbasedradioaccess
networkconnecttothesamecorenetwork
5.7.1RELEASE99CORENETWORK
ELEMENTS
TwodomainsofRelease99corenetwork
CircuitSwitched(CS)domain
PacketSwitched(PS)domain
Thedivisioncomesfromthedifferent
requirementsfordata
dependingonwhetheritisrealtime(circuit
switched)ornonrealtime(packetdata)
 Figure5.12
Release99corenetwork
structurewithbothCS
andPSdomains
Registers
HLR,VLR,EIR

ServiceControlPoint
(SCP)
thelinkforprovidinga

particularservicetoend
user
 CSdomainhasthefollowingelements
MobileSwitchingCentre(MSC),includingVisitor
LocationRegister(VLR)
GatewayMSC(GMSC)
 PSdomainhasthefollowing
elements
ServingGPRSSupport
Node(SGSN)
coverssimilarfunctions

asMSCforpacketdata,
includingVLRtype
functionality
GatewayGPRSSupport
Node(GGSN)
connectsPScore

networktoother
networks,e.g.tothe
Internet
 Inadditiontothetwodomains,thenetwork
needsvariousregistersforproperoperation
HomeLocationRegister(HLR)
EquipmentIdentityRegister(EIR)
containstheinformationrelatedtothe
terminalequipment
canbeusedto,e.g.,preventaspecificterminal

fromaccessingthenetwork
5.7.2RELEASE5CORENETWORK
ANDIPMULTIMEDIASUBSYSTEM
Release4includedthechangeincorenetwork
CSdomain
MSCwasdividedintoMSCserverandMedia
Gateway(MGW)
GMSCwasdividedintoGMSCserverandMGW
Release5
containsthefirstphaseofIPMultimediaSubsystem
(IMS)
thiswillenableastandardizedapproachforIPbased
serviceprovisionviaPSdomain
 Release6
enhanceIMStoallowthe
provisionofservicessimilartoCS
domainservicesfromPSdomain
Release5architectureispresented
inFigure5.13
HomeSubscriberServer(HSS)
shownasanindependentitem

SessionInitiationProtocol(SIP)
thekeyprotocolbetween

terminalandIMS
thebasisforIMSrelated

signaling
 MSCorGMSCserver
takescareofthecontrolfunctionalityas

MSCorGMSC,respectively
userdatagoesviaMediaGateway(MGW)
oneMSC/GMCSservercancontrolmultiple
MGWs
thisallowsbetterscalabilityofthenetwork

whendataratesincreasewithnewdata
services
inthiscase,onlythenumberofMGWs

needstobeincreased
MGWperformsactualswitchingforuserdata
andnetworkinterworkingprocessing
e.g.,echocancellationorspeechdecoding/

encoding
 IMSincludesthefollowingkey
elements
MediaResourceFunction(MRF)

controlsmediastreamresources

ormixesdifferentmedia
streams
CallSessionControlFunction

(CSCF)
thefirstcontactpointto

terminalintheIMS(asaproxy)
handlingofsessionstates

actingasafirewalltowards

otheroperatorsnetworks
 MediaGatewayControlFunction
(MGCF)
handleprotocolconversions
controlaservicecomingviaCS

domainandperformprocessingin
anMGW,e.g.forecho
cancellation