El servicio de mensajes cortos se realiza mediante el uso de la parte de aplicación móvil (MAP) del protocolo SS7 , y los elementos del protocolo de mensajes cortos se transportan a través de la red como campos dentro de los mensajes MAP. [1] Estos mensajes MAP pueden transportarse utilizando señalización basada en TDM "tradicional" , o sobre IP utilizando SIGTRAN y una capa de adaptación adecuada.
Protocolo
El protocolo de mensajes cortos en sí está definido por 3GPP TS 23.040 para el servicio de mensajes cortos - punto a punto (SMS-PP) , [2] y 3GPP TS 23.041 para el servicio de difusión celular (CBS) . [3]
Se definen cuatro procedimientos MAP para el control del servicio de mensajes cortos: [1]
- Transferencia de servicio de mensajes cortos originados en móviles (MO);
- Transferencia de servicio de mensajes cortos con terminación móvil (MT);
- Procedimiento de alerta de mensajes cortos;
- Procedimiento de conjunto de datos de mensajes cortos en espera.
Transferencia del servicio de mensajes cortos de MO
El diagrama de la derecha muestra un flujo de llamadas simplificado para un envío exitoso de un mensaje corto (SM) originado en un dispositivo móvil. [1]
Cuando el suscriptor envía un mensaje corto, el teléfono envía el mensaje de texto a través de la interfaz aérea al centro de conmutación móvil (MSC) / nodo de soporte de servicio GPRS (SGSN) . Junto con el texto real del mensaje corto, se incluyen la dirección de destino del SM y la dirección del centro de servicio de mensajes cortos (SMSC) , esta última tomada de la configuración del teléfono almacenada en la tarjeta SIM. [4]
Independientemente de la tecnología de interfaz aérea, el VMSC / SGSN invoca el paquete de servicio MAP MAP_MO_FORWARD_SHORT_MESSAGE para enviar el texto al MSC de interfuncionamiento del centro de servicio cuya dirección fue proporcionada por el teléfono. Este servicio envía la operación MAP mo-ForwardSM [Nota 1] al SMSC identificado en el envío SM desde el teléfono, integrado en un mensaje de la parte de aplicación de capacidades de transacción (TCAP) y transportado a través de la red central utilizando la parte de control de conexión de señalización ( SCCP). [1]
El MSC de interfuncionamiento del SMSC, al recibir el mensaje MAP mo-ForwardSM, pasa la Unidad de datos de protocolo de aplicación (APDU) SMS-PP [2] que contiene el mensaje de texto al Centro de servicio (SC) real del SMSC para su almacenamiento, y posterior "reenvío" (entrega) a la dirección de destino y el SC devuelve un acuse de recibo que indica éxito o fracaso. Al recibir este estado de envío del Centro de servicios, el MSC de interfuncionamiento enviará una indicación apropiada al VMSC / SGSN del abonado remitente. El estado de envío del mensaje se reenvía a través de la interfaz aérea al teléfono del suscriptor. [4] [Nota 2]
Transferencia del servicio de mensajes cortos MT
La figura de la derecha muestra un flujo de llamadas para la entrega de mensajes cortos con terminación móvil. [1] En aras de la simplicidad, se han omitido algunas de las interacciones entre VMSC y VLR, y VMSC y Handset, y solo se muestra el caso en el que el enrutamiento doméstico SMS no está en uso.
Cuando el SMSC determina que necesita intentar enviar un mensaje corto a su destino, enviará la APDU SMS-PP que contiene el mensaje de texto, el "B-Party" (número de teléfono de destino) y otros detalles al Gateway MSC (GMSC ) componente lógico en el SMSC. [2] El GMSC, al recibir este Mensaje Corto, necesita descubrir la ubicación del B-Party para poder entregar correctamente el texto al destinatario (el término Gateway MSC, en este contexto, indica un MSC que está obteniendo información de enrutamiento del Registro de ubicación de origen (HLR) ). Para hacer esto, el GMSC invoca el paquete de servicio MAP MAP_SEND_ROUTING_INFO_FOR_SM, que envía un mensaje MAP sendRoutingInfoForSM (SRI-for-SM) al HLR del número de destino, solicitando su ubicación actual. Este mensaje SRI-for-SM puede enviarse a un HLR en la misma red que el SMSC, o mediante una interconexión a un HLR en una PLMN extranjera , dependiendo de la red a la que pertenezca el suscriptor de destino.
El HLR realiza una búsqueda en la base de datos para recuperar la ubicación actual de la B-Party y la devuelve en un mensaje de reconocimiento a la entidad GMSC del SMSC. La ubicación actual puede ser la dirección de MSC en la que el abonado se encuentra actualmente en itinerancia, la dirección de SGSN o ambas. El HLR también puede devolver un error si considera que el destino no está disponible para mensajes cortos; consulte la sección Entrega de mensajes cortos fallidos a continuación.
Habiendo obtenido la información de enrutamiento del HLR, el GMSC intentará entregar el Mensaje Corto a su destinatario. Esto se hace invocando el servicio MAP_MT_FORWARD_SHORT_MESSAGE, que envía un mensaje MAP mt-ForwardSM [Nota 3] a la dirección devuelta por el HLR, independientemente de si es un MSC (entrega de SMS con conmutación de circuitos) o un SGSN (entrega de SMS con conmutación de paquetes). ).
El VMSC solicitará la información necesaria para entregar el mensaje corto a su destinatario enviando un mensaje Send_Info_for_MT_SMS al VLR. A continuación, el VLR iniciará una solicitud de búsqueda, o búsqueda de abonado, para el número ISDN de abonado móvil de los abonados de destino (MSISDN) y devolverá el resultado al VMSC. Dado que una implementación típica considera que el VLR se ubica junto con el MSC, este flujo de mensajes suele ser interno a la plataforma. [Nota 4] Si la página o la búsqueda del suscriptor falla, el VLR indicará la causa de la falla al VMSC, que cancelará el procedimiento de entrega de mensajes cortos y devolverá la falla al SMSC (consulte la sección Entrega de mensajes cortos fallidos a continuación) . Si la búsqueda del teléfono fue exitosa, el VMSC enviará al SMSC indicando que la entrega se realizó correctamente. El componente GMSC del SMSC pasa el resultado del intento de entrega al Centro de Servicio. En el caso de una entrega exitosa, el mensaje de texto entregado se eliminará de Store and Forward Engine (SFE) y, si se solicita, se enviará un informe de entrega al autor del texto. [2] Si la entrega falla, el SMSC invoca un procedimiento de reintento para realizar periódicamente más intentos de entrega; Además, puede registrarse con el HLR para recibir una notificación cuando el B-Party esté disponible para la entrega de mensajes cortos en el futuro (consulte la sección Entrega de mensajes cortos fallidos a continuación).
Entrega fallida del mensaje corto
Cuando el VMSC / SGSN indica una falla en la entrega de mensajes cortos, el SMSC puede enviar un mensaje al HLR, utilizando el procedimiento MAP_REPORT_SM_DELIVERY_STATUS, indicando el motivo de la falla en la entrega y solicitando que el SMSC sea incluido en una lista de centros de servicio que desean ser se notificará cuando la parte de destino vuelva a estar disponible. El HLR colocará una bandera contra la cuenta de destino, indicando que no está disponible para la entrega de mensajes cortos, y almacenará la dirección del SMSC en la lista de datos de mensajes en espera (MWD) para la parte de destino. Los indicadores válidos son el indicador de móvil no alcanzable (MNRF), el indicador de capacidad de memoria excedida (MCEF) y el indicador de móvil no accesible para GPRS (MNRG). El HLR ahora comenzará a responder a las solicitudes SRI-for-SM con una falla, indicando el motivo de la falla, y agregará automáticamente la dirección del SMSC solicitante a la lista de MWD para la parte de destino. (Sin embargo, si el mensaje SRI-for-SM tiene un indicador de prioridad establecido, el HLR responderá con la dirección VLR si está disponible)
El HLR puede ser informado de la disponibilidad de un suscriptor para la entrega de mensajes cortos de varias formas:
- Cuando el suscriptor se haya desconectado de la red, una nueva conexión activará una Actualización de ubicación en el HLR.
- Cuando el suscriptor ha estado fuera de cobertura, pero no completamente desconectado de la red, al regresar a la cobertura, responderá a las solicitudes de búsqueda del Registro de ubicación de visitantes (VLR). El VLR enviará entonces un mensaje Ready-for-SM (móvil presente) al HLR.
- Cuando la MS ha tenido su memoria llena y el suscriptor borra algunos textos, se envía un mensaje Ready-for-SM (memoria disponible) desde el VMSC / VLR al HLR.
Al recibir una indicación de que la parte de destino ya está lista para recibir mensajes cortos, el HLR envía un mensaje AlertSC MAP a cada uno de los SMSC registrados en la lista MWD para el suscriptor, lo que hace que el SMSC inicie de nuevo el proceso de entrega de mensajes cortos . desde el principio. [1]
Además, el SMSC entrará en un programa de reintentos, intentando entregar periódicamente el SM sin recibir una alerta. El intervalo del programa de reintentos dependerá de la causa original de la falla: las fallas transitorias de la red darán como resultado un programa de reintentos corto, mientras que la falta de cobertura generalmente resultará en un programa más largo.
Operaciones MAP
Las operaciones de MAP relacionadas con la transferencia de mensajes cortos se resumen en la siguiente tabla:
Operación | Código | Fuente → Destino | MAPA | ||
1 | 2 | 3 | |||
MT-ForwardSM | 44 | GMSC → MSC / SGSN | - | - | + |
MO-ForwardSM | 46 | MSC / SGSN → IWMSC | - | - | + |
SendRoutingInfoForSM | 45 | GMSC → HLR | + | + | + |
ForwardSM | 46 | GMSC → MSC / SGSN | + | + | - |
ForwardSM | 46 | MSC / SGSN → IWMSC | + | + | - |
ReportSM-DeliveryStatus | 47 | GMSC → HLR | + | + | + |
AlertServiceCentreWithoutRes | 49 | HLR → IWMSC | + | - | - |
InformServiceCentre | 63 | HLR → GMSC | - | + | + |
AlertServiceCentreWithResult | 64 | HLR → IWMSC | - | + | + |
InformServiceCentre
InformServiceCentre es un mensaje que HLR puede proporcionar a la respuesta sendRoutingInfoForSM o reportSM-DeliveryStatus. El mensaje se usa generalmente para transferir indicadores MWD al centro de servicio de mensajes cortos . [1]
Protocolos de transporte MAP
Mientras que las especificaciones de MAP 3GPP hacen algún esfuerzo para separar MAP de la capa que lo transporta, el transporte típico es a través de TCAP que a su vez es a través de protocolos SCCP / MTP [1-3] y / o SIGTRAN (SUA, M3UA, etc.).
Por tanto, una construcción MAP_OPEN está directamente relacionada con un TCAP_BEGIN con un contexto de aplicación MAP, un MAP_CLOSE es un TCAP_END.
Si un mensaje se envía utilizando MAP fase 2 o superior, y sobre MTP en lugar de SIGTRAN, entonces el tamaño máximo de PDU de MTP puede hacer que el remitente instigue el envío de mensajes segmentados. Este proceso no está relacionado con la concatenación , sino que simplemente significa que la transacción con el MSC / SMSC / SGSN implica más pasos de lo habitual. La forma recomendada [1] es un TCAP_BEGIN vacío, seguido del contenido del MAP dentro de un TCAP_CONTINUE y completando con un TCAP_END. El TCAP_BEGIN tiene información relacionada con TCAP que de otra manera causaría que se exceda el límite debido a los campos adicionales agregados por la fase 2 del MAP. El punto exacto en el que se requiere la segmentación depende de factores como la longitud de las direcciones, pero depende principalmente de la la longitud del mensaje en sí. Los mensajes alfabéticos de 7 bits que tienen 140 caracteres o más suelen estar sujetos al procedimiento de segmentación MAP.
Este procedimiento de segmentación también es seguido cada vez más, y opcionalmente aplicado, por los operadores para evitar que la suplantación de SMS afecte a sus clientes. Esto funciona porque la parte remitente debe recibir las respuestas para enviar un mensaje y, por lo tanto, su dirección de origen debe ser correcta. [5]
Notas
- ^ En la Fase 1 de MAP, no hubo segregación de código de operación para mensajes SMS originados en dispositivos móviles y terminados en dispositivos móviles, solo una operación genérica de ForwardSM.
- ^ Una indicación de éxito en estos contextos es solo una notificación de que el SM ha sido enviado al Centro de Servicio y no significa una entrega exitosa al destino final del mensaje de texto.
- ^ Aunque MAP (fase 2 en adelante) especifica una operación separada para la entrega de mensajes cortos con terminación móvil, a menudo se usa la operación mo-ForwardSM en su lugar. Cuando este es el caso, los mensajes móviles originados y terminados se distinguen por la inclusión, en la porción de diálogo TCAP, de un contexto de aplicación (AC) apropiado. Los AC relevantes son shortMessageMO-RelayContext y shortMessageMT-RelayContext. Este uso de un único código de operación permite una compatibilidad retroactiva simple con las redes MAP fase 1, que no tienen operaciones separadas para mensajes cortos MO y MT.
- ^ Estos mensajes no son utilizados por un SGSN.
Referencias
- ^ a b c d e f g h Especificación de la parte de aplicación móvil, 3GPP TS 29.002, disponible aquí
- ^ a b c d Especificación punto a punto de SMS, 3GPP TS 23.040, disponible aquí
- ^ Especificación del servicio de transmisión celular 3GPP TS 23.041, disponible aquí
- ^ a b Soporte de servicio de mensajes cortos (SMS) punto a punto (PP) en la especificación de interfaz de radio móvil, 3GPP TS 24.011, disponible aquí
- ^ Proyecto de asociación de tercera generación 3GPP TS 33.204 ; Seguridad de usuario de la parte de aplicación de capacidades de transacción (TCAP); Anexo D: Uso del protocolo de enlace TCAP para la transferencia de SMS