Umts Tout Ip

UMTS TOUT IPGROUPE 1FAISALSHERAZWASIQTHIAM

All rights reserved for DESS-IRS

Presentations Architecture du UTRAN avec IP Moussa Equipement Terminal Sheraz RNCServices (IP) WASIQ OSA / VHE (VoIP) QOS Faisal Multicast


UMTS TOUT IP


MODELE EN COUCHES


Couches de protocole dans UMTS

Node-B

RNCUuIuGnUuIuGn

UE

RNSUTRAN

PDCPGTP-URLCUDP/IPMACAAL5WCDMAATM

GTP-UGTP-UUDP/IPUDP/IPAAL5L2ATML1

ApplicationE.g., IP,PPPPDCPRLCMACWCDMA

E.g., IP,PPPGTP-UUDP/IPL2L1

PDCPGTP-URLCUDP/IPMACAAL5WCDMAATM

GTP-UGTP-UUDP/IPUDP/IPAAL5L2ATML1

ApplicationE.g., IP,PPPPDCPRLCMACWCDMA

E.g., IP,PPPGTP-UUDP/IPL2L1


UMTS TOUT IP


CONCEPT WCDMA MULTIPLEXAGEFDD EN FREQUENCEBANDES APPAIREES2 PORTEUSES (liaisons montante et descendante)pour utilisation couranteTDD EN TEMPS1 PORTEUSE(utilisation haut debit)


LES CANAUX DE LINTERFACE RADIO


UMTS TOUT IP


NUD B(station de base dans UMTS)GESTION DE LA COUCHE PHYSIQUE DE LINTERFACE AIRCODAGE DU CANALENTRELACEMENT ADAPTATION DU DEBIT


UMTS TOUT IP


UTRAN(UMTS Terrestrial Radio Acces Network)Two major elements;

RNC (Radio Network Controller)Node B RNC (Radio Network Controller), which own and controls the radio resources in its domain i.e. the Node Bs connected. RNC is the service access point for all services UTRAN provides to CN.

MSC,SGSN and HLR can be extended to UMTS requirements.RNC and Node B are completely new designs.


GoalMaximization in handling of packet switched and circuit switched data.

IP based protocols such RTP (data transport) and SIP (Signaling control) protocols

ATM is currently main transport mechanism in the UTRAN.


Primary functions RNC! Uplink and downlink signal transfer! Mobility! Add and delete cells during soft hand-off! Macro-diversity during handover! Uplink Outer Loop Power Control functionality! Downlink Power Control! Controls common physical channels, which are used by multiple users! Interfaces with SGSN and MSC/VLR


Types of RNCCRNC (Controlling RNC) Responsible for the load and congestion control of its own cellsSRNC (Serving RNC)Terminates both Iu link for the transport of user data and the corresponding RANAP signaling to/from the core network. DRNC (Drift RNC) Controls cells used by the mobile. When is required the DRNC performs macro-diversity combining and splitting.


Protocol for UTRAN Interfaces


Layered ArchitectureHorizontal layers have two main layers:! Radio Network layer! Transport Network Layer

Vertical planes have four main planes:! Control Plane! User Plane! Transport Network Control Plane! Transport Network User Plane


IP implementation


Diversified positions in UMTSMost important issues that are emphasize SSCF layer SSCOP layerspecifically designed for transport in ATM networks and which take care of solutions such as signaling connection management.Already IP based consists; M3UA (SS7 MTP3 _user adaptation Layer)SCTP (Simple Control Transmission Protocol) IP (Internet Protocol),AAL5(ATM Adaptation Layer 5).


IP implementations in IurApplication layer, RNSAP, connects to its signaling bearer via an SCCP-SAP (Service Access Point).Signaling bearer is ATM based. The SCCP layer provides both connectionless and connection-oriented service.Below SCCP, the operator is able to select from one of two switches a) MTP3-B/SCCFNNI/SSCOP b) SCTP/IP.


GlossaryUMTS Universal Mobile Transmission SystemRNC Radio Network ControllerCN Core NetworkSGSN Serving GPRS NodeGPRS Global Packet Radio ServiceUSIM UMTS Subscriber Identity ModuleUu UMTS air interfaceIub Interface between Node B and RNCIur Interface between two RNCGSMC Gateway MSCPLMN Public Land Mobile NetworkGGSN Gateway GPRS Support NodeSSCF Service Specific Coordination FunctionSSCOP Service Specific Connection Oriented Protocol


Toward an All-IP Based UMTS System Architecture


TransitionsShift from R99 to R00 standardReplacment of Circuit Switced transport technology by Packet technologyIntroduction of multimedia support in the UMTS Core NetworkEvolution of Open Service Architecture (OSA)Apart from the official bodies ( 3GPP, 3GPP2) other partnerships and foras started polling in to the success of an all-IP based UMTS architecture.


The 2 TrendsThe trend in the design of UMTS service architecture to standardize Open Network InterfaceThe trend in the design of the UMTS network architecture to move towards an IP based approach


OSAObliged network operators to provide third party service providers access to their UMTS service architecture via open standardized interfacesDevelopment of OSA interfaces through the Parlay/OSA API API presented by the Joint API Group consisting of Parlay and 3GPP


OSA/Parley APIParlay APIs try to open telecommunication networks to third party service providers.


A change in business model has introduced new players in the telecomm businessand they have no network!

THE TECHNICAL ENABLER = PARLAY/OSA


Control layerService Capability ServersOSA/Parlay APIsexposing network service capabilitiesDistribution via middlewareParlay / OSAServices/application layerConnectivity layerCore & Radio Networks2G 2.5G & 3GCore networkService networkPresence of Parley/OSA


Open Service Architecture


Role of SCS in service provisioningUMTS Call Control ServersHLRMExESATCAMEL


From OSA to VHEIntervention of European Commission Opening of application interfaces towards the networksLiberalization of telecommunication services marketEnhancing portability of telecommunication services between network and terminalsService portability = Virtual Home Environment (VHE)


Virtual Home Environment (VHE)ConceptProvide user an environment to access the services of his home network/service provider even while roaming in the domain of another network provider.


Introduction to VoIP in MobileMoving towards an all IP Network


VoIP pros and consAdvantages Lower equipment costEasier management of networkUsage of Techniques like silence suppressionHence lower communication cost to userUse of end to end IP, opens path to multimedia over IP services like video conferencingUsing same technology (IP services) in fixed and mobile networks facilitates internetworking

DisadvantageQoSDelays by handoverScarce radio resourcesAdmission control


Enabling PacketsMSC divisionMSC for Call ControlMG for switching (IP Router)MG at the UTRAN sideMG at the PSTN sideMGCF for MGSignaling GatewayCSCF (Call State Control Function)HSS


Interworking Two WorldsIN/AIN NetworkSIPServerVideoServerApplicationServer


For transport of Data TrafficUMTS uses GPRSFor transport of Voice CallsPacket Switched mobile terminalsCalls transmitted using GTP GTP works over IPAll Mobility dealt with by GPRSCircuit Switched mobile terminalsVoice samples travel between MGs using IP using Iu Frame Protocol (FP).No GTPMG Handover


2 Scenarios for Providing VoIP Services SoftSSP Concept : INAP / CAP support of VOIPPreviously implementation of service logic from network switchNOW IN allows controlling the service from a centralized point (SCP) outside the switchIN relies on SSPs in the switches to trigger the SCP via the IN Application Part (INAP) protocol when IN service control is needed. Power of IN/CAMEL in complexity of SSP and INAP/CAP


SoftSSP (Continued)the SSP contains a mapping determines which point in the MSC call state model needs to trigger which point in the state model of the IN/CAMEL service logicThe more complex the mapping, the more complex the service


SoftSSP (Continued)IN/CAMEL on a SIP serverDevelop SSP on top of SIP Servera mapping between the SIP call state model and the state model of the IN/CAMEL service logicThis kind of SSP is called as SoftSSPInvestment on CAMEL can be reused for providing VoIP on a CSCF.Billing and database handling process can be reused from the R99 SSP circuit-switched call control


Direct Third Party Call ControlOSA Support for VoIP(Via CGI/CPL or SIP)Third Party Call control mechanismsSIP ( already well known)CGLCPL Used to instruct network entites to create and terminate calls to other network entitiesCGL and CPL allow independence from the SIP server logic.Concept similar to IN but there is no SCP control


ContinuedCGI For trusted userstriggered when the first request arrivesCPL Untrusted usersAllows users to load CPL scripts on networksReads and verifies scriptsControlled party executes instructionMessages sent back to CPL Controller


Quality of ServiceEnd to End


QoS to the Content & Services OperatorThe ability of the network to predictably deliver content & services to subscribers, consistent with their expectation, and therefore resulting in a overall satisfactory user experience is related toPerceived Voice or Video QualityQuantified by Jitter (aka delay variation)Quantified by ThroughputPerceived response timeQuantified by RTT and Uni-directional End to End delay (aka Latency)Quantified by ThroughputPerceived Availability/ReliabilityQuantified by Network Utilization And 24/7 Service Level Monitoring


End to End QoS TestingTraditional performance testing focused on per flow measurements at the lowest layer (data link layer)ATM ( Cell rate, Cell Delay, etc) Frame Relay (Frame Rate, Frame Delay, etc)Traditional testing is still necessary but no longer enoughQoS testing must now be End to End Higher Layer (Network and Transport)IP (Packet Rate, Packet Delay) TCP (Segments)This approaches a quantitative measure that is much closer to the subscribers true experience


Active (Intrusive) QoS TestingMeasured MetricsPacket LossDelay & JitterThroughputSequencingInvolves generation and monitoring of test traffic to simulate real world scenariosApplicabilityLab EvaluationsProvisioning of New ServicesTroubleshooting


Passive (Non-Intrusive) QoS TestingMeasured MetricsPacket LossRTT & DelayThroughputApplicabilityContent DeliveryService AssuranceNetwork OptimizationBilling MediationInvolves passive monitoring of customer traffic


RadioSystemsMaintaining QoSAre there Database Problems?Are the GPRS Support Nodes Dropping Packets?

Is there a Capacity Problem?Why is my email frozen

Why are my calls disconnecting?Why cant I get Access?

Should theAntenna be Adjusted ?

Should the cell be split?

Are Data & Voice channels properly allocated?Is the ISP causing the DelayPublic VoiceNetworkInternetMSC VLRSGSNGGSNxRAN


QoS Example: Effects of mobility


UMTS QoS Architecture


4 Classes of QoS in UMTS


Le Multicast dans UMTS tout IP


Plan

1. Le multicast dans les rseaux IP2. Le multicast dans les rseaux UMTS3. Le multicast dans le GGSN4. Le multicast dans le RNC5. Le multicast dans le Node-B


Multicast : Pourquoi faire ?1. Vido confrence, Diffusion Vido. 2. Avantages du Multicast : Economie de bande passante, bande passante limit dans le UMTS Economie des ressources dans les serveurs


Unicast dans les rseau IP


Multicast dans les rseau IP


Multicast dans UMTSQuel Architecture Choisir ?Architecture du Multicast dans le GGSN

Architecture du Multicast dans le RNC

Architecture du Multicast dans le Node B


Chaque terminal client multicast doit avoir un lien tablit avec le GPRSChaque terminal client multicast doit crer un lien (PDP) avec le GGSN pour le protocole IGMPLe terminal UMTS est maintenant dans lenvironnement IGMP et peut joindre ou quitter le groupe multicast en utilisant la signalisation IGMP.Rgle pour recevoir ou envoyer une trame multicast :


Architecture du Multicast dans le GGSN

SGSNRNCHLR/AuC/EIR/CGFNode-B InternetRNCNode-BTerminalTerminalTerminalTerminalGGSNMulticastUnicastUnicastUnicastUnicastUnicast1 Circuit PDP/Terminal pour le UMTS1 Circuit PDP/Terminal pour le protocole ICMPSource Multicast


Les inconvnients de cette architecture

Lorsquun membre dcide de quitter le multicast groupe, la source multicast UMTS ne reoit pas cette information.2. Lorsque tous les membres ont quitt le multicast groupe, la source multicast continue transmettre les donnes GGSN.Larchitecture multicast a aussi besoin de ressource pour ses propres protocoles ( PIM-SM) et le GGSN doit pouvoir grer le protocole IGMP.Surcharge important sur le GGSN qui peut entraner de la congestion Le GGSN doit crer un circuit PDP pour la signalisation du protocole IGMP et un circuit PDP pour le transport des donnes. Le multicast des donnes vue dans cette architecture demande deux fois plus de ressources PDP que lunicast


Architecture avec Multicast dans le RNC

Architecture au Multicast dans le RNC

SGSNRNCHLR/AuC/EIR/CGF InternetRNCGGSNMulticastMulticastNode-BNode-BTerminalTerminalTerminalTerminalMulticastMulticastUnicastUnicastUnicastUnicastSource Multicast1 Circuit PDP/Terminal pour le UMTS1 Circuit PDP/Terminal pour le protocole ICMP


Avantages et Inconvnients Avantages :La charges du GGSN est rduite par rapport la solution prcdente.

Cette architecture permet au terminal de spcifier ses exigence de QoS au RNC

Permet de contrler les admissions et les congestions pour chaque flux de donnes. Inconvnients :Linformation de rsiliation dun client multicast ne remonte toujours pas la source qui continue dmettre les donnes multicast. Deplus, lorsquun terminal sengage pour tre un client multicast, cette information nest pas remont au GGSN, il y aura donc des problmes de facturation des services multicast. Il faut dvelopper un protocole de signalisation entre le RNC et SGSN pour rsoudre ce problme.

Lorsque la source multicast provient dun autre domaine que celui du SGSN ou GGSN, le packet sera rejet par le multicast routeur du RNC. Pour rsoudre ce problme, il faudrait que le GGSN puisse agir comme la source du multicast ce qui signifie que le roaming ne peut fonctionner pour le multicast.

Il nexiste pas de mcanisme permettant de crer un canal de donn entre le RNC et le terminal UMTS, il en est de mme dans le cur du rseau UMTS.


Architecture avec Multicast dans le Node-B

Architecture au Multicast dans le RNC

SGSNRNCHLR/AuC/EIR/CGF InternetRNCGGSNMulticastMulticastNode-BNode-BTerminalTerminalTerminalTerminalMulticastMulticastUnicastUnicastMulticastMulticastSource Multicast1 Circuit PDP/Terminal pour le UMTS1 Circuit PDP/Terminal pour le protocole ICMP


Avantages et Inconvnients Avantages :La mobilit sera bien visible de larbre multicast dont la racine se trouve dans le Node-B Sachant que le handover dans UMTS se fera au niveau soft, et que lors du handover les deux node-B seront en liaison avec le terminal alors le handover multicast se fera avant le handover rel.

Inconvnients :Il nexiste pas de mcanisme de broadcast de donne entre le Node-B et le terminal UMTS.

Il nexiste pas de mcanisme dimplmentation de larbre de distribution dans le Core de UMTS.

Linformation de rsiliation dun client multicast ne remonte toujours pas la source qui continue dmettre les donnes multicast. Deplus, lorsquun terminal sengage pour etre un client multicast, cette information nest pas remont au GGSN, il y aura donc des problmes de facturation des services multicast. Il faut dvelopper un protocole de signalisation entre le Node-B et SGSN pour rsoudre ce problme.


Point amliorer :

Pour chacun de ces architectures, il faut quun protocole spcifique puisse grer la distribution des clefs et de lencryptage des donnes par la source multicast afin que seul les membres du service multicast puisse recevoir ce service et pas les autres.

On peut dcentraliser la fonction de facturation du GGSN au SGSN, mais pour cela il faut concevoir un canal de signalisation entre SGSN et la fonction routeur multicast o quelle se trouve dans le rseau.

Il faut que UMTS soit capable de reconnatre diffrent type de service multicast pour quune facturation par service puisse tre tablie.


ConclusionsLa premire solution darchitecture Multicast Routing dans GGSN : - Requiert peu de modification du rseau existant- le Multicast demande plus de ressources que l Unicast La seconde solution darchitecture Multicast Routing dans RNC : - Demande une modification modr du rseau existant. - Rduit la cration des circuits PDP dans le GGSN - Rduit donc la charge dans le Cur du rseau

La troisime solution darchitecture Multicast Routing dans Node-B : - Demande une modification substantiel du rseau existant - On ne pourra pas rutiliser les mcanismes de lUMTS existant - La mobilit est visible pour larbre de diffusion multicast. - Cette architecture est la bonne solution si on utilise une solution * avec des protocoles propritaire dans le UTRAN


Umts Tout Ip

Documents

Transcript of Umts Tout Ip