Diagrama de Secuencia del Caso de Estudio

La figura 33 es un diagrama de secuencia que explica el funcionamiento del prototipo, omite algunas entidades (especialmente el Enrutador de Eventos, ya que este solo hace la función de puente entre dos entidades), mensajes y casos de error con el fin de hacer énfasis en las relaciones entre los servicios y entidades involucradas en el prototipo.

Todo comienza cuando un usuario previamente registrado en la red IMS, decide ejecutar su aplicación cliente del servicio de valor agregado “Sudafrica Live!”, tras lo cual la aplicación inmediatamente procede a enviar un mensaje SIP solicitando el inicio de la sesión, ello es efectuado mediante un mensaje SIP INVITE enviado al contacto [email protected].

Cuando este mensaje SIP llega hasta el núcleo de la red IMS, es decir el S-CSCF, este procede a evaluar los iFC y encuentra que hay uno que coincide con ese mensaje SIP en particular, entonces este ejecuta las acciones necesarias indicadas por el iFC y reenvía la petición directamente hacia el AS correspondiente. Cabe resaltar que el S-CSCF debe tener configurado correctamente el iFC para que sean encaminados por la misma ruta todos los mensajes SIP que pertenezcan a una misma sesión.

Cuando el mensaje SIP INVITE llega al AS, específicamente al Enrutador de Eventos, este procede a evaluar si existe algún servicio activo en el SLEE que haya indicado en sus descriptores de despliegue que los eventos SIP INVITE son eventos que requieren de la creación de una Entidad SBB de esos servicios. Como resultado de esta evaluación, una Entidad SBB del Servicio de Interfaz ISC es creada.

Una vez la Entidad SBB del Servicio de Interfaz ISC ha sido creada, el Enrutador de Eventos procede a enviarle el evento SIP INVITE para que ésta lo procese. Luego de que este evento ha sido procesado, el servicio continua y envía un mensaje SIP 200 OK y queda a la espera del ACK de parte de la aplicación cliente en el terminal de usuario. Cuando el ACK llega, entonces el inicio de la sesión previa es completado correctamente y el Servicio de Interfaz ISC crea un dialogo SIP persistente que representa toda la sesión. Durante el procesamiento del evento ACK, el Servicio de Interfaz ISC procede a crear un evento simplificado que solo contiene la identidad SIP del usuario que envió el mensaje original y el destinatario del mensaje, de modo que el evento solo contiene los campos [email protected] como remitente y [email protected] como destinatario. Una vez el evento personalizado ha sido creado, la Entidad SBB procede a enviarlo al Enrutador de Eventos y este repite el procedimiento de evaluación de los servicios activos que puedan estar interesados en tal evento y como resultado una nueva Entidad SBB del SBB raíz del servicio de valor agregado “Sudafrica Live!” 16 _{es creada.}

Después de que la Entidad SBB del servicio de valor agregado ha sido creada, el Enrutador de Eventos procede a enviarle el evento simplificado creado previamente por el Servicio de Interfaz ISC. Aquí, lo que haga esta Entidad SBB depende totalmente de la lógica del servicio, que para este caso, lo primero que hace es verificar que el usuario que ha solicitado iniciar la sesión tiene saldo disponible en su cuenta, y en caso de no tenerlo, terminar la sesión inmediatamente después de enviar un mensaje de texto informándole que debe recargar. Para hacer la consulta, crea un evento simplificado que solo contiene la identidad del usuario sobre el que va a realizar dicha consulta y el tipo de consulta que desea realizarse sobre el HSS, que para este caso, es una consulta sobre datos arbitrarios del servicio “Sudafrica Live!”. Tras crear el evento simplificado, este es enviado al Enrutador de Eventos.

De la misma forma que con los anteriores eventos, el evento personalizado es procesado por el Enrutador de Eventos y como resultado crea una Entidad SBB del Servicio de Interfaz Sh. Luego, esta Entidad SBB recibe el evento personalizado y lo procesa, lo que resulta en la identificación completa del tipo de consulta que desea hacerse sobre el HSS para así crear un mensaje Diameter apropiado para iniciar la transacción de consulta. Cuando este mensaje es enviado por esta Entidad SBB hacia el Enrutador de Eventos, este lo identifica como un evento que debe ser enviado a través del RA de Diameter sobre la interfaz Sh del AS hacia el HSS. De aquí en adelante pueden ocurrir varias cosas dependiendo del HSS y de las cuales el Servicio de Interfaz Sh es encargado completamente. Posteriormente, cuando la Entidad SBB y el HSS han terminado la transacción, la Entidad SBB procede a crear un evento personalizado de respuesta que contiene el resultado y los datos de la operación de consulta, y lo envía a través del Enrutador de Eventos de regreso a la Entidad SBB del servicio de valor agregado, tras lo cual la Entidad del Servicio Sh es eliminada y el objeto SBB que la representada vuelve a la piscina de objetos disponibles del SLEE. Cuando la Entidad SBB del servicio de valor agregado recibe el evento personalizado, obtiene los resultados sobre la consulta que realizó, específicamente son dos valores, el primero es un indicador de si la consulta pudo ser realizada correctamente y el segundo son los datos XML correspondientes a los datos arbitrarios de servicio, los cuales están presentes solo si el resultado de la consulta fue positivo. Si al analizar el documento XML, su resultado arroja que el usuario no tiene saldo suficiente, entonces la Entidad SBB crea un evento personalizado que contiene un mensaje de texto para el usuario y lo envía al Enrutador de Eventos para que este lo entregue a la Entidad SBB del Servicio de Interfaz ISC, para que a su vez, esta cree un mensaje SIP MESSAGE a semejanza del evento personalizado recibido y lo envíe al terminal de usuario. Luego, la Entidad SBB del servicio de valor agregado, crea otro evento personalizado que indica el termino de la sesión con el usuario y lo envía igualmente al Enrutador de Eventos para que lo entregue a la Entidad SBB del Servicio de Interfaz ISC, tras lo cual la Entidad SBB del servicio de valor agregado

es eliminada inmediatamente. Al mismo tiempo, la Entidad SBB del Servicio de Interfaz ISC crea un mensaje SIP BYE que envía hacia el Enrutador de Eventos para que sea enviado al terminal de usuario, tras lo cual esta Entidad SBB también es eliminada y todo habrá terminado. Para el caso en que el usuario sí tiene saldo disponible, entonces la Entidad SBB del servicio de valor agregado procede a conectar al usuario al servicio de narración para luego descontar un partido de la cuenta personal del usuario, para lo cual crea un evento personalizado que contiene la identidad del usuario y el nuevo documento XML con los nuevos datos de servicio, y lo envía al Enrutador de Eventos.

El Enrutador de Eventos procesa este evento personalizado de la misma manera realizada anteriormente y finaliza creando una nueva Entidad SBB del Servicio de Interfaz Sh. De manera similar al caso de la consulta, esta Entidad esta encargada de realizar toda la operación de actualización de datos arbitrarios de servicio sobre el HSS, para lo cual realiza una serie de intercambios de mensajes un poco más elaborada que para el caso anterior. Al finalizar, y si todo ha resultado correctamente, esta Entidad SBB procede a crear un evento personalizado de respuesta para enviarlo de regreso a la Entidad SBB del servicio de valor agregado a través del Enrutador de Eventos, este evento contiene en este caso solo un indicador acerca del resultado de la operación. Tras enviar este evento, la Entidad SBB del Servicio de Interfaz Sh es eliminada inmediatamente y el objeto que la representaba vuelve a la piscina de objetos disponibles.

En este punto, el usuario está conectado al servicio y ya se le ha descontado el presente partido de su cuenta personal, por lo que cada vez que la Entidad SBB reciba un mensaje XMPP desde el servicio Gtalk por el comentarista, ésta crea un evento personalizado con el contenido del mensaje instantáneo recibido y lo envía al Enrutador de Eventos para que lo entregue a la Entidad SBB del Servicio de Interfaz ISC y así crea un mensaje SIP MESSAGE para que sea enviado al terminal de usuario.

Por último, cuando el usuario desea terminar la sesión, la aplicación cliente de su terminal envía el correspondiente mensaje SIP BYE que es encaminado, a través de la red de acceso del caso, hacia el S-CSCF, luego es entregado al AS y recibido por la Entidad SBB del Servicio de Interfaz ISC que a su vez, crea un evento personalizado que indica el fin de la sesión y lo envía al Enrutador de Eventos para que lo entregue a la Entidad SBB del servicio de valor agregado, la cual al recibirlo es eliminada. Previamente, la Entidad SBB del Servicio de Interfaz ISC al recibir el mensaje SIP BYE, responde automáticamente con un mensaje SIP 200 OK y también es eliminada pues la sesión ha terminado. Después de haber sido eliminadas todas las entidades SBB, los objetos SBB que las representaban regresan a la piscina de objetos SBB disponibles.