Lte Fondamentaux

Les Fondamentaux du LTE
Christophe GRUET
Le LTE est un projet mené par l'organisme de standardisation 3GPP visant à préparer les
normes techniques de la future quatrième génération en téléphonie mobile. Il permet le
transfert de données à très haut débit avec une faible latence similaire à l ’ADSL. En théorie,
ce standard permet d’atteindre des débits de l’ordre de 50 à 75 Mbit/s en lien ascendant et
supérieur à 100 Mbit/s en lien descendant tout en les partageant entre les utilisateurs mobiles
d'une même cellule.
Pour les opérateurs, le LTE implique l’introduction d’une licence, d’un nouveau réseau d’accès,
et d’un nouveau réseau cœur uniquement paquet.
En terme de vocabulaire, le futur réseau s’appelle EPS (Evolved Packet System). Il est
constitué d’un nouveau réseau d’accès appelé LTE (Long Term Evolution) ou e-UTRAN
(enhanced Universal Terrestrial Access Network) et d’un nouveau réseau cœur appelé ePC
(Evolved Packet Core) aussi appelé SAE (System Architecture Evolution).
L’objectif de ce cours est d’ introduire la vision de bout en bout du réseau EPS avec son accès,
son réseau cœur en se focalisant sur les points fondamentaux tels que l’interface radio,
l’architecture, les interfaces, la gestion des sessions, la gestion de la mobilité et la gestion des
services.
1
PLAN
1. Introduction: Contexte de la normalisation LTE

2. EPS: Vue Globale
3. LTE vu du coté Radio : Interface Air & e-UTRAN
4. LTE vu du coté Cœur : EPC, IMS & PCC
5. Quelques Compléments : e-MBMS, SON & Home NodeB
6. Principes d’Ingénierie Radio du LTE
7. L’Evolution 4G LTE-Advanced
8. Conclusion
2
1. Introduction
Contexte de la normalisation LTE
Il existe 4 standards pour les systèmes 2G: le GSM (Global System for Mobile
communications) et ses dérivés; digital AMPS (D-AMPS/IS-136); code division multiple
access (CDMA) IS-95; et le personal digital cellular (PDC). Le GSM est de loin celui qui a eu
le plus de succès et qui est le plus largement déployé. D’abord utilisé dans la bande des 900
MHz, il a ensuite été étendu dans la bandes des 1800 MHz (système DCS) pour répondre à
des problématiques de saturation des fréquences. Le GSM a également été étendu hors
Europe et constitue une des composantes du PCS Américain (1900 MHz).
Les dérivés de la 2G – Différentes améliorations ont été normalisées: High Speed Circuit
Switched Data (HSCSD), General Packet Radio Services (GPRS), Enhanced Data Rates for
Global Evolution (EDGE).
La 3ème génération a été normalisée d’abord par l’ETSI puis par le forum 3GPP (3G
Partnership Project) en lien avec l’ITU (International Telecommunication Union) au travers du
projet “IMT-2000” qui définit la technique de transmission, le transport des services IP, le
roaming et les communications multimédia. Deux propositions émergent: wideband code
division multiple access (WCDMA) et CDMA2000.
Les dérivés de la 3G :
- HSDPA, High Speed Downlink Packet Access, qui est un service de données paquet
modulé en CDMA dans le sens réseau vers mobile avec des débits potentiels de plusieurs
Mbit/s (14,4 Mbit/s). Aujourd’hui, toutes les zones sont déjà mises à niveau en France avec
le HSPDA (3,6 Mbit/s).
- HSUPA, High-Speed Uplink Packet Access, qui est un protocole permettant des débits
remontants extrêmement élevés (jusqu’à 5.76 Mbit/s). Déploiement fin 2007.
3
Contexte Global
1G 2G 2.5G 3G 3.5G (3G+) 4G
AMPS (US) GSM (Europe) HSCSD (Europe) UMTS(3GPP) HSDPA(3GPP) LTE Advanced (3GPP)
C-Netz (All)
Public
IS136 (US) GPRS (Europe) CDMA2000(3GPP2) HSUPA(3GPP)

NMT (Europe du Nord)
R2000 (France)
IS95-A (US) IS136+ (US) 2.75G
TACS (GB - Italie) PDC (Japon) IS95-B (US) E-CSD (Europe) EV-DO 3.9G
J-TACS (Japon) (3GPP2)
-R PDC-P (Japon) E-GPRS (Europe) 3G-LTE (3GPP)
G SM UMB (3GPP2) †
1G 2G 2.5/2.75G 3G/4G
TETRA (Europe) TETRA-TEDS (Europe)

PMR
Solutions TETRAPOL (Europe) LTE en Overlay LTE-R ???

Propriétaires APCO-P25 (US)
80 90 96 98 00 05 10
19 19 19 19 20 20 20
W-PAN
LAN
Bluetooth: 802.15 (US - Europe)
802.3 (Ethernet)
Data
W-LAN
802.2 (LLC)
WiFi: 802.11 802.11 g (US)
802.5 ‘(Token Ring)
Hiperlan Hiperlan2 (Europe)
W-MAN
Cordless Backhaul BLR

Misc
802.16 802.16a Mobilité 4G Evolution

DECT (Europe)
(WiMAX fixe) (WiMAX) 802.16e 802.16m
CT1-CT2 (GB)
(WiMAX (WiMAX 4G)
PHS (Japon) 802.16d Mobile)
La 4ème génération: OFDMA (Orthogonal Frequency Division Multiple Access) sera

introduite dans les années à venir pour offrir des débits allant jusqu ’à 100 Mbits/s en débit
descendant (OFDMA) et 50 Mbit/s en débit montant (SC-FDMA).
Il faut différencier l ’accès GPRS et le réseau GPRS. Le réseau GPRS est constitué de
commutateurs de paquets et sert à transférer les paquets émis depuis des accès GPRS,
EDGE, W-CDMA, HSUPA ou HSDPA vers l ’Internet et les Intranets d ’entreprise. Par
ailleurs ce réseau sert à remettre au mobile des paquets émis par l ’Internet ou par les
Intranets.
Par contre l ’accès GPRS n ’est qu ’un accès possible parmi de multiples accès (GPRS,
EDGE, W-CDMA, HSUPA ou HSDPA) et offre un débit asymétrique relativement faible,
généralement, 10kbit/s dans le sens montant (du mobile au réseau) et 40 kbit/s dans le sens
descendant (du réseau au mobile).
EDGE qui n ’apparaît qu ’à l’accès permet d’augmenter les débits pour les services de
données (jusqu ’à 200 kbit/s en débit descendant) par rapport à l ’accès GPRS. Le même
réseau cœur GPRS supporte l ’accès EDGE.
La 3G avec W-CDMA (Wideband Code Division Multiple Access) permet des débits allant
jusqu ’à 384 kbit/s bidirectionnels. HSDPA (High Speed Downlink Packet Access) améliore
les débits descendants pouvant atteindre 14,4 Mbit/s et HSUPA (High Speed Uplink Packet
Access) améliore les débits montants pouvant atteindre 5,75 Mbit/s.
La 4G fait apparaître un nouveau réseau cœur pour les services de données et services
conversationnels appelé ePC (Evolved Packet Core). Les services conversationnels seront
offerts par ePC+IMS à la différence d’aujourd’hui où il y a un réseau cœur dédié pour offrir
ces services
4
Accès et Réseau mobiles
Accès Réseau
GSM
2G GPRS
GSM/NGN Mobile
EDGE IMS
EDGE+
Réseau
GPRS IP
W-CDMA GSM : Global System for Mobile Telecommunications
GPRS : General Packet Radio Service
3G HSDPA EDGE : Enhanced Data Rates for GSM Evolution,
W-CDMA : Wideband Code Division Multiple Access
HSUPA HSDPA : High Speed Downlink Packet Access
HSUPA : High Speed Uplink Packet Access
HSPA+ OFDMA : Orthogonal Frequency Division Multiple Access
SC-FDMA : Single Carrier FDMA
ePC : Evolved Packet Core IMS
IMS : IP Multimedia Subsystem
OFDMA Réseau
4G ePC IP
SC-FDMA
5
Le réseau mobile est constitué d ’un réseau d ’accès et d ’un réseau cœur.
Trois réseaux d ’accès sont possibles : 2G, 3G, 4G. Le réseau d ’accès 2G s ’appelle BSS (Base Station
Subsystem). Il supporte les technologies radio GSM, GPRS et EDGE. Le réseau d ’accès 3G s ’appelle
UTRAN (UMTS Terrestrial Radio Access Network). Il supporte les technologies radio W-CDMA, HSDPA,
HSUPA et HSPA+. Le réseau d ’accès 4G s ’appelle LTE (Long Term Evolution of 3G). Il supporte les
technologies radio OFDMA et SC-FDMA.
Le réseau coeur 2G/3G consiste en deux domaines : Domaine circuit et domaine paquet.
Le domaine circuit offre des services de téléphonie. Au départ constitué de commutateurs voix, il a évolué
vers une structure NGN Mobile appelée R4. Le domaine paquet appelé GPRS (General Packet Radio
Service) offre un accès plus (3G) ou moins (2G) haut débit au monde IP et à ses services.
Il faut différencier l ’accès GPRS et le réseau GPRS. Le réseau GPRS est constitué de commutateurs de
paquets et sert à transférer les paquets émis depuis des accès GPRS, EDGE, W-CDMA, HSUPA ou
HSDPA vers l ’Internet et les Intranets d ’entreprise. Par ailleurs ce réseau sert à remettre au mobile des
paquets émis par l ’Internet ou par les Intranets.
Par contre l ’accès GPRS n ’est qu ’un accès possible parmi de multiples accès (GPRS, EDGE, W-CDMA,
HSUPA ou HSDPA) et offre un débit asymétrique relativement faible, généralement, 10kbit/s dans le sens
montant (du mobile au réseau) et 40 kbit/s dans le sens descendant (du réseau au mobile).
EDGE qui n ’apparaît qu ’à l ’accès permet d ’augmenter les débits pour les services de données (jusqu ’à
200 kbit/s en débit descendant) par rapport à l ’accès GPRS. Le même réseau cœur GPRS supporte
l ’accès EDGE.
La 3G avec W-CDMA (Wideband Code Division Multiple Access) permet des débits allant jusqu ’à 384
kbit/s bidirectionnels. HSDPA (High Speed Downlink Packet Access) améliore les débits descendants
pouvant atteindre 14,4 Mbit/s et HSUPA (High Speed Uplink Packet Access) améliore les débits montants
pouvant atteindre 5,75 Mbit/s. Avec HSPA+ l ’UE peut utiliser deux porteuses avec par porteuse en HSDPA
21,6 Mbit/s et en HSUPA 5,75 Mbit/s.
La 4G fait apparaître un nouveau réseau cœur pour les services de données et services conversationnels
appelé ePC (Evolved Packet Core). Les services conversationnels seront offerts par ePC+IMS à la
différence d’aujourd’hui où il y a un réseau cœur dédié pour offrir ces services La 4G permettra des débits
allant jusqu ’à 100 Mbit/s pour les débits descendants avec la technologie OFDMA (Orthogonal Frequency
Division Multiple Access) et 50 Mbit/s pour les débits montants avec SC-FDMA Single Carrier Frequency
Division Multiple Access). 5
Accès et Réseau mobile ePC
Accès Réseau
2G GPRS
EDGE IMS
EDGE+
Réseau
ePC IP
W-CDMA
3G HSDPA
HSUPA
HSPA+ GPRS : General Packet Radio Service
EDGE : Enhanced Data Rates for GSM Evolution,
W-CDMA : Wideband Code Division Multiple Access
HSDPA : High Speed Downlink Packet Access
OFDMA HSUPA : High Speed Uplink Packet Access
OFDMA : Orthogonal Frequency Division Multiple Access
4G SC-FDMA : Single Carrier FDMA
SC-FDMA ePC : Evolved Packet Core
Accès IMS : IP Multimedia Subsystem
Non-3GPP
WiFi 6
Le réseau ePC est un réseau convergent qui a pour finalité de permettre la mobilité dés
paquets IP de l’UE quelque soit la technologie radio mobile utilisée (GPRS, EDGE, W-
CDMA, HSPA, HSPA+, LTE, WiFi).
C ’est le même nœud qui sert de point d ’ancrage pour les bearers de l ’UE (à savoir le
PDN GW), celui même qui a alloué l ’adresse IP à l ’UE.
6
Releases 3GPP
R99 R4 R5 R6 R7
2000 2001 2002 2003 2004 2005 2006

UMTS HSDPA HSUPA HSPA
NGN IMS
R8 R9 R10 R11
2007 2008 2009 2010 2011 2012 2013

LTE LTE-A
ePC
R12 ?
=
2014 2015
7
Release 3GPP: Points Importants
Release Evolution à l’accès Evolution dans le réseau cœur
R99 Nouveau réseau d’accès Nouveaux commutateurs MSC

appelé UTRAN supportant la voix et la vidéo-
Nouvelle technologie radio téléphonie
W-CDMA (384 kbit/s) Nouveaux commutateur SGSN
plus scalable
R4 IP dans l’UTRAN Emulation des commutateurs
MSC par NGN Mobile
R5 Nouvelle technologie radio IMS Phase 1 pour offrir des
HSDPA (jusqu’à 14,4 Mbits) services non temps réels
R6 Nouvelle technologie radio IMS Phase 2 pour offrir des
HSUPA (jusqu’à 5,75 Mbits) service temps réels (e.g., voix)
R7 Evolution EDGE (EDGE+) IMS Phase 3 indépendant de
Evolution HSPA (HSPA+) l’accès; PCC (Policy and Charging
Control) ; 3G Direct Tunnel (DT)
R8 Nouvelles technologies radio Nouveau réseau cœur ePC en
OFDMA et SC-FDMA mode paquet, Common IMS
R10 LTE-Advanced
Release 3: Introduit le réseau d’accès 3G ou UMTS appelé UTRAN (UMTS Terrestrial Radio Access
Network) constitué de NodeBs et de RNCs. La technologie que supporte UTRAN s’appelle W-CDMA qui
permet d’offre des services circuit tels que la téléphonie et la visiophonie ainsi que des services de données
avec un débit maximum de 384 kbit/s dans les sens montant et descendant. Dans le cœur de réseau il
s’agit de mettre à jour les MSC 2G afin qu’ils deviennent des MSC 3G et les SGSN 2G afin qu’ils supportent
l’accès 3G.
Release 4: Permet d’introduire le concept NGN mobile dans le domaine circuit. Avec le passage à la 3G, il
est difficile de faire évoluer les MSC 2G afin qu’ils s’interconnectent avec l’accès UTRAN. Les opérateurs
préfèrent remplacer les MSC 2G par une architecture NGN Mobile (R4) qui supporte les accès 2G ainsi que
les accès 3G. Avec le NGN mobile le transport de la voix dans le domaine circuit se fait sur IP met
uniquement dans le cœur de réseau.
Release 5: Introduit la technologie HSDPA à l ’accès par une mise à jour logicielle des Node B et RNC. Le
débit descendant devient égal à 14,4 Mbit/s alors que le débit montant reste inchangé par rapport à W-
CDMA. Les réseaux 3G déployés actuellement son principalement basés sur cette Release. L’architecture
IMS Phase 1 est aussi définie pour des services non temps -réels (e.g., présence, messagerie, etc) et pour
un accès 3G.
Release 6: Introduit la technologie HSUPA à l ’accès par une mise à jour logicielle des Node B et RNC. Le
débit montant devient égal à 5,75 Mbit/s. L’architecture IMS Phase 2 est aussi définie pour des services
non temps-réels (e.g., présence, messagerie, etc) et temps réel (e.g., téléphonie) pour un accès 3G.
Release 7: Les technologie HSPA+ (2 x HSPA ou 3 x HSPA) et EDGE+ (2 x EDGE) sont proposées.
L’architecture IMS Phase 3 est aussi définie pour des services non temps -réels (e.g., présence,
messagerie, etc.) et temps réel (e.g., téléphonie) pour tout type d ’accès large bande. Il s ’agit de Common
IMS.
Release 8: Introduit les technologies pré-4G appelées OFDMA (100 Mbit/s dans le sens descendant) et
SC-FDMA (50 Mbit/s dans le sens montant) pour 20 MHz de fréquence. Le nouveau réseau d ’accès pré-
4G est appelé LTE. La Release 8 définit par ailleurs un nouveau réseau cœur paquet pré-4G appelé ePC
(Evolved Packet Core). La Release 8 finalise aussi les spécifications concernant Common IMS initiées
dans la Release 7.
Release 10 introduit la LTE-Advanced. Elle permet 3 Gbit/s dans le sen descendant et 1,5 Gbit/s dans le
sens montant avec 100 Mhz de fréquence.
8
Débits pour les services de données
Technologie Débit descendant Débit montant Canal

GSM 9,6 kbit/s 9,6 kbit/s 200 kHz
GPRS 41,6 kbit/s (171,2) 20,8 kbit/s (171,2) 200 kHz
EDGE 236,8 kbit/s (473,6) 50 kbit/s (473,6 kbit/s) 200 kHz
EDGE Evolution 1 Mbit/s (1,9 Mbit/s) 500 kbit/s (1 Mbit/s) 200 kHz
W-CDMA(UMTS) 384 kbit/s 384 kbit/s 5 MHz
HSDPA 1-2 Mbit/s (7,2 Mbit/s) 5 MHz
HSUPA 1 Mbit/s (5,75 Mb/s) 5 MHz
HSPA 1-2 Mbit/s (7,2 Mbit/s) 1 Mbit/s (5,75 Mb/s) 5 MHz
HSPA+ 6 Mbit/s (43,2 Mbit/s) 2 Mbit/s (11,5 Mbit/s) 10 MHz
LTE 10-15 Mbit/s (100 Mbit/s) 6-8 Mbit/s (50 Mbit/s) 20 MHz
GPRS peut transporter le trafic de données de l’usager à des débits de 41,2 kbits dans
le sens descendant avec 4 timeslots (le débit maximum théorique est de 171,2 kbit/s
pour 8 timeslots opérant chacun à 21,4 kbit/s). En mode paquet. Le débit par timeslot en
pratique est de 10,4 kbit/s. Le débit montant pratique est limité à 20,8 kbit/s avec 2
timeslots..
EDGE peut transporter le trafic de données de l’usager avec un débit de 236.8 kbit/s
dans le sens descendant avec 4 timeslots (le débit maximum théorique est de 473.6
kbit/s avec 8 timeslots) en mode paquet. Le débit par timeslot est de 59,2 kbit/s. Le
débit montant pratique est limité à 118,4 kbit/s avec 2 timeslots.
Les opérateur WCDMA (3G) sont capables de fournit des débits montant et descendant
de 384 kbit/s.
La technologie 3,5G appelée HSDPA permet en théorie des débits descendants
pouvant atteindre 14,4 Mbit/s. Même s’il existe des terminaux pouvant fonctionner à 1,8
ou 3,5 ou 7,2 ou 10,8 Mbit/s, le débit offert par l’opérateur atteint un maximum autour de
1 Mbit/s en débit descendant. Le débit montant est celui de W-CDMA.
La technologie 3,75G appelée HSUPA permet en théorie des débits montants pouvant
atteindre 5,75 Mbit/s. Même s’il existe des terminaux pouvant fonctionner 2 Mbit/s, le
débit offert par l’opérateur atteint un maximum autour de 1 Mbit/s en débit montant. Le
débit descendant est celui de W-CDMA.
La technologie HSPA (HSDPA+HSUPA) permet donc des débit pratiques montant et
descendant de 1 Mbit/s.
La technologie HSPA+ permet de multiplier par 2 ou par 3 le débit de HSPA.
Enfin le débit pratique que permettra la technologie LTE sera d’environ 10 Mbit/s dans
le sens descendant et 6 Mbit/s dans le sens montant..
9
Latence (latency) moyenne à l’accès
La latence est le temps requis pour transmettre un signal d'un
Point à un autre d'un Réseau.
Dans le contexte 2G, il s’agit du temps de transmission des
donnéés entre la MS et le GGSN
GPRS : 700 ms
EDGE : 400 ms
Dans le contexte 3G, il s’agit du temps de transmission des

donnéés entre l’UE et le GGSN
WCDMA : 200 ms
HSDPA : 90 ms
HSUPA : 80 ms
HSPA+ : <50 ms
Dans le contexte LTE, il s’agit du temps de transmission des

donnéés entre l’UE et le PDN GW
LTE : 30 ms
10
La latence a une incidence majeure sur l’expérience utilisateur. En particulier, les

services conversationnels tels que la voix sur IP et la vidéotéléphonie requièrent une
latence courte. Les autres services qui bénéficieraient d’une petite latence sont les jeux
multimédia en réseau, l’IPTV, etc.
Comme les exigences de l’usager croient de plus en plus avec l’avènement des
nouvelles applications mobiles sur IP, les nouvelles technologies mobiles doivent être
conçues en les prenant en compte.
10
Evolution de l’Architecture
RTC RTC IP RTC IP
CS CS PS NGN PS
Accès Accès Accès
Architecture 2G Architecture Evolution 2G/3G

2G/2,5G/2,75G avec NGN
RTC RTC
RTC IMS IP IMS IP

EPS = LTE + ePC
NGN PS PS Réseau paquet
EPS : Evolved Packet System
LTE : Long Term Evolution
Accès Accès ePC : Evolved Packet Core
CS : Circuit Switched domain
3G avec Evolution IMS Architecture EPS PS : Packet Switched domain 11
Les réseaux mobile GSM (2G) ont été initialement conçus pour les services voix et autres services
s’appuyant sur la commutation de circuit. C’est la raison pour laquelle, cette génération de réseau
présentait une architecture relativement simple constituée de deux parties principales :
• Le réseau d’accès
• Le domaine cœur de commutation de circuit (CS, Circuit Switched Domain) fournissant les services
de la téléphonie aux clients mobiles et l’interfonctionnement avec le RTC.
Les réseaux mobiles 2,5G/2,75G correspondent à l’évolution paquet de la 2G. L’architecture de ces
réseaux consiste en deux parties :
• Le réseau d’accès 2G qui a été mis à jour pour supporter la transmission de paquet et des schémas
d’allocation de ressource partagée (pour la voix, la 2G dédie les ressources) pour GPRS (2,5G) et
EDGE (2,75G).
• Un nouveau réseau cœur (PS, Packet Switching Domain) qui est rajouté au domaine circuit (CS)
précédent.
Ce domaine paquet à le même rôle que le domaine paquet dans un but cette fois d’offrir des services de
données aux clients mobiles et assurer l’interfonctionnement avec les réseaux IP (Internet, Intranet).
D’un point de vue système, l’architecture de réseau 3G est plus ou moins celle de la 2G et inclut les
domaines circuit et paquet. Le domaine circuit peut être émulé par une architecture du réseau NGN
appelé R4 constituée de Media Gateway et de (G)MSC Server.
Il est aussi possible de rajouter un nouveau domaine aux domaines CS et PS, appelé IMS afin de fournir
des services conversationnels sur IP aux clients mobiles. En effet grâce à l’évolution de l’accès 3G vers le
haut débit, il sera possible d’envisager la fourniture de services conversationnels tels que la téléphonie de
bout en bout sur IP. Dans ces conditions, il est important de créer sur le mode paquet les plans de
signalisation et de service qui permettront d’émuler les services offert par le domaine circuit et de
nouveaux services grâce à la flexibilité d’IP.
L’architecture EPS (Evolved Packet System) a pour objectif d’intégrer toutes les application sur une
architecture commune et assez simple. Les principaux composants de l’architecture sont :
• Un réseau d’accès paquet qui peut efficacement supporter les services temps réel (e.g., la voix) et
non temps réel.
• Un réseau cœur composé d’un domaine paquet supportant les services de commutation de paquet
dont les services IMS et assurant l’interfonctionnement vers Internet, Intranets d’entreprise, et le RTC à
travers l’IMS.
Le domaine CS n’est plus présent car toutes les applications sont supportées sur un domaine PS.
11
Architecture GSM & GPRS
BSS SCP
BTS
HLR
MS BSC
BTS PCU SSP SS7/TDM

BTS
Fabric
VLR SSP
Frame RTC
MSC
Relay Fabric
NSS GMSC
IP Internet
Intranet
SGSN
NSS Paquet GGSN
12
Le GSM est un système de commutation de circuit conçu pour le transfert de la voix. Dans ce système, un paquet
est émis / reçu à un instant (timeslot) et une fréquence spécifique à la communication considérée. En GSM, la
ressource est donc immobilisée tout au long de la communication, qu'un signal soit émis ou non. Le débit obtenu
en transmission de données est limité à 9,6 kbit/s, ce qui rend le GSM peu adapté au transfert de données.
C'est ainsi qu'une nouvelle technologie a été amenée à se développer pour mener à bien l'évolution vers une
véritable solution d'accès mobile aux réseaux de données : le GPRS (General Packet Radio Service). Le GPRS
n'est pas à proprement parler un nouveau réseau : c'est en fait une évolution du réseau GSM qui permet la
transmission de données par paquet. Etant une étape importante entre la 2G et la 3G, le GPRS est souvent
désigné comme un système de 2,5G.
Parmi les caractéristiques principales du GPRS figurent :
Un accès paquet au niveau de l'interface radio avec optimisation de la ressource spectrale : les ressources radio
ne sont plus affectées en permanence à un utilisateur, mais elles sont partagées entre plusieurs utilisateurs
Une commutation de paquets au niveau du sous-système réseau avec optimisation des ressources réseau ;
Un débit théorique variable compris entre 9,6 kbits/s et 171,2 kbits/s ; En pratique, le débit pourra atteindre 40
kbit/s.
Un accès Internet standardisé ;
Une possibilité de taxation au volume (par rapport à la taxation à la durée)
Une applicabilité du GPRS pour les services existants (e.g., WAP) et pour les nouveaux services (e.g., MMS,
streaming, etc).
L'autre avantage du GPRS est qu'il a été conçu pour être intégré dans l'architecture GSM avec le minimum de
changements.
Le sous-système radio est mis à jour afin de supporter de nouveaux protocoles adaptés aux données par paquet.
Ces mises à jour sont principalement logicielles.
Si le réseau d’accès GSM est peu impacté par le GPRS, un nouveau sous-système réseau est intégré à celui du
GSM afin de permettre une interconnexion directe à l’Internet et l’acheminement des données en mode paquet.
Ainsi de nouveaux nœuds de commutation de paquet complètent les commutateurs de circuit du GSM. C'est le
sous-système radio qui démultiplexe les trafics voix et data et les achemine aux commutateurs appropriés (circuit
et paquet).
Il faut bien noter que la technologie GPRS est une technologie d ’accès permettant un débit concret de 40 kbit/s et
une technologie de commutation de paquet dans le réseau cœur. Ces mêmes commutateurs GPRS supportent
différentes technologie d ’accès pour offrir des débits de plus en plus importants : GPRS, EDGE, EDGE+, W-
CDMA, HSDPA, HSUPA, HSPA+.
12
Architecture UMTS R99
SCP
RNC HLR
Node B UTRAN
UE SSP SS7/TDM
ATM
ATM
Fabric
VLR SSP
Node B
MSC RTC
CN-CS Fabric
UE GMSC
RNC
IP Internet
Intranet
SGSN
CN-PS GGSN
13
UMTS (Universal Mobile Telecommunications System) aussi appelé 3G introduit une

nouvelle interface radio appelée UTRAN (UMTS Terrestrial Radio Access Network).
UTRAN va permettre aux usagers UMTS de disposer de débits suffisants pour établir des
sessions multimédia.
Le sous-système radio se compose de deux éléments distincts, à savoir le nœud B (node
B) et le contrôleur de réseau radio (RNC, Radio Network Controller). Le node B équivaut à
la BTS du réseau GSM. Le RNC équivaut à la BSC du réseau GSM. Le RNC possède et
contrôle les ressources radio des nodes B auquel il est connecté. Les échanges intra
UTRAN (NodeB-RNC & RNC-RNC) s’appuient sur ATM. Cette technologie de transport
est également utilisée pour les échanges entre l’UTRAN et les dimensions CS et PS du
cœur de réseau.
L’entité MSC/VLR évolue peu. A noter la présence désormais du coté CN des
fonctionnalités relative au codage de parole qui étaient en 2G traitées par le BSS.
L’entité 3G SGSN (Serving GPRS Support Node) s'occupe dans son aire de service des
transmissions de données entre les mobiles et le réseau mobile. Ses tâches incluent le
routage et le transfert de paquets, les fonctions attach/detach des terminaux mobiles et
leur authentification.
L’entité GGSN (Gateway GPRS Support Node) joue le rôle d’interface à des réseaux de
données externes (e.g., réseaux IPv4 et IPv6). Elle décapsule des paquets IP arrivant sur
un tunnel en provenance du SGSN et les envoie au réseau externe correspondant. Le
GGSN permet aussi d’acheminer les paquets IP provenant des réseaux de données
externes vers le SGSN du destinataire sur un tunnel.
La technologie W-CDMA utilisée par UMTS (3G) permet des débits montant et
descendant jusqu ’à 384 kbit/s depuis le mobile.
13
L’Usager Mobile
MSISDN =
33 6 11 23 24 25
IMSI =
Réseau 208 01 4356244811
3G USIM Card
IMEI =
435654
IMSI = 208 01 4356244811 45
056543
0
A chaque abonné est associé :
Un numéro MSISDN (Mobile Station ISDN Number) par lequel il
peut être appelé
Une identité IMSI (International Mobile Subscriber Identity) utilisé par
le réseau pour le repérer

A un équipement est associé un IMEI (International Mobile Equipment
Identity)
14
Lorsqu’un abonné souscrit à un abonnement mobile 3G auprès d ’un opérateur, il reçoit un

identifiant unique appelé IMSI (International Mobile Subscriber Identity). Ce numéro
d ’IMSI est stocké sur la carte SIM. Un téléphone mobile ne peut être utilisé que si une
carte SIM valide a été insérée ans l ’équipement mobile appelé User Equipment (UE) car
c ’est la seule façon de facturer correctement un abonné mobile.
Cet IMSI est un concept d ’adressage spécifique au GSM et est différent du plan de
numérotage RNIS.
Le numéro d ’IMSI n ’est pas connu de l ’abonné mobile et n ’est utilisé que par le réseau
GSM.
L’IMSI commence par un chiffre identifiant le continent (Europe = 2), puis deux chiffres
définissant le pays (France = 08), puis deux chiffres identifiant l ’opérateur dans le pays
(Orange France = 01; SFR = 10; Bouygues Telecom = 20) et finalement jusqu ’à 10
chiffres pour identifier le numéro de l ’abonné chez l ’opérateur. Exemple d ’IMSI : 2 08 01
4356244811.
Le numéro de téléphone du terminal mobile est le MSISDN (Mobile Station ISDN Number).
Exemple de MSISDN : 33 6 11 90 24 50. Il permet d ’être appelé.
33 identifie le pays. 611 identifie l ’opérateur dans le pays (SFR in France). 902450 est
l ’identification de l ’abonné mobile.
L ’IMEI identifie de façon unique un terminal mobile au niveau international. Il s ’agit d ’un
numéro de série. Ce numéro est alloué par le constructeur du terminal mobile.
14
Relations entre UE et Core Network
CM : Connection Management
MM : Mobility Management
GMM : GPRS Mobility Management
SM : Session Management
VLR : Visitor Location Register
MSC : Mobile Switching Center
SGSN : Serving GPRS Support Node
CC : Call Control
SM : Short Messaging
SS : Supplementary Services
MS/UE
MM Protocol VLR
CM = CC+SM1+SS
2G/3G MSC
GMM Protocol
SM1+ SM2 Protocol 2G/3G SGSN
15
Dans le réseau fixe, le téléphone est toujours rattaché au même commutateur d ’accès
(Class 5 Switch). Ce commutateur inclut une base de données stockant le profil des
abonnés. Le profil contient en particulier les marques de services complémentaires souscrits
par l'abonné rattaché à ce commutateur.
Le téléphone utilise un protocole de gestion des connexions pour l’établissement et la
libération d'appels; il s'agit du protocole de signalisation RNIS appelé Q.931 ou une
signalisation analogique (Off-hook, On-hook, Flash Hook, etc.). Par exemple, si l ’utilisateur
a un terminal RNIS, il émet le message de signalisation SETUP pour établir la
communication ; de même un appel entrant se présente au terminal RNIS à travers ce
message SETUP.
Dans un environnement mobile, une station mobile (MS, Mobile Station) n’est pas toujours
rattachée au même MSC. C’est la raison pour laquelle le mobile doit régulièrement informer
le réseau de sa localisation courante. Lorsqu’une station mobile est mise sous tension par
l ’usager, elle se rattache au réseau ; elle informe le MSC qui contrôle l ’aire dans laquelle
elle est présente, de sa localisation courante. Ce dernier met alors à jour sa VLR.
Afin de réaliser cette action d’enregistrement, un mobile utilise un protocole de gestion de la
mobilité (Mobility Management Protocol, MM). L'établissement et la libération d'appel par
le mobile sont possibles à travers la couche Communication Management (CM). Cette
couche permet au mobile d'établir et de libérer des appels (CC, Call Control), de disposer de
services complémentaires (SS, Supplementary Services) et d'échanger des messages
courts (SM, Short Message). Le protocole CC est similaire au protocole de signalisation
Q.931 utilisé par un terminal fixe RNIS.
Un mobile UMTS (UE, User Equipment) a aussi les capacités pour se rattacher à un réseau
GPRS et pour établir des contextes PDP (appels de données). Les protocoles utilisés pour
ce faire sont GMM (GPRS Mobility Management) et SM (Session Management)
respectivement.
15
Contexte PdP
SGSN GGSN1 ISP X

UE Same PDP (IP) address and APN
PDP Context X1 (APN X, IP address X, QoS1)
APN X
PDP Context X2 (APN X, IP address X, QoS2)
ISP Y
GGSN2
APN Y
PDP Context Y (APN Y, IP address Y, QoS)
APN Z
PDP Context Z (APN Z, IP address Z, QoS)
ISP Z
16
Un contexte PDP est un ensemble d'information qui caractérise un service de transmission de

base. Il regroupe des paramètres qui permettent à un abonné de communiquer avec une
adresse PDP définie (i.e., adresse IPv4 ou adresse IPv6), selon un protocole spécifique (IP4
ou IPv6), suivant un profil de Qualité de service déterminé (débit, délai, priorité...).
La procédure "PDP Context Activation", déclenchée à l'initiative de l'abonné mobile, permet
au terminal d'être connu de la passerelle GGSN qui réalise l'interconnexion avec le réseau
PDP externe demandé par l'abonné GPRS. La transmission de données entre le réseau
GPRS et le réseau PDP externe (réseau IPv4 ou réseau IPv6) peut alors débuter. La
procédure inverse de "PDP Context Activation" est la procédure "PDP Context Deactivation".
Il existe deux types de contexte PDP :
• Contexte PDP primaire qui ne peut être établi que par l ’usager.
• Contexte PDP secondaire qui peut être établi par l ’usager ou par le réseau (i.e.,
GGSN).
Une adresse IP est allouée par le GGSN à l ’usager lors de l ’établissement d ’un contexte
PDP primaire (pour une APN donnée). Un contexte PDP secondaire partage la même
adresse IP que le PDP contexte primaire auquel il est associé, mais pas la même QoS.
Dans l'exemple présenté à la figure, l'UE (User Equipment) a établi trois contextes PDP
primaires X1, Y, Z. Chacun est associé à une APN donnée, APN X, APN Y, APN Z et à une
adresse IP donnée, respectivement IP X, IP Y, IP Z. Par ailleurs une QoS doit être associée à
chaque contexte PDP. Quatre classes de QoS sont définies : conversationnel (pour des
services temps réel bidirectionnel tels que une communication audio ou visio), streaming
(pour des services temps réel unidirectionnels tels que le video streaming ou le broadcast
TV), interactive (pour des services de données interactifs tels que la messagerie instantanée
ou le WEB), et background (pour des services de données best effort).
L'exemple montre un contexte PDP secondaire X2 associé à un contexte PDP primaire X1.
Ce contexte PDP secondaire partage la même APN, la même adresse IP que le contexte
PDP primaire X1, mais pas la même QoS.
16
Activation d’un Contexte PdP
DNS
RNC
UE
SGSN GGSN
1. SM Activate PDP Context Request
2. Create PDP Context Request
(PDP Type = IPv4,
(MSISDN,
PDP address = 0.0.0.0,
PDP Type = IPv4,
QoS requested,
PDP address = 0.0.0.0,
APN = internet.orange.fr)
QoS requested,
APN = internet.orange.fr)
3. Create PDP Context Response
4.1. RANAP RAB
(PDP Type = IPv4,
Assignment Request
PDP address = 192.23.24.25,
4.2. RANAP RAB QoS negotiated,
Assignment Response APN = internet.orange.fr)
5. SM Activate PDP Context Accept
(PDP Type = IPv4,
PDP address = 192.23.24.25,
QoS negotiated,
APN = internet.orange.fr) 17
Pour échanger (envoyer et recevoir) des paquets IP via le réseau GPRS, l'UE doit
activer un contexte PDP (Figure). L’activation de contexte PDP constitue donc la
deuxième étape après la procédure d’attachement de l'UE au réseau GPRS.
La procédure d’activation de contexte PDP (PDP Context Activation) déclenchée par
l'UE, lui permet d’être connue de l’entité GGSN concernée.
1. Au cours de cette procédure, l'UE communique au 3G-SGSN via la commande SM
Activate PDP Contexte Request, le point d’accès au réseau externe auquel elle
souhaite se connecter (i.e. APN), le type d'adresse IP quel souhaite obtenir appelé PDP
Type (IPv4 ou IPv6) et la QoS requise.
2. Le SGSN traduit à l'aide du DNS l'APN en l'adresse IP d'un GGSN qui supporte
l'APN, puis émet une demande d'établissement d'un tunnel réseau à ce GGSN, appelé
Create PDP Contexte Request. Les paramètres fournis par l'UE sont inclus ainsi que
son MSISDN.
3. Une négociation de qualité de service est engagée. Le GGSN alloue une adresse IP
du type demandé (IPv4 ou IPv6) et la retourne dans la réponse Create PDP Context
Response aunsi que la QoS négociée.
4. Le SGSN doit maintenant demander au RNC d'établir un RAB entre l'UE et le SGSN.
Le RAB est constitué d'un tunnel radio entre l'UE et le RNC et d'un tunnel d'accès entre
le RNC et le 3G-SGSN. Un contexte PDP est donc l'agrégation des tunnel radio, accès
et réseau.
5. Une fois le RAB établi par le RNC, le 3G-SGSN peut retourner à l'UE la confirmation
d'établissement du contexte PDP via le message SM Activiate PDP Context Accept.
L'UE peut donc commencer à émettre et recevoir des paquets IP.
17
GTP
SGSN GGSN
GTP Tunnel
IP TCP/UDP GTP IP TCP/UDP
Contient l’identifiant du tunnel (TEID)

permettant de connaitre le UE et la session
associée. Permet aussi de distinguer GTP-
C de GTP-U
18
GPRS Tunneling Protocol (GTP) est un groupe de protocoles basés sur IP qui est
utilisé pour le transport des paquets GPRS dans les réseaux 3GPP.
GTP se décompose en 2 protocoles distincts: GTP-C et GTP-U.
GTP-C est utilisé dans le cœur de réseau GPRS pour la signalisation entre les nœuds
"Gateway GPRS Support Node" (GGSN) et le "Serving GPRS Support Node" (SGSN).
Cela permet au SGSN d'activer une session au nom d'un utilisateur (activation de
contexte PdP), pour désactiver la même session, pour régler les paramètres de QoS,
ou de mettre à jour une session pour un abonné qui vient d'arriver d'un autre SGSN.
GTP-U est utilisé pour transporter des données d'utilisateur dans le cœur de réseau
GPRS et entre le RAN 3G et le cœur de réseau. Les données de l'utilisateur peuvent
être transportées dans des paquets de type IPv4 ou IPv6. Ce transport ce fait par une
logique de tunnelisation opérée entre les deux nœuds GSN (S et G) concernés.
GTP peut être utilisé avec UDP ou TCP.
18
Evolution NGN-R4
BSS SCP
BTS
HLR
MS BSC
Domaine Circuit
BTS VLR
SS7/
MSC SIGTRAN
PCU
BTS Server
Frame
Relay
RNC IP
ATM RTC
Network
Node B
Domaine Paquet
UE
IP/GE
IP/GE
GGSN
Node B SGSN
Internet
UE UTRAN Intranet
RNC 19
L’évolution dite NGN (Next Generation Network) est avant tout une révolution de transport
dans laquelle on voit arriver IP. IETF a su faire évoluer l’environnement natif d’IP pour le
doter d’armes efficaces pour assurer la délivrance de n’importe quel type de flux en
respectant les prérogatives de QoS de chacun.
Ces armes s’appellent RTP/RTCP ou SCTP du coté des protocoles mais elles se
nomment aussi DiffServ et MPLS pour ce qui est du changement de comportement d’un
routeur IP vis-à-vis des flux qu’il a à traiter.
IP rentre d’abord du coté du domaine circuit en rationalisant coté cœur l’ensemble des
besoins d’échanges en une seule et unique logique. La question se pose ensuite de se
séparer coté UTRAN de la dimension ATM pour faire également confiance à cet IP
devenu soudain plus regardant sur les flux qu’il perme de transporter.
19
DiffServ
Les
Les routeurs
routeurs placés
placés dans dans lele
réseau
réseau s’occupent
s’occupent du du routage
routage
selon
selon l’adresse
l’adresse etet lala classe
classe de
de
service.
service.
Les
Les routeurs
routeurs enen bordure
bordure sont
sont dits
dits ROUTEURS
ROUTEURS
EDGE. Ils
EDGE. Ils s’occupent,
s’occupent, en
en plus
plus du
du routage,
routage, du
du
marquage
marquageen enclasse
classede
deservices
servicesdes
desflux
fluxentrants.
entrants. 20
DiffServ ou Differentiated Services est une architecture qui spécifie un

mécanisme pour classer et contrôler le trafic tout en fournissant de la QoS, en
différenciant les services. Leur gestion des priorités du trafic appelée Per hop
Behaviour (PHB), s'effectue alors selon les différents type de flux (voix, streaming,
data). Le PHB est déterminé par la valeur des six bits du champ (DSCP) de l'en-
tête IP. Les opérations de classification, contrôle et marquage sont effectuées par
les routeurs périphériques (Edge Router) tandis que les routeurs centraux (Core
Router) traitent les paquets en fonction du champs DSCP
Trois principaux PHB sont permis:
• Expedited Forwarding (EF) (RFC 2598); il a pour but de garantir une
bande passante avec des taux de perte, de délai et de gigue faible;
• Assured Forwarding (AF) (RFC 2597) regroupant plusieurs PHB
garantissant un acheminement de paquets IP avec une haute probabilité.
Cette famille est scindée en 4 classes garantissant de fournir une bande
passante et un délai minimum, chaque classe comprenant 3 niveaux de
priorité (Drop Precedence).
• BE (Best Effort)
Les PHB sont mis en oeuvre par les constructeurs dans les routeurs en utilisant
des mécanismes de gestion de files d'attente (Custom Queuing, Weighted Fair
Queuing,...) et de régulation de flux.
20
MPLS
@ Dest Label OUT Interface OUT
192.168.1.0 5 1
IP
IF 0
Interface Label Interface Label

L5 IP IN IN OUT OUT
0 8 1 9
IF 0
IF1 IF 0
IF1
L8 IP
Interface Label Interface Label

IN IN OUT OUT IF 0
L9 IP
0 5 1 8
IP
21
MultiProtocol Label Switching (MPLS) est un mécanisme de transport de données basé

sur la commutation d'étiquettes ou "labels", qui sont insérés à l'entrée du réseau MPLS et
retirés à sa sortie. À l'origine, cette insertion s'opère entre la couche liaison de donnée (L2) et
la couche réseau (L3) afin de transporter des protocoles comme IP. MPLS peut être utilisé
pour transporter pratiquement tout type de trafic (voix, streaming, data). À l'origine, la
technologie n'était prévue pour fonctionner que sur ATM ce qui limita sa place sur le marché.
Mais rapidement des extensions non ATM furent proposées. MPLS fonctionne par
commutation d'étiquettes (Label Switching). Des chemins entre ER (Edge Router) sont établis
de façon manuelle (action d'un administrateur dans le plan d'administration) ou automatique
(via un protocole de signalisation comme LDP — Label Distribution Protocol).
Le routeur d'entrée a pour rôle d'encapsuler le trafic reçu sur ses interfaces. Il applique (au
moins) une étiquette au paquet reçu et l'envoie vers une de ses interfaces sortantes. Pour
créer l'étiquette, le routeur utilise les FEC (Forwarding Equivalence Class), qui sont des tables
de correspondances dont les clefs sont un élément du paquet (adresse MAC, adresse IP,
Class of Service, port TCP/UDP, etc.). Une FEC est donc un groupe de paquets transférés
vers la même interface de sortie et avec les mêmes critères de transmission. Le paquet
atteint ensuite des commutateurs de transit. Ceux-ci possèdent une table de commutation.
L'opération de commutation est donc extrêmement simple, puisqu'il suffit d'analyser l'étiquette
MPLS qui se trouve directement après l'en-tête de la trame de niveau 2. Il n'est donc pas
nécessaire d'extraire le paquet IP et de parcourir l'ensemble de la table de routage.
21
SCTP
22
SCTP, ou Stream Control Transmission Protocol (RFC 4960) est un protocole de

transport au même titre que TCP ou UDP. Il fournit des services similaires à TCP,
assurant la fiabilité, la remise en ordre des séquences, et le contrôle de congestion.
Mais contrairement à TCP qui est orienté octets, SCTP gère des trames. SCTP offre
une gestion multi-flux pour laquelle une des extrémités (voire les deux) de la
connexion est constituée de plusieurs adresses IP.
À l'origine, SCTP a été imaginé pour optimiser le transport des flux de signalisation
utilisés dans les réseaux téléphoniques (ISUP, BICC, INAP, CAP, …) dans un
réseau IP. Mais il peut aller au-delà et se présenter comme une alternative à TCP.
22
Vers une Architecture tout IP
BSS SCP
BTS
HLR
MS BSC
Domaine Circuit
BTS VLR
SS7/
MSC SIGTRAN
PCU
BTS Server
Gbit RNC IP
RTC
Eth Network
Node B OFCS
Domaine Paquet
UE PCRF OCS
IP/GE Gx Gz Gy
IP/GE PCEF GGSN
Node B SGSN
Internet
UE UTRAN Intranet
RNC 23
Dans les évolutions vers le très haut débit, Ethernet devient la technologie de transport pour
tous les flux : téléphonie et data. En effet, les liens ATM entre Node B et RNC sont remplacé
par des liens GE (Gigabit Ethernet); De même si des les liens ATM sont encore présents
entre RNC et MGW, ils sont remplacés par des liens GE. Enfin les liens Frame Relay
permettant de relier les PCU (BSC) au SGSN sont aussi migrés vers GE.
Avec certains fournisseurs, il est même possible d ’intégrer la fonction RNC dans le Node B.
Les Node/RNC sont alors directement reliés aux cœur de réseau circuit et paquet pas des
liens GE.
A noter également l’émergence de la dimension PCC (Policy & Charging Control). Plusieurs
entités sont présentes:
• L’entité PCRF (Policy and Charging Rules Function) permet à la fonction PCEF
(Policy and Charging Enforcement Function) incluse dans le GGSN d ’apprendre les
règles PCC (Policy and Charging Control) afin d ’identifier les flux circulant sur le
contexte PDP, de bloquer ou d ’autoriser les flux, d ’affecter une QoS par flux, et de
taxer chaque flux individuellement. Le PCRF dispose d ’une interface avec la base de
données qui dispose des informations concernant le policy and charging relatif à
chaque client.
• L'entité PCEF dispose d'une interface de taxation avec l'OCS (l'Online Charging
System) pour la taxation online des flux de services IP consommés par l'usager et une
interface avec l'OFCS (Offline Charging System) pour la taxation offline des flux de
services IP de l'usager.
•Le PCEF obtient des crédits de l'OCS et soumet des tickets de taxation à l'OFCS. Il
est à noter que l'entité PCEF peut être indépendante du GGSN et dans ce cas se
retrouve derrière le GGSN à l'interface des réseaux externes IP.
23
Etat des Réseaux Mobiles GSM/3G
Fin 2013, GSA (Global Mobile Suppliers Association)
5.976 Milliards de souscriptions GSM-WCDMA-HSPA dans le

monde représentant 90% du marché mondial des mobiles
690 opérateurs GSM dans 213 pays
1.3 millions de nouvelles souscriptions GSM ou 3G chaque jour
532 réseaux 3G/WCDMA/HSPA lancés dans 203 pays
254 Réseaux HSPA+ offrent un service commercial dans 112
pays.
3847 terminaux HSPA proposés par 285 fournisseurs.
http://www.gsacom.com
24
24
499 opérateurs dans 138 pays
investissent dans la LTE
En 2009, 2 opérateurs mettent en place leur réseau LTE
En 2010, 15 opérateurs se rajoutent (Total cumulé : 17)
Au 18 Décembre 2013, 251 opérateurs ont mis en place
leur réseau LTE dans 93 pays.
Les MVNOs sont exclus de ces nombres.
157,7 millions de souscriptions au Q3 2013.
51,4% des souscriptions sont en Amérique du Nord, 43,4%
en Asie et 3,7% en Europe. 1,5% restant concerne le reste
du monde.
Evolution to LTE report (GSA) – 18 Décembre 2013 - http://www.gsacom.com

25
25
La 4G, dans quel but?
L’accès large bande mobile permettant des usages nouveaux

tels que
La vidéo, la TV mobile
Le cloud computing
Les jeux multimédia en réseau (latence faible)
Accès global et sécurisé aux applications de l ’entreprise
Communications téléphoniques enrichies (présence, messaging, etc)
L’accès large bande fixe : De nombreux opérateurs ont acheté
des licences LTE pour offrir deux « plays » dans un contexte
fixe avec une box.
1er play : l ’accès large bande à Internet
2ème play : la téléphonie sur IP
Le M2M
3GPP a définit un standard pour une version bas cout du chipset LTE
permettant ainsi l ’usage de la technologie LTE dans le contexte M2M.
26
26
2. EPS: Vue Globale
27
27
Architecture EPS (LTE + ePC)
ePC : Evolved Packet Core
GW : Gateway
MME : Mobility Management Entity EIR HSS
PCRF : Policy and Charging Rules Function
PDN : Packet Data Network
HSS : Home Subscriber Server
EIR : Equipment Identity Register
S6
PCEF : Policy and Charging Enforcement Function
OCS : Online Charging System SPR PCRF
OFCS : Offline Charging System S13
SPR : Subscription Profile Repository Gx
OCS OFCS
Gy Gz
S1-C MME
UE eNode B
S11
S1-U S5 PCEF
IP/GE IP/GE Réseau IP
Serving GW PDN GW
LTE
ePC
Plan de contrôle
Interface DIAMETER Plan usager28
Le réseau EPS (LTE + ePC) consiste en les entités suivantes : eNodeB (eNB) / Mobility Management Entity
(MME) / Serving Gateway (SGW) / Packet Data Network Gateway (PDN GW) / Home Subscriber Server
(HSS) / Policy and Charging Rules Function (PCRF)
L’eNodeB est responsable de la transmission et de la réception radio avec l’UE. A la différence de l’UTRAN
3G où sont présentes les entités Node B et RNC, l’architecture E-UTRAN ne présente que des eNodeB. Les
fonctions supportées par le RNC ont été réparties entre l’eNodeB et les entités du réseau cœur
MME/Serving GW. L’eNodeB dispose d’une interface S1 avec le réseau cœur. L’interface S1 consiste en S1-
C (S1-Contrôle) entre l’eNodeB et le MME et S1-U (S1-Usager) entre l’eNodeB et le Serving GW.
Le MME (Mobility Management Entity) est le nœud responsable du contrôle dans le réseau EPC (Evolved
Packet Core). Il est responsable de l’enregistrement des mobiles, de leur authentification, de leur joignabilité
lorsqu’ils sont dans l ’état de repos (incluant paging), de la sélection du Serving GW et du PDN GW. C’est au
MME de sélectionner le Serving GW et le PDN GW qui serviront à mettre en œuvre le Default Bearer (le
canal de communication permanent) au moment du rattachement du mobile au réseau.
Le SGW (Serving GW, passerelle de service) route les paquets sortants de l ’usager au PDN GW et
achemine les paquets entrants à l ’usager via le réseau d ’accès. Il réalise par ailleurs les fonctions
d ’interception légale et de comptabilité par usager pour la taxation inter-opérateurs.
Le PGW (PDN GW, passerelle PDN) fournit la connectivité vers les réseaux externes tels que Internet et
Intranets. Il réalise les procédures d ’allocation de l’adresse IP au mobile, d’interception légale et de taxation
des flux de service montants et descendants.
Le HSS (Home Subscriber Server) est la base de données contenant les données de souscription de
l ’usager EPS. L ’interface au HSS est S6 basée sur le protocole DIAMETER.
L ’EIR (Equipment Identity Register) est la base de données comportant les informations de sécurité relatives
à un mobile. C'est à partir de cet équipement qu'un opérateur peut bloquer un mobile volé.
Le PCRF (Policy and Charging Rules Function) fournit les règles de taxation au PDN GW afin que ce
dernier puisse réaliser la taxation des flux de service montants et descendants.
L'entité PCEF dispose d'une interface de taxation avec l'OCS (l'Online Charging System) pour la taxation
online des flux de services IP consommés par l'usager et une interface avec l'OFCS (Offline Charging
System) pour la taxation offline des flux de services IP de l'usager.
Le PCEF obtient des crédits de l'OCS et soumet des tickets de taxation à l'OFCS.
28
EPS et IMS
EIR HSS Cx, Sh

IMS
Rx
S13 S6
SPR PCRF Ro Rf
Gx
OCS OFCS
Gy Gz
S1-C
MME
UE eNode B
S11
S1-U
S5 PCEF
Serving GW PDN GW
LTE ePC
Plan de contrôle
Interface DIAMETER Plan usager
29
L’IMS s’impose en complément du réseau EPS pour fournir au client des services de
communication multimédia dans un environnement IP.
L’IMS n ’est pas un système mais juste un sous système. En effet, pour qu'un client
accède à ses services IMS il doit passer par un accès. Il est donc nécessaire de
disposer de réseaux d ’accès s ’interfaçant au réseau IP qui supporte l ’architecture
de réseau et de services IMS. Parmi les accès possibles figurent bien sur les
solutions 3GPP mais aussi les accès xDSL, l ’accès câble, FTTx, WiMAX, etc.
L ’IMS est une architecture fonctionnelle de référence. Elle est normalisée au niveau
mondial. Comme toute architecture fonctionnelle, elle consiste en un ensemble
d ’entités reliées entre elles par des interfaces. Les interfaces sont supportées par
des protocoles. L ’IMS étant une architecture tout IP, tous les protocoles sont issus
du monde IP. Deux protocoles de signalisation sont utilisés par l ’IMS : SIP (Session
Initiation Protocol) pour le contrôle des sessions et des services et DIAMETER pour
les procédures AAA (Authentification, Authorisation, Accounting). Deux protocoles de
transport de l ’information usager sont utilisés par l ’IMS : RTP (Realtime Transport
Protocol) pour le trafic temps réel tel que le trafic voix, vidéo, IPTV, streaming, etc.,
et le protocole MSRP (Message Session Relay Protocol) pour le transport des
données de l ’usager, tel que les données dans le contexte d ’un tchat (messages
instantanés, fichiers, photos, etc.).
29
3. LTE vu du coté Radio:
Interface Air & e-UTRAN
30
30
3.1 Interface Air
31
31
LTE: Une certaine flexibilité radio
6 configurations LTE:
1.4 MHz 3.0 MHz 5.0 MHz 10.0 MHz
15.0 MHz 20.0 MHz
2 modes Duplex :
FDD
TDD
32
L’interface radio E-UTRAN doit pouvoir supporter un débit maximum descendant

instantané (du réseau au terminal) de 100 Mbit/s en considérant une allocation de
bande de fréquence de 20 MHz pour le sens descendant et un débit maximum
montant instantané (du terminal au réseau) de 50 Mbit/s en considérant aussi une
allocation de bande de fréquence de 20 MHz que peut exploiter le terminal.
Cela correspond à une efficacité du spectre de 5 bit/s/Hz pour le sens descendant et
2,5 bit/s/Hz pour le sens montant.
En considérant HSPA à 14,4 Mbit/s dans le sens descendant et 5,75 Mbit/s dans le
sens montant avec une allocation d ’une bande de 5 MHz (ce que peut exploiter le
terminal), l ’efficacité spectrale est de 2,9 bit/s/Hz dans le sens descendant et 1,1
bit/s/Hz dans le sens montant.
Avec la 3G il est nécessaire d’allouer un canal de largeur 5 MHz. Avec la LTE, il est
possible d ’opérer avec des largeurs de canaux de tailles différentes avec les
possibilités suivantes : 1.4, 3.0, 5, 10, 15 et 20 MHz, pour les sens descendant et
montant. L’intention est de permettre un déploiement flexible en fonction des besoins
des opérateurs et des services qu’ils souhaitent proposer.
Bien sur lorsque le LTE est opéré sur des canaux de largeur inferieure à 20 MHz les
débits associés sont proportionnellement réduits.
Tout comme son prédécesseur UMTS, LTE peut être opérer en mode FDD ou en
mode TDD
32
LTE: Aspects Spectre
LTE
Alternative aux systèmes 3GPP existants
33
La technologie 4G peut fonctionner avec de nombreuses bandes de fréquences

hertziennes s’étalant de 400 MHz à 3,8 GHz. Bien entendu l’ensemble des bandes ne
sont pas disponibles pour cet usage, et malgré les harmonisations internationales il
persiste d’importantes disparités dans les bandes de fréquences utilisées pour la 4G
suivant les pays.
LTE possède à priori deux points d’ancrage principaux:

• la bande de fréquence associée au dividende numérique (700/800 MHz)
• la bande de fréquence 2.5/2.6 GHz
Entre ces deux extrémités, LTE s’annonce clairement comme un standard pouvant
remplacer les standards 3GPP existants et présents sur les bandes 900 (GSM),
1800/1900 (DCS/PCS) et 2100 (UMTS). En France, Bouygues Telecom à été autorisé
en 2013 par l’ARCEP à jouer une musique LTE dans sa bande 1800 MHz.
33
LTE = OFDM
4-QAM,
4-QAM,16-QAM,
16-QAM,64-QAM
64-QAM
Subcarrier-2
Subcarrier-N
Subcarrier-1
Subcarrier-3
Subcarrier-4
∆f
Frequency
OFDM Slot/Frame
IFFT
S1 S2 S3 S4 S5 S6 S7 SN
IFFT OFDM Symbol (FTT
SN+1 SN+2SN+3SN+4 S2N duration)
IFFT
Guard Time = 1/∆f (Loi de Nyquist)
Time Bandwidth
34
Du coté radio, LTE est avant tout le choix de l’OFDM (Orthogonal Frequency
Division Multiplexing).
Cette technique connue depuis la fin des années 60, s’est imposée dans les
systèmes WiFi, DVB, ADSL sans oublier bien évidemment WiMAX. On va la
retrouver désormais dans l’E-UTRAN.
L’OFDM consiste simplement en une mise en parallèle de plusieurs sous porteuses

mutuellement orthogonales (d’où le O de OFDM) opérée via l’usage de transformée
de Fourier numérique rapide (FFT: Fast Fourier Transform). Les sous porteuses
sont distantes l’une de l’autre de ∆f.
En fonction de la bande à occuper plus ou moins de porteuses peuvent être

réquisitionnées pour la transmission. L’alphabet de modulation est classique. Les
modulations numériques de type BPSK (1b/symb), QPSK (2b/symb), QAM-16
(4b/symb) et QAM-64 (6b/symb) sont communément associées a cette dimension
OFDM.
D’un point de vue mathématique la forme d’onde qui est opérée sur chacune des
sous porteuses fi est de la forme:
Acos(2πfit+φ) = Acos(φ)cos(2πfit) - Asin(φ)sin(2πfit)
le couple (Acos(φ), Asin(φ)) dépend de l’alphabet de modulation choisi
34
Schéma de Transmission OFDM
iFFT/FFT: si N = 2X
1 seule chaine RF 35
Plutôt que d’associer une chaine RF* à chacune des sous porteuses on peut chercher à
traiter cela tout d’abord de manière numérique avant d’attaquer une seule chaine RF de
transmission/réception. A l’émission, ce que l’on souhaite faire c’est additionner ensemble
pendant la durée d’un temps symbole Ts (=1/∆f) N sous porteuses synchrones les unes
des autres et portant des symboles différents. En modélisant mathématiquement cela on
arrive progressivement à une représentation très particulière de la forme d’onde
temporelle que l’on cherche a projeter sur la voie des airs:
N −1 2πj
kn
sn = ∑k =0
cke M
(N nombre de sous porteuses – M nombre de points pris pendant la durée du temps

symbole pour représenter la forme d’onde temporelle s(t) à construire)
Cette expression mathématique est fort connue des traiteurs de signaux. C’est par
définition la Transformée de Fourier inverse du signal numérique ck.
Pour rendre en pratique plus réalisable cette implantation il est préférable de choisir M =
N = 2n . On bénéficie alors des mécanismes de transformée de Fourier rapide et on peut
dès lors parler de FFT (Fast Fourier Transform).Il est à noté que M et N peuvent etre
différents.
*: Chaine RF = Tx {Conversion N/A Ampli Filtre} + Rx {Filtre Conversion A/N}
35
Intérêts de l’OFDM
36
On peut légitimement se demander quel peut être l’intérêt de troquer une transmission
de symboles qui pourrait s’opérer classiquement en présentant les symboles
séquentiellement en temps contre une autre ou les symboles sont présentés
parallèlement les uns aux autres.
En tout cas le débit produit n’augmente ni ne diminue pas.
Avec un schéma de transmission conventionnel N symboles sont émis en une durée

T0 = N*T = N/W. Avec la logique OFDM ces N symboles sont produits en une durée
T1 = 1/∆f=N/W.
Soit donc le même nombre de symboles en le même nombre de temps.
36
L’ISI sous contrôle
Symboles courts Hauts Débits ISI si Multitrajet
Pour éliminer complètement l’ISI

le symbole sera artificiellement
allongé d’une durée homogène à
l’étalement du multitrajet à
combattre. On parle de Cyclic
Prefix pour évoquer cette astuce
de traitement
37
L’ISI (Inter Symbol Interference) dépend de la durée du symbole et de la structure

du multi trajet et notamment son étalement temporel.
L’étalement temporel du multi trajet dépend de l’environnent de propagation. Il est
de l’ordre de 1µs en rural, 5µs en urbain et peut s’étendre à 15µs ou plus pour des
environnements de type montagne/colline.
Pour des systèmes mono porteuses classiques la durée du symbole est directement
associée au débit de modulation (et donc à la largeur de canal). Plus le débit
souhaité est important, plus le canal est large, plus le symbole est court et
donc plus l’ISI est présent. Cet ISI doit être éliminé. Des techniques d’égalisation
temporelles existent et tentent de réaligner les échos afin de démoduler
correctement les symboles qui se présentent. Ces traitements sont complexes et
donc couteux en temps de calcul.
Pour des systèmes OFDM, la durée du symbole dépend de l’écart ∆f entre porteuse.
Par un paramétrage pertinent on peut à mettre l’ISI sous contrôle et ainsi profiter
d’un canal large propice aux hauts débits. Ainsi donc les symboles de même rang
s’entrechoquent principalement avec eux même (sauf au frontière de symboles).
Dans ce cas c’est une fluctuation d’amplitude qui sera constatée lors de la réception
du signal. Ce phénomène (également dénommé fading dans la littérature) peut être
traité plus simplement au niveau du récepteur.
En allongeant la durée du temps symbole par un choix judicieux de l’espacement
entre porteuses on peut mettre le phénomène d’interférence entre symboles sous
l’éteignoir.
L’égalisation nécessaire du canal est encore d’actualité mais plutôt que de
l’appréhender dans la dimension temporelle une égalisation plus simple dans le
domaine fréquentiel est possible.
37
Fading (1)
Fréquence d’apparition des évanouissements
FADING
Deux trous successifs sont espacés d’une distance d’environ λ/2
Puissance reçue (en dB) pour un mobile se mouvant uniformément à une vitesse v.
c c v v
On a λ = et donc d = comme f d = f 0 alors d =
f0 2 f0 c 2 fd
d 1 f = 2 fd
Et donc t= =
v 2 fd
Durée moyenne de l’évanouissement
On connaît la puissance moyenne σ2 de la trajectoire

de fading. (Cela peut correspondre au 0dB de la courbe
via normalisation)
On fixe un seuil R et on calcule là moyenne des temps

ou l’amplitude est inférieure à R.
eρ −1
2
R
τ = avec ρ =
ρ f d 2π σ
temps
Profondeur moyenne de l’évanouissement.

Fréquemment faibles (5 à 10 dB) et parfois important (jusqu’à 30dB)
38
Toute transmission radio quelle que soit la technique utilisée ou pas est affectée du
phénomène de fading. Souvent du aux obstacles l’environnement proche du
récepteur (cas du mobile) ou à la diffraction des signaux par des obstacles
rencontrés sur les chemins de propagation empruntés (cas station de base) des
symboles de même rang n’ont pas d’autres choix que de s’entrechoquer entre eux
créant ainsi des fluctuations d’amplitude (donc de puissance). Parfois c’est
bénéfique (addition constructive) parfois non (addition destructive).
Ce phénomène peut être observé via la dimension temporelle (cas du visuel) ou par
la dimension fréquentielle. Selon la technique de transmission choisie
(Conventionnelle/OFDM) et la largeur du canal W considéré ce fading peut être plus
ou moins perturbant.
38
Fading (2)
Band 400 Mhz 900 Mhz 1800 Mhz 2000 Mhz
Wavelenght (m) 0.75 0.33 0.17 0.15
Speed (km/h) 3 50 120 3 50 120 3 50 120 3 50 120
Doppler (Hz) 1.1 18.3 44 2.5 41.7 100 5 83.4 200 5.5 91.7 220
Fading Period 450 27 11 200 12 5 100 6 2.5 91 5.5 2.3
(ms)
Mean duration 36 2.2 0.91 16 0.96 0.4 8 0.48 0.2 7.2 0.44 0.18
(ms) for a 10dB
attenuation
Band 2500 Mhz 3500 Mhz 5000 Mhz

Wavelenght (m) 0.12 0.09 0.06
Speed (km/h) 3 50 120 3 50 120 3 50 120
Doppler (Hz) 6.9 115,7 278 9.6 160.4 385 13.8 231.5 556
Fading Period 72 4.3 1.8 52 3.1 1.3 36 2.2 0.9
(ms)
Mean duration 5.8 0.35 0.15 4.1 0.25 0.10 2.9 0.18 0.07
(ms) for a 10dB
attenuation
39
39
OFDM devient OFDMA (1)
L’OFDM nous offre une vision du canal radio très
singulière. En effet, la vue temps/fréquence OFDM nous
permet de voir les perturbations affectant le canal
comme un océan très chahuté:
Et l’on voit alors l’intérêt que pourrait avoir une gestion

conjointe temps et fréquence de ce type de structure.
C’est l’ouverture vers l’OFDMA
40
40
OFDM devient OFDMA (2)
IDEE de BASE: allouer les ressources en fonction des

zones temps fréquence les meilleures
41
La dimension multi trajet a laquelle s’ajoute la dimension de mobilité crée entre

le transmetteur et le récepteur un océan de perturbation constitué de creux et
de bosses (phénomène de fading) dont on peut prendre conscience grâce à la
dimension OFDM. En effet, la découpe temps-fréquence proposée par la
technique OFDM nous permet théoriquement d’avoir accès à cet océan (à Ts
et ∆f près).
L’idée de l’OFDMA est simple. Deux usagers, affectés de conditions de multi
trajets et de mobilité différents vont expérimenter des océans de perturbations
différents. Les creux et bosses de chacun ne sont pas identiques et
permettent d’envisager un placement temps – fréquences différents pour les
ces deux usagers lorsqu’il s’agira de les servir.
L’OFDMA nous propose juste de jouer a TETRIS !
Bien sur il faudra se donner les moyens de mesurer cette surface temps-
fréquence aussi bien pour les sens UL et DL et de rapporter a qui de droit ces
mesures. C’est toute la difficulté du design de ce system LTE.
41
Inconvénients de l’OFDM (1)
Deux problèmes avec OFDM:

Sensible aux décalages en fréquences
(ICI: Inter Carrier Interference)

attention au Doppler
42
42
PAPR (Peak to Average Power Ratio)
Signal vu par le PA
La forme d’onde temporelle résultant

de l’addition anarchique de N
contributions QAM fait apparaitre un
Mise en // de plusieurs signal pouvant présenter une forte
variabilité.
contributions QAM
43
43
Impactant le design du PA
44
Avec OFDM on additionne anarchiquement différents symboles portés par différentes

sous porteuses pour produire au même instant un signal composite. On ne maitrise
plus les variabilités temporelles de la forme d’onde ainsi créée.
Elle peut malheureusement exhiber de très (trop) fortes variations obligeant a
travailler avec un ampli de puissance extrêmement linéaire et d’aménager une marge
conséquente entre la zone de saturation du PA et la zone moyenne de travail afin
d’anticipé ces rares large variations.
C’est jouable au niveau d’une station de base mais inacceptable coté mobile. Il faut
faire quelque chose de spécifique du coté du UE pour réduire ce PAPR
44
Du FDMA à l’OFDMA
45
Pour faire simple:
1G: FDMA
2G: TDMA
3G: CDMA
4G: OFDMA
Une nouvelle technologie DMA pour la 5G ??
45
Les choix radio LTE (1)
Espacement Sous Porteuse: 15 kHz
Débit de Modulation: 15 kbauds
TSymb = 1/15000 = 66.66 µs
Canal LTE 1.4 MHz 3 MHz 5 MHz 10 MHz 15 MHz 20 MHz
Durée Trame 10ms
(1ms)
Δf 15 kHz
Fech (MHz)
1.92 3.84 7.68 15.36 23.04 30.72
Taille FFT 128 256 512 1024 1536 2048

Nombre
Sous 72 180 300 600 900 1200
Porteuses
46
Même si LTE est flexible (largeur canal, FDD/TDD) de nombreux choix sont fixés:
• Une trame LTE dure 10 ms (comme en UMTS)

• Une sous trame dure 1ms (10 sous trame par trame)
• L’espacement entre porteuse est toujours de 15kHz ce qui fige en fonction
de la bande la taille de la FFT. A noter le soucis de rester compatible des
horloges de l’UMTS (3.84 MHz)
46
La boite à outils radio LTE
est identique à celle
utilisée en HSPA
Redondance
C (bps) r = N in/N out
Protection: … si si+1 si+2 … W
Modulation
CRC + CC /TC
…1011…
…101010111101…
Claude Shannon (1948)
C =W lo g 2 (1 + SNR )
47
Le deuxième théorème de Shannon dit de codage canal montre qu'il est possible de
transmettre des données numériques sur un canal même bruité (qualifié par son rapport
signal à bruit: SNR) presque sans erreurs à un débit maximum calculable. Ce résultat publié
par Claude Shannon en 1948 est basé sur des travaux antérieurs de Harry Nyquist et Ralph
Hartley. La limite ou capacité de Shannon d'un canal est donc le débit théorique maximal
de transfert d'information sur ce canal pour un certain niveau de bruit.
En 1948, Shannon a posé les limites sans préciser comment il était possible de les atteindre.
Il a fallu près de 60 ans pour se rapprocher au plus près de ces limites. On a profité de
l’évolution des techniques RF afin de rendre possible l’usage de modulation de plus en plus
exotiques mais aussi de l’augmentation constante de la capacité de processing rendant
possible l’intégration d’algorithmes de protection de plus en plus sophistiqués.
47
PROTECTION = TURBO CODE
Révolution dans le domaine du Codage

Canal due à Alain Glavieux et Claude
Berrou (1993).
Technique qui approche les limites

théoriques de Shannon.
48
Cette technique s’appuie sur deux codes convolutifs faiblement protecteurs (longueur de
contrainte faible, faible rendement, sortie systématique) travaillant en parallèle l’un de
l’autre sur deux versions entrelacées du même bloc.
Le récepteur enchaine itérativement des décodages de type Viterbi SOVA améliorés afin
qu’a chaque itération le décodage précédent apporte un peu plus de certitude sur le flux
à décoder (principe de softbit) au décodage suivant. On stoppe ce processus itératifs
lorsque mutuellement les deux décodeurs cessent de s’enrichir.
Dans la boite à outil radio du LTE ce turbo coding prend une place importante. Il
accompagne la transmission des flux de trafic échangés entre le UE et les entités e-
UTRAN/ePC. Il est aidé d’une logique de CRC de 24 bits. Ce schéma de rendement r =
1/3 (par construction) est complémenté par des étages de poinçonnage/répétition afin
d’adapter finement le rendement de protection souhaité.
Certains échanges de contrôles se font via l’usage de Codes Convolutifs (CC) moins
efficaces et aidés de CRC 16bits et de mécanismes d’ajustement de rendement de
protection similaires.
48
K
QPS 16
M-
QA -64
M
QA
n
ptatio
Ada
Link
49
Coté modulation on reste dans l’état de l’art: QPSK, QAM-16 et QAM-64 (BPSK peut
être utilisé pour certains canaux de contrôle). QAM-128, QAM-256 ne sont pas
envisagés car leur usage correspond à des SNR trop élevés par rapport à ceux
rencontrés dans les déploiement macro et dans les gammes de fréquences
considérées.
Protection et Modulation doivent être dynamiquement choisis pour optimiser la
transmission. C’est grâce aux innombrables mesures L1 reportées par le UE que
l’eNodeB choisira le meilleur MCS (Modulation and Coding Scheme) DL? De manière
équivalente, c’est par l’observation du sens UL que cet eNodeB fera de même en UL
et choisira le MCS que les UE doivent utiliser.
49
Q
HAR
P1,1 P1,2 P2,1 P2,2 P3,1
K
K
ACK
ACK
ACK
NAC
NAC
Tx
P1,2 P2,2
+ +
P1,1 P1,1 P2,1 P2,1 P3,1
Rx
Rythmes HARQ:
ACK/NACK 4ms après chaque envoi
Retransmission au mieux 4ms après le NACK.
50
Il ne faut pas oublier non plus:

• La dimension HARQ (Hybrid ARQ) qui propose de jouer à
transmettre/retransmettre rapidement les blocks échangés afin de tirer profit
d’une forme de gain de diversité au niveau L1. Tout ce qui est non correctement
reçu est gardé afin d’être recombiné avec les futures retransmissions.
HARQ proposé initialement en EDGE et revisité pour

HSDPA/HSUPA.
En LTE, chaque block transmis (UL et/ou DL) se doit d’être acquitté
4ms après son envoi afin d’envisager une retransmission au plus tôt 8ms
après.
• Cette dimension HARQ agissant au niveau PHY est complémenté par un

mécanisme ARQ plus classique. C’est la couche RLC (similaire à celle utilisée
en UMTS) qui agit au niveau juste supérieur et offre des mécanismes de
reprises pour les flux le nécessitant (web/mails/flux data/…)
• Avec HARQ chaque blocs retransmis vient des recombiner avec les
précédents. On peut proposer deux type de recombinaisons:
• un première dite « Chase Combining » lorsque les blocs transmis sont
toujours identiques.
• une seconde dite « Incremental Redundancy » lorsque l’on joue au
niveau codage canal à poinconner les blocs transmis. Chaque
transmission peut proposer une version différente du poinçonnage
appliqué au du bloc protégé
50
Et surtout …
PDCCH
ling
ch edu PDSCH
S
OFDM DL
Traffic
Toutes les 1 ms (sub frame) on sélectionne Scheduler
une zone OFDM UL et/ou DL pour faire (1ms)
travailler les UE.
OFDM UL
PRACH
PUSCH Feedback:
Link Quality
ACK/NACK
PUCCH
51
Mais surtout c’est dans l’approche de l’allocation des ressources radio que LTE
impose une logique très particulière:
• La structure OFDM DL est basée sur le rythme sous trame (1ms) sur laquelle
les mobiles s’appuient pour y découvrir les ressources radio qu’un scheduler a
décidé de leur attribuer.
• la zone PDCCH est l’endroit ou les mobiles reçoivent leur messages
d’allocation UL et/ou DL.
• la zone PDSCH est l’endroit ou les mobiles pourront y trouver les
ressources DL qui leur sont assignées.
• La structure OFDM UL est structurée de la même façon en prenant soin d’y

distinguer la région PUCCH permettant aux mobiles de rapporter des mesures
L1 (ACK/NACK, CQI, MIMO) de la région PUSCH leur permettant de remonter
leurs flux de trafic. On trouvera également les ressources PRACH permettant
d’initier l’accès au réseau
• L’allocation DL est immédiate (dans la sous trame courante) alors que

l’allocation UL est différée (dans 4ms).
• La ressource radio allouée qu’elle soit UL ou DL est constituée de zone

temps-fréquence (N symboles en temps/M sous porteuses) sur laquelle on
impose au mobile la modulation et le schéma de protection (MCS: Modulation
Coding Scheme).
51
Et bien sur : MIMO !!!
MIMO signifie Multiple Input Multiple Output. En pratique cela

consiste à se doter de plusieurs antennes en transmission mais aussi en
réception. On parle d’un système MIMO (NxM) lorsque N antennes en
transmission sont placées en face de M antennes en réception.
52
52
SISO
MISO (Nx1) OL
(ALAMOUTI)
MISO (Nx1) CL
SIMO (1xN)
53
• SISO (Single Input Single Output) = MIMO (1x1): C’est le cas le plus simple ou l’on va opérer une transmission
en subissant les perturbations du canal (fading, multi trajet) en espérant que les mécanismes de protection choisis
pour la transmission permettrons de s’en sortir. Un rapport signal à bruit (SNR: signal to noise ratio) moyen pourra
être mesuré sur le chemin unique liant l’émetteur et le récepteur. Ce SNR moyen n’est que la moyenne des SNR
instantanés qui se présentent lors de la transmission. SISO est en général le cas de transmission opéré pour le
sens DL
• Avec SIMO (Single Input Multiple Output) = MIMO (1xM) une double amélioration est possible. La première est
liée au fait que plus d’une antenne (M) sont utilisées en réception. Appelé gain d’antenne et dépendant du nombre M
d’antennes utilisées le SNR initialement constaté dans le cas SISO s’améliore d’autant. La deuxième dépend des
deux chemins qui sont désormais à disposition du récepteur. Si ces deux chemins exhibent des variations de fading
différentes un gain complémentaire est possible: c’est le gain dit de diversité. Les évanouissements dus au fading
deviennent moins gênant car les moments ou la perte de signal est simultanée sur les M antennes de réception est
rare. Pour mettre en évidence ces gains (antenne et diversité) un traitement spécifique est nécessaire au récepteur.
La technique MRC (Maximum Ratio Combining) est utilisée. Elle propose une combinaison linéaire des M signaux
reçus chacun étant pondéré par un facteur proportionnel au rapport signal a bruit instantané de chaque lien. Il faut
noter ici que le gain d’antenne est toujours disponible alors que le gain de diversité dépend de la structure globale du
canal de propagation qui peut nous présenter M chemins très corrélés entre eux annihilant de fait le gain de diversité
attendu. En SIMO, le SNR SISO moyen s’améliore et permet soit d’augmenter la couverture soit de proposer un
schéma de protection moindre améliorant donc le débit utile à faire passer. SIMO est souvent utilisé en UL
• Avec MISO (Multiple Input Single Output) = MIMO (Nx1) ca se complique un peu. En effet si le but rechercher
est de retrouver les gains SIMO un feedback du récepteur distant est indispensable. C’est le mode dit closed loop,
pour lequel l’émetteur possède la connaissance du canal de transmission. Aussi le même flux peut être
optimalement réparti sur les antennes de transmission afin d’en retirer les même gains qu’en SIMO. Cette boucle
doit etre rapide et précise et parfois devant un fading très rapide elle ne peut être opérée efficacement. Les travaux
de Siavash ALAMOUTI ont permis en 1997 de présenter un autre schéma MISO ne nécessitant aucun canal de
retour depuis le récepteur vers le transmetteur. C’est le schéma MISO dit open loop. Le schéma initial MISO(2x1)
d’ALAMOUTI propose une judicieuse répartition spatio-temporelle du flux de symboles à envoyer sur les deux
chemins de transmission. Le gain que l’on peut en tirer est celui lié à la diversité (si le canal exhibe cette dimension)
par contre l’absence de boucle de retour empêche définitivement l’obtention du gain d’antenne. MISO CL et OL
options de l’UMTS
53
MIMO (NxM) MIMO (NxM)

CL ou OL Spatial Mux
54
A priori MIMO (Multiple Input Multiple Output) = MIMO (NxM) peut être vu
comme une mise en cascade des techniques SIMO (MRC) et MISO (CL ou OL)
vues précédemment. Le but étant alors de cumuler les gains SIMO & MISO. Mais
alors si tel est le cas rien ne permet de penser que l’on peut aller au-delà des
limites de Shannon.
Et pourtant on peut montrer que dans certaines situations (SNR élevé / Milieu
riche en diversité) le schéma de transmission MIMO (NTxNR) peut se transformer
en NL schémas SISO en parallèle les uns des autres avec NL = min(NT,NR). On
parle pour ce phénomène de MIMO SM (SM = Spatial Multiplexing). Les lois de
Shannon ne sont pas enfreintes.
54
En LTE on envisage des stations de base dotées d’une, de deux ou de

quatre antennes Tx/Rx.
Le UE possède une seule antenne Tx mais peut être doté d’une, de

deux ou de quatre antennes Rx.
Ces configurations figent les schémas de transmission possible:
DL: SISO: (1x1), SIMO: (1x2) (1x4), MISO CL & OL: (2x1) (4x1),
MIMO CL & OL: (2x2) (2x4) (4x2) (4x4), MIMO SM 2 flux: (2x2)
(2x4), MIMO SM 3 ou 4 flux: (4x4)
UL: pas de MIMO mais du SISO (1x1) ou du SIMO (1x2) et (1x4)
55
55
Un bref calcul de débit LTE
Quel débit UL/DL peut on attendre d’un LTE

20MHz opéré en mode FDD ?
• 20 MHz = 1200 porteuses
• QAM-64: 6bits/symboles
• ∆f = 15 kHz 15000 symboles/porteuse
-----------------------------------
= 1200*6*15000 = 108 Mbps
56
Le calcul simple de débit proposé ci-dessus nous amène croire que la limite maximale est de
108Mbps.
Ce débit maximal reste très théorique. Il part du principe que l’usager est seul dans la cellule et
bénéficie d’un canal radio exceptionnellement bon le dispensant de protection. Mais aussi que toutes
les porteuses peuvent lui être attribuer pour ses besoins de trafic.
Ceci est faux car il convient de considérer sur la surface OFDM commune des besoins spécifiques:
DL:
• zone PDCCH pour allouer les ressources en complément de la zone PDSCH pour
écluser le trafic.
• canaux de synchronisation (PSS/SSS).
• canaux SysInfo (PBCH & PDSCH).
• symboles pilotes pour démoduler et mesurer le canal DL OFDM temps-fréquence
(RS).
UL:
• zone RACH pour initier une connectivité avec une station de base.
• zone PUCCH pour permettre aux mobiles des feedbacks L1 (CQI & ACK/NACK)
indépendamment de leur besoin de trafic (zone PUSCH).
•symboles pilotes pour démoduler et mesurer le canal UL OFDM temps-fréquence
(DM-RS/SRS).
L’estimation de cet overhead est de l’ordre de 70 à 80% laissant au mobile au mieux 80 Mbps.
Pourtant le LTE annonce notamment en DL des débits de l’ordre de 300 Mbps. Il manque un facteur 4
que l’on va chercher avec MIMO SM !
56
Slot & Trame LTE
2 CP possibles
(~5µs/~16.7µs)
Trame LTE FDD / TDD:
7 OFDM Symboles/Slot (CP court)
6 OFDM Symboles/Slot (CP long)
Logique TDD
57
57
RE & RB
Une structure fondamentale est proposée

en LTE: le Resource Block (RB)
58
Un bloc ressource DL/UL est constitué de 12 sous porteuses et de 6 ou 7 symboles

OFDM transportés dans le slot qui le délimite temporellement.
Suivant la bande considérée on dispose de plus ou moins de RB (ressource block)
(100 en 20MHz, 75 pour 15MHz, …) par slot.
L’élément constitué de 2 RB consécutifs en temps d’une même sous trame sera
l’élément minimal sur lequel on s’appuiera pour allouer des ressources DL et/ou UL
aux usagers.
58
En clair
FDD
TDD
59
59
LTE: Organisation DL (1)
60
Il faut organiser la surface OFDM DL et proposer un certain nombre de canaux

physiques:
• Canaux SCH pour permettre aux UE de se synchroniser en temps et en

fréquence
• Canaux PBCH pour obtenir certaines informations système relative à
l’organisation physique de la surface OFDM
• Canaux PDCCH permettant aux UE de recevoir leurs messages d’allocation
DL et/ou UL. Ces messages d’allocations sont appelé DCI Format.
• Canaux PDSCH pour envoyer du trafic aux UE
• Canaux PCFICH précisant la surface PDCCH utilisée
• Canaux PHICH permettant de faire vivre la logique HARQ DL
Pour que ces canaux DL soit opérés optimalement un retour des UE est
nécessaire. Les canaux PUCCH UL aideront alors.
60
61
Les canaux PHICH et PCFICH sont intégrés sur la surface PDCCH.

La zone PDCCH sert à distribuer des messages d’allocations aux UE pour leur
besoin de trafic DL et UL mais aussi en DL pour s’adresser collectivement aux UE
pour délivrer les SySInfo et les messages de paging
Les signaux RS servent à opérer la démodulation des blocs de datas adressés aux
UE. Ces signaux servent également comme base sur laquelle les mesures de
performances L1 DL sont effectuées afin de reporter via PUCCH UL au eNodeB le
MCS à utiliser (CQI: Channel Quality Information), la configuration MIMO qui se
présente mais aussi les mesures de voisinage permettant d’envisager à terme un
handover.
61
PDCCH (jusqu’à 3 symboles)

+(PCFICH/PHICH)
62
62
LTE: Organisation UL (1)
Pour l’UL cela va rester similaire au DL à un bémol près ! On a un petit

souci en plus que l’on va chercher à contrer: le PAPR (Peak to Average
Power Ratio). P
2 out PA back-off
max x ( t )
{x( t )} =
{ }
t
PAPR 2
E x( t ) P
max
P Saturation
Tx
Marge de puissance pour passer

les pics d’amplitude du signal
dans la zone linéaire. Zone linéaire
P
in
Cette marge doit être la plus faible
possible pour avoir la puissance Tx
moyenne la plus élevée possible Les signaux à faibles variabilités
sont préférables !!!
63
63
C’est du SC-FDMA
A
DM
C -F
S
Sous Porteuses
contigües
64
Pour réduire le PAPR il faut cesser d’additionner ensemble des symboles différents
de manière anarchique. Il faut les envoyer séquentiellement dans la bande
considérée. On revient à une logique de transmission classique dite SC-FDMA
(Single Carrier FDMA)
On pourrait s’appuyer sur design très classique consistant à générer la forme d’onde
radio en en présentant les symboles les uns à la suite des autres à la chaine RF mais
que l’on va la générer à l’aide de principes OFDM légèrement modifiés : le DFT-
OFDM (Discrete Fourier Transform Spread OFDM).
Une DFT vient se présenter en amont de la structure OFDM. C’est une forme de
OFDM précodée. La DFT est la pour calculer la représentation fréquentielle associée
au train de symboles à envoyer.
Cette DFT pourrait devenir FFT si d’aventure le nombre de symboles qui lui serait
confiés était une puissance de 2.
On pourrait distribuer ou localiser ensuite les symboles fréquentiels ainsi gérés. Le
choix d’une structure localisée à été faite pour cet OFDM UL pour des soucis de
simplification mais aussi car la structure localisée permet de gagner un peu de dB
supplémentaire dans la réduction du PAPR.
A noter que la structure distribuée est également appelée iFDMA (Interleaved FDMA)
dans la littérature.
64
Si la complexité du PA est réduite il n’en est pas de même

pour le eNodeB
Une sous porteuse fadée

Tous les symboles sont impactés
l’égalisation revient 65
Mais réduire la complexité du UE c’est augmenter celle de la BTS.

En effet, par cet artifice SC-FDMA chaque porteuse ne porte plus un symbole mais
tous les symboles souhaités. Le multi trajet (qui crée des trous sur l’axe fréquentiel)
va malheureusement réintroduire une forme d’interférence entre symbole qui va
nécessiter à l’usage d’une égalisation un peu plus musclée.
Cette égalisation pourrait se faire dans le domaine temporel mais la structure
OFDM se prête à une égalisation à effectuer cette fois dans le domaine fréquentiel:
réaligner en temps revient fréquentiellement à réajuster le spectre en procédant à
une égalisation des différentes composantes fréquentielles.
65
66
Pour l’UL trois types de canaux vont co-exister sur la surface OFDM UL::
• PUCCH (Physical Uplink Control Channel): canal permettant au mobile de

remonter des informations de contrôle (CQI, ACK/NACK en réponse à un
envoi DL, feedback MIMO)
• PUSCH (Physical Uplink Shared Channel): canal permettant d’envoyer du

trafic ou de la signalisation. Ce canal lorsqu’il est alloué permet également
de remonter en overlay les informations de contrôle dont le P-UCCH
s’occupe. P-UCCH et P-USCH ne peuvent pas être opérés simultanément
par le mobile.
• PRACH (Physical Random Access Channel): canal à accès aléatoire pour

initier les dialogues avec le réseau lorsque le mobile n’est pas synchronisé
avec ce dernier.
66
Configuration PUCCH
Typiques
20.0 MHz: 16 PUCCH

15.0 MHz: 12 PUCCH
10.0 MHz: 8 PUCCH
5.0 MHz: 4 PUCCH

3.0 MHz: 2 PUCCH
1.4 MHz: 1 PUCCH
67
67
PRACH permet aux UE d’accéder à la BTS
Répétition de PREAMBULE
pour les formats #2 & #3
GT ~
0
GT ~ .1 ms
0.52 R
ms ~15km
R ~7 GT ~
8km 0
GT ~ .2 ms
0.72 R
ms ~30km
R ~1
08km
68
Le canal PRACH est celui qui permet aux UE de se connecter à la station de base
afin dans la continuité de dialoguer avec le réseau cœur.
6 RB (72 porteuses) sont utilisés pour placer un PREAMBULE que la BTS cherche
à détecter.
64 séquences de PREAMBULE sont à priori disponibles par cellule
Une séquence plus courte que la sous trame permet à la station de base de
déterminer le délai associée à la propagation (aller-retour)
Les trois formats sont la pour permettre d’envisager plusieurs configurations
possibles en matière de taille de cellule.
68
PUSCH est la pour trafiquer
69
Le canal PUSCH permet d’écluser les flux de trafic et de signalisation. Un nombre fini
de RB contigus (SC-FDMA oblige) est attribué au mobile. Pour ces différents RB, une
séquence RS est utilisée et est positionné systématiquement sur le 4eme symbole
OFDM du bloc. On jouera sur ces RB le jeu AMC (Adaptive Modulation Coding)
décidé par la BTS afin d’optimiser le débit à transférer (QPSK, QAM16 ou QAM64
avec un Turbo Code de rendement adapté aidé d’un CRC de 24 bits).
Remarquez que la structure d’envoi proposée aux UE est semblable aux bursts GSM
(546,5 µs avec une training séquence de 96 µs au milieu). Le pseudo burst LTE fait
500 µs de long et possède une structure de training séquence de 71.5 µs en son
milieu.
69
PUCCH aide le scheduling DL/UL par le report de:
CQI (Channel Quality Indicator) indicateur du meilleur MCS à utiliser
Informations MIMO: Feedbacks MISO CL, MIMO CL & MIMO SM
ACK/NACK: 4ms après l’envoi d’un bloc PDSCH
SR (Scheduling Request): pour ré-entrer dans le jeu de scheduling UL
70
Le PUCCH utilise 2 RB (12 sous porteuses x 7 symboles OFDM) mappés sur les 2
slots de chaque sous trame avec un frequency hopping à effectuer entre les deux
slots. Les ressources PUCCH sont en nombre limités et sont positionnées aux deux
extrémités du spectre utilisé.
Différents formats de transmission sont proposés permettant d’opérer les envois
autonomes de CQI/MIMO et de ACK/NACK mais aussi des envois groupés
CQI/MIMO + ACK/NACK.
70
LTE: DL/UL
71
71
Complément Radio
A savoir également:
Power Control en mode open loop pour l’UL / Pas de Power Control
en DL
Le Scheduler radio essaie de trouver le bon équilibre entre

l’optimalité radio de chacun (SNR), la QoS des flux a traiter.
Cette fonctions est l’affaire des fournisseurs de solutions
(Ericsson, ALU, Huawei, NSN, …)
Principe de Timing Advance en UL (similaire à GSM)
72
72
3.2 e-UTRAN: Architecture & Protocoles
73
73
L’eNodeB (1)
Fonctions de la
station de base
Protocoles Radio
de la station de
base
74
Du coté du RAN (appelé désormais E-UTRAN) un seul équipement existe: le e-

NodeB. Le RNC/BSC disparait. Dans cet équipement « tout en un », on va retrouver
l’ensemble des fonctionnalités et des couches protocolaires qui par le passé étaient
logés dans le RNC/BSC et qui concernaient le monde radio.
Fonctionnalités:
• Admission et contrôle des flux soumis par le cœur de réseau
• Sélection et application du paramétrage radio garant de la QoS des flux
admis.
• Gestion de la mobilité radio: collecte et analyse des mesures de voisinages
rapportées par les UE, interaction avec les eNodeB voisins pour opérer le
handover
• Le scheduler DL/UL des ressources
• Coordination entre eNodeB pour optimiser le scheduling radio (ICIC)
74
L’eNodeB (2)
75
Protocoles:
• RRC (Radio Resource Control) gérant toute la messagerie relative à la
radio entre UE et eNodeB et permet les transferts de signalisation vers
ou depuis le cœur de réseau
• PDCP (Physical Data Convergence Protocol): adaptation et
compression de l’entête IP des flux à échanger. La logique sécuritaire
(chiffrement & intégrité) se joue ici.
• RLC (Radio Link Control) : couche de niveau liaison de donnée qui
accompagne les flux pour adapter leurs formats aux contraintes du
transporteur radio mais aussi pour appliquer une éventuelle fiabilisation.
On peut opérer RLC en mode acquitté (AM) ou non (UM). Un mode
transparent (TM) existe aussi
• MAC (Medium Access Control): mise en forme du container présenté à
la physique et contenant les flux à échanger
Le eNodeB reste néanmoins une machine radio et ce doit d’opérer la
dimension physique: modulation/démodulation, gestion de la chaine RF Rx/Tx.
75
MAC & RLC & PDCP
76
76
RRC (1)
77
La couche RRC est une couche de signalisation ou on parle principalement radio.

Elle s’occupe par essence du broadcasting des informations système, du paging, de
la gestion des connexions, du contrôle des radio bearers, des fonctions mobilité, du
contrôle et du reporting des mesures UE. C’est cette couche qui assure la cohérence
de la transmission des flux de trafic entre UE et le eNodeB et qui configure les
différentes couches PDCP / RLC / MAC.
Elle assure également un rôle dans la transition des messages de signalisation NAS
produits entre le UE et le MME.
77
RRC (2)
Avec RRC:
Un UE est en mode RRC CONNECTED lorsqu'il est connecté à un
eNodeB et qu’il participe au jeu de scheduling. Sa mobilité est

gérée par le eNodeB via la procédure de HANDOVER.
A l’opposé un UE non connecté est en mode RRC_IDLE. Il gère de

manière autonome sa mobilité par la procédure de CELL
SELECTION.
78
La couche RRC:
Les états RRC en LTE sont réduits par rapport à ceux de l’UTRAN. LTE définit 2 états RRC
pour un Mobile UE: RRC_IDLE (état Veille) et RRC_CONNECTED (état Connecté).
Dans l’état RRC IDLE, un UE n’a pas de contexte RRC au niveau du eNode B. Dans cet
état, l’UE a un ID qui l’identifie de manière unique dans une Tracking area. Le Paging, la
resélection de cellules, et la réception des informations de Broadcast sont des opérations
possibles entre un UE et l’eNode B dans l’état RRC_IDLE.
Dans l’état RRC_CONNECTED, un Mobile UE a un contexte RRC au niveau du eNode B.

C’est une connexion RRC. L’E-UTRAN sait dans quelle cellule le Mobile UE est présent, et
les handovers sont possibles. Transmissions et réceptions de données sont possibles entre
l’UE et l’ E-UTRAN.
Il conviendra de différentier dans cet état les cas ou le UE est CONNECTE et
SYNCHRONISE de celui ou il est CONNECTE mais DESYNCHRONISE. Cette
désynchronisation est décidée lorsque le Timing Advance délivré au UE est jugé trop
ancien (par rapport à un timer). Dans ce cas le UE devra préalablement à toute émission
envoyer un RACH.
Si l’envie d’envoyer est à l’initiative du UE pas de problème. Au lieu de fair un SR il envoie
sa requête avec un RACH. Par contre si la reprise est à l’initiative du réseau, le eNodeB
devra demander l’émission d’un RACH au UE. C’est pourquoi le DCI Format 1A permet de
réclamer explicitement l’envoi d’un RACH a tout UE.
78
RRC (3)
MME
Random Access Preamble (sur RACH)
Random Access Response

(UL Grant/TA/Temporary C-RNTI)
RRC Connection Request
(Non ambiguous UE Id/Establishment Cause)
RRC Connection Setup

(Non ambiguous UE Id)
RRC Connection Setup Complete
(C-RNTI/NAS message)
NAS message (EMM Attach Request)
79
4 étapes distinctes caractérise l’usage de ce canal:
Step 1: Choix aléatoire d’une séquence de Préambule. Deux sous ensembles de Préambule
sont possibles (subset #0 et subset #1). Selon le volume d’information que le UE souhaite
reporter le Préambule sera tiré dans l’un des deux sous ensembles. La zone RACH utilisée
permet de déduire l’identité spécifique (RA-RNTI) qui lui est associé à cette demande d’accès
et qui sera utilisée dans l’étape d’après pour effectuer la gymnastique de calcul des CCE
utilisés dans la zone P-DCCH et susceptibles d’accueillir la réponse au RACH. La puissance à
utiliser par le UE, pour envoyer ce préambule, est déterminée par des principes open loop.
Step 2: Réponse de la station de base au UE (RAR: Random Access Response). Une
allocation DL est produite vers le UE. La réponse du eNodeB est attendue dans une fenêtre
[Tmin,Tmax] indiquée dans les informations systèmes délivrées dans la cellule. Tmin vaut au
pire 2ms, Tmax au max 12ms. Cette réponse prépare la ressource UL qui lui est réservée,
6ms après, pour passer sa requête. Les RB sélectionnés, des informations de timing, de
power control et bien sur de MCS lui sont passés. On y ajoute également une identité
temporaire TC-RNTI.
Step 3: Le UE envoie sa requête (à priori RRC Connection Request pour un UE cherchant à
initier un dialogue avec le Cœur de Réseau). Il ajoute également une identité nouvelle UE-
CRId (UE Contention Resolution Identity) afin de résoudre une éventuelle contention
(plusieurs UE effectuant au même moment un accès RACH avec le même préambule). Cette
identité peut être aléatoire ou bien celle utilisée dans les dialogues antérieurs avec le Cœur de
réseau (S-TMSI).
Step 4: La réponse de la station permet de continuer le dialogue RRC mais surtout de
résoudre la contention. Le UE-CRid est passé et permet ainsi aux UE éventuellement en
contention de savoir qui est réellement concerné par le dialogue. Pour scheduler ce message
le TC-RNTI est utilisé. Cette identité jusqu’alors temporaire doit être considérée par le UE
vainqueur de la contention désormais comme son C-RNTI.
79
RRC (4)
Avec RRC on assure également:
La distribution périodiques des Informations Système (SysInfo)
organisées en SIB (System Information Block). Elles empruntent

les canaux PDSCH et sont adressées alors à tous les UE.
Message Content Period (ms)
MIB Essential parameters 40

(Subframe #0)
SIB 1 Cell Access Info 80
(Subframe #5) SIB Scheduling
SIB2 Common & Shared Channels configuration 160
(on SI-1)
SIB3 Common cell reselection information 320
(on SI-2)
SIB4 Intra freq cell neighboring cells information 320
(on SI-2)
SIB 5 Inter freq cell neighboring cells information 640
(on SI-3)
SIB 6 UTRAN cell neighboring cells information 640
(on SI-4)
SIB7 GERAN cell neighboring cells information 640
(on SI-4)
80
A noter aussi:
• SIB 9: Pour les informations relatives au Home eNodeB (Femtocells)
• SIB 10 à SIB 12: Information relatives aux services d’alertes: ETWS
(EarthQuake and Tsunami Warning Service) & CMAS (Commercial Mobile
Alert Service)
• SIB 13: Informations relatives au MBMS
Les SIB sont mappés et multiplexé sur des SI Message (System Information
Messages). Selon la périodicité annoncés des différents SIB certains SIB pourraient
avoir à être transporter sur des SI de rang différents.
A noter que seul le SIB1 qui explique toute la logique et la mécanique de la

distribution des SIB est à positionner dans une sous trame de rang fixe: la sous
trame #5.
80
RRC (5)
Mais aussi:
Le Paging qui a deux objets:
Trouver un UE que le Cœur de réseau cherche à joindre

Indiquer aux UE que les Informations Systèmes sont
nouvelles et nécessitent un cycle de relecture (SIB-1 a
également cette faculté)
81
81
RRC (6)
C’est également au niveau RRC que les Radio Bearer sont gérés.
DRB#1(internet) DRB#2(voix) SRB#0(RRC) SRB#1(NAS)
PDCP PDCP PDCP PDCP
RLC RLC RLC RLC

(AM) (UM) (AM) (AM)
MAC
Vers PHY
C’est par RRC que l’on crée, modifie ou détruit les RB (RRC Connection Reconf).
82
Cette notion extrêmement importante fait référence aux différents flux échangés.
Ces flux sont de deux types:
DRB (Data Radio Bearer): pour les flux de trafic négociés avec le cœur de
réseau. Ils sont associés à une logique de QoS.
SRB (Signaling Radio Bearer): pour les flux de signalisation échangés entre
UE et eNodeB (RRC) et ceux échangés entre UE et CN (NAS).
Chacun de ces RB est associé à une dimension PDCP et RLC. Il se trouvent

ensuite multiplexés au niveau de la dimension MAC.
82
Architectures UTRAN et E- UTRAN
Core Network Core Network

Iu Iu
S1 S1
Iur RNC
RNC
X2
Iub Iub Iub Iub
eNodeB eNodeB
NodeB
Architecture UTRAN Architecture E-UTRAN
83
L’eNodeB est responsable de la transmission et de la réception radio avec l’UE.

A la différence de l’UTRAN 3G où sont présentes les entités Node B et RNC,
l’architecture E-UTRAN ne présente que des eNodeB. Les fonctions supportées
par le RNC ont été réparties entre l’eNodeB et les entités du réseau cœur
MME/Serving GW. L’eNodeB dispose d’une interface S1 avec le réseau cœur.
L’interface S1 consiste en S1-C (S1-Contrôle) entre l’eNodeB et le MME et S1-U
(S1-Usager) entre l’eNodeB et le Serving GW.
Une nouvelle interface X2 a été définie entre eNodeBs adjacents. Son rôle est de
minimiser la perte de paquets lors de la mobilité de l’usager en mode ACTIF
(handover). Lorsque l’usager se déplace d’un eNodeB à un autre eNodeB, de
nouvelles ressources sont allouées sur le nouvel eNodeB pour l’UE ; or le réseau
continue à transférer les paquets entrants vers l’ancien eNodeB tant que le
nouvel eNodeB n’a pas informé le réseau qu’il s’agit de lui relayer les paquets
entrants pour cet UE. Pendant ce temps l’ancien eNodeB relaie les paquets
entrants sur l’interface X2 au nouvel eNodeB qui les remet à l’UE. L'interface X2
est donc utilisée principalement pour faciliter la mobilité en mode actif. L'interface
X2 sert en outre à assurer la mobilité sans perte entre cellules adjacentes en
permettant la retransmission des paquets.
La figure décrit l’architecture E-UTRAN avec ses eNodeB et les interfaces X2
(entre les eNodeB) et S1 (entre eNodeB et entités du réseau cœur MME/Serving
GW).
83
Interfaces Logiques et Physiques
PDN GW
Réseau IP
MME Serving GW
Réseau IP
IP Router
Connectivité d ’accès Connectivité d ’accès

e.g., FTTH e.g., FTTH
Interface X2
Logique
84
84
Interfaces de l’entité eNodeB
PDN GW
ePC Interface basée sur X2-AP
Interface basée sur S1-AP
S5/S8 Tunnel GTPv1-U
S11
MME
• Contrôle des
tunnels GTP-U Serving GW
•Tunnels GTP-U
S1-C
S1-U pour transport le trafic UL et DL
• Handovers Inter eNodeB
• Gestion des bearers •Handover inter-eNodeB
• Paging •Relai du trafic DL pendant le handover
UE
X2
LTE-Uu
eNode B eNode B
85
L ’eNodeB dispose d ’une interface S1 avec le réseau ePC. S1 est présente

sur deux plans : Les plans contrôle et usager. Sur le plan contrôle elle est
appelée S1-C ou S1-MME et met en relation l ’eNodeB avec le MME. Elle est
supportée par le protocole d ’application S1-AP qui s ’appuie sur un transport
SCTP/IP. Sur le plan usager, elle est appelée S1-U et met en relation
l ’eNodeB avec le Serving GW. Elle est supportée par le protocole GTPv1-U
qui s ’appuie sur un transport UDP/IP.
De même sur X2 l’échange de signalisation entre eNodeB se fait via le
protocole d’application X2-AP porté sur SCTP/IP. Principalement concerné par
des problématiques de mobilité du mobile, ce protocole assure également des
échanges pour vérifier la cohérence des paramètres des eNodeB (concept
SON) ou pour optimiser le scheduling (ICIC).
L ’UE dispose d ’une interface radio avec l ’eNodeB. Sur le plan contrôle l ’UE
dispose du protocole RRC avec l ’eNodeB. Sur le plan usager, il s ’agit du
protocole de tunneling PDCP (Packet Data Convergence Protocol). Ce sont
ces mêmes protocoles qui sont utilisés sur les plans contrôle et usager entre
l ’UE et le RNC dans le réseau 3G.
85
4. LTE vu du coté Coeur
ePC, IMS & PCC
86
86
4.1 Architecture & Protocoles
87
87
ePC : Evolved Packet Core (1)
SAE (System Architecture Evolution) est le nom du projet,

ePC (Evolved Packet Core) est le nom du réseau cœur
évolué.
ePC est un réseau cœur paquet tout IP
ePC fonctionne dans le cas de roaming en mode « home
routed » ou en mode « local breakout »
ePC interagit avec les réseaux paquets 2G/3G et HRPD en
cas de mobilité
ePC supporte les Default bearers et Dedicated bearers
ePC supporte le filtrage de paquet (deep packet inspection
par exemple pour la détection de virus) et une taxation
évoluée (taxation basée sur les flux de service).
88
SAE est le nom du projet, EPC (Evolved Packet Core) est le nom du réseau cœur évolué.
EPC est un réseau cœur paquet tout IP. A la différence des réseaux 2G et 3G où l’on distinguait les
domaines de commutation de circuit (CS, Circuit Switched) et de commutation de paquet (PS, Packet
Switched) dans le réseau coeur, le nouveau réseau ne possède qu’un domaine paquet appelé
EPC.Tous les services devront être oferts sur IP y compris ceux qui étaient auparavant offerts par le
domaine circuit tels que la voix, la visiophonie, le SMS, tous les services de téléphonie, etc.
EPC fonctionne en situation de roaming en mode “ home routed ” ou en mode “ local
breakout ”. Lorsqu’un client est dans un réseau visité, son trafic de données est :
Soit routé à son réseau nominal qui le relaye ensuite à la destination (home routed)
Soit directement routé au réseau de destinataire sans le faire acheminer à son réseau nominal (local
breakout). Le mode local breakout est particulièrement intéressant pour les applications temps réel
telles que la voix qui ont des contraintes de délai fortes.
EPC interagit avec les réseaux paquets 2G/3G et CDMA-2000 en cas de mobilité. Il est possible
de faire acheminer le trafic de l’EPC vers l’accès LTE, CDMA-2000 (paquet), 2G (paquet) et 3G
(paquet) et ainsi garantir le hadover entre ces technologies d’accès.
EPC supporte les Default bearers et Dedicated bearers. Lorsque l’usager se rattache au réseau
EPC, ce dernier lui crée un défaut bearer qui représente une connectivité permanente (maintenue tant
que l’usager est rattaché au réseau) mais avec une qualité de service best effort. Lorsque l’usager
souhaitera établir un appel qui requiert une certaine qualité de service telle que l’appel voix ou
visiophonie, le réseau pourra établir pour la durée de l’appel un dedicated bearer qui supporte la
qualité de service exigée par le flux de service.
EPC supporte le filtrage de paquet (deep packet inspection par exemple pour la détection de virus)
et une taxation évoluée (taxation basée sur les flux de service). En effet la LTE fournit des
mécanismes de taxation très sophistiqués permettant de taxer le service accédé par le client sur la
based du volume, de la session, de la durée, de l’événement, du contenu, etc.
88
ePC : Evolved Packet Core (2)
EIR HSS Cx, Sh

IMS
Rx
S13 S6
SPR PCRF Ro Rf
Gx
OCS OFCS
Gy Gz
S1-C
MME
UE eNode B
S11
S1-U
S5 PCEF
Serving GW PDN GW
LTE ePC
Plan de contrôle
Interface DIAMETER Plan usager
89
Le HSS sert l’ePC, l’IMS et les réseaux 2G et 3G.

L ’EIR sert l’ePC ainsi que les réseaux 2G et 3G.
Le PCRF est utilisé par le réseau GPRS (fonction PCEF du GGSN) et par
le réseau ePC (fonction PCEF du PDN GW). L ’OCS et l ’OFCS sont
utilisés par l ’ePC, les réseaux 2G et 3G et l ’IMS.
89
Un mot sur DIAMETER
DIAMETER (RFC 3588/RFC 6733) est une évolution de RADIUS
(Remote Authentication Dial In User Service) qui permet d’aller au
DIAMETER
delà des seuls besoins AAA. Ce protocole améliore RADIUS par:
Une extension des attributs (3 octets versus 1 octet)
RADIUS Un transport via TCP ou SCTP (au lieu d’UDP)
Un usage plus peer-to-peer que client-server.
Une extension des commandes (vendor-specific commands).
Une adaptation possible à IPSEC ou TLS
Un usage multiple via le concept de DIAMETER applications
Redirect Redirect.RealmB.com
Agent
2. Request 3. Redirect Notification
1. Request Relay/Proxy 4. Request

Client Server
Agent
6. Answer 5. Answer
Client.RealmA.com Server.RealmB.com
90
90
Une lente évolution vers
une architecture plate
Release 7
Release 7 Direct Tunnel et Release 8
Release 6
Direct Tunnel RNC dans Node B LTE & ePC PGW
GGSN GGSN GGSN SGW
SGSN SGSN SGSN MME
RNC RNC
Plan Contrôle
Plan Usager
RNC
Node B Node B eNode B
Node B
91
Jusqu’à la Release 6, les éléments impliqués sur le plan contrôle et le plan usager pour un contexte PDP sont
l'UE, le Node B, le RNC, le 3G SGSN et le GGSN.
Afin d’améliorer les performances de HSPA, une architecture plate a été considérée à partir de la Release 7.
A la Release 7, il y a l’option d’une architecture “ one-tunnel ” dans laquelle le réseau établit un chemin (tunnel)
direct pour le trafic usager entre le RNC et le GGSN sans passer par le SGSN. Les éléments impliqués sur le
plan usager sont donc l'UE, le NodeB, le RNC et le GGSN. Par contre le SGSN est toujours présent sur le plan
de contrôle pour l’établissement du contexte PDP. Cela permet de minimiser le nombre éléments ayant à traiter
le trafic usager et donc réduire les délais ainsi que simplifier l’ingénierie du réseau.
Il existe aussi une autre solution encore plus optimisée appelée "NodeB/RNC intégré" dans laquelle les
fonctions du RNC sont intégrées dans le Node B. Ce type de solution apparaît notamment dans les
architectures femtocell. Cette nouvelle amélioration est similaire à celle de l’architecture du réseau 4G appelé
LTE (Long Term Evolution of 3G) où le seul élément présent dans le réseau d’accès est l’eNodeB, qui réalise
certaines fonctions du RNC. Par ailleurs, même si l’interface entre RNC et 3G-SGSN (i.e., interface IuPs)
s’appuyait initialement sur un transport ATM, l’évolution met en jeu un transport GE. De même, alors
qu'initialement les NodeB et les RNCs étaient interfacés par des liens ATM, la tendance est d'assurer
l'interfonctionnement via GE.
Notons toutefois que le Direct Tunnel ne peut pas être utilisé dans les scénarii suivants :
1. Si l’usager est dans un réseau visité, le SGSN doit être présent sur le plan usager pour le comptage des
octets envoyés et reçus par l’usager et pour les reversements entre opérateurs. Aujourd’hui la tarification du
trafic de données lorsque l ’usager est dans un réseau visité est en moyenne de 5 Euros par Mégaoctet
(tarification au volume uniquement).
2. Si l ’usager est relié par un accès 2G au SGSN, ce dernier ne peut pas fonctionner en mode direct tunnel. Ce
mode est réservé au cas où l’usager est pris en charge par un accès 3G (NodeB/ RNC).
3. Le GGSN ne supporte pas le protocole GTPv1. Avec le protocole GTPv0 il n’est pas possible de fonctionner
selon le mode direct tunnel car le protocole GTPv0 ne sait pas dissocier le plan contrôle du plan usager.
Avec la LTE, La fonction MME est similaire à un SGSN en mode direct tunnel puisqu ’elle n ’est présente que
sur le plan de contrôle. Les fonctions SGW et PGW sont toujours présentes sur le plan contrôle et le plan média
même lorsque l ’usager est en situation de roaming.
91
SeGW entre LTE et ePC
S1-C (S1-AP)
LTE S1-U (GTPv1-U)
eNode B S1-C
MME
SeGW Réseau S1-U

ePC
Réseau
IP/GE IP/GE
Serving GW
Tunnel IPSec
eNode B
SeGW : Security Gateway
92
Dans son architecture de référence LTE, 3GPP définit la fonction security

gateway (SeGW) et recommande IPsec comme mécanisme de chiffrement pour
le trafic S1 entre LTE et ePC.
Ceci inclut le trafic de contrôle (Interface S1-C) entre les eNodeBs et les MMEs
et le trafic de données (plan usager) entre les eNodeBs et les Serving GWs.
L’architecture plate LTE expose les MMEs à toute la signalisation générée par
l’accès LTE. Si la charge de signalisation dépasse les limites capacitaires pré-
configurées, le service sera alors compromis. Des pics de trafic de signalisation
peuvent causer des délais,des pertes de paquets et même des interruptions. La
fonction SeGW est logiquement placée à l’interface entre LTE et l’ePC, c’est à
dire sur l’interface S1 et terme les tunnels IPSec pour le trafic généré sur les
plans de contrôle et usager. Par sa localisation dans le réseau le SeGW devient
l’élément de réseau protecteur pour l’ePC de toute charge excessive ou mal
intentionnée de signalisation
92
Mode quasi-associé pour la
signalisation DIAMETER
HSS S6a, S6d, S6c SMSC
SWx, Agent
Cx, Sh (DRF)
OFCS DRF :
Gz, OFCS DIAMETER
S6a Rf
S6a Routing
S6a Gy, Ro, Function
MME Rc, Re
OCS
OCS
S6a
MME Agent
Gx, S9,
(DRF) Rx PCRF
S6d S6d PCRF
Cx, Sh,
Gx, Gy, Gz
Rx, Ro, Rf
IMS
PCEF • I-CSCF
PCEF •S-CSCF
S4-SGSN • P-CSCF
DRF : DIAMETER Routing Function • AS
MME : Mobility Management Entity PDN GW • MRF
PDN GW : Packet Data Network Gateway • MGCF
PCRF : Policy and Charging Rules Function • BGCF
HSS : Home Subscriber Server
OCS : Online Charging System 93
OFCS : Offline Charging System
Interface DIAMETER
Pour des raisons de scalabilité et de simplicité de configuration, le mode quasi-

associé devrait être choisi par les opérateurs pour le transport de la signalisation
DIAMETER. Un agent (similaire à un STP dans le réseau SS7) relie l ’ensemble des
nœuds devant dialoguer avec le protocole DIAMETER. Ce même Agent route le
trafic de signalisation DIAMETER entre ces nœuds. Tous les nœuds par défaut
relaient leur signalisation à l ’agent DIAMETER qui dispose de toute l ’intelligence de
routage. Pour garantir la disponibilité à 100%, les Agents sont déployés par paire,
chaque client ou serveur DIAMETER étant relié au moins à une paire d'Agent.
93
Fonctions EPS de haut niveau
Fonctions de contrôle d’accès réseau, i.e., AAA

(Authentication, Authorization and Accounting) et Fonctions de
sécurité
Fonctions de gestion de la mobilité
Fonctions de gestion de session
Fonctions de routage de paquet et de transfert
Fonctions de gestion de ressource radio
94
Les grandes fonctions assurées par l’EPS sont les:

• Fonctions de contrôle d’accès réseau : Elle permettent d’authentifier l’usager
lorsque ce dernier s’attache au réseau, met à jour sa tracking area, et demande des
resources pour ses communications. Elles permettent aussi de réaliser la taxation
de l’usager en fonction de l’usage des ressources et en fonction des flux de service
émis et reçus. Elle permettent enfin de sécuriser les flux de signalisation et les flux
média des usagers en les encryptant entre l’UE et l’eNodeB.
• Fonctions de gestion de la mobilité : Elle permettent à l’UE de s’attacher, de se
détacher et de mettre à jour sa tracking area.
• Fonctions de gestion de session : Elles permettent d’établir des default bearers
et des dedicated bearers afin que l’UE dispose de connectivités IP pour ses
communications.
• Fonctions de routage de paquet et de transfert : Elle permettent d’acheminer les
paquets de l’UE au PDN GW ainsi que du PDN GW à l’UE.
• Fonctions de gestion de ressource radio : Elle permettent l’établissement et la
libération de RAB (Radio Access Bearer) entre l’UE et le Serving GW à chaque fois
que l’UE souhaite devenir actif pour communiquer.
94
Architecture EPC sans roaming
Rx
IP/IMS
EIR
SGi PCRF
PDN S7 = Gx
Gateway
S13
HSS S5
S6a S11 Serving
MME
Gateway
S1-C S1-U
E-UTRAN
UE eNodeB Interface DIAMETER 95
Les interfaces basées sur DIAMETER/SCTP/IP dans l ’architecture EPC sans roaming
sont :
• L’interface S6a entre MME et HSS pour la gestion de la mobilité de l’usager
• L’interface S13 entre MME et EIR pour vérifier le statut de l’IMEI de l’usager
• L’interface Gx entre le PDN GW et le PCRF afin que le PCRF fournisse au PDN-GW
les règles de taxation et puisse mettre en œuvre sur le PDN GW des politiques de
qualité de service.
• L’interface entre l’IMS (P-CSCF) et le PDN-GW.
Par ailleurs l’eNodeB dispose de l’interface S1 avec le réseau cœur.

L’interface S1 consiste en :
• S1-C sur le plan de contrôle (entre eNodeB et MME) basé sur le protocole S1-
AP/SCTP/IP.
• S1-U sur le plan usager (entre eNodeB et Serving Gateway) basé sur le protocole
GTP-U/UDP/IP.
Le MME dispose d’une interface de contrôle avec le Serving GW appelée S11. Elle
s’appuie sur le protocole GTPv2-C.
Enfin le Serving GW et le PDN GW partagent l’interface S5.
S5 consiste en :
• GTPv2-C/UDP/IP sur le plan de contrôle,
• GTPv1-U/UDP/IP sur le plan usager.
95
Configuration pour l’accès à Internet
et l’accès aux services IMS
Default bearer pour l ’accès à Internet
Internet
Serving PDN
Gateway Gateway
P-CSCF
Default bearer pour
l ’accès aux services IMS
IP Network
PDN
Gateway
96
Le futur client EPS au rattachement au réseau EPS disposera d’une connectivité

permanente appelée default bearer. Cette connectivité lui permettra d’accéder à
Internet. Il s’agit de l’accès au 1er play.
Le second play permet au client d’accéder aux services de la téléphonie via l’IMS.
Une seconde connectivité permanente est donc nécessaire pour le transport des
messages SIP pour invoquer les services de l’IMS comme la téléphonie. La
connectivité pour l’accès aux services de l’Internet et la connectivité pour l’accès
aux services de l’IMS se différencient par leurs QoS. La QoS pour IMS a une QCI
(QoS Class Identifier) égale à 5 alors que celle pour l’Internet peut disposer d’une
QCI égale à 6, 7, 8 ou 9.
Par ailleurs le contrôle et la taxation des flux sur ces deux bearers est différente.
Le default bearer SIP/IMS ne permet que le transport des messages SIP
échangés entre l’UE et le P-CSCF. Tout autre trafic sera rejeté. Ce trafic ne sera
pas payant.
Le default bearer Internet permet le transport de différents flux vers des
applications de l’Internet mais l’opérateur rejettera certains flux qui sont contraires
au business model de l’opérateur. Par exemple, les flux Skype et les flux peer to
pourront être bloqués. La taxation de ces flux peut être online ou offline en fonction
de l’offre data mobile souscrite par le client.
Les deux default bearers se terminent sur un ou plusieurs PDN GW du réseau
nominal si le client est dans son réseau nominal. Par contre les deux default
bearer sont pris en charge par un même Serving GW. L’APN identifie le PDN GW.
96
Implantation physique possible
Rx
IP/IMS
HLR SGSN GGSN SGi PCRF
PDN PCEF Gx
Gateway
HSS
Serving
S6a
MME Gateway
S1-C S1-U
E-UTRAN
NodeB/RNC 97
L’architecture EPS physique peut être mise en oeuvre par mise à jour logicielle et
matérielle de l’architecture 3G paquet.
Le HLR peut évoluer pour devenir un HLR/HSS.
Le SGSN peut intégrer la fonction MME.
Le GGSN peut être mise à jour pour supporter les fonctions Serving GW et PDN
GW.
Le même PCRF 3G peut mettre en œuvre les fonction PCC pour l’EPS.
Enfin certains fournisseurs proposent des NodeB intégrant la fonction RNC. Ces
mêmes Node B peuventt évoluer pour intégrer la fonction eNodeB.
97
Architecture EPC avec Roaming
mode Home Routed
Réseau Nominal A Réseau Visité B

Rx
IP/IMS
PCRF
SGi
PDN Gx
PCEF S8
Gateway
Serving
Gateway
HSS
Agents DIAMETER MME S11
S6a
S1-C S1-U
Interface DIAMETER E-UTRAN

98
En situation de roaming, deux cas se présentent pour le traitement du trafic de

l’usager :
• Local breakout : Le PDN GW est dans le réseau visité et le trafic de l’usager est pris
en charge uniquement par le réseau visité.
• Home routed : Le PDN GW est dans le réseau nominal et le trafic de l’usager doit
être ramené du Serving GW du réseau visité au PDN GW du réseau nominal via l’IPX
(IP Exchange network).
En roaming, le Serving GW et le MME sont toujours dans le réseau visité.
La figure ci-dessus présente le cas “home routed”.
• L’interface S6a est donc présente entre le MME du réseau visité et le HSS du réseau
nominal
• L’interface Gw est établie entre le PDN Gw du réseau nominal et le PCRF du réseau
nominal
• L’interface Rx met en relation le P-CSCF (IMS) du réseau nominal et le PCRF du
réseau nominal.
98
Architecture EPC avec Roaming
mode Local Breakout
Réseau Nominal A Réseau Visité B
Rx IP/IMS
S9
PCRF Agents DIAMETER PCRF SGi
PDN
Gx PCEF
Gateway
HSS
S5
S6a
Agents DIAMETER MME S11 Serving
Gateway
S1-C S1-U
Interface DIAMETER E-UTRAN

99
L’architecture ci-dessus décrit le cas où le trafic est routé localement aussi appelé
cas “local breakout”.
Les Serving et PDN Gateways sont dans le réseau visité. Le PCRF du réseau visité
obtient les règles de taxation et les politiques de qualité de service du PCRF du
réseau nominal via l’interface S9.
99
Roaming international avec
des Agents Diameter
Broker
Broker
e.g., Syniverse
e.g., IBNF
3. Request
Agent Agent
Relai Relai
Diameter Diameter
8. Answer
2. Request
9. Answer 7. Answer
4. Request
1. Request Agent Agent

MME Relai 5. Request
Proxy HSS
Diameter Diameter
10. Answer
6. Answer
Réseau visité Réseau nominal
FT IBNF : France Telecom International
Interface DIAMETER interface
Backbone Network & Factory (IBNF)
Message DIAMETER
100
Dans le cas de roaming il conviendra d’opérer des échanges DIAMETER entre

opérateurs. Il est nécessaire de considérer la présence d'Agents DIAMETER au
niveau international tout comme dans le monde SS7.
Certains HUBs ou brokers internationaux se profilent dans le monde DIAMETER.
Les Agents Diameter seront des composants importants du futur réseau mobile de la
même manière que les STPs/IP STPs sont les composants importants du réseau
mobile actuel.
Les agents Diameter sont obligatoires pour le roaming international dans
l ’environnement EPS. Une hiérarchie d ’agents peut exister incluant des agents
nationaux, des agent nationaux/internationaux et des agents uniquement
internationaux.
100
Configuration typique pour l ’accès à Internet
et l ’accès à l ’IMS depuis un réseau visité
Réseau visité IPX Réseau nominal

Default bearer pour l ’accès à Internet
Réseau IP Réseau IP Réseau IP
S-CSCF PGW
eNodeB SGW
P-CSCF
Default bearer pour
l ’accès à IMS
Réseau IP Réseau IP
PGW
101
Si le client EPS s ’attache depuis un réseau visité, les deux default bearers
Internet et IMS impliqueront les éléments suivants. Un Serving GW du réseau
visité pour les deux default bearers, un PDN GW du réseau nominal pour le
default bearer Internet, un PDN GW du réseau visité pour le default bearer IMS.
En effet, l ’UE doit échanger les messages SIP avec le P-CSCF du réseau visité.
Pour des raisons d ’optimisation, le PDN GW est celui du réseau visité.
101
IMS et roaming
Appliquer le modèle home routed traffic à la VoLTE serait
problématique car il impliquerait que le point d ’entrée IMS soit
localisé dans le réseau nominal. Les conséquences sont :
Le réseau visité ne sera plus informé des sessions multimédia (e.g.,
Appels voix) et des messages courts initiés ou terminés par l ’usager
et donc les revenus de roaming seraient moindres pour les
opérateurs mobiles visités.
Les exigences réglementaires seront difficiles à respecter :
La signalisation SIP peut être chiffrée entre l ’UE et le P-CSCF nominal
et donc le réseau visité ne pourra pas réaliser l ’interception légale
L’appel d ’urgence requiert l ’implication du P-CSCF visité.
Par ailleurs le PGW dans le réseau nominal accroît le délai des
paquets RTP/UDP/IP sur le plan usager.
C’est la raison pour laquelle la GSMA dans son document de
référence IR.65 (IMS Roaming & Interworking Guidelines) requiert
les fonctions P-CSCF/PGW dans le réseau visité pour la voix et
les services conversationnels IMS.
102
Un UE doit disposer d ’une adresse IP pour accéder au monde IMS. Comme le nom l ’indique IMS
correspond à un domaine ou sous-système multimédia sur IP. L ’UE doit établir une connectivité à l ’IMS via
l ’attachement EPS ou via l ’établissement d ’une connectivité avec l ’APN IMS. Comme montré
précédemment l ’EPC assigne une adresse IP à l ’UE. Cette adresse IP peut être IPv4 ou IPv6 et est
utilisée pour l ’enregistrement au monde IMS. Afin d ’associer l ’identité de l ’UE dans le monde IMS à
l ’adresse IP assignée.
Lorsque l ’UE est dans son réseau nominal, tous les nœuds sont aussi dans le réseau nominal (eNodeB,
MME, SGW, PGW, IMS) et la connectivité est obtenue dans ce réseau.
En situation de roaming 3GPP spécifie que la connectivité IP peut se terminer dans le réseau nominal ou
dans le réseau visité. Dans les réseaux GPRS et les réseaux LTE n ’offrant que le service d ’accès à
Internet/Intranet, la connectivité se termine toujours dans le réseau nominal. Cela signifie que les entités
eNodeB, MME, SGW appartiennent au réseau visité dans lequel se trouve l ’usager alors que le PGW est
dans le réseau nominal de ce même usager. Appliquer ce modèle à la VoLTE serait problématique car il
impliquerait que le point d ’entrée IMS soit localisé dans le réseau nominal. Les conséquences sont :
• Le réseau visité ne sera plus informé des sessions multimédia (e.g., Appels voix) et des messages courts
inités ou terminés par l ’usager et donc des revenus de roaming moindres pour les opérateurs mobiles
visités.
• Les exigences réglementaires seront difficiles à respecter :
• La signalisation SIP peut être chiffrée entre l ’UE et le P-CSCF nominal et donc le réseau visité ne
pourra pas réaliser l ’interception légale
• L ’ appel d ’urgence requiert l ’implication du P-CSCF visité.
• Par ailleurs le PGW dans le réseau nominal accroît le délai des paquets RTP/UDP/IP sur le plan usager.
C ’est la raison pour laquelle la GSMA dans son document de référence IR.65 (IMS Roaming &
Interworking Guidelines ) requiert les fonctions P-CSCF/PGW dans le réseau visité pour la voix et
les services conversationnels IMS.
http://www.gsma.com/newsroom/wp-content/uploads/2012/03/ir6570final.pdf
102
Le S4-SGSN
• Authentification HSS
• Gestion de la localisation
• Profil Usager
EIR
• Gestion de la mobilité entre S6d S13 ’
eUTRAN et UTRAN/BSS (S3) S4-SGSN
• Status de l ’IMEI
S3
MME • Contrôle des tunnels GTP-U
• Tunnels GTP-U en mode sans
Gb direct tunnel
S4
IuPs
Serving GW
• Handovers Inter eNodeB NAS
• Gestion des bearers (GMM, SM)
• Paging
• Gestion de la mobilité
• Gestion de session
BSC
Interface basée sur Diameter
Interface basée sur GTPv2-C RNC UE
Tunnel GTPv1-U
103
Le réseau LTE se doit d’interagir avec les membres de sa famille, à savoir GSM/GPRS et UMTS.
Ces réseaux possèdent une dimension similaire à l’ePC: leur dimension PS centrée sur le couple
SGSN-GGSN.
L’interopérabilité entre les dimensions paquet de ces systèmes peut donc se jouer de manière
simple partant du simple fait que MME et SGSN ont quelques similitudes, sont basés sur les
mêmes concepts et manipulent sensiblement les mêmes protocoles notamment GTP pour les
besoins de signalisation inter GSN et de tunnelisation des bearers.
Il faut néanmoins prévoir un dialogue de mobilité entre l’entité SGSN et l’entité MME car un rendez
vous radio est a négocier si le mobile quitte la couverture LTE pour rejoindre une couverture
GERAN/UTRAN et inversement bien sur. Dans ces réseaux anciens de tels dialogues n’existaient
pas.
Une voie possible pourrait constituer à voir le PDN-GW comme un GGSN apte à opérer l’interface
Gn/Gp (SGSN-GGSN) et permettant de traiter l’interopérabilité de manière très classique: le tunnel
GTP entre SGW et PDN-GW est remplacé par un tunnel entre SGSN et PDN-GW.
La voie qui a été préférée est d’imposer un nouveau genre de SGSN: le S4-SGSN apte d’une part
à dialoguer via l’interface S3 avec son homologue MME pour parler handover et d’autre part à
ouvrir un tunnel GTP via l’interface S4 vers un Serving GW assurant alors un rôle de MME au yeux
du SGW.
Il est a noté ici que si l’option tunnel mode est permise alors via l’interface S12 le tunnel GTP va
directement du RNC au SGW.
L’un des intérêts principaux de cette architecture est de faire du SGW un point d’ancrage unique de
mobilité pour un usager quel que soit le type de RAN réellement emprunté.
Mais cette architecture de mobilité ne permet que de faire transiter tous les flux paquets d’un
monde à l’autre. Si les flux à faible connotation temps réel de type web, mail ou streaming pourront
aisément passer du LTE au dimensions paquet 2G/3G avec peut être des surprises au niveau des
débits obtenus qu’en est il pour les flux temps réel comme la voix qui ne sont traités que par des
MSC/GMSC dans la partie 2G/3G? Un MME devra t-il dialoguer avec un MSC ? Un MSC se
mettra-t-il à parler IMS ?
103
Interfonctionnement 2G/3G
PDN GW
EIR
• Contrôle des tunnels GTP-U
S5/S8 • Tunnels GTP-U pour le transport du
trafic usager
HSS
S13’ Serving GW
S6d S4
•Tunnels GTP-U pour le transport du
S12 trafic UL et DL si implantation du
mode Direct Tunnel
S4-SGSN
Gb IuPs • Contrôle des tunnels GTP-U
• Tunnels GTP-U pour le transport
BSS du trafic usager en mode sans
UTRAN direct tunnel
104
Lorsque l’usager EPS s’attache au réseau 2G ou 3G faute d’avoir trouvé de couverture LTE, il
émet une requête Attach request d’un côté au MSC server et de l’autre au S4-SGSN. Un S4-
SGSN est un SGSN qui dispose d’une interface DIAMETER S6d avec le HSS, d’ue interface
DIAMETER S13’ avec l’EIR et une interface S4 (GTPv2C/GTP-U) avec le Serving GW.
Lorsque le S4-SGSN reçoit la demande Attach de l’UE, il contacte le HSS : Deux situations sont
possibles :
• Le client qui s’est attaché a une souscription LTE. Dans ce cas, le HSS retourne le profil EPS
du client au S4-SGSN.
• Le client qui s’est attaché n’a pas de souscription LTE. Dans ce cas, le HSS ne trouve pas de
profil EPS pour ce client et demande au HLR (C’est le même système qui contient les fonctions
HLR et HSS) de lui fournir le profil GPRS du client. Ce profil est passé du HLR au HSS qui le
retourne via l’interface S6d au S4-SGSN.
A la différence du MME, le S4-SGSN n’établit aucun défault bearer ou conexte PDP primaire
lorsque le client s’attache. Le S4-SGSN après avoir authentifier le client, vérifié son IMEI et
obtenu son profil d’abonné, retourne à l’UE la réponse Attach Accept.
C’est à l’UE de demander explicitement l’établissement de chaque contexte PDP primaires au
S4-SGSN.
Si le client a une souscription EPS, ses contextes PDP termineront sur le PDN GW et non pas le
GGSN pour garantir une mobilité 4G vers 3G ou 2G sans perte de session IP. Dans ce cas, le
S4-GSN dialogue sur le plan contrôle avec le SGW (interface S4) qui relaie les messages au
PGW (interface S5/S8).
Si l’accès est 3G, le mode direct tunnel est possible pour le S4-SGSN, i.e., le S4-SGSN ne sera
présent que sur le plan de contrôle
Si l’accès est 2G, le mode direct tunnel n’est pas envisageable pour le S4-SGSN, i.e., le S4-
SGSN sera présent sur les plans contrôle et usager.
104
Configuration typique pour l ’accès à Internet
et l ’accès à l ’IMS pour un client LTE rattaché
à la 2G (donc sans Direct Tunnel)
Contexte PDP pour l ’accès à Internet

BTS BSC S4-SGSN
Internet
Serving PDN
Gateway Gateway
P-CSCF
Contexte PDP pour l ’accès
aux Services IMS
IP Network
PDN
Gateway
+ Attachement de l ’UE au domaine circuit
105
Si le client EPS se rattache depuis son réseau nominal depuis un accès 2G ou 3G

faute de couverture LTE, il est alors pris en charge par un S4-SGSN. Il s’agit d’un
SGSN qui a la capacité à s’interfacer au réseau ePC. En effet, il faut que les
bearers du client se terminent sur un PDN GW et non pas un GGSN. C’est le PDN
GW qui alloue une adresse IP au client et si le client plus tard détecte un eNodeB
LTE, il pourra alors basculer sur la technologie LTE sans perdre ses sessions de
données puisque le même PDN GW conserve les bearers du client ainsi que son
adresse IP.
La figure ci-dessus montre les bearers en considérant que le direct tunnel n’est
pas implanté du fait qu ’il s ’agit d ’un accès 2G. Le S4-SGSN est présent sur le
plan de contrôle et le plan usager.
Les bearers sont établis via BTS/BSC (en considérant l’accès 2G), puis S4-SGSN,
puis l’ePC (à travers le SGW et le PDN GW).
Cette architecture simplifie la gestion de la mobilité inter-RAT (Radio Access
Technology) et garantit bien la continuité des sessions de données quelque soit le
scénario de mobilité.
105
Configuration pour l’accès à Inter-net et
l’accès à l ’IMS pour un client LTE rattaché
à la 3G (Direct Tunnel)
Contexte PDP pour l ’accès à Internet

Node B RNC
Internet
Serving PDN
Gateway Gateway
P-CSCF
Contexte PDP pour l ’accès
aux Services IMS
Réseau IP
PDN
Gateway
+ Attachement de l ’UE au domaine circuit
106
La figure ci-dessus est identique à celle précédente mais en considérant le mode

direct tunnel. Dans ce mode, le S4-SGSN n’est plus présent sur le plan usager. Les
bearers sont établis via NodeB/RNC (en considérant l’accès 3G), puis l’ePC (à travers
le SGW et le PDN GW). Si l ’accès avait été 2G (GPRS/EDGE), il n ’aurait pas été
possible de considérer le mode direct tunnel. Le S4-SGSN est dans ce cas précis
présent sur les plans contrôle et usager.
106
Architecture EPC pour un accès
WLAN non fiable (untrusted)
Réseau Réseau nominal 3GPP
Non-3GPP
HSS
SWx
3GPP AAA
PCRF
Server
UE SWm
SWu Gx
WiFi ePDG
AP S2b
PDN
Gateway
ePDG : Evolved Packet Data Gateway
Interface Diameter AP : Access Point
107
L ’architecture ePC permet le rattachement depuis un accès WLAN non fiable

(untrusted) comme le montre la figure ci-dessus.
Son architecture est similaire à celle de l'UMA/GAN, à savoir le déploiement
d'une passerelle d'interconnexion, l ’ePDG (Evolved Packet Data Gateway).
Le mobile sous couverture WiFi établit un lien IP sécurisé avec l ’ePDG (via
l'accès xDSL, FTTx ou câble) positionné directement dans le réseau coeur.
Contrairement à l'UMA/GAN qui supporte indifféremment les modes "circuit" et
"paquet", l'I-WLAN ne permet d'accéder qu'au mode "paquet". Les
communications téléphoniques ne deviennent alors possibles que grâce au
déploiement d'une infrastructure de voix sur IP située dans le cœur du réseau
(reposant par exemple sur le protocole SIP, voire sur l'architecture IMS).
Le 3GPP a normalisé les extensions du standard permettant un basculement
des communications en cours de communication ("handover") entre la 3G et le
WiFi. Le "handover" entre le réseau GSM/UMTS et le service de voix sur IP sur
WLAN sera contrôlé par un serveur d'application de l'IMS appelé VCC (Voice
Call Continuity)
107
Interfonctionnement
Réseaux IP
externes
PDN GW
Domaine de Commutation de Paquet

(Architecture Evolved Packet Core)
LTE Larde bande

HRPD
Fixe (e.g., xDSL)
2G/3G

HRPD : High Rate Packet Data WLAN
ePC : Evolved Packet Core
108
L’architecture ePC a été conçue afin de permettre l’interfonctionnement avec tout type
d’accès. Cette approche permet de rendre la connexion avec un réseau IP externe
indépendante de la technologie d’accès. Le réseaux IP externe est appelé à un niveau
générique PDN (Packet Data Network). La manière d’obtenir son adresse IP en tant qu ’UE,
la gestion de la souscription de l’usager, la procédure d’authentification et le contrôle ainsi
que la taxation des flux IP de l’usager sont donc indépendants de la technologie d’accès
qu ’elle soit fixe, wireless ou mobile.
En effet l’ePC a été pensé afin de permet l’accès depuis l’accès LTE (via des eNodeB) ,
l’accès depuis la 2G/3G via un SGSN appelé S4-SGSN ou l’accès depuis un accès large
bande fixe (xDSL, Câble, FTTx, etc.) via un Access Point WiFi. L’Access Point WiFi sera
relié via l’accès large bande fixe à un nœud ePDGde l ’ePC. Dans tous les cas, les bearers
du client se terminent sur un ou des PDN GWs de l’ePC. C’est ce même PDN GW qui
assure l’assignation de l’adresse IP à l ’UE, le contrôle et la taxation des flux, la gestion de
la mobilité inter technologie d’accès, e.g., 2G ou 3G paquet vers 4G et vice versa, WiFi vers
4G et vice versa (afin de garantir au client la continuité de sa session de données même en
situation de mobilité). Dans cette architecture, il est aussi possible de considérer des
femtocell ou des efemtocells. Ces femtocells remplacent les Access Points WiFi chez le
client.
108
Accès à l’ePC : Plan usager
IPSec
WiFi Accès Câble ePDG
AP Accès xDSL Réseau IP
Accès FTTx
Accès 2G SNDCP GTP-v1U
GTP-v1U
Réseau IP Réseau IP
BTS BSC S4-SGSN
GTP-v1U
Serving GW GTP-v1U PDN GW
Accès 3G
PDCP
GTP-v1U ePC
Node B RNC
Accès 4G
PDCP
109
Le protocole IPSec est utilisé entre l ’UE et l ’ePDG (Accès WiFi).

Le protocole PDCP est utilisé entre l ’UE et l ’eNodeB (Accès LTE) et entre l ’UE
et le RNC (Accès 3G).
Le protocole SNDCP est utilisé entre l ’UE et le S4-SGSN (Accès 2G).
Le protocole GTPv1-U est utilisé entre :
• L ’ePDG et le PDN GW
• Le S4-SGSN et le Serving GW
• Le Serving GW et le PDN GW
• Le RNC et le S4-SGSN (si le direct tunnel n ’est pas mis en oeuvre)
• Le RNC et le Serving GW (si le direct tunnel est implémenté)
• L ’eNodeB et le Serving GW
109
Accès à l’ePC : Plan de contrôle
3GPP AAA Diameter (SWx)

WiFi
Server HSS
EAP-AKA Diameter (S6d)
IKEv2
2G Diameter (S6a)
GMM
Diameter (SWm)
SM
3G S4-SGSN
ePDG GTPv2-C (S2b)
EMM GTPv2-C (S4)

4G
ESM
MME
GTPv2-C (S5/S8) PCEF
GTPv2-C (S11)
Serving GW PDN GW
110
110
PCC : Policy and Charging Control (1)
SPR : Subscription Profile Repository
P-CSCF : Proxy Call Sessionful Control Function
DIAMETER Interface IMS
Ro Rf
Rx Rc
PCRF OCF ABMF
S9 Re
Sy RF
OCS
Sp Gy
SPR PCRF OFCS
Gx Gz OCS : Online Charging System

OFCS : Offline Charging System
UE EPS bearer PCEF AF : Application Function
ABMF : Account Balance
Management Function
RF : Rating Function
111
PDN GW
L’entité PCRF réalise deux fonctions :

• Elle fournit au PCEF les règles de taxation lorsqu’un default bearer ou un
dedicated bearer est activé ou modifié pour l’usager. Ces règles de taxation
permettent au PCEF de différencier les flux de données de service et de les
taxer de façon appropriée. Par exemple, si l’usager fait transiter sur son
contexte PDP primaire des flux WAP et des flux de streaming, il sera possible
au PCEF de distinguer ces deux flux et de taxer le flux WAP sur la base du
volume alors que le flux de streaming sera taxé sur la base de la durée.
• Elle permet de demander au GGSN/PDN GW d’établir, de modifier et de
libérer des contextes PDP secondaires sur la base de QoS souhaitée par
l’usager (interface Gx). Par exemple, Si l’usager demande l’établissement
d’une session IMS, un message SIP sera envoyé au P-CSCF qui dialoguera
avec le PCRF (interface Rx) pour lui indiquer la QoS requise par l’usager pour
cette session. Le PCRF dialogue alors avec le GGSN (interface Gx) pour créer
le contexte PDP secondaire correspondant.
Afin de générer les règles de QoS et les règles de taxation, le PCRF doit accéder à
une base de données pouvant fournir des données de souscription de l ’usager. Cette
dernière s ’appelle SPR (Subscription Profile Repository) et dispose d ’une interface
Sp avec le PCRF.
La taxation online est réalisée grâce à l ’entité PCEF qui demande des crédits à
l ’entité OCS (Online Charging System). L ’OCS s ’interface au module contenant les
comptes online via l ’interface Rc et au module de rating via l ’interface Re.
La taxation offline consiste en la génération de tickets à la fin du contexte PDP. Ces
tickets sont soumis du PCEF à l ’entité OFCS.
111
Aujourd’hui grâce aux procédures PCC, les opérateurs ont la

possibilité d’implanter les scénarii suivants :
Fair usage : Les opérateurs mobiles peuvent limiter la bande passante

disponible aux usagers les plus consommateurs, typiquement ceux qui
téléchargent en peer to peer. Par exemple, au delà d ’un certain volume
mensuel (e.g., 5 Gbytes), le débit est limité à 40 kbit/s.
Freemium : Les opérateurs mobiles peuvent offrir l ’accès à des
applications telles que Facebook ou Twitter, afin d ’attirer les usagers à
souscrire un abonnement data mobile et ainsi accéder à d ’autres services
data mobiles.
Contrôle d ’application : Les opérateurs mobiles peuvent bloquer certains
flux d ’application (e.g., skype, mail) tant que l ’usager n ’a pas souscrit à
l ’option permettant l ’usage de ces applications.
Bill-shock prevention (anti bill shock) : Les opérateurs peuvent alerter
leurs clients lorsque ces derniers ont consommé leur forfait et lorsque tout
usage supplémentaire induit des coûts additionnels.
112
112
Speed boost : Les clients qui souhaitent utiliser des applications

consommatrices en bande passante peuvent souscrire pour une
augmentation temporaire de leur bande passante maximum. Le but pour
l ’opérateur est la génération de revenus.
Premium mobile video : Les clients peuvent vouloir payer plus pour
disposer d ’un service de vidéo mobile offrant une qualité supérieure
sans affecter leur crédit data. Le but pour l ’opérateur est la génération
de revenus et pour le client une préservation de leur crédit data restant.
Contrôle parental : Selon la souscription, interdire l ’accès à un
ensemble d ’URLs.
113
113
Et demain:
Services Multimédia sur IP avec IMS (Policy Control) : Les clients
disposeront d ’une option voix sur IP proposée par les opérateurs
lorsque la VoLTE sera mise en œuvre. A chaque session VoIP,
l ’opérateur réserve des ressources à l ’accès pour garantir la qualité
de service au client.
Qualité de service pour les services temps réels sur Internet
(Policy Control) : Les clients pourront acheter de la qualité de service
pour certains de leurs services sur Internet qui l ’exigent : jeux
multimédia en réseau où la latence doit être la plus petite possible,
visiophonie skype où le débit et la latence doivent être garantis pour la
durée de la session, Internet TV où le débit dit être maintenu pour la
durée de la session.
Prépayé Voix sur IP et SMS sur IP (Charging Control) : Lorsque la
VoLTE sera mise en œuvre, la voix et le SMS seront proposés au
client en postpayé ou prépayé. Pour les offres prépayés, l ’opérateur
doit prendre en charge la taxation online de la voix à la durée et du
SMS à l ’événement. 114
114
Jusqu’à 3GPP R5 GGSN

1 PDP Bearer = 1 QoS Flow
UE
PDP Based Charging
Améliorations3GPP R6 GGSN
1 PDP Bearer = n Service Flows
UE Flow Based Charging Control
Améliorations 3GPP R7
GGSN
1 PDP Bearer = n Service Flows
UE
Flow Based Policy and Charging Control
115
Dans les anciennes versions des normes mobiles 3GPP (incluant la release 5, R5), l’usager
établissait son PDP context (Packet Data Protocol Context) avec la qualité de service associée
en fonction du type de service demandé par le client. La taxation s’opérait sur l’ensemble des
flux échangés sur le PDP context soit en fonction du volume( nombre d’octets émis et reçus
concernant l’ensemble des flux échangés sur le PDP context) ou en fonction du temps (durée
du PDP context).
Malheureusement, il n’était pas possible d’appliquer différentes rèlges de taxation sur différents
flux de service (e.g., WAP, streaming) qui auraient pu être échangés sur le même PDP context.
Pour différents flux de service taxés différemment, il aurait fallu ouvrir plusieurs PDP context, et
chacun transportant un type de flux. Aujourd’hui les terminaux même très évolués ne savent pas
ouvvrir plus de deux PDP contexts.
Avec l’émergence de l’IMS et l’avènement des nouvelles applications sur IP, l’organisme de
normalisation 3GPP a décidé de définir une architecture de taxation beaucoup plus flexible où il
s’agit de taxer les flux de service individuellement et non pas le PDP context dans son
ensemble.
A partir de la Release 6 des spécifications 3GPP, Les flux de service appelés SDFs (Service
Data Flows) sont identifiés individuellement même s’il sous tous transportés sur le même PDP
context (voir figure).^Chaque flux peut être taxé individuellement.
Avec la Release 7, chaque flux peut être contrôlé (e.g., autorisé/bloqué) et taxé en fonction
d’une règle de taxation associée au flux de service.
Chaque règle de taxation définit un filtre IP pour identifier le flux de service. Ce filtre consiste en
un quintuplet (adresse IP source, adresse IP destination, port source, port destination, protocole
utilisé au dessus d’IP). Cet définition permet l’identification les paquets du flux émis ou reçus par
le terminal parmi le grand nombre de paquets IP transitant par le PDP context. Par exemple:
• Une session WEB vers un serveur WEB A
• Une session de streaming à partir du serveur B
• Une session WAP vers un serveur WAP D
• La signalisation SIP associée à des services IMS vers le serveur IMS appelé P-CSCF
• Le trafic DNS vers le serveur DNS, etc.
115
pcrf1.orange.fr ocs1.orange.fr ofcs1.orange.fr
UE IP 192.168.100.1 (Internet)
UE IP 192.168.100.2 (SIP signaling)
PCRF OCS OFCS
Gx Gy Gz
2 Contextes PDP
SGSN/SGW
UE Charging Rule2
Service Flow2 (Internet)
Packets to/from any IP Filter 2 P
C
Charging Rule3 E
Service Flow1 (IMS Signaling)
ggsn1.orange.fr F
Packets to/from IP 192.130.1.6 and Port 5060 IP Filter 3 P-CSCF
IP 192.130.1.6
PCEF : Policy and Charging Enforcement Function GGSN/PDN GW Port 5060
OCS : Online Charging System Un exemple de plan tarifaire pour les services basés
OFCS : Offline Charging System sur le contenu
Service type Method Tariff of Group A
WAP Volume-based $0.10/KB
Video streaming Time-based $0.50/minute
IMS Signaling Free
116
Les services offerts par le monde Internet sont délivrés sur le même contexte
PDP primaire.
Une règle PCC est configurée, associée au contexte PDP utilisé pour l ’accès à
Internet. Cette règle demandera la notification au PCRF lorsque 5 Go ont été
consommés, afin de limiter le débit dès lors que les 5 Go auront été atteints. Une
autre règle sera associée au trafic Internet pour bloquer tout autre flux qui n ’est
pas un flux lié à Internet.
La signalisation SIP est délivrée sur un autre contexte PDP primaire. Deux règles
PCC sont configurées pour la signalisation SIP. La première autorise le flux SIP
entre l ’UE et le P-CSCF. La seconde demande le blocage de tout traffic entre
l ’UE et toute autre adresse IP qui n ’est pas celle du P-CSCF.
116
Home Subscriber Server (HSS)
Avec la technologie LTE, le HLR est réutilisé et renommé

Home Subscriber Server (HSS). Le HSS est un HLR évolué
et contient l’information de souscription pour GSM, GPRS,
3G, LTE et IMS.
A la différence de la 2G et de la 3G où l’interface vers le
HLR est supportée par le protocole MAP (protocole du
monde SS7), l’interface S6 s’appuie sur le protocole
DIAMETER (protocole du monde IP).
Le HSS est une base de données qui est utilisée
simultanément par les réseaux 2G, 3G, LTE/ePC et IMS
appartenant au même opérateur. Il supporte donc les
protocoles MAP (2G, 3G) et DIAMETER (LTE/ePC, IMS).
117
117
Interfaces HSS
I-WLAN
IMS LTE / ePC
3GPP AAA
I-CSCF, S-CSCF AS Server
MME
SWx
Sh S6a
Cx S6c SMSC
UPSF
HSS
SMSC
C S6d
MSC/VLR GMSC D HLR HSS
C
D Gr S4-SGSN
C
MSC Server GMSC Server
Interface DIAMETER 2G/3G SGSN
Interface MAP
2G/3G CS Domain 2G/3G PS Domain 118
Le HSS consiste en les fonctionnalités suivantes :

• Fonctionnalité HSS IP multimédia afin de fournir le support au fonctions de contrôle de
session IMS, telles que les I-CSCF et S-CSCF (Interface Cx basée sur DIAMETER) et
contrôle de service (Interface Sh).
• Fonctionnalité HSS EPS nécessaire afin que les usagers EPS accèdent au domaine
paquet ePC (Interface S6a/S6d).
• Fonctionnalité HSS pour l ’accès non-3GPP à l ’EPS nécessaire afin de permettre à un
3GPP AAA Server d ’obtenir du HSS les informations d ’authentification pour authentifier
l ’usager I-WLAN, ainsi que son profil d ’usager I-WLAN.
• Fonctionnalité HLR/AuC requise pour le domaine PS (Interface Gr, Gc).
• Fonctionnalité HLR/AuC requise par le domaine circuit, s’il est nécessaire que les
usagers accèdent au domaine circuit ou pour supporter le roaming dans des réseaux
visités légataires supportant le domaines circuit 2G/3G (Interfaces C, D).
Un réseau nominal peut être supporté par un ou plusieurs HSSs. Le nombre est fonction du
nombre d’usagers mobiles, de la capacité du HSS et de l’organisation du HSS.
Le HSS prend en charge le stockage des informations suivantes de l’usager :
• Identités privée et publiques de l’usager
• Information de sécurité de l’usager pour les aspects autorisation et authentification.
• Information de localisation de l’usager. Le HSS supporte l’enregistrement de l’usager et
mémorise l’adresse du nœud réseau auquel il est rattaché.
• Le profil de l’usager contenant entre autres les maques de service de l’usager autorisant
l’accès à ces services
Le HSS génère aussi des informations de sécurité usager pour l’authentification mutuelle, le
chiffrement et l’intégrité des données. 118
Protocoles UE-MME
Désormais on parle:
VLR
EMM: Enhanced Mobility Management CM
ESM: Enhanced Session Management
MM
NAS layers 2G/3G MSC

UE
CM SM ESM
SM
MM GMM EMM
GMM
Acess Layers 2G/3G SGSN
2G+, 3G, 3G+, LTE
SM
MME
Access Networks EMM
119
119
Etats ESM & ECM
120
120
Identités du UE
Le UE est doté de multiples identités:
• RADIO: RNTI
• RESEAU: IMSI, GUTI
• SERVICE: @IP, MSISDN, Identifiants IMS
121
121
Plan usager: UE - PDN GW
Application Application
IP IP IP IP
PDCP Relay Relay

GTP-U
PDCP GTP-U GTP-U GTP-U
L2’ L2’
RLC RLC UDP/IP UDP/IP UDP/IP UDP/IP
MAC MAC L2 L2 L2 L2
L1 L1 L1 L1 L1 L1
L1’ L1’
LTE- Uu S1-U S5/S8 SGi
Application
UE eNodeB Serving GW PDN GW Server
122
122
Architecture SMS in MME
Interface DIAMETER HSS

Interface MAP ou DIAMETER
HSS
Interface MAP
S6c/C
S6a SMSC
UE
SGd
Uu S1-MME
UE E-UTRAN MME
HSS
HSS
S6c/C
S6a C
UE IWF SMSC
SGd E
Uu S1-MME
UE E-UTRAN MME IWF
123
L’architecture “SMS in MME” requiert le support de la fonctionnalité SMS dans le MM; le

MME doit aussi pouvoir recevoir les informations de souscription relatives au service SMS
du HSS. Ces informations de souscriptions peuvent directement être fournis par le HSS
via l’interface S6a (ou S6d pour le S4-SGSN).
Il n’y a aucun impact au niveau de l’UE . Le SMSC est le même que celui du domaine CS
(Circuit Switched) à l’exception des nouvelles interfaces SGd et S6c qui sont basées sur
le protocole DIAMETER (spécifiées dans 3GPP TS 29.338).
S6a : Afin de supporter “SMS in MME”, l’interface S6adoit permettre au MME d’obtenir du
HSS les information de souscription SMS et d’enregistrer le serving node (MME Id) pour
le service SMS. Les informations de souscription SMS incluent par exemple l’état de
barring des MO-SMS et MT-SMS et le MSISDN. Si le HSS détermine que le MME doit
être désenregistré pour SMS, il doit le lui indiquer.
S6c : Afin de supporter "SMS in MME”, l’interface S6d doit permettre au SMSC de
demander les informations de routage du SMS au HSS.
SGd : Afin de supporter "SMS in MME”, l’interface SGd doit permettre le relai du SMS du
SMSC au MME destinataire et vice versa.
123
IMS (1)
Comme la téléphonie est simplement une application sur

Internet, toute entreprise, même sans fournir de réseau d’accès,
peut proposer un service de téléphonie.
Microsoft (MSN), Yahoo (Messenger), Google (GoogleTalk) et
Ebay (Skype) sont déjà présents sur ce marché mais proposent
des solutions de téléphonie propriétaires.
Les opérateurs voudront continuer à offrir des services
téléphoniques même lorsque les réseaux IP auront remplacé les
réseaux téléphoniques actuels. Les opérateurs ne veulent pas
abandonner les services à l’usagers et devenir uniquement des
transporteurs de paquets IP. En effet l’accès est devenu une
commodité avec une pression forte sur les prix.
Les opérateurs doivent rapidement adopter l’IMS avant que
les solutions propriétaires puissent être largement adoptées,
sinon ils se contenteront d ’être des fournisseurs d’accès.
124
L’IMS permet de conserver l’intelligence dans le réseau même si le transport s’appuie

désormais sur IP. Avec le monde IP, par défaut l’intelligence est à la périphérie, c’est à
dire dans les terminaux connectés au réseau IP. L’IMS suit donc la philosophie du RTC
et du GSM pour que l ’opérateur puisse proposer et facturer des services
conversationnels sur IP.
L’IMS peut offrir plus que simplement les services voix car c’est une architecture qui
s’appuie sur un transport IP qui par définition est un transport multiservices. Ainsi des
sessions voix, vidéo et data sont possibles avec l’IMS.
L’IMS est une architecture indépendante de tout accès large bande, permettant demain
à un opérateur global de mettre en œuvre une seule instance IMS qui pourra offrir des
services conversationnels à ses clients xDSL, 3G, WiMax, câble, etc. Ceci est différent
de la situation actuelle, où il y a d’une part des commutateurs RTC et d’autre part des
commutateurs GSM qui servent les clients fixe et mobile respectivement.
L ’IMS supporte le concept de roaming permettant aux clients d ’un opérateur de
disposer de leurs services IMS dans leur réseau nominal et dans des réseaux visités.
L ’IMS fournit des services temps réels (e.g., session audio et vidéo entre un appelant
et un appelé, session conférence audio ou vidéo), des services pseudo temps réel
(e.g., session push to talk entre différents participants), et des services non temps réel
(e.g., envoi d ’un message court).
L ’IMS permet la mobilité de l ’usager qui peut s’enregistrer sur tout terminal IMS, la
mobilité des services qui permet à l ’usager de disposer de ses services la où il
s ’enregistre, et la mobilité de session permettant de transférer la session d ’un terminal
à un autre terminal.
L ’IMS permet de disposer de plusieurs sessions actives simultanément (e.g., session
voix mise en garde où l ’appelé joue à l ’appelant une musique d ’attente, session voix
active et session data parallèle pour l ’échange de message courts, photos, fichiers,
etc.).
124
IMS (2)
Normalisé par le 3GPP sous la dénomination IMS dans les Releases

R5 et R6 (Accès principalement 3G)
Normalisé par le 3GPP2 sous l ’appellation IMS (accès CDMA2000)
Normalisé par TISPAN sous la dénomination Core IMS (Accès
principalement xDSL)
Normalisé par PacketCable sous le nom PacketCable Multimedia
(Accès Cable)
La Release R7 de 3GPP a pour objectif de définir une architecture

IMS qui soit complètement indépendante de tout type d ’accès
appelée COMMON IMS.
La Release R8 de 3GPP continue de définir des aspects non traités
tels que Operations Administration and Maintenance (OAM) et le
service brokering, et se focalise sur l’adaptation de l’IMS aux réseaux
d’accès de 4ème génération.
125
L ’IMS est défini par différents organismes qui ont réutilisé les spécifications d ’origine
qui proviennent du 3GPP et les ont adapté à leur accès respectif.
3GPP spécifie l ’IMS R5 pour offrir des services non temps réel ou pseudo réels sur
IP pour un accès 3G. L ’IMS Release 6 quant à lui concerne tout type de service
incluant les services temps réel tels que la voix ou la vidéotéléphonie sur IP pour un
accès 3G.
TISPAN adapte les spécifications Release 6 au cas de l ’accès xDSL.
PacketCable adapte les spécifications Release 6 au cas de l ’accès Câble.
3GPP2 adapte les spécifications Release 5 au cas de l ’accès CDMA2000 qui
représentent la 3G aux normes américaines.
3GPP sera responsable d ’éditer les spécifications d ’une architecture de réseau et
de services IMS indépendante de tout type d ’accès appelée IMS R7.
125
IMS (3)
xDSL
RACS
Rx
NASS
Rx
LTE + ePC = EPS Common IMS
PCRF Rx
NASS Rx
Packet Cable
RACS
NASS
... IP Backbone
WiMAX
RACS
NASS 126
Chaque réseau d’accès a des méthodes d’attachement et de réservation des

ressources spécifiques. L’architecture Common IMS indépendante de tout accès
s’appuiera sur les principes de réservation des ressources qui sont eux spécifiques à
l’accès (RACS, Ressource Admission Control Subsystem). Par ailleurs, avant de
pouvoir s’attacher à Common IMS, il faut s’attacher à l’accès, et la méthode
d’attachement sera toujours spécifique à l’accès.
126
IMS (4)
Plan de signalisation
Sig RNIS SP SP SP Sig RNIS
Sig analogique ISUP ISUP Sig analogique
Fabric x x Fabric x x Fabric
Plan de commutation
IMS Plan de Contrôle de Session
CSCF CSCF
Signalisation SIP SIP Signalisation SIP
PDN PDN
UE eNodeB MME EPS GW GW EPS MME eNodeB UE
IP
Réseau Réseau IP
Network IP IPX IP Network
Serving Serving
Client GW Plan de Commutation GW
Réseau d’Accès Réseau d’Accès127
Dans le RTC ou le réseau GSM qui sont des réseau voix, le commutateur implémente deux
fonctions : la fonction de commutation qui utilise le transport TDM et la fonction de signalisation
qui utilise le protocole ISUP/SS7 pour l’établissement et la libération d’appel.
ISUP est un protocole de proche en proche entre commutateurs. Un protocole de signalisation
d ’accès est aussi utilisé entre l ’équipement de l ’usager et le commutateur d ’accès. Il peut
s ’agir du protocole de signalisation analogique ou du protocole de signalisation RNIS appelé
Q.931, ou Call Control dans le cas d ’un accès GSM.
Avec l ’IMS, la fonction de signalisation est prise en charge par un serveur d ’appel SIP nommé
CSCF (Call Session Control Function) dont le rôle est de router la signalisation SIP entre
l ’appelant et l ’appelé et éventuellement d ’invoquer des services IMS. SIP est le protocole
utilisé de bout en bout pour l ’établissement/la libération de sessions multimédia. A la différence
du RTC ou GSM, l ’IMS propose un seul protocole, SIP, pour la signalisation à l ’accès et la
signalisation réseau. Avec l ’IMS la fonction de commutation des paquets contenant le trafic de
l ’usager (e.g., la voix) est prise en charge par le routeur.
Dans le RTC , il existe des commutateurs à l ’accès appelés Class 4 Switch et des
commutateurs de transit appelés Class 5 Switch. Dans l ’IMS, il existe des routeurs d ’accès
appelés Edge Routers et des routeurs de transit appelés Core Router.
Les principaux fournisseurs de commutateurs voix sont ALCATEL (E10), Ericsson (AXE),
Siemens (EWSD), Nortel (DMS100), Lucent (5ESS), NEC (Neax 61) et Fujitsu (Fetex 150). Les
principaux fournisseurs de routeurs sont Cisco et Juniper.
L ’usager RTC est relié au premier commutateur d ’accès à travers une liaison analogique ou
RNIS. L ’usager IMS est relié au premier router Edge à travers un accès haut débit tel que
xDSL, câble, WiMAX, LTE, 3G+, EVDO, WiFi, etc.
Les fonctions de l’IMS sont indépendantes de l’accès. Que ce soit l’accès EPS (Evolved Packet
System) ou l’accès xDSL, les réseaux d’accès large bande, sont reliés au réseau IP sur lequel
est connecté le CSCF.
Par ailleurs les réseaux IP des opérateurs sont reliés entre eux par un réseau IP inter-opérateur
appelé IPX (IP Exchange).
127
IMS (5)
RACS0
Client Fiber FTTH
Fiber OLT
SLF AS
ONT Coupler
IP
xDSL Backbone
RACS1 IMS
Client DSLAM BAS SIP BGCF
HSS MGCF
xDSL SIP SIP
PCRF2
MME EPS
UE eNodeB PDN GW Diameter SGW
Serving GW
IP Network S-CSCF ISUP
PCRF3 SIP
UE Node B RNC SGSN 3G GGSN
ATM IP Network MRF
PCRF4 ISUP
MS BTS BSC CDMA2000 HA P-CSCF RTP
IP Network IP Network
MEGACO/
PDSN
PCRF5 H.248
WLAN WLAN PDG
Router
Access Network
RACS6
Client HES IP Backbone
CM CABLE BGF
CMTS
HFC, Hybrid Fiber Coaxial IMS-MGW
MS RACS7 PSTN
BS WiMAX ASN-GW
BGF
PSTN access IPX
128
Analog/ISDN
MSAN
Le CSCF (Call Session Control Function) route le message SIP. Il doit supporter les protocoles SIP et
DIAMETER.
Le PCRF (Policy and Charging Rules Function) met en œuvre la QoS dans le réseau d’action pour
chaque session IMS en fonction des demandes du P-CSCF. Il doit supporter le protocole DIAMETER.
Le HSS (Home Subscriber Server) est le serveur qui contient les profils des usagers IMS. Si plusieurs
HSS sont présents dans un réseau IMS, alors il est nécessaire de disposer d’un SLF (Subscription
Locator Function) ou d ’un proxy agent DIAMETER. Le SLF est un agent de redirection DIAMETER qui
retourne au CSCF l’adresse du HSS disposant du profil d’un usager IMS donné. Le Proxy Agent route la
requête du CSCF directement au HSS approprié. HSS, SLF et Proxy Agent doivent supporter le
protocole DIAMETER.
Les serveurs d'application SIP (SIP AS, Application Server) exécute des services (e.g., Push To Talk,
Présence, Conférence, Instant messaging, IP Centrexetc.) et peuvent influencer le déroulement de la
session à la demande du service. Le serveur d ’application correspond au SCP du Réseau Intelligent.
Le serveur de média SIP (appelé dans les recommandations le MRF pour Multimedia Resource
Function) établit des conférences multimédias, joue des annonces vocales ou multimédia et collecte des
informations utilisateur. Il s’agit de l’évolution de l’entité SRP (Specialized Resource Point) dans le
monde multimédia.
L ’entité CSCF a trois rôles possibles : P-CSCF (Proxy CSCF), I-CSCF (Interrogating CSCF) etS-CSCF
(Serving-CSCF). Le Proxy-CSCF (P-CSCF) est le premier point de contact dans le domaine IMS vu de
l’accès. L'Interrogating-CSCF (I-CSCF) est le point de contact au sein d'un réseau d'opérateur pour
toutes les sessions destinées à un utilisateur de cet opérateur. Le Serving-CSCF (S-CSCF) prend en
charge le contrôle de la session. Il maintient un état de session afin de pouvoir invoquer des services.
Il dispose du profil de service de l’abonné qui lui indique les services souscrits par l’abonné et sous
quelle condition invoquer ces services. Il correspond au SSP de l’architecture Réseau Intelligent.
Les marques de service IMS appelées iFC (initial Filter Criteria) sont fournies par le HSS au S-CSCF via
l’interface Cx (DIAMETER) lors de l’enregistrement de l’usager au réseau IMS
Les marques de service CAMEL appelées CSI (CAMEL Subscription Information) sont fournies par le
HLR au SSP via l’interface C (MAP) lors de l’enregistrement de l’usager au réseau mobile.
Les données de service IMS sont obtenues par l’AS SIP par interrogation du HSS via l’interface Sh
(DIAMETER).
128
IMS (6)
S-CSCF
MGCF
SIP
T-SGW
ISUP/
SIGTRAN
SIP ISUP/SS7
MEGACO
SIP UA
IMS-MGW
Circuit de parole
xDSL IP
Flux RTP
Commutateur
IMS-MGW : IMS Media Gateway RTC
MGCF : Media Gateway Control Function
T-SGW : Trunking Signaling Gateway
S-CSCF : Serving Call Session Control Function
GPRS : General Packet Radio Service
SS7 : Signaling System 7
129
Le domaine IMS doit interfonctionner avec le RTCP/GSM afin de permettre aux

utilisateurs IMS d'établir des appels avec le RTCP/GSM. L'architecture
d'interfonctionnement présente un plan de contrôle (signalisation) et un plan d'usager
(transport). Dans le plan usager, des entités passerelles (IMS-MGW, IMS - Media
Gateway Function) sont requises afin de convertir des flux RTP en flux TDM. Ces
passerelles ne traitent que le média. Des entités sont responsables de créer, maintenir
et libérer des connexions dans ces passerelles; il s'agit de contrôleurs de passerelles
(MGCF, Media Gateway Control Function). Par ailleurs, ce même MGC termine la
signalisation ISUP du côté RTC/GSM qu'il convertit en signalisation SIP qui est délivrée
au domaine IMS. Les messages ISUP provenant du RTC/GSM sont d'abord acheminés
sur SS7 à une entité passerelle de signalisation (T-SGW, Trunking Signaling Gateway)
qui les relaye à l ’entité MGCF sur un transport SIGTRAN.
L'interfonctionnement entre le domaine IMS et le RTC/GSM est donc assuré par trois
entités : L'IMS-MGW (IP Multimedia Subsystem Media Gateway Function), MGCF
(Media Gateway Control Function) et T-SGW (Trunking Signalling Gateway Function).
129
IMS (7)
S-CSCF BGCF
MGCF
SIP
SIP
SIP
MEGACO
MGCF
MEGACO
Réseau IP
Interface RTC RTC

Interface RTP / UDP / IP
130
Lorsque le S-CSCF découvre que la session doit être routée vers le domaine
de commutation de circuit (CS, Circuit Switched Domain) il utilise l’interface Mi
(protocole SIP) afin de relayer la session au BGCF. L’interface Mi est
supportée par le protocole SIP.
L’entité Breakout Gateway Control Function (BGCF) est responsable de la
sélection de la localisation pour l’interfonctionnement avec le domaine CS. Le
résultat du processus de sélection peut être un interfonctionnement dans le
même réseau que celui contenant le BGCF ou un autre réseau auquel cas le
BGCF route le message SIP au BGCF de l’autre réseau.
Si l’interfonctionnement a lieu dans le même réseau, alors l’entité BGCF
sélectionne une entité Media Gateway Control Function (MGCF) qui traitera la
session. Les règles de sélection de l’entité BGCF ne sont pas spécifiées. Par
ailleurs, l’entité BGCF peut rapporter des informations de taxation (MGCF-
CDR) et des statistiques.
130
IMS (8)
SIP (Session Initiation Protocol), IETF RFC 3261 (06/2002).

SIP est un protocole de signalisation utilisé pour
l’établissement, la modification et la libération de sessions
audio/vidéo/data.
SIP s ’appuie sur le protocole SDP (Session Description
Protocol) pour décrire la configuration de la session, RTP pour
le transfert de la voix et de la vidéo, RTCP pour le contrôle des
échanges RTP, et MSRP pour l ’échange de données dans le
contexte de session.
SIP réutilise certains aspects des protocoles HTTP (conception
selon le modèle client/server, adressage par URL, codes de
réponse) et SMTP (headers et transfert ascii).
SIP définit une architecture de service avec les entités
suivantes : Serveur d’Application SIP, Serveur de Media SIP,
Serveur de Messagerie SIP. SMTP : Simple Mail Transport Protocol
HTTP : Hyper Text Transport Protocol
SDP : Session Description Protocol 131
RTP : Real-Time Transport Protocol
SIP est un protocole de signalisation défini par l’IETF (Internet Engineering Task
Force, RFC 3261, Juin 2002) permettant l’établissement, la libération et la
modification de sessions multimédia.
Il hérite de certaines fonctionnalités des protocoles HTTP (Hyper Text Transport
Protocol) utilisé pour naviguer sur le WEB, et SMTP (Simple Mail Transport Protocol)
utilisé pour transmettre des messages électroniques (E-mails).
SIP s’appuie sur un modèle transactionnel client/serveur comme HTTP. L’adressage
utilise le concept d’URL SIP (Uniform Resource Locator) qui ressemble à une adresse
E-mail. Chaque participant dans un réseau SIP est donc adressable par une URL SIP.
Par ailleurs, les requêtes SIP sont acquittées par des réponses identifiées par un code
numérique. D’ailleurs, la plupart des codes de réponses SIP ont été empruntés au
protocole HTTP. Par exemple, lorsque le destinataire n’est pas trouvé, un code de
réponse “ 404 Not Found ” est retourné. Une requête SIP est constituée de headers
comme une commande SMTP. Enfin SIP comme SMTP est un protocole textuel.
131
IMS (9)
REGISTER
UAC 200 OK CSCF
CSCF
HSS
OPTIONS OPTIONS
UAC 200 OK 200 OK UAS
CSCF
INVITE INVITE
180 RINGING 180 RINGING
UAC 200 OK 200 OK UAS
ACK ACK
CSCF
BYE BYE
UAC UAS
200 OK 200 OK
CSCF
CANCEL CANCEL
UAC UAS
200 OK 200 OK
132
La méthode INVITE est utilisée afin d’établir une session entre User agents. INVITE
correspond au message ISUP IAM ou au message Q.931 SETUP et contient les
informations sur l’appelant et l’appelé et sur le type de flux qui seront échangés (voix,
vidéo, etc.).
Lorsque le User agent ayant émis la méthode SIP INVITE reçoit une réponse finale à
l’invitation, il confirme la réception de cette réponse par une méthode ACK. Une
réponse telle que “ busy ” ou “ answer ” est considérée comme finale alors qu’une
réponse telle que “ ringing ” signifiant que l’appelé est alerté, est une réponse
provisoire.
La méthode BYE permet la libération d’une session préalablement établie. Elle
correspond au message RELEASE des protocoles ISUP et Q.931. Un message BYE
peut être émis par l’appelant ou l’appelé.
La méthode REGISTER est utilisée par un User agent afin d’indiquer au Registrar son
adresse IP ainsi que son adresse SIP (SIP URL). Ainsi le Registrar connaît la
localisation de l’utilisateur. Comme dans le cas du Gatekeeper, le User agent peut
connaître par avance son Registrar (adresse IP du Registrar préconfigurée dans le
User agent) auquel cas il émet une méthode REGISTER uniquement à ce Registrar.
Sinon, le User agent émet le message à tous les Registrars en utilisant l’adresse
multicast (224.0.1.175).
La méthode CANCEL est utilisée afin de mettre fin à des requêtes en cours. Si un User
agent s’enregistre auprès de plusieurs terminaux, un message INVITE envoyé à ce
User agent sera dupliqué et relayé à l’ensemble de ces terminaux. Lorsque l’utilisateur
accepte l’appel sur un des terminaux, une méthode CANCEL est émise vers les autres
terminaux afin d’annuler les requêtes INVITE en cours.
La méthode OPTIONS est utilisée afin d’interroger les capacités et l’état d’un User
agent ou d’un serveur. La réponse contient ses capacités (e.g., type de média étant
supporté) ou le fait que le User agent soit indisponible.
132
IMS (10)
Il faut d’abord s’enregistrer
UE P-CSCF I-CSCF HSS S-CSCF
1. Register 2. Register 3. UAR Joue le rôle

SIP 4. UAA de registrar
DIAMETER
5. Register
6. MAR
7. MAA
9. 401 Unauthorized 8. 401 Unauthorized
10. 401 Unauthorized
11. Register 12. Register

13. UAR
Jouent le rôle 14. UAA
de Proxy Server 15. Register
16. SAR
19. 200 OK 17. SAA
21. 200 OK 20. 200 OK 18. Service Control
133
1.Un message SIP REGISTER est émis par l'UE au P-CSCF.

2.Le P-CSCF le relaye à l'entité I-CSCF du réseau nominal de l'usager s'enregistrant. Le réseau nominal peut être
identifié à partir de l'URL SIP de l'usager s'enregistrant ou à partir de son IMSI. Le nom de domaine de l'adresse SIP de
l'UE s'enregistrant peut être résolu par le DNS en une adresse IP d'une entité I-CSCF du domaine IMS nominal. L'entité
I-CSCF joue le rôle de point d'entrée pour les messages de signalisation SIP provenant d'autres réseaux.
3.L'entité I-CSCF interroge le HSS (Home Subscriber Server) à travers l'interface Cx supportée par le protocole
DIAMETER (Requête UAR : User Authorization Request). Le HSS est le HLR avec de nouvelles capacités pour
supporter le domaine IMS. Le HSS est indépendant de l'accès de telle sorte que des opérateurs peuvent réutiliser le
domaine IMS pour d'autres technologies d'accès telles que xDSL (Digital Subscriber Line), le câble ou la boucle locale
radio. Le message UAR émis et contient le nom du domaine nominal, le nom du domaine visité et l'identité de l'UE.
4.Le HSS retourne les informations d ’autorisation de l'usager et les capacités du S-CSCF à sélectionner par le I-CSCF
(Réponse UAA : User Authorization Answer). Ces informations serviront d'entrées à sa fonction de sélection d'un S-
CSCF.
5. L ’I-CSCF vérifie si l ’usager est autorisé à s'enregistrer à partir du réseau visité et dans le cas postif, L'I-CSCF relaye
la méthode SIP REGISTER au S-CSCF approprié. L'entité S-CSCF a plus de fonctionnalités que les P-CSCF et I-
CSCF. L'opérateur peut disposer de plusieurs S-CSCFs avec des capacité différentes et sélectionner celui approprié
pour rendre le service demandé.
6. L ’entité S-CSCF demande des données d ’authentification du client au HSS (MAR : Multimedia authentication
request)
7. Le HSS retourne les données d’authentification par une réponse MAA (Multimedia authentication answer) au S-
CSCF.
8.9. 10. L’entité S-CSCF retourne à l”usager une réponse négative d’enregistrmeent contenant une valeur random à
utiliser par sa carte SIM pour calculer un résultat d’authentification.
11. L ’usager renvoie une demande d ’enregistrement au P-CSCF.
12. Le P-CSCF route le message REGISTER à un S-CSCF du domaine nominal de l ’usager.
13. et 14. Idem 3 et 4.
15. Le message REGISTER est routé de l ’I-CSCF au S-CSCF.
16. L'entité S-CSCF après avoir vérifié les informations d ’authentification de l ’usager, émet une requête SAR (Server
Assignment Request) au HSS afin que ce dernier mette à jour le profil de l'usager avec le nom du S-SCSF qui le sert.
17.Le HSS retourne une réponse SAA (Server Assignment Answer à l'entité S-CSCF, contenant le profil de l'usager. Ce
profil consiste en les informations de souscription par l'usager à des services, appelées ASSI (Application Server
Subscription Information). Le S-CSCF doit par ailleurs stocker le nom / l'adresse du P-CSCF courant de l'usager afin de
lui délivrer directement des demandes d'établissement de session entrantes concernant cet usager.
18. Le S-CSCF invoque des services éventuels tels que le service de Présence.
19., 20. et 21. Une réponse 200 OK est retournée par le S-CSCF à l'entité I-CSCF qui la relaye au P-CSCF puis à l ’UE.
133
IMS (11)
Avec une identité IMS
IMS
Subscription IMPI, e.g.,
208019999999999@orange.fr
IMPU Public user identity-2
Private user tel : +336 72 22 55 55
Service
identity-1 IMPU Public user identity-1 profile-1
sip:JohnCook@orange.fr
Au moment de la souscription, Le serveur ENUM d ’orange.fr doit être

mis à jour avec la correspondance :
(+336 72 22 55 55 sip:JohnCook@orange.fr)
134
IMPU : IMS Public User Identity

Les requêtes et réponses SIP contiennent des adresses émission et destination SIP. Ces adresses SIP sont des
URLs SIP (Uniform Resource Locator) et ont une forme similaire à une adresse e-mail c’est à dire user@host.
Toutefois, une adresse e-mail utilise une URL mailto (mailto :mark.rich@orange.fr) alors qu’une adresse SIP a la
forme d’une URL SIP (sip :mark.rich@orange.Fr).
• La partie user est identifiée soit par un nom, soit par un numéro de téléphone.
• La partie host est représentée soit un par nom de domaine, soit par une adresse de réseau.
L’utilisation des numéros de téléphone est aussi considérée, notamment pour la réutilisation du plan de numérotage
du réseau téléphonique commuté (RTC) et pour l’interfonctionnement entre SIP et RTC. Lorsqu ’un appelant du
RTC ou du réseau GSM veut appeler un destinataire sur le réseau SIP/IMS, il n ’a pas d ’autre solution que de
composer un numéro de téléphone. Ce numéro qui appartient au plan de numérotage de SIP/IMS sera traduit par
ENUM/DNS en adresse SIP. ENUM contient pour tout numero de telephone d ’un client SIP une adresse
téléphonique associée à une adresse SIP. Il ne peut pas y avoir d ’adresse téléphonique assignée (tel:) sans
adresse SIP associée.
Donc dans le monde SIP, l ’usager SIP/IMS devra disposer d ’une adresse SIP et d ’une adresse téléphonique (e.g.,
tel:+33672333333). Ses appels lui seront acheminés exclusivement avec son adresse SIP (e.g., sip: x.y@orange.fr).
IMPI : IMS Private User Identity
L’identité privée d’usager IMS (IMS Private User Identity, IMPI) est une identité globale unique définie par le réseau
nominal qui peut être utilisée dans le réseau nominal afin d’identifier de manière unique une souscription. Cette
identité est principalement utilisée afin d’authentifier l’usager. Elle sert aussi aux procédures administratives et aux
procédures de taxation. L’architecture IMS impose les caractéristiques suivantes pour l’identité privée IMS :
• L’IMPI a un format Network Access Identifier (NAI).
• L’IMPI sera contenu dans dans les demandes d’enregistrement passées de l’UE au réseau nominal.
• L’IMPI sera authentifiée uniquement lors de l’enregistrement de l’usager.
• L’IMPI ne sera pas utilisée pour le routage des messages SIP.
• L’IMPI sera alloué à l’usager de manière permanente. Elle sera valide pour la durée de souscription dans le réseau
nominal.
• Il ne sera pas possible pour l’UE modifier l’IMPI.
• Le HSS devra stocker l’IMPI..
• L’IMPI pourra être présent dans les tickets de taxation en fonction de la politique opérateur.
134
IMS (12)
Avant de créer des sessions
Proxy Server
francetelecom.com
sip:mary.taylor@francetelecom.com sip:mark.rich@francetelecom.com
SIP UA 1 SIP UA 2
v = 0 (dans message 1) 1. INVITE 2. INVITE

c = IN IP4 192.23.34.45
m = audio 45450 RTP/AVP 0, 4, 15
4. 180 RINGING 3. 180 RINGING
6. 200 OK 5. 200 OK v=0 (dans message 5)
c = IN IP4 192.190.130.38
7. ACK 8. ACK
m = audio 22222 RTP/AVP 0
Flux de média RTP
v=version
c=connection
9. BYE 10. BYE
m=media
12. 200 OK 11. 200 OK
135
Dans l’exemple suivant, l'appelant a pour URL SIP sip:mary.taylor@francetelecom.com,

alors que celle de l'appelé est sip:mart.rich@francetelecom.com.
Un message d'établissement d'appel SIP INVITE est émis par le terminal IMS de l'appelant
au Proxy Server. Ce dernier interroge le HSS pour identifier la localisation de l'appelé
(adresse IP) et achemine l'appel à la destination. Le message INVITE contient différents
headers obligatoires dont l'adresse SIP de l'appelant "From", l'adresse SIP de l'appelé "To",
un identifiant d'appel "Call-ID", un numéro de séquence "Cseq".
Par ailleurs, le message SIP contient une syntaxe SDP (Session Description Protocol). Cette
structure consiste en plusieurs lignes qui décrivent les caractéristiques du média que
l’appelant “ Mary ” requiert pour l’appel.
Mary Taylor indique qu'il s'agit d'une session téléphonique (m=audio), que la voix paquétisée
doit lui être délivrée à l'adresse de transport (port UDP = 45450, adresse IP = 192.23.34.45)
avec le protocole RTP et en utilisant un format d'encodage défini dans le RFC AVP (Audio
Video Profile) et pouvant être G.711 m-law (0), G.729 (4) et G.728 (15).
La réponse 180 RINGING est retournée par le destinataire au terminal IMS de l ’appelant.
Lorsque l'appelé accepte la session, la réponse 200 OK est émise par son terminal IMS et
acheminée au terminal IMS de l ’ appelant.
Le terminal IMS de l ’appelant retourne une méthode ACK au destinataire, relayée par l'entité
CSCF.
L'entité Proxy Server participe à l'acheminement de la signalisation entre UAs alors que les
UAs établissent directement des canaux RTP pour le transport de la voix ou de la vidéo
paquétisée sans implication du Proxy Server dans ce transport.
Lorsque Mary raccroche, son terminal IMS envoie une requête BYE pour terminer la session.
Cette requête est délivrée au Proxy Server qui l'achemine au terminal IMS de Mark. Ce
dernier retourne la réponse 200 OK suivante.
135
IMS (13)
Service Control
HSS
Sh Sh
Sh Sh Sh Sh Sh
Multimedia
Telephony
Presence GLMS PoC Messaging Conferencing SCC
(TAS)
ISC
+ Hosted Enterprise Services (IP Centrex)
+ Video sharing (Combinational services) S-CSCF
+ IP TV
Broadband Access to IMS IP 2G/3G/4G Access to IMS

WLAN Access to IMS
PacketCable™ WiMAX
DSL DOCSIS Forum
Forum
Residential Enterprise Mobile 136
L’IMS définit un ensemble de capacités de service :

• La capacité de service Multimedia Telephony permet des communications conversationnelles entre deux
ou plusieurs participants. Cette capacité inclut les services complémentaires comparables à ceux fournis par
le domaine circuit tels que le renvoi d’appel, le signal d’appel, la mise en garde, le rappel automatique sur
occupation, etc.
• La capacité de service Presence permet à un usager de souscrire à l’état de présence un contact et d’être
notifié à chaque changement d’état de ce contact.
• La capacité de service Push-to-talk over Cellular (PoC, Push To Talk over Cellular) consiste à utiliser son
téléphone comme un talkie-walkie, simplement en poussant un bouton pour dialoguer les uns avec les autres.
La technologie se veut l'équivalent voix du SMS. Le service PoC permet la transmission de messages vocaux
entre utilisateurs mobiles sur réseaux de données. L'utilisateur sélectionne un ou plusieurs correspondants
dans son carnet d'adresses, puis presse un bouton sur son terminal pour enregistrer son message vocal. Le
message est ensuite encodé puis transmis par paquet RTP/UDP/IP via le réseau d’accès large bande mobile.
La transmission de messages par ce biais introduit un délai de latence qui n'autorise pas, en théorie, des
échanges vocaux en "quasi-temps réel", mais qui, en pratique, pourrait voir le service PoC utilisé plutôt pour
des services de type "messagerie instantanée vocale".
• La capacité de service Conference fonctionne selon deux modes:
- Le mode Ad-hoc qui permet de créer des conférences à la demande. Il s’agit de conférences non
planifiées et de courte durée.
- Le mode pre-arranged (Plannifié) qui permet de créer des conférence à l’avance en utilisant le protocole
Conference Policy Control Protocol (CPCP). Il spécifie un schéma XML qui énumère les éléments
d ’information de politique de conférence permettant à l ’usager de définir sa politique de conférence.
• La capacité de service Messaging fonctionne selon deux modes :
- Pager-mode messaging : Des messages SIP contenant les données à échanger son routés de manière
asynchrone entre l’émetteur et le récepteur.
- Session-mode messaging : Une session IMS est établie pour la session de donnée (de type Tchat). Le
protocole MSRP est alors utilisé pour transporter les données entre usagers et non pas le protocole SIP.
• Les capacités de service Hosted Enterprise Services (IP Centrex), IP TV (Mode broadcast et mode video
à la demande), video sharing, on aussi été récemment définies.
136
IMS (14)
HSS
C (MAP)
SMSC
E (MAP)
IP-SM-GW Sh (Diameter) On peut même passer

Application ses SMS via IMS
ISC (SIP)
Cx (Diameter)
S-CSCF
SIP
UE
137
L’équipement IP-SM-GW va faciliter l’interopérabilité entre le UE-IMS et le SMSC.

Le SMS est soit produit par le UE remis au SMSC pour ensuite trouver le UE
destinataire (SMS sortant) ou bien est reçu par le SMSC et doit être délivré au UE-
IMS (SMS entrant).
L’ IP-SM-GW doit:
• déterminer le domaine (CS/PS ou IMS) à utiliser pour délivrer le SMS
• être connecté au SMSC et utiliser MAP (en ce sens il est vu comme un MSC
du SMSC);
• être connecté au HSS via MAP pour connaitre la destination finale du SMS
reçu: CS/PS ou IMS et connaitre les paramètres associés: @ MSC/SGSN si
CS/PS, @S-CSCF si IMS.
• vérifier la cohérence identitaire (@IP, TEL URI) des messages transitant par
lui
• opérer la transformation protocolaire MAP/SIP pour les SMS entrants et
sortants
• se comporter comme un Application Server vu du monde IMS
137
Evolution S1-Flex
3G SGSN
IuPS Connectivité 1-à-n
RNC RNC RNC RNC

RNC
Service Provider 1 Service Provider 2
MME1 MME2 MME3 MME4

Serving GWs Serving GWs Serving GWs Serving GWs
S1
S1-Flexibility
Les eNodeBs appartiennent à

Pool Area 1 Service Provider 1 considéré comme
fournisseur d ’accès LTE.
eNodeB eNodeB eNodeB eNodeB eNodeB
138
Dans les réseaux mobiles 2G et 3G, la connectivité entre le réseau cœur et le

réseau d’accès était définie comme hiérarchique : un nœud du réseau cœur
(soit le MSC dans le domaine circuit, soit le SGSN dans le domaine paquet)
sert un ensemble de contrôleurs d’antennes (BSC 2G ou RNC 3G), et un
contrôleur donné ne peut s’interfacer qu’à un nœud MSC et un nœud SGSN.
Depuis la Release 5 des spécifications 3GPP, une nouvelle fonctionnalité a été
introduite permettant plus de flexibilité dans l’interconnexion entre les nœuds
d’accès et les nœuds du réseau cœur, cassant la hiérarchie traditionnelle dans
le réseau mobile.
Cette fonctionnalité appelée Iu-flex dans les réseaux 3G a été introduite dès le
début dans les recommandations LTE et est appelée S1-flex.
Iu-flex permet à un RNC de s ’interfacer à plusieurs MSC et plusieurs SGSN à
la fois. S1-flex permet à un eNodeB de s ’interfacer à plusieurs MME/Serving
GW à la fois appartenant ou non au même opérateurs. S ’il appartiennent au
même opérateur, alors le but recherché est la redondance. S ’ils appartiennent
à des opérateurs différents, alors l ’objectif est le RAN sharing.
138
4.2 Principales Procédures
139
139
Attachement initial E-UTRAN (1)
UE SGW PGW
New EIR HSS
PCRF
eNodeB MME
1. Attach Request (PDN Connectivity Request)
2. Authentication Information Request

2. Authentication Information Answer
3. Authentication Request
3. Authentication Response Authentification
4. Identity request
4. Identity response 5. Check IMEI Request
5. Check IMEI Answer

Vérification d ’IMEI
6. Update Location Request

EMM
Diameter 6. Update Location Answer (Profil usager EPS)
GTPv2-C
S1-AP Mise à jour de localisation
RRC
140
L'UE souhaite s'enregistrer au réseau EPS. Cette procédure correspond à un attachement au

réseau EPS qui conduira à la création d'un default bearer permanent correspondant à une
connectivité permanente IP.
1. L'UE initie la procédure d'attachement en émettant une requête Attach à l'eNodeB
fournissant son GUTI. D'après le GUTI, l'eNodeB est capable d'identifier l'opérateur avec lequel
l'UE souhaite s'attacher. L'eNodeB sélectionne ensuite le MME de cet opérateur en relation
avec l'EnodeB et lui relaie la requete Attach à l'aide de l'interface S1-C.
2. Le MME obtient du HSS disposant du profil de l'UE, des vecteurs d'authentification à l'aide
de la requête Send Authentication Info.
3. Le MME soumet une valeur aléatoire à l'UE et escompte une réponse de l'UE contenant un
résultat d'authentification égal à celui fourni par le HSS. L'UE retourne la réponse au MME.
4. Le MME demande à l'UE de lui fournir son IMEI.
5. L 'EIR, interrogé par le MME indique dans le message de retour si le terminal fait ou ne fait
pas partie de la liste des équipements interdits (black list).
6a. Le MME délivre un message Update Location (adresse MME sous forme de hostname,
IMSI) au HSS.
6b. Le HSS acquitte la mise à jour de localisation par une réponse Update Location Ack au
MME qui contient les données de souscription de l ’UE incluant la liste de tous les APNs que
l'UE est en droit d'accéder, une indication sur l'APN par défaut, et les paramètres de QoS
associés à chaque APN. Si le HSS rejette a procédure de mise à jour de localisation, alors le
MME rejette la demande d'attachement de l'UE.
140
Attachement initial E-UTRAN (2)
UE eNodeB New Old MME/ SGW PGW
EIR HSS
SGSN PCRF
MME
7. GTPv2C Create Session Request 8. GTPv2C Create Session Request (APN, QoS)
(APN = internet.orange.fr, QoS, PGW’s IP address) 9a. Gx. CCR
10. GTPv2C Create Session Response 9b. Gx. CCA

(APN = internet.orange.fr, QoS, UE’s IP address)
11. GTPv2C Create Session Response (APN = internet.orange.fr, QoS, UE’s IP address)
12. S1-AP Initial Context Setup Request

(EMM Attach Accept (APN = internet.orange.fr, QoS, UE’s IP address, GUTI, TAI List))
13. RRC Connection Reconfiguration Request (EMM Attach Accept
(APN = internet.orange.fr, QoS, UE’s IP address, GUTI, TAI List)) EMM
14. RRC Connection Reconfiguration Complete (EMM Attach complete) Diameter
GTPv2-C
15. S1-AP Initial Context Setup Response (EMM Attach Complete)
S1-AP
First uplink data RRC
16. GTPv2C Modify Bearer Request
17. GTPv2C Modify Bearer Response

First downlink data
18. S6a Notify Request

19. S6a Notify Answer
141
7. Le MME sélectionne un Serving GW et assigne une valeur au paramètre EPS Bearer Identity (BI) pour le
bearer par défaut associé à cet UE. Puis, il émet une requête Create Session Request (pour la création du
default bearer) au serving GW sélectionné.
8. Le serving GW crée une nouvelle entrée dans sa table d'EPS bearer et émet à son tour une requête Create
Session Request au PDN Gateway en utilisant le protocole GTP-C. Ce bearer permet à l'UE d'accéder à
Internet par exemple.
9. Le PDN GW interagit avec l'entité PCRF afin d'obtenir les règles de taxation permettant de différencier les
flux de service qui transiteront par le default bearer et ainsi différencier la taxation de ces flux.
10. Le PDN GW retourne une réponse Create Session Response au Serving GW contenant l'adresse IP
allouée par le PDN GW à l'UE.
11. Le Serving GW retourne une réponse Create Session Response au MME.
12. Le MME émet un message de contrôle sur l'interface S1-C à l'eNodeB, appelé Initial Context Setup
Request, afin de demander à l'eNodeB de créer un bearer d'accès entre l'UE et le Serving GW. Ce message
inclut la QoS requise pour ce bearer, l'identité du bearer EPS (BI), ainsi que l'adresse du Serving GW pour la
livraison des flux média au serving GW.
13. L'eNodeB émet un message RRC Connection Reconfiguration request incluant l'identité du bearer d'accès
et le message Attach Accept contenant le GUTI assigné à l'UE.
14. l'UE retourne une réponse RRC Connection Reconfiguration Complete à l'eNodeB incluant le message
EMM Attach Complete.
15. L'eNodeB retourne le message Initial Context Response au MME incluant l'identité du bearer EPS,
l'adresse de l'eNodeB à utiliser pour le trafic descendant du Serving GW à l'eNodeB sur l'interface S1-U. L'UE
peut dès à présent émettre des paquets IP dans le sens montant vers l'eNodeB qui les routera sur le tunnel
GTP-U au Serving GW qui à son tour les relayera aussi sur un tunnel GTP-U au PDN GW.
16. A la réception du message Initial Context Response et de l'Attach Complete, l'entité MME émet une
requête Modify Bearer Request (Identité du bearer EPS (BI), adresse eNodeB) au Serving GW.
17. Le Serving GW l'acquitte en retournant une réponse Modify Bearer Response (Identité du bearer EPS) au
MME. Le Serving GW est dès à présent prêt à relayer les paquets IP qu'il a pu mettre temporairement en
mémoire tampon dans le sens descendant à travers l'eNodeB à destination de l'UE.
18. et 19. Si le PDN GW choisi par le MME n ’est pas celui proposé dans le profil de l ’usager, l ’UE doit
notifier l ’identité de ce PDN GW au HSS.
141
Quelques mots sur la sécurité
142
Derrière l’étape d’authentification se cache deux besoins principaux:
• l’authentification qui est mutuelle et qui nécessite l’usage de 2

algorithmes et d’une clé secrète.
• la génération des clés de sécurité utiles au futur chiffrement du

trafic (entre eNodeB et UE), de la signalisation RRC (entre eNodeB
et UE) et de la signalisation NAS (entre MME et UE) mais aussi à
l’intégrité à apporter aux flux RRC et NAS.
142
Mise à jour de Tracking Area
PGW
HSS
Update
Location
User context New

Old
Old transfer New SGW
SGW
MME MME
Old Tracking Area (TA) New Tracking Area (TA)
143
La Figure ci-dessus décrit un exemple de mise à jour de Tracking Area (TAU,

Tracking Area Update). Dans le cas présenté, l’UE change de MME et de Serving
GW. Les opérations suivantes doivent être réalisées lors de la procédure TAU:
• Mise à jour du chemin média : Le default bearer doit être mis à jour ainsi que tout
bearer supplémentaire (defaut et dedicated) établi une fois l’UE attaché au réseau.
Le PDN GW doit être informé du nouveau Serving GW en charge de la nouvelle
Tracking Area (TA), et un nouveau bearer doit être créé entre l’UE et le nouveau
Serving GW si l’UE est dans l’état actif.
• Transfert du contexte usager de l’ancien MME au nouveau MME.
• Mise à jour du profil de l’usager dans le HSS notamment avec l’adresse du
nouveau MME.
143
Mise à jour de Tracking Area avec
changement de MME et de Serving GW
UE eNodeB New SGW Old SGW PGW
New Old HSS
MME MME
1. EMM TAU
Request 2. EMM TAU Request (Old GUTI)
(Old GUTI) 3. GTPv2C Context Request (old GUTI)
4. GTPv2C Context Response (IMSI, Unused EPS Authentication Vectors)

5. Authentication
6. GTPv2C Context Acknowledge (Serving GW change notification)
7. GTPv2C Create Session Request8. GTPv2C Modify Bearer Request
10. GTPv2C Create Session Response 9. GTPv2C Modify Bearer Response
DIAMETER 11. S6a. Update Location Request
GTPv2-C 12. S6a. Cancel Location Request
EMM 13. S6a. Cancel Location Response
TAU : Tracking area Update
14. S6a. Update Location Response
17. TAU Accept 15. GTPv2C Delete Session Request
18. TAU Complete 16. GTPv2C Delete Session Response
144
1. L'UE détecte qu'elle entre dans une nouvelle Tracking Area (TA) en se rendant compte que l'identité de sa TA courante n'est pas
présente dans la liste des TA prises en charge par son MME. Rappelons qu'au moment de l'attachement de l'UE, le MME lui a indiqué la
liste des TA sous la responsabilité de ce MME. Tant que l'UE est présent dans un de ces TAs, il n'est pas nécessaire de mettre à jour la
TA. L'UE initie la procédure TAU (Tracking Area Update) par l'envoi à l'eNodeB du message TAU request avec l'indication de l'opérateur
sélectionné. Le GUTI doit être inclus.
2. L'eNodeB dérive le MME auquel router la requête TAU request à partir du GUTI et du réseau sélectionné. Le message TAU request
est passé par l'eNodeB au MME.
3. Le nouveau MME émet une requête GTP-C Context request (GUTI) à l'ancien MME afin d'obtenir des informations d'usager.
4. L'ancien MME retourne la réponse GTP-C Context Response. L'adresse du PDN GW et les TEID(s) des bearers établis par l'UE sont
inclus dans la réponse.
5. L'authentification s'applique à l'UE.
6. Le nouveau MME émet un acquittement GTP-C Context Acknowledge à l'ancien MME.
7. Le MME détermine s'il faut sélectionner un nouveau Serving GW par exemple dans le cas où le chemin entre l'UE à un nouveau
Serving GW serait plus court. Si tel est le cas, le MME émet la requête Create Session Request (IMSI, bearer contexts, MME Context
ID) au nouveau Serving GW sélectionné. L'adresse du PDN GW est indiquée dans les "bearer contexts".
8. Le nouveau Serving GW émet le message GTP-C Modify Bearer Request (Serving GW Address, Tunnel Endpoint Identifier) au PDN
GW concerné. Rappelons que le PDN GW ne peut pas changer même s'il est possible de changer de Serving GW, car c'est le PDN GW
qui a alloué l'adresse IP à l'UE. Les flux entrants passent forcément par ce PDN GW qui représente le point d'entrée du monde mobile
pour les réseaux IP externes.
9. Le PDN GW met à jour ses "bearer contexts" et retourne une réponse Modify Bearer Response (adresse PDN et TEID(s)).
10. Le Serving GW retourne une réponse Create Session Response (MME Context ID, adresse Serving GW, TEID pour le plan usager,
Serving GW Context ID) au nouveau MME.
11. Le nouveau MME émet une requête Update Location (MME Identity, IMSI) au HSS.
12. Le HSS émet la requête Cancel Location à l'ancien MME pour lui demander de supprimer le profil de l'usager.
13. L'ancien MME acquitte cette requête avec une réponse Cancel Location Ack (IMSI).
14. Le HSS acquitte la requête Update Location en émettant la réponse Update Location Ack au nouveau MME.
15. Lorsque l'ancien MME supprime le contexte associé à l'UE, il libère toutes les ressources allouées aux bearers EPS de l'UE en
envoyant le message Delete Bearer Request (TEID) au Serving GW.
16. Le Serving GW acquitte ce message avec la réponse Delete Bearer Response (TEID).
17. Le nouveau MME valide la présence de l'UE dans la TA après avoir reçu les informations de souscription de l'usager et envoie à l'UE
le message TAU Accept qui peut contenir une nouvelle identité temporaire pour l'UE appelée GUTI.
18. Si une nouvelle identité temporaire est incluse dans le message TAU Accept, l'UE acquitte le message reçu en retournant le
message TAU Complete au MME.
144
Default et dedicated bearers
Serving GW1 PDN GW1 ISP X

UE Same PDP (IP) address and APN
Dedicated bearer (APN X, IP address X, QoS2)
APN X
Default Bearer (APN X, IP address X, QoS1)
ISP Y
PDN GW2
Dedicated bearer (APN Y, IP address Y, QoS3)
APN Y
Dedicated bearer (APN Y, IP address Y, QoS2)
Default bearer (APN Y, IP address Y, QoS1)
ISP Z
145
Afin d’accéder aux services EPS, l’UE doit disposer de bearer. Un default bearer qui est permanent par
nature est établi par le réseau EPS dès l’attachement de l’UE à ce réseau. Ce bearer EPS est maintenu
pour toute la durée d’attachement de l’UE afin de fournir à l’UE une connectivité IP permanente à un
réseau IPv4 ou IPv6. Il correspond au concept de contexte PDP établi dans un réseau GPRS. A tout
moment l’UE peut établir un ou plusieurs default bearers additionnels. Seul l’UE peut initier la demande
d’établissement d’un default bearer additionnel.
L’UE obtient une adresse IP par default bearer établi. Les default bearer ne fournissent pas de débit
garanti.
Afin que l’usager puisse accéder à des services temps réel IP tels que la téléphonie sur IP, il est
nécessaire qu’un dédicated bearer soit établi ; un dedicated bearer a une durée limitée et fournit un débit
garanti, et est toujours associé à un default bearer. Le default bearer et tous les dedicated bearer
associés partagent la même adresse IP. Le réseau ou l’UE peuvent initier l’établissement d’un dedicated
bearer.
Le MME crée pour le compte de l ’usager un default bearer au moment du rattachement au réseau.
Supposons qu ’il s ’agisse du default bearer utilisé pour l ’accès au PDN (Packet Data Network) Internet.
Ce Default bearer est maintenu tant que l ’usager est rattaché au réseau mobile. L ’APN correspondante
est présente dans le profil de l ’usager qui est fourni par le HSS au MME
Si l ’usager nécessite d ’accèder à un autre PDN (e.g., réseau IP supportant l ’IMS), alors son terminal
devra établir un default bearer additionnel en utilisant une autre APN. Ce default bearer additionnel est
maintenu tant que l ’usager a besoin d ’accéder au PDN correspondant.
Pour chaque APN, une adresse IP est fournie par le PDN GW au mobile.
Si l ’usager émet un message SIP sur son default bearer IMS au P-CSCF (call server de l ’IMS), ce
dernier demande au PDN GW via le PCRF de réserver un dedicated bearer. Ce dedicated bearer est
caractérisé par une QoS compatible par rapport au trafic à transporter. Le dedicated bearer a une durée
de vie qui correspond à celle de la session pour laquelle il a été établi (e.g., session de voix sur IP).
Un dedicated bearer est toujours associé à un default bearer. Il partage la même adresse IP que le
default bearer, mais une QoS qui peut être la même ou différente. Plusieurs dedicated bearers peuvent
être associés au même default bearer.
145
Activation d’un default bearer par l’UE
UE SGW PGW
New HSS
eNodeB PCEF PCRF
MME
1. ESM PDN Connectivity Request
2. Create Session Request 3. Create Session Request
4a. Gx. CCR
4b. Gx. CCA
6. Create Session Response 5. Create Session Response
7. S1-AP Bearer Setup Request (ESM PDN Connectivity Accept)
8. RRC Connection Reconfiguration Request (ESM Activate default EPS bearer context request)
9. RRC Connection Reconfiguration Complete (ESM Activate default EPS bearer context accept)
10. S1-AP Bearer Setup Response
First Uplink Data

11. Modify Bearer Request ESM
GTPv2-C
12. Modify Bearer Response S1-AP
First Downlink Data RRC
146
La procédure “ UE requested PDN connectivity ” permet à l’UE de demander l’établissement d’un bearer EPS par défaut (default bearer)
vers un réseau de données externe IPv4 ou IPv6. Ce default bearer vient en supplément de celui établi lors de l’attachement de l’UE au
réseau EPS. L’UE dispose alors de plusieurs default bearers et obtient pour chacun de ces bearers, une adresse IP. L’UE émet le
message PDN CONNECTIVITY REQUEST au MME pour la création du default bearer. Ce message doit inclure l’Access Point Name
(APN) et la procédure transaction identity (PTI).
A la réception de ce message l’entité MME vérifie si la connectivité avec l’APN demandée est possible d’après le profil de l’usager. Si tel
est le cas, l’entité MME initie l’établissement de ce defaut bearer et retourne une réponse PDN CONNECTIVITY ACCEPT. Si la
demande n’est pas acceptée, l’entité MME retourne PDN CONNECTIVITY REJECT.
A titre d’exemple, le premier default bearer établi au moment de l’attachement de l’UE permet l’accès à Internet alors que le second
permet l’accès à l’Intranet d’entreprise ou au réseau et aux services IMS.
La figure ci-dessus décrit la procédure de bout en bout d’établissement d’un default bearer additionnel.
1. L'UE initie la procédure d'établissement d'un default bearer additionnel à l'aide de la requête "PDN Connectivity Request" envoyée au
MME.
2. Le MME vérifie que l'APN fournie par l'UE dans sa requête est authorisée selon le profil d'usager. Si tel est le cas, le MME sélectionne
un Serving GW et assigne une valeur au paramètre EPS Bearer Identity (BI) pour le default bearer additionnel associé à cet UE. Puis, il
émet une requête Create Session Request (pour la création de ce nouveau default bearer) au serving GW sélectionné.
3. Le serving GW crée une nouvelle entrée dans sa table d'EPS bearer et émet à son tour une requête Create Session Request au PDN
Gateway.
4. Le PDN GW interagit avec l'entité PCRF afin d'obtenir les règles de taxation permettant de différencier les flux de service qui
transiteront par ce default bearer et ainsi différencier la taxation de ces flux.
5. Le PDN GW retourne une réponse Create Session Response au Serving GW contenant l'adresse IP allouée par le PDN GW à l'UE.
6. Le Serving GW retourne une réponse Create Session Response au MME.
7. Le MME émet un message de contrôle sur l'interface S1-C à l'eNodeB, appelé Bearer Setup Request, afin de demander à l'eNodeB
de créer un bearer d'accès entre l'UE et le Serving GW associé à ce nouveau default bearer. Ce message inclut la QoS requise pour ce
bearer, l'identité du bearer EPS (BI), ainsi que l'adresse du Serving GW pour la livraison des flux média au Serving GW.
8. L'eNodeB émet un message RRC Connection Reconfiguration request incluant l'identité du bearer d'accès et un message ESM PDN
Connectivity Accept.
9. l'UE retourne une réponse RRC Connection Reconfiguration Complete à l'eNodeB.
10. L'eNodeB retourne le message S1-C Bearer Context Response au MME incluant l'identité du bearer EPS, l'adresse de l'eNodeB à
utiliser pour le trafic descendant du Serving GW à l'eNodeB sur l'interface S1-U. L'UE peut dès à présent émettre des paquets IP dans le
sens montant vers l'eNodeB qui les routera sur le tunnel GTP-U au Serving GW qui à son tour les relayera aussi sur un tunnel GTP-U au
PDN GW.
11. A la réception du message Bearer Context Response, l'entité MME émet une requête Modify Bearer Request (Identité du bearer
EPS (BI), adresse eNodeB) au Serving GW.
12. Le Serving GW l'acquitte en retournant une réponse Modify Bearer Response (Identité du bearer EPS) au MME. Le Serving GW est
dès à présent prêt à relayer les paquets IP, qu'il a pu mettre temporairement en mémoire tampon, dans le sens descendant à l'UE à
travers l'eNodeB.
146
Activation d’un bearer dédié par le
PDN GW suite à une demande de l’IMS
IMS
PCRF : Policy and Charging Resource Function P-CSCF
Rx et Gx sont des applications DIAMETER

Rx 1
2
SIP/SDP (Contrôle de session)

Signalisation d’accès PCRF
(ESM, S1-AP et GTPv2C)
DIAMETER (Policy Control) Routeur
Gx
3 Backbone IP
UE Réseau d ’accès large bande EPS
4 PCEF
1. Signalisation SIP
2. Signalisation Rx
PDN GW 3. Signalisation Gx (policy control)
4. Signalisation d ’accès 147
L’établissement et la modification de session dans l’IMS implique un échange de

messages SIP/SDP de bout en bout. Pendant l’échangé, le terminal négocie un
ensemble de caractéristiques média (e.g., les codecs). Le P-CSCF à travers son PCRF
(Policy & Charging Rules Function) autorise les flux IP des composants média choisis
par le terminal en réalisant une translation des paramètres de la description SDP en des
paramètres de QoS IP. Ces paramètres de QoS IP sont ensuite passés par le PCRF au
PCEF par le biais de l’interface Gx basée sur le protocole DIAMETER.
Lorsque le terminal IMS émet une requête SIP INVITE au P-CSCF, ce dernier émet une
requête Rx AAR au PCRF. Le PCRF la traduit en une requête Gx RAR et l’achemine au
PCEF. Cette requête indique au PCEF de réserver des ressources dédiées (dedicated
bearer) entre le PDN GW et l ’UE VoLTE avec la QoS appropriée (QCI = 1 pour un appel
voix).
147
Activation d’un bearer dédié par le PDN GW
UE eNodeB
SGW PGW P-CSCF
S1 S11 S5 PCEF Gx Rx
MME PCRF
SIP INVITE (sdp1)

183 Session Progress (sdp2)
1. Rx AAR (sdp1, sdp2)
2. Gx RAR (QCI, ARP, MBR, GBR, Flow information)
3. GTPv2C Create Bearer Request (QCI, ARP, MBR, GBR, TFT)
4. GTPv2C Create Bearer Request (QCI, ARP, MBR, GBR, TFT)

GTPv2-C
5. S1-AP Bearer Setup Request (QCI, ARP, MBR, GBR, TFT) S1-AP
RRC
Rx, Gx
6. RRC Connection Reconfiguration Request ()
SIP
7. RRC Connection Reconfiguration Response ()
8. S1-AP Bearer Setup Response ()
9. GTPv2C Create Bearer Response
10. GTPv2C Create Bearer Response
11. Gx RAA
12. Rx AAA
148
Un usager initie une session téléphonique IMS en émettant une requête SIP INVITE (sdp1) à son P-CSCF. L ’adresse
du P-CSCF a été fournie par le PDN GW lorsque l ’usager a ouvert un default bearer dédié à la signalisation SIP IMS.
La demande INVITE (sdp1) est routée par l ’IMS à l ’appelé.
Lorsque le terminal de l ’appelé reçoit cette requête INVITE (sdp1), le terminal ne se met pas à sonner et retourne une
réponse 183 Session Progress (sdp2) pour bien indiquer que la demande de l ’appelant est prise en compte. Le terminal
ne pourra se mettre à sonner que lorsque les ressources dans les réseaux d ’accès de l ’appelant et de l ’appelé auront
été réservées par le PCRF. Ces ressources sont représentées par des dedicated bearer avec QCI = 1 (conversational
audio). L ’appelant comme l ’appelé doit donc disposer d ’un dedicated bearer pour le transport de la voix sur IP . Ce
dedicated bearer est associé au default bearer SIP/IMS, qui lui, est relatif à la signalisation SIP IMS.
1. Le P-CSCF s’adresse au PCRF (Policy and Charging Rules Function) afin de lui demander de réserver les ressources
à l’accès, relatives à la description SDP. Pour ce faire, le P-CSCF émet une requête Rx Authenticate and Authorize
Request (AAR) contenant les informations des descriptions SDP de l ’appelant (SDP1) et de l ’appelé (SDP2).
2. L’entité PCRF traduit la QoS des descriptions SDPs en des paramètres QoS spécifiques à l’accès EPS; elle émet la
requête Gx Re-Authorize Request (RAR) au PDN-GW.
3. Le PDN GW initie la création du dedicated bearer à l’aide de la requête Create Dedicated Bearer Request (EPS
Bearer QoS) indiquant la QoS requise;. Cette requête est reçue par l’entité Serving GW.
4. Le Serving GW relaie la requête Create Dedicated Bearer Request (EPS Bearer QoS) au MME.
5. L’entité MME demande l’établissement d’un bearer d’accès à l’eNodeB à l’aide de la requête S1-AP Bearer Setup
Request (EPS Bearer QoS).
6. L’eNodeB traduit la Qos demandée dans le paramètre “EPS Bearer QoS” en une QoS correspondante sur l’interface
radio “Radio Bearer QoS”. Il notifie alors à l’UE la mise en place d’un bearer radio.
7. L’UE acquitte cet activation de bearer radio à l’eNodeB.
8. L’eNodeB acquitte l’activation du bearer au MME à l’aide de la réponse Bearer Setup Response. L’eNodeB indique si
la QoS requise a pu être allouée ou non.
9. Le MME acquiite l’activation du bearer au Serving GW par l’envoi d’une réponse Create Dedicated Bearer Response.
10. Le Serving GW acquitte l’activation du bearer au PDN GW par l’envoi de la réponse Create Dedicated Bearer
Response.
11. Le PDN GW retourne la réponse Re-Authorize Answer (RAA) au PCRF pour lui indique que la politique de QoS a pu
être exécutée avec succès.
12. Le PCRF retourne la réponse Rx Authenticate and Authorize Answer (AAA) au P-CSCF pour lui indiquer que la QoS
a pu être réservée dans le réseau d’accès de l’appelant.
148
Description de session IMS (Descriptions de
l ’appelant et de l’appelé)
Descriptions SDP (Session Description Protocol RFC 4566)

Appelant (sdp1)
v=0
m=audio 49234 RTP/AVP 97
c=IN IP6 3456::1:2:3:4
a=rtpmap:97 W-AMR/16000
b=AS:25
Appelé (sdp2)
v=0
m=audio 41212 RTP/AVP 97
c=IN IP6 6789::5:6:7:8
a=rtpmap:97 W-AMR/16000
b=AS:25
149
Paramètres SDP
v = 0 : Version du protocole SDP (0)
c = IN IP6 3.4.5.6::1:2:3:4 Données de connexion incluant le type de réseau (IN =
Internet), le type d’adresse (IP6=IPv6) et l’adresse de connexion (3.4.5.6::1:2:3:4)
m = audio 49234 RTP/AVP 97 Type de média (audio), port de transport où la voix ou
la vidéo paquétisée doit être envoyée (49234), le protocole de transport (RTP) et le
type de codec (AVP 97).
a = rtpmap 97 W-AMR/16000. Attribute. Décrit les attributs du codec 97. Il s ’agit du
codec Wideband AMR (W-AMR) aussi appelé codec audio HD dont la fréquence
d ’horloge est de 16000 Hz
b = AS : 25. Bandwidth. Il est demandé un débit de 25 kbit/s pour le transport de ce
flux audio.
149
Requête Rx AA-Request du P-CSCF au PCRF (1)
<AA-Request> ::= < Diameter Header: 265, REQ, PXY >
< Session-Id = “pcscf1.orange.fr;222111;110” >
{ Auth-Application-Id = 16777222 (Rx) }
{ Origin-Host = “pcscf1.orange.fr” }
{ Origin-Realm = “orange.fr” }
{ Destination-Realm = “orange.fr” }
{Subscription-Id =
{ Subscription-Id-Type = END_USER_SIP_URI (2)}
{ Subscription-Id-Data= sip:JohnCook@orange.fr}
}
{ Media-Component-Description =
{ Media-Component-Number = 1 }
{ Media-Sub-Component =
{ Flow-Number = 1 }
{ Flow-Description =
“permit in 17 from 3456::1:2:3:4 49234 to 6789::5:6:7:8 41212 ” }
“permit out 17 from 6789::5:6:7:8 41212 to 3456::1:2:3:4 49234”}
{ Flow-Usage = RTP(1) }
{ Max-Requested-Bandwidth-UL = 25000 }
{ Max-Requested-Bandwidth-DL = 25000 }
{ Flow-Status = ENABLED }
}
} 150
150
Requête Rx AA-Request du P-CSCF au PCRF (2)
{ Media-Sub-Component =
{ Flow-Number = 2 }
“permit in 17 from 3456::1:2:3:4 49235 to 6789::5:6:7:8 41213 ” ]
“permit out 17 from 6789::5:6:7:8 41213 to 3456::1:2:3:4 49235” ]
{ Flow-Usage = RTCP(1) }
{ Max-Requested-Bandwidth-UL =1250 }
{ Max-Requested-Bandwidth-DL = 1250 }
{ Flow-Status = ENABLED }
}
{ Media-Type = AUDIO (0) }
}
{AF-Charging-Identifier = AyretyU0dm+6O2IrT5tAFrbHLso=023551024}
{Specific-Actions = IP-CAN Change (6)}
151
151
Requête Gx Re-Auth Request (RAR)
du PCRF au PCEF (i.e., PGW)
<RA-Request> ::= < Diameter Header: 258, REQ, PXY >
{ Session-Id = “pgw1.orange.fr;1144207323;110 ” }
{ Auth-Application-Id = 16777224 (Gx) }
{ Origin-Host = “pcrf1.orange.fr” }
{ Origin-Realm = “orange.fr” }
{ Destination-Realm = “orange.fr” }
{ Re-Auth-Request-Type = AUTHORIZE_ONLY (0)}
{ Event-Trigger = QOS_CHANGE (1), RAT_Change (2),
USER_LOCATION_CHANGE (13), AN_GW_CHANGE (21)}
{ Charging-Rule-Install =
{Charging-rule-Definition}
{Charging-rule-Definition}
{QoS-Information =
QoS-Class-Identifier = QCI_1 (1),
Allocation-Retention-Priority =
Priority-level = 2,
Pre-emption-Capability = PRE-EMPTION_CAPABILITY_ENABLED (0),
Pre-emption-Vulnerability = PRE-EMPTION_VULNERABILITY_DISABLED (1)
Guaranteed-Bitrate-UL = 26250,
Guaranteed-Bitrate-DL = 26250
}
} 152
152
Règle PCC relative au trafic RTP
Charging-Rule-Definition ::= < AVP Header: 1003 >
{ Charging-Rule-Name = “RN_VoIP_1”}
{ Service-Identifier = “VoIP”}
{ Rating-Group = GroupA}
{ Flow-Information =
Flow-Description =
“permit in 17 from 3456::1:2:3:4 49234 to 6789::5:6:7:8 41212 ” }
Flow-Description =
“permit out 17 from 6789::5:6:7:8 41212 to 3456::1:2:3:4 49234”}
{Flow-Status = ENABLED}
{ QoS-Information =
Max-Requested-Bandwidth-UL = 25000,
Max-Requested-Bandwidth-DL = 25000,
{Online = DISABLE_ONLINE (1)}
{Offline = ENABLE_OFFLINE (1)}
{Metering-Method = VOLUME (1)}
{ Flows =
Flow-Number = 1}
153
The Charging-Rule-Definition AVP (AVP code 1003) is of type Grouped, and it defines the PCC rule for a service
flow sent by the PCRF to the PCEF.
The Charging-Rule-Name AVP (AVP code 1005) uniquely identifies the PCC rule and it is used to reference to a
PCC rule in communication between the PCEF and the PCRF within one IP CAN session.
The Service-Identifier AVP is the identity of the service or service component the service data flow in a PCC rule
relates to.
The Rating-Group AVP (AVP Code 432) is of type Unsigned32 and contains the identifier of a rating group. All the
services subject to the same rating type are part of the same rating group.
The Flow-Information AVP(s) (AVP Code 1058) determines the traffic that belongs to the service flow.
The Flow-Status (AVP code 511) is of type Enumerated, and describes whether the IP flow(s) are enabled or
disabled. The following values are defined: ENABLED-UPLINK (0), ENABLED-DOWNLINK (1), ENABLED (2) (i.e.,
This value shall be used to enable all associated IP flow(s) in both directions), DISABLED (3).
The QoS-Information (AVP code 1016) is of type Grouped, and it defines the QoS information for resources
requested by the UE, an IP-CAN bearer, PCC rule, QCI or APN.
The Online AVP (AVP code 1009) is of type Enumerated. The following values are defined: DISABLE_ONLINE (0),
ENABLE_ONLINE (1).
The Offline AVP (AVP code 1008) is of type Enumerated. The following values are defined: DISABLE_OFFLINE (0),
ENABLE_OFFLINE (1).
The Metering-Method AVP (AVP code 1007) is of type Enumerated. The following values are defined: DURATION
(0), VOLUME (1), DURATION_VOLUME (2).
The Precedence AVP (AVP code 1010) is of type Unsigned32. Within the Charging Rule Definition AVP, the
Precedence AVP determines the order, in which the service data flow templates are applied at service data flow
detection at the PCEF. A PCC rule with the Precedence AVP with lower value shall be applied before a PCC rule with
the Precedence AVP with higher value.
The AF-Charging-Identifier (505) is the AF charging identifier that may be used in charging correlation. For IMS is
the ICID. This AVP may only be included in a Charging-Rule-definition AVP if the SERVICE_IDENTIFIER_LEVEL
reporting is being selected with the Reporting-Level AVP.
The Flows AVP (AVP code 510) is of type Grouped, and it indicates IP flows via their flow identifiers.
The Monitoring-Key AVP (AVP code 1066) is of type OctetString and is used for usage monitoring control purposes
as an identifier to a usage monitoring control instance.
The AF-Signaling-Protocol Indicates the protocol used for signalling between the UE and the AF.
153
Règle PCC relative au trafic RTCP
Charging-Rule-Definition ::= < AVP Header: 1003 >
{ Charging-Rule-Name = “RN_RTCP_1”}
{ Service-Identifier = “RTCP”}
{ Rating-Group ]
“permit in 17 from 3456::1:2:3:4 49235 to 6789::5:6:7:8 41213 ” ]
“permit out 17 from 6789::5:6:7:8 41213 to 3456::1:2:3:4 49235” ]
{ Flow-Usage = RTCP(1) }
{Flow-Status = ENABLED}
{ QoS-Information =
Max-Requested-Bandwidth-UL = 1250,
Max-Requested-Bandwidth-DL = 1250}
{Online = DISABLE_ONLINE (0)}
{Offline = ENABLE_OFFLINE (1)}
{Metering-Method = VOLUME (1)}
{ Flows =
Flow-Number = 2}
154
154
Libération de Session IMS et désactivation
du bearer dédié
UE
UE P-CSCF
eNodeB
SGW PGW
S1 S11 S5 PCEF Gx
MME PCRF Rx
SIP BYE
1. Rx STR
2. Gx RAR
3. GTPv2C Delete Bearer Request
4. GTPv2C Delete Bearer Request

5. S1-AP Deactivate Bearer Request GTPv2-C
S1-AP
6. RRC Connection Reconfiguration Request
RRC
Rx, Gx
7. RRC Connection Reconfiguration Response SIP
8. S1-AP Deactivate Bearer Response
9. GTPv2C Delete Bearer Response

10. GTPv2C Delete Bearer Response
11. Gx RAA 12. Rx STA
155
Un usager émet une requête SIP BYE afin de libérer une session IMS en cours (e.g., session de
téléphonie). Cette requête est relayée par l’UE au P-CSCF.
1. Le P-CSCF s’adresse au PCRF (Policy and Charging Rules Function) afin de lui demander
de libérer les ressources à l’accès. Pour ce faire, le P-CSCF émet une requête Rx Session
Termination Request (STR).
2. L’entité PCRF traduit la requête Rx STR en une requête Gx Re-Authorize Request (RAR) au
PDN-GW.
3. Le PDN GW initie la liberation du dedicated bearer à l’aide de la requête Delete Bearer
Request.. Cette requête est reçue par l’entité Serving GW.
4. Le Serving GW relaie la requête Delete Bearer Request au MME.
5. L’entité MME demande la libération du bearer d’accès (Radio access bearer, RAB) à
l’eNodeB à l’aide de la requête S1-AP Deactivate Bearer Request.
6. L’eNodeB notifie à l’UE la libération du bearer radio.
7. L’UE acquitte la liberation du bearer radio à l’eNodeB.
8. L’eNodeB acquitte la liberation du radio access bearer au MME à l’aide de la réponse S1-AP
Delete Bearer Response..
9. Le MME acquiite la liberation du dedicated bearer au Serving GW par l’envoi d’une réponse
Delete Bearer Response.
10. Le Serving GW acquitte la liberation du dedicated bearer au PDN GW par l’envoi de la
réponse Delete Bearer Response.
11. Le PDN GW retourne la réponse Re-Authorize Answer (RAA) au PCRF pour lui indiquer que
la politique a pu être exécutée avec succès.
12. Le PCRF retourne la réponse Rx Session Termination Answer (STA) au P-CSCF pour lui
indiquer que le dedicated bearer a pu être libéré dans le réseau d’accès de l’appelant.
155
Demande de service initiée par le réseau
UE
eNodeB
SGW PGW
MME
2. Downlink Data Notification 1. Downlink Data
4. Paging Request
5. Paging 3. Downlink Data Notification Ack
6. Service Request (service type = paging response)
7. S1-AP : Initial Context Setup Request
8. S1-AP : Initial Context Setup Complete
9. Modify Bearer Request
10. Modify Bearer Response
11. Downlink Data
156
1. Le PDN GW délivre un paquet IP entrant au SGW sur le default bearer de l’UE.

2. Le SGW n’ayant de pas RAB établi vers l’UE notifie le MME (message DDN) de l’arrivée
de paquets pour l’UE et mémorise ces paquets.
3. Le MME acquitte la réception du message DDN au Serving GW.
4. Le MME réalise un opération de paging vers l’UE. La demande de paging est diffusée sur
l’ensemble des eNodeB de la Tracking Area de l’UE.
5. L’UE reçoit la demande de paging via son eNodeB.
6. L’UE répond à la demande de paging via le message Serving GW. Pour ce faire, l’UE a
ouvert une connexion RRC avec l’eNodeB.
7. Le MME ayant identifié l’eNodeB prenant en charge l’UE, demande à cet eNodeB de créer
le RAB (Radio Access Bearer). Le RAB est établi par l’eNodeB entre l’UE et le Serving GW.
Le MME fournit à l’eNodeB l’adresse du Serving GW.
8. Une fois le RAB établi, l’eNodeB retourne une confirmation au MME.
8. Le MME fournit au Serving GW le numéro de tunnel GTP-U vers l’eNoeB ainsi que
l’adresse de l’eNodeb via le message Modifiy Bearer Request.
10. Le Serving GW confirme la réception du message.
11. Le Serving GW peut dès à présent relayer les paquets IP mémorisés sur le RAB.
156
Demande de service initiée par l’UE
UE
eNodeB
SGW PGW
S1 MME S11 S5 Gx HSS
PCRF
1. NAS: Service Request

2. NAS: Service Request
3. Authentification
4. S1-AP : Initial Context Setup Request
5. Radio Bearer Establishment
6. Uplink Data
7. S1-AP : Initial Context Setup Complete
8. Modify Bearer Request
9. Modify Bearer Response
157
1. L ’UE est dans l ’état Idle. Il souhait émettre des paquets IP sur son default bearer. L ’UE
émet donc un message NAS Service Request afin de demander l ’établissement d ’un RAB
pour son default bearer.
2. Le message NAS Service Request est relayé par l ’eNodeB au MME.
3. Le MME authentife l ’UE suite à sa demande d ’établissement de RAB.
4. Le MME ayant identifié l’eNodeB prenant en charge l’UE, demande à cet eNodeB de créer le
RAB (Radio Access Bearer). Le RAB est établi par l’eNodeB entre l’UE et le Serving GW. Le
MME fournit à l’eNodeB l’adresse du Serving GW.
5. L ’eNodeB créer le RB (Radio Bearer entre l ’UE et l ’eNodeB).
7. Une fois le RAB établi entre l ’UE et le Serving GW, l’eNodeB retourne une confirmation au
MME.
8. Le MME fournit au Serving GW le numéro de tunnel GTP-U vers l’eNoeB ainsi que l’adresse
de l’eNodeb via le message Modifiy Bearer Request.
9. Le Serving GW confirme la réception du message. Le Serving GW sait dès à présent relayer
les futurs paquets IP entrants sur le RAB à l ’UE via l ’eNodeB.
157
Concept de Bearer
E-UTRAN EPC Internet
UE eNB S-GW P -GW Peer

Entity
End-to-end Service
EPS Bearer External Bearer
E-RAB S5 /S8 Bearer
Radio Bearer S1 Bearer
Radio S1 S5/S8 Gi
158
158
Terminologie Bearer EPS
Qualité de service
GBR bearer : Débit garanti (GBR, Guaranteed bit rate)
Non-GBR bearer : Aucune garantie de débit (Non-GBR, No
Guaranteed bit rate)
Temps d ’établissement
Default bearer
Etabli lorsque l ’UE se connecte au PDN
fournit une connectivé always-on non-GBR
Dedicated bearer
Etabli ultérieurement
Peut être GBR ou non-GBR
159
159
Paramètres QoS
Chaque bearer EPS est caractérisé par :

QoS class identifier (QCI)
Allocation and retention priority (ARP)
Chaque bearer GBR est caractérisé par :
Guaranteed bit rate (GBR)
Maximum bit rate (MBR)
Les bearers non-GBR sont caractérisés ensemble par :
Per APN aggregate maximum bit rate (APN-AMBR)
Per UE aggregate maximum bit rate (UE-AMBR)
160
160
QoS Class Identifier (QCI)
161
161
Allocation and Retention Priority (ARP)
L’ Allocation and Retention Priority consiste en :

Priority Level : Valeurs de 1 à 15
Pre-emption-Capability a pour valeur
PREEMPTION_CAPABILITY_ENABLED (0) ou
PREEMPTION_CAPABILITY_DISABLED (1)
Pre-emption-Vulnerability a pour valeur
PREEMPTION_VULNERABILITY_ENABLED (0) ou
PREEMPTION_VULNERABILITY_DISABLED (1)
162
162
Application des paramètres de QoS (1)
Le client dispose d ’une souscription pour l ’accès à Internet et

l ’accès à des services IMS.
Pour l ’accès Internet, sa souscription lui permet un débit maximum
descendant de 8 Mbit/s et un débit montant de 4 Mbit/s. Lorsqu ’il
aura atteint son fair-use le débit sera baissé à 128 kbit/s descendant
et 64 kbits/s montant.
Son Profil dans le HSS ne décrit que la QoS pour le défault bearer,
soit pour l ’APN internet :
QCI = 9
ARP = 6
APN-AMBR-DL = 8000000; APN-AMBR-UL = 4000000
Pour l ’APN IMS, son profil fournit les informations pour le default
bearer, soit :
QCI = 5
ARP = 1
APN-AMBR-DL = 20000; APN-AMBR-UL = 20000
163
163
Application des paramètres de QoS (2)
UE-AMBR-DL = 10000000; UE-AMBR-UL = 4000000

APN : ims.orange.fr GBR UL = 25000
GRB DL = 25000
QCI = 1 MBR UL = 25000
ARP = 3 Dedicated Bearer (GBR) MBR DL = 25000
QCI = 7
ARP = 3
Dedicated Bearer (Non-GBR) APN-AMBR DL = 20000
100000
QCI = 5 Default bearer (Non-GBR)
ARP = 1 APN-AMBR UL = 20000
100000
APN : internet.orange.fr GBR UL = 25000

GRB DL = 25000
QCI = 1
Dedicated Bearer (GBR) MBR UL = 25000
ARP = 6
MBR DL = 25000
QCI = 7
ARP = 5 Dedicated Bearer (Non-GBR) APN-AMBR DL = 8000000
QCI = 9 10000000
ARP = 6
Default bearer (Non-GBR) APN-AMBR UL = 4000000
164
Pour l ’APN IMS :

• Le dedicated bearer avec QCI = 1 est établi pour supporter le trafic de voix sur IP. Il
s ’agit d ’un bearer GBR et donc est caractérisé par des débits garantis et des débits
maximum dans les sens montant et descendant.
• Le dedicated bearer avec QCI = 7 est utilisé pour le « Tchat ». Il s ’agit d ’un bearer
Non-GBR et donc partage avec les autres bearers non-GBR de cet APN une QoS
caractérisée par un débit maximum dans les montant et descendant. L’opérateur a
donc augmenté le débit de l ’APN-AMBR qui était au départ de 20 kbit/s dans les deux
sens et l ’a fait passer à 100 kbit/s pour accommoder les deux flux, le flux SIP et le flux
tchat. La somme des débits des deux bearers (default bearer pour SIP et dedicated
bearer Non-GBR pour le tchat) ne pourra donc pas dépasser 100 kbit/s dans chaque
sens.
• Le default bearer avec QCI = 5 est celui qui transporte la signalisation SIP. Il s ’agit
d ’un bearer Non-GBR (puisque tout default bearer est bearer non-GBR) et donc
partage avec les autres bearers non-GBR de cet APN une QoS caractérisée par un
débit maximum dans les montant et descendant.
• Le dedicated bearer (QCI=7) et le default bearer (QCI=5) auront un débit total
maximum qui ne pourra pas dépasser 100 kbit/s dans le sens descendant et 100 kbit/s
dans le sens montant.
164
QoS et Transport
Il convient d’appliquer une politique de transport adaptée à la

QoS des flux. Si au niveau radio c’est au scheduler de faire le
travail il convient au niveau S1 (SGW-eNodeB) et S5 (SGW-
PGW) d’appliquer les bons choix MPLS/Diffserv.
165
165
Mobilité en mode ACTIVE
Mobilité Intra-E-UTRAN avec support X2 : Handover entre
un eNodeB source et un eNodeB cible avec présence de
l’interface X2 entre eNodeBs.
Mobilité Intra-E-UTRAN sans support X2 : Handover entre
un eNodeB source et un eNodeB cible avec absence de
l’interface X2 entre eNodeBs.
Mobilité Intra E-UTRAN avec changement de noeud EPC :
Un cas plus complexe faisant intervenir les nœuds du réseau
core paquet
Mobilité entre les réseaux paquet 2G/3G et E-UTRAN :
handover pour le mode paquet entre technologies.
166
166
Procédure de handover
Late Path Switching
Avant Préparation Handover Commutation de
Handover Handover Radio chemin tardif
SGW SGW SGW SGW
MME MME MME MME
eNodeB eNodeB eNodeB eNodeB eNodeB eNodeB eNodeB eNodeB
Data in radio
Signaling in radio
GTP tunnel
UE GTP signaling UE UE UE
S1 signaling
X2 signaling 167
167
Commutation du plan usager lors du handover
Avant le Handover Relai des paquets Late Path Switching

Commutation de chemin tardif
SGW SGW SGW
UL DL DL UL DL UL
eNodeB eNodeB eNodeB eNodeB eNodeB eNodeB

DL DL
UL DL UL UL DL
DL
UE UE UE
UL : Uplink
DL : Downlink 168
168
Mobilité Intra-E-UTRAN avec support X2
UE eNodeB Source eNodeB Cible

SGW PGW
X2 S1 S11 S5
MME
Décision de Handover
Handover Request
Allocation de
Ressources Radio
Handover Request Acknowledge
(Handover Command)
Start data forwarding
Handover Command
Handover Confirm Path Switch Request
Modify Bearer Request
Release Resource Path Switch Ack Modify Bearer Response
Libération des
ressources radio
Tracking Area Update Procedure 169
Avec LTE la gestion de mobilité est distribuée, les eNodeBs prennent la décision de Handover d’une façon
autonome sans implication des éléments : MME et S-GW. Les informations nécessaires au Handover sont
échangées entre les eNodeBs via une interface appelée X2. Le MME et le S-GW recevront une notification
avec un message complet de Handover après que la nouvelle connexion aura été attribuée entre l’UE et la
nouvelle eNodeB. Après réception du message, les Gateways effectuent le chemin de commutation.
Durant le Handover il y a un délai durant lequel l’UE n’est pas connecté au système. Pour résoudre cela,
une solution temporaire de Forwarding des données perdues de l’ancien eNB vers le nouveau eNB est
proposée. Dans ce cas il n y a pas de mémorisation des données au niveau des Gateways. L’intérêt de
cette solution est de minimiser la charge de signalisation au niveau de l’interface entre l’eNB et l’MME/S-
GW.
Les principales étapes du Handover sont :
1) Le Handover est déclenché par l’UE qui envoie un rapport de mesure à l’eNB source qui va décider en
se fondant sur le rapport reçu et sur les informations concernant la gestion des ressources radio (RRM :
Radio Resource Management).
2) La phase de préparation du Handover commence par l’envoi d’une requête de Handover (HO Request)
de la part de l’eNB source vers l’eNB cible. Ce message contient toutes les informations pertinentes sur le
Handover.
3) L’eNB cible enregistre le contexte, prépare les couches 1 et 2 (L1/L2) pour le Handover et répond à
l’eNB source par un acquittement (HO Request Ack) qui fournira les informations sur l’établissement de
nouveau lien radio (handover Command).
4) L’eNB source transférera toutes les informations nécessaires à l’UE (Handover Command), et à ce
moment là, l’eNB source arrête d’envoyer et de recevoir des données avec l’UE. Il fera alors suivre les
données à l’eNB cible.
5) L’UE informe l’eNB cible du succès du Handover avec un message de confirmation (Handover Confirm).
Jusqu’à cet instant l’eNB cible mémorise les données reçus de l’eNB source. Après avoir reçu le message
de confirmation il commence à envoyer les données bufférisées à l’UE.
6) L’eNB cible initie le changement de chemin de données en envoyant un « Path Switch Request » au
MME. Les informations de localisation de l’UE seront ensuite mises à jour au niveau duu réseau effectue le
changement de chemin pour que les données soient envoyées directement vers l’eNB cible.
7) Le MME confirme le chemin par un message ‘Path Switch Request Ack’, et dès que l’eNB cible reçoit ce
message, il envoie une indication ‘release Resource’ au eNB source pour qu’il libère définitivement la
connexion avec l’UE. 169
Mobilité Intra-E-UTRAN sans support X2
UE eNodeB Source eNodeB Cible

SGW PGW
S1 MME S11 S5
Décision de Handover
Handover Required
Handover request
Allocation de
Ressources Radio
Handover Request Ack (Handover Command)
Handover Command
Handover Command
Handover Confirm Handover Notify
Modify Bearer Request
UE Context Release Command Modify Bearer Response
Libération des
ressources radio
UE Context Release Complete
170
Dans certains cas, il peut arriver que l’interface X2 ne soit pas disponible entre eNodeBs. Cela peut
être du à un problème réseau ou tout simplement du à l’opérateur qui ne souhaite pas interconnecter
ces eNodeB pour des raisons de coûts.
Dans ce cas, l’architecture est la même que celle lorsque il y a X2, mais sans connectivité entre
eNodeBs.
La procédure de handover sera alors plus complexe puisqu’il n’est plus possible de faire acheminer les
messages de handover directement entre eNodeB. Ces messages devront être relayés par le MME.
Les messages échangés entre les entités lorsque l’interface X2 est absente sont décrits sur la Figure.
Même si les messages sont différents du cas où X2 est présent, les principes de base restent les
mêmes. La demande de handover (S1-AP Handover Required) du eNodeB source au eNodeB cible
est acheminée via le MME (Ici il est supposé que le même MME dispose d’interfaces S1-MME vers les
deux eNodeBs.
Le MME achemine la commande S1-AP Handover Request au eNodeB cible.
Une fois les ressource allouées, l’eNodeB cible retourne au MME une réponse S1-AP handover
request Ack (Handover Command). Le MME achemine la réponse S1-AP Handover Command est
retournée par le MME au eNodeB source.
Le eNodeB source transfère toutes les informations nécessaires à l’UE (RRC Handover Command), et
à ce moment là, l’eNB source arrête d’envoyer et de recevoir des données avec l’UE. Par contre, Il ne
fera pas suivre les données à l’eNB cible.
L’UE informe l’eNB cible du succès du Handover avec un message de confirmation (Handover
Confirm).
L’eNB cible initie le changement de chemin de données en envoyant un message S1-AP handover
notify au MME. Les informations de localisation de l’UE seront ensuite mises à jour au niveau du
réseau qui effectue le changement de chemin pour que les données soient envoyées directement vers
l’eNB cible.
7) Le MME envoie une indication S1-AP UE Contexte Release Command au eNB source pour qu’il
libère définitivement la connexion avec l’UE. Une fois la connexion libérée, la réponse S1-AP UE
Contexte Release Complete est retourné par l ’eNodeB source au MME.
170
Mobilité Intra E-UTRAN avec
changement de noeud EPC
UE SOURCE CIBLE
SGW SGW PGW
S1 S11 S1 S11 S5
MME MME
Measurement Report
Décision de handover
Handover Required Forward Relocation Request Create Session Request
Create Session Response
Handover Request
Allocation de ressources radio

Handover Request Ack (Handover Command)
Handover Command Forward Relocation Response (Handover Command)
Handover Command
Handover Confirm Handover Notify
Forward Relocation Complete
Forward Relocation Complete Ack
UE Context Release Command
Modify Bearer Request Modify Bearer Request
Libération de ressource radio
Modify Bearer Response
Delete Session Request Modify Bearer Response
Delete Session Response
171
L’eNodeB source décide d’initier la procédure de handover. Comme le nouveau eNodeB est sous la responsabilité d’un
autre MME, il est important que les messages de handover soient acheminés via les MMEs respectifs.
L’eNodeB source émet un message S1-AP Handover Required au MME source. Le MME source identifie le MME cible
et s’il s’agit d’un MME différent, il achemine un message GTPv2-C Forward Relocation Request au MME cible.
Si le MME a été délocalisé, le MME cible vérifie si le Serving GW source peut continuer à servir l’UE. Si tel n’est pas le
cas, il sélectionne un nouveau Serving GW.
Le MME cible émet un message S1-AP Handover Request à l’eNodeB cible. Une fois que les ressources radio ont été
allouées par l’eNodeB cible, ce dernier retourne au MME cible la réponse S1-AP Handover Request Ack.
Si le Serving GW est délocalisé, le MME cible émet un message GTPv2-C Create Session Request au nouveau Serving
GW pour lui fournir les informations concernant les ressources requises pour l ’usager. Le Service GW reserve ses
ressources localement et retourne les informations les concernant dans la réponse GTPv2-C Create Session Response.
Par ailleurs le Serving GW a appris où router les paquets sortant (i.e., le PDN Gateway).
Le MME cible retourne une réponse GTPv2-C Forward Relocation Response au MME source contenant la commande
Handover Command à acheminer à l ’UE. Le MME source émet un message S1-AP Handover Command au eNodeB
source.
L’eNB source transfére toutes les informations nécessaires à l’UE (Handover Command), et à ce moment là, l’eNB
source arrête d’envoyer et de recevoir des données avec l’UE. Il fera alors suivre les données à l’eNB cible si l ’interface
X2 est présente.
L’UE informe l’eNB cible du succès du Handover avec un message de confirmation (RRC Handover Confirm).
Jusqu’à cet instant l’eNB cible mémorise les données reçus de l’eNB source. Après avoir reçu le message de
confirmation il commence à envoyer les données bufférisées à l’UE.
L’eNB cible initie le changement de chemin de données en envoyant un message S1-AP handover notify au MME.
Le MME cible confirme au MME source par un message GTPv2-C Forward Relocation Complete le basculement de
l ’usager sur l ’eNodeB cible. Le MME source acquitte ce message par la réponse GTPv2-C Forward Relocation
Complete Ack.
Le MME source envoie une indication S1-AP UE Contexte Release Command au eNB source pour qu’il libère
définitivement la connexion avec l’UE. Une fois la connexion libérée, la réponse S1-AP UE Contexte Release Complete
est retourné par l ’eNodeB source au MME source.
En parallèle le MME cible émet une requête GTPv2-C Modify Bearer Request pour informer le Serving GW cible des
informations pour le transfert des paquets entrants au eNodeB cible.
Le Serving GW cible émet une requête GTPv2-C Modify Bearer Request au PDN GW pour lui demander de transférer
les paquets entrants au Serving GW cible.
171
Mobilité entre les réseaux
paquet 2G/3G et E-UTRAN
UE SOURCE CIBLE
SGSN SGW PGW
S1 S3 IuPS RNC S5
MME
Décision de handover
Handover Required
Forward Relocation Request
Relocation Request
Allocation de ressources radio

Relocation Response Ack
Handover Command Forward Relocation Response
Handover Command
Handover to UTRAN Confirm
Relocation Complete
Forward Relocation Complete
Forward Relocation Complete Ack
UE Context Release Command
Modify Bearer Request Modify Bearer Request
Libération de ressource radio
172
172
4.3 LTE et Services de Voix
173
L ’EPS est entièrement basé sur la commutation de paquets et ne

comporte pas de domaine à commutation de circuits, contrairement aux
réseaux. Il a en outre vocation à être associé à l’architecture de services
IMS, définie par le 3GPP, pour l’accès aux services multimédias incluant
la téléphonie sur IP.
Cependant, lors de l’élaboration de la Release 8 3GPP où est née la
spécification de l ’EPS, plusieurs opérateurs souhaitaient pouvoir fournir
un service voix via les terminaux mobiles LTE dès l’ouverture de leur
réseau LTE, sans avoir à déployer dans le même temps une architecture
IMS, complexe et coûteuse.
Pour cette raison, un mécanisme a été défini pour basculer l’UE, dès
qu’un appel voix est lancé, vers une technologie d’accès traitant la voix en
commutation de circuits (appelée aussi voix CS par opposition à la VoIP).
Ce mécanisme, appelé Circuit Switched Fallback (CSFB), permet de
renvoyer un appel voix lancé par l’UE ou à destination de celui-ci vers le
domaine CS de la 2G ou de 3G. CSFB supporte aussi les services
visiophonie, SMS et USSD en plus du service voix, tous ces services
étant offerts par un domaine circuit 2G/3G existant.
173
CS Fallback dans l ’architecture EPS
S4-SGSN
IuPS
UTRAN
IuCS Gs
MSC Server
Gb
UE
A
GERAN
S3 SGs
S1-C SGsAP
E-UTRAN MME SCTP
IPv4/IPv6
Interface SGs spécifiée par la recommandation TS 29.118

174
Le préalable à la procédure CSFB est que l’UE s’attache au domaine circuit en même
temps qu’il s’enregistre à l’EPS. Sans cela, le MSC Server recevant la notification
d’appel ou le SMS à destination de l’UE ne saura router le message vers le bon MME.
On parle alors d’enregistrement combiné EPS/CS. La réalisation de cette procédure
nécessite donc la prise en charge de fonctions spécifiques, principalement sur l’UE, le
MME et le MSC Server. En particulier, le MME et le MSC Server doivent tous deux
mettre en œuvre une nouvelle interface (SGs), semblable à l’interface Gs définie entre
SGSN et MSC, pour l’enregistrement combiné, l’envoi de la notification d’appel, le
transfert du message EMM et l’envoi ou la réception de SMS. Le MME doit par ailleurs
indiquer à l’eNodeB la nécessité de basculer l’UE. L’UE doit quant à lui être capable de
réaliser un enregistrement combiné, d’implémenter les procédures CSFB pour les
appels voix entrants et sortants.
Afin de garantir la continuité des sessions de données de l ’UE lors de l ’établissement
d ’un appel voix sortant ou entrant, il est nécessaire que le MME partage avec le S4-
SGSN une interface de signalisation S3 basé sur le protocole GTPv2-C transporté sur
UDP/IP.
L ’interface SGs est supportée par un nouveau protocole de signalisation appelé
SGsAP transporté sur SCTP/IP.
174
Mapping TA/LA
175
Le MME doit pouvoir identifier le MSC Server devant prendre en charge l ’UE lors de
l ’attachement combiné ou la mise à jour de localisation combinée. Pour ce faire, la
Tracking Area (4G) doit être incluse dans une Location Area (2G/3G). Dans
l ’exemple ci-dessus la TA1 est incluse dans la LA1 alors que les TA2 et TA3 sont
incluses dans la LA2.
Le MME dispose d ’une table de mapping entre TA et LA qui indique par ailleurs
l ’identité du MSC Server prenant en charge la LA correspondante.
Lorsque l ’UE s ’attache ou met à jour sa localisation, il s ’adresse au MME en
indiquant sa TA. Le MME la traduit en la LA et identifie le MSC Server auquel il
s ’adresse pour le mettre à jour.
175
Procédure d ’Attachement
UE MSC Server HSS
MME
1. EMM Attach Request
2. Procédure d ’attachement dans l ’EPS
3. Déduit le numéro de VLR (Mapping Tracking Area Location Area)
4. SGsAP-LOCATION-UPDATE-REQUEST (IMSI)
5. Crée l ’association SGs
6. Mise à jour de localisation

dans le domaine CS
7. SGsAP-LOCATION-UPDATE-ACCEPT
8. EMM Attach Accept
176
1. L’UE demande un enregistrement combiné EPS/IMSI.

2. Le MME réalise la procédure d’enregistrement de l’UE à l’EPS incluant
l’authentification, la mise à jour des informations de localisation du profil de l’usager,
l’obtention du profil auprès du HSS et l’établissement du premier default bearer pour
l’UE..
3. Le MME traduit la Tracking Area Identity de l’UE en sa Location Area pour
identifier le MSC Server/VLR qui prend en charge la zone de couverture du l’UE. Le
MME informe le MSC Server/VLR qu’il a reçu une demande d’attachement combiné
EPS/IMSI de l’UE via le message SGsAP-LOCATION-UPDATE-REQUEST.
4. Le MSC Server/VLR réalise la procédure d’enregistrement au domaine circuit de
l’UE.
5. Le MSC Server/VLR confirme la réception du message SGsAP-LOCATION-
UPDATE-REQUESTpar un message SGsAP-LOCATION-UPDATE-ACCEPT.
6. L’UE est informé de son attachement aux deux réseaux.
176
Procédure de mise à jour
combinée de TA/LA
UE
MSC Server HSS
MME
1. L ’UE décide de réaliser

l ’opération TAU
2. EMM TAU Request
3. Procédure TAU dans l ’EPS
4. SGsAP-LOCATION-UPDATE-REQUEST (IMSI)
5. Mise à jour de localisation dans le domaine CS
6. SGsAP-LOCATION-UPDATE-ACCEPT
7. EMM TAU Accept
177
1. L’UE demande une mise à jour combinée TA/LA. Pour ce faire, il émet à son
MME un message EMM Tracking Area Update (TAU) contenant un paramètre EPS
Update Type qui est positionné à la valeur “Combined TA/LA Updating”.
2. Le MME réalise la procédure de mise à jour de tracking area.
3. Le MME traduit la nouvelle Tracking Area Identity de l’UE en sa Location Area
pour identifier le MSC Server/VLR qui prend en charge la zone de couverture du
l’UE. Le MME informe le MSC Server/VLR qu’il a reçu une demande de mise à jour
de Location Area.
4. Le MSC Server/VLR réalise la procédure de mise à jour de Location Area dans
le domaine circuit.
5. Le MSC Server/VLR confirme la réception du message SGsAP-LOCATION-
UPDATE-REQUESTpar un message SGsAP-LOCATION-UPDATE-ACCEPT.
6. L’UE est informé de la mise à jour de la Tracking Area et de la Location Area.
177
Demande d’établissement d’appel dans E-
UTRAN, appel dans GERAN/UTRAN
UE eNodeB RNC
MSC Server SGSN Serving GW
MME
1a. Extended Service Request

1a. Extended Service Request
1b. S1-AP UE Initial Context Request avec indicateur « CS Fallback »
2. Sollicitation de rapport de
mesure (optionnel)
3. Handover paquet (PS, Packet Switching) de LTE à 3G
4. Procédure d ’établissement d ’appel CS (Circuit Switching)
5. Handover paquet de 3G à LTE
178
1a. L ’usager compose un numéro de téléphone de destination pour un appel

sortant. L ’UE étant attaché via la radio LTE à un MME, établit une connexion
RRC et contacte le MME avec le message EMM Extended Service Request,
dédié au CSFB et encapsulé successivement dans la signalisation RRC puis
dans un message S1-AP.
1b. Le MME demande alors à l’eNodeB de faire basculer l’UE, en lui indiquant
qu’il s’agit d’un CSFB dans le message S1AP UE Context Setup.
2. et 3. L’eNodeB peut alors rediriger l’UE vers la cellule cible prédéfinie, sans
préparation préalable. L’eNodeB peut éventuellement demander à l’UE
d’effectuer des mesures sur une ou plusieurs cellule(s) de la technologie cible
avant de lui envoyer la commande de bascule. Cette phase, si elle augmente les
chances de succès de la procédure, conduit néanmoins à un délai plus long
avant l’établissement effectif de l’appel voix.
4. L’UE tente alors d’accéder à la cellule cible et procède comme pour
l’établissement d’un appel voix CS sur le domaine circuit 2G ou 3G, après avoir
réalisé une mise à jour de localisation si la zone de localisation CS (Location
Area) a changé.
5. A partir de la Release 10, une fois l’appel voix terminé, un handover 2G ou
3G vers LTE est possible.
178
Appel entrant : Paging CS dans E-UTRAN,
appelé dans GERAN/UTRAN
HLR/HSS
UE GMSC Server
eNodeB RNC SGSN MSC Server
MME
MAP PRN (IMSI) MAP SRI (MSISDN)

MAP PRN Res (MSRN)
MAP PRN Res (MSRN)
2. SGsAP-Paging-Request 1. IAM
3. Paging (CS Domain Indicator)
4. Paging (CS Domain Indicator)
5. Extended Service Request
5. Extended Service Request
6. SGsAP-Service-Request
7. S1-AP UE Context Modification Request with « CS Fallback » indicator
8a. Optional Measurement
Report Sollicitation
8b. PS Handover from LTE to 3G
9. Paging Response 9. Paging Response
10. MM Location Area Updating Request 10. MM Location Area Updating Request
11. CC Setup Request 11. CC Setup Request
179
12. PS Handover from 3G to LTE
La figure ci-dessus illustre la procédure CSFB dans le cas d’un appel voix entrant.
1. Un appel entrant est délivré au MSC Server qui prend en charge dans le domaine circuit 2G/3G l ’UE
concerné par cet appel.
2. Le MME reçoit du MSC Server un message de notification d’appel CS pour l’UE (message SGsAP-
PAGING-Request).
3. Le MME transmet alors un message de paging à tous les eNodeB inclus dans la zone de localisation de
l’UE (Tracking Area, ou liste de TA). Cette demande de paging qui correspond pas à un paquet mais bien à
un paging Circuit (CS).
4. Chaque eNodeB envoie un paging sur les canaux radio communs des cellules associées à la zone de
localisation de l’UE. L’eNodeB indique dans chaque paging l ’identité de l’UE ‘(S-TMSI) pour qu’il sache que
le message lui est destiné. Ce message indique également que la notification provient du domaine CS, ce
qui permet à l’UE de déduire qu’il s’agit d’une procédure CSFB.
5. Sur réception de cette notification, l’UE établit une connexion RRC et contacte le MME avec le message
EMM Extended Service Request, dédié au CSFB et encapsulé successivement dans la signalisation RRC
puis dans un message S1-AP.
6. Le message SGsAP Service Request émis par le MME au MSC Server permet à ce dernier d’arrêter
l’éventuelle retransmission de message SGs-AP Paging request.
7. Le MME demande alors à l’eNodeB de faire basculer l’UE, en lui indiquant qu’il s’agit d’un CSFB dans le
message S1AP UE Context Modification Request.
8. L’eNodeB peut alors rediriger l’UE vers la cellule cible prédéfinie, sans préparation préalable. L’eNodeB
peut éventuellement demander à l’UE d’effectuer des mesures sur une ou plusieurs cellule(s) de la
technologie cible avant de lui envoyer la commande de bascule. Cette phase, si elle augmente les chances
de succès de la procédure, conduit néanmoins à un délai plus long avant l’établissement effectif de l’appel
voix.
9. L ’UE une fois basculé sur GERAN/UTRAN répond à la demande de paging du MSC Server directement
via GERAN/UTRAN au MSC Server.
10. L ’UE réalise une mise à jour de localisation si la zone de localisation CS (Location Area) a changé.
11. L ’appel entrant peut alors être traité.
179
Envoi de SMS
UE MSC Server HLR/HSS SMSC
MME
1. Procédure EPS/IMSI attach

2. UE triggered Service Request
3. Uplink NAS Transport (SMS-SUBMIT)
4. SGsAP-UPLINK-UNITDATA (SMT-SUBMIT)
5. MAP-MO-FORWARD-SHORT-MESSAGE
4a. SGsAP-DOWNLINK-UNITDATA
4a. Downlink NAS Transport
6. MAP-MO-FORWARD-SHORT-MESSAGE-Ack
7. SGsAP-DOWNLINK-UNITDATA (SMS-SUBMIT-REPORT)
8. Downlink NAS Transport (SMS-SUBMIT-REPORT)
9. Uplink NAS Transport

10. SGsAP-UPLINK-UNITDATA
11. SGsAP-RELEASE-REQUEST
180
Si le CSFB a été défini en premier lieu pour établir des appels voix CS lorsque que
l’UE a sélectionné une cellule LTE, son périmètre est plus étendu et recouvre
d’autres services initialement portés en 2G et 3G par le domaine circuit, e.g.,
services de localisation et services complémentaires de la téléphonie. Cependant,
tous ne donnent pas lieu à une bascule vers le domaine circuit de la 2G ou de la
3G. Ainsi, l’UE peut envoyer et recevoir des SMS insérés dans la signalisation
NAS sans utiliser l’IMS, mais sans être non plus envoyé sur une cellule 2G ou 3G.
On réutilise donc ici simplement le mode classique de transmission des SMS,
employé dans tous les réseaux 2G et 3G comme l ’illustre la figure ci-dessus
concernant le traitement d ’un SMS sortant avec CSFB.
180
Réception de SMS
UE eNodeB MSC Server HLR/HSS SMSC
MME
1. Procédure EPS/IMSI attach

2. MAP-SEND-ROUTING-INFO-FOR-SMS
3. MAP-SEND-ROUTING-INFO-FOR-SMS-Ack
4. MAP-MT-FORWARD-SHORT-MESSAGE
5. SGsAP-PAGING-REQUEST (MT-SMS)
6. Paging (MT-SMS)
7. Paging (MT-SMS)
8. Service Request 8a. SGsAP-SERVICE-REQUEST
9b. Downlink NAS Transport (SMS-DELIVER) 9a. SGsAP-DOWNLINK-UNITDATA (SMS-DELIVER)

9c. Uplink NAS Transport 9d. SGsAP-UPLINK-UNITDATA
10. Uplink NAS Transport 11. SGsAP-UPLINK-UNITDATA (SMS-DELIVER-REPORT)

(SMS-DELIVER-REPORT) 12. MAP-MT-FORWARD-SHORT-MESSAGE-Ack
14. Downlink NAS Transport 13. SGsAP-DOWNLINK-UNITDATA
15. SGsAP-RELEASE-REQUEST
181
181
Single Radio VCC (SRVCC)
Fournit la continuité de l ’appel voix entre IMS sur PS et CS

lorsque l ’UE est capable de transmettre/recevoir sur un seul
de ces réseaux d ’accès à un instant donné :
But
SRVCC de l ’accès E-UTRAN à l ’accès 3GPP2 1xCS
SRVCC de l ’accès E-UTRAN à l ’accès 3GPP UTRAN/GERAN CS
SRVCC de l ’accès UTRAN (HSPA) à l ’accès 3GPP UTRAN/GERAN CS
Recommandation TS 23.216
182
182
Chemins de signalisation et média
SR-VCC depuis l ’accès IMS
Domaine CS Domaine IMS

SCC AS
SIP
MSC SIP
MGCF S-CSCF
Server
SIP
MGW
RTP/UDP/IP
UE CS UE IMS
SR-VCC : Single Radio Voice Call Continuity

SCC : Service Centralization and Continuity
183
183
Architecture SRVCC E-UTRAN et
3GPP UTRAN/ GERAN
SCC : Service Consistency and Continuity
CSCF : Call State Control Function
ISC : IMS Service Control
BTS/ SCC
BSC/ MSC Server AS
UE NodeB RNC
Iu-CS/A SIP
ISC
SGSN CSCF
IuPS/Gb
Sv
SR-VCC
HSS
S3
MME
S1-C
UE eNodeB S11 IMS
S1-U SGi
SGW/PGW
Le MSC Server représenté à la figure est mis à jour pour SRVCC

184
184
Procédure SR-VCC
UE eNodeB MSC Server BSC/RNC
MME IMS
1. Measurement
reports 2. Handover
3. SRVCC PS to CS Request
Required
4. Handover Request/Ack
5. Initiation of Session Transfer

6. SRVCC PS to CS Response Session transfer and
7. Handover update remote end
8. HO from Command
E-UTRAN Release of IMS access leg
Command
UE changes to target
system, i.e. to GERAN
9. Handover Complete
10. SRVCC PS to CS Complete Notification
11. SRVCC PS to CS Complete Acknowledge
185
1. Le UE reporte des mesures au eNodeB

2. Un handover SRVCC est alors décidé. Il est notifié au MME par Handover Required
3. Basé sur les QCI on sépare les flux PS des flux CS (QCI 1 pour la voix) et on initie un handover
hybride PS-CS. Le MME envoie le message SRVCC PS to CS Request (STN-SR, MSISDN,
generic Source to Target Transparent Container, MM Context) au MSC Server. C’est l’identifiant
de la cellule non E-UTRAN qui permet au MME de sélectionner le MSC Server. Les informations
STN-SR (Session Transfer Number for SR-VCC) et MSISDN sont obtenues par le MME
directement du HSS. Elles font des informations essentielles du profil de l’abonné.
4. Le MSC Server et le BSS gèrent la logique de handover par les échanges: Handover Request/
Acknowledge.
5. En parallèle de ce basculement radio un basculement d’appel est préparé. Le MSC Server initie
le transfert de la session en envoyant le STN-SR vers le monde IMS. Selon le degré d ’évolution
du MSC Server cet envoi peut être un message SIP ou bien un message ISUP IAM (STN-SR).
C’est la que le SR-VCC AS va agir et aider à exécuter le transfert..
6. Le handover radio se poursuit par le retour vers le MME du message SRVCC PS to CS
Response (Target to Source Transparent Container)
7 & 8. Coté E-UTRAN la logique Handover Command (Target to Source Transparent Container) se
prolonge via le eNodeB jusqu’au UE
9. Une fois le UE basculé dans le monde GERAN/UTRAN, Target BSS envoie un Handover
Complete message a son MSC Server.
10 & 11. Ce dernier prévient le MME par SRVCC PS to CS Complete Notification du succès global
de cette logique de handover radio
185
5. Quelques Compléments
eMBMS, SON & Home-eNodeB
186
186
e-MBMS (1)
Le but de MBMS (Multicast Broadcast Multimedia System) est

d’assurer une logique de délivrance multicast radio pour certains
services. Typiquement c’est la TV qui est en ligne de mire.
Déjà imaginé avec l’UMTS, avec un faible succès, il revient avec

LTE sous le nom d’ e-MBMS.
Zone MBMS
Content Provider eMBMS

Multicast eBM-SC
Gateway
Broadcast source
187
187
e-MBMS (2)
Cela se traduit par une modification de l’architecture et
l’introduction de deux fonctions: MCE et MBMS-GW venant
s’immiscer dans l’architecture du LTE.
188
Multi-cell/multicast Coordination Entity (MCE)

Le MCE est une entité logique dont les fonctions sont l’allocation des
ressources radio utilisées par tous les eNBs dans la zone MBMS.
En plus de l’allocation des ressources radio temps/fréquence, cela inclut
aussi les détails de la configuration radio, i.e. la modulation et le schéma
de codage.
Le MCE est impliqué dans la signalisation MBMS Session Control
Signalling.
Par contre, le MCE ne fait pas de signalisation UE - MCE.
E-MBMS Gateway (MBMS GW)

Le MBMS GW est une entité logique qui est présente entre le eBM-SC et
les eNBs dont les fonctions sont l’envoi et la diffusion des paquets MBMS
avec protocole SYNC vers chaque eNB transmettant le service.
Le MBMS GW héberge la couche PDCP du user plane et utilise IP
Multicast comme moyen pour transférer les data MBMS utilisateur au
eNB.
Le MBMS GW effectue la signalisation MBMS Session Control Signalling
(Session start/stop) vers l’ E-UTRAN.
188
e-MBMS (3)
Coté radio, on invente le

MBSFN (Multicast Broadcast
Single Frequency Network) ou
l’art et la manière d’utiliser la
même fréquence partout. Vu la
grande durée des symboles si
les eNodeB sont synchronisés
on force une forme de
multitrajet: le SIMULCAST
En réservant périodiquement
au plus 6 sous trames d’une
trame LTE on se dote de la
capacité MBMS.
189
189
SON (1)
MME
Les concepts Self Organizing
Networks (SON) sont inclus O&M
MME
dans les standards LTE (E- Certification & System
UTRAN) prenant en compte Registration
différents aspects de l ’auto-
Authority Auto S1 4
configuration de l ’eNodeB.
Setup 5 Auto SW & configuration
3 download
Authentication & public key
certificated download Auto X2 Setup
6
eNodeB eNodeB
IP address
allocation
2
1 Auto connect to Backhaul
DHCP
Server
Backhaul
190
SON (Self Organizing / Optimizing Network) est un ensemble de

fonctionnalités mis en avant par l’intermédiaire de la normalisation LTE
afin de permettre au eNode des forme de :
• Self Configuration
• Self Optimisation
• Self Protection
• Self Healing
C’est un chantier radio très ambitieux dans lequel différentes

fonctionnalités ont été imaginées et standardisées.
190
SON (2)
Sous couvert de SON de nombreux thèmes on été explorés:
• Vérifier la cohérence du paramétrages des eNodeB par

échanges X2 (Identités Cellule/Liste des Cellules Voisines)
• S’aider des UE pour auto-découvrir des cellules voisines

(ANR: Automatic Neighboring Relation)
• Optimiser le Handover
• Enrichir les statistiques par la vision UE (RACH, RLF, …)
• Cordonner les actions de scheduling (ICIC: Inter Cell

Interference Coordination)
SON permet de revisiter l’OMC
191
191
Home eNodeB (1)
Et si votre Access Point personnel n’était plus WiFi mais LTE ? C’est ce que
permet le Home eNodeB. On parle aussi de FemtoCell.
Cette option est une aide pour les opérateurs car cela permet de décharger le
réseau principal mais c’est également une nuisance potentielle. En effet des cas
d’interférence mutuelles sont à traiter entre le réseau macro.
Cet équipement permet d’accéder au Cœur de Réseau mais on peut imaginer un

accès plus direct sans passer par la circuiterie habituelle SGW/PGW. Cette
solution s’appelle LIPA: Local IP Access. Elle consiste à intégrer SGW/PGW
dans la Femto pour privilégier un accès IP plus directe mais toujours sous le
contrôle du MME.
192
Ces histoires de FemtoCells ne sont pas apparues avec LTE. C’est en réalité une
aventure qui a commencée au début des années 2000 avec le concept UMA
(Unlicensed Mobile Access) revisité GAN (Generic Access Network) par le 3GPP.
L’objet d’UMA/GAN était de permettre la connectivité d’une borne WiFi au cœur de
réseau 2G/3G. L’introduction d’une Gateway intermédiaire (UMA/GAN GW) fut
proposée agissant comme un BSC/RNC au yeux du cœur de réseau 2G/3G et
comme un point d’accès IP aux yeux du mobile cherchant à rejoindre son cœur de
réseau. La solution ePDG proposée en LTE dérive indirectement de ces travaux, à
la différence près que l’ePDG est un élément du cœur de réseau alors que
l’UMA/GAN fait partie est du coté RAN.
Quand la technologie UMTS est devenue attractive en terme de débits grâce aux
nouveautés HSPA l’idée fut alors de substituer HSPA à WiFi au niveau de la borne
locale: les FemtoCells étaient nées. Elles se sont alors intégrées au réseau cœur
2G/3G via des UMA/GAN Gateway revisitées pour les besoins de ces nouvelles
entités. Les Home eNodeB et l’architecture associée s’inspire directement de cela.
192
Home eNodeB (2)
LGW
LIPA
L’accès à la Femto peut être fermé ou ouvert (notion de CSG: Closed

Subscriber Group)
Un équipement optionnel HeNB GW peut être introduit sur le chemin HeNB –

MME. Il peut servir de concentrateur et apparait comme un HeNB aux yeux de
du MME et comme un MME aux yeux de l’HeNB.
A noter que le standard prévoit l’ interface X2 entre Femtocells et Macrocell.

193
193
6. Eléments d’Ingénierie Radio
194
194
Performances (1)
DOWNLINK:
UPLINK:
195
195
Performances (2)
196
196
Performances (1)
LTE UL Throughput v.s. SNR, max 4HARQ Tx, EPedB-3km
40000
MCS = 0 MCS = 1
MCS = 2 MCS = 3
MCS = 4 MCS = 5
35000
MCS = 6 MCS = 7
MCS = 8 MCS = 9
MCS = 10 MCS = 11
30000 MCS = 12 MCS = 13
MCS = 14 MCS = 15
MCS = 16 MCS = 17
MCS = 18 MCS = 19
Throughput (kbps)
25000
MCS = 20 MCS = 21
MCS = 22 MCS = 23
MCS = 24 MCS = 25
20000
MCS = 26 MCS = 27
MCS = 28 T'put (kbps)
15000
 SNR 
10000
C = αWlog2  1 + 
5000  β 
0
-10 -5 0 5 10 15 20 25 30
SINR (dB)
197
197
Frequency Reuse
Comment planifier un tel système ?
Des spectres différents ?

Schéma FR > 1 On
améliore le SNR en
bordure mais on réduit la
bande.
Le même spectre partout ?
Schéma FR1 Mauvais SNR
en bordure
Le même spectre partout mais avec des sous

spectres que l’on utilisent en fonction de la
localisation du UE. Schémas FFR/SFR Compromis
FR1 – FR>1
On peut vouloir via X2 rendre dynamique les schémas

FFR/SFR. Solutions ICIC (Inter Cell Interference
Coordination)
198
198
LKB & Capacité
UL Rates
Puissance UE: 200mW
(23dBm) 128kbps (3RB)
256kbps (5RB)
512kbps (10RB)
RangeUL
8623kbps (50RB)
3921kbps (50RB)
1323kbps (50RB)
DL Rates
Puissance eNodeB typiques:
2x10W(1.4 MHz), 2x20W(3.0 & 5.0 MHz)

2x30W(10MHz) & 2x40W(>10 MHz)
199
199
LKB & Capacité (2)
Quelques exemples
200
200
7. L’évolution 4G LTE Advanced
201
201
O
atio
n MIM
g DL
ggr e
d UL /
r i er A a nce
Ca r Adv
e
a y Nod
Rel
P
COM
202
202
4G Target = 1Gbps
De la Release 8 LTE à la Release 10 LTE-A:
• DL: 300 Mbps x 2 (MIMO 8x8) x 5 (100 MHz) = 3 Gbps
• UL: 75 Mbps x 4 (MIMO 4x4) x 5 (100 MHz) = 1.5 Gbps
203
203
Carrier Aggregation
Intra-Band
Contiguous
Frequency Band A Frequency Band B
Intra-Band
Non Contiguous
Inter-Band
Les 100 MHz sont possibles par la concaténation

de 5 systèmes LTE (20 MHz)
Les schémas d’agrégation peuvent être
symétriques/asymétriques
204
204
MIMO Avancé
DL MIMO Evolutions
UL MIMO Evolutions
205
205
LTE-A Catégories UE
Category 6 Category 7 Category 8

DL (Mbps) 300 300 3000
UL (Mbps) 50 150 1500
DL QAM-64 QAM-64 QAM-64
Modulation
UL QAM-16 QAM-64 QAM-64
Modulation
Number of 4 4 8
DL Streams
Number of 1 2 4
UL Streams
206
206
COMP (1)
Aussi bien en DL qu’en

UL, COMP propose des
schémas ou les eNodeB
coopèrent très fortement
207
207
COMP (2)
Cette coopération permet

de revisiter totalement la
structure de l’ingénierie
RAN en centralisant les
actions de scheduling
208
208
Noeud Relais
Un eNodeB vu comme un UE
par le eNodeB principal c’est
un Relay Node.
Permet d’offrir ainsi par le lien

UE(RN) – Master eNodeB
une connectivité vers l’ePC.
209
209
8. Pour Conclure
210
210
Le futur réseau mobile 4G s ’appelle l ’EPS.
Son réseau d ’accès est nommé LTE (3,99G) avec son évolution
appelé LTE-Advanced (4G). Le terme eUTRAN est aussi utilisé.
Son réseau cœur, l ’ePC est un réseau tout IP. Le terme SAE est
aussi utilisé.
L ’ensemble LTE+ePC est l ’EPS. Il s ’agit d ’un réseau d ’accès
large bande qui offre une connectivité au monde Internet/Intranet,
avec QoS, avec mobilité, et pouvant supporter la fonctionnalité
multicast.
Afin de contrôler les flux IP du client et taxer les flux autorisés, une
architecture PCC est mise en œuvre.
Les services proposés au client sont tous mis en œuvre dans le
monde IP. L ’IMS est l ’architecture long terme pour offrir les
services multimédia incluant la voix et le SMS.
Deux solutions alternatives existent pur offrir les services « circuit »
: double rattachement et CS-Fallback. 211
211
Plusieurs nouveautés en préparation:
QAM-128 & QAM-256
PROSE
GCSE
212
212
Annexes
213
213
SA1
TS 22.011 Service accessibility
TS 22.168 Earthquake and Tsunami Warning System (ETWS) requirements
TS 22.220 Service requirements for Home Node B (HNB) and Home eNode B (HeNB)
TS 22.268 Public Warning System (PWS) requirements Rel-9
TS 22.278 Service requirements for the EPS
SA2
TS 23.002 Network architecture
TS 23.060 GPRS; Service description; Stage 2
TS 23.203 PCC architecture
TS 23.216 Single Radio Voice Call Continuity (SRVCC); Stage 2
TS 23.221 Architectural requirements
TS 23.236 Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes
TS 23.272 Circuit-Switched (CS) fallback in EPS; Stage 2
TS 23.401 GPRS enhancements for E-UTRAN access
TS 23.402 Architecture enhancements for non-3GPP accesses
SA3
TS 33.401 3GPP SAE; Security architecture
TS 33.402 3GPP SAE; Security aspects of non-3GPP accesses
CT1
TS 23.003 Numbering, addressing and identification
TS 23.122 Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode
TS 24.301 NAS protocol for EPS; Stage 3
TS 24.302 Access to the EPC via non-3GPP access networks; Stage 3
TS 24.303 Mobility management based on Dual-stack Mobile IPv6; Stage 3
TS 24.304 Mobility management based on MIPv4; User Equipment (UE)-foreign agent interface; Stage 3
TS 24.312 Access Network Discovery and Selection Function (ANDSF) Management Object (MO)
CT3 and CT4
TS 29.002 Mobile Application Part (MAP)
TS 29.060 GPRS; GTP across the Gn and Gp interfaces
TS 29.061 Interworking between the Public L and Mobile Network (PLMN) supporting PS services and PDN
TS 29.118 Mobility Management Entity (MME)-Visitor Location Register (VLR) SGs interface specification
TS 29.168 Cell Broadcast Centre interfaces with the EPC; Stage 3
TS 29.210 Charging rule provisioning over Gx interface
TS 29.211 Rx interface and Rx/Gx signalling flows ?
TS 29.212 PCC over Gx reference point
TS 29.213 PCC signalling flows and QoS parameter mapping
TS 29.214 PCC over Rx reference point
TS 29.215 PCC over S9 reference point
TS 29.230 Diameter applications; 3GPP specific codes and identifiers
TS 29.272 EPS; MME and SGSN-related interfaces based on Diameter protocol
TS 29.273 EPS; 3GPP EPS AAA interfaces
TS 29.274 3GPP EPS; Evolved GPRS Tunnelling Protocol for Control plane (GTPv2-C); Stage 3
TS 29.275 PMIPv6-based Mobility and Tunnelling protocols; Stage 3
TS 29.276 Optimized Handover Procedures and Protocols between E-UTRAN Access and cdma2000 Access
TS 29.277 Optimized Handover Procedures and Protocols between E-UTRAN Access and 1xRTT Access
TS 29.279 MIPv4-based Mobility protocols; Stage 3
TS 29.280 EPS; 3GPP Sv interface (MME to MSC, and SGSN to MSC) for SRVCC
TS 29.281 GPRS Tunnelling Protocol User Plane (GTPv1-U)
TS 29.303 Domain Name System Procedures; Stage 3
TS 29.304 MIPv4-based Mobility protocols; Stage 3
TS 29.305 Interworking Function (IWF) between MAP-based and Diameter-based interfaces
214
E-UTRAN (RAN1-5)
TS 36.101 E-UTRA; UE radio transmission and reception
TS 36.104 E-UTRA; Base Station (BS) radio transmission and reception
TS 36.106 E-UTRA; FDD repeater radio transmission and reception
TS 36.113 E-UTRA; BS and repeater Electromagnetic Compatibility (EMC)
TS 36.124 E-UTRA; EMC requirements for mobile terminals and ancillary equipment
TS 36.133 E-UTRA; Requirements for support of radio resource management
TS 36.141 E-UTRA; BS conformance testing
TS 36.143 E-UTRA; Repeater conformance testing
TS 36.201 E-UTRA; LTE physical layer; General description
TS 36.211 E-UTRA; Physical channels and modulation
TS 36.212 E-UTRA; Multiplexing and channel coding
TS 36.213 E-UTRA; Physical layer procedures
TS 36.214 E-UTRA; Physical layer measurements
TS 36.300 E-UTRA and E-UTRAN; Overall description; Stage 2
TS 36.302 E-UTRA; Services provided by the physical layer
TS 36.304 E-UTRA; UE procedures in idle mode
TS 36.306 E-UTRA; UE radio access capabilities
TS 36.314 E-UTRAN; Layer 2 measurements
TS 36.321 E-UTRA; Medium Access Control (MAC) protocol specification
TS 36.322 E-UTRA; Radio Link Control (RLC) protocol specification
TS 36.323 E-UTRA; Packet Data Convergence Protocol (PDCP) specification
TS 36.331 E-UTRA; Radio Resource Control (RRC); Protocol specification
TS 36.401 E-UTRAN; Architecture description
TS 36.410 E-UTRAN; S1 layer 1 general aspects and principles
TS 36.411 E-UTRAN; S1 layer 1
TS 36.412 E-UTRAN; S1 signalling transport
TS 36.413 E-UTRA; S1 Application Protocol (S1AP)
TS 36.414 E-UTRAN; S1 data transport
TS 36.420 E-UTRAN; X2 general aspects and principles
TS 36.421 E-UTRAN; X2 layer 1
TS 36.422 E-UTRAN; X2 signalling transport
TS 36.423 E-UTRAN; X2 Application Protocol (X2AP)
TS 36.424 E-UTRAN; X2 data transport
TS 36.440 E-UTRAN; General aspects and principles for interfaces supporting MBMS
TS 36.441 E-UTRAN; Layer 1 for interfaces supporting MBMS within E-UTRAN
TS 36.442 E-UTRAN; Signalling Transport for interfaces supporting MBMS within E-UTRAN
TS 36.443 E-UTRAN; M2 Application Protocol (M2AP)
TS 36.444 E-UTRAN; M3 Application Protocol (M3AP)
TS 36.445 E-UTRAN; M1 Data Transport
TS 36.446 E-UTRAN; M1 User Plane protocol
TS 36.508 E-UTRA and EPC; Common test environments for UE conformance testing
TS 36.509 E-UTRA; Special conformance testing function for UE
TS 36.521-1 E-UTRA; UE conformance specification; Radio transmission and reception; Part 1: Conformance testing
TS 36.521-2 E-UTRA; UE conformance specification; Radio transmission and reception; Part 2: Implementation
TS 36.521-3 E-UTRA; UE conformance specification; Radio transmission and reception; Part 3: Radio Resource Mngt
TS 36.523-1 E-UTRA and E-UTRAN; UE conformance specification; Part 1: Protocol conformance specification
TS 36.523-2 E-UTRA and E-UTRAN; UE conformance specification; Part 2: ICS
TS 36.523-3 E-UTRA and E-UTRAN; UE conformance specification; Part 3: Abstract Test Suites (ATS)
TR 36.801 E-UTRA; Measurement requirements
TR 36.803 E-UTRA; UE radio transmission and reception
TR 36.804 E-UTRA; BS radio transmission and reception
TR 36.814 Further advancements for E-UTRA Physical layer aspects
TR 36.902 E-UTRAN; Self-configuring and self-optimizing network (SON) use cases and solutions
TS 36.903 E-UTRA; Derivation of test tolerances for multi-cell Radio Resource Management (RRM) conformance tests
TR 36.913 Requirements for further advancements for E-UTRA (LTE-Advanced)
TR 36.938 E-UTRAN; Improved network-controlled mobility between E-UTRAN and 3GPP2/mobile WiMAX
TR 36.942 E-UTRA; Radio Frequency (RF) system scenarios
TR 36.956 E-UTRA; Repeater planning guidelines and system analysis
215
IETF documents
RFC 768: User Datagram Protocol
RFC 793: Transmission Control Protocol
RFC 2003: IP Encapsulation within IP
RFC 2401: Security Architecture for the Internet Protocol
RFC 2402: IP Authentication Header
RFC 2406: IP Encapsulating Security Payload (ESP)
RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP
RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409: The Internet Key Exchange (IKE)
RFC 2473: Generic Packet Tunnelling in IPv6 Specification
RFC 2784: Generic Routing Encapsulation (GRE)
RFC 2890: Key and Sequence Number Extensions to GRE
RFC 2960: Stream Control Transmission Protocol (SCTP)
RFC 3309: SCTP Checksum Change
RFC 3344: IP Mobility Support for IPv4
RFC 3748: Extensible Authentication Protocol (EAP)
RFC 3775: Mobility Support in IPv6
RFC 3776: Using IPsec to Protect MIPv6 Signalling between Mobile Nodes and Home Agents
RFC 3588: Diameter Base Protocol
RFC 4005: Diameter Network Access Server Application
RFC 4006: Diameter Credit-Control Application
RFC 4072: Diameter EAP Application
RFC 4186: EAP Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
RFC 4187: EAP Method for Third Generation Authentication and Key Agreement (EAP-AKA)
RFC 4285: Authentication Protocol for MIPv6
RFC 4301: Security Architecture for the Internet Protocol
RFC 4302: IP Authentication Header
RFC 4303: IP Encapsulating Security Payload (ESP)
RFC 4306: Internet Key Exchange (IKEv2) Protocol
RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4877: MIPv6 Operation with IKEv2 and the Revised IPsec Architecture
RFC 4960: SCTP
RFC 5213: PMIPv6
RFC 5216: The EAP-TLS Authentication Protocol
216
0–9
2G 2nd Generation
3G 3rd Generation
3GPP Third Generation Partnership Project
3GPP2 Third Generation Partnership Project 2
A
AAA Authentication, Authorization and Accounting
ABMF Account Balance Management Function
AF Application Function
AH Authentication Header
AKA Authentication and Key Agreement
AMBR Aggregate Maximum Bit Rate
AN Access Network
ANDSF Access Network Discovery and Selection Function
AP Application Protocol
API Application Programming Interface
APN Access Point Name
APN-NI APN Network Identifier
APN-OI APN Operator Identifier
ARIB Association of Radio Industries and Businesses (Japan)
ARP Allocation and Retention Priority
ARQ Automatic Repeat ReQuest
AS Application Server
ASME Access Security Management Entity
ATIS Alliance for Telecommunications Industry Solutions
ATM Asynchronous Transfer Mode
AuC Authentication Centre
AUTN Authentication Token
AV Authentication Vector
AVP Attribute Value Pair
B
BBERF Bearer Binding and Event Reporting Function
BGCF Breakout Gateway Control Function
BRA Binding Revocation Acknowledgement
BRI Binding Revocation Indication
BS Base Station
BSC Base Station Controller
BSS Base Station Subsystem
C
CAMEL Customized Application for Mobile network Enhanced Logic
CAP CAMEL Application Part
CCSA China Communications Standards Association
CDF Charging Data Function
CDMA Code Division Multiple Access
CDR Charging Data Records
CGF Charging Gateway Function
CGI Cell Global Identity
CHAP Challenge Handshake Authentication Protocol
CK Cipher Key
CN Core Network; Correspondent Node
CS Circuit-Switched
CSCF Call Session Control Function
CSFB Circuit Switched Fall Back
CTF Charging Trigger Function
217
D
DCCA Diameter Credit Control Application
DHCP Dynamic Host Configuration Protocol
DL DownLink
DM Device Management
DNS Domain Name System
DPI Deep Packet Inspection
DRA Diameter Routing Agent
DRX Discontinuous Reception
DSCP DiffServ Code Point
DSL Digital Subscriber Line
DTF Domain Transfer Function
DTX Discontinuous Transmission
E
EAP Extensible Authentication Protocol
ECM EPS Connection Management
EDGE Enhanced Data rates for GSM Evolution
eHRPD Evolved High Rate Packet Data
EIR Equipment Identity Register
eMBMS Evolved Multicast Broadcast Multimedia Service
EMM EPS Mobility Management
eNB E-UTRAN NodeB
EPC Evolved Packet Core
ePDG Evolved Packet Data Gateway
EPS Evolved Packet System
E-RAB E-UTRAN Radio Access Bearer
ESM EPS Session Management
ETSI European Telecommunications Standards Institute
ETWS Earthquake and Tsunami Warning System
EV-DO Evolution - Data Only
F
FDD Frequency Division Duplex
FEC Forward Error Correction
G
GBR Guaranteed Bit Rate
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GRE Generic Routing Encapsulation
GRX GPRS Roaming eXchange
GSM Global System for Mobile communications
GSMA GSM Association
GSN GPRS Support Node
GTP GPRS Tunnelling Protocol
GTP-C GPRS Tunnelling Protocol for Control Plane
GTP-U GPRS Tunnelling Protocol for User Plane
GUMMEI Globally Unique MME Identifier
GUTI Globally Unique Temporary Identifier
GW Gateway
218
H
HA Home Agent
HLR Home Location Register
HO Handover
HoA Home Address
H-PCRF Home PCRF
HPLMN Home Public Land Mobile Network
HRPD High Rate Packet Data
HSDPA High Speed Downlink Packet Access
HSGW HRPD Serving Gateway
HSPA High Speed Packet Access
HSS Home Subscriber Server
HSUPA High Speed Uplink Packet Access
I
IANA Internet Assigned Numbers Authority
ICMP Internet Control Message Protocol
I-CSCF Interrogating-CSCF
IEEE Institute of Electrical and Electronics Engineers
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IK Integrity key
IKEv1 Internet Key Exchange version 1
IKEv2 Internet Key Exchange version 2
IMEI International Mobile Equipment Identity
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IPSec IP Security
ISDN Integrated Services Digital Network
ISP Internet Service Provider
ITU International Telecommunication Union
IWF Interworking Function
L
LA Location Area
LAC Location Area Code
LAN Local Area Network
LI Lawful Intercept
LTE Long-Term Evolution
219
M
M2M Machine-to-Machine
MAG Mobile Access Gateway
MAP Mobile Application Part
MBMS Multimedia Broadcast Multicast Service
MCC Mobile Country Code
MGCF Media Gateway Control Function
MGW Media Gateway
MIMO Multiple Input, Multiple Output
MIP Mobile IP
MIPv4 Mobile IPv4
MIPv6 Mobile IPv6
MM Mobility Management
MME Mobility Management Entity
MMEC MME Code
MMEGI MME Group Identifier
MMEI MME Identifier
MMS Multimedia Messaging Service
MMTel MultiMedia Telephony
MN Mobile Node
MNC Mobile Network Code
MPLS Multi-Protocol Label Switching
MRFC Media Resource Function Controller
MRFP Media Resource Function Processor
MS Mobile Station
MSC Mobile Switching Centre
MSC-S MSC Server
MSIN Mobile Subscriber Identification Number
MSISDN Mobile Subscriber ISDN Number
N
NAI Network Access Identifier
NAS Non-Access Stratum; Network Access Server
NAT Network Address Translation
NB NodeB
NW Network
O
OCF Online Charging Function
OCS Online Charging System
OFDM Orthogonal Frequency Division Multiplexing
OFCS Offline Charging System
OMA Open Mobile Alliance
P
PC Personal Computer
PCC Policy and Charging Control
PCEF Policy and Charging Enforcement Function
PCRF Policy and Charging Rules Function
P-CSCF Proxy-CSCF
PDCP Packet Data Convergence Protocol
PDN Packet Data Network
PDN GW Packet Data Network Gateway
PDP Packet Data Protocol
PDU Protocol Data Unit
P-GW PDN GW
PIN Personal Identification Number
PLMN Public Land Mobile Network
PS Packet-Switched 220
Q
QAM Quadrature Amplitude Modulation
QCI QoS Class Identifier
QoS Quality of Service
R
RAB Radio Access Bearer
RAC Routing Area Code
RADIUS Remote Authentication Dial In User Service
RAI Routing Area Identity
RAN Radio Access Network
RANAP Radio Access Network Application Protocol
RAT Radio Access Technology
RAU Routing Area Update
Rel-8 Release 8
Rel-9 Release 9
Rel-99 Release 99
RF Rating Function
RFC Request For Comments
RLC Radio Link Control
RNC Radio Network Controller
RRC Radio Resource Control
RRM Radio Resource Management
RTSP Real Time Streaming Protocol
S
SA Security Association
SAE System Architecture Evolution
SCC AS Service Centralization and Continuity Application Server
S-CSCF Serving-CSCF
SCTP Stream Control Transmission Protocol
SDF Service Data Flow
SDP Session Description Protocol
SEG Security Gateway
SGSN Serving GPRS Support Node
S-GW Serving GW
SIM GSM Subscriber Identity Module
SIP Session Initiation Protocol
SLA Service Level Agreement
SMS Short Message Service
SMS-C Short Message Service Centre
SPR Subscription Profile Repository
SQN Sequence Number
SRVCC Single-Radio Voice Call Continuity
SS7 Signalling System No 7
SSID Service Set Identifier
221
T
TA Tracking Area
TAC Tracking Area Code
TAI Tracking Area Identity
TAP Transferred Account Procedure
TAU Tracking Area Update
TCP Transmission Control Protocol
TDD Time Division Duplex
TDMA Time-Division Multiple Access
TEID Tunnel End Point Identifier
TFT Traffic Flow Template
TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking
TLS Transport Layer Security
TMSI Temporary Mobile Subscriber Identity
TOS Type of Service
TR Technical Report
TS Technical Specification
TSG Technical Specification Group
TTA Telecommunication Technology Association of Korea
TTC Telecommunication Technology Committee (Japan)
U
UDP User Datagram Protocol
UE User Equipment
UICC Universal Integrated Circuit Card
UL UpLink
UMTS Universal Mobile Telecommunications System
USB Universal Serial Bus
USIM Universal Subscriber Identity Module
UTRAN Universal Terrestrial Radio Access Network
V
VCC Voice Call Continuity
VoIP Voice over IP
V-PCRF Visited PCRF
VPLMN Visited Public Land Mobile Network
VPN Virtual Private Network
W
WCDMA Wideband Code Division Multiple Access
WG Working Group
WiMAX Worldwide Interoperability for Microwave Access
WLAN Wireless Local Area Network
X
XRES eXpected RESult
222

Lte Fondamentaux

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Lte Fondamentaux

Transféré par

Droits d'auteur :

Formats disponibles

Les Fondamentaux du LTE

1. Introduction: Contexte de la normalisation LTE

Contexte de la normalisation LTE

IS136 (US) GPRS (Europe) CDMA2000(3GPP2) HSUPA(3GPP)

TETRA (Europe) TETRA-TEDS (Europe)

Solutions TETRAPOL (Europe) LTE en Overlay LTE-R ???

Cordless Backhaul BLR

802.16 802.16a Mobilité 4G Evolution

La 4ème génération: OFDMA (Orthogonal Frequency Division Multiple Access) sera

2000 2001 2002 2003 2004 2005 2006

2007 2008 2009 2010 2011 2012 2013

Release Evolution à l’accès Evolution dans le réseau cœur

R99 Nouveau réseau d’accès Nouveaux commutateurs MSC

Technologie Débit descendant Débit montant Canal

Dans le contexte 3G, il s’agit du temps de transmission des

Dans le contexte LTE, il s’agit du temps de transmission des

La latence a une incidence majeure sur l’expérience utilisateur. En particulier, les

RTC RTC IP RTC IP

Accès Accès Accès

Architecture 2G Architecture Evolution 2G/3G

RTC IMS IP IMS IP

BTS PCU SSP SS7/TDM

UMTS (Universal Mobile Telecommunications System) aussi appelé 3G introduit une

le réseau pour le repérer

Lorsqu’un abonné souscrit à un abonnement mobile 3G auprès d ’un opérateur, il reçoit un

SGSN GGSN1 ISP X

PDP Context X1 (APN X, IP address X, QoS1)

Un contexte PDP est un ensemble d'information qui caractérise un service de transmission de

IP TCP/UDP GTP IP TCP/UDP

Contient l’identifiant du tunnel (TEID)

DiffServ ou Differentiated Services est une architecture qui spécifie un

Interface Label Interface Label

Interface Label Interface Label

MultiProtocol Label Switching (MPLS) est un mécanisme de transport de données basé

SCTP, ou Stream Control Transmission Protocol (RFC 4960) est un protocole de

5.976 Milliards de souscriptions GSM-WCDMA-HSPA dans le

Evolution to LTE report (GSA) – 18 Décembre 2013 - http://www.gsacom.com

L’accès large bande mobile permettant des usages nouveaux

EIR HSS Cx, Sh

Interface Air & e-UTRAN

1.4 MHz 3.0 MHz 5.0 MHz 10.0 MHz

15.0 MHz 20.0 MHz

L’interface radio E-UTRAN doit pouvoir supporter un débit maximum descendant

Alternative aux systèmes 3GPP existants

La technologie 4G peut fonctionner avec de nombreuses bandes de fréquences

LTE possède à priori deux points d’ancrage principaux:

L’OFDM consiste simplement en une mise en parallèle de plusieurs sous porteuses

En fonction de la bande à occuper plus ou moins de porteuses peuvent être

(N nombre de sous porteuses – M nombre de points pris pendant la durée du temps

*: Chaine RF = Tx {Conversion N/A Ampli Filtre} + Rx {Filtre Conversion A/N}

En tout cas le débit produit n’augmente ni ne diminue pas.

Avec un schéma de transmission conventionnel N symboles sont émis en une durée

Symboles courts Hauts Débits ISI si Multitrajet

Pour éliminer complètement l’ISI

L’ISI (Inter Symbol Interference) dépend de la durée du symbole et de la structure

Durée moyenne de l’évanouissement

On connaît la puissance moyenne σ2 de la trajectoire

On fixe un seuil R et on calcule là moyenne des temps

Profondeur moyenne de l’évanouissement.

Band 2500 Mhz 3500 Mhz 5000 Mhz

Et l’on voit alors l’intérêt que pourrait avoir une gestion

IDEE de BASE: allouer les ressources en fonction des

La dimension multi trajet a laquelle s’ajoute la dimension de mobilité crée entre

= 1200615000 = 108 Mbps