Download
1 / 76
760 likes | 1.14k Views
All rights reserved for DESS-IRS. 2. Presentations. Architecture du UTRAN avec IP Moussa Equipement Terminal Sheraz RNCServices (IP) WASIQ OSA / VHE (VoIP) QOS Faisal Multicast . All rights reserved for DESS-IRS. 3. UMTS TOUT IP. All rights reserved for DESS-IRS. 4. MODELE EN COUCHES.
E N D
1. All rights reserved for DESS-IRS 1 UMTS TOUT IP GROUPE 1
FAISAL
SHERAZ
WASIQ
THIAM
2. All rights reserved for DESS-IRS 2 Presentations Architecture du UTRAN avec IP
Moussa Equipement Terminal
Sheraz RNC
Services (IP)
WASIQ OSA / VHE (VoIP) QOS
Faisal Multicast
3. All rights reserved for DESS-IRS 3 UMTS TOUT IP
4. All rights reserved for DESS-IRS 4 MODELE EN COUCHES
5. All rights reserved for DESS-IRS 5 Couches de protocole dans UMTS
6. All rights reserved for DESS-IRS 6 UMTS TOUT IP
7. All rights reserved for DESS-IRS 7 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)
8. All rights reserved for DESS-IRS 8 LES CANAUX DE L’INTERFACE RADIO
9. All rights reserved for DESS-IRS 9
10. All rights reserved for DESS-IRS 10 UMTS TOUT IP
11. All rights reserved for DESS-IRS 11 UMTS TOUT IP
12. All rights reserved for DESS-IRS 12 NŒUD B(station de base dans UMTS) GESTION DE LA COUCHE PHYSIQUE DE L’INTERFACE AIR
CODAGE DU CANAL
ENTRELACEMENT
ADAPTATION DU DEBIT
13. All rights reserved for DESS-IRS 13 UMTS TOUT IP
14. All rights reserved for DESS-IRS 14 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.
15. All rights reserved for DESS-IRS 15
16. All rights reserved for DESS-IRS 16
17. All rights reserved for DESS-IRS 17
18. All rights reserved for DESS-IRS 18 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.
19. All rights reserved for DESS-IRS 19
20. All rights reserved for DESS-IRS 20 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
21. All rights reserved for DESS-IRS 21 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.
22. All rights reserved for DESS-IRS 22 Protocol for UTRAN Interfaces
23. All rights reserved for DESS-IRS 23 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
24. All rights reserved for DESS-IRS 24
25. All rights reserved for DESS-IRS 25 IP implementation
26. All rights reserved for DESS-IRS 26 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).
27. All rights reserved for DESS-IRS 27 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.
28. All rights reserved for DESS-IRS 28 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
29. All rights reserved for DESS-IRS 29 Toward an All-IP Based UMTS System Architecture
30. All rights reserved for DESS-IRS 30 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.
31. All rights reserved for DESS-IRS 31 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
32. All rights reserved for DESS-IRS 32 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
33. All rights reserved for DESS-IRS 33 OSA/Parley API Parlay APIs try to open telecommunication networks to third party service providers.
34. All rights reserved for DESS-IRS 34 A change in business model has introduced new players in the telecomm business
35. All rights reserved for DESS-IRS 35 Presence of Parley/OSA
36. All rights reserved for DESS-IRS 36
37. All rights reserved for DESS-IRS 37 Open Service Architecture
38. All rights reserved for DESS-IRS 38
39. All rights reserved for DESS-IRS 39 Role of SCS in service provisioning UMTS Call Control Servers
HLR
MExE
SAT
CAMEL
40. All rights reserved for DESS-IRS 40 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)
41. All rights reserved for DESS-IRS 41 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.
42. All rights reserved for DESS-IRS 42 Introduction to VoIP in Mobile Moving towards an all IP Network
43. All rights reserved for DESS-IRS 43 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
44. All rights reserved for DESS-IRS 44 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
45. All rights reserved for DESS-IRS 45 Interworking Two Worlds
46. All rights reserved for DESS-IRS 46 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
47. All rights reserved for DESS-IRS 47 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
48. All rights reserved for DESS-IRS 48 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
49. All rights reserved for DESS-IRS 49 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
50. All rights reserved for DESS-IRS 50 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
51. All rights reserved for DESS-IRS 51 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
52. All rights reserved for DESS-IRS 52 Quality of Service End to End
53. All rights reserved for DESS-IRS 53 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)
Quantified by Throughput
Perceived Availability/Reliability
Quantified by Network Utilization
And 24/7 Service Level Monitoring
QoS to the Content & Services Operator
54. All rights reserved for DESS-IRS 54 End to End QoS Testing
55. All rights reserved for DESS-IRS 55
56. All rights reserved for DESS-IRS 56
57. All rights reserved for DESS-IRS 57
58. All rights reserved for DESS-IRS 58
59. All rights reserved for DESS-IRS 59
60. All rights reserved for DESS-IRS 60
61. All rights reserved for DESS-IRS 61 Le Multicast dans UMTS tout IP
62. All rights reserved for DESS-IRS 62
63. All rights reserved for DESS-IRS 63
64. All rights reserved for DESS-IRS 64 Unicast dans les réseau IP
65. All rights reserved for DESS-IRS 65
66. All rights reserved for DESS-IRS 66 Multicast dans les réseau IP
67. All rights reserved for DESS-IRS 67
68. All rights reserved for DESS-IRS 68
69. All rights reserved for DESS-IRS 69 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.
70. All rights reserved for DESS-IRS 70
71. All rights reserved for DESS-IRS 71 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
72. All rights reserved for DESS-IRS 72
73. All rights reserved for DESS-IRS 73 Avantages et Inconvénients Avantages :
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.
74. All rights reserved for DESS-IRS 74
75. All rights reserved for DESS-IRS 75 Avantages et Inconvénients Avantages :
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.
76. All rights reserved for DESS-IRS 76
77. All rights reserved for DESS-IRS 77
