Diseño de un sistema automatizado de pruebas para los estandares

Transcription

UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Ingeniería Electrónica
Diseño de un sistema automatizado de pruebas
para los estándares GSM 11.11 y 11.14
Por:
Luis Alberto Parra Castellano
Sartenejas, Febrero 2005
Por:
Realizado con la asesoría de:
Prof. Alfredo Thomas (Universidad Simón Bolívar)
Ing. Juan Carlos Sosa (Motorola de Venezuela)
PROYECTO DE GRADO
Presentado ante la Ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de Ingeniero Electrónico
Dedicatoria
A mi familia, amigos y a la persona que más amo
Por tolerar todo el tiempo que no pude pasar con ellos
Agradecimientos
A Dios por darme la fortaleza en los momentos más difíciles
A mi familia por darme todo el cariño, apoyo y mucho más
A mi cielo por su infinito amor e invaluable comprensión
A mis amigos por soportarme cuando nadie más pudo hacerlo
A la Universidad Simón Bolívar por darme tantos conocimientos a lo largo de mi formación
A Motorola por darme la oportunidad de poner en práctica mis conocimientos
A mi tutor industrial por su oportuna orientación
A mi tutor académico por su dedicación y esmero en guiarme
A todos aquellos que de alguna forma me ayudaron en mi labor
PROYECTO DE GRADO presentado por:
Realizado con la asesoría de:
Prof. Alfredo Thomas (Universidad Simón Bolívar)
Ing. Juan Carlos Sosa (Motorola de Venezuela)
RESUMEN
Se realizó el diseño e implementación de una herramienta automatizada para evaluar la
compatibilidad de los móviles GSM Motorola con respecto a los estándares GSM 11.11 y
11.14. Esta herramienta está constituida por una aplicación cuyo objetivo es detectar errores
en la implementación de los comandos basándose en los resultados de los códigos de errores
definidos en los estándares. Se programaron SIM Cards de prueba nativas y la depuración se
llevó a cabo en equipos reales así como en el simulador del GemXplore 98 CASE 2.0, además
se redactó un informe detallado mostrando las fallas detectadas y su verificación en equipos de
la competencia.
PALABRAS CLAVE
GSM, SIM Card, SIM Application Toolkit, GemXplore Macro Assembly Language, Lectora de
tarjeta inteligente, comandos básicos GSM, comandos proactivos, SDK, OTA.
Aprobado con mención:______
Postulado para premio:______
Indice General
Indice General …………………………………………………………………………...… i
Indice de Figuras…………………………………………………………….……………... iii
Indice de Tablas……………………………………………………………………............. v
Lista de símbolos y abreviaturas………………………………………………………….... vi
Capítulo 1 – Introducción………………………………………………………………... 1
1.1 Planteamiento del Problema…………………………………………………………… 2
1.2 Antecedentes del Problema……………………………………………………………. 3
1.3 Justificación e Importancia…………………………………………………………….. 4
1.4 Contenido del Libro………………………………………………………………….… 4
Capítulo 2 – Marco Teórico ……………………………………………………………. 6
2.1 El Sistema GSM……………………………………………………………..………… 7
2.2 Definición del Proyecto……………………………………………………………..… 12
2.3 Solución Propuesta…………………………………………………………………….. 13
2.4 Fundamentos Teóricos……………………………………………………………….… 14
2.4.1 Una Smart Card para el sistema GSM………………………………………. 14
2.4.2 Arquitectura de una Smart Card…………………………………………….. 17
2.4.3 Interacción de la Smart Card………………………………………………… 19
2.4.4 El Sistema Operativo de una Smart Card……………………………………. 19
2.4.5 Aplicaciones dentro de una Smart Card……………………………………... 21
2.4.6 Aspectos de seguridad básicos en una Smart Card………………………..… 22
2.5 La SIM Card…………………………………………………………………………… 24
2.5.1 Sistema de Archivos de la SIM Card………………………………………... 26
2.5.2 Seguridad en el sistema GSM a través de la SIM Card ………………………29
2.5.3 Procedimientos de activación de una SIM Card……………………………... 32
2.6 Nuevas prestaciones de la SIM Card…………………………………………………... 34
2.6.1 Conjunto de Instrucciones SAT……………………………………………… 35
ii
2.6.2 Comunicación aérea (OTA: Over-The-Air)………………………………….. 39
2.6.3 Administración Remota de Archivos (RFM)………… ……………………... 41
2.6.4 Administración Remota de Applets (RAM)…………………………………. 43
Capítulo 3 – Metodología de Evaluación………………………………………………... 44
3.1 Descripción del Proyecto………………………………………………………………. 44
3.2 Metodología……………………………………………………………………………. 46
3.2.1 Conjunto de Instrucciones…………………………………………………….46
3.2.1.1 Comandos Básicos GSM………………………………………...… 47
3.2.1.2 Comandos Proactivos……………………………………………….49
3.2.2 Manejo de Excepción de Errores…………………………………………….. 50
3.2.2.1 Resultados Generales………………………………………………. 51
3.2.2.2 Códigos de Estado…………………………………………………..53
3.3 Herramientas empleadas en el desarrollo del Proyecto………………………………... 56
3.3.1 GemXplore 98 CASE 2.0……………………………………………………. 59
3.3.1.1 Módulos………………………...………………………………….. 60
3.3.1.2 Programación………………………………………………………. 62
3.3.2 Motorola RTA……………………………………………………………….. 63
Capítulo 4 – Resultados Obtenidos……………………………………………………… 64
4.1 Comandos Básicos GSM………………………………………………………………. 65
4.2 Comandos Proactivos………………………………………………………………….. 66
Capítulo 5 - Conclusiones y Recomendaciones…………………………………………. 69
5.1 Conclusiones…………………………………………………………………………… 69
5.2 Recomendaciones……………………………………………………………………… 70
Referencias…………………………………………………………………………………72
Bibliografías………………………………………………………………………………. 74
Apéndice A…………………………………………………………………………............ 75
iii
Indice de Figuras
Fig. 1 Smart Card virgen………………………………………………………………… 15
Fig. 2 Tarjetas que no requieren contacto (contactless card)……………………….……... 16
Fig. 3 Elementos básicos de una SIM Card………………………………………………... 17
Fig. 4 Elementos de una Smart Card………………………………………………………. 19
Fig. 5 Distribución de puertos de una Smart Card según ISO 7816………..……………... 20
Fig. 6 Lectora de Smart Cards……………………………………………………………... 20
Fig. 7 GemXplore Suite v1.3 de Gemplus, un SDK que emplea lenguaje de alto
nivel para la edición del código fuente…………………………………………………….. 22
Fig. 8 Solicitud del PIN en el inicio de sesión de una SIM Card………………………….. 23
Fig. 9 Cryptoflex de Axalto………………………………………………………………... 24
Fig. 10 Arquitectura básica del sistema Java Card……………………………………….. 26
Fig. 11 Sistema de archivos de la SIM Card………………………………………………..28
Fig. 12 Elementos básicos de la arquitectura GSM………………………………………... 30
Fig. 13 Ranura de inserción para la SIM Card……………………………………………...34
Fig. 14 La SIM Contiene una aplicación STK……………………………………………... 36
Fog 15 Parte del protocolo que brinda soporte al SAT…………….. ……………………... 37
iv
Fig. 16 Vista de la aplicación GSM Standard Tester desarrollada………………………… 57
Fig. 17 Vista de la aplicación GSM Modular Tester desarrollada…………………………. 57
Fig. 18 Módulo SIM Explorer y el sistema de archivos de una SIM Card………………… 60
Fig. 19 Módulo MenuEditor y proyecto englobado en menús…………………………….. 61
Fig. 20 Módulo ScriptEditor y parte del código fuente elaborado………………………… 61
Fig. 21 Módulo MobileSimulator………………………………………………………….. 62
v
Indice de Tablas
Tabla N° 1: Comandos básicos GSM presentes en el SDK……………………………….. 48
Tabla N° 2: Tipos de archivos con los que trabaja cada función……………....………….. 48
Tabla N° 3: Resultados Generales especificados en el estándar GSM 11.14….………….. 51
Tabla N° 4: Códigos de estado en respuesta a comandos ejecutados correctamente….….. 53
Tabla N° 5: Códigos de estado producidos en respuesta a comandos cuya ejecución ha sido
pospuesta…………………………………………………………………………………… 54
Tabla N° 6: Códigos de estado vinculados a problemas en manejo de memoria………..… 54
Tabla N° 7: Códigos de estado vinculados a problemas en el manejo de referencias…...… 54
Tabla N° 8: Códigos de estado vinculados a problemas de seguridad………………..…… 55
Tabla N° 9: Códigos de estado en respuesta a errores independientes de la aplicación…… 55
Tabla N° 10: Comandos presentes en el menú GSM Modular 1………………………….. 58
Tabla N° 11: Comandos presentes en el menú GSM Modular 2………………………...… 58
Tabla N° 12: Comandos presentes en el menú GSM Modular 3……………………………… 59
Tabla N° 13 Archivos extras creados para evaluar los comandos…………………………. 63
Lista de símbolos y abreviaturas
3DES:
Triple Data Encryption Standard
3GPP:
3rd Generation Partnership Project
AC:
Access Condition
ADM:
Administration Number
ADN:
Abbreviated Dialing Number
APDU:
Application Protocol Data Unit
API:
Application Interface
ATR:
Answer To Reset
AuC:
Authentication Center
BER-TLV:
Basic Encoding Rule for Tag, Length and Value
BS:
Base Station
BSC:
Base Station Controller
CAT:
Card Application Toolkit
CDMA:
Code Division Multiple Access
CEPT:
Conférence des Administrations Européenes des Postes et Télécommunications
CHV:
Card Holder Verification Number
CPU:
Central Process Unit
CRC:
Cyclic Redundancy Check
DCS:
Data Coding Scheme / Digital Communication System
DES:
Data Encryption Standard
DF:
Dedicated File
EDGE:
Enhanced Data for GSM Evolution
EEPROM:
Electrically Erasable Programmable Read Only Memory
EF:
Elementary File
EP SCP:
ETSI Project Smart Card Platform
ESMS:
Enhanced Short Message Service
ETSI:
European Telecommunication Standards Institute
FDMA:
Frequency Division Multiple Access
Lista de Abreviaturas
FID:
File Identification
GPRS:
General Packet Radio System
GSM:
Groupe Spéciale Mobile / Global System for Mobile Communications
HLR:
Home Location Register
HSCSD:
High-Speed Circuit-Switched Data
ICCID:
Integrated Circuit Card Identifier
ID:
Identifier
IMEI:
International Mobile Equipment Identifier
IMSI:
International Mobile Subscriber Identity
ISDN:
Integrated Service Digital Network
ISO/IEC:
Int'l Standard Organization / International Electrotechnical Commission
ITA:
Interim Type Approval
JCVM:
Java Card Virtual Machine
KC:
Ciphering Key
KI:
Individual Key
LAC:
Local Area Code
LAI:
Location Area Information
LFSR:
Linear Feedback Shift Register
LOCI
Location Information
MAC:
Media Access Control
MCC:
Mobile Country Code
ME:
Mobile Equipment, Terminal
MF:
Master File
MMS:
Multimedia Message Service
MNC:
Mobile Network Code
MoU:
Memorandum of Understanding
MS:
Mobile Station (Mobile Equipment ME + SIM Card)
MSC:
Mobile Switching Center
MSISDN:
Mobile Subscriber ISDN
NMT:
Nordic Mobile Telephone
NVM:
Non-Volatile Memory|
vii
OTA:
Over-The-Air
PC:
Personal Computer
PCS:
Personal Communications Service
PFE:
Product Field Engineering
PID:
Protocol Identifier
PIN:
Personal Identification Number
PPS:
Protocol Parameter Selection
PUK:
Personal Unblocking Key
RAND:
Random Number
RAM:
Random Access Memory / Remote Applet Management
ROM:
Read Only Memory
RFM:
Remote File Management
RFU:
Reserved for Future Use
RSA:
Random Scheduling Algorithm
RTMI:
Radio Telephone Mobile Integrated
RTMS:
Radio Telephone Mobile Second Generation
SAT:
SIM Application Toolkit
SC:
Service Center
SCA:
Service Center Address
SDK:
Software Development Kit
SIM:
Subscriber Identity Module, SIM Card
SIMEG:
Subscriber Identity Module Expert Group
SME:
Short Message Entity
SMG9:
Special Mobile Group 9
SMS:
Short Message Service (Servicio de mensajería de texto)
SMSC:
Short Message Service Center
SRES:
Signed Response
SS:
Supplementary Service
SST:
SIM Service Table
SW1/SW2:
Status Word 1 / Status Word 2
TACS:
Total Access Communication System
viii
TDMA:
Time Division Multiple Access
TMSI:
Temporary Mobile Subscriber Identity
TON:
Type Of Number
TP:
Transfer layer Protocol
TPDU:
Transport Protocol Data Unit
UATK:
UIM Application Toolkit
UIM:
Universal Identification Module
USAT:
USIM Application Toolkit
USIM:
Universal Subscriber Identity Module
VAS:
Value-added Service
VLR:
Visitor Location Register
VLSI:
Very Large Scale Integration
ix
Capítulo 1
Introducción
El mercado tecnológico de las telecomunicaciones está siempre en expansión inspirado en
una búsqueda incesante de nuevos desarrollos, innovaciones, mejores y más atractivos
productos y servicios que ofrecer a un público cada vez más exigente. Siguiendo esta
orientación muchas empresas han tenido que desarrollar estrategias que conlleven a alcanzar
una mayor calidad en sus productos, ofreciendo no sólo valor agregado sino también
versatilidad, al menor costo.
Actualmente los dispositivos móviles destinados a telefonía inalámbrica cuentan con una
mayor capacidad de procesamiento y mejoras tecnológicas que han respondido a la creciente
presión, por parte de las operadoras telefónicas, para promocionar y vender servicios de valor
agregado acorde a las necesidades de un mercado cada vez más segmentado. Se dice
segmentado porque es necesario distinguir entre los requerimientos de empresarios, jóvenes,
profesionales y demás personas que han hecho de estos equipos una necesidad adaptada a un
estilo de vida particular.
Ahora es posible no sólo enviar mensajes de texto (SMS) sino también imágenes y clips de
video (EMS/MMS) mediante la incorporación de cámaras VGA, capacidad para escuchar
sonidos polifónicos, radio, ver TV y navegar en Internet, realizar transacciones comerciales,
descargar juegos de video, conexión inalámbrica de alta velocidad (GPRS y Bluetooth) con
otros equipos y mucho más. Es claro que estas innovaciones responden a una mayor
especialización en el diseño de nuevos equipos y de un mercado dispuesto a pagar el precio
por ellos. La integración de múltiples servicios en un sólo dispositivo brinda muchas
Diseño de un sistema automatizado de pruebas para los estándares GSM 11.11 y 11.14
2
Capítulo 1
comodidades y ofrece una plataforma versátil que responde a las demandas de un mercado
exigente y especializado.
En un principio la tecnología celular tenía como norte la comunicación telefónica
inalámbrica por medio de la voz pero cada vez es mayor el número de servicios que
complementan el objetivo original, servicios como la mensajería de texto, el envío de
imágenes y operaciones bancarias son cada vez más comunes. La adquisición de un mayor
número de opciones dentro de un mismo equipo han significado notables mejoras en el
hardware así como un mayor control de depuración a nivel de programación. También ha
promovido la diversificación de las operadoras y la integración de las mismas con otras
entidades comerciales.
El desafío tecnológico que ha significado la integración de estos servicios ha sido posible
gracias a la digitalización de las comunicaciones, así como la adopción de mecanismos
modulares que de manera flexible permitan la incorporación de nuevas tecnologías. El sistema
GSM es un claro ejemplo que responde a la necesidad de un sistema de comunicaciones
inalámbrico más globalizado. Su implementación en Europa y en muchos países alrededor del
mundo constituye un éxito en la carrera de la unificación de las telecomunicaciones, dándole
la oportunidad a millones de subscriptores de disfrutar de las ventajas de disponer de un
módulo de identidad personal como lo es la SIM Card.
1.1 Planteamiento del Problema
Debido al crecimiento acelerado de los servicios de valor agregado ofrecidos por las
operadoras telefónicas ha sido necesario diseñar aplicaciones cada vez más complejas con el
propósito de brindar más y mejores beneficios a los abonados. Muchos de estos servicios
implican un incremento substancial de las capacidades, no sólo del equipo móvil (ME) sino
también de la SIM Card en el caso GSM. La tecnología GSM ha tenido que adoptar nuevas
estrategias para poder ser capaz de ofrecer estos servicios, una de ellas ha significado el
cambio en la forma en que el ME y la SIM Card se comunican. Esta conducta maestro-esclavo
3
Capítulo 1
implementada en el diseño original ha quedado obsoleta por lo que se requería que la SIM
Card jugase un rol más activo dentro de la moderna plataforma GSM.
Partiendo de este hecho, la modificación de ciertos aspectos en la interfaz SIM Card - ME
ha tenido serias consecuencias en el desempeño de funciones específicas creadas para dar
soporte a estas nuevas aplicaciones. Estas funciones, que surgieron con la creación del
conjunto de instrucciones SAT (SIM Application Toolkit), debido a su tardía implementación
han presentado problemas de ejecución en los equipos móviles más recientes. Cada comando
del SAT, dentro de la aplicación de la SIM Card, ejecutará funciones propias del ME. En este
sentido, la SIM Card contiene no sólo datos que ofrecer al ME sino instrucciones y
aplicaciones elaboradas con el SAT. En este sentido, la SIM Card ha adquirido cierto nivel de
proactividad al participar protagónicamente en la ejecución de aplicaciones complejas propias
de los nuevos servicios de valor agregado. Aun cuando estas instrucciones están claramente
definidas en el estándar, su implementación no ha sido completamente exitosa en muchos de
los equipos móviles del presente.
Este problema de incompatibilidad con las instrucciones y por ende con los estándares ha
limitado las prestaciones de los ME impidiendo muchas veces la correcta ejecución de una
aplicación, lo que se traduce en pérdidas no sólo para la operadora que adquiere los equipos
incapaces de adaptarse a los nuevos servicios, sino también para los fabricantes cuyos equipos
cada vez poseen menos demanda en virtud de que no pueden adaptarse al estándar y mucho
menos ofrecer nuevos beneficios.
1.2 Antecedentes del Problema
Estudios previos de este problema no han sido documentados y, por el contrario, lo que se
puede especificar es la presencia de SIM Cards programadas con ayuda de la interfaz gráfica
del entorno de desarrollo (SDK) que se ha adoptado para este proyecto. Dichas SIM Cards
contienen escasos y limitados comandos debido a que no permiten conocer el estado de la
instrucción luego de su ejecución. En virtud de esta ausencia de antecedentes se consideró
4
Capítulo 1
realizar un estudio detallado de los recursos disponibles sin tomar como referencia avances
previos del mismo.
1.3 Justificación e Importancia
El sistema GSM ha significado un gran avance en el proceso de unificación de las
telecomunicaciones al concebir la estandarización de muchos de sus parámetros, facilitando
así su difusión e implementación. Sin embargo, y pese a los detallados lineamientos que se
especifican, es común que en el mercado de las telecomunicaciones encontremos equipos
móviles que, si bien muestran un desempeño aceptable en las tareas comunes de los usuarios,
no siempre ejecutan los comandos acorde con el estándar dando lugar a incongruencias y
problemas de incompatibilidad que pueden afectar el funcionamiento del equipo con la red
GSM local. Esto constituye un serio problema para los fabricantes de equipo móviles al verse
obligados constantemente a estar apegados al estándar así como a las actualizaciones que,
sobre la base del tiempo, surjan para mejorar u optimizar las prestaciones del sistema GSM.
1.4 Contenido del Libro
Inicialmente se presenta un marco teórico detallado en el capítulo dos donde se discute una
breve introducción a la tecnología GSM comenzando por sus orígenes, evolución y aspectos
generales. Esto permitirá brindar al lector un panorama en donde inscribir el problema
planteado. Posteriormente se define el proyecto que se plantea en respuesta al problema, así
como la solución propuesta. El marco teórico ofrece información correspondiente a las tarjetas
inteligentes (Smart Cards) para brindar al lector el conocimiento necesario sobre las SIM
Cards, su desarrollo y funciones, estructura y aplicaciones. Aspectos de organización y
seguridad son también tratados en esta sección.
Más adelante en el capítulo tres se muestra detalladamente la metodología empleada para
la evaluación del proyecto. En la elaboración de esta herramienta, destinada a la detección de
5
Capítulo 1
incompatibilidades de los equipos móviles GSM Motorola con los estándares GSM 11.11 y
11.14, se explica el procedimiento requerido para el manejo de excepción de errores ofrecido
por el entorno GemXplore 98 CASE 2.0. También se aborda la naturaleza del problema así
como los mecanismos disponibles para su solución y la importancia de la precisión de los
resultados.
Posteriormente, el capítulo cuatro contiene los resultados generales y específicos
alcanzados con el proyecto, una evaluación sistemática de los resultados obtenidos y de sus
implicaciones.
Para finalizar, en el capítulo cinco, se ofrecen las conclusiones y recomendaciones
destinadas a promover la continuación del desarrollo iniciado con este proyecto, así como el
mejoramiento de las pruebas de compatibilidad en los estándares GSM 11.11 y 11.14 y otros
estándares.
Capítulo 2
Marco Teórico
Hacia principio de los años 80 muchos países europeos experimentaban un fuerte
crecimiento económico y a medida que el comercio crecía se hacía más crucial la
comunicación efectiva con otros clientes en otros países del continente. Sin embargo, en los
primeros días las grandes empresas de telecomunicaciones estaban enfocadas en su mercado
local y en las soluciones de la telefonía celular para consumo interno.
Era claro que el comercio mundial presionaría cada vez más por una tecnología que
ofreciera facilidades de comunicación inalámbrica internacional y esto llegó a ser el principio
del apogeo de las redes celulares de primera generación. El problema era cuestión de
capacidad y la carencia de la misma establecía fuertes limitaciones al sistema. Sería a
principio de los años 90 cuando la demanda por un sistema con mayores prestaciones de
interconexión haría colapsar el sistema de redes análogas que imperaba en aquellos días.
Pronto los grandes empresarios comenzaron a comprender que la investigación y
desarrollo de este sistema, en virtud de los elevados costos de operación y manufactura, debía
ser explotado internacionalmente a fin de justificar la cuantiosa inversión que requería. Si la
nueva industria debía sobrevivir debería hacerse algo y rápido.
Capítulo 2
7
2.1 El Sistema GSM
Ya existía para esa época la organización europea CEPT que administraba las
telecomunicaciones en 26 países de la región. La creación de este comité fue el primer paso
que Europa dio en la búsqueda de soluciones para los problemas que encaraba la industria de
las comunicaciones móviles. No sólo sentó las bases para una verdadera integración sino el
reconocimiento de una realidad que influía notoriamente en la industria europea. Ante tales
acontecimientos la CEPT estableció el GSM y para 1986 su sede principal (Permanent
Nucleus) se erigió en la capital francesa. Su objetivo era desarrollar las especificaciones para
una red de comunicaciones móviles para toda Europa capaz de dar soporte a muchos millones
de subscriptores así como permitir su interconexión con otras redes de telecomunicación.
Las tecnologías consideradas por el grupo GSM eran hasta entonces muy recientes y
ninguna había sido probada en la práctica. Un ejemplo claro de esto fue el concebir la
combinación de esquemas TDMA y FDMA con la transmisión digital de datos, todo esto
constituía un territorio completamente inexplorado para el desarrollo de aplicaciones móviles
a gran escala y, desde luego, significó uno de los obstáculos que dieron pie a numerosos
problemas técnicos que requirieron innovaciones en todos los sentidos.
Ninguno dudaba que el sólo hecho de establecer un estándar estaría plagado de problemas
técnicos, económicos y logísticos. No sólo eran economías muy distintas entre sí sino que
también culturas muy distintas que buscaban una mayor interrelación de mercado. De todas
formas, era obvio que si daba resultado las recompensas serían sustanciales y existía un
genuino deseo de combinar recursos a fin de obtener el éxito a largo plazo. Y no es
exageración decir que los subsecuentes progresos de la industria europea permanecen como la
prueba más fehaciente de que la cooperación de los países europeos pueden promover
enormes cambios en el mercado mundial.
Hacia 1985 la creciente urgencia por resolver los problemas se hizo evidente cuando
Alemania Occidental, Francia e Italia firmaron un acuerdo para el desarrollo del sistema GSM.
El Reino Unido se adhirió posteriormente y para ese entonces GSM argumentaba
persuasivamente que el estándar que estaban desarrollando contenía la clave para una solución
Capítulo 2
8
viable técnica y económicamente. Desde sus inicios el grupo GSM tenía en mente emplear un
sistema digital en lugar de uno analógico y que este operase sobre la banda de frecuencias de
900MHz. La tecnología digital ofrecía una atractiva combinación de desempeño y eficiencia
espectral que proveería de transmisión de alta calidad al tiempo que permitiría a un mayor
número de usuarios simultáneos usar la limitada banda de radio disponible. Además de sentar
las bases para futuros desarrollos e implementaciones en materia de seguridad de las
comunicaciones y de la transmisión de data. La digitalización del sistema permitió también
emplear dispositivos VLSI a base de silicón empleados en la miniaturización de las
computadoras, para hacer a los equipos móviles más pequeños y económicos.
Para lograr una base contractual común entre los países europeos se creó el MoU
(Memorandum of Understanding) que fue firmado en principio por tan sólo 15 operadores de
redes europeas hacia 1987. La Asociación GSM representa a más de 500 operadoras,
fabricantes y proveedores en la industria GSM. Hacia 1989, las especificaciones desarrolladas
fueron incorporadas en la recién fundada ETSI en donde se establecieron definitivamente.
Toda la especificación del GSM Fase 1 fue completada en forma aceptable en 1990 y
desarrollos posteriores permanecieron estancados por un tiempo hasta posteriores desarrollos
del GSM Fase 2, que dieron pie al surgimiento del GSM Fase 2+.
El sistema GSM inició su proceso de integración con la red ISDN, que estaba siendo
desarrollada para los sistemas basados en telecomunicaciones terrestres alrededor del mundo,
dando pie a una genuina interconexión entre sistemas digitales y analógicos. Aun cuando la
red estaba completa no existían suficientes ME porque los fabricantes requerían realizar
pruebas a fin de no ocasionar daños a la misma. La solución fue la introducción de la ITA.
Esencialmente, la ITA estaba integrada por un subconjunto de parámetros aprobados que
requerían ser probados para evitar que el terminal (ME) pudiese causar problemas a la red. A
pesar de la considerable preocupación que mostraron algunos operadores, los terminales ITA
estaban disponibles para comienzos de 1992 y terminales completos invadieron el mercado a
finales de ese mismo año. Finalmente el sistema GSM estaba comercialmente inaugurado.
En la práctica el lanzamiento del sistema GSM era un hecho. Entre los primeros en
adoptarlo estaban: Dinamarca (2 operadores), Finlandia (2 operadores), Francia, Alemania (2
Capítulo 2
9
operadores), Italia, Portugal (2 operadores) y Suecia (3 operadores). Hacia junio de 1992 se
firmó el primer acuerdo para roaming entre Telecom Finlandia y Vodafone del Reino Unido.
Hacia finales de 1993 el sistema GSM había alcanzado la marca de 1 millón de subscriptores y
con el siguiente millón a la vista. El MoU ahora agrupaba más de 70 miembros de 48 países y
con la firma de 25 acuerdos de roaming el sistema GSM estaba en camino de globalizarse.
Comenzó a dejar de ser un fenómeno exclusivamente europeo al adoptar a Telstra de Australia
como nuevo miembro del MoU. Con el paso del tiempo un mayor número de países adoptaron
este sistema como parte de su red de telecomunicaciones. Su estandarización había probado
ser efectiva y de alcance mundial.
En 1998, el grupo SIMEG comenzó a trabajar en las especificaciones para la Smart Card
GSM que fue denominada SIM Card. Este grupo fue originalmente compuesto por
representantes de fabricantes de tarjetas inteligentes, fabricantes de equipos móviles y
operadoras de redes de telecomunicación. Trabajando bajo los auspicios de ETSI, el SIMEG
estableció las especificaciones mediante las cuales se definía la interacción entre la SIM Card
y el ME, este estándar se conoció como GSM 11.11. Posteriormente en 1994, el SIMEG fue
transformado en el recientemente fundado SMG9, el cual mantenía bajo su mandato gran parte
del desarrollo y mantenimiento de todas las especificaciones de la SIM Card hasta el año 2000.
En ese año el SMG9 fue disuelto y las responsabilidades fueron repartidas entre 2 nuevos
grupos: el grupo de expertos de EP SCP que manejaría todos los problemas de orden genérico
en el área de las tarjetas para telecomunicaciones y el otro grupo 3GPP sería responsable de
las especificaciones para la interfaz de una aplicación específica entre el ME y la SIM Card.
Un gran número de especificaciones interrelacionadas y mutuamente dependientes fueron
necesarias para poder describir completamente, en términos técnicos, el sistema GSM. En total
son aproximadamente 130 especificaciones individuales con un total de más de 6.000 páginas.
Es importante señalar que los términos “especificaciones” y “estándar” suelen intercambiarse
ya que en el caso del GSM ambos términos son justificados. Desde que fueron publicados por
la organización ETSI, las especificaciones formalmente han adquirido el estatus de estándar.
De cualquier manera, las descripciones técnicas son tan estrictas que prácticamente todas las
implementaciones basadas en ellas son mutuamente compatibles. Es por ello que tiende a
Capítulo 2
10
usarse mucho más la numeración propia del GSM (GSM 11.11), en lugar del correspondiente
esquema ETSI (TS 100977) cuyo contenido es idéntico al primero.
La historia de la evolución del sistema GSM está caracterizada por una serie de progresos
edificados sobre logros previos y que han evolucionado en fases que definen los alcances del
sistema desde su creación. En este sentido, los servicios básicos (transmisión de voz, desvío de
llamadas, roaming y el servicio de mensajería de texto) fueron implementados en la Fase 1
(Phase 1) la cual comenzó en 1992. En la Fase 2 (Phase 2) que comenzó en 1996 se
implementaron servicios adicionales que incluyeron llamadas en conferencia, conmutación de
llamada, negociación del número discado y el uso de la banda de 1800MHz. Todo esto fue
continuado por la siguiente Fase (Phase 2+) en la cual estos servicios fueron mejorados
gracias a nuevas funciones implementadas a través de las aplicaciones SAT, HSCSD, GPRS,
entre otras.
Es importante acotar que cuando nos referimos al estándar GSM hablamos de un conjunto
de directrices y lineamientos agrupados por categorías que son empleados por los fabricantes
para asegurar compatibilidad. Estos están muy vinculados con la estandarización de la SIM
Card. He aquí algunos de los más importantes estándares que definen la arquitectura del
sistema GSM:
• GSM 02.09 Aspectos de seguridad.
• GSM 02.17 Características funcionales de la SIM Card.
• GSM 02.19 SIM Application Programming Interface (SIM API); Descripción del
servicio; Etapa 1.
• GSM 02.48 Especificaciones para los mecanismos de seguridad de SIM Application
Toolkit, Etapa 1.
• GSM 03.19 Sistema de Telecomunicación Celular Digital (Phase 2); SIM Application
Programming Interface (SIM API); SIM API para Java Card; Etapa 2.
• GSM 03.48 Especificaciones para los mecanismos de seguridad de SIM Application
Toolkit, Etapa 2.
• GSM 09.91 Aspectos de la interfaz de trabajo SIM – ME entre fase 1 y fase 2.
Capítulo 2
11
• GSM 11.11 Especificaciones para la interfaz SIM – ME.
• GSM 11.12 Especificaciones para la interfaz SIM de 3V – ME.
• GSM 11.13 Especificaciones para las pruebas de SIM API para Java Cards.
• GSM 11.14 Especificaciones de SIM Application Toolkit para la interfaz SIM – ME.
• GSM 11.17 Especificaciones para pruebas de desempeño de la SIM Card.
• GSM 11.18 Especificaciones para la interfaz SIM de 1.8V – ME.
A mediados del año 2001 había un total de 400 redes de telecomunicaciones móviles en
171 países basados en el estándar GSM, y con más de 565 millones de subscriptores y más de
20 billones de mensajes cortos de texto transmitidos cada mes. El número de usuarios sigue
creciendo en virtud de las excelentes prestaciones del sistema. El sistema GSM aún continúa
realizado notables progresos dando paso a nuevas tecnologías como GPRS, EDGE y GSM 3G.
La adaptación de GSM a la banda de los 1800 MHz. se denomina DCS 1800. DCS 1800
también está siendo ampliamente adoptado y utilizado en varios países de Asia y algunos
países de Sudamérica. PCS 1900 es una derivación de GSM para Norteamérica, actualmente
ya cubre un área substancial de los Estados Unidos de América. Todos estos sistemas tendrán
una forma de roaming (internacional-intersistemas, GSM 900, DCS 1800, PCS 1900) basada
en el Módulo de Identidad del Suscriptor (SIM). Un abonado de cualquiera de estos tres
sistemas puede acceder a los servicios de telecomunicaciones utilizando la SIM Card en una
unidad móvil. Si el abonado tiene una unidad móvil multibanda, entonces la misma unidad
móvil se puede utilizar en todo el mundo (desde hace un tiempo se han añadido nuevas bandas
para la comunicación GSM) y por tanto hay más oportunidades para nuevos fabricantes y
nuevas tecnologías.
Esta globalización está haciendo de GSM y su derivados una de las principales opciones
para ofrecer los servicios de comunicaciones personales (PCS) y de comunicaciones digitales
en el mundo.
Capítulo 2
12
2.2 Definición del Proyecto
El estándar contempla un gran número de instrucciones que requieren ser verificadas en
los equipos antes de que estos salgan al mercado, por tal motivo es necesario evaluar cada uno
de los comandos y detectar posibles fallas de compatibilidad a tiempo. Todo esto con el fin
último de ofrecer equipos móviles con un desempeño óptimo y prestaciones competitivas en el
mercado GSM.
El proyecto titulado “Diseño de un sistema automatizado de pruebas para los estándares
GSM 11.11 y 11.14” es una propuesta de la empresa Motorola de Venezuela C.A. que
persigue la mejora de su sistema de pruebas de compatibilidad con los estándares GSM, en
particular, los estándares 11.11 y 11.14 en sus equipos móviles. Recientes pruebas han
reportado la existencia de fallas a nivel de SIM Application Toolkit en algunos modelos
Motorola, estos reportes han sido arrojados por la empresa OMEGA DB Services & Software
que, empleando una SIM Card programada con escasos comandos proactivos, ha detectado
algunas fallas por lo que se presume un mayor número de fallas. La necesidad de detectar y
reportar estas fallas a tiempo ha llevado a la empresa Motorola a plantear el desarrollo de un
sistema de pruebas que contemple la evaluación de la mayor cantidad de comandos.
Este sistema incluye una serie de pruebas de los comandos comprendidos en cada estándar,
haciéndose énfasis en los comandos proactivos del estándar 11.14 que forman parte de un
conjunto de instrucciones elaboradas para mejorar las prestaciones de la SIM Card, a este
conjunto se le conoce con el nombre de SIM Application Toolkit. Su desarrollo se llevará a
cabo bajo la plataforma GemXplore 98 CASE 2.0 de Gemplus y contiene un menú en donde
se despliegan los diferentes tipos de pruebas correspondientes a los estándares, es decir
pruebas sobre los comandos básicos GSM y sobre los comandos proactivos. Esta herramienta
se halla almacenada en una SIM Card de prueba que contiene el código fuente (script)
necesario para evaluar cada una de las instrucciones ofrecidas por el entorno de desarrollo y
que están debidamente estandarizadas en el sistema GSM.
Capítulo 2
13
Las instrucciones serán evaluadas en función de la respuesta ofrecida por el móvil, a tales
efectos se cuenta con la codificación necesaria para el manejo de excepción de errores. En el
caso de un comando básico de GSM se emplearán los códigos de estado (Status Codes) y en el
caso de los comandos proactivos se emplearan los resultados generales (General Results)
retornados por cada instrucción. Es importante señalar que no todos los comandos se ejecutan
en un tiempo breve, así pues existen comandos que contemplan un tiempo de ejecución
relativamente largo debido a su propia función o a las modificaciones necesarias para ofrecer
una respuesta adecuada y de fácil comprensión.
2.3 Solución Propuesta
Estos problemas de compatibilidad de las instrucciones antes detalladas comprometen
seriamente el desempeño de los equipos móviles en la ejecución de nuevas aplicaciones.
Motorola no es la excepción dentro de los fabricantes de equipos GSM y por tal motivo, se
propuso la creación de un sistema capaz de detectar estos problemas de incompatibilidad con
el estándar en sus equipos. Este sistema formaría parte de un proyecto cuya meta final sea la
elaboración de una herramienta de software que pudiese evaluar comandos básicos GSM y
proactivos, siendo éstos últimos los que suelen presentar el mayor número de incongruencias.
Esta aplicación debe realizar la detección de los errores por cada comando que se ejecute y
para ello, el estándar define una serie de códigos de error que ayudan a determinar el resultado
de la ejecución de un comando dado. Dentro del entorno de desarrollo (SDK) se dispone de
instrucciones especiales para el manejo de excepción de errores. Aun cuando no se produce
una “excepción” como tal cuando un comando falla, se entiende que este término se aplica a
los códigos de errores que se generan por cada instrucción ejecutada. Una serie de SIM Cards
serían programadas con el código fuente a fin de cargarlo en el ME y proceder a ejecutar las
debidas pruebas. La interfaz que se ofrece está limitada por la arquitectura de menús del SIM
Application Toolkit que ofrece el GemXplore 98 CASE 2.0. En virtud de consideraciones
posteriores se crearon dos modalidades de la herramienta a fin de proveer de flexibilidad a los
futuros usuarios.
Capítulo 2
14
2.4 Fundamentos Teóricos
Para proceder a implementar la solución propuesta es necesario realizar un estudio
detallado de los aspectos teóricos más relevantes. Estas nociones básicas nos permitirán
comprender mejor la naturaleza del problema. El punto central del proyecto esta vinculado a
un dispositivo electrónico conocido como SIM Card, la cual es una de las múltiples
aplicaciones que poseen las Smart Cards y casi la más difundida de todas.
2.4.1 Una tarjeta inteligente para el sistema GSM
La SIM Card es una de las aplicaciones de un circuito integrado a modo de tarjeta mejor
conocido como Smart Card, el cual consiste en un dispositivo similar a un microcomputador
con capacidad de almacenamiento programable. Es de un tamaño casi exacto al de una tarjeta
de crédito pero puede almacenar desde 4KB hasta 64KB y más de información para realizar
tareas de procesamiento aunque modestas son significantes en muchas de sus aplicaciones.
Las Smart Cards son ideales en tareas que requieren mecanismos de seguridad para resguardar
la información así como su integridad. Las políticas de seguridad garantizan que el acceso a la
información presente sólo puede ser efectuado por personas autorizadas. La integridad de los
datos garantiza que la data almacenada debe permanecer sin cambios por un tiempo
relativamente prolongado, aun cuando el suministro de energía a la Smart Card sea
interrumpido. Básicamente existen tres clases de Smart Cards:
•
Tarjetas basadas en un circuito integrado a modo de memoria (memory cards).
•
Tarjetas que contienen un microprocesador (microprocessor cards).
•
Tarjetas que no requieren contacto y que contienen un microprocesador (contactless
cards).
Las primeras Smart Cards fueron tarjetas de memoria que contenían un circuito integrado
que funcionaba como una memoria no volátil así como los circuitos necesarios para realizar
operaciones de lectura y escritura en esa memoria. Estas primeras tarjetas dependían del
dispositivo conocido como lectora de tarjetas o bien de una computadora para realizar las
Capítulo 2
15
tareas de procesamiento, su bajo costo y su modesto nivel de seguridad le permitieron
difundirse profusamente y aún hoy en día constituyen la mayor proporción de las Smart Cards
que están en el mercado. Tarjetas prepago para teléfonos son una de las aplicaciones
principales de este tipo de Smart Card y la razón principal es un mayor nivel de seguridad del
que se obtenía con tarjetas a base de banda magnética. En la Fig. 1 puede apreciarse una Smart
Card virgen.
Fig. 1 Smart Card virgen
Las tarjetas de memoria emplean un protocolo de comunicación síncrono entre ellas y la
lectora de tarjetas, estando el canal de comunicación siempre bajo control de la lectora. Una
variante de este tipo de tarjeta es la llamada tarjeta lógica (Logic Card). Esta tarjeta incorpora
mejoras en aspectos de seguridad a través de un circuito de memoria direccionada que
requieren un intercambio confidencial entre la tarjeta y la lectora. Más sofisticada aún es otro
tipo de tarjeta de memoria conocida como tarjeta óptica (Optical Card) cuya capacidad puede
llegar hasta 4MB. Sin embargo, una vez escrita la data no puede ser cambiada o removida.
Estas tarjetas son útiles en el resguardo de información como por ejemplo registros de
conducir, médicos o de viajes.
Otro tipo de tarjetas son aquellas que tienen microprocesadores y son más conocidas con el
nombre de Chip Cards en virtud del microprocesador que poseen y que les permite procesar
Capítulo 2
16
datos en la tarjeta. La generación actual de tarjetas con microprocesador tiene un poder de
procesamiento equivalente al de las primeras computadoras IBM. Ejemplo de las tarjetas con
microprocesador son los monederos electrónicos, que proveen un acceso relativamente seguro
a las redes para garantizar confidencialidad en las transacciones financieras y desde luego, las
SIM Cards empleadas por el sistema GSM y las cuales abordaremos en las próximas secciones.
Por último y no menos importante está el grupo de tarjetas que no requieren contacto y que
hacen uso de una señal electromagnética para establecer comunicación con la lectora. La
potencia requerida para encender el chip es transmitida desde la lectora vía microondas a la
tarjeta. Estas tarjetas ofrecen un uso sencillo en aplicaciones donde la posesión de la tarjeta
basta para ser usada, un ejemplo clásico son en puestos de identificación y el control de acceso
como el que se observa en la Fig. 2.
Fig. 2. Tarjetas que no requieren contacto (contactless card)
Capítulo 2
17
2.4.2 Arquitectura de una Smart Card
Una SIM Card como sabemos es una Smart Card que posee un microprocesador y como
tal una arquitectura bien definida. El elemento central de la misma lo constituye la Unidad
Central de Procesamiento (CPU), además de la memoria y toda la electrónica de entrada y
salida del dispositivo. Todo debidamente integrado en un chip cuyas dimensiones son:
3cm×2cm. En la Fig. 3 se pueden apreciar los componentes que integran el chip. Debido a su
reducido tamaño, la interconexión entre los diversos componentes del chip no son observables
por lo que resulta muy difícil intersectar las señales.
Fig. 3 Elementos básicos de una SIM Card
El CPU en un chip de una Smart Card esta formado por un microcontrolador,
generalmente de 8-bit (con set de instrucciones propios del Motorola 6805 o Intel 8051). Los
CPUs de las Smart Card ejecutan instrucciones en lenguaje máquina a una velocidad
aproximada de 400.000 instrucciones por segundo, aunque recientes versiones puede superar
fácilmente el millón de instrucciones por segundo. Tareas comunes en la Smart Card pueden
tomar alrededor de 1 ó 2 segundos, pero si se requieren ejecutar labores de encriptación
usando una clave de 1024 bits como las del RSA es posible que el tiempo este alrededor de 10
a 20 segundos. Es por esta razón que últimamente los microprocesadores contienen un coprocesador que está destinado a acelerar las labores de encriptación, algo similar ocurre con
Capítulo 2
18
los procesadores para las computadoras personales que disponen de co-procesadores para
realizar cálculos con precisión de flotante. Algunas Smart Cards colocan restricciones
referentes a la localización de código ejecutable, por lo que muchos chips de Smart Cards no
aceptarán la ejecución de código en memoria RAM. En algunos casos las Smart Cards
habilitan secciones especiales de memoria no-volátil para ser reconfigurada de forma que un
programa guardado en ella no pueda ser sobrescrito, es decir, transformando la sección en
memoria ROM.
En contraste con la mayoría de las computadoras con grandes cantidades de memoria de
acceso aleatorio (RAM), las Smart Card tienen una muy pequeña cantidad de RAM (256-1000
bytes). Memoria de sólo lectura (ROM) así como memoria no volátil (NVM) también están
presente en las Smart Cards. La data almacenada en la RAM no puede continuar siendo
guardada una vez que la tarjeta es apagada, pese a esto la RAM sigue siendo un elemento
requerido para ciertas aplicaciones en las Smart Cards. Al igual que ocurre en las PCs, el
tiempo de acceso del CPU a la RAM es mucho más rápido y este factor resulta importante
cuando se trata de operaciones que requieren respuestas en un tiempo preciso (e.g.
comunicaciones móviles)
Las Smart Cards de propósito general suelen contener entre 8KB y 32 KB de memoria
ROM en la cual se almacena el sistema operativo incluyendo rutinas para comunicación,
archivos de sistema, rutinas aritméticas de encriptación y propósitos especiales. El fabricante
suele colocar esta información en la ROM y esta no puede ser modificada. La información que
cambia frecuentemente se almacena en la memoria no volátil (NVM), la cual es de hecho
eléctricamente borrable y programable sólo para lectura (EEPROM) y este tipo de memoria
suele ser entre 1KB y 16 KB en las Smart Card. En este tipo de memoria la data puede
permanecer hasta 10 años almacenada aun si no se suministra energía en ese tiempo. Sin
embargo, hay algunas desventajas que presenta la EEPROM: la primera es que toma entre 3 y
10 ms. para escribir datos en ella, la segunda es que la EEPROM tiene un límite de ciclos de
escritura cercano a las 100.000 veces. En la Fig. 4 pueden observarse los componentes básicos
presentes en una Smart Card.
Capítulo 2
19
Fig. 4 Elementos de una Smart Card
2.4.3 Interacción de la Smart Card
La conexión que requiere una Smart Card con el mundo exterior se lleva a cabo a través
de puertos sencillos de entrada/salida, como se observa en la Fig. 5, que pueden ser reservados
por el microprocesador. Esto se logra empleando protocolos de alto nivel en donde el
procesador discrimina toda la información que va y viene hacia y desde otros componentes del
chip. Como una Smart Card no posee una fuente de poder propia ni una señal de reloj para el
procesador, es necesario que la Smart Card interactúe con un dispositivo que pueda
suministrar alimentación y la señal de reloj, suele conocerse como dispositivo de interfaz
(IFD), terminal o lectora. Además la lectora debe ser capaz de establecer un canal de
comunicación entre la aplicación en la PC y el sistema operativo en la tarjeta. Casi todas las
lectoras son de hecho también grabadoras (escritoras) pues permiten, dependiendo de la
aplicación, escribir data así como leerla.
Capítulo 2
20
Fig. 5 Distribución de puertos de una Smart Card según ISO 7816
La relación entre la Smart Card y los dispositivos que se emplean para acceder a ella
suelen emplear una comunicación maestro-esclavo como ocurre con las tarjetas de crédito
(Ver Fig. 6). Sin embargo en aplicaciones como la SIM Card se ha implementado un conjunto
de instrucciones que permite dar mayor proactividad a la SIM Card y la aplicación que pueda
contener. El canal de comunicación entre la Smart Card y la lectora es half-duplex. Esto
significa que la data puede fluir de la tarjeta a la lectora y viceversa, con la limitación de que
no puede fluir en ambas direcciones al mismo tiempo como sí sucedería en un full-duplex. En
relación a la tasa de transmisión, esta debe ser igual a la de muestreo en el receptor a fin de
garantizar la integridad de la data. Esta tasa recibida por y transmitida desde la Smart Card es
almacenada en un buffer contenido en la limitada memoria RAM de la tarjeta. Luego, paquetes
de entre 10 y 100 bytes de datos son movilizados en cada mensaje, y de esta manera se
establece la comunicación entre la Smart Card y la lectora.
Fig. 6 Lectora de Smart Cards
Capítulo 2
21
2.4.4 El Sistema Operativo de una Smart Card
El sistema operativo que se halla en la mayoría de las Smart Cards implementa un
conjunto de instrucciones (de 20 a 30) que están definidas en los estándares (ISO 7816 o CEN
726) y a los cuales las Smart Cards responden. La mayoría de los fabricantes ofrecen tarjetas
con sistemas operativos que implementan algunos o todos estos comandos estándares
(posiblemente con las extensiones). Este sistema operativo soporta un sistema de archivos
definidos de igual forma en el estándar ISO 7816 y conforma un bloque de memoria pequeño
de la Smart Card. Los detalles del sistema de archivos suelen ser confidenciales a menos que
el fabricante exprese lo contrario por lo tanto detalles de su estructura quedan reservados.
2.4.5 Aplicaciones dentro de una Smart Card
El software contenido en una Smart Card y por ende en una SIM Card puede ser
clasificado en dos categorías: card software y host software. El primero es software que se
ejecuta en la Smart Card y provee de servicios de cómputo para aplicaciones que tienen
acceso a la información contenida en la tarjeta. También suministra protección a la
información a la que pueden intentar ingresar incorrectamente. Dentro de este software
podemos identificar 2 categorías: software de aplicación y software de sistema. El primero
funciona de forma muy similar a cualquier programa que instalamos en un PC y típicamente
está escrito en lenguaje ensamblador (Assembly Language) definido específicamente para la
arquitectura del microprocesador que contiene la Smart Card. Sin embargo, puede ser
programado empleando un lenguaje de alto nivel y luego interpretado en el mismo chip o
puede ser compilado en lenguaje ensamblador y posteriormente descargado a la Smart Card.
Por otro lado, el software de sistema hace uso explícito de mecanismos que permiten asegurar
la integridad de los datos así como aplicar propiedades particulares.
El host software se ejecuta en una PC que esta en contacto con la Smart Card a través de
una lectora de tarjetas. Suele incluir un software que sirve de interfaz al usuario y que permite
la detección y conexión de la aplicación con un periférico en particular, en este caso la propia
Capítulo 2
22
lectora. En su mayoría constituyen paquetes de diseño y programación conocidos como SDK
(Software Development Kit) que están disponibles comercialmente. En la Fig. 7 se puede
apreciar la interfaz de un SDK de Gemplus llamado GemXplore Suite v1.3
Fig. 7 GemXplore Suite v1.3 de Gemplus, un SDK que emplea
lenguaje de alto nivel para la edición del código fuente
2.4.6 Aspectos de seguridad básicos en una Smart Card
Una de las principales razones que motivaron el surgimiento de las Smart Cards fue la
seguridad. La tarjeta provee una plataforma computacional en la cual la información puede
resguardarse empleando técnicas de encriptamiento. De esta forma se puede restringir, por
ejemplo en las SIM Cards, lectura de información mediante un control de acceso
implementado mediante la solicitud de una clave personal PIN (Personal Identification
Number) y alguna otra clave para acceder a ciertos archivos como se observa en la Fig. 8
Capítulo 2
23
Fig. 8 Solicitud del PIN en el inicio de sesión de una SIM Card
Estas claves son almacenas en archivos que se ubican inmediatamente por debajo del
archivo maestro (MF), el cual se detallará en posteriores secciones. También pueden
almacenarse las claves, públicas o privadas, para encriptar la información o para propósitos de
autenticación. Puede hacer uso de diversos algoritmos para asegurar la inviolabilidad de la
información resguardada. De este modo los procesos de verificación pueden ser sencillos
como la solicitud del PIN o pueden ser más complejos como la encriptación de un mensaje
dado empleando un algoritmo y clave particulares. De hecho, existen mecanismos que
autorizan la autodestrucción de una SIM Card en caso de que cierto número de intentos de
verificación hallan resultado fallidos, asegurando así la protección de la data de terceros.
La encriptación es un proceso que demanda gran capacidad de cómputo y son pocas las
Smart Cards que pueden emplear semejantes algoritmos de encriptamiento. En ciertas
ocasiones, las Smart Cards requieren de un procesador extra que esté dedicado a esta tarea y
suele recibir el nombre de criptoprocesador (crytoprocessor). Un ejemplo conocido de este
tipo de Smart Card lo es la “Cryptoflex” fabricada por Schlumberger y Axalto, la cual puede
implementar algunos de los algoritmos de encriptamiento más conocidos como los son: DES,
3DES y RSA 1024. En la Fig. 8 puede apreciarse una versión de esta Smart Card.
Capítulo 2
24
Fig. 9 Cryptoflex de Axalto
2.5 La SIM Card
La SIM Card es, en esencia, un módulo de seguridad intercambiable necesario en el
sistema GSM y se ubica dentro del equipo móvil (ME). Su definición se describe
detalladamente en la especificación GSM 02.17 y señala lo siguiente: “La SIM Card es una
entidad que contiene la identidad del subscriptor y su función primaria es asegurar la
autenticidad de la estación móvil (MS) con respecto a la red”. Además de su función primaria
de seguridad la cual se lleva a cabo a través de los PIN que pueden ser desbloqueados
empleando los PUK respectivos en caso de introducir erróneamente más de 3 veces el PIN
(esto depende de la configuración de la misma). La SIM Card también permite la ejecución de
programas que deben ser protegidos contra manipulación lo que le permite almacenar data de
forma segura (números telefónicos, mensaje, configuración personal del móvil, etc.) y ofrece
una plataforma para la implementación de nuevos servicios que requieren de niveles de
protección como los que ofrece la SIM Card.
Cuenta con aproximadamente 32 KB de espacio aunque esta cifra puede variar según las
versiones. Fue y aún sigue siendo un dispositivo pionero en términos de funcionalidad y
capacidad de memoria. Dentro del sistema GSM se distinguen dos formatos de SIM Card.
Para los equipos móviles diseñados para permitir el intercambio frecuente de SIM Cards se
usa el formato ID-1, el cual está basado en la idea de un teléfono familiar o corporativo con
una SIM Card para cada usuario. En cambio, para los equipos móviles más pequeños, que por
lo general tienen un único dueño, cuyas SIM Cards raras veces son removidas del equipo
móvil, se emplean las de formato ID-000. De cualquier manera, la única diferencia entre estos
dos tipos de tarjetas son sus dimensiones ya que sus características lógicas y físicas son
Capítulo 2
25
idénticas. Desde mediados de los años 90, los teléfonos móviles se han convertido en algo más
que accesorios personales y su uso se ha extendido a personas de todas las edades. Esto ha
sido un efecto del tamaño de la tarjeta usada, pues ya no era necesario intercambiar la tarjeta
dependiendo de quién usaba el teléfono.
La comunicación entre el ME y la SIM Card usa un protocolo conocido como T=0 con
parámetros estandarizados y detalladamente especificados en el ISO/IEC 7816-3. La
convención empleada para la transmisión de la data puede ser escogida libremente por la
tarjeta vía ATR. También existe un mecanismo conocido como PPS que tiene la capacidad de
incrementar la velocidad de transmisión de datos.
El desarrollo de las SIM Cards lo han liderizado los grandes fabricantes como Gemplus
(Francia), Schlumberger (Francia), ORGA (Alemania), Microsoft (USA) y Hewlett-Packard
(USA). Cada uno de ellos ha desarrollado herramientas de programación para SIM Cards y
han implementado las bondades de los lenguajes de alto nivel en el diseño y programación de
estas tarjetas. Todos y cada uno de los desarrollos deben estar fuertemente adheridos al
estándar GSM a fin de garantizar su correcto funcionamiento dentro de la red, y todas las
mejoras que se hagan deben realizarse tomando como base la plataforma de las
especificaciones.
Un ejemplo claro es la aparición de las Java Cards que, a diferencia de las tarjetas nativas,
pueden ser programadas usando un subconjunto de instrucciones de Java usando un
compilador especial proporcionado por el entorno de desarrollo que convierte el código Java
Card en instrucciones que luego serán interpretadas por la JCVM (Java Card Virtual
Machine) según se aprecia en la Fig. 10. Este avance permite la creación de código mucho
más rápido que si se usara una herramienta convencional para programar en lenguaje nativo,
típicamente conocido como Macro Assembly Language. Sin embargo, ésta es tan sólo una de
múltiples ventajas que han surgido como consecuencia de la necesidad de adaptarse a un
mercado que cambia con gran rapidez y que insta a los fabricantes y desarrolladores a
implementar soluciones rápidas, oportunas y de alta demanda.
Capítulo 2
26
Fig. 10 Arquitectura básica del sistema Java Card
2.5.1 Sistema de Archivos de la SIM Card
La SIM Card cuenta con un sistema jerárquico de archivos que comprende un archivo
maestro (MF), dos o más archivos dedicados (DF) directamente debajo del archivo maestro y
muchos archivos elementales (EF). En la Fig. 10 se muestra un esquema básico del sistema de
archivos presente en una SIM Card. Los archivos elementales contienen información de
diversa índole y se presentan con estructuras diferentes, pueden ser: transparentes, lineales
fijos o cíclicos.
•
Transparentes: Los datos se almacenan de forma secuencial byte a byte. El acceso a estos
datos se realiza especificando el offset desde el comienzo del EF así como la cantidad de
datos que se desean obtener. Usualmente se emplean para almacenar aplicaciones.
Algunos archivos fundamentales transparentes son: EFICC (archivo de identificador de
tarjeta), EFCSTEP (archivo de personalización de descripción), EFDIR (archivo de
identificador de directorios), EFKEY (archivos de claves), EFADM y EFCHV (archivos de
códigos secreto) y EFAUTHCOUNT (archivo de contador de autenticación).
Capítulo 2
•
27
Lineales Fijos: Los datos se almacenan estructurados en registros de longitud fija. Este
tipo de archivos puede contener hasta 255 registros incluidas las extensiones que puedan
hacerse. Su acceso puede realizarse mediante direccionamiento absoluto o relativo
(similar a como ocurre con algunos microcontroladores). También existen Lineales
Variables que pueden ajustar el tamaño de sus registros en función de la data almacenada.
•
Cíclicos: Los datos se almacenan en registros de longitud fija en estructura de anillo en
orden cronológico. Cada archivo puede contener hasta 255 registros cada uno de 255
bytes de longitud. El último registro creado es contiguo al primero que fue creado y que
pasa a su vez a ser el último. Su acceso puede realizarse mediante direccionamiento
absoluto o relativo.
Los archivos dedicados constituyen directorios que agrupan una serie de archivos
elementales que guardan características similares además de compartir funciones
emparentadas. Sólo existe un archivo maestro dentro del árbol jerárquico de archivos de una
SIM Card y bajo él se encuentran archivos elementales relacionados con funciones de
seguridad y administración de aplicaciones así como arranque de aplicaciones, identificación
de la SIM Card y permisología general.
Los identificadores de archivo (FID) de la SIM Card poseen una característica especial, el
primer byte de cada archivo dedicado debajo del archivo maestro siempre tiene como valor
0x7F. Por otra parte, los archivos elementales debajo del archivo maestro deben tener como
primer byte del identificador de archivo el valor 0x2F. Los archivos elementales que se hallen
debajo del archivo dedicado TELECOM deben tener como primer byte del identificador de
archivo el valor 0x6F, y los que se hallen debajo del archivo dedicado GSM tendrán un valor
igual a 0x5F. Finalmente aquellos archivos elementales que se ubiquen debajo del archivo
dedicado MExE tendrán como primer byte del identificador de archivos el valor 0x4F. Esta
última clase de archivos no se observa normalmente en el sistema de archivos de la SIM Card
(ver Fig. 11) ya que no siempre contienen aplicaciones que son las que se almacenan en estos
Capítulo 2
28
archivos. Estas convenciones constituyen un remanente de los primeros días de los
microcontroladores en Smart Cards.
Fig. 11 Sistema de archivos de la SIM Card
Todos los archivos elementales que contienen información acerca de la SIM Card, tales
como el número serial único (ICCID), están ubicados directamente debajo del archivo maestro.
Todos los archivos elementales relevantes al sistema GSM están ubicados debajo del archivo
dedicado TELECOM, un caso típico de tales archivos lo constituye el archivo elemental que
almacena los números de discado abreviado (ADN). El archivo dedicado GSM en contraste
contiene archivos elementales que almacenan información específica referente al operador de
la red, un ejemplo es el IMSI.
En total existen alrededor de 70 archivos elementales definidos en las especificaciones
GSM 11.11, de las cuales tan sólo 12 (con un tamaño total de 110 bytes) son de carácter
Capítulo 2
29
obligatorio y el resto es opcional, por lo que su presencia en el sistema de archivos de la SIM
Card depende de los servicios ofrecidos por la operadora de red. Además de los archivos
predefinidos, una operadora de red puede añadir sus propios archivos en el árbol de archivos
de la SIM Card con propósitos administrativos o de mantenimiento. En la práctica, el uso
intensivo de esta característica puede producir un gran número de archivos (alrededor de 40)
con data perteneciente al usuario, cuyo tamaño total puede llegar a los 12 KB.
Muchos de los archivos localizados en el árbol de archivos de la SIM Card deben ser
reescritos frecuentemente, un ejemplo lo constituye el archivo elemental LOCI el cual
almacena la identidad temporal del móvil subscriptor TMSI junto con información
complementaria sobre su ubicación por medio del LAI. La data almacenada en este archivo
debe ser modificada cada vez que ocurre un cambio de estación base (BS) o cada vez que se
efectúa una nueva llamada. Todo esto da pie a que el “sistema operativo” de la SIM Card debe
soportar atributos especiales en los archivos, en este caso “alto nivel de actualización”.
Aparte de almacenar data, una de las funciones principales de la SIM Card es efectuar la
autenticación con respecto a la red GSM. Esto involucra un proceso unilateral en el cual la
SIM Card es verificada por el sistema. Si la autenticidad de la SIM Card es confirmada, la
operadora de la red puede saber que puede cobrar el costo de la llamada o servicio al
subscriptor dueño de la línea adscrita a la SIM Card. Para garantizar la seguridad se han
implementado técnicas como la mutua autenticación seguido del encriptamiento de todos los
datos de una llamada entre la SIM Card y el sistema.
2.5.2 Seguridad en el sistema GSM a través de la SIM Card
La SIM Card se identifica ante la red GSM usando un número que es único en todo el
sistema, se trata del IMSI el cual tiene una longitud máxima de 8 bytes. De este modo el
subscriptor puede ser identificado en todas las redes GSM alrededor del mundo, y en virtud de
mantener la identidad del subscriptor lo más confidencial posible se suele emplear el TMSI en
lugar del IMSI. El TMSI es generado desde el VLR y sólo es válido dentro de una porción de
Capítulo 2
30
toda la red GSM. Sin embargo, en combinación con el LAI, el TMSI es único en toda la red
GSM. Los elementos que intervienen en el proceso de identificación y autenticación forman
parte activa del sistema GSM tal y como se observa en la Fig. 12
Fig. 12 Elementos básicos de la arquitectura GSM
Las claves de la SIM Card para autenticación y encriptamiento de data en la interfaz aérea
pueden derivarse del IMSI. Sin embargo, la SIM Card no puede encriptar data para la interfaz
aérea debido a que las capacidades de procesamiento y transmisión no son idóneas para un
encriptamiento en tiempo real de una llamada. En su lugar, la SIM Card calcula el valor de
una clave temporal para la encriptación de la transmisión y la envía al ME. El ME posee una
unidad de encriptamiento de elevado desempeño a modo de procesador de señal, el cual puede
encriptar y desencriptar la data de la voz para la interfaz aérea y en tiempo real. La data
encriptada que viaja en la interfaz aérea suele desencriptarse en la BSC. Si un subscriptor
desea realizar una llamada, su terminal (ME) junto con la SIM Card conforman la estación
móvil (MS), la cual establece una conexión con la estación base que posea la mejor recepción
y le envía el TMSI, que la SIM Card ha almacenado en su memoria, junto con el LAI y en
casos excepcionales empleará el IMSI. En caso de que este se ubique en la región de la red
doméstica, una terna de datos de autenticación y encriptamiento es generada por el AuC. Esta
Capítulo 2
31
data incluye la clave de cifrado Kc para encriptar la data en la interfaz aérea, un número
aleatorio (RAND) y la respuesta resultante SRES. La ventaja de este procedimiento es que la
clave secreta Ki y el algoritmo de encriptamiento nunca tienen que abandonar el AuC. Esta
terna de datos es entonces enviada al HLR. Si el ME ha accesado a la red doméstica, la terna
(Kc, RAND, SRES) es enviada al VLR apropiado y el resultado (SRES) de encriptar el
número aleatorio es solicitado por la SIM Card a través del MSC y comparado con el resultado
recibido del AuC. Si ambos resultados coinciden, la SIM Card ha sido autenticada y el sistema
puede dar inicio al encriptamiento de la data de la interfaz aérea usando el algoritmo
criptográfico A5 y el Kc asociado. Situación similar se presenta cuando el ME intenta acceder
a una red foránea (no doméstica) en donde la terna de datos se emplea de la misma forma.
Los algoritmos de criptografía empleados en el sistema GSM son en general de naturaleza
confidencial y constituye un remanente del principio de Kerckhoff1 aplicado a este sistema.
Cualquier otra información sobre el sistema suele ser de dominio público. Originalmente, un
algoritmo llamado COMP 128 solía usarse para los algoritmos criptográficos A3 y A8, los
cuales son específicos para cada operador de red.
Hacia 1998, el algoritmo fue descifrado debido principalmente a que la clave era muy
corta, por lo que se optó por mejorarla dando lugar al COMP 128-2 y el algoritmo A5, el cual
es el mismo a través de todo el sistema GSM y consiste en una cadena cifrada de tres LFSR de
longitudes 19, 22 y 23 respectivamente incrementados por el número de la ranura TDMA
correspondiente.
Otro mecanismo de seguridad implementado por algunas operadoras de telefonía móvil se
conoce como SIM Lock, el cual consiste en restringir al móvil una SIM Card en particular o a
un grupo de éstas. Esta técnica de resguardo por así llamarla esta claramente especificada en el
estándar GSM 02.22 y su modo de operar se basa en la data almacenada en la SIM Card así
como la información del ME, ambas son comparadas por alguno de los dos componentes (SIM
1
El principio de Kerckhoff establece: “los algoritmos de ecnriptamiento deben ser de dominio público no así los
códigos que generan las claves”
Capítulo 2
32
Card o ME) cada vez que ocurre una conmutación de voltaje. De este modo el ME estará
habilitado siempre y cuando ambos conjuntos de datos concuerden.
Existen básicamente dos implementaciones de esta función (SIM Lock), la más
comúnmente usada consiste en la lectura de datos de la SIM Card por parte del ME y es
comparada con la data almacenada en el ME. Esta data esta compuesta por una serie de
identificadores que se hallan almacenados en los archivos EFGID1 y EFGID2. Estos grupos de
identificadores pueden ser usados para especificar clases de SIM Cards para un determinado
ME. Sin embargo, no siempre estos identificadores se usan para producir la correspondencia
de la SIM Card con el ME. Muchas veces se emplea el IMSI o alguna otra data específica
almacenada en los EF. La segunda opción que raras veces es puesta en práctica, es emplear
una aplicación SAT para leer un dato específico del ME y compararlo con su correspondiente
dato en la SIM Card, si ambos datos corresponde se inicia un proceso de habilitación de la
SIM Card y el ME. Es posible desactivar la función SIM Lock, bien sea vía Comunicación
aérea (OTA) o empleando el código secreto con el ME para así permitir que otras SIM Cards
puedan ser usadas en el ME. Usualmente la referencia empleada es el IMEI para poder
desactivar el SIM Lock.
2.5.3 Procedimientos de activación de una SIM Card
Uno de los primeros procedimientos que un ME realiza cuando es encendido es una
verificación del hardware para luego cargar el sistema operativo. Con el propósito de distraer
al impaciente usuario durante los segundos que toma el proceso de carga se ejecutan diversas
animaciones. El siguiente paso corresponde a la secuencia de activación de la SIM Card. La
secuencia de activación está acompañada por mediciones para la configuración de los
parámetros óptimos de transmisión, tales como el análisis del ATR y la ejecución del
procedimiento PPS. Luego de esto, suele crearse una imagen virtual de la SIM Card en la
memoria del ME. Para lograrlo se requiere la lectura de grandes cantidades de datos de la SIM
Card y el objetivo no es otro sino garantizar una rápida lectura y modificación de la
información almacenada, lo cual no sería posible debido a la baja tasa de transmisión de datos
Capítulo 2
33
entre la SIM Card y el ME además del considerable tiempo que le toma a la EEPROM para
escribir. Es por ello que la mayoría de los ME suelen trabajar con una SIM Card virtual
almacenada en memoria. Sin embargo esta técnica no puede ser implementada para toda la
data de la SIM Card, un ejemplo claro de esto lo constituye la verificación y autenticación del
PIN cuya ejecución debe hacerse en combinación con la SIM Card pues esta información
junto con otras no se les permite ser copiadas a la memoria del ME.
Uno de los aspectos favorables de trabajar con el concepto de SIM Card virtual es el
incremento considerable del tiempo de vida de la SIM Card, ya que se reduce en gran medida
el gran número de escrituras en la EEPROM que de otra forma serían necesarias y que
causarían un lento y progresivo deterioro de los archivos de la SIM Card. Un ejemplo lo
constituye el archivo EFLOCI el cual contiene información acerca de la ubicación actual del ME,
el contenido de este archivo es volátil en el ME que frecuentemente cambia de celda GSM y
por tal motivo se les atribuye una elevada tasa de refrescamiento. La data contenida en la SIM
Card virtual es escrita en la SIM Card siguiendo un procedimiento crítico que permite
oportunas actualizaciones de la información que debe contener la SIM Card. Esto
normalmente se lleva a cabo de forma asíncrona por la MS asignando una tarea de baja
prioridad al sistema operativo del ME, pasando desapercibido para el usuario.
Estas actualizaciones precisas son de importancia considerable en virtud de que la SIM
Card debe contener data esencial en su EEPROM y prevenir eventos inesperados tales como
el apagado repentino (remover la batería del ME). En la Fig. 13 se aprecia la ranura de
inserción de la SIM Card con los seis contactos básicos y un mecanismo de seguridad para
prevenir que esta se salga.
Capítulo 2
34
Fig. 13 Ranura de inserción para la SIM Card
Cuando se inicia el proceso de apagado del ME, el usuario suele ver una breve secuencia
de caracteres o animaciones en pantalla. Sin embargo, todos los archivos de la SIM Card
virtual son escritos a la SIM Card física mientras esas animaciones son mostradas. Finalmente
se da inicio a la secuencia de desactivación de la SIM Card y el sistema operativo del ME se
cierra. Es importante señalar que estos procedimientos y mecanismos aquí descritos no forman
parte de las especificaciones GSM, por lo que su implementación varía de acuerdo al
fabricante y a la tecnología empleada.
2.6 Nuevas prestaciones de la SIM Card
Pese a la versatilidad de la SIM Card, ésta no pasaba de ser sólo un dispositivo que
identificaba al usuario con la red y almacenaba información, la cual era solicitada por el ME
en una comunicación maestro-esclavo como ya se mencionó. Con el tiempo surgieron más y
mejores servicios de valor agregado (VAS) que demandaban una mayor proactividad en la
SIM Card, es decir, que ésta también tomara decisiones en función de alguna aplicación que
pudiese almacenar en su memoria. Para ello se diseñó un conjunto de instrucciones orientadas
a este propósito y tomó el nombre de SIM Application Toolkit (SAT).
Capítulo 2
35
2.6.1 Conjunto de Instrucciones SAT
En las especificaciones originales del sistema GSM, la SIM Card es vista como sólo un
medio para identificar al usuario, a través del PIN, con propósitos de control, facturación y
seguridad que fuesen independientes del ME. Sin embargo, con el paso del tiempo ha
aumentado el deseo de emplear la SIM Card para propósitos adicionales, esta tendencia se ha
incrementado considerablemente.
El estándar GSM 11.11 define 22 comandos operacionales para la SIM Card, los cuales se
identifican por el byte clase de valor 0xA0 2 . Los comandos pueden ser clasificados en:
comandos de seguridad, comandos para operaciones sobre archivos pertenecientes a
aplicaciones de SIM Application Toolkit y comandos misceláneos. Los comandos SAT se
definen en el estándar GSM 11.14
La memoria del teléfono es considerablemente mayor y constituye un recurso competente
para verificar información bancaria, recibir noticias u otra información, etc. Debido a sus
limitadas prestaciones la SIM Card no tiene suficientes recursos para la implementación de
servicios de valor agregado (VAS), en respuesta a esto surgió el SIM Application Toolkit
(SAT) que se conoce ampliamente con el nombre de SIM Toolkit. La primera versión de esta
especificación fue publicada en 1996 por ESTI.
El SIM Application Toolkit le permite a la SIM Card acceder directamente algunas de las
funciones del ME, tales como controlar lo que se muestra en pantalla, consultar el teclado,
enviar mensajes de texto y otras funciones que requieren conexión con un servicio de valor
agregado. Esta herramienta permite que casi cualquier aplicación, de tamaño razonable, sea
implementada en una SIM Card. Para llevar a cabo esta tarea fue necesario implementar no
sólo la creación de nuevos comandos sino también un cambio de mentalidad pues en esta
etapa se requería algo más que la lectura de datos de la SIM Card, se requerían de comandos
enviados por la SIM Card para que fuesen interpretados por el ME. De modo que ahora la SIM
Card dictaría las acciones a tomar por parte del ME, tal y como se ilustra en la Fig. 14
2
Números que contengan el formato 0xFF y FFh corresponden a la notación hexadecimal
Capítulo 2
36
Fig. 14 La SIM Card contiene una aplicación STK
La data contenida en estos comandos “proactivos” se codificó en BER-TLV, lo cual
facilitó la expansión de la capacidad al tiempo que aseguraba compatibilidad. De cualquier
forma, la mayor ventaja que se consiguió con esto fue la enorme flexibilidad que se adquirió
con el empleo de la codificación TLV.
Antes de SIM Application Toolkit, el ME y la SIM Card mantenían un protocolo de
comunicación maestro-esclavo y por razones de compatibilidad no se permitió el cambio de
este protocolo. La solución propuesta ante esta limitación fue el desarrollo de un
procedimiento de “encuesta” en el cual el ME envía solicitud de instrucciones a la SIM Card
cada cierto período de tiempo (aproximadamente 20 segundos). De ser necesario la SIM Card
podía indicar en su respuesta que un comando para el ME está listo para ser enviado y debe ser
localizado en la SIM Card. En la práctica, el intervalo asignado al proceso de encuesta no
suele permanecer constante y no constituye un problema crítico. Este cambio del principio
maestro-esclavo es designado “Proactividad de la SIM Card” y tiene vinculada un conjunto de
macros denominados comandos proactivos y resulta efectiva al revertir la relación maestroesclavo que originalmente fue concebida en el desarrollo del sistema GSM. Esto le permite a
la SIM Card funcionar con iniciativas propias que se hallen programadas en ella, haciendo
posible incluso interactuar con el sistema GSM a través de instrucciones que emplean interfaz
aérea (OTA).
Capítulo 2
37
Los comandos que hacen posible esta operación son básicamente tres: Fetch,
TerminalResponse y Envelope. El comando Fetch es empleado para solicitar
comandos a la SIM Card, después de procesar este comando el ME devuelve el resultado de la
operación usando el comando TerminalResponse. El comando Envelope permite la
transferencia de data al SAT del ME. Adicional a este nivel de proactividad por parte de la
SIM Card, esta puede también informar al ME sobre ciertos eventos que deben ser notificados
a la SIM Card tan pronto ocurran. En la Fig. 15 puede apreciarse parte del protocolo de
comunicación bajo el cual opera el SIM Application Toolkit.
Fig. 15 Parte del protocolo que brinda soporte al SAT
Existen diversas maneras de ejecutar servicios adicionales basados en SAT para la SIM
Card y la manera más sencilla involucra acciones por parte del usuario, la selección de una
función específica del menú del ME que este basada en una aplicación SIM Card implica que
un comando correspondiente será enviado a la SIM Card por parte del ME. También ciertos
eventos en el ME tales como: ejecución de una llamada, finalización de una llamada o el
cambio de celda pueden ser usados para invocar aplicaciones basadas en SAT en la SIM Card.
Otra manera más sencilla de invocar una aplicación SAT en una SIM Card es llevar a cabo
una especie de “encuesta cíclica” solicitada por el ME, en la práctica es posible lograrlo
Capítulo 2
38
implementando servicios de valor agregado de costo relativamente moderado usando estos tres
métodos de invocación básicos.
La típica secuencia de eventos que se ejecutan con SIM Application Toolkit incluye en
primer lugar la secuencia de activación de la SIM Card en donde diferentes tipos de datos son
leídos por el ME, datos que incluyen el archivo EFPHASE que contiene información sobre la
fase GSM que soporta la SIM Card. Si el código para la fase es almacenado en el archivo
EFPHASE y este corresponde a una fase que soporta SAT, entonces el ME procederá a usar el
comando TerminalProfile para informar a la SIM Card de las propiedades que posee y
que son relevantes para el SIM Application Toolkit. Esto completa el proceso de inicialización,
además si algún otro comando relacionado con GSM puede ser enviado, aun cuando no sea un
comando SIM Application Toolkit, se enviará.
El siguiente paso consiste básicamente en la instalación del menú de selección en el ME,
esto se logra transfiriendo data codificada en BER-TLV para el menú de selección en
respuesta al comando Fetch solicitado por la SIM Card enviado por el ME. El ME entonces
agrega un nuevo menú de selección en su estructura de menús y su respectiva comprobación
luego de ser confirmado por el subsiguiente TerminalResponse. Una vez instalado y
activado es posible intercambiar y ejecutar comandos GSM y, tan pronto como el usuario
ingresa en el nuevo menú, el comando Envelope es enviado a la SIM Card con información
sobre el menú seleccionado. La SIM Card confirma la recepción del comando y se da inicio a
una amplia gama de procesos propios de la aplicación SAT y de la interacción con el usuario.
Como se puede apreciar, el SIM Application Toolkit brinda muchas posibilidades a la SIM
Card al expandir sus capacidades de acción mediante la implementación de aplicaciones que
conformen un servicio de valor agregado. Ahora bien, las aplicaciones pueden incrementarse
en su complejidad y puede ocurrir que dichas implementaciones no puedan ser soportadas por
el SAT. Otro obstáculo que puede presentarse específicamente en aplicaciones basadas en
SAT lo constituye la gran diversidad de métodos para presentar datos en pantalla o incluso
detección de incompatibilidades o errores en el ME. Sin embargo, puede decirse con toda
confianza que el SIM Application Toolkit es aún la mejor y más segura manera de implementar
Capítulo 2
39
servicios de valor agregado. Puede ser implementado al sistema existente sin realizar
modificaciones.
Actualmente, un equipo de expertos del EP SCP están en proceso de definir la base para
nuevas aplicaciones para Smart Cards en telecomunicaciones basándose en el SAT. Este
nuevo conjunto será llamado Card Application Toolkit (CAT) y contendrá los elementos
necesarios para el desarrollo de SAT, USIM Application Toolkit (USAT) y de UIM
Application Toolkit (UATK). Estos últimos constituyen nuevos conjuntos de instrucciones
para lo que se ha denominado la SIM Card Universal (USIM) y el nuevo módulo de
identificación universal (UIM).
2.6.2 Comunicación aérea (OTA: Over-The-Air)
Muchas de las aplicaciones que contiene la SIM Card pueden realizarse sin necesidad de
emplear la red GSM para ejecutar un servicio. Sin embargo, muchas veces es necesario
hacerlo y se requiere en primera instancia establecer una conexión directa entre el sistema y la
SIM Card. Este tipo de comunicación resulta esencial para la implementación de diversos
servicios de valor agregado y es por ello que nuevas especificaciones han sido necesarias,
entre ellas destacamos el estándar GSM 03.48, en el cual se definen lineamientos precisos que
tienen como finalidad garantizar un enlace seguro entre el sistema GSM y la SIM Card. De
este modo se cuenta con un mecanismo más robusto ante posibles ataques a la red vía interfaz
aérea. Es importante señalar que estos requerimientos de seguridad no fueron contemplados
del todo en la creación del sistema original GSM, por lo que resulta virtualmente imposible
aplicar esos cambios necesarios al sistema debido a la magnitud de los mismos. Pese a eso,
existen técnicas empleadas para asegurar la confidencialidad entre usuarios finales, así como
nuevos algoritmos de encriptamiento que resguardan la data de los usuarios.
Los mensajes de textos, mejor conocidos como SMS, son una especie de contenedores
para enviar datos desde y hacia la red. Todo lo que se requiere son algunas modificaciones al
sistema a fin de admitir nuevas SIM Cards sin necesidad que realizar cambios a los elementos
Capítulo 2
40
intermediarios. Si bien no es la única forma de comunicación vía aérea, es una de las más
ampliamente usadas. Las comunicaciones aéreas (OTA) ofrecen un amplio repertorio de
mecanismos para proteger la data transmitida. Por ejemplo, el más sencillo consiste en el uso
de una verificación mediante CRC para garantizar la transmisión de datos libre de errores. En
el ámbito de la criptografía, es posible proteger la data mediante el envío de un contador de
secuencia y encriptarlo usando algún algoritmo como por ejemplo DES o 3DES. De ser
necesario puede emplearse una firma digital que puede ser calculada en función de la data
transmitida.
El principio bajo el cual operan los SMS como portadores de servicios consiste en incluir
en el contenido del SMS, el comando que se desea ejecutar dentro de la SIM Card. Este
comando, debidamente encriptado, es enviado (empleando el canal de señalización, en lugar
del canal de tráfico usado para llamadas) tan pronto como el ME se registra en el sistema. La
codificación necesaria para que el ME reconozca que el contenido del SMS corresponde a un
comando a ejecutar está contenida en la especificación GSM 03.40, una vez decodificada se
emplea el comando Envelope para enviarlo desde el ME hacia la SIM Card. En este modo
el mensaje no es automáticamente almacenado en el archivo EFSMS usando el comando
UpdateRecord como suele hacerse, en su lugar la SIM Card guarda el mensaje recibido vía
Envelope en un buffer separado. Si el mensaje forma parte de una cadena de comandos es
necesario que la SIM Card reordene la secuencia pues el envío de SMS no garantiza que los
mensajes sean recibidos en el orden correcto. La SIM Card interpreta el contenido del mensaje
recibido y extrae la información necesaria para procesar el comando, la instrucciones que se
requieren son solicitadas al ME en la respuesta Fetch solicitada por la SIM Card. El ME
atiende la solicitud del comando como si se tratase de una aplicación estándar. Con este
mecanismo es posible establecer una comunicación bidireccional entre el sistema GSM (la
red) y la SIM Card que es completamente transparente a todos los elementos intermediarios.
Una tarea común en comunicaciones aéreas (OTA) es actualizar los número de servicio de
marcado (e.g. números de emergencia o mensajería) almacenados en la SIM Card, aunque
también pueden ejecutarse tareas más complejas como descargar código ejecutable en forma
de código de tamaño reducido elaborados en Java (applets) para aplicaciones
Capítulo 2
41
complementarias en las Java Cards. Pese a la enorme ventaja que ofrece la interfaz aérea
existen ciertas desventajas que han impedido una mayor implementación. Un ejemplo lo
constituye el estándar GSM 03.48 que contiene secciones que no representan una
especificación, es decir, en lugar de ser un estándar con muchas opciones disponibles y
especificadas este no presente mayor detalle en algunos aspectos que pudieran ser
aprovechados por los fabricantes de Smart Cards. Esto trae problemas de compatibilidad entre
diferentes fabricantes de SIM Card que tienen que compensar su desempeño con la ayuda de
librerías en el núcleo del sistema del operador de red que son específicas para cada fabricante
de SIM Card.
2.6.3 Administración Remota de Archivos (RFM)
Los mecanismos suministrados por la interfaz aérea permiten una comunicación directa
entre la SIM Card y el sistema GSM. Esta tecnología de transmisión de datos constituye la
base fundamental para la administración remota de archivos (RFM). Esta funcionalidad está
especificada en el estándar GSM 03.48 y para su implementación requiere condiciones básicas
establecidas en el estándar GSM 02.48.
Es importante señalar que sólo algunos comandos pueden ser usados para la
administración remota de archivos, pese a esta limitación se puede obtener gran funcionalidad.
Estos comandos envían y solicitan datos hacia y desde la SIM Card. Está permitido no sólo el
envío de comandos individuales a la SIM Card a través de la interfaz aérea por parte del
sistema GSM, sino también listas que contengan muchos comandos. Estos comandos listados
suelen estar restringidos al hecho de que sólo el último comando tiene la permisología
suficiente para solicitar datos de la SIM Card, esta restricción esta fundada en la simplicidad
que aporta en el manejo de archivos remotamente en la SIM Card. Debido a esta restricción
muchos mensajes aéreos deben ser enviados a la SIM Card si muchos archivos o registros
tienen que ser leídos.
Capítulo 2
42
El principio bajo el cual funciona el SMS como portador en la administración remota de
archivos se puede explicar con un ejemplo sencillo: Si el sistema GSM desea modificar el
registro de un número almacenado en el archivo EFADM puede hacerlo de la siguiente manera:
En el primer mensaje aéreo (OTA), el cual puede estar integrado por muchos SMS, selecciona
el EFADM usando el comando SelectbyId especificando la ruta de archivo dentro del
directorio DFTELECOM. El último comando dentro de este mensaje aéreo es ReadRecord con
el número de registro conocido por el sistema, el cual permite la lectura del número y su
devolución vía interfaz aérea. En caso de que este número no esté actualizado se envía el
comando UpdateRecord en otro mensaje aéreo con el número correcto a fin de actualizar el
registro previamente consultado.
Como es de esperarse, es necesario tomar ciertas precauciones al manipular archivos
remotamente que pueden modificar datos indispensables para la sesión iniciada. Un típico
ejemplo de tales archivos lo constituye el EFSST el cual contiene la tabla de servicios de la SIM
Card. Esta tabla contiene todos los servicios disponibles y que pueden ser activados en la SIM
Card. Bajo ciertas condiciones, modificar el contenido de este archivo puede causar
comportamientos impredecibles en el ME y en el peor de los casos puede producir un daño
irreparable a la SIM Card.
La SIM Card también contiene dos EF cuya modificación de contenido está prohibida y
esos son: EFICCID el cual almacena el número de identificación de la SIM Card (ICCID), y el
EFKC el cual contiene la clave para encriptar la data transmitida entre el ME y la estación base
(BS) vía interfaz aérea. Desde una perspectiva lógica no tiene sentido modificar estos archivos
puesto que el ICCID es un número de identificación único para la SIM Card y no juega un rol
en la operación normal del ME.
La clave Kc es siempre calculada por la SIM Card para cada sesión por lo que sería
recomendable modificarla vía RFM. Si llega a ser modificada durante el desarrollo de una
sesión, la conexión con la red puede perderse debido a que el ME usaría una clave de
encriptamiento incorrecta para los datos que serán enviando vía interfaz aérea.
Capítulo 2
43
2.6.4 Administración Remota de Applets (RAM)
La administración remota de applets también es posible y los lineamientos para llevarlo a
cabo están especificados en el estándar GSM 03.48, el proceso es muy similar a la
administración remota de archivos. La administración remota de applets hace posible
descargar aplicaciones basadas en Java en Java Cards empleando un enlace directo entre el
sistema GSM y la SIM Card. Un requisito indispensable es que la SIM Card debe ser
compatible con el estándar GSM 03.19, que corresponde en gran parte a los lineamientos de
Java Card 2.1
Todos los comandos relacionados con el manejo de applets y paquetes están basados en
especificaciones de Plataforma Abierta que constituye el estándar de la industria para estos
mecanismos. Estas funciones de administración de aplicaciones incluyen cargar, instalar,
borrar, bloquear y desbloquear Java applets. Mecanismos similares se han establecido para
descargar y borrar paquetes en la SIM Card. Todos los procedimientos son independientes del
servicio que se use como portador, pero el SMS es el más comúnmente usado para el envío de
applets y paquetes en SIM Card vía interfaz aérea. Si el SMS es empleado como portador, la
transmisión y recepción de datos en la SIM Card funciona de la misma manera que se describe
en la administración remota de archivos usando interfaz aérea
Capítulo 3
Metodología de Evaluación
En este capítulo se hace una descripción del sistema y la metodología seguida en el
proyecto. Primero se inicia con una imagen conceptual del proyecto detallando parte de los
pasos que se ejecutaron. La metodología involucra los distintos elementos que formaron parte
del desarrollo del proyecto. Los pasos y etapas del proyecto así como las herramientas
empleadas son piezas claves de este capítulo.
3.1 Descripción del Proyecto
Este proyecto se basa en la evaluación efectiva de los códigos de error a los que se ha
hecho referencia anteriormente. La evaluación de estos comandos se hará mediante la
implementación de un código fuente (scripts) contenidos en SIM Cards, cuya función será la
ejecución sistemática de cada uno de los comandos así como la evaluación de las respuestas
ofrecidas por el ME de acuerdo al manejo de excepción de errores discutido en secciones
previas. Estas respuestas a evaluar constituyen el núcleo del proyecto y corresponden a los
resultados generales (general results) y a los códigos de estado (status codes). Cada uno de
los scripts fue debidamente depurado a fin de obtener una lectura precisa de las respuesta del
ME ante los comandos enviados por la SIM Card.
La depuración se realizó combinando el módulo MobileSimulator presente en el
GemXplore 98 CASE 2.0 con pruebas realizadas en terminales Motorola y de otras marcas
para estudiar respuestas que sólo se pueden obtener de un teléfono real, como por ejemplo el
Capítulo 3
45
IMEI. El módulo MobileSimulator permitió conocer parte del APDU que se efectuaba entre
el script de la SIM Card y un equipo móvil ideal simulado dentro del SDK. Este simulador
facilitó el reconocimiento de comandos que eran enviados al simulador y su interpretación
correspondiente. Debido a que el módulo ScriptEditor en donde se realiza la edición del
código no posee un depurador (debugger), la adopción de pruebas con el simulador, las
pruebas con equipos móviles reales y el uso del Motorola RTA compensaron la ausencia de
esta importante herramienta que debe tener todo SDK.
Luego de la evaluación metódica de cada una de las instrucciones y su correcta
implementación se procedió a ensamblar una aplicación que englobara todos los comandos.
Esta aplicación organizada en menús con la ayuda del módulo MenuEditor del GemXplore
98 CASE 2.0, contendría los scripts necesarios para evaluar los comandos de forma continua.
Esta modalidad fue adoptada debido a la gran cantidad de comandos a evaluar y para ayudar
a disminuir el tiempo de ejecución de las pruebas. Esta versión lleva por nombre GSM
Standard Tester y constituye la versión integral que contiene las pruebas de los comandos
básicos GSM y los comandos proactivos.
Posteriormente, en plena ejecución de las pruebas en los equipos móviles, se pudo
apreciar que algunos de éstos no entendían el comando que la SIM Card les estaba enviando.
Este hecho provocaba que el ME abortara la ejecución del script impidiendo continuar con la
evaluación de los subsecuentes comandos. En virtud de este comportamiento en muchos ME
fue necesaria la creación de otra versión que permitiera la evaluación por separado de cada
comando. Esta versión, debido a su estructura, presentó limitaciones a causa del gran número
de menús desplegados por lo que sólo se pudo considerar la inclusión de comandos
proactivos. Esta versión lleva por nombre GSM Modular Tester y constituye la versión
modular de las pruebas de los comandos proactivos.
Capítulo 3
46
3.2 Metodología
El procedimiento metódico a seguir para la implementación del proyecto comprende el
uso de elementos de programación así como de herramientas de software. El elemento clave
en la resolución del problema parte de la comprensión del conjunto de instrucciones así como
de su respectivo manejo de excepción de errores.
3.2.1 Conjunto de Instrucciones
El desarrollo de esta herramienta automatizada para las pruebas de compatibilidad con los
estándares GSM 11.11 y 11.14 se llevó a cabo mediante la implementación de un software
realizado en un lenguaje de macros llamado GemXplore Macro Assembly Language que es
muy similar al lenguaje ensamblador empleado en algunos microcontroladores. Existen
instrucciones propias del estándar que el GemXplore 98 CASE 2.0 no incluye en su conjunto
de instrucciones y por lo tanto son imposibles de evaluar. Sin embargo, debido a su
naturaleza fundamental estos pocos comandos hacen posible que el ME sea capaz de realizar
operaciones básicas. Estas instrucciones que el SDK no considera se listaran oportunamente.
Este conjunto de instrucciones está integrado por comandos que pertenecen a dos
estándares distintos. El estándar GSM 11.11 describe comandos básicos GSM así como otros
lineamientos, los cuales en teoría no deberían presentar problemas, ya que formaron parte del
diseño original del sistema GSM y su correcta implementación es fundamental para el
desempeño de las operaciones más elementales del equipo móvil (ME). Por otra parte existen
comandos que fueron implementados posteriormente y que en su adopción presentan
problemas de compatibilidad. Estos comandos corresponden al estándar GSM 11.14 y en las
siguientes secciones discutiremos como, a través del manejo de excepción de errores del SDK,
podremos verificar su compatibilidad.
Existen básicamente dos clases de comandos con los cuales trabaja una SIM Card, existen
otros que son propios del SDK y que sirven como facilitadores de operaciones como aquellos
Capítulo 3
47
que se emplean para realizar cálculos aritméticos, manejo de datos, funciones administrativas,
etc. El SDK empleado llama a estas funciones “macros” y pueden ser usadas en el script para
diseñar y crear una determinada aplicación. Estas macros pueden clasificarse en grupos
funcionales los cuales se muestran a continuación:
• Macros administrativas
• Macros GSM
• Macros aritméticas
• Instrucciones
• Manejo de datos
• Macros proactivas
• Macros para doble ranura (dual slot)
• Macros para el manejo de rutinas
• Manejo de excepción de errores
• Macros lógicas
• Administración de archivos
3.2.1.1 Comandos Básicos GSM
Los comandos básicos GSM definidos en el estándar GSM 11.11 son fundamentales
para algunas de las operaciones realizadas por el sistema GSM. Estos comandos en su
mayoría no presentan problemas de incompatibilidad pero están especificados en el
estándar y es necesario verificar su correcta implementación. Estas instrucciones están
principalmente orientadas a trabajar con la información presente en la SIM Card y su
interacción con el ME en procesos de búsqueda y actualización. Algunos retornan
información adicional que resulta útil en la verificación del comando. No todos los
comandos básicos están disponibles en el entorno de desarrollo. Estos comandos básicos
que se omiten en el conjunto de instrucciones del GemXplore 98 CASE 2.0 son: Verify
CHV, Change CHV, Disable CHV, Enable CHV, Unblock CHV, Run GSM
Algorithm, Sleep, Terminal Profile, Envelope, Fetch y Terminal
Response.
El conjunto de instrucciones disponibles en el SDK para el estándar GSM 11.11 que
corresponde a los comandos básicos se muestra en la Tabla Nº 1
Capítulo 3
48
SelectbyId
Seek
Status
UpdateRecordbyMode
UpdateBinary
GetResponse
UpdateRecordbyModeData
UpdateRecord
ReadBinary
UpdateRecordbyNum
Increase
ReadRecordbyNum
UpdateRecordbyNumData
Invalidate
ReadRecordbyOffset
UpdateRecordbyOffset
Rehabilitate
ReadRecordbyMode
Tabla Nº 1: Comandos básicos GSM presentes en el SDK
Estos comandos realizan diversas tareas con los archivos de la SIM Card y cada uno
de ellos trabaja con clases específicas de archivos. La Tabla Nº 2 muestra el (los) tipo(s)
de archivo(s) con los que trabaja cada función.
Comando
MF
DF
EF transparente
EF lineal fijo
EF cíclico
SelectbyId
Status
ReadBinary
UpdateBinary
ReadRecord
UpdateRecord
Seek
Increase
Invalidate
Rehabilitate
Tabla Nº 2: Tipos de archivo con los que trabaja cada función
Capítulo 3
49
3.2.1.2 Comandos Proactivos
Los comandos proactivos surgieron con el desarrollo del SIM Application Toolkit
(SAT) y constituyen un conjunto de instrucciones que le permiten a la SIM Card ejecutar
instrucciones propias del ME. Estos comandos debidos a su tardía implementación suelen
presentar problemas de compatibilidad entre los principales fabricantes de equipos
móviles. Los comandos que integran el conjunto de instrucciones proactivas son:
• Refresh
• DisplayText
• CompleteSendSMS
• GetInkey
• SendSMS
• MoreTime
• SetUpMenu
• PlayTone
• ProvideLOCI
• DefaultPlayTone
• SelectItem
• PollInterval
• GetInput
• PollingOff
• CompleteSetUpCall
• CompleteSendSS
• SetUpCall
• SendSS
Algunos comandos, como los que aparecen subrayados, requieren de acceso a la red
GSM local para poder ser evaluados. Estos comandos permiten el envío de mensajes de
texto, así como la ejecución de llamadas. Para poder acceder a la red GSM se requieren
de algunos parámetros para poder identificar la SIM Card con la red, estos parámetros
son propios de la operadora local GSM. Debido a la imposibilidad de obtener estos
parámetros durante la ejecución del proyecto, estos seis comandos de red no pudieron ser
evaluados. Sin embargo, fueron programados a fin de que a futuro se puedan evaluar
debidamente.
Los detalles correspondientes a los parámetros de cada instrucción así como el
resultado que debe producir se pueden encontrar en los estándares GSM 11.11 y GSM
11.14 correspondientes a los Apéndices B y C que se ofrecen en el CD que acompaña al
presente libro.
Capítulo 3
50
3.2.2 Manejo de Excepción de Errores
El manejo de excepción de errores es un concepto que engloba los diversos
mecanismos de depuración de un programa a fin de detectar errores en la ejecución de un
determinado comando. En este sentido los estándares GSM definen un conjunto de
códigos que devuelve el ME a fin de conocer si una instrucción es ejecutada
correctamente. Tradicionalmente, un programador puede evaluar la validez del resultado
de dicha instrucción pero esto no suele ser muy preciso. Para manejar este tipo de
situaciones se suelen emplear dos estrategias: a) Incluir el código del error en la respuesta
de la instrucción y b) Emplear una variable global que reporte el estado del error.
En ambos casos es necesario verificar si ha ocurrido un error y preverlo a fin de
generar la acción apropiada. El programador debe revisar si ha ocurrido un error, y en ese
caso predecir una acción apropiada que lo maneje. Esto puede ser muy útil porque la
calidad del programa aumenta en virtud de la robustez que puede generarse ante posibles
errores graves. En general, estos programas suelen tener casi la mitad de su código
destinado a la revisión de los resultados ofrecidos por las funciones. Lamentablemente,
estos programas tienden a ser complicados y bastante difíciles de seguir, por lo que la
alternativa es descartar algunos errores considerados como “tontos” a fin de darle
prioridad a los errores más severos.
El uso de excepciones se ha difundido en entornos de programación más recientes y
constituyen una eficiente alternativa para el manejo de errores. Cuando se produce un
error se genera una excepción y el sistema fuerza un salto hacia el bloque de excepciones
más cercano, el cual toma las acciones apropiadas para alertar o solventar el error
producido. El sistema consta de un “manejador” estándar por defecto que toma todas las
excepciones y que muestra los mensajes de error, deteniendo la ejecución del programa.
Este manejo de excepción de errores es propio de lenguajes de programación de alto
nivel. En este caso con el GemXplore Macro Assembly Language se dispone de una serie
de códigos que pueden ser consultados para verificar la correcta ejecución de la macro.
Capítulo 3
51
Estos códigos pueden evaluarse valiéndose de instrucciones como Keep dentro del
GemXplore 98 CASE 2.0 o haciendo uso de la pila (stack) de la SIM Card.
Esta modalidad de analizar los códigos de error no es automatizada pero nos ofrece la
posibilidad de verificar si el comando ha sido entendido por el dispositivo móvil. Este
hecho es muy importante a considerar puesto que la ejecución correcta de una instrucción
“no necesariamente implica que esa instrucción este debidamente implementada” de
acuerdo a los estándares antes mencionados. De modo que, estos códigos de error son una
herramienta que nos ayudará a verificar si el ME está o no entendiendo el comando, en
caso de que sea entendido es necesario verificar si cumple con los lineamientos y
especificaciones pertinentes.
3.2.2.1 Resultados Generales
Los resultados generales (general results) son los códigos que, valga la redundancia,
especifican el resultado de la acción de un comando proactivo, este código es devuelto
por el ME y suele estar acompañado por información adicional relacionada con el
comando en cuestión. En la Tabla N° 3 se describen los resultados generales
especificados en el estándar GSM 11.14:
Códigos
Definiciones
00
Comando ejecutado exitosamente.
01
Comando ejecutado con comprensión parcial.
02
Comando ejecutado con pérdida de información.
20
ME incapaz de procesar el comando en estos momentos.
21
Red incapaz de procesar el comando en estos momentos.
22
Usuario no aceptó solicitud de llamada.
Capítulo 3
52
23
Usuario terminó llamada antes de establecer o liberar conexión.
30
Comando más allá de las capacidades del ME.
31
Tipo de comando no entendido por el ME.
32
Data del comando no entendida por el ME.
33
Número de comando desconocido para el ME.
34
35
Error en retorno de SS.
SMS RP-ERROR.
36
Error, valores requeridos no se hallan presentes en el comando.
Tabla N° 3: Resultados Generales especificados en el estándar GSM 11.14
Todos los demás valores deben ser tratados de acuerdo al código de error “20”. En
forma general, los valores representados por 0X y 1X indican que el comando ha sido
ejecutado. El estándar no define los comandos 1X como los que aparecen en la Tabla N°
3 pero pueden aparecer. Sin embargo hay una diferencia notable, el primero indica que se
completó la ejecución del comando y el segundo garantiza que sólo se ejecutó pero no se
puede determinar si fue completamente. En este sentido, los códigos del tipo 1X ofrecen
la alternativa de poder recuperarse de la acción del ME valiéndose de acciones como:
Abort, No response o Backwards.
Aquellos que son de la forma 2X indican que la SIM Card podría intentar el comando
en otra oportunidad, esto suele deberse a congestión en la red o problemas en la
arquitectura del ME. Finalmente aquellos que son de la forma 3X señalan que, no importa
cuantas veces la SIM Card ejecute el comando, siempre se obtendrá el mismo error y la
decisión de seguir reintentando el comando corresponde a la aplicación.
Cuando uno de estos errores ocurre lo más probable es que se intente de nuevo un
cierto número de veces según el dispositivo móvil, o bien detener completamente la
ejecución del script.
Capítulo 3
53
3.2.2.2 Códigos de Estado
Los códigos de estado (status codes) son los códigos generados por el sistema de
manejo de excepción de errores para los comandos básicos GSM. Estos son generados
por la instrucción Keep del SDK que arroja el código de estado correspondiente a la
instrucción GSM que se está ejecutando en ese momento. Este código ofrece mucha más
información que los resultados generales aplicados a los comandos proactivos. Estos
códigos de estados son mejor conocidos dentro del estándar como condiciones de estado
(status conditions) y están compuestos por dos bytes conocidos como SW1 y SW2
(Status Word 1, Status Word 2) en lugar de sólo uno como ocurre con los resultados
generales. Estos códigos se clasifican según la naturaleza del error.
La Tabla N° 4 corresponde a los códigos de estado que aparecen en respuesta a
comandos ejecutados correctamente. La Tabla N° 5 corresponde a los códigos de estado
producidos en respuesta a comandos cuya ejecución ha sido pospuesta para un próximo
intento. La Tabla N° 6 corresponde a los códigos de estado que indican problemas
vinculados al manejo de memoria. La Tabla N° 7 muestra los códigos de estado que
indican problemas vinculados al manejo de referencias y direccionamiento. La Tabla N°
8 contiene los códigos de estado vinculados a problemas de seguridad y la Tabla N° 9
especifica los códigos de estado en respuesta a errores independientes de la aplicación.
SW1 SW2
Definición
90 00
Comandos ejecutado correctamente.
91 XX
Comando ejecutado correctamente con información extra disponible
y de longitud XX.
9E XX
Respuesta de datos de longitud XX ofrecida en caso de error en
descarga de datos de la SIM Card.
9F XX
Respuesta de datos de longitud XX.
Tabla N° 4: Códigos de estado en respuesta a comandos ejecutados correctamente
Capítulo 3
54
SW1 SW2
93 00
Definición
SIM Application Toolkit está ocupado. El comando no puede ser
ejecutado en estos momentos. Otros comandos normales están
permitidos.
Tabla N° 5: Códigos de estado producidos en respuesta a comandos cuya ejecución ha
sido pospuesta
SW1 SW2
92 0X
Definición
Comando ejecutado exitosamente pero luego de usar una rutina
interna para reintentar X veces.
92 40
Problema de memoria.
Tabla N° 6: Códigos de estado vinculados a problemas en el manejo de memoria
SW1 SW2
Definición
94 00
No se ha seleccionado un EF.
94 02
Dirección inválida o fuera de rango.
94 04
ID del archivo no encontrado / Patrón no encontrado.
94 08
Archivo es inconsistente con el comando empleado.
Tabla N° 7: Códigos de estado vinculados a problemas en el manejo de referencias
Capítulo 3
55
SW1 SW2
Definición
98 02
CHV (PIN) no inicializado.
98 04
Condición de acceso no satisfactoria, Verificación del CHV fallida,
quedando al menos un intento, Verificación del UNBLOCK CHV
fallida quedando sólo un intento.
98 08
Contradicción con el status de CHV.
98 10
Contradicción con el estado de invalidación.
98 40
Verificación del CHV fallida, no quedan más intentos, CHV
bloqueado, UNBLOCK CHV bloqueado.
98 50
Increase no puede ser ejecutado, valor máximo alcanzado.
Tabla N° 8: Códigos de estado vinculados a problemas de seguridad
SW1 SW2
Definición
67 XX
Parámetro P3 incorrecto.
6B XX
Parámetro P1 o P2 incorrecto 3 4.
6D XX
Código de instrucción desconocido ofrecido por el comando 3.
6E XX
Tipo de instrucción ofrecida por el comando está equivocada 3.
6F XX
Problema técnico sin diagnóstico ofrecido 3.
Tabla N° 9: Códigos de estado en respuesta a errores independientes de la aplicación
3
El valor XX está debidamente especificado por ISO/IEC, sin embargo para aquellos sin especificar se
asumirá el valor XX = 00.
4
El error suele deberse a un almacenamiento de registro fuera de rango y en tales casos es necesario
emplear el código 94 02 para indicar este error.
Capítulo 3
56
3.3.Herramientas empleadas en el desarrollo del Proyecto
Las herramientas empleadas en el desarrollo de la aplicación comprenden elementos
tanto de software como hardware. Los elementos de hardware comprenden los equipos
electrónicos tales como una computadora personal (PC) (Intel Pentium III Mobile CPU
1.20 GHz / 512 MB RAM con Microsoft Windows XP® SP1), una lectora de tarjetas
inteligentes (SmartCard Reader GemPC410 de Gemplus) y las SIM Card vírgenes de
pruebas de Gemplus (nativas de 32KB), etc.
En tanto que los elementos de software comprenden el entorno de desarrollo (SDK)
que corresponde al GemXplore98 CASE 2.0, aplicaciones para la “personalización de un
equipo móvil” como el Mobile PhoneTool de Motorola y aplicaciones para el rastreo de
código en la comunicación entre la SIM Card y el ME, como el Motorola RTA que
realiza tareas de rastreo de datos (data logging)
En conjunto, estas herramientas facilitaron y permitieron el diseño y desarrollo del
proyecto, siendo un software el producto final que se entregará en dos modalidades en
diferentes SIM Cards. Cada modalidad permite la ejecución de las pruebas en dos
versiones distintas: una integral en donde se realizan las pruebas de los comandos de
forma secuencial y otra modular en donde las pruebas se realizan de forma puntual.
• Versión Integral (GSM Standard Tester): esta versión del software permite la
ejecución continua de los comandos básicos GSM así como de los comandos
proactivos. El menú de la aplicación ofrece dos alternativas a fin de escoger el tipo
de prueba a realizar, la cual se hará de forma ininterrumpida y no se podrá abortar
(en virtud de que se trata de un sólo script). En la Fig. 16 puede apreciarse la
ubicación del software dentro del ME, así como los elementos que lo componen.
Capítulo 3
57
Fig. 16 Vista de la aplicación GSM Standard Tester desarrollada
• Versión Modular (GSM Modular Tester): esta versión del software permite la
ejecución puntual de los comandos proactivos solamente. El hecho de no poder
incluir los comandos básicos GSM se debe a limitaciones en memoria, de la cual
sólo se dispone de aproximadamente 20 KB para nuestro código. Las restricciones
impuestas a cada menú en función del número de elementos y el tamaño de cada
uno de ellos obligó a adoptar un esquema de árbol a fin de lograr incluir todas las
funciones proactivas, que a fin de cuentas constituyen las instrucciones que
presentan mayores problemas de compatibilidad. Por esta razón todo el código se
subdividió en módulos y submódulos que agrupan todas las instrucciones proactivas
evaluadas en la modalidad Integral. Existen tres módulos principales: GSM
Modular 1, GSM Modular 2 y GSM Modular 3 que a su vez agrupan submódulos
llamados: Proactives 1,..., Proactives 9. En la Fig. 17 se aprecia la ubicación del
software dentro del ME, así como los elementos que lo componen.
Fig. 17 Vista de la aplicación GSM Modular Tester desarrollada
Capítulo 3
58
Cada una de las versiones ejecuta las mismas pruebas y emplean la codificación de
errores antes referida. La versión global lleva por nombre: GSM Standard Tester y la
versión modular lleva por nombre: GSM Modular Tester. Para esta última versión se
muestra a continuación la lista por módulos de los comandos presentes. La Tabla N° 10
muestra los menús que integran al GSM Modular 1, en la Tabla N° 11 se muestran los
menús correspondientes al GSM Modular 2 y finalmente la Tabla N° 12 define el menú
contenido en GSM Modular 3.
Menú
Comandos contenidos
Proactives 1
PlayTone (Dial tone, Caller subscriber busy, Congestion, Radio
pack acknowledgement).
Proactives 2
PlayTone (Radio path not available/Call dropped, Error/Special
Information, Call waiting tone, Ringing tone).
Proactives 3
PlayTone (General Beep, Positive acknowledgement, Negative
acknowledgement or error tone), MoreTime.
Proactives 4
GetInkey (Digits only, SMS alphabet), GetInput (Digits only +
Echo user input + Unpacked format).
Proactives 5
GetInput (SMS alphabet + Echo user input + SMS packed format,
Digits Only + User input not revealed + Unpacked format),
DefaultPlayTone, PollInterval.
Tabla N° 10: Comandos presentes en el menú GSM Modular 1
Menú
Proactives 6
Comandos contenidos
DisplayText (Normal priority, High priority, Clear after delay,
Wait for user to clear message).
Capítulo 3
59
Proactives 7
SelectItem, SetUpMenu, SetUpCall,
CompleteSetUpCall, SendSMS, CompleteSendSMS,
SendSS, CompleteSendSS5.
Proactives 8
ProvideLOCI, PollingOff.
Proactives 9
Refresh (SIM Initialization and Full File Change Notification, File
Change Notification, SIM Initialization and File Change Notification,
SIM Initialization).
3.3.1 GemXplore 98 CASE 2.0
El GemXplore 98 CASE 2.0 de Gemplus es el entorno de desarrollo empleado para la
elaboración del proyecto. Este SDK cuenta con diversos módulos de desarrollo que
permiten el diseño, implementación y simulación del proyecto. Su instalación se llevó a
cabo sobre una máquina virtual que pudiese contener un sistema operativo compatible
con sus requerimientos. El sistema operativo (OS) instalado fue Microsoft Windows 98
SE®. Una vez instalado el sistema operativo dentro de la máquina virtual se procedió a
instalar el paquete de software (case) GemXplore 98 CASE 2.0 de Gemplus.
La necesidad de instalar la máquina virtual se debe a que la PC presente en las
instalaciones de Motorola posee sistema operativo Windows XP. El case no está apto
para ser instalado en ese sistema operativo.
5
Los comandos en color rojo no pudieron ser implementados. Se requiere de acceso a la red GSM local
para evaluar su programación.
Capítulo 3
60
3.3.1.1 Módulos
El GemXplore 98 CASE 2.0 posee diversos módulos para el diseño y desarrollo de
aplicaciones para SIM Card. Entre esos módulos que integran el SDK destacan por su uso
para este proyecto:
• SIM Explorer: el cual permite la exploración del árbol de archivos de la SIM así
como la administración del contenido de los mismos. Permite la creación de
imágenes de tarjetas a fin de guardar archivos de la SIM Card en la PC. En la Fig.
18 puede apreciarse el módulo SIM Explorer así como el sistema de archivos de una
SIM Card.
Fig. 18 Módulo SIM Explorer y el sistema de archivos de una SIM Card
• MenuEditor: es un editor de sencillo uso que permite la creación de aplicaciones
SIM Toolkit independientes mediante interfaz gráfica. Permite también administrar
el llamado a subrutinas y servicios mediante la creación de submenús. En la Fig. 19
puede apreciarse el proyecto organizado en menús dentro del módulo.
Capítulo 3
61
Fig. 19 Módulo MenuEditor y proyecto englobado en menús
• ScriptEditor: permite crear aplicaciones más detalladas y complejas mediante el uso
del GemXplore Macro Assembly Language, este lenguaje se basa en el uso de
macros pertenecientes al conjunto de instrucciones del GemXplore 98 CASE 2.0.
No sólo permite la creación de procesos SIM sino también de script residente y
contenidos de mensajes ESMS v1 y ESMS v2. En la Fig. 20 puede apreciarse parte
del código fuente (script) desarrollado en este módulo.
Fig. 20 Módulo ScriptEditor y parte del código fuente elaborado
Capítulo 3
62
• MobileSimulator: simula un teléfono ideal ejecutando los comandos previamente
compilados y descargados a la SIM Card. Cuenta con opciones de rastreo de datos
(data logging), así como de grabación de secuencia como se muestra en la Fig. 21.
Fig. 21 Módulo MobileSimulator
3.3.1.2 Programación
En el módulo SIM Explorer podemos crear algunos archivos necesarios para la
implementación de algunos comandos básicos GSM y proactivos. Debido a que algunos
comandos trabajan exclusivamente con cierto tipo de archivos como se evidencia en la
Tabla N° 13, fue necesaria la creación de los siguientes archivos:
Dirección
Tipo
Función
7F20/6F52
Transparente
Creado para trabajar con lectura binaria.
7F20/6F53
Transparente
Creado para hacer las veces de buffer.
7F20/6F54
Transparente
Creado para procesar cadenas de datos.
Capítulo 3
63
7F20/6F55
Lineal fijo
7F20/6F56
Cíclico
Creado para ser usado con instrucciones de registros.
Creado para evaluar la instrucción Increase.
Tabla N° 13: Archivos extras creados para evaluar los comandos
3.3.2 Motorola RTA
El programa Motorola RTA es un analizador en tiempo real (Real Time Analyzer) que
se emplea para adquirir, salvar, reproducir y analizar diferentes tipos de datos presentes
en un ME Motorola. Esta data puede ser originaria del proceso de rastreo de datos (data
logging) que consiste en el monitoreo discreto del tráfico de datos entre la PC y el ME o
bien, dentro del mismo móvil. También es capaz de hacer mediciones de voltaje y
corriente en algunos componentes del hardware del equipo. Se empleó para estudiar
parte del APDU durante el arranque de la SIM Card y luego en la transformación del
resultado arrojado por la instrucción ProvideLOCI.
Capítulo 4
Resultados Obtenidos
En este capítulo se presentan los resultados obtenidos en las pruebas efectuadas a los
diferentes equipos empleando la herramienta desarrollada, así como un breve análisis y
explicación de los mismos. Las tablas muestran los resultados y la comparación entre ellos en
función del grado de compatibilidad. El capítulo también expone un breve análisis estadístico
que permite conocer el porcentaje de incidencia de determinadas fallas en algunos equipos.
Con el propósito de proteger información confidencial de Motorola se optará por definir
cuatro equipos móviles llamados: Móvil A, Móvil B, Móvil C y Móvil D.
Cada móvil fue sometido a las mismas pruebas ya que usaron la misma SIM Card
programada con la versión integral GSM Standard Tester. En algunos casos, debido a que un
equipo móvil no entendió el comando y abortó la ejecución de la aplicación, se utilizó la
versión modular GSM Modular Tester a fin de completar la prueba de los comandos
subsecuentes. Detalles del funcionamiento del programa pueden encontrarse en el Manual del
Usuario presente en el Apéndice A y en el CD que acompaña a este libro.
Capítulo 4
65
4.1 Comandos Básicos GSM
Se observó un desempeño exitoso en los comandos básicos GSM. Todos los móviles no
presentaron problemas de compatibilidad con el estándar GSM 11.11. Esto podía predecirse
debido a que estos comandos no pertenecen al SIM Application Toolkit como tal y su
implementación formó parte del diseño original del sistema GSM. Los resultados de las
pruebas en cada uno de los móviles se observan en la Tabla N° 14.
Comandos Básicos GSM (GSM 11.11)
Móvil A
Móvil B
Móvil C
Seek
Status
GetResponse
Invalidate
Rehabilitate
ReadBinary
UpdateBinary
UpdateRecord
ReadRecordbyMode
ReadRecordbyNum
ReadRecordbyOffset
UpdateRecordbyMode
UpdateRecordbyNum
SelectbyId
Increase
Tabla N° 14: Resultados de las pruebas de los comandos básicos GSM
Móvil D
Capítulo 4
66
4.2 Comandos Proactivos
Los resultados de las pruebas de los comandos proactivos en cada uno de los móviles
pueden apreciarse en la Tabla N° 15. Sólo el móvil D pudo ejecutar todos los comandos sin
presentar errores de compatibilidad. La mayoría de los errores corresponden a fallas en el
comando PlayTone, en el Manual de Usuario se incluye una tabla extraída del estándar
GSM 02.40 (ver Apéndice D en CD) donde se especifican la duración, frecuencia y tipo de
tono que debe escucharse en cada uno de los ocho modos supervisados de esta instrucción. Se
observó una falla del comando Refresh en el Móvil B y del comando MoreTime en el
Móvil A, esta falla se manifiesta en el aborto de la ejecución de la aplicación. Para continuar
con las pruebas en estos equipos se empleó la versión modular. En todos los equipos salvo en
el Móvil D se observó una falla en el comando GetInput en modo Digits only + User input
not revealed + Unpacked format, esta falla se manifiesta al revelar en pantalla la tecla
presionada por breves instantes antes de sustituirla por * (asterisco), según se especifica en el
estándar GSM 11.14. El comando DisplayText en modo Clear after delay no funciona en
los móviles B y C por lo que el usuario debe presionar la tecla OK.
En la Tabla N° 16 se muestran los porcentajes de compatibilidad de cada uno de los
móviles sometidos a las pruebas.
Comandos Proactivos (GSM 11.14)
Móvil
A
Móvil
B
Móvil
C
Refresh (SIM Initialization and Full File Change
Notification)
Refresh (File Change Notification)
Refresh (SIM Initialization and File Change
Notification)
Refresh (SIM Initialization)
Refresh (SIM Reset)
ProvideLOCI (IMEI)
DefaultPlayTone
PlayTone (Dial Tone)
PlayTone (Caller subscriber busy)
Móvil
D
Capítulo 4
67
PlayTone (Congestion)
PlayTone (Radio path acknowledge)
PlayTone (Radio path not available/Call dropped)
PlayTone (Error/Special Information)
PlayTone (Call waiting tone)
PlayTone (Ringing Tone)
PlayTone (General Beep)
PlayTone (Positive acknowledgement tone)
PlayTone (Negative acknowledgement or error tone)
MoreTime
GetInkey (Digits only)
GetInkey (SMS alphabet)
GetInput (Digits only + Echo user input +
Unpacked format)
GetInput (SMS alphabet + Echo user input + SMS
packed format)
GetInput (Digits only + User input not revealed +
Unpacked format)
PollInterval
PollingOff
DisplayText (Normal priority)
DisplayText (High priority)
DisplayText (Clear after delay)
DisplayText (Wait for user to clear message)
SelectItem
SetUpMenu
SetUpCall
CompleteSetUpCall
SendSS
CompleteSendSS
SendSMS
CompleteSendSMS
Tabla N° 15: Resultados de las pruebas de los comandos proactivos
= Implementadas pero sin funcionalidad ya que dependen del acceso a la red GSM local
Capítulo 4
68
Equipo móvil
Número de comandos errados
Porcentaje de compatibilidad (%)
Móvil A
5
84,37
Móvil B
10
68,75
Móvil C
4
87,50
Móvil D
0
100,00
Tabla N° 16: Porcentaje de compatibilidad por equipo móvil
Los resultados señalan que gran parte de los equipos sometidos a las pruebas corresponden
a errores en un mismo comando. Esto puede implicar que los equipos móviles estudiados
comparten el mismo software interno. Sin embargo, para estas pruebas los equipos móviles A,
B, C y D poseen distinto software. La comparación porcentual obtenida pone de manifiesto no
sólo que la mayoría de los teléfonos implementa cerca del 70% de los comandos
correctamente, sino que muy pocos teléfonos logran ser completamente compatibles con el
estándar.
El manejo de excepción de errores que ofrecen ambos estándares permite conocer la
respuesta que ofrece el ME. Sin embargo esto no garantiza que el comando interpretado se
ejecute correctamente según el estándar, por lo que es necesario un conocimiento detallado de
las especificaciones vinculadas por parte del usuario de la aplicación.
Los resultados preeliminares de las pruebas efectuadas en los teléfonos de Motorola como
en los de la competencia han demostrado ser fiables y acordes a la programación de la SIM
Card siendo este el principal argumento, junto con los lineamientos del estándar, que da
soporte a los resultados obtenidos. El código ha sido verificado con el simulador del SDK que
presenta el comportamiento ideal de un ME ante la ejecución de los respectivos comandos.
Capítulo 5
Conclusiones y Recomendaciones
Cada vez más la SIM Card adquiere un papel más relevante en el proceso de globalización
de las telecomunicaciones y como parte de un sistema de telefonía ampliamente difundido
como los es el GSM. La correcta implementación de los estándares con relación a la SIM Card
se traduce en equipos móviles de mayor calidad. La compatibilidad con los estándares asegura
la versatilidad del producto con muchos de los servicios de valor agregado de las operadoras.
Un mejor desempeño de los equipos Motorola significa un incremento en el número de
equipos homologados por las operadoras locales y por ende, un aumento en las ventas.
5.1 Conclusiones
Es importante que cada uno de los equipos móviles de Motorola que están siendo
implementados por cada una de las operadoras este libre de errores. La naturaleza del error es
diversa pero con este proyecto se propuso detectar oportunamente problemas de
compatibilidad del ME con los estándares GSM 11.11 y 11.14.
El esfuerzo empleado en el desarrollo de una herramienta automatizada para detectar
problemas de compatibilidad con los estándares GSM 11.11 y 11.14, se ha visto
recompensado con el éxito logrado en las pruebas efectuadas. El desarrollo de esta
herramienta implicó el estudio de los estándares señalados, así como un estudio del lenguaje
Capítulo 5
70
de programación GemXplore Macro Assembly Language que, pese a las limitaciones del SDK
que se señalaron en capítulos anteriores, permitió la implementación de todas las instrucciones.
Se lograron evaluar un total de diecinueve comandos básicos GSM y de treinta y dos
comandos proactivos. Quedaron por evaluar seis comandos proactivos que requieren de acceso
a la red GSM local y, aunque fueron programados, no pueden ser evaluados por las razones
previamente expuestas.
En virtud de la diversidad de respuestas ofrecidas por los equipos móviles, se desarrollaron
dos versiones de la aplicación que permiten un mayor grado de flexibilidad a los usuarios.
Cada una de las aplicaciones fue descargada a una SIM Card para ser usadas por el personal
de la empresa OMEGA DB Software & Services. Las SIM Cards vienen acompañadas por un
Manual de Usuario, presente en el Apéndice A, que ilustra el funcionamiento de cada uno de
los comandos, así como de los resultados esperados. Muchos de estos resultados deben ser
estudiados con la ayuda de los estándares respectivos.
El producto final ha detectado errores importantes que han sido reportados y verificados en
muchos equipos incluyendo modelos de la competencia. Cada una de estas fallas presentes en
los equipos de Motorola así como en los de la competencia, se omiten en favor de mantener la
confidencialidad de los resultados. Esta herramienta ahora se suma al arsenal de las
aplicaciones destinadas al control de calidad de los productos GSM de Motorola.
5.2 Recomendaciones
A fin de garantizar la continuidad en el mejoramiento de las pruebas de calidad de los
equipos Motorola, es necesario promover la extrapolación de estas pruebas a otros estándares
del sistema GSM que así lo requieran. Entre las recomendaciones propuestas luego del
desarrollo del proyecto “Diseño de un sistema automatizados de pruebas para los estándares
GSM 11.11 y 11.14” se tienen:
Capítulo 5
71
1. Es necesario que las personas destinadas a realizar las pruebas y emplear el software
estén familiarizadas con los lineamientos de los diversos estándares involucrados, a fin
de detectar oportuna y eficazmente los problemas de compatibilidad que se produzcan
en los dispositivos.
2. Como proyecto a futuro sería útil contar con una infraestructura que permita el envío
de los resultados a una base de datos vía SMS a fin de poder administrar mejor los
diferentes resultados y por ende minimizar el tiempo de respuesta.
3. La adopción de SIM Cards con tecnología Java (Java Cards) permitiría el empleo de
herramientas de desarrollo (SDK) más sofisticadas. Además de disponer de tarjetas con
mayor capacidad de almacenamiento a fin de poder realizar tareas más complejas.
4. Definir un plan piloto para las pruebas de los terminales que, en forma metodológica,
permita una supervisión constante. La obtención de un reporte detallado por parte del
personal de OMEGA DB Software & Services, permitirá conocer el estado de cada
modelo y su compatibilidad, de esta forma las pruebas empleadas con esta herramienta
pasarán a formar parte del plan de pruebas ya implementado.
Referencias
[1]
Motorola de Venezuela, 15 de septiembre de 2004
http://venezuela.mot.com
[2]
PFE LatinAmerica
http://lapfe.mot.com/lapfe
[3]
PFE Tools
http://lapfe.mot.com/lapfe/Tools/tools.html
[4]
Downloads & Tools from Sun Microsystem
http://developers.sun.com/techtopics/mobility/allsoftware
[5]
Telcel Costa Rica – GSM
http://telcel-gsm.com/pages/gsmCostaRica.htm
[6]
Gemplus’ products, solutions and services
http://www.gemplus.com/
[7]
RTA Home Page
http://pcstls.sps.mot.com/rta_unsecure/static/
[8] Smart Card Standards
http://www.ttfn.net/techno/smartcards/
[9] 3GPP Specification Details
http://www.3gpp.org/ftp/Specs/html-info/1110-4.htm
[10] Mobile SIM Tool Kit
http://www.ec-mobile.ust.hk/mobile/toolkit.htm
[11] Vodafone SIM Tool Kit
http://www.gsmmobile.co.nz/Sim_Toolkit.htm
[12] Smart Card Library
http://www.franken.de/crypt/scez.html
[13] Smart Card Types
http://www.weethet.nl/english/smartcards_types.php
[14] GSM Codes
Referencias
73
http://martinri.freeshell.org/gsm-access-codes.html
[15] MOTOCODER Home
http://www.motocoder.com/motorola/template.jsp?filename=template.jsp?filename=cent
er_V3.html
[16] Writing a Java Applet
http://developers.sun.com/techtopics/mobility/javacard/articles/intro/
[17] SIM Cloning – Reverse Engineering
http://archive.nokiafree.org/index.php/f-33-SIM_Cloning.html
[18] SIM Toolkit functions
http://www.bladox.com/devel-docs/group__api__stk.html
[19] Software for SIM Card researching
http://angeltowns2.com/members/nuken/soft/soft.html
[20] GSM & SIM Information
http://www.0xdecafbad.com/GSM-and-SIM-Information.html
[21] ISO 7816 Standard Definitions
http://www.didya.com/iso-7816.asp
[22] Dekart SIM Card Reader
http://www.dekart.com/products/sim_card_reader/
[23] ISO 7816 Standard Definitions
http://www.didya.com/iso-7816.asp
Bibliografía
1. Tanenbaum, Andrew S., “Redes de Computadoras”, 4ta. Edición. Editorial Pearson,
México, 1999.
2. Wolfgang Rankl and Wolfgang Effing, “Smart Card Handbook”, 3ra. Edición. Editorial
John Wiley & Sons, 2003
3. Sun Microsystems, “Virtual Machine Specifications” Java Card platform, 2003
Apéndice
GSM Standard & Modular Tester v1.0
MANUAL DE USUARIO
Enero 2005
Tabla de Contenido
1. Introducción………………………………………………………………......... 1
1.1. Audiencia………………………………………………………….............. 1
1.2. Lista de Abreviaturas……………………………………………………… 2
2. Resumen………………... ……………………………………………………... 4
3. Requerimientos………………………………………………………………… 5
4. Inicio del programa…………………………………………………………….. 6
4.1 Comandos Básicos GSM…………………………………………………... 8
4.2 Comandos Proactivos……………………………………………………….9
5. Referencias del estándar GSM…………………………………………………. 10
1.1. Referencias del estándar GSM 11.11 (COMANDOS BASICOS GSM)..... 10
Seek................................................................................................................ 10
Status.............................................................................................................. 11
GetResponse.................................................................................................. 11
Invalidate........................................................................................................12
Rehabilitate.................................................................................................... 12
ReadBinary.................................................................................................... 13
UpdateBinary................................................................................................. 13
UpdateRecord................................................................................................ 14
ReadRecord.................................................................................................... 14
SelectbyId...................................................................................................... 15
Increase.......................................................................................................... 15
1.2. Referencias del estándar GSM 11.14 (COMANDOS PROACTIVOS)....... 16
Refresh........................................................................................................... 16
ProvideLOCI.................................................................................................. 18
DefaultPlayTone............................................................................................ 19
PlayTone........................................................................................................ 20
MoreTime...................................................................................................... 21
GetInkey......................................................................................................... 22
GetInput......................................................................................................... 23
PollInterval..................................................................................................... 24
PollingOff...................................................................................................... 24
DisplayText.................................................................................................... 24
SelectItem...................................................................................................... 26
SetUpMenu............................................................................ ....................... 26
1. Introducción
El siguiente manual pretende ilustrar sobre el uso del software GSM Standard Tester y GSM
Modular Tester programados bajo el entorno GemXplore 98 CASE 2.0 de Gemplus. Estas
aplicaciones tienen como propósito detectar problemas de compatibilidad e implementación de los
comandos contemplados en los estándares GSM 11.11 y 11.14 siendo este último el conjunto de
instrucciones del SAT (SIM Application Toolkit). Por medio de este manual el usuario podrá
comprender la estructura de la aplicación, así como los resultados que el programa produzca en el
proceso de detección de errores. Estas aplicaciones hacen uso de los códigos de errores definidos
en los estándares GSM 11.11 y 11.14 para verificar el resultado de la ejecución de cada comando.
1.1 Audiencia
Este manual contiene información de referencia para el manejo de las aplicaciones antes
mencionadas. Su uso no requiere conocimientos de programación, pero está destinado a aquellos
usuarios familiarizados con conceptos elementales sobre:
a) Tecnología de Smart Cards
b) Sistema GSM
c) Referencias hechas a los estándares:
GSM Technical Specification 02.40
1
Esto con el propósito de facilitar la comprensión de los lineamientos expuestos sin requerir de
un tratamiento detallado. Es importante que el usuario esté en capacidad de comprender algunos
aspectos contemplados en los estándares antes mencionados. Como se verá más adelante el usuario,
haciendo uso de la información aquí expuesta, estará en capacidad de evaluar el desempeño del
equipo.
1.2 Abreviaturas y acrónimos
3DES:
Triple Data Encryption Standard
ADM:
Administration Number
ADN:
Abbreviated Dialing Number
APDU:
ATR:
Answer To Reset
BS:
Base Station
CHV:
Card Holder Verification Number
CRC:
Cyclic Redundancy Check
DES:
Data Encryption Standard
DF:
Dedicated File
EF:
Elementary File
FID:
File Identification
GSM:
Groupe Spéciale Mobile / Global System for Mobile Communications
ICCID:
Integrated Circuit Card Identifier
IMEI:
International Mobile Equipment Identifier
IMSI:
ISDN:
Integrated Service Digital Network
ISO/IEC:
Int'l Standard Organization / International Electrotechnical Commission
KC:
Ciphering Key
KI:
Individual Key
LOCI
MCC:
Mobile Country Code
2
ME:
Mobile Equipment, Terminal
MF:
Master File
MSISDN:
Mobile Subscriber ISDN
OTA:
Over-The-Air
PIN:
Personal Identification Number
PUK:
Personal Unblocking Key
RFU:
SAT:
SIM Application Toolkit
SDK:
Software Development Kit
SIM:
Subscriber Identity Module, SIM Card
SMS:
Short Message Service (Servicio de mensajería de texto)
SMSC:
Short Message Service Center
SRES:
Signed Response
SS:
SW1/SW2:
VAS:
Value-added Service
3
2. Resumen
El presente texto ofrece los detalles del modo de uso de las aplicaciones GSM Standard
Tester y GSM Modular Tester. Esto incluye los requerimientos necesarios para ejecutar la
aplicación en el equipo móvil y los pasos para su arranque. Detalles del modo de operación de
ambas versiones en virtud de los diferentes escenarios que se presenten durante la ejecución de
las pruebas.
Se incluye una explicación detallada de cada comando y la respuesta que debería esperarse
en función de los lineamientos de los estándares. Una explicación sencilla apoyada por
ilustraciones sobre el manejo de cada instrucción y lo que se debería observar posteriormente.
4
3. Requerimientos
Para poder realizar las pruebas con la aplicación GSM Standard Tester y GSM Modular
Tester es necesario que el equipo móvil cuente con una versión de software reciente que
soporte aplicaciones SIM Application Toolkit, así como también es recomendable que el
usuario esté familiarizado con algunos lineamientos básicos de los estándares GSM 11.11 y
11.14
5
4. Inicio del Programa
Para dar inicio al programa es necesario insertar la SIM Card en el ME a evaluar
procurando que el software que contiene permita cargar aplicaciones SIM Toolkit.
Dependiendo de la SIM empleada tendremos 2 versiones de la aplicación. Una versión integral
que llamaremos GSM Standard Tester que nos permitirá realizar una evaluación continua de
los comandos y una versión modular a la que llamaremos GSM Modular Tester que nos
permitirá realizar pruebas puntuales de los comandos GSM. Al encender el ME debería
mostrarse el prompt para el ingreso del PIN el cual es 1234. Posteriormente debemos navegar
hasta el menú Herramientas de Oficina o algún menú alterno en donde se encuentre nuestra
aplicación.
GSM Standard Tester
GSM Modular Tester
6
La ubicación del programa dentro de los menús que ofrece el equipo móvil no siempre es la
misma por lo que debemos explorar a fin de ubicar su localización. Una vez hecho procedemos
a ingresar presionando la tecla correspondiente SELECT u OK dependiendo del caso. De
inmediato se desplegará un menú como el que se muestra a continuación, dependiendo de la
versión:
GSM Standard Tester
GSM Modular Tester
Dependiendo de que tipo de comandos queramos evaluar podemos seleccionar entre
comandos básicos GSM y comandos proactivos. El comando SIM Reset es una variante del
comando REFRESH que no puede ser incluida en la aplicación debido a que abortaría la
ejecución para “resetear” la SIM Card. Se ofrece información adicional en la opción Release
Notes y About. En el caso de la versión modular, el usuario debe guiarse por el diagrama de
menús que aparece en la subsiguiente imagen a fin de ubicar el comando que desea evaluar
GSM Modular 1
Proactives 1 PlayTone (Dial tone, Caller subscriber busy, Congestion, Radio pack
acknowledgement)
Proactives 2 PlayTone (Radio path not available/Call dropped, Error/Special
Information, Call waiting tone, Ringing tone)
Proactives 3 PlayTone
(General
Beep,
Positive
acknowledgement,
Negative
acknowledgement or error tone), MoreTime
7
Proactives 4 GetInkey (Digits only, SMS alphabet), GetInput (Digits only + Echo
user input + Unpacked format)
Proactives 5 GetInput (SMS alphabet + Echo user input + SMS packed format, Digits
only + User input not revealed + Unpacked format), DefaultPlayTone,
PollInterval
GSM Modular 2
Proactives 6 DisplayText (Normal priority, High priority, Clear after delay, Wait for
user to clear message)
Proactives 7 SelectItem, SetUpMenu, SetUpCall, CompleteSetUpCall,
SendSMS, CompleteSendSMS, SendSS, CompleteSendSS)
Proactives 8 ProvideLOCI, PollingOff
GSM Modular 3
Proactives 9 Refresh (SIM Initialization and Full File Change Notification, File
Change Notification, SIM Initialization and File Change Notification, SIM
Initialization)
NOTA IMPORTANTE: es necesario que el usuario no apresure la ejecución de los
comandos. Se ha observado que algunos MEs presentan problemas cuando no se da el
tiempo apropiado para la ejecución del comando.
4.1
Comandos Básicos GSM
En esta opción se dará inicio a la ejecución sistemática y contínua de cada uno de los
comandos básicos GSM contemplados por el GemXplore Macro Assembly Language. Los
cuales son:
8
Seek
Status
GetResponse
Invalidate
Rehabilitate
ReadBinary
UpdateBinary
UpdateRecord
ReadRecordbyMode
ReadRecordbyNum
ReadRecordbyOffset
UpdateRecordbyMode
UpdateRecordbyNum
SelectbyId
Increase
4.2
Comandos Proactivos
En esta opción se da inicio a las pruebas de manera secuencial de los comandos
proactivos contemplados por el GemXplore Macro Assembly Language. Los cuales son:
Refresh (SIM Initialization and Full File Change Notification)
Refresh (File Change Notification)
Refresh (SIM Initialization and File Change Notification)
Refresh (SIM Initialization)
Refresh (SIM Reset)
ProvideLOCI (IMEI)
DefaultPlayTone
PlayTone (Dial Tone)
PlayTone (Caller subscriber busy)
PlayTone (Congestion)
PlayTone (Radio path acknowledge)
PlayTone (Radio path not available / Call dropped)
PlayTone (Error / Special Information)
PlayTone (Call waiting tone)
9
PlayTone (Ringing Tone)
PlayTone (General Beep)
PlayTone (Positive acknowledgement tone)
PlayTone (Negative acknowledgement or error tone)
MoreTime
GetInkey (Digits only)
GetInkey (SMS alphabet)
GetInput (Digits only + Echo user input + Unpacked format)
GetInput (SMS alphabet + Echo user input + SMS packed format)
GetInput (Digits only + User input not revealed + Unpacked format)
PollInterval
PollingOff
DisplayText (Normal priority)
DisplayText (High priority)
DisplayText (Clear after delay)
DisplayText (Wait for user to clear message)
SelectItem
SetUpMenu
SetUpCall
CompleteSetUpCall
SendSS
CompleteSendSS
SendSMS
CompleteSendSMS
5. Referencias del estándar GSM
5.1 Referencias del estándar GSM 11.11 (COMANDOS BASICOS GSM)
Seek:
Esta función realiza una búsqueda de un patrón específico dentro del archivo de
tamaño fijo (lineal fixed) EF seleccionado. Este comando sólo es válido sobre
un archivo con permisología READ habilitada. El tamaño del patrón no debe
exceder el tamaño del registro. Esta instrucción trabaja en 4 modos: 1) búsqueda
desde el principio, 2) búsqueda comenzando por el final, 3) búsqueda desde el
siguiente registro en adelante y 4) búsqueda desde el anterior registro hacia atrás.
La modalidad evaluada es la primera. Se procede a ubicar dentro del archivo
ADN (Abbreviated Dialing Numbers) el registro GEMPLUS. Si el registro es
10
borrado la función retornará File pattern not found, de lo contrario mostrará
Command executed successfully with extra data available
Status:
Esta función devuelve información relacionada con el directorio actualmente
seleccionado. El EF no se ve afectado por este comando. Suele emplearse para
darle oportunidad a una SIM proactiva de indicar que la misma desea enviar un
comando proactivo al ME. Este comando verifica el status del directorio ADN
el cual debe devolver Command executed successfully
GetResponse:
Esta función devuelve información relacionada con el registro llamado
OMEGA dentro del DNA. En particular sobre su ubicación dentro del
registro. El registro OMEGA suele estar en el 8 pero puede ser modificado
para confirmar la validez del comando. OMEGA is located in record # 8 y
luego Command executed successfully en caso de que el registro exista, de
lo contrario se obtendrá un error.
11
Invalidate:
Esta función deshabilita el archivo EF actualmente seleccionado
siempre y cuando la condición de invalidar este disponible. Esta
condición impide que una aplicación trabaje con este archivo siendo
la instrucción SelectbyId y Rehabilitate las únicas que
hacerlo. También Read y Update pueden ser usadas siempre y
cuando posean la debida permisología. Si esta función se ejecuta y
luego se desea realizar alguna operación distinta a las antes
mencionadas se recibirá un mensaje de error. En la aplicación esta
función invalida el archivo FDN (Fixed Dialing Numbers) por lo que
el acceso a este registro debe estar negado una vez se halla ejecutado
exitosamente el comando. El resultado observado es Command
executed successfully
Rehabilitate:
Esta función rehabilita el archivo EF que fue inhabilitado
previamente por la instrucción Invalidate siempre y cuando la
12
condición de rehabilitar este disponible. Al ejecutarse este comando
se podrán realizar las operaciones permitidas por el propio archivo.
Se puede intentar inspeccionar un registro previamente invalidado a
fin de detectar si se ha reestablecido el acceso. En la aplicación se
rehabilita el archivo FDN (Fixed Dialing Numbers) y luego retornar
Command executed successfully
ReadBinary:
Esta función lee una cadena de bytes del actual archivo EF
transparente seleccionado. Esta función sólo será posible si la
condición Read está habilitada. En la aplicación esta operación se
realiza sobre un archivo creado para este propósito ubicado en
7F20/6F52 y debe devolver Command executed successfully
UpdateBinary:
Esta función actualiza el contenido del actual archivo EF
transparente seleccionado con una cadena de bytes específica. Esta
13
función sólo será posible si la condición Update está habilitada. En
la aplicación esta operación se realiza sobre el mismo archivo
empleado por ReadBinary. Esta función debe retornar Command
executed successfully
UpdateRecord:
Esta función actualiza el registro completo de un archivo EF (lineal
fijo o cíclico) seleccionado. Esta función sólo será posible si la
condición Update está habilitada. Tiene 4 modos de operar:
CURRENT, ABSOLUTE, NEXT y PREVIOUS. En la aplicación
esta operación se realiza sobre el archivo ADN (Abbreviated Dialing
Numbers)
UpdateRecord
(Current)
[10]
1111111111111111111111111111
|UpdateRecordbyMode
(First)
[01]
2222222222222222222222222222
(Next)
[02]
3333333333333333333333333333
(Current)
[02]
0
UpdateRecordbyNum
(12 Abs)
[12]
4444444444444444444444444444
(13 Abs)
[13]
5555555555555555555555555555
ReadRecord: Esta función lee el registro completo de un archivo EF (lineal fijo o cíclico)
seleccionado. Esta función sólo será posible si la condición Read está
habilitada. En la aplicación esta operación se realiza sobre el archivo ADN
14
(Abbreviated Dialing Numbers). Tiene 4 modos de operar: CURRENT,
ABSOLUTE,
NEXT
y
PREVIOUS,
el
modo
evaluado
en
ReadRecordbyMode es LAST y debe retornar Command executed
successfully en cada uno de los modos evaluados.
SelectbyId: Esta función selecciona un archivo de acuerdo a los métodos definidos en el
estándar GSM 11.11. Luego de seleccionar exitosamente un archivo lineal
fijo el puntero queda indefinido. No sucede lo mismo en un registro cíclico
en donde el puntero señala el último registro actualizado. Esta función debe
retornar Command executed successfully with extra data available
Increase:
Esta función añade el valor dado por el ME al valor presente en el último
registro incrementado o actualizado del actual archivo EF cíclico y lo
almacena en el registro más antiguo y el apuntador queda señalando a éste
último convirtiéndose en el registro 1. Sólo se podrá realizar si la opción
Increase está habilitada. En caso de que el resultado exceda el valor
máximo del registro (todos los bytes en ‘FF’) la SIM no realizará la
operación. De lo contrario debe retornar Command executed successfully
with extra data available
15
5.2 Referencias del estándar GSM 11.14 (COMANDOS PROACTIVOS)
Refresh:
El propósito de este comando es notificar al ME que han ocurrido cambios en la
SIM Card durante una aplicación. Le compete a la SIM Card verificar que esta
solicitud ha sido ejecutada correctamente. Este comando tiene 5 diferentes
modos de operación y se listan a continuación:
SIM Initialization: este modo ocasiona una inicialización de la SIM por parte
del ME de acuerdo a la subcláusula 11.21.1 del estándar GSM 11.11. Este
procedimiento debe comenzarte en el punto justo después del proceso de
verificación del PIN (CHV1). El ME no debe reiniciar la SIM eléctricamente.
Debe retornar Command performed
16
File Change Notification: Este modo le avisa al ME que algunas propiedades de
algunos EFs han cambiado, ya sea en estructura o en contenido, en la SIM Card.
Esta información sirve para actualizar la imagen que tiene el ME de algún
archivo de la SIM como por ejemplo el ADN (Abbreviated Dialing Numbers).
En la aplicación se actualiza el archivo ADN con el contenido del archivo LND
(Last Number Dialed). Debe retornar Command executed successfully.
SIM Initialization and File Change Notification: este comando realiza una
operación de actualización que combina los dos modos anteriores. En la
aplicación se actualiza el archivo ADN con el contenido del archivo LND (Last
Number Dialed). Debe retornar Command performed
SIM Initialization & Full File Change Notification: este modo permite llevar a
cabo una inicialización de la SIM Card como en el primer modo y advierte al
ME que muchos EFs han sido cambiados (en estructura o contenido). De modo
17
que si existe una imagen de la SIM Card en el ME, esta debe ser actualizada
completamente. Debe retornar Command executed successfully
SIM Reset: este modo da inicio al cierre de sesión GSM en la SIM Card por
parte del ME así como su desactivación de acuerdo al estándar GSM 11.11 [20].
Luego, el ME activa la SIM Card para iniciar una nueva sesión GSM. En caso
de ME cuya tecnología sea de 3V, el ME debe reiniciar la SIM Card con el
mismo voltaje de alimentación que en la sesión anterior. En otros MEs, el
equipo debe realizar una conmutación de voltaje de alimentación de acuerdo al
estándar GSM 11.12 [21]. Este modo es empleado cuando una aplicación SAT
requiere un ATR (Answer to Reset) o completar un procedimiento de
inicialización
ProvideLOCI:
Este comando solicita al ME el envío de información local actual a
la SIM Card. Hasta hoy en día esta información está restringida a:
18
Información Local:
Mobile Country Code (MCC), Mobile Network Code (MNC),
Location Area Code (LAC) y la identificación de la celda
IMEI:
El IMEI del ME
En la aplicación el ME debe retornar el IMEI del teléfono. Esta
operación toma un tiempo relativamente considerable en virtud de la
gran cantidad de cálculos requeridos para mostrar el número en un
formato entendible. Se puede verificar si corresponde al indicado por
el comando *#06#. Debe retornar Command executed successfully.
*#06#
DefaultPlayTone:
Este comando ejecuta el tono por defecto del ME con la duración por
defecto. Este comando no está dentro de las 8 modalidades
supervisadas del PlayTone por el estándar GSM 11.14. Debe
retornar Command executed successfully.
19
PlayTone:
Este comando solicita al ME reproducir un tono específico en el auricular,
altavoz del ME o el algún otro terminal del ME apropiado. Posee 8 tonos
supervisados y otros 3 no supervisados. He aquí los diferentes tonos que
deben cumplir con los lineamientos del estándar GSM 02.40. La duración de
todos los tonos está programada para 15 segundos. Debe retornar Command
executed successfully.
1. Dial Tone
2. Caller subscriber busy
No supervisados:
3. Congestion
4. Radio path acknowledge
11. General Beep
5. Radio path not available/Call dropped
12. Positive acknowledgment tone
6. Error / Special Information
13. Negative acknowledgement or error
7. Call waiting tone
tone
8. Ringing tone
Supervisory tones in GSM
Tone
1
2*
3*
4
5
6*
Frequency
Dial tone (optional)
Subscriber Busy (Called
Number)
Congestion
Radio Path
Acknowledgement (Mobile
Originated only) (optional)
{Radio Path Not Available
{Call Dropped – Mobile
originated only
Error/Special Information}
Number Unobtainable }
Authentication Failure }
Tolerance
GSM 900/
DCS 1800
425Hz
425Hz
PCS 1900
for NA
350Hz added to 440Hz
15Hz
15Hz
425Hz
15Hz
425Hz
425Hz
15Hz
425Hz
425Hz
15Hz
950Hz
1400Hz
1800Hz
950Hz
1400Hz
1800Hz
50Hz
50Hz
50Hz
Type
GSM 900 /
DCS 1800
Continuous
Tone on 500ms
Silence 500ms
Tone on 200ms
Silence 200ms
Single tone 200ms
PCS 1900
for NA
Continuous
Tone on 500ms
Silence 500ms
Tone on 250ms
Silence 250ms
Single tone 200ms
200ms} On/off
200ms} for 3
burst
{Triple Tone
{Tones on 330ms
{Silence 1.0s
200ms} On/off
200ms} for 3
burst
{Triple Tone
{Tones on 330ms
{Silence 1.0s
20
7
Call Waiting Tone
425 Hz (tolerance 15Hz), on for 200ms, off for 600ms on for 200ms, off for 3s, on for 200ms,
off for 600ms on for 200ms. This tone is superimposed on the audio traffic received by the
called user. Alternate tones are acceptable but not preferred.
440 Hz, on for 300 ms, 9.7s off followed by (440 Hz, on for 100 ms off for 100 ms, on
for 100 ms, 9.7s off and repeated as necessary) This tone is superimposed on the audio
traffic received by the called user.
Definition of these and other tones, together with advice on announcements, may be found in CEPT T/CS 20-15 and in T/SF
23.
* The duration of these tones is an implementation option. However, in each case, the MS should be returned immediately to the
idle state, and will be able to originate/receive calls, which will override these tones.
Ringing Tone (Alternative
425Hz
15Hz
national options permitted)
Tone on 1s
Silence 4s
Tone on 2s
Silence 4s
For application of Call Control Cause Information Elements to these tones, see Annex A, GSM 02.40.
Cada una de las pantallas de los 8 tonos supervisados por el estándar GSM 02.40. Es
importante recordar que no es recomendable apresurar la ejecución de las pruebas ya que se ha
observado que muchos MEs abortan la ejecución de la aplicación al realizar esta acción
MoreTime:
Este comando le permite a una aplicación SAT solicitar más tiempo para
procesar al ME. Este comando no posee ningún parámetro por lo que su
21
efecto no es posible de evaluar a simple vista. Debe retornar Command
executed successfully.
GetInkey:
Este comando le indica al ME que muestre en pantalla un sólo carácter
correspondiente a la tecla presionada por el usuario. El texto puede estar en
uno de los siguientes formatos: packet format o unpacket format. Y la
respuesta puede darse de dos tipos: sólo dígitos (0-9,*,# y +) y caracteres del
alfabeto SMS. En la aplicación se evalúan las dos modalidades en las que
sólo se puede ingresar un dígito o un carácter respectivamente. Debe
retornar Command executed successfully.
22
GetInput:
Este comando le indica al ME que muestre en pantalla las teclas presionadas
las cuales pueden ser hasta cuarenta y nueve (49). El texto puede estar en
uno de los siguientes formatos: packet format o unpacket format. Y la
respuesta puede darse de 3 tipos diferentes: 1) Sólo dígitos (0-9,*, # y +) y
caracteres del alfabeto SMS, 2) En packet format o unpacket format y 3)
mostrar o no los caracteres introducidos (en el último caso sustituir los
caracteres por *). Debe retornar Command executed successfully.
23
PollInterval:
Este comando inicia la negociación de máximo intervalo de tiempo entre
comandos Status ejecutados por el ME cuando se encuentre inactivo. El
comando dentro de la aplicación solicita al ME un tiempo de negociación de
1 segundo. El ME puede ofrecer un tiempo menor, igual o mayor al
solicitado por la SIM. Debe retornar Command executed successfully.
PollingOff:
Este comando cancela el comando previo PollInterval permitiendo
que el ME emplee el intervalo de tiempo por defecto entre cada ejecución
del comando Status. Debe retornar Command executed successfully.
|DisplayText:
Este comando permite mostrar texto completo en pantalla en 4 modos
distintos:
1) Con prioridad normal y borrado luego de un tiempo
2) Con prioridad normal y a la espera del usuario para borrarlo
3) Con prioridad alta y borrado luego de un tiempo
24
4) Con prioridad alta y a la espera del usuario para borrarlo.
En la aplicación se muestra el texto respectivo a la condición que esta siendo
evaluada. Debe retornar Command executed successfully.
25
SelectItem:
Este comando permite a la SIM mostrar una lista de elementos de los cuales
el usuario debe seleccionar uno. Cada elemento contiene un identificador
para poder listarlo así como un título para los elementos listados (un
máximo de 18 elementos pueden ser listados). En el caso de la aplicación
esta ofrece una lista de 4 personas pertenecientes al equipo de PFE de
Motorola. Debe retornar Command executed successfully.
SetUpMenu:
La SIM debe proveer un conjunto de menús los cuales deben ser integrados
a la estructura del sistema de menús. Esto con el propósito de darle la
oportunidad al usuario de seleccionar uno. Cada uno de ellos puede contener
una aplicación debidamente identificada. En nuestra aplicación esta
instrucción advierte sobre el cambio de menú e insta al usuario a ejecutar un
SIM Reset para restaurar el menú inicial donde esta contenido nuestro
programa. El nuevo menú debe tener como título NEW MENU TO
MOBILE. Debe retornar Command executed successfully.
26
COMANDOS PROACTIVOS PENDIENTES:
*SetUpCall
*CompleteSetUpCall
*SendSS
*CompleteSendSS
*SendSMS
*CompleteSendSMS
*Programados pero no implementados
debido a limitaciones en el acceso a la
red local GSM
27
TS 100 977 V6.2.0 (1999-05)
Technical Specification
Digital cellular telecommunications system (Phase 2+);
Specification of the Subscriber Identity Module Mobile Equipment (SIM - ME) interface
(GSM 11.11 version 6.2.0 Release 1997)
R
GLOBAL SYSTEM FOR
MOBILE COMMUNICATIONS
2
TS 100 977 V6.2.0 (1999-05)
Reference
RTS/SMG-091111Q6R1 (91o030o3.PDF)
Keywords
Digital cellular telecommunications system,
Global System for Mobile communications (GSM)
ETSI
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Internet
[email protected]
Individual copies of this ETSI deliverable
can be downloaded from
http://www.etsi.org
If you find errors in the present document, send your
comment to: [email protected]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1999.
All rights reserved.
ETSI
3
TS 100 977 V6.2.0 (1999-05)
Contents
Intellectual Property Rights................................................................................................................................8
Foreword ............................................................................................................................................................8
1
Scope........................................................................................................................................................9
2
References................................................................................................................................................9
3
Definitions, abbreviations and symbols .................................................................................................11
3.1
3.2
3.3
4
4.1
4.1.1
4.1.2
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.4
4.5
5
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.8.1
5.8.2
5.8.3
5.9
5.10
6
6.1
6.2
6.3
6.4
6.4.1
6.4.2
6.4.3
6.5
6.6
7
7.1
7.2
7.3
8
8.1
8.2
Definitions ....................................................................................................................................................... 11
Abbreviations................................................................................................................................................... 12
Symbols ........................................................................................................................................................... 13
Physical characteristics ..........................................................................................................................13
Format and layout ............................................................................................................................................ 14
ID-1 SIM .................................................................................................................................................... 14
Plug-in SIM................................................................................................................................................ 14
Temperature range for card operation.............................................................................................................. 14
Contacts ........................................................................................................................................................... 14
Provision of contacts .................................................................................................................................. 14
Activation and deactivation........................................................................................................................ 14
Inactive contacts......................................................................................................................................... 15
Contact pressure ......................................................................................................................................... 15
Precedence ....................................................................................................................................................... 15
Static Protection............................................................................................................................................... 15
Electronic signals and transmission protocols .......................................................................................15
Supply voltage Vcc (contact C1) ..................................................................................................................... 16
Reset (RST) (contact C2)................................................................................................................................. 16
Programming voltage Vpp (contact C6) .......................................................................................................... 16
Clock CLK (contact C3) .................................................................................................................................. 16
I/O (contact C7) ............................................................................................................................................... 17
States................................................................................................................................................................ 17
Baudrate........................................................................................................................................................... 18
Answer To Reset (ATR) .................................................................................................................................. 18
Structure and contents ................................................................................................................................ 18
PTS procedure............................................................................................................................................ 20
Speed enhancement .................................................................................................................................... 21
Bit/character duration and sampling time ........................................................................................................ 21
Error handling.................................................................................................................................................. 21
Logical Model ........................................................................................................................................21
General description .......................................................................................................................................... 21
File identifier ................................................................................................................................................... 22
Dedicated files ................................................................................................................................................. 22
Elementary files ............................................................................................................................................... 23
Transparent EF........................................................................................................................................... 23
Linear fixed EF .......................................................................................................................................... 23
Cyclic EF.................................................................................................................................................... 24
Methods for selecting a file.............................................................................................................................. 24
Reservation of file IDs ..................................................................................................................................... 25
Security features.....................................................................................................................................26
Authentication and cipher key generation procedure....................................................................................... 26
Algorithms and processes ................................................................................................................................ 26
File access conditions ...................................................................................................................................... 26
Description of the functions...................................................................................................................27
SELECT........................................................................................................................................................... 28
STATUS .......................................................................................................................................................... 28
ETSI
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
8.18
8.19
8.20
8.21
9
9.1
9.2
9.2.1
9.2.2
9.2.3
9.2.4
9.2.5
9.2.6
9.2.7
9.2.8
9.2.9
9.2.10
9.2.11
9.2.12
9.2.13
9.2.14
9.2.15
9.2.16
9.2.17
9.2.18
9.2.19
9.2.20
9.2.21
9.2.22
9.3
9.4
9.4.1
9.4.2
9.4.3
9.4.4
9.4.5
9.4.6
9.4.7
10
10.1
10.1.1
10.1.2
10.2
10.3
4
TS 100 977 V6.2.0 (1999-05)
READ BINARY .............................................................................................................................................. 28
UPDATE BINARY ......................................................................................................................................... 28
READ RECORD ............................................................................................................................................. 29
UPDATE RECORD ........................................................................................................................................ 29
SEEK ............................................................................................................................................................... 30
INCREASE...................................................................................................................................................... 30
VERIFY CHV ................................................................................................................................................. 31
CHANGE CHV ............................................................................................................................................... 31
DISABLE CHV ............................................................................................................................................... 31
ENABLE CHV ................................................................................................................................................ 32
UNBLOCK CHV............................................................................................................................................. 32
INVALIDATE ................................................................................................................................................. 32
REHABILITATE ............................................................................................................................................ 33
RUN GSM ALGORITHM .............................................................................................................................. 33
SLEEP ............................................................................................................................................................. 33
TERMINAL PROFILE.................................................................................................................................... 33
ENVELOPE..................................................................................................................................................... 33
FETCH............................................................................................................................................................. 34
TERMINAL RESPONSE................................................................................................................................ 34
Description of the commands ................................................................................................................34
Mapping principles .......................................................................................................................................... 34
Coding of the commands ................................................................................................................................. 37
SELECT ..................................................................................................................................................... 37
STATUS .................................................................................................................................................... 40
READ BINARY......................................................................................................................................... 40
UPDATE BINARY.................................................................................................................................... 40
READ RECORD........................................................................................................................................ 40
UPDATE RECORD................................................................................................................................... 40
SEEK.......................................................................................................................................................... 41
INCREASE ................................................................................................................................................ 41
VERIFY CHV............................................................................................................................................ 41
CHANGE CHV.......................................................................................................................................... 42
DISABLE CHV ......................................................................................................................................... 42
ENABLE CHV........................................................................................................................................... 42
UNBLOCK CHV ....................................................................................................................................... 42
INVALIDATE ........................................................................................................................................... 43
REHABILITATE....................................................................................................................................... 43
RUN GSM ALGORITHM......................................................................................................................... 43
SLEEP........................................................................................................................................................ 43
GET RESPONSE....................................................................................................................................... 43
TERMINAL PROFILE .............................................................................................................................. 44
ENVELOPE ............................................................................................................................................... 44
FETCH....................................................................................................................................................... 44
TERMINAL RESPONSE .......................................................................................................................... 44
Definitions and coding..................................................................................................................................... 44
Status conditions returned by the card ............................................................................................................. 46
Responses to commands which are correctly executed .............................................................................. 46
Responses to commands which are postponed ........................................................................................... 46
Memory management ................................................................................................................................. 46
Referencing management ........................................................................................................................... 46
Security management ................................................................................................................................. 47
Application independent errors .................................................................................................................. 47
Commands versus possible status responses .............................................................................................. 47
Contents of the Elementary Files (EF)...................................................................................................48
Contents of the EFs at the MF level................................................................................................................. 49
EFICCID (ICC Identification)................................................................................................................... 49
EFELP (Extended language preference)....................................................................................................... 50
DFs at the GSM application level .................................................................................................................... 50
Contents of files at the GSM application level................................................................................................. 50
ETSI
10.3.1
10.3.2
10.3.3
10.3.4
10.3.5
10.3.6
10.3.7
10.3.8
10.3.9
10.3.10
10.3.11
10.3.12
10.3.13
10.3.14
10.3.15
10.3.16
10.3.17
10.3.18
10.3.19
10.3.20
10.3.21
10.3.22
10.3.23
10.3.24
10.3.25
10.3.26
10.3.27
10.3.28
10.3.29
10.3.30
10.3.31
10.3.32
10.3.33
10.4
10.4.1
10.4.2
10.4.3
10.4.4
10.4.5
10.4.6
10.4.7
10.4.8
10.4.9
10.4.10
10.4.11
10.4.12
10.4.13
10.4.14
10.4.15
10.5
11
11.1
11.1.1
11.1.2
11.1.3
11.2
11.2.1
11.2.2
11.2.3
5
TS 100 977 V6.2.0 (1999-05)
EFLP (Language preference) ..................................................................................................................... 50
EFIMSI (IMSI).......................................................................................................................................... 51
EFKc (Ciphering key Kc) .......................................................................................................................... 52
EFPLMNsel (PLMN selector)................................................................................................................... 52
EFHPLMN (HPLMN search period) ........................................................................................................ 53
EFACMmax (ACM maximum value) ....................................................................................................... 54
EFSST (SIM service table) ........................................................................................................................ 55
EFACM (Accumulated call meter) ............................................................................................................ 57
EFGID1 (Group Identifier Level 1) ........................................................................................................... 57
EFGID2 (Group Identifier Level 2) ........................................................................................................... 57
EFSPN (Service Provider Name)............................................................................................................... 58
EFPUCT (Price per unit and currency table)............................................................................................. 58
EFCBMI (Cell broadcast message identifier selection)............................................................................. 59
EFBCCH (Broadcast control channels)..................................................................................................... 60
EFACC (Access control class)................................................................................................................... 60
EFFPLMN (Forbidden PLMNs) ............................................................................................................... 61
EFLOCI (Location information) ............................................................................................................... 61
EFAD (Administrative data) ...................................................................................................................... 63
EFPhase (Phase identification) .................................................................................................................. 64
EFVGCS (Voice Group Call Service) ....................................................................................................... 64
EFVGCSS (Voice Group Call Service Status) .......................................................................................... 65
EFVBS (Voice Broadcast Service) ............................................................................................................ 66
EFVBSS (Voice Broadcast Service Status) ............................................................................................... 66
EFeMLPP (enhanced Multi Level Pre-emption and Priority) ................................................................... 66
EFAAeM (Automatic Answer for eMLPP Service)................................................................................... 67
EFCBMID (Cell Broadcast Message Identifier for Data Download) ........................................................ 68
EFECC (Emergency Call Codes)............................................................................................................... 69
EFCBMIR (Cell broadcast message identifier range selection) ................................................................ 70
EFDCK De-personalization Control Keys ................................................................................................. 70
EFCNL(Co-operative Network List).......................................................................................................... 70
EFNIA(Network's Indication of Alerting).................................................................................................. 72
EFKcGPRS (GPRS Ciphering key KcGPRS) ........................................................................................... 73
EFLOCIGPRS (GPRS location information) ........................................................................................... 73
Contents of files at the telecom level ............................................................................................................... 75
EFADN (Abbreviated dialling numbers) ................................................................................................... 75
EFFDN (Fixed dialling numbers) .............................................................................................................. 78
EFSMS (Short messages)........................................................................................................................... 78
EFCCP (Capability configuration parameters) .......................................................................................... 79
EFMSISDN (MSISDN)............................................................................................................................. 80
EFSMSP (Short message service parameters) ........................................................................................... 80
EFSMSS (SMS status) ............................................................................................................................... 82
EFLND (Last number dialled) ................................................................................................................... 83
EFSDN (Service Dialling Numbers) .......................................................................................................... 83
EFEXT1 (Extension1) ............................................................................................................................... 84
EFEXT2 (Extension2) ............................................................................................................................... 85
EFEXT3 (Extension3) ............................................................................................................................... 85
EFBDN (Barred Dialling Numbers)........................................................................................................... 85
EFEXT4 (Extension4) ............................................................................................................................... 86
EFSMSR (Short message status reports) ................................................................................................... 86
Files of GSM (figure 8).................................................................................................................................... 87
Application protocol ..............................................................................................................................88
General procedures .......................................................................................................................................... 90
Reading an EF ............................................................................................................................................ 90
Updating an EF .......................................................................................................................................... 90
Increasing an EF......................................................................................................................................... 90
SIM management procedures........................................................................................................................... 91
SIM initialization ....................................................................................................................................... 91
GSM session termination ........................................................................................................................... 92
Emergency Call Codes ............................................................................................................................... 92
ETSI
11.2.4
11.2.5
11.2.6
11.2.7
11.2.8
11.2.9
11.3
11.3.1
11.3.2
11.3.3
11.3.4
11.3.5
11.4
11.4.1
11.4.2
11.4.3
11.4.4
11.4.5
11.4.6
11.4.7
11.4.8
11.5
11.5.1
11.5.2
11.5.3
11.5.4
11.5.5
11.5.6
11.5.7
11.5.8
11.5.9
11.5.10
11.5.11
11.5.12
11.5.13
11.5.14
11.5.15
11.5.16
11.6
11.6.1
11.6.2
11.6.3
11.6.4
11.6.5
11.6.6
11.6.7
11.6.8
11.6.9
11.6.10
11.6.11
11.6.12
11.6.13
11.6.14
11.6.15
11.6.16
11.6.17
6
TS 100 977 V6.2.0 (1999-05)
Language preference .................................................................................................................................. 93
Administrative information request;........................................................................................................... 93
SIM service table request ........................................................................................................................... 93
SIM phase request ...................................................................................................................................... 93
SIM Presence Detection and Proactive Polling.......................................................................................... 93
Extended Language preference .................................................................................................................. 93
CHV related procedures................................................................................................................................... 93
CHV verification ........................................................................................................................................ 93
CHV value substitution .............................................................................................................................. 94
CHV disabling............................................................................................................................................ 94
CHV enabling............................................................................................................................................. 94
CHV unblocking ........................................................................................................................................ 94
GSM security related procedures..................................................................................................................... 95
GSM algorithms computation .................................................................................................................... 95
IMSI request............................................................................................................................................... 95
Access control request................................................................................................................................ 95
HPLMN search period request................................................................................................................... 95
Location information.................................................................................................................................. 95
Cipher key .................................................................................................................................................. 95
BCCH information ..................................................................................................................................... 95
Forbidden PLMN ....................................................................................................................................... 95
Subscription related procedures....................................................................................................................... 95
Dialling numbers ........................................................................................................................................ 95
Short messages ........................................................................................................................................... 98
Advice of Charge (AoC) ............................................................................................................................ 98
Capability configuration parameters .......................................................................................................... 99
PLMN selector ........................................................................................................................................... 99
Cell broadcast message identifier............................................................................................................... 99
Group identifier level 1 .............................................................................................................................. 99
Group identifier level 2 .............................................................................................................................. 99
Service Provider Name............................................................................................................................... 99
Voice Group Call Services......................................................................................................................... 99
Voice Broadcast Services........................................................................................................................... 99
Enhanced Multi Level Pre-emption and Priority Service ......................................................................... 100
Cell Broadcast Message range identifier .................................................................................................. 100
Depersonalisation Control Keys............................................................................................................... 100
Short message status report ...................................................................................................................... 100
Network's indication of alerting ............................................................................................................... 100
SIM Application Toolkit related procedures ................................................................................................. 101
Initialization procedure ............................................................................................................................ 101
Proactive polling ...................................................................................................................................... 101
Support of commands............................................................................................................................... 101
Support of response codes........................................................................................................................ 101
Command-response pairs ......................................................................................................................... 101
Independence of normal GSM and SIM Application Toolkit tasks ......................................................... 101
Use of BUSY status response................................................................................................................... 102
Use of NULL procedure byte................................................................................................................... 102
Using the TERMINAL PROFILE, ENVELOPE, and TERMINAL RESPONSE commands ................. 102
Using the FETCH command .................................................................................................................... 102
Data Download via SMS-CB ................................................................................................................... 102
Data Download via SMS-PP .................................................................................................................... 102
Menu selection ......................................................................................................................................... 102
Call Control.............................................................................................................................................. 103
Proactive SIM .......................................................................................................................................... 103
Mobile Originated Short Message control by SIM................................................................................... 103
SIM data download error ......................................................................................................................... 103
ETSI
7
TS 100 977 V6.2.0 (1999-05)
Annex A (normative):
Plug-in SIM ..................................................................................................104
Annex B (normative):
Coding of Alpha fields in the SIM for UCS2 ............................................105
Annex C (informative):
FDN/BDN Procedures .................................................................................107
Annex D (informative):
Suggested contents of the EFs at pre-personalization..............................112
Annex E (informative):
SIM application Toolkit protocol diagrams..............................................113
Annex F (informative):
Bibliography.................................................................................................120
Annex G (informative):
Change history .............................................................................................121
History ............................................................................................................................................................122
ETSI
8
TS 100 977 V6.2.0 (1999-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server)
which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by the Special Mobile Group (SMG).
The present document defines the interface between the Subscriber Identity Module (SIM) and the Mobile Equipment
(ME) within the digital cellular telecommunications system.
The contents of the present document are subject to continuing work within SMG and may change following formal
SMG approval. Should SMG modify the contents of the present document it will then be republished by ETSI with an
identifying change of release date and an increase in version number as follows:
Version 6.x.y
where:
6 indicates GSM Release 1997 of Phase 2+
y the third digit is incremented when editorial only changes have been incorporated in the specification;
x the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections,
updates, etc.
ETSI
1
9
TS 100 977 V6.2.0 (1999-05)
Scope
The present document defines the interface between the Subscriber Identity Module (SIM) and the Mobile Equipment
(ME) for use during the network operation phase of GSM as well as those aspects of the internal organization of the
SIM which are related to the network operation phase. This is to ensure interoperability between a SIM and an ME
independently of the respective manufacturers and operators. The concept of a split of the Mobile Station (MS) into
these elements as well as the distinction between the GSM network operation phase, which is also called GSM
operations, and the administrative management phase are described in the GSM 02.17 [6].
The present document defines:
-
the requirements for the physical characteristics of the SIM, the electrical signals and the transmission protocols;
the model which shall be used as a basis for the design of the logical structure of the SIM;
the security features;
the interface functions;
the commands;
the contents of the files required for the GSM application;
the application protocol.
Unless otherwise stated, references to GSM also apply to DCS 1800.
The present document does not specify any aspects related to the administrative management phase. Any internal
technical reallocation of either the SIM or the ME are only specified where these reflect over the interface. It does not
specify any of the security algorithms which may be used.
The present document defines the SIM/ME interface for GSM Phase 2. While all attempts have been made to maintain
phase compatibility, any issues that specifically relate to Phase 1 should be referenced from within the relevant Phase 1
specification.
2
References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same
number.
• For this Release 1997 document, references to GSM documents are for Release 1997 versions (version 6.x.y).
[1]
GSM 01.02: "Digital cellular telecommunications system (Phase 2+); General description of a
GSM Public Land Mobile Network (PLMN)".
[2]
GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and
acronyms".
[3]
GSM 02.07: "Digital cellular telecommunications system (Phase 2+); Mobile Stations (MS)
features".
[4]
GSM 02.09: "Digital cellular telecommunications system (Phase 2+); Security aspects".
[5]
GSM 02.11: "Digital cellular telecommunications system (Phase 2+); Service accessibility".
[6]
GSM 02.17: "Digital cellular telecommunications system (Phase 2+); Subscriber Identity Modules
(SIM) Functional characteristics".
ETSI
10
TS 100 977 V6.2.0 (1999-05)
[7]
GSM 02.24: "Digital cellular telecommunications system (Phase 2+); Description of Charge
Advice Information (CAI)".
[8]
GSM 02.30: "Digital cellular telecommunications system (Phase 2+); Man-Machine Interface
(MMI) of the Mobile Station (MS)".
[9]
GSM 02.86: "Digital cellular telecommunications system (Phase 2+); Advice of charge (AoC)
Supplementary Services - Stage 1".
[10]
GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing and
identification".
[11]
GSM 03.20: "Digital cellular telecommunications system (Phase 2+); Security related network
functions".
[12]
GSM 03.38: "Digital cellular telecommunications system (Phase 2+); Alphabets and
language-specific information".
[13]
GSM 03.40: "Digital cellular telecommunications system (Phase 2+); Technical realization of the
Short Message Service (SMS) Point-to-Point (PP)".
[14]
GSM 03.41: "Digital cellular telecommunications system (Phase 2+); Technical realization of
Short Message Service Cell Broadcast (SMSCB)".
[15]
GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer
3 specification".
[16]
GSM 04.11: "Digital cellular telecommunications system (Phase 2+); Point-to-Point (PP) Short
Message Service (SMS) support on mobile radio interface".
[17]
GSM 09.91 (ETR 174): "Digital cellular telecommunications system; Interworking aspects of the
Subscriber Identity Module - Mobile Equipment (SIM - ME) interface between Phase 1 and
Phase 2".
[18]
CCITT Recommendation E.118: "The international telecommunication charge card".
[19]
CCITT Recommendation E.164: "Numbering plan for the ISDN era".
[20]
CCITT Recommendation T.50: "International Alphabet No. 5". (ISO 646: 1983, Information
processing - ISO 7-bits coded characters set for information interchange).
[21]
ISO/IEC 7810 (1995): "Identification cards - Physical characteristics".
[22]
ISO/IEC 7811-1 (1995): "Identification cards - Recording technique - Part 1: Embossing".
[23]
ISO/IEC 7811-3 (1995): "Identification cards - Recording technique - Part 3: Location of
embossed characters on ID-1 cards".
[24]
ISO 7816-1 (1987): "Identification cards - Integrated circuit(s) cards with contacts, Part 1: Physical
characteristics".
[25]
ISO 7816-2 (1988): "Identification cards - Integrated circuit(s) cards with contacts, Part 2:
Dimensions and locations of the contacts".
[26]
ISO/IEC 7816-3 (1989): "Identification cards - Integrated circuit(s) cards with contacts, Part 3:
Electronic signals and transmission protocols".
[27]
GSM 11.14 (TS 101 267): "Digital cellular telecommunications system (Phase 2+); Specification
of the SIM Application Toolkit for the Subscriber Identity Module - Mobile Equipment (SIM ME) interface".
[28]
GSM 11.12: "Digital cellular telecommunications system (Phase 2); Specification of the 3 Volt
Subscriber Identity Module - Mobile Equipment (SIM - ME) interface".
ETSI
11
TS 100 977 V6.2.0 (1999-05)
[29]
GSM 02.22: "Digital cellular telecommunications system (Phase 2+); Personalization of GSM
Mobile Equipment (ME) Mobile functionality specification".
[30]
ISO 639 (1988): "Code for the representation of names of languages".
[31]
ISO/IEC 10646-1:1993 "Information technology -- Universal Multiple-Octet Coded Character Set
(UCS) -- Part 1: Architecture and Basic Multilingual Plane"
[32]
GSM 03.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio ervice
(GPRS); Service description; Stage 2"
3
Definitions, abbreviations and symbols
3.1
Definitions
For the purposes of the present document, the following terms and definitions apply. For further information and
definitions refer to GSM 01.02 [1].
access conditions: A set of security attributes associated with a file.
application: An application consists of a set of security mechanisms, files, data and protocols (excluding transmission
protocols).
application protocol: The set of procedures required by the application.
card session: A link between the card and the external world starting with the ATR and ending with a subsequent reset
or a deactivation of the card.
current directory: The latest MF or DF selected.
current EF: The latest EF selected.
data field: Obsolete term for Elementary File.
Dedicated File (DF): A file containing access conditions and, optionally, Elementary Files (EFs) or other Dedicated
Files (DFs).
directory: General term for MF and DF.
Elementary File (EF): A file containing access conditions and data and no other files.
file: A directory or an organized set of bytes or records in the SIM.
file identifier: The 2 bytes which address a file in the SIM.
GSM or DCS 1800 application: Set of security mechanisms, files, data and protocols required by GSM or DCS 1800.
GSM session: That part of the card session dedicated to the GSM operation.
IC card SIM: Obsolete term for ID-1 SIM.
ID-1 SIM: The SIM having the format of an ID-1 card (see ISO 7816-1 [24]).
Master File (MF): The unique mandatory file containing access conditions and optionally DFs and/or EFs.
normal GSM operation: Relating to general, CHV related, GSM security related and subscription related procedures.
padding: One or more bits appended to a message in order to cause the message to contain the required number of bits
or bytes.
plug-in SIM: A Second format of SIM (specified in clause 4).
ETSI
12
TS 100 977 V6.2.0 (1999-05)
proactive SIM: A SIM which is capable of issuing commands to the ME. Part of SIM Application Toolkit (see clause
11).
record: A string of bytes within an EF handled as a single entity (see clause 6).
record number: The number which identifies a record within an EF.
record pointer: The pointer which addresses one record in an EF.
root directory: Obsolete term for Master File.
SIM application toolkit procedures: Defined in GSM 11.14 [27].
3.2
Abbreviations
For the purposes of the present document, the following abbreviations apply, in addition to those listed in
GSM 01.04 [2]:
A3
A5
A8
A38
ACM
ADN
ADM
ALW
AoC
APDU
ATR
BCCH
BCD
BDN
BTS
CB
CBMI
CCITT
CCP
CHV
CLA
CNL
DCK
DCS
DF
DTMF
ECC
EF
ETSI
eMLPP
etu
FDN
GSM
HPLMN
IC
ICC
ID
IEC
IMSI
ISO
Kc
Algorithm 3, authentication algorithm; used for authenticating the subscriber
Algorithm 5, cipher algorithm; used for enciphering/deciphering data
Algorithm 8, cipher key generator; used to generate Kc
A single algorithm performing the functions of A3 and A8
Accumulated Call Meter
Abbreviated Dialling Number
Access condition to an EF which is under the control of the authority which creates this file
ALWays
Advice of Charge
Answer To Reset
Broadcast Control CHannel
Binary Coded Decimal
Barred Dialling Number
Base Transmitter Station
Cell Broadcast
Cell Broadcast Message Identifier
The International Telegraph and Telephone Consultative Committee (now also known as the ITU
Telecommunications Standardization sector)
Capability/Configuration Parameter
Card Holder Verification information; access condition used by the SIM for the verification of the
identity of the user
CLAss
Co-operative Network List
De-personalization Control Keys
Digital Cellular System
Dedicated File (abbreviation formerly used for Data Field)
Dual Tone Multiple Frequency
Emergency Call Code
Elementary File
European Telecommunications Standards Institute
enhanced Multi-Level Precedence and Pre-emption Service
elementary time unit
Fixed Dialling Number
Global System for Mobile communications
Home PLMN
Integrated Circuit
Integrated Circuit(s) Card
IDentifier
International Electrotechnical Commission
International Organization for Standardization
Cryptographic key; used by the cipher A5
ETSI
13
TS 100 977 V6.2.0 (1999-05)
Ki
Subscriber authentication key; the cryptographic key used by the authentication algorithm, A3, and
cipher key generator, A8
LAI
Location Area Information; information indicating a cell or a set of cells
lgth
The (specific) length of a data unit
LND
Last Number Dialled
LSB
Least Significant Bit
MCC
Mobile Country Code
ME
Mobile Equipment
MF
Master File
MMI
Man Machine Interface
MNC
Mobile Network Code
MS
Mobile Station
MSISDN
Mobile Station international ISDN number
MSB
Most Significant Bit
NET
NETwork
NEV
NEVer
NPI
Numbering Plan Identifier
PIN/PIN2
Personal Identification Number / Personal Identification Number 2 (obsolete terms for CHV1 and
CHV2, respectively)
PLMN
Public Land Mobile Network
PTS
Protocol Type Select (response to the ATR)
PUK/PUK2
PIN Unblocking Key / PIN2 Unblocking Key (obsolete terms for UNBLOCK CHV1 and
UNBLOCK CHV2, respectively)
RAND
A RANDom challenge issued by the network
RFU
SDN
Service Dialling Number
SIM
Subscriber Identity Module
SMS
Short Message Service
SRES
Signed RESponse calculated by a SIM
SSC
Supplementary Service Control string
SW1/SW2
TMSI
Temporary Mobile Subscriber Identity
TON
Type Of Number
TP
TPDU
Transfer Protocol Data Unit
TS
UNBLOCK CHV1/2 value to unblock CHV1/CHV2
VBS
Voice Broadcast Service
VGCS
Voice Group Call Service
VPLMN
Visited PLMN
3.3
Symbols
Vcc
Supply voltage
Vpp
Programming voltage
'0' to '9' and 'A' to 'F' The sixteen hexadecimal digits
4
Physical characteristics
Two physical types of SIM are specified. These are the "ID-1 SIM" and the "Plug-in SIM".
The physical characteristics of both types of SIM shall be in accordance with ISO 7816-1,2 [24, 25] unless otherwise
specified. The following additional requirements shall be applied to ensure proper operation in the GSM environment.
ETSI
4.1
14
TS 100 977 V6.2.0 (1999-05)
Format and layout
The information on the exterior of either SIM should include at least the individual account identifier and the check digit
of the IC Card Identification (see clause 10, EFICCID).
4.1.1
ID-1 SIM
Format and layout of the ID-1 SIM shall be in accordance with ISO 7816-1,2 [24, 25].
The card shall have a polarization mark (see GSM 02.07 [3]) which indicates how the user should insert the card into the
ME.
The ME shall accept embossed ID-1 cards. The embossing shall be in accordance with ISO/IEC 7811 [22, 23]. The
contacts of the ID-1 SIM shall be located on the front (embossed face, see ISO/IEC 7810 [21]) of the card.
NOTE:
4.1.2
Card warpage and tolerances are now specified for embossed cards in ISO/IEC 7810 [21].
Plug-in SIM
The Plug-in SIM has a width of 25 mm, a height of 15 mm, a thickness the same as an ID-1 SIM and a feature for
orientation. See figure A.1 in normative annex A for details of the dimensions of the card and the dimensions and
location of the contacts.
Annexes A.1 and A.2 of ISO 7816-1 [24] do not apply to the Plug-in SIM.
Annex A of ISO 7816-2 [25] applies with the location of the reference points adapted to the smaller size. The three
reference points P1, P2 and P3 measure 7,5 mm, 3,3 mm and 20,8 mm, respectively, from 0. The values in table A.1 of
ISO 7816-2 [25] are replaced by the corresponding values of figure A.1.
4.2
Temperature range for card operation
The temperature range for full operational use shall be between -25°C and +70°C with occasional peaks of up to +85°C.
"Occasional" means not more than 4 hours each time and not over 100 times during the life time of the card.
4.3
Contacts
4.3.1
Provision of contacts
ME: Contacting elements in the ME in positions C4 and C8 are optional, and are not used in the GSM application.
They shall present a high impedance to the SIM card in the GSM application. If it is determined that the SIM is a
multi-application ICC, then these contacts may be used. Contact C6 need not be provided for Plug-in SIMs.
SIM: Contacts C4 and C8 need not be provided by the SIM, but if they are provided, then they shall not be
connected internally in the SIM if the SIM only contains the GSM application. Contact C6 shall not be bonded in
the SIM for any function other than supplying Vpp.
4.3.2
Activation and deactivation
The ME shall connect, activate and deactivate the SIM in accordance with the Operating Procedures specified in
ISO/IEC 7816-3 [26].
For any voltage level, monitored during the activation sequence, or during the deactivation sequence following soft
power-down, the order of the contact activation/deactivation shall be respected.
NOTE 1: Soft Power switching is defined in GSM 02.07 [3].
NOTE 2: It is recommended that whenever possible the deactivation sequence defined in ISO/IEC 7816-3 [26]
should be followed by the ME on all occasions when the ME is powered down.
ETSI
15
TS 100 977 V6.2.0 (1999-05)
If the SIM clock is already stopped and is not restarted, the ME is allowed to deactivate all the contacts in any order,
provided that all signals reach low level before Vcc leaves high level. If the SIM clock is already stopped and is
restarted before the deactivation sequence, then the deactivation sequence specified in ISO/IEC 7816-3 [26] subclause
5.4 shall be followed.
When Vpp is connected to Vcc, as allowed by GSM (see clause 5), then Vpp will be activated and deactivated with Vcc,
at the time of the Vcc activation/deactivation, as given in the sequences of ISO/IEC 7816-3 [26] subclauses 5.1 and 5.4.
The voltage level of Vcc, used by GSM, differs from that specified in ISO/IEC 7816-3 [26]. Vcc is powered when it has
a value between 4,5 V and 5,5 V.
4.3.3
Inactive contacts
The voltages on contacts C1, C2, C3, C6 and C7 of the ME shall be between 0 and ± 0,4 volts referenced to ground (C5)
when the ME is switched off with the power source connected to the ME. The measurement equipment shall have a
resistance of 50 kohms when measuring the voltage on C2, C3, C6 and C7. The resistance shall be 10 kohms when
measuring the voltage on C1.
4.3.4
Contact pressure
The contact pressure shall be large enough to ensure reliable and continuous contact (e.g. to overcome oxidisation and
to prevent interruption caused by vibration). The radius of any curvature of the contacting elements shall be greater than
or equal to 0,8 mm over the contact area.
Under no circumstances may a contact force be greater than 0,5 N per contact.
Care shall be taken to avoid undue point pressure to the area of the SIM opposite to the contact area. Otherwise this may
damage the components within the SIM.
4.4
Precedence
For Mobile Equipment, which accepts both an ID-1 SIM and a Plug-in SIM, the ID-1 SIM shall take precedence over
the Plug-in SIM (see GSM 02.17 [6]).
4.5
Static Protection
Considering that the SIM is a CMOS device, the ME manufacturer shall take adequate precautions (in addition to the
protection diodes inherent in the SIM) to safeguard the ME, SIM and SIM/ME interface from static discharges at all
times, and particularly during SIM insertion into the ME.
5
Electronic signals and transmission protocols
Electronic signals and transmission protocols shall be in accordance with ISO/IEC 7816-3 [26] unless specified
otherwise. The following additional requirements shall be applied to ensure proper operation in the GSM environment.
The choice of the transmission protocol(s), to be used to communicate between the SIM and the ME, shall at least
include that specified and denoted by T=0 in ISO/IEC 7816-3 [26].
The values given in the tables hereafter are derived from ISO/IEC 7816-3 [26], subclause 4.2 with the following
considerations:
-
VOH and VOL always refer to the device (ME or SIM) which is driving the interface. VIH and VIL always refer to
the device (ME or SIM) which is operating as a receiver on the interface.
-
This convention is different to the one used in ISO/IEC 7816-3 [26], which specifically defines an ICC for which
its current conventions apply. The following clauses define the specific core requirements for the SIM, which
provide also the basis for Type Approval. For each state (VOH, VIH, VIL and VOL) a positive current is defined as
flowing out of the entity (ME or SIM) in that state.
ETSI
-
16
TS 100 977 V6.2.0 (1999-05)
The high current options of ISO/IEC 7816-3 [26] for VIH and VOH are not specified for the SIM as they apply to
NMOS technology requirements. No realization of the SIM using NMOS is foreseen.
5.1
Supply voltage Vcc (contact C1)
The SIM shall be operated within the following limits:
Table 1: Electrical characteristics of Vcc under normal operating conditions
Symbol
Vcc
Icc
Minimum
4,5
Maximum
5,5
10
Unit
V
mA
The current consumption of the SIM shall not exceed the value given in table 1 during any state (including activation
and deactivation as defined in subclause 4.3.2).
When the SIM is in idle state (see below) the current consumption of the card shall not exceed 200 µA at 1 MHz and
25°C. If clock stop mode is allowed, then the current consumption shall also not exceed 200 µA while the clock is
stopped.
The ME shall source the maximum current requirements defined above. It shall also be able to counteract spikes in the
current consumption of the card up to a maximum charge of 40 nAs with no more than 400 ns duration and an amplitude
of at most 200 mA, ensuring that the supply voltage stays in the specified range.
NOTE:
5.2
A possible solution would be to place a capacitor (e.g. 100 nF, ceramic) as close as possible to the
contacting elements.
Reset (RST) (contact C2)
The ME shall operate the SIM within the following limits:
Table 2: Electrical characteristics of RST under normal operating conditions
Symbol
Conditions
Minimum
Maximum
VOH
IOHmax = +20 µA
Vcc-0,7
Vcc (note)
VOL
IOLmax = -200 µA
0V (note)
0,6 V
tR tF
Cout = Cin = 30 pF
NOTE:
5.3
400 µs
To allow for overshoot the voltage on RST shall remain between
-0,3 V and Vcc+0,3 V during dynamic operation.
Programming voltage Vpp (contact C6)
SIMs shall not require any programming voltage on Vpp. The ME need not provide contact C6. If the ME provides
contact C6, then, in the case of the ID-1 SIM the same voltage shall be supplied on Vpp as on Vcc, while in the case of
Plug-in SIMs the ME need not provide any voltage on C6. Contact C6 may be connected to Vcc in any ME but shall not
be connected to ground.
5.4
Clock CLK (contact C3)
The SIM shall support 1 to 5 MHz. The clock shall be supplied by the ME. No "internal clock" SIMs shall be used.
If a frequency of 13/4 MHz is needed by the SIM to run the authentication procedure in the allotted time (see
GSM 03.20 [11]), or to process an ENVELOPE command used for SIM Data Download, bit 2 of byte 1 in the file
characteristics shall be set to 1. Otherwise a minimum frequency of 13/8 MHz may be used.
ETSI
17
TS 100 977 V6.2.0 (1999-05)
The duty cycle shall be between 40 % and 60 % of the period during stable operation.
The ME shall operate the SIM within the following limits:
Table 3: Electrical characteristics of CLK under normal operating conditions
Symbol
Conditions
Minimum
Maximum
VOH
IOHmax = +20 µA
0,7xVcc
Vcc (note)
VOL
IOLmax = -200 µA
0 V (note)
0,5 V
tR tF
Cout = Cin = 30 pF
NOTE:
5.5
9 % of period with a maximum of
0,5 µs
To allow for overshoot the voltage on CLK shall remain between -0,3 V and
Vcc+0,3 V during dynamic operation.
I/O (contact C7)
Table 4 defines the electrical characteristics of the I/O (contact C7). The values given in the table have the effect of
defining the values of the pull-up resistor in the ME and the impedances of the drivers and receivers in the ME and SIM.
Table 4: Electrical characteristics of I/O under normal operating conditions
Symbol
VIH
Conditions
IIHmax = ± 20 µA (note 2)
Minimum
0,7xVcc
Maximum
Vcc+0,3 V
VIL
IILmax = +1 mA
-0,3 V
0,8 V
VOH (note 1)
IOHmax = + 20µA
3,8 V
Vcc (note 3)
VOL
IOLmax = -1 mA
0 V (note 3)
0,4 V
tR tF
Cout = Cin = 30 pF
1 µs
NOTE 1: It is assumed that a pull-up resistor is used in the interface device (recommended
value: 20 kohms).
NOTE 2: During static conditions (idle state) only the positive value can apply. Under
dynamic operating conditions (transmission) short term voltage spikes on the I/O
line may cause a current reversal.
NOTE 3: To allow for overshoot the voltage on I/O shall remain between -0,3 V and
Vcc+0,3 V during dynamic operation.
5.6
States
There are two states for the SIM while the power supply is on:
-
The SIM is in operating state when it executes a command. This state also includes transmission from and to the
ME.
The SIM is in idle state at any other time. It shall retain all pertinent data during this state.
The SIM may support a clock stop mode. The clock shall only be switched off subject to the conditions specified in the
file characteristics (see clause 9).
Clock stop mode. An ME of Phase 2 or later shall wait at least 1 860 clock cycles after having received the last
character, including the guard time (2 etu), of the response before it switches off the clock (if it is allowed to do so). It
shall wait at least 744 clock cycles before it sends the first command after having started the clock.
To achieve phase compatibility, the following procedure shall be adhered to:
A SIM of Phase 2 or later shall always send the status information "normal ending of the command" after the successful
interpretation of the command SLEEP received from a Phase 1 ME. An ME of Phase 2 or later shall not send a SLEEP
command.
ETSI
18
TS 100 977 V6.2.0 (1999-05)
A Phase 1 ME shall wait at least 744 clock cycles after having received the compulsory acknowledgement SW1 SW2 of
the SLEEP command before it switches off the clock (if it is allowed to do so). It shall wait at least 744 clock cycles
before it sends the first command after having started the clock.
5.7
Baudrate
The initial baudrate (during ATR) shall be: (clock frequency)/372. Subsequent baudrate shall be: (clock frequency)/372
unless the PTS procedure has been successfully performed. In that case the negotiated baudrate shall be applied
according to subclause 5.8.2.
5.8
Answer To Reset (ATR)
The ATR is information presented by the SIM to the ME at the beginning of the card session and gives operational
requirements.
5.8.1
Structure and contents
The following table gives an explanation of the characters specified in ISO/IEC 7816-3 [26] and the requirements for
their use in GSM. The answer to reset consists of at most 33 characters. The ME shall be able to receive interface
characters for transmission protocols other than T=0, historical characters and a check byte, even if only T=0 is used by
the ME.
ETSI
19
TS 100 977 V6.2.0 (1999-05)
Table 5: ATR
Character
1. Initial character
TS
2. Format
character
T0
3. Interface
character
(global)
TA1
4. Interface
character
(global)
TB1
5. Interface
character
(global)
TC1
6. Interface
character
TD1
7. Interface
character
(specific)
Contents
coding convention for all
subsequent characters
(direct or inverse
convention)
subsequent interface
characters, number of
historical characters
parameters to calculate the
work etu
sent by
the card
always
a) evaluation by the ME
b) reaction by the ME
a) always
b) using appropriate convention
always
a) always
optional
b) identifying the subsequent
characters accordingly
a) always if present
b) if TA1 is not '11', PTS procedure
shall be used (see subclause 5.8.2)
programming voltage and
current
optional
extra guardtime requested
by the card; no extra
guardtime is used to send
characters from the card to
the ME
protocol type; indicator for
the presence of interface
characters, specifying rules
to be used for transmissions
with the given protocol type
not used for protocol T=0
optional
b) if PI1 is not 0, then reject the SIM (in
accordance with subclause 5.10)
b) if TC1 is neither 0 nor 255, then reject the
SIM (in accordance with subclause 5.10); see
the note after the table
optional
b) identifying the subsequent characters
accordingly
optional
a) optional
b) --------
TA2
8. Interface
character
(global)
parameter to calculate the
programming voltage
never
the allowed value of TB1 above defines that an
external programming voltage is not applicable
TB2
9. Interface
character
(specific)
work waiting time
optional
TC2
10. Interface
character
TDi
(i>1)
b) using the work waiting time accordingly
protocol type; indicator for
the presence of interface
characters, specifying rules
to be used for transmissions
with the given protocol type
optional
(continued)
ETSI
b) identifying the subsequent characters
accordingly
20
TS 100 977 V6.2.0 (1999-05)
Table 5 (concluded): ATR
Character
Contents
11. Interface
character
characters which contain
interface characters for
other transmission protocols
TAi, TBi, TCi
(i>2)
12. Historical
characters
contents not specified in
ISO/IEC
sent by
the card
optional
a) evaluation by the ME
b) reaction by the ME
a) optional
b) --------
optional
a) optional
b) --------
T1,...,TK
13. Check
character
check byte (exclusive
-ORing)
TCK
NOTE:
5.8.2
not sent if
only T=0 is
indicated in
the ATR; in
all other
cases TCK
shall be sent
a) optional
b) --------
According to ISO/IEC 7816-3:1989/DAM2 (see annex D) N=255 indicates that the minimum delay is 12
etu for the asynchronous half-duplex character transmission protocol.
PTS procedure
Specifically related to the present document the PTS procedure according to ISO/IEC 7816-3 [26], clause 7, is applied,
only if TA1 is not equal to '11', as follows:
a) for MEs only supporting default speed (F=372, D=1)
ME
————————————— Reset —————————————>
<————————————— ATR ——————————————
PTSS = 'FF'
PTS0 = '00'
———————— PTS Request —————>
PCK = 'FF'
PTSS = 'FF'
<———————— PTS Response —————
PTS0 = '00'
PCK = 'FF'
SIM
TA1 not = '11'
Figure 1: PTS procedure
PTS Request and PTS Response consist of the three (3) characters PTSS, PTSO and PCK of which PTSS is sent first.
After this procedure the protocol T=0 and the parameters F=372, D=1 and N=0 will be used.
b) for MEs only supporting enhanced speed (F=512, D=8)
ME
————————————— Reset —————————————>
<—————————————— ATR ——————————————
PTSS = 'FF'
PTS0 = '10'
———————— PTS Request —————>
PTS1 = '94'
PCK = '7B'
PTSS = 'FF'
<———————— PTS Response —————
PTS0 = '10'
PTS1 = '94'
PCK = '7B'
SIM
TA1 = '94'
Figure 2: PTS procedure requesting enhanced speed values (F=512, D=8, see clause 5.8.3)
ETSI
21
TS 100 977 V6.2.0 (1999-05)
PTS Request and PTS Response consist of the four (4) characters PTSS, PTSO, PTS1 and PCK of which PTSS is sent
first.
After this procedure the protocol T=0 and the parameters F=512, D=8 and N=0 will be used.
5.8.3
Speed enhancement
If speed enhancement is implemented, the ME and the SIM shall at least support F=512 and D=8 in addition to F=372
and D=1. However, other values may also be supported. If the ME requests PTS using values other than those above
then the PTS procedure shall be initiated accordingly.
The SIM shall support the default value (F=372 and D=1). If the speed enhancement is supported by the SIM it is
mandatory that F=512 and D=8 is supported. However, the value in TA1 may even indicate a faster speed (F=512 and
D=16). The SIM may also support other values between the default value (F=372 and D=1) and the values indicated in
TA1. The SIM shall offer the negotiable mode, to ensure backwards compatibility with existing MEs. In the negotiable
mode the SIM will use default values even if other parameters are offered in the ATR if the PTS procedure is not
initiated.
The ME shall support the default value (F=372 and D=1). If the speed enhancement is supported in the ME it is
mandatory to support F=512 and D=8. The ME may additionally support other values.
If the SIM does not answer the PTS request within the initial waiting time the ME shall reset the SIM. After two failed
PTS attempts using F=512 and D=8 or values indicated in TA1, (no PTS response from the SIM) the ME shall initiate
PTS procedure using default values. If this also fails (no PTS response from the SIM) the ME may proceed using default
values without requesting PTS.
If the SIM does not support the values requested by the ME, the SIM shall respond to the PTS request indicating the use
of default values.
5.9
Bit/character duration and sampling time
The bit/character duration and sampling time specified in ISO/IEC 7816-3 [26], subclauses 6.1.1 and 6.1.2, are valid for
all communications.
5.10
Error handling
Following receipt of an ATR, which is not in accordance with the present document, e.g. because of forbidden ATR
characters or too few bytes being transmitted, the ME shall perform a Reset. The ME shall not reject the SIM until at
least three consecutive wrong ATRs are received.
During the transmission of the ATR and the protocol type selection, the error detection and character repetition
procedure specified in ISO/IEC 7816-3 [26], subclause 6.1.3, is optional for the ME. For the subsequent transmission on
the basis of T=0 this procedure is mandatory for the ME.
For the SIM the error detection and character repetition procedure is mandatory for all communications.
6
Logical Model
This clause describes the logical structure for a SIM, the code associated with it, and the structure of files used.
6.1
General description
Figure 3 shows the general structural relationships which may exist between files. The files are organized in a
hierarchical structure and are of one of three types as defined below. These files may be either administrative or
application specific. The operating system handles the access to the data stored in different files.
ETSI
22
TS 100 977 V6.2.0 (1999-05)
MF
DF2
EF
DF1
DF11
DF111
EF
DF12
....
EF
EF
EF
EF
EF
....
Figure 3: Organization of memory
Files are composed of a header, which is internally managed by the SIM, and optionally a body part. The information of
the header is related to the structure and attributes of the file and may be obtained by using the commands GET
RESPONSE or STATUS. This information is fixed during the administrative phase. The body part contains the data of
the file.
6.2
File identifier
A file ID is used to address or identify each specific file. The file ID consists of two bytes and shall be coded in
hexadecimal notation. They are specified in clause 10.
The first byte identifies the type of file, and for GSM is:
-
'3F': Master File;
'7F': 1st level Dedicated File;
'5F': 2nd level Dedicated File;
'2F': Elementary File under the Master File;
'6F': Elementary File under a 1st level Dedicated File;
'4F': Elementary File under 2nd level Dedicated File.
File IDs shall be subject to the following conditions:
-
the file ID shall be assigned at the time of creation of the file concerned;
no two files under the same parent shall have the same ID;
a child and any parent, either immediate or remote in the hierarchy, e.g. grandparent, shall never have the
same file ID.
In this way each file is uniquely identified.
6.3
Dedicated files
A Dedicated File (DF) is a functional grouping of files consisting of itself and all those files which contain this DF in
their parental hierarchy (that is to say it consists of the DF and its complete "subtree"). A DF "consists" only of a header
part.
Three 1st level DFs are defined in the present document:
-
DFGSM which contains the applications for both GSM and/or DCS 1800;
DFIS41 which contains the applications for IS-41 as specified by ANSI T1P1;
DFTELECOM which contains telecom service features.
ETSI
23
TS 100 977 V6.2.0 (1999-05)
All three files are immediate children of the Master File (MF) and may coexist on a multi-application card.
2nd level DFs are defined in the present document under DFGSM.
All 2nd level DFs are immediate children of the DFGSM and may coexist on a multi-application card.
6.4
Elementary files
An Elementary File (EF) is composed of a header and a body part. The following three structures of an EF are used by
GSM.
6.4.1
Transparent EF
An EF with a transparent structure consists of a sequence of bytes. When reading or updating, the sequence of bytes to
be acted upon is referenced by a relative address (offset), which indicates the start position (in bytes), and the number of
bytes to be read or updated. The first byte of a transparent EF has the relative address '00 00'. The total data length of
the body of the EF is indicated in the header of the EF.
Header
Body
NOTE:
Sequence
of bytes
This structure was previously referred to as "binary" in GSM.
Figure 4: Structure of a transparent EF
6.4.2
Linear fixed EF
An EF with linear fixed structure consists of a sequence of records all having the same (fixed) length. The first record is
record number 1. The length of a record as well as this value multiplied by the number of records are indicated in the
header of the EF.
Header
Body
Record 1
Record 2
:
:
Record n
Figure 5: Structure of a linear fixed file
There are several methods to access records within an EF of this type:
-
absolutely using the record number;
-
when the record pointer is not set it shall be possible to perform an action on the first or the last record by
using the NEXT or PREVIOUS mode;
-
when the record pointer is set it shall be possible to perform an action on this record, the next record (unless
the record pointer is set to the last record) or the previous record (unless the record pointer is set to the first
record);
-
by identifying a record using pattern seek starting:
-
forwards from the beginning of the file;
-
forwards from the record following the one at which the record pointer is set (unless the record pointer is
set to the last record);
-
backwards from the end of the file;
ETSI
-
24
TS 100 977 V6.2.0 (1999-05)
backwards from the record preceding the one at which the record pointer is set (unless the record pointer
is set to the first record).
If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it
was set prior to the action.
NOTE 1: It is not possible, at present, to have more than 255 records in a file of this type, and each record cannot be
greater than 255 bytes.
NOTE 2: This structure was previously referred to as "formatted" in GSM.
6.4.3
Cyclic EF
Cyclic files are used for storing records in chronological order. When all records have been used for storage, then the
next storage of data shall overwrite the oldest information.
An EF with a cyclic structure consists of a fixed number of records with the same (fixed) length. In this file structure
there is a link between the last record (n) and the first record. When the record pointer is set to the last record n, then the
next record is record 1. Similarly, when the record pointer is set to record 1, then the previous record is record n. The
last updated record containing the newest data is record number 1, and the oldest data is held in record number n.
Header
Body
Record 1
Record 2
:
:
Record n
Figure 6: Structure of a cyclic file
For update operations only PREVIOUS record shall be used. For reading operations, the methods of addressing are
Next, Previous, Current and Record Number.
After selection of a cyclic file (for either operation), the record pointer shall address the record updated or increased last.
If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it
was set prior to the action.
NOTE:
6.5
It is not possible, at present, to have more than 255 records in a file of this type, and each record cannot be
greater than 255 bytes.
Methods for selecting a file
After the Answer To Reset (ATR), the Master File (MF) is implicitly selected and becomes the Current Directory. Each
file may then be selected by using the SELECT function in accordance with the following rules.
Selecting a DF or the MF sets the Current Directory. After such a selection there is no current EF. Selecting an EF sets
the current EF and the Current Directory remains the DF or MF which is the parent of this EF. The current EF is always
a child of the Current Directory.
Any application specific command shall only be operable if it is specific to the Current Directory.
The following files may be selected from the last selected file:
-
any file which is an immediate child of the Current Directory;
any DF which is an immediate child of the parent of the current DF;
the parent of the Current Directory;
the current DF;
the MF.
This means in particular that a DF shall be selected prior to the selection of any of its EFs. All selections are made using
the file ID.
ETSI
25
TS 100 977 V6.2.0 (1999-05)
The following figure gives the logical structure for the GSM application. GSM defines only two levels of DFs under the
MF.
MF
E F1
D F2
D F1
EF3
E F2
E F4
D F3
EF5
Figure 7: Logical structure
The following table gives the valid selections for GSM for the logical structure in figure 7. Reselection of the last
selected file is also allowed but not shown.
Table 6: File selection
Last selected file
MF
DF1
DF2
DF3
EF1
EF2
EF3
EF4
EF5
6.6
Valid Selections
DF1, DF2, EF1
MF, DF2, DF3, EF2
MF, DF1, EF3, EF4
MF, DF1, EF5
MF, DF1, DF2
MF, DF1, DF2, DF3
MF, DF1, DF2, EF4
MF, DF1, DF2, EF3
MF, DF1, DF3
Reservation of file IDs
In addition to the identifiers used for the files specified in the present document, the following file IDs are reserved for
use by GSM.
Dedicated Files:
- administrative use:
'7F 4X', '5F1X', '5F2X'
- operational use:
'7F 10' (DFTELECOM), '7F 20' (DFGSM), '7F 21' (DFDCS1800), '7F 22' (DFIS41), and '7F 2X', where X
ranges from '3' to 'F'.
- reserved under '7F20':
'5F30' (DFIRIDIUM), '5F31' (DFGlobalstar), '5F32' (DFICO), '5F33' (DFACeS), '5F3X', where X ranges from '4' to
'F' for other MSS.
'5F40'(DFPCS-1900), '5F4Y' where Y ranges from '1' to 'F' and,
'5FYX' where Y ranges from '5' to 'F'.
Elementary files:
- administrative use:
'6F XX' in the DFs '7F 4X'; '4F XX' in the DFs '5F 1X', '5F2X'
'6F 1X' in the DFs '7F 10', '7F 20', '7F 21';
'4F 1X' in all 2nd level DFs
'2F 01', '2F EX' in the MF '3F 00';
ETSI
-
26
TS 100 977 V6.2.0 (1999-05)
operational use:
'6F 2X', '6F 3X', '6F 4X' in '7F 10' and '7F 2X';
'4F YX', where Y ranges from '2' to 'F' in all 2nd level DFs.
'2F 1X' in the MF '3F 00'.
In all the above, X ranges, unless otherwise stated, from '0' to 'F'.
7
Security features
The security aspects of GSM are described in the normative references GSM 02.09 [4] and GSM 03.20 [11]. This clause
gives information related to security features supported by the SIM to enable the following:
-
authentication of the subscriber identity to the network;
data confidentiality over the radio interface;
file access conditions.
7.1
Authentication and cipher key generation procedure
This subclause describes the authentication mechanism and cipher key generation which are invoked by the network. For
the specification of the corresponding procedures across the SIM/ME interface see clause 11.
The network sends a Random Number (RAND) to the MS. The ME passes the RAND to the SIM in the command RUN
GSM ALGORITHM. The SIM returns the values SRES and Kc to the ME which are derived using the algorithms and
processes given below. The ME sends SRES to the network. The network compares this value with the value of SRES
which it calculates for itself. The comparison of these SRES values provides the authentication. The value Kc is used by
the ME in any future enciphered communications with the network until the next invocation of this mechanism.
A subscriber authentication key Ki is used in this procedure. This key Ki has a length of 128 bits and is stored within the
SIM for use in the algorithms described below.
7.2
Algorithms and processes
The names and parameters of the algorithms supported by the SIM are defined in GSM 03.20 [11]. These are:
-
Algorithm A3 to authenticate the MS to the network;
Algorithm A8 to generate the encryption key.
These algorithms may exist either discretely or combined (into A38) within the SIM. In either case the output on the
SIM/ME interface is 12 bytes. The inputs to both A3 and A8, or A38, are Ki (128 bits) internally derived in the SIM,
and RAND (128 bits) across the SIM/ME interface. The output is SRES (32 bits)/Kc (64 bits) the coding of which is
defined in the command RUN GSM ALGORITHM in clause 9.
7.3
File access conditions
Every file has its own specific access condition for each command. The relevant access condition of the last selected file
shall be fulfilled before the requested action can take place.
For each file:
-
the access conditions for the commands READ and SEEK are identical;
the access conditions for the commands SELECT and STATUS are ALWays.
No file access conditions are currently assigned by GSM to the MF and the DFs.
The access condition levels are defined in the following table:
ETSI
27
TS 100 977 V6.2.0 (1999-05)
Table 7: Access condition level coding
Level
0
1
2
3
4 to 14
15
Access Condition
ALWays
CHV1
CHV2
Reserved for GSM Future Use
ADM
NEVer
The meaning of the file access conditions is as follows:
ALWAYS: The action can be performed without any restriction;
CHV1 (card holder verification 1): The action shall only be possible if one of the following three conditions is
fulfilled:
- a correct CHV1 value has already been presented to the SIM during the current session;
- the CHV1 enabled/disabled indicator is set to "disabled";
NOTE: Some Phase 1 and Phase 2 SIMs do not necessarily grant access when CHV1 is "disabled" and
"blocked".
- UNBLOCK CHV1 has been successfully performed during the current session;
CHV2: The action shall only be possible if one of the following two conditions is fulfilled:
- a correct CHV2 value has already been presented to the SIM during the current session;
- UNBLOCK CHV2 has been successfully performed during the current session;
ADM: Allocation of these levels and the respective requirements for their fulfilment are the responsibility of the
appropriate administrative authority
The definition of access condition ADM does not preclude the administrative authority from using ALW, CHV1,
CHV2 and NEV if required.
NEVER: The action cannot be performed over the SIM/ME interface. The SIM may perform the action
internally.
Condition levels are not hierarchical. For instance, correct presentation of CHV2 does not allow actions to be performed
which require presentation of CHV1. A condition level which has been satisfied remains valid until the end of the GSM
session as long as the corresponding secret code remains unblocked, i.e. after three consecutive wrong attempts, not
necessarily in the same card session, the access rights previously granted by this secret code are lost immediately. A
satisfied CHV condition level applies to both DFGSM and DFTELECOM.
The ME shall determine whether CHV2 is available by using the response to the STATUS command. If CHV2 is "not
initialized" then CHV2 commands, e.g. VERIFY CHV2, shall not be executable.
8
Description of the functions
This clause gives a functional description of the commands and their respective responses. Associated status conditions,
error codes and their corresponding coding are specified in clause 9.
It shall be mandatory for all cards complying with the present document to support all functions described in the present
document. The command GET RESPONSE which is needed for the protocol T=0 is specified in clause 9.
The following table lists the file types and structures together with the functions which may act on them during a GSM
session. These are indicated by an asterisk (*).
ETSI
28
TS 100 977 V6.2.0 (1999-05)
Table 8: Functions on files in GSM session
File
Function
SELECT
STATUS
READ BINARY
UPDATE BINARY
READ RECORD
UPDATE RECORD
SEEK
INCREASE
INVALIDATE
REHABILITATE
8.1
MF
*
*
DF
*
*
EF transparent
*
*
*
*
*
*
EF linear fixed
*
*
EF cyclic
*
*
*
*
*
*
*
*
*
*
*
*
SELECT
This function selects a file according to the methods described in clause 6. After a successful selection the record pointer
in a linear fixed file is undefined. The record pointer in a cyclic file shall address the last record which has been updated
or increased.
Input:
- file ID.
Output:
- if the selected file is the MF or a DF:
file ID, total memory space available, CHV enabled/disabled indicator, CHV status and other GSM specific
data;
- if the selected file is an EF:
file ID, file size, access conditions, invalidated/not invalidated indicator, structure of EF and length of the
records in case of linear fixed structure or cyclic structure.
8.2
STATUS
This function returns information concerning the current directory. A current EF is not affected by the STATUS
function. It is also used to give an opportunity for a pro-active SIM to indicate that the SIM wants to issue a SIM
Application Toolkit command to the ME.
Input:
- none.
Output:
- file ID, total memory space available, CHV enabled/disabled indicator, CHV status and other GSM specific data
(identical to SELECT above).
8.3
READ BINARY
This function reads a string of bytes from the current transparent EF. This function shall only be performed if the READ
access condition for this EF is satisfied.
Input:
- relative address and the length of the string.
Output:
- string of bytes.
8.4
UPDATE BINARY
This function updates the current transparent EF with a string of bytes. This function shall only be performed if the
UPDATE access condition for this EF is satisfied. An update can be considered as a replacement of the string already
present in the EF by the string given in the update command.
ETSI
29
TS 100 977 V6.2.0 (1999-05)
Input:
- relative address and the length of the string;
- string of bytes.
Output:
- none.
8.5
READ RECORD
This function reads one complete record in the current linear fixed or cyclic EF. The record to be read is described by
the modes below. This function shall only be performed if the READ access condition for this EF is satisfied. The
record pointer shall not be changed by an unsuccessful READ RECORD function.
Four modes are defined:
CURRENT: The current record is read. The record pointer is not affected.
ABSOLUTE: The record given by the record number is read. The record pointer is not affected.
NEXT: The record pointer is incremented before the READ RECORD function is performed and the pointed
record is read. If the record pointer has not been previously set within the selected EF, then READ RECORD
(next) shall read the first record and set the record pointer to this record.
If the record pointer addresses the last record in a linear fixed EF, READ RECORD (next) shall not cause the
record pointer to be changed, and no data shall be read.
If the record pointer addresses the last record in a cyclic EF, READ RECORD (next) shall set the record pointer
to the first record in this EF and this record shall be read.
PREVIOUS: The record pointer is decremented before the READ RECORD function is performed and the
pointed record is read. If the record pointer has not been previously set within the selected EF, then READ
RECORD (previous) shall read the last record and set the record pointer to this record.
If the record pointer addresses the first record in a linear fixed EF, READ RECORD (previous) shall not cause
the record pointer to be changed, and no data shall be read.
If the record pointer addresses the first record in a cyclic EF, READ RECORD (previous) shall set the record
pointer to the last record in this EF and this record shall be read.
Input:
- mode, record number (absolute mode only) and the length of the record.
Output:
- the record.
8.6
UPDATE RECORD
This function updates one complete record in the current linear fixed or cyclic EF. This function shall only be performed
if the UPDATE access condition for this EF is satisfied. The UPDATE can be considered as a replacement of the
relevant record data of the EF by the record data given in the command. The record pointer shall not be changed by an
unsuccessful UPDATE RECORD function.
The record to be updated is described by the modes below. Four modes are defined of which only PREVIOUS is
allowed for cyclic files:
CURRENT: The current record is updated. The record pointer is not affected.
ABSOLUTE: The record given by the record number is updated. The record pointer is not affected.
NEXT: The record pointer is incremented before the UPDATE RECORD function is performed and the pointed
record is updated. If the record pointer has not been previously set within the selected EF, then UPDATE
RECORD (next) shall set the record pointer to the first record in this EF and this record shall be updated. If the
record pointer addresses the last record in a linear fixed EF, UPDATE RECORD (next) shall not cause the record
pointer to be changed, and no record shall be updated.
ETSI
30
TS 100 977 V6.2.0 (1999-05)
PREVIOUS: For a linear fixed EF the record pointer is decremented before the UPDATE RECORD function is
performed and the pointed record is updated. If the record pointer has not been previously set within the selected
EF, then UPDATE RECORD (previous) shall set the record pointer to the last record in this EF and this record
shall be updated. If the record pointer addresses the first record in a linear fixed EF, UPDATE RECORD
(previous) shall not cause the record pointer to be changed, and no record shall be updated.
For a cyclic EF the record containing the oldest data is updated, the record pointer is set to this record and this
record becomes record number 1.
Input:
- mode, record number (absolute mode only) and the length of the record;
- the data used for updating the record.
Output:
- none.
8.7
SEEK
This function searches through the current linear fixed EF to find a record starting with the given pattern. This function
shall only be performed if the READ access condition for this EF is satisfied. Two types of SEEK are defined:
Type 1
The record pointer is set to the record containing the pattern, no output is available.
Type 2
The record pointer is set to the record containing the pattern, the output is the record number.
NOTE:
A Phase 1 SIM only executes type 1 of the SEEK function.
The SIM shall be able to accept any pattern length from 1 to 16 bytes inclusive. The length of the pattern shall not
exceed the record length.
Four modes are defined:
-
from the beginning forwards;
from the end backwards;
from the next location forwards;
from the previous location backwards.
If the record pointer has not been previously set (its status is undefined) within the selected linear fixed EF, then the
search begins:
-
with the first record in the case of SEEK from the next location forwards; or
with the last record in the case of SEEK from the previous location backwards.
After a successful SEEK, the record pointer is set to the record in which the pattern was found. The record pointer shall
not be changed by an unsuccessful SEEK function.
Input:
- type and mode;
- pattern;
- length of the pattern.
Output:
- type 1: none;
- type 2: status/record number
8.8
INCREASE
This function adds the value given by the ME to the value of the last increased/updated record of the current cyclic EF,
and stores the result into the oldest record. The record pointer is set to this record and this record becomes record
number 1. This function shall be used only if this EF has an INCREASE access condition assigned and this condition is
fulfilled (see bytes 8 and 10 in the response parameters/data of the current EF, clause 9). The SIM shall not perform the
increase if the result would exceed the maximum value of the record (represented by all bytes set to 'FF').
Input:
ETSI
31
TS 100 977 V6.2.0 (1999-05)
- the value to be added.
Output:
- value of the increased record;
- value which has been added.
8.9
VERIFY CHV
This function verifies the CHV presented by the ME by comparing it with the relevant one stored in the SIM. The
verification process is subject to the following conditions being fulfilled:
-
CHV is not disabled;
CHV is not blocked.
If the access condition for a function to be performed on the last selected file is CHV1 or CHV2, then a successful
verification of the relevant CHV is required prior to the use of the function on this file unless the CHV is disabled.
If the CHV presented is correct, the number of remaining CHV attempts for that CHV shall be reset to its initial value 3.
If the CHV presented is false, the number of remaining CHV attempts for that CHV shall be decremented. After 3
consecutive false CHV presentations, not necessarily in the same card session, the respective CHV shall be blocked and
the access condition can never be fulfilled until the UNBLOCK CHV function has been successfully performed on the
respective CHV.
Input:
- indication CHV1/CHV2, CHV.
Output:
- none.
8.10
CHANGE CHV
This function assigns a new value to the relevant CHV subject to the following conditions being fulfilled:
-
CHV is not disabled;
CHV is not blocked.
The old and new CHV shall be presented.
If the old CHV presented is correct, the number of remaining CHV attempts for that CHV shall be reset to its initial
value 3 and the new value for the CHV becomes valid.
If the old CHV presented is false, the number of remaining CHV attempts for that CHV shall be decremented and the
value of the CHV is unchanged. After 3 consecutive false CHV presentations, not necessarily in the same card session,
the respective CHV shall be blocked and the access condition can never be fulfilled until the UNBLOCK CHV function
has been performed successfully on the respective CHV.
Input:
- indication CHV1/CHV2, old CHV, new CHV.
Output:
- none.
8.11
DISABLE CHV
This function may only be applied to CHV1. The successful execution of this function has the effect that files protected
by CHV1 are now accessible as if they were marked "ALWAYS". The function DISABLE CHV shall not be executed
by the SIM when CHV1 is already disabled or blocked.
If the CHV1 presented is correct, the number of remaining CHV1 attempts shall be reset to its initial value 3 and CHV1
shall be disabled.
ETSI
32
TS 100 977 V6.2.0 (1999-05)
If the CHV1 presented is false, the number of remaining CHV1 attempts shall be decremented and CHV1 remains
enabled. After 3 consecutive false CHV1 presentations, not necessarily in the same card session, CHV1 shall be blocked
and the access condition can never be fulfilled until the UNBLOCK CHV function has been successfully performed on
CHV1.
Input:
- CHV1.
Output:
- none.
8.12
ENABLE CHV
This function may only be applied to CHV1. It is the reverse function of DISABLE CHV. The function ENABLE CHV
shall not be executed by the SIM when CHV1 is already enabled or blocked.
If the CHV1 presented is correct, the number of remaining CHV1 attempts shall be reset to its initial value 3 and CHV1
shall be enabled.
If the CHV1 presented is false, the number of remaining CHV1 attempts shall be decremented and CHV1 remains
disabled. After 3 consecutive false CHV1 presentations, not necessarily in the same card session, CHV1 shall be
blocked and may optionally be set to "enabled". Once blocked, the CHV1 can only be unblocked using the UNBLOCK
CHV function. If the CHV1 is blocked and "disabled", the access condition shall remain granted. If the CHV1 is
blocked and "enabled", the access condition can never be fulfilled until the UNBLOCK CHV function has been
successfully performed on CHV1.
Input:
- CHV1.
Output:
- none.
8.13
UNBLOCK CHV
This function unblocks a CHV which has been blocked by 3 consecutive wrong CHV presentations. This function may
be performed whether or not the relevant CHV is blocked.
If the UNBLOCK CHV presented is correct, the value of the CHV, presented together with the UNBLOCK CHV, is
assigned to that CHV, the number of remaining UNBLOCK CHV attempts for that UNBLOCK CHV is reset to its
initial value 10 and the number of remaining CHV attempts for that CHV is reset to its initial value 3. After a successful
unblocking attempt the CHV is enabled and the relevant access condition level is satisfied.
If the presented UNBLOCK CHV is false, the number of remaining UNBLOCK CHV attempts for that UNBLOCK
CHV shall be decremented. After 10 consecutive false UNBLOCK CHV presentations, not necessarily in the same card
session, the respective UNBLOCK CHV shall be blocked. A false UNBLOCK CHV shall have no effect on the status of
the respective CHV itself.
Input:
- indication CHV1/CHV2, the UNBLOCK CHV and the new CHV.
Output:
- none.
8.14
INVALIDATE
This function invalidates the current EF. After an INVALIDATE function the respective flag in the file status shall be
changed accordingly. This function shall only be performed if the INVALIDATE access condition for the current EF is
satisfied.
An invalidated file shall no longer be available within the application for any function except for the SELECT and the
REHABILITATE functions unless the file status of the EF indicates that READ and UPDATE may also be performed.
Input:
ETSI
33
TS 100 977 V6.2.0 (1999-05)
- none.
Output:
- none.
8.15
REHABILITATE
This function rehabilitates the invalidated current EF. After a REHABILITATE function the respective flag in the file
status shall be changed accordingly. This function shall only be performed if the REHABILITATE access condition for
the current EF is satisfied.
If BDN is enabled (see clause 11.5.1) then the REHABILITATE function shall not rehabilitate the invalidated EFIMSI
and EFLOCI until the PROFILE DOWNLOAD procedure is performed indicating that the ME supports the "Call control
by SIM" facility (see GSM 11.14 [27]).
Input:
- none.
Output:
- none.
8.16
RUN GSM ALGORITHM
This function is used during the procedure for authenticating the SIM to a GSM network and to calculate a cipher key.
The card runs the specified algorithms A3 and A8 using a 16 byte random number and the subscriber authentication key
Ki, which is stored in the SIM. The function returns the calculated response SRES and the cipher key Kc.
The function shall not be executable unless DFGSM or any sub-directory under DFGSM has been selected as the Current
Directory and a successful CHV1 verification procedure has been performed (see 11.3.1).
Input:
- RAND.
Output:
- SRES, Kc.
The contents of Kc shall be presented to algorithm A5 by the ME in its full 64 bit format as delivered by the SIM.
8.17
SLEEP
This is an obsolete GSM function which was issued by Phase 1 MEs. The function shall not be used by an ME of Phase
2 or later.
8.18
TERMINAL PROFILE
This function is used by the ME to transmit to the SIM its capabilities concerning the SIM Application Toolkit
functionality.
Input:
- terminal profile.
Output:
- none.
8.19
ENVELOPE
This function is used to transfer data to the SIM Application Toolkit applications in the SIM.
Input:
- data string.
Output:
- The structure of the data is defined in GSM 11.14 [27].
ETSI
8.20
34
TS 100 977 V6.2.0 (1999-05)
FETCH
This function is used to transfer an Application Toolkit command from the SIM to the ME.
Input:
- none.
Output:
- data string containing an SIM Application Toolkit command for the ME.
8.21
TERMINAL RESPONSE
This function is used to transfer from the ME to the SIM the response to a previously fetched SIM Application Toolkit
command.
Input:
- data string containing the response.
Output:
- none.
9
Description of the commands
This clause states the general principles for mapping the functions described in clause 8 onto Application Protocol Data
Units which are used by the transmission protocol.
9.1
Mapping principles
An APDU can be a command APDU or a response APDU.
A command APDU has the following general format:
CLA
INS
P1
P2
P3
Data
The response APDU has the following general format:
Data
SW1
SW2
An APDU is transported by the T=0 transmission protocol without any change. Other protocols might embed an APDU
into their own transport structure (ISO/IEC 7816-3 [26]).
The bytes have the following meaning:
-
-
CLA is the class of instruction (ISO/IEC 7816-3 [26]), 'A0' is used in the GSM application;
INS is the instruction code (ISO/IEC 7816-3 [26]) as defined in this subclause for each command;
P1, P2, P3 are parameters for the instruction. They are specified in table 9. 'FF' is a valid value for P1, P2 and P3.
P3 gives the length of the data element. P3='00' introduces a 256 byte data transfer from the SIM in an outgoing
data transfer command (response direction). In an ingoing data transfer command (command direction), P3='00'
introduces no transfer of data.
SW1 and SW2 are the status words indicating the successful or unsuccessful outcome of the command.
For some of the functions described in clause 8 it is necessary for T=0 to use a supplementary transport service
command (GET RESPONSE) to obtain the output data. For example, the SELECT function needs the following two
commands:
-
the first command (SELECT) has both parameters and data serving as input for the function;
the second command (GET RESPONSE) has a parameter indicating the length of the data to be returned.
If the length of the response data is not known beforehand, then its correct length may be obtained by applying the first
command and interpreting the status words. SW1 shall be '9F' and SW2 shall give the total length of the data. Other
status words may be present in case of an error. The various cases are:
ETSI
35
TS 100 977 V6.2.0 (1999-05)
Case 1: No input / No output
CLA
INS
P1
P2
P3
lgth (='00')
SW1
SW2
'90'
'00'
SW1
SW2
'90'
'00'
SW1
SW2
'9F'
lgth1
SW1
SW2
'90'
'00'
SW1
SW2
'90'
'00'
SW1
SW2
'9F'
lgth1
SW1
SW2
'90'
'00'
Case 2: No input / Output of known length
CLA
INS
P1
P2
P3
DATA with length lgth
lgth
NOTE:
lgth='00' causes a data transfer of 256 bytes.
Case 3: No Input / Output of unknown length
CLA
INS
P1
P2
P3
lgth (='00')
GET RESPONSE
CLA
INS
P1
P2
DATA with length lgth2 ≤ lgth1
P3
lgth2
Case 4: Input / No output
CLA
INS
P1
P2
P3
lgth
Case 5: Input / Output of known or unknown length
CLA
INS
P1
P2
P3
lgth
GET RESPONSE
CLA
INS
P1
P2
P3
lgth2
For cases 3 and 5, when SW1/SW2 indicates there is response data (i.e. SW1/SW2 = '9FXX'), then, if the ME requires
to get this response data, it shall send a GET RESPONSE command as described in the relevant case above.
For case 5, in case of an ENVELOPE for SIM data download, SW1/SW2 may also indicate there is response data with
the value '9EXX', and the ME shall then send a GET RESPONSE command to get this response data.
If the GSM application is one of several applications in a multi-application card, other commands with CLA not equal to
'A0' may be sent by the terminal. This shall not influence the state of the GSM application.
The following diagrams show how the five cases of transmission protocol identified in the above diagrams can all be
used to send pro-active SIM commands. For further information on the diagrams below see GSM 11.14 [27].
Case 1: No input / "OK" response with no output, plus additional command from SIM
CLA
INS
P1
P2
P3
lgth (='00')
SW1
SW2
'91'
lgth1
SW1
SW2
'90'
'00'
[Possible "normal GSM operation" command/response pairs]
FETCH
CLA
INS
P1
P2
P3
DATA with length lgth1
lgth1
ETSI
NOTE:
36
TS 100 977 V6.2.0 (1999-05)
lgth1='00' causes a data transfer of 256 bytes.
Case 2: No input / "OK" response with data of known length, plus additional command from SIM
CLA
INS
P1
P2
P3
lgth
SW1
SW2
'91'
lgth1
SW1
SW2
'90'
'00'
FETCH
CLA
INS
P1
P2
P3
lgth1
NOTE:
lgth='00' causes a data transfer of 256 bytes. The same applies to lgth1.
Case 3: No Input / "OK" response with data of unknown length, plus additional command from SIM
CLA
INS
P1
P2
P3
lgth (='00')
GET RESPONSE
CLA
INS
P1
P2
P3
lgth2
SW1
SW2
'9F'
lgth1
SW1
SW2
'91'
lgth3
SW1
SW2
'90'
'00'
SW1
SW2
'91'
lgth1
SW1
SW2
'90'
'00'
FETCH
CLA
INS
P1
P2
P3
lgth3
Case 4: Input / "OK" response with no output data, plus additional command from SIM
CLA
INS
P1
P2
P3
lgth
FETCH
CLA
INS
P1
P2
P3
lgth1
Case 5: Input / "OK" response with data of known or unknown length, plus additional command from SIM
CLA
INS
P1
P2
P3
lgth
GET RESPONSE
CLA
INS
P1
P2
DATA with length lgth2≤lgth1
P3
lgth2
SW1
SW2
'9F'
lgth1
SW1
SW2
'91'
lgth3
SW1
SW2
'90'
'00'
FETCH
CLA
INS
P1
P2
P3
lgth3
ETSI
9.2
37
TS 100 977 V6.2.0 (1999-05)
Coding of the commands
Table 9 below gives the coding of the commands. The direction of the data is indicated by (S) and (R), where (S) stands
for data sent by the ME while (R) stands for data received by the ME. Offset is coded on 2 bytes where P1 gives the
high order byte and P2 the low order byte. '00 00' means no offset and reading/updating starts with the first byte while an
offset of '00 01' means that reading/updating starts with the second byte.
In addition to the instruction codes specified in table 9 the following codes are reserved:
GSM operational phase:
'1X' with X even, from X=6 to X=E.
Administrative management phase:
'2A', 'D0', 'D2', 'DE', 'C4', 'C6', 'C8', 'CA', 'CC', 'B4', 'B6', 'B8', 'BA' and 'BC'.
Table 9: Coding of the commands
COMMAND
SELECT
STATUS
INS
'A4'
'F2'
P1
'00'
'00'
P2
'00'
'00'
P3
'02'
lgth
S/R
S/R
R
READ BINARY
UPDATE BINARY
READ RECORD
UPDATE RECORD
SEEK
INCREASE
'B0'
'D6'
'B2'
'DC'
'A2'
'32'
offset high
offset high
rec No.
rec No.
'00'
'00'
offset low
offset low
mode
mode
type/mode
'00'
lgth
lgth
lgth
lgth
lgth
'03'
R
S
R
S
S/R
S/R
VERIFY CHV
CHANGE CHV
DISABLE CHV
ENABLE CHV
UNBLOCK CHV
'20'
'24'
'26'
'28'
'2C'
'00'
'00'
'00'
'00'
'00'
CHV No.
CHV No.
'01'
'01'
see note
'08'
'10'
'08'
'08'
'10'
S
S
S
S
S
INVALIDATE
REHABILITATE
'04'
'44'
'00'
'00'
'00'
'00'
'00'
'00'
-
RUN GSM ALGORITHM
'88'
'00'
'00'
'10'
S/R
SLEEP
'FA'
'00'
'00'
'00'
-
GET RESPONSE
TERMINAL PROFILE
ENVELOPE
FETCH
TERMINAL RESPONSE
'C0'
'10'
'C2'
'12'
'14'
'00'
'00'
'00'
'00'
'00'
'00'
'00'
'00'
'00'
'00'
lgth
lgth
lgth
lgth
lgth
R
S
S/R
R
S
NOTE:
If the UNBLOCK CHV command applies to CHV1 then P2 is coded '00'; if it applies to CHV2 then P2 is
coded '02'.
Definitions and codings used in the response parameters/data of the commands are given in subclause 9.3.
9.2.1
SELECT
COMMAND
SELECT
CLASS
INS
P1
P2
P3
'A0'
'A4'
'00'
'00'
'02'
Command parameters/data:
Byte(s)
Description
1-2
File ID
Length
2
ETSI
38
TS 100 977 V6.2.0 (1999-05)
Response parameters/data in case of an MF or DF:
Byte(s)
Description
Length
1-2
RFU
2
3-4
Total amount of memory of the selected directory which is
not allocated to any of the DFs or EFs under the selected
directory
File ID
2
2
Type of file (see subclause 9.3)
1
RFU
5
Length of the following data (byte 14 to the end)
1
GSM specific data
21
5-6
7
8 - 12
13
14 - 34
GSM specific data:
Byte(s)
Description
Length
14
File characteristics (see detail 1)
1
15
1
18
Number of DFs which are a direct child of the current
directory
Number of EFs which are a direct child of the current
directory
Number of CHVs, UNBLOCK CHVs and administrative
codes
RFU
19
CHV1 status (see detail 2)
1
20
UNBLOCK CHV1 status (see detail 2)
1
21
CHV2 status (see detail 2)
1
22
UNBLOCK CHV2 status (see detail 2)
1
23
RFU
1
16
17
24 - 34
Reserved for the administrative management
1
1
1
0 lgth 11
Bytes 1 - 22 are mandatory and shall be returned by the SIM. Bytes 23 and following are optional and may not be
returned by the SIM.
NOTE 1: Byte 35 and following are RFU.
NOTE 2: The STATUS information of the MF, DFGSM and DFTELECOM provide some identical application
specific data, e.g. CHV status. On a multi-application card the MF should not contain any application
specific data. Such data is obtained by terminals from the specific application directories. ME
manufacturers should take this into account and therefore not use application specific data which may
exist in the MF of a mono-application SIM.
Similarly, the VERIFY CHV command should not be executed in the MF but in the relevant application
directory (e.g. DFGSM).
Detail 1: File characteristics
b8
b7
b6
b5
b4
b3
b2
b1
Clock stop (see below)
For running the authentication algorithm, or the
ENVELOPE command for SIM Data Download, a frequency
is required of at least 13/8 MHz if b2=0 and 13/4
MHz if b2=1
Clock stop (see below)
for coding (see GSM 11.12 [28])
RFU
b8=0: CHV1 enabled; b8=1: CHV1 disabled
ETSI
39
TS 100 977 V6.2.0 (1999-05)
The coding of the conditions for stopping the clock is as follows:
Bit b1
1
1
1
0
0
0
Bit b3
0
1
0
0
1
0
Bit b4
0
0
1
0
0
1
clock stop allowed, no preferred level
clock stop allowed, high level preferred
clock stop allowed, low level preferred
clock stop not allowed
clock stop not allowed, unless at high level
clock stop not allowed, unless at low level
If bit b1 (column 1) is coded 1, stopping the clock is allowed at high or low level. In this case columns 2 (bit b3)
and 3 (bit b4) give information about the preferred level (high or low, respectively) at which the clock may be
stopped.
If bit b1 is coded 0, the clock may be stopped only if the mandatory condition in column 2 (b3=1, i.e. stop at high
level) or column 3 (b4=1, i.e. stop at low level) is fulfilled. If all 3 bits are coded 0, then the clock shall not be
stopped.
Detail 2: Status byte of a secret code
b8
b7
b6
b5
b4
b3
b2
b1
Number of false presentations remaining
('0' means blocked)
RFU
b8=0: secret code not initialised,
b8=1: secret code initialised
Response parameters/data in case of an EF:
Byte(s)
Description
Length
1-2
RFU
2
3-4
File size
(for transparent EF: the length of the body part of the EF)
(for linear fixed or cyclic EF: record length multiplied by the
number of records of the EF)
File ID
2
2
7
Type of file (see 9.3)
1
8
see detail 3
1
Access conditions (see 9.3)
3
12
File status (see 9.3)
1
13
Length of the following data (byte 14 to the end)
1
14
Structure of EF (see 9.3)
1
15
Length of a record (see detail 4)
1
RFU
-
5-6
9 - 11
16 and
following
Bytes 1-14 are mandatory and shall be returned by the SIM.
Byte 15 is mandatory in case of linear fixed or cyclic EFs and shall be returned by the SIM.
Byte 15 is optional in case of transparent EFs and may not be returned by the SIM.
Byte 16 and following (when defined) are optional and may not be returned by the SIM.
Detail 3: Byte 8
For transparent and linear fixed EFs this byte is RFU. For a cyclic EF all bits except bit 7 are RFU; b7=1
indicates that the INCREASE command is allowed on the selected cyclic file.
Detail 4: Byte 15
For cyclic and linear fixed EFs this byte denotes the length of a record. For a transparent EF, this byte shall be
coded '00', if this byte is sent by the SIM.
ETSI
9.2.2
40
TS 100 977 V6.2.0 (1999-05)
STATUS
COMMAND
STATUS
CLASS
'A0'
INS
'F2'
P1
'00'
P2
'00'
P3
lgth
The response parameters/data are identical to the response parameters/data of the SELECT command in case of an MF
or DF.
9.2.3
READ BINARY
COMMAND
READ BINARY
CLASS
'A0'
INS
'B0'
P1
offset high
P2
offset low
P3
lgth
Response parameters/data:
9.2.4
Byte(s)
Description
Length
1 - lgth
Data to be read
lgth
UPDATE BINARY
COMMAND
UPDATE BINARY
CLASS
'A0'
INS
'D6'
P1
offset high
P2
offset low
P3
lgth
9.2.5
Byte(s)
Description
1 - lgth
Data
Length
lgth
READ RECORD
COMMAND
READ RECORD
CLASS
'A0'
INS
'B2'
P1
Rec.No.
P2
Mode
P3
lgth
Parameter P2 specifies the mode:
- '02' = next record;
- '03' = previous record;
- '04' = absolute mode/current mode, the record number is given in P1 with P1='00' denoting the current record.
For the modes "next" and "previous" P1 has no significance and shall be set to '00' by the ME. To ensure phase
compatibility between Phase 2 SIMs and Phase 1 MEs, the SIM shall not interpret the value given by the ME.
9.2.6
Byte(s)
Description
Length
1 - lgth
The data of the record
lgth
UPDATE RECORD
COMMAND
UPDATE RECORD
CLASS
'A0'
INS
'DC'
P1
Rec.No.
P2
Mode
P3
lgth
Parameter P2 specifies the mode:
- '02' = next record;
- '03' = previous record;
- '04' = absolute mode/current mode; the record number is given in P1 with P1='00' denoting the current record.
For the modes "next" and "previous" P1 has no significance and shall be set to '00' by the ME. To ensure phase
compatibility between Phase 2 SIMs and Phase 1 MEs, the SIM shall not interpret the value given by the ME.
ETSI
41
TS 100 977 V6.2.0 (1999-05)
9.2.7
Byte(s)
Description
1 - lgth
Data
Length
lgth
SEEK
COMMAND
SEEK
CLASS
'A0'
INS
'A2'
P1
'00'
P2
Type/Mode
P3
lgth
Parameter P2 specifies type and mode:
- 'x0' = from the beginning forward;
- 'x1' = from the end backward;
- 'x2' = from the next location forward;
- 'x3' = from the previous location backward
with x='0' specifies type 1 and x='1' specifies type 2 of the SEEK command.
Byte(s)
Description
1 - lgth
Pattern
Length
lgth
There are no response parameters/data for a type 1 SEEK. A type 2 SEEK returns the following response
parameters/data:
Byte(s)
1
9.2.8
Description
Length
Record number
1
INCREASE
COMMAND
INCREASE
CLASS
'A0'
INS
'32'
P1
'00'
P2
'00'
P3
'03'
Byte(s)
1-3
Description
Length
Value to be added
3
Byte(s)
NOTE:
9.2.9
Description
Length
1-X
Value of the increased record
X
X+1 - X+3
Value which has been added
3
X denotes the length of the record.
VERIFY CHV
COMMAND
VERIFY CHV
CLASS
'A0'
INS
'20'
Parameter P2 specifies the CHV:
- '01' = CHV1;
- '02' = CHV2.
ETSI
P1
'00'
P2
CHV No.
P3
'08'
42
TS 100 977 V6.2.0 (1999-05)
Byte(s)
1-8
9.2.10
Description
Length
CHV value
8
CHANGE CHV
COMMAND
CHANGE CHV
CLASS
'A0'
INS
'24'
P1
'00'
P2
CHV No.
P3
'10'
- '01' = CHV1;
- '02' = CHV2.
Byte(s)
9.2.11
Description
Length
1-8
Old CHV value
8
9 - 16
New CHV value
8
DISABLE CHV
COMMAND
DISABLE CHV
CLASS
'A0'
INS
'26'
P1
'00'
P2
'01'
P3
'08'
9.2.12
Byte(s)
Description
Length
1-8
CHV1 value
8
ENABLE CHV
COMMAND
ENABLE CHV
CLASS
'A0'
INS
'28'
P1
'00'
P2
'01'
P3
'08'
9.2.13
Byte(s)
Description
Length
1-8
CHV1 value
8
UNBLOCK CHV
COMMAND
UNBLOCK CHV
CLASS
'A0'
INS
'2C'
P1
'00'
P2
CHV No.
- 00 = CHV1;
- 02 = CHV2.
NOTE:
The coding '00' for CHV1 differs from the coding of CHV1 used for other commands.
ETSI
P3
'10'
43
TS 100 977 V6.2.0 (1999-05)
Byte(s)
9.2.14
Description
1-8
UNBLOCK CHV value
8
9 - 16
New CHV value
8
INVALIDATE
COMMAND
INVALIDATE
9.2.15
CLASS
'A0'
INS
'04'
P1
'00'
P2
'00'
P3
'00'
CLASS
'A0'
INS
'44'
P1
'00'
P2
'00'
P3
'00'
INS
'88'
P1
'00'
P2
'00'
P3
'10'
REHABILITATE
COMMAND
REHABILITATE
9.2.16
Length
RUN GSM ALGORITHM
COMMAND
RUN GSM
ALGORITHM
CLASS
'A0'
Byte(s)
1 - 16
Description
Length
RAND
16
Byte(s)
Description
Length
1-4
SRES
4
5 - 12
Cipher Key Kc
8
The most significant bit of SRES is coded on bit 8 of byte 1. The most significant bit of Kc is coded on bit 8 of byte 5.
9.2.17
SLEEP
COMMAND
SLEEP
NOTE:
9.2.18
CLASS
'A0'
INS
'FA'
P1
'00'
P2
'00'
P3
'00'
P1
'00'
P2
'00'
P3
lgth
This command is used by Phase 1 MEs only.
GET RESPONSE
COMMAND
GET RESPONSE
CLASS
'A0'
INS
'C0'
The response data depends on the preceding command. Response data is available after the commands RUN GSM
ALGORITHM, SEEK (type 2), SELECT, INCREASE and ENVELOPE. If the command GET RESPONSE is executed,
it is required that it is executed immediately after the command it is related to (no other command shall come between
the command/response pair and the command GET RESPONSE). If the sequence is not respected, the SIM shall send
the status information "technical problem with no diagnostic given" as a reaction to the GET RESPONSE.
Since the MF is implicitly selected after activation of the SIM, GET RESPONSE is also allowed as the first command
after activation.
The response data itself is defined in the subclause for the corresponding command.
ETSI
9.2.19
44
TS 100 977 V6.2.0 (1999-05)
TERMINAL PROFILE
COMMAND
TERMINAL PROFILE
CLASS
'A0'
INS
'10'
P1
'00'
P2
'00'
P3
lgth
length lgth. The structure of the command parameters is defined in GSM 11.14 [27].
none available
9.2.20
ENVELOPE
COMMAND
ENVELOPE
CLASS
'A0'
INS
'C2'
P1
'00'
P2
'00'
P3
lgth
The structure of the data is defined in GSM 11.14 [27].
9.2.21
FETCH
COMMAND
FETCH
CLASS
'A0'
INS
'12'
P1
'00'
P2
'00'
P3
lgth
P2
'00'
P3
lgth
none.
length lgth. The structure of the data is defined in GSM 11.14 [27].
9.2.22
TERMINAL RESPONSE
COMMAND
TERMINAL
RESPONSE
CLASS
'A0'
INS
'14'
P1
'00'
none available.
9.3
Definitions and coding
The following definitions and coding are used in the response parameters/data of the commands.
Coding
Each byte is represented by bits b8 to b1, where b8 is the most significant bit (MSB) and b1 is the least significant bit
(LSB). In each representation the leftmost bit is the MSB.
RFU
In a GSM specific card all bytes which are RFU shall be set to '00' and RFU bits to 0. Where the GSM application exists
on a multiapplication card or is built on a generic telecommunications card (e.g. TE9) then other values may apply. The
values will be defined in the appropriate specifications for such cards. These bytes and bits shall not be interpreted by an
ME in a GSM session.
ETSI
45
TS 100 977 V6.2.0 (1999-05)
File status
b8
b7
b6
b5
b4
b3
b2
b1
b1=0: invalidated; b1=1: not invalidated
RFU
b3=0: not readable or updatable when invalidated
b3=1: readable and updatable when invalidated
RFU
Bit b3 may be set to 1 in special circumstances when it is required that the EF can be read and updated even if the EF is
invalidated, e.g. reading and updating the EFADN when the FDN feature is enabled, or reading and updating the EFBDN
when the BDN feature is disabled.
Structure of file
- '00'transparent;
- '01'linear fixed;
- '03'cyclic.
Type of File
- '00'RFU;
- '01'MF;
- '02'DF;
- '04'EF.
Coding of CHVs and UNBLOCK CHVs
A CHV is coded on 8 bytes. Only (decimal) digits (0-9) shall be used, coded in CCITT T.50 [20] with bit 8 set to zero.
The minimum number of digits is 4. If the number of digits presented by the user is less than 8 then the ME shall pad the
presented CHV with 'FF' before sending it to the SIM.
The coding of the UNBLOCK CHVs is identical to the coding of the CHVs. However, the number of (decimal) digits is
always 8.
Coding of Access Conditions
The access conditions for the commands are coded on bytes 9, 10 and 11 of the response data of the SELECT command.
Each condition is coded on 4 bits as shown in table 10.
Table 10: Access conditions
ALW
CHV1
CHV2
RFU
ADM
.....
ADM
NEW
'0' *
'1' *
'2' *
'3'
'4'
..
'E'
'F' *
Entries marked "*" in the table above, are also available for use as administrative codes in addition to the ADM access
levels '4' to 'E' (refer to subclause 7.3) if required by the appropriate administrative authority. If any of these access
conditions are used, the code returned in the Access Condition bytes in the response data shall be the code applicable to
that particular level.
Byte 9:
b8
b7
b6
b5
b4
b3
b2
b1
UPDATE
READ; SEEK
ETSI
46
TS 100 977 V6.2.0 (1999-05)
Byte 10:
b8
b7
b6
b5
b4
b3
b2
b1
RFU
INCREASE
Byte 11:
b8
b7
b6
b5
b4
b3
b2
b1
INVALIDATE
REHABILITATE
9.4
Status conditions returned by the card
This subclause specifies the coding of the status words SW1 and SW2.
9.4.1
9.4.2
9.4.3
9.4.4
Responses to commands which are correctly executed
SW1
SW2
'90'
'00'
Description
- normal ending of the command
'91'
'XX'
'9E'
'XX'
'9F'
'XX'
- normal ending of the command, with extra information from the
proactive SIM containing a command for the ME. Length 'XX' of the
response data
- length 'XX' of the response data given in case of a SIM data download
error
- length 'XX' of the response data
Responses to commands which are postponed
SW1
SW2
'93'
'00'
Error description
- SIM Application Toolkit is busy. Command cannot be executed at
present, further normal commands are allowed.
Memory management
SW1
SW2
'92'
'0X'
'92'
'40'
Error description
- command successful but after using an internal update retry routine
'X' times
- memory problem
Referencing management
SW1
SW2
Error description
'94'
'00'
- no EF selected
'94'
'02'
- out of range (invalid address)
'94'
'04'
'94'
'08'
- file ID not found
- pattern not found
- file is inconsistent with the command
ETSI
9.4.5
NOTE:
9.4.6
TS 100 977 V6.2.0 (1999-05)
Security management
SW1
SW2
'98'
'02'
- no CHV initialized
'98'
'04'
'98'
'08'
-
'98'
'10'
- in contradiction with invalidation status
'98'
'40'
'98'
'50'
-
Error description
access condition not fulfilled
unsuccessful CHV verification, at least one attempt left
unsuccessful UNBLOCK CHV verification, at least one attempt left
authentication failed (see note)
in contradiction with CHV status
unsuccessful CHV verification, no attempt left
unsuccessful UNBLOCK CHV verification, no attempt left
CHV blocked
UNBLOCK CHV blocked
increase cannot be performed, Max value reached
A Phase 1 SIM may send this error code after the third consecutive unsuccessful CHV verification attempt
or the tenth consecutive unsuccessful unblocking attempt.
Application independent errors
SW1
#
47
SW2
Error description
'67'
'XX'
- incorrect parameter P3 (see note)
'6B'
'XX'#
- incorrect parameter P1 or P2 (see ##)
'6D'
'XX'#
- unknown instruction code given in the command
'6E'
'XX'#
- wrong instruction class given in the command
'6F'
'XX'#
- technical problem with no diagnostic given
These values of 'XX' are specified by ISO/IEC; at present the default value 'XX'='00' is the only one defined.
##
When the error in P1 or P2 is caused by the addressed record being out of range, then the return code '94 02' shall be
used.
NOTE:
9.4.7
'XX' gives the correct length or states that no additional information is given ('XX' = '00').
Commands versus possible status responses
The following table shows for each command the possible status conditions returned (marked by an asterisk *).
ETSI
48
TS 100 977 V6.2.0 (1999-05)
Table 11: Commands and status words
OK
Commands
Select
Status
B Mem Refer.
Status
u Sta
s
y
9 9 9 9 9 9 9 9
E F 3 2 2 4 4 4
9
0
9
1
0
0
X X X 0
X X X 0
*
*
0 4
X 0
*
*
0
0
*
*
*
*
*
*
*
*
*
*
*
*
*
Update Binary
Update Record
Read Binary
Read Record
Seek
Increase
*
*
*
*
*
Verify CHV
Change CHV
Disable CHV
Enable CHV
Unblock CHV
*
*
*
*
*
Invalidate
Rehabilitate
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Run GSM Algorithm
*
Sleep
*
Get Response
Terminal Profile
Envelope
Fetch
Terminal Response
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
0
2
0
4
*
*
*
*
Security
Status
Application
Independent
Errors
9 9
4 8
9
8
9
8
9
8
9
8
9 6
8 7
0 0
8 2
0
4
0
8
1
0
4
0
5 X X X X X
0 X X X X X
* *
* *
* *
* *
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
6 6 6 6
B D E F
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
The responses '91 XX', '93 00' and '9E XX' can only be given by a SIM supporting SIM Application Toolkit, to an ME
also supporting SIM Application Toolkit.
For the SEEK command the response '91 XX' can be given directly after a Type 1 SEEK command. Following the Type
2 SEEK command the SIM can give the response '91 XX' only after the GET RESPONSE command.
10
Contents of the Elementary Files (EF)
This clause specifies the EFs for the GSM session defining access conditions, data items and coding. A data item is a
part of an EF which represents a complete logical entity, e.g. the alpha tag in a EFADN record.
EFs or data items having an unassigned value, or, which during the GSM session, are cleared by the ME, shall have their
bytes set to 'FF'. After the administrative phase all data items shall have a defined value or have their bytes set to 'FF'. If
a data item is 'deleted' during a GSM session by the allocation of a value specified in another GSM TS, then this value
shall be used, and the data item is not unassigned; e.g. for a deleted LAI in EFLOCI the last byte takes the value 'FE'
(GSM 04.08 [15] refers).
EFs are mandatory (M) or optional (O). The file size of an optional EF may be zero. All implemented EFs with a file
size greater than zero shall contain all mandatory data items. Optional data items may either be filled with 'F', or, if
located at the end of an EF, need not exist.
When the coding is according to CCITT Recommendation T.50 [20], bit 8 of every byte shall be set to 0.
ETSI
49
TS 100 977 V6.2.0 (1999-05)
For an overview containing all files see figure 8.
10.1
Contents of the EFs at the MF level
There are only two EFs at the MF level.
10.1.1
EFICCID (ICC Identification)
This EF provides a unique identification number for the SIM.
Identifier: '2FE2'
File size: 10 bytes
Structure: transparent
Mandatory
Update activity: low
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1 - 10
-
ALWAYS
NEVER
ADM
ADM
Description
Identification number
M/O
M
Length
10 bytes
Identification number
Contents:
according to CCITT Recommendation E.118 [18]. However, network operators who are already issuing
Phase 1 SIM cards with an identification number length of 20 digits may retain this length.
Purpose:
card identification number.
Coding:
BCD, left justified and padded with 'F'; after padding the digits within a byte are swapped (see below).
However, network operators who are already issuing Phase 1 SIM cards where the digits within a byte are not
swapped may retain this configuration.
Byte 1:
b8
b7
b6
b5
b4
b3
b2
b1
LSB
:
:
MSB
LSB
:
:
MSB
of Digit 1
LSB
:
:
MSB
LSB
:
:
MSB
of Digit 3
of Digit 1
of Digit 2
of Digit 2
Byte 2:
b8
b7
b6
b5
b4
b3
b2
b1
of Digit 3
of Digit 4
of Digit 4
etc.
ETSI
10.1.2
50
TS 100 977 V6.2.0 (1999-05)
EFELP (Extended language preference)
This EF contains the codes for up to n languages. This information, determined by the user/operator, defines the
preferred languages of the user in order of priority. This information may be used by the ME for MMI purposes and for
short message handling (e.g. screening of preferred languages in SMS-CB).
When the CB Message Identifier capability is both allocated and activated the ME selects only those CB messages the
language of which corresponds to one of the languages given in this EF or in EFLP, whichever of these EFs is used (see
subclause 11.2.1). The CB message language is recognized according to GSM 03.38 by its data coding scheme.
Identifier: '2F 05'
File size: 2n bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Optional
ALW
CHV1
ADM
ADM
Bytes
1-2
3-4
Description
st
1 language code (highest prior.)
nd
2 language code
M/O
O
O
Length
2 bytes
2 bytes
2n-1 - 2n
nth language code (lowest prior.)
O
2 bytes
Coding:
each language code is a pair of alpha-numeric characters, defined in ISO 639 [30]. Each alpha-numeric
character shall be coded on one byte using the SMS default 7-bit coded alphabet as defined in GSM 03.38
[12] with bit 8 set to 0.
Unused language entries shall be set to 'FF FF'.
10.2
DFs at the GSM application level
For compatibility with other systems based on the GSM switching platform, DFs may be present as child directories of
DFGSM. The following have been defined.
DFIRIDIUM
DFGLOBALSTAR
DFICO
DFACeS
DFPCS1900
10.3
'5F30'
'5F31'
'5F32'
'5F33'
'5F40'
Contents of files at the GSM application level
The EFs in the Dedicated File DFGSM contain network related information.
10.3.1
EFLP (Language preference)
This EF contains the codes for one or more languages. This information, determined by the user/operator, defines the
preferred languages of the user in order of priority. This information may be used by the ME for MMI purposes and for
short message handling (e.g. screening of preferred languages in SMS-CB).
When the CB Message Identifier capability is both allocated and activated the ME selects only those CB messages the
language of which corresponds to one of the languages given in this EF or in EFELP, whichever of these EFs is used (see
subclause 11.2.1). The CB message language is recognized according to GSM 03.41 by its data coding scheme.
ETSI
51
Identifier: '6F05'
File size: 1-n bytes
TS 100 977 V6.2.0 (1999-05)
Mandatory
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
ALW
CHV1
ADM
ADM
Bytes
1
2
Description
st
1 language code (highest prior.)
nd
2 language code
M/O
M
O
Length
1 byte
1 byte
n
nth language code (lowest prior.)
O
1 byte
Coding: according to GSM 03.41 [14].
Using the command GET RESPONSE, the ME can determine the size of the EF.
10.3.2
EFIMSI (IMSI)
This EF contains the International Mobile Subscriber Identity (IMSI).
Identifier: '6F07'
File size: 9 bytes
Mandatory
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2-9
CHV1
ADM
ADM
CHV1
Description
length of IMSI
IMSI
M/O
M
M
Length
1 byte
8 bytes
-
length of IMSI
Contents:
The length indicator refers to the number of significant bytes, not including this length byte, required for the
IMSI.
-
IMSI
Contents:
International Mobile Subscriber Identity.
Coding:
This information element is of variable length. If a network operator chooses an IMSI of less than 15 digits,
unused nibbles shall be set to 'F'.
Byte 2:
b8
b7
b6
b5
b4
b3
b2
b1
1
0
0
Parity
LSB of Digit 1
:
:
MSB of Digit 1
For the parity bit, see GSM 04.08 [15].
ETSI
52
TS 100 977 V6.2.0 (1999-05)
Byte 3:
b8
b7
b6
b5
b4
b3
b2
b1
LSB
:
:
MSB
LSB
:
:
MSB
of Digit 2
of Digit 2
of Digit 3
of Digit 3
etc.
10.3.3
EFKc (Ciphering key Kc)
This EF contains the ciphering key Kc and the ciphering key sequence number n.
Identifier: '6F20'
File size: 9 bytes
Mandatory
Update activity: high
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-8
9
-
-
CHV1
CHV1
ADM
ADM
Description
Ciphering key Kc
Ciphering key sequence number n
M/O
M
M
Length
8 bytes
1 byte
Ciphering key Kc
Coding:
The least significant bit of Kc is the least significant bit of the eighth byte. The most significant bit of Kc is
the most significant bit of the first byte.
Ciphering key sequence number n
Coding:
b8
b7
b6
b5
b4
b3
b2
b1
n
bits b4 to b8 are coded 0
NOTE:
10.3.4
GSM 04.08 [15] defines the value of n=111 as "key not available". Therefore the value '07' and not 'FF'
should be present following the administrative phase.
EFPLMNsel (PLMN selector)
This EF contains the coding for n PLMNs, where n is at least eight. This information determined by the user/operator
defines the preferred PLMNs of the user in priority order.
ETSI
Identifier: '6F30'
File size: 3n (n 8) bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-3
22 - 24
25 - 27
(3n-2)-3n
-
53
TS 100 977 V6.2.0 (1999-05)
Optional
CHV1
CHV1
ADM
ADM
Description
st
1 PLMN (highest priority)
M/O
M
Length
3 bytes
8 PLMN
th
9 PLMN
M
O
3 bytes
3 bytes
nth PLMN (lowest priority)
O
3 bytes
th
PLMN
Contents:
Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
according to GSM 04.08 [15].
If storage for fewer than the maximum possible number n is required, the excess bytes shall be set to 'FF'.
For instance, using 246 for the MCC and 81 for the MNC and if this is the first and only PLMN, the contents
reads as follows:
Bytes 1-3: '42' 'F6' '18'
Bytes 4-6: 'FF' 'FF' 'FF'
etc.
10.3.5
EFHPLMN (HPLMN search period)
This EF contains the interval of time between searches for the HPLMN (see GSM 02.11 [5]).
Identifier: '6F31'
File size: 1 byte
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
-
Mandatory
CHV1
ADM
ADM
ADM
Description
Time interval
M/O
M
Length
1 byte
Time interval
Contents:
The time interval between two searches.
Coding:
The time interval is coded in integer multiples of n minutes. The range is from n minutes to a maximum value.
The value '00' indicates that no attempts shall be made to search for the HPLMN. The encoding is:
-
'00': No HPLMN search attempts
'01': n minutes
'02': 2n minutes
:
:
'YZ': (16Y+Z)n minutes (maximum value)
All other values shall be interpreted by the ME as a default period.
For specification of the integer timer interval n, the maximum value and the default period refer to GSM 02.11 [5].
ETSI
10.3.6
54
TS 100 977 V6.2.0 (1999-05)
EFACMmax (ACM maximum value)
This EF contains the maximum value of the accumulated call meter. This EF shall always be allocated if EFACM is
allocated.
Identifier: '6F37'
File size: 3 bytes
Optional
Access Conditions:
READ
UPDATE
CHV1
CHV1/CHV2
(fixed during administrative management)
ADM
ADM
INVALIDATE
REHABILITATE
Bytes
1-3
-
Description
M/O
M
Maximum value
Maximum value
Contents:
maximum value of the Accumulated Call Meter (ACM)
Coding:
First byte:
b8
b7
b6
b5
b4
b3
b2
b1
223
222
221
220
219
218
217
216
Second byte:
b8
b7
b6
b5
b4
b3
b2
b1
215
214
213
212
211
210
29
28
b8
b7
b6
b5
b4
b3
b2
b1
27
26
25
24
23
22
21
20
Third byte:
For instance, '00' '00' '30' represents 25+24.
All ACM data is stored in the SIM and transmitted over the SIM/ME interface as binary.
ACMmax is not valid, as defined in GSM 02.24 [7], if it is coded '000000'.
ETSI
Length
3 bytes
10.3.7
55
TS 100 977 V6.2.0 (1999-05)
EFSST (SIM service table)
This EF indicates which services are allocated, and whether, if allocated, the service is activated. If a service is not
allocated or not activated in the SIM, the ME shall not select this service.
Identifier: '6F38'
File size: X bytes, X 2
Mandatory
Access Conditions:
READ
CHV1
UPDATE
ADM
INVALIDATE
ADM
REHABILITATE
ADM
Bytes
Description
1
Services n¡1 to n¡4
2
3
4
5
6
7
8
etc.
X
Services (4X-3) to (4X)
-Services
Contents:
Service n°1 :
Service n°2 :
Service n°3 :
Service n°4 :
Service n°5 :
Service n°6 :
Service n°7 :
Service n°8 :
Service n°9 :
Service n°10:
Service n°11:
Service n°12:
Service n°13:
Service n°14:
Service n°15:
Service n°16:
Service n°17:
Service n°18:
Service n°19:
Service n°20:
Service n°21:
Service n°22:
Service n°23:
Service n°24:
Service n°25:
Service n°26:
Service n°27:
Service n°28:
Service n°29:
Service n°30:
Service n°31:
Service n°32:
Service n°33:
Service n°34:
Service n°35:
Service n°36
Service n°37
Service n°38
M/O
M
M
O
O
O
O
O
O
Length
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
O
1 byte
CHV1 disable function
Abbreviated Dialling Numbers (ADN)
Fixed Dialling Numbers (FDN)
Short Message Storage (SMS)
Advice of Charge (AoC)
Capability Configuration Parameters (CCP)
PLMN selector
RFU
MSISDN
Extension1
Extension2
SMS Parameters
Last Number Dialled (LND)
Group Identifier Level 1
Group Identifier Level 2
Service Provider Name
Service Dialling Numbers (SDN)
Extension3
RFU
VGCS Group Identifier List (EFVGCS and EFVGCSS)
VBS Group Identifier List (EFVBS and EFVBSS)
enhanced Multi-Level Precedence and Pre-emption Service
Automatic Answer for eMLPP
Data download via SMS-CB
Data download via SMS-PP
Menu selection
Call control
Proactive SIM
Cell Broadcast Message Identifier Ranges
Barred Dialling Numbers (BDN)
Extension4
De-personalization Control Keys
Short Message Status Reports
Network's indication of alerting in the MS
Mobile Originated Short Message control by SIM
GPRS
ETSI
56
TS 100 977 V6.2.0 (1999-05)
For a phase 2 SIM, the EF shall contain at least two bytes which correspond to the Phase 1 services. Further bytes may
be included, but if the EF includes an optional byte, then it is mandatory for the EF to also contain all bytes before that
byte. Other services are possible in the future and will be coded on further bytes in the EF. The coding falls under the
responsibility of ETSI.
NOTE 1: Service N°8 was used in Phase 1 for Called Party Subaddress. To prevent any risk of incompatibility
Service N°8 should not be reallocated.
NOTE 2: As the BDN service relies on the Call Control feature, service n°31 (BDN) should only be allocated and
activated if service n°28 (Call control) is allocated and activated.
Coding:
2 bits are used to code each service:
first bit = 1: service allocated
first bit = 0: service not allocated
where the first bit is b1, b3, b5 or b7;
second bit = 1: service activated
second bit = 0: service not activated
where the second bit is b2, b4, b6 or b8.
Service allocated means that the SIM has the capability to support the service. Service activated means that
the service is available for the card holder (only valid if the service is allocated).
The following codings are possible:
- first bit = 0: service not allocated, second bit has no meaning;
- first bit = 1 and second bit = 0: service allocated but not activated;
- first bit = 1 and second bit = 1: service allocated and activated.
The bits for services not yet defined shall be set to RFU. For coding of RFU see subclause 9.3.
First byte:
b8
b7
b6
b5
b4
b3
b2
b1
Service
Service
Service
Service
n°1
n°2
n°3
n°4
Service
Service
Service
Service
n°5
n°6
n°7
n°8
Second byte:
b8
b7
b6
b5
b4
b3
b2
b1
etc.
The following example of coding for the first byte means that service n°1 "CHV1-Disabling" is allocated but
not activated:
b8
b7
b6
b5
b4
b3
b2
b1
X
X
X
X
X
X
0
1
If the SIM supports the FDN feature (FDN allocated and activated) a special mechanism shall exist in the SIM which
invalidates both EFIMSI and EFLOCI once during each GSM session. This mechanism shall be invoked by the SIM
automatically if FDN is enabled. This invalidation shall occur at least before the next command following selection of
either EF. FDN is enabled when the ADN is invalidated or not activated.
If the SIM supports the BDN feature (BDN allocated and activated) a special mechanism shall exist in the SIM which
invalidates both EFIMSI and EFLOCI once during each GSM session and which forbids the REHABILITATE command
to rehabilitate both EFIMSI and EFLOCI until the PROFILE DOWNLOAD procedure is performed indicating that the
ME supports the "Call control by SIM" facility. This mechanism shall be invoked by the SIM automatically if BDN is
enabled. The invalidation of EFIMSI and EFLOCI shall occur at least before the next command following selection of
either EF. BDN is enabled when the EFBDN is not invalidated.
ETSI
10.3.8
57
TS 100 977 V6.2.0 (1999-05)
EFACM (Accumulated call meter)
This EF contains the total number of units for both the current call and the preceding calls.
NOTE:
The information may be used to provide an indication to the user for advice or as a basis for the
calculation of the monetary cost of calls (see GSM 02.86 [9]).
Identifier: '6F39'
Record length: 3 bytes
Access Conditions:
READ
UPDATE
INCREASE
INVALIDATE
REHABILITATE
Bytes
1-3
-
Structure: cyclic
Optional
CHV1
CHV1/CHV2
CHV1
ADM
ADM
Description
Accumulated count of units
M/O
M
Length
3 bytes
Accumulated count of units
Contents: value of the ACM
Coding: see the coding of EFACMmax
10.3.9
EFGID1 (Group Identifier Level 1)
This EF contains identifiers for particular SIM-ME associations. It can be used to identify a group of SIMs for a
particular application.
Identifier: '6F3E'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-n
Optional
CHV1
ADM
ADM
ADM
Description
SIM group identifier(s)
M/O
O
Length
n bytes
10.3.10 EFGID2 (Group Identifier Level 2)
This EF contains identifiers for particular SIM-ME associations. It can be used to identify a group of SIMs for a
particular application.
Identifier: '6F3F'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-n
NOTE:
Optional
CHV1
ADM
ADM
ADM
Description
SIM group identifier(s)
M/O
O
Length
n bytes
The structure of EFGID1 and EFGID2 are identical. They are provided to allow the network operator to
enforce different levels of security dependant on application.
ETSI
58
TS 100 977 V6.2.0 (1999-05)
10.3.11 EFSPN (Service Provider Name)
This EF contains the service provider name and appropriate requirements for the display by the ME.
Identifier: '6F46'
File Size: 17 bytes
Optional
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2 - 17
-
ALWAYS
ADM
ADM
ADM
Description
Display Condition
M/O
M
M
Length
1 byte
16 bytes
Display Condition
Contents: display condition for the service provider name in respect to the registered PLMN (see
GSM 02.07 [3]).
Coding: see below
Byte 1:
b8
b7
b6
b5
b4
b3
b2
b1
b1=0: display of registered PLMN not required
b1=1: display of registered PLMN required
RFU (see subclause 9.3)
-
Contents: service provider string to be displayed
Coding: the string shall use either
- the SMS default 7-bit coded alphabet as defined in GSM 03.38 [12] with bit 8 set to 0. The string shall be left
justified. Unused bytes shall be set to 'FF'.
- one of the UCS2 code options defined in Annex B.
10.3.12 EFPUCT (Price per unit and currency table)
This EF contains the Price per Unit and Currency Table (PUCT). The PUCT is Advice of Charge related information
which may be used by the ME in conjunction with EFACM to compute the cost of calls in the currency chosen by the
subscriber, as specified in GSM 02.24 [7]. This EF shall always be allocated if EFACM is allocated.
Identifier: '6F41'
File size: 5 bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-3
4-5
-
Optional
CHV1
CHV1/CHV2
ADM
ADM
Description
Currency code
Price per unit
M/O
M
M
Length
3 bytes
2 bytes
Currency code
Contents:
the alpha-identifier of the currency code.
Coding:
bytes 1, 2 and 3 are the respective first, second and third character of the alpha identifier. This alpha-tagging
shall use the SMS default 7-bit coded alphabet as defined in GSM 03.38 [12] with bit 8 set to 0.
ETSI
-
59
TS 100 977 V6.2.0 (1999-05)
Price per unit
Contents:
price per unit expressed in the currency coded by bytes 1-3.
Coding:
Byte 4 and bits b1 to b4 of byte 5 represent the Elementary Price per Unit (EPPU) in the currency coded by
bytes 1-3. Bits b5 to b8 of byte 5 are the decimal logarithm of the multiplicative factor represented by the
absolute value of its decimal logarithm (EX) and the sign of EX, which is coded 0 for a positive sign and 1
for a negative sign.
Byte 4:
b8
b7
b6
b5
b4
b3
b2
b1
211
210
29
28
27
26
25
24
of EPPU
Byte 5:
b8
b7
b6
b5
b4
b3
b2
b1
23
22
21
20
of EPPU
Sign of EX
20 of Abs(EX)
21 of Abs(EX)
22 of Abs(EX)
The computation of the price per unit value is made by the ME in compliance with GSM 02.24 [7] by the
following formula:
price per unit = EPPU * 10EX.
The price has to be understood as expressed in the coded currency.
10.3.13 EFCBMI (Cell broadcast message identifier selection)
This EF contains the Message Identifier Parameters which specify the type of content of the cell broadcast messages that
the subscriber wishes the MS to accept.
Any number of CB Message Identifier Parameters may be stored in the SIM. No order of priority is applicable.
Identifier: '6F45'
File size: 2n bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-2
3-4
2n-1 - 2n
-
Optional
CHV1
CHV1
ADM
ADM
Description
CB Message Identifier 1
CB Message Identifier n
M/O
O
O
Length
2 bytes
2 bytes
O
2 bytes
Coding:
as in GSM 03.41, "Message Format on BTS-MS Interface - Message Identifier".
Values listed show the types of message which shall be accepted by the MS.
Unused entries shall be set to 'FF FF'.
ETSI
60
TS 100 977 V6.2.0 (1999-05)
10.3.14 EFBCCH (Broadcast control channels)
This EF contains information concerning the BCCH according to GSM 04.08 [15].
BCCH storage may reduce the extent of a Mobile Station's search of BCCH carriers when selecting a cell. The BCCH
carrier lists in an MS shall be in accordance with the procedures specified in GSM 04.08 [15]. The MS shall only store
BCCH information from the System Information 2 message and not the 2bis extension message.
Identifier: '6F74'
File size: 16 bytes
Mandatory
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1 - 16
-
CHV1
CHV1
ADM
ADM
Description
M/O
M
BCCH information
Length
16 bytes
BCCH information
Coding:
The information is coded as octets 2-17 of the "neighbour cells description information element" in
GSM 04.08 [15].
10.3.15 EFACC (Access control class)
This EF contains the assigned access control class(es). GSM 02.11 [5] refers. The access control class is a parameter to
control the RACH utilization. 15 classes are split into 10 classes randomly allocated to normal subscribers and 5 classes
allocated to specific high priority users. For more information see GSM 02.11 [5].
Identifier: '6F78'
File size: 2 bytes
Mandatory
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-2
-
CHV1
ADM
ADM
ADM
Description
Access control classes
M/O
M
Length
2 bytes
Access control classes
Coding:
Each ACC is coded on one bit. An ACC is "allocated" if the corresponding bit is set to 1 and "not allocated"
if this bit is set to 0. Bit b3 of byte 1 is set to 0.
Byte 1:
b8
b7
b6
b5
b4
b3
b2
b1
15
14
13
12
11
10
09
08
b8
b7
b6
b5
b4
b3
b2
b1
07
06
05
04
03
02
01
00
Number of the ACC (except for bit b3)
Byte 2:
ETSI
Number of the ACC
61
TS 100 977 V6.2.0 (1999-05)
10.3.16 EFFPLMN (Forbidden PLMNs)
This EF contains the coding for four Forbidden PLMNs (FPLMN). It is read by the ME as part of the SIM initialization
procedure and indicates PLMNs which the MS shall not automatically attempt to access.
A PLMN is written to the EF if a network rejects a Location Update with the cause "PLMN not allowed". The ME shall
manage the list as follows.
When four FPLMNs are held in the EF, and rejection of a further PLMN is received by the ME from the network, the
ME shall modify the EF using the UPDATE command. This new PLMN shall be stored in the fourth position, and the
existing list "shifted" causing the previous contents of the first position to be lost.
When less than four FPLMNs exist in the EF, storage of an additional FPLMN shall not cause any existing FPLMN to
be lost.
Dependent upon procedures used to manage storage and deletion of FPLMNs in the EF, it is possible, when less than
four FPLMNs exist in the EF, for 'FFFFFF' to occur in any position. The ME shall analyse all the EF for FPLMNs in
any position, and not regard 'FFFFFF' as a termination of valid data.
Identifier: '6F7B'
File size: 12 bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-3
4-6
7-9
10 - 12
-
Mandatory
CHV1
CHV1
ADM
ADM
Description
PLMN 1
PLMN 2
PLMN 3
PLMN 4
M/O
M
M
M
M
Length
3 bytes
3 bytes
3 bytes
3 bytes
PLMN
Contents:
Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
For instance, using 246 for the MCC and 81 for the MNC and if this is stored in PLMN 3 the contents is as
follows:
Bytes 7-9: '42' 'F6' '18'
If storage for fewer than 4 PLMNs is required, the unused bytes shall be set to 'FF'.
10.3.17 EFLOCI (Location information)
This EF contains the following Location Information:
-
Temporary Mobile Subscriber Identity (TMSI)
Location Area Information (LAI)
TMSI TIME
Location update status
ETSI
62
Identifier: '6F7E'
File size: 11 bytes
Mandatory
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-4
5-9
10
11
-
TS 100 977 V6.2.0 (1999-05)
CHV1
CHV1
ADM
CHV1
Description
TMSI
LAI
TMSI TIME
M/O
M
M
M
M
TMSI
Contents: Temporary Mobile Subscriber Identity
Byte 1: first byte of TMSI
b8
b7
b6
b5
b4
b3
b2
b1
MSB
-
LAI
Contents: Location Area Information
Byte 5: first byte of LAI (MCC)
b8
b7
b6
b5
b4
b3
b2
b1
LSB
:
:
MSB
LSB
:
:
MSB
of MCC Digit 1
of MCC Digit 1
of MCC Digit 2
of MCC Digit 2
Byte 6: second byte of LAI (MCC continued)
b8
b7
b6
b5
b4
b3
b2
b1
LSB of MCC Digit 3
:
:
MSB of MCC Digit 3
bits b5 to b8 are 1
Byte 7: third byte of LAI (MNC)
b8
b7
b6
b5
b4
b3
b2
b1
LSB
:
:
MSB
LSB
:
:
MSB
of MNC Digit 1
of MNC Digit 1
of MNC Digit 2
of MNC Digit 2
Byte 8: fourth byte of LAI (LAC)
Byte 9: fifth byte of LAI (LAC continued)
-
TMSI TIME
ETSI
Length
4 bytes
5 bytes
1 byte
1 byte
63
TS 100 977 V6.2.0 (1999-05)
Contents: Current value of Periodic Location Updating Timer (T3212).
This byte is used by Phase 1 MEs, but it shall not be used by Phase 2 MEs.
-
Contents: status of location update according to GSM 04.08 [15].
Coding:
Byte 11:
Bits:
b3 b2 b1
0
0
0
: updated
0
0
1
: not updated
0
1
0
: PLMN not allowed
0
1
1
: Location Area not allowed
1
1
1
: reserved
Bits b4 to b8 are RFU (see subclause 9.3).
10.3.18 EFAD (Administrative data)
This EF contains information concerning the mode of operation according to the type of SIM, such as normal (to be
used by PLMN subscribers for GSM operations), type approval (to allow specific use of the ME during type approval
procedures of e.g. the radio equipment), cell testing (to allow testing of a cell before commercial use of this cell),
manufacturer specific (to allow the ME manufacturer to perform specific proprietary auto-test in its ME during e.g.
maintenance phases).
It also provides an indication of whether some ME features should be activated during normal operation.
Identifier: '6FAD'
File size: 3+X bytes
Mandatory
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2-3
4 - 3+X
-
-
ALW
ADM
ADM
ADM
Description
MS operation mode
Additional information
RFU
MS operation mode
Contents: mode of operation for the MS
Coding:
Initial value
- normal operation
- type approval operations
- normal operation + specific facilities
- type approval operations + specific facilities
- maintenance (off line)
- cell test operation
Coding:
- specific facilities (if b1=1 in byte 1);
Byte 2 (first byte of additional information):
b8
b7
b6
b5
b4
b3
b2
b1
RFU
ETSI
M/O
M
M
O
'00'
'80'
'01'
'81'
'02'
'04'
Length
1 byte
2 bytes
X bytes
64
TS 100 977 V6.2.0 (1999-05)
Byte 3:
b8
b7
b6
b5
b4
b3
b2
b1
b1=0: OFM to be disabled by the ME
b1=1: OFM to be activated by the ME
RFU
- ME manufacturer specific information (if b2=1 in byte 1).
10.3.19 EFPhase (Phase identification)
This EF contains information concerning the phase of the SIM.
Identifier: '6FAE'
File size: 1 byte
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
-
Mandatory
ALW
ADM
ADM
ADM
Description
SIM Phase
M/O
M
Length
1 byte
SIM Phase
Coding:
'00' : phase 1
'02' : phase 2
'03' : phase 2 and PROFILE DOWNLOAD required (see GSM 11.14 [27]).
All other codings are reserved for specification by ETSI TC SMG. Codings '04' to '0F' indicate that the SIM
supports, as a minimum, the mandatory requirements defined in this specification.
This phase identification does not preclude a SIM to support some features of a phase later than the one indicated in
EFPhase. For example : if EFPhase is coded '00', it may be assumed by the ME that some Phase 2 or Phase 2+ features are
supported by this SIM; if EFPhase is coded '02' or '03', it may be assumed by the ME that some Phase 2+ features are
supported by this SIM.
However, the services n°3 (FDN) and/or n°5 (AoC) shall only be allocated and activated in SIMs of phase 2 or later
with EFPhase being coded '02' or greater. Similarly, service n°31 (BDN) shall only be allocated and activated in SIMs
with EFPhase being coded '03' or greater.
If EFPhase is coded '03' or greater, an ME supporting SIM Application Toolkit shall perform the PROFILE
DOWNLOAD procedure, as defined in GSM 11.14 [27].
10.3.20 EFVGCS (Voice Group Call Service)
This EF contains a list of those VGCS group identifiers the user has subscribed to. The elementary file is used by the
ME for group call establishment and group call reception.
ETSI
65
Identifier: '6FB1'
File size: 4n bytes (n <= 50)
Optional
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-4
5-8
:
(4n-3)-4n
-
TS 100 977 V6.2.0 (1999-05)
CHV1
ADM
ADM
ADM
Description
Group ID 1
Group ID 2
:
Group ID n
M/O
M
O
:
O
Length
4 bytes
4 bytes
:
4 bytes
Group ID
Contents: VGCS Group Id
Coding: according to GSM 03.03 [10]
If storage for fewer than the maximum possible number of n is required, the excess bytes shall be set to 'FF'.
10.3.21 EFVGCSS (Voice Group Call Service Status)
This EF contains the status of activation for the VGCS group identifiers. The elementary file is directly related to the
EFVGCS. This EF shall always be allocated if EFVGCS is allocated.
Identifier: '6FB2'
File size: 7 bytes
Optional
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-7
-
CHV1
ADM
ADM
ADM
Description
Activation/Deactivation Flags
Contents: Activation/Deactivation Flags of the appropriate Group IDs
Coding:
bit = 0 means - Group ID deactivated
bit = 1 means - Group ID activated
Byte 1:
b8
b7
b6
b5
b4
b3
b2
b1
Group ID 1
:
:
:
:
:
:
Group ID 8
etc
:
:
:
:
:
:
:
:
ETSI
M/O
M
Length
7 bytes
66
TS 100 977 V6.2.0 (1999-05)
Byte 7:
b8
b7
b6
b5
b4
b3
b2
b1
Group ID 49
Group ID 50
1
1
1
1
1
1
10.3.22 EFVBS (Voice Broadcast Service)
This EF contains a list of those VBS group identifiers the user has subscribed to. The elementary file is used by the ME
for broadcast call establishment and broadcast call reception.
Identifier: '6FB3'
File size: 4n bytes (n <= 50)
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-4
5-2
:
(4n-3)-4n
-
Optional
CHV1
ADM
ADM
ADM
Description
Group ID 1
Group ID 2
:
Group ID n
M/O
M
O
:
O
Length
4 bytes
4 bytes
:
4 bytes
Group ID
Contents: VBS Group Id
Coding: according to GSM 03.03 [10]
If storage for fewer than the maximum possible number of n is required, the excess bytes shall be set to 'FF'.
10.3.23 EFVBSS (Voice Broadcast Service Status)
This EF contains the status of activation for the VBS group identifiers. The elementary file is directly related to the
EFVBS. This EF shall always be allocated if EFVBS is allocated.
Identifier: '6FB4'
File size: 7 bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-7
-
Optional
CHV1
ADM
ADM
ADM
Description
M/O
M
Length
7 bytes
Contents: Activation/Deactivation Flags of the appropriate Group IDs
Coding:
see coding of EFVGCS
10.3.24 EFeMLPP (enhanced Multi Level Pre-emption and Priority)
This EF contains information about priority levels and fast call set-up conditions for the enhanced Multi Level Preemption and Priority service that which can be used by the subscriber.
ETSI
67
Identifier: '6FB5'
File size: 2 bytes
Optional
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2
-
TS 100 977 V6.2.0 (1999-05)
CHV1
ADM
ADM
ADM
Description
Priority levels
Fast call set-up conditions
M/O
M
M
Length
1 byte
1 byte
Priority levels
Contents: The eMLPP priority levels subscribed to.
Coding: Each eMLPP priority level is coded on one bit. Priority levels subscribed to have their corresponding
bits set to 1. Priority levels not subscribed to have their corresponding bits set to 0. Bit b8 is reserved and set
to 0.
Byte 1:
b8
b7
b6
b5
b4
b3
b2
b1
priority
priority
priority
priority
priority
priority
priority
0
level
level
level
level
level
level
level
A
B
0
1
2
3
4
Example: If priority levels B and 2 are subscribed to, EFeMLPP shall be coded '12'.
-
Fast call set-up conditions
Contents: For each eMLPP priority level, the capability to use a fast call set-up procedure.
Coding: Each eMLPP priority level is coded on one bit. Priority levels for which fast call set-up is allowed have
their corresponding bits set to 1. Priority levels for which fast call set-up is not allowed have their
corresponding bits set to 0. Bit b8 is reserved and set to 0.
Byte 2:
b8
`
b7
b6
b5
b4
b3
b2
b1
fast
fast
fast
fast
fast
fast
fast
0
call
call
call
call
call
call
call
set-up
set-up
set-up
set-up
set-up
set-up
set-up
condition
condition
condition
condition
condition
condition
condition
for
for
for
for
for
for
for
priority
priority
priority
priority
priority
priority
priority
level
level
level
level
level
level
level
A
B
0
1
2
3
4
Example: If fast call set-up is allowed for priority levels B, 0 and 2, then byte 2 of EFeMLPP is coded '16'.
10.3.25 EFAAeM (Automatic Answer for eMLPP Service)
This EF contains those priority levels (of the Multi Level Pre-emption and Priority service) for which the mobile station
shall answer automatically to incoming calls.
ETSI
68
Identifier: '6FB6'
File size: 1 byte
Optional
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
-
TS 100 977 V6.2.0 (1999-05)
CHV1
CHV1
ADM
ADM
Description
Automatic answer priority levels
M/O
M
Length
1 byte
Automatic answer priority levels
Contents:
For each eMLPP priority level, the capability for the mobile station to answer automatically to incoming calls
(with the corresponding eMLPP priority level).
Coding:
Each eMLPP priority level is coded on one bit. Priority levels allowing an automatic answer from the mobile
station have their corresponding bits set to 1. Priority levels not allowing an automatic answer from the
mobile station have their corresponding bits set to 0. Bit b8 is reserved and set to 0.
Byte 1:
b8
b7
b6
b5
b4
b3
b2
b1
Automatic
Automatic
Automatic
Automatic
Automatic
Automatic
Automatic
0
answer
answer
answer
answer
answer
answer
answer
priority
priority
priority
priority
priority
priority
priority
for
for
for
for
for
for
for
priority
priority
priority
priority
priority
priority
priority
level
level
level
level
level
level
level
A
B
0
1
2
3
4
Example: If automatic answer is allowed for incoming calls with priority levels A, 0 and 1, then EFAAeMLPP is
coded '0D'.
10.3.26 EFCBMID (Cell Broadcast Message Identifier for Data Download)
This EF contains the message identifier parameters which specify the type of content of the cell broadcast messages
which are to be passed to the SIM.
Any number of CB message identifier parameters may be stored in the SIM. No order of priority is applicable.
Identifier: '6F48'
File size: 2n bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-2
3-4
2n-1-2n
-
Optional
CHV1
ADM
ADM
ADM
Description
CB Message Identifier n
M/O
O
O
Length
2 bytes
2 bytes
O
2 bytes
Coding:
as in GSM 03.41 [14]. Values listed show the identifiers of messages which shall be accepted by the MS to
be passed to the SIM.
Unused entries shall be set to 'FF FF'.
ETSI
69
TS 100 977 V6.2.0 (1999-05)
10.3.27 EFECC (Emergency Call Codes)
This EF contains up to 5 emergency call codes.
Identifier: '6FB7'
File size: 3n (n ≤ 5) bytes
Optional
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-3
4-6
Description
Emergency Call Code 1
Emergency Call Code 2
(3n-2) - 3n
-
ALW
ADM
ADM
ADM
Emergency Call Code n
M/O
O
O
Length
3 bytes
3 bytes
O
3 bytes
Emergency Call Code
Contents:
Emergency Call Code
Coding:
The emergency call code is of a variable length with a maximum length of 6 digits. Each emergency call code
is coded on three bytes, with each digit within the code being coded on four bits as shown below. If a code of
less that 6 digits is chosen, then the unused nibbles shall be set to 'F'.
Byte 1:
b8
b7
b6
b5
b4
b3
b2
b1
LSB
:
:
MSB
LSB
:
:
MSB
of Digit 1
LSB
:
:
MSB
LSB
:
:
MSB
of Digit 3
LSB
:
:
MSB
LSB
:
:
MSB
of Digit 5
of Digit 1
of Digit 2
of Digit 2
Byte 2:
b8
b7
b6
b5
b4
b3
b2
b1
of Digit 3
of Digit 4
of Digit 4
Byte 3:
b8
b7
b6
b5
b4
b3
b2
b1
of Digit 5
of Digit 6
of Digit 6
ETSI
70
TS 100 977 V6.2.0 (1999-05)
10.3.28 EFCBMIR (Cell broadcast message identifier range selection)
This EF contains ranges of cell broadcast message identifiers that the subscriber wishes the MS to accept.
Any number of CB Message Identifier Parameter ranges may be stored in the SIM. No order of priority is applicable.
Identifier: '6F50'
File size: 4n bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
-
Optional
CHV1
CHV1
ADM
ADM
Bytes
1-4
5-8
Description
CB Message Identifier Range 1
CB Message Identifier Range 2
M/O
O
O
Length
4 bytes
4 bytes
(4n-3) - 4n
CB Message Identifier Range n
O
4 bytes
Cell Broadcast Message Identifier Ranges
Contents:
CB Message Identifier ranges:
Coding:
bytes one and two of each range identifier equal the lower value of a cell broadcast range, bytes three and
four equal the upper value of a cell broadcast range, both values are coded as in GSM 03.41 [14] "Message
Format on BTS-MS Interface - Message Identifier". Values listed show the ranges of messages which shall be
accepted by the MS.
Unused entries shall be set to 'FF FF FF FF'.
10.3.29 EFDCK De-personalization Control Keys
This EF provides storage for the de-personalization control keys associated with the OTA de-personalization cycle of
GSM 02.22.
Identifier: '6F2C'
File size: 16 bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1 to 4
5 to 8
9 to 12
13 to 16
Optional
CHV1
CHV1
ADM
ADM
Description
8 digits of network de-personalization control
key
8 digits of network subset de-personalization
control key
8 digits of service provider de-personalization
control key
8 digits of corporate de-personalization control
key
M/O
M
Length
4 bytes
M
4 bytes
M
4 bytes
M
4 bytes
Empty control key records shall be coded 'FFFFFFFF'.
10.3.30 EFCNL(Co-operative Network List)
This EF contains the Co-operative Network List for the multiple network personalization services defined in
GSM 02.22.
ETSI
71
Identifier: '6F32'
File size: 6n bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
-
TS 100 977 V6.2.0 (1999-05)
Optional
CHV1
ADM
ADM
ADM
Bytes
1 to 6
Description
Element 1 of co-operative net list
M/O
O
Length
6 bytes
6n-5 to 6n
Element n of co-operative net list
O
6 bytes
Contents:
MCC, MNC, network subset, service provider ID and corporate ID of co-operative networks.
Coding:
For each 6 byte list element
Byte 1:
b8
b7
b6
b5
b4
b3
b2
b1
LS
:
:
MS
LS
:
:
MS
bit of MCC digit 1
LS
:
:
MS
LS
:
:
MS
bit of MCC digit 3
LS
:
:
MS
LS
:
:
MS
bit of MNC digit 1
LS
:
:
MS
LS
:
:
MS
bit of network subset digit 1
bit of MCC digit 1
bit of MCC digit 2
bit of MCC digit 2
Byte 2:
b8
b7
b6
b5
b4
b3
b2
b1
bit of MCC digit 3
bit of MNC digit 3
bit of MNC digit 3
Byte 3:
b8
b7
b6
b5
b4
b3
b2
b1
bit of MNC digit 1
bit of MNC digit 2
bit of MNC digit 2
Byte 4:
b8
b7
b6
b5
b4
b3
b2
b1
ETSI
NOTE:
72
TS 100 977 V6.2.0 (1999-05)
Digit 3 of the MNC is placed directly after the MCC fields for compatibility between GSM and PCS 1900
PLMN structures.
Byte 5:
b8
b7
b6
b5
b4
b3
b2
b1
LS
:
:
MS
LS
:
:
MS
bit of service provider digit 1
LS
:
:
MS
LS
:
:
MS
bit of corporate digit 1
Byte 6:
b8
b7
b6
b5
b4
b3
b2
b1
For 2 digit MNCs digit 3 of this field shall be 'F'.
For 1 digit network subsets digit 2 of this field shall be 0.
Empty fields shall be coded with 'FF'.
The end of the list is delimited by the first MCC field coded 'FFF'.
10.3.31 EFNIA(Network's Indication of Alerting)
This EF contains categories and associated text related to the Network's indication of alerting in the MS service defined
in GSM 02.07 [3].
Identifier: '6F51'
Record length : X+1 bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2 to X+1
Structure: linear fixed
Optional
CHV1
ADM
ADM
ADM
Description
Alerting category
Informative text
M/O
M
M
Length
1 byte
X bytes
-
Alerting category
Contents:
category of alerting for terminating traffic.
Coding:
according to GSM 04.08 [15]. Value 'FF' means that no information on alerting category is available.
-
Informative text
Contents:
text describing the type of terminating traffic associated with the category.
Coding:
see the coding of the Alpha Identifier item of the EFADN (subclause 10.4.1). The maximum number of
characters for this informative text is indicated in GSM 02.07 [3].
ETSI
73
TS 100 977 V6.2.0 (1999-05)
10.3.32 EFKcGPRS (GPRS Ciphering key KcGPRS)
This EF contains the ciphering key KcGPRS and the ciphering key sequence number n for GPRS (see GSM 03.60 [32]).
Identifier: '6F52'
File size: 9 bytes
Mandatory
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-8
9
CHV1
CHV1
ADM
ADM
Description
Ciphering key KcGPRS
Ciphering key sequence number n for GPRS
M/O
M
M
Length
8 bytes
1 byte
-
Ciphering key KcGPRS
Coding:
The least significant bit of KcGPRS is the least significant bit of the eighth byte. The most significant bit of
KcGPRS is the most significant bit of the first byte.
-
Ciphering key sequence number n for GPRS
Coding:
b8
b7
b6
b5
b4
b3
b2
b1
n
bits b4 to b8 are coded 0
NOTE:
GSM 04.08 [15] defines the value of n=111 as "key not available". Therefore the value '07' and not 'FF'
should be present following the administrative phase.
10.3.33 EFLOCIGPRS (GPRS location information)
This EF contains the following Location Information:
-
Packet Temporary Mobile Subscriber Identity (P-TMSI)
Packet Temporary Mobile Subscriber Identity signature value (P-TMSI signature value)
Routing Area Information (RAI)
Routing Area update status
Identifier: '6F53'
File size: 14 bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-4
5–7
8 - 13
14
-
Mandatory
CHV1
CHV1
ADM
ADM
Description
P-TMSI
P-TMSI signature value
RAI
Routing Area update status
P-TMSI
Contents: Packet Temporary Mobile Subscriber Identity
Byte 1: first byte of P-TMSI
ETSI
M/O
M
M
M
M
Length
4 bytes
3 bytes
6 bytes
1 byte
b8
b7
b6
b5
74
b4
b3
b2
TS 100 977 V6.2.0 (1999-05)
b1
MSB
-
P-TMSI signature value
Contents: Packet Temporary Mobile Subscriber Identity signature value
Byte 1: first byte of P-TMSI signature value
b8
b7
b6
b5
b4
b3
b2
b1
MSB
-
RAI
Contents: Routing Area Information
Byte 5: first byte of RAI
b8
b7
b6
b5
b4
b3
b2
b1
LSB
:
:
MSB
LSB
:
:
MSB
of MCC Digit 1
of MCC Digit 1
of MCC Digit 2
of MCC Digit 2
Byte 6: second byte of RAI (MCC continued)
b8
b7
b6
b5
b4
b3
b2
b1
LSB of MCC Digit 3
:
:
MSB of MCC Digit 3
bits b5 to b8 are 1
Byte 7: third byte of RAI (MNC)
b8
b7
b6
b5
b4
b3
b2
b1
LSB
:
:
MSB
LSB
:
:
MSB
of MNC Digit 1
of MNC Digit 1
of MNC Digit 2
of MNC Digit 2
Byte 8: fourth byte of RAI (LAC)
Byte 9: fifth byte of RAI (LAC continued)
Byte 10: sixth byte of RAI (RAC)- Routing update status
-
Routing update status
Contents: status of location update according to GSM 04.08 [15].
Coding:
Byte 12:
Bits:
b3 b2 b1
0
0
0
: updated
0
0
1
: not updated
0
1
0
: PLMN not allowed
0
1
1
: Routing Area not allowed
1
1
1
: reserved
Bits b4 to b8 are RFU (see subclause 9.3).
ETSI
10.4
75
TS 100 977 V6.2.0 (1999-05)
Contents of files at the telecom level
The EFs in the Dedicated File DFTELECOM contain service related information.
10.4.1
EFADN (Abbreviated dialling numbers)
This EF contains Abbreviated Dialling Numbers (ADN) and/or Supplementary Service Control strings (SSC). In
addition it contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also
contain an associated alpha-tagging.
Identifier: '6F3A'
Record length: X+14 bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1 to X
X+1
X+2
X+3 to X+12
X+13
X+14
-
Optional
CHV1
CHV1
CHV2
CHV2
Description
Alpha Identifier
Length of BCD number/SSC contents
TON and NPI
Dialling Number/SSC String
Capability/Configuration Identifier
Extension1 Record Identifier
M/O
O
M
M
M
M
M
Length
X bytes
1 byte
1 byte
10 bytes
1 byte
1 byte
Alpha Identifier
Contents:
Alpha-tagging of the associated dialling number.
Coding:
this alpha-tagging shall use either
- the SMS default 7-bit coded alphabet as defined in GSM 03.38 [12] with bit 8 set to 0. The alpha
identifier shall be left justified. Unused bytes shall be set to 'FF'.
- one of the UCS2 coded options as defined in Annex B.
NOTE 1: The value of X may be from zero to 241. Using the command GET RESPONSE the ME can determine
the value of X.
-
Contents:
this byte gives the number of bytes of the following two data items containing actual BCD number/SSC
information. This means that the maximum value is 11, even when the actual ADN/SSC information length is
greater than 11. When an ADN/SSC has extension, it is indicated by the extension1 identifier being unequal
to 'FF'. The remainder is stored in the EFEXT1 with the remaining length of the additional data being coded in
the appropriate additional record itself (see subclause 10.4.10).
Coding:
-
TON and NPI
Contents:
Type of number (TON) and numbering plan identification (NPI).
Coding:
according to GSM 04.08 [15]. If the Dialling Number/SSC String does not contain a dialling number, e.g. a
control string deactivating a service, the TON/NPI byte shall be set to 'FF' by the ME (see note 2).
NOTE 2: If a dialling number is absent, no TON/NPI byte is transmitted over the radio interface (see
GSM 04.08 [15]). Accordingly, the ME should not interpret the value 'FF' and not send it over the radio
interface.
ETSI
b8
b7
b6
b5
b4
b3
76
b2
TS 100 977 V6.2.0 (1999-05)
b1
NPI
TON
1
-
Contents:
up to 20 digits of the telephone number and/or SSC information.
Coding:
according to GSM 04.08 [15] , GSM 02.30 [8] and the extended BCD-coding (see table 12). If the telephone
number or SSC is longer than 20 digits, the first 20 digits are stored in this data item and the remainder is
stored in an associated record in the EFEXT1. The record is identified by the Extension1 Record Identifier. If
ADN/SSC require less than 20 digits, excess nibbles at the end of the data item shall be set to 'F'. Where
individual dialled numbers, in one or more records, of less than 20 digits share a common appended digit
string the first digits are stored in this data item and the common digits stored in an associated record in the
EFEXT1. The record is identified by the Extension 1 Record Identifier. Excess nibbles at the end of the data
item shall be set to 'F'.
Byte X+3
b8
b7
b6
b5
b4
b3
b2
b1
LSB
:
:
MSB
LSB
:
:
MSB
of Digit 1
LSB
:
:
MSB
LSB
:
:
MSB
of Digit 3
of Digit 1
of Digit 2
of Digit 2
Byte X+4:
b8
b7
b6
b5
b4
b3
b2
b1
of Digit 3
of Digit 4
of Digit 4
etc.
-
Contents:
capability/configuration identification byte. This byte identifies the number of a record in the EFCCP
containing associated capability/configuration parameters required for the call. The use of this byte is
optional. If it is not used it shall be set to 'FF'.
Coding:
binary.
-
Contents:
extension1 record identification byte. This byte identifies the number of a record in the EFEXT1 containing an
associated called party subaddress or additional data. The use of this byte is optional. If it is not used it shall
be set to 'FF'.
If the ADN/SSC requires both additional data and called party subaddress, this byte identifies the additional
record. A chaining mechanism inside EFEXT1 identifies the record of the appropriate called party subaddress
(see subclause 10.4.10).
Coding:
binary.
ETSI
77
TS 100 977 V6.2.0 (1999-05)
NOTE 3: As EFADN is part of the DFTELECOM it may be used by GSM and also other applications in a
multi-application card. If the non-GSM application does not recognize the use of Type of Number (TON)
and Number Plan Identification (NPI), then the information relating to the national dialling plan must be
held within the data item dialling number/SSC and the TON and NPI fields set to UNKNOWN. This
format would be acceptable for GSM operation and also for the non-GSM application where the TON and
NPI fields shall be ignored.
Example: SIM storage of an International Number using E.164 [19] numbering plan
GSM application
Other application compatible with GSM
TON
NPI
Digit field
001
000
0001
0000
abc...
xxx...abc...
where "abc..." denotes the subscriber number digits (including its country code), and "xxx..."
denotes escape digits or a national prefix replacing TON and NPI.
NOTE 4: When the ME acts upon the EFADN with a SEEK command in order to identify a character string in the
alpha-identifier, it is the responsibility of the ME to ensure that the number of characters used as SEEK
parameters are less than or equal to the value of X if the MMI allows the user to offer a greater number.
Table 12: Extended BCD coding
BCD Value
Character/Meaning
'0'
"0"
'9'
"9"
'A'
"*"
'B'
"#"
'C'
DTMF Control digit separator (GSM 02.07 [3])
'D'
"Wild" value
This will cause the MMI to prompt the user for a single digit (see
GSM 02.07 [3]).
Expansion digit ("Shift Key").
It has the effect of adding '10' to the following digit. The following BCD digit
will hence be interpreted in the range of '10'-'1E'. The purpose of digits in
this range is for further study.
Endmark
e.g. in case of an odd number of digits
'E'
'F'
BCD values 'C', 'D' and 'E' are never sent across the radio interface.
NOTE 5: The interpretation of values 'D', 'E' and 'F' as DTMF digits is for further study.
NOTE 6: A second or subsequent 'C' BCD value will be interpreted as a 3 second PAUSE (see GSM 02.07 [3]).
ETSI
10.4.2
78
TS 100 977 V6.2.0 (1999-05)
EFFDN (Fixed dialling numbers)
This EF contains Fixed Dialling Numbers (FDN) and/or Supplementary Service Control strings (SSC). In addition it
contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also contain an
associated alpha-tagging.
Identifier: '6F3B'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1 to X
X+1
X+2
X+3 to X+12
X+13
X+14
Optional
CHV1
CHV2
ADM
ADM
Description
Alpha Identifier
TON and NPI
M/O
O
M
M
M
M
M
Length
X bytes
1 byte
1 byte
10 bytes
1 byte
1 byte
For contents and coding of all data items see the respective data items of the EFADN (subclause 10.4.1), with the
exception that extension records are stored in the EFEXT2.
NOTE:
10.4.3
The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in
EFADN.
EFSMS (Short messages)
This EF contains information in accordance with GSM 03.40 [13] comprising short messages (and associated
parameters) which have either been received by the MS from the network, or are to be used as an MS originated
message.
Identifier: '6F3C'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2 to 176
Optional
CHV1
CHV1
ADM
ADM
Description
Status
Remainder
ETSI
M/O
M
M
Length
1 byte
175 bytes
-
79
TS 100 977 V6.2.0 (1999-05)
Status
Contents:
Status byte of the record which can be used as a pattern in the SEEK command. For MS originating messages
sent to the network, the status shall be updated when the MS receives a status report, or sends a successful
SMS Command relating to the status report.
Coding:
b8
b7
b6
b5
b4
b3
b2
b1
X
X
0
0
X
X
0
1
0
1
1
1
1
1
1
free space
used space
message received by MS from network; message read
message received by MS from network; message to be
read
MS originating message; message to be sent
b8
b7
b6
b5
b4
b3
b2
b1
X
0
0
1
X
0
1
0
1
1
1
1
0
0
0
0
1
1
1
1
1
1
1
0
1
MS originating message; message sent to
status report not requested
status report requested but not (yet)
status report requested, received but
in EF-SMSR;
status report requested, received and
in EF-SMSR;
the network:
received;
not stored
stored
-
Remainder
Contents:
This data item commences with the TS-Service-Centre-Address as specified in GSM 04.11 [16]. The bytes
immediately following the TS-Service-Centre-Address contain an appropriate short message TPDU as
specified in GSM 03.40 [13], with identical coding and ordering of parameters.
Coding:
according to GSM 03.40 [13] and GSM 04.11 [16]. Any TP-message reference contained in an MS
originated message stored in the SIM, shall have a value as follows:
message to be sent:
message sent to the network:
Value of the TP-message-reference:
'FF'
the value of TP-Message-Reference used in the
message sent to the network.
Any bytes in the record following the TPDU shall be filled with 'FF'.
It is possible for a TS-Service-Centre-Address of maximum permitted length, e.g. containing more than 18
address digits, to be associated with a maximum length TPDU such that their combined length is 176 bytes.
In this case the ME shall store in the SIM the TS-Service-Centre-Address and the TPDU in bytes 2-176
without modification, except for the last byte of the TPDU, which shall not be stored.
10.4.4
EFCCP (Capability configuration parameters)
This EF contains parameters of required network and bearer capabilities and ME configurations associated with a call
established using an abbreviated dialling number, a fixed dialling number, an MSISDN, a last number dialled, a service
dialling number or a barred dialling number.
ETSI
Identifier: '6F3D'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1 to 10
11 to 14
-
80
TS 100 977 V6.2.0 (1999-05)
Optional
CHV1
CHV1
ADM
ADM
Description
Bearer capability information element
Bytes reserved - see below
M/O
M
M
Length
10 bytes
4 bytes
Bearer capability information element
Contents and Coding:
see GSM 04.08 [15]. The Information Element Identity (IEI) shall be excluded. i.e. the first byte of the EFCCP
record shall be Length of the bearer capability contents.
-
10.4.5
Bytes 11-14 shall be set to 'FF' and shall not be interpreted by the ME.
EFMSISDN (MSISDN)
This EF contains MSISDN(s) related to the subscriber. In addition it contains identifiers of associated network/bearer
capabilities and identifiers of extension records. It may also contain an associated alpha-tagging.
Identifier: '6F40'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1 to X
X+1
X+2
X+3 to X+12
X+13
X+14
Optional
CHV1
CHV1
ADM
ADM
Description
Alpha Identifier
TON and NPI
M/O
O
M
M
M
M
M
Length
X bytes
1 byte
1 byte
10 bytes
1 byte
1 byte
For contents and coding of all data items see the respective data items of EFADN.
NOTE 1: If the SIM stores more than one MSISDN number and the ME displays the MSISDN number(s) within the
initialization procedure then the one stored in the first record shall be displayed with priority.
NOTE 2: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in
EFADN.
10.4.6
EFSMSP (Short message service parameters)
This EF contains values for Short Message Service header Parameters (SMSP), which can be used by the ME for user
assistance in preparation of mobile originated short messages. For example, a service centre address will often be
common to many short messages sent by the subscriber.
The EF consists of one or more records, with each record able to hold a set of SMS parameters. The first (or only)
record in the EF shall be used as a default set of parameters, if no other record is selected.
To distinguish between records, an alpha-identifier may be included within each record, coded on Y bytes.
ETSI
81
TS 100 977 V6.2.0 (1999-05)
The SMS parameters stored within a record may be present or absent independently. When a short message is to be sent
from the MS, the parameter in the SIM record, if present, shall be used when a value is not supplied by the user.
Identifier: '6F42'
Record length: 28+Y bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1 to Y
Y+1
Y+2 to Y+13
Y+14 to Y+25
Y+26
Y+27
Y+28
Optional
CHV1
CHV1
ADM
ADM
Description
Alpha-Identifier
Parameter Indicators
TP-Destination Address
TS-Service Centre Address
TP-Protocol Identifier
TP-Data Coding Scheme
TP-Validity Period
M/O
O
M
M
M
M
M
M
Length
Y bytes
1 byte
12 bytes
12 bytes
1 byte
1 byte
1 byte
Storage is allocated for all of the possible SMS parameters, regardless of whether they are present or absent. Any bytes
unused, due to parameters not requiring all of the bytes, or due to absent parameters, shall be set to 'FF'.
-
Alpha-Identifier
Contents:
Alpha Tag of the associated SMS-parameter.
Coding:
see subclause 10.4.1 (EFADN).
NOTE:
-
The value of Y may be zero, i.e. the alpha-identifier facility is not used. By using the command GET
RESPONSE the ME can determine the value of Y.
Parameter Indicators
Contents:
Each of the default SMS parameters which can be stored in the remainder of the record are marked absent or
present by individual bits within this byte.
Coding:
Allocation of bits:
Bit number Parameter indicated
1
2
TS-Service Centre Address
3
4
5
TP-Validity Period
6
reserved, set to 1
7
reserved, set to 1
8
reserved, set to 1
Bit value
0
1
Meaning
Parameter present
Parameter absent
-
Contents and Coding: As defined for SM-TL address fields in GSM 03.40 [13].
-
TP-Service Centre Address
Contents and Coding: As defined for RP-Destination address Centre Address in GSM 04.11 [16].
-
Contents and Coding: As defined in GSM 03.40 [13].
ETSI
82
TS 100 977 V6.2.0 (1999-05)
-
Contents and Coding: As defined in GSM 03.38 [12].
-
TP-Validity Period
Contents and Coding: As defined in GSM 03.40 [13] for the relative time format.
10.4.7
EFSMSS (SMS status)
This EF contains status information relating to the short message service.
The provision of this EF is associated with EFSMS. Both files shall be present together, or both absent from the SIM.
Identifier: '6F43'
File size: 2+X bytes
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2
3 to 2+X
Optional
CHV1
CHV1
ADM
ADM
Description
Last Used TP-MR
SMS "Memory Cap. Exceeded" Not. Flag
RFU
M/O
M
M
O
Length
1 byte
1 byte
X bytes
-
Last Used TP-MR.
Contents:
the value of the TP-Message-Reference parameter in the last mobile originated short message, as defined in
GSM 03.40 [13].
Coding:
as defined in GSM 03.40 [13].
-
SMS "Memory Capacity Exceeded" Notification Flag.
Contents:
This flag is required to allow a process of flow control, so that as memory capacity in the MS becomes
available, the Network can be informed. The process for this is described in GSM 03.40 [13].
Coding:
b1=1 means flag unset; memory capacity available
b1=0 means flag set
b2 to b8 are reserved and set to 1.
ETSI
10.4.8
83
TS 100 977 V6.2.0 (1999-05)
EFLND (Last number dialled)
This EF contains the last numbers dialled (LND) and/or the respective supplementary service control strings (SSC). In
contain associated alpha-tagging.
Identifier: '6F44'
Access Conditions:
READ
UPDATE
INCREASE
INVALIDATE
REHABILITATE
Bytes
1 to X
X+1
X+2
X+3 to X+12
X+13
X+14
Structure: cyclic
Optional
CHV1
CHV1
NEVER
ADM
ADM
Description
Alpha Identifier
TON and NPI
M/O
O
M
M
M
M
M
Length
X bytes
1 byte
1 byte
10 bytes
1 byte
1 byte
Contents and coding: see subclause 10.4.1 (EFADN).
The value of X in EFLND may be different to both the value of X in EFADN and of X in EFFDN.
If the value of X in EFLND is longer than the length of the α-tag of the number to be stored, then the ME shall pad the
α-tag with 'FF'. If the value of X in EFLND is shorter than the length of the α-tag of the number to be stored, then the ME
shall cut off excessive bytes.
10.4.9
EFSDN (Service Dialling Numbers)
This EF contains special service numbers (SDN) and/or the respective supplementary service control strings (SSC). In
contain associated alpha-tagging.
Identifier: '6F49'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1-X
X+1
X+2
X+3-X+12
X+13
X+14
Optional
CHV1
ADM
ADM
ADM
Description
Alpha identifier
TON and NPI
M/O
O
M
M
M
M
M
Length
X bytes
1 bytes
1 byte
10 bytes
1 byte
1 byte
For contents and coding of all data items see the respective data items of the EFADN (subclause 10.4.1), with the
exception that extension records are stored in the EFEXT3.
NOTE:
EFADN.
ETSI
84
TS 100 977 V6.2.0 (1999-05)
10.4.10 EFEXT1 (Extension1)
This EF contains extension data of an ADN/SSC, an MSISDN, or an LND. Extension data is caused by:
-
an ADN/SSC (MSISDN, LND) which is greater than the 20 digit capacity of the ADN/SSC (MSISDN, LND)
Elementary File or where common digits are required to follow an ADN/SSC string of less than 20 digits. The
remainder is stored in this EF as a record, which is identified by a specified identification byte inside the
ADN/SSC (MSISDN, LND) Elementary File. The EXT1 record in this case is specified as additional data;
-
an associated called party subaddress. The EXT1 record in this case is specified as subaddress data.
Identifier: '6F4A'
Optional
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2 to 12
13
-
CHV1
CHV1
ADM
ADM
Description
Record type
Extension data
Identifier
M/O
M
M
M
Length
1 byte
11 bytes
1 byte
Record type
Contents: type of the record
Coding:
b8
b7
b6
b5
b4
b3
b2
b1
Called Party Subaddress
Additional data
RFU
b3-b8 are reserved and set to 0;
a bit set to 1 identifies the type of record;
only one type can be set;
'00' indicates the type "unknown".
The following example of coding means that the type of extension data is "additional data":
b8
b7
b6
b5
b4
b3
b2
b1
0
0
0
0
0
0
1
0
-
Extension data
Contents: Additional data or Called Party Subaddress depending on record type.
Coding:
Case 1, Extension1 record is additional data:
The first byte of the extension data gives the number of bytes of the remainder of ADN/SSC (respectively
MSISDN, LND). The coding of remaining bytes is BCD, according to the coding of ADN/SSC
(MSISDN, LND). Unused nibbles at the end have to be set to 'F'. It is possible if the number of additional
digits exceeds the capacity of the additional record to chain another record inside the EXT1 Elementary
File by the identifier in byte 13.
Case 2, Extension1 record is Called Party Subaddress:
The subaddress data contains information as defined for this purpose in GSM 04.08 [15]. All information
defined in GSM 04.08, except the information element identifier, shall be stored in the SIM. The length of
this subaddress data can be up to 22 bytes. In those cases where two extension records are needed, these
records are chained by the identifier field. The extension record containing the first part of the called party
subaddress points to the record which contains the second part of the subaddress.
-
Identifier
Contents: identifier of the next extension record to enable storage of information longer than 11 bytes.
Coding: record number of next record. 'FF' identifies the end of the chain.
ETSI
85
TS 100 977 V6.2.0 (1999-05)
Example of a chain of extension records being associated to an ADN/SSC. The extension1 record identifier (Byte
14+X) of ADN/SSC is set to 3.
No of Record
:
:
Record 3
Record 4
Record 5
Record 6
:
:
Type
:
:
‘02’
‘xx’
‘01’
‘01’
:
:
Extension Data
:
:
xx ........xx
xx ........xx
xx ........xx
xx ........xx
:
:
Next
:
:
‘06’
‘xx’
‘FF’
‘05’
:
:
Record
In this example ADN/SSC is associated to additional data (record 3) and a called party subaddress whose length
is more than 11 bytes (records 6 and 5).
This EF contains extension data of an FDN/SSC (see EXT2 in 10.4.2).
Identifier: '6F4B'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2 to 12
13
Optional
CHV1
CHV2
ADM
ADM
Description
Record type
Extension data
Identifier
M/O
M
M
M
Length
1 byte
11 bytes
1 byte
For contents and coding see subclause 10.4.10 (EFEXT1).
This EF contains extension data of an SDN (see EXT3 in 10.4.9).
Identifier: '6F4C'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2 to 12
13
Optional
CHV1
ADM
ADM
ADM
Description
Record type
Extension data
Identifier
M/O
M
M
M
Length
1 byte
11 bytes
1 byte
For contents and coding see subclause 10.4.10 EFEXT1 .
10.4.13 EFBDN (Barred Dialling Numbers)
This EF contains Barred Dialling Numbers (BDN) and/or Supplementary Service Control strings (SSC). In addition it
contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also contain an
associated alpha-tagging.
ETSI
86
Identifier: '6F4D'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1 to X
X+1
X+2
X+3 to X+12
X+13
X+14
X+15
TS 100 977 V6.2.0 (1999-05)
Optional
CHV1
CHV2
CHV2
CHV2
Description
Alpha Identifier
TON and NPI
Comparison Method Information
M/O
O
M
M
M
M
M
M
Length
X bytes
1 byte
1 byte
10 bytes
1 byte
1 byte
1 byte
For contents and coding of all data items, except for the Comparison Method Information, see the respective data items
of the EFADN (subclause 10.4.1), with the exception that extension records are stored in the EFEXT4.
NOTE:
-
EFADN.
Comparison Method Information
Contents:
this byte describes the comparison method which is associated with that BDN. Its interpretation is not
specified but it shall be defined by the operators implementing the BDN feature on their SIMs.
Coding:
binary; values from 0 to 255 are allowed.
This EF contains extension data of an BDN/SSC (see EXT4 in 10.4.13).
Identifier: '6F4E'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2 to 12
13
Optional
CHV1
CHV2
ADM
ADM
Description
Record type
Extension data
Identifier
M/O
M
M
M
Length
1 byte
11 bytes
1 byte
For contents and coding see subclause 10.4.10 EFEXT1 .
10.4.15 EFSMSR (Short message status reports)
This EF contains information in accordance with GSM 03.40 [13] comprising short message status reports which have
been received by the MS from the network.
Each record is used to store the status report of a short message in a record of EFSMS. The first byte of each record is the
link between the status report and the corresponding short message in EFSMS.
ETSI
87
Identifier: '6F47'
Access Conditions:
READ
UPDATE
INVALIDATE
REHABILITATE
Bytes
1
2 - 30
TS 100 977 V6.2.0 (1999-05)
Optional
CHV1
CHV1
ADM
ADM
Description
SMS record identifier
SMS status report
M/O
M
M
Length
1
29 bytes
-
SMS record identifier
Contents:
This data item identifies the corresponding SMS record in EFSMS, e.g. if this byte is coded '05' then this status
report corresponds to the short message in record #5 of EFSMS.
Coding:
'00' - empty record
'01' - 'FF' - record number of the corresponding SMS in EFSMS.
-
SMS status report
Contents:
This data item contains the SMS-STATUS-REPORT TPDU as specified in GSM 03.40 [13], with identical
coding and ordering of parameters.
Coding:
according to GSM 03.40 [13]. Any bytes in the record following the TPDU shall be filled with 'FF'.
10.5
Files of GSM (figure 8)
This subclause contains a figure depicting the file structure of the SIM. DFGSM shall be selected using the identifier
'7F20'. If selection by this means fails, then DCS 1800 MEs shall, and optionally GSM MEs may then select DFGSM
with '7F21'.
NOTE 1: The selection of the GSM application using the identifier '7F21', if selection by means of the identifier
'7F20' fails, is to ensure backwards compatibility with those Phase 1 SIMs which only support the
DCS 1800 application using the Phase 1 directory DFDCS1800 coded '7F21'.
NOTE 2: To ensure backwards compatibility with those Phase 1 DCS 1800 MEs which have no means to select
DFGSM two options have been specified. These options are given in GSM 09.91 [17].
ETSI
88
TS 100 977 V6.2.0 (1999-05)
MF
'3F00'
DFGSM
'7F20'
DFTELECOM
'7F10'
DFIS-41
'7F22'
EFICCID
'2FE2'
EFELP
'2F05'
s
EFADN
'6F3A'
EFFDN
'6F3B'
EFSMS
'6F3C'
EFCCP
'6F3D'
EFMSISDN
'6F40'
EFSMSP
'6F42'
EFSMSS
'6F43'
EFLND
'6F44'
EFSMSR
'6F47'
EFSDN
'6F49'
EFEXT1
'6F4A'
EFEXT2
'6F4B'
EFEXT3
'6F4C'
EFBDN
'6F4D'
EFEXT4
'6F4E'
DFGLOBST
'5F31'
DFICO
'5F32'
DFACeS
'5F33'
EFLP
'6F05'
EFIMSI
'6F07'
EFKc
'6F20'
EFPLMNsel
'6F30'
EFHPLMN
'6F31'
EFACMmax
'6F37'
EFSST
'6F38'
EFACM
'6F39'
EFGID1
'6F3E'
EFGID2
'6F3F'
EFPUCT
'6F41'
EFCBMI
'6F45'
EFSPN
'6F46'
EFCBMID
'6F48'
EFBCCH
'6F74'
EFACC
'6F78'
EFFPLMN
'6F7B'
EFLOCI
'6F7E'
EFAD
'6FAD'
EFPHASE
'6FAE'
EFVGCS
'6FB1'
EFVGCSS
'6FB2'
EFVBS
'6FB3'
EFVBSS
'6FB4'
EFeMLPP
'6FB5'
EFAAeM
'6FB6'
EFECC
'6FB7'
EFCBMIR
'6F50'
EFNIA
'6F51'
EFKcGPRS
'6F52'
DFIRIDIUM
'5F30'
DFPCS1900
'5F40'
EFLOCIGPRS
'6F53'
Figure 8: File identifiers and directory structures of GSM
11
Application protocol
When involved in GSM administrative management operations, the SIM interfaces with appropriate terminal equipment.
These operations are outside the scope of the present document.
ETSI
89
TS 100 977 V6.2.0 (1999-05)
When involved in GSM network operations the SIM interfaces with an ME with which messages are exchanged. A
message can be a command or a response.
-
A GSM command/response pair is a sequence consisting of a command and the associated response.
-
A GSM procedure consists of one or more GSM command/response pairs which are used to perform all or
part of an application-oriented task. A procedure shall be considered as a whole, that is to say that the
corresponding task is achieved if and only if the procedure is completed. The ME shall ensure that, when
operated according to the manufacturer's manual, any unspecified interruption of the sequence of
command/response pairs which realize the procedure, leads to the abortion of the procedure itself.
-
A GSM session of the SIM in the GSM application is the interval of time starting at the completion of the
SIM initialization procedure and ending either with the start of the GSM session termination procedure, or at
the first instant the link between the SIM and the ME is interrupted.
During the GSM network operation phase, the ME plays the role of the master and the SIM plays the role of the slave.
Some procedures at the SIM/ME interface require MMI interactions. The descriptions hereafter do not intend to infer
any specific implementation of the corresponding MMI. When MMI interaction is required, it is marked "MMI" in the
list given below.
Some procedures are not clearly user dependent. They are directly caused by the interaction of the MS and the network.
Such procedures are marked "NET" in the list given below.
Some procedures are automatically initiated by the ME. They are marked "ME" in the list given below.
The list of procedures at the SIM/ME interface in GSM network operation is as follows:
General Procedures:
-
Reading an EF
Updating an EF
Increasing an EF
ME
ME
ME
SIM management procedures:
-
SIM initialization
GSM session termination
Emergency call codes request
Extended language preference request
Language preference request
Administrative information request
SIM service table request
SIM phase request
ME
ME
ME
ME
ME
ME
ME
ME
CHV related procedures:
-
CHV verification
CHV value substitution
CHV disabling
CHV enabling
CHV unblocking
MMI
MMI
MMI
MMI
MMI
GSM security related procedures:
-
GSM algorithms computation
IMSI request
Access control information request
HPLMN search period request
Cipher key
BCCH information
Forbidden PLMN information
NET
NET
NET
NET
NET
NET
NET
NET
ETSI
90
TS 100 977 V6.2.0 (1999-05)
Subscription related procedures:
-
Dialling Numbers (ADN, FDN, MSISDN, LND, SDN, BDN)
Short messages (SMS)
Capability Configuration Parameters (CCP)
PLMN Selector
Cell Broadcast Message Identifier (CBMI)
Group Identifier Level 1 (GID1)
Group Identifier Level 2 (GID2)
Service Provider Name (SPN)
Voice Group Call Service (VGCS)
Voice Broadcast Service (VBS)
Enhanced Multi Level Pre-emption and Priority (eMLPP)
Depersonalisation Control Keys
Short message status reports (SMSR)
Network's indication of alerting
MMI/ME
MMI
MMI
MMI
MMI
MMI
MMI/ME
MMI/ME
ME
MMI/ME
MMI/ME
MMI/ME
ME
MMI
ME
SIM Application Toolkit related procedures:
-
Data Download via SMS-CB (CBMID)
Data Download via SMS-PP
Menu selection
Call Control
Proactive SIM
Mobile Originated Short Message control by SIM
NET
NET
MMI
MMI/ME/NET
MMI/ME/NET
MMI/ME/NET
The procedures listed in subclause 11.2 are basically required for execution of the procedures in subclauses 11.3, 11.4
and 11.5. The procedures listed in subclauses 11.3 and 11.4 are mandatory (see GSM 02.17 [6]). The procedures listed
in 11.5 are only executable if the associated services, which are optional, are provided in the SIM. However, if the
procedures are implemented, it shall be in accordance with subclause 11.5.
If a procedure is related to a specific service indicated in the SIM Service Table, it shall only be executed if the
corresponding bits denote this service as "allocated and activated" (see subclause 10.3.7). In all other cases this
procedure shall not start.
11.1
General procedures
11.1.1
Reading an EF
The ME selects the EF and sends a READ command. This contains the location of the data to be read. If the access
condition for READ is fulfilled, the SIM sends the requested data contained in the EF to the ME. If the access condition
is not fulfilled, no data will be sent and an error code will be returned.
11.1.2
Updating an EF
The ME selects the EF and sends an UPDATE command. This contains the location of the data to be updated and the
new data to be stored. If the access condition for UPDATE is fulfilled, the SIM updates the selected EF by replacing the
existing data in the EF with that contained in the command. If the access condition is not fulfilled, the data existing in
the EF will be unchanged, the new data will not be stored, and an error code will be returned.
11.1.3
Increasing an EF
The ME selects the EF and sends an INCREASE command. This contains the value which has to be added to the
contents of the last updated/increased record. If the access condition for INCREASE is fulfilled, the SIM increases the
existing value of the EF by the data contained in the command, and stores the result. If the access condition is not
fulfilled, the data existing in the EF will be unchanged and an error code will be returned.
ETSI
NOTE:
11.2
91
TS 100 977 V6.2.0 (1999-05)
The identification of the data within an EF to be acted upon by the above procedures is specified within
the command. For the procedures in subclauses 11.1.1 and 11.1.2 this data may have been previously
identified using a SEEK command, e.g. searching for an alphanumeric pattern.
SIM management procedures
Phase 2 MEs shall support all SIMs which comply with the mandatory requirements of Phase 1, even if these SIMs do
not comply with all the mandatory requirements of Phase 2. Furthermore, Phase 2 MEs shall take care of potential
incompatibilities with Phase 1 SIMs which could arise through use of inappropriate commands or misinterpretation of
response data. Particular note should be taken of making a false interpretation of RFU bytes in a Phase 1 SIM having
contradictory meaning in Phase 2; e.g. indication of EF invalidation state.
11.2.1
SIM initialization
After SIM activation (see subclause 4.3.2), the ME selects the Dedicated File DFGSM and optionally attempts to select
EFECC. If EFECC is available, the ME requests the emergency call codes.
The ME requests the Extended Language Preference. The ME only requests the Language Preference (EFLP) if at least
one of the following conditions holds:
-
EFELP is not available;
EFELP does not contain an entry corresponding to a language specified in ISO 639[30];
the ME does not support any of the languages in EFELP.
If both EFs are not available or none of the languages in the EFs is supported then the ME selects a default language. It
then runs the CHV1 verification procedure.
If the CHV1 verification procedure is performed successfully, the ME then runs the SIM Phase request procedure.
For a SIM requiring PROFILE DOWNLOAD, then the ME shall perform the PROFILE DOWNLOAD procedure in
accordance with GSM 11.14 [27]. When BDN is enabled on a SIM, the PROFILE DOWNLOAD procedure is used to
indicate to the SIM whether the ME supports the "Call Control by SIM" facility. If so, then the SIM is able to allow the
REHABILITATE command to rehabilitate EFIMSI and EFLOCI.
If the ME detects a SIM of Phase 1, it shall omit the following procedures relating to FDN and continue with the
Administrative Information request. The ME may omit procedures not defined in Phase 1 such as HPLMN Search
Period request.
For a SIM of Phase 2 or greater, GSM operation shall only start if one of the two following conditions is fulfilled:
-
if EFIMSI and EFLOCI are not invalidated, the GSM operation shall start immediately;
-
if EFIMSI and EFLOCI are invalidated, the ME rehabilitates these two EFs.
MEs without FDN capability but with Call control by SIM facility shall not rehabilitate EFIMSI and/or EFLOCI if
FDN is enabled in the SIM and therefore have no access to these EFs. GSM operation will therefore be
prohibited;
MEs without FDN capability and without Call control by SIM facility shall not rehabilitate EFIMSI and/or EFLOCI
and therefore have no access to these EFs. GSM operation will therefore be prohibited.
It is these mechanisms which are used for control of services n°3 and n°31 by the use of SIMs for these services
which always invalidate these two EFs at least before the next command following selection of either EF.
NOTE:
When FDN and BDN are both enabled, and if the ME supports FDN but does not support the Call control
by SIM facility, the rehabilitation of EFIMSI and EFLOCI will not be successful because of a restriction
mechanism of the REHABILITATE command linked to the BDN feature.
When EFIMSI and EFLOCI are successfully rehabilitated, if the FDN capability procedure indicates that:
i) FDN is allocated and activated in the SIM; and FDN is set "enabled", i.e. ADN "invalidated" or not activated;
and the ME supports FDN;
ETSI
92
TS 100 977 V6.2.0 (1999-05)
or ii) FDN is allocated and activated in the SIM; and FDN is set "disabled", i.e. ADN "not invalidated";
or iii) FDN is not allocated or not activated;
then GSM operation shall start.
In all other cases GSM operation shall not start.
Afterwards, the ME runs the following procedures:
-
Administrative Information request;
SIM Service Table request;
IMSI request;
Access Control request;
HPLMN Search Period request;
PLMN selector request;
Location Information request;
Cipher Key request;
BCCH information request;
Forbidden PLMN request;
CBMID request;
Depersonalisation Control Keys request;
Network's indication of alerting request.
If the SIM service table indicates that the proactive SIM service is active, then from this point onwards, the ME, if it
supports the proactive SIM service, shall send STATUS commands at least every 30s during idle mode as well as during
calls, in order to enable the proactive SIM to respond with a command. The SIM may send proactive commands (see
GSM 11.14 [27]), including a command to change the interval between STATUS commands from the ME, when in idle
mode. In-call requirements for STATUS for SIM Presence Detection are unchanged by this command.
After the SIM initialization has been completed successfully, the MS is ready for a GSM session.
11.2.2
GSM session termination
NOTE 1: This procedure is not to be confused with the deactivation procedure in subclause 4.3.2.
The GSM session is terminated by the ME as follows:
The ME runs all the procedures which are necessary to transfer the following subscriber related information to the SIM:
- Location Information update;
- Cipher Key update;
- BCCH information update;
- Advice of Charge increase;
- Forbidden PLMN update.
As soon as the SIM indicates that these procedures are completed, the ME/SIM link may be deactivated.
Finally, the ME deletes all these subscriber related information elements from its memory.
NOTE 2: If the ME has already updated any of the subscriber related information during the GSM Session, and the
value has not changed until GSM session termination, the ME may omit the respective update procedure.
11.2.3
Request:
Update:
NOTE:
Emergency Call Codes
The ME performs the reading procedure with EFECC.
The ME performs the updating procedure with EFECC.
The update procedure is only applicable when access conditions of ADM for update is set to ALW, CHV1
or CHV2.
ETSI
11.2.4
Request:
Update:
11.2.5
93
TS 100 977 V6.2.0 (1999-05)
Language preference
The ME performs the reading procedure with EFLP.
The ME performs the updating procedure with EFLP.
Administrative information request;
The ME performs the reading procedure with EFAD.
11.2.6
SIM service table request
The ME performs the reading procedure with EFSST.
11.2.7
SIM phase request
The ME performs the reading procedure with EFPHASE.
11.2.8
SIM Presence Detection and Proactive Polling
As an additional mechanism, to ensure that the SIM has not been removed during a card session, the ME sends, at
frequent intervals, a STATUS command during each call. A STATUS command shall be issued within all 30 second
periods of inactivity on the SIM-ME interface during a call. Inactivity in this case is defined as starting at the end of the
last communication or the last issued STATUS command. If no response data is received to this STATUS command,
then the call shall be terminated as soon as possible but at least within 5 seconds after the STATUS command has been
sent. If the DF indicated in response to a STATUS command is not the same as that which was indicated in the previous
response, or accessed by the previous command, then the call shall be terminated as soon as possible but at least within
5 seconds after the response data has been received. This procedure shall be used in addition to a mechanical or other
device used to detect the removal of a SIM.
If the ME supports the proactive SIM service, and the SIM has this service activated in its Service Table, then during
idle mode the ME shall send STATUS commands to the SIM at intervals no longer than the interval negotiated with the
SIM (see GSM 11.14 [27]).
11.2.9
Request:
Update:
11.3
Extended Language preference
The ME performs the reading procedure with EFELP.
The ME performs the updating procedure with EFELP.
CHV related procedures
A successful completion of one of the following procedures grants the access right of the corresponding CHV for the
GSM session. This right is valid for all files within the GSM application protected by this CHV.
After a third consecutive presentation of a wrong CHV to the SIM, not necessarily in the same GSM session, the CHV
status becomes "blocked" and if the CHV is "enabled", the access right previously granted by this CHV is lost
immediately.
An access right is not granted if any of the following procedures are unsuccessfully completed or aborted.
11.3.1
CHV verification
The ME checks the CHV status.
In the case of CHV1 the following procedure applies:
If the CHV1 status is "blocked" and CHV1 is "enabled", the procedure ends and is finished unsuccessfully.
ETSI
94
TS 100 977 V6.2.0 (1999-05)
If the CHV1 status is "blocked" but CHV1 is "disabled", the procedure ends and is finished successfully. The
ME shall, however, accept SIMs which do not grant access rights when CHV1 is "blocked" and "disabled". In
that case ME shall consider those SIMs as "blocked".
If the CHV1 status is not "blocked" and CHV1 is "disabled", the procedure is finished successfully.
If the CHV1 status is not "blocked" and CHV1 is "enabled", the ME uses the VERIFY CHV function. If the
CHV1 presented by the ME is equal to the corresponding CHV1 stored in the SIM, the procedure is finished
successfully. If the CHV1 presented by the ME is not equal to the corresponding CHV1 stored in the SIM, the
procedure ends and is finished unsuccessfully.
In the case of CHV2 the following procedure applies:
If the CHV2 status is "blocked", the procedure ends and is finished unsuccessfully.
If the CHV2 status is not "blocked", the ME uses the VERIFY CHV function. If the CHV2 presented by the ME
is equal to the corresponding CHV2 stored in the SIM, the procedure is finished successfully. If the CHV2
presented by the ME is not equal to the corresponding CHV2 stored in the SIM, the procedure ends and is
finished unsuccessfully.
11.3.2
CHV value substitution
The ME checks the CHV status. If the CHV status is "blocked" or "disabled", the procedure ends and is finished
unsuccessfully.
If the CHV status is not "blocked" and the enabled/disabled indicator is set "enabled", the ME uses the CHANGE CHV
function. If the old CHV presented by the ME is equal to the corresponding CHV stored in the SIM, the new CHV
presented by the ME is stored in the SIM and the procedure is finished successfully.
If the old CHV and the CHV in memory are not identical, the procedure ends and is finished unsuccessfully.
11.3.3
CHV disabling
Requirement: Service n°1 "allocated and activated".
The ME checks the CHV1 status. If the CHV1 status is "blocked", the procedure ends and is finished unsuccessfully.
If the CHV1 status is not "blocked", the ME reads the CHV1 enabled/disabled indicator. If this is set "disabled", the
If the CHV1 status is not "blocked" and the enabled/disabled indicator is set "enabled", the ME uses the DISABLE
CHV function. If the CHV1 presented by the ME is equal to the CHV1 stored in the SIM, the status of CHV1 is set
"disabled" and the procedure is finished successfully. If the CHV1 presented by the ME is not equal to the CHV1 stored
in the SIM, the procedure ends and is finished unsuccessfully.
11.3.4
CHV enabling
The ME checks the CHV1 status. If the CHV1 status is "blocked", the procedure ends and is finished unsuccessfully.
If the CHV1 status is not "blocked", the ME reads the CHV1 enabled/disabled indicator. If this is set "enabled", the
If the CHV1 status is not "blocked" and the enabled/disabled indicator is set "disabled", the ME uses the ENABLE
CHV function. If the CHV1 presented by the ME is equal to the CHV1 stored in the SIM, the status of CHV1 is set
"enabled" and the procedure is finished successfully. If the CHV presented by the ME is not equal to the CHV1 stored
in the SIM, the procedure ends and is finished unsuccessfully.
11.3.5
CHV unblocking
The execution of the CHV unblocking procedure is independent of the corresponding CHV status, i.e. being blocked or
not.
ETSI
95
TS 100 977 V6.2.0 (1999-05)
The ME checks the UNBLOCK CHV status. If the UNBLOCK CHV status is "blocked", the procedure ends and is
finished unsuccessfully.
If the UNBLOCK CHV status is not "blocked", the ME uses the UNBLOCK CHV function. If the UNBLOCK CHV
presented by the ME is equal to the corresponding UNBLOCK CHV stored in the SIM, the relevant CHV status
becomes "unblocked" and the procedure is finished successfully. If the UNBLOCK CHV presented by the ME is not
equal to the corresponding UNBLOCK CHV stored in the SIM, the procedure ends and is finished unsuccessfully.
11.4
GSM security related procedures
11.4.1
GSM algorithms computation
The ME selects DFGSM and uses the RUN GSM ALGORITHM function (see 8.16). The response SRES-Kc is sent to
the ME when requested by a subsequent GET RESPONSE command.
11.4.2
IMSI request
The ME performs the reading procedure with EFIMSI.
11.4.3
Access control request
The ME performs the reading procedure with EFACC.
11.4.4
HPLMN search period request
The ME performs the reading procedure with EFHPLMN.
11.4.5
Request:
Update:
11.4.6
Request:
Update:
11.4.7
Request:
Update:
11.4.8
Request:
Update:
Location information
The ME performs the reading procedure with EFLOCI.
The ME performs the updating procedure with EFLOCI.
Cipher key
The ME performs the reading procedure with EFKc.
The ME performs the updating procedure with EFKc.
BCCH information
The ME performs the reading procedure with EFBCCH.
The ME performs the updating procedure with EFBCCH.
Forbidden PLMN
The ME performs the reading procedure with EFPLMN.
The ME performs the updating procedure with EFPLMN.
11.5
Subscription related procedures
11.5.1
Dialling numbers
The following procedures may not only be applied to EFADN and its associated extension files EFCCP and EFEXT1 as
described in the procedures below, but also to EFFDN, EFMSISDN, EFLND, EFBDN and EFSDN and their associated
extension files. If these files are not allocated and activated, as denoted in the SIM service table, the current procedure
shall be aborted and the appropriate EFs shall remain unchanged.
ETSI
96
TS 100 977 V6.2.0 (1999-05)
As an example, the following procedures are described as applied to ADN.
Requirement:
Service n°2 "allocated and activated"
(Service n°3 for FDN,
Service n°9 for MSISDN,
Service n°13 for LND,
Service n°18 for SDN),
Service n°31 for BDN)
Update:
The ME analyses and assembles the information to be stored as follows (the byte identifiers used
below correspond to those in the description of the EFs in subclauses 10.4.1, 10.4.4 and 10.4.10):
i) The ME identifies the Alpha-tagging, Capability/Configuration Identifier and Extension1 Record Identifier.
ii) The dialling number/SSC string shall be analysed and allocated to the bytes of the EF as follows:
-
if a "+" is found, the TON identifier is set to "International";
-
if 20 or less "digits" remain, they shall form the dialling number/SSC string;
-
if more than 20 "digits" remain, the procedure shall be as follows:
Requirement:
(Service n°10 applies also for MSISDN and LND;
Service n°11 for FDN;
Service n°19 for SDN;
Service n°32 for BDN.)
The ME seeks for a free record in EFEXT1. If an Extension1 record is not marked as "free", the ME runs the
Purge procedure. If an Extension1 record is still unavailable, the procedure is aborted.
The first 20 "digits" are stored in the dialling number/SSC string. The value of the length of BCD
number/SSC contents is set to the maximum value, which is 11. The Extension1 record identifier is coded
with the associated record number in the EFEXT1. The remaining digits are stored in the selected Extension1
record where the type of the record is set to "additional data". The first byte of the Extension1 record is set
with the number of bytes of the remaining additional data. The number of bytes containing digit information
is the sum of the length of BCD number/SSC contents of EFADN and byte 2 of all associated chained
Extension1 records containing additional data (see subclauses 10.4.1 and 10.4.10).
iii) If a called party subaddress is associated to the ADN/SSC the procedure shall proceed as follows:
Requirement:
(Service n°10 applies also for MSISDN and LND;
Service n°11 for FDN;
Service n°19 for SDN;
Service n°32 for BDN.)
If the length of the called party subaddress is less than or equal to 11 bytes (see GSM 04.08 [15] for coding):
The ME seeks for a free record in EFEXT1. If an Extension1 record is not marked as "free", the ME runs the
Purge procedure. If an Extension1 record is still unavailable, the procedure is aborted.
The ME stores the called party subaddress in the Extension1 record, and sets the Extension1 record type to
"called party subaddress".
If the length of the called party subaddress is greater than 11 bytes (see GSM 04.08 [15] for coding):
The ME seeks for two free records in EFEXT1. If no such two records are found, the ME runs the Purge
procedure. If two Extension1 records are still unavailable, the procedure is aborted.
The ME stores the called party subaddress in the two Extension1 records. The identifier field in the
Extension1 record containing the first part of the subaddress data is coded with the associated EFEXT1 record
ETSI
97
TS 100 977 V6.2.0 (1999-05)
number containing the second part of the subaddress data. Both Extension1 record types are set to "called
party subaddress".
Once i), ii), and iii) have been considered the ME performs the updating procedure with EFADN. If the SIM has no
available empty space to store the received ADN/SSC, or if the procedure has been aborted, the ME advises the user.
NOTE 1: For reasons of memory efficiency the ME is allowed to analyse all Extension1 records to recognize if the
additional or subaddress data to be stored is already existing in EFEXT1. In this case the ME may use the
existing chain or the last part of the existing chain from more than one ADN (LND, MSISDN). The ME is
only allowed to store extension data in unused records. If existing records are used for multiple access, the
ME shall not change any data in those records to prevent corruption of existing chains.
Erasure:
The ME sends the identification of the information to be erased. The content of the identified
record in EFADN is marked as "free".
Request:
The ME sends the identification of the information to be read. The ME shall analyse the data of
EFADN (subclause 10.4.1) to ascertain, whether additional data is associated in EFEXT1 or EFCCP.
If necessary, then the ME performs the reading procedure on these EFs to assemble the complete
ADN/SSC.
Purge:
The ME shall access each EF which references EFEXT1 (EFEXT2) for storage and shall identify
records in these files using extension data (additional data or called party subaddress). Note that
existing chains have to be followed to the end. All referred Extension1 (Extension2) records are
noted by the ME. All Extension1 (Extension2) records not noted are then marked by the ME as
"free" by setting the whole record to 'FF'.
NOTE 2: Dependent upon the implementation of the ME, and in particular the possibility of erasure of ADN/SSC
records by Phase 1 MEs, which have no knowledge of the EFEXT1, it is possible for Extension1 records to
be marked as "used space" (not equal to 'FF'), although in fact they are no longer associated with an
ADN/SSC record.
The following three procedures are only applicable to service n°3 (FDN).
FDN capability request. The ME has to check the state of service n°3, i.e. if FDN is "enabled" or "disabled". In case of
enabled FDN, the ME has to switch to a restrictive terminal mode (see GSM 02.07). To ascertain the state of FDN, the
ME checks in EFSST whether or not ADN is activated. If ADN is not activated, service n°3 is enabled. If ADN is
activated, the ME checks the response data of EFADN. If EFADN is invalidated, service n°3 is enabled. In all other cases
service n°3 is disabled.
FDN disabling. The FDN disabling procedure requires that CHV2 verification procedure has been performed
successfully and that ADN is activated. If not, FDN disabling procedure will not be executed successfully. To disable
FDN capability, the ME rehabilitates EFADN. The invalidate/rehabilitate flag of EFADN, which is implicitly set by the
REHABILITATE command, is at the same time the indicator for the state of the service n°3. If ADN is not activated,
disabling of FDN is not possible and thus service n°3 is always enabled (see FDN capability request).
NOTE 3: If FDN is disabled (by rehabilitating EFADN) using an administrative terminal then the FDN disabling
procedure of this administrative terminal need also to rehabilitate EFIMSI and EFLOCI to ensure normal
operation of the SIM in a phase 1 ME or a phase 2 ME which does not support FDN.
FDN enabling. The FDN enabling procedure requires that CHV2 verification procedure has been performed
successfully. If not, FDN enabling procedure will not be executed successfully. To enable FDN capability, the ME
invalidates EFADN. The invalidate/rehabilitate flag of EFADN, which is implicitly cleared by the INVALIDATE
command, is at the same time the indicator for the state of the service n°3 (see FDN capability request). If ADN is not
activated, service n°3 is always enabled.
Invalidated ADNs may optionally still be readable and updatable depending on the file status (see clause 9.3)
The following three procedures are only applicable to service n°31 (BDN).
BDN capability request. The ME has to check the state of service n°31, i.e. if BDN is "enabled" or "disabled". BDN
service is "enabled" only if service n°31 is allocated and activated, and EFBDN is not invalidated. In all other cases, the
BDN service is "disabled".
ETSI
98
TS 100 977 V6.2.0 (1999-05)
BDN disabling. The BDN disabling procedure requires that CHV2 verification procedure has been performed
successfully. If not, BDN disabling procedure will not be executed successfully. To disable BDN capability, the ME
invalidates EFBDN. The invalidate/rehabilitate flag of EFBDN, which is implicitly cleared by the INVALIDATE
command, is at the same time the indicator for the state of the service n°31 (see BDN capability request).
BDN enabling. The BDN enabling procedure requires that CHV2 verification procedure has been performed
successfully. If not, BDN enabling procedure will not be executed successfully. To enable BDN capability, the ME
rehabilitates EFBDN. The invalidate/rehabilitate flag of EFBDN, which is implicitly set by the REHABILITATE
command, is at the same time the indicator for the state of the service n°31 (see BDN capability request).
Invalidated BDNs (when BDN capability is disabled) may optionally still be readable and updatable depending on the
file status (see clause 9.3).
11.5.2
Short messages
Requirement:
Service n°4 "allocated and activated".
Request:
The SIM seeks for the identified short message. If this message is found, the ME performs the
reading procedure with EFSMS.
If service n°35 is "allocated and activated" and the status of the SMS is '1D' (status report
requested, received and stored in EFSMSR), the ME performs the reading procedure with the
corresponding record in EFSMSR. If the ME does not find a corresponding record in EFSMSR, then
the ME shall update the status of the SMS with '19' (status report requested, received but not stored
in EFSMSR).
If the short message is not found within the SIM memory, the SIM indicates that to the ME.
Update:
The ME looks for the next available area to store the short message. If such an area is available, it
performs the updating procedure with EFSMS.
If there is no available empty space in the SIM to store the received short message, a specific MMI
will have to take place in order not to loose the message.
Erasure:
The ME will select in the SIM the message area to be erased. Depending on the MMI, the message
may be read before the area is marked as "free". After performing the updating procedure with
EFSMS, the memory allocated to this short message in the SIM is made available for a new
incoming message. The memory of the SIM may still contain the old message until a new message
is stored in this area.
If service n°35 is "allocated and activated" and the status of the SMS is '1D' (status report
requested, received and stored in EFSMSR), the ME performs the erasure procedure for EFSMSR with
the corresponding record in EFSMSR.
11.5.3
Requirement:
Accumulated Call Meter.
Request:
The ME performs the reading procedure with EFACM. The SIM returns the last updated value of
the ACM.
Initialization:
The ME performs the updating procedure with EFACM using the new initial value.
Increasing:
The ME performs the increasing procedure with EFACM sending the value which has to be added.
Accumulated Call Meter Maximum Value.
Request:
The ME performs the reading procedure with EFACMmax.
Initialization:
The ME performs the updating procedure with EFACMmax using the new initial maximum value.
Price per Unit and Currency Table (PUCT).
Request:
The ME performs the reading procedure with EFPUCT.
Update:
The ME performs the updating procedure with EFPUCT.
ETSI
11.5.4
Requirement:
Request:
Update:
Erasure:
11.5.5
Requirement:
Request:
Update:
11.5.6
Requirement:
Request:
Update:
11.5.7
Requirement:
Request:
11.5.8
Requirement:
Request:
11.5.9
Requirement:
Request:
99
Capability configuration parameters
The ME performs the reading procedure with EFCCP.
The ME performs the updating procedure with EFCCP.
The ME sends the identification of the requested information to be erased. The content of the
identified record in EFCCP is marked as "free".
PLMN selector
The ME performs the reading procedure with EFPLMNsel.
The ME performs the updating procedure with EFPLMNsel.
Cell broadcast message identifier
The ME performs the reading procedure with EFCBMI.
The ME performs the updating procedure with EFCBMI.
Group identifier level 1
The ME performs the reading procedure with EFGID1.
The ME performs the reading procedure with EFGID2.
The ME performs the reading procedure with EFSPN.
11.5.10 Voice Group Call Services
Requirement:
Voice Group Call Service
Request:
The ME performs the reading procedure with EFVGCS.
Voice Group Call Service Status
Request:
The ME performs the reading procedure with EFVGCSS.
Update:
The ME performs the updating procedure with EFVGCSS.
11.5.11 Voice Broadcast Services
Requirement:
TS 100 977 V6.2.0 (1999-05)
Voice Broadcast Service
Request:
The ME performs the reading procedure with EFVBS.
Voice Broadcast Service Status
Request:
The ME performs the reading procedure with EFVBSS.
Update:
The ME performs the updating procedure with EFVBSS.
ETSI
100
TS 100 977 V6.2.0 (1999-05)
11.5.12 Enhanced Multi Level Pre-emption and Priority Service
Requirement:
Enhanced Multi Level Pre-emption and Priority
Request:
The ME performs the reading procedure with EFeMLPP.
Automatic Answer on eMLPP service
Request:
The ME performs the reading procedure with EFAAeM.
Update:
The ME performs the updating procedure with EFAAeM.
11.5.13 Cell Broadcast Message range identifier
Requirement:
Request:
Update:
The ME performs the reading procedure with EFCBMIR.
The ME performs the updating procedure with EFCBMIR.
11.5.14 Depersonalisation Control Keys
Requirement:
Request:
The ME performs the reading procedure with EFDCK.
11.5.15 Short message status report
Requirement:
Request:
If the status of a stored short message indicates that there is a corresponding status report, the ME
performs the seek function with EFSMSR to identify the record containing the appropriate status
report. The ME performs the reading procedure with EFSMSR.
Update:
If a status report is received, the ME first seeks within the SMS record identifiers of EFSMSR for the
same record number it used for the short message in EFSMS. If such a record identifier is found in
EFSMSR, it is used for storage. If such a record identifier is not found, then the ME seeks for a free
entry in EFSMSR for storage. If no free entry is found the ME runs the Purge procedure with EFSMSR.
If there is still no free entry, the status report is not stored.
If the ME found an appropriate record in EFSMSR for storage, it updates the record with the status
report setting the record identifier in EFSMSR to the appropriate record number of the short message
in EFSMS.
The status in EFSMS is updated accordingly (see 10.4.3) by performing the update procedure with
EFSMS.
Erasure:
The ME runs the update procedure with EFSMSR by at least storing '00' in the first byte of the
record. The ME may optionally update the following bytes with 'FF'.
Purge:
The ME shall read the SMS record identifier (byte 1) of each record of EFSMSR. With each record
the ME checks the corresponding short messages in EFSMS. If the status (byte 1) of the
corresponding SMS is not equal '1D' (status report requested, received and stored in EFSMSR), the
ME shall perform the erasure procedure with the appropriate record in EFSMSR.
11.5.16 Network's indication of alerting
Requirement:
Request:
The ME performs the reading procedure with EFNIA.
ETSI
11.6
101
TS 100 977 V6.2.0 (1999-05)
SIM Application Toolkit related procedures
SIM Application Toolkit is an optional feature. The higher level procedures, and contents and coding of the commands,
are given in GSM 11.14 [27]. Procedures relating to the transmission of commands and responses across the SIM/ME
interface are given in this section. A SIM or ME supporting SIM Application Toolkit shall conform to the requirements
given in this section.
11.6.1
Initialization procedure
A SIM supporting SIM Application Toolkit shall indicate this through relevant data in EFPhase and EFSST, as defined in
the relevant sections above.
An ME supporting SIM Application Toolkit shall perform initialization as defined in the SIM Initialization section
above.
11.6.2
Proactive polling
An ME supporting proactive SIM (part of SIM Application Toolkit) shall support the polling procedure as defined
above.
11.6.3
Support of commands
A SIM or ME supporting SIM Application Toolkit shall support the commands TERMINAL PROFILE, ENVELOPE,
FETCH and TERMINAL RESPONSE.
These commands shall never be used if either the SIM or ME does not support SIM Application Toolkit. Therefore
standard SIMs and MEs do not need to support these commands.
11.6.4
Support of response codes
A SIM or ME supporting SIM Application Toolkit shall support the response status words (SW1 SW2) '91 XX', '93 00'
and '9E XX.
The SIM shall send '9E XX' only to an ME indicating in TERMINAL PROFILE that it supports the handling of these
status words.
These responses shall never be used if either the SIM or ME does not support SIM Application Toolkit. Therefore
standard SIMs and MEs do not need to support them.
11.6.5
Command-response pairs
Using the terminology where the ME issues a command and the SIM a response, ending in status words SW1 SW2, a
command-response pair is considered as a single transaction. Each transaction is initiated by the ME and terminated by
the SIM. One transaction must be completed before the next one can be initiated. This protocol applies to SIM
Application Toolkit in the same way as it does to normal operation.
11.6.6
Independence of normal GSM and SIM Application Toolkit tasks
Normal GSM operation (relating to general, CHV related, GSM security related, and subscription related procedures)
and SIM Application Toolkit operation shall be logically independent, both in the SIM and in the ME.
Specifically, this means:
-
The currently selected EF and current record pointer in the normal GSM task shall remain unchanged, if still
valid, as seen by the ME, irrespective of any SIM Application Toolkit activity.
-
Between successive SIM Application Toolkit related command-response pairs, other normal GSM related
command-response pairs can occur. The SIM Application Toolkit task status shall remain unchanged by these
command-response pairs.
ETSI
11.6.7
102
TS 100 977 V6.2.0 (1999-05)
Use of BUSY status response
If for any reason the SIM Application Toolkit task of the SIM cannot process an ENVELOPE command issued by the
ME at present (e.g. other SIM Application Toolkit processes are already running, and this additional one would cause an
overload), the SIM can respond with a status response of '93 00'. The ME may re-issue the command at a later stage.
The BUSY status response has no impact on normal GSM operation.
11.6.8
Use of NULL procedure byte
The NULL procedure byte provides a mechanism for the SIM to obtain more time before supplying the response part of
a command-response pair, during which time the ME is unable to send further commands to the SIM.
If a SIM Application Toolkit activity in the SIM runs for too long, this may prevent the ME from sending "normal
GSM" commands which are time-critical, e.g. RUN GSM ALGORITHM. A MORE TIME command is defined in
GSM 11.14 [27], which ensures that the SIM Application Toolkit task in the SIM gets more processing time, while at
the same time freeing the SIM/ME interface. This should be used in preference to NULL procedure bytes ('60').
11.6.9
Using the TERMINAL PROFILE, ENVELOPE, and TERMINAL
RESPONSE commands
These commands are part of the set used by SIM Application Toolkit. The use of the these commands, the occasions
where they are required, and the command and response parameters associated with the commands, are specified in
GSM 11.14 [27]. The ME completes the command parameters/data of the relevant command and sends the command to
the SIM. The transmitted data is processed by the SIM in a specific way depending on the tag value in the command
parameters.
A SIM or ME not supporting SIM Application Toolkit does not need to support these commands.
11.6.10 Using the FETCH command
This command is used by SIM Application Toolkit. The use of the this command, the occasions where it is required, and
the command and response parameters associated with the command, are specified in GSM 11.14 [27]. It is similar in
function to GET RESPONSE, in that it requests response parameters from the SIM, following a '91 XX' status response.
The transmitted response data from the SIM is processed by the ME in a specific way depending on the tag value in the
response parameters.
A SIM or ME not supporting SIM Application Toolkit does not need to support this command.
11.6.11 Data Download via SMS-CB
Requirement:
The ME shall perform the reading procedure with EFCBMID. On receiving a cell broadcast message with an identifier
which matches an identifier in EFCBMID, the ME shall pass the CB message to the SIM using the ENVELOPE command.
If a match is not found and service no. 14 is "allocated and activated", then the message identifier is checked against
those in EFCBMI.
11.6.12 Data Download via SMS-PP
Requirement:
The procedures and commands for Data Download via SMS-PP are defined in GSM 11.14 [27].
11.6.13 Menu selection
Requirement:
The procedures and commands for Menu Selection are defined in GSM 11.14 [27].
ETSI
103
TS 100 977 V6.2.0 (1999-05)
11.6.14 Call Control
Requirement:
The procedures and commands for Call Control are defined in GSM 11.14 [27]. It is mandatory for the ME to perform
the procedures if it has indicated that it supports Call Control in the TERMINAL PROFILE command. When BDN is
enabled, the Call control facility of the ME is used by the SIM to support the BDN service.
11.6.15 Proactive SIM
Requirement:
The procedures and commands for Proactive SIM, at the application level, are defined in GSM 11.14 [27].
11.6.16 Mobile Originated Short Message control by SIM
Requirement:
The procedures and commands for Mobile Originated Short Message control by SIM are defined in GSM 11.14 [27]. It
is mandatory for the ME to perform the procedures if it has indicated that it supports Mobile Originated Short Message
control by SIM in the TERMINAL PROFILE command.
11.6.17 SIM data download error
In case of an ENVELOPE for SIM data download, the SIM can respond with the status words '9E XX' to indicate that
response data is available. The ME shall use the GET RESPONSE command to get the response data. The ME shall
then send transparently to the network this response data, using the error procedure of the transport mechanism.
ETSI
104
TS 100 977 V6.2.0 (1999-05)
Plug-in SIM
This annex specifies the dimensions of the Plug-in SIM as well as the dimensions and location of the contacts of the
Plug-in SIM. For further details of the Plug-in SIM see clause 4.
Upper edge
(16,48)
15±0,1
12,07 m in
10,37 m ax
9,53 m in
7,83 m ax
5,29 m ax
6,99 m in
7,5
,1
_+0
R1
P1
P3
4,45 m in
_+0
,1
P2
0
R1
L e ft e d g e
3 ,3
2,75 m ax
2 0 ,8
1 _+
0,
1
R1
R
1
3 ±0 ,1
3 ±0,1
,
+_ 0
_+
0,
1
R1
4 max
6 m in
1 1 ,6 2 m a x
1 3 ,6 2 m in
(6 ,2 5 )
NOTE:
2 5 ±0 ,1
The Plug-in SIM may be "obtained" by cutting away excessive plastic of an ID-1 SIM. The values in
parenthesis in figure A.1 show the positional relationship between the Plug-in and the ID-1 SIM and are
for information only.
Figure A.1: Plug-in SIM
ETSI
105
TS 100 977 V6.2.0 (1999-05)
Annex B (normative):
Coding of Alpha fields in the SIM for UCS2
If 16 bit UCS2 characters as defined in ISO/IEC 10646 [31] are being used in an alpha field, the coding can take one of
three forms. If the ME supports UCS2 coding of alpha fields in the SIM, the ME shall support all three coding schemes
for character sets containing 128 characters or less; for character sets containing more than 128 characters, the ME shall
at least support the first coding scheme. If the alpha field record contains GSM default alphabet characters only, then
none of these schemes shall be used in that record. Within a record, only one coding scheme, either GSM default
alphabet, or one of the three described below, shall be used.
1) If the first octet in the alpha string is '80', then the remaining octets are 16 bit UCS2 characters, with the more
significant octet (MSO) of the UCS2 character coded in the lower numbered octet of the alpha field, and the less
significant octet (LSO) of the UCS2 character is coded in the higher numbered alpha field octet, i.e. octet 2 of the
alpha field contains the more significant octet (MSO) of the first UCS2 character, and octet 3 of the alpha field
contains the less significant octet (LSO) of the first UCS2 character (as shown below). Unused octets shall be set
to 'FF', and if the alpha field is an even number of octets in length, then the last (unusable) octet shall be set to
'FF'.
Example 1
Octet 1
'80'
2)
Octet 2
Ch1MSO
Octet 3
Ch1LSO
Octet 4
Ch2MSO
Octet 5
Ch2LSO
Octet 6
Ch3MSO
Octet 7
Ch3LSO
Octet 8
'FF'
Octet 9
'FF'
If the first octet of the alpha string is set to '81', then the second octet contains a value indicating the number of
characters in the string, and the third octet contains an 8 bit number which defines bits 15 to 8 of a 16 bit base
pointer, where bit 16 is set to zero, and bits 7 to 1 are also set to zero. These sixteen bits constitute a base pointer
to a "half-page" in the UCS2 code space, to be used with some or all of the remaining octets in the string. The
fourth and subsequent octets in the string contain codings as follows; if bit 8 of the octet is set to zero, the
remaining 7 bits of the octet contain a GSM Default Alphabet character, whereas if bit 8 of the octet is set to one,
then the remaining seven bits are an offset value added to the 16 bit base pointer defined earlier, and the resultant
16 bit value is a UCS2 code point, and completely defines a UCS2 character.
Example 2
Octet 1
'81'
Octet 2
'05'
Octet 3
'13'
Octet 4
'53'
Octet 5
'95'
Octet 6
'A6'
Octet 7
'XX'
Octet 8
'FF'
Octet 9
'FF'
In the above example;
-
Octet 2 indicates there 5 characters in the string
-
Octet 3 indicates bits 15 to 8 of the base pointer, and indicates a bit pattern of 0hhh hhhh h000 0000 as the 16
bit base pointer number. Bengali characters for example start at code position 0980 (0000 1001 1000 0000),
which is indicated by the coding '13' in octet 3 (shown by the italicised digits).
-
Octet 4 indicates GSM Default Alphabet character '53', i.e. "S".
-
Octet 5 indicates a UCS2 character offset to the base pointer of '15', expressed in binary as follows 001 0101,
which, when added to the base pointer value results in a sixteen bit value of 0000 1001 1001 0101, i.e. '0995',
which is the Bengali letter KA.
Octet 8 contains the value 'FF', but as the string length is 5, this a valid character in the string, where the bit
pattern 111 1111 is added to the base pointer, yielding a sixteen bit value of 0000 1001 1111 1111 for the
UCS2 character (i.e. '09FF').
ETSI
3)
106
TS 100 977 V6.2.0 (1999-05)
If the first octet of the alpha string is set to '82', then the second octet contains a value indicating the number of
characters in the string, and the third and fourth octets contain a 16 bit number which defines the complete 16 bit
base pointer to a "half-page" in the UCS2 code space, for use with some or all of the remaining octets in the
string. The fifth and subsequent octets in the string contain codings as follows; if bit 8 of the octet is set to zero,
the remaining 7 bits of the octet contain a GSM Default Alphabet character, whereas if bit 8 of the octet is set to
one, the remaining seven bits are an offset value added to the base pointer defined in octets three and four, and
the resultant 16 bit value is a UCS2 code point, and defines a UCS2 character.
Example 3
Octet 1
'82'
Octet 2
'05'
Octet 3
'05'
Octet 4
'30'
Octet 5
'2D'
Octet 6
'82'
Octet 7
'D3'
Octet 8
'2D'
Octet 9
'31'
In the above example
-
Octet 2 indicates there are 5 characters in the string
-
Octets 3 and 4 contain a sixteen bit base pointer number of '0530', pointing to the first character of the
Armenian character set.
-
Octet 5 contains a GSM Default Alphabet character of '2D', which is a dash "-".
-
Octet 6 contains a value '82', which indicates it is an offset of '02' added to the base pointer, resulting in a
UCS2 character code of '0532', which represents Armenian character Capital BEN.
-
Octet 7 contains a value 'D3', an offset of '53', which when added to the base pointer results in a UCS2 code
point of '0583', representing Armenian Character small PIWR.
ETSI
107
TS 100 977 V6.2.0 (1999-05)
FDN/BDN Procedures
ATR
S elect D F
G SM
G e t R espo n se
Verify C H V1
(if not disabled)
P hase 2+
S IM
P hase?
P hase 1
Perform Profile
D ow nload
(see note3)
Phase 2
M E : unrestricted
operation
S e le ct E F
LO C I
(see note1)
G e t R e sponse
(ev alu ation o f
invalida tion flag )
S e le ct E F
IM SI
(see note1)
G e t R e sponse
(ev alu ation o f
invalida tion flag )
not invalidated
(see note 2 )
S tatus EF
IM SI
and E FLOCI
invalidated
1
M E : unrestricted
operation
NOTE 1: In case of enabled FDN and/or enabled BDN, the EF has been invalidated by the SIM at no later than this
stage.
NOTE 2: Invalidation of only one of the two EFs is not allowed for FDN and BDN.
NOTE 3: For SIMs with enabled BDN this procedure is used to check whether the ME supports the Call Control by
the SIM facility.
Figure C.1: Example of an Initialization Procedure of a FDN/BDN SIM (see 11.2.1)
ETSI
108
TS 100 977 V6.2.0 (1999-05)
1
SIM capability
request
yes
ME
supports all
enabled services
(see note 6)
?
ME
supports
CC ?
no
no
no
ME
supports FDN
and FDN is
enabled
?
yes
yes
Rehabilitate
EF LOCI and EF IMSI
Rehabilitate
EF LOCI and EF IMSI
(note 4)
(note 4)
EFs
rehabilitated
?
no
(note 5)
no
(note 5)
yes
EFs
rehabilitated
?
yes
restricted or unrestricted
no operation
operation, according to
the state (enabled/disabled)
of the various services
(FD N , C C )
F D N operation
Note 4: In case of "BDN enabled", the SIM only allows rehabilitation of the EFIMSI and EFLOCI, if the ME has indicated
its CC-capability to the SIM (by PROFILE_DOWNLOAD).
Note 5: Possibility for future "restricting" services to use the internal SIM mechanism of invalidation of EFIMSI and
EFLOCI.
Note 6: If the ME does not support all enabled services (e.g. FDN, BDN), it does not operate. In case of enabled BDN,
the support of the "Call Control Feature" by the ME is sufficient for operation. For future use, there may be
additional "restricting" services, which are not known to the ME. In that case the ME will perform the
subsequent rehabilitation procedure but will fail to rehabilitate EFIMSI and EFLOCI (see note 4).
Figure C.1: Example of an Initialization Procedure of a FDN/BDN SIM (continued)
ETSI
109
TS 100 977 V6.2.0 (1999-05)
BDN capability
request
FDN capability
request
Figure C.2: SIM capability request
Select EF
SS T
Read EF SST
yes
BDN
allocated and
activated
?
no
Select DF TELECOM
Select EF
BDN
Get Response
(evaluation of
invalidation flag)
no
BDN enabled
EF BDN
invalidated
?
yes
BDN disabled
Figure C.3: BDN capability request (see 11.5.1)
ETSI
No BDN SIM
110
Select EF
Read EF
TS 100 977 V6.2.0 (1999-05)
SST
SST
FDN
yes
no
ADN
allocated
and
activated
?
no
allocated and
activated
?
yes
Select
DF
Telecom
Select
EFADN
Get Response
(evaluation of
invalidation flag)
(see note 7)
yes
EF
ADN
no
invalidated
?
FDN enabled
FDN disabled
NOTE 7: In this case FDN is enabled without the possibility of disabling.
Figure C.4: FDN capability request (see 11.5.1)
ETSI
No FDN SIM
111
TS 100 977 V6.2.0 (1999-05)
Rehabilitate
EFIMSI EFLOCI
Select EF
IMSI
Rehabilitate
EF IMSI
Select EF
(Note 8)
LOCI
Rehabilitate
EF
Rehabilitate
LOCI
(Note 8)
NOTE 8: If BDN is enabled in the SIM, and if the Profile download procedure has not indicated that the ME
supports Call Control, the EF is not rehabilitated by the SIM.
Figure C.5: Procedure to rehabilitate GSM files
FDN
allocated and
activated
?
no
Boolean Equation:
FD = FDA.(NOT(ADA+ADA.ADI)
yes
ADN
allocated
and
activated
?
where
FD = FDN enabled
FDA = FDN allocated and activated
ADA = ADN allocated and activated
ADI = EF ADN invalidated
yes
EF
ADN
EF
no
invalidated
?
no
yes
FDN enabled
FDN not enabled
FDN not enabled
Figure C.6: Coding for state of FDN
ETSI
112
TS 100 977 V6.2.0 (1999-05)
Annex D (informative):
Suggested contents of the EFs at pre-personalization
If EFs have an unassigned value, it may not be clear from the main text what this value should be. This annex suggests
values in these cases.
File Identification
Description
Value
'2F E2'
'2F 05'
ICC identification
Extended Language preference
operator dependant (see 10.1.1)
'FF…FF'
'6F 05'
'6F 07'
'6F 20'
'6F 30'
'6F 31'
'6F 37'
'6F 38'
'6F 39'
'6F 3E'
'6F 3F'
'6F 41'
'6F 45'
'6F 46'
'6F 48'
'6F 49'
'6F 74'
'6F 78'
'6F 7B'
'6F 7E
Language preference
IMSI
Ciphering key Kc
PLMN selector
HPLMN search period
ACM maximum value
SIM service table
Accumulated call meter
PUCT
CBMI
Service provider name
CBMID
Service Dialling Numbers
BCCH
Access control class
Forbidden PLMNs
Location information
'6F AD'
'6F AE'
'6F 3A'
'6F 3B'
'6F 3C'
'6F 3D'
'6F 40'
'6F 42'
'6F 43'
'6F 44'
'6F 47'
Administrative data
Phase identification
Abbreviated dialling numbers
Fixed dialling numbers
Short messages
MSISDN storage
SMS parameters
SMS status
Last number dialled
Short message status reports
'FF'
'FF...FF07'
'FF...FF'
'FF'
'000000' (see note 1)
'000000'
operator dependant
operator dependant
'FFFFFF0000'
'FF...FF'
'FF...FF'
'FF...FF'
'FF...FF'
'FF...FF'
'FF...FF'
'FFFFFFFF xxFxxx 0000 FF 01'
(see note 2)
see 10.3.16
'FF...FF'
'FF...FF'
'00FF...FF'
'FF...FF'
'FF...FF'
'FF...FF'
'FF...FF'
'FF...FF'
'00FF…FF'
'6F 4A'
'6F 4B'
'6F 4C'
'6F 4D'
'6F 4E'
'6F 51'
Extension 1
Extension 2
Extension 3
Barred dialling numbers
Extension 4
Network's indication of alerting
'FF...FF'
'FF...FF'
'FF...FF'
'FF...FF'
'FF...FF'
'FF...FF'
'6F 52
'6F 53
GPRS Ciphering key KcGPRS
GPRS Location Information
'FF...FF07'
'FFFFFFFF FFFFFF xxFxxx 0000 FF
01'
NOTE 1: The value '000000' means that ACMmax is not valid, i.e. there is no restriction on the ACM. When
assigning a value to ACMmax, care should be taken not to use values too close to the maximum possible
value 'FFFFFF', because the INCREASE command does not update EFACM if the units to be added would
exceed 'FFFFFF'. This could affect the call termination procedure of the Advice of Charge function.
NOTE 2: xxFxxx stands for any valid MCC and MNC, coded according to GSM 04.08 [15].
ETSI
113
TS 100 977 V6.2.0 (1999-05)
Annex E (informative):
SIM application Toolkit protocol diagrams.
The diagrams in this annex are intended to illustrate the data protocols of the SIM toolkit application in various
situations. The SIM application is shown as initiated by SMS Data Download messages. Other possibilities exist (as
defined in GSM 11.14) such as data entry from a menu selection.
Case 1: Simple
Network
GSM
SIM
ME
SIM
Application
S M S SIM
_Data_Download/Class_2
ENV(SMS)
(SMS)
(‘9000’)
‘9000’
SMS Ack
This shows the simple case where an SMS for SIM updating is received from the network, passed to the SIM by the ME
and processed immediately by the SIM application. This requires no ME action except to acknowledge the SMS.
ETSI
114
TS 100 977 V6.2.0 (1999-05)
Case 2: Simple with short delay
Network
SIM
Appl
GSM
SIM
ME
S M S SIM
ENV(SMS)
(SMS)
‘60’
(‘60’)
‘60’
(‘60’)
(‘9000’)
‘9000’
SMS Ack
This shows the simple case where an SMS for SIM updating is received from the network, passed to the SIM by the ME
and which requires some time to process by the SIM application. The processing time is "not long" and is obtained by
the SIM application sending "null procedure bytes" to the ME. Each byte has the effect of restarting the work waiting
time so that the ME does not abort the transaction before the SIM application has finished processing the command(s)
sent in the SMS.
Guidelines on timings:
1. The SMS Ack must be sent back before the network times out and sends the SMS again.
2. Use of null procedure bytes must not be excessive as during this time the ME is unable to issue normal GSM
commands to the SIM.
ETSI
115
TS 100 977 V6.2.0 (1999-05)
Case 3: Simple with short delay and SIM Acknowledgement
Network
SIM
Appl
GSM
SIM
ME
S M S SIM
ENV(SMS)
(SMS)
‘60’
(‘60’)
‘60’
(‘60’)
(‘9F10’)
‘9F10’
Get Response (16 bytes)
(SIM Ack)
SIM Ack
SMS Ack (with
SIM Ack)
This shows the same case as previously where an SMS for SIM updating is received from the network, passed to the
SIM by the ME and which requires some time to process by the SIM application. However in this case the SIM
application has SIM acknowledgement data to include in the SMS acknowledgement being returned to the network by
the ME.
Guideline on timings:
The SMS Ack must be sent back before the network times out and sends the SMS again.
ETSI
116
TS 100 977 V6.2.0 (1999-05)
Case 4: A Toolkit command generated by the SIM application as a result of an SMS from the network
Network
GSM
SIM
ME
SIM
Application
S M S SIM
ENV(SMS)
(SMS)
‘60’
(‘60’)
‘60’
(‘60’)
(‘91XX’)
‘91XX’
SMS Ack
FETCH
(FETCH)
(Command)
Command
TERMINAL RESPONSE
(TERMINAL RESPONSE)
(‘9000’)
‘9000’
This shows the case where an SMS for SIM updating is received from the network, passed to the SIM by the ME and
processed by the SIM application which then generates a command for action by the ME (e.g. PLAYTONE).
NOTE:
If a positive acknowledgement to the network of completion of execution of the instructions given in the
SMS message is required then the SIM application can issue a command to the ME to send a MO SMS.
ETSI
117
TS 100 977 V6.2.0 (1999-05)
Case 5: A normal GSM command requires processing before the ME can respond to the 91XX from the SIM
Network
GSM
SIM
ME
SIM
Application
S M S SIM
ENV(SMS)
(SMS)
(‘91XX’)
‘91XX’
SMS Ack
GSM Command
‘91XX’
FETCH
(FETCH)
(Command)
Command
TERMINAL RESPONSE
(TERMINAL RESPONSE)
(‘9000’)
‘9000’
processed by the SIM application which then generates a command for action by the ME (e.g. PLAYTONE). However a
normal GSM command requires processing before the ME can FETCH the command which the SIM is waiting to give
it. The response to the normal GSM command is '91XX' in this case to remind the ME of the outstanding SIM
application command request.
ETSI
118
TS 100 977 V6.2.0 (1999-05)
Case 6: MORE TIME Command
Network
GSM
SIM
ME
SIM
Application
S M S SIM
ENV(SMS)
(SMS)
(‘91XX’)
SMS Ack
‘91XX’
FETCH
(FETCH)
MORETIME
(MORETIME)
TERMINAL RESPONSE
(TERMINAL RESPONSE)
(‘9000’)
‘9000’
requires a considerable period of time to be processed by the SIM application. In this case the use of null procedure
bytes only is inappropriate as the ME must be given the opportunity to process normal GSM commands. The
opportunities gained by the SIM application for processing, and the opportunities for normal GSM commands are shown
in the diagram above. The sequence of 91XX, FETCH and MORETIME commands can be repeated if required.
Opportunities to process normal GSM commands are shown thus:
Opportunities for SIM application processing are shown thus:
ETSI
119
TS 100 977 V6.2.0 (1999-05)
Case 7: SIM Application Busy
Network
GSM
SIM
ME
SIM
Application
BUSY
S M S SIM
ENV(SMS’)
‘9300’
SMS NACK
While the SIM application is busy processing a SMS for the SIM application arrives from the network and is sent to the
SIM by the ME in the usual manner. The SIM operating system recognizes that the SIM application is busy, and it sends
a busy response ('9300') to the ME. The ME then sends negative acknowledgement to the network. The responsibility
for a retry rests with the network.
ETSI
120
TS 100 977 V6.2.0 (1999-05)
Annex F (informative):
Bibliography
1)
EN 726-3 (1994): "Terminal Equipment (TE); Requirements for IC cards and terminals for
telecommunication use Part 3: Application independent card requirements".
2)
EN 726-4 (1994): "Terminal Equipment (TE); Requirements for IC cards and terminals for
telecommunication use Part 4: Application independent card related terminal requirements".
3)
ISO/IEC 7816-3/A2 (1994): "Identification cards - Integrated circuit(s) cards with contacts, Part 3:
Electronic signals and transmission protocols": "Protocol type select".
ETSI
121
TS 100 977 V6.2.0 (1999-05)
Annex G (informative):
Change history
This annex lists all change requests approved for the present document since the first phase2+ version was approved by
ETSI SMG.
SMG#
SMG
tdoc
SMG9
tdoc
VERS
CR
RV
PH
CAT
SUBJECT
Resulting
Version
S16
709/95
154/95
4.15.0 A008
r96
1
SIM Speed Enhancement
5.0.0
S17
062/96
060/96
060/96
059/96
061/96
147/95
06/96
06/96
204/95r
05/96
5.0.0
A006
A009
A010
A013
A014
r96
r96
r96
r96
r96
B
B
B
C
D
Service Dialling Numbers
ASCI for VGCS and VBS
ASCI for eMLPP
Interaction between FDNs and ADNs
Correction of baud rate for SIM Speed enhancement
5.1.0
S18
263/96
260/96
261/96
262/96
57/96
45/96
54/96
55/96
5.1.0
A011
A016
A018
A020
r96
r96
r96
r96
B
A
A
A
SIM Application Toolkit protocol enhancements
SIM presence detection clarification
Reponse codes and coding of SIM service table
Reference to International Standards
5.2.0
S19
374/96
373/96
409/96
374/96
102/96
105/96
107/96
108/96
5.2.0
A012
A023
A024
A025
r96
r96
r96
r96
C
A
B
C
Contacting elements
Clarification of clock stop timing
Emergency Call Codes (ECC)
Using ranges of CBMIs
5.3.0
S20
580/96
734/96
734/96
702/96
206/96
197/96
197/96
207/96
5.3.0
A021
A026
A027
A031
r96
r96
r96
r96
B
B
B
D
Barred Dialling Numbers
Addition of Cooperative Network List EF
Addition of ME Depersonalisation feature and EF
RFU bit taken into use in GSM 11.12
5.4.0
s21
101/97
101/97
101/97
101/97
101/97
101/97
97/079
97/086
97/056
97/058
97/059
97/089
5.4.0
A032
A033
A034
A036
A037
A041
r96
r96
r96
r96
r96
r96
D
B
C
D
B
B
Ammendment to BDN diagrams in Annex B
5.5.0
DFs for MSS/ PCS1900/other use
Reading of EFDCK during SIM initialisation
Administrative Access Conditions
Format of EFCNL to include fields for Corporate Personal. Code
Administrative Data field
s22
356/97
356/97
356/97
356/97
356/97
356/97
183/97
163/97
179/97
187/97
093/97
109/97
5.5.0
A042
A044
A045
A047
A048
A049
r97
r96
r96
r96
r96
r96
B
A
D
F
D
F
Extended language preference
Clarification of electrical/mechanical SIM/ME interface
Security procedures for 2nd level; DFs located under DF GSM
Number of bytes returned after a SELECT command
Serivce table and "radio interface"
Update Access condition of EFDCK (aligns 11.11 & 02.22)
5.6.0
788/97
788/97
788/97
788/97
788/97
788/97
788/97
97/249
97/243
97/259
97/262
97/260
97/271
97/261
5.6.0
r97
r96
r97
r96
r96
r97
r97
B
F
C
F
F
C
B
Short Message Status Reports
Addition of SDN and BDN in the description of EFCCP
SIM and ME behaviour when SIM is disabled and blocked
Response data following an ENVELOPE command
Coding of EFPhase
Changes to Dialling Number Files and extensions
Network's indication of alerting in the MS
5.7.0
97-0886
97-0886
97/365
97/383
5.7.0
r97
r97
b
c
Introduction of UCS2
MO SMS control by SIM
5.8.0
s23
s24
A046
A050
A051
A053
A054
A055
A056
A052
A057
3
1
2
1
1
2
1
2
At SMG #25, it was decided to create a version 6.0.0 of every specification that contained at least one release '97 workitem
s25
98-0157
98-0157
98-0157
98p052
98p108
98p094
5.8.0
s26
98-0398
98-0398
98p240
98p263
6.0.0
s28
P-99-184 P-99-096 6.1.0
P-99-188
A058
A059
A061
2
R97 B
R97 F
r96 A
Addition of EFs for GPRS
Clarification regarding EFCCP records
Clarification of removal of the SIM
6.0.0
A066
A069
R97 F
R97 D
RP-ACK RP-ERROR for SIM data download error.
Allocation of file ID for IS-41
6.1.0
A079
A081
R97 C
R97 D
Addition of P-TIMSI signature value to EF LOCIGPRS
Deletion of $(......)$ release markers
6.2.0
1
ETSI
122
History
Document history
V6.1.0
July 1998
Publication
V6.2.0
May 1999
Publication
ISBN 2-7437-3097-8
Dépôt légal : Mai 1999
ETSI
TS 100 977 V6.2.0 (1999-05)
GSM
TECHNICAL
SPECIFICATION
GSM 11.14
December 1996
Version 5.2.0
Source: ETSI TC-SMG
Reference: TS/SMG-091114QR
ICS: 33.020
Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM)
R
GLOBAL SYSTEM FOR
Specification of the SIM Application Toolkit for the
Subscriber Identity Module - Mobile Equipment
(SIM - ME) interface
(GSM 11.14)
ETSI
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [email protected]
Tel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1996. All rights reserved.
Page 2
GSM 11.14 version 5.2.0: December 1996
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.
Page 3
Contents
Foreword ...........................................................................................................................................7
1
Scope.......................................................................................................................................9
2
Normative references.................................................................................................................9
3
Definitions, abbreviations and symbols ...................................................................................... 10
3.1
Definitions................................................................................................................. 10
3.2
Abbreviations ............................................................................................................ 11
3.3
Symbols ................................................................................................................... 12
4
Overview of SIM Application Toolkit .......................................................................................... 12
4.1
Profile Download ....................................................................................................... 12
4.2
Proactive SIM ........................................................................................................... 12
4.3
Data download to SIM ............................................................................................... 12
4.4
Menu selection .......................................................................................................... 12
4.5
Call control by SIM .................................................................................................... 12
4.6
Security .................................................................................................................... 13
5
Profile download...................................................................................................................... 13
5.1
Procedure................................................................................................................. 13
5.2
Structure and coding of TERMINAL PROFILE ............................................................. 13
6
Proactive SIM ......................................................................................................................... 14
6.1
Introduction............................................................................................................... 14
6.2
Identification of proactive SIMs and of ME support....................................................... 16
6.3
General procedure .................................................................................................... 16
6.4
Proactive SIM commands and procedures................................................................... 16
6.4.1
DISPLAY TEXT...................................................................................... 16
6.4.2
GET INKEY ........................................................................................... 17
6.4.3
GET INPUT............................................................................................ 17
6.4.4
MORE TIME .......................................................................................... 18
6.4.5
PLAY TONE........................................................................................... 18
6.4.6
POLL INTERVAL.................................................................................... 19
6.4.7
REFRESH.............................................................................................. 19
6.4.8
SET UP MENU ....................................................................................... 20
6.4.9
SELECT ITEM ....................................................................................... 20
6.4.10
SEND SHORT MESSAGE....................................................................... 20
6.4.11
SEND SS............................................................................................... 21
6.4.12
SEND USSD .......................................................................................... 21
6.4.13
SET UP CALL ........................................................................................ 22
6.4.14
POLLING OFF ....................................................................................... 23
6.4.15
PROVIDE LOCAL INFORMATION .......................................................... 23
6.5
Common elements in proactive SIM commands ........................................................... 23
6.5.1
Command number .................................................................................. 23
6.5.2
Device identities ..................................................................................... 23
6.5.3
Alpha identifier in response data .............................................................. 24
6.6
Structure of proactive SIM commands......................................................................... 24
6.6.1
DISPLAY TEXT...................................................................................... 25
6.6.2
GET INKEY ........................................................................................... 25
6.6.3
GET INPUT............................................................................................ 25
6.6.4
MORE TIME .......................................................................................... 25
6.6.5
PLAY TONE........................................................................................... 26
6.6.6
POLL INTERVAL.................................................................................... 26
Page 4
6.7
6.8
6.9
6.6.7
SET-UP MENU .......................................................................................26
6.6.8
SELECT ITEM........................................................................................27
6.6.9
SEND SHORT MESSAGE.......................................................................27
6.6.10
SEND SS ...............................................................................................27
6.6.11
Reserved for SEND USSD.......................................................................27
6.6.12
SET UP CALL ........................................................................................28
6.6.13
REFRESH..............................................................................................28
6.6.14
POLLING OFF .......................................................................................28
6.6.15
PROVIDE LOCAL INFORMATION...........................................................28
Command results.......................................................................................................29
Structure of TERMINAL RESPONSE ..........................................................................30
Handling of unknown, unforeseen and erroneous messages ..........................................31
6.9.1
General..................................................................................................31
6.9.2
Message too short..................................................................................31
6.9.3
Missing minimum information....................................................................31
6.9.4
Unknown Tag value.................................................................................32
6.9.5
Unexpected Tag value.............................................................................32
6.9.6
Length errors..........................................................................................32
6.9.7
Contents not understood .........................................................................32
6.9.8
Extended length data objects...................................................................32
7
Data download to SIM .............................................................................................................33
7.1
SMS-PP data download.............................................................................................33
7.1.1
Procedure ..............................................................................................33
7.1.2
Structure of ENVELOPE (SMS-PP DOWNLOAD) .....................................33
7.2
Cell Broadcast data download ....................................................................................34
7.2.1
Procedure ..............................................................................................34
7.2.2
Structure of ENVELOPE (CELL BROADCAST DOWNLOAD) ....................34
8
Menu Selection........................................................................................................................34
8.1
Procedure.................................................................................................................34
8.2
Structure...................................................................................................................35
9
Call Control by SIM..................................................................................................................35
9.1
Procedure for mobile originated calls...........................................................................35
9.2
Procedure for Supplementary Services........................................................................35
9.3
Interaction with Fixed Dialling Number .........................................................................36
9.4
Support of Barred Dialling Number (BDN) service.........................................................36
9.5
Structure of ENVELOPE (CALL CONTROL) ................................................................37
10
Security requirements ..............................................................................................................38
11
SIMPLE-TLV data objects........................................................................................................38
11.1
Address ....................................................................................................................38
11.2
Alpha identifier...........................................................................................................39
11.3
Called party subaddress ............................................................................................39
11.4
Capability configuration parameters ............................................................................39
11.5
Cell Broadcast Page..................................................................................................39
11.6
Command details.......................................................................................................40
11.7
Device identities ........................................................................................................42
11.8
Duration....................................................................................................................42
11.9
Item..........................................................................................................................43
11.10
Item identifier ............................................................................................................43
11.11
Response length........................................................................................................43
11.12
Result.......................................................................................................................43
11.12.1
Additional information for SEND SS ..........................................................44
11.12.2
Additional information for ME problem ......................................................44
11.12.3
Additional information for network problem................................................45
11.12.4
Additional information for SS problem .......................................................45
11.12.5
Additional information for SMS problem ....................................................45
Page 5
11.13
11.14
11.15
11.16
11.17
11.18
11.19
11.20
SMS TPDU ............................................................................................................... 45
SS string................................................................................................................... 46
Text string................................................................................................................. 46
11.15.1
Coding of text in unpacked format ............................................................ 46
11.15.2
Coding of text in packed format ............................................................... 46
Tone......................................................................................................................... 46
Reserved for USSD string .......................................................................................... 47
File List..................................................................................................................... 47
LOCATION INFORMATION ....................................................................................... 48
IMEI ......................................................................................................................... 48
12
Tag values .............................................................................................................................. 48
12.1
BER-TLV tags in ME to SIM direction ......................................................................... 48
12.2
BER-TLV tags in SIM TO ME direction ....................................................................... 48
12.3
SIMPLE-TLV tags in both directions............................................................................ 48
13
Allowed Type of command and Device identity combinations....................................................... 50
Mandatory support of SIM Application Toolkit by Mobile Equipment ................ 51
Annex B (informative):
Example command sequences for proactive SIM ........................................... 52
Example of DISPLAY TEXT Proactive SIM Command.................................... 55
History ............................................................................................................................................. 56
Page 6
Blank page
Page 7
Foreword
This Global System for Mobile communications Technical Specification (GTS) has been produced by the
Special Mobile Group (SMG) Technical Committee (TC) of the European Telecommunications Standards
Institute (ETSI).
This GTS defines the interface between the Subscriber Identity Module (SIM) and the Mobile Equipment
(ME) within the digital cellular telecommunications system.
This GTS is a TC-SMG approved GSM technical specification version 5.
GTS are produced by TC-SMG to enable the GSM Phase 2 + specifications to become publicly available,
prior to submission for the formal ETSI standards approval procedure to become European
Telecommunications Standards (ETS). This ensures the earliest possible access to GSM Phase 2+
specifications for all Manufacturers, Network operators and implementors of the Global System for Mobile
communications.
The contents of this GTS are subject to continuing work within TC-SMG and may change following formal
TC-SMG approval. Should TC-SMG modify the contents of this GTS it will then be republished by ETSI
with an identifying change of release date and an increase in version number as follows:
Version 5.x.y
where:
y
x
the third digit is incremented when editorial only changes have been incorporated in the
specification;
the second digit is incremented for all other types of changes, i.e. technical enhancements,
corrections, updates, etc.
The specification from which this GTS has been derived was originally based on CEPT documentation,
hence the presentation of this GTS may not be entirely in accordance with the ETSI rules.
Page 8
Blank page
Page 9
1
Scope
This Global System for Mobile communications Technical Specification (GTS) defines the interface
between the Subscriber Identity Module (SIM) and the Mobile Equipment (ME), and mandatory ME
procedures, specifically for "SIM Application Toolkit".
SIM Application Toolkit is a set of commands and procedures for use during the network operation phase
of GSM, in addition to those defined in GSM 11.11 [14].
Specifying the interface is to ensure interoperability between a SIM and an ME independently of the
respective manufacturers and operators. The concept of a split of the Mobile Station (MS) into these
elements as well as the distinction between the GSM network operation phase, which is also called GSM
operations, and the administrative management phase are described in GSM 02.17 [3].
This Technical Specification defines:
-
the commands;
-
the application protocol;
-
the mandatory requirements on the SIM and ME for each procedure.
Unless otherwise stated, references to GSM also apply to DCS 1 800.
This standard does not specify any aspects related to the administrative management phase. Any internal
technical realization of either the SIM or the ME are only specified where these reflect over the interface.
This standard does not specify any of the security algorithms which may be used.
This Technical Specification defines an enhancement for GSM Phase 2+ of the SIM/ME interface for GSM
Phase 2. While all attempts have been made to maintain phase compatibility, any issues that specifically
relate to Phase 1 should be referenced from within the relevant Phase 1 specification.
2
Normative references
This GTS incorporates, by dated or undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to, or revisions of, any of these publications
apply to this GTS only when incorporated in it by amendment or revision. For undated references the latest
edition of the publication referred to applies.
[1]
GSM 01.02: "Digital cellular telecommunications system (Phase 2+); General
description of a GSM Public Land Mobile Network (PLMN)".
[2]
GSM 01.04 (ETR 350): "Digital cellular telecommunications system (Phase 2+);
Abbreviations and acronyms".
[3]
GSM 02.17 (ETS 300 922): "Digital cellular telecommunications
Subscriber Identity Modules (SIM) Functional characteristics".
system;
[4]
(Phase 2+); Man-Machine Interface (MMI) of the Mobile Station (MS)".
system
[5]
(Phase 2+); Alphabets and language-specific information".
system
[6]
GSM 03.40 (ETS 300 901): "Digital cellular telecommunications system
(Phase 2+); Technical realization of the Short Message Service (SMS)
Point-to-Point (PP)".
Page 10
[7]
(Phase 2+); Technical realization of Short Message Service Cell Broadcast
(SMSCB)".
[8]
(Phase 2+); Mobile radio interface layer 3 specification".
[9]
(Phase 2+); Point-to-Point (PP) Short Message Service (SMS) support on
mobile radio interface".
[10]
(Phase 2+); Mobile radio interface layer 3 supplementary services specification;
Formats and coding".
[11]
Unstructured Supplementary Service Data (USSD) - Stage 3".
[12]
GSM 07.05: "Digital cellular telecommunications system (Phase 2+); Use of
Data Terminal Equipment - Data Circuit terminating Equipment (DTE - DCE)
interface for Short Message Service (SMS) and Cell Broadcast Service (CBS)".
[13]
GSM 09.91 (ETR 360): "Digital cellular telecommunications system; Interworking
aspects of the Subscriber Identity Module - Mobile Equipment (SIM - ME)
interface between Phase 1 and Phase 2".
[14]
(Phase 2); Specification of the Subscriber Identity Module - Mobile Equipment
(SIM - ME) interface"
[15]
CCITT Recommendation E.164: "Numbering plan for the ISDN era".
[16]
ISO/IEC 7816-3 (1989): "Identification cards - Integrated circuit(s) cards with
contacts, Part 3: Electronic signals and transmission protocols".
[17]
ISO/IEC 7816-6 (1995): "Identification cards - Integrated circuit(s) cards with
contacts, Part 6 Inter-industry data elements".
[18]
(Phase 2); Procedures for call progress indications".
[19]
GSM 02.07 (ETS 300 906): "Digital cellular
(Phase 2+); Mobile Stations (MS) features".
[20]
(Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment
(SIM - ME) interface".
[21]
GSM 11.12 (ETSI 300 641): "Digital cellular telecommunications system
(Phase 2); Specification of the 3 Volt Subscriber Identity Module - Mobile
Equipment (SIM - ME) interface".
3
3.1
telecommunications
system
system;
system
Definitions, abbreviations and symbols
Definitions
For the purposes of this GTS, the following definitions apply. For further information and definitions refer to
GSM 01.02 [1].
Page 11
application: An application consists of a set of security mechanisms, files, data and protocols (excluding
transmission protocols).
application protocol: The set of procedures required by the application.
card session: A link between the card and the external world starting with the ATR and ending with a
subsequent reset or a deactivation of the card.
data object: Information seen at the interface for which are defined a tag (identifier), a length and a value.
Data objects can be either BER-TLV (objects that conform to the Basic Encoding Rules of ASN.1) or
SIMPLE-TLV. In this specification, all BER-TLV data objects are "primitive": the value part consists only of
SIMPLE-TLV data objects.
padding: One or more bits appended to a message in order to cause the message to contain the required
number of bits or bytes.
proactive SIM: A SIM which is capable of issuing commands to the ME within the T=0 protocol.
SIM Application Toolkit: A set of applications and related procedures which may be used during a GSM
session.
3.2
Abbreviations
For the purpose of this GTS, the following abbreviations apply, in addition to those listed in GSM 01.04 [2]:
A3
A5
A8
A38
ADN
APDU
BCD
BDN
CB
CBMI
CCP
DCS
DTMF
EF
ETSI
etu
FDN
GSM
ID
IEC
IMSI
ISO
Kc
Ki
lgth
LND
ME
MMI
MS
NPI
RAND
RFU
SIM
SMS
Algorithm 3, authentication algorithm; used for authenticating the subscriber
Algorithm 5, cipher algorithm; used for enciphering/deciphering data
Algorithm 8, cipher key generator; used to generate Kc
A single algorithm performing the functions of A3 and A8
Abbreviated Dialling Number
Binary Coded Decimal
Barred Dialling Number
Cell Broadcast
Capability/Configuration Parameter
Digital Cellular System
Dual Tone Multiple Frequency
Elementary File
elementary time unit
Fixed Dialling Number
Global System for Mobile communications
IDentifier
International Electrotechnical Commission
International Organization for Standardization
Cryptographic key; used by the cipher A5
Subscriber authentication key; the cryptographic key used by the authentication
algorithm, A3, and cipher key generator, A8
The (specific) length of a data unit
Last Number Dialled
Mobile Equipment
Man Machine Interface
Mobile Station
Numbering Plan Identifier
A RANDom challenge issued by the network
Subscriber Identity Module
Short Message Service
Page 12
SRES
SS
SSC
SW1/SW2
TLV
TON
TP
TS
USSD
3.3
Signed RESponse calculated by a SIM
Supplementary Service Control string
Tag, length, value.
Type Of Number
Unstructured Supplementary Service Data
Symbols
"0" to "9" and "A" to "F" The sixteen hexadecimal digits.
4
Overview of SIM Application Toolkit
The SIM Application Toolkit provides mechanisms which allow applications, existing in the SIM, to interact
and operate with any ME which supports the specific mechanism(s) required by the application.
The following mechanisms have been defined. These mechanisms are dependent upon the commands and
protocols relevant to SIM Application Toolkit in GSM 11.11 [20].
4.1
Profile Download
Profile downloading provides a mechanism for the ME to tell the SIM what it is capable of. The ME knows
what the SIM is capable of through the SIM Service Table and EFPHASE.
4.2
Proactive SIM
Proactive SIM gives a mechanism whereby the SIM can initiate actions to be taken by the ME. These
actions include:
4.3
display text from the SIM to the ME;
send a short message;
set up a voice call to a number held by the SIM;
set up a data call to a number and bearer capabilities held by the SIM;
send a SS control or USSD string;
play tone in earpiece;
initiate a dialogue with the user;
SIM initialization request and notification of changes to EF(s);
provide local information from the ME to the SIM.
Data download to SIM
Data downloading to the SIM uses the transport mechanisms of SMS point-to-point and Cell Broadcast.
Transferral of information over the SIM-ME interface uses the ENVELOPE command.
4.4
Menu selection
A set of possible menu entries is supplied by the SIM in a proactive SIM command. The menu selection
mechanism is used to transfer the SIM application menu item which has been selected by the user to the
SIM.
4.5
Call control by SIM
When this service is activated by the SIM, all dialled digit strings and supplementary service control strings
are first passed to the SIM before the ME sets up the call or the supplementary service operation. The
SIM has the ability to allow, bar or modify the call or the supplementary service operation.
Page 13
4.6
Security
Applications designed using the features in this specification may require methods to ensure data
confidentiality, data integrity, and data sender validation, or any subset of these. Requirements for these
mechanisms are defined in section 10.
5
5.1
Profile download
Procedure
The profile download instruction is sent by the ME to the SIM as part of the SIM initialization procedure.
This procedure is specified in GSM 11.11 [14]. In this procedure, the ME reads EFPHASE. If the EF
indicates that the SIM requires the ME to perform the profile download procedure, then the ME shall send,
as the next instruction to be sent to the SIM, the TERMINAL PROFILE command as specified below. The
profile sent by the ME shall state the facilities relevant to SIM Application Toolkit that are supported by the
ME.
This procedure is important, as it is by this that the SIM knows what the ME is capable of, and the SIM
can then limit its instruction range accordingly. If no command is sent by the ME, the SIM shall assume that
the ME does not support SIM Application Toolkit.
5.2
Structure and coding of TERMINAL PROFILE
Direction: ME to SIM
The command header is specified in GSM 11.11 [14].
Description
Profile
-
Section
M/O
Length
-
M
lgth
Profile:
Contents:
The list of SIM Application Toolkit facilities that are supported by the ME.
Coding:
1 bit is used to code each facility:
bit = 1: facility supported by ME
bit = 0: facility not supported by ME
)LUVWE\WH'RZQORDG
¸¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¹
·E·E·E·E·E·E·E·E·
º¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶»
·······º¶¶3URILOHGRZQORDG
······º¶¶¶¶¶60633GDWDGRZQORDG
·····º¶¶¶¶¶¶¶¶&HOO%URDGFDVWGDWDGRZQORDG
····º¶¶¶¶¶¶¶¶¶¶¶0HQXVHOHFWLRQ
º¶¶¿¶¶¿¶¶¿¶¶¶¶¶¶¶¶¶¶¶¶¶¶5)8ELW 6HFRQGE\WH2WKHU
¸¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¹
º¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶»
·······º¶¶&RPPDQGUHVXOW
······º¶¶¶¶¶&DOO&RQWUROE\6,0
º¶¶¿¶¶¿¶¶¿¶¶¿¶¶¿¶¶¶¶¶¶¶¶5)8ELW Page 14
7KLUGE\WH3URDFWLYH6,0
¸¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¹
º¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶»
·······º¶¶3URDFWLYH6,0
······º¶¶¶¶¶3URDFWLYH6,0
·····º¶¶¶¶¶¶¶¶3URDFWLYH6,0
····º¶¶¶¶¶¶¶¶¶¶¶3URDFWLYH6,0
···º¶¶¶¶¶¶¶¶¶¶¶¶¶¶3URDFWLYH6,0
··º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶3URDFWLYH6,0
·º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶3URDFWLYH6,0
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶3URDFWLYH6,0
)RXUWKE\WH3URDFWLYH6,0
¸¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¹
º¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶»
·······º¶¶3URDFWLYH6,0
······º¶¶¶¶¶3URDFWLYH6,0
·····º¶¶¶¶¶¶¶¶3URDFWLYH6,0
····º¶¶¶¶¶¶¶¶¶¶¶3URDFWLYH6,0
···º¶¶¶¶¶¶¶¶¶¶¶¶¶¶3URDFWLYH6,0
__º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶3URDFWLYH6,0
_º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶3URDFWLYH6,0
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶5)8ELW ',63/$<7(;7
*(7,1.(<
*(7,1387
025(7,0(
3/$<721(
32//,17(59$/
32//,1*2))
5()5(6+
6(/(&7,7(0
6(1'6+2570(66$*(
6(1'66
5HVHUYHGIRU6(1'866'
6(783&$//
6(7830(18
3529,'(/2&$/,1)250$7,21
6XEVHTXHQWE\WHV
¸¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¾¶¶¹
º¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶¿¾¶»
º¶¶¿¶¶¿¶¶¿¶¶¿¶¶¿¶¶¿¶¶¿¶¶5)8ELW RFU bits, and all bits of subsequent bytes, are reserved to indicate future facilities. A SIM
supporting only the features of SIM Application Toolkit defined here shall not check the value of
RFU bits.
Response parameters/data: None.
6
6.1
Proactive SIM
Introduction
GSM 11.11 [14] defines that the ME communicates to the SIM using the T=0 protocol, which is specified in
ISO/IEC 7816-3 [16]. The ME is always the "master", and initiates commands to the SIM, and therefore
there is no mechanism for the SIM to initiate a communication with the ME. This limits the possibility of
introducing new SIM features requiring the support of the ME, as the ME needs to know in advance what
actions it should take.
The proactive SIM service provides a mechanism which stays within the protocol of T=0, but adds a new
status response word SW1. This status response has the same meaning as the normal ending ("90 00"),
and can be used with most of the commands that allow the normal ending, but it also allows the SIM to
say to the ME "I have some information to send to you". The ME then uses the FETCH function to find out
what this information is.
To avoid cross-phase compatibility problems, these functions shall only be used between a proactive SIM
and an ME that supports the proactive SIM feature.
The SIM can issue a variety of commands through this mechanism, given in alphabetical order:
-
DISPLAY TEXT, which displays text on screen (no more than 160 characters). A high priority is
available, to replace anything else on screen.
-
GET INKEY, which sends text to the display and requests a single character response in return. It is
intended to allow a dialogue between the SIM and the user, particularly for selecting an option from
a menu.
Page 15
-
GET INPUT, which sends text to the display and requests a response in return. It is intended to
allow a dialogue between the SIM and the user.
-
MORE TIME, which does not request any action from the ME. The ME is required to respond with
TERMINAL RESPONSE (OK) as normal - see below. The purpose of the MORE TIME command is
to provide a mechanism for the SIM Application Toolkit task in the SIM to request more processing
time.
-
PLAY TONE, which requests the ME to play a tone in its earpiece, ringer, or other appropriate
loudspeaker.
-
POLL INTERVAL, which negotiates how often the ME sends STATUS commands to the SIM during
idle mode. Polling is disabled with POLLING OFF. Use of STATUS for the proactive SIM is
described in GSM 11.11 [14].
-
REFRESH, which requests the ME to carry out a SIM initialization according to GSM 11.11
subclause 11.2.1, and/or advises the ME that the contents or structure of EFs on the SIM have
been changed. The command also makes it possible to restart a card session by resetting the SIM.
-
SELECT ITEM, where the SIM supplies a list of items, and the user is expected to choose one. The
ME presents the list in an implementation-dependent way.
-
SEND SHORT MESSAGE, which sends a short message or SMS-COMMAND to the network.
-
SEND SS, which sends a SS request to the network.
-
SEND USSD, which sends an USSD string to the network.
-
SET UP CALL, of which there are three types:
set up a call, but only if not currently busy on another call;
set up a call, putting all other calls (if any) on hold;
set up a call, disconnecting all other calls (if any);
SET UP MENU, where the SIM supplies a list of items to be incorporated into the ME's menu
structure.
-
PROVIDE LOCAL INFORMATION which requests the ME to pass local information to the SIM, for
example the mobile country and network codes (MCC + MNC) of the network on which the user is
registered.
The ME tells the SIM if the command was successful or not using the command result procedure defined in
section 6.7. Responsibility for what happens after that (whether to repeat the command, try another one
immediately, try again sometime later, or not to try again at all) lies with the SIM application. However, the
SIM application needs to know why the command failed, so the ME provides the SIM with the result of the
command.
Results are grouped into three main types:
-
OK.
-
Temporary problem. These results are further broken down into types of temporary problems, and
specific causes. Generally, they indicate to the SIM that it may be worth trying again.
-
Permanent problem. These results are again further broken down into types of permanent problems,
and specific causes. Generally, they indicate to the SIM that it is not worth trying again during this
GSM session.
Page 16
6.2
Identification of proactive SIMs and of ME support
A proactive SIM shall be identified by having the proactive SIM service activated in the SIM Service Table
(see GSM 11.11 [14]). An ME that supports proactive SIMs shall be identified as such when it sends a
TERMINAL PROFILE command during SIM initialization. The ME shall then send STATUS commands to
the SIM at intervals determined by the poll interval procedure (see section 6.4.6).
A proactive SIM shall not send any command requests (status bytes SW1 SW2 = "91 XX") to a mobile
that does not support the proactive SIM feature.
An ME that supports the proactive SIM feature shall not send proactive SIM related commands to a SIM
that does not have the proactive SIM service activated.
6.3
General procedure
For all of the procedures that can end in "90 00" (indicating normal ending to the command), and which
cannot end in "9F XX" (response data available from SIM), a proactive SIM operating with an ME that
supports proactive SIMs may instead use the status response "91 XX".
The response code "91 XX" shall indicate to the ME that the previous command has been successfully
executed by the SIM in the same way as "90 00" (i.e. "OK"), but additionally it shall indicate response data
which contains a command from the SIM for a particular ME procedure (defined in section 6.4).
The value "XX" indicates the length of the response data. The ME shall use the FETCH command to obtain
this data.
GSM 11.11 [20] shows how the SIM can initiate a proactive command in each of the five cases of
transmission protocol identified in GSM 11.11 [14]. Some commands require the SIM to indicate that it has
response data for the ME (through SW1/SW2 = "9F XX"), and the ME gets this data using the GET
RESPONSE command.
When the ME has received a command from the SIM, it shall attempt to process the command
immediately.
-
If the command has been successfully executed, the ME shall inform the SIM immediately, using
TERMINAL RESPONSE.
-
If the command was not successfully executed, the ME shall inform the SIM immediately using
TERMINAL RESPONSE with an error condition.
Responsibility for re-trying lies with the SIM application. The SIM application can make a judgement
whether to send the same command again, to send a different one, or not to try again, from the
information given by the ME in TERMINAL RESPONSE. If the SIM application wishes the ME to try again,
it shall issue a new (identical) command.
6.4
Proactive SIM commands and procedures
6.4.1
DISPLAY TEXT
Four types are defined:
-
Display normal priority text on screen (packed format);
Display normal priority text on screen (unpacked format);
-
Display high priority text on screen (packed format);
Display high priority text on screen (unpacked format).
Page 17
When text is to be explicitly displayed by the ME, a flag shall be set to inform the ME if it should clear the
message and return to what was present previously after a short delay (the duration of the delay being at
the discretion of the ME manufacturer), or whether the message shall remain on the display until the user
clears it. The first instance would normally only be used where it is expected that the user is already
looking at the display.
NOTE:
For the case where the text is cleared after a short delay, the ME may also allow the
user to clear the display via the MMI prior to this.
The ME shall reject normal priority text commands if the screen is currently being used for more than its
normal stand-by display. If the command is rejected, the ME informs the SIM using TERMINAL
RESPONSE (ME currently unable to process command - screen busy).
High priority text must be displayed on the screen immediately.
6.4.2
GET INKEY
This command instructs the ME to display text, and to expect the user to enter a single character. Any
response entered by the user shall be passed transparently by the ME to the SIM.
The text can be in one of two formats:
-
packed format;
unpacked format.
The response can be from one of two character sets. This is specified by the SIM:
-
digits only (0-9, *, #, and +);
characters from the SMS default alphabet.
Upon receiving the command, the ME shall display the text. The ME shall allow the user to enter a single
character in response.
-
If the user presses END (or otherwise declines to respond, e.g. CLEAR), the ME shall give a null
text string to the SIM, using TERMINAL RESPONSE.
-
If the SIM requests a digit only, the ME shall only allow the user to enter a character from the
digits 0-9, *, # and +. When the user has entered a digit, the ME shall pass the entered digit
transparently to the SIM, using TERMINAL RESPONSE.
-
If the SIM requests a character from the SMS default alphabet, the ME shall allow the user to enter
a character using characters from this alphabet. When the user has entered a character, the ME
shall pass the entered character transparently to the SIM, using TERMINAL RESPONSE.
NOTE:
If the MMI of the ME requires more than one keypress in order to select a character, it
is an implementation decision for the ME manufacturer how to indicate completion (e.g.
timeout, pressing SEND, OK). It may be useful to echo the input character on the
display.
For both character sets, the response shall be coded using the SMS default alphabet in unpacked format.
6.4.3
GET INPUT
This command instructs the ME to display text, and that any response string entered by the user shall be
passed transparently by the ME to the SIM.
The text can be in one of two formats:
-
packed format;
unpacked format.
Page 18
The SIM indicates how many characters are expected for the response string, by giving a minimum and a
maximum acceptable length.
The SIM specifies three variables for the response string it is expecting from the user:
-
the response contains either digits only (0-9, *, # and +) or characters from the SMS default
alphabet;
the response is either in an unpacked format or in a packed format;
the ME may display the text string being entered by the user (the response), or the ME shall
hide (i.e. not display) the actual text string.
If the SIM requests that the user input (text string) is to be hidden, it is permissible for the ME to indicate
the entry of characters, so long as the characters themselves are not revealed.
Upon receiving the command, the ME shall display the text. The ME shall allow the user to enter
characters in response.
-
The ME MMI is responsible for managing the entry of the correct number of characters.
-
If the user presses END (or otherwise declines to respond), the ME shall give a null text string to the
SIM, using TERMINAL RESPONSE.
-
If the SIM requests digits only, the ME shall only allow the user to enter the digits 0-9, *, # and +.
When the user presses SEND (or otherwise indicates completion), the ME shall pass the entered
digit string transparently to the SIM, using TERMINAL RESPONSE.
-
If the SIM requests characters from the SMS default alphabet, the ME shall allow the user to enter
a character string using characters from this alphabet. When the user presses SEND (or otherwise
indicates completion), the ME shall pass the entered text string transparently to the SIM, using
TERMINAL RESPONSE.
If the SIM requests the user input to be in packed format, then the ME shall pack the text according to
GSM 03.38 [5] before submitting it to the SIM.
6.4.4
MORE TIME
This procedure is provided to allow the SIM Application Toolkit task in the SIM more time for processing,
where the processing is so long that it is in danger of affecting normal GSM operation, and clock stop
prevents processing to take place in the background.
The ME shall take no extraordinary action when it receives this command, and all other operations shall be
unaffected. The ME shall conclude the command by sending TERMINAL RESPONSE (OK) to the SIM, as
soon as possible after receiving the MORE TIME command.
6.4.5
PLAY TONE
This command instructs the ME to play an audio tone.
Upon receiving this command, the ME shall check if it is currently in, or in the process of setting up
(SET-UP message sent to the network, see GSM 04.08 [8]), a speech call.
-
If the ME is in, or is setting up a speech call, it shall superimpose the tone on top of the downlink
audio (if any), for the duration given in the command. The progress or current state of the call shall
not be affected in any way.
-
If the ME is not in or setting up a speech call, it shall route the audio to the external ringer, or other
appropriate audio device, and play the tone for the duration given in the command.
Page 19
-
If ME support for the specific tone requested is optional, and the ME does not support this particular
tone, the ME shall inform the SIM using TERMINAL RESPONSE (Command beyond ME's
capabilities).
This proactive command contains no information on how a call is progressing; therefore the ME shall not
generate any verbal indication or display any text or graphical indication about the normal meaning of this
tone (e.g. display "called subscriber busy"). If the SIM wishes to convey a meaning in text to the user, it
shall do this through the alpha identifier data object.
If the ME is required to generate a supervisory tone due to the progress of the current call (e.g. the
network sends the ME call control cause information) as defined in GSM 02.40 [18], then the call
supervisory tone shall take precedence over the tone requested by the SIM.
6.4.6
POLL INTERVAL
This procedure negotiates the maximum interval of time between STATUS commands issued by the ME
when in idle mode. The SIM requests the time interval it would like from then onwards, and the ME
responds through TERMINAL RESPONSE with the maximum interval that it will use. This can be greater,
less than, or exactly the same as requested by the SIM.
NOTE:
6.4.7
Applications on the SIM should not request short time intervals for an extended period,
as this will have an adverse effect on battery life.
REFRESH
The purpose of this command is to enable the ME to be notified of the changes to the SIM configuration
that have occurred during a SIM application. It is up to the SIM application to ensure that this is done
correctly.
The command supports five different modes:
-
SIM Initialization. This mode tells the ME to carry out SIM initialization as it is defined in GSM 11.11
subclause 11.2.1 only, starting after the CHV1 verification procedure. The ME shall not reset the
SIM electrically.
-
File Change Notification. This mode advises the ME of the identity of the EFs that have been
changed (in structure and/or contents) in the SIM. This information can be used by the ME if there is
an image of SIM EFs (e.g. the ADN file) in the ME's memory, to determine whether it needs to
update this image.
-
SIM Initialization and File Change Notification. This is a combination of the first two modes above.
-
SIM Initialization and Full File Change Notification. This mode causes the ME to perform the SIM
initialization procedure of the first mode above and advises the ME that several EFs have been
changed (in structure or contents) in the SIM. If there is an image of SIM EFs in the ME's memory,
the ME shall completely update this image.
-
SIM Reset. This mode causes the ME to run the GSM session termination procedure and to
deactivate the SIM in accordance with GSM 11.11 [20]. Subsequently, the ME activates the SIM
again and starts a new card session. In case of a 3 Volt technology ME, the ME shall restart the
SIM with the same supply voltage as in the previous session, if the ME can ensure that the SIM has
not been changed in between. Otherwise, the ME shall perform the supply voltage switching in
accordance with GSM 11.12 [21]. The SIM Reset mode is used when a SIM application requires
ATR or complete SIM initialization procedures to be performed.
NOTE:
Many MEs copy an image of the SIM's memory to the ME at initialization to speed up
access to these fields during a GSM session. One of the purposes of this coding of the
REFRESH command is to enable MEs to change such an image efficiently.
Page 20
6.4.8
SET UP MENU
The SIM shall supply a set of menu items, which shall be integrated with the menu system (or other MMI
facility) in order to give the user the opportunity to choose one of these menu items at his own discretion.
Each item comprises a short identifier (used to indicate the selection) and a text string. The SIM shall
include an alpha identifier which acts as a title for the list of menu items.
NOTE:
The maximum amount of data sent in one proactive SIM command is 256 bytes. It is
therefore unavoidable that there is trade-off between the number of items and the
length of the descriptive text (the alpha identifier of the SET-UP MENU command and
the text strings of the items), e.g. for an average length of 10 bytes per text string the
maximum amount of items is 18.
The list of menu items shall then be part of the menu system of the ME and the user is allowed to select an
item from this list. The presentation style is left as an implementation decision to the ME manufacturer.
When the ME has successfully integrated the list of menu items, it shall send TERMINAL RESPONSE
(OK) to the SIM.
When the ME is not able to successfully integrate the list of menu items, it shall sent TERMINAL
RESPONSE (Command beyond ME's capabilities).
Any subsequent SET-UP MENU command replaces the current list of menu items supplied in the previous
SET-UP MENU command.
When the user has selected one of the menu items of this menu item list, then the ME shall use the Menu
Selection mechanism to transfer the identifier of the selected menu item to the SIM.
6.4.9
SELECT ITEM
The SIM shall supply a set of items from which the user may choose one. Each item comprises a short
identifier (used to indicate the selection) and a text string. Optionally the SIM may include an alpha
identifier. The alpha identifier is intended to act as a title for the list of items.
NOTE:
The maximum amount of data sent in one proactive SIM command is 256 bytes. It is
therefore unavoidable that there is trade-off between the number of items and the
length of the descriptive text (the alpha identifier of the SELECT ITEM command and
the text strings of the items), e.g. for an average length of 10 bytes per text string the
maximum amount of items is 18.
The ME shall present the list of text strings to the user, and allow the user to select an item from this list.
The presentation style is left as an implementation decision to the ME manufacturer.
When the user has selected an item, the ME shall send TERMINAL RESPONSE (OK) to the SIM with the
identifier of the item chosen.
If no item was selected, the ME shall send TERMINAL RESPONSE (OK) to the SIM with null as the
identifier of the item chosen.
6.4.10
SEND SHORT MESSAGE
Two types are defined:
-
A short message to be sent to the network in an SMS-SUBMIT message, or an SMS-COMMAND
message, where the user data can be passed transparently;
-
A short message to be sent to the network in an SMS-SUBMIT message where the text needs to
be packed by the ME.
Page 21
Where the text has been packed, the text string provided by the SIM shall not be longer than
160 characters. It shall use the SMS default 7-bit coded alphabet, packed into 8-bit octets, in accordance
with GSM 03.38 [5]. The text length (which is part of the SMS TPDU) given by the SIM shall state the
number of 7-bit characters in the text string. The command details shall indicate "packing not required".
8-bit data Short Messages may be sent by the SIM. The command shall indicate packing not required. The
string shall not be longer than 140 bytes, and the length (in SMS TPDU) shall state the number of bytes in
the string.
SMS commands may be sent by the SIM. These shall count as packed text message. The SMS TPDU
from the SIM shall indicate SMS-COMMAND. The command details shall indicate "packing not required".
Where packing by the ME is required, the text string provided by the SIM shall not be longer than
160 characters. It shall use the SMS default 7-bit coded alphabet as defined in GSM 03.38 [5] with bit 8
set to 0. The text length given by the SIM shall state the number of characters in the text string. The ME
shall pack the text string in accordance with GSM 03.38 [5] before submitting the message to the network.
If the ME is capable of SMS-MO, then it shall send the data as a Short Message TPDU to the destination
address. The ME shall give the result to the SIM using TERMINAL RESPONSE (indicating successful or
unsuccessful transmission of the Short Message) after receiving an SMS RP-ACK or RP-Error from the
network.
6.4.11
SEND SS
Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are
given below, but the list is not exhaustive:
-
If the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM
using TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction);
-
If the command is rejected because the ME does not support that Supplementary Service, the ME
informs the SIM using TERMINAL RESPONSE (Command beyond ME's capabilities).
If the ME is able to send the SS request, the ME shall:
-
Send the SS request immediately, without need to alert the user first. Optionally, the ME can give
some audible or display indication concerning what is happening.
-
Once a SS Return Result message not containing an error has been received from the network, the
ME shall inform the SIM that the command has been successfully executed, using TERMINAL
RESPONSE. This command shall include the contents of SS Return Result as additional data.
Optionally, the ME may display the result on screen.
-
If the command is rejected because the network cannot support or is not allowing the
Supplementary Service request, the ME informs the SIM using TERMINAL RESPONSE (SS Return
Result error code);
-
If the SS request is unsuccessfully received by the network, the ME shall inform the SIM using
TERMINAL RESPONSE (network currently unable to process command), and not retry to send the
request.
6.4.12
SEND USSD
For further study.
Page 22
6.4.13
SET UP CALL
Three types are defined:
set up a call, but only if not currently busy on another call;
set up a call, putting all other calls (if any) on hold;
set up a call, disconnecting all other calls (if any) first.
For each of these types, the SIM may request the use of an automatic redial mechanism according to the
GSM 02.07 [19]. The SIM may also request an optional maximum duration for the redial mechanism. The
ME shall attempt at least one call set-up.
In addition to the called party number, the command may contain capability configuration parameters
(giving the bearer capability to request for the call) and the called party subaddress. The ME shall use
these in its call set-up request to the network. The command may also include DTMF digits, which the ME
shall send to the network after the call has connected.
Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are
given below, but the list is not exhaustive:
-
If the command is rejected because the ME is busy on another call, the ME informs the SIM using
TERMINAL RESPONSE (ME unable to process command - currently busy on call);
-
If the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM
using TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction);
-
If the command is rejected because the ME cannot support Call Hold, or because the ME does not
support the capability configuration parameters requested by the SIM, the ME informs the SIM using
TERMINAL RESPONSE (Command beyond ME's capabilities);
-
If the command is rejected because the network cannot support or is not allowing Call Hold, the ME
informs the SIM using TERMINAL RESPONSE (SS Return Result error code).
If the ME is able to set up the call on the serving network, the ME shall:
-
Alert the user (as for an incoming call). Optionally, the ME can give some indication to the user
concerning what is happening, perhaps using the alpha identifier in the command data from the SIM;
-
If the user accepts the call, the ME shall then set up a call to the destination address given in the
response data, with the relevant capability configuration parameters and called party subaddress (if
provided by the SIM);
-
If the user does not accept the call, or rejects the call, then the ME informs the SIM using
TERMINAL RESPONSE (user did not accept call set-up request). The operation is aborted;
-
Optionally, during call set-up, the ME can give some audible or display indication concerning what is
happening;
-
Once a CONNECT message has been received from the network (defined in GSM 04.08), the ME
shall inform the SIM that the command has been successfully executed, using TERMINAL
RESPONSE. Operation of the call then proceeds as normal.
If the first call set-up attempt is unsuccessful:
-
If the SIM did not request redial then the ME shall inform the SIM using TERMINAL RESPONSE
(network currently unable to process command), and not redial to set-up the call;
-
If the SIM requested redial, then the ME may automatically redial the call (depending on its
capability/configuration). In this case, the ME shall not send a command result to the SIM
concerning the first or any subsequent failed set-up attempts. If the call set-up has not been
successful, and the ME is not going to perform any more redials, or the time elapsed since the first
Page 23
call set-up attempt has exceeded the duration requested by the SIM, then the ME shall inform the
SIM using TERMINAL RESPONSE (network currently unable to process command), and the redial
mechanism shall be terminated;
-
6.4.14
If the user stops the call set-up attempt or the redial mechanism before a result is received from the
network, the ME informs the SIM using TERMINAL RESPONSE (user cleared down call before
connection or network release).
POLLING OFF
This command cancels the effect of any previous POLL INTERVAL commands.
6.4.15
PROVIDE LOCAL INFORMATION
This command requests the ME to send current local information to the SIM. At present this information is
restricted to:
-
location information: the mobile country code (MCC), mobile network code (MNC), location area
code (LAC) and cell ID;
the IMEI of the ME.
The ME shall return the requested local information within a TERMINAL RESPONSE. If the ME does not
store the requested local information, then the ME shall return TERMINAL RESPONSE (Command beyond
ME's capabilities). Where location information has been requested, TERMINAL RESPONSE (temporary
problem with executing command - no service is currently available) may also be applicable.
6.5
6.5.1
Common elements in proactive SIM commands
Command number
The command number is to cater for the future possibility of multiple ongoing commands (i.e. when the
SIM issues further commands before receiving the response to the ongoing command). The implications of
such multiple ongoing commands have not been elaborated at this stage of the toolkit specification.
Each command issued by a proactive SIM during a GSM session shall have its own command number.
Command numbers may take any hexadecimal value between "01" and "FE". The command number is held
in the command details data object.
The SIM is responsible for assigning the command number.
The ME shall keep a record of the status of each command and its command number, until the ME gives
the result of the command to the SIM, using TERMINAL RESPONSE. After this, the ME may erase all
internal records concerning this command. The command number is then free for allocation by the SIM to a
new command.
When the MS is powered off and on, the details of any ongoing command shall be reset. The ME shall not
be expected to know the status of commands issued in a previous GSM session.
6.5.2
Device identities
This data object gives the devices which are the source and destination for the instruction. Only certain
combinations of source and destination devices are allowed for each proactive command. These are given
in section 13 of this document.
Page 24
6.5.3
Alpha identifier in response data
Many of the commands include an alpha identifier data object. This is intended to be a short one or two
word identifier for the ME to optionally display on screen along with any other indications, at the same time
as the ME performs the SIM command. If longer text statements are required, which must be displayed on
the screen, the SIM shall send a separate display command.
6.6
Structure of proactive SIM commands
BER-TLV data
object
T
L
SIMPLE-TLV
data object
V
T
L
1..n SIMPLE-TLV objects
V
1..m elements
T
L
V
Elements within
the data object
Proactive SIM commands are sent across the interface as BER-TLV data objects. The tag is a constant
value, length one byte, indicating it is a proactive SIM command.
The length is coded onto 1,or 2 bytes according to ISO 7816-6. The following table details this coding:
Length
0-127
128-255
Byte 1
length ("00" to "7F")
"81"
Byte 2
not present
length ("80" to "FF")
Any length within the APDU limits (up to 255 bytes) can thus be encoded on two bytes. This coding is
chosen to remain compatible with ISO/IEC 7816-6 [17].
Any values for byte 1 or byte 2 that are not shown above shall be treated as an error and the whole
message shall be rejected.
The value part of the BER-TLV data object consists of SIMPLE-TLV data objects, as shown in the
sections below on individual commands. It is mandatory for SIMPLE-TLV data objects to be provided in
the order given in this section for each command, but they do not necessarily need to be consecutive.
(i.e., in the future, new SIMPLE-TLV data objects can be added to the middle of a command). The coding
of SIMPLE-TLV data objects are specified later in this document.
The M/O columns specifie whether it is mandatory or optional for the sender to send that particular
SIMPLE-TLV data object for compliance with the current version of this TS. The Min (Minimum Set) column
describes whether it is necessary for the receiver to have received that particular SIMPLE-TLV data object
to be able to attempt at least the most basic form of this command. The procedure for dealing with
incomplete messages is described in section 6.9.
"00" and "FF" are never used as tag values for BER-TLVs. Before, between or after BER-TLV data
objects, "00" and "FF" bytes without any meaning may occur (i.e. padding characters). This is in
accordance with ISO/IEC 7816-6 [17]. The ME shall ignore them.
See ISO/IEC 7816-6 [17] for more information on data objects.
Page 25
6.6.1
DISPLAY TEXT
Description
Section
M/O
Min
Length
12.2
M
Y
1
Length (A+B+C)
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Text string
11.15
M
Y
C
Section
M/O
Min
Length
12.2
M
Y
1
Length (A+B+C)
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Text string
11.15
M
Y
C
Proactive SIM command Tag
6.6.2
GET INKEY
Description
Text string
Contents: text for the ME to display in conjunction with asking the user to respond.
6.6.3
GET INPUT
Description
Section
M/O
Min
Length
12.2
M
Y
1
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Text string
11.15
M
Y
C
Response length
11.11
M
Y
D
Length (A+B+C+D)
Text string
Contents: text for the ME to display in conjunction with asking the user to respond.
Response length
Contents: the minimum and maximum acceptable lengths for the response from the user.
6.6.4
MORE TIME
Description
Section
M/O
Min
Length
12.2
M
Y
1
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Length (A+B)
Page 26
6.6.5
PLAY TONE
Description
Section
M/O
Min
Length
12.2
M
Y
1
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Alpha identifier
11.2
O
N
C
Tone
11.16
O
N
D
Duration
11.8
O
N
E
Length (A+B+C+D+E)
Tone
Contents: the standard supervisory tone or proprietary ME tone that the ME shall generate, either on its
own or on top of the downlink audio path. If no tone is specified, then the ME shall default to
"general beep".
NOTE:
Some supervisory tones are optional for mobile equipment (see GSM 02.40 [18]).
Duration
Contents: the length of time for which the ME shall generate the tone, if the tone is continuous or
repeatable. For single tones, the value of this data object shall be ignored by the ME. If no duration
is specified, the ME shall default to a duration determined by the ME manufacturer.
6.6.6
POLL INTERVAL
Description
Section
M/O
Min
Length
12.2
M
Y
1
Length (A+B+C)
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Duration
11.8
M
Y
C
Duration
Contents: the maximum interval between two STATUS commands while in idle mode.
6.6.7
SET-UP MENU
Description
Section
M/O
Min
Length
12.2
M
Y
1
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Alpha identifier
11.2
M
Y
C
Item data object for item 1
11.9
M
Y
D1
11.9
O
N
D2
......
11.9
O
N
Dx
Item data object for last item in list
11.9
O
N
Dn
Length (A+B+C+D1+D2+...Dn)
The SET-UP MENU command BER-TLV data object shall contain Item SIMPLE-TLV data objects. Each
Item data object contains an item in the list, for the user to choose. The length of each Item data object
may be different. Within a list, each Item shall have a unique item identifier.
Page 27
6.6.8
SELECT ITEM
Description
Section
M/O
Min
Length
12.2
M
Y
1
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Alpha identifier
11.2
O
N
C
11.9
M
Y
D1
11.9
O
N
D2
......
11.9
O
N
Dx
Item data object for last item in list
11.9
O
N
Dn
Length (A+B+C+D1+D2+...Dn)
The SELECT ITEM command BER-TLV data object shall contain Item SIMPLE-TLV data objects. Each
Item data object contains an item in the list, for the user to choose. The length of each Item data object
may be different. Within a list, each Item shall have a unique item identifier.
6.6.9
SEND SHORT MESSAGE
Description
Section
M/O
Min
Length
12.2
M
Y
1
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Alpha identifier
11.2
O
N
C
Address
11.1
O
N
D
SMS TPDU (SMS-SUBMIT or SMSCOMMAND)
11.13
M
Y
E
Length (A+B+C+D+E)
The address data object holds the RP_Destination_Address of the Service Centre. If
RP_Destination_Address is transferred, then the ME shall insert the default Service Centre address.
6.6.10
SEND SS
Description
Section
M/O
Min
Length
12.2
M
Y
1
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Alpha identifier
11.2
O
N
C
SS string
11.4
M
Y
D
Length (A+B+C+D)
6.6.11
Reserved for SEND USSD
no
Page 28
6.6.12
SET UP CALL
Description
Section
M/O
Min
Length
12.2
M
Y
1
Length (A+B+C+D+E+F+G)
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Alpha identifier
11.2
O
N
C
Address
11.1
M
Y
D
11.4
O
N
E
Called party subaddress
11.3
O
N
F
Duration
11.8
O
N
G
If the capability configuration parameters are not present, the ME shall assume the call is a speech call.
If the called party subaddress is not present, the ME shall not provide a called party subaddress to the
network.
If the duration is not present, the SIM imposes no restrictions on the ME of the maximum duration of
redials.
6.6.13
REFRESH
Description
Section
M/O
Min
Length
12.2
M
Y
1
Length (A+B+C)
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
File List
11.18
O
N
C
Section
M/O
Min
Length
12.2
M
Y
1
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device identities
11.7
M
Y
B
Section
M/O
Min
Length
12.2
M
Y
1
-
M
Y
1 or 2
Command details
11.6
M
Y
A
Device Identities
11.7
M
Y
B
6.6.14
POLLING OFF
Description
Length (A+B)
6.6.15
Description
Length (A+B)
Page 29
6.7
Command results
Once the ME has made its attempt to execute a proactive command from the SIM, the ME shall inform the
SIM of the success or otherwise of that command, by using TERMINAL RESPONSE. This message gives
the command details, including the number of the command (see section 6.5.1), a general result, and
sometimes more specific information.
Three overall categories of results are defined:
-
Command performed successfully. This is returned by the ME for every successful command;
-
Temporary problem with executing command. This is further defined below, but generally these
indicate to the SIM that it is worth trying again later;
-
Permanent problem with executing command. These are further defined below, but generally
indicate that the same command will end in the same result if repeated during the same GSM
session.
Successful commands are further defined as:
-
Command performed successfully. There were no problems;
-
Command performed with partial comprehension. Here the ME receives a command with one or
more SIMPLE-TLV data objects that are unrecognized or unexpected, all of which do not have their
"comprehension required" flag set (section 12.3), but the parent BER-TLV data object still has the
minimum set of SIMPLE-TLV data objects required to perform the command;
-
Command performed, with missing information. The ME received at least the minimum set of
component parts, but did not receive all of the parts that it believed mandatory for the SIM to send.
Temporary problems are further defined as:
-
ME is currently unable to process the command. Specific causes for this are:
the screen is busy;
ME currently busy on a call;
ME currently busy on SS transaction;
no service is currently available;
access control class barred on serving network;
no radio resource currently available;
not in speech call.
If none of these can be made to apply, a "no cause can be given" value can be used.
-
Network is currently unable to process the command. Specific cause values are the cause values
given by the network, as defined in GSM 04.08 [8].
-
The user did not accept the call set-up request. This is where the ME alerts the user before setting
up a call, and the user either rejected or did not accept the "call".
-
The user cleared down the call, before the call connected (CONNECT received from network, as
defined in GSM 04.08 [8]) or before the network released the call.
Permanent problems are further defined as:
-
Command is beyond ME's capabilities. This is sent by the ME when it understands what the SIM is
asking it to do, but does not have the capability to do it, e.g. ME which only supports SMS asked to
set up a call.
-
Command type not understood by ME. This is sent by the ME when the SIM sends a command with
the Type of Command byte set to a value the ME does not know. This is to allow future expansion
of commands.
Page 30
-
Command data not understood by ME. This is sent by the ME when the command type is
understood by the ME, but the related data object(s) are not, e.g. reserved values have been
included in a data object, or one or more unknown SIMPLE-TLV data objects have a
"comprehension required" tag.
-
SS Return Error. This is given to the SIM when the network returns a SS error in response to a
previous SS command. Specific cause values are the same as given by the network in the Return
Error message.
-
SMS RP-ERROR. This is given to the SIM when the network returns an error in response to the ME
trying to send a short message. Specific cause values are the same as the cause value of
RP-Cause in an RP-ERROR message.
-
Error, required values are missing. This is given when the command type is understood by the ME,
but it does not receive the minimum set of SIMPLE-TLV data objects that it requires to perform the
command. These components are shown by the "Min" column in the command structure definitions.
6.8
Structure of TERMINAL RESPONSE
The command header is specified in GSM 11.11 [14]. Length (A+B+C+D+E+F+G) is indicated by P3 of
the header.
Description
Section
M/O
Min
Length
Command details
11.6
M
Y
A
Device identities
11.7
M
N
B
Result
11.12
M
Y
C
Duration (only required in response to a
POLL INTERVAL proactive command)
Text string (only required in response to
a GET INKEY or GET INPUT proactive
command)
Item identifier (only required in response
to SELECT ITEM proactive command)
Local information (only required in
response to PROVIDE LOCAL
INFORMATION proactive command)
11.8
M/O
Y/N
D
11.15
M/O
Y/N
E
11.10
M/O
Y/N
F
11.19
/11.20
M/O
Y/N
G
-
Command details: this data object shall be identical to the command details data object given by the
SIM in the proactive command to which the ME is giving the result.
-
Device identities: the ME shall set the device identities to:
Source:
ME
Destination:
SIM
-
Result: This data object holds the result of the proactive SIM command. . If the receiving SIM does
not know the meaning of a value in the result, it shall assume that the command has failed.
-
Duration: When the ME issues a successful TERMINAL RESPONSE for a POLL INTERVAL
command, it shall state the polling interval it will be using in the Duration data object. All other types
of TERMINAL RESPONSE do not need to include Duration. If one is included by the ME, the SIM
shall ignore it.
Page 31
-
Text string: When the ME issues a successful TERMINAL RESPONSE for a GET INKEY or GET
INPUT command, it shall supply the single character or the character string entered by the user in
the Text string data object, no matter what type of string was entered. All other types of TERMINAL
RESPONSE do not need to include Text string. If one is included by the ME, the SIM shall ignore it.
-
Item identifier: When the ME issues a successful TERMINAL RESPONSE for a SELECT ITEM
command, it shall supply the identifier of the item selected by the user in the Item identifier data
object. All other types of TERMINAL RESPONSE do not need to include Item identifier. If one is
included by the ME, the SIM shall ignore it.
-
Local information. When the ME issues a successful TERMINAL RESPONSE for a PROVIDE
LOCAL INFORMATION command, it shall supply the requested local information.
-
Where the SIM has requested location information, TERMINAL RESPONSE shall contain the
location information data object. All other types of TERMINAL RESPONSE do not need to
include location information. If one is included by the ME, the SIM shall ignore it.
-
Where the SIM has requested the IMEI, TERMINAL RESPONSE shall contain the IMEI data
object. All other types of TERMINAL RESPONSE do not need to include IMEI information. If
one is included by the ME, the SIM shall ignore it.
Under no circumstances shall the SIM wait indefinitely for a terminal response.
Any future additional SIMPLE-TLV objects shall be included as Min = N and comprehension not
required. This will ensure that any proactive command will end in a predictable way.
Response parameters/data: None.
6.9
6.9.1
Handling of unknown, unforeseen and erroneous messages
General
The procedures described in this section apply to the BER-TLV and SIMPLE-TLV data objects described
in this TS. The purpose of this section is to allow greater flexibility in future versions of this document, and
a greater predictability across different versions of this standard.
The procedures described here specify how the ME and SIM shall behave when they receive a proactive
command or response that is not fully compliant with the standards by which it was designed. A response
will be made to the SIM by means of the "general result" field of the "result"
If the ME sends a TERMINAL RESPONSE to the SIM that contains values that the SIM does not
understand, then the SIM shall issue the appropriate SW1 / SW2 error response. The current proactive
transaction shall be considered complete and neither the ME or the SIM shall take no further action with
regard to it. In this case, unless the "General result" is "command performed..." then the SIM shall assume
that the command was not carried out and that a permanent error exists with regard to that particular
proactive command. If the command was performed, but the "additional information on result" field was not
understood, then the SIM may attempt the command again at a later stage in the current GSM session.
If the SIM has enough information to proceed (i.e. it has received all the data objects of the Minimum set)
then it shall do so.
6.9.2
Message too short
Any information received that is not a complete tag and length shall be ignored.
6.9.3
Missing minimum information
If a message is received that does not have all the mandatory elements in it, then if all of the minimum set
elements are present then the receiver shall complete the command and report "command performed, with
missing information".
Page 32
If the minimum set of elements is not complete, then the ME shall respond with "Error, required values are
missing".
6.9.4
Unknown Tag value
If a BER-TLV object is received that has a tag that is understood, but contains SIMPLE-TLV components
that have unknown tags, then provided the minimum set condition is fulfilled, the "comprehension required"
bit of the tag shall determine how the receiving entity behaves.
If the comprehension required flag in an unknown tag is set to "1", and the ME either does not recognize
or is not expecting one or more of the SIMPLE-TLV objects in the message, then it shall respond with
"Error, command data not understood by ME".
If the comprehension required flag is set to "0", then the ME shall read the length field that follows and
ignore that object. In this case the ME will be able to carry out the command without the SIMPLE-TLV
components that it cannot understand. It shall respond with "command performed, with missing
information".
6.9.5
Unexpected Tag value
If a BER-TLV object is received that contains elements that have recognisable tags, but which where not
expected in the context of this message (for example, the ME sees SMS TDPU tag as part of TEXT FOR
DISPLAY), then is shall discard that element. It shall then proceed as described for Unknown Tag values.
If a received object has a tag that has already been received, then the first instance shall be used and any
subsequent instances shall be discarded.
6.9.6
Length errors
If the total lengths of the SIMPLE-TLV data objects are not consistent with the length given in the BERTLV data object, then the whole BER-TLV data object shall be rejected. The result field in the TERMINAL
RESPONSE shall have the error condition "ME unable to process command".
6.9.7
Contents not understood
If the contents of a SIMPLE-TLV data object contains a field with a value that is defined as reserved, then
the whole SIMPLE-TLV data object shall be considered as invalid. It will then depend on the
"comprehension required" bit of the relevant tag as to whether the whole BER-TLV data object shall be
rejected, or whether that particular SIMPLE-TLV data object shall be ignored.
If the contents of a BER-TLV object contains "Spare" bits, then these shall be ignored.
6.9.8
Extended length data objects
If a SIMPLE-TLV data object has a length longer than expected (i.e. more information has been added),
then the receiver shall ignore this extra information to the end of the object. The end of the object shall be
found by looking at the "length" field of that object.
NOTE:
If comprehension of the extra bytes is required, this can be achieved by the use of a
reserved coding in an earlier field.
Page 33
7
7.1
7.1.1
Data download to SIM
SMS-PP data download
Procedure
If the service "data download via SMS Point-to-point" is allocated and activated in the SIM Service Table
(see GSM 11.11 [14]), then the ME shall follow the procedure below:
-
When the ME receives a Short Message with:
protocol identifier = SIM data download, and
data coding scheme = class 2 message,
then the ME shall pass the message transparently to the SIM using the ENVELOPE (SMS-PP
DOWNLOAD) command as defined below.
-
The ME shall not display the message, or alert the user of a short message waiting.
-
The ME shall wait for an acknowledgement from the SIM. The SIM shall respond with SW1 / SW2 =
"90 00", "91 XX" or "9F XX".
-
If the SIM responds with "90 00" or "91 XX", the ME shall acknowledge the receipt of the short
message to the network.
-
If the SIM responds with "9F XX", the ME shall use the GET RESPONSE command to get the
response data. The response data from the SIM will be appended by the ME to the RP-ACK
message it will send back to the network (see GSM 04.11[9]). The response data will be limited to
16 bytes.
If the service "data download via SMS-PP" is not allocated and activated in the SIM Service Table, and the
ME receives a Short Message with the protocol identifier = SIM data download and data coding scheme =
class 2 message, then the ME shall store the message in EFSMS in accordance with GSM 11.11 [14].
NOTE:
7.1.2
MEs not supporting SIM Application Toolkit are likely to store data download
messages in EFSMS, as if they were normal short messages.
Structure of ENVELOPE (SMS-PP DOWNLOAD)
Description
Section
M/O
Min
Length
12.1
M
Y
1
Length (A+B+C)
-
M
Y
1 or 2
Device identities
11.7
M
Y
A
Address
11.1
O
N
B
SMS TPDU (SMS-DELIVER)
11.13
M
Y
C
SMS-PP download tag
-
-
Source:
Network
Destination:
SIM
Address: The address data object holds the RP_Originating_Address of the Service Centre
(TS-Service-Centre-Address), as defined in GSM 04.11 [9].
Response parameters/data: None for this type of ENVELOPE command.
Page 34
7.2
7.2.1
Cell Broadcast data download
Procedure
If the service "data download via SMS-CB" is allocated and activated in the SIM Service Table (see
GSM 11.11 [14]), then the ME shall follow the procedure below:
-
When the ME receives a new Cell Broadcast message, the ME shall compare the message
identifier of the Cell Broadcast message with the message identifiers contained in EF CBMID.
-
If the message identifier is found in EFCBMID, the cell broadcast page is passed transparently to the
SIM using the ENVELOPE (CELL BROADCAST DOWNLOAD) command, as defined below. The
ME shall not display the message.
-
If the message identifier of the incoming cell broadcast message is not found in EFCBMID, then the
ME shall determine if the message should be displayed, by following the procedures in
GSM 03.41 [7] and GSM 11.11 [14].
The ME shall identify new cell broadcast pages by their message identifier, serial number and page values.
7.2.2
Structure of ENVELOPE (CELL BROADCAST DOWNLOAD)
Description
Section
M/O
Min
Length
12.1
M
Y
1
-
M
Y
1 or 2
Device identities
11.7
M
Y
A
Cell Broadcast page
11.5
M
Y
B
Cell Broadcast Download tag
Length (A+B)
-
Source:
Network
Destination:
SIM
Response parameters/data: None for this type of ENVELOPE command.
8
Menu Selection
A set of possible menu options can be supplied by the SIM using the proactive command SET UP MENU.
If the SIM has sent this command, and the user subsequently chooses an option, the ME informs the SIM
using this procedure.
8.1
Procedure
If the service "menu selection" is allocated and activated in the SIM Service Table (see TS
GSM 11.11 [14]), then the ME shall follow the procedure below.
-
When the ME receives a menu selection from one of the menu items defined by a "SET-UP MENU"
command issued previously by the SIM it shall pass the identifier of the selected menu item to the
SIM using the ENVELOPE( MENU SELECTION) command, as defined below.
Page 35
8.2
Structure
The command header is specified in TS GSM 11.11 [14].
Description
Section
M/O
Min
Length
12.1
M
Y
1
-
M
Y
1 or 2
Device identities
11.7
M
Y
A
Item identifier
11.10
M
Y
B
Menu Selection tag
Length (A+B)
-
9
9.1
Source:
Keypad
Destination:
SIM
Call Control by SIM
Procedure for mobile originated calls
If the service "call control" is allocated and activated in the SIM Service Table (see GSM 11.11 [14]), then
the ME shall follow the procedure below:
-
For all call set-up attempts, the ME shall first pass the dialled digits and associated parameters to
the SIM, using the ENVELOPE (CALL CONTROL) command defined below. The only exception is
for redial attempts which are managed by the ME and only require the call set-up details to be
passed to the SIM for the first attempt.
-
The SIM shall respond with SW1 / SW2 = "90 00" or "9F XX".
-
If the SIM responds with "90 00", the ME shall set up the call with the dialled digits and other
parameters as sent to the SIM.
-
response data. The response data from the SIM shall indicate to the ME whether to set up the call
as proposed, not set up the call, or instead set up a call using the data supplied by the SIM. It is
mandatory for the ME to perform the call set-up request in accordance with the data from the SIM.
Optionally, the ME may indicate to the user that the call has been barred or changed.
The ME shall then follow the call set-up procedure defined in GSM 04.08 [8].
9.2
Procedure for Supplementary Services
If the service "call control" is allocated and activated in the SIM Service Table (see GSM 11.11 [14]), then
for all supplementary service operations, the ME shall first pass the supplementary service control string
(corresponding to the supplementary service operation and coded as defined in GSM 02.30 [4], even if this
SS operation has been performed via a specific menu of the ME) to the SIM, using the ENVELOPE (CALL
CONTROL) command defined below.
The SIM shall respond in the same way as for dialled digits. The ME shall interpret the response as
follows:
-
If the SIM responds with "90 00", the ME shall send the supplementary service operation with the
information as sent to the SIM.
Page 36
-
response data. The response data from the SIM shall indicate to the ME whether to send the
supplementary service operation as proposed, not send the SS operation, or instead send the SS
operation using the data supplied by the SIM. It is mandatory for the ME to send the supplementary
service operation in accordance with the data from the SIM.
Optionally, the ME may indicate to the user that the supplementary service operation has been barred or
changed.
The ME shall then follow the supplementary service operation procedure defined in GSM 04.80 [10].
9.3
Interaction with Fixed Dialling Number
It is permissible for the Fixed Dialling Number service to be enabled (see GSM 11.11 [14]) at the same
time as Call Control is allocated and activated in the SIM Service Table.
If FDN is enabled and Call Control is activated, the ME shall follow this procedure:
-
The ME shall check that the number entered through the MMI is on the FDN list, in accordance with
GSM 02.07 [19].
-
If the MMI input does not pass the FDN check, the call shall not be set up.
-
If the MMI input does pass the FDN check, the ME shall pass the dialled digits and other
parameters to the SIM, using the ENVELOPE (CALL CONTROL) command.
-
If the SIM responds with "allowed, no modification", the ME shall set up the call as proposed.
-
If the SIM responds with "not allowed", the ME shall not set up the call.
-
If the SIM responds with "allowed with modifications", the ME shall set up the call in accordance
with the response from the SIM. If the modifications involve changing the dialled digits, the ME shall
not re-check this modified number against the FDN list.
If the user wishes to enable or disable Fixed Dialling Number, the ME shall follow the procedure in
GSM 11.11 [14]. The state of the Call Control service shall have no effect on this procedure.
9.4
Support of Barred Dialling Number (BDN) service
The BDN service shall be allocated and activated in the SIM Service Table only if Call Control is also
allocated and activated in the SIM Service Table.
If Barred Dialling Number service is enabled (see GSM 11.11 [14]), when receiving the dialled number (or
supplementary service control string) and other parameters from the ME, the SIM may check this
information against those stored in EFBDN (examples of comparison methods are given in
GSM 02.07 [19]).
-
If the SIM responds with "not allowed" (e.g., a match is made against a BDN), the ME shall not set
up the call (or the supplementary service operation).
-
If the SIM responds with "allowed, no modification", the ME shall set up the call (or the
supplementary service operation) as proposed.
-
If the SIM responds with "allowed with modifications", the ME shall set up the call (or the
supplementary service operation) in accordance with the response from the SIM. If the modifications
involve changing the dialled number (or the supplementary service control string), the ME shall not
re-check this modified number (or string) against the FDN list when FDN is enabled.
If the user wishes to enable or disable Barred Dialling Number, the ME shall follow the procedure in
GSM 11.11 [14].
Page 37
9.5
Structure of ENVELOPE (CALL CONTROL)
Description
Section
M/O
Min
Length
12.1
M
Y
1
-
M
Y
1 or 2
Device identities
11.7
M
Y
A
Address
or
SS string
Address
11.1
or
11.14
11.1
M
Y
B
M
Y
B
11.4
O
N
C
11.3
O
N
D
Call control tag
Length (A+B+C+D)
-
Source:
ME
Destination:
SIM
-
Address or SS string : only one data object shall be sent to the SIM.
For a call set-up, the address data object is used and holds the Called Party Number, as defined in
GSM 04.08 [8], to which the ME is proposing setting up the call.
For a supplementary service operation, the SS string data object is used and holds the
corresponding supplementary service control string.
-
Capability configuration parameters: Only used for a call set-up, this contains the Bearer capabilities
that the ME is proposing to send to the network. If this data object is not present, this shall indicate
a speech call.
-
Called party subaddress: Only used for a call set-up, this contains the called party subaddress that
the ME is proposing to send to the network. If one is not present, this shall indicate that the ME is
proposing not to send this information element to the network.
It is permissible for the SIM to provide no response data, by responding with SW1 / SW2 = "90 00". If the
SIM does not provide any response data, then this shall have the same meaning as "allowed, no
modification".
Description
Section
M/O
Min
Length
Call control result
-
M
Y
1
Length (A+B+C)
-
M
Y
1 or 2
Address
or
SS string
Address
11.1
or
11.14
11.1
O
N
A
O
N
A
11.4
O
N
B
11.3
O
N
C
Page 38
Call control result:
Contents: the command that the SIM gives to the ME concerning whether to allow, bar or modify the
proposed call (or supplementary service operation).
Coding:
"00" = Allowed, no modification
"01" = Not allowed
"02" = Allowed with modifications
-
Address or SS string : Only one data object may be included if the SIM requests the call (or
supplementary service operation) details to be modified.
For a call set-up, if the address data object is not present, then the ME shall assume the Dialling
number is not to be modified.
For a supplementary service operation, if the SS string data object is not present, then the ME shall
assume that SS operation is not to be modified.
-
Capability configuration parameters: Only used for a call set-up, this data object is only required if
the SIM requests the call details to be modified. If the capability configuration parameters are not
present, then the ME shall assume the parameters are not to be modified.
-
Called party subaddress: Only used for a call set-up, this data object is only required if the SIM
requests the call details to be modified. If the called party subaddress is not present, then the ME
shall assume the subaddress is not to be modified. If the subaddress supplied by the SIM is a null
data object, then the ME shall not provide a called party subaddress to the network. A null data
object shall have length = "00" and no value part.
It is mandatory for the SIM to provide at least one of the optional data objects if it has set the Call control
result to "allowed with modifications".
10
Security requirements
To be defined.
11
SIMPLE-TLV data objects
This section specifies the coding of the SIMPLE-TLV data objects, which are contained in a BER-TLV data
object. SIMPLE-TLV data objects may be transferred across the interface in either direction. A
SIMPLE-TLV data object consists of a tag of length one byte, a length indicator, which gives the number of
bytes in the value field, and a value part of variable length, whose contents, meaning and coding are given
below.
Tag codings are given in section 12.3 for all SIMPLE-TLV data objects.
"00" and "FF" are never used as tag values for SIMPLE-TLVs. Before, between or after SIMPLE-TLV data
objects, "00" and "FF" bytes without any meaning may occur (i.e. padding characters). The receiving entity
shall ignore them. This is in alignment with ISO 7816-4 [17].
11.1
Address
Byte(s)
Description
Length
1
Address tag
1
2
Length (x)
1
3
TON and NPI
1
4 - x+2
Dialling number string
x-1
TON/NPI is coded as for EFADN.
Dialling number string is coded as for EFADN, and may include DTMF separators and DTMF digits, which
the ME shall send in the same way as for EFADN.
Page 39
See GSM 11.11 [14] for the coding of all EFs.
11.2
Alpha identifier
Byte(s)
Description
Length
1
Alpha identifier tag
1
2
Length (X)
1
Alpha identifier of X characters
X
3 - X+2
The alpha identifier is coded as for EFADN.
11.3
Byte(s)
Description
Length
1
Called party subaddress tag
1
2
Length (x)
1
X
3 - x+2
Called party subaddress contains information as defined for this purpose in GSM 04.08 [8]. All information
defined in GSM 04.08 shall be given in the value part of the data object, except the information element
identifier and the length of called party subaddress contents (which is given by the length part of the data
object).
11.4
Byte(s)
Description
Length
1
Capability configuration parameters tag
1
2
Length (X)
1
X
3 - X+2
Capability configuration parameters are coded as for EFCCP. If it is being provided by the SIM, the SIM
shall supply all information required to complete the Bearer Capability Information Element in the Call Setup message (see GSM 04.08 [8]). Any unused bytes at the end of the value part shall be coded "FF".
11.5
Cell Broadcast Page
Byte(s)
Description
Length
1
Cell Broadcast page tag
1
2
Length = "58" (88 decimal)
1
Cell Broadcast page
88
3 - 90
The Cell Broadcast page is formatted in the same way as described in GSM 03.41 [7].
Page 40
11.6
Command details
Byte(s)
Description
Length
1
Command details tag
1
2
Length = "03"
1
3
Command number
1
4
Type of command
1
5
Command Qualifier
1
Command number
For contents and coding, see section 6.5.1.
Type of command:
Contents: The Type of Command specifies the required interpretation of the data objects which follow, and
the required ME procedure.
Coding:
-
"01" = REFRESH;
"02" = MORE TIME;
"03" = POLL INTERVAL;
"04" = POLLING OFF;
-
"10" =SET UP CALL,
"11" = SEND SS;
"12" = Reserved for SEND USSD;
"13" = SEND SHORT MESSAGE,
-
"20" = PLAY TONE;
"21" = DISPLAY TEXT,
"22" = GET INKEY,
"23" = GET INPUT,
"24" = SELECT ITEM,
"25" = SET UP MENU.
"26" = PROVIDE LOCAL INFORMATION
"27" to "FF" are reserved values
The ME shall respond to reserved values with the result “Command type not understood”.
Command Qualifier:
Contents: Qualifiers specific to the command.
Coding:
REFRESH;
"00" =SIM Initialization and Full File Change Notification;
"01" = File Change Notification;
"02" = SIM Initialization and File Change Notification;
"03" = SIM Initialization;
"04" = SIM Reset.
-
MORE TIME;
The byte shall be set to "00".
-
POLL INTERVAL;
-
POLLING OFF;
Page 41
-
SET UP CALL,
"00" = set up call, but only if not currently busy on another call;
"01" = set up call, but only if not currently busy on another call, with redial;
"02" = set up call, putting all other calls (if any) on hold ;
"03" = set up call, putting all other calls (if any) on hold, with redial;
"04" = set up call, disconnecting all other calls (if any);
"05" = set up call, disconnecting all other calls (if any), with redial;
"06" to "FF" = Reserved;
-
SEND SS;
-
Reserved for SEND USSD;
-
SEND SHORT MESSAGE,
bit 1:
0 = packing not required
1 = SMS packing by the ME required
bits 2-7
= 0 (Reserved);
-
PLAY TONE;
-
DISPLAY TEXT,
bits 1-8:
87654321
xxxxx000 - normal priority
xxxxx001 - high priority
0xxxx00x - clear message after a delay
1xxxx00x - wait for user to clear message
All other conditions are RFU
-
GET INKEY,
bit 1
bits 2-7
-
0 = digits (0-9, *, # and +) only
1 = SMS default alphabet;
= 0 (Reserved)
GET INPUT,
bit 1
0 = digits (0-9, *, #, and +) only
1 = SMS default alphabet;
bit 2
= 0 (Reserved)
bit 3
0 = ME may echo user input on the display
1 = user input shall not be revealed in any way (see note)
bit 4
0 = user input to be in unpacked format
1 = user input to be in SMS packed format
bits 5 to 8 = 0 (Reserved)
-
SELECT ITEM.
-
SET UP MENU.
-
"00" = Location Information (MCC, MNC, LAC and Cell Identity)
"01" = IMEI of the ME
"02" to "FF" = Reserved
NOTE:
Where user input is not to be revealed, the ME may provide an indication of key
entries, such as by displaying "*"s.
The ME shall respond to reserved values with the result "Command type not understood".
Page 42
11.7
Device identities
Byte(s)
Description
Length
1
Device identities tag
1
2
Length = "02"
1
3
Source device identity
1
4
Destination device identity
1
Source device identity
Contents: the source device for information held in the data objects which follow.
Destination device identity
Contents: the destination device for information held in the data objects which follow.
NOTE:
Only some combinations of Type of Command, Data Download type and Device
identities are allowed. These are defined later in section 13.
Coding: both Source and Destination device identities are coded as follows:
"01" = Keypad
"02" = Display
"03" = Earpiece
"81" = SIM
"82" = ME
"83" = Network
All other values are reserved.
11.8
Duration
Byte(s)
Description
Length
1
Duration tag
1
2
Length = "02"
1
3
Time unit
1
4
Time interval
1
Time unit
Contents: time unit used; minutes, seconds or tenths of seconds.
Coding:
"00" Minutes
"01" Seconds
"02" Tenths of seconds
Time interval
Contents: the length of time required, expressed in units.
Coding: The time interval is coded in integer multiples of the time unit used. The range is from 1 unit to
255 units. The encoding is:
-
"00": reserved
"01": 1 unit
"02": 2 units
:
:
"FF": 255 units
Page 43
11.9
Item
Byte(s)
Description
Length
1
Item tag
1
2
Length (X)
1
3
Identifier of item
1
4 - X+2
Text string of item
X-1
The identifier is a single byte between "01" and "FF". Each item must have a unique identifier within an Item
list.
The text string is coded using the SMS default alphabet padded to 8 bits per character, in the same way
as the alpha identifier for EFADN. Any unused bytes at the end of the value part shall be coded "FF".
11.10
Item identifier
Byte(s)
Description
Length
1
Item identifier tag
1
2
Length = "01"
1
3
Identifier of item chosen
1
The identifier is a single byte between "01" and "FF", exactly the same as for the Item data object. A null
item identifier is coded "00".
11.11
Response length
Byte(s)
Description
Length
1
Response length tag
1
2
Length = "02"
1
3
Minimum length of response
1
4
Maximum length of response
X-1
The range of length is between "00" and "FF". A minimum length coding of "00" indicates that there is no
minimum length requirement; a maximum length coding of "FF" indicates that there is no maximum length
requirement. If a fixed length is required the minimum and maximum values are identical.
11.12
Result
Byte(s)
Description
Length
1
Result tag
1
2
Length (X)
1
3
General result
1
4 - X+2
Additional information on result
General result
Contents: General result specifies the result and indicates appropriate SIM action:
Coding:
"00" = Command performed successfully;
"01" = Command performed with partial comprehension;
"02" = Command performed, with missing information;
X-1
Page 44
-
"20" = ME currently unable to process command;
"21" = Network currently unable to process command;
"22" = User did not accept call set-up request;
"23" = User cleared down call before connection or network release;
-
"30" = Command beyond ME's capabilities;
"31" = Command type not understood by ME;
"32" = Command data not understood by ME;
"33" = Command number not known by ME;
"34" = SS Return Error;
"35" = SMS RP-ERROR;
"36" = Error, required values are missing.
All other values are reserved and shall be treated by the SIM as "20".
NOTE:
General results "0X" and "1X" indicate that the command has been performed. Results
"2X" indicate to the SIM that it may be worth re-trying the command at a later
opportunity. Results "3X" indicate that it is not worth the SIM re-trying with an identical
command, as it will only get the same response. However, the decision to retry lies
with the SIM application.
Contents: For the general result "Command performed successfully", some proactive commands require
additional information in the command result. This is defined in the sections below. For the general
results "20", "21", "34" and "35", it is mandatory for the ME to provide a specific cause value as
additional information, as defined in the sections below. For the other general results, the ME may
optionally supply additional information. If additional information is not supplied, then the length of the
value part of the data object need only contain the general result.
11.12.1
Additional information for SEND SS
When the ME issues a successful COMMAND RESULT for a SEND SS proactive command, it shall also
include the Operation Code and Parameters included in the Return Result component from the network, as
additional information.
The first byte of the additional information shall be the SS Return Result Operation code, as defined in
GSM 04.11 [9].
The rest of the additional information shall be the SS Return Result Parameters, as defined in
GSM 04.11 [9].
11.12.2
Additional information for ME problem
For the general result "ME currently unable to process command", it is mandatory for the ME to provide
additional information, the first byte of which to be as defined below:
-
"00" = No specific cause can be given;
"01" = Screen is busy;
"02" = ME currently busy on call;
"03" = ME currently busy on SS transaction;
"04" = No service;
"05" = Access control class bar;
"06" = Radio resource not granted;
"07" = Not in speech call.
All other values shall be interpreted by the SIM as "00".
NOTE:
The coding "00" shall only be used by the ME if no others apply.
Page 45
11.12.3
Additional information for network problem
For the general result "network currently unable to process command", it is mandatory for the ME to
provide additional information. The first byte shall be the cause value of the Cause information element
returned by the network (as defined in GSM 04.08 [8]). Bit 8 shall be set to "1". One further value is
defined:
-
"00" = No specific cause can be given.
NOTE:
11.12.4
Additional information for SS problem
For the general result "SS Return Error", it is mandatory for the ME to provide additional information. The
first byte shall be the error value given in the Facility (Return result) information element returned by the
network (as defined in GSM 04.80 [10]). One further value is defined:
-
NOTE:
11.12.5
Additional information for SMS problem
For the general result "SMS RP-ERROR", it is mandatory for the ME to provide additional information. The
first byte shall be the cause value given in the RP-Cause element of the RP-ERROR message returned by
the network (as defined in GSM 04.11 [9]), with bit 8 = 0. One further value is defined:
-
NOTE:
11.13
Specific cause "00" shall only be used by the ME if no others apply.
SMS TPDU
Byte(s)
Description
Length
1
SMS TPDU tag
1
2
Length (X)
1
3 - X+2
SMS TPDU
X
The TPDU is formatted as described in GSM 03.40 [6].
Where the TPDU is being sent from the SIM to the ME (to be forwarded to the network), and where it
includes a TP-Message-Reference which is to be incremented by the MS for every outgoing message, the
TP-Message-Reference as provided by the SIM need not be the valid value. TP-Message-Reference shall
be checked and corrected by the ME to the value described in GSM 03.40 [6].
Page 46
11.14
SS string
Byte(s)
Description
Length
1
SS string tag
1
2
Length (X)
1
3
TON and NPI
1
4 - X+2
SS string
X-1
TON/NPI and SS control string are coded as for EFADN, where the ADN record relates to a
Supplementary Service Control string. See GSM 11.11 [14] for the coding of EFADN.
11.15
Text string
Byte(s)
Description
Length
1
Text string tag
1
2
Length (X)
1
3
Data coding scheme
1
4 - X+2
Text string of X-1 characters
X-1
A null text string shall be coded with Length = "00", and no Value part.
Data coding scheme is coded as for SMS Data coding scheme defined in GSM 03.38 [5].
11.15.1
Coding of text in unpacked format
This is indicated by the data coding scheme having a value of 8 bit data. Other parts of the data coding
scheme shall be ignored.
This string shall be no longer than 160 characters, and use the SMS default 7-bit coded alphabet as
defined in GSM 03.38 [5] with bit 8 set to 0. It may or may not include formatting characters, but all such
formatting characters shall be taken from the set given in the SMS alphabet.
NOTE:
11.15.2
This is exactly the same format as is used for EFADN alpha-identifiers. It is also the
same as SMS messages that have been "unpacked".
Coding of text in packed format
This is indicated by the data coding scheme having a value of 7 bit GSM default alphabet. Other parts of
the data coding scheme shall be ignored.
This string shall be no longer than 160 characters, and use the SMS default 7-bit coded alphabet, packed
into 8-bit octets, as defined in GSM 03.38 [5]. It may or may not include formatting characters, but all such
formatting characters shall be taken from the set given in the SMS alphabet.
NOTE:
11.16
This is the same format as is used in SMS messages to and from the network.
Tone
Byte(s)
Description
Length
1
Tone tag
1
2
Length = "01"
1
3
Tone
1
Page 47
Tone
Contents: Tones can be either the standard supervisory tone, as defined in GSM 02.40 [18], or proprietary
tones defined by the ME manufacturer. The code values for proprietary tones shall be supported by
the ME. If proprietary tones are not supported the ME shall map these codings to tones that it can
generate. The tones to be used are left as an implementation decision by the manufacturer.
Coding:
Standard supervisory tones:
"01" Dial tone
"02" Called subscriber busy
"03" Congestion
"04" Radio path acknowledge
"05" Radio path not available / Call dropped
"06" Error / Special information
"07" Call waiting tone
"08" Ringing tone
ME proprietary tones:
"10" General beep
"11" Positive acknowledgement tone
"12" Negative acknowledgement or error tone
11.17
Reserved for USSD string
11.18
File List
Byte(s)
Description
Length
1
File List tag
1
2
Length (X) of bytes following
1
3
Number of files (n)
1
4 to X+2
Files
X-1
Number of files:
This is the number of files that will be described in the following list.
Files:
Full paths are given to files. Each of these must be at least 4 octets in length (e.g. "3F002FE2" or
"3F007F206FAD"). Each entry in the file description is composed of two bytes, where the first byte
identifies the type of file (see GSM 11.11).
An entry in the file description shall therefore always begin with "3FXX". There can be any number of
Dedicated File entries between the Master File and Elementary File. There shall be no delimiters between
files, as this is implied by the fact that the full path to any EF starts with "3FXX" and ends with an
Elementary type file.
Page 48
11.19
LOCATION INFORMATION
Byte(s)
Description
Length
1
Location Information tag
1
2
1
3-5
Mobile Country & Network Codes (MCC & MNC)
3
6-7
Location Area Code (LAC)
2
8-9
Cell Identity Value (Cell ID)
2
The mobile country code (MCC), the mobile network code (MNC), the location area code (LAC) and the
cell ID are coded as in TS GSM 04.08 [8].
11.20
IMEI
Byte(s)
Description
Length
1
IMEI tag
1
2
1
IMEI of the ME
8
3 - 10
The IMEI is coded as in TS GSM 04.08 [8].
12
Tag values
This section specifies the tag values used to identify the BER-TLV and SIMPLE-TLV data objects used in
this specification.
12.1
BER-TLV tags in ME to SIM direction
Description
Length of tag
Value
SMS-PP download tag
1
"D1"
Cell Broadcast download tag
1
"D2"
Menu Selection tag
1
"D3"
Call control tag
1
"D4"
Length of tag
Value
1
"D0"
12.2
BER-TLV tags in SIM TO ME direction
Description
Proactive SIM command tag
12.3
SIMPLE-TLV tags in both directions
8
CR
7
T
6
T
5
T
4
T
3
T
2
T
1
T
CR: Comprehension required for this object. (See section 6.9.4 for a description of the use of the CR flag.)
CR
Value
Comprehension required
1
Comprehension not required
0
Page 49
Description
Length of tag
CR
Command details tag
1
1
Value (T)
("01" - "7E")
"01"
Device identity tag
1
1
"02"
Result tag
1
1
"03"
Duration tag
1
1
"04"
Alpha identifier tag
1
1
"05"
Address tag
1
1
"06"
Capability configuration parameters tag
1
1
"07"
Called party subaddress tag
1
1
"08"
SS string tag
1
1
"09"
Reserved for USSD string tag
1
1
"0A"
SMS TPDU tag
1
1
"0B"
Cell Broadcast page tag
1
1
"0C"
Text string tag
1
1
"0D"
Tone tag
1
1
"0E"
Item tag
1
1
"0F"
Item identifier tag
1
1
"10"
Response length tag
1
1
"11"
Address tag
1
1
"12"
Menu selection tag
1
1
"13"
File List tag
1
1
"14"
Location Information tag
1
1
"15"
IMEI tag
1
1
"16"
Page 50
13
Allowed Type of command and Device identity combinations
Only certain types of commands can be issued with certain device identities. These are defined below:
Command description
CALL CONTROL
CELL BROADCAST DOWNLOAD
COMMAND RESULT
DISPLAY TEXT
GET INKEY
GET INPUT
MENU SELECTION
MORE TIME
PLAY TONE
POLLING OFF
POLL INTERVAL
PROFILE DOWNLOAD
REFRESH
SELECT ITEM
SEND SHORT MESSAGE
SEND SS
SEND USSD
SET UP CALL
SET UP MENU
SMS-PP DOWNLOAD
NOTE:
Source
ME
Network
ME
SIM
SIM
SIM
Keypad
SIM
SIM
SIM
SIM
ME
SIM
SIM
SIM
SIM
SIM
SIM
SIM
Network
Destination
SIM
SIM
SIM
Display
ME
ME
SIM
ME
Earpiece (see note 1)
ME
ME
SIM
ME
ME
Network
Network
Network
Network
ME
SIM
The ME may route the tone to other loudspeakers (external ringer, car kit) if more
appropriate.
Page 51
Mandatory support of SIM Application Toolkit by
Mobile Equipment
Support of SIM Application Toolkit is optional for Mobile Equipment. However, any ME claiming to support
SIM Application Toolkit need not support all toolkit functions, but shall support all functions within a class as
given in the table below:
Classes
Command description
2
3
CALL CONTROL
X
X
CELL BROADCAST DOWNLOAD
X
X
DISPLAY TEXT
X
X
GET INKEY
X
X
GET INPUT
X
X
MENU SELECTION
X
X
MORE TIME
X
X
PLAY TONE
X
X
POLLING OFF
X
X
POLL INTERVAL
X
X
X
X
SELECT ITEM
X
X
SEND SHORT MESSAGE
X
X
SEND SS
X
X
REFRESH
1
X
SEND USSD
X
SET UP CALL
X
X
SET UP MENU
X
X
X
X
X
X
SMS-PP DOWNLOAD
SET UP MENU
X
Page 52
Example command sequences for proactive SIM
This section shows example APDU sequences for proactive SIM commands, and is for information only.
Case 1: Proactive SIM request following a normal command from the ME
0(
6,0
·1RUPDOFRPPDQG·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
·1RUPDO'DWDLIDQ\··OJWK·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
·)(7&+·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
·3URDFWLYH6,0FRPPDQG···
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
[ME performs command]
·7(50,1$/5(63216(2.·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
···
º¶¶¶¶¿¶¶¶¶»
Case 2: Proactive SIM request following a (polling) STATUS command from the ME
0(
6,0
·67$786FRPPDQG·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
·1RUPDO'DWDRQ')··OJWK·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
·)(7&+·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
·7(50,1$/5(63216(2.·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
···
º¶¶¶¶¿¶¶¶¶»
Page 53
Case 3: STATUS command from ME, not followed by any proactive SIM request
0(
6,0
·67$786FRPPDQG·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
·1RUPDO'DWDRQ')···
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
Case 4: Unsuccessful proactive SIM request, followed by SIM asking the ME to retry
0(
6,0
·1RUPDOFRPPDQG·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
·)(7&+·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
·7(50,1$/5(63216(WHPSRUDU\SUREOHP·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
··OJWK·
º¶¶¶¶¿¶¶¶¶»
·)(7&+·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
·5HSHDWRISURDFWLYH6,0FRPPDQG···
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
·7(50,1$/5(63216(2.·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
···
º¶¶¶¶¿¶¶¶¶»
Page 54
Case 5: Unsuccessful proactive SIM request, and the SIM does not ask for the ME to retry
0(
6,0
·1RUPDOFRPPDQG·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
·)(7&+·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¿¶¶¶¶¿¶¶¶¶»
·7(50,1$/5(63216(WHPSRUDU\SUREOHP·
º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
···
º¶¶¶¶¿¶¶¶¶»
Page 55
Example of DISPLAY TEXT Proactive SIM Command
Example of DISPLAY TEXT Proactive SIM Command
(BER-TLV Data Object)
Byte#
1
2
3
4
5
6-7
8
9
10
11
12
13
14 - 17
Value (Hex)
D0
0F
01
03
01
21 00
02
02
81
02
0D
04
Description
Proactive SIM command tag
length
command details tag
length
command number
Display text(normal priority)
Device identity tag
length
source : SIM
destination : Display
Text string tag
length
text string
Page 56
History
Document history
December 1996
Publication of GSM 11.14 version 5.2.0
ISBN 2-7437-1205-8
Dépôt légal : Décembre 1996
ETSI TS 100 512 V7.0.1 (1999-07)
Procedure for call progress indications
R
GLOBAL SYSTEM FOR
2
ETSI TS 100 512 V7.0.1T T(1999-07)
Reference
RTS/SMG-010240Q7 (4qo03i0r.PDF)
Keywords
Digital cellular telecommunications system,
Global System for Mobile communications (GSM)
ETSI
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Internet
[email protected]
Individual copies of this ETSI deliverable
can be downloaded from
http://www.etsi.org
If you find errors in the present document, send your
comment to: [email protected]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1999.
All rights reserved.
ETSI
3
ETSI TS 100 512 V7.0.1T T(1999-07)
Contents
Intellectual Property Rights................................................................................................................................4
Foreword ............................................................................................................................................................4
1
1.1
1.2
1.3
2
2.1
2.2
2.3
2.4
2.5
2.6
3
Scope ........................................................................................................................................................5
References ......................................................................................................................................................... 5
Abbreviations..................................................................................................................................................... 5
General............................................................................................................................................................... 5
Supervisory tones .....................................................................................................................................6
General............................................................................................................................................................... 6
Method............................................................................................................................................................... 6
Standard tones.................................................................................................................................................... 6
Applicability ...................................................................................................................................................... 6
Point of introduction .......................................................................................................................................... 7
Comfort tones .................................................................................................................................................... 7
Recorded announcements.........................................................................................................................8
Application of call control cause information elements to supervisory
tones ..................................................................................................................9
Change history ...............................................................................................10
History ..............................................................................................................................................................11
ETSI
4
ETSI TS 100 512 V7.0.1T T(1999-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be
found in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on
the ETSI Web server (http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server)
which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by the Special Mobile Group (SMG).
The present document defines requirements for call progress and related information to be provided to users of the
GSM system.
The contents of the present document is subject to continuing work within SMG and may change following formal
SMG approval. Should SMG modify the contents of the present document, it will be re-released by SMG with an
identifying change of release date and an increase in version number as follows:
Version 7.x.y
where:
7 indicates GSM Phase 2+ Release 1998;
x the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections,
updates, etc.
y the third digit is incremented when editorial only changes have been incorporated in the specification;
ETSI
1
5
ETSI TS 100 512 V7.0.1T T(1999-07)
Scope
The present document defines requirements for call progress and related information to be provided to users of the
GSM system.
1.1
References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the
same number.
• For this Release 1998 document, references to GSM documents are for Release 1998 versions (version 7.x.y).
[1]
GSM 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and
acronyms".
[2]
GSM 02.30: "Digital cellular telecommunications system (Phase 2+); Man-Machine Interface
(MMI) of the Mobile Station (MS)".
[3]
GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer
3 specification".
[4]
CEPT Recommendation T/CS 20-15: "Tones and announcements".
[5]
CEPT Recommendation T/S F23: "Relative aux définitions et caractéristiques audibles des
tonalités et des annonces parlées".
[6]
ANSI T1.607: “Digital Subscriber Signalling Sytem No.1-Layer 3 Signalling Specification for
Circuit Switched Bearer Service”.
1.2
Abbreviations
Abbreviations used in the present document are listed in GSM 01.04.
1.3
General
There are aspects of the Man Machine Interface (MMI) of the GSM Network which relate to users, but which are not
covered by GSM 02.30, which deals specifically with the MMI of the Mobile Station (MS). The present TS covers the
means by which mobile users, and callers to a GSM network, will be given information regarding progress of their
calls.
Indications of call progress, such as ringing, engaged, unobtainable, and no radio channel, may in principle be verbal
message, tones, displayed text or graphical symbols. Which combination of these applies may depend on the message,
the MS and selection by the user or PLMN operator. However, verbal announcements will generally be reserved for
situations which are peculiar to a mobile network, where users may be unfamiliar with any tone chosen to indicate
conditions such as "call diversion" or "subscriber not available".
It may also be desirable to add comfort indications (e.g. tones, noise, music, clicks) while a call is being connected,
since silence may cause an unfamiliar user to believe that nothing is happening.
ETSI
6
ETSI TS 100 512 V7.0.1T T(1999-07)
Generally, on data calls, and on the data part of alternate speech/data or speech-followed-by-data calls, PLMN
generated network tones and announcements should be muted.
2
Supervisory tones
2.1
General
Supervisory Tones, indicating primarily ringing, engaged and unobtainable numbers, may be generated by both the
PLMN and PSTN.
Except for ring tone, all tones indicating call progress to a MS user shall be generated in the MS, on the basis of signals
from the network where available, and are according to the standard defined in the present document.
Tones sent to a caller to a MS will be generated in the network, generally local to the caller, and will be to the standard
of his local exchange, except for mobile to mobile calls, where the tones will be generated in the calling MS. For
mobile terminated calls, the ring tone will be generated in the called MSC (except OACSU).
2.2
Method
In the interests of early release of the traffic channel on failure to succeed in setting up a (mobile originated) call, where
possible supervisory tones should be indicated over signalling channels. The MS will then generate the required tones.
However, if the network generates an in-band announcement this will be indicated to the MS. In this case the MS shall
connect the user to the announcement until instructed to release the call, either by the user or by the network. An
alternate procedure may apply for MS able to generate appropriate announcements internally (see clause 3).
The ring tone will be sent over the traffic channel, since this channel must be available for traffic immediately it is
answered (exception: Off Air Call Set Up). The Ring Tone is therefore generated by the PLMN or PSTN supporting the
called phone.
On failed mobile terminated call attempts, the called MSC will either signal to the caller, if this is possible, or else will
generate the required supervisory tones.
"Alert" is not a supervisory tone. The indication is signalled, and the MS may generate any form of indication to the
user that the MS is being called.
2.3
Standard tones
MS generated tones will be generally in accordance with CEPT (GSM 900 and DCS 1800), or ANSI T1.607 (PCS
1900 for NA) recommendations, where appropriate, and are listed in table 1. Any network originated tones will be
according to PLMN or PSTN choice.
2.4
Applicability
This method will apply in all cases where signalling is capable of indicating the supervisory tone required. However,
for connection to certain fixed networks where this signalling is not possible, fixed network tones will be carried over
the traffic channel.
Mobile Stations may employ any suitable technique to indicate supervisory information. However, if tones are
employed, they shall be in accordance with the present document. The use of these tones in the MSC is preferred.
NOTE 1: The tones and/or announcement to the calling party should not be provided if the Information transfer
capability is set to UDI.
NOTE 2: For a call with information transfer capability set to 3.1 kHz, the use of tones and/or announcement may
cause the expiry of an awaiting answer timer in a modem or fax machine.
ETSI
2.5
7
ETSI TS 100 512 V7.0.1T T(1999-07)
Point of introduction
Introduction E1.
2.6
Comfort tones
If desired by the PLMN operator, the network may optionally introduce "comfort tones" while the call is being
connected, during what would otherwise be silence. This would be overridden by indication of a supervisory tone, an
announcement or by traffic. PLMNs may offer this feature optionally to incoming or outgoing callers.
The "comfort tones" may take the form of tones, clicks, noise, music or any other suitable form, provided that they
cannot be confused with other indications that might be expected.
This feature is intended to indicate to the user that his call is progressing, to prevent him terminating the call
prematurely.
Table 1: Supervisory tones in GSM MSs
Tone
Frequency
Tolerance
GSM 900/
DCS 1800
425Hz
PCS 1900
for NA
15Hz
Type
GSM 900 /
DCS 1800
Continuous
PCS 1900
for NA
Continuous
1
Dial tone (optional)
2*
Subscriber Busy (Called
Number)
425Hz
15Hz
Tone on 500ms
Silence 500ms
Tone on 500ms
Silence 500ms
3*
Congestion
425Hz
15Hz
Tone on 200ms
Silence 200ms
Tone on 250ms
Silence 250ms
4
Radio Path
Acknowledgement (Mobile
Originated only) (optional)
425Hz
425Hz
15Hz
Single tone 200ms
Single tone 200ms
5
{Radio Path Not Available
{Call Dropped – Mobile
originated only
425Hz
425Hz
15Hz
200ms} On/off
200ms} for 3
burst
200ms} On/off
200ms} for 3
burst
6*
Error/Special Information}
950Hz
950Hz
50Hz
{Triple Tone
{Triple Tone
Number Unobtainable }
1400Hz
1400Hz
50Hz
{Tones on 330ms
{Tones on 330ms
Authentication Failure }
1800Hz
1800Hz
50Hz
{Silence 1.0s
{Silence 1.0s
7
Call Waiting Tone
425 Hz (tolerance 15Hz), on for 200ms, off for 600ms on for 200ms, off for 3s, on for 200ms,
off for 600ms on for 200ms. This tone is superimposed on the audio traffic received by the
called user. Alternate tones are acceptable but not preferred.
440 Hz, on for 300 ms, 9.7s off followed by (440 Hz, on for 100 ms off for 100 ms, on
for 100 ms, 9.7s off and repeated as necessary) This tone is superimposed on the audio
traffic received by the called user.
Definition of these and other tones, together with advice on announcements, may be found in CEPT T/CS 20-15 and in T/SF
23.
* The duration of these tones is an implementation option. However, in each case, the MS should be returned immediately to the
idle state, and will be able to originate/receive calls, which will override these tones.
Ringing Tone (Alternative
425Hz
15Hz
national options permitted)
Tone on 1s
Silence 4s
Tone on 2s
Silence 4s
ETSI
8
ETSI TS 100 512 V7.0.1T T(1999-07)
For application of Call Control Cause Information Elements to these tones, see Annex A, GSM 02.40.
3
Recorded announcements
In present networks, both fixed and cellular, the language of recorded announcements and displayed information is
invariably that of the country of origin. However, this is generally undesirable in a multi-lingual environment such as is
encountered on a pan-European network with international roaming. It is therefore probably desirable to minimise the
number of such announcements.
Advanced MSs may be designed which have the ability to generate announcements in the form desired by the user, e.g.
in the language preferred by the user. In this case, it becomes necessary to block any verbal announcements sent from
the network towards the MS, to avoid clashes with those generated by the MS. The MS may be allowed to block inband announcements in case appropriate announcements according to the Cause Information Elements (annex A) can
be generated. The default setting of the MS shall be "non blocking", which could be set by MMI command to
"blocking".
Announcements generated by the PLMN and sent to callers to that PLMN will generally be in the language of the
PLMN. However, on some fixed networks it will be possible for the message to be signalled back to the caller's local
exchange, which will then generate the announcement in its local language.
ETSI
9
ETSI TS 100 512 V7.0.1T T(1999-07)
Application of call control cause information elements to
supervisory tones
The Cause Information Elements are listed and defined in GSM 04.08. This annex lists these elements and indicates
which supervisory tone should be generated in response. It should be noted that some conditions (e.g. radio path not
available, dropped call) may be deduced by the MS, rather than signalled explicitly over the air interface. All causes not
listed below should result in the generation of tone 6. In case of multiple calls a tone should only be generated if it does
not disturb an ongoing active call. "-" indicates no tone required.
Cause
CC
16
17
22
30
31
34
41
42
44
49
58
Tone
(see table 1)
Normal Clearing
User Busy
Number Changed
Response to STATUS ENQUIRY
Normal, unspecified
No circuit/channel available
Temporary Failure
Switching Equipment Congestion
Requested circuit/channel not available
Quality of Service Unavailable
Bearer Capability not available
ETSI
1
2
3
3
3
3
3
3
10
ETSI TS 100 512 V7.0.1T T(1999-07)
Change history
Change history
SMG No. TDoc.
No.
CR. No.
Subclause affected New
version
21
SMG#27 98-0549
A001
A002
Annex A
Subject/Comments
Annex B First introduced at SMG#27
Update and approve Annex A
Procedure for call progress indications.
Harmonization between GSM 02.40 version 5.0.0
and J-STD-007 Volume 7.
0.1 Normative
references
2.3Standard tones
2.6 Comfort tones
ETSI
11
History
Document history
V6.0.0
April 1999
Publication
V7.0.1
July 1999
Publication
ISBN2-7437-3204-0
Dépôt légal : Juillet 1999
ETSI
ETSI TS 100 512 V7.0.1T T(1999-07)

Diseño de un sistema automatizado de pruebas para los estandares

Transcription

Similar documents

St. Joseph Catholic Church

TODAY`S READINGS First Reading — When the wicked turn away

M2M Ecosystem Development

bâÜ _twç Éy _ÉâÜwxá V{âÜv - Our Lady of Lourdes

Sts. Peter and Paul Catholic Church Sanctuary of St. Toribio Romo

Celebren Celebren El nacimiento nacimiento nacimiento de Cristo

NEBRASkA

File

blessed virgin mary help of christians church

Forecast - Info