Trabajo Fin de Máster

DE

ANÁLISIS DE EMBMS (RELEASE 14) COMO ALTERNATIVA

DE RADIODIFUSIÓN 4G

Anexo I - 3GPP: Estructura y proceso de

estandarización

Alumno Ander Barroso García

Titulación Máster Universitario en Ingeniería de Telecomunicación

Fecha Septiembre de 2016

Profesores de Proyectos Directores del Proyecto Curso Académico

Sr. Otegi Sr. Angueira 2015 - 2016

Sra. Toledo Sr. Montalban

Índice
1. Lista de tablas e ilustraciones ............................................................................................................................. 3
1.1 Tablas ............................................................................................................................................................ 3
1.2 Ilustraciones .................................................................................................................................................. 3
2. Introducción ................................................................................................................................................... 4
3. 3GPP ............................................................................................................................................................... 4
3.1 Compatibilidad ...................................................................................................................................... 4
3.2 Hitos del Acceso Radio........................................................................................................................... 5
3.3 Evolución del Núcleo Radio ................................................................................................................... 6
3.4 Generaciones de los Sistemas de Telefonía Móvil ................................................................................ 7
4. Estructura de 3GPP......................................................................................................................................... 7
4.1 Miembros de 3GPP ................................................................................................................................ 7
4.1.1 Socios Organizadores .................................................................................................................... 8
4.1.2 Socios Representantes del Mercado............................................................................................. 8
4.1.3 Miembros Individuales ................................................................................................................. 9
4.1.4 Observadores e Invitados ............................................................................................................. 9
4.2 Grupos de especificaciones de 3GPP ..................................................................................................... 9
4.2.1 Project Coordination Group (PCG) .............................................................................................. 11
4.2.2 TSG GERAN .................................................................................................................................. 11
4.2.3 TSG RAN ...................................................................................................................................... 12
4.2.4 TSG SA ......................................................................................................................................... 12
4.2.5 TSG CT ......................................................................................................................................... 13
5. Especificaciones............................................................................................................................................ 14
5.1. Proceso de estandarización ................................................................................................................. 14
5.2. Releases ............................................................................................................................................... 15
5.3. Numeración de las especificaciones .................................................................................................... 16
5.4. Solicitudes de cambio .......................................................................................................................... 18
5.5. Work Item ........................................................................................................................................... 20
5.5.1 Creación de un Work Item................................................................................................................... 22
5.5.2 Tipos de Work Items ............................................................................................................................ 22
5.5.3 Inicio, continuación del trabajo y responsabilidades .......................................................................... 23
5.5.4 Realización del Work Item ................................................................................................................... 24
5.5.5 Estados de los Work Items .................................................................................................................. 26
5.5.6 Modelo de Work Item ......................................................................................................................... 27
5.6. Tipos de documentos y estados ................................................................................................................ 28
6. Conclusiones................................................................................................................................................. 31

2
1. Lista de tablas e ilustraciones

1.1 Tablas

1. Tabla: Categorías de las Solicitudes de Cambio .................................................................................. 7

2. Tabla: Releases de 3GPP.................................................................................................................... 16
3. Tabla: Series de 3GPP ........................................................................................................................ 17
4. Tabla: Categorías de las Solicitudes de Cambio ................................................................................ 18
5. Tabla: Estados de las Solicitudes de Cambio ..................................................................................... 20
6. Tabla: Estados de los Work Item ....................................................................................................... 26
7. Tabla: Tipos de TDoc.......................................................................................................................... 29
8. Tabla: Estados de TDoc...................................................................................................................... 30

1.2 Ilustraciones

1. Imagen: Ejemplo de compatibilidad hacia adelante y hacia atrás ...................................................... 5

2. Imagen: Hitos de 3GPP ........................................................................................................................ 5
3. Imagen: Evolución del Núcleo de Red ................................................................................................. 6
2. Imagen: Estructura de 3GPP .............................................................................................................. 10
3. Imagen: Ejemplo de las reuniones de los WG ................................................................................... 10
4. Imagen: Ejemplo de cronología de una Release ............................................................................... 15
5. Imagen: Modelo de Work Item ......................................................................................................... 28
6. Imagen: Proceso de estandarización de 3GPP .................................................................................. 31

3
2. Introducción

En este documento se hace una introducción de 3rd Generation Partnership Project (3GPP), en el que
se identifican sus objetivos, jerarquía, los grupos que lo forman y el objetivo de cada uno de ellos.
Para ello, se analiza la estructura de 3GPP, formada por un grupo de coordinación y cuatro grupos de
especificaciones técnicas. Posteriormente, se estudian las áreas de trabajo de cada uno de los grupos
de especificaciones.

Posteriormente se realiza un estudio del proceso de estandarización de 3GPP. El objetivo de este

Trabajo de Fin de Máster es trabajar de cara al futuro, por ello se analizará el estado de cada una de
las Releases, fijando especial atención en el actual estado y la fecha de finalización de las mismas. A
partir de estos datos, se decidirá la Release sobre la cual estará basado este Trabajo de Fin de
Máster. Además, se analizan otros aspectos de interés como las solicitudes de cambio y los Work
Item de 3GPP.

3. 3GPP

El proyecto 3GPP es una entidad colaborativa formada por siete desarrolladores de estándares de
telecomunicaciones, también conocidos como "Socios Organizadores", que provee a sus miembros
de una estructura estable para producir los informes y especificaciones que definen las tecnologías
de 3GPP. Este proyecto cubre las redes de tecnologías celulares, incluyendo el acceso radio, la red de
transporte y servicios (codecs, seguridad, calidad de servicio) y, por lo tanto, sus especificaciones
cubren el sistema completo.

El propósito general de 3GPP es preparar, aprobar y mantener Especificaciones Técnicas (Technical

Specifications) y Reportes Técnicos (Technical Reports) para:

 continuar con la evolución de GERAN (GSM/EDGE Radio Access Network).

 evolucionar UTRA (Universal Terrestrial Radio Access), sistema de comunicaciones móviles de
3ª Generación, también conocido como 3G.
 desarrollar tecnologías radio como LTE (Long Term Evolution), al mismo tiempo que se
desarrollan los elementos que forman el núcleo de, como EPC (Evolved Packet Core).

Este desarrollo debe ser realizado con una visión global de roaming y circulación de terminales, de tal
manera que los terminales puedan ser utilizados en cualquier punto del planeta. Además, las
especificaciones de 3GPP deben incluir varias opciones en forma de requerimientos regulatorios
particulares para diferentes regiones o naciones. Por lo tanto, los resultados del trabajo realizado por
3GPP deberían formar la base de la contribución de sus miembros a ITU, de acuerdo con los
procedimientos existentes.

3.1 Compatibilidad

La compatibilidad hacia adelante y hacia atrás (fordward and backward compatibility), que consiste
en que cuando sea posibles las nuevas Releases sean compatibles con sus predecesoras, es uno de

4
los mayores objetivos de todas las Releases de 3GPP. De esta forma forma se pretende conseguir que
el funcionamiento de los terminales de los usuarios sea continuo, sin interrupciones. Un buen
ejemplo de este principio es la prioridad establecida en los Grupos de Trabajo para asegurar la
compatibilidad hacia atrás entre LTE y LTE-Advanced, de tal manera que un terminal LTE-A pueda
funcionar correctamente en una celda LTE y, al revés, que un terminales LTE pueda funcionar en una
celda LTE-A.

1. Imagen: Ejemplo de compatibilidad hacia adelante y hacia atrás

3.2 Hitos del Acceso Radio

RAN, uno de los Technical Specificacion Group de 3GPP, al igual que otros se asegura de que los
sistemas basados en las especificaciones de 3GPP puedan ser evolucionados y desplegados de
manera rápida, asegurando el roaming global del equipamiento. Entre las tecnologías y sistemas
radio desarrollados en las Releases de 3GPP en los últimos años se destacan los que se muestran a
continuación:

2. Imagen: Hitos de 3GPP

5
Todos estos avances han provisto a la evolución de los sistemas de un alto nivel de continuidad,
permitiendo preparar el equipamiento actual para futuras características y funcionalidades,
ofreciendo mayores velocidades, calidad de servicio y eficiencia en el coste. A partir de la Release 10,
3GPP LTE-Advanced ha sido aprobado por ITU como un ITU-R IMT-Advanced Radio Interface
Technology. El estándar LTE ofrece velocidades pico de 100 Mbit/s con gran movilidad y 1 Gbit/s en
comunicaciones con poca movilidad.

Cada nueva tecnología de acceso radio se desarrolla con el objetivo de reducir la complejidad y evitar
la fragmentación de las tecnologías ofrecidas.

3.3 Evolución del Núcleo Radio

Las redes de GSM inicialmente utilizaban la telefonía con conmutación de circuitos, a la que se le
añadió la conmutación de paquetes con GPRS. En la arquitectura UMTS, este concepto de dominio
dual se mantuvo en el núcleo de red. Aunque algunos elementos de la red evolucionaron, el
concepto de conmutación de circuitos y paquetes se mantuvo de manera muy similar.

Cuando se consideró la evolución del sistema 3G hacia LTE, la comunidad de 3GPP decidió utilizar IP
(Internet Protocol) como el protocolo clave para transportar todos los servicios. Se decidió que el EPC
(Evolced Packet Core) no tuviera un dominio de conmutación de circuitos, sino que EPC debería ser
una evolución de la arquitectura de conmutación de paquete utilizada en GPRS/UMTS.

Esta decisión tuvo consecuencia no sólo en la propia arquitectura, sino que también cambió la forma
en la que los servicios eran proporcionados. A partir de dicho momento se estableció un nuevo hito
en la manera de dar servicios de voz y mensajería corta.

3. Imagen: Evolución del Núcleo de Red

6
3.4 Generaciones de los Sistemas de Telefonía Móvil

Con el fin de situar en contexto las diferentes generaciones de los sistemas de telefonía móvil, en la
siguiente tabla se resumen los hitos más relevantes de cada una de las generaciones.

Generación Hitos más relevantes

Tecnología analógica, a partir de 1980. Varias tecnologías fueron implementadas a nivel

Nacional o Regional, entre las que se incluían: NMT (Nordic Mobile Telephone), AMPS
1G (Advanced Mobile Phone System), TACS (Total Access Communications System), A-Netz to E-
Netz, Radiocom 2000, RTMI (Radio Telefono Mobile Integrato), JTACS (Japan Total Access
Communications System) and TZ-80n.

Primeros sistemas digitales, desplegados en la década de los 90, que contenían servicios de
2G voz, SMS y datos. Las tecnologías 2G primarias son: GSM/GPRS, CDMAOne, PDC, iDEN, IS-
136 or D-AMPS. Cabe destacar que el 80% de los subscriptores de 2G lo hacían a GSM/GPRS.

Esta generación permitió crear una visión global de las redes de 2G, con tecnologías que
3G mejoraban la familia de los sistemas IMT-2000. Las tecnologías primarias 3G son: EDGE
(Enhanced Data for GSM), CDMA2000 1X/EVDO, UMTS-HSPA+.

LTE y LTE-Advanced han supuesto la creación de una nueva generación, proveyendo a las
4G y siguientes generaciones con nuevas capacidades. Con su capacidad de transmisión de alta
posteriores velocidad, mejora de la eficiencia espectral y la adopción de técnicas radio avanzadas, su
aparición ha supuesto la base para los sistemas móviles futuros.
1. Tabla: Categorías de las Solicitudes de Cambio

4. Estructura de 3GPP

El análisis de la estructura de 3GPP puede dividirse en dos ejes fundamentales. Por un lado se sitúa la
estructura de los miembros y, por otro lado, la estructura interna de trabajo de 3GPP, la que forman
los grupos de especificaciones de 3GPP. En este apartado se abordará cada una de ellas por
separado.

4.1 Miembros de 3GPP

3GPP no es una entidad legal, sino un entidad colaborativa formada por siete Organizaciones
Desarrolladoras de Estándares reconocidas mundialmente:

 ARIB (Association of Radio Industries and Businesses), Japón.

 CCSA (China Communications Standards Association), China.
 ETSI (European Telecommunications Standards Institute), Europa.
 ATIS (Alliance for Telecommunications Industry Solutions), EEUU.
 TTA (Telecommunications Technology Association), Corea.
 TTC (Telecommunication Technology Committee), Japón.
 TSDSI (Telecommunications Standards Development Society), India.

7
En cuanto a las categorías de participación en 3GPP, se pueden distinguir cinco:

 Socios (Partners)
 Miembros Individuales (Individual Members)
 Representantes de ITU (ITU Representatives)
 Observadores (Observers)
 Invitados (Guests)

Cabe destacar que, además de la anterior clasificación, hay que tener en cuenta que todos los Socios
(Partners) de 3GPP tienen que pertenecer a alguno de los dos siguientes categorías:

 Socios Organizadores (Organizational Partners)

 Socios Representantes del Mercado (Market Representation Partners)

4.1.1 Socios Organizadores

La participación como Socio Organizador está abierta a cualquier Organización Desarrolladora de

Estándares, independientemente de su área geográfica, que:

 tenga un estatus reconocido, ya sea nacional, regional o de otro tipo y que tenga la
capacidad y autoridad para definir, publicar y decidir estándares dentro de los objetivos de
3GPP, en la mencionada nación o región.
 siga cualquier política de Derechos de Propiedad Intelectual (DPI) que sea compatible con las
políticas de los Socios Organizadores.
 sea parte todos o parte de sus objetivos compartidos con 3GPP.
 haya firmado el Acuerdo de Participación en el Proyecto (Partnership Project Agreement).

Cualquier Organización Desarrolladora de Estándares puede solicitar ser Socio Organizador

poniéndose en contacto con cualquiera de los Socios Organizadores existentes.

4.1.2 Socios Representantes del Mercado

Los Socios Organizadores pueden invitar a Representantes del Mercado para ser Socios de 3GPP. Las
invitaciones para convertirse en Socio Representante del Mercado está abierta a cualquier
organización que:

 tenga la capacidad de aconsejar a 3GPP sobre los mercados y crear en 3GPP consenso en
cuanto a los requerimientos (servicios, características y funcionalidades) de mercado.
 no tenga la capacidad ni autoridad para definir, publicar y decidir estándares dentro de los
objetivos de 3GPP.
 sea parte todos o parte de sus objetivos compartidos con 3GPP.
 haya firmado el Acuerdo de Participación en el Proyecto (Partnership Project Agreement).

8
4.1.3 Miembros Individuales

El requisito previo que tiene que cumplir una entidad para ser Miembro Individual es ser miembro de
uno de los Socio Organizadores de 3GPP. Además, todas estas entidades que sean elegibles para ser
partícipes del trabajo técnico de los Socios Organizadores pueden convertirse en Miembros
Individuales de 3GPP, siempre y cuando estén dispuestas a apoyar el trabajo de 3GPP y a:

 contribuir técnicamente o, sino, contribuir al trabajo de uno o más Technical Specification

Group.
 utilizar el resultado de los trabajos de 3GPP en la medida de lo posible.

Cada Miembro Individual tiene derecho a participar en el trabajo de 3GPP acudiendo a las reuniones
de los TSG y sus subgrupos. Las solicitudes para convertirse en Miembros Individuales de un TSG han
de ser realizadas al Socio Organizador pertinente.

4.1.4 Observadores e Invitados

El status de Observador puede ser concedido por cualquiera de los Socios Organizadores a una de las
entidades que posee las cualificaciones para convertirse en miembro en el futuro. Los Observadores
pueden enviar un representante a las reuniones de los Socios Organizadores o a las de los Project
Coordination Group. Los representantes de los miembros Observadores pueden recibir
documentación y contribuir con documentación informativa, pero no podrán presentar
documentación que proponga cambios a las especificaciones, informes, descripciones de los work
items, planes de trabajo o cualquier otro documento bajo el control de los Technical Specification
Groups. Además, los Observadores no podrán ser parte de cualquier posición de toma de decisiones
o liderazgo. Todas los derechos adicionales de los Observadores no mencionados anteriormente,
deberán ser ratificados por los Socios Organizadores caso por caso.

El status de Invitado puede ser expedido por un tiempo limitado de tiempo, por un Socio Organizador
a cualquier entidad que esté cualificada para convertirse en un Miembro Individual en un futuro. La
duración del mencionado "tiempo limitado" será decidido por los Socios Organizadores caso por
caso. Los Invitados pueden enviar representantes a las reuniones de los Technical Specification
Groups o de sus subgrupos. Estos representantes podrán recibir documentos pero no podrán
participar en las discusiones, toma de decisiones, contribuir con documentos o tomar ningún puesto
de liderazgo.

4.2 Grupos de especificaciones de 3GPP

La estructura de 3GPP está encabezada por el grupo de coordinación PCG, que coordina los cuatro
grupos de especificaciones técnicas (TSG). Estos, a su vez, están formados por varios grupos de
trabajo (WG). Los cuatro TSG que forman 3GPP son los siguientes:

 Radio Access Networks (RAN)

 Service & Systems Aspects (SA)
 Core Network & Terminals (CT)
 GSM EDGE Radio Access Networks (GERAN)

9
La estructura es la que se muestra en la siguiente imagen.

2. Imagen: Estructura de 3GPP

Por su parte, los WG se reúnen regularmente para discutir los temas que se tratarán, discutirán y
aprobaran en su correspondiente Plenario de TSG (TSG Plenary). Cada TSG tiene un área de
responsabilidad particular en cuanto a los Reportes y Especificaciones que serán publicados.

La última reunión del ciclo de Plenarios es la del TSG SA, que también tiene la responsabilidad de la
coordinación y monitorización del progreso de los diferentes trabajos.

3. Imagen: Ejemplo de las reuniones de los WG

Las tecnologías de 3GPP desarrolladas por estos grupos están en constante evolución a través de
Generaciones comerciales de los sistemas de comunicaciones móviles o celulares. Aunque esta
descripción en diferentes Generaciones se ha convertido en un adecuado método sobre el que
clasificar la red sobre la que se trabaja, el progreso real de los estándares de 3GPP están medido
mediante los hitos alcanzados mediante las Releases.

10
Si bien es cierto que las nuevas funcionalidades están preparadas para ser implementas cuando una
Release ha sido completada, 3GPP trabaja en varias Releases en paralelo, comenzando con el trabajo
futuro con antelación a la finalización de la Release actual. Aunque esta forma de trabajo añade un
grado de complejidad al trabajo de los grupos, permite asegurar un progreso continuo y estable.

4.2.1 Project Coordination Group (PCG)

El grupo PCG, situado en lo más alto de la jerarquía de 3GPP, se reúne cada 6 meses para decidir
cuáles serán los puntos de trabajo de los TSG, ratificar la elección de resultados y los recursos
comprometidos para ello.

Este grupo es responsable de los plazos y gestiones de los grupos técnicos, para así poder asegurar
que las especificaciones de 3GPP se crean de acuerdo a los plazos establecidos por los mercados.
Cada TSG tiene la responsabilidad de preparar, aprobar y mantener las especificaciones de acuerdo a
los términos de referencia, coordinando sus WG. Posteriormente, cada TSG informa al PCG.
Específicamente, el PCG tiene las siguientes responsabilidades:

 Gestión del trabajo de todos los grupos de trabajo para que se ajusten a los plazos
establecidos.
 Aprobación de los temas de trabajo de acuerdo a los objetivos de 3GPP.
 Distribución de los recursos humanos y financieros a cada uno de los TSG.
 Asignación de recursos humanos y/o financieros adicionales a cada TSG, aportados por los
Miembros Individuales de 3GPP.
 Nombramiento de los presidentes de los TSG.
 Nombramiento del presidente del PCG.
 Gestión de las solicitudes técnicas y de procedimiento de los Miembros Individuales.

4.2.2 TSG GERAN

El TSG GSM/EDGE Radio Access Network (GERAN) es responsable de la parte de acceso radio en las
especificaciones. Concretamente, es responsable de los aspectos radio e interfaces GERAN y de la
gestión de los puntos de trabajo que están bajo su responsabilidad. Más concretamente, GERAN es
responsable de las siguientes áreas de trabajo:

 Aspectos RF de GERAN.
 Especificaciones de las capas 1, 2 y 3 de GERAN.
 Especificaciones de las interfaces internas (Abis, Ater) y externas (A, Gb) de GERAN.
 Creación de especificaciones para evaluación de todos los aspectos de las estaciones base y
terminales GERAN.
 Creación de especificaciones para evaluación del rendimiento del sistema RF de GERAN.
 Coordinación con otros TSG para asegurar la coordinación global de 3GPP.

11
La consecución de estos objetivos está directamente ligado con la estructura de GERAN, que está
subdividido en tres grupos de trabajo (WG):

 GERAN WG1: responsable de los aspectos radio de GERAN.

 GERAN WG2: encargado de los protocolos de las capas superiores a la capa física.
 GERAN WG3: responsabilidad de realizar las especificaciones técnicas para el testeo de los
terminales.

4.2.3 TSG RAN

El TSG Radio Access Network (RAN) es responsable de la definición de las funciones, requerimientos e
interfaces de las red UTRA/E-UTRA en sus dos modos, FDD y TDD. Estas son las áreas de trabajo más
relevantes de RAN:

 Especificación del interfaz radio Uu en las capas 1,2 y 3 para el UE, el Node B y el eNode B.
 Especificación del interfaz radio Un en las capas 1,2 y 3 para el relay node y el eNode B.
 Arquitecturas UTRAN y E-UTRAN, incluyendo la especificación de las interfaces entre
UTRAN/E-UTRAN y el núcleo de red y de las interfaces internas de UTRAN/E-UTRAN.
 Especificación del LTE Positioning Protocol (LPP) entre el UE y el servidor de posicionamiento
de LTE y entre el eNodeB y el servidor de posicionamiento.
 Definición de los requerimientos operativos y de mantenimiento de UTRAN y E-UTRAN.
 Creación de especificaciones y test para la evaluación de todos los aspectos del sistemas de
RF y de las estaciones base.
 Coordinación con otros TSG para asegurar la coordinación global de 3GPP.

El TSG RAN está formado por siete los siguientes grupos de trabajo, cuyas responsabilidades se
resumen a continuación:

 RAN WG1: especificación de la capa radio 1.

 RAN WG2: especificación de las capas radio 2 y 3.
 RAN WG3: especificaciones Iub, Iur y Iu; requerimientos operativos y de mantenimiento
UTRAN.
 RAN WG4: rendimiento radio y protocolos del sistema; parámetros RF y adecuación de BS.
 RAN WG5: testeo de terminales.
 RAN WG6: protocolos y aspectos radio de Legacy RAN.
 RAN AHG1: Grupo ad-hoc para la coordinación con ITU.

4.2.4 TSG SA

El TSG Service and System Aspects (SA) es responsable de las capacidades de la arquitectura y servicio
de los sistemas basados en las especificaciones de 3GPP y, en consecuencia, tiene la responsabilidad
de mantener la coordinación con otros TSG, reportando al PCG cualquier dificultad relacionada con
este rol. A continuación se resumen sus responsabilidades:

12
  Definición, evolución y mantenimiento de la arquitectura del sistema, incluyendo la
asignación de funciones a los subsistemas (UTRAN, GERAN, CN, terminal, SIM/USIM), la
identificación de las corrientes de información claves y la definición servicios ofrecidos por
los subsistemas mencionados.
 Desarrollo de infraestructuras para servicios, capacidades de servicios, arquitecturas de
servicios y la consideración de la necesidad de condiciones base para los servicios y
aplicaciones.
 Definición de una arquitectura de seguridad y la revisión de los aspectos de seguridad del
sistemas.
 Gestión de las áreas de trabajo, incluyendo la asignación de tareas a otros TSG y la
monitorización de su progreso.

El TSG SA está formado por siete los siguientes grupos de trabajo:

 SA WG1: servicios
 SA WG2: arquitectura.
 SA WG3: seguridad.
 SA WG4: codecs.
 SA WG5: gestión de la red.
 SA WG6: aplicaciones críticas.

4.2.5 TSG CT

El TSG Core Network and Terminals (TSG CT) es responsable de especificar las interfaces lógicas y
físicas de los terminales, sus capacidades y el núcleo de red de los sistemas 3GPP. Estos son algunas
de sus campos de acción:

 Protocolos de la capa 3 entre el UE y el núcleo de red, tanto en CS como en PS, excluyendo

las capas de acceso.
 Interoperabilidad del núcleo de red con redes internas y externas.
 SIM/USIM/ISIM y las especificaciones de sus interfaces.
 Aplicaciones de los terminales y la red soportadas por los terminales 3GPP.
 Protocolos de los dominios CS y PS en el núcleo de red para los sistemas 3GPP legacy y
evolved.
 Subsistema multimedia IP (IMS) y su adaptación a diferentes tecnologías de acceso.

El TSG CT está formado por siete los siguientes grupos de trabajo:

 CT WG1: protocolos de la capa 3 (Call Control, Session Management, Mobility Management,

SMS).
 CT WG3: interoperabilidad con redes externas.
 CT WG4: MAP/GTP / BCH/SS.
 CT WG6: aplicaciones Smart Card.

13
5. Especificaciones

En este apartado se tratan todos los aspectos relacionados con las especificaciones realizadas en el
seno de 3GPP. En primer lugar se explican brevemente las etapas del proceso de estandarización de
3GPP. El siguiente apartado trata las Releases de 3GPP, que no son más que un conjunto de
especificaciones desarrolladas de forma paralela a lo largo de un periodo de tiempo concreto. A
continuación se explican los métodos de numeración de las especificaciones y el proceso de solicitud
de cambio de las mismas. Otro de los temas analizados es el de los work item, de vital importancia en
este Trabajo de Fin de Máster ya que como se verá más adelante, será uno de ellos en los que se
basará este trabajo. Para finalizar, se presentan los tipos de documentos existentes en 3GPP y sus
posibles estados a lo largo del proceso de estandarización.

5.1. Proceso de estandarización

El proceso de estandarización en 3GPP es realizado a base de contribuciones. Las compañías o

Miembros Individuales, participan mediante su representación dentro de los Miembros Organizativos
(Organizational Partners).

El proceso de especificación se realiza a nivel de Grupos de Trabajo (Working Groups o WG) y a nivel
de Grupos Técnicos de Especificaciones (Tecnical Specifications Group o TSG):

 Los WG mantienen varias reuniones a lo largo del año. En ellas, se preparan y discuten las
solicitudes de cambios en las especificaciones de 3GPP. Las solicitudes aprobadas en los WG
son calificadas como acordadas (agreed).

 Los TSG se reúnen trimestralmente. En dichas reuniones, se pueden aprobar o denegar las
solicitudes de cambios acordadas en los WG. Algunas de las especificaciones son
responsabilidad directa de los TSG, por lo que los cambios realizados pueden ser propuestos
a nivel de TSG. Las solicitudes de cambio aprobadas son posteriormente incorporadas a las
especificaciones.

3GPP sigue una metodología de tres etapas a la hora de realizar las especificaciones, que
posteriormente son agrupadas en Releases:

 Primera etapa (stage 1): estas especificaciones definen los servicios requeridos desde el
punto de vista del usuario.

 Segunda etapa (stage 2): definen la arquitectura necesaria para dar soporte a los servicios
definidos en la primera etapa.

 Tercera etapa (stage 3): definen la implementación de la arquitectura definida en la segunda

etapa, mediante la especificación de los protocolos en detalle. Las especificaciones de
prueba (test specification) suelen ser denominadas como la cuarta etapa, ya que son
realizadas tras la tercera etapa.

14
5.2. Releases

3GPP utiliza un sistema de Releases en paralelo, lo que permite a los desarrolladores disponer de una
plataforma estable para la implementación de características concretas y, además, la posible
incorporación de nuevas funcionalidades en posteriores Releases.

4. Imagen: Ejemplo de cronología de una Release

Cada una de las Relases es acotada cronológicamente por tres fechas claves: fecha de inicio (start
date), fecha de finalización (end date) y fecha de cierre (closure date).

 Start date: la fecha de inicio de una Release es un indicador de la fecha en la que fue
realizado el primer work item o artículo de trabajo. Aún así, cabe destacar que es una fecha
aproximada, ya que en ocasiones los artículos de trabajo pueden haber empezado en una
Release anterior, pero sin llegar a ser completados. Es decir, son trasladados a la siguiente
Relase. A partir de este momento, el estado de la Release pasa a ser abierto (open).

 End date: la fecha de finalización indica que los protocolos detallados han pasado a ser
estables. A partir de ese momento, el estado de la Release pasa a estar congelado (frozen).
Sin embargo, dicha Release todavía puede sufrir alguna modificación menor, como
actualizaciones o correcciones, que pueden esperarse durante un periodo no menor a dos
años tras la fecha de finalización. Cabe destacar que la adición o modificación de
funcionalidades queda prohibida.

 Closure date: la fecha de cierre indica el momento a partir del cual las Releases no sufrirán
ningún cambio de ningún tipo. El estado de la Release pasa a estar cerrado (closed).

En la tabla que se muestra a continuación se resume el estado y las fechas previamente mencionadas
de cada una de las Releases desarrolladas por 3GPP.

15
 Nombre Estado Start date End date Closure date

Release 15 Open 2016-06-01 -

Release 14 Open 2014-09-17 2017-06-09 (SA#76)
Release 13 Frozen 2012-09-30 2016-03-11 (SP-71)
Release 12 Frozen 2011-06-26 2015-03-13 (SP-67)
Release 11 Frozen 2010-01-22 2013-03-06 (SP-59)
Release 10 Frozen 2009-01-20 2011-06-08 (SP-52)
Release 9 Frozen 2008-03-06 2010-03-25 (SP-47)
Release 8 Frozen 2006-01-23 2009-03-12 (SP-43)
Release 7 Closed 2003-10-06 2008-03-13 (SP-39) 2014-09-17 (SP-65)
Release 6 Closed 2000-03-28 2005-09-28 (SP-29) 2014-09-17 (SP-65)
Release 5 Closed 2000-05-01 2002-09-12 (SP-17) 2014-09-17 (SP-65)
Release 4 Closed 1998-08-01 2001-06-21 (SP-12) 2014-09-17 (SP-65)
Release 2000 Closed 1999-03-30 1999-12-17 (SP-06)
Release 1999 Closed 1996-11-01 1999-12-17 (SP-06) 2008-06-05 (SP-40)
UMTS Closed 1994-08-18 1999-02-12 (SMG-28) 2005-06-08 (SP-28)
Release 1998 Closed 1996-03-26 1999-02-12 (SMG-28) 2005-06-08 (SP-28)
Release 1997 Closed 1996-04-15 2005-06-08 (SP-28)
Release 96 / Phase 2+ Closed 1995-07-20 2004-09-16 (SP-25)
Phase 2 Closed 1993-03-25 2004-09-16 (SP-25)
Phase 1 extension Closed 1994-10-01
Phase 1 DCS-1800 Closed 1992-12-03

Phase 1 Closed 1987-01-01

2. Tabla: Releases de 3GPP

5.3. Numeración de las especificaciones

Entender el método de numeración de las especificaciones que sigue 3GPP es de vital importancia,
debido a la gran cantidad de especificaciones que existen y sus numerosas versiones.

La numeración de todas las especificaciones de 3GPP se componen de cuatro o cinco dígitos. Los
primeros dos dígitos definen las serie a la que corresponde cada especificación, que están seguidos
por otros dos dígitos más para las series 01-13 y por tres dígitos para las series 21-55. El título
completo de cada especificación, junto a su número de especificación y el número de la última
versión puede encontrarse en http://www.3gpp.org/specifications/specification-numbering.

En la tabla que se muestra a continuación se resume el tema de todas series de 3GPP, clasificadas
por tecnologías (GSM, 3G o posteriores) y Releases.

16
 3G y posteriores / GSM (Rel-4 y GSM (previas
Tema de las series
GSM posteriores) a Rel-4)

Información general serie 00

Requerimientos serie 21 serie 41 serie 01

Servicios (stage 1) serie 22 serie 42 serie 02

Realización técnica (stage 2) serie 23 serie 43 serie 03

Protocolos de señalización (stage 3) - usuario a red serie 24 serie 44 serie 04

Aspectos radio serie 25 serie 45 serie 05

CODECs serie 26 serie 46 serie 06

Data serie 27 serie 47 serie 07

Protocolos de señalización (stage 3) -(RSS-CN) y

serie 28 serie 48 serie 08
OAM&P y Charging

Protocolos de señalización (stage 3)- intrared serie 29 serie 49 serie 09

Gestión programática serie 30 serie 50 serie 10

Subscriber Identity Module (SIM / USIM), tarjetas

serie 31 serie 51 serie 11
IC, especificaciones de tests

OAM&P y Charging serie 32 serie 52 serie 12

Requerimientos de acceso y especificación de tests serie 13 (1) serie 13 (1)

Seguridad serie 33 (2) (2)

Especificación de tests del UE y (U)SIM serie 34 (2) serie 11

Algoritmos de seguridad (3) serie 35 serie 55 (4)

LTE (Evolved UTRA), LTE-Advanced, LTE-Advanced

serie 36 - -
Pro radio technology

Aspectos de accesos radio múltiples serie 37 - -

Tecnología radio posterior a LTE serie 38 - -

3. Tabla: Series de 3GPP

Nota (1): La series 13 de GSM están relacionadas con estándares regulatorios de la Unión Europea. La
responsabilidad de estas especificaciones fue transferida a ETSI TC MSG (Mobile Specification Group)
y por esa razón no figuran en los servidores de 3GPP.

Nota (2): Estas especificaciones están divididas en varias series.

Nota (3): Los algoritmos pueden estar sujetos a condiciones de licencias.

Nota (4): Los algoritmos originales de GSM no son publicados y están controlados por la GSM
Association.

17
5.4. Solicitudes de cambio

En el apartado 5.1. Proceso de estandarización, se ha mencionado la posibilidad de realizar

Solicitudes de Cambio o Change Requests (CR), que es la herramienta de la que disponen los WG para
solicitar cambios en las especificaciones de 3GPP tras su aprobación inicial.

Un CR es un documento temporal que especifica de manera detallada los cambios propuestos a una
especificación concreta. Está formado por una carátula o CR coversheet que, entre otros aspectos,
describe la razón por la que un cambio es necesario y explica la manera de realizar dicho cambio.
Junto con la carátula, se añaden los apartados afectados de la especificación en cuestión,
identificándolos mediante la herramienta Track Changes de Microsoft Word.

Las seis categorías en las que se puede clasificar las solicitudes de cambio se resumen a continuación:

Categoría Significado A tener en cuenta

Se usa para reflejar cambios en una Release anterior de una misma
especificación.
Corresponde a un
A cambio de una Nota: El cambio propuesto a una Release posterior no necesita ser
Release anterior absolutamente idéntico al cambio propuesto a una Release anterior, ya
que debido a otras solicitudes de cambio anteriores es posible que el
texto afectado no sea idéntico en cada Release.
Una nueva funcionalidad será añadida a la Release; la referencia no es la
Adición o eliminación
B especificación misma, sino un work item concreto. Esta categoría no
de una funcionalidad
puede ser utilizada para una Release en estado frozen.
Cualquier modificación funcional debe corresponder a un work item
Modificación
concreto. Sin embargo, la "compatibilidad hacia atrás" debe ser
C funcional de una
garantizada cuando impacte a un equipamiento de usuario. Esta categoría
funcionalidad
no puede ser utilizada para una Release en estado frozen.

Modificación Se usa para reflejar cambios funcionales realizados a una Release anterior
D
editorial de la misma especificación.

E (no se usa)

Utilizada para:
1. corregir un error en la especificación (por ejemplo una instrucción de la
especificación que conduce a un incorrecto funcionamiento del sistema.
2. corregir una ambigüedad en la especificación que podría dar pie a
F Corrección diferentes implementaciones no interoperables.
3. corregir una incorrecta implementación de una solicitud de cambio
previamente aprobada.
4. corregir un desalineamiento de funcionalidades o servicios entre
especificaciones (stage 1, stage 2 o stage 3)

4. Tabla: Categorías de las Solicitudes de Cambio

18
Las principales razones por las que se puede requerir una solicitud de cambio son tres:

 Añadir una nueva funcionalidad o característica a una especificación.

 Corregir, clarificar o mejorar una funcionalidad en una especificación perteneciente a una
Release que todavía está en desarrollo.
 Corregir un error en especificación cuyo estado es Frozen.

Las solicitudes de cambio puede ser propuestas por cualquier organización miembro de 3GPP. Las
solicitudes son entregadas al WG responsable de la especificación afectada. Una vez el WG a
decidido que la Solicitud de Cambio es válida y necesaria (en ocasiones una solicitud puede ser
revisada varias veces hasta alcanzar esta etapa), es presentada al pleno del TSG correspondiente
para su aprobación final. Una vez que la solicitud de cambio ha sido aprobada por el TSG, el 3GPP
Support Team (MCC) la incorpora a una nueva versión de la especificación, para su posterior
publicación. El proceso completo de Solicitud de Cambio está descrito en la TR 21.900 "Technical
Specification Group working methods" [1].

Al igual que sucede con las especificaciones, las propuestas de cambio tienen una numeración
reguladas. Por ejemplo, la solicitud de cambio CR 31.102-0095 es la solicitud número 0095 a la
especificación 31.102. Toda solicitud de cambio presentada al pleno de un TSG es archivada en una
base de datos, a la que se puede acceder mediante el siguiente link:
http://www.3gpp.org/ftp/Information/Databases/Change_Request. Esta base de datos, en formato
Microsoft Access, contiene el estado de cada solicitud y, en caso de ser aprobada, indica el número
de la nueva versión creada de la especificación. Cabe destacar que cada especificación contiene un
historial de todas las solicitudes de cambio aprobadas.

A medida que una Release se va desarrollando, el número de especificaciones que la forman va

aumentando progresivamente. Si bien esto puede parecer que indique un mayor estabilidad y una
reducción en el número de solicitudes de cambio, la realidad es diferente. Una vez que las Releases
pasan a estado frozen el número de solicitudes de cambio se incrementa de manera dramática,
principalmente debido a que es la etapa en la que se produce el desarrollo de los equipamientos. La
implementación de sistema reales y el desarrollo de los protocolos conllevan muchas mejoras y
correcciones, que se reflejan en el número de solicitudes de cambio.

El criterio para decidir el momento en el que una especificación de una Release concreta ha pasado a
ser "estable" es subjetivo. Si la implementación real se hace demasiado pronto, el riesgo de cambios
técnicos esenciales incrementa, pero al mismo tiempo se estará en mejor lugar para conseguir mayor
penetración en el mercado de manera temprana. Y viceversa. Es decisión de cada desarrollador
tomar la decisión.

La tabla que se muestra a continuación resume el significado de los estados de las solicitudes de
cambio. Además, indica que si dichos estado pueden ser utilizados a nivel de TSG o WG.

19
Estado de CR TSG WG Uso

- SI SI No ha sido todavía analizada y no se ha tomado ninguna decisión.

Aceptada
NO SI Sin ninguna objeción para que sea enviada al TSG para su aprobación.
(agreed)

Aprobada Sin ninguna objeción para que sea implementada en el correspondiente TS/TR
SI NO
(approved) (decisión final).

Rechazada Objeción a que la solicitud de cambio progrese. Este estado no es políticamente

SI SI
(rejected) correcto en algunos grupos.

No
discutida
SI SI La versión políticamente correcta de Rechazada.
(not
pursued)

Revisada
SI SI Modificada a una nueva versión de la misma solicitud de cambio.
(revised)

Mezclada
SI SI Combinación de una o más solicitudes de cambio.
(merged)

Postpuesta Decisión aplazada a una fecha posterior. Cuando es utilizada a nivel de TSG,
SI SI
(postponed) normalmente indica que el WG la reexaminará .

Respaldada Consenso a nivel de WG que la solicitud de cambio es correcta a nivel técnico,

NO SI
(endorsed) pero puede haber otras soluciones

Retirada Nunca fue producida o fue retirada por el autor antes de la discusión del
SI SI
(withdrawn) WG/TSG.

Reeditada Solicitudes de cambio al TSG, incluidas en múltiples packs de solicitudes de

SI NO
(reissued) cambio.

Tenida en No ha sido presentada en este momento, sólo tenida en cuenta a modo

cuenta SI SI informativo. Este estado es menospreciado, ya que Tenida en cuenta es
(noted) demasiado ambiguo.
5. Tabla: Estados de las Solicitudes de Cambio

5.5. Work Item

En cualquier proyecto complejo de ingeniería es necesaria su planificación, monitorización del

progreso y tener la posibilidad de determinar si está siendo completado ajustándose a los tiempos y
presupuesto establecidos. Para poder llevar a cabo este control, en la informe TR 21.900 [1] de 3GPP
se proponen varios pasos que se enumerarán a continuación.

20
En primer lugar habitualmente será deseable producir un Study Item (SI). Este tipo de ítem es un
estudio inicial que tendrá como resultado un informe técnico o Technical Report (TR), que no es más
que un estudio de viabilidad para una funcionalidad adicional. Si los resultados de dicho estudio
fueran positivos, desembocarían en uno o más Work Item (WI).

Tras la realización del SI, se definirán algunas nuevas características o Features que se desearán
añadir al sistema existente. Estas son funcionalidades nuevas o ampliadas de manera substancial que
dan un valor añadido al sistema existente. Estas Features deben de ser, de alguna manera,
independientes. Es decir, cada nueva característica debe ser vista como extra opcional, que podrá ser
añadida al sistema o no en función de la demanda del mercado. Cabe destacar que la descripción de
una Feature no tiene por qué ser técnicamente precisa, pero sí un concepto entendible a nivel de
servicio.

Siendo este el caso, la mayoría de las Features serán responsabilidad de SA1, subgrupo de TSG SA. El
conjunto de las nuevas características del sistema representará la diferencia entre una Release y su
Release predecesora.

Las Features pueden ser consideradas como objetivos a alto nivel desde el punto de vista de la
gestión del proyecto. Ya que la mayoría de estas nuevas características serán demasiado complejas,
deberán de ser divididas en elemento más simples: Buildin Blocks.

Un Building Block es una subdivisión de una nueva Feature, que representa un conjunto de
funcionalidades coherentes y es implementada en un elemento único del sistema. Los Building Blocks
deben de ser definidos en términos técnicos y su descripción requerirá de la comprensión de la
arquitectura del sistema completo. Un concepto que se destaca en los Building Blocks es un
reusabilidad, es decir, que puede existir un Building Block común a más de una Feature. En el caso de
las Features simples, un Building Block será suficiente, por lo que en esos casos ambos serán
sinónimos.

Por lo general, para la implementación de un Building Block será necesario subdividir todavía más la
funcionalidad en tareas, donde cada una de ellas represente una actividad específica. Estas tareas se
definen como Work Task. La diferencia más relevante entre los Building Blocks y las Work Tasks es
que estos últimos identifican de manera inequívoca un ítem muy concreto.

Es en este punto tan bajo de la jerarquía donde se pueden realizar las estimaciones de duración de
cada tarea. A partir de la duración de todos los Work Tasks, que a su vez forman Building Blocks, y de
sus interdependencias, pueden ser calculadas las duraciones de los Building Blocks. A su vez, de estos
se podrá calcular la duración de las Features.

El resultado de un Work Task serán una o varias nuevas Especificaciones Técnicas (TS) o Informes
Técnicos (TR) o una o varias solicitudes de cambio (CR).

21
El término genérico utilizado por 3GPP para abarcar los Study Items, Features, Building Blocks y Work
Tasks es Work Item. Todo los Work Items, independientemente de la clase que sean (Features,
Building Blocks o Work Tasks) requieren de:

 Una definición concreta del contenido, es decir, un alcance.

 Una planificación estimada, con los hitos correspondientes para realizar el seguimiento
cuando sea posible.
 Una persona encargada de ser el ponente o rapporteur.
 Un mínimo de cuatro Organizaciones Miembro de 3GPP que apoyen el Work Item y
ofreciéndose para participar de manera activa en su realización.

5.5.1 Creación de un Work Item

Cuando la ampliación de un estándar se considera deseable y necesaria, una delegación podrá tomar
la responsabilidad de dicha ampliación, mediante la propuesta de un nuevo Work Item al TSG o TSG
WG relevante.

 Para nuevos servicios, características o funcionalidades, la propuesta será enviada al TSG

correspondiente. Este TSG asignará un primer responsable y en caso de ser necesario, un
segundo.
 Para ampliaciones de las funcionalidades de un sistema, la responsabilidad será de uno o
varios TSG WG.

El WG responsable deberá estudiar y mejorar el documento del WI propuesto, enviándoselo después

al TSG para su aprobación. Por lo tanto, hasta que el TSG correspondiente adopte una decisión a
cerca de la aprobación del WI propuesto, el WG no deberá realizar ningún trabajo substancial sobre
el mismo. Normalmente, la aprobación de un WI supondrá la creación de una nueva especificación y
una solicitud de cambio o Change Request de las especificación existente.

5.5.2 Tipos de Work Items

Las modificaciones de un estándar podrán ser de dos tipos:

 Nuevos servicios/funcionalidades/funciones que en general afectarán a varias

especificaciones e involucrarán a varios WG.
 Ampliaciones puramente técnicas que afectan a un número pequeño de especificaciones e
involucran a un único o a un número reducido de WG.

Las modificaciones pertenecientes al segundo grupo deberán ser remitidas al WG y posteriormente

al TSG como una solicitud de cambio, antes de presentarla como WI.

22
5.5.3 Inicio, continuación del trabajo y responsabilidades

Una de las primeras acciones a la hora de elaborar un WI es identificar las tareas relacionadas con el
mismo, para posteriormente asignárselas al TSG o WG correspondiente. En la mayoría de los casos,
estas tareas pueden ser divididas en:

 Requerimientos de servicios
 Requerimientos e implicaciones del sistema o de la arquitectura
 Especificación de protocolos

La responsabilidad de los requerimientos de servicios puede ser asignada inmediatamente tras la

creación de WI. En ocasiones, otro grupo puede ser asignado dicha responsabilidad. En todo caso,
aunque la responsabilidad sea compartida, será un único TSG WG el encargado de informar al TSG.

La responsabilidad de los requerimientos e implicaciones del sistema o de la arquitectura también

deberá ser asignada de manera inmediata, aunque esta responsabilidad no será vista de manera
clara hasta que la fase de requerimientos de servicios esté avanzada. Esta responsabilidad solamente
será asignada a un grupo, con el objetivo de garantizar la consistencia de la solución adoptada.

La elección del grupo responsable deberá predeterminar las elecciones técnicas, ya que esta
responsabilidad podrá variar a medida que avance su estudio. El TSG SA deberá mantener la
consistencia global de la arquitectura del sistema, a pesar de las numerosas modificaciones debido al
elevado número de WI. Por lo tanto, el TSG SA deberá de prestar atención a los WI liderados por
otros TSG WG.

El tercer y último tipo de tarea es la especificación de protocolos. A diferencia de los dos tipos
anteriores, en este caso será extremadamente difícil asignar la responsabilidad a un grupo, en
especial en las primeras etapas del WI. La razón de esta dificultad es que la especificación de
protocolos depende de la implementación técnica de los requerimientos de servicios y del sistema.
Por lo tanto, la identificación de nuevos protocolos se realizará en función de las decisiones tomadas
en los requerimientos del sistema y de la arquitectura.

Todos los WI deberán tener un ponente, que será miembro de las compañías que soportan el mismo.
Entre las funciones del ponente destacan:

 Monitorización del progreso del trabajo del WI, en todos los TSG WG.
 Informar al responsable del TSG WG mediante un informe.
 Informar al TSG para que el plan de trabajo sea actualizado en base a los avances realizados.
 Mantener el WI actualizado, con la aprobación del responsable del TSG WG correspondiente.
 Identificar el cumplimiento del WI.

23
5.5.4 Realización del Work Item

A continuación se resumen las fases existentes a lo largo de la realización de un WI.

5.5.4.1 Planificación y categorización de los entregables

El primer paso es realizar una planificación, que debe ser realizada en las etapas iniciales. Como
punto de partida, la planificación deberá incluir como mínimo los siguiente puntos:

 Presentación inicial para un principio de acuerdo sobre los requerimientos de servicios.

 Presentación inicial para un principio de acuerdo sobre requerimientos e implicaciones del
sistema o de la arquitectura.
 Presentación a modo informativo de todos los entregables necesarios.
 Presentación para aprobación de todos los entregables necesarios.

La planificación temporal deberá incluir fechas realísticas para la finalización de cada etapa. Además,
en el listado en el que se resuma el estado del WI también se deberá incluir información relativa a los
todos los documentos del WI.

Después de que una parte substancial de WI haya sido realizada, la dependencia técnica y comercial
del WI deberá ser examinada, al igual que su dependencia con respeto a otros WI. Se deben tener en
cuenta los siguientes aspectos:

 Comparación de escalas de tiempo deseadas y realísticas.

 Aclarar si el WI tiene impacto sobre el Equipamiento del Usuario o User Equipment (UE).
 Aclarar si el WI tiene impacto sobre la arquitectura.
 Aclarar hasta qué punto el WI necesitará ser específico.
 Estudiar si el WI puede ser técnica o comercialmente combinada o agrupada con otros WI.

Si los aspectos enumerados no son tenidos en cuenta en las primeras etapas del WI, existirá un gran
riesgo de que el trabajo sea ineficiente, lo que provocará que el control del mismo sea imposible de
gestionar.

5.5.4.2 Contenido de los entregables

Existen tres tipos de entregables o tipos de informes a generar a lo largo de la realización de un WI:

 Requerimientos del sistema: esta tarea consiste en describir en detalle el objetivo de Work
Item desde el punto de vista de quien recibirá dicho servicio: usuario final, operadores,
proveedores de servicio, etc.

En muchos casos, antes de generar este documento, es necesario realizar un documento

inicial que combine las necesidades de servicios y del sistema o arquitectura, orientado tanto
desde el punto de vista de servicios como desde el de la implementación. Esto será
especialmente necesario cuando se cree una tarea específica dentro del WI para estudiar un

24
 aspecto concreto. En dichos casos, el documento inicialmente generado será posteriormente
utilizado como un punto de partida para el TSG.

El mencionado documento inicial que sentará las bases, deberá perdurar durante un tiempo
dentro del WI, hasta que la especificación desarrollada haya alcanzado un nivel de
maduración importante. Por eso, también podrá ser considerada la opción de generar el
mencionado documento de partida como un Study Item, antes de empezar el trabajo propio
del Work Item.

 Especificaciones técnicas: son documentos que cubren tanto las especificaciones de

arquitecturas como de interfaces. Las necesidades arquitecturales deben de ser identificadas
en una fase temprana, para así poder identificar qué partes del estándar estarán afectadas
por el WI. La coordinación de los requerimientos de la arquitectura y el sistema se realizará
dentro de un grupo de trabajo, mientras que la coordinación de protocolos requerirá de la
coordinación de todos los grupos implicados.

 Especificaciones de test: los cambios realizados al núcleo de red tendrán un impacto

importante, por ello será necesaria la aprobación de especificaciones para realizar los tests,
acordes con los cambios hechos en el núcleo de red.

5.5.4.3 Implementación prematura

El TSG responsable puede decidir que un una funcionalidad es candidata a ser implementado de
manera prematura. Cuando una funcionalidad sea candidata a este tipo de implementación, deberá
de incluir un TR específico para dicha implementación, indicando como se deberá realizar. Este TR no
definirá ningún tipo de nuevo requerimiento técnico, sino que se realizará para ayudar a los
implementadores a identificar qué parte de las especificaciones son relevantes para el WI y como
deberán de ser tratadas en la implementación prematura.

Cuando una funcionalidad de estas características pertenezca a varios WI, el número de TR deberá
de ser minimizado, tratando reflejarlo todo en uno único. Sin embargo, 3GPP permite cierta
flexibilidad respecto a esta indicación.

El contenido del TR de la implementación prematura deberá de ser desarrollado en paralelo al

progreso global de estandarización del WI. Los WG responsables deberán de mantener dicho TR
actualizado.

5.5.4.4 Finalización

Cuando una funcionalidad no pueda ser completada antes de la fecha de freeze de la Release, existen
dos posibilidades:

1. Si la funcionalidad que se propone ampliar es considerada por el TSG como prescindible para
la funcionalidad en su conjunto, podrá ser abandonada o ser pospuesta para la próxima

25
 Release. En tal caso, será necesario crear solicitudes de cambio para eliminar las
modificaciones realizadas a las especificaciones.

2. Si las funcionalidad cuyo trabajo está retrasado, se espera poder acabarlo en un periodo no
superior a pocos meses (en general no más de 2 ciclos de plenarios de TSG), el WG
responsable podrá crear un "informe de excepcionalidad" pidiendo un margen para
completar el trabajo en el periodo mencionado. En este caso, WG responsable se
compromete a darle máxima prioridad a la conclusión de dicho trabajo atrasado.

En el primer caso, el WG será el responsable de realizar los cambios apropiados a la planificación de

3GPP. En el segundo de los casos, el "informe de excepcionalidad" deberá contar información
suficiente para que el TSG encargado tome una decisión razonada, aceptando o rechazando la
propuesta.

5.5.5 Estados de los Work Items

El status de cada Work Item debería de ser monitorizado a lo largo de su ciclo de vida en 3GPP. Dicho
status podrá tomar los siguientes valores:

Estado Descripción Indicación en el Plan de Trabajo

No aprobado por El WI puede aparecer en el Plan

Trabajo en fase inicial, tipo borrador, que
un TSG de Trabajo. Si es incluido, el
todavía no ha sido aprobado por el TSG
campo "nivel de aprobación"
(Not TSG approved) correspondiente.
deberá aparecer en blanco.
El WI debe aparecer en el Plan de
Trabajo. En el campo "nivel de
Trabajo en progreso Este tipo de WI ha sido aprobado por un
aprobación" deberá indicarse el
TSG. El trabajo del WI está en progreso
(work in progress) TSG que lo ha aprobado. El
en el WG correspondiente.
porcentaje de ejecución deerá de
ser inferior al 100%.
Este tipo de WI ha sido aprobado por un
El WI debe aparecer en el Plan de
Congelado TSG. El trabajo del WI ha sido completado
Trabajo. En el campo "nivel de
y ha pasado a estado congelado.
(frozen) aprobación" deberá de ser
Únicamente se permiten cambios
"100%".
esenciales sobre el mismo.
El trabajo sobre este WI ha sido detenido,
sin que el WI haya sido completado. No
se permite realizar más cambios
Detenido El Plan de Trabajo deberá de
utilizando el código de este WI. Los
indicar la reunión del TSG en la
(stopped) cambios realizados utilizando este WI se
que el WI fue detenido.
mantienen en las especificaciones, a
menos que hayan sido eliminados
mediante un CR.
6. Tabla: Estados de los Work Item

26
5.5.6 Modelo de Work Item

El modelo que se describe a continuación es un modelo propuesto por 3GPP como referencia para la
estructuración del trabajo. Sin embargo, no es un modelo de obligado cumplimiento, sino una mera
referencia. Este modelo utiliza el TSG SA como ejemplo, pero es válido para cualquier TSG o
combinación de ellos.

TSG SA es, mediante SA1, el responsable de la definición de las características y servicios de las
especificaciones de 3GPP. Además también es responsable de las descripciones de la stage 1 o etapa
1 (requerimientos), para las características más relevantes. Por otro lado, SA1 tiene la posibilidad de
hacer saber a SA2 las consideraciones que crea oportunas a cerca de la arquitectura y la
implementación, aunque no sea responsable de esa área.

Después, SA2 definirá la arquitectura para las características y el sistema aprobados en SA1,
dividiendo posteriormente dicha arquitectura en Building Blocks. SA2 enviará dichos Building Blocks
al TSG SA para que detalle exactamente los trabajos a realizar. Esta propuestas deberán de ser
revisadas de manera interactiva entre el TSG y sus WG, hasta llegar a un acuerdo. Durante dicha
revisión, SA2 deberá de mantenerse informado del progreso.

Los TSG y sus WG tratan los Building Blocks definidos como una o varias tareas dedicadas, cuyo
resultado final será una nueva especificación, una especificación actualizada, un informe técnico o la
conclusión de que el soporte requerido ya está contemplado en las especificaciones actuales.

El roll de SA2, en cooperación con los TSG y sus WG, será identificar la posibilidad de utilizar algunos
de los Building Blocks para más de una característica. Por lo tanto, parte del trabajo de SA2 será
verificar que todo el trabajo necesario para la creación de una especificación será realizado en 3GPP
sin que diferentes grupos se solapen. Para la consecución de dicho objetivo será imprescindible la
cooperación entre SA2 y el resto de los TSG.

A continuación se propone una guía para la planificación del proyecto:

1. SA1 establece un objetivo.

2. SA2 realiza una primera revisión técnica sobre los objetivos y los comenta.
3. SA2 propone un objetivo de planificación junto con la definición de los Building Block.
4. El TSG y sus WG evalúan dicha propuesta.
5. Si es necesario, SA2 ajustará dicho objetivo en función de la evaluación de los TSG y WG.
6. Se mantiene informados a SA1 y SA2 de la planificación.

Es responsabilidad de SA, SA1 y SA2 asegurar la pronta participación de SA3 en el trabajo, de tal
manera que los posibles requerimientos de seguridad estén alineados con los requerimientos
arquitecturales y de servicios, así como con los TSG y sus WG.

Finalmente, cabe destacar que para que los TSG CT, GERAN y RAN y sus subgrupos puedas realizar
sus tareas de manera paralela, SA2 debería invitarlos para que evalúen el posible impacto de las

27
nuevas características propuestas. Si es necesaria la participación de otros grupos, deberán de ser
incluidos en la planificación general.

F1 F2

Building blocks B1 B2 B3 B4 B5

Transfer to TSGs

Building blocks B1 B2 B3 B4 B5

Work Tasks W1 W2 W3 W4 W5 W6 W7 W8 W9 Wa Wb

5. Imagen: Modelo de Work Item

5.6. Tipos de documentos y estados

En este apartado se describen brevemente todos los tipos de documentos que se presentan en las
reuniones de 3GPP, también llamados contribuciones, los "TDOCs".

Tipo de TDoc Descripción

Agenda de las reuniones, en las que se incluyen la asignación de TDocs a los items
Agenda
de la agenda. Además, incluye la planificación temporal.
Work Plan Listado de Work Items.
Liasion Statement. Documentos recibidos de otro grupo de 3GPP o una entidad
LS in
externa.
Liasion Statement. Documentos entregados por parte de 3GPP o una entidad
LS out
externa.
Pseudo-Change Request. Similar a un CR, pero sin número de CR asignado. Su
pCR
objetivo es proponer un cambio sobre un texto todavía no aprobado.
Similar a un CR, pero sin número de CR asignado. Propone un cambio sobre un texto
Draft CR
aprobado y puede llegar a convertirse en última instancia en un CR.
Es una propuesta formal de solicitud de cambio a un TS o TR. Se le asigna un
CR
número único.
Un grupo de CRs que ha sido aprobado conjuntamente a nivel de WG para ser
CR Pack
presentado ante un TSG.
ToR Terms of Reference. Son los términos de referencia para un TSG o WG.
WID new Descripción de un nuevo Work Item.
WID revised Propuesta de cambio a un Work Item existente.

28
Tipo de TDoc Descripción
SID new Descripción de un nuevo Study Item.
SID revised Propuesta de cambio a un Study Item existente.
WI status
Informe realizado por parte del ponente a cerca del estado del Work Item.
report
WI exception Petición a un TSG para que permita la finalización de un Work Item fuera del plazo
request establecido.
TS or TR cover Portada de un TS o TR.
Draft TS Borrador de un TS completo que será presentado a nivel de TSG para su aprobación.
Draft TR Borrador de un TR completo que será presentado a nivel de TSG para su aprobación.
Report Incluye cualquier informe, típicamente precedente de un TSG o WG.
Discussion Un TDoc que será discutido.
Un TDoc que ha sido preparado como contrapropuesta a otro TDoc. Este tipo de
Response
documtos únicamente suelen ser utilizados en RAN3.
Otro tipo de TDoc que no puede ser clasificado entre ninguno de los anteriormente
Other
mencionados.
7. Tabla: Tipos de TDoc

Además de la clasificación de los tipos de documentos de 3GPP, es interesante conocer los posibles
estados de los mismo. Cabe destacar que no todos los estados pueden ser utilizados en todos lo tipos
de documentos. A continuación se resumen los posibles estados de dichos documentos.

Estado Significado Usado en TDocs tipo...

Reservado Tiene el número de TDoc reservado, pero no está

disponible. Si este estado se mantuviera al final de la Cualquiera
(reserved) reunión, su estado pasará a "No disponible"

Disponible TDox disponible, pero sin tratar. Si este estado se

mantuviera al final de la reunión, su estado pasará a Cualquiera
(available) "No tratado"
Aprobado Conclusión favorable, el grupo en cuestión (TSG o
Cualquiera
(approved) WG) tendrá la última palabra.
Conclusión favorable, la decisión debe de ser
Acordado refrendada por un grupo de mayor responsabilidad
Cualquiera
(agreed) (por ejemplo: la decisión del WG tiene que ser
refrendada por el TSG).
Anotado EL TDoc ha sido presentado, sin resultados
Cualquiera, excepto CR.
(noted) específicos.

Pospuesto EL TDoc ha sido presentado pero no se ha podido

tomar una decisión final. Probablemente será Cualquiera
(postponed) discutido en la siguiente reunión.

29
 Estado Significado Usado en TDocs tipo...
Antes de que la reunión sucediera, el autor ha
Retirado decidido retirar el documento. Cualquiera
(withdrawn)

Tratado El TDoc ha sido presentado pero ningún otro estado Cualquiera, pensado
(treated) es apropiado. principalmente para CR pack
Revisado El TDoc será modificado y presentado en un nuevo
Cualquiera
(revised) TDoc.
Aprobado
parcialmente Utilizado sólo para CR packs. Uno o más CR del pack
ha sido aprobado a nivel de TSG. Otros CRs del pack CR pack
(partially tienen otro estado (revisado, pospuesto, etc.)
approved)
Cualquiera, pensado
Apoyado principalmente para CR con
El grupo piensa que el TDoc es válido pero no ha
más de dos soluciones
(endorsed) llegado a la conclusión de "acordado" o "aprobado".
propuestas o WID que
pertenecen a otro grupo.

Unido Cualquiera, pensado

El TDoc ha sido combinado con uno o más TDocs y
principalmente para pCR,
(merged) presentado en un nuevo TDOc.
draft CR y CR.
Reeditado Indica que el CR aparece sin cambios en otro CR Sólo CRs que son parte de
(reissued) pack. CR pack.
Respuesta a Indica que un LS out ha sido creado en respuesta a
LS in
(replied to) este LS in.
Acordado de
manera Cualquiera, pensado
Acordado, dependiente de la decisión tomada en
condicional principalmente para CR
otro TDoc, probablemente en otro grupo.
(conditionally pack.
agreed)
Aprobado de
manera
Aprobado, dependiente de la decisión tomada en Cualquiera, pensado
condicional
otro TDoc, probablemente en otro grupo. principalmente para CR.
(conditionally
approved)
Sin concluir La discusión sobre esto documento ha comenzado
(not pero no ha finalizado. Típicamente utilizado como un Cualquiera
concluded) estado temporal.
No discutido
No se ha tomado no decisión. Cualquiera
(not pursued)
Rechazado Rechazado debido a falta de compatibilidad con otros
Cualquiera
(rejected) TDoc.
8. Tabla: Estados de TDoc

30
6. Conclusiones

En este documento se han analizado la estructura y el proceso de estandarización de 3GPP partiendo

desde cero, es decir, sin ningún conocimiento previo sobre ello. El proyecto del que es parte este
Anexo I, es el primero que se basado en 3GPP en el seno del grupo de investigación TSR,
perteneciente a la Escuela Técnica Superior de Ingeniería de Bilbao. Por ello, este primer paso ha sido
de vital importancia para el desarrollo del resto del Trabajo de Fin de Máster.

El primer paso ha sido definir qué es exactamente el foro 3GPP, que como se ha visto, es una entidad
colaborativa formada por siete desarrolladores de estándares de telecomunicaciones, que provee a
sus miembros de una estructura estable para producir los informes y especificaciones que definen las
tecnologías de 3GPP. Entre otros aspectos se han definido algunos de las características o funciones
más importantes de este foro de estandarización. El más importante es el desarrollo de las
tecnologías de comunicaciones móviles en sus diferentes generaciones: GSM (2G), UMTS (3G) y LTE
(4G). Además, recientemente ha comenzado el desarrollo de la Release 15, en la que se definirá la
base técnica de la quinta generación, el 5G.

A continuación se ha analizado detalladamente la estructura de 3GPP. Como se ha podido observar

se trata una estructura jerárquica encabezada por el PCG (Grupo de Coordinación de Proyectos). Por
debajo de este se encuentran los cuatro TSG (Grupos de Especificaciones técnicas) que forman 3GPP:
GERAN, RAN, SA y CT. Cada uno de ellos tiene responsabilidades técnicas muy dispares, que en su
conjunto cubren todos los aspectos de un proceso de estandarización, que van desde los servicios
ofrecidos a los usuarios hasta los protocolos de seguridad. A su vez, estos están formados por varios
WG (Working Group) con diferentes responsabilidades.

Para añadir más complejidad a esta la estructura de 3GPP, el foro de estandarización está formado
por varios tipos de miembros, que se clasifican en función de sus responsabilidades y atribuciones.
Las categorías en las que se dividen los miembros, son las cinco siguientes: Socios Organizadores,
Socios Representantes del Mercado, Miembros Individuales, Observadores e Invitados. En cuanto a
los miembros, en su mayoría son organizaciones internacionales (ETSI, ARIB, ATIS,...) o empresas del
mundo de las comunicaciones móviles (Ericsson, Huawei...) que pueden participar en los diferentes
trabajos llevados a cabo por los TSG y los WG en función de sus intereses.

6. Imagen: Proceso de estandarización de 3GPP

31
Además de la compleja estructura de 3GPP, en este documento se ha analizado su proceso de
estandarización (Imagen 6). Teniendo en cuenta que se estudiará una tecnología viva, cuyo
desarrollo se realiza al mismo tiempo que este Trabajo de Fin de Máster, es de vital importancia
conocer los pormenores del proceso de estandarización. Esta comprensión permite al alumno llegar
a cualquier rincón de 3GPP, acceder a los numerosos documentos oficiales presentados por los
miembros de 3GPP y seleccionar los de su interés. Cabe destacar que, como se muestra en el Anexo
II, los documentos y propuestas presentados no se presentan organizados por temas, sino por
reuniones de 3GPP que cubren un sin fin de desarrollos tecnológicos. Este es uno de los factores que
mayor complejidad añade a este proyecto, ya que en cada una de dichas reuniones se presentan
cientos de documentos.

Volviendo a las especificaciones de 3GPP, en este documento no sólo se ha descrito el proceso de

estandarización, sino también todos los aspectos relacionados con ello. Uno de estos aspectos es la
cronología de las Releases, un análisis imprescindible que ha servido para decidir en qué Release se
basará este proyecto, la Release 14. La elección de esta Release se fundamenta en que es la única en
cumplir las dos condiciones previamente establecidas: es una Release en desarrollo (en estado open)
y no está lo suficientemente desarrollada como para tener todos los análisis de eMBMS
prácticamente finalizados.

Otro de los aspectos analizados en profundidad ha sido el de los Work Item de 3GPP, otro de los
pilares fundamentales de este Anexo I. Como se ha descrito en este documento, el trabajo llevado a
cabo por cada uno de los WG afecta a innumerables aspectos técnico de una tecnología. Por ello este
trabajo se fragmenta en trabajos específicos, tras los cuáles se definen los Work Item. En el análisis
llevado a cabo en el Anexo II sobre eMBMS, se identifica un Work Item concreto para las
ampliaciones de eMBMS en LTE. Esta identificación no podría haber sido llevada a cabo sin el trabajo
previo de análisis de 3GPP.

Si bien es cierto que tras la lectura de este documento pueda parecer que la estructura de 3GPP no
es tan compleja como se dice, ha de tenerse en cuenta que todas estas conclusiones han sido
obtenidas tras un minucioso y riguroso análisis del mismo, en muchas ocasiones dificultado por la
falta de información. Por otro lado, es importante destacar que en una estructura tan compleja como
esta existen numerosos aspectos que no son relevantes para este proyecto, pero que han tenido que
ser analizados detenidamente por el alumno para llegar a dicha conclusión. Este documento, además
de sentar las bases para la realización de este Trabajo de Fin de Máster, servirá como cimiento para
los futuros proyectos basados en 3GPP que sean llevados a cabo en el grupo de investigación TSR.

32