Conclusiones Podría parecer que hemos llegado a los límites alcanzables por la tecnología informática, aunque uno debe ser prudente con estas afirmaciones, pues tienden a sonar bastante tontas en cinco años John Von Neumann. Capítulo V.- Conclusiones 1.- Conclusiones Están claras las ventajas de IMS para una operadora, pero hay que hacerlo atractivo para el cliente, de forma que así se justifique la integración de este subsistema en la arquitectura de la red de una operadora de 3G. La diferencia entre una operadora y un usuario o cliente es la concepción de la tecnología, la operadora lo ve en términos de protocolos y tecnología en sí, mientras que los usuarios son compradores de servicios. Por tanto, la forma de vender IMS es diseñar atractivos servicios como el que se presenta en este proyecto. Se trata, pues, de un éxito hipotecado al dinamismo y facilidad de manejo de las herramientas de desarrollo de servicios para IMS. El plugin que se ha manejado para este servicio, lejos de ser dinámico y eficiente, ha resultado en ocasiones tedioso, rudimentario e ineficiente. Cabe destacar que el framework de pruebas es poco ágil ya que no permite hacer un seguimiento detallado de las pruebas ni 86
Conclusiones detenerlas cuando convenga; cuando la prueba va adquiriendo peso puede llegar a ser un inconveniente funcional importante. Es digna de mención la considerable limitación de sólo poder arrancar un cliente por equipo, o a lo sumo dos, pero un cliente java y otro en el emulador proporcionado con la herramienta. Además dicho emulador requiere un trabajo adicional para conseguir un mayor parecido al comportamiento del terminal físico real ya que en algunas ocasiones puede suponer una carga adicional de trabajo; por otra parte, hay que pararse a configurar estáticamente la ip del emulador debido a que no consigue obtenerla por DHCP aunque aparentemente está capacitado para ello. Por último, añadir, que algo que adquiere tanta importancia en la integración de los servicios como son las mapping rules, ofrecen una interfaz de definición que resulta engorrosa e ineficiente. Por otra parte, las API s en que se basa la implementación del cliente no están al nivel de desarrollo necesario para el diseño de un servicio de cierta envergadura. De hecho, no todos los métodos SIP están completamente soportados ya que en algunos no se pueden incluir ciertas cabeceras. Está más orientada a la recepción que al envío de métodos. Por todos los contratiempos anteriormente enunciados y la escueta documentación disponible hemos tenido que acudir al soporte presencial de Ericsson en el laboratorio Minerva y al foro de Ericsson para desarrolladores de servicios para IMS en SDS ( http://www.ericsson.com/mobilityworld/sub/open/technologies/ims_ poc/forum_topics.html?fid=164&start=1&step=25 ). A la mayoría de las consultas hemos obtenido orientaciones más que respuestas definitivas, pero siempre hemos conseguido resolver lo planteado. Otra de las consecuencias de las limitaciones de la herramienta y de la API ha sido tener que prescindir de una de las funcionalidades del servicio contempladas en la fase de diseño, Push To Talk (PTT), ya que no ofrecían todo el soporte necesario para abordar la implementación de dicha funcionalidad. Hemos apostado por un método de trabajo basado en la máxima cuatro ojos ven más que dos que nos ha llevado a desarrollar habilidades de toma de decisiones desde distintos enfoques y buscando puntos de encuentro. Esto nos ha permitido compensar una de las carencias formativas de la carrera que sin embargo están muy demandadas en el tejido empresarial actual. 87
Líneas futuras 2.- Líneas futuras Actualmente la localización está diseñada de tal manera que el grupo asume la ubicación del creador en el instante de creación del grupo como zona de cobertura. Se puede plantear la posibilidad de dotar al servicio de la funcionalidad de seguimiento de la localización del creador de grupo, así, la zona de cobertura del grupo se va actualizando dinámicamente siguiendo los movimientos de su creador. Un ejemplo sería un grupo de excursionistas desplazándose de ciudad en ciudad, así evitaríamos tener que crear el grupo en cada nueva ubicación. Se podría llamar servicio follow me. En cuanto a las comunicaciones se podrían abordar dos líneas de trabajo encaminadas a enriquecer las posibilidades del servicio. Por un lado, dotarlo de la funcionalidad PTT tal como se comentaba en la descripción del servicio pero que debido a limitaciones de la plataforma no se ha podido abordar. Por otra parte, en algunos escenarios, podría ser de interés que las comunicaciones fueran de 1 a N, es decir, todos se comunican con el creador pero no entre ellos, y el creador con todos. Para el seguimiento del servicio por parte de la operadora se podría plantear el desarrollo de un software de monitorización de grupos y usuarios orientado a obtener estadísticas de uso en tiempo real que permitan tomar decisiones que optimicen la configuración de la red para la explotación del servicio. Por último, habría que acometer el siguiente paso en el ciclo de desarrollo de un servicio, su prueba en maqueta antes de desplegarlo en el escenario real. Habría que negociar con alguna operadora para trasladar el servidor del SIP Container del SDS a un SIP AS real de una arquitectura IMS completa. 88
Glosario 3.- Glosario 3GPP AS ATF B2BUA BSS BTS CAMEL CAP CN CPoCS CSCF DA DCU DNS FB GC GGSN GMSC GPRS GSM gsmcsf GTT GW HLR HSS I CSCF IFC IM IMS IM SSF IP LBS MAA MAR MGCF MGW MMS MRF MRFC 3rd Generation Partnership Project Application Server Automated Testing Framework Back to Back User Agent Base Station Subsystem Base Transceiver Station Customized Applications for Mobile network Enhanced Logic CAMEL Application Part Core Network Controlling PoC Server Call Session Control Function Diagrama de Actividades Diagrama de Casos de Uso Domain Name System Fuera de banda Group Creator Gateway GPRS Support Node Gateway Mobile Switching Centre General Packet Radio Services Global System Mobile GSM Service Control Function Global Text Telephony Gateway Home Location Register Home Subscriber Server Interrogating Call Session Control Function Initial Filter Criteria Instant message IP Multimedia Subsystem IP Multimedia Service Switching Function Internet Protocol Location Based Services Multimedia Auth Answer Multimedia Auth Request Media Gateway Controller Function Media Gateway Multimedia Messaging System Multimedia Resource Function Media Resources Function Controllers 89
Glosario MRFP MS MSC OP OSA P CSCF PDF PoC PoCT PPoCS PSTN PTT QoS RTC SCS S CSCF SDP SDS SGSN SGW SIMPLE SIP SLF SMS SMSC SSF UA UAA UAR UDB UML UMTS URI USSD VLR WAP XCAP Media Resources Function Processors Mobile Station Mobile Switching Center Operadora Open Service Access Proxy Call Session Control Function Policy Decision Function PTT Over Celular PoC Terminal Participating PoC Server Public Switched Telephony Network Push To Talk Quality of Service Red Telefónica Conmutada Service Capability Server Serving Call Session Control Function Session Description Protocol Service Development Studio Serving GPRS Support Node Signalling Gateway SIP for Instant Messaging and Presence Leveraging Extensions Session Initiation Protocol Subscriber Location Function Short Message Service Short Message Service Center Service Switching Function User Agent User Authorization Answer User Authorization Request User Data Base Unified Modeling Language Universal Mobile Telecommunications System Uniform Resource Identifier Unstructured Supplementary Service Data Visit Location Register Wireless Application Protocol XML Configuration Access Protocol 90