Redes Celulares

CDR Un Call Detail Record o simplemente CDR es un archivo que posee la informacin detallada de una llamada realizada. Por cada llamada realizada existe su respectivo CDR con la informacin detallada del sistema que corresponde a esta llamada. Un CDR puede poseer la informacin de la celda donde se inicia la llamada y donde termina la llamada, pero sin duda debe poseer la informacin del nmero inicio y destino. Por supuesto como todo registro se obtiene una relacin del equipo que suministro la informacin as como fecha/hora. Principalmente se utiliza el CDR para determinar el cobro en un sistema postpago, sin embargo tambin puede darse otros usos. El ejemplo de CDR que tenemos a continuacin por ejemplo fue elaborado para un proceso criminal y en este caso sirvi como evidencia.

El CDR es generado una vez finalizado el proceso, es decir, cuando se finaliza la llamada. La plataforma encargada de monitorear y establecer el proceso mantiene en memoria la informacin necesaria y una vez terminado su ciclo genera el archivo CDR que es almacenado Como existen ms procesos que solo los de llamada, como por ejemplo SMS, RBT, WAP que tambin requieren de documentacin se aplica el mismo proceso extendido a estas plataformas, sin embargo, cada plataforma posee su informacin correspondiente

En la actualidad, cuando hablamos de CDR no podemos dar fe que este registro es de llamada, sino que puede ser de otro elemento de red el cual cumple con la funcin de registro SMSC... continuacion

Ahora que miro la informacin que corresponde para SMSC y veo la informacin la cual suministre ya 2 aos atrs, creo podra haber subministrado ms informacin A fin de continuar con un anlisis ms profundo y ms completo en relacin a esta plataforma vamos a verificar los tipos de mensajes de acuerdo a su inicio/destino Los posibles destinatarios o emisores de mensajes son Persona: Sera el telfono que posee todo usuario, es decir, es una lnea telefnica destinada para un usuario normal (del cual lo ms probablemente t seas uno) Aplicacin: Los mensajes de aplicacin son generalmente emitidos por aplicaciones, tal como puede ser un servidor o plataforma. Los mensajes de campaas de publicidad masivos o mensajes de notificacin de llamada perdida por el HLR/RBT pueden verse como mensajes de aplicacin As podemos clasificar a los mensajes como P2P (Persona a Persona): Envo de un mensaje de una persona a otro (el mensaje de texto ms comn) P2A (Persona a Aplicacin): Envo de mensaje de una persona a una aplicacin dentro de la red. Un ejemplo son las subscripciones a sorteo que en lo general son enviar un mensaje a un numero corto (auto al 611) A2P (Aplicacin a Persona): Envo de mensaje de una aplicacin a una persona. Un ejemplo es el envo de mensaje de notificacin del HLR cuando se llam al usuario y este tena el telfono apagado. Como comente en el post anterior, el proceso de envo de mensajes consta de dos parte: A)el envi del mensaje del inicio a la SMSC B) La remisin del mensaje de la SMSC al destino El primer paso es MO (Mobile Origination) y MT(Mobile Terminating) La seccin MO funciona del siguiente modo Al partir el mensaje del usuario A el mensaje llega a la red de acceso (puede ser BTS/BSC o NodoB/RNC) del mismo modo como lo realizan todos los mensajes hasta la MSC. La MSC es quien discrimina que tipo de mensaje es envindola a la plataforma que se encarga de los mensaje, la SMSC. Aunque no es parte del proceso de mensajes, es necesario que el usuario este registrado en la red. De este modo el MS(Mobile Station) debe haber procedido al Access Request y Autenticacin necesaria para cualquier usuario en la red. Se

realiza en un procedimiento el cual involucra al MS y VLR, donde el VLR tiene el perfil del HLR en su memoria (en caso de no tenerla, hace un pedido al HLR)

Posteriormente el terminal enva el SM mediante un Message Transfer al MSC que a su vez se comunica con el VLR para interrogar al mismo si el usuario posee los servicios necesarios para el envo de mensajes mediante un sendInfoFor-MOSMS.

De aqu en ms, el mensaje se encamina a la SMSC del abonado. Para lle SMSC se pasa por una SMS-IWMSC que luego enva un Message Transfer.

En este punto se debe pasar de una red a la otra mediante interconexin entre las SMSC. Es decir, el mensaje que posee una de las SMSC debe ser transferido a la SMSC del abonado B Podra ser un nube SMPP, o conexin directa. De aqu en ms la SMSC de destino debe determinar donde debe continuar el envo del mensaje En base a esto se realiza un requerimiento de ruta al HLR mediante un SRI_SM, el cual se responde con la informacin de ruta Finalmente el mensaje es enviado a la MSC/VLR al cual est registrado el abonado de modo a entregar el mensaje

IMS Plano de Control La funcion principal del Plano de Control es el establecimiento de sesiones entre usuarios. IMS es una arquitectura que responde al protocolo SIP y la mayora de los elementos pueden verse como una evolucin del SIP Proxy Server, cada uno de ellos tomando una regla del procesamiento de mensajes SIP. Los servidores de SIP llamados CSCF(Call Service Control Funtion) son definidos en tres elementos: P-CSCF(Proxy), I-CSCF(Interrogating) y S-CSCF(Serving)

De modo a mantener los principios escenciales del protocolo SIP se separan los planos de control y de media . En IMS es necesario que los terminales (UE User Equipment) poseean su propia IP para traficar, que a su vez ser el modo de establecer la conectividad IP requerida por el IMS. El P-CSCF es un nico punto de contacto con el Plano de Control del IMS para todos los IMS User Equipment (IUE). Toda los mensajes SIP enviado del IUE deben pasar por el P-CSCF hacia otro elemento del Plano de Control. El P-CSCF funciona como un firewall para tanto autenticacin como QoS. El UE debe ser poseer una direccin P-CSCF antes de poder registrarse al dominio del IMS. Esto puede darse manualmente o establecindose dinmicamente mediante procedimientos

DHCP/DNS o durante la creacin de un GPRS context. En el proceso de registro, el UE establecer una conexin segura con el P-CSCF para la sealizacin SIP El I-CSCF es el punto de entrada para el dominio administrativo. Cada requerimiento inicial perteneciente a este dominio ser recibido por el I-CSCF. Esto significa que un DNS pblico debe configurarse con el I-CSCF para cada dominio con punto de entrada preferido SIP. Como el I-CSCF ser publicado en un servidor DNS interno, este nodo puede ser de acceso externo al dominio. Tener en cuenta que este primer contacto con este dominio podra implementar features adicionales como THIG(seguridad),ALG(Aplication Level Gateway), etc. En este caso, puede reverenciarse al mismo como un elemento IBCF (Inner Border Gateway Control Function) El S-CSCF puede jugar el roll de registro SIP o interfase del Call Server con el Plano de Servicios y el servidor de aplicaciones. Como registro, debe autenticar a los usuarios y almacenar su direccin de contacto SIP de modo a identificar a los UE pblicamente. Con Call Server, debe asegurar el establecimiento del dialogo SIP e invocar los servicios correspondientes a la subscripcin del usuario. Por definicin, I-CSCF y S-CSCF estn localizados en el dominio administrativo del usuario mientras el P-CSCF puede localizarse en la red visitada por el usuario (esto en situacin de roaming). El S-CSCF es dinmicamente asignada a un usuario en el proceso de registro por el I-CSCF, de acuerdo a los criterios de la base de datos central. Adems de los servidores SIP se encuentran la base de datos central que provee informacin de usuarios. Esta base de datos es referida como HSS y puede ser vista como una evolucin del HLR. La informacin relacionada a permiso de establecimiento de sesiones, autorizacin y autenticacin estn contenidas en el HSS. El HSS ayuda al I-CSCF en el proceso de asignacin S-CSCF para un usuario entregando las capacidades requeridas al servidor. Aun SIP es el protocolo para creacin de sesiones, otros nodos de la red acceden al HSS utilizando Diamete, el cual es una evolucin del Radius. IMS - Capas El IMS es una arquitectura relacionada a la telefona mvil y fija, donde el fin es converger tanto las telecomunicaciones como la transmisin de datos ms estrechamente. La convergencia es llevar los circuitos conmutados a una tecnologa relacionada a IP, donde el pico de iceberg actualmente es el IMS. Para analizar el IMS podemos dividirlo en planos. Un plano de Servicios, un plano de Control y un plano de Media. Los planos de Media y Control se comunican mediante un plano Media Control plan basado en protocolos como MEGACO o H.248.

El plan de Media apunta generalmente a transportar un flujo de RTP y se compone principalmente de equipamiento IP (as como routers, switches o gateways). El plan de Control permite el establecimiento de protocolo SIP y tiene acceso a la informacin de todos los usuarios a modo a proveer autenticacin y services accouting. El plan de Servicios maneja como claramente lo indica su nombre a los servicios, y contiene todos los servicios de la plataforma IMS. La evolucin en esta capa o plan nos lleva a una reduccin de complejidad en la infraestructura permitiendo un menor tiempo de integracin. El IMS poseera el control de los distintos tipos de acceso donde la real convergencia depende en gran parte de la adaptacin basada en la red de acceso actual y las capacidades de terminal del abonado. Como abonado, el gran beneficio del IMS es la capacidad de la red de proveer los mismos servicios cualquiera sea la red de acceso utilizada. Esto es posible debido a la centralizacin de procesos de ejecucin. El Call Server del plano Control (llamado S-CSCF: Serving Call Service Control Funcion) es el responsable de invocar el servicio de aplicacin basado en los criterios relacionados base de datos central. El S-CSCF obtiene estos criterios (llamados Inicial Filter Criteria) durante el registro del abonado a la red IMS. Lo que es notable aqu es que el servidor esta siempre alocado en la Home Network (en la red origen del abonado) lo cual garantiza servicios de roaming pueden accederse en forma transparente. Festividades = Congestin Es un clsico en las fiestas de Ao Nuevo y Navidad poseer alta congestin. Es tan normal atravesar esta fase de congestin que ya enviamos saludos y

felicitaciones horas antes del pico de trafico el cual apunta a la medianoche an as, siempre existe esa necesidad de llamar por lo menos a esa persona especial a las 12 y por supuesto se manifiesta la congestin. Navidad y Ao Nuevo no son los nicos casos, toda conglomeracin de llamadas genera congestin. Ej: En grandes conciertos de rock en celdas en la zona. Aqu va la pregunta, bueno, porque existe congestin? Y sencillamente porque los sistemas de telecomunicacin no estn diseados para masivas llamadas simultaneas. Si lo pensamos bien, todo colapsa, los locales nocturnos colapsan, los taxis son insuficientes, los negocios abarrotados es decir, ningn sistema esta preparado para una estampida de gente requiriendo servicios. Podra un sistema de telecomunicaciones evitar la congestin de ao nuevo? La repuesta es s, pero no sera rentable La ejemplificacin ms clara sera comparar la congestin con un Local Nocturno. Supongamos este Local Nocturno tiene una capacidad de 1.500 personas. Durante el ao el promedio de personas que asiste los fines de semanas es 1.000, razn por la que existen espacios y comodidad debido a estar bien dimensionado para suministrar servicios. Ahora, en el Ao Nuevo el numero de personas que ingresa al local no son 1.000, no son 1.500 sino son 3.000 teniendo en cuenta existen 10.000 mas afuera esperando se de algo de espacio. Los 3.000 estn claramente disconformes pues no se puede dar un buen servicio a tanta cantidad y afuera 10.000 que daran el alma para estar dentro. Ahora, si expandimos al Local Nocturno a 13.000 personas no tendramos congestin de personas en Ao Nuevo, pero durante el ao los 1.000 clientes asiduos no ingresaran suficiente dinero para mantener una infraestructura para 13.000 personas. Es as como la congestin en Festividades es algo con lo cual debemos lidiar o sencillamente dejar a ir a los Locales Nocturnos en Ao Nuevo. Finalmente, si durante el ao existe congestin permanente en una zona es signo claro de expansin pero Ao Nuevo, Navidad y Festividades no responden a parmetros de planificacin. Voz Sobre LTE VoLTE Las especificaciones de la tecnologa LTE no se dan de modo a proveer voz sino apuntando hacia datos. Se proyecta de ese modo un servicio de voz ejecutado mediante la tecnologa VoIP. Los operadores sin embargo han visto a la voz por IP como una gran falta en el sistema, en parte por su falta de regulacin que desemboca por ejemplo en el servicio de Roaming y SMS. Siendo que en general el 80% del ingreso de los operadores moviles proviene de Voz y SMS, es necesario estandarizar estos escenarios de LTE. Papel de QoS en LTE A diferencia de las tecnologas de telecomunicaciones anterior (ej: CDMA, GSM y 3G), LTE no provee un canal dedicado para circuito conmutado de telefona. LTE

es un sistema full IP el cual provee conexiones IP del telfono mvil al core network. Esta comunicacin full IP puede ser dada mediante la estandarizacin VoIP. Como IP responde a paquetes donde no se prioriza uno de otro, en general se tienen un flujo de datos randomico para una transmisin. Sin embargo de modo a establecer un canal de voz debe asegurarse una taza de datos, y el asegurar esta taza de datos debe responder a un servicio de QoS(Quality of Service) disponible. Opciones de Voz Para LTE Existen desarrollos de modo a proveer a LTE con voz, de los cuales se han delineado los siguientes (3): 1- VoLGA Esta basado en el estandar 3GPP Generic Access Network(GAN) 2- CSFB (Circuit Switched Fall Back) Este sistema se enfoca mantener el escenario de llamadas en 2G y 3G, en este caso, cuando ingresa una llamada en LTE el telefono cambia a la tecnologa 2G/3G para recibirla. Esta especificacin permite llevar los SMS como se llevan hoy da. Todo esto es posible mediante una interfaz con los SGs y LTE en la que se envan los mensajes. 3- Voice over LTE, VoLTE basics Esta se basa en las especificaciones de el IMS, adoptando esta solucin para integrar un suite de aplicaciones. Para proveer el servicio VoLTE se debe definir 3 interfases: User Network Interfase (UNI): Esta interfaz esta alocada entre el equipo del usuario y el operador de red. Roaming Network Network Interfase (R-NNI): Es una interfaz entre la operadora Local y en la que se realizar el Roaming de modo a establecer una sealizacin. Interconnect Network Network Interfase (I-NNI): La interfaz entre operadoras que requieren establecer un canal de voz. En muchos aspectos VoLTE es una aproximacin de alto nivel as como directa, la cual requiere necesariamente de un core IMS.

Femtoceldas La idea de la Femtocelda es poseer pequeas celda para el hogar de modo a dar cobertura a una sola casa, donde anteriormente la celda ms pequea era la picocelda que cubra oficinas o un rea en particular. En general estn diseadas para proveer servicio a 10 usuarios en simultneo. La razn de la existencia en la Femtocelda es la atenuacin que generan las estructuras a las seales electromagnticas, lo que termina dejando prcticamente sin cobertura reas de un hogar. Aunque cada vez es menos frecuente, podemos en algunas ocasiones encontrarnos en edificios en los cuales el concreto nos deja fuera de servicio. Otro punto es que teniendo cobertura en estas estructuras la velocidad de interconexin a Internet puede verse comprometida pues se ve afectada en su tasa de transmisin. A los equipos en la casa del abonado se los denomina HNB(home Node B) que se encargan de la propagacin electromagntica. Toman la funcin de un Nodo B realizando la interaccin con los handset Ahora, estos equipos estn pensados para interactuar con los equipos de red celular (MSC,HLR,etc) por lo cual necesitan un enlace directo a la central. Este enlace se realiza mediante una conexin a Internet segurizada (IPsec) a un Gateway. Es decir, con tener conexin a Internet en nuestro hogar podemos contar con una femtocelda. El Gateway a la central celular es el FAP Gateway (FAP GW) que interactua con la HNB (uno o varios HNB) ingresando el tren de informacin a la interfase IuCs e IuPS que responden a la sealizacion con el Core Network. Debido a la irradiacin de seal que generan la Femtoceldas, podra darse el caso que cause interferencia, sin embargo, debido a la zona de cobertura limitada no es relevante a nivel macro. Uno de los puntos de inters es que las Femtoceldas solo tienen handover para afuera de su cobertura. Es decir, el handover posible es de la Femtocelda a un NodoB, del otro sentido no es posible. Una de las razones del HandOver Unilateral es que el handover debe ser definido especficamente en la red, por lo cual, existe una complicacin al definir handovers donde los CPE son de mucha movilidad. Finalmente veo a las Femtoceldas como una excelente alternativa inhouse, donde reemplazan a los repetidores que eran solo amplificadores de seal (como tambin amplificadores de ruido), ahora se tiene una interconexin para generar una seal limpia.