Tesis Doctoral Contribución al Desarrollo de Soluciones Para
Transcripción
Tesis Doctoral Contribución al Desarrollo de Soluciones Para
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 - Introduction and Objectives 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 - Introduction and Objectives 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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) Informational (provisional response) Informational (provisional response) 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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 2 0 0 O K to IN V IT E 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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 2 0 0 O K to IN V IT E 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 - State of the Art Analysis; Research Opportunities • 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities (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 - State of the Art Analysis; Research Opportunities 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 - State of the Art Analysis; Research Opportunities 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 Voice transport session Voice transport session 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 Voice transport session Voice transport session 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 Party Service Providers 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 - Análisis del Problema: Dispersión de las Sesiones 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 Party Service Providers 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones 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 - Análisis del Problema: Dispersión de las Sesiones • 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 accounting & authorization VASP 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 Request to AAA to finnish accounting & authorization NVUP Sent to QoS System User sends packets CMS indicates no more packets sent request to CMS to finnish measurement session request to CMS to start measurement session User sends packets CMS indicates no more packets sent request to CMS to start measurement session request to CMS to finnish measurement session User finnishes RSVP User starts RSVP request to CMS to finnish measurement session request to CMS to start measurement session CMS indicates no more packets sent User sends packets request to CMS to finnish measurement session request to CMS to start measurement session Figure 26 sessions handled by the QoS system - 94 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support • 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 User and communication related policy 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 1: Does QoS reservation 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 User and communication related policy AN-QoSB (may do QoS reservation) Option 1: Does QoS reservation AN-QoSB decides - 120 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 - Proposed 4G Architecture & Session Setup Support 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 QoSB_an2_dom1 : ANQoSB ER_an2_dom1 : ER RSVP::Path("Artifact","ArtifactR","SubsessionID","QoSParam") COPS::REQ("Flow Param", "QoSParam", "Artifact", "SessHandle1" , "SubsessionID") COPS::DEC("QoSParam2&Flow ") 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. COPS::DEC("QoSParam2&Flow ") 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") COPS::DEC("QoSParam6&Flow ") COPS::DEC("QoSParam6&Flow ") COPS::DEC("QoSParam6&Flow ") 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 QoSB_an1_dom1 : ANQoSB QoSB_an2_dom1 : ANQoSB 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") COPS::DEC("QoSParam3&Flow ") COPS::DEC("QoSParam3&Flow ") COPS::DEC("QoSParam3&Flow ") RSVP::Path("","","","QoSParam3") RSVP::Path("","" ,"", "") RSVP::Path("", "", "", "") RSVP::Resv("Artifact", "ArtifactR", "SubsessionID", "QoSParam4") COPS::REQ("Flow Param", "QoSParam4", "ArtifactR", "SessHandleID3" , "SubsessionID") COPS::DEC("QoSParam5&Flow ") COPS::DEC("QoSParam5&Flow ") COPS::DEC("QoSParam5&Flow ") 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 AAA_an1_dom1 : ANAAA MMSP_an1_dom1 : ANMMSP QoSB_an1_dom1 : ANQoSB 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 QoSB_an2_dom1 : ANQoSB MMSP_an2_dom1 AAA_an2_dom1 : ANAAA 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>> QoSB_an1_dom1 : ANQoSB AAA_an1_dom1 : ANAAA AAA_dom1 : CNAAA AAA_an2_dom1 : ANAAA QoSB_an2_dom1 : ANQoSB : 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::ACR("", "", "") 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::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>> QoSB_an1_dom1 : ANQoSB AAA_an1_dom1 : ANAAA AAA_dom1 : CNAAA AAA_an2_dom1 : ANAAA QoSB_an2_dom1 : ANQoSB : 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::ACR("", "", "") DIAMETER::ACA() DIAMETER::ACA() COPS::DEC("") SIP::ACK() DIAMETER::ACR("AppSessID", "NASSessID", "Start") DIAMETER::ACR("AppSessID", "NASSessID", "Start") 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 Dominio Hogar Dominio Visitado D D I I D D visitado llamante = hogar llamado 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 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 Non Roaming Terminal 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 Figure 57 Enlaces CN-Internet atravesados para el caso 4 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 Figure 58 Enlaces CN-Internet atravesados para el caso 3 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 Dominio Hogar Dominio Visitado D D NR NR 2,4 s I I NR NR 0s D D R R 7,2 s visitado llamante = hogar llamado 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. 64 llamadas/s. Estrategia MMSP. Cada punto es un mensaje 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 Tiempo de procesamiento de los mensajes en un AN-MMSP. 64 llamadas/s. Estrategia MN. Cada punto es un mensaje Tiempo de proceso del mensaje (s) 1.2 1 0.8 0.6 0.4 0.2 0 12 16 20 24 28 32 36 40 44 48 Tiempo de entrada del mensaje (s) 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) Tiempo de establecimiento de las llamadas. 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 Tiempo de inicio de la llamada (s) 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 de los mensajes en un AN-MMSP. 43 llamadas/s. Estrategia MMSP. Cada punto es un mensaje 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 Tiempo de entrada del mensaje (s) 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" Tiempo de establecimiento de las llamadas. Pico de llamadas. Estrategia MMSP Tiempo de establecimiento (s) 9 8 7 6 5 4 3 2 1 0 12 22 32 42 52 62 72 82 Tiempo de inicio de la llamada (s) Figure 69 Tiempo de establecimiento de llamada. Pico de llamadas. Estrategia “MMSP" Tiempo de establecimiento de las llamadas. 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 Tiempo de inicio de la llamada (s) 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. Tiempo de procesamiento de los mensajes en un AN-MMSP. Pico de llamadas. Cada punto es un mensaje. Estrategia MMSP Tiempo de proceso del mensaje (s) 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 Tiempo de entrada del mensaje (s) Figure 71 Tiempo de procesamiento en el AN-MMSP. Pico de llamadas. Estrategia MMSP - 180 - Validación Tiempo de procesamiento de los mensajes en un AN-MMSP. Pico de llamadas. Cada punto es un mensaje. Estrategia MN Tiempo de proceso del mensaje (s) 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 Tiempo de entrada del mensaje (s) 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 Tiempo de entrada del mensaje (s) 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. Tiempo de establecimiento (s) 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. Tiempo de procesamiento de los mensajes en un AN-MMSP. 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 - Conclusions and Future Work 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 - Conclusions and Future Work 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] RFC 4005, P. Calhoum, Network Working Group, “Diameter 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] TS 32.240, 3GPP, “Telecommunication management; Charging 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, ``User 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] RFC 4004, P. Calhoum, Network Working Group, “Diameter Mobile IPv4 Application”, August 2005 [RFC4005] RFC 4005, P. Calhoum, Network Working Group, “Diameter 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] TS 32.200, 3GPP, “Telecommunication management; Charging management; Charging principles” [TS32240] TS 32.240, 3GPP, “Telecommunication management; Charging 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, ``User 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 -