GSM 03.40 o 3GPP TS 23.040 [1] es un estándar de telefonía móvil que describe el formato de las Unidades de Datos del Protocolo de Transferencia (TPDU) del Protocolo de Transferencia de Mensajes Cortos (SM-TP) usado en las redes GSM para transportar mensajes cortos . Este formato se utiliza durante toda la transferencia del mensaje en la red móvil GSM . Por el contrario, los servidores de aplicaciones utilizan diferentes protocolos, como Short Message Peer-to-Peer o Universal Computer Protocol , para intercambiar mensajes entre ellos y el Short Message Service Center (SMSC).
GSM 03.40 es el nombre original del estándar. Desde 1999 está siendo desarrollado por el 3GPP bajo el nombre 3GPP TS 23.040. Sin embargo, el nombre original se usa a menudo para referirse incluso al documento 3GPP.
Uso
Las TPDU GSM 03.40 se utilizan para transportar mensajes entre la estación móvil (MS) y el centro de conmutación móvil (MSC) utilizando el protocolo de retransmisión de mensajes cortos (SM-RP), [2] mientras que entre MSC y el centro de servicio de mensajes cortos (SMSC) el Las TPDU se transportan como un parámetro de un paquete de la parte de aplicación móvil (MAP) [3] . [4]
En las redes emergentes que utilizan el subsistema multimedia IP (IMS), los mensajes cortos se transportan en el comando MESSAGE del protocolo de inicio de sesión (SIP). Incluso en estas redes basadas en IP existe una opción que (por razones de compatibilidad) define la transferencia de Mensajes Cortos en el formato GSM 03.40 incrustado en 3GPP 24.011 como Content-Type: application / vnd.3gpp.sms. [5] [6]
Tipos de TPDU
GSM 03.40 define seis tipos de mensajes, que se distinguen por la dirección del mensaje y los dos bits menos significativos en el primer octeto del mensaje SM-TP (el campo TP-MTI):
TP-MTI | dirección | Tipo de mensaje |
---|---|---|
0 0 | MS → SC | INFORME-ENTREGA-SMS |
0 0 | SC → MS | ENTREGA DE SMS |
0 1 | MS → SC | ENVIAR SMS |
0 1 | SC → MS | INFORME-ENVIAR-SMS |
1 0 | MS → SC | COMANDO SMS |
1 0 | SC → MS | INFORME-ESTADO-SMS |
1 1 | alguna | Reservado |
SMS-SUBMIT se utiliza para enviar un mensaje corto desde un teléfono móvil (Mobile Station, MS) a un centro de servicio de mensajes cortos (SMSC, SC).
SMS-SUBMIT-REPORT es un acuse de recibo del SMS-SUBMIT; un éxito significa que el mensaje se almacenó (en búfer) en el SMSC, un error significa que el mensaje fue rechazado por el SMSC.
SMS-COMMAND se puede utilizar para consultar un mensaje almacenado en el búfer del SMSC, modificar sus parámetros o eliminarlo.
SMS-DELIVER se utiliza para enviar un mensaje desde SMSC a un teléfono móvil. El acuse de recibo devuelto por el teléfono móvil puede contener opcionalmente un SMS-ENTREGA-INFORME. Cuando se aplica el enrutamiento doméstico , SMS-DELIVER se utiliza para enviar mensajes desde un SMSC a otro.
El SMSC puede enviar SMS-STATUS-REPORT para informar al teléfono móvil de origen sobre el resultado final de la entrega del mensaje o para responder a un SMS-COMMAND.
Campos TPDU
Los campos de los mensajes SM-TP, incluido su orden y tamaño, se resumen en la siguiente tabla, donde M significa un campo obligatorio, O un campo opcional, E se usa para los campos que son obligatorios en las respuestas negativas (RP-ERR) y no presente en respuestas positivas (RP-ACK), x es un campo presente en otra parte:
COMANDO SMS | Talla | Nombre del campo | ||||||
---|---|---|---|---|---|---|---|---|
INFORME-ESTADO-SMS | ||||||||
INFORME-ENVIAR-SMS | ||||||||
ENVIAR SMS | ||||||||
INFORME-ENTREGA-SMS | ||||||||
ENTREGA DE SMS | ||||||||
campo | ||||||||
TP-MTI | METRO | METRO | METRO | METRO | METRO | METRO | 2 bits | Indicador de tipo de mensaje |
TP-MMS | METRO | METRO | 1 bit | Más mensajes para enviar | ||||
TP-RD | METRO | Rechazar duplicados | ||||||
TP-LP | O | O | 1 bit / 2 bits | Prevención de bucle | ||||
TP-VPF | METRO | Formato del período de validez | ||||||
TP-SRI | O | 1 bit | Indicación del informe de estado | |||||
TP-SRR | O | O | Solicitud de informe de estado | |||||
TP-SRQ | METRO | Calificador de informe de estado | ||||||
TP-UDHI | O | O | O | O | O | O | 1 bit | Indicador de encabezado de datos de usuario |
TP-RP | METRO | METRO | 1 bit | Ruta de respuesta | ||||
TP-FCS | mi | mi | 1 octeto | Causa de falla | ||||
TP-MR | METRO | METRO | METRO | 1 octeto | Referencia de mensaje | |||
TP-DA | METRO | X | 2 a 12 octetos | Dirección de destino | ||||
TP-OA | METRO | 2 a 12 octetos | Dirección de origen | |||||
TP-RA | METRO | 2 a 12 octetos | Dirección del receptor | |||||
TP-SCTS | X | X | METRO | 7 octetos | Sello de hora del centro de servicio | |||
TP-DT | METRO | 7 octetos | Tiempo de descarga | |||||
TP-ST | METRO | 1 octeto | Estado | |||||
TP-PI | METRO | METRO | O | 1 octeto | Indicador de parámetro | |||
TP-SCTS | X | METRO | X | 7 octetos | Sello de hora del centro de servicio | |||
TP-PID | METRO | O | METRO | O | O | METRO | 1 octeto | Identificador de protocolo |
TP-DCS | METRO | O | METRO | O | O | 1 octeto | Esquema de codificación de datos | |
TP-SCTS | METRO | X | X | 7 octetos | Sello de hora del centro de servicio | |||
TP-VP | O | 0, 1 o 7 octetos | Período de validez | |||||
TP-UDL | METRO | O | METRO | O | O | 1 octeto | Longitud de los datos de usuario | |
TP-UD | O | O | O | O | O | dado por TP-UDL | Datos del usuario | |
TP-CT | METRO | 1 octeto | Tipo de comando | |||||
TP-MN | METRO | 1 octeto | Número de mensaje | |||||
TP-DA | X | METRO | 2-12 octetos | Dirección de destino | ||||
TP-CDL | METRO | 1 octeto | Longitud de datos de comando | |||||
TP-CD | O | dado por TP-CDL | Datos de comando |
El primer octeto de la TPDU contiene varias banderas, incluido el campo TP-MTI descrito anteriormente:
poco (s) | Significado |
---|---|
1-0 | TP-Message-Type-Indicator (TP-MTI) |
2 | TP-More-Messages-to-Send (TP-MMS) en SMS-DELIVER (0 = más mensajes) |
2 | TP-Rechazo-Duplicados (TP-RD) en SMS-SUBMIT |
3 | TP-Loop-Prevention (TP-LP) en SMS-DELIVER y SMS-STATUS-REPORT |
4-3 | TP-Validity-Period-Format (TP-VPF) en SMS-SUBMIT (00 = no presente) |
5 | TP-Status-Report-Indication (TP-SRI) en SMS-DELIVER |
5 | TP-Status-Report-Request (TP-SRR) en SMS-SUBMIT y SMS-COMMAND |
5 | TP-Status-Report-Qualifier (TP-SRQ) en SMS-STATUS-REPORT |
6 | TP-User-Data-Header-Indicator (TP-UDHI) |
7 | TP-Reply-Path (TP-RP) en SMS-DELIVER y SMS-SUBMIT |
Al establecer el bit TP-More-Messages-to-Send (TP-MMS) en 0 (lógica inversa), el SMSC indica que tiene más mensajes para el destinatario (a menudo, más segmentos de un mensaje concatenado). El MSC generalmente no cierra la conexión con el teléfono móvil y no finaliza el diálogo MAP con el SMSC, lo que permite una entrega más rápida de mensajes o segmentos de mensajes posteriores. Si, por coincidencia, los mensajes adicionales desaparecen del SMSC mientras tanto (cuando, por ejemplo, se eliminan), el SMSC termina el diálogo MAP con un mensaje MAP Abort.
El bit TP-Loop-Prevention (TP-LP) está diseñado para evitar el bucle de mensajes SMS-DELIVER o SMS-STATUS-REPORT enrutados a una dirección diferente a la dirección de destino o generados por una aplicación. Dicho mensaje sólo puede enviarse si el mensaje original tenía esta bandera borrada y el nuevo mensaje debe enviarse con la bandera activada.
Al establecer el bit TP-Status-Report-Indication (TP-SRI) en 1, el SMSC solicita que se devuelva un informe de estado al SME.
Al establecer el bit TP-Status-Report-Request (TP-SRR) en 1 en un SMS-SUBMIT o SMS-COMMAND, el teléfono móvil solicita un informe de estado para ser devuelto por el SMSC.
Cuando el TP-SRQ tiene el valor 1 en un mensaje SMS-STATUS-REPORT, el mensaje es el resultado de un SMS-COMMAND; de lo contrario, es el resultado de un SMS-ENVIAR.
Cuando TP-UDHI tiene el valor 1, el campo TP-UD comienza con el encabezado de datos del usuario .
La configuración de los bits TP-RP activa una función que permite enviar una respuesta a un mensaje utilizando la misma ruta que el mensaje original. Si las redes domésticas del originador y del destinatario difieren, la respuesta pasaría por otro SMSC, entonces normalmente. El operador de telefonía móvil debe tomar medidas especiales para cobrar dichos mensajes.
Tanto el SM-RP como el MAP que se utilizan para transmitir GSM 03.40 TPDU contienen suficiente información para devolver el acuse de recibo, es decir, si una solicitud se realizó correctamente o no. Sin embargo, se puede incluir una TPDU GSM 03.40 en el acuse de recibo para transportar aún más información. El GSM 03.40 ha experimentado el siguiente desarrollo:
- Hasta GSM 03.40 5.2.0 SMS-DELIVER-REPORT y SMS-SUBMIT-REPORT se enviaron solo en caso de error. Desde 5.3.0 también se envían en caso de éxito. MO-ForwardSM-Res se introdujo en GSM 09.02 5.6.0 Agosto de 1997
- Hasta GSM 03.40 6.0.0 SMS-DELIVER-REPORT y SMS-SUBMIT-REPORT enviados en caso de error contenían solo los campos TP-MTI y TP-FCS y el último campo en SMS-STATUS-REPORT era TP-ST. Desde la versión 6.1.0, estas TPDU tienen el formato que se muestra en la tabla anterior.
Aunque estos cambios son antiguos (la versión 6.1.0 se produjo en julio de 1998), los formatos antiguos de MAP se ven con frecuencia incluso en las redes actuales.
Contenido del mensaje
El contenido del mensaje (su texto cuando el mensaje no es binario) se transporta en el campo TP-UD. Su tamaño puede ser de hasta 160 × 7 = 140 × 8 = 1120 bits. Los mensajes más largos pueden dividirse en varias partes y enviarse como SMS concatenados . La longitud del contenido del mensaje se da en el campo TP-UDL. Cuando la codificación del mensaje es el alfabeto predeterminado GSM de 7 bits (depende del campo TP-DCS), el TP-UDL da la longitud de TP-UD en unidades de 7 bits; de lo contrario, TP-UDL da la longitud de TP-UD en octetos.
Cuando TP-UDHI es 1, TP-UD comienza con el encabezado de datos de usuario (UDH); en este caso, el primer octeto del TP-UD es el octeto de longitud de encabezamiento de datos de usuario (UDHL), que contiene la longitud del UDH en octetos sin el propio UDHL. UDH come espacio del campo TP-UD. Cuando la codificación del mensaje es el alfabeto predeterminado de 7 bits GSM y hay un UDH, se insertan bits de relleno para alinear el comienzo del primer carácter del texto después de UDH con el límite del septeto. Este comportamiento fue diseñado para teléfonos móviles más antiguos que no entienden UDH; tales teléfonos móviles pueden mostrar la UDH como un revoltijo de caracteres extraños; si el primer carácter después de UDH fuera Carriage Return (CR), el teléfono móvil volvería a escribir el mensaje con el resto del mensaje.
Direcciones
Un mensaje GSM 03.40 contiene como máximo una dirección: dirección de destino (TP-DA) en SMS-SUBMIT y SMS-COMMAND, dirección de origen (TP-OA) en SMS-DELIVER y dirección del destinatario (TP-RA) en SMS-STATUS- INFORME. Otras direcciones son transportadas por capas inferiores .
El formato de las direcciones en el GSM 03.40 se describe en la siguiente tabla:
octeto | Significado |
---|---|
0 | longitud de la dirección en nibbles ( semioctetos ) |
1 | EXT, TON, NPI |
2-11 | dígitos de la dirección |
Tipo de número (TON):
Bit 6 5 4 | Significado |
---|---|
0 0 0 | Desconocido 1) |
0 0 1 | Número internacional 2) |
0 1 0 | Número nacional 3) |
0 1 1 | Número específico de red 4) |
1 0 0 | Número de abonado 5) |
1 0 1 | Alfanumérico, (codificado de acuerdo con 3GPP TS 23.038 [9] Alfabeto predeterminado GSM de 7 bits) |
1 1 0 | Número abreviado |
1 1 1 | Reservado para extensión |
Si un suscriptor ingresa un número de teléfono con el signo "+" al principio, el signo "+" se eliminará y la dirección obtendrá TON = 1 (número internacional), NPI = 1. El número en sí debe comenzar siempre con un código de país y debe formatearse exactamente de acuerdo con el estándar E.164 .
Por el contrario, para los números escritos sin el signo `+ ', la dirección obtiene TON = 0 (desconocido), NPI = 1. En este caso, el número debe cumplir con el plan de marcación del operador de telefonía móvil , lo que significa que los números internacionales deben tener el prefijo internacional (00 en la mayoría de los países, pero 011 en los EE. UU.) Antes de que el código de país y los números para llamadas de larga distancia deben comenzar con el prefijo de troncal (0 en la mayoría de los países, 1 en EE. UU.) seguido de un código de troncal.
Identificación del plan de numeración (NPI):
Bits 3 2 1 0 | Significado |
---|---|
0 0 0 0 | Desconocido |
0 0 0 1 | RDSI / plan de numeración telefónica ( E.164 /E.163) |
0 0 1 1 | Plan de numeración de datos ( X.121 ) |
0 1 0 0 | Plan de numeración por télex |
0 1 0 1 | Plan específico del centro de servicio 1) |
0 1 1 0 | Plan específico del centro de servicio 1) |
1 0 0 0 | Plan nacional de numeración |
1 0 0 1 | Plan de numeración privado |
1 0 1 0 | Plan de numeración ERMES (ETSI DE / PS 3 01 3) |
1 1 1 1 | Reservado para extensión |
Los números de teléfono deben tener NPI = 1. Los servidores de aplicaciones pueden utilizar direcciones alfanuméricas que tienen una combinación de TON = 5, NPI = 0.
El bit EXT siempre es 1, lo que significa "sin extensión".
Ejemplos de direcciones
El número de EE. UU. +1 555 123 4567 se codificaría como 0B 91 51 55 21 43 65 F7 (la F en los cuatro bits superiores del último octeto es un relleno que se usa cuando la longitud del número es impar).
La dirección alfanumérica se coloca primero en el alfabeto predeterminado de 7 bits GSM, luego se codifica de la misma manera que cualquier texto de mensaje en el campo TP-UD (eso significa que está empaquetado en 7 bits) y luego se proporciona la dirección con el "número" longitud y TON y NPI.
Por ejemplo, una dirección alfanumérica ficticia Design @ Home se convierte al alfabeto predeterminado de 7 bits GSM que produce 11 bytes 44 65 73 69 67 6E 00 48 6F 6D 65 (hex), el empaquetado de 7 bits lo transforma en 77 bits almacenados en 10 octetos como C4 F2 3C 7D 76 03 90 EF 76 19; 77 bits son 20 nibbles (14 hexadecimales), que es el valor del primer octeto de la dirección. El segundo octeto contiene TON (5) y NPI (0), lo que produce D0 hex. La dirección completa en formato GSM es 14 D0 C4 F2 3C 7D 76 03 90 EF 76 19.
Referencia de mensaje
El campo de referencia de mensaje (TP-MR) se utiliza en todos los mensajes en el lado de envío con excepción del SMS-SUBMIT-REPORT (es decir, SMS-SUBMIT, SMS-COMMAND y SMS-STATUS-REPORT). Es un valor de un solo octeto que se incrementa cada vez que se envía un nuevo mensaje o se envía un nuevo SMS-COMMAND. Si el envío del mensaje falla, el teléfono móvil debe repetir el envío con el mismo valor TP-MR y con el bit TP-RD establecido en 1.
Formato de tiempo
La fecha y la hora utilizadas en TP-SCTS, TP-DT y en formato Absoluto de TP-VP se almacenan en 7 octetos:
octeto | Contenido |
---|---|
0 | Últimos dos dígitos del año |
1 | Mes |
2 | Día |
3 | Hora |
4 | Minuto |
5 | Segundo |
6 | Zona horaria |
En todos los octetos, los valores se almacenan en formato decimal codificado en binario con dígitos conmutados (el número 35 se almacena como 53 hexadecimal).
La zona horaria se expresa en cuartos de hora. Si el desplazamiento de la zona horaria es negativo (en el hemisferio occidental), el bit 3 del último octeto se establece en 1.
23:01:56 El 25 de marzo de 2013 PST (GMT-7) se codificaría como 31 30 52 32 10 65 8A.
En este ejemplo, el huso horario, 8A es binario 1000 1010. El bit 3 es 1, por lo tanto, el huso horario es negativo. El número restante (bit a bit 'y' con 1111 0111) es 1000 0010, hexadecimal 82. Trátelo como cualquier elemento anterior en la secuencia, (hexadecimal 82 representa el número 28). Finalmente, el desplazamiento de la zona horaria viene dado por 28 × 15 minutos = 420 minutos (7 horas).
Período de validez
Una TPDU SMS-SUBMIT puede contener un parámetro TP-VP que limita el período de tiempo durante el cual el SMSC intentaría entregar el mensaje. Sin embargo, el período de validez suele estar limitado globalmente por el parámetro de configuración del SMSC, a menudo a 48 o 72 horas. El formato del período de validez se define mediante el campo Formato del período de validez:
TP-VPF | Formato TP-VP | Longitud TP-VP |
---|---|---|
0 0 | TP-VP no presente | 0 |
0 1 | Formato mejorado | 7 |
1 0 | Formato relativo | 1 |
1 1 | Formato absoluto | 7 |
Formato relativo
Valor TP-VP | Período de validez | Posibles periodos de validez |
---|---|---|
0-143 | (TP-VP + 1) x 5 minutos | 5, 10, 15 minutos ... 11:55, 12:00 horas |
144-167 | (12 + (TP-VP - 143) / 2) horas | 12:30, 13:00, ... 23:30, 24:00 horas |
168–196 | (TP-VP - 166) días | 2, 3, 4, ... 30 días |
197-255 | (TP-VP - 192) semanas | 5, 6, 7, ... 63 semanas |
Formato absoluto
El formato absoluto es idéntico a los otros formatos de hora en GSM 03.40.
Formato mejorado
Rara vez se utiliza el formato mejorado del campo TP-VP. Siempre tiene 7 octetos, aunque algunos de ellos no se utilizan. El primer octeto es el indicador de funcionalidad TP-VP. Sus 3 bits menos significativos tienen el siguiente significado:
2 1 0 | Significado |
---|---|
0 0 0 | Sin período de validez especificado |
0 0 1 | El siguiente octeto es un período de validez relativa como se describe en la tabla Valores del período de validez relativa |
0 1 0 | El siguiente octeto contiene un período de validez relativa en segundos en el rango de 0 a 255 |
0 1 1 | Los siguientes 3 octetos contienen un período de validez relativa en horas, minutos y segundos como el 3º al 5º octeto del formato de hora. |
1 XX | Reservado |
El valor de 1 en el bit 6 del primer octeto significa que el mensaje es de disparo único. El valor de 1 en el bit 7 del primer octeto indica que el indicador de funcionalidad TP-VP se extiende a otro octeto. Sin embargo, no se definen tales extensiones.
Identificador de protocolo
TP-PID (identificador de protocolo) se refiere al protocolo de capa superior que se está utilizando, indica el interfuncionamiento con un cierto tipo de dispositivo telemático (como fax , télex , buscapersonas , teletex , correo electrónico ), especifica el tipo de reemplazo del mensaje o permite la descarga de los parámetros de configuración a la tarjeta SIM . Los mensajes MO-MT sencillos tienen PID = 0.
TP-PID | significado |
---|---|
0 | Almacenar y reenviar mensajes cortos predeterminados |
1-31 | sin interfuncionamiento telemático, pero protocolo de PYME a PYME |
32 | dispositivo telemético implícito |
33 | Télex o teletex reducido al formato de télex |
34 | Telefax del grupo 3 |
35 | Telefax del grupo 4 |
36 | Telefono de voz |
37 | ERMES (sistema europeo de mensajería por radio) |
38 | Sistema de megafonía nacional (conocido por el SC) |
39 | Videotex (T.100 [20] /T.101 [21]) |
40 | Teletex , operador no especificado |
41 | Teletex , en PSPDN |
42 | Teletex , en CSPDN |
43 | Teletex , en PSTN analógico |
44 | Teletex , en RDSI digital |
45 | UCI (Interfaz informática universal, ETSI DE / PS 3 01 3) |
46–47 | Reservado |
48 | Una facilidad de manejo de mensajes (conocida por el SC) |
49 | Cualquier sistema público de manejo de mensajes basado en X.400 |
50 | Correo electrónico de Internet |
51–55 | Reservado |
56–62 | Específico de SC; uso basado en el mutuo acuerdo entre la PYME y el SC |
63 | Una estación móvil GSM / UMTS. |
64 | Tipo de mensaje corto 0 |
sesenta y cinco | Reemplazar mensaje corto tipo 1 |
66 | Reemplazar mensaje corto tipo 2 |
67 | Reemplazar mensaje corto tipo 3 |
68 | Reemplazar el tipo de mensaje corto 4 |
69 | Reemplazar el tipo de mensaje corto 5 |
70 | Reemplazar el tipo de mensaje corto 6 |
71 | Reemplazar el tipo de mensaje corto 7 |
72 | Mensaje corto de activación del dispositivo |
73–93 | Reservado |
94 | Servicio de mensajes mejorado (obsoleto) |
95 | Devolver mensaje de llamada |
96-123 | Reservado |
124 | ANSI-136 R-DATA |
125 | Descarga de datos ME |
126 | ME De personalización Mensaje corto |
127 | (U) Descarga de datos SIM |
128-191 | reservado |
192-255 | Asigna bits 0 5 para uso específico de SC |
Para TP-PID = 63, el SC convierte el SM del Esquema de codificación de datos de TP recibido a cualquier esquema de codificación de datos soportado por esa MS (por ejemplo, el predeterminado).
El tipo de mensaje corto 0 se conoce como SMS silencioso . Cualquier teléfono debe poder recibir dicho mensaje corto independientemente de si hay memoria disponible en la (U) SIM o ME o no, debe acusar recibo del mensaje, pero no debe indicar su recepción al usuario y debe descartar su contenido. por lo que el mensaje no se almacenará en la (U) SIM o ME.
Esquema de codificación de datos
Se diseñó una codificación especial de 7 bits llamada alfabeto predeterminado GSM de 7 bits para el sistema de mensajes cortos en GSM. El alfabeto contiene los símbolos más utilizados de la mayoría de los idiomas de Europa occidental (y algunas letras mayúsculas griegas). Algunos caracteres ASCII y el símbolo del euro no encajan en el alfabeto predeterminado de 7 bits de GSM y deben codificarse utilizando dos septetos. Estos caracteres forman la tabla de extensión alfabética predeterminada GSM de 7 bits . La compatibilidad con el alfabeto GSM de 7 bits es obligatoria para los teléfonos y elementos de red GSM. [7]
Los idiomas que usan escritura latina , pero usan caracteres que no están presentes en el alfabeto predeterminado de 7 bits GSM, a menudo reemplazan los caracteres faltantes con marcas diacríticas con los caracteres correspondientes sin signos diacríticos, lo que causa una experiencia de usuario no del todo satisfactoria, pero a menudo se acepta. Para una mejor apariencia, la codificación UTF-16 de 16 bits (en GSM llamada UCS-2) se puede usar al precio de reducir la longitud de un mensaje (no segmentado) de 160 a 70 caracteres.
Los mensajes en los idiomas chino, coreano o japonés deben codificarse con la codificación de caracteres UTF-16 . Lo mismo ocurrió con otros idiomas que utilizan escrituras no latinas como el ruso, el árabe, el hebreo y varios idiomas indios. En 3GPP TS 23.038 8.0.0 publicado en 2008 se introdujo una nueva función, una tabla de cambio de idioma nacional ampliada , que en la versión 11.0.0 publicada en 2012 cubre turco , español , portugués , bengalí , gujarati , hindi , kannada , malayalam , Idiomas oriya , punjabi , tamil , telugu y urdu . El mecanismo reemplaza la tabla de códigos alfabéticos predeterminados de 7 bits GSM y / o la tabla ampliada con una tabla o tablas nacionales de acuerdo con elementos de información especiales en el encabezado de datos de usuario . El mensaje no segmentado que utiliza tablas de cambio de idioma nacional puede transportar hasta 155 (o 153) caracteres de 7 bits.
El campo Esquema de codificación de datos (TP-DCS) contiene principalmente información sobre la codificación de mensajes. GSM reconoce solo 2 codificaciones para mensajes de texto y 1 codificación para mensajes binarios :
- Alfabeto predeterminado GSM de 7 bits (que también incluye el uso de tablas de cambio de idioma nacional)
- UCS-2
- Datos de 8 bits
El octeto TP-DCS tiene una sintaxis compleja para permitir el transporte de otra información; las más notables son las clases de mensajes:
Valor | Clase de mensaje |
---|---|
0 0 | 0 - Mensajes flash |
0 1 | 1 - específico de ME |
1 0 | 2 - SIM / USIM específico |
1 1 | 3 - específico de TE |
Los mensajes flash se reciben en un teléfono móvil aunque tenga la memoria completa. No se almacenan en el teléfono, solo se muestran en la pantalla del teléfono.
Otra característica disponible a través de TP-DCS es la eliminación automática: después de leer el mensaje se elimina del teléfono.
El grupo de indicación de mensaje en espera de valores DCS puede establecer o restablecer indicadores para indicar la presencia de mensajes de correo de voz , fax , correo electrónico u otros mensajes no leídos .
Un valor DCS especial también permite la compresión de mensajes , pero tal vez ningún operador lo utilice.
Los valores de TP-DCS se definen en la recomendación GSM 03.38 . Los mensajes enviados a través de esta codificación se pueden codificar en el alfabeto GSM de 7 bits predeterminado , el alfabeto de datos de 8 bits y el alfabeto UCS-2 de 16 bits . [7]
Tiempo de descarga
El campo TP-DT indica la hora y la fecha asociadas con un resultado TP-ST en particular:
- si el mensaje se ha entregado o, más generalmente, se ha completado otra transacción (TP-ST es 0-31), el TP-DT es el momento de la finalización de la transacción
- si el SMSC todavía está intentando entregar el mensaje (TP-ST es 32-63), el TP-DT es el momento del último intento de entrega
- si el SMSC no está realizando más intentos de entrega (TP-ST es 64-127), el TP-DT es la hora del último intento de entrega o la hora en la que el SMSC eliminó el mensaje
Indicador de parámetro
El campo TP-PI indica la presencia de otros campos en la TPDU ENVIAR-INFORME, ENTREGAR-INFORME o SMS-INFORME-ESTADO.
un poco | Significado |
---|---|
0 | TP-PID |
1 | TP-DCS |
2 | TP-UDL y TP-UD |
8 | otro octeto TP-PI (bit de extensión) |
Como actualmente todavía hay cuatro bits libres en TP-PI, se puede esperar que el bit de extensión sea cero incluso en el futuro, lo que ayuda a distinguir el campo TP-PI del campo TP-FCS cuando la información sobre si TPDU es parte de positivo o la respuesta negativa no está disponible: si el bit más significativo del segundo octeto de TPDU es 1, el segundo octeto es TP-FCS (en una respuesta negativa), de lo contrario es TP-PI (en una respuesta positiva).
Ver también
- Servicio de mensajes cortos
- GSM 03.38
- Esquema de codificación de datos
- Encabezado de datos de usuario
- SMS concatenados
- Realización técnica del servicio de mensajes cortos (GSM)
- Servicio de mensajería mejorado
- Servicio de Mensajes Multimedia
- Mensaje corto de igual a igual
- Protocolo informático universal
Referencias
- ^ Proyecto de asociación de tercera generación 3GPP TS 23.040 ; Realización técnica del Servicio de Mensajes Cortos (SMS)
- ^ Proyecto de asociación de tercera generación 3GPP TS 24.011 ; Soporte de servicio de mensajes cortos (SMS) punto a punto en la interfaz de radio móvil
- ^ Proyecto de asociación de tercera generación 3GPP TS 29.002 ; Especificación de la parte de aplicación móvil (MAP)
- ^ Proyecto de asociación de tercera generación; Realización técnica del Servicio de Mensajes Cortos (SMS) (3G TS 23.040 versión 11.5.0) (archivo .doc comprimido), ETSI, marzo de 2013.
- ^ Proyecto de asociación de tercera generación 3GPP TS 24.341 ; Soporte de SMS sobre redes IP
- ^ 3GPP TS 24.451 Soporte de SMS y MMS sobre el subsistema NGN IMS; Etapa 3 de 3GPP TS 24.341 Versión 7
- ^ a b 3GPP TS 23.038 , Alfabetos e información específica del idioma.