Support de Cours LTE - SII

Etudes et FORmations en Tlcommunication
GPRS, (LTE + ePC = EPS), PCC, IMS

Simon ZNATY, EFORT
sznaty@efort.com http://www.efort.com
Simon ZNATY
Copyright EFORT
Le nombre dabonns un rseau mobile via LTE/ePC (Long Term Evolution / Evolved Packet Core) va connatre un vritable boom dans les prochaines annes. Le cabinet dtudes et de conseil Pyramid Research prvoit un taux annuel moyen de croissance de 404 % entre 2010 et 2014, pour atteindre les 136 millions dabonns fin 2014. Les autres normes de tlphonie mobile nont pas connu un tel essor, y compris la norme UMTS/HSPA. La LTE est un projet men par l'organisme de standardisation 3GPP visant rdiger les normes techniques de la future quatrime gnration en tlphonie mobile. Elle permet le transfert de donnes trs haut dbit, avec une porte plus importante, un nombre dappels par cellule suprieur (zone dans laquelle un metteur de tlphonie mobile peut entrer en relation avec des terminaux) et une latence plus faible. En thorie, elle permet datteindre des dbits de lordre de 50 Mbit/s en lien ascendant et de 100 Mbit/s en lien descendant, partager entre les utilisateurs mobiles d'une mme cellule. Pour les oprateurs, la LTE implique de modifier le cur du rseau et les metteurs radio. Il faut galement dvelopper des terminaux mobiles adapts. En terme de vocabulaire, le futur rseau sappelle EPS (Evolved Packet system). Il est constitu dun nouveau rseau daccs appel LTE (Long Term Evolution) et dun nouveau rseau cur appel ePC (Evolved Packet Core) aussi appel SAE (System Architecture Evolution). Lobjectif de ce cours est dintroduire la vision de bout en bout du rseau EPS avec son accs, son rseau cur, les procdures de gestion de la mobilit, de gestion de session et de handover. Comme il sagit dun rseau en mode paquet uniquement, le cours dcrit les diffrentes approches pour offrir les services auparavant supports par le domaine circuit tels que les services de tlphonie et le service SMS. L approche long terme sera l IMS (IP Multimedia Subsystem) qui fait l objet d une prsentation dtaille dans ce cours. Ce rseau EPS devra interfonctionner avec le rseau lgataire paquet, savoir GPRS (General Packet Radio Service). Le cours introduit aussi brivement le rseau GPRS.
PLAN

1. Evolution des Rseaux Mobiles 2. GPRS dans le rseau mobile

2.1. Entits GPRS 2.2. Gestion de la mobilit, gestion de session et roaming GPRS 3.1. Dfinition et Architecture de Haut Niveau 3.2. Interfaces EPS 3.3. Gestion de la Mobilit EPS 3.4. Gestion de Session EPS 3.5. Taxation EPS 3.6. Les services du domaine CS sur lEPS 4.1. Dfinition dIMS 4.2. Entits IMS 4.3. Enregistrement IMS, Etablissement de sessions IMS 4.4. SMS avec IMS
Copyright EFORT
3. LTE + ePC = EPS

4. IP Multimedia Subsystem

Simon ZNATY
1. Evolution des Rseaux Mobiles
Simon ZNATY
Copyright EFORT
Il existe 4 standards pour les systmes 2G: le GSM (Global System for Mobile communications) et ses drivs; digital AMPS (D-AMPS); 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 succs et qui est le plus largement dploy. Dabord utilis dans la bande des 900 MHz, il a ensuite t tendu dans la bandes des 1800 MHz pour rpondre des problmatiques de saturation des frquences. Le GSM a galement t tendu hors Europe et constitue une des composantes du PCS Amricain (1900 MHz). Les drivs de la 2G Diffrentes amliorations ont t normalises: General Packet Radio Services (GPRS), Enhanced Data Rates for Global Evolution (EDGE). La 3me gnration a t normalise dabord par lETSI puis par le forum 3GPP (3G Partnership Project) en lien avec lITU (International Telecommunication Union) au travers du projet IMT-2000 qui dfinit la technique de transmission, le transport des servies IP, le roaming et les communications multimdia. Deux propositions mergent: wideband code division multiple access (WCDMA) et CDMA2000. Les drivs de la 3G : - HSDPA, High Speed Downlink Packet Access, qui est un service de donnes paquet modul en CDMA dans le sens rseau vers mobile avec des dbits potentiels de plusieurs Mbit/s (14,4 Mbit/s). Aujourdhui, toutes les zones sont dj mises niveau en France avec le HSPDA (3,6 Mbit/s). - HSUPA, High-Speed Uplink Packet Access, qui est un protocole permettant des dbits remontants extrmement levs (jusqu 5.76 Mbit/s). Dploiement fin 2007. La 4me gnration: OFDMA (Orthogonal Frequency Division Multiple Access) sera introduite dans les annes venir pour offrir des dbits allant jusqu 100 Mbits/s en dbit descendant (OFDMA) et 50 Mbit/s en dbit montant (SC-FDMA). Il faut diffrencier l accs GPRS et le rseau GPRS. Le rseau GPRS est constitu de commutateurs de paquets et sert transfrer les paquets mis depuis des accs GPRS, EDGE, W-CDMA, HSUPA ou HSDPA vers l Internet et les Intranets d entreprise. Par ailleurs ce rseau sert remettre au mobile des paquets mis par l Internet ou par les Intranets. Par contre l accs GPRS n est qu un accs possible parmi de multiples accs (GPRS, EDGE, W-CDMA, HSUPA ou HSDPA) et offre un dbit asymtrique relativement faible, gnralement, 10kbit/s dans le sens montant (du mobile au rseau) et 40 kbit/s dans le sens descendant (du rseau au mobile). EDGE qui n apparat qu l accs permet d augmenter les dbits pour les services de donnes (jusqu 200 kbit/s en dbit descendant) par rapport l accs GPRS. Le mme rseau cur GPRS supporte l accs EDGE. La 3G avec W-CDMA (Wideband Code Division Multiple Access) permet des dbits allant jusqu 384 kbit/s bidirectionnels. HSDPA (High Speed Downlink Packet Access) amliore les dbits descendants pouvant atteindre 14,4 Mbit/s et HSUPA (High Speed Uplink Packet Access) amliore les dbits montants pouvant atteindre 5,75 Mbit/s. La 4G fait apparatre un nouveau rseau cur pour les services de donnes et services conversationnels appel ePC (Evolved Packet Core). Les services conversationnels seront offerts par ePC+IMS la diffrence daujourdhui o il y a un rseau cur ddi pour offrir ces services
Accs et Rseau mobiles

Accs Rseau
2G
GSM GPRS EDGE EDGE+ W-CDMA HSDPA HSUPA HSPA+ OFDMA SC-FDMA
GSM/NGN Mobile
IMS
GPRS
Rseau IP
3G
GSM : Global System for Mobile Telecommunications 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 HSUPA : High Speed Uplink Packet Access OFDMA : Orthogonal Frequency Division Multiple Access SC-FDMA : Single Carrier FDMA ePC : Evolved Packet Core IMS : IP Multimedia Subsystem
IMS Rseau IP
4
4G
Simon ZNATY
ePC
Copyright EFORT
Le rseau mobile est constitu d un rseau d accs et d un rseau cur. Trois rseaux d accs sont possibles : 2G, 3G, 4G. Le rseau d accs 2G s appelle BSS (Base Station Subsystem). Il supporte les technologies radio GSM, GPRS et EDGE. Le rseau d accs 3G s appelle UTRAN (UMTS Terrestrial Radio Access Network). Il supporte les technologies radio W-CDMA, HSDPA, HSUPA et HSPA+. Le rseau d accs 4G s appelle LTE (Long Term Evolution of 3G). Il supporte les technologies radio OFDMA et SC-FDMA. Le rseau coeur 2G/3G consiste en deux domaines : Domaine circuit et domaine paquet. Le domaine circuit offre des services de tlphonie. Au dpart constitu de commutateurs voix, il a volu vers une structure NGN Mobile appele R4. Le domaine paquet appel GPRS (General Packet Radio Service) offre un accs plus (3G) ou moins (2G) haut dbit au monde IP et ses services. Il faut diffrencier l accs GPRS et le rseau GPRS. Le rseau GPRS est constitu de commutateurs de paquets et sert transfrer les paquets mis depuis des accs GPRS, EDGE, W-CDMA, HSUPA ou HSDPA vers l Internet et les Intranets d entreprise. Par ailleurs ce rseau sert remettre au mobile des paquets mis par l Internet ou par les Intranets. Par contre l accs GPRS n est qu un accs possible parmi de multiples accs (GPRS, EDGE, W-CDMA, HSUPA ou HSDPA) et offre un dbit asymtrique relativement faible, gnralement, 10kbit/s dans le sens montant (du mobile au rseau) et 40 kbit/s dans le sens descendant (du rseau au mobile). EDGE qui n apparat qu l accs permet d augmenter les dbits pour les services de donnes (jusqu 200 kbit/s en dbit descendant) par rapport l accs GPRS. Le mme rseau cur GPRS supporte l accs EDGE. La 3G avec W-CDMA (Wideband Code Division Multiple Access) permet des dbits allant jusqu 384 kbit/s bidirectionnels. HSDPA (High Speed Downlink Packet Access) amliore les dbits descendants pouvant atteindre 14,4 Mbit/s et HSUPA (High Speed Uplink Packet Access) amliore les dbits montants pouvant atteindre 5,75 Mbit/s. La 4G fait apparatre un nouveau rseau cur pour les services de donnes et services conversationnels appel ePC (Evolved Packet Core). Les services conversationnels seront offerts par ePC+IMS la diffrence daujourdhui o il y a un rseau cur ddi pour offrir ces services La 4G permettra des dbits allant jusqu 100 Mbit/s pour les dbits descendants avec la technologie OFDMA (Orthogonal Frequency Division Multiple Access) et 50 Mbit/s pour les dbits montants avec SC-FDMA Single Carrier Frequency Division Multiple Access).
4
Points importants de chaque Release 3G

Release
R3
Evolution laccs
Nouveau rseau daccs appel UTRAN Nouvelle technologie radio W-CDMA (384 kbit/s)
Evolution dans le rseau cur

Nouveaux commutateurs MSC supportant la voix et la vidotlphonie Nouveaux commutateur SGSN plus scalable Emulation des commutateurs MSC par NGN Mobile IMS Phase 1 pour offrir des services non temps rels IMS Phase 2 pour offrir des service temps rels (e.g., voix) IMS Phase 3 indpendant de laccs; PCC (Policy and Charging Control ; 3G Direct Tunnel (DT) Nouveau rseau cur ePC en mode paquet, Common IMS
R4 R5 R6 R7 Nouvelle technologie radio HSDPA (jusqu 14,4 Mbits) Nouvelle technologie radio HSUPA (jusqu 5,75 Mbits) Evolution EDGE (EDGE+) Evolution HSPA (HSPA+) Nouvelles technologies radio OFDMA et SC-FDMA LTE-Advanced
Copyright EFORT
R8 R10
Simon ZNATY
Release 3: Introduit le rseau daccs 3G ou UMTS appel UTRAN (UMTS Terrestrial Radio Access Network) constitu de NodeBs et de RNCs. La technologie que supporte UTRAN sappelle W-CDMA qui permet doffre des services circuit tels que la tlphonie et la visiophonie ainsi que des services de donnes avec un dbit maximum de 384 kbit/s dans les sens montant et descendant. Dans le coeud de rseau il sagit de mettre jour les MSC 2G afin quils deviennent des MSC 3G et les SGSN 2G afin quils supportent laccs 3G. Release 4: Permet dintroduire le concept NGN mobile dans le domaine circuit. Avec le passage la 3G, il est difficile de faire voluer les MSC 2G afin quils sinterconnectent avec laccs UTRAN. Les oprateurs prfrent remplacer les MSC 2G par une architecture NGN Mobile (R4) qui supporte les accs 2G ainsi que les accs 3G. Avec le NGN mobile le transport de la voix dans le domaine circuit se fait sur IP met uniquement dans le cur de rseau. Release 5: Introduit la technologie HSDPA l accs par une mise jour logicielle des Node B et RNC. Le dbit descendant devient gal 14,4 Mbit/s alors que le dbit montant reste inchang par rapport WCDMA. Les rseaux 3G dploys actuellement son principalement bass sur cette Release. L architecture IMS Phase 1 est aussi dfinie pour des services non temps -rels (e.g., prsence, messagerie, etc) et pour un accs 3G. Release 6: Introduit la technologie HSUPA l accs par une mise jour logicielle des Node B et RNC. Le dbit montant devient gal 5,75 Mbit/s. L architecture IMS Phase 2 est aussi dfinie pour des services non temps-rels (e.g., prsence, messagerie, etc) et temps rel (e.g., tlphonie) pour un accs 3G. Release 7: Les technologie HSPA+ (2 x HSPA ou 3 x HSPA) et EDGE+ (2 x EDGE) sont proposes. L architecture IMS Phase 3 est aussi dfinie pour des services non temps -rels (e.g., prsence, messagerie, etc) et temps rel (e.g., tlphonie) pour tout type d accs large bande. Il s agit de Common IMS. Release 8: Introduit les technologies pr-4G appeles OFDMA (100 Mbit/s dans le sens descendant) et SC-FDMA (50 Mbit/s dans le sens montant) pour 20 MHz de frquence. Le nouveau rseau d accs pr4G est appel LTE. La Release 8 dfinit par ailleurs un nouveau rseau cur paquet pr-4G appel ePC (Evolved Packet Core). La Release 8 finalise aussi les spcifications concernant Common IMS inities 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 frquence.
5
Dbits pour les services de donnes

Technologie GSM GPRS EDGE EDGE Evolution W-CDMA(UMTS) HSDPA HSUPA HSPA HSPA+ LTE Dbit descendant 9,6 kbit/s 41,6 kbit/s (171,2) 236,8 kbit/s (473,6) 1 Mbit/s (1,9 Mbit/s) 384 kbit/s 1 Mbit/s (14,4 Mbit/s) 1 Mbit/s (14,4 Mbit/s) 2 Mbit/s (43,2 Mbit/s) 6 Mbit/s (100 Mbit/s) Dbit montant 9,6 kbit/s 20,8 kbit/s (171,2) 50 kbit/s (473,6 kbit/s) 500 kbit/s (1 Mbit/s) 384 kbit/s 1 Mbit/s (5,75 Mb/s) 1 Mbit/s (5,75 Mb/s) 2 Mbit/s (23 Mbit/s) 6 Mbit/s (50 Mbit/s)
Bande de frquence
200 kHz 200 kHz 200 kHz 200 kHz 5 MHz 5 MHz 5 MHz 5 MHz 5 MHz 20 MHz
Simon ZNATY
Copyright EFORT
GPRS peut transporter le trafic de donnes de lusager des dbits de 41,2 kbits dans le sens descendant avec 4 timeslots (le dbit maximum thorique est de 171,2 kbit/s pour 8 timeslots oprant chacun 21,4 kbit/s). En mode paquet. Le dbit par timeslot en pratique est de 10,4 kbit/s. Le dbit montant pratique est limit 20,8 kbit/s avec 2 timeslots.. EDGE peut transporter le trafic de donnes de lusager avec un dbit de 236.8 kbit/s dans le sens descendant avec 4 timeslots (le dbit maximum thorique est de 473.6 kbit/s avec 8 timeslots) en mode paquet. Le dbit par timeslot est de 59,2 kbit/s. Le dbit montant pratique est limit 118,4 kbit/s avec 2 timeslots. Les oprateur WCDMA (3G) sont capables de fournit des dbits montant et descendant de 384 kbit/s. La technologie 3,5G appele HSDPA permet en thorie des dbits descendants pouvant atteindre 14,4 Mbit/s. Mme sil existe des terminaux pouvant fonctionner 1,8 ou 3,5 ou 7,2 ou 10,8 Mbit/s, le dbit offert par loprateur atteint un maximum autour de 1 Mbit/s en dbit descendant. Le dbit montant est celui de W-CDMA. La technologie 3,75G appele HSUPA permet en thorie des dbits montants pouvant atteindre 5,75 Mbit/s. Mme sil existe des terminaux pouvant fonctionner 2 Mbit/s, le dbit offert par loprateur atteint un maximum autour de 1 Mbit/s en dbit montant. Le dbit descendant est celui de W-CDMA. La technologie HSPA (HSDPA+HSUPA) permet donc des dbit pratiques montant et descendant de 1 Mbit/s. La technologie HSPA+ permet de multiplier par 2 ou par 3 le dbit de HSPA. Enfin le dbit pratique que permettra la technologie LTE sera denviron 5 Mbit/s.
Latence (latency) moyenne laccs

La latence est le temps requis pour transmettre un signal d'un Point un autre d'un Rseau. Dans le contexte 2G, il sagit du temps de transmission des donns entre la MS et le GGSN GPRS : 700 ms EDGE : 400 ms Dans le contexte 3G, il sagit du temps de transmission des donns entre lUE et le GGSN WCDMA : 200 ms HSDPA : 90 ms HSUPA : 80 ms HSPA+ : <50 ms Dans le contexte LTE, il sagit du temps de transmission des donns entre lUE et le PDN GW LTE : 30 ms
Copyright EFORT
Simon ZNATY
La latence a une incidence majeure sur lexprience utilisateur. En particulier, les services conversationnels tels que la voix sur IP et la vidotlphonie requirent une latence courte. Les autres services qui bnficieraient dune petite latence sont les jeux multimdia en rseau, lIPTV, etc. Comme les exigences de lusager croient de plus en plus avec lavnement des nouvelles applications mobiles sur IP, les nouvelles technologies mobiles doivent tre conues en les prenant en compte.
Evolution de larchitecture de Rseau Mobile

RTC CS Accs
Architecture 2G
RTC CS Accs
IP PS
RTC NGN Accs
IP PS
Architecture 2G/2,5G/2,75G
Evolution 2G/3G avec NGN
RTC RTC NGN IMS PS Accs

Simon ZNATY
RTC IP PS IMS IP
EPS = LTE + ePC

Rseau paquet Accs
Architecture EPS Copyright EFORT
EPS : Evolved Packet System LTE : Long Term Evolution ePC : Evolved Packet Core CS : Circuit Switched domain PS : Packet Switched domain
3G avec Evolution IMS
Les rseaux mobile GSM (2G) ont t initialement conus pour les services voix et autres services sappuyant sur la commutation de circuit. Cest la raison pour laquelle, cette gnration de rseau prsentait une architecture relativement simple constitue de deux parties principales : Le rseau daccs Le domaine cur de commutation de circuit (CS, Circuit Switched Domain) fournissant les services de la tlphonie aux clients mobiles et linterfonctionnement avec le RTC. Les rseaux mobiles 2,5G/2,75G correspondent lvolution paquet de la 2G. Larchitecture de ces rseaux consiste en deux parties : Le rseau daccs 2G qui a t mis jour pour supporter la transmission de paquet et des schmas dallocation de ressource partage (pour la voix, la 2G ddie les ressources) pour GPRS (2,5G) et EDGE (2,75G). UN nouveau rseau cur (PS, Packet Switching Domain) qui est rajout au domaine circuit (CS) prcdent. Ce domaine paquet le mme rle que le domaine paquet dans un but cette fois doffrir des services de donnes aux clients mobiles et assurer linterfonctionnement avec les rseaux IP (Internet, Intranet). Dun point de vue systme, larchitecture de rseau 3G is plus ou moins celle de la 2G et inclut les domaines circuit et paquet. Le domaine circuit peut tre mul par une architecture dd rseau NGN appel R4 constitue 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 grce lvolution de laccs 3G vers le haut dbit, il sera possible denvisager la fourniture de services conversationnels tels que la tlphonie de bout en bout sur IP. Dans ces conditions, il est important de crer sur le mode paquet les plans de signalisation et de service qui permettront dmuler les services offert par le domaine circuit et de nouveaux services grce la flexibilit dIP. L architecture EPS (Evolved Packet System) a pour objectif dintgrer toutes les application sur une architecture commune et assez simple. Les principaux composants de larchitecture sont : Un rseau daccs paquet qui peut efficacement supporter les services temps rel (e.g., la voix) et non temps rel. Un rseau cur compos dun domaine paquet supportant les services de commutation de paquet dont les services IMS et assurant linterfonctionnement vers Internet, Intranets dentreprise, et le RTC travers lIMS. Le domaine circuit nest plus prsent car toutes les applications sont supportes sur un domaine paquet (PS).
IS-95 : Evolution Rseau

Dbit
Max : downlink :288 Mbit/s uplink : 75 Mbit/s
UMB RevC
Max : downlink :73,5 Mbit/s uplink : 27 Mbit/s Max : downlink :3,1 Mbit/s uplink : 1,8 Mbit/s Max : downlink :2,4 Mbit/s uplink : 153 kbit/s
10 Mbit/s 2 Mbit/s 1 Mbit/s 100 kbit/s 60 kbit/s 14,4 kbit/s IS-95A

Simon ZNATY
EV-DO RevB
EV-DO RevA
Max : downlink 307 kbit/s uplink : 153 kbit/s Max : downlink 115 kbit/s
EV-DO Rev0
Cdma2000 1X
IS-95B
Max : downlink 14,4 kbit/s uplink : 14,4 kbit/s
EV-DO : Evolution Data Optimized UMB : Ultra Mobile Broadband
Disponibilit commerciale
1995
1999
Copyright EFORT
2000
2002
2006
2008
IS-95A is the brand name of the first cdma cellular system, deployed in 1995, initially based on IS-95A North American standards. This system provides voice services as well as circuit switched data up to 14,4 kbit.s This system is mostly deployed in North and Latin America as well as other countries such as South Korea and Australia. IS-95B is a standard evolution of IS-95A systems, first deployed in 1999 offering simultaneous voice and packet data services up to 115 kbit/s (maximum theoretical bitrate). Cdma2000 1X commercially deployed in October 2000 is the first 3G system derived from the IS-95 technology. It has been developed by 3GPP2. The 1X name comes from the fact that this system relies on a single 1.25 MHz carrier, as opposed to multi-carrier transmission schemes making use of three 1,25 MHz carriers. Initially CDMA 1X was able to provide voice services as well as up to 307 kbit/s downlink packet data and 153 kbit/s on the uplink on a single 1,25 MHz carrier. From the initial CDMA2000 1X version, two branches have emerged. The first one is based on the evolution of the 1X specifications leading to the 1xEVDV (Evolution Data and Voice). The second branch known as 1xEV-DO (Evolution Data Only) was renamed Data Optimized, provides improved data transmission as an overlay technology. EV-DV was stopped due to lack of interest from operators and manufacturers. EV-DO Rev0 has been in commercial service since end of 2002. This evolution allows operators to provide simultaneous voice and high speed packet data at the cost of an additional 1,25 MHz carrier. It provides theoretical peak data speeds of 2,4 Mbit/s on the downlink and 153 kbit/s on the uplink. Commercially available in 2006, the EV-DO RevA objective was to improve the lack of quality of service for packet data transmission and limited uplink capabilities of Rev0. As a result, RevA enables to deliver theoretical peak data rates of 3,1 Mbit/s on the downlink and 1,8 Mbit/s on the uplink. Revision B is commercially planned for end of 2008. Its objective is to improve multimedia experience and packet-based delay-sensitive application performance in general. RevB will be able to deliver theoretical peak data rates of 73,5 Mbit/s on the downlink and 27 Mbit/s on the uplink through the aggregation of 15 1,25 MHz carriers within 20 MHz of bandwidth. RevC currently under specification also called Ultra Mobile Broadband (UMB) is equivalent to Evolved 3G. IT is oriented towards all over IP service support over a high-speed packet radio interface. RevC will be able to deliver theoretical peak data rates of 288 Mbit/s on the downlink and 75 Mbit/s on the uplink throughput within 20 MHz of bandwidth.
Etat des Rseaux Mobiles GSM/3G (28 Octobre 2011, Global mobile Suppliers Association, GSA )
4,76 Milliards de souscriptions GSM-WCDMA-HSPA dans le monde reprsentant 90% du march mondial des mobiles 690 oprateurs GSM dans 213 pays 1.3 millions de nouvelles souscriptions GSM ou 3G chaque jour 428 rseaux 3G/WCDMA/HSPA lancs dans 162 pays 152 Rseaux HSPA+ offrent un service commercial dans 79 pays. 3227 terminaux HSPA proposs par 264 fournisseurs. http://www.gsacom.com
10
Simon ZNATY
Copyright EFORT
10
March des terminaux HSPA (4 Aot 2011)
264 fournisseurs commercialisent 3227 modles de terminaux HSPA (tous ces quipements ne sont pas proposs sur tous les marchs):

1340 tlphones incluant les smartphones 292 cartes PC (cartes PCMCIA) 498 notebooks 404 Wireless Routers 568 modems USB 24 Femtocells 48 Personal Media Players (PMPs), UMPCs 8 Camras 45 e-book readers et mobile tablets
iPad2
HTC iPhone 4 Wildfire S D-Link Wireless Router
Asus T500
Simon ZNATY
Copyright EFORT
Sierra Wireless 885 USB Modem
11
11
HSPA Evolution
De nouvelles amliorations sont dj disponibles avec Evolved HSPA, aussi appel HSPA Evolution ou HSPA+. HSPA Evolution fait voluer les dbits :
28 Mbit/s, puis 42 Mbit/s, puis 84 Mbit/s dans le sens descendant et 22 Mbit/s montant
Ces volutions sont possibles grce la transmission sur diffrents canaux parallles depuis le terminal en utilisant la technologie Multiple Input Multiple Output (MIMO) technologies.
Simon ZNATY
Copyright EFORT
12
Evolved HSPA (also known as: HSPA Evolution, HSPA+, I-HSPA or Internet HSPA) is a 3G mobile data protocol defined in 3GPP release 7. Evolved HSDP features increase of DL and UL data speed. Evolved HSPA provides HSPA data rates up to 42 Mbit/s on the downlink and 22 Mbit/s on the uplink with MIMO technologies and higher order modulation. Internet HSPA or I-HSPA is Nokia Siemens Networks product concept implementing Evolved HSPA. Combining 64 QAM with 2x2 MIMO means that 42 Mbps on the downlink (peak) is market reality in some markets from mid-2009 onwards. Further evolution of HSPA is planned by 3GPP, which may utilize combinations of multi-carrier and MIMO technologies to reach 84 Mbps peak on the downlink, and 23 Mbps peak uplink. The mobile industry is consolidating around the LTE system as the next evolution step, with several leading operators committing to LTE deployment. LTE is a natural evolution for GSM/WCDMA-HSPA operators. The leading CDMA operators are expected to be amongst the first to commercially launch LTE.
12
LTE versus UMB
Qualcomm a annonc qu il arrtait le dveloppement de la technologie 4G UMB (Ultra Mobile Broadband), et se focalisait exclusivement sur la technologie LTE. LTE, choisie par l oprateur CDMA Verizon Wireless et de nombreux oprateurs GSM comme technologie 4G a gagn la bataille face l UMB. UMB tait suppose permettre le handover avec CDMA-2000 mais comme le 3GPP a pris en compte la mobilit entre LTE et les accs UTRAN, GERAN et CDMA-2000, l UMB devenait redondant par rapport LTE.
Simon ZNATY
Copyright EFORT
13
13
301 oprateurs dans 95 pays investissent dans la LTE
242 engagement pour la mise en place de rseaux LTE dans 81 pays 59 exprimentations additionnelles de rseau LTE avec pr-engagement dans 14 pays Au 13 Mars 2012, 57 rseaux LTE ont t dploys dans 32 pays. A la fin 2012, plus de 128 rseaux LTE au moins auront t dploys dans 56 pays.
Evolution to LTE report (GSA) 13 Mars 2012
Simon ZNATY
Copyright EFORT
14
Selon les estimations effectues par lassociation "Global mobile Suppliers Association", prs de 301 exploitants de 95 pays se prparent actuellement mettre en uvre la technologie LTE. Dj, 57 exploitants ont ouvert ( oprateurs LTE tablis au 13 Mars 2012) commercialement des rseaux LTE dans 32 pays (dont lAllemagne, la Core du Sud, les Etats-Unis, le Japon, Hong Kong). Selon la GSA, prs de 228 nouveaux rseaux LTE seront en service la fin de 2012 dans 56 pays et le milliard dabonns pourrait tre dpass cette date. http://www.gsacom.com
14
57 rseaux commerciaux LTE dploys au 13 Mars 2012 (1)

Norway Sweden Uzbekistan Uzbekistan Poland USA Austria Sweden Sweden Hong Kong Finland Germany USA Finland Denmark Estonia Japan
Simon ZNATY
TeliaSonera TeliaSonera MTS UCell

Aero2/Mobyland/CenterNet
MetroPCS A1 Telekom TeleNor Sweden Tele2 Sweden CSL Limited TeliaSonera Vodafone Verizon Wireless Elisa TeliaSonera EMT NTT DoCoMo
Copyright EFORT
14.12.09 14.12.09 28.07.10 09.08.10 07.09.10 21.09.10 05.11.10 15.11.10 15.11.10 25.11.10 30.11.10 01.12.10 05.12.10 08.12.10 09.12.10 17.12.10 24.12.10
15
March 13, 2012; GSA; www.gsacom.com)
USA On September 21, 2010 regional carrier MetroPCS became the first operator in the United States to launch LTE. MetroPCS also offered the worlds first commercially available 4G LTE enabled handset, the Samsung Craft. Service was launched initially in Las Vegas, then extended to Dallas/Forth Worth (September 29), Detroit (October 20) and Boston, Sacramento and New York (December 15). The Samsung SCH-R900/Craft is also the first multi-mode CDMALTE handset. LTE network rollouts continue into 2011 across the remaining MetroPCS U.S. markets. Verizon Wireless launched its large-scale commercial LTE system in 700 MHz spectrum on December 5, 2010. The company expects coverage to match that of its existing 3G network by 2013, and 185 million people in 175 metro areas will be served by end 2011. Japan NTT DoCoMo launched Japans first commercial LTE system on December 24, 2010 under the Xi brand. DoCoMo is initially selling Xi USB dongles, beginning with the L-02C device. The company said that voice calls using Xi will become possible sometime within the fiscal year starting in April 2011, when DoCoMo will begin launching LTE-compatible mobile phones. Xi service is initially available in the Tokyo, Nagoya and Osaka areas, and other major cities and regions will follow. DoCoMo plans to spend over $3.6 billion on network build-out by March 2013, with 15,000 base stations serving 40% of the population, 70% coverage planned by March 2015. DoCoMo expects 25% of its 3G user base to migrate to LTE by March 2015. Europe A1 Telekom Austria commercially launched LTE in parts of Vienna and St. Plten (a regional capital) on November 5, 2010. The LTE mobile broadband price plan, A1 Broadband LTE, offers 30 Gbytes of data for 90 per month. TeliaSonera launched the first commercial LTE system in Denmark on December 9, 2010 in Copenhagen, Aarhus, Odense and Aalborg Vodafone launched the first rural LTE mobile broadband service across Germany on December 1, 2010. Some 1,500 base stations will incorporate LTE technology by end March 2011, serving thousands of communities. Vodafone plans to eventually upgrade all base stations in Germany to LTE. On September 7, 2010 the worlds first LTE system in 1800 MHz spectrum (LTE1800) was commercially launched by Mobyland and CenterNet. The service uses the maximum standardized 20 MHz bandwidth. The company targeted to have 700 base stations in operation covering over 7 million people by 2010. TeliaSonera launched the worlds first LTE networks in Oslo and Sweden in December 2009. TeliaSonera launched the worlds first LTE networks in Stockholm and Norway (Oslo) in December 2009. Tele2 Sweden and TeleNor Sweden have deployed an LTE network through a jointly-owned company (Net4Mobility).
15

Germany Philippines Lithuania Latvia Singapore South Korea South Korea Germany Canada Austria Canada Saudi Arabia Saudi Arabia Saudi Arabia USA UAE Australia Denmark
Simon ZNATY
Deutsche Telekom Smart Communications Omnitel LMT M1 SK Telecom LG U+ O2 Rogers Wireless T-Mobile Bell Mobility Mobily STC Zain AT&T Mobility Etisalat Telstra TDC
Copyright EFORT
05.04.11 16.04.11 28.04.11 31.05.11 21.06.11 01.07.11 01.07.11 01.07.11 07.07.11 28.07.11 14.09.11 14.09.11 14.09.11 14.09.11 18.09.11 25.09.11 27.09.11 10.10.11
16
AT&T Mobility launched commercial LTE service on September 18, 2011 in Atlanta, Chicago, Dallas, Houston and San Antonio, initially offering four LTE-compatible devices: HTC Jetstream tablet, AT&T USBConnect Momentum 4G, AT&T Mobile Hotspot Elevate 4G, and AT&T USBConnect Adrenaline. AT&T plans to offer LTE in at least 15 markets and to 70 million Americans by end 2011. AT&T earlier revealed Voice over LTE will be introduced by 2013. Rogers Wireless announced the launch of Canada? s first commercial LTE service on July 7, 2011 in Ottawa. This fall Rogers will roll out LTE to Toronto, Vancouver and Montreal, and another 21 markets in 2012. Later this year, Rogers promises availability of the first LTE smartphones from HTC and Samsung Bell Mobility and Telus have launched a joint HSPA+ network. Bell Mobility launched commercial LTE services in Toronto, Mississauga, Hamilton, KitchenerWaterloo and Guelph on September 14, 2011. Customers can fallback to DC-HSPA+ or HSPA+ outside LTE coverage. The company offers the Sierra Wireless U313 Turbo Stick, and says in coming weeks the Novatel Wireless U679 Turbo Stick will be added. T-Mobile Austria launched a 60-cell site pilot LTE network in Innsbruck in July 2009 and entered a soft launch phase on October 19, 2010. In May 2011, the first LTE base station in Vienna went live. LTE base stations for Linz and Graz were activated in July 2011. On July 28 the company launched LTE and its Internet All Inclusive LTE tariff. Currently ~100 LTE base stations are on air. Etisalat (Mobily) commercially launched LTE TDD service on September 14, 2011 via its Bayanat subsidiary in Najran, Jazan, Al Kharj, Ras tanoura, Algurayat and Aldudam - also in Band 40. Zain commercially launched LTE FDD service in Riyadh, Jeddah, and Dammam on September 14, 2011 in 1800 MHz (LTE1800), and plans to expand to all major cities by end 2012. STC commercially launched LTE TDD service initially in Riyadh and Dammam on September 14, 2011 in Band 40 (2.3 GHz) spectrum.
16

Austria Puerto Rico Puerto Rico Belarus Brazil Finland Uruguay USA Singapore Kuwait Armenia Bahrain Hungary South Korea Russia Canada USA
Simon ZNATY
3 AT&T Mobility Claro Yota Bel Sky Brazil DNA Antel Cricket SingTel Viva Vivacell-MTS Viva Bahrain T Mobile KT Yota TELUS
18.11.11 20.11.11 24.11.11 01.12.11 13.12.11 13.12.11 13.12.11 21.12.11 22.12.11 27.12.11 28.12.11 01.01.12 01.01.12 03.01.12 15.01.12 10.02.12 Peoples Telephone Co-op 14.02.12
Copyright EFORT
17
17

Japan Portugal Portugal Softbank TMN Vodafone Portugal 24.02.12 12.03.12 12.03.12
Simon ZNATY
Copyright EFORT
18
18
2. GPRS dans le rseau mobile
Simon ZNATY
Copyright EFORT
19
Le GSM est un systme de commutation de circuit conu pour le transfert de la voix. Dans ce systme, un paquet est mis / reu un instant (timeslot) et une frquence spcifiques la communication considre. En GSM, la ressource est donc immobilise tout au long de la communication, qu'un signal soit mis ou non. Le dbit obtenu en transmission de donnes est limit 9,6 kbit/s, ce qui rend le GSM peu adapt au transfert de donnes. C'est ainsi qu'une nouvelle technologie a t amene se dvelopper pour mener bien l'volution vers une vritable solution d'accs mobile aux rseaux de donnes : le GPRS (General Packet Radio Service). Le GPRS n'est pas proprement parler un nouveau rseau : c'est en fait une volution du rseau GSM qui permet la transmission de donnes par paquet. Etant une tape importante entre la 2G et la 3G, le GPRS est souvent dsign comme un systme de 2,5G. Parmi les caractristiques principales du GPRS figurent : Un accs paquet au niveau de l'interface radio avec optimisation de la ressource spectrale : les ressources radio ne sont plus affectes en permanence un utilisateur, mais elles sont partages entre plusieurs utilisateurs Une commutation de paquets au niveau du sous-systme rseau avec optimisation des ressources rseau ; Un dbit thorique variable compris entre 9,6 kbits/s et 171,2 kbits/s ; En pratique, le dbit pourra atteindre 40 kbit/s. Un accs Internet standardis ; Une possibilit de taxation au volume (par rapport la taxation la dure) 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 conu pour tre intgr dans l'architecture GSM avec le minimum de changements. Le sous-systme radio est mis jour afin de supporter de nouveaux protocoles adapts aux donnes par paquet. Ces mises jour sont principalement logicielles. Si le rseau daccs GSM est peu impact par le GPRS, un nouveau sous-systme rseau est intgr celui du GSM afin de permettre une interconnexion directe lInternet et lacheminement des donnes en mode paquet. Ainsi de nouveaux nuds de commutation de paquet compltent les commutateurs de circuit du GSM. C'est le sous-systme radio qui dmultiplexe les trafics voix et data et les achemine aux commutateurs appropris (circuit et paquet). Il faut bien noter que la technologie GPRS est une technologie d accs permettant un dbit concret de 40 kbit/s et une technologie de commutation de paquet dans le rseau cur. Ces mmes commutateurs GPRS supportent diffrentes technologie d accs pour offrir des dbits de plus en plus importants : GPRS, EDGE, EDGE+, W-CDMA, HSDPA, HSUPA, HSPA+. 19
2.1. Entits GPRS
Simon ZNATY
Copyright EFORT
20
20
Architectures 3G et 3G+ actuelles

BSS
MS SCP Domaine Circuit
BTS BTS BTS
BSC
HLR
SS7/ SIGTRAN
PCU
MSC VLR Server Frame Relay
ATM
RNC
IP Network
Domaine Paquet
RTC OFCS PCRF OCS

Gx Gz Gy
Node B
UE
Gbit Eth Node B

UE
Simon ZNATY
Rseau IP SGSN
RNC : Radio Network controller UE : User Equipment UTRAN : UMTS Terrestrial Radio Access Network PCRF : Policy and Charging Rlues unction PECF : Polich and Charging Enforcement Function Copyright EFORT
PCEF GGSN Internet Intranet

21
UTRAN RNC
UMTS (Universal Mobile Telecommunications System) aussi appel 3G introduit une nouvelle interface radio appele UTRAN (UMTS Terrestrial Radio Access Network). UTRAN va permettre aux usagers UMTS de disposer de dbits suffisants pour tablir des sessions multimdia. Le sous-systme radio se compose de deux lments distincts, savoir le nud B (node B) et le contrleur de rseau radio (RNC, Radio Network Controller). Le node B quivaut la BTS du rseau GSM. Le RNC quivaut la BSC du rseau GSM. Le RNC possde et contrle les ressources radio des nodes B auquel il est connect. Le Node B s interface au RNC par ATM (Dans le futur cette interface sera supporte par Gigabit Ethernet). Le RNC s interface avec le SGSN en utilisant une connectivit Gigabit Ethernet (GE). Lentit 3G SGSN (Serving GPRS Support Node) s'occupe dans son aire de service des transmissions de donnes entre les mobiles et le rseau mobile. Ses tches incluent le routage et le transfert de paquets, les fonctions attach/detach des terminaux mobiles et leur authentification. Lentit GGSN (Gateway GPRS Support Node) joue le rle dinterface des rseaux de donnes externes (e.g., rseaux IPv4 et IPv6). Elle dcapsule des paquets IP arrivant sur un tunnel en provenance du SGSN et les envoie au rseau externe correspondant. Le GGSN permet aussi dacheminer les paquets IP provenant des rseaux de donnes externes vers le SGSN du destinataire sur un tunnel. La technologie W-CDMA utilise par UMTS (3G) permet des dbits montant et descendant jusqu 384 kbit/s depuis le mobile. Le dbit descendant W-CDMA peut tre amlior par la technologie radio HSDPA (High Speed Downlink Packet Access) qui permet des dbits descendants jusqu 14,4 Mbit/s. Cela requiert une mise jour logicielle des nodeB et RNC, et un nouveau terminal mobile supportant cette technologie. En pratique HSDPA offre 1 Mbit/s au client mobile pour ses dbits descendants. Le dbit montant W-CDMA peut tre amlior par la technologie radio HSUPA (High Speed Uplink Packet Access) qui permet des dbits montants jusqu 5,75 Mbit/s. Cela requiert une mise jour logicielle des nodeB et RNC, et un nouveau terminal mobile supportant cette technologie. En pratique HSUPA offre 1 Mbit/s au client mobile pour ses dbits montants. L entit PCRF (Policy and Charging Rules Function) permet la fonction PCEF (Policy and Charging Enforcement Function) incluse dans le GGSN d apprendre les rgles 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. 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 consomms 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 crdit de l'OCS et soumet des tickets de taxation l'OFCS. Il est noter que l'entit PCEF peut tre indpendante du GGSN et dans ce cas se retrouve derrire le GGSN l'interface des rseaux externes IP.
21
Architectures 3G et 3G+ futures

BSS
MS SCP Domaine Circuit
BTS BTS BTS
BSC
HLR
SS7/ SIGTRAN
PCU
MSC VLR Server
Gbit RNC Eth
IP Network
Domaine Paquet
RTC OFCS PCRF OCS

Gx Gz Gy
Node B
UE
Gbit Eth Node B

UE
Simon ZNATY
Rseau IP SGSN
PCEF GGSN Internet Intranet
UTRAN RNC
Copyright EFORT
22
Dans les volutions vers le trs haut dbit, Ethernet devient la technologie de transport pour tous les flux : tlphonie et data. En effet, les liens ATM entre Node B et RNC sont remplace par des liens GE (Gigabit Ethernet); De mmesi des les liens ATM sont encore prsents entre RNC et MGW, ils sont remplacs par des liens GE. Enfin les liens Frame Relay permettant de relier les PCU (BSC) au SGSN sont aussi migrs vers GE. Avec certains fournisseurs, il est mme possible d intgrer la fonction RNC dans le Node B. Les Node/RNC sont alors directement relis aux cur de rseau circuit et paquet pas des liens GE.
22
Evolution du domaine paquet vers une architecture plate

Release 6 Release 7 Direct Tunnel Release 7 Direct Tunnel et RNC dans le Node B
GGSN
GGSN
GGSN
SGSN
SGSN
SGSN
RNC
RNC
Plan Contrle Plan Usager
Node B
Simon ZNATY
Node B
RNC Node B
23
Copyright EFORT
Jusqu la Release 6, les lments impliqus sur le plan contrle et le plan usager pour un contexte PDP sont l'UE, le Node B, le RNC, le 3G SGSN et le GGSN. Afin damliorer les performances de HSPA, une architecture plate a t considre partir de la Release 7. A la Release 7, il y a loption dune architecture one-tunnel dans laquelle le rseau tablit un chemin (tunnel) direct pour le trafic usager entre le RNC et le GGSN sans passer par le SGSN. Les lments impliqus sur le plan usager sont donc l'UE, le NodeB, le RNC et le GGSN. Par contre le SGSN est toujours prsent sur le plan de contrle pour ltablissement du contexte PDP. Cela permet de minimiser le nombre lments ayant traiter le trafic usager et donc rduire les dlais ainsi que simplifier lingnierie du rseau. Il existe aussi une autre solution encore plus optimise appele "NodeB/RNC intgr" dans laquelle les fonctions du RNC sont intgres dans le Node B. Ce type de solution apparat notamment dans les architectures femtocell. Cette nouvelle amlioration est similaire celle de larchitecture du rseau 4G appel LTE (Long Term Evolution of 3G) o le seul lment prsent dans le rseau daccs est leNodeB, qui ralise certaines fonctions du RNC. Par ailleurs, mme si linterface entre RNC et 3G-SGSN (i.e., interface IuPs) sappuyait initialement sur un transport ATM, lvolution met en jeu un transport GE. De mme, alors qu'initialement les NodeB et les RNCs taient interfacs 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 scnarii suivants : 1. Si lusager est dans un rseau visit, le SGSN doit tre prsent sur le plan usager pour le comptage des octets envoys et reus par lusager et pour les reversements entre oprateurs. Aujourdhui la tarification du trafic de donnes lorsque l usager est dans un rseau visit est en moyenne de 5 Euros par Mgaoctet (tarification au volume uniquement). 2. Si lusager est reli par un accs 2G au SGSN, ce dernier ne peut pas fonctionner en mode direct tunnel. Ce mode est rserv au cas o lusager est pris en charge par un accs 3G (NodeB/ RNC). 3. Le GGSN ne supporte pas le protocole GTPv1. Avec le protocole GTPv0 il nest pas possible de fonctionner selon le mode direct tunnel car le protocole GTPv0 ne sait pas dissocier le plan contrle du plan usager.
23
User Equipment (UE)

MSISDN = 33 6 11 23 24 25 IMSI = 208 01 4356244811
USIM Card
Rseau 3G
IMSI = 208 01 4356244811
A chaque abonn est associ :
IMEI = 435654 45 056543 0
Un numro MSISDN (Mobile station ISDN number) par lequel il peut tre appel Une identit IMSI (International Mobile Subscriber Identity) utilis par le rseau pour le reprer A un quipement est associ un IMEI (International Mobile Equipment Identity)
Copyright EFORT
Simon ZNATY
24
Lorsqu un abonn souscrit un abonnement mobile 3G auprs d un oprateur, il reoit un identifiant unique appel IMSI (International Mobile Subscriber Identity). Ce numro d IMSI est stock sur la carte SIM. Un tlphone mobile ne peut tre utilis que si une carte SIM valide a t insre ans l quipement mobile appel User Equipment (UE) car c est la seule faon de facturer correctement un abonn mobile. Cet IMSI est un concept d adressage spcifique au GSM et est diffrent du plan de numrotage RNIS. Le numro d IMSI n est pas connu de l abonn mobile et n est utilis que par le rseau GSM. L IMSI commence par un chiffre identifiant le continent (Europe = 2), puis deux chiffres dfinissant le pays (France = 08), puis deux chiffres identifiant l oprateur dans le pays (Orange France = 01; SFR = 10; Bouygues Telecom = 20) et finalement jusqu 10 chiffres pour identifier le numro de l abonn chez l oprateur. Exemple d IMSI : 2 08 01 4356244811. Le numro de tlphone 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 oprateur dans le pays (SFR in France). 902450 est l identification de l abonn mobile. L IMEI identifie de faon unique un terminal mobile au niveau international. Il s agit d un numro de srie. Ce numro est allou par le constructeur du terminal mobile.
24
Interfaces entre UE et 3G MSC / 3G SGSN

CM Protocol PSTN
Subscriber Database
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
Class 5 Switch
3G UE
MM Protocol
CM = CC+SM1+SS
VLR
3G MSC GMM Protocol

SM1+ SM2 Protocol
Simon ZNATY Copyright EFORT
3G SGSN
25
Dans le rseau fixe, le tlphone est toujours rattach au mme commutateur d accs (Class 5 Switch). Ce commutateur inclut une base de donnes stockant le profil des abonns. Le profil contient en particulier les marques de services complmentaires souscrits par l'abonn rattach ce commutateur. Le tlphone utilise un protocole de gestion des connexions pour ltablissement et la libration 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 mme un appel entrant se prsente au terminal RNIS travers ce message SETUP. Dans un environnement mobile, une station mobile (MS, Mobile Station) nest pas toujours rattache au mme MSC. Cest la raison pour laquelle le mobile doit rgulirement informer le rseau de sa localisation courante. Lorsquune station mobile est mise sous tension par l usager, elle se rattache au rseau ; elle informe le MSC qui contrle l aire dans laquelle elle est prsente, de sa localisation courante. Ce dernier met alors jour sa VLR. Afin de raliser cette action denregistrement, un mobile utilise un protocole de gestion de la mobilit (mobility management protocol, MM). L'tablissement et la libration d'appel par le mobile sont possibles travers la couche communication management (CM). Cette couche permet au mobile d'tablir et de librer des appels (CC, Call Control), de disposer de services complmentaires (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 capacits pour se rattacher un rseau GPRS et pour tablir des contextes PDP (appels de donnes). Les protocoles utiliss pour ce faire sont GMM (GPRS Mobility Management) et SM (Session Management) respectivement.
25
3G SGSN

Gnralement un 3G SGSN peut tre mis jour pour devenir un 3G SGSN Connect plusieurs BSC et RNC et prsent dans le site dun MSC. Principales fonctions :
Il prend en charge lenregistrement des station mobile au rseau GPRS (attachement) Il authentifie les stations mobiles GPRS, EDGE, 3G, 3G+ Il prend en charge la gestion de la mobilit des stations mobiles Il tablit, maintient et libre les contextes PDP Il relaie le paquets de donnes de la station mobile au rseau externe ou du rseau la station mobile Il collecte les donnes de taxation de linterface air Il sinterface dautres noeuds (HLR, MSC, BSC, RNC, SMSC, GGSN, CSE, DNS).
Copyright EFORT
Devient gnralement un MME du rseau LTE/ePC

26
Simon ZNATY
Lentit SGSN (Service GPRS Support Node) se charge dans son aire de service des transmissions de donnes entre les stations mobiles et le rseau mobile. Le SGSN est reli par des liens Frame Relay au sous-systme radio GSM (2G) et par des liens ATM ou Gigabit Ethernet au sous systme radio UTRAN (3G). Le SGSN est connect plusieurs BSC et prsent dans le site dun MSC. Le SGSN : Authentifie les stations mobiles GPRS Prend en charge lenregistrement des stations mobile au rseau GPRS (attachement) Prend en charge la gestion de la mobilit des stations mobiles. En effet, une station mobile doit mettre jour sa localisation chaque changement de zone de routage. Etablit, maintient et libre les contextes PDP, qui correspondent des sessions de donnes permettant la station mobile d'mettre et de recevoir des donnes. Relaie les paquets de donnes de la station mobile au rseau externe ou du rseau la station mobile Collecte les donnes de taxation de linterface air
26
Dimensionnement 3G SGSN
Un nud SGSN a une capacit dfinie par les paramtres suivants :

Nombre de stations mobile attaches Bande passante totale Nombre de ports Gb/IuPs Nombre de cellules Nombre de Routing Areas
Typiquement les principaux facteurs sont le nombre de stations mobile attaches et la bande passante totale Le nombre de stations mobiles pouvant sattacher un SGSN varie selon le modle SGSN constructeur et peut atteindre 3 Million. La bande passante totale dun SGSN varie entre 1Gbit/s et 16 Gbit/s. Le nombre de contextes PDP actifs peut atteindre 1,5 Millions. Le nombre de ports Gb ou IuPs est au maximum 128
Copyright EFORT
Simon ZNATY
27
27
GGSN
Prsent dans le site dun MSC. Il y a un GGSN ou un nombre faible de SGSN par oprateur Principales fonctions :
Il joue le rle dinterface aux rseaux externes de type IPv4 ou IPv6 Il ressemble un routeur. Dailleurs dans de nombreuses implmentations, il sagit dun routeur IP avec des fonctionnalits supplmentaires. Il relaie les paquets aux stations mobiles travers un SGSN; Il faut noter que les paquets ne sont pas dlivrs la station mobile si cette dernire na pas activ un contexte PDP. Il route les paquets mis par la station mobile la destination approprie. Il filtre le trafic usager. Il collecte les donnes de taxation associes lusage des ressources entre SGSN et GGSN (Starent).
Les fonctionnalits SGSN et GGSN peuvent tre combines dans un mme quipement physique (e.g., Lucent s, Alcatel s or Ericsson s combined SGSN/GGSN) ou tre distribues dans des noeuds spars (e.g., Nortel, Motorola, Alcatel, Copyright Lucent, Ericsson, etc.) 28 Simon ZNATY EFORT
Lentit GGSN (Gateway GPRS Support Node) joue le rle dinterface des rseaux de donnes externes (e.g., IPv4, IPv6). Elle convertit des paquets GPRS provenant du SGSN en le format de donnes appropri (PDP, Packet Data Protocol) et les envoie au rseau externe correspondant. Egalement, le GGSN permet dacheminer les paquets provenant des rseaux de donnes externes vers le SGSN du destinataire. Les termes SGSN et GGSN identifient des entits fonctionnelles qui peuvent tre implantes dans un mme quipement ou dans des quipements distincts (comme pour les entits fonctionnelles MSC et GMSC). Lensemble des entits SGSN, GGSN, des routeurs IP ventuels reliant les SGSN et GGSN et les liaisons entre quipements est appel rseau fdrateur GPRS (GPRS backbone). Le GGSN est gnralement prsent dans le site dun MSC. Il existe un GGSN ou un nombre faible de GGSN par oprateur
28
Dimensionnement GGSN
Un nud GGSN a une capacit dfinie par les paramtres suivants :

Nombre de contextes PDP actifs simultanment Bande passante totale
Le nombre de contextes PDP actifs simultanment varie entre 25000 et 6 Million. La capacit de commutation dun GGSN varie entre 10 Gbit/s et 100 Gbit/s. Le nombre de paquets commuts par seconde varie entre 200000 et plusieurs millions.
Simon ZNATY
Copyright EFORT
29
29
Backbones GPRS

Permet la communication entre nuds GSN. Le Backbone sappuie sur un rseau IP priv

IPv6 est le protocole qui sera utilis sur le long terme IPv4 peut tre utilis en tant que solution intermdiaire Connecte les nuds GSN dun oprateur donn Loprateur dcide de son architecture
Backbone Intra-PLMN (rseau intra-oprateur IP)

LAN, Liens point point, ATM, etc.
Backbone Inter-PLMN (rseau inter-oprateur IP)
Connecte des oprateurs GPRS travers des Border Gateways (BGs) Permet le roaming GPRS international
Copyright EFORT
Simon ZNATY
30
Lensemble des entits SGSN, GGSN, des routeurs IP ventuels reliant les SGSN et GGSN et les liaisons entre quipements est appel rseau fdrateur GPRS (GPRS backbone). On peut distinguer deux types de backbones GPRS : Backbone intra-PLMN : il sagit dun rseau IP appartenant loprateur de rseau GPRS permettant de relier les GSNs de ce rseau GPRS. Backbone inter-PLMN : Il sagit dun rseau qui connecte les GSNs de diffrents oprateurs de rseau GPRS. Il est mis en uvre sil existe un accord de roaming entre deux oprateurs de rseau GPRS. Deux backbones Intra-PLMN peuvent tre connects en utilisant des Border Gateways (BGs). Les fonctions du BG ne sont pas spcifies par les recommandations GPRS. Au minimum, il doit mettre en uvre des procdures de scurit afin de protger le rseau intra-PLMN contre des attaques extrieures. La fonctionnalit de scurit est dtermine sur la base d'accords de roaming entre les deux oprateurs.
30
2.2. Gestion de la mobilit, Gestion de session, Roaming GPRS
Simon ZNATY
Copyright EFORT
31
31
Attachement au domaine paquet (PS, Packet Switching)

MS
BTS
BSC
SGSN HLR EIR
GMM Attach Request GMM Authentication and ciphering req
MAP Send Authentication Info (IMSI) MAP Send Authentication Info Ack (Vector)
GMM Authentication and ciphering response (RES) GMM Identity req GMM Identity response (IMEI) MAP Check IMEI (IMEI) MAP Check IMEI Ack (IMEI, Status)
MAP Update GPRS Location (IMSI) MAP Insert Subscriber Data MAP Insert Subscriber Data Ack MAP Update GPRS Location Ack
GMM Attach Accept (P-TMSI) GMM Attach Complete

32
La demande d attachement est mise par le mobile au SGSN travers le BTS et le BSC. Avant de pouvoir enregistrer le mobile, le SGSN doit procder certaines vrifications sur la validit de l identit de l usager (IMSI) et l identit du terminal (IMEI). La vrification de l identit de l usager seffectue travers la procdure d authentification. Les donnes permettant l authentification sont pralablement demandes au HLR par le SGSN. La vrification de l identification du mobile est une procdure optionnelle. Sur demande du SGSN , le terminal fournit son identit (IMEI : International Mobile Equipment Identity). L EIR, interrog par le SGSN indique dans le message de retour si le terminal fait ou ne fait pas partie de la liste des quipements interdits (black list). Une fois les vrifications d identits effectues, le SGSN peut procder l inscription du mobile auprs du rseau. Le SGSN informe le HLR de l enregistrement du mobile dans sa base de donnes. En retour, le HLR transmet au SGSN les caractristiques de l abonnement souscrit par l usager. Ces informations seront utilises ultrieurement par le SGSN lorsque l usager souhaitera tablir ou recevoir un appel tlphonique.
32
Contexte PDP
UE SGSN
Same PDP (IP) address and APN
GGSN1
ISP X
PDP Context X1 (APN X, IP address X, QoS1) PDP Context X2 (APN X, IP address X, QoS2)
APN X
GGSN2
PDP Context Y (APN Y, IP address Y, QoS) PDP Context Z (APN Z, IP address Z, QoS)
APN Y
ISP Y
APN Z
ISP Z
Simon ZNATY
Copyright EFORT
33
Un contexte PDP est un ensemble d'information qui caractrise un service de transmission de base. Il regroupe des paramtres qui permettent un abonn de communiquer avec une adresse PDP dfinie (i.e., adresse IPv4 ou adresse IPv6), selon un protocole spcifique (IP4 ou IPv6), suivant un profil de Qualit de service dtermin (dbit, dlai, priorit...). La procdure "PDP Context Activation", dclenche l'initiative de l'abonn mobile, permet au terminal d'tre connu de la passerelle GGSN qui ralise l'interconnexion avec le rseau PDP externe demand par l'abonn GPRS. La transmission de donnes entre le rseau GPRS et le rseau PDP externe (rseau IPv4 ou rseau IPv6) peut alors dbuter. La procdure inverse de "PDP Context Activation" est la procdure "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 rseau (i.e., GGSN). Une adresse IP est alloue par le GGSN l usager lors de l tablissement d un contexte PDP primaire (pour une APN donne). Un contexte PDP secondaire partage la mme adresse IP que le PDP contexte primaire auquel il est associ, mais pas la mme QoS. Dans l'exemple prsent la figure, l'UE (User Equipment) a tabli trois contextes PDP primaires X1, Y, Z. Chacun est associ une APN donne, APN X, APN Y, APN Z et une adresse IP donne, respectivement IP X, IP Y, IP Z. Par ailleurs une QoS doit tre associe chaque contexte PDP. Quatre classes de QoS sont dfinies : conversationnel (pour des services temps rel bidirectionnel tels que une communication audio ou visio), streaming (pour des services temps rel unidirectionnels tels que le video streaming ou le broadcast TV), interactive (pour des services de donnes interactifs tels que la messagerie instantane ou le WEB), et background (pour des services de donnes best effort). L'exemple montre un contexte PDP secondaire X2 associ un contexte PDP primaire X1. Ce contexte PDP secondaire partage la mme APN, la mme adresse IP que le contexte PDP primaire X1, mais pas la mme QoS. Si l'on considre un usager qui souhaite accder ses services IMS, il doit disposer d'un contexte PDP primaire pour le transport de la signalisation SIP/IMS afin de pouvoir tout moment tablir ou recevoir des appels. Ce contexte PDP sera permanent et sera associ une QoS interactive. Par contre lorsqu'un appel est tabli, un contexte PDP secondaire sera ouvert pour le transport de la voix sur IP (protocole RTP) qui requiert une QoS conversationnelle. Lorsque des paquets entrants arrivent au GGSN1,il sera les acheminer sur le contexte PDP primaire ou secondaire en fonction du couple adresse IP/numro de port. En effet, les flux SIP et RTP sont manipuls par des applications sur le terminal qui utilisent des port diffrents. Les paquets sortants seront mis par l'UE sur le contexte PDP primaire ou secondaire en fonction des flux SIP ou RTP. 33
Activation dun Contexte PDP primaire par lUE

DNS
RNC UE 3G SGSN GGSN
1. SM Activate PDP Context Request (PDP Type = IPv4, PDP address = 0.0.0.0, QoS requested, APN = mms.orange.fr)
4. Radio Access Bearer Setup
2. Create PDP Context Request (MSISDN, PDP Type = IPv4, PDP address = 0.0.0.0, QoS requested, APN = mms.orange.fr) 3. Create PDP Context Response (PDP Type = IPv4, PDP address = 192.23.24.25, QoS negotiated, APN = mms.orange.fr)
Simon ZNATY
5. SM Activate PDP Context Accept (PDP Type = IPv4, PDP address = 192.23.24.25, QoS negotiated, APN = mms.orange.fr) Copyright EFORT
34
Pour changer (envoyer et recevoir) des paquets IP via le rseau GPRS, l'UE doit activer un contexte PDP (Figure). Lactivation de contexte PDP constitue donc la deuxime tape aprs la procdure dattachement de l'UE au rseau GPRS. La procdure dactivation de contexte PDP (PDP Context Activation) dclenche par l'UE, lui permet dtre connue de lentit GGSN concerne. 1. Au cours de cette procdure, l'UE communique au 3G-SGSN via la commande SM Activiate PDP Contexte Request, le point daccs au rseau 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 rseau ce GGSN, appel Create PDP Contexte Request. Les paramtres fournis par l'UE sont inclus ainsi que son MSISDN. 3. Une ngociation de qualit de service est engage. Le GGSN alloue une adresse IP du type demand (IPv4 ou IPv6) et la retourne dans la rponse Create PDP Context Response aunsi que la QoS ngocie. 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'accs entre le RNC et le 3G-SGSN. Un contexte PDP est donc l'agrgation des tunnel radio, accs et rseau. 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.
34
Ractivation du RAB (Radio Access Bearer) pour l mission de paquets

UE RNC 3G SGSN GGSN
1. Service Request
2. Service Request 3. RANAP RAB Assignment Request
4. RRC : Radio Bearer Setup
Radio Resource Establishment Iu PS Bearer Establishment 5. RRC : Radio Bearer 6. RANAP RAB Setup Complete Assignment Response
Simon ZNATY
Copyright EFORT
35
Il est noter que lorsque l'UE n'a pas de paquets IP mettre ou recevoir le RAB est automatiquement libr par le RNC. L'UE passe alors de l'tat actif l'tat de repos (idle). Par contre le tunnel rseau entre le SGSN et le GGSN est maintenu pour une dure qui dpend de l'APN. Cette dure est gre par le GGSN. Celle-ci est de plusieurs dizaines de minutes voir de plusieurs heures. Il s'agit alors pour l'UE qui souhaite de nouveau mettre des paquets de ractiver le RAB uniquement. L usager met un message NAS Service Request transport de faon transparente jusqu au 3G-SGSN (Figure 7). Le message est transport sur le protocole de signalisation RRC entre l UE et le RNC et sur le protocole de signalisation RANAP entre le RNC et le 3G SGSN. Comme vu prcdemment, le 3G-SGSN demande au RNC d'tablir le RAB qui correspond un tunnel de l'UE au 3G-SGSN.. Une fois celui-ci tabli, une confirmation est retourne au 3G-SGSN. L UE peut mettre des paquets IP. Le plus important est de minimiser le dlai ncessaire pour que l'UE passe de l'tat idle l'tat actif.
35
Ractivation du RAB (Radio Access Bearer) pour la rception de paquets

UE RNC 3G SGSN GGSN
RANAP Paging Request RRC Paging Request
Paquet IP
Paquet IP
Paquet IP
RRC Paging Response RANAP Paging Response RRC : Radio Bearer Setup RANAP RAB Assignment Request
Radio Resource Establishment Iu PS Bearer Establishment RRC : Radio Bearer RANAP RAB Setup Complete Assignment Response
36
Considrons le cas de paquets IP entrants alors que l'UE est dans l'tat idle. le GGSN encapsule les paquets IP entrants dans des paquets GTP-U et les transfre sur le tunnel rseau associ au contexte PDP de l'UE, au SGSN. Ce dernier doit d'abord localiser l'UE avant de demander au RNC appropri l'tablissement du RAB pour acheminer les paquets IP l'UE. Dans l'tat idle, l'UE n'informe le 3G-SGSN que lorsque l'UE change de routing area. Or, une routing area peut contenir des Node B contrls par diffrents RNC. Le 3GSGSN, ralise donc une opration de Paging sur l'ensemble de la routing area de l'UE. Une fois que l'UE rpond cette demande, il est localis. Le 3G-SGSN demande alors au RNC appropri d'tablir le RAB. Une fois l'opration ralise, le 3G-SGSN transfre les paquets IP de l'UE sur ce RAB.
36
Tunnels de domaine UMTS PS (Plan usager)
App. IP Relay PDCP PDCP RLC MAC L1 RLC MAC L1 GTP-U UDP/IP GE GTP-U GTP-U UDP/IP L2 L1 Relay GTP-U IP
UDP/IP UDP/IP GE L2 L1
UE
Simon ZNATY
Uu
UTRAN
Iu-PS
Copyright EFORT
3G-SGSN
Gn
GGSN
37
Les donnes de l'usager sont transportes de manire transparente entre la station mobile et le rseau de donnes externe en utilisant des mcanismes d'encapsulation et de tunneling. La couche PDCP (Packet Data Convergence Protocol) a deux fonctions principales. Tout d'abord elle permet d'assurer l'indpendance des protocoles radio de l'UTRAN (couches MAC et RLC) par rapport aux couches de transport rseau. Cette indpendance permettra de faire voluer les protocoles rseau (par exemple de passer de l'IPv4 l'IPv6) sans modification des protocoles radio de l'UTRAN. D'autre part, la couche PDCP offre les algorithmes de compression de donnes ou d'en tte de paquets de donnes, permettant un usage plus efficace des ressources radio. Le transport fiable des donnes entre deux quipements est assur par la couche RLC (Radio Link Control). Le protocole RLC ressemble beaucoup aux protocoles tels que HDLC et LAPD. La couche MAC (Medium Access Control) remplit la fonction de multiplexage des donnes sur les canaux de transport radio. Le niveau 1 (PHY) reprsente le couche physique de l'interface radio. Elle ralise entre autres les fonctions de codage de canal, d'entrelacement et de modulation Un paquet d'information reu par l'UTRAN et provenant du rseau de base (CN) est appel N-PDU (Network PDU). Dans le cas d'un paquet IP, l'en-tte de la N-PDU est compress par la couche PDCP, c'est dire remplac par un entte PDCP de taille plus rduite. Cette nouvelle PDU est ensuite segmente par la couche RLC, qui ajoute chaque segment son propre en-tte. La RLC-PDU est alors traite par la couche MAC, qui ajoute un en-tte lorsqu'un multiplexage est effectu (Figure 12). GPRS Tunnelling Protocol for the user plane (GTP- U) transporte dans des tunnels les donnes utilisateur entre l'UTRAN (RNC) et le 3G SGSN et entre les GSNs dans le rseau GPRS. Le protocole GTP s'appuie sur le transport UDP/IP/AAL5/ATM ou UDP/IP/Ethernet. Le protocole GTP version 1 utilis dans le contexte de l'UMTS R3 spare le plan de transfert des donnes utilisateur (GTP-U), du plan de contrle (GTP-C). Si l'UE met un paquet IP (IP1), ce dernier est transport sur un tunnel PDCP de l'UE au RNC. Le RNC dcapsule le paquet IP (IP1) du paquet PDCP et l'inclut dans un paquet GTP-U. GTP-U est un protocole de niveau application s'appuyant sur UDP/IP. Le paquet IP (IP2) encapsulant le paquet GTP-U/UDP a pour adresse IP source celle du RNC et pour adresse de destination celle du 3G-SGSN. Le paquet IP (IP2) est encapsul dans une trame GE (Gigabit Ethernet) et dlivr au 3G SGSN, destinataire du paquet IP (IP2). Le 3G-SGSN dcapsule le paquet GTP-U et l'inclut dans un autre paquet GTP-U sur UDP/IP. Au niveau IP, le paquet IP(IP3) a pour adresse source celle du 3G-SGSN et pour adresse de destination celle du GGSN. Le paquet IP est transmis sur une couche liaison de donnes et physique (L2/L1) qui est gnralement GE. Le GGSN dcapsule le contenu du paquet IP (IP3) puisqu'il en est le destinataire, puis le contenu du segment UDP puis le contenu du paquet GTP-U, savoir le paquet IP (IP1) et route ce paquet IP vers sa destination comme l'aurait ralis tout routeur IP. 37
Requte HTTP encapsule dans un paquet GTP

1 2 TCP HTTP Requte (Longueur = X) + En-tte TCP (Longueur = X + 20)
IP
TCP
HTTP
+ En-tte IP (Longueur = X+ 40) + En-tte GTP (Longueur = X+ 60)
GTP UDP GTP
IP IP
TCP TCP
HTTP HTTP
+ En-tte UDP (Longueur = X+ 68)
IP
UDP GTP
IP
TCP
HTTP
+ En-tte IP (Longueur = X+ 88)
Simon ZNATY
Copyright EFORT
38
Dans le plan de transmission, le protocole GTP entre GSNs est un protocole de tunneling pour le transport des paquets de donnes de l'usager. Le tunneling est un terme gnrique utilis trs largement dans le monde des rseaux, qui n'est pas forcment caractristique au protocole IP. Globalement, la technique de tunneling consiste en l'encapsulation de donnes d'un protocole dans un autre protocole. Le protocole encapsulant, ou encore porteur, permet au protocole sous-jacent de traverser de faon transparente un rseau pour lequel il n'est pas forcment adapt. GTP (GPRS Tunneling Protocol) est le protocole d'encapsulation du trafic IP de l'utilisateur dans le rseau IP de l'oprateur entre le SGSN et le GGSN. GTP s appuie sur UDP/IP
38
Activation dun Contexte PDP depuis un rseau visit Node B

RNC UE Node B Node B SGSN Intra-PLMN Backbone Network Inter-PLMN Backbone Network BG RNC
UE
BG Intra-PLMN Backbone Network GGSN
SGSN
HPLMN
GGSN Data Network (Internet)
VPLMN
UE dans le HPLMN UE dans le VPLMN

Simon ZNATY
Serveur dentreprise Routeur

Copyright EFORT
39
LAN
Pour tablir le lien entre les rseaux GPRS/IP des diffrents oprateurs mobiles, plusieurs solutions existent : la connexion directe entre oprateurs mobiles ; la connexion indirecte par lintermdiaire de lInternet et la connexion indirecte par raccordement aux GRX (GPRS Roaming eXchange). Le GRX est une solution propose par les oprateurs de backbone IP. Un GRX est un rseau de donnes ddi interconnectant les infrastructures des oprateurs mobiles GPRS. La connexion directe entre oprateurs offre la meilleure scurit et la meilleure qualit de service mais aussi le cot le plus lev. La connexion indirecte par lintermdiaire dInternet, en revanche offre le meilleur cot de mise en place mais une scurit et une qualit de service mdiocres. Des arbitrages furent donc raliss entre la qualit / scurit et les cots de mise en place conduisant privilgier la solution GRX qui prsente le meilleur rapport entre la qualit et le cot pour lensemble des solutions disponibles. Il existe 15 oprateurs de GRX qui sinterconnectent : Belgacom, BT, Deutsche Telekom, France Tlcom, Sonera, Telecom Italia, Telefonica Data, Telenor, Telia International Carrier, Cable & Wireless, UUNet, Equant, Aicent, Comfone et TSI. Lorsque l'usager est dans son rseau nominal, l'activation d'un contexte PDP conduit la cration d'un tunnel entre les nuds SGSN et GGSN de ce rseau nominal. Le GGSN est identifi par le paramtre APN prsent dans le message SM Activate PDP Context Request. Cet APN est traduit par le DNS en une adresse IP de GGSN. Si l'usager est dans un rseau visit, l'activation d'un contexte PDP induit la cration d'un tunnel GTP entre le SGSN visit et le GGSN nominal. Le SGSN visit identifie le GGSN l'aide de l'APN. Cette approche peut tre perue comme inefficace car elle cre un effet trombone, mais en fait, 80% du trafic d'un roamer typique est chang avec des serveurs dans le pays d'origine. Le principal inconvnient de cette solution est le grand nombre de tunnel tablis travers le backbone inter-PLMN (GRX) et l'ajout de nouveaux nuds, les BGs (Border Gateways).
39
Procdure d tablissement de Contexte PDP depuis un rseau visit

MS SGSN visit DNS visit 1. Activate PDP Context Request (, APN, ) 2. DNS Query (APN) Proxy/GRX DNS DNS nominal GGSN nominal
3. DNS Query
4. DNS Response (Adresse DNS nominal) 5. DNS Query (APN) 6. DNS Response (Adresse IP GGSN nominal) 7. DNS Response (Adresse IP GGSN nominal)
8. Create PDP Context Request (, APN, ) 9. Create PDP Context Response

RAB GTP Tunnel RAB : Radio Access Bearer
40
Dans ce scnario, un roamer sattache au SGSN dun rseau visit et active un contexte PDP qui implique un GGSN prsent du rseau nominal. Le SGSN visit doit apprendre ladresse IP de ce GGSN nominal pour lui envoyer une requte GTP-C Create PDP Context Request. Le SGSN visite utilise lAPN soumise par lUE pour interroger le DNS. Le dessin ci-dessus dcrit la procdure de rsolution DNS en dtail. Elle consiste en les tapes suivantes : 1. LUE envoie une requte SM Activate PDP context Request au SGSN visit pour demander ltablissement du context PDP. Ce message contient lAPN du service que veut utiliser lusager, la QoS requise, etc. 2. Le SGSN visit rajoute lAPN lidentifiant du rseau nominal (e.g., mnc001.mcc208.gprs) et envoie une requte DNS son DNS local. 3. Le DNS local nayant pas la correspondance entre cet APN et ladresse IP du GGSN nominal concern, route la demande au DNS du GRX (root DNS)., 4. Le DNS du GRX rpond en retournant ladresse IP du DNS associ loprateur mnc001.mcc208.gprs, savoir Orange France. 5. Le DNS visit interroge alors le DNS nominal pour obtenir la correspondance. 6. Le DNS nominal retourne la ou les adresses IP du (des) GGSN concern(s). 7. Le DNS visit retourne cette information au SGSN visit. 8. Le SGSN visit choisit une des adresses IP si plusieurs lui ont t retournes par son DNS visit et met une requte GTP-C Create PDP Context Request au GGSN correspondant. 9. La rponse GTP-C Create PDP Context Response indique au SGSN qu un tunnel rseau est tabli entre SGSN et GGSN. Il reste au SGSN de demander au BSC ou RNC l accs de crer un RAB (Radio Access Bearer) qui correspond une connectivit entre l UE et le SGSN.
40
Donnes de souscription GPRS prsentes dans le HLR (1)

IMSI : lIMSI est la principale cl de rfrence MSISDN : Le MSISDN de lUE. SGSN Number : Le GT (Global Title) du SGSN auquel sest rattach lUE. SGSN Address : Ladresse IP du SGSN auquel sest rattach lUE.
Simon ZNATY
Copyright EFORT
41
41
Donnes de souscription GPRS prsentes dans le HLR (2)
Chaque IMSI fait rfrence un ou plusieurs enregistrements de souscription de contexte PDP :

PDP Context Identifier : Index du contexte PDP PDP Type : Type de PDP, e.g., IPv4, IPv6. PDP Address : Adresse PDP, e.g., une adresse IPv4 ou IPV6. Ce champ est vide si ladressage est dynamique. Access Point Name : Un label dcrivant le point daccs au rseau de commutation de paquet externe. QoS Profile Subscribed : Le profil de QoS requis pour ce contexte PDP. VPLMN Address Allowed : Spcifie si l UE est autoris utiliser avec ce contexte PDP uniquement un GGSN du rseau nominal (valeur = 0) ou soit un GGSN du rseau nominal, soit un GGSN du rseau visit (valeur = 1).
Copyright EFORT
Simon ZNATY
42
42
Questions ( choix multiples)

A. GPRS est : 1. Une technologie d accs 2. Une technologie rseau B. GPRS est le domaine de commutation de paquet du : 1. Rseau 2G 2. Rseau 3G 3. Rseau 4G C. GPRS fonctionne en : 1. Mode connect 2. Mode non connect D. En situation de roaming, le trafic usager est pris en charge par : 1. Le SGSN et le GGSN visits 2. Le SGSN visit et le GGSN nominal 3. Le SGSN et le GGSN nominal
Simon ZNATY
Copyright EFORT
43
A. Rponses correctes : 1 & 2 GPRS est la fois une technologie daccs qui fournit un dbit de 40 kbit/s descendant et 20 kbit/s montant et une technologie cur de rseau avec les quipements SGSN et GGSN. B. Rponses correctes : 1 & 2 GPRS est le cur de rseau paquet pour les technologies daccs 2G telles que GPRS et EDGE et 3G telles que W-CDMA, HSDPA, HSUPA, HSPA+. La 4G utilise un autre cur de rseau paquet appel ePC (Evolved Packet Core). C. Rponse correcte : 1 Avant de pouvoir mettre ou recevoir des paquets IP, le mobile doit tablir une connexion de donnes appele contexte PDP. Cest pourquoi, le rseau GPRS fonctionne en mode connect. D. Rponse correcte : 2 En situation de roaming GPRS, le trafic est pris en charge par le SGSN visit et le GGSN nominal. Le SGSN identifie le GGSN a impliquer grce lAPN. Le contexte PDP tabli emprunte les rseaux IP des rseaux visit et nominal interconnects entre par le GRX.
43

E. Le mode Direct tunnel s appliqu : 1. L accs 2G uniquement 2. L accs 3G uniquement 3. Les accs 2G et 3G F. GTP (GPRS Tunneling Protocol) est : 1. Un protocole du plan de contrle pour l tablissement/la libration de contexte PDP. 2. Un protocole du plan usager pour la livraison du trafic usager 3. Un protocole des plans de contrle et d usager G. Quelles sont les fonctions ralises durant lenregistrement? 1. Authentification 2. Vrification de lIMEI 3. Tlchargement du profil usager du HLR au SGSN 4. Contrle de session
Simon ZNATY
Copyright EFORT
44
E. Rponse correcte : 2 Le mode direct tunnel ne sapplique que dans le cas de laccs 3G. Par ailleurs, mme en 3G, ce mode peut tre utilis si et seulement si lusager est dans son rseau nominal. En effet, dans le cas o lusager est dans un rseau visit, il est ncessaire que le SGSN visit puisse comptabiliser le nombre doctets mis et reus par lusager; pour ce faire, le SGSN est sur le plan contrle et sur le plan usager. F. Rponse correcte : 3 GTP est la fois un protocole du plan de contrle (GTP-C) et un protocole du plan usager (GTP-U) GTP-C est utilis entre le SGSN et le GGSN afin dtablir/modifier/librer des tunnels rseau. GTP-U est utilis entre le RNC et le SGSN et entre le SGSN et le GGSN afin de transporter des paquets IP dans dautres paquets IP.. G. Rponses correctes : 1,2 & 3. Pendant lenregistrement au domaine paquet mobile, le SGSN authentifie lusager, vrifie lIMEI de lusager (optionnel) et obtient le profil de lusager auprs du HLR. Par contre il ny a pas dtablissement de contexte PDP entre lusager et le rseau. Cette dernire procdure ne peut tre qu linitiative de lusager une fois lusager enregistr et accept par le rseau.
44

H. Un contexte PDP secondaire est 1. Toujours tabli aprs un contexte PDP primaire auquel il sera associ 2. Partage la mme adresse IP que le contexte PDP primaire auquel il est associ 3. A la mme QoS que le contexte PDP primaire auquel il est associ E. I. Le RAB (Radio Access Bearer) est tabli par : 1. le SGSN 2. Le RNC/BSC 3. Le GGSN 4. Le PCRF J. Les QoS possibles supportes par GPRS lors de ltablissement du contexte PDP sont : 1. Conversationnel 2. Streaming 3. Interactif 4. Background
Simon ZNATY
Copyright EFORT
45
H. Rponses correctes : 1 & 2. Un contexte PDP secondaire est toujours tabli aprs le contexte PDP primaire et partage l adresse IP alloue au contexte PDP primaire par le rseau. Par ailleurs la QoS associe au contexte PDP secondaires peut tre diffrente de celle relative au contexte PDP primaire. I. : Rponse correcte : 2 Le RAB est une ressource d accs donc l tablissement/ la modification/la libration est toujours de la responsabilit du nud qui contrle l accs, i.e., le BSC en 2G et le RNC en 3G. J : Rponses correctes : 1, 2, 3 & 4. Les QoS conversationnel (e.g., voix), streaming (e.g. TV mobile), interactif (e.g., chat), backgroup (e.g., mail) sont supportes par le rseau GPRS.
45
3. Evolution Long Terme de la 3G : LTE + ePC = EPS
Simon ZNATY
Copyright EFORT
46
La LTE (Long Term Evolution of 3G) est un projet men par l'organisme de standardisation 3GPP visant rdiger les normes techniques de la future quatrime gnration en tlphonie mobile. Elle permet le transfert de donnes trs haut dbit, avec une porte plus importante, un nombre dappels par cellule suprieur (zone dans laquelle un metteur de tlphonie mobile peut entrer en relation avec des terminaux) et une latence plus faible. En thorie, elle permet datteindre des dbits de lordre de 50 Mbps en lien ascendant et de 100 Mbps en lien descendant, partager entre les utilisateurs mobiles d'une mme cellule. Pour les oprateurs, la LTE implique de modifier le cur du rseau et les metteurs radio. Il faut galement dvelopper des terminaux mobiles adapts. En terme de vocabulaire, le futur rseau sappelle EPS (Evolved Packet System). Il est constitu dun nouveau rseau daccs appel LTE (Long Term Evolution) et dun nouveau rseau cur appel SAE (System Architecture Evolution) ou encore appel ePC (Evolved Packet Core). Lobjectif de ce chapitre est de prsenter la vision de bout en bout du rseau EPS avec son accs, son rseau cur, et les entits associes.
46
3.1. Dfinition et Architecture de Haut Niveau
Simon ZNATY
Copyright EFORT
47
47
Besoins au niveau de l accs LTE

Dbit sur linterface radio : 100 Mbit/s descendant et 50 Mbit/s montant Connexion permanente : Principe des accs haut dbit o la connectivit est permanente pour l accs Internet Dlai pour la transmission de donnes : 30 ms entre lUE et le PDN GW. Mobilit : assure des vitesses comprises entre 120 et 350 km/h Co-existence et Interfonctionnement avec la 3G : Le handover entre E-UTRAN et UTRAN doit tre ralis en moins de 300 ms pour les services temps-rel et 500 ms pour les services non temps-rel. Flexibilit dans lusage de la bande : E-UTRAN doit pouvoir oprer dans des allocations de bande de frquence de diffrentes tailles incluant 1.25, 2.5, 5, 10, 15 et 20MHz. Support du multicast notamment pour les applications multimdia Couverture de cellule importante dans les zones rurales
Copyright EFORT
Simon ZNATY
48
Dbit sur linterface radio : 100 Mbit/s descendant et 50 Mbit/s montant. L interface radio E-UTRAN doit pouvoir supporte un dbit maximum descendant instantan (du rseau au terminal) de 100 Mbit/s en considrant une allocation de bande de frquence de 20 MHz pour le sens descendant et un dbit maximum montant instantan (du terminal au rseau) de 50 Mbit/s en considrant aussi une allocation de bande de frquence de 20 MHz. Les technologies utilises sont OFDMA (Orthogonal Frequency Division Multiple Access) pour le sens descendant et SC-FDMA (Single Carrier Frequency Division Multiple Access) pour le sens montant. Cela correspond une efficacit du spectre de 5 bit/s/Hz pour le sens descendant (HSDPA a pour efficacit 2.9 bit/s/Hz) et 2,5 bit/s/Hz pour le sens montant (HSUPA 1,1 bit/s/Hz). Avec la 3G il est ncessaire d allouer une bande de frquence de 5 MHz. Avec la LTE, il est possible d oprer avec une bande de taille diffrente avec les possibilits suivantes : 1.25, 2.5, 5, 10, 15 et 20MHz, pour les sens descendant et montant. L intention est de permettre un dploiement flexible en fonction des besoins des oprateurs et des services qu ils souhaitent proposer. Connexion permanente : Principe des accs haut dbit o la connectivit est permanente pour l accs Internet. Mme si la connexion est permanente au niveau du rseau, il est ncessaire pour le terminal de passer de ltat IDLE ltat ACTIF lorsquil sagira denvoyer ou recevoir du trafic. Ce changement dtat sopre en moins de 100 ms. Le rseau pourra recevoir le trafic de tout terminal rattach puisque ce dernier dispose dune adresse IP, mettre en mmoire ce trafic, raliser lopration de paging afin de localiser le terminal et lui demander de rserver des ressources afin de pouvoir lui relayer son trafic. Dlai pour la transmission de donnes : 5 ms entre lUE et le PDN GW, ceci dans une situation de non-charge o un seul terminal est ACTIF sur linterface radio. La valeur moyenne du dlai devrait avoisiner les 30 ms en situation de charge moyenne de linterface radio. Ceci permet de supporter les services temps rel IP nativement, comme la voix sur IP et le streaming sur IP. Mobilit : assure des vitesses comprises entre 120 et 350 km/h. Le handover pourra seffectuer (la LTE ne permet que le hard handover et non pas le soft handover) dans des conditions o lusager se dplace grande vitesse. Co-existence et Interfonctionnement avec la 3G : Le handover entre E-UTRAN et UTRAN doit tre ralis en moins de 300 ms pour les services temps-rel et 500 ms pour les services non temps-rel. Il est clair quau d bit peu de zones seront couvertes par la LTE. Il sagira pour loprateur que sassurer que le handover entre LTE et la 2G/3G est toujours possible. Le handover pourra aussi seffectuer entre LTE et les rseaux CDMA-2000. Les oprateurs CDMA volueront aussi vers la LTE qui devient le vrai standard de communication mobile de 4me gnration. Flexibilit dans lusage de la bande : Comme indiqu prcdemment E-UTRAN doit pouvoir oprer dans des allocations de bande de frquence de diffrentes tailles incluant 1.25, 2.5, 5, 10, 15 et 20MHz. Support du multicast notamment pour les applications multimdia telles que la tlvision en broadcast. Couverture de cellule importante dans les zones urbaines et rurales : Comme la LTE pourra oprer sur des bandes de frquences diverses et notamment basses comme celle des 700 MHz (dailleurs choisie par les oprateurs AT&T et Verizon Wireless), il sera possible de considrer des cellules qui pourront couvrir un large diamtre). 48
Dbit de l interface radio et flexibilit de spectre
L interface radio E-UTRAN doit pouvoir supporte un dbit maximum descendant instantan (du rseau au terminal) de 100 Mbit/s en considrant une allocation de bande de frquence de 20 MHz pour le sens descendant et un dbit maximum montant instantan (du terminal au rseau) de 50 Mbit/s en considrant aussi une allocation de bande de frquence de 20 MHz. 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 considrant HSDPA 14,4 Mbit/s avec une allocation d une bande de 5 MHz, l efficacit spectrale est de 2,9 bit/s/Hz dans le sens descendant. Avec la 3G il est ncessaire d allouer une bande de frquence de 5 MHz. Avec la LTE, il est possible d oprer avec une bande de taille diffrente avec les possibilits suivantes : 1.25, 2.5, 5, 10, 15 et 20 MHz, pour les sens descendant et montant. L intention est de permettre un dploiement flexible en fonction des besoins des oprateurs et des services qu ils souhaitent proposer.
Copyright EFORT
Simon ZNATY
49
49
Bande de frquence pour le dploiement de la LTE
Un oprateur peut introduire la LTE dans de nouvelles bandes de frquence o il est plus simple de disposer de 10 ou 20 MHz de bande.
Par exemple, la bande 2.6 GHz ou le spectre du dividende numrique 700, 800 MHz ou rutiliser les bande des rseaux 2G et 3G existantes telles que 850, 900, 1800, 1900, 2100 MHz
La LTE pourrait mme tre dploye sur toutes ces bandes et sur d autres plus tard. Les bandes 2.6 GHz (pour la capacit) et 700/800 MHz (couverture plus importante) sont une bonne combinaison. La LTE offre un choix de bande de frquence compris entre 1,25 et 20 MHz.

La bande la plus large est ncessaire pour les dbits les plus importants. Par exemple, TeliaSonera Oslo et Stockholm utilise chaque fois une bande de 20 MHz.
Copyright EFORT
Simon ZNATY
50
Les bandes qui sont considres pour la LTE sont diverses (700 MHz, 800 MHz, 900 MHz, 1700 MHz, 1800 MHz, 1900 MHz, 2100 MHz, etc.) mais celles qui semblent s imposer sont dans les bandes 2.6GHz et 800 MHz. 2.6 GHz est appropri pour les zones forte densit de population et donc avec une couverture rduite, alors que 800 MHz, issu du dividende numrique est appropri pour les zone rurales avec une couverte importante.
50
Bandes de Frquence UMTS et LTE en France
W-CDMA (FDD)

UL : 1920 1980 MHz, soit 60 MHz DL : 2110 2170 MHz soit 60 MHz 12 bandes ou porteuses de 5 MHz chacune dans le sens montant (UL) et dans le sens descendant (DL). Ces bandes de frquence sont aussi utiliss pour les technologies HSDPA, HSUPA et HSPA+ De nombreuses bandes sont possibles (700, 800, 900, 1700, 1800, 1900, 2100, 2600 MHz, etc.) mais celles qui s imposent sont les bandes 2.6 GHz et 800 MHz. En France les largeurs de bandes aux enchres sont: UL : 25002570 MHz DL : 26202690 MHz UL : 832 MHz862 MHz DL : 791 MHz821 MHz
Copyright EFORT
LTE
Simon ZNATY
51
Deux technologies daccs radio (UTRA - Universal Terrestrial Radio Access) sont proposes dans lUMTS, savoir FFD (Frequency Division Duplex) et TDD (Time Division Duplex. C est FDD qui est utilis en Europe. UTRA FDD (FrequencyDivision Duplex): 2 groupes (un groupe montant et un groupe descendant) de 12 porteuses de largeur 5 MHz ont t identifis pour la technologie UTRA FDD. En France, lART a initialement attribu 3 porteuses FDD chaque oprateur ayant acquis une licence UMTS (Orange, SFR, Bouygues), puis une porteuse Free, puis une porteuse supplmentaire Orange et une porteuse supplmentaire SFR. En W-CDMA, l usager est limiter pour ses services de donnes 384 kbit/s dans les deux sens. Les mmes porteuses UMTS sont aussi utilises pour les technologies HSDPA, HSUPA et HSPA+. Alors qu en W-CDMA, HSDPA et HSUPA, l usager n exploite qu une bande de 5 MHz, Alors qu en 3G, la bande de frquence minimum que doit acqurir un oprateur est 5 MHz, en LTE (4G), l usage de la bande est plus flexible. Il est possible d oprer avec une bande de frquence de diffrentes tailles incluant 1.25, 2.5, 5, 10, 15 et 20MHz.Le dbit est proportionnel la bande de frquence acquise. Il est de 5 bits/s/Hz dans le sens descendant avec la technologie OFDMA (Orthogonal Frequency Division Multiple Access) , et de 2,5 bits/s/Hz dans le sens montant avec la technologie SC-FDMA (Single Carrier Frequency Division Multiple Access).. Les bandes qui sont considres pour la LTE sont diverses (700 MHz, 800 MHz, 900 MHz, 1700 MHz, 1800 MHz, 1900 MHz, 2100 MHz, etc.) mais celles qui semblent s imposer sont dans les bandes 2.6GHz et 800 MHz. 2.6 GHz est appropri pour les zones forte densit de population et donc avec une couverture rduite, alors que 800 MHz, issu du dividende numrique est appropri pour les zone rurales avec une couverte importante. En France, les bandes suivantes sont en vente : UL : 25002570 MHz; DL : 26202690 MHz; UL : 832 MHz862 MHz; DL : 791 MHz821 MHz. On notera que 70 MHz dans chaque sens sont disponibles dans les 2.6 GHz alors que la largeur est limite 30 MHz dans la bande des 800 MHz. La bande 800 MHz, dont la largeur est limite 30 MHz dans chaque sens, ne permet pas dattribuer des quantits de frquences leves un grand nombre doprateurs : cest pourquoi la mutualisation des frquences entre oprateurs peut prsenter lintrt de concilier lattribution de plusieurs licences et la mise en oeuvre de canalisations leves dans la bande 800 MHz. Orange et Free ont obtenu chacun 20 Mhz dans la bande 2.6 Gz alors que SFR et Bouygues nont obtenu chacun que 15 MHz. Dans la bande 800 Mhz, Orange, SFR et Bouygues ont obtenu chacun 10 MHz. Free na rien obtenu.
51
Comparaison LTE / 3G
LTE
Dbit thorique Dbit attendu Efficacit spectrale Bande de frquence Couverture zone rurale DL : 100 Mbit/s UL : 50 Mbit/s DL : 5 Mbit/s
EVDO Rev-A
DL- 3,1 Mbps UL- 1,8 Mbps DL : 400 kbit/s
HSPA
DL- 14,4 Mbps UL- 5,75 Mbps DL : 1 Mbit/s
~2,5-5 bps/Hz
~1-2 bps/Hz
~1,1-2,9 bps/Hz
1.25-20 MHz
1,25 MHz
5 MHz (Maintenant 10 MHz) 1-5 Miles
1-30 Miles (Thorique)
1-5 Miles
Simon ZNATY
Copyright EFORT
52
52
ePC : Evolved Packet Core
SAE (System Architecture Evolution) est le nom du projet, ePC (Evolved Packet Core) est le nom du rseau cur volu. ePC est un rseau cur paquet tout IP ePC fonctionne dans le cas de roaming en mode home routed ou en mode local breakout ePC interagit avec les rseaux 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 dtection de virus) et une taxation volue (taxation base sur les flux de service).
53
Simon ZNATY
Copyright EFORT
SAE est le nom du projet, EPC (Evolved Packet Core) est le nom du rseau cur volu. EPC est un rseau cur paquet tout IP. A la diffrence des rseaux 2G et 3G o lon distinguait les domaines de commutation de circuit (CS, Circuit Switched) et de commutation de paquet (PS, Packet Switched) dans le rseau coeur, le nouveau rseau ne possde quun 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 tlphonie, etc. EPC fonctionne en situation de roaming en mode home routed ou en mode local breakout . Lorsquun client est dans un rseau visit, son trafic de donnes est : Soit rout son rseau nominal qui le relaye ensuite la destination (home routed) Soit directement rout au rseau de destinataire sans le faire acheminer son rseau nominal (local breakout). Le mode local breakout est particulirement interessant pour les applications temps rel telles que la voix qui ont des contraintes de dlai fortes. EPC interagit avec les rseaux paquets 2G/3G et CDMA-2000 en cas de mobilit. Il est possible de faire acheminer le trafic de lEPC vers laccs LTE, CDMA-2000 (paquet), 2G (paquet) et 3G (paquet) et ainsi garantir le hadover entre ces technologies daccs. EPC supporte les Default bearers et Dedicated bearers. Lorsqe lusager se rattache au rseau EPC, ce dernier lui cre un dfaut bearer qui reprsente une connectivit permanente (maintenue tant que lusager est rattach au rseau) mais avec une qualit de service best effort. Lorsque lusager souhaitera tablir un appel qui requiert une certaine qualit de service telle que lappel voix ou visiophonie, le rseau pourra tablir pour la dure de lappel un dedicated bearer qui supporte la qualit de service exige par le flux de service. EPC supporte le filtrage de paquet (deep packet inspection par exemple pour la dtection de virus) et une taxation volue (taxation base sur les flux de service). En effet la LTE fournit des mcanismes de taxation trs sophistiqus permettant de taxer le service accd par le client sur la based du volume, de la session, de la dure, de lvnement, du contenu, etc.
53
Concepts EPS
Architecture plate et simplifie compare celle hirarchique 2G/3G Architecture uniquement paquet compare larchitecture 2G/3G circuit et paquet Connectivit permanente tout-IP compare des contextes PDP temporaires ou permanents en 2G/3G dans le domaine paquet Interface radio totalement partage compare des ressources ddies et partages dans larchitecture 2G/3G Handover possible vers les rseaux 2G/3G et CDMA/CDMA2000.
Simon ZNATY
Copyright EFORT
54
LEPS (Evolved packet System) reprsente lensemble du rseau savoir LTE et ePC. Il a les caractristiques suivantes : Il possde une architecture plate et simplifie compare celle hirarchique 2G/3G puisque la fonction de contrleur dantenne disparat. La seule entit prsente dans laccs est leNodeB qui peut tre assimil un nodeB+RNC. Il sagit dune architecture uniquement paquet compare larchitecture 2G/3G circuit et paquet. Cela signifie que tous les flux de service seront pris en charge par ce domaine paquet alors qu auparavant les services de tlphonie taient pris en charge par un domaine ddi circuit constitu de MSC ou MSC Server/MGW. Il permet une connectivit permanente tout-IP compare des contextes PDP temporaires ou permanents en 2G/3G dans le domaine paquet. En effet, gnralement le contexte PDP tabli dans le rseau paquet 3G a une dure de vie courte. Aprs l expiration d un temporisateur d inactivit, le contexte PDP est libr par le rseau.Avec l EPS, le bearer (quivalente du contexte PDP) est tabli ds la mise sous tension du mobile et n est libr qu la mise hors tension du mobile. Son interface radio est totalement partage entre tous les usagers en mode ACTIF compare des ressources ddies et partages dans larchitecture 2G/3G. Les appels voix et visiophonie requirent des ressources ddies en 3G. Il permet des handover vers les rseaux 2G/3G et CDMA/CDMA2000 afin dassurer des communications sans couture en environnement htrogne.
54
Capacit du terminal LTE
Releases 8, 9 et 10 (LTE)
Catgorie UE 1 2 3 4 5 Dbit maximum descendant (Mbps) 10 50 100 150 300 Dbit maximum montant (Mbps) 5 25 50 50 75
Release 10 uniquement (LTE-Advanced)
Catgorie UE 6 7 8 Dbit maximum descendant (Mbps) 300 300 3000 Dbit maximum montant (Mbps) 50 150 1500
Simon ZNATY
Copyright EFORT
55
La systme LTE a t conu pour supporter cinq catgories d UE, du terminal bon march ayant des caractristiques proches du terminal HSPA, au terminal trs haute capacit qui exploite au maximum la technologie LTE. Les capacits des cinq catgories de terminaux LTE sont indiques au tableau ci-dessus. La LTE-Advanced rajoute trois nouvelles catgories. Dans la catgorie 8, le terminal exploite 100 MHz de frquence avec un dbit de 30 bit/s/Hz dans le sens descendant et de 15 bit/s/Hz dans le sens montant.
55
Architectures UTRAN et Evolved UTRAN

Core Network
Iu Iu S1 Iur S1 X2
Core Network
RNC
RNC
Iub
Iub
Iub
Iub
eNodeB
eNodeB
NodeB
Architecture UTRAN
Architecture E-UTRAN
Simon ZNATY
Copyright EFORT
56
LeNodeB est responsable de la transmission et de la rception radio avec lUE. A la diffrence de lUTRAN 3G o sont prsentes les entits Node B et RNC, larchitecture E-UTRAN ne prsente que des eNodeB. Les fonctions supportes par le RNC ont t rparties entre leNodeB et le les entits du rseau cur MME/Serving GW. LeNodeB dispose dune interface S1 avec le rseau cur. Linterface S1 consiste en S1-C (S1-Contrle) entre leNodeB et le MME et S1-U (S1-Usager) entre leNodeB et le Serving GW. Une nouvelle interface X2 a t dfinie entre eNodeBs adjacents. Son rle est de minimiser la perte de paquets lors de la mobilit de lusager en mode ACTIF (handover). Lorsque lusager se dplace dun eNodeB un autre eNodeB, de nouvelles ressources sont alloues sur le nouvel eNodeB pour lUE ; or le rseau continue transfrer les paquets entrants vers lancien eNodeB tant que le nouvel eNodeB na pas inform le rseau quil sagit de lui relayer les paquets entrants pour cet UE. Pendant ce temps lancien eNodeB relaie les paquets entrants sur linterface X2 au nouvel eNodeB qui les remet lUE. La figure dcrit larchitecture E-UTRAN avec ses eNodeB et les interfaces X2 (entre les eNodeB) et S1 (entre eNodeB et entits du rseau cur MME/Serving GW).
56
Interfaces Logiques et Physiques

PDN GW Rseau IP MME Serving GW
Rseau IP IP Router
Connectivit d accs e.g., FTTH
Connectivit d accs e.g., FTTH
Interface X2 Logique
57
57
La famille FTTx (Fibre To The x)

Implmentation possible: P2MP ou P2P (sans splitter)
ONT
Fibre
FTTH: Home
Terminaison Client Optique (ONT) ONT
Fibre
ONT ONU VDSL
Fibre
coupler
Fibre Fibre
coupler
FTTC: Curb
Cuivre
Fibre OLT
FTTB: Building
VDSL
Mixed access : Optical and Copper
OLT: Optical Line Termination ONT: Optical Network Termination ONU: Optical Network Unit Splitter: Coupler
Cuivre
Simon ZNATY
ONU
FibreCopyright EFORT
coupler
58
Avec l'architecture FTTH (Fiber to the Home), l'OLT est l unit de raccordement optique multiplexant plusieurs clients. Pour distribuer la fibre vers les diffrents utilisateurs, il est possible de mettre en oeuvre des coupleurs qui permettent des liaisons point--multipoint (P2MP) ou raliser des liens point point (P2P). Le mode P2P est aussi appel FTTH ddi alors que le mode P2MP est dnomm FTTH partag. Dans le cas de FTTC (Fiber to the Curb), traduit en franais par "fibre jusqu'au sousrpartiteur", la fibre relie l'OLT un ONU. l'ONU assure les couplages optolectroniques permettant d'offrir des terminaisons sur cuivre. Dans le cas du VDSL, l'ONU est un DSLAM. Le FTTB (Fiber to the Building) relie un immeuble un OLT via la fibre optique. Nanmoins, du pied de l'immeuble jusqu' l'abonn, c'est la technologie VDSL2 qui est utilise. Ce sont donc la fibre optique et le paire de cuivre qui sont utilises pour faciliter le dploiement mais au dtriment de la puissance de la bande passante qui sera limite 100 Mbits. Si la fibre va jusqu'au client (FTTH), l'ONU est absent. La fibre aboutit l'ONT, qui termine la liaison optique.
58
Architecture cible EPS (LTE+ePC)

LTE : Long Term Evolution ePC : Evolved Packet Core GW : Gateway MME : Mobility Management Entity PCRF : Policy and Charging Rules Function PDN : Packet Data Network HSS : Home Subscriber Server EIR : Equipment Identity Register IMS : IP Multimedia Subsystem PCEF : Policy and Charging Enforcement Function
EIR
HSS
Cx, Sh
IMS
S6 Rx
S13
PCRF
Gx
UE
eNode B
S1-C S1-U Rseau IP
MME
S11 Rseau IP S5
PCEF
Rseau IP
LTE
Interface DIAMETER
Simon ZNATY
Serving GW
PDN GW
ePC
Copyright EFORT
Plan de contrle Plan usager59
Le rseau EPS (LTE + ePC) consiste en les entits 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) LeNodeB est responsable de la transmission et de la rception radio avec lUE. A la diffrence de lUTRAN 3G o sont prsentes les entits Node B et RNC, larchitecture E-UTRAN ne prsente que des eNodeB. Les fonctions supportes par le RNC ont t rparties entre leNodeB et les entits du rseau cur MME/Serving GW. LeNodeB dispose dune interface S1 avec le rseau cur. Linterface S1 consiste en S1-C (S1-Contrle) entre leNodeB et le MME et S1-U (S1Usager) entre leNodeB et le Serving GW. Le MME (Mobility Management Entity) est le nud responsable du contrle dans le rseau EPC (Evolved Packet Core). Il est responsable de lenregistrement des mobiles, de leur authentification, de leur joignabilit lorsqu ils sont dans l tat de repos (incluant paging). de la slection du Serving GW et du PDN GW. Cest au MME de slectionner 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 rseau. 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 rseau d accs. Il ralise par ailleurs les fonctions d interception lgale et de comptabilit par usager pour la taxation inter-oprateurs. Le PGW (PDN GW, passerelle PDN) fournit la connectivit vers les rseaux externes tels que Internet et Intranets. Il ralise les procdures d allocation de ladresse IP au mobile, . D interception lgale et de taxation des flux de service montants et descendants. Le HSS (Home Subscriber Server) est la base de donnes contenant les donnes de souscription de l usager EPS. L interface au HSS est S6 base sur le protocole DIAMETER. Le PCRF (Policy and Charging Rules Function) fournit les rgles de taxation au PDN GW afin que ce dernier pisse raliser la taxation des flux de service montants et descendants.
59
Architecture de Taxation
LTE : Long Term Evolution ePC : Evolved Packet Core GW : Gateway MME : Mobility Management Entity PCRF : Policy and Charging Rules Function PDN : Packet Data Network HSS : Home Subscriber Server EIR : Equipment Identity Register S13 IMS : IP Multimedia Subsystem PCEF : Policy and Charging Enforcement Function
EIR
HSS
Cx, Sh
IMS
Rx S6
PCRF
Gx Gy
Ro
Rf
OCS OFCS
Gz
UE
eNode B
S1-C S1-U Rseau IP
MME
S11 S5 Rseau IP
PCEF
Rseau IP
LTE
Serving GW
PDN GW
ePC
Interface DIAMETER Plan de contrle Plan usager
Copyright EFORT
Simon ZNATY
60
L entit PCRF (Policy and Charging Rules Function) permet la fonction PCEF (Policy and Charging Enforcement Function) incluse dans le PDN GW d apprendre les rgles 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. 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 consomms 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 crdit de l'OCS et soumet des tickets de taxation l'OFCS. Il est noter que l'entit PCEF peut tre indpendante du PDN GW et dans ce cas se retrouve derrire le PDN GW l'interface des rseaux externes IP.
60
Mode quasi-associ pour la signalisation DIAMETER

Agent
HSS
S6a, S6d, SWx, Cx, Sh Gz, Rf Gy, Ro, Rc, Re Gx, S9, Rx Cx, Sh, Rx, Ro, Rf
OFCS OFCS OCS OCS PCRF PCRF
MME MME
S6a S6d
Agent
Gx, Gy, Gz
IMS
I-CSCF S-CSCF P-CSCF AS MRF MGCF BGCF
61
PCEF PCEF S4-SGSN PDN GW

Interface DIAMETER
Pour des raisons de scalabilit et de simplicit de configuration, le mode quasiassoci devrait tre choisi par les oprateurs pour le transport de la signalisation DIAMETER. Un agent (similaire un STP dans le rseau SS7) relie l ensemble des nuds devant dialoguer avec le protocole DIAMETER. Ce mme agent route le trafic de signalisation DIAMETER entre ces nuds. Tous les nuds par dfaut relaient leur signalisation l agent DIAMETER qui dispose de toute l intelligence de routage. Lorsque la destination DIAMETER appartient un autre rseau, l agent transfert la signalisation DIAMETER un autre agent (international) qui dispose de la connectivit pour acheminer le trafic DIAMETER au rseau de destination.
61
Types de noeud Diameter

Client (e.g., MME, S-CSCF) Server (e.g., HSS) Agent

Relay Agent Proxy Agent Redirect Agent (e.g., SLF) Translation Agent (e.g., MAP DIAMETER IWF)
Redirect Agent
2. Request 1. Request 6. Answer
Redirect.RealmB.com
3. Redirect Notification 4. Request 5. Answer

Copyright EFORT
Client Client.RealmA.com
Relay/Proxy Agent
Server
Simon ZNATY
Server.RealmA.com
62
Un nud DIAMETER est un hte qui implante le protocole DIAMETER. Un client DIAMETER est un nud la frontire du rseau qui ralise un contrle daccs. Des exemples de clients DIAMETER sont les Network Access Servers (NAS), MME, S4-SGSN. Un serveur DIAMETER prend en charge les demandes dauthentification, dautorisation et de taxation pour un domaine donn (appel realm). Un exemple de serveur est le HSS. Un agent DIAMETER est un nud DIAMETER qui fournit des services de relai, de proxy ou de traduction. Un agent relai route les messages DIAMETER base sur linformation prsente dans les messages. Les agents sont transparents. Un agent relai peut modifier les messages DIAMETER uniquement en insrant et retirant les informations de routage mais ne peut pas modifier les autres lments dinformation du message. Un agent proxy comme un agent relai route le message DIAMETER. Toutefois un agent Proxy peut modifier les messages afin de raliser un contrle daccs, un contrle de politiques, etc. Un exemple dagent proxy est le lentit PCRF dans larchitecture LTE. Un agent de redirection fournit aussi une fonction de routage. Il sert de directory permettant gnralement la traduction de Nom de domaine Adresse du serveur. A la diffrence des autres types dagent (relai et proxy) qui acheminent les messages DIAMETER, lagent de redirection retourne un type particulier de message de rponse lmetteur de la requte. La rponse contient linformation de routage afin que lmetteur puisse retransmettre son message directement a serveur destinataire. Un exemple dagent de redirection est lentit SLF dans larchitecture IMS. Un agent de traduction traduit les protocoles tels que DIAMETER et RADIUS ou DIAMETER et MAP. Un exemple dagent de traduction est lentit IWF de larchitecture LTE qui traduit DIAMETER en MAP. A la figure 1, le chemin de la requte et de la rponse est 1, 4, 5 et 6 dans le cas du traitement uniquement par des agent relai/proxy. Le chamin est 1, 2, 3, 4, 5, et 6 si lagent de redirection est aussi impliqu.
62
Scnario possible pour l interaction entre MME et HSS dans l EPS

Destination Realm : epc.mnc001.mcc208.3gppnetwork.org (Orange France) Origin host : mmec2.mmegi1.mme.epc.mnc010.mcc206.3gppnetwork.org Origin Realm : epc.mnc010.mcc206.3gppnetwork.org (Mobistar Belgique) IMSI : 208012245678911
MME
1. Request 6. Answer
Agent Relai Diameter
Agent Proxy Diameter
HSS
Simon ZNATY
Copyright EFORT
63
Le MME visit du rseau Mobistar drive le nom de domaine du rseau nominal de lusager mobile LTE partir de lIMSI de lusager. Le nom de domaine est epc.mnc01.mcc208.3gppnetwork.org (Orange France) 1. MME identifie que tout message DIAMETER destination dun rseau externe Mobistar doit tre achemin au Proxy Agent de Mobistar. Une association SCTP existe entre le MME et le Proxy Agent puisquil sagit dun peer. Alors il met la requte DIAMETER S6a Update Location request sur cette association SCTP. La requte DIAMETER contient les AVPs suivants : Origin host, origin realm, destination realm. Il LAVP Destination-Host nest pas prsent car le MME ne connat pas le HSS dans le rseau Orange France (Rseau nominal) qui dispose du profil de lusager. 2. La requte DIAMETER est reue par le Proxy Agent. Ce dernier analyse lAVP Destination-Realm de la requte reue et partir de sa table de routage de Realm, il lui est possible didentifier le prochain agent qui peut prendre en charge la requte. Il relaie la requte un autre Proxy Agent dans le rseau nominal Orange France. 3. Ce Proxy Agent dOrange France interroge sa table de routage applicative qui lui permet de traduire l IMSI de l usager qui souhaite s enregistrer en le hotname du HSS qui dispose du profil de cet usager. Le Proxy Agent peut maintenant relayer la requte au HSS. Le HSS est prsent dans la table de peer du Proxy Agent. 4., 5., 6. La rponse DIAMETER suit le mme chemin que la requte. La rponse contient les AVPs Origin-Host et Origin-Realm qui correspondent au hostname et au nom de domaine du HSS.
63
Roaming international avec des agents Diameter

Broker e.g., Syniverse
2. Request 3. Request
Broker e.g., IBNF

8. Answer 9. Answer
4. Request
7. Answer
MME
Agent Proxy Diameter
HSS
Rseau visit
FT IBNF : France Telecom International Backbone Network & Factory (IBNF)
Rseau nominal
Interface DIAMETER interface Message DIAMETER
64
Les Agents Diameter seront des composants importants du futur rseau mobile de la mme manire que les STPs/IP STPs sont les composants importants du rseau mobile actuel. Les agents Diameter sont obligatoires pour le roaming international dans l environnement EPS. Une hirarchie d agents peut exister incluant des agents nationaux, des agent nationaux/internationaux et des agents uniquement internationaux.Syniverse et IBNF (International and Backbone Network Factory) correspondent des brokers internationaux.
64
Fournisseurs d Agents DIAMETER
Tekelec : Diameter Signaling Router (DSR) (500 000 messages/s)
Produit indpendant (standalone) Produit indpendant
Traffix Systems : Signaling Delivery Controller (SDC) (1 million messages/s)
ACME Packet : Policy Exchange Controller (PEC) (750 000 messages/s)
Produit indpendant ou intgr dans le SBC d ACME (ACME Packet Net-Net Session Director)
Huawei : Unified Signaling Routing Solution IntelliNet : Accelero Diameter Routing Agent
Produit indpendant Produit indpendant Produit indpendant ou intgr dans le PCRF ou le HSS de Bridgewater
Openet : Dynamic Context Router (DCR)
Bridgewater : Diameter Routing Agent (DRA).
Simon ZNATY
Copyright EFORT
65
Requirements for a DIAMETER Agent

3G/LTE/IMS Interface Support Supports a wide range of 3G/LTE/IMS interfaces including S6a, S6d, S9, S13, Cx/Dx, Sh, Rf/Ro, Gq/Gq, e2, e4, Rx, Gx, Gxx, Gy, Gz and many more. All these interfaces should be 3GPP standards compliant. Transports Support Supports TCP and SCTP based transports for communicating with Diameter peers IPv4 and IPv6 version support with version adaptation Security Support Supports IPSec and TLS transport level security mechanisms and provisions Peer Discovery Supports Dynamic Peer Discovery as per RFC 3588 and GSMA specification Using Table lookups and NAPTR/DNS queries S6a User-Identity to HSS Resolution High Performance and Scalability Among the industry leading solution in-terms of performance and scalability Supports a multi-threaded and load balancer based architecture that scales to handle thousands of messages/sec with low latency and CPU and memory consumption High Availability Supports 1+1 Active-Standby Redundancy mechanism for High Availability Congestion Management and Overload Control Built-in Congestion Management and Overload control mechanisms Traffic Load Balancing Capability to load balance traffic based on Diameter and Application specific AVPs
65
Le Rseau Evolved Packet Core
Le rseau cur appel ePC (Evolved Packet Core) ou SAE (System Architecture Evolution) consiste en les entits suivantes :

Mobility Management Entity (MME) Serving Gateway Packet Data Network Gateway (PDN GW)
Les composants suivants sont utiliss par l ePC mais ne sont pas inclus dans l ePC:

Home Subscriber Server (HSS) Policy and Charging Rules Function (PCRF) Online Charging System (OCS) Offline Charging System (OFCS)
Copyright EFORT
Simon ZNATY
66
Les seuls lments prsents dans lePC sont les MME, les Serving GW et PDN GW. Le HSS sert lePC, lIMS et les rseaux 2G et 3G. Le PCRF est utilis par le rseau GPRS (fonction PCEF du GGSN) et par le rseau ePC (fonction PCEF du PDN GW). Les entits OCS et OFCS sont aussi utilises par les rseaux GPRS et ePC. LePC possde un autre composant important pour les accs non-3GPP, appel ePDG (Evolved Packet Data Gateway).
66
Evolution du domaine paquet vers une architecture plate

Release 6 Release 7 Direct Tunnel Release 7 Direct Tunnel et RNC dans Node B Release 8 LTE & ePC
PGW
GGSN
GGSN
GGSN
SGW
SGSN
SGSN
SGSN
MME
RNC
RNC
Plan Contrle Plan Usager
Node B
Simon ZNATY
Node B
RNC Node B
Copyright EFORT
eNode B
67
67
Client
ONT
Common IMS - Architecture IMS RACS0 indpendante de laccs Fiber FTTH Fiber OLT
Coupler
SLF
AS
SIP
Client
xDSL IP DSLAM Backbone

xDSL MME
RACS1 BAS
HSS
Diameter
MGCF
UE eNodeB
EPS
PCRF2 PDN GW
PCRF3
SIP
IMS
ISUP
IP Network
Serving GW UE Node B RNC SGSN 3G
S-CSCF SIP P-CSCF

RTP
SGW MRF
Megaco ISUP
GGSN PCRF4
HA
ATM
MS BTS BSC
IP Network
IP Network
EVDO
PDSN
IP Network
WLAN WLAN PDG Access Network

Client
CM CMTS HFC, Hybrid Fiber Coaxial BS
PCRF5 Routeur
CABLE
RACS6 HES RACS7
BGF
Backbone IP
IMS-MGW
MS
WiMAX ASN-GW PSTN access
RTC
BGF IPX
Copyright EFORT
Simon ZNATY
Analog/ISDN
68
MSAN
Chaque rseau daccs a sa propre mthode dattachement et de rservation de ressources. Larchitecture Common IMS qui a pour objectif lindpendance par rapport laccs sappuie sur les accs spcifiques mais dispose dune interface normalise pour demander les services de nimporte quel type daccs. Le diagramme ne montre pas tous les accs possibles et dans ce sens n est pas exhaustif.
AS : Application Server ASN-GW : Access Service Network Gateway ATM : Asynchronous Transfer Mode BAS : Broadband Access Server BGF : Border Gateway Function BSC : Base Station Controller BTS : Base Transceiver Station CDMA : Code Division Multiple Access CSCF : Call Session Control Function CS-MGW : Circuit Switched Media Gateway DSL : Digital Subscriber Line DSLAM: DSL Access Multiplexer EPS : Evolved Packet system GGSN : Gateway GPRS Support Node GW : Gateway HA : Home Agent HFC : Hybrid Fiber Coaxial HSS : Home Subscriber Server IMS : IP Multimedia Subsystem ISDN : Integrated Services Digital Network LMDS : Local Multipoint Distribution Service MME : Mobility Management Entity MGCF : Media Gateway Control Function MRF : Multimedia Resource Function MSAN : Multi-Service Access Npde MS : Mobile Station PCRF : Policy & Charging Rules Function PDF : Policy Decision Function PDG : Packet Data Gateway PDN : Packet Data Network PDSN : Packet Data Serving Network RACS : Resource Admission Control Subsystem RNC : Radio Network Controller SGSN : Serving GPRS Support Node SGW : Signaling Gateway UE : User Equipment UMTS : Universal Mobile Telecommunications System WLAN : Wireless Local Area Network
68
Questions oui-non
A. EPS est une technologie de rseau d accs comme l est l ADSL B. EPS permet la mobilit des paquets C. EPS permet l interface Internet et Intranet D. EPS est un rseau en mode connect E. EPS fournit des services multimdia F. EPS fournit des services de tlphonie
Simon ZNATY
Copyright EFORT
69
A. Oui. EPS est un accs large bande des rseaux IP dont l Internet ou l Intranet tout comme l est l ADSL. B. Oui. Si l usager se dplace pendant sa session de donnes, les paquets sont rerouts automatiquement vers sa nouvelle localisation. Il y a donc continuit de la session de donnes mme si l usager de dplace vers accs autres que 4G, comme 3G/3G ou WiFi. C. Oui. C est le but mme d un accs large bande. D. Oui. Il faut tablir des bearers afin de pouvoir envoyer ou recevoir des paquets IP. Il existe donc comme en GPRS, des procdures d tablissement, modification et libration de bearer. Un bearer est comparable une connexion PPP entre le modem ADSL et le BAS sauf que le bearer est reconfigurable afin de prendre en compte la mobilit de l UE. E. Non. EPS n est qu un rseau d accs large bande. Il n offre aucun service IP. Les plates-formes de service du monde IP fournissent les services IP. Il s agit des serveurs de streaming, les serveurs de MMS, les services de mail, les serveurs WEB, etc. F. Non. Les services de tlphonie sont assimils des services IP et sont donc offerts par les plates-formes de service sur IP telles que celles de l IMS.
69
Questions (a choix multiples)

A. ePC consiste en les composants suivants : 1. MME 2. Serving GW 3. PDN GW 4. HSS 5. PCRF 6. eNode B 7. Architecture IMS B. ePC est un : 1. Rseau en mode non connect 2. Rseau en mode connect C. Quelles sont les fonctions ralises lors de lenregistrement : 1. Authentification 2. Vrification dIMEI 3. Tlchargement du profil de lusager du HSS au MME 4. Contrle de session D. En situation de roaming, le MME visit interagit avec le HSS du rseau nominal en utilisant le protocole DIAMETER: 1. Directement 2. travers des agents DIAMETER
Simon ZNATY
Copyright EFORT
70
A. Rponses correctes : 1, 2 & 3. Le rseau ePC consiste en les MME, Serving GW, PDN GW. Le HSS est commun ePC et IMS. Le PCRF est commun ePC et GPRS. Les eNodeB sont dans la LTE et non pas dans lePC. LIMS est indpendant de tout type daccs et ne fait donc pas partie de lIMS. B. Rponse correcte : 2 Comme GPRS, ePC est un rseau en mode connect. Avant denvoyer et de recevoir des paquets IP, lUE doit tablir un bearer. Un bearer dans lePC est un concept quivalent au contexte PDP dans le rseau GPRS. C. Rponse correcte : 1,2, 3 & 4. Durant son enregistrement au rseau EPS, lUE est authentifie. Son IMEI est vrifi afin de sassurer que le terminal nest pas vol. La vrification de lIMEI nest pas toujours effectue. Cela dpend de lautorit de rgulation dans le pays qui peut forcer les oprateurs de ce pays raliser cette opration. Le MME met jour le profil de labonn dans le HSS avec ladresse du MME afin que le HSS connaisse la localisation de lUE. En rponse, le HSS retourne le profil de lusager au MME. Le contrle de session a aussi lieu lors de la phase denregistrement puisque le MME dialogue avec le Serving GW afin dtablir pour lUE un default bearer qui reprsente une connectivit permanente qui pourra tre utilise par exemple pour laccs Internet. D. Les agents DIAMETER sont requis pour linteraction entre le MME visit et le HSS nominal. C. Rponse correcte : 2. Entre rseau visit et rseau nominal il faut des agents DIAMETER.
70
Scnarii de dploiement EPS
1. LTE et EPC pour des oprateurs avec des rseaux 3GPP (2G/3G au standard GSM) existants 2. LTE et EPC pour des oprateurs nouveaux entrants 3. LTE et EPC pour des oprateurs disposant de rseaux 3GPP2 (2G/3G au standard CDMA) 4. EPC-uniquement (sans dployer LTE) pour des oprateurs qui souhaitent s appuyer sur un rseau d accs LTE d un oprateur tabli.
Simon ZNATY
Copyright EFORT
71
1. La majorit des oprateurs GSM/GPRS a migr vers la 3G. La prochaine tape pour ces oprateurs sera le dploiement de la technologie LTE afin de pouvoir adresser le march de masse reprsent par le client disposant d un smartphone et souhaitant une souscription data mobile haut dbit. 2. Il est possible d imaginer un oprateur ne disposant pas de rseaux 2G et 3G et obtenant une licence 4G. Il pourra toujours, notamment au dbut tant que sa couverture 4G ne sera pas importante, disposer d un accord d itinrance 2G/3G avec un oprateur tabli du mme pays. 3. La LTE n est pas qu une technologie pour l volution des rseaux aux standards 3GPP. Elle effet cette technologie est aussi considre pour l volution des rseaux aux standards 3GPP2. 4. Du fait de l interface S1 flexible entre l accs et le cur de rseau 4G, il est possible qu un oprateur ne dploie que le cur de rseau 4G et s interface un rseau d accs LTE d un autre oprateur pour utiliser les ressources associes.
71
Fonctions EPS de haut niveau
Fonctions de contrle daccs rseau, i.e., AAA (Authentication, Authorization and Accounting) et Fonctions de scurit 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
Simon ZNATY
Copyright EFORT
72
Les grandes fonctions assures par lEPS sont les: Fonctions de contrle daccs rseau : Elle permettent dauthentifier lusager lorsque ce dernier sattache au rseau, met jour sa tracking area, et demande des resources pour ses communications. Elles permettent aussi de raliser la taxation de lusager en fonction de lusage des ressources et en fonction des flux de service mis et reus. Elle permettent enfin de scuriser les flux de signalisation et les flux mdia des usagers en les encryptant entre lUE et leNodeB. Fonctions de gestion de la mobilit : Elle permettent lUE de sattacher, de se dtacher et de mettre jour sa tracking area. Fonctions de gestion de session : Elles permettent dtablir des default bearers et des dedicated bearers afin que lUE dispose de connectivits IP pour ses communications. Fonctions de routage de paquet et de transfert : Elle permettent dacheminer les paquets de lUE au PDN GW ainsi que du PDN GW lUE. Fonctions de gestion de ressource radio : Elle permettent ltablissement et la libration de RAB (Radio Access Bearer) entre lUE et le Serving GW chaque fois que lUE souhaite devenir actif pour communiquer.
72
Architecture EPC sans roaming

IP/IMS EIR PDN Gateway S5 S6a MME S11 Serving Gateway S1-U E-UTRAN UE
Simon ZNATY
Rx PCRF S7 = Gx
SGi
S13 HSS
S1-C
eNodeB
Copyright EFORT
Interface DIAMETER
73
Les interfaces bases sur DIAMETER/SCTP/IP dans l architecture EPC sans roaming sont : Linterface S6a entre MME et HSS pour la gestion de la mobilit de lusager Linterface S13 entre MME et EIR pour vrifier le statut de lIMEI de lusager Linterface Gx entre le PDN GW et le PCRF afin que le PCRF fournisse au PDN-GW les rgles de taxation et puisse mettre en uvre sur le PDN GW des politiques de qualit de service. Linterface entre lIMS (P-CSCF) et le PDN-GW. Par ailleurs leNodeB dispose de linterface S1 avec le rseau cur. Linterface S1 consiste en : S1-C sur le plan de contrle (entre eNodeB et MME) bas sur le protocole S1AP/SCTP/IP. S1-U sur le plan usager (entre eNodeB et Serving Gateway) bas sur le protocole GTP-U/UDP/IP. Le MME dispose dune interface de contrle avec le Serving GW appele S11. Elle sappuie sur le protocole GTPv2-C. Enfin le Serving GW et le PDN GW partagent linterface S5. S5 consiste en : GTPv2-C/UDP/IP sur le plan de contrle, GTPv1-U/UDP/IP sur le plan usager.
73
Configuration pour l accs Internet et l accs aux services IMS
Default bearer pour l accs Internet
Internet Serving Gateway PDN Gateway
P-CSCF
Default bearer pour l accs aux services IMS

IP Network PDN Gateway
Simon ZNATY
Copyright EFORT
74
Le futur client EPS au rattachement au rseau EPS disposera dune connectivit permanente appele default bearer. Cette connectivit lui permettra daccder Internet. Il sagit de laccs au 1er play. Le second play permet au client daccder aux services de la tlphonie via lIMS. Une seconde connectivit permanente est donc ncessaire pour le transport des messages SIP pour invoquer les services de lIMS comme la tlphonie. La connectivit pour laccs aux services de lInternet et la connectivit pour laccs aux services de lIMS se diffrencient par leurs QoS. La QoS pour IMS a une QCI (QoS Class Identifier) gale 5 alors que celle pour lInternet peut disposer dune QCI gale 6, 7, 8 ou 9. Par ailleurs le contrle et la taxation des flux sur ces deux bearers est diffrente. Le default bearer SIP/IMS ne permet que le transport des messages SIP changs entre lUE et le P-CSCF. Tout autre trafic sera rejet. Ce trafic ne sera pas payant. Le default bearer Internet permet le transport de diffrents flux vers des applications de lInternet mais loprateur rejettera certains flux qui sont contraires au business model de loprateur. Par exemple, les flux Skype et les flux peer to pourront tre bloqus. La taxation de ces flux peut tre online ou offline en fonction de loffre data mobile souscrite par le client. Les deux default bearers se terminent sur un ou plusieurs PDN GW du rseau nominal si le client est dans son rseau nominal. Par contre les deux default bearer sont pris en charge par un mme Serving GW. LAPN identifie le PDN GW.
74
Implantation physique possible

IP/IMS HLR SGSN GGSN SGi Gx Rx PCRF
PDN PCEF Gateway HSS S6a MME Serving Gateway
S1-C
S1-U E-UTRAN NodeB/RNC
Simon ZNATY
Copyright EFORT
75
Larchitecture EPS physique peut tre mise en oeuvre par mise jour logicielle et matrielle de larchitecture 3G paquet. Le HLR peut voluer pour devenir un HLR/HSS. Le SGSN peut intgrer la fonction MME. Le GGSN peut tre mise jour pour supporter les fonctions Serving GW et PDN GW. Le mme PCRF 3G peut mettre en uvre les fonction PCC pour lEPS. Enfin certains fournisseurs proposent des NodeB intgrant la fonction RNC. Ces mmes Node B peut voluer pour intgrer la fonction eNodeB.
75
Architecture EPC avec Roaming Trafic rout au rseau nominal

Rseau Nominal A Rx IP/IMS SGi PDN PCEF Gateway HSS
Agents DIAMETER
Rseau Visit B
PCRF Gx S8 Serving Gateway MME S11
S6a S1-C
Interface DIAMETER
S1-U E-UTRAN
76
En situation de roaming, deux cas se prsentent pour le traitement du trafic de lusager : Local breakout : Le PDN GW est dans le rseau visit et le trafic de lusager est pris en charge uniquement par le rseau visit. Home routed : Le PDN GW est dans le rseau nominal et le trafic de lusager doit tre ramen du Serving GW du rseau visit au PDN GW du rseau nominal via lIPX (IP Exchange network). En roaming, le Serving GW et le MME sont toujours dans le rseau visit. La figure ci-dessus prsente le cas home routed. Linterface S6a est donc prsente entre le MME du rseau visit et le HSS du rseau nominal Linterface Gw est tablie entre le PDN Gw du rseau nominal et le PCRF du rseau nominal Linterface Rx met en relation le P-CSCF (IMS) du rseau nominal et le PCRF du rseau nominal.
76
Architecture EPC avec Roaming Local Breakout

Rseau Nominal A Rseau Visit B Rx S9 PCRF
Agents DIAMETER
IP/IMS SGi
PCRF Gx
PCEF S5
PDN Gateway
HSS S6a
Agents DIAMETER
MME
S11
Serving Gateway S1-U E-UTRAN
S1-C
Interface DIAMETER
77
Larchitecture ci-dessus dcrit le cas o le trafic est rout localement aussi appel cas local breakout. Les Serving et PDN Gateways sont dans le rseau visit. Le PCRF du rseau visit obtient les rgles de taxation et les politiques de qualit de service du PCRF du rseau nominal via linterface S9.
77
Configuration typique pour l accs Internet et l accs l IMS depuis un rseau visit
Rseau visit
Default bearer pour l accs Internet
Rseau IP Rseau IP Rseau IP
IPX
Rseau nominal
SGW P-CSCF
S-CSCF
PGW
Default bearer pour l accs IMS

Rseau IP PGW Rseau IP
Simon ZNATY
Copyright EFORT
78
Si le client EPS s attache depuis un rseau visit, les deux default bearers Internet et IMS impliqueront les lments suivants. Un Serving GW du rseau visit pour les deux default bearers, un PDN GW du rseau nominal pour le default bearer Internet, un PDN GW du rseau visit pour le default bearer IMS. En effet, l UE doit changer les messages SIP avec le P-CSCF du rseau visit. Pour des raisons d optimisation, le PDN GW est celui du rseau visit.
78
Configuration typique pour l accs Internet et l accs l IMS pour un client LTE rattach la 2G (Donc sans Direct Tunnel)
Contexte PDP pour l accs Internet
BTS BSC S4-SGSN Internet Serving Gateway PDN Gateway P-CSCF
Contexte PDP pour l accs aux Services IMS

IP Network PDN Gateway
Simon ZNATY
Copyright EFORT
79
Si le client EPS se rattache depuis son rseau nominal depuis un accs 2G ou 3G faute de couverture LTE, il est alors pris en charge par un S4-SGSN. Il sagit dun SGSN qui a la capacit sinterface au rseau ePC. En effet, il faut que les bearers du client se terminent sur un PDN GW et non pas un GGSN. Cest le PDN GW qui alloue une adresse IP au client et si le client plus tard dtecte un eNodeB LTE, il pourra alors basculer sur la technologie LTE sans perdre ses sessions de donnes puisque le mme PDN GW conserve les bearers du client ainsi que son adresse IP. La figure ci-dessus montre les bearers en considrant que le direct tunnel nest pas implant du fait qu il s agit d un accs 2G. Le S4-SGSN est prsent sur le plan de contrle et le plan usager. Les beares sont tablis via BTS/BSC (en considrant laccs 2G), puis S4SGSN, puis lePC ( 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 donnes quelque soit le scnario de mobilit.
79
Configuration pour l accs Internet et l accs l IMS pour un client LTE rattach la 3G (Direct Tunnel)
Node B RNC Internet Serving Gateway PDN Gateway P-CSCF

Rseau IP PDN Gateway
Simon ZNATY
Copyright EFORT
80
La figure ci-dessus est identique celle prcdente mais en considrant le mode direct tunnel. Dans ce mode, le S4-SGSN nest plus prsent sur le plan usager. Les bearers sont tablis via NodeB/RNC (en considrant laccs 3G), puis lePC ( travers le SGW et le PDN GW). Si l accs avait t 2G (GPRS/EDGE), il n aurait pas t possible de considrer le mode direct tunnel. Le S4-SGSN est dans ce cas prcis prsent sur les plans contrle et usager.
80
Configuration pour l accs Internet et l accs l IMS pour un client LTE rattach la 3G en roaming
Rseau visit
RNC Serving Gateway Rseau IP Rseau IP Rseau IP
IPX
Rseau nominal
P-CSCF
S-CSCF
PDN Gateway

Rseau IP PDN Gateway Rseau IP
Situation de Roaming avec Direct Tunnel

81
81
Architecture EPC pour un accs WLAN non fiable (untrusted)

Rseau Non-3GGP
Rseau nominal 3GPP
UE SWu WiFi AP SWa SWn ePDG S2b SWm 3GPP AAA Server SWx HSS
PCRF Gx PDN Gateway
Interface Diameter
82
L architecture ePC permet le rattachement depuis un accs WLAN non fiable (untrusted) comme le montre la figure ci-dessus. Son architecture est similaire celle de l'UMA/GAN, savoir le dploiement d'une passerelle d'interconnexion, l ePDG (Evolved Packet Data Gateway). Le mobile sous couverture WiFi tablit un lien IP scuris avec l ePDG (via l'accs xDSL, FTTx ou cble) positionn directement dans le rseau coeur. Contrairement l'UMA/GAN qui supporte indiffremment les modes "circuit" et "paquet", l'I-WLAN ne permet d'accder qu'au mode "paquet". Les communications tlphoniques ne deviennent alors possibles que grce au dploiement d'une infrastructure de voix sur IP situe dans le cur du rseau (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 rseau GSM/UMTS et le service de voix sur IP sur WLAN sera contrl par un serveur d'application de l'IMS appel VCC (Voice Call Continuity)
82
Interfonctionnement
Rseaux IP externes
PDN GW
Domaine de Commutation de Paquet (Architecture Evolved Packet Core) LTE

Larde bande Fixe (e.g., xDSL)
HRPD 2G/3G
LTE : Long Term Evolution HRPD : High Rate Packet Data ePC : Evolved Packet Core
Simon ZNATY
WLAN
Copyright EFORT
83
Larchitecture ePC a t conue afin de permettre linterfonctionnement avec tout type daccs. Cette approche permet de rendre la connexion avec un rseau IP externe indpendante de la technologie daccs. Le rseaux IP externe est appel un niveau gnrique PDN (Packet Data Network). La manire dobtenir son adresse IP en tant qu UE, la gestion de la souscription de lusager, la procdure dauthentification et le contrle ainsi que la taxation des flux IP de lusager sont donc indpendants de la technologie daccs qu elle soit fixe, wireless ou mobile. En effet lePC a t pens afin de permet laccs depuis laccs LTE (via des eNodeB) , laccs depuis la 2G/3G via un SGSN appel S4-SGSN ou laccs depuis un accs large bande fixe (xDSL, Cble, FTTx, etc.) via un Access Point WiFi. LAccess Point WiFi sera reli via laccs large bande fixe un nud ePDGde l ePC. Dans tous les cas, les bearers du client se terminent sur un ou des PDN GWs de lePC. Cest ce mme PDN GW qui assure lassignation de ladresse IP l UE, le contrle et la taxation des flux, la gestion de la mobilit inter technologie daccs, 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 donnes mme en situation de mobilit). Dans cette architecture, il est aussi possible de considrer des femtocell ou des efemtocells. Ces femtocells remplacent les Access Points WiFi chez le client.
83
PCC : Policy and Charging Control

Interface DIAMETER
PCRF : Policy and Charging Rules Function SPR : Subscription Profile Repository PCEF : Policy and Charging Enforcement Function P-CSCF : Proxy Call Stateful Control Function OCF : Online Charging Function OFFCS : Offfline Charging System
e.g., P-CSCF
PCRF S9 Sp SPR
Rc OCF Re Gy OFCS Gz
AF Rx PCRF Gx Sy
ABMF RF
UE
EPS bearer
PCEF
ABMF : Account Balance Management Function RF : Rating Function

84
Simon ZNATY
GGSN/PDN GW Copyright EFORT
Lentit PCRF ralise deux fonctions : Elle fournit au PCEF les rgles de taxation lorsquun default bearer ou un dedicated bearer est activ ou modifi pour lusager. Ces rgles de taxation permettent au PCEF de diffrencier les flux de donnes de service et de les taxer de faon approprie. Par exemple, si lusager 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 dure. Elle permet de demander au GGSN/PDN GW dtablir, de modifier et de librer des contextes PDP secondaires sur la base de QoS souhaite par lusager (interface Gx). Par exemple, Si lusager demande ltablissement dune session IMS, un message SIP sera envoy au P-CSCF qui dialoguera avec le PCRF (interface Rx) pour lui indiquer la QoS requise par lusager pour cette session. Le PCRF dialogue alors avec le GGSN (interface Gx) pour crer le contexte PDP secondaire correspondant. Afin de gnrer les rgles de QoS et les rgles de taxation, le PCRF doit accder une base de donnes pouvant fournir des donnes de souscription de l usager. Cette dernire s appelle SPR (Subscription Profile Repository) et dispose d une interface Sp avec le PCRF. La taxation online est ralise grce l entit PCEF qui demande des crdits 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 gnration de tickets la fin du contexte PDP. Ces tickets sont soumis du PCEF l entit OFCS.
84
Policy Control dans l EPS concerne deux fonctions gating control et QoS control:
1. Gating control permet de bloquer ou d autoriser les paquets IP apparenant un flux de service. 2. QoS control permet au PCRF de fournir au PCEF la QoS authorise pour les flux de service (i.e., dbit maximum par flux de service)
Charging Control inclut les mcanismes pour les taxations online et offfline. Le PCRF prends la dcision sur la mthode de taxation (online ou offline) pour chaque flux de service. Le PCEF met en uvre la taxation en collectant les informations de taxation et en interagissant avec les systmes de taxation.
Simon ZNATY
Copyright EFORT
85
Gating Control : Le PCRF prend des dcisions de filtrage qui sont ralises par le PCEF. Ces dcisions permettent de laisser passer certains flux et de bloque les autres flux. QoS Control : La qualit de service autorise peut inclure par exemple le dbit maximum par flux. Un flux est transport par un bearer. Un bearer supporte une classe de service (e.g., Conversationnel, streaming, interactive, background). Le PCEF doit sassurer quun flux de service soit accommod sur le bearer disposant de la classe de service approprie. Tous les flux empruntant ce bearer disposent de la mme classe de service. Le bearer dispose dun dbit maximum, et le dbit de chaque flux peut aussi limit un maximum. La somme des dbits maximum des diffrents flux empruntant le mme bearer doit bien sur tre infrieure au dbit maximum du bearer. Le PCEF doit contrler le dbit de chaque flux individuellement afin de sassurer quil nexcde pas sa QoS autorise.
85
DRA : Diameter Routing Agent
PCRF_1 Gx
PCRF_2 ... PCRF_N Gx Gx
DRA
Gx PDN Gateway
Interface DIAMETER
DRA : Diameter Routing Agent
86
In order to ensure that all Diameter sessions for Gx, S9 and Rx for a certain session reach the same PCRF when multiple and separately addressable PCRFs have been deployed in a Diameter realm, an optional logical "Diameter Routing Agent (DRA)" function is enabled. This resolution mechanism is not required in networks that utilise a single PCRF per Diameter realm. The DRA has the following roles: When deployed, DRA needs to be contacted at first interaction point for a given PDN-GW and a given session. When the DRA (Diameter Routing Agent) first receives a request for a certain bearer establishment from a PDN GW, the DRA selects a suitable PCRF for the session and stores the PCRF address. Subsequently, the DRA can retrieve the selected PCRF address according to the information carried by the incoming requests from other entities (e.g. the P-CSCF). When the IP- CAN Session terminates, the DRA shall remove the information about the session. The DRA functionality should be transparent to the Diameter applications used on the Gx, S9 or Rx reference points. In roaming scenario, home routed or local breakout, if the DRA is deployed, the vPCRF is selected by the DRA located in the visited PLMN, and the hPCRF is selected by the DRA located in the home PLMN. The parameters available for the DRA to be able to determine the already allocated PCRF depend on the reference point over which the DRA is contacted.
86
Home Subscriber Server (HSS)
Avec la technologie LTE, le HLR est rutilis et renomm Home Subscriber Server (HSS). Le HSS est un HLR volu et contient linformation de souscription pour GSM, GPRS, 3G, LTE et IMS. A la diffrence de la 2G et de la 3G o linterface vers le HLR est supporte par le protocole MAP (protocole du monde SS7), linterface S6 sappuie sur le protocole DIAMETER (protocole du monde IP). Le HSS est une base de donnes qui est utilise simultanment par les rseaux 2G, 3G, LTE/ePC et IMS appartenant au mme oprateur. Il supporte donc les protocoles MAP (2G, 3G) et DIAMETER (LTE/ePC, IMS).
Simon ZNATY
Copyright EFORT
87
87
Interfaces HSS
IMS
I-CSCF, S-CSCF AS
I-WLAN 3GPP AAA Server

SWx
LTE / ePC MME

S6a
Sh Cx
MSC/VLR GMSC
HSS
D C D C
S6d
Gr
S4-SGSN
MSC Server GMSC Server 2G/3G SGSN Interface DIAMETER Interface MAP
Domaine CS 2G/3G
Domaine PS 2G/3G88
Le HSS consiste en les fonctionnalits suivantes : Fonctionnalit HSS IP multimedia afin de fournir le support au fonctions de contrle de session IMS, telles que les I-CSCF et S-CSCF (Interface Cx base sur DIAMETER) et contrle de service (Interface Sh). Fonctionnallit HSS EPS ncessaire afin que les usagers EPS accdent au domaine paquet ePC (Interface S6a/S6d). Fonctionnalit HSS pour l accs non-3GPP l EPS ncessaire 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, sil est ncessaire que les usagers accdent au domaine circuit ou pour supporter le roaming dans des rseaux visits lgataires supportant le domaines circuit 2G/3G (Interfaces C, D). Un rseau nominal peut tre support par un ou plusieurs HSSs. Le nombre est fonction du nombre dusagers mobiles, de la capacit du HSS et de lorganisation du HSS. Le HSS prend en charge le stockage des informations suivantes de lusager : Identits prive et publiques de lusager Information de scurit de lusager pour les aspects autorisation et authentification. Information de localisation de lusager. Le HSS supporte lenregistrement de lusager et mmorise ladresse du nud rseau auquel il est rattach. Le profil de lusager contenant entre autres les maques de service de lusager autorisant laccs ces services le HSS gnre aussi des informations de scurit usager pour lauthentification mutuelle, le chiffrement et lintgrit des donnes.
88
Provisioning HSS pour un usager LTE

Profil usager dans HLR/HSS/UPSF
HLR HSS UPSF
2G/3G Circuit Switched Profile
2G/3G Packet Switched Profile
4G Packet Switched Profile
IMS Profile
Service Data
SPR
MAP
MAP
DIAMETER S6a/S6d
DIAMETER Cx
DIAMETER Sh
DIAMETER Sp
MSC Server ou MSC/VLR 2G/3G SGSN

HLR : Home Location Register HSS : Home Subscriber Server UPSF : User Profile Server Function
Simon ZNATY
MME S4-SGSN
S-CSCF
AS
PCRF
Copyright EFORT
89
When the LTE user is in his home network, LTE coverage may be assumed to be spotty at the beginning of the deployment. Therefore he may register from LTE areas or from 2G/3G areas. His LTE (packet switched) profile will be supplied to an MME if he attaches from LTE area and will be downloaded to the S4-SGSN if he is served by a 2G/3G area. The S4-SGSN will terminate all the PDP contexts of this user on a PDN GW instead of terminating them on a GGSN. His IMS profile will be supplied to an S-CSCF if the user is served by an LTE area and will be provided to an MSC Server if he attaches from a 2G/3G area. When the LTE user is in a visited network which just supports 2G and/or 3G, his 2G/3G circuit switched profile is supplied to the visited MSC Server and his 2G/3G packet switched profile will be downloaded to a visited 2G/3G SGSN. This SGSN has no S4 capability. This is the reason, it is required to provision both HLR and HSS profiles of an LTE user.
89
CS Fallback dans larchitecture EPS

S4-SGSN UTRAN IuPS IuCS Gb
UE
Gs MSC Server
GERAN
A SGs
S3 E-UTRAN S1-C MME
Simon ZNATY
Copyright EFORT
90
La fonctionnalit CSFB ou CS Fall back (repli en circuit commut) dans le rseau EPS est ralise en utilisant linterface SGs entre le MSC Server et le MME. Linterface SGs est base sur les fonctionnalites de linterface Gs dfinie entre le MSC/VLR et le SGSN, mais qui na jamais t implante.
90
3.3. Gestion de la Mobilit EPS
3GPP TR 24.801
Simon ZNATY
Copyright EFORT
91
91
Connectivit Accs-Rseau Cur classique et S1-flex

3G SGSN IuPS
Connectivit 1--n
RNC Service Provider 1
RNC
RNC
RNC
RNC
Service Provider 2 MME4 MME3 Serving GWs Serving GWs S1-Flexibility

Les eNodeBs appartiennent Service Provider 1 considr comme fournisseur d accs LTE.
92
MME1 MME2 Serving GWs Serving GWs S1
Pool Area 1
eNodeB eNodeB eNodeB eNodeB eNodeB
Dans les rseaux mobiles 2G et 3G, la connectivit entre le rseau cur et le rseau daccs tait dfinie comme hirarchique : un nud du rseau cur (soit le MSC dans le domaine circuit, soit le SGSN dans le domaine paquet) sert un ensemble de contrleurs dantennes (BSC 2G ou RNC 3G), et un contrleur donn ne peut sinterfacer qu un nud MSC et un nud SGSN. Depuis la Release 5 des spcifications 3GPP, une nouvelle fonctionnalit a t introduite permettant plus de flexibilit dans linterconnexion entre les nuds daccs et les nuds du rseau cur, cassant la hirarchie traditionnelle dans le rseau mobile. Cette fonctionnalit appele Iu-flex dans les rseaux 3G a t introduite ds le dbut dans les recommandations LTE et est appele 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 mme oprateurs. S il appartiennent au mme oprateur, alors le but recherch est la redondance. S ils appartiennent des oprateurs diffrents, alors l objectif est le RAN sharing.
92
Etapes d auto-configuration de leNodeB

SGW MME
Etablissement S1-C
O&M System
S associe SGW
Dtecte systme O&M
MME SCTP
MME
Etablissement des liens X2

SCTP
SCTP Hub?
SCTP SCTP
eNodeB
eNodeB
eNodeB
Simon ZNATY
eNodeB
Copyright EFORT
93
In 3GPP Release 8 development, it has been agreed to define the support for self-configuration of the S1-C and X2 interfaces. The basic process is as presented in the above figure, where the eNodeB once turned on (and given that the IP connection exists) will connect to the O&M (based on the known IP address) to obtain then further parameters in terms of which other network elements to connect (and also for eNodeB software download) as well as initial parameters for the operation, such as in which part of the frequency band to operate and what kind of parameters to include for the broadcast channels. This is expected to include setting the S1-C connection by first setting up the SCTP association with at least one MME, and once that is connected to continue with application level information exchange to make S1-C interface operational. Once the link to MME exists, there needs to be then association with S-GW created for UP data transfer. To enable functionalities such as mobility and inter-cell interference control, the X2 interface configuration follows similar principles to the S1-C interface. The difference here is that initially the eNodeB will set up the X2 connection for those eNodeBs indicated from the O&M. The parameters that are exchanged over the X2 interface include: global eNodeB ID; information of the cell specific parameters such as Physical Cell ID (PCI), uplink/downlink frequency used, bandwidth in use; MMEs connected (MME Pool).
93
Attachement initial E-UTRAN (1)

UE
eNodeB
New MME
SGW
EIR
PGW PCRF
HSS
Attach Request (PDN Connectivity Request) Authentication Information Request Authentication Request Authentication Response Identity request Identity response Check IMEI Request Check IMEI Answer Vrification d IMEI Authentication Information Answer Authentification
EMM Diameter GTPv2-C S1-AP RRC

Simon ZNATY
Update Location Request Update Location Answer (User Profile) Mise jour de localisation
Copyright EFORT
94
L'UE souhaite s'enregistrer au rseau EPS. Cette procdure correspond un attachement au rseau EPS qui conduira la cration d'un default bearer permanent correspondant une connectivit permanente IP. 1. L'UE initie la procdure d'attachement en mettant une requte Attach l'eNodeB fournissant son GUTI. D'aprs le GUTI, l'eNodeB est capable d'identifier l'oprateur avec lequel l'UE souhaite s'attacher. L'eNodeB slectionne ensuite le MME de cet oprateur 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 requte Send Authentication Info. 3. Le MME soumet une valeur alatoire l'UE et escompte une rponse de l'UE contenant un rsultat d'authentification gal celui fourni par le HSS. L'UE retourne la rponse 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 dlivre un message Update Location (adresse MME sous forme de hostname, IMSI) au HSS. 6b. Le HSS acquitte la mise jour de localisation par une rponse Update Location Ack au MME qui contient les donnes de souscription de l UE incluant la liste de tous les APNs que l'UE est en droit d'accder, une indication sur l'APN par dfaut, et les paramtres de QoS associs chaque APN. Si le HSS rejette a procdure de mise jour de localisation, alors le MME rejette la demande d'attachement de l'UE.
94
Attachement initial E-UTRAN (2)

UE eNodeB New MME Old MME/ SGSN SGW EIR PGW PCRF HSS 7. Create Session Request 8. Create Session Request
9a. Gx. CCR 9b. Gx. CCA
10. Create Session Response 11. Create Session Response
12. S1-AP Initial Context Setup Request (EMM Attach Accept (ESM Activate Default EPS bearer Context Request)) 13. RRC Connection Reconfiguration Request (EMM Attach Accept (Activate Default EPS bearer Context Req)) 14. RRC Connection Reconfiguration Complete (EMM Attach complete (ESM Activate Default EPS Bearer Context Accept )) 15. S1-AP Initial Context Setup Response (EMM Attach Complete (ESM Activate Default EPS Bearer Context Accept ))
First uplink data 16. Modify Bearer Request 17. Modify Bearer Response First downlink data 18. Notify Request 19. Notify Answer
EMM Diameter GTPv2-C S1-AP RRC
95
7. Le MME slectionne un Serving GW et assigne une valeur au paramtre EPS Bearer Identity (BI) pour le bearer par dfaut associ cet UE. Puis, il met une requte Create Session Request (pour la cration du default bearer) au serving GW slectionn. 8. Le serving GW cre une nouvelle entre dans sa table d'EPS bearer et met son tour une requte Create Session Request au PDN Gateway en utilisant le protocole GTP-C. Ce bearer permet l'UE d'accder Internet par exemple. 9. Le PDN GW interagit avec l'entit PCRF afin d'obtenir les rgles de taxation permettant de diffrencier les flux de service qui transiteront par le default bearer et ainsi diffrencier la taxation de ces flux. 10. Le PDN GW retourne une rponse Create Session Response au Serving GW contenant l'adresse IP alloue par le PDN GW l'UE. 11. Le Serving GW retourne une rponse Create Session Response au MME. 12. Le MME met un message de contrle sur l'interface S1-C l'eNodeB, appel Initial Context Setup Request, afin de demander l'eNodeB de crer un bearer d'accs 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 mdia au serving GW. 13. L'eNodeB met un message RRC Connection Reconfiguration request incluant l'identit du bearer d'accs et le message Attach Accept contenant le GUTI assign l'UE. 14. l'UE retourne une rponse 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 ds prsent 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 rception du message Initial Context Response et de l'Attach Complete, l'entit MME met une requte Modify Bearer Request (Identit du bearer EPS (BI), adresse eNodeB) au Serving GW. 17. Le Serving GW l'acquitte en retournant une rponse Modify Bearer Response (Identit du bearer EPS) au MME. Le Serving GW est ds prsent prt relayer les paquets IP qu'il a pu mettre temporairement en mmoire 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.
95
3.4. Gestion de session EPS

3GPP TS 23.401 3GPP TR 24.801
Simon ZNATY
Copyright EFORT
96
Afin daccder aux services EPS, lUE doit disposer de bearer. Un default bearer qui est permanent par nature est tabli par le rseau EPS ds lattachement de lUE ce rseau. Ce bearer EPS est maintenu pour toute la dure dattachement de lUE afin de fournir lUE une connectivit IP permanente un rseau IPv4 ou IPv6. Il correspond au concept de contexte PDP tabli dans un rseau GPRS. A tout moment lUE peut tablir un ou plusieurs default bearers additionnels. Seul lUE peut initier la demande dtablissement dun default bearer additionnel. LUE obtient une adresse IP par default bearer tabli. Les default bearer ne fournissent pas de dbit garanti. Afin que lusager puisse accder des services temps rel IP tels que la tlphonie sur IP, il est ncessaire quun ddicated bearer soit tabli ; un dedicated bearer a une dure limite et fournit un dbit garanti, et est toujours associ un default bearer. Le default bearer et tous les dedicated bearer associs partagent la mme adresse IP. Le rseau ou lUE peuvent initier ltablissement dun dedicated bearer.
96
Default et dedicated bearers

UE Serving GW1
Same PDP (IP) address and APN
PDN GW1 ISP X
APN X
Dedicated bearer (APN X, IP address X, QoS2) Default Bearer (APN X, IP address X, QoS1)
PDN GW2
ISP Y
Dedicated bearer (APN Y, IP address Y, QoS2) Default bearer (APN Y, IP address Y, QoS1)
APN Y
ISP Z
Simon ZNATY
Copyright EFORT
97
Le MME cre pour le compte de l usager un default bearer au moment du rattachement au rseau. Supposons qu il s agisse du default bearer utilis pour l accs au PDN (Packet Data Network) Internet. Ce Default bearer est maintenu tant que l usager est rattach au rseau mobile. L APN correspondante est prsente dans le profil de l usager qui est fourni par le HSS au MME Si l usager ncessite d accder un autre PDN (e.g., rseau 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 accder 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 rserver un dedicated bearer. Ce dedicated bearer est caractris par une QoS compatible par rapport au trafic transporter. Le dedicated bearer a une dure 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 mme adresse IP que le default bearer, mais une QoS qui peut tre la mme ou diffrente. Plusieurs dedicated bearers peuvent tre associs au mme default bearer.
97
Relation entre les contexte PDN et les contextes de bearer par dfaut/ddis
PDN Context 1 PDN address(es) APN Default bearer context 1 ESM state EPS bearer identity TFT QoS Dedicated bearer context 1 ESM state EPS bearer identity TFT QoS BI Dedicated bearer context 2
Dedicated bearer context n Dedicated bearer context 1 Dedicated bearer context 2 Dedicated bearer context n
PDN Context 2 Default bearer context 2
PDN Context n Default bearer context n
Dedicated bearer context 1 Dedicated bearer context 2

Copyright EFORT
Simon ZNATY
Dedicated bearer context n
98
Each established EPS bearer will be described by a set of parameters in both the UE and the MME. This grouping of parameters is referred to as an EPS bearer context. A PDN context can be defined as a grouping of one default EPS bearer context and zero, one or more dedicated EPS bearer contexts. A UE may have simultaneous connectivity with more than one PDN and thus more than one PDN context. The structure and content as well as the relationship between the PDN context and the default and dedicated EPS bearer contexts that are stored in the UE and MME are shown in the following tables:
PDN context Field PDN address(es) APN Default EPS bearer context Field ESM state EPS bearer identity TFT QoS Dedicated EPS bearer context Field ESM state EPS bearer identity TFT QoS LBI Description Session management state EPS bearer identity Traffic flow template Quality of service Linked bearer identity Description One IPv4 address and/or one IPv6 prefix assigned to the UE Access point name Description Session management state EPS bearer identity Traffic flow template Quality of service
98
UE eNodeB
Activation dun default bearer par lUE PGW SGW

New MME PCRF 3. Create Session Request
HSS
1. ESM PDN Connectivity Request
2. Create Session Request
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 12. Modify Bearer Response First Downlink Data
ESM GTPv2-C S1-AP RRC

99
La procdure UE requested PDN connectivity permet lUE de demander ltablissement dun bearer EPS par dfaut (default bearer) vers un rseau de donnes externe IPv4 ou IPv6. Ce default bearer vient en supplment de celui tabli lors de lattachement de lUE au rseau EPS. LUE dispose alors de plusieurs default bearers et obtient pour chacun de ces bearers, une adresse IP. LUE met le message PDN CONNECTIVITY REQUEST au MME pour la cration du default bearer. Ce message doit inclure lAccess Point Name (APN) et la procdure transaction identity (PTI). A la rception de ce message lentit MME vrifie si la connectivit avec lAPN demande est possible daprs le profil de lusager. Si tel est le cas, lentit MME initie ltablissement de ce defaut bearer et retourne une rponse PDN CONNECTIVITY ACCEPT. Si la demande nest pas accepte, lentit MME retourne PDN CONNECTIVITY REJECT. A titre dexemple, le premier default bearer tabli au moment de lattachement de lUE permet laccs Internet alors que le second permet laccs lIntranet dentreprise ou au rseau et aux services IMS. La figure ci-dessus dcrit la procdure de bout en bout dtablissement dun default bearer additionnel. 1. L'UE initie la procdure d'tablissement d'un default bearer additionnel l'aide de la requte "PDN Connectivity Request" envoye au MME. 2. Le MME vrifie que l'APN fournie par l'UE dans sa requte est authorise selon le profil d'usager. Si tel est le cas, le MME slectionne un Serving GW et assigne une valeur au paramtre EPS Bearer Identity (BI) pour le default bearer additionnel associ cet UE. Puis, il met une requte Create Session Request (pour la cration de ce nouveau default bearer) au serving GW slectionn. 3. Le serving GW cre une nouvelle entre dans sa table d'EPS bearer et met son tour une requte Create Session Request au PDN Gateway. 4. Le PDN GW interagit avec l'entit PCRF afin d'obtenir les rgles de taxation permettant de diffrencier les flux de service qui transiteront par ce default bearer et ainsi diffrencier la taxation de ces flux. 5. Le PDN GW retourne une rponse Create Session Response au Serving GW contenant l'adresse IP alloue par le PDN GW l'UE. 6. Le Serving GW retourne une rponse Create Session Response au MME. 7. Le MME met un message de contrle sur l'interface S1-C l'eNodeB, appel Bearer Setup Request, afin de demander l'eNodeB de crer un bearer d'accs 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 mdia au Serving GW. 8. L'eNodeB met un message RRC Connection Reconfiguration request incluant l'identit du bearer d'accs et un message ESM PDN Connectivity Accept. 9. l'UE retourne une rponse 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 ds prsent 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 rception du message Bearer Context Response, l'entit MME met une requte Modify Bearer Request (Identit du bearer EPS (BI), adresse eNodeB) au Serving GW. 12. Le Serving GW l'acquitte en retournant une rponse Modify Bearer Response (Identit du bearer EPS) au MME. Le Serving GW est ds prsent prt relayer les paquets IP, qu'il a pu mettre temporairement en mmoire tampon, dans le sens descendant l'UE travers l'eNodeB.
99
Libration dun default bearer par lUE PGW SGW

UE eNodeB
New MME
PCRF
HSS
1. ESM PDN Disconnect Request
2. Delete Session Request
3. Delete Session Request

5. Delete Session Response 6. Delete Session Response 7. S1-AP Deactivate Bearer Request 8. RRC Connection Reconfiguration Request 9. RRC Connection Reconfiguration Complete 10. S1-AP Deactivate Bearer Response ESM GTPv2-C S1-AP RRC
Simon ZNATY
Copyright EFORT
100
1. The UE initiates the UE requested PDN disconnection procedure by the transmission of a PDN
Disconnection Request (LBI) message. The LBI indicates the default bearer associated with the PDN connection being disconnected. 2. The EPS Bearers in the Serving GW for the particular PDN connection are deactivated by the MME by sending Delete Session Request (TEID, LBI) to the Serving GW. This message includes an indication that all bearers belonging to that PDN connection shall be released. 3. The Serving GW sends Delete Session Request (TEID, LBI) to the PDN GW. 5. The PDN GW interacts with the PCRF to inform the PCRF that the session is released. 4. The PDN GW acknowledges with Delete Session Response towards the Serving GW. 6. The Serving GW acknowledges with Delete Bearer Response towards the MME. 7. The MME initiates the deactivation of all Bearers associated with the PDN connection to the eNodeB by sending the Deactivate Bearer Request message to the eNodeB. 8. The eNodeB releases the corresponding radio bearers by sending the RRC Connection Reconfiguration message to the UE. 9. The UE releases all resources corresponding to the PDN connection and acknowledges this by sending the RRC Connection Reconfiguration Complete message to the eNodeB. 10. The eNodeB sends an acknowledgement of the deactivation to the MME.
100
Activation dun bearer ddi par le PDN GW suite une demande de lIMS
Mthode Push
Rx et Gx sont des interfaces bases sur DIAMETER
P-CSCF Rx
IMS
2
Signalisation dappel (SIP) Contrle de politique) Signalisation bearer
PCRF Gx 3
Router
UE
eNodeB
MME
EPS
PCEF
Rseau IP
Backbone IP
4
PDN GW
Copyright EFORT
Serving GW
Simon ZNATY
1. Signalisation SIP 2. Signalisation Rx 3. Signalisation Gx 101 4. Signalisation bearer (ESM+GTPv2-C)
The P-CSCF sends an RX request to the PCRF for dedicated bearer establishment. The PCRF translates the Rx request into a Gx request. The Gx request is sent to the PDN GW which performs the dedicated bearer establishment procedure.
101
UE
eNodeB
Activation dun bearer ddi par le PDN GW SGW P-CSCF PGW

S1
MME
S11
S5
Gx
PCRF
Rx
SIP INVITE (sdp1)

Rx AAR (sdp1, sdp2) 183 Session Progress (sdp2) 1. Gx. RAR 2. GTPv2C Create Bearer Request 3. GTPv2C Create Bearer Request 4. S1-AP Bearer Setup Request (ESM Activate dedicated eps bearer context request) 5. RRC Connection Reconfiguration Request (ESM Activate dedicated eps bearer context request) 6. RRC Connection Reconfiguration Response (ESM Activate dedicated eps bearer context Accept) GTPv2-C S1-AP RRC Rx, Gx SIP
7. S1-AP Bearer Setup Response (ESM Activate dedicated eps bearer context Accept) 8. GTPv2C Create Bearer Response 9. GTPv2C Create Bearer Response 10. Gx. RAA Rx. AAA
102
Un usager initie une session tlphonique IMS en mettant une requte 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 ddi la signalisation SIP IMS. La demande INVITE (sdp1) est route par l IMS l appel. Lorsque le terminal de l appel reoit cette requte INVITE (sdp1), le terminal ne se met pas sonner et retourne une rponse 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 rseaux d accs de l appelant et de l appel auront t rserves par le PCRF. Ces ressources sont reprsentes 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 sadresse au PCRF (Policy and Charging Rules Function) afin de lui demander de rserver les ressources laccs, relatives la description SDP. Pour ce faire, le P-CSCF met une requte Rx Authenticate and Authorize Request (AAR) contenant les informations des descriptions SDP de l appelant (SDP1) et de l appel (SDP2). 2. Lentit PCRF traduit la QoS des descriptions SDPs en des paramtres QoS spcifiques laccs EPS; elle met la requte Gx Re-Authorize Request (RAR) au PDN-GW. 3. Le PDN GW initie la cration du dedicated bearer laide de la requte Create Dedicated Bearer Request (EPS Bearer QoS) indiquant la QoS requise;. Cette requte est reue par lentit Serving GW. 4. Le Serving GW relaie la requte Create Dedicated Bearer Request (EPS Bearer QoS) au MME. 5. Lentit MME demande ltablissement dun bearer daccs leNodeB laide de la requte S1-AP Bearer Setup Request (EPS Bearer QoS). 6. LeNodeB traduit la Qos demande dans le paramtre EPS Bearer QoS en une QoS correspondante sur linterface radio Radio Bearer QoS. Il notifie alors lUE la mise en place dun bearer radio. 7. LUE acquitte cet activation de bearer radio leNodeB. 8. LeNodeB acquitte lactivation du bearer au MME laide de la rponse Bearer Setup Response. LeNodeB indique si la QoS requise a pu tre alloue ou non. 9. Le MME acquiite lactivation du bearer au Serving GW par lenvoi dune rponse Create Dedicated Bearer Response. 10. Le Serving GW acquitte lactivation du bearer au PDN GW par lenvoi de la rponse Create Dedicated Bearer Response. 11. Le PDN GW retourne la rponse Re-Authorize Answer (RAA) au PCRF pour lui indique que la politique de QoS a pu tre excute avec succs. 12. Le PCRF retourne la rponse Rx Authenticate and Authorize Answer (AAA) au P-CSCF pour lui indiquer que la QoS a pu tre rserve dans le rseau daccs de lappelant. 102
Description de session IMS (Descriptions de l appelant et de l appel)
Appelant

v=0 c=IN IP6 3456::1:2:3:4 m=audio 49234 RTP/AVP 97 a=rtpmap:97 G.722.2/8000 b=AS:25 v=0 c=IN IP6 6789::5:6:7:8 m=audio 41212 RTP/AVP 97 a=rtpmap:97 G.722.2/8000 b=AS:25
Appel

Simon ZNATY
Copyright EFORT
103
A callers wants to make a call which consists of an ordinary voice call, plus additional bidirectional and unidirectional video streams. caller s terminal (UE1) builds a SIP INVITE containing an SDP that reflects caller s preferences and his UE1 capabilities. SDP (Session Description Protocol) contains supported codecs, bandwidth requirements and assigned local port numbers for each possible media flow.This example concentrates only on those parameters that are necessary for the policy control. v=0. The "v=" field gives the version of the Session Description Protocol. There is no minor version number. c= <network type> <address type> <connection address>. c specifies connection data. A session announcement must contain one "c=" field in each media description (see below) or a "c=" field at the session-level. It may contain a sessionlevel "c=" field and one additional "c=" field per media description, in which case the per-media values override the sessionlevel settings for the relevant media. C lines consist of <network type> which is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet". <address type> is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined. <address> is the globally unique address of the machine from which the session was created.In the example,address is 3456::1:2:3:4. m=<media> <port> <transport> <fmt list>. A session description may contain a number of media descriptions. Each media description starts with an "m=" field, and is terminated by either the next "m=" field or by the end of the session description. A media field also has several sub-fields: The first sub-field is the media type. Currently defined media are "audio", "video", "message ", etc.. The second sub-field is the transport port to which the media stream will be sent. The third sub-field is the transport protocol such as RTP/AVP - the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP. The fourth and subsequent sub-fields are media formats. For audio and video, these will normally be a media payload type as defined in the RTP Audio/Video Profile. b line specifies bandwidth information. b=<modifier>:<bandwidth-value> This specifies the proposed bandwidth to be used by the session or media, and is optional. <bandwidth-value> is in kilobits per second <modifier> is a single alphanumeric word giving the meaning of the bandwidth figure. Two modifiers are initially defined: CT Conference Total.: AS Application-Specific Maximum: The bandwidth is interpreted to be application-specific, i.e., will be the application's concept of maximum bandwidth. Normally this will coincide with what is set on the application's "maximum bandwidth" control if applicable.
103
Requte Rx AA-Request du PCSCF au PCRF (Exemple 1) (1)

<AA-Request> ::= < Diameter Header: 265, REQ, PXY, 16777236 > < Session-Id = pcscf1.orange.fr;222111;110 > { Auth-Application-Id = 16777236 (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 ] [ Flow-Description = permit out 17 from 6789::5:6:7:8 41212 to 3456::1:2:3:4 49234] [ Max-Requested-Bandwidth-UL = 25000 ] [ Max-Requested-Bandwidth-DL = 25000 ] [ Flow-Status = ENABLED ] ] ] Simon ZNATY Copyright EFORT
104
This new example allows PCC for RTP and RTCP traffic. Flow-Description : For uplink and downlink direction, a Flow-Description AVP is provided. The uplink destination address shall be copied from the "c=" line of downlink SDP. The uplink destination port shall be derived from the "m=" line of downlink SDP. The downlink destination address shall be copied from the "c=" line of uplink SDP. The downlink destination port shall be derived from the "m=" line of uplink SDP. Proto shall be derived from the transport of the "m=" line. For "RTP/AVP" proto is 17(UDP).
104
Requte Rx AA-Request du PCSCF au PCRF (Exemple 1) (2)

[ Media-Sub-Component = { Flow-Number = 2 } [ Flow-Description = permit in 17 from 3456::1:2:3:4 49235 to 6789::5:6:7:8 41213 ] [ Flow-Description = 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 ] ] [ Media-Type = AUDIO (0) ] ] [AF-Charging-Identifier = AyretyU0dm+6O2IrT5tAFrbHLso=023551024] [Specific-Actions = IP-CAN Change (6)]
Simon ZNATY
Copyright EFORT
105
The Flow-Usage AVP shall be supplied with value "RTCP" if the IP flow(s) described in the Media-Sub-Component AVP are used to transport RTCP.
105
Rponse Rx AA-Answer du PCRF au P-CSCF

<AA-Answer> ::= < Diameter Header: 265, PXY, 16777236 > < Session-Id = pcscf1.orange.fr;222111;110 > { Auth-Application-Id = 16777236 (Rx) } { Origin-Host = pcrf1.orange.fr } { Origin-Realm = orange.fr } { Result-Code = DIAMETER_SUCCESS (2001) }
Simon ZNATY
Copyright EFORT
106
106
Requte Gx Re-Auth Request (RAR) du PCRF au PCEF (i.e., PGW) (1)

<RA-Request> ::= < Diameter Header: 258, REQ, PXY, 16777238 > { Session-Id = pgw1.orange.fr;1144207323;110 } { Auth-Application-Id = 16777238 (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)} { Usage-Monitoring-Information = Usage-Monitoring-Report = USAGE_MONITORING_REPORT_REQUIRED (0)}
107
The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and is included in application-specific auth answers to inform the client of the action expected upon expiration of the Authorization-Lifetime. If the answer message contains an Authorization-Lifetime AVP with a positive value, the Re-AuthRequest-Type AVP must be present in an answer message. The following values are defined: AUTHORIZE_ONLY (0) : An authorization only re-auth is expected upon expiration of the Authorization-Lifetime. This is the default value if the AVP is not present in answer messages that include the Authorization-Lifetime. AUTHORIZE_AUTHENTICATE (1) : An authentication and authorization re-auth is expected upon expiration of the Authorization-Lifetime.
107
Rgle PCC relative au trafic RTP

[ Charging-Rule-Definition = { Charging-Rule-Name = Rule-VoIP-Service-1 } [ Service-Identifier = VoIP] [ Rating-Group = Groupe A ] [ Flow-Information =Flow-Description: permit in 17 from 3456::1:2:3:4 49234 to 6789::5:6:7:8 41212] [ Flow-Information =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 (0) ] [ Offline = ENABLE_OFFLINE (1) ] [ Metering-Method = VOLUME (1) ] [ AF-Charging-Identifier = AyretyU0dm+6O2IrT5tAFrbHLso=023551024 ] [ Flows = [ Flow-Number = 1 ]] [ Precedence = 1 ] ]
Simon ZNATY
Copyright EFORT
108
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. 108
Rgle PCC relative au trafic RTCP

[ Charging-Rule-Definition = { Charging-Rule-Name = Rule-RTCP-Service-1 } [ Service-Identifier = RTCP] [ Rating-Group = Groupe A ] [ Flow-Information =Flow-Description: permit in 17 from 3456::1:2:3:4 49235 to 6789::5:6:7:8 41213] [ Flow-Information =Flow-Description: permit out 17 from 6789::5:6:7:8 41213 to 3456::1:2:3:4 49235] [ 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) ] [ AF-Charging-Identifier = AyretyU0dm+6O2IrT5tAFrbHLso=023551024 ] [ Flows = [ Flow-Number = 2 ]] [ Precedence = 2 ] ]
Simon ZNATY
Copyright EFORT
109
109
UE
eNodeB
Modification du bearer ddi (mise jour de QoS) par le PDN GW P-CSCF

SGW
S1
PGW
MME
S11
S5
Gx
PCRF
SIP re-INVITE (sdp1 ) 183 Session Progress (sdp2 )

Rx AAR (sdp1, sdp2) 1. Gx. RAR 2. GTPv2C Update Bearer Request 3. GTPv2C Update Bearer Request 4. S1-AP Bearer Modify Request (ESM Session management configuration request) 5. RRC Connection Reconfiguration Request (ESM Session management configuration request) GTPv2-C S1-AP RRC Rx, Gx SIP
6. RRC Connection Reconfiguration Response (ESM Session management configuration accept) 7. S1-AP Bearer Modify Response (ESM Session management configuration response) 8. GTPv2C Update Bearer Response 9. GTPv2C Update Bearer Response 10. Gx. RAA Rx. AAA
110
1. Le P-CSCF sadresse au PCRF (Policy and Charging Rules Function) afin de lui demander de modifier les ressources laccs. Les descriptions sdp1 et sdp2 pralablement utilises pour rserver les ressources l accs sont dsormais remplaces par les nouvelles descriptions sdp1 et sdp2 . Pour ce faire, le P-CSCF met une requte Rx Authenticate and Authorize Request (AAR) contenant les informations des descriptions SDP de l appelant (SDP1 ) et de l appel (SDP2 ). 2. Lentit PCRF traduit la QoS des descriptions SDPs en des paramtres QoS spcifiques laccs EPS; elle met la requte Gx Re-Authorize Request (RAR) au PDN-GW. 3. Le PDN GW initie la modification du dedicated bearer laide de la requte Update Bearer Request (EPS Bearer QoS) indiquant la QoS requise;. Cette requte est reue par lentit Serving GW. 4. Le Serving GW relaie la requte Update Bearer Request (EPS Bearer QoS) au MME. 5. Lentit MME demande la modification du bearer daccs leNodeB laide de la requte S1-AP Bearer Modify Request (EPS Bearer QoS). 6. LeNodeB traduit la Qos demande dans le paramtre EPS Bearer QoS en une QoS correspondante sur linterface radio Radio Bearer QoS. Il notifie alors lUE la modification du bearer radio. 7. LUE acquitte la modification du bearer radio leNodeB. 8. LeNodeB acquitte la modification du bearer au MME laide de la rponse S1-AP Bearer Modify Response.. LeNodeB indique si la QoS requise a pu tre modifie ou non. 9. Le MME acquitte la modification du bearer au Serving GW par lenvoi de la rponse Update Bearer Response. 10. Le Serving GW acquitte la modification du bearer au PDN GW par lenvoi de la rponse Update Bearer Response. 11. Le PDN GW retourne la rponse Re-Authorize Answer (RAA) au PCRF pour lui indiquer que la politique de QoS a pu tre excute avec succs. 12. Le PCRF retourne la rponse Rx Authenticate and Authorize Answer (AAA) au P-CSCF pour lui indiquer que la QoS a pu tre modifie dans le rseau daccs de lappelant.
110
UE
Dsactivation dun bearer ddi par le PDN GW, lUE tant en mode actif
eNodeB S1
SGW MME
S11 S5
PGW
Gx
P-CSCF PCRF
Rx
SIP BYE
1. RAR STR
2. GTPv2C Delete Bearer Request 3. GTPv2C Delete Bearer Request 4. S1-AP Deactivate Bearer Request (ESM Session management configuration request) 5. RRC Connection Reconfiguration Request (ESM Session management configuration request) 6. RRC Connection Reconfiguration Response (ESM Session management configuration accept) GTPv2-C S1-AP RRC Rx, Gx SIP
7. S1-AP Deactivate Bearer Response (ESM Session management configuration accept) 8. GTPv2C Delete Bearer Response 9. GTPv2C Delete Bearer Response 10. RAA STA
111
Un usager met une requte SIP BYE afin de librer une session IMS en cours (e.g., session de tlphonie). Cette requte est relaye par lUE au P-CSCF. 1. Le P-CSCF sadresse au PCRF (Policy and Charging Rules Function) afin de lui demander de librer les ressources laccs. Pour ce faire, le P-CSCF met une requte Rx Session Termination Request (STR). 2. Lentit PCRF traduit la requte Rx STR en une requte Gx Re-Authorize Request (RAR) au PDN-GW. 3. Le PDN GW initie la liberation du dedicated bearer laide de la requte Delete Bearer Request.. Cette requte est reue par lentit Serving GW. 4. Le Serving GW relaie la requte Delete Bearer Request au MME. 5. Lentit MME demande la libration du bearer daccs (Radio access bearer, RAB) leNodeB laide de la requte S1-AP Deactivate Bearer Request. 6. LeNodeB notifie lUE la libration du bearer radio. 7. LUE acquitte la liberation du bearer radio leNodeB. 8. LeNodeB acquitte la liberation du radio access bearer au MME laide de la rponse S1-AP Delete Bearer Response.. 9. Le MME acquiite la liberation du dedicated bearer au Serving GW par lenvoi dune rponse Delete Bearer Response. 10. Le Serving GW acquitte la liberation du dedicated bearer au PDN GW par lenvoi de la rponse Delete Bearer Response. 11. Le PDN GW retourne la rponse Re-Authorize Answer (RAA) au PCRF pour lui indiquer que la politique a pu tre excute avec succs. 12. Le PCRF retourne la rponse Rx Session Termination Answer (STA) au P-CSCF pour lui indiquer que le dedicated bearer a pu tre libr dans le rseau daccs de lappelant.
111
Interface Rx

Linterface Rx est utilise afin que le P-CSCF fournisse au PCRF les informations obtenues de la signalisation SIP/SDP. Lentit PCRF par ailleurs retourne au P-CSCF des rponses et lui met des notifications travers cette interface Rx. Linterface Rx sappuie sur un ensemble de requtes/rponses Diameter telles que dfinies dans le RFC 3588 et la recommandation 3GPP TS 29.209. Quatre couples de rqute/rponses sont utilises sur le point de rfrence Rx :

AA-Request/AA-Answer (AAR&AAA); Re-Auth-Request/Re-Auth-Answer (RAR&RAA); Session-Termination-Request/Session-Termination-Answer (STR&STA); Abort-Session-Request/Abort-Session-Answer (ASR&ASA).
Simon ZNATY
Copyright EFORT
112
Le plan de session form par lIMS dispose dune fonction appele Proxy Call Stateful Control Function (P-CSCF) qui constitue le point dentre de lIMS. Le P-CSCF reoit les demandes dtablissement de session pour laccs aux contenus multimdia, il a connaissance du contexte de la session tablir et notamment de ses besoins en terme de QoS. Il est ainsi capable dinformer la fonction PCRF (Policy and Charging Rules Function) charge de la gestion de la QoS, du type de ressources requises pour la communication. Le PCRF sinterface avec lIMS et le plan de transfert afin dallouer les ressources ncessaires la session en fonction de la politique du rseau tout en exerant un contrle daccs aux ressources du rseau. The Authenticate and Authorize Request (AAR) message sent by the P-CSCF to the bandwidth manager must contain a Media Component Description. This performs a function within Diameter that is identical to that of the embedded SDP seen in SIP and H.248 in that it defines the bandwidth characteristics of the media stream being requested, thus allowing the bandwidth manager to determine how much resource and between which network, ingress and egress points are being requested. The AA-Answer would typically contain a result code (in this case, the result code would be DIAMETER SUCCESS but in a failure case, it might be INSUFFICIENT RESOURCES). Reservation clear down is performed by the Call Agent by sending a Session Termination Request (ST-Request) which would contain a cause for the release. The Session Termination Answer provides an acknowledgement that the termination was successful. Additional Diameter messages are used to allow the bandwidth manager to inform the Call Agent that a sessions resource has been lost for whatever reason, that is, dropped owing to a network failure. This is achieved by sending an Abort-Session-Request (ASR) containing an abort cause, and the P-CSCF would acknowledge this with an Abort-Session-Answer (ASA) message.
112
Interface Rx
Nom Commande
AAR Authenticate and Authorize request AAA Authenticate and Authorize answer RAR Re-Auth request RAA Re-Auth answer STR Session Termination request STA Session Termination answer ASR Abort Session request ASA Abort Session answer
Emis par
P-CSCF PCRF PCRF P-CSCF P-CSCF PCRF PCRF P-CSCF
Code
265 265 258 258 275 275 274 274
Simon ZNATY
Copyright EFORT
113
P-CSCF uses AAR to push SIP session information and IMS charging correlation identifier towards PCRF. This information is used in the PCRF to make an authorization decision about the request received via Gx interface. After receiving a SIP request or response containing SDP information, the P-CSCF sends an AAR to the PCRF. This command will carry the necessary information to construct downlink information (flow identifiers, calculate maximum bandwidth and derive maximum authorized QoS class) at the PCRF. P-CSCF secondly issues an AAR command when it receives a 183 Session Progress response from. The second AAR command will carry the necessary information to construct uplink information. The PCRF is now ready to authorize the whole bearer activation request. Within an initial AAR command the P-CSCF can also indicate whether the P-CSCF wants to be contacted in each bearer authorization or whether the PCRF can use available information to make the decision itself (resource reservation policy). Moreover, the P-CSCF may indicate that it is interested in receiving indications of loss of bearer, recovery of bearer or release of bearer. In these cases, the PCRF sends an RAR command to the P-CSCF after receiving an appropriate message from GGSN via the Gx reference point. The RAR command is acknowledged with an RAA command. The AAR command is acknowledged with an AAA command. In order to trigger the release of PDP context(s) associated with a SIP session, the P-CSCF sends an STR command. This could occur, for instance, when a SIP session is released. When the PCRF receives this command it will send another message via the Gx interface to trigger GGSN-initiated PDP context deactivation to prevent bearer misuse after SIP session termination. After receiving a bearer release notification from GGSN via the Gx reference point, the PCRF needs to notify the P-CSCF, if the P-CSCF has requested this type of notification. The PCRF uses an ASR command if all IP flows within a SIP session are affected. An RAR command is used instead if not all IP flows within a SIP session are affected. This could occur, for example, when only the video component of a multimedia session is dropped. When GGSN reports bearer loss or bearer recovery via the Gx reference point, the PCRF needs to notify the PCSCF, if the P-CSCF has requested this type of notification. In order to do so, the PCRF issues an RAR command.
113
Demande de service (Service Request)
Demande de service : Cette procdure est initie par lUE afin de demander au rseau dtablir un bearer radio. Cela correspond une transition du terminal de ltat IDLE ltat ACTIVE car lusager reprend une session de donnes ou active un nouveau service. Cette procdure de demande de service est utilise par l UE pour :
transfrer la signalisation (paging response) aprs que le rseau ait mis une requte de paging (paging request) l UE. transfrer les donnes usager dans les sens montant et descendant.
Simon ZNATY
Copyright EFORT
114
The network shall initiate the paging procedure for EPS services using S-TMSI when EMM signaling messages or user data is pending to be sent to the UE when no NAS signalling connection exists. To initiate the procedure the EMM entity in the network requests the lower layer to start paging and starts a timer for this paging procedure. Upon reception of a paging indication, the UE shall respond to the paging with a SERVICE REQUEST message with service type "paging response.
114
Demande de service initie par lUE

UE eNodeB S1
SGW MME
S11 S5
PGW
Gx
PCRF
HSS
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
Simon ZNATY
Copyright EFORT
115
1. The UE sends NAS message Service Request (S-TMSI) towards the MME encapsulated in an RRC message to the eNodeB. 2. The eNodeB forwards NAS message to MME. NAS message is encapsulated in an S1-AP: Initial UE Message (NAS message, TAI+ECGI of the serving cell). 4. The MME sends S1-AP Initial Context Setup Request (Serving GW address, S1-TEID(s) (UL), EPS Bearer QoS(s), Security Context, MME Signalling Connection Id, Handover Restriction List) message to the eNodeB. This step activates the radio and S1 bearers for all the active EPS Bearers. The eNodeB stores the Security Context, MME Signalling Connection Id, EPS Bearer QoS(s) and S1-TEID(s) in the UE RAN context. 5. The eNodeB performs the radio bearer establishment procedure. The user plane security is established at this step. When the user plane radio bearers are setup the Service Request is completed and EPS bearer state is synchronized between the UE and the network, i.e. the UE should remove the EPS bearer for which no radio bearers are setup.
t h e c a 6. The uplink M ax im u m f r om UE n eNodeB to the Serving GW. The eNodeB sends the uplink data to the Serving GW address and TEID provided in the step 4.
7. The eNodeB sends an S1-AP message Initial Context Setup Complete (eNodeB address, List of accepted EPS bearers, List of rejected EPS bearers, S1 TEID(s) (DL)) to the MME. 8. The MME sends an Modify Bearer Request message (eNodeB address, S1 TEID(s) (DL) for the accepted EPS bearers, Delay Downlink Packet Notification Request, RAT Type) to the Serving GW. The Serving GW is now able to transmit downlink data towards the UE. 9. The Serving GW sends an Modify Bearer Response to the MME.
115
Demande de service initie par le rseau

eNodeB
SGW Ch a 2. Downlink Data Notification 5. Paging 4. Paging Request 3. Downlink Data Notification Ack
PGW
1. Downlink Data
6. Service Request (service type = paging response) 7. User Plane Setup 8. Downlink Data
Simon ZNATY
Copyright EFORT
116
1. When the Serving GW receives a downlink data packet for a UE known as not user plane connected (i.e. the Serving GW context data indicates no downlink user plane TEID), it buffers the downlink data packet. and identifies which MME or SGSN is serving that UE. If the Serving GW receives additional downlink data packets for this UE before the expiry of a waiting timer, the Serving GW does not restart this timer. 2. & 3.The Serving GW sends a Downlink Data Notification message to the MME for which it has control plane connectivity for the given UE. The MME responds to the Serving GW with a Downlink Data Notification Ack message. If the Serving GW receives additional downlink data packets for this UE, the Serving GW buffers these downlink data packets and the Serving GW does not send a new Downlink Data Notification. 4. MME sends a Paging message (NAS ID for paging, TAI(s), UE identity) to each eNodeB belonging to the tracking area(s) in which the UE is registered. 5. If eNodeBs receive paging messages from the MME, the UE is paged by the eNodeBs. 6. On receipt of a paging message, the UE performs a service request procedure which results in moving the UE to ECM-CONNECTED state. UE-related information is thereby created in the EUTRAN, and the bearers are re-established. TheMME is responsible for the re-establishment of the radio bearers and updating the UE context in the eNodeB. This transition between the UE states is called an idle-to-active transition. 7. This triggers the MME to setup the user plane connection between eNodeB and Serving GW. 8. The downlink data are transferred to the UE.
116
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 Radio Bearer S1 Bearer
S 5 /S8 Bearer
Radio
S1
S5/S8
Gi
Simon ZNATY
Copyright EFORT
117
A bearer carries data from one network element to another. It is associated with a particular quality of service, which describes parameters such as the data rate, error rate and delay. The most important bearer is an EPS bearer, which carries data between the UE and the PDN gateway (P-GW). When the network sets up a data stream, the data are carried by an EPS bearer, and are associated with a particular quality of service. Its impossible to implement an EPS bearer directly, because it spans several interfaces that use different transport protocols. The EPS bearer is therefore broken down into three lower-level bearers: The radio bearer carries data between the UE and the E-UTRAN Node B (eNB). The S1 bearer carries data over the S1 interface, between the eNB and the serving gateway (S-GW). The S5/S8 bearer carries data over the S5 or S8 interface, between the S-GW and the P-GW (If these network elements are co-located, then this bearer is absent). The network can implement each of these bearers using the transport protocols that are appropriate for the corresponding interfaces. In particular, the radio bearer is implemented using the air interface protocols. Of course the EPS bearer does not carry the full end-to-end service, because there is also an external bearer which carries the data in the external network. This bearer lies outside the scope of the system, and is not considered it further.
117
Terminologie Bearer EPS
Qualit de service

GBR bearer : Dbit garanti (GBR, Guaranteed bit rate) Non-GBR bearer : Aucune garantie de dbit (Non-GBR, No Guaranteed bit rate) Default bearer

Temps d tablissement
Etabli lorsque l UE se connecte au PDN fournit une connectiv always-on non-GBR Etabli ultrieurement Peut tre GBR ou non-GBR
Dedicated bearer

Simon ZNATY
Copyright EFORT
118
There are a few different types of EPS bearer. One classification refers to quality of service: A GBR bearer has a guaranteed bit rate (GBR) amongst its quality-of-service parameters. A GBR bearer would be suitable for a conversational service, such as a voice call. A non-GBR bearer does not have a guaranteed bC Ssys te mq ui co n s bearer would be suitable for a background service, such as EMail. Another classification refers to the time when the bearer is established: One EPS bearer is established when the UE connects to a packet data network. This is known as a default bearer. It provides the user with an alwayson IP connection to that network. A default bearer is always a non-GBR bearer. Any additional EPS bearers for the same packet data network are known as dedicated bearers. Dedicated bearers can be either GBR or non-GBR bearers. In addition, every EPS bearer is associated with two traffic flow templates (TFTs), one for the uplink and one for the downlink. The TFT is a set of packet filters, which the UE and network use to map incoming packets to the correct EPS bearer.
118
Paramtres QoS
Chaque bearer EPS est caractris par :

QoS class identifier (QCI) Allocation and retention priority (ARP) Guaranteed bit rate (GBR) Maximum bit rate (MBR) Per APN aggregate maximum bit rate (APN-AMBR) Per UE aggregate maximum bit rate (UE-AMBR)
Chaque bearer GBR est caractris par :

Les bearers non-GBR sont caractriss ensemble par :

Simon ZNATY
Copyright EFORT
119
Every EPS bearer is associated with the following QoS parameters: QoS class identifier (QCI): This is a number which describes the error rate and delay that are associated with the service. More details are given on the next slide. Allocation and retention priority (ARP): This determines whether a bearer can be dropped if the network gets congested, or whether it can cause other bearers to be dropped. Emergency calls might be associated with a high ARP, for example. Every GBR bearer is also associated with the following parameters: Guaranteed bit rate (GBR): This is the long-term average bit rate that the user can expect to receive. Maximum bit rate (MBR): This is the maximum instantaneous bit rate that the network will ever provide. In release 8, the maximum bit rate equals the guaranteed bit rate, but this may be relaxed in future releases. Non-GBR bearers are collectively associated with the following parameters: Per APN aggregate maximum bit rate (APN-AMBR): This limits the total bit rate of the non-GBR bearers that a UE is exchanging with a particular access point name. Per UE aggregate maximum bit rate (UE-AMBR): This limits the total bit rate of all of the non-GBR bearers for a particular UE. (GBR bearers are excluded from these last two parameters.)
119
QoS Class Identifier (QCI)
Simon ZNATY
Copyright EFORT
120
The above table is an example of the possible QoS class definition for some GBR and non-GBR bearer types. In each case, some RT (Real-Time) and NRT (Non Real-Time) example services are given. The Default Bearer (which is established when the terminal connects to the PDN network, at registration) can only be a non-GBR bearer type. At the session setup, as part of the EPS bearer establishment, the terminal indicates associated requested Quality of Service attributes. These attributes are checked by the MME, as regards the user subscription rights provided by the HSS to the MME during the registration phase. Eventually, an answer is provided to the terminal, possibly containing reduced values of the attributes, if the terminal request exceeded the user subscription. Every EPS bearer is associated with a number called the QoS class identifier (QCI). Network nodes use the QCI as a reference, so as to look up the parameters that control the way in which packets from that data stream are forwarded. Example parameters include scheduling weights and queue management thresholds. Some QCI values have been standardized, and are associated with quality-of-service parameters that are listed in the table above. The parameters are as follows: QCI: Standardized QoS class identifier. Other values can be defined by the network operator. Bearer: Whether or not the bearer has a guaranteed bit rate. Priority: This affects the scheduling at the network nodes. 1 is the highest priority. Delay: Upper bound (with 98% confidence) for the delay that a packet can experience between the UE and the PDN GW. Packet error loss rate (PELR): Upper bound for the proportion of packets that are lost. (Non-GBR services can experience additional packet loss due to congestion.) The QoS parameters are not mandatory: instead, they are guidelines that network operators can use to work out the node-specific parameters noted above. The intention is that applications mapped to a particular QCI should receive roughly the same quality of service, whichever network they are in.
120
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)
Simon ZNATY
Copyright EFORT
121
Priority-Level AVP The Priority-Level is used for deciding whether a bearer establishment or modification request can be accepted or needs to be rejected in case of resource limitations (typically used for admission control of GBR traffic). It can also be used to decide which existing bearers to pre-empt during resource limitations. The priority level defines the relative importance of a resource request. Values 1 to 15 are defined, with value 1 as the highest level of priority. Values 1 to 8 should only be assigned for services that are authorized to receive prioritized treatment within an operator domain. Values 9 to 15 may be assigned to resources that are authorized by the home network and thus applicable when a UE is roaming. Pre-emption-Capability AVP The Pre-emption-Capability defines whether a service data flow can get resources that were already assigned to another service data flow with a lower priority level. The following values are defined: PRE-EMPTION_CAPABILITY_ENABLED (0) : This value indicates that the service data flow is allowed to get resources that were already assigned to another service data flow with a lower priority level. PRE-EMPTION_CAPABILITY_DISABLED (1) : This value indicates that the service data flow is not allowed to get resources that were already assigned to another service data flow with a lower priority level. This is the default value applicable if this AVP is not supplied. Pre-emption-Vulnerability AVP The Pre-emption Vulnerability defines whether a service data flow can lose the resources assigned to it in order to admit a service data flow with higher priority level. The following values are defined: PRE-EMPTION_VULNERABILITY_ENABLED (0) : This value indicates that the resources assigned to the service data flow can be pre-empted and allocated to a service data flow with a higher priority level. This is the default value applicable if this AVP is not supplied. PRE-EMPTION_VULNERABILITY_DISABLED (1) : This value indicates that the resources assigned to the service data flow shall not be pre-empted and allocated to a service data flow with a higher priority level.
121
Application des paramtres de QoS

UE-AMBR-DL = 1100000; UE-AMBR-UL = 550000 APN : ims.orange.fr QCI = 1 QCI = 7 QCI = 5 Dedicated Bearer (GBR) Dedicated Bearer (Non-GBR) Default bearer (Non-GBR)
GBR UL = 25000 GRB DL = 25000 MBR UL = 25000 MBR DL = 25000 APN-AMBR DL = 100000 APN-AMBR UL = 100000
APN : internet.orange.fr QCI = 1 QCI = 7 QCI = 9

Simon ZNATY
Dedicated Bearer (GBR) Dedicated Bearer (Non-GBR) Default bearer (Non-GBR)

Copyright EFORT
GBR UL = 25000 GRB DL = 25000 MBR UL = 25000 MBR DL = 25000 APN-AMBR DL = 1000000 APN-AMBR UL = 500000
122
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 caractris par des dbits garantis et des dbits maximum dans les sens montant et descendant. Le dedicated bearer avec QCI = 7 est utilis pour le Chat . Il s agit d un bearer Non-GBR et donc partage avec les autres bearers non-GBR de cet APN une QoS caractrise par un dbit maximum dans les sens montant et descendant. 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 caractrise par un dbit maximum dans les sens montant et descendant. Le dedicated bearer (QCI=7) et le default bearer (QCI=5) auront un debit total maximum qui ne pourra pas dpasser 100 kbit/S dans le sens descendant et 100 kbit/s dans le sens montant.
122
Exemples (1)
Appel d urgence (bearer ddi)

QCI = 1 ARP = 1 GBR UL = 25000 GBR DL = 25000 MBR UL = 25000 MBR DL = 25000 QCI = 5 ARP = 1 APN-AMBR UL = 20000 APN-AMBR DL = 20000
Signalisation SIP (bearer par dfaut)

Simon ZNATY
Copyright EFORT
123
123
Exemples (2)
Tlvision mobile (bearer ddi)

QCI = 4 ARP = 5 GBR UL = 10000 GBR DL = 256000 MBR UL = 10000 MBR DL = 512000 QCI = 9 ARP = 3 APN-AMBR UL = 2000000 APN-AMBR DL = 7200000
Accs Internet (bearer par dfaut)

Simon ZNATY
Copyright EFORT
124
124

A. Le premier default bearer est toujours tabli par : 1. L UE 2. Le Rseau B. Les default bearers additionnels sont tablis par : 1. L UE 2. Le Rseau C. Le dedicated bearer peut tre tabli par : 1. L UE 2. Le Rseau D. Un default bearer est : 1. Un bearer GBR 2. Un bearer non-GBR E. Un dedicated bearer peut tre : 1. Un bearer GBR 2. Un bearer non-GBR
Simon ZNATY
Copyright EFORT
125
A. The first default bearer is established by the network (MME) during the registration procedure. Correct answer : 2 B. Any additional default bearer can only be established by the user equipment (UE) after the user has successfully attached to the network. Correct answer : 1 C. A dedicated bearer may be established by the UE or by the network. Correct answer : 1 & 2 D. A default bearer can only be a non guaranteed bit rate bearer. Correct answer : 2 E. A dedicated bearer may be either a guaranteed bitrate bearer or non guaranteed bitrate bearer. Correct answer : 1 & 2
125
3.5. PCC : Policy and Charging Control
Simon ZNATY
Copyright EFORT
126
En mettrant en uvre un contrle de la qualit de service (QoS) et de la taxation, les oprateurs de service fixe et mobile peuvent : garantir la bande passante pour les services haut revenu, raliser une segmentation du march, assurer un usage adquat du rseau par les flux de service bloquer ou dgrader les flux de service qui dgradent les performances du rseau garantir la meilleure exprience utilisateur possible taxer les flux de services avec les mthodes de taxation online et offline. Les politiques de QoS et de taxation sont configures dans un nud centralis appel le PCRF (Policy and Charging Rules Function) ou RACS (Resource and Admission Control Subsystem) situ entre le service et les diffrents domaines de transport (e.g., 3G, LTE, xDSL, accs cble). Le PCRF a accs aux donnes de souscription de lusager afin de pouvoir adapter lusage des ressources de transport par le service ainsi que la taxation du service en fonction du profil de lusager.
126
Example d utilisation de PCC (Aujourd hui)

Aujourdhui grce aux procdures PCC, les oprateurs ont la possibilit dimplanter les scnarii suivants : Fair usage : Les oprateurs mobiles peuvent limiter la bande passante disponible aux usagers les plus consommateurs, typiquement ceux qui tlchargent en peer to peer. Par exemple, au del d un certain volume mensuel (e.g., 5 Gbytes), le dbit est limit 40 kbit/s. Freemium : Les oprateurs mobiles peuvent offrir l accs des applications telles que Facebook ou Twitter, afin d attirer les usagers souscrire un abonnement data mobile et ainsi accder d autres services data mobiles. Contrle d application : Les oprateurs 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 oprateurs peuvent alerter leurs clients lorsque ces derniers ont consomm leur forfait et lorsque tout usage supplmentaire induit des cots additionnels. 127 Simon ZNATY Copyright EFORT
127
Example d utilisation de PCC (Aujourd hui)
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 oprateur est la gnration de revenus. Premium mobile video : Les clients peuvent vouloir payer plus pour disposer d un service de vido mobile offrant une qualit suprieure sans affecter leur crdit data. Le but pour l oprateur est la gnration de revenus et pour le client une prservation de leur crdit data restant.
Simon ZNATY
Copyright EFORT
128
128
Les Evolutions de PCC

Jusqu 3GPP R5 1 PDP Bearer = 1 QoS Flow UE PDP Based Charging GGSN
Amliorations3GPP R6 UE 1 PDP Bearer = n Service Flows Flow Based Charging Control
GGSN
Amliorations 3GPP R7 1 PDP Bearer = n Service Flows UE Flow Based Policy and Charging Control
GGSN
Simon ZNATY
Copyright EFORT
129
Dans les anciennes versions des normes mobiles 3GPP (incluant la release 5, R5), lusager tablissait son PDP context (Packet Data Protocol Context) avec la qualit de service associe en fonction du type de service demand par le client. La taxation soprait sur lensemble des flux changs sur le PDP context soit en fonction du volume( nombre doctets mis et reus concernant lensemble des flux changs sur le PDP context) ou en fonction du temps (dure du PDP context). Malheureusement, il ntait pas possible dappliquer diffrentes rlges de taxation sur diffrents flux de service (e.g., WAP, streaming) qui auraient pu tre changs sur le mme PDP context. Pour diffrents flux de service taxs diffremment, il aurait fallu ouvrir plusieurs PDP context, et chacun transportant un type de flux. Aujourdhui les terminaux mme trs volus ne savent pas ouvvrir plus de deux PDP contexts. Avec lmergence de lIMS et lavnement des nouvelles applications sur IP, lorganisme de normalisation 3GPP a dcid de dfinir une architecture de taxation beaucoup plus flexible o il sagit de taxer les flux de service individuellement et non pas le PDP context dans son ensemble. A partir de la Release 6 des spcifications 3GPP, Les flux de service appels SDFs (Service Data Flows) sont identifis individuellement mme sil sous tous transports sur le mme PDP context (voir figure).^Chaque flux peut tre tax individuellement. Avec la Release 7, chaque flux peut tre contrl (e.g., autoris/bloqu) et tax en fonction dune rgle de taxation associe au flux de service. Chaque rgle de taxation dfinit 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 dIP). Cet dfinition permet lidentification les paquets du flux mis ou reus 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 associe des services IMS vers le serveur IMS appel P-CSCF Le trafic DNS vers le serveur DNS, etc.
129
IP-CAN session et IP-CAN bearer

IP-CAN signifie IP Connectivity Access Network. IP-CAN bearer: un chemin de transmission IP avec une capacit, un dlai, un taux derreur, etc. Les default et dedicated bearers EPS et les contextes PDP GPRS sont des exemples dIP-CAN bearers. IP-CAN session: Lassociation entre lUE reprsent par une adresse IPv4 ou IPv6, et un PDN reprsent par un PDN ID (e.g. an APN). Une IP-CAN session inclut un ou plusieurs IPCAN bearers. La capacit supporter plusieurs IP-CAN bearers par IP-CAN session dpend de lIP-CAN. Une IP-CAN session existe tant que ladresse IP de lUE est maintenue. IP flow: flux unidirectionnel de paquets IP avec la mme adresse de transport source (adresse IP, numro de port), la mme adresse de transport destination (adresse IP, numro de port) et le mme protocole de transport.
Copyright EFORT
Simon ZNATY
130
Un type IP-CAN est un type de rseau d accs, tel que GPRS (UTRAN/GERAN), accs xDSL, accs cble, EPS, etc. Une session IP-CAN (IP CAN session) est une association entre un UE et un rseau IP. Un bearer IP-CAN (IP-CAN bearer) est un chemin de transmission IP avec une capacit, un dlai, un taux d erreur, etc. Une session IP-CAN inclut un ou plusieurs bearers. Dans le contexte GPRS, une session IP-CAN consiste en un contexte PDP primaire et 0 N contextes PDP secondaires. Dans le contexte EPS, une session IP-CAN consiste en un default bearer et 0 N dedicated bearers. Le fait qu une session IP-CAN puisse consister en un ou pluseurs bearers est spcifique l IP-CAN. La taxation peut tre ralise par bearer IP-CAN ou par flux circulant sur le bearer IP-CAN.
130
Policy control concerne les fonctions de gating control, QoS control, event reporting (
1. Binding est la mise en place dune association entre un flux de donne de service (SDF, Service Data Flow) et un bearer daccs (IPCAN) transportant ce SDF. 2. Gating control est la capacit de bloquer ou autoriser des paquets IP appartenant des flux IP pour un certain service. 3. QoS control permet au PCRF de fournir au PCEF des QoS autorises pour les flux IP. 4. Event reporting permet au PCEF de notifier le PCRF dvnements lis aux ressource, sollicits ou non sollicits. A la suite, le PCRF modifie les rgles PCC et donc le comportement du plan usager. 5. IP-CAN bearer establishment permet aux PCRF de solliciter ltablissement de bearer par le rseau si le rseau daccs (IP-CAN) le supporte.
Charging Control inclut la taxation online (online charging) et la taxation offline (offfline charging). Le PCRF dcide de la mthode de taxation pour un flux de service donn. Cela permet au PCEF soit 131 Simon ZNATY EFORT d obtenir un crdit (online) ouCopyright de gnrer un ticket (offline).
Gating Control : Le PCRF prend des dcisions de filtrage qui sont ralises par le PCEF. Ces dcisions permettent de laisser passer certains flux et de bloque les autres flux. QoS Control : La qualit de service autorise peut inclure par exemple le dbit maximum par flux. Un flux est transport par un bearer. Un bearer supporte une classe de service (e.g., Conversationnel, streaming, interactive, background). Le PCEF doit sassurer quun flux de service soit accommod sur le bearer disposant de la classe de service approprie. Tous les flux empruntant ce bearer disposent de la mme classe de service. Le bearer dispose dun dbit maximum, et le dbit de chaque flux peut aussi limit un maximum. La somme des dbits maximum des diffrents flux empruntant le mme bearer doit bien sur tre infrieure au dbit maximum du bearer. Le PCEF doit contrler le dbit de chaque flux individuellement afin de sassurer quil nexcde pas sa QoS autorise. Charging Control :Mise en uvre de la taxation offline et de la taxation online.
131
Exemples de service data flows

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
Gx
OCS
Gy
OFCS
Gz
UE
SGSN/SGW
2 Contextes PDP
Service Flow2 (Internet) Packets to/from any
Charging Rule2 IP Filter 2
P C Charging Rule3 E Service Flow1 (IMS Signaling) ggsn1.orange.fr F IP Filter 3 Packets to/from IP 192.130.1.6 and Port 5060
GGSN/PDN GW PCEF : Policy and Charging Enforcement Function PCRF : Policy and Charging Rules Function Un exemple de plan tarifaire pour les services bass OCS : Online Charging System sur le contenu OFCS : Offline Charging System
Service type WAP Video streaming IMS Signaling
P-CSCF IP 192.130.1.6 Port 5060
Method Volume-based Time-based
Tariff of Group A $0.10/KB $0.50/minute Free

132
Les services offerts par le monde Internet sont dlivrs sur le mme contexte PDP primaire. Une rgle PCC est configure, associe au contexte PDP utilis pour l accs Internet. Cette rgle demandera la notification au PCRF lorsque 5 Go ont t consomms, afin de limiter le dbit ds lors que les 5 Go auront t atteints. Une autre rgle sera associe au trafic Internet pour bloquer tout autre flux qui n est pas un flux li Internet. La signalisation SIP est dlivre sur un autre contexte PDP primaire. Deux rgles PCC sont configures pour la signalisation SIP. La premire 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.
132
Architecture PCC Intgre

e.g., Tekelec Multimedia Policy Engine PCRF
Gy/Gz Gx
e.g., Huawei OCS OCS/OFCS
10 GE
10 GE
PCEF
Rseau priv oprateur
10 GE
10 GE
Internet
SGSN/SGW
GGSN/PDN GW e.g., GGSN STARENT
Firewall
SGW : Serving GW PGW : PDN GW PCC : Policy an Charging Control GE : Gigabit Ethernet
Interface physique Interface logique (Interface DIAMETER)

133
133
Architecture PCC Distribue
PCRF
OCS/OFCS
Gy/Gz
Gx
10 GE
Rseau priv oprateur
10 GE
10 GE
Internet
GGSN/PDN GW
Firewall Taxation et DPI externe e.g., Sandvine Policy Traffic Switch, Procera Networks PacketLogic PL Series, Allot Service Gateway Sigma
Simon ZNATY
Copyright EFORT
134
134
Fonctionnalit PCEF
Huawei GGSN avec PCEF : GGSN9811 (Gx and Gy sont supportes) PCEF Indpendant : Quidway SIG9800 Service Inspection Gateway (Gx et Gy supportes) CISCO GGSN avec PCEF : ASR5000 (Gx et Gy supportes) PCEF Indpendant: CSG Content Services Gateway 2nd Gen (Gx supporte) PCEF Indpendant : SCE (Service Control Engine). (Gx et Gy supportes). Procera Networks (ATCA) PCEF Indpendant: PacketLogic PL Series (Gx et Gy supportes) Sandvine PCEF Indpendant : Sandvine Policy Traffic Switch (Gx et Gy supportes) Allot (ATCA) PCEF Indpendant: Allot Service Gateway Sigma (Gx et Gy supportes) Ericsson SACC (Service Aware Charging and Control) est un PCEF fonctionnant en mode PCEF Indpendant ou PCEF intgr dans le GGSN 2010B. Il supporte les interfaces Gx and Gy PCEF Indpendant : SASN (Service-Aware Support Node). 135 NSN (ATCA) Simon ZNATY : Flexi NG10 GGSN (Gx et Gy supportes) Copyright EFORT
135
Fonctionnalit PCRF

Tekelec (Camiant) : Tekelec Policy Server. Capacit : 10000 00 transactions/s par blade G T P v2- C 00 t r a n s ac ti Bridgewater : Policy Controller Openet : FusionWorks Policy Manager Huawei : Unified Policy and Charging Controller (UPCC) CISCO : Intelligent Policy Control Function (IPCF) Ericsson : Service-Aware Policy Controller (SAPC) NSN : NSN PCS 5000 Alcatel-Lucent : 5780 Dynamic Services Controller (DSC) Volubill : CONTROL-IT Policy Manager
Simon ZNATY
Copyright EFORT
136
136
Fonctionnalit OCS

Volubill : CHARGE-IT Convergent Charging Huawei : Online Charging System Openet : Openets FusionWorks OCS system qui consiste en FusionWorks Convergent Charging, Network Edge Rating et Balance Manager Oracle : BRM (Billing & Revenue Mgmt) ZTE : Online Charging Solution Comptel : Control and Charge DigitalRoute : Policy Zone Roox : PCRF et OCS
Simon ZNATY
Copyright EFORT
137
137
Rgles PCC de l exemple

CCR mis par le PCEF au PCRF pour l tablissement du PDP context/bearer relatif aux flux Internet CCA retourn par le PCRF au PCEF :
Charging rule-install Charging-rule-definition (Internet) Charging-rule-definition (Autre flux)
CCR mis par le PCEF au PCRF pour l tablissement du PDP context/bearer relatif aux flux de signalisation SIP CCA retourn par le PCRF au PCEF :
Charging rule-install Charging-rule-definition (Signalisation SIP) Charging-rule-definition (Autre flux)

Copyright EFORT
Simon ZNATY
138
138
Rgle de taxation relative aux flux de service Internet

Charging-Rule-Name: Rule-Internet-Service-1 Service-Identifier: Internet Service Rating-Group: Group A Flow-Information : Flow-Description: permit in ip from 192.168.100.1 to any Flow-Information : Flow-Description: permit out ip from any to 192.168.100.1 Flow-Status : enabled (2) QoS-Information = Max-Requested-Bandwidth-UL = 2000000, Max-Requested-Bandwidth-DL = 7200000, Online : DISABLE_ONLINE (with value 0) Offline : ENABLE_OFFLINE (with value 1) Metering-Method = VOLUME (1) Precedence = 1 Monitoring-Key = Monitoring-Key-21 Granted-Service-Unit CC-Total-Octets AVP = 5000000000
139
139
Rgle de taxation relative aux autres flux qui ne sont pas des flux pour Internet
Charging-Rule-Name: Rule-Any-Other-Service Flow-Information : Flow-Description: permit in ip from any to any Flow-Information : Flow-Description: permit out ip from any to any Flow-Status : disabled Precedence : 100
Simon ZNATY
Copyright EFORT
140
140
Rgle de taxation relative au flux de signalisation SIP

Charging-Rule-Name: Rule-SIP-Signaling-1 Service-Identifier: SIP-Signaling Flow-Information :
Flow-Description: permit in ip 17 from 192.168.100.2 5060 to 192.130.1.6 5060
Flow-Information :
Flow-Description: permit out 17 from 192.130.1.6 5060 to 192.168.100.2 5060
Flow-Status : enabled QoS-Information : Max-Requested-Bandwidth-UL = 20000, Max-Requested-Bandwidth-DL = 20000, Online : DISABLE_ONLINE (with value 0) Offline : DISABLE_OFFLINE (with value 0) Precedence : 1
Simon ZNATY
Copyright EFORT
141
141
Rgle de taxation relative aux autres flux qui ne sont pas de la signalisation SIP
Charging-Rule-Name: Rule-Any-Other-Service Flow-Information : Flow-Description: permit in ip from any to any Flow-Information : Flow-Description: permit out ip from any to any Flow-Status : disabled Precedence : 100
Simon ZNATY
Copyright EFORT
142
142
Messages Gx (Diameter)
Message type CCR CCA RAR RAA
Description Credit Control Request Credit Control Answer Re-Auth Request Re-Auth Answer
Delivery direction PCEFPCRF PCEFPCRF PCEFPCRF PCEFPCRF
Simon ZNATY
Copyright EFORT
143
Le PCRF doit indiquer au PCEF via linterface Gx les rgles PCC que lentit PCC doit excuter. Procdure PULL : Suite une demande de rgles PCC initie par lentit PCEF via la requte CCR, lentit PCRF les retourne dans la rponse CCA. Procdure PUSH : le PCRF peut dcider de fournir des rgles PCC une entit PCEF soit avoir t sollicit par cette entit PCEF. Pour ce faire, le PCRF dispose de la requte RAR. Lentit PEF acquitte cette requte par une rponse RAA.
143
Scnario Fair Use 1 (1)

SGSN GGSN hPCRF SPR
PCEF
1. Activate PDP Context Request 2. Create PDP Context Request
PCRF
3. DIAMETER CCR-I 4. Store Information 5. Profile Request 6. Profile Response 7. PCC Rules Decision Policy Decision 8. Store PCC Rules 9. DIAMETER CCA-I
12. Activate PDP Context Accept
10. Store PCC Rules Policy Decision 11. Create PDP Context Accept
Simon ZNATY
Copyright EFORT
144
1.The UE sends a request to establish a primary PDP context for Internet access. 2. The GGSN receives the first Create PDP Context Request within an IP-CAN session. 3. A non-roaming case is considered here. The PCEF embedded in the GGSN informs the H-PCRF of the IP-CAN Session establishment. The PCEF starts a new Gx session by sending a CCR to the H-PCRF using the CC-Request-Type AVP set to the value INITIAL_REQUEST. 4. The H-PCRF stores the information received in the CCR. 5. The H-PCRF requires subscription-related information and does not have it. It sends a request to the SPR in order to receive the information. R l i es t s r el a t e o Co p yr i g ht E F O RT r ep wi t h he u b s c r i p t i on d i nf service(s), QoS information and PCC Rules information. 7. The H-PCRF selects or generates PCC Rule(s) to be installed. 8. The H-PCRF stores the selected PCC Rules. 9. The H-PCRF provisions the PCC Rules to the PCEF using CCA. The CC-Request-Type AVP set to the value INITIAL_REQUEST. As part of the rule a volume threshold is installed (5 GBytes). The volume is set for the PCC Rule. 10. The PCEF installs the received PCC Rules. The PCEF also enforces the authorized QoS and enables or disables service flows according to the flow status of the corresponding PCC Rules. 11. The GGSN accepts the PDP Context Request based on the results of the authorisation policy decision enforcement. If the requested QoS parameters do not correspond to the authorized QoS, the GGSN adjusts (downgrades /upgrades) the requested UMTS QoS parameters to the authorized values.
144

SGSN GGSN hPCRF SPR
PCEF
PCRF
5 Gbytes ont t consomms avant la fin du mois
13. DIAMETER CCR-U 14. DIAMETER CCA-U (Downgraded Maximum bitrate) Fin du mois 15. DIAMETER RAR (Default Max bitrate) 16. DIAMETER RAA
Simon ZNATY
Copyright EFORT
145
13. After some time the Quota of 5 GBytes is breached and the PCEF sends an updating CCR to the PCRF notifying it about the quota observed event. The CCRequest-Type AVP set to the value UPDATE_REQUEST. 14. Consequently (due to the quota breach) the PCRF modifies the bitrates on uplink and downlink associated with the PCC rule supplied to the PCEF in the CCA Initial Request (message 9). In this example we assume no more counting is needed. 15. New monthly billing cycle is observed. PCRF modifies again the bitrates on uplink and downlink which return to their default value (negotiated in the subscription). A RAR message is sent by PCRF to PCEF. 16. PCEF acknowledges the RAR message ith an RAA answer.
145

UE
PCEF
1. Establish IP-CAN Session Request 2. Gx CCR-I
PCRF
SPR
OCS
3. Store Information 4. Sh UDR 5. Sh UDA 6. PCC Rules Decision Policy Decision 7. Store PCC Rules 8. Gx CCA-I (Charging-Rule-install (2M/1Mbps), charging-Info (online), Event-Trigger = OUT_OF_CREDIT) 9. Store PCC Rules Policy Decision 10. Gy CCR-I (Quota Request) 12. Establish IP-CAN Session Accept 11. Gy CCA-I (Quota Granted = 10 Mbytes)
Copyright EFORT
Simon ZNATY
146
146

PCEF PCRF
10. Gy CCR-U (Quota Request) 11. Gy CCA-U (Quota Granted = 10 Mbytes) ... 13. Gx CCR-U (Event-Trigger = OUT_OF_CREDIT) 14. Gx CCA-U (Install new rule to throttle (384/128 Kbps)) Fin du mois 15. Gx RAR (Charging-Rule-install (2M/1Mbps), charging-Info (online), Event-Trigger = OUT_OF_CREDIT) 16. Gx RAA 17. Gy CCR-I (Quota Request) 18. Gy CCA-I (Quota Granted = 10 Mbytes) ...
OCS
147
147
Contrle du dbit en fonction du temps

UE
PCEF
PCRF
SPR
Application Function
1. Establish IP-CAN Session Request
2. Gx CCR-I
3. Sh UDR 4. Sh UDR
6. Establish IP-CAN Session Accept
5. Gx CCA-I (Charging-Rule-install (1Mbps/384Kbps), charging-Info (offline)) 7. Rx AAR (Activation de la promotion) 8. Rx AAA 9. Gx RAR-U (Charging-Rule-Install (7.2Mbps/2.1Mbps), charging-Info (offline)) 10. Gx RAA-U 11. Rx AAR (Dsactivation de la promotion) 12. Rx AAA 13. Gx RAR-U (Charging-Rule-install (1Mbps/384Kbps), charging-Info (offline)) 14. Gx RAA-U
Simon ZNATY
Copyright EFORT
148
148
Anti-bill shock
UE
PCEF
PCRF
SPR
SMSC
1. Establish IP-CAN Session Request
Obtention des volume/seuil en fonction du pays) 5. Gx CCA-I (Charging-Rule-install (2Mbps/1Mbps), charging-Info (offline), monitoring key : CC-total-octet = 10000000) 6. Establish IP-CAN Session Accept 4. Sh UDR 7. Gx CCR-U (Event-Trigger=Volume-Threshold-Reached) 8. Gx CCA-U (Charging-Rule-install (2Mbps/1Mbps), charging-Info (offline), monitoring key : CC-total-octet = 10000000) 9. SMS delivery with SMPP 10. SMS delivery
2. Gx CCR-I (adresse Serving GW)
3. Sh UDR
149
149
3.6. Services du domaine circuit (CS) sur laccs PS

3GPP TR 23.879 V9.0.0 (2009-03)
Simon ZNATY
Copyright EFORT
150
150
3.6.1. Alternative 1 : CS Fallback

Aussi appele Page in eUTRAN, Call in GSM/WCDMA
3GPP TS 23.272
Simon ZNATY
Copyright EFORT
151
Voice service with LTE terminals can also be offered before high quality VoIP support is included into LTE radio and before IP Multimedia Subsystem (IMS) is deployed. The first phase can use so-called Circuit Switched (CS) fallback for LTE where the LTE terminal will be moved to GSM, WCDMA or CDMA network to provide the same services that exists in CS networks today, for example voice or videotelephony calls. The CS fallback procedures require that the Mobility Management Entity (MME) as well as Mobile Switching Center (MSC)/Visiting Location Register (VLR) network elements are upgraded to support procedures described in this section. The CS fallback in EPS enables the provisioning of voice and other CS-domain services (e.g. CS videotelephony/ SMS/ LCS/ USSD) by reuse of CS infrastructure when the UE is served by E-UTRAN. A CS fallback enabled terminal, connected to E-UTRAN may use GERAN or UTRAN to establish one or more CS-domain services. This function is only available in case E-UTRAN coverage is overlapped by either GERAN coverage or UTRAN coverage. CS Fallback and IMS-based services shall be able to co-exist in the same operators network. The advantage of the fallback handover is that there is no urgent need to implement QoS support in LTE or SAE. The network optimization may also be less stringent if the voice is not supported initially. Also, there is no need to deploy IMS just because of the voice service. From the end user point of view, the voice service in GSM or in WCDMA is as good as voice service in LTE, except that the highest data rates are not available during the voice call. On the other hand, the CS fallback for LTE adds some delay to the call setup process as the UE must search for the target cell. With high mobility, the CS fallback for LTE may also affect the call setup success rate, which naturally needs to be addressed in practical implementation.
151
CS Fallback dans l architecture EPS

S4-SGSN UTRAN IuPS IuCS Gb
UE
Gs MSC Server
GERAN
A SGs
S3 E-UTRAN S1-C MME
Simon ZNATY
Copyright EFORT
152
Voice service with LTE terminals can also be offered before high quality VoIP support is included into LTE radio and before IP Multimedia Subsystem (IMS) is deployed. The first phase can use so-called Circuit Switched (CS) fallback for LTE where the LTE terminal will be moved to GSM, WCDMA or CDMA network to provide the same services that exists in CS networks today, for example voice calls or SMS. The Circuit Switched fallback procedures require that the Mobility Management Entity (MME) as well as MSC Server network elements are upgraded to support CSFB procedures. For SMS, an optimization is proposed where the UE sens the SMS for LTE and MME forwards that SMS over SGs to the MSC Server. The CS fallback in EPS function is realized by using the SGs interface mechanism between the MSC Server and the MME. The SGs interface functionality is based on the mechanisms specified for the Gs interface.
152
Procdure d Attachement
UE
MSC Server MME
HSS
1. Attach Request
2. Procdure d attachement dans l EPS

3. Dduit le numro de VLR (Mapping Tracking Area Location Area) 4. Location Update Request 5. Cre l association SGs
6. Mise jour de localisation dans le domaine CS

7. Location Update Accept 8. Attach Accept
Simon ZNATY
Copyright EFORT
153
When LTE UE executes the attach procedure towards the LTE core network, the LTE core network will also execute a location update towards the serving CS core network to announce the presence of the terminal to the CS core network via the LTE network in addition to executing the normal attach procedures. The UE sends the attach request together with specific CS Fallback Indicator to the MME, which starts the location update procedure towards MSC Server via an IP based SGs interface. The new Location Area Identity (LAI) is determined in the MME based on mapping from the Tracking area. Combined TA/LA Update procedure The combined TA/LA Update procedure for the CS fallback in EPS is realized based on the combined RA/LA Update procedure 1. The UE initiates the attach procedure by the transmission of an Attach Request (including the Attach Type) message to the MME. The Attach Type indicates that the UE requests a combined EPS/IMSI attach and informs the network that the UE is capable and configured to use CS fallback. 2. The EPS Attach procedure is performed wiyj interactions between the MME and the HSS. 3. The VLR shall be updated according to the combined GPRS/IMSI Attach procedure if the Attach Request message includes an Attach Type indicating that the UE requests a combined EPS/IMSI attach. The MME allocates a default LAI, which is configured on the MME and may take into account the current TAI and/or E-CGI. The MME derives a VLR number based on the allocated LAI and on an IMSI hash function. The MME starts the location update procedure towards the new MSC/VLR or MSC Server/VLR upon receipt of the first Insert Subscriber Data message from the HSS in step 2. This operation marks the MS as EPS-attached in the VLR. 4. The MME sends a Location Update Request message to the VLR. MME address is an IP address. 5. The VLR creates an association with the MME by storing MME address. 6. The VLR performs Location Updating procedure in CS domain. 7. The VLR responds with Location Update Accept (VLR TMSI) to the MME. 8. The MME sends an Attach Accept message to the UE. The existence of LAI and VLR TMSI indicates successful attach to CS domain.
153
Procdure de Dtachement
UE
MSC Server MME
HSS
1. Detach Request 2. Procdure de dtachement dans l EPS
3. IMSI Detach Indication 4. Supprime l association SGs 5. Detach Accept
Simon ZNATY
Copyright EFORT
154
1. The UE initiates the detach procedure by the transmission of a Detach Request (with parameters including Detach Type) message to the MME. Detach Type indicates which type of detach is to be performed, i.e., IMSI Detach only or combined EPS and IMSI Detach. 2. If EPS detach is indicated in step 1, the EPS Detach procedure is performed. 3. The MME sends an IMSI Detach Indication (IMSI) message to the VLR. 4. The VLR removes the association with the MME. 5. The MME sends a Detach Accept message.
154
Procdure de mise jour combine de TA/LA

UE
MSC Server MME
HSS
1. L UE dcide de raliser l opration TAU 2. TAU Request 3. Procdure TAU dans l EPS 4. Location Update Request
5. Mise jour de localisation dans le domaine CS 6. Location Update Accept 7. TAU Accept
Simon ZNATY
Copyright EFORT
155
1. The UE detects a change to a new TA by discovering that its current TAI is not in the list of TAIs that the UE registered with the network or the UE's TIN indicates the need for a TAU when re-selecting to E-UTRAN.. The combined TA/LA Update Procedure is also performed in order to re-establish the SGs association. 2. The UE initiates the TAU procedure by sending a TAU Request (parameters including the Update Type) message to the MME. The Update Type indicates that this is a combined Tracking Area/Location Area Update Request or a combined Tracking Area/Location Area Update with IMSI attach Request. 3. The EPS TAU procedure is performed. 4. If there is an associated VLR in the MM context, the VLR also needs to be updated. If the association has to be established or if the LA changed, the new MME sends a Location Update Request message to the VLR. New LAI is determined in the MME based on the received GUTI from the UE. If this GUTI is mapped from a P-TMSI/RAI, the LAI is retrieved from the GUTI without any modification by the MME. Otherwise, the MME allocates a default LAI, which is configured on the MME and may take into account the current TAI/or E-CGI. The MME retrieves the corresponding VLR number from the determined LAI. The Location Update Type shall indicate normal location update. The MME address is an IP address. 5. The VLR performs Location Update procedure in CS domain. 6. The VLR responds with Location Update Accept (VLR TMSI) to the MME. 7. The MME sends a TAU Accept message to the UE. The VLR TMSI is optional if the VLR has not changed. The presences of the LAI indicate to the UE that it is IMSI attached.
155
Demande dtablissement dappel dans E-UTRAN, appel dans GERAN/UTRAN

UE
eNodeB RNC
MSC Server MME
SGSN
Serving GW
1a. Service Request 1a. Service Request 1b. Message S1-AP avec indicateur CS Fallback
2. Sollicitation de rapport de mesure (optionnel) 3. Handover paquet (PS, Packet Switching) de LTE 3G 4. Procdure d tablissement d appel CS (Circuit Switching) 5. Handover paquet de 3G LTE
Simon ZNATY
Copyright EFORT
156
The UE sends a CS call request to the eNodeB, which may ask the UE to measure the target cell. eNodeB triggers the handover to the target system. the UE starts the normal CS call establishment procedure in the target cell. Once the CS call ends, the UE again reselects LTE to get access to high data rate capabilities. 1a. The UE sends Service Request (CS Fallback Indicator) to MME. Service Request message is encapsulated in RRC and S1-AP messages. CS Fallback Indicator indicates MME to perform CS Fallback. The UE only transmits this request if it is attached to CS domain (with a combined EPS/IMSI Attach) and cannot initiate an IMS voice session (because e.g. the UE is not IMS registered or IMS voice services are not supported by the serving EPS service provider). 1b. The MME sends an S1-AP Request message to eNB that includes a CS Fallback indicator. This message indicates to the eNB that the UE should be moved to UTRAN/GERAN. 2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN cell to which PS handover will be performed. 3. The eNodeB triggers PS handover to a GERAN/UTRAN neighbour cell by sending a Handover Required message to the MME. In the following an inter-RAT handover from E-UTRAN to UTRAN or GERAN begins. As part of this handover, the UE receives a HO command from E-UTRAN and tries to connect to a cell in the target RAT. The HO command from E-UTRAN may contain a CSFB Indicator which indicates to UE that the handover is triggered due to a CS fallback request. If the HO from E-UTRAN Command contains a CSFB Indicator and the UE fails to establish connection to the target RAT, then the UE considers that CSFB has failed. 4. The UE initiates the CS call establishment procedure. 5. After the UE moves to a cell in the target RAT, the inter-RAT handover from E-UTRAN to UTRAN or GERAN is completed. At the end of this handover the UE may trigger the Routing Area Update procedure when the sending of uplink packet data is possible. The worst effect of CSFB is probably the extra time needed to make or receive calls. Call set-up latency is a major factor in determining quality of experience with phone calls. Many people remember the seeminglyamazing shift to digital exchanges on fixed-line networks, when calls connected the instant the last digit was dialled. Most cellular calls today are already a retrograde step from this and making matters noticeably worse with the latest and greatest generation of cellular technology is far from ideal. There have been various attempts made to calculate the impact of CSFB on call establishment times. Although findings vary somewhat based on input assumptions and precise procedures followed, the general consensus seems to be that the best-case scenario is an extra 1-2 seconds, an average perhaps 2-3 seconds, and worstcase may be as bad as 6-8 seconds. Much of the extra time comes from the need for the phone to start up the 2G/3G radio, which involves measuring different channels to find the appropriate cell and frequency to connect.
156
Appel entrant : Paging CS dans EUTRAN, appel dans GERAN/UTRAN

UE eNodeB RNC SGSN
MSC Server
HSS GMSC Server
MME 1. IAM
2. CS Paging Indication 3. Paging (CS Domain Indicator) 4. Paging (CS Domain Indicator) 5. Handover paquet (PS, Packet Switching) de LTE 3G 6. CS Paging Response 7. CS Paging Response
Simon ZNATY
Copyright EFORT
157
1. GMSC sends IAM to the MSC/VLR on the terminating side. 2. The MSC/VLR sends a Page message to the MME via SGs. 3. The MME receives the Page message from the MSC/VLR. If the UE is in ECM-IDLE state, the MME sends a Paging message to each eNodeB serving the TA list the UE is registered to. If the UE is in ECMCONNECTED, the MME relays the CS Page message to the serving eNodeB over the S1 interface. 4. The eNodeB receives CS paging messages from the MME. The eNodeB forwards the paging message to the UE 5. The eNodeB triggers PS handover to a GERAN/UTRAN neighbour cell by sending a Handover Required message to MME. In the following an inter-RAT handover from E- UTRAN to UTRAN or GERAN begins. As part of this handover, the UE receives a HO command from E- UTRAN and tries to connect to a cell in the target RAT. The HO command from E-UTRAN may contain a CS Fallback Indicator which indicates to UE that the handover was triggered due to a CS fallback request. If the HO command from E-UTRAN contains a CS Fallback Indicator and the UE fails to establish connection to the target RAT, then the UE considers that CS fallback has failed. 6. When CS Fallback completes, the UE responds to the CS paging request and returns the CS paging response to the RNS/BSS. 7. When received at the RNS/BSS, the CS Paging Response message is sent to the MSC/VLR. The MSC/VLR receives CS paging response contained in corresponding message which shall then stop the paging response timer and establish the CS connection, then the MT call process takes place.
157
Envoi de SMS en mode idle

UE
MSC Server MME

1. EPS/IMSI attach procedure 2. UE triggered Service Request 3. Uplink NAS Transport 4. Uplink Unitdata
HLR/HSS
SMSC
5. MAP-MO-FORWARD-SHORT-MESSAGE
4a. Downlink Unitdata 4a. Downlink NAS Transport
8. MAP-MO-FORWARD-SHORT-MESSAGE-Ack
7. Downlink Unitdata 8. Downlink NAS Transport 9. Uplink NAS Transport 10. Uplink Unitdata 11. Release Request
Simon ZNATY
Copyright EFORT
158
1. The combined EPS/IMSI attach procedure is performed. 2. A mobile originating SMS is triggered and the UE is in idle mode. The UE initiates the UE triggered Service Request procedure. The UE indicates its S-TMSI (short form of GUTI) in the RRC signalling. 3. The UE builds the SMS message to be sent (i.e. the SMS message consists is embedded in SM message called SMS-SUBMIT). Following the activation of the Radio Bearers, the SMS message is encapsulated in an NAS message and sent to the MME. 4. The MME forwards the SMS message to the MSC/VLR in an Uplink Unitdata message. In order to permit the MSC to create an accurate charging record, the MME adds the IMEISV, the local time zone, the Mobile Station Classmark 2, and the UE's current TAI and E- CGI. 4a. The MSC Server acknowledges receipt of the SMS to the UE. 5. and 6. The MSC Server delivers a MAP-MO-Forward-Short-Message which contains the SMS to the SMSC. SMSC Acknowledges reception of that SMS. 7. The MSC Server forwards the received delivery report to the MME associated with the UE in a Downlink Unitdata message. 8. The MME encapsulates the received delivery report in an NAS message and sends the message to the UE. 9, 10. The UE acknowledges receipt of the delivery report to the MSC Server. 11. The MSC Server indicates to the MME that no more NAS messages need to be tunnelled. If the UE were in the active mode when sending its SMS, step 2 is omitted.
158
Rception de SMS en mode idle

UE eNodeB
MSC Server MME
HLR/HSS
SMSC
1. EPS/IMSI attach procedure

2. MAP-SEND-ROUTING-INFO-FOR-SMS 3. MAP-SEND-ROUTING-INFO-FOR-SMS-Ack 4. MAP-MT-FORWARD-SHORT-MESSAGE
5. Paging 7. Paging 6. Paging
8. Service Request 9b. Downlink NAS Transport 9c. Uplink NAS Transport 10. Uplink NAS Transport
8a. Service Request 9a. Downlink Unitdata 9d. Uplink Unitdata 11. Uplink Unitdata 12. MAP-MT-FORWARD-SHORT-MESSAGE-Ack
14. Downlink NAS Transport
13. Downlink Unitdata 15. Release Request
Simon ZNATY
Copyright EFORT
159
1. The combined EPS/IMSI attach procedure is performed. 2. and 3. The SC initiates transfer of mobile terminating SMS. The HLR is requested to provide the global title (GT) for SMS routing and the SMS message is forwarded to the MSC Server where the UE is CS attached. HLR returns this global title. 3. The MSC Server sends a Paging (IMSI, VLR TMSI, Location Information, SMS indicator) message to the MME. 4. The SMSC origines a MAP-MT-FORWARD-SHORT-MESSAGE and forwards it to the MSC Server. 6. The MME initiates the paging procedure by sending the Paging message to each eNodeB with cells belonging to the tracking area(s) in which the UE is registered. The UE is paged with its S-TMSI. 7. The UE is paged by the eNodeBs. 8. The UE sends a Service Request message to the MME. The UE indicates its S-TMSI in the RRC signalling. The MME sends the S1-AP Initial Context Setup Request message to the eNodeB and the eNodeB establishes the Radio Bearers. 8a. The MME sends a Service Request message to the MSC Server. In order to permit the MSC to create an accurate charging record, the MME adds the IMEISV, the local time zone, the Mobile Station Classmark 2, and the UE's current TAI and E- CGI. 9a. The MSC Server builds the SMS message to be sent as defined in TS 23.040 (i.e. the SMS message is contained in the SM SMS-SUBMIT message). The MSC Server forwards the SMS message to the MME in a Downlink Unitdata message. 9b. The MME encapsulates the SMS message in a NAS message and sends the message to the MS/UE. 9c, 9d. The MS/UE acknowledges receipt of the SMS message to the MSC/VLR. 10. The UE returns a delivery report. The delivery report is encapsulated in an NAS message and sent to the MME. 11. The MME forwards the delivery report to the MSC Server in an Uplink Unitdata message. 12. The MSC Server returns an MAP-MT-FORWARD-SHORT-MESSAGE-Ack to the MSC Server. 13-14. In parallel to steps 12, the MSC Server acknowledges receipt of the delivery report to the MS/UE. 16. The MSC Server indicates to the MME that no more NAS messages need to be tunnelled.
159
4. IMS : IP Multimedia Subsystem
Simon ZNATY
Copyright EFORT
160
L'Internet supporte depuis dj plusieurs annes et avec une qualit trs acceptable de nombreux services succs tels que l'E-mail, le WEB, le streaming audio/vido, le chat . Dans les domaines des applications de tlphonie et les communications multimdia, Microsoft MSN, Yahoo (Messenger), Microsoft (MSN), Google (GoogleTalk) et Ebay (Skype) sont dj prsents sur ce march mais proposent des solutions propritaires. La tlphonie devient donc une application sur Internet parmi dautres et tout fournisseur d'applications sur l'Internet peut proposer le service de tlphonie sur IP ses clients indpendamment du type daccs Internet utilis par le client : ADSL, cble, et demain, 3G+ et LTE. Dans ce contexte les oprateurs de tlcommunication dont le service de tlphonie tait jusqu prsent le core business se trouvent face lalternative suivante : Repositionner leur business autour des applications sur IP incluant la tlphonie, devenant ainsi oprateur de services globaux. Les oprateurs qui feront ce choix devront rapidement dvelopper une architecture IMS seule solution normalise dans le monde des tlcommunications et cela avant que des solutions propritaires ne soient trop largement adoptes. Abandonner le march des applications y compris celui de la tlphonie et rduire leur business celui de fournisseur daccs et/ou de transporteur de paquets IP. Les oprateurs qui feraient ce choix limiteraient leur champs daction celui doprateurs de rseaux. Parmi les risques de cette option, la difficult maintenir le revenu dans un contexte ou l'accs comme le transport seront devenus des commodits sujettes une trs forte pression sur les prix. L'IMS IP Multimedia Subsytem- normalis par le monde des tlcommunications est une nouvelle architecture base sur de nouveaux concepts, de nouvelles technologies, de nouveaux partenaires et un nouvel ecosystme. LIMS supporte sur un rseau tout IP les sessions applicatives temps rels (voix, vido, confrence,) et non temps rel (Push To Talk, Prsence, messagerie instantane,). LIMS intgre de plus le concept de convergence de services supports indiffremment par des rseaux de natures diffrentes : fixe, mobile ou Internet. LIMS est galement dsign sous le vocable de NGN Multimedia (Next Generation Network) Dployer une architecture IMS est donc une dcision stratgique qui peut tre prise par un oprateur de tlcommunication traditionnel dans le cadre du repositionnement de son activit sur le march des services sur IP mais qui peut galement tre prise par toute entit qui dciderait, mme sans possder de rseaux daccs ou de transport de dvelopper une activit de services valeur ajoute sur IP.
160
4.1. Pourquoi IMS et quest-ce quIMS ?

IMS : IP Multimedia Subsystem SIP : Session Initiation Protocol
Simon ZNATY
Copyright EFORT
161
161
Pourquoi lIMS?
Comme la tlphonie est simplement une application sur Internet, toute entreprise, mme sans fournir de rseau daccs, peut proposer un service de tlphonie. Microsoft (MSN), Yahoo (Messenger), Google (GoogleTalk) et Ebay (Skype) sont dj prsents sur ce march mais proposent des solutions de tlphonie propritaires. Les oprateurs voudront continuer offrir des services tlphoniques mme lorsque les rseaux IP auront remplac les rseaux tlphoniques actuels. Les oprateurs ne veulent pas abandonner les services lusagers et devenir uniquement des transporteurs de paquets IP. En effet laccs est devenir une commodit avec une pression forte sur les prix. Les oprateurs doivent rapidement adopter lIMS avant que les solutions propritaires puissent tre largement adoptes, sinon ils se contenteront d tre des fournisseurs daccs.
Copyright EFORT
Simon ZNATY
162
162
IMS : Une dfinition
Selon les standards, l IMS est dfinie sous la forme d une architecture de rfrence afin de fournir des services de communication de prochaine gnration mixant la voix, la vido, les donnes et la mobilit sur un rseau IP. L IMS est considr comme un sous-systme car il n est qu une partie d un rseau complet. En dautres termes, l IMS requiert dautres composants tels que le rseau d accs afin de jouer le rle de systme fournit des services multimdia. L IMS est une architecture fonctionnelle de rfrence. Elle consiste en un ensemble d entits fonctionnelles disposant d interfaces entre elles. Toutes les interfaces de l IMS sont supportes par des protocoles IP.
Simon ZNATY
Copyright EFORT
163
L IMS doit fournir au client des services de communication multimdia. L IMS n est pas un systme mais juste un sous systme. En effet, pour qu un client accde ses services IMS il doit passer par un accs. Il est donc ncessaire de disposer de rseaux d accs s interfaant au rseau IP qui supporte l architecture de rseau et de services IMS. Parmi les accs possibles figurent xDSL, l accs cble, FTTx, WiMAX, etc. L IMS est une architecture fonctionnelle de rfrence. Elle est normalise au niveau mondial. Comme toute architecture fonctionnelle, elle consiste en un ensemble d entits relies entre elles par des interfaces. Les interfaces sont supportes par des protocoles. L IMS tait une architecture tout IP, tous les protocoles sont issus du monde IP. Deux protocoles de signalisation sont utiliss par l IMS : SIP (Session Initiation Protocol) pour le contrle de session et de service et DIAMETER pour les procdures AAA (Authentification, Authorisation, Accounting). Deux protocoles de transport de l information usager sont utiliss par l IMS : RTP (Realtime Transport Protocol) pour le trafic temps rel tel que le trafic voix, vido, IPTV, streaming, etc., et le protocole MSRP (Message Session Relay Protocol) pour le transport des donnes de l usager, tel que les donnes dans le contexte d un tchat (messages instantans, fichiers, photos, etc.).
163
Ce que lIMS fournit
LIMS fournit :
La continuit du business model associ aux rseaux RTC et GSM Un rseau IP multi-service, multi-accs, scuris et fiable Multi-services : dlivrs par un rseau cur supportant diffrents niveaux de QoS, Multi-accs: Tout rseau daccs large bande, fixe et mobile peut sinterfacer lIMS Non pas un rseau unique, mais diffrents rseaux qui interoprent grce des accords de roaming IMS fixe-fixe, fixe-mobile, mobilemobiles Un enabler pour les fournisseurs de service afin d offrir Des services de communication non temps-reel, pseudo tempsrel et temps rel suivant une configuration client-server ou entre entits paires Mobilit de l usager (Nomadisme)/ Mobilit des services / Mobilit de la session Plusieurs sessions et services simultanment sur la mme 164 Simon ZNATY Copyright EFORT connexion rseau
LIMS permet de conserver lintelligence dans le rseau mme si le transport sappuie dsormais sur IP. Avec le monde IP, par dfaut lintelligence est la priphrie, cest dire dans les terminaux connects au rseau IP. LIMS suit donc la philosophie du RTC et du GSM pour que l oprateur puisse proposer et facturer des services conversationnels sur IP. LIMS peut offrir plus que simplement les services voix car cest une architecture qui sappuie sur un transport IP qui par dfinition est un transport multiservices. Ainsi des sessions voix, vido et data sont possibles avec lIMS. LIMS est une architecture indpendante de tout accs large bande, permettant demain un oprateur global de mettre en uvre une seule instance IMS qui pourra offrir des services conversationnels ses clients xDSL, 3G, WiMax, cble, etc. Ceci est diffrent de la situation actuelle, o il y a dune part des commutateurs RTC et dautre part des commutateurs GSM qui servent les clients fixe et mobile respectivement. L IMS supporte le concept de roaming permettant aux clients d un oprateur de disposer de leurs services IMS dans leur rseau nominal et dans des rseaux visits. L IMS fournit des services temps rels (e.g., session audio et vido entre un appelant et un appel, session confrence audio ou vido), des services pseudo temps rel (e.g., session push to talk entre diffrents participants), et des services non temps rel (e.g., envoi d un message court). L IMS permet la mobilit de l usager qui peut senregistrer 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 transfrer la session d un terminal un autre terminal. L IMS permet de disposer de plusieurs sessions actives simultanment (e.g., session voix mise en garde o l appel joue l appelant une musique d attente, session voix active et session data parallle pour l change de message courts, photos, fichiers, etc.).
164
Services fournis par l IMS
Les services dans le catalogue dun oprateur peuvent tre simplement classifis de la manire suivante :
Accs large bande Internet et Intranets. Il sagit de services de connectivit qui sont fournies par le moyen de technologies daccs large bande fixe et mobile telles que xDSL, FTTx, cble, 3G+, LTE, EVDO, etc. Services de communication : Cest le domaine dexpertise dun oprateur de tlcommunication qui inclut tout type de service qui permet aux clients de communiquer tels que la tlphonie, la visiophonie, le ring back tone, le push-to-talk, le prpay, le VPN tlphonie, le SMS, le chat, la prsence, etc. Services de divertissement : Il sagit dune catgorie de services qui inclut le Broadcast TV, la vido la demande, le video streaming, les jeux multimdia en rseau, etc.
Simon ZNATY
La conception initiale dIMS a eu pour but doffrir la seconde catgorie de services. Puis lIMS a intgr la troisime catgorie, ce qui permet la cration de nouveaux services et notamment de la tlvision interactive. 165
Copyright EFORT
L IMS initialement n avait pour but d offrir que des services de communication qui correspond la catgorie de service de prdilection de tout oprateur de tlcommunication. Ces services sont par exemple ceux proposs aujourd hui par les oprateurs mobiles GSM : la tlphonie, la visiophonie (dans le cas d un client 3G ayant un terminal compatible), le customized ring back tone, la messagerie vocale, le push to talk, le prpay, le rseau priv virtuel voix, le tlphone convergent (tlphone WiFi et GSM) avec basculement de la voix sur IP la voix sur GSM ds que perte du signal WiFi mais sans perte de la communication, le SMS, etc. Mais l IMS a volu et peut maintenant aussi offrir des services dits de divertissement tels que broadcast TV, la vido la demande, le streaming vido, les jeux multimdia en rseau. L ide pour un oprateur est d offrir d abord un premier play au client, savoir l accs large bande et ensuite d autres plays tous proposs via l IMS pour ainsi rduire les cots de dveloppement, de dploiement et d exploitation des services.
165
Avantages de lIMS compar lapplication de tlphonie sur Internet

Interoprabilit Qualit de Service Roaming Interception lgale Appels durgence Modle de taxation flexible Orchestration de service Mobilit de session
Interface fournisseur de service unique
166
Simon ZNATY
Copyright EFORT
Si lon compare IMS et SKYPE IMS garantit linteroprabilit au niveau mondial entre tous les oprateurs alors que Skype ne garantit linteroprabilit quentre les lcients de la communaut Skyoe. Tous les sessions disposent dune QoS dpendant du trafic de lusager, alors que Skype sappuie sur une Qos par dfaut (Best Effort) puisque Skype nest quune application sur Internet. En situation de Roaming, le client se rattache au rseau IMS visit et dispose de la mme QoS pour ses sessions IMS quil aura obtenu avec son oprateur nominal. Tous les aspects taxation sont par ailleurs transparents pour le client car dans le cas du GSM en roaming aujourdhui. Skype est utilisable partout, mais sans QoS. Par ailleurs, le client qui souhaite utiliser Skype doit acheter un pass our accder Internet par exemple lhotel. Skype ne traite pas linterception lgale et les appels durgence alors que les oprateurs IMS le supportent puisque ces fonctionnalits ont t normalises. D ailleurs L'Arcep poursuit Skype afin qu'il assume les obligations d'un oprateur comme permettre l'interception d'appels par les services judiciaires, participer l'annuaire universel, achemnier des appels d'urgence, mettre en place la portabilit du numro... LIMS propose une architecture de taxation flexible permettant la taxation la dure, lacte, au contenu, au volume, etc, en plus des mthodes de taxation online et offline. LIMS permet la mobilit de session. Par exemple, lappel peut commencer depuis un accs WiFi/IMS et continuer sur un rseau GSM (car perte de couverture WiFi) sans perte de communication. Cela suppose que le client que lusager dispose dun terminal dual mode WiFi et GSM. Skype noffre pas une telle fonctionnalit.
166
IMS et normalisation

Normalis par le 3GPP sous la dnomination IMS dans les Releases R5 et R6 (Accs principalement 3G) Normalis par le 3GPP2 sous l appellation IMS (accs CDMA2000) Normalis par TISPAN sous la dnomination Core IMS (Accs principalement xDSL) Normalis par PacketCable sous le nom PacketCable Multimedia (Accs Cable)
La Release R7 de 3GPP a pour objectif de dfinir une architecture IMS qui soit compltement indpendante de tout type d accs appele COMMON IMS. La Release R8 de 3GPP continue de dfinir des aspects non traits tels que Operations Administration and Maintenance (OAM) et le service brokering, et se focalise sur ladaptation de lIMS aux rseaux daccs de 4me gnration.
Copyright EFORT
Simon ZNATY
167
L IMS est dfini par diffrents organismes qui ont rutilis les spcifications d origine qui proviennent du 3GPP et les ont adapt leur accs respectif. 3GPP spcifie l IMS R5 pour offrir des services non temps rel ou pseudo rels sur IP pour un accs 3G. L IMS Release 6 quant lui concerne tout type de service incluant les services temps rel tels que la voix ou la vidotlphonie sur IP pour un accs 3G. TISPAN adapte les spcifications Release 6 au cas de l accs xDSL. PacketCable adapte les spcifications Release 6 au cas de l accs Cble. 3GPP2 adapte les spcifications Release 5 au cas de l accs CDMA2000 qui reprsentent la 3G aux normes amricaines. 3GPP sera responsable d diter les spcifications d une architecture de rseau et de services IMS indpendante de tout type d accs appele IMS R7.
167
xDSL
RACS NASS
IMS indpendant de laccs : Common IMS

Rx Rx
LTE + ePC = EPS PCRF NASS
Rx Rx
Common IMS
Packet Cable
RACS NASS
...
IP Backbone
WiMAX
RACS
Simon ZNATY
NASS
Copyright EFORT
168
Chaque rseau daccs a des mthodes dattachement et de rservation des ressources spcifiques. Larchitecture Common IMS indpendante de tout accs sappuiera sur les principes de rservation des ressources qui sont eux spcifiques laccs (RACS, Ressource Admission Control Subsystem). Par ailleurs, avant de pouvoir sattacher Common IMS, il faut sattacher laccs, et la mthode dattachement sera toujours spcifique laccs.
168
4.2. Entits IMS
Simon ZNATY
Copyright EFORT
169
169
RTC ou GSM
Sig RNIS Sig analogique
RTC/GSM versus Architecture de rseau IMS (3G)

Plan de signalisation
SP
ISUP
SP
ISUP
SP
Sig RNIS Sig analogique
Fabric
Fabric
Fabric
Plan de commutation IMS

Signalisation SIP
Plan de Contrle de Session CSCF CSCF SIP GGSN

IP Network IP IPX Network
Signalisation SIP
SGSN
IP Network
Simon ZNATY
GGSN
SGSN
IP Network
170
Rseau dAccs
Plan de Commutation Rseau dAccs Copyright EFORT
Dans le RTC ou le rseau GSM qui sont des rseau voix, le commutateur implmente deux fonctions : la fonction de commutation qui utilise le transport TDM et la fonction de signalisation qui utilise le protocole ISUP/SS7 pour ltablissement et la libration dappel. ISUP est un protocole de proche en proche entre commutateurs. Un protocole de signalisation d accs est aussi utilis entre l quipement de l usager et le commutateur d accs. 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 accs 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 rle 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 libration de sessions multimdia. A la diffrence du RTC ou GSM, l IMS propose un seul protocole, SIP, pour la signalisation l accs et la signalisation rseau. Avec l IMS la fonction de commutation est prise en charge par le router. Dans le RTC , il existe des commutateurs l accs appels Class 4 Switch et des commutateurs de transit appels Class 5 Switch. Dans l IMS, il existe des routeurs d accs appels Edge Routers et des routeurs de transit appels Core Router. Les principaux fournisseurs de commutateurs voix sont ALCATEL (E10), Ericsson (AXE), Siemens (EWSD), Nortel (DMS100), Lucent (5ESS), Huawei, NEC et Fujitsu. Les principaux fournisseurs de routeurs sont Cisco et Juniper. L usager RTC est reli au premier commutateur d accs travers une liaison analogique ou RNIS. L usager IMS est reli au premier router Edge travers un accs haut dbit tel que xDSL, cble, WiMAX, UMTS, EDGE, CDMA2000, WiFi, etc.
170
RTC versus IMS (EPS et xDSL)

IMS
Signalisation SIP
UE eNodeB MME Serving GW
Plan de Contrle de Session CSCF CSCF SIP

PDN GW
Signalisation SIP
PDN GW
EPS
IP Network
Rseau IP
Rseau IPX IP
EPS
IP Network
MME eNodeB UE
Client
Plan de Commutation Plan de Contrle de Session CSCF CSCF SIP

Rseau IP Rseau IP
Serving GW
Rseau dAccs
Rseau dAccs
IMS
Signalisation SIP
Signalisation SIP
xDSL
IP Network BAS
xDSL
IPX
Rseau dAccs Simon ZNATY
Client
IP-based DSLAM
Plan de Commutation
Copyright EFORT
Rseau dAccs
171
Daprs le schma, les fonctions de lIMS sont indpendantes de laccs. Que ce soit laccs EPS (Evolved Packet System) ou laccs xDSL, les rseaux daccs large bande, sont relis au rseau IP sur lequel est connect le CSCF. Par ailleurs les rseaux IP des oprateurs sont relis entre eux par un rseau IP inter-oprateur appel IPX (IP Exchange).
171
HSS et SLF (1)

SLF HSS 1 HSS 2
Redirect Agent
UAA HSS #2 UAR Dx SIP REGISTER
I-CSCF
UAR UAA Cx
HSS : Home Subscriber Server SLF : Subscription Locator Function UAR : User Authorization Request UAA : User Authorization Answer
DIAMETER SIP
Simon ZNATY
Copyright EFORT
172
Lorsque plusieurs HSS ont t dploys dans le rseau, ni lentit I-CSCF, ni lentit S-CSCF ne connaissent le HSS contacter. Par contre, elles doivent dabord contacter le SLF (Subscription Locator Function). Linterface Dx est dfinie dans ce but, et est toujours utilise en association avec linterface Cx. Le protocole utilis sur linterface Dx sappuie sur DIAMETER. Le SLF prend le rle d agent de redirection DIAMETER. Afin dobtenir ladresse du HSS appropri, lentit I-CSCF ou lentit S-CSCF met au SLF le message Cx qui devait tre envoy au HSS. Sur rception de ladresse du HSS provenant de lentit SLF, lentit I-CSCF ou lentit S-CSCF renvoie la mme requte Cx au HSS comme montr la figure ci-dessus.
172
HSS et Proxy Agent ( partir de 3GPP Release 8) (2)

HSS 1 HSS 2
UAR
UAA Cx
UAR
I-CSCF
Proxy Agent
Cx UAA
SIP REGISTER
HSS : Home Subscriber Server UAR : User Authorization Request UAA : User Authorization Answer
DIAMETER SIP
173
SLF qui correspond un agent de redirection DIAMETER est une des options qui permet le routage des messages DIAMETER lorsquil existe plusieurs HSS. Une autre option est dutiliser un agent proxy DIAMETER. Dans ce cas, cest lagent qui dtermine le HSS destinataire du message DIAMETER et route directement ce message. Lavantage pour le CSCF est de se contenter denvoyer une seule fois son message, alors quavec lapproche SLF le mme message est envoy deux fois, une premire fois au SLF qui retourne une rponse de redirection et une seconde fois au HSS appropri.
173
PCRF : Policy & Charging Resource Function

PCRF : Policy & Charging Resource Function AGW : Access Gateway
P-CSCF
Gx et Rx sont des interfaces bases sur le protocole DIAMETER
IMS
2
SIP (call Control) Bearer Signaling Diameter (Policy Control)
Rx
PCRF Gx 3
Routeur
Backbone IP
UE
Rseau d accs large bande
4
AGW
1. Signalisation SIP 2. Signalisation Rx 3. Signalisation Gx (policy control) 4. Signalisation mdia (Bearer signaling) 174
Ltablissement et la modification de session dans lIMS implique un change de messages SIP/SDP de bout en bout. Pendant lchang, le terminal ngocie un ensemble de caractristiques mdia (e.g., les codecs). Le P-CSCF travers son PCRF (Policy & Charging Rules Function) autorise les flux IP des composants mdia choisis par le terminal en ralisant une translation des paramtres de la description SDP en des paramtres de QoS IP. Ces paramtres de QoS IP sont ensuite passs par le PCRF lAGW par le biais de linterface Gx base sur le protocole DIAMETER. LAccess Gateway est le terme gnrique du nud qui appartient au rseau daccs large et qui termine le rseau daccs large bande. Lorsque le terminal IMS met une requte SIP INVITE au P-CSCF, ce dernier met une requte Rx AAR au PCRF. Le PCRF la traduit en une requte Gx RAR et lachemine lAGW. Cette requte informe lAGW de rserver des ressources ddies entre lAGW et le terminal IMS avec la QoS approprie.
174
UE
eNodeB
Etablissement de session audio IMS partir de l accs LTE P-CSCF

S1
MME
S11
Serving GW
S5
PDN GW
Gx
PCRF
Rx
SIP INVITE (sdp1) 183 Session Progress (sdp2)

4. Create Bearer Request 5. S1-AP Bearer Setup Request (ESM Activate dedicated eps bearer context request) 6. RRC Connection Reconfiguration Request (ESM Activate dedicated eps bearer context request) 7. RRC Connection Reconfiguration Response (ESM Activate dedicated eps bearer context Accept) 8. S1-AP Bearer Setup Response (ESM Activate dedicated eps bearer context Accept) 9. Create Bearer Response 10. Create Bearer Response 11. RAA
2. RAR
1. AAR (sdp1, sdp2)
3. Create Bearer Request GTPv2-C S1-AP RRC Rx Gx SIP
12. AAA
175
Un usager initie une session tlphonique IMS en mettant une requte 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 ddi la signalisation SIP IMS. La demande INVITE (sdp1) est route par l IMS l appel. Lorsque le terminal de l appel reoit cette requte INVITE (sdp1), le terminal ne se met pas sonner et retourne une rponse 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 rseaux d accs de l appelant et de l appel auront t rserves par le PCRF. Ces ressources sont reprsentes 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 sadresse au PCRF (Policy and Charging Rules Function) afin de lui demander de rserver les ressources laccs, relatives la description SDP. Pour ce faire, le P-CSCF met une requte Rx Authenticate and Authorize Request (AAR) contenant les informations des descriptions SDP de l appelant (SDP1) et de l appel (SDP2). 2. Lentit PCRF traduit la QoS des descriptions SDPs en des paramtres QoS spcifiques laccs EPS; elle met la requte Gx Re-Authorize Request (RAR) au PDN-GW. 3. Le PDN GW initie la cration du dedicated bearer laide de la requte Create Dedicated Bearer Request (EPS Bearer QoS) indiquant la QoS requise;. Cette requte est reue par lentit Serving GW. 4. Le Serving GW relaie la requte Create Dedicated Bearer Request (EPS Bearer QoS) au MME. 5. Lentit MME demande ltablissement dun bearer daccs leNodeB laide de la requte S1-AP Bearer Setup Request (EPS Bearer QoS). 6. LeNodeB traduit la Qos demande dans le paramtre EPS Bearer QoS en une QoS correspondante sur linterface radio Radio Bearer QoS. Il notifie alors lUE la mise en place dun bearer radio. 7. LUE acquitte cet activation de bearer radio leNodeB. 8. LeNodeB acquitte lactivation du bearer au MME laide de la rponse Bearer Setup Response. LeNodeB indique si la QoS requise a pu tre alloue ou non. 9. Le MME acquiite lactivation du bearer au Serving GW par lenvoi dune rponse Create Dedicated Bearer Response. 10. Le Serving GW acquitte lactivation du bearer au PDN GW par lenvoi de la rponse Create Dedicated Bearer Response. 11. Le PDN GW retourne la rponse Re-Authorize Answer (RAA) au PCRF pour lui indique que la politique de QoS a pu tre excute avec succs. 12. Le PCRF retourne la rponse Rx Authenticate and Authorize Answer (AAA) au P-CSCF pour lui indiquer que la QoS a pu tre rserve dans le rseau daccs de lappelant. 175
Elments de rseau IMS

CSCF : Contrle de sessions (SIP, DIAMETER) PCRF : Policy and Charging Control (DIAMETER) HSS : Base de donnes des profils (DIAMETER) SLF ou Proxy Agent : Agent didentification du HSS appropri si plusieurs HSS sont prsents (DIAMETER)
Simon ZNATY
Copyright EFORT
176
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 rseau daction 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 prsents dans un rseau IMS, alors il est ncessaire de disposer dun SLF (Subscription Locator Function) ou d un proxy agent DIAMETER. Le SLF est un agent de redirection DIAMETER qui retourne au CSCF ladresse du HSS disposant du profil dun usager IMS donn. Le Proxy Agent route la requte du CSCF directement au HSS appropri. HSS, SLF et Proxy Agent doivent supporter le protocole DIAMETER.
176
Rseau Intelligent versus Architecture de service IMS

Rseau Intelligent
HSS
HLR SCP
IMS
Sh (DIAMETER)
SIP AS INAP/CAP INAP/ MAP CAP

Cx (DIAMETER)
ISC (SIP)
SSP SRP
Circuit de parole
VLR
Fabric
Mr (SIP)
S-CSCF
SRP : Specialized Resource Point SCP : Service Control Point SSP : Service Switching Point Simon HLRZNATY : Home Location Register
MRF
Copyright EFORT
MRF : Multimedia Resource Function CSCF : Call Session Control Function 177 HSS : Home Subscriber Server AS : Application Server
L architecture de service IMS de base est constitue de serveurs d application, de serveurs de mdia et de S-CSCF. Le serveur d'application SIP (SIP AS, Application Server) excute des services (e.g., Push To Talk, Prsence, Confrence, Instant messaging, IP Centrex, etc.) et peuvent influencer le droulement de la session la demande du service. Le serveur d application correspond au SCP du Rseau Intelligent. Le serveur de mdia SIP (appel dans les recommandations le MRF pour Multimedia Resource Function) tablit des confrences multimdias, joue des annonces vocales ou multimdia et collecte des informations utilisateur. Il sagit de lvolution de lentit SRP (Specialized Resource Point) dans le monde multimdia. Le serveur d appel SIP (S-CSCF, Service Call Session Control Function) joue le rle de point depuis lequel un service peut tre invoqu. Il dispose du profil de service de labonn qui lui indique les services souscrits par labonn et sous quelle condition invoquer ces services. Il correspond au SSP de larchitecture Rseau Intelligent. Les marques de service IMS appeles iFC (initial Filter Criteria) sont fournies par le HSS au S-CSCF via linterface Cx (DIAMETER) lors de lenregistrement de lusager au rseau IMS Les marques de service CAMEL appeles CSI (CAMEL Subscription Information) sont fournies par le HLR au SSP via linterface C (MAP) lors de lenregistrement de lusager au rseau mobile. Les donnes de service IMS sont obtenues par lAS SIP par interrogation du HSS via linterface Sh (DIAMETER).
177
Orchestration d invocation de service

Approche 3 Approche 1 Approche 2
SIP AS SIP AS SIP AS SIP AS SIP AS SIP AS SIP AS SIP AS = SIP AS SIP AS
Approche 4
SIP AS
A1 A2 An SCIM
SCIM
SCIM
S-CSCF
Simon ZNATY
S-CSCF
Copyright EFORT
S-CSCF
S-CSCF
178
Approach 1 : The S-CSCF directly invokes services based on service marks called Initial Filter Criteria. This approach is valid if there are few services to invoke. Approach 2 : One single filter criteria/trigger to a single application (SCIM, Service Capability Interaction Manager) that will have overall control. This application (i.e., workflow or SCIM) resides in the S-CSCF. Introducing a SCIM enables managing service interactions for complex service packages/bundles. Approach 3 : One single filter criteria/trigger to a single application (i.e., workflow or SCIM) that will have overall control. The SCIM/workflow resides in a standalone application server. The workflow then invokes services within application servers individually. Approach 4 : One single filter criteria/trigger to a single application that will have overall control. This application (i.e., workflow or SCIM) resides in an application server that also hosts all the applications to be invoked. This approach is suitable for example when an AS specialized in telephony services also hosts its own SCIM.
178
Capacits de Service IMS (Service Enablers)

HSS
Sh Sh Sh Sh Sh Sh Sh
Multimedia Telephony
Presence
GLMS
PoC
Messaging
Conferencing
VCC
+ Hosted Enterprise Services + Video sharing (Combinational services) + IP TV + SCC

Broadband Access to IMS
ISC
S-CSCF
IP
WLAN Access to IMS
2G/3G/4G Access to IMS
DSL DOCSIS Forum
PacketCable WiMAX Forum
Residential
Simon ZNATY
Enterprise
Copyright EFORT
Mobile
179
LIMS dfinit un ensemble de capacits de service : La capacit de service Multimedia Telephony permet des communications conversationnelles entre deux ou plusieurs participants. Cette capacit inclut les services complmentaires comparables ceux fournis par le domaine circuit tels que le renvoi dappel, le signal dappel, la mise en garde, le rappel automatique sur occupation, etc. La capacit de service Presence permet un usager de souscrire ltat de prsence un contact et dtre notifi chaque changement dtat de ce contact. La capacit de service Push-to-talk over Cellular (PoC, Push To Talk over Cellular) consiste utiliser son tlphone 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 rseaux de donnes. L'utilisateur slectionne 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 rseau daccs large bande mobile. La transmission de messages par ce biais introduit un dlai de latence qui n'autorise pas, en thorie, des changes vocaux en "quasi-temps rel", mais qui, en pratique, pourrait voir le service PoC utilis plutt pour des services de type "messagerie instantane vocale". La capacit de service Conference fonctionne selon deux modes: Le mode Ad-hoc qui permet de crer des confrences la demande. Il sagit de confrences non planifies et de courte dure. Le mode pre-arranged (Plannifi) qui permet de crer des confrence lavance en utilisant le protocole Conference Policy Control Protocol (CPCP). Il spcifie un schma XML qui numre les lments d information de politique de confrence permettant l usager de dfinir sa politique de confrence. La capacit de service Messaging fonctionne selon deux modes : Pager-mode messaging : Des messages SIP contenant les donnes changer son routs de manire asynchrone entre lmetteur et le rcepteur. Session-mode messaging : Une session IMS est tablie pour la session de donne (de type Tchat). Le protocole MSRP est alors utilis pour transporter les donnes entre usagers et non pas le protocole SIP. Les capacits de service Hosted Enterprise Services (IP Centrex), IP TV (Mode broadcast et mode video la demande), video sharing, on aussi t rcemment dfinies.
179
Interfonctionnement RTC ou GSM IMS

S-CSCF MGCF
SIP ISUP/ SIGTRAN SIP MEGACO
SIP UA
T-SGW
ISUP/SS7
IMS-MGW xDSL
Flux RTP Circuit de parole
IP Commutateur RTC
IMS-MGW : IMS Media Gateway 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
180
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 prsente un plan de contrle (signalisation) et un plan d'usager (transport). Dans le plan usager, des entits passerelles (IMS-MGW, IMS - Media Gateway Function) sont requises afin de convertir des flux RTP en flux TDM. Ces passerelles ne traitent que le mdia. Des entits sont responsables de crer, maintenir et librer des connexions dans ces passerelles; il s'agit de contrleurs de passerelles (MGCF, Media Gateway Control Function). Par ailleurs, ce mme MGC termine la signalisation ISUP du ct RTC/GSM qu'il convertit en signalisation SIP qui est dlivre au domaine IMS. Les messages ISUP provenant du RTC/GSM sont d'abord achemins 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 entits : L'IMS-MGW (IP Multimedia Subsystem Media Gateway Function), MGCF (Media Gateway Control Function) et T-SGW (Trunking Signalling Gateway Function).
180
BGCF : Breakout Gateway Control Function

S-CSCF
SIP SIP
BGCF MGCF
SIP
MGCF
MEGACO
MEGACO
Rseau IP RTC
Copyright EFORT
Interface RTC Interface RTP / UDP / IP

Simon ZNATY
181
Lorsque le S-CSCF dcouvre que la session doit tre route vers le domaine de commutation de circuit (CS, Circuit Switched Domain) il utilise linterface Mi (protocole SIP) afin de relayer la session au BGCF. Linterface Mi est supporte par le protocole SIP. Lentit Breakout Gateway Control Function (BGCF) est responsable de la slection de la localisation pour linterfonctionnement avec le domaine CS. Le rsultat du processus de slection peut tre un interfonctionnement dans le mme rseau que celui contenant le BGCF ou un autre rseau auquel cas le BGCF route le message SIP au BGCF de lautre rseau. Si linterfonctionnement a lieu dans le mme rseau, alors lentit BGCF slectionne une entit Media Gateway Control Function (MGCF) qui traitera la session. Les rgles de slection de lentit BGCF ne sont pas spcifies. Par ailleurs, lentit BGCF peut rapporter des informations de taxation (MGCF-CDR) et des statistiques.
181
BGCF : Breakout Gateway Control Function

S-CSCF
SIP
BGCF
SIP
BGCF MGCF
SIP ISUP
MEGACO
Rseau IP Rseau IP IPX RTC

Copyright EFORT
Interface RTC Interface RTP / UDP / IP

Simon ZNATY
182
182
Taxation Off-line
Systme de Facturation BSS Business Support System
Systme de Mdiation (Taxation)
OSS Operation Support System
CCF Rf (Diameter)
x-CSCF, MGCF, BGCF, AS, MRF
Simon ZNATY
Architecture de Rseau et de Service IMS

Interface propritaire CCF : Charge Collection Function
Entits IMS
Copyright EFORT
183
Le point central de larchitecture de taxation off-line IMS est lentit Charging Collection Function (CCF). Elle reoit les informations de taxation des entits IMS, les traite, puis construit et formate les CDRs (Call Detail Records). Les CDRs sont passs au systme de mdiation qui les corrle pour produire un CDR qui est soumis au systme de facturation qui se charge de produire le billing record. Lorsque lusager en en roaming, deux CCFs seront alors impliqus.
183
Taxation On-line
OSS
Account Balance Management System Rating System
Architecture de Rseau et de Service IMS

Interface propritaire OCS : Online Charging System
Rc (Diameter)
Taxation au volume, Taxation la session (dure), Taxation l vnement
Re (Diameter) OCS Gy (Diameter) Ro
Ro (Diameter) AS
Ro (Diameter) CAP DIAMETER AS = Translation Agent IMS-GWF

ISC = SIP S-CSCF
GGSN
Ge (CAP)
SSP
Copyright EFORT
Simon ZNATY
184
La taxation on-line reprsente la taxation des usagers prpays. Le S-CSCF, l AS et le MRFC sont les entits IMS capable de raliser la taxation on-line. LAS et le MRFC utilisent linterface Ro alors que l entit S-CSCF utilise l interface ISC pour la communication avec le systme de taxation on-line (OCS, Online Charging System).
184
Caractristiques IMS

Connectivit IP Indpendance par rapport laccs Garantie de QoS pour les services multimdia IP Exerce un contrle de politique pour sassurer de lusage appropri des ressources mdia Communications scurises Taxation Support du roaming (itinrance) Interfonctionnement avec dautres rseaux (RTC, GSM, Internet) Contrle de service Dveloppement de Service
Simon ZNATY
Copyright EFORT
185
Connectivit IP : Le client devra disposer de la connectivit IP pour accder aux services IMS. Mme si le protocole IPv6 n est pas requis, long terme La raison fondamentale qui justifiera l'usage d'Ipv6 est l'insuffisance d'adresse Ipv4 pour permettre chaque mobile (si lon considre lapplication de lIMS aux rseaux mobiles) de disposer d'une adresse IP avec un mode "accs permanent". Des solutions comme la traduction dadresse rseau (NAT, Network Address Translation) ne peuvent tre que temporaires. De nouveaux services comme laccs permanent, le tlchargement systmatique, lauto-configuration, les applications en temps rel (tlphonie), la scurit, etc. dpasseront bientt les possibilits de la technologie NAT. Indpendance par rapport laccs : LIMS a t conu pour tre indpendant de laccs afin que les services IMS puissent tre fournis partir de nimporte quel type daccs connect un rseau IP (e.g., 3G+, WLAN, xDSL, cble, WiMAX, LTE, etc). Garantie Qos des services multimdia : Sur Internet, le type de QoS fourni est best effort. Cela ne sera pas le cas avec lIMS. Les rseaux daccs et de transport de lIMS fournissent la QoS de bout-en-bout. A travers lIMS, le terminal ngocie ses capacits et exprime ses exigences de QoS durant la phase dtablissement de la session avec le protocole SIP. En parallle le terminal rserve les ressources ncessaires dans le rseau daccs en utilisant un protocole de rseau de ressources (e.g., RSVP, SM/GTP, etc). Contrle de politique : Le contrle de politique IP signifie la capacit dautoriser et de contrler lusage du trafic au niveau mdia dans lIMS sur la base des paramtres de la signalisation SIP change lors de ltablissement de la session. Cela requiert des interactions entre le rseau daccs et lIMS laide du protocole DIAMETER. Communications scurises : LIMS fournit des mcanismes de scurit similaires ceux mis en place dans les rseaux GSM et GPRS. Par exemple, lIMS sassure que lusager a t authentifi avant de pouvoir utiliser ses services. Tous les flux SIP changs entre l usager et le rseau IMS sont chiffrs avec protection de leur intgrit et empruntent un tunnel IPSec. Taxation : LIMS fournit diffrents modles de taxation : off-line (gnration de ticket la fin de l appel) et on-line (dcrmentation du crdit de l usager en temps rel). Support du roaming : Lusager peut accder ses services IMS depuis nimporte quel rseau IMS visit. Inferfonctionnement avec dautre rseaux : LIMS ne sera pas dploy partout au mme moment. Il est donc ncessaire de prvoir des passerelles entre les rseaux RTC/GSM et le rseau IMS. Ces passerelles de mdia (media gateways) sont contrles par des softswitchs. LIMS identifie aussi un signaling gateway permettant de dlivrer la signalisation ISUP du RTC/GSM au softswitch sur SIGTRAN. L IMS assure aussi l interfonctionnement avec les solution de voix sur Internet telles que Skype, MSN, etc. Contrle de service : LIMS fournit tous les lments permettant de connatre les services souscrits par labonn et de les invoquer pour toute session sortante ou entrante. Dveloppement de service : LIMS fournit les capacits de service permettant le dveloppement de services multimdia. Parmi les capacits de service dj considres figurent la prsence, la messagerie, le push to talk, la confrence, le partage de vido, etc. 185
Client
ONT
IMS : Une Architecture Indpendante RACS0 de lAccs Fiber FTTH Fiber OLT
SLF
Coupler
AS
Client
DSLAM xDSL
IP xDSL Backbone BAS MME
RACS1
SIP
HSS
Diameter
BGCF
SIP
IMS
MGCF SGW
UE eNodeB
EPS
PCRF2 PDN GW
PCRF3
SIP
IP Network
Serving GW UE Node B RNC SGSN 3G
S-CSCF
SIP
ISUP
GGSN PCRF4
HA
ATM
MS BTS BSC
IP Network
IP Network
MRF P-CSCF
ISUP RTP MEGACO/ H.248
CDMA2000
PDSN
IP Network
WLAN WLAN Access Network

Client
CM
PCRF5 PDG
Router
CMTS HFC, Hybrid Fiber Coaxial BS
CABLE
RACS6 HES RACS7
BGF
IP Backbone
IMS-MGW
MS
PSTN
WiMAX ASN-GW PSTN access
BGF IPX
MSAN
Copyright EFORT
Simon ZNATY
Analog/ISDN
186
Chaque rseau daccs a sa propre mthode dattachement et de rservation de ressources. Larchitecture Common IMS qui a pour objectif lindpendance par rapport laccs sappuie sur les accs spcifiques mais dispose dune interface normalise pour demander les services de nimporte quel type daccs. Le diagramme ne montre pas tous les accs possibles. Il n est donc pas exhaustif.
AS : Application Server ASN-GW : Access Service Network Gateway ATM : Asynchronous Transfer Mode BAS : Broadband Access Server BGF : Border Gateway Function BSC : Base Station Controller BTS : Base Transceiver Station CDMA : Code Division Multiple Access CSCF : Call Session Control Function CS-MGW : Circuit Switched Media Gateway DSL : Digital Subscriber Line DSLAM: DSL Access Multiplexer EPS : Evolved Packet system GGSN : Gateway GPRS Support Node GW : Gateway HA : Home Agent HFC : Hybrid Fiber Coaxial HSS : Home Subscriber Server IMS : IP Multimedia Subsystem ISDN : Integrated Services Digital Network LMDS : Local Multipoint Distribution Service MME : Mobility Management Entity
MGCF : Media Gateway Control Function MRF : Multimedia Resource Function MSAN : Multi-Service Access Npde MS : Mobile Station PCRF : Policy & Charging Rules Function PDF : Policy Decision Function PDG : Packet Data Gateway PDN : Packet Data Network PDSN : Packet Data Serving Network RACS : Resource Admission Control Subsystem RNC : Radio Network Controller SGSN : Serving GPRS Support Node SGW : Signaling Gateway UE : User Equipment UMTS : Universal Mobile Telecommunications System WLAN : Wireless Local Area Network
186
Introduction SIP

SIP (Session Initiation Protocol), IETF RFC 3261 (06/2002). SIP est un protocole de signalisation utilis pour l tablissement, la modification et la libration de sessions audio/vido/data. SIP s appuie sur le protocole SDP (Session Description Protocol) pour dcrire la configuration de la session, RTP pour le transfert de la voix et de la vido, RTCP pour le contrle des changes RTP, et MSRP pour l change de donnes dans le contexte de session. SIP rutilise certains aspects des protocoles HTTP (conception selon le modle client/server, adressage par URL, codes de rponse) et SMTP (headers et transfert ascii). SIP dfinit une architecture de service avec les entits suivantes : Serveur dApplication SIP, Serveur de Media SIP, SMTP : Simple Mail Transport Protocol Serveur de Messagerie SIP. HTTP : Hyper Text Transport Protocol
Copyright EFORT
Simon ZNATY
SDP : Session Description Protocol RTP : Real-Time Transport Protocol
187
SIP est un protocole de signalisation dfini par lIETF (Internet Engineering Task Force, RFC 3261, Juin 2002) permettant ltablissement, la libration et la modification de sessions multimdia. Il hrite de certaines fonctionnalits 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 sappuie sur un modle transactionnel client/serveur comme HTTP. Ladressage utilise le concept dURL SIP (Uniform Resource Locator) qui ressemble une adresse E-mail. Chaque participant dans un rseau SIP est donc adressable par une URL SIP. Par ailleurs, les requtes SIP sont acquittes par des rponses identifies par un code numrique. Dailleurs, la plupart des codes de rponses SIP ont t emprunts au protocole HTTP. Par exemple, lorsque le destinataire nest pas trouv, un code de rponse 404 Not Found est retourn. Une requte SIP est constitue de headers comme une commande SMTP. Enfin SIP comme SMTP est un protocole textuel.
187
Mthodes SIP
6 Mthodes SIP (RFC 3261; Juin 2002):

INVITE : Initialiser une session ACK : Confirme la rponse un message INVITE BYE : Termine une session OPTIONS : Communique les lments supports CANCEL : Annule une requte en cours REGISTER : Enregistre un client avec un service de localisation
Simon ZNATY
Copyright EFORT
188
La mthode INVITE est utilise afin dtablir une session entre User agents. INVITE correspond au message ISUP IAM ou au message Q.931 SETUP et contient les informations sur lappelant et lappel et sur le type de flux qui seront changs (voix, vido, etc.). Lorsque le User agent ayant mis la mthode SIP INVITE reoit une rponse finale linvitation, il confirme la rception de cette rponse par une mthode ACK. Une rponse telle que busy ou answer est considre comme finale alors quune rponse telle que ringing signifiant que lappel est alert, est une rponse provisoire. La mthode BYE permet la libration dune session pralablement tablie. Elle correspond au message RELEASE des protocoles ISUP et Q.931. Un message BYE peut tre mis par lappelant ou lappel. La mthode REGISTER est utilise par un User agent afin dindiquer au Registrar son adresse IP ainsi que son adresse SIP (SIP URL). Ainsi le Registrar connat la localisation de lutilisateur. Comme dans le cas du Gatekeeper, le User agent peut connatre par avance son Registrar (adresse IP du Registrar prconfigure dans le User agent) auquel cas il met une mthode REGISTER uniquement ce Registrar. Sinon, le User agent met le message tous les Registrars en utilisant ladresse multicast (224.0.1.175). La mthode CANCEL est utilise afin de mettre fin des requtes en cours. Si un User agent senregistre auprs de plusieurs terminaux, un message INVITE envoy ce User agent sera dupliqu et relay lensemble de ces terminaux. Lorsque lutilisateur accepte lappel sur un des terminaux, une mthode CANCEL est mise vers les autres terminaux afin dannuler les requtes INVITE en cours. La mthode OPTIONS est utilise afin dinterroger les capacits et ltat dun User agent ou dun serveur. La rponse contient ses capacits (e.g., type de mdia tant support) ou le fait que le User agent soit indisponible.
188
Mthodes SIP
UAC OPTIONS UAC 200 OK INVITE UAC 180 RINGING 200 OK ACK
HSS
CSCF OPTIONS 200 OK UAS
REGISTER
200 OK CSCF
CSCF INVITE 180 RINGING 200 OK ACK CSCF BYE 200 OK CSCF UAS
UAS
UAC
BYE 200 OK CANCEL 200 OK

Copyright EFORT
CANCEL 200 OK UAS

189
UAC
Simon ZNATY
189
Etablissement d une session audio

Proxy Server francetelecom.com sip:mary.taylor@francetelecom.com
SIP UA 1
sip:mark.rich@francetelecom.com
SIP UA 2
v = 0 (dans message 1) c = IN IP4 192.23.34.45 m = audio 45450 RTP/AVP 0, 4, 15
1. INVITE 4. 180 RINGING 6. 200 OK 7. ACK

v=0 (dans message 5) c = IN IP4 192.190.130.38 m = audio 22222 RTP/AVP 0
Flux de mdia RTP

v=version c=connection m=media
9. BYE 12. 200 OK
10. BYE 11. 200 OK

Copyright EFORT
Simon ZNATY
190
Dans lexemple 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 diffrents headers obligatoires dont l'adresse SIP de l'appelant "From", l'adresse SIP de l'appel "To", un identifiant d'appel "Call-ID", un numro de squence "Cseq". Par ailleurs, le message SIP contient une syntaxe SDP (Session Description Protocol). Cette structure consiste en plusieurs lignes qui dcrivent les caractristiques du mdia que lappelant Mary requiert pour lappel. Mary Taylor indique qu'il s'agit d'une session tlphonique (m=audio), que la voix paqutise doit lui tre dlivre l'adresse de transport (port UDP = 45450, adresse IP = 192.23.34.45) avec le protocole RTP et en utilisant un format d'encodage dfini dans le RFC AVP (Audio Video Profile) et pouvant tre G.711 -law (0), G.729 (4) et G.728 (15). La rponse 180 RINGING est retourne par le destinataire au terminal IMS de l appelant. Lorsque l'appel accepte la session, la rponse 200 OK est mise par son terminal IMS et achemine au terminal IMS de l appelant. Le terminal IMS de l appelant retourne une mthode ACK au destinataire, relaye 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 vido paqutise sans implication du Proxy Server dans ce transport. Lorsque Mary raccroche, son terminal IMS envoie une requte BYE pour terminer la session. Cette requte est dlivre au Proxy Server qui l'achemine au terminal IMS de Mark. Ce dernier retourne la rponse 200 OK suivante.
190
Etablissement d une session audio/vido Proxy Server

francetelecom.com sip:mary.taylor@francetelecom.com
SIP UA 1
SIP UA 2
v = 0 (dans message 1) c = IN IP4 192.23.34.45 m = audio 45450 RTP/AVP 0, 4, 15 m = video 45452 RTP/AVP 31

v=0 (dans message 5) c = IN IP4 192.190.130.38 m = audio 22222 RTP/AVP 0 m = video 22224 RTP/AVP 31
Flux de mdia RTP

v=version c=connection m=media
9. BYE 12. 200 OK
10. BYE 11. 200 OK

Copyright EFORT
Simon ZNATY
191
Mary Taylor indique qu'il s'agit d'une session visiophonie (deux lignes m=audio et m= video sont prsentes), La voix paqutise doit lui tre dlivre l'adresse de transport (port UDP = 45450, adresse IP = 192.23.34.45) avec le protocole RTP et en utilisant un format d'encodage dfini dans le RFC AVP (Audio Video Profile) et pouvant tre G.711 -law (0), G.729 (4) et G.728 (15). La vido (visio) paqutise doit lui tre dlivre l'adresse de transport (port UDP = 45452, adresse IP = 192.23.34.45) avec le protocole RTP et en utilisant un format d'encodage dfini dans le RFC AVP (Audio Video Profile) et pouvant tre H.261. Le terminal de Mary Taylor se chargera de raliser l opration de mixage des flux audio et vido. La rponse 180 RINGING est retourne par le destinataire au terminal IMS de l appelant. Lorsque l'appel accepte la session, la rponse 200 OK est mise par son terminal IMS et achemine au terminal IMS de l appelant. Le terminal IMS de l appelant retourne une mthode ACK au destinataire, relaye par l'entit CSCF.
191
Etablissement dune session de donnes SIP Proxy Server

francetelecom.com sip:mary.taylor@francetelecomcom
SIP UA 1
SIP UA 2
1. INVITE sdp1 4. 200 OK 5. ACK
2. INVITE 3. 200 OK sdp2 6. ACK
Etablissement d une connexion TCP

Echange de messages MSRP
v = 0 (in message 1) c = IN IP4 192.23.34.45 m = message 7300 tcp/msrp * a = accept-types: text/plain text/html a = path:msrp://192.23.34.45:7300/mary_taylor;tcp
Simon ZNATY
v = 0 (in message 3) c = IN IP4 192.190.130.38 m = message 8400 tcp/msrp * a = accept-types: text/plain a = path:msrp://192.190.130.38:8400/mark_rich;tcp
Copyright EFORT
192
In order to describe an MSRP session using SDP, two new mandatory media level attributes are defined: path : This attribute always accompanies an MSRP media line. It indicates the MSRP URI of the user agent that sent this session description. An MSRP URI represents the end user address where he or she expects to receive incoming instant messages. An MSRP URI has the form: msrp://host:port/session_id;transport accept-types : This is also a mandatory attribute that accompanies an m-line. It indicates the media types that are acceptable to the endpoint. It may indicate wrapper types (e.g., message/cpim) or simple types (e.g., text/plain). In addition to these new attributes, the connection and media line in an SDP message describing an MSRP session have the following requirements: c-line : The address in this line must coincide with the IP address indicated in the path attribute. m-line The protocol parameter is tcp/msrp. The media field must be message. In order to further qualify the media type, the accept-types attribute is used. The port parameter must match the port value used in the MSRP URI in the path attribute. An endpoint may indicate the maximum size message it wishes to receive using the max-size a-line attribute.
192
4.3. Enregistrement et Etablissement de Session IMS
Simon ZNATY
Copyright EFORT
193
193
Types de CSCF
S-CSCF I-CSCF
SP Rseau Visit 1 VLR SSP SP Rseau Nominal 1
HSS
P-CSCF
Rseau IP SP
Accs large bande Simon ZNATY
Rseau IP
Copyright EFORT
IPX
194
194
Information de localisation
S-CSCF
Public URIs Adresse IP P-CSCF Public URIs Adresse IP terminal
Rseau Nominal 1
HSS
Rseau Visit 1
P-CSCF
Rseau IP
Public URIs Adresse IP S-CSCF
Broadband Access
Simon ZNATY
Rseau IP
Copyright EFORT
IPX
195
Lorsque lusager senregistre, il inclut dans la requte SIP REGISTER son adresse publique (adresse SIP, e.g., sip :JohnCook@orange.fr) et son adresse prive (JohnCook_private@orange.fr); son terminal rajoute son adresse IP. Lorsque le P-CSCF reoit la requte REGISTER, il y rajoute son adresse IP et relaye la requte REGISTER au rseau nominal travers un point dentre appel le I-CSCF. Le I-CSCF aprs avoir interroger le HSS identifie un S-CSCF capable de prendre en charge lusager, et route la requte SIP REGISTER ce S-CSCF. Le S-CSCF stocke dans sa base de donnes la correspondance entre ladresse publique de lusager (adresse SIP), ladresse IP du terminal de lusager et ladresse IP du P-CSCF qui prend.en charge lusager. Le S-CSCF interagit avec le HSS afin dobtenir le profil de lusager et afin de mettre jour dans le HSS ladresse IP du S-CSCF qui prend en charge lusager. Le HSS associe dans le profil de lusager ladresse public SIP de lusager et ladresse IP de son S-CSCF.
195
Types de CSCF
L entit CSCF a trois rles possibles :

P-CSCF (Proxy CSCF), I-CSCF (Interrogating CSCF) S-CSCF (Serving-CSCF).
Le Proxy-CSCF (P-CSCF) est le premier point de contact dans le domaine IMS. L'Interrogating-CSCF (I-CSCF) est le point de contact au sein d'un rseau d'oprateur pour toutes les sessions destines un utilisateur de cet oprateur. Le Serving-CSCF (S-CSCF) prend en charge le contrle de la session. Il maintient un tat de session afin de pouvoir invoquer des services.
Simon ZNATY
Copyright EFORT
196
196
Enregistrement IMS
Avant de pouvoir utiliser les services du domaine IM, tels qu'tablir une session multimdia ou recevoir une demande de session, un usager doit s'enregistrer l IMS. Que l'usager soit dans son rseau nominal ou dans un rseau visit, cette procdure fait intervenir un P-CSCF. Grce l'enregistrement SIP :
Le HSS est notifi de la localisation courante de l'UE par rapport au domaine IMS et met jour le profil de l'usager correspondant, L'usager est authentifi avant de pouvoir accder aux services du domaine IM, Le domaine IMS nominal de l'usager slectionne un S-CSCF appropri qui invoquera les services de l'UE auprs de serveurs d'application, et ce, grce au profil de l'usager retourn par le HSS au S-CSCF slectionn (i.e., ASSI). Le S-CSCF peut tre assimil l'entit SSP de l'architecture du Rseau Intelligent.
Copyright EFORT
Simon ZNATY
197
197
Identifications : Exemple 1 Private User Identity, e.g.,

Souscription IMS
208019999999999@orange.fr (si ISIM prsent) ou 208019999999999@ims.mnc01.mcc208.3gppnetwork.org Public user identity-7 sip:JohnCook_G@orange.fr Public user identity-6 tel : +336 72 22 44 56 Public user identity-5 sip : JohnCook_P@orange.fr Public user identity-4 tel : +336 72 22 44 57 Public user identity-3 sip : JohnCook_F@orange.fr Public user identity-2 tel : +336 72 22 55 55 Public user identity-1 sip:JohnCook@orange.fr Service profile-4
Private user identity-1
Service profile-3
Service profile-2
Service profile-1
Simon ZNATY
Copyright EFORT
198
Les requtes et rponses 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 cest dire user@host. Toutefois, une adresse e-mail utilise une URL mailto (mailto :mark.rich@orange.fr) alors quune adresse SIP a la forme dune URL SIP (sip :mark.rich@orange.Fr). La partie user est identifie soit par un nom, soit par un numro de tlphone. La partie host est reprsente soit un par nom de domaine, soit par une adresse de rseau. Lutilisation des numros de tlphone est aussi considre, notamment pour la rutilisation du plan de numrotage du rseau tlphonique commut (RTC) et pour linterfonctionnement entre SIP et RTC. Lorsqu un appelant du RTC ou du rseau GSM veut appeler un destinataire sur le rseau SIP/IMS, il n a pas d autre solution que de composer un numro de tlphone. Ce numro qui appartient au plan de numrotage de SIP/IMS sera traduit par ENUM/DNS en adresse SIP. ENUM contient pour tout numero de telephone d un client SIP une adresse tlphonique associe une adresse SIP. Il ne peut pas y avoir d adresse tlphonique assigne (tel:) sans adresse SIP associe. Donc dans le monde SIP, l usager SIP/IMS devra disposer d une adresse SIP et d une adresse tlphonique (e.g., tel:+33672333333). Ses appels lui seront achemins exclusivement avec son adresse SIP (e.g., sip: x.y@orange.fr). Lorsque l usager SIP souhaitera appeler un client du RTC, il composera tel: pour indiquer l adresse du destinataire dans le header To de la mthode INVITE du protocole SIP. John Cook veut appartenir diffrentes communauts : Communaut par dfaut, communaut famille, communaut professionnelle et communaut jeux. Pour chaque communaut lexception de la communaut jeux, il peut recevoir des sessions dappelants SIP/IMS, RTC ou GSM. Un appelant rattach un rseau RTC ou GSM ne peut que composer un numro de tlphone pour appeler John Cook. Un appelant reli au rseau SIP/IMS a le choix entre composer une adresse SIP (sip:) ou une adresse tlphonique (tel:). Cest la raison pour laquelle John Cook dispose de deux adresses publiques pour les communauts famille, professionnelle, et dfaut. Un profil de service est associ chaque communaut et consiste en les adresses publiques de la communaut et en un ensemble de marques de services. Les sessions de jeux pourront tre considres comme une session de messagerie SIP. Les commandes de jeux seront transportes dans des messages MSRP. Afin quun utilisateur Skype puisse appeler John Cook, le fournisseur de service IMS orange.fr doit configurer Skype ou equivalent tel que MSN, GoogleTalk, Messenger comme une identit de service publique. Il existe donc les PUI (Public User Identities) telles que sip: et tel: et les PSI (Public Service Identities telles que celles de Skype. John Cook sera visible par le domaine Skype comme tant identifi par JohnCook1005@skype.com.
198
Ids IMS : Private Id (1)
La rfrence une souscription IMS est dfinie par un compte usager. La souscription IMS peut tre utilise depuis n importe quel quipement appel UE, pour des communications fixes ou mobiles. Un usager doit avoir au moins une identit prive et au moins une identit publique. L identit prive IMS (IMSI Private User Identity, IMPI) est une donne usager permanente dans le HSS. Le format de l IMPI est de type username@realm de Network Address Identifier (NAI) tel que spcifi dans le RFC IETF 4282. L IMSI peut tre inclus dans la partie username si souhait par l oprateur; le format de la partie realm est : ims.mnc[MNC].mcc[MCC].3gppnetwork.org Si l IMSI suivant est utilis, 208019999999999, alors IMPI = 208019999999999@ims.mnc001.mcc208.3gppnetwork.org autre IMPI possible: 208019999999999@orange.fr La Private User Identity n est pas une URI SIP.
Copyright EFORT
Simon ZNATY
199
Lidentit prive dusager IMS (IMS Private User Identity, IMPI) est une identit globale unique dfinie par le rseau nominal qui peut tre utilise dans le rseau nominal afin didentifier de manire unique une souscription. Cette identit est principalement utilise afin dauthentifier lusager. Elle sert aussi aux procdures administratives et aux procdures de taxation. Larchitecture IMS impose les caractristiques suivantes pour lidentit prive IMS : LIMPI a un format Network Access Identifier (NAI). LIMPI sera contenu dans dans les demandes denregistrement passes de lUE au rseau nominal. LIMPI sera authentifie uniquement lors de lenregistrement de lusager. LIMPI ne sera pas utilise pour le routage des messages SIP. LIMPI sera allou lusager de manire permanente. Elle sera valide pour la dure de souscription dans le rseau nominal. Il ne sera pas possible pour lUE modifier lIMPI. Le HSS devra stocker lIMPI.. LIMPI pourra tre prsent dans les tickets de taxation en fonction de la politique oprateur.
199
Ids IMS : Public Id (2)
Lidentit publique dusager (IMS Public User Identity, IMPU) est un nom de contact publi ou un numro avec lequel adresser lusager. Plusieurs IMPUs peuvent exister par souscription IMS par exemple, un numro de tlphone et une adresse URI. Loprateur de rseau IMS nominal assigne les identits IMPU. Ces IDs sont des donnes permanentes de lusager stockes dans le HSS. Des IMPUs peuvent tre partags par diffrents IMPIs avec la mme souscription IMS. Une identit IMPU donne peut tre enregistre simultanment sur diffrents UEs qui utilisent des IMPIs diffrents. Un service externe est identifi par une identit de service publique IMS (IMS Public Service Identity, PSI). Ces IDs sont des donnes permanentes de lusager stockes dans le HSS.
Copyright EFORT
Simon ZNATY
200
Les identits dusager dans les rseaux IMS sont appeles IMPU (IMS public user identities). Elles sont utilises pour la demande de communication avec dautres usagers. Les identits publiques peuvent tre publies (e.g., dans des annuaires, sur des sites WEB, sur des cartes de visites). Les usagers IMS peuvent initier et recevoir des sessions partir de diffrents rseaux, tels que rseaux GSM et IP. Pour tre joignable depuis le rseau circuit, ladresse publique doit tre conforme au plan de numrotage tlphonique (e.g., +33612131415). De la mme faon, pour des demandes dappel avec des clients IP, ladresse publique doit tre conforme au nommage Internet (e.g., john.cook@orange.fr). Larchitecture IMS impose les caractristiques suivantes pour une adresse public dusager (IMPU) [3GPP TS 23.228, TS 23.003] : Le format de lIMPU est soit une SIP Uniform Resource Identifier (URI) ou une telephone Uniform Resource Locator (tel URL). Il ne sera pas possible pour un UE donn de modifier l IMPU. Une IMPU sera enregistre avant que cette identit puisse tre utilise pour tablir ou recevoir des sessions IMS. Il sera possible denregistrer plusieurs IMPUs travers une seule requte de lUE.
200
Enregistrement de l usager sans ISIM mais avec USIM (1)

Une adresse prive temporaire et une adresse publique temporaire ont le format : username@realm. L IMSI doit tre inclus dans la partie username; le format de la partie realm est : ims.mnc[MNC].mcc[MCC].3gppnetwork.org Ex : IMSI = 208019999999999, o MCC = 208, MNC = 01, et MSIN = 9999999999. L identit prive est alors : 208019999999999@ims.mnc001.mcc208.3gppnetwork.org L identit publique temporaire est identique une adresse prive temporaire mais prfixe par sip: car il s agit d une URI SIP. Dans notre exemple sa valeur est : sip : 208019999999999@ims.mnc001.mcc208.3gppnetwork.org
Simon ZNATY
Copyright EFORT
201
Si le terminal de l usager possde une carte USIM mais sans module ISIM par exemple parce que la carte a t acquise par l usager avant que les services IMS sont proposs par l oprateur, l usager peut toutefois s enregistrer l IMS mais certains problmes se prsent alors. Premier problme : le terminal IMS n est pas en mesure de driver l identit prive de l usager (IMS Privite User Identity, IMPI), l identit publique de l usager (IMS Public User Identity, IMPU) et le nom de domaine du rseau nominal afin d adresser la requte SIP, car tous ces paramtres sont stocks dans l ISIM et non pas dans l USIM. Toutefois, un terminal IMS peut accder l USIM. L IMSI prsent dans l USIMassign par l oprateur nominal identifie de manire unique l usager mobile et inclut l identit du pays et de son oprateur dans ce pays. Lorsqu un terminal IMS contient une USIM sans ISIM, le terminal extrait l IMSI afin de crer une identit prive temporaire, une identit publique temporaire et le nom de domaine du rseau nominal et ainsi gnrer une requte REGISTER qui sera route au rseau nominal. Ces trois paramtres sont uniquement utiliss pour les procdures d enregistrement, de dsenregistrement et de r-enregistrement. Lorsque l usager est enregistr, le S-CSCF renvoie l ensemble des identits publiques alloues l usager. Le terminal IMS utilise uniquement ces identits pour tout message SIP autre que REGISTER. Les identits temporaires ne sont donc jamais utiliss en dehors du rseau nominal. L identit prive temporaire et l identit publique temporaire ont un format explicit ci-dessus.
201
Enregistrement de l usager sans ISIM mais avec USIM (2)
Simon ZNATY
Lorsqu un terminal IMS disposant d une USIM sans ISIM doit construire le nom de domaine de son rseau nominal qui est inclus dans le Request-URI de la requte SIP REGISTER, le terminal supprime la partie user de l identit publique temporaire. L URI du nom de domaine du rseau nominal est : sip: ims.mnc001.mcc208.3gppnetwork.org Dans ce cas particulier, lorsque l usager s enregistre, l authentification sera base sur l AKA 3G et non pas l AKA IMS. Si le second REGISTER de l usager fournit un rsultat d authentification XRES correct (issu de l AKA 3G), alors le S-CSCF recontacte le HSS pour obtenir le profil de l usager. Une partie de ce profil contient les identits publiques de l usager. Le S-CSCF retourne ces identits publiques dans le header P-Associated-URI de la rponse 200 OK. Une fois la procdure d enregistrement finalise, le terminal IMS dispose d un ensemble d identits publiques d usager pour par exemple tablir des sessions IMS. 202
Copyright EFORT
202
Enregistrement de lUE lIMS

Rseau Visit
UE P-CSCF
Rseau Nominal
I-CSCF HSS S-CSCF
1. Register
SIP DIAMETER
2. Register 3. UAR 4. UAA 5. Register 6. MAR 7. MAA 8. 401 Unauthorized
Joue le rle de registrar
9. 401 Unauthorized 10. 401 Unauthorized 11. Register 12. Register

Jouent le rle de Proxy Server
13. UAR 14. UAA 15. Register 19. 200 OK 16. SAR 17. SAA 18. Service Control
21. 200 OK 20. 200 OK

Simon ZNATY
Copyright EFORT
203
1.Un message SIP REGISTER est mis par l'UE au P-CSCF. 2.Le P-CSCF le relaye l'entit I-CSCF du rseau nominal de l'usager s'enregistrant. Le rseau 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 rsolu par le DNS en une adresse IP d'une entit I-CSCF du domaine IMS nominal. L'entit I-CSCF joue le rle de point d'entre pour les messages de signalisation SIP provenant d'autres rseaux. 3.L'entit I-CSCF interroge le HSS (Home Subscriber Server) travers l'interface Cx supporte par le protocole DIAMETER (Requte UAR : User Authorization Request). Le HSS est le HLR avec de nouvelles capacits pour supporter le domaine IMS. Le HSS est indpendant de l'accs de telle sorte que des oprateurs peuvent rutiliser le domaine IMS pour d'autres technologies d'accs telles que xDSL (Digital Subscriber Line), le cble 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 capacits du S-CSCF slectionner par le HSS (Rponse UAR : User Authorization Response). ces informations serviront d'entres sa fonction de slection d'un S-CSCF. 5. L I-CSCF vrifie si l usager est autoris s'enregistrer partir du rseau visit et dans le cas postif, L'I-CSCF relaye la mthode SIP REGISTER au S-CSCF appropri. L'entit S-CSCF a plus de fonctionnalits que les P-CSCF et I-CSCF. L'oprateur peut disposer de plusieurs S-CSCFs avec des capacit diffrentes et slectionner celui appropri pour rendre le service demand. 6. L entit S-CSCF demande des informations d authentification de l usager au HSS (MAR : Multimedia authentication request) 7. Le HSS retourne les informations dauthentification par une rponse MAA (Multimedia authentication answer) au S-CSCF. 8.9. 10. Lentit S-CSCF retourne lusager une rponse ngative denregistrmeent contenant une valeur random utiliser par sa carte SIM pour calculer un rsultat dauthentification. 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 aprs avoir vrifi les informations d authentification de l usager, met une requte 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 rponse SAA (Server Assignment Response l'entit S-CSCF, contenant le profil de l'usager. Ce profil consiste en les informations de souscription par l'usager des services, appeles 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 dlivrer directement des demandes d'tablissement de session entrantes concernant cet usager. 18. Le S-CSCF invoque des services ventuels tels que le service de Prsence. 19., 20. et 21. Une rponse 200 OK est retourne par le S-CSCF l'entit I-CSCF qui le relaye au P-CSCF qui le dlivre UE.
203
Adresses retournes par le S-CSCF
P-Associated-URI de John Cook :
<sip: JohnCook@orange.fr>, <sip : +33672225555@orange.fr; user=phone>, <sip:JohnCook_F@orange.fr>, <sip : +33672224457@orange.fr; user=phone>, <sip:JohnCook_P@orange.fr>, <sip : +33672224456@orange.fr; user=phone> <sip:JohnCook_G@orange.fr>
Seule la premire adresse de la liste prsente dans le header P-Associated-URI est considre comme enregistre. Elle peut donc tre utilise afin par exemple d tablir un appel.
Simon ZNATY
Copyright EFORT
204
Lorsque l usager s est authentifi avec succs et a t enregistr, le S-CSCF lui retourne une rponse 200 OK pour la requte REGISTER, contenant le header P-Associated- URI. La valeur de ce header est la liste des adresses publiques qui sont associes l usager mais qui ne sont pas forcment enregistres. Seule la premire URI prsente dans la liste (dans l exemple cidessus, il s agit de sip:JohnCook@orange.fr) est toujours une identit publique valide et enregistre qui peut tre utilise par l usager pour par exemple tablir des appels. Comme le header P-Associated-URI ne peut transporter que des SIP URIs, il inclut les TEL URI associs John Cook dans un format de SIP URI, par exemple si tel : +33672225555, alors l URI SIP correspondante est : sip : +33672225555@orange.fr; user=phone
204
Etat d enregistrement
John Cook envoie alors une requte SIP SUBSCRIBE au S-CSCF avec le header Event positionn la valeur reg Il obtient via une requte SIP NOTIFY retourne par le S-CSCF l tat de chacune de ses identits publiques :
<registration aor = sip : JohnCook@orange.fr , state="active">, <registration aor = tel: +33672225555 , state="active">, <registration aor = sip : JohnCook_F@orange.fr , state="active"> <registration aor = tel: +33672224457 , state="active"> <registration aor = sip : JohnCook_P@orange.fr , state="active"> <registration aor = tel: +33672224457 , state="active"> <registration aor = sip : JohnCook_G@orange.fr, state= "terminated">
Simon ZNATY
Copyright EFORT
205
John Cook met alors une requte SIP SUBSCRIBE au S-CSCF contenantun header Event = reg . Le S-CSCF retourne une requte SIP NOTIFY au terminal IMS, contenant l tat de chacune de ses identits publiques. Etat active signifie que l adresse est enregistre. Etat terminated signifie que l adresse est dsenregistre Etat init signifie que l adresse est en cours d enregistrement, par exemple REGISTER a t reu mais l usager n a pas encore t authentifi.
205
Annulation denregistrement de lUE

Rseau Visit
UE P-CSCF
Rseau Nominal
I-CSCF HSS S-CSCF
1. Register 2. Register 3. UAR 4. UAA 5. Register 6. Service Control

SIP DIAMETER
7. SAR 8. SAA 11. 200 OK 10. 200 OK 9. 200 OK
Simon ZNATY
Copyright EFORT
206
The deregistration from IMS may be mobile initiated or network initiated. The network-initiated deregistration may also be initiated by registration timeout or by a network administrative function such as HSS or S-CSCF. The above figure depicts the signaling flows of a mobile-initiated deregistration.The process is similar to the registration procedure, except that the expiration time is zero in the SIP REGISTER in Flows 1 ,2 ,and 5. When a mobile user wishes to deregister, it simply sends a new SIP REGISTER request. Because the user has registered already, the HSS indicates which S-CSCF should be contacted by Flow 4 in response to the query from the I-CSCF (Flow 3 ). Because the expiration time is zero, the S-CSCF will perform necessary service control functions to deregister and remove all subscription information regarding this user as indicated in Flow 6. The S-CSCF then sends its own name together with the mobiles identities to the HSS in a SAR message (Server Assignment Request) as illustrated in Flow 7. Based on the operator s choice, the SAR may either ask the HSS to clear or keep the S-CSCF name for the specific user. In either case, the HSS indicates that the user is unregistered. Once the S-CSCF receives the SAA answer (Server Assignment Answer), it clears all registration information of the user and triggers a 200 OK message to the I-CSCF. Similarly, the P-CSCF releases all registration information regarding the user upon receiving the 200 OK from the I-CSCF.
206
Flux de signalisation de bout en bout pour le contrle de la session (1)
La signalisation change de bout en bout pour ltablissement de la session peut tre divise en trois sous-flux :

Flux mobile origine Flux mobile destination Flux de signalisation S-CSCF I-CSCF S-CSCF
Rseau Nominal Mobile Destination
2. Flux S-CSCF I-CSCF
Rseau Nominal Mobile Origine I-CSCF I-CSCF S-CSCF S-CSCF
I-CSCF I-CSCF
S-CSCF S-CSCF
1. Flux mobile origine

Rseau visit P-CSCF Mobile Origine P-CSCF
3. Flux mobile destination

Rseau Visit P-CSCF P-CSCF Mobile Destination

Simon ZNATY

Copyright EFORT
207
L'tablissement d'une session entre deux UEs IMS ncessite les tapes suivantes : L'UE appelant initie la procdure d'tablissement de session par un message SIP INVITE. Ce message contient une description SDP. Cette dernire consiste en un ensemble d'attributs du mdia que l'appelant requiert pour la session. Le message INVITE est mis par l'UE l'entit P-CSCF qui le relaie au I-CSCF qui le dlivre au S-CSCF. I-CSCF et S-CSCF font toujours partie du rseau nominal de l appelant alors que le P-CSCF se trouve dans le rseau visit par l appelant. Si l appelant est dans son rseau nominal, alors le P-CSCF fait partie du rseau nominal. Le S-CSCF invoque ventuellement des services souscrits par l'appelant (e.g., prepaid, filtrage d appel au dpart, etc.) et achemine le message INVITE la destination. Afin de pouvoir acheminer ce message, le S-CSCF de l appelant interroge le DNS, identifie le rseau nominal de l appel et route le message INVITE un des I-CSCF du rseau nominal de l appel. L I-CSCF interroge le HSS de l appel, identifie ainsi le S-CSCF assign l appel, et route ce S-CSCF la mthode INVITE. Le S-CSCF aprs avoir invoqu les services souscrits par l appel, peut acheminer la requte INVITE au P-CSCF de l appel. L adresse de ce P-CSCF est apprise par le SCSCF au moment de l enregistrement de l appel au rseau IMS. Le P-CSCF se charge alors de dlivrer la requte INVITe l appel. Les deux participants la session ngocient les caractristiques du mdia (nombre de flux mdia, codec, etc.) pour la session. Le rseau rserve les ressources ncessaires la session aprs que les caractristiques du mdia aient t ngocies. Si l'tape de rservation de ressource est russie, l'UE appel retourne une rponse SIP 200 OK l'appelant qui l'acquitte par une mthode SIP ACK. 5. Les flux de mdia peuvent alors tre changs entre les UEs. Les flux mdia par contre n impliquent pas les rseau nominaux de l appelant et de l appel. Les rseaux nominaux sont invoqus uniquement sur le plan de contrle et ont pour but l invocation des services de l appelant et de l appel.
207
Flux de signalisation de bout en bout pour le contrle de la session (2)

Rseau Nominal Mobile Origine S-CSCF S-CSCF
2. Flux S-CSCF I-CSCF
Rseau Nominal Mobile Destination I-CSCF I-CSCF S-CSCF S-CSCF

P-CSCF P-CSCF

P-CSCF P-CSCF Rseau Visit Mobile Destination
Simon ZNATY
Copyright EFORT
208
Il est aussi possible de considrer que le P-CSCF de lappelant puisse directement contacter le S-CSCF de lappelant sans avoir passer par un ICSCF du rseau nominal de lappelant. Cela se produit lorsque lenregistrement, le P-CSCF apprend ladresse du S-CSCF. Il suffit que le SCSCF rajoute son adresse IP dans la rponse 200 OK retourne lusager pour lui confirmer son enregistrement. Le P-CSCF sur le chemin de cette rponse 200 OK copie alors ladresse IP du S-CSCF prsente dans cette rponse. Le header de la rponse 200 OK qui contient ladresse du S-CSCF sappelle le service-route.
208
Architecture de Roaming IMS

S-CSCF 5 HSS 4 3 6 8 DNS S-CSCF I-CSCF HSS
HN1
I-CSCF
HN2
IP
IP
P-CSCF
IPX
2
P-CSCF
VN1
9 Broadband Access 1 10
VN2
IP
IP
Broadband Access
Simon ZNATY
SIP (1, 2, 4, 6, 8, 9, 10) DIAMETER (3, 7) DNS (5)
VN : Visited Network HN : Home Network

Copyright EFORT
209
1. SIP INVITE (Appelant P-CSCF) 2. SIP INVITE (P-CSCF I-CSCF) 3. DIAMETER LIR (I-CSCF HSS) 4. SIP INVITE (I-CSCF S-CSCF) 5. DNS Query (S-CSCF DNS Server) 6. SIP INVITE (S-CSCF I-CSCF) 7. DIAMETER LIR (I-CSCF HSS) 8. SIP INVITE (I-CSCF S-CSCF) 9. SIP INVITE (S-CSCF P-CSCF) 10. SIP INVITE (S-CSCF Appel)
209
Etablissement de session IMS avec SIP UA 2 QoS SIP UA 1

Contrle de Service
1. INVITE (SDP1) 2. 183 Session Progress (SDP2) 3. PRACK 4. 200 OK (PRACK)
Rservation de ressource
Rservation de Ressource
Rservation de Ressource
5. UPDATE (SDP3) 6. 200 OK (UPDATE) (SDP4) 7. 180 Ringing 8. PRACK 9. 200 OK (PRACK) 10. 200 OK (INVITE) 11. ACK
Alerte et Rponse
Flux mdia RTP

210
Considrons lexemple suivant pour illustrer ltablissement d un appel entre deux usagers IMS avec QoS : UA1 met un mthode INVITE (1) contenant une description SDP1 pour tablir une session avec UA2. Cette description SDP indique des prconditions de QoS pour la session (e.g., session tlphonique). UA1 ne souhaite pas que UA2 soit alert tant que les ressources n'ont pas t rserves dans les deux sens (sendrecv). UA2 accepte de rserver des ressources pour cette session avant d'alerter l'appel. UA2 prend en charge la rservation des ressources dans le sens UA2UA1 ; par ailleurs il est ncessaire que UA1 rserve des ressources dans le sens UA1UA2. Afin de le lui indiquer, UA2 retourne une rponse provisoire 183 Session Progress (2) UA1 lui demandant de commencer la rservation des ressources et de confirmer UA2 ds que la session est prte dans le sens UA1UA2. Cette rponse provisoire contient aussi une description SDP2. A La rception du 183 Session Progress, UA1 met une mthode PRACK (3) acquitte par 200 OK (4). UA1 et UA2 commencent la rservation de ressources (dans le cas de UE IMS, en crant des contextes PDP avec la QoS requise pour la session; cette cration implique les entits UE, SGSN et GGSN). Mme si UA2 a reu une confirmation du rseau qui indique la rservation des ressources, l'appel n'est pas alert tant qu'une confirmation n'est pas envoye par UA1. Lorsque UA1 a finalis sa procdure de rservation, il met un message UPDATE (5) UA2 contenant une description SDP3 qui indique cette rservation dans le sens UA1UA2. UA2 retourne une rponse 200 OK (6) de confirmation de la mthode UPDATE, indiquant que toutes les prconditions de Qos pour la session ont t remplies et que la QoS a bien t rserve dans les deux sens (La rponse 200 OK contient la description SDP4). A cet instant, UA2 alerte l'appel. Une rponse provisoire 180 Ringing (7) est mise par l'UA2 l'UA1. L'appel dcroche. UA2 retourne une rponse 200 OK (10) (rponse la mthode INVITE) sans description SDP. UA1 met une mthode ACK (11) afin de finaliser ltablissement dappel. L'change de mdia peut donc avoir lieu entre les deux participants la session.
210
Ngociation de QoS avec les paramtres SDP

SDP1 m=audio 49234 RTP/AVP 97 c=IN IP6 3456::1:2:3:4 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv SDP2 m=audio 41212 RTP/AVP 97 c=IN IP6 6789::5:6:7:8 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv SDP3 m=audio 49234 RTP/AVP 97 c=IN IP6 3456::1:2:3:4 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv SDP4 m=audio 41212 RTP/AVP 97 c=IN IP6 6789::5:6:7:8 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv
Simon ZNATY
Copyright EFORT
211
Pour chaque description SDP, deux paramtres sont spcifis : a= curr:qos tat courant de la QoS a=des:qos tat dsir de la QoS indicant les exigences de QoS des parties dans l appel Le besoin de QoS est exprim traves tois paramtres : mode, strength et type. Mode : peut valoir send, receive, sendrecv ou none. Il exprime le sens du flux media pour la QoS. Si la valeur est none, cela signifie, qu aucune QoS n a t tablie pour le flux. Type : Le type peut tre local, remote ou e2e (end-to-end). Ce paramtre se rfre au rseau dans lequel la QoS est requise. Pour chaque UA, local signifie le rseau local de l UA et remote signifie le rseau d accs de l entit paire. e2e est utilis si la QoS peut tre ablie par un des UAs sur l ensemble du lien. Strength : Indique quel point l tablissement de la QoS est critique pour la progression de l appel. Les valeurs possibles sont : non, optional et mandatory. Pour l tablissement de l appel, toutes les demandes avec mandatory doivent tre satisfaites. Si optional, alors l appel peut aboutir mme si la QoS ne peut tre fournie
211
Etablissement de Session IMS (R8) (1)

UE P-CSCF Serving GW PDN GW S-CSCF
PCRF
INVITE (SDP1) 183 Session Progress PRACK 200 OK (PRACK) ... ... Rx. AA Answer UPDATE 200 OK (UPDATE) 180 Ringing PRACK 200 OK (PRACK) 200 OK (INVITE) Simon ZNATYACK UPDATE 200 OK (UPDATE) 180 Ringing PRACK 200 OK (PRACK) 200 OK (INVITE) ACK
Copyright EFORT
INVITE (P-Charging-Vector, SDP1) 183 Session Progress 183 Session Progress Rx. AA Request (SDP1, SDP2) PRACK PRACK 200 OK (PRACK) 200 OK (PRACK) Gx. Re-Auth Request (QoS: QCI, ARP, GBR, MBR) Create Bearer Request (QoS) Create Bearer Response Gx. Re-Auth Answer UPDATE 200 OK (UPDATE) 180 Ringing PRACK 200 OK (PRACK) 200 OK (INVITE) ACK
212
INVITE (P-Charging-Vector, SDP1)
Rx Gx GTP SIP SM
The call flow for this example is shown in the figure above. For step 1, the original offer is sent in the INVITE message ;the SDP also contains the request for the QoS. The SDP for the answer in step 2 is sent using the 183 session progress response, SDP2. Since this message is crucial to the call, it must be sent reliably,and to achieve this the provisional acknowledgement message PRACK is used. The 183 response will be retransmitted until a PRACK is received by UA2.Once the 183 message has been received by UA1, it can request the QoS from its own access network. When UA1 receives local confirmation of its QoS request, it sends the UPDATE message containing SDP3.This contains the confirmed QoS provision.This UPDATE message (RFC 3311) is designed to allow details about the media stream to be updated without modifying the SIP call state. As well as QoS provision, UPDATE can be used to control early media streams (for example when sending call progression signaling inband). At UA2, as soon as the local QoS request is confirmed and the UPDATE message received, the user can be alerted and the call proceeds as normal. The CDRs generated in the IMS nodes are correlated by an IMS Charging Identifier (ICID). This identifier is globally unique across all 3GPP IMS networks for a period of at least one month. Expiration of an ICID can be detected by using IMS node-specific information, e.g., high-granularity time information and location information. A new ICID is generated for an IMS session at the first IMS node that processes the SIP INVITE message. The ICID is included in all subsequent SIP messages (e.g., 200 OK, UPDATE, and BYE) for that IMS session until the session is terminated. For the example shown above, an ICID is generated by the callers P-CSCF for mobile-originated calls. The SIP request includes the ICID specified in the P-Charging-Vector header. This ICID is passed along the SIP signaling path to all involved IMS nodes. Each IMS node that processes the SIP request retrieves the ICID and includes it in the CDRs generated later. In a CSCF CDR, the ICID is listed in the IMS Charging Identifier field. Therefore, CDRs from different IMS nodes within an IMS session can be correlated in the billing system through the ICID. GTP : GPRS Tunneling Protocol SM : Session Management.
212
Etablissement de Session IMS (R8) (2)

Rx Gx UE GTP I-CSCF SIP PCRF SM INVITE INVITE (P-Charging-Vector, SDP1) INVITE (SDP1) (P-Charging-Vector, SDP1) 183 Session Progress (SDP2) 183 Session Progress (SDP2) 183 Session Progress (SDP2) Rx. AA Request (SDP1, SDP2) PRACK PRACK PRACK 200 OK (PRACK) 200 OK (PRACK) 200 OK (PRACK) Gx. Re-Auth Request (QoS : QCI, ARP, GBR, MBR) S-CSCF PDN GW Serving GW P-CSCF Create Bearer Request (QoS) Create Bearer Response Gx. Re-Auth Answer UPDATE 200 OK (UPDATE) 180 Ringing PRACK 200 OK (PRACK) 200 OK (INVITE) ACK Simon ZNATY UPDATE 200 OK (UPDATE) 180 Ringing PRACK 200 OK (PRACK) 200 OK (INVITE) ACK
Copyright EFORT
... Rx AA Answer UPDATE 200 OK (UPDATE) 180 Ringing PRACK 200 OK (PRACK) 200 OK (INVITE) ACK
213
213
4.4. Service SMS avec IMS

3GPP TS 23.204 3GPP TS 24.341
Simon ZNATY
Copyright EFORT
214
214
Architecture de rfrence du service SMS sur IMS

HSS
SMSC
C (MAP)
E (MAP)
IP-SM-GW Application
ISC (SIP)
S-CSCF
Sh (Diameter)
Cx (Diameter)
SIP UE
215
Simon ZNATY
Copyright EFORT
The IP-SM-GW shall provide the protocol interworking for delivery of the short message between the IP-based UE and the SMSC. The message is routed to the SMSC for delivery to the SMS-based user or the message is received from the SMSC of an SMS-based UE for delivery to an IP-based UE. The general functions of the IP-SM-GW are: to determine the domain (CS/PS or IMS) for delivery of an SMS message; to connect to the SMSC using established MAP protocols, appearing to the SMSC as an MSC or SGSN using the E or Gd interfaces; to connect to the HSS using established MAP protocols , to obtain the address of MSC/SGSN address(es) for MT delivery of SMS message in CS/PS; to check that it has a valid address in SMS for the sender as well as the recipient when receiving an IMS message for an SMS user. The IP-SM-GW shall obtain a valid address for both from the SIP headers of the IMS message (e.g. the sender would be identified in the asserted id in form of TEL URI). for terminating procedures, to map the recipients address from an MSISDN/IMSI to TEL URI format when receiving an SMS for an IP-based UE, and then it is the responsibility of the IMS core to perform any further mapping towards a SIP URI as required. to act as an Application Server towards the IMS core. to perform domain selection to choose the appropriate domain to deliver a message to a recipient and to obtain the MSC and/or SGSN addresses from the HSS. The additional functions of the IP-SM-GW when interworking is done by carrying encapsulated SMS messages in IMS messages are: to communicate with the UE using IMS messaging as transport while maintaining the format and functionality of the SMS message; to carry the SMS status messages as encapsulated bodies of IMS messages; to store the subscriber data of the short message service similar to the data for the current CS/PS domain and to perform the short message authorization as performed by the MSC/SGSN, as well as to store additional service data on the service authorisation of the encapsulated short message delivery via IMS and to perform the service authorization. In order to support SMS over generic IMS, the HSS shall support the following functions: storing the address of the IP-SM-GW.
215
LIP-SM-GW indique au HSS la disponibilit de lIMPU pour la livraison des SMS

UE
P-CSCF I-CSCF S-CSCF HSS
IP-SM-GW Application 1. Successful UE registration 2. Evaluation of initial filter criteria
3. REGISTER 4. 200 OK 5. SUBSCRIBE 6. 200 OK 7. NOTIFY 8. 200 OK 9. MAP:ATM 10. MAP:ATM response
Simon ZNATY
Copyright EFORT
216
The figure shows the registration signalling flow for the scenario when IP-SM-GW registers to HSS. The details of the signalling flows are as follows: 1. The user registers successfully to IMS. 2. Initial filter criteria. The S-CSCF analyses the incoming request against the initial filter criteria and decides to send a third-party REGISTER request to the IP-SM-GW. Initial Filter Criteria for IP-SM-GW includes a Service Information that contains the MSISDN belonging to "sip:user1_public1@tn.com". 3. REGISTER request (S-CSCF to IP-SM-GW) . This signalling flow forwards the REGISTER request from the S-CSCF to the IP-SM-GW. 4. 200 OK response (IP-SM-GW to S-CSCF). The IP-SM-GW sends a 200 (OK) response to the S-CSCF indicating that registration was successful. 5. SUBSCRIBE request (IP-SM-GW to S-CSCF). The IP-SM-GW subscribes to the S-CSCF for the registration status of the registered subscriber. 6. 200 (OK) response (S-CSCF to IP-SM-GW). The S-CSCF sends a 200 (OK) response to the IP-SM-GW. 7. NOTIFY request (S-CSCF to IP-SM-GW). The S-CSCF sends a first NOTIFY request to the IP-SM-GW. The notification indicates that the monitored public user identity registered using an SMS capable UE. 8. 200 (OK) response (IP-SM-GW to S-CSCF). IP-SM-GW sends a 200 (OK) response to the S-CSCF. 9. MAP: AnyTimeModification. The IP-SM-GW sends the request to inform the HSS/HLR that the user with MSISDN +32435465761" is ready to receive short messages via the sender of the request. 10. MAP: AnyTimeModification response. The HSS/HLR acknowledges the request.
216
Envoi de SMS russi partir de lIMS

HSS
S-CSCF
SMSC
UE
1. SIP Message 2. SIP Message 3. 202 Accepted 4. 202 Accepted 5. MAP-Mo-forward-Short-Message.req 6. MAP-Mo-forward-Short-Message.ack 7. SIP Message (Submit Report) 8. SIP Message (Submit Report) 9. 200 OK 10. 200 OK
Simon ZNATY
Copyright EFORT
217
1. UE submits the SMS message (SMS-SUBMIT, SC Address) to the S-CSCF using the SIP MESSAGE method. 2. S-CSCF forwards the Message (SMS- SUBMIT, SC Address) to IP-SM-GW (AS) based on stored iFC (Initial Filter Criteria). iFC corresponds to a service mark in the service profile of originator of the SMS. NOTE: Subscribers who have no subscription for SMS service will be provided with the relevant iFCs, to provide SMS filtering/blocking. 3. IP-SM-GW (AS) acknowledges the SIP message with a 202 meaning that the message has been received but not yet delivered to the destination user. 4. SIP message acknowledge is forwarded by S-CSCF to UE. 5. The IP-SM-GW performs service authorization based on the stored subscriber data. The IP-SM-GW shall check whether the subscriber is authorised to use the short message service (e.g. Operator Determined Barring settings), similar to the authorization performed by MSC/SGSN in case the short message is delivered via CS or PS domain. In addition, the IP-SM-GW shall also check whether the user is authorised to use the encapsulated short message delivery via IMS. If the result of service authorization is negative, the IP-SM-GW shall not forward the message, and shall return the appropriate error information to the UE in a failure report. Otherwise, the IP-SM-GW (AS) extracts the SMS message (SMS- SUBMIT) and forwards it to SMSC (SC Address) using standard MAP signalling (MAP-MO-FORWARD-SM.Req). 6. SMSC sends SUBMIT-REPORT to IP-SM-GW. 7. IP-SM-GW (AS) sends SUBMIT-REPORT to S-CSCF, using a SIP MESSAGE method. 8. S-CSCF sends the SUBMIT-REPORT to the UE. 9. UE acknowledges the SUBMIT-REPORT. 10. Acknowledgement of the SUBMIT-REPORT is forwarded by S-CSCF to IP-SM-GW (AS).
217
Livraison de SMS russie via lIMS

HSS
S-CSCF
SMSC
UE
1. MAP-SRI-for-SMS.req 2. MAP-SRI-for-SMS.ack 3. MAP-MT-forward-Short-Message.req 4. SIP Message (SMS message) 5. SIP Message (SMS Message) 6. 200 OK 7. 200 OK 8. MAP-MT-forward-Short-Message.ack
Simon ZNATY
Copyright EFORT
218
1. The SMSC interrogates the HLR/HSS of the recipient of the SMS to identify the GT (Global Title) the SMS should be delivered to. 2. The HLR returns the GT of the IP-SMS-GW. 3. The SMSC send the MAP-MT-FORWARD-SM message to the IP-SMS-GW. 4. The IP-SMS-GW knows that the UE is registered with the IMS domain. It translate the received MAP message into a SIP Message method and sends it to the S-CSCF of the UE. 5. The S-CSCF routes it the the UE. 6. He UE acknowledges it by a 200 OK. 7. 200 OK is forwarded by the S-CSCF to the IP-SMS-GW 8. The IP-SMS-GW sends an acknowledgment of SMS delivery to the SMSC using the MAP protocol.
218
LIP-SM-GW indique au HSS lindisponibilit de lIMPU pour la livraison des SMS

UE
P-CSCF I-CSCF S-CSCF HSS
1. Successful UE deregistration 2. NOTIFY 3. 200 OK 4. MAP:ATM 5. MAP:ATM response
Simon ZNATY
Copyright EFORT
219
The Figure shows the registration signalling flow for the scenario when IP-SMGW deregisters to HSS. The details of the signalling flows are as follows: 1. Deregistration is similar to a registration with the Expires header set to zero. 2. NOTIFY request (S-CSCF to IP-SM-GW). The S-CSCF sends a first NOTIFY request to the IP-SM-GW. The notification indicates that the monitored public user identity is not registered any more with an SMS capable UE. 3. 200 (OK) response (IP-SM-GW to S-CSCF). IP-SM-GW sends a 200 (OK) response to the S-CSCF. 4. MAP: AnyTimeModification. The IP-SM-GW sends the request to inform the HSS/HLR that the user with MSISDN +32435465761" is not available to receive short messages via the sender of the request. 5. MAP: AnyTimeModification response. The HSS/HLR acknowledges the request.
219
Conclusion

Simon ZNATY
Le futur rseau mobile 4G s appelle l EPS. Son rseau d accs est nomm LTE (3,99G) avec son volution appele LTE-Advanced (4G). Le terme eUTRAN est aussi utilis. Son rseau cur, l ePC est un rseau tout IP. Le terme SAE est aussi utilis. L ensemble LTE+ePC est l EPS. Il s agit d un rseau d accs large bande qui offre une connectivit au monde Internet/Intranet, avec QoS, avec mobilit, et pouvant supporter la fonctionnalit multicast. Afin de contrler les flux IP du client et taxer les flux autoriss, une architecture PCC est mise en uvre. Les services proposs au client sont tous mis en uvre dans le monde IP. L IMS est l architecture long terme pour offrir les services multimdia incluant la voix et le SMS. Deux solution alternatives existent pur offrir les services circuit : double rattachement et CS-Fallback. 220
Copyright EFORT
220
Acronymes LTE/ePC et IMS (1)

AAA AGW APN-AMBR ARP AS BBERF BGF BGCF CSCF CSFB DL TFT DNS EIR EMM EPC ePDG EPS E-RAB ESM E-UTRAN GBR GGSN GRE GTP GTP-C GTP-U GUMMEI
Authentication, Authorization and Accounting Access Gateway Per APN Aggregate Maximum Bit Rate Allocation/Retention Priority Application Server Bearer Binding and Event Reporting Function Border Gateway Function Breakout Gateway Control Function Call State Control Function Circuit Switch Fallback DownLink Traffic Flow Template Domain Name Service Equipment Identity Register EPS Mobility Management Evolved Packet Core Evolved Packet Data Gateway Evolved Packet System E-UTRAN Radio Access Bearer EPS Session Management Evolved Universal Terrestrial Radio Access Network Guaranteed bitrate Gateway GPRS Support Node Generic routing Encapsulation GPRS Tunnelling Protocol GTP Control Part GTP User Part Globally Unique MME Identifier
GUTI GW HA HLR HSS I-CSCF IMS IMS-MGW IP-SM-GW IPX ISC LBI LTE MBR MGCF MME MMEC MMEGI MMEI MRF MSC M-TMSI NAS OCS OFCS OMC-ID PCEF PCRF
Globally Unique Temporary Identity Gateway Home Agent Home Location Rregister Home Subscriber Server Interrogating CSCF IP Multimedia Subsystem IMS Media Gateway IP SMS Gateway IP Exchange IMS Service Control Interface Linked EPS Bearer Id Long Term Evolution of 3G Maximum Bitrate Media Gateway Control Function Mobility Management Entity MME Code MME Group Id MME Identifier Multimedia Resource Function Mobile Services Switching Center M-Temporary Mobile Subscriber Identity Non-Access Stratum Online Charging System Offline Charging System Operation and Maintenance Center Identity Policy Enforcement Function Policy and Charging Rules Function
Simon ZNATY
Copyright EFORT
221
221
Acronymes LTE/ePC et IMS (2)

P-CSCF PDB PDCP PDG PDN PDP P-GW PDN GW PLR PMIP PSAP PTI QCI SAE SCC S-CSCF SCP SCTP SDF SGSN S-GW Serving GW SGW SIP SMS SMSC
Proxy CSCF Packet Delay Budget Packet Data Convergence Protocol Packet Data Gateway Packet Data Network Packet Data Protocol PDN Gateway PDN Gateway Packet Loss Rate Proxy Mobile IP Public Safety Answering Point Protocol Transaction Id QoS Class Indicator System Architecture Evolution Service Centralization and Continuity Serving CSCF Service control Point Stream Control Transmission Protocol Service Data Flow Serving GPRS Support Node Serving Gateway Serving Gateway Signaling Gateway Session Initiation Protocol Short Message Service SMS Center
SPR SRP SSP S-TMSI TA TAC TAI TAU TCP TPF TI UE UL TFT VANC VoLGA VoLTE XCAP
Subscription Profile Repository Specialized Resource Point Service Switching Point S-Temporary Mobile Subscriber Identity Tracking Area Tracking Area Code Tracking Area Identity Tracking Area Update Transmission Control Protocol Transport Plane Function Transaction Identifier AMBR : Per UE aggregate maximum bit rate UpLink Traffic Flow Template VoLGA Access Network Controller Voice over LTE via Generic Access Voice over LTE XML Configuration Access Protocol
Simon ZNATY
Copyright EFORT
222
222
Rfrences LTE/ePC

3GPP TS 23.002. Network architecture (Release 8). 3GPP TS 23.003, Numbering, addressing and identification (Release 8). 3GPP TS 24.008, Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 8). 3GPP TS 29.274, 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS), Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 8). 3GPP TS 23.401, General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 8). 3GPP TS 23.272, Circuit Switched Fallback in Evolved Packet System; Stage 2 (Release 8). 3GPP TS 23.204, Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access; Stage 2 (Release 8). 3GPP TS.29.212. Policy and Charging Control over Gx reference point (Release 9) 3GPP TS.29.214. Policy and Charging Control over Rx reference point (Release 9) 3GPP TS.29.213. Policy and Charging Control signalling flows and Quality of Service (QoS) parameter mapping (Release 9) Harri Holma and Antti Toskala, LTE for UMTS: OFDMA and SC-FDMA Based Radio Access , Wiley 2009. Pierre Lescuyer and Thierry Lucidarm, Evolved Packet System : LTE and SAE Evolution of 3G UMTS , Wiley 2008.
Copyright EFORT
Simon ZNATY
223
223
Rfrences IMS
3GPP TS 23.517 : TISPAN IMS Functional architecture. 3GPP TS 23.228 : IP Multimedia Subsystem (IMS) Stage 2 3GPP TS 23.218. Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network; IP Multimedia (IM) session handling; IM call model; Stage 2 3GPP TS 23.206. Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 2 3GPP TR 22.973. Technical Report 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IMS Multimedia Telephony service; and supplementary services 3GPP TR 24.930. Signalling flows for the session setup in the IP Multimedia core network Subsystem (IMS) based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 3GPP TS 24.228. Signalling flows for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 3GPP TS 29.228. Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signaling flows and message contents
Simon ZNATY
Copyright EFORT
224
224
Livres IMS
Dave Wisely, Philip Eardley and Louise Burness, BTexact Technologies, IP for 3GNetworking Technologies for Mobile Communications, John Wiley & Sons, Ltd, 2002. Basavaraj Patil, Yousuf Saifullah, Stefano Faccin, Srinivas Sreemanthula, Lachu Aravamudhan, Sarvesh Sharma, Risto Mononen, IP in Wireless Networks, Prentice Hall PTR, 2003. Jyh-Cheng Chen, Tao Zhang, IP-Based Next-Generation Wireless Networks, John Wiley & Sons, Ltd, 2003. Miikka Poikselk, Georg Mayer, Hisham Khartabil, Aki Niemi, IP Multimedia Concepts and Services in the Mobile Domain, John Wiley & Sons, 2006.
Simon ZNATY
Copyright EFORT
225
225

Support de Cours LTE - SII

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Support de Cours LTE - SII

Încărcat de

Drepturi de autor:

Formate disponibile

Etudes et FORmations en Tlcommunication

GPRS, (LTE + ePC = EPS), PCC, IMS

1. Evolution des Rseaux Mobiles 2. GPRS dans le rseau mobile

3. LTE + ePC = EPS

1. Evolution des Rseaux Mobiles

Accs et Rseau mobiles

Points importants de chaque Release 3G

Evolution dans le rseau cur

Dbits pour les services de donnes

Latence (latency) moyenne laccs

Evolution de larchitecture de Rseau Mobile

RTC NGN Accs

Evolution 2G/3G avec NGN

RTC RTC NGN IMS PS Accs

EPS = LTE + ePC

3G avec Evolution IMS

IS-95 : Evolution Rseau

Max : downlink :288 Mbit/s uplink : 75 Mbit/s

10 Mbit/s 2 Mbit/s 1 Mbit/s 100 kbit/s 60 kbit/s 14,4 kbit/s IS-95A

March des terminaux HSPA (4 Aot 2011)

HTC iPhone 4 Wildfire S D-Link Wireless Router

Sierra Wireless 885 USB Modem

LTE versus UMB

301 oprateurs dans 95 pays investissent dans la LTE

Evolution to LTE report (GSA) 13 Mars 2012

57 rseaux commerciaux LTE dploys au 13 Mars 2012 (1)

TeliaSonera TeliaSonera MTS UCell

March 13, 2012; GSA; www.gsacom.com)

57 rseaux commerciaux LTE dploys au 13 Mars 2012 (2)

57 rseaux commerciaux LTE dploys au 13 Mars 2012 (3)

57 rseaux commerciaux LTE dploys au 13 Mars 2012 (4)

2. GPRS dans le rseau mobile

2.1. Entits GPRS

Architectures 3G et 3G+ actuelles

BTS BTS BTS

MSC VLR Server Frame Relay

RTC OFCS PCRF OCS

Gbit Eth Node B

PCEF GGSN Internet Intranet

Architectures 3G et 3G+ futures

BTS BTS BTS

MSC VLR Server

Gbit RNC Eth

RTC OFCS PCRF OCS

Gbit Eth Node B

PCEF GGSN Internet Intranet

Evolution du domaine paquet vers une architecture plate

Plan Contrle Plan Usager

User Equipment (UE)

IMSI = 208 01 4356244811

A chaque abonn est associ :

IMEI = 435654 45 056543 0

Interfaces entre UE et 3G MSC / 3G SGSN

3G MSC GMM Protocol

Devient gnralement un MME du rseau LTE/ePC

Un nud SGSN a une capacit dfinie par les paramtres suivants :

Un nud GGSN a une capacit dfinie par les paramtres suivants :

Nombre de contextes PDP actifs simultanment Bande passante totale

Backbone Intra-PLMN (rseau intra-oprateur IP)

LAN, Liens point point, ATM, etc.

Backbone Inter-PLMN (rseau inter-oprateur IP)

2.2. Gestion de la mobilit, Gestion de session, Roaming GPRS

Attachement au domaine paquet (PS, Packet Switching)