Curso Servicios de Red Inteligente en Redes Móviles
1
Este documento es propiedad de SERPROTEL® ARGENTINA. Su reproducción total o parcial no está autorizada sin previo consentimiento de SERPROTEL® ARGENTINA.
2
Contenido Parte I: Sistema de señalización número 7 •
•
Arquitectura de una red SS7 • Puntos de conmutación de servicios (SSP) • Puntos de transferencia de señal (STP) Puntos de control de servicios (SCP) • Nodos de servicio (SN) • Creación y administración de servicios • Vínculos de datos • Capas de protocolo SS7 y su vinculación con el modelo OSI • Capa física (MTP – nivel 1) • Capa de enlace (MTP – Nivel 2) • Capa de red (MTP – Nivel 3) Parte de control de conexión de • señalización (SCCP) Parte de Usuario de RDSI (ISUP) • Parte de Aplicación de Capacidades de • Transacción (TCAP) • Parte de Aplicación de Red Inteligente (INAP) • Parte de Aplicaciones Móviles (MAP)
Parte II: Protocolos de Red Inteligente para Redes Móviles •
•
•
Introducción a GSM • Señalización • Movilidad • Identificadores • Servicios básicos y suplementarios Servicios y tecnologías de mensajería móvil El protocolo WAP • El protocolo SMPP • Introducción a las Redes Inteligentes • Función de Servicios de Control y Conmutación Modelo básico de estado de llamada • • Tratamiento de llamadas Principios y evolución del estándar • CAMEL Señalización para CAMEL •
•
CAMEL Fase I Arquitectura • • Descripción funcional • Modelo de llamada • Parte de aplicación CAMEL (CAP)
•
CAMEL Fase II Arquitectura • Descripción funcional • Modelo de Llamada • • Interacción con los servicios suplementarios GSM CAMEL Fase III Conceptos generales de redes 3G • Control de llamadas • Control de GPRS • Control de SMS • • Administración de la movilidad CAMEL Fase IV • Control de llamadas • Control de GPRS
•
•
Parte III: Seguridad de Red para Acceso Móvil •
• •
Conceptos principales • El modelo AAA • Conceptos de Autenticación Autorización • Contabidad (Accounting) • El protocolo RADIUS El protocolo DIAMETER
3
4
El ITU-T ha fijado y diseñado el SS7 con el propósito de ser el único compatible con la red digital futura y con los servicios integrados ISDN. La estructura lógica del SS7 se fundamenta en el modelo de 7 capas de Interconexión de Sistemas Abiertos OSI. El modelo se reduce a 4 capas para obtener un ahorro sustancial en el tiempo de procesamiento. De acuerdo con ITU-T Q.709 el retardo de señalización debe tener un límite en el 95% de las llamadas. En la señalización por canal común la red de señalización puede ser distinta a la red de información debido a que se pretende una red redundante para asegurar al máximo la confiabilidad del mensaje. En otras palabras, se pretende que la comunicación entre procesadores de los centros de conmutación se mantenga aún cuando las condiciones de la red de transporte de información de usuario se encuentre interrumpida.
5
Sistema de señalización Número 7 Estándar de la UIT-T que define los procedimientos y protocolos mediante los cuales, los elementos de una red se intercambia información, sobre una red enteramente digital, para establecer, mantener y liberar las llamadas tanto móviles como fijas. Características: • Sistema de señalización por canal común y fuera de banda • Establece tres modos de explotación: • Modo asociado: La topología de la red de señalización y la red para la transmisión de información de los usuarios coincide • Modo cuasi-asociado: Ambas topologías coinciden parcialmente • Modo disociado: Topologías disjuntas
6
SSP (Service Switching Point) – Elementos de la red en los que comienza, se conmutan o terminan llamadas. – Se comunican con otros SSP para mantener, gestionar o liberar los recursos necesarios – Pueden comunicarse con los SCP para ofrecer nuevos servicios STP (Signal Transfer Point) – Conmutadores de tráfico de señalización – Encaminan el paquete entre una de sus bocas de entrada y una de salida en función de la información contenida en el paquete SS7. SCP (Signal Control Point) – Concentran la mayor parte de la inteligencia de proceso de la red – Base de datos con información sobre operación, mantenimiento y servicios suplementarios.
•
•
•
7
8
Componentes de la red Enlaces de señalización Los enlaces de señalización son los componentes básicos de una red de señalización que conecta dos puntos de señalización. Los enlaces de señalización abarcan funciones del nivel 2 destinadas a asegurar la protección contra errores en los mensajes (detección y consiguiente corrección de errores). Proporcionan además medios para mantener la secuencia correcta de los mensajes (véase la Recomendación Q.703). Puntos de señalización Los enlaces de señalización conectan puntos de señalización en los cuales se ejecutan funciones de red de señalización del nivel 3 tales como el encaminamiento de mensajes, pudiendo realizarse funciones de usuario del nivel 4 cuando se trata de un punto de señalización de origen o de destino (véase 2.4/Q.704). Un punto de señalización que sólo transfiere mensajes de un enlace de señalización a otro en el nivel 3 actúa como punto de transferencia de señalización (STP, signalling transfer point). Los enlaces de señalización, puntos de transferencia de señalización y puntos de señalización (de origen y de destino) pueden combinarse de muchas formas diferentes para constituir una red de señalización.
9
10
• El STP W y el X ejecutan funciones idénticas, son redundantes, al igual que Y y Z. Se le llama el STP
par. • Cada SSP tiene dos enlaces, uno a cada STP del par. • Los STP pares son unidos por un enlace. • Dos pares de STPs se unen por cuatro enlaces, los cuales se les conoce como enlaces cuadrangulares o quad. • De igual manera, se acostumbra tener SCP redundantes, pero estos no están unidos por un enlace.
11
Se considera que las redes nacional e internacional son estructuralmente independientes; por tanto, aunque un punto de señalización determinado puede pertenecer a ambas redes, a los puntos de señalización se les atribuyen códigos de punto de señalización de acuerdo con las reglas de cada red. Con objeto de explotar eficazmente redes de señalización de diferentes grados de complejidad, se establecen procedimientos de red de señalización. Tales procedimientos, permiten una transferencia fiable de los mensajes a través de la red y la reconfiguración de ésta en caso de falla. La red de señalización más elemental está constituida por un punto de señalización de origen y un punto de señalización de destino conectados por un solo enlace de señalización. Para satisfacer los requisitos de disponibilidad, puede complementarse dicho enlace por otros adicionales, en paralelo, capaces de funcionar con compartición de carga. Si, para todas las relaciones de señalización, los puntos de señalización de origen y de destino están conectados directamente de esta manera en una red, ésta funciona en el modo asociado. Por razones técnicas o económicas, puede no ser adecuada una red que funciona en el modo asociado simple, en tal caso puede establecerse una red que funcione en el modo cuasiasociado, en el cual la información enviada por el punto de señalización de origen al de destino puede transferirse a través de varios puntos de transferencia de señalización. Tal red puede representarse por una red en malla como la ilustrada en el Anexo A, ya que otras redes o bien constituyen un subconjunto de la red en malla o están estructuradas de modo que comprendan como componentes, la red en malla, o subconjuntos de ésta.
12
Independencia estructural de la red de señalización internacional y de las redes de señalización nacionales La red de señalización mundial está estructurada en dos niveles funcionalmente independientes, el nivel internacional y el nacional, que se han representado en la Figura. Esta estructura permite dividir de una manera clara las responsabilidades en cuanto a la gestión de la red de señalización y permite establecer planes de numeración de puntos de señalización de la red internacional y de las diferentes redes nacionales, completamente independientes entre sí. Un punto de señalización (SP, signalling point), que incluye un punto de transferencia de señalización (STP), puede pertenecer a una de las tres categorías siguientes: – punto de señalización nacional (NSP, national signalling point) (punto de transferencia de señalización), perteneciente a la red de señalización nacional solamente (por ejemplo, NSP1) e identificado por un código de punto de señalización de origen de o destino (OPC o DPC) de acuerdo con el plan de numeración nacional de puntos de señalización; – punto de señalización internacional (ISP, international signalling point) (punto de transferencia de señalización), perteneciente a la red de señalización internacional solamente (por ejemplo ISP3) e identificado por un código de punto de señalización (OPC o DPC) de acuerdo con el plan de numeración internacional de puntos de señalización; – nodo que funciona tanto como punto de señalización internacional (punto de transferencia de señalización) y como un punto de señalización nacional (punto de transferencia de señalización), y pertenece, por tanto, a la red de señalización internacional y a una red de señalización nacional, por lo que está identificado por un código de punto de señalización (OPC o DPC) específico en cada una de las redes de señalización. Cuando en un punto de señalización sea necesario distinguir entre códigos de punto de señalización internacional y nacional, puede utilizarse el indicador de red.
13
Formato de código de punto de señalización internacional (CPSI) Identificador de zona geográfica (3 bits) • Identificador de red (8 bits) • Identificador de punto de señalización (3 bits) Solo 8 puntos de señalización internacionales por red • A nivel nacional, la numeración se determina localmente
14
A. (Acces) Conecta un SCP o SSP a un STP. B. (Bridge) Conecta a un STP con otro STP. C. (Cross) Conecta a STPs redundantes. D. (Diagonal) Lo mismo que los enlaces B. E. (Extended) Conecta a un SSP a un STP alterno, para redundancia. F. (Fully associated) Conecta a dos puntos de señalización terminales, utilizado cuando no se tienen STPs.
15
Ejemplos de redes de señalización en malla Consideraciones generales Tiene por objeto explicar los procedimientos definidos en la Recomendación Q.704. Aunque en los ejemplos se utiliza una red en malla específica para presentar los procedimientos, no es el propósito recomendar, sea implícita o explícitamente, la red descrita. Para presentar los procedimientos de nivel 3 de la MTP, se utiliza la red en malla por considerarse que ella, tal como está representada, constituye una forma posible de realización de la red internacional, o que dicha red, o subconjuntos de la misma, pueden constituir los componentes de otras estructuras de red. Estructuras básicas de red (ejemplos) Las figuras muestran una estructura básica de la red en malla, y tres versiones simplificadas derivadas de esta estructura básica. Pueden construirse redes de señalización más complejas utilizando estas estructuras como componentes. En esta red, cada punto de señalización con funciones del nivel 4 está conectado por dos conjuntos de enlaces con dos puntos de transferencia de señalización. Cada par de puntos de transferencia de señalización está conectado con cada uno de los demás pares mediante cuatro conjuntos de enlaces. Además, un conjunto de enlaces conecta los dos puntos de transferencia de señalización que constituyen cada par. Las versiones simplificadas a), b) y c) de la red de señalización básica se obtienen suprimiendo, respectivamente: a) dos de los cuatro conjuntos de enlaces de señalización entre puntos de transferencia de señalización; b) los conjuntos de enlaces entre puntos de transferencia de señalización que pertenecen al mismo par; c) los conjuntos citados en a) y en b) al mismo tiempo. Debe señalarse que para una determinada disponibilidad de los enlaces de señalización, cuanto mayor sea el número de conjuntos de enlaces de señalización retirados de la red de señalización básica menor será la disponibilidad de la red de señalización. Sin embargo, puede aumentarse la disponibilidad de las redes de señalización simplificadas, añadiendo uno o más enlaces de señalización en paralelo a cada uno de los conjuntos restantes de enlaces de señalización.
16
17
Esta capa recibe el Campo de Información de Señalización CIS desde la capa 3 y arma una trama denominada Unidad de Mensaje de Señalización. En ITU-T Q.703 se determinan las funciones y la estructura de la trama que se muestra en la Figura siguiente. La estructura de la trama es similar a HDLC (High Level Data Link Control) y tiene diferencias de estilo con los protocolos LAP-B y LAP-D usados en X.25 y DSS1. DELIMITACIÓN DE TRAMAS. La Bandera oficia de encabezamiento y cierre de la Unidad de Señalización. La misma bandera puede oficiar de apertura de una unidad y cierre de la anterior. Los bits usados son 0111 1110. Como la longitud de la trama no está definida de antemano nunca se debe simular durante la transmisión una secuencia igual a la bandera. Por ello cada vez que se encuentra una secuencia 11111 se le agrega un 0 para impedir esa posibilidad. El Indicador de Longitud LI señala el número de Bytes que siguen a continuación y que preceden a los bits de control BCE. Se disponen de 6 bits que señalan entre 0 y 63 Bytes. Si el número de Bytes es superior a 63, se indica este valor y dentro del campo de información de señalización CIS de la capa 4 se indicará la longitud exacta. CONTROL DE ERRORES. Consiste en 2 Bytes calculados mediante Chequeo de Redundancia Cíclica CRC16. El polinomio generador es X-16+X-12+X-5+1. Si se detectan errores en la unidad de señalización se la descarta y se pide la retransmisión mediante el bit BI. CORRECCIÓN DE ERRORES. Se hace referencia al Número de Secuencia en sentido Directo FSN y en sentido Inverso BSN. Cada trama se numera desde el 0 al 127 mediante 7 bits que corresponden a FSN. El lado de recepción controla el estado de la trama recibida mediante los bits de control de errores BCE. En el sentido inverso mediante los 7 bits BSN se informa sobre la trama que ha sido recibida.
18
TIPOS DE MENSAJES DE CAPA 3 La capa 3 se ocupa del enrutamiento (dirección y control del enlace de datos) que seguirá el mensaje dentro de la red de señalización. En ITU-T Q.705 se indican las características y funciones de la capa 3 de este sistema de señalización por canal común. Se disponen de 3 tipos de Unidades: de relleno, de estado y la unidad de señalización. -Unidad de relleno. La Unidad de Relleno no lleva campo de información por lo cual el indicador de longitud IL se encuentra en cero. Esta unidad es usada cuando no existe mensaje alguno a ser intercambiado entre extremos. No se requiere dirección del punto de origen y destino (función de la capa 3) pues se intercambian entre capas 2 adyacentes. -El Mensaje de Estado de Enlace. Consiste en 1 o 2 Bytes con información del estado de alineamiento de trama; estado normal o de emergencia; fuera de servicio; interrupción del microprocesador; congestión de red; etc. -El Mensaje de Señalización. Consistente en una etiqueta normalizada de 4 Bytes que lleva información para el enrutamiento seguido del mensaje del usuario desde la capa 4. El SS7 es una red de datos que no posee control de flujo; los centros de conmutación se diseñan con suficiente memoria. El enrutamiento es de tipo sinconexión. Cada mensaje lleva la dirección del origen y del destino. Cada nodo de procesamiento de SS7 posee información de routing en capa 3 del “próximo paso” hacia el destino final.
19
20
CONTENIDO DEL MENSAJE DE CAPA 7. En el modelo de capas la Parte de Usuario ocupa una parte de las capas 4-7. Se disponen de distintas partes de usuario de acuerdo con el tipo de servicio: -para usuario de telefonía ( TUP), -para usuario de red digital ISDN ( ISUP) y -para usuario de red de datos ( DUP). Otros usuarios de capa 4-7 son: telefonía móvil MAP, y el control de conexión SCCP-TCAP.
21
Encaminamiento Consideraciones generales Se dan aquí algunos ejemplos de encaminamiento en la red en malla básica y se describen las acciones de encaminamiento requeridas para cambiar las rutas que han de seguir los mensajes en condiciones de falla. En los ejemplos presentados, se suponen los s iguientes principios de encaminamiento: – Las rutas de mensajes deben atravesar un número mínimo de puntos de transferencia de señalización intermedios. – El encaminamiento en cada punto de señalización no será afectado por las rutas de mensajes utilizadas hasta el punto de transferencia de señalización en cuestión. – Cuando haya disponibles más de una ruta de mensajes el tráfico de señalización deberá ser compartido entre dichas rutas. – Los mensajes relativos a una transacción de usuario determinada, y enviados en una dirección dada, serán encaminados por la misma ruta de mensajes a fin de asegurar la secuencia de mensajes correcta. Encaminamiento en ausencia de fallas: La Figura ilustra un ejemplo de encaminamiento en ausencia de fallas, para mensajes transmitidos del punto de señalización A al punto de señalización F. Deben tenerse en cuenta los siguientes aspectos: a) Al distribuir el tráfico para la compartición de carga en el punto de señalización de origen y en puntos de transferencia de señalización intermedios, deben emplearse con cuidado los códigos de selección de enlaces de señalización (SLS), a fin de que el tráfico se distribuya uniformemente entre las cuatro rutas disponibles. En el ejemplo, el punto de señalización de origen A utiliza el segundo bit menos significativo del código de selección de enlace de señalización y los puntos de transferencia de señalización B y C utilizan el bit menos significativo. b) En casos distintos del descrito anteriormente, la elección de un determinado enlace, para un código dado de selección de enlaces de señalización, puede hacerse en cada punto de s eñalización independientemente. En consecuencia, las rutas de mensajes en los dos sentidos de transmisión, para una determinada transacción de usuario (por ejemplo, SLS = 0010), pueden seguir trayectos diferentes (por ejemplo, A → C → D → F y F → E → B → A). c) Los enlaces BC y DE no se utilizan en condiciones de ausencia de fallas, sino en ciertas situaciones de fallas. d) Cuando el número de enlaces de un conjunto de enlaces no es una potencia de dos (es decir, 1, 2, 4, 8) la compartición de carga de la SLS no consigue una distribución uniforme del tráfico a través de los distintos enlaces.
22
23
24
Intercambio de mensajes en una conexión SS7 para usuario ISUP. IAM (Initial Address Message ). Contiene la información inicial de llamada para el encaminamiento. SAM (Subsequent Address Message ). Transporta las cifras no enviadas en el mensaje IAM. ACM ( Address Complete Message ). Indica que se ha obtenido en acceso al destino. ANM ( Answer Message). Indica que el usuario llamado ha respondido. BLO (Blocking Message ). Permite el bloqueo del canal útil. UBL (Unblocking Message ). Desbloquea el canal útil. REL (Release Message ). Permite iniciar la liberación del canal. RLC (Release Complete Message ). Informa que la liberación ha sido completada
25
La Especificación de la "Parte de Usuario de Servicios Integrados (PU-RDSI) del Sistema de Señalización por Canal Común Nº7 (SSCCNº7) a emplear en el ámbito de la Red Digital Telefónica se basa en las Recomendaciones Q.761-Q.766 y Q.730 del libro Azul del CCITT. Define las funciones, mensajes y procedimientos de señalización requeridos para proporcionar los servicios y las facilidades de usuario que precisan conexiones por conmutación de circuitos tanto para aplicaciones vocales como no vocales en la Red Digital de Servicios Integrados nacional. Además, la PU-RDSI se utilizará también en la red telefónica conmutada, tanto en conexiones digitales extremo a extremo como en la red mixta analógico/digital. Dentro de la arquitectura funcional del Sistema de Señalización por Canal Común, la PU-RDSI utiliza los servicios de red proporcionados por la Parte de Transferencia de Mensajes (PTM). La presente versión de la PU-RDSI no utilizará Parte de Control de la Conexión de Señalización (PCCS) para la transferencia de información entre PURDSI's. A su vez, la PU-RDSI proporciona su servicio a una entidad superior que denominaremos Control (de la llamada). Además del servicio básico, la PU-RDSI soporta diferentes Servicios Suplementarios: - Identificación del número llamante - Restricción de la identificación del número llamante - Identificación del número conectado - Restricción de la identificación del número conectado - Desvío de llamadas - Grupo cerrado de usuarios - Llamada en espera - Información de Usuario a Usuario - Subdireccionamiento - Retención, consulta y recuperación - Conferencia de a tres - Portabilidad de terminales - Red privada virtual
26
Los mensajes de la PU-RDSI se transportan en el enlace de señalización mediante unidades de señalización cuyo formato se describe en el capítulo III de la Especificación correspondiente a la PTM. El formato del octeto de información de servicio y los códigos utilizados en estos octetos, se describen con más detalle a continuación en consideración a los mensajes más comunes dentro del tráfico de la red. El indicador de servicio para la parte usuario RDSI se codifica 0101. El campo de información de señalización de cada unidad de señalización de mensaje que contiene un mensaje de la PU-RDSI está constituido por un número entero de octetos y tiene los siguientes componentes. ETIQUETA DE ENCAMINAMIENTO Las etiquetas de todos los mensajes correspondientes a una conexión de circuito determinada deberán ser iguales. El código de punto de destino (CPD) indica el punto de destino del mensaje y el código de punto de origen (CPO) señala el punto de origen del mensaje. La estructura de etiqueta normalizada, requiere que a cada nodo de la red se le asigne un código de PS del plan de codificación nacional. Se utilizarán planos de codificación separados para la red de señalización nacional y para la red de señalización internacional. La asignación de estos códigos se hace conforme a: a) La "Norma de Numeración de Códigos de Puntos de Señalización para la Red de Señalización por Canal Común", en la red de señalización nacional. b) La Recomendación Q.708 del Libro Azul del C.C.I.T.T. "Numeración de códigos de puntos de señalización internacional", para la red de señalización internacional.
27
Para la atribución de códigos de identificación de circuito a circuitos individuales deben seguirse las disposiciones adoptadas por acuerdo bilateral, o reglas predeterminadas. Para aplicaciones internacionales, los cuatro bits de reserva se utilizan para la ampliación del CIC, siempre que se obtenga un acuerdo bilateral antes que se aumente el tamaño. Para aplicaciones nacionales, los cuatro bits de reserva pueden utilizarse cuando se necesiten. En un trayecto digital a 2048 kbit/s para circuitos derivados del enlace (Recomendaciones G.732 y G.734, Libro Azul del CCITT), el código de identificación de circuito contiene, en los cinco bits menos significativos, una representación binaria del número real del intervalo de tiempo asignado al trayecto de comunicación. Los bits restantes del código de identificación de circuito se utilizan, cuando es necesario, para identificar unívocamente el circuito entre todos los otros circuitos de otros sistemas que interconectan un punto de origen y uno de destino.
28
29
30
31
PARTE OBLIGATORIA FIJA La parte obligatoria de longitud fija comprende los parámetros que son obligatorios y tienen una longitud fija para un determinado tipo de mensaje. La posición, longitud y orden de los parámetros vienen definidos unívocamente por el tipo de mensaje. Por tanto, los nombres de los parámetros y los indicadores de longitud no se incluyen en el mensaje. PARTE OBLIGATORIA VARIABLE Los parámetros obligatorios de longitud variable están incluidos en la parte obligatoria de longitud variable. Se utilizan punteros para indicar el principio de cada parámetro. Cada puntero se codifica con un solo octeto. El nombre de cada parámetro y el orden en que se envían los punteros están implícitos en el tipo de mensaje. Por tanto, los nombres de los parámetros no están incluidos en el mensaje. El número de parámetros y, por consiguiente, el número de punteros, está definido unívocamente por el tipo de mensaje. Se incluye también un puntero que tiene por función indicar el principio de la parte facultativa. Si el mensaje no admite una parte facultativa, no aparecerá este puntero. Si el tipo de mensaje admite una parte facultativa (reflejada por la presencia de un octeto de fin de parámetros facultativos en los cuadros 2/IV a 34/IV), pero en el mensaje considerado no se ha incluido una parte facultativa, el campo del puntero se codificará a cero. Todos los punteros se envían consecutivamente al principio de la parte obligatoria variable. Cada parámetro contiene el indicador de longitud de parámetro seguido del contenido del parámetro. En la figura vemos el órden de transmisión de los bits de acuerdo con los formatos que hemos analizado hasta ahora en los cuadros anteriores, respetando la posición y los segmentos que corresponden a las distintas partes.
32
PARTE FACULTATIVA La parte facultativa está constituida por parámetros que pueden o no estar presentes en un determinado mensaje. Esta parte puede comprender parámetros de longitud fija y parámetros de longitud variable. Los parámetros facultativos se pueden transmitir en cualquier orden. Cada uno de estos parámetros estará constituido por el nombre de parámetro (un octeto) y el indicador de longitud (un octeto) seguido del contenido del parámetro. OCTETO DE FIN DE PARÁMETROS FACULTATIVOS Si existen parámetros facultativos, después de transmitidos todos ellos, se transmitirá el octeto de fin de parámetros facultativos, codificado a cero. Si el mensaje no tiene definido una parte facultativa, no se transmite este octeto.
33
Estos acrónimos con las respectivas descripciones y los códigos binarios son una parte de todos los mensajes que conforman el protocolo de SS7. Esta información corresponde al contenido del primer octeto inmediato siguiente a la etiqueta de encaminamiento y el código de identificación de circuito. Define cual es el mensaje en cuestión. A continuación de este octeto, definido cual es el mensaje, comienza el desarrollo del mensaje con una extensión variable según la cantidad y el tipo de los parámetros que componen cada uno de los mensajes. Existen parámetros de longitud fija y obligatorios, como parámetros de longitud variable, optativos pero con carácter de cuasi obligatorios. Los distintos parámetros están formados por octetos y tienen los contenidos que arman el mensaje con la correspondiente interpretación para establecer el diálogo entre las centrales, realizar la activación y el control del enlace de señalización y la supervisión de las comunicaciones de los usuarios. El ajuste de estos parámetros son los factores que se deben customizar para que los conmutadores de nuestro país dialoguen correctamente entre ellos. Vamos a analizar algunos parámetros en desglose, viendo un cuadro de los que están catalogados en las documentaciones de la CNC con los acrónimos sólo en castellano para no cargar excesiva información en este curso. El primer octeto del contenido de los parámetros es el que define cual es ese parámetro y es el valor binario que debemos analizar para saber y leer correctamente los contenidos del mensaje. Para poder analizar el contenido de algunos parámetros los debemos relacionar con alguno de los mensajes como el MID (IAM), MDC (ACM) o RST (ANM).
34
Capa física (MTP – nivel 1) Capa de enlace (MTP – Nivel 2) Métodos básicos de control de errores. CRC Unidad de señalización de estado del enlace (LSSU) Procedimiento de alineamiento de señales Capa de red (MTP – Nivel 3) Partes de transferencia de mensaje (MTP) Señalización en capa de enlace Unidades de señalización Tipos de mensajes de señalización y de administración Identificación de nodo de red SS7 Procedimiento normal de enrutamiento Administración de enlaces, rutas y tráfico Parte de control de conexión de señalización (SCCP) Enrutamiento y discriminación. Enrutamiento global de títulos Administración de subsistemas Control de flujo Servicios orientados a conexión y no-orientados a conexión Traducción de títulos globales Administración y estructura de SCCP. Tipos de mensajes, funciones y parámetros Fundamentos de una conexión SCCP Parte de usuario telefónico (TUP) e RDSI (ISUP) Parte de Usuario Servicios ISUP Establecimiento y terminación de llamadas Control de conexión
35
• •
•
MTP-1 Capa 1: Tiene las funciones de conexión física entre módulos a interconectar. MTP-2 Capa 2: Se ocupa del alineamiento de paquete mediante banderas (Flag) al inicio y final. Permite la detección de errores mediante un código CRC-16. Realiza el proceso de numeración secuencial de mensajes e indicación de retransmisión. Efectúa la confirmación o rechazo del mensaje para la retransmisión automática en mensajes con errores. Los paquetes son numerados en forma secuencial con módulo-7. Indica la longitud total del mensaje transmitido. MTP-3 Capa 3: Posee una dirección de punto de acceso al servicio SAP en la información de servicio SIO. SAP permite identificar a la capa superior SCCP sobre el protocolo MTP3. En la red PSTN se dispone de las direcciones de procesador CPU de origen y destino (14 bits de dirección). Por otro lado identifica el enlace de señalización utilizado cuando existe más de uno. Realiza las funciones de Routing dentro de la red de señalización SS7.
36
37
38
39
40
41
42
43
44
Facilita la transferencia de mensajes en tiempo real entre MSC, HLR y VLR. Se aplica también para enlaces con O&M. En tarjetas de crédito permite verificar la autenticidad y movimientos de cuenta. Realiza el control de diálogo con el terminal remoto. Es un servicio de transporte. La información contiene: tipo de mensaje (unidireccional, inicio, final, intermedio, aborto); longitud del mensaje (número de bytes total); identificador de origen y destino de transacción; tipo de componente (retorno de resultado, reporte de error y de reject) y contenido de información (código de operación, de error, de problema, parámetros, etc).
45
46
47
48
Las redes PSTN son fijas. La línea de un abonado está fijada (conectada) a una central local, q ue tiene un registro de cada uno de sus abonados. El registro contiene datos semipermanentes y temporarios. Los datos semipermanentes incluyen el número del abonado y su perfil de servicio. Existe una lista de características (por ejemplo llamada en espera, etc.) vigentes en el contrato de servicio con el abonado. Los datos temporales incluyen información acerca del estado actual del abonado (ocupado, libre, bloqueado) y durante los momentos en que se realiza una llamada, detalles de la conexión. La central consulta estos datos cuando procesa las llamadas de los abonados. Cuando un MSC atiende a un abonado móvil (MS), requiere datos similares. Sin embargo, un MS es “móvil”. En diferentes momentos, puede estar en el área de servicio de diferentes MSC. No es práctico almacenar la información de todos los móviles en cada MSC. En su lugar, la información se almacena en bases de datos centralizadas. Uno de los propósitos de las transacciones MAP es permitir a las MSC la obtención de información acerca de un MS desde dichas bases de datos. La versión de MAP de uso en redes GSM se conoce como GSM-MAP. MAP permite las operaciones de: Actualización de localización; Roming; Handover; autentificación; información de llamada entrante; información de servicio de subscriptor; identificación de equipos móviles; carga de información a los registros; etc
49
MAP-B: Entre el MSC y su VLR asociado: La interfaz es “interna” y la transferencia de mensajes no involucra a la red de señalización. Esta interfaz no está estandarizada por ETSI o 3GPP MAP-C: Entre el MSC Gateway (GMSC) y el HLR: Esta interfaz es necesaria para el establecimiento de llamadas terminadas en MS. A través de esta interfaz el GMSC inquiere la locación actual del usuario del HLR, y el HLR entrega el MSC con un Número de Roaming de Abonado Móvil (MSRN) necesario para setear la conexión conmutada del circuito entre el GMSC y el MSC que atiende al abonado. MAP-D: Entre el VLR y el HLR: Esta interfaz está involucrada tanto en las aplicaciones de Administración de Conexión (CM) como de Administración de Movilidad (MM) CM : A través de esta interfaz el HLR pide al VLR que asigne e informe un número de roaming (MSRN) que será usado para el establecimiento de una llada terminada en Móvil MM : Esta interfaz puede utilizarse también durante una actualización de ubicación entre VLR´s cuando los VLR actualizan el HLR (en otras palabras, los VLR informan al HLR respecto a cambios en la ubicación del usuario), o bien cuando el HLR elimina información en el VLR “ antiguo”. MAP-E: Entre MSCs en una PLMN: Esta interfaz se usa durante operaciones de handover entre MSC. (Adicionalmente, la interfaz E involucra ISUP). MAP-F: Entre MSC y EIR: Esta interfaz transporta información para verificación de lndentidad del MS. MAP-G: Entre dos VLR: Por ejemplo, en el caso de actualizaciones de ubicación entre VLR, el “nuevo” VLR puede solicitarle al “viejo” VLR información relevante del usuario.
50
En los países con redes GSM se implementa un plan de numeración para la telefonía fija y un plan separado para la PLMN. En la red fija (PSTN), un móvil es identificado mediante un MSISDN, que tiene un formato definido en la Rec. E.164 del ITU-T. El MSISDN es un número internacional, consistente en un código de país CC y un número nacional NN. El número de roaming de la estación móvil (MSRN) utilizado por la red fija para extender el establecimiento de llamada al MSC que está sirviendo en ese momento al MS llamado, es un número nacional o internacional E.164. En la PLMN, un MS se identifica mediante una Identidad Internacional de Estación Móvil (IMSI) o mediante la combinación de un Identificador de locación de área (LAI) y una Identidad Temporaria de Estación Móvil (TMSI). El formato de IMSI se define en la E.212 como: IMSI = MCC_MNC_MSIN, donde la combinación del código de país móvil MCC y el código de red móvil MNC identifica la red PLMN original del MS, y el MSIN es la identidad de estación móvil que identifica al móvil dentro de dicha PLMN. El IMSI es un número internacional que identifica unívocamente a un móvil globalmente. En su país de origen, el MS puede identificarse unívocamente mediante la identidad de estación móvil nacional (NMSI): NMSI=MNC_MSIN. El MSISDN, IMSI y NMSI identifican a un MS de manera permanente. Adicionalmente, una combinación de la Identidad de Locación de Area (LAI) y la Identidad temporaria de estación móvil identifica al MS durante el tiempo en que es atendido por el VLR que cubre el área de servicio. El formato de LAI es: LAI=MCC_MNC_LAC, donde MCC_MNC identifica un PLMN en particular y el código de área local (LAC) representa la locación en dicha PLMN. TMSI es un número binario de 32 bits que identifica al MS mientras está operando en un área en particular.
51
52
Las redes GSM se estructuran jerárquicamente. Consisten principalmente de por lo menos una región administrativa, asignada a un Centro de Conmutación Móvil (MSC). Cada región administrativa se construye con por lo menos un Area de Localización (LA), también llamada a veces área visitada. Un LA consiste de numerosos grupos de celdas. Cada grupo de celdas se asigna a un Controlador de Estaciones Base (BSC). Por lo tanto para cada LA existe por lo menos un BSC, pero las celdas de un BSC pueden pertenecer a diferentes LA. El particionamiento exacto del área de servicio en celdas y su organización o administración referida a los LA, BSC y MSC es, sin embargo no únicamente determinada y se deja al criterio de cada operador de red que tendrá entonces numerosasa posibilidades de optimización. En la figura se ve la construcción jerárquica de un sistema GSM. La celda está formada por la cobertura inalámbrica de una Estación Base (BTS). Un BSC controla numerosas estaciones base. El tráfico combinado de las estaciones móviles en sus celdas respectivas es enrutado a través de una central, la Central de Conmutación Móvil (MSC). Las llamadas originadas en o terminadas en la red fija son administradas por una Central de Transferencia de Conmutación Móvil (GMSC). La operación y mantenimiento se organizan desde un punto central, el Centro de Operación y Mantenimiento (OMC). A efectos de realizar el control de llamadas y administración de red se definen varias bases de datos: • Home Location Register (HLR) • Visited Location Register (VLR) • Authentication Center (AUC) • Equipment Identity Register (EIR) Para todos los abonados registrados en un operador de red, el HLR almacenará datos permanentes (como el perfil de servicio del usuario) y datos temporarios (como la ubicación actual del usuario). Cuando se produce una llamada al usuario, en primer lugar se consulta al HLR para determinar la ubicación actual del usuario. Un VLR es responsable por un grupo de LA y almacena los datos de los usuarios que están actualmente en su área de responsabilidad. Esto incluye parte de los datos permanentes del abonado que fue transmitida desde el HLR al VLR para ser accedida rápidamente. Pero el VLR también podrá asignar y almacenar datos locales como ser identificación temporaria. El AUC genera y almacena datos relacionados con la seguridad como ser llaves para autenticación y encripción, El El EIR registra datos de los equipos en lugar de datos de abonados.
53
Un sistema GSM tiene dos componentes principales: La infraestructura de red fija (La red en su sentido estricto) y los abonados móviles, que utilizan los servicios de la red y se comunican a través de la interfaz de radio (interfaz de aire). La red fija instalada GSM puede a su vez subdividirse en tres subredes: La red de radio, la red de conmutación móvil y la red de administración. Estas subredes se llaman subsistemas en el estándar GSM: Subsistema de Estaciones Base (BSS), Subsistema de Conmutación y Administración (SMSS) y Subsistema de Operación y Mantenimiento (OMSS).
54
Aquí se ven los componentes de la red de radio GSM. Una Celda GSM se exande en el área de radio de la Estación Transceptora Base (BTS) . La BTS provee los canales de radio para señalización y tráfico de datos de usuario en la celda. Por lo tanto la BTS es la parte de red de la interfaz de aire GSM. Además de la parte de alta frecuencia (Equipamiento transmisor y receptor), contiene otros pocos componentes para procesar la señal y los protocolos. Por ejemplo, se realiza la codificación de protección de errores y se termina el protocolo de enlace de datos LAPDm para la señalización del camino de radio. Para mantener pequeño el tamaño de las BTS, es esencial que las entidades de control y protocolos residan en el Controlador de Estaciones Base (BSC) . Por ejemplo, el protocolo de handover se ejecuta en la BSC: Las BTS y la BSC forman juntas el Subsistema de Estaciones Base (BSS). Una BSC puede controlar numerosas BTS. A cada BTS se le asigna un conjunto de canales de frecuencia, la Asignación de Celda (CA). Se disponen dos tipos de canales en la interfaz de radio: Canales de tráfico y canales de señalización. Para los canales de tráfico, el BSS básicamente entrega las funciones de capa 1 del esquema OSI.
55
El Subsistema de Conmutación y Administración Móvil (SMSS) consiste de los centros de conmutación móvil y las bases de datos que almacenan los datos requeridos para el enrutamiento y provisión de servicios. Centro de Conmutación Móvil El nodo de conmutación de una PLMN GSM es el Centro de Conmutación Móvil (MSC). El MSC realiza todas las funciones de conmutación de un nodo de conmutación de red fija, por ejemplo, búsqueda del camino de enrutamiento, enrutamiento de señalización, y procesamiento de características de servicio. La diferencia principal entre un conmutador ISDN y un MDC es que éste último además debe considerar la ubicación y administración de los recursos de radio y la movilidad de los abonados. Por lo tanto debe implementar funciones adicionales para el registro de la ubicación de los abonados y el handover de una conexión en el caso que cambie de una celda a otra. Una PLMN puede tener numerosos MSC siendo cada uno responsable por una parte del Area de Servicio. Los BSC de cada BSS están subordinados a una única MSC. El traspaso de tráfico vocal entre las redes fijas y móviles es manejado por un MSC dedicado: el GMSC. Si la red fija no puede conectar una llamada entrante al MSC local (debido a su inposibilidad de interrogar al HLR), enrutará la conexión al GMSC más próximo. El GMSC requerirá la información de enrutamiento del HLR y enrutará la conexión al MSC local en cuya área esté en ese momento la estación móvil. Las conexiones hacia otras redes móviles o redes internacionales se enrutan principalmente a través del Centro de Conmutación Internacional (ISC) del país. Una unidad funcional asociada con un MSC permite la interoperación de una PLMN y las redes fijas (PSTN, ISDN, PDN). Esta Función de Interoperación (IWF) realiza una cantidad de funciones dependiendo del servicio y de la red fija a la que se conecta. Es necesario mapear los protocolos de la PLMN hacia aquellos de la red fija respectiva. En caso de tener ambas implementaciones compatibles, la IWF no realiza ninguna función.
56
Una PLMN GSM tiene numerosas bases de datos. Se definen dos unidades funcionales para el registro de los abonados y su ubicación actual: El Home Location Register (HLR) y el Visitor Location Register (VLR). En general, existe un HLR principal para una PLMN y un VLR para cada MSC. Esta organización depende del número de abonados, la capacidad de procesamiento y almacenamiento de las centrales de conmutación y la estructura de la red. El HLR tiene registros para cada abonado y cada número móvil que tiene su “hogar” en su red respectiva. Almacenará los datos permanentes y datos temporarios relevantes de todos los abonados registrados permanentemente en el HLR. Además de los datos fijos como subscripciones y permisos de servicio, los datos almacenados incluyen enlaces a la ubicación actual del abonado móvil. El HLR se requiere como registro central para enrutar a los abonados para los cuales tiene responsabilidad administrativa. El HLR no tiene control directo sobre una MSC. Todas las actividades administrativas concernientes a un abonado se realizan en las bases de datos del HLR. El VLR como registro de visita almacena los datos de todas las estaciones móviles que están actualmente en el área administrativa del MSC asociado. Un VLR puede ser responsable por las áreas de uno o varios MSC. Las estaciones móviles hacen roaming libremente, y por lo tanto, dependiendo de su ubicación, pueden estar registrados en uno de los VLR de su ubicación “hogar” o bien en un VLR de una red de otro operador (si existen acuerdos de roaming entre ambos operadores). Para dicho propósito, la MS debe iniciar un procedimiento de registro cuando ingresa a un LA. El MSC responsable pasa la identidad del MS y su LAI actual al VLR, que los incluye en su base de datos y registra al MS. Luego se informa al HLR que entonces podrá enrutar las llamadas entrantes hacia el MS.
57
La operación de red se controla y administra mediante el Subsistema de Operación y Mantenimiento (OMSS). Las funciones de control de red se monitorean e inician desde un Centro de Operación y Mantenimiento (OMC). Veamos algunas de sus funciones: • Administración y operación comercial (Abonados, terminales, tarifación, estadísticas) • Administración de seguridad • Configuración de red, operación y administración del rendimiento • Tareas de mantenimiento La administración de la red puede estar centralizada en uno o varios Centros de Administración de Red (NMC). Las funciones de operación y mantenemiento se basan en los conceptos de la TMN (ITU-T M.30). Autenticación de usuarios y registro de equipos Se definen dos bases de datos adicionales en GSM además del HLR y VLR. Son responsables de varios aspectos de la seguridad del sistema. En GSM la seguridad se basa principamente en la verificación del equipo y del abonado. Estos datos son manejados por dichas bases de datos: Los datos confidenciales y llaves de seguridad se almacenan o generan el el Centro de Autenticación (AUC). Estas llaves sirven para la autenticación del usuario y autorizan los accesos a los servicios respectivos. El Registro de Identidad de Equipamientos (EIR) almacena los números de serie (provistos por los fabricantes) de los terminales (IMEI), lo que hace posible verificar a estaciones móviles con software obsoleto o bloquear acceso a los servicios a unidades reportadas como robadas.
58
Las conexiones fijas para el transporte de la señalización y datos de usuario en una PLMN GSM son líneas de transmisión estándar. Se utilizan enlaces de 2Mb/s y 64 kb/s. La señalización tiene dos partes fundamentalmente diferentes: Señalización específica de GSM dentro del BSS incluyendo la interfaz de aire, y señalización dentro del SMSS y con otros PLMN en conformidad con el SS7. Las conexiones de datos de usuario son procesadas utilizando ISUP. Para la señalización específica de la red móvil, el MSC, HLR y VLR utilizan extensiones MAP de SS7. La señalización entre el MSC y el BSS utiliza la Parte de Aplicación del Sistema de Estaciones Base (BSSAP). Dentro del BSS y en la interfaz de aire, la señalización es específica del sistema móvil y no se utilizan protocolos SS7 para transportar la señalización.
59
La gran cantidad de relaciones de comunicación para el transporte de datos de usuario y señalización requirió separarlas introduciendo una cantidad de interfaces: La interfaz A entre BSS y MSC se utiliza para transferir datos de administración del BSS, control de conexiones y administración de la movilidad. Dentro del BSS, se definen la interfaz Abis entre las BTS y el BSC y la interfaz de aire Um. Un MSC que requiere obtener datos de una MS que está dentro de su área administrativa, solicita los datos del VLR responsable por esa área a través de la interfaz B. Por otro lado el MSC le envía al VLR cualquier dato genereado durante las actualizaciones de locación de las estaciones móviles. Si el abonado reconfigura características especiales del servicio o bien activa servicios suplementarios, el VLR se informa primero, y luego actualiza el HLR, lo que ocurre a través de la interfaz D. Esta interfaz se utiliza para el intercambio de datos de abonado dependientes de la locación y para administración de abonados. El BLR informa al HLR acerca de la locación actual de los abonados móviles y reporta el MSRN actual. El HLR transfiere todos los datos del abonado al VLR necesarios para brindar su acceso personalizado a los servicios. El HLR también es responsable de enviar un pedido de cancelación al VLR para los datos de abonado una vez que se recibe el reconocimiento de la actualización del nuevo VLR. Si durante la actualización de localización el nuevo VLR requiere datos del viejo VLR, los solicita directamente a través de la interfaz G. Además, la identidad del abonado o su equipamiento puede verificarse durante una actualización de locación.; para lo cual el MSC dispone de la interfaz F hacia el EIR. Un MSC dispone de dos interfaces adicionales además de la A y B, llamadas interfaces C y E. La información de tarifación puede enviarse por la interfaz C al HLR. Además, el MSC debe poder requerir información de enrutamiento al HLR durante el establecimiento de llamadas, para llamadas desde la red móvil como también para llamadas desde la red fija. En el caso de llamadas desde la red fija, si la central de red fija no puede interrogar al HLR directamente, enruta la llamada inicialmente al GMSC, el que interrogará al HLR. Si un MS cambia durante una conversación de un área de MSC a otra, se requiere un handover entre las dos MSC, el que se realizará a través de la interfaz E.
60
Los servicios ofrecidos en el punto de interfaz de red a usuario (UNI) de GSM están diagramados en base a los servicios ofrecidos por la RDSI para terminales fijos acoplados a líneas telefónicas. Los servicios GSM se dividen por lo tanto como los servicios RDSI en tres categorías: Servicios básicos (Bearer services), Teleservicios y Servicios Suplementarios. Un Servicio Básico ofrece la capacidad técnica de transmitir datos binarios, es decir ofrece la transferencia de datos entre los terminales en los puntos de referencia S y R del modelo de referencia. Estos servicios básicos son utilizados por los teleservicios para la transferencia de datos con protocolos de mayor nivel. Se debe notar que tanto los servicios básicos como los teleservicios requieren medidas especiales no sólo en la interfaz de aire, sino también dentro de la PLMN, la que deberá ofrecer una infraestructura acomodada a la red fija y proveer funciones de interoperabilidad de redes (IWF). Especialmente al nivel de los servicios básicos, la IWF deberá proveer un mapeo de los servicios de la PLMN GSM dentro de sus respectivas características de servicios a os servicios básicos y características de otras redes, como ser PSTN e ISDN. Los teleservicios son servicios de extremo a extremo, para los cuales usualmente no se requiere translación en la IWF. Pero sí utilizan servicios básicos, los que requerirán de todas maneras de las funciones IWF. Los servicios básicos y teleservicios se transportan dentro del marco de los Servicios de telecomunicaciones. Se excluye el uso simultáneo de dos servicios de telecomunicaciones, excepto para el caso de los SMS, que pueden por lo menos ser recibidos durante la utilización de otro servicio de telecomunicaciones. Los servicios suplementarios complementan el control y modificación de los servicios extendidos y sólo se pueden utilizar en conexión con un servicio de telecomunicaciones.
61
Servicios básicos Los servicios básicos de la red GSM son la base para la transmisión de datos, es decir, los servicios básicos proven las capacidades técnicas fundamentales en la interfaz terminal (Punto de referencia R) a las cargas de transporte de datos de usuario. Los servicios básicos GSM ofrecen capacidades de transporte de datos asíncrono o síncrono en formato de conmutación de circuitos o de paquetes a tasas de transferencia entre 300 a 9600 b/s, con un servicio de 13 kb/s para voz. Los servicios básicos realizan únicamente el transporte de información independiente de la aplicación y la codificación entre las interfaces de usuario a red. Representan los servicios de Capa 1, 2 y 3 del modelo de referencia OSI. Los operadores del Equipamiento Terminal (TE) pueden utilizar dichos servicios y emplear protocolos de mayor nivel de manera arbirtraria, pero son responsables de la compatibilidad de los protocolos utilizados en el equipamiento terminal, en contraste con los teleservicios, en donde los protocolos de los equipamientos terminales también están estandarizados. Cada servicio básico tiene su número como se ve en la tabla. Además de los servicios de datos conmutados por circuitos asíncronos y síncronos (BS21-BS34), también se dispone de servicios de datos conmutados por paquetes. Estos servicios se implementan bien a través de acceso asíncrono por medio de un PAD (BS41-BS46) o como acceso de paquetes directo síncrono (BS51-BS53). Los servicios básicos para la transferencia de datos GSM se ofrecen en dos modos fundamentalmetne diferente: Transparente (T) y No Transparente (NT). En el modo transparente, se crea una conexión conmutada por circuito entre el terminal móvil (TE) y el módulo de interoperabilidad en la MSC, desde donde se maneja la conexión con otras redes. Esta conexión se proteje mediante FEC. Las características más importantes de todos los servicios transparentes son Tasa de transferencia constante (CBR), retardo de transporte constante, y BER residual dependiente de las condiciones de canal. El modo no transparente activa un protocolo de capa 2 especial para la protección adicional de la transferencia de datos, el Protocolo de enlace de radio (RLP), que está especialmente adaptado al canal de radio GSM. Este protocolo es terminado en la MS y en la MSC. Utiliza procedimientos ARQ para solicitar la retransmisión de bloques con errores residuales que no pudieron corregirse mediante FEC. Otros servicios importantes contienen el servicio vocal (telefonía) – BS61 a BS81, que puede intercambiarse numerosas veces durante una llamada a pedido del usuario a servicios de datos (datos/voz alternada). Otra alternativa es que el usuario establezca una llamada vocal y luego la cambia a una sesión de datos que no podrá volver atrás (Voz seguida de datos).
62
Por encima de los servicios básicos, que pueden utilizarse por sí mismos, se definen una cantidad de teleservicios. Las categorías más importantes son: voz, SMS, Acceso a Sistemas de Manejo de Mensajes (MHS) , videotexto, teletexto y transferencia de fax. Servicios Vocales Se distinguen dos categorías: Servicios telefónicos regulares (TS11) y servicios de Emergencia (TS12). Respecto a la transmisión de señales vocales codificadas digitalmente, ambos servicios utilizan conexiones punto a punto full dúplex, simétricas bidireccionales. La única diferencia es que los servicios regulares requieren una IWF internacional, mientras que los servicios de emergencia permanecen dentro de las fronteras de la red nacional. Servicios de Mensaje Corto Los servicios de mensaje corto SMS están definidos en TS21 y TS22. TS21 es la versión punto a punto del SMS, que permite enviar a una estación individual un mensaje de hasta 160 caracteres. A su vez el TS22 se definió como implementación opcional para el envío de mensajes desde la estación móvil. Para SMS, el operador móvil debe establecer un centro de servicios que acepte los mensajes cortos de la red fija y los procese en un modo de almacenamiento y reenvío. A su vez, el centro de servicios podrá aceptar mensajes cortos desde los MS y retransmitirlos a la red fija. La transmisión de SMS utiliza un protocolo de conmutación de paquetes no orientado a la conexión protegido. Estos teleservicios son los únicos que pueden utilizarse simultáneamente con otros servicios, es decir por ejemplo se podrán recibir SMS mientras se está cursando una llamada.
63
Los servicios suplementarios en GSM corresponden a los servicios suplemntarios de la RDSI en cuanto a características y rendimiento. Pueden utilizarse únicamente en conexión con un teleservicio, es decir modifican o suplementan la funcionalidad de un servicios de telecomunicaciones de GSM (Básico o teleservicio).
64
Además de mejoras en la organización de la red, la introducción de numerosos servicios suplementarios del estilo RDSI es la característica principal de la fase 2 de GSM. Algunos servicios suplementarios GSM son idénticos o similares a aquellos de la RDSI, pero su implementación es a menudo mucho más compleja debido al agregado de la movilidad. Más allá de eso, GSM ofrece nuevas características de servicios disponibles en la RDSI en forma limitada o nula.
65
El beneficio principal para los abonados móviles derivado de la estandarización internacional de GSM es que pueden moverse libremente no sólo dentro de sus redes sino también en otras redes de su país u otros países y al mismo tiempo acceder a los servicios especiales suscriptos en su red de origen, siempre que existan acuerdos entre los operadores. Las funciones requeridas para este desplazamiento libre se llaman funciones de movilidad o roaming. Se basan principalmente en extensiones específicas de GSM sobre el protocolo SS7. Los procedimientos relevantes para movilidad de la Parte de Aplicaciones Móviles Móviles (MAP) son la Registración/actualización de Locación , la vinculación/desvinculación de IMSI , los pedidos de datos de abonado para establecimiento de llamadas y el paging. Adicionalmente, Adicionalmente, MAP contiene funciones y procedimientos para el control de servicios suplementarios suplementarios y handover, para administración administra ción de abonados e IMEI, autenticación e identificación, identificac ión, así como el transporte de datos de usuario de los SMS. La administración de los datos de movilidad son la base para crear las funciones requeridas para enrutar y conmutar las conexiones de usuarios y sus servicios asociados. Por ejemplo, son necesarias para enrutar una llamada entrante al MSC actual o para localizar un MS antes de comenzar el proceso de paging.
66
El número discado para ubicar a un abonado móvil (MSISDN) no contiene ninguna información acerca de la ubicación actual del abonado. A efectos de establecer una conexión completa con el abonado móvil, se debe determinar su ubicación actual y el MSC responsable. Para enrutar la llamada a dicho MSC, se debe obtener la dirección de enrutamiento del abonado (MSRN). Dicha dirección es asignada temporariamente al abonado por el VLR asociado en ese momento. Una vez que llega una llamada al GMSC, el HLR es la única entidad en la red GMS que puede proveer dicha información, y por lo tanto deberá ser interrogado para cada establecimiento de conexión a un abonado móvil. A continuación se describe la secuencia de operaciones para enrutar una llamada al abonado móvil. Una central ISDN reconoce a partir del MSISDN que el abonado llamado es un móvil, y reenvía la llam ada al GMSC de la PLMN correspondiente al área local del abonado basado en el CC y NDC del MSISDN. (1). El GMSC pide la dirección de enrutamiento actual (MSRN) del abonado móvil al HLR a través de MAP (2,3). Mediante el MSRN la llamada se reenvía al MSC local (4), que determina el TMSI del abonado (5,6) e inicia el procedimiento de paging al área de localización relevante (7). Luego que la estación móvil responde a la llamada de paging (8), es posible establecer la conexión. Existen varias posibilidades para determinar la ruta e interrogar al HLR, dependiendo de cómo se asignó y almacenó el MSRN, si la llamada es nacional o internacional, y dependiendo de las prestaciones de los centros de conmutación asociados. Existen dos maneras de obtener el MSRN: • En actualizaciones de locación • En cada llamada Para la primera variante, el MSRN de la estación móvil es asignado al momento en que se almacena cada actualización de locación en el HLR. De esta manera el HLR está en condiciones de entregar inmediatamente la información de enrutamiento requerida requerida para conmutar la llamada al MSC local. La segunda variante requiere que el HLR tenga por lo menos la identificación del VLR actual. En ese caso, cuando se le solicita información de enrutamiento, el HLR deberá obtener en primer lugar el MSRN del VLR. Este MSRN se asigna por cada llamada, es decir, cada llamada involucra la asignación de un MSRN.
67
68
69
Fase 1 La estandarización de la Fase 1 de GSM se completó en 1990 para GSM900 y 1991 para GSM1800. Esta fase inicial introdujo toda la infraestructura necesaria para soportar llamadas vocales, algunso servicios básicos como derivación y rechazo de llamadas, y transmisión de datos a velocidades entre 0,3 a 9.6 kb/s. También estandarizó el servicio de SMS, si bien no todos los operadores lo soportaron inicialmente. De esta manera se dio a los operadores la oportunidad de comenzar a generar ingresos mientras se continuaba con el desarrollo del estándar GSM. Fase 2 Luego de completar la fase 1 se comenzó rápidamente la fase 2 que se completó en 1995 e introdujo mejoras sustanciales en GSM. Se agregaron un conjunto completo de servicios suplementarios al estilo de RDSI, y se introdujo el códec de Half-Rate. Fase 2+ La fase 2 representó una actualización completa del estándar GSM. La fase 2+ representa una aproximación diferente a la evolución del estándar. Se desarrollan de manera separada nuevas recomendaciones direccionadas a tópicos específicos y se agregan al estándar de manera anual. De esta manera se agregaron GPRS, ASCI, SOR, UUS, EFR, CAMEL, HSCSD y EDGE. Un error común es suponer que WAP pertenece a la fase 2+. Si bien el protocolo de aplicaciones inalámbrico (WAP) arribó dentro del calendario de la fase 2+, no es parte de las especificaciones GSM. WAP se diseñó para permitir el acceso a Internet móvil, independientemente de la tecnología de acceso (GSM, GPRS, UMTS, etc.). WAP realiza una interfaz entre el protocolo “ hambriento de recursos” TCP/IP utilizado en Internet y un protocolo de acceso altamente eficiente. (TCP/IP puede utilizar hasta un 40% del ancho de banda para control de flujo, lo que no es obviamente deseable en la interfaz de aire).
70
Fundamentos de GPRS
En su forma más simple, GSM administra comunicaciones vocales y de datos a través de conexiones conmutadas por circuitos. El Servicio General de Radio Paquetizada (GPRS) es una extensión de GSM que permite a los abonados enviar y recibir datos a través de conexiones conmutadas por paquetes. La utilización de GPRS es particularmente apropiada para aplicaciones con las siguientes características: Transmisiones impulsivas (para las cuales el tiempo entre transmisiones sucesivas excede grandemente el • retardo promedio de transferencia) • Transmisiones frecuentes de bajos volúmenes de datos • Transmisiones infrecuentes de grandes volúmenes de datos Estas aplicaciones no requieren usualmente comunicación permanente. Consecuentemente, la reserva continua de recursos de una conexión conmutada por circuitos no representa una manera eficiente de aprovechar los escasos recursos de radio. El concepto básico detrás de la transmisión GPRS está en su habilidad de permitir a las aplicaciones seleccionadas compartir los recursos de radio asignándolos para transmitir sólo cuando las aplicaciones tienen datos para transmitir. Una vez que los datos se transmitieron, se liberan los recursos de radio para su uso por otras aplicaciones. GPRS permite asignar más recursos de radio a una conexión conmutada por paquetes que a una conexión conmutada por circuitos en GSM. De esta manera se logran mayores velocidades de transferencia (hasta 171.2 Kbps) utilizando una configuración multislot. Las mayores ventajas de GPRS surgen del hecho que utiliza Conmutación de Paquetes: Debido a que los dispositivos pueden manejar tráfico de paquetes, los datos pueden intercambiarse • directamente con la Internet o intranets corporativas Los paquetes de un usuario pueden transmitirse a través de numerosos timeslots de la interfaz de aire • (bundling) • Los timeslot no se utilizan de manera continua y pueden compartirse entre usuarios • Aún si los usuarios no están enviando ni recibiendo, pueden permanecer conectados (por ejemplo a la LAN corporativa) sin utilizar recursos. Los recursos se le asignan a los usuarios sólo cuando éstos los necesitan • GPRS se implementa dentro del estándar GSM, por lo que no se requieren nuevas frecuencias • Se pueden agrupar los usuarios GPRS en tres clases: • Clase A: Soporta el uso simultáneo de servicios de voz y datos. El móvil puede mantener una conversación de voz y transmitir datos al mismo tiempo. • Clase B: Soporta conexión GPRS y GSM simultáneas pero no el uso simultáneo de ambos servicios. El móvil puede estar registrado en ambas redes GSM y GPRS al mismo tiempo, pero no puede mantener una conversación y transferir datos al mismo tiempo. Clase C: El usuario puede conectarse a la red GSM o GPRS pero no al m ismo tiempo. •
71
Arquitectura GPRS
Como se mencionó, GPRS es completamente diferente de la transmisión de datos o voz por medio de circuitos conmutados, dado que los datos se envían en forma de paquetes. Cada vez que se requiere transmitir un paquete, los recursos (ancho de banda o interfaz de aire) se asigna y el paquete respectivo se envía al receptor (que, por ejemplo puede ser otro usuario móvil o un servidor en Internet). Los elementos de red introducidos hasta el momento son conmutadores de tráfico y nodos de señalización. En GSM, el tráfico se conmuta por circuitos con determinadas tasa de transmisión dependiendo de la aplicación. La señalización es conmutada por paquetes pero a una velocidad mucho más baja. Sin embargo, ninguno de los nodos vistos son capaces de transferir datos conmutados por paquetes a las altas tasas requeridas por GPRS. Nodos de Soporte GPRS Claramente, GPRS requiere un conjunto completo de nuevos conmutadores capaces de enrutar datos conmutados por paquetes en una red paralela separada. Se deben considerar dos entidades funcionales diferentes: La puerta de entrada hacia redes de datos externas y el nodo que atiende al usuario. El primero es el punto de acceso de una red externa de datos y se conoce como el Nodo de Soporte de Entrada GPRS (GGSN). El GGSN puede enrutar los paquetes hacia la localización actual del móvil. Por lo tanto, tiene acceso al HLR para obtener la información de localización requerida para transferir paquetes al m óvil. El segundo es el nodo que atiende las necesidades de la MS y se conoce como Nodo de Soporte de Atención GPRS (SGSN). El SGSN establece un contexto de administración para el MS adosado. Es también su función realizar el cifrado del tráfico de paquetes, dado que la BTS sólo se encarga de cifrar tráfico conmutado por circuitos. De las especificaciones, las dos funcionalidades pueden combinarse en un nodo físico (útil para las primeras implementaciones de GPRS), separadas en la misma red o aún en diferentes redes. Ambos nodos de soporte GPRS (GSN) recolectan datos de tarifación: Los detalles del volumen de datos transferidos por el usuario son recolectados por el SGSN, mientras que la inform ación detallada del acceso del usuario a la red de datos pública es contabilizada por el GGSN. Un celular GPRS transmitirá datos en modo de conmutación de paquetes, pero la voz se transmitirá como llamadas conmutadas por circuito. Esto significa que debe existir un elemento de red que distinga entre dos tipos diferentes de transferencia y desvíe cada uno hacia la red de transporte correspondiente, es decir hacia la MSC o hacia el SGSN. Esta es una de las funciones principales de la Unidad de control de Paquetes (PCU). Otras funciones incluyen: • Segmentación y reensamblado de paquetes, en el sentido descendente y ascendente respectivamente • Control de acceso • Diagramación de todas las transmisiones activas incluyendo administración de los canales de radio • Control de transmisión (verificación, buffering, retransmisión) La PCU se puede ubicar en varios lugares de la red: En el sitio del BTS, en la BSC o bien al lado del conmutador. La ubicación preferida es en la BSC.
72
La introducción de nuevos nodos de núcleo de red para soportar las funcionalidades de GPRS, así como la necesidad de comunicación con los nodos integrantes del núcleo de GSM provocan la aparición de nuevas interfaces protocolos. Las nuevas interfaces que aparece entre nodos GPRS son Gb, Gn y Gp. Con nodos GSM, aparecen Gr, Gs, Gd, Gc y Gf. Notar, que el operador no tiene por que implementar todas (p.e, Gs, Gd, Gc y Gf).. Con las redes externas aparecen Gi y Gp. Una implementación típica (que incluya Roaming) tendría: Gb, Gn, Gi, Gp, y Gr.
Interfaz Gb: Interfaz entre la BSS y el SGSN. Sobre él, se realizan el intercambio de datos de usuario y de información de señalización. No existe diferencia a nivel de pila de protocolos entre estos dos planos. Las diferencias entre ambos se encuentra por encima de la pila que este subsistema maneja. No hay recursos físicos dedicados a señalización. Diferencia con respecto al interfaz A (BSS-MSC): información de múltiples usuarios puede ir multiplexada sobre el mismo recurso físico. Emplea Frame-Relay para el transporte. Interfaz Gr: Interfaz entre el SGSN y el HLR. Función: dar acceso a la información de usuario que se encuentra almacenada en el HLR. Interfaz MAP estándar. Emplea enlaces físicos SS7. Interfaz Gs: Es una interfaz SS7 que implementa SCCP. Permite la coordinación entre el MSC y el SGSN para soportar servicios conmutados por circuitos (voz) controlados por el MSC y servicios conmutados por paquetes controlados por el SGSN. Interfaz Gd: Interfaz SS7 con el SMCC para permitir a los móviles GPRS enviar y recibir SMS. Interfaz Gn: Permite la comunicación del SGSN con otros GSNs (GGSNs/SGSNs) del backbone Intra-PLMN. Emplea IP para el transporte. Interfaz Gp: igual función que el Gn pero Inter-PLMN (otros operadores). El canal físico puede tener distintas configuraciones: Ethernet, ATM, etc Interfaz Gi: Desde la GGSN hacia la red de datos externa Interfaz Gc: Es una interfaz opcional entre el GGSN y el HLR. Utiliza SS7 MAP. Es necesaria para aplicaciones de datos entrantes (es decir generadas en la red externa), por ejemplo servicios PUSH GPRS.
73
GPRS Tunnelling Protocol (GTP): Encapsula los datos de usuario y los de señalización entre los GSNs Transmission Control Protocol (TCP): Lleva las PDUs GTP cuando se necesita enlace de datos fiable. Realiza control de flujo y protección ante perdida y corrupción de PDUs GTP User Datagram Protocol (UDP): Lleva las PDUs GTP cuando no se precisa enlace de datos fiable. Protege ante corrupción de PDUs GTP Internet Protocol (IP): Protocolo del Backbone de GPRS. Realiza el encaminamiento de datos de usuario y control de señalzación Subnetwork Dependent Convergence Protocol (SNDCP): Funciones de mapeo y compresión entre el nivel de red y capas inferiores. Segmentación, reensamblado y multiplexación Logical Link Control (LLC): Enlace lógico fiable (cifrado). Independiente de niveles inferiores de radio. Relay: En el BSS realiza la retransmisión de las PDUs LLC entre Um y Gb. En el SGSN retransmite las PDUs PDP entre Gb y Gn Base Station System GPRS Protocol (BSSGP): Lleva información realacionada con el encaminamiento y QoS entre BSS y SGSN. No realiza corrección de errores Network Service: Transporta PDUs BSSGp. Basado en conexión Frame Relay entre BSS y SGSN Radio Link Control (RLC) : Proporciona un enlace fiable. Depende de la solución radio implantada Medium Access Control (MAC) . Control de acceso a los procedimientos de señalización para el canal de radio GSM RF: Igual que el definido para GSM
74
75
El sistema GPRS estructura sus comunicaciones en forma similar al GSM, en el que un conjunto de radio bases conforman un área de localización de las estaciones móviles, en el GPRS se introduce el concepto de área de enrutamiento que puede ser igual o menor que un área de localización, considerándose de forma general como un subconjunto de esta.
76
En la figura, la Location Area LA1 contiene tres Routing Areas: RA1, RA2 y RA3. Pero la Routing Area naranja es la misma área que la Location Area LA2
77
78
Las estaciones móviles GPRS incluyen un estado adicional con relación a los 2 considerados en el GSM, de esta forma el GPRS puede permanecer “inactivo” y en este caso el terminal solo puede recibir datos del tipo punto a multipunto en modo multicast ya que el móvil permanece no localizado por la red y por lo tanto no es factible accionar en relación a esta, se introduce el estado “reposo” (Stand by) utilizado cuando un suscriptor ha terminado una sesión de trabajo y permanece conectado quedando el móvil localizado en la red a nivel de área de enrutamiento, el móvil recibe datos del tipo punto a multipunto y además es capaz de recibir llamadas de busca, en el estado dedicado el móvil está localizado a nivel de celda y está en capacidad de recibir datos del SGSN o de enviarlos a este, aquí al expirar el tiempo definido, el móvil pasa de forma automática al estado de reposo.
79
Antes de poder transferir datos entre el MS y la red de datos externa, se requiere cierta preparación para habilitar la transferencia de paquetes IP a través de la red GPRS. Los tres puntos siguientes son necesarios: 1. El MS debe estar attached en la red GPRS. El procedimiento “GPRS attach” es el proceso lógico entre el MS y el SGSN que toma nota de la posición (la routing area) del MS. 2. Cómo se encuentra el camino adecuado para los paquetes IP dentro de la red GPRS? Se debe configurar una conexión entre el ms y el GGSN. A esto se lo llama activación del contexto PDP (Protocol Data Packet ). Luego de este procedimiento, cada nodo de la red GPRS sabe como debe transferir paquetes a ese MS. 3. Se prepara el camino entre el MS y la red de datos externa, de manera que los paquetes enviados a través de la red GPRS puedan llegar a destino.
80
81
Para enviar y recibir datos GPRS (excepto SMS), la MS debe realizar una activación del contexto PDP luego del GPRS attach, lo que significa que debe especificar la red externa que quiere alcanzar. El contexto PDP permite establecer un túnel hacia la red externa especificada por el MS. 1. La MS manda el mensaje de solicitud de activación de un contexto PDP a la SGSN, para esto transfiere los parámetros : • NSAPI : punto de acceso al servicio, identifica el servicio que s e desea. • Tipo de PDP : indica qué protocolo de nivel de red, se utilizará para la trasferencia de los datos del contexto (ejemplo IP, X.25). • APN (Access Point Name) : Es el punto de conexión de una GGSN con una red externa específica. • Dirección de PDP :Indica al dirección destino dentro de la red externa, donde se desea transferir la información • Parámetros de QoS solicitada 2. El SGSN recibe la solicitud y verifica si el usuario (a partir de la P_TMSI ó IMSI), está autorizado a ese servicio. 3. Se define un enlace lógico con un TLLI (Temporary Logical Link Identifier ) y el SGSN establece la tabla que relaciona la MS con su TLLI. 4. El SGSN toma la información del APN y le dice al DNS, que le busque la dirección IP de los GGSN que tengan conexión con el punto de acceso APN solicitado. 5. El SGSN recibe una lista de IP de los posibles GGSN candidatos. El SGSN escoge uno y establece comunicación en el Backbone IP. El GGSN contesta y se establece un TID (Tunnel Identifier) que identificará el túnel apropiado para intercambio de información. 6. El SGSN, a través del túnel, informa al GGSN, sobre el tipo de contexto PDP, que debe crear con la red externa, transfiriéndole todos los parámetros establecidos por el MS (NSAPI, Tipo de PDP, dirección de PDP, QoS, APN). 7. La GGSN gestiona la conexión con la red externa, que una vez establecida, le responde al SGSN sobre los parámetros negociados de QoS y dirección PDP asignada.
82
La dirección del MS puede ser asignada de varias maneras : • Dinámica : El GGSN utiliza un servidor DHCP habilitado en la red GPRS. • Estática : Se utiliza el HLR para almacenar direcciones fijas a cada MS • Asignada por una red externa(ISP o Intranet) : El GGSN realiza el proceso de autentificación con la re externa y una vez validado, esta le pasa la IP a utilizar, el GGSN transfiere la nueva IP al MS para que la utilice en su comunicación
83
Servicios y tecnologías de mensajería móvil El protocolo de Aplicaciones Inalámbricas (WAP)
C lien te
Pasarela
S e r v id o r d e Inform ac ión
P e t ic ió n C o d if ic a d a
P e t ic ió n
C G I,
A ge nt e de U suario W AE
Scripts,
C o d i f ic a d o r e s
(Entorno de
etc.
A pl ica ció n
y
Inalám brica) R espue sta C odificada
R espu esta (C ontenido)
D e c o d i f ic a d o r e s C ontenido
El Prot oc olo d e Ap licacio nes Inalám bric as surge como la combinación de dos tecnologías de amplio crecimiento y difusión durante los últimos años: Las Comunicaciones Inalámbricas e Internet . Mas allá de la posibilidad de acceder a los servicios de información contenidos en Internet, el protocolo pretende proveer de servicios avanzados adicionales como, por ejemplo, el desvío de llamadas inteligente, en el cual se proporcione una interfaz al usuario en el cual se le pregunte la acción que desea realizar: aceptar la llamada, desviarla a otra persona, desviarla a un buzón vocal, etc. Para ello, se parte de una arquitectura basada en la arquitectura definida para el World Wide Web (WWW), pero adaptada a los nuevos requisitos del sistema. En la figura se muestra el esquema de la arquitectura WAP. De esta forma, en el terminal inalámbrico existiría un “micro navegador” encargado de la coordinación con la pasarela, a la cual la realiza peticiones de información que son adecuadamente tratadas y redirigidas al servidor de información adecuado. Una vez procesada la petición de información en el servidor, se envía esta información a la pasarela que de nuevo procesa adecuadamente para enviarlo al terminal inalámbrico. La tecnología WAP es un habilitador para construir aplicaciones (por ejemplo navegación, mensajería, etc.) que se ejecuten sin problemas en varias plataformas inalámbricas. El objetivo del WAP Forum fue proveer un marco para el desarrollo de aplicaciones con foco en los siguientes aspectos: • Interoperabilidad: Las aplicaciones desarrolladas por varios grupos y corriendo sobre los dispositivos producidos por diferentes fabricantes, interoperan de manera satisfactoria. • Escalabilidad: Los operadores de red móviles pueden escalar los servicios de acuerdo a las necesidades de los usuarios. • Eficiencia: El marco ofrece una calidad de servicio acomodada a las capacidades de las redes inalámbricas subyacentes • Confiabilidad: El marco representa una plataforma estable para el desarrollo de s ervicios • Seguridad: El marco asegura que los datos de usuario pueden transferirse de m anera segura sobre la red móvil, que puede no ser su propia red. Esto incluye la protección de los servicios y dispositivos y la confidencialidad de los datos de usuario. En línea con estas consideraciones, la tecnología W AP provee un modelo de aplicación cercano al modelo WW W (conocido como modelo Web). En el modelo Web, el contenido se representa utilizando formatos descriptores estándar. Adicionalmente, las aplicaciones conocidas como navegadores reciben el contenido disponible utilizando protocolos de transporte estándar. Para conseguir consistencia en la comunicación entre el terminal móvil y los servidores de red que proporcionan la información, WAP define un conjunto de componentes estándar: • Un modelo de nombres estándar. Se utilizan las URIs definidas en WWW para identificar los recursos locales del dispositivo (tales como funciones de control de llamada) y las URLs (tam bién definidas en el WWW) para identificar el contenido WAP en los servidores de información. • Un formato de contenido estándar, basado en la tecnología WWW. • Unos protocolos de comunicación estándares, que permitan la com unicación del micro navegador del terminal móvil con el servidor Web en red.
84
El modelo WAP toma mucho del existoso modelo Web. Sin embargo, el m odelo web así como es, no hace frente a las limitaciones de las redes móviles. Para enfrentar estas limitaciones, el modelo WAP se monta sobre el modelo Web agregando las siguientes mejoras: • La tecnología push permite que el contenido sea enviado directamente desde el servidor al dispositivo móvil sin un pedido explicito previo del usuario • La adaptación del contenido a las capacidades de los dispositivos WAP se basa en un mecanismo conocido como Perfil del Agente de Usuario (UAProf). • El soporte de características avanzadas de telefonía • La Interfaz de Funcionalidad Externa (EFI) permite agregar módulos “ plug-in” a los navegadores y aplicaciones almacenadas en dispositivos WAP para incrementar sus capacidades. • El almacenamiento persistente permite a los usuarios organizar, acceder, almacenar y recuperar contenido desde/hacia locaciones remotas. • Los servicios de mensajería multimedia (MMS) son un agregado significativo del modelo WAP por sobre el modelo Web. Utiliza los mecanismos WAP genéricos como Push y UAProf para ofrecer sofisticados servicios de mensajería multimedia a los usuarios móviles. El modelo WAP utiliza los modelos de nombres y tipos de contenidos estándar definidos en el modelo web. Adicionalmente, WAP incluye lo siguiente: • Formatos de contenido estándar: los navegadores en el ambiente WAP, conocidos como micronavegadores, soportan una cantidad de lenguajes y formatos de contenido estándar, incluyendo el Wireless Markup Languaje (WML) y XHTML. Ambos son aplicaciones de XML. • Protocolos estándar: los micronavegadores se comunican de acuerdo a protocolos optimizados para redes móviles, incluyendo el Protocolo de Sesión Inalámbrica (WSP) y HTTP del modelo web.
85
En el ejemplo de la figura, nuestro terminal móvil tiene dos posibilidades de conexión: a un proxy WAP, o a un servidor WTA (Aplicación de Telefonía Inalámbrica). El primero de ellos, el proxy WAP traduce las peticiones WAP a peticiones Web, de forma que el cliente WAP (el terminal inalámbrico) pueda realizar peticiones de información al servidor Web. Adicionalmente, este proxy codifica las respuestas del servidor Web en un formato binario compacto, que es interpretable por el cliente. Por otra parte, el segundo de ellos, el Servidor WTA está pensado para proporcionar acceso WAP a las facilidades proporcionadas por la infraestructura de telecomunicaciones del proveedor de conexiones de red.
86
Los protocolos y tipos de contenido de WAP han sido optimizados para el uso en dispositivos inalámbricos de mano de presencia masiva en el mercado. WAP utiliza tecnología proxy para mejorar y optimizar la conexión entre el dominio inalámbrico y la WWW. Algunas de las funciones que puede proveer un proxy WAP son: • Puerta de enlace de protocolo : la puerta de enlace de protocolo traduce requerimientos de una pila de protocolo inalámbrico (por ejemplo, la pila de WAP 1.X –WSP, WTP, WTLS y WDP) a los protocolos de WWW (HTTP y TCP/IP). La puerta de enlace además realiza consultas DNS de los servidores nombrados por el cliente en los URLs. • Codificadores y decodificadores de contenido: pueden usarse codificadores de contenido para traducir contenido WAP a un formato compacto que permita un mejor aprovechamiento del enlace subyacente debido a su reducido tamaño. • Administración de perfil de agente de usuario: describen las capacidades de los clientes y las preferencias personales. • Proxy de cacheo: puede mejorar la performance percibida y la utilización de la red, manteniendo en cache los recursos que se acceden mas frecuentemente. Esta infraestructura asegura que los usuarios de terminales móviles puedan acceder a una variedad de contenidos y aplicaciones de Internet, y que los autores de aplicaciones tengan la posibilidad de desarrollar servicios y aplicaciones que corran en una gran cantidad de terminales móviles. El Proxy WAP permite que las aplicaciones y contenidos puedan ser almacenados en servidores WWW estándar y desarrollados usando tecnologías de WWW ya probadas. Si bien el uso nominal de WAP incluye un servidor Web, un Proxy WAP y un cliente WAP, esta arquitectura también soporta otras configuraciones.
87
La arquitectura WAP también incluye servidores soportados, que proveen servicios a dispositivos, Proxies y aplicaciones que los necesiten. Usualmente estos servidores tienen funciones especificas, pero son de uso general para una amplia variedad de aplicaciones. Los servidores soportados incluyen entre otros: • Portal PKI: permite a los dispositivos iniciar la creación de nuevos certificados de clave publica. • Servidor UAProf: permite a las aplicaciones recobrar las capacidades del cliente y perfiles personales de agentes de usuarios y usuarios individuales. • Servidor de provisión: es un servidor de confianza al cual el dispositivo WAP provee su información. Los clientes WAP se comunican con servidores de aplicación mediante diferentes Proxies o en forma directa. Los clientes WAP soportan el mecanismo de “selección de Proxy”, que les permite elegir el Proxy mas adecuado para un servicio dado o conectarse directamente con ese servicio. Los Proxies pueden usarse para aumentar un requerimiento. Traducen entre protocolos WAP y WWW (HTTP, TCP), permitiendo al cliente WAP hacer pedidos al servidor de origen. Los Proxies pueden ubicarse en distintos lugares: portadores inalámbricos o proveedores independientes de servicios para ofrecer mejoras asociadas a las redes inalámbricas o para optimizar la comunicación entre el dispositivo y el servidor. Pueden ubicarse en redes seguras para proveer un canal seguro entre el dispositivo inalámbrico y la red segura. En algunos casos, el dispositivo puede conectarse directamente a los servidores de aplicaciones, por ejemplo para proveer una conexión segura directamente entre el dispositivo y el servidor de aplicación.
88
La arquitectura WAP ofrece un entorno de desarrollo escalable y extensible para dispositivos móviles. Esto es logrado a través de un diseño de capas del protocolo como se muestra en la figura. Cada capa provee un set de funciones y/o servicios a los otros servicios y aplicaciones a través de un conjunto de interfaces bien definidas. Cada capa de la arquitectura es accesible tanto por las capas superiores, como por otros servicios y aplicaciones. La arquitectura WAP separa las interfaces de servicios de los protocolos que proveen estos servicios, teniendo en cuenta la evolución de las especificaciones y seleccionando el protocolo mas apropiado para un contexto dado. Algunos de los servicios de la pila pueden ser provistos por mas de un protocolo. Por ejemplo, tanto el HTTP como el WSP pueden proveer el Hypermedia Transfer Service. Los protocolos se diseñaron o seleccionaron para operar sobre una variedad de servicios portadores, incluyendo mensajes cortos, datos conmutados por circuitos y datos de paquetes. Los portadores ofrecen diferentes niveles de calidad de servicio en relación con la tasa de transferencia, tasa de error y retardos. Los protocolos se diseñan para compensar o tolerar estos niveles de servicio variables. Debido a que la capa de servicios de transporte provee la convergencia entre los servicios portadores y el resto de la pila WAP, las especificaciones de transporte (WDP) podrán indicar los servicios portadores soportados y las técnicas utilizadas para permitir a los protocolos correr sobre cada portador.
89
Servicios de Transporte La capa de Servicio de Transporte ofrece un set de servicios para la capa superior y mapea estos servicios como disponibles en los servicios soportados. El Servicio de Transporte transporta datos desestructurados a través de las redes. Este servicio crea una abstracción común que es consistente a través de todos los Servicios soportados. El Servicio de Transporte incluye, pero no esta limitado a: • Datagramas : El servicio de Datagramas provee un trasporte de datos en el que se contiene a si mismo, independiente de que el dato lleve suficiente información para ser ruteada desde la fuente al destino sin confiar en un intercambio cercano entre esta fuente y el equipo destino y la red de transporte. UDP (User Datagram Protocol) y WDP (Wireless Datagram Protocol) son dos protocolos usados para proveer el servicio de transporte de Datagramas en la arquitectura WAP. • Conexiones: El servicio de conexiones provee el servicio de transporte de datos en donde la comunicación procede según tres fases bien definidas: se establece la comunicación, información fiable de transferencia de datos en ambos lados y fin de la conexión. TCP (Transmission Control Protocol) es un protocolo usado para dar servicio de conexión IP en la arquitectura WAP.
Servicio de Transferencia El Servicio de Transferencia provee la transferencia de información estructurada entre los elementos de la red. El Servicio de Transferencia incluye, pero no esta limitado a: • Hypermedia Transfer: Este servicio provee la transferencia de los recursos hypermedia. La combinación de WSP (Wireless Session Protocol) y WTP (Wireless Transaction Protocol) provee la transferencia hypermedia segura y no segura sobre datagramas. El HTTP (Hypertext Transfer Protocol) brinda el servicio de transferencia hypermedia segura y no segura sobre transporte orientado a conexión. • Streaming: El Servicio Streaming provee los medios para transferir datos sincrónicos como audio y video. • Message Transfer: Provee los medios para transferir mensajes multimedia asincrónicos como los emails, o mensajes instantáneos. MMS Encapsulation [MMSEncapsulation] es un protocolo usado para transferir mensajes entre dispositivos WAP y servidores MMS.
Servicios de Sesión El Servicio de Sesión es para iniciar la sesión entre un elemento de la red que envía múltiples requerimientos de red o transferencia de datos. Por ejemplo, la sesión „Push‟ establece que el dispositivo WAP esta listo y preparado para recibir „pushes‟ desde Push Proxy. Servicio de Sesión incluye, pero no esta limitado a: • Negociación de capacidades: La arquitectura WAP incluye especificaciones para describir, transmitir y manejar información de compatibilidades y preferencia sobre los clientes, usuarios y elementos de la red. Esto permite la adecuación de la información y contenido, devuelto por el servidor de origen o puesto por la aplicación. • Push-OTA: El Servicio de Sesión Push-OTA (Over The Air) brinda a la transacción inicializada de red el servicio de que sea llevada a través de los dispositivos inalámbricos que son de estado intermitente para recibir datos. (Ejemplo; dispositivos con direcciones asignadas dinámicas.) El PushOTA opera sobre Servicio de Transporte orientado a conexión y Transporte de datagramas. • Sync: El Servicio Sync provee la sincronización de datos replicados. Se utiliza con conexiones TCP sobre IP, que pueden requerir componentes adicionales de la suite de protocolos TCP/IP. Un ejemplo seria el componente ICMP. • Cookies: El Servicio de Cookies permite a las aplicaciones establecer el estado en el cliente o en el Proxy que permanece durante múltiples transacciones de transferencia hypermedia.
90
Capas de protocolo y procesos O T R O S S E R V I C IO S Y APLICACIONES
C A P A D E A P L IC A C IÓ N ( W A E )
CAPA DE SESIÓN (WSP)
CAPA DE TRANSACCIONES (WTP)
C A P A D E S E G U R ID A D ( W T L S )
CAPA DE TRANSPORTE (WDP) Protocolos portadores:
GSM
IS -1 3 6
C DMA
PHS
CDPD
P D C -P
iD E N
e tc .
Una vez introducido el sistema, vamos a ver la arquitectura que le da consistencia. La arquitectura WAP está pensada para proporcionar un “entorno escalable y extensible para el desarrollo de aplicaciones para dispositivos de comunicación móvil” . Para ello, se define una estructura en capas, en la cual cada capa es accesible por la capa superior así como por otros servicios y aplicaciones a través de un conjunto de interfaces muy bien definidos y especificados. CAPA DE APLICACIÓN (WAE) El Entorno Inalámbrico de Aplicación (WAE) es un entorno de aplicación de propósito general basado en la combinación del World Wide Web y tecnologías de Comunicaciones Móviles. Este entorno incluye un micro navegador , del cual ya hemos hablado anteriormente, que posee las siguientes funcionalidades: • Un lenguaje denominado WML similar al HTML, pero optimizado para su uso en terminales móviles. • Un lenguaje denominado WMLScript , similar al JavaScript (esto es, un lenguaje para su uso en forma de Script ) Un conjunto de formatos de contenido, que son un conjunto de formatos de datos bien definidos entre los que • se encuentran imágenes, entradas en la agenda de teléfonos e inform ación de calendario. CAPA DE SESIÓN (WSP) El Protocolo Inalámbrico de Sesión (WSP) proporciona a la Capa de Aplicación de WAP interfaz con dos servicios de sesión: Un servicio orientado a conexión que funciona por encima de la Capa de Transacciones y un servicio no orientado a conexión que funciona por encima de la Capa de Transporte (y que proporciona servicio de datagramas seguro o servicio de datagramas no seguro) Actualmente, esta capa consiste en servicios adaptados a aplicaciones basadas en la navegación Web, proporcionando las siguientes funcionalidades: Semántica y funcionalidades del HTTP/1.1 en una c odificación compacta. • Negociación de las características del Protocolo. • Suspensión de la Sesión y reanudación de la m isma con cambio de sesión. • CAPA DE TRANSACCIONES (WTP) El Protocolo Inalámbrico de Transacción (WTP) funciona por encima de un servicio de datagramas, tanto seguros como no seguros, proporcionando las siguientes funcionalidades: • Tres clases de servicio de transacciones: Peticiones inseguras de un solo camino. • Peticiones seguras de un solo camino. • Transacciones seguras de dos caminos (petición-respuesta) • Seguridad usuario-a-usuario opcional. • • Transacciones asíncronas.
91
CAPA DE SEGURIDAD (WTLS) La Capa Inalámbrica de Seguridad de Transporte (WTLS) es un protocolo basado en el estándar SSL, utilizado en el entorno Web para la proporción de seguridad en la realización de transferencias de datos. Este protocolo ha sido especialmente diseñado para los protocolos de transporte de Wireless Transaction Protocol ó Protocolo Inalámbrico de Transacción. Wireless Transport Layer Security ó Capa Inalámbrica de Seguridad de Transporte WAP y optimizado para ser utilizado en canales de comunicación de banda estrecha. Para este protocolo se han definido las siguientes características: Integridad de los datos. Este protocolo asegura que los datos intercambiados entre el terminal y un servidor de • aplicaciones no ha sido modificada y no es información corrupta. Privacidad de los datos. Este protocolo asegura que la información intercambiada entre el terminal y un servidor • de aplicaciones no puede ser entendida por terceras partes que puedan interceptar el flujo de datos. • Autentificación. Este protocolo contiene servicios para establecer la autenticidad del terminal y del servidor de aplicaciones. Adicionalmente, el WTLS puede ser utilizado para la realización de comunicación segura entre terminales, por ejemplo en el caso de operaciones de com ercio electrónico entre terminales móviles. CAPA DE TRANSPORTE (WDP) El Protocolo Inalámbrico de Datagramas (WDP) proporciona un servicio fiable a los protocolos de las capas superiores de WAP y permite la comunicación de forma transparente sobre los protocolos portadores válidos. Debido a que este protocolo proporciona un interfaz común a los protocolos de las capas superiores, las capas de Seguridad, Sesión y Aplicación pueden trabajar independientemente de la red inalámbrica que dé soporte al sistema. Como se ve en la figura, dependiendo de la aplicación en cuestión, la comunicación se realizará con una determinada capa de la estructura de WAP
92
El entorno inalámbrico de aplicaciones (WAE) WAE
Agentes de Usuario Agente de Usuario para WML Agente de Usuario para WTA
Servicios / Formatos
Otros Agentes
WMLScript
Otras Aplicaciones y Servicios
Servicios WTA WML URLs
Otros Servicios y Formatos
Servicios y Pila del Protocolo de WAP
Servicios / Sistema Operativo del Dispositivo
El objetivo del Entorno Inalámbrico de Aplicaciones es construir un entorno de aplicación de propósito general, basado fundamentalmente en la filosofía y tecnología del World Wide Web (WWW). Principalmente, se pretende establecer un entorno que permita a los operadores y proveedores de servicios construir aplicaciones y servicios que puedan utilizarse en una amplia variedad de plataformas inalámbricas de forma útil y eficiente. De esta forma, la arquitectura del Entorno Inalámbrico de Aplicaciones (WAE) está enfocado principalmente sobre los aspectos del cliente de la arquitectura del sistema de WAP, esto es, de los puntos relacionados con los agentes de usuario. Esto es debido a que la parte que más interesa de la arquitectura es aquella que afecta principalmente a los terminales móviles, esto es, a aquellos puntos en los cuales van a estar ejecutándose los diversos agentes de usuario. Entre los agentes de usuario localizados en el cliente (en el terminal móvil) y los servidores de información se define un nuevo elemento: Las Pasarelas . Su función es codificar y decodificar la información intercambiada con el cliente, para así minimizar la cantidad de datos radiados, así como minimizar el proceso de la información por parte del cliente. Basándonos en esta arquitectura, vemos que se divide en dos partes, dos capas lógicas: • Los Agentes de Usuario, que incluye aquellos elementos como navegadores, agendas telefónicas, editores de mensajes, etc. • Los Servicios y Formatos, que incluyen todos aquellos elementos y formatos comunes, accesibles a los Agentes de Usuario, tales como WML, WMLScript, formatos de imagen, etc. Como se puede ver en la Figura, dentro de WAE se separan Servicios de Agentes de Usuario, lo que proporciona flexibilidad para combinar varios Servicios dentro de un único Agente de Usuario, o para distribuir los Servicios entre varios Agentes de Usuario. Los dos Agentes de Usuario más importantes son el Agente de Usuario para WML y el Agente de Usuario para WTA. El Agente de Usuario para WML es el Agente de Usuario fundamental en la arquitectura del Entorno Inalámbrico de Aplicación. A pesar de su importancia, este Agente de Usuario no está definido formalmente dentro de esta arquitectura, ya que sus características y capacidades se dejan en manos de los encargados de su implementación. El único requisito de funcionalidad que debe cumplir este Agente de Usuario, es el proporcionar un sistema intérprete a los lenguajes W ML y WMLScript, de forma que se permita la navegación desde el terminal móvil. Por otra parte, el Agente de Usuario para WTA permite a los autores acceder e interactuar con las características de los teléfonos móviles (p. e. Control de Llamada), así como otras aplicaciones supuestas en los teléfonos, tales como agendas de teléfono y aplicaciones de calendario.
93
La estructura de aplicación provee un entorno de aplicación de propósito general basado en una combinación de WWW (World Wide Web), Internet y tecnología de telefonía móvil. El principal objetivo de esta, es de establecer un entorno operable que permita operadores y servicios para construir aplicaciones y servicios que puedan usar diferentes plataformas inalámbricas. La estructura de aplicación incluye, pero no esta limitada a: WAE/WTA User-Agent: WAE es un entorno micro-browser que incluye WML, XHTML, scripting, lenguajes style-sheet, y servicios de telefonía e interfaces de programación, todo optimizado para usar en terminales móviles. Push: El Servicio Push ofrece mecanismos generales para que la red inicialice la transmisión de datos a las aplicaciones residentes en los dispositivos WAP. Multimedia Messaging: El servicio Multimedia Message Service (MMS) se usa para transferir y procesar los mensajes multimedia como emails o mensajes instantáneos. Content Formats: La estructura de aplicación incluye soporte para el set de los formatos definidos, como imágenes de colores, audio, video, animación, agenda, y calendario.
94
En un modelo cliente/servidor típico, el cliente recupera la información seleccionada de una aplicación en el servidor requiriendo de forma explícita la descara de información desde el servidor. El método de recuperación se conoce también como tecnología pull debido a que el cliente “tira” de los datos desde el servidor. La navegación web es un ejemplo de modelos basados en la tecnología pull. En contraste, se introdujo otra tecnología en el modelo WAP conocida como tecnología Push. Mediante esta tecnología, un servidor puede enviar “empujar” datos al dispositivo WAP sin que medie un pedido explicito previo desde el cliente. En otras palabras, en el modelo “pull” la transacción es iniciada por el cliente, mientras que en el modelo “push” es siempre iniciada en el servidor. En el marco push, el iniciador lanza la transacción push. Usualmente un servidor de aplicación transmite el contenido a ser empujado junto con instrucciones de entrega formateadas en XML a la Pasarela de proxy Push (PPG). La PPG entonces entrega el contenido al dispositivo WAP de acuerdo a las instrucciones de entrega. El iniciador interactúa con la PPG utilizando el Protocolo de Acceso Push (PAP). En la otra parte, la PPG utiliza el protocolo Push Over the Air (P-OTA) que está basado en WSP o HTTP para entregar el contenido push al dispositivo WAP. La PPG puede implementar políticas de control de acceso a red indicando si se les permite a los iniciadores push enviar contenido a los dispositivos WAP. La PPG puede enviar una notificación al iniciador indicando el estado del pedido de push (entregado, cancelado, expirado, etc.) Se pueden entregar tres tipos de contenido mediante push a un micronavegador WAP: Indicación de Servicio (SI), Carga de Servicio (SL) y operación de cache (CO). El primero permite empujar contenido a los usuarios para notificarlos acerca de mensajes de correo electrónico a la espera de su recuperación, títulos de noticias, ofertas comerciales, etc. En su forma más simple, un SI contiene un mensaje corto junto con una URI. Luego de recibir el Push SI, el mensaje se presenta al usuario quien tiene la posibilidad de comenzar el servicio (recuperar el contenido) al cual se refiere la URI. El usuario podrá decidir comenzar el servicio inmediatamente o demorarlo. En contraste con el Push SI, el Push SL permite empujar contenido al dispositivo WAP sin un pedido explícito del usuario. Un Push SL contiene una URI que refiere al contenido Push. Luego de recibido, el contenido Push es automáticamente buscado por el dispositivo WAP y presentado al usuario. Push CO permite invalidar objetos almacenados en la memoria cache del dispositivo WAP. En adición al contenido específico de navegación push, es posible empujar información a otras aplicaciones basadas en WAP como ser un agente WTA o un agente de aprovisionamiento. El cliente MMS embebido en WAP también recibe mensajes push específicos para notificar al usuario acerca de la disponibilidad de mensajes nuevos y la entrega de reportes.
95
La especificación del Perfil de Agente de Usuario (UAProf) se publicó por primera vez en la especificación WAP 1.2, se mejoró en WAP 2.0 y tuvo mejoras posteriores por la Open Mobile Alliance. El objetivo de esta especificación es definir el método para describir las capacidades de los clientes y las preferencias de los usuarios. En la práctica, esta descripción es utilizada principalmente para adaptar el contenido disponible a las capacidades de representación de los dispositivos WAP. Para dicho propósito, el perfil ser formatea utilizando un esquema de Marco de Descripción de Recursos (RDF) de acuerdo con las Capacidades Compuestas/Perfil de Preferencias (CC/PP). La especificación CC/PP define un marco de alto nivel para el intercambio y descripción de información de capacidades y preferencias utilizando RDF. Ambas especificaciones fueron publicadas por el W3C. El UAProf permite el intercambio de perfiles de agente de usuario conocidos como Información de Capacidades y Preferencias (CPI) entre el dispositivo WAP, puntos de red intermedios, y el servidor de origen (Servidor Web o Centro MMS). Estos puntos intermedios de red y servidores de origen pueden utilizar el CPI para adaptar el contenido de las respuestas WSP/HTTP a la medida de las capacidades de los dispositivos WAP receptores. La especificación UAProf define un conjunto de componentes que los dispositivos WAP pueden transportar dentro del CPI. Cada componente está integrado por un conjunto de atributos o propiedades. Alternativamente, un componente puede contener un URI apuntando a un documento que describa las capacidades del cliente. Dicho documento estará almacenado en un servidor llamado Repositorio de Perfiles (usualmente administrado por los fabricantes de dispositivos o bien desarrolladores de microbrowsers). El UAProf está compuesto por los siguientes componentes: Plataforma de Hardware: este componente reúne un conjunto de propiedades indicando las capacidades de hardware del dispositivo • (tamaño de pantalla, etc.) Plataforma de Software: Agrupa las propiedades que indican las capacidades de software del dispositivo (sistema operativo, formatos de • imagen soportados, etc.) Agente de Navegador de Usuario: Reúne las propiedades respecto a las capacidades del Navegador de Internet. • Características de Red: Informa las características y ambiente de la red como ser capacidad de transporte. • Características WAP: Este componente documenta las capacidades de navegación WAP del dispositivo. Esto incluye información acerca • de la configuración WML. • Características PUSH: Indica las capacidades push del dispositivo. Incluye los tipos de contenido soportados, el tamaño máximo de mensaje y si el dispositivo puede o no almacenar mensajes push. Características MMS: Describe las capacidades del dispositivo para recibir y mostrar mensajes multimedia (Versión MMS, Tamaño • máximo del mensaje, tipos de contenido soportado, etc.) Para una configuración que involucra un dispositivo WAP y una pasarela comunicándose con el WSP, las descripciones RDF pueden codificarse en binario mediante el XML WAP Binario (WBXML). En este contexto, el dispositivo WAP entrega la CPI como parte de un pedido de establecimiento de sesión WSP. El dispositivo WAP también podrá actualizar su CPI en cualquier momento durante una sesión WSP activa. Notar que la pasarela WAP podrá sobrescribir la CPI provista por el dispositivo.
96
Como varios de estos servicios en la pila WAP pueden ser provistos usando diferentes protocolos según las circunstancias, hay mas de una posibilidad de configurar la pila. Los siguientes esquemas describen algunos casos utilizando tecnología WAP. WAP 1.x con pasarela El primer esquema describe la pila de protocolos para la arquitectura original WAP. La WAP Gateway convierte el Servicio de Transferencia Hypermedia entre los protocolos basados en datagramas (WSP, WTP, WTLS, WDP) y los protocolos orientados a conexión usados en Internet (HTTP, SSL, TCP). WAP HTTP Proxy con perfil TCP y http Este esquema describe un proxy WAP HTTP. La configuración del proxy es muy usada en Internet para el acceso web ordinario, datos multimedia, Ejemplo; descarga de música, video, etc. Esta configuración coloca al WAP Proxy entre las redes cableadas y las inalámbricas para tener performance usando perfiles inalámbricos de TCP (mostrado como TCP*). Además sobre la optimización de TCP, el perfil inalámbrico de HTTP (HTTP*) permite aumentar la performance. Ambos perfiles constan de opciones IETF que proveen operaciones de eficiencia sobre redes inalámbricas. Las versiones de perfiles inalámbricos son inter operables con TCP y HTTP. WAP Proxy soporte para túnel TLS El esquema describe un proxy WAP HTTP que establece un túnel orientado a conexión a un servidor Web, por ejemplo, en respuesta a un comando „connect‟ . Esta configuración es usada para permitir al TLS proveer seguridad „end-to-end‟ entre la terminal móvil y el servidor de origen. E-comerce es un ejemplo de uso de seguridad „end-to-end‟.
97
Acceso Directo El esquema describe un dispositivo WAP accediendo directamente a un servidor Web vía Internet. El router de IP inalámbrico es una parte estándar de una red IP que se usa para transferir paquetes IP de un nodo de conexión (Ej.; nodo inalámbrico) a otra (Ej.; nodo cableado). Esta configuración puede aplicarse al caso donde el nivel soportado de seguridad (como IPSec) es utilizado. En el escenario de la conexión directa, la optimización inalámbrica es definida por el perfil inalámbrico para TCP y HTTP, pudiendo no estar disponibles. Soporte de Pila dual Mientras las configuraciones previas mostraban pilas de protocolos únicos para cada configuración WAP, este esquema describe un dispositivo que soporta ambas, las pilas de protocolos 1.X y 2.X Esta configuración es útil en casos donde los dispositivos necesitan operar tanto con viejos como con nuevos servidores WAP.
98
SMPP es un protocolo abierto, diseñado para proporcionar un interfaz de comunicación para la transferencia de mensajes cortos (SM) entre External Short Message Entities (ESMES), Routing Entities (RE), y Message Centres (MC). Message Centre (MC) Un Message Centre (MC) o Centro de Mensajes es un término genérico utilizado para describir sistemas tales como un Short Message Service Centre (SMSC), GSM Unstructured Supplementary Services Data (USSD) o Cell Broadcast Centre (CBC). External Short Message Entity (ESME) Un ESME típicamente representa un cliente SMS de una red fija/una entidad de red, tal como un Server Proxy WAP, un Email Gateway, un Servidor de Mensajería de voz (Voice Mail Server). También puede representar un Cell Broadcast Entity (CBE). Routing Entity (RE) Un Routing Entity (RE) o Entidad de ruteo es un término genérico para un elemento de red que es utilizado por un MC a MC y un ESME a MC para ruteo de mensajes. Un SMPP RE tiene la capacidad de emular la funcionalidad de asociación tanto de un MC como de un ESME o de ambos a la vez. Para un ESME, un RE aparece como un MC y para un MC, un RE aparece como un ESME. Un Carrier puede utilizar RE´s para ocultar una red de MC´s, presentando únicamente las RE´s como el punto de interfaz externo para las ESME´s. Tecnologías Celulares Soportadas SMPP está diseñado para soportar funcionalidades short messaging para cualquier tecnología celular como: GSM • • UMTS • IS-95 CDMA • CDMA2000 • ANSI-136 TDMA IDEN •
99
Aplicaciones SMPP La variedad de aplicaciones de mensajería, particularmente SMS para lo cual SMPP puede ser empleado es casi ilimitada. Operadores inalámbricos, vendedores de centro de mensajes, proveedores de infraestructura, y diseñadores de aplicaciones están constantemente desarrollando nuevas aplicaciones para SMS. SMPP es ideal como un protocolo de acceso para estas aplicaciones. SMPP es destinado a diseñadores e implementadores de SMPP como interfaz entre MC, RE y ESMES. Usos comunes de SMPP: • Alertas de voicemail originadas desde un VPS (Voice Processing System) indicando mensajes de voz al mailbox del cliente, son una de las primeras aplicaciones SMS basadas en ESME que todavía son utilizadas en la industria. • Servicios de información. Por ejemplo, permitir a los suscriptores móviles consultar tasas de cambio o información de precios de acciones de una base de datos o en la WWW, y que estos reciban esa información desplegada en su móvil como un SM (short message). • Se utiliza para llamadas directamente marcadas o desviadas hacia un operador, quien a su vez direcciona o remite los mensajes hacia una MC para entregarlas al terminal o celular del suscriptor • Servicios de Directorios. • Servicios basados en Posicionamiento o localización. Incluyen rastreo de vehículos, envío de taxis, controle logístico. • Aplicaciones de seguridad tales como sistemas de alarmas que pueden utilizar los servicios SMS para accesos remotos y propósitos de alertas. Por ejemplo, un padre recibe un SMS de su compañía de seguridad para informarles que su hija ha llegado a casa y que ingresó el código de seguridad para acceso. • Banco en línea , E-Commerce. • SMS – Chat, juegos. Los usuarios de móviles pueden interactuar unos con otros utilizando un Server ESME y utilizar esta interacción para jugar inalámbricamente. • Mensajería Instantánea • Notificación de MMS • Cell Broadcasting Services (Servicios de Difusión) . Apoyo de mensajería geográfica como alarmas de tráfico y servicios de emergencia.
100
Para hacer uso del protocolo SMPP, una sesión SMPP debe establecerse entre el ESME y el MC o SMPP RE cuando sea apropiado. La sesión establecida está basada en una capa de aplicación TCP/IP o una conexión X.25 entre el ESME y MC/RE y por lo general, es iniciada por el ESME. Hay 3 formas de inicio de Sesión ESME. 1-TX Transm itter
Cuando la autenticación es como un transmisor, un ESME puede enviar o entregar SM hacia el MC (Message Center) para entregar más adelante éstos hacia los MS (Mobile Station). Una sesión de transmisor también permitirá que un ESME, cancele, consulte o sustituya mensajes enviados con anterioridad. Los mensajes enviados de esta manera son a menudo llamados Mobile Terminated Message. (Mensajes terminados en el terminal) MT 2-RX Receiv er
Una sesión de receptor permite a un ESME recibir SM de un MC, estos mensajes normalmente se originan o provienen de los MS y se conocen como Mobile Originated Messages (Mensajes originados en el terminal). MO 3-TRX Transc eiver
Una sesión TRX es una combinación de TX y RX, de forma que una sesión SMPP pueda utilizar ambas modalidades de MO y MT. Adicionalmente un MC puede establecer una sesión SMPP mediante la conexión a un ESME. Esto se llama una Sesión Outbind. Un ESME puede enviar y recibir SM´s
101
El protocolo SMPP es un conjunto de operaciones, cada una de las cuales toma la forma de Solicitud y Respuesta PDU. Por ejemplo, si un ESME desea enviar un SM, puede enviar un submit_sm PDU al MC. El MC responderá con un submit_sm_resp PDU , indicando el éxito o falla de la petición. Del mismo modo, si un MC desea entregar un SM a un ESME, este puede enviar un deliver_sm PDU al ESME que a su vez, responderá con un deliver_sm_resp PDU como medio de reconocimiento de la entrega. Algunas operaciones son específicas a un ESME, como otras son específicas para un MC. Otras pueden ser específicas a un tipo de sesión dado. Refiriéndome a los ejemplos de arriba de un submit_sm y el deliver_sm, un ESME puede enviar un submit_sm a un MC únicamente si ha establecido una sesión TX o una conexión/sesión TRX con ese MC, igualmente, un MC puede enviar un deliver_sm PDU a un ESME solo si ya estableció una conexión o sesión RX o TRX. Tipos de PDU: 1. PDU´s de solicitud o requerimiento 2. PDU´s de respuesta Los PDU´s contienen 3 Partes: • Área de encabezado o Header • Área de Parámetros Mandatorios • Área de Parámetros Opcionales. Las operaciones del protocolo y PDU´s se clasifican en términos generales en los siguientes grupos: Administración de Sesión: Estas operaciones son diseñadas para habilitar el establecimiento de sesiones SMPP entre un ESME y un MC y proporcionar métodos de manejo de errores inesperados. Mensaje de Presentación (Submission): Estas operaciones son diseñadas específicamente para la presentación de mensajes desde las ESMES hacia los MC. Entrega de Mensajes: Estas operaciones permiten a un MC entregar mensajes a un ESME. Mensaje de Difusión (Broadcasting): Estas operaciones son diseñadas para proveer servicios de difusión c elular dentro de MC. Operaciones Auxiliares: Estas operaciones están diseñadas para proporcionar características mejoradas, tales como la cancelación, consulta o reemplazo de los mensajes
102
Estableciendo una Sesión SMPP Para establecer una sesión, primero se requiere que una ESME se conecte a un MC. Esto se consigue utilizando una red TCP/IP o X.25. El MC normalmente se mantiene escuchando las conexiones por uno o más puertos de TCP/IP / X.25, sin embargo los puertos pueden variar dependiendo del vendedor y el operador del MC. Típicamente el puerto estandarizado para SMPP, es el 2775. Estados de una Sesión SMPP Open
Un ESME ha establecido una conexión de red con la MC, pero aun no ha emitido una petición o Bind_request . El MC únicamente es consciente de la conexión TCP/IP o X.25. Ningún detalle de identificación ha sido cambiado todavía. Bound_TX
Un ESME conectado ha solicitado unirse como un transmisor (utilizando un bind_transmitter PDU) y ha recibido un bind_transmitter_resp PDU desde la MC autorizando su petición o solicitud. Un ESME ligado como un transmisor puede enviar SM hacia un MC, para ser entregado a un MS o hacia otro ESME. El ESME puede también reemplazar, solicitar o cancelar SM previamente entregados. Bound_RX
Un ESME conectado ha solicitado unirse como un Receptor (utilizando un b ind_receiver PDU) y ha recibido un bind_receiver_resp PDU desde el MC autorizando su bind_request. Un ESME enlazado como un receptor puede recibir SM desde un MC, el cual puede ser originado desde un MS o por otro ESME o por el m ismo MC. Bound_TRX
Un ESME conectado ha solicitado enlazarse como un Transceiver (utilizando un bind_transceiver PDU ) y ha recibido un bind_transceiver_resp PDU desde la MC autorizando su bind_request. Un ESME enlazado o unido como un transceiver esta autorizado a utilizar todas las operaciones soportadas por un ESME Transmitter y un ESME Receiver. Una sesion transceiver es efectivamente la combinacion de una sesión Transmitter y Receiver. Un ESME unido como un transceiver puede enviar SM a un MC para ser entregados a un MS o hacia otro ESME y puede también recibir SM desde un MC, el cual puede ser originado por un MS, o por otro ESME o por un MC.
103
Unbound
Un Unbound se da, cuando un ESME enlazado como un TX, RX o TRX solicita una petición de desunión a la MC (Message Center) para la terminación de la sesión SMPP . Closed
Un estado Closed entre ESME-MC, se da cuando un ESME o MC han cerrado la conexión de Red. Esto típicamente es producido por un estado Unbound donde un punto de enlace ha solicitado terminar la sesión. Un estado Closed puede también resultar debido a un error de comunicación entre pares o por una falla de conexión inesperada en la red. Outbound
El objetivo de la operación Outbind, es permitir que la MC inicie una sesión SMPP. Un ejemplo tipico seria que la MC tuviera un SM pendiente de entregar a un ESME. El segundo diagrama ilustra el concepto de Outbind cuando es utilizado para solicitar un enlace de un ESME Receiver.
104
105
Sincrono y Asincrono SMPP es un protocolo Asincrono. Esto significa que un ESME o un MC puede enviar varias solicitudes o peticiones a la vez para la otra parte. Los números de secuencia PDU hacen posible la adecuada respuesta para cada request/response. ¿Por qué Asíncrono? El comportamiento síncrono puede parecer un camino fácil cuando se desarrolla una aplicación a nivel del protocolo SMPP. El envío de una petición PDU, y luego esperar por el PDU response es una alternativa fácil sobre la gestión de varios PDU‟s manejándolos en un entorno completo, en la forma asíncrono, el orden de PDU y su secuencia numérica puede ser reconocido en un orden no continuo y definitivo para la secuencia request/response. Sin embargo para una aplicación eficiente en el uso de sesiones SMPP y la utilización de ancho de banda, la transmisión asíncrono puede hacer mejoras significativas. El diagrama ayuda a explicar la razón para utilizar el protocolo de forma asíncrona. El ejemplo muestra 5 PDU´s de forma asíncrona transmitidos a través de sesiones SMPP desde el ESME hacia el MC. Si el MC puede procesar solo un PDU a la vez, entonces el beneficio de la transmisión asíncrono no está realmente perdido. En esta situación, la transmisión de PDU´s se convierte en una cola de solicitudes o peticiones para el MC. Tan pronto como el MC reconozca cada solicitud o petición, inmediatamente encontrara otra solicitud o petición en estado de espera. Los mismos beneficios aplican para las sesiones Receiver y Transceiver, donde el MC emite deliver_sm o data_sm PDU´s hacia el ESME. Si el ESME es síncrono y solo puede enviar un único PDU a la vez, entonces, tan pronto como el MC reconozca el PDU, la sesión SMPP permanecerá inactiva hasta que el response_PDU del MC ha sido procesado por el ESME y éste pueda enviar la próxima solicitud o petición al MC. Si consideramos el tiempo de transporte desde el ESME hacia el MC, tomara microsegundos, entonces el tiempo de inactividad por operación será 2. Este es el tiempo de inactividad transcurrido mientras que la respuesta está en tránsito hacia el ESME y cuando la petición o solicitud siguiente esta en tránsito hacia el MC. Una ventana Asíncrona de peticiones o solicitudes efectivamente evita esta ineficiencia.
106
1-Operación de Gestión de Sesión (Session Management) Estas operaciones son utilizadas para establecer y mantener sesiones SMPP. PDU BIND
El propósito de la operación de enlace (bind) de SMPP, es el registro de una instancia ESME con un sistema MC y establecer una sesión SMPP a través de una conexión de red para la entrega de mensajes. Así, la operación Enlace BIN puede ser vista como una forma de petición login MC para autenticar a la entidad ESME que desea establecer la conexión. Como se describió anteriormente, un ESME puede enlazarse-unirse a un MC como un Transmitter (llamado ESME Transmitter Transmisor), puede unirse a un MC como un Receiver (llamado ESME Receiver Receptor) o puede unirse a un MC como un Transceiver (llamado ESME Transceiver Transmisor-Receptor). Hay 3 SMPP BIND PDU´s para soportar los distintos modos de operación, los cuales son: a) Bind_transmitter b) Bind_receiver c) Bind_transceiver El campo command_id específica cual PDU se está utilizando. Un ESME puede enlazarse como un SMPP transmitter y/o Receiver utilizando operaciones separadas de bind_transmitter y bind_receiver (habiendo primero establecido 2 conexiones de red separadas). Alternativamente un ESME puede también enlazarse o unirse como un Transceiver habiendo primero establecido una única conexión de red. Con los PDUs de BIND el ESME establece una sesión SMPP con el MC Para cada operación BIND existe una operación BIND_RESP : BIND_TRANSMITTER BIND_TRANSMITTER_RESP
El bind_transmitter_resp SMPP PDU se utiliza para responder a una solicitud bind_transmitter BIND_RECEIVER BIND_RECEIVER_RESP BIND_TRANSCEIVER BIND_TRANSCEIVER_RESP Parámetros mandatorios importantes de los PDUs BIND: • system_id: identifica al ESME haciendo BIND • password: utilizado para autenticar el ESME system_type: identifica el tipo de ESME que está haciendo el BIND • Una respuesta exitosa del MC indica que el ESME puede iniciar el i ntercambio de SM´s con el MC.
107
PDU UNBIND
UNBIND finaliza la sesión SMPP. El objetivo de la operación Unbind SMPP (desenlazar) es dar de baja una instancia ESME desde una MC e informar a la MC que el ESME ya no desea utilizar la conexión de red para el envío o entrega de mensajes. Esta operación puede ser vista como una forma de la MC de solicitar el cierre de sesión actual de SMPP, pero en realidad, Unbind puede ser enviado tanto por el ESME como por el MC y cerrar la conexión TCP. La operación Unbind , recibe siempre su respectivo unbind_resp . El unbind_resp SMPP es utilizado para responder a una solicitud unbind y comprende el encabezado del mensaje SMPP. PDU ENQUIRE LINK
Este puede ser originado tanto por el ESME como por el MC y es utilizado para proporcionar chequeo de confidencialidad de comunicación entre las entidades ESME y MC. Tras la recepción de esta petición, la entidad receptora debe responder con un enquire_link_resp , por lo que se verifica o valida que la conexión a nivel de aplicación entre el ESME y el MC está funcionando. El ESME puede también responder con el envío de cualquier SMPP valido.
108
Presentación y entrega de mensajes
Presentacion de Mensajes (Message Submission) Las operaciones de presentación de mensajes proveen a un ESME la capacidad de enviar SM a estaciones móviles. PDU SUBMIT_SM
Con submit_sm, un ESME encola SM en el SMSC o MC, el PDU submit_sm_resp exitoso, indica que el SM fue aceptado por el MC para ser entregado a su destino. Parámetros mandatorios importantes del PDU SUBMIT_SM: • source_addr, source_addr_ton, source_addr_npi: identifican el originador del SM • destination_addr, dest_addr_ton, dest_addr_npi: identifican el destinatario del SM • short_message: texto del SM • registered_delivery: indica si se solicita notificación de entrega del SM Parámetros mandatorios importantes del PDU SUBMIT_SM_RESP: • message_id: identifica el SM dentro del SMSC, puede ser utilizado posteriormente para consultar el status del SM, cancelarlo o reemplazarlo Operaciones de entrega de Mensajes (Message Delivery Operations) Las operaciones de entrega de mensajes proveen los medios de entrega de SM´s desde un MC hacia un ESME. Estos mensajes suelen originarse desde los terminales o estaciones móviles. PDU DELIVER_SM
La operación deliver_sm , ésta operación es emitida por el MC para entregar un mensaje a un ESME. Utilizando este comando, el MC puede rutear / dirigir un SM al ESME para la entrega. Con el PDU deliver_sm_resp exitoso, se indica que el SM fue entregado correctamente al destinatario Parámetros mandatorios importantes del PDU DELIVER_SM: • source_addr, source_addr_ton, source_addr_npi : identifican el originador del SM • destination_addr, dest_addr_ton, dest_addr_npi: identifican el destinatario del SM • short_message: texto del SM • esm_class: Indica si el SM corresponde a una notificación de entrega de un SM enviado anteriormente con SUBMIT_SM , en cuyo caso el parámetro opcional receipted_message_id contiene el message_id del mensaje notificado Difusión de mensaje (Message Broadcast) Las operaciones de mensaje de difusión proporcionan servicios de difusión a ESME´s. Las operaciones de mensajes de difusión son aplicables únicamente a CBS (Cell Broadcast Centres) o a SMSC´s con funcionalidades de integración con CBS´s. La operación broadcast_sm , es emitida por el ESME para enviar SM al MC para la difusión del SM en una área geográfica determinada o un a un conjunto de zonas geográficas, para esta operación existe su broadcast_sm_resp.
109
Operaciones Auxiliares
Las operaciones ancilliary submission proporcionan gestión de mensajes presentados por las ESME´s. Esto incluye, cancelación, consultas y reemplazo de mensajes. PDU CANCEL_SM
Con la operación cancel_sm , el ESME cancela uno o más SM´s enviados con anterioridad con la operación PDU submit_sm. Parámetros mandatorios importantes del PDU CANCEL_SM: message_id : Identificador de un SM previamente enviado, puede ser nulo para cancelar un grupo de mensajes source_addr, source_addr_ton, source_addr_npi : Debe hacer match con el origen de los mensajes a cancelar destination_addr, dest_addr_ton, dest_addr_npi: Debe hacer match con el destino de los mensajes a cancelar. Puede ser nulo si la operación message_id es distinta de nulo PDU QUERY_SM
Este comando es emitido por el ESME para consultar el estado de un SM presentado o enviado con anterioridad con el comando submit_sm. El mecanismo de match se basa sobre el MC y los campos asignados message_id y source_address . Donde los parámetros submit_sm, data_sm o submit_multi (source address) fueron colocados o seteados originalmente con el valor NULL, entonces la dirección de origen en la consulta query_sm también se debe setear o establecer con el valor NULL. Parámetros mandatorios importantes del PDU QUERY_SM : message_id : identificador de mensaje entregado por un SUBMIT_SM_RESP previo source_addr, source_addr_ton, source_addr_npi : Deben hacer match con los datos de origen del SUBMIT_SM previo Parámetros mandatorios importantes del PDU QUERY_SM_RESP: message_id : identificador del SM final_date: fecha y hora en que el SM alcanzó un estado final message_state: status del SM consultado error_code: utilizado en caso de falla de entrega del SM PDU REPLACE_SM
Este comando es emitido por el ESME para sustituir un SM enviado anteriormente y que se encuentra pendiente de ser entregado a su destino final. El mecanismo de match está basado en el campo message_id y la dirección origen del mensaje original. Parámetros mandatorios importantes del PDU REPLACE_SM: message_id: identificador del SM a ser reemplazado source_addr, source_addr_ton, source_addr_npi: Debe hacer match con el originador del SM a reemplazar short_message: nuevo texto del SM.
110
Se conoce como “Red Inteligente” (IN) a una técnica que complementa a las redes de telecomunicaciones digitales con un método que transfiere el control de llamadas conmutadas por circuitos (CS) hacia una plataforma de control de mayor nivel. Estas redes digitales, basadas en los principios de señalización definidos por ISUP, pueden incluir resdes como RDSI, PSTN y las PLMN. Lo común en la aplicación de IN a estas redes es que el establecimiento de llamadas se intercepta en un nodo designado de la red, transfiriendo el control sobre la llamada a una Plataforma de Control . La Plataforma de control es la que determina cómo continuará el establecimiento de la llamada. El Punto de Control de Servicio (SCP) forma la plataforma de control para IN. El protocolo de control IN es la capacidad configurada que permite al operador imponer el control sobre la llamada. Se han definido varios protolos IN, de los cuales CAMEL es uno. La central está ubicada en la red núcleo y puede ser un nodo como una central local (LE), central de tránsito (TE) o MSC. El SCP se localiza en la capa de servicio . La capa de servicio puede contener una cantidad diversa de nodos, pero para IN, el SCP es la entidad principal a través de la que se puede imponer control sobre las llamadas.
111
Un principio fundamental de IN es la interacción entre el protocolo de señalización de la red core (por ejemplo ISUP) y el protocolo de control de red inteligente (INAP). En la figura se ven los componentes de red típicos para una llamada de móvil a móvil en una red GSM. Se ve la secuencia de señales ISUP. El móvil A (MS-A) establece la llamada a través de su VMSC (VMSC-A), el GMSC del abonado B (GMSCB), el VMSC del abonado B (VMSC-B) hasta el abonado B (MS-B). Entre el MSC y el MSC se utiliza el protocolo de control de llamadas DTAP (Parte de aplicación de transferencia directa). La interacción entre el MSC y el SCP ocurre en puntos designados de la secuencia de mensajes. Estas interacciones permiten al SCP influenciar en el procesamiento de la llamada. En el ejemplo siguiente, la interacción ocurre en los siguientes puntos: • Establecimiento de llamada: Cuando el MSC-A comienza el proceso de establecimiento de llamada como consecuencia de haber recibido un mensaje por la OTA del abonado A, invoca un servicio IN del SCP. La invocación del servicio IN implica el establecimiento de un dialogo IN entre el MSC y el SCP. Es a través de este diálogo que el SCP puede controlar la llamada • Alerta: Cuando el MSC-A recibe la indicación que el terminal del abonado B está alertando (sonando), envía una notificación al SCP • Contestación: Cuando el MSC-A recibe la indicación que el abonado B ha atendido la llamada, envía una notificación al SCP. • Desconexión: Cuando el MSC-A recibe la indicación de cualquiera de los lados liberó la llamada, envía una notificación al SCP y concluye el diálogo IN. Cerrar el diálogo IN tiene el efecto de terminar también el servicio IN.
112
Al momento de invocar el servicio y en las notificaciones de evento, el MSC copia elementos de información del mensaje de señalización (por ejemplo el mensaje ISUP) al mensaje de control IN. El SCP decide como controlar la llamada en base a la información recibida. El SCP puede decidir permitir continuar la llamada sin modificaciones, o bien con información modificada, lo que hará enviando al MSC elementos específicos de información que deberán reemplazar los elementos correspondientes en determinados mensajes ISUP. El SCP podrá retener el control de la llamada en su duración completa, o bien abandonar el control antes. Cuando el SCP abandona el control de la llamada, termina el servicio IN y la llamada podrá continuar sin control IN. La invocación al servicio IN está basada en criterios presentes en la central. En este ejemplo, el VMSC-A determinó que para esta llamada, se deberá invocar un servicio IN. La IN tradicional no define criterios de invocación específicos. Un operador podrá definir estos criterios en un MSC según considere adecuado. Los ejemplos incluyen: • Invocación basada en números llamados: El MSC lanza un servicio IN para ciertos números o rangos de números, por ejemplo un 0800 lanza un servicio de llamada gratuita. • Invocación basada en troncales: Una llamada que arriba a partir de un troncal específico lanza un servicio IN, por ejemplo llamadas recibidas de otra red lanzan un servicio de filtrado de llamadas. • Invocación basada en suscripciones: Llamadas de un abonado específico lanzan un servicio IN, por ejemplo llamadas de abonados de una compañía lanzan un servicio de red privada virtual (VPN). La central que invoca el servicio IN requiere configuración en varias otras características relacionadas con el servicio IN, entre las que se incluyen: La dirección del SCP donde residen los servicios IN El protocolo que se utilizara para el servicio IN Los elementos de información que deberán proveerse al servicio IN
113
Función de Servicio de Conmutación (SSF) El protocolo de control IN en la central es manejado por la función de servicio de conmutación (SSF). La SSF pasa el control de la llamada de la central al SCP y retransmite las instrucciones del SCP hacia la central. Maneja los aspectos del protocolo IN. En la invocación del servicio IN, la SSF copia información del protocolo de acceso (ISUP o DTAP por ejemplo) en el mensaje INAP que utilizará para invocar el servicio IN. Cuando la SSF recibe instrucciones del SCP, copia la información recibida en el protocolo de control de llamadas. En una red GSM, cada MSC podrá equiparse con un SSF, o bien existirá un MSC designado con SSF. Una red podrá tener una mezcla de control IN centralizado y distribuido, dependiendo del tipo de servicio IN. El control IN centralizado requiere menor inversión en SSF, pero puede llevar a tener más cantidad de mensajes ISUp debido a que las llamadas deben enrutarse a través del MSC designado para poder invocar los servicios IN. El control centralizado de IN podrá aplicarse también cuando el MSC designado tiene capacidades de control IN específicas que otros MSC de la red no pueden ofrecer, por ejemplo cuando la red núcleo está formada con equipamiento de diferentes fabricantes. Función de Servicio de Control (SCF) La función de servicio de control es la entidad funcional que reside en el SCP, formando la aplicación que facilita la ejecución de los servicios IN. El SCP es un nodo direccionable en la red SS7. Los otros nodos de la red podrán comunicarse con el SCP a través del protocolo de señalización SS7. Tanto para CAMEL como para INAP, el comportamiento de la SCF se define en menor detalle que el comportamiento de la SSF. La razón es que, una vez que el SCF tomó el control de la llamada, decidirá cómo continuará. Si bien se define el protocolo de IN que deberá soportar (por ejemplo INAP), el comportamiento de la lógica del servicio es específico del operador.
114
Modelo Básico de Estado de Llamada (BCSM)
Un concepto fundamental en el control IN es el Modelo Básico de estado de llamada (BCSM). Cuando una central procesa una llamada, ésta pasa por un número de fases predefinidas. El BCSM describe las fases de la llamada, siguiendo en general la señalización ISUP de la llamada. Los mensajes ISUP recibidos por la central resultan en la transición de un estado BCSM a otro. La definición del BCSM permite al MSC interactuar con el SSF en puntos definidos de la llamada. El SSF podrá a su vez contactar al SCP. El BCSM contiene Puntos de detección (DP) y Puntos en llamada (PIC). EL PIC indica el estado de una llamada, por ejemplo análisis, enrutamiento, alerta y activa. El DP está asociado a la transición entre estados. Cuando la llamada llega a un determinado PIC, el BCSM primero procesará el DP asociado con la transición a dicho PIC. Por ejemplo cuando la llamada está en la fase de alerta y se recibe un evento de contestación mediante ISUP, el BCSM procesa el DP asociado con el evento de contestación. Una vez completado el procesamiento del DP el BCSM transita hacia el PIC activo. El BCSM describe un modelo al cual la central debe remitirse para manejar el establecimiento de una llamada. Para cada llamada manejada por la central se lanza un proceso que se comporto según la definición del BCSM. Esto se describe comúnmente como “se crea una instancia BCSM”. Los mensajes ISUP que pasan por esta central podrán provocar que la instancia BCSM de la llamada pase de un estado a otro. La SSF de la central podrá notificar al SCP y, dependiendo de la lógica del servicio IN continuar procesando el mensaje de contestación ISUP. En la práctica esto significa retransmitir el mensaje de contestación en la dirección del originante de la llamada. En INAP CS-1 se definieron dos tipos de BCSM: El BCSM de llamada originante y el de llamada de terminación. Están basados en los mensajes ISUP utilizados para el establecimiento de llamadas del protocolo DSS1 (protocolo utilizado entre un terminal ISDN y la red ISDN). Los BCSM definidos en CAMEL están derivados del INAP CS1. IN define cuatro tipos de DP: • Trigger detection point – Request (TDP-R): Cuando la instancia BCSP para una llamada transita a un DP definido como TDP-R, se podrá lanzar un servicio IN en ese punto. Esto implica que el SSF notificará la SCF y esperará instrucciones. El procesamiento de la llamada en el MSC se suspenderá hasta que la SSF haya recibido las instrucciones de la SCF. Estos TDP se definen de manera estática en la central. Definiendo diferentes DP del BCSM como TDP, la central podrá invocar servicios IN en diferentes puntos de la llamada. • Trigger detection point – Notify (TDP-N): El TDP-N es una variante del TDP-R. Un servicio IN podrá ser invocado desde un DP definido como TDP-N. En este caso la SSF no esperará instrucciones del SCP, retornando el control de la llamada directamente al MSC. Como resultado, el procesamiento de la llamada no se suspende. El SCP no adquiere control sobre la llamada, siendo simplemente notificado de la ocurrencia de un evento. El uso de TDP-N no es muy común en IN, CAMEL define únicamente TDP-R. • Event detection point – Request (EDP-R): Cuando se invoca un servicio IN, este podrá “armar” DP´s dentro del BCSM como Puntos de detección de eventos (EDP). Armar un DP implica que el servicio IN instruye a la SSF a monitorear la ocurrencia del evento asociado con el DP. Cuando el evento se produce, la SSF notifica el SCP. Si el DP se armó como EDP-R, la SSF suspende el procesamiento de la llamada luego de la notificación y aguarda instrucciones del SCP. El reporte de un evento armado como EDP-R se conoce como modo interrumpido. •
Event detection point – Notify (EDP-N): El servicio IN podrá armar un EDP en modo interrumpido o modo notificación. Cuando se arma en este modo, la SSF reporta la ocurrencia del evento asociado con el DP pero no
suspende el procesamiento de la llamada. En su lugar, la SSF instruye al MSC a continuar el procesamiento de la llamada. Un servicio IN normalmente guarda una imagen de la instancia BCSM en la SSF para la llamada que está siendo controlada por un servicio IN. De esta manera, IN conoce la fase de la llamada y qué eventos podrán ocurrir. A efectos de mantener esta imagen del BCSM, el servicio IN armará DP´s en el BCSM para recibir notificaciones de las transiciones de estado que ocurren en el BCSM. Cuando un DP no está armado se conoce como transparente” .
115
CAMEL es la evolución natural de los estándares IN definidos por ITU-T, ETSI y Bellcore. Muchos de los conceptos definidos en Core INAP CS1 se aplicaron en CAMEL.Por lo tanto, CAMEL es por definición un estándar IN. La necesidad de CAMEL creció durante el desarrollo del estándar de red GSM. Si bien cuando se desarrolló el estándar GSM (entre los ´80 y ´90) IN ya estaba en uso en la mayoría de las redes fijas, las redes GSM permitieron nuevos servicios avanzados lo que requirió mejoras a los estándares existentes. CAMEL es una prestación de la red y no un servicio suplementario. Es una herramienta para el operador para que pueda ofrecer servicios específicos aún cuando el abonado esté en otra red. Estas mejoras fueron agregadas por los operadores utilizando las redes IN existentes. Esta práctica sin embargo tenía numerosos inconvenientes: Las capacidades de IN relacionadas con tarifación estaban indefinidas en los estándares existentes, debiendo • definirlas los operadores que implementan IN • Los métodos de activación no están definidos, por lo que no existe un conjunto de reglas unificadas que indique cuando un conmutador como un MSC debe invocar un servicio IN para un abonado. • Los estándares IN existentes habían sido desarrollados para redes fijas. Muchos aspectos específicos de GSM no estaban soportados. Los estándares IN existentes no soportaban los aspectos de movilidad de GSM, por ejemplo, abonados • haciendo roaming a otras redes GSM y utilizando sus servicios básicos y s uplementarios en dichas redes. Para atender estos problemas, el ETSI introdujo un estándar IN específico para la red GSM. Este estándar IN específico de GSM (CAMEL) forma parte integral de los estándares GSM de ETSI. La primera versión de CAMEL se introdujo en la fase 2+ rel. 96 de GSM (GSM R96). Los aspectos principales de CAMEL en comparación con los protocolos IN tradicionales incluyen: • El protocolo de control IN de CAMEL: Camel Application Part (CAP) está completamente especificado, incluyendo tarifación. CAMEL puede utilizarse en redes GSM con equipamiento de múltiples proveedores. • El abonado podrá usar los servicios CAMEL tanto en su red home como en roaming. • • El estándar IN CAMEL está diseñado para la red GSM y evoluciona acompañando el desarrollo de GSM .
116
117
118
Actualización de Locación – Subscripción de servicios Procedimiento de registro con fallback a CAMEL Fase 1: 1. El abonado con CAMEL Fase 2 se registra en un MSC en VPLMN. El MSC soporta únicamente fase 1 2. El MSC solicita al HLR de la HPLMN los datos de subscripción, indicando que soporta CAMEL Fase 1 3. El HLR no puede enviar datos de Fase 2 (O-CSI) pero en su lugar decide enviar datos de Fase 1 4. El HLR envía datos de CAMEL Fase 1 al MSC (O-CSI) 5. El abonado queda registrado en el MSC. El MSC invocará servicios CAMEL Fase 1 para las llamadas MO y MF.
Posiblemente la característica más importante de CAMEL es su aspecto relacionado a la movilidad. Un operador GSM puede ofrecer un servicio IN a sus abonados. Este servicio podrá ser utilizado de idéntica manera en su red home como cuando visita otras redes. Esto se logra mediante la especificación estricta de la gsmSSF, la entidad SSF para redes GSM, en combinación con los datos de subscripción CAMEL. Para que un usuario utilice un servicio CAMEL, deberá tener datos de subscripción CAMEL en su perfil GSM en el HLR. Cuando un abonado se registra en una PLMN, el HLR podrá transferir los datos de subscripción CAMEL del abonado al MSC/VLR. Cuando el abonado origine una llamada desde la PLMN, el MSC que lo atiende podrá invocar un servicio CAMEL para este abonado. La transferencia de los datos de subscripción CAMEL del HLR al MSC/VLR está en línea con los aspectos de movilidad de GSM. Una red GSM soporta varios servicios básicos y suplementarios. Los abonados de una red podrán subscribirse a estos servicios. Esto implica que el abonado tendrá datos de su subscripción en el HLR para dichos servicios, el HLR transferirá los datos al MSC/VLR. De esta manera, los servicios suplementarios estarán personalizados para este abonado. Similarmente, la transferencia de los datos de subscripción desde el HLR al MSC/VLR, personaliza la invocación de servicio CAMEL para un abonado. Cuando un abonado CAMEL se registra en un MSC/VLR, entre el HLR y el VLR ocurre la negociación de capacidades CAMEL Esta negociación implica que el HLR determina si el abonado está habilitado a regisrarse en ese VLR y qué datos CAMEL debe enviar al VLR. Esto s e debe a que diferentes redes GSM podrán tener diferentes niveles de soporte CAMEL, por ejemplo la HPLMN del abonado GSM podrá soportar diferentes fases que la VPLMN. Los ejemplos incluyen: • La HPLMN del abonado soporta CAMEL Fase 1 y Fase 2. La VPLMN soporta sólo CAMEL Fase 1 La HPLMN del abonado soporta CAMEL Fase 1 y Fase 2. La VPLMN no soporta CAMEL. • Por lo tanto, un abonado que tiene subscriptos servicios de CAMEL Fase 1 y 2 para llamadas originadas en su móvil (MO) podrá desplazarse a una PLMN que no so porte CAMEL Fase 2. Si el abonado se registra en esa PLMN, su HLR no podrá enviar los datos de subscripción de CAMEL Fase 2 al VLR, y como resultado, el abonado no podrá utilizar sus servicios CAMEL Fase 2. En esta situación, el HLR deberá tomar una acción de fallback durante el registro, la que podrá ser alguna de las siguientes: 1. El HLR permite la registración normal, sin enviar datos CAMEl al VLR. Esta opción podrá ser utilizada por abonados GSM que subscriben, por ejemplo a un servicio VPN de CAMEL Fase 2 y el operador no tiene VPN de CAMEL Fase 1. El abonado no dispondrá de las funciones VPN disponibles en su red, como discado corto. 2. El HLR permite la registración normal y envía datos CAMEL de una fase menor, considerando que dicha fase es soportada por el VLR. Esta opción podrá ser utilizada por abonados GSM prepagos. Si la VPLMN no soporta CAMEL Fase 2, pero soporta Fase 1, el abonado se registrará en Fase 1. El nivel de servicio será menor, pero por lo menos los abonados prepagos podrán registrarse en la red y realizar llamadas. 3. El HLR permite una registración restricta. Esta opción implica que el HLR envía un mensaje de Prohibición de todas las llamadas salientes (BAOC) al VLR. El BAOC impide que el abonado establezca llamadas salientes o derive llamadas. La capacidad de recibir llamadas no se afecta. El abonado podrá utilizar servicios de Callback USSD para establecer llamadas vocales. 4. El HLR no permite la registración. Esta opción podrá, por ejemplo, ser utilizada por abonados prepagos de CAMEL Fase 2 cuando el operador no dispone de servicios CAMEL Fase 1 prepagos o servicios callback USSD. El MS del abonado deberá intentar registrarse en otra red. La lista de arriba no es obligatoria en CAMEL, pero es bastante común en las implementaciones de HLR que soportan CAMEL. La Opción de fallback podrá generalmente configurarse por abonado.
119
A medida que se agregan más y más elementos de subscripción CAMEL en las siguientes fases, los algoritmos del HLR utilizados para decidir qué datos CAMEL enviar al VLR adquiere mayor complejidad. El comportamiento exacto del HLR para determinar qué datos enviar sigue siendo específico del operador. Sin embargo se utilizan las siguientes regles en el HLR y VLR: • Cuando un MSC/VLR no indica sus fases CAMEL soportadas, el HLR asumirá que soporta CAMEL Fase 1 • Cuando el HLR envía datos CAMEL al MSC/VLR, éste responderá las fases CAMEL que soporta • Un MSC/VLR que soporta una fase CAMEL en particular, soportará el conjunto completo definido en la fase, en tanto dichas capacidades estén relacionadas con el MSC/VLR • Un MSC/VLR que soporte una fase en particular de CAMEL, soportará todas las fases previas Estas reglas garantizan que los servicios CAMEL que están operativos continuarán estándolo en una VPLMN luego de una actualización a la fase CAMEL siguiente. Soporte CAMEL Selectivo Un operador GSM podrá decidir ofrecer capacidades CAMEL en su red a socios de roaming específico, por ejemplo brindando determinado soporte a los abonados provenientes de una u otra compañía. Esta distinción se puede hacer a través del análisis del IMSI en el momento del registro al MSC. El operador podrá configurar capacidades por rangos IMSI. Se puede refinar más aún, donde podrá por ejemplo ofrecer capacidades de Fase 3 a determinados rangos de IMSI, Fase 2 a otros rangos, y no soportar CAMEL para el resto.
120
Si bien CAMEL incluye un amplio rango de funcionalidades relacionadas con la implementación de IN en la red GSM, una parte importante es el protocolo de control IN, utilizado entre la gsmSSF y la gsmSCF. El protocolo de Parte de Aplicación CAMEL (CAP) deriva del Core INAP CS1. La capacidad de CAP se define en términos de “operaciones” . Una operación puede ser vista como un mecanismo por el cual una entidad lanza un procedimiento en la entidad par. El envío de IDP al SCP significa que la gsmSSD inicia un procedimiento en el SCP. El SCP podrá a su vez enviar una operación a la gsmSSF, iniciando de esta manera un procedimiento en la gsmSSF. La entidad que recibe una operación podrá responder al originante. El envío de una respuesta dependerá de la operación específica y del resultado de procesar la operación. Se pueden especificar tres tipos de información para cada operación: • Argumento: El emisor de la operación podrá incluir un argumento conteniendo los parámetros que deberán usarse como datos de entrada de la llamada de proceso. • Resultado: Para algunas operaciones se define un resultado. El receptor de una operación podrá reportar el efecto del procesamiento de la operación en el resultado. • Errores: Para muchas operaciones, el receptor podrá reportar un error. Se enviará un error cuando el receptor encuentre un problema en el procesamiento de la operación. Si el emisor no recibe un error de operación dentro de de un período definido de tiempo, asumirá que la operación se ejecutó correctamente. Este período (conocido como “tiempo de operación”) se especifica para cada operación CAP. GSM utiliza el lenguaje de Notación de Sintaxis Abstracta número 1 (ASN.1) definido en X.680 a X.683. Este lenguaje se utiliza para varios de los protocolos GSM, como por ejemplo MAP. La transferencia de las operaciones CAP entre el MSC/gsmSSF y el SCP se realiza a través de la red SS7.
121
Cada entidad de la red SS7 es direccionable mediante un punto de código de señalización (SPC), que es un número único asignado localmente. Por lo tanto, para invocar un servicio CAMEL en el SCP, el SPC del SCP debe envíar el primer mensaje SCCP conteniendo la operación CAP IDP al SCP. Sin embargo, la dirección gsmSCF del O-CSI no es el SPC del SCP sino un título global (GT) del servicio CAMEL. La razón de este principio es que el operador de la red que contiene al SCP podrá alterar la configuración de la red SS7, incluyendo cambios en la asignación del SPC. Sin embargo, los GT utilizados para direccionar las entidades en la red en la que el SPC cambió no son afectados. Esto se logra mediante la translación de GT en el STP. El STP traduce los GT utilizados por el servicio CAMEL en los SPC del SCP correspondewinte. Cuando el MSC/gsmSSF recibe la primer respuesta del SCP, almacena su dirección. Esta será el GT de dicho SCP. A partir de ese momento, el MSC/gsmSSF utiliza la dirección almacenada internamente para las comunicaciones subsiguientes hacia ese SCP por el resto del diálogo CAMEL. La capa TC del protocolo SS7 en el MSC/gsmSSF no reporta el GT del SCP que responde a su capa de aplicación, es decir el protoco CAP. La aplicación sólo conoce el GT utilizado para invocar el servicio CAMEL. Esta restricción es debido a que la entidad que inicia un servicio global no debe recibir información acerca de la configuración de red de otro operador.
122
Las entidades de la red GSM tienen un número de subsistema (SSN). El SSN se utiliza para direccionar un subsistema particular dentro de un nodo SS7. Un nodo en una red GSM puede contener, por ejemplo, MSC y el HLR, o bien el MSC, HLR y gsmSSF. Dicho nodo tendrá un único SPC en la red SS7, pero los subsistemas internos tendrán diferentes SSN. Los SSN también pueden usarse en el STP cuando se realiza la translación GT para derivar el SPC de la entidad destino. El SSN de CAP no se asigna a un nodo sino a un protocolo. Este SSN es utilizado por cualquier entidad que hable CAP, como ser gsmSCF, gsmSSF (en los MSC o GMSC), gprsSSF (en el SGSN), etc. Cuando el MSC/gsmSSF y el gsmSCF residen en el mismo nodo de la red SS7, el SSN de un mensaje SCCP entreante no puede utilizarse para seleccionar la entidad a la que es destinado. En su lugar, el nodo deberá analizar, por ejemplo, el contexto de aplicación del protocolo o el código de operación. El SSN se utiliza únicamente durante el establecimiento del diálogo. Una vez que el MSC/gsmSSF y el gsmSCF establecieron su relación CAMRL, las dos entidades habrán intercambiado un identificador de transacción TC. Este identificador de transacción es único dentro de un nodo SS7 y está relacionado con un diálogo CAMEL específico. El nodo SS7 asignará un nuevo identificador de transacción TC para cada diálogo TC que inicie o acepte. Cuando se liberó la primera versión de CAMEL (1996) se asignó el SSN 5 a CAP. Luego se vio que ese SSN ya estaba siendo utilizado por otra entidad de la red SS7, por lo que se cambió a SSN 146. Al mismo tiempo, se introdujo un SSN para los mensajes MAP con el SCP (SSN147).
123
La capa TC de SS7 es responsible de establecer, mantener y cerrar un diálogo entre dos entidades. Esto se realiza transfiriendo mensajes TC entre las entidades. Los mensajes TC se usan también para enviar componentes CAP, como ser Invocación, retorno y error de operaciones. Un diálogo TC ocurre entre dos puntos terminales de señalización. Los STP del enlace no están involucrados en el diálogo TC. Las operaciones CAP están embebidas dentro de los mensajes TC, que a su vez se encapsulan en mensajes SCCP y son transportados a destino por SCCP y MTP. En la administración del diálogo se utilizan los mensajes siguientes: • TC Begin: Se utiliza para iniciar un diálogo TC. Puede contener operaciones como DP inicial, Iniciar intento de llamad o instrucción de pedido de asistencia • TC Continue: Continúa o termina un diálogo TC y transfiere una o más operaciones, resultados o errores CAP. • TC End: Se utiliza para cerrar de manera explícita un diálogo TC. También puede contener operaciones CAP • TC Abort: Aborta un diálogo TC cuando se produjo un error que requiere cerrar el diálogo, pero la entidad no tiene la posibilidad de cerrarlo de la manera correcta. Puede ser emitido por TC (P abort) o bien por el usuario TC, es decir la aplicación (U Abort) En la figura se ve un ejemplo de cómo funciona la señalización TC entre el MSC/gsmSSF y el SCP. El diálogo TC se establece no bien el gsmSSF recibe el primer TC Continue. A partir de allí, el gsmSSF direcciona la instancia lógica de servicio CAMEL en el SCP utilizando el identificador de transacción TC, el que fue incluido en el primer TC Continue del SCP. Las operaciones, errores y resultados CAP se transportan como componentes TC. Un mensaje TC puede tener uno o varios componentes TC. En la tabla se ilustran los tipos de componentes TC que pueden transportarse.
124
Las gsmSSF, gsmSCF y otros components que hablan CAP, pueden incluir múltiples componentes CAP dentro de un único mensaje TC, en lugar de transportarlos en mensajes separados. Este método tiene dos propósitos: Eficiencia de señalización y manejo de errores. Cuando la gsmSSF recibe el mensaje TC Continue conteniendo las operaciones apply charging (ACH), furnish charging (FCI) y continue (CUE) , comienza el procesamiento de las operaciones en ese orden. En caso que el procesamiento de cualquier operación CAP falle, la gsmSSF reportará error de ejecución al SCP (siempre que la operación fallida tenga una definición de error) y descartará las operaciones aún no comenzadas del buffer TC. En el ejemplo, si falla FCI, el SCP concluye que dado que FCI tuvo error el CUE no se ejecutó. El SCP podrá en ese caso tomar una acción correctiva, que podrá ser enviar el CAP CUE o la liberación CAP (RC). Sólo deberá realizarse este tipo de agrupamiento de operaciones CAP cuando éstas tengan definición de error, a menos que sea la última del mensaje TC. De otra manera,el SCP no tendrá ningún reporte acerca de la falla en la ejecución de una operación y el consiguiente descarte de las restantes contenidas en el mismo mensaje TC, por lo que no podrá tomar acciones correctivas para las operaciones descartadas.
125
Arquitectura de CAMEL Fase 1
Como se ve en la figura, los nodos anexos a la red GSM que forman la arquitectura CAMEL Fase 1 tienen una estructura similar a los definidos para la red inteligente IN, pero en este caso les antecede el indicador “gsm”, que señala que corresponden a la red GSM. Esta Fase 1 de CAMEL permite la visita a redes externas pero el encaminamiento de la llamada se realiza a través de la red local, resultando en la posibilidad de dos ramas de roaming, una nacional y otra internacional. De manera de proveer la capacidad CAMEL a los usuarios, la información específica de estos se intercambia entre las redes públicas móviles terrestres (PLMN). La información específica de los suscriptores se almacena en el HLR y es denominada como información de suscripción CAMEL (CSI) . La información de suscripción de usuario CAMEL CSI se envía al VLR en el momento de la actualización de la localización, al restablecer datos o cuando estos son actualizados por una acción administrativa. El CSI es enviado a la pasarela del centro de conmutación móvil (GMSC) cuando el HLR responde a un requerimiento para información de encaminamiento. Cuando se procesan las llamadas para usuarios que requieren soporte CAMEL, el centro de conmutación móvil MSC recibe el CSI desde el VLR que indica al MSC pedir información desde el punto de conmutación de servicio (gsmSSF: GSM Service Switching Function). El MSC supervisa bajo requerimiento los estados de la llamada e informa al gsmSSF de estos estados durante el procesamiento, permitiendo al gsmSSF controlar la ejecución de la llamada en el MSC. El gsmSSF es una entidad funcional derivada del SSF de la red inteligente IN, pero usa diferentes mecanismos de disparo a causa de la naturaleza de la red móvil. La entidad funcional gsmSCF (GSM Service Control Function) contiene la lógica de servicio para implementar los servicios específicos de operador OSS. La interfaz gsmSCF-gsmSSF usa el protocolo CAP (CAMEL Application Part) basado en un subconjunto del núcleo de INAP CS-2 de la ETSI. La interfaz gsmSCF-HLR usa el protocolo MAP (Mobile Application Part).
126
Entidades Funcionales
Desde la perspective de CAMEL, las entidades funcionales de GSM adquieren nuevas funcionalidades. En la figura se incluye una única instancia de cada entidad. Sin embargo, es posible tener múltiples instancias, y además dos o más entidades podrán estar localizadas en el mismo nodo físico. En muchas redes, los MSC funcionan también como GMSC. En redes pequeñas el gsmSCF puede estar colocalizado con el MSC/gsmSSF.
HLR El HLR es la entidad en la red que contiene los datos de suscripción CAMEL, agrupados en Elementos de Información de Servicio CAMEL (CSI). Los servicios CAMEL son en principio servicios IN “suscriptos”. Esto significa que un abonado tiene una suscripción a un servicio CAMEL, por lo que tiene su CSI correspondiente en su perfil de suscripción GSM en el HLR. El contenido del CSI se relaciona con el servicio CAMEL suscripto, es decir qué servicio será invocado. Los datos de suscripción contenidos en el HLR podrán distribuirse a los restantes nodos de la red GSM, incluyendo MSC, GMSC, SGSN y gsmSCF. Estos nodos podrán estar en la HPLMN o VPLMN. El HLR siempre reside en la HPLMN del abonado. El HLR podrá enviar datos de suscripción CAMEL al MSC/VLR y al GMSC. Las diferencias son las siguientes: Los CSI enviados al MSC/VLR permanecen en tanto el abonado esté registrado en dicho MSC. Cuando el • abonado apaga su teléfono, permanece registrado en el MSC. Cuando lo enciende nuevamente, el MSC no requiere pedir los datos CAMEL al HLR nuevamente. • Cuando el teléfono está apagado un largo tiempo, sus datos de registro, incluyendo los datos de suscripción CAMEL pueden eliminarse del VLR, por lo que el abonado deja de estar registrado en ese MSC. La duración es dependiente del operador. Por ejemplo 24 hs. Cuando el abonado está registrado, pero el VLR no tiene contacto de radio por un cierto tiempo, podrá decidir • también eliminar sus datos. Cuando el abonado restablece contacto con el MSC, éste realiza una actualización de locación, luego de la cual • registra al abonado, incluyendo los datos CAMEL. • Los CSI que se envían del HLR al GMSC permanecen en dicho GMSC por la duración del procesamiento de la llamada saliente. Una vez que concluye la llamada, los datos CAMEL se descartan en el GMSC. Es decir que para cada procesamiento de llamada el GMSC deberá recibir los datos CAMEL (junto con otros datos GSM) del HLR. Este comportamiento es coherente con los principios genéricos de GSM. Otra función del HLR es aplicar manejos específicos de CAMEL para llamadas terminadas en el móvil (MT). Por ejemplo, el HLR podrá obtener el estado del abonado y su locación del VLR, enviarla al GMSC para que éste pueda enviarla al gsmSCF como entrada para un procesamiento CAMEL de MT.
127
gsmSCF La gsmSCF es la entidad donde residen los servicios CAMEL. La gsmSCF reside en la HPLMN. Todos los pedidos de servicio CAMEL se direccionan al gsmSCF. La gsmSCF es una entidad funcional . El nodo donde reside se llama “punto de control de servicio”. El término gsmSCF se introdujo en la especificación CAMEL de GSM para distinguirlo claramente ente un SCF estandarizado (CAMEL) y un SCF propietario Por lo tanto aplican las siguientes convenciones: • gsmSCF: Una función de control de servicio, de acuerdo con un protocolo estándar GSM (por ej. CAMEL); la gsmSCF soporta CAP y partes relevantes de MAP, pudiendo soportar también otros protocolos, los que, sin embargo, no entran dentro de la especificación CAMEL • SCF: Función de control de servicio de acuerdo a ITU-T INAP (por ej. CS1 o CS2) o protocolos IN propietarios. Puede soportar también partes relevantes de MAP, extensiones propietarias y otros protocolos. Un SCP podrá contener tanto un gsmSCF y un SCF. Esto significa que podrá estar corriendo servicios CAMEL y CS1 u otros servicios no-CAMEL al mismo tiempo. Por ejemplo un SCP podrá ofrecer un servicio CS1 a un abonado en la HPLMN. Cuando ese abonado se registre en otra PLMN, el SCP podrá ofrecerle servicios CAMEL Fase 2. Para logara esta diferenciación de servicios, el HLR deberá enviar diferentes datos de suscripción IN a los MSC/VLR en redes diferentes. El envío de suscripciones no-CAMEL del HLR al MSC/VLR o GMSC no está especificado dentro del estándar CAMEL. Sin embargo, los mecanismos de extensión de varias operaciones MAP permiten la transferencia de información específica del operador al MSC/VLR o GMSC. Un operador podrá por ejemplo usar CS1 para un servicio prepago en su HPLMN, permitiendo a su abonado ir a otra PLMN utilizando CAMEL, pero manteniendo CS1 en su red. En ese caso, deberá operar ambos servicios para el mismo grupo de abonados. Los servicios podrán residir en el mismo o diferentes SCP. MSC/gsmSSF El MSC/gsmSSF es un MSC con capacidad integrada CAMEL, teniendo la posibilidad de recibir y almacenar datos CAMEL en el VLR. El MSC también tiene una función de conmutación de servicios gsm integrada (gsmSSF), que forma el puente entre el MSC y la gsmSCF. Cuando se establece una llamada en el MSC, el MSC deberá verificar si está sujeta a manejo CAMEL. La presencia de O-CSI en el VLR para ese abonado indica que el MSC deberá pedir la invocación de un servicio CAMEL para esa llamada. Para ello lanza el proceso gsmSSF. La función gsmSSF establece una relación con la gsmSCF en la HPLMN del abonado siempre que se cumplan los criterios de l anzamiento. También se debe tomar en cuenta la distinción entre los nombres entre SSF CAMEL y SSF no-CAMEL: • gsmSSF: función de servicio de conmutación de acuerdo al protocolo GSM estándar (CAMEL). Siempre está localizada en el MSC visitado (VMSC, conectado a la red de acceso de radio) o pasarela MSC (MSC que interroga al HLR como parte del procesamiento de una llamada MT) • SSF: Función de servicio de conmutación de acuerdo a un protocolo no-CAMEL. Podrá estar localizada en el VMSC y GMSC pero también en centrales MSC de tránsito o centrales de la red fij a. Un MSC o central fija con SSF integrado se llama Punto de conmutación de servicio (SSP), si bien no se utiliza de forma general para la combinación de MSC o GMSC y gsmSSF. Un MSC podrá tener un gsmSSF y un SSF integrados simultáneamente, por lo que podrá establecer diálogos CAMEL y no-CAMEL. GMSC/gsmSSF El GMSC/gsmSSF es el GMSC con capacidad CAMEL integrada. Tiene la capacidad de recibir datos CAMEL durante el manejo de llamadas terminantes. El GMSC tiene una función gsmSSF integrada que forma el puente entre el GMSC y la gsmSCF. Cuano llega una llamada al GMSC (por ejemplo recibe un IAM para una abonado de esa red) y el GMSC recibe los datos CAMEL del HLR (en el mensaje MAP SRI-Res), inicia una instancia gsmSSF, la que establece una relación con la gsmSCF en la HPLMN del abonado llamado. Si bien conceptualmente el GMSC está ubicado en la IPLMN, generalmente la IPLMN y la HPLMN son la misma red, por lo que el GMSC y el SCP están normalmente en la misma red. Si bien CAMEL especifica un proceso único gsmSSF para el MSC y el GMSC, las instancias gsmSSF se comportan de manera diferente, dependiendo de la llamada. De manera similar el GMSC podrá tener una gsmSSF y una SSF integradas conjuntamente, por lo que podrá establecer relaciones CAMEL y no-CAMEL al mismo tiempo para diferentes abonados. Existe una ligera diferencia entre la coexistencia de relaciones CAMEL y no-CAMEL en el VMSC y en el GMSC. Un abonado de la PLMN-A podrá recibir un servicio CAMEL cuando se registra en un MSC de la PLMN-B y un servicio propietario no-CAMEL cuando se registre en un MSC de la PLMN-A (su propia red). El GMSC, por otro lado, usualmente procesa llamadas terminadas en abonados de la misma red únicamente, debido a que normalmente reside en la HPLMN. De esta manera, el procesamiento de llamada terminante se hace siempre en la HPLMN del abonado llamado, independientemente del origen de la llamada. El operador podrá entonces ofrecer servicios IN consistentes para llamadas MT de un grupo (CAMEL o propietarios). Ver figura.
128
El control de llamadas de CAMEL Fase 1 utiliza dos modelos de estado: El modelo para llamadas originantes (O-BCSM) y el modelo para llamadas terminantes (T-BCSM). Los BCSM definen el proceso en el MSC o GMSC para procesar la llamada. El O-BCSM se utiliza para procesar llamadas MO y MF, el T-BCSM para las llamadas MT. Los BCSM contienen puntos definidos en el model de estados en donde el MSC podrá interactuar con la gsmSSF. La gsmSSF podrá a su turno interactuar con la gsmSCF. Para cada llamada establecida en el MSC, se instancia un BCSM. Si bien la definición del BCSM se produjo con la introducción de CAMEL en GSM, el hecho que se procese un BCSM no implica que se invoque un servicio CAMEL en esa llamada. En principio, se invoca una instancia de BCSM para cada llamada. Si no se requiere un servicio CAMEL, el procesamiento de la llamada seguirá de acuerdo a las reglas de procesamiento de llamada de GSM, sin control de CAMEL. El proceso de manejo de llamadas en el MSC puede no ser consciente de la invocación de servicios CAMEL, de acuerdo a la separación funcional estricta que se define según: • GSM TS 03.18 especifica los procesos de manejo básico de llamadas, los cuales podrán llamar a procedimientos CAMEL en puntos definidos • GSM TS 03.78 contiene los procedimientos CAMEL, los que, cuando se requiera, podrán enviar una señal interna al gsmSSF Durante los procesamientos normales de llamada, el proceso de manejo de llamada del (G)MSC transita de un PIC del BCSM a otro. La secuencia normal para una llamada MO podría ser por ejemplo: O_Null → analyse, routing and alerting → O_Active → O_Null . Cuando se transita de un PIC al siguiente, el BCSM pasa a través de un DP. La Fase 1 de CAMEL no incluye DP´s para casos de falla de establecimiento, como ser abonado ocupado o no contesta. Cuando ocurre un evento de este tipo, el BCSM transita al PIC de excepción y desde allí al estado null. En ese caso, la gsmSSF aborta el diálogo CAMEL. De manera similar, cuando el abonado llamante abandona la llamada antes de ser atendida, la gsmSSF transita al PIC excepción y aborta el diálogo CAMEL. A menudo estas cancelaciones del diálogo CAMEL se ven como una indicación de falla. Sin embargo están causadas por limitaciones en el modelo BCSM y no son erróneas.
129
Llamadas Originadas en Móvil (MO)
Las llamadas MO son llamadas establecidas por un abonado GSM registrado en un MSC. Todas las llamadas MO establecidas por un suscriptor CAMEL pueden estar sujetas al control de CAMEL, excepto llamadas de emergencia, (TS12) que saltan todo el manejo CAMEL en el MSC. Cuando un abonado establece una llamada MO, el MSC comienza el proceso básico de manejo de llamada, incluyendo la verificación respecto a si el abonado tiene una suscripción al servicio básico requerido. Si el VLR no lo tiene suscripto por no haber recibido la información de suscripción requerida del HLR, el MSC rechazará el intento de llamada, aún antes de invocar un servicio CAMEL. Los servicios básicos suscriptos se provisionan en el HLR, quien los envía al VLR al momento de la actualización de locacalización. Cuando un abonado tiene un O-CSI en su perfil y ninguna de las verificaciones previas del MSC rechazó la llamada, el MSC pasará el control de la llamada a la gsmSSF, suspendiendo en ese momento el procesamiento de manejo de la llamada. La gsmSSF utilizará la información del O-CSI para invocar el correspondiente servicio CAMEL, suspendiendo su operación mientras aguarda instrucciones de la gsmSCF. El establecimiento de la llamada continuará una vez que la gsmSCF envíe una operación de continuación de llamada al gsmSSF. Las siguientes son las operaciones de continuación de llamadas: • Continue (CUE) – La gsmSCF instruye a la gsmSSF a establecer la llamada al destino discado. El MSC compilará un IAM hacia el destino utilizando la información recibida de la red de radio e información relacionada del abonado en el VLR. • Connect (CON) – La gsmSCF instruye a la gsmSSF a establecer la llamada al destino contenido en el CAP CON, que podrá contener asimismo otros parámtros reem plazando los parámetros correspondientes en el IAM. • Release call (RC) – La gsmSCF instruye a la gsmSSF a liberar la llamada, proveyendo un código de causa para retornar al abonado llamante. Si la gsmSCF usa CAP CUE o CAP Con, el procesamiento de la llamada en el MSC continúa. El MSC analiza el número llamado, posiblemente modificado por el SCP y envía el IAM ISUP para establecer la llamada. El servicio CAMEL podrá mantener el monitoreo de la llamada o terminar en este punto, dependiendo del armado de DP en el O-BCSM. Si la gsmSCF armó uno o más DP antes de enviar el CAP CUE o CAP CON, el servicio CAMEL permanecerá activo. Si no armó ningún DP, el servicio CAMEL term inará en ese punto.
130
En el ejemplo de “conexión de llamada”, el servicio CAMEL no arma ningún DP. El servicio CAMEL concluye luego que se envió CAP CON. En el ejemplo “monitorear hasta atender”, el servicio CAMEL arma el evento de contestación, por lo que permanece activo luego de enviar CAP CUE. Cuando se atiende la llamada, se reporta el evento y como no hay más DP armados se termina el servicio CAMEL. En el ejemplo “monitorear hasta desconectar”, el servicio CAMEL arma los dos DP en los eventos de contestación y desconexión. El evento desconexión puede ser armado en modo interrumpido. En ese caso, la gsmSSF reportará el evento y detendrá el procesamiento de la llamada por parte del MSC. La gsmSCF deberá enviar un CAP CUE o CAP RC luegode l reporte y luego finalizará el servicio CAMEL. La capacidad de control de CAMEL Fase 1 es limitada. Un servicio CAMEL fase 1 puede armar un evento de atención y de desconexión, pero no puede armar eventos de falla de establecimiento, lo que puede redundar en terminación del diálogo CAMEL prematura. Cuando se produce una falla en el establecimiento de la llamada, la gsmSSF abortará el diálogo CAMEL.
131
132
No todas las llamadas siguen las transiciones definidas en el BCSM. El SCP podrá en varios lugares del BCSM inducir una liberación de la llamada. Se refiere a estas transiciones de estados como “transiciones por fuera de la llamada básica” . En la figura se ven para el ejemplo de una O-BCSM. La transición (1) puede ocurrir cuando el servicio CAMEL determina que no se permite al abonado completar la llamada, por ejemplo debido a restricciones en llamadas salientes. La gsmSCF envía un CAP RC que provoca que el O-BCSM transiciones al estado O_Null. La transición (2) puede ocurrir cuando el servicio CAMEL aplica un control de duración de llamadas basado en el SCP. Cuando el servicio CAMEL determina durante la llamada que el abonado alcanzó su límite de crédito permisible, el SCP envía un CAP RC y el O-BCSM transita al estado O_Null. En este caso el O-BCSM no pasa a través del DP O_Disconnect. Una transición como (3) desde el estado PIC analysis, routing and alerting al O_Null no es muy común, debido a que implicaría que el servicio CAMEL de deniega la llamada luego de instruir al MSC a continuarla. Una transición entre DP O_Answer y O_Null no es posible, debido a que el DP O_Answer no puede ser armado como EDP-R. De esta manera, cuando el O-BSCM transita a DP O_Answer, reporta la ocurrencia del DP e inmediatamente transita al PIC O_Active.
133
Aquí se presentan tres ejemplos del servicio CAMEL fase 1 utilizado para VPN internacional. El servicio VPN traduce el número discado en un número público asociado con el destino, que pertenece al mismo grupo VPN que el abonado llamante. Para los abonados de un mismo grupo VPN, por ejemplo una empresa, uno podrá llamar a otro por GSM discando el número de extensión de la PABX. En el caso (1), el servicio CAMEL conecta al abonado llamante con un abonado VPN móvil. El abonado VPN móvil pertenece al mismo grupo VPN que el abonado llamante. La llamada se enruta por el GMSC del operador HPLMN, de donde se enruta hacia el VMSC que tiene en ese momento registrado al abonado destino. En el caso (2), el abonado llamante se conecta a una extensión de la PABX de la empresa. En el ejemplo (3), el abonado llamante está conectado a una VPN colega en la oficina de un país visitante. En los tres casos, la señalización ISUP podrá tomar el camino más corto entre el VMSC del abonado llamante y la PSTN/PLMN del abonado llamado. El servicio VPN podrá permitir que el abonado llamado reciba el número VPN del abonado llamado en su display en lugar del número público. Las llamadas onnet son entre abonados del mismo grupo VPN. Las llamadas off-net son entre usuarios de un grupo VPN a usuarios que no pertenecen al grupo o viceversa. Cuando el abonado llamante disca 3341, el servicio VPN determina que ese número pertenece a un abonado dentro del mismo grupo VPN, por lo que traduce el número discado al número público GSM del abonado destino. El servicio VPN también entrega el número interno del abonado llamante (3342) en el CAP CON. El abonado llamado recibe el número privado en lugar del público, por lo que si quisiera retornar la llamada a ese número, invocará el servicio VPN desde su origen, con el consiguiente reemplazo del número interno por el público. En caso que el abonado reciba una llamada de su VPN cuando está en una red que no soporta CAMEL, el servicio VPN del abonado llamante deberá remover el envío del número corto, y reemplazarlo por el número público. Caso contrario, cuando el abonado llamado intente retornar la llamada, tendrá un número carente de sentido en la red en que se encuentra sin soporte CAMEL.
134
Si bien CAMEL Fase 1 no incluye capacidades de tarifación online, se utiliza habitualmente para prepagos. Un servicio prepago CAMEL Fase 1 utiliza el principio de “route home”. En una llamada internacional prepaga, el servicio CAMEL disparado en la VPLMN se utiliza para forzar la ruta de la llamada al SSP de la HPLMN del abonado. El SSP es un MSC con SSF integrado, que se diferencia del gsmSSF en lo siguiente: • El SSF utiliza CS1 o CS1 modificado • El SSF no requiere un elemento de suscripción para lanzar el servicio. Este puede activarse también basado en el número o troncal. El servicio CAMEL Fase 1 lanzado en la VPLMN almacena la información recibida en el CAP IDP. Cuando el SSP en la HPLMN redispara IN para la llamada, la lógica de servicio del SCP usa la información almacenada del CAP IDP para manejar la llamada y conectarla al destino requerido. El número de destino en el CAP CON podrá tener el siguiente formato: Destination subscriber number = < SSP routing address >< SCP Id >< Correlation Id > La SSP routing address contiene dígitos usados para enrutar la llamada al SSP en el HPLMN. El servicio route home de CAMEL fase 1 se usa sólo cuando el abonado prepago está en otra PLMN diferente de su HPLMN. Por lo tanto, la SSP routing address debe contener el código de país, código de destino nacional y número de suscripción. El SCP Id indica el SCP donde se almacenan los datos de llamada del CAP IDP. Se necesita cuando los servicios prepagos están corriendo en más de un SCP. El Correlation Id se usa como un índice en el archivo con la información almacenada del CAP IDP debido a que el SCP podrá tener varias llamadas prepagas en establecimiento. Se utiliza sólo en el establecimiento de la llamada. Tan pronto el SCP realizó la correlación, se reutilizará el correlation Id para otras llamadas. El SSP copia el número completo del abonado destino del ISUP IAM al CS1 IDP para que el SCP pueda recuperar el correlation id.
135
Una vez que se produjo la correlación, el SCP podrá aplicar tarifación online utilizando las capacidades CS1. El servicio CAMEL no requiere permanecer activo luego de enviar el CAP CON. El abonado llamante no requiere conocer que se está usando route home en esta llamada. Sin embargo algunos dilemas asociados con el mecanismo incluyen: • Lanzamiento adicional de servicios y señalización CAP/CS1: el lanzamiento ocurre en dos nodos de la red núcleo, incrementando la carga y tráfico de señalización de la red. • Uso adicional de troncales ISUP. La llamada siempre se enruta a través del SSP de la red HPLMN del abonado suscripto, en lugar de directamente a destino. Si el abonado llamado está en otro país que el HPLMN del abonado llamante, el enrutamiento será suboptimo. El caso extremo es cuando el abonado llamado es un destino local. En este caso la conexión ISUP irá a la red Home y retornará al país origen. El operador debe decidir cómo tarifar a un abonado CAMEL 1 por las llamadas de roaming: • La tarifa debe reflejar el uso real de ISUP • La tarifa debe basarse en la distancia entre el abonado llamante y la red de destino, sin tomar en cuenta las idas y vueltas del ISUP • Se aplica una tarifa plana para llamadas internacionales
136
CAMEL Fase 2 es una extension de CAMEL Fase 1. Todas las funcionalidades disponibles en CAMEL Fase 1 están disponibles en CAMEL Fase 2. Las primeras características listadas están directamente relacionadas al control de la llamada, es decir a CAP. Estas características pueden verse como mejoras de CAP, y pueden utilizarse en la relación entre la gsmSCF y la MSC/gsmSSF. Para poder usarlas se requiere una versión diferente de CAP. En este caso corresponderá usar CAPv2. La distinción entre CAP v1 y CAP v2 se realiza en el contexto de aplicación (AC). CAP v2 engloba todas las capacidades de CAP v1. Pese a eso son protocolos diferentes. La gsmSSF podrá requerir el establecimiento de una relación CAMEL fase 1 o 2 y la gsmSCF deberá responder con el protocolo requerido únicamente. Por ejemplo si gsmSSF solicita un establecimiento CAMEL Fase 1, la gsmSCF no deberá responder con una relación CAMEL Fase 2 “utilizando la capacidad de CAMEL Fase 1 únicamente”, lo que sería un error.
137
Arquitectura de CAMEL Fase 2 El diagrama muestra únicamente las entidades y protocolos relevantes a CAMEL Entidades Funcionales
La fase 2 de CAMEL introduce un amplio rango de funcionalidades. Cada funcionalidad se relaciona con una entidad específica o múltiples entidades de la red GSM. A continuación se especifican las funcionalidades de la fase 2 de CAMEL para cada entidad de la red GSM. También se introducen nuevas entidades. Figure 4.1 depicts the network architecture for CAMEL phase 2. This network architecture reflects only the entities and protocols that are relevant for CAMEL. HLR: En CAMEL F2, el HLR podrá contener más datos de activación CAMEL.Entre ellos se incluyen: O-CSI, T-CSI, SSCSI, TIF-CSI y U-CSI. Además, se puede definir UG-CSI como un elemento de activación genérico. CAMEL F2 puede funcionar como un retransmisor de señalización USSD utilizando los contenidos de U-CSI o UG-CSI. Para el registro de números cortos de reenvío y desvío de llamadas puede usarse TIF-CSI internamente en el HLR. gsmSCF: La gsmSCF de CAMEL F2 podrá responder a un requerimiento de establecimiento de relación de un MSC/gsmSSF encima de una relación F1. Además la gsmSCF podrá establecer relaciones con el gsmSSF asistente y el Periférico Inteligente (IP) a efectos de realizar interacciones con el usuario en banda. También podrá establecer relaciones USSD directamente con el MS y actuar como punto terminal de los servicios USSD requeridos por el MS. Finalmente una gsmSCF de CAMEL F2 podrá recibir notificaciones de invocación de servicios suplementarios del MSC. MSC/gsmSSF: El MSC podrá enviar notificaciones de servicios suplementarios a la gsmSCF utilizando SS-CSI, y podrá establecer relaciones con el gsmSCF usando O-CSI. Si el MSC soporta derivación de llamada, usará TIF-CSI para los números cortos de derivación. GMSC/gsmSSF: El GMSC podrá establecer relaciones con la gsmSCF usando T-CSI. Si bien T-CSI podrá contener criterios de activación, éstos no se le envían al GMSC, sino que son verificados en el HLR. Por lo tanto, la activación condicional de llamadas MT no afecta al GMSC. Por otro lado, dado que el GMSC utiliza O-CSI para llamadas MF el criterio de activación en OCSI podrá ser usado en la GMSC CAMEL Fase 2. gsmSRF: Un MSC o GMSC podrán contener una función de recursos especializados gsm (gsmSRF) para proveer la capacidad de interactuar con el abonado. Cuando una gsmSCF tiene una relación de control CAMEL con el MSC o GMSC, podrá instruir a la gsmSSF que conecte la llamada a la gsmSRF y aplique interacción con el usuario, que podrá tener alguna de las siguientes formas:
•
Reproducción de anuncios pregrabados o tonos al usuario
•
Mensajes de anuncio de texto utilizando conversión de texto a habla
•
Recepción de información en banda (DTMF) del usuario
MSC/assisting gsmSSF: Mediante su relación de control con el MSC, la gsmSCF podrá instruir a la gsmSSF que establezca una conexión temporaria de habla (por ejemplo una conexión ISUP) con un MSC/assisting gsmSSF. Esta entidad funcional es un MSC con gsmSSF integrado que puede ofrecer capacidades de interacción con el usuario a otros MSC de la red o a un MSC externo a la red. La interacción se realiza en banda entre el abonado y el MSC/assisting gsmSSF. Esta entidad contiene un gsmSRF para interactuar con el usuario. Un MSC/assisting gsm SSF podrá ser a la vez un MSC/gsmSSF. Intelligent Peripheral: El Periférico Inteligente (IP) puede ofrecer la misma capacidad de interacción que un MSC/assisting gsmSSF. Una diferencia es que un IP es un nodo aislado, dedicado a realizar interacción con el usuario. Un IP puede establecer relaciones de control CAMEL con el gsmSCF. Puede verse al IP como un gsmSRF autónomo. Por esa razón, y para evitar la confusión con la sigla de Internet Protocol (IP), se lo llama a menudo Punto de recurso Especializado (SRP). Un IP puede actuar de forma autónoma sin control del gsmSCF. Este IP no requerirá soporte de CAP v2. Cuando se utiliza de esta manera, la gsmSCF no sabrá cuando se concluye un anuncio. La liberación del IP no se reporta al gsmSCF. Un ejemplo de uso es para los menús guiados de recarga de sistemas prepagos. Otro servicio es el de tono de ringback (RBT), que hace escuchar un tono o melodía personalizada al abonado llamante durante la fase de alerta.
138
Un MSC o GMSC podrán tener un gsmSRF interno o externo conectado. La gsmSCF podrá indicar a la gsmSSF a establecer una conexión entre el puente de conexión de la llamada y un gsmSRF interno o externo. Esta conexión sólo se permite cuando la gsmSSF indicó en el CAP IDP que la MSC donde reside (la gsmSSF) tiene capacidades de interacción con el usuario. La conexión con la gsmSRF se realiza con un CAP CTR.
139
Hay casos en que un servicio CAMEL no puede usar la gsmSRF interna o asociada para la interacción de usuario con el abonado servido. Estos casos incluyen: • El servicio CAMEL está controlando una llamada a través de un diálogo CAP con un MSC de un país visitado. La gsmSRF del MSC foráneo no tiene los anuncios requeridos para este servicio CAMEL • El MSC no tiene un gsmSRF integrado o asociado. Por ejemplo, un operador puede equipar una cantidad limitada de MSC con gsmSRF en la red • El MSC tiene gsmSRF integrado, pero éste no tiene la capacidad requerida para ese servicio CAMEL específico. Por ejemplo sólo algunos gsmSRF en la red del operador tienen implementada la capacidad de “generación de anuncios de voz desde texto” . En estos casos, el servicio CAMEL deberá establecer una conexión temporaria de tráfico ISUP entre el MSC que está ejecutando el servicio CAMEL y el MSC con la función assisting gsmSSF.
El periférico Inteligente (IP) El IP es conceptualmente igual a un MSC con una función integrada assisting gsmSSF (assisting MSC). Las diferencias funcionales son las siguientes: • El assisting MSC tiene una función gsmSRF integrada o asociada. Cuando se establece una conexión temporaria con el aMSC, la gsmSCF instruye a la agsmSSF a realizar la conexión ISUP al gsmSRF interno o asociado. La gsmSCF podrá desconectar la gsmSRF y conectar la ISUP a otro gsmSRF interno o asociado • El IP es un gsmSRF autónimo. Cuando se establece una conexión temporaria con un IP, se establece una conexión implícita con la funcionalidad de recursos del IP. Por lo tanto, la gsmSCF no requiere enviar un CAP CTR antes de enviar un CAP PA o CAP PC. • El IP usa un CAP AC diferente respecto del agsmSSF. CAP CTR y CAP DFC no se requieren y por lo tanto no se incluyen dentro del protocolo CAP del IP. El CAP AC del IP no soporta la operación reset timer, por lo que el valor Tssf se debe configurar para permitir anuncios • pregrabados de la duración máxima. De esta manera se evita la expiración del ti mer Tssf. Aparte de estas diferencias, los diagramas de interacción con el IP son los mismos que los usados con el MSC con assisted gsmSRF. Un IP puede utilizarse en casos especiales de interacción con el usuario como ser reconocimiento del habla, conversión de texto a habla pueden soportarse en un IP dedicado, pero podrían no soportarse en un MSC o assisted MSC.
140
BCSM para llamadas originantes
La principal adición a los BCSM de CAMEL Fase 2 son los puntos de detección de fallas, que permiten hacer un análisis más detallado y tomar acciones consecuentes dependiendo del tipo de falla, incluyendo incluyendo la emisión de mensajes ISUP informando las causas de las fallas de establecimiento. establecimiento.
141
142
BCSM para llamadas terminantes
143
144
145
Control de tarifación en línea
El control de tarifación en línea permite que el gsmSCF monitoree y controle la duración de la llamada. “En Línea” se refiere en este contexto a que el control de la llamada se realiza mientras la llamada ocurre. Es una diferencia clara con el control “fuera de línea” como se ve en la comparación: c omparación: • Tarifación en línea: El servicio CAMEL determina la tarifa durante el establecimiento de la llamada. Se permitirá establecer la llamada sólo cuando el abonado tenga suficiente crédito en su cuenta para esa llamada. Si se permite la llamada, el s ervicio CAMEL la monitoreará m onitoreará y deducirá crédito de la cuenta del abonado a medida que la llamada continúa. Si el crédito baja cierto umbral durante la llamada, el servicio CAMEL podrá terminar la llamada. • Tarifación fuera de línea: La tarifa se determina una vez completada la llamada, procesando el Registro de Detalles de llamada (CDR), que contiene origen, destino, duración y demás datos relevantes de la llamada. Un error común de interpretación es asociar la tarifación en línea con abonados prepagos y la tarifación fuera de línea con clientes postpagos. Sin embargo, la t arifación en línea se puede usar en ambos am bos tipos de clientes: • Clientes prepagos: Un cliente prepago debe obtener crédito de llamadas antes de generar llamadas salientes o bien recibir llamadas en roaming. El sistema de tarifación online monitorea las llamadas de este abonado y reduce el crédito remanente de acuerdo con la tarifa de la llamada y su duración. Cuando se llega a un límite mínimo de crédito, la llamada se termina. El cliente deberá recargar su cuenta antes de iniciar nuevas llamadas. • Clientes Postpagos: Un cliente postpago paga por las llamadas entrantes y salientes luego de realizarlas, por lo que constituirá una deuda. En intervalos regulares (mensualmente) debe cancelar su deuda con el operador. Cuando se hace monitoreo en línea de las llamadas de este cliente, se pueden incorporar características como: • Control de gastos: El abonado podrá llamar hasta un monto máximo por mes • Control de crédito: El operador desea tener un control preciso sobre el crédito disponible de sus clientes. Monitoreo de llamadas: Dentro de una compañía podría requerirse el monitoreo del uso del teléfono en • tiempo real.
146
El mecanismo principal del control de duración de llamadas de CAMEL está implementado en la gsmSSF. Cuando se establece una llamada y la gsmSCF tomó el control, podrá requerir de la gsmSSF que monitoree la duración de la llamada y le envíe reportes de duración luego de períodos predefinidos de tiempo. El monitoreo de la llamada comienza en la gsmSSF tan pronto como la llamada pasa al estado activo, es decir el abonado remoto la contesta. La llamada se divide en períodos de llamada. Luego de cada período de llamada, la gsmSSF envía un reporte a la gsmSCF infomando la duración transcurrida de la llamada. La gsmSCF podrá enviar un nuevo pedido de reporte. La secuencia de (1) pedido de reporte de duración y (2) generación del reporte de tarifación, continúa hasta que los abonados concluyen la llamada o bien se alcanzó un nivel mínimo de crédito, donde la gsmSSF o la gsmSCF terminarán la llamada. Las operaciones CAP utilizadas para este mecaismo son: • Apply charging (ACH): Es la instrucción de la gsmSCF a la gsmSSF para comenzar o continuar el monitoreo de duración de la llamada. • Apply Charging Report: Es el reporte enviado de la gsmSSF a la gsmSCF al finalizar un período de llamada o cuando se libera la llamada. Durante una llamada en curso sujeta al control de duración, las gsmSSF y gsmSCF intercambian operaciones de tarifación. La gsmSCF envía un CAP ACH habilitando una duración definida de llamada, y la gsmSSF responde con un CAP ACR cuando finalizó el tiempo asignado. Mientras que el ACH contiene la duración permitida para el siguiente período de llamada, los ACR contienen la duración acumulada de la llamada.
147
Cuando bien al inicio o durante una llamada la gsmSCF determina que la llamada puede continuar por sólo por un tiempo parcial , instruye a la gsmSSF a liberar la llamada luego de la expiración del período. Este mecanismo se conoce como “liberación forzada”. Las razones pueden incluir entre otras: • El abonado es prepago y alcanzó un límite mínimo de crédito • El abonado es pospago y alcanzó un límite máximo de deuda
148
La interacción con el usuario (UI) es el método en que un servicio IN interactúa con el abonado llamante durante el procesamiento de la lógica de servicio. UI puede aplicarse durante el establecimiento de llamada para por ejemplo informar al abonado la tarifa de la llamada. Cuando se aplica derivación de llamada, el servicio IN podrá ejecutar un anuncio indicando al llamante acerca de la derivación. La UI no se aplica a una pata individual de la llamada, sino al puente de la conexión, como se ve en la figura, el que se conectará a una gsmSRF o un IP (SRP). En el caso (a) la conexión a la gsmSRF en el MSC-A se realiza antes de enviar el ISUP IAM. El abonado llamante aún no recibió el mensaje de contestación y por lo tanto no será tarifado por la duración del anuncio. En el caso (b), la conexión con la gsmSRF en el GMSC se realiza luego de recibir un ISUP REL del abonado llamado. Si ya se le envió un ISUP ANM al abonado llamante (por ejemplo llamada de seguimiento luego de contestar), se tarifará al abonado llamante por la duración del anuncio. Para ejecutar un anuncio a un abonado llamante, se debe establecer una conexión de tráfico entre el abonado llamante y un gsmSRF. Esta conexión de tráfico podrá ser interna del MSC o externa a través de un canal ISUP/TDM. En CAMEL Fase 2, la UI se puede aplicar durante el establecimiento de una llamada o en su liberación. No se puede aplicar durante una llamada activa. La idea es que la UI es en esencia una conexión de tráfico, es decir un canal ISUP/TDM entre el abonado llamante y el dispositivo de UI. El modelo de estado del gsmSSF no tiene la capacidad de monitorear la conexión de UI y la llamada saliente al mismo tiempo. Existen dos formas de interacción de usuario: (1) Ejecución de anuncios y (2) colecta de información del usuario.
149
150
151
152
153
154
155
La fase 3 de CAMEL se introdujo en la R99 del 3GPP para la red móvil de tercera generación. Esta red es la evolución de la red GSM de 2da. Generación. La arquitectura núcleo de la red 3GPP 3G es similar a la de una red GSM, por lo que se puede utilizar CAMEL Fase 1 y Fase 2 en una red 3G pese a que fueron desarrollados para la red GSM. Las tecnologías 3GPP 3G incluyen además de la conmutación de circuitos presente en redes 2G la conmutación de paquetes, lo que permite optimizar el procesamiento de datos de paquetes dentro de la red. Conceptualmente se dividen en susbsistemas como se ve en la figura tanto en lo referente a subsistemas de transporte como de generación de servicios y señalización.
156
157
158
Al comparar UMTS con GSM, se ve una cantidad de diferencias de arquitectura. Sin embargo, el esquema de migración permite realizarla por fases, de manera que el operador no requiere aplicar todos los aspectos específicos de la red 3G. Una red 3G puede contener funcionalidades 2G y 3G mezcladas. En las figuras anteriores se presenta la arquitectura UMTS para servicios conmutados por circuitos (CS) y por paquetes (PS). Tanto el MSC como el SGSN de la red 3G pueden controlar las infraestructuras de acceso de radio 2G (RAN) y 3G (UTRAN) al mismo tiempo. Las entidades de la arquitectura 2G y 3G se agrupan en partes lógicas. La red núcleo puede ser una combinación de nodos CS (MSC, GMSC) y nodos PS (SGSN, GGSN). CAMEL tiene capacidad de control para cada una de las combinaciones posibles: • Llamada CS o SMS a través de 2G RAN • Llamada CS o SMS a través de 3G UTRAN • Conexión GPRS o SMS a través de 2G RAN • Conexión GPRS o SMS a través de 3G UTRAN
159
160
161
La información de locación que reporta una RAN 3G al MSC difiere ligeramente de la información de una RAN 2G. Por lo tanto, el SCP recibe diferente información de locación al controlar una red 3G que en el caso de una red 2G. Diferencias significativas: Service Area Code: Identifica el área de servicio donde se registró el cliente al momento del contacto más reciente entre el UE y el MSC. El área de servicio es reportada en una RAN 3G únicamente. Los MCC, MNC, LAC y CI o SAC se reportan en un único elemento de información. Un MSC podrá reportar un LAI consistente del MCC, MNC y LAC, o bien un CGI o SAI. El CGI combina el MCC, MNC, LAC y CI, y el SAI combina el MCC, MNC, LAC y SAC. Debido a que el CGI y el SAI tienen la misma codificación, el receptor de la información de locación puede no tener elementos para deducirsi el abonado atendido está registrado en una red 2G (CGI reportado) o bien 3G (SAI Reportado). Para evitarlo, puede aplicarse alguno de los siguientes métodos: (1): El operador se asegura que no tiene superposición entre los códigos CI y los códigos SAC, por lo que el CI/SAC reportado identificará el tipo de red. (2) El MSC que reporta la información de locación incluye un parámetro “SAI Present ”. La presencia de este parámetro indica que el abonado se registró en una red 3G. Routing Area Code: El RAC se utiliza para identificar una locación en la red de acceso 2G o 3G para conectividad PS. Forma parte del RAI.
162
163
164
165
Información de suscripción CAMEL (CSI)
CSI de CAMEL Fase 3: •
CSI de Fase 1 MAS Fase 2 MAS:
•
Dialled Services CAMEL Sub scr iptio n Info rm ation (D-CSI):
•
•
•
•
•
Se transfiere al VPLMN (durante la actualización de locación) y al IPLMN (para una llamada entrante en el GMSC): D-CSI contiene información de activación requerida para invocar la lógica de servicio CAMEL para SDS. Se transfiere al VPLMN: Contiene GPRS CAMEL Sub scri ptio n Info rm ation (GPRS-CSI): información de activación para invocar la lógica de servicio CAMEL para sesiones GPRS y contextos PDP. Mobility Management CAMEL Subscrip tion Information (M -CSI): Se transfiere al VPLMN. Se utiliza para notificar al Ambiente de Servicio CAMEL (CSE) acerca de eventos de administración de movilidad. Network CAMEL Subsc ription Information (N-CSI): Se transfiere al VPLMN: Identifica los servicios ofrecidos en función de la red por el operador PLMN para todos los abonados. Debe almacenarse en el MSC. Short Message Service CAMEL Subscrip tion Information (SMS-CSI): Se transfiere al VPLMN. Contiene información de disparo requerida para invocar la lógica de servicio CAMEL para envío de SMS MO. VMSC Termin ating CAMEL Subscrip tion Information (VT-CSI): Se transfiere al VPLMN durante la actualización de localción. Requerida para invocar el servicio CAMEL para llamadas MT en el VMSC.
Información contenida en cada CSI: • • • • • • • •
Trigger Detection Point (DP2, DP12 etc gsmSCF address (Global Title of the SCP) Service Key (identifies the service logic in the SCP) Default Call/SMS /GPRS Handling (Continue or Release, if CAP dialogue fails ) Capability Handling (CAP protocol version, not for MAP CS Is ) Trigger criteria (e.g. dialled number, basic service, reason code etc) CSI state (active/inactive). CSE Notification on CSI change.
166
Servicios discados suscriptos (SDS) Es un método en CAMEL Fase3 para disparar servicios IN
adicionales durante el establecimiento de una llamada MO o MF. Se pueden invocar los siguientes servicios durante el establecimiento de la llamada: Servicio suscripto en DP collected info y servicio discado suscripto en DP analysed info. Este método utiliza una mejora del O-BCSM, donde se agrega el DP analysed info. La invocación del servicio discado suscripto se poroduce en presencia del elemento D-CSI, que al igual que O-CSI está en el HLR y podrá ser enviado al VLR en la registración y al GMSC durante el procesamiento de la llamada terminante. Cuando se está estableciendo una llamada, el flujo sigue el O-BCSM. En primer lugar, se podrá invocar un servicio CAMEL en DP_collected_info, de igual manera que en CAMEL Fase 1 & 2, el que dependerá de la existencia de un O-CSI y de cumplir el criterio de activación. Una vez que se completó el procesamiento del DP_Collected_info el BCSM transita al estado DP_analysed_info . Si el abonado tiene un D-CSI, el gsmSSF podrá invocar un servicio suscrito discado. La invocación del servicio discado se basa en el número discado para esta llamada. Como resultado, la activación del servicio discado suscrito podrá estar influenciada por el O-CSI. La gsmSSF compara el número discado con un conjunto de números almacenados en el D-CSI. Si se encuentra una coincidencia, se invocará el servicio indicado en D-CSI.
167
168
169
170
171
Una de las extensiones importantes de la fase 3 de CAMEL respecto a las fases 1 y 2 es el soporte de GPRS. La fase 3 de CAMEL permite que un SCF de la red home del abonado controle la administración de movilidad GPRS y la activación de contextos PDP. Como en GSM, los servicios CAMEL para GPRS son activados por un SSF asociado con el SGSN al que se encuentra vinculado el abonado. Los modelos BCSM existentes no pueden aplicarse directamente a GPRSE, debido a que el procedimiento para establecer una comunicación de paquetes es diferente a realizar una llamada GSM. Por lo tanto CAMEL Fase 3 introduce dos nuevos modelos de estado para GPRS: 1. Attach-Detach state: Este modelo sigue los procedimientos de administración de movilidad de GPRS y permite al SCF intervenir en ellos. 2. PDP Context State: Este modelo representa el proceso de establecer contextos PDP para la comunicación de datos. Es comparable a los modelos O-BCSM y T-BCSM de CAMEL. El modelo Attach-Detach solo distingue dos estados de conexión y cuatro DP: attach, detach, location update y exception. El punto de detección location-update es bastante especial debido a sus dos casos distintivos: • Intra-SGSN location_update: El termina permanece attached y el DP puede ser únicamente del tipo EDP-N. Esto significa que la SSF sólo podrá enviar una notificación del evento a la SCF, pero no se puede suspender la administración de la movilidad. • Inter-SGSN location_update: El terminal se despega del SGSN viejo y se vincula al nuevo, y se envía notificación del cambio al HLR. En este caso el DP puede ser TDP-R y la administración de la movilidad puede efectivamente suspenderse y controlarse por la lógica del servicio IN en el SCF.
172
Antes que un abonado pueda pueda enviar o recibir datos, el GGSN GGSN debe configurar configurar un cntexto PDP. Como se explicó en la sección de GPRS, el contexto PDP mantiene al relación entre la identidad del abonado (IMSI), la dirección IP, la QoS requerida y el SGSN. Un abonado puede tener varios contextos PDP activos al mismo tiempo, si es que utiliza diferentes direcciones IP simultáneamente. El modelo de estados CAME para configurar contextos PDP se ve en la figura. Se iniciará uno de estos modelos para cada contexto PDP activado. Sus estados y puntos de detección son simples: Un pedido de envío o recepción de datos causa la transición del estado de reposo ( idle) hacia el estado PDP_Setup , pasando por el DP context_establishment . Cuando la GGSN configuró el contexto PDP, notifica al SGSN que la transmisión de datos puede comenzar. Esto causa la transición via el DP context_acknowledgment al estado PDP_context_established. Es posible que mientras el abonado está enviando o recibiendo datos se mueva de un área de enrutamiento a otra. Esto causará un handover y se pasarán los DP routing_area_update y change_of_position_context . El contexto PDP puede desactivarse tanto a pedido del abonado como de la red, causando una transición al estado idle a través del DP disconnect_detection. Un punto importante a notar es que el estado idle de este modelo no es el mismo que el definido por GPRS. En GPRS idle significa desvinculado de la red (detached). En CAMEL, significa que no existe un contexto PDP activo (en otras palabras, no se está enviando ni recibiendo datos). La configuración de puntos de activación para GPRS funciona de la misma manera que en GSM. Si una suscripción GPRS involucra el procesamiento de un servicio CAMEL, el HLR enviará la información de suscripción GPRS CAMEL (GPRS-CSI) al SGSB, conteniendo la dirección del SCF que administra el servicio, la identificación del servicio a invocar (service key), la lista de los DP a armar, y una indicación del manejo por defecto en caso de excepciones. excepciones.
173
PDP Context activation with CAMEL control. (1) The subscriber establishes the PDP context. An APN and other information inf ormation elements may be included in the request. The gprsSSF sends CAP IDP-GPRS to the gsmSCF. gsmSCF. (2) The gsmSCF sends CAP CUE-GPRS to the gprsSSF. gprsSSF. PDP context establishment continues, which includes the execution of procedure APN and GGSN selection. selection . (3) The SGSN has derived the APN (if not yet available) and the address of the GGSN. A PDP context activation request is sent to the GGSN. (4) The GGSN validates the PDP context activation request and returns an acknowledgement to the SGSN. The acknowledgement includes the selected APN, negotiated quality of service, charging Id and end user address. (5) The gprsSSF reports the PDP context activation to the gsmSCF, gsmSCF, by sending CAP event report GPRS with event PDP context establishment acknowledgement. acknowledgement. (6) The gsmSCF confirms conf irms the activation notification to the gprsSSF, gprsSSF, by sending CAP CUEGPRS. The PDP context is now active and data da ta transfer between UE and addressed application may take place.
174
SMS puede utilizarse tanto en el dominio PS como en el CS: • Dominio CS: El SMS puede enviarse al MSC donde el abonado está registrado. Este método se conoce com “MSC-based-SMS” • Dominio PS: El SMS puede enviarse a través del SGSN al que está adosado el abonado. Conocido como “SGSN-based-SMS” Un abonado podrá, dependiendo de sus datos de suscripción, enviar SMS via MSC, SGSN o ambos. Cuando un abonado envía un SMS, se transfiere del US al MSC o SGSN. Si el abonado está suscripto a TS22, el MSC utiliza señalización MA para transferir el SMS al SMSC. Una vez que el SMS arribó al SMSC, y es aceptado por éste, se considera exitoso el envío. La entrega del SMS al destino no es parte de la funcionalidad MO SMS. Cuando el SMS llegó al SMSC, se tarifa por el mensaje al abonado. El SMS-IWMSC tiene la función de interfaz entre el dominio GSM/3GPP y el dominio IT. El MSC y SGSN están en el dominio GSM/3GPP, mientras mientras que el SMSC está en el dominio IT. Control CAMEL de MO-SMS El control CAMEL de los MO-SMS implica que se debe establecer una relación CAMEL entre el MSC y el gsmSCF o entre el SGSN y el gsmSCF. El contol CAMEL de MO-SMS es un servicio suscripto, lo que implica que debe existir datos de suscripción en el HLR: MO-SMS-CSI, que se envía del HLR al MSC durante el registro en el MSC o bien al SGSN al momento del attach del UE.
175
176
Cuando el abonado se registra en el MSC y tiene datos de suscripción apropiados, podrá enviar SMS. Si el MSC tiene un MO-SMS-CSI, el envío de SMS del abonado llevará a la activación incondicional del servicio CAMEl. El servicio CAMEL se identifica por el contenido del MO-SMS-CSI. El flujo CAP entre el smsSSF y el gsmSCF contiene información obtenida del encabezado SMS, el contenido del mensaje no se envía al gsmSCF. Este instruye al smsSSF a continuar la emisión del SMS, luego de lo cual el MSC enviará el mensaje MAP MO-ForwardSM al SMS-IWSC. El control CAMEL de los MO-SMS se refiere a la transferencia de datos desde el MS al SMSC. El TPDU SMS-Submit y el TPDU SMS-Command pueden disparar el servicio CAMEL. El TPDU SMS-ServiceDeliver-Report no constituye una transferencia de datos o mensaje, pero se usa para reportar el éxito o no de la transmisión de una TPDU anterior. Por lo tanto no dispara un servicio CAMEL.
177
La administración de la movilidad es un mecanismo que permite al operador hacer seguimiento de la ubicación y el estado de attach/detach del abonado. La locación del abonado se conoce en el HLR hasta el nivel de la dirección del VLR. El HLR requiere la dirección VLR para enrutar las llamadas entrantes al abonado, entregar SMS, etc. Sin embargo, el HLR no tiene un registro de la locación del abonado dentro del área de servicio del VLR y tampoco del estado de attach/detach. Por lo tanto, el HLR no mantiene información suficientemente precisa respecto de la locación o estado del abonado necesaria para determinados servicios de valor agregado. La fase 3 de CAMEL ofrece una solución a este dilema en la forma de administración de la movilidad. La administración de movilidad en CAMEL Fase 3 se refiere a movilidad CS únicamente. La movilidad PS se introduce en CAMEL Fase 4.
178
Cuando un abonado no está en una llamada, puede moverse de una locación a otra y realizar una actualización de locación, que será notificada a varios nodos, dependiendo del tipo de actualización, según se ve en la tabla. La columna derecha de la tabla indica si la administración de movilidad puede resultar en una notificación de CAMEL 3 al gsmSCF. Las notificaciones de administración de movilidad que pueden enviarse al gsmSCF no se relacionan con el manejo e llamadas. Cuando un abonado se mueve de un área a otra durante una llamada, no se produce una actualización de locación GSM. En ese caso el proceso se conoce como handover. Las notificaciones de handover se introducen en la fase 4 de CAMEL. Cuando se produce handover, la actualización de locación correspondiente, incluyendo la actualización de la información de locación almacenada en el VLR se produce luego de completar la llamada. La notificación de administración de movilidad al gsmSCF usa MAP y se envía luego de completar el procedimiento de administración relacionado. La gsmSCF podrá reenviar las notificaciones a una base de datos.
179
La administración de la movilidad en CAMEL puede usarse para servicios como el Número Personal ( PN) o el Número único (Single Number Reach – SNR). Un abonado puede ser ubicable en una variedad de dispositivos, en un mismo número. Los servicios PN o SNR llevan un registro del estado y locación del abonado. Cuando llega una llamada, el servicio utiliza la información para determinar a qué dispositivo se le debe ofrecer la llamada. En el ejemplo de la figura el servicio PN puede no requerir la recepción continua de notificaciones de movilidad. Sólo las requeriría cuando se activa una característica específica PN. El servicio PN podrá entonces usar la interfaz MAP al HLR para activar o desactivar la suscripción del servicio de administración de la movilidad para un abonado, es decir, activar o desactivar el M-CSI. Un requerimiento para activar el M-CSI en el HLR es que se encuentre previamente provisionado para ese abonado, siempre que el VLR en donde el abonado está registrado en ese momento soporte CAMEL fase 3. El servicio PN puede usar la misma interfaz MAP con el HLR para verificar las fases CAMEL soportadas por el VLR para verificar que realmente se le envió el M-CSI. La desactivación del M-CSI significa que el HLR removerá el M-CSI del VLR.
180
181
182
183
184
185
186
187
•
• IP Multimedia Service Switching Function (IM-SSF)
functional entity that is a SIP Application Server interfaces SIP to CAP. • IP Multimedia CAMEL Subscription Information (IM-CSI) • identifies the subscriber as having IP Multimedia CAMEL services. • Service Platform Trigger Points (STP) • the points in the SIP signalling that instruct the SIP AS, OSA SCS and IM-SSF to trigger the service logic. • For the IM-SSF the IP Multimedia Camel Subscriber Information (IM-CSI) defines them. • Initial Filter Criteria (iFC) • filter criteria that are stored in the HSS as part of the user profile and are downloaded to the S-CSCF upon user registration. • They represent a provisioned subscription of a user to an application. •
• •
•
188
189
Como ya se describión, cada fase de CAMEL soporta determinados casos de llamadas. La fase 4 introduce 2 nuevos casos. Cada uno tiene sus mecanismos de disparo y capacidades específicas.
190
En la fase 4 de CAMEL se mejoran aún más los modelos BCSM comparado con Fase 3. Se agregan los DP DP_Term_Seized, O_Mid_Call y O_Change_of_Position en el O-BCSM y Call_Accepted, T_Mid_Call y T_Change_of_Position en el T-BCSM. Estos puntos tienen relación con las nuevas capacidades adicionales de alerta, interacción con el usuario durante la llamada y de movilidad en medio de la llamada, que se agregan en CAMEL Fase 4. Las reglas respecto al armado, desarmado y reporte de DP son las mismas que para las fases anteriores.
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
A user comes into a foreign network and presents his identity using the locally supported AAA mechanisms. Based on the identity of the user, the network can decide on the home provider of the user and contact him through the AAA infrastructure. In case the home provider is using a different AAA protocols than the foreign provider then a gateway needs to be provided to translate between the two protocols. As depicted in the figure, a user wishing to access the services offered by the foreign network indicates its wish to use the service and gives the provider its network address identifier (NAI). This identity if forwarded from the access to the AAA server . • If the NAI contains an IMSI, then the access request is forwarded to a gateway that translates the AAA request into the equivalent 3G AAA protocol request. This gateway might be pre-configured or might be dynamically searched for through some brokerage service. • The access request might then be further forwarded over SS7 signalling to another 3G network (home network of the user). • Replies to the request are forwarded back to the user over the gateway . • In case the NAI does not include an IMSI then the AAA server tries to contact the home network of the user as identified by the NAI over the AAA infrastructure, i.e., either directly if a trust relation is available between the foreign and home network or through an AAA broker
230
Roaming Model We assume here that the end user has already gained access to the Internet t hrough the AAA infrastructure and wishes to move to another network. Depending on the user‟s home domain, two cases arise: the user may have a contract with a 3G operator or may have an agreement with an Internet Service provider (ISP). 3G User Scenario In this scenario, a 3G subscriber enters a WLAN network. To authenticate and authorize the user, the HLR of the 3G home provider needs to be contacted. This scenario is as follows, see Figure (left) : The user starts its mobile device and contacts the Access Point (AP) using the standard 802.1x • The AP contacts the AAA server • The AAA server checks the home provider of the user and contacts the AAA server of that provider. As the • home provider is a 3G provider, so it provides only a HLR/AAA gateway • The AAA/HLR gateway contacts the HLR to authenticate the user • The authentication data go all the way back to the Access Point AP • In case of successful AAA procedure the user gets IP access and is assigned a dynamic hom e agent (DHA) • In case the user wants to use SIP based services, he needs to authenticate with the local SIP proxy which in turn contacts the AAA server, which contacts the AAA server of the home provider in the sam e way as the IP access authentication. (Note that the SIP home provider and the network home provider might be different, Figure (left) assumes them to be the same) In the next step, see Figure (right), the user roams to a 3G network. Here, again, the user needs to authenticate himself (we assume no direct relation between the previous wireless provider and this 3G provider). • The user contacts the AAA server, i.e. the VLR of the 3G network using the local authentication technology (AKA UMTS) The VLR contacts the HLR • The user needs also to inform the DHR about its new position (IP address) so that all started flows would keep • on running without interruption. New flows should be started with the new address so that when all the flows initiated with through the DHR are • terminated the binding at the DHR can be deleted.
231
ISP User Scenario An ISP user describes a user that has an ISP as his home provider (the ISP could be a network provider, an application provider such as yahoo or a banking entity such as VISA, the only thing that matters here is that this entity has a AAA server). In Figure (left), the user starts his mobile device in a wireless LAN • The user contacts the Access router using the local authentication technology (802.1x) • The Access Point contacts the AAA server • The AAA server checks the home provider of the user and contacts the AAA server of that provider • The home AAA server sends the authentication data go all the way back to the AP • In case of successful AAA procedure the user gets IP access and is assigned a dynamic home agent • In case the user wants to use SIP based services, he needs to authenticate with the local SIP proxy which in its turn contacts the AAA server, which contacts the AAA server of the home provider in the same way as the IP access authentication. (note that the SIP home provider and the IP home provider might be different, Figure (left) assumes them to be the same). In Figure (right) the user has roamed into a 3G network • The user contacts the AAA server, i.e., VLR, of the 3G network using the local authentication technology (AKA UMTS) • The VLR contacts the HLR of the home provider (here it is a HLR/AAA gateway), which contacts the AAA server of the ISP. • The user needs also to inform the DHR about its new position (IP address) so that all started flows would keep on running without interruption. New flows should be started with the new address so that when all the flows initiated with, through the DHR are terminated, the binding at the DHR can be deleted.
232
Apéndice: Mensajes CAP
233
Abreviaturas
234
235
236
237
238
