Umts Tout Ip

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

UMTS TOUT IP
MODELE EN COUCHES
Couches de protocole dans UMTS
PDCP GTP-U
RLC UDP/I
P
MAC AAL5
WCDM
A
ATM
GTP-
U
GTP-
U
UDP/
IP
UDP/
IP
AAL5 L2
ATM L1
Node-B

RNC
Application
E.g.,
IP,PPP
PDCP
RLC
MAC
WCDMA
E.g.,
IP,PPP
GTP-U
UDP/IP
L2
L1
Uu Iu Gn
PDCP GTP-U
RLC UDP/I
P
MAC AAL5
WCDM
A
ATM
GTP-
U
GTP-
U
UDP/
IP
UDP/
IP
AAL5 L2
ATM L1
Application
E.g.,
IP,PPP
PDCP
RLC
MAC
WCDMA
E.g.,
IP,PPP
GTP-U
UDP/IP
L2
L1
Uu Iu Gn

UE

RNS
UTRAN
UMTS TOUT IP
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)
LES CANAUX DE LINTERFACE
RADIO
UMTS TOUT IP
UMTS TOUT IP
NUD B(station de base dans
UMTS)
GESTION DE LA COUCHE PHYSIQUE DE
LINTERFACE AIR
CODAGE DU CANAL
ENTRELACEMENT
ADAPTATION DU DEBIT

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

a) RNC (Radio Network Controller)
b) 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.


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
SGSN
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.

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 RNC
1. CRNC (Controlling RNC)
Responsible for the load and congestion control of its
own cells
2. SRNC (Serving RNC)
Terminates both Iu link for the transport of user data and
the corresponding RANAP signaling to/from the core
network.
1. 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 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

IP implementation
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).

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.

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

Toward an All-IP Based UMTS
System Architecture
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.

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
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

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

A change in business model has
introduced new players in the telecomm
business
User
New Player
services
connectivity
Operator
connectivity
Some want to address
users directly
User
New Player
connectivity
+ services
Operator
connectivity
Some prefer to do it
via the Network Operator
But they have something in common:
They compete in the services market...

and they have no network!

THE TECHNICAL ENABLER = PARLAY/OSA
Control layer
Service Capability Servers
OSA/Parlay APIs
exposing
network service
capabilities
Distribution
via
middleware
Parlay / OSA
Services/application
layer
Connectivity layer
Core & Radio Networks
2G 2.5G & 3G
Presence of Parley/OSA
Parlay/OSA API
OSA Gateway
Mapping to network specific protocols
Network
Network complexity hidden from
applications
App1 App2 AppN
Applications (independent of
underlying network technology)
3GPP
ETSI
Parlay
JAIN
Open Service Architecture
Role of SCS in service
provisioning
UMTS Call Control Servers
HLR
MExE
SAT
CAMEL

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)

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.

Introduction to VoIP in Mobile
Moving towards an all IP Network
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

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

Interworking Two Worlds
IP/ATM Router
Optical DWDM
IN/AIN
Network
Circuit Switch
ATM
SONET/SDH
Optical Layer
SIP
Server
Video
Server
Application
Server
Signaling
Gateway
Signaling Gateway
SS7 over IP
Connects control and service
elements
Bridges service elements of
IN and SIP
Media
Gateway
Controller
Media Gateway Controller
Call state
Control of Media Gateways
Authorization, verification &
settlement
Media
Gateway
Media Gateway
Media adaptation
Addressing
Usage and QoS information
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

2 Scenarios for Providing VoIP
Services
1. 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
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

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
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
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

Quality of Service
End to End
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
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

Active (Intrusive) QoS Testing
Measured
Metrics
Packet Loss
Delay &
Jitter
Throughput
Sequencing
Involves generation and monitoring of test traffic to
simulate real world scenarios
Applicability
Lab Evaluations
Provisioning of
New Services
Troubleshooting
Test Frame or CELL
HEADER Sequence Number Timestamp CRC
Abis Gb
BSC BTS
GSM RAN
Internet
SGSN GGSN
CN PS-Domain
Gn Gi
Passive (Non-Intrusive) QoS
Testing
Measured
Metrics
Packet Loss
RTT & Delay
Throughput
Applicability
Content Delivery
Service Assurance
Network Optimization
Billing Mediation
Abis Gb
BSC BTS
GSM RAN
Internet
SGSN GGSN
CN PS-Domain
Gn Gi
Involves passive monitoring of customer traffic
Radio
Systems
Maintaining QoS
Are there
Database
Problems
?
Are the GPRS
Support
Nodes
Dropping
Packets?

I s there a
Capacity
Problem?
Why is my
email frozen

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

Should the
Antenna be
Adjusted ?

Should
the cell be
split?

Are Data & Voice
channels properly
allocated?
I s the I SP
causing the
Delay
HLR
Public Voice
Network
Internet
MSC
VLR
SGSN GGSN
xRAN
QoS Example: Effects of mobility
Throughput decreases during cell changes
UMTS QoS Architecture

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
-Preserve payload
content

Example of
the application

voice

streaming
video

web
browsing

telemetry,
emails

4 Classes of QoS in UMTS
Le Multicast dans UMTS tout IP
Plan

1. Le multicast dans les rseaux IP
2. Le multicast dans les rseaux UMTS
3. Le multicast dans le GGSN
4. Le multicast dans le RNC
5. 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 UMTS
Quel 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 GPRS
Chaque terminal client multicast doit crer un lien (PDP)
avec le GGSN pour le protocole IGMP
Le 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

SGSN
RNC
HLR/AuC/EIR/CGF
Node-B
Internet
RNC
Node-B
Terminal
Terminal
Terminal
Terminal
GGSN
Multicast Unicast Unicast
Unicast
Unicast
Unicast
1 Circuit PDP/Terminal pour le UMTS
1 Circuit PDP/Terminal pour le protocole ICMP
Source
Multicast
Les inconvnients de cette architecture

1. 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.
3. Larchitecture multicast a aussi besoin de ressource pour ses
propres protocoles ( PIM-SM) et le GGSN doit pouvoir grer le
protocole IGMP.
4. Surcharge important sur le GGSN qui peut entraner de la
congestion
5. 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

SGSN
RNC
HLR/AuC/EIR/CGF
Internet
RNC
GGSN
Multicast
Multicast
Node-B
Node-B
Terminal
Terminal
Terminal
Terminal
Multicast
Multicast
Unicast
Unicast
Unicast
Unicast
Source
Multicast
Avantages et Inconvnients
Avantages :
1. La charges du GGSN est rduite par rapport la solution prcdente.

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

3. Permet de contrler les admissions et les congestions pour chaque flux de
donnes.
Inconvnients :
1. 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.

2. 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.

3. 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

SGSN
RNC
HLR/AuC/EIR/CGF
Internet
RNC
GGSN
Multicast
Multicast
Node-B
Node-B
Terminal
Terminal
Terminal
Terminal
Multicast
Multicast
Unicast
Unicast
Multicast
Multicast
Source
Multicast
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.

Conclusions
La 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

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Umts Tout Ip

Загружено:

Авторское право:

Доступные форматы

All rights reserved for DESS-IRS 1

Вам также может понравиться