GROUPE 1 FAISAL SHERAZ WASIQ THIAM UMTS TOUT IP GROUPE 1 FAISAL SHERAZ WASIQ THIAM All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Presentations Architecture du UTRAN avec IP Moussa Equipement Terminal Sheraz RNC Services (IP) WASIQ OSA / VHE (VoIP) QOS Faisal Multicast All rights reserved for DESS-IRS

All rights reserved for DESS-IRS UMTS TOUT IP All rights reserved for DESS-IRS

All rights reserved for DESS-IRS MODELE EN COUCHES All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Couches de protocole dans UMTS RNS UTRAN Application E.g., IP,PPP PDCP RLC MAC WCDMA Application E.g., IP,PPP PDCP RLC MAC WCDMA E.g., IP,PPP GTP-U UDP/IP L2 L1 E.g., IP,PPP GTP-U UDP/IP L2 L1 PDCP GTP-U RLC UDP/IP MAC AAL5 WCDMA ATM PDCP GTP-U RLC UDP/IP MAC AAL5 WCDMA ATM GTP-U UDP/IP AAL5 L2 ATM L1 GTP-U UDP/IP AAL5 L2 ATM L1 Node-B RNC UE Uu Uu Iu Iu Gn Gn All rights reserved for DESS-IRS

All rights reserved for DESS-IRS UMTS TOUT IP All rights reserved for DESS-IRS

CONCEPT WCDMA MULTIPLEXAGE FDD EN FREQUENCE BANDES APPAIREES 2 PORTEUSES (liaisons montante et descendante)pour utilisation courante TDD EN TEMPS 1 PORTEUSE(utilisation haut debit) All rights reserved for DESS-IRS

LES CANAUX DE L’INTERFACE RADIO All rights reserved for DESS-IRS

All rights reserved for DESS-IRS

All rights reserved for DESS-IRS UMTS TOUT IP All rights reserved for DESS-IRS

All rights reserved for DESS-IRS UMTS TOUT IP All rights reserved for DESS-IRS

NŒUD B(station de base dans UMTS) GESTION DE LA COUCHE PHYSIQUE DE L’INTERFACE AIR CODAGE DU CANAL ENTRELACEMENT ADAPTATION DU DEBIT All rights reserved for DESS-IRS

All rights reserved for DESS-IRS UMTS TOUT IP All rights reserved for DESS-IRS

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. All rights reserved for DESS-IRS

All rights reserved for DESS-IRS

All rights reserved for DESS-IRS UTRAN PSTN/ISDN GMSC MSC RNC HLR UTRAN: Terrestrial Radio Access Network RNC: Radio Network Controller BTS UTRAN transport: ATM New tricks: Soft Handover IP GGSN Packet core NW SGSN All rights reserved for DESS-IRS

All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Goal Maximization 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. All rights reserved for DESS-IRS

All rights reserved for DESS-IRS

All rights reserved for DESS-IRS 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 All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Types of RNC CRNC (Controlling RNC) Responsible for the load and congestion control of its own cells SRNC (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. All rights reserved for DESS-IRS

Protocol for UTRAN Interfaces All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Layered Architecture Horizontal 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 All rights reserved for DESS-IRS

All rights reserved for DESS-IRS

All rights reserved for DESS-IRS IP implementation All rights reserved for DESS-IRS

Diversified positions in UMTS Most important issues that are emphasize SSCF layer SSCOP layer specifically 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). All rights reserved for DESS-IRS

IP implementations in Iur Application 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. All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Glossary UMTS Universal Mobile Transmission System RNC Radio Network Controller CN Core Network SGSN Serving GPRS Node GPRS Global Packet Radio Service USIM UMTS Subscriber Identity Module Uu UMTS air interface Iub Interface between Node B and RNC Iur Interface between two RNC GSMC Gateway MSC PLMN Public Land Mobile Network GGSN Gateway GPRS Support Node SSCF Service Specific Coordination Function SSCOP Service Specific Connection Oriented Protocol   All rights reserved for DESS-IRS

Toward an All-IP Based UMTS System Architecture All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Transitions Shift from R99 to R00 standard Replacment of Circuit Switced transport technology by Packet technology Introduction of multimedia support in the UMTS Core Network Evolution 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. All rights reserved for DESS-IRS

All rights reserved for DESS-IRS The 2 Trends The trend in the design of UMTS service architecture to standardize Open Network Interface The trend in the design of the UMTS network architecture to move towards an IP based approach All rights reserved for DESS-IRS

All rights reserved for DESS-IRS OSA Obliged network operators to provide third party service providers access to their UMTS service architecture via open standardized interfaces Development of OSA interfaces through the Parlay/OSA API API presented by the “Joint API Group” consisting of Parlay and 3GPP All rights reserved for DESS-IRS

All rights reserved for DESS-IRS OSA/Parley API Parlay APIs try to open telecommunication networks to third party service providers. All rights reserved for DESS-IRS

All rights reserved for DESS-IRS A change in business model has introduced new players in the telecomm business User New Player connectivity + services Operator connectivity Some prefer to do it via the Network Operator User New Player services connectivity Operator Some want to address users directly But they have something in common: They compete in the services market... and they have no network! THE TECHNICAL ENABLER = PARLAY/OSA All rights reserved for DESS-IRS

Presence of Parley/OSA Parlay / OSA Services/application layer Service network OSA/Parlay API’s exposing network service capabilities Control layer Service Capability Servers Core network Distribution via middleware Connectivity layer Core & Radio Networks 2G 2.5G & 3G All rights reserved for DESS-IRS

All rights reserved for DESS-IRS App1 App2 AppN Applications (independent of underlying network technology) 3GPP ETSI Parlay JAIN Parlay/OSA API OSA Gateway Mapping to network specific protocols Network Network complexity hidden from applications All rights reserved for DESS-IRS

Open Service Architecture All rights reserved for DESS-IRS

All rights reserved for DESS-IRS

Role of SCS in service provisioning UMTS Call Control Servers HLR MExE SAT CAMEL All rights reserved for DESS-IRS

All rights reserved for DESS-IRS From OSA to VHE Intervention of European Commission Opening of application interfaces towards the networks Liberalization of telecommunication services market Enhancing portability of telecommunication services between network and terminals Service portability = Virtual Home Environment (VHE) All rights reserved for DESS-IRS

Virtual Home Environment (VHE) Concept Provide user an environment to access the services of his home network/service provider even while roaming in the domain of another network provider. All rights reserved for DESS-IRS

Introduction to VoIP in Mobile Moving towards an all IP Network All rights reserved for DESS-IRS

All rights reserved for DESS-IRS VoIP – pros and cons Advantages Lower equipment cost Easier management of network Usage of Techniques like silence suppression Hence lower communication cost to user Use of end to end IP, opens path to multimedia over IP services like video conferencing Using same technology (IP services) in fixed and mobile networks facilitates internetworking Disadvantage QoS Delays by handover Scarce radio resources Admission control All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Enabling Packets MSC division MSC for Call Control MG for switching (IP Router) MG at the UTRAN side MG at the PSTN side MGCF for MG Signaling Gateway CSCF (Call State Control Function) HSS All rights reserved for DESS-IRS

Interworking Two Worlds Media Gateway Controller Call state Control of Media Gateways Authorization, verification & settlement Signaling Gateway Signaling Gateway SS7 over IP Connects control and service elements Bridges service elements of IN and SIP IN/AIN Network SIP Server IP/ATM Router Optical DWDM Circuit Switch ATM SONET/SDH Optical Layer Media Gateway Media Gateway Media adaptation Addressing Usage and QoS information Video Server Application Server All rights reserved for DESS-IRS

All rights reserved for DESS-IRS For transport of Data Traffic UMTS uses GPRS For transport of Voice Calls Packet Switched mobile terminals Calls transmitted using GTP GTP works over IP All Mobility dealt with by GPRS Circuit Switched mobile terminals Voice samples travel between MGs using IP using Iu Frame Protocol (FP). No GTP MG Handover All rights reserved for DESS-IRS

2 Scenarios for Providing VoIP Services SoftSSP Concept : INAP / CAP support of VOIP Previously implementation of service logic from network switch NOW – IN allows controlling the service from a centralized point (SCP) outside the switch IN 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 All rights reserved for DESS-IRS

All rights reserved for DESS-IRS 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 logic The more complex the mapping, the more complex the service All rights reserved for DESS-IRS

All rights reserved for DESS-IRS SoftSSP (Continued…) IN/CAMEL on a SIP server Develop SSP on top of SIP Server a mapping between the SIP call state model and the state model of the IN/CAMEL service logic This kind of SSP is called as SoftSSP Investment 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 All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Direct Third Party Call Control OSA Support for VoIP(Via CGI/CPL or SIP) Third Party Call control mechanisms SIP ( already well known) CGL CPL Used to instruct network entites to create and terminate calls to other network entities CGL and CPL allow independence from the SIP server logic. Concept similar to IN but there is no SCP control All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Continued… CGI For trusted users triggered when the first request arrives CPL Untrusted users Allows users to load CPL scripts on networks Reads and verifies scripts Controlled party executes instruction Messages sent back to CPL Controller All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Quality of Service End to End All rights reserved for DESS-IRS

QoS to the Content & Services Operator The 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 to… Perceived Voice or Video Quality Quantified by Jitter (aka delay variation) Quantified by Throughput Perceived response time Quantified by RTT and Uni-directional End to End delay (aka Latency) Perceived Availability/Reliability Quantified by Network Utilization And 24/7 Service Level Monitoring All rights reserved for DESS-IRS

All rights reserved for DESS-IRS End to End QoS Testing Traditional 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 enough QoS 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 All rights reserved for DESS-IRS

Active (Intrusive) QoS Testing Involves generation and monitoring of test traffic to simulate real world scenarios Abis Gb BSC BTS GSM RAN Internet SGSN GGSN CN PS-Domain Gn Gi Applicability Lab Evaluations Provisioning of New Services Troubleshooting Measured Metrics Packet Loss Delay & Jitter Throughput Sequencing Test Frame or CELL HEADER Sequence Number Timestamp CRC All rights reserved for DESS-IRS

Passive (Non-Intrusive) QoS Testing Abis Gb BSC BTS GSM RAN Internet SGSN GGSN CN PS-Domain Gn Gi Involves passive monitoring of customer traffic Applicability Content Delivery Service Assurance Network Optimization Billing Mediation Measured Metrics Packet Loss RTT & Delay Throughput All rights reserved for DESS-IRS

Maintaining QoS Should the Antenna be Adjusted ? Are Data & Voice channels properly allocated? Is there a Capacity Problem? Radio Systems Should the cell be split? Public Voice Network HLR MSC VLR Are there Database Problems? Why can’t I get Access? xRAN Internet SGSN GGSN Why are my calls disconnecting? Is the ISP causing the Delay Why is my email frozen Are the GPRS Support Nodes Dropping Packets? All rights reserved for DESS-IRS

QoS Example: Effects of mobility Throughput decreases during cell changes All rights reserved for DESS-IRS

All rights reserved for DESS-IRS UMTS QoS Architecture All rights reserved for DESS-IRS

All rights reserved for DESS-IRS 4 Classes of QoS in UMTS Traffic class Conversational class Real Time Streaming class Real Time Preserve time relation (variation) between information entities of the stream Interactive class Best Effort Background class Best Effort Fundamental characteristics - Preserve time relation (variation) between information entities of the stream - Conversational pattern (stringent and low delay ) - Request response pattern -Preserve payload content -Destination is not expecting the data within a certain time Example of the application   voice streaming video   web browsing telemetry, emails All rights reserved for DESS-IRS

Le Multicast dans UMTS tout IP All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Plan 1. Le multicast dans les réseaux IP 2. Le multicast dans les réseaux UMTS 3. Le multicast dans le GGSN 4. Le multicast dans le RNC 5. Le multicast dans le Node-B All rights reserved for DESS-IRS

Multicast : Pourquoi faire ? 1. Vidéo conférence, Diffusion Vidéo. 2. Avantages du Multicast : Economie de bande passante, bande passante limité dans le UMTS Economie des ressources dans les serveurs All rights reserved for DESS-IRS

Unicast dans les réseau IP All rights reserved for DESS-IRS

All rights reserved for DESS-IRS

Multicast dans les réseau IP All rights reserved for DESS-IRS

All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Multicast dans UMTS Quel Architecture Choisir ? Architecture du Multicast dans le GGSN Architecture du Multicast dans le RNC Architecture du Multicast dans le Node B All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Règle pour recevoir ou envoyer une trame multicast : Chaque terminal client multicast doit avoir un lien établit avec le GPRS Chaque terminal client multicast doit créer un lien (PDP) avec le GGSN pour le protocole IGMP Le terminal UMTS est maintenant dans l’environnement IGMP et peut joindre ou quitter le groupe multicast en utilisant la signalisation IGMP. All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Architecture du Multicast dans le GGSN Source Multicast 1 Circuit PDP/Terminal pour le UMTS 1 Circuit PDP/Terminal pour le protocole ICMP Internet Unicast Unicast Unicast Unicast Multicast Terminal RNC Node-B GGSN Terminal SGSN Terminal Unicast RNC Node-B HLR/AuC/EIR/CGF Terminal All rights reserved for DESS-IRS

Les inconvénients de cette architecture Lorsqu’un membre décide de quitter le multicast groupe, la source multicast UMTS ne reçoit pas cette information. 2. Lorsque tous les membres ont quitté le multicast groupe, la source multicast continue à transmettre les données à GGSN. L’architecture multicast a aussi besoin de ressource pour ses propres protocoles ( PIM-SM) et le GGSN doit pouvoir gérer le protocole IGMP. Surcharge important sur le GGSN qui peut entraîner de la congestion Le GGSN doit créer un circuit PDP pour la signalisation du protocole IGMP et un circuit PDP pour le transport des données.  Le multicast des données vue dans cette architecture demande deux fois plus de ressources PDP que l’unicast All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Architecture avec Multicast dans le RNC Architecture au Multicast dans le RNC Source Multicast 1 Circuit PDP/Terminal pour le UMTS Internet 1 Circuit PDP/Terminal pour le protocole ICMP Unicast Unicast Multicast Terminal Multicast Multicast RNC Node-B GGSN Terminal Unicast Unicast SGSN Terminal Multicast RNC Node-B HLR/AuC/EIR/CGF Terminal All rights reserved for DESS-IRS

Avantages et Inconvénients La charges du GGSN est réduite par rapport à la solution précédente. Cette architecture permet au terminal de spécifier ses exigence de QoS au RNC Permet de contrôler les admissions et les congestions pour chaque flux de données. Inconvénients : L’information de résiliation d’un client multicast ne remonte toujours pas à la source qui continue d’émettre les données multicast. Deplus, lorsqu’un terminal s’engage pour être un client multicast, cette information n’est pas remonté au GGSN, il y aura donc des problèmes de facturation des services multicast. Il faut développer un protocole de signalisation entre le RNC et SGSN pour résoudre ce problème. Lorsque la source multicast provient d’un autre domaine que celui du SGSN ou GGSN, le packet sera rejeté par le multicast routeur du RNC. Pour résoudre ce problème, 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 n’existe pas de mécanisme permettant de créer un canal de donné entre le RNC et le terminal UMTS, il en est de même dans le cœur du réseau UMTS. All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Architecture avec Multicast dans le Node-B Architecture au Multicast dans le RNC Source Multicast 1 Circuit PDP/Terminal pour le UMTS Internet 1 Circuit PDP/Terminal pour le protocole ICMP Unicast Multicast Multicast Terminal Multicast Multicast RNC Node-B GGSN Terminal Unicast SGSN Multicast Terminal Multicast RNC Node-B HLR/AuC/EIR/CGF Terminal All rights reserved for DESS-IRS

Avantages et Inconvénients La mobilité sera bien visible de l’arbre 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 réel. Inconvénients : Il n’existe pas de mécanisme de broadcast de donnée entre le Node-B et le terminal UMTS. Il n’existe pas de mécanisme d’implémentation de l’arbre de distribution dans le Core de UMTS. L’information de résiliation d’un client multicast ne remonte toujours pas à la source qui continue d’émettre les données multicast. Deplus, lorsqu’un terminal s’engage pour etre un client multicast, cette information n’est pas remonté au GGSN, il y aura donc des problèmes de facturation des services multicast. Il faut développer un protocole de signalisation entre le Node-B et SGSN pour résoudre ce problème. All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Point à améliorer : Pour chacun de ces architectures, il faut qu’un protocole spécifique puisse gérer la distribution des clefs et de l’encryptage des données par la source multicast afin que seul les membres du service multicast puisse recevoir ce service et pas les autres. On peut décentraliser 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ù qu’elle se trouve dans le réseau. Il faut que UMTS soit capable de reconnaître diffèrent type de service multicast pour qu’une facturation par service puisse être établie. All rights reserved for DESS-IRS

All rights reserved for DESS-IRS Conclusions La première solution d’architecture Multicast Routing dans GGSN : - Requiert peu de modification du réseau existant - le Multicast demande plus de ressources que l’ Unicast La seconde solution d’architecture Multicast Routing dans RNC : - Demande une modification modéré du réseau existant. - Réduit la création des circuits PDP dans le GGSN - Réduit donc la charge dans le Cœur du réseau La troisième solution d’architecture Multicast Routing dans Node-B : - Demande une modification substantiel du réseau existant - On ne pourra pas réutiliser les mécanismes de l’UMTS existant - La mobilité est visible pour l’arbre de diffusion multicast. - Cette architecture est la bonne solution si on utilise une solution * avec des protocoles propriétaire dans le UTRAN All rights reserved for DESS-IRS