Curso

Tecnologas de Voz
En Redes Celulares
De Cuarta Generacin

1
2
El estndar AAA (RFC 2903) proporciona un marco arquitectnico para configurar un sistema de seguridad de red,
con tres funciones independientes y bien definidas: Autenticacin, Autorizacin y Auditoria.
De manera genrica podemos decir que un servicio AAA debe ser capaz de autenticar a los usuarios, dar una
respuesta correcta a las solicitudes de autorizacin de los mismos as como de recolectar datos que permitan hacer
una auditoria sobre los recursos a los que se ha tenido acceso.
Para un proveedor de servicios es necesario el uso de uno o varios servidores que cumplan con estas
caractersticas, para situarse como punto intermedio entre una aplicacin (especficamente el mdulo que se
encarga de autorizar los accesos) y los posibles usuarios.
Autenticacin: Provee el mtodo para identificar a los usuarios (usuario y contrasea, reto y repuesta, etc.) y,
dependiendo del protocolo de seguridad seleccionado, el mtodo de encriptacin a utilizar.
Es decir, autenticacin es el servicio a travs del cual se identifica a un usuario antes de determinar a que servicios
de red o aplicaciones tiene acceso.
Autorizacin: El servicio de autorizacin se refiere a la concesin de acceso a determinadas aplicaciones o
servicios de red para un usuario, basndose en su autenticacin.
La autorizacin tambin puede estar basada en restricciones, por ejemplo: de tiempo, de ubicacin fsica, nmero
de accesos con un mismo usuario, etc.
Este servicio trabaja ensamblando una serie de atributos que describen que es lo que el usuario tiene permitido o
no. Para conocer los atributos de cada usuario, se genera una consulta a una base de datos especfica donde el
resultado es reenviado al servicio AAA. Esta base de datos puede estar localizada localmente en el dispositivo de
acceso a la red (Access Server, enrutador) o puede estar ubicada en un servidor remoto.
Auditora: El servicio de auditoria se refiere al seguimiento o monitoreo del consumo de los recursos de la red por
cada uno de los usuarios autorizados. Esta informacin puede ser usada para propsitos de administracin,
planeacin, facturacin, etc.
La auditoria en tiempo real se lleva a cabo entregando la informacin en el momento utilizando los recursos de la
red o a travs de una red dedicada para este propsito.
La auditoria de respaldo se lleva acabo salvaguardando toda la informacin en un servidor especfico para ser
revisada ms tarde.

3
El protocolo DIAMETER est diseado para ofrecer un marco para los servicios que requieran soporte
de AAA, a nivel de tecnologa de acceso.
El protocolo pretende ser lo suficientemente flexible para permitir que los servicios aadan extensiones
al protocolo DIAMETER bsico para satisfacer sus requisitos. Al contrario que otros protocolos AAA para
tecnologas de acceso (como PPP dial-in, Mobile IP u otros), DIAMETER usa una arquitectura "peer to
peer" en vez del esquema clsico cliente / servidor. DIAMETER se considera un protocolo "peer to peer"
ya que cualquier nodo puede iniciar una peticin en cualquier momento. Los mensajes que un servidor
inicia contra un cliente normalmente son peticiones de abortar un servicio para un usuario concreto.
DIAMETER tambin est enfocado a operar tanto en situaciones locales como de itinerancia (roaming).
Dado que DIAMETER en s no es un protocolo completo, sino que precisa de extensiones especficas
para cada aplicacin referentes a la tecnologa o arquitectura de acceso a la red, no es posible describir
o comparar los detalles del protocolo en cuanto a seguridad y otros aspectos. Por tanto, la descripcin
subsiguiente se ocupar principalmente de los elementos incluidos en el marco comn del DIAMETER
bsico: formato de mensajes, transporte, informe de errores, registro y consideraciones de seguridad.

4
 El RFC 3539 establece los requisitos y recomendaciones para los protocolos de transporte
para protocolos AAA.
En el RFC 3588 se establecen los formatos para los mensajes de transporte, reporte de
errores, accounting y servicios de seguridad que deben ser soportados por todas las
aplicaciones de DIAMETER.
Cada aplicacin que usa DIAMETER es descrita en un RFC.

5
Las AVP son el objeto ms importante del protocolo DIAMETER; se usan para enviar todos los
datos. Algunas AVP las necesita el propio DIAMETER para funcionar, mientras que otras se
usan para transmitir datos propios de las aplicaciones que usan DIAMETER. Las AVP que llevan
informacin especfica de aplicacin se pueden aadir libremente a los mensajes DIAMETER,
siempre y cuando las AVP necesarias estn presentes, y aquellas que se aaden no estn
explcitamente prohibidas por las reglas del protocolo. Las AVP que necesita DIAMETER para
proporcionar sus caractersticas se usan para :
Transportar informacin de autenticacin, con el propsito de que los servidores DIAMETER
puedan autenticar a los usuarios.
Transportar informacin especfica de un servicio entre clientes y servidores, permitiendo a
los participantes decidir si aceptar o no la peticin de acceso de un usuario.
Intercambiar informacin acerca de uso de recursos, que puede ser necesaria para el
registro, planificacin de la capacidad, etc.
Redireccin de los mensajes DIAMETER a travs de una jerarqua de servidores.
Con estas AVP, DIAMETER es capaz de ofrecer los requisitos mnimos para implementar una
arquitectura de AAA slida.

6
 Un Cliente DIAMETER es un dispositivo en la frontera de una red que lleva a cabo control de acceso,
y al cual se suele denominar Servidor de Acceso a la Red (Network Access Server, NAS) o Agente
Forneo (Foreign Agent, FA). Los clientes DIAMETER normalmente generan mensajes DIAMETER
para solicitar servicios de AAA de usuarios.
Un Agente DIAMETER es cualquier nodo que no autentica ni autoriza usuarios de forma local;
ejemplos de tales agentes son los proxies y los relays DIAMETER.
Un Servidor DIAMETER es la entidad que realiza la autenticacin o autorizacin de usuarios
remotos, basndose en perfiles. Es importante destacar que un nodo DIAMETER puede actuar como
Servidor para ciertas peticiones, y como Agente para otras.
Tanto los clientes como los servidores deben soportar el protocolo Diameter Base y las extensiones que
correspondan a las aplicaciones implementadas.
Los agentes DIAMETER se introdujeron para aadir flexibilidad a la arquitectura; sus ventajas
principales son :
Pueden distribuir la administracin del sistema formando grupos configurables, incluyendo el
mantenimiento de las asociaciones de seguridad.
Pueden usarse para concentrar peticiones desde equipos NAS cercanos o distribuidos hacia grupos
de usuarios similares.
Pueden realizar un proceso de valor aadido sobre las peticiones o las respuestas.
Se pueden usar para balancear la carga.
Una red compleja tendr muchas fuentes de autenticacin; los agentes pueden ordenar las peticiones y
redirigirlas al destino correcto.DIAMETER requiere que los agentes mantengan el estado de las
transacciones, es decir, que al reenviar una peticin se guarde el identificador original de salto, con la
finalidad de proporcionar tolerancia a fallos. El agente sobrescribe entonces este campo con un
identificador nico, que se vuelve a cambiar por el original cuando se recibe la respuesta
correspondiente.

7
Agente Relay: Los relays envan y enrutan mensajes a otros nodos DIAMETER en funcin de la
informacin de la cabecera nicamente, como por ejemplo el campo Destination-Realms. Los relays se
usan para agregar peticiones de mtiples NAS's dentro de un rea geogrfica comn. Esto es una
ventaja dado que elimina la necesidad de configurar los NAS con la informacin que de otro modo
necesitaran para comunicarse con los servidores DIAMETER de otros dominios. Es ms, reducen la
carga de configuracin en los servidores que de otra forma sera necesaria al aadir, modificar o eliminar
los NAS. Usando estados de transaccin, los agentes relay pueden enrutar un mensaje de respuesta
hacia exactamente el mismo nodo DIAMETER que envi la peticin al relay. Las nicas modificaciones
que hacen los relays en los mensajes son insertar o eliminar informacin de enrutamiento; no cambian
ninguna otra parte del mensaje.

8
Como las estaciones Relay no hacen ningn procesamiento a nivel de aplicaciones, prestan sus
servicios de retransmisin a todas las aplicaciones Diameter.
La decisin de enrutamiento se realiza usando listas de los realms y peers conocidos
almacenados en una tabla denominada Realm Routing Table.
Varias NAS puede conectarse a un Relay, y de esta forma se pueden crear nuevas NAS sin
necesidad de conocer el resto de la red. De igual forma el Relay facilita la configuracin del
servidor Diameter, ya este ltimo no necesita ser modificado al agregar, modificar o eliminar
algn NAS.

9
Agente Proxy: enruta mensajes DIAMETER usando su Tabla de Enrutamiento DIAMETER. Sin
embargo, son diferentes porque modifican los mensajes de forma sustancial para poder implementar la
aplicacin de polticas. Es importante notar que, aunque los proxies ofrezcan un valor aadido a los
NAS, evitan que los dispositivos de acceso puedan usar seguridad extremo a extremo, dado que la
modificacin de los mensajes hara fallar la autenticacin. Los proxies se pueden usar en centros de
control de llamadas o ISP's de acceso que ofrecen conexiones desde el exterior; pueden monitorizar el
nmero y tipo de los puertos en uso, y tomar decisiones de asignacin y admisin de acuerdo con su
configuracin.

10
Agente de Redireccin:. Se usan para ofrecer resolucin de direcciones de servidor y resolucin de
usuario a servidor dentro de un dominio dado. Los agentes de redireccin usan tablas de enrutamiento
DIAMETER especiales, o tablas de usuarios, para determinar dnde debe dirigirse una peticin
concreta. Estos agentes no se ocupan directamente de los mensajes de peticin y respuesta; slo
proporcionan al nodo fuente la informacin de hacia dnde debe enviarse la peticin. Un ejemplo seria
un agente de redireccin que da servicio a todos los miembros de un consorcio, pero no desea
encargarse adems de reenviar todos los mensajes de un dominio a otro. Este escenario tiene la ventaja
de que no se necesita actualizar la tabla de enrutamiento de todos los miembros cuando la
infraestructura cambia. Los agentes de redireccin no necesitan mantener el estado de las
transacciones.

11
Agente de Traduccin: se usan para traducir entre protocolos distintos como por ejemplo RADIUS y
DIAMETER, o TACACS+ y DIAMETER. Los agentes de traduccin se disean como servidores de
agregacin que se comunican con una infraestructura DIAMETER, a la vez que permiten que los
sistemas embebidos puedan migrar a un paso ms lento.

12
Se recomienda que en lo posible se usen los AVPs definidos, sin embargo, cuando sea
necesario incorporar nuevos valores en la tuple, se debe hacer una solicitud al IANA con una
explicacin de los nuevos valores del AVP. Las consideraciones al respecto se explican en el
RFC 3588. Un procedimiento similar debe seguirse para la creacin de nuevos AVPs.
NEGOCIACIN DE LAS CAPACIDADES
Se refiere a que los clientes y los servidores puedan ponerse de acuerdo sobre las capacidades
que son comunes a ambos, de esta manera se sabe de antemano los servicios que cada
entidad puede manejar; esto garantiza el xito de las sesiones de comunicacin.

13
El cliente tpico de Diameter es un NAS que necesita llevar a cabo los procesos de AAA para
una cierta tecnologa de acceso. El NAS necesita autenticar los terminales conectados a una
red antes de darle acceso a recursos de la misma.
Por ejemplo en una red celular, la BS necesita autenticar al mvil; en ese caso la BS tiene un
NAS que corre Diameter y usa sus servicios para autenticar al equipo mvil. As el NAS es el
cliente Diameter.

14
15
16
Aqu se muestran los Command Codes definidos en el documento base RFC
3588.
En el RFC 3589 el IANA asign al 3GPP los commands codes del 300 al 313 para mensajes
Diameter definidos en el Release 5 del 3GPP.
Los Command Codes se refieren a las diferentes acciones que se deben tomar en una
aplicacin Diameter particular. Todas las abreviaciones todas termina en R (Request) o en A
(Answer). Todos los comandos de REQUEST tienen el bit R en el flag del header del mensaje
DIAMETER puesto a 1 para indicar que es una solicitud, si no es as es porque el mensaje es
una respuesta.

17
18
19
20
21
22
El protocolo DIAMETER no debe usarse sin mecanismos de seguridad; los nodos deben soportar
seguridad IP (IPsec) y TLS. El borrador de DIAMETER sugiere el uso sobre todo de IPsec con claves
pre-compartidas en las fronteras para el trfico intra-dominio, as como que el uso de TLS es la mejor
opcin para el trfico inter-dominio. Por lo tanto, todas las implementaciones de DIAMETER deben
soportar IPsec ESP en modo transporte con cifrado no nulo y algoritmos de autenticacin para
proporcionar autenticacin paquete a paquete, proteccin de la integridad y confidencialidad, y deben
tambin soportar los mecanismos de proteccin contra copia de IPsec. Las implementaciones de
DIAMETER tambin deben soportar el Intercambio de Claves sobre Internet (Internet Key Exchange,
IKE) para autenticacin de los participantes, negociacin de las asociaciones de seguridad y gestin de
claves, usando el Dominio de Interpretacin de IPsec (IPsec Domain of Interpretation, DOI).
La autenticacin de los participantes se debe hacer usando claves pre-compartidas; tambin puede ser
una solucin posible la autenticacin basada en certificados basada en firmas digitales. Adems,
configurar un entorno "peer to peer" no es fcil, el modelo de confianza de cada participante DIAMETER
es esencial para la seguridad. Una posible solucin es usar certificados. En este caso, es necesario
configurar las Autoridades de Certificacin races (CA) en las que confen los participantes DIAMETER.
Estas CA's races deberan ser nica para el uso de DIAMETER, distintas de las CA's en las que se est
confiando para otros propsitos como por ejemplo la navegacin Web. En general, se espera que estas
CA's estn configuradas de forma que reflejen las relaciones de negocio entre la organizacin a la que
pertenece el participante DIAMETER y otras organizaciones. Como resultado, un participante
DIAMETER normalmente se configurar para no aceptar conexiones desde un participante cualquiera.
Cuando los participantes DIAMETER con autenticacin basada en certificados no se conozcan de
antemano, se necesitar realizar un descubrimiento de participantes.
La seguridad extremo a extremo la puede ofrecer una extensin, que no se define en la especificacin
del protocolo bsico. Cuando no haya agentes proxies implicados, puede bastar con usar TLS o IPsec
entre los participantes DIAMETER.

23
24
25
26
27
28
29
30
31
32
33
34
35
Session Initiation Protocol o SIP (Protocolo de Iniciacin de Sesin), es un protocolo de sealizacin definido por
el Internet Engineering Task Force o IETF que permite el establecimiento, la liberacin y la modificacin de
sesiones multimedia (RFC3261). Este protocolo hereda ciertas funcionalidades de los protocolos Hyper Text
Transport Protocol o http, utilizados para navegar sobre el WEB y Simple Mail Transport Protocol o SMTP,
utilizados para transmitir mensajes electrnicos (e-mails). SIP se apoya sobre un modelo transaccional cliente /
servidor como http. El direccionamiento utiliza el concepto Uniform Resource Locator o URL SIP parecido a una
direccin E-mail. Cada participante en una red SIP es entonces alcanzable va una direccin, por medio de una
URL SIP. Por otra parte, los requerimientos SIP son satisfechos por respuestas identificadas por un cdigo digital.
De hecho, la mayor parte de los cdigos de respuesta SIP han sido tomados del protocolo http. Por ejemplo,
cuando el destinatario no esta ubicado, un cdigo de respuesta 404 Not Found esta devuelto. Un requerimiento
SIP esta constituido de headers o encabezamientos, al igual que un mando SMTP.
SIP ha sido extendido con el fin de soportar numerosos servicios tales como la presencia, la mensajeria instantnea
(similar al servicio SMS en las redes mviles), la transferencia de llamada, la conferencia, los servicios
complementarios de telefona, etc
SIP ha sido elegido por el 3GPP para la arquitectura IP Multimedia Subsystem o IMS como protocolo para el
control de sesin y el control de servicio. El reemplazar en el futuro, los protocolos ISUP, utilizado para el control
de llamada en la Red Telefnica Conmutada, y INAP, utilizado para el control de servicio en la arquitectura Red
Inteligente.
El protocolo SIP es solo un protocolo de sealizacin. Una vez la sesin establecida, los participantes de la sesin
intercambian directamente su trafico audio / video a travs del protocolo Real-Time Transport Protocol o RTP. Por
otra parte, SIP no es un protocolo de reservacin de recursos, y en consecuencia, no puede asegurar la calidad de
servicio. Se trata de un protocolo de control de llamada y no de control del medio.
SIP tampoco es un protocolo de transferencia de fichero tal como http, usado con el fin de transportar grandes
volmenes de datos. Ha sido concebido para transmitir mensajes de sealizacin cortos con el fin de establecer,
mantener y liberar sesiones multimedia. Mensajes cortos, no relativos a una llamada pueden sin embargo ser
transportados por SIP al estilo de SMS .

36
37
38
SIP lleva a cabo 5 funciones bsicas:
1. Determinar la localizacin de puntos finales de comunicacin (usuarios)
2. Contactar puntos finales para determinar su disponibilidad para establecer una sesin de
comunicacin multimedia
3. Permitir intercambiar las capacidades de comunicacin multimedia de los puntos finales para
determinar los parmetros a utilizar en una sesin
4. Establecer sesiones de comunicacin multimedia
5. Modificar sesiones de comunicacin multimedia, incluyendo la transferencia y finalizacin de
sesiones, as como la modificacin de los parmetros de la sesin

39
40
41
SIP no es un sistema de comunicacin integrado verticalmente en el modelo OSI, es ms bien un
componente que puede ser usado con otro protocolo para construir una completa arquitectura
multimedia, tal como se muestra en la figura aunque su funcionalidad es independiente de otro
protocolo.

42
43
 Entidades funcionales
SIP define dos tipos de entidades : los clientes y los servidores. De manera mas precisa, las entidades
definidas por SIP son :
El Agente Usuario (User Agent) o UA : se trata de una aplicacin sobre un equipo de usuario
que emite y recibe solicitudes SIP. Se materializa por un software instalado sobre un User
Equipment o UE : una PC, un telfono IP o una estacin mvil UMTS. Pueden actuar como
Agentes de Usuario Clientes (UAC) que son los que se encargan de generar peticiones, y los
Agentes de Usuario Servidores (UAS) que son los que se encargan de responder a las peticiones
solicitadas. Estos deben implementar el transporte tanto sobre TCP como sobre UDP. Los UAs
pueden por si solos, llevar a cabo una comunicacin sin intervencin de los servidores de red, pero
el potencial de SIP se basa en el uso de estos servidores.
Los servidores de red son los dispositivos encargados de procesar las peticiones de los UAs y
generar respuestas. Se dividen de la siguiente forma:
Servidor de Registro o Registrador (Registrar) : se trata de un servidor quien acepta las
solicitudes SIP REGISTER. SIP dispone de la funcin de registro de los usuarios. El usuario
indica por un mensaje REGISTER emitido al Registrar, la direccin donde es localizable
(direccin IP). El Registrar actualiza entonces una base de dato de localizacin. El registrador
es una funcin asociada a un Proxy Server o a un Redirect Server. Un mismo usuario puede
registrarse sobre distintas UAs SIP, en este caso, la llamada le ser entregada sobre el conjunto
de estas UAs.
Servidor de Redireccin (Redirect Server) : se trata de un servidor quien acepta solicitudes
SIP, traduce la direccin SIP de destino en una o varias direcciones de red y las devuelve al
cliente. De manera contraria al Proxy Server, el Redirect Server no encamina las solicitudes SIP.
En el caso de la devolucin de una llamada, el Proxy Server tiene la capacidad de traducir el
numero del destinatario en el mensaje SIP recibido, en un numero de reenvi de llamada y
encaminar la llamada a este nuevo destino, y eso de manera transparente para el cliente de
origen; para el mismo servicio, el Redirect Server devuelve el nuevo numero (numero de reenvi)
al cliente de origen quien se encarga de establecer una llamada hacia este nuevo destino.
Servidor Proxy (Proxy Server) : el recibe solicitudes de clientes que el mismo trata o encamina
hacia otros servidores despus de haber eventualmente, realizado ciertas modificaciones sobre
estas solicitudes.
Generalmente, un servidor SIP implementa ms de un tipo de servidor, puede llegar a ser servidor
Proxy y de Registro o servidor de Redireccin y de Registro. En cualquier caso debe implementar el
transporte tanto sobre TCP como sobre UDP.
Los mensaje SIP son archivos de texto plano basadas en la codificacin UTF-8, cuyo formato
consta de una lnea de inicio, uno o ms campos de cabecera (header fields) y una lnea vaca
indicando el fin de la cabecera. Adems se puede agregar de forma opcional el cuerpo de mensaje,
utilizando el protocolo SDP.

44
Los mensaje SIP son archivos de texto plano basadas en la codificacin UTF-8, cuyo formato consta de
una lnea de inicio, uno o ms campos de cabecera (header fields) y una lnea vaca indicando el fin de
la cabecera. Adems se puede agregar de forma opcional el cuerpo de mensaje, utilizando el protocolo
SDP.
Los mensajes SIP pueden ser de dos tipos:
Solicitudes SIP: estos mensajes son emitidos por los UACs y constan bsicamente de tres bloques:
Request Line + Cabeceras + Cuerpo. La lnea Request Line tiene el siguiente formato:
Mtodo SP Request-URI SP SIP-Version CRLF
Donde SP es el carcter espacio, y CRLF es retorno de carro.
Respuestas SIP: estos mensajes son emitidos por los UASs o servidores y se utilizan para responder
a un mensaje de solicitud SIP, constan de tres bloques al igual que los mensajes de solicitud: Status
Line + Cabeceras + Cuerpo. La lnea Status Line tiene el siguiente formato:
SIP-Version SP Status-Code SP Reason-Phrase CRLF
Cabe sealar, como fue mencionado anteriormente, que para ambos tipos de mensajes el cuerpo del
mensaje es opcional, pudiendo tenerlo o no.
Sintaxis:
Los nombres de campos y algunas claves (por ejemplo tipo de medio) son case-insensitive
Todo el resto es case-sensitive
Los espacios en blanco no importan excepto en la primera lnea
Las lneas pueden desdoblarse
Los campos de mltiples valores pueden combinarse como una lista con comas

45
Los mtodos del protocolo base SIP son:
El mtodo INVITE es usado con el fin de establecer una sesin entre UAs. INVITE corresponde al
mensaje ISUP IAM o al mensaje Q.931 SET UP y contiene las informaciones sobre el que genera la
llamada y el destinatario as como sobre el tipo de flujos que sern intercambiados (voz, video,...).
Cuando un UA que emiti el mtodo SIP INVITE recibe una respuesta final a la invitacin (ejemplo :
200 OK), l confirma la recepcin de esta respuesta por medio de un mtodo ACK. Una respuesta
del tipo busy o answer es considerada como final mientras una respuesta tipo ringing
significando que el destinatario ha sido avisado es una respuesta provisoria.
El mtodo BYE permite la liberacin de una sesin anteriormente establecida. Corresponde al
mensaje RELEASE de los protocolos ISUP y Q.931. Un mensaje BYE puede ser emitido por el que
genera la llamada o el que la recibe.
El mtodo REGISTER es usado por una UA con el fin de indicar al Registrar la correspondencia
entre su Direccin SIP y su direccin de contacto (ejemplo : direccin IP).
El mtodo CANCEL es utilizado para pedir el abandono de la llamada en curso pero no tiene
ningn efecto sobre una llamada ya aceptada. De hecho, solo el mtodo BYE puede terminar una
llamada establecida.
El mtodo OPTIONS es utilizado para interrogar las capacidades y el estado de un User Agent o
de un servidor . La respuesta contiene sus capacidades (ejemplo: tipo de media siendo soportado,
idioma soportado) o el hecho de que el UA sea indisponible.

46
El mtodo INFO (RFC2976) permite transferir informaciones de sealizacin durante la llamada. Entre los
ejemplos de informacin se encuentran los dgitos DTMF, las informaciones relativas a la tasacin de una
llamada, las imgenes etc...
El mtodo UPDATE (RFC3311) permite a un terminal SIP actualizar los parmetros de una sesin
multimedia (ejemplo : flujo media y sus codecs). El mtodo UPDATE puede ser enviado antes de que la
sesin sea establecida. UPDATE es entonces particularmente til cuando se trata de poner al da los
parmetros de sesin antes de su establecimiento, por ejemplo en puesta en espera del destinatario.
Las respuestas finales 2xx, 3xx, 4xx, 5xx y 6xx a un requerimiento INVITE son satisfechas por el
requerimiento ACK mientras las respuestas provisorias de tipo 1XX no son satisfechas. Ciertas respuestas
temporarias tales como el 180 Ringing son criticas y su recepcin es esencial para la determinacin del
estado de la llamada, entre otros durante el proceso de interconexin con la RTCP. El mtodo PRACK
(RFC3262) ha sido definido con el fin de satisfacer la recepcin de respuestas temporarias de tipo 1XX.
Una entidad SIP puede suscribir a un evento con el fin de ser notificada de su ocurrencia. El mtodo
SUBSCRIBE permite la suscripcin mientras el requerimiento NOTIFY es utilizado con el fin de notificar
(RFC 3265). El mtodo PUBLISH permite publicar su estado.
El mtodo REFER (RFC3515) reenva el receptor hacia un recurso identificado en el mtodo. REFER permite
emular distintos servicios o aplicaciones incluyendo la transferencia de llamada. Contemplamos T1, la
entidad que origino la transferencia, T2 la entidad transferida y T3, el destinatario de la transferencia. La
transferencia de llamada permite a T1 transformar una llamada en curso entre T1 y T2 en una nueva llamada
entre T2 y T3, elegida por T1. Si la transferencia de llamada se lleva a cabo, T2 y T3 podrn comunicar
mientras que T1 no podr seguir dialogando con T2 o T3.
El mtodo MESSAGE (RFC 3428) ha sido propuesto como extensin al protocolo SIP con el fin de permitir la
transferencia de mensajes instantneos. La mensajera instantnea o Instant Messaging o IM consiste en
el intercambio de mensajes entre usuarios en seudo tiempo real.
Este nuevo mtodo hereda de todas las funciones ofrecidas por el protocolo SIP tales que el enrutamiento y
la seguridad. El requerimiento MESSAGE puede transportar varios tipos de contenidos basndose sobre la
codificacin MIME.

47
Despus de haber recibido y interpretado un requerimiento SIP, el destinatario de este requerimiento
devuelve una respuesta SIP. Existen seis clases de respuestas:
Clase 1xx : Informacin, el requerimiento ha sido recibido y est en curso de tratamiento
Clase 2xx: xito, el requerimiento ha sido recibido, entendido y aceptado.
Clase 3xx: Reenrutamiento, la llamada requiere otros procesamientos antes de poder determinar si
puede ser realizada.
Clase 4xx: Error requerimiento cliente, el requerimiento no puede ser interpretado o servido por el
servidor. El requerimiento tiene que ser modificado antes de ser reenviado.
Clase 5xx: Error servidor, el servidor fracasa en el procesamiento de un requerimiento
aparentemente valido.
Clase 6xx: Fracaso global, el requerimiento no puede ser procesado por ningn servidor.

48
Una sesin, dentro del marco de las telecomunicaciones podra definirse como: una serie de
interacciones entre dos o varios extremos de una conferencia, durante las cuales se negocian
diferentes parmetros de la comunicacin. Normalmente una sesin no implica que se tengan que
usar protocolos orientados a conexin, sino que todos los intercambios de informacin, ya sean a travs
de una o varias conexiones o por datagramas, seguirn las pautas y caractersticas negociadas en el
establecimiento de la sesin.
Ejemplo: Una Sesin multimedia de RTP puede implicar el establecimiento de varias sesiones RTP para
cada tipo de contenido.
Segn el IETF, aparece una definicin de Sesin Multimedia en la RFC del protocolo SDP:
Una sesin es un conjunto de transmisores y receptores de contenidos multimedia y los flujos de
datos que fluyen desde los transmisores a los receptores. Una conferencia multimedia es un
ejemplo de una sesin multimedia. (RFC 2327).
El uso de sesiones no es algo fortuito. Como ya se ha visto, la complejidad de las actuales
comunicaciones por Internet requieren un proceso ms cuidadoso y detallado que una simple conexin
TCP.
Una sesin consta de varias fases: establecimiento, transferencia de datos y liberacin.
Sin duda es en la negociacin durante el establecimiento donde se pone ms nfasis, si bien, el control
durante el periodo en el que se transmiten los datos es importante, sin un adecuado establecimiento, se
puede realizar un derroche de recursos o incluso el no poder establecerla siquiera.

49
When two devices communicate with one another, they exchange a set of messages (referred to as transactions).
For example, a cell phone originating a call to another cell phone would send an INVITE to the other phone
requesting a connection be made. The recipient of the INVITE will determine whether to accept or reject the
transaction.
If the cell phone chooses to accept the invitation to a session, then it will send a response to the request and
exchange other messages, entering into a dialog with the other device. The dialog then becomes a logical
connection between the communicating entities for the purpose of exchanging SIP messages regarding a session.
Each user agent establishes its own dialog with the user agent client (the requestor). The dialog is then used by the
user agent to maintain the status of the dialog and associated sessions. The session is not the same as a dialog,
since a session can involve multiple user agents communicating with one user agent client.
In other words, the dialog is established between each entity involved in the same session as depicted in the Figure.
The illustration shows the user agent client with a dialog established with multiple user agent servers, exchanging
session control information for the same session (as would be the case in a conference call).
As can be seen in the illustration, the user agent client can now delineate transactions between each of the entities
participating in the same session. This allows the UAC to correlate responses from each individual UAS and treat
each one independently even though they are all participating in the same session. Each dialog requires a dialog ID,
which is derived from the SIP headers. When the UAC sends a request for a session, it will expect a response. In
that response will be required headers (as we will discuss in a moment). The response must contain the TO, FROM,
and CALL-ID headers. The TO and the FROM headers will include the TAG parameter. The TAG parameter is used
by each user agent for correlating requests with responses, but it is also used for calculating the dialog ID.
The dialog ID then becomes unique for the UAC and each of the UASs. In other words, the UAC creates its own
dialog ID, while each of the UASs will create its own unique dialog ID. This is not communicated to other entities,
since the use of the dialog ID is local (used by the user agent).
Note that a dialog ID cannot be determined until the UAC receives a 2xx response back from each of the UASs. This
is because the TO header does not actually contain the TAG parameter until the response is generated by the UAS.
Remember that the TAG is used by the UAS for correlation of responses (more on that when we discuss the various
message headers and their parameters).

50
So in summary, a UAC will generate a SIP message and send it to one or more UASs. Each UAS will
then answer the UAC by sending a response message. The response message contains at a minimum
the TO, FROM, and CALL-ID headers, which are used in creating the dialog ID. Once all of these are
done, the dialog is considered established, as depicted in the call flow shown in this figure. It also shows
a handshake. Once the dialog has been established and the acknowledgment is received, the handshake
sequence between two entities has been completed. This marks the beginning of a session where bearer
traffic is exchanged.
A session cannot begin without completion of a handshake between the two entities. Think of the
handshake as an agreement between all involved user agents to engage in the transfer of bearer traffic.
To establish a session, a sequence of messages must be exchanged between all involved parties. This
sequence of messages consists of an offer and an answer. The offer is established by the user agent
client wishing to begin a session. It must contain all of the data necessary to establish the session and
transfer bearer traffic.
The offer therefore carries the description of the session, including the encoding methods, required media
support, and any other support required for the session at the receiving end. The offer may or may not be
contained in the initial request, but carried in a subsequent response.
The offer is then followed by an answer. Each entity involved in the session must provide an answer to
the offer. The answer in essence is accepting the offer and acknowledging it can support the
requirements specified in the offer. If no requirements were specified in the offer, the answer may contain
requirements.
The offer and the answer use specific methods. A method in SIP parlance is a message type. There are
two forms of SIP messaging: the SIP request and the SIP response.

51
This is one dialog
100 response (Trying) Quenches retransmissions of the initial message (INVITE)
This stops the UAC from resending the initial request thinking it wasnt received.
Matches the INVITE transaction.
The User Agent Server (UAS) has added the To: tag
A 101-199 provisional response can establish an early dialog

Cseq (Command Sequence)

This is one dialog
200 response Dialog established and confirmed
This is one dialog
BYE matches dialog (tag) but is a new transaction from DN 5103005700
Note that the From: & To: fields never change for the dialog no matter the source or
destination of the request
The branch identifies this transaction
The response also has the same To, From, Call-ID and Cseq
Cseq: It contains an integer and a method name. When a transaction starts, the first message is
given a random CSeq. After that it is incremented by one with each new message. It is used to
detect non-delivery of a message or out-of-order delivery of messages.
CANCEL transaction has one other rule, the Via branch matches the request being cancelled
One other note the order of the fields does not matter, so long as they are different field names
Requests
A request is sent from a SIP client to a SIP server. A SIP server could support any type of function. Remember these
are logical entities rather than physical entities. The request format consists of a start line containing the following
information:
METHOD (space) REQUEST URI (space) SIP VERSION (crlf)
The METHOD identifies the type of request being sent.
Addresses in a SIP network are referred to as Universal Resource Identifiers (URIs). These are very much like
Universal Resource Locators (URLs) used in the HTTP protocol (the Web addresses we have come so familiar
with). The REQUEST-URI is used for routing the SIP message through the network, so therefore it contains the
address of the next hop. Last but not least in the request message is the SIP VERSION. This identifies the version
of SIP that is being supported by the transaction user that created the SIP message. This allows the receiving entity
of a request to understand what version of SIP was used to create the request, so it can decode the request
properly. Following the start line in a request are the message header (or headers), a carriage return line feed
(CRLF), and an optional message body. So the request identifies the type of session that is being requested by the
user agent client. The requirements for supporting the session (such as the type of media, how it is encoded, and
what other methods must be supported) are included as part of the request.
There are requests that are specific to certain types of sessions. A good example of this is the MESSAGE method,
which carries a text message. No session and dialog are needed, since the contents are provided in the message
body. The recipient can choose to accept the message or not through a response.
Responses
Responses are sent by a SIP server to a client in response to a request. Responses are identified by the receiving
entity by the status line, which is formatted differently than a request start line. The response status line contains the
following information:
SIP VERSION (space) STATUS CODE (space) REASON PHRASE (crlf)
Think of the response status line as informing the user of the request status. The STATUS CODE is a numerical
code used by the receiver to identify the status of a request. It is a three-digit code followed by a text field that
provides a textual description of the code for us humans that are number-challenged. While the various network
entities will be able to interpret the numeric code, there is no reason as a technician or engineer to memorize these
codes, since they are always followed by the REASON PHRASE, which is always in plain English.
57
Campos de encabezado SIP

58
 Descripcin de los encabezados
Header fields contain detailed information about the request or the response. This includes the destination and
origination addresses of some requests, as well as routing information. The header field uses the form of
header name: header value
There can be spaces between the header name and the header value fields, so you may encounter implementations
of this; however, the standards highly recommend against the use of white space between the header name and the
header value, recommending the use of a single space between the two.
There can be multiple appearances of the same header name within one request, such as the ROUTE header
name. When this appears multiple times, the order is not specific, but it is recommended that routing should be listed
in the top of the request so that the routers and proxies in the network are able to parse these messages quickly.
There can be mixed orders, though, for example:
ROUTE: <russell@tekelec.com>
ROUTE: <jones@tekelec.com>
SUBJECT: Lunch at 1:00
ROUTE: <smith@tekelec.com>
The point is, while the standards do recommend using some form of order in the headers, it is not required, and the
header names can be in a mixed order. The receiving entities should still be able to process these requests even
though the order is mixed (although it may slightly slow the processing of the request).
Another worthy note is that the contents of the header field are not case sensitive. The exception to this rule is when
a value is part of a quotation. This would be the case when text, for example, is to be displayed on a subscriber
device. In this event, the text is displayed exactly as it is found within the header field. There are two classifications
for header fields: request header fields and response header fields. Some header fields only make sense in a
request, for example, and therefore are ignored if they are received as part of a response.
Header fields can be represented in both long form and abbreviated form. The RFC has defined short, abbreviated
versions of each of the header fields for use where bandwidth is a concern. The abbreviated versions are provided
with each of the header field descriptions that follow.
Accept The ACCEPT header field identifies the format of the request contents. For example, in the next example,
the accept header field indicates that the format for the request at the application layer is SDP, with HTML text.
Accept: application/sdp;level=1, application/x-private, text/html
When this header field is not present, the default value will always be SDP.
Accept Encoding The meaning of this header field is almost identical to that of ACCEPT. This header field restricts
the coding for the header field. The default value of this header field if absent is no encoding. An example of this
header field is:
ACCEPT ENCODING:gzip
Accept Language This header field is used when a language other than English is to be used for the status codes,
SDP, or status responses. When this header field is absent, the default is that all languages are accepted by the
server. Here is an example of the
ACCEPT-LANGUAGE header field:
ACCEPT LANGUAGE: da, en-gb;q=0.8
Alert Info This header field is typically used within an INVITE request to indicate the use of an alternate ringtone
(the ringing tone used to alert the called party) to the server; however, it can also be used to indicate a different
ringback tone. If this appears within the 180 RINGING response, this header field indicates the use of an alternate
ringback (the tone that the calling party hears). It also provides the location of the file providing the audio ringtone or
ringback tone. Here is an example of an ALERT-INFO header:
ALERT INFO: <http://www.ringtones.com/sounds/clapping.wav>
Allow This is used by user agents to indicate the methods supported by the user agent. Whenever the ALLOW is
present, all methods supported must be included or it will be interpreted that the absent method is not supported.
However, the absence of an ALLOW does not mean that no methods are supported. For example, a query to a
server to determine the servers capabilities may result in the response containing:
ALLOW: INVITE, ACK, OPTIONS, CANCEL, BYE

59
Authentication Info This is used as part of the authentication process and is carried within a 2xx response. It is
used by the device to provide its authentication credentials, usually during the registration process. In an IMS
environment, this is used as part of the authentication/registration process whenever a mobile is activated or
changes locations.
Here is an example of how this header field is used:
AUTHENTICATION INFO: nextnonce="47364c23432d2e131a5fb210812c"
Authorization This header field contains the credentials of a user agent. These are provided typically when the
device is challenged by a SIP registrar. The credentials are known to the device and the network provider only, so
that fraudulent access to ones subscription is prevented. This next example shows the syntax supported for this
header field:
AUTHORIZATION: Digest username="Travis", realm="raleigh.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
Call ID The CALL-ID header field contains a unique identifier for INVITEs and REGISTERs. A conference call could
carry multiple CALL IDs, one for each INVITE.
It is the CALL ID that allows a server to keep track of each individual session. Any subsequent messages relating to
the same session must carry the same CALL ID. If another session is established, a different CALL ID is created for
that session, even if the same parties are involved.
CALL ID: f81d4fae-15apr-11d0-a765-00a0c91e6bf6@raleigh.com
i:f81d4fae-15apr-11d0-a765-00a0c91e6bf6@192.0.2.4
Call Info This is a way for SIP to provide additional information about either the called party or the calling party. For
example, the calling party may send an ICON as a representation of themselves, along with a business card (using
vcard, for example) to the called party. The header field can be sent in either a request (in which case information
about the calling party is sent) or in a response to a request (in which case information about the called party is
included).
There is potential risk in using this header field. Malicious use of this header field could result in questionable content
being sent to a calling or called party. The standards recommend use of this header field only if the source can be
authenticated and is a trusted source.
The next example shows what this header would look like when sending both an image such as an icon and a vcard
for contact information.
CALL INFO: <http://wwww.tekelec.com/travis/photo.jpg>;purpose=icon,
<http://www.tekelec.com/travis/>;purpose=info
Contact The CONTACT field is used to identify the URI, or the TEL URI, or the MAIL URL that should be used to
contact the user agent sending a request, associated with an established dialog. Depending on the request type,
multiple URIs could be identified in the CONTACT field. The only stipulation is that the URI should be the same as
the TO field. If the TO field contains a SIPS URI, then the CONTACT field should also be a SIPS URI.
When there are multiple URIs in the CONTACT field, the q parameter is used to indicate which order the URIs
should be used. For example, the lowest numbers could be processed first, in sequential order. A redirect server
uses the CONTACT field to indicate alternative URIs if requests are being redirected to another address.
It should also be noted that when the CONTACT is being used, responses could be routed directly to the address
provided in the header, in essence bypassing the proxies used to originally reach the device. In cases such as IMS
networks where strict routing is implemented, the CONTACT header simply provides additional addresses for the
device; it is not used for routing purposes.
The EXPIRES parameter indicates in seconds when a URI provided in the header is to expire. If the value is 0,
then the URI is to expire immediately. A user agent can renew a registration prior to expiration by sending a
REGISTER message to the same registrar before the URI expires. A list of sessions can be renewed with one
REGISTER message as long as the sessions all belong to the user agent, using the same CALL ID.
CONTACT: sip:travis@nc1lt2172b.raleigh.com
The Contact header field may contain a feature tag, which can be used to indicate the capabilities of the device
identified by the Contact URI. For example, the feature tag isfocus is used to indicate that the URI in the Contact
header field is a Conference URI, and that the dialog is associates with a focus. A focus is a SIP user agent that
hosts a particular instance of a conference, called a bridge or MCU in other protocols. The presence of the isfocus
feature tag can be used by a SIP user agent that supports advanced conferencing features to invoke certain call
control operations or subscribe to the conference package.

60
Content Length The LENGTH field indicates the total length of the message body, indicated by a decimal value
indicating the number of octets. Any number is a valid value, but zero can only be used if there is no message body.
CONTENT-LENGTH: 265
Content-Transfer-Encoding The CONTENT-TRANSFER-ENCODING is used when tunneling a SIP message
within the message body of another SIP message. The header identifies the encoding used for the tunneled portion
of the SIP message.
CONTENT-TRANSFER-ENCODING: base64
Content Type The CONTENT TYPE header is used to identify the content media type. There must be a value in the
CONTENT TYPE field if there is a message body. There can, however, be a CONTENT TYPE field and no message
body (indicating an empty voice file, for example).
CONTENT-TYPE: application/sdp
CSeq This field is used to indicate the sequence order of a message within a dialog, in the event that messages are
received out of sequence. The sequence number is followed by a method (such as INVITE). This field is also used to
differentiate requests from retransmissions.
CSeq: 3411 INVITE
Date This header is used when devices are deriving local times and dates from the network. The device registers
with the network and receives the DATE header in a response, which it then uses to set its own date and time. This
is commonly used in many cell phones today.
DATE: Mon, 10 Aug 2007 14:33:03 GMT
Error Info This header is used to provide additional information regarding an error response, and is used by the
endpoint to provide notification to the user. For example, the error code itself could be displayed on the users
device, while the header provides the location of a recording to be played back to the user. This provides more
flexibility to the operator as to how to implement user notification and service tones/recordings.
SIP/2.0 404 Not Found
Error-Info: <sip:out-of-service-recording@raleigh.com
Event Used with the NOTIFY method, the EVENT header identifies the event that caused for a change in
registration status. For example, if a Presence server has subscribed to event notification, when a subscriber device
changes its registration (moves to another location resulting in a new IP address being assigned), the NOTIFY
method sends the new registration information. The EVENT header then provides the reason (reg, for registration)
the registration was changed.
EVENT: reg
Expires The EXPIRES header is used for multiple purposes. It allows the sender to express when an event (such as
a users registration) is to expire. For example, when the EXPIRES header is sent within a REGISTER message, the
EXPIRES value indicates when the registration is to expire. The user must then register again prior to the EXPIRES
value. The use of this header varies upon its implementation. It is flexible in that it can be used to express any
expiration (not just registration), depending on the method or request it is contained within. The value is expressed in
decimal as seconds.
EXPIRES: 3
From The FROM header provides the address of the message sender. This is the logical identity, not the physical
identity, and therefore must not be the IP address of a message originator. This field is used in many different ways,
including rejecting or
accepting calls according to user input. The value provided in this header is for human consumption only and is not
used by the network for any purpose. A device, however, may display the contents as a name display, and the user
can then determine whether he or she wants to accept or reject the session.
It should be noted that this is not a secure or authenticated value. For this reason, it should not be a trusted header.
The value provided in this header could easily be spoofed, leading users to accept content or other malware from a
rogue source.
There is also a tag parameter that is added by the user agent client (UAC) when the message is created. The tag
value must be a unique value to the UAC so that it can correlate this message with responses.
The FROM header may also contain a display name, although this is not a requirement. Likewise, the identity can be
hidden, in which case the UAC will insert Anonymous or some other generic identity, as well as an invalid domain
so as to hide the source of the message.
FROM: "Travis Russell" <sip:travisruss@aol.com>;tag=9hz34567sl

61
In-Reply-To This header is used for applications where calls that previously were unanswered are returned. The
content of this header is the CALL-ID of the call being returned. It could be used by call distributors and other
applications where users want control over the calls that are accepted and returned. It can also be used by voicemail
systems and other like applications where the user misses a call and wants to return the missed call.
IN-REPLY-TO: 89222@aol.com
Max Forwards is used to prevent looping of messages. When a message is created (either a request or a
response), this header is set to 70. As the message passes through each proxy in the network, the value is
decremented by 1, until the value reaches 0. If a proxy receives a message with a MAX-FORWARDS value of 0, the
message is discarded.
This can also be used by systems that are measuring or monitoring the network to troubleshooting routing of SIP
messages. By measuring the value of the MAXFORWARDS header at various points in the network, one could
derive where looping is occurring and identify proxies that are causing circular routing.
MAX-FORWARDS: 70
Min Expires This header identifies the minimum time allowed for the expiration of a value such as CONTACT within
a proxy, such as a registrar (the S-CSCF in the IMS). The value is a decimal number expressed in seconds.
MIN-EXPIRES: 60
MIME Version This header identifies the version of MIME used within the message body if there is content provided
in MIME format. This allows the receiving device to properly render or decode the content as received.
MIME-VERSION: 1.0
Organization This can be used by the operator to identify the name of the operator and domain (Jacks Telephone
Company for example). It can also be used by the user to identify the name of his or her company for display
purposes. It identifies the name of the organization that initiated the request (or response) and is used for
informational purposes (such as display on a device).
ORGANIZATION: Jack's Telephone Company
Privacy This header is used to identify when subscribers wish to hide their identity from other networks. This could
be the case when a subscriber wishes to maintain secrecy for certain communications, but of course it can be used
for illegitimate purposes as well. The header is provided in the specifications for legitimate purposes, allowing
subscribers to provide a different identity in the REQUEST-URI than they do in the TO header. The TO header of
course is displayed to the calling party, while the REQUEST-URI is used by the network for routing and
authentication purposes.
PRIVACY: ID
Proxy Authenticate The PROXY-AUTHENTICATE header is provided as a challenge by a proxy (such as an
application server or a registrar). When a request is sent by the device, the proxy can send a 407 Proxy
Authorization Required response, containing this header. The device then must return a response containing the
PROXY-AUTHORIZATION header, with the proper credentials. This could be used in cases where the operator
wishes to authenticate a user every time the user accesses its call control server, to prevent unauthorized access to
a server used to define call treatment and voicemail services by the subscriber.
PROXY-AUTHENTICATE: Digest Realm="tekelec.com,
domain= "sip:Verizon.com", qop="auth",
nonce= "a73dd646abc898763fbade98129e763547",
opaque= "", stale= FALSE, algorithm= MD5
Proxy Authorization is used when a device is authenticating itself with the challenging proxy in response to a 407
Proxy Authentication Required. It is within this header that the user provides his or her credentials, known only to the
device and the network provider. None of the data provided for authentication is human-consumable data. This is
data that is created using the various algorithms and keys that are provided by the network provider at subscription
time, and embedded within the device (usually within the UICC or SIM card). This process is different than
registration, where the network registrar performs the authentication. This procedure and its associated headers
provide the operator with an added measure of security to prevent unauthorized access to network services, even
after registration. The use of this header is implementation specific and is not required, but it does add an additional
level of security for the operator and an additional layer of protection to select services housed on application
servers.
PROXY-AUTHORIZATION:Digest username= "Travis", realm= "Verizon.com",
Nonce= "c60f3082ee1212b402a21831ae
Response= "43536ff4355tcc45567"

62
Record Route is used for strict routing within a SIP network. As a request is routed through the network, each proxy
inserts this header along with its address into the request. When the request is received by the destination, it uses
the RECORD-ROUTE to determine the route for a response.
Think of the RECORD-ROUTE as the headers used to create a routing list for a subscriber device. One use for this
is to prevent highjacking of sessions when routing is enforced. When a device registers with the network, the
RECORD-ROUTE is used as the REGISTER is routed through the network, and the various entities used to route
the REGISTER to the registrar enter their addresses prior to forwarding to the next entity.
When the registrar receives the REGISTER, it then uses the RECORD-ROUTE headers to create a route list for the
user. All responses are then sent using the same route as recorded. This route is stored as part of the registration,
so that all subsequent requests and responses use the same route.
This form of strict routing ensures that a man-in-the-middle attack cannot be used to hijack a subscribers
registration, for example. It ensures that all requests and responses are sent through the same path used for the
registration to reach the user.
Reply To is inserted by a user device upon receipt of a request. It is used to communicate the direct address of the
device for all subsequent responses and requests throughout a dialog. This in essence would then allow responses
to bypass the various proxies within the network and allow routing directly to the device. Within an IMS domain,
there may be concerns about routing directly to a device, bypassing the Call Session Control Function (CSCF) within
the network. In fact, this form of loose routing is not defined within the IMS. The IMS procedures call for strict routing
to ensure that all requests and responses always follow the same path used during registration. The REPLY-TO
header is still supported within the IMS, but its use is not necessarily for routing of responses. It is simply used to
identify the direct address of the device, but requests and responses are still routed through the CSCF entities within
the network. Other proxies may be bypassed, however.
REPLY-TO: Travis Russell sip:travisruss@aol.com
Route This header is used along with the RECORD-ROUTE header when strict routing is implemented (as is the
case in the IMS). When a request is being sent, the RECORD-ROUTE header records the addresses of each of the
entities in the call path. The response then inserts these addresses in the ROUTE headers (there are typically
multiple headers).
The headers are listed in the order of the route. In other words, the addresses are shown in the same order they are
routed through. The routers then use this for routing the responses to the next hop in the network.
ROUTE: sip:Raleigh@bellhead.com
Subject This is much like the subject line in e-mail. It is provided as a means of sharing additional information about
the session for display to the user. For example, if used for an emergency broadcast feature, the SUBJECT header
would contain the actual alert message (such as Thunderstorm warnings for Johnston County), while the
PRIORITY header would contain the priority for the session. The SUBJECT header can also contain text displayed
on the end device for a call. The sender may wish to have the message Answer the phone! pop up when the call
begins ringing on the called partys phone (subject to call servers supporting such a function). There are many other
implementations for the SUBJECT header dependent on operator implementation.
SUBJECT: Anyone Home?
To This field identifies the destination for a SIP transaction. Usually this will take the form of a URI, although it can
take many different forms, including a TEL URI. The address may not be the final destination for a SIP message,
though, as user agents have the ultimate responsibility of determining how to interpret this field. The address itself
may be input through a human interface, or it may be provided through some other entity. For example, a user may
select an address from his or her address book, in which case the TO field will be populated by the address book on
the users phone. The address can be interpreted in a number of ways. For example, if the user inputs
travis@tekelec.com, the user agent then assumes that a Domain Name Service (DNS) lookup is required in the
Tekelec domain. The SIP message would then be sent to the domain for address resolution at that DNS. If the user
inputs a TEL URI, the proxy that receives the message would be responsible for interpreting the address and
resolving the address accordingly. Likewise, each network that the request passes through would have the same
opportunity, resolving the address along the way. The TO field is also used to provide a display name for an
incoming call or session. For example, if the URI is travis@tekelec.com, then the display of the receiving device
would show Travis. This is not a requirement, so this field may not contain a display name.

63
 Enrutamiento estricto utilizando el campo Via

User Agent This header is like the SERVER header providing the software version of the SIP user agent processing
a request. The two headers can be used together to identify the software versions on both devices. This information
can then be used by operators for profiling and other applications. For example, in todays networks cell phones
send an International Mobile Equipment Identifier (IMEI) identifying the make and model of the device, and
configuration information about the device. Operators that collect this information can then use the data to track the
activities of the subscriber based on that subscribers phone make and model. They can use these statistics to better
understand the behaviors of the subscribers based on their phone models. They can also determine how the various
phones are being used, and whether or not subscribers are using all capabilities of the device. If a device identified
supports video, the operator can track the actual usage of all video-enabled devices to determine how many actually
use this capability, when they use the capability, and so on. This data could even be used for promotional
campaigns to alert all users of certain models of devices to new features and applications that are being offered for
their devices. Application servers can also process this information and use it for various applications.
USER-AGENT: Vista Beta1.5
Via The required Via header field is used to record the SIP route taken by a request and is used to route a response
back to the originator. A user agent generating a request records its own address in a Via header field in the request.
While the ordering of most SIP header fields is not significant, the Via header fields order is significant because it is
used to route responses. A proxy forwarding the request adds a Via header field containing its own address to the
top of the list of Via header fields. A proxy adding a Via header field always includes a branch tag containing a
cryptographic hash of the To, From, Call-ID header fields and the Request-URI. A proxy or user agent generating a
response to a request copies all the Via header fields from the request in order into the response, then sends the
response to the address specified in the top Via header field. A proxy receiving a response checks the top Via
header field to ensure that it matches its own address. If it does not, the response has been misrouted and should be
discarded. The top Via header field is then removed, and the response forwarded to the address specified in the
next Via header field. A simplified Via decision tree is shown in the Figure. Via header fields contain protocol name
and version number and transport (SIP/2.0/UDP, SIP/2.0/TCP, etc.) and may contain port numbers and parameters
such as received, branch, maddr, and ttl. A received tag is added to a Via header field if a user agent or proxy
receives the request from a different address than that specified in the top Via header field. This indicates that a NAT
or firewall proxy is in the message path. If present, the received tag is used in response routing. (The hidden
parameter, deprecated in RFC 3261, was used to indicate the Via header field has been encrypted.) A branch
parameter is added to Via header fields by UAs and proxies, which is computed as a hash function of the Request-
URI, and the To, From, Call-ID and CSeq number. A second part is added to the branch parameter if the request is
being forked. The maddr and ttl parameters are used for multicast transport and have a similar meaning as the
equivalent SIP URI parameters.

64
65
 Identidad SIP y formato URI

Esquema USO RFC

sip: sips: Direcciones SIP (segura y no segura) 3261

Tel: Nmeros de telfono 3999

Pres: Presencia de recurso 3861

Im: Recurso de mensajera instantnea 3861
http: Protocolo de transporte de Hipertexto para pginas Web 2616
Xmpp: Xmpp: Jabber IM y presencia de URIs

H323:H323 URL H323 3508

Resources within the SIP network are identified using either a SIP URI or a SIPS URI. There is no difference
between the format of these two URIs. The SIPS URI indicates that the session between the user agent and the
resource addressed in the URI is secure using encryption. The user field identifies a resource. A resource can be a
person, or it can be a server resource. The RFC does not recommend using the password field in the URI for
obvious reasons. This would require publishing the users password in plain text, naturally raising significant security
concerns. Nonetheless, it has been defined but is not implemented.
There are two principles behind the use of a URI. First, one can use an IP address; however, this address should be
static rather than dynamic, as the address could change when dynamic allocation is used. If a domain name is used,
the receiving user agent can query the DNS to determine the IP address (common in e-mail, as an example). The
URI usually takes the form of:
russell@tekelec.com
The host can be identified by using either the registered domain or the IP address. Both IPv4 and IPv6 addressing is
supported in most networks today, so the format of the IP address will conform to either one of those versions. The
port can also be identified but is not required. Some other examples of a SIP URI could look like:
russell@192.43.1.0:5060
There are events where the user information would not be included in the URI. For example, if the resource being
addressed is a server or a router rather than a person, then the URI would not have the user information, nor would
it use the @ sign. For example:
sip:p4.tekelec.com
The URI can also take the form of a telephone number, referred to as the TEL URI. When a telephone number is
used, the user information is replaced with the telephone number digits rather than the user identity. The number
can be any global number using E.164 format, with a + preceding the number. If a local number is used, then the
+ is dropped. Hyphens can also be added to separate groups of numbers to match local notation for telephone
numbers.
sip:+19194602172@tekelec.com
TEL URI supports VoIP applications where the voice is being routed through an IP network, but will need to be
terminated back into the PSTN. Since the PSTN only understands telephone numbers, this format has to be
supported. In a pure VoIP implementation, the use of TEL URIs is not necessary, since the SIP network is capable
of routing using a standard URI.
When a call is being routed into the VoIP network from the PSTN, a TEL URI is all that can be used, since the
originator in the PSTN is able to enter only telephone numbers. If the destination is an IP address, the TEL URI will
have to be resolved to an IP address.
This is accomplished through the ENUM function. The purpose of the ENUM function is to convert from telephone
numbers (or TEL URI) to domain names. Once they are converted to domain names, they can be resolved by the
DNS into an IP address. There are some who will implement the ENUM function as an extension of their DNS, while
others will implement ENUM as a stand-alone function. Either implementation will work.

66
A single subscriber may possess multiple identities. Think of your own communications. You have at
least one identity for e-mail. Many people have multiple e-mail addresses; one for business use and one
for personal use. You also have a home phone number, a work phone number, a cell number, and
possibly more. This allows you as a subscriber to have multiple destinations for mail and voice calls,
depending on the address being used. For the service provider, it allows flexibility in defining services for
a single subscriber, and the ability to offer multiple services under one subscription. For each subscriber
there are at least two identities known by the service providertheir private and their public identities.
Private User Identity
The private identity is what uniquely identifies the subscription. Remember, however, that this only
identifies a subscription and cannot necessarily guarantee authenticity of the actual person using the
subscription. The purpose of the private identity is to allow the operator to identify one subscription for all
communications, and all services for the purposes of registration, authorization, administration, and
billing. The private identity, therefore, is not advertised to the subscriber, nor is it visible to other networks.
The private identity is known only to the service provider. It may take many different forms, but it must be
unique within the domain and it must be limited to one identity for each subscription. It must always be
used during registration. RFC 2486 specifies that the private identity take the form of Network Access
Identifier (NAI), with the IMSI embedded as part of the address. The IMSI is already used by GSM
operators as the private user identity for GSM subscribers. The NAI as defined by the RFC is really what
we have come to know as our e-mail address, where the @ separates the username portion from the
domain portion. It is the domain portion that uniquely identifies the network (and therefore the service
provider). This is why it is so important that domain names be administered by a third-party
administration. If someone wishes to establish a domain name for his or her own use, that person must
register with the Internet Assigned Numbers Authority (IANA) to ensure the domain is not already in use
by someone else. This ensures uniqueness worldwide. This is probably a good time to emphasize,
however, that private user identities are never used for routing purposes. They are used only for
administration, and so on. There are times, however, when the private user identity may need to cross
network boundaries. For example, when placing a long-distance call from your home service provider,
through the long-distance carrier, and back to the local operator, the local operator may be the same as
your home service provider.
In this case it would be important to be able to pass along your private user identity for proper billing of
the call. However, the identity must be protected from discovery by intermediate networks, so tunneling
and other methods may be used. Since the private user identity is not known by subscribers themselves,
there must be a means of embedding the identity into a subscribers device. This is commonly done
today in GSM networks using the Universal Integrated Circuit Card (UICC). This is the little card inserted
into the GSM phone when you obtain service from a GSM service provider. We commonly refer to this
little card as the Subscriber Identity Module (SIM); however, the SIM is actually the name of the
application that resides on the UICC. The SIM provides the private user identity for the GSM service
provider, and as SIP is implemented in these networks going forward, the device will continue to provide
this identity in the SIP domain. This also applies to fixed-line services, where the subscriber will purchase
a device and insert the SIM into the phone when that subscriber obtains services from the service
provider. This model allows subscribers to use any device they want, while uniquely identifying them to
the service provider. The service provider is then able to associate the user with an authorized
subscription, even though that user may be using a device he or she purchased from someplace else.
There is other information stored on the SIM application in addition to the private user identity, as we will
discuss. In a perfect world, subscribers purchase a SIM application contained on a UICC from their local
service provider of choice, and then use this in the various devices they purchase from the Internet, from
their local electronics store, or from other service providers. The revenue stream comes from the
purchase of a subscription rather than a device locked to work on the service provider network only.

67
Public User Identity
The public user identity is what subscribers use to advertise their existence. We all have one today,
although ten years ago only a select group carried one. On the other hand, one could argue that we have
all had a public user identity in a different form for decades: our telephone number.
The public user identity uses the same NAI form described for the private user identity, with the exception
of the content, which would not consist of the IMSI (in the wireless case). The public user identity is not
limited per subscriber as the private user identity is. A subscriber is likely to have multiple public user
identities associated with one subscription, allowing that subscriber to use different devices for different
purposes, using the same service provider (and on the same bill).
This means that every subscriber has the potential of multiple public identities to then use for personal
use, business use, maybe a special hobby, or anything else he or she chooses. If you use AOL today,
you will find a similar concept, where you have a primary screen name (your public user identity) but on
the same account you can have multiple screen names, all billed to the same account.
Each of the public user identities will have a profile identifying the various preferences defined by the
subscriber, and identifying what services are associated with the identity For example, I may choose to
have my Blackberry service associated with my business identity, but a separate cell phone service with
text and instant messaging for personal use, associated with my personal identity.
This allows the service provider to offer a lot of flexibility for its subscribers, and eliminates the need for
multiple accounts for each identity. This also allows for flexible routing to the subscribers various
devices. For example, I can have calls to my business number routed directly to my Blackberry, and if
there is no answer (or my Blackberry is out of range), I can have the call routed to my voicemail.
On the other hand, if my spouse calls my business number and I do not answer, I can request special
routing for her call (based on her identity) so that she is routed to my personal phone rather than
voicemail. The subscriber then has complete control over call treatment for each one of his or her
identities.
The public user identity is used for routing, which is different than the private user identity as we
discussed previously. However, the public user identity is not used for authentication. Only the private
user identity can be used for authentication. Authentication is an optional function in SIP networks, unless
the network is following the 3GPP IMS implementation standards. In the IMS, authentication is required
anytime a subscriber accesses the network and registers his or her location.
When a subscriber activates a device and accesses the network, that subscribers private user identity is
sent along with his or her public user identity of choice (usually assigned to the device or through a login
GUI on their PC) in a REGISTER message. This is how subscribers notify the network of their location.
The REGISTER message is not the same as authentication. Registering does nothing more than notify
the network of the location for the specified identity. Authentication requires the exchange of credentials
between the device and the network.

68
El protocolo SDP define un formato de descripcin diseado exclusivamente para describir sesiones
multimedia en tiempo real, siendo til para invitacin, anuncio y cualquier otra forma de inicio de
sesiones. En este mbito, por descripcin se entiende proporcionar en formato estndar la informacin
necesaria para que posibles participantes (usuarios y aplicaciones) puedan tener conocimiento y unirse
a una sesin. Las descripciones SDP se pueden emplear en situaciones muy diversas. Cada
descripcin SDP proporciona la siguiente informacin:
Nombre y propsito de la sesin
Tipo y formato de los medios que la componen
Intervalo(s) temporal(es) de desarrollo de la sesin
Parmetros necesarios para poder recibir e interpretar los datos: direcciones, puertos, tipos de
formato multimedia, etc.
Informacin complementaria relativa a los recursos de red necesarios para participar en la sesin,
como por ejemplo requisitos de ancho de banda e informacin de contacto del responsable de la
sesin.
En general SDP deber portar suficiente informacin para permitir a las aplicaciones unirse a una sesin
(con la posible excepcin de las claves de encriptado) y anunciar los recursos necesarios a los usuarios
no participantes.
SDP est pensado para ser de propsito general y puede ser usado por una amplia gama de entornos
de red y aplicaciones. Sin embargo no aportan ningn mecanismo para la negociacin del contenido de
sesiones o codificacin de medios. Esto queda fuera de la descripcin de la sesin.
Segn la RFC 4566, una descripcin de sesin se define como sigue:
Un formato bien definido para contener informacin suficiente para descubrir y participar en una
sesin multimedia.
Sin embargo, en la actualidad SDP se emplea adems para describir las capacidades de los sistemas y
proporcionar varias alternativas de configuracin a elegir.
69
Una descripcin de sesin SDP se denota por el tipo de contenido application/sdp. Una descripcin de sesin
SDP es enteramente textual usando el juego de caracteres ISO 10646 con codificacin UTF-8. Los nombres de
campo usan el subconjunto USASCII, pero los campos textuales y atributos pueden usar el conjunto de caracteres
completo de la ISO 10646. Los valores de los campos y de los atributos que usan el juego de caracteres completo
UTF-8. Una descripcin de sesin SDP consiste en un nmero de lneas de texto en el siguiente formato:
<tipo>=<valor>
Donde < tipo > debe ser exactamente uno de los caracteres (importan las maysculas) y <valor> es texto
estructurado cuyo formato depende del < tipo >. En general, <valor> es cualquier nmero de campos delimitados
por un simple carcter espacio o una cadena de formato libre y es sensible a maysculas, salvo que el <tipo>
especifique otra cosa. Los espacios no deben ser usados a cualquier lado del signo =. Una descripcin de sesin
SDP consiste en una seccin de nivel de sesin seguida de ninguna o ms secciones de nivel de contenidos. Las
partes de nivel de sesin comienzan con una lnea v= y continan hasta la primera seccin de nivel de contenidos.
Cada seccin de nivel de contenido comienza con una lnea m= y continua hasta la prxima seccin de
contenidos o hasta el final de la descripcin de la sesin completa. Algunas lneas en cada descripcin son
obligatorias y otras opcionales pero todas deben aparecer en el orden exacto dado en la RFC. Esto se ha hecho as
para facilitar la deteccin de errores y el procesado de la informacin. El conjunto de letras de tipo es
deliberadamente pequeo y no est pensado para ser extensible. Un analizador SDP debe ignorar completamente
cualquier descripcin de sesin que contenga una letra que no entienda. El mecanismo de atributos (a=) es la
forma de extender SDP y ajustarlo para aplicaciones o contenidos particulares. Adems un analizador SDP debe
ignorar cualquier atributo que no entienda.
Una descripcin de sesin SDP puede contener URIs que referencien contenido externo, haciendo que la propia
descripcin no sea auto contenida ("u=", "k=", y "a=) La informacin de conexin (c=) y de atributos (a=) en la
seccin de nivel de sesin se aplica a todo el contenido de esa sesin a menos que sea sobre escrito por los
mismos campos en la especificacin de cada contenido. El conjunto de letras de tipo es deliberadamente pequeo y
no est pensado para ser extensible. Un analizador SDP debe ignorar completamente cualquier descripcin de
sesin que contenga una letra que no entienda. El mecanismo de atributos (a=) es la forma de extender SDP y

70
ajustarlo para aplicaciones o contenidos particulares. Adems un analizador SDP debe ignorar
cualquier atributo que no entienda.
Una descripcin de sesin SDP puede contener URIs que referencien contenido externo, haciendo
que la propia descripcin no sea auto contenida ("u=", "k=", y "a=) La informacin de conexin
(c=) y de atributos (a=) en la seccin de nivel de sesin se aplica a todo el contenido de esa
sesin a menos que sea sobre escrito por los mismos campos en la especificacin de cada
contenido.

70
 Descriptores de sesin SDP

Session Descriptions
The session-level descriptions provide details about the session itself, such as the host of the session and the
address for the session. There could be more than one session description within a single SIP message. In other
words, one SIP INVITE could carry within itself SDP descriptors for more than one session. This is so when
supporting a conference call, as an example; where there is need for multiple media types, each media type can be
described separately. The session descriptors in this case will always be followed by their respective time
descriptions and media descriptions. Following are the headers for the session-level descriptions in SDP:
v = protocol version Identifies the version of SDP being supported for this session. This is used so that the
receiving entity knows how to interpret the other attribute lines within the SDP.
o = owner/creator and session identifier Identifies who is initiating the session as well as identifying the session
itself. Its use may not seem logical for a simple voice session between two parties, but it makes more sense when
the session is a conference call or Webex session.
The format for this field is shown here:
o=<username><session id><version><network type><address type><address>
The username is all one word (cannot contain spaces) and is the user ID of the session host. For example, the
username may be travis.russell. This is used along with the session ID and the rest of the parameters in this field to
form a globally unique identifier for this session. It is really up to the creator of the session how to use the <version>
parameter. It was placed here to allow proxies to be able to use different versions of an announcement and
determine which session announcement is the most recent. A simple method is to use a timestamp as the version,
allowing the proxies to always be able to determine which is the most current. For <network type> IN is used to
indicate the Internet, although this certainly changes when used within an IMS environment. Most likely an IMS
environment will use IMS. Meanwhile, <address type> denotes the version of IP being used; either IPv4 or IPv6.
s = session name Again, this makes more sense when used in association with a multimedia conference bridge
or Webex session. The name of the session, for example, could be something like Introduction to SIP by Travis
Russell. This might look something like:
s="Introduction to SIP By Travis Russell"
i = session information This descriptor provides additional information about the session. This is used in
conjunction with the session name, and like the session name it is provided for the use by participants in the
session. There can only be one i= field at the session level, and only one i= field at the media description level.
The description is a text string. It could look something like:
i=session on IMS
u = URI of description Identifies the URI where participants can go to receive more information about the
session. Again, this makes more sense when associated with a Webex or some other similar multimedia session
with multiple participants. This is an optional field, but when present it should always be found before the first media
description. This field might look like:
u=www.tekelec.com.

71
 e = e-mail address This allows the session owner to provide an e-mail address so that participants can contact
him or her regarding the session. More than one can be provided for each session.
p = phone number Like the e-mail address, this is used to provide a phone number that participants can call to
inquire about the session. This and the e-mail address make sense for multimedia conferences and Webex sessions
but probably will not be used for simple voice communications.
c = connection information The connection information consists of the following:
c=<network type><address type><connection address>
The network type is the same definition as previously described. Currently IN has been defined for use when
describing the Internet. The <address type> and <connection address> identify the actual IP address to be used for
the connection, with the address type identifying it either as an IPv4 or IPv6 address.
b = bandwidth information Identifies the amount of bandwidth to be used for the session. It is broken into two
parameters as shown here:
b=<modifier><bandwidth-value>
The modifier can be one of two values: either CT for conference total or AS for application specific. CT denotes
the total bandwidth across all sites, encompassing all media used for the session. AS denotes the amount of
bandwidth at a single site, from the perspective of a single application receiving the session. The bandwidth value is
then expressed in kilobytes per second.
k = encryption keys When encryption is provided, this field is used to identify the encryption keys needed to read
the payload. The standards do not identify the exact mechanism for exchanging keys, but rather a vehicle whereby
encryption keys could be exchanged. The format and parameters for this field are
k=<method><key parameter>
The method may use one of several values:
Clear = is provided without modification or alteration in this field.
Base64 = is included in this field but has been encoded to base64 because SDP does not support its characters.
Uri = indicates that the included URI must be used to obtain the encryption keys through additional authentication.
Prompt = the encryption key is not included and the host should be prompted to provide the necessary encryption
keys when accessing the session.
a = zero or more attribute lines Attributes are used as a vehicle to extend SDP for other applications. For
example, if a specific application requires an attribute not already defined by the IETF, it can be called out in this
parameter. Any receiving entity that does not understand the attribute simply ignores it. There are basically two
types of attributes. An example of a property attribute might be rcvonly. Value attributes might look something like
a=orient:landscape. These are interpreted by the receiving application, or if not understood are ignored.
m = media The optional m= field contains information about the type of media session. The field contains:
m=<media><port><transport><media formats>
The media parameter is either audio, video, application, data, telephone-event, or control. The port parameter
contains the port number. The transport parameter contains the transport protocol, which is either RTP/AVP or udp.
(RTP/AVP stands for Real-time Transport Protocol / audio video profiles.The media formats contains more
information about the media. Usually, it contains media payload types defined in RTP audio video profiles. More than
one media payload type can be listed, allowing multiple alternative codecs for the media session. For example, the
following media field lists three codecs:
m=audio 49430 RTP/AVP 0 6 8 99
One of these three codecs can be used for the audio media session. If the intention is to establish three audio
channels, three separate media fields would be used. For non-RTP media, Internet media types should be listed in
the format-list. For example,
m=application 52341 udp wb
could be used to specify the application/wb media type.

72
 Descripcin de medios - Atributos
As mentioned, attributes serve as an extension of the SDP. In the case of media
descriptions, there are a number of attributes that are defined in RFC 2327, but keep in
mind that various vendors may include other proprietary attributes for their own
systems use. This is perfectly acceptable and allows for more flexibility in the various
entities that use SDP. The following attributes have been defined in RFC 2327:
a=rtpmap<payload type><encoding name>/<clock rate><encoding parameters> The
payload type of this attribute indicates whether it is audio or video. In the case of audio,
there may also be encoding parameters identifying the number of voice channels,
although this is optional. The encoding parameters field is not used if the payload type
is video.
a=cat:<category>
This attribute has been suggested for use at the session description level. An
application could use this to allow the receiver of a session to sort through various
sessions by category. For example, in the case of streaming audio (digital radio
broadcast) the category may be the genre of the music one wants to listen to.
a=keywds:<keywords>
Keywords work a lot like the category attribute but allow for a search utility where
sessions can be searched for according to specific keywords. This is also a session-
level attribute.
a=tool:<name and version of tool>
This attribute is used to identify the name and the version of the tool that was used to establish a session. This is also a session-
level attribute.
a=ptime:<packet time>
This is a media description-level attribute that is used to identify in milliseconds the length of time represented in received
packets for a session. This is used primarily for audio to ensure proper encoding of the audio stream.
a=rcvonly
This can be a session- or description-level attribute and is used to set the tools to receive only when receiving a session. For
example, if this is to be a Webcast session, audio is received in one direction only (receivers can listen only; they cannot have a
conversation with the host of the session).
a=sendrecv
This is the same as the preceding attribute, with the exception that the receiving application is set in the send and receive mode.
This then enables the receiver of a session to participate in the session (bidirectional audio).
a=orient:<whiteboard orientation>
This attribute is typically used with whiteboard applications such as those used in Webinars. The three values supported are
landscape, portrait, or seascape (this is upside-down landscape).
a=type:<conference type>
The conference type attribute is a session-level attribute and identifies the type of conference being established. There are
several suggested values:
Broadcast Meeting Moderated Test
a=charset:<character set>
This attribute identifies the character set that is to be used to describe the character sets used when interpreting SDP. This is
necessary for international networks if a character set other than ISO 10646 is to be used.
a=sdplang:<SDP language>
This attribute identifies the language to be used within the SDP. The default is English.
a=lang:<language>
Similar to SDP language, this allows a different language to be identified for a specific media descriptor. For example, the
a=sdplang:english attribute may be found in the session description, but for a specific media description in the same session
there may be a different language called out just for that medium (a=lang:spanish).
a=framerate:<frame rate>
Used for video media, this attribute identifies the maximum frame rate per second to be supported.
a=quality:<quality>
This is used to suggest a level of quality for video. There are several defined values for this field:
10 The best still-image possible
5 Default (this value does not have a quality description)
0 The worst still image quality that can be supported and is still usable
All attributes are found in either the session description or the media description levels. We have defined those found in the RFC,
but remember that there can be others. Again, if an entity does not recognize an attribute, it simply ignores that attribute.

73
74
SIP User Agents
A SIP-enabled end-device is called a SIP user agent . One purpose of SIP is to enable sessions to be established
between user agents. As the name implies, a user agent takes direction or input from a user and acts as an agent on
their behalf to set up and tear down media sessions with other user agents. In most cases, the user will be a human,
but the user could be another protocol, as in the case of a gateway (described in the next section). A user agent
must be capable of establishing a media session with another user agent.
A UA must maintain state on calls that it initiates or participates in. A minimum call state set includes the local and
remote tags, Call-ID, local and remote CSeq header fields, along with the route set and any state information
necessary for the media. This information is used to store the dialog information and for reliability. The remote CSeq
storage is necessary to distinguish between a re-INVITE and a retransmission. A re-INVITE is used to change the
session parameters of an existing or pending call. It uses the same Call-ID, but the CSeq is incremented because it
is a new request. A retransmitted INVITE will contain the same Call-ID and CSeq as a previous INVITE. Even after a
call has been terminated, call state must be maintained by a user agent for at least 32 seconds in case of lost
messages in the call tear-down.
User agents silently discard an ACK for an unknown dialog. Requests to an unknown URI receive a 404 Not Found
Response. A user agent receiving a request for an unknown dialog responds with a 481 Dialog/Transaction Does
Not Exist. Responses from an unknown dialog are also silently discarded. These silent discards are necessary for
security. Otherwise, a malicious user agent could gain information about other SIP user agents by spamming fake
requests or responses.
Although not required to understand every response code defined, a minimal implementation must to be able to
interpret any unknown response based on the class (first digit of the number) of the response. That is, if an
undefined 498 Wrong Phase of the Moon response is received, it must be treated as a 400 Client Error.
A user agent responds to an unsupported request with a 501 Not Implemented response. A SIP UA must support
UDP transport and also TCP if it sends messages greater than 1,000 octets in size. A SIP user agent contains both
a client application and a server application.
The two parts are a user agent client (UAC) and user agent server (UAS). The UAC initiates requests while the UAS
generates responses. During a session, a user agent will usually operate as both a UAC and a UAS. A SIP user
agent must also support SDP for media description. Other types of media description protocols can be used in
bodies, but SDP support is mandatory. A UA must understand any extensions listed in a Require header field in a
request. Unknown header fields may be ignored by a UA. A UA should advertise its capabilities and features in any
request it sends. This allows other UAs to learn of them without having to make an explicit capabilities query. For
example, the methods that a UA supports should be listed in an Allow header field. SIP extensions should be listed
in a Supported header field. Message body types that are supported should be listed in an Accept header field.
Presence Agents
A presence agent (PA) is a SIP device that is capable of receiving subscription requests and generating state
notifications as defined by the SIP Events specification. A presence agent supports the presence Event package,
responds to SUBSCRIBE requests, and sends NOTIFY requests. A presence agent can collect presence
information from a number of devices. Presence information can come from a SIP device registering, a SIP device
publishing presence information, or from many other non-SIP sources. A presence server is a server that sometimes
acts as a presence agent and supplies presence information and other times acts as a proxy, forwarding
SUBSCRIBE requests to another presence agent. A presence agent first authenticates a subscription request. If the
authentication passes, it establishes a dialog and sends the notifications over that dialog. The subscription can be
refreshed by receiving new SUBSCRIBE requests.
Back-to-Back User Agents
A back-to-back user agent (B2BUA) is a type of SIP device that receives a SIP request, then reformulates the
request and sends it out as a new request. Responses to the request are also reformulated and sent back in the
opposite direction. For example, a B2BUA device can be used to implement an anonymizer service in which two SIP
UAs can communicate without either party learning the other partys URI, IP address, or any other information. To
achieve this, an anonymizer B2BUA would reformulate a request with an entirely new From, Via, Contact, Call-ID,
and SDP media information, also removing any other SIP header fields that might contain information about the
calling party. The response returned would also change the Contact and SDP media information from the called
party. The modified SDP would point to the B2BUA itself, which would forward RTP media packets from the called
party to the calling party and viceversa. In this way, neither end point learns any identifying information about the
other party during the session establishment. The most common form of B2BUA present in SIP networks is
application layer gateways (ALG). Some firewalls have ALG functionality built in, which allows a firewall to permit
SIP and media traffic while still maintaining a high level of security.

75
A SIP gateway is an application that interfaces a SIP network to a network utilizing another signaling protocol. In
terms of the SIP protocol, a gateway is just a special type of user agent, where the user agent acts on behalf of
another protocol rather than a human. A gateway terminates the signaling path and can also terminate the media
path, although this is not always the case. For example, a SIP to H.323 gateway terminates the SIP signaling path
and converts the signaling to H.323, but the SIP user agent and H.323 terminal can exchange RTP media
information directly with each other without going through the gateway. A SIP to Public Switched Telephone Network
(PSTN) gateway terminates both the signaling and media paths. SIP can be translated into, or interwork with,
common PSTN protocols such as Integrated Services Digital Network (ISDN), ISDN User Part (ISUP), and other
Circuit Associated Signaling (CAS) protocols. A PSTN gateway also converts the RTP media stream in the IP
network into a standard telephony trunk or line. The conversion of signaling and media paths allows calling to and
from the PSTN using SIP. The figure shows a SIP network connected via gateways with the PSTN and a H.323
network. In the figure, the SIP network, PSTN network, and H.323 networks are shown as clouds, which obscure the
underlying details. Shown connecting to the SIP cloud are SIP IP telephones, SIP-enabled PCs, and corporate SIP
gateways with attached telephones. The clouds are connected by gateways. Shown attached to the H.323 network
are H.323 terminals and H.323-enabled PCs. The PSTN cloud connects to ordinary analog black telephones (so-
called because of the original color of their shell), digital ISDN telephones, and corporate private branch exchanges
(PBXs). PBXs connect to the PSTN using shared trunks and provide line interfaces for either analog or digital
telephones. Gateways are sometimes decomposed into a media gateway (MG) and a media gateway controller
(MGC). An MGC is sometimes called a call agent because it manages call control protocols (signaling), while the
MG manages the media connection. This decomposition is transparent to SIP. Another difference between a user
agent and a gateway is the number of users supported. While a user agent typically supports a single user (although
perhaps with multiple lines), a gateway can support hundreds or thousands of users. A PSTN gateway could support
a large corporate customer, or an entire geographic area. As a result, a gateway does not REGISTER every user it
supports in the same way that a user agent might. Instead, a non-SIP protocol can be used to inform proxies about
gateways and assist in routing.

76
SIP servers are applications that accept SIP requests and respond to them. A SIP server should not be confused
with a user agent server or the client-server nature of the protocol, which describe operation in terms of clients
(originators of requests) and servers (originators of responses to requests). A SIP server is a different type of entity.
The types of SIP servers discussed in this section are logical entities. Actual SIP server implementations may
contain a number of server types, or may operate as a different type of server under different conditions. Because
servers provide services and features to user agents, they must support both TCP, TLS, and UDP for transport. The
figure shows the interaction of user agents, servers, and a location service. Note that the protocol used between a
server and the location service or database is not in general SIP.
Proxy Servers
A SIP proxy server receives a SIP request from a user agent or another proxy and acts on behalf of the user agent
in forwarding or responding to the request. A proxy is not a B2BUA since it is only allowed to modify requests and
responses according to strict rules set out in RFC 3261. These rules preserve the end-to-end transparency of the
SIP signaling while still allowing a proxy server to perform valuable services and functions for user agents. A proxy
server typically has access to a database or a location service to aid it in processing the request (determining the
next hop). The interface between the proxy and the location service is not defined by the SIP protocol. A proxy can
use any number of types of databases to aid in processing a request. Databases could contain SIP registrations,
presence information, or any other type of information about where a user is located. The example of the figure
introduce a proxy server as a facilitator of SIP message exchange providing user location services to the caller. A
proxy does not need to understand a SIP request in order to forward itany unknown request type is assumed to
use the non-INVITE transaction model. A proxy should not change the order of header fields or in general modify or
delete header fields.
A proxy server is different from a user agent or gateway in three key ways:
1. A proxy server does not issue requests; it only responds to requests from a user agent. (A CANCEL request is an
exception to this rule.)
2. A proxy server has no media capabilities.
3. A proxy server does not parse message bodies; it relies exclusively on header fields.

77
The figure shows a common network topology known as the SIP Trapezoid. In this topology, a pair of user agents in
different domains establishes a session using a pair of proxy servers, one in each domain. The trapezoid refers to
the shape formed by the signaling and media messages. In this configuration, each user agent is configured with a
default outbound proxy server, to which it sends all requests. This proxy server typically will authenticate the user
agent and may pull up a profile of the user and apply outbound routing services. In an interdomain exchange, DNS
SRV queries will be used to locate a proxy server in the other domain. This proxy, sometimes called an inbound
proxy may apply inbound routing services on behalf of the called party. This proxy also has access to the current
registration information for the user, and can route the request to the called party. In general, future SIP requests will
be sent directly between the two user agents, unless one or both proxies inserts a Record-Route header field.
A proxy server can be either stateless or stateful. A stateless proxy server processes each SIP request or response
based solely on the message contents. Once the message has been parsed, processed, and forwarded or
responded to, no information about the message is storedno dialog information is stored. A stateless proxy never
retransmits a message, and does not use any SIP timers. Note that the stateless loop detection using Via header
fields described in RFC 2543 has been deprecated (removed) in RFC 3261 in favor of the use of a mandatory Max-
Forwards header field in all requests.
A stateful proxy server keeps track of requests and responses received in the past and uses that information in
processing future requests and responses. For example, a stateful proxy server starts a timer when a request is
forwarded. If no response to the request is received within the timer period, the proxy will retransmit the request,
relieving the user agent of this task. Also, a stateful proxy can require user agent authentication.
The most common type of SIP proxy is a transaction stateful proxy. A transaction stateful proxy keeps state about a
transaction but only for the duration that the request is pending. For example, a transaction stateful proxy would
keep state when it receives an INVITE request until it received a 200 OK or a final failure response (e.g., 404 Not
Found). After that, it would destroy the state information. This allows a proxy to perform useful search services but
minimize the amount of state storage required.

78
 Proxy Stateful

A stateful proxy usually sends a 100 Trying response when it receives an INVITE. A stateless proxy never
sends a 100 Trying response. A 100 Trying response received by a proxy is never forwardedit is a single
hop only response. A proxy handling a TCP request must be stateful, since a user agent will assume
reliable transport and rely on the proxy for retransmissions on any UDP hops in the signaling path. The
only limit to the number of proxies that can forward a message is controlled by the Max-Forwards header
field, which is decremented by each proxy that touches the request. If the Max-Forwards count goes to
zero, the proxy discards the message and sends a 483 Too Many Hops response back to the originator.
A SIP session timer has been proposed to limit the time period over which a stateful proxy must maintain
state information. In the initial INVITE request, a Session-Expires header field indicates a timer interval
after which stateful proxies may discard state information about the session. User agents must tear down
the call after the expiration of the timer. The caller can send re-INVITEs to refresh the timer, enabling a
keep alive mechanism for SIP. This solves the problem of how long to store state information in cases
where a BYE request is lost or misdirected, or in other security cases.
CALL FLOW
1. An INVITE message is sent to bob@ acme.com, but finds the Proxy server sip.acme.com along the
signaling path.
2. The Proxy server immediately responds with a 100 (Trying) provisional response.
3. The Proxy server looks-up Bobs current location in a Location Service using a non-SIP protocol (For
example, LDAP).
4. The Location Service returns Bobs current location: SIP address bob@lab.acme.com.
5. The Proxy server decides to proxy the call and creates a new INVITE message based on the original
INVITE message, but with the request URI in the start line changed to bob@lab.acme.com. The Proxy
server sends this request to the UAS at lab.acme.com.
6. The UAS responds first with a 100 (Trying).
7. The UAS responds with a 180 (Ringing) response.
8. The Proxy server forwards the 180 (Ringing) response back to the calling UA.
9. When the call is accepted by the user (for example, by picking up the handset) the UAS at lab.acme.com
sends a 200 (OK) response. In this example, Bobs UAS inserts a Contact header into the response with
the value bob@lab.acme.com. Further SIP communication will be sent directly to it and not via the Proxy
Server. This action is optional.
10. The Proxy forwards the 200 (OK) response back to the calling UAC.
11. The calling UA sends an ACK directly to Bobs UA at the lab (according to the Contact header it found
in the 200 (OK) response).

79
Forking proxies are used to split requests for routing to multiple destinations. For example, if a subscriber has
registered multiple addresses (for multiple devices) and has a service that facilitates routing of calls to all devices, a
forking proxy would then take the original request and split (or fork) it into multiple requests. These multiple requests
would then be sent to all of the destinations registered for the subscriber. This is only one example; there are many
other, similar services where forking of requests requires the services of a forking proxy. Since the forking proxy is
splitting the request, it is the only entity that knows about the other destinations. The forking proxy may be an
application server providing proxy service. Whatever the implementation, the originator of the request has no
knowledge of the request being sent to other destinations. This means that the forking proxy must manage the
responses from the other destinations.
This of course requires the forking proxy to be a stateful proxy. As a stateful proxy, the forking proxy will send a 1xx
provisional response when it receives the request. It will then forward the request to multiple destinations. However,
when it receives multiple responses, it does not forward those responses to the UAC. This is one important
differentiator between forking proxies and stateful proxies. Stateful proxies do not send 2xx responses, but the
forking proxy does if it receives at least one 2xx response from one destination. The forking proxy will send the 2xx
response back to the UAC regardless of the responses sent by the other destinations.
This means that any non-1xx/2xx responses (error responses) must be handled by the forking proxy and not sent to
the UAC, as this will cause the session to be terminated. Therefore, the proxy will return the appropriate response to
all other destinations, depending on their response. For example, if multiple destinations send a 2xx response, the
forking proxy will return an ACK to each of the responding destinations (remember only the forking proxy knows who
these destinations are). The forking proxy must then also maintain the dialog between itself and the other
destinations, acting as a middle agent for the entire session. Likewise, if any of the destinations responds with a
3xx6xx response, the forking proxy will return a BYE message and terminate the dialog between itself and the other
destination. The UAC that originated the request has no knowledge of this and has no visibility into the responses.

80
A redirect server is a type of SIP server that responds to, but does not forward requests. Like a proxy
sever, a redirect server uses a database or location service to look up a user. The location information,
however, is sent back to the caller in a redirection class response (3xx), which, after the ACK, concludes
the transaction.
CALL FLOW
1. First a SIP INVITE message is sent to bob@acme.com, but finds the Redirect server sip.acme.com
along the signaling path.
2. The Redirect server looks up Bobs current location in a Location Service using a non-SIP protocol (for
example, LDAP).
3. The Location Service returns Bobs current location: SIP address 3573572@gwtelco.com.
4. The Redirect Server returns this information to the calling UAC using a 302 (Moved Temporarily)
response. In the response message it enters a contact header and sets the value to Bobs current
location, 3573572@gwtelco.com.
5. The calling UAC acknowledges the response by sending an ACK message.
6. The calling UAC then continues the transaction directly with gw.telco.com by sending a new INVITE.
7. gw.telco.com is able to notify Bobs terminal of the call and Bob picks up the call. A 200 (OK)
response is sent back to the calling UAC.
8. The calling UAC acknowledges with an ACK message.

81
A registration server, also known as a registrar, accepts SIP REGISTER requests; all other requests
receive a 501 Not Implemented response. The contact information from the request is then made
available to other SIP servers within the same administrative domain, such as proxies and redirect
servers. In a registration request, the To header field contains the name of the resource being registered,
and the Contact header fields contain the alternative addresses or aliases. The registration server
creates a temporary binding between the Address of Record (AOR) URI in the To and the device URI in
the Contact Courier. Registration servers usually require the registering user agent to be authenticated,
so that incoming calls cannot be hijacked by an unauthorized user. This could be accomplished by an
unauthorized user registering someone elses SIP URI to point to their own phone. Incoming calls to that
URI would then ring the wrong phone. Depending on the header fields present, a REGISTER request can
be used by a user agent to retrieve a list of current registrations, clear all registrations, or add a
registration URI to the list. For full registration security, TLS must be used as HTTP Digest does not
provide the needed integrity protection.
When a device is turned on or changes location (resulting in a new IP address being assigned), the
device will send a REGISTER message into the SIP network to provide its new address. The registrar
then has two options: One is to accept the new address and save it in a location server. The other option
is to challenge the subscriber by rejecting the first registration attempt and force the subscriber to send
authentication keys (credentials) to verify they are indeed who they say they are. This second option is
highly recommended in any SIP network as a very simple security measure that helps prevent man-in-
the-middle attacks. Forcing authentication as part of the registration process would eliminate a lot of fraud
and security issues today if it were implemented; sadly, there are many VoIP implementations that do not
force authentication or authorization at all.

82
 SIP a travs de NAT

Since SIP was developed, guidelines for protocol design to make them more NAT friendly have been
developed by the IETF. Unfortunately, SIP violates most of these newer guidelines. For example, one of the
major recommendations of this document is that application layer protocols should not transport IP addresses
and port numbers. The example shows why this is a major problem for routing SIP and resulting Real-time
Transport Protocol (RTP) sessions through a NAT. In this INVITE generated from behind a NAT, the fields in
bold represent IP addresses that cannot be routed across a globally addressed network such as the Internet.
Because of the presence of the NAT:
The response to this request could not be routed back to the originator because of the inability to route
these private network address ranges defined for use on private internal networks (based on an incorrect
Via header).
Future requests during this session would be misrouted (based on an incorrect Contact header).
RTP packets sent by user B would be misrouted (based on an incorrect connection IP address c= for the
media in the Session Description Protocol, or SDP).
Note also that the two port numbers contained in this INVITE, port 5060 and port 49170, also may be changed
by the NAT and may cause signaling or media exchange to fail. If the NAT is being used for security
purposes, the amount of topology leakage shown in this INVITE would not be acceptable to a network
administrator, as shown in the figure.
Of these three problems identified, only this first one has a solution in SIP. A proxy or user agent (UA)
receiving this request would compare the IP address in the Via header to the IP address from which the
packet was received. If the two are different (as they would be if a NAT is present), the correct IP address is
added to the Via header with a received= parameter listing the actual IP address. This IP address would be
used to route the response successfully back to user A, provided the NAT maintains the same binding
between the private IP address and public IP address. (This is not a problem if TCP is used as the transport.
When a TCP connection is opened, the NAT creates the binding between the private IP address and port
number and the assigned public IP address and port number. When the connection closes, the NAT removes
the binding.) However, no easy solution exists for the other two problems. The second problem could be
solved by a persistent TCP connection for the duration of the session. This would mean that the Contact
header would never be used to route future requests (such as a re-INVITE or BYE), since there would always
be an open TCP connection. A possible solution to the third problem has been proposed that involves making
RTP flows symmetric. For the case where only one endpoint is behind a NAT, RTP packet flow will be
possible in at least one direction. This is so because the SDP of the endpoint outside the NAT will contain a
correct globally routable IP address and port number. The use of symmetric RTP would make the recipient of
the successful RTP stream use the received IP address and port number to send RTP, ignoring the IP
address in the SDP (which is not routable). In addition to these SIP and RTP issues, there is the issue of the
disclosure of the private IP address, information that administrators like to see blocked by the NAT. Although
not significant from a signaling or media perspective, the Call-ID also leaks the private IP address of the UA.

83
A firewall is a device typically present where a private IP network interconnects with the public Internet. A
firewall acts like a one-way gate, allowing requests to go from the private network into the Internet, and
allowing only responses to those requests to return, but blocking most requests originating in the Internet
destined for the private network. Certain types of requests from the public Internet are typically allowed.
For example, HTTP requests to the corporate public web server will not be blocked by the firewall, nor
SMTP e-mail transfers, nor are DNS queries for the public DNS server. These types of legitimate
requests can be identified by the firewall by examination of the destination IP address in the IP header
and the destination port number in the UDP or TCP headers.
For example, a valid web browsing request will contain the destination IP address of the public web
server and port 80 (a well-known port number for HTTP). A particularly diligent firewall may even parse
the packet to ensure that it contains a valid HTTP message. The nature of the interaction between SIP
and a firewall depends on the transport protocol. If the UA uses UDP to initiate the session, the server
outside the firewall will be able to receive the SIP messages, but responses sent using UDP will be
blocked by the firewall, since they are not associated with an outgoing request, because they are sent
over a TCP connection. Any resulting media stream also will be one-sided only. This scenario is shown in
the leftmost figure.
If TCP is used, it is possible for a SIP UA to establish a SIP session with a server on the outside of the
firewall. This is because the SIP responses will be sent in the TCP connection opened by the user behind
the firewall and will not be blocked. However, RTP media packets sent by the called party will be blocked
by the firewall. The resulting media session will be only one-way. This is shown in the rightmost figure. If
the a UA outside the firewall attempts to establish a session with the UA inside the firewall, all SIP and
RTP packets will be blocked, regardless of transport, resulting in no session. Note that it is possible to
configure a firewall to allow SIP. However, doing so opens so many holes and weakens the protection
provided by a firewall to such a degree that few network administrators would allow it. This is in contrast
to NATs, which currently cannot be reconfigured to pass SIP and media.

84
I-SBC / A-SBC Interconnect SBC / Access SBC
The SBC is the public interface for the telephony network, keeping the inside network private.
Yet, it does not manage everything regarding Voice, for example:
A hosted PBX extension when it starts uses DHCP & HTTP(S) to:
1) Contact a Provisioning Server to download all of its config data
2) Check if there is a newer release of its software
The SBC doesnt deal with DHCP or HTTP(S) traffic at all, so is not involved throughout
this process
SIP requests or methods are considered verbs in the protocol, since they request a specific action to be
taken by another user agent or server. The INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS
methods are the original six methods in SIP. The REFER, SUBSCRIBE, NOTIFY, MESSAGE, INFO,
PRACK and UPDATE methods are described in separate RFCs.
Note that a proxy does not need to understand a request method in order to forward the request. A proxy
treats an unknown method as if it were an OPTIONS; that is, it forwards the request to the destination if it
can. This allows new features and methods useful for user agents to be introduced without requiring
support from proxies that may be in the middle. A user agent receiving a method it does not support
replies with a 501 Not Implemented response. Method names are case sensitive and conventionally use
all uppercase for visual clarity to distinguish them from header fields, which use both upper and lower
case.

89
The INVITE method is used to establish media sessions between user agents. In telephony, it is similar to a Setup
message in ISDN or an initial address message (IAM) in ISUP. Responses to INVITEs are always acknowledged
with the ACK method. An INVITE usually has a message body containing the media information of the caller. The
message body can also contain other session information such as quality of service (QoS) or security information. If
an INVITE does not contain media information, the ACK contains the media information of the UAC. If the media
information contained in the ACK is not acceptable, then the called party must send a BYE to cancel the sessiona
CANCEL cannot be sent because the session is already established. A media session is considered established
when the INVITE, 200 OK, and ACK messages have been exchanged between the UAC and the UAS. A successful
INVITE request establishes a dialog between the two user agents, which continues until a BYE is sent by either
party to end the session. A UAC that originates an INVITE to establish a dialog creates a globally unique Call-ID that
is used for the duration of the call. A CSeq count is initialized (which need not be set to 1, but must be an integer)
and incremented for each new request for the same Call-ID. The To and From headers are populated with the
remote and local addresses. A From tag is included in the INVITE, and the UAS includes a To tag in any responses.
A To tag in a 200 OK response to an INVITE is used in the To header field of the ACK and all future requests within
the dialog. The combination of the To tag, From tag, and Call-ID is the unique identifier for the Dialog. An INVITE
sent for an existing dialog references the same Call-ID as the original INVITE and contains the same To and From
tags. Sometimes called a re-INVITE, the request is used to change the session characteristics or refresh the state of
the dialog. The CSeq command sequence number is incremented so that a UAS can distinguish the re-INVITE from
a retransmission of the original INVITE.
If a re-INVITE is refused or fails in any way, the session continues as if the INVITE had never been sent. A re-
INVITE must not be sent by a UAC until a final response to the initial INVITE has been receivedinstead, an
UPDATE request can be sent. There is an additional case where two user agents simultaneously send re-INVITEs
to each other. This is handled in the same way with a Retry-After header. This condition is called glare in telephony,
and occurs when both ends of a trunk group seize the same trunk at the same time. An Expires header in an INVITE
indicates to the UAS how long the call request is valid. For example, the UAS could leave an unanswered INVITE
request displayed on a screen for the duration of specified in the Expires header. Once a session is established, the
Expires header has no meaning the expiration of the time does not terminate the media session. Instead, a
Session-Expires header can be used to place a time limit on an established session. In addition to the required
headers, this request contains the optional Subject header.

90
91
92
The REGISTER method is used by a user agent to notify a SIP network of its current Contact URI (IP address) and
the URI that should have requests routed to this Contact. SIP registration bears some similarity to cell phone
registration on initialization. Registration is not required to enable a user agent to use a proxy server for outgoing
calls. It is necessary, however, for a user agent to register to receive incoming calls from proxies that serve that
domain unless some non-SIP mechanism is used by the location service to populate the SIP URIs and Contacts of
end-points. A REGISTER request may contain a message body, although its use is not defined in the standard.
Depending on the use of the Contact and Expires headers in the REGISTER request, the registrar server will take
different action. If no expires parameter or Expires header is present, a SIP URI will expire in 1 hour. The presence
of an Expires header sets the expiration of Contacts with no expires parameter. If an expires parameter is present, it
sets the expiration time for that Contact only. Non-SIP URIs have no default expiration time. The CSeq is
incremented for a REGISTER request. The use of the Request-URI, To, From, and Call-ID headers in a REGISTER
request is slightly different than for other requests. The Request-URI contains only the domain of the registrar server
with no user portion. The REGISTER request may be forwarded or proxied until it reaches the authoritative registrar
server for the specified domain. The To header contains the SIP URI of the AOR of the user agent that is being
registered. The From contains the SIP URI of the sender of the request, usually the same as the To header. It is
recommended that the same Call-ID be used for all registrations by a user agent. A user agent sending a
REGISTER request may receive a 3xx redirection or 4xx failure response containing a Contact header of the
location to which registrations should be sent. A third-party registration occurs when the party sending the
registration request is not the party that is being registered. In this case, the From header will contain the URI of the
party submitting the registration on behalf of the party identified in the To header.

93
The ACK method is used to acknowledge final responses to INVITE requests. Final responses to all other
requests are never acknowledged. Final responses are defined as 2xx, 3xx, 4xx, 5xx, or 6xx class
responses. The Cseq number is never incremented for an ACK, but the CSeq method is changed to
ACK. This is so that a UAS can match the CSeq number of the ACK with the number of the
corresponding INVITE.
An ACK may contain an application/sdp message body. This is permitted if the initial INVITE did not
contain a SDP message body. If the INVITE contained a message body, the ACK may not contain a
message body. The ACK may not be used to modify a media description that has already been sent in
the initial INVITE; a re-INVITE must be used for this purpose. SDP in an ACK is used in some
interworking scenarios with other protocols where the media characteristics may not be known when the
initial INVITE is generated and sent. For 2xx responses, the ACK is end-to-end, but for all other final
responses it is done on a hop-by-hop basis when stateful proxies are involved. The end-toend nature of
ACKs to 2xx responses allows a message body to be transported.
An ACK generated in a hop-by-hop acknowledgment will contain just a single Via header with the
address of the proxy server generating the ACK. The difference between hop-by-hop acknowledgments
to a response end-to-end acknowledgments is shown in the message fragments of the figure. A hop-by-
hop ACK reuses the same branch ID as the INVITE since it is considered part of the same transaction.
An end-to-end ACK uses a different branch ID as it is considered a new transaction. A stateful proxy
receiving an ACK message must determine whether or not the ACK should be forwarded downstream to
another proxy or user agent or not. That is, is the ACK a hop-by-hop ACK or an end-to-end ACK? This is
done by comparing the branch ID for a match pending transaction branch IDs. If there is not an exact
match, the ACK is proxied toward the UAS. Otherwise, the ACK is for this hop and is not forwarded by
the proxy.

94
The BYE method is used to terminate an established media session. In telephony, it is similar to a
release message. A session is considered established if an INVITE has received a success class
response (2xx) or an ACK has been sent. A BYE is sent only by user agents participating in the session,
never by proxies or other third parties. It is an end-to-end method, so responses are only generated by
the other user agent. A user agent responds with a 481 Dialog/Transaction Does Not Exist to a BYE for
an unknown dialog. It is not recommended that a BYE be used to cancel pending INVITEs because it will
not be forked like an INVITE and may not reach the same set of user agents as the INVITE.

95
The CANCEL method is used to terminate pending searches or call attempts. It can be generated by
either user agents or proxy servers provided that a 1xx response containing a tag has been received, but
no final response has been received. A user agent uses the method to cancel a pending call attempt it
had earlier initiated. A forking proxy can use the method to cancel pending parallel branches after a
successful response has been proxied back to the UAC. CANCEL is a hop-by-hop request and receives
a response generated by the next stateful element. The CSeq is not incremented for this method so that
proxies and user agents can match the CSeq of the CANCEL with the CSeq of the pending INVITE to
which it corresponds. The branch ID for a CANCEL matches the INVITE that it is canceling. A CANCEL
only has meaning for an INVITE since only an INVITE may take several seconds (or minutes) to
complete. All other SIP requests complete immediately (that is, a UAS must immediately generate a final
response). Consequently, the final result will always be generated before the CANCEL is received.
A proxy receiving a CANCEL forwards the CANCEL to the same set of locations with pending requests
that the initial INVITE was sent to. A proxy does not wait for responses to the forwarded CANCEL
requests, but responds immediately. A user agent confirms the cancellation with a 200 OK response to
the CANCEL and replies to the INVITE with a 487 Request Terminated response.
If a final response has already been received, a user agent will need to send a BYE to terminate the
session. This is also the case in the race condition where a CANCEL and a final response cross in the
network, as shown in the figure. In this example, the CANCEL and 200 OK response messages cross
between the proxy and the UAS. The proxy still replies to the CANCEL with a 200 OK, but then also
forwards the 200 OK response to the INVITE. The 200 OK response to the CANCEL sent by the proxy
only means that the CANCEL request was received and has been forwardedthe UAC must still be
prepared to receive further final responses. No 487 response is sent in this scenario. The session is
canceled by the UAC sending an ACK then a BYE in response to the 200 OK. Since it is a hop-by-hop
request, a CANCEL may not contain a message body.

96
Session termination and cancellation are two separate operations in SIP but are often confused. Session
termination occurs when either user agent sends a BYE referencing an existing call leg (that is, a session
successfully established using the INVITE/200/ACK exchange). This is shown in the example of the left.
Session cancellation occurs when a user agent ends a call prior to the call setup completing and the call being
established. The reader can think of the analogy to the action of the cancel button on the browser. In this
scenario, a user agent that has sent an INVITE, but has not yet received a final response (2xx, 3xx, 4xx, 5xx,
or 6xx), sends a CANCEL request. A CANCEL can also be originated by a proxy to cancel individual legs in a
forking proxy or parallel search.
While INVITE and BYE are end-to-end methods, CANCEL is an example of a SIP request that is a hop-by-
hop request. A proxy receiving a CANCEL request immediately responds with a 200 OK response, then
proxies the CANCEL on to the same set of destinations to which the original INVITE was sent. Auser agent
receiving a CANCEL replies with a 200 OK if a final response has not yet been sent, or a 481 Transaction
Unknown response if a final response has been sent. The latter corresponds to the race condition, where the
CANCEL and final response cross on the wire. In this condition, the user agent may have to send a BYE to
cancel the call. In the example of the rightmost figure, a user agent sends an INVITE request, and then a
CANCEL request. The INVITE is forwarded through two proxies to reach the destination user agent. Notice
that the CANCEL request sent to the first proxy results in a 200 OK response to the CANCEL, and the
CANCEL being forwarded to the next proxy. The second proxy immediately sends a 200 OK to the first proxy
and forwards the CANCEL to the destination user agent. Finally, the user agent responds with a 200 OK to
the CANCEL and a 487 Request Cancelled response to the INVITE. The 487 response is acknowledged by
the second proxy with an ACK, and then forwards the 487 to the first proxy, which eventually is received by
the calling user agent, which then knows that the pending session was successfully cancelled. (Non-success
final responses such as 3xx, 4xx, 5xx, or 6xx are always acknowledged on a hop-by-hop basis. Only a 200
OK receives an end-to-end ACK.) The user agent then has completed two transactions: a CANCEL/200 and
an INVITE/487/ACK transaction. Since it is possible that a CANCEL may be sent at the same time as a 200
OK response, the user agent must be prepared to send an ACK and a BYE to the 200 OK even after sending
the CANCEL.

97
The OPTIONS method is used to query a user agent or server about its capabilities and discover its
current availability. The response to the request lists the capabilities of the user agent or server. A proxy
never generates an OPTIONS request. A user agent or server responds to the request as it would to an
INVITE (i.e., if it is not accepting calls, it would respond with a 4xx or 6xx response). A success class
(2xx) response can contain Allow, Accept, Accept-Encoding, Accept-Language, and Supported headers
indicating its capabilities. An OPTIONS request may not contain a message body. A proxy determines if
an OPTIONS request is for itself by examining the Request-URI. If the Request-URI contains the address
of the proxy, the request is for the proxy. Otherwise, the OPTIONS is for another proxy or user agent and
the request is forwarded.

98
The REFER method is used by a user agent to request another user agent to access a URI or URL
resource. The resource is identified by a URI or URL in the required Refer-To header field . Note that the
URI or URL can be any type of URI: sip, sips, http, pres and so forth. When the URI is a sip or sips URI,
the REFER is probably being used to implement a call transfer service. REFER can also used to
implement peer-to-peer call control.
A REFER request can be sent either inside or outside an existing dialog. A typical call flow is shown in
the figure. In this example, a UAC sends a REFER to a UAS. The UAS, after performing whatever
authentication and authorization, decides to accept the REFER and responds with a 202 Accepted
response. Note that this response is sent immediately without waiting for the triggered request to
complete. This is important because REFER uses the non-INVITE method state machine, which requires
an immediate final response, unlike an INVITE which may take several seconds (or even minutes) to
complete. Since the Refer-To URI in this example is a sip URI, the UAC sends an INVITE setting the
Request-URI to the Refer-To URI. This INVITE is successful since it receives a 200 OK response. This
successful outcome is communicated back to the UAC using a NOTIFY method. The message body of
the NOTIFY contains a partial copy of the final response to the triggered request. In this case, it contains
the start-line SIP/2.0 200 OK. This part of a SIP message is described in the Content-Type header field
as a message/sipfrag.
Another example is the use of REFER to push a Web page. In the example of the second figure, the
UAC sends a REFER to the UAS with a Refer-To set to an HTTP URL or a Web page. This causes the
UAS to send a 202 Accepted then send a HTTP GET request to the Web server identified by the URL.
After the Web page has loaded, the UAS sends a NOTIFY containing a body and HTTP/1.0 200 OK.
A REFER and the SIP request triggered by the REFER may contain the Referred-By header field, which
contains information about who requested the request.

99
The figure shows an advanced use of REFER to implement a common PSTN or PBX feature known as
attended transfer. In this feature, the transferor is assumed to be in a dialog (in a session) with the transferee.
The transferor places the transferee on hold, then sends an INVITE to another party, called the transfer target.
After the session is established between the transferor and the transfer target, the transferor then puts the
target on hold. Now the transferor has two on hold sessions. The transferor then sends a REFER to the
transferee which causes the transferee to generate a new INVITE (called a triggered INVITE) to the target.
The successful INVITE replaces the existing session between the transferor and the transfer target. When
the transferee receives notification that the transfer was successful, the session between the transferor and
the transferee is terminated with a BYE. This application uses escaped header fields in the Refer-To URI.
That is, certain SIP header fields are specified and prepopulated in the URI, which are then copied into the
triggered INVITE. In this case, the transferor generates the Replaces header field necessary in the triggered
INVITE to make the transfer succeed. The transferee copies the escaped Replaces header and places it in
the INVITE.
The acceptance of a REFER with a 202 Accepted response creates an implicit subscription (a subscription
without sending a SUBSCRIBE request). After sending the 202 Accepted, the target must send an immediate
NOTIFY with the status 100 Trying and Subscription-State: active;expires=60, which indicates that the
subscription will expire in 60 seconds (the expiration value is chosen by the notifier). The Subscription-State
header contains the expiration time of the subscription. If that time period expires before the triggered request
has completed, both sides terminate the subscription, with the notifier sending a final notification.
The subscription is terminated when the transfer target (the party that accepted the REFER) sends a final
notification (a NOTIFY with Subscription-State: terminated;reason=noresource). Usually, this is after the
transfer target has received a final response to the triggered request. However, a transfer target that does not
wish to establish a subscription and provide a final result of the REFER may send an immediate NOTIFY
indicating that the subscription has been terminated. Each REFER sent creates a separate subscription. If
more than one REFER is sent within a dialog, the resulting notifications (and subscriptions) are identified by
an id parameter in the Event header field. The id parameter is optional in refer triggered NOTIFYs except
when multiple REFERs have been accepted, in which case it is mandatory.

100
The SUBSCRIBE method is used by a user agent to establish a subscription for the purpose of receiving
notifications (via the NOTIFY method) about a particular event. A successful subscription establishes a dialog
between the UAC and the UAS. The subscription request contains an Expires header field, which indicates the
desired duration of the existence of the subscription. After this time period passes, the subscription is automatically
terminated. The subscription can be refreshed by sending another SUBSCRIBE within the dialog before the
expiration time. A server accepting a subscription returns a 200 OK response also containing an Expires header
field. The expiration timer can be the same as the request, or the server may shorten the interval, but it may not
lengthen the interval. There is no UNSUBSCRIBE method used in SIPinstead a SUBSCRIBE with Expires:0
requests the termination of a subscription and hence the dialog. A terminated subscription (either due to timeout out
or a termination request) will result in a final NOTIFY indicating that the subscription has been terminated. A 202
Accepted response to a SUBSCRIBE does not indicate whether the subscription has been authorizedit merely
means it has been understood by the server. The basic call flow is shown in the figure. The client sends a
SUBSCRIBE, which is successful, and receives NOTIFYs as the requested events occur at the server. Before the
expiration of the subscription time, the client re-SUBSCRIBEs to extend the subscription and hence receives more
notifications. Note that a client must be prepared to receive a NOTIFY before receiving a 200 OK response to the
SUBSCRIBE. Also, due to forking, a client must be prepared to receive NOTIFYs from multiple servers (the
NOTIFYs will have different To tags and hence will establish separate dialogs), although only one 200 OK response
to the SUBSCRIBE may be received. The type of event subscription is indicated by the required Event header field
in the SUBSCRIBE request. Each application of the SIP Events framework defines a package with a unique event
tag. Each package defines the following things:
Default subscription expiration interval;
Expected SUBSCRIBE message bodies;
What events cause a NOTIFY to be sent, and what message body is expected in the NOTIFY;
Whether the NOTIFY contains complete state or increments (deltas);
Maximum notification rate.

101
The NOTIFY method is used by a user agent to convey information about the occurrence of a particular
event. A NOTIFY is always sent within a dialog when a subscription exists between the subscriber and
the notifier. However, it is possible for a subscription to be established using non-SIP means (no
SUBSCRIBE is sent) and may also be implicit in another SIP request type (for example, a REFER
establishes an implicit subscription). Since it is sent within a dialog, the NOTIFY will contain a To tag,
From tag, and existing Call-ID. A NOTIFY request normally receives a 200 OK response to indicate that
it has been received. If a 481 Dialog/Transaction Does Not Exist response is received, the subscription is
automatically terminated and no more NOTIFYs are sent. NOTIFY requests contain an Event header field
indicating the package and a Subscription-State header field indicating the current state of the
subscription. The Event header field will contain the package name used in the subscription. The
Subscription-State header field will either be active, pending, or terminated. A NOTIFY is always sent at
the start of a subscription and at the termination of a subscription. If a NOTIFY contains incremental
(delta) state information, the message body will contain a state version number that will be incremented
by 1 for each NOTIFY sent. This way, the receiver of the NOTIFY can tell if information is missing or
received out of sequence.

102
The MESSAGE method is used to transport instant messages (IM) using SIP. IM usually consists of short
message exchanged in near-real time by participants engaged in a conversation. MESSAGEs may be
sent within a dialog or outside a dialog, but they do not establish a dialog by themselves. The actual
message content is carried in the message body as a MIME attachment. All UAs that support the
MESSAGE method must support plain/text format, they may support other formats such as
message/cpim or text/html, or many others. A MESSAGE request normally receives a 200 OK response
to indicate that the message has been delivered to the final destination. An Instant Message response
should not be sent in the message body of a 200 OK, but rather a separate MESSAGE request sent to
the original sender. A 202 Accepted response indicates that the request has reached a store-and-forward
device and will likely eventually be delivered to the final destination. In neither case does the 2xx
response confirm that the message content has been rendered to the user.
A MESSAGE request may use the im (Instant Message) URI scheme in a Request-URI, although a client
should try to resolve to a sip or sips. An example MESSAGE call flow is shown in the figure.
Note that the MESSAGE method is not the only application of instant messaging with SIP. It is also
possible to use SIP to establish an instant message session in a completely analogous way that SIP is
commonly used to establish a media session. An INVITE could be used to establish the session with a
SDP body that describes the instant message protocol to be used directly between the two users. IM
sessions have been proposed using SIP MESSAGE, Common Presence and Instant Messaging (CPIM),
and even Jabber.

103
The INFO method is used by a user agent to send call signaling information to another user agent with
which it has an established media session. This is different from a re-INVITE since it does not change the
media characteristics of the call. The request is end-to-end, and is never initiated by proxies. A proxy will
always forward an INFO requestit is up to the UAS to check to see if the dialog is valid. INFO requests
for unknown dialogs receive a 481 Transaction/Dialog Does Not Exist response.
An INFO method typically contains a message body. The contents may be signaling information, a
midcall event, or some sort of stimulus. INFO has been proposed to carry certain PSTN midcall signaling
information such as ISUP USR (user to user) messages. The INFO method always increments the CSeq.

104
The PRACK method is used to acknowledge receipt of reliably transported provisional responses (1xx).
The reliability of 2xx, 3xx, 4xx, 5xx, and 6xx responses to INVITEs is achieved using the ACK method.
However, in cases where a provisional response, such as 180 Ringing, is critical in determining the call
state, it may be necessary for the receipt of a provisional response to be confirmed. The PRACK method
applies to all provisional responses except the 100 Trying response, which is never reliably transported.
A PRACK is generated by a UAC when a provisional response has been received containing a RSeq
reliable sequence number and a Supported: 100rel header. The PRACK echoes the number in the Rseq
and the CSeq of the response in a RAck header. The message flow is as shown in the figure. In this
example, the UAC sends the 180 Ringing response reliably by including the RSeq header. When no
PRACK is received from the UAC after the expiration of a timer, the response is retransmitted. The
receipt of the PRACK confirms the delivery of the response and stops all further transmissions.
The 200 OK response to the PRACK stops retransmissions of the PRACK request. The call completes
when the UAC sends the ACK in response to the 200 OK. Reliable responses are retransmitted using the
same exponential backoff mechanism used for final responses to an INVITE. The combination of Call-ID,
CSeq number, and RAck number allows the UAC to match the PRACK to the provisional response it is
acknowledging. As shown, the PRACK receives a 200 OK response, which can be distinguished from the
200 OK to the INVITE by the method contained in the CSeq header. The detailed use of the method (The
PRACK method always increments the CSeq. A PRACK may contain a message body.

105
The UPDATE method is used to modify the state of a session without changing the state of the dialog. A
session is established in SIP using an INVITE request in an offer/answer manner. Typically, a session
offer is made in the INVITE and an answer made in a response to the INVITE. In an established session,
a re-INVITE is used to update session parameters. However, neither party in a pending session (INVITE
sent but no final response received) may re-INVITEinstead, the UPDATE method is used. Possible
uses of UPDATE include muting or placing on hold pending media streams, performing QoS or other
end-to-end attribute negotiation prior to session establishment.

106
SIP has extensions to require preconditions.
Quality of service (QoS) can be supported in the network layer (IP layer 3) and in the link layer below (layer 2). QoS
in IP networks is independent of any specific application and the network, therefore, need not be aware of the
specifics of the applications (be they telephony, multimedia, financial transactions, or games). SIP is orthogonal to
QoS. Setting up an application such as a commercial-grade phone call with QoS requires the support of valuable
network resources (for example, giving priority to a media flow having a data rate of 100 kb/s for 30 minutes over a
distance of 5,000 km). The authorization required to provide the network resources for the SIP-initiated session
involves complex procedures for authentication, authorization, and accounting (AAA) that go beyond the topics
discussed here. We will, therefore, limit the discussion of QoS for SIP only for the simple case where the AAA issues
can be ignored. SIP enables user agents to establish sessions using the INVITE/200/ACK exchange. However, in
order to establish an IP session with QoS, a more complicated message exchange is required. The Integrated
Services QoS protocol assumed in these examples is the Resource Reservation Protocol (RSVP). However, the
approach described here for SIP will also work with other QoS approaches, such as setting the type of service
(TOS) bits in the IP header used in DiffServ. A simplified approach to QoS would be to first establish a best-effort
session between user agents, then use a re-INVITE to set up the new QoS session. However, since the SIP
messaging is completely independent of the media, it is entirely possible to successfully set up a session using SIP,
only to have the session fail because of lack of bandwidth for the media, in which case this approach will fail. Also,
there was a desire to mimic the behavior in the PSTN, where the called partys phone will not ring if there are not
sufficient resources (that is, trunks) to complete the call if answered. The approach described here was developed
by the PacketCable consortium for the Voice over Cable Modem project. This call flow makes use of three
extensions to SIP. The first is Early Media, which allows SDP to be present in the provisional 183 Session Progress
response. This allows an addition media (SDP) handshake between the user agents necessary to establish the QoS
prior to the call being answered. The second is the Reliable Provisional Responses extension to SIP, which allows a
lost provisional response such as a 183 to be detected and retransmitted. The receipt of the 183 response is
indicated by the PRACK (Provisional Response ACKnowledgement) message. The third extension is the use of the
COMET (preCOnditions MET) method, which allows the UAS to indicate the QoS preconditions have been met and
that the user may now be alerted, and the 180 Ringing response sent. The call then continues as per normal. Note
that the need for QoS was indicated in the last line of the SDP of the initial INVITE request, as shown here with the
attribute qos:mandatory:

107
108
The necessity of protocol interworking between networks based on SIP and ISUP was recognized by both the ITU and IETF who
independently developed alternative methods for SIP with ISUP encapsulation referred to as SIP-I and SIP-T, respectively. The
technical differences between the two methods of ISUP encapsulation are dealt with in detail later in the paper. An alternative to
SIP-T and SIP-I is BICC which was standardized by the ITU-T in 2000. BICC was developed to provide ISUP-like services over
broadband connections. It can be used to create, modify, and terminate packetized voice calls between switches.
SIP-I and SIP-T refer to two very similar approaches for interworking ISUP networks with SIP networks. In particular, they
provide the means for conveying ISUP-specific parameters through a SIP network so that calls that originate and terminate on
the ISUP network can transit a SIP network with no loss of information. SIP-T was developed by the IETF the same body that
developed the SIP protocol itself around the same time the most recent version of SIP was being developed (mid-2002). It is
defined by RFC 3372, RFC 3398, RFC 3578, and RFC 3204.
SIP-I was developed by the ITU in 2004, and made use of most of the constructs defined in the IETF SIP-T effort. It is defined by
ITU-T Q.1912.5. SIP-I and SIP-T both define the mapping of messages, parameters, and error codes between SIP and ISUP.
Both of them are fully interoperable with compliant SIP network components on the SIP network.
The key differences between SIP-I and SIP-T are:
SIP-I defines a mapping from SIP to BICC (in additional to ISUP), while SIP-T addresses only the ISUP case, and
SIP-T is inherently designed for interoperation with native SIP terminals, while SIP-I is restricted for use between PSTN
gateways only.
SIP-I and SIP-T also define somewhat different mappings of information between the protocols, mostly in terms of converting
from SIP error codes to ISUP cause codes.
The way SIP-I and SIP-T allow transparent transit of ISUP parameters through a SIP network is by attaching a literal copy of the
original ISUP message to the SIP message at the ingress PSTN gateway; this ISUP message appears as another body on the
SIP message (typically, a peer to an SDP body).
The SIP network ignores the extra ISUP body, processing the SIP message as it normally would. After the SIP service network
performs any necessary modifications to the SIP message, it arrives at the PSTN egress gateway. This egress gateway uses the
attached ISUP message as the basis for the ISUP message it will send; however, it first makes modifications necessary to match
changes made to the SIP message during its traversal of the SIP network.
As mentioned before, with SIP-T, the messages may also terminate on the native SIP terminals in the network, which will ignore
the extra ISUP body. Additionally, messages may originate from these SIP phones and terminate on the PSTN gateways, which
will then generate a new ISUP message for the PSTN.

109
There are three (3) session control protocols that interwork with the PSTN and can set up packetized voice calls (i.e.
VoATM or VoIP) between switches in a GSM/UMTS network:
Bearer Independent Call Control (BICC)
SIP-T
SIP-I
BICC was standardized by the International Telecommunication Union Standardization Sector (ITU-T), SIP-T by the
IETF, and SIP-I by ITU-T and then ANSI. BICC is a network level call control signaling protocol based on the
existing narrowband ISUP specifications. It inherits the message and parameter set of ISUP and can therefore
support the same services as ISUP. The Third Generation Partnership Project (3GPP) adopted BICC in the
Universal Mobile Telecommunications Service (UMTS) Release 4 (2001) standard, a decision that was ahead of its
time when compared to some of the other broadly adopted cellular standards of the day. Defined by the IETF in
2002, Session Initiation Protocol (SIP) for Telephones (SIP-T) provides an extension to the standard SIP protocol to
transport ISUP messages across a SIP network as attachments to the SIP messages. Defined by the ITU-T in 2004
and adopted by ANSI, Session Initiation Protocol (SIP) with encapsulated ISUP (SIP-I) also provides an extension to
the standard SIP protocol to transport ISUP messages across a SIP network as attachments to the SIP messages.
These three (3) specifications all include an architectural context for interworking, mappings for specific parameters,
and a mechanism for encapsulating ISUP messages. There are important technical differences between SIP-I and
SIP-T, as well as between BICC and SIP with ISUP encapsulation, however.
At a high level, although BICC is the current session control protocol standardized in the 3GPP R4 architecture and
deployed in some networks today, BICC is not an optimal choice for on-going evolution because it has been limited
to, and is predicted to remain limited to, operation within a GSM/UMTS context. It does not appear that BICC was
ever intended to, and currently being extended to, address domains beyond GSM/UMTS; as a result, BICC does not
automatically offer the future level of flexibility of continued development and evolution that would occur by selecting
one of the SIP with ISUP encapsulation variants (i.e. either SIP-T or SIP-I). In comparing and contrasting the two (2)
SIP technologies with ISUP encapsulation variants, the recommended direction for evolution is SIP-I based on a
detailed technical analysis of capabilities existing within the two standards in their current form and considering as
well the methods used to develop and evolve each standard. The two (2) standards differ in ways which can be
linked to the differences between IETF and ITU in terms of operational practices, operating objectives, and
underlying assumptions on industry dynamics and future industry evolution. The differences are highlighted next.
There are four (4) areas where SIP-I is better suited for a GSM/UMTS environment than SIP-T:
Assumptions regarding the trust and security environment
Encapsulation procedures & message mapping
Support of RFCs
User plane interoperability
In SIP-I, it is assumed that it is possible to provision trust domains and that any message received from an entity
within the trust domain can be treated as if it had come from a valid network node. On the other hand, SIP-T
assumes that trust can never be assumed on the basis of network location. The assumptions regarding trust
domains form a core on top of which the protocols were developed, and as such leads directly to increased
operational complexity in the case where it is assumed that trust domains do not exist.
SIP-T is largely underspecified with regard to encapsulation procedures and message mapping as compared with
SIP-I. The implication is that there is a higher degree of risk and uncertainty for initial SIP-T implementations which
could be addressed with an increased emphasis on comprehensive interoperability testing of products at the end of
the development cycle. The list of RFCs supported by SIP-I and SIP-T differ. For example, SIP-I provides a
normative list of RFCs, whereas SIP-T provides mostly inferences. The implication is that there is a higher degree of
risk and uncertainty associated with initial SIP-T implementations which could also be addressed with an increased
emphasis on interoperability testing. SIP-T does not give any attention to interoperability of the user plane or define
any media profile. SIP-I, however, defines a media profile and provides a normative list of RFCs which are required.
Similar comments apply about the increased risks and uncertainties with initial SIP-T implementations. It is therefore
recommended that all GSM/UMTS network operators put SIP-I on their network evolution roadmap as the session
control protocol and evolve to it over time as operational requirements and/or service delivery requirements emerge.
It is recognized that SIP-I/SIP-T adaptors or translators may be required to interface with some minor subset of
networks or network elements, but this does not invalidate or change the main conclusion that SIP-I is the optimal
session control protocol for GSM/UMTS networks.

110
111
112
113
114
115
116
117
Aspectos principales:
Manejado por el estado de la llamada
SIP-T define una mquina de estados formal para el mapeo
La semntica de los tipos de mensaje debe ser muy similar
Numerosos mensajes no tienen mapeo (por ej. SIP OPTIONS, ISUP CCR)

118
119
120
 Enfocado predominantemente en mapear la traslacin IAM/INVITE. En la prctica la mayora del
mapeo se relaciona con las identidades de los lado llamado y llamante.
Tiene soporte limitado para la indicacin SIP de portabilidad numrica y seleccin de carrier.
Requiere aprovisionar numerosos parmetros obligatorios con valores por defecto en las pasarelas
(por ejemplo, Naturaleza de la Conexin, Requisitos de Medio de Transmisin, etc.)

121
El mapeo de cdigos de respuesta transporta la razn para una falla de establecimiento cuando
el error est en el lado B de la llamada.
SIP-I y SIP-T toman aproximaciones radicalmente diferentes para mapear los cdigos. SIP-T
intenta mapear a un cdigo semnticamente similar, mientras que SIP-I mapea prcticamente
todos los cdigos ISUP a 500 Server Error de SIP y prcticamente todos los cdigos SIP a
127 Interworking, Unspecified
El mapeo no es necesariamente reversible (por ej., ISUP 34 SIP 503 ISUP 41).

122
123
124
Developed by the Internet Engineering Task Force (IETF), the Sigtran protocol suite lets operators carry
SS7 signaling traffic between a signaling gateway (SG) and a media gateway controller (MGC) or IP-
enabled signaling control point (IP-SCP), thus allowing carriers to maintain their SS7 signaling schemes
while being able to tap into the IP network for transport. Sigtran is a suite of networking protocols
consisting of toshe stream control transport protocol (SCTP) and a set of user adaptation (UA) layers
(which transform the look and feel of SCTP into the lower layers of SS7).
Sigtran currently defines four SS7-related adaptation layers. These include:
The message transfer part level 2 user adaptation (M2UA) layer provides the services of MTP2 in a
client-server situation, such as SG to MGC. Its user would be MTP3.
The message transfer part level 2 peer-to-peer adaptation (M2PA) layer provides the services of
message transfer part level 2 (MTP2) in a peer-to-peer situation, such as SG-to-SG connections. Its
user would be MTP3.
The message transfer part level 3 user adaptation (M3UA) layer provides the services of MTP3 in a
client-server situation, such as SG to MGC. Its users would be SCCP and/or ISUP.
The SS7 SCCP user adaptation (SUA) layer provides the services of the signaling connection control
part (SCCP) in a client-server architecture, such as SG-to-IP SCP. Its user would be TCAP, or
another transaction-based application part.

125
 SCTP vs. TCP

Multi-Streaming Multi-Homing

The stream control transport protocol (SCTP) is a new transport protocol defined by the Sigtran specification as a a
replacement for TCP. SCTP is designed to cope with time-sensitive signaling data while remaining flexible enough
for general use.
SCTP has been designed to counter some features of TCP that make it unsuitable for transporting real-time
signaling data, such as:
TCP is byte-streamedTCP provides a single stream of data and guarantees that data to be delivered in byte-
sequence order. This makes it ideal for delivery of large, unstructured pieces of data, such as a file or email
message. TCP is particularly sensitive to delays caused by network errors cause by loss of bytes, messages or
sequence violation. When this occurs, TCP will hold up delivery of all data (for all applications) until the correct
sequence is restored. Because of this, data for one application may be delayed due to problems in transporting
data from an unrelated application.
TCP timers are defined in terms of many seconds. In particular, the length of the connection, keep alive, and
retransmission timers may result in excessive delays.
There are no inherent security features in TCP itself.
SCTP is very similar to TCP, but has a number of features which aim to overcome the limitations listed above.
These include:
It defines timers of much shorter duration than TCP.
It supports multi-homing. Each SCTP endpoint may be known by multiple IP addresses. Routing to one address
is independent of all others and, if one route becomes unavailable, another will be used.
It uses an initialization procedure, based on cookies, to prevent denial of service attacks.
It supports bundling, where a single SCTP message may contain multiple 'chunks' of data. Each chunk contains
a whole signaling message.
It supports fragmentation, where a single signaling message may be split into multiple SCTP messages in order
to be accommodated within the underlying packet data unit (PDU).
It is message-oriented, defining structured frames of data. TCP, conversely, imposes no structure on the
transmitted stream of bytes.
It has a multi streaming capability. Data is split into multiple streams, each with independent sequenced delivery.
TCP has no such feature.
Multi-streaming is the main attraction. This feature allows users to partition a single IP connection between two
endpoints into separate logical streams of data, assigning each stream to a particular application or resource. The
principle is that errors or delays on one stream will not interfere with normal delivery on another.
Consider the example of SS7's ISDN user part (ISUP) protocol. ISUP carries signaling messages for many PSTN
resources (essentially trunk circuits). If three calls are in progress, then one of the calls experiencing a loss of data
should not cause a delay in transmission of messages relating to another call. The figure shows a situation where
ISUP is carried over TCP. A single 'pipe' of data carries all ISUP messages for all three calls.
If the establishment messages for all three calls are received correctly, then the calls are in progress. If the calls are
then released in the same order, but the release message for Call 1 is lost, then the release messages for the other
two calls will be delayed while TCP recognizes the loss of the message and recovers the data. This has the potential
to delay the release of Calls 2 and 3 for a large number of seconds, which is unacceptable in today PSTN world.
Consider now ISUP carried over SCTP. In this case, loss of a message relating to Call 1 affects only that stream of
data. Calls 2 and 3 are serviced as normal.

126
 Las cuatro capas de adaptacin de SIGTRAN

The Sigtran protocol defines four UA layers: the M2UA, M2PA, M3UA, and
SUA. All four of these layers service a common purpose: to carry a higher
layer's protocol messages from the point of termination in the SS7 network,
over an IP network, to the point of presence of the higher layer itself.
The higher SS7 layer would be message transfer part level 3 (MTP3) or above
(as described in the following sections) and would reside on either an MGC or
an IP-SCP. The purpose of the Nodal Interworking Function (NIF) is defined by
the UA in use. In general, it provides a mapping of management, data and
control messages from the UA to the specific lower SS7 layer.
1. The M2UA Layer
M2UA is used to transfer MTP2 user data between the MTP2 instance on a SG and the MTP3 instance on an MGC. As such, it
operates a client-server model, where the MGC is the client and the SG is the server. M2UA provides a means by which an
MTP2 service may be provided on an MGCin essence, extending SS7 into the IP network. Effectively, the MTP3 instance on
the MGC is the user of the MTP2 instance on the SG. Neither MTP2 nor MTP3 are aware that they are remote from one another.
This process, by which signaling messages are passed over IP from the top of one SS7 layer to the bottom of another, is
described as backhauling. The MTP3 user at the MGC would usually be ISUP. This architecture is most applicable when there is
a low density of SS7 links at a particular physical point in the network (perhaps as low as one) and when there are a large
number of physically separate SG functions (due to the SS7 links being physically located remotely from each other).
In this case, it makes sense to host MTP3 in the MGC. The SS7 address (the pointcode) of the system resides with MTP3. If
each SG had its own MTP3 layer, a large number of pointcodes would be required to implement a (logically) single gateway.
2. The M2PA Layer
M2PA is the peer-to-peer equivalent of M2UA. Rather than provide a link between remotely located MTP2 and MTP3 instances,
it replaces an MTP2 link beneath MTP3. The user of M2PA is MTP3 at both ends of the connection (with M2UA, one user is
MTP3 and the other is an SG IWF). This is not typical of the overview given in the figure. M2PA provides a means for peer MTP3
layers in SGs to communicate directly. In essence, it extends the reach of SS7 over the IP network. The M2PA architecture is
most applicable for a SG-to-SG connection, used to bridge two SS7 network 'islands'. In this case, each SG may connect to
multiple other SGs, none of which need to know about the upper layer that they are supporting. MTP3 is present on each SG to
provide routing and management of the MTP2/M2PA links. Because of the presence of MTP3, each SG would require its own
SS7 pointcode. Replacing MTP2 links with M2UA is a distinct case from accessing an IP-SCP from an SG (the service provided
by SUA). In the SUA case, it is known that the higher layer is TCAP and the SCCP services can be explicitly provided. M2PA, on
the other hand, has no knowledge of the upper SS7 layer.
3. The M3UA Layer
M3UA is similar to M2UA, in that it operates in a client-server way to provide an upper layer SS7 with protocol remote access to
the lower layers. M3UA, however, operates between an SG and an MGC, providing an MTP3 service on the MGC.
The MTP3 in the SG is unaware that the user is located on a different node. Similarly, the user layer at the MGC will be unaware
that it is not served by a local MTP3. This is another example of the MGC backhauling signaling messages from the SG.
This architecture is most appropriate when there is a high enough density of SS7 links to make a standalone SG viable. It is also
useful when the SS7 links are physically accessible at a single point.
Both situations highlighted in the paragraph above are common in North American networks, where the SS7 links are physically
separate from the voice circuits. In this case, a number of links are gathered together into a single physical medium (for example,
a T1 line). Here, each SG has a local MTP3 instance, and so must have its own SS7 pointcode.
4. The SUA Layer
SUA provides a means by which an application part (such as transaction application capabilities part [TCAP]) on an IP-SCP may
be reached via an SG. The network architecture associated with SUA allows for multiple IP-SCPs to be reached via a single SG.
The IP-SCP(s) do not have local MTP3 instances, and so do not require their own SS7 pointcodes (MTP3, and the pointcode,
reside on the SG). The functionality of SUA could be provided by M2UA or M3UA. However, SUA provides the mapping between
SCCP addresses and IP addresses (at the SG). Without such a function, SCCP would have to be present at each IP-SCP and
the external SS7 network would require knowledge of each such SCCP instance. SUA can abstract the presence of each IP
SCP, thus providing one SCCP address to cover all nodes.
SUA is also flexible enough to support application parts running between two network nodes wholly within the IP network. This is
particularly relevant to emerging networks, where there may be no need for an underlying 'traditional' SS7 network. In this case,
the IP-SCP stack would be the same on both (IP based) nodes.

127
128
MEGACO (Media Gateway Control Protocol), definido por el IETF, presenta muchas similitudes con el protocolo
MGCP (Media Gateway Control Protocol). Se trata de un protocolo de control entre las entidades MGC (Media
Gateway Controller) y MGW. (Media Gateway) MEGACO se denomina H.248 en el ITU-T y est por tanto definido
conjuntamente entre el IETF y el ITU-T. La especificacin MEGACO est escrita utilizando ABNF (Abstract Backus-
Naur Form) mientras que H.248 est descrito basndose en ASN 1 (Abstract Syntax Notation 1).
El protocolo MEGACO permite a estas dos entidades (MGC y MGW) intercambiar transacciones. Cada transaccin
se expresa por el envo de una transactionRequest por una de las entidades y el envo de una transactionReply por
la otra entidad. Una transactionRequest est formada por un conjunto de instrucciones, y una transactionReply
contiene el conjunto de respuestas correspondientes.
El modelo de conexin del protocolo MEGACO es un modelo orientado a objeto. Describe las entidades lgicas u
objetos en el seno del MGW que pueden ser controlados por el MGC. Las principales abstracciones utilizadas en
este modelo de conexin son las terminaciones (termination) y los contextos (context).
El protocolo MEGACO permite el establecimiento de llamadas multipartes a diferencia del protocolo MGCP, que
slo permite las llamadas entre dos partes. Una terminacin MEGACO comienza o termina uno o varios flujos. Una
terminacin est descrita por un conjunto de propiedades reagrupadas en un conjunto de descriptores incluidos en
las instrucciones. Una terminacin tiene una identidad nica (TermiantionId) atorgada en el momento de su
creacin por el MGW.
Ciertas terminaciones que representan entidades fsicas son semi-permanentes. Un circuito de voz ligado a un
MGW es un ejemplo de terminacin semi-permanente. Otras terminaciones representan flujos temporales tales
como los flujos RTP que slo existen durante el transcurso de la llamada correspondiente. Se trata de
terminaciones temporales.
Un contexto es una asociacin entre terminaciones. Existe un tipo especial de contexto, el contexto null, que
contiene todas las terminaciones no asociadas a otra terminacin. Por ejemplo, en un Trunking Gateway, todas las
lneas en reposo estn representadas por terminaciones del contexto null.
Las terminaciones temporales son creadas por la instruccin Add en el que la funcionalidad es similar a
CreateConnection del protocolo MGCP. Son suprimidas por la instruccin Substract correspondiente a
DeleteConnection con MGCP. Una terminacin fsica se aade a un contexto mediante la instruccin Add, y se
elimina del contexto null en el que se encontraba por defecto. Es retirada de un contexto dado mediante la
instruccin Substract, pasando a ocupar el contexto null.

129
 Escenario de establecimiento de llamada con MEGACO
En el ejemplo considerado en la figura, la direccin
del MGC es 128.23.31.11, la del RGW es
128.23.11.51 y la del TGW es 128.23.17.18 Para
simplificar, el puerto UDP utilizado para estas tres
entidades para la aplicacin MEGACO es 45678. El
MGC programa una terminacin dentro de un
contexto Null. Esta modificacin solicita a la
terminacin notificar al MGC del suceso de un
evento off-hook. El MGC emite un mensaje
TransactionRequest con un identificador de valor 1.
El MGC indica su direccin IP y el puerto UDP sobre
el que desea recibir la respuesta. El valor del
protocolo MEGACO utilizado es 1. El identificador de
terminacin cuyas propiedades van a ser
modificadas por el RGW es T1. El identificador de
peticin dentro del descriptor de eventos
(EventDescriptor) tiene el valor 1111. El identificador
de peticin es utilizado por el MGC para
correlacionar la peticin emitida con las
notificaciones devueltas por el RGW. El evento que
el RGW debe detectar y notificar al MGC es Off
Hook (of) del lote analog line supervisin (al). El
modo de esta terminacin est situado al valor
ReceiveOnly.
1. El RGW recibe la instruccin del MGC, la acepta y responde con un transactionReply cuyo nmero de
transaccin es idntico al de la transactionRequest correspondiente para permitir al MGC correlacionar la
peticin con su respuesta.
2. El usuario A descuelga su equipo telefnico para realizar una llamada. Este evento es detectado por el RGW,
que produce un mensaje Notify enviado al MGC. El RGW utiliza el mismo identificador de respuesta (1111) que
el que est presente en la peticin inicial del MGC. El momento de deteccin de la seal Off Hook es un
parmetro devuelto dentro del descriptor observedEventDescriptor en cntimos de segundo.
3. El MGC modifica la terminacin para pedir la emisin de una seal dial tone (dt) del lote call progress tones
generation (cg) al llamante. El descriptor DigitMapDescriptor permite asociar un DigitMap a la terminacin
tratada. El nombre del DigitMap en el ejemplo es Dmap1 y su valor contiene 12|0xxxxxxxxx que significa que el
llamante puede componer el nmero 12 o todo nmero de 10 cifras empezando por 0 y seguido de 9 cifras. El
descriptor de evento lista los eventos On Hook (on) del lote analog line supervisin (al) y el Digit map
completion event (ce) del lote DTMF detection (dd). El identificador de peticin es 1112. El RGW entonces
deber informar al MGC del nmero de destino marcado por el llamante y recogido por la terminacin, o del
suceso de un evento On Hook, que significa que el llamante abandona la llamada.
4. El RGW, en el momento de recepcin y validacin de la instruccin Modify, responde al MGC e inicia el
tratamiento de los descriptores presentes dentro de la instruccin.
5. Tras haber recibido la seal Dial Tone, el llamante marca el nmero de destino. Se considera el nmero vlido
segn el DigitMap, o sea 0143223454. El RGW notifica este nmero al MGC a travs de la instruccin Notify. El
identificador de peticin dentro del descriptor ObervedEventsDescriptor tiene el valor 1112. El evento observado
est descrito por su nmero (digit string (ds)), con un full match (FM).
6. El MGC confirma la recepcin de la instruccin Notify con una transactionReply.

130
7. El MGC solicita al RGW la creacin de un nuevo contexto cuyo identificador ser escogido por el RGW. Este
nuevo contexto deber contener la terminacin T1 que es semipermanente y una nueva terminacin temporal
cuyo identificador tambin ser designado por el RGW. El modo de las dos terminaciones es receive only, que
permite a las terminaciones recibir flujos pero no permite emitir, por el momento. El MGC sugiere al RGW la
utilizacin del codec G.723 para la nueva terminacin. El carcter $ es utilizado para la direccin IP y el puerto
RTP de esta terminacin. Su valor ser definido por el RGW. La terminacin T1 deber emitir una seal Ring
Tone (rt) del lote call progress tones generation (cg) al llamante para informar que el establecimiento de la
comunicacin est en curso.
8. Cuando se reciben las dos instrucciones Add, el RGW crea un contexto cuyo identificador tiene el valor 1.
Aade la terminacin T1. Una terminacin temporal cuyo identificador es T2 es creada y aadida al contexto 1.
La direccin IP asignada a esta terminacin es 43230. El RGW responde al MGC con una respuesta
transactionReply.
9. El MGC emite una transactionRequest al segundo Gateway, el TGW, para pedirle la creacin de un nuevo
contexto y aadir una terminacin semi-permanente que elegir el TGW y una nueva terminacin temporal cuyo
identificador ser escogido por el TGW. La terminacin semi-permanente corresponde a uno de los circuitos de
voz que el TGW comparte con un Class 5 Switch sobre el grupo de circuitos 1 (Trunk 1). El modo de la nueva
terminacin es ReceiveOnly. El MGC sugiere que la nueva terminacin utilice el codec G.723. El carcter $ es
utilizado por la direccin IP y el puerto RTP de esta nueva terminacin. Su valor ser asignado por el TGW. Por
otro lado, el MGC proporciona las informaciones SDP que describen la sesin a nivel del RGW (remote
descriptor). Esto permitir al TGW conocer el puerto UDP y la direccin IP donde el TGW deber emitir los
paquetes RTP que contienen la voz codificada con el codec G.723.
10. Cuando se recibe la TransactionRequest, el TGW crea un nuevo contexto cuyo identificador es 2. Aade la
terminacin semi-permanente cuyo identificador es Trunk1/line1. Crea una nueva terminacin llamada T3 y la
aade al contexto. Una direccin IP (128.23.28.14) y un puerto RTP (43300) son asignados por esta
terminacin. Estas informaciones son devueltas por el TGW al MGC a travs de una transactionReply.
11. Cuando el MGC recibe esta respuesta, emite un mensaje ISUP IAM transportado por SIGTRAN al SG (cf.
captulo 5). El SG remite este mensaje ISUP, a travs de su interfaz SS7, al Class 5 Switch que est conectado
con el destino. El Class 5 Switch traduce este mensaje en un mensaje de sealizacin enviado al terminal del
abonado (por ejemplo, mensaje SETUP en el caso de un terminal RDSI). El terminal abonado avisado genera
un mensaje Alerting (se trata de un terminal RDSI) emitido hacia el Class 5 Switch, que lo traduce en un
mensaje ISUP ACM reenviado al SG. El SG remite este mensaje ISUP ACM recibido sobre su interfaz SS7 al
MGC a travs de su interfaz SIGTRAN.
12. Cuando el llamado descuelga, el Class 5 Switch genera un mensaje ISUP ANM hacia el MGC a travs del SG:
13. Cuando se recibe el mensaje ISUP ANM, el MGC enva una instruccin Modify al RGW para proporcionarle la
descripcin de la sesin establecida por el TGW. Esto permite al RGW conocer el puerto RTP y la direccin IP
del TGW donde el RGW deber emitir los paquetes RTP. Por otro lado, el modo de las terminaciones T1 y T2
est situado al valor SendAndReceive.
14. El RGW responde con una transactionReply para informar al MGC de las modificaciones realizadas sobre las
terminaciones T1 y T2.
15. Por otro lado, el MGC emite una transactionRequest al TGW para pedirle situar el modo de la terminacin
temporal T3 al valor SendAndReceive. De este modo, los canales RTP unidireccionales establecidos entre las
dos terminaciones temporales emularn un canal de comunicacin bidireccional entre el RGW y el TGW.
16. El TGW confirma las modificaciones al MGC
17. A partir de este momento, puede iniciarse la comunicacin entre los dos participantes, uno de ellos conectado
al RGW y el otro a un Class 5 Switch. La comunicacin entre los dos participantes est establecida mediante
canales RTP entre los dos Gateways y por un circuito de voz establecido entre el TGW y el Class 5 Switch

131
Cuando uno de los participantes descuelga (por ejemplo, el llamante), el RGW indica al MGC el suceso del evento
On Hook
1. El MGC acusa la recepcin de esta transaccin con una respuesta transactionReply.ok (on) del lote analog line
supervisin (al).
2. Entonces, el MGC emite mensajes Substract al RGW y al TGW. El MGC pide al RGW el suministro de
estadsticas de utilizacin de la terminacin temporal T2.
3. Cuando se recibe la peticin, el RGW elimina la terminacin temporal T2 y mueve la terminacin semi-
permanente T1 a un contexto ntull. El contexto cuyo identificador es 1 es suprimido. El RGW devuelve al MGC
estadsticas de utilizacin de la terminacin temporal, principalmente el nmero de paquetes RTP emitidos (ps,
packets sent), el nmero de octetos emitidos (os, octets sent), el nmero de paquetes RTP recibidos (pr,
packets received), el nmero de octetos recibidos (or, octets received), el porcentaje de prdida de paquetes
RTP (pl, packets lost), la fluctuacin en el flujo RTP (jitter), y la latencia mediana, que es el tiempo de
propagacin de los paquetes RTP (delay, average latency). A destacar que cada erminacin posee su propio
lote de estadsticas recogidas. Las estadsticas son propiedades de los lotes red (nt) y RTP (rtp).
4. El MGC genera una transaccin equivalente emitida hacia el TGW para suprimir las terminaciones y pedir
estadsticas de utilizacin de la terminacin temporal T3.
5. El TGW responde a la peticin informando al MGC de las estadsticas de utilizacin de T3, de la eliminacin de
T3, de la eliminacin del contexto cuyo identificador es 2 y del posicionamiento de la terminacin semi-
permanente Trunk1/line1 en el contexto null.
6. Por otro lado, el MGC enva un mensaje ISUP REL (Release) al Class 5 Switch a travs del SG para pedirle la
liberacin del circuito de voz establecido co el TGW. El Class 5 Switch responde con un mensaje ISUP RLC
(Release Complete) para confirmar la liberacin del circuito al MGC.

132
133
1G First Generation Cellular Wireless
La primera generacin celular se bas en tecnologa analgica. Los sistemas se disearon
para transportar nicamente voz.
2G Second Generation Cellular Wireless
La tecnologa 2G convierte la voz a datos digitales para su transmisin en el aire y la
reconvierte a voz en el receptor. La mayora de los sistemas 2G ofrecan servicios de datos
conmutados por circuito de 9.6-14.4 Kbps.
2.5G Enhanced Second Generation Cellular Wireless
La tecnologa 2.5G se refiere al agregado realizado en las redes 2G para ofrecer servicios
de datos por paquetes. Es sinnimo de la tecnologa GPRS definida por el 3GPP Release
97
3G Third Generation Cellular Wireless
Los sistemas 3G se disearon para voz y datos. Por la definicin de la ITU, deben proveer
servicios de datos a 144 Kbps.
3.5G Enhanced Third Generation Cellular Wireless
3.5G refiere a las actualizaciones de los servicios 3G que proveen rendimientos
significativamente mejorados para la comunicacin de datos.

134
El sector de las comunicaciones mviles celulares ha mostrado un gran dinamismo en las dos
ltimas dcadas. Los inicios de la dcada de los 1990 vinieron marcados por el crecimiento
exponencial de usuarios de voz al amparo de un entorno cada vez ms competitivo y con
predominancia de la tecnologa GSM como estndar de facto a nivel mundial. Posteriormente, y
contrariamente a lo que pronosticaban muchos estudios de mercado, la madurez alcanzada en el
servicio de voz no se vio relevada por los servicios de datos en los primeros aos de los 2000 de la
mano del cambio tecnolgico asociado a la implantacin del acceso radio WCDMA de UMTS. A
nivel global, la principal competencia de UMTS es cdma2000, emanado del 3GPP2. La clara
necesidad de mayores velocidades de transmisin de datos como condicin necesaria para el
eventual despegue de estos servicios encuentra respuesta en la tecnologa HSPA, y
equivalentemente EV-DO en el contexto 3GPP2, elementos a la postre facilitadores del crecimiento
exponencial del trfico de datos observado desde 2007, junto con la generalizacin de las tarifas
planas para el acceso a Internet mvil. El camino apuntado por el 3GPP para cubrir las
necesidades tecnolgicas en el horizonte 2010-2020 tiene a LTE como mximo exponente. La
predominancia de LTE supone el fin del camino paralelo del 3GPP2, que abandona el desarrollo de
UMB, equivalente a LTE. El contrapunto competitivo para LTE intenta impulsarse desde IEEE con
WiMAX 802.16e y posteriormente 802.16m, como solucin propiamente IMT-Advanced (sistema
4G), al igual que la propuesta LTE-Advanced por parte del 3GPP. Sin embargo, se ha visto en los
ltimos aos el declive de la tecnologa WiMAX debido a su mayor costo y dificultad de integracin
con los sistemas mviles 3G ya existentes, lo que impeda el traspaso de servicios entre una y otra
tecnologa, motivando a las compaas celulares a inclinarse por el camino lgico de evolucin que
lleva a LTE.

135
En el caso de LTE, las especificaciones emanan del 3GPP (3rd Generation Partnership Project), que
naci en 1998 con el objetivo de especificar 3G (UTRA-FDD y UTRA-TDD). Tambin se encarga de
mantener y desarrollar las especificaciones de GERAN (GSM EDGE RAN). La red de acceso radio se
especifica en el marco del TSG RAN, que se organiza en cinco grupos de trabajo: WG1 (capa fsica),
WG2 (capas 2 y 3), WG3 (interfaces fijos de la red de acceso), WG4 (aspectos de RF y RRM) y WG5
(conformidad de terminales). Los documentos del 3GPP se estructuran en Releases, cada una de ellas
caracterizada por la incorporacin de un conjunto de funcionalidades destacadas en relacin a la
versin anterior. As, la que se llam R99 (por el hecho de que se congel en diciembre de 1999)
supuso el primer conjunto de especificaciones UMTS. Seguidamente, tras la llamada R4, se complet
en marzo de 2002 la R5 que incluye por ejemplo HSDPA. Tres aos despus se incorpora HSUPA as
como MBMS en R6. En la R7 (septiembre de 2007) se incluye HSPA+, mientras que LTE/SAE se
asocian ya a R8 y posteriores.
Puede decirse que el primer paso hacia LTE se llev a cabo en noviembre de 2004, cuando 3GPP
TSG RAN organiz un Workshop sobre RAN Evolution en Toronto (Canad), en el que se
presentaron unas 40 contribuciones con ideas, propuestas, etc. En el propio Workshop se identificaron
una serie de requisitos de alto nivel, como un coste por bit reducido, mejora en la provisin de
servicios, flexibilidad en el uso de las bandas frecuenciales, arquitectura simplificada con interfaces
abiertas, consumo de potencia en el terminal razonable, etc. Tambin se puso de manifiesto que el
esfuerzo de estandarizacin que esta evolucin, bautizada como E-UTRAN (Evolved UTRAN), llevara
asociado slo resultara justificable si las mejoras fueran significativas.
En diciembre de 2004 se cre el Study Item Evolved UTRA and UTRAN para la evolucin hacia una
tecnologa de acceso de elevada velocidad de transmisin, baja latencia y optimizada para la
transmisin de paquetes, de modo que con ello quedase asegurada la competitividad de las
soluciones 3GPP en un horizonte temporal largo.

136
Evolucin de las redes mviles: IMT-Advanced del ITU-T
En Enero 2012, durante la Asamblea de Radiocomunicaciones en Gnova, la ITU aprob las
especificaciones finales para la siguiente generacin de banda ancha inalmbrica, bajo el marco
regulatorio de IMT-Advanced, consolidando el anteproyecto esbozado desde el ao 2008, y determin
que las tecnologas LTE-Advanced y WirelessMAN-Advanced (WiMAX 2) cumplen con las nuevas
exigencias de proveer hasta 100 Mbps sobre terminales mviles que se desplazan a velocidades de
hasta 120 Kmph.
IMT-Advanced provee un marco de especificaciones evolutivo sobre las especificaciones IMT-2000,
ya que las velocidades que pueden ser provistas por las nuevas tecnologas son hasta 500 veces
superiores a las de una conexin 3G de IMT-2000, gracias al uso de tecnologas con muy alta
eficiencia espectral medida en bps/Hz.
IMT-Advanced cubre mltiples servicios basados en telecomunicaciones por conmutacin de
paquetes tanto para redes mviles, como el caso de LTE-Advanced, como para redes fijas, con
WiMAX 2. Adems del avance en las velocidades sobre los terminales fijos y mviles, que
representan un enorme salto para las capacidades de las redes actuales fijas y mviles, IMT-
Advanced define los medios para el empleo masivo de multimedia sincrnica como HDTV,
videoconferencias de alta definicin, MMS (Multimedia Messaging Services), juegos y entretenimiento
con prestaciones avanzadas en velocidad, resolucin y capacidades multiusuario, sin requerir
accesos desde terminales fijas en desktops.
El marco IMT-Advanced, inicialmente delineado por la UIT en el ao 2008, permite que sean
comercializadas como 4G las tecnologas LTE-Advanced en telefona mvil y WiMAX 2 en redes
terrestres, para accesos a Internet. Un sistema IMT-Advanced est enteramente basado en sesiones
IP securizadas, aplicables sobre una amplia gama de dispositivos como smartphones, laptops,
notebooks, tablets y otros dispositivos mviles.
Velocidades pico promedio de 100 Mbps sobre terminales en movimiento a velocidades elevadas
con respecto a la estacin base, y de 1 Gbps pico promedio cuando las terminales estn en reposo
se mueven lentamente.
Anchos de banda de RF escalables para diferentes redes de operadores, entre 5 y 40+ Mhz.
Eficiencia espectral pico de 15 bps/Hz en el downlink y de 6.75 bps/Hz en el uplink, requiriendo 67
Mhz para proveer 1 Gbps pico promedio en el downlink sobre un terminal.
Eficiencia espectral de una celda del sistema de 3bps/Hz/celda en el downlink y de 2.25
bps/Hz/celda para su empleo en picoceldas en interiores.
Sistemas enteramente basados en redes IPv4 e IPv6, indistintamente.
Interoperabilidad con los standares inalmbricos actuales.
Capacidad de proveer QoS de alta calidad, para el soporte de diferentes servicios multimedia.
Aprovechamiento dinmico de recursos de red para el soporte de mayor cantidad de usuarios por
celda.
Conectividad y roaming global a travs de mltiples redes sin percepcin del usuario, mediante
traspasos blandos.
Mientras que 3GPP ha estado activo introduciendo el primer conjunto de requerimientos de LTE-
Advanced en Junio del 2008 y el primer conjunto de standares en el Release 10 de 3GPP, otros
organismos normalizadores como el IEEE y el WiMAX Forum han estado desarrollando las
especificaciones para IMT-Advanced alrededor del standart IEEE 802.16e (WiMAX mvil), y estos
grupos y otros afines estn desarrollando especificaciones para la interoperabilidad de los sistemas
IMT-Advanced como son LTE-Advanced y WiMAX 2 (IEEE 802.16m).
El grupo WP 5D de la ITU-R, ha aprobado en Octubre 2010, las tecnologas LTE-Advanced y WiMAX
2 como parte del marco IMT-Advanced y, en Diciembre 2010, la ITU ha considerado que ambas
tecnologas pueden utilizar el trmino 4G con propsitos de marketing debido al sustancial avance
sobre tecnologas previas, an cuando las mismas no cumplen an completamente con las
especificaciones del marco de IMT-Advanced.

137
Una funcionalidad importante de las redes de comunicaciones mviles es el soporte del servicio
de itinerancia (roaming). Este servicio permite que los usuarios puedan acceder a sus servicios de
telecomunicacin a travs de las redes de otros operadores con los que no tienen establecida
ninguna relacin contractual (subscripcin). A efectos de nomenclatura, el operador con el que el
usuario tiene establecida la relacin contractual para la prestacin de servicios se conoce como
operador matriz, y por extensin, la red de dicho operador constituye la red matriz (Home
Network). La red de otro operador a la que el usuario puede tener acceso se denomina red
visitada (Visited Network).

138
Se ilustra una arquitectura simplificada de un sistema de comunicaciones mviles celular. Esta arquitectura
representa un modelo de la red a muy alto nivel donde se identifican tres componentes bsicos:
Equipo de usuario, dispositivo que permite al usuario acceder a los servicios de la red. El equipo de usuario
puede incluir una tarjeta inteligente (Universal Integrated Circuit Card, UICC) que contenga la informacin
necesaria para permitir la conexin a la red y la utilizacin de sus servicios (e.g., identificador nico del
usuario en el sistema de comunicaciones). El equipo de usuario se conecta a la red de acceso a travs de
una interfaz radio.
Red de acceso, parte del sistema responsable de sustentar la transmisin radio con los equipos de usuario
de cara a proporcionar la conectividad necesaria entre stos y los equipos de la red troncal. Los servicios de
transmisin ofrecidos por la red de acceso para transportar la informacin de los equipos de usuario (tanto
informacin de datos como sealizacin) hacia/desde la red troncal son servicios portadores, es decir,
servicios cuya finalidad ltima es la provisin de una cierta capacidad de transmisin. La red de acceso es la
responsable de gestionar el uso de los recursos radio disponibles para la provisin de servicios portadores
de forma eficiente. La activacin de los recursos de transmisin en la red de acceso se controla
generalmente desde la red troncal. La red de acceso est formada por estaciones base y, en los sistemas
mviles actuales 2G y 3G, tambin por equipos controladores de las estaciones base.
Red troncal, parte del sistema encargado de aspectos tales como control de acceso a la red celular (e.g.,
autenticacin de los usuarios del sistema), gestin de la movilidad de los usuarios, gestin de las sesiones
de datos o circuitos que transportan la informacin de los usuarios, mecanismos de interconexin con otras
redes, etc. Tambin pueden forman parte de la red troncal las funciones asociadas con el control de los
servicios finales ofrecidos a los usuarios (e.g., control y sealizacin asociada al servicio de telefona). La
red troncal est formada por equipos que albergan funciones de conmutacin de circuitos, encaminamiento
de paquetes, bases de datos, etc.
Esta arquitectura genrica ha sido adoptada en las diferentes familias de sistemas celulares 2G y 3G, y tambin
se mantiene en el sistema LTE. La separacin entre la red de acceso y red troncal confiere un importante grado
de flexibilidad al sistema de cara a soportar un proceso evolutivo en el que se puedan ir mejorando, agregando
o sustituyendo las diferentes partes de la red con la mnima afectacin posible al resto de la misma.

139
Se muestran dos escenarios representativos de la provisin de servicios de comunicacin a travs
de redes de comunicaciones mviles celulares. En el escenario (a) se ilustra una red celular que
sustenta servicios de comunicacin (e.g., llamadas de voz) entre los equipos de usuario
conectados a ella. En el escenario (b) se muestra la provisin de los servicios de comunicacin
entre equipos de usuario operando en redes celulares diferentes interconectadas entre s
mediante redes de trnsito.
Los servicios finales son los diferentes servicios de comunicacin (e.g., telefona,
videoconferencia, etc.) que se ofrecen a travs del sistema. El calificativo finales se utiliza para
enfatizar la diferencia entre estos servicios y los servicios portadores. Un servicio portador
bsicamente se concibe como un servicio de transporte de informacin entre dos puntos de la red.
As, el transporte de la informacin generada por los servicios finales se realiza a travs de los
servicios portadores que ofrece la red.

140
En la Figura se representa un escenario ilustrativo de la provisin de servicios entre equipos
conectados a redes celulares y equipos localizados en otras redes (e.g., red telefnica, Internet,
etc.).

141
142
Basado en la naturaleza del trfico:
Conmutado por paquetes: (PS)
Conmutado por circuitos. (CS)
El dominio es el mayor nivel de un grupo de entidades fsicas y las interfaces definidas entre
dichos dominios (3GPP spec. TR 21-905)
La estructura de protocolos y responsabilidades se divide como:
Estrato de acceso: Actividades de manejo de protocolo entre el Equipo de Usuario (UE) y la
red de acceso
Estrato de no-acceso: actividades de manejo de protocolo entre el UE y la red Ncleo (CN)
Un estrato (stratum) es la manera de agrupar los protocolos relacionados a un aspecto de los
servicios provistos por uno o varios dominios (3GPP spec. TR 21-905)

143
 Dominios de Equipo de Usuario
Dominio Equipo Mvil (ME):
Entidad de Terminacin Mvil (MT) que realiza la transmisin de radio y funciones
relacionadas
Entidad de Equipo terminal (TE) conteniendo la aplicacin extremo a extremo
Dominio de Mdulo de Identidad de usuario (USIM); contiene datos y procedimientos para
identificarse de manera segura y definida.
Dominios de Infraestructura
Dominio de Red de Acceso: entidades fsicas que administran los recursos de red de
acceso y proveen a los usuarios de mecanismos para acceder a la red ncleo
Dominio de Red Ncleo: entidades fsicas que proveen soporte para las caractersticas de
red y servicios de telecomunicaciones: administracin de la informacin de ubicacin del
usuario, control de caractersticas y servicios de red, conmutacin y transmisin de
servicios.

144
145
 Arquitectura genrica de los sistemas 3GPP

Las arquitecturas de red contempladas en la familia de sistemas especificados por 3GPP se adaptan a la
arquitectura genrica descrita en el apartado anterior. As pues, tal como se representa en la Figura, los
sistemas 3GPP abarcan la especificacin del equipo de usuario (User Equipment, UE) y de una infraestructura
de red que se divide de forma lgica en una infraestructura de red troncal (Core Network, CN) y una de red de
acceso (Access Network, AN).
El equipo de usuario en 3GPP se compone de dos elementos bsicos: el propio dispositivo mvil o terminal
(denominado como Mobile Equipment, ME) y una tarjeta UICC. La tarjeta UICC, tambin denominada SIM
(Subscriber Identity Module) en sistemas GSM y USIM (Universal SIM) en UMTS y LTE, es la encargada de
almacenar la informacin y sustentar los procedimientos que tienen que ver con la subscripcin del usuario a los
servicios proporcionados por la red. Mediante esta separacin entre terminal y tarjeta se permite que un usuario
(identificado a travs de la SIM/USIM) pueda utilizar diferentes terminales para acceder a la red.
Respecto a la red de acceso, 3GPP ha especificado tres tipos de redes de acceso diferentes:
GERAN (GSM/EDGE Radio Access Network), UTRAN (UMTS Terrestrial Radio Access Network) y E-UTRAN
(Evolved UTRAN). Las redes de acceso GERAN y UTRAN forman parte del sistema 3G UMTS mientras que E-
UTRAN es la nueva red de acceso del sistema LTE. Cada red de acceso define su propia interfaz radio para la
comunicacin con los equipos de usuario:
GERAN, tambin denominada de forma habitual simplemente como GSM, utiliza un acceso basado en TDMA, la
tecnologa utilizada en UTRAN es WCDMA y, E-UTRAN ha apostado por la tecnologa OFDMA. Asimismo, la
interconexin de las redes de acceso a la red troncal se realiza mediante interfaces AN-CN especficas a cada
una de ellas. Respecto a la red troncal, sta se divide de forma lgica en un dominio de circuitos (Circuit
Swiched, CS, Domain), un dominio de paquetes (Packet Switched, PS, Domain) y el subsistema IP Multimedia
(IP Multimedia Subsystem, IMS).
El dominio CS alberga a todas las entidades de la red troncal que participan en la provisin de servicios de
telecomunicacin basados en conmutacin de circuitos, es decir, servicios a los que se les asignan recursos de
forma dedicada (circuitos) en el momento de establecimiento de la conexin, mantenindose stos hasta la
finalizacin del servicio (e.g., servicios de voz y videoconferencia en redes UMTS). El dominio de circuitos de la
red troncal es accesible a travs de las redes de acceso UTRAN y GERAN. En cambio, el diseo de E-UTRAN
no contempla el acceso al dominio CS ya que todos los servicios se proporcionan a travs del dominio PS.
El dominio PS incluye a las entidades de la red troncal que proporcionan servicios de telecomunicacin basados
en conmutacin de paquetes: la informacin de usuario se estructura en paquetes de datos que se encaminan y
transmiten por los diferentes elementos y enlaces de la red. En particular, el dominio PS proporciona un servicio
de conectividad a redes de paquetes (e.g., redes IP y X.25). Existen dos implementaciones diferentes del
dominio PS: GPRS y EPC. GPRS es la implementacin del dominio PS que se desarroll inicialmente en el
contexto de redes GSM y que actualmente tambin forma parte del sistema UMTS. Los servicios de conectividad
por paquetes de GPRS son accesibles tanto a travs de UTRAN como de GERAN. Por otro lado, EPC es la
nueva especificacin del dominio PS desarrollada en el contexto del sistema LTE.

146
147
148
En el desarrollo de especificaciones para IMS se presenta el objetivo claro de utilizar protocolos estndar
de Internet, los cuales hansido tradicionalmente desarrollados por el IETF. De este modo, se mantiene la
compatibilidad con las tecnologas utilizadas en las redes de paquetes actuales, reducindose tambin
el tiempo empleado en los procesos de estandarizacin y de desarrollo.
Un hecho determinante que sin duda ha influido en el diseo de la arquitectura del Subsistema
Multimedia IP ha sido la eleccin del Protocolo de Iniciacin de Sesin (Session Initiation Protocol, SIP)
para implementar las funcionalidades relacionadas con el control de sesiones multimedia. SIP es un
protocolo de nivel de aplicacin que permite establecer, mantener y liberar sesiones multimedia sobre
redes basadas en el protocolo IP. Estas sesiones multimedia, proporcionan la base sobre la cual se
proveen en IMS los servicios que son accesibles al usuario. De este modo, SIP es el protocolo clave en
IMS que habilita a los usuarios para acceder a los distintos servicios multimedia ofrecidos por el
operador.
Adicionalmente, en el proceso de establecimiento de sesiones multimedia otros dos protocolos
adquieren especial relevancia: el protocolo de Descripcin de Sesin (Session Description Protocol,
SDP) y el modelo Oferta/Respuesta de SDP. SDP permite describir sesiones multimedia, mientras que
el modelo Oferta/Respuesta de SDP permite a los participantes en una sesin llegar a un acuerdo sobre
los distintos parmetros que la caracterizan. De este modo, SIP, SDP y el modelo Oferta/Respuesta de
SDP soportan el establecimiento de la sesin multimedia con los parmetros negociados por los
participantes en la misma.
Por otro lado, Diameter es el protocolo utilizado en IMS en los procesos de autenticacin, autorizacin y
facturacin. Diameter consiste en un protocolo base, cuya funcionalidad se extiende mediante
Aplicaciones de Diameter. Dichas aplicaciones permiten particularizar el protocolo en funcin de la
finalidad para la que se desea utilizar. IMS utiliza el protocolo Diameter en varias interfaces, si bien no
todas las interfaces utilizan la misma Aplicacin de Diameter.
Finalmente, los protocolos RTP (Real-time Transport Protocol) y RTCP (RTP Control Protocol) se utilizan
para transmitir informacin de usuario en tiempo real, ej. audio o vdeo.

149
La arquitectura IMS puede ser estructurada en capas. Cuatro capas importantes son identificadas:
La capa de ACCESO puede representar todo acceso de alta velocidad tal como: UMTS Terrestrial Radio
Access Network o UTRAN, CDMA2000 tecnologa de acceso de banda ancha usada en las redes mviles
en Estados Unidos, xDSL, redes de cable, Wireless IP, WiFi, etc...
La capa de TRANSPORTE representa una red IP. Esta red IP podr integrar mecanismos de calidad de
servicios con MPLS, Diffserv, RSVP, etc... La capa de transporte esta compuesta de enrutadores o routers
(edge routers para el acceso y core routers para el transito), conectados por una red de transmisin. Distintas
pilas de transmisin pueden ser contempladas para la red IP: IP/ATM/SDH, IP/Ethernet, IP/SDH, etc.
La capa CONTROL consiste en controladores de sesin responsables del encaminamiento de la sealizacin
entre usuarios y de la invocacin de los servicios. Estos nodos se llaman Call State Control Function o CSCF.
El IMS introduce entonces un mbito de control de sesiones sobre el campo de paquetes.
La capa APLICACIN introduce las aplicaciones (servicios de valor agregado) propuestas a los usuarios. El
operador puede posicionarse gracias a su capa CONTROL como integrador de servicios ofrecidos por el mismo
o bien por terceros. La capa aplicacin consiste en servidores de aplicacin Aplication Server o AS y
Multimedia Resource Function o MRF que los proveedores llaman Servidores de Media IP (IP Media Sever
o IP MS)

150
 Conceptos Subyacentes de la Arquitectura
Un conjunto de necesidades han sido definidos durante la concepcin del IMS :
Conectividad IP : El usuario debe disponer de la conectividad IP para acceder a los servicios IMS. Por
otra parte, el protocolo Ipv6 es necesario. La razn fundamental que justifica el uso del Ipv6 es la
carencia de direcciones Ipv4 para permitir a cada mvil (si contemplamos la aplicacin del IMS a las
redes mviles) disponer de una direccin IP con un modo de acceso permanente. Soluciones del tipo
traduccin de la direccin de red (Network Address Translation o NAT) solo pueden ser
temporarias. Nuevos servicios tales como el acceso permanente, el tele cargamento sistemtico, la
auto-configuracin, las aplicaciones en tiempo-real (telefona), la seguridad etc... pasaran, en un futuro
cercano, las posibilidades de la tecnologa NAT.
Con Ipv6, los campos de direccin tienen 16 bytes, a diferencia de las direcciones de Ipv4
sobre 4 bytes. El Ipv6 ofrece en consecuencia un espacio de direccionamiento ampliado
permitiendo otorgar una direccin nica a cada equipo Internet mvil (una necesidad
imprescindible para los equipos siempre conectados).
El Ipv6 permite configurar automticamente la direccin IP de la maquina Host, sin tener que
acudir al protocolo de configuracin dinmica de la maquina Host (Dynamic Host
Configuraction Protocol o DHCP), proceso valioso para los equipos mviles.
El Ipv6 maneja la seguridad de un lado al otro de toda la cadena. La red mvil puede ser
considerada como una red cerrada de la cual el interfuncionamiento con la red antecedente
Ipv4 esta asegurado a la periferia de la red (con routers pasarela ejecutando apilamientos IP
dobles con tneles Ipv6-Ipv4, etc)
Independencia hacia el acceso : el IMS ha sido concebido para ser independiente del acceso con el
fin que los servicios IMS puedan ser ofrecidos desde cualquier tipo de acceso conectado a una red IP
(GPRS, UMTS, Wlan, xDSL, cable, etc...).
Garanta de Calidad de Servicio del los servicios multimedia : en el Internet, el tipo de Calidad de
Servicio ofrecido es Best Effort o Mejor Esfuerzo. Eso no va a ser el caso con el IMS. Las redes de
acceso y de transporte del IMS ofrecen la Calidad de Servicio del principio al final de la cadena. A
travs del IMS, el terminal negocia sus capacidades y expresa sus exigencias de Calidad de Servicio
durante la fase de establecimiento de sesin con el protocolo SIP. En paralelo, el terminal reserva los
recursos necesarios en la red de acceso utilizando un protocolo de red de recursos. (RSVP, SM/GTP1,
etc...)
Control Poltico : El control poltico IP significa la capacidad de autorizar y controlar el uso del trafico a
nivel de media en el IMS, sobre la base de parmetros de la sealizacin SIP intercambiada durante el
establecimiento de la sesin. Eso requiere interacciones entre la red de acceso y el IMS logrado
gracias al protocolo Common Open Policy Service o COPS.
Comunicaciones Segurizadas : el IMS brinda mecanismos de seguridad similares a los de las redes
GSM y GPRS. Por ejemplo, el IMS asegura que le usuario ha sido autentificado antes de poder usar el
servicio.
Tasacin : el IMS brinda distintos modelos de tasacin : off-line (pospago) y on-line (prepago).
Soporte de Roaming : el usuario puede acceder a sus servicios IMS desde cualquier red IMS visitada.
La movilidad del usuario (nomadismo) y de sus servicios son tomados en cuenta.
Interfuncionamiento con otras redes : el IMS no va a ser desplegado en todas partes en el mismo
momento. Es entonces necesario prever pasarelas entre las redes RTC/GSM y la red IMS. Estas
pasarelas de media (Media Gateways) son controladas por Softswitches. El IMS identifica tambin un
Signalling Gateway permitiendo entregar la sealizacin ISUP del RTC/GSM al Softswitch sobre
SIGTRAN.
Control de servicios : el IMS brinda todos los elementos que permiten conocer los servicios suscritos
por el usuario e invocarlos para toda sesin saliente o entrante.
Desarrollo de Servicios : el IMS brinda los APIs que permiten el desarrollo de servicios multimedia.
Entre los APIs ya contemplados se encuentran la presencia, la mensajeria instantnea, el PTT, la
conferencia y el chat.

151
IMS est formado por tres capas: la capa Media/Transport tambin llamada Bearer Plane, la
capa de Control de Sesin IMS y la capa de Servicios Multimedia o Application Plane. El control
de sesin es una de la funciones ms importantes de IMS.
La figura muestra como IMS puede comunicarse con diferentes tipos de redes. IMS fue
construido sobre lo que exista, es decir protocolos y estndares ya probados y provenientes de
Internet de acuerdo con el IETF.
IMS es un Core Network abierto a todas las tecnologas de acceso para ofrecer servicios
multimedia; IMS no tiene nada que ver con el acceso ni con el enrutamiento, slo tiene que ver
con el core, IMS es transparente a la red de acceso usada por el equipo terminal

152
Es importante comprender que las especificaciones IMS se establecen de manera que la funcionalidad
interna de las entidades de red no se especifica en detalle. En su lugar, las especificaciones describen
puntos de referencia entre entidades y funcionalidades soportadas en los puntos de referencia. Por
ejemplo, cmo el CSCF obtiene los datos de usuario de las bases de datos?

153
La descripcin de cada una de estas entidades se presenta en ETSI TS 123 002 V8.6.0 (2009-
10), seccin 4.a7, pp. 37.
En total existen 14 entidades y 25 puntos de referencia propios de IMS.
Existen otros puntos de referencia relacionados sobre todo con el proceso de realizar los cargos
a un usuario.
A diferencia de los dos dominios anteriores del 3GPP, donde el dominio de circuitos y dominio
de paquetes tienen su propio conmutador, IMS no tiene un switch en el sentido de los otros
dominios, sino que usa un Packet Switch mejorado para ofrecer servicios multimedia IMS.
Los Planos de Control y Datos estn separados
Red totalmente IP (All-IP Network)
Voz y datos pueden manejarse de manera similar
El HSS es como un sper HLR

154
155
La arquitectura del Core de IMS es una red basada en distintas entidades funcionales relacionadas entre si mediante interfaces
con sealizacin SIP y Diameter.
Dicho Core esta compuesto de tres tipos de servidores proxy SIP o Call Session Control Funtions (CSCFs): Proxy-CSCF (P-
CSCF), Interrogating-CSCF (I-CSCF) y Serving-CSCF (S-CSCF), y dos tipos de servidores Diameter: el Home Subscriber
Server (HSS) donde se guarda bsicamente la informacin de los suscriptores y el Subscription Locator Function (SLF) para
guardar las direcciones de los HSS. El Core cuenta tambin con Servidores de Aplicaciones SIP donde radican los servicios.
Call Session Control Function (CSCF):
El Call Session Control Function (CSCF) es el centro de la arquitectura del Core IMS y es utilizado para procesar la sealizacin
SIP. La funcin bsica del CSCF es la de proveer el control de las sesiones multimedia a los terminales y las aplicaciones. El
control de las sesiones incluye el enrutamiento seguro de los mensajes SIP, el consecuente monitoreo de las sesiones SIP y la
comunicacin con las entidades de policy para manejar la correspondiente autorizacin de medios. Es responsable tambin por
la interaccin con el HSS.
Home Subscriber Server (HSS):
El Home Subscriber Server (HSS) es la base de datos maestra que contiene la informacin de los suscriptores necesaria para
que las entidades de la red manejen las llamadas y sesiones. Esta compuesto por un servidor Diameter, que guarda perfiles de
suscriptores (informacin relevante de los servicios que deben ser provedos al usuario), registracin, y lgica de los servicios
(por ejemplo criterios de filtrado).
Provee las siguientes funciones: identificacin, autorizacin de acceso, autenticacin, gestin de movilidad (lleva el registro de
la entidad que esta sirviendo al suscriptor), soporte del establecimiento de las sesiones, soporte del aprovisionamiento de los
servicios y soporte de la autorizacin de los servicios.
Cuando un suscriptor se registra en el dominio IMS, el perfil del usuario es transmitido desde el HSS al S-CSCF. Para el
establecimiento de las sesiones, el HSS informa cual es el S-CSCF que esta sirviendo al suscriptor.
Al igual que en las redes mviles, de las cuales el Core IMS hereda muchas de sus caractersticas, aqu sigue existiendo la
necesidad de una base de datos centralizada del suscriptor la cual reside en el HSS. El Registro de la Localizacin de la red
origen (Home Location Register, HLR) de las redes mviles ha pasado a ser en IMS el HSS. La informacin de suscriptor
guardada en el HSS es la llave que habilita la movilidad de los servicios a travs de diferentes tipos de redes de acceso y el
roaming entre diferentes operadores de redes. Una de las caractersticas y ventajas mas importantes de la arquitectura del
Core IMS es que la red de origen es la que proporciona las caractersticas de los servicios, esto significa que el usuario no esta
restringido a las capacidades de la red visitada, sino que el usuario puede siempre conseguir el acceso a sus caractersticas
suscritas. Esta capacidad de la arquitectura del Core IMS se conoce como Virtual Home Enviroment (VHE).
Application Server (AS):
Todas las aplicaciones y servicios en el Core IMS son ejecutadas en Servidores de Aplicaciones SIP. Un Servidor de
Aplicaciones SIP puede estar dedicado a un nico servicio o hostear varios servicios.
En el Core IMS tambin es posible combinar servicios de diferentes Servidores de Aplicaciones a los efectos de crear una
experiencia unificada al usuario final. Por ejemplo un usuario puede combinar simultneamente servicios de presencia y de
video llamada aunque los servicios por si mismos se encuentren alojados en diferentes Servidores de Aplicaciones SIP.
El beneficio fundamental del uso de Servidores de Aplicaciones es la facilidad y la rapidez con las cuales se pueden brindar los
servicios de forma centralizada. La centralizacin de los servicios en uno o en pocos Servidores de Aplicaciones facilita los
procesos de actualizacin y upgrade de los servicios para todos los usuarios, evitando de que existan problemas derivados de
incompatibilidades por el manejo de versiones o datos viejos.

156
157
Cada subcomponente tiene significado lgico, es decir pueden estar incluidos fsicamente en el mismo
equipo pero conectados por medio de las interfaces lgicas.
El CSCF se encarga del procesamiento de las llamadas y realiza las funciones de control similares a las
que se realizan en sistemas de conmutacin de circuitos. De acuerdo con el estndar el CSCF es un
servidor SIP integrado por los tres componentes mencionados. La tendencia actual es combinar los tres
componentes en uno y aumentar el desempeo del sistema, ya que es posible el uso protocolos
propietarios entre los mdulos CSCF, lo cual es transparente visto desde afuera y permite hacer ciertas
economas; para un operador es mucho ms econmico comprar y administras un solo equipo que tres.
Tambin es muy probable que cuando las redes IMS maduren el P-CSCF se convierta en un elemento
independiente.

158
El P-CSCF se comporta como un proxy tal como se define en el RFC 3261, donde se define a SIP.
El P-CSCF acepta solicitudes de los usuarios, las analiza para propsitos de enrutamiento y las
retransmite. Es de hacer notar que el P-CSCF no modifica las solicitudes SIP del usuario, slo las
retransmite.
El P-CSCF tambin puede actuar en lugar del usuario es decir como B2BUA, significa que en algunas
circunstancias puede generar y terminar transacciones SIP, esto puede suceder por seguridad,
enrutamiento o en casos de roaming.
El P-CSCF responde a todas las solicitudes de los usuarios y manejas las interfaces hacia la red de
acceso.
Despus de haber atravesado la IP-CAN, el primer contacto con el core IMS es a travs del P-CSCF.
Desde la perspectiva de SIP, el P-CSCF acta como un servidor proxy SIP de entrada/salida. Esto
quiere decir que todas las solicitudes y respuestas desde o hacia el UE pasan por el P-CSCF. El P-
CSCF asignado a un UE durante el registro a nivel de IMS no cambia durante la duracin del registro, lo
que significa que el UE se comunica con un solo P-CSCF a la vez.

159
Una vez registrado en la red IMS cada usuario tiene asignado un S-CSCF.
El S-CSCF es uno de los elementos medulares del core IMS. La primera funcin del S-CSCF es iniciar,
manejar y liberar las sesiones, razn por la cual est involucrado en todo el proceso de sealizacin,
tanto para llamadas salientes como entrantes. En una red de un mismo operador pueden existir varios S-
CSCF.
Entre sus funciones podemos mencionar:
1. Registro y des-registro de usuarios, de acuerdo con SIP RFC 3261, obteniendo los perfiles desde el
HSS
2. Gestin de las sesiones: establecimiento, mantenimiento y liberacin
3. Selecciona las aplicaciones apropiadas de acuerdo a los perfiles de los usuarios
4. Actualizacin del HSS cuando los usuarios se registran
5. Rechazo de usuarios de acuerdo a ciertas polticas y limitaciones impuestas, por ejemplo
limitaciones en el ancho de banda.
Todos los mensajes de sealizacin SIP que un usuario enva o recibe pasan por el S-CSCF.
A futuro se espera que los S-CSCF de una red no estn equipados de manera similar, sino que por el
contrario existan diferencias en ellos debido a razones econmicas; por ejemplo podran existir un S-
CSCF gold-plated para usuarios exclusivos, bronze-plated para clientes de mercado masivo y un
SCSCF dedicado slo para clientes corporativos.
La conversin de nmeros E.164 a SIP URI es para el caso donde el destino sea un nmero en la
PSTN. Para ello existe el protocolo ENUM que hace la conversin de nmeros telefnicos
internacionales E.164 a SIP URI:

160
Funciones del CSCF

Proxy-Call Session Control Function (P-CSCF):

El Proxy-CSCF (P-CSCF) constituye el primer punto de contacto de los terminales con el Core IMS. La
funcin fundamental del P-CSCF es la de proveer transmisin segura de la sealizacin SIP entre si
mismo y cada uno de los terminales (UE) utilizando IPsec, redireccionando los mensajes SIP Register y
los mensajes de establecimiento de las sesiones.
Cuenta adems con una interfaz hacia el Policy Decisin Function (PDF), al cual le provee de
informacin para la autorizacin de la media y para ejercer el control de las polticas de calidad de los
servicios (QoS) dentro de la red. El PDF puede ser parte del P-CSCF, o ser una entidad separada de
este que se encuentra alojada en el RACS de la arquitectura TISPAN IMS.
El P-CSCF soporta la compresin de la sealizacin SIP donde sea necesario mediante Signaling
Compression (SigComp). Tambin juega un rol importante en la deteccin de los servicios IMS de
emergencia y el control local de los mismos.
Interrogating-Call Session Control Function (I-CSCF):
El Interrogating-CSCF (I-CSCF) es un punto de contacto opcional en la red para las conexiones
destinadas a un suscriptor. Una de sus funciones principales es la de ayudar en la bsqueda del S-
CSCF donde el suscriptor esta registrado o seleccionar un nuevo S-CSCF si el suscriptor todava no
esta registrado. Para cumplir con esta funcin interroga al HSS a travs de las interfaces Diameter.
Para buscar el S-CSCF adecuado en cada sesin, el I-CSCF se basa en parmetros como capacidad y
carga, por lo cual, realiza un balanceo de carga entre S-CSCFs con la ayuda del HSS. La otra funcin
importante que cumple el I-CSCF es la de redireccionar las peticiones SIP de los suscriptores hacia el S-
CSCF asignado en base a la informacin que le suministra el HSS. Si el Core contara con varios HSS, el
I-CSCF necesita contactarse inicialmente con el SLF va Diameter a los efectos de obtener la direccin
de un HSS para servir al suscriptor.
Tal como lo mencionamos, el I-CSCF es una funcin opcional en la arquitectura IMS, por lo que el
sistema puede ser configurado de modo que el S-CSCF entre en contacto con el P-CSCF directamente
sin la intervencin del I-CSCF.
Adems de las funciones anteriormente indicadas, el I-CSCF puede ser usado para ocultar la
configuracin y topologa de la red hacia otras redes externas, proporcionando un solo punto de entrada
a la red y soportando funciones de firewall. Esta funcin es opcional en el I-CSCF y se denomina THIG
(Topology Hiding Internetwork Gateway).
Serving-Call Session Control Function (S-CSCF):
El Serving-CSCF (S-CSCF) es el nodo central para la provisin y la gestin de la sealizacin SIP y el
verdadero corazn del sistema IMS. Es responsable del correcto encaminamiento de los mensajes SIP y
del mantenimiento de las sesiones en la red. Funciona como elemento pivot en la arquitectura,
transmitiendo la informacin entre los extremos . El S-CSCF utiliza interfaces Diameter para conectarse
al HSS y solicitar informacin de los suscriptores y de esa forma asistir en la autenticacin y registro de
los mismos.
Acta tanto como un SIP proxy para el encaminamiento de los mensajes SIP, como un SIP User Agent
(UA) para iniciar o terminar las transacciones SIP, y como un SIP Registrar para la autenticacin de los
suscriptores.
Puede haber varios S-CSCFs en la red, la cantidad final depender de sus capacidades y los requisitos
de la red. Todos los CSCFs generan CDRs en la red, dependiendo del despliegue necesario, estos tres
tipos de CSCFs podrn estar distribuidos en tres diferentes entidades fsicas o estar consolidados en
una o dos entidades.

161
Para el CSCF se han definido las siguientes interfaces relevantes para el aprovisionamiento de
servicios:
Ma (I-CSCF AS): Usada para reenviar SIP requests destinadas a un Public Service Identity
alojado por un Application Server. Especificada en el TS 23.228, subclusula 5.4.12.
ISC (S-CSCF AS): Usada para suministrar servicios. Especificada en el TS 23.228,
subclusula 4.2.4.
Las dos interfaces estn basadas en SIP (RFC3261)

162
163
La estructura del perfil de los usuarios est estandarizada a travs de un perfil genrico GUP (Generic
User Profile) estandarizado en ETSI TS 129 228 V9.0.0 (2010-01).
El USER PROFILE, almacenado en el HSS contiene gran cantidad de informacin relacionada con los
usuarios, incluyendo informacin de seguridad como claves criptogrficas, informacin relativa a los
servicios asignados, el S-CSCF que ha sido asignado al usuario, etc.. Cuando el usuario se registra por
primera vez, el S-CSCF baja el USER PROFILE del HSS y lo recibe a travs de un mensaje DIAMETER
SAA usando la interface Cx. Si el USER PROFILE cambia mientras el usuario est registrado en la red,
el HSS enva un mensaje DIAMETER PPR y actualiza dicho perfil.

164
El USER PROFILE contiene una serie de Services Profiles. Cada Service Profile define los servicios que
aplican a las Public User Identities. El Service Profile est dividido en cuatro partes: uno o ms
identificadores pblicos, un core network service authorization que es opcional,ninguno o varios initial
filter criteria y ninguno o varios shared initial filter criteria.
El Service Profile se aplica a todas las identificaciones pblicas que aparecen en el User Profile. Cada
identificacin contiene una etiqueta que indica si es BARRED o no, si es BARRED slo puede ser usada
para el registro, no para otros mensajes SIP. Cada identificacin publica contien un SIP URI o un TEL
URI.
El USER PROFILE puede tener un core network service authorization, el cual contiene un subscribed
media profile identifier, el cual a su vez contiene un valor que indica cuales son los parmetros SDP que
el usuario est autorizado a solicitar.
El initial filter criteria, indica los criterios de los filtros que estn almacenados en el HSS como parte de
USER PROFILE y son bajados por el S-CSCF durante el registro. Representan una subscripcin del
usuario establecida durante el aprovisionamiento del UE para una cierta aplicacin, seala cual
Application Server debe relacionarse con un determinado SIP REQUEST. Un criterio de un filtro define
un subconjunto de SIP requests que el S-CSCF puede enviar a una aplicacin particular.
La ltima parte del SERVICE PROFILE es el shared initial filter criteria, es opcional y necesita del
soporte del S-CSCF y del HSS. Se refiere a una serie de initial filter criteria que son comunes a varios
usuarios, entonces cuando el usuario se registra no es necesario bajar del HSS dicha informacin si ya
est en el S-CSCF, entonces lo que se hace es colocarle un identificador y slo ste se baja del HSS
cuando el UE se registra.

165
166
SIP permite el registro de una identidad de usuario pblica por vez. Es decir si el usuario tiene ms de
una identidad pblica, deber registrar cada identidad individualmente. Esto puede ser frustrante y
consumir demasiado tiempo desde el punto de vista del usuario final. Esta fue una de las razones por las
que 3GPP desarroll un mecanismo para registrar ms de una identidad pblica de un usuario en un
nico momento. Este concepto se llama registro implcito.
Un conjunto de registro implcito es un grupo de identidades pblicas de un usuario que se registran
mediante un nico pedido. Cuando una de las identidades pblicas dentro del conjunto se registra, todas
las identidades pblicas asociadas con el registro implcito se registran al mismo tiempo. De manera
similar, cuando una de las identidades pblicas de un usuario dentro del conjunto se desregistra, todas
las identidades del conjunto de registro implcito se desregistran al mismo tiempo Las identidades
pblicas que pertenecen a un nico conjunto de preregistro pueden estar apuntando a diferentes perfiles
de servicio.

167
Se han definido las siguientes interfaces para el HSS, relevantes para el aprovisionamiento de servicios:
Cx (HSS - CSCF): Usado para enviar datos del suscriptor al S-CSCF, incluyendo el Filter Criteria.
Especificado en TS 29.228 y TS 29.229 del 3GPP.
Sh (HSS AS): Puede ser usada para transferir informacin del User Profile, tal como informacin
relacionada con el servicio del usuario, informacin relacionada con localizacin o para manejar
funciones de charging. Especificado en TS 29.328 y TS 29.329 del 3GPP.
Las dos interfaces estn basadas en Diameter.

168
 Mecanismos y polticas QoS

No obstante que las redes celulares proveen movilidad y una amplia gama de servicios, la razn principal por la que
se crea el IMS es para ofrecer mas que un simple soporte de Calidad de Servicio (QoS). Todas las soluciones IMS
deben garantizar el QoS requerido y demandado por los clientes. El despliegue de nuevos servicios depende de los
niveles de QoS que sea capaz de proveer la tecnologa IMS.
Debido a que el IMS involucra una gran cantidad de protocolos, es importante definir las vas en que los diferentes
sistemas puede alcanzar la QoS de extremo a extremo para una conexin. Una de las preguntas es cmo utilizar
los mecanismos de QoS de bajo nivel para lograr QoS en las capas superiores dentro de la red. Se ve la necesidad
de asegurar la interoperabilidad entre las diferentes capas, dominios y redes. La capacidad de la red usualmente
es adecuada para la mayora de las aplicaciones. No obstante, a menuda sucede que las calidades de las
caractersticas del trfico percibidas por el cliente no son satisfactorias. Para proveer QoS extremo a extremo, es
necesario gestionar el QoS dentro de cada dominio a lo largo del camino. En el dominio IP, existen varios
mecanismos para el aprovisionamiento de QoS, como ser DiffServ o IntServ.
Las aplicaciones multimedia requieren una gestin sofisticada de los componentes del sistema que afectan el QOS.
Para lograr las caractersticas de QoS demandadas, todos los componentes de la red deben trabajar
correctamente, es decir que la QoS depende del elemento ms dbil de la red. A nivel de red se utilizan dos
mecanismos: Reservacin de recursos (IntServ / RSVP) o priorizacin (DiffServ).
Mapeo de QoS
El aprovisionamiento de las garatas de QoS en una red multimedia completamente integrada es complejo.
Involucra numerosos aspectos interrelacionados como ser Especificaciones QoS, Mapeo, control de polticas, etc.
Los mecanismos de QOS pueden dividirse en dos partes: Mecanismos verticales y mecanismos horizontales. En
los primeros se vinculan las capas inferiores con las superiores, mienrtas que el segundo vincula los mecanismos
de las capas inferiores entre diferentes dominios y redes. El proceso de traducir las especificaciones de QoS entre
dos diferentes niveles de la suite de protocolos IP se llama Mapeo de QoS. Se ve un ejemplo en la figura. Cada
capa de la pila de protocolos puede ofrecer su propio tipo de QoS. Se requiere el mapeo para traducir el QoS
provisto por las capas inferiores a parmetros que tengan sentido en las capas superiores. Tambin se debe tomar
en cuenta el sentido inverso del mapeo,, es decir que un conjunto de parmetros de un protocolo de capa superior
puede ser usado para controlar la capa inferior. Se deben considerar reglas de mapeo apropiadas para lograr el
QoS deseado. El mapeo entre servicios IMS y el transporte IP es fundamental para mantener una calidad
determinada. Dado que existen numerosos elementos cooperando en la ruta de los servicios, se debe asegurar que
cada uno de ellos provea las garantas requeridas para construir una traza de servicios que tenga servicios de
calidad consistente en todo su recorrido.

169
En la Rel. 5 de UMTS, el 3GPP define el uso de la tecnologa IMS. Es por esto que las sesiones multimedia del IMS se
procesan mediante un conjunto de elementos de red diseados originalmente para soportar servicios multimedia IP en el
UMTS. El marco de QoS para UMTS se aplica a los servicios de acceso de paquetes de GPRS e incluye los aspectos de
interrelacin al IMS. La base de provisionar el QoS requerido es la seleccin de portadores con las caractersticas apropiadas.
El servicio portador incluye todos los aspectos que permiten la provisin de QoS. Cada servicio portador realiza una oferta a
servicios individuales utilizando los servicios de capas inferiores. Los servicios de circuitos conmutados no se encuentran
comprendidos en la definicin.
El trfico pasa a travs de diferentes servicios portadores de la red desde un Equipo Terminal (TE) hasta otro.
QoS para servicios IMS
El QoS no puede controlarse sin la interaccin entre la capa de Sealizacin y la capa de Transporte. Por lo tanto, se debe
crear un mecanismo para autorizar y controlar el uso de los trficos portadores relacionados al trfico IMS. Este mecanismo se
basa en los parmetros de SDP negociados al establecerse la sesin IMS. La QoS aplica en un escenario basado en
comunicacin SIP. Durante el establecimiento de la sesin SIP, el UE negocia sus capacidades y expresa sus requerimientos
de QoS a nivel de aplicacin. El UE puede negociar el tipo de media, direccin del trfico, tamao de paquetes, tasa de
transferencia, etc. En funcin de ello se reservan los recursos apropiados en la red. Una vez establecida la sesin de medios,
los UE transfieren la informacin usando protocolos de tiempo real, (RTP) mientras que el proveedor debe garantizar la QoS en
el ncleo de la red.
El control de QoS y la gestin de polticas son dos funciones interrelacionadas. El concepto de control de QoS se incluye en la
arquitectura de Control de Polticas y Tasacin (PCC). El control de polticas significa la capacidad de autorizar y controlar el
uso de trfico portador por el media IMS. La funcin de PCRF incluye funcionalidades de control y tasacin basada en flujos y
establece decisiones de polticas, las que son implementadas por la funcin PCEF que tpicamente se encuentra dentro del
GGSN.

170
 Soporte de QoS en IMS
HSS
Diameter
PDF Policy Decision Function
PEP Policy Enforcement Point CSCF
PDF

COPS /
Diameter

PEP
External
UTRAN Gn Gi
SGSN GGSN IP Network

DiffServ, RSVP, NSIS, Diffserv over MPLS

La migracin hacia ambientes IP transform el QoS en un punto muy importante, debido a que la
estrategia tradicional de mejor esfuerzo de IP slo es apropiada para los primeros servicios de Internet
como email, telnet o Web, que son en general muy tolerantes en aspectos de parmetros de la red como
capacidad disponible, retardos o jitter. Sin embargo, las nuevas redes convergentes deben ofrecer
servicios de tiempo real como ser telefona, llamadas de video, o nuevas aplicaciones multiusuario
altamente colaborativas como juegos en lnea, etc. La estrateguia de mejor esfuerzo no es ms valida
para aprovechar los recursos de red y simultneamente garantizar la experiencia del usuario. El IMS
debe ofrecer QoS negociable para sesiones multimedia IP, al tiempo que soporta itinerancia y
negociacin entre operadores del QoS y las capacidades del servicio.
Se debe soportar la itinerancia par permitir a los usuarios acceder a servicios multimedia IP
provisionados por, al menos, su dominio matriz y red servidora. Por supuesto, dado que el IMS pretende
ser agnstico al acceso, se recomienda a los operadores ser capaces de ofrecer servicios a sus clientes
sin importar cmo obtienen su conexin IP. La especificacin IMS permite a los operadores diferenciar
sus servicios y disearlos para acomodar necesidades especficas, por lo que provee una especificacin
flexible que no impone la implementacin de una tecnologa WoS en particular.
El 3GPP eligi originalmente COPS (Servicio Abierto de Polticas comunes) para transferir la informacin
entre los Puntos de Decisin de Polticas (PDP) y los Puntos de Aplicacin de Polticas (PEP) del IMS
Rel. 5. En versiones posteriores de la especificacin IMS, el 3GPP decidi reemplazar COPS por
Diameter debido a lo siguiente:
1. Protocolo ms escalable
2. Protocolo ms robusto con integracin predefinida de procedimientos de recuperacin de fallas
3. Soporte de agentes

171
172
Para poder comunicarse con el IMS, un tem que debe conocer el UE es por lo menos una direccin IP
del P-CSCF. El mecanismo por el cual un UE recupera estas direcciones se llama P-CSCF discovery.
El 3GPP estandariz dos procedimientos dinmicos para el P-CSCF discovery: El procedimiento DHCP
DNS y el procedimiento GPRS. Adicionalmente es posible configurar tanto el nombre del P-CSCF o bien
su direccin IP en el UE. En el procedimiento GPRS, el UE incluye el flag de pedido de direccin de P-
CSCF en el pedido de activacin de contexto PDP y recibe en respuesta la(s) direccin(es) del P-CSCF.
Esta informacin se transporta en el elemento de informacin de opciones de configuraciones del
protocolo [3GPP TS 24.008]. El mecanismo que utiliz el GGSN para adquirir las direcciones de los P-
CSCF est fuera del estndar. Este mecanismo no funciona con GGSN con releases menores a Rel. 5.
En el proceso DHCP DNS, el UE enva un pedido DHCP a la red de conectividad IP de acceso, que lo
reenva a un servidor DHCP. De acuerdo con [RFC3319] y [RFC3315], el UE puede pedir tanto una lista
de los nombres de dominio de los servidores SIP, o bien una lista de direcciones IPv6 de los P-CSCF.
Cuando se le retornan los nombres de dominio, realizar una consulta DNS (NPTR/SRV) para encontrar
la direccin IP del P-CSCF. El mecanismo DHCP DNS es una manera de descubrir el P-CSCF
independiente del acceso.

173
 Asignacin del S-CSCF

Luego de descubrir su punto de entrada a IMS (es decir el P-CSCF), el siguiente paso es llegar al S-CSCF. Existen
tres casos en los que se asigna un S-CSCF:
Cuando un usuario se registra en la red.
Cuando se requiere un S-CSCF para ejecutar servicios en nombre de un usuario no registrado
Cuando un S-CSCF asignado previamente no responde

Asignacin del S-CSF durante el registro

Cuando un usuario se est registrando en una red, el UE enva el pedido REGISTER al P-CSCF descubierto, quien
encuentra la entidad de red de la red home del usuario (el I-CSCF) Luego el I-CSCF intercambia mensajes con el
HSS (UAR y UAA). Como resultado, el I-CSCF recibe las capacidades de S-CSCF requeridas, siempre que no
haya un S-CSCF previamente asignado. En funcin de las capacidades recibidas, el I-CSCF selecciona un S-CSCF
adecuado. La informacin de capacidades se transfiere entre el HSS y el I-CSCF dentro del AVP Server-
Capabilities, el que contiene:
Cero o ms AVP de Capacidades Obligatorias: cada uno contiene una capacidad obligatoria requerida del S-
CSCF. Cada capacidad obligatoria dentro de una red individual de un operador tiene asignado un valor nico
Cero o ms AVP de capacidades Opcionales.
Cero o ms AVP de nombre de servidor: contienen las URI SIP utilizadas para identificar un servidor SIP.
Utilizando los AVP de capacidades obligatorias y opcionales el operador podr distribuir a los usuarios entre S-
CSCF dependiendo de las diferentes capacidades (capacidades requeridas para servicios de usuario, preferencias
del operador por usuario, etc.) que puede tener cada S-CSCF,
Es responsabilidad del operador definir (posiblemente basado en las funcionalidades ofrecidas por cada S-CSCF
instalado en la red) el significado exacto de las capacidades obligatorias y opcionales. Como primera eleccin, el I-
CSCF elegir el S-CSCF que tenga todas las capacidades obligatorias y opcionales. Si esto no fuera posible,
aplicar un algoritmo de best-fit. Estos algoritmos no estn estandarizados.
Utilizando el AVP de Server-Name, el operador tiene la posibilidad de dirigir a los usuarios hacia ciertos S-CSCF,
por ejemplo tener un S-CSCF dedicado para la misma compaa o grupo para implementar un servicio VPN.

Asignacin de S-CSCF para ejecutar servicios a un usuario no registrado.

Si el HSS conoce que no hay un S-CSCF asignado actualmente y que el usuario tiene servicios relacionados al
estado no registrado, retornar la informacin de capacidades S-CSCF y el procedimiento continuar como ya
descripto.

Asignacin de S-CSCF en casos de error

El estndar 3GPP permite la reasignacin de S-CSCF durante la etapa de registracin cuando el S-CSCF asignado
no responde, es decir cuando el I-CSCF se da cuenta que no puede alcanzar al S-CSCF asignado enva un
comando UAR al HSS y explcitamente setea el tipo de elemento de informacin de autorizacin al valor de
capacidades y registro. Luego de recibir las capacidades del S-CSCF, el I-CSCF contina el proceso normal de
registro.

174
Previamente al registro en el IMS, que permitir al UE utilizar los servicios IMS, el UE deber obtener un
transporte de conectividad IP y descubrir un punto de entrada IMS (el P-CSCF). Por ejemplo, en el caso
de acceso GPRS, el UE deber realizar un procedimiento de GPRS Attach activar un PDP para
sealizacin SIP. El registro IMS consiste en dos fases: Primero la red desafa al UE (figura de la
izquierda). Luego el UE responde el desafo y completa la registracin (Fig. de la derecha).
En primer lugar el UE enva un pedido SIP REGISTER al P-CSFC descubierto. Este pedido podr
contener, entre otros, la identidad a registrar y el nombre del dominio home (direccin del I-CSCF). El P-
CSCF procesa el pedido de REQUEST y usa el nombre provisto del dominio home para resolver la
direccin IP del I-CSCF. El I-CSCF a su tiempo contactar al HSS para procurar las capacidades
requeridas para la seleccin del S-CSCF. Luego de la seleccin del S-CSCF el I-CSCF reenva el pedido
de REQUEST al S-CSCF quien nota que el usuario no est autorizado y por lo tanto procura datos de
autenticacin del HSS y desafa al usuario con una respuesta 401-Unauthorized. En segundo lugar, el
UE calcula la respuesta al desafo y enva un segundo pedido de REQUEST al P-CSCF. Nuevamente el
P-CSCF encuentra al I-CSCF y ste a su vez encuentra al S-CSCF. Finalmente el S-CSCF verifica la
respuesta y si est correcta, toma el perfil del usuario el HSS y acepta el registro con un 200 OK. Una
vez que est autorizado satisfactoriamente, el UE podr iniciar y recibir sesiones. Durante el proceso de
registro, tanto el UE como el P-CSCF aprenden qu S-CSCF de la red estar sirviendo al UE.
Es responsabilidad del UE mantener su registracin activa refrescndola peridicamente. Si el UE no
refresca su registro, el S-CSCF remover silenciosamente la reserva cuando se termine el tiempo de un
contador. Cuando el UE desea desregistrarse del IMS enva un temporizador de registro 0 y enva un
mensaje REGISTER.

175
Supongamos una registracin inicial en el caso donde un usuario visita otra red. Este procedimiento
comienza con el pedido de SIP REGISTER por parte del usuario el que es enviado al P-CSCF visitado.
Si en la red local del usuario existen mltiples S-CSCF, entonces esta contara con un I-CSCF para
seleccionar el S-CSCF asignado a cada sesin de usuario. Para resolver la direccin del I-CSCF local
del usuario, el P-CSCF utiliza el nombre del dominio local del usuario y encamina el REGISTER hacia el
I-CSCF. Luego el I-CSCF envia un User-Authorization-Request (UAR) al HSS, que responde con una
direccin de S-CSCF disponible. A continuacin el I-CSCF selecciona el SCSCF y le reenva el mensaje
de REGISTER. Una vez que el S-CSCF recibe el REGISTER, solicita al HSS un vector de autenticacin
va un Diameter Multimedia Authentication Request (MAR), y a continuacin de recibirlo, reenva al
usuario un mensaje SIP 401 Unauthorized que lleva la informacin de autenticacin.
Luego de computarse la respuesta de autenticacin, el usuario envi al S-CSCF un nuevo mensaje
REGISTER que lleva la respuesta. El S-CSCF verifica dicha respuesta, y si es correcta, baja el perfil del
usuario del HSS va a Diameter Server-Asignment-Request (SAR). El S-CSCF contacta entonces un AS
para control del servicio segn lo que esta especificado en el perfil del usuario, antes de responder con
un mensaje 200 OK al usuario.

176
Before a user can get access to IP Multimedia services, it must register at least one IMPU (IP Multimedia
Public Identity), such as a telephone number. Then the IMS network must authenticate the IMPI (IP
Multimedia Private Identity) at application. The registration process is initiated by the IMS terminal
sending a SIP REGISTER message to the P-CSCF directed his IMPI and IMPU. This message reaches
the P-CSCF, and it forwards the message to the I-CSCF. The I-CSCF sends a DIAMETER message
authentication request of the user who sent the REGISTER message, DIAMETER UAR to HSS, who
responds with another message DIAMETER UAA and parallel to I-CSCF informs the direction of the S-
CSCF assigned to the user. Then the I- CSCF forwards the registration message to the S-CSCF, which
in turn sends the message DIAMETER MAR including IMPI, which is used by the HSS to calculate the
Authentication Vector (AV) and generates the quintuple < RAND, AUTN, XRES, CK, IK > and returns the
S-CSCF to fivefold through DIAMETER MAA message. This message is an indication that the network is
requesting that the terminal uses its security algorithms in order to authenticate. Then the S-CSCF sends
the SIP 401 Unauthorized message accompanied by four of the five parameters making up the AV to I-
CSCF, which forwards the message to the P-CSCF. Again, the P-CSCF forwards the message to the UE
but leaving him only two parameters, the RAND and AUTN. Since the terminal has the same secret key
that has a corresponding HSS, the user can calculate the AUTN. If this matches the one received from
the network, the network is considered legitimate. The UE also calculates its response RES which is sent
to another SIP REGISTER message with IMPI and ARPU. This message reaches the P-CSCF which
forwards the I-CSCF. After the I-CSCF sends a DIAMETER UAR to HSS who responds with the address
of S-CSCF through a DIAMETER UAA message. Then the I-CSCF forwards the registration message
with the RES to S-CSCF. The latter sends the message DIAMETER SAR to the HSS who replies with
DIAMETER SAA. If the RES parameter sent by the user is equal to XRES had calculated the HSS during
the first registration attempt, then the HSS authenticates the user by means of the message DIAMETER
SAA. Finally the S-CSCF sends a SIP 200 OK message to P-CSCF, which forwards it to the user.
Security processes are always executed by the Home Network, even if the user is roaming.

177
Cuando el usuario A quiere establecer una sesin con el usuario B, generar un pedido SIP INVITE y lo
enviar a travs del punto de referencia Gm al P-CSCF, quien lo procesar: Por ejemplo, descomprime
el pedido y verifica la identidad del originante antes de reenviarlo a travs de la interfaz Mw al S-CSCF.
Este procesar el pedido, ejecuta el control del servicio que podr incluir interacciones con los
Servidores de Aplicacin (AS) y eventualmente determina el punto de entrada del operador del Usuario
B en funcin de la identidad del Usuario B contenida en el pedido SIP INVITE. El I-CSCF recibe el
pedido a travs de la interfaz Mw y contacta al HSS via el punto Cx para encontrar al S-CSCF que est
atendiendo al usuario B. El pedido se pasa al S-CSCF a travs de Mw. El S-CSCF toma a su cargo el
procesamiento de la sesin de terminacin, que podr incluir interacciones con los AS y eventualmente
entrega el pedido al P-CSCF a travs de Mw. Luego de procesamientos adicionales (compresin y
verificacin de privacidad), el P-CSCF usa el punto de referencia Gm para enviar el SIP INVITE al UE B.
El UE genera una respuesta (183 Session Progress) que viaja en sentido contrario hasta el UE A
siguiendo la ruta generada en el camino desde UE A (por ejemplo: UE B > P-CSCF > S-CSCF > I-
CSCF > S-CSCF >P-CSCF > UE A) Luego de algunos intercambios ms, ambos UE completan el
establecimiento de sesin y estn listos para comenzar la aplicacin en s (por ejemplo, un juego de
ajedrez). Durante el establecimiento de la sesin, un operador podr controlar el uso de los canales
disponibles para el trfico de medios.

178
Un perfil de usuario es un conjunto de informacin especfica del usuario almacenada permanentemente
en el HSS y descargada al S-CSCGF cuando ste debe ejecutar servicios para usuarios registrados o no
registrados. El perfil del usuario contiene por lo menos una identidad de usuario privada y un perfil de
servicios. El perfil puede tener ms de una identidad privada si por ejemplo el usuario est utilizando una
identidad pbloca compartida. Una suscripcin nica IMS puede contener mltiples perfiles de usuario,
permitiendo dar tratamietno diferenciado para las diferentes identidades pblicas.
El operador asigna un perfil al usuario cuando el usuario obtiene una suscripcin IMS del operador. El
perfil se transfiere del HSS a un S-CSCF asignado en dos operaciones: Server-Assignement-Answer
(SSA) y Push-Profile-Request (PPR). El perfil del servicio se transporta en un AVP Diameter, donde se
incluye como un documento XML.

179
180
En el presente la mayora de los usuarios utilizan UE de circuitos conmutados, lneas telefnicas fijas y todo tipo de
terminales celulares. Por lo tanto es deseable que IMS interfuncione con las redes legadas de circuitos conmutados
para soportar servicios vocales bsicos entre usuarios IMS y usuarios de redes CS. Esto requiere
interfuncionamiento tanto en el plano de usuario como el de control, debido a que los protocolos utilizados son
diferentes en cada plano.
El interfuncionamiento del plano de control es manejado por el MGCF, que realiza el mapeo entre la sealizacin
SIP de IMS al ISUP de la red PSTN/PLMN y viceversa. La pasarela de medios IMS (IMS-MGW) realiza a su vez la
traslacin de protocolos en el plano de usuario, terminando los canales de transporte de las redes PSTN/PLMN as
como los flujos de media de redes de paquetes IP o ATM y provee la traslacin entre las terminaciones. Tambin
puede proveer funciones adicionales, como ser interfuncionamiento de codecs, cancelacin de eco y verificacin de
continuidad. La MGCF controla las terminaciones.

Sesin originada en IMS hacia la red CS

Cuando un usuario IMS inicia una sesin, no debe preocuparse si el abonado llamado es un usuario IMS o CS.
Simplemente inicia la llamada e IMS se encarga de encontrar al abonado llamado. El pedido de sesin del abonado
llamante siempre llegar al S-CSCF que atiende a ese abonado utilizando la ruta aprendida durante el proceso de
registro. Cuando el S-CSCF recibe un pedido de sesin con un tipo de URL TEL (tel +541132142222) debe realizar
una consulta ENUM para convertir el URI TEL a URI SIP, debido a que los principios de enrutamiento IMS no
permiten enrutar URI TEL. Si el S-CSCF puede convertir la identidad al formato URI SIP enrutar la sesin hacia el
destino dentro de la red IMS. Cuando esta conversin falle el S-CSCF intentar ubicar el destino en la red CS. Para
salir hacia la red CS, el S-CSCF enruta el pedido de sesin hacia la Funcin de Control de Pasarela de Salida
(BGCF) en su misma red.
La BGCF tiene dos opciones: seleccionar el punto de salida en la misma red o seleccionar otra red para salir a la
red CS. En el primer caso la BGCF selecciona una MGCF en la misma red para convertir la sealizacin SIP a
ISUP y controlar el IMS-MGW. En el segundo caso, la BGCF selecciona otra BGCF en otra red IMS diferente para
seleccionar la MGCF de su red que manejar la salida. La MGCF acta como punto de terminacin de la
sealizacin, por lo que negocia los parmetros de medios con el IMS UE por un lado, y por el otro negocia con la
entidad CS (por ejemplo un MSC) de la red CS.

181
 Interfuncionamiento con la PSTN
La Figura representa una llamada iniciada por el RTCP
con destino a un terminal en el subsistema IMS.
El conmutador de la RTC reserva un circuito de voz que
comparte con el IMS-MGW y emite un mensaje ISUP
IAM sobre un transporte SS7 al Trunking Signalling
Gateway o T-SGW. El TSGW es responsable de la
conversin del transporte del mensaje ISUP. Este
mensaje es relevado a la entidad MGCF sobre
SIGTRAN. El MGCF crea un contexto en la entidad IMS-
MGW usando el protocolo MEGACO/H.248. Este
contexto consiste en una asociacin entre una
terminacin TDM y una terminacin RTP. La terminacin
TDM termina el circuito de voz que el IMS-MGW
comparte con el conmutador telefnico. La terminacin
RTP termina los canales RTP entre el IMS-MGW y el
terminal IMS. El IMQ-MGW retorna una respuesta a la
entidad MGCF, esta respuesta contiene un local
descriptor que corresponde a la descripcin SDP
asociada a su terminacin RTP.
La entidad MGCF genera un mtodo SIP INVITE
conteniendo la descripcin SDP devuelta por el IMS-
MGW. Este mtodo es enviado al subsistema IMS quien
se encarga de entregarla al terminal IMS llamado.

El dominio IMS debe interfuncionar con la Red Telefnica Conmutada Publica o PSTN con el fin de permitir a los usuarios IMS
establecer llamadas con la PSTN. La arquitectura de interfuncionamiento presenta un plan de control (sealizacin) y un plan de
usuario (transporte). En el plan usuario, pasarelas IMS-Media Gateways o IMS-MGW son necesarias con el fin de convertir
los flujos RTP en flujos TDM. Estas pasarelas, nicamente tratan el aspecto media.
Las entidades son responsables de crear, mantener y liberar conexiones en estas pasarelas, se trata de controladores de
pasarelas Media Gateway Control Function o MGCF. Por otra parte, el mismo MGC termina la sealizacin ISUP del lado
RTC y la convierte en sealizacin SIP entregada al dominio IMS. Los mensajes ISUP procedentes del PSTN son en primer
lugar encaminados sobre SS7 a una pasarela de sealizacin Trunking Signalling Gateway o TSG quien los releva al MGC
sobre un transporte SIGTRAN. El interfuncionamiento entre el dominio IMS y la PSTN esta entonces asegurado por tres
entidades: el IP Multimedia Subsystem Media Gateway Function o IMS-MGW, el Media Gateway Control Function o
MGCF y el Trunking Signaling Gateway Function o T-SGW.
El IMS-MGW
Recibe un trafico de palabras de la PSTN y lo encamina sobre una red IP. El trafico audio es
transportado sobre RTP/UDP/IP.
Soporta generalmente funciones de conversin del media y de tratamiento del media
(cancelacin de eco, puente de conferencia).
Es controlado por el MGCF por medio del protocolo MEGACO/H.248.
El MGCF
De igual manera que las entidades CSCF, solo pertenece al plan de control y no al plan media.
Controla el IMS-MGW para establecer, mantener y liberar conexiones en el IMS-MGW. Una conexin corresponde por
ejemplo a una asociacin entre una terminacin TDM (terminacin del lado RTC) y una terminacin RTP/UDP/IP. Una
transcodificacin de la voz debe tambin tener lugar a nivel del IMS-MGW para convertir la voz recibida codificada con el
apoyo del cdec G.711, en voz codificada usando el cdec AMR (UMTS) si el terminal IMS es un mvil UMTS.
Asegura la conversin de mensajes ISUP (sealizacin RTC) en mensajes SIP (Sealizacin IMS).
Selecciona el CSCF idneo con el fin de entregar la sealizacin SIP que el genera, al subsistema IMS.
El T-SGW
Asegura la conversin del transporte para el encaminamiento de la sealizacin ISUP entre el conmutador telefnico y el
MGCF. La sealizacin ISUP se intercambia:
Sobre SS7 entre el conmutador y el T-SGW
Sobre SIGTRAN entre el T-SGW y el MGCF.
Por otra parte, no analiza los mensajes de aplicacin ISUP.

182
Cuando un usuario CS disca un nmero E.164 que pertenece a un usuario IMS, ser procesado por la
red CS como cualquier otro nmero E.164. Sin embargo, luego del anlisis de la ruta ser enviado a un
MGCF en la red IMS del usuario destino. Luego de recibir el mensaje de sealizacin ISUP, el MGCF
interacta con el IMS-MGW para crear una conexin en el plano de usuario, convierte el mensaje ISUP a
sealizacin SIP y enva un SIP INVITE al I-CSCF, que encontrar la S-CSCF que atiende al usuario
llamado con la ayuda del HSS. Luego la S-CSCF toma las acciones necesarias para reenviar el SIP
INVITE al UE. Despus la MGCF contina la comunicacin con el UE y la red CS para establecer la
llamada.

183
Para describir la sealizacin que se intercambia entre el Core IMS y las redes de conmutacin de
circuitos, veremos un ejemplo de flujo de sealizacin correspondiente al establecimiento de una
llamada entre un usuario IMS y un usuario de la red PSTN.
A los efectos del ejemplo consideraremos que ambos usuarios, llamante y llamado, pertenecen al mismo
dominio.
El procedimiento comienza cuando el User Agent IMS enva un mensaje SIP INVITE con el Request-
URI. Cuando el S-CSCF recibe el mensaje contacta un servidor ENUM a los efectos de convertir el URI
de destino en una SIP URI para su encaminamiento. Si el URI de destino no esta guardado en el
servidor ENUM (indicando que el usuario llamado no es un usuario IMS), el S-CSCF encamina el
mensaje INVITE al BGCF, quien determina que el intercambio debe ocurrir en la misma red para este
ejemplo. El BGCF selecciona un MGCF y encamina el mensaje INVITE. El MGCF le solicita al MGW
guardar los recursos de media para el usuario IMS, y luego le enva un correspondiente mensaje IAM de
ISUP al SGW a travs de M3UA.
El mismo mensaje es enviado a la red SS7 desde el SGW pero en este caso utilizando MTP3. Despus
que el mensaje IAM alcanzo la red SS7, mensajes ACM y ANM son normalmente respondidos al MGCF,
quien enva al usuario IMS los mensajes 180 ringing y 200 OK.
Cuando el usuario IMS recibe las respuestas, este devuelve un mensaje SIP PRACK a los efectos de
reconocimiento de la respuesta recibida.

184
185
En Internet en general, el despliegue de IPv6 no ha progresado tan rpido como se esperaba o se
espera desde que se introdujo el concepto inicial de la primera IMS. Muchos factores han contribuido y
siguen contribuyendo a esto, pero, en general, cualquier cambio en la infraestructura de enrutamiento de
ncleo de la Internet es probable que tome un tiempo mucho ms largo que uno en los bordes de la red.
Los traductores de direcciones de red (NAT), constituyen un cambio que cae en la ltima categora. Los
NAT son ampliamente reconocidos como perjudiciales para los nuevos servicios, as como los ya
existentes (por ejemplo, VoIP basado en SIP), pero en trminos de inversin ofrecen una opcin muy
asequible y fcilmente desplegable para ampliar el espacio de direcciones rpido agotamiento de IPv4, y
por lo tanto frenar el despliegue de la solucin a largo plazo en forma de IPv6.
En muchos sentidos, lo que est sucediendo a travs de Internet es descriptivo de lo que est
sucediendo en el terreno mvil. Aunque IPv6 se ve como tcnicamente superior a IPv4 para el IMS, la
obligatoriedad de la compatibilidad con IPv6 representa una gran barrera para la implementacin de
cualquier sistema. Utilizar exclusivamente IPv6 tambin requiere que los socios de roaming y los
proveedores de servicios migren a IPv6. Por ello, muchos despliegues iniciales han optado por
trabajar con las redes de acceso de GPRS, y muchas veces esta infraestructura de red existente no es
compatible con IPv6. Adems, el sistema de 3GPP2 MMD, opera tanto sobre IPv4 e IPv6. Esto significa
que cualquier interconexin entre el IMS y el MMD, naturalmente, implica interfuncionamiento IPv4-IPv6.
Por lo tanto, se ha hecho evidente algn despliege del IMS basado en IPv4es inevitable, aunque
originalmente se especifica como el apoyo a IPv6. Por lo general, estos despliegues IMS basado
en IPv4 son llamados "Implementaciones iniciales de IMS, y ya sea la UE, el ncleo de red IMS, o
ambos utilizan exclusivamente IPv4

186
187
Atendiendo a la arquitectura general de los sistemas 3GPP, se ilustra de forma simplificada la
arquitectura completa del sistema LTE, denominado formalmente en las especificaciones como
Evolved Packet System (EPS). Los componentes fundamentales del sistema LTE son, por un lado, la
nueva red de acceso E-UTRAN y el nuevo dominio de paquetes EPC de la red troncal (denominado en
adelante simplemente como red troncal EPC), y por otro, la evolucin del subsistema IMS concebido
inicialmente en el contexto de los sistemas UMTS. Los diferentes componentes han sido diseados
para soportar todo tipo de servicios de telecomunicacin mediante mecanismos de conmutacin de
paquetes, por lo que no resulta necesario disponer de un componente adicional para la provisin de
servicios en modo circuito (en el sistema LTE los servicios con restricciones de tiempo real se soportan
tambin mediante conmutacin de paquetes). En este sentido, EPC constituye una versin
evolucionada del sistema GPRS.
La red de acceso E-UTRAN y la red troncal EPC proporcionan de forma conjunta servicios de
transferencia de paquetes IP entre los equipos de usuario y redes de paquetes externas tales como
plataformas IMS y/o otras redes de telecomunicaciones como Internet. Las prestaciones de calidad de
servicio (e.g., tasa de datos en bits/s, comportamientos en trminos de retardos y prdidas) de un
servicio de transferencia de paquetes IP puede configurarse en base a las necesidades de los servicios
finales que lo utilicen, cuyo establecimiento (sealizacin) se lleva a cabo a travs de plataformas de
servicios externas (e.g., IMS) y de forma transparente a la red troncal EPC. Formalmente, el servicio de
transferencia de paquetes IP ofrecido por la red LTE entre el equipo de usuario y una red externa se
denomina servicio portador EPS (EPS Bearer Service). Asimismo, la parte del servicio de transferencia
de paquetes que proporciona la red de acceso E-UTRAN se denomina E-UTRAN Radio Access Bearer
(ERAB).
Otra caracterstica fundamental del sistema LTE es que contempla tambin el acceso a sus servicios a
travs de UTRAN y GERAN as como mediante la utilizacin de otras redes de acceso que no
pertenecen a la familia 3GPP (e.g., CDMA2000, Mobile WiMAX, redes 802.11, etc.). La interconexin
de las redes de acceso alternativas, tanto 3GPP como no, se soporta a travs de un conjunto de
interfaces del EPC.
188
La arquitectura de la red de acceso se compone de una nica entidad de red (Formalmente, una
entidad de red en 3GPP representa una entidad lgica que cubre una funcionalidad perfectamente
delimitada. Por tanto, una entidad de red es una entidad funcional), denominada evolved NodeB (eNB)
que constituye la estacin base de E-UTRAN. As pues, la estacin base E-UTRAN integra toda la
funcionalidad de la red de acceso, a diferencia de las redes de acceso de GSM y UMTS compuestas
por estaciones base (BTS, NodoB) y equipos controladores (BSC y RNC). La descripcin de la
arquitectura de E-UTRAN se detalla en las especificaciones del 3GPP TS 36.300 y TS 36.401.
Tal y como se ilustra en la figura, una red de acceso E-UTRAN est formada por eNBs que
proporcionan la conectividad entre los equipos de usuario (UE) y la red troncal EPC. Un eNB se
comunica con el resto de elementos del sistema mediante tres interfaces: E-UTRAN Uu, S1 y X2.
La interfaz E-UTRAN Uu, tambin denominada LTE Uu o simplemente interfaz radio LTE, permite la
transferencia de informacin por el canal radio entre el eNB y los equipos de usuario.
Todas las funciones y protocolos necesarios para realizar el envo de datos y controlar la operativa de
la interfaz E-UTRAN Uu se implementan en el eNB. El eNB se conecta a la red troncal EPC a travs de
la interfaz S1. Dicha interfaz est desdoblada en realidad en dos interfaces diferentes: S1-MME para
sustentar el plano de control y S1-U como soporte del plano de usuario. La separacin entre plano de
control y plano de usuario es una caracterstica importante en la organizacin de las torres de
protocolos asociadas a las interfaces de la red LTE. As pues, el plano de usuario de una interfaz se
refiere a la torre de protocolos empleada para el envo de trfico de usuario a travs de dicha interfaz
(e.g., paquetes IP del usuario que se envan entre E-UTRAN y EPC a travs de S1-U). Por otro lado, el
plano de control se refiere a la torre de protocolos necesaria para sustentar las funciones y
procedimientos necesarios para gestionar la operacin de dicha interfaz o de la entidad
correspondiente (e.g., configuracin de la operativa del eNB desde la red EPC a travs de S1-MME).
Esta separacin entre plano de control y plano de usuario en la interfaz S1 permite realizar la conexin
del eNB con dos nodos diferentes de la red troncal.

189
As, mediante la interfaz S1-MME, el eNB se comunica con una entidad de red de la EPC encargada
nicamente de sustentar las funciones relacionadas con el plano de control (dicha entidad de red de la
red troncal EPC se denomina Mobility Management Entity, MME). Por otro lado, mediante la interfaz S1-
U, el eNB se comunica con otra entidad de red encargada de procesar el plano de usuario (dicha entidad
de red de la EPC se denomina Serving Gateway, S-GW). Esta separacin entre entidades de red
dedicadas a sustentar el plano de control o bien el plano de usuario es una caracterstica importante de
la red LTE que permite dimensionar de forma independiente los recursos de transmisin necesarios para
el soporte de la sealizacin del sistema y para el envo del trfico de los usuarios.
Opcionalmente, los eNBs pueden conectarse entre si mediante la interfaz X2. A travs de esta interfaz,
los eNB se intercambian tanto mensajes de sealizacin destinados a permitir una gestin ms eficiente
del uso de los recursos radio (e.g., informacin para reducir interferencias entre eNBs) as como trfico
de los usuarios del sistema cuando estos se desplazan de un eNB a otro durante un proceso de
handover.
En la tabla se resumen las entidades de red e interfaces de E-UTRAN y se indican las principales
especificaciones del 3GPP relacionadas con cada una de ellas.

190
Tal como se ha comentado en la descripcin general de la arquitectura de E-UTRAN, el eNB integra todas las
funciones de la red de acceso. Por ello, en el eNB terminan todos los protocolos especficos de la interfaz radio.
Mediante dichos protocolos, el eNB realiza la transmisin de los paquetes IP hacia/desde los equipos de usuario
junto con los mensajes de sealizacin necesarios para controlar la operacin de la interfaz radio. El servicio de
transferencia de paquetes IP entre un eNB y un equipo de usuario se denomina formalmente como servicio
portador radio (Radio Bearer, RB). El eNB mantiene un contexto de cada uno de los equipos de usuario que tiene
conectados. En dicho contexto se almacena la informacin necesaria para mantener los servicios de E-UTRAN
activos (informacin sobre el estado del equipo de usuario, servicios portadores activos, informacin de
seguridad, capacidades del terminal, etc.).
Sin duda, la funcionalidad clave de un eNB consiste en la gestin de los recursos radio. As, el eNB alberga
funciones de control de admisin de los servicios portadores radio, control de movilidad (p.ej, decisin de realizar
un handover), asignacin dinmica de los recursos radio tanto en el enlace ascendente como descendente
(denominadas funciones de scheduling), control de interferencias entre estaciones base, control de la realizacin
y del envo de medidas desde los equipos de usuario que puedan ser tiles en la gestin de recursos, etc.
Otra funcin importante introducida en la funcionalidad de un eNB es la seleccin dinmica de la entidad MME de
la red troncal EPC cuando un terminal se registra en la red LTE. Esta funcin otorga un grado de flexibilidad muy
importante en la operativa de la red. En E-UTRAN, a diferencia de arquitecturas ms jerarquizadas como GERAN
o las primeras versiones de UTRAN, un eNB puede estar conectado simultneamente a mltiples MMEs de la red
troncal. El conjunto de MMEs a los que tiene acceso un NB se denomina su pool area. As, mediante la seleccin
de qu entidad MME va a controlar el acceso de cada usuario, es posible balancear la carga de sealizacin entre
diferentes MMEs as como aumentar la robustez del sistema frente a puntos de fallo crticos. Esta opcin se
soporta mediante lo que se denomina la interfaz S1 flexible (S1-flex).
Al igual que la posibilidad de interactuar con mltiples MMEs, un eNB puede enviar/recibir paquetes IP de los
usuarios a los que sirve a travs de diferentes pasarelas S-GW de la red troncal EPC. Ello conlleva que el eNB
albergue funciones de encaminamiento del trfico de los usuarios hacia la pasarela de red S-GW correspondiente.
La eleccin de S-GW en este caso compete a la entidad MME y no al eNB.
Un eNB puede gestionar una o varias celdas. Un caso tpico es el uso de sectorizacin de forma que, el eNB
ubicado en un emplazamiento soporta tantas celdas como sectores.

191
La interfaz radio soporta bsicamente tres tipos de mecanismos de transferencia de la informacin en el canal radio: difusin
de sealizacin de control, envo de paquetes IP y transferencia de sealizacin de control dedicada entre un equipo de
usuario y el eNB.
Difusin (broadcast) de sealizacin de control en la zona de cobertura de la celda. La informacin enviada permite a los
equipos de usuario detectar la presencia del eNB y conocer sus parmetros bsicos de operacin (e.g., potencia mxima
que pueden utilizar los equipos de usuario en la celda) as como la identidad de los operadores de red a los que puede
accederse a travs del eNB. La informacin difundida corresponde tanto a informacin especfica de la red de acceso
(denominada informacin del access stratum, AS) como de la red troncal (denominada informacin del non access
stratum, NAS). La difusin de sealizacin de control tambin sirve para forzar que un equipo de usuario que no tenga una
conexin de control establecida con el eNB, inicie un acceso a la red (funcin de aviso o paging).
Transferencia de paquetes IP de los usuarios a travs del canal radio. Tal como se ha comentado anteriormente, los
servicios de transferencia entre un eNB y un equipo de usuario se denominan servicios portadores radio (Radio Bearers,
RB). Es importante destacar que los servicios portadores radio de E-UTRAN han sido diseados especficamente para
soportar trfico IP y no permiten la transferencia de otros protocolos (e.g., paquetes X.25, tramas Ethernet, etc.). Por ello,
de cara a la optimizacin del envo de trfico IP a travs de la interfaz radio, los servicios portadores albergan funciones
como la compresin de cabeceras de los paquetes IP que permiten reducir el nmero de bytes enviados por la interfaz
radio (las cabeceras de los paquetes IP pertenecientes a un mismo tipo de trfico contienen un gran nmero de
parmetros idnticos, p.ej, direcciones origen y destino, por lo que no resulta necesario enviar todos los bytes de la
cabecera IP en cada uno de los paquetes).
Transferencia de sealizacin de control dedicada entre el eNB y un equipo de usuario. El establecimiento de una
conexin de control dedicada resulta imprescindible de cara a poder gestionar el uso de los servicios portadores radio as
como para realizar cualquier gestin de sealizacin con la red troncal (e.g., registro del terminal en la red). La conexin
de control se soporta mediante el protocolo Radio Resource Control (RRC). A travs de dicho protocolo se gestionan,
adems del establecimiento, modificacin y liberacin de los servicios portadores radio entre el eNB y el equipo de
usuario, otros mecanismos claves para la gestin eficiente de los recursos radio. Entre dichos mecanismos cabe citar el
control y envo de medidas radio desde los terminales haca el eNB y el mecanismo de handover, que permite que un
equipo de usuario cambie de celda manteniendo activos tanto la conexin de control como los posibles servicios
portadores radio que est utilizando. Los terminales que mantienen una conexin de control con E-UTRAN se dice que se
encuentran en modo conectado o activo, en contraposicin al denominado modo idle en que el terminal no tiene una
conexin RRC y bsicamente se encuentra monitorizando la informacin de control difundida por la red.

192
El plano de usuario de esta interfaz, denominado S1-U (S1 User Plane), proporciona un servicio de transferencia de datos de
usuario entre eNB y S-GW sin garantas de entrega (se basa en UDP) y que no soporta ni mecanismos de control de errores
ni de control de flujo. Este servicio de transferencia a travs de la interfaz S1-U se denomina servicio portador S1 (S1 bearer).
El plano de control, denominado S1-MME o tambin S1-C, se utiliza para soportar un conjunto de funciones y procedimientos
de control entre eNBs y la entidad MME de la red troncal.
Concretamente, entre los procedimientos soportados en la interfaz S1 destacan:
Procedimientos para establecimiento, modificacin y liberacin de recursos de los servicios portadores tanto en la interfaz
radio (servicio portador radio o RB) como en la interfaz S1 (S1 bearer). La concatenacin de un servicio portador radio y un
servicio portador S1 constituye el servicio portador completo que ofrece la red de acceso E-UTRAN y que se denomina E-
RAB (E-UTRAN Radio Access Bearer). Es importante tener en cuenta que en LTE, el establecimiento de estos servicios
portadores que constituyen el plano de usuario para la transferencia del trfico IP se controla desde la red troncal, en
particular desde la entidad de red MME. Por tanto, en LTE no se permite que un eNB o el propio equipo de usuario puedan
iniciar por su cuenta el establecimiento de un servicio portador radio. En la figura se ilustra dicho control del plano de
usuario por parte de la entidad MME.
Procedimientos de handover entre eNBs. Si la red E-UTRAN decide que un terminal debe cambiar de eNB en el
transcurso de una conexin, y no existe una interfaz X2 entre los dos eNBs involucrados, la interfaz S1-MME se utiliza
para articular el procedimiento de handover. De esta forma, a travs de la interfaz S1-MME, la entidad MME puede
establecer un nuevo contexto en el eNB destino asociado al terminal que va a realizar el cambio con toda la informacin
relativa a la configuracin de los servicios portadores que tiene establecidos el usuario as como las claves de seguridad.
De esta forma, el re-establecimiento del servicio a travs del nuevo eNB puede hacerse mucho ms rpidamente ya que
se evita el tener que ejecutar de nuevo los mecanismos para el establecimiento de los servicios portadores en la interfaz
radio as como los mecanismos de seguridad.
Procedimiento de aviso (Paging).Una de las funciones bsicas de la entidad MME es la gestin de la localizacin de los
equipos de usuario en la red. La gestin de localizacin permite conocer con cierta resolucin en qu eNB o conjunto de
eNBs (denominados reas de seguimiento, Tracking areas) puede ser localizado un usuario que se encuentre en modo
idle, es decir, que no tenga establecida una conexin de control RRC con ningn eNB. Por ello, cuando el MME quiere
forzar que un usuario en modo idle pase a modo activo, a travs de la interfaz S1-MME se ordena la ejecucin del
mecanismo de aviso en todos los posibles eNBs en los que espera encontrar al terminal.
Procedimiento de envo de forma transparente entre MME y eNB de los mensajes de sealizacin de control que fluyen
entre el MME y el equipo de usuario. Dichos mensajes corresponden a los protocolos denominados como protocolos NAS
(Non Access Stratrum).

193
Respecto al plano de control, entre las funciones y procedimientos soportados en la interfaz X2
destacan:
Soporte del mecanismo de handover entre eNBs. En concreto, a travs del plano de control se realiza
la transferencia del contexto de un usuario del eNB antiguo al nuevo y se controla el mecanismo de
transferencia de paquetes IP en el plano de usuario de X2. El contexto de usuario contiene
informacin relativa a los servicios portadores radio que tiene establecidos el usuario, claves de
seguridad as como los datos sobre las capacidades del terminal.
Indicacin del estado de carga del eNB. A travs de dicha interfaz, eNBs que tengan celdas vecinas
pueden transferirse informacin para llevar a cabo funciones de gestin de recursos radio como la
coordinacin de interferencias entre celdas que operen en el mismo canal.

194
Protocolos de la interfaz fsica E-UTRAN

El envo de paquetes IP entre el eNB y un equipo de usuario a travs de la interfaz radio se sustenta en una
torre de protocolos formada por una capa de enlace (o capa de nivel 2) y una capa fsica. La torre de
protocolos utilizada se muestra en la figura. La capa de enlace se desglosa a su vez en tres subcapas:
Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC) y Medium Access Control (MAC).
Cada capa/subcapa de la torre de protocolos se ocupa de un conjunto de funciones concreto y define el
formato de los paquetes de datos (e.g., cabeceras y colas) que se intercambian entre entidades remotas. A
continuacin se describen las principales caractersticas de las diferentes capas/subcapas:
Packet Data Convergence Protocol (PDCP). Constituye la capa superior de la torre de protocolos
encargada de proporcionar el punto de acceso al servicio portador radio (Radio Bearer, RB). Es decir, los
paquetes IP del trfico de usuario se entregan y se reciben a travs del servicio de transferencia
proporcionado por la capa PDCP. Las funciones principales de esta capa son la compresin de cabeceras
de los paquetes IP y el cifrado de la informacin para garantizar su confidencialidad e integridad. La
cabecera aadida por la capa PDCP bsicamente contiene un nmero de secuencia que identifica al
paquete IP enviado y permite realizar una entrega ordenada de los paquetes IP en el extremo receptor as
como detectar posibles duplicados de los paquetes IP (ocasionados por ejemplo en un proceso de
handover). Cada servicio portador radio tiene una entidad PDCP asociada.
Radio Link Control (RLC). La capa RLC permite enviar de forma fiable los paquetes PDCP entre el eNB y
equipo de usuario. Para ello, la capa RLC soporta funciones de correccin de errores mediante
mecanismos Automatic Repeat ReQuest (ARQ), concatenacin, segmentacin y re-ensamblado, entrega
ordenada de paquetes PDCP a capas superiores (excepto durante el mecanismo de handover), deteccin
de duplicados y deteccin/recuperacin de errores en el protocolo. Cada servicio portador radio tiene una
entidad RLC asociada.
Medium Access Control (MAC). Es la capa encargada de controlar el acceso al canal radio. Para ello, la
capa MAC soporta funciones de scheduling dinmico entre equipos de usuario atendiendo a prioridades,
multiplexa los paquetes RLC de diferentes servicios portadores radio en los canales de transporte
ofrecidos por la capa fsica (un canal de transporte puede ser compartido por varios servicios portadores
de uno o varios equipos de usuario) y realiza un control de errores mediante Hybrid ARQ (HARQ). Los
servicios de transferencia que la capa MAC ofrece a la capa RLC se denominan canales lgicos. Existe
una nica entidad MAC por celda.
Capa fsica. Es la capa encargada de realizar la transmisin propiamente dicha a travs del canal radio.
Alberga funciones de codificacin de canal, modulacin, procesado asociado a las tcnicas de mltiples
antenas de transmisin/recepcin, y mapeo de la seal a los recursos fsicos frecuencia-tiempo
apropiados. En el enlace ascendente, la capa fsica se basa en un esquema single-carrier FDMA. En el
enlace descendente, el esquema de transmisin es OFDMA. Los servicios de transferencia que la capa
fsica ofrece a la capa MAC se denominan canales de transporte. Existe una nica entidad de capa fsica
por celda.

195
Respecto al plano de control entre el equipo de usuario y la red, ste se soporta sobre la misma capa de
enlace (protocolos PDCP, RLC, MAC) y la misma capa fsica utilizadas en el plano de usuario. Los
protocolos de nivel de red especficos de este plano son:
Radio Resource Control (RRC). Esta capa permite establecer una conexin de control entre el eNB y
un equipo de usuario a travs de la cual se llevan a cabo un nmero importante de funciones
relacionadas con la gestin de la operativa de la interfaz radio. Entre dichas funciones de la capa
RRC destacan los mecanismos de gestin de los servicios portadores radio (e.g., sealizacin para el
establecimiento/liberacin/modificacin de los portadores radio), el soporte de funciones de movilidad
(e.g., sealizacin de handover), la difusin (broadcast) de parmetros de sistema y funciones de
aviso de los terminales que no disponen de una conexin RRC establecida (e.g., envo de avisos a
travs del canal de paging). El servicio de transferencia que ofrece la capa PDCP para el envo de los
mensajes de sealizacin del protocolo RRC se denomina servicio portador de sealizacin
(Signalling Radio Bearer, SRB).
Sealizacin de los protocolos NAS. Los protocolos NAS se extienden entre la entidad de red MME
en la red troncal y el equipo de usuario. Los mensajes de estos protocolos se transportan de forma
transparente en la interfaz radio encapsulados dentro de la parte de datos de los mensajes RRC. Las
principales funciones de los protocolos NAS son: autenticacin, autorizacin, gestin de movilidad de
los terminales que no tienen una conexin RRC establecida y gestin de los servicios portadores de la
red EPS.

196
La estructura de protocolos utilizada en E-UTRAN para soportar las interfaces S1 y X2 establece una
separacin entre la capa de red radio (Radio Network Layer, RNL) y la capa de red de transporte
(Transport Network Layer, TNL), tal como ya introdujo en la red UMTS. Esta descomposicin tiene como
objetivo aislar las funciones que son especficas del sistema de comunicaciones mviles (UMTS o LTE),
de aquellas otras que dependen de la tecnologa de transporte utilizada (e.g., IP, ATM). De esta forma,
los protocolos especficos de la red de acceso radio constituyen la capa RNL mientras que la capa TNL
alberga los protocolos utilizados para el transporte de la informacin de la capa RNL entre las entidades
de la red. En la figura se ilustra la arquitectura de protocolos de las interfaces S1 y X2. Tanto el plano de
usuario de la interfaz S1 (S1-U) como el de la interfaz X2 utilizan el protocolo de encapsulado GTP-U
(GPRS Tunneling Protocol User Plane) para el envo de paquetes IP de usuario. El procotolo GTP-U
es un protocolo heredado de GPRS que en la redes GSM y UMTS se utiliza dentro del dominio de
paquetes de la red troncal (e.g., en la interfaz entre SGSN y GGSN) as como en el plano de usuario de
la interfaz Iu-PS de la red de acceso UTRAN. En las interfaces S1-U y X2, el protocolo GTP-U se
transporta sobre UDP/IP y fundamentalmente se utiliza para multiplexar los paquetes IP de mltiples
usuarios (los paquetes IP de un determinado servicio portador se encapsulan con una determinada
etiqueta identificador de tnel-). Finalmente, es importante destacar que los planos de usuario de
ambas interfaces no contemplan mecanismos de entrega garantizada para la transferencia de los
paquetes de usuario, ni tampoco mecanismos de control de errores o control de flujo.

197
Respecto al plano de control de la interfaz S1 (S1-MME o S1-C), la capa de red radio consiste en el
protocolo S1-AP (S1 - Application Part). Este protocolo es el que sustenta los procedimientos soportados
en la interfaz S1 (establecimiento de servicios portadores en el eNB, control del handover, paging, etc.).
La transferencia de los mensajes de sealizacin del protocolo S1-AP entre eNBs y MMEs se realiza
mediante el servicio de transferencia fiable que ofrece el protocolo de transporte Stream Control
Transmission Protocol (SCTP). SCTP es un protocolo de transporte (al igual que otros protocolos como
TCP y UDP) de propsito general estandarizado por IETF que fue concebido originariamente para el
envo de sealizacin de redes telefnicas sobre redes IP. SCTP hereda muchas de las funciones
contempladas en TCP a la vez que introduce importantes mejoras encaminadas a proporcionar mayor
robustez y versatilidad en la transferencia de diferentes tipos de informacin.
En particular, al igual que TCP, SCTP dispone de mecanismos de control de flujo y de congestin en la
conexin, denominada asociacin en SCTP. Por otro lado, SCTP incorpora soporte para multihoming
(las asociaciones soportan la transferencia a travs de mltiples caminos entre los nodos participantes,
es decir, los nodos participantes pueden disponer de mltiples direcciones IP), multi-streaming (mltiples
flujos pueden enviarse en paralelo en el seno de una misma asociacin) y el envo de la informacin se
estructura en base a mensajes (a diferencia del protocolo TCP que trata la informacin como una
secuencia de bytes). Estas nuevas capacidades son las que hicieron que en 3GPP se optara por la
utilizacin de este protocolo, en lugar de TCP, para implementar el plano de control de las interfaces S1
y X2 de E-UTRAN.

198
Atendiendo a la descripcin realizada en los anteriores apartados, en la figura se ilustra el plano de
usuario completo de E-UTRAN para el envo de paquetes IP entre el equipo de usuario (UE) y la red
troncal (S-GW). Los paquetes IP contienen la informacin correspondiente al servicio que el usuario est
utilizando (voz, video, datos) as como la sealizacin a nivel de aplicacin (protocolos SIP, RTCP, etc.).
El eNB realiza funciones de relay entre la torre de protocolos PDCP/RLC/MAC/PHY de la interfaz radio
y la torre de protocolos de la interfaz S1-U. Es importante destacar que el eNB no realiza ninguna
decisin de encaminamiento a partir de la informacin contenida en las cabeceras IP de los paquetes de
usuario sino que simplemente se ocupa de su transferencia entre las dos interfaces atendiendo a los
servicios portadores establecidos.

199
Se ilustra la torre de protocolos del plano de control para el envo de sealizacin NAS entre el equipo
de usuario y la red troncal. Los protocolos se transportan encapsulados (de forma transparente) dentro
de mensajes RRC en la interfaz radio y en mensajes S1-AP en la interfaz S1-MME. El eNB realiza las
funciones de relay necesarias entre ambas torres de protocolos.

200
La arquitectura E-UTRAN presenta importantes diferencias con respecto a las redes de acceso UTRAN
y GERAN. Las redes de acceso anteriores a E-UTRAN se basan en una arquitectura jerrquica donde
las funciones de la red de acceso se distribuyen en dos tipos de nodos: estaciones base (denominados
Nodos B en UTRAN) y equipos controladores de estas estaciones base (denominados RNC en
UTRAN). En esta arquitectura jerarquizada, los equipos controladores albergan el plano de control de
la interfaz radio (sealizacin de control del enlace radio) as como mltiples funciones del plano de
usuario (algunas funciones de la capa de acceso al medio, control de enlace, compresin de
cabeceras, etc.). Por otro lado, las estaciones base se ocupan principalmente de las funciones de
transmisin radio (procesado de capa fsica) y su operacin se gestiona de forma remota desde los
equipos controladores. La interconexin entre estaciones base y controladores se realiza mediante una
interfaz denominada Iub de forma que la topologa de red resultante a nivel lgico es una topologa en
forma de estrella. Los equipos controladores tambin pueden conectarse entre si mediante interfaces
especficas como la interfaz Iur que, en el caso de UTRAN, permite la explotacin del mecanismo de
macrodiversidad entre dos Nodos B que se encuentren conectados a RNCs diferentes. La
interconexin de la red de acceso a la troncal se realiza a travs de los equipos controladores
mediante las interfaces Iu-PS, entre RNCs y los nodos SGSNs del dominio de paquetes, y Iu-CS, entre
RNCs y las centrales de conmutacin MSC del dominio de circuitos.

201
Comparando la arquitectura de UTRAN con E-UTRAN, puede observarse en la figura que E-
UTRAN sigue una arquitectura plana, sin ningn nivel de jerarquizacin. Tal como se ha
indicado en la lista de funciones asociadas a un eNB, los protocolos radio se ejecutan
ntegramente en los eNBs (no es necesario ningn equipo adicional como el RNC de UTRAN).
Es importante destacar que la integracin de los protocolos radio de capa fsica y de enlace en
la estacin base es una caracterstica adoptada tambin en otras interfaces radio como IEEE
802.11 para redes de rea local y IEEE 802.16 utilizada en WiMAX. La interconexin de E-
UTRAN con la red troncal se realiza en cada uno de las estaciones base (eNBs) mediante la
interfaz S1. Tal como se ha comentado anteriormente, la interfaz S1 soporta configuraciones
donde un eNB puede estar conectado simultneamente con mltiples elementos de la EPC
(varios MME y/o varios S-GW). Esto hace que el dimensionamiento de la red de acceso (eNBs)
y de los equipos de la red troncal (MME y pasarelas S-GW) pueda hacerse de forma ms
flexible, permitiendo, por ejemplo, que el trfico cursado a travs de los eNBs se derive hacia el
nodo de la red troncal ms adecuado atendiendo a criterios de balanceo de cargas. Por el
contrario, en una estructura jerrquica en rbol como la utilizada en UTRAN, la capacidad
sobrante en nodos ubicados en ramas diferentes no puede ser aprovechada. Asimismo, aunque
de forma opcional, las estaciones base de E-UTRAN pueden conectarse directamente entre si
formando una topologa semi-mallada (un eNB puede conectarse a un subconjunto de eNBs
mediante la interfaz X2) que permite tanto la transferencia de informacin de control como de
trfico de usuario entre ellas. Esta opcin no est contemplada en UTRAN (los Nodos B no se
interconectan entre ellos).
Uno de los principales motivos que condujeron a la utilizacin de arquitecturas jerrquicas en los
sistemas 2G y 3G fue bsicamente econmico: la concentracin de los recursos de procesado
en unos pocos equipos capaces de servir a un elevado conjunto de usuarios a travs de
estaciones base poco complejas, y por tanto, con un coste relativamente menor, constitua una
opcin ms competitiva en trminos de coste frente a la alternativa de utilizar estaciones base
mucho ms complejas capaces de albergar la mayora de las funciones propias del sistema de
comunicaciones. Este argumento ha ido perdiendo peso de forma progresiva en los ltimos
aos conforme a los avances realizados en las tecnologas de computacin que permiten
disponer de plataformas de procesado muy potentes a costes reducidos. Adicionalmente, otros
argumentos que han propiciado la transicin a arquitecturas planas como E-UTRAN, en lugar de
arquitecturas jerarquizadas, han sido la explotacin de mecanismos de diversidad temporal
como H-ARQ y schedulers rpidos que requieren ser ejecutados en la propia estacin base para
conseguir tiempos de ida y vuelta muy reducidos.
La explotacin de estos mecanismos de diversidad conlleva a la vez que no sea necesario
soportar mecanismos de diversidad adicionales como la macrodiversidad (transmisin y
recepcin simultnea de un equipo de usuario en varias celdas) para mejorar las prestaciones
del enlace radio. Ntese que el soporte de macrodiversidad es uno de los pilares fundamentales
de UTRAN que requiere la realizacin de funciones especficas de combinacin y bifurcacin del
trfico dentro de la red de acceso, en particular, en los equipos controladores RNC. Tambin, en
trminos de escalabilidad y robustez, existen argumentos a favor de las arquitecturas planas
frente a las centralizadas. La existencia de un elemento crtico y de alto coste como el
controlador en las arquitecturas centralizadas condiciona la escalabilidad de la red de acceso
(e.g., si se requiere aumentar la capacidad o cobertura de la red mediante la instalacin de una
estacin base adicional, y el controlador ya se encuentra al lmite de su capacidad, sera
necesario introducir un nuevo controlador en la red simplemente para poder incorporar una
nueva estacin base). Adems, un elemento controlador constituye un punto de fallo crtico que
puede afectar al funcionamiento de muchas estaciones base y, por tanto, afectar a un elevado
nmero de usuarios (un controlador RNC puede gestionar varios centenares de estaciones
base).

202
El diseo de la red troncal EPC ha sido concebido principalmente para proporcionar un servicio de conectividad IP (evolucin
del servicio GPRS) mediante una arquitectura de red optimizada que permite explotar las nuevas capacidades que ofrece la
red de acceso EUTRAN. Asimismo, otro factor clave considerado en el diseo de la arquitectura de la red troncal ha sido la
posibilidad de acceder a sus servicios a travs de otras redes de acceso tanto 3GPP (UTRAN y GERAN) como fuera del
mbito del 3GPP (cdma2000, WiMAX, 802.11).
La arquitectura mostrada en la figura comprende nicamente las entidades de red que forman el ncleo de la red troncal EPC
para la provisin de servicios de conectividad IP a travs de una red de acceso E-UTRAN, junto con las entidades de red e
interfaces que soportan las funciones relacionadas con el control de del servicio de conectividad (e.g., control de QoS) y de
los mecanismos de tarificacin. Es importante matizar en este punto que las entidades de red en base a las cuales se realiza
la descripcin de la arquitectura de la red troncal son entidades funcionales: una entidad de red en 3GPP se concibe como
una entidad lgica que cubre una funcionalidad perfectamente delimitada. Por tanto, una implementacin concreta de la red
troncal EPC admite que diferentes entidades funcionales puedan residir en el mismo equipo fsico.
El ncleo del sistema EPC est formado por tres entidades de red: MME (Mobility Management Entity), Serving Gateway (S-
GW) y Packet Data Network Gateway (P-GW). Estas tres entidades, junto con la base de datos principal del sistema 3GPP
denominada HSS (Home Subscriber Server), constituyen los elementos bsicos para la provisin del servicio de conectividad
IP entre los equipos de usuario conectados a travs de E-UTRAN y redes externas a las que se conecta la red troncal EPC.
Las funciones asociadas con el plano de usuario se concentran en las dos pasarelas (S-GW y P-GW) mientras que la entidad
MME se encarga de las funciones y sealizacin del plano de control. La interconexin de la red de acceso E-UTRAN a la
EPC se realiza a travs de la interfaz S1. En particular, la interfaz S1-MME que sustenta el plano de control termina en la
entidad MME mientras que la interfaz S1-U del plano de usuario termina en el S-GW.
La entidad MME termina el plano de control de los equipos de usuario conectados a la red LTE mediante los protocolos NAS y
controla las funciones de transferencia del plano de usuario de red LTE a travs de la interfaz S114 con la pasarela S-GW.
Asimismo, la entidad MME se conecta a la entidad HSS a travs de la interfaz S6a para acceder a la informacin asociada a
los usuarios de la red que estn autorizados a establecer conexiones a travs de E-UTRAN. Las entidades MME tambin
pueden comunicarse entre ellas mediante la interfaz S10.

203
Por otro lado, la interconexin de la EPC con redes externas o plataformas de servicio (e.g, plataformas IMS) se
realiza a travs de la pasarela P-GW mediante la interfaz SGi. La pasarela P-GW soporta funciones, entre otras, de
asignacin de direcciones IP a los equipos de usuario y mecanismos de control de los parmetros de calidad de
servicio de las sesiones de datos establecidas a travs de la red LTE. Internamente, la pasarela P-GW se conecta a
la pasarela S-GW mediante la interfaz S5, cuando ambas pasarelas pertenecen al mismo operador, y mediante S8,
cuando stas se encuentran en redes de operadores diferentes y se proporciona un servicio de roaming o
itinerancia
La entidad de red PCRF (Policy and Charging Rules Function) constituye un elemento clave de todos los sistemas
3GPP, y en particular, del sistema LTE. La entidad PCRF forma parte del marco funcional denominado PCC (Policy
and Charging Control) que se utiliza para controlar los servicios portadores que ofrece la red LTE (e.g., activacin y
determinacin de los parmetros de QoS asociados a cada servicio portador) as como realizar el control de los
mecanismos de tarificacin (e.g., tarificacin on-line, offline, medicin del volumen de datos transferido, tiempo
transcurrido, etc.). As pues, mediante la interfaz Gx, el PCRF gestiona los servicios portadores EPS de la red LTE
mediante el envo de unas reglas de uso (i.e., reglas PCC) que sirven para configurar la operacin de unas
funciones especficas del plano de usuario de la pasarela P-GW (e.g., funciones que limitan la tasa de transferencia
en bits/s de los servicios portadores). La entidad PCRF es accesible desde las plataformas de servicios externas
como IMS mediante la interfaz Rx. Dicha interfaz ofrece la funcionalidad de control necesaria para que los
servidores de aplicacin externos puedan proporcionar informacin asociada a los servicios finales a los que
accede el usuario junto con las caractersticas y requerimientos de QoS. A modo de ejemplo, si un usuario
establece un servicio de videoconferencia a travs de IMS, el elemento que controla la provisin del servicio en IMS
puede indicar a travs de la interfaz Rx cules son los parmetros de QoS que debe proporcionar el servicio
portador de la red LTE para transferir de forma adecuada la informacin de la videoconferencia. Con esta
informacin, la entidad PCRF enva a la red LTE las reglas PCC pertinentes para la configuracin de los servicios
portadores. Finalmente, las entidades OFCS (Offline Charging System) y OCS (Online Charging System)
constituyen el ncleo del sistema de tarificacin de la red. Ambas entidades interactan directamente con la
pasarela P-GW mediante la interfaz Gz, en el caso de OFCS, y Gy, en el caso de OCS. El marco de tarificacin
soportado es un marco flexible que permite desplegar modelos de tarificacin en base a diferentes parmetros tales
como tiempo de uso, volumen de datos, eventos, etc.

204
Funciones de la entidad MME

La entidad MME constituye el elemento principal del plano de control de la red LTE para gestionar el acceso
de los terminales a travs de E-UTRAN. Todo terminal que se encuentre registrado en la red LTE y sea
accesible a travs de E-UTRAN, tiene una entidad MME asignada.
La eleccin de la entidad MME se realiza en el proceso de registro y depende de aspectos tales como la
ubicacin geogrfica del terminal en la red (cada MME sirve a un conjunto determinado de eNBs) as como a
criterios de balanceo de cargas (gracias al soporte de la interfaz S1-flex). Dicha entidad mantiene un contexto
de datos del usuario (e.g., identificadores del usuario, conexiones y servicios portadores EPS activos, claves
de seguridad, datos de localizacin del usuario en la red, etc.) y articula todas las gestiones que se realicen
en relacin a dicho usuario (e.g., establecimiento de servicios portadores EPS, etc.). La entidad MME
asignada a un usuario puede ir cambiando atendiendo a la movilidad de dicho usuario dentro de la zona de
servicio de la red. Las principales funciones de la entidad MME son las siguientes:
Autenticacin y autorizacin del acceso de los usuarios a travs de E-UTRAN. A partir de los datos de
usuario obtenidos desde el HSS, la entidad MME se encarga de llevar a cabo el control de acceso a la red
mediante la identificacin, autenticacin y autorizacin de los usuarios que se conectan a travs de E-
UTRAN.
Gestin de los servicios portadores EPS. La entidad MME es la encargada de articular la sealizacin
necesaria para establecer, mantener, modificar y liberar los servicios portadores EPS sobre los cuales se
sustenta el envo de paquetes IP entre los equipos de usuario y la red externa.
Gestin de movilidad de los usuarios en modo idle (i.e. terminales que no tienen ninguna conexin de
control establecida con E-UTRAN). La entidad MME es la encargada de hacer un seguimiento de la
localizacin de los usuarios dentro del rea de servicio de la red. Para ello, se definen unas reas de
seguimiento (Tracking areas) y unos procedimientos asociados (denominados Tracking Area Update) que
permiten disponer de informacin de localizacin de todos los usuarios que se encuentren registrados en la
red LTE. Esta gestin es conocida especficamente como gestin de localizacin,
Sealizacin para el soporte de movilidad entre EPS y redes 3GPP. La entidad MME de la EPC y la entidad
SGSN pueden intercambiarse informacin relativa a los equipos de usuario conectados bien a travs de E-
UTRAN o de UTRAN/GERAN para poder gestionar, por ejemplo, mecanismos de gestin de movilidad
conjunta (la red troncal GPRS as como la red troncal EPC pueden intercambiar informacin relativa a las
reas de seguimiento). Dicha sealizacin se realiza a travs de la interfaz S3 entre MME y SGSNs.
Tambin, a travs de esta interfaz, se gestionan los procedimientos de reubicacin del plano de usuario en
las entidades de la red troncal (e.g., el plano de usuario de un terminal conectado inicialmente a UTRAN y
que fluye a travs de un determinado SGSN, se reubica hacia una pasarela S-GW cuando el terminal
cambia de UTRAN a E-UTRAN).
Terminacin de los protocolos de sealizacin NAS (Non Access Stratum). Los protocolos NAS fluyen entre
el equipo de usuario y la entidad MME que tenga asignada. A travs de ellos se soportan los
procedimientos relacionados con las funciones de control de acceso a la red LTE, la gestin de las
conexiones a redes externas y el establecimiento de servicios portadores EPS, y la gestin de movilidad de
los terminales que se encuentran en modo idle.

205
Esta entidad acta de pasarela del plano de usuario entre E-UTRAN y la red troncal EPC.
Al igual que sucede con la entidad MME, un usuario registrado en la red LTE dispone de una entidad S-GW
asignada en la EPC a travs de la cual transcurre su plano de usuario. La asignacin de la pasarela S-GW
responde tambin a criterios geogrficos as como de balanceo de cargas. Entre las principales funciones del S-
GW podemos destacar:
La entidad S-GW proporciona un punto de anclaje en la red troncal EPC con respecto a la movilidad del terminal
entre eNBs. De esta forma, en un proceso de handover entre dos eNBs, el cambio del plano de usuario puede
nicamente derivar en un cambio del servicio portador S1 entre los eNBs implicados y el S-GW, mantenindose
sin cambios el resto del plano de usuario (camino entre S-GW y P-GW).
La funcionalidad de punto de anclaje tambin se aplica a la gestin de movilidad con las otras redes de acceso
3GPP (UTRAN y GERAN). De esta forma, equipos de usuario que se conecten a la red LTE a travs de UTRAN
o GERAN, disponen tambin de un S-GW asociado en la red troncal EPC por el que fluye su plano de usuario.
Almacenamiento temporal de los paquetes IP de los usuarios en caso de que los terminales se encuentren en
modo idle. En la red LTE, el plano de usuario entre S-GW y el equipo de usuario puede desactivarse cuando
no haya trfico para transmitir. Es decir, aunque las conexiones y servicios portadores EPS permanezcan
activos, un terminal puede encontrarse en estado idle y, por tanto, no estar conectado a ningn eNB. As pues,
cuando se recibe trfico de la red externa dirigido a un usuario en modo idle, este trfico llega hasta la entidad S-
GW a cargo de ese usuario, que retiene temporalmente los paquetes IP e inicia (a travs de la sealizacin
pertinente con la entidad MME) el restablecimiento del plano de usuario hasta el equipo de usuario.
Encaminamiento del trfico de usuario. Como todo el trfico de un usuario fluye a travs de una pasarela S-GW,
sta alberga la informacin y funciones de encaminamiento necesarias para dirigir el trfico de subida (trfico IP
proveniente de los equipos de usuario) hacia la pasarela (o pasarelas) P-GW que corresponda y el trfico de
bajada (proveniente de las pasarelas P-GW) hacia el eNB a travs del cual se encuentra conectado el equipo de
usuario. Es importante destacar que, aunque un usuario puede tener mltiples conexiones establecidas con
diferentes pasarelas P-GW de forma simultnea, todo el trfico atraviesa una nica S-GW.

206
Esta entidad es la encargada de proporcionar conectividad entre la red LTE y las redes externas (denominadas
como Packet Data Network, PDN, en las especificaciones 3GPP). Es decir, a travs de la entidad P-GW, un
usuario conectado al sistema LTE resulta visible en la red externa. Por tanto, los paquetes IP generados por el
usuario se inyectan en la red externa a travs de esta pasarela y, viceversa, todo el trfico IP dirigido a un
terminal LTE proveniente de la red externa va a ser encaminado hasta el P-GW. Un usuario tiene asignada como
mnimo una pasarela P-GW desde su registro en la red LTE. Entre las principales funciones de la pasarela P-GW
podemos destacar:
Aplicacin de las reglas de uso de la red (i.e., policy control) y control de tarificacin a los servicios portadores
que tenga establecidos el terminal. Estas funciones forman parte del marco PCC.
La asignacin de la direccin IP de un terminal utilizada en una determinada red externa se realiza desde la
pasarela P-GW correspondiente. La direccin puede ser una direccin IPv4, IPv6 o bien un par de direcciones
(IPv4, IPv6). El mecanismo de asignacin de la direccin se sustenta en la sealizacin propia de la red LTE
(e.g., el terminal recibe la direccin IP a travs de los protocolos NAS) o bien en la utilizacin de protocolos
propios de redes IP como DHCP.
La pasarela P-GW acta de punto de anclaje para la gestin de movilidad entre LTE y redes no 3GPP. La
pasarela alberga funciones de Home Agent (HA) para proporcionar continuidad de servicio en caso de utilizar el
protocolo Mobile IPv4 (MIPv4) para gestionar la movilidad entre la red LTE y, por ejemplo, una red WiMAX.
Adems de MIPv4, la pasarela incluye soporte de movilidad para los protocolos Dual Stack MIPv6 (DSMIPv6) y
Proxy MIPv6 (PMIPv6).
El trfico IP que transcurre por la pasarela P-GW es procesado a travs de un conjunto de filtros que asocian
cada paquete IP con el usuario y servicio portador EPS correspondiente. Esto permite, por un lado, aplicar las
reglas de uso y tarificacin antes comentadas, y por otro, aplicar funciones de inspeccin y verificacin de la
validez de los paquetes IP que cursa la red (packet screening). De esta forma, la pasarela puede descartar los
paquetes IP que sean considerados como trfico anmalo (e.g., un equipo de usuario enva paquetes con una
direccin o puertos para los que no est autorizado).

207
El Servidor de informacin de abonados (HSS)

El HSS es la base de datos principal del sistema 3GPP que almacena la informacin de los usuarios
de la red. La informacin contenida en el HSS abarca tanto informacin relativa a la subscripcin del
usuario (i.e., perfil de subscripcin) como informacin necesaria para la propia operativa de la red. La
base de datos HSS es consultada, y modificada, desde las diferentes entidades de red encargadas de
proporcionar los servicios de conectividad o servicios finales (desde, e.g., MME de red troncal EPC,
SGSN de la red GPRS, MSC del dominio de circuitos y tambin desde servidores de control del
subsistema IMS). El HSS contiene tanto informacin permanente que slo puede ser cambiada
mediante procesos administrativos (e.g., campos creados al dar de alta a un usuario en la red o
cambiar las condiciones de su contrato), as como informacin temporal que cambia a raz de la propia
operacin del sistema (e.g., localizacin del terminal dentro de la zona de servicio del sistema). As,
entre la informacin almacenada en el HSS podemos destacar: identificadores universales del usuario
(e.g., International Mobile Subscriber Identity, IMSI), identificadores de servicio (e.g., Mobile Station
ISDN, MSISDN); informacin de seguridad y cifrado (vectores de autenticacin); informacin de
localizacin del usuario en la red (identificador de la entidad de control, e.g, MME, que proporciona el
plano de control hacia un determinado usuario); e informacin necesaria para la provisin de los
servicios de acuerdo con las condiciones establecidas en el contrato de subscripcin (e.g.,
identificador de la red externa y parmetros de calidad de servicio del servicio portador por defecto).
La entidad HSS se estandariz en 3GPP R5 en base a la integracin de dos entidades definidas
inicialmente en redes GSM y que se denominan HLR (Home Location Register) y AuC (Authentication
Center), a las que se aadieron funciones adicionales necesarias para soportar el acceso y la
operativa del sistema LTE. En la Release 8 correspondiente al sistema LTE, el HSS abarca:
El subconjunto de funciones de las entidades HLR/AuC necesarias para el funcionamiento del
dominio de paquetes EPC, as como GPRS. El acceso a HSS desde la red EPC se realiza desde la
entidad de red MME mediante la interfaz S6a.
El subconjunto de funciones de las entidades HLR/AuC necesarias para el funcionamiento del
dominio CS.
Funciones de soporte asociadas a las funciones de control del subsistema IMS como la gestin de
informacin relativa a la subscripcin de servicios IMS y el almacenamiento de perfiles de usuario
asociados a servicios IMS.
Las entidades de red que acceden a la base de datos HSS para gestionar el acceso al servicio de
conectividad de la red troncal EPC son las siguientes. Cuando el acceso se realiza a travs de E-
UTRAN, la entidad MME es la que interacta con la base de datos a travs de la interfaz S6a. Cuando
el acceso es a travs de UTRAN o GERAN, el acceso a HSS se realiza desde el Server GPRS
Support Node (SGSN) mediante la interfaz S6d. Cuando el acceso es a travs de redes no 3GPP, el
acceso se canaliza a travs del servidor AAA mediante la interfaz SWz.

208
Posibles configuraciones de la red EPC

Las entidades de red en base a las que se describe la arquitectura de los sistemas LTE son
entidades funcionales. As, una entidad de red en 3GPP se concibe como una entidad lgica que
cubre una funcionalidad perfectamente delimitada. Por tanto, una implementacin concreta de la red
LTE admite que diferentes entidades funcionales pueden residir en el mismo equipo fsico.
Se ilustran cuatro posibles implementaciones de la red troncal EPC en base a la ubicacin fsica de
las tres principales entidades de red que la componen: MME, S-GW y P-GW. Tal como se muestra
en la opcin (A), una implementacin posible de la red troncal EPC consiste en integrar las tres
entidades funcionales en un nico equipo de red.
Esta opcin conduce a que el nmero de saltos o puntos de procesado del plano de usuario en la
red LTE sea nicamente de dos (eNB y equipo de la red troncal S-GW+P-GW), con la consiguiente
mejora en trminos de latencia. No obstante, esta configuracin no permite dimensionar por separado
los recursos necesarios para soportar el plano de control y el de usuario de forma que el nmero de
equipos de red troncal necesarios debe contemplar el peor de los casos. Ntese que, como el
dimensionado de los recursos del plano de control depende principalmente del nmero de usuarios
mientras que el dimensionado del plano de usuario est asociado al volumen de trfico, la proporcin
entre el nmero de recursos necesarios para soportar ambos planos puede abarcar un amplio rango
de valores atendiendo a la relacin y evolucin del nmero de usuarios y del volumen de trfico que
genera cada usuario en la red. De la misma manera, el montante de recursos necesarios para
soportar la funcionalidad de punto de anclaje del plano de usuario (i.e., S-GW) y la funcionalidad de
pasarela con redes externas (i.e., P-GW) tampoco guarda una relacin de proporcionalidad clara. El
nmero de equipos de red que alberguen la funcionalidad de P-GW puede depender en gran medida
del nmero y tipologa de las redes externas a las que se debe proporcionarse servicio mientras que
el nmero de equipos S-GW est vinculado ms directamente al nmero de usuarios y distribucin
geogrfica de la red de acceso. Por tanto, implementaciones de equipos que alberguen ambas
funciones, tal como sera el caso de la opcin (A), limitan claramente la versatilidad y escalabilidad
del sistema.
En el otro extremo, la opcin (D) consiste en alojar cada entidad de red en un equipo fsico diferente.
Esta opcin permite dimensionar ms adecuadamente los recursos necesarios para cada
funcionalidad: plano de control, plano de usuario y puntos de anclaje/pasarelas con redes externas.
En este caso, el nmero de saltos del plano de usuario en la red es de tres (estacin base, S-GW y
P-GW).
Adems de los dos casos extremos, se tienen las otras dos posibilidades: la opcin (B) permitira
explotar la separacin de plano de control y usuario, y la opcin (C) explotara la separacin de las
funciones de anclaje y las funciones de interconexin a redes externas.

209
Una gran cantidad de interfaces del EPS estn basadas en Diameter. Estas son las ms importantes:
S6 (EPS) : Habilita la transferencia de los datos de suscripcin yu autenticacin para autenticar y
autorizar el acceso del usuario al EPS. Se implementa entre el MME y el HSS
S13 (EPS) : Se utiliza para la verificacin del IMEI entre el MME y el EIR
Gx (EPS) : Permite al PCEF (ej. El P-GW) obtener las reglas de polticas y tasacin del PCRF. Con
estas reglas, el PCEF sabe como autorizar, bloquear o restringir los flujos IP y como debe tasar
dichos flujos
Gy (EPS) : Es la interfaz de tasacin online entre el PCEF y el OCS
Gz (EPS) : Es la interfaz de tasacin offline entre el PCEF y el OFCS
S9 (EPS) : S9 es la interfaz entre el PCRF en la red visitada y el PCRF en la red matriz. Se utiliza
cuando el PDN-GW que termina los servicios portadores del usuario visitante pertenece a la red
visitada (no mostrado en la figura)
Rx (EPS) : Mediante esta interfaz el IMS solicita los recursos de la red de acceso (portadores
dedicados) para garantizar la QoS de los servicios correspondientes a sesiones IMS. Se implementa
ente el IMS y el PCRF
Cx (IMS) : Es una interfaz propia de IMS entre los CSCF y el HSS para autenticar, autorizar y localizar
al usuario
Sh (IMS) : Se implementa entre los servidores de aplicacin IMS (IMS AS) y el HSS para obtener los
datos de servicio requeridos para la ejecucin de un determinado servicio.
Rf (IMS) : Es la interfaz de tasacin offine entre las entidades IMS y el OFCS
Ro (IMS) : Es la interfaz de tasacin online entre las entidades IMS y el OCS

210
Interface S6a
The interface S6a lies between the HSS (Home Subscriber Server) and the MME (Mobility Management Entity) for
authentication and authorization. This interface has the following properties:
Transport of subscriber related data.
Transport of location information.
Authorizing a user to grant access to EPS.
Transport of authentication information.
Interface S6b
The reference point S6b lies between the PDG (PDN Gateway) and the 3GPP AAA Proxy/Server for mobility-related
authentication. This interface has the following properties:
Transport of commands to retrieve and store the mobility parameters.
Transport of static QoS.
Interface S6c
The reference point S6c lies between the PDG in the HPLMN (Home Public Land Mobile Network) and the 3GPP
AAA Server for mobility-related authentication. This interface transports the commands to retrieve and store the
mobility parameters.
Interface S6d
The interface S6d lies between the HSS and the SGSN (Serving GPRS Support Node) used to retrieve and store
mobility-related parameters. This interface shares the same properties as those of S6a.
Interface S9
The reference point S9 lies between the H-PCRF (Home Network-Policy Charging and Rules Function) and the V-
PCRF (Visited Network-Policy Charging and Rules Function) in the EPS network. This interface has the following
properties that enable the H-PCRF:
Dynamic PCC control, including both PCEF and, if applicable, BBERF (Bearer Binding and Event Reporting
Function) in the VPLMN.
Transport of IP-CAN-specific parameters from both the PCEF and, if applicable, the BBERF in the VPLMN.
Serves Rx authorizations and event subscriptions from the AF in the VPLMN.

211
Interface S13
The reference point S13 lies between the MME and the EIR (Equipment Identity Register). This interface enables
the ME Identity check procedure between the MME and the EIR.
Interface S13
The reference point S13 lies between the SGSN and the EIR and has the similar property as that of S13.
Interface Gx
The reference point Gx lies between the PCRF (Policy Charging and Rules Function) and the PCEF (Policy Control
Enforcement Function) in the EPS network and enables the PCRF to have dynamic control over PCC behavior at
the PCEF. This interface has the following properties:
Enables the signaling of PCC decisions.
Negotiation of IP-CAN bearer establishment mode.
Termination of Gx session.
Interface Gy
The online charging reference point Gy lies between the PCEF and the OCS (Online Charging Function). This
reference point Gy provides the same functionalities as those of reference point Ro.
Interface Gz
The offline charging reference point Gz lies between the PCEF and the CGF. This reference point Gz provides the
same functionalities as those of Rf in the EPS.
Interface Gi
The reference point Gi lies between the Packet Domain and the external PDN (Packet Data Network). As an
example, Gi lies between the GGSN and external IP networks. This reference point Gi provides the following
functionalities:
Transfer of authentication and authorization information during Access Point Name (APN) provisioning.
Transfer of accounting information during APN provisioning.
Interface SGi
The reference point SGi lies between the EPC-based PLMN and external PDN. As an example, SGi lies between
the PGW and external IP networks. This reference point SGi provides similar functionality to that of the Gi interface.
Interface Sp
The reference point Sp lies between the SPR (Subscription Profile Registry) and the PCRF (Policy Control and
Charging Rules Function). This reference point provides following functionalities and is not limited to:
Transfer of subscriber information related to IP-CAN based on subscriber Id.
Unsolicited notifications about subscriber information change
Interface Rx
The reference point Rx lies between the AF and PCRF. This reference point provides the transport of application-
level session information and is not limited to:
IP filter information that identifies service data flow for the policy control.
QoS control of media/application bandwidth.
Notifications on IP-CAN bearer level events.
Interface Rx+
The reference point Rx+ is the Rx reference point for the EPC. This reference point lies between the PCRF and IP
services or proxies to network services. This reference point provides the transport of application-level session
information similar to Rx.
Interface Wm
The intra-operator reference point Wm lies between the PDG and a 3GPP AAA Proxy/Server. This interface has the
following properties:
Applies for WLAN 3GPP IP access.
Transport of tunneling attributes and WLAN UEs IP configuration parameters.
Transport of charging data for 3GPP PS-based service charging.
Transport of user authentication and authorization data.

212
213
The Update Location Procedure shall be used between the MME and the HSS and between the SGSN and the HSS
to update location information in the HSS. The procedure shall be invoked by the MME or SGSN and is used:
- to inform the HSS about the identity of the MME or SGSN currently serving the user, and optionally in addition;
- to update MME or SGSN with user subscription data;
- to provide the HSS with other user data, such as Terminal Information.
The Cancel Location Procedure shall be used between the HSS and the MME and between the HSS and the SGSN
to delete a subscriber record from the MME or SGSN. The procedure shall be invoked by the HSS and is used:
- to inform the MME or SGSN about the subscribers subscription withdrawal or
- to inform the MME or SGSN about an ongoing update procedure i.e. MME or SGSN change.
- to inform the MME or SGSN about an initial attach procedure.
The Purge UE Procedure shall be used between the MME and the HSS and between the SGSN and the HSS to
indicate that the subscribers profile has been deleted from the MME or SGSN either by an MMI interaction or
automatically, e.g. because the UE has been inactive for several days.
The Insert Subscriber Data Procedure shall be used between the HSS and the MME and between the HSS and the
SGSN for updating certain user data in the MME or SGSN in the following situations:
- due to administrative changes of the user data in the HSS and the user is now located in an MME or SGSN, i.e. if
the user was given a subscription and the subscription has changed;
- the operator has applied, changed or removed Operator Determined Barring for this user;
- activate subscriber tracing in the MME or the SGSN;
- to indicate to the MME that the HSS has requested to be notified when the UE has become reachable.
The Delete Subscriber Data procedure shall be used between the MME and the HSS and between the SGSN and
the HSS, to remove some or all data of the HSS user profile stored in the MME or SGSN. The procedure shall be
invoked by the HSS and it corresponds to the functional level operation Delete Subscriber
It shall be used to remove:
- all or a subset of the EPS subscription data (APN Configuration Profile) for the subscriber from the MME or SGSN;
- the regional subscription;
- the subscribed charging characteristics;
- Session Transfer Number for SRVCC;
- trace data.
The Authentication Information Retrieval Procedure shall be used by the MME and by the SGSN to request
Authentication Information from the HSS.
The Reset Procedure shall be used by the HSS, after a restart, to indicate to the MME and to the SGSN that a
failure has occurred.
The Notification Procedure shall be used between the MME and the HSS and between the SGSN and the HSS
when an inter MME or SGSN location update does not occur but the HSS needs to be notified about
- an update of terminal information;
- - an assignment/change/removal of PDN GW for an APN;
- - the need to send a Cancel Location to the current SGSN.
- - the UE is present or the UE has memory capacity available to receive one or more short messages.
- - the UE has become reachable again.

214
Elementos de Informacin

215
Elementos de Informacin

216
En pos de la simplicidad de configuracin y escalabilidad, para el transporte de la sealizacin Diameter se
utiliza el modelo cuasi asociado. Un Agente (Similar a un STP en una red SS7) conecta a todos los nodos
Diameter (MME, HSS, PCEF, PCRF, OCS, OFCS, entidades IMS, etc.) y enruta los pedidos y respuestas de
Diameter entre ellos. Todos los nodos Diameter tienen solo una entrada en su table de rutas pare entregar
cualquier mensaje Diameter al Agente. El Agente Diameter puede enrutar entre nodos de la misma red y
tambin entre nodos de diferentes redes. Para asegurar una disponibilidad del 100%, los agentes se
implementan en pares acoplados. Cada nodo cliente o servidor Diamenter se conecta a los dos agentes de
un par acoplado.
Los agentes ofrecen una cantidad de ventajas a la arquitectura EPS:
Escalabilidad: Considerando N entidades que requieren interactuar con M entidades, la cantidad de
conexiones TCP o SCTP entre ellas sera de NxM si no se introduce un agente Diameter. En caso de
tener un agente la cantidad baja a N+M. Se debe usar el modo cuasi asociado para garantizar la
escalabilidad de la arquitectura de sealizacin Diameter.
Simplificacin de las ampliaciones: En caso que no se utilice un Agente, el agregado de un nuevo
servidor o cliente en el EPS deriva en la necesidad de actualizar las tablas de rutas de todas las entidades
que requieren comunicarse con la nueva entidad, mientas que con la presencia de un agente, slo se
debern actualizar las tablas de enrutamiento del agente.
Interconexin de redes con ocultamiento de topologa: El agente permite simplificar la interconexin
con otras redes para soporte de acuerdos de itinerancia, al mismo tiempo que oculta la topologa interna
de la red a otros operadores.
Enrutamiento a nivel de aplicacin: El agente permite realizar enrutamiento basado en aplicacin como
ser balance de carga en el contexto de PCC (Control de tasacin y polticas), identificacin del HSS para
la interaccin entre el MME y HSS, etc.
Conversin de protocolos AAA: Si se implementa dentro del Agente de enrutamiento un agente de
traslacin, podr ayudar en la migracin a Diameter, soportando la interconexin con otros dominios que
aplican diferentes protocolos AAA, como ser MAP, CAP, Radius, etc.

217
Una funcionalidad importante de las redes de comunicaciones mviles es el soporte del servicio de itinerancia
(roaming). Este servicio permite que los usuarios puedan acceder a sus servicios de telecomunicacin a travs de
las redes de otros operadores con los que no tienen establecida ninguna relacin contractual (subscripcin). A
efectos de nomenclatura, el operador con el que el usuario tiene establecida la relacin contractual para la
prestacin de servicios se conoce como operador matriz, y por extensin, la red de dicho operador constituye la
red matriz (Home Network). La red de otro operador a la que el usuario puede tener acceso se denomina red
visitada (Visited Network).
El sistema LTE especifica tres posibles configuraciones para la implementacin de un servicio de itinerancia. Las
diferentes configuraciones dependen de qu pasarela P-GW se utiliza para encaminar el trfico con la red externa
y de la capacidad de proporcionar acceso a los servicios propios del operador matriz. Las tres configuraciones
son:
I. Encaminamiento de trfico a travs de la red matriz, con acceso a los servicios de la red matriz.
II. Encaminamiento de trfico a travs de la red visitada, con acceso a los servicios de la red visitada.
III. Encaminamiento de trfico a travs de la red visitada, con acceso a los servicios de la red matriz.
En el primer caso, el nodo MME en la red visitada responsable de la terminacin del plano de control con el
terminal (protocolos NAS) accede a la base de datos HSS de la red matriz (a travs de la interfaz S6a) para poder
obtener la informacin necesaria del usuario en itinerancia. De esta forma, el usuario en itinerancia puede
autenticarse en la red visitada a partir de las credenciales que le han sido otorgadas por su operador matriz. Por
otro lado, el establecimiento de los servicios de conectividad se realiza mediante la utilizacin de pasarelas P-GW
del operador matriz. Para ello, se establece un tnel (a travs de la interfaz S8) entre la pasarela S-GW que acta
de punto de anclaje en la red visitada y la pasarela P-GW que proporciona la interconexin con la red externa en
la red matriz. Esta configuracin permite que el usuario acceda a todos sus servicios como si estuviera conectado
a travs de la red de acceso de su operador matriz. Este modo de operacin es similar al desarrollado para GPRS
en redes 3Gpp (utilizando las redes GRX para derivar el trfico a la red matriz).

218
Esta configuracin permite que el trfico generado por los usuarios en itinerancia se curse de forma local
en las redes visitadas. As, el acceso a las redes externas y/o plataformas de servicio se realiza
mediante pasarelas P-GW pertenecientes a la red visitada. En cualquier caso, ntese como, al igual que
en la opcin (I), el nodo MME de la red visitada accede directamente a la base de datos HSS de la red
matriz para obtener la informacin relativa al usuario en itinerancia.
Asimismo, el control de las reglas de uso de la red y de tarificacin, atendiendo a que cada operador
puede establecer sus propias estrategias comerciales, puede realizarse en base al acceso al sistema
PCC de la red matriz. De esta forma, las reglas de uso (e.g., parmetros de QoS) que se aplicaran en la
red visitada vendrn determinadas por el operador matriz. Las reglas de uso pueden transferirse desde
la red matriz de un usuario a la red visitada donde est recibiendo servicio a travs de la interfaz S9
diseada a tal efecto.

219
Esta configuracin resulta til en el caso de que se pretenda que el usuario en itinerancia tenga acceso a
las plataformas de servicio de su operador (el control de los servicios se realiza a travs del operador
matriz) pero quiera evitarse el encaminamiento de todo el trfico a travs de la red matriz. De esta forma,
el trfico de usuario que no necesariamente tenga que atravesar la plataforma de servicios puede
acceder a las redes externas (e.g., Internet) sin necesidad de que tenga que ser transferido desde la red
visitada a la red matriz.

220
La gestin de sesiones se refiere a la gestin del servicio de conectividad IP que ofrece una red LTE.
Este servicio de conectividad IP se articula en base a los conceptos de conexin PDN y servicio portador
EPS. El servicio de conectividad IP de una red LTE es capaz de ofrecer diferentes niveles de calidad de
servicio (QoS) y puede ser gestionado mediante mecanismos de control de las polticas de uso de la red
(i.e., policy control) que permiten la interaccin del servicio de conectividad proporcionado por LTE con
las plataformas que sustentan los servicios finales (e.g., IMS).
La gestin de movilidad se refiere a los mecanismos con los que cuenta el sistema LTE para que los
usuarios puedan acceder y recibir servicios desde cualquier ubicacin geogrfica donde el sistema
disponga de cobertura. Asimismo, la gestin de movilidad tambin abarca los mecanismos utilizados en
el sistema LTE para poder mantener las conexiones de sus usuarios activas aun cuando stos puedan
cambiar de estacin base debido a su movilidad (i.e., mecanismos de handover).
La gestin de seguridad concierne a cmo la red LTE autentica y autoriza el uso de sus servicios a los
usuarios as como cules son los mecanismos utilizados para proporcionar confidencialidad e integridad
de la informacin enviada tanto en la interfaz radio como en otras interfaces entre equipos de red.

221
 Servicio de conectividad LTE: La conexin PDN

El sistema LTE proporciona a los usuarios un servicio de conectividad IP a una o mltiples redes de
paquetes externas. El servicio de conectividad IP permite que un terminal LTE pueda intercambiar
informacin (i.e., paquetes IP) con otros equipos de la red IP externa remota como si el terminal LTE se
encontrara conectado fsicamente a dicha red (i.e., el terminal es visible en la red remota externa mediante
una direccin IP propia que le ha sido asignada a travs del sistema LTE). El servicio de conectividad IP
proporcionado por LTE entre el equipo de usuario y una red externa IP se denomina conexin PDN. Las
redes de paquetes externas a las que puede accederse a travs de la red LTE pueden ser redes pblicas
como Internet o bien redes privadas como una intranet corporativa, la red de un proveedor de acceso a
Internet (ISP) o bien una red interna del propio operador de la red LTE para la provisin, por ejemplo, de
servicios IMS. En las especificaciones del 3GPP, las posibles redes externas de paquetes accesibles desde
LTE se denominan, sin distincin alguna, como Packet Data Networks (PDNs), y por este motivo se habla
de conexin PDN en lugar de simplemente conexin IP. La denominacin de PDN es herencia de GPRS
donde se acu este trmino. En GPRS, el servicio de conectividad ofrecido contempla la transferencia de
otros tipos de paquetes adems de IP como, por ejemplo, paquetes PPP (Point-to-Point Protocol) o
paquetes X.25. Por ello, en GPRS se habla de forma genrica de conexiones PDN, en lugar de conexiones
IP, si bien es cierto que el servicio de conectividad IP es el caso predominante en los despliegues actuales
de este tipo de redes. A diferencia de GPRS, el sistema LTE nicamente proporciona conexiones a redes
IP (LTE no soporta la transmisin de otro tipos de paquetes). No obstante, en las especificaciones del
sistema LTE sigue utilizndose el trmino conexin PDN utilizado en GPRS para referirse al servicio de
conectividad IP ofrecido por la red. Una conexin PDN en el sistema LTE se caracteriza siempre por una
direccin IP nica a travs de la cual el equipo de usuario opera en la red externa. La direccin IP de una
conexin PDN puede ser IPv4, IPv6 o ambas (una conexin puede estar asociada simultneamente a una
direccin IPv4 y a una IPv6).
Las redes externas a las que una red LTE puede proporcionar acceso se identifican mediante una etiqueta
denominada Access Point Name (APN). El APN se compone de un identificador del operador de la red LTE
(un cdigo de operador y de pas) y un identificador especfico de la red externa a la que se proporciona
acceso (e.g., servicios-ims, internet, red-corporativa-1, etc.). De esta forma, cuando se establece una
conexin PDN entre un equipo de usuario y una red externa, la red LTE utiliza el parmetro APN para
determinar la pasarela P-GW o pasarelas P-GW de la red LTE que van a participar en la provisin de dicha
conexin PDN.
Un equipo de usuario puede establecer mltiples conexiones PDN simultneas, a travs de la misma o
varias pasarelas P-GW de la red LTE. El conjunto de redes externas a las qu tiene acceso un determinado
usuario LTE se controla a travs de su subscripcin, donde se indica el conjunto de identificadores APNs
autorizados. En LTE, a partir del momento en que un usuario se registra en la red LTE, se establece, como
mnimo, una conexin PDN. La red externa a la que proporciona acceso la conexin PDN inicial la puede
decidir el propio usuario mediante el envo del correspondiente APN o bien puede utilizarse un valor de APN
por defecto que la red LTE guarde en el perfil de subscripcin de dicho usuario. Las conexiones PDN
adicionales, si cabe, las inicia el equipo de usuario una vez ya est registrado y dispone de una conexin
PDN inicial (el registro y el establecimiento de la primera conexin se realiza de forma combinada mediante
el procedimiento denominado Network Attach). La desconexin de una conexin PDN puede iniciarla tanto
la propia red LTE (debido, por ejemplo, a un cambio en la subscripcin o a una falta de recursos) como el
propio usuario.

222
223
Se representa un equipo de usuario que tiene establecidas tres conexiones PDN con sendas redes externas.
Cada conexin PDN se caracteriza por un identificador APN (que indica a qu red externa se proporciona acceso,
y por extensin, desde qu pasarela P-GW) y la direccin IP utilizada por el terminal LTE en dicha red externa.
Ntese, por tanto, que un terminal LTE puede tener asignadas mltiples direcciones IP, una para cada conexin
PDN establecida. Mediante la conexin PDN A, el usuario tiene acceso a servicios proporcionados en una
plataforma IMS. Por otro lado, la conexin PDN B proporciona al usuario acceso a Internet. En este ejemplo, el
acceso a Internet como red externa se indica mediante el identificador APN B y puede realizarse tanto a travs de
la pasarela P-GW#1 como de P-GW#2. Cuando existen mltiples pasarelas P-GW que proporcionan acceso a
una misma red externa, la eleccin de la pasarela ms apropiada la determinara la red LTE en base a diferentes
aspectos tales como balanceo de cargas, espacio de direcciones utilizado en cada pasarela, diferenciacin del
servicio de acceso a Internet, etc. Finalmente, el equipo de usuario mantiene una tercera conexin PDN a una red
privada que se identifica mediante el APN C y cuyo acceso se logra a travs de la pasarela P-GW#2. En caso de
que hubiera mltiples conexiones PDN asociadas al mismo APN, estas deberan ser proporcionadas por la misma
pasarela. El soporte de mltiples conexiones PDN desde el mismo equipo de usuario es opcional en el sistema
LTE. En la figura, tambin puede verse como cada conexin PDN est compuesta por un conjunto de servicios
portadores EPS (EPS bearer services).
Tal como se observa en la figura, el servicio portador EPS se extiende desde el terminal hasta la pasarela P-GW
de la red LTE proporcionando QoS end-to-edge. QoS end-to-edge hace referencia a la provisin de un
comportamiento de QoS entre el equipo de usuario desde donde se accede a los servicios (end) y el punto de
interconexin de LTE con la red externa (edge). Ntese la diferencia con un modelo QoS end-to-end, donde el
comportamiento de QoS debe estar determinado entre los dos extremos de un servicio (e.g., entre el equipo de
usuario y un servidor de videostreaming ubicado en una red externa a LTE). El sistema LTE no especifica un
modelo de QoS end-to-end que cubra la transmisin en la red externa.

224
Servicio portador EPS
El servicio de conectividad IP proporcionado por el sistema LTE es un servicio que soporta calidad de
servicio (Quality of Service, QoS). As, el trato que reciben los paquetes IP de una determinada conexin
PDN en trminos de, por ejemplo, tasa de transferencia en bits/s, retardo de transmisin y tasa de prdidas
de paquetes, puede adaptarse a las necesidades de transmisin de los servicios finales a los que accede el
usuario. En este contexto, es importante tener en cuenta que a travs del sistema LTE pueden
proporcionarse servicios finales de muy diferente ndole que no requieren las mismas prestaciones del
servicio de transmisin (e.g., transmisin de audio y video en tiempo real, servicios de mensajera, etc.). Por
tanto, la adaptacin de las prestaciones de QoS de las conexiones PDN a las caractersticas de los servicios
finales permite al sistema LTE proporcionar una buena experiencia de uso a los usuarios a la vez que
posibilita una gestin eficiente de los recursos (i.e., no se reservan ms recursos de transmisin de los
estrictamente necesarios para satisfacer los objetivos de calidad de servicio).
Ntese que la configuracin del comportamiento de QoS, aparte de ser dependiente del servicio final al que
accede un usuario, tambin puede permitir al operador de la red LTE llevar a cabo unas determinadas
estrategias de negocio en base a la diferenciacin de usuarios (e.g., mediante una subscripcin gold un
usuario puede recibir una tasa de transferencia superior en el acceso a Internet).
La forma de gestionar la calidad de servicio en el sistema LTE se estructura en torno a la definicin de lo que
se denomina servicio portador EPS (EPS Bearer Service). Un servicio portador EPS es un servicio de
transferencia de paquetes IP que tiene asociados unos parmetros de QoS y la plantilla o filtro de paquetes
(denominado como Traffic Flow Template, TFT) utilizada para seleccionar el flujo de paquetes IP que debe
recibir dicho trato de QoS.
En este sentido, el servicio portador EPS constituye la unidad mnima de resolucin para la provisin de QoS:
todos los paquetes IP que fluyen en la red asociados a un mismo servicio portador EPS reciben el mismo
trato de QoS.
La transmisin de paquetes IP en las conexiones PDN se articula en base al establecimiento de, como
mnimo, un servicio portador EPS. As, en cada conexin PDN siempre existe un servicio portador EPS por
defecto activo por el que se enviara
todo el trfico IP de usuario sin distincin alguna (e.g., sealizacin SIP y datos de las diferentes aplicaciones
en curso). Opcionalmente, en aras a poder proporcionar un trato de QoS especfico a un determinado flujo de
paquetes IP (e.g., paquetes IP correspondientes a una aplicacin de videoconferencia) pueden activarse
servicios portadores EPS adicionales al portador por defecto, denominados como servicios portadores EPS
dedicados. De esta forma, si en una conexin PDN existen servicios portadores EPS dedicados activos, el
trfico seleccionado (mediante el TFT) se enva a travs de ellos y el resto se cursa a travs del portador
EPS por defecto.
Los parmetros de QoS del servicio portador por defecto vienen fijados por la subscripcin del usuario y,
como tal, se encuentran en la informacin almacenada en la base de datos HSS del sistema LTE. En caso de
que el usuario acceda a servicios IMS a travs del servicio portador por defecto de una conexin PDN, los
valores de QoS utilizados deben ser adecuados para la transferencia de sealizacin SIP entre el equipo de
usuario y los servidores de control de la plataforma IMS. El servicio portador por defecto permanece activado
durante la vigencia de la conexin PDN y su desactivacin conduce a la terminacin de la conexin PDN. En
cambio, si se hace uso de servicios portadores EPS dedicados, stos pueden activarse, modificarse o
desactivarse al inicio o bien en el transcurso de una conexin PDN. La existencia de un servicio portador
EPS dedicado suele estar vinculada a la existencia de un servicio final que requiere un trato especfico de
QoS (e.g., el establecimiento de un servicio videoconferencia puede conllevar la activacin de un servicio
portador EPS dedicado con valores de QoS adecuados para la transmisin de los paquetes de voz durante el
tiempo que dure el servicio). Es importante destacar que todos los servicios portadores EPS de una misma
conexin PDN comparten los mismos parmetros de conectividad IP (i.e., misma direccin IP). Tal como
puede observarse en el ejemplo, en las tres conexiones PDN existe un servicio portador EPS por defecto y,
en este ejemplo, nicamente en la conexin PDN A, hay activado un servicio portador EPS dedicado. Por
tanto, en las conexiones PDN B y C, todo el trfico recibe el mismo trato de QoS (el del servicio portador por
defecto) mientras que en la conexin PDN A se aplican dos tratos de QoS diferentes (e.g., uno al servicio de
videoconferencia y otro al resto de paquetes

225
Estructura de un servicio portador EPS
Los componentes en que se estructura un
servicio portador se ilustran ms
detalladamente en la figura, donde se
representa un escenario con dos servicios
portadores EPS establecidos (A y B).
La implementacin de un servicio portador
EPS requiere que, en cada nodo de la red
LTE donde se procesa el plano de usuario
(i.e., equipo de usuario, eNB, S-GW y P-
GW), se establezca un contexto de
informacin con los parmetros de QoS
pertinentes as como la informacin
necesaria (filtros, etiquetas) que permita la
identificacin del flujo de datos asociado al
servicio portador en las diferentes interfaces
de la red. As, cada servicio portador EPS
tiene asociado un

filtro de paquetes IP que se utiliza para seleccionar los paquetes que deben recibir el trato de QoS
especificado. El filtro de paquetes recibe el nombre de TFT (Traffic Flow Template) y contiene
atributos tales como: puertos de los protocolos de transporte, direcciones IP y mscaras de subred de
los nodos remotos; puertos locales de los protocolos de transporte; y campos especficos de calidad
de servicio en las cabeceras del protocolo IP (Type of Service, TOS, en IPv4 y Traffic Class y Flow
Label en IPv6). El filtro de paquetes se instala en el equipo de usuario para filtrar el trfico
ascendente y en las pasarelas de red (PGW o S-GW) para filtrar el trfico dirigido al terminal. En la
figura se ilustra la ubicacin de los filtros de paquetes en el caso de considerar una interfaz basada
en GTP entre S-GW y P-GW, donde el TFT en sentido descendente se aplica en la pasarela P-GW.
En caso de que la interfaz entre S-GW y P-GW estuviera basada en PMIPv6), los filtros TFT para el
enlace descendente se ubicaran en la pasarela S-GW dado que el protocolo PMIPv6 no soporta la
identificacin de diferentes flujos de trfico entre las pasarelas S-GW y P-GW (los tneles PMIPv6
entre pasarelas se establecen por conexin PDN, no por servicio portador EPS).
Una vez identificados los paquetes IP asociados a un servicio portador mediante los TFTs, stos se
transportan a travs de la red de forma que resulta posible identificar el servicio portador EPS al que
pertenece cada uno de los paquetes IP enviados en todos los equipos de red que sustentan el plano
de usuario. Para ello, en la interfaz radio, los paquetes asociados a un servicio portador EPS se
transmiten mediante un servicio portador radio (Radio Bearer, RB).
Un servicio portador EPS se mapea unvocamente a un RB en la interfaz radio. En la interfaz S1
entre eNB y S-GW, el servicio portador EPS se mapea en un servicio portador S1 que bsicamente
queda especificado mediante la asignacin de un identificador de tnel (TEID) del protocolo GTP en
ambos extremos de la interfaz De forma similar, en la interfaz S5/S8 basada en GTP el mapeo del
servicio portador EPS tambin consiste en su asociacin con los identificadores de tnel que definen
el servicio portador S5/S8. Tal como se ha comentado anteriormente, si la interfaz S5/S8 se basa en
PMIPv6, la distincin entre los paquetes IP que pertenecen a diferentes servicios portadores EPS no
se lleva a cabo en esta interfaz. En este caso, el servicio portador EPS queda implementado
nicamente mediante el servicio portador radio y el servicio portador S1.
Los parmetros de QoS se establecen por servicio portador EPS y se mapean a los parmetros de
QoS que soportan los servicios portadores integrantes (RB, S1 y S5/S8). En el caso de la interfaz
radio, el cumplimiento de los parmetros de QoS se fundamenta en la configuracin apropiada de la
capa radio y de enlace (e.g., configuracin de los mecanismos de retransmisiones RLC y H-ARQ) y
en la utilizacin de mecanismos de scheduling, gestin activa de colas y control de la tasa de
transferencia (bits/s) del servicio portador radio. En el caso de las interfaces S1 y S5/S8, los
parmetros de QoS del servicio portador EPS deben relacionarse con los parmetros de QoS que
empleen las redes de transporte IP que interconectan los diferentes equipos de la infraestructura de
la red LTE (e.g., parmetros de un modelo de servicios Diffserv).

226
En LTE, el modelo de QoS utilizado para definir el comportamiento de un servicio portador EPS se basa en la
especificacin de un mximo de cuatro parmetros. Adems de estos cuatro parmetros, el modelo de QoS se
complementa con dos parmetros adicionales asociados a la subscripcin de un usuario.
Cada servicio portador EPS siempre tiene asociados como mnimo dos parmetros: QCI (QoS Class Identifier) y
ARP (Allocation and Retention Priority). De forma general, el parmetro QCI determina el comportamiento del
plano de usuario del servicio portador EPS mientras que el parmetro ARP aplica a la operativa del plano de
control. Adicionalmente, algunos servicios portadores denominados como servicios de tasa garantizada (GBR
Bearers) especifican tambin un parmetro de tasa media garantizada (GBR) y otro de tasa mxima permitida
(MBR). A continuacin se describe ms detalladamente el significado de dichos parmetros.
El QCI es un parmetro que representa una determinada clase de servicio o comportamiento de la red. El valor
del QCI no indica de forma directa ninguna magnitud relacionada con las prestaciones de la red sino que
simplemente se concibe como un puntero a una determinada clase de servicio5. De esta forma, la seleccin de un
valor de QCI para un servicio portador EPS implica la utilizacin de una serie de parmetros especficos en cada
uno de los nodos que procesan el plano de usuario (e.g., pesos del scheduling, umbrales del control de admisin,
configuracin de los parmetros de capa de enlace y capa fsica, etc.). Dichos parmetros podran haber sido pre-
configurados en el equipo por el fabricante en cuestin o bien por el propio operador de la red. Dada la gran
flexibilidad que ofrece este esquema, 3GPP ha especificado el comportamiento esperable para un conjunto de
QCIs de forma que pueda utilizarse como gua en la configuracin de los mecanismos que afectan a la QoS en
cada nodo. La finalidad ltima en la estandarizacin de un conjunto de QCIs es la de facilitar la consecucin de un
determinado comportamiento en redes con equipos de diferentes fabricantes as como en escenarios de
itinerancia. Los QCIs estandarizados se proporcionan en trminos de tipo de servicio portador, retardo, tasa de
prdida de paquetes en situaciones de no congestin y un nivel de prioridad.

227
Los valores de QCI estandarizados son aplicables cualquiera que sea la red de acceso.
El parmetro ARP se utiliza como un indicador de prioridad en los procesos de establecimiento/ modificacin/desactivacin de
un servicio portador. El sistema LTE soporta un total de 15 prioridades. El valor de prioridad puede utilizarse, por ejemplo, en
la funcin de control de admisin cuando no haya suficientes recursos disponibles para dar respuesta a varias activaciones.
Asimismo, el valor de ARP tambin puede utilizarse para desactivar determinados servicios portadores en aras a liberar
recursos que deban ser destinados a servicios portadores ms prioritarios (pre-emption). Esta prctica puede formar parte de
un mecanismo de control de congestin.
Para los servicios portadores EPS de tasa garantizada, el parmetro GBR indica justamente la tasa en bits/s que debe
proporcionar el servicio portador. Por otro lado, el parmetro MBR acota su tasa mxima de forma que, a travs de un
mecanismo de control de tasa (rate control), el volumen de trfico que excede el valor de MBR puede ser descartado.
Actualmente, la versin inicial del sistema LTE solamente proporciona soporte para configuraciones donde los valores de
GBR y MBR coincidan (las funciones de control de tasa nicamente se han definido para acotar tasas de pico).
Por definicin, un servicio portador de tasa garantizada que curse una tasa de datos inferior o igual al valor del parmetro
GBR que tenga asociado no tiene que experimentar prdidas de paquetes por congestin. Por ello, una caracterstica
importante de los servicios de tasa garantizada es que deben someterse siempre a control de admisin, ya que su activacin
conlleva la reserva de un determinado volumen de recursos de transmisin en aras a poder garantizar dicha tasa. Por el
contrario, en el caso de los servicios portadores sin tasa garantizada, no resulta estrictamente necesario pasar un control de
admisin. Por tanto, a diferencia de un servicio de tasa garantizada, un servicio sin tasa garantizada puede experimentar
prdida de paquetes en situaciones de congestin.
Adems de los parmetros de QoS asignados a cada servicio portador EPS, un usuario del sistema LTE tiene asociados dos
parmetros adicionales: UE-AMBR y APN-AMBR. Ambos parmetros indican la mxima tasa de transferencia en bits/s que de
forma agregada podrn experimentar el conjunto de servicios portadores EPS sin tasa garantizada que tenga activados un
usuario. En particular, el parmetro UE-AMBR acota la tasa mxima del equipo de usuario y el parmetro APN-AMBR la tasa
agregada mxima del equipo de usuario con una determinada red externa (asociada a dicho APN). Estos dos parmetros
forman parte del perfil de subscripcin del usuario de forma que, a travs de ellos, el operador de la red puede plantear
diferentes estrategias de negocio basadas en la tasa mxima de transferencia ofrecida a los usuarios.

228
Gestin de la Seguridad
Los mecanismos para garantizar la seguridad de la informacin tienen un papel muy relevante en los
sistemas de comunicaciones mviles. En particular, la utilizacin en estos sistemas de un canal
abierto entre los equipos de usuario y la infraestructura como es el canal radio, constituye uno de
los aspectos fundamentales que condicionan el desarrollo de la arquitectura y mecanismos de
seguridad. Adems de fuertes condicionantes derivados del uso de una interfaz radio, la gestin de
seguridad tambin debe ocuparse de que las comunicaciones entre los diferentes equipos que
conforman la infraestructura del sistema se realice con las garantas de seguridad necesarias. As
por ejemplo, si en un emplazamiento de una estacin base LTE se utilizan radioenlaces de
microondas para sustentar las interfaces S1 y X2 que conectan la base con el resto de la
infraestructura, la informacin transportada a travs de estas interfaces contiene informacin crtica
tal como identidades de usuario, claves de seguridad, etc., que tambin debe estar debidamente
protegida.
Marco general de seguridad
Los mecanismos de seguridad que incorporan las redes de comunicaciones proporcionan diferentes
servicios de seguridad. De forma general, existen cinco tipos de categoras en los que pueden
clasificarse los servicios de seguridad en los sistemas de comunicaciones :
Autenticacin. Un servicio de autenticacin debe garantizar que la entidad con la que establece
la relacin es quien dice ser. Este servicio es clave en redes mviles para contrastar la identidad
de los usuarios que se conectan al sistema, as como para que estos usuarios tengan la certeza
que estn accediendo a la red correcta (autenticacin mutua entre usuarios y red).
Control de Acceso. Este servicio de seguridad se ocupa de la prevencin de cualquier acceso
no autorizado a los recursos. As, en el contexto de las redes de comunicaciones mviles, es muy
importante condicionar la activacin de los servicios de comunicacin a los derechos de acceso
que tenga el usuario en virtud de su tipo de subscripcin al sistema.
Confidencialidad. Este servicio se ocupa de ofrecer la proteccin de los datos que transporta el
sistema frente a observadores no autorizados. El servicio de confidencialidad es uno de los
componentes bsicos de la interfaz radio en aras a evitar que un receptor cualquiera pueda
entender la informacin transmitida por un usuario determinado. La confidencialidad puede
aplicarse tanto a la informacin propia de los servicios que estn utilizando los usuarios (e.g.,
confidencialidad de los datos contenidos en los paquetes IP) as como a la sealizacin propia
relacionada con la operativa del sistema (e.g., sealizacin de control RRC en la interfaz radio).
Los servicios de confidencialidad tambin pueden abarcar la proteccin de la informacin que
puede derivarse de la observacin de flujos de trfico (es decir, aunque no se pueda entender lo
que transmite un usuario, el hecho de conocer cundo transmite y dnde tambin puede ser
objeto de proteccin). Este ltimo caso de confidencialidad, en sistemas LTE suele denominarse
como privacidad y, tal como se ver, se basa en limitar al mximo la transmisin de
identificadores universales de los usuarios (i.e., IMSI) en la interfaz radio.
Integridad. Mediante este tipo de servicio de seguridad se garantiza que los datos recibidos por
una entidad no han sufrido alteracin alguna desde su emisin. El servicio de integridad es muy
importante para evitar ataques al sistema que consistan en alterar la informacin que circula por
l y causar comportamientos no deseados.
No repudio. Este servicio pretende dejar constancia de la participacin de una entidad en un
proceso o transferencia de informacin. Mediante este servicio, el recipiente de la informacin
dispone de pruebas que le permiten identificar el origen de los datos (frente a una posible
negacin del emisor de los datos como origen de los mismos). El emisor de los datos puede
tambin disponer de pruebas para constatar que sus datos han sido recibidos por un
destinatario (ante una posible negacin del recipiente acerca de la recepcin de la informacin).
Los servicios de no repudio se basan principalmente en el uso de mecanismos de firma
electrnica.

229
Dominios de seguridad

El diseo de los diferentes mecanismos de seguridad que incorpora el sistema LTE se ha realizado en base
a la definicin de una arquitectura completa de seguridad que integra todos los posibles componentes y
agentes en la provisin segura de los servicios de telecomunicacin. La arquitectura de seguridad se
estructura en dominios de seguridad.
Cada dominio de seguridad agrupa las diferentes funciones de seguridad que tienen en comn un
determinado tipo de vulnerabilidades y unos objetivos de seguridad especficos. Los cinco dominios de
seguridad identificados en dicha arquitectura son:
1. Seguridad de acceso a la red. Este grupo de funciones tiene como objetivo proporcionar a los usuarios
un acceso seguro a la red LTE. En particular, la seguridad de acceso a la red alberga funciones de
autenticacin mutua usuario-red, confidencialidad (incluyendo privacidad) e integridad. Los mecanismos
de seguridad necesarios para proporcionar estos servicios son especficos de la red de acceso (E-
UTRAN, UTRAN o GERAN).
2. Seguridad en el dominio de red. Funciones de seguridad relacionadas con el soporte de servicios de
seguridad entre los equipos que componen la infraestructura de red. Es decir, los intercambios de
informacin entre los equipos de la red de un operador mvil (e.g., interfaces entre eNBs y equipos de
la red troncal) as como entre equipos de diferentes operadores (e.g., acceso a la base de datos HSS
de un operador matriz para la provisin de un servicio de roaming) deben estar adecuadamente
protegidos.
3. Seguridad del equipo de usuario. Este dominio de seguridad abarca aquellas funciones destinadas a
establecer un marco de operacin seguro entre el terminal LTE, la tarjeta SIM/USIM y el propio usuario
del sistema. Un ejemplo claro de estas funciones lo encontramos en la utilizacin de un nmero secreto
(PIN) para poder operar una tarjeta SIM/USIM en un terminal. El uso de un PIN es la forma ms
extendida actualmente de vincular al usuario con su mdulo de identificacin en la red (tarjeta
SIM/USIM).
4. Seguridad en nivel de aplicacin y servicios. Este dominio albergara las funciones de seguridad
utilizadas por las diferentes aplicaciones a las que tiene acceso el usuario a travs de la red LTE. Estas
funciones aplicaran directamente entre el equipo de usuario y los servidores de las plataformas de
servicios o entidades remotas con las que se intercambiara la informacin. A modo de ejemplo, el
servicio de confidencialidad (cifrado) de la sealizacin SIP que soporta el subsistema IMS formara
parte de este dominio. Tambin, la utilizacin de protocolos de transporte seguros para el intercambio
de informacin (e.g., Transport Layer Security, SSL) formaran parte de este grupo de funciones. Ntese
que, de hecho, este nivel de seguridad es transparente a la red LTE ya que, tal como se ha visto, sta
se ocupa de ofrecer un servicio de conectividad IP y no limita el tipo de proteccin que pueda hacerse a
niveles superiores (protocolos de transporte y sealizacin de aplicacin).
5. Visibilidad y configuracin de la seguridad. Aqu se incluyen el conjunto de funciones destinadas a
proporcionar al usuario una visin clara de los servicios de seguridad que estn operativos en la red. Un
ejemplo claro sera la implementacin de un indicador grfico en el equipo de usuario (e.g., un candado
cerrado) que informara al usuario que su informacin se est transfiriendo mediante el uso del servicio
de confidencialidad (cifrado) radio que tiene E-UTRAN.

230
La seguridad de acceso a la red LTE a travs de una red de acceso E-UTRAN se compone de los
siguientes elementos:
Mecanismos para la autenticacin mutua entre el usuario y la red. El procedimiento a travs del cual
se realiza la autenticacin mutua, junto con la gestin de claves, se denomina EPS Authentication and
Key Agreement (AKA).
Mecanismos para la determinacin de las claves secretas utilizadas en los algoritmos de cifrado para la
provisin de los diferentes servicios de confidencialidad e integridad.
Servicios de confidencialidad e integridad para la transferencia de la sealizacin NAS entre el equipo
de usuario y la entidad MME de la red troncal EPC.
Servicios de confidencialidad e integridad para la transferencia de la sealizacin del protocolo RRC
entre el equipo de usuario y el eNB (el cifrado se realiza en la capa PDCP de la torre de protocolos
radio).
Servicios de confidencialidad para la transferencia de informacin en el plano de usuario entre el
equipo de usuario y el eNB (el cifrado se realiza en la capa PDCP de la torre de protocolos radio).
Ntese que la informacin del usuario no dispone de un servicio de integridad ya que, en caso de ser
necesario, se considera un aspecto dependiente del servicio final en cuestin.

231
La gestin de movilidad es una de las piezas clave que caracteriza a los sistemas de comunicaciones
mviles. Un requisito bsico que deben satisfacer estos sistemas es permitir que los usuarios puedan
acceder y recibir sus servicios desde cualquier ubicacin geogrfica donde el sistema disponga de
cobertura, dejando aparte posibles limitaciones operativas o restricciones derivadas de las propias
condiciones de uso de los servicios.
Por un lado, este requisito implica que el sistema de comunicaciones mviles tiene que albergar
mecanismos que le permitan avisar a los usuarios de la activacin de servicios originados desde la red
dondequiera que se encuentren. Dada la gran extensin geogrfica que puede abarcar una red celular,
el envo de avisos (funcin de paging) a los terminales debe hacerse de forma selectiva a travs
nicamente de aquellas estaciones base donde exista una cierta probabilidad de encontrar al usuario.
Para ello, el sistema debe hacer un seguimiento que le permita acotar la localizacin de los usuarios
dentro de la zona de servicio de la red. Esta funcionalidad se conoce como gestin de la localizacin.
Por otro lado, cuando los usuarios se encuentran conectados al sistema a travs de una determinada
estacin base, se requiere que el sistema sea capaz de mantener las conexiones activas an cuando
el terminal se encuentre en movimiento y resulte necesario realizar, en el transcurso de una conexin
activa, un cambio de la estacin base que le proporciona el acceso a la red. Esta funcionalidad se
conoce como traspaso o handover. Por tanto, la gestin de movilidad en un sistema de
comunicaciones mviles abarca tanto la gestin de la localizacin como la gestin del handover.
Asimismo, las funciones propias de gestin de movilidad deben complementarse con funciones que
permitan la autenticacin de los usuarios y la autorizacin de acceso a los servicios solicitados desde
cualquier estacin base a travs de la que se conecte el terminal.

232
La conmutacin entre ambos estados de movilidad se realiza a travs de procedimientos de registro y
cancelacin de registro. El procedimiento de registro, conlleva el paso de un estado No registrado a
un estado Registrado y siempre es un procedimiento iniciado por el terminal. El procedimiento de
cancelacin de registro (i.e., Network Dettach) sirve para realizar el paso contrario y puede ser
iniciado tanto por el terminal (e.g., en el proceso de apagado del terminal) como por la propia red (e.g.,
cambios en la subscripcin de un usuario).
La conmutacin de un estado Registrado a No registrado tambin puede acontecer debido a otros
motivos tales como el rechazo de la red al registro de un terminal en una determinada rea de
localizacin o bien el hecho de que, pasado un cierto tiempo, no se haya recibido ninguna
actualizacin por parte del terminal (la red puede forzar a que los equipos realicen actualizaciones
peridicas de su localizacin an cuando no cambien de rea de seguimiento).

233
234
 Modelo de estados de registro para movilidad

Junto con los estados de

movilidad EMM, el sistema LTE
tambin define un modelo de
estados para indicar la
existencia o no de un plano de
control activo entre el equipo de
usuario y el nodo MME de la red
troncal donde se encuentra
registrado. Dicho modelo de
estados se denomina modelo
ECM (EPS Connection
Management) y se estructura
tambin en dos posibles
estados:

Estado Desconectado (ECM-Idle). En este estado, el terminal no tiene establecida una conexin de
sealizacin con ninguna entidad MME. La existencia de este estado responde bsicamente a la
necesidad de disponer de un modo de operacin de bajo consumo que permita conseguir un modelo de
funcionamiento Always on mediante la posibilidad de conmutar de forma rpida entre este estado y el
siguiente estado Conectado en el que el terminal podra enviar/recibir datos.
Estado Conectado (ECM-Connected). En este estado, el equipo de usuario tiene establecida una
conexin de sealizacin con una entidad MME de la EPC. Dicha conexin de sealizacin se compone
de una conexin RRC en E-UTRAN y de una conexin a travs de la interfaz S1-MME entre la red de
acceso E-UTRAN y la entidad de la red troncal MME. El envo/recepcin de datos de usuario siempre
se realiza en este estado.
La informacin relativa a los estados EMM y ECM de un usuario se almacena en el equipo de usuario y
en la red troncal EPC, en particular en el nodo MME que da servicio a dicho equipo terminal. En el caso
del terminal, los estados ECM-Idle y ECM-Connected se mapean directamente a los estados
RRC_IDLE y RRC_CONNECTED empleados por la capa RRC del plano de control entre el terminal y
E-UTRAN). En el caso del nodo MME, el estado ECM-Connected se vincula a la existencia de una
conexin de sealizacin en la interfaz S1-MME asociada al usuario entre el MME
Cuando un equipo de usuario se encuentra en estado Registrado y Desconectado, el equipo de
usuario va decodificando la informacin recibida a travs de los canales de control de las estaciones
base del sistema y ejecuta los mecanismos de seleccin/re-seleccin de celda y de seleccin de red.
En este estado, la red de acceso E-UTRAN no dispone de ninguna informacin relativa al equipo de
usuario (no hay ningn contexto activo con informacin del usuario en E-UTRAN) y el seguimiento de su
localizacin dentro de la zona de servicio del sistema se realiza desde la red troncal EPC a travs de un
procedimiento de actualizacin del rea de seguimiento (Tracking Area Update, TAU). Encontrndose
en el estado Registrado y Desconectado, el equipo de usuario debe responder a los mensajes de
aviso (paging) enviados desde un nodo MME a travs de las estaciones base que integran el rea de
seguimiento donde est registrado el equipo. La respuesta a un aviso se realiza a travs del envo de un
mensaje de peticin de servicio (Service Request), que es el mismo mensaje utilizado en el caso de que
el equipo de usuario solicite a la red el establecimiento de los servicios portadores para el envo de
datos en el canal ascendente. En particular, entre los requerimientos descritos en el informe tcnico TR
25.913 [8] elaborado por el 3GPP se indica que la latencia para pasar de un modo Desconectado a un
modo Conectado, y por tanto pasar de no tener recursos asignados en E-UTRAN a disponer del plano
de usuario establecido y preparado para enviar/recibir informacin, debe ser inferior a 100 ms.
Cuando un equipo de usuario se encuentra en estado Registrado y Conectado, el nodo MME conoce
su localizacin a nivel de cul es el eNB que le est dando servicio en E-UTRAN (i.e., el eNB con el que
tiene la conexin RRC). En esta situacin, la movilidad del equipo de usuario se controla mediante el
procedimiento de handover. Asimismo, en este estado, el equipo de usuario sigue ejecutando el
procedimiento de actualizacin del rea de seguimiento (i.e., TAU) en caso de que sea necesario.

235
El procedimiento de registro es el primer procedimiento que ejecuta un usuario del sistema LTE en aras a poder
recibir los servicios de la red. El procedimiento de registro normalmente se lleva a cabo cuando se enciende el
equipo de usuario y ste detecta la presencia de una red LTE. A diferencia de sus predecesores GSM y UMTS
donde los procedimientos de registro correspondientes (IMSI Attach y GPRS Attach) estn asociados
exclusivamente a la gestin de movilidad, en LTE dicho procedimiento tambin forma parte de la gestin de
sesiones. El motivo radica en que el procedimiento de registro en LTE conlleva el establecimiento de una
conexin PDN a travs de la activacin de un servicio portador EPS por defecto y, opcionalmente, servicios
portadores EPS dedicados adicionales. Por tanto, en LTE, una vez el terminal ya se ha registrado en la red, ya
dispone de un servicio de conectividad IP operativo (faceta popularmente conocida como always-on).
La red debe disponer de mecanismos para conocer con un determinado nivel de resolucin la localizacin de los
terminales que se encuentren registrados (estado EMM-Registered) pero que no tengan establecida una conexin
con ninguna estacin base (estado ECM-Idle). Para ello, en LTE se define el concepto de rea de Seguimiento
(Tracking Area, TA) para gestionar la informacin de localizacin. Un TA agrupa a un conjunto de eNBs de forma
que la informacin de localizacin disponible en la red troncal EPC de un determinado equipo de usuario
solamente se conoce en base a la resolucin proporcionada por tales agrupaciones. La identidad de un TA se
denomina TAI (Tracking Area Identifier) y se difunde a travs de los mensajes de informacin de sistema enviados
en los canales de broadcast de los eNBs que integran una TA. Un eNB slo puede pertenecer a una TA de una
red troncal EPC, es decir, no hay solapes entre diferentes TAs. El equipo de usuario, a partir del identificador TAI
recibido, es el encargado de comunicar a la red en qu TA se encuentra accesible mediante los mecanismos de
Network Attach y de Tracking Area Update. De esta forma, cuando la red necesita contactar con el terminal, el
mensaje de aviso (paging) se difunde a travs de todas las estaciones base que integran el TA en que se
encuentra localizado el terminal.
El mecanismo de traspaso se utiliza para gestionar la movilidad de los equipos de usuario que se encuentran en
modo activo (ECM-Connected). Conceptualmente, el traspaso es un mecanismo que permite que las conexiones
que tengan establecidas los equipos de usuario sobrevivan al cambio de estacin base que proporciona el
acceso a la red. Desde la perspectiva del servicio ofrecido al usuario, los requisitos de diseo de un mecanismo
de preparacin y ejecucin del traspaso se plantean en trminos del tiempo de interrupcin o tasa de prdida de
datos que puede aparecer durante la ejecucin del cambio.

236
La primera accin que un terminal mvil LTE debe realizar despus de activarse es buscar una celda a la que
conectarse. Con este procedimiento se pretende:
Sincronizarse en tiempo y frecuencia a nivel de capa fsica el terminal mvil con el transceptor ubicado en el
eNB de la celda a la que el Terminal mvil desea conectarse.
Adquirir la sincronizacin temporal a nivel de trama y subtrama
Determinar la identidad fsica de la celda.
El procedimiento de bsqueda de celda se basa en el uso de las seales de sincronizacin primaria y secundaria
del sistema.
Adems, con la deteccin del canal de sincronizacin primario P-SCH, el terminal mvil tambin realiza las
siguientes funciones
Correccin de offsets de frecuencia introducidos en la seal recibida por los cabezales de RF transmisores y
receptores as como el ajuste de la frecuencia central del radiocanal (raster en frecuencia - El raster en
frecuencia se define como la granularidad con que se puede ajustar la frecuencia portadora o central de un
radiocanal. En el caso de LTE se ha fijado en 100KHz).
Adquisicin del sincronismo de smbolo.
Deteccin del lmite de trama.
Deteccin del grupo de identificadores de celda (Cell group ID).
Finalmente, a partir del canal de radiodifusin (PBCH), el terminal mvil obtiene informacin de la red (cell system
information) a la que quiere conectarse, informacin necesaria para poder operar correctamente. Para ello, el
terminal mvil recibe, utilizando el canal de radiodifusin (PBCH), el denominado Master Information Block que
bsicamente contiene informacin sobre la canalizacin disponible (4 bits), informacin sobre la configuracin del
canal PHICH (3 bits) y 7 bits para el nmero de trama (System Frame Number-SFN).

237
238
Se entiende por acceso aleatorio al procedimiento mediante el cual un terminal mvil se conecta a un
determinado eNB. Este procedimiento se ejecuta por diversas razones:
i. al acceder el terminal mvil a la red,
ii. cuando el terminal mvil realiza un procedimento de handover, es decir cuando a lo largo de una
llamada, cambia de eNB,
iii. cuando el terminal mvil realiza procedimientos de reseleccin de celda,
iv. como resultado de una llamada entrante, etc.
En el sistema LTE se definen dos tipos distintos de procedimientos de de acceso:
Acceso basado en contienda, que aplica de forma general, es decir tanto a los procesos de acceso
general, transferencia de llamada (handover), transferencia de informacin en UL para establecer
los mecanismos de scheduling, cuando no estn disponibles canales del tipo PUCCH o bien cuando
hay datos a transmitir en el enlace ascendente o descendente y el terminal mvil ha perdido la
sincronizacin (e.g., debido a mecanismos de ahorro de batera o power saving).
Acceso regulado (no basado en contienda), que slo aplica en los procedimientos de handover.
La diferencia entre uno y otro radica que en el segundo caso no hay posibilidad de colisin de la
secuencia prembulo

239
Para poder establecer cualquier tipo de transferencia de informacin entre el terminal mvil y el eNB es
necesario establecer el denominado servicio portador radio, tanto a nivel de sealizacin (servicio
portador radio de sealizacin o SRBs) como de datos (DRBs).
El mecanismo de establecimiento de la conexin a nivel de capa RRC implica el establecimiento de un
servicio portador de sealizacin del tipo SRB1 (dedicado al intercambio de mensajes del protocolo RRC
y los protocolos NAS) y el envo de un mensaje hacia el NAS pidiendo el establecimiento de una
conexin a travs de la interfaz S1 que conecta al eNB con el gestor de movilidad (MME).
Habitualmente, despus de esta primera fase de establecimiento de la conexin se inicia una segunda
fase en donde se activan los mecanismos de seguridad y se establece un segundo servicio portador
radio de sealizacin (SRB2) y uno o varios servicios portadores de datos (DRB) dependiendo del
nmero de portadores opcionales y por defecto establecidas con la red troncal EPC (Evolved Packet
Core) del sistema LTE.

240
Initial Attach Procedure
After the Random Access procedure, if the UE is not already attached to the network it has to do so by initiating the
attach procedure. Otherwise, the UE initiates the tracking area update if it changed its tracking area since the last
update. For initiating any NAS procedure, the UE is required to establish an RRC connection with the eNodeB. The
purpose of this procedure, depicted in the figure, is to request the resources from the network for its service needs.
NAS Common Procedures
The MME can initiate the NAS common procedures during the initial Attach, Tracking Area Update and other
dedicated NAS procedures. These procedures, depicted in Figure 10, are used to identify and authenticate the UE.
1. The MME sends the identity Request to the UE if it is unable to retrieve the UE profile from the HSS.
2. The UE responds back with its IMSI in the Identity Response message to MME.
3. After getting the valid IMSI from the UE, the network now authenticates the UE to ascertain whether the UE is
genuine or not. The network and UE share a secret key (the Authentication Centre stores it in the network and the
SIM card stores it in UE). Using this secret key and a random number, the network (AuC) computes a result and
expects the UE to give back the same result as part of this procedure.
4. After receiving the parameters (RAND and AUTN from the network), the UE computes the result and gives it back
to the network in the Authentication Response.
5. After successful authentication, the network initiates the Security mode command to encrypt the NAS messages
between the UE and MME; this is to protect the privacy of the subscriber.
6. The UE agrees to the Security mode command and sends the response back to the Network. After this step, both
the UE and the network will encrypt the NAS messages while sending and decrypt them while receiving. Similarly,
NAS messages are integrity-protected from now onwards.

241
Procedimiento de vinculacin inicial

NAS Attach Procedure

To get NAS-level services (for example, internet connectivity) from the network, NAS nodes in the network have to know about
the UE. To facilitate this; the UE has to initiate the Attach Procedure, which is mandatory for the UE at power on and also during
the initial access of the network.
Once the attach procedure succeeds, a context is established for the UE in the MME, and a default bearer is established
between the UE and the PDN GW and an IP address is allocated to it. Now that the UE has IP connectivity, it can start using IP-
based internet services or IMS services if the IMS network is available and if the UE has a subscription for the same. The NAS
Attach procedure is depicted in the Figure 9 and the steps are given below:
1. UE establishes the RRC Connection with the eNodeB.
2. The UE sends the ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST for the PDN (IP)
connectivity on the established RRC Connection. As part of this, the eNodeB establishes the S1 logical connection with the MME
for this UE.
3. If the Network is not able to identify the UE with the Identity given in the Attach Request message, it initiates the identification
followed by Authentication and Security Mode procedures as given in Figure 10
4. The MME update the HSS with the location of the UE using the Update Location request message using the Diameter
protocol; it also requests the subscriber profile from the HSS using this message.
5. The HSS updates its database with the current location of the UE and sends the subscriber profile information to the MME in
the Diameter Update Location Acknowledge message.
6. The MME now establishes an eGTP User Tunnel to establish the default bearer at the SGW; it sends a Create Session
Request (eGTP-C protocol) toward the SGW.
7. The SGW creates the default bearer for this UE and requests the PGW to create a bearer for this UE between the SGW and
the PGW to provide end-to-end bearer connectivity. The PDN-GW then creates the bearer and allocates an IP Address for the
UE.
8. Once the SGW receives the response from the PGW, it responds with a Create Session Response to MME.
9. The MME now has to establish the bearer between the eNodeB and SGW. It sends the S1AP Initial Context Setup Request to
the eNodeB to create a context for this UE, which includes the bearer Context and the security Context.
10. After receiving the Initial Context Setup Request, the eNodeB now establishes the security parameters with the UE by
initiating the AS Security Mode Command Procedure.
11. The UE establishes the security parameters (parameters required for ciphering the Integrity protection) and sends the
Security Mode Complete Message to the eNodeB. From now on, all the messages exchanged between the UE and eNodeB on
the radio interface are ciphered as well as integrity-protected.
12. The eNodeB reconfigures the resources to the UE by sending an RRC Connection Reconfig Request to the UE. In this
message, the eNodeB piggy-backs the Activate Default EPS Bearer Context Request NAS message to the UE.
13. The UE updates its RRC Connection configuration and responds back with an RRC Connection Reconfig Complete.
14. The eNodeB now sends the Initial Context Setup Response to the MME.
15. The MME sends the eGTP-C Modify Bearer Request to the SGW to update the eNB Tunnel Id for the default bearer.
16. After updating the information, the SGW responds with a Modify Bearer Response to the MME.
17. The MME now sends the Attach Accept and Activate Default Bearer Context Request NAS message to the UE.
18. If the MME has allocated a GUTI while sending the Attach Accept, the UE needs to process it and give back the Attach
Complete as a response to it. The UE piggy-backs the Activate Default EPS bearer context Accept NAS message to the MME.

242
243
244
245
246
247
248
249
250
251
252
253
UE Initiated Detach Procedure
If the UE does not require services from the network, it needs to deregister itself with the network by initiating the detach procedure.
One example for this is when the UE is switched off.
This detach procedure is initiated by the UE by sending a DETACH REQUEST message. The Detach type IE included in the
message indicates whether detach is due to a switch off or not.
The network and the UE deactivate the EPS bearer context(s) for this UE locally without peer-to-peer signaling between the UE and
MME. If the detach type is a switch off then the MME does not send the Detach Accept, otherwise it does send it to UE. While
processing the Detach from the UE, the MME initiates the release of the EPS bearers in the network and it also clears the UE
Context held at the eNodeB (not shown in Figure).

254
Tracking Area Update

After a successful attach to the network, the UE can roam freely in the current Tracking Area. If it detects
a different tracking area, it needs to update the network with this new tracking area. Similarly, the network
can request the UE to update its tracking area periodically, which helps the network in quickly locating the
UE whenever a mobile-terminated call is received by the network for this UE since it can just page the UE
in the last reported area.
During the tracking area updating procedure, the MME may initiate an authentication procedure and
setup a security context.

255
256
257
 Llamada de datos originada en el UE

After successfully attaching to the network, the UE can request the services from the Network using the service request
procedure. One example scenario is when the UE requests resources from the Network to initiate a data call; the UE can utilize
the NAS service request procedure for this purpose. Another example of this procedure is to invoke MO/MT CS fallback
procedures if they are supported by the network.
1. The UE establishes the RRC Connection with the eNodeB.
2. The UE sends the Service Request to the MME and requests (dedicated) bearer resources by including the Bearer Resource
Allocation Req. As part of this, the eNodeB establishes the S1 logical connection with the MME for this UE. Note that the UE
may also send the Bearer Resource Allocation Req to the MME as a standalone message at a later point in time too.
3. At this point the network can initiate an optional identification followed by Authentication and Security Mode procedures as
given in Figure 10.
4. After the completion of the Authentication and Security Mode control procedures, the MME initiates the activation of default
bearer with the SGW / PGW by initiating the eGTP-C Modify Bearer Req message toward the SGW.
5. After receiving the Modify Bearer Req, the SGW activates the required resources and forwards the Modify Bearer Req toward
the PDN GW.
6. The PGW processes the Modify Bearer Req and activates required resources. Note that the IP Address is allocated during the
Attach procedure, so it will not happen now. It responds back with the Modify Bearer Response to the SGW and the SGW
forwards it to the MME.
7. The MME now initiates the Dedicated Bearer establishment by sending the eGTP-C Bearer Resource Command to the SGW.
8. The SGW process the Bearer Resource Command and forwards it to the PGW.
9. The PGW responds with a Create Bearer Request toward the SGW after allocating the dedicated bearer resource (TFT
initialization, etc).
10. The SGW process the Create Bearer Request and forwards to the MME for further processing.
11. The MME now sends the E-RAB Setup Req to the eNodeB to allocate the bearer between the eNodeB and the SGW; it
piggy-backs the NAS Activate Dedicated EPS Bearer Context Req to the UE.
12. The eNodeB allocates the resources for the Radio Bearers using an RRC Conn Reconfig Req message to the UE. The
eNodeB includes the received NAS message in it.
13. The UE establishes the Radio bearers and responds back with an RRC Connection Reconfiguration Complete Msg to the
eNodeB.
14. Radio Bearers are established between the eNodeB and the UE by now, so the eNodeB sends the E-RAB Setup response to
the MME.
15. The UE now sends the Activate Dedicated EPS Bearer Context Accept NAS message to the MME via the eNodeB.
16. The MME sends a Create Bearer Response to the SGW to complete the Dedicated Bearer Activation. The SGW forwards it
to the PGW.

258
Once the UE finishes the Data call it can trigger the release of the dedicated bearers by sending the Bearer
Resource Modification Req message to the MME, which can then take care of releasing the dedicated bearer
with the SGW and PGW.
1. The UE triggers the dedicated bearer release by sending the Bearer Resource Modification Request to the
MME.
2. The MME initiates an EPS bearer context deactivation procedure by sending the eGTP-C Bearer Resource
Command Msg to the SGW.
3. The SGW process the Bearer Resource Command and forwards it to the PGW.
4. The PGW initiates the Delete Bearer Req msg toward the SGW/MME to clear the requested bearer
resources. The SGW forwards the same to the MME.
5. The MME initiates the E-RAB Release Command to the eNB to clear the bearer resources. It includes the
NAS Msg: Deactivate EPS Bearer Context Req message for the UE.
6. The UE receives the NAS message from the eNB in the DL NAS procedure. It clears the bearer resources
and sends a Deactivate EPS Bearer Context Accept to the MME.
7. The eNB now sends the E-RAB Release Response to the MME.
8. The MME sends the Delete Bearer Response to the SGW and the SGW forwards it to the PGW after
clearing the bearer resources.
9. The PGW clears the requested Bearer resources.
10. If it is the release of the last dedicated bearer for this UE, the MME shall release the Context associated
with this UE by sending an S1AP UE Context Release Command.
11. The eNodeB clears the Radio resources allocated to this UE by sending the RRC Connection Release
message to the UE.

259
Paging
The paging procedure is used by the network to request the establishment of a NAS signaling connection
to the UE. If there is an IP packet that comes for a UE from the external network to the PGW and if there
is no dedicated bearer existing for the UE, it will forward the IP packet to the SGW on the default bearer.
Once the packet has reached the SGW on the default bearer, the SGW detects the need to create a
dedicated bearer and sends the Downlink Data Notification message to the MME in order the page the
UE and create the dedicated bearers.
Now the MME has to ensure that the UE establishes an RRC connection, so the MME sends a Paging
Request message to all eNodeBs associated with the last known Tracking Area.

260
Mobile-Terminated Data Call
For a UE-terminated call, the network sends the paging request to all the eNodeBs associated with the
last known tracking area as discussed above. When receiving the Paging Request message from the
MME, the eNodeB sends the paging message over the radio interface in the cells which are contained
within one of the tracking areas provided in that message.
The UE is normally paged using its S-TMSI or IMSI. The Paging message also contains a UE identity
index value in order for the eNodeB to calculate the paging occasions at which the UE listens for paging
message.
1. The PGW/SGW receive the incoming IP packet addressed to a UE.
2. The SGW sends a DL Data Notification to the MME requesting dedicated UE bearer creation.
3. The MME now sends a Paging message to notify the UE about the incoming IP Packet.
4. Once the UE receives the Paging message on the radio interface, it establishes the RRC Connection
with the eNodeB.
5. The UE sends the Service Request to the MME and includes the Bearer Resource Allocation Request
to request the Dedicated Bearer Establishment.
6. From this point onward, the message sequence is the same as that outlined in the Mobile Originated
Data Call.

261
Objectives of Handover Procedures
1. It is important that QoS is maintained, not just before and after a handover, but during the handover
as well.
2. Handover shall not drain the UE battery power.
3. Service continuity shall be maintained (i.e., minimal handover latency).
4. Seamless handoff to 3G / 2G / CDMA technology.
There are two ways a handoff can be decided:
Network Evaluated: the network makes the handover decision
Mobile Evaluated: the UE makes the handoff decision and informs the network about it. In this instance,
the final decision will be made by the network based upon on the Radio Resource Management.
In 3G and LTE networks, a hybrid approach is used to decide on the handover. In this case, the UE will
assist in the handoff decision by measuring the neighboring cells and reporting the measurements to
the network, which in turn decides upon the handoff timing and the target cell/node. The parameters to
measure and the thresholds for reporting are decided by the network.
In LTE there are three types of handovers:
Intra-LTE: Handover happens within the current LTE nodes (intra-MME and Intra-SGW)
Inter-LTE: Handover happens toward the other LTE nodes (inter-MME and Inter-SGW)
Inter-RAT: Handover between different radio technology networks, for example GSM/UMTS and UMTS

262
 Traspaso Intra-LTE usando X2

This procedure is used to handover a UE from a source eNodeB (S-eNB) to a target eNodeB (T-eNB) using the X2 interface when the Mobility
Management Entity (MME) and Serving Gateway (SGW) are unchanged. It is possible only if direct connectivity exists between the source and
target eNodeBs with the X2 interface.
The X2 handover procedure is performed without Evolved Packet Core (EPC) involvement, i.e. preparation messages are directly exchanged
between the S-eNB and T-eNB. The release of the resources at the source side during the handover completion phase is triggered by the T-
eNB. The message flow is shown in the figure followed by the description.
1. A data call is established between the UE, S-eNB and the network elements. Data packets are transferred to/from the UE to/from the
network in both directions (DL as well as UL).
2. The network sends the MEASUREMENT CONTROL REQ message to the UE to set the parameters to measure and set thresholds for
those parameters. Its purpose is to instruct the UE to send a measurement report to the network as soon as it detects the thresholds.
3. The UE sends the MEASUREMENT REPORT to the S-eNB after it meets the measurement report criteria communicated previously. The
S-eNB makes the decision to hand off the UE to a T-eNB using the handover algorithm; each network operator could have its own
handover algorithm.
4. The S-eNB issues the RESOURCE STATUS REQUEST message to determine the load on T-eNB (this is optional). Based on the received
RESOURCE STATUS RESPONSE, the S-eNB can make the decision to proceed further in continuing the handover procedure using the
X2 interface.
5. The S-eNB issues a HANDOVER REQUEST message to the T-eNB passing necessary information to prepare the handover at the target
side (e.g., UE Context which includes the Security Context and RB Context (including E-RAB to RB Mapping) and the Target cell info).
6. The T-eNB checks for resource availability and, if available, reserves the resources and sends back the HANDOVER REQUEST
ACKNOWLEDGE message including a transparent container to be sent to the UE as an RRC message to perform the handover. The
container includes a new C-RNTI, T-eNB security algorithm identifiers for the selected security algorithms, and may include a dedicated
RACH preamble and possibly some other parameters (i.e., access parameters, SIBs, etc.).
7. The S-eNB generates the RRC message to perform the handover, i.e, RRCCONNECTION RECONFIGURATION message including the
mobilityControlInformation. The S-eNB performs the necessary integrity protection and ciphering of the message and sends it to the UE.
8. The S-eNB sends the eNB STATUS TRANSFER message to the T-eNB to convey the PDCP and HFN status of the E-RABs.
9. The S-eNB starts forwarding the downlink data packets to the T-eNB for all the data bearers (which are being established in the T-eNB
during the HANDOVER REQ message processing).
10. In the meantime, the UE tries to access the T-eNB cell using the non-contention-based Random Access Procedure. If it succeeds in
accessing the target cell, it sends the RRC CONNECTION RECONFIGURATION COMPLETE to the T-eNB.
11. The T-eNB sends a PATH SWITCH REQUEST message to the MME to inform it that the UE has changed cells, including the TAI+ECGI of
the target. The MME determines that the SGW can continue to serve the UE.
12. The MME sends a MODIFY BEARER REQUEST (eNodeB address and TEIDs for downlink user plane for the accepted EPS bearers)
message to the SGW. If the PDN GW requested the UEs location info, the MME also includes the User Location Information IE in this
message.
13. The SGW sends the downlink packets to the target eNB using the newly received addresses and TEIDs (path switched in the downlink
data path to T-eNB) and the MODIFY BEARER RESPONSE to the MME.
14. The SGW sends one or more end marker packets on the old path to the S-eNB and then can release any user plane / TNL resources
toward the S-eNB.
15. The MME responds to the T-eNB with a PATH SWITCH REQ ACK message to notify the completion of the handover.
16. The T-eNB now requests the S-eNB to release the resources using the X2 UE CONTEXT RELEASE message. With this, the handover
procedure is complete.

263
The S1-based handover procedure is used when the X2-based handover cannot be usede.g., no X2
connectivity to the target eNodeB; by an error indication from the T-eNB after an unsuccessful X2-based
handover; or by dynamic information learnt by the S-eNB using the STATUS TRANSFER procedure. The
S-eNB initiates the handover by sending a Handover required message over the S1-MME reference
point. The EPC does not change the decisions taken by the S-eNB.
The availability of a direct forwarding path is determined in the S-eNB (based on the X2 connectivity with
the T-eNB) and indicated to the source MME. If a direct forwarding path is not available, indirect
forwarding will be used. The source MME uses the indication from the S-eNB to determine whether to
apply indirect forwarding or not. The message flow is depicted in the figure.
Intra-LTE Handover (Intra-MME/SGW)
As mentioned in the previous slide, based on the MEASUREMENT REPORT from the UE, the S-eNB
decides to Handover the UE to another eNodeB (T-eNB). The handover procedure in this section is very
similar to that in the previous section (Intra-LTE Handover Using the X2 Interface), except the
involvement of the MME in relaying the handover signaling between the S-eNB and T-eNB.
There are two differences here: No need for the PATH SWITCH Procedure between the T-eNB and
MME, as MME is aware of the Handover.
The SGW is involved in the DL data forwarding if there is no direct forwarding path available between the
S-eNB and T-eNB.
Once the Handover is complete, the MME clears the logical S1 connection with the S-eNB by initiating
the UE CONTEXT RELEASE procedure.

264
In an inter-MME handover, two MMEs are involved in the handover, the source MME (S-MME) and target MME (T-
MME). The S-MME controls the S-eNB and the T-MME controls the T-eNB; both MMEs are connected to the same
SGW. This handover is triggered when the UE moves from one MME area to another MME area.
1. As mentioned in the previous section (Intra-MME/SGW handover), based on the MEASUREMENT REPORT
from the UE, the S-eNB decides to handover the UE to another eNodeB (T-eNB). The handover procedure in
this section is very similar to that in the previous section except for the involvement of two MMEs coordinating
the handover signaling between the source and target eNodeBs.
2. The S-MME uses GTP signaling to communicate the handover signaling to the T-MME and vice versa. The
FORWARD RELOCATION procedure in GTP-C is being used here.
3. After receiving the S1 HANDOVER REQUIRED, the S-MME detects that the target cell requested for handover
belongs to another MME and initiates the GTP FORWARD RELOCATION REQ message to the T-MME.
4. The T-MME creates the S1 logical connection toward the T-eNB and sends the S1 HANDOVER REQ on it.
5. The T-eNB prepares the requested resources and responds with a HANDOVER REQ ACK to the T-MME.
6. The T-MME sends a GTP FORWARD RELOCATION RESP to the S-MME, to notify the resource reservation at
the T-eNB. From this point onwards, the interaction between the S-MME and S-eNB is very similar to the S1-
based Intra-MME/SGW handover described in the previous section.
7. DL data packets are forwarded from the S-eNB to T-eNB via the SGW during the handover as the SGW is not
changed here.
8. Once the T-eNB detects the UE in its area, it notifies the T-MME with a S1 HANDOVER NOTIFY message.
9. The T-MME notifies the completion of the handover to the S-MME with a GTP FORWARD RELOCATION
COMPLETE NOTIFY message.
10. The S-MME acknowledges the GTP FORWARD RELOCAION COMPLETE NOTIFY to the T-MME and
proceeds with clearing the S1 logical connection and the associated bearer resources.

265
This scenario is similar to the previous section with the difference being the Source and Target
eNodeBs are served by different MME/SGW nodes.
1. As described in the previous section (Inter-MME, Intra-SGW handover), based on the
MEASUREMENT REPORT from the UE, the S-eNB decides to handover the UE to another
eNodeB (T-eNB). The handover procedure in this section is very similar to that in the
previous section, except for the involvement of two SGWs (S-SGW and T-SGW) to transfer
the data packets during the handover.
2. After receiving the GTP: FORWARD RELOCATION REQ from the S-MME, the T-MME
detects the SGW change and initiates the bearer creation toward the target SGW (T-SGW)
using a GTP: CREATE SESSION REQ message.
3. After the creation of the requested bearers, the T-SGW responds back to the MME with a
GTP: CREATE SESSION RESPONSE message.
4. From this point onward, the message flow is very similar to that in the previous section (Inter-
MME, Intra-SGW handover) except for the following differences:
While processing the S1 HANDOVER NOTIFY message from the T-eNB, the T-MME
updates the T-eNB endpoint information to the T-SGW using GTP: MODIFY BEARER
REQ.
After updating the T-eNB information in the bearers (successfully set up during the
handover), the T-SGW responds with a GTP: MODIFY BEARER RESPONSE message to
the T-MME.
After successful completion of the handover, the S-MME takes care of releasing bearer
resources with the S-SGW for this UE by initiating the GTP: DELETE SESSION procedure.

266
In the LTE-to-UMTS Inter RAT handover, the source eNodeB connects to the S-MME and S-SGW while
the target RNC connects to the T-SGSN and T-SGW; both the source and target SGWs connect to the
same PGW. This procedure is divided into two parts for clarity, Preparation and Execution. In the
Preparation phase, resources are reserved in the target network. In the Execution phase, the UE is
handed over to the target network from the source network.
Once the inter-RAT handover is decided at the S-eNB based on the measurement report procedure, it
prepares and sends a HANDOVER REQUIRED message to the S-MME.
The S-MME detects that it is an Inter-RAT handover from the message contents, retrieves the target
SGSN details from the database based on the information in the message. It now prepares and sends
a GTP-C: FORAWRD RELOCATION REQUEST to the T-SGSN.
The T-SGSN detects the change of SGW and creates the bearer resources in the T-SGW by initiating
the GTP: CREATE SESSION procedure.
Once the resources are reserved at the T-SGW, it responds to the T-SGSN with a GTP: CREATE
SESSION RESPONSE message.
The T-SGSN now reserves the resources at the T-RNC by sending a RANAP: RELOCATION
REQUEST message to it.
The T-RNC reserves the radio resources and responds to the T-SGSN with a RANAP: RELOCATION
REQUEST ACK message.
The T-SGSN creates the indirect data forwarding tunnels in the T-SGW for the DL packets transfer
from the S-SGW to T-SGW during the handover.
After the Indirect Data forwarding tunnel creation, the T-SGSN responds with a GTP: FORWARD
RELOCATION RESPONSE message to the S-MME.
The S-MME has to create the indirect data forwarding tunnels as the resources are reserved
successfully in the target network to forward the DL packets to the target network. With this, the
preparation phase is complete.

267
1. The S-MME sends the HANDOVER COMMAND message to the S-eNB with the target to source
transparent container (i.e., it has the reserved resource information at the target).
2. The S-eNB prepares and sends the MOBILITY FROM EUTRA COMMAND message to prepare the
UE for the handover toward the target network.
3. After accessing the target UMTS cell, the UE sends a HO TO UTRAN COMPLETE message to the T-
RNC signaling the successful handover.
4. The S-eNB forwards the DL data packets toward the T-SGW via the S-SGW during the handover.
This step can happen any time after it receives the S1AP HANDOVER COMMAND message from the
S-MME. This step is executed in case a direct forwarding path is not available with the T-RNC,
otherwise it will forward the DL data packets to the T-RNC directly.
5. Once the T-RNC detects the UE in its area, it notifies the T-SGSN about the completion of the
handover by sending a RANAP: RELOCATION COMPLETE message.
6. The T-SGSN notifies the completion of handover to the S-MME by sending a GTP: FORWARD
RELOCATION COMPLETE NOTIFICATION ACK message. The S-MME acknowledges this message
and proceeds with release of the resources associated with this UE at the S-SGW and S-eNB.
7. The T-SGSN modifies the E-RAB resources at the T-SGW by initiating the GTP MODIFY BEARER
procedure.
8. The T-SGW notifies the bearer parameters with the PGW by initiating the GTP MODIFY BEARER
procedure.

268
269
 Voz sobre LTE: Fases de Implementacin

Soporte de voz sobre LTE

En la nueva arquitectura LTE y SAE, no existe el dominio de circuitos conmutados para manejar las llamadas
de voz, tal y como ocurra en las tradicionales redes 2G/3G. Las principales -que no las nicas- formas de
ofrecer voz sobre las redes 4G son: 1) CSFB; 2) mVoIP de OTT; y 3) VoLTE basado en IMS. Actualmente,
GSMA VoLTE es la opcin preferida por los operadores mviles para el despliegue masivo de servicios de
voz sobre IP.
CSFB sobre redes 2G/3G
CSFB (Circuit Switched Fallback) es la solucin estndar del 3GPP para ofrecer voz en las etapas
iniciales de despliegue de LTE, cuando no existe suficiente cobertura o el operador no ha desplegado IMS.
Es la tecnologa empleada en los despliegues comerciales iniciales de LTE, por ejemplo, por parte de: AT&T,
Verizon y MetroPCS en Estados Unidos; Telia-Sonera y T-Mobile en Europa; NTT DoCoMo y KDDI en Japn,
etc.
Aunque para las comunicaciones de datos se utiliza LTE, a travs de CSFB el terminal es redirigido a la
red 2G/3G para iniciar o recibir una llamada de voz y la llamada permanece en el dominio de circuitos
conmutados hasta que es completada. En redes con poca cobertura de LTE, esto permite evitar continuos
handovers entre conmutacin de circuitos y VoIP.
Puesto que CSFB slo proporciona los servicios de voz y SMS tradicionales, es considerada una etapa
intermedia en la evolucin hacia servicios de comunicaciones totalmente multimedia. Sin embargo, una vez
introducida CSFB, probablemente seguir siendo reutilizada en fases posteriores, debido a que CSFB
permite soportar usuarios de LTE en roaming sin capacidades de IMS.
mVoIP OTT
Los mobile VoIP Over-the-top (OTT) son aplicaciones como Skype, Google Voice, FaceTime, Fring,
Line2, Nimbuzz, Talkonaut, Tango, ThruTu , Truphone o Viber. Su xito se ha basado, principalmente, en
que se pueden instalar fcilmente y sin coste, pudiendo realizar llamadas y videollamadas internacionales e
intercambiar mensajes y ficheros de forma gratuita o a un coste muy bajo. Para evitar la huida de clientes
han aparecido incluso servicios de OTT liderados por operadores, como Bobsled de T-Mobile y TU Me de
Telefnica. Otros operadores, como Verizon, estn trabajando para que los OTT y desarrolladores de
aplicaciones de Internet estn integrados en su plataforma IMS, mejorando la experiencia de usuario sobre
estas aplicaciones.
A medida que las redes mviles se conviertan en redes todo IP y las capacidades multimedia de los
dispositivos mviles mejoren, las barreras de entrada de los OTT al mundo mvil estn desapareciendo,
pudiendo llegar a una situacin similar a la que se ha producido en las redes fijas. Aunque es complicado
para los operadores mviles competir con estos servicios de bajo coste, la realidad es que la mayora tienen
modelos de negocio insostenibles y puesto que la calidad de servicio ofrecido por las OTT no est
garantizada y no es posible ofrecer una experiencia de usuario satisfactoria sin cobertura 4G continua -
debido a la ausencia de un mecanismo de handover a la red de circuitos conmutados-, el xito a largo de
los clientes mVoIP OTT es toda una incgnita.

270
271
The CS FallBack (CSFB) in EPS enables the provisioning of voice and other CS-domain services (e.g.
CS UDI video, LCS, USSD) by reuse of CS infrastructure when the UE is served by E-UTRAN. A CSFB
enabled terminal, connected to E-UTRAN may use GERAN or UTRAN to connect to the CS-domain. This
function is only available in case E-UTRAN coverage is overlapped by either GERAN coverage or
UTRAN coverage.

272
The CSFB and SMS over SGs in EPS function is realized by using the SGs interface mechanism
between the MSC Server and the MME.
SGs is an interface between the MME and MSC server. It is used for the Mobility Management (MM) and
paging procedures between EPS and CS domain, and is based on the Gs (VLR-SGSN) interface
procedures. The SGsreference point is also used for the delivery of both Mobile Originating and Mobile
Terminating SMS (MO-SMS and MT-SMS).
S3 is an interface between MME and SGSN. It has additional functionality to support CSFB with ISR.
SGs Application Part (SGsAP) protocol is used to connect an MME to an MSC Server. SGsAP is based
on the BSSAP+ protocol, used earlier on Gs (SGSN-VLR) interface.
Stream Control Transmission Protocol (SCTP) transfers signalling messages.

273
For UE originating calls, the UE performs access domain selection. The service domain selection
functionality decides whether the call is serviced in the CS domain or the IMS. Service domain selection
functionality may take into account for originating calls whether the user is roaming or not, user
preferences, service subscription and operator policy. If the UE is configured for Voice over IMS, the
service domain selection functionality takes the IMS voice over PS session supported indication into
account and should only initiate IMS voice calls (with the voice bearer in the PS domain) using the RAT
where the IMS voice over PS session supported indication applies and indicates support. The "IMS
voice over PS session supported indication applies to E-UTRAN when received in E-UTRAN, and
applies to UTRAN when either received in GERAN or UTRAN

274
To allow for appropriate domain selection, the CSFB and IMS capable UE in E-UTRAN can be provision with the HPLMN
operator preferences on how a CSFB/IMS enabled UE is supposed to handle vice services:
CS Voice only: the UE does not attempt to initiate voice sessions over IMS using a PS bearer. The UE attempts
combined EPS/IMSI attach.
CS Voice preferred, IMS PS Voice as secondary: the UE tries preferably to use the CS domain to originate and terminate
voice calls. The UE attempts combined EPS/IMSI attach and if combined EPS/IMSI attach fails for the CS domain or
succeeds with an SMS only indication or succeeds with a CSFB Not Preferred indication, the UE attempts voice over IMS.
IMS PS Voice preferred, CS Voice as secondary: the UE tries preferably to use IMS to originate and terminate voice
sessions. If the UE fails to use IMS for voice e.g. due to IMS voice over PS session supported indication indicates voice
is not supported, then the services are provided using CS domain. The UE can either perform combined EPS/IMSI attach
or EPS attach when attaching to E-UTRAN.
IMS PS Voice only: the UE does not attempt combined EPS/IMSI attach (to support voice services) and perform IMS
registration indicating support for voice.
A CSFB/IMS enabled UE may behave in either a Voice centric or Data centric way:
UE acting in a Voice centric way always tries to ensure that Voice service is possible. A CSFB/IMS enabled UE acting
in a Voice centric way that cannot obtain IMS voice over PS session service, selects a cell of any RAT that provides
access to the CS domain. In this case, when CSFB is not supported in the network, the UE camps only on RATs that
provides access to the CS domain (e.g. GERAN and UTRAN) and disable E-UTRAN capability.
Upon receiving combined EPS/IMSI attach accept with SMS only indication or with CSFB Not Preferred indication, a
voice centric UE that fails to use IMS reselects to another RAT.
UE acting in a Data centric way always tries to ensure it gets PS data connectivity, e.g. the UE stays in the current RAT
for PS data connectivity even when voice service is not obtained. A CSFB/IMS enabled UE acting in a Data centric way
that cannot obtain IMS voice over PS session service in EPS, continues to stay in EPS even when the EPS does not
support CSFB.
Upon receiving combined EPS/IMSI attach accept with SMS only indication, a data centric UE stays in the current RAT.
Upon receiving combined EPS/IMSI attach accept with CSFB Not Preferred indication, a data centric stays in the current
RAT and is allowed to use CSFB.

275
276
The attach procedure for the CS fallback and SMS over SGs in EPS is realized based on the combined
GPRS/IMSI Attach procedure specified earlier for the Gs interface.
The UE initiates the attach procedure by the transmission of an Attach Request. message to the MME. The
Attach Type parameter indicates that the UE requests a combined EPS/IMSI attach and informs the network
that the UE is capable and configured to use CS fallback. If the UE needs SMS service but not CSFB, the UE
includes an SMS-only indication.
Security procedures, registration and default bearer establishment as in ordinary EPS Attach procedure.
The MME allocates a default LAI, which is configured on the MME and may take into account the current TAI
and/or E-CGI and whether the IMSI attach is for both CSFB and SMS, or for SMS only. The MME derives a
VLR number based on the allocated LAI and IMSI. The MME starts the location update procedure towards the
new MSC/VLR upon receipt of the subscriber data from the HSS in step .
The MME sends a Location Update Request (new LAI, IMSI, MME IP address, Location Update Type)
message to the VLR.
The VLR creates an association with the MME by storing MME address.
The VLR performs Location Updating procedure in CS domain.
The VLR responds with Location Update Accept (TMSI) to the MME.
The EPS Attach procedure is completed. Attach Accept message includes LAI and TMSI. The existence of
LAI and TMSI indicates successful attach to CS domain.
If the UE requests combined EPS/IMSI Attach Request without the SMS-only indication, and if the network
supports only SMS over SGs, the network performs the IMSI attach and the MME indicates in the Attach
Accept message that the IMSI attach is for SMS only.
When the network accepts a combined EPS/IMSI attach without limiting to SMS-only, the network may
provide a CSFB Not Preferred indication to the UE.

277
The combined TA/LA Update procedure for the CSFB and SMS over SGs in EPS is realized based on the combined RA/LA
Update procedure specified in earlier for the Gs interface.
The UE detects a change to a new TA by discovering that its current TAI is not in the list of TAIs that the UE registered with the
network.
The UE initiates the TAU procedure by sending a TAU Request. The Update Type indicates that this is a combined Tracking
Area/Location Area Update Request or a combined Tracking Area/Location Area Update with IMSI attach Request. If the UE
needs SMS service but not CSFB, the UE include an SMS-only indication in the combined TA/LA Update procedure.
Security procedures, possible MME and S-GW reallocation and bearer modification as in ordinary EPS TAU procedure. If there
is an associated VLR in the MM context, the VLR also needs to be updated. If the association has to be established or if the LA
changed, the new MME sends a Location Update Request (new LAI, IMSI, MME IP address, Location Update Type) message to
the VLR. New LAI is determined in the MME based on the received GUTI from the UE. If this GUTI is mapped from a P-
TMSI/RAI, the LAI is retrieved from the GUTI without any modification by the MME. Otherwise, the MME allocates a default LAI,
which is configured on the MME and may take into account the current TAI or E-CGI and whether the IMSI attach is for both
CSFB and SMS, or for SMS only. The MME retrieves the corresponding VLR number from the determined LAI. If multiple
MSC/VLRs serve this LAI an IMSI is used to retrieve the VLR number for the LAI.. The Location Update Type indicates normal
location update.
The VLR performs Location Update procedure in CS domain.
The VLR responds with Location Update Accept (TMSI) to the MME.
The MME sends a TAU Accept (LAI, TMSI) message to the UE. The TMSI is optional if the VLR has not changed. The presence
of the LAI indicate to the UE that it is IMSI attached. If the UE requests combined TA/LA Update Request without the SMS-only
indication, and if the network supports SGs for SMS only, the network performs the IMSI attach and the MME indicates in the
TAU Accept message that the IMSI attach is for SMS only.
The UE may send a TAU complete message for the TAU procedure if the LAI/TMSI has been changed.
Periodic TA/LA update procedure
When the UE is camped on E-UTRAN, periodic LA updates are not performed, but periodic TA updates are performed. In this
case, an SGs association is established and the MSC/VLR disables implicit detach for EPS-attached UEs and instead rely on the
MME to receive periodic TA updates.

278
 The UE sends an Extended Service Request (CS Fallback Indicator) to MME. CS Fallback Indicator indicates MME
to perform CS Fallback. The UE only transmits this request if it is attached to CS domain (with a combined EPS/IMSI
Attach) and can not initiate an IMS voice session (because e.g. the UE is not IMS registered or IMS voice services
are not supported by the serving IP-CAN, home PLMN or UE).
The MME sends an S1-AP Request message to eNB that includes a CS Fallback indicator. This message indicates
to the eNB that the UE should be moved to UTRAN/GERAN.
The eNB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN cell to
which PS handover will be performed.
If the UE and the network support inter-RAT handover from E-UTRAN to GERAN/UTRAN, the eNB triggers PS
handover to a GERAN/UTRAN neighbour cell by sending a Handover Required message to the MME.
If the UE and the network support inter-RAT Cell Change Order (CCO) to GERAN and the target cell is GERAN, the
eNB triggers an inter-RAT CCO (optionally with NACC).
If the UE or the network does not support inter-RAT handover from E-UTRAN to GERAN/UTRAN nor inter-RAT
CCO, the eNB triggers connection release with redirection to GERAN/UTRAN instead of PS HO or COO.
The UE establishes CS signalling connection in the target RAT and sends CM Service Request message. The
simultaneous support of packet data bearers depends on selected RAT and additional features like e.g. DTM.
In case the MSC serving the 2G/3G target cell is different from the MSC that served the UE while camped on E-
UTRAN, the MSC rejects the service request, if implicit location update is not performed. The CM Service Reject
triggers the UE to perform a Location Area Update as follows:
If the target system operates in Network Mode of Operation (NMO) I the UE performs a combined RA/LA update.
In this case, the SGSN establishes a Gs association with the MSC/VLR, which replaces the SGs association with
the MME.
If the target system operates in NMO II or III the UE performs a LA update towards the MSC. In this case, the MSC
releases the SGs association with the MME.
The UE initiates the CS call establishment procedure.
The UE may trigger the RA update procedure when the sending of uplink packet data is possible.

279
Llamada MO sin HO de PS

280
The MSC receives an incoming voice call.
The MME receives a CS Paging (IMSI, VLR TMSI, Location Information, optional Caller Line Identification)) message from the
MSC over a SGs interface. The TMSI (or IMSI) received from the MSC is used by the MME to find the S-TMSI which is used as
the paging address on the radio interface.
If the UE is in Idle mode the MME pages the UE in all the TAs, the UE is registered to.1
In active mode the MME reuses the existing connection to relay the CS Page to the UE.
The eNB forwards the paging message to the UE. The message contains a suitable UE Identity (i.e. S-TMSI or IMSI) and a CN
Domain indicator and Caller Line Identification if available and needed.
The UE establishes an RRC connection or reuses the existing connection to send an Extended Service Request (CS Fallback
Indicator, Reject or Accept) to MME.
MME sends S1AP Initial UE Context Setup or S1AP Request message to eNB that includes CSFB indicator. This message
indicates to the eNB that the UE should be moved to UTRAN/GERAN.
The eNB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN cell to which PS
handover will be performed.
If the UE and the network support inter-RAT handover from E-UTRAN to GERAN/UTRAN, the eNB triggers PS handover to a
GERAN/UTRAN neighbour cell by sending a Handover Required message to the MME.
If the UE and network support inter-RAT Cell Change Order (CCO) to GERAN and the target cell is GERAN, the eNB triggers an
inter-RAT CCO (optionally with NACC).
If the UE or the network does not support inter-RAT handover from E-UTRAN to GERAN/UTRAN nor inter-RAT CCO, the eNB
triggers connection release with redirection to GERAN/UTRAN instead of PS HO or COO.
If the UE obtains LA/RA information of the new UTRAN/GERAN cell (e.g. based on the system information or redirection info)
and the LA/RA of the new cell is different from the one stored in the UE, it performs a Location Area
Update or a Combined RA/LA procedure if the target system operates in NMO I
The UE establishes CS signalling connection in the target RAT and sends Paging Response message2. The simultaneous
support of packet data bearers depends on selected RAT and additional features like e.g. DTM.
If the MSC that receives the Paging Response is different from the MSC that sent the paging request and if the Location Area
Update / Combined RA/LA Update was not performed in step , the MSC rejects the page response by releasing the A/Iu-cs
connection. The BSC/RNC in turn releases the signalling connection for CS domain. The signalling connection release triggers
the UE to perform a LA update or Combined RA/LA update. In case the MSC serving the 2G/3G cell is the same as the MSC
that served the UE while camped on LTE, it shall stop the paging response timer and establish the CS connection.

281
Llamada MT sin HO de PS

282
283
VoLTE basado en IMS
VoLTE en su forma ms sencilla, especifica un servicio basado en IMS (IP Multimedia Subsystem)
que trata de replicar las funcionalidades ofrecidas actualmente en el dominio de conmutacin de circuitos
2G/3G. El servicio fue descrito funcionalmente en la GSMA IR.92. Sin embargo, VoLTE proporciona los
servicios tradicionales con una mayor calidad debido, entre otras razones, a: la utilizacin de codecs de
banda ancha y el reducido tiempo de establecimiento de llamadas -inferior a un segundo, frente a los
cerca de tres segundos de UMTS-.
Adems, VoLTE puede ser utilizado para crear nuevos servicios avanzados que facilitan la
comunicacin multimedia y colaboracin en tiempo real. El objetivo es hacer estos servicios ubicuos y
accesibles, tal y como lo son la voz y SMS actualmente, pero abriendo tambin la interaccin con
aplicaciones Web. Los servicios VoLTE y RCSe, por el hecho de estar perfectamente definidos y ser
interoperables, permiten que otras empresas los utilicen para desarrollar aplicaciones ms avanzadas,
enfocando sus esfuerzos a cosas que son ms relevantes a su servicio en cuestin. La voz enriquecida
y la mensajera pueden ser integradas, por ejemplo, en una aplicacin de usuario o un servicio de
colaboracin empresarial sin que el desarrollador tenga que desarrollar el servicio de comunicaciones
por s mismo.
La solucin de VoLTE sobre IMS permite integrar RCSe (Rich Content Suite enhaced), tambin
conocido por su nombre comercial Joyn o por el WhatsApp de las operadoras, para realizar
videollamadas, mensajera instantnea, transferencia de ficheros, etc. Adems, permite a las operadoras
competir con las OTT, ofreciendo como aspectos distintivos: seguridad extremo a extremo, calidad de
servicio garantizada extremo a extremo, servicios regulatorios como llamadas de emergencias, alcance
global, interoperabilidad total con cualquier otro usuario sin necesidad de instalar ningn software en el
terminal mvil, servicios regulatorios como llamada a nmeros de emergencia o intercepcin de
llamadas, etc. De este modo, VoLTE es la solucin preferida e idnea para redes LTE maduras.
El handover entre VoLTE y la voz por circuitos conmutados en redes 2G/3G es importantsimo, debido
a la imposibilidad de conseguir una cobertura total de LTE en el corto plazo. Adems, incluso en el caso
de total cobertura LTE en la red de un operador, hay que tener en cuenta que podra ser necesario en
caso de roaming sobre redes de operadoras que an no tienen cobertura total de LTE o IMS. 3GPP
defini SRVCC (Single Radio Voice Call Continuity), como el mecanismo para mover llamadas activas
de LTE a 2G/3G. SRVCC emplea una nica tecnologa radio al mismo tiempo LTE o 2G/3G-, en vez de
dos tecnologas activas al mismo tiempo, con el fin de preservar la batera del dispositivo. El handover
requiere una latencia muy baja -inferior a 300 ms-, para conmutar las llamadas entre redes de acceso,
con el fin de incrementar el porcentaje de xito. En 3GPP R10 se definen dos funciones de IMS nuevas,
ATCF (Access Transfer Control Function) y ATGW (Access Transfer Gateway), que pueden ser
integradas en el SBC/P-CSCF/E-CSCF/IMS-AGW de la red de acceso del usuario, lo cual asegura que
el handover es mucho ms rpido, eficiente y fiable, que en las R8 y R9.

284
285
286
287
288
289
In a VoLTE call, the bearer is associated with a QoS Class Identifier (QCI) of 1. QCI values from the
3GPPs TS 23.2032 are shown in the Table. Each is generally targeted to a specific service type based
on delay and packet loss requirements. For example, a video telephony call might add a second
dedicated bearer for video traffic, assigning a QCI of 6 to that bearer.

290
291
292
Flujo multicapa para una llamada VoLTE
Any discussion of IMS protocols must start with a
dialogue describing the procedures being
implemented. It is important to note that there is no
one size fits all procedural flow; IMS in LTE offers a
lot of flexibility to both network equipment
manufacturers and network operators. Note that the
processes described here are strictly from the UEs
point of view, without discussion of the many intra-
network procedures required to make the system
work.
The processes involved in a Voice over LTE (VoLTE)
call can provide a meaningful background and a fairly
typical scenario. From the UEs point of view the initial
step is to listen for system information in the form of
Master Information Blocks (MIBs) and System
Information Blocks (SIBs). Once that information has
been processed the UE can initiate its own processes.
These processes are outlined in the next section. The
graphical depiction in the figure is not meant to
distinguish between multiple protocol layers; it is
merely an intuitive impression of the required
processes.

293
As in legacy 3GPP technologies, the UE starts connection by issuing a Radio Resource Control (RRC)
Connection Request. Note that while either the UE or the network can trigger the connection request, it is
always initiated by the UE. This request includes both the UE identity information and the call
establishment cause (i.e. Mobile Originating Signaling or Emergency). Assuming there are no issues, the
network responds with an RRC Connection Setup message.
The procedure thus far has established a signaling bearer and a Dedicated Control Channel (DCCH).
Once in RRC Connected mode, the UE responds by sending an RRC Connection Setup Complete
message which includes the Attach request for PDN connectivity. While this part of the connection is
familiar to those versed in 3G technologies, it is worth noting that at this point, unlike in a legacy UMTS
system, the initial NAS message has already been delivered to the Mobility Management Entity (MME). In
the case of a VoLTE call this message would be an Attach Request.

294
Now that NAS signaling is established, the network initiates an Authentication Request or challenge.
Once the UEs Authentication Response is deemed valid, the network sends a NAS Security Mode
Command. Note that while neither the Authentication Request nor the Authentication Response is
integrity-protected, the Security Mode Command is protected. The UE then sends a Security Mode
Complete message, establishing protected NAS signaling.
In order to protect EPS Session Management (ESM) information, the network now sends an ESM
Information Request; the UE reacts with an ESM Information response describing the now-protected
protocol configuration options.

295
At this point, additional radio bearers must be set up. The network sends an RRC Connection
Reconfiguration to activate the EPS bearer. The UE confirms successful completion with an RRC
Connection Reconfiguration Complete message and then finalizes the Attach procedure and accepts the
activation of the EPS bearer.
It should be noted that the way a default PDN is associated to an IMS device varies per the network
operator. In some networks, powering on a device will cause it to attempt to establish a connection with
an Internet PDN. In this case the device will only establish IMS connectivity when an IMS application
needs to be serviced. A device used on another network will, on powering up, attempt to establish a
connection with an IMS PDN, and display a No Service message if the connection is not made.

296
297
After Authentication, Security and UE Capability requests, the network accepts the Attach request and
activates the EPS bearer context. Once that has happened and the UE has also established a PDP
context, a typical IMS SIP client registration (Figure 4) begins:
1. The IMS client attempts to register by sending a REGISTER request to the P-CSCF.
2. The P-CSCF forwards the REGISTER request to the I-CSCF.
3. The I-CSCF polls the HSS for data used to decide which S-CSCF should manage the REGISTER
request. The I-CSCF then makes that decision.
4. The I-CSCF forwards the REGISTER request to the appropriate S-CSCF.
5. The S-CSCF typically sends the P-CSCF a 401 (UNAUTHORIZED) response as well as a challenge
string in the form of a number used once or nonce.
6. The P-CSCF forwards the 401 UNAUTHORIZED response to the UE.
7. Both the UE and the network have stored some Shared Secret Data (SSD), the UE in its ISIM or
USIM and the network on the HSS. The UE uses an algorithm per RFC 33101 (e.g. AKAv2-MD5) to
hash the SSD and the nonce.
8. The UE sends a REGISTER request to the P-CSCF. This time the request includes the result of the
hashed nonce and SSD.
9. The P-CSCF forwards the new REGISTER request to the I-CSCF.
10. The I-CSCF forwards the new REGISTER request to the S-CSCF.
11. The S-CSCF polls the HSS (via the I-CSCF) for the SSD, hashes it against the nonce and determines
whether the UE should be allowed to register. Assuming the hashed values match, the S-CSCF
sends 200 OK response to the P-CSCF. At this point an IPSec security association is established
by the P-CSCF.
12. The P-CSCF forwards the 200 OK response to the UE.

298
Each element described therefore has a unique set of roles in this arrangement:
The UE initiates the registration sequence, attaches to the LTE network and activates the PDP
context. It discovers which P-CSCF to use, then makes a deliberately unauthenticated registration
attempt. It waits for the expected 401 response, extracts the nonce from the response and hashes it
with the SSD before including the result in a second REGISTER request.
The P-CSCF, typically resident in the visited network, acts as the UEs gateway into the UEs home
network. It identifies the home IMS network, routes traffic to and from the home IMS network and
establishes the IPSec security association.
The I-CSCF, typically resident in the home network, acts as the front-end of the home IMS. It
interfaces with the P-CSCF in the visited network and selects the S-CSCF (by querying the HSS).
The S-CSCF, typically resident in the home network, handles the registration request from the I-CSCF,
pulls authentication vectors from the HSS and passes them to the P-CSCF (via the I-CSCF), and
authenticates the user in the second registration attempt.

299
SIP Registration flow

The initial registration procedure consists of the UE sending an unprotected SIP REGISTER request to the P-CSCF.
The UE can register any of its public user identities with any IP address acquired by the UE. A user can associate
different user identities with different IMS services by including the designated ICSIs (IMS communication service
identifier, see below). The P-CSCF then determines the appropriate I-CSCF of the UEs home network using the
user identity the subscriber wants to register. The P-CSCF may use either preconfigured entries or DNS procedures.
The I-CSCF then contacts the HSS. The HSS stores user preferences and settings and checks whether the user is
already registered or whether the user may register in that P-CSCF network. The HSS also stores the associated S-
CSCFs. An SCSCF can be associated with different services and is selected depending on the service to be used.
The S-CSCF serves to authenticate the user. The authentication and key agreement (AKA) algorithm known as in
UMTS is used to authenticate and generate keys. The S-CSCF acquires the necessary keys from the HSS. Via I-
CSCF and P-CSCF it returns an authentication challenge to the UE in the form of a negative reply (401
Unauthorized) to the initial SIP REGISTER request. As soon as the UE has correctly responded to this challenge
with another SIP REGISTER request, it has been successfully registered in the IMS, which the S CSCF confirms by
a positive reply.
Starting with the second SIP REGISTER, all SIP messages can now be protected forintegrity and confidentiality as
these keys were derived during the AKA procedure.
According to the IMS profile stipulated in GSMA document IR.92 [14], support of integrity protection is required for
both the UE and the network, while confidentiality protection is optional, as lower layer security is available.
Internet Protocol Security (IPsec), is a protocol providing secure IP communication. It is used to secure SIP traffic
between the UE and the P-CSCF. The only messages sent unprotected in the message flow in Figure 17 are the
initial SIP REGISTER and the 401 (Unauthorized). IPsec is based on the user authentication described above and
involves the establishment of security associations between the UE and the PCSCF that define how the
communication shall be secured, e.g. algorithms and keys to be used.
IMS authentication is based on the ISIM (IP multimedia services identity module). The ISIM is an application on the
universal integrated circuit card (UICC) smart card, containing parameters for user identification and authentication.
The ISIM is preconfigured with all necessary parameters to initiate IMS registration and authentication. These
parameters include:
the private user identity to identify the users subscription (comparable to the function of the international mobile
subscriber identity (IMSI) used in legacy systems)
one or more public user identities to identify the user

300
Suppose the UE now intends to monitor a specific registration event. In this context an event may be a
callback (to provide audio for a shared web event, for example) or an update to a buddy list or a
message waiting indicator. In general, this means that the UE is asking to be notified any time there is a
change in registration status and it requires cooperation between two end nodes. It is an essential part of
IMS since it enables the concept of subscriber presence.
The UE will begin the transaction using the SUBSCRIBE method. This method, defined in RFC 3265, is
one of the many SIP extensions used in IMS. This is basically a request to be notified (for a specified
period of time) of a change in resource state. As is shown in the call flow section later in this document,
the eventual response is a NOTIFY method indicating that there has been a change in status.

301
The initial stages of setting up a VoLTE call are the processes of the initial attach, P-CSCF
discovery and creating the default bearer for SIP signaling (by registering with the IMS network
and subscribing to a registration event package).
The first step in a VoLTE call setup is a SIP INVITE request initiated by the calling UE. Following
this step, agreement is made on the media-specific parameters such as codecs (e.g. AMR or
WB-AMR). After some RINGING, TRYING and OK messaging, the calling UE may respond with
a Provisional ACK (PRACK) method as shown in the flow diagram above and as defined in RFC
3551. The PRACK method is used because ACK cannot safely traverse proxy servers that
comply with RFC 3261. The PRACK is also forwarded to the called UE. When the called
subscriber answers the call, the called UE will respond with a 200 OK before the RTP (media)
messaging begins.

302
Operational Requirements for IMS Voice and Conversational Services
Three key operational requirements have been identified:
1. Routing of media for Voice & video over IMS (VoIMS; includes IR.58, IR.92 and IR.94) when call
originator is Roaming should be at least as optimal as that of current Circuit Switched (CS) domain.
2. The charging model for roaming used in CS domain shall be maintained in VoIMS.
3. Allow the HPMN to decide, based on service and commercial considerations & regulatory obligations,
to enforce the routing of the traffic to itself (home routing).

A solution to the first requirement necessitates that the user plane is not routed towards the HPMN of the
A party (unless so desired by HPMN A). When the GRX/IPX network is used as the interconnect network,
the addressing requirements specified in IR.34 and IR.40 need to be followed. With this in mind,
architecture is illustrated in the Figure.
Note 1: Although illustrated as a stand-alone element in the diagram above, the TRF has been defined
as a functional element rather than a new network node.
Note 2: The figure does not depict the interface between UE and the network (Ut reference point).
The second requirement is met by the deployment of P-CSCF (Proxy-Call Session Control Function)
functionality in the VPMN and use of Transit and Roaming Function (TRF) which receives the call related
signalling after it has been processed by the A party HPMN (VPMN Routing). This allows the A party
VPMN to send both control and user plane towards the destination and therefore replicate the current CS
voice roaming model. Optimal Media Routing (OMR) is used to prevent the user plane to be routed to
HPMN A during the set up signalling loop from VPMN A to HPMN A and back to VPMN A. The TRF, P-
CSCF, together with Packet Data Network Gateway (P-GW) and Billing Mediation, deliver the charging
information needed for the VPMN to generate TAP3 records. 3GPP TS 23.228, TS 32.260, and 3GPP TS
32.275 provide further details.

303
The last requirement is met by supporting home routing according to the architecture in the
figure where the media is not optimized and is routed through HPMN A (Home Routing). The
routing decision is performed by the HPMN A in the S-CSCF (or the BGCF).

304
 SRVCC: Sus Beneficios

The benefits of SRVCC

As an all-IP transport technology using packet switching, LTE introduces challenges to satisfying established quality of service
expectations for circuit-switched mobile telephony and SMS for LTE-capable smartphones while being served on the LTE
network.
In many cases, operators build and expand their LTE networks gradually, adding cells and capacity in line with their business
plans and subscriber demand. As a result, LTE networks and the VoLTE services built on top of them must be able to coexist
with legacy CS networks and to ensure handover to the legacy CS network when LTE coverage is insufficient. Since LTE and
VoLTE services are a fundamental part of next-generation mobile networks, voice handover to legacy CS systems is a key
capability while LTE coverage continues to be spotty.
The central challenge during the transition from todays hybrid networks with gaps in LTE coverageboth within single operator
networks and across roaming agreement multi-operator networksto an all-LTE network environment, and consequently all-
VoLTE voice call environment, is transferring voice calls already in progress between LTE packet switched VOIP to legacy
2G/3G circuit switched voice, without compromising these established quality of service levels available in legacy networks
today.
As noted before, in the first phase of voice evolution, all native voice calls are handled in the CS network. The LTE (PS data)
connection falls back to the legacy 2G/3G CS voice network connection prior to initiation of a voice call.
In sharp contrast, a VoLTE call must be transferred from the LTE PS network to the legacy CS voice network while the call is in
progress, while satisfying existing user experience expectations for minimal call interruption and low call drop rates. This
handover needs to be well engineered with performance levels comparable to the Inter-Radio Access Technology (IRAT)
handover procedures for voice calls available in CS networks today. These established QoS standards are less than 0.3
seconds voice interruption time and call drop rates under one percent.
SRVCCSingle Radio Voice Call Continuityis the solution to this requirement for voice call continuity, and uses a single radio
in the users device along with upgrades to the supporting network infrastructure. This solution transfers VoLTE calls in progress
from LTE to legacy voice networks, while meeting the rigorous QoS standards. Additionally, SRVCCby ensuring voice call
continuitysatisfies critical requirements for emergency calls.
Without SRVCC, operators with gaps or weaknesses in LTE coverage (or offering roaming in non-LTE networks) cannot realize
the user experience and network efficiency advantages offered by VoLTE until LTE coverage is built out to match the full
geographic range of their subscriber service commitments.
With SRVCC, operators can accelerate time to market and realize these benefits during the entire time span from todays hybrid
network environments to the all-LTE environment of the future.
SRVCC network architecture
Since its initial specification in 3GPP Release 8, SRVCC has evolved continuously. To ensure interoperability of the various
implementations with legacy networks, the GSMA has provided a set of guidelines for SRVCC (GSMA IR.64 [4]), detailing the
requirements for networks and user devices. SRVCC provides continuity for PS to CS handover between LTE and
WCDMA/GSM networks and from LTE to CDMA networks (GSMA TS.23.216 [3]).
GSMA guidelines recommend 3GPP Release 10 architecture for SRVCC (shown in Figure 3), because it reduces both voice
interruption delay during handover and the dropped call rate compared with earlier configurations.
The network controls and guides the user device from LTE to 2G/3G as the user moves out of LTE coverage. The SRVCC
handover mechanism is fully network controlled and calls remain under control of the IMS core network, which maintains access
to subscribed services implemented in the IMS/MMTel service engine before, during and after the handover.
The Release 10 configuration includes all components needed to manage the time-critical signaling between the users device
and the network, and between network elements within the serving network, including visited networks during roaming. As a
result, signaling follows the shortest possible path and is as robust as possible, minimizing voice interruption time caused by
switching from the PS core to the CS core, whether the users device is in its home network or roaming. With the industry aligned
around the 3GPP standard and GSMA recommendations, SRVCC-enabled user devices and networks are interoperable,
ensuring that solutions work well in all important call cases.

305
Network upgrades
As with any new handover technologies, SRVCC requires additional functionality in both the source
(LTE) system and the target (legacy) system.
SRVCC functionality can be added to the network by software updates of the MSS subsystem, the IMS
subsystem and the LTE/EPC subsystems. No upgrades are required to the legacy GSM/WCDMA RAN
target radio access.
Only a fraction of the installed base of Mobile Switching Center Servers (MSC-S) requires an upgrade to
support well-functioning SRVCC. Where these servers are clustered in poolsthe recommended
architecture for the CS coreonly the pools in the vicinity of the LTE coverage area need to be upgraded
to achieve good performance. Additionally, only two servers in each pool need to be upgraded, with the
second server upgraded primarily for backup redundancy.
Where it is not possible to upgrade a deployed MSC-S, either inside or outside a server pool, a dedicated
MSC-S can be added to handle the SRVCC function with minimal impact on performance.

306
When a user on an active voice call using VoLTE moves into an area without LTE coverage, the
handover of the call to the CS network is accomplished with two steps: IRAT handover and session
transfer. IRAT handover is the traditional handover of the users device from LTE radio access to
WCDMA/GSM radio access. Session transfer is a new mechanism to move access control and voice
media anchoring from the LTE Evolved Packet Core (EPC) to the legacy CS core.
During the entire voice handover process from LTE to 2G/3G, the IMS/MMTel retains control of the user.
The handover process is initiated by a session transfer request to the IMS/MMTel.
The IMS/MMTel responds simultaneously with two commands, one to the LTE network and one to the
2G/3G network. The LTE networkon which the users voice call is in progressreceives an IRAT
handover execution command through the MME and the LTE RAN to the instruct the users device to
prepare to move to the CS network for the voice call. The CS networkwhere the users voice call is
being sent receives a session transfer response, preparing it to accept the call in progress. With
acknowledgements that the commands have been executed, the users device and the IMS/MMTelstill
in control of the users voice call in progressswitch to the CS network to continue the call.

307
308
Call retention
Since the aim of SRVCC is to greatly reduce the number of dropped voice calls caused by users moving in
and out of LTE coverage, the SRVCC mechanism must work not only for ordinary voice callsthe bulk of the
trafficbut also for the small yet vital volumes of emergency calls. It must support the deployment of an LTE
network in line with network operators business strategies and subscriber demand, and should support voice
handover to and from VoLTE and CS telephony over 2G/3G access.
To meet these requirements, the SRVCC specification is designed to provide good call retention in the
following scenarios:
During the active phase of a call, including IMS emergency calls
During the call initiation alert phase, with handover executed when a user initiates an outgoing call or
receives an incoming call
During an inactive (on hold) call, both with and without an active call
While participating in a conference call
While on an IMS-based video call, maintaining voice stream continuity while (under current specifications)
allowing video streaming to end during SRVCC handover
The call retention rate is the percentage of successfully completed calls for a given user. Since SRVCC can
happen only once per call, and some calls may include both SRVCC handover and other handovers, the
SRVCC handover success must be higher than the total call retention target rate. With legacy voice call
retention rates typically higher than 98%, SRVCC handover is targeted to be successful more than 99% of the
time.
Accurate evaluation of call retention requires a statistically significant amount of data over a variety of different
real-world radio conditions. Such volumes of data for SRVCC handover are, expectably, not yet available. An
indication of call retention probability can, however, be obtained by examining similar systems. As with service
interruption time, call retention probability is dependent on two factors:
The probability of IRAT handover failure, and
The probability of session transfer failure
IRAT handover failure occurs more frequently in real-world deployments than session transfer failure, so this
measurement is a better predictor of call retention probability. From a reliability perspective, SRVCC handover
to WCDMA is similar to WCDMA inter-frequency handover (IFHO). The time to do the handover preparation of
the target WCDMA cell is also the same. So call statistics for IFHO may provide some insight into the
expected call retention rate for SRVCC.
Based on data collected from existing commercial deployments, the percentage of successful handovers for
IFHO in well-planned networks is in the 98% to 99% range. Most of the calls for which handover fails return
successfully to the original cell and continue, so the actual failure rate is typically significantly less than 0.5%.
Given its similarity to IFHO, similar statistics are likely for SRVCC. Should call retention become a problem in
certain network coverage areas, call retention might be improved by tuning handover parameter settings.
Additionally, as an early indicator, testing to date using Ericsson commercial products and Qualcomm test
phones with commercial chipsets has already demonstrated SRVCC handover success rates greater than
99%.

309
In this scenario, the SRVCC nodes on the target CS network and IMS network are enhanced with
additional capabilities to support smooth transition of the UE from LTE to 3GPP UTRAN/GERAN based
networks (e.g. 2G/3G).
MSC Server, is enhanced with the following features:
a. Employed alongside the MME in LTE network through the Sv reference point.
b. Mainly comprises the call control (CC) and mobility control parts of an MSC. The MSC Server is
responsible for the control of mobile-originated and mobile-terminated CC CS Domain calls for medial
channels in the CS-MGW (Media Gateway). It terminates the user-network signaling and translates it
into the relevant networknetwork signaling, i.e., SIP Signaling in IMS and vice versa.
c. For SRVCC, the MSC Server provides the following functions as needed:
i. Handling the Relocation Preparation procedure requested for the voice component from the
MME via the Sv interface.
ii. Invoking the session transfer procedure from IMS to CS. This involves the access transfer at the
IMS level of one or more of session signaling paths and associated media flow paths of an
ongoing IMS session.
iii. Coordinating the CS Handover and session transfer procedures.
Session Centralization and Continuity Application Server (SCC AS) is present in the IMS network and
provides the following functionality in support of SRVCC:
a. Required to enable IMS Centralized Services. The ICS User Agent (IUA) function furnishes SIP UA
behavior on behalf of the UE for setup and control of IMS sessions using CS bearers that are
established between the UE and the SCC AS.
b. For executing and controlling the session transfers needed by the UE for its access legs anchored in
IMS.

310
Sealizacin para SRVCC sin DTM

311
Cuando un UE se mueve en la red, puede llegar a un punto donde la cobertura LTE disminuya y un traspaso
SRVCC se debe realizar a CS 2G 3G. El requisito principal para el traspaso SRVCC es proveer continuidad de
servicio o por lo menos continuidad de sesin. La continuidad de servicio significa que despus de que una sesin
en curso se ha trasladado a la red 2G/3G, todos los servicios siguen funcionando de una manera que es
transparente para el usuario. La continuidad de sesin significa que todas las sesiones se conservan durante el
traspaso, aunque algunos de los servicios se vean comprometidos. El traspaso SRVCC usualmente satisface los
requisitos de continuidad pero en algunos casos en el Release 8 puede tumbar las sesiones (falta de continuidad de
sesin) o reducir las capacidades de servicio (falta de continuidad de servicio). En este caso se analiza un flujo de
llamadas para SRVCC desde LTE a 2G sin soportar DTM (Modo de transferencia dual). El flujo requiere que el
eNodeB pueda determinar que el destino es 2G sin soporte de DTM o que el UE no tiene soporte DTM.
En este escenario el MSC destino no tiene que ser mejorado para SRVCC. Si el servidor MSC controla el BSS
destino, no se ejecutan los pasos que se muestran con lneas punteadas representando el procedimiento de
traspaso MSC-MSC y las funciones del servidor MSC se fusionan con las de la MSC destino.
Las lneas rojas en la figura indican la ruta de la voz antes del traspaso, que pasa por el subsistema IMS y despus
se enruta al UE a travs del S-GW y eNodeB. Las lneas amarillas indican la ruta de la voz despus de que se ha
completado el traspaso. Durante una sesin activa de voz el UE, por orden del eNodeB toma medidas de la celda
LTE en que se encuentra y cuando se reduce la fuerza de la seal de LTE, el UE mide el nivel de seal en las
celdas 2G vecinas. El UE transmite los reportes de las mediciones al eNodeB y estos reportes son la entrada a los
algoritmos de decisin de traspaso. La celda LTE que sirve al UE conoce si el UE est habilitado para SRVCC, si
el UE tiene una llamada de voz activa. Basndose en esta informacin, la celda LTE que sirve al UE decide cundo
un traspaso SRVCC es necesario y selecciona la celda de destino 2G, que en este caso puede soportar nicamente
servicios de voz en el dominio tradicional CS. Cuando se toma la decisin de traspaso SRVCC, el eNodeB enva un
mensaje de traspaso requerido al MME, este mensaje tiene una indicacin de traspaso SRVCC que le indica al
MME que es una operacin de traspaso SRVCC solamente hacia el dominio CS. Y el mensaje incluye una
indicacin de que el UE no esta habilitado para el servicio PS en la celda de destino. Luego para una conexin
simultnea de voz y datos no vocales, la MME separa los portadores de voz de los portadores que no son de voz,
basado en el QCI asociado con el portador de voz (QCI = 1) y la indicacin de traspaso SRVCC y hace la solicitud
de traspaso PS a CS al servidor MSC. El servidor MSC enva un mensaje de solicitud de preparacin de traspaso al
MSC destino y esta enva el mensaje de solicitud de traspaso al BSS, quien responde con una confirmacin de la
solicitud de traspaso al MSC destino y hace la reserva de los recursos en el lado destino. La MSC destino enva un
mensaje de respuesta de preparacin de traspaso al servidor MSC y se establece el circuito de conexin entre la
MSC destino y la MGW asociada con el servidor MSC.
Despus el servidor MSC inicia el procedimiento de transferencia de sesin hacia el IMS, que es una solicitud de
una nueva llamada de voz hacia un nmero especial, STN-SR. El servidor MSC incluye el C-MSISDN como el
nmero que llama. Despus la S-CSCF enruta la solicitud de llamada al AS SCC, el cual correlaciona el STN-SR
recibido con la sesin de voz entre el UE y el extremo remoto. La recepcin de una solicitud de nueva llamada es
una seal para el AS SCC de que la sesin de voz asociada IMS debe ser redireccionada al servidor MSC, por lo
tanto esto activa el procedimiento de transferencia de sesin IMS. Durante la ejecucin de este procedimiento, el
extremo remoto es actualizado con nuevos detalles de contacto SDP (Protocolo de descripcin de sesin) y el flujo
de enlace descendente de paquetes de voz es reenviado al MGW asociado con el servidor MSC. La MME recibe el
mensaje de respuesta de SRVCC PS a CS del servidor MSC y el BSS de destino enva a travs de la MME al
eNodeB, la informacin necesaria para el comando de traspaso (contenedor transparente destino a origen),
incluyendo informacin nicamente sobre el componente de voz. El eNodeB le enva al UE el comando de traspaso
desde LTE y despus el UE ajusta los canales de radio al sistema destino 2G. Cuando el DTM no es soportado y
despus de que ocurre la deteccin de traspaso en la BSS destino, el UE realiza un procedimiento de suspensin
para notificar a la red de destino que los portadores PS tienen que ser suspendidos por un tiempo predeterminado.
En el procedimiento de suspensin el UE enva un mensaje de suspensin (TLLI, RAI) al BSS y el BSS puede
terminar cualquier portador que no sea de voz para esta TLLI. Despus el BSS enva un mensaje de suspensin
(TLLI, RAI) al SGSN.
La TLLI (Identidad de enlace lgica temporal) y la RAI (Identidad de rea de enrutamiento) son derivadas desde la
GUTI (Identidad de UE temporal nica global) y esto activa al SGSN de destino para que enve un mensaje de
notificacin de suspensin a la MME. Despus la MME retorna una respuesta de suspensin al SGSN de destino.
La MME puede suprimir el traspaso de un portador que no es de voz durante el procedimiento SRVCC y esto
ocurre si el sistema 2G de destino no soporta la funcionalidad de voz y datos simultneos (DTM).

312
Para dirigirse a los recursos utilizados para GPRS, se utiliza una TLLI, que es construida por el suscriptor mvil
por el SGSN, ya sea sobre la base del P-TMSI (TLLI local externo), o directamente (TLLI aleatorio auxiliar). El
P-TMSI (Identidad temporal de suscriptor mvil - paquetes) es una identificador temporal emitido a un mvil
habilitado para GPRS, nico dentro de una RA (Routing Area) y es utilizado por la red GPRS para buscar el mvil
especificado. La RAI est compuesta por una LAI (Identidad de rea de localizacin) y por un RAC (Cdigo de rea
de enrutamiento) que es un cdigo para identificar un rea de enrutamiento dentro de un rea de localizacin. La
GUTI es un identificador nico global que apunta a un contexto de suscriptor especfico en una MME especfica, es
decir a las capacidades de voz del UE y a los ajustes recibidos como parte de la capacidad de red del UE. El BSS
debe almacenar la TLLI y la RAI con el fin de solicitar al SGSN que reanude los portadores suspendidos que no son
de voz, cuando el traspaso para el portador de voz se ha completado y el UE se mueve al lado de destino 2G.
Despus del procedimiento de suspensin, la RNS/BSS enva un mensaje de reubicacin/traspaso completado al
MSC de destino. Si la MSC destino no es el servidor MSC, entonces la MSC destino enva un mensaje de traspaso
completado al servidor MSC. El servidor MSC enva al MME un mensaje de notificacin de SRVCC completado PS
a CS, informndole que el UE ha llegado al lado destino. Si el IMSI es desconocido en el VLR, el servidor MSC
realiza un procedimiento de actualizacin de localizacin MAP al HSS/HLR y si varios MSC/VLRs sirven al mismo
LAI, el servidor MSC realiza una reasignacin TMSI (Identidad temporal de suscriptor mvil) hacia el UE, ya que la
lgica es asignar al usuario que acaba de transferir, un LAI que este bajo control nico de esa MSC, para no
actualizar el resto de VLRs.
La MME desactiva los portadores usados para voz y otros portadores GBR (Velocidad de bit garantizada, que es la
velocidad de bit mnima solicitada por una aplicacin), para este caso en que no se soporta DTM. Todos los
portadores GBR son desactivados borrando el contexto de portador GBR en la MME y S-Gw/PDN-Gw. El indicador
de traspaso PS a CS es notificado al PDN-Gw para el portador de voz. La MME tambin suspende los portadores
no-GBR (no garantizan ninguna velocidad de bit particular, como los usados para web browsing) hacia el S-
Gw/PDN-Gw. Y la MME almacena en el contexto del UE, que el UE esta en estado suspendido. Si el eNodeB de
origen decide dar por terminado el procedimiento de traspaso antes de su finalizacin, la MME/SGSN se vuelve al
estado que tena antes de que el procedimiento de traspaso fuera activado. La MME/SGSN intenta activar, en el
servidor MSC, los procedimientos de cancelacin de traspaso. El servidor MSC no tomar ninguna accin
especfica SRVCC hacia IMS. A travs de la interfaz Sv van mensajes de notificacin de cancelacin SRVCC PS a
CS, desde la MME al servidor MSC para solicitar la cancelacin de un traspaso SRVCC en curso y mensajes de
reconocimiento como respuesta a la notificacin de cancelacin. Cuando la llamada de voz CS se ha terminado y si
el UE an est en 2G, el UE reanuda los servicios PS. El SGSN usa la interaccin basada en la interfaz Gn con el
GGSN y reanuda el contexto PDP. El SGSN usa la interaccin basada en la interfaz S4 con el S-Gw/PDN-Gw para
reanudar los portadores y adems informa al S-Gw/PDN-Gw que reanude los portadores suspendidos. Si el UE ha
retornado a LTE despus de que la llamada de voz CS fue terminada, entonces el UE reanuda el servicio PS
enviando una TAU a la MME. La MME adems informa al S-Gw/PDN-Gw que reanude los portadores suspendidos.

313
No Native Voice and SMS in LTE
While packet switched wireless networks have many advantages, there is also a major disadvantage: Voice
calls and SMS messaging, the main revenue generators of mobile network operators, are no longer available
in LTE, as they are based on a circuit switched radio and core network infrastructure. To counter this issue,
3GPP has so far adopted two different approaches:
1. Fallback to 2G or 3G for Voice
The first solution, designed to be available early on, is referred to as Circuit Switched Fallback (CSFB). As the
name implies it allows mobile devices to fall back to 2G or 3G networks for circuit switched services such as
voice calls. The main problems with this approach are longer call setup times which result in a significant
degradation of the user experience and the necessity for software upgrades on circuit switched network nodes
such as the Mobile Switching Centers (MSCs).
2. IMS As a Potential Solution For the Mid and Long Term
A solution envisaged for the mid and long term is to introduce network operator based voiceservices in LTE
with the IP Multimedia Subsystem (IMS). Development of this fully IP based platform for rich media
communication including voice calls begun many years ago for UMTS. Recently, enhancements have been
specified for handing-over ongoing IMS based voice calls to circuit switched networks such as GSM when the
user leaves the UMTS or LTEcoverage area during a call. Due to the significant complexity of the system,
however, it is likely that it will still take several years before large scale commercial IMS deployments will be
undertaken.
Voice over LTE via GAN
A third solution is Voice over LTE via Generic Access Network, or VoLGA for short, which is defined by the
VoLGA forum. Here, the concept is to connect the already existing Mobile Switching Centers to the LTE
network via a gateway.
As no fallback to a legacy network is required, call setup times are not increased and the user's quality of
experience is consistent with that of the 2G or 3G voice environment.

314
VoLGA in the Network
The Figure gives an overview of the basic network setup for VoLGA in the home network as described in
the Voice over LTE via Generic Access Stage 2 specification. For an easy start, the optional interfaces
that enable explicit quality of service in the LTE network and those required for handing over ongoing
voice calls to a circuit switched network are not shown. The only new network element introduced is the
VoLGA Access Network Controller (VANC), shown in green in the figure below. All other network
elements and the interfaces between them already exist and are reused without any modifications.
VoLGA from the LTE Network Point of View
On the LTE side, the VANC connects to the Packet Data Network Gateway (P-GW) via the standard SGi
interface. Both signaling and user data traffic (i.e. the voice packets) are transported over this interface.
From an LTE core network point of view the VANC looks like any other IP based external node and IP
packets exchanged between a wireless device and the VANC are transparently forwarded through the
Evolved Packet Core (EPC) network.
VoLGA from the Circuit Switched Network Point of View
On the circuit switched network side the A-interface is used to connect the VANC to a GSM Mobile
Switching Center (MSC). The Iu-interface is used to connect the VANC to the UMTS MSC. The VANC
thus looks like a GSM Base Station Controller (BSC) to a GSM MSC and like a UMTS Radio Network
Controller (RNC) to a UMTS Mobile Switching Center. Which interface is used in practice depends on the
requirements of the network operator. As the A and Iu interfaces are used without any enhancements, the
MSCs are not aware that the mobiles are not directly connected via their respective radio networks but
instead are connected over LTE. Consequently, no changes are required on these network nodes to
support voice, SMS and other services over the LTE network.
Registering to the Network
When a mobile device is switched on and detects an LTE network it first registers with the Mobility
Management Entity (MME) over the LTE access network. The MME uses the S6a interface to the Home
Location Register / Home Subscriber Server (HLR/HSS) to retrieve the subscriber data required for
authenticating and managing the user.
After registering with the LTE network, the mobile then establishes a connection to the VANC. How this is
done depends on the VoLGA specific configuration information stored in the mobile device. First, a
suitable IP connection needs to be in place. In the home network the default bearer might be used. It is
also possible to use a separate bearer and IP address for the purpose. The host name or IP address of
the VANC can be pre-provisioned in the mobile device or can be acquired by querying a Dynamic Host
Configuration Protocol (DHCP) server in the network over the bearer that was established for VoLGA in
the previous step. Once the IP address of the VANC is known, the mobile establishes a secure IPSec
tunnel to it over the LTE radio network through the LTE core network and over the SGi interface. During
the process the VANC authenticates the user with the help of authentication information stored in the
HLR/HSS, which it contacts over the D' interface.
Next, the mobile device registers to the MSC through the secure tunnel and the VANC. The Direct
Transfer Application Part (DTAP) protocol is used for this purpose, which is already known from GSM
and UMTS. Messages are tunneled transparently between the mobile device and the MSC by all network
components involved. Merely the VANC adds information such as a cell-id (2G) or the service area
identifier (3G) to the initial registration message as defined in the GSM and UMTS standards
respectively.

315
Flujo de mensajes para llamada saliente

The figure shows the signaling exchange to establish a mobile originated voice call over LTE. All
signaling and control plane messages between the UE and the VANC are transported over the
established IPSec tunnel. In a first step, the mobile device sends a message to the VANC to change the
connection from idle to dedicated state. Afterwards, a standard GSM/UMTS CM Service Request
message is sent to establish a connection to the MSC. When the VANC receives the message it creates
a dedicated signaling connection to the MSC over the A- or Iu interface for this user and forwards the
message. The MSC then usually authenticates the user and activates ciphering (step 4 and 5 in the
figure). Then, the mobile device sends a Setup message in step 6, which contains among other things,
the phone number of the person that is to be called. The MSC acknowledges the request with a Call
Proceeding message in step 7. As the MSC thinks of the VANC as a GSM Base Station Controller or
UMTS Radio Network Controller, it then sends an Assignment Request message to the VANC to request
the establishment of a circuit switched bearer channel. The VANC translates this message into an
Activate Channel message to the mobile device in step 9 to prepare it for the exchange of IP packets
containing voice data. Optionally, quality of service for the voice packets can be ensured by activating a
second bearer in the LTE network (step 11). This is further discussed below. Once the mobile device is
prepared for the voice data stream, an Assignment Response message is sent back to the MSC in step
13 to signal to it the successful 'pseudo establishment of a circuit switched channel in the radio network.
Once the call has been established with the other party, the MSC sends Alerting and Connect Messages
(step 14 and 15) which the mobile device acknowledges. The voice path is then established and the
voice conversation can begin.
The voice signal is either transmitted in a 64 kbit/s TDM timeslot on the A-interface in the case of a GSM
MSC or via an ATM or IP based data flow in the case of a UMTS MSC. The VANC translates this data
stream into IP packets for transmission over the LTE network and vice versa. The standardized Real-time
Transfer Protocol (RTP) is used for this purpose and this is the same RTP protocol that is also used by
many other voice over IP solutions such as those utilizing SIP and IMS.

316
Wi-Fi calling is closely aligned with VoLTE; it uses the same IMS telephony client, and supports
mobility between LTE and Wi-Fi accesses, making the resulting user experience a seamless
one. Handover of calls between LTE and Wi-Fi is enabled by routing Wi-Fi calling traffic to the
IMS through the Evolved Packet Core (EPC), which results in a scalable deployment opportunity
for network operators.
Wi-Fi access can be used for telephony services for several subscriber and enterprise scenarios.
However, the bulk of current implementations and the primary use case for Wi-Fi calling is to
complement indoor environments where cellular network coverage is limited. This use case may
also apply to small business premises. Operators are also considering using this technology to
provide users, traveling outside their home network, with access to the IMS telephony services
of their home network over Wi-Fi networks that are commonly found in hotels, airports, shopping
malls and cafs.
Wi-Fi calling offers users a simple solution for voice and video calls one that is fully integrated
with modern smartphones and does not require any additional apps or downloads. As such, the
introduction of Wi-Fi calling is expected to have an impact on the use of OTT VoIP solutions, as
well as fixed telephony offerings.

317
For the past decade Communications Service Providers (CSPs) have invested heavily in their network
infrastructure in order to manage the explosion of data traffic being generated. The roll out of Long Term
Evolution (LTE) networks and the move towards data centricity have been foremost in the thinking and
associated spending of CSPs. Voice services, despite continuing to account for a significant portion of
CSPs revenues, have taken a back seat in terms of focus and relevance and been reduced to
commodity status.
That is until recently. The roll out of voice over LTE (VoLTE) and Wi-Fi Calling is enabling operators to
use voice as a differentiator (e.g. HD voice with VoLTE and Wi-Fi Calling and access to voice in remote
and poor coverage locations with Wi-Fi Calling). Also the cost savings of migrating voice traffic from
circuit switched networks to LTE is significant. CSPs such as AT&T, Verizon and Singtel have
successfully launched VoLTE, while many more CSPs are in the process of rolling out or trialling VoLTE
on their networks.
With the prevalence of Wi-Fi networks, CSPs such as T-Mobile US, EE and Sprint are pioneering Wi-Fi
Calling as part of their core offerings to cost effectively improve coverage. A major benefit of Wi-Fi Calling
is that it uses a native dialer, so from the end users viewpoint its just the same as making a call on a
cellular network.
Wi-Fi Calling allows customers to make and receive phone calls over the Wi-Fi network. Wi-Fi Calling
originated with the birth and availability of voice over IP (VoIP) applications. The first generation of Wi-Fi
Calling experienced limited success, predominantly due to the fact that very few devices were enabled to
deliver the service.
Following technology advances, namely updating the native dialer on popular devices, which also
support Wi-Fi, the 2nd generation Wi-Fi Calling is experiencing substantial growth. Another contributing
factor is the shift in opinion on Wi-Fi networks. Previously, CSPs viewed Wi-Fi as a competing technology
that was cannibalizing their revenues but such thinking has evolved. Most CSPs are now embracing Wi-
Fi technology which is evident in the prevalence of Wi-Fi access points.

318
 60% Plus Houses have limited 2G, 3G or 4G coverage
Most offices have some limited coverage areas
Challenges around Adoption of Small Cell & DAS deployments
VoWiFi solves many coverage issues very efficiently and cost effectively

319
IP-based mobility management enables the UE to preserve IP address(es), even when the UE changes its point of
attachment to the network. There are two basic approaches to providing IP-based mobility management: network
based mobility management and client-based mobility management.In the case of network-based mobility
management, the network (e.g., access gateway), on detecting that the UE has changed its point of attachment,
provides the UE with the same IP address that it had at its previous point of attachment. The network entity providing
the IP address to the UE also handles updating the mobility anchor in the network so that the packets arrive at the
new point of attachment of the UE. The UE is not aware of the mobility management signaling within the network. In
contrast, for client-based mobility management, the UE obtains a new local-IP address (also referred to as care-of-
address) when it moves to a new point of attachment. It is then the responsibility of the UE to update its home agent,
which maintains a binding between the care-of-address and the home address of the UE.
3GPP has closely investigated the mobile operator requirements from a service aspect point of view. The
requirement to provide handover capability within and between access systems with no perceivable service
interruption has been identified. This means that the delay introduced by the mobility management procedure must
be minimized. Efficient use of wireless resources is another requirement for mobility management because wireless
resources could be a bottleneck. Finally, it is generally desirable to minimize UE involvement in mobility
management to improve the battery life of the terminal. Because network-based mobility management fulfills these
requirements well, PMIPv6 was adopted as the IP mobility protocol for mobility between 3GPP and non-3GPP
accesses and as an option for intra-3GPP access mobility. PMIPv6 introduces two new functional entities:
The local mobility anchor (LMA), the equivalent of a home agent, which is the topological anchor point for the home
network prefix(es) and manages the binding state of the mobile node.
The mobile access gateway (MAG), which acts as the proxy (foreign) agent for the terminal and handles the
mobility signaling (e.g., a proxy binding update) toward the LMA upon terminal movement.

320
The network architecture of the non-trusted EPC access is shown in the figure. It is the evolution of the
WLAN access to the 3GPP UMTS in Release 6, called I-WLAN, where the access to the 3GPP network
was over the Packet Data Gateway (PDG) network node to the GGSN, the 3G counterpart of the PDN
GW.
The I-WLAN architecture was adapted to the EPC in Release 8 with an evolved PDG (ePDG) connected
to the PDN GW. The ePDG is under full control of the EPC network operator and interfaces to the WLAN
via the SWn interface. It is an enhancement of the PDG adapted to the EPC with new functionalities
defined, e.g. for IP mobility. Both, network based and client based IP mobility architectures are supported
which shows up in using the S2b or S2c interface between the ePDG and the PDN GW, respectively. For
access authentication the WLAN gateway interacts with the EPC over the SWa interface to the 3GPP
Authentication, Authorization, and Accounting (AAA) server, or to the 3GPP AAA Proxy in the roaming
case. In order to get connection with the EPC, the UE has first to authenticate with the AAA (Proxy)
server. In a next step, a secure data tunnel (IPSec) between the UE and the ePDG has to be established
in order to set up a data path. Here, the ePDG acts as an authenticator and gets the required AAA related
parameters from the AAA server (proxy) via the SWm interface. In this part, Internet Key Exchange
Version 2 (IKEv2) signaling between the UE and the ePDG is used. When client based mobility is
applied, an additional IPSec tunnel between the UE and the PDN GW has to be established.

321
 Functionality defined for the PDG in TS 23.234 for the allocation of a remote IP address as an IP
address local to the ePDG which is used as CoA when S2c is used;
Functionality for transportation of a remote IP address as an IP address specific to a PDN when S2b is
used;
Routing of packets from/to PDN GW (and from/to Serving GW if it is used as local anchor in VPLMN)
to/from UE; if GTP based S2b is used, this includes routing of uplink packets based on the uplink
packet filters in the TFTs assigned to the S2b bearers of the PDN connection;
Routing of downlink packets towards the SWu instance associated to the PDN connection;
De-capsulation/Encapsulation of packets for IPSec and, if network based mobility (S2b) is used, for
GTP or PMIPv6 tunnels;
Mobile Access Gateway (MAG) according to the PMIPv6 specification, RFC 5213, if PMIP based S2b
is used;
Tunnel authentication and authorization (termination of IKEv2 signalling and relay via AAA messages);
Local mobility anchor within untrusted non-3GPP access networks using MOBIKE (if needed);
Transport level packet marking in the uplink;
Enforcement of QoS policies based on information received via AAA infrastructure;
Lawful Interception.
Allocation of downlink GRE key for each PDN connection within the ePDG, which is used to
encapsulate downlink traffic to the ePDG on the PMIPv6-based S2b interface.
Accounting for inter-operator charging according to charging principles specified in TS 32.240.
Interfacing OFCS through reference points TS 32.251 for EPC nodes.

322
323
324
325
326
327
The trusted WLAN access to the EPC is only defined from 3GPP Release 11 on. From an architectural
point of view, the main difference to the non-trusted access is the missing ePDG. Instead, the non-3GPP
network interacts directly with the EPC The PDN GW is connected over the S2a or S2c interface,
depending on the IP mobility. Due to the trust relationship, there is no need to set up an additional IPSec
tunnel between the UE and the EPC network, apart from the one used in case of client based IP mobility.
Connection to the AAA server is done over the STa interface. Whereas it is optional in the non-trusted
architecture to require a 3GPP based authentication, it is mandatory in the trusted one.
In both architectures, the trusted and the non-trusted, this authentication is independent of the WLAN
technology and is instead based on the EAP-AKA protocol. Authentication is based on USIM credentials
which are obtained by the 3GPP AAA server over the SWx interface from the HSS, together with
additional subscriber information needed.

328
Trusted Access makes use of the EAP-SIM and EAP-AKA authentication methods for authenticating
users using SIM card information, and supports simple, high-speed offloading to non-3GPP networks.
Untrusted Access supports secure communications using ePDG to provide access to carriers networks
via public networks. The two key technologies are authentication using EAP and secured
communications using ePDG.
EAP-SIM/EAP-AKA
EAP-SIM/EAP-AKA are UE authentication methods using the UE SIM card that make use of the
Extensible Authentication Protocol, which extends the older Point to Point Protocol standard used for
wired network authentication. The UE sends the SIM card information to the trusted non-3GPP access
AP and the AP queries the AAA server with Pass/Fail authentication (STa interface). The AAA server
compares the query with the user information saved at HSS and returns the authentication result to the
UE. The implementation of authentication functions EAP-SIM/EAP-AKA to the UE has been standardized
by the TS22 GSMA.

329
330
Abreviaturas

331
332
333
334
335
Referencias
Signaling in Telecommunication Networks, Second Edition
John G. van Bosse, Fabrizio U. Devetak
2007 John Wiley & Sons, Inc
GSM Switching, Services and Protocols, Second Edition
Hans-Jrg Vgel, Christian Bettstetter
2001 John Wiley & Sons, Ltd
GPRS Networks
Geoff Sanders, Lionel Thorens, Manfred Reisky, Oliver Rulik and Stefan Deylitz
2003 John Wiley & Sons Ltd
Mobile Messaging, Technolgies and Sercices, Second Edition
Gwenal Le Bodic
2005 John Wiley & Sons Ltd
CAMEL Intelligent Networks for the GSM, GPRS and UMTS Network
Rogier Noldus
2006 John Wiley & Sons Ltd
Next Generation Intelligent Networks
Johan Zuidweg
2002 Artech House
LTE: Nuevas Tendencias en Comunicaciones Mviles
Coord. Ramn Agustin Comes
2010 Fundacin Vodafone
LTE Signalling: Troubleshooting and Optimization
Ralf Kreher, Karsten Gaenger
2011 John Wiley & Sons Ltd
Voice over LTE
Miikka Poikselk, Harri Holma y otros
2013 John Wiley & Sons Ltd

336