Tesis Doctoral Contribución al Desarrollo de Soluciones Para

Transcripción

UNIVERSIDAD CARLOS III DE MADRID
Tesis Doctoral
Contribución al Desarrollo de
Soluciones Para la Integración de
Métodos de Establecimiento de Sesión
en Redes 4G
(Contribution to Designing Suitable Session Setup
Solutions in 4G Networks)
Autor:
D. Antonio Cuevas Casado
Director:
Dr. José Ignacio Moreno Novella
DEPARTAMENTO INGENIERÍA TELEMÁTICA
Leganés, Junio de 2006
AGRADECIMIENTOS
Son muchas las personas que con sus ánimos, consejos, amistad o cariño, han
contribuido a que esta tesis llegara a buen término. Esta tesis es, en parte, también
vuestra; recibid mi más cordial agradecimiento.
A José Ignacio Moreno, director de esta tesis. Gracias por tu excelente labor
como director; por tus consejos, por tu experiencia, por tu constante apoyo y por la
confianza que siempre has depositado en mí.
Al resto de compañeros del Departamento de Ingeniería Telemática de la
Universidad Carlos III de Madrid y a todos los colegas con los que, durante estos cinco
años, he tenido el gusto de trabajar. Vuestra ayuda ha sido fundamental.
Y, como no, gracias a mi familia y amigos, por contribuir a que esta tesis salga
adelante y, sobretodo, por tantas otras cosas.
ii
ABSTRACT
The convergence or, better, migration of the telephone network into the Internet
is becoming a reality. It is already common to use, over the Internet, traditional services
from the telephone network like voice calls. Besides, features such as mobility are ready
to be implemented into the Internet. This “converged” IP-based communication
infrastructure is what is known under the general term of 4G networks. The definition of
4G network is still vague but it is clear that it will be a step beyond the 3G “All-IP”
based networks in the sense that IP will be native in 4G networks while it is an overlay
in 3G “All-IP” ones.
The advantages of this migration are clear and, as such, strong research efforts
are directed to 4G. In 4G networks the users’ mobile devices will be like another IP
host connected to the Internet. In such a scenario, the network operator infrastructure
will be degraded to bit pipes. Because of this and the lack of “winning” business
models, proper session setup and management solutions integrating service and network
layers are not yet available. This thesis will tackle this issue. Our aim is to design
solutions that place again the network operator in the core of the business value chain.
IMS or i-mode business models will be followed.
We will concentrate on the orchestration between the different systems, subservices (including transport service) and business entities. But still the Internet model
of complete separation between transport and applications will be kept. We will design
the session setup interactions between the pillars of 4G networks: QoS, AAA, and SIP
proxies infrastructure. Mobility will not be dealt in our thesis, although, as we will see,
it could easily be integrated in our framework. Our goal is to propose several
approaches for several scenarios, compare and evaluate them (including by the means of
simulation) and design the mechanisms for their coexistence.
Since some parts of the session setup “puzzle” are already available we shall
analyse them, see what is profitable, identify research opportunities and analyse the
optimal way to put all the “pieces” together. In concrete, we should evaluate session
setup protocols and session description languages to see if they fulfil our needs, for
instance, we will need to include cost sharing aspects in SDP. Another aspect we will
tackle is the design of some aspects of 4G networks relevant to our session setup
techniques but not yet available, like the AAA-QoS interaction. The integration and
coexistence of the different business models into our 4G framework and session setup
solutions will be addressed.
This thesis is part of the “Communications Technologies” Doctorate in the
University “Carlos III de Madrid”. It will apply for a “European amendment”
(“mención Europea”) in the Ph.D. Diploma. Following the rules, part of this thesis is
written in English and part in Spanish.
iii
INDICE
1.
2.
Introduction and Objectives ________________________________ - 13 1.1
Overal objectives __________________________________________- 15 -
1.2
Thesis phases _____________________________________________- 17 -
1.3
Resources employed________________________________________- 18 -
1.4
Document outlook _________________________________________- 19 -
State of the Art Analysis; Research Opportunities_______________ - 21 2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.2
Session setup techniques ____________________________________- 21 Session setup models ____________________________________________ - 21 IETF’s RSVP for QoS enabled transport sessions______________________ - 26 IETF’s SIP and SDP for application sessions _________________________ - 27 H323 and H323 vs. SIP __________________________________________ - 31 Research efforts ________________________________________________ - 31 Coordination of application and network setup ________________________ - 34 -
IMS _____________________________________________________- 36 -
2.2.1
SIP signalling in the IMS _________________________________________ - 38 2.2.2
Integration of session setup and network setup in IMS __________________ - 38 2.2.2.1 Charging aspects in session setup and tear down ___________________ - 39 2.2.2.2 Authentication and Authorization in SIP registration and session setup _ - 41 2.2.2.3 QoS and policy aspects in session setup and tear down ______________ - 42 2.2.3
Business model proposed, IMS general conclusions ____________________ - 44 2.2.4
“Next Generation Network” framework _____________________________ - 45 -
2.3
2.3.1
2.3.2
2.3.3
2.4
3.
4G networks ______________________________________________- 46 Fundamentals of 4G networks _____________________________________ - 46 Research projects _______________________________________________ - 51 Session setup aspects in research projects ____________________________ - 52 -
Conclusion. Research opportunities and thesis objectives_________- 54 -
Análisis del Problema: Dispersión de las Sesiones ______________ - 57 3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.2
Diversidad de entidades y de sesiones _________________________- 57 Interlocutores. Parámetros a negociar _______________________________ - 57 Interlocutores -Proveedores de Servicio- _____________________________ - 63 Proveedor de Red _______________________________________________ - 64 “Mediadores” en el establecimiento de sesión_________________________ - 66 -
Modelos de negocio, análisis de requisitos______________________- 67 -
3.2.1
Modelos de negocio, análisis de sus prestaciones ______________________ - 68 3.2.1.1 Tipos de sevicio y requistios para componer servicios _______________ - 68 3.2.1.2 El modelo de negocio Internet __________________________________ - 70 3.2.1.3 El negocio de los operadores móviles. Modelo “Walled Garden” ______ - 71 3.2.1.4 El modelo “Semi-Walled Garden” _______________________________ - 71 3.2.1.5 Dueños de puntos de acceso “WiFi” _____________________________ - 74 3.2.2
Propuestas de gestión de los perfiles de usuario _______________________ - 74 3.2.2.1 Contratos, identidades y perfiles de usuario _______________________ - 74 3.2.2.2 Perfiles de usuario: el NVUP y contratos con los proveedores de servicio- 75 3.2.2.3 Perfiles de usuario: el SVUP. Coherencia lograda __________________ - 77 3.2.2.4 Almacén de los perfiles de usuario ______________________________ - 78 -
3.3
Interacción con el proveedor de red. Cohesión de las sesiones _____- 79 -
3.3.1
Los interlocutores gestionan la petición de servicio de transporte _________ - 81 3.3.1.1 Perfiles y contratos involucrados ________________________________ - 81 3.3.1.2 Negociación, niveles de transporte y aplicación ____________________ - 82 3.3.2
Usuarios y proveedores de servicio _________________________________ - 84 iv
3.3.3
3.3.4
3.3.5
3.4
4.
Uso de mediadores ______________________________________________ - 85 Relación con los modelos de negocio _______________________________ - 87 Consideraciones sobre “roaming” __________________________________ - 88 -
Conclusiones______________________________________________- 89 -
Proposed 4G Architecture & Session Setup Support _____________ - 91 4.1
4G Systems involved in session setup __________________________- 92 -
4.1.1
Users’ Profiles and session concept in the 4G systems __________________ - 92 4.1.1.1 QoS enabled data transport_____________________________________ - 92 4.1.1.2 MMSP _____________________________________________________ - 95 4.1.1.3 AAA ______________________________________________________ - 96 4.1.1.4 Mobilitiy ___________________________________________________ - 99 4.1.1.5 Network Measurement System ________________________________- 100 4.1.2
Systems’ interactions and their relevance for session setup _____________- 101 4.1.2.1 AAA-security ______________________________________________- 101 4.1.2.2 Mobility - AAA+security _____________________________________- 101 4.1.2.3 AAA-QoS _________________________________________________- 102 4.1.2.4 MMSP-AAA and MMSP-QoS_________________________________- 103 -
4.2
Architecture of the 4G systems involved in session setup ________- 104 -
4.2.1
QoS. Proposed designs for setting up QoS sessions ___________________- 104 4.2.1.1 QoSBroker as central transport control entity _____________________- 104 4.2.1.2 QoSBroker: QoS management and access control _________________- 105 4.2.1.3 Access and Core Networks____________________________________- 105 4.2.1.4 AN-QoSBroker and AR in session setup _________________________- 107 4.2.1.5 Role of the CN-QoSBroker in session setup ______________________- 110 4.2.1.6 Interactions with the service providers. Application garden __________- 111 4.2.1.7 Roaming and local AN-QoSBroker as contact point________________- 111 4.2.1.8 Summary of QoS system interactions ___________________________- 111 4.2.2
MMSP design _________________________________________________- 111 4.2.2.1 AN-MMSP ________________________________________________- 112 4.2.2.2 CN-MMSP ________________________________________________- 112 4.2.2.3 SIP message “routing” proposal. MMSP interfaces ________________- 113 4.2.2.4 Roaming __________________________________________________- 114 4.2.2.5 Application garden __________________________________________- 114 4.2.3
IRTF’s AAA and our decentralisation proposal ______________________- 114 4.2.3.1 Application garden __________________________________________- 115 4.2.3.2 Conclusion, AAA System interfaces ____________________________- 116 4.2.4
Other systems: Measurements & Mobility __________________________- 116 4.2.5
AN CN split and WiFi hot spots venue owners. ______________________- 116 -
4.3
Session setup possibilities in the proposed architecture __________- 117 -
4.3.1
AAA Authorization or distribution of users profiles? __________________- 117 4.3.2
Session setup: proposals to orchestrate the interactions between systems __- 118 4.3.3
Proposals for QoS transport session setup. Propagation of QoS sessions___- 121 4.3.3.1 MMSP or Terminal doing the QoS reservation ____________________- 121 4.3.3.2 Terminal non inband QoS reservation ways ______________________- 122 4.3.3.3 Terminal inband QoS reservation and flow QoS identification _______- 122 4.3.3.4 Propagation of QoS transport sessions between ANs _______________- 124 4.3.3.5 Propagation of sessions and users’ profiles _______________________- 126 4.3.3.6 Coexistence of the different solutions ___________________________- 126 4.3.4
Co-ordination of transport and application session setup _______________- 127 -
4.4
5.
Conclusions______________________________________________- 128 -
Signalling Design _______________________________________ - 131 5.1
5.1.1
5.1.2
5.1.3
Protocols and their ways to identify sessions. __________________- 131 SIP and SDP’s Session id. Cost sharing and preference level____________- 131 COPS and its “Handle”__________________________________________- 132 Diameter and SAML____________________________________________- 133 v
5.1.3.1 Diameter aggregation of sessions_______________________________- 134 5.1.3.2 Distribution of user profiles and single sign-on: SAML _____________- 136 5.1.3.3 Diameter messages employed in this thesis _______________________- 138 5.1.4
PANA and IPSEC______________________________________________- 138 -
6.
5.2
Terminal registration. SAML and “QoS registration” __________- 139 -
5.3
Setup and propagation of transport sessions___________________- 143 -
5.4
Application and transport sessions, MMSP scenario ____________- 147 -
5.5
Non-MMSP assisted scenarios: user and VASP ________________- 152 -
5.6
Conclusions______________________________________________- 155 -
Validación _____________________________________________ - 157 6.1
Escenarios / Implementación _______________________________- 157 -
6.2
Validación del simulador___________________________________- 163 -
6.2.1
6.2.2
6.3
6.3.1
6.3.2
6.3.3
6.3.4
6.4
7.
Pruebas _________________________________________________- 171 Tasa de llamadas soportada por el sistema __________________________- 172 Respuesta ante un pico de llamadas ________________________________- 178 Heterogeneidad en las capacidades. Cuellos de botella_________________- 182 Momento de realización de la reserva de QoS________________________- 186 -
Conclusión ______________________________________________- 186 -
Conclusions and Future Work _____________________________ - 187 7.1
8.
Pruebas “individuales” __________________________________________- 163 Pruebas generales ______________________________________________- 167 -
Research avenues and forecast for our proposal _______________- 190 -
Referencias_____________________________________________ - 193 -
vi
INDICE ABREVIADO
1.
2.
3.
4.
5.
6.
7.
Introduction and Objectives ________________________________ - 13 1.1
Overal objectives __________________________________________- 15 -
1.2
Thesis phases _____________________________________________- 17 -
1.3
Resources employed________________________________________- 18 -
1.4
Document outlook _________________________________________- 19 -
State of the Art Analysis; Research Opportunities_______________ - 21 2.1
Session setup techniques ____________________________________- 21 -
2.2
IMS _____________________________________________________- 36 -
2.3
4G networks ______________________________________________- 46 -
2.4
Conclusion. Research opportunities and thesis objectives_________- 54 -
Análisis del Problema: Dispersión de las Sesiones ______________ - 57 3.1
Diversidad de entidades y de sesiones _________________________- 57 -
3.2
Modelos de negocio, análisis de requisitos______________________- 67 -
3.3
Interacción con el proveedor de red. Cohesión de las sesiones _____- 79 -
3.4
Conclusiones______________________________________________- 89 -
Proposed 4G Architecture & Session Setup Support _____________ - 91 4.1
4G Systems involved in session setup __________________________- 92 -
4.2
Architecture of the 4G systems involved in session setup ________- 104 -
4.3
Session setup possibilities in the proposed architecture __________- 117 -
4.4
Conclusions______________________________________________- 128 -
Signalling Design _______________________________________ - 131 5.1
Protocols and their ways to identify sessions. __________________- 131 -
5.2
Terminal registration. SAML and “QoS registration” __________- 139 -
5.3
Setup and propagation of transport sessions___________________- 143 -
5.4
Application and transport sessions, MMSP scenario ____________- 147 -
5.5
Non-MMSP assisted scenarios: user and VASP ________________- 152 -
5.6
Conclusions______________________________________________- 155 -
Validación _____________________________________________ - 157 6.1
Escenarios / Implementación _______________________________- 157 -
6.2
Validación del simulador___________________________________- 163 -
6.3
Pruebas _________________________________________________- 171 -
6.4
Conclusión ______________________________________________- 186 -
Conclusions and Future Work _____________________________ - 187 7.1
8.
Research avenues and forecast for our proposal _______________- 190 -
Referencias_____________________________________________ - 193 vii
INDICE DE FIGURAS
Figure 1: Possible signalling protocol modes ____________________________________________ - 22 Figure 2: Yes/No signalling – Single Configuration _______________________________________ - 23 Figure 3: Low granularity signalling – SLA like signalling__________________________________ - 24 Figure 4: Fine granularity signalling – Parameter level signalling ___________________________ - 25 Figure 5 SIP Basic Call Setup_________________________________________________________ - 29 Figure 6 SIP signalling proposed in RFC 3312 to coordinate application and network setup ______ - 35 Figure 7 IMS architecture ____________________________________________________________ - 37 Figure 8 IMS session setup, interaction with AAA (Accounting) ______________________________ - 40 Figure 9 IMS session release, interaction with AAA (Accounting) ____________________________ - 41 Figure 10 IMS session setup, interaction with QoS ________________________________________ - 43 Figure 11 IMS session tear down, interaction with QoS ____________________________________ - 44 Figure 12 ETSI-TISPAN NGN Architecture ______________________________________________ - 46 Figure 13 A QoS enabled interface in a router ___________________________________________ - 48 Figure 14 an example of QoSBroker functionality, MSC ____________________________________ - 49 Figure 15 Diameter Protocols organisation______________________________________________ - 50 Figure 16 Gross' architecture for inter-domain QoS and AAA enabled SIP communications _______ - 54 Figure 17 escenario: sesiones desde el punto de vista de los usuarios _________________________ - 60 Figure 18 Clasificación propuesta de los parámetros negociados en el establecimiento de sesión___ - 61 Figure 19 escenario: sesiones desde el punto de vista de un proveedor de servicio_______________ - 64 Figure 20 escenario: sesiones desde el punto de vista del proveedor de red ____________________ - 66 Figure 21 escenario: sesiones desde el punto de vista del mediador __________________________ - 67 Figure 22 VAS en el mercado de las telecomunicaciones ___________________________________ - 69 Figure 23 Business relations in the internet business model _________________________________ - 70 Figure 24 Business relations in the “walled garden” business model _________________________ - 71 Figure 25 business relations in the “semi walled garden” business model _____________________ - 72 Figure 26 sessions handled by the QoS system____________________________________________ - 94 Figure 27 sessions handled by the MMSP _______________________________________________ - 95 Figure 28 AAA system interactions _____________________________________________________ - 98 Figure 29 sessions handled by the AAA system ___________________________________________ - 99 Figure 30 AAA-QoS proposed interaction ______________________________________________- 103 Figure 31 Hierarchical network topology ______________________________________________- 106 Figure 32 Triggers in the AN-QoSBroker to setup a QoS enabled transport session _____________- 110 Figure 33 Triggers in the AN-QoSBroker to tear down a QoS enabled transport session _________- 110 Figure 34 QoS system interactions ____________________________________________________- 111 Figure 35 MMSP interactions. Dashed, intra domain communication; solid inter domain. _______- 113 Figure 36 AAA system interactions ____________________________________________________- 116 Figure 37 MMSP driven transport QoS session setup. Setup is propagated by the AN-QoSBrokers_- 125 Figure 38 MMSP driven transport QoS session setup. Setup is propagated by MMSPs __________- 125 Figure 39 Registration processes _____________________________________________________- 140 Figure 40 MIP registration __________________________________________________________- 141 Figure 41 AAA registration and assertion "push” to AN-AA________________________________- 142 Figure 42 “Transport service” registration. Explicit QoS request ___________________________- 143 Figure 43 QoS session setup. Explicit request sent by terminal. 1st AN________________________- 144 Figure 44 QoS session setup. Explicit request sent by terminal. 2nd AN _______________________- 145 Figure 45 Implicit QoS request and AAA-QoS interaction _________________________________- 147 Figure 46 Session setup. AAA, MMSP and QoS interworking. Caller side _____________________- 150 Figure 47 Session setup. AAA, MMSP and QoS interworking. Callee side_____________________- 151 Figure 48 Session setup in a non-MMSP supported VASP scenario __________________________- 153 Figure 49 Session setup in a non-MMSP supported VASP scenario. Terminal setting QoS sessions - 154 Figure 50 Escenario de simulación. Un AN (izquierda), un CN y la “Internet” (derecha) ________- 161 Figure 51 Cálculo del tiempo de procesamiento en cada nodo ______________________________- 162 Figure 52 escenario ns2 para pruebas de validación _____________________________________- 164 Figure 53 Mensajes impresos por los distintos nodos al hacer una llamada. Nótese como la llamada se
considera establecida cuando el llamado recibe el ACK, evento que sucede antes de que el ANQoSBroker reciba el mensaje RPT ____________________________________________________- 165 Figure 54 Trazas ns realizadas en los terminales (llamante y llamado) junto con la interpretación de los
mensajes y el análisis hecho por nuestra herramienta (tiempo de inicio y duración del establecimiento de
la llamada) _______________________________________________________________________- 166 viii
Figure 55 Trazas ns realizadas en los AN-AA (en este caso el mismo para llamante y llamado) junto con
la interpretación de los mensajes y el análisis hecho por nuestra herramienta (tiempos de recepción y
envío del mensaje) _________________________________________________________________- 167 Figure 56 Enlaces CN-Internet atravesados para el caso 1 ________________________________- 168 Figure 57 Enlaces CN-Internet atravesados para el caso 4 ________________________________- 169 Figure 58 Enlaces CN-Internet atravesados para el caso 3 ________________________________- 169 Figure 59 tiempo de procesamiento en el CN-AAA _______________________________________- 171 Figure 60 Tiempo de establecimiento de llamada. Condiciones de saturación. MMSP ___________- 172 Figure 61 Tiempo de procesamiento en un AN-AA. Condiciones de saturación. Estrategia MMSP _- 173 Figure 62 Tiempo de procesamiento de los mensajes en un AN-MMSP. Condiciones de saturación.
Estrategia MMSP__________________________________________________________________- 174 Figure 63 Tiempo de procesamiento de los mensajes en un AN-MMSP. Condiciones de saturación.
Estrategia MN ____________________________________________________________________- 175 Figure 64 Tiempo de establecimiento de llamada. Estrategia “MMSP"_______________________- 177 Figure 65 Tiempo de establecimiento de llamada. Estrategia “MMSP" (2) ____________________- 177 Figure 66 Tiempo de establecimiento de llamada. Estrategia “MN” _________________________- 177 Figure 67 Tiempo de procesamiento de los mensajes en el AN-MMSP. Estrategia MMSP ________- 178 Figure 68 Establecimiento de llamada (extracto). Pico de llamadas. Estrategia “MMSP"________- 179 Figure 69 Tiempo de establecimiento de llamada. Pico de llamadas. Estrategia “MMSP"________- 179 Figure 70 Tiempo de establecimiento de llamada (extracto). Pico de llamadas. Estrategia “MN"__- 179 Figure 71 Tiempo de procesamiento en el AN-MMSP. Pico de llamadas. Estrategia MMSP ______- 180 Figure 72 Tiempo de procesamiento de los mensajes en el AN-MMSP. Estrategia MN __________- 181 Figure 73 Tiempo de procesamiento en el CN-AAA. Pico de llamadas. Estrategia MN __________- 182 Figure 74 Establecimiento de llamada. 4 colas en el AN-MMSP. Estrategia MMSP_____________- 184 Figure 75 Tiempo de procesamiento de los mensajes en el AN-MMSP. Pico de llamadas y 4 colas en el
AN-MMSP. Estrategia MMSP________________________________________________________- 185 -
ix
INDICE DE TABLAS
Table 1 The SIP messages (or methods) _________________________________________________ - 28 Table 2 Some of the SIP responses (status codes) _________________________________________ - 29 Table 3 Perfil de usuario con un proveedor de red (NVUP) _________________________________ - 76 Table 4 Perfil de usuario con un proveedor de contenidos __________________________________ - 77 Table 5 Perfil de usuario con un proveedor de espacio de archivo____________________________ - 77 Table 6 contratos involucrados cuando los interlocutores hacen la reserva de red _______________ - 81 Table 7 Niveles de la negociación, cuando los interlocutores hacen la reserva de red ____________ - 82 Table 8 Reparto de costos de la sesión cuando los interlocutores hacen la reserva de QoS ________ - 84 Table 9 Reparto de costos de la sesión cuando los interlocutores hacen la reserva de QoS. 2 ______ - 84 Table 10 contratos involucrados cuando un interlocutor es proveedor de servicios ______________ - 84 Table 11 Niveles de la negociación, cuando un interlocutor es proveedor de servicios____________ - 85 Table 12 contratos involucrados cuando un mediador asiste a los interlocutores ________________ - 86 Table 13 Niveles de la negociación cuando un mediador asiste a los interlocutores ______________ - 86 Table 14 Reparto de costos de la sesión cuando un mediador asiste a los interlocutores __________ - 86 Table 15 Ways to orchestrate MMSP, QoSBroker and AAA interactions ______________________- 120 Table 16 Ways to orchestrate MMSP, QoSBroker and AAA interactions with the AAA being the sole
network contact point ______________________________________________________________- 121 Table 17 Session aggregation in the AAA server _________________________________________- 136 Table 18 Diameter Messages ________________________________________________________- 138 Table 19 Casos de llamada en función de la situación. ____________________________________- 159 Table 20 Simplificación de los casos de simulación_______________________________________- 160 Table 21 Casos simulados en nuestro escenario _________________________________________- 161 Table 22 Mensajes procesados por un CN-MMSP en los distintos escenarios __________________- 163 Table 23 Casos simulados en nuestro escenario, retardo introducido por los enlaces CN-Internet cuando
el tiempo de propagación es 400 ms __________________________________________________- 169 Table 24 Nº de mensajes gestionados por cada nodo. 128 llamadas en el escenario _____________- 170 Table 25 velocidad de procesamiento en los nodos para soportar 64 llamadas/s _______________- 172 Table 26 Tiempo de establecimiento de llamada bajo condiciones de mínima carga_____________- 175 Table 27 Tiempo de establecimiento de llamada con carga máxima antes de tener saturación ____- 176 Table 28 Velocidad de proceso de las 4 colas del AN-MMSP _______________________________- 183 Table 29 tiempos medios de establecimiento de llamada –en condiciones estables-. _____________- 186 -
x
GLOSARIO
A4C, AAAC, AAAAC,
AAA
AAA Authentication, Authorisation, Accounting (AAA), Auditing and
Charging
AD
Administrative Domain
AN
Access Network
AN-AA(A)
Access Network Accounting and Authorization Server
AN-QoSBroker
AN-QoSB
Access Network Quality of Service Broker
AR
Access Router
CCF
Charge Collection Function
CID
Charge Identifier
CMS
Central Monitoring System
CN
Core Network
CN-AAA
Core Network Authentication, Authorisation, Accounting Server, or AAAServer
COPS
Common Open Policy Signalling
CN-QoSBroker
CN-QoSB
Core Network Quality of Service Broker
CR
Core Router
CSCF (P-CSCF, SCSCSF, I-CSCF)
Call Service Control Function. Proxy, Server, Interrogating
DiffServ
Differentiated Services
DSCP
Differentiated Services Code Point
ER
Edge Router
FHO
Fast Handover
HD
Home Domain
IMS
IP Multimedia Subsystem
IntServ
Integrated Services
MMSP(P)
Multimedia Service Provision Platform
MSC
Message Sequence Chart
MT, MN
Mobile Terminal, Mobile Node
nAR
New Access Router
xi
NME
Network Monitoring Entity
NVUP
Network View of User Profile
oAR
Old Access Router
PBNMS
Policy-Based Network Management System
PDF
Policy Decision Function
PDP
Policy Decision Point
PEP
Policy Enforcement Point
PHB
Per Hop Behaviour
QoS
Quality of Service
RSVP
Resource Reservation Protocol
RTMS
Real Time Monitoring System
RTP/RTCP
Real Time (Control) Protocol
SDP
Session Description Protocol
SIP
Session Initiation Protocol
SLA
Service Level Agreement
SNMP
Simple Network Management Protocol
SP
Service Provider
SVUP
Service View of User Profile
TSpec
Traffic Specification
UA (SIP-UA)
SIP User Agent
VAS(P)
Value Added Service (Provider)
xii
1. Introduction and Objectives
It is foreseeable that in the future the circuit switched telephone –fixed or
mobile- networks will converge, or, better, migrate, into the Internet packet switched
network. Currently, we can already use, over the internet, the applications that were
normally employed in the telephone networks. For instance the Deutsche Telekom
cellular clients in Germany can connect to the internet and since recently they can use
the Skype application to do their voice calls via the internet and not via the cellular
telephone network [SPI02].
Vinton Cerf’s, one of the “fathers” of today’s Internet, in a statement on a recent
interview for the Spanish Journal “El Mundo” [MUN05], supported this view. Due to its
relevance, we translate the following excerpt:
Interviewer: “Do you believe that VoIP will replace the telephony we are used
to? Do you believe that every information transmission will use the Internet?”
Vinton Cerf: “It has no sense to keep two different networks if there is enough
capacity and quality to merge them.”
Even more, network operators such as NTT are already driving its efforts to this
convergence. NTT offers Freedom of Mobile Multimedia Access (FOMA) [FOMA], it
was the first 3G service worldwide. FOMA supports a connection to the Internet via
cellular phones. Over this connection, the users can enjoy the classical telephone
network services like voice calls. NTT forecasts [SCH02] that by 2010, the biggest
revenue will come from Internet based services and no longer from cellular network
ones.
We believe that two are the motivations that are driving this change. First it will
spare costs to the network operators since, instead of managing two different networks,
they will need to handle one single network. Second, it will increase revenue since, due
to the open characteristic of the Internet, it is very easy to build more and better services
upon it and to offer them to the users who will then expend more money. But this
convergence is full of challenges. First, the services offered today in mobile and fixed
telephone networks should be moved -with the same or better performance- to the
Internet. This is far from being simple due to the very different technical natures of the
telephone and the Internet networks. On the other hand, business-related aspects pose
also serious constraints to this convergence. For instance, although the above mentioned
- 13 -
A. Cuevas
Tesis Doctoral
openness of the Internet is positively seen as a source for increased revenue, networks
operators fear to loose their central role in the provision of services, particularly in
telephony or SMS services. If care is not taken the network operators may become mere
“bit pipes”.
Many approaches and ideas, sometimes quite different but, nevertheless, valid
exist to make this migration come true. This exciting and hot research area is known
under the generic term of “4th Generation networks”. There is not yet a clear concept
of what a 4G (4th Generation) network will be; but, broadly speaking, we can say it will
be an IPv6 Internet like network [COM05] with extra features; some, such as mobility,
coming from today’s telephone networks. Also any access technology –wired or
wireless- will allow the user to connect to these 4G networks [WIR04]. Research
projects in 4G networks concentrate on several aspects such as providing QoS, mobility
and fast handovers, AAA (Authentication, Authorization, Accounting), etc. in IP based
4G networks; All these aspects are hard to provide in IP based networks since they were
not designed for this. Until 4G networks are ready, an “intermediate” system, known as
UMTS (Universal Mobile Telecommunication Service) or 3G (3rd generation) has been
developed and is already under commercial use.
One of the topics still to be properly handled in 4G networks is the question of
session setup. When two or more users want to establish a session between themselves
(for instance to begin a voice call) they need, among others, to agree on the quality and
on who will pay. It is true that available solutions partially cover these aspects. Among
them is the SIP (Session Initiation Protocol) [RFC3261] which is widely used. With
SIP, two users can agree on the codecs they will employ and that will determine the
quality (e.g. in voice or video) they will experience during their session. Depending on
the codecs chosen the users will require from the network different “transport”
capabilities. If SIP is used to negotiate the setup of sessions at “application level”, there
are also protocols to setup sessions at “data transport” level, for instance RSVP
[RFC2205]. But there is not yet a clear way to integrate both into a common framework
taking into account issues such as users’ profiles or tariffs and with characteristics like
single sing-on. These shortcomings arise certainly from the fact that we need to
negotiate at two different levels: service and transport and that the business entities
offering the service and the transport may be different. This is a key issue in the
development of 4G networks and, in the session setup aspect, it is of special relevance.
This integration between service and transport in session setup is, among others, one
of the key points the network operators have to achieve being in the core of the value
chain of the telecommunications business. However, we can not go back to classical
telephone network model, where transport and service are combined. It is just the
opposite, we must go to an Internet like model where transport and service are separated
and we have to define the correct interaction between them.
We think that decisions and solutions in this field must be available as soon as
possible, since this migration is already happening, sometimes out of the control of the
network operator. For its good insight into this problem we translate and comment an
article that appeared in the Spanish journal “Cinco Días” [CDI05]. The article begins
with a quotation from Niklas Zennstrom, founder of Skype: “paying for telephone calls
is history”. Further on, the importance of Skype, a company that developed a program
to do voice calls over the internet, is highlighted: Ebay bought it paying about 2 100
millions euros. The article also analyses the market in the USA and Europe. “Last year
Internet telephony accounted for 232 million dollars revenue in the USA and this
- 14 -
Introduction and Objectives
revenue should increase till 4 800 millions in 2009. In Europe, it is estimated that
Internet telephony has diminished by 25% the revenues of traditional telephone network
operators”
1.1 Overal objectives
The objective of this thesis is to contribute to design suitable session setup
solutions in 4G networks integrating both application and network layer aspects and
services. Integrating those aspects in session setup implies, actually, to integrate the
applications and the network transport services. Our challenge is that the Internet
model of complete separation between transport and applications will be kept. Our
solutions will position the network operator in the core of business chain, thus giving an
answer to the urgent needs just presented.
First let’s define the concept of session. The encyclopaedia Britannica defines a
session, among others, as “a meeting or period devoted to a particular activity”. This
same encyclopaedia defines a service as “useful labor that does not produce a tangible
commodity”. We can thus term as services, voice calls, e-mail, web browsing, etc. We
will say that a session is the instantiation of a particular service. The session setup
includes all the means so that the service can be instantiated. A service can be formed of
different subservices (like a video call, it can be formed of the audio and video
services). Likewise, sessions can be composed of several subsessions.
In telecommunications, sessions can cover many aspects and mainly in pervasive
environments. In this thesis we will focus on application (actual “services”) and
transport (the telecommunication service that exchanges the information between the
different parties participating in a session). Besides, this thesis will concentrate on
session setup aspects and the orchestration between the different systems, subservices and business entities. It will not focus on other aspects such as session
mobility. Neither will we analyse deeply multiparty calls. However our design will
allow to integrate these aspects in similar ways as they are integrated today.
As the framework of our thesis is 4G networks we need to analyse the different
approaches to 4G networks and propose or choose a 4G architecture where we will
apply our design.
To orchestrate the different entities participating in the session setup, several
aspects need to be covered. Those include signalling, handling of user profiles, division
of tasks and functionality, etc. All this will be done in our proposed 4G framework.
The interaction between application and network layer implies an interaction
between service and network providers so it is important to study the different possible
business models between users, network providers and service providers. We need to
define how these business models can be provided in the proposed architecture and the
technical requirements (such as messages exchanged between the elements) to support
them.
If we focus again on session setup, our goal is to propose several approaches,
compare and evaluate them (including by the means of simulation). We aim to obtain
a solution where the session setup between users is assisted by proxies. Those proxies
either pertain to the network operator or have a business agreement with it. That way the
- 15 -
A. Cuevas
Tesis Doctoral
network operator will keep playing a fundamental role in the provisioning of services
(besides being a mere bit pipe). This issue is fundamental for 4G networks to become a
reality. The reason is that the network operators will be the key driver in the movement
to 4G networks and they will favour such a change only if they keep the central role in
the provisioning of services, as we propose in our model.
Our goal is challenging since users could employ (e.g. to establish voice calls
between them) peer to peer communications or applications assisted by proxies with no
relation with the network provider. In those scenarios the network operator is just a bit
transporter. If the network provider aims to offer added value services to its costumers it
must entice them to use its service infrastructure and not the applications servers
widespread in the Internet. The advantages that can be offered to the users can be
twofold, either cost saving (paying less) or having better quality (e.g. more valuable
services or best video quality). To reach so, our design must be open enough to offer
any kind of service, it must offer them with the best quality and yet it must be simple
enough to require few managing cost from the operator. To achieve such requirements
may be a difficult task and may need a clever design, evaluation and comparison as it
will be done in this thesis, focussing on the session setup aspects.
As we have stated, the objective of this thesis is to contribute to design suitable
session setup solutions in 4G networks. They will encompass interaction between users,
network providers and services providers. Several approaches will be proposed,
analysed, evaluated and compared. The main milestones of this thesis could be:
Analysis and enhancement of the existing session setup protocols. We will
focus mainly on SIP and H323. We will also tackle SDP (and SDPng) [RFC3264]
[OTT05], which is a session description language, to evaluate how well are they suited
to describe session-setup-negotiation related aspects. Others approaches will be also
evaluated. This point can be divided into two sub-objectives:
•
Analysis and Enhancement of the Session Description Languages: We will
examine the parameters they can describe, focussing on QoS and pricing
aspects. If they lack information on some of these facets we will propose
ourselves the needed information.
•
We will also analyse the capabilities of session setup protocols to coordinate the
session setup with network setup: session setup at application level must be
paired with setup at network level, otherwise, for instance, the participants may
have agreed on the session and be ready to communicate, but the network may
not be ready yet to “accommodate” their data. The extensions to SIP [RFC3312]
to allow preconditions will be analysed. They are focused on QoS and we will
see the possible ways to extend them to other aspects such as AAA. Special care
must be taken in scenarios were caller and callee have very different profiles.
Analysis of 3GPP’s IMS: Integration of application service and network layers
session setup. We will see how the IMS model proposes a way to integrate SIP services
into a telecommunications operator infrastructure. We will parallel it to possible 4G
solutions. First we will examine the business model(s) considered which are of special
interest since they put the network operator in the core of the service provisioning. We
will check if these business models can accommodate to the 4G “open” networks. Then
we will tackle technical aspects. We will analyse the different architectural elements,
- 16 -
see if they may fit with 4G networks or they are too specific to 3G ones. We will see the
processes defined (registration, session setup, …) and the messages exchanged, paying
special attention if they follow the existing protocols (SIP, COPS, DIAMETER). We
will analyse if these processes could be exported to 4G scenarios. Finally we will see
aspects not sufficiently covered in the IMS and that will need to be addressed in 4G
networks.
Analysis of 4G networks and proposed framework: First, we will find the
common points of the different approaches to 4G networks to try to give a definition of
what a 4G network is and we will also present our own view. Once this is done, we will
focus on key aspects that are present in 4G networks like mobility, QoS and AAA and
how they are intended to be solved, we will also give our view and see the degree the
different approaches match with existing IETF solutions. Based on this, we will propose
the framework architecture that will be considered in this thesis. We will focus on
aspects such as QoS, AAA, service providers, session setup proxies, etc.
Discussion and integration of different business models. Several business
models will be analysed, focusing on the model proposed by the 3GPP. Within the
3GPP model we will concentrate in the IMS framework. However other business
models will also be considered. Those may target different business scenarios or
applications. Our goal is to integrate all the business models in a coherent 4G
framework.
Proposals for session setup in 4G networks: based on the IMS analysis
previously done, we will design session setups solutions for our 4G network design. We
will analyse existing 4G solutions and will propose new ones. We don’t aim to provide
one single solution, but to offer several choices and compare them. Aspects such as the
number of messages to be sent in the access network (radio, ADSL, …), possible
bottlenecks, time to establish a session in each approach, network and processing load
introduced, their response to congestion situations (like massive number of calls trying
to be established), how there are suited to deal with user mobility or with multiparty
calls, etc. will be analysed. As we will see next, an important tool to do so is simulation.
As a result, a complete characterization of the different approaches will be given and
network operators will have the criteria to choose the one that best fits their needs.
Evaluation and validation: We stress again that besides proposing several
solutions we will analyse their pros and their cons under different scenarios and
situations. One of the means to do so will be simulation. Simulation will be of much
value since the two other approaches (mathematical model and measurements in a
prototype test bed) to evaluate a proposal are difficult to do. Concerning the
mathematical model, it would be too costly because a lot of interactions would need to
be considered. Respect to the prototype test-bed two are the issues that make this
approach difficult, first, as it is obvious, the test bed must be implemented, which is
costly. Second, to evaluate scalability and performance issues, several users (from
dozens to hundreds) will need to be present in the test bed to emulate the conditions
(million of users) that will appear in public 4G networks.
1.2 Thesis phases
To achieve the mentioned objectives the next steps will be followed.
- 17 -
A. Cuevas
Tesis Doctoral
•
First the existing session setup protocols will be studied and special care will be
taken to the extensions they may support to negotiate QoS or handle AAA
aspects. IETFs QoS architectures –focusing on the processes needed to request
QoS (even if they are not defined by the IETF)- and AAA and mobility solutions
will be analysed.
•
Next we will focus on the IMS solution that integrates some of the mentioned
aspects under a 3GPP architecture and we will see which aspects are not covered
by it.
•
The step beyond IMS is 4G networks, which shall integrate many aspects under
their architecture. We will study the different approaches, find their weak and
strong points and propose our own 4G architecture.
•
At this point, we should have defined our framework and within it we will try to
contribute to find solutions for session setup in 4G networks. Those solutions
will be built upon our framework but should not be tied to it and be, whenever
possible, applicable to other approaches. Major work will be done in this step,
since we will propose several solutions and evaluate and compare them.
•
Finally, to help to evaluate and compare our proposals we will use simulation
tools. We first have to build a simulation model and see whether, despite the
simplifications done, if the model is still valid to compare and evaluate our
approaches. Once the simulation model is built we will test it to see if it was
correctly implemented. Finally we will do the required tests over it, extract
results and analyse them.
1.3 Resources employed
This thesis is mainly a study and a contribution to find proper solutions for
session setup in 4G networks. It is not the objective to implement the proposed solutions
(only a few limited aspects). The solutions will, nevertheless, be evaluated and
compared using simulation tools.
State of the art documents were gathered thanks to the Carlos III University’s
and Telematic’s department library services. Online access to several magazines was
also available and used.
We help ourselves with simulation tools –building the simulation model- to
accomplish this task. To do so, we required simulation tools and computers to run the
simulation in. As we will detail, ns2 was the most suited simulation tool, it is freely
available and was our choice. We run the simulations in a Linux based Pentium-4 PC.
For the prototype implementation of some of the aspects defined an IPv6
network with at least two mobile nodes, one access router and some “servers” such as
SIP proxy or AAA server will be needed.
Finally, for UML modelling “Telelogic Tau” was used. Offimatic tools such as
Microsoft Word were also made available by the Telematics Department.
- 18 -
1.4 Document outlook
Chapter 2 will summarize the work carried out in the research fields related to
this thesis. Emphasis will be made in the 3GPP-defined IMS framework integrates some
of these research results under a coherent “umbrella” and achieves a business model that
places the network operator in the core of the business value chain which, as we have
seen, one of the driving objectives of this thesis. However IMS must be extended to 4G
and as we will see in this chapter there are still many gaps and shortcomings. Those
shortcomings bring the research opportunities to this thesis and justify the objectives
presented in the introduction.
Chapter 3 will analyze the problems derived from today’s “Internet” business
model. We will focus on the split of subsessions between the different entities. The
future business models, along with their advantages will be presented. Their
requirements for session setup will be analyzed. The ways to correlate the different
subsessions will be presented, focusing on users profiles, contracts, business
relationship with the users and different negotiation levels (application and transport).
This will be the key point to understand the session setup signaling design described in
chapter 5.
Chapter 4 proposes the design of the 4G architecture where our session setup
solutions are developed. The endpoints of the signalling, nodes and systems, are
identified and their role is described. Several design solutions are presented and
evaluated. Since different scenarios have to be supported in the same architecture,
different proposals have to coexist and some systems and nodes need to play different
functionalities. The ways to orchestrate the various systems is presented.
Chapter 5 describes in a straight forward way the signalling and the protocols.
Chapter 3 and 4 have provided already the basis to understand our solutions and chapter
5 gives the level of detail necessary to understand completely our design. Different
proposals will also be presented and evaluate. Signalling will be the basis for the overall
evaluation done in chapter 6.
Chapter 6 will deal with the simulation based evaluation of the several proposed,
all integrated in a complete session setup framework. This evaluation will be
quantitative and pretends to identify issues such as scalability and bottlenecks.
Finally, the conclusion gathers the main results and contributions of this thesis.
The way the objectives presented in this introduction are fulfilled will be detailed. The
research areas still open or resulting from this thesis will be explained.
This thesis is part of the Communications Technologies Doctorate in
“Universidad Carlos III de Madrid”. It will apply for a “European amendment”
(“mención Europea”) in the Ph.D. Diploma. Following the rules, part of this thesis is
written in English and part in Spanish.
- 19 -
2.
State of the Art Analysis; Research Opportunities
In the introduction we presented the strong motivations to move to 4G networks.
As a result, the research efforts being done in the area of 4G networks are huge. This
section aims to analyse them, see the goals they fulfil and their shortcomings, focusing
on session setup aspects. As 4G networks will inherit many mechanisms from the IETF,
IETF’s existing and under-development protocols will also be analysed in this section.
It is also important to study 3G solutions and, namely, the IMS and see which of their
aspects can be profitable for 4G networks.
2.1
Session setup techniques
This section will review the current session setup approaches, mainly developed
within the IETF. It will first describe the existing solutions, focusing on application
session setup and not dealing with their integration with network setup and 4G
networks. Then, we will analyse their shortcomings –like lack of capability to negotiate
the price of the session- and the research efforts being done. Finally, we will concentrate
on how these session setup solutions are being integrated with network setup.
2.1.1 Session setup models
Several are the general mechanisms to setup a session between nodes
[RFC2326], [BOS02], [RFC3264]. The main criterion for classifying them are the
number of roundtrips required to complete the negotiation and the complexity of the
parameters to be negotiated [MIND02]. Of course, these two aspects are related. In this
section we will summarise the classification study done in [MIND02]. This analysis is
important to better understand the different state-of-the-art session setup techniques and
when we study them we will refer to the classification done in this section. When we
propose modifications to these state-of-the-art session setup techniques, this
classification will also help to better understand them.
The different modes to setup a session between nodes depend mainly on the
expressiveness of the parameters to be negotiated to establish the session. The
complexity of the session signalling depends on the intelligence of the applied
protocols, i.e. if one or many session configurations can be exchanged with a single
request/response, if the response to a request can detail the reason for having exactly
- 21 -
A. Cuevas
Tesis Doctoral
such response and how exact and detailed is the description format for defining the
session/system configurations. This leads to the so-called negotiation modes (Figure 1):
•
Push Mode – The peer, which initiates the negotiation process, makes also the
initial proposal (i.e. Offer) about the media-session configuration parameters.
The reply to this proposal is a subset of parameters, applicable also at the
negotiation partner for opening and supporting a multimedia session(s). This
mode corresponds also to the proposal of the basic “Offer/Answer Model”.
•
Pull Mode – The negotiation-initiating peer begins with a query to its partner
about the supportable capabilities and QoS parameters. This is conducted in
order to adapt the initiator’s request according to the proposed configurations of
the negotiation peer. This mode can be applied by querying automatic services
upon their parameters, since they cannot support any arbitrary configuration
proposed by their users and it is up to the users to fit their request to some
predefined profiles of the service.
•
Push-Pull Mode – For this mode the initiator of the negotiation also delivers the
final results from the negotiation. This mode enables the partner by receiving an
offer from the initiator of the negotiation to actively express also its request(s) to
the initiator. The push-pull scenario corresponds to the enhanced “Offer/Answer
Model”. This mode can be used for independent configuration of unidirectional
streams belonging to the same media session, i.e. a given “Peer A” may be a
“sender” of a stream to “Peer B” and simultaneously a “receiver” of another
stream from “Peer B”. These streams can be bound with mutual constraints,
expressed in a Counter-Offer with the final negotiation result.
Figure 1: Possible signalling protocol modes
Concerning the complexity of the parameters to be negotiated, the following
three scenarios consider the overhead for service/session/QoS signalling in accordance
with the described above general protocol modes.
Cero Granularity Signalling
In this scenario (Figure 2) End-system A (Offerer) asks End-system B
(Answerer) if the configuration X (just a single configuration) can be supported by the
End-system B. The answer of End-system B can be Yes (End-system B can support the
- 22 -
configuration proposed by End-system A) or No (End-system B cannot support the
configuration proposed by End-system A). This corresponds to the Push mode of the
above described options. The interactions marked red (bottom arrows in Figure 2) are
interactions to provide protocol synchronisation (in accordance with the 3 modes above)
and interactions with network internal services to provide AAA and security for the
protocol.
Figure 2: Yes/No signalling – Single Configuration
Compared to the other approaches this one has the following pros and cons:
Pros:
•
This scenario provides the smallest negotiation overhead compared with the
following ones, as only one configuration is sent per negotiation roundtrip
and the answer thereof is short (i.e. “yes/no” or “ACK/NACK”).
Cons:
•
If the Offerer has no initial knowledge about the capabilities of the
Answerer, it is difficult to create initial proposal for the service/session
configuration.
•
The maximum number of roundtrips to reach an agreement is infinite, since
when receiving a decline the Offerer may repeat the negotiation roundtrip
with new parameter.
•
If multiple test and set procedures should be considered, this can increase
essentially the signalling overhead.
•
In the general case it is possible, due to heterogeneity of the peers (i.e.
different hardware/software), that they do not reach an agreement. As the
service/session description model here is too simple it might not come to
communication between peers even if media-transcoder services are
available in the system, since the peers might not have the ability to
negotiate their features with such services or may not be able to define
complex session scenarios (e.g. multi-stream multimedia conference).
Low granularity signalling
- 23 -
A. Cuevas
Tesis Doctoral
In this scenario (Figure 3) End-system A (Offerer) proposes several standard
configurations (i.e. X, Y, Z) to End-system B (Answerer) so that End-system B can
chose one of those. In its answer End-system B indicates which are the possibly
supportable configurations and, finally, End-system A indicates which configuration
would be used to establish a session or to configure the service. This corresponds to the
Push-Pull mode of the above described options. Note that, if in the answer B indicates
only one possible configuration or if A accepts all the proposed configurations, this can
be considered as the result message and thus we will be in the case of Push mode. The
interactions marked red (bottom arrows in Figure 3) are interactions to provide protocol
synchronisation (in accordance with the 3 modes above) and interactions with network
internal services to provide AAA and security for the protocol.
Figure 3: Low granularity signalling – SLA like signalling
Compared to the other approaches this one has the following pros and cons:
Pros:
•
More flexible model (compared to the “Yes/No signalling”) to signal session
establishment or service configuration.
•
Uses multiple, standard descriptions to negotiate configurations.
Cons:
•
Usage of fix format for the configurations (e.g. SIP/SDP). This leads to
several additional problems:
•
Support of terminal/system heterogeneity – This problem concerns the
mapping between different SLA(s). If one terminal does not support features
which the other terminal supports but it is bound to use fix SLA descriptions,
it cannot deliver the information that the terminal can probably partially
support the configuration/s proposed by its partner. The problem is the same
when mapping SLA(s) between different provider domains at vertical
handover.
•
Application of new system features and rules – If the applied format does not
allow to be enhanced, some novel system features cannot be introduced. This
- 24 -
concerns especially novel audio/video codecs and parameterisation of codecs
and the description of complex multi-stream multimedia scenarios.
•
Describing relations between configurations – In audio/video communication
scenarios, it is necessary to support relations between media-streams.
Additionally, adaptation and provider constraints should also be supportable.
•
Exchanging complete sets of information with every negotiation increases
crucially the signalling overhead when managing complex multi-stream
multimedia sessions.
Fine granularity signalling
In this scenario (Figure 4) End-system A (Offerer) proposes several
parameterised configurations to End-system B (Answerer). The End-system B adapts
these configurations to its own requirements and answers to End-system A with a new
configuration or a set of configurations and can also deliver new information about
itself (i.e. T(h, j) on Figure 4). The Answerer can either repeat the configurationdescriptions from the Offer in its Answer and/or can only reference the already known
information sent by the Offerer (e.g. by using a URI-name). The Offerer creates a final
configuration out of the common knowledge of End-system A and End-system B, and
both end-systems use this configuration for session establishment and later on at session
adaptation.
Figure 4: Fine granularity signalling – Parameter level signalling
This kind of service/session signalling has the most complex configuration
description model. Such description model can only be expressed with an appropriate
configuration language. But in comparison with the other two models it can express any
system parameter.
Pros:
•
The negotiation is most flexible, as any granularity (from single parameter to
SLA) is definable.
- 25 -
A. Cuevas
Tesis Doctoral
•
Heterogeneous systems are supportable – End-systems and provider entities
can define any supportable configuration and enhance configurations
according to their specific features and requirements.
•
If there is completely no common configurations between end-systems, they
can still be able to describe their features for translation means when using a
media-transcoder, i.e. having flexible negotiation means the end-systems can
negotiate transcoding capabilities with transcoder services within the
network.
•
The possibility to flexibly enhance configurations by referencing them,
decreases the signalling impact, as it is not necessary to repeat them as in the
“Low granularity signalling” scenario.
Cons:
•
The negotiation is most complex and requires higher processing impact
within the management components of the system to keep track of
exchanged configuration information.
2.1.2 IETF’s RSVP for QoS enabled transport sessions
The Resource Reservation Protocol (RSVP) [RFC2205] was designed to enable
the senders, receivers, and routers of communication sessions (either multicast or
unicast) to communicate with each other in order to set up the necessary router state to
support QoS enabled transport services. It is worth noting that RSVP is not the only IP
reservation protocol that has been designed for this purpose. Others include ST-II
[RFC1190] and ST-II+ [RFC1819]. However, we consider RSVP since currently this
has the most industry support.
RSVP identifies a communication session by the combination of destination
address, transport-layer protocol type, and destination port number. In IPv6 those two
last parameters may be replaced by the flow label. RSVP is used to reserve resources
along the route between the sender and the receiver(s). The primary messages used by
RSVP are the Path message, which originates from the traffic sender, and the Resv
message, which originates from the traffic receiver(s). The primary roles of the Path
message are first to install reverse routing state in each router along the path, and second
to provide receivers with information about the characteristics of the sender traffic and
end-to-end path so that they can make appropriate reservation requests. The primary
role of the Resv message is to carry reservation requests to the routers along the
distribution tree between receiver(s) and sender.
Path message includes, among others, the following:
•
•
The Sender Template, a filter specification identifying the sender. It contains the
IP address of the sender and optionally the sender port (in the case of IPv6 a
flow label may be used in place of the sender port).
The Sender Tspec defining the sender traffic characteristics. It characterises it
with token bucket parameters such as Token Bucket Rate, Token Bucket Size
and Peak Rate
- 26 -
Resv message includes, among others, the following:
•
•
A filter specification, Filterspec. This is used to identify the sender(s), and the
format is identical to that of the Sender Template in a Path message.
A flow specification, Flowspec, comprising the Rspec and Tspec.
o Tspec is usually set equal to the Sender Tspec.
o The Rspec is calculated by the receiver. Rspec describes the actual
reservation parameters for the flow and a traffic specification. It is used
only in a specific QoS reservation type: GUARANTEED. Parameters
include the rate and the Delay Slack Term.
RSVP follows a push mode, with an offer from the sender and the final answer
accepted by the receiver. This answer is normally equal to the offer. This simple
exchange is possible because the parameters that are negotiated are very simple, related
only to transport capabilities.
RSVP can also explicitly shut down the QoS sessions using RSVP teardown
messages. Teardown messages can be initiated by an application in an end system
(sender or receiver) or a router as the result of state timeout. RSVP supports two types
of teardown messages: path-teardown and reservation-request teardown. Path-teardown
messages delete the path state (which deletes the reservation state), travel toward all
receivers downstream from the point of initiation, and are routed like path messages.
Reservation-request teardown messages delete the reservation state, travel toward all
matching senders upstream from the point of teardown initiation, and are routed like
corresponding reservation-request messages.
2.1.3 IETF’s SIP and SDP for application sessions
Several are the IETF’s working groups (WG) dealing with multimedia and
session setup aspects. We will first present them and then describe one of their most
extended solutions for establishing multimedia sessions: SIP and SDP. Actually SIP
and SDP can setup any kind of session, multimedia or not.
The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was
chartered to develop protocols to support Internet teleconferencing and multimedia
communications. It developed, among others, SIP, SDP, RTP (Real Time Transport
Protocol, used to transport multimedia data) and RTSP (Real Time Streaming Protocol,
used for streaming audio and video) protocols. These protocols are now reasonably
mature and many have received widespread deployment. The group is now focussed on
the enhancements of these protocols in the light of implementation experience and
additional demands that have arisen from other WGs (such as SIP and SIPPING).
The Session Initiation Protocol (SIP) working group is chartered to continue the
development of SIP. It will respond to general-purpose requirements for changes to SIP
provided by other working groups, including the SIPPING working group.
The SIMPLE (Sip for Instant Messaging and Presence) working group focuses
on the application of the Session Initiation Protocol (SIP) to the suite of services
collectively known as instant messaging and presence (IMP).
- 27 -
A. Cuevas
Tesis Doctoral
SIPPING (Session Initiation Protocol Project INvestiGation) is a working group
in charge of collecting requirements coming from several institutions (among them
3GPP) and distribute the work to the other working groups.
SIP (Session Initiation Protocol) was first developed within the IETF’s
MMUSIC working group and now is under the umbrella of the SIP Working Group. It
was first defined in [RFC2543] which was replaced by [RFC3261], [RFC3262],
[RFC3263] and [RFC3264]. It is a widely used session setup protocol. Many books and
tutorials exist and the interested reader is encouraged to read them [CAM01], [SIN01],
[JOH03]. SIP enables Internet endpoints (called user agents) to discover one another
and to agree on a characterization of a session they would like to share.
SIP is designed to work over non reliable networks, so each message –also
called methods- must be confirmed by a response with a status code. The sole exception
is the ACK message which has no response. Table 1 and Table 2 list the SIP methods
and the SIP responses.
SIP Method
INVITE
ACK
OPTIONS
BYE
CANCEL
REGISTER
SUBSCRIBE
NOTIFY
MESSAGE
PRACK
Function
Request to initiate a SIP session. INVITE is sent from the calling party to the called
party.
The called party has accepted the call. ACK is sent from the calling party to the
called party. Sole method with no answer.
The calling party is requesting the called party to respond with its capabilities.
Request to terminate the session. BYE can be sent by the calling or the called party.
It is not necessary for the party receiving the BYE to respond with a BYE.
Cancels pending requests.
The calling party wants to register its current location with a registrar server.
The calling party requests an update regarding the presence information of the
called party.
Conveys the updated status of self to subscribed parties of self.
Used to send an instant message.
Use to acknowledge provisional responses see [RFC3264]
Table 1 The SIP messages (or methods)
Status Code
100
180
181
182
200
300
301
305
400
401
402
404
408
415
480
486
500
501
503
600
604
Response Category
Informational (provisional response)
Success
Redirection
Redirection
Redirection
Client Error
Client Error
Client Error
Client Error
Client Error
Client Error
Client Error
Client Error
Server Error
Server Error
Server Error
Global Failures
Global Failures
Response Phrase
Trying
Ringing
Call is being forwarded
Queued
OK
Multiple choices
Moved permanently
Use proxy
Bad request
Unauthorized
Payment required
Not found
Request timeout
Unsupported media type
Temporarily not available
Busy here
Internal server error
Not implemented
Service unavailable
Busy everywhere
Does not exist anywhere
- 28 -
Status Code
606
Response Category
Global Failures
Response Phrase
Not acceptable
Table 2 Some of the SIP responses (status codes)
SIP may make use of elements called proxy servers to help route requests
between the SIP UAs, authenticate and authorize users for services, implement provider
call-routing policies and provide advanced features to users. SIP also provides a
registration function that allows users to upload their current locations for use by proxy
servers. The registration function matches user identification, called SIP URI (similar to
an e-mail address) –see URI (Uniform Resource Identifier) definition in [RFC3986] and
its use in SIP in [RFC3261]- with the devices the user is currently logged in (identified
by their network interfaces IP addresses). Typically, callers will only know one another
URIs and not the IP addresses of their machines, thus the information available to route
the initial sip message is only the SIP URI. For example if the SIP proxy server of
domain “exampleA.com” has to deliver a message to [email protected], it must
first locate –for instance performing a DNS NAPT query, see [RFC3263]- the SIP
proxy server in charge of domain “exampleB.com”
SIP basic operation to establish a call (or any kind of session) is very simple
(see Figure 5). The caller’s SIP User Agent (UA) just has to send a SIP INVITE method
to the callee’s SIP-UA and wait for a positive response (200 OK). Once this answer is
received, the caller sends the callee an ACK message that, we recall, is the sole message
with no answer. At this time the session is setup. To tear down a session, any of the
speakers sends the other a BYE message, the 200 OK positive answer indicates the
session was ended successfully.
SIP User Agent
[email protected]
SIP proxy of domain
exampleA.com
SIP proxy of domain
exampleB.com
INVITE
[email protected]
Look for SIP proxy of
domain exampleB.com
[RFC3263]
Look for userB in the
registrar
200 OK
ACK
Figure 5 SIP Basic Call Setup
Provisional responses
- 29 -
SIP User Agent
[email protected]
A. Cuevas
Tesis Doctoral
In the call setup process we have just described, the “200 OK” response is sent
when the callee “picks up the phone” and answers the call. Besides, this response or
others can also take a while to be sent to the caller because e.g. length processing had to
be done in the sip proxies. If the time to receive the response to the INVITE message (or
to any other method) is too long, the sender may think that his message was lost. To
avoid so, SIP has defined a set of responses “the provisional responses” (see Table 2)
which are sent before sending the final (success or failure) answer. Unlike other
responses, which are only sent by the endpoints, the provisional responses may also be
sent by the proxies. As we will see in section 2.1.6, some of the provisional responses
may be used to convey information –and not just be a provisional acknowledgment to
the reception of a SIP method. Therefore, the delivery of this information must be made
in a reliable way. [RFC3262] faces that problem defining an optional mechanism to
acknowledge the provisional responses. It uses the PRACK (PRovisional ACK)
method.
SIP is a perfect solution to establish multimedia sessions. Its use is today
widespread and it will be the signalling protocol employed in our thesis. But SIP
involves in the session setup only to the caller and callee, aspects like negotiation with
the telecommunication operator to let the media flow through its network are not
covered. For instance, since SIP messages and the sessions they establish can pass
through entirely different networks, SIP cannot, and does not, provide any kind of
network resource reservation capabilities. Before we see in section 2.1.6 the research
efforts being done to integrate SIP and negotiation with network provider during a
session setup, we will describe next the way SIP characterises the parameters of the
session to be negotiated.
SIP very typically uses Session Description Protocol (SDP) [RFC2327] –it is a
description language not a protocol- for describing the multimedia sessions the users are
trying to establish. SDP with SIP uses an offer/answer model (see section 2.1.1 and
[RFC3264]). In this model, one participant in the session generates an SDP message
that constitutes the offer: the set of media streams and codecs the offerer wishes to use,
along with the IP addresses and ports the offerer would like to use to receive the media.
The offer is conveyed to the other participant, called the answerer. The answerer
generates an answer, which is an SDP message that responds to the offer provided by
the offerer. The answer indicates whether the media stream is accepted or not, along
with the codecs that will be used and the IP addresses and ports that the answerer wants
to use to receive media. This interaction corresponds to the low granularity signalling
scenario of section 2.1.1 but with no need of a final answer from the offerer. There is no
need of such a message because it is assumed that the offerer will accept all (or the sole)
the proposals of the answerer.
SDP and all the description languages we will deal with are Application Layer.
It is worth mentioning here that, according to [JIN04], two types of application-layer
features exist: performance-specific and behaviour-specific. We express performancespecific features via quantitative parameters, for example, frame rate and frame
resolution. We express behaviour-specific features via qualitative parameters, for
example, what to do if network bandwidth is scarce. SDP covers the first aspect but not
the second. In typical scenarios, adaptation to varying network conditions is done using
RTCP. RTCP (Real Time Control Protocol) is used in conjunction with RTP and both
are defined in [RFC3550] once the session has been setup. RTP transports the media,
RTCP controls the QoS of the media communication.
- 30 -
Typically, when used on top of SIP, the SDP offer is carried in the INVITE
message issued from the caller to the callee and the answer is present in the reply to this
message (200 OK, if everything is ok), see Figure 5. This corresponds with the push
model of section 2.1.1 or also with the low granularity scenario of this same section but
with no final response from the offerer to the answerer.
As we will see in section 2.1.5, SDP is being extended to support richer session
description. One goal of this thesis is to contribute to this enhanced set of session
description parameters.
2.1.4 H323 and H323 vs. SIP
Before SIP was available, H.323, designed by the ITU, was a quite widespread
solution. H.323 is not a protocol, it’s better an specification that defines the
interworking of several protocols such as H.225, H.245 and RTP. It was first designed
for LAN multimedia conferences. In H.323 we have User Terminals, Multipoint
Control Units, Gateways –to connect to other networks- and Gatekeepers who manage
the session setup. The main drawback of H.323 is that it needs a much higher number
of messages to establish a session than SIP. And this problem is increased if several
domains and several gatekeepers are involved. We have to say that “in compensation”
the H.323 messages are much shorter than the SIP ones, but it’s much better to have a
few long messages than many short. The “Fast Start” method reduces a lot the required
messages in H323 to establish a session but providing that the conferees previously
know some parameters of each other such as ports. This limits, compared to SIP, the
capabilities of the protocol.
Today the most widespread solution is SIP.
2.1.5 Research efforts
Has we have said in section 2.1.2, [RFC3264] chooses SDP and the offer/answer
model for describing the multimedia sessions the users are trying to setup using SIP.
But SDP was not originally conceived for this, instead it was designed for
announcements of multicast multimedia conferences. In this scenario only those
participants supporting the predefined settings could join and there was no need of
negotiation, just the opposite of what happens in the offer/answer model. So SDP had to
be extended to fulfil this new purpose. Moreover, SDP was also extended to include:
•
media descriptions for audio/video streaming (retrieval) controlled by RTSP
(Real Time Streaming Protocol) [RFC2326]
•
media/session descriptions exchanged between Media Gateways and Media
Gateway Controllers as specified in the MEGACO WG.
But SDP falls short in meeting a number of requirements that came up with
these new uses. Numerous workarounds, sometimes heavily bending SDP syntax and
semantics, have been created. Among those extensions, requirements came from the
work on media packetization formats in the AVT Working Group: more complex
descriptions for codecs, codec parameters, and packetization formats were needed in
various places. And, finally, support for multiparty negotiation of capabilities is found
- 31 -
A. Cuevas
Tesis Doctoral
useful. These and other requirements have led to the idea to develop a successor to
SDP. Many research works are being done, inside and outside the IETF.
Before presenting two of these works –SDPng from the IETF and E2ENP- we
will analyse (based on [JIN04]) the characteristics those description languages should
present.
•
Expressiveness: A good QoS specification must be capable of specifying a wide
variety of services, their required resources, and corresponding adaptation rules.
•
Declarativity: A QoS specification should be declarative in nature, so that
applications need not cope with complex resource management mechanisms for
ensuring QoS guarantees.
•
Independence: Specifications should be developed independently from the
functional code for readability and ease of development and maintenance
purposes. Independence also lets developers associate a single application, at the
user’s request, with different QoS specifications.
•
Extensibility: This criterion lets developers evaluate how easily a language can
be extended for specifying new QoS dimensions, such as security, availability,
and responsiveness.
•
Reusability: Reusability is important when QoS specifications become large,
because a new specification might just be an existing one with only minor
refinements. Ideally, a QoS language, like other programming languages, should
have reusable features. One condition necessary to help achieve reusability is
independence. The separation of concern would make both functional and nonfunctional code clean, easy to develop, and easy to maintain.
[JIN04] also classifies application-layer QoS specification languages by their
paradigm; it proposes 7 types but here we will just present 3 of them:
Parameter-based paradigm
This approach describes the QoS using structures. Several types of structures can
be used and within a structure some of its parameters can, on its turn, be another
structure. Structure parameters are mapped into standard protocol fields. SDP follows
this paradigm. The parameter-based approach features a rich set of QoS constructs,
making it good in terms of expressiveness, and we believe new QoS constructs can be
added without too much difficulty. Because QoS parameters and actions are specified as
structures the parameter based paradigm doesn’t provide special facilities for
specification reuse.
Fuzzy control
The fuzzy-control approach lets applications express QoS-aware adaptation
policies and preferences as rules and member functions. Rules are specified in an if-then
format: “if X1 is A1 and… and Xn is An , then Y is B”, where X1 , …, Xn and Y are
parameters corresponding to certain QoS-relevant system conditions such as bandwidth
and CPU, and A1 , …, An and B represent actual values of parameters in the fuzzy form
- 32 -
e.g. “high, low, moderate, or below_average”. An example of a QoS-aware adaptation
rule is “if cpu_availability is very_high and available_bandwidth is very_low, then
rate_demad is compress ,” which tells the system to compress the data because available
bandwidth is low but a large amount of CPU processing power is available. One
limitation of the fuzzy-control approach is that it is intended only to specify actions, not
other QoS properties. This approach is poor in terms of expressiveness and is generally
not sufficient for multimedia applications.
Markup based paradigm
XML is the most widely used markup-based language, so the Markup based
paradigm is equivalent, in practice, to use XML as description language. Besides
SDPng or E2ENP -that will be described next- other XML based QoS description
languages exist. For instance, the Hierarchical QoS Markup Language (HQML)
[GU02] defines a set of tags relevant to QoS of multimedia applications, so that
application developers can define QoS parameters and policies. Tags such as
<ServerCluster>, <ClientCluster> and <LinkList> define the QoS requirements of the
server, gateway, client machines and the properties of the links (for example, fixed link
or mobile link). HQML lets developers specify adaptation rules between the pair of tags
<ReconfigRuleList> and </ReconfigRuleList>. A good feature of HQML is that, due to
XML’s metalanguage property, you can easily extend it to include new QoS parameters.
The language is also good in expressiveness, declarativity, and independence. However,
it doesn’t have any special constructs to facilitate the extension and reuse of existing
specifications.
Within IETF, MMUSIC working group is undertaking the development of the
successor of SDP, SDPng [OTT05]. SDPng will be capable to provide the necessary
semantical expressiveness, syntactical structure and procedures yet will be simple
enough to allow easy implementation. SDPng is a description language which can be
transported over any protocol, but its default “carrier” is SIP and it has been designed to
compile with the 3 way handshake (INVITE, 200 ok, ACK) used in SIP to setup a
session. The flexibility of description for SDPng is provided by using XML as
description format. XML allows the description of complex data relations (e.g. multistream, multimedia session) and to optimise the configuration structure by using
document cross-references. SDPng currently specifies only session capabilities
definitions (it does not, for instance, specify transport QoS) and within one message it
uses only references to this same message (XML document internal cross-references),
which optimises the structure of a single configuration, but not the negotiation process
as a whole. To this extent, SDPng directly follows the approach of the Offer/Answer
Model (see section 2.1.1) and exchanges complete configurations every time a new
negotiation/re-negotiation takes place. Thus, the principal conclusion and criticism is
that SDPng is much more “elegant” (with the price that its XML format makes its
overhead much bigger) than SDP but it offers no significant new functionality
[CAM05].
So further research issues exist. One of them is E2ENP which refines the SDPng
description model by introducing QoS definitions at application and transport level
[RUI04] and optimises further the negotiation model by introducing cross-references
between the XML documents containing different configurations, documents that may
be present in several different set of messages. The main idea is that, previous to the
negotiation, the caller and callee using the SIP method “OPTIONS” exchange their
- 33 -
A. Cuevas
Tesis Doctoral
capabilities including the capabilities IDs. When the SIP negotiation is being done
(following the procedure of [RFC3312] –see section 2.1.6- to support preconditions) the
caller and callee, instead of exchanging the description of their capabilities, they just
exchange these capabilities IDs. The same happens if a renegotiation during the call is
needed to be done. The advantage of exchanging the whole description of capabilities
only in the prenegotiation is that the signalling load can be drastically reduced respect to
SDPng, mainly bearing in mind that this description is done in the verbose XML
format. E2ENP does not change the structure of SIP, but it needs some logical changes
within the SIP User Agent (UA).
Many more specification languages exist, most of them focussing on QoS
aspects, since this is still a hot research topic. We won’t analyse them here, since they
are not so popular as SDPng or E2ENP. But one problem that still needs more research
is to include price parameters in the session setup negotiation. Since in 4G networks
different QoS will imply different tariffs, there is no sense in making the different
parties agree on the QoS of their communication if they don’t agree on the
corresponding tariff. For example, the callee may want the best QoS but does not accept
to pay any share of the cost and the caller may want basic QoS and pay the total cost of
the communication while he will pay only a part of the cost if the QoS of the call is the
best. Work is being done to describe tariffs [HEC02] and also to include tariff
negotiation in the session setup. One of the proposals is to add pricing information in
the RSVP “QoS” negotiation messages [FAN98] but this last work is more focused on
QoS negotiation at transport level and not at application level. We think this is a topic
that needs further investigation and we will focus our description language extension
in pricing and cost sharing aspects.
2.1.6 Coordination of application and network setup
As we have said in section 2.1.2, SIP does not provide any kind of network
resource reservation capabilities. Nor it is prepared to coordinate the session setup with
the network reservation. One extension to SIP, defined in [RFC3312] and summarised
in this section, will fill this gap.
To avoid ghost rings (the user is alerted of a new call but, indeed, there is no call
since it can no further be realised) it is necessary to reserve network resources for the
session before the callee is alerted. Of course, other aspects (e.g. lack of credit) may
cause the call to fail, but they are not handled in the [RFC3312] proposal. Concerning,
the reservation of network resources, it frequently requires learning the IP address, port,
and session parameters from the callee. This information is obtained as a result of the
initial offer/answer exchange carried in SIP/SDP [RFC3264]. This exchange normally
causes the "phone to ring", thus introducing a chicken-and-egg problem: resources
cannot be reserved without performing an initial offer/answer exchange, and the initial
offer/answer exchange can't be done without performing resource reservation.
The solution, proposed in [RFC3312] “Integration of Resource Management and
Session Initiation Protocol”, is to introduce the concept of a precondition. A
precondition is a set of constraints about the session which are introduced in the offer.
Figure 6, taken from the same [RFC3312], illustrates this concept in a possible scenario.
The first offer (present in the INVITE method) states the preconditions to meet. The
answer carried in the “183 Session Progress” response indicates, among others, the state
of the fulfilment of the preconditions. The callee can start the QoS reservation but it
- 34 -
won’t alert the user until all the preconditions are met. As soon as the caller receives the
183 response it will start reserving the resources. When it finishes it indicates so to the
callee (UPDATE method) who will then know that all the preconditions are meet –
provided that himself had already finished reserving the resources-. Then the callee will
tell the caller, in the “200 OK” response to the “UPDATE” message, that he is also
complying with the preconditions and thus that all the preconditions are met. The caller
will also alert the user and proceed with the normal call setup (180 Ringing –reliably
sent- 200 OK and ACK messages). Although this RFC does not focus on the actual QoS
reservation, it assumes the SIP User Agents will handle the QoS reservation. Note that
several other approaches exist like the one in [GIO03] where the SIP proxy is the one
doing the QoS reservation.
SIP User Agent
[email protected]
SIP User Agent
[email protected]
INVITE with SDP1
183 session progress with SDP2
PRACK
200 OK (PRACK)
UPDATE with SDP3
200 OK (UPDATE) with SDP4
180 Ringing
PRACK
200 OK (PRACK)
200 OK (INVITE)
ACK
Figure 6 SIP signalling proposed in RFC 3312 to coordinate application and network setup
The attentive reader will have noticed that all the provisional responses are made
reliable following the mechanisms previously discussed [RFC3262]. The biggest
problem of this approach is that the number of signalling messages increases a lot. And
indeed, when SIP was designed, its main goal was to do a simple network initiation
protocol, mainly in comparison with H.323, which main drawback is that it needs a lot
of signalling messages to setup a session. Although we will employ in this work SIP as
the signalling protocol and we will embrace the concept of preconditions, we plan to
design an approach that reduces the number of signalling messages.
[RFC3312] defines preconditions for QoS aspects but, before establishing a
multimedia session, several other issues than QoS may have to be satisfied, for example
it may be necessary to check the credit available by the caller. For example, the
interworking between SIP and AAA systems such as Diameter is already under
definition [RFC3702], so the extension of [RFC3312] to support more preconditions
than the ones related to QoS will also be tackled in our thesis.
- 35 -
A. Cuevas
2.2
Tesis Doctoral
IMS
There is still a long wait to see commercial 4G networks and, until this,
“intermediate” approaches have been developed and recently put into the market. The
yet available system is called 3G (3rd Generation) or UMTS, developed by [3GPP]. In
this strategy, all the (complex) UMTS access network behaves as ‘1 hop’ at the IP layer,
and hides issues such as mobility and QoS from it. However, adding new access
network technologies involves then great amount of translation procedures from the
specific mechanisms of UMTS to the mechanisms in these other technologies. This is
one of the main disadvantages of 3G networks compared to 4G one. Indeed, as we will
see, 4G architectures, since they use IP as common layer, should be able to embrace
almost any wireless (or even wired) access technology available without the need of
translation procedures.
IP Multimedia Subsystem (IMS) was introduced in the 3GPP architecture in
release 5 to support IP multimedia services over GPRS and UMTS access networks.
IMS latest specification is release 7 [TS23228]. Two excellent books can be checked by
the interested reader: [CAM04] and [POI04]. IMS uses SIP (Session Initiation Protocol)
for the control of sessions (session signalling) and IPv6 for the network transport. It
offers an excellent solution to integrate session setup at application and network levels.
It integrates SIP [RFC3261] calls (with RTP/RTCP [RFC 3550] media transport) into
the infrastructure of a 3G network. Although our work is not tied to SIP, IMS is the
perfect starting point.
The main elements of IMS are the proxy call service control function (P-CSCF),
the interrogating CSCF (I-CSCF) and the serving CSCF (S-CSCF). The P-CSCF acts as
a SIP proxy between the UE’s SIP-UA and the S-CSCF. The S-CSCF implements the
actual SIP registrar functionality and session control including service triggering. The ICSFC is an element used mainly for topology hiding (THIG) issues and also, in case of
having several S-CSCF in the domain, to assist selecting the appropriate one. We can
conclude that the SIP proxies in IMS follow a two level hierarchy, the P-CSCFs being
the IMS contact points for the UE’s SIP-UA and the S-CSCF (or S-CSCFs) being the
proxy server controlling the session. The P-CSCFs leverages the work needed to be
done by the S-CSCF, they handle issues such as interworking with the network
elements (GGSN), compression and decompression of messages and verification of
their correctness before delivering them to the S-CSCF. This two level hierarchy will
be followed in our proposed architecture. The following Figure 7 shows the IMS
architecture, which has been simplified for comprehension purposes.
- 36 -
Application Server
or
OSA Gateway
IMS signalling
IP Flows
ISC
Interface
SIP/SDP
SIP/SDP
IMS
Home
Subscriber
HSS Server
P-CSCF
UE
UTRAN
S-CSCF
IPv6
SGSN
GGSN
GPRS
SIP/SDP
IP external
networks
Figure 7 IMS architecture
Figure 7 shows more elements playing a role in IMS. Those are:
HSS (Home Subscriber Server): It stores and manages the network operator’s
subscriber profile, including the service profile for the IMS, if the user is also a IMS
subscriber.
Application Servers and OSA Gateways: 3GPP defines interfaces between the SCSCF and the service plane. The S-CSCF can transfer the SIP signalling to a SIP
application server or an OSA gateway.
SGSN and GGSN. They are GPRS-UMTS entities and are not specific to IMS.
In simple words, the GGSN is an entity used in GPRS which can be seen as a router
with additional functionalities to manage the mobility issues of the user’s terminal. The
SGSN is another entity to support GPRS.
Besides SIP/SDP and IPv6, 3GPP IMS uses other IETF protocols for the
provision of IP multimedia services:
•
RTP (Real Time Protocol) and RTCP (Real Time Control Protocol) for the
transport of IP multimedia flows in the traffic plane [RFC3550].
•
COPS (Common Open Policy Service) for the control of GPRS QoS resources
[RFC2748]
•
Diameter for authentication, authorization and accounting [RFC3588]
- 37 -
A. Cuevas
Tesis Doctoral
•
RSVP (Resource Reservation Protocol) [RFC2205] and DiffServ [RFC2475]
[RFC2638] to ensure end-to-end QoS.
•
Megaco [RFC3015] to control Media Gateways.
2.2.1 SIP signalling in the IMS
In this section we concentrate on the SIP signalling in the IMS, further sections
will show the associated COPS and Diameter signalling showing how IMS integrates
AAA and QoS issues into the application session setup.
As we have said in section 2.1.2, SIP signalling can be done directly between the
end points -User agents (UA)- or via SIP proxies. In IMS, as we described in previous
section, there is a two level SIP proxies hierarchy. Imagine a simple case where two non
roaming users and pertaining to the same domain want to setup a session. Suppose there
is only one S-CSCF in this domain and that the P-CSCF serving the user 1 (P-CSCF A)
is different than the P-CSCF serving user 2 (P-CSCF B). The SIP messages will follow
the “user 1 SIP-UA, P-CSCF A, S-CSCF, P-CSCF B, user 2 SIP-UA” path. Now let’s
describe the most complicated scenario: two users, from different domains, who are
roaming, each in a different domain. User 1’s home domain is domain C, user 2 is from
domain D. User 1 is roaming in domain A and user 2 in domain B. Suppose domain A
and domain B are IMS enabled (namely they both have P-CSCFs) and that there is only
one S-CSCF in C and D domains. In this case, the signalling trapezoid would be:
“user 1 SIP-UA, P-CSCF A, S-CSCF C, S-CSCF D, P-CSCF B, user 2 SIP-UA”
If topology hiding is enabled or domain C and D have more than one S-CSCF
each, then I-CSCF will also take role in this signalling path. Depending on the
scenarios, the I-CSCF of domains A, B, C and/or D could intervene.
The SIP signalling messages are the same as the ones in Figure 6. There is,
however, one more type of SIP message used in IMS: the “100 Trying” provisional
response which is sent by each entity (but the caller UA) to its “downstream” entity,
when it receives from it the INVITE message.
A session can be tear down by any of the participants. To do so, the standard SIP
signalling flow is followed: BYE method and if everything is ok, “200 OK” response
2.2.2 Integration of session setup and network setup in IMS
This section will briefly describe some of the main aspects of the IMS
architecture that are useful for our work. We will analyse what can be reused and what
will be the adaptations and enhancements needed.
Although, perhaps, the more logical order to present the IMS procedures would
be to describe first Authorization and then QoS and Charging procedures, for ease of
understanding we think its better to describe first the charging procedure and then the
Authorization and QoS ones.
- 38 -
2.2.2.1 Charging aspects in session setup and tear down
IMS charging architecture is described in [TS32200] for release 5 and in
[TS32240] for release 6. Charing is a fundamental issue when defining business models
between users, network providers and service providers. IMS charging architecture is
flexible enough and is not tied to any specific business model but, of course, as it was
designed by 3GPP, it is biased to the network provider centric model. Anyway, what
enables the feasibility of rich business models is the capacity of correlating charging
at network and service levels provided by the IMS charging architecture. And this is
what we will discuss in this section.
IMS, following the Internet Model, completely separates the network and
service planes. GGSN, in the network plane, is aware of e.g. the packets being sent and
received and their QoS. S-CSCF, in the service plane, is aware of e.g. that a video call
with blackboard application is being setup between 3 roaming users. The charging
architecture allows correlating both things and, as such, can support, for instance, the 3
following different business models:
1. user pays both to the network and service providers
2. user pays to the service provider and this pays the network provider
3. user pays to the network provider and this pays the service provider
IMS is biased to the 3rd case, which is, by the way, the model defined in the
3GPP’s OSA [TS29128] or followed with clear success by i-mode [IMODE] from
NTT.
Charging in the IMS supports both offline and online charging. In offline
charging the amount due is deducted from the user’s account after the end of the session
while in the online charging, the amount is progressively deducted during the session.
An example of online charging is the prepaid mobile phone service, money is deducted
gradually during the session and if the user has not enough credit to continue the service
this will be shutdown. An example of offline charging is phone service with a contract.
The amount is deducted at the end of the session and billed once a month to the user
account.
The CCF is the central point in the IMS offline charging architecture. It receives
information form several IMS and GPRS/UMTS entities, processes, correlates,
consolidates and keeps only the relevant parts of this information and generates CDRs
for the UMTS billing system. IMS entities communicate with the CCF following the
Diameter base protocol [RFC3588] with 3GPP specific extension which are not yet
standardized in the IETF. It is based on the interaction between P-CSCF and S-CSCF
with the CCF (charring correlation function) module to charge the session in the
application plane. Interaction between SIP proxies and AAA servers was already
proposed in [RFC3702]. The interaction between the GGSN and the CCF (via the CGF)
is also defined to charge the session in the network plane. P-CSCF, S-CSCF, GGSN and
CCF will share the same Charging IDentifier (CID) for the same session and for the
PDP context(s) transporting the session’s media flow(s). Therefore the CCF can
correlate charging at application and network levels for the same session.
- 39 -
A. Cuevas
Tesis Doctoral
IMS related (application related) Accounting in the IMS is performed in the
home and visited domains. Both P-CSCF and S-CSCF take part of this accounting in
roaming or non roaming cases. Network related accounting is performed by the GGSN
only in the visited domains. SIP session flows traverse both visited and home networks,
that’s why application related accounting can be performed in both domains. But media
flows traverse only the visited domains and thus can not be accounted in the home
domains.
The Message Sequence Chart for Session Setup is simple: When P-CSCF and
S-CSCF (in caller and callee sides) receive the “200 OK” response to the INVITE
method they issue a DIAMETER ACR Start message to the CCF which responds with
an ACA message. Respect to the GGSN interaction with the CCF it was not yet
properly defined at the time this section was written. What is stated is that the GGSN
communicates with the CCF (via the CGF) when the session starts (the media traffic
starts to flow) passing it the CID. It is not clear whether this is done when the GGSN
receives from the P-CSCF the open gate message (assumed in the Figure 8) or at the
moment the UE opens the PDP context for the media flows.
V is ite d
C a lle r ’s
hom e
S -C S C F
C a lle e ’s
hom e
S -C S C F
G G S N P -C S C F
C a lle r
CCF
CCF
GGSN
V is ite d
P -C S C F
CCF
C a lle e
CCF
2 0 0 O K to IN V IT E
200 O K
200 O K
ACR
ACR
200 O K
O pen
G a te
O pen
G a te
ACR
ACA
ACA
ACR
ACA
ACA
Figure 8 IMS session setup, interaction with AAA (Accounting)
Concerning the Session release case, the P-CSCFs and the S-CSCFs issue a
DIAMETER ACR Stop message to the CCF when they receive the SIP BYE method.
Again it is not clear when the GGSN will communicate with the CCF either when it
receives the close gate message (assumed in the Figure 9) from the P-CSCF or when the
UE closes the PDP context for the media flows.
- 40 -
Caller’s
home
S-CSCF
Visited
Callee’s
home
S-CSCF
GGSN P-CSCF
Caller
CCF
CCF
GGSN
Visited
P-CSCF
CCF
Callee
CCF
BYE
BYE
BYE
ACR
ACR
BYE
Close
Gate
BYE
Close
Gate
ACR
ACA
ACA
ACR
ACA
ACA
Figure 9 IMS session release, interaction with AAA (Accounting)
The online charging architecture is composed of several modules like the
Bearer Charging Function (BCF) the Event Charing Function (ECF) and the Session
Charing Function (SCF). Online Charging follows the Diameter Credit Control
Application [RFC4006] and supports the two modes defined in this RFC: Immediate
Event Charing and Event Charing with Unit Reservation. At the time this section was
written, the communication between the S-CSCF and the SCF –that follows the ISC
Interface- was being changed by 3GPP. The objective is to use, instead, the Ro
Diameter interface. The reasons and the discussion being carried out to do this change
can be seen in [TR32815]
2.2.2.2 Authentication and Authorization in SIP registration and session setup
The IMS is integrated with the network operator infrastructure for handling
Authentication and Authorization of users. This integration is based on the S-CSCF –
HSS interaction. The HSS is a 3G entity (in 2G it was called the HLR) holding user
data. In IMS the authentication is done when the user registers (using the SIP
REGISTER method) and not when the user tries to setup sessions. The IMS (namely the
S-CSCF) does not hold the user authentication data so it delegates the authentication
task to the HSS. Namely, when it receives a SIP REGISTER message it takes the
authentication data and passes it to the HSS who will check and tell back the S-CSCF
whether the user is authenticated and authorized to register in the IMS. The
authentication follows the “challenge” method. With this interaction the S-CSCF also
retrieves from the HSS some parts of the user profile that the S-CSCF will use later
(when the user tries to setup a session) for authorization purposes. The interaction
between the S-CSCF and the HSS is done following the Diameter base protocol
[RFC3588] and some extensions for this concrete application [RFC3589]. When
[GAR05] becomes an RFC it will be the reference Diameter application to be used for
authentication and authorization by the IMS.
- 41 -
A. Cuevas
Tesis Doctoral
This interaction also reflects the network provider centric model of the IMS. The
IMS user profile must be stored in the network provider’s HSS and thus it’s the network
provider who holds the customer relationship and user data. Of course, for the IMS
registration to take place, the user must have previously register in the network (open a
PDP context), in this process it is also the HSS the one taking the final decision.
Concerning authorization, as we have said, it is done by the IMS (the S-CSCF)
itself but based on the user profile obtained from the HSS at registration time. Some
times, when the user tries to setup a new IMS session, the S-CSCF may not have all the
needed parts of the user profile. In this case, when the S-CSCF receives the SIP INVITE
message it may retrieve from the HSS the user data, following the Diameter protocol
just like when performing the Registration.
2.2.2.3 QoS and policy aspects in session setup and tear down
As we have described in section 2.2.1, IMS SIP signalling follows [RFC3312]
and thus can coordinate session setup at application level with the setup of network
resources and QoS for the application’s flows. Needles to say, the SIP negotiation
messages traverse a different path than the media flows (RTP/RTCP flows), thus the
SIP proxies (P-CSCF and the S-CSCF) can not, and are neither designed for this,
control the media flows. They let this control, as we will see, to the GGSN.
IMS integrates the application level negotiation –handled by the SIP UA in the
UE, the P-CSCF and the S-CSCF- with the setup of network resources (PDP Context
Activation in 3G networks) –handled by the UE and the GGSN- defining an interaction
between the PDF (part of the P-CSCF or a standalone unit) and the GGSN. This
interaction has one main goal which is to allow the GGSN –responsible of the packet
routing- knowing whether the PDP context trying to be established by the UE
corresponds to the media traffic being negotiated in the SIP session setup phase. That
way, the GGSN can control and authorize the bearer traffic of the SIP UA multimedia
call. The overall interaction between the IMS and the 3G or GPRS network elements is
called the SBLP (Service-Based Local Policy).
A key element to achieve this is the PDF (policy decision function). The PDF is
a logical entity that can be collocated with the P-CSCF or be a standalone unit. In the
later case, no protocol is defined in 3GPP’s Release 5 for the communication with the
P-CSCF. Release 7 [TS23228] uses, for protocols definitions, a release 6 document
[TS23207]. It is, however [TS29209] the document specifying the PDF-P-CSCF
interface. This interface is based on Diameter. The PDF is “aware of the application
level details” of the session being established, like codecs and requested BW for the
media flow(s). The PDF provides the GGSN with the characteristics of the media
flow(s). For example, a user agent may have negotiated (and be authorized for) an audio
stream of no more than 20kbps. The GGSN uses this information to install packets
filters in its routing logic. If the user agent tries to employ more bandwidth or send the
packets to a different destination, the flow will be discarded by the GGSN filters.
As we pointed out in the beginning of this section, the IMS session setup
signalling flow is very similar to the one described in [RFC3312]. The preconditions in
this case are the successful reservation of the PDP context(s) both in the callee and
caller sides. In IMS, the caller starts the resource reservation (creation of the PDP
context) when it receives the “183 Session Progress” provisional response and the callee
- 42 -
does so when it receives the PRACK method acknowledging the reception of the 183
response. The PDP context is handled by the GGSN who will ask –REQ Message in
Figure 10-, using COPS [RFC2748] protocol, the P-CSCF (via de PDF) whether the
user is authorized to open such a PDP context. Since the P-CSCF takes part in the
session setup and can know the user and the operators profile, it has all the needed
information to answer to the GGSN –DEC COPS message in Figure 10-. This happens
both in the caller and callee side and, in the case of roaming, always in the visited
domain (provide that both visited domains are IMS enabled -namely they have PCSCFs-). When the PDP contexts are open, caller and callee inform each other of the
fulfilment of the preconditions, using the UPDATE method, and the call setup proceeds
in the normal way (“180 Ringing” and “200 OK” responses –to the INVITE- and the
ACK method). When the P-CSCF in the callee side receives the “200 OK” response it
tells the “callee’s” GGSN –via the PDF- to approve the commitment of the resources of
the previously reserved PDP context (“Open Gate” message). The P-CSCF in the caller
side does the same thing when it receives this message.
C a ller
GGSN
V isited
V isited
P -C S C F
P -C S C F G G S N
C a llee
IN V IT E
G e n era te to k e n # 2
IN V IT E w ith tok en # 2
1 83 S e ssion p ro gre s s
G e ne ra te to k e n # 1
1 83 w ith to k e n # 1
P R A C K to 18 3
O pen
P D P co nte xt w ith R E Q
to k e n # 1
w ith
to k e n # 1
REQ
w ith
tok en #2
DEC
U pd a te
P re co n ditio n s
S ta tus
P D P c on te xt
op e n
DEC
P D P co nte xt
o pe n
U p da te
P rec on d itio n s
S ta tus
2 00 O K to IN V IT E
RPT
O p en
G a te
O p en
P D P co nte xt w ith
tok en # 2
RPT
O pen
G a te
Figure 10 IMS session setup, interaction with QoS
Authentication of the UE’s PDP context request is achieved following a “token
model”. During the session setup, the P-CSCF/PDFs generate “tokens” and conveys
them to the caller and the callee in the normal SIP messages. UEs will include their
token in the requests to open the PDP context and the GGSN will forward it back to the
P-CSCF/PDF when queering for authorization to open the PDP context.
The session release signalling is “the inverse” of the session setup signalling:
The UE closes the PDP context(s) for the media flow(s) and the P-CSCF tells the
GGSN to close the gate. There is, however, no query from the GGSN to the P-CSCF to
check whether the user is authorized to close his session.
- 43 -
A. Cuevas
Tesis Doctoral
V is ite d
V is ite d
P -C S C F
G G S N P -C S C F
C a lle r
GG SN
C a lle e
B YE
C lo s e
G a te
BYE
BYE
C lo s e
P D P co n te xt w ith
tok e n # 1
C lo s e
G a te
C lo s e
P D P c o n te xt w ith
tok e n # 2
P D P c o nte xt
c lo s ed
P D P c on te xt
c lo s ed
Figure 11 IMS session tear down, interaction with QoS
2.2.3 Business model proposed, IMS general conclusions
As a conclusion we have to say that the IMS model is a very good solution for
integrating service and network providers in 3G networks. Its advantage is that, while it
is open for third parties to add many new applications and services, it puts the network
provider in the central role of the business and thus solves the problem raised in the
introduction: relegating the network provider to a mere bits transporters. This model is
the model defined in the 3GPP’s OSA or followed with clear success by i-mode
[IMODE] from NTT. Indeed in the IMS model, the IMS infrastructure belongs to the
network operator and the third parties services (termed AS) interact with the S-CSCF.
ASs are considered as another SIP proxy but, of course, the S-CSCF and AS interaction
is done with security mechanisms. An example of Added value third party service is an
agenda that is capable of redirecting the incoming calls (e.g. modifying the headers in
the INVITE message) to appropriate devices (voice box or PDA) depending on the
caller (boss, friends, etc.) and the agenda of the user (in a meeting, having lunch, etc.).
But the IMS defined business model is still valid even if the IMS infrastructure would
belong to a third party because all the user related data and billing is handled by 3G
network operator elements. Of course, in the case of the IMS being owned by a different
entity, proper security mechanisms will need to be added for the interaction between 3G
network and IMS entities.
But can the IMS solution be exported to 4G networks? The answer is yes, but
several issues not covered in IMS must be solved before.
•
First, although IMS spirit is to support any kind of access network, at the time
this chapter was written, the only available specification was for CDMA based
3G networks. As we have said in the introduction of section 2.2, 4G networks
will have native IP connectivity and many of the 3G elements will not be present
(namely the GGSN) and this will require some adaptations in the IMS. For
instance, the QoS setup is based on PDP context which is specific to 3G
networks and can not be done in any other network e.g. WiFi.
- 44 -
•
Second, although complete, the 3GPP solution does not take into account
MIPv6. Further only 3GPP2 (cdma2000) considers MIP. 3GPP UMTS do not
explicitly consider MIPv6. Although SIP is independent of the IP-mobility
issues (those happen at layer 3 and SIP is located a layer 5) it is still under
discussion whether the MN should provide the HoA or/and the CoA in the SIP
registration and invite. The best solution (according to [FAC04]) would be to
provide the HoA but that would require the P-CSCF to support MIP.
•
Third, IMS has the following problems related to security:
o Integrity-protection of all messages is not possible between the UE and
the S-CSCF as the P-CSCF which, if the user is roaming, is located in
the foreign domain, needs to modify payload of some of them
o P-CSCF should be able to check the integrity of messages sent by the UE
o Need for network domain security between GGSN and P-CSCF and
between PCSCF and S-CSCF
Further, IMS is designed for proxiable applications, so applications that do
not use proxies (such as FTP) are out of the scope of the IMS. In 4G networks
support should be given to these applications, perhaps with less features than the
ones within the 4G IMS framework, but still enjoying services like QoS enabled
data transport.
2.2.4 “Next Generation Network” framework
Research to find similar IP based architectures to IMS resulted in the project the
“Next Generation Network” (NGN) developed and funded by the International
Telecommunications Union (ITU). ETSI TISPAN is taking lead and has already
proposed an architecture [ES282001]. The NGN will complement the IMS with other
subsystems, identify inherent differences between xDSL access networks and UMTS
access networks, derive impacts on 3GPP specifications, particularly on the internal
IMS interface (both SIP based and DIAMETER based), Gq interface
(application/session control to resource control), RF interface (charging), ISC and OSA
interfaces (Session control to applications). The standard will also specify NGN
reminder aspects (e.g. alternative to GPRS for network attachment). The aim is to limit
the number of extensions to the 3GPP IMS.
Figure 12 shows a possible realization of the proposed TISPAN NGN
architecture. The aim of the architecture is to offer a combined solution for mobile and
fixed access networks, also taking into account legacy services for PSTN and ISDN,
using
•
•
PSTN/ISDN Emulation: Providing PSTN/ISDN service capabilities and interfaces
using adaptation to an IP infrastructure.
PSTN/ISDN Simulation: Providing PSTN/ISDN-like service capabilities using
session control over IP interfaces and infrastructure.
- 45 -
A. Cuevas
Tesis Doctoral
PSTN/ISDN Emulation to
support legacy terminals
IMS
TISPAN xDSL Connectivity Network
Access
Network Attachment
Subsystem
(SIP -based)
IP Multimedia Subsystem
(Core IMS )
PSTN/ISDN emulation
Subsystem
Resource Control
Subsystem
Access Transport
Network
P
S
T
N
Core Transport Network
IP
Figure 12 ETSI-TISPAN NGN Architecture
2.3
4G networks
As we have pointed, there is a clear will to move beyond 3G and go for a new
generation of communications. One of the main motivations is the need to have multiple
access techniques. But this is complicate to do in 3G networks because of the heavy
adaptation procedures, while in 4G networks, that will use the IP layer as a convergence
layer, this adaptation will be immediate. Besides, instead of bringing the concept of
packet switching into existing connection-oriented cellular network environments –the
more traditional evolutionary path-, several voices [COM05], [WIR04] argue that
redesigning directly the network to provide 4G capabilities (such as seamless
heterogeneous access) may help them to become a reality much sooner than forecasted.
Due to the interest to move to 4G network, the research effort in this area is very
intensive, but many issues are still to be covered, among them the subject of our thesis,
session setup procedures integrating both network and application level aspects. As we
have seen in section the IMS approach, adapted to 4G networks, will be the basis of our
solution. Prior to presenting it, we will analyse the current research efforts in 4G
networks, focusing on the problems solved, the different approaches adapted and the
topics that need more research.
2.3.1 Fundamentals of 4G networks
There is not yet a clear concept of what a 4G (4th Generation) network will be;
but, broadly speaking, we can say it will be an Internet network with extra features, such
as mobility, coming from today’s telephone networks. Also any access technology –
wired or wireless- will allow the user to connect to these 4G networks. Some voices
tend to focus the definition of 4G networks in broader band access technologies, but we
- 46 -
think the concept exposed just above is more accurate to define 4G networks. Research
projects in 4G networks concentrate on several aspects such as providing QoS, mobility
and fast handovers, AAA (Authentication, Authorization, Accounting), etc. in IP based
4G networks. All these aspects are hard to provide in IP based networks since they were
not designed for this. Some times the difficulty is not in solving one single isolated
problem but to integrate the different solutions. For instance
1. Some aspects of the different functions overlap. For instance both QoS and AAA
must perform authorization
2. Some aspects of one function pose severe burdens to the performance of another.
For example, authorization must be performed each time the user changes his point
of attachment, posing serious constraints to FHO.
In the rest of this section we will present some of the aspects that are believed to
form the pillars of 4G networks [GAR02]:
•
Mobility is one of the topics that are being added to IP networks. After many
discussions (in IETF the draft about mobility had more than 18 versions) a solution
is yet available. It is described in [RFC3775]. Micro mobility is also being discussed
and IETF has already arrived to a solution [RFC4068]
•
Paging is another issue which is very relevant for low battery mobile devices, which
will be one of the main equipments used in 4G networks. IETF is carrying huge
efforts in this topic and [RFC3132] has been produced about it, but the work is still
very preliminary and the main contributions are under drafts [LIE01] or papers
[XIE04].
•
QoS provisioning in IP networks has been discussed for long. As it is perfectly well
known IP networks were not designed to provide any QoS warrantees. But the
applications traditionally using IP as their communication technology could
perfectly cope with its lack of warrantees. But telephony or iterative applications
require transport networks with very stringent QoS requirements.
The transport QoS required by application has been extensively studied both
from technical and user perception points of view. Recent user perception studies
[GRO05] flow on the direction of psychoacoustics; they try, for instance, to measure
the effort a person must do to understand a conversation in function of the QoS of
the transport technology. The goal is to infer the user perceived QoS without
directly asking him about his felling.
Not only the application QoS requirements have been extensively studied, but also
the ways to endow IP networks with QoS mechanisms. The most accepted solutions
are IETF’s IntServ [RFC1663] and DiffServ [RFC2475]. Both IntServ and DiffServ
endow the routers with QoS mechanisms such as, classifiers, priority queuing and
shaping. The differences lie in the level of detail in the classifiers and in the state
maintained.
- 47 -
Tesis Doctoral
Metter,
Shaper,
Dropper
Metter,
Shaper,
Dropper
To the network
Queue
with dropper
Scheduler
Metter,
Shaper,
Dropper
Queue
with dropper
Multiplexer
&
Classifier
Classifier
through this interface
Packets to be routed
A. Cuevas
Queue
with dropper
Figure 13 A QoS enabled interface in a router
The IntServ model provides end-to-end QoS guarantees by reserving per-flow
resources (normally using the RSVP protocol [RFC2205]) in all the nodes along the
path. While this architecture provides excellent QoS guarantees, it has scalability
problems in the network core because of per-flow state maintenance and per-flow
operation in routers. DiffServ, on the other hand, requires no per-flow control on the
core and, consequently, routers do not maintain any per-flow state and operation. As
a result, DiffServ is relatively scalable in the forwarding/data plane but offers no
strict QoS guarantees. The criterion to classify the packets in the core routers is the
DiffServ code point (DSCP) field in the packet header [RFC2638]. Several
approaches also exist combining IntServ and DiffServ: e.g. IntServ in the “access
part” of the network and DiffServ in the core. Of course, solutions based on other
paradigms also exist and are even complementary to these ones. For Instance
[SCH04], proposes new routing schemes over high availability networks.
Coming back to DiffServ and IntServ, besides the QoS enabled routers, another
entity, called QoS Broker or Bandwidth Broker [NAH95], used to control and
manage the network is also widely accepted by the research community. This entity,
for scalability reasons, can be replicated in the network. More even, the network can
be hierarchically divided into several areas as proposed in [COR03] and each area
controlled by its own QoSBroker. The QoS network architecture we will propose in
our thesis will also be hierarchically divided. We note again that we will also follow
the IMS idea of hierarchically dividing the functions of the SIP proxies. In our thesis
we plan to make both QoS and SIP hierarchies compatible.
Let’s now concentrate more on the role of the QoSBroker (QoSB). In a simplified
way, the QoSBroker manages and monitors the network resources in one particular
domain of operation. It also monitors the edges for the incoming and outgoing
resource reservations/utilisation. [RFC2749] gives examples of this role. For
instance, a RSVP enabled router consults the QoSBroker (using the COPS protocol
[RFC2748]) about the decision to take when receiving RSVP Path or Reservation
messages. The decision taken by the QoSBroker is conveyed in the COPS DEC
message and then enforced by the router. Figure 14 illustrates the message
exchange.
- 48 -
Router
QoSBroker
RSVP Path COPS REQ
 COPS DEC
RSVP Resv
COPS REQ
COPS DEC
COPS RPT Figure 14 an example of QoSBroker functionality, MSC
The information thereby acquired is used in conjunction with the Policy System
(PS) information to take admission control decisions and reconfigurations and
convey them to the routers. A QoS Broker is then an entity that takes Service
Admission Control (SAC) decisions and does network device configuration,
according to a set of conditions imposed by the network administration entities
(AAAC System, for instance) with the goal of achieving end-to-end QoS
(eventually over different networks). The QoSB may also be responsible for
managing inter-domain communications with neighbour QoS Brokers, so that
services may be implemented in a coordinated way across various domains.
[HOW05] proposes such a model using BGP between the routers and SLS
management entities –similar to QoS Brokers- communicating between domains.
•
AAA (Authentication Authorization and Accounting) issues plus Charging and
Auditing will be handled in 4G networks using Diameter protocol as a framework.
The Diameter base protocol [RFC3588] just specifies a basic set for all the Diameter
applications to follow. The strong security extension [CAL01] specifies extensions
to secure some selected parts of the Diameter messages. The actual needs are
covered by Diameter applications defined in different RFCs (Figure 15). In 4G
networks the most suited applications are the Diameter Mobile IP application
([RFC4004] tackles IPv4 and IPv6 RFC is under preparation [LE04]) and the
NASREQ [RFC4005] applications. They roughly define a Diameter server per
domain containing all the user profiles and several Diameter clients that are in
charge of controlling the access of the users to the network. The NASREQ
application allows users to connect to the network. Terminal may establish an
IPSEC tunnel with the Network Access Server (NAS) in the Access Router and this,
using the NASREQ application outsource the admission decision to the AAA
server. To allow roaming, the Diameter Mobile IP application [RFC4004], employs
the interdomain communication capabilities from Diameter Base protocol; normally
it is done between the AAA Diameter servers of each domain.
- 49 -
A. Cuevas
Tesis Doctoral
NASREQ
Extension
Mobile IP
Extension
Strong Security
Extension
Diameter Base Protocol
Accounting
Extension
Extension
...
Figure 15 Diameter Protocols organisation
The Diameter server can be assimilated to the HSS in the 4G networks.
Besides, and since IMS also uses Diameter, in our thesis the AAA architecture will
be based on Diameter mobile IPv6 application. Note that Diameter does not
preclude any business model but in our thesis we will follow the IMS or OSA model
so we will assume that the network operator will host a diameter server containing
the profiles of the users.
The aspects of security associations normally affect negatively to the
performance of fast handoffs since these security associations may need to be rebuilt
each time the user changes its point of attachment, process that takes some time.
Several approaches exist but we cite the one [KUR04] that proposes to pass the
security association parameters from one attachment point to the other (provide they
are owned by the same administrative identity) and so build the new security
association prior to move (make before break paradigm).
Another very important aspect is the coordination of QoS and charging. QoS
in IntServ or DiffServ (which will be the accepted model in 4G networks) is based
on Differentiation. These Differentiation can be made upon several aspects but one
of them is user profile i.e. users who pay more are different and have better QoS
than the others; see, for instance, [PAN04]. But the aspect of user handling is not
part of QoS but of AAA framework. Thus there is the need of a clear interaction
between the two. This thesis will propose how.
Besides, the aspect of charging is very tied to the business model and as, by
the moment, there is not a clear a business model, there is a huge variety of work in
this area. One of the proposals is to add pricing information in the RSVP [FAN98].
Some work even use pricing for purposes of admission control [LI04]. Almost all
the works propose flexible enough designs to accommodate to several business
models, for example, [BRI03] proposes an architecture flexible enough to support
many business models for QoS pricing. The main drawback is that most of the
proposals use charging as a mean to regulate the network usage while as [ROB2004]
says, the main reason of charging is making profit out of the service offered
- 50 -
(network transports service or “added value” service). Of course, the AAA system
may do accounting and charging based on more issues than QoS, the clear example
is the IMS where Diameter is used to account for sessions. Besides there is already
an [RFC4006] that describes an application that enables online charging (used
mainly in prepaid scenarios) in the Diameter framework. So we think that, besides
IMS, many applications and systems will use Diameter for accounting and charging
e.g. tarrif for mp3 songs download.
•
Mobility and QoS: One of the most difficult problems when dealing with IP
mobility is assuring a constant level of QoS. When users move they may reach a
more overloaded cell or even move to a technology with less available bandwidth.
Or, simply, due to long handover procedures, have an interruption in the
communication. But in none of these cases the QoS of the service should be
affected. Many is the research being done and one of the basics paradigms is, like in
the case of Mobility + AAA, is the make before break model. The work in [LO04]
follows a hierarchical mobile IP approach with the concept of forwarding chain to
reduce the packet loss during FHO. It also includes RSVP mechanisms but with the
concept of “passive reservation” to avoid doing new reservation each time the MN
changes its point of attachment. The work from [CAL05] focuses more on the
challenge of moving between heterogeneous network which may have very different
characteristics and its scenarios are wide area networks.
2.3.2 Research projects
We have to stress again that, perhaps, one of the most challenging tasks in 4G
networks is not endowing the IP network with extra features (such as mobility) but
integrating all the proposed solutions. The research effort needed for handling and
integrating different issues is important and it’s mainly conducted within wide research
projects. We present here some the most relevant.
Among the research projects are: The MIND (Mobile IP based Network
Developments) project [MIND], which is the follow up of the BRAIN (Broadband
Radio Access over IP Networks) project, was focused in mobility aspects, as well as ad
hoc, self-organising and meshed networks. Concerning the mobility-related work
performed within that project, good results were obtained for the Wireless LAN
(WLAN) horizontal handover scenario, although the network complexity in terms of
required infrastructure is high.
The IST OverDRIVE project [OVERDRIVE] was focused in vehicular
environments and worked also in radio resource management issues, thus improving
specific access technologies.
The LONG project [LONG] was focused on IPv6 transition and deployment
issues. Nevertheless, LONG did not aim at deploying a native IPv6 4G system.
Other European IST projects (like Tequila, NOMAD, WINE-GLASS)
developed work on some of the areas required for a 4G network (e.g. QoS, mobility,
etc), but none of them implemented the whole picture of a 4G prototype. Besides the
IST initiatives, there are other projects working on 4G related issues. For example, the
Cambridge Open Mobile System (COMS) project [COMS] at the Computer Laboratory
of the University of Cambridge works on Mobile IPv6 and vertical handover
- 51 -
A. Cuevas
Tesis Doctoral
performance issues. The main point of this project is that their tests are conducted over
test beds using real 2.5G infrastructure (real operator GPRS network). Nevertheless, this
project is focused only in mobility, so neither QoS nor AAA is integrated in its test bed.
The Moby Dick project [MOBYDICK] developed a 4G network with native
IPv6 connectivity and all the issues (QoS, AAA and mobility) handled at IP level so it
supported any access technology [JÄH04]. Three access technologies were used in the
test beds, WiFi, Ethernet and CDMA. The project only dealt with IP level and the
applications and services were not the focus of the project. Indeed any existing Mobile
IPv6 application could be used within Moby Dick. AAA used Diameter mobile IPv6
application extended to support Charing and Auditing [KUR04]. It charged the users per
packets sent and received and the QoS employed for their transport. It provided security
mechanisms using IPsec and assuring the correspondence between users and packets.
QoS used DiffServ with access control in the Access Routers. Differentiation was given
to the packets but, thanks to the interaction designed with the AAA system, the packets
were associated with users and their profiles. Mobility used Mobile IPv6 with FHOs
(integrated with QoS and AAA) based on the bicasting and make before break
paradigms. Paging was also implemented. Moby Dick achieved very good results
[CUE05] and showed that a 4G network is able to support multimedia communications
which are the main applications that require session setup techniques. The Moby Dick
architecture is being extended under the [DAIDALOS] project, that has also relevant
contributions in the field of session setup.
2.3.3 Session setup aspects in research projects
The issue of integrating application and network layer aspects in the session
setup has been handled by many projects. Due that this is the main topic of our thesis
we have dedicated this specific section to the state of the art of session setup in 4G
networks.
One of the projects that was more focused on this issue is the MIND project. The
mind project clearly distinguishes between the transport domain which just forwards
packets –the role of an ISP in today’s Internet- and the service domain who provides
services to the user (like web pages). In MIND, the service domain also includes
features such as registration, AAA, etc. MIND defines 4 scenarios for interworking
between the service domain and the transport domain.
The first one is the “no coupling” scenario. In this scenario the (SIP or E2ENP)
session setup signalling is done directly between the conferees without including any
SIP proxy in the service domain. In this case, no interactions between Service Domain
and Transport Domain take place. Thus, the Service Domain can not authorise or
activate/de-activate Transport Domain resource reservations. The only communication
concerning resources occurs between the conferees and Transport Domain via a
resource reservation signalling protocol like RSVP. The “No Coupling” scenario is
applicable to e.g. legacy applications in the current Internet.
The second one is the “Loose Coupling” model. Here the sip proxies of the
service domain take part in the (SIP or E2ENP) session setup signalling. They generate
tokens for the conferees to include in the QoS reservations they will do with the
transport domain. During the session setup there is no interaction between the service
and transport domain.
- 52 -
The “Tight Coupling” scenario corresponds to the IMS model, where the
conferees implement the reservation protocol (e.g. RSVP) themselves but the Service
Domain interacts with the Transport Domain during call setup for reservation
processing.
Finally, we have the “Integrated” scenario. In this case the service domain
handles completely the resource reservation and the conferees do not need to do setup
any network resources, indeed they do not need to interact with the transport domain,
only with the service domain. Several other authors or projects [GIO03] propose a
solution where the SIP proxy (or proxies) does the QoS reservation. This solution has
one advantage respect to the other: MNs nodes used by the conferees which may be
moving and attached to very different access technologies do not need to know the
specific reservation mechanisms that apply in each domain or technology.
These scenarios influence the work done in [DAIDALOS] and will also be taken
into account in this thesis.
The key point to see the business model associated to the scenarios is to know
which entity/ies detain the user profile and bill them. Before continuing with the
discussion, it must be noted that the owner of the transport domain may also own
entities whose role falls within the service domain. As we have seen in section 2.2.2.1,
in IMS, the owner of the entity detaining part or all of the user profile and doing the
charging is the transport domain.
There are other projects dealing with SIP sessions and their integration with
AAA and QoS. The work in [GRO01] specifies the architecture, protocols and
messages for SIP based IP communications between Internet domains in support of QoS
and AAA. AAA requirements including inter-domain and user authorization in mobile
and non-mobile environments are addressed: Dynamic setup of end-to-end network
resources for QoS requires highly scalable mechanisms to authenticate, authorize and
account (AAA) for network resources across the Internet. This must be able to happen
between a very large number of independent and various access domains that may have
no business or trust relationship with each other, or may not even know of each other's
existence before initiating end-to-end communications.
Figure 16 depicts de architecture proposed. This architecture is a good starting
point but the AAA and QoS functionalities are handled together in a policy node. The
problem is that the functionality of this node becomes too big and thus we may face
scalability concerns. In our thesis, AAA and QoS systems will be separated and
specialised each in its task. The interactions between them will be proposed.
- 53 -
A. Cuevas
Tesis Doctoral
Customer
Application
and Policy
Server
PS
ISP or
Enterprise
Policy
Domain
Directory
Accounting
Data Base
Dir
ADB
AAA
and
Policy
Server
Outsourced policy
Media
Agent
Signaling
SIP
Proxy
UA
CH
Policy/Usage
Reports
COPS
SIP
Interdomain AAA
APS
IP Tel App
SIP phone
or gateway
Clearinghouse
RSVP
RSVP
DiffServ
R
ER
router
Edge router
Figure 16 Gross' architecture for inter-domain QoS and AAA enabled SIP communications
The architecture, like the IMS or the MIND Project, separates the SIP signalling
and data transport. The first is handled by SIP proxies, the second by QoS enabled
routers. Both “worlds” interact via the APS, which is a policy server controlling the
routers, based on the sessions setup via the SIP proxy and also based on AAA issues.
2.4
Conclusion. Research opportunities and thesis objectives
As we have seen, much work has been carried out in the research fields related
to this thesis, e.g. [GRO01], [OTT05]. Some of the solutions are even standardized and
have great commercial acceptance e.g. SIP [RFC3261]. The 3GPP-defined IMS
[TS23228] framework integrates some of these solutions under a coherent “umbrella”
and achieves a business model that places the network operator in the core of the
business value chain.
However, the IMS is designed for 3G networks. As we saw, most of its solutions
can be exported to 4G. This chapter showed also the required adaptations. The scientific
community is addressing this (e.g. [MIND]) while dedicating strong efforts to the
design of 4G networks (e.g. [CUE05]). The session setup topic addressed in this thesis
falls within this research area. We presented the research efforts, the solutions they
provide and identified their shortcomings. Those shortcomings bring the research
opportunities to this thesis and justify the objectives presented in the introduction.
Next we will briefly summarize our identified research opportunities. We
explained that IMS assumes and is designed to support only one business model and
one type of applications: the ones using SIP and IMS proxies. However several business
models and scenarios will be present in 4G networks and our goal is to propose the
mechanisms to support them in an integrated 4G framework. SIP [RFC3263] and SDP
[RFC2327] are good session setup techniques; RSVP [RFC2205] on its side is used to
- 54 -
setup and request QoS resources at the network level. However, due to the shift in
business paradigms, they have to be enriched to support new aspects. This also will be
addressed in this thesis. Also, many 4G solutions are available (e.g. [CAL05], [L004])
but, as we showed, the challenge is to integrate them. This thesis will propose different
ways, focusing on session setup aspects.
In the following chapters the solutions proposed to address these aspects will be
developed.
The enhancements to existing session setup and description protocols, adapting
them to the new business models will be tackled in chapter 3 and 5. The business
models and the different scenarios and requirements to be supported in our integrated
4G framework will be identified in chapter 3. The 4G designed architecture along with
the ways to support several scenarios will be dealt with in chapter 4 and chapter 5
stressing the enhancements respect to IMS. The protocols and the ways to correlate and
coordinate session setup at network and application layers will be mainly addressed in
chapter 5.
Next chapter will analyze the problems derived from today’s “Internet” business
model. We will focus on the split of subsessions between the different entities. The
future business models, along with their advantages will be presented. Their
requirements for session setup will be analyzed. The ways to correlate the different
subsessions will be described, focusing on users’ profiles, contracts, business
relationship with the users and different negotiation levels (application and transport).
This and the architecture proposed in chapter 4 will be the key point to understand the
session setup signaling design described in chapter 5.
- 55 -
3. Análisis del Problema: Dispersión de las Sesiones
La funcionalidad que cubre el establecimiento de sesión entre dispositivos
telemáticos consiste en que las distintas partes lleguen a una definición común de la
sesión que se va a establecer entre ellas ([RFC3264]). Esto requiere un intercambio de
información entre los participantes en la sesión. Este capítulo analizará esa información.
Dicho análisis se hará bajo la óptica de las distintas clases de entidades implicadas en la
sesión. Como esas entidades manejan distintos conceptos de sesión, la información que
posean sobre una misma sesión y sus subsesiones será distinta, tal como veremos en la
primera parte del capítulo. Además, toda esa información estará dispersa entre todas las
entidades participantes. Esta dispersión es el modelo imperante hoy en día en Internet.
En cambio, los modelos de negocio que analizaremos en la segunda parte de este
capítulo se basan en cohesionar y centralizar dicha información. Veremos las ventajas
que esto supone. Así mismo, resaltaremos como la piedra angular de dichos modelos de
negocio es la gestión de los perfiles de usuario. Estos modelos de negocio plantearán
una serie de requisitos para lograr una visión común de la sesión. En la última parte de
este capítulo veremos las pautas que deberán seguir los sistemas 4G para cumplir con
dichos requisitos a la hora de establecer sesiones.
3.1 Diversidad de entidades y de sesiones
En una sesión y, en particular, a la hora de establecerla, pueden estar implicadas
varias entidades, desde los interlocutores de una conversación telefónica hasta la red
que transmite dicha conversación. Esas entidades, por su diferente naturaleza, tendrán
distintos conceptos de sesión. Esto es lo que trataremos en esta sección. Antes de entrar
en su desarrollo debemos recalcar que un mismo sujeto puede jugar el papel de
entidades distintas de la sesión, tal como veremos en la sección 3.2.
3.1.1 Interlocutores. Parámetros a negociar
A la hora de establecer una sesión, los interlocutores no sólo generan datos sobre
si mismos (por ejemplo sus identificadores) sino también sobre los terminales que están
usando. Además, como vamos a analizar, los usuarios suelen tener –aunque no en
exclusiva- el control de la sesión (su creación, su conclusión y otros aspectos) por lo
que son la mayor fuente de información que se maneja en el establecimiento de sesión.
Describiremos en esta sección esos parámetros. Otras entidades también manejan parte
de esos mismos parámetros, por lo tanto, los estudiaremos a lo largo de varias
- 57 -
A. Cuevas
Tesis Doctoral
secciones. Muchos de esos parámetros son ya conocidos y usados. Sus definiciones
están hechas por múltiples organismos, desde el IETF hasta el MPEG: [RFC2205],
[RFC2327], [RFC3261], [OTT05], [N5845]. Nosotros las analizaremos y
clasificaremos. Veremos como, sin embargo, hay un parámetro que aún no ha sido
considerado, la negociación del pago de los recursos. Nosotros propondremos en esta
sección y en otras los mecanismos para incluir y usar ese nuevo parámetro en la
negociación de establecimiento de sesión.
Aunque el término “interlocutores” empleado es, en sí, descriptivo, antes de
seguir vamos a explicitar más a qué nos referimos con esta palabra. Interlocutores son
todos los usuarios que quieren establecer una sesión entre sí (ayudados o no por
mediadores o “proxies”) usando una red de telecomunicación (redes 4G en nuestro
caso). Los participantes en la sesión pueden ser:
•
Usuarios sin intención de lucrarse con el otro interlocutor. Es decir ninguno de
los interlocutores paga al otro. Pero puede ser que sí paguen a terceras entidades,
como la red de telecomunicaciones. En ese caso y si, además, los interlocutores
emplean un servicio de conferencia, el término de interlocutor coincide
plenamente con el que manejamos habitualmente para referirnos a los
participantes en una llamada telefónica clásica.
•
Usuarios y proveedores de servicio. En este caso uno de los participantes (el
proveedor de servicio) ofrece y cobra un servicio a los otros miembros de la
sesión. Los ejemplos que pertenecen a este caso van desde el típico servicio de
información telefónica a compra de entradas de cine pasando por la descarga de
tonos en el móvil. En este caso, el proveedor de red también recibirá
compensación económica. Quién le pague (el usuario o el proveedor de servicio)
es un aspecto relacionado con los modelos de negocio que discutiremos en la
sección 3.2.
En esta sección nos centramos en los interlocutores que consumen servicios,
los que los ofrecen (proveedores de servicio) serán tratados en la sección 3.1.2. Una vez
aclarado la noción de interlocutor, en el resto de esta sección veremos el concepto de
sesión manejados por estos y sus parámetros más descriptivos.
Para los interlocutores estudiados en esta sección, la sesión es el consumo de un
servicio. Ellos (si tienen los debidos permisos, crédito etc.) deciden cuando consumir el
servicio y durante cuanto tiempo, es decir controlan y son conscientes del
establecimiento de la sesión y de su conclusión. La noción de servicio la pueden
entender de varias formas, en función de los modelos de negocio y de los conocimientos
técnicos que tengan. Por ejemplo un usuario que esté navegando por la Web a través de
su móvil GPRS con tarificación por cantidad de bytes enviados y recibidos y que accede
a una página WAP para comprar unas entradas para el cine, puede considerar dos cosas:
•
Hay dos sesiones, por las que paga aparte; la primera el envío y recepción de
datos a través de la red GPRS, la segunda la compra de la entradas
•
El usuario también puede considerar que el envío y recepción de datos es parte
de la sesión de compra de entradas. Esta percepción la tendrá el usuario si por,
ejemplo, recibe un única factura detallando ambos conceptos. De hecho, en
- 58 -
Análisis del Problema: Dispersión de las Sesiones
algunos de los modelos de negocio que propondremos en la sección 3.2, la
sesión de envío y recepción de datos puede quedar totalmente enmascarada por
la sesión de compra de entradas.
Otro ejemplo sería un usuario conectado a Internet, esta vez a través un enlace
ADSL y con tarifa plana. Como ese servicio de conectividad tiene una tarifa fija,
independiente del uso que se haga de él, el usuario lo verá completamente separado de
los otros servicios (de valor añadido) pese a que la conectividad IP es básica para que
estos servicios de valor añadido se den.
Estos ejemplos no son más que para ilustrar un hecho fundamental, la prestación
de un servicio puede acarrear el uso de varias sesiones y subsesiones y que el usuario
forma parte de todas ellas. Además, según los modelos de negocio, estas sesiones se
pueden agregar y así el usuario las percibirá como una sola, o, como en el modelo
Internet de hoy, pueden ser independientes.
Para entender mejor este concepto, vamos a presentar un ejemplo más y lo
vamos a explicar bajo el punto de vista de cada una de las entidades presentes en él. En
esta sección lo haremos bajo el punto de vista de los usuarios y en las sucesivas (3.1.2,
3.1.3 y 3.1.4), bajo el punto de vista del proveedor de servicios, del operador de red y de
los “mediadores”, respectivamente.
Consideremos 4 personas que establecen una videoconferencia entre ellas y con
servicio de “pizarra compartida”. La videoconferencia y el servicio de pizarra se
establecen usando un “mediador”. Los datos de la aplicación de pizarra electrónica son
transportados sin hacer ninguna reserva. En cambio, para transportar los flujos de audio
y vídeo, se decide establecer una reserva con la red para cada uno de los flujos. Hay dos
excepciones: uno de los participantes está conectado mediante una red que no admite
ninguna reserva y otro de ellos, por una limitación de su terminal, sólo acepta el flujo de
audio. Este mismo usuario desea que el audio se traduzca a su lengua materna y, para
eso, emplea a un proveedor que ofrece ese servicio. Le redirige el flujo de audio, este lo
traduce y se lo vuelve a enviar. Para esta comunicación se establece también una reserva
con el proveedor de red.
Los usuarios serán conscientes la sesión de “tele reunión” (video conferencia y
pizarra electrónica) y, si son ellos los encargados de realizar las reservas para los flujos
de audio y video o de pagar por ellas, entonces también serán conscientes de estas
sesiones. La excepción es el usuario conectado a una red que no admite este tipo de
reservas. El usuario que emplea el servicio de traducción también será consciente de la
sesión correspondiente y de la sesión de transporte del flujo de audio entre él y el
proveedor del servicio de traducción. Recalcamos que el servicio de traducción podría
formar parte del servicio de tele-reunión y estar incluido dentro de este y, por lo tanto,
podría quedar “oculto” al usuario. Hay que notar que ningún usuario es consciente de la
sesión que transporta los datos de la pizarra electrónica, pues para transportar esos datos
no se necesita establecer ninguna sesión. Esta perspectiva que los usuarios tienen está
representada en la Figure 17.
- 59 -
A. Cuevas
Tesis Doctoral
IP connectivity
session
IP connectivity
session
Voice transport session
Video transport session
Tr a
on
ssi
se
n
o
i
lat
ns
IP
connectivity
session
IP connectivity
session
Figure 17 escenario: sesiones desde el punto de vista de los usuarios
Consideremos la información manejada por las distintas sesiones y entidades.
Vemos primero los aspectos de tarificación al usuario. Éste tiene que suministrar, en el
establecimiento de sesión, un identificador que le ligue a un contrato y a una forma de
pago. Este identificador (u otro distinto) también debe estar presente para que la otra
parte (por ejemplo el usuario llamado) tenga forma de saber quién le llama. El usuario
también puede facilitar datos de su contexto en el establecimiento de sesión como puede
ser su estado (trabajando, reunido, en casa). Estos se pueden usar, por ejemplo, junto
con otro parámetro que puede indicar la importancia de la sesión para determinar si
dirigirla al usuario o, si se dispone de un contestador, automático enviarla a éste. En
futuros ambientes pervasivos1 los parámetros a intercambiar pueden ser muchos y,
además, depender del tipo de sesión que se esté estableciendo.
No sólo se intercambian y negocian datos relacionados con los usuarios sino
también, y sobretodo, relacionadas con los terminales que estos ocupan. Otros
parámetros a considerar son los que describen y negocian la sesión a nivel de transporte;
estos suelen estar basados en las características de las redes de cada uno de los
interlocutores. Por último hay parámetros que describen e identifican la sesión a nivel
de aplicación. Dicha descripción se asimila a la descripción de la sesión global (nivel de
aplicación y servicio transporte de datos). SDP [RFC2327], SDPng [OTT05] o RSVP
[RFC2205] proponen una nutrida lista de estos parámetros. Por ejemplo:
•
Capacidades del terminal (software y hardware)
1
pervasivos es una palabra inglesa (pervasive) proveniente del latín. En español podría utilizarse
“entrometidos”.
- 60 -
o Audio: Codecs, nº de canales (estereo, mono), ancho de banda (en bits
por segundo), supresión de silencio si / no, etc.
o Video: Codecs, tamaño de la pantalla (pixels), fotogramas por segundo,
etc.
•
Sesión a nivel de transporte de datos
o Capacidades de la red de transporte: Tasa máxima, tasa media, tasa de
pérdidas, etc.
o Identificación de los flujos de la sesión: puertos, direcciones IP.
•
Sesión a nivel de aplicación
o Identificador de la sesión, proxies por los que pasan los mensajes de
señalización, etc.
Entre estos parámetros arriba mencionadas podemos establecer una clasificación
fundamental Figure 18:
1) los que dependen de las prestaciones que suministre una tercera entidad (el
operador de red) estos son, por ejemplo, la tasa máxima de envío/recepción
2) los que no dependen de ningún tercero, como son las capacidades del
terminal (tamaño de la pantalla en pixels etc.)
3) parámetros del terminal pero que pueden adaptarse para cumplir con las
prestaciones de la red; estos pueden ser los codecs.
3rd party (network)
ressource dependent
Parameters:
BW,…
Terminal dependent parameters:
Screen size,…
Mix:
Codecs,…
Figure 18 Clasificación propuesta de los parámetros negociados en el establecimiento de
sesión
Los parámetros que dependen de las prestaciones de una tercera entidad son los
que más retos plantean en la negociación que tiene lugar al establecer la sesión.
Centrémonos en este aspecto. Actualmente, el servicio de transporte de datos no está
- 61 -
A. Cuevas
Tesis Doctoral
diferenciado, lo único que cambia es la tecnología y su capacidad (por ejemplo ADSL
tiene mayor capacidad que GPRS). Pero, para una misma tecnología, todos los usuarios
disfrutan de las mismas prestaciones. En un futuro, es de prever, que se puedan
suministrar diferentes calidades sobre misma red de transporte. Esto creara una
oportunidad para ofrecer distintos servicios de transporte a diferentes precios y dará
lugar a mayor variedad de contratos y más parámetros en los perfiles de usuario. La
sección 3.2 profundizará en este aspecto. Por lo tanto, y esto es fundamental, en el
establecimiento de sesión los parámetros que se intercambian los interlocutores y que
describen las prestaciones de la red estarán relacionados con los perfiles de los
usuarios y los contratos de estos.
Este aspecto plantea nuevos retos para el establecimiento de sesión, retos para
los que propondremos soluciones. Esto lo haremos en siguientes secciones pero por
clarificar este punto al lector imaginemos el caso en que dos usuarios establecen una
llamada. Uno de ellos, según su contrato, puede establecer llamadas con mucha calidad
y ancho de banda, el otro está en el caso contrario. ¿Qué calidad se negociará entre
ambos en el establecimiento de sesión? ¿La más baja? ¿La más alta? ¿Depende de quién
pague los costes? Si se elige esta última opción, en la negociación del establecimiento
de sesión se debe incluir un nuevo parámetro: el reparto de costos.
Incluir en el establecimiento de sesión la “negociación” del reparto de costos
es una propuesta de esta tesis. Otros trabajos existen ([FAN98], [LI04]) pero, más que
en negociar el reparto de costos, se centran en establecer mecanismos para tarificar por
el consumo de servicios de transporte de red con QoS. Hasta ahora, tal negociación no
era necesaria porque los recursos de red se ofrecían, en la mayoría de los casos, en
modalidad de tarifa plana. Pero esto, en un futuro, puede no ser así, tal como
analizaremos en la sección 3.2.
La negociación del reparto de costos es fundamental. De su resultado dependen
muchos de los parámetros que caracterizan una sesión, como hemos visto en esta
sección. Por ejemplo, en la negociación que tiene lugar durante el establecimiento de
sesión, el llamado puede aceptar un ancho de banda elevado y un codec que aproveche
ese ancho de banda ofreciendo alta calidad si quien paga por el servicio es el llamante.
Como hemos no hay aún propuestas que permitan elegir unos parámetros u otros en
función de quién pague la costos de la sesión. En esta tesis proponemos una solución
directa: incluir en los parámetros de negociación de la sesión que parte del precio se está
dispuesto a pagar. En esta sección y a lo largo de la tesis detallaremos esta propuesta.
Hay muchos aspectos que añaden complejidad al reparto de costos. Primero, en
un futuro será muy común tener sesiones entre varias partes (ahora suele ser entre dos,
el llamado y el llamante) y el reparto de los costes entre los participantes puede estar no
muy claro. Por ejemplo, dos personas establecen una sesión entre si y deciden invitar a
otra persona. ¿Cómo se repartirán entre el costo de añadir a este nuevo interlocutor? ¿O
el costo lo asumirá el nuevo conferenciante? Otro aspecto que añade complejidad es que
los servicios ofrecidos en un futuro serán más ricos y formados por varias subsesiones.
De nuevo, un ejemplo sirve para ilustrar este concepto. Pongamos un servicio de
reunión a distancia. Este servicio está formado por el servicio de pizarra compartida y
por el de video conferencia, a su vez formado por el servicio de audio y por el de video.
De los participantes en esta reunión virtual puede haber quienes quieran disfrutar con
mucha calidad el servicio de pizarra y el de audio y estén dispuestos a pagar por ello,
pero no así en el caso del video. La solución que proponemos es añadir a cada
- 62 -
parámetro que implique un coste (con el operador de red) el % que se está dispuesto a
pagar. Como veremos en futuras secciones estos parámetros pueden estar enfocados a
distintos niveles, desde “pagaré el X % de la recepción del flujo Y a Z kbps” a “pagaré
X % del servicio de video de alta calidad y W % por el de baja”.
3.1.2 Interlocutores -Proveedores de ServicioDe entre todas las partes que puede haber involucradas en la sesión, tratamos
aquí con los interlocutores pero, a diferencia de la anterior sección, consideramos aquí a
los interlocutores que son proveedores de servicio. Estos prestan un servicio a los
usuarios y les pueden cobrar por ello. Los usuarios de este servicio pueden ser
“particulares”, lo que nos lleva al caso conocido por su nombre en inglés “business to
consumer”. También pueden ser otros proveedores de servicio (es el caso “business to
business”). Los servicios ofrecidos pueden ser desde descarga de canciones mp3 a un
servicio de información telefónica. A estos servicios se les suele llamar servicios de
valor añadido, para distinguirlos del servicio de transporte de datos ofrecido por el
operador de red. La sección 3.2 detallará más estos servicios.
Para esta entidad la sesión es el servicio por el que cobra. El pago puede
provenir directamente del usuario o, según algunos de los modelos de negocio de la
sección 3.2, de otras entidades que hagan de intermediarios. El servicio o la sesión,
puede sólo ser un subservicio del servicio total que se ofrece (y cobra) al usuario. Por
ejemplo, en el caso de una descarga de canciones mp3 podemos decir que este es el
servicio en sí; en cambio, la traducción automatizada e instantánea con reconocimiento
y síntesis de voz puede ser parte de un servicio de “tele reunión”. Este último caso
merece una consideración más profunda: al usuario se le puede vender un servicio de
“tele reunión” y este servicio, en una relación “business to business”, contratar con otro
proveedor de servicios, el servicio de traducción automática. Esto muestra, de nuevo,
como un servicio puede estar disgregado en varios subservicios y subsesiones.
Estas entidades controlan la sesión, pueden esperar a que un usuario u otro
proveedor de servicio la inicie o pueden iniciarla ellos mismos. Tienen también
visibilidad de la sesión de transmisión de datos y pueden controlarla en vez del usuario,
por ejemplo en un servicio de transmisión de noticias (“streaming”) puede ser el
proveedor del servicio quien se encargue de establecer con el proveedor de red el
servicio de transporte de datos hasta el usuario.
El escenario presentado en la sección 3.1.1, desde el punto de vista del
proveedor de servicios (el servicio de traducción) se percibirá así:
Este proveedor de servicio verá la sesión que establece con el usuario y también
la sesión de transporte de datos que establece con el proveedor de red (recodemos que
dijimos que los flujos de voz requerían una reserva de QoS). Notemos que este servicio
podría encargarse completamente de esta sesión de transporte de datos y ocultársela al
usuario.
- 63 -
A. Cuevas
Tesis Doctoral
IP connectivity
session
Tr a
n
n
tio
sla
ssi
se
on
IP connectivity
session
Figure 19 escenario: sesiones desde el punto de vista de un proveedor de servicio
Los datos de la sesión que los proveedores de servicio manejan pueden ser:
•
su identificación. Los servicios se deben identificar. Esto cobrará más
importancia en el futuro y, sobe todo, en entornos pervasivos (entrometidos). Lo
que se persigue es poder descubrir los servicios ofrecidos y a los que se tiene
acceso.
•
No sólo los servicios se deben identificar, también deben ofrecer sus
características. Esto tiene dos fines. Primero para poder hacer composición de
servicios, incluso con el servicio de transporte de datos. En este caso se
considerarán parámetros como el ancho de banda o el retardo requeridos.
Segundo, en ciertos modelos, el proveedor de servicio no tendrá los datos del
usuario los tendrá una tercera entidad. Esa entidad, con datos sobre el servicio
ofrecido (por ejemplo tipo de película) y los del perfil del usuario (edad)
decidirá si el usuario está autorizado a recibir ese servicio (la recepción de la
película).
•
Los provedores de servicio necesitan proveer datos sobre el costo del servicio,
para informar al usuario o a terceras entidades que vayan a efectuar el cobro al
usuario.
•
Evidentemente necesitaran datos sobre los usuarios desde, por ejemplo, su
localización, el tipo de Terminal(es) que están usando etc. para pode adaptar el
servicio al contexto del usuario. Si son ellos mismos los que van a cobrar al
usuario necesitan saber si éste dispone de fondos. Además, si son los encargados
de autenticar al usuario y de autorizarle necesitarán su identificación y también
ciertos datos de su perfil de usuario, como pude ser la edad, para así establecer si
el usuario está autorizado a consumir el servicio o no.
3.1.3 Proveedor de Red
El servicio fundamental que ofrece la red de telecomunicaciones es el transporte
de datos entre los interlocutores de la sesión. Es un subservicio poco “visible” (los
usuarios suelen ser conscientes de servios como llamadas o correo electrónico pero no
de transmisión de datos). Eso sí es un servicio imprescindible para que todos los demás
se puedan dar ya que transporta los datos de todos los servicios y las sesiones.
- 64 -
Partiendo de la base que las redes 4G serán redes IP y como IP es una tecnología
no orientada a conexión, si sólo se ofrece IP “Best Effort” la red no necesita manejar ni
ser consciente de ningún tipo de sesión para ofrecer el servicio de conectividad IP.
Salvo en determinados modelos de negocio que veremos en la sección 3.2 en donde se
hace participe a la red de las aplicaciones asociadas a esos flujos, la red, en principio, no
sabe ni controla los servicios de valor añadido que dichos flujos de datos hacen
posibles.
Si sobre su red el operador acopla mecanismos de QoS con reserva de recursos,
como puede ser el conocido modelo IntServ, entonces la red maneja un concepto de
sesión asociado a estas reservas. De hecho, la red es una parte activa en esa sesión, la
red puede decidir el principio y el fin de esta sesión. Las otras entidades que citamos en
este capítulo necesitan negociar con ella (por ejemplo usando RSVP) para establecer la
mencionada sesión. La particularidad de esta negociación es que normalmente será a
“tres bandas”, dicho más formalmente entre los –normalmente dos- interlocutores y la
red.
En el caso DiffServ también se pueden establecer sesiones para controlar los
bytes que cada usuario envía para las distintas clases de servicio. Pero si no hay un
protocolo explícito, como es RSVP en el caso IntServ, para establecer y terminar las
sesiones, el concepto y los parámetros de la sesión pueden tomar distintas formas como
veremos en la sección 4.1.1.1.
Los parámetros usados para describir las sesiones en las que interviene el
proveedor de red describen la QoS a nivel de red; estos pueden ser ancho de banda
medio y máximo, retardo, etc. ([RFC2205], [RFC2327]). Estos parámetros deben incluir
un identificador de los flujos de datos involucrados en la sesión (para saber a qué flujos
suministrar la QoS negociada en la sesión). En IPv6 ese identificador puede ser el “flow
label” junto con las direcciones origen y destino. Las soluciones clásicas sustituyen el
“flow label” por los puertos y el protocolo de nivel 4.
Hasta aquí no hemos hablado de tarificación. La red ofrece un servicio de
transporte de datos, aunque sea “best effort” y por ello cobrará a los usuarios. Este
servicio de transporte se ofrece a los paquetes de datos y habrá que poder asociar esos
paquetes a los usuarios para poder tarifar a estos últimos. La asociación de flujos de
datos a usuarios y a las sesiones en las que estos participan es una contribución de
esta tesis que detallaremos a lo largo de varias secciones. Respecto a la tarificación, esta
se podrá hacer directamente sobre las sesiones de red que se establecieron o, si estamos
en un caso sin establecimiento de sesión a nivel de red (típicamente servicio best effort),
la sesión de tarificación puede asociarse a una sesión que controle la presencia del
usuario en la red. Debemos señalar que, por cuestiones de tarificación o políticas de
negocio, a parte de la sesión de conexión a la red, se pueden establecer sesiones para
controlar los datos inyectados y recibidos por el usuario, aunque esto no sea necesario
por la tecnología empleada (por ejemplo el caso “best effort”). Los datos de tarificación
manejados serán a nivel de red como por ejemplo, € por minuto de reserva de QoS o €
por Mb enviados a determinada cadencia.
Volviéndonos a referir al escenario presentado en la sección 3.1.1, la perspectiva
que tendrá el proveedor de red es la que detallamos a continuación. Éste “verá” todas las
reservas hechas para transportar flujos de datos y, también, las sesiones de conectividad
a la red. En cambio, los datos transportados sin necesidad de establecer ninguna sesión
- 65 -
A. Cuevas
Tesis Doctoral
específica de transporte (por ejemplo la información de la aplicación de pizarra
electrónica) no serán “vistos” por la red. Esta situación se ilustra en la Figure 20.
IP con ne ctivity
se ssio n
IP
co nn ectivity
se ssion
n et wo rk
Vo ice tran spo rt se ssio n
Voice transp ort session
Vo ice tran spo rt sessio n
Vide o tran sport session
IP co nn ectivity
session
IP con ne ctivity
se ssio n
IP co nne ctivity
se ssion
Figure 20 escenario: sesiones desde el punto de vista del proveedor de red
3.1.4 “Mediadores” en el establecimiento de sesión
Los “Mediadores” no participan en la sesión como hacen los interlocutores,
tampoco tienen el rol del proveedor de servios ni transportan los flujos de datos de la
sesión. Su papel es prescindible pero, aún así, en la mayoría de las soluciones son una
parte fundamental. Ayudan a los usuarios a establecer la sesión y esta “asistencia”
puede cubrir aspectos clave como el servicio de directorio y otras ventajas como el
desvío inteligente de llamadas. En el caso de SIP los mediadores son los SIP Proxy.
Al ser mediadores, su noción de sesión será la suma de las nociones de sesión
de las partes a las que asisten y de las entidades con las que interactúan. Por ejemplo, si
asisten a dos usuarios haciendo una llamada y, además, les asisten para hacer la reserva
de QoS con el operador de red, su noción de sesión es la sesión de la llamada más la
sesión de transporte de datos.
De nuevo nos referimos al escenario de la sección 3.1.1. Recordemos que allí
mencionamos que para establecer la sesión de tele reunión los usuarios usaban un
mediador. Este mediador verá por lo tanto las sesiones a nivel de aplicación de la telereunión. Si este fuera el encargado de realizar la reserva para los flujos transportando
los datos (audio y video) de la sesión también sería consciente de esas sesiones pero, de
nuevo, recordemos que estas reservas las hacían los usuarios y, por lo tanto, quedan
ocultas al mediador. El mediador también podría gestionar el servicio de traducción y,
así tal vez, hacerlo “transparente” al usuario. Pero dijimos que este no era el caso, de
hecho el servicio de traducción es completamente independiente del mediador. La
Figure 21 representa este caso.
- 66 -
Figure 21 escenario: sesiones desde el punto de vista del mediador
Los parámetros que manejan son los expuestos en las anteriores secciones y
dependerán de con qué entidades el mediador interactúe. Por ejemplo si no interactúa
con el operador de red, puede no considerar parámetros como el ancho de banda. Los
mediadores necesitan conocer los parámetros negociados durante el establecimiento de
sesión, por ejemplo para saber a qué terminal de los múltiples en los que está registrado
el usuario dirigir una sesión. Por ejemplo si el usuario está registrado en una PDA y un
ordenador, y la sesión necesita una pantalla de gran tamaño el mediador puede dirigir la
llamada al ordenador. Los mediadores no inician las sesiones pero pueden terminarlas o
alterarlas, por ejemplo si el operador de red les informa que la red de acceso de uno de
los usuarios está congestionada, pueden alterar los parámetros de la sesión (en concreto
sus requisitos de QoS a nivel de transporte. Los mediadores, durante el establecimiento
de la sesión (o en cualquier otra fase que genere señalización que los “atraviese”)
pueden alterar los parámetros de los mensajes de señalización por ejemplo porque saben
que el ancho de banda que intenta negociar un usuario no está disponible en la red del
otro interlocutor.
3.2 Modelos de negocio, análisis de requisitos
Hemos visto en la sección 3.1 que en una sesión puede haber involucradas varias
entidades y que cada una de ellas maneja distintos aspectos de la sesión y/o de las
subsesiones. Veremos cómo, con las adecuadas relaciones entre esas entidades, se
pueden crear ventajas para el usuario. Estas relaciones definen unos modelos de negocio
u otros. Estos se basan, fundamentalmente, en determinar qué entidad(es) gestionan la
relación con el usuario y el cobro de los servicios. Analizaremos los modelos de
negocio, sus ventajas y las posibilidades que tienen de ser adoptados por los usuarios.
Un requisito fundamental para materializar esas relaciones y modelos de negocio es la
agregación de las distintas subsesiones que forman un servicio. Esta tésis estudiará
cómo cumplir con ese requisito de agregación de sesiones y veremos cómo esto está
especialmente vinculado al establecimiento de sesión. Un pilar básico de los modelos de
- 67 -
A. Cuevas
Tesis Doctoral
negocio son los contratos y los perfiles de usuario que estos definen. Estos aspectos
serán tratados en la segunda subsección de esta parte.
3.2.1 Modelos de negocio, análisis de sus prestaciones
En esta sección describiremos los distintos modelos de negocio. Antes
introduciremos el concepto de “servicio” y las características que cualquier modelo de
negocio debería ofrecer.
3.2.1.1 Tipos de sevicio y requistios para componer servicios
Los servicios dentro de el campo de telecomunicaciones son actualmente muy
numerosos y diversos. En el futuro, el abanico será incluso más amplio llegando incluso
a lo que llamamos modelo pervasivo. Estos servicios se pueden clasificar en dos
grandes tipos:
o “Servicios habilitadores” (Enabling Services –ESs-). Estos servicios pueden incluir
desde un servicio de transporte de datos a entregar la localización del usuario a una
compañía que ofrezca la lista de los restaurantes más cercanos al usuario.
o Servicios de valor añadido (Value Added Services –VAS-). Servicios que son
“visibles” para el usuario y que proporcionan el servicio a ese usuario final. Esos
servicios pueden ser politonos, información basada en localización (e.g. lista de los
restaurantes vegetarianos más cercanos), llamadas de voz, etc. Además, el ES se
puede esencialmente vender como un VAS –dependerá, sobre todo, del enfoque que
se dé-. Por ejemplo, una conexión IP superior 1Mbps puede ser un ES, pero si se
vende como una forma de acceso a Internet para los usuarios se convierte en un
VAS.
La división terminológica entre los ES y los VAS se mantiene ya que identifican
funciones bien definidas dentro del mercado actual de las telecomunicaciones. En esta
tesis se usará esta terminología: El ES será, esencialmente, un servicio de transporte con
QoS, al que llamaremos, por abreviar sólo transporte o QoS. Los VAS serán todos los
servicios que funcionan encima de él, por ejemplo los que está enumerados en la Figure
22.
- 68 -
Figure 22 VAS en el mercado de las telecomunicaciones
Además, en las redes 4G futuras, los usuarios también serán capaces ellos
mismos de ofrecer servicios. Un ejemplo es la redes ad-hoc donde un usuario puede
proporcionar a otros usuarios el servicio de conectividad a Internet a través de su
dispositivo. Esta cantidad enorme de servicios exacerbará el problema de fragmentación
de sesión presentado en la sección 3.1.
Uno de los puntos claves para lograr una agregación de servicios y sesiones que
aporte ventajas a los usuarios y a los proveedores, será proporcionar facturación no
duplicada y unificada aunado con características de “single sign-on”. Esto implica que
una entidad tendrá el contacto directo con el usuario mientras las otras puede que no
mantengan ninguna relación con el usuario. Antes de proseguir detallemos más estos
conceptos:
o “single sign-on”: permite al usuario registrarse y autenticarse con sólo una
entidad. Esta autenticación es utilizada por todas las otras entidades para
autorizar al usuario los servicios que proporcionan.
o “Facturación no duplicada”: Expliquemos este concepto utilizando un
ejemplo. Un usuario con una conexión de GPRS facturada por la cantidad de
Mb mandados y recibidos (e.g. 0,10 € por Mb) descarga una canción de 3
Mb, por la que paga 1 €. El usuario necesitará también pagar los 0,30 € que
cuesta el tráfico originado por esta descarga. Con facturación no duplicada el
usuario pagará 1.3€ por la canción (y 0 para los datos transportados).
o “Facturación unificada” se explicará siguiendo el mismo ejemplo. Si esta
característica no se permite, el usuario recibirá dos facturas, una del operador
de red, la otra del proveedor de contenidos. Con, “Facturación unificada”, el
usuario recibirá una sola factura (emitida por el proveedor de servicio, el
operador de red o por terceros). Esta factura tendrá dos conceptos si
- 69 -
A. Cuevas
Tesis Doctoral
“Facturación no duplicada” no se aplica y sólo un concepto (la descarga de la
canción) si sí.
Las ventajas de agregar las sesiones no son sólo los tres aspectos antes
mencionados. Los servicios finales pueden ser también más ricos si hay una
colaboración entre la red y el servicio (y entre todos los sub-servicios que forman el
servicio final). El servicio puede necesitar el conocimiento del contexto actual del
usuario (por ejemplo, su ubicación, el idioma preferido etc.), y una fuente adecuada –
aunque no la única posible- para obtener esta información es la red. Además, el servicio
integrará las capacidades de la red como parte de su funcionalidad. Llevando esto a los
extremos, el servicio llega a ser completamente dependiente de la información proveída
y gestionada por la red.
Estudiaremos los diferentes modelos de negocio, analizando las posibilidades
que tienen para lograr las características antes planteadas.
3.2.1.2 El modelo de negocio Internet
El modelo “abierto” es el modelo de negocio usado en Internet, donde cada parte
involucrada es, generalmente, una organización distinta. La aplicación, el dispositivo de
acceso (PC, ordenador portátil, Terminal de VoIP) y el transporte de datos son
controlados cada uno por entidad distinta, y el proveedor de red se ve típicamente como
un mero “transportista de bits”. La Figure 23 representa esta situación.
Trust
relationship
3rd
Party Service Providers
Trust
relationship
Trust
relationship
Network operator
Trust
relationship
3rd
Trust
relationship
Figure 23 Business relations in the internet business model
El usuario tiene acceso a todos los servicios disponibles dentro y,
principalmente, fuera del operador de red. Conseguir el acceso a todos esos servicios es
tan fácil como pagar una tarifa plana mensual al proveedor de la red por su servicio de
acceso a Internet. Como los servicios (tanto VAS como ES) están controlados por
entidades diferentes y con protocolos diferentes, en el modelo Internet, la
interoperabilidad de protocolos y servicios no se asegura. Este modelo no proporciona
- 70 -
ninguna posibilidad para la agregado de sesiones ni ninguna de las características antes
vistas. El concepto de sesión se dispersa entre todas las entidades, como indicado en la
sección 3.1.
3.2.1.3 El negocio de los operadores móviles. Modelo “Walled Garden”
El modelo "Walled Garden" se hereda del modelo clásico de proveedor de
telefonía. El término "Walled Garden" se acuñó para describir a un cliente “cautivo” en
un negocio donde, salvo el operador de red, nadie podía entrar. Este modelo es utilizado
también por los proveedores de telefonía móvil. Se definen un conjunto de protocolos y
parámetros operacionales para proporcionar un servicio bien definido al usuario. El
usuario no puede acceder a servicios que están fuera del operador de red. El proveedor
de red es visto típicamente como una entidad que proporciona los servicios (las
llamadas, SMS) y no como un mero "transportista de bits". Este modelo simplifica
varios aspectos, tal como la seguridad, la autorización, y facturación. La red entera se
considera segura y está controlada por una sola entidad. La Figure 24 representa este
modelo de negocio.
Network operator &
Service provider
Pays for data
transport and
for services
Trust
relationship
Figure 24 Business relations in the “walled garden” business model
La agregación de sesiones y subsessions se lleva fácilmente a cabo ya que todas
ellas son proporcionadas por la misma entidad. Pero, incluso si este modelo puede
afrontar todos los requisitos presentados antes, como dijimos en la introducción, las
redes 4G lo invalidarán. Las redes 4G “llevarán” directamente Internet al dispositivo del
usuario y, por lo tanto, permitirán acceder a cualquier servicio fuera del proveedor de
red. Además, en las redes 4G, los operadores de red colaborarán con proveedores de
servicio para ofrecer más servicios en sus redes. La introducción mostró porqué las
redes 4G seguramente llegarán a ser una realidad pero debemos diseñar modelos de
negocio que sitúen al operador de red en el centro de la cadena de valor. Esta es la única
forma para impulsar la migración a redes 4G. Uno de esos modelos es el “Semi Walled
Garden”.
3.2.1.4 El modelo “Semi-Walled Garden”
El modelo “Semi Walled Garden” es una combinación del modelo abierto de
Internet y del modelo cerrado de las telecomunicaciones “clásicas”. En este modelo se
- 71 -
A. Cuevas
Tesis Doctoral
permite acceder a servicios situados más allá del dominio del operador de red. El
operador alentará que el usuario acceda a proveedores de servicio que tengan un
acuerdo con el operador de red. Normalmente el usuario pagará al operador de red y
éste al proveedor de servicio, reteniendo un %. La red mantiene la relación con el
cliente y puede compartir con el proveedor de servicios algunos de los datos de los
usuarios. El operador se convierte en un gestor y agregador de servicios. Esto
permitirá disfrutar de características como “single sign-on” antes expuestas. Un ejemplo
particular es el servicio i-mode de NTT DoCoMo, donde conseguir acceso a
proveedores de servicio situados en Internet se permite, con tal de que los proveedores
cumplan algunos requisitos. La Figure 25 representa esta situación.
3rd
Trust
relationship
Pays for the service
(retains a %)
Network operator
Pays for data
transport and
for 3rd Party
services
Trust
relationship
Figure 25 business relations in the “semi walled garden” business model
La idea básica del modelo “semi walled garden” es la agregación de sesiones
hecha por el operador de red que entonces puede ser “consciente” y partícipe en las
sesiones de servicios de valor añadido, además de transportar los datos de esas sesiones
(sección 3.1). La cooperación entre proveedores de red y de servicios debe redundar en
beneficios para el usuario. Esta agregación de sesiones permite ofrecer características
como el “single sign-on” pero, además, posibilita coordinar aspectos como calidad de
servicio a nivel de red y de aplicación y ofrecer un servicio unificado al usuario, tal
como en el modelo de telefonía actual, pero con el valor de los múltiples proveedores de
servicios que estarán presentes y coordinados con la red. Debemos enfatizar que será la
mejor calidad de los servicios la que empujará al usuario a emplear proveedores de
servicio con acuerdos con el operador de red. De no ofrecer incentivos al usuario, éste
empleará proveedores de servicio sin ninguna relación con el proveedor de red, cayendo
así en el modelo Internet.
Notemos que el operador de red puede ser dueño de parte de los proveedores de
servicio. Estos, incluso, pueden estar completamente integrados en su infraestructura.
Un candidato claro para esto son los mediadores que se presentaron el la sección 3.1.4.
Estos mediadores gestionarán los servicios claves en las redes de telecomunicación:
comunicaciones entre personas como llamadas de voz o SMSs. Esto es precisamente la
filosofía de IMS. Estos mediadores son clave para lograr el agregado de sesiones y este
- 72 -
agregado será realizado por el operador de red. Por ejemplo, en los escenarios
presentados en la sección 3.1, los mediadores pueden encargarse de gestionar tanto el
establecimiento de la sesión de tele-reunión como de la reserva de QoS con el operador
de red, ocultando este último aspecto a los usuarios. Sin embargo, como veremos en
próximas secciones, los mediadores no son las únicas entidades capaces de cohesionar
las distintas sesiones.
El modelo “semi walled garden” es bastante probable de ser aceptado por los
usuarios puesto que, normalmente, las personas son reacias a difundir sus datos tal
como números de cuenta bancaria. En este modelo, gracias al “single sign-on” los
usuarios sólo necesitan dar esos datos a una entidad. Este modelo asume que esta
entidad será el operador de red. Esto es bastante razonable: el operador de red
proporciona la red y así es el primer y básico contacto para todos los servicios. Además,
los usuarios han asumido que los operadores de red son entidades en las que se puede
confiar y no temen, por ejemplo, suministrarles sus datos de cuenta corriente o comprar
tarjetas prepago. El éxito del i-mode en Japón (más de 31 millones de suscriptores en
febrero 2002, brevemente después que el servicio se lanzó) demuestra que el modelo
“semi walled garden” con el operador de red en el centro de la cadena de valor puede
tener un gran éxito.
Esta tesis también considera un modelo de negocio “simétrico” al “semi-walled
garden”. Este modelo también se basa en la asociación entre el operador de red y los
proveedores de servicio. Hay también una entidad que centraliza la relación con el
usuario pero esta entidad, en vez de ser el operador de red, es un proveedor de servicio.
Es por esto por lo qué decimos que este modelo es “simétrico” al modelo “semi-walled
garden”. Esta entidad coordinará todos los aspectos relacionados con el servicio, desde
la aplicación al transporte de datos con QoS hecho por la red. Un ejemplo de tal modelo
representará su funcionamiento y utilidad. Imaginemos una marca de automóviles que
recomienda a sus clientes pasar una revisión cuando el coche alcanza 30 000 kilómetros.
Cuando el coche está cercano a este kilometraje, transmite su estado a los servicios
post-venta del coche. De modo que, cuando el dueño lleva su coche al mecánico para
pasar la revisión, el garaje haya pronosticado las piezas necesarias para la reparación y
las haya encargado. Así, el tiempo que el coche debe permanecer en el mecánico se
reduce. En la factura, se reflejarán los costos de la revisión y eventuales reparaciones y
estos incluirán la transmisión del estado del coche. Aquí el operador de red ha perdido
totalmente cualquier relación del cliente. El operador de red sólo tiene un acuerdo con la
marca del coche para transmitir esos datos.
Este modelo proporciona las mismas ventajas para el usuario que el modelo
“semi walled garden” donde el operador de red juega el papel de entidad central. Pero
tales modelos serán rechazados por los operadores de red y por los proveedores de
servicio que no jueguen el papel central. Pensamos que este modelo será utilizado
solamente en escenarios muy específicos tales como el que está representado arriba.
La tercera variación es que la entidad que agrega las sesiones y que tiene la
relación del cliente no sea ni el proveedor de red ni el de servicios sino una entidad que
actúa como “broker”. Esta entidad puede existir pero no de forma independiente; será
parte del negocio del operador de red.
- 73 -
A. Cuevas
Tesis Doctoral
3.2.1.5 Dueños de puntos de acceso “WiFi”
El éxito comercial de la tecnología Wi-Fi y su despliegue fácil (tecnología de
fácil uso y ninguna licencia gubernamental necesaria) ha introducido nuevos modelos
de negocio. La particularidad es que el dueño de la red de acceso ya no es un operador
de telecomunicaciones pero, lo que en terminología anglosajona, se denomina los
“venue-owners”; es decir los dueños del emplazamiento del punto de acceso WiFi
(hoteles, aeropuertos, etc.). La relación entre los dueños del emplazamiento y el
proveedor de red es una relación entre dos “operadores de red” no entre un operador de
red y un proveedor de servicio, como en los casos anteriores. En este caso el servicio de
transporte de la red se fragmenta entre distintas partes. La agregación de los servicios de
red es también muy importante. Si no se consigue, surgirán escenarios donde los
usuarios tienen que pagar a un operador de red celular y también a una serie de “venue
owners”. El modelo de negocio que parece que se va a imponer es que el operador de
red también gestione el acceso de sus usuarios a estas redes WiFi. Los operadores de red
pagarán a los “venue-owners” por usar su red. Este pago puede ser tan sólo el
mantenimiento su infraestructura WiFi. Disponer de ésta puede ser una ventaja
competitiva, por ejemplo en hoteles y aeropuertos, y estas entidades no tienen por
objetivo sacar beneficio económico de ellas sino ofrecer esa ventaja a sus clientes. Eso
sí, requerirán que cualquier usuario, de cualquier operador de red, pueda conectarse a su
red WiFi.
3.2.2 Propuestas de gestión de los perfiles de usuario
Una parte fundamental de los modelos de negocio consiste en gestionar la
relación con el usuario. Esto implica la firma de un contrato y la generación de
información que será compartida y gestionada por ambas partes. Parte de la información
generada al establecer un contrato es el “perfil de usuario” y su gestión es clave en los
distintos modelos de negocio.
3.2.2.1 Contratos, identidades y perfiles de usuario
Cuando un usuario desea consumir un servicio debe antes firmar un contrato;
matizaremos esto afirmación más adelante pero de momento nos centraremos en las
implicaciones de ese contrato. Cuando se firma un contrato se crea lo que llamamos un
perfil de usuario que contendrá datos para autenticar (identificar) al usuario (firmante
del contrato). Además, el perfil del usuario tendrá datos necesarios para poder prestar
ese servicio y poder cobrarlo (como un número de tarjeta de crédito). Como veremos en
esta misma sección, la gestión y el almacenaje de los perfiles de usuario son aspectos
claves en los modelos de negocio analizados en la anterior sección.
Bien es verdad que muchos servicios se prestan sin firmar un contrato; o, al
menos, aparentemente. Por ejemplo si se usa el servicio de telefonía móvil prepago, tan
sólo por “comprar” ese servicio se aceptan los términos del contrato (por ejemplo
precios y compensaciones si el operador falla al prestar el servicio). Además, se
identifica al usuario frente al operador. El usuario será para el operador un “número”, y
el operador tendrá formas de garantizar su autenticidad. Pero el operador no sabrá su
verdadera identidad -el nombre del usuario (asumiendo que el nombre identifica a una
persona). Para autenticarse frente al operador, el usuario usará la contraseña (PIN) que
se le suministra al comprar el servicio prepago. Otro ejemplo de servicios que no
requieren aparentemente una firma de contrato son los que se prestan “una sola vez” o
- 74 -
que generan una única transacción. Por ejemplo la compra y descarga de una canción en
Internet. Aquí, de nuevo, al aceptar el servicio el usuario acepta las condiciones del
mismo. El usuario no necesita identificarse frente al proveedor del servicio, puede sólo
suministrar una forma para que el proveedor compruebe que el usuario (que si está
identificado con, por ejemplo, un servicio de tarjeta de crédito) pagará por el servicio.
La anterior discusión pone en evidencia un aspecto fundamental, una misma
persona puede identificarse de distintas formas y presentar distintos datos a los distintos
proveedores de servicio o de red. En las redes 4G la gestión eficiente de esas distintas
identidades virtuales será un aspecto clave. Esta tesis no desarrollará este tema pues,
para el establecimiento de sesión, sólo necesitamos centrarnos en la gestión de los
distintos perfiles de usuario sin considerar las identidades virtuales a las que están
asociados. Aún así, no está de más que clarifiquemos el concepto de identidad virtual y
para ello usaremos un sencillo ejemplo. En el ejemplo veremos como una misma
identidad física (la persona en sí) puede tener asociadas varias identidades virtuales
(usuario de biblioteca, cliente de banco, etc.). Cada una de estas identidades tiene
asociados unos datos: el perfil de usuario asociado a la identidad.
Identidad física: Ciertos de esto datos sólo serán accesibles por la policía.
Nombre, datos biométricos (ejemplo huellas dactilares, fecha nacimiento, etc.
Ejemplo 1 de identidad virtual (contrato): usuario de biblioteca. Necesita
suministrar ciertos datos de su identidad física, el nombre, el domicilio (ejemplo para
que la biblioteca pueda reclamar libros prestados). Datos que se pueden asociar a esta
identidad: número de libros prestados, etc.
Ejemplo 2 de identidad virtual (contrato): cliente de un banco. Tendrá datos
relacionados con la cuenta, puede no necesitar siquiera suministrar el nombre de la
persona
Ejemplo 3 de identidad virtual (contrato): Identidad genérica de comprador.
Puede acceder a ciertos datos relacionados con la identidad cliente de un banco, como
ver si hay fondos como para pager el servicio que se está consumiendo. También puede
acceder a ciertos datos de la identidad física, como la fecha de nacimiento (por posibles
descuentos).
3.2.2.2 Perfiles de usuario: el NVUP y contratos con los proveedores de servicio
Como hemos dicho, esta tesis sólo necesita de los perfiles de usuario (términos
del contrato) asociados a las identidades. Vamos a describir lo que pueden ser estos
perfiles de usuario en las futuras redes 4G.
Si el servicio considerado es el de transporte de bits, el perfil de usuario, que
proponemos llamar NVUP (en inglés Network View of User Profile), puede tener una
forma parecida a la de la Table 3:
BE
Envío
Precio
de 0 a 64
kbps a
1€/Mb
de 64kbps
Restricciones Observaciones
Máximo 1
Disponible en
Mbps
roaming con
50% de
incremento en
Recepción
Precio
Restricciones
de 0 a 64 Máximo 2
kbps a
Mbps
0,5€/Mb,
de 64
- 75 -
Observaciones
Disponible en
roaming con 50%
de incremento en
el precio
A. Cuevas
Tesis Doctoral
el precio
Disponible en
puntos WiFi
públicos con un
máximo de 2
Mbps
en adelante
1,5€/Mb.
De 20:00 a
8:00
descuento
50%
prepago
AF1 de
1,5 € Mb
128 kbps prepago
Máximo 128
kbps
EF
No
disponible en
este contrato
Ráfagas
No disponible
permitidas
en roaming ni
en puntos WiFi
públicos
Ráfagas
No disponible
permitidas
en roaming ni
en puntos WiFi
públicos
No
disponible en
este contrato
Reserva 1 € minuto
RSVP de
64 kbps
Reserva 3 € minuto
RSVP de
128 kbps
Reserva
RSVP de
256 kbps
Disponible en
roaming con
50% de
incremento en
el precio
No Disponible
en puntos WiFi
públicos
kbps en
adelante
1,5€/Mb
de 20:00
a 8:00
descuent
o 50%
prepago
1,5 € Mb Máximo 128
kbps
1€
minuto
3€
minuto
Disponible en
puntos WiFi
públicos con un
máximo de 3
Mbps
Disponible en
roaming con 50%
de incremento en
el precio
No Disponible en
puntos WiFi
públicos
No
disponible en
este contrato
Ráfagas
No disponible en
permitidas
roaming ni en
puntos WiFi
públicos
Ráfagas
No disponible en
permitidas
roaming ni en
puntos WiFi
públicos
No
disponible en
este contrato
Table 3 Perfil de usuario con un proveedor de red (NVUP)
Un detalle que vemos en la Table 3 es que en el NVUP, incluso el ancho de
banda “best effort” (sin garantías), está limitado y tarificado en distintos tramos. Esto
tendrá implicaciones que más adelante veremos en el control que la red debe hacer
sobre este servicio. Por otra parte, hoy en día, los contratos para el transporte de datos
son mucho más simples (por ejemplo tarifa planas) y es lícito preguntarse si en el futuro
llegarán a complicarse tanto. La tendencia es que sí. Por ejemplo el presidente de
Deutsche Telekom declaró en [WIW06]: “si los consumidores no están dispuestos a
pagar y Google y otras tampoco, no habrá redes de banda ancha” En ese mismo artículo,
se cita a otro trabajador de Deustche Telekom, Mark Nierwetberg, que comentó la
posibilidad de seguir con el modelo de tarifa plana para la conexión a Internet pero, para
servicios (y las compañías que los ofrecen) que necesitan mucho ancho de banda,
emplear otros mecanismos de tarificación.
Come es lógico, aunque los contratos “NVUP” sean así de complejos, no se
expondrá esa complicación al usuario. Las aplicaciones se encargarán de gestionarla, y
presentarán un interfaz sencillo al usuario.
Los perfiles de usuario para los servicios de valor añadido, serán tan diversos
como éstos. Aquí en Table 4 y Table 5 sólo podemos dar un ejemplo para varios
servicios.
Precio
Restricciones
Observaciones
Descarga de música 1 € / canción para las de Longitud máxima Con el operador X se
- 76 -
mp3
mínima calidad
2 € / canción para las de calidad
media
entre las 22:00 y las 10:00
todas las canciones al mismo
precio: 1 €
Servicio de noticias 1,5 € por hora para calidad
en directo (video + media
audio)
2 € por hora para calidad alta
Descuento 50 % de 22:00 a
8:00
de la canción 5 asegura la descarga en
menos de 2 minutos
Mb.
Alta calidad no
disponible
Sólo disponible si el
usuario tiene contrato con
el operador Y
Table 4 Perfil de usuario con un proveedor de contenidos
Almacén de datos
Precio
Restricciones
1€ / Gb para datos no replicados en otro
país, 2€ / Gb cuando los datos se replican
en otro país
Observaciones
Table 5 Perfil de usuario con un proveedor de espacio de archivo
Esta proliferación de contratos es a la que estamos acostumbrados hoy, con la
única diferencia que, en muchos casos, los NVUP son más simples, entre otras cosas
porque de momento no se manejan QoS diferenciadas en el servicio de transporte de
datos. Esta diversidad y descoordinación de los contratos, cuando en cambio para
prestar un servicio se necesitan de varios de ellos (al menos el contrato de transmisión
de datos y el del servicio de valor añadido) da lugar (o dará lugar) a situaciones como
las del siguiente ejemplo:
En la Table 4 el servicio de noticias tiene descuento de 22:00 a 10:00 pero el de
transmisión de datos de la Table 3 de 20:00 a 8:00. El usuario se preguntará a qué hora
es más barato ver las noticias del día, ya que para disfrutar de ese servicio necesita
también del de transmisión de datos. Siguiendo con esta dinámica nos podemos plantear
qué QoS a nivel de recepción elegir para el servicio de noticias: ¿Reserva RSVP o AF1?
O ¿Qué pasa si el servicio de noticias de alta calidad que tiene contratado el usuario
necesita una reserva RSVP de 256 kbps, extremo que no tiene el usuario en su NVUP?
Es fundamental no “propagar” al usuario esa complejidad, veremos cómo en esta tesis.
3.2.2.3 Perfiles de usuario: el SVUP. Coherencia lograda
Los modelos de negocio antes presentados en la sección 3.2.1, no sólo buscan
características como el “single sign-on” o el son el “unified non duplicated billing” sino
ofrecer todos los servicios bajo un mismo “paraguas” que les dé coherencia y eviten
situaciones como la descrita. De momento, logramos cierta “sencillez” y evitar casos
como los anteriores porque los servicios de transporte de datos son simples (todos la
misma QoS, tarifa plana, etc.). Pero es de prever que en un futuro esto no será así;
primero porqué aparecerán calidades diferenciadas en el servicio de transporte, segundo
porque las operadoras se negarán a reducir su negocio a “tarifas planas”. Es también
predecible una evolución similar en los servicios de valor añadido que serán cada vez
más completos y diferenciados. Con esto vislumbramos la importancia que cobrará en
un futuro gestionar los servicios y los perfiles de usuario de forma coordinada. Este es
uno de los aspectos en los que se centra esta tesis y veremos nuestras propuestas. Es
más, aunque los servicios crezcan en diversidad, riqueza y posibilidades de
- 77 -
A. Cuevas
Tesis Doctoral
personalización y tarificación, los usuarios querrán modelos sencillos e integrados, lo
que refuerza la importancia de lograr los objetivos de esta tesis.
En la sección 3.2.1 vimos algunos modelos para “cohesionar” los servicios,
siendo el más prometedor el que deja este papel al operador de red. Uno de los aspectos
clave para lograr esa “cohesión” es crear un perfil de usuario que describa de forma
coherente los parámetros de los servicios contratados por el usuario. A este perfil lo
llamamos SVUP, Service View of User Profile, y contendrá la lista de los servicios que,
aunque no los preste el operador, los prestaran identidades relacionadas con él bajo el
modelo de negocio de “semi walled garden”. Los términos del SVUP los determinarán
los contratos que el usuario tenga con los proveedores de servicio, pero el proveedor de
red y el contrato del proveedor de red con el usuario pueden influir en esos términos. El
SVUP también tendrá información para establecer la correspondencia entre la calidad
de los servicios y la calidad a nivel de servicio de transporte (especificada en el NVUP).
El SVUP puede, de hecho, englobar al NVUP. La idea es que el contrato, reflejado en el
SVUP, que un usuario tiene para un determinado servicio –del que de alguna forma la
red es consciente- determine la calidad del transporte de datos que ofrece la red al
usuario para ese servicio. Esa calidad en el transporte toma un sentido amplio,
incluyendo aspectos como un servicio de adaptación de contenidos interno a la red si,
por las características de los enlaces, así se requiriera. Notemos que el NVUP no
desaparece del perfil del usuario pues se usará para los servicios de transporte de datos
que la red no pueda relacionar a ningún servicio del SVUP, por ejemplo si el usuario
opera con algún proveedor de servicio usando el modelo “Internet”.
3.2.2.4 Almacén de los perfiles de usuario
El SVUP es tan sólo una agregación a nivel “lógico”, es decir el SVUP no tiene
porque estar almacenado en su totalidad en ninguna entidad. Eso sí, para lograr “single
sign-on” y “unified non duplicated billing” la entidad que mantenga la relación con el
usuario (en los modelos de la sección 3.2.1, normalmente el proveedor de red) debe
poseer, obligatoriamente, dos datos del SVUP: datos de cobro y la contraseña del
usuario, para poder autenticarle. Debemos puntualizar que si la autenticación
(identificación del usuario) no se hace mediante el método de secreto compartido
(contraseña) sino mediante firma electrónica y una autoridad de certificación,
evidentemente el dato de la contraseña es superfluo.
Las entidades que pueden almacenar la información del usuario pueden ser:
•
El usuario almacena (cifrada) toda o parte de su información (por ejemplo en un
“pen-drive usb” o en una tarjeta RFID). Esto se puede asimilar a una especie de
DNI electrónico del usuario. El usuario puede organizar esta información
dividiéndola entre las distintas identidades virtuales (ver más arriba). El usuario
decidirá qué proveedores de servicios accederán a los datos de una identidad u
otra. Ciertos de estos datos pueden ser dinámicos como la localización del
usuario que el mismo puede obtener, por ejemplo usando un sistema GPS, o
preguntando al operador celular sobre su posición. Una autoridad de
certificación (que puede ser gubernamental) se encarga de refrendar que los
datos almacenados son auténticos. Esta solución tiene como ventaja que el
usuario es consciente en todo momento qué información suministra sobre si
mismo a las distintas entidades. Un problema que presenta esta solución es el
caso en el que el usuario quiera estar dado de alta en dos o más equipos a la vez.
- 78 -
El operador de red puede pedir a ambos equipos la autenticación del usuario,
pero sólo el que tenga conectado el “pendrive” del usuario (si es ahí donde el
usuario almacena sus datos) podrá suministrar esa autenticación. Para solventar
esta situación, se puede crear un copia local y temporal de la información del
(cifrada) del usuario en cada equipo.
•
La información del usuario puede estar repartida en varias entidades, sean estas
las que mantienen la relación con el usuario (típicamente el proveedor de red en
el modelo “semi walled garden” de la sección 3.2) o las que le ofrecen un
servicio en concreto. En este caso lo único dato que necesita almacenar el
usuario es algo que le autentique, por ejemplo su contraseña.
Veremos en futuras secciones cómo se puede repartir e intercambiar esa
información.
3.3 Interacción con el proveedor de red. Cohesión de las
sesiones
En las dos anteriores secciones de este capítulo hemos visto como el concepto de
sesión está distribuido y es diferente entre las varias entidades que toman parte en la
sesión. Además, analizamos cómo los modelos de negocio propuestos para las redes 4G,
en los cuales las distintas entidades colaboran entre sí, pueden aportar grandes
beneficios. Para poder realizar dichos modelos de negocio, la información de la sesión
debe cohesionarse. Además se debe coordinar los perfiles y los contratos de los usuarios
con las distintas entidades participantes en la sesión. En esta sección veremos
Propondremos en esta sección cómo se intercambia, entre las distintas entidades, la
información que describe las sesiones para lograr una visión coherente de la sesión y del
servicio prestado al usuario. Nos centraremos en la representación de la información a
distintos niveles: red y aplicación; además analizaremos el papel de los distintos
contratos y de los perfiles de usuario.
Como hemos visto en la sección 3.1, la red transporta los datos de todas las
sesiones y subsesiones pero, normalmente, no será consciente de las sesiones, sólo del
transporte de datos. Un aspecto fundamental para cohesionar las diferentes vistas de una
sesión y poder cumplir así con los modelos de negocio expuestos en la sección 3.2 es
lograr conjugar las sesiones de transporte con las sesiones a nivel de aplicación.
Proponemos dos formas para llevar acabo la tarea de establecer la sesión de transporte
con el operador de red. Esto originará varios modelos que analizaremos aquí. Además,
veremos la relación con los modelos de negocio, enfatizando en el modelo “semi walled
garden” que informa al operador de red de todas las sesiones y le convierte en un
agregador de servicios.
La primera aproximación es que los interlocutores realicen la reserva. Es la
aproximación más clásica. Su justificación la encontramos en que los interlocutores
conocen los parámetros de QoS a nivel de aplicación (lo están negociando entre ellos) y,
además, como están conectados a la red del operador, deberían saber como establecer
una sesión de QoS a nivel de transporte con el operador. Como hemos visto en el estado
del arte, diversos son los trabajos que siguen este modelo pero sin integrarlo con otras
consideraciones fundamentales en redes 4G como gestión de perfiles de usuario. En esta
tesis trataremos en detalle este aspecto.
- 79 -
A. Cuevas
Tesis Doctoral
La segunda opción es que los mediadores realicen la mencionada reserva. Estas
entidades conocen también los parámetros de QoS a nivel de aplicación y, al tener una
relación con el proveedor de red, saben también cómo establecer reservas de QoS en su
red. Esta propuesta es menos seguida en la literatura. [PAP02] compara este modelo
frente a la anterior aproximación. Los principales aspectos expuestos son:
1) el modelo en el que los mediadores realizan la reserva, permite ahorrar a los
interlocutores cualquier aspecto de QoS a nivel de transporte de datos en su
negociación.
2) Ese mismo modelo obliga que los interlocutores interactúen con el mediador y hay
muchas aplicaciones que están diseñadas para involucrar sólo a los extremos
(interlocutores), por ejemplo FTP.
De todas formas, al igual que en el anterior caso, una de las principales carencias
es la integración con otros aspectos fundamentales en redes 4G como gestión de perfiles
de usuario o formas de agregar las sesiones. Al igual que antes, una de nuestras
aportaciones será cubrir esos aspectos.
Antes de proseguir hay que mencionar que, como hemos visto en el estado del
arte, IMS sigue una mezcla entre ambas. IMS, que consideramos como un mediador,
por una parte instruye a la red UMTS o GPRS sobre la QoS de la sesión, pero la reserva
la hará el móvil activando el contexto PDP.
Por otra parte, como mencionamos en el estado del arte, esta necesidad de
activar el contexto PDP, característica específica de las redes 3G, hace que la solución
IMS deba ser extendida para soportarse en redes 4G. Además debemos tener en cuenta
que hay muchas aplicaciones que no usan ningún mediador, por lo tanto no son
soportadas por IMS. Como hemos ya comentado, en esta tesis plantearemos cómo
salvar esos inconvenientes. En definitiva las dos anteriores propuestas ya han sido
presentadas y estudiadas por otros autores. El valor que añade esta tesis es su
integración en redes 4G. En esta sección nos centraremos en aspectos de perfiles de
usuario y niveles de negociación (aplicación y transporte de bits).
Como veremos, lo importante para lograr cohesionar las sesiones tanto a nivel de
transporte como a nivel de aplicación y cumplir así con los modelos de negocio de la
sección 3.2 no es quién realice la reserva del servicio de transporte, sino si se cohesiona
esa sesión de transporte de red con las de nivel de aplicación.
El estudio de nuestras propuestas se verá marcado por un hecho y es que
tenemos dos posibilidades: la primera que uno de los interlocutores sea un proveedor de
servicio con acuerdo con la red, la segunda, que no se de esto, por ejemplo que sea otro
interlocutor “normal” o un proveedor de servicio pero sin acuerdo con el proveedor de
red.
Consideremos un escenario en el que el primer interlocutor, usuario 1, tiene un
contrato de transmisión y recepción de datos con un proveedor de red, llamémosle red 1.
El otro interlocutor, usuario 2, tiene, a su vez, un contrato con ese mismo proveedor de
red. Esos contratos se reflejan en los perfiles de usuario bajo la forma de NVUP que
vimos en la sección 3.2
- 80 -
Pasemos ahora a estudiar las distintas opciones. Señalamos que el análisis en
detalle de la primera opción (los interlocutores hacen la reserva de QoS) será también la
base para exponer las otras proposiciones.
3.3.1 Los interlocutores gestionan la petición de servicio de
transporte
3.3.1.1 Perfiles y contratos involucrados
Analicemos primero los contratos que entran en juego en esta modalidad. El
contrato del usuario con la red 1 especifica, en una parte del perfil del usuario que
llamamos NVUP (ver sección 3.2), parámetros tanto para recepción como para envío de
datos. El contrato del usuario 2 tiene otro NVUP distinto. Ninguno de los usuarios se
encuentra fuera de su red.
Supongamos que el interlocutor 1 envía datos al interlocutor 2 (el caso contrario
es simétrico a este). Al establecer la sesión, los contratos que intervienen y, en
concreto, las partes de los perfiles de usuario involucradas son los escritos en la Table 6:
Red 1
Interlocutor 1
Envío (NVUP, envío)
Interlocutor 2
Recepción (NVUP, recepción)
Table 6 contratos involucrados cuando los interlocutores hacen la reserva de red
En general los términos del contrato que el usuario 1 tiene con su red 1 para
enviar datos a través de ella (parte de envío del NVUP), serán distintos de los que tiene
el usuario 2 para recibir datos a través de esa misma red 1. Por lo tanto, para que la
comunicación se pueda realizar, se ha de tomar una decisión sobre qué perfil seguir para
establecer los parámetros de la comunicación. Veamos las distintas opciones:
•
Se usa el perfil del usuario que envía (en este caso el 1) para establecer los
parámetros de la comunicación, tanto en el envío por parte del usuario 1 como
en la recepción en el usuario 2.
Para establecer los parámetros de envío de datos del usuario 1, se usará,
evidentemente, el NVUP (parte de envío) del usuario 1. Pero, para los datos que
recibe el usuario 2 caben dos posibilidades:
o usar la parte de recepción del NVUP del usuario 1
o usar la parte de envío del NVUP del usuario 1
Si lo que queremos es evitar que la comunicación no pueda realizarse por
falta de correspondencia en los perfiles y, como el NVUP de envío y recepción
del usuario 1 pueden ser distintos, debemos elegir para la recepción de datos del
usuario 2, la 2ª de las opciones antes listadas.
•
Caso contrario al anterior: se usa el perfil del usuario que recibe (aquí el 2)
•
Se usa el perfil del usuario llamante (quién inició la comunicación). Si
suponemos que este es el usuario 1, en la red 1 se usará su parte de envío y
recepción del NVUP para enviar y recibir, respectivamente. Pero, para los datos
- 81 -
A. Cuevas
Tesis Doctoral
que recibe el usuario 2, nos vemos enfrentados a distintas opciones: se podría
usar el NVUP (parte de recepción del usuario 1), pero también cabría la
posibilidad de usar la parte de envío. Como hemos explicado antes, para
asegurar la comunicación habría que elegir esta segunda opción. Para los datos
que envía el usuario 2, tenemos el caso simétrico.
•
Se usa el perfil del usuario llamado
•
Se usa el perfil del usuario que paga. Esto, evidentemente, implica que se
negocie este extremo, ya sea a nivel del servicio en su conjunto o sólo en el
aspecto del servicio de transporte de la red.
Otra opción es usar los parámetros del perfil del usuario 1 y del perfil del usuario
2 y negociar el subconjunto soportado por ambos. En realidad, esto es la solución actual
pero en vez de tratar únicamente las capacidades de la red, considerando estas en
conjunto con los perfiles de usuario. Notemos que si el número de interlocutores
aumenta, el subconjunto con parámetros que estén presentes en todos los perfiles puede
disminuir o incluso estar vacío e impedir que alguno de los interlocutores pueda
participar en la sesión. Nótese que este problema tal vez no pueda siquiera resolverse
que técnicas de adaptación de contenidos, pues estas deberían tener en cuenta también
aspectos de los NVUPs de los usuarios.
Ciertas simplificaciones pueden reducir el número de posibilidades planteadas,
por ejemplo se puede considerar que:
•
Las restricciones en los perfiles de usuario pueden ser iguales entre los distintos
usuarios (eso sí los precios pueden ser diferentes)
•
Los NVUP sólo establecen restricciones en el envío de datos, no en la recepción.
•
Para un mismo usuario, iguales restricciones en el envío y recepción de datos.
3.3.1.2 Negociación, niveles de transporte y aplicación
Durante el establecimiento de sesión, los usuarios negociarán entre si a nivel de
aplicación y a nivel de transporte. Con la red, la negociación será únicamente a nivel de
transporte. La Table 7 recoge este caso. Asumimos que, sin la intermediación de otras
partes (mediadores, proveedores de servicio), los usuarios sólo podrán negociar con la
red un servicio de transporte de datos sin vincularlo a ninguna aplicación. En este
modelo los únicos que tienen una vista global de la sesión y de todas sus subsesiones
son los interlocutores. El operador de red, en cambio, sólo es consciente de una sesión
de transmisión de datos, es decir no controla el servicio de valor añadido pese a estar
transmitiendo sus datos y haciendo posible que éste se desarrolle. Es más, según el
método de transmisión de datos empleado (por ejemplo “Best Effort” sin ningún control
de acceso), tal vez los usuarios no necesiten ni siquiera negociar con la red.
Red 1
Interlocutor 1
Interlocutor 1
Transporte
Interlocutor 2
Transporte
Transporte
Aplicación
Table 7 Niveles de la negociación, cuando los interlocutores hacen la reserva de red
- 82 -
Si el único costo de esta sesión es por el envío y recepción de datos (los
interlocutores no se están prestando ningún servicio lucrativo –ese caso lo veremos
luego-), la negociación de reparto de costos se puede representar como en la Table 8.
Recalcamos que, aunque la negociación expuesta en esa tabla es complicada, al usuario
se le ofrecerá un interfaz sencillo. De hecho lo mismo sucede actualmente: las
aplicaciones realizan complejas negociaciones durante el establecimiento de sesión pero
el interfaz que presentan al usuario es sencillo. Veamos el significado de esta tabla. En
la sección 3.1.1 propusimos incluir un nuevo parámetro en la negociación que ocurre
al establecer la sesión: el precio o reparto de gastos de la misma. En la tabla, los hemos
expresado mediante un porcentaje. En este caso los recursos que acarrean un costo son
el envío y recepción de datos. En la negociación de la sesión, se intercambian qué
posibilidades tiene cada usuario para enviar y recibir; en la tabla, simplificadas a los
distintos anchos de banda. Estas posibilidades vendrán dadas por su contrato con el
operador de red (reflejado en el NVUP) y por las capacidades del enlace al que el
usuario esté conectado. El lector deducirá que la mencionada Table 8, se refiere al caso
de los antes comentados en donde para establecer la sesión se negocia considerando los
perfiles de cada uno de los usuarios, no de ninguno en particular como podría ser el del
llamante. Las soluciones actuales consiguen que la negociación producida durante el
establecimiento extraiga el subconjunto de posibles modos de envío y recepción
soportados por ambos usuarios. Con nuestra propuesta este subconjunto será más
reducido porque tendrá en cuenta también que coincidan los repartos de costos. En el
caso presentado en la Table 8 ese subconjunto son las líneas resaltadas. Las
posibilidades que se tienen son pues:
•
Para el envío de datos entre el llamante y el llamado (primera fila resaltada en la
tabla), se podrá emplear 64 kbps o 144 kbps. Si se emplean 64 kbps, el llamante
asume todos los costos. Si se emplean 144 kbs, entonces el llamante sólo paga el
70% y el llamado 30 %. 8, 12 y 512 kbps no se pueden emplear porque no lo
permite el llamado (8 y 12) o el llamante (512), bien sea porque no está en su
perfil o por limitaciones de su terminal (falta de codecs para esas velocidades) o
de la red de acceso.
•
Para el envío de datos entre el llamado y el llamante (última fila), se podrá
emplear 12 kbps o 64 kbps. En este caso el llamante asume todos los costos,
para ambas posibilidades. 8 kbps y 512 kbps no se pueden emplear porque no lo
permite el llamante (para los 8 kbps) y el llamado (para los 512 kbps). Las
razones serán las mismas que en el anterior caso. Se podrían usar los 144 kbps
pero por falta de acuerdo en el reparto de costos esto queda descartado.
Llamante (Interlocutor 1)
Recurso
(con Reparto
coste)
costes
NVUP llamante 8 kbps
100%
(Envío)
12 kbps
100%
64 kbps
100%
144 kbps
70%
NVUP llamante
(Recepción)
12 kbps
64 kbps
144 kbps
100%
100%
70%
Llamado (Interlocutor 2)
de Recurso (con Reparto
coste)
costes
64 kbps
144 kbps
512 kbps
8 kbps
12 kbps
64 kbps
144 kbps
512 kbps
- 83 -
0%
30%
30%
0%
0%
0%
0%
0%
de
NVUP
llamado
(Recepción)
NVUP
llamado
(Envío)
A. Cuevas
Tesis Doctoral
Table 8 Reparto de costos de la sesión cuando los interlocutores hacen la reserva de QoS
Suponiendo que las limitaciones en la capacidad de ancho de banda se debiesen
únicamente a los parámetros de los NVUP (y no a las características de la red), entonces
podemos extrapolar directamente esta tabla para los casos anteriores. Por ejemplo si
negociación con las distintas redes se basa en el NVUP del usuario que envía
tendríamos lo que aparece en la Table 9. Debemos notar que los usuarios deben
informarse sobre sus NVUPs (por ejemplo el llamante indicar su NVUP de envío al
llamado). Además, se debe mantener la negociación de capacidades de la red (ya que
estas pueden depender de más parámetros además del NVUP) y del terminal. Lo mismo
ocurre con el reparto de costos. Por ejemplo, en la Table 9 si miramos la última fila que
representa, como en el anterior caso, el envío de datos desde el llamante al llamado, el
NVUP que se manejará para establecer los parámetros de recepción del llamante será el
de envío del llamado. Pero aún así, el llamante sólo aceptará pagar el 70% de los costos
para tasas de 144 y 512 kbps.
Llamante (Interlocutor 1)
NVUP llamante 8 kbps
100%
(Envío)
12 kbps
100%
64 kbps
100%
144 kbps
70%
NVUP llamado 8 kbps
0%
(Envío)
12 kbps
100%
64 kbps
100%
144 kbps
70%
512 kbps
70%
Llamado (Interlocutor 2)
8 kbps
12 kbps
64 kbps
0%
144 kbps
30%
8 kbps
0%
12 kbps
0%
64 kbps
0%
144 kbps
0%
512 kbps
0%
NVUP llamante
(envío)
NVUP llamado
(Envío)
Table 9 Reparto de costos de la sesión cuando los interlocutores hacen la reserva de QoS. 2
3.3.2 Usuarios y proveedores de servicio
En este caso uno de los interlocutores (pongamos el segundo) es un proveedor de
servicios que tiene un acuerdo con la red del otro interlocutor (la red 1). De no existir
este acuerdo estamos ante una situación análoga al caso anterior. Debemos resaltar un
detalle: el proveedor de servicios puede tener un acuerdo con otra red. En este caso, si
las dos redes están federadas y la validez de ese acuerdo se puede extender entre las
redes, la exposición que sigue se aplica, sino, de nuevo, estamos ante una situación
análoga al anterior caso.
Como hemos visto en la sección 3.2 en este escenario el contrato que tenga el
proveedor de servicio con el proveedor de red, determinará la QoS que el proveedor de
red ofrezca, a nivel de transporte, a los usuarios del proveedor de servicio. Teniendo eso
en cuenta podemos elaborar la Table 10 con un ejemplo de los contratos que influirán
en la negociación para establecer la sesión.
Interlocutor 1
Interlocutor 2 (proveedor de servicios)
Ninguno (para la Transmisión de Qué QoS a nivel de transporte ofrece la
datos de esta sesión)
red 1 al usuario 1 (y a cada uno de los
usuarios del proveedor de servicios)
Interlocutor
2 SVUP (ejemplo Alta calidad
(proveedor de servicios) para streaming)
Red 1
Table 10 contratos involucrados cuando un interlocutor es proveedor de servicios
- 84 -
En cuanto al establecimiento de la sesión, lo primero que debemos decir es que
en este caso, al haber un contrato entre los interlocutores, estos ya sabrán de antemano
las características que puede tener la sesión. Por lo tanto, la negociación entre ambos
puede reducirse a que el usuario informe al proveedor de servicio de las capacidades de
su terminal y de la red a la que está conectado; en particular no se necesitará negociar el
reparto de costos. En la negociación de la sesión de QoS con el proveedor de red puede
intervenir el usuario o sólo el proveedor de servicio; este segundo caso es el recogido en
la Table 11. El proveedor de servicios necesita negociar con la red la QoS que ésta
ofrecerá al usuario en el transporte de los datos de la sesión. El proveedor de servicio
necesita pues transferir al proveedor de red los parámetros que le permitan identificar
los flujos de datos correspondientes a dicha sesión. Como hemos visto en la sección 3.2,
en este escenario se pueden dar dos modelos de negocio: en el primero el usuario paga a
la red por el servicio de valor añadido y esta paga parte al proveedor de servicios. El
segundo modelo es justo el simétrico.
En el primer caso –reflejado en la Table 11-, el proveedor de servicios debe
indicar a la red los parámetros del servicio (costo, descripción del servicio etc.). Es
decir, se hace “consciente” a la red de la aplicación cuyos datos está transportando. El
proveedor de red agregará las sesiones (transporte y aplicación) y, usando los datos
suministrados por el proveedor de servicios, producirá la factura para el usuario.
Además, aunque el usuario no negocie con el proveedor de red ningún servicio para
esta sesión, debe suministrarle sus datos de autenticación para que éste, bajo el modelo
de “single sign-on” asegure al proveedor de servicio la autenticidad del usuario.
En el segundo de los casos antes mencionados, es la red la que debe informar de
lo que va a cobrar al proveedor de servicios, por ejemplo por uso de ancho de banda.
Interlocutor 1
Nada (sólo autenticación)
Red 1
Interlocutor 1
Interlocutor 2 (proveedor de servicio)
Transporte. Además, informa de los detalles de la
sesión.
Aplicación
Table 11 Niveles de la negociación, cuando un interlocutor es proveedor de servicios
3.3.3 Uso de mediadores
En este caso los usuarios tienen un contrato con el mediador y éste con el
proveedor de red.
Como hemos visto en la sección 3.2, en este escenario el contrato que tenga el
mediador con el proveedor de red, determinará la QoS que el proveedor de red ofrezca,
a nivel de transporte, a los usuarios que empleen los servicios del mediador. Teniendo
eso en cuenta podemos elaborar la Table 12 con un ejemplo de los perfiles de usuario
que influirán en la negociación para establecer la sesión.
Red 1
Mediador
Interlocutor 1
Interlocutor 2
Mediador
Ninguno (para la transmisión Ninguno (para la transmisión Qué QoS a nivel de
de datos de esta sesión)
de datos de esta sesión)
transporte ofrece la red 1 al
usuario 1 (y a cada uno de
los usuarios del mediador)
SVUP
(ejemplo:
para SVUP (ejemplo: en las
llamadas con el jefe emplear llamadas emplear siempre la
la más alta calidad tanto si se máxima calidad y, para ello,
- 85 -
A. Cuevas
Tesis Doctoral
es llamado como llamante. aceptar como mucho pagar un
Para el resto, buscar los 30% de los costos al ser
menores costos y no aceptar llamado)
pagar al ser llamado)
Table 12 contratos involucrados cuando un mediador asiste a los interlocutores
En cuanto al establecimiento de la sesión, esta será una especie de combinación
entre los dos casos anteriormente expuestos. Al igual que en la sección 3.3.1, la
negociación, a nivel de aplicación entre los dos usuarios es imprescindible. En cambio,
en este escenario, no es necesario que estos negocien a nivel de transporte ya que el
mediador puede negociar el establecimiento de la sesión de transporte de datos con la el
proveedor de red. Este es el caso reflejado en la Table 13; otra posibilidad es que los
interlocutores, establezcan ellos la sesión de transporte con la red. En cuanto a la
negociación entre el mediador y la red, la discusión es idéntica al anterior caso (sección
3.3.2). Al igual que entonces reflejamos en la tabla el escenario en el que quién agrega
las sesiones y mantiene la relación con los usuarios es el operador de red.
Interlocutor 1
Interlocutor 1
Interlocutor 2
Nada
(sólo Nada
(sólo
autenticación)
autenticación)
Aplicación
Interlocutor 2
Aplicación
Red 1
Mediador
Transporte. Además informa de los
detalles de la sesión.
No hay negociación pero puede intervenir
en ella
No hay negociación pero puede intervenir
en ella
Table 13 Niveles de la negociación cuando un mediador asiste a los interlocutores
En este caso si debemos negociar los costos entre los usuarios pero, a diferencia
del caso de la sección 3.3.1, aquí los recursos se tarifican a nivel de aplicación y no a
nivel de transporte de datos. Por lo tanto obtendremos un modelo mucho más sencillo,
reflejado en la Table 14.
Llamante
Llamado
Servicio (de llamada) y Servicio (de llamada)
reparto de costes
y reparto de costes
SVUP (para servicio de Low QoS 100%
Low QoS 0%
SVUP (para servicio
llamadas cuando se es Medium QoS 70%
Medium QoS 0%
de llamadas cuando se
llamante)
High QoS 50 %
High QoS 30 %
es llamado)
Table 14 Reparto de costos de la sesión cuando un mediador asiste a los interlocutores
Hemos mencionado muy brevemente que, en realidad, incluso cuando usamos
un mediador, los interlocutores pueden encargarse de establecer la sesión de transporte
con el proveedor de red (este es, por cierto, el modelo seguido por IMS). Esto puede
llevar al lector a engaño y pensar que estamos ante un caso análogo al de la sección
3.3.1. Esto no es así. Hay dos diferencias fundamentales:
•
El contrato que se aplica para establecer la sesión de transporte es el de los
usuarios con el mediador (SVUP) y el de este con la red, no el de los usuarios
con la red (NVUP).
•
Hay una entidad, ya sea el mediador, ya sea la red (extremo detallado aquí) que
puede agregar las sesiones a nivel de aplicación y de transporte y presentar una
- 86 -
factura consolidada al usuario. Es decir, se hace partícipe a la red de la
aplicación cuyos datos está transportando.
3.3.4 Relación con los modelos de negocio
Lo esencial en los modos de hacer la reserva de QoS con la red antes
presentados, es analizar cómo casan con los modelos de negocio presentados en la
sección 3.2. Además debemos ver cómo soportan aspectos como el “single sign-on” o el
“unified non-duplicated billing”.
En los casos de las secciones 3.3.2 y 3.3.3 los usuarios serán tarificados por un
servicio de valor añadido, no por el servicio de transporte. Además, la autorización para
consumir ese servicio –basada en el SVUP- incluye la necesaria para poder usar el
transporte de datos con la QoS adecuada. Para lograr estos aspectos, como vimos en
esas secciones, el mediador o el proveedor de servicio no sólo tienen que contactar con
el proveedor de red para solicitarle QoS. El intercambio de información de incluir,
también, datos de la aplicación, tarifas, etc. Este intercambio logra una visión coherente
de las subsesiones (a nivel de aplicación y de transporte) que se usan para la prestación
de un servicio. Estamos ante el modelo de “walled garden” si los servicios y
subservicios considerados sólo los ofrece el operador de red, o con el caso de “semi
walled garden” si consideramos que esos servicios los ofrece otra entidad, con relación
con el proveedor de red. En este último supuesto, como hemos dicho, no importa quien
mantiene la relación con el usuario y quién agrega las subsesiones, si el operador de red
o el proveedor de servicio. Pero nuestra ilustración se ha centrado en el primer caso que
es, sin duda, el que se adoptará en la inmensa mayoría de los escenarios de
telecomunicaciones futuros. El poder considerar el servicio como un “todo” incluyendo
el servicio de valor añadido y el de transporte de datos, influirá en la forma de negociar
los parámetros de la sesión entre los usuarios, incluido el reparto de costos. Como se
puede comprobar comparando con el caso presentado en 3.3.1, la negociación se hace
mucho más sencilla.
En toda esta discusión, no se ha hecho hincapié en si el mediador o el proveedor
de servicios realizaban la reserva de QoS, sólo hemos resaltado que interactuaban con el
proveedor de red para informarle de los datos de la aplicación. En realidad, el terminal
puede encargarse de establecer la sesión de QoS. Es más el terminal, también puede
cooperar para informar al operador sobre la correspondencia entre las aplicaciones y los
datos que transporta la red.
El escenario de la sección 3.3.1 supone, en cambio, un modelo de Internet,
donde el servicio de transporte de datos y los de valor añadido están completamente
desligados y los usuarios deben de encargarse de gestionar ambos. Los usuarios podrían
incluso usar un mediador pero, si este no tiene ningún acuerdo con el proveedor de red,
el resultado es el mismo. A parte de los usuarios, ninguna otra entidad es “consciente”
de la totalidad de las sesiones a nivel de aplicación y a nivel de transporte, por lo tanto
los aspectos de “single sign-on” y “unified non duplicated billing” no se soportan. En
este escenario, el operador de red pierde toda participación en el desarrollo de los
servicios, sólo transporta sus datos y lo hará en base a los parámetros del NVUP.
Como veremos más adelante, para aspectos de tarificación basados en aplicación
y no en transporte de datos, la intervención de entidades con relación con el operador de
red es necesaria. Asumiremos en esta tesis que, si los usuarios no interactúan con estas
- 87 -
A. Cuevas
Tesis Doctoral
entidades estos, por si solos, no podrán hacer participes al proveedor de red de las
aplicaciones que están usando.
Los tres modelos presentados son complementarios y destinados a cubrir las
necesidades de distintos escenarios:
•
El modelo en el que interviene un mediador es similar al IMS y está destinado,
fundamentalmente, a comunicaciones entre interlocutores (“peer-to-peer”) pero
que pueden emplear un “mediador” para negociar su establecimiento. Hacemos
notar que uno de los interlocutores puede ser un proveedor de servicio. Incluso,
al igual que en IMS, un proveedor de servicio puede interactuar con el
“mediador” (pero sin ser parte de la comunicación) y ofrecer características
avanzadas en el establecimiento de sesión, como desvío condicional de
llamadas.
•
El modelo en el que no se involucra a ningún mediador pero sí a un proveedor
de servicio podría corresponder al modelo OSA definido, al igual que IMS, por
el 3GPP. Este modelo es útil cuando las aplicaciones que ofrece el proveedor de
servicio no están diseñadas para emplear ningún mediador durante la
negociación. Aplicaciones que, por lo tanto, no están soportadas por IMS.
•
Por último, el modelo “Internet” presentado en la sección 3.3.1 es, precisamente,
para soportar comunicaciones con entidades y proveedores de servicio sin
ninguna relación con el proveedor de red. Nuestra propuesta, a diferencia de las
soluciones existentes, permite a los extremos negociar la QoS y el reparto de
costes del servicio de transporte de datos.
Esta tesis integrará estos tres modelos dentro de una única arquitectura 4G.
3.3.5 Consideraciones sobre “roaming”
En las anteriores discusiones hemos considerado un caso muy sencillo: los
usuarios pertenecen a una misma red y se encuentran en ella. Pero esto, obviamente, no
siempre es así. Veremos en esta sección las complicaciones que acarrea soportar estos
nuevos escenarios.
En el modelo Internet, en el que la red es sólo un transportista de bits, no
tendremos dificultades añadidas, basta que las redes tengan contratos de provisión de
QoS en el transporte de datos entre sí y, si es necesario, que se puedan comunicar los
NVUPs de los usuarios.
En el caso en el que un usuario, fuera de su red, desea interactuar con un
proveedor de servicio que tiene un contrato con su operador de red, se nos presentan
varias posibilidades. Si consideramos el servicio de transporte con QoS prestado por la
red visitada podemos tener:
•
el usuario se encarga de realizar dicha petición a la red en la que se encuentra
(red visitada). La red visitada puede contactar con la red hogar y esta con el
proveedor de servicios para comprobar si el usuario está autorizado a disfrutar
de tal servicio de transporte.
- 88 -
•
Otra solución sería que el proveedor de servicio se encargara de realizar la
petición de QoS. Para ello debe interactuar con el proveedor de la red hogar y
éste con el proveedor de la red visitada.
Si consideramos el caso de sesiones establecidas gracias a la intervención de los
mediadores, el escenario puede cambiar. Como hemos dicho en la sección 3.2, estas
entidades pueden formar parte de la infraestructura del operador de red. Además, no
ofrecen directamente ningún servicio específico (sólo hacen de mediadores), por lo
tanto la funcionalidad de todas será muy similar. Entonces, siguiendo el modelo IMS,
un usuario en la red visitada pueda contactar directamente con el mediador de esa red (y
no con el de su red hogar). El escenario se torna entonces al caso presentado en 3.3.3,
pero los mediadores de la red hogar y la red visitada deben interactuar. Podemos hacer
la misma consideración si la sesión se establece entre dos usuarios de dos redes
distintas, para permitirlo lo que debemos hacer es lograr que los mediadores interactúen
entre sí.
3.4 Conclusiones
En este capítulo hemos analizado la problemática que, en el modelo actual de
servicios “Internet”, plantea el que las subsesiones que conforman una misma sesión
estén dispersas entre varias entidades. Este problemática se pone de especial manifiesto
cuando queremos materializar los nuevos modelos de negocio que imperarán en el
futuro en el mercado de las telecomunicaciones. Un correcto diseño de los mecanismos
de establecimiento de sesión es fundamental para lograr cohesionar las distintas
subsesiones y poder así lograr los mencionados modelos de negocio.
Este capítulo ha propuesto el intercambio de información necesario durante el
establecimiento de sesión. Nos hemos centrado en aspectos como niveles de
negociación –aplicación o transporte-, perfiles de usuario, contratos y relación de las
entidades con los usuarios ya que estos son la piedra angular de los modelos de negocio
planteados. Aspectos como coordinar los perfiles de usuario a nivel de red y aplicación
para lograr un mejor servicio final, han sido abordados. Además, hemos planteado un
aspecto que deberán tener los lenguajes de descripción de sesiones futuros, el reparto de
costos y hemos sugerido soluciones para negociarlo.
Este intercambio de información propuesto será vital para entender el diseño de
la señalización que describiremos en el capítulo 5. Antes deberemos ver la arquitectura
4G considerada, la funcionalidad de los distintos sistemas y nodos entre los que se
realizará esa señalización. El siguiente capítulo describirá esa arquitectura planteando y
evaluando las distintas posibilidades de diseño.
- 89 -
4. Proposed 4G Architecture & Session Setup Support
Chapter 3 has analysed and showed that the information describing a session is
split between the different entities that participate in the session. This raises challenges
to achieve the business models presented in that same chapter. Those business models
and some of their features such as single sign-on draw the requirements to build session
setup solutions. This chapter presents the architecture that supports advanced session
setup mechanisms and will propose and evaluate the different possibilities and
scenarios. Since our focus is the, still under research, 4G networks, some aspects of this
architecture must also be designed as we will do in this chapter.
The architecture we are going to describe in this chapter not only focuses on
session setup aspects. The reason was already explained in the thesis’ introduction but
we recall it here. On the one hand the 4G networks are still under research, certainly
many contributions exist but there are still plenty of issues to cover. Therefore, in the
aspects needed to support session setup procedures and not covered by current research
works we will elaborate our own design. On the other hand, the advanced session setup
mechanisms of this thesis involve a great number of systems for which we are going to
define the iterations necessary to support our session setup proposals. Those are the
reasons why we need to design other 4G architecture aspects, in addition to the purely
related to session setup. Indeed the 4G architecture design is one the objectives of this
thesis.
Let us recall, as we already commented in the introduction and the state-of-theart, that the 4G network concept is not yet totally defined. The main characteristic of 4G
is the use of native IP technologies in the core and the access networks, to support all
the services. This is one step beyond the “All-IP” 3G networks. In this strategy, all the
(complex) UMTS access network behaves as ‘1 hop’ at the IP layer, and hides issues
such as mobility and QoS from it. However, adding new access network technologies
involves then great amount of translation procedures from the specific mechanisms of
UMTS to the mechanisms in these other technologies. Since 4G architectures are based
on native IP, they should be able to embrace almost any available wireless (or even
wired) access technology without any translation procedure.
One of the desirable features in 4G networks is that they are based on IPv6,
solving that way problems like the address space. This is vital for the deployment of a
new network where the use of public addresses would facilitate the development of
- 91 -
A. Cuevas
Tesis Doctoral
peer-to-peer applications, for instance telephone conversations. Like the present day
networks, 4G networks will be divided in administrative domains. Each domain will be
made up of routers, servers for managing the network and the elements necessary to
deploy the access network (antennas, etc.). The 4G networks should provide different
mechanisms with equal or better performance than those of the present day mobile
networks. These will be, for instance, mobility, QoS, access control, charging, paging
etc. In addition, the different protocols used (for example to provide mobility or QoS),
must be independent, at least as far as possible, of the L2 technology. The benefits of
such a network are analyzed [CUE05] and it is demonstrated that they can support the
present and future applications. In concrete they can support multimedia applications
that rely on protocols like SIP to negotiate and to setup the sessions. As a conclusion,
we can say that our solutions and their targeted applications can be supported in a 4G
network.
We divide the chapter in three parts. First, we will study the involved systems,
we will see what entities and business actors of the ones defined in chapter 3 they
belong to. We will also address their notion of session and the parts of the users’
profiles they handle. In the second part we will define the architecture of each system,
identifying the different involved nodes, their components and their functionality. The
interfaces will also be presented. Finally, we will define the interactions between those
nodes focussing in the case of session setup. We will analyze our diverse proposals.
4.1 4G Systems involved in session setup
In this section we will describe the systems of a 4G architecture involved in the
session setup. We will see what entities and business actors of the ones defined in
chapter 3 they belong to. We will also detail their notion of session and the parts of the
users’ profiles they handle. Many of those systems are defined already and even
standardized but, in numerous cases, the iterations among them are not designed. Those
iterations are essential to be able to carry out our session setup proposals. In this section
we will expose our solutions to achieve these interactions. We point that we will focus
on interactions related to session setup but not on pure session setup mechanisms.
These are defined in other sections.
4.1.1 Users’ Profiles and session concept in the 4G systems
For each of the systems described in this section we will analyse the entity that
may own the system (service provider, network operator), the session concept handled
by the system and the parts of the user profile the system deals with.
4.1.1.1 QoS enabled data transport
As we have mentioned all along this thesis, 4G networks will be based on IP
(version 6). As it is perfectly well known, IP networks were not designed to provide any
QoS warrantees. But the applications traditionally using IP as their communication
technology could perfectly cope with its lack of warrantees. But telephony or iterative
applications require transport networks with very stringent QoS requirements.
The mechanisms to endow IP networks with QoS, as seen on the state of the art,
vary from 100% warrantee solutions employing techniques that can be assimilated to
- 92 -
Proposed 4G Architecture & Session Setup Support
virtual circuit creations and reservation to other solutions not giving 100% warrantees.
The over provisioning approach is also considered but, of course, it can not be applied
in scarce BW radio access networks. Besides, offering different quality for the data
transport service, will create new opportunities for offering several quality levels at
different prices. We can conclude that in 4G networks the transport of data will not be
enough, data transport will need to be QoS enabled.
The QoS system will basically consist on QoS enabled routers and some control
entities called Bandwidth Brokers (or also QoS Brokers). These elements will be further
detailed in section 4.2.1. Obviously, the QoS enabled transport system will be part and
owned by the network operator.
Depending on the QoS technology used, the notion of QoS enabled transport
session can be very diverse. Besides, between different domains -or, even, within the
same domain- this technology can be different. This aspect will complicate the
aggregation of the transport session with the other sub sessions taking part in the
session. The transport session itself can be divided in several subsessions. Let’s study
this notion of session depending on the different QoS technologies that may be
employed in 4G networks:
DiffServ networks (core): there is no notion of session is this kind of networks
Access control (in DiffServ): In DiffServ networks the control of traffic injected
into the network is fundamental. For instance, to warrantee that EF traffic has enough
resources, the amount of introduced EF and AF traffic must be limited (there is no need
to do so with BE traffic). We must stress the fact that even for BE traffic and that even
if the user has been granted network access, a QoS session must be established. This is
just needed to control the amount of traffic sent and received by the user trough the
network. This is not for a matter of QoS management; it is just for coping with SLAs.
As we have seen in section 3.2, the users may have a limitation even for Best Effort
traffic.
If a signalling protocol is employed by the user, by the Value-Added Service
Provider (VASP) or by the “mediator” (see section 3.3) to setup and tear down network
transport sessions, then it’s this protocol notion of session the one to be considered. An
example could be RSVP but RSVP was designed to operate in IntServ networks. The
signalling of the session setup and tear down may also be in band with the flow to be
given QoS, for instance, indicated by “special” DSCP codes. But, in many cases, there
won’t be any signalling, then it is up to the network operator to decide the “concept of
session”, its parameters and when to start the session and finish it. As an example, one
QoS transport session can be setup by the QoS system when the user starts to send
traffic to a certain destination. The parameters of this session may be the source and
destination addresses of the packets. The session will finish when, during a certain
period of time, there is no more traffic with these characteristics (source and destination
addresses).
The access control we have considered is for users connecting to the DiffServ
network but note that access control should also be done for neighbouring domains. In
this case, the “sessions” would begin when signing the SLA between the domains and
should finish when changing the SLA.
- 93 -
A. Cuevas
Tesis Doctoral
Let’s now consider IntServ Networks. These networks have associated a
protocol, RSVP, to handle the control of the QoS reservation, so the notion of session is
just the one employed in RSVP.
Figure 26 shows the different sessions the QoS system may handle. It also shows
the triggers to start the sessions (horizontal right pointing arrows) and to finish them
(horizontal left pointing arrows). The actions the QoS system takes when a session is
setup or tear down are also displayed in Figure 26: the upwards pointing arrows indicate
the interaction with the AAA system, the downwards pointing arrows the actions with
the Measurement system. All the interfaces presented will be detailed in next sections.
There is a group of sessions bounded by just one request to start and another to
stop the corresponding session in the AAA system. The AAA system will see all those
QoS System sessions as just a single one. Those sessions correspond to Internet like
model sessions where nor the QoS or AAA systems are given details about them. The
network plays the role of just a bit pipe and the transmission is done under the NVUP
parameters. Although, they have not been displayed in the figure, there may be
“Internet” like sessions that require Accounting and, even, authorization from the AAA
System. In such cases, the QoS System will need to interact with the AAA System when
those sessions are setup and tear down.
Request to AAA to
finnish accounting
Request to AAA to
start accounting
MMSP requests to start
QoS tranpsort session
MMSP requests to finnish
QoS transport session
request to CMS to finnish
measurement session
request to CMS to start
measurement session
Request to AAA to start
accounting & authorization
VASP requests
to start QoS
tranpsort
session
Request to AAA to finnish
VASP requests to finnish
QoS transport session
measurement session
measurement session
Request to AAA to start accounting
& authorization
Request to AAA to finnish
NVUP Sent to QoS System
User sends
packets
CMS indicates no more
packets sent
measurement session
measurement session
User sends packets
CMS indicates
no more
packets sent
measurement session
measurement session
User
finnishes
RSVP
User starts RSVP
measurement session
measurement session
CMS indicates no
more packets sent
User sends packets
measurement session
measurement session
Figure 26 sessions handled by the QoS system
- 94 -
The QoS System will decide the parameters of the transport enabled QoS based
on the user NVUP (Internet model), or on the indications dictated either by the
mediator (MMSP) or VASP. Mediators and VASP will base their indications on the
user’s SVUP (see section 3).
Note that the NVUP terms (and SVUP) may not match exactly the data transport
session parameters. For instance, a user may have stated in his NVUP that he can send
up to 128kbps of EF traffic irrespective of the destination, but the QoS System may
create sessions based on packet’s source address (if we assume it represents the user),
the DSCP indicating EF traffic but also on packet’s destination address.
A key point this thesis will handle and propose is how packets are associated to
users, either by the QoS system or by other systems.
4.1.1.2 MMSP
The MMSP (Multimedia Service Provisioning Platform) is the system that
implements the functionality of the mediator entity described in section 3.1.4. This
system can be assimilated to the IMS (to the CSCFs, actually). Like in IMS, its main
components are SIP proxies. It can be part and owned by the network operator or be an
independent entity. However, as we saw is sections 3.1.4 and 3.3.3, its main role is to
assist to setup up session between peers, which includes normal user to user voice calls
or SMSs. These two services are nowadays the core network operators business and
thus the network operators will not only own the MMSP entity, they will trend to
integrate it into their telecommunication network infrastructure (as we pointed in
section 3.2), just like the IMS system is.
The MMSP system directly maps to the mediator entity described in section
3.1.4, thus its concept of session and the role in setting up, tearing down and controlling
the session and subsessions (including the QoS transport subsession) are the same. It
may handle all the sessions and subsessions (e.g. a voice call and its transport session)
where it is assisting the peers. So this system could be a good candidate for centralising
and co-ordinating all the subsessions participating in a service. But we have to note
that there are sessions that don’t use the MMSP as mediator. So the role of session
aggregation is to be taken by other entity: the AAA system (section 4.1.1.3)
Figure 27 shows a session handled by the MMSP. This session maps to the top
most session of Figure 26. It also shows the triggers to start the sessions (horizontal
right pointing arrows) and to finish them (horizontal left pointing arrows). The actions
the MMSP takes when a session is setup or tear down are also displayed in Figure 26:
the upwards pointing arrows indicate the interaction with the AAA system, the
downwards pointing arrows the actions with the QoS system. All these interfaces will
be detailed in next sections.
Request to AAA to
finnish accounting
Request to AAA to
start accounting
user tears down a session
using the MMSP as proxy
user setups a session using
the MMSP as proxy
request to QoS System to
finnish session
request to QoS system
to setup session
Figure 27 sessions handled by the MMSP
- 95 -
A. Cuevas
Tesis Doctoral
The MMSP handles the SVUP, specifically the parts related to all the peer-topeer communications services that employ the MMSP to setup the session. Examples of
these services can be voice calls, multiparty multimedia conferences, instant messages
etc.
4.1.1.3 AAA
In section 3.2 we saw the advantages of aggregating all the subsessions within a
session and how the business models based on single sign-on and unified billing are
promising. The AAA architecture defined by the IRTF and that we presented in section
2.3.1 is well suited for this task. This Architecture was designed to provide a number of
Internet Services with Authentication, Authorization and Accounting Support. This
thesis will present some proposals to enhance the AAA architecture (IRTF AAA
architecture is designed to be extended) in order to fulfil the mentioned aggregation of
sessions requirements (to achieve single sign-on and unified billing) and to perfectly
integrate it with other aspects of 4G networks, among them the session setup. The AAA
System can be federated with other domains AAA systems to allow features such as
roaming.
The AAA System does not create, by itself, any session. It setups, handles and
finishes a session when one of the systems and entities able to interact with it, requests
so. The AAA System can then be seen as the point correlating all the sessions and
subsessions spread out over the different systems. The AAA system keeps track of user
accounting data, registration and authorization. It is thus the key entity to achieve single
sign-on and unified billing. Sections 4.3 and 5 detail these issues.
The AAA system will be located and owned by the entity of the
telecommunication business value chain that centralises user control and billing. As we
have seen in section 3.2, this entity can be either the Network operator (“semi-walled
garden” business model) or the Service provider.
The user profile (age, services contracted, etc.) may be stored either in user
owned storage devices (e.g. USB stick), split over the service providers or centralised in
the AAA system responsible for single-sign-on and unified billing.
As we saw in section 3.2, users will prefer to give sensitive information (like
credit data) only to one entity. By credit data we mean either a bank account or credit
card number from which to withdraw money or, for prepaid scenarios, the remaining
budget of the user. This credit data must be stored in the AAA system doing single sign
on and unified billing. Besides, if the authentication of the user is based on a shared
secret (password), the AAA system must also store this password (see section 4.1.2.1
for more details). So it’s the AAA system the one storing the two key elements of the
user profile (credit and password) for achieving single sign-on and unified billing.
Respect to the other parts of the user profile let’s first consider the NVUP
(Network View of the User Profile) and then the SVUP (Service View of the User
Profile). As we saw in section 4.1.1.1, the QoS system will interpret the NVUP but this
thesis considers that the NVUP should be located in the AAA system and delivered to
the QoS system on request. As section 4.1.2.3 shows, the QoS system is not designed to
store user profiles. Besides, the AAA system needs the NVUP to do network usage
based charging (with the data ccou8nted by the QoS system). Value-added-services- 96 -
related parts of the user profile (such as his date of birth or whether he contracted good
or medium quality news streaming) can be stored either in the AAA system or in the
valued added service provider. The same comments applies to the “pieces” forming the
SVUP which integrates the value added services and the NVUP. In section 4.3 we will
provide an analysis of the different possibilities along with studying which system
should interpret this data.
One special system interacting with the AAA is the Network Access Server
(NAS). The NAS is responsible for granting access to the users willing to connect to the
operator’s network. The NAS must thus have a way to do a mapping between user and
his packets (e.g. between user’s NAI and packets’ source address). We should note that
this functionality overlaps with the QoS system one which grants transport services over
the operator network. This issue is tackled in section 4.1.2.3. NAS offers a basic service
and creates a session over which all the other sessions will be aggregated, the network
access session. This session is setup by explicit signalling done by the user terminal and
finishes either after a timeout or by explicit signalling from the terminal. In our design
this session will be local and not shared between the different users: i.e. each user will
have its individual NAS session, just for his access and won’t share or inform the other
users about it. This session could also be accounted by the NAS (for instance the
number of packets sent) but we will consider this is done by the QoS system.
The NAS is, like the QoS system, part of the network operator. As we will see in
section 4.2.3, the NAS will be spread out in many elements and the network operator
will configure them to interact only with its AAA system. The AAA system will store
user profile data related to NAS for instance, aspects such as which types of networks
the user is allowed to connect to (only CDMA network, also airport hot-spots etc.). Note
that in the service-provider-centric business model or in roaming scenarios the network
operator AAA system plays, for the NAS, the role of a relay with the user’s AAA
system. Taking all this into account (basic access session creation, forced interaction
with the network operator AAA system -and not with any other AAA System-) the NAS
can be considered to form part of the network operator AAA system.
Figure 28 shows the AAA system and its interfaces with other systems,
including the NAS. AAA system interacts with all the entities participating in the
delivery of services and subservices and, as we said before, aggregates all the
corresponding sessions.
- 97 -
A. Cuevas
Tesis Doctoral
PKI only used when authentication is
based on certificates, not in shared
secret (password)
AAA System
Federation
AAA System
Operator specific
AAA Clients
Added value
Service Providers
NAS
QoS
System
MMSP
MMSP
Figure 28 AAA system interactions
Figure 29 shows all the sessions that the AAA system aggregates. The system
interacting with the AAA system handles the sessions and informs the AAA system
about them. Thus the AAA system can do the mentioned aggregation. For instance, the
top most session corresponds to the MMSP & QoS sessions for delivering a specific
service. The next session (with green & blue stripes) corresponds to the QoS transport
session and a service provider session while delivering another specific service. Finally,
the third session (blue) corresponds to a QoS enabled data transport session (but not
associated to any service). It must be noted that within the QoS system, this session
corresponds to many others. The QoS system does not need to inform the AAA system
about those sessions, all of them are authorised and lay under the NVUP umbrella.
However, if detailed accounting is required, perhaps these sessions are made visible to
the AAA system, by the QoS system. It must be noted that all the above sessions are
subsessions of the Network Access session created by the NAS.
- 98 -
MMSP requests to start
authorisation &
accounitng
MMSP requests to finnish
authorization & accounting
QoS requests to start
accounting
QoS requests to finnish
accounting
VASP requests
to finnsih
authorisation &
accounting
VASP requests
to start
authorisation &
accounting
QoS requests to
finnish
authorisation &
accounting
QoS requests to
start
authorisation &
accounting
NAS
Requests to
finnish
authorization
NAS
Requests to
start
authorization
QoS requests
to start
accounting &
authorization
QoS
requests to
finnish
accounting &
authorization
NVUP Sent to
QoS System
Figure 29 sessions handled by the AAA system
In advanced architectures the AAA system also monitors SLA compliance and
anonymizes the user in front of the consumed service. These two features are interesting
research topics but out of the scope of this thesis. However we will present them in a
few words; [HAS04] broads our discussion. SLAs are handled by the AAA System and
the auditing system has to cross-check the service conditions versus what was
committed in the SLA. This shows the need of an interaction between AAA and
auditing system. The anonimization of user is also a very interesting research topic
since it aims to satisfy two contradictory requirements. On one side, users are very kind
of the single-sign-on feature provided by AAA but, on the other side, they do not want
to be tracked on their various activities (services consumption). This is the goal of
anonimization performed by the AAA system.
4.1.1.4 Mobilitiy
Mobility is a key service and thus of great importance in 4G. Mobility can
encompass different aspects:
•
Roaming – Enables the user to use his own terminal and services regardless the
network he is attached to.
- 99 -
A. Cuevas
Tesis Doctoral
•
Terminal Mobility – Enables to change the point of attachment with no
disruption in the (eventually) ongoing session.
•
User Mobility – Enables the user to access his services through different
terminals.
•
Session Mobility – Ensures that sessions are not disrupted whenever a session is
transferred from one terminal to another or even from one user to another.
The Terminal mobility depends in a whole architecture designed for this: Mobile
IP. The Mobile IP model relies on two IP addresses, one that identifies the Mobile Node
(MN) –termed Home Address (HoA)-, and the other that identifies its location in the
network (Care of Address). The HoA is fixed but the Care of Address (CoA) changes
with the terminal point of attachment to the network. Note that if a terminal has multiple
interfaces it will have multiple CoAs. The entity doing the correspondence between the
CoA and the HoA is the home agent (HA). The Correspondent Node (CN) can also do
this mapping. This solution, as we said in the state of the art, is defined in [RFC3775].
Micro mobility is also being discussed and IETF has already arrived to a solution
[RFC4068]. The research efforts are now directed to integrate this solution with other
4G mechanisms like QoS but this is outside the scope of this thesis.
The Mobile system (namely the HA) will pertain to the network operator. MIP’s
concept of session is the time a CoA is associated to a HoA. The parameters handled are
just these two plus the time-to-live of this association. This session is set-up and shut
down following MIP’s [RFC3775].
The network operator does accounting for the network access and packet
sending and receiving services. If we assume that network access includes the feature
of terminal mobility the MIP session does not need to be accounted neither authorised
(but it must be secured) so the user profile does not need to be taken into account for
handling MIP sessions.
The user-terminal(s) association during a session is, however, a fundamental
aspect. But this association in current proposals is not done by the MIP system but by
the MMSP or the NAS. Thus we can conclude that the MIP session can be kept
independent to the other ones. Nevertheless this thesis will explore the possibility of
involving the HA in user-terminal association and thus having to consider more deeply
the MIP session as part of the other sessions.
The other different types of mobility are not enabled by a dedicated architecture
but by features of another system. For instance, network access while roaming is
achieved thanks to the federation capabilities of the AAA system.
4.1.1.5 Network Measurement System
The measurement system is in charge of collecting data about network usage and
informing the entities needing it. It is thus part of the network operator.
Measurement is not a service required by the user but is a helper service for
those systems needing to control or to account for network resources. Thus the
- 100 -
measurement system does not need to check the user profile. However the systems
requesting measurement services may based these request on the user profile.
A measurement session will consist on the parameters to be measured (such as
throughput and delay) and parameters indicating the scope of these measurements (such
as IP addresses and DSCP of the packets). Measurement sessions are started and ended
by other systems. When the user starts to employ network resources, the QoS System
may start a session in the measurement system, to get data about the network usage of
this transport session. This data will be used by the QoS system to fill the accounting
requests it performs to the AAA system. Note that the QoS system may also get, from
the measurement system, data that is not bounded to any session, it just gives the
network status. For QoS transport sessions with no end indication, the measurement
system may prevent the QoS that no traffic is going through this session. Based on this
indication the QoS system will be able to end this session, free the reserved resources
and also indicate the measurement system to shutdown this session.
4.1.2 Systems’ interactions and their relevance for session setup
4.1.2.1 AAA-security
The two main types of mechanisms for authentication are knowledge-based and
certificate-based authentication. While knowledge-based authentication makes use of
shared secrets (i.e. passwords), certificate-based authentication relies on public and
private key pairs, i.e., asymmetric keys. In the case of shared secrets, the AAA System
(which is the identity that shares the secret with the user) can it self warrantee the user
identity to Systems requesting so. But in order to support the use of asymmetric
cryptography for authentication, the AAA system must interact with PKIs (Public Key
Infrastructure). The AAA system, to offer authentication services to other systems,
should make use of the authentication and validation services offered by a PKC/PKI.
There is another aspect that also requires AAA and “security” interaction. The
NAS in not only in charge of managing the access to the network, but also in securing
the communication between the mobile terminal and the network. It has to assure that
the packets entering the network operator can be associated to a user. Namely this
association will grant the user to CoA (or HoA) IP address correspondence. This is a
key point to allow the AAA-QoS interaction that we will describe in section 4.1.2.3.
4.1.2.2 Mobility - AAA+security
When setting up a MIPv6 session the correspondence between a HoA and a CoA
is done. But this correspondence must be authenticated and secured. The MIP RFC
[RFC3775], itself defines mechanisms for doing so. However Diameter mobile IPv6
application [LE04] proposes a new way, where the AAA system interacts with the MIP
system, in concrete with the Home Agent. This thesis does not consider this interaction.
First because some voices claim that this is not very convenient (see [BOU02]) and,
further, we see no gain in doing so; second, because separating this two processes
makes the design clearer as it decouples user AAA registration and MIPv6 terminal
registration.
- 101 -
A. Cuevas
Tesis Doctoral
Concerning Accounting, as we analysed in section 4.1.1.4, we don’t see the need
for accounting for mobility sessions (but yes for roaming, of course) so the AAA-MIP
interface does neither need to be considered for this aspect.
Referring again to this same section, Authorization does not need to be done for
mobility, since network access authorization is already done (and we assume network
access includes the mobility feature). But when moving and the terminal changes its
point of attachment, this network access authorization must be changed to the mobile’s
new point of attachment including the security mechanisms described in 4.1.2.1. The
mechanisms to transfer the “access authorization” are out of the scope of this thesis.
Diameter mobile IPv6 application proposes a concept that we will follow in this
thesis: the correspondence between the user (identified by his NAI) and the device(s) it
is using (identified by their HoA or CoA) is done by the AAA system.
4.1.2.3 AAA-QoS
The QoS system manages the network resources. It limits and shapes the amount
of traffic entering the network and decides which packets are high priority. These
aspects are mainly based on the profile of the user sending/receiving the packet. But
identifying and handling users is a responsibility of the AAA system. Besides, we have
seen that the AAA System employs this user identification to grant user access to the
network. But network access control and traffic shaping is also done by the QoS system,
so there is an overlap in the responsibilities of the two (AAA and QoS) systems. This
overlapping also happens in the domain of accounting. Both the network access session
(“owned by the AAA system”) and the QoS system transport session may account for
the user consumption of network resources. The clear definition, separation and
specialization of the roles of the two systems and the design of the interfaces between
them is a must for 4G networks to become reality [CUE03].
To our knowledge, our AAA-QoS designed interaction is the first proposal of
this kind. As we have stated, the definition of interactions between the different systems
participating in session setup is not our main objective but, as we will see throughout
this thesis, this interaction plays a key role in the session setup. It enables new ways to
coordinate the different systems and support of more scenarios than the IMS defined
ones. The lack of AAA-QoS interaction solutions, led us to develop our own one.
Our solution specializes the QoS system in packet control leveraging it of any
user related task, including managing his NVUP. The QoS system will only handle
packet parameters, such as source and destination addresses, flow label and DSCP.
The AAA system will handle user control and do the mapping between users and the
packets their devices are sending. Figure 30 shows the task division between the AAA
and QoS Systems.
AAA system will establish, for instance, a correspondence between the “source”
address of the packets (Home Address or CoA) and the user login (NAI, Network
Access Identifier [RFC2486]). Besides, the NAS within the AAA System will warrantee
that this mapping holds. This is the main role the NAS takes in the network access
session: a user can only attach to the network if this association is warranted. Then it’s
up to the QoS system to handle and account the transmission and reception usage this
user can do in the network. In other works [KUR04] the module accounting the packets
- 102 -
sent and received by the user is the NAS. Here we propose that the QoS system does so.
This system is more prepared to this, since having knowledge of the packets sent and
received is key to QoS. For these tasks the QoS system will only need to consider the
packet parameters and the QoS to give to them. Future sections detail when this event
takes place, along with the sharing of user profiles.
AAA System
User Control
User tranport-QoS profile
User & Packet correspondance
QoS to give to packets
QoS System
Network and packets control
Deals With Packets parameters
Figure 30 AAA-QoS proposed interaction
We must note that for MMSP assisted applications, the information about the
flows to be given QoS and the requested QoS may come from the MMSP. For
applications interacting with 3rd party VASP with agreements with the network
operator, it may be the 3rd party VASP the one providing this information to the QoS
system. But for the other applications (i.e. the ones following the Internet model) this
information can only come from the AAA system, in form of the user’s NVUP. So the
AAA-QoS interaction allows extending the functionality of our architecture beyond the
IMS like models.
Different ways of realising the AAA-QoS interaction would be possible, for
instance the one we proposed in [CUE03]. But this thesis will propose a model where
the QoS system is considered as a normal client of the AAA System. The service the
QoS system offers and for which it requests the AAA system authentication and
authorisation, is not content or any added value service but transport service with QoS.
For this service, the QoS system will also request the AAA system to do accounting,
based on the network resources usage done by the user.
4.1.2.4 MMSP-AAA and MMSP-QoS
This interaction is one of the key points to allow advanced session setup and
implementing the scenarios described in section 3. Due to its importance it will not be
dealt in great detail in this section that overlooks general 4G networks procedures. It
will be discussed in specific session setup sections.
This interface will allow all the services using the MMSP as a proxy for setting
up their sessions, to offer characteristics such as single-sign-on and unified billing.
- 103 -
A. Cuevas
Tesis Doctoral
This interface will leverage all the services using the MMSP as a proxy for
setting up their sessions, of having to tackle network level QoS reservations. Services
will only deal with a unified QoS negotiation and done at application level.
Coordination of sessions at transport and application levels will be done thanks to this
interaction.
4.2 Architecture of the 4G systems involved in session setup
En la sección 4.1 hemos visto los sistemas 4G involucrados en el
establecimiento de sesión y cómo interactúan entre sí. Pero para llegar a un nivel que
nos permita desplegar nuestras soluciones en una red 4G y evaluar sus prestaciones,
necesitamos ir más al detalle. Esta sección explicitará los nodos y componentes de cada
unos de los sistemas antes mencionados. Recalcamos que si bien muchos sistemas están
ya definidos (como hemos dicho en la sección 4.1) su arquitectura interna y, sobre todo,
dentro de una red 4G que puede tener millones de usuarios, no está, en muchos casos,
diseñada. Por otra parte, las interacciones entre sistemas que en su mayoría tuvimos
nosotros mismos que proponer en esa misma sección 4.1, encontrarán aquí el detalle de
entre que nodos se deben realizar. Analizaremos nuestra arquitectura, enfatizando en
aspectos de escalabilidad y posibles cuellos de botella.
4.2.1 QoS. Proposed designs for setting up QoS sessions
4.2.1.1 QoSBroker as central transport control entity
QoS enabled routers can under, for instance, the IntServ framework, provide 100
% QoS transport warrantees. But besides providing QoS warrantees, the network needs
to be properly managed to achieve more efficiency. Two approaches, which are
complimentary, are followed by the research community:
•
The routers can interact among themselves and, based on this interaction,
achieve a self optimised network.
•
There is a central management point that receives data about the network status
and, based on this data and other parameters, takes configuration decisions to be
sent to the routers.
To endow a router with QoS, several parameters must be properly configured:
markers, policers, schedulers, shapers and droppers. Besides, the QoS levels to achieve
will surely depend on network operator policies. The routers, through adequate
configuration, will enforce these policies. The approach of having a centralised control
point for QoS related issues that will distribute the proper configuration commands to
the routers is derived from the SNMP framework.
On the other hand, the transport QoS does not depend only on general policies
but also on user profiles and, as we have seen in section 4.1.2.3, in a 4G network users
profiles will be handled by the AAA system, not by the QoS one. Another aspect to
consider it that one of the approaches to integrate QoS transport session and application
sessions is based, as we explained in section 3.3.3 on MMSP and QoS system
interaction. These interactions could be done between the routers and the AAA and
MMSP systems. But it is not the natural role of the AAA or MMSP systems to
- 104 -
configure QoS parameters in routers. That’s why an entity that centralises the QoS
control managing these routers and able to interact with the AAA and MMSP systems is
needed.
We have stated the need of an entity that centralises the QoS control. This is the
SNMP framework philosophy. However, SNMP is not flexible enough for the provision
of higher level management concepts and interaction with other systems. That’s why a
new entity, the Bandwidth Broker or (QoS Broker), and protocols to communicate this
entity with the routers, are developed. The interfaces of the QoSBroker to the other
systems are also considered but their development is still under research. This is due
that till very recently the QoS brokers were seen as “isolated” entities handling all the
aspects like, for instance, user profiles and priorities. However, as we point in [CUE03],
in large scale networks and with more functionalities, there is a need to specialise
entities. QoSBroker will be specialised in QoS management and interfaces between the
QoS Broker and other systems specialised e.g. in user handling will be implemented.
These interfaces are vital for setting up transport sessions under the umbrella of the
complete service session. One of the contributions of this thesis will be to propose and
evaluate them.
4.2.1.2 QoSBroker: QoS management and access control
The QoSBroker has already been presented in the state of the art. The role it will
play in our architecture is the common role of a QoSBroker but it will be enhanced to
support, in an optimum way, all the interfaces to the other 4G systems.
The QoS Broker does network device configuration with the goal of achieving
end-to-end QoS (eventually over different networks). The QoS Broker manages and
monitors the network resources in one particular domain of operation. The
measurements needed for monitoring could be done by the QoS system entities
themselves but in our model this is done by an independent system, the monitoring
system that will interface with the QoSBroker. The QoSBroker also manages and
monitors the edges for the incoming and outgoing resource reservations/utilisation. In
conjunction with the AAA and MMSP System and all under the networks policies
defined and the monitoring data obtained, the QoSBroker (QoSB) is the entity in the
QoS system to take admission control decisions. The QoSB may also be responsible for
managing inter-domain communications with neighbour QoSBrokers, so that services
may be implemented in a co-ordinated way across various domains.
In IMS there is an entity, the PDF that also takes network admission decisions.
As we saw in the state of the art, UMTS has its own QoS management mechanisms and
at IP level the whole UMTS network is only one hop, so there is no need of managing
QoS at IP level, that’s why the PDF is only a decision point. The QoSBroker, besides
this policy function may also be in charge of the network management.
4.2.1.3 Access and Core Networks
As for scalability reasons one QoS broker can not handle one whole (big)
network, several QoS brokers may exist each having its own domain of operation.
Actually, managing QoS at the network level may be considered to have two different
aspects: one related with the management of the “access network” (AN) and the other
related with the management of the core network (CN). Thus the idea, also presented in
- 105 -
A. Cuevas
Tesis Doctoral
[CADENUS] and [COR03], is to organise the domains of QoS Broker operation
hierarchically; one domain will be structured in several ANs and in one CN. The ANs
limits are the ARs that connect them to the users and the Edge Routers (ERs) that
connect the ANs to the core network. The Core Network connects all the ANs between
them and also is the domain’s “gateway” to the Internet and other domains. The CN is
connected to the Internet by Edge Routers. The CN will be controlled by the CNQoSBroker and in a coarser level of detail than the AN is by the AN-QoSBroker. All
the other routers which are neither ER or AR are called Core Routers (CR)
irrespectively of they are in the access or core networks. Needles to say, depending on
the network topology, the AN – CN frontier may be much more blurred and not be
delimited by ERs. Figure 31 shows a domain’s network topology, divided in ANs and
one CN.
Internet
ER
CR
QoS
Broker
DiffServ CN
No access control,
No session
No need of flow-user association
CR
CR
ER
QoS
Broker
CR
ER
QoS
Broker
ER
IntServ
like AN
IntServ like AN,
Access control,
Sessions
AR
AR
AR
AR
Figure 31 Hierarchical network topology
The ANs are the parts of the network “closer” to the user and, as such, closer to
the access technologies that may have scarce BW and thus will require finer QoS
control. The AN will handle the QoS at “flow” level (which implies at user level as we
saw in 4.1.2.3). That means that the QoSBroker (QoSB) controlling the AN, (or ANQoSBroker) must have a notion of session. Note that the actual “per flow” QoS
mechanisms in the AN may be various (IntServ like, DiffServ access control, etc.) just
like the notion of flow. A flow can be considered in its normal sense: source and
destination address, layer 4 protocol and source and destination ports, or, in IPv6,
source and destination address plus flow label. However, we can also consider a flow as
the source address and the DSCP or other combinations suited to identify and handle the
different QoS enabled transport services offered by the network operator to its users.
Even if this thesis does not tackle QoS enforcement issues, the way the QoS
system manages the flow concept is important for session setup issues. As we said in
section 4.1.2.3, flows need to be associated to users (and to applications), to give them
the QoS contracted by “their user”. AAA system warrantees this association and the
- 106 -
QoS system will just deal with packets headers fields. Thus the association
packets(flow) to QoS(user and application) can be done. ANs have flow-based control.
But in the CN we propose not to have per flow QoS, only per aggregate, so the flow
identification and the above relation are lost. However, since in the CN there is no need
to do any user-based task (such as access control), the relation QoS-user is not relevant.
But, still, the relation packet-QoS must be maintained. The standard solution is to use
the DSCP field of the IPv6 header. DSCP carries the “QoS” information the packet
should be given. We will follow this approach. Roughly speaking, the QoS information
the DSCP conveys is limited to packet priority in the different aggregates but has no
clue about the flow bandwidth. This is enough for CN DiffServ based networks, but if
the packet traverses another “IntServ like” AN network, the DSCP information is not
enough. Besides, this new AN will also perform user based admission control and
packets will need to be associated to users again. This AN will need to handle those
packets in the same level of detail (flow level) as the first AN. The different proposed
possibilities to achieve this “transfer of details between ANs” are explained in section
4.3.3.
This proposed AN-CN “strategy”, also defines the way the transport session is
controlled by the QoS system. The CN will not manage any concept of session. We will
have only “sessions” in the ANs, each controlled by a AN-QoSBroker. We propose
those sessions to be independent and local to the AN and the AN-QoSBroker
controlling it. The end-to-end transport will then be defined by two sessions, one in
each of the endpoints AN; of course, if these two AN endpoints are the same, there will
only one session. As we will see in chapter 5, the two AN sessions will be aggregated
for just one single application level session.
The AN-QoSBrokers controlling the different ANs may need to communicate
between them (see the discussion in section 4.3.3). This can be done directly or using
the domain’s CN-QoSBroker as a “gateway”. If the AN-QoSBrokers are located in two
different domains, then the CN-QoSBrokers of each domain will be used as gateways.
4.2.1.4 AN-QoSBroker and AR in session setup
The AN-QoSBroker must take admission decisions and control that the QoS
transport is granted to users according to their profile. It will base its decisions on the
data provided by a VASP, by the MMSP (just like in the IMS model) or in the
information the AN-QoSBroker may get from the AAA system. This last option is new
respect to IMS and enables more scenarios to be supported as discussed in section
4.3.2.
But the AN-QoSBroker is not only a policy decision point (like in the IMS the
PDF): It also manages “its” AN resources. That includes handling the setup of QoS
sessions and this, according to the different options -existing or proposed in this thesisto do so, can be triggered in different ways:
•
MMSP (or VASP) issues a QoS allocation request
•
The user’s terminal does a QoS allocation request. Here several scenarios are
possible as we will see in section 4.3.3. We consider in this bullet that the
terminal can request directly (using a specific protocol) to the AN-QoSBroker
the delivery of the QoS transport service.
- 107 -
A. Cuevas
•
Tesis Doctoral
Routers do a QoS allocation request.
•
The terminal can “request” the QoS transport service to the network routers
(e.g. using RSVP) and these will outsource the decision to the ANQoSBroker.
•
The terminal can use in band signalling e.g. marking packets with special
DSCP codes and the AR will interpret this signalling and perform the QoS
allocation request done by the user. In this case, the only way to identify a
user the QoS system has, is thanks to the packets IP addresses and the QoS
needs by the inband information present in the packets like DSCP, or as we
will see, some special bits of the flow label. Thanks to the AAA-QoS
interaction described, this is enough to give user-profile-related QoS to the
packets.
•
The network (specifically the ARs) can infer the users needs and issue a QoS
session setup request to the AN-QoSBroker. The degree of intelligence
employed to infer the user QoS transport requirements, can be very different,
varying from:
o a simple identification of a new flow and its packets’ DSCP –stating the
QoS needs-, (the considerations made earlier about the way to identify
users also apply in this case)
o to analysing e.g. the FTP signalling and determine the BW needed. This
is discussed in [GOM04].
•
Propagation to this AN of the session created in another AN. Essentially this
propagation can be done via the AN-QoSBrokers. This will be analysed
carefully in section 4.3.3
•
Doing an inter-AN handover, the old AN-QoSBroker transfers the sessions to
the new AN-QoSBroker
The AN QoS Broker, upon the creation of the QoS Session, can request the
CMS system to create a measurement session to monitor the flow(s) pertaining to this
QoS session.
The AN QoS Broker is also responsible of handling the termination of QoS
sessions, aspect that can also be triggered in different ways:
•
Explicit request either by the MMSP or the user (in the ways presented above
for establishing a session) or because the network inferred that the session ended
(for instance it saw a FTP bye message).
•
For sessions depending on the NVUP, if the NVUP validity expires and the
renewal is not successful, the QoS Broker will shutdown these sessions.
•
For sessions with no explicit end indication the AN QoS Broker is signalled by
the measurement system that the flows related to this session are no longer
transporting traffic.
- 108 -
•
The AN-QoSBroker received an indication from another AN-QoSBroker telling
this session is ended.
•
The network is overloaded and resources have to be freed. The measurement
system or the CN-QoSBroker can trigger this event.
•
There is a inter AN Handover and the session is transferred to the new ANQoSBroker
Upon the shutdown of the session, if the AN QoS Broker created any
measurement session in the CMS related to it, it will ask the CMS to finish it. It will
also free any resources reserved in the routers of its AN. It can even notify other ANQoSBrokers of the end of the session.
The Access Routers (but also the AN’s Edge Routers for flows entering the AN
from the CN) must:
•
Process user QoS requests and outsource the decision to the AN-QoSBroker.
Users will signal their QoS requirements either explicitly (e.g. RSVP) or using
in-band signalling. In case of in-band signalling special codes can be employed
for starting and ending the sessions. But this is normally not the case. The codes
employed (e.g. DSCP values in the IPv6 header) will just indicate the “QoS”
needed by the packet. Then the AR must detect that these packets are the first of
a “flow” and perform the QoS setup according to the DSCP code. In this latter
case, the end of the session is detected by the AN-QoSBroker as mentioned
earlier.
•
Process user packets with no specific QoS requests, infer the QoS requirements
and outsource the decision to the AN QoS Broker. This covers the case of an
application that is not able to signal any QoS requirements and the terminal has
neither any middleware capable of doing so.
•
•
Maintain state of already granted requests.
The above processes can also be done by AN IntServ enabled Core Routers
(CRs), if the AN-QoSBroker does not configure the whole AN (including these CR
routers) when it receives a request from an AR. However we think it is better that only
the ARs (for flows coming from the users to the AN) and the AN’s ERs (for flows
coming from the CN and directed to users) will interact –indeed outsource the
configuration decision- with the AN-QoSBroker. Then the AN-QoSBroker will
configure these and all the needed routers in its AN. This approach reduces signalling as
we will show in section 5.
It is important for the reader to note that our description of the AN-QoSB and
AR behaviour illustrates the way the MMSP (or service provider) driven QoS transport
session setup works. It also illustrates how the terminal driven (either with explicit
signalling or inband signalling) QoS session is setup. Figure 32 summarises our
discussion, while Figure 33 deals with the session tear down. These proposed
procedures will be further detailed in next sessions, specifically the exact signalling is
described in section 5.
- 109 -
A. Cuevas
Tesis Doctoral
MMSP
AN-QoSBroker
AN-QoSBroker
Explicit signalling
P
ro ack
ut et
e s
th r i se
e nt nt
ne er a
ed pr nd
s ets
g
lin
al
).
n
g
,…
si
t
t
r
i
ta CP
ic
in
(s S
pl
)
g al D
ed P
Ex
n
at S C
l i ci
l
t
e
a
s
D
p
s g.
gn s
ed e.
Si ing
n e ts (
nd Us
a
b g.
oS e
Q ac k
In E.
p
Figure 32 Triggers in the AN-QoSBroker to setup a QoS enabled transport session
MMSP
CMS (user stops
sending
packets)
AN-QoSBroker
AN-QoSBroker
Explicit signalling
P
r o ac
k
se ute et
ss r s S
io int e
n e nt
is rp a
en re nd
di ts
ng a
Network
overload (CMS
or CNQoSBroker
indication)
g
lin
).
al
n
,…
g
i
d
s
n CP
it
( e DS
ic
g
pl
ng ial
in
i
x
l
E
al ec
nd s
n
p
e
g s
s et
S i ng
ps ck
nd Us i
t o pa
a
S
b .
In E.g
Figure 33 Triggers in the AN-QoSBroker to tear down a QoS enabled transport session
4.2.1.5 Role of the CN-QoSBroker in session setup
In the CN, there is no notion of QoS enabled transport session; the CN QoS
Broker does not participate in the sessions. The core network QoS Broker works in a
less dynamic mode. It gets the measurement data of the core network from the
measurement system. It may also get data (and even requests) from AN-QoSBroker
about inter AN routes. This data will be on a per class/aggregate basis. The CNQoSBroker acts over the core network elements under its control to assure constant
availability of core resources. It can even tell some AN-QoSBrokers to limit the user
access if some parts of the core network are getting excessively overloaded. The CNQoSBroker is in charge of inter-domain QoS. The CN-QoSBroker also acts as a QoS
signalling gateway between domains (between the AN-QoSBrokers of the different
domains, if this is enabled) and also, if needed, between the AN-QoSBrokers of the
same domain.
- 110 -
4.2.1.6 Interactions with the service providers. Application garden
The service providers (with agreement with the network operator) interface to
the QoSBroker can be identical to the one of the MMSP. The difference is their
topological location. MMSP functionally, as we will see in section 4.2.2, is distributed
over the network, but the service providers are not, each is located in single “place”.
The service providers could then interface to the CN-QoSBroker which in this case will
take the role of a AN-QoSBroker. They can also interface to a dedicated ANQoSBroker. This dedicated AN-QoSBroker along with the dedicated AN-AA and ANMMSP will form what we call the application garden. Note that those AN servers do
not define any AN, since the service providers may be located in many different places
and scattered over the internet.
4.2.1.7 Roaming and local AN-QoSBroker as contact point
The QoS transport service is, obviously, provided in the visited domain (in
concrete in the AN) and all along the e2e QoS path, but not in the home domain. So, for
roaming users, the QoSBroker that will handle the QoS the users receive is the visited
domain AN-QoSBroker.
4.2.1.8 Summary of QoS system interactions
As a conclusion, the AN QoS Broker handles all the QoS System session
concept that we explained in section 4.1.1.1. It deals with all the session parameters
there defined and with the relevant parts of the user profile. It interacts with the other
elements handling the sessions. Figure 34 summarises the central role of the ANQoSBroker.
QoS
Broker
Internet
DiffServ CN
Measurement
system
AAA
system
IntServ
like AN
Measurement
system
QoS
Broker
MMSP
VASP
Users
Figure 34 QoS system interactions
4.2.2 MMSP design
Like in the IMS (section 2.2), this thesis proposes the operator’s MMSP
infrastructure to be hierarchically divided in several parts (besides the SIP-UA present
in the users’ terminals). These “parts”, following an analogy with the QoS System
- 111 -
A. Cuevas
Tesis Doctoral
should be termed AN-MMSP and CN-MMSP. We propose, however, several changes
respect to IMS SIP proxies hierarchy to best suit to our 4G architecture.
4.2.2.1 AN-MMSP
We propose the AN-MMSP to be the contact point of the MMSP-UA, that is it
will play the functions of the IMS’s P-CSCF. In the IMS, the entity interfacing with the
PDF (equivalent to the AN-QoSBroker) is also the P-CSCF. We thus propose that the
AN-MMSP also interfaces with the AN-QoSBroker. Since there is a 1:1 correspondence
between AN-MMSP and AN-QoSBroker, the AN-MMSP – AN-QoSBroker interactions
become easier both in terms of implementation and design, because the AN-MMSP
does not need to look up which AN-QoSBroker to interface to. In IMS the P-CSCF, just
instructs the PDF about the user’s permissions but does not handle any QoS session
setup with the PDF. But in 4G scenarios, the AN-MMSP will be able to setup the QoS
session with the AN-QoSBroker, if needed. Besides, for issues such as seamless
mobility and in, particular, the make-before-break paradigm, the MMSP entity
interfacing with the AN-QoSBroker should keep state of the QoS session created with
it. This is to allow, in the case the user moves to an area controlled by a different ANMMSP, to transfer the QoS reservation context to the new AN-MMSP entity. Profiting
that the AN-MMSP entity should be state full, it could also keep the session state, like
actually does the S-CSCF in IMS. In SIP terminology we would say it is “call stateful”.
Making the entity that interacts with the AN QoS Broker (the AN-MMSP) call and
QoS session stateful will enable the AN-MMSP to trigger content adaptation or
renegotiation of the session if the QoS parameters of the transport session change
during the session. IMS presents such features but only during the QoS session setup,
not if the conditions change (since the P-CSCF does not maintain QoS session state).
That is the reason why we propose to create an entity, the AN-MMPS that will merge
the functions of the P-CSCF and S-CSCF in the IMS. Those functions require many
computing resources, but, since the AN-MMSP will be distributed per access network
and not per domain, no scalability issues should appear.
The QoS and MMSP system interaction is done between the AN-QoSB and the
AN-MMSP. AN-MMSP and AN-QoSB are always located in the visited domain. Thus,
if the AN-MMSP – AN-QoSB interface is enabled not just for policy purposes but also
for QoS reservation (see section 4.3.3) this QoS reservation will be directly done in the
visited domain.
Besides, the AN-MMSP also interacts with the AAA system to get user related
data. AN-MMSPs control many aspects of the session setup and can even modify –
based on the information they possess- the contents of the SIP signalling between the
peers in order to improve the setup or other processes.
4.2.2.2 CN-MMSP
We will let the CN-MMSP handle the issues that the I-CSCF tackles. CNMMSP are not distributed in the domain like the AN-MMSP are, indeed there could be
only one CN-MMSP per domain. We should do any inter-domain communication go
through the CN-MMSP. CN-MMSP won’t be call state full thus alleviating much their
work and coping better with scalability concerns. Nevertheless, the CN-MMSP needs to
be transaction state full to know to which AN-MMSP(s) direct the (SIP) signalling
messages. To know the device(s) where a user is logon and in which AN they are
- 112 -
located in, the CN-MMSP will interface with the AAA system. The AAA system plays
the role of a “SIP” registrar. Indeed, as we will see in section 5, the SIP registrar
functionality will not exist, the AAA–NAS registration should be enough.
4.2.2.3 SIP message “routing” proposal. MMSP interfaces
Several SIP message routing schemes could be adopted. However, the first
message must be routed through the callee CN-MMSP because it is the one interacting
with the CN-AAA “SIP Registar” and thus the one capable of locating the callee. For
the rest of messages, in intra-domain scenarios the AN-MMSPs could communicate
directly. There are not yet many SIP related performance studies but according to
[JAN03] one of the most demanding aspects in SIP is the processing of the record
routing headers. So this issue should be considered carefully when designing a SIP
based infrastructure. We propose to specialize the AN-MMSP in session handling and
interaction with AAA and QoS systems and let the SIP message routing be done by the
CN-MMSP. The main function of CN-MSPP will then be SIP message routing, both
intra and inter domain. Also, as does the I-CSCF in IMS for THIG issues, the CNMMSP could insert (or delete) the need record route fields in the SIP messages and
alleviate the AN-MMSP of this task. The AN-MMSP within the same domain of the
CN-MMSP will use it as a SIP “route point”: AN-MMSPs will only send messages to
the devices directly “attached” to them (to their SIP User Agents modules) or to the CNMMSP. Thus the AN-MMSP are alleviated from any routing related aspect, they just
have to consider the mobile terminal to send the message to.
The price to pay is that the CN-MMSP becomes a single point of failure and also
that the CN-MMSP complexity increases while CN-MMSP is not a distributed entity.
Of course, as any other important server, the CN-MMSP can be replicated. The
advantages of this proposed “routing specialisation approach” will be studied
quantitatively in section 6.
The SIP message routing along with the MMSP interfaces to other systems are
illustrated in Figure 35.
Internet
MMSP
DiffServ CN
CN
MMSP
AAA system
MMSP
AN
AN
QoS
system
MMSP
MMSP
AN
AN
MMSP
AAA System
VASP
Users
Figure 35 MMSP interactions. Dashed, intra domain communication; solid inter domain.
- 113 -
A. Cuevas
Tesis Doctoral
4.2.2.4 Roaming
AN-MMSP will be located in the visited domain thus the session is controlled in
the visited domain, which may not be acceptable for some operator policies. So we
should make all the signalling go through the home CN-MMSP which in this case,
depending on the operator’s policies, may need to maintain the state of the session.
Assuming that the number of roaming users will not be very big, this should not present
a big scalability problem. Besides, the home CN-MMSP does not need to keep track of
the session in a so very detailed way as the AN-MMSP does because it does not handle
QoS issues. Another reason to make the signalling go through the CN-MMSP is that
they can interact with the register (indeed the AAA system) where the user has indicated
its NAI and the terminal’s IP address where it is logged on.
4.2.2.5 Application garden
Jut like in the IMS, there may be some value added service providers that may
interact with the MMSP. To mimic the QoS “application garden” we propose that this
interaction is done via a dedicated AN-MMSP.
4.2.3 IRTF’s AAA and our decentralisation proposal
Our AAA System architecture will be based in IRTF generic AAA architecture.
The AAA system consists on a server (or a pool of servers) handling databases with the
user profile containing, at least, information such as a password or bank account number
(section 4.1.1.3 discussed the user related data the AAA system holds). Other modules
and their eventually associated databases may be coupled with the AAA server. Those
modules can be, for example, SAML single sign-on module (see section 5) or charging
calculation. The AAA server will interact with the AAA clients of its domain. AAA
clients will be implemented in components that require the support of the AAA server.
The AAA clients may request the AAA server to:
•
authenticate the user that the module they belong to is dealing with
•
to verify whether this user is authorised to consume the services that the module
the AAA client belongs to provides
•
and to account the session that the module they belong to is handling
The AAA server can interact with AAA servers from other federated domains.
This interaction will occur when the AAA server does not know how to deal with the
user (it is not in its databases) but knows the domain and the AAA server that will
handle the user.
The NAS presented in section 4.1.1.3 is a system that handles network access
and assures the mapping of the user to the packets he sends. NAS “understands” client
network access requests (detailed in section 5) but can not itself decide: NAS needs the
services of the AAA server and thus implements a AAA client. Since NAS warrantees
access to the network and user-packet correspondence, it should be placed in the usernetwork contact point: the ARs.
Other clients of the AAA server are the AN-QoSBs, the AN-MMSPs and the
service providers. SAML -one of the most promising frameworks for assuring single
- 114 -
sign-on over the IRTF’s AAA architecture- is a very verbose protocol and should be
used by all the AAA clients. SAML verbosity plus the proliferation of AAA clients lead
to AAA server scalability concerns. To cope with this, this thesis proposes to
decentralise the AAA server in a similar way it is done for the other systems: divided in
AN and CN. Note that the design or enhancements of the AAA system are not the
objective of this thesis. However we will deal with this topic. Let’s explain why: To
satisfy the aggregation of sessions and the business models proposed in section 3,
several mechanisms must be achieved. This thesis follows the most accepted ones and
proposes ways to orchestrate them. These mechanisms relay heavily on the AAA
system. Thus we estimated, for the “existing” solutions and for our proposal to be
feasible, the AAA system should be enhanced in the sense it should be distributed and
not centralised, and this to upgrade its scalability. Next we will propose how.
The most obvious function to decentralise is Accounting. Accounting servers
should be scattered all over the network, perhaps putting one per AN, termed ANAccounting. These servers will satisfy AAA clients accounting requests, perform the
accounting and send to the AAA server only aggregated and consolidated accounting
data. This is like in the IMS the CCF node. In prepaid-online charging scenarios, these
AN-Accounting servers could also manage the remaining budget of the user and, in case
it is no longer enough, prevent the AAA client which will tell the module it is running
in to stop the service. This is just the function of a diameter credit control server
[RFC4006]. This function indeed, falls into the filed of authorization. It could be done,
because the AAA server delegated this authorisation function to the AN-accounting
server. How was this delegation done?: By transferring to it the part of the user profile
to be considered for this authorization, in this case the remaining budget. In a similar
way, other authorisation functions could be delegated by the AAA server to the ANAccounting, which then becomes a AN-Authorisation+Accounting (AN-AA) entity.
Thus this AN-Accounting server may also perform authorization functions. Of course,
when the AN-AA is not able to take a specific authorisation decision, it will just
forward the request to the AAA server. An important point to consider is when the parts
of the user profile will be transferred. We will deal with this in section 5. This
discussion considers that the AN-AA (AN-Authorisation+Accounting) is a perfectly
trusted entity, i.e. belongs to the same domain than the AAA server. But this is not the
case when a user is roaming, the AN-AA will be the one of the visiting domain. In this
case, the authorizations functions to delegate (if any, including the credit control one)
will depend of the domains’ signed SLAs.
Needless to say, this authorisation is done over previously authenticated users.
The authentication of the users will not be delegated to the AN-AA.
In summary, the AN-AA will be the contact point of the NAS, the AN-MMSP
and the AN-QoSBroker. It will perform accounting aggregation and the functionalities
of a diameter credit control server. Some authorisation functions can also be performed
by it. When the AN-AA can not perform a task, or in the case of authentication requests
it just acts like a proxy with the AAA server or CN-AAA.
4.2.3.1 Application garden
Again we propose the value added service providers to interact not with the
AAA server directly but with a dedicated AN-AA. The dedicated AN-AA, AN-QoSB,
and AN-MMSP form the application garden.
- 115 -
A. Cuevas
Tesis Doctoral
4.2.3.2 Conclusion, AAA System interfaces
Figure 36 illustrates the AAA system interactions.
AAA
Server
Internet
DiffServ CN
MMSP
VASP
IntServ
like AN
AN-AA
MMSP
QoS System
NAS
Users
Figure 36 AAA system interactions
4.2.4 Other systems: Measurements & Mobility
Considering other systems, these can also be hierarchically divided. For
instance, the measurement system can be composed of several probes spread in the AN
(mainly in the routers) and reporting their measurements (and controlled by) a AN
Central Monitoring System (CMS). This AN-CMS will interface with the ANQoSBroker for delivering it the measurements results. The same structure can be
followed in the CN, but this time the measurements will be made in a much coarser
level. Apart from the probes located in the CN, the CN-Central Measurement System
can receive data from the AN-CMS. The CN-CMS will interface with the CNQoSBroker to deliver him the status of the CN.
The MIPv6 mobility system is composed of a Home Agent and the Mobile and
Correspondent nodes. There can be several home agents per administrative domain,
each one handling the terminals under its address space. If hierarchical Mobile IP
[RFC4140] is employed, the Mobile Anchor Point (MAP) –a kind of “sub Home
Agent”- could be located, for instance, in each AN. As we propose in this thesis (see
section 4.1.1.4) the mobile IP session will be independent form the others so no further
consideration will be done regarding the MIP architecture.
4.2.5 AN CN split and WiFi hot spots venue owners.
The idea of splitting many of the network enabler functions (AAA, MMSP, etc.)
in several parts (AN and CN), apart from a cleaner designer and advantages regarding
scalability, is very well suited to cope with some business models presented in section
3.2. In concrete we refer to the case where large WiFi hot spots venue owners (like
airports) may decide to build an access network and sell this access to different mobile
networks operators (and their customers). This venue owners network will form a AN
- 116 -
network, with QoS capabilities and able to manage users sessions. This can be specially
useful if, for instance, a user wants to print from his laptop in a printer in the business
lounge of the airport. This service can essentially be handled by the airport AN.
However, it must be clear that for any communication outside the airport, the mobile
operator must be contacted. Besides, since this operator keeps the customer relationship
and the ownership of the AAA servers, the venue owner should not be able to charge
users directly, only in co-operation with the mobile operator. Services that can be
charged to users are, for instance, the printing service we mentioned. In this model, it is
expected that network operators will be glad to integrate many venue owners into their
network, since they keep controlling the user relationship, they offer more services
(access in airports, etc.) to their users and the integration of these ANs does not pose
any difficulty or scalability constraints; they are, indeed, just like any other network
operator’s AN.
Equipment vendors may also design a AN server set, composed of the ANMMSP, AN-AA, AN-QoSBroker and AN-CMS. The communication between these
servers can also follow proprietary protocols (to the CN elements and the users and
routers, standard protocols will be needed).
4.3 Session setup possibilities in the proposed architecture
Sections 4.1 and 4.2 built our 4G architecture proposal and analysed the
different approaches. We described the role of each node and system. We shall see in
this section how to setup sessions on top of this proposed 4G architecture. We will draw
different solutions and will see how they fulfil the proposals made in section 3.3.
4.3.1 AAA Authorization or distribution of users profiles?
One of the functions of the AAA system is to take authorization decisions about
already authenticated users. For instance, a service provider will use its AAA client to
ask the AAA system if a certain user (e.g. [email protected]) is authorised to use
the service the service provider offers (e.g. stream a movie rated for over 18 year old
people). The AAA system is informed by the service provider about the service
characteristics (for over 18 years old), then looks at user’s age in his profile, takes the
authorisation decision and informs of its result to the service provider. This is the most
normal way the AAA system delivers its authorization service. But there is another
approach. The new way would be to use the AAA system as a user profile dispatcher
and let the service provider take the decision. In this same example, the service provider
will request the AAA system the profile of [email protected] (indeed just the
relevant parts, like his birth date) and, based on this profile, the service provider will
itself do the authorisation. Note that this proposal follows the same philosophy as the
delegation of the Authorisation function to the AN-AA (see section 4.2.3). This thesis
compares and evaluates both approaches.
The first approach presents some drawbacks:
Both AAA client and AAA system need the added functionality to parse and
understand every detail of information in the used profile (note that the service hosting
the AAA client needs this functionality anyway, because it actually implements the
- 117 -
A. Cuevas
Tesis Doctoral
service). This will force the AAA system to deal with every possible combination and in
different granularity of the services authorisation parameters.
If, at anytime, only a small change occurs in the service authorization parameters
(which is very likely), both entities (AAA system and AAA client) have to be changed.
For example, this change may just happen if there is a new regulation replacing the old
classification of movies (from 2 types: “over and under 18 year old” we have 3: “under
7, between 7 and 18 and above 18 years old”)
But the approach has a clear advantage: the AAA system does not need to
deliver the user profile to other entities. Note that in future walled garden models, like
today happens with i-mode, the operator (and thus its AAA system) may have contact
with multiple service providers. Besides, these service providers can be divided in
categories –like i-mode also does- for instance privileged relationship and normal
relationship. The service providers in the normal relationship may not have the privilege
of receiving any part of the user profile.
The second approach has the symmetric advantages and drawbacks: the AAA
system task is only to transfer the appropriate parts of the user profile. But this implies
exposing user data to all the service providers with which the AAA system has a
relationship.
This thesis proposes to use the second approach (distribution of parts of the user
profile) with some privileged AAA clients; among these the MMSP, which will receive
the SVUP –the parts that are related to applications using the MMSP as proxy to setup
their sessions- and the QoS System (AN QoSBroker) which will receive the NVUP.
This first approach (authorization done by user’s home AAA system) will be followed
with the “unprivileged” service providers.
4.3.2 Session setup: proposals to orchestrate the interactions
between systems
Several are the ways to orchestrate the functionalities of the different systems
participating in session setup. We will refer and compare our approaches to the IMS
proposal. The different suggested possibilities are summarised in Table 15.
Essentially, IMS uses the P-CSCF interface with the PDF for policy issues:
CSCF tells the PDF which policies to apply to a certain user. Then it’s up to the
terminal to do the actual QoS reservation. In IMS the PDF can not setup the QoS
transport session and configure the network elements because, even if IMS is designed
in a “true IP” basis, it has to collaborate with UMTS networks which have their own
QoS reservation and handling mechanisms. These mechanisms mandate that the QoS
reservations are made by the terminal and managed and enforced by UMTS specific
elements, and not by the PDF.
In our 4G networks architecture the CSCF-PDF interaction corresponds to the
interface between the AN-MMSP and the AN-QoSBroker. This thesis proposes to use
this interface also to trigger the QoS reservation: i.e. that the AN-QoSBroker configures
the needed routers. In Table 15 this is illustrated by “Terminal Option 2, just sends
packets” and assuming that the AN-QoSBroker did the QoS reservation after being
contacted by the MMSP. We should support as well, that this interface has just the same
- 118 -
functionally as the PDF—CSCF one, only transfer of QoS related policies. In the table,
this corresponds to the cases where the Terminal follows “Option 1: Does reservation”
and the AN-QoSBroker does not setup any QoS reservation. These two approaches will
be compared and their coexistence analysed in section 4.3.3.
Another difference is that the IMS defines no interaction between the PDF and
the HSS, but we do define an interaction between their “homologues” the ANQoSBroker and the AAA System (AN-AA). This interaction allows us to propose
added possibilities respect to the IMS:
•
•
Non delivery of users profiles by the AAA. The first advantage of our proposed
AN-QoSBroker AAA interaction is that we can make the AAA system to perform
actually the authorization decision, without delivering the user profile to the service
provider (which may be better in terms of security) or to the MMSP. Once the
authorization is done, the service provider (or the MMSP) can interact with the
QoSBroker but, in this case, it can not specify the parameters of the QoS transport
session related with the user profile (because the AAA system did not delivered
them). The service provider (or MMSP) will just interact with the QoSBroker to
inform it about the QoS required by the service and about the identification of the
flows transporting the data of the sessions controlled by the service provider. Then,
the QoSBroker can interact with the AN-AA to check for the validity of this
reservation and for getting the missing (user related) parameters. The AAA System
will match the service provider and the QoSBroker requests and will base its answer
to the QoSBroker on user and application dependent parameters found in the SVUP.
This scenario is illustrated in Table 15, under the "AAA not delivering user profile”
tag.
Support of “non IMS” or Internet like scenarios. These scenarios are not assisted
by the MMSP (or by a service provider with agreement with the network provider).
In “IMS like” scenarios, the MMSP or the service provider can dictate the
QoSBroker the policies related to the user, just likes the CSCF does to the PDF. But
in the scenarios here considered, where this interaction does not exist, the
QoSBroker needs to check with the AAA about the user permissions recorded in the
NVUP. This functionality is not provided in the IMS framework and is possible
thanks to our proposed AAA-QoS interaction.
CSCF
CSCF
Terminal
AN-MMSP
AN-MMSP
Terminal
IMS
 Gets user profile and based on it performs  HSS
authorisation
User and communication related policy
PDF
PDP context activation (reservation)
PDF decides
IMS adapted to 4G architecture
 Gets user profile and based on it performs  AN-AA
authorisation
AN-QoSB (may do
QoS reservation)
Option 1: Does QoS reservation
AN-QoSB decides
Option 2: Just sends packets (variant to IMS)
AAA not delivering user profile
- 119 -
A. Cuevas
Tesis Doctoral
Service provider
 Authorisation decision
Service Provider
communication related policy
AN-QoSB (may do  Get the user related data
QoS reservation)
Terminal
Option 2: Just sends packets
Terminal
AN-QoSB
Internet model
Does reservation or just sends packets
 Checks with AAA to take the decision
 AN-AA
AN-QoSB
 AN-AA
ANQoSB decides
AN-QoSB decides
 AN-AA
Table 15 Ways to orchestrate MMSP, QoSBroker and AAA interactions
There is another possibility to orchestrate the work between the AAA, Service
Providers (or MMSP) and QoS Systems. We propose that the AAA system becomes
the sole network operator interface towards service providers with an agreement with
the network provider. It can also be the sole interface for the MMSP, in the case where
the terminal does the QoS reservation. This approach is illustrated in Table 16. The
service provider will interface with the AAA system following the same possibilities we
proposed above (authorisation or delivery of user profiles). However, the service
provider will give the AAA system more details about its service and users’ data it may
have. With these extra details the AAA system can (and should) contact the QoS
System so that it performs the QoS session setup (or just has ready the correct set of
permissions for when the user does the session setup).
The AAA system is “prepared” to deal with the AAA clients of the service
providers. However the QoS system is not prepared to interact with the service
providers (there are no defined protocols for this). In this approach, the QoS system
does not interface with the service providers; but it did so in the previous proposals.
This is the main advantage of this method. The drawback is that the AAA system is not
prepared at all to setup QoS sessions with the QoS system. Note that if there is the need
to maintain the state of the QoS session, this has to be done by the AAA system. But the
AAA system is neither a part of the communication (like may be the users or the service
providers) and it’s neither a mediator (like the MMSP) so the QoS setup is completely
outside the scope of the functionalities provided by the AAA system.
However if the AAA system does not try to setup a QoS session, it just delivers
policy data to the QoS system then this approach could work. In Table 16, first case, the
terminal doing the QoS reservation and not the AN-QoSBroker illustrates this approach.
Moreover, another option would be that the AAA system just retains this data and that
when the Mobile node does the QoS reservation, the QoS System asks for it. This
variant is also illustrated in Table 16, under the label “No AAA push of QoS policies”.
This last approach finds also its applicability in the MMSP case, if we chose that
the MMSP neither does the QoS reservation nor contacts the QoSBroker. This scenario
is possible thanks again to our proposed AAA-QoS interaction.
Service provider
AN-AA
Terminal
AAA as sole interface to Service providers
decision
and
QoS  AN-AA
 Authorisation
information
AN-QoSB (may do
QoS reservation)
AN-QoSB decides
- 120 -
Option 2: Just sends packets
Service provider
Terminal
AN-QoSB
AN-QoSB decides
No AAA push of QoS policies
 Authorisation decision
Does QoS reservation
Get communication related policy

 AN-AA

AN-AA
Table 16 Ways to orchestrate MMSP, QoSBroker and AAA interactions with the AAA
being the sole network contact point
4.3.3 Proposals for QoS transport session setup. Propagation of
QoS sessions
As we have seen, there are several ways to setup the QoS transport sessions.
This section will analyse them. It will also address how to setup QoS sessions that
involve two ANs. The aspects to be considered when evaluating the different
approaches are the scalability, the information needed to be transferred between the
different ANs (such as user profile) and the coexistence of the different solutions.
4.3.3.1 MMSP or Terminal doing the QoS reservation
As we have explained, the MMSP (or a service provider with an agreement with
the network operator) can just tell the QoS system (the AN-QoSBroker) the flows to be
given transport QoS or can also request the QoS system to perform the QoS reservation.
The advantage of this second approach is that transport QoS can be given to completely
QoS unaware terminals. Those terminals do not need to setup any QoS session nor to
co-ordinate the application and transport session setup.
Apart from the aspects considered above, there is also a fundamental issue to be
taken into account: the state that needs to be maintained by the different elements. In the
case the network reservation is done by the AN-MMSP it should keep the state of the
network reservation, but this should not be a very big surcharge to the AN-MMSP
because the AN-MMSP already keeps the session state, just like we discussed in section
4.2.2. If this QoS session setup is done by the Terminal then it is up to it to keep this
state. This is not a big issue neither since, if the terminal is enabled to do QoS
reservations, it should also be enabled to keep the state of this reservation. However, the
big concern appears when doing a fast handover with make-before-break and context
transfer characteristics. Performing a context transfer in the handover process implies
gathering state information from all stateful entities involved in a session. But parts of
this context may not be needed immediately in the new destination, they can “arrive”
after the communication is established in the new destination. For instance, if there is an
inter-AN handover, the accounting state may be shifted from AN-AA to AN-AA after
the communication has resumed in the new AN. But for other aspects, for instance, the
transfer of transport QoS configurations, the context transfer must be immediate and
take place before the communication is resumed. The parts of the context to be
transferred immediately during a handover should be kept to the minimum. From this
point of view, it is interesting to place a large fraction of the context in the common
element in the handover: the terminal. In this aspect, the terminal handling the QoS
session setup is better. If we consider the case of the service provider (instead of the
MMSP), since this entity is not replicated in different AN networks, the context transfer
- 121 -
A. Cuevas
Tesis Doctoral
does not need to be done when doing inter-AN handovers, so the problem does not
appear.
Other factors exist in the MMSP vs. Terminal QoS reservation comparison, for
instance, if the MMSP needs to handle the QoS reservation it will have more processing
load. Those aspects need to be evaluated quantitatively and this will be done in section
6.
4.3.3.2 Terminal non inband QoS reservation ways
Respect to the ways a QoS enabled terminal has to do QoS reservations, there
are two:
1. The terminal directly contacts the AN-QoSBroker and this will verify, if needed,
with the AAA System (with the AN-AA) if the user is authorised to use this QoS
transport service. This approach considers the AN-QoSBroker like any other
service provider. This approach is a proposal from this thesis.
2. The terminal uses a reservation protocol, like RSVP. The routers, before
granting the request outsource the decision to the QoSBroker. The QoSBroker
may also contact the AAA system (in concrete with the AN-AA) to check the
user’s permissions. This approach is more followed in the literature [PAP02]
These two approaches need to be considered deeper. Let’s recall that, to our
knowledge, this thesis carries on the first study about QoSBroker and AAA system
interaction. That’s why when dealing with similar problems, the current works do not
consider the QoSBroker-AAA system interaction.
The first approach is very suitable in terms of AAA-QoSBroker interaction
because it perfectly falls within the single sign-on framework that we will detail in
section 5. However, the protocol between the terminal and the QoSBroker has not been
studied yet.
The opposite considerations can be made to the second approach. The protocol
between the terminal and the AR is well known (RSVP) and also between the AR and
the QoSBroker (COSP). But, in this case, the one requesting the service to the
QoSBroker is the router, not directly the user. If the QoSBroker needs to contact the
AAA system it must provide him with the user’s credentials (the artifact in the SAML
framework considered in section 5), but since the QoSBroker was not contacted directly
by the user, this may cause problems. This will be analysed further in section 5.
We note also that the result of the process will be the QoSBroker sending
configuration parameters to the routers. In the second approach, the routers are also the
ones doing the request to the QoSBroker (which is not the case, in the first one), so this
option may be easier to implement and more scalable since there are less signalling
messages (the configuration parameters are carried in the response to the routers).
4.3.3.3 Terminal inband QoS reservation and flow QoS identification
The use of in “band signalling” is also possible to request QoS. The process has
been studied in section 4.2.1. In this section we will consider the case where the inband
- 122 -
signalling is used to state the packets’ QoS “needs”. We do not consider that inband
signalling is used to indicate (with e.g. special DSCP codes) the start or end of the QoS
reservation. We will describe the process for marking the packets appropriately.
In band signalling has its major relevance when the application or the mobile
terminal have not the capacity to signal any transport QoS setup and neither they
employ the MMSP or a VASP that could setup the QoS session. In this case a
middleware is used to “write” inband QoS signalling in the application flows. By
“write” we mean to mark some of the fields of the packets with QoS codes. These fields
are, in the IPv6 header, the DSCP; the flow label may also be used for this purpose.
Note that this inband signalling is not exclusive to middleware, some QoS aware
applications may use this technique to signal their QoS requirements. The biggest
drawback of inband signalling is that the terminal can not receive any feedback from the
network about the status of its QoS reservation (specifically when the QoS setup is
finished) so the terminal has no way to co-ordinate the QoS session setup with the
application session setup. This may drive to situations like “ghost rings”: i.e. the callee
is alerted because the session is setup at application level but, then, it fails to be setup at
transport layer.
Several solutions exist in the literature for inband signalling but (to our
knowledge) none has considered user profile parameters. Our proposal [GAR03], for
the middleware to match the QoS inband signalling with the NVUP, is related next. The
middleware in the mobile terminal should be capable of identifying some well known
applications and protocols like web browsing, RTP, etc. It can do so, for instance
looking at the ports of the packets. Each application should have associated a “QoS
class”. The NVUP will also be dumped to the terminal (for instance, upon registration;
see section 5) and associate an inband signalling code (DSCP and, possibly, flow label
value) to each “QoS class”. For instance, imagine that all the RTP flows would be
associated by the middleware to the QoS class “interactive”. For this class, the user, in
his NVUP should have a DSCP corresponding to EF but since the user is a low profile
user he will just have AF11. The DSCP along with the address of the packets (source
address for the packets sent and destination address for the packets received) will be the
two parameters available to the QoS system (namely the AN-QoSBroker) to identify the
QoS to be given to the packets and matching user’s profile. We recall that, thanks to the
AAA-QoS interaction defined in this thesis, the QoS system does need only to “care”
about packets parameters and not about users.
It must be noted that the DSCP has a meaning limited to DiffServ networks. In
the AN IntServ like networks finer QoS details are needed. For this, this thesis
proposes to use some bits of the flow label to indicate these “details”. In concrete two
bits should be enough to specify the flow bandwidth. The flow is identified by the other
flow label bits. The meaning of these two BW bits (actual BW value) can depend on the
DSCP. For instance for EF DSCP the two bits combination “10” would mean 256 kbps
but for AF11 these same two bits could mean 1Mbps.
[RFC2474], [RFC2597], [RFC2598] define the DSCP codes and propose to use
them universally. However, if a DiffServ domain decides to employ different DSCP
codes, DSCP remarking mechanism at the edges of this domain are designed. The same
approach should be followed with our proposed DSCP + two flow label bits
combination. Besides, in case of roaming to a domain with different DSCPs + flow
label meanings the AAA server located in the visited domain should do the mapping
- 123 -
A. Cuevas
Tesis Doctoral
between the DSCPs and flow label bits of the two domains when delivering the NVUP
to the user terminal and QoS System.
Note that the method of stating the packet’s QoS requirements using the DSCP,
only influences the packets the user sends and there can be mismatches with the
reception part of the NVUP of the other communicating peer. The different approaches
to overcome this situation have been discussed in section 3.3. Some of the approaches
there described are very suited for this simple QoS setup scenario like having only
restrictions for sending and not for receiving packets or using the senders NVUP (the
sending part) to determine the receiving permissions of the other peer.
4.3.3.4 Propagation of QoS transport sessions between ANs
Till here we have discussed the ways to establish a QoS transport session in the
AN of one of the end points. But this session, may also need to be setup in the other
end-point AN, if it is different. In the DiffServ based Core Network, there are no QoS
sessions and the only QoS descriptive factor to consider is the DSCP. To setup the
session in the other AN, the QoS session parameters must be transferred between the
two ANs. Those are the identification of the flow to be given QoS and the QoS needed
by the flow. Note again, that thanks to the AAA-QoS co-operation, the QoS system
does not need to deal with user related aspects and can focus just on packet’s
parameters. The parameters to consider will depend on the notion of flow used (e.g.
Source Address and DSCP or Source and Destination Address plus Flow Label and
DSCP). Several are the approaches and our design divides them in two categories:
•
In the other AN, the session setup process is repeated. Several cases are possible
here, corresponding to the different QoS session setup options:
o the setup is done by the other AN-MMSP
o The session setup explicit signalling between the two end points
configures the session in both ANs
o The session setup inband signalling between the two end points
configures the session in both ANs. This inband signalling must contain
the QoS this flow requires. And all this in the AN level of detail. The
DSCP and the 2 flow label bits conveying this data can be written by the
“sending” terminal. The QoS session setup in the sender’s AN will be
done when the flow traverses the AR, and in the other end-point, when it
enters the AN via its ER.
•
The session setup is propagated between the two ANs. The AN-QoSBroker in
the AN of the “initiator” endpoint configures the other end-point ANQoSBroker. This should not cause many problems in intra-domain scenarios, the
AN-QoSBrokers of the two ANs could communicate directly. But for interdomain situations, if the whole signalling between the two domains needs to be
routed through e.g. two “gateways” (the CN-QoSBrokers indeed) this may rise
scalability concerns.
Figure 37 and Figure 38 show a QoS enabled transport session setup by the
MMSP. In Figure 37 the AN-QoSBrokers propagate the QoS transport session between
- 124 -
the two ANs, while in Figure 38 the MMSP infrastructure setups the session in both
ANs.
MMSP
Internet
QoSB
MMSP
QoSB
QoSB
MMSP
Figure 37 MMSP driven transport QoS session setup. Setup is propagated by the ANQoSBrokers
MMSP
Internet
QoSB
MMSP
QoSB
QoSB
MMSP
Figure 38 MMSP driven transport QoS session setup. Setup is propagated by MMSPs
We stress that in our design, although the session parameters may be transferred
from AN to another, the two AN transport sessions will be kept independent and will be
aggregated into one single application level session. This will reduce the needed
signalling between the two AN-QoSBrokers as we will show in section 5.
- 125 -
A. Cuevas
Tesis Doctoral
4.3.3.5 Propagation of sessions and users’ profiles
We recall that section 3.3 analysed the management of user profiles, with
scenarios such as using the caller’s NVUP to define the parameters of the whole
communication. Here we will propose several ways to cope with these scenarios. If the
MMSP infrastructure creates the QoS session in both ANs, since the MMSP is able to
communicate between the different AN-MMSP the session and user profile parameters,
the problem of user profile transfer presented is solved. For instance, the MMSP can
decide that all the communication will be based on the caller’s user profile and
configure the AN-QoSBrokers with these parameters. Another approach is that the
session is propagated between the endpoints’ ANs by the AN-QoSBrokers. The “first”
AN-QoSBroker can dictate the parameters to the other AN-QoSBroker. These
parameters will be based on the profile of the user connected to the first AN. Finally, in
the scenarios where the MMSP is not employed and neither the AN-QoSBrokers
propagate the QoS session, the profile of the user in the first AN can not influence the
AN-QoSBroker in the other AN, and vice versa. In this case, the constraints mentioned
in section 3.3 will apply: either the user profiles specify restrictions only for sending
(and not for receiving) or the communicating peers have to negotiate the QoS transport
session in a way that the parameters followed in the transmission of one the peers match
the reception ones in the profile of the other peer.
4.3.3.6 Coexistence of the different solutions
The reader surely has noticed that there are many ways to achieve the same
goals. Some are more indicated in some scenarios, some in other. Besides, our
architecture aims to support them all. But this may raise coexistence problems. We will
see them next.
If we choose to propagate the (setup of) the QoS transport sessions via the ANQoSBrokers then no session should be setup in the other AN: neither the terminal
explicit signalling, the implicit signalling contained in the flows, or the MMSP should
try to establish a QoS session in the “other” AN. If this is done, this AN-QoSBroker
must be able to detect a “duplicated” QoS session setup: the one done locally and the
one transferred from the other AN-QoSBroker.
In MMSP mediated sessions, the MMSP must know when it should perform the
QoS reservation or when this QoS setup will be done by the terminal. For this a simple
solution is proposed: the terminal will include a flag in its session setup signalling
messages if it is willing to do the QoS reservation; if this flag is not present, the MMSP
will handle it.
Another problem to solve is what happens if the terminals decide to employ
different techniques for QoS transport session setup. For instance, one (let’s imagine it
is in AN1) can indicate the MMSP to setup the session while the other (located in AN2)
may be willing to setup the QoS session itself. This may correspond to a (transport)
QoS unaware terminal (and thus relying on the MMSP for QoS issues) trying to setup a
session with a terminal that can and wants to use RSVP to setup the QoS transport
session. A solution to this would be that the AN (AN1 or AN2) elements respond to the
RSVP signalling, faking the other terminal answer. These issues will be detailed in
section 5.
- 126 -
4.3.4 Co-ordination of transport and application session setup
To establish a session with QoS requirements, at least two services have to be
setup: the transport service and the actual application. This has implications such as the
order of the procedures that we will study in this section.
Respect to the order, the possibilities are, obviously, 3:
1. the QoS transport setup is done before the application setup. The problem of this
approach is that to setup the QoS transport session, results of the application level
negotiation are needed
2. the QoS transport setup is done after the application setup. This has implementation
related problems. Indeed there is not a protocol to embrace the setup of these two
sessions; normally the whole session is considered established once the application
level one is established. In that case the whole session may be considered setup
before the transport one has finished being setup. That poses problems such as what
happens if the QoS transport session fails to be established or what may occur if the
peers start to exchange data before the QoS transport session is established. Note
that, however, in scenarios with no explicit QoS transport session setup signalling
(neither by the peers nor by the proxy) the only possible way is to setup the QoS
session after the application session is setup. Indeed, the QoS session setup starts
when the peers start to exchange data.
3. Simultaneous and co-ordinated. Essentially that means that as soon as the
application level setup has negotiated all the needed parameters to establish a QoS
session, the QoS session will start to be setup. Besides, the application level setup
won’t finish until the QoS session is setup. This approach is the one followed by the
IMS (see the state of the art, section 2). This is what we will consider in our
discussion.
The IMS solution achieves to co-ordinate session setup at application and at
transport levels. For this, it follows the method described in [RFC3312]. However it has
two problems:
1. In standard SIP-SDP procedures just one offer/answer exchange (see the state of the
art, section 2) is enough for the peers to know each other capabilities and the
possible sets of the communication session parameters. But in IMS, to be able to
setup the QoS transport session, the peers need to know which is the chosen set of
communication parameters. So, if in the initial offer/answer exchange several
possibilities are announced, then there is the need of a second offer/answer
exchange.
2. The number of messages respect to a normal SIP session setup increases much
(roughly it is multiplied by two, depending on the options). Several factors
contribute to this: first the need of making provisional responses reliable. This is
because IMS profits of provisional responses to transfer offers or answers. Second,
the need of a second offer answer exchange, as we explained in the previous
paragraph and, third, the need for the peers to prevent each other when the QoS
session is setup.
- 127 -
A. Cuevas
Tesis Doctoral
This thesis proposes to add information in the session setup stating not only the
supported configurations but also associating to them a preference level. When the
callee receives a message stating the preference level and, after matching with its own
capabilities, it will be able to determine which should be the parameters to setup the
QoS transport session. When the caller receives the answer, it will also know the QoS
transport session parameters. This allows reducing to one exchange the offer/answers
between the peers. However, this does not decrease to total number of SIP messages,
since IMS profits the acknowledgement to convey SDP offer and answer data.
Nevertheless, this allows the peers or the MMSP to start the QoS transport setup one
offer/answer exchange before. The impact of this proposal will be quantitatively studied
in section 6.
4.4 Conclusions
This chapter has proposed the design of the 4G architecture where our session
setup solutions are developed. The role of each system and each node has been
identified and several design solutions have been presented and evaluated. The ways to
give coherence to the session split problem presented in chapter 3 have been suggested
and will be further detailed in chapter 5. The notion of session and the handling of user
profiles in the different systems and nodes have been studied. Since different scenarios
have to be supported in the same architecture, different proposals have to coexist and
some systems and nodes need to play different functionalities. The support of this
coexistence is one of the main benefits of our proposed 4G framework. Scalability
issues have been one of the main concerns and we have chosen to divide the network in
ANs (with one central CN). The ways to orchestrate the various systems and nodes have
been either proposed and evaluated or, when available (e.g. [RFC3775] for mobility),
used and analysed.
One of the main points to achieve scalability was, as we have just say, dividing
our architecture in ANs and one CN. Several works already split some systems
hierarchically, like the CSCFs in IMS. In our thesis we have matched and harmonised
this divisions creating a coherent hierarchical AN-CN structure. Besides we have
proposed ways to decentralise AAA (in concrete Accounting and Authorisation) and
integrated this division in our AN-CN structure.
Our proposed AAA-QoS interaction was a key point to allow richer interaction
scenarios and to allow several possibilities to coexist, such as AAA delivering parts of
user profiles or just authorisation decisions to VASPs. This proposal and its integration
into our 4G architecture is one step beyond the IMS possibilities. Its advantages have
been analyzed in this chapter. Also, pushing this forward, we have developed a scenario
where the AAA system is the only interface of the network operator to the VASP,
while, still QoS enabled transport service is given to them. The integration of Internet
like scenarios in our architecture has also been addressed. This is fundamental for 4G
networks where Internet model applications will be an important part of the services
consumed and demanded by the users. IMS just deals with IMS enabled scenarios.
The IMS PDF has been replaced in our architecture by a QoSBroker capable of
managing the QoS in an IP network. The AN-MMSP keeps the call and the transport
QoS sessions state and thus can better co-ordinate application and transport level
aspects of the session and cope with changing conditions (e.g. a handover to wireless
- 128 -
link with scarce BW) doing, for instance, content adaptation. These possibilities also
outperform IMS ones.
Also aspects such as coping with heterogeneity in QoS enabled transport session
setup have been tackled. For instance scenarios where one peer uses RSVP as QoS
session setup protocol and the other peer asks the AN-MMSP to setup the QoS session
have been addressed. Again this widens the applicability of our proposal. Also the
heterogeneity of the networks and, specifically, the management of QoS enabled
transport sessions traversing IntServ and DiffServ like networks have been studied
always bearing in mind scalability concerns. Several proposals were done to manage
and transfer those sessions between ANs, including stating the QoS needs of the packets
in the DSCP but also using the flow label. A way to match those needs to the user
profile has been proposed.
Finally a way to speed up the session setup process has been proposed consisting
on adding a preference level to the QoS configurations stated in the SDP offers and
answers. That way, terminals can know, with just one single offer/answer exchange, the
QoS transport parameters and start to reserve QoS resources. In IMS, usually two
exchanges are needed for this.
Next chapter will detail the signalling in the 4G framework here presented, thus
closing the design of our solution and of all the proposals made.
- 129 -
5. Signalling Design
The two previous chapters have shown the information to be exchanged to
establish a session in a 4G network identifying the roles of the different systems and
nodes. Several possibilities and several application scenarios have been presented. The
4G architecture was also designed and the different approaches evaluated. In this
chapter we reach the messages level (signalling). This is the final part of our solution to
integrate mechanisms of session setup in 4G networks.
As the readers see, we have devoted a whole chapter of this thesis to this aspect
of the session setup: the signalling. The reasons are several. First, the signalling is a
determining aspect at the time of evaluating two key factors of our proposal, the
scalability and the possible bottlenecks. Second, throughout this thesis the different
approaches and the design decisions taken have been analysed and evaluated. To
support this analysis chapter 6 will carry a simulation study. This simulation is centred
in signalling aspects that, therefore, require to be specially detailed, as it will be done in
this chapter. Those are the two reasons why we have considered advisable to dedicate a
whole chapter to the signalling.
5.1 Protocols and their ways to identify sessions.
This section will present the protocols used to communicate the different
modules between them. All of them are defined by the IETF and thus have the great
advantage of being standardised protocols, ready to be adopted by vendors. However
these protocols were not discussed in the state of the art; rather they are presented here.
Neither on this section nor in the others, detailed description of the protocols will be
given, the reader is referred to the appropriate reading if he is interested in those details.
We will focus on the proposed enhancements to the protocols and on the designed
interworking between them in our 4G framework. In this section, special attention will
be paid on the ways they have to identify sessions and subsessions.
5.1.1 SIP and SDP’s Session id. Cost sharing and preference level
SIP and SDP have a clear concept of session [RFC3261]: “A multimedia session
is a set of multimedia senders and receivers and the data streams flowing from senders
to receivers. A multimedia conference is an example of a multimedia session.” Also
they support multiparty sessions.
- 131 -
A. Cuevas
Tesis Doctoral
If SDP is used, a session is defined by the concatenation of the SDP user name,
session id, network type, address type, and address elements in the origin field.
SDP carries a list of possible media descriptions. To achieve the proposals of
section 4.3.4 we need to convey the preferences of the peers. For this, two solutions are
available: give a meaning to the order of these media description in the SDP message or
add an attribute inside the media description stating the preference. SDP supports BW
(b attribute) in the description of the whole session of for each media. If we consider
BW is the sole attribute billable for using the QoS enabled transport service, there is one
easy way to negotiate the cost sharing. We propose to include in each media description
the b attribute and define a new attribute stating the % of the cost of the BW the user is
whiling to pay. This media description will be accepted if the cost sharing satisfies the
answerer.
If we consider SDPng, for specifying the cost sharing we can add an attribute to
the TrafficInfo element in the RTP schema. To deal with the preference of the
configuration an extra element stating this preference can be added to the Capabilities
element (which is somehow equivalent to the media description attribute in SDP).
5.1.2 COPS and its “Handle”
The IETF RAP working group has defined the Common Open Policy Service
(COPS) protocol [RFC2748] as a mean to support policy control in an IP QoS based
network.
COPS is based on simple request and answer messages used to exchange
information about traffic policy between a policy server (PDP, Policy Decision Point)
and different kind of clients (PEPs, Policy Enforcement Points). COPS is purely clientserver and, to allow sending “unsolicited” messages to the clients, extensions were
defined in [RFC3084]. The PDP is the responsible for interpretation of the rules to be
implemented in the network, and enforced by the PEPs. At least one policy server must
be present in each administrative domain. A typical COPS framework is as set of
routers playing the role of PEPs and enforcing the decisions taken by the PDP, the
QoSBroker.
One of the main goals of the COPS protocol is to provide a simple but easily
extensible model. The protocol is extensible in the way that it is designed to allow the
use of auto-identificative objects and supports different kinds of clients specific
information, without making any modification over the protocol.
Thanks to this extensibility COPS can be broadened from the “routers plus
QoSBroker” scenario presented before: COPS can be used to implement the interactions
between many more network elements, for instance H.323 gatekeepers, SIP servers or
AAA servers. Indeed COPS was considered in [RFC3127] as a candidate protocol for
AAA communication. [ESC02] uses COPS for QoSBroker-H323 gatekeeper
communication and [SAR03] use it for SIP proxy-QoSBroker interworking. This thesis
follows this approach: besides using COPS for the routers and QoS Brokers interaction,
we will also use it for the MMSP (assimilated to SIP server) and QoSBroker
communication. The protocol for inter QoS Brokers communication will also be COPS.
Note that IMS uses COPS for the PDF (assimilated to the QoSBroker) and GGSN (like
an IP router) communication. In IMS, the protocol between the P-CSCF and the PDF
- 132 -
Signalling Design
(corresponding to the AN-MMSP and AN-QoSBroker) was not defined till very
recently [TS23209]; the protocol is based on Diameter.
COPS protocol has an object, the HANDLE, to identify sessions. The Handle
Object encapsulates a unique value that identifies an installed state. It is always initially
chosen by the PEP and then deleted by the PEP when no longer applicable. The Handle
is a variable-length field and has no implied format other than it is unique from other
client handles from the same PEP. The handle normally will identify configuration
states in the routers but these states are not directly related to sessions but to QoS
system internal procedures. We propose to use also the Handle to identify the QoS
sessions between the MMSP (or VASP) and the QoSBroker. In this case, the MMSP
will play the role of a PEP in the COPS defined operation, but, obviously, its
functionality is completely different of the one of a PEP.
As we will see, besides the QoS Session ID conveyed by the MMSP to the
QoSBroker in the HANDLE, the MMSP (or VASP) will also need to send the
QoSBroker a subsession (the application level session) ID. This will be done in a
COPS Object.
5.1.3 Diameter and SAML
The DIAMETER protocol [RFC3588] is defined for the transport of
Authentication, Authorization, and Accounting information between AAA clients, such
as Network Access Server (NAS), and AAA servers. The DIAMETER protocol is also
able to transport configuration information back to an AAA client after successful
authorization. Diameter was chosen among a set of other candidates protocols. The
reasons of this election can be found in [RFC3127].
The major DIAMETER features cover the following aspects:
•
sessions are set-up between the client and server. They are identified by a
globally unique session ID.
•
Any node can initiate a request. Thus, instead of being called client and servers,
Diameter nodes should all simply be called peers.
•
support of mobile systems and roaming
The DIAMETER architecture includes (1) a base protocol and (2) a set of
protocol extensions. The common functionality is implemented into the base protocol,
while application-specific functionality is provided by the extensions.
Network access service is supported by several Diameter Applications. The
DIAMETER Extensible Authentication Protocol (EAP) [RFC 4072] application
provides a standard mechanism for support of various authentication methods. This
application is used mainly for user and network authentication when trying to gain
access to the network. The DIAMETER NASREQ application [RFC4005] defines the
use of DIAMETER in the traditional PPP/SLIP dial-up environment. In addition a
DIAMETER Mobile IPv4 and mobile IPv6 applications [RFC4004], [LE04] provide the
ability for a DIAMETER server to authenticate, authorize, and collect accounting
information for services rendered to a mobile node, addressing service delivery of a
- 133 -
A. Cuevas
Tesis Doctoral
foreign provider. While Mobile IPv4 application is already standardised, Mobile IPv6
diameter application is still under discussion. This set of applications defines the
procedures to register a mobile terminal (or mobile node (MN) in the network.
A DIAMETER SIP application [GAR05] has been defined. It allows a
DIAMETER server to authenticate, authorize, and collect accounting information for
Session Initiation Protocol (SIP) services rendered to a client node. However this
application does not support the usage of SAML, so it should be adapted to fit into our
framework. Note that SAML usage for all the Diameter clients is a proposal of this
thesis that will be analysed in this section.
A DIAMETER credit control application [RFC4006] has been defined for
supporting real-time cost and credit control between a service element and a credit
control server in service environment. The architecture defined in this RFC is a pillar
for our AAA decentralization proposal; as we explained, the AN-AA plays the role,
among others, of a credit server and accounting data aggregator.
5.1.3.1 Diameter aggregation of sessions
Diameter protocol deals with two kinds of sessions: authorization and
accounting. Each is identified by a session ID that may be the same. This is useful if for
one service there is a match between authorization and accounting.
Besides the concept of session, diameter defines multisessions and subsessions.
Their actual meaning depends on the diameter application used. The multisession
identifier is used to correlate different sessions provided by different entities but still for
the same service. The immediate example is when the same network access session is
transferred from one NAS in an Access Router to another NAS in another Access
Router due to terminal handover. These two sessions will have different session
identifier but same multisession identifier. Concerning the sub-session identifier it is
used to identify a service (its session) provided to another service. The format of the
session identifiers is not fixed, so that it can adapt to the session identifiers used by
different applications like SIP-SDP.
These session identifiers will be the base for the AAA system to perform the
aggregation of sessions discussed along this thesis. In concrete it will allow the
combination of sessions in the AAA system presented in section 4.1.1. The idea, like in
the IMS, is to “exchange and share” the session identifiers between the systems
controlling the subsession providing a service. Then, these identifiers are provided to
the AAA system so that it correlates them. In IMS this is done for accounting and the
entity performing this correlation is the CCF (Charging Collection Function).
In our approach we use this correlation both for authorisation and for accounting
(unified non duplicated billing) issues. We consider several scenarios and sessions to
be correlated:
•
Internet model: NAS access session and the QoS enabled transport session
controlled by the QoSBroker
•
MMSP driven session: the same previous two sessions (access and transport
session) plus the application session controlled by the MMSP
- 134 -
Signalling Design
•
A third party Value Added Service Provider (with agreement with the operator)
controls the session: just like in the previous point but in this case the
application session is controlled by the VASP
IMS targets only the second case. IMS also considers VASP but they are
dependent on the MMSP (CSCF in IMS terminology). Next we will describe the
sessions IDs exchange in these scenarios. Our approach follows the natural
interworking ways between the elements. This interworking was studied in section
4.3.2.
The NAS will create a session ID, just upon user registration into the network.
This registration and the successful creation of the corresponding network access
session precede any other session. The AAA system is informed about the network
access session ID (NsID), and will ask all other AAA clients to include it, as a subsession in all their requests concerning this same user. These AAA clients are, as we
have seen, the AN-QoSBrokers, the MMSP and the third party application servers. As a
result any other session will be linked to the network access session. In Internet like
scenarios, this communication is the only needed to aggregate the two operator
meaningful sessions: the network access session and the QoS enabled transport session.
In scenarios where the MMSP or service provider contacts the QoS Broker, they
will exchange their respective session IDs and include them in the requests to the AAA
system. The order of AAA, MMSP and QoSBroker communication dictates this
exchange. As we proposed in section 4.3.2, the MMSP (or service provider) contacts
first the AAA system and then the QoSBroker. The MMSP or (VASP) will create an
application session id (AsID). In case of SIP based services this session will be the SDP
session identifier that, indeed, is created by the caller. The MMSP will inform of this
session to the AAA server using, as subsession ID, the NAS session. The MMSP (or
VASP) will create a QoS transport session with the QoSBroker, this session ID (TsID)
will be represented by a COPS handle object. The MMSP will also inform the
QoSBroker about its application session ID (AsID). When the QoSBroker contacts the
AAA it will use the MMSP application session ID (AsID) as subsession and the ID of
the QoS session created with the MMSP (TsID) as session. The NAS session ID could
also be included as a sub-sub-session ID but this is not necessary since the AAA system
can link, on one hand, the MMSP session with the NAS session and, on the other hand,
the MMSP session with the QoS enabled transport session, so the link between this QoS
session and the NAS session is immediate. It must be noted that the MMSP (or the
VASP) may create several transport sessions for only one application session. This
represents no problem, the result would be the QoS Broker informing the AAA system
of several QoS transport sessions, each with the same subsession id ; subsession id that
identifies the application session.
The Table 17 presents a summary of the previous discussion. We stress that our
session correlation scheme outperforms the IMS one in the sense it is adapted to 4G
networks (the network access session is created by a DIAMETER NAS and not by a 3G
PDP context) and allows supporting in an integrated 4G framework, besides the MMSP
scenarios, the Internet and VASP ones.
NAS
Client)
AAA
(AAA NAS session ID (NsID)
AAA
Use NsID as Sub-session ID (sent on AAA Clients (VASP, MMSP,
- 135 -
A. Cuevas
Tesis Doctoral
answers to clients requests)
Creates SIP session ID or any
application ID (AsID)
MMSP or VASP application session ID (AsID) (Use
terminal session ID or create new one)
NAS session id as subsession
MMSP or VASP Creates QoS transport session(s) TsID(s)
Use AsID as Sub-session
Terminal
Creates the QoS Session(s) TsID(s)
(in the “terminal
Use AsID as subsession
does de QoS
reservation case”)
Terminal
QoSBroker
TsID(s)
AsID
NsID
QoSB)
MMSP or VASP
AAA
QoSBroker
QoSBroker
May match the AsID (or TsID)
against the info sent by the
MMSP or by the VASP. If this
info was not sent, it may ask
the AAA about the AsID
AAA
Table 17 Session aggregation in the AAA server
One comment we have to do is that, since the AN-MMSP to AN-QoSBroker
uses COPS and not diameter, the “AsID” subsession must be conveyed in a new COPS
Object. The Transport Session(s) ID(s) are conveyed each in a handle object (each in a
new COPS message), the MMSP playing the role of a COPS client.
5.1.3.2 Distribution of user profiles and single sign-on: SAML
Diameter solves the problem of aggregation of sessions and thus of aspects like
unified non-duplicated billing. Since Diameter framework also centralises the
authentication and authorisation it can also provide single sing-on. Besides, as we
discussed in section 4.3.1, the model of distributing relevant parts of the user profile to
service providing entities and let those entities take themselves the authorization
decision, is another possibility worth to be supported. However these last aspects are
less explored. They are addressed individually by the different Diameter applications.
For instance in the Diameter SIP application [GAR05] the concept of nonce is used and
special AVPs for this application are defined. IMS, on its side, employs the concept of
user profile distribution to the CSCF and delegating the authorisation decision to it.
Several are the approaches to enable distributed authorization concepts and
single sign on. We propose to use the eXtensible Access Control Markup Language
XACML and its subset SAML (Security Assertions Markup Language). Both are XMLbased. Thanks to XML, SAML provides a common and flexible description framework
for the different applications servers interacting with the AAA, and thus not needing to
define a different Diameter application for each service. SAML is formed by two
“constructive blocks”: artifacts and assertions.
The artifact is used as the authentication credential of the user with any SAMLAAA client running in any service provider. Upon principal’s registration, the SAML
identity provider generates and delivers the artifact to the principal. The principal is a
user of the network operator which registers to the AAA system; the SAML identity can
be a module running in the CN-AAA server. Later, when the user wants to enjoy any
service, it will include the artifact within the service request to the service provider. The
service provider extracts the artifact, signs it with its private key and sends this token to
the AAA server-SAML identity provider. The SAML identity provider verifies the
- 136 -
Signalling Design
signatures, retrieves the relevant authentication assertion and sends it to the service
provider.
Assertions contain statements that service providers use to make access control
decisions. SAML provides three types of statements:
•
Authentication statements
•
Attribute statements
•
Authorization decision statements
Any combination of those three can be present in the assertion. The
Authentication statements assert to the service provider that the principal did indeed
authenticate with the identity provider (at registration time). The attribute statements
contain relevant parts of the user profile that the service provider will need to decide its
authorization. Those parts may include aspects from the SVUP and user’s remaining
credit. The authorization statements contain authorization decisions already taken by the
SAML identity provider (CN-AAA server).
The assertions have a time to live (TTL). If, before this time to live expires, the
user requests again a service and the assertion has all the data relevant for the service
provider to authorize this service, then the service provider does not need to contact
again the SAML identity provider (CN-AAA server).
This characteristic is fundamental to implement the proposal -presented in
section 4.2.3- of distributing the AAA architecture. Let’s recall that we suggest to
split the AAA server in two components: a CN-AAA server (namely the AAA server)
and several AN-Authorization and Accounting servers that alleviate some of the CNAAA server tasks. There is a chain of trust between the CN-AAA server and the ANAA servers and a delegation of some of the CN-AAA server functionalities into AN-AA
servers (except, perhaps, in roaming situations where the AN-AA server is in a foreign
domain). This delegation is achieved by sending the relevant assertions to the ANAA server. Then the AN-AA server can use these assertions to authorise the requests of
the AN-QoSBroker and the AN-MMSP. Note that our proposed AAA decentralisation
is also based in accounting consolidation and credit control done in the AN-AA and
then the final accounting and charging in the CN-AAA, as we have explained in
previous sections.
However the aspect that needs further study to be done in this thesis, is the
integration of the QoSBroker and its QoS enabled service in the SAML framework. As
we explained in this thesis the AAA QoS system interaction spares the QoS system of
handling any user related data. The QoS system just needs to look at some of the
packets parameters and ask, based exclusively on then, authorisation to the AAA
system. Those parameters could just be the packet’s source address (CoA or HoA). We
also recall that the AAA system warrantees the user-packets correspondence. The
importance of this approach is that it allows giving QoS to packets sent by completely
QoS unaware terminals, terminals that just sent packets to the network. And all this in
the Internet model, where no entity (MMSP or VASP) can setup a previous QoS
reservation with the QoS system. The QoSBroker acts like another AAA client.
However, if we want to integrate it also in the SAML framework, the authorization
- 137 -
A. Cuevas
Tesis Doctoral
request to the AAA can not just be based on packets parameters such as source address.
Instead, the QoSBroker has to provide the user’s artifact. The consequences of this
will be evaluated in future sections.
5.1.3.3 Diameter messages employed in this thesis
As a summary of the previous discussions, Table 18 gives a list of the Diameter
messages considered. This table will also help to understand the message sequence
charts presented latter in this chapter.
Message
Nodes involved
(Request
and
Answer)
ACR ACA
AN-MMSP, ANACounting R and QoSBroker,
A
VASPs
LIR LIA
CN-MMSP
Location Info R
and A
AAR AAA
NAS
Authentication
and Authorization
R and A
APR APA
AN-QoSBroker,
Authorise Profile AN-MMSP
R and A
User authentication Function
Comments
Important is to Accounting
identify
the sessions
session, not the
user
Not needed. use Location service.
NAI
NAI and password
SAML Artifact
ASR ASA
VASP
SAML Artifact
Authorise Service Needs to provide
R and A
the
service
description to the
AAA server
QAR QAA
AN-QoSBroker
IP Address
QoS
Authorisation R
and A
Delivers Network
Access
authorisation
Delivers
the
Artifact
Delivers part of
user profile (to
enable
taking
authorization
decisions)
Delivers
an
authorisation
decision
Design decision: to
which
entities
deliver user profile
and to which just
an
authorisation
decision
Delivers part of In case SAML
user profile (to model is not used
enable
taking for AN-QoSBroker
authorization
decisions)
Table 18 Diameter Messages
5.1.4 PANA and IPSEC
One last protocol relevant for this thesis is PANA (Protocols for carrying
Authentication for Network Access) [RFC4016], which is used between the terminal
and the NAS (that is located in the access routers). PANA is employed to request the
very particular service offered by the NAS: network access. EAP (Extensible
Authentication Protocol) will also by used (over PANA).
Note that the NAS will use EAP over DIAMETER following the diameter EAP
application [FOR04] to communicate with the AAA system.
PANA aims defining a protocol that allows clients to authenticate themselves to
the access network using IP protocols. PANA just operates between the terminal and the
- 138 -
Signalling Design
NAS, so it spares the terminal of understanding the particular AAA infrastructure
protocols (generally DIAMETER) that are in use at the site. It also allows such
interactions to take place without a link-layer specific mechanism. PANA is applicable
to both multi-access and point-to-point links. When PANA is used, network access
AAA can be completely independent of the specific Layer 2 technology. PANA can be
implemented and deployed as a UDP-based application, which makes it more adequate
than TCP for radio based access technologies with high bit error rates. It provides
support for various authentication methods, dynamic service provider selection, and
roaming clients.
PANA allows a device to authenticate itself with the network using EAP. The
flexibility of EAP to add new attributes (AVPs) is also a key point in this thesis since it
allows to add some information during registration. This information is needed by the
terminal for later processes. Among this information is the NVUP and the artifact. This
will be detailed in section 5.2.
At the end of the PANA authentication and registration process a security
association (SA) between the terminal and the NAS (running in the AR) is established.
This association is done at IP level using IPSec. The IPSec IKE key [RFC2409] is
generated by the NAS. IPSec serves to protect (by ciphering if needed) the potentially
unsecured access link between the AR and the terminal. This can be achieved
irrespectively of the actual layer 2 technology used in this access link. This SA is also
important for one key issue: to warrantee the user-packet correspondence which is a
major functionally of the NAS and the AAA system and that is one of the pillars of our
proposed AAA and QoS system interaction.
5.2 Terminal registration. SAML and “QoS registration”
Registration is the phase required prior to any service consumption including the
transport service offered by the network operator. Following the semi-walled garden
(section 3.2) and the SAML single sing-on techniques (section 5.1.3) it is enough for the
user to register with the network to enjoy any added value service (we consider “MMSP
applications” or services provided by 3rd party VASPs with agreements with the
network operator). We will deal in this section with registration with the network
operator.
The outcome of the registration with the network operator is that a security
association is created between the user, the operator, the terminal and the terminal’s
location in the network. Further, an artifact is delivered to the user, to identify it, later
on, with any service provider. The user-operator association is handled by the AAA
system, the user-terminal one by the MMSP (SIP) system, and the terminal’s location in
the network by MIP and the HA. However, with the MIPv6 Diameter application the
AAA system could also deal with the user-terminal and terminal-network location
bindings. The former will be followed and will spare the SIP register procedure. The
NAI [RFC2486] used in Diameter will stand for the SIP URI. This can easily be done
since their formats are very similar.
A relevant issue to be taken into account is that registering a user does not imply
consuming any resources, specially transport ones. For example, most of the times,
when a user powers on his handy, it is only to be reachable, which is just achieved by
registration mechanisms. The user may consume the resources much later than
- 139 -
A. Cuevas
Tesis Doctoral
registering. Besides, the registering mechanism itself, does not require that the user
employs directly the transport service. User’s PANA packets just have to reach the NAS
located in the network edge, the AR. Those packets do not need to be forwarded by the
AR. The NAS process those packets and interacts with the AAA server. Of course, the
packets sent by the AR do not need any authorization from the QoS System to flow into
the network.
Several extra processes after the AAA registration may be needed. Figure 39
shows the parts in which we divide the terminal registration.
<<actor >>
<<actor>>
<<ac tor >>
<<actor>>
<<ac tor>>
us 1_dom 1 : Term inal
A R_an1_dom 1 : A R
Q oS B _an1_dom 1 : A NQ oS B
M A P _an1_dom 1 : M A P
A A A _an1_dom1 : A NA A A
ref
ref
<<ac tor>>
A A A _dom 1 : CNA A A
<<ac tor>>
HA _dom 1 : HA
A A A Regis tration
If we us e S A M L m odel
for Q oS B and need to
provide it with us er's
NV UP A s s ertion
opt
ref
ref
Trans S ervReq
ref
ref
M IP Regis tration
M es s ages to M A P do not require Trans port S ervice authorization
Figure 39 Registration processes
One of the extra processes, is the MIPv6 “registration”. To do so, the network
needs to transport the MIP Binding Update to the HA. Note again, that the user
registration just warrantees his identity and the network access but does not entitle him
to consume any network resources. That means that the terminal must request the QoS
system authorization for sending the BU. However, the network service request can be
avoided. Note that the user is already authenticated and granted network access, so
avoiding the QoS system authorization will not pose many security concerns. The ways
to spare this request are:
•
Follow Diameter MIPv6 application and that the AAA server, when the user
registers, builds and sends the BU to the HA. We already explained why we
don’t follow this approach in this thesis.
•
We create a kind of “MIP agent” in the Access Router. The terminal will send
the BU to this entity, this entity “processes” the BU and sends it to the
terminal’s HA. As for the PANA case, the AR is not doing a “pure” forwarding
of the BU, the AR is just creating new BUs (with the same information) and
sending then. This, however, may suppose changes in the MIP protocol and will
add complexity to the AR.
•
The AR detects this kind of packets (BUs) and forwards them without
requesting any authorization to the QoSBroker. Several are the ways for the AR
to detect that packets are BUs:
o Inspect some fields of the packet like DSCP, to check for special codes
which indicate the AR to forward the packets without asking QoS Broker
authorization.
- 140 -
Signalling Design
o Check that the destination address is the one of the terminal’s HA.
Although this does not warrantee that the packet is a BU, at least it
assures that the packet is addressed to the HA and not to any other node.
The terminal’s HA or a list of all the possible HA (pertaining to the
domain or not) must be known by the AR.
o Check that the destination address is the one of the AN’s Mobile Anchor
Point (a sort of HA relay used in [RFC4140]). The advantage of this
approach is that the AR just needs to know the address of the MAP in
“its” AN. This is the approach followed, as shown in Figure 40.
: Terminal
: MAP
: HA
MIP::BU()
MIP::BU()
MIP::BACK()
MIP::BACK()
Figure 40 MIP registration
As we have said, after registering, the user will normally not consume any
resources, so there is no need in this moment of distributing authorization decisions or
users profiles (in the form of SAML assertions) to VASPs or any other entity. However,
we will do so, being this an added “feature” that takes part during user’s AAA
registration (Figure 41). This “push” of user’s profile has one advantage: when the user
will consume the service, the authorization process will be much faster since the
relevant entities will already have the information needed to perform the authorization
decision. However, the disadvantage is also clear: entities are forced to “waste”
resources, providing this information and storing it and, in most of the cases, they will
never use it, since the user may not be whiling to consume that service. So our decision
is to push this profile (SAML assertions) only to the AN-AA server. This is the way
to delegate to the AN-AA server the authorization decision to be given to the ANMMSP or the AN-QoSBroker. Pushing the user profile, perhaps, will not be done if the
user is roaming because the AN-AA server is not located in the home domain but in the
visited and privacy issues may arise. When the AN-MMSP or AN-QoSB need to get the
relevant assertion, they will contact the AN-AA server and this, if the assertion is not
expired, will send it, without “disturbing” the CN-AAA server. Note that the transfer
of the SAML assertions will be done in the AAA registration answer from the AAA
system, so no extra message will be needed. The assertions to be transferred must be
chosen correctly to minimize the amount of data transmitted.
- 141 -
A. Cuevas
Tesis Doctoral
<<actor>>
<<actor>>
<<actor>>
<<actor>>
us1_dom1 : Terminal
AR_an1_dom1 : AR
AAA_an1_dom1 : ANAAA
AAA_dom1 : CNAAA
PANA::BINDREQ("[email protected]", "MT_IP_Addr", "Pass")
DIAMETER::AAR("NAS_SessID", "MT_IP_Addr", "[email protected]", "Pass")
If we do explicit
service request
to QoS upon
registration
keep the
assertions
for future
delivery to
other entities
DIAMETER::AAR("", "", "", "")
DIAMETER::AAA("NAS_SessID", "Artifact", "Assertions")
DIAMETER::AAA("", "", "")
alt
If AN-AAA is not in home
domain we may only
transfer the NVUP assertion
PANA::BINDANS("Artifact","","NAS_SessID")
else
PANA::BINDANS("Artifact","NVUP_Asser","NAS_SessID")
Figure 41 AAA registration and assertion "push” to AN-AA
The service providers in the application garden contact a different AN-AA
server. So those VASP will get the assertion directly from the CN-AAA server. In this
scenario our approach is meaningless. However, the services offered by the MMSP and
the QoSBroker (and QoS transport service, respectively) will be the services most
demanded by users; the first for all user-to-user communications like voice calls or
SMSs. So the delegation of authorization decision, will still be meaningful in most of
the service scenarios.
There is one last issue to handle: providing the user’s artifact to the ANQoSBroker. Let’s focus on Internet scenarios where no other entity (MMSP, VASP)
informs the QoSBroker about the QoS to give to the user. In this case and following a
normal SAML operation, the user will provide the artifact to the AN-QoSBroker when
he is requesting it to consume transport service resources (i.e. sending packets to the
network). However, we have to support terminals without the capability of explicitly
signaling the QoSBroker of their willingness to consume resources. Receiving packets
from the network may also be considered as consuming network resources and, for the
QoSBroker to authorize this, it must have previously the user artifact. The solution
proposed is that just after the registration the user issues an explicit QoS request to the
QoSBroker sending it his artifact (Figure 42). With this artifact the QoSBroker will be
able to obtain, from the AN-AA, the NVUP, in form of a SAML assertion. This NVUP
assertion will also be send to the terminal so that it knows which are the NVUP
transport services available for the user. This NVUP is used by the terminal to mark
user’s packets (section 4.3.3.3). But, in the case of roaming, the transport services and,
specially, the DSCPs employed in the visited domain may be different. The NVUP
assertion is created and signed by the home AAA server’s SAML provider so this
assertion can not be altered by the visited domain to adapt it to the visited domain’s
definition of transport services. The solution is to define a set of well known transport
services universal to all the domains.
- 142 -
Signalling Design
: Terminal
: AR
: ANQoSB
: ANAAA
RSVP::Path("Artifact", "NASSessID", "","")
COPS::REQ("", "", "Artifact", "" , "NASSessID")
DIAMETER::APR("Artifact","TransSessID", "NASSessID")
The SubSession
NASSessID
can be left in blanck
DIAMETER::APA("NVUPAssertion", "NASSessID")
COPS::DEC("NVUPAssertion")
RSVP::Resv("","", "", "NVUPAssertion")
Figure 42 “Transport service” registration. Explicit QoS request
However, all this procedure can be spared if the QoSBroker behaves only just
like a standard AAA client without the SAML functionality. In this case, and taking
profit of the AAA-QoS interaction, the QoS Broker can ask the AN-AA for user
authorization and NVUP just based on the packets source and destination address and
without needing the user’s artifact. Moreover, this can be done just when the user
consumes network transport resources, not when the user registers.
5.3 Setup and propagation of transport sessions
We will describe in this section the ways to setup a QoS enabled transport
session and how this session is propagated between the ANs. This will help us to
understand the application session setup (described next) and how it is co-ordinated and
aggregated to this session. We have seen that there are two main ways to setup a QoS
session, either by explicit signalling (e.g. using RSVP) or using inband signalling. This
last method has several possibilities: e.g., including special DSCP codes to setup the
session or just stating QoS needs in the packet’s DSCP. We will first deal with explicit
signalling then with the inband signalling.
Figure 43 and Figure 44 show an explicit signalling scenario between two nodes
located in different ANs. The signalling is used to setup the “user1 sending to user 2”
QoS session. The symmetric signalling may need to take place to setup the reverse
session. The ANs considered can belong to the same domain or not. If they don’t and
AN-QoSBroker to AN-QoSBroker communication is needed, the messages will need to
go through the domains’ CN-QoSBrokers. For ease of reading we have split the
signalling in two parts, each focussing on one access network (AN).
- 143 -
A. Cuevas
Tesis Doctoral
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
us1_dom1 : Terminal
AR_an1_dom1 : AR
CR_an1_dom1 : ANIntServ
ER_an1_dom1 : ER
QoSB_an1_dom1 : ANQoSB
ER_an2_dom1 : ER
RSVP::Path("Artifact","ArtifactR","SubsessionID","QoSParam")
COPS::REQ("Flow Param", "QoSParam", "Artifact", "SessHandle1" , "SubsessionID")
COPS::DEC("QoSParam2&Flow ")
SubSessionID is an application
(VASP or MMSP) session.
For NAS sessions it can be leftf in
blanck. (Note: NAS session ID
is different in the 2 end points.)
SubSessionID, allong w ith the
QoSSession(s) handled by the
QoSSystem(s), is sent to the
AAASystem.
In NAS case, the AAASystem
w ill "find" the NAS session ID
and tell the QoSSystem to
use it for subsequent requests.
RSVP::Path("","","","QoSParam2")
RSVP::Path("","", "", "")
May create a specifc QoSSession
or use a existing one. The
QoSSessionID is sent to
the AAASystem allong w ith the
SubSessionID. The QoSSessionID
may be diferent or shared betw een
the ANQoSBs. This QoSSessionID
may even be chosed and shared
betw een the end-points
RSVP::Path("","", "", "")
COPS::REQ("Flow Param", "QoSParam2", "ArtifactR", "SessHandle2" , "SubsessionID")
RSVP::Resv("", "", "", "")
COPS::REQ("Flow Param", "QoSParam5", "Artifact", "SessHandle4" , "SubsessionID")
RSVP::Resv("","", "", "")
RSVP::Resv("", "", "", "")
RSVP::Resv("", "", "", "")
Figure 43 QoS session setup. Explicit request sent by terminal. 1st AN
- 144 -
Signalling Design
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
ER_an1_dom1 : ER
ER_an2_dom1 : ER
CR_an2_dom1 : ANIntServ
AR_an2_dom1 : AR
us2_dom1 : Terminal
May create a specifc QoSSession
or use a existing one. The
QoSSessionID is sent to
the AAASystem allong w ith the
SubSessionID. The QoSSessionID
may be diferent or shared betw een
the ANQoSBs. This QoSSessionID
may even be chosed and shared
betw een the end-points
RSVP::Path("","", "", "")
COPS::REQ("Flow Param", "QoSParam2", "ArtifactR", "SessHandle2" , "SubsessionID")
RSVP::Path("","","","QoSParam3")
RSVP::Path("","" ,"", "")
RSVP::Path("", "", "", "")
RSVP::Resv("Artifact", "ArtifactR", "SubsessionID", "QoSParam4")
COPS::REQ("Flow Param", "QoSParam4", "ArtifactR", "SessHandleID3" , "SubsessionID")
RSVP::Resv("","", "", "QoSParam5")
RSVP::Resv("", "", "", "")
RSVP::Resv("", "", "", "")
Figure 44 QoS session setup. Explicit request sent by terminal. 2nd AN
- 145 -
A. Cuevas
Tesis Doctoral
The signalling presented is very similar to the COPS+RSVP signalling already
discussed in the state of the art. However there is one difference: only the edge routers
(including ARs) issue signalling (COPS::REQ) to the AN-QoSBroker who will
configure (COPS::DEC messages) all the routers within its AN. When these routers
“see” any QoS signalling message (explicit or inband), since they are already
configured, they will not send out any request to the QoSBroker. The specific issues
related to this thesis and our proposals to face them are detailed next.
Firs thing to note is that in our design the only Session that is kept end-to-end
(e2e) is the application session (conveyed in the signalling as a subsession), negotiated
with a VASP or thanks to a MMSP. This application session will serve to correlate all
the QoS (QoSSessID1 and QoSSessID2 in the figures) sessions and other subsessions.
If there is no control of an application session (i.e. we are in the Internet model) no
correlation –in the AAA level- will occur and, for instance, both peers may pay for both
sending and receiving packets and, perhaps, with different tariffs.
We have also to point out that, since the 2 users artifacts are sent to the ANQoSBroker, this may use them to do queries to the AN-AA server. The artifact
exchange between the 2 end-points must be done by application specific signalling (e.g.
SIP) before doing the RSVP reservation. If artifacts are not present then the ANQoSBroker & AN-AA interaction can not follow the SAML model, IP address should
be employed as user identification as we have discussed all along this thesis. ANQoSBroker & AN-AA interaction is especially useful in the Internet model, where the
AN-QoSBroker can not match the QoS Session to any known and authorised session. In
this case the transport service stated in the user’s NVUP will be delivered. The
subsession in this scenario is not an application session but the NAS Session which is
different for the two end-points.
An important issue that we have discussed in section 4.3.3.6 is the coexistence
of different QoS technologies in the ANs and in the terminals. Several proposals were
made and the signalling is detailed here. Imagine the first user of Figure 43 and Figure
44 has RSVP capabilities but the second has not. Different approaches can be followed.
For instance, when the RSVP::Path message arrives to the 2nd AN ER, this ER issues a
COPS::REQ message. In case the AN-QoSBroker knows that the other terminal has no
RSVP functionality (the AN-QoSBroker gets the terminal capabilities from the ANAA) or that a QoS session has already been setup in its AN (e.g. by request of a ANMMSP) it can tell so to the 1st AN-QoSBroker, and do not let the ER propagate the
RSVP::Path message. The 1st AN-QoSBroker then may configure its AN and ask the
AR (or the ER) to originate an RSVP::Resv message to be sent to the 1st Terminal. Note
that this approach can be the default and sole option supported: i.e. no end to end RSVP
will be allowed, but we will have inter AN-QoSBroker communication. The RSVP
messages will be blocked and the RSVP answers generated by the local AN. Since the
QoS provision is not under our study, we will not discuss this issue further. We just
stress that we have proposed a way so that QoS enabled transport sessions can be setup
in different ways and coexist in our framework and even within a single application
session.
It must be noted, that the two AN-QoSBrokers may also interact to co-ordinate
the transport service e2e in the two ANs, but QoS provisioning mechanisms are out of
the scope of this thesis.
- 146 -
Signalling Design
So far we have discussed the case of explicit signalling. Let’s see now the case
of implicit inband signalling. We recall that by implicit signalling we refer to a
scenario where the terminal just sends packets (and expects QoS to be given to them)
without having previously done any negotiation with the QoS system, either directly or
by the means of a VASP or a MMSP. The signalling here is simple and can be directly
deduced from our discussion in section 4.2.1. When one AN Edge Router (including
ARs) sees a new flow, it sends a COPS::REQ message to the AN-QoSBroker. After
receiving this message, the QoSBroker will configure this router, (COPS::DEC
message) and may configure other routers in its AN (just like in the previous case). To
propagate the QoS session, the AN-QoSBroker may communicate with the other ANQoSBroker. The second option is that the session is “propagated” by the flow itself
(with the inband QoS info carried as discussed in section 4.3.3) and the process of
Figure 45 repeated in the second AN. As we already discussed, this second approach is
our proposed solution since it reduces inter AN-QoSBroker signalling.
: ER
: ANQoSB
: ANAAA
The SubSession
NASSessID
can be left in blanck
AN Edge
Router,
including AR
COPS::REQ("", "", "IPAddress", "" , "NASSessID")
When an
"unknown"
"flow" tries
to enter the
AN
opt
DIAMETER::QAR("TransSessID", "NASSessID","IPAddress")
DIAMETER::QAA("NVUPAssertion", "NASSessID")
COPS::DEC("QoSParam&Flow")
This is done only if the QoSB
has not the valid "assertion".
If this is the case (i.e.
"assertion" was not sent
during registration or by
a MMSP or a VASP)
the SAML model can not be
followed because we do not
have user artifact
Figure 45 Implicit QoS request and AAA-QoS interaction
The important fact here is that if the terminal has not done any “Transport
Service Registration” during its registration (section 5.2, Figure 42) the AN-QoSBroker
has not the assertion and neither it is sent the user’s artifact to get the assertion. This
implies that AN-QoSBroker has not the possibility to get authorization information
from the AN-AA. If we drop the SAML model for the AN-QoSBroker and AN-AA
interaction, the QoSBroker will be able to use AAA services just providing the IP
Address as a “user identifier” as we have discussed along this thesis.
5.4 Application and transport sessions, MMSP scenario
This section will present how the QoS and application sessions are co-ordinated
and created. It will emphasise in the interaction with AAA. For ease of reading, the
signalling has been divided in two parts, caller and callee, each one focussing on one
AN. We have assumed the users are in the same domain and non-roaming. For roaming
- 147 -
A. Cuevas
Tesis Doctoral
case, the SIP signalling path is just like in IMS (see section 2.2). We have assumed that
the AN-MMSPs do not have the assertions (or they have expired) but the AN-AAs do.
If AN-AAs do not have the assertion, they just forward the Requests and Answers
to/from the CN-AAA.
The most relevant steps followed (Figure 46 and Figure 47) are detailed next:
1. First the caller AN-MMSP checks user authorization, gets the assertion
(with this data it can adapt the SDP information) and creates in the ANAA an application session with session ID “AppSessID”.
2. The request to the callee’s home CN-AAA is like a request to a SIP
Registrar. The NAI-Terminal(s) IPAddress association is kept by the
AAA and this delivers the IP to the CN-MMSP which now can direct the
SIP invite to the proper AN-MMSP(s) and this/these to the Terminal(s).
3. When the terminal answers, the callee AN-MMSP interacts with the ANAAA just like the caller AN-MMSP did.
4. The Session Progress with SDP parameters is sent to caller.
5. Now the SDP QoS parameters to be used in the communication are
known. Several may the possibilities but the one with highest preference
is chosen. The AN-MMSP can ask the AN-QoSBroker to create a QoS
session associated to the Application Session. As we have discussed, two
possibilities arise: that the AN-QoSBroker actually creates the QoS
session (COPS::DEC messages) or that it waits for the terminals to create
it. The key point is that now the QoSBroker can associate its local
QoSSession to the global application session (AppSessID) and inform
the AN-AA about both of them so that the AN-AA can perform the
needed aggregation.
6. The QoSBroker does not need to ask the AN-AA for authorisation of the
QoSSession that the AN-MMSP wants to setup since the AN-MMSP is a
trusted entity. However the AN-QoSBroker tells the AN-AA to begin
accounting for the packets being sent by this session. The AN-AA can
aggregate this accounting at transport level with the accounting at
application level thanks to the common AppSessID. Any possible
charging scheme can be applied.
7. The Session Progress is received and the QoS setup is repeated in the
other AN. The QoSSession is different but not the Application Session.
8. Same procedure for the AN-QoSBroker - AN-AA interaction.
9. OK is received meaning the caller has completed its setup.
10. Finally, when the caller sends the ACK (actually that means that the
caller has finished his setup), the AN-MMSP tells the AN-AA to start the
accounting at application level
11. Idem for the callee AN-MMSP
- 148 -
Signalling Design
When the session is shut down, the aggregated accounting data is sent to the CNAAA that will be able to correlate the two NAS Sessions and the two QoS Sessions
with the unique Application Session.
In the case the terminal is in charge of doing the QoS reservation we have two
possibilities:
1. The AN-MMSP keeps informing the AN-QoSBroker of the session the
terminal will setup sending to both the terminal and the AN-QoSBroker the
Application Session ID (AppSessID) and/or the QoSSessionID .
2. The MMSP does not contact the AN-QoSBroker. In this case the ANQoSBroker, when receiving the QoS session setup request from the terminal,
must interact with the AN-AAA to authorise this session.
The question to solve is when the terminals start to setup the QoS session. They
can not do that before the AN-MMSP has informed either the AN-AA or the ANQoSBroker of the session to be setup. For the caller (Figure 46) that means receiving
the SIP::SP message (AN-AA has been contacted) or the SIP::OK (AN-AA and ANQoSBroker have been contacted). The callee (Figure 47) can only know that “his” ANMMSP has contacted the AN-QoSBroker and the AN-AA after the reception of the
SIP::ACK message. Since this may cause a too large delay, an extra message could be
sent from the AN-MMSP to the callee just to indicate him, that the AN-MMSP already
contacted the AN-AA and the AN-QoSBroker.
Finally, we could have the scenario where one terminal (let’s assume it is the
caller) setups the QoS session and the other delegates this task to its AN-MMSP. This
situation is solved following the procedures explained in section 5.3: the caller issues a
RSVP::Path message and when this message arrives to the callee’s AN, the ANQoSBrokers communicate and a RSVP::Resv message is generated by the caller’s AN.
- 149 -
A. Cuevas
Tesis Doctoral
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
us1_dom1 : Terminal
MMSP_an1_dom1 : ANMMSP
AAA_dom1 : CNAAA
MMSP_dom1 : CNMMSP
SIP::INVITE("Artifact1", "[email protected]", "IPAddr1", "SDPQoSPriceOrdA", "[email protected]", "AppSessID")
DIAMETER::APR("Artifact1", "AppSessID", "")
Could Even include
the NASSessID1
DIAMETER::APA("Assertion1", "NASSessID1")
SIP::INVITE("","","","","","")
DIAMETER::LIR("[email protected]")
DIAMETER::LIA("IPAddr2", "AN_MMSP")
SIP::SP("","","","","","","","")
SIP::SP("","","","","","","","")
COPS::REQ("FlowParam", "QoSParam", "Artifact1", "QoSSessID1" , "AppSessID")
COPS::DEC("")
DIAMETER::ACR("QoSSessID1", "AppSessID", "Start")
DIAMETER::ACA()
Sent to terminal
only after the COPS::DEC
has been received
Means session is setup
in caller side
SIP::OK("","","","","","","","")
SIP::OK("","","","","","","","")
Indeed it means, I'm
ready on my side you
can start ringing
SIP::ACK()
DIAMETER::ACR("AppSessID", "NASSessID1", "Start")
DIAMETER::ACA()
SIP::ACK()
Figure 46 Session setup. AAA, MMSP and QoS interworking. Caller side
- 150 -
Signalling Design
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
MMSP_dom1 : CNMMSP
MMSP_an2_dom1
us2_dom1 : Terminal
SIP::INVITE("","","","","","")
SIP::INVITE("","","","","","")
SIP::SP("Artifact1","Artifact2","[email protected]","[email protected]","IPAddr1","IPAddr2","SDPQoSPriceOrdB","AppSessID")
DIAMETER::APR("Artficat2", "AppSessID", "null")
DIAMETER::APA("Assertion", "NASSessID2")
Could Even include
the NASSessID2
SIP::SP("","","","","","","","")
SIP::OK("Artifact1","Artifact2","[email protected]","[email protected]","IPAddr1","IPAddr2","SDPQoSPriceOrdB","AppSessID")
COPS::REQ("FlowParam", "QoSParam", "Artifact2", "QoSSessID2" , "AppSessID")
COPS::DEC("")
DIAMETER::ACR("QoSSessID2", "AppSessID", "Start")
DIAMETER::ACA()
SIP::OK("","","","","","","","")
Forward this to MN
only after the COPS::DEC
has been received
Means: session is
setup in callee side
SIP::ACK()
DIAMETER::ACR("AppSessID", "NASSessID2", "Start")
DIAMETER::ACA()
SIP::ACK()
Figure 47 Session setup. AAA, MMSP and QoS interworking. Callee side
- 151 -
A. Cuevas
Tesis Doctoral
For readers’ comfort, the SIP signalling is very simplified, for instance the
(optional) ringing message has not been shown. To achieve co-ordination of the QoS
and application session setup, the signalling based on [RFC3312] and explained in
section 2.1.6 should be followed. In this framework and assuming a scenario where the
caller has to “pick-up the phone” in order to start the session the SIP::OK is just an SDP
update. The SIP::ACK message is also just an SDP update message, the actual
SIP::ACK message (and the corresponding DIAMETER::ACR messages to the ANAA) should be sent only after the caller has been adverted that the callee has “picked-up
the phone”.
The reader must note that the callee side starts the QoS reservation just after
sending the SDP answer (SIP::SP message) and the caller when he receives it. This is
achieved thanks to the proposal we made in section 4.3.4 stating that SDP should
convey the preference order of the suggested configurations. As we discussed, this
makes possible to start the QoS reservation in the first SDP offer/answer exchange and
thus quicker than IMS that needs a 2nd offer/answer exchange to begin the QoS session
setup.
5.5 Non-MMSP assisted scenarios: user and VASP
The main characteristic of the previous scenarios is that they were assisted by
the MMSP infrastructure which is able to setup QoS and AAA sessions in both (caller
and callee) ANs. In this section we consider that we don’t have MMSP support and that
one of the communicating end points is a VASP with an agreement with the network
operator, the other is a “normal” user. This originates an asymmetrical situation
because the VASP, in its AN (the “application garden”) can interact with the network
provider AN elements (AN-AA and AN-QoSBroker) in different conditions than the
user does with “its” AN elements. Figure 48 shows the signalling approach followed in
this scenario when the VASP does the QoS reservation. In this scenario the terminal
may completely be QoS unaware. Figure 49 tackles the case where the terminal does the
QoS reservation.
- 152 -
Signalling Design
: Terminal
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
AAA_dom1 : CNAAA
: VASP
SIP::INVITE("Artifact", "", "IPAddr", "SDP_QoSPrice_Ord", "", "AppSessID")
DIAMETER::ASR("Artifact", "AppSessID", "")
may include
NASSessID
DIAMETER::APR("Artifact", "AppSessID", "")
Depending on policies
the VASP may not even know
the transport QoS it can assing to
the user. Thus the AN-QoSB has
to ask the AAA about it
DIAMETER::APA("Assertion&yes", "NASSessionID")
DIAMETER::ASA("yes", "NASSessionID")
COPS::REQ("FlowParam", "AppQoSParam", "Artifact", "QoSSessID" , "AppSessID")
opt
May create a
different
QoSSessID.
AppSessID
is kept e2e
DIAMETER::APR("Artifact","QoSSessID", "AppSessID")
We assume the user is QoS
unaware and can't setup the
QoS session in his AN.
That's why we have
inter AN-QoSB
communication
DIAMETER::APR("","", "")
DIAMETER::APA("Assertion", "NASSessID")
DIAMETER::APA("", "")
COPS::REQ("FlowParam", "App&UserQoSParam", "Artifact", "QoSSessID" , "AppSessID")
DIAMETER::ACR("QoSSessID","AppSessID", "Start")
DIAMETER::ACR("QoSSessID2","AppSessID", "Start")
DIAMETER::ACR("", "", "")
DIAMETER::ACA()
COPS::DEC("QoS")
DIAMETER::ACA()
DIAMETER::ACA()
DIAMETER::ACA()
Perhaps wait for an ACK
from the other
AN-QoSBroker
beefore sending the DEC
SIP::OK("", "", "", "", "", "", "", "")
SIP::ACK()
DIAMETER::ACR("AppSessID", "NASSessID", "Start")
DIAMETER::ACA()
DIAMETER::ACA()
Figure 48 Session setup in a non-MMSP supported VASP scenario
- 153 -
A. Cuevas
Tesis Doctoral
: Terminal
<<actor>>
<<actor>>
<<actor>>
<<actor>>
<<actor>>
AAA_dom1 : CNAAA
: VASP
SIP::INVITE("Artifact", "", "IPAddr", "SDP_QoSPrice_Ord", "", "AppSessID")
DIAMETER::ASR("Artifact", "AppSessID", "")
DIAMETER::APR("Artifact", "AppSessID", "")
may include
NASSessID
DIAMETER::APA("Assertion&yes", "NASSessionID")
DIAMETER::ASA("yes", "NASSessionID")
SIP::OK("", "", "", "", "", "", "", "")
COPS::REQ("FlowParam", "AppQoSParam", "Artifact", "QoSSessID" , "AppSessID")
DIAMETER::APR("Artifact","QoSSessID", "AppSessID")
DIAMETER::APR("","","")
The Termianl QoS
session setup
should be done
using RSVP and
involving the AR.
This is a
simplification
If the VASP is
not able to setup
the QoS session
in its AN, then the
AN-QoSBrokers need
to communicate
DIAMETER::APA("QoSAssertion", "NASSessID")
DIAMETER::APA("","")
DIAMETER::ACR("QoSSessID2","AppSessID", "Start")
DIAMETER::ACA()
DIAMETER::ACA()
COPS::DEC("")
SIP::ACK()
DIAMETER::ACA()
DIAMETER::ACA()
Figure 49 Session setup in a non-MMSP supported VASP scenario. Terminal setting QoS sessions
- 154 -
A. Cuevas
Tesis Doctoral
The VASP uses the AAA infrastructure in its application garden to authorize the
user who is located in a different AN. The AN-AA located in the application garden has
not the assertions related to the user so it can act only as a proxy with the CN-AAA.
However, in the response from the CN-AAA to the AN-AA (DIAMETER::APA) some
of the assertions could be included so that the AN-AA can take authorisation decisions
in forthcoming AAA requests from other VASPs. Besides, as we discussed in section
4.3.1, we do not deliver the user profile (assertions) to the third party VASP, just an
authorization decision (DIAMETER::ASA).
In Figure 48, the AN-QoSBroker request of authorization services
(DIAMETER::APR) is needed when the VASP did not “completely” inform the ANQoSBroker about the QoS to be given to the application flows. This happens in the
following scenario:
1. The transport QoS delivered to the user does not depend on the user-VASP
and VASP- network provider contracts but on the user-network provider
contract and
2. The VASP has not been informed by the AAA system of the transport QoS
to be delivered to the user
This procedure takes also place in the case depicted in Figure 49.
Note that the QoS session setup in the application garden, is transferred to the
user AN (COPS::REQ between the two AN-QoSBrokers). In the user’s AN the ANQoSBroker will ask the AN-AA for accounting. The accounting session will be sent to
the CN-AAA. In the application garden the accounting information is also directly sent
to the CN-AAA. This is so because the same user is being accounted in two different
ANs and, to avoid so, we decided to forward all the accounting tasks to the CN-AAA.
Note that this is not the case in the “MMSP” scenarios where the caller AN accounts for
the caller and the callee’s AN accounts for the callee.
Here, as in the MMSP scenarios, the terminal can also do the QoS reservation
and we have the same possibilities: The VASP contacts or not the AN-QoSBroker. The
advantages of the different approaches were discussed in section 4.3.2. Figure 49 shows
the case where the VASP did not contact the AN-QoSBroker. We achieve one of the
proposals of the referred section: the AAA infrastructure as sole network provider
interface towards the VASPs. This also demonstrates the need of centralising the AAA
processing in the CN-AAA for the VASP scenario. The CN-AAA is the only aware of
the application and QoS transport sessions because those sessions were created in
different ANs (QoS Session in user’s AN, Application session in the VASP AN). Note
again that in the MMSP scenario, that was not the case: the AN-AA were aware of both
sessions. In Figure 49 we have assumed that the VASP can setup (e.g. using RSVP) a
QoS session in its AN, just like the terminal does in its AN. In such a case, the ANQoSBroker communication is not needed.
5.6 Conclusions
This chapter has closed the design of our solution. The signalling messages over
our proposed 4G architecture have been detailed focussing on the ways to support the
different possibilities presented in this thesis.
- 155 -
A. Cuevas
Tesis Doctoral
We concentrated on the methods the different protocols have to identify sessions
and users and proposed the way to profit from these features to accomplish our
solutions. We showed the information and the procedures to achieve aggregation of
sessions proposing which messages to exchange and when.
SAML model as a proposal to merge the different services representations and
reach a unified Value Added Service Provider - AAA system interaction has been
studied. The SAML chain of trust between CN-AAA and AN-AA has been presented as
a pillar to achieve our proposed delegation of Authorisation responsibilities to the ANAA.
A method to allow user and terminal registration without the need of requesting
transport service has been designed. We point that, normally, when a user registers into
the network it is just to be reachable not to immediately consume any service. That
shows the relevance of our proposal. However, if we use the SAML model also for
QoSBroker-AAA interaction, a transport service request is needed as a way to provide
the QoSBroker with the NVUP assertion. That was our proposed method to allow
implicit transport requests later on, again in the scenario where SAML is used by the
QoSBroker. The possibility of not using SAML for the QoSBroker was also presented.
The setup procedures for transport layer and co-ordination with application layer
and AAA in MMSP or VASP scenarios have been detailed. The application session is
kept end-to-end but neither the NAS nor the QoS enabled transport sessions are. This
design allows having different QoS session types in caller and callee networks. We also
presented the ways to cope with possible differences in QoS provisioning techniques in
the two endpoints networks. The methods to support this heterogeneity in a coherent
session setup framework have been proposed.
- 156 -
6. Validación
En los anteriores capítulos hemos propuesto, analizado y evaluado las distintas
opciones para lograr nuestros objetivos. Hemos considerado en ese estudio aspectos
como capacidades de los terminales (que puedan o no hacer reservas de QoS), intimidad
y gestión de perfiles de usuario, etc. En este capítulo nos vamos a centrar en profundizar
el análisis de las distintas propuestas, esta vez desde un punto de vista más cuantitativo
y, además, considerando la arquitectura en su conjunto y no sistemas aislados.
Atacaremos aspectos como escalabilidad, retardos, cuellos de botella, etc. Como las
redes 4G aún no son una realidad no disponemos de suficiente información para poder
caracterizarlas y dar valores representativos. Por lo tanto, nuestros resultados y
procedimientos, más que para caracterizar el funcionamiento de una red 4G, constituyen
una metodología que puede ser usada para planificación de redes 4G, por ejemplo
previendo dónde pueden surgir problemas o analizando el impacto de ciertas decisiones
de diseño.
Hay, esencialmente, tres formas de evaluar una arquitectura de red. La primera,
el desarrollar un modelo matemático que la represente y, a partir de él, estudiar
analíticamente las propiedades que queremos analizar. La segunda, es construir un
prototipo y, sobre ese prototipo, medir los parámetros que queremos evaluar. La tercera
consiste en usar métodos de simulación. La primera de las opciones puede ser
excesivamente complicada si lo que queremos es extraer resultados significativos del
sistema en su totalidad y éste es complejo, como lo es nuestra arquitectura. En la
segunda opción, la implementación es una tarea muy costosa y, además, limitada a
prototipos. En esos prototipos, por su reducida extensión, no se pueden evaluar
convenientemente aspectos como escalabilidad. Por lo tanto, una opción recomendable
es recurrir a los modelos de simulación. Estos modelos pueden ser lo suficientemente
representativos de la arquitectura diseñada y sobre ellos se pueden reproducir
situaciones que se den en escenarios reales cuando la arquitectura esté desplegada
comercialmente. Por lo tanto, esta será la opción elegida en esta tesis para la evaluación
de nuestra arquitectura.
6.1 Escenarios / Implementación
El modelo de simulación lo implementamos en la herramienta [NS2]. Ns2 es un
simulador de red orientado a objetos, basado en eventos discretos. Ns2 está codificado
en C++ y OTcl. Ns2 soporta numerosos protocolos y, al ser de código fuente abierto,
- 157 -
A. Cuevas
Tesis Doctoral
puede ser extendido fácilmente para satisfacer las necesidades del usuario. Ns2 se ha
convertido en el estándar de facto en simulación de redes dentro del ámbito académico.
De todas formas debemos mencionar que existen otras herramientas de
simulación de redes [OPNET] y que, en ciertos aspectos que necesitamos, ns2 no es
todo lo adecuado que debiera. Nos referimos, en concreto, a la simulación de tiempos de
procesamiento en los servidores [RAM03]. Si bien está función se puede lograr en ns2,
ns2 está más bien orientado a simulaciones de tráfico en redes, no a evaluar retardos de
proceso en los nodos. Hay simuladores [WAN02], basados o no en ns2, que sí se
centran en aspectos de tiempos de proceso pero son menos completos que ns2 y su
código fuente no es abierto y, por lo tanto, no se pueden extender a nuestras
necesidades. Nos reafirmamos, pues, en nuestra decisión de usar ns2.
En ns2, simulamos la arquitectura propuesta en esta tesis, en concreto los
terminales, servidores AN (MMSP, QoSBroker y AAA) y los servidores CN (MMSP,
AAA y QoSBroker, éste último sin ninguna funcionalidad). Los routers formando las
distintas redes son nodos normales de ns2, sin funcionalidad de QoS. Recalcamos que
nos centramos en aspectos de señalización no en la QoS ofrecida realmente por la red.
La señalización (SIP) entre los terminales y los MMSP está basada en [IPTEL] pero ha
sido ampliamente extendida por nosotros. La señalización entre los MMSP, QoSBroker,
AAA la implementamos nosotros. En el caso en que los terminales se encarguen de
realizar ellos la reserva de QoS (y no el AN-MMSP) esta reserva la hemos
implementado como un mensaje directo entre el terminal y el AN-QoSBroker, no
mediante las técnicas RSVP+COPS presentadas en esta tesis. Esta simplificación no
resta validez a nuestro análisis, como veremos más adelante al relatar las pruebas
realizadas.
La señalización implementada refleja fielmente la planteada en esta tesis para
establecer sesiones con soporte de la infraestructura MMSP. Se hicieron pequeñas
simplificaciones para facilitar el desarrollo. Primero, los nodos AN-MMSP contactan a
los AN-AA siempre al recibir el mensaje INVITE (y el ACK). La interacción ANMMSP con el AN-QoSBroker se realiza bien al recibir el mensaje “200 OK” o el
mensaje “183 Session Progress”, según se configure. Además, la señalización entre el
AN-QoSBroker y el AN-AA no está implementada. Por último, se añadió una
interacción entre el CN-AAA y el CN-MMSP hogar del llamante. Esto se hizo por
simetría con la interacción entre los mismos nodos del llamado (mensajes LIR y LIA en
nuestro diseño). Los contenidos de los mensajes de señalización intercambiados eran los
imprescindibles para logar la correcta secuencia de intercambio de mensajes. Además se
implementó el registro AAA, con la finalidad que le CN-MMSP pueda contactar con el
CN-AAA y preguntarlo por la localización del usuario.
La función indicada para implementar retardos en ns2 es el “scheduler” y es lo
que hemos usado. El modelo de retardo que hemos seguido es sencillo: antes de enviar
un mensaje, se le somete a éste a un retardo de procesamiento que es constante y
configurable para cada nodo (AN o CN). Además, realizamos una cola “FIFO” y no se
empezará a procesar ese mensaje hasta que los demás no hayan salido.
Desafortunadamente los trabajos sobre evaluación de prestaciones de elementos de red
4G son escasos [CUE05]. Esto es normal ya que éstos no están ni siquiera en fase de
desarrollo, sólo de estudio. Tampoco son muy abundantes los estudios sobre
prestaciones de servidores SIP [JAN03]. Como mucho, los estudios dan valores sobre
los retardos de procesamiento, pero no sobre su comportamiento frente, por ejemplo, a
- 158 -
Validación
picos de carga. Tampoco hay disponibles simulaciones de arquitecturas mezclando SIP
y, por ejemplo, AAA y QoS. [SAL02] se centra en el coste de procesar en nodos SIP
aspectos relacionados con autenticación, como generación de claves IPSec. [CAM03]
compara las prestaciones de SIP sobre UDP, TCP o SCTP. Ante la falta de estudios
disponibles, debemos nosotros mismos razonar el posible modelo de retardo de
procesamiento que pueden tener los nodos. Si tenemos en cuenta que, en una
implementación real, los distintos mensajes a procesar se pueden almacenar en una tabla
indexada por “hash”, que esa tabla se almacena entera en memoria RAM (no se usa
memoria virtual) y que el mayor costo al procesar un protocolo basado en texto (por
ejemplo SIP) es manejar las cadenas de caracteres, podemos decir que el retardo de
procesamiento será constante y no variará en función de la carga del servidor. Este
retardo constante es lo que asumiremos para los servidores del AN y el CN. En los
terminales no hemos incluido ningún retardo de procesamiento, simplificación que se
sustenta en el hecho de constatar que los terminales manejarán un nº de mensajes mucho
más pequeño que los servidores AN o CN.
Ns2 suministra los resultados en archivos de trazas (.tr) con un formato
conocido. Esos archivos se analizan extrayendo los resultados pertinentes.
Desarrollamos 6 programas para realizar este análisis, cada uno centrado en uno de los
siguientes aspectos:
•
tiempo total en establecer una llamada,
•
tiempo en enviar una respuesta a una petición (para los AN-AA, ANQoSB y CN-AAA) y
•
tiempo en reenviar un mensaje SIP al terminal o al CN-MMSP y esto
para los nodos AN-MMSP y CN-MMSP. Por ejemplo cuando un ANMMSP recibe un mensaje INVITE de un CN-MMSP, el tiempo que tarda
en enviarlo al llamado. Debemos decir que esos tiempos incluyen el
tiempo que tardan en hacerse las peticiones a otros nodos. Pongamos otro
ejemplo, cuando a un AN-MMSP le llega de un CN-MMSP un mensaje
“200 OK”, el tiempo que el AN-MMSP tarda en reenviarlo al terminal
llamado incluye el tiempo que tardó el AN-MMSP en hacer la petición
de recursos al AN-QoSBroker
Estos tiempos nos permiten medir los principales parámetros considerados para
evaluar sistemas de telefonía sobre IP como son llamadas por segundo o transacciones
por segundo [JAN03] [SCU02].
El escenario simulado consiste en 4 dominios diferenciados. Así podemos
simular todos los casos en el que el llamante o el llamado están en su red hogar o no
(Table 19).
Llamado
Llamante
Red Hogar (Red 1)
Hogar X
Red
(Red 3)
Red Visitada
(Red 4)
X
Red Visitada (Red 2)
X
X
Table 19 Casos de llamada en función de la situación.
- 159 -
A. Cuevas
Tesis Doctoral
Con 4 dominios cubrimos todos los casos de comunicación entre usuarios de
distintos dominios y situados en diferentes dominios. Pero el número de posibilidades es
muy grande, 256: el llamante puede pertenecer a 4 dominios y estar situado en otros 4,
tenemos 4*4=16 posibilidades (incluyendo los 4 casos en los que el dominio hogar es el
mismo que el dominio visitado). Idéntico razonamiento se puede hacer para el nodo
llamado, lo que nos da un total de 16*16=256 posibilidades.
Por lo tanto, debemos reducir nuestro número de casos. La primera
simplificación es considerar no los 4 dominios individualmente sino sólo mirar si el
dominio (visitado u hogar) del llamante y del llamado son el mismo o no. Esto nos da 4
casos. Además, en cada uno de esos 4 casos, la situación del llamado o del llamante
puede ser de roaming o no. Es decir, tal como muestra la Table 20 tenemos 16 casos a
considerar.
Dominio llamante o llamado Igual o Distinto Situación
del
llamante
(Roaming o No Roaming)
Dominio Hogar
Dominio Visitado
I
I
R-NR
I
D
R-NR
D
I
R-NR
D
D
R-NR
Situación del llamado
(Roaming o No Roaming)
R-NR
R-NR
R-NR
R-NR
Table 20 Simplificación de los casos de simulación
Aún así, para los aspectos de señalización lo que nos interesa es cuantos CNMMSP involucra una llamada. El número de CN-MMPSs puede variar desde 1 (mismo
dominio visitado y hogar para el llamante y el llamado y ninguno está en roaming) hasta
4 (distinto dominio visitado y hogar y ambos están en roaming). Podemos tener dos CNMMSP, por ejemplo, para usuarios en su red hogar pero pertenecientes a distintos
dominios o tres para usuarios de distintos dominios y situados en un mismo tercer
dominio visitado. Debemos notar que este fenómeno sólo se da para los CN-MMSPs.
Cualquier otro tipo de nodo participa en una llamada, siempre de forma “doble”, es
decir, uno en el lado del llamante y otro en el lado del llamado. Hagamos unas
puntualizaciones: si llamado y llamante están en el mismo dominio y este también es su
dominio hogar, sólo participará un CN-AAA, pero gestionará el doble de mensajes
(Autenticación del llamante y localización del llamado). Si los dos interlocutores están
en el mismo AN, sólo se involucrará a un AN-MMSP, un AN-QoSBroker y un AN-AA
pero estos también manejarán el doble de mensajes.
Hicimos una última simplificación, esta vez motivada sólo por razones de
facilidad de implementación y es sólo considerar los casos en el que 1,2 o 3 CN-MMSP
se ven involucrados en el establecimiento de sesión. Finalmente, los casos que se dan en
nuestro escenario están reflejados en la Table 21. Todos ellos, por cómo diseñaremos
nuestro escenario, se darán en igual número en la simulación.
Dominio llamante o llamado Igual o Situación
del Situación
del Número de CNDistinto
llamante (Roaming llamado (Roaming o MMSP
o No Roaming)
No Roaming)
involucrados en una
llamada
Dominio Hogar Dominio Visitado
D
D
NR
NR
2
I
I
NR
NR
1
D
D
R
R
3
- 160 -
Validación
visitado llamante = hogar llamado
D
I
R
NR
2
Table 21 Casos simulados en nuestro escenario
Los 4 dominios tienen la misma estructura. Están conectados mediante tres
routers, que forman lo que llamamos la Internet. Cada dominio está formado por 1 CN
y 8 AN. Los CN son idénticos entre sí, y los AN también. La Figure 50 representa los
“bloques” seguidos para construir nuestro escenario.
MN
From an
ER in a AN
AR
MN
AR
A4C
QoSB
MN
MMSP
MN
AR
CR
MN
AR
ER
To
an
ER
From an
In ER in a AN
a CN
From an
ER in a AN
From an
ER in a AN
MN
MN
From an
ER in a AN
From an
ER in a AN
CR
MN
ER
CR
From an
ER in a CN
ER
QoSB
MMSP
ER
From an
ER in a CN
Internet
Internet
From an
ER in a CN
From an
ER in a CN
ER
From an
ER in a AN
From an
ER in a AN
A4C
To
Internet
Internet
CR
ER
Figure 50 Escenario de simulación. Un AN (izquierda), un CN y la “Internet” (derecha)
El lector apreciará que nuestro escenario sigue fielmente la arquitectura de red
planteada en la tesis: cada dominio está compuesto por un CN y varios AN. Los límites
de los AN o CN son los routers de borde (Edge Routers –ER-). Si estos ER conectan al
AN con los terminales (o nodos móviles, “Mobile Node” –MN-) se llaman AR.
Recalcamos que los routers, en nuestro escenario, son routers normales de ns2, todos
con las mismas funcionalidades y sin capacidades de QoS. De nuevo puntualizamos que
no nos centramos en aspectos de QoS sino en señalización. La ventaja de delimitar cada
red por un ER es que así podemos medir mejor en el simulador el tráfico intercambiado
entre esa red y las demás. Si consideramos un CN, ese tráfico será el tráfico
interdomimio.
En nuestro escenario, la mitad de los terminales ejerce de llamante y la otra
mitad de llamado. Además llamantes y llamados se reparten de forma equilibrada en
todo el escenario. Si unimos a esto la arquitectura de red, donde cada AN es idéntico a
los demás y lo mismo los CNs y los dominios, podemos decir que el comportamiento de
un AN, será igual que el de los otros ANs e igualmente con los CNs. Esto nos permitirá
estudiar, por ejemplo, un solo AN-QoSBroker de todos los del escenario ya que el resto
tendrá un comportamiento similar.
Este comportamiento simétrico nos permite deducir, para una llamada, el nº de
mensajes que deberá procesar cada nodo. La Figure 51 ilustra el proceso de cálculo.
Hay que considerar el número total de CNs (4) y de CN-MMSPs y CN-AAAs y el
número total de ANs (32=8ANs/CN*4CN) y de AN-MMSPs, AN-QoSBs y AN-AA
Consideramos también que los nodos, para una misma llamada, participan tanto en el
“lado” del llamante como del llamado.
- 161 -
A. Cuevas
Tesis Doctoral
8MNs/AN 8ANs/CN => 64MNs/CN
4 CNs=> 256MNs
CN-AAA
AN-AA
AP in
callee,
LI in
caller
AP
and
AC
INV
INV
AN-MMSP
ACK
REQ-DEC
AN-QoSB
CN-MMSP
ACK
ACK
RPT
INV
INV
OK and SP
ACK
AN-QoSB may receive these
messages from MN or ANMMSP. In this case, for ANMMSP processing time we
have considered they are sent
by the terminal
Figure 51 Cálculo del tiempo de procesamiento en cada nodo
Los mensajes gestionados por el CN-MMSP merecen un comentario más
extenso. Como hemos dicho, el número de mensajes que gestione un CN-MMSP
dependerá de la situación de los interlocutores (situados en la red hogar o visitada, etc.).
La Table 21 muestra los casos considerados en estas pruebas. En el caso en el que los
dos nodos están en su red hogar y ésta es la misma para ambos, el CN-MMSP
involucrado gestionará 4 mensajes SIP, por ejemplo para el invite el reenviarlo desde el
AN-MMSP del llamado al AN-MMSP del llamante (estos AN-MMSP pueden ser los
mismos). Ilustremos ahora el caso en el que el los terminales están en su red hogar pero
esta es distinta. El AN-MMSP del llamante envía el mensaje INVITE al CN-MMSP
quien lo reenvía al CN-MMSP del llamado y este al 2º AN-MMSP. Podemos seguir un
razonamiento análogo con los otros mensajes SIP. En este caso, una llamada involucra a
2 CN-MMSP. Si consideramos dos nodos, en el mismo dominio pero uno de ellos (el
llamante) está en “roaming” el camino de los mensajes SIP (INVITE y ACK) es el
siguiente:
AN-MMSPCN-MMSPvisitadoCN-MMSPhogarCN-MMSPvisitadoAN-MMSP
Es decir, sólo hay dos CN-MMSP involucrados, pero el CN-MMSP visitado
debe procesar los mensajes por duplicado. Por último, cuando los dos terminales están
en roaming, son de dominios distintos y están en dominios visitados distintos pero el
dominio visitado del llamante es el dominio hogar del llamado, el camino de los
mensajes es el siguiente:
AN-MMSPCN-MMSP1(visited)CN-MMSP2(home)CN-MMSP1(home)CN-MMSP3(visited)AN-MMSP
Es decir 3 CN-MMSP están involucrados pero uno debe gestionar los mensajes
2 veces. Está discusión será retomada en la sección 6.2. La Table 22, basada en la Table
21, resume estos resultados, teniendo en cuanta que las 4 situaciones se dan en igual
número en nuestro escenario.
Dominio llamante o llamado Igual o Situación del Situación del Número de CN- Mensajes SIP
Distinto
llamante
llamado
MMSP
procesados
- 162 -
Validación
D
D
I
I
D
D
D
I
NR
NR
R
NR
NR
R
2
1
3
2*4
1*4
4*4
R
NR
2
Total
promediado
3*4
(2,5=10/4)*4
Table 22 Mensajes procesados por un CN-MMSP en los distintos escenarios
Por último, comentar que, si bien el número de CNs es perfectamente válido (ya
hemos explicado que permite todas las combinaciones de llamadas) y el de ANs es
adecuado, el número de terminales es bastante bajo. Esto no es más que por cuestiones
de capacidad de cálculo. En ns2 (y en general en cualquier simulador de red) el tiempo
de la simulación aumenta, más que con el número de mensajes, con el número de nodos
a considerar. No podemos, por lo tanto, incrementar mucho en número de terminales en
el escenario. Para simular escenarios con un número importante de llamadas (periodos
de saturación, etc.) lo que haremos es que cada llamante repita, tantas veces como sea
necesario, la llamada aumentando así el número de llamadas en el escenario.
6.2 Validación del simulador
Como es lógico, antes de poder usar nuestro modelo de simulación y las
herramientas empleadas para analizar los resultados, tuvimos que realizar una serie de
pruebas para asegurarnos la ausencia de errores. Como hemos elaborado un modelo de
simulación muy completo, las pruebas a realizar son innumerables y, como en la
mayoría de las ocasiones, un análisis del 100% de los casos no es abordable. Los casos
más significativos se analizaron exhaustivamente. En esta sección presentaremos los
resultados y pruebas más representativos.
6.2.1 Pruebas “individuales”
El primer paso es probar que la señalización entre los nodos es correcta. Ns2, a
parte de presentar resultados en un archivo, viene acompañado de una herramienta
gráfica, nam, que permite visualizar los mensajes intercambiados entre los nodos.
Usaremos esa herramienta para comprobar el correcto diagrama de intercambio de
mensajes. Pero en un escenario tan amplio como el descrito, la visualización de los
mensajes no es posible, es por lo tanto que, para estas pruebas, realizamos otro
escenario mucho más reducido y fácil de representar. Ese escenario también tiene 4
dominios cada uno con un CN y uno o varios ANs. El escenario, completo, está
representado en la Figure 52.
- 163 -
A. Cuevas
Tesis Doctoral
DOMAIN AVEIRO.PT
1 CN 2 ANs
DOMAIN MADRID.ES DOMAIN PARIS.FR DOMAIN STUTTGART.DE
1 CN 1 AN
1 CN 1 AN
1 CN 1 AN
Figure 52 escenario ns2 para pruebas de validación
Sobre este escenario se probó, satisfactoriamente, el intercambio de mensajes
para todos las variantes posibles, llamadas intra e inter dominio, con llamante y/o
llamado en red visitada u hogar, cuando los interlocutores están en la misma AN, o en
distintas ANs dentro de un mismo dominio, etc. Evidentemente, las pruebas no pudieron
ser exhaustivas, ya que cómo hemos visto existen 256 posibilidades referentes sólo al
dominio hogar y visitado del llamante y del llamado. Si bien no probamos todos esos
casos, probamos, como hemos dicho todas las posibilidades, e.g. que el dominio
visitado del llamante fuera el dominio hogar del llamado, etc.
Una vez comprobada la señalización restaba comprobar si el escenario de
pruebas estaba creado sin errores y si nuestras herramientas de análisis eran correctas.
Para ello, en el escenario de pruebas generamos un número muy limitado de llamadas,
cubriendo distintos casos, tal como hicimos en los anteriores experimentos. Hicimos
nuestras pruebas comprobando y cotejando tres fuentes: los mensajes impresos por
pantalla de nuestro código, las trazas generadas por ns2 y los análisis arrojados por
nuestras herramientas de análisis de trazas. Nuestro código (si así se configura)
imprime, en los terminales y servidores AN y CN, un mensaje a cada vez que el nodo
recibe una trama. Los terminales imprimen, además, el estado del proceso de
establecimiento de llamada. Estos mensajes se confrontan con los mensajes aparecidos
en las trazas. Para ello, estudiamos esas trazas y, además, así comprobamos que nuestras
herramientas las interpretan bien. En las Figure 53, Figure 54 y Figure 55 presentamos
algunos resultados para una llamada hecha entre dos nodos del mismo dominio –
denominado “0”- y situados en ese mismo dominio. El lector debe entender el formato
básico de las trazas ns2, que puede consultar en [NS2]. En esas trazas, se presenta los
nodos entre los que circula el mensaje y las direcciones origen y destino del mismo. El
- 164 -
Validación
símbolo “+” representa el momento en el que el mensaje se envía, el “r” en el que se
recibe.
********************************************************
*************STARTING CALL SET UP********************
****** *******FROM [email protected] TO [email protected] ***********************
********************************************************
**************************************************************
STARTING SIP INVITE TRANSITION FROM [email protected] TO [email protected]
**************************************************************
AN_MMSPP(node:15): received SIP_MSG_INVITE(transition SIP_INVITE) from MN(node 20, [email protected])
AN_A4C(node:14): received AAA_AUTH_QUERY(transition SIP_INVITE) from AN_MMSPP(node 15)
AN_MMSPP(node:15): received AAA_AUTH_REPLY(transition SIP_INVITE) from A4C(node 14)
CN_MMSPP(node:5): received SIP_MSG_INVITE(transition SIP_INVITE) from AN_MMSPP(node 15)
CN_A4C(node 4):received AAA_AUTH _QUERY(transition SIP_INVITE) from CN_MMSPP(node 5)
CN_MMSPP(node:5): received AAA_AUTH_REPLY(transition SIP_INVITE) from CN_AAA(node 4)
CN_A4C(node 4):received AAA_LOCATION_QUERY(transition SIP_INVITE) from CN_MMSPP(node 5)
CN_MMSPP(node:5): received AAA_LOCATION_REPLY(transition SIP_INVITE) from CN_AAA(node 4)
AN_MMSPP(node:33): received SIP_MSG_INVITE(transition SIP_INVITE) from CN_MMSPP(node 5)
AN_A4C(node:32): received AAA_AUTH_QUERY(transition SIP_INVITE) from AN_MMSPP(node 33)
AN_MMSPP(node:33): received AAA_AUTH_REPLY(transition SIP_INVITE) from A4C(node 32)
MN(node 38,[email protected]): received SIP_MSG_INVITE(transition SIP_INVITE) from AN_MMSPP(node 33 )
**************************************************************
STARTING 200oK TRANSITION FROM [email protected] TO [email protected]
**************************************************************
AN_MMSPP(node:33): received SIP_RSP_SUCCESS(transition 200oK) from MN(node 38, [email protected])
AN_MMSPP(node:33): received SIP_SESSION_PROGRESS(transition 200oK) from MN(node 38, [email protected])
AN_QoSB(node 31): received AN_QOSB_RESV_QUERY(transition 200ok) from AN_MMSPP(node 33)
CN_MMSPP(node:5): received SIP_SESSION_PROGRESS(transition 200oK) from AN_MMSPP(node 33)
AN_MMSPP(node:15): received SIP_SESSION_PROGRESS(transition 200oK) from CN_MMSPP(node 5)
MN(node 20,[email protected]): received SIP_SESSION_PROGRESS(transition 200_oK) from AN_MMSPP(node 15 )
AN_MMSPP(node:33): received AN_QOSB_RESV_REPLY(transition 200oK) from AN_QoSB(node 31)
CN_MMSPP(node:5): received SIP_RSP_SUCCESS(transition 200oK) from AN_MMSPP(node 33)
AN_MMSPP(node:15): received SIP_RSP_SUCCESS(transition 200oK) from CN_MMSPP(node 5)
AN_QoSB(node 13): received AN_QOSB_RESV_QUERY(transition 200ok) from AN_MMSPP(node 15)
AN_MMSPP(node:15): received AN_QOSB_RESV_REPLY(transition 200oK) from AN_QoSB(node 13)
MN(node 20,[email protected]): received SIP_RSP_SUCCESS(transition 200oK) from AN_MMSPP(node 15 )
*****************MMSP QoS************************************
STARTING ACK TRANSITION FROM [email protected] TO [email protected]
**************************************************************
AN_MMSPP(node:15): received SIP_MSG_ACK(transition ACK) from MN(node 20, [email protected])
AN_A4C(node:14): received AAA_AUTH_QUERY(transition ACK) from AN_MMSPP(node 15)
AN_MMSPP(node:15): received AAA_AUTH_REPLY(transition ACK) from A4C(node 14)
CN_MMSPP(node:5): received SIP_MSG_ACK(transition ACK) from AN_MMSPP(node 15)
AN_QoSB(node:13): received AN_QOSB_REPORT (transition ACK) from AN_MMSPP(node 15)
AN_MMSPP(node:33): received SIP_MSG_ACK(transition ACK) from MN(node 5, [email protected])
AN_A4C(node:32): received AAA_AUTH_QUERY(transition ACK) from AN_MMSPP(node 33)
AN_MMSPP(node:33): received AAA_AUTH_REPLY(transition ACK) from A4C(node 32)
MN(node 38,[email protected]): received SIP_MSG_ACK(transition ACK) from AN_MMSPP(node 33 )
**********************************************************
*************CALL SET UP COMPLETE.CALL ESTABLISHED**
************* FROM [email protected] TO [email protected]***************************
**********************************************************
AN_QoSB(node:31): received AN_QOSB_REPORT (transition ACK) from AN_MMSPP(node 33)
Figure 53 Mensajes impresos por los distintos nodos al hacer una llamada. Nótese como la
llamada se considera establecida cuando el llamado recibe el ACK, evento que sucede antes de que
el AN-QoSBroker reciba el mensaje RPT
Una vez vistos los mensajes que imprime nuestro código (Figure 53), vamos a
ver cómo estos concuerdan con las trazas que ns2 genera. Recordemos que esta es una
característica de ns2 que no ha necesitado de ninguna modificación por nuestra parte. La
Figure 54 se centra en la traza hecha para los terminales y la Figure 55 en la traza hecha
para el AN-AA. El análisis para los otros nodos (AN-QoSB, AN-MMSP, CN-MMSP y
CN-AAA) es análogo.
- 165 -
A. Cuevas
Tesis Doctoral
INV --> AN-MMSP
+ 10 20 16 SIP 83 ------- 0 20.0 15.0 -1 256
- 10 20 16 SIP 83 ------- 0 20.0 15.0 -1 256
r 10.001332 20 16 SIP 83 ------- 0 20.0 15.0 -1 256
INV <-- AN-MMSP
+ 10.11584 34 38 SIP 83 ------- 0 33.0 38.0 -1 256
- 10.11584 34 38 SIP 83 ------- 0 33.0 38.0 -1 256
r 10.117172 34 38 SIP 83 ------- 0 33.0 38.0 -1 256
183, 200 --> AN-MMSP
+ 10.117172 38 34 SIP 83 ------- 0 38.0 33.0 -1 256
- 10.117172 38 34 SIP 83 ------- 0 38.0 33.0 -1 256
+ 10.117172 38 34 SIP 83 ------- 0 38.0 33.0 -1 257
- 10.117504 38 34 SIP 83 ------- 0 38.0 33.0 -1 257
r 10.118504 38 34 SIP 83 ------- 0 38.0 33.0 -1 256
r 10.118836 38 34 SIP 83 ------- 0 38.0 33.0 -1 257
183 <-- AN-MMSP
+ 10.151655 16 20 SIP 83 ------- 0 15.0 20.0 -1 257
- 10.151655 16 20 SIP 83 ------- 0 15.0 20.0 -1 257
r 10.152987 16 20 SIP 83 ------- 0 15.0 20.0 -1 257
200 <-- AN-MMSP
+ 10.28532 16 20 SIP 83 ------- 0 15.0 20.0 -1 256
- 10.28532 16 20 SIP 83 ------- 0 15.0 20.0 -1 256
r 10.286652 16 20 SIP 83 ------- 0 15.0 20.0 -1 256
ACK --> AN-MMSP
+ 10.286652 20 16 SIP 83 ------- 0 20.0 15.0 -1 256
- 10.286652 20 16 SIP 83 ------- 0 20.0 15.0 -1 256
r 10.287984 20 16 SIP 83 ------- 0 20.0 15.0 -1 256
ACK <-- AN-MMSP
+ 10.3923 34 38 SIP 83 ------- 0 33.0 38.0 -1 256
- 10.3923 34 38 SIP 83 ------- 0 33.0 38.0 -1 256
r 10.393632 34 38 SIP 83 ------- 0 33.0 38.0 -1 256
[[email protected] valida]$ ../../calc_setup_tr realSimulation_MN.tr
10.000000
0.393632
20 38 256 6
[[email protected] valida]$
Figure 54 Trazas ns realizadas en los terminales (llamante y llamado) junto con la
interpretación de los mensajes y el análisis hecho por nuestra herramienta (tiempo de inicio y
duración del establecimiento de la llamada)
En la traza tenemos todos los mensajes enviados y recibidos por los terminales.
Como están indicadas las direcciones IP origen y destino y como sabemos la secuencia
de los mensajes SIP (INVITE, “183 Session Progress”, “200 OK” y ACK) podemos
asociar a cada traza el mensaje que le corresponde. Esta asociación está mostrada en la
misma figura. Vemos cómo coincide con los mensajes emitidos por nuestro código
(Figure 53). Además vemos como nuestra herramienta de análisis ha sido capaz de
recoger el tiempo de envío el mensaje INVITE por el llamante y el de recepción del
mensaje ACK por el llamado, instantes que delimitan el establecimiento de la llamada.
APR  AN-MMSP
+ 10.010079 11 14 SIP 83 ------- 0 15.0 14.0 -1 256
- 10.010079 11 14 SIP 83 ------- 0 15.0 14.0 -1 256
r 10.010186 11 14 SIP 83 ------- 0 15.0 14.0 -1 256
APA --> AN-MMSP
+ 10.041436 14 11 SIP 83 ------- 0 14.0 15.0 -1 256
- 10.041436 14 11 SIP 83 ------- 0 14.0 15.0 -1 256
r 10.041542 14 11 SIP 83 ------- 0 14.0 15.0 -1 256
APR <-- AN-MMSP
+ 10.07563 29 32 SIP 83 ------- 0 33.0 32.0 -1 256
- 10.07563 29 32 SIP 83 ------- 0 33.0 32.0 -1 256
r 10.075736 29 32 SIP 83 ------- 0 33.0 32.0 -1 256
- 166 -
Validación
APA --> AN-MMSP
+ 10.106986 32 29 SIP 83 ------- 0 32.0 33.0 -1 256
- 10.106986 32 29 SIP 83 ------- 0 32.0 33.0 -1 256
r 10.107093 32 29 SIP 83 ------- 0 32.0 33.0 -1 256
ACR <-- AN-MMSP
+ 10.296731 11 14 SIP 83 ------- 0 15.0 14.0 -1 256
- 10.296731 11 14 SIP 83 ------- 0 15.0 14.0 -1 256
r 10.296838 11 14 SIP 83 ------- 0 15.0 14.0 -1 256
ACA --> AN-MMSP
+ 10.328088 14 11 SIP 83 ------- 0 14.0 15.0 -1 256
- 10.328088 14 11 SIP 83 ------- 0 14.0 15.0 -1 256
r 10.328195 14 11 SIP 83 ------- 0 14.0 15.0 -1 256
ACR <-- AN-MMSP
+ 10.35209 29 32 SIP 83 ------- 0 33.0 32.0 -1 256
- 10.35209 29 32 SIP 83 ------- 0 33.0 32.0 -1 256
r 10.352197 29 32 SIP 83 ------- 0 33.0 32.0 -1 256
ACA --> AN-MMSP
+ 10.383447 32 29 SIP 83 ------- 0 32.0 33.0 -1 256
- 10.383447 32 29 SIP 83 ------- 0 32.0 33.0 -1 256
r 10.383553 32 29 SIP 83 ------- 0 32.0 33.0 -1 256
[[email protected] valida]$ ../../calc_flow_anaaa_tr realSimulation_ANAAA.tr
10.010186
10.041436
256
10.296838
10.328088
256
10.075736
10.106986
256
10.352197
10.383553
256
[[email protected] valida]$
Figure 55 Trazas ns realizadas en los AN-AA (en este caso el mismo para llamante y
llamado) junto con la interpretación de los mensajes y el análisis hecho por nuestra herramienta
(tiempos de recepción y envío del mensaje)
Los mismos comentarios que para la Figure 54 se aplican al caso representado
en la Figure 55. Las trazas coinciden con los mensajes impresos en la Figure 53 y
nuestra herramienta de análisis es capaz de captar los tiempos de procesamiento en le
AN-AA.
6.2.2 Pruebas generales
Vamos a relatar el último tipo de pruebas de validación realizadas, todas ellas
sobre el escenario “normal” (Figure 50). En este caso no miraremos llamadas
individuales, sino todas ellas y en el escenario completo. Varios son los aspectos que
podemos verificar. Primero, que las llamadas se establecen entre los nodos que
deseamos, segundo que los tiempos de establecimiento de llamada corresponden con lo
esperado. Por último, y ligado con el anterior caso, podemos comprobar el nº de
mensajes gestionado por cada nodo. Para el primer caso, nos basta tabular la
información analizada –por nuestra herramienta de cálculo de establecimiento de
sesión- a partir de las trazas generadas por ns2. Nuestra herramienta nos da, entre otras
cosas, el nodo llamante y llamado y el tiempo que se tardó en establecer la llamada.
Pasando los resultados a una tabla Excel, y usando la capacidad de análisis de este
programa vemos que:
•
Tal como deseábamos se establecen 128 llamadas
•
Hay 128 nodos llamantes y 128 nodos llamados
•
Ningún nodo llamante es también llamado (y viceversa)
- 167 -
A. Cuevas
Tesis Doctoral
•
De los 256 nodos, todos participan –como llamante o llamado- en una y
una sola llamada
Para comprobar que la señalización es correcta, establecimos un retardo (400
ms) entre los 4 dominios e “Internet” (es decir en la conexión entre el nodo Internet y
el ER del CN de la Figure 50). Este retardo es muy elevado en comparación con
cualquier otro tipo de retardo en el escenario. En los 4 escenarios de la Table 21,
podemos establecer el número de enlaces CN-Internet que los mensajes de señalización
atraviesan. Para establecer una llamada, como hemos visto, se requiere el intercambio
de 3 mensajes SIP (“INVITE”, “200 OK” y “ACK”) entre llamante y llamado. El
mensaje “183 Session Progress” se envía en paralelo con el 200 OK y no provoca
ninguna respuesta (el ACK se envía al recibir el “200 OK”); por lo tanto no nos influirá
en los cálculos que vamos a relatar.
En el caso de dos usuarios en distintas redes hogar el mensaje INVITE atraviesa
el enlace CN-Internet en el nodo llamante y el enlace Internet-CN en el nodo llamado.
Lo mismo pasa con el mensaje ACK y lo contrario con el mensaje “200 OK”. Los
enlaces entre los CN e Internet, como hemos dicho tienen un retardo de 400 ms, por lo
tanto hemos de sumar 400 ms * 6 =2,4 segundos al tiempo de establecimiento de
llamada. La Figure 56 ilustra este caso.
Non Roaming Terminal
From an
ER in a CN
From an
ER in a CN
OK: 1
OK: 1
INVITE &
ACK: 1
INVITE &
ACK: 2
Internet
618
From an
ER in a CN
Internet
617
Internet
616
From an
ER in a CN
Figure 56 Enlaces CN-Internet atravesados para el caso 1
Las Figure 57 y Figure 58 ilustran otros dos casos y, siguiendo un razonamiento
análogo al anterior, podemos decir que el retardo introducido por el tiempo de
propagación de los enlaces CN-Internet en el caso en el que uno de los usuarios está en
roaming en le dominio hogar del otro (Figure 57), es de 18*400 ms=7,2 s. En el caso de
que los usuarios estén en un mismo dominio y sólo el llamante esté en roaming -Figure
58- ese retardo es de 12*400 ms=4,8 s. Evidentemente, si los nodos están el mismo
dominio y ese dominio es su dominio hogar ese retardo es 0. El retardo obtenido en esta
situación es el debido a los tiempos de procesamiento de los otros nodos y se añadirá al
retardo de los otros casos.
- 168 -
Validación
Roaming Terminal
From an
ER in a CN
INVITE &
ACK: 1,4
From an
ER in a CN
OK:
1,4
Internet
618
Internet
617
INVITE &
ACK: 2,3
OK:
2,3
Internet
616
From an
ER in a CN
From an
ER in a CN
Roaming Terminal
Roaming Terminal
From an
ER in a CN
INVITE &
ACK: 1,4,5
From an
ER in a CN
OK:
2,3,6
OK:
1
INVITE &
ACK: 6
Internet
618
Internet
617
INVITE &
ACK: 2,3
OK:
4,5
From an
ER in a CN
Internet
616
From an
ER in a CN
La Table 23 recoge estos resultados.
Dominio llamante o llamado Igual o Situación
del Situación
del Retardo introducido
Distinto
llamante (Roaming llamado
en el establecimiento
o No Roaming)
(Roaming o No de sesión por atravesar
Roaming)
enlaces CN-Internet
D
D
NR
NR
2,4 s
I
I
NR
NR
0s
D
D
R
R
7,2 s
D
I
R
NR
4,8 s
Table 23 Casos simulados en nuestro escenario, retardo introducido por los enlaces CNInternet cuando el tiempo de propagación es 400 ms
Experimentalmente, los tiempos de establecimiento de llamada se pueden dividir
en 4 grupos claramente separados. Tenemos una serie de llamadas (32 en concreto)
cuyo tiempo de establecimiento se encuentra entre 1,7 y 2,2 s. Estas llamadas son las
que no necesitan atravesar ningún enlace CN-Internet. Este es el lapso que se necesita
para establecer una llamada teniendo en cuenta los tiempos de procesamiento de todos
- 169 -
A. Cuevas
Tesis Doctoral
los nodos (AN-AAA, …). En la sección 6.3 profundizaremos en él. Tenemos otras tres
categorías, cada una con 32 llamadas también definidas por tiempos de establecimiento
(en s) de llamada entre 1) 4,2 y 4,7; 2) 6,7 y 7,1; 3) 9 y 9,6. La separación (en
segundos) entre los cuatro grupos obtenida en las simulaciones coincide con los tiempos
calculados en la Table 23. Esto corrobora los resultados anteriores sobre la correcta
construcción de nuestro escenario. Además muestra que la señalización en el escenario
se hace de forma correcta, al menos en cuanto a intercambio de mensajes SIP entre los
CN-MMSPs.
Otra prueba para verificar la correcta señalización es analizar el número de
mensajes procesado por cada nodo. De nuevo usamos nuestras herramientas de análisis
y la tabulación en Excel para efectuar ese recuento. Los resultados, para 128 llamadas
efectuadas en el escenario y para uno de cada tipo de nodos son los que aparecen en
Table 24. Todos ellos concuerdan con los cálculos de la sección 6.1. El lector se podrá
preguntar porqué el número de mensajes gestionado por un CN-MMSP no es 8 veces
más grande que el gestionado por un AN-MMSP, la razón la hemos explicado en la
sección 6.1, Table 22.
AN-MMSP (sólo mensajes SIP)
AN-QoSBroker (sin contar mensaje RPT)
AN-AA
CN-MMSP (sólo mensajes SIP)
CN-AAA
32
8
16
320
64
Table 24 Nº de mensajes gestionados por cada nodo. 128 llamadas en el escenario
Finalmente, también en el escenario completo, comprobamos que el retardo de
procesamiento en los distintos nodos estaba bien implementado y si nuestras
herramientas de análisis eran capaces de extraerlo de las trazas ns2 sin errores. Para ello,
sobrecargamos la red y miramos el comportamiento de los distintos nodos. La Figure 59
muestra los resultados obtenidos para el CN-AAA. Cada barra es un mensaje procesado
en el CN-AAA, el inicio de la barra (a la izquierda) indica el momento en el que ese
mensaje llegó al CN-AAA. El final indica el instante en el que salió. El tiempo de
procesamiento no es más que la “longitud” (en segundos) de la barra. Analizando esa
figura y apoyándonos en los resultados numéricos obtenidos en la simulación podemos
decir que el primer mensaje (abajo a la izquierda en la figura) tarda exactamente en
procesarse 0,03125 segundos, que fue lo que establecimos en la configuración de
nuestro escenario. Además comprobamos (tanto en la Figure 59 como en los resultados
numéricos obtenidos) que el tiempo de salida del mensaje n, es el tiempo de salida del
mensaje n-1más los 0,03125 segundos de tiempo de procesamiento. Esto se ve en la
figura a partir del 4º mensaje; todos los sucesivos mensajes, cuando entran en el CNAAA se encuentran con que éste debe procesar más mensajes antes que ellos. Un
fenómeno interesante que muestra la figura (y que detallaremos luego) es que el nodo
CN-AAA, bajo la cadencia de llamadas establecida, entra en saturación, el tiempo de
procesamiento de los mensajes se hace cada vez más largo (mayor longitud de las
barras)
- 170 -
Validación
Mensaje (ordenados por tiempo de entrada)
Tiempo de entrada, procesamiento y salida de los
mensajes en el CN-AAA en condiciones de saturación
12.2
12.4
12.6
12.8
13
13.2
13.4
Tiempo (s)
Figure 59 tiempo de procesamiento en el CN-AAA
6.3 Pruebas
Diseñamos nuestro escenario para soportar una tasa de 64 llamadas /s. Teniendo
en cuenta que tenemos 256 nodos que establecen 128 llamadas, esto significa que el
inicio de esas 128 llamadas debe realizarse en un intervalo de 2s. Elegimos que el
inicio de la llamada fuera una variable aleatoria con distribución uniforme entre 0 y 2
(s). A ese tiempo de inicio le sumamos 12 s (para separarlo en el tiempo del proceso de
registro AAA de los terminales). Notemos que, pese a estar tratando con variables
aleatorias, no repetimos los experimentos varias veces. Como veremos, los resultados se
centrarán en caracterizar el sistema sin mirar individualmente cada una de las llamadas.
Como tenemos un número muy elevado de llamadas de las mismas características (e.g.
roaming a no roaming) no necesitamos repetir ninguna prueba para observar el
comportamiento general del sistema. Por otra parte, elegimos distribuciones uniformes
(y no exponenciales, por ejemplo) porque nuestro objetivo es medir la carga sostenida
que es capaz de manejar del sistema.
El tiempo de procesamiento de los nodos lo calculamos para soportar esta tasa
de 64 llamadas/s y teniendo en cuenta el número de mensajes por llamada que debe
procesar cada tipo de nodo (ver sección 6.1, Figure 51). La Table 25 muestra los
retardos de procesamiento para cada nodo. Debemos tener en cuenta para estos cálculos
que a un mensaje sólo se le aplica un retardo de procesamiento cuando va a salir del
nodo. Además, los cálculos se han realizado para el caso en el que le terminal hace la
reserva de QoS, es decir el AN-MMSP no necesita interactuar con el AN-QoSBroker.
Capacidad de proceso (mensajes/s)
Terminal
AN-MMSP
AN-QoSBroker
AN-AA
CN-MMSP
CN-AAA
24
4
8
200
32
- 171 -
Retardo de proceso –sólo para los
mensajes salientes- (s/mensaje)
0
0.04167
0.25
0.125
0.005
0.03125
A. Cuevas
Tesis Doctoral
Table 25 velocidad de procesamiento en los nodos para soportar 64 llamadas/s
6.3.1 Tasa de llamadas soportada por el sistema
Nuestras primeras medidas observan el tiempo de establecimiento de llamada
para las 128 llamadas efectuadas en un intervalo de 2 s. Para el caso en el que el ANMMSP hace la reserva de recursos con el AN-QoSBroker el tiempo de establecimiento
varía entre 1,86 y 3,55 segundos. En el caso en el que el terminal contacta con el ANQoSBroker esos tiempos son entre 1,6 y 3,4 segundos.
Para asegurarnos que observamos el sistema ante en un estado permanente y no
en un transitorio repetimos todo el proceso varias veces sumando, a cada vez, 2 s más
(valor fijo no aleatorio) al tiempo aleatorio de inicio de la llamada. Vemos que una tasa
de 64 llamadas por segundo satura al sistema, aumentando paulatinamente el tiempo de
establecimiento de la llamada a medida que entran más llamadas en el sistema. Esto por,
lo tanto, invalida a los resultados anteriores. Puesto que estamos ante una situación
“inestable” no tiene sentido dar valores cuantitativos. La Figure 60 muestra de forma
cualitativa el tiempo de establecimiento de llamada. La figura se centra en el caso en el
que el AN-MMSP realiza la reserva de QoS con el AN-QoSBroker lo que, de ahora en
adelante, llamaremos de forma abreviada estrategia “MMSP”.
Tiempos de inicio, fin y duración del establecimiento de las llamadas.
Llamadas (ordenadas por tiempo de inicio)
64 llamadas/s. Estrategia "MMSP"
12
16
20
24
28
32
36
40
44
48
Tiempo (s)
Figure 60 Tiempo de establecimiento de llamada. Condiciones de saturación. MMSP
En la Figure 60 vemos como las llamadas “pendientes de procesar” se acumulan
en el sistema ya que estas entran a una tasa más rápida que la de procesamiento del
sistema. Esto lleva a una paulatina saturación y a un incremento gradual del tiempo de
procesamiento, cuyo máximo (14,7 s) está señalado por la línea horizontal continua en
la figura. Esta tendencia se invierte cuando dejan de entrar llamadas al sistema (instante
36s de la simulación), momento señalado en la gráfica con una línea punteada vertical.
Cuando es el terminal quien realiza la reserva de QoS -estrategia MN (de
Mobile Node)- el tiempo de establecimiento de llamada también aumenta de forma
progresiva, pero mucho más lentamente, es decir el sistema está menos saturado.
- 172 -
Validación
La diferencia observada entre las dos estrategias se puede explicar por la distinta
carga del AN-MMSP: en la estrategia MMSP, debe encargarse de la reserva de recursos
con el QoSBroker y en la estrategia MN no (se encarga el terminal). Recordemos que
los terminales (MNs) no tienen, en nuestra simulación, ningún retardo. Esta
simplificación es lógica puesto que un terminal procesa un número de mensajes muy
inferior al de los nodos AN o CN.
Analizando el tiempo de procesamiento de un mensaje en un nodo, vimos que
este tiempo, prácticamente en todos los casos, incluía el tiempo para que anteriores
mensajes terminaran de ser procesados. Pero aún así, ese tiempo no aumentaba
progresivamente, tan sólo sufría oscilaciones a lo largo de la simulación; es decir, el
nodo no estaba saturado. En la estrategia “MMSP” todos los nodos se comportaban así
(salvo el AN-MMSP que luego estudiaremos). A modo de ejemplo, la Figure 61
muestra el tiempo de procesamiento de los mensajes en un AN-AA en el caso MMSP.
Recordemos que nuestro escenario es perfectamente “simétrico”, es decir cada dominio,
cada CN y AN soportan la misma carga y tipo de llamadas. Por lo tanto, el
comportamiento de, por ejemplo, los 64 AN-AA será muy similar entre sí y elegir para
su estudio uno de ellos será tomar una muestra representativa del comportamiento de
todos. En la Figure 61 el lector puede observar que aparecen algunos mensajes (19) con
un tiempo de procesamiento “anormalmente” alto: superior a 0.35 s e incluso cercano a
los 0.6 cuando el tiempo “normal” de los demás (173) ronda entre los 0,1 y 0,32 s.
Como hemos dicho, el tiempo de inicio de las llamadas es una variable aleatoria unirme
entre 0 y 2s. Esto puede provocar que, en ciertos intervalos, haya un número de
llamadas “anormalmente” elevado y, por tanto, el tiempo de procesamiento se
incremente. Esto explica esos picos observados. Lo importante es recalcar que el ANAA (y los otros nodos también) pasados esos picos vuelven a una situación “normal”.
Tiempo de procesamiento de los mensajes en un AN-AA
64 llamadas/s. Estrategia MMSP. Cada punto es un mensaje
Tiempo de procesamiento del mensaje (s)
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
12
16
20
24
28
32
36
40
44
48
Tiempo de de entrada del mensaje (s)
Figure 61 Tiempo de procesamiento en un AN-AA. Condiciones de saturación. Estrategia
MMSP
Como hemos dicho, el único nodo que no tiene un comportamiento inestable es
el AN-MMSP. La Figure 62 muestra como su tiempo de proceso se incrementa
gradualmente. Esto es debido a que la tasa de entrada de mensajes es superior a la de
salida y, por lo tanto, cada mensaje nuevo tiene que esperar más tiempo a que los
anteriores mensajes sean procesados para que llegue su turno de ser procesado. Esta
tendencia dura hasta el segundo 36, instante en el cual se dejan de inyectar más
- 173 -
A. Cuevas
Tesis Doctoral
llamadas al sistema. A partir de ese momento la cola de mensajes en el AN-MMSP
desciende y, por lo tanto, el tiempo en atender un mensaje. Otro fenómeno que muestra
la figura es la existencia de un grupo de mensajes (curva inferior) con un tiempo de
procesamiento menor (pero con la misma evolución comentada). Estos mensajes son los
mensajes “183 Session Progress” que a diferencia de los otros (INVITE, “200 OK” y
ACK) no necesitan de la interacción con ningún elemento (AN-AA y AN-QoSBroker)
para ser procesados. Puntualizemos que en estas pruebas so se realiza la reserva de QoS
por el AN-MMSP de llamante hasta que se recibe el mensaje “200 OK”, no cuando se
recibe el mensaje “183 Session Progress”. Ese caso, que es el que hemos propuesto en
la sección 4.3.4, será estudiado más adelante (sección 6.3.4). El tiempo de proceso de
los mensajes “183 Session Progress” muestra que el AN-MMSP está saturado “de por
sí” no por su interacción con otros elementos.
Tiempo de procesamiento de los mensajes en un AN-MMSP.
Tiempo de proceso del mensaje (s)
3
2.5
2
1.5
1
0.5
0
12
16
20
24
28
32
36
40
44
48
Tiempo de entrada del mensaje (s)
Figure 62 Tiempo de procesamiento de los mensajes en un AN-MMSP. Condiciones de
saturación. Estrategia MMSP
Recordemos que los tiempos de proceso del AN-MMSP se calcularon para la
estrategia “MN” no para la MMSP, caso en el que el AN-MMSP procesa más mensajes.
Por lo tanto, en la estrategia MN, debemos ver si el nodo AN-MMSP también es el
nodo saturado y causante de la saturación del sistema o si son otros. El estudio del ANMMSP se muestra en la Figure 63. Ahí vemos como, en este caso, el nodo AN-MMSP
no está saturado pues su tiempo de proceso es constante. Además, al igual que en el
anterior caso, distinguimos un grupo de mensajes con un tiempo de proceso mucho
menor. En este caso son los “183 Session Progress” pero también los “200 OK” pues
estos últimos en esta estrategia tampoco deben de esperar la respuesta de ningún nodo
para ser procesados.
- 174 -
Validación
64 llamadas/s. Estrategia MN. Cada punto es un mensaje
1.2
1
0.8
0.6
0.4
0.2
0
12
16
20
24
28
32
36
40
44
48
Figure 63 Tiempo de procesamiento de los mensajes en un AN-MMSP. Condiciones de
saturación. Estrategia MN
Visto que en la estrategia MN el causante de la saturación no era el AN-MMSP
debemos ver si hay algún otro nodo saturado. Todos tienen un comportamiento
“normal” (su tiempo de procesamiento no va aumentando). Eso sí, al igual que para el
AN-MMSP el tiempo de proceso es muy oscilante, variando a lo largo de la simulación
incluso en un orden de magnitud.
Después de estas observaciones podemos concluir dos cosas. La primera, que
nuestros cálculos a la hora de establecer los tiempos de proceso en los nodos eran
correctos ya que ninguno de ellos se satura –para la estrategia MN-. Segundo, si bien los
nodos no están saturados, como estos están trabajando al límite de su capacidad, la
influencia de los unos sobre los otros (en especial de los nodos más lentos) hace que es
el escenario global sí esté saturado. Esto hace que, a la hora de calcular la capacidad de
un sistema como el de esta tesis, los métodos analíticos no sean suficientes y haya que
recurrir a simulaciones para encontrar el punto de trabajo óptimo; aspecto que
abordaremos más adelante.
Después de trabajar con el escenario justo en el límite de su capacidad y ver
cómo éste se saturaba, hicimos las pruebas contrarias: llevar el sistema a zonas de muy
poca carga distribuyendo el inicio del las llamadas en un intervalo de 40 s y luego en
uno de 80 s. Al igual que antes, esos son los intervalos de la distribución uniforme de la
variable aleatoria que define el inicio de la llamada. Los resultados obtenidos, para 128
llamadas, se representan en la Table 26. Evidentemente, en estas condiciones el sistema
es completamente estable, el tiempo de establecimiento de llamada se mantiene
estacionario –no aumente paulatinamente- y, por lo tanto, tiene sentido dar su media, tal
como se hace en la tabla. Además éste no varía prácticamente se espacien las llamadas
40 u 80 s. Los valores encontrados son pues los valores mínimos que se pueden obtener
para el establecimiento de llamada.
Estrategia
MMSP
MN
Intervalo de 80 s, 1,6 llamadas/s
Min
Media
Max
1,64
1,76
2,20
1,57
1,68
1,89
Intervalo de 40 s, 3,2 llamadas/s
Min
Media
Max
1,64
1,78
2,14
Table 26 Tiempo de establecimiento de llamada bajo condiciones de mínima carga
- 175 -
A. Cuevas
Tesis Doctoral
Podemos constatar un hecho relevante: la diferencia de tiempo de
establecimiento de llamada entre las dos estrategias es de 0,08 s (para las medias).
Recordemos que el tiempo de procesamiento del AN-MMSP es de 0,0416 s y que en la
estrategia MMSP, el AN-MMSP debe gestionar dos mensajes más que en la estrategia
MN: la reserva de recursos en el AN-QoSBroker del llamante y del llamado. Ese tiempo
extra (0,0416*2) coincide con la diferencia de 0,08 s medida.
Una vez observado el comportamiento del sistema bajo poca carga, vamos a
encontrar cual es la carga mayor que podemos introducir sin que el sistema se sature.
Para el caso de la estrategia MMSP esa carga es 42,6 llamadas/s (es decir distribuir el
establecimiento de llamada en un rango de 0 a 3 s.) Para el caso MN es 53,3 es decir el
rango de inicio de la llamada está entre 0 y 2,4 s. La Table 27 compara los tiempos para
las dos estrategias cuando la carga es 42,6 llamadas/s. De nuevo, como el tiempo de
establecimiento de llamada es estable tiene sentido dar su media.
Un análisis interesante es comparar las Table 26 y Table 27. En el caso MMSP,
el tiempo de establecimiento aumenta un 70% y en el caso MN un 45%. Además la
diferencia de tiempos (0,65 s) ya no coincide, como en el anterior caso, con la diferencia
de tiempo de procesamiento del AN-MMSP. Esto nos muestra como, en condiciones de
alta carga (pero sin llegar a la saturación), la carga de un nodo (en concreto el ANMMSP en la estrategia MMSP) influye en todo el sistema más allá del propio retardo
introducido por ese nodo. Además, el AN-MMSP es el que más interacciones tiene con
otros nodos. Para compensar esto, debemos hacer que el procesamiento en el ANMMSP sea los más sencillo posible, por ejemplo, como propusimos en nuestra
arquitectura, ahorrándole todo proceso de rutado de mensajes SIP y dejando esa tarea al
CN-MMSP. En la sección 6.3.3 analizaremos más la influencia de la capacidad de
proceso del AN-MMSP.
Mmsp
Mn
Min
1,82
1,64
42,6 llamadas/s
media
3,07
2,42
Max
4,85
3,9
Table 27 Tiempo de establecimiento de llamada con carga máxima antes de tener
saturación
Las tres figuras siguientes (Figure 64, Figure 65 y Figure 66) muestran el tiempo
de establecimiento de sesión para las dos estrategias. Se puede ver cómo ese tiempo es
estacionario, el sistema no está saturado. La Figure 64 sigue el mismo esquema que la
Figure 60, pero aquí observamos cómo las llamadas no se van acumulando en el sistema
(la curva no se ensancha). Las otras dos figuras ilustran el mismo fenómeno pero bajo
otra representación: cada llamada está simbolizadaza con un punto que en el gráfico
indica el tiempo de inicio de la llamada y la duración del proceso de establecimiento de
la misma. Se puede ver, además, como las llamadas para el caso MMSP (Figure 65)
tienen un tiempo de procesamiento mayor (recta más “alta”) que para la estrategia MN
(Figure 66). Puntualizamos, además, que el rango del eje y de la Figure 66 es más
grande de lo necesario. En este y otros gráficos que veremos, esto se ha hecho para que
la escala coincida con las escalas de otras figuras y, así, poder compararlas mejor.
- 176 -
Validación
Tiempos de inicio, fin y duración del establecimiento de las llamadas.
Llamadas (ordenadas por tiempo de inicio)
43 llamadas/s. Estrategia "MMSP"
12
17
22
27
32
37
42
47
52
Tiempo (s)
Figure 64 Tiempo de establecimiento de llamada. Estrategia “MMSP"
Tiempo de establecimiento de las llamadas.
43 llamadas/s estrategia MMSP. Cada punto es una llamada
Tiempo de inicio de la llamada (s)
6
5
4
3
2
1
0
12
17
22
27
32
37
42
47
52
Tiempo de establecimiento de la llamada (s)
Figure 65 Tiempo de establecimiento de llamada. Estrategia “MMSP" (2)
43 llamadas/s estrategia MN. Cada punto es una llamada
Tiempo de establecimiento (s)
6
5
4
3
2
1
0
12
17
22
27
32
37
42
47
52
Figure 66 Tiempo de establecimiento de llamada. Estrategia “MN”
Puesto que ya no estamos en una situación de saturación, vamos a observar
ahora el comportamiento del nodo AN-MMSP que en la estrategia MMSP y con 64
llamadas/s estaba saturado. Vemos en la Figure 67 como ya no es el caso.
- 177 -
A. Cuevas
Tesis Doctoral
Tiempo de procesamiento del mensaje (s)
1.2
1
0.8
0.6
0.4
0.2
0
12
17
22
27
32
37
42
47
52
Figure 67 Tiempo de procesamiento de los mensajes en el AN-MMSP. Estrategia MMSP
6.3.2 Respuesta ante un pico de llamadas
Abordaremos en esta sección la respuesta del sistema ante un pico de llamadas.
Veremos lo que tarda en recuperarse y los nodos más afectados por el pico. Para ello
generamos las llamadas espaciadas con en los anteriores experimentos pero esta vez
definimos tres tramos: de 12 s a 36 s con 43 llamadas / s de 36 s a 37 s con 128
llamadas/s y de 37 s a 85 s con 43 llamadas / s de nuevo. Como hemos visto, el sistema
soporta 43 llamadas/s (en ambas estrategias) pero, también en ambas estrategias –
MMSP y MN- 64 llamadas/s saturaban al sistema y, evidentemente, 128 llamadas /s
también lo harán.
La Figure 68, la Figure 69 y la Figure 70 muestran el tiempo de establecimiento
de las llamadas. En los dos últimos gráficos vemos claramente los picos y cómo la
estrategia MN se recupera mucho antes -llega antes a tiempos de establecimientos
acordes con las 43 llamadas/s que tenemos después (y antes) del pico-. En el primer
caso la demora es de unos 16 s, en el segundo de unos 6 (menos de la mitad). Además,
podemos observar como en condiciones “permanentes” el tiempo de establecimiento de
llamada coincide con los valores de las Figure 65 y Figure 66. La Figure 68 es
meramente ilustrativa y nos sirve para comparar con casos anteriores. Por claridad de
representación dicha figura sólo muestra una “ventana” de tiempo de toda la simulación.
Vemos fenómenos ya relatados: tiempos de proceso constantes, luego, durante el pico
de llamadas, acumulación de las mismas para, al final, cuando ese pico de llamadas
cesa, ir reduciendo las llamadas pendientes de ser procesadas.
- 178 -
Validación
Tiempos de inicio, fin y establecimiento de las llamadas.
Estrategia MMSP. Pico de llamadas. Estracto
30
35
40
45
50
Tiempo (s)
55
60
65
70
Figure 68 Establecimiento de llamada (extracto). Pico de llamadas. Estrategia “MMSP"
Pico de llamadas. Estrategia MMSP
9
8
7
6
5
4
3
2
1
0
12
22
32
42
52
62
72
82
Figure 69 Tiempo de establecimiento de llamada. Pico de llamadas. Estrategia “MMSP"
Pico de llamadas. Estrategia MMSP
Tiempo de procesamiento (s)
9
8
7
6
5
4
3
2
1
0
12
22
32
42
52
62
72
82
Figure 70 Tiempo de establecimiento de llamada (extracto). Pico de llamadas. Estrategia
“MN"
- 179 -
A. Cuevas
Tesis Doctoral
Como hemos dicho, la estrategia MMSP presenta un pico más agudo y tarda más
en volver al estado normal que la estrategia MN. Analicemos por qué. Adelantamos que
este análisis nos aportará, además, conclusiones interesantes relacionadas con otros
aspectos.
De los anteriores experimentos vemos que el nodo que tiene un comportamiento
más distinto entre las dos estrategias es el AN-MMSP, ya que en una (la MMSP)
procesa más mensajes que en la otra (MN). Lo mismo sucede en este escenario.
Presentamos es las siguientes figuras las medidas en un AN-MMSP para ambas
estrategias. Podemos observar como el tiempo de procesamiento en la estrategia MMSP
(Figure 71) es mucho mayor y se puede apreciar el pico en ese tiempo de proceso,
correspondiente al pico de carga que existe en el sistema. En cambio, el tiempo de
proceso en el caso MN (Figure 72), es mucho menor. Puesto que el comportamiento de
los otros nodos en similar entre ambas estrategias, deducimos que la mayor carga del
AN-MMSP es la razón por la que el escenario “MMSP” tarda más en recuperarse
del pico de llamadas.
Pico de llamadas. Cada punto es un mensaje. Estrategia MMSP
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
0
10
20
30
40
50
60
70
80
90
100
Figure 71 Tiempo de procesamiento en el AN-MMSP. Pico de llamadas. Estrategia MMSP
- 180 -
Validación
Pico de llamadas. Cada punto es un mensaje. Estrategia MN
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
0
10
20
30
40
50
60
70
80
90
100
Figure 72 Tiempo de procesamiento de los mensajes en el AN-MMSP. Estrategia MN
Como hecho relevante, podemos decir que el tiempo de proceso en el ANMMSP en la estrategia MN no presenta ningún pico netamente definido. Este es un
aspecto sobre el que volveremos luego. Además, en la Figure 72 vemos una serie de
puntos claramente diferenciados por tener menor tiempo de procesamiento (y en un
rango más compacto). Esto puntos corresponden a los mensajes “183 Session Progress”
y “200 OK” que en esta estrategia (MN) no necesitan de la interacción con ningún nodo
(AN-AA o AN-QoSBroker) para ser procesados por el AN-MMSP. Por eso se procesan
mucho más rápidamente. Contando con Excel esos puntos vemos que son un 50% del
total, al igual que los mensajes 183 y 200 son un 50% del total de los mensajes SIP
intercambiados para establecer la sesión.
Habíamos comentado que el AN-MMSP, en la estrategia MN no presenta un
pico de procesamiento. Lo mismo pasa para otros elementos del AN. En cambio los
elementos del CN (CN-MMSP y CN-AAA -Figure 73-) si presentan un pico nítido de
procesamiento. Una explicación razonable de este fenómeno es que el pico de 128
llamadas producidas en un segundo queda “diluido” en los elementos del AN pero no
en los del CN ya que tenemos 8 ANs por cada CN. Esto muestra los beneficios de tener
una arquitectura jerárquica y es que la congestión no se propaga a todos los nodos.
Para evitar que, en picos de llamada, los nodos centrales (CN) se congestionaran (por la
suma de pequeñas congestiones en los nodos de los AN) bastaría con replicar aquellos.
- 181 -
A. Cuevas
Tesis Doctoral
Tiempo de procesamiento de los mensajes en un CN-AAA. Pico de llamadas. Cada punto
es un mensaje. Estrategia MN
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
12
22
32
42
52
62
72
82
Figure 73 Tiempo de procesamiento en el CN-AAA. Pico de llamadas. Estrategia MN
6.3.3 Heterogeneidad en las capacidades. Cuellos de botella
Para procesar los mensajes INVITE y ACK el AN-MMSP debe interactuar con
el AN-AA. Además, en la estrategia MMSP, para procesar el mensaje “200 OK” debe
interactuar con el AN-QoSBroker; recordemos que hasta la sección 6.3.4, no
contemplaremos el caso presentado en el capítulo 5, donde la reserva de QoS se realiza
al recibir el mensaje “183 Session Progress”. Pero estos nodos, en nuestro escenario,
como tienen que procesar menos mensajes que el AN-MMSP son más lentos que éste.
Como hemos visto, esto provoca un retraso en el procesamiento de los mensajes en el
AN-MMSP. Además, el AN-MMSP cuenta con una sola cola de mensajes y sus
recursos de procesamiento (24 mensajes/s) se dividen “equitativamente” entre todos los
mensajes que salen de la cola, sea cual sea su destino: un CN-MMSP con retardo de
procesamiento de 0,005 s/mensaje, un AN-QoSB con un retardo de procesamiento de
0,25 s/m, etc. Nuestra idea es dotar el AN-MMSP de 4 colas de mensajes, una para los
mensajes a los nodos móviles, una segunda para los mensajes al CN-MMSP, otra para
los mensajes al AN-QoSBroker y la cuarta para los mensajes al AN-AA.
Antes de comenzar con nuestro análisis vamos a hacer una prueba, que podemos
considerar como una prueba piloto. En ella el tiempo de procesamiento del AN-MMSP
se fija a 0 s/mensaje y, tenga éste 4 colas o 1, los resultados son idénticos, como es
lógico. Usamos el escenario de la anterior sección, con un pico de llamadas. Escogemos
la estrategia MMSP. El tiempo medio de establecimiento de llamada (en condiciones
estables) es de 1,83 s, es decir un poco superior al obtenido para un sistema no cargado
(Table 26). Es decir, el reducir a 0 el tiempo de proceso del AN-MMSP, hace que los
tiempos de establecimiento de llamada sean prácticamente iguales a los obtenidos en
casos de mínima carga. Esto de nuevo muestra la gran influencia del AN-MMSP en el
sistema pues es el nodo que más interacciones debe realizar. Además, se observan
resultados muy similares para la estrategia MN. En los anteriores casos, para la
estrategia MN los tiempos de establecimiento de llamada eran menores. No es así en
estos experimentos. Recordemos que en la estrategia MN la diferencia es que el ANMMSP gestiona menos mensajes y, por lo tanto, introduce menos retardo. Como aquí el
tiempo de procesamiento es 0 mensajes/s está diferencia queda sin efecto, de ahí que los
resultados entre las dos estrategias MN y MMSP sean muy parecidos. Como conclusión
- 182 -
Validación
podemos decir que la gran influencia en el retardo de establecimiento de las llamadas
del AN-MMSP justifica que encontremos fórmulas para evitar que este nodo se
convierta en un cuello de botella. Una de ellas, la que estamos estudiando en esta
sección, es la creación de 4 colas de mensajes en el AN-MMSP.
Para realizar nuestras pruebas, la primera tarea a acometer es ver qué capacidad
de procesamiento otorgar a cada una de las 4 colas de mensajes. Veamos el caso en el
que una sola llamada se establece en le sistema. Supongamos que los AN-MMSPs
tienen una sola cola. Veamos el caso del AN-MMSP del llamante. Primero entra el
mensaje INVITE, y el AN-MMSP debe enviar una petición al AN-AA. Esta petición se
pone en la cola. Como es la única tardará exactamente 0,0417 s (tiempo configurado por
nosotros tal como vimos en las anteriores secciones) en ser procesada y enviada al ANAA. Cuando se reciba la respuesta del AN-AA, el AN-MMSP reenvía el mensaje
INVITE al CN-MMSP. Este mensaje se pone en la cola e, igual que antes, tarda 0,0417
s en ser enviado. Idéntico razonamiento hacemos con los otros mensajes. Para el caso en
él que el AN-MMSP tiene cuatro colas todas con un retardo de procesamiento de 0,0417
s/mensajes, el mensaje al AN-AA se pondría en esa cola y también tardaría 0,0417s. El
mensaje al CN-MMSP se pondría en dicha cola y tardaría 0,0417 s. Es decir, en
condiciones sin carga es lo mismo tener una cola con un retardo de procesamiento de
0,0417 s /m que 4 con ese mismo retardo.
Estos datos los verificamos experimentalmente realizando una sola llamada en el
sistema y viendo cuanto tarda en ser procesada con 1 o 4 colas en el AN-MMSP. En
cambio, para el caso en el que los mensajes se acumulan en el AN-MMSP a la espera
de ser procesados, sí que encontramos diferencias, como es lógico. En estas pruebas
originamos 4 llamadas idénticas, es decir, emitidas en el mismo instante y con igual
llamante y llamado. En el caso de tener una cola las llamadas tardaron 1.68; 2.01; 2.26
y 2.51 s en establecerse. El lector debe notar que aunque los mensajes INVITE se
emitan en el mismo instante, ns2 los ordena en el enlace según se hayan ordenado en el
archivo que genera las ordenes de simulación. En el AN-MMSP y en el resto de los
nodos, los mensajes deberán esperar a que los anteriores hayan sido procesados para ser
ellos atendidos. Por eso el tiempo de establecimiento de las llamadas va aumentando.
Veamos el caso en el que los AN-MMSP tienen 4 colas. Los tiempos medidos fueron
1.63; 1.88; 2.13 y 2.38 s. es decir un 5% aproximadamente más bajos.
Hecho este estudio, decidimos hacer que el tiempo de procesamiento de las 4
colas sumara 4*0,0417s/mensaje, es decir una llamada con el sistema vacío debía tardar
lo mismo que con una sola cola con un retardo de 0,0417s, tal como hemos visto antes.
Además otorgamos mayor capacidad a las colas que van a destinos con velocidades de
proceso más rápidas. Los nodos móviles no tiene retardo de procesamiento y para estos
cálculos asumimos que es igual al del CN-MMSP: 0,005 s/mensaje. Así obtenemos la
Table 28.
Cola
CN-MMSP
Terminal (MN)
AN-AA
AN-QoSBroker
Total
Tiempo de proceso (s/mensaje)
0.00216
0.00216
0.054
0.108
0.0417*4
Tiempo de proceso del nodo ( s/mensaje)
0.005
0 (para los cálculos usamos 0.005)
0.125
0.25
--
Table 28 Velocidad de proceso de las 4 colas del AN-MMSP
- 183 -
A. Cuevas
Tesis Doctoral
Los resultados más relevantes, también para un escenario con pico de llamadas,
son el tiempo de procesamiento de los mensajes. La Figure 74 se centra en la estrategia
MMSP. De nuevo puntualizamos que la escala del eje “y” se ha elegido de forma que
sea fácil comparar esta figura con las de otros casos anteriores. Respecto al caso MMSP
anterior (sin 4 colas en el AN-MMSP) debemos notar cómo el tiempo de procesado (2,3
s de media) de los mensajes –en condiciones estables- ha disminuido (más de 20%).
Además, se da una disminución más pronunciada aún de los efectos del pico de
llamadas: su “cumbre” es menor y también lo es el tiempo (6 s) que se tarda en volver a
una situación estable (menos de la mitad). Para la estrategia MN, los resultados son
similares pero siendo la media más baja que en la estrategia MMSP, como en los casos
estudiados anteriormente. El resultado es 2,1s. La ganancia respecto a la estrategia MN
pero sin 4 colas en los AN-MMSP es un poco menor que 20%.
Tiempo de establecimiento de llamada.
Pico de llamadas. Estrategia MMSP. 4 colas en AN-MMSP
9
8
7
6
5
4
3
2
1
0
12
22
32
42
52
62
72
82
Instante de inicio de la llamada (s)
Figure 74 Establecimiento de llamada. 4 colas en el AN-MMSP. Estrategia MMSP
Que las ganancias de ambas estrategias respecto a las pruebas con una sola cola
sean similares (entorno al 20%) nos hace pensar que lo que más ha influido ha sido el
aumentar la capacidad de procesamiento del AN-MMSP antes que la correcta
elección del tiempo de procesamiento de sus colas. Para corroborar esta hipótesis
realizamos tres nuevos experimentos todos para la estrategia MMSP. En el primero
pusimos un tiempo de procesamiento igual en todas las colas de 0,0417 s/mensaje. En el
segundo, en vez de basarnos en los cálculos de la Table 28 para decidir la velocidad de
procesamiento de las colas, lo hicimos en función del número de mensajes que estas
rutaban. Así para la cola AN-QoSBroker el tiempo fue de 0.066 s/mensajes y para las
otras 3 (MN, AN-AA, CN-MMSP) de 0.033 s/mensajes. El total es, como en la Table
28, igual a 4*0,0417 s / mensaje. Los resultados en ambos experimentos fueron muy
similares entre sí y a las anteriores pruebas. El tercer experimento usó los valores de la
Table 28 pero permutando el tiempo de la cola del MN y la del AN-QoSBroker. En este
caso si observamos una ligera diferencia. Pasamos de 2,3 s de media de tiempo de
establecimiento a 2,4 (aproximadamente 5% más). Esto viene a demostrar nuestra
hipótesis: lo importante es ampliar la capacidad de proceso del AN-MMSP, más que
elegir cuidadosamente la distribución de ésta entre las colas. Aún así, si el reparto se
hace mal se pueden perder prestaciones, tal como hemos visto en la tercera prueba.
- 184 -
Validación
Toda nuestra discusión se ha centrado en torno al AN-MMSP, además este nodo
era el que tenía un comportamiento más diferente entre las estrategias MMSP y MN,
acuciando mucho más los efectos del pico de llamadas en la estrategia MMSP. Era este
nodo el principal causante de las diferentes “prestaciones” de las dos estrategias. Es por
lo tanto lógico que lo estudiemos. Vemos en la Figure 75 como el comportamiento del
AN-MMSP prácticamente no acusa el pico de llamadas, al igual que pasaba en la
estrategia MN anteriormente. Además, si observamos el comportamiento de este mismo
nodo pero en la estrategia MN, estos son muy similares.
Cada punto es un mensaje. Pico de llamadas. Estrategia MMSP. 4 colas en
AN-MMSP
Tiempo de procesamiento (s)
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
12
22
32
42
52
62
72
82
Instante de entrada del mensaje (s)
Figure 75 Tiempo de procesamiento de los mensajes en el AN-MMSP. Pico de llamadas y 4
colas en el AN-MMSP. Estrategia MMSP
Con 4 colas en el AN-MMSP los únicos nodos que “sufren” las consecuencias
del pico de llamadas son los CN y de forma muy similar en ambas estrategias. Es por
esto que en las dos el tiempo de llamada sigue una variación similar.
Por último, realizamos una prueba poniendo el tiempo de proceso del nodo más
lento (el AN-QoSBroker) a 0 s/mensaje. Usamos sólo una cola en la AN-MMSP con
una tasa de 0,0417 s/mensaje. En este caso el tiempo de establecimiento de llamada
sigue un comportamiento muy parecido al descrito en la sección 6.3.2. Cambian, sin
embargo, las medias del tiempo de establecimiento –en condiciones estables-. Para la
estrategia MMSP tenemos 2,54 s y para la MN 1,77. En el primer caso se ganan unos
0,50 s que coincide con el tiempo que antes perdía una llamada en que se procesasen los
mensajes en el AN-QoSBroker. En el segundo caso se gana más que 0,5 s, 0,65 s.
La conclusión final que podemos extraer de este estudio es que en la estrategia
MMSP el cuello de botella es el AN-MMSP pues la capacidad de proceso de este etá
calculada para soportar el escenario MN donde gestiona menos mensajes. La solución
es aumentar su capacidad de procesamiento. En cambio, en el caso MN el cuello de
botella es el AN-QoSBroker esta vez porque es el nodo más lento.
- 185 -
A. Cuevas
Tesis Doctoral
6.3.4 Momento de realización de la reserva de QoS
Todas las anteriores pruebas las hemos realizado siguiendo una secuencia de
intercambio de mensajes que hace que el llamante empiece la reserva de QoS cuando
recibe el mensaje “200 OK” del llamado. Pero hemos propuesto en la sección 5 como el
llamante puede hacer su reserva al recibir el mensaje Session Progress. Estas pruebas
mostrarán la influencia de este aspecto. Las pruebas se hicieron para las dos estrategias
MN y MMSP y para una sola cola de llamadas en el AN-MMSP o para 4 colas. Los
resultados son como en los anteriores pero aquí la media es unos 0,25 s menor. Este
valor coincide con el tiempo de proceso del AN-QoSBroker. Este tiempo se gana por no
tener que esperar a recibir el 200 OK (que implica que el llamado haya hecho la reserva
con el QoSBroker) para que el llamante puede comenzar a realizar “su” reserva de QoS.
La Table 29 resume los resultados de esta sección (las dos columnas de la
derecha) y los compara con los obtenidos anteriormente. Con las etiquetas “serie” nos
referimos al caso en el que el nodo llamante espera a recibir el mensaje “200 ok” del
nodo llamado y con las etiquetas “paralelo” al otro caso, cuando tan solo espera a recibir
el mensaje “183 session progress”.
Estrategia MMSP
Estrategia MN
“serie” 1 cola
3s
2,4 s
“serie” 4 colas
2,3 s
2,1 s
“paralelo” 1 cola
2,76 s
2,11 s
“paralelo” 4 colas
1,97 s
1,84 s
Table 29 tiempos medios de establecimiento de llamada –en condiciones estables-.
6.4 Conclusión
Con estas pruebas hemos puesto de manifiesto ciertos aspectos de nuestra
arquitectura. Debemos recalcar que la simulación aquí planteada es pionera a la hora de
investigar arquitecturas completas de redes 4G y de establecimiento de sesión; los
trabajos anteriores se centran es aspectos aislados [CAM03], [SAL02]. Por lo tanto, los
resultados obtenidos definen una metodología de planificación de redes 4G. Los más
importantes están resumidos a continuación.
Primero, al haber un número grande de nodos involucrados en el
establecimiento de sesión y tener estos unas características muy diferentes se pueden
formar cuellos de botella si no se distribuyen bien los tiempos de proceso. Segundo, el
cálculo analítico de la capacidad de proceso individual de cada nodo no es suficiente
para dimensionar la red puesto que las numerosas interacciones entre ellos rebajan la
capacidad de la red. También hemos comprobado como gracias a tener una arquitectura
jerarquizada, sólo los nodos centrales sufren efectos como picos de llamadas. El resto
(nodos AN) al gestionar menos mensajes sufren menos estos efectos.
Además, parte de nuestra arquitectura ha sido implementada en un escenario de
red 4G IPv6 nativo [SAN05]. Se pudo comprobar en ese prototipo la viabilidad y
utilidad de las soluciones propuestas.
- 186 -
7.
Conclusions and Future Work
This thesis has addressed one of the topics still to be solved in the coming 4G
networks: session setup integrating both application and transport layers and using the
network infrastructure not only as a bit pipe but also as broker of services and sessions.
While there is much research work done in 4G networks, many aspects of this huge and
hot field still have to be covered, among them the session setup issues addressed in this
thesis.
The biggest endeavour we had to address is that in 4G networks the users’
mobile devices will be like another IP host connected to the Internet. In such a scenario,
the network operator infrastructure will be degraded to bit pipes. Finding adequate
solutions, like turning the network into an aggregator of services, is key to overcome
this problem that, otherwise, may obstruct the development of 4G networks. However,
the Internet model of complete separation of application and transport must be kept.
Facing these two contradictory aspects was the big challenge of this thesis.
To meet this challenge we concentrated on the co-operation between the
different sub-services (including transport service) and business entities. The ways to
orchestrate the various systems and nodes have been either proposed and evaluated or,
when available, used, analysed and adapted to our framework. We designed the session
setup interactions between some of the pillars of 4G networks: QoS, AAA, and SIP
proxies infrastructure (MMSP). We proposed several approaches for several scenarios,
compared and evaluated them (including by the means of simulation) and designed the
mechanisms for their coexistence.
To meet our objectives, we first undertook a deep state-of-the art analysis
identifying research opportunities but also profitable solutions. We found that much
work has been carried out in the research fields related to this thesis and that, even,
some of the solutions are standardized and have great commercial acceptance (e.g. SIP).
However there is not a “glue” integrating all this in a 4G framework. We saw that, for
3G networks, the 3GPP-defined IMS framework integrates some of these solutions
under a coherent “umbrella” and achieves a business model that places the network
operator in the core of the business value chain. But we identified some issues that need
to be enhanced in order to make the IMS solution profitable for 4G networks. Those
were mainly the support of native IP networks with any access technology (and not only
- 187 -
A. Cuevas
Tesis Doctoral
CDMA) and allowing the coexistence of several scenarios and business models under a
single framework. This thesis overcomes these problems.
We focused on the session concept and identified the several actors that can
create or manage sessions. Those were the users, the service providers, the “mediators”
(e.g. SIP proxies) and the network provider. The network provider itself can deal with
sessions in several ways: its transport system will create QoS-enabled transport
sessions, its AAA system will centralize all the sessions created by all the actors (semiwalled garden business model) and we also considered network access sessions handled
by the AAA system.
We showed the advantages of considering QoS-enabled data transport as
another service and not as a service parameter like IMS does. As Deutsche Telekom
President said, in the future data transport won’t longer be a commodity, it will need to
be “differentiated”. Our proposal allows the fine control this scenario requires. It eases
the network operator in managing the QoS-enabled data transport and all the
components interworking to build the final service. In the scenario forecasted by
Deutsche Telekom President, there are some issues to solve respect to handle
efficientlty differentiated QoS-enabled data transport. For instance, users like simple
tariffs (e.g. flat-rates) and we must avoid situations like: “streaming news services with
discount from 21:00 to 8:00 that uses AF11 transport service with discount from 22:00
to 9:00.” In such a case the medium user will not understand how much does he pay.
We must also find ways to determine the final QoS to give to a session (e.g. audio call)
between two users with different profiles stating different quality preferences. The
thesis proposals coped with these issues.
We must note that, as a service, data transport may be priced and depend on
user’s profiles, and this will influence session setup techniques.
We proposed to include cost sharing aspects in the session description
languages. This allows the peers to better negotiate sessions in scenarios where the QoS
enabled data transport is to be paid and, as such, is an important piece to help solving
the problems above presented.
Other aspects were also addressed to enhance existing session setup techniques
such as including preference levels in the negotiated configurations. We saw the
advantages of doing so, speeding the whole session setup process.
These improved session setup techniques was one of the objectives of this thesis.
We will see next how our further proposals benefit from these achievements.
Our session setup solutions and the scenarios they enable are to be supported by
4G networks. We analyzed existing 4G networks architectures, identified their gaps and
designed an infrastructure capable of hosting our solutions. We evaluated such an
infrastructure including test bed measurements and integrating aspects such as QoS
and mobility. This was one of our main objectives. To design our service platform, we
concentrated on three systems MMSP (SIP Proxies), QoS enabled data transport, AAA
and the interfaces between the network operator and the service providers. IMS was a
good source for ideas.
- 188 -
Scalability was one of the main concerns and we followed the idea of “pushing”
finer control to the network edges closest to the users –access networks (ANs)-. This
approach is “common”, for instance it is followed in IMS; we shall see next our
contributions and how we take advantage of this “tactic”.
The interfaces between the systems (MMSP, AAA and QoS) where pushed to
the ANs. The nodes in the ANs had autonomy to take some decisions not involving the
nodes centralizing user and service management, located in the CN (core network). For
instance, thanks to SAML and transferring user profiles, we could delegate
Authorization and Accounting to the servers present in the AN. This decentralization
of the AAA system is key to allow scalability. QoS-enabled data transport complexity
was also pushed to the ANs following the “classical” IntServ and DiffServ interworking
or, more accurately, employing DiffServ in the CN with per flow access control in the
ANs. We proposed to do this access control not only for “upstream packets” but also
for the packets directed to the terminals. That way we better “track” the flows despite
having a scalable DiffServ CN.
We suggested the AN’s QoS Broker’s role to be more than a policy decision
point (like the IMS’ PDF is). QoS Brokers should handle all the data transport service
within their AN, keeping state of the flows. That way the interaction between the
QoSBroker and the MMSP or the service providers is richer than in IMS and we saw
how to take advantage of this. A clear scenario is adapting to changes in network
conditions because the user hands over to a less performing access network. We showed
how to involve Content Adaptation nodes or change the communication codecs in such
a scenario. Note that the IMS can do so, but only at the session setup, not while the
session is running.
The interfaces from the network operator (AAA server and QoS Broker) to the
service providers were designed supporting several possible scenarios in function of the
type of agreement between the network and service providers.
We found that a key to support more interactions scenarios between service
providers, users, and network providers’ AAA, QoS-enabled transport and MMSP
systems was designing an interaction between QoS and AAA. Since we are considering
QoS-enabled transport system as another service, this QoS to AAA interaction is
necessary to provide this service with AAA capabilities. This QoS-AAA interaction
was one of our main contributions in refining current 4G architectures. The idea is to
treat QoS enabled data transport as any other service requesting AAA services and
specializing the AAA system in user control and the QoS system in network control.
A unified format of AAA infrastructure and services interaction was proposed
using SAML and the possibilities of distributing user profiles or just authorization
decisions analyzed and found the best outcome for the different scenarios. Aspects like
single sign-on and unified billing are supported in our design.
We achieved coherence in the session(s) and still coped with heterogeneity in
QoS-enabled transport session setup. For instance, scenarios where one peer uses
RSVP as transport session setup protocol and the other peer asks the AN-MMSP to
setup the QoS session, have been addressed. Again, this widens the applicability of our
proposal. We always bear in mind scalability concerns in our suggested solutions.
- 189 -
A. Cuevas
Tesis Doctoral
Evaluation of our architecture and of our different proposals was one of our
main objectives and was addressed in this thesis. The evaluation criteria have included
aspects such as scalability or user’s privacy. In some issues we have resorted to
simulation results and we have proposed a methodology to cope with some planning
challenges that may appear in future 4G networks with many interacting nodes with
different characteristics (such as processing speed). Aspects such as bottlenecks could
be identified in our ns2 simulation model and the possible methods to cope with them
were suggested and evaluated.
Fulfilling all our objectives and sub-objectives has lead to a complete integrated
architecture supporting several possibilities for different scenarios in session setup. The
“semi walled garden” business model has been followed while pure “Internet” model
applications are also supported, as it was our aim. The integration of several scenarios
and business models under a single, coherent framework is one of our major
achievements compared to IMS.
7.1
Research avenues and forecast for our proposal
Our solution is complete but was specialised in MMSP, AAA and QoS
interactions and some aspects have not been tackled, such as mobility or multiparty
sessions. Also we think our design can serve as the basis of future developments upon
it, such as multicast or anonimization.
Mobility is well supported thanks to Mobile IPv6 or SIP procedures. Also SIP
and SDP are ready to support multiparty sessions. So we think those two aspects should
not be difficult to integrate in our solution since it is based in IP. Some issues have been
addressed, others can be covered by, for instance, current research work such as
Diameter Mobile IPv6 application. This application should help to handle one problem
when dealing with SIP and MIP: doing the registration either with the HoA or CoA
[FAC04].
Multiparty sessions is another interesting topic to deal with. This is well
addressed by current SIP/SDP solutions and the MMSP, AAA and QoS interactions
designed in this thesis could just be “replicated” in each party to support multiparty
scenarios. In such situations, the cost sharing aspects proposed in this thesis are of
special relevance, for instance if two persons are talking and they decide to call a third
one, who should pay for the cost of having this extra person in the conversation?
The anonimization of the user is also a very interesting research topic since it
aims to satisfy two contradictory requirements. On one side, users are very kind of the
single sign-on feature provided by in our design, on the other side, they do not want to
be tracked on their various activities (services consumption). Again, current research
works are addressing these issues [HAS04]. Their approaches are based on AAA
architectures like the one presented in this thesis.
Multicast based on transport QoS, users’ profiles and device capabilities could
also be integrated in our framework. One may think adding content adaptation to our
framework. For instance, one user may send only one high quality stream, a multicast
tree is created and some branches of the multicast tree are diverted to the content
adaptation nodes. Those branches will be then able to reach nodes with low BW access
technologies, while the other nodes would receive the high quality stream. This is just
- 190 -
another example of the possible research avenues and the possibilities that our design
has to integrate and support future developments.
In our world, user preference determines all the aspects in the business. For
instance, since users prefer and are willing to pay more for direct flights rather than stop
flights, the former are more expensive although they generate fewer costs to the airline.
All our proposed infrastructure and business models are not an exception. They will
succeed if users find any advantage employing the services enabled by our framework
compared to applications that just use the network provider as a bit pipe. These
advantages are richer and better services and this thesis’ proposals create a very good
platform to provide them. Still these services have to be found. But the advantage can
also be cost sparing. In such a case the question is whether the networks operators will
build such an infrastructure just to compete in price. They may do so, since that way
they control better the customer relationship. Taking these two aspects into account, we
forecast that the solutions here presented or similar ones will be adopted in the future
4G networks.
- 191 -
8.
Referencias
[3GPP]
“3rd Generation Partnership Project” www.3gpp.org
[BOS02]
L. Bos et al. “SDPng extensions for Quality of service negotiation”,
IETF Internet-Draft, Work-in-progress, September 2002 <draftbos-mmusic-sdpng-QoS-00.txt >.
[BOU02]
Julien Bournelle et. al, « Adaptation et implémentation de
Diameter/AAA pour Mobile IPv6 ». Proceeding of the DNAC
2002, Décembre 2002, Paris
[BRI03]
Bob Briscoe et al. “A Market Managed Multi-service Internet
(M3I)” Computer Communications 26 (4) February, 2003.
[CADENUS]
Creation and Deployment of End-UserServices in Premium IP
Networks http://wwwcadenus.fokus.fraunhofer.de/
[CAL01]
Pat R. Calhoun et al. “Diameter Strong Security Extension”
Internet-Draft Work-in-progress, March 2001. <draft-calhoundiameter-strong-crypto-07.txt>
[CAL05]
Andrea Calvagna et al. “Mobility and quality of service across
heterogeneous wireless networks” in Computer Networks 47
(2005)
[CAM01]
Gonzalo Camarillo “SIP Demystified” McGraw-Hill, 2001, ISBN:
0071373403
[CAM03]
Gonzalo Camarillo et al. “Evaluation of Transport Protocols for the
Session Initiation Protocol”. IEEE Network. September/October
2003
[CAM04]
Gonzalo Camarillo, Miguel-Angel Garcia-Martin “The 3G IP
Multimedia Subsystem (IMS): Merging the Internet and the
Cellular Worlds” John Wiley & Sons (August, 2004) ISBN:
0470871563
- 193 -
A. Cuevas
Tesis Doctoral
[CAM05]
Gonzalo Camarillo, “SIP: an standardization update” Invited Talk
in EUNICE 2005, 11th Open European Summer School. July 6-8,
Colmenarejo (Spain). http://www.it.uc3m.es/eunice2005/talks.html
[CDI05]
Diario Cinco Días “Las nuevas telefónicas vienen de internet” Luz
Fernández / Mar Jiménez / MADRID (16-09-2005)
[COM05]
Mohamed Atiquzzaman, Mohsen Guisan “The Next-Generation
Internet” Guest Editorial IEEE Communications Magazine, May
2005
[COMS]
Cambridge
Open
Mobile
System
(COMS)
http://www.cl.cam.ac.uk/Research/SRG/netos/coms/
[COR03]
Giovanni Cortese et.al. “CADENUS: Creation and Deployment of
End-User Services in Premium IP Networks”, IEEE
Communication Magazine Vol.41 No.1, January 2003.
[CUE03]
Antonio Cuevas et al. “Mechanisms for AAA and QoS Interaction"
ISBN: 3-9522719-0-X. 3rd Workshop on Application and Services
in Wireless Networks, Bern, Switzerland, July 2003
[CUE05]
Antonio Cuevas et al. “Usability and Evaluation of a Deployed 4G
Network Prototype”, Journal of Communications and Networks,
Volume 7, Number 2, June 2005
[ES282001]
ES 282 001 v1.1.1, ETSI, “Overall functional architecture” August
2005
[ESC02]
J. Escribano, C. García, J.I. Moreno, C. Seldas “Diffserv como
solución a la provisión de QoS en Internet” II Congreso
Iberoamericano de Telemática,CITA'2002. ISBN 980-237-217-X.
[FAC04]
Stefano M. Faccin, “IP Multimedia Services: Analysis of Mobile IP
and SIP Interaction in 3G Networks” IEEE comm. magazine
January 2004
[FAN98]
George Fankhauser et al. “Revervation-based Charging in an
Integrated Services Network”, 4th INFORMS Telecommunications
Conference, Boca Ratón, Florida USA, March 1998”
[FOMA]
Freedom
of
Mobile
Multimedia
Access
http://www.nttdocomo.com/technologies/present/fomatechnology/i
ndex.html
[FOR04]
D. Forsberg, Y. Ohba: “Protocol for Carrying Authentication for
Network Access (PANA)”, work in progress, IETF Internet Draft,
draft-ietf-pana-pana-03.txt, February 2004.
[GAR05]
draft-ietf-aaa-diameter-sip-app-10, M. Garcia_Martin et al., AAA
Working Group, “Diameter Session Initiation Protocol (SIP)
Application”, October 2005
- 194 -
project.
Referencias
[GRO01]
G. Gross et al. Internet Draft “QoS and AAA Usage with SIP
Based IP Communications” April 2001.
[HAS04]
Daidalos deliverable D341 A4C Framework Design Specification
Aug 04
[HEC02]
O. Heckmann et al., Internet Draft, “Tarif Distribution Protocol
(TDP)”, March 2002
[LIE01]
Marco Liebsch et al. Internet Draft, „Paging Concept for IP based
Networks“, September 2001.
[JAN03]
Jan Janák “SIP Proxy Server Efectiveness” Master's Thesis. Czech
Technical University Faculty Of Electrical Engineering Department
Of Computer Science Prague, 21st May 2003
[LE04]
draft-le-aaa-diameter-mobileipv6-04.txt Franck Le et al. AAA
Working Group “Diameter Mobile IPv6 Application” November
2004
[GAR03]
"QoS en Redes Móviles de Cuarta Generación", Carlos García,
Pedro Antonio Vico, Antonio Cuevas, Ignacio Soto, Jose Ignacio
Moreno, JITEL 2003, Gran Canaria, Spain, September 2003.
ISBN: 84-96131-38-6
[GIO03]
S. Giordano et al. “Managing Multimedia Traffic in IP Integrated
over Differentiated Services: SIP dynamic signalling interworking” in IEEE’s HICSS’03, 2003
[GOM04]
“A transsignalling strategy for QoS support in heterogeneous
networks” Diogo Gomes et al. Proc International Conf. on
Telecommunications - ConTEL , Fortaleza , Brazil , Vol. 1 , pp.
1114 - 1121 , August , 2004
[GRO05]
"Assessing speech quality: a new approach" Laeticia Gros et al.
ForumAcusticum, Budapest August-September 2005.
[GU02]
X. Gu et al., “An XML-Based Quality of Service Enabling
Language for the Web”, Journal of Visual Language and
Computing, special issue on multimedia languages for the Web,
vol. 3, no. 1, Feb, 2002.
[HOW05]
Michale P. Howarth et al. in “Provisioning for Interdomain Quality
of Service, the MESCAL Approach” IEEE Communications
Magazine, June 2005
[IMODE]
i-mode http://www.nttdocomo.com/corebiz/services/imode/
[IPTEL]
NIST. IPTel Project. http://dns.antd.nist.gov/proj/iptel/
[JÄH04]
Juergen Jaehnert, Jie Zhou, Rui L. Aguiar, Victor Marques,
Michelle Wetterwald, Eric Melin, Jose I. Moreno, Antonio
- 195 -
A. Cuevas
Tesis Doctoral
Cuevas_Casado, Marco Liebsch, Ralf Schmitz, Piotr Pacyna,
Telemaco Melia, Pascal Kurtansky, Hasan, Davinder Singh,
Sebastian Zander, Burkhard Stiller "Moby Dick: A Pure-IP 4G
Architecture" Computer Communications Vol 28/9 pp 1014-1027,
December 2004
[JIN04]
Jingwen Jin et al., “QoS specification languages for distributed
multimedia applications: a survey and taxonomy” IEEE
Multimedia, Volume: 11, Issue: 3, Date: July-Sept. 2004
[JOH03]
Alan B. Johnston “SIP: Understanding the Session Initiation
Protocol” Artech House Publishers; 2nd edition (November, 2003)
ISBN: 1580536557
[KUR04]
Pascal Kurtansky, Hasan, Burkhard Stiller Davinder Singh,
Sebastian Zander, Antonio Cuevas, Jürgen Jähnert, Jie Zhou,
“Extensions of AAA for Future IP Networks” WCNC 2004,
Atlanta, USA, 2004.
[LI04]
Tianshu Li et al. “Pricing and admission control for QoS-enabled
Internet” Computer Networks 46, 2004
[LO04]
Shou-Chih Lo et al. “"Architecture for mobility and QoS support in
all-IP wireless networks"” in IEEE Journal on selected areas in
communications vol. 22 no.4 may, 2004
[LONG]
“Laboratories over Next Generation Networks”, IST Project.
http://long.ccaba.upc.es/
[MIND]
“Mobile IP-based Network
http://www.mind-project.org/
[MIND02]
MIND Project, “Top-level architecture for providing seamless
QoS, security, accounting and mobility to applications and
services”, Deliverable D1.2, November 2002, http://www.istmind.org/deliverables.htm
[MOBYDICK]
Moby Dick: “Mobility and Differentiated Services in a Future IP
Network”, IST Project. http://www.ist-mobydick.org.
[MUN05]
Diario El Mundo, 8th February 2005, Diario del Navegante,
Ariadna
[N5845]
MPEG MDS Group, MPEG-21 Multimedia Framework, Part 7:
Digital Item Adaptation (Final Committee Draft), ISO/MPEG
N5845, July 2003;
[NAH95]
K. Nahrstedt et al. „The QoS Broker“, IEEE MultiMedia, vol. 2, no
1, 1995.
[NS2]
Network Simulator 2 http://www.isi.edu/nsnam/ns/
- 196 -
Developments”,
IST
project.
Referencias
[OPNET]
OPNET Technologies http://www.opnet.com.
[OTT05]
draft-ietf-mmusic-sdpng-09.txt, Joer Ott et al., Network Working
Group, “Session Description and Capability Negotiation”,
September 2005
[OVERDRIVE]
OverDRiVE: “Spectrum Efficient Uni- and Multicast Services over
Dynamic Multi-Radio Networks in Vehicular Environments”, IST
Project. http://www.ist-overdrive.org
[PAN04]
Vijoy Pandey, „Exploiting User Profiles to Support Differentiated
Services in Next-Generation Wireless Networks“, IEEE Network,
September/October 2004
[PAP02]
D. Papalilo, S.Salsano, L.Veltri, “Extending SIP for QoS support”,
Joint Planet-IP NEBULA workshop, Courmayeur, 2002.
[POI04]
Poikselkä, Miikka “The IMS : IP multimedia concepts and services
in the mobile domain” Wiley & Sons ISBN: 047087113X (2004)
[RAM03]
Ramaswamy et al. “Considering Processing Cost in Network
Simulations”. ACM SIGCOMM 2003 Workshops, August
25&27,2003, Karlsruhe, Germany. Copyright 2003 ACM 1-58113748-6/03/0008
[RFC1445]
RFC1445 Administrative Model for version 2 of the Simple
Network Management Protocol (SNMPv2). J. Galvin, K.
McCloghrie. April 1993.
[RFC1190]
RFC1190 C. Topolcic, “Experimental Internet Stream Protocol,
Version 2 (ST-II)”, Oct. 1990,
[RFC1819]
RFC1819 L. Delgrossi and L. Berger, “Internet Stream Protocol
Version 2 (ST2) Protocol Specification — Version ST2+,” Aug.
1995,
[RFC1663]
RFC 1663, R. Braden et al., Network Working Group, “Integrated
Services in the Internet Architecture: an Overview”, June 1994
[RFC2205]
RFC 2205, R. Braden et al., Network Working Group, “Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification” September 1997
[RFC2326]
RFC 2326, H. Schulzrinne et al., Network Working Group, “Real
Time Streaming Protocol (RTSP)”, April 1998.
[RFC2327]
RFC 2327, M. Handley et al., Network Working Group, “SDP:
Session Description Protocol”, April 1998
[RFC2409]
RFC 2409, D. Harkins et al., Network Working Group, “The
Internet Key Exchange (IKE)”, November 1998
- 197 -
A. Cuevas
Tesis Doctoral
[RFC2474]
RFC 2474, Nichols, K. et. al. “Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers”. 1998.
[RFC2475]
RFC 2475,
S. Blacke et al., Network Working Group, “An
Architecture for Differentiated Services”, December 1998
[RFC2486]
RFC 2486 B. Aboba et al. « The Network Access Identifier »,
January 1999
[RFC2597]
RFC 2597 Heinanen, J. et. al. “Assured Forwarding PHB Group”.
1999
[RFC2598]
RFC2598 Jacobson, V. et. al. “An Expedited Forwarding PHB”.
1999
[RFC2638]
RFC 2638, K. Nichols et al., Network Working Group, “A Two-bit
Differentiated Services Architecture for the Internet”, July 1999
[RFC2748]
RFC 2748, D. Dirham et al., Network Working Group “The COPS
(Common Open Policy Service) Protocol” January 2000
[RFC2749]
RFC 2749, S. Herzog et al., Network Working Group “COPS usage
for RSVP” January 2000
[RFC3015]
RFC 3015, F. Cuervo et al., Network Working Group “Megaco
Protocol Version 1.0”, November 2000
[RFC3084]
RFC 3084, K. Chan et al., Network Working Group “COPS Usage
for Policy Provisioning (COPS-PR)”. March 2001
[RFC3127]
RFC3127, D. Mitton et al., Network Working Group
“Authentication, Authorization, and Accounting: Protocol
Evaluation” June 2001
[RFC3132]
RFC 3132, J. Kempf, Network Working Group “Dormant Mode
Host Alerting ("IP Paging") Problem Statement”, June 2001
[RFC3261]
RFC 3261, J. Rosenberg et al., Network Working Group, “SIP:
Session Initiation Protocol”, June 2002
[RFC3262]
RFC 3262, J. Rosenberg et al., Network Working Group,
“Reliability of Provisional Responses in the Session Initiation
Protocol (SIP)”, June 2002
[RFC3263]
RFC 3263, J. Rosenberg et al., Network Working Group, “Session
Initiation Protocol (SIP): Locating SIP Servers”, June 2002
[RFC3264]
RFC 3264, J. Rosenberg et al., “An Offer/Answer Model with the
Session Description Protocol (SDP)”, June 2002
- 198 -
Referencias
[RFC3312]
RFC 3312, G. Camarillo et al., Network Working Group, “Update
to the Session Initiation Protocol (SIP) Preconditions Framework”
March 2005
[RFC3550]
RFC 3550, H. Schulzrinne et al., Network Working Group, “RTP:
A Transport Protocol for Real-Time Applications”, July 2003
[RFC3588]
RFC 3588 P. Calhoun et al., Network Working Group, “Diameter
Base Protocol” September 2003
[RFC3589]
RFC 3589, J. Loughney, Network Working Group “Diameter
Command Codes for Third Generation Partnership Project (3GPP)
Release 5” September 2003
[RFC3702]
RFC 3702, J. Loughney, Network Working Group,
“Authentication, Authorization, and Accounting Requirements for
the Session Initiation Protocol (SIP)”, February 2004.
[RFC3775]
RFC 3755, D. Johnson, Network Working Group, “Mobility
Support in IPv6”, June 2004
[RFC3986]
RFC 3986, T. Berners-Lee, Network Working Group, “Uniform
Resource Identifier (URI): Generic Syntax”, January 2005
[RFC4006]
RFC 4006, H. Hakala et al., Network Working Group, “Diameter
Credit-Control Application”, August 2005.
[RFC4004]
RFC 4004, P. Calhoum, Network Working Group, “Diameter
Mobile IPv4 Application”, August 2005
[RFC4005]
Network Access Server Application”, August 2005
[RFC4016]
RFC 4016, M. Parthasarathy, Network Working Group, “Protocol
for Carrying Authentication and Network Access (PANA)
Threat Analysis and Security Requirements”, March 2005
[RFC4068]
RFC 4068, R. Koodli, Network Working Group, “Fast Handovers
for Mobile IPv6”, July 2005
[RFC4072]
RFC 4072, P. Eronen et al., “Diameter Extensible Authentication
Protocol (EAP) Application” August 2005
[RFC4140]
RFC 4140, H. Soliman et al. Hierarchical Mobile IPv6 Mobility
Management (HMIPv6), August 2005
[ROB04]
J.W. Roberts “Internet Traffic, QoS, and Pricing, Proceedings of
the IEEE, Vol 92, No 9. September 2004”
[RUI04]
P. Ruiz, et al., “Adaptive Multimedia Multi-party Communication
in Ad Hoc Environments”, HICSS-37, Software Technology Track,
January 2004
- 199 -
A. Cuevas
Tesis Doctoral
[SAL02]
Stefano Salsano “SIP Security Issues: The SIP Authentication
Procedure and its Processing Load” IEEE Network
November/December 2002
[SAN05]
"Integración de servicios multimedia en redes 4G" R. Sánchez
Martín, A. Cuevas Casado, J. I. Moreno Novella, P. A. Vico Solano
V Jornadas de Ingeniería Telemática. Vigo, Spain, Septiembre
2005, ISBN: 84-8408-346-2
[SAR03]
Susana Sargento, et al. , “IP-based Access Networks for Broadband
Multimedia Services”, IEEE Communications Magazine, Special
Issue em Broadband Access, February 2003,
[SCH02]
Mobile Europe 2002, Bremen 18 Mobile Europe 2002, Bremen
18th th March 2002 March 2002 Peter Schoo A Wireless Vision for
2010 in Japan
[SCH04]
Gereo Schollmeier et al. “Providing Sustainable QoS in NextGeneration Networks” in IEEE Communications Magazine June
2004
[SCU02]
SIPstone - Benchmarking SIP Server Performance Henning
Schulzrinne et al. Columbia University, Ubiquity.
[SIN01]
Henry Sinnreich, Alan B. Johnston “Internet Communications
Using Session Initiation Protocol: Delivering VoIP and Multimedia
Services with Session Initiation Protocol” Wiley, 2001. ISBN: 0471-41399-2
[SPI02]
SPIEGEL ONLINE - 02. Februar 2006
[TR32815]
TR 32.815, 3GPP, “Telecommunication management; Charging
management; Online Charging System (OCS) architecture study”
[TS23207]
TS 23.207 3GPP “End-to-end Quality of Service (QoS) concept
and architecture (Release 6)” September 2005.
[TS23228]
TS 23.228 3GPP “IP Multimedia Subsystem (IMS); Stage 2
(Release 7)” December 2005.
[TS29198]
TS 29.198 3GPP “Open Service Architecture (OSA) Application
Programming Interface (API)”
[TS32200]
TS 32.200, 3GPP, “Telecommunication management; Charging
management; Charging principles”
[TS32240]
management; Charging architecture and principles”
[WAN02]
L.Wang, V.Pai, and L.Peterson. The effectiveness of request
redirection on CDN robustness. In Proceedings of the Fifth
- 200 -
Referencias
Symposium on Operating Systems Design and Implementation
Boston, MA, dec 2002.
[WIR04]
Theodore B. Zahariadis “Migration Toward 4G Wireless
Communications”
GUEST EDITORIAL, IEEE Wireless
Communications, June 2004.
[WIW06]
WirtschaftsWoche, 23 februar 2006
[XIE04]
J. Xie, `Ùser independent paging scheme for Mobile IP,'' ACM
Journal of Wireless Networks (WINET), 2004.
- 201 -
A. Cuevas
Tesis Doctoral
Ordenadas por formato
•
Libros
[CAM01]
Gonzalo Camarillo “SIP Demystified” McGraw-Hill, 2001, ISBN:
0071373403
[CAM04]
Gonzalo Camarillo, Miguel-Angel Garcia-Martin “The 3G IP
Multimedia Subsystem (IMS): Merging the Internet and the
Cellular Worlds” John Wiley & Sons (August, 2004) ISBN:
0470871563
[JOH03]
Alan B. Johnston “SIP: Understanding the Session Initiation
Protocol” Artech House Publishers; 2nd edition (November, 2003)
ISBN: 1580536557
[POI04]
Poikselkä, Miikka “The IMS : IP multimedia concepts and services
in the mobile domain” Wiley & Sons ISBN: 047087113X (2004)
[SIN01]
Henry Sinnreich, Alan B. Johnston “Internet Communications
Using Session Initiation Protocol: Delivering VoIP and Multimedia
Services with Session Initiation Protocol” Wiley, 2001. ISBN: 0471-41399-2
•
RFCs y otros éstandares
[RFC1445]
RFC1445 Administrative Model for version 2 of the Simple
Network Management Protocol (SNMPv2). J. Galvin, K.
McCloghrie. April 1993.
[RFC1190]
RFC1190 C. Topolcic, “Experimental Internet Stream Protocol,
Version 2 (ST-II)”, Oct. 1990,
[RFC1819]
RFC1819 L. Delgrossi and L. Berger, “Internet Stream Protocol
Version 2 (ST2) Protocol Specification — Version ST2+,” Aug.
1995,
[RFC1663]
RFC 1663, R. Braden et al., Network Working Group, “Integrated
Services in the Internet Architecture: an Overview”, June 1994
[RFC2205]
RFC 2205, R. Braden et al., Network Working Group, “Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification” September 1997
[RFC2326]
RFC 2326, H. Schulzrinne et al., Network Working Group, “Real
Time Streaming Protocol (RTSP)”, April 1998.
[RFC2327]
RFC 2327, M. Handley et al., Network Working Group, “SDP:
Session Description Protocol”, April 1998
- 202 -
Referencias
[RFC2409]
RFC 2409, D. Harkins et al., Network Working Gropu, “The
Internet Key Exchange (IKE)”, November 1998
[RFC2474]
RFC 2474, Nichols, K. et. al. “Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers”. 1998.
[RFC2475]
RFC 2475,
S. Blacke et al., Network Working Group, “An
Architecture for Differentiated Services”, December 1998
[RFC2486]
RFC 2486 B. Aboba et al. « The Network Access Identifier »,
January 1999
[RFC2597]
RFC 2597 Heinanen, J. et. al. “Assured Forwarding PHB Group”.
1999
[RFC2598]
RFC2598 Jacobson, V. et. al. “An Expedited Forwarding PHB”.
1999
[RFC2638]
RFC 2638, K. Nichols et al., Network Working Group, “A Two-bit
Differentiated Services Architecture for the Internet”, July 1999
[RFC2748]
RFC 2748, D. Dirham et al., Network Working Group “The COPS
(Common Open Policy Service) Protocol” January 2000
[RFC2749]
RFC 2749, S. Herzog et al., Network Working Group “COPS usage
for RSVP” January 2000
[RFC3015]
RFC 3015, F. Cuervo et al., Network Working Group “Megaco
Protocol Version 1.0”, November 2000
[RFC3084]
RFC 3084, K. Chan et al., Network Working Group “COPS Usage
for Policy Provisioning (COPS-PR)”. March 2001
[RFC3127]
RFC3127, D. Mitton et al., Network Working Group
“Authentication, Authorization, and Accounting: Protocol
Evaluation” June 2001
[RFC3132]
RFC 3132, J. Kempf, Network Working Group “Dormant Mode
Host Alerting ("IP Paging") Problem Statement”, June 2001
[RFC3261]
RFC 3261, J. Rosenberg et al., Network Working Group, “SIP:
Session Initiation Protocol”, June 2002
[RFC3262]
RFC 3262, J. Rosenberg et al., Network Working Group,
“Reliability of Provisional Responses in the Session Initiation
Protocol (SIP)”, June 2002
[RFC3263]
RFC 3263, J. Rosenberg et al., Network Working Group, “Session
Initiation Protocol (SIP): Locating SIP Servers”, June 2002
[RFC3264]
RFC 3264, J. Rosenberg et al., “An Offer/Answer Model with the
Session Description Protocol (SDP)”, June 2002
- 203 -
A. Cuevas
Tesis Doctoral
[RFC3312]
RFC 3312, G. Camarillo et al., Network Working Group, “Update
to the Session Initiation Protocol (SIP) Preconditions Framework”
March 2005
[RFC3550]
RFC 3550, H. Schulzrinne et al., Network Working Group, “RTP:
A Transport Protocol for Real-Time Applications”, July 2003
[RFC3588]
RFC 3588 P. Calhoun et al., Network Working Group, “Diameter
Base Protocol” September 2003
[RFC3589]
RFC 3589, J. Loughney, Network Working Group “Diameter
Command Codes for Third Generation Partnership Project (3GPP)
Release 5” September 2003
[RFC3702]
RFC 3702, J. Loughney, Network Working Group,
“Authentication, Authorization, and Accounting Requirements for
the Session Initiation Protocol (SIP)”, February 2004.
[RFC3775]
RFC 3755, D. Johnson, Network Working Group, “Mobility
Support in IPv6”, June 2004
[RFC3986]
RFC 3986, T. Berners-Lee, Network Working Group, “Uniform
Resource Identifier (URI): Generic Syntax”, January 2005
[RFC4006]
RFC 4006, H. Hakala et al., Network Working Group, “Diameter
Credit-Control Application”, August 2005.
[RFC4004]
Mobile IPv4 Application”, August 2005
[RFC4005]
Network Access Server Application”, August 2005
[RFC4016]
RFC 4016, M. Parthasarathy, Network Working Group, “Protocol
for Carrying Authentication and Network Access (PANA)
Threat Analysis and Security Requirements”, March 2005
[RFC4068]
RFC 4068, R. Koodli, Network Working Group, “Fast Handovers
for Mobile IPv6”, July 2005
[RFC4072]
RFC 4072, P. Eronen et al., “Diameter Extensible Authentication
Protocol (EAP) Application” August 2005
[RFC4140]
RFC 4140, H. Soliman et al. Hierarchical Mobile IPv6 Mobility
Management (HMIPv6), August 2005
- 204 -
Referencias
[N5845]
MPEG MDS Group, MPEG-21 Multimedia Framework, Part 7:
Digital Item Adaptation (Final Committee Draft), ISO/MPEG
N5845, July 2003;
[ES282001]
ES 282 001 v1.1.1, ETSI, “Overall functional architecture” August
2005
[TR32815]
TR 32.815, 3GPP, “Telecommunication management; Charging
management; Online Charging System (OCS) architecture study”
[TS23207]
TS 23.207 3GPP “End-to-end Quality of Service (QoS) concept
and architecture (Release 6)” September 2005.
[TS23228]
TS 23.228 3GPP “IP Multimedia Subsystem (IMS); Stage 2
(Release 7)” December 2005.
[TS29198]
TS 29.198 3GPP “Open Service Architecture (OSA) Application
Programming Interface (API)”
[TS32200]
management; Charging principles”
[TS32240]
management; Charging architecture and principles”
•
Artículos en revistas
[BRI03]
Bob Briscoe et al. “A Market Managed Multi-service Internet
(M3I)” Computer Communications 26 (4) February, 2003.
[CAL05]
Andrea Calvagna et al. “Mobility and quality of service across
heterogeneous wireless networks” in Computer Networks 47
(2005)
[CAM03]
Gonzalo Camarillo et al. “Evaluation of Transport Protocols for the
Session Initiation Protocol”. IEEE Network. September/October
2003
[COR03]
Giovanni Cortese et.al. “CADENUS: Creation and Deployment of
End-User Services in Premium IP Networks”, IEEE
Communication Magazine Vol.41 No.1, January 2003.
[COM05]
Mohamed Atiquzzaman, Mohsen Guisan “The Next-Generation
Internet” Guest Editorial IEEE Communications Magazine, May
2005
[CUE05]
Antonio Cuevas et al. “Usability and Evaluation of a Deployed 4G
Network Prototype”, Journal of Communications and Networks,
Volume 7, Number 2, June 2005
- 205 -
A. Cuevas
Tesis Doctoral
[FAC04]
Stefano M. Faccin, “IP Multimedia Services: Analysis of Mobile
IP and SIP Interaction in 3G Networks” IEEE comm. magazine
January 2004
[GU02]
X. Gu et al., “An XML-Based Quality of Service Enabling
Language for the Web”, Journal of Visual Language and
Computing, special issue on multimedia languages for the Web,
vol. 3, no. 1, Feb, 2002.
[HOW05]
Michale P. Howarth et al. in “Provisioning for Interdomain Quality
of Service, the MESCAL Approach” IEEE Communications
Magazine, June 2005
[JÄH04]
Juergen Jaehnert, Jie Zhou, Rui L. Aguiar, Victor Marques,
Michelle Wetterwald, Eric Melin, Jose I. Moreno, Antonio
Cuevas_Casado, Marco Liebsch, Ralf Schmitz, Piotr Pacyna,
Telemaco Melia, Pascal Kurtansky, Hasan, Davinder Singh,
Sebastian Zander, Burkhard Stiller "Moby Dick: A Pure-IP 4G
Architecture" Computer Communications Vol 28/9 pp 1014-1027,
December 2004
[JIN04]
Jingwen Jin et al., “QoS specification languages for distributed
multimedia applications: a survey and taxonomy” IEEE
Multimedia, Volume: 11, Issue: 3, Date: July-Sept. 2004
[LI04]
Tianshu Li et al. “Pricing and admission control for QoS-enabled
Internet” Computer Networks 46, 2004
[LO04]
Shou-Chih Lo et al. “"Architecture for mobility and QoS support in
all-IP wireless networks"” in IEEE Journal on selected areas in
communications vol. 22 no.4 may, 2004
[NAH95]
K. Nahrstedt et al. „The QoS Broker“, IEEE MultiMedia, vol. 2, no
1, 1995.
[PAN04]
Vijoy Pandey, „Exploiting User Profiles to Support Differentiated
Services in Next-Generation Wireless Networks“, IEEE Network,
September/October 2004
[ROB04]
J.W. Roberts “Internet Traffic, QoS, and Pricing, Proceedings of
the IEEE, Vol 92, No 9. September 2004”
[SAL02]
Stefano Salsano “SIP Security Issues: The SIP Authentication
Procedure and its Processing Load” IEEE Network
November/December 2002
[SAR03]
Susana Sargento, et al. , “IP-based Access Networks for Broadband
Multimedia Services”, IEEE Communications Magazine, Special
Issue in Broadband Access, February 2003,
- 206 -
Referencias
[SCH04]
Gereo Schollmeier et al. “Providing Sustainable QoS in NextGeneration Networks” in IEEE Communications Magazine June
2004
[WIR04]
Theodore B. Zahariadis “Migration Toward 4G Wireless
Communications”
GUEST EDITORIAL, IEEE Wireless
Communications, June 2004.
[XIE04]
J. Xie, `Ùser independent paging scheme for Mobile IP,'' ACM
Journal of Wireless Networks (WINET), 2004.
[WIW06]
WirtschaftsWoche, 23 februar 2006
[CDI05]
Diario Cinco Días “Las nuevas telefónicas vienen de internet” Luz
Fernández / Mar Jiménez / MADRID (16-09-2005)
[MUN05]
Diario El Mundo, 8th February 2005, Diario del Navegante,
Ariadna
[SPI02]
SPIEGEL ONLINE - 02. Februar 2006
•
Artículos en conferencias
[BOU02]
Julien Bournelle et. al, « Adaptation et implémentation de
Diameter/AAA pour Mobile IPv6 ». Proceeding of the DNAC
2002, Décembre 2002, Paris
[CUE03]
Antonio Cuevas et al. “Mechanisms for AAA and QoS Interaction"
ISBN: 3-9522719-0-X. 3rd Workshop on Application and Services
in Wireless Networks, Bern, Switzerland, July 2003
[ESC02]
J. Escribano, C. García, J.I. Moreno, C. Seldas “Diffserv como
solución a la provisión de QoS en Internet” II Congreso
Iberoamericano de Telemática,CITA'2002. ISBN 980-237-217-X.
[FAN98]
George Fankhauser et al. “Revervation-based Charging in an
Integrated Services Network”, 4th INFORMS Telecommunications
Conference, Boca Ratón, Florida USA, March 1998”
[GAR03]
"QoS en Redes Móviles de Cuarta Generación", Carlos García,
Pedro Antonio Vico, Antonio Cuevas, Ignacio Soto, Jose Ignacio
Moreno, JITEL 2003, Gran Canaria, Spain, September 2003.
ISBN: 84-96131-38-6
[GIO03]
S. Giordano et al. “Managing Multimedia Traffic in IP Integrated
over Differentiated Services: SIP dynamic signalling interworking” in IEEE’s HICSS’03, 2003
- 207 -
A. Cuevas
Tesis Doctoral
[GOM04]
“A transsignalling strategy for QoS support in heterogeneous
networks” Diogo Gomes et al. Proc International Conf. on
Telecommunications - ConTEL , Fortaleza , Brazil , Vol. 1 , pp.
1114 - 1121 , August , 2004
[GRO05]
"Assessing speech quality: a new approach" Laeticia Gros et al.
ForumAcusticum, Budapest August-September 2005.
[KUR04]
Pascal Kurtansky, Hasan, Burkhard Stiller Davinder Singh,
Sebastian Zander, Antonio Cuevas, Jürgen Jähnert, Jie Zhou,
“Extensions of AAA for Future IP Networks” WCNC 2004,
Atlanta, USA, 2004.
[PAP02]
D. Papalilo, S.Salsano, L.Veltri, “Extending SIP for QoS support”,
Joint Planet-IP NEBULA workshop, Courmayeur, 2002.
[RAM03]
Ramaswamy et al. “Considering Processing Cost in Network
Simulations”. ACM SIGCOMM 2003 Workshops, August
25&27,2003,Karlsruhe,Germany. Copyright 2003 ACM 1-58113748-6/03/0008
[RUI04]
P. Ruiz, et al., “Adaptive Multimedia Multi-party Communication
in Ad Hoc Environments”, HICSS-37, Software Technology Track,
January 2004
[SAN05]
"Integración de servicios multimedia en redes 4G" R. Sánchez
Martín, A. Cuevas Casado, J. I. Moreno Novella, P. A. Vico Solano
V Jornadas de Ingeniería Telemática. Vigo, Spain, Septiembre
2005, ISBN: 84-8408-346-2
[WAN02]
L.Wang, V.Pai, and L.Peterson. The effectiveness of request
redirection on CDN robustness. In Proceedings of the Fifth
Symposium on Operating Systems Design and Implementation
Boston, MA, dec 2002.
•
Páginas web
[3GPP]
“3rd Generation Partnership Project” www.3gpp.org
[CADENUS]
Creation and Deployment of End-UserServices in Premium IP
Networks http://wwwcadenus.fokus.fraunhofer.de/
[COMS]
Cambridge
Open
Mobile
System
(COMS)
http://www.cl.cam.ac.uk/Research/SRG/netos/coms/
[IMODE]
i-mode http://www.nttdocomo.com/corebiz/services/imode/
[IPTEL]
NIST. IPTel Project. http://dns.antd.nist.gov/proj/iptel/
- 208 -
project.
Referencias
[FOMA]
Freedom
of
Mobile
Multimedia
Access
http://www.nttdocomo.com/technologies/present/fomatechnology/i
ndex.html
[LONG]
“Laboratories over Next Generation Networks”, IST Project.
http://long.ccaba.upc.es/
[MIND]
“Mobile IP-based Network
http://www.mind-project.org/
[MOBYDICK]
Moby Dick: “Mobility and Differentiated Services in a Future IP
Network”, IST Project. http://www.ist-mobydick.org.
[NS2]
Network Simulator 2 http://www.isi.edu/nsnam/ns/
[OPNET]
OPNET Technologies http://www.opnet.com.
[OVERDRIVE]
OverDRiVE: “Spectrum Efficient Uni- and Multicast Services over
Dynamic Multi-Radio Networks in Vehicular Environments”, IST
Project. http://www.ist-overdrive.org
•
Developments”,
IST
project.
Otros
[CAM05]
Gonzalo Camarillo, “SIP: an standardization update” Invited Talk
in EUNICE 2005, 11th Open European Summer School. July 6-8,
Colmenarejo (Spain). http://www.it.uc3m.es/eunice2005/talks.html
[FOR04]
D. Forsberg, Y. Ohba: “Protocol for Carrying Authentication for
Network Access (PANA)”, work in progress, IETF Internet Draft,
draft-ietf-pana-pana-03.txt, February 2004.
[GRO01]
G. Gross et al. Internet Draft “QoS and AAA Usage with SIP
Based IP Communications” April 2001.
[HAS04]
Daidalos deliverable D341 A4C Framework Design Specification
Aug 04
[HEC02]
O. Heckmann et al., Internet Draft, “Tarif Distribution Protocol
(TDP)”, March 2002
[LIE01]
Marco Liebsch et al. Internet Draft, „Paging Concept for IP based
Networks“, September 2001.
[JAN03]
Jan Janák “SIP Proxy Server Efectiveness” Master's Thesis. Czech
Technical University Faculty Of Electrical Engineering Department
Of Computer Science Prague, 21st May 2003
[SCH02]
Mobile Europe 2002, Bremen 18 Mobile Europe 2002, Bremen
18th th March 2002 March 2002 Peter Schoo A Wireless Vision for
2010 in Japan
- 209 -
A. Cuevas
Tesis Doctoral
[SCU02]
SIPstone - Benchmarking SIP Server Performance Henning
Schulzrinne et al. Columbia University, Ubiquity.
[GAR05]
draft-ietf-aaa-diameter-sip-app-10, M. Garcia_Martin et al., AAA
Working Group, “Diameter Session Initiation Protocol (SIP)
Application”, October 2005
[LE04]
draft-le-aaa-diameter-mobileipv6-04.txt Franck Le et al. AAA
Working Group “Diameter Mobile IPv6 Application” November
2004
[OTT05]
draft-ietf-mmusic-sdpng-09.txt, Joer Ott et al., Network Working
Group, “Session Description and Capability Negotiation”,
September 2005
[MIND02]
MIND Project, “Top-level architecture for providing seamless
QoS, security, accounting and mobility to applications and
services”, Deliverable D1.2, November 2002, http://www.istmind.org/deliverables.htm
[BOS02]
L. Bos et al. “SDPng extensions for Quality of service negotiation”,
IETF Internet-Draft, Work-in-progress, September 2002 <draftbos-mmusic-sdpng-QoS-00.txt >.
[CAL01]
Pat R. Calhoun et al. “Diameter Strong Security Extension”
Internet-Draft Work-in-progress, March 2001. <draft-calhoundiameter-strong-crypto-07.txt>
- 210 -

Tesis Doctoral Contribución al Desarrollo de Soluciones Para

Transcripción

Documentos relacionados

August 7, 2016 - St. James Catholic Cathedral