ES2833410T3 - Redes de telecomunicaciones - Google Patents

Redes de telecomunicaciones Download PDF

Info

Publication number
ES2833410T3
ES2833410T3 ES15700913T ES15700913T ES2833410T3 ES 2833410 T3 ES2833410 T3 ES 2833410T3 ES 15700913 T ES15700913 T ES 15700913T ES 15700913 T ES15700913 T ES 15700913T ES 2833410 T3 ES2833410 T3 ES 2833410T3
Authority
ES
Spain
Prior art keywords
savi
content
platform
application
cloud
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES15700913T
Other languages
English (en)
Inventor
Walter Bindrim
John Moughton
Adam Pollard
David Fox
Peter Cosimini
Matthew Cheng
Christopher Pudney
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vodafone IP Licensing Ltd
Original Assignee
Vodafone IP Licensing Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vodafone IP Licensing Ltd filed Critical Vodafone IP Licensing Ltd
Application granted granted Critical
Publication of ES2833410T3 publication Critical patent/ES2833410T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2592—Translation of Internet protocol [IP] addresses using tunnelling or encapsulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1013—Network architectures, gateways, control or user entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/66—Policy and charging system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/32—Hierarchical cell structures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/08—User group management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/53—Allocation or scheduling criteria for wireless resources based on regulatory allocation policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/186—Processing of subscriber group data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/12—Access point controller devices

Abstract

Una red de telecomunicaciones móviles que incluye: una red de acceso por radio que tiene medios de radio (2000) para comunicación inalámbrica con una pluralidad de terminales (10) registrados con la red de telecomunicaciones y la red de telecomunicaciones que tiene medios de control (700) operables para proporcionar servicios a los usuarios de los terminales conectados a la misma; un núcleo (2030) que tiene medios de procesamiento de contenido (2200, 2250) operables para proporcionar un servicio central con relación al contenido; en donde el núcleo (2030) es operable para proporcionar el servicio central con relación al contenido sobre una base por usuario/por portador, usando una conexión basada en GTPU; y unos medios de procesamiento de contenido alojados en la nube (2210) (2220) operables para proporcionar un servicio basado en la nube con relación al contenido correspondiente al servicio central; en donde los medios de control (700) son operables para transmitir datos a los medios de procesamiento de contenido alojados en la nube (2220) para la ejecución del servicio basado en la nube sobre los mismos; en donde los medios de control (700) son operables para seleccionar si el contenido se envía a los medios de procesamiento (2200, 2250) del núcleo (2030) o a los medios de procesamiento de contenido alojados en la nube (2210) (2220), en donde el servicio basado en la nube incluye al menos una de tarificación de contenido e intercepción legal, en donde el contenido que requiere soporte de movilidad sobre una base por usuario/por portador se envía a los medios de procesamiento (2200, 2250) del núcleo (2030) y en donde el contenido para el cual no se proporciona movilidad por un marco de encapsulación de GTP-U se envía a los medios de procesamiento de contenido alojados en la nube (2210) (2220) para realizar al menos una de tarificación de contenido e intercepción legal.

Description

DESCRIPCIÓN
Redes de telecomunicaciones
Campo técnico
La presente invención se refiere a una red de telecomunicaciones móviles que incluye una red de acceso por radio que tiene medios de radio para comunicación inalámbrica con una pluralidad de terminales registrados con la red de telecomunicaciones y medios de control operables para proporcionar servicios a los usuarios de los terminales conectados a la misma; y un núcleo que tiene medios de procesamiento del contenido operables para proporcionar un servicio básico relacionado con el contenido. También se proporciona un método correspondiente.
Antecedentes de la técnica
Recientemente, un aumento drástico en las ventas tanto de teléfonos inteligentes como de tarjetas de datos de portátiles ha dado como resultado un aumento sustancial en la cantidad de comunicaciones de datos que pasan a través de redes de telecomunicaciones móviles. Este aumento volumétrico también se puede atribuir a las mejoras hechas a las capacidades de las redes. El uso más popular de datos móviles es la navegación de HTTP, aunque el uso de difusión en forma continua de HTTP está creciendo considerablemente. Otros usos de datos móviles incluyen la descarga de HTTP y actividades de igual a igual (P2P) tales como compartición de archivos.
Esta habilidad de usar las redes celulares para servicios de datos móviles, tales como la navegación en internet están dando como resultado que los abonados traten sus redes móviles de la misma forma que tratan sus redes fijas. Es decir, los abonados están tendiendo a esperar el mismo servicio de Internet, independientemente de su método de acceso. No obstante, las redes móviles tienen una capacidad más restringida y son más costosas de operar, en comparación con las redes fijas.
A este respecto, desde el punto de vista del operador de la red, a medida que el volumen de tráfico de banda ancha móvil transportada sobre redes 2G, 3G, HSPA (Acceso de Paquetes de Alta Velocidad) y 4G continúa creciendo, el coste de soportar este volumen de datos está llegando a ser cada vez más caro en base a la arquitectura y los despliegues de red actuales. Este diferencial de coste se ve agravado por uno de los modelos de negocio actuales que se utilizan, por lo que los operadores cargan una tarifa plana por cantidades ilimitadas de datos.
El aumento del uso también es probable que, desafortunadamente, dé como resultado un aumento de atascos de tráficos de datos, y por lo tanto una degradación del servicio para los usuarios móviles si no se gestiona correctamente.
Se ha propuesto controlar a los usuarios de datos pesados “ahogando” el ancho de banda disponible para ellos cuando se exceda un límite de volumen de datos máximo. Mientras que esto aborda el problema en un nivel individual, no aborda el problema de capacidad de red en su conjunto.
Es por lo tanto evidente que la banda ancha móvil está en una encrucijada a medida que las redes y los modelos de negocio se ven afectados por la demanda de ancho de banda que es incomparable con la generación de ingresos. Estos problemas solamente empeorarán con los movimientos para posicionar los datos móviles como un sustituto del acceso DSL (Línea de Abonado Digital) fijo y con la llegada de velocidades de acceso por radio más altas con la red de LTE/SAE (Evolución a Largo Plazo/Evolución de Arquitectura de Sistema) de 4G. Un gran porcentaje de este tráfico consistirá en datos que se destinan para Internet pública, a una proporción significativa de los cuales los operadores móviles no serán capaces de añadir valor, pese a transportar los datos en su propia infraestructura de transporte de enlace de retroceso, transporte de núcleo o núcleo celular.
Además de los problemas tratados anteriormente, las redes de comunicaciones de telefonía móvil convencionales tienen arquitecturas que son jerárquicas y tradicionalmente caras de escalar. Muchos de los elementos de red, tales como las BTS, los encaminadores, los BSC/RNC, etc., son propietarios: los dispositivos de un fabricante a menudo no interactúan con los dispositivos de otro fabricante. Esto hace que sea difícil introducir nuevas capacidades en la red en la medida que se requerirá una interfaz diferente para dispositivos de cada fabricante. Además, las estaciones base convencionales no son capaces de encaminamiento y procesamiento local inteligente. Además, la capacidad de las redes existentes no siempre se usa de manera eficaz. Por ejemplo, muchos emplazamientos celulares están infrautilizados, mientras que otros se usan considerablemente.
La arquitectura de red celular actual tiene las siguientes desventajas:
• Jerárquica y cara de escalar
• El enlace de retroceso es un problema importante
• Plataformas propietarias: BTS, BSC/RNC, etc.
• Nodos e interfaces cerrados
• Aplicación o conocimiento del cliente muy limitados (excepto para prioridad de QoS)
• Sin encaminamiento o procesamiento local inteligente
• Uso ineficiente de la capacidad instalada
Por lo tanto hay una necesidad de superar o mejorar al menos uno de los problemas de la técnica anterior. En particular hay una necesidad de abordar las necesidades tanto de los operadores de red como de los usuarios de mejorar la prestación de servicios de datos de banda ancha móviles.
El documento EP2403290 describe una red de telecomunicaciones móviles que incluye un núcleo y una red de acceso por radio que tiene medios de radio para comunicación inalámbrica con terminales móviles registrados con la red, en donde la red de acceso por radio incluye medios de control operables para controlar el uso de recursos de red por los terminales móviles. Los medios de control pueden almacenar temporalmente información de un terminal móvil en un almacenamiento en la nube.
El documento US2011280143 describe un método para servir medios que incluye recibir un registro de entrega de uso del tráfico después de cada primer intervalo de tiempo para un equipo de usuario. Se menciona que los registros de entrega de datos de medios se pueden enviar a la nube o que los parámetros de política de QoS se pueden enviar a la nube.
El documento US2012303835 describe un método para implementar un plano de control de un núcleo de paquetes evolucionado (EPC) de una red de evolución a largo plazo (LTE) del proyecto de cooperación de tercera generación (3GPP) en un sistema de computación en la nube. El documento describe la realización de funciones del plano de control tales como MME en la nube cuando la capacidad del núcleo (EPC) está sobrecargada.
El documento EP2315412 describe la introducción de una plataforma novedosa en el borde de la red. Para abrir la parte de acceso por radio se puede implementar una “Plataforma de Hardware de Propósito General” en el borde de la red. Esto puede permitir que los operadores dividan las funciones de un Controlador de Red de Radio (RNC) y/o un (e)NodoB entre hardware y software. Como consecuencia los operadores tienen la capacidad de colocar aplicaciones y contenido directamente en el borde de la red.
A pesar de la capacidad de colocar contenido y aplicaciones en el borde, tales como juegos, contenidos de M2M, de CDN o de caché, se deben soportar aún funciones de red central obligatorias, tales como Intercepción legal (LI), Filtro de Contenido para Adultos (ACF), tarificación u otros.
En la medida que los contenidos y aplicaciones situados en diferentes ubicaciones de radio requieren los mismos servicios y funciones situados en la red central, el operador móvil tiene que ofrecer una paridad de servicio si se sirve a un usuario o máquina, por ejemplo, contenido desde, por ejemplo, el (e)NodoB o la red central. Esto se ve como uno de los principales problemas al traer contenido y aplicaciones a las ubicaciones de radio. La solución propuesta debería ofrecer preferiblemente todas las funciones y servicios ofrecidos por las redes central y de Gi a los clientes.
Las siguientes disposiciones conocidas se describen, en su mayoría, en el documento EP2315412 y ahora se describirán con referencia a las Figuras que se acompañan en las que:
la Figura 1 ilustra una arquitectura de red de datos de paquete de alto nivel conocida, útil para explicar la técnica anterior y las realizaciones de la presente invención;
la Figura 2 ilustra la introducción de una “plataforma” funcional en una red de 3G;
la Figura 3 muestra la “plataforma” con más detalle proporcionada en la Red de Acceso por Radio;
la Figura 4 muestra ubicaciones posibles de la plataforma dentro de una red de telecomunicaciones móviles; la Figura 5 es un diagrama de flujo que muestra los pasos realizados cuando se activa un terminal móvil;
la Figura 6 muestra la optimización de entrega de contenido a un terminal móvil;
la Figura 7 muestra una optimización adicional de entrega de contenido a un terminal móvil;
la Figura 8 es un diagrama de flujo que muestra los procedimientos realizados cuando se mueve un terminal móvil dentro de la red;
la Figura 9 muestra la transferencia de información entre plataformas.
En las figuras, los elementos similares se designan generalmente con los mismos números de referencia.
Los elementos clave de una red de telecomunicaciones móviles de 3G y su operación se describirán ahora con referencia a la Figura 1.
Cada estación base (por ejemplo, el NodoB 1 y la Femto 2) corresponde a una celda respectiva de la red de telecomunicaciones celular o móvil y recibe llamadas de o transmite llamadas a un terminal móvil (no mostrado) en esa celda por radiocomunicación inalámbrica en uno o ambos de los dominios de paquetes conmutado o de circuitos conmutados. El terminal móvil puede ser cualquier dispositivo de telecomunicaciones portátil, incluyendo un teléfono móvil de mano, un asistente digital personal (PDA), un dispositivo de máquina a máquina (M2M) o un ordenador portátil equipado con una tarjeta de datos de acceso a red.
El nodoB 1 o la Femto 2 se puede considerar que comprende dos partes principales: una parte de radiofrecuencia (unidad de radio) y una parte de banda base. La parte de radiofrecuencia maneja la transmisión de señales de radiofrecuencia entre la antena del nodoB 1 o la Femto 2 y el terminal móvil, y de convertir señales de radiofrecuencia en señales en banda base digitales (y viceversa). La parte de banda base es responsable de controlar y gestionar la transmisión de las señales en banda base a otros componentes de la red de telecomunicaciones móviles.
En una macro red de 3G, la Red de Acceso por Radio (RAN) comprende Nodos B y Controladores de Red de Radio (RNC). El Nodo B es la función dentro de la red de 3G que proporciona el enlace de radio físico y de transporte entre el terminal móvil (Equipo de Usuario, UE) y la red. El Nodo B realiza la transmisión y recepción de datos de manera inalámbrica a través de la interfaz de radio, y también aplica los códigos que son necesarios para describir canales en un sistema de WCDMA. El RNC es responsable de controlar los Nodos B que están conectados a él. El RNC realiza la Gestión de Recursos de Radio (RRM), algunas de las funciones de gestión de movilidad y es el punto donde se hace el cifrado antes de que se envíen los datos de usuario a y desde un terminal móvil. El RNC conecta con la Red Central de Circuitos Conmutados a través de una Pasarela de Medios (MGW) (o MSC/MSS en caso de arquitectura de R4) y con un SGSN (Nodo de Soporte de GPRS de Servicio) 5 en la Red Central de Paquetes Conmutados. En la Figura 1, el Nodo B 1 se controla por el RNC 3 a través de la interfaz Iub. Un RNC puede controlar más de un nodo B.
La Figura 1 también ilustra una Femto RAN de 3G, con la Femto 2 funcionando como la estación base. La Femto 2 se conecta a una Pasarela de Acceso (AGW) (también conocida como Concentrador) 4 a través de una interfaz Iuh. Femto es una abreviatura de “femto celdas” y se han usado muchos otros nombres diferentes, incluyendo puntos de acceso domésticos (HAP), puntos de acceso (AP) y femto estaciones de base, pero todos los nombres se refieren al mismo aparato.
El enlace de radio entre la Femto 2 y el terminal móvil usa los mismos protocolos de transporte de telecomunicación celular que el Nodo B 1 pero con un alcance más pequeño, por ejemplo, 25 m. La Femto 2 se muestra al terminal móvil como una estación base convencional, así que no se requiere ninguna modificación al terminal móvil para que opere con la Femto 2. La Femto 2 realiza un papel correspondiente al del Nodo B 1 en la macro RAN de 3G.
La Femto 2 se configuraría típicamente para servir a un hogar u oficina, además de las redes de GSM/UMTS/LTE. La WLAN podría pertenecer al abonado del terminal móvil, o ser un WLAN operada independientemente. El propietario de la Femto 2 puede prescribir si está abierta o cerrada, por lo que un AP abierto es capaz de transportar comunicaciones desde cualquier dispositivo móvil en la red de GSM/UMTS/LTE y un AP cerrado solamente es capaz de transportar comunicaciones desde dispositivos móviles asignados previamente específicos.
Convencionalmente, en una red de 3G (macro o Femto), las RAN se controlan por un centro de conmutación móvil (MSC) y un SGSN (Nodo de Soporte de GPRS de Servicio) 5 de la red central. El MSC soporta comunicaciones en el dominio de circuitos conmutados, mientras que el SGSN 5 soporta comunicaciones en el dominio de paquetes conmutados, tales como transmisiones de datos de GPRS. El SGSN es responsable de la entrega de paquetes de datos desde y a los terminales móviles dentro de su área de servicio geográfica. Realiza encaminamiento y transferencia de paquetes, gestión de movilidad (gestión de conexión/desconexión y de ubicación), gestión de enlace lógico y funciones de autentificación y tarificación. Un registro de ubicación del SGSN almacena información de ubicación (por ejemplo, celda actual, VLR actual) y perfiles de usuario (por ejemplo, IMSI, dirección o direcciones usadas en la red de datos de paquete) de todos los terminales móviles registrados con este SGSN. En la Figura 1, dado que la realización concierne a la transmisión de datos, solamente se ilustra el SGSN como que está en comunicación con el RNC 3 y la AGW 4, a través de la interfaz Iu. El RNC 3 tiene típicamente una conexión dedicada (no compartida) con su SGSN 5, tal como una conexión por cable.
Las comunicaciones entre la AGW 4 y el SGSN 5 son preferiblemente comunicaciones basadas en IP y se pueden transmitir, por ejemplo, sobre una red de IP de banda ancha. Además, la conexión entre la Femto y la AGW 4 puede usar la PSTN (Red Pública Telefónica Conmutada). Típicamente un cable de DSL conecta la AGW con la PSTN, y los datos se transmiten entre las mismas por transporte de IP/transporte de DSL. La Femto o AGW convierte los protocolos de transporte de telecomunicaciones celulares usados entre el terminal móvil y la Femto 2 en la señalización basada en IP adecuada. La interfaz Iuh es similar al RAP con algunas Femto extensiones.
La Femto 2 se puede conectar a la AGW por medios distintos a un cable de DSL y la red PSTN. Por ejemplo, la Femto 2 se puede conectar a la AGW por una conexión por cable dedicada que es independiente de la PSTN, o por una conexión por satélite.
El SGSN 5 está en comunicación con el GGSN 6 (Nodo de Soporte de GPRS de Pasarela) a través de la interfaz Gn. El GGSN es responsable de la interacción ente la red de GPRS y redes de paquete conmutados externas, por ejemplo, Internet. El GGSN permite la movilidad de terminales móviles en las redes. Mantiene el encaminamiento necesario para tunelizar las Unidades de Datos de Protocolo (PDU) al SGSN que sirve a un terminal móvil particular. El GGSN convierte los paquetes de GPRS que vienen desde el SGSN en el formato de protocolo de datos de paquete (PDP) (por ejemplo, IP o X.25) y los envía en la red de datos de paquete correspondiente. En la otra dirección, las direcciones de PDP de los paquetes de datos entrantes se convierten en la dirección de red móvil del usuario de destino. Los paquetes redireccionados se envían al SGSN responsable. Con este propósito, el GGSN almacena la dirección de SGSN actual del usuario y su perfil en su registro de ubicación. El GGSN es responsable de la asignación de direcciones de IP y es el encaminador por defecto para el terminal móvil conectado. El GGSN también realiza funciones de autentificación y tarificación. Otras funciones incluyen la gestión de Agrupaciones de IP y correlación de direcciones, QoS y aplicación de contexto de PDP.
A su vez, el GGSN 6 puede encaminar datos a través de cualquier equipo de Servicio de Valor Añadido (VAS) 7 aplicable, antes de que los datos se reenvíen hacia su destino previsto a través de Internet 8. Como ejemplo de la funcionalidad del equipo de VAS, el tráfico puede ser inspeccionado en busca de contenido para adultos antes de llegar al usuario final si este usuario es menor de 18 años de edad.
Con propósitos de facturación, por ejemplo, también se proporciona un aparato de PCRF (Función de Reglas de Política y Tarificación) 9, en comunicación con el GGSN 6.
El SGSN 5, el GGSN 6, el VAS 7 y el aparato de PCRF 9 comprenden la red central de la red de telecomunicaciones móviles. El núcleo también comprende elementos adicionales, tales como el HLR (que no se muestra).
Las redes de telecomunicaciones móviles tienen un estado activo de comunicación con sus terminales móviles y un estado inactivo/de reposo de comunicación con sus terminales. Cuando está en el estado activo, a medida que los terminales móviles se mueven entre diferentes celdas de la red, la sesión de comunicación se mantiene realizando una operación de “traspaso” entre las celdas. En el estado inactivo/de reposo, a medida que un terminal móvil se mueve entre diferentes celdas de la red el terminal móvil realiza “reselección de celda” para seleccionar la celda más adecuada en la que “asentarse” con el fin de que el terminal móvil se pueda buscar por la red cuando los datos de terminación móvil se destinan a ese terminal móvil.
Convencionalmente, el terminal o red móvil determina si se debería desencadenar un procedimiento de traspaso/reselección de celda en dependencia de las mediciones de las señales de radio de las celdas en la región del terminal móvil. Se aplica un filtro a las señales (o bien por la red o bien por el terminal móvil) que calcula un valor promedio (por ejemplo, media aritmética) de estas señales durante un periodo de tiempo particular. Los valores filtrados/promedios de las celdas se comparan entonces unos con otros o con un valor umbral. En dependencia de estas comparaciones, se desencadenan los procedimientos relacionados con la reselección de celda/traspaso. Este proceso de reselección de celda/traspaso generalmente comprende tomar mediciones de señal de radio de las celdas colindantes y comparar éstas entre sí y con la señal de radio de la celda actual para determinar qué celda proporciona la mejor intensidad/calidad de señal. El traspaso/reselección a la mejor celda puede ocurrir entonces. Generalmente los cálculos para determinar si realizar el traspaso desde una estación base a otra estación base se realizan por la red, mientras que los cálculos de si realizar la reselección de celda se realizan por el terminal móvil. Los datos en una red de telecomunicaciones móviles se pueden considerar que se separan en “plano de control” y “plano de usuario”. El plano de control realiza la señalización requerida e incluye protocolo de aplicación y el portador de señalización pertinentes, para transportar los mensajes de protocolo de aplicación. Entre otras cosas, el protocolo de aplicación se usa para establecer el portador de acceso por radio y la capa de red de radio. El plano de usuario transmite tráfico de datos e incluye flujos de datos y portadores de datos para los flujos de datos. Los flujos de datos se caracterizan por uno o más protocolos de trama específicos para una interfaz particular. En términos generales, el plano de usuario transporta datos para su uso por un terminal de recepción, tales como datos que permiten que se reproduzca una voz o imagen, y el plano de control controla cómo se transmiten los datos.
Además de los elementos y funciones descritos anteriormente, las redes de telecomunicaciones móviles también incluyen facilidades para transmitir mensajes de SMS. Los mensajes SMS se transmiten solamente sobre el plano de control (y no del plano de usuario).
Esta arquitectura es la que se usa actualmente para transportar todos los de paquetes de datos a y desde terminales móviles. Es decir, en la implementación actual de la arquitectura de paquetes de datos, el tráfico de plano de usuario atraviesa a través de todos los elementos de red mostrados entre el Nodo B o la Femto en el que se asienta el usuario e Internet. Es decir, todos los datos se dirigen desde la RAN aplicable a través de los componentes de red central SGSN, GGSN y VAS antes de llegar a Internet. Todo el tráfico de PS sigue en consecuencia el mismo camino y por lo tanto tiene los mismos costes de red. Todas las aplicaciones se procesan en el cliente (en el dispositivo móvil) o en el servidor (que está conectado a Internet), y el núcleo de red por lo tanto actúa como una tubería de bits en la arquitectura actual. Para datos, donde el operador móvil no puede añadir ningún valor transportándolos en su propia infraestructura de transporte de enlace de retroceso, de transporte de núcleo o de núcleo celular (la red central), tales como los datos destinados para Internet pública sin intervención requerida de la red central, no hay ningún beneficio en encaminar estos datos a través de la red central.
No obstante, un gran porcentaje de este tráfico se puede manejar de una manera más inteligente por ejemplo a través de optimización de contenido (Video y Web), almacenamiento en caché de contenido o contenido encaminado localmente o encaminado directamente a Internet pública. Todas estas técnicas reducen la inversión requerida por un operador móvil para transportar los datos a su propia infraestructura de enlace de retroceso y de transporte de núcleo o de núcleo celular.
Con el fin de ofrecer datos de paquetes de bajo coste, para soportar nuevos servicios y para gestionar las expectativas del cliente, se requiere una reducción escalonada en el coste por bit de extremo a extremo.
Los operadores móviles quieren reducir sus costes de manejo de datos de paquetes a través de arquitecturas de red alternativas basadas en plataformas de IT mercantilizadas, rompiendo con la arquitectura tradicional basada en su legado de voz. Estas nuevas arquitecturas de red superan los problemas de arquitectura de Acceso de hoy en día. Con el fin de ofrecer con éxito datos de paquetes baratos y ser capaces de competir con las ofertas de banda ancha fijas (tarifa plana), se propone una solución que se centra en la reducción del coste por bit de extremo a extremo, especialmente para el servicio de acceso a Internet.
Esto permite que los operadores móviles reduzcan los costes de manejo de datos de paquetes por medio de una arquitectura de modelo de coste de red alternativa, que rompe con la arquitectura de red y los nodos tradicionales y utiliza redes de transporte de menor coste para optimizar el flujo de datos.
A este respecto, la Figura 2 muestra una descripción de alto nivel de la arquitectura que se puede adoptar para desplegar esto en una red de 3G. Tal arquitectura se describe en el documento EP2315412.
Según esta disposición, las novedosas “plataformas” (medios/unidades de control, a los que se hace referencia también como “SAVi”) 24, 25, 26 para realizar funciones tales como almacenamiento en caché, encaminamiento, optimización o descarga/devolución de funcionalidad de decisión se integran en la red. Esta funcionalidad de decisión se puede incorporar en la arquitectura de radio. A este respecto, las plataformas 24, 25, 26 se pueden incorporar en los NodosB 1 (25), los RNC 3 (26) o existir como entidades físicas (24) separadas. Son estas plataformas 24, 25, 26 las que, por ejemplo, determinan el camino de comunicación que se origina desde los terminales móviles.
La colocación exacta de la plataforma 24, 25, 26 no es esencial y, para una macro red de 3G, se puede colocar en o entre los Nodos B y los RNC, y también entre los RNC y los SGSN (o cualquier combinación de los mismos). También sería posible colocar la plataforma 24, 25, 26 en el GGSN o en la P-GW.
En la macro red de 3G, el objetivo es descargar un alto porcentaje del trafico de macro red del núcleo y transporte (IuPS, Gn, etc.) desviando tipos de tráfico específico para ciertas clases de usuario o usuarios directamente a Internet.
Donde se sitúa la plataforma 24, 25 en los Nodos B (o en la interfaz Iub), puede ser posible redirigir los datos desde todos los elementos de red móvil restantes (por ejemplo, el RNC, SGSN, GGSN y VAS para la macro 3G) y enviar los datos directamente a Internet 8. De manera similar, cuando la plataforma 26 se sitúa en el RNC (o en la interfaz Iu), llega a ser posible redirigir los datos desde el SGSN 5, el GGSN 6 y el VAS 7. La ruta de datos alternativa es preferiblemente un DSL que usa ADSL.
También es preferible agregar las rutas de datos alternativas para cada celda, donde sea aplicable. A este respecto, cada celda tendrá al menos un RNC 3 y una pluralidad de Nodos B, así que cuando se sitúen los bloques de decisión en o dentro de las inmediaciones de los Nodos B, por ejemplo, habrá una pluralidad de enlaces que se deberían agregar idealmente antes de ser pasados a Internet 8. En el punto de esta agregación 42, hay preferiblemente un bloque de decisión adicional que permite que los datos se devuelvan a la ruta legada. Por ejemplo, una nueva regla de política se puede haber implementado, lo que requiere o permite que los datos descargados previamente se devuelvan a la ruta de red central. Esta nueva regla de política se puede comunicar al módulo de decisión de devolución por el módulo de política de red central. En la Figura 2, esta devolución de los datos solamente se muestra al VAS 7, pero los datos se pueden devolver a uno o más de los otros elementos de red central.
Cada uno de los NodosB 1 se conecta a un núcleo de red móvil a través de un Punto de Concentración (PoC) 27. Todo tráfico desde los NodosB 1 que ha de ser encaminado a través de la red móvil central se encamina al PoC 27. Esto incluye tanto datos de plano de usuario como de plano de control. En el nivel de plano de control, el PoC 27 encamina datos a y desde el SGSN 5 y el GGSN 6. Los datos de control también se envían a y desde otros componentes de red central, incluyendo la Base de Datos de Intercepción legal (DB de LI) 30, el Servidor de DNS 32, Servidor de Política 9 (que incluye reglas de Tarificación y Red de IT 9A) y Registro de Posición Base/Servidor Local de Abonado (HLR/HSS) 36 (que contiene información de estado y perfil de dispositivo y de abonado).
Los datos del plano de usuario se transmiten por el PoC 27 al SGSN 5 y al GGSN 6. Desde el GGSN 6, los datos se encaminan a través de un nodo de VAS 7 a Internet 8. En 3G, este es el camino de datos estándar desde los terminales móviles a Internet.
La realización de la Figura 2 está en relación con una red de 3G. Las realizaciones de la invención son igualmente aplicables a redes de 4G (LTE/SAE).
La macro red de LTE/SAE incluye eNodos B que constituyen la RAN. Los eNodos B combinan eficazmente la funcionalidad del nodo B y el RNC de la red de 3G. Estos eNodosB son los componentes de red que comunican con los dispositivos de comunicaciones móviles. Está previsto que los eNodosB se dispondrán en grupos y cada grupo se controlará por una Entidad de Gestión de Movilidad (MME) y una Entidad de Plano de Usuario (UPE):
La MME realiza muchas de las funciones de movilidad proporcionadas tradicionalmente por el SGSN. La MME termina el plano de control con el dispositivo móvil. Es responsable de terminar la Señalización de NAS (Estrato Sin Acceso) tal como información de MM (Gestión de Movilidad) y de SM (Gestión de Sesión) así como coordinar procedimientos de Modo Inactivo. Otras responsabilidades de la MME incluyen Movilidad entre MME de selección de pasarela y autentificación del dispositivo móvil.
La UPE gestiona protocolos en el plano de usuario tales como, almacenar contextos de terminal móvil, terminar el Modo Inactivo en el plano de usuario y cifrado de contexto de PDP.
Las plataformas funcionarían de la misma manera que se describe con relación a la red de 3G. Las plataformas se pueden situar en muchas ubicaciones diferentes en la red de 4G.
Ahora se describirán disposiciones en las que la Red de Acceso por Radio controla el uso de recursos por terminales móviles.
Arquitectura de plataforma
Como se ha discutido anteriormente, una red de telecomunicación móvil se modifica por la introducción de una “plataforma” 24, 25, 26. Tal plataforma (o medios/unidad de control, a los que se hace referencia también como “SAVi”) se muestra con más detalle en 700 de la Figura 3 y que incluye tres partes principales: nodos programables 702 (capa física/de transporte), funciones de red 704 y servicios 706 (capa de aplicaciones).
La plataforma 700 comunica con la parte de radiofrecuencia/RF (unidad de radio) de una estación base, tal como un NodoB 1. Los nodos programables 702 de la plataforma 700 comprenden componentes tales como un NodoB programable 708, Bt S programable 710, eNodoB programable 711 y RNC programable 712 y SGSN/GGSN programable 714. El eNodoB programable 708 proporciona funciones equivalentes a la parte en banda base de un NodoB convencional en una red de telecomunicaciones de 3G. La BTS programable 710 proporciona funciones en banda base equivalentes a las funciones en banda base de una BTS en una red de telecomunicaciones móviles de 2G convencional. El eNodoB programable 711 proporciona funciones en banda base equivalentes a las funciones en banda base proporcionadas por un eNodoB convencional en una red de telecomunicaciones móviles de 4G. La plataforma 700 puede comunicar por lo tanto con la parte de radiofrecuencia de una estación base de 2G, 3G o 4G y proporcionar servicios en banda base adecuados para tecnologías de 2G, 3G y 4G (o en realidad para otras tecnologías). Un terminal móvil de 3G que desea obtener servicios de telecomunicación desde las redes de telecomunicaciones móviles conecta inalámbricamente con la parte de radiofrecuencia de un eNodoB. Las funciones en banda base se pueden proporcionar o bien por una parte en banda base del eNodoB convencional o bien por el NodoB programable 708 que forma un elemento de la parte de nodo programable de la plataforma 700. Por ejemplo, el NodoB programable 708 puede recibir mediciones por radio desde la parte de radiofrecuencia del NodoB a la que está conectado, y puede proporcionar estas mediciones por radio a otros elementos de la plataforma 700.
La parte de funciones de red 704 de la plataforma 700 incluye módulos para realizar funciones similares a las realizadas por la red central de una red de telecomunicaciones móviles, tales como facturación 720, seguimiento de ubicación 722 y la gestión de recursos de radio (RRM) 724. Las funciones de red pueden comprender además un módulo de decisión de descarga 726 que realiza una función similar a los módulos de decisión de descarga 24, 25 y 26 descritos anteriormente. La parte de funciones de red 704 puede comprender además una función de almacenamiento en caché 728 y una función de Red de Entrega de Contenido 730.
La parte de funciones de red 704 de la plataforma 700 proporciona un marco de referencia de Interfaz de Programación de Aplicaciones (API) a la parte de servicios 706 de la plataforma 700. La parte de servicios 706 de la plataforma soporta una pluralidad de aplicaciones 740, 742, etc.
Las funciones de red se dividen en tres categorías principales, las que permiten la operación de la red (por ejemplo, tarificación, O y M), las que soportan la operación de servicio (por ejemplo, Ubicación) y las que optimizan el uso de la red por ciertas aplicaciones y servicios (por ejemplo, Almacenamiento en Caché, Optimización de Video).
Las aplicaciones soportadas en la Plataforma 700 son las entidades que suministran o demandan el flujo de datos en la red, similar a un servidor en Internet, por ejemplo, un servidor de juegos, un servidor de navegación.
La API se implementa por un programa de software que se ejecuta en la parte de función de red 704 que presenta una novedosa interfaz estandarizada para las aplicaciones 740, 742, etc., de la parte de servicios 706. La novedosa API estandarizada proporciona una interfaz consistente, que define protocolos, puertos, etc. de comunicación. Los detalles completos de la API se pueden publicar para permitir que se desarrolle una multiplicidad de aplicaciones para la plataforma 700 por múltiples desarrolladores. Esto se debería contrastar con disposiciones de la técnica previa donde cada componente de una red de telecomunicaciones móviles (tales como BTS, BSC/RNC, SGSN, etc.) es propietario y tiende a tener una interfaz única, lo que significa que se debe escribir una aplicación diferente para cada nodo de una red convencional.
Las aplicaciones 740, 742, etc., pueden proporcionar servicios a usuarios de la red de telecomunicaciones cooperando con otras partes de la plataforma 700.
Los detalles del uso de cada aplicación usada por un usuario de la red de telecomunicaciones móviles se almacenan en un contexto/contenedor de aplicaciones. El contexto de aplicación contiene nombres de aplicaciones, el protocolo usado para transportar tal aplicación, sus características que se miden/notifican durante un periodo de tiempo y alguna información estadística acerca de estas aplicaciones (volumen, número de usuarios que usan estas aplicaciones, etc.).
Como se muestra en la Figura 4, una plataforma 700 se puede proporcionar a cada estación base de la red móvil (donde se conecta a la parte de radiofrecuencia de la estación base, el NodoB 1 en la Figura 2), formando un nodo de acceso 800. La plataforma 700 también se puede proporcionar en el RNC (artículo 3 en la Figura 2) donde forma una pasarela 802. El nodo de acceso 800 y la pasarela 802 se configuran ambos para comunicar directamente con el núcleo de la red 804 (por ejemplo, que comprende el SGSN 5, GGSN 6 y VAS 7). El nodo de acceso 800 y la pasarela 802 también se pueden conectar a Internet 8 para acceso directo a Internet a través de enlaces directos 806 y 808, respectivamente, de manera que al menos una parte de la red central 804 se desvía de la manera descrita anteriormente.
Los siguientes son ejemplos de tecnologías de acceso que se pueden proporcionar dentro del nodo de acceso 700: 3GPP: GSM/GPRS, UMTS/HSPA y LTE
IEEE: familia 802.11 y familia 802.16
ITU: DSL, ADSL, VDSL, VDSL2
Asignación de funciones a plataformas
Los pasos realizados cuando se activa un terminal móvil en un NodoB, en la Femto o en el Punto de Acceso (AP) de la red que incluye la novedosa plataforma 700 se describirán ahora con referencia a la Figura 5. En el paso 9A, el terminal móvil (UE) se activa dentro del área de cobertura de un NodoB particular, en la Femto o en el AP. La parte de acceso del NodoB, en la Femto o en el AP comunica información desde el terminal móvil a la plataforma 700 asociada con el NodoB, en la Femto o en el AP. En el paso 9B, la plataforma 700 asigna entonces el NodoB en banda base, en la función de la Femto o el AP y la función de RNC o de BRAS (Servidor de Acceso Remoto de Banda Ancha) o bien en el nodo de acceso 800 en el NodoB en la Femto o en el emplazamiento del AP o en la pasarela 802 en el emplazamiento de RNC o BRAS de la red o incluso desde nodos colindantes que tienen recursos de sobra para sacar. La decisión en cuanto a si la función de RNC o de BRAS se asigna en la plataforma 700 del nodo de acceso 800 o en el nodo de pasarela 802 se puede tomar dependiendo de diversos criterios, incluyendo: * El tipo de dispositivo: por ejemplo, esta decisión se puede basar en las capacidades de acceso por radio que el terminal móvil indica tras su activación, tales como si está operando en los dominios de paquetes conmutados o de circuitos conmutados.
* La ubicación del terminal móvil. Si el terminal móvil esta cerca del borde de la celda (que se puede determinar por mediciones de potencia de la red o mediciones de celdas colindantes del terminal móvil, dentro de un rango de más o menos 3dB para el RACH).
* La causa de establecimiento de la solicitud de conexión: de manera que el NodoB pueda filtrar la información de señalización innecesaria del terminal móvil que no es crítica, por ejemplo, mensajes de actualización de área de encaminamiento periódicos.
Tras asignar el NodoB en banda base en la Femto o en el AP y la función de RNC o de BRAS, el NodoB en la Femto o en el AP puede asignar el terminal móvil a un portador particular dedicado a la función de RNC o de BRAS.
Una vez se asigna la función de RNC o de BRAS o bien al nodo de acceso 800 o bien a la pasarela 802 en el paso 9C, otras funciones realizadas por la plataforma 700 en el nodo de acceso 800 (u otro nodo de acceso) y la pasarela 802 (u otra pasarela) se asignan al dispositivo móvil. Todas las demás funciones de plataforma se pueden proporcionar por la plataforma donde se asigna la función de RNC o de BRAS al terminal móvil. No obstante, una plataforma en una ubicación diferente a la que proporciona la función de RNC o de BRAS al terminal móvil puede proporcionar algunas o todas las demás funciones.
En el paso 9D, la plataforma a la que se asigna la función de RNC o de BRAS se dota con un mensaje de ID Común desde la red central 804.
En el paso 9E, este mensaje se usa por la plataforma 700 para buscar la información de suscripción completa para el terminal móvil, así como los requisitos de recursos (QoS) de los servicios requeridos y el contexto de PDP negociado, siendo esta información proporcionada por la red central 804.
La información de abonado con relación al dispositivo que se obtiene de los nodos centrales (por ejemplo, red central) 804 se usa para asignar las otras funciones en el nodo de acceso 800 y/o la pasarela 802 en dependencia de diversos factores, incluyendo:
Información detallada con respecto al tipo de terminal móvil obtenido de la red central.
Las características de suscripción del terminal móvil.
Las aplicaciones previamente usadas más frecuentemente por el terminal móvil.
Las características de las aplicaciones previamente usadas por el dispositivo móvil y los requisitos de rendimientos de las mismas.
La movilidad histórica del terminal móvil (velocidad, conexión, distancia recorrida, etc.)
La ubicación del terminal móvil y el destino probable del tráfico desde el terminal móvil en base a los patrones de uso históricos.
La carga del NodoB que proporciona servicios de RF al terminal móvil y las tendencias de tráfico histórico en ese NodoB, en la Femto o en el AP.
Las características del NodoB en la Femto o el AP que proporcionan servicios de RF (por ejemplo, la ubicación, qué otros dispositivos se conectan a través del NodoB en la Femto o en el AP, el número de dispositivos de máquina a máquina que se unen y se sirven por el NodoB, etc.).
Como se ha mencionado anteriormente, un único terminal móvil puede tener aplicaciones/funciones de plataforma asignadas en una pluralidad de plataformas. Generalmente, cuando un terminal móvil es casi estacionario es más eficiente que sus aplicaciones/funciones ser servido desde un nodo de acceso 800 (es decir, distribuidas), mientras que terminales móviles con mayor movilidad (o menores tiempos de espera de celda anticipados) se servirán más eficazmente teniendo menos o ninguna función/aplicación servida desde el nodo de acceso 800, y más o todas las funciones/aplicaciones servidas desde una pasarela 802 (es decir, centralizadas). La asignación de funciones/aplicaciones a un terminal móvil entre un nodo de acceso 800 y una pasarela 802 también dependerá de las características del tipo de servicio proporcionado por la aplicación (por ejemplo, la duración de sesión de IP promedio, la popularidad de la aplicación particular, la movilidad promedio del terminal móvil que usa el servicio proporcionado por la aplicación, etc.).
La gestión de tráfico se puede realizar en el nodo de acceso 800, donde hay acceso a información de radio en tiempo real desde la parte de radiofrecuencia del NodoB, sirviendo la Femto o el AP al dispositivo móvil.
La Gestión de Recursos de Radio (RRM) Centralizada se puede proporcionar en la pasarela 802 y mantiene el rendimiento a través de diferentes modos de acceso 800, que pueden tener diferentes tecnologías de acceso por radio, bandas de frecuencia, cobertura, etc. La función de RRM 724 de la plataforma 700 de la pasarela 802 puede obtener información con respecto a la gestión del tráfico de radio de cada nodo de acceso 800 para posicionar dinámicamente abonados a tecnologías de radio particulares. Esta técnica se usará para asignar recursos de red en base a la disponibilidad de recursos, la aplicación usada y la movilidad de usuario. Por ejemplo, la información de gestión de tráfico se puede proporcionar por el NodoB programable 708, la Femto o el AP de la plataforma 700 en el nodo de acceso 800. Este NodoB programable 708 obtiene información de radio con relación al terminal móvil de la parte de radiofrecuencia del NodoB al que el terminal móvil se conecta de manera inalámbrica.
Para un terminal móvil particular, las funciones proporcionadas por un nodo de acceso 800 y una pasarela 802 se pueden coordinar para funcionar juntas de una manera ventajosa (es decir, una disposición híbrida o distribuida). Por ejemplo, la pasarela 802 puede establecer límites o rangos de operación dentro de los que se pueden realizar funciones realizadas por el nodo de acceso 800, sin referencia a la pasarela 802. Cuando las funciones se mueven fuera de los rangos establecidos, se puede pasar el control de esas funciones a la pasarela 802.
Además, el nodo de acceso 800 y la pasarela 802 pueden cooperar para optimizar ventajosamente la entrega de contenido a un terminal móvil.
La optimización de entrega de contenido se describirá ahora con referencia a la Figura 6 de los dibujos. El contenido se puede optimizar en la pasarela 802 y en un nodo de acceso 800. La pasarela 802 puede servir a múltiples nodos de acceso 800 y puede distribuir contenido a esos múltiples nodos de acceso 800, para transmisiones posteriores desde cada uno de esos nodos de acceso 800 a un terminal móvil a través de la parte de radiofrecuencia del NodoB, de la Femto o del AP que sirve a ese nodo. Las mediciones de calidad de radio se notifican por el terminal móvil al nodo de acceso 800 en intervalos regulares, tales como intervalos de 2 milisegundos. Las mediciones de calidad de radio con relación al terminal móvil se transmiten entre la parte de radiofrecuencia del NodoB, de la Femto y del AP que sirve al terminal móvil al nodo de acceso 800 en intervalos regulares, tales como intervalos de entre 2 y 10 milisegundos. Estas mediciones de radio se reciben en los nodos programables 702 y se pasan a las funciones 704 (por ejemplo, a la función de QoS 732 para análisis). Estas mediciones de radiofrecuencia desde el terminal móvil y el NodoB se comunican por el nodo de acceso 800 a la pasarela 802 (por ejemplo, a la función de QoS 732 de la pasarela 802 para análisis) en intervalos regulares, tales como intervalos de entre 1 y 10 segundos. La pasarela 802 puede recibir información de radio desde múltiples nodos de acceso 800. Las mediciones de radio recibidas por la pasarela 802 se pueden analizar sobre un periodo relativamente largo, tal como entre 1 y 2 minutos. Las mediciones de calidad de radio se pueden promediar (por ejemplo, se puede determinar la media aritmética de la calidad de radio) sobre este periodo de tiempo. La transmisión de contenido desde la pasarela 802 se puede optimizar entonces según este cálculo. Donde el contenido se distribuye por la pasarela 802 a una pluralidad de nodos de acceso 800, la distribución de contenido se basará en el análisis de los indicadores de calidad de radio de todos los nodos de acceso 800. El análisis puede considerar el rendimiento de radio máximo o pico sobre un periodo de tiempo de entre 1 y 2 minutos.
Cuando se recibe el contenido por cada nodo de acceso 800, el nodo de acceso 800 entonces distribuye el contenido a cada terminal móvil. Esta distribución se optimiza en base al modo de red en tiempo real y calidad de enlace de radio específica del terminal móvil, como se determina sobre un periodo de, por ejemplo, entre 1 y 10 milisegundos. Es decir, el contenido entregado a un terminal móvil que tiene alta calidad de enlace de radio se puede optimizar de una manera diferente a un terminal móvil que tenía escasa calidad de enlace de radio.
La cooperación entre los nodos de acceso 800 y las pasarelas 802 puede mejorar además la distribución de contenido de una manera a ser descrita ahora con referencia a la Figura 7.
Cuando un terminal móvil solicita un elemento de contenido particular, esta solicitud se transmite al nodo de acceso 800 que sirve ese terminal móvil, suponiendo que esta es la primera solicitud de este elemento de contenido al nodo de acceso 800, el nodo de acceso 800 pasa esta solicitud a la pasarela 802 que sirve al nodo de acceso 800. Suponiendo que esta es la primera solicitud de este elemento de contenido de la pasarela 802, la pasarela 802 recupera el contenido del servidor de contenido. El contenido se proporciona entonces por al servidor de contenido a la pasarela 802 y desde allí se distribuye al nodo de acceso 800, y posteriormente al terminal móvil solicitante. Ventajosamente, la pasarela 802 mantiene un registro de elementos de contenido que se solicitan frecuentemente. Cuando un elemento de contenido se determina por la pasarela 802 que se solicita frecuentemente, éste se almacena en una caché 1110 asociada con la pasarela 802 (que puede ser la caché 728 de la plataforma 700). Las solicitudes posteriores de ese elemento de contenido de los nodos de acceso 800 a la pasarela 802 se pueden servir entonces recuperando el elemento de contenido de la caché 1110 y distribuyendo el elemento de contenido al nodo de acceso 800 solicitante, y evitando de este modo la necesidad de solicitar el contenido desde el servidor de contenido.
La pasarela 802 se puede configurar además para identificar elementos de contenido populares que es probable que se soliciten por un gran número de nodos de acceso 800. Cuando se determina que un elemento de contenido es popular, la pasarela 802 puede empujar estos elementos de contenido a cada uno de los nodos de acceso 800 asociados con los mismos (de modo que este contenido se aloje en el nodo de acceso 800, usando la función de Red de Entrega de Contenido (CDN) 730 de las funciones de red 704 de la pasarela 802 y del nodo de acceso 800). El contenido está disponible entonces en el nodo de acceso 800 para su transmisión a cualquier terminal móvil que lo solicite, sin tener que recuperar este contenido de la pasarela 802 o del servidor de contenido. Ventajosamente, la distribución de tales elementos de contenido se realiza de una manera que tiene en cuenta la capacidad o la congestión del enlace entre el terminal móvil y la pasarela 802 y la naturaleza del contenido. Por ejemplo, típicamente un enlace entre un terminal móvil y la pasarela 802 puede experimentar muy poco uso y congestión en las primeras horas de la mañana. El elemento de contenido se puede transmitir ventajosamente entre medias de la pasarela 802 y del nodo de acceso 800 en este momento, cuando hay capacidad de sobra. La pasarela 802 determinará si el elemento de contenido es adecuado para transmisión sobre esta base, por ejemplo, teniendo en cuenta un número de veces que el elemento de contenido se ha solicitado, el tamaño del elemento de contenido y el espacio de almacenamiento en el nodo de acceso 800. Si un elemento de contenido es relativamente pequeño y es crucial, tales como titulares de noticias, entonces tal elemento de contenido se puede distribuir frecuentemente a lo largo del día, en la medida que tal contenido no es adecuado para transmisión una vez al día a primeras horas de la mañana, en la medida que llega a estar rápidamente desactualizado.
Reubicación de terminal móvil
Los procedimientos realizados cuando un terminal móvil se mueve entre celdas en la red de telecomunicaciones móviles se describirán ahora con referencia a la Figura 8. De la manera convencional en el paso 12A, cuando el terminal móvil se mueve al borde de su celda de servicio actual, las mediciones de radio notificadas desde el terminal móvil y la parte de radiofrecuencia del NodoB, de la Femto o del AP que sirve a ese terminal móvil, se usan por la red central para determinar cuándo realizar un traspaso y a qué celda de destino se debería realizar el traspaso. Cuando la mejor celda de destino se ha identificado, se realiza el traspaso a la celda de destino desde la celda de servicio en 12B de una manera convencional.
En el paso 12C, las funciones de plataforma seleccionadas se pueden reubicar desde el nodo de acceso de origen (que servía a la antigua celda) al nodo de acceso de destino (que sirve a la nueva celda de destino).
Cuando los nodos de acceso de origen y de destino se sirven por la misma pasarela, solamente una función de estación base (tal como las funciones de NodoB programable 708) se puede reubicar al nodo de acceso de destino. La reubicación de funciones de los nodos de acceso se realiza independientemente del traspaso de radio, de modo que durante un tiempo después del traspaso de radio, el nodo de acceso de origen continúa sirviendo contenido al terminal móvil a través del nodo de acceso de origen. El encaminamiento de paquetes de datos para la red de 3G entre los nodos de acceso de destino y de origen se puede realizar usando una interfaz Iu entre la función de RNC o de BRAS 712 del nodo de acceso de destino y la función de SGSN/GGSN 714 del nodo de acceso de origen. Alternativamente, el encaminamiento de paquetes de datos entre los nodos de acceso de destino y de origen se puede completar por la función de SGSN/GGSN 714 del nodo de acceso de destino que conecta directamente con las funciones del nodo de acceso de origen a través de una interfaz de IP.
Después de que se haya completado el traspaso en el paso 12B, el nodo de acceso que controla el terminal móvil se puede reubicar desde el nodo de acceso de origen al nodo de acceso de destino en coordinación con la pasarela, las decisiones de traspaso estandarizadas (principalmente basadas en cobertura, calidad, potencia, interferencia, etc.) para red de 2G, 3G, LTE y fija se usan para mover el móvil desde un nodo o sistema a otro. No obstante, la plataforma 700 introduce una nueva oportunidad para tomar la decisión de traspaso en base al tipo o las características de cierta aplicación, tipo de usuario y los requisitos de QoS.
El momento de la reubicación de las funciones de nodo de acceso desde la plataforma de origen a la de destino puede ser dependiente de lo siguiente:
• la duración de la conexión/comunicación actual del terminal móvil
• la velocidad de movimiento del terminal móvil
• las características de las aplicaciones que se usan por el dispositivo móvil, la calidad del servicio, el tipo previsto y las cantidades de transmisión en curso.
• el estado de asignaciones de recursos de radio en el terminal móvil
• el nodo respectivo de los nodos de acceso de origen y de destino.
En el paso 12D, opcionalmente, algunas funciones se reasignarán desde los nodos de acceso a la pasarela. Por ejemplo, si el nodo de acceso de destino se carga considerablemente y está congestionado, o tiene una capacidad menor que el nodo de acceso de origen o el terminal móvil se determina que es muy móvil, puede ser ventajoso transferir funciones a la pasarela. Las funciones se reasignan del nodo de acceso a la pasarela, por ejemplo, por una reubicación de Subsistema de Red de Radio de Servicio (SRNS) entre la función de RNC 712 del nodo de acceso y la pasarela. Alternativamente, las funciones se pueden reasignar realizando una reconfiguración de radio de la conexión de usuario al terminal móvil.
La reubicación de funciones desde un nodo de acceso a la pasarela se puede realizar en la configuración de sesiones de llamada/comunicación. En la configuración de sesiones de llamada/comunicación, se proporcionará información de abonado adicional, que se puede usar por el nodo de acceso o pasarela para determinar si sería ventajoso reubicar las funciones del nodo de acceso a la pasarela. La reubicación de funciones desde el nodo de acceso 800 a la pasarela 802 se puede realizar durante una conexión activa cuando se ha modificado un requisito de las sesiones de comunicación, o donde el recurso requerido no está disponible en el nodo de acceso 800.
Según los mismos principios, las aplicaciones se pueden (re)ubicar (o distribuir) entre nodos de acceso 800 y para que las pasarelas 802 proporcionen entrega de aplicación optimizada/mejor uso de los recursos de comunicación. Como se ha mencionado anteriormente, se almacena información acerca de cada aplicación usada por el usuario en el terminal móvil en un contexto de aplicación. El contexto de aplicación se comparte entre cada nodo de acceso 800 y la pasarela 802 que controlan la conexión de usuario para ese terminal móvil. Uno de los nodos de acceso 800/pasarelas 802 será el “maestro” para esa aplicación particular, y ese también será el maestro de un registro específico de aplicación en el contexto de aplicación. El contexto de aplicación se sincroniza periódicamente ventajosamente entre el nodo de acceso 800 y la pasarela 802.
La información de aplicación es el contexto de aplicación específico para un terminal móvil particular, y esto se pasa entre nodos de acceso y pasarelas durante la reasignación para un terminal móvil, permitiendo que la aplicación se pase sin problemas a nodos de acceso/pasarelas, evitando impactos en la experiencia del usuario.
La Figura 9 muestra la transferencia de información de aplicación entre nodos de acceso y pasarelas.
Adaptar el ancho de banda a la aplicación
Las mediciones de radio recibidas desde la parte de radiofrecuencia del NodoB, de la Femto y del AP que sirve al terminal móvil se pasan a los nodos programables 702 de la plataforma 700 (del nodo de acceso 800 o de la pasarela 802 que sirve al terminal móvil) y se pasan a las funciones de red 704 de la plataforma 700, que entonces distribuye las mediciones a donde sea necesario dentro de la plataforma 700. La plataforma 700 tiene acceso a la información de abonado desde la red central, que permite que las funciones de red 704 entreguen tráfico de datos de una manera que se optimiza para condiciones de radio como se indica por las mediciones de radio. El tráfico de datos también se puede optimizar según la suscripción del usuario del recurso de radio disponible del terminal móvil, la capacidad del terminal móvil y/o para la clase del terminal (por ejemplo, tecnologías de acceso usadas). Esta optimización permite que el uso de ancho de banda se equilibre con la experiencia del usuario. La información de abonado puede incluir información acerca del plan de precios del usuario del terminal móvil. El operador de red móvil puede hacer el seguimiento del tipo de aplicación usada por el usuario, del uso de datos total del usuario y puede enfocarse diferencialmente a los recursos de radio el mayor flujo de valores de datos de usuarios.
Alojando las aplicaciones 740, 742 en la parte de servicios 706 de la plataforma el nodo de acceso 800 (o al menos la pasarela 802), el punto de la red que es consciente de la aplicación que se usa por el usuario del terminal móvil más cercano en el enlace entre el terminal móvil y la red central al NodoB que sirve al terminal móvil. Esto permite la compartición de los recursos de red a los flujos de datos más adecuados, tales como los flujos de datos más rentables. Tal conciencia de la aplicación a la que se refiere una solicitud de transmisión de datos permite que el uso de flujos de datos de valores bajos, tales como compartición de archivos de igual a igual, se asigne solamente ancho de banda limitado, de modo que el ancho de banda restante se pueda destinar a usuarios particulares. En el enlace ascendente, se puede controlar la transmisión de datos por el nodo de acceso 800 (o pasarela 802) que aloja la aplicación para controlar el flujo de datos adecuadamente antes de que los datos se transmitan posteriormente hacia el núcleo de la red (que no era posible con disposiciones convencionales).
Interfaz de programación de aplicaciones (API)
Como se ha mencionado anteriormente, se proporciona una API novedosa que define el lenguaje que cada uno de los módulos de software 740, 742 de la plataforma 700 usa para comunicar, para coordinar y para optimizar la entrega de aplicación a los usuarios. La plataforma 700 negocia con cada aplicación 740, 742 los requisitos de recursos y rendimiento específicos en base a las características de la aplicación, permitiendo que la aplicación comunique directamente los requisitos de rendimiento de programación, en lugar de usar un conjunto predefinido de parámetros calidad de servicio. Esta negociación entre la plataforma 700 y las aplicaciones 740, 742 se facilita por la API.
La API también puede facilitar la provisión de información de calidad de enlace de radio (por ejemplo, a partir de la función de QoS 732) a las aplicaciones 740, 742.
La API puede permitir además que la plataforma 700 controle el uso de las aplicaciones 740, 742, por ejemplo, para permitir, no permitir o adaptar las aplicaciones.
A modo de ejemplo, la aplicación 740 puede ser una aplicación de Voz sobre IP (VoIP). La naturaleza de comunicaciones de Voz sobre IP es que hay una sucesión virtualmente continua de pequeños paquetes de datos en los que se comunican datos de voz. Los datos de voz se deben comunicar sin o con latencia mínima con el fin de que una conversación bidireccional se puede realizar con éxito. La aplicación de Voz sobre IP 740 es capaz de comprimir datos de voz antes de la transmisión usando una variedad de técnicas/CODEC. Las técnicas de comprensión/CODEC pueden variar desde una técnica de compresión relativamente baja, que proporciona reproducción de voz de alta calidad pero requiere un ancho de banda grande, hasta una técnica de compresión mucho más alta que proporciona calidad de voz reducida y que requiere un ancho de banda mucho menor.
La API se opera para proporcionar detalles de las características de aplicación a la parte de funciones de red 704 de la plataforma 700. Esto hace que la parte de funciones de red 704 de la plataforma sea consciente de las características de la aplicación. En el presente ejemplo, como la aplicación es una aplicación de Voz sobre IP, la parte de funciones de red 704 se puede dar cuenta de que la aplicación tenderá a transmitir sucesiones continuas de pequeños paquetes de datos que requieren transmisión sin o con poca latencia. La función de red 704 se puede configurar entonces adecuadamente.
La API además puede ser operable para permitir que la parte de funciones de red 704 comunique información de calidad de enlace de radio a la aplicación 740. Por ejemplo, cuando la parte de funciones de red 704 recibió información con respecto a las características de la aplicación (a través de la API), puede asignar recursos de enlace de radio a esa aplicación 740. Esta asignación de recursos de enlace de radio se puede comunicar por la parte de funciones de red 704 a la aplicación 740 (a través de la API). La aplicación 740 puede seleccionar entonces una técnica de compresión/CODEC adecuado en dependencia de la calidad de enlace de radio disponible. Durante una llamada de Voz sobre IP, la calidad de enlace de radio disponible se puede comunicar regularmente de la parte de funciones de red 704 a la aplicación 740 (a través de la API) para permitir que la aplicación 740 varíe la técnica de compresión/CODEC usado según los cambios de la calidad de enlace de radio.
La parte de funciones de red 704 puede controlar cómo funcionan las aplicaciones 740, 742 (a través de la API). La parte de funciones de red 704 puede permitir, no permitir o adaptar las aplicaciones 740, 742 alojadas en la parte de servicios 706 de la plataforma 700. Por ejemplo, la parte de funciones de red 704 puede requerir que la aplicación de Voz sobre IP 740 use una técnica de compresión/CODEC particular si está restringido el ancho de banda de enlace. Otro ejemplo de cómo la parte de funciones de red 704 puede proporcionar ventajosamente información de calidad de enlace de radio a una aplicación (a través de la API) es cuando la aplicación 742 es una aplicación de juego usada por varios usuarios. Si la información de calidad de enlace de radio recibida por la aplicación 742 indica que está restringido el ancho de banda, la aplicación 742 puede adaptar sus comunicaciones a usuarios de manera que la latencia de las comunicaciones se aumente uniformemente para todos los usuarios (de modo que todos experimenten el mismo retardo), con fin de que se dote a cada uno de los usuarios con la misma experiencia de juego.
En las disposiciones descritas, los dispositivos que se conectan con la plataforma 700 son dispositivos móviles que conectan con las plataformas a través de la red de acceso por radio de una red de telecomunicaciones móviles/celulares. Se debería apreciar que los dispositivos no móviles (fijos) se pueden conectar a las plataformas 700, por ejemplo, mediante una conexión cableada o por cable.
Asignación de servicios
Los medios de control son responsables de asignar la instancia de servicio para cada UE, en base a las ubicaciones del UE y la capacidad, habilidad y recursos disponibles de los medios de control para alojar otra instancia de un servicio. El UE está usando un servicio pero el Usuario (MSISDN) da acceso a servicios específicos.
Para ciertos servicios de baja popularidad o donde la capacidad o habilidad de los medios de control de servicio disponibles es limitada, el servicio se puede alojar desde unos medios de control central o desde unos medios de control distribuidos colindantes.
Para algunos servicios/funciones, donde las aplicaciones de cliente de origen y de destino están en la misma región geográfica, siendo servidas por el mismo emplazamiento (por ejemplo, ubicación de BTS) o el mismo grupo de emplazamientos (por ejemplo, número finito de emplazamientos), el nodo de acceso 800/pasarela 802 asegura que el servidor para el servicio se sitúa cerca de ambos usuarios y el tráfico se encamina entre los usuarios dentro del emplazamiento.
La disposición descrita anteriormente con relación a las Figuras de 1 a 9 es la materia objeto del documento EP2315412. Tal disposición se ocupa de LI y otras funciones de red central encaminando siempre tráfico que se debe someter a LI y otras funciones de red central a través de la red central o proporcionado funcionalidad de LI y otras funciones de red central en el borde de la red.
Una representación conocida alternativa de la plataforma 700 se muestra en la Figura 10. La plataforma 700 incluye un núcleo de plataforma 1000 que se comunica en base a dos conjuntos de API:
API de aplicación 1010, que, como se ha tratado anteriormente, ofrecen un entorno de alojamiento estandarizado para aplicaciones que proporcionan comunicación a Software de Servicio 741, 742 y Software de Funciones de Red 1015, 1016 alojados en la plataforma 700.
API de red 1017, que proporcionan control y conectividad a nodos de red 1030 a través de Adaptadores específicos de proveedor 1020; la API de red define comunicación estandarizada entre el núcleo 1000 y los Adaptadores 1020; la comunicación entre nodos de red de Adaptador 1020 y un nodo de 3GPP/LTE, tal como (e)NodoB 1, BBU 1032, RNC 3, SGSN 5 GGSN 6/P-GW y MME 1040, sigue siendo propietaria.
La plataforma 700 incluye Software de funciones de red común 1015, 1016 tal como funciones de programación, encaminamiento, facturación/contabilidad, seguridad y política, que permiten que la arquitectura ofrezca una experiencia sin problemas a través de la red. La plataforma 700 proporcionará capacidad para cumplir los requisitos de Intercepción legal (LI).
Los Adaptadores 1020 traducen la implementación específica de proveedor en los nodos de 3GPP/LTE 1030, tales como eNB, BBU, RNC, SGSN, GGSN/P-GW y MME, a una interfaz común y abierta al entorno de la plataforma 700. El Adaptador 1020 para cada nodo de 3GPP/LTE 1030, tal como eNB, BBU, RNC, SGSN, GGSN/P-GW y MME, es responsable de asegurar que la comunicación entre la API de Red 1017 y el nodo de 3GPP es segura.
La Plataforma 700 proporciona la capacidad de algunas Aplicaciones 741, 742 alojadas en la Plataforma 700 de ser contactadas remotamente desde la plataforma 700.
Lógicamente, las interfaces de tráfico de control y datos (plano de control y plano de usuario) entre las manifestaciones físicas de la plataforma 700 existen independientemente de los nodos de red de 3GPP/LTE 1030 subyacentes. Estas interfaces requerirán ser seguras a través de la funcionalidad incluida dentro de cada plataforma 700.
La Plataforma 700 también proporciona la capacidad de Red alojadas 1015, 1016 y Aplicaciones de Servicio 741, 742 en diferentes plataformas 700 para comunicar y pasar datos de una manera segura sin exigir que se proporcione seguridad por la aplicación 741,742, 1015, 1016.
En contraste con las disposiciones descritas anteriormente, en esta implementación la plataforma 700 puede manejar tanto interfaces de tráfico de control como de datos (plano de control y plano de usuario), en lugar de solo el tráfico de datos/plano de usuario. Además, en contraste con las disposiciones descritas anteriormente, la naturaleza de la pasarela 802 puede ser diferente. En la implementación descrita en lo sucesivo, la pasarela 802 se puede situar distinta de en el RNC. Por ejemplo, la pasarela 802 se puede situar en el SGSN 5, GGSN 6, VAS 7 o aparato de PCRF 9, o en cualquier parte del núcleo de la red o RAN. En la implementación descrita en lo sucesivo, la pasarela 802 se puede considerar que es una interfaz entre las plataformas 700 en el nodo de acceso (800) y la red central, en lugar de parte de los “medios de control”.
Cuando el entorno de la plataforma 700 se introduce en la red móvil significa que se puede insertar, alojar o crear tráfico en el camino de datos entre el GGSN 6 y el UE, impactando potencialmente la operación de sistemas centrales existentes (tales como tarificación, aplicación de política y LI de otros componentes de red central (Reglas de tarificación y Red de IT 9A, Servidor de Política 9 e incluyendo la Base de Datos de Intercepción legal (DB de LI) 30, véase la Figura 2)) que necesitan ser replicados.
Compendio de la invención
Según un aspecto de la presente invención, se proporciona una red de telecomunicaciones móviles que incluye: una red de acceso por radio que tiene medios de radio para comunicación inalámbrica con una pluralidad de terminales registrados con la red de telecomunicaciones y medios de control operables para proporcionar servicios a los usuarios de los terminales conectados a la misma;
un núcleo que tiene medios de procesamiento de contenido operables para proporcionar un servicio basado en la nueve con relación al contenido correspondiente al servicio central;
unos medios de procesamiento de contenido alojados en la nube operables para proporcionar un servicio basado en la nube con relación al contenido correspondiente al servicio central;
en donde los medios de control son operables para transmitir datos a los medios de procesamiento de contenido alojados en la nube para la ejecución del servicio basado en la nube sobre los mismos.
El servicio basado en la nube puede incluir al menos una de carga de contenido e intercepción legal.
Los medios de control y los medios de procesamiento de contenido alojados en la nube pueden ser son operables para crear una conexión de encapsulación de IP entre los mismos.
Los medios de control pueden ser operables para transmitir datos en la conexión de encapsulación IP en un paquete de datos que incluye el contenido, o una indicación del contenido, y al menos uno de: ID de terminal, Identidad de portador, identidad de aplicación, marca de tiempo, dirección de flujo e información tarificación.
Los medios de procesamiento de contenido alojados en la nube pueden ser operables para recibir el paquete de datos y para realizar al menos una de las funciones de tarificación de contenido y de intercepción legal sobre los mismos.
La red de acceso por radio y el núcleo pueden ser operables para crear una conexión de Protocolo de Tunelización de GPRS, GTP, (GTP-U) entre los mismos para proporcionar el servicio central con relación al contenido.
Los medios de control pueden ser operables para seleccionar si el contenido se envía a los medios de procesamiento del núcleo o a los medios de procesamiento de contenido alojados en la nube. La selección se puede realizar en dependencia de la movilidad del terminal al que se refiere el contenido.
El término “nube” tiene su significado habitual en informática, un término general para todo lo que implica la entrega de servicios alojados sobre Internet. Esto se puede contrastar con los servicios proporcionados por el núcleo de red de telecomunicaciones, que puede no ser parte de Internet.
Según otro aspecto, se proporciona un método de operación de una red de telecomunicaciones como se define en las reivindicaciones.
Los aspectos de la invención están definidos por las reivindicaciones independientes.
Breve descripción de los dibujos
Para una mejor comprensión de la presente invención, se describirán ahora realizaciones a modo de ejemplo, con referencia a los dibujos que se acompañan, en los que:
Las Figuras de 1 a 10 muestran disposiciones de “plataforma” conocidas, como se han descrito anteriormente; La Figura 11 muestra el flujo para instalación de política a través de la Pasarela de SAVi;
La Figura 12 muestra el registro de flujo de una aplicación en una Pasarela de SAVi;
La Figura 13 muestra un nuevo túnel de comunicación establecido entre la Plataforma de SAVi y la Pasarela;
La Figura 14 muestra la Plataforma de SAVi configura con Plantillas de Aplicación;
La Figura 15 muestra un modelo de ejemplo para la Pasarela de SAVi;
La Figura 16 muestra el Posicionamiento de Contenido a través de Arquitectura de Pasarela de SAVi;
La Figura 17 muestra la Recuperación de Información a través de Arquitectura de Pasarela de SAVi;
La Figura 18 muestra el Flujo de recuperación de información a través de la Pasarela de SAVi;
La Figura 19 muestra el Flujo de tarificación de aplicación de SAVi a través de la Pasarela de SAVi;
La Figura 20 muestra un Diagrama de Arquitectura para Movilidad de SAVi a SAVi;
La Figura 21 muestra un Diagrama de Arquitectura para Movilidad de SAVi a no SAVi;
La Figura 22 muestra el flujo para movilidad de capa de red de SAVi;
La Figura 23 muestra el flujo de transferencia de contexto de aplicación;
Las Figuras 24A-C muestran almacenamiento central o local de información/contexto de aplicación, cuando el UE libera una conexión de RRC;
La Figura 25 muestra un spool de enlace ascendente de Plano de usuario de SAVi a través de un diagrama de flujo de Portador de EPS;
La Figura 26 es un Diagrama de Flujo de un Adjunto o TAU de un abonado de política de eNB de origen que persiste a través de la P-GW;
La Figura 27 es un Diagrama de Flujo de reinstalación de Política después de una nueva solicitud de servicio a través de la P-GW;
La Figura 28 es un Diagrama de Flujo de reinstalación de Política después de un procedimiento de Liberación de S1; La Figura 29 es un Diagrama de Flujo de reinstalación de Política en el eNB de Origen original en la devolución de Traspaso del eNB de destino;
La Figura 30 es un Diagrama de Flujo de Política Modificada después o durante una nueva solicitud de servicio a través de la MME;
La Figura 31 muestra LI soportada por de Arquitectura de P-GW Mejorada de SAVi;
La Figura 32 muestra soporte de LI en conceptos de “Telecomunicaciones sobre la nube” según una realización de la invención; y
La Figura 33 muestra una nueva cabecera formateada especialmente para una solución de encapsulación de IP según una realización de la invención.
En las figuras, los elementos similares se designan generalmente con los mismos números de referencia.
Descripción detallada de las realizaciones de la invención
Aspectos opcionales de la invención
La presente invención proporciona estos aspectos, que se pueden implementar individualmente o en cualquier combinación.
(18.1.2) Descubrimiento de capacidad basada en MME - Indicación de Soporte de PDN-GW habilitada por SAVi a través de MME
Los flujos de señalización se describen a continuación con referencia a la Figura 11, que muestra el flujo de instalación de política a través de la Pasarela de SAVi.
Instalación de política
En este ejemplo, la Identidad de Usuario se proporciona a la Plataforma de SAVi por la MME sobre la interfaz S1-c. Ocurren los siguientes flujos:
1) Cuando el UE10 está en modo inactivo de RRC y tiene datos para enviar, el UE10 envía un mensaje de Solicitud de Servicio a la MME 2010 solicitando un servicio de datos.
2) En línea con el procedimiento de activación de servicio de LTE normal, la MME 2010 envía el mensaje de Solicitud de Configuración de Contexto Inicial al eNB 2000 incluyendo los parámetros de servicio para que el eNB 2000 maneje correctamente el UE10. Este mensaje se mejora para incluir IE de INFO de SUB de SAVi que transporta el Identificador del UE y otros parámetros de SAVi de la Información de Abonado recibida desde el HSS36, y el IE DE INFO DE E-RaB DE sAvI para cada E-RAB con Portadores de Radio activos que transportan la información de APN. La inclusión del IE DE INFO DE E-RAB indica a la Plataforma de SAVi 700 que la P-GW asociada con el E-RAB se ha actualizado para soportar funcionalidad de SAVi. La MME 2010 determina el soporte de SAVi de P-GW a través de la mejora de la señalización de capacidad existente sobre S5/8 y S11 o realizando una búsqueda de DNS del nodo de P-GW, donde la respuesta de DNS incluye información de capacidad.
3) El eNB 2000 informa a la Plataforma de SAVi 700 que se han asignado recursos de radio a un UE en una celda controlada por el eNB 2000 y proporciona el Identificador de UE y la información de APN.
4) La Plataforma de SAVi 700 contacta con la Pasarela de SAVi 2020 y registra interés en el UE10 con el mensaje de REGISTRO DE UE DE SAVI. La Plataforma de SAVi 700 usa el Identificador de UE y la información de APN para referenciar el UE y el Portador.
5) Si la Pasarela de SAVi 2020 no tiene ya información de Perfil para este UE10, contacta con los Sistemas Centrales 2030, por ejemplo, la PCRF9 y HSS36, y recupera la información de Cliente/Portador necesaria.
6) La Pasarela de SAVi 2020 almacena el Perfil de UE y una unión del UE10 y la Plataforma de SAVi 700 en una base de datos local.
7) La Pasarela de SAVi 2020 proporciona la Información de Política para el UE10 a la Plataforma de SAVi 700 en el mensaje de TRANSFERENCIA DE PERFIL DE UE DE SAVI, donde se almacena. El Perfil de UE de SAVI incluye una lista de ID de Grupos de Clientes a los que pertenece el UE y cada Grupo de Clientes tendría un Perfil configurado en la Plataforma de SAVi. La Información de Perfil puede desencadenar la Plataforma de SAVi para solicitar/sacar cualquier información específica de Aplicación para el UE almacenado centralmente.
Modificación de política
Posteriormente, si se cambia el perfil dentro de la red de un UE:
8) Los Sistemas Centrales 2030 informan a la Pasarela de SAVi 2020 de un cambio en la Política de un UE. 9) La Pasarela de SAVi 2020 almacena el perfil actualizado del UE10 y busca qué Plataformas de SAVi 700 tienen restricciones activas para un UE10.
10) La Pasarela 700 de SAVi 2020 envía un mensaje de TRANSFERENCIA DE PERFIL DE UE DE SAVI a cada una de las Plataformas de SAVi 700 incluyendo la última Información de Política del UE10.
Alternativamente, si el cambio en el Perfil impacta un gran grupo de los UE y estos UE pertenecen todos al mismo Grupo de Clientes, la GW de SAVi puede enviar el mensaje de TRANSFERENCIA DE CONFIGURACIÓN DE GRUPO DE SAVI a la Plataforma de SAVi para modificar la información de Perfil asociada con el Grupo de Clientes. La Plataforma de SAVi responde con el mensaje de ACK DE TRANSFERENCIA DE CONFIGURACIÓN DE GRUPO DE SAVI que confirma que se ha cambiado el Perfil.
(12.2.1) La Plataforma de SAVi 700 se da cuenta de que la MME 2010 se ha actualizado para soportar procedimientos de SAVi mediante la inclusión de IE DE INFO DE SUB DE SAVI dentro del mensaje de Solicitud de Configuración de Contexto Inicial sobre la interfaz S1.
La inclusión de la IE DE INFO DE E-RAB en el mensaje de Solicitud de Configuración de Contexto Inicial indica a la Plataforma de SAVi 700 que la P-GW asociada con el E-RAB se ha actualizado para soportar funcionalidad de SAVi. La MME 2010 determina el soporte de SAVi de P-GW a través de mejora de la señalización de capacidad existente en S5/8 y S11 o realizando una búsqueda de DNS del nodo de P-GW, donde la respuesta de DNS incluye información de capacidad.
También se hacen cambios similares al mensaje de CONFIGURACIÓN DE E-RAB, los mensajes de SOLICITUD DE MODIFICACIÓN DE CONTEXTO DE UE y de SOLICITUD DE TRASPASO sobre la interfaz S1c, con una implicación común para la Plataforma de SAVi.
Descubrimiento de Capacidad
Estos aspectos incorporan unos medios por la MME 2010 para interrogar la capacidad de la PDN-GW para soportar procedimientos de SAVi, a través de búsqueda de DNS, y desencadenar el procedimiento para incluir información relacionada con SAVi dentro de la señalización del 3GPP a la Plataforma de SAVi 700 si la PDN-GW asociada con el portador de usuario soporta SAVi. La inclusión u omisión de la política de SAVi del UE puede ser una indicación implícita a la Plataforma de SAVi 700 acerca de si la PDN-GW soporta funcionalidad de SAVi.
(18.1.4) Señalización/tunelización de aplicación en S1
Sección: 3.5, Pasarela de SAVi
La Pasarela de SAVi 2020 es una función lógica dentro de la arquitectura que es responsable de conectar con las Plataformas de SAVi 700 alojadas en la Red de Acceso por Radio, sobre una nueva interfaz a la que se hace referencia como la interfaz S1-s.
La Pasarela de SAVi 2020 es responsable de realizar una serie de papeles:
• Terminar Interfaces específicas de Usuario y Aplicación a cada una de las Plataformas de SAVi y gestionar la correlación entre Clientes y Plataformas de SAVi.
• Actuar como un mediador entre sistemas centrales y las muchas Plataformas de SAVi a través de la red de acceso para la entrega de política específica de Usuario y/o Aplicación a la Plataforma de SAVi.
• Actuar como un agregador de información de Plataformas de SAVi antes de la exposición a las aplicaciones o funciones alojadas centralmente. Implicado potencialmente en el soporte de movilidad.
7.3.1.1, Funciones de cada entidad implicada
Las Aplicaciones de SAVi 741, 742, A comunican con la funcionalidad de Tarificación de SAVi en la Plataforma de SAVi 700 usando una API definida, para proporcionar información de tarificación tanto específica de usuario como específica de aplicación. La Aplicación de SAVi se configura en la instalación con las reglas asociadas con los derechos asociados con acceso a las API de Tarificación disponibles en la Plataforma de SAVi.
La funcionalidad de Tarificación de SAVi en la Plataforma de SAVi agrega el material de tarificación de múltiples aplicaciones, empaquetando estas para su entrega a la Pasarela de SAVi 2020. La funcionalidad de Tarificación de SAVi en la Plataforma de SAVi también puede realizar recuento de volumen y notificación basada en eventos para aplicaciones específicas y para usuarios específicos. Las políticas de UE o Aplicación definen si se requiere cualquier funcionalidad de Tarificación de Aplicación relacionada con aplicaciones de SAVi situadas en la Plataforma de SAVi. El material de Tarificación se pasa a la funcionalidad de Tarificación de SAVi igual en la Pasarela de SAVi 2020 que es responsable de desempaquetar el material de tarificación y que interactúen éstos en los Sistemas de Tarificación (por ejemplo, al GIG).
La Plataforma de SAVi 700 es responsable del establecimiento de una conexión de señalización asociada con la Aplicación de S1-s entre la Plataforma de SAVi y la Pasarela de SAVi 2020 cuando se inicia y de pasar cualquier mensaje de Tarificación a o desde la funcionalidad de Tarificación de SAVi a esta conexión de señalización.
La Pasarela de SAVi 2020 es responsable del establecimiento de una conexión de señalización asociada con la Aplicación de S1-s con la Plataforma de SAVi y de pasar cualquier mensaje de Tarificación a o desde la funcionalidad de Tarificación de SAVi alojada en la Pasarela de SAVi.
12.3.2 Registro de aplicación
Como se muestra en la Figura 12, cuando se inicializa una aplicación (Aplicación A) en la Plataforma de SAVi 700, la Plataforma de SAVi registra la Aplicación en la Pasarela de SAVi 2020:
1) La Plataforma de SAVi 700 envía el mensaje de Registro de Aplicación de SAVi a la Pasarela de SAVi incluyendo el Identificador de la Aplicación.
2) La Pasarela de SAVi 2020 acepta el registro a través del mensaje de Aceptar Registro de Aplicación de SAVi y la conexión de S1s asociada con la Aplicación se establece para la Aplicación.
3) La Aplicación A puede pasar entonces mensajes a la Plataforma de SAVi 700 para la transmisión por la Plataforma de SAVi 700 a la Pasarela de SAVi 2020. La Plataforma de SAVi 700 empaqueta el mensaje en el mensaje de INFO DE UL DE APLICACIÓN DE SAVI incluyendo el identificador de la Aplicación y pasa éste a la Pasarela de SAVi 2020 en el canal de señalización asociado con la Aplicación en la interfaz S1s a la Pasarela de SAVi 2020. La Pasarela de SAVi 2020 pasa este mensaje a la Aplicación de SAVi alojada localmente indicando el identificador de la Plataforma de SAVi donde está siendo alojada la Aplicación.
4) La Aplicación alojada en la Plataforma de SAVi también puede enviar mensajes a otra instancia de la Aplicación en una Plataforma de SAVi pasando un mensaje a la Pasarela de SAVi con una indicación de la Plataforma de SAVi donde está siendo alojada la instancia. La Pasarela de SAVi empaqueta el mensaje en el mensaje de INFO DE DL DE APLICACIÓN DE SAVI sobre la interfaz S1s con la Plataforma de SAVi respectiva. La Plataforma de SAVi que recibe el mensaje reenvía este mensaje a la aplicación prevista.
Se señala en relación con este aspecto que dentro de la arquitectura de LTE del 3GPP, la principal interfaz de control al eNB es la interfaz S1-c y esta interfaz proporciona funcionalidad para entregar información de control a la Plataforma de SAVi 700 y también para tunelizar la información de control de UE que se ejecuta entre la MME 2010 y el UE10.
Una variante del diseño de Arquitectura de SAVi implica la inclusión de la Pasarela de SAVi 2020 y esta nueva entidad es responsable de actuar como un mediador entre las muchas Plataformas de SAVi 700 y los sistemas centrales de una red móvil. La Plataforma de SAVi 700 y la Pasarela de SAVi 2020 se comunican sobre una interfaz definida como la S1s.
Como se muestra en la Figura 13, se propone que se establezca un nuevo túnel de comunicación entre la Plataforma de SAVi 700 y la Pasarela de SAVi 2020 para cualquier aplicación que requiera señalización similar a control a una entidad central en la red, y por lo tanto la Plataforma de SAVi 700 no necesita exponer y gestionar/proteger una interfaz externa para cada aplicación alojada en la Plataforma de SAVi 700, y la Aplicación alojada puede comunicar solamente información de control a través de la Pasarela de SAVi 2020.
Similar a la arquitectura del 3GPP, se propone que se establezca un nuevo túnel de Control (mecanismo de encapsulación) entre la Plataforma de SAVi 700 y la Pasarela de SAVi 2020 para la entrega de información de Control a las Aplicaciones alojadas en la Plataforma de SAVi 700. Dentro de la Pasarela de SAVi 2020 la información de control se puede manejar por la Pasarela de SAVi 2020 o por una aplicación igual de la alojada en la Plataforma de SAVi 700. El beneficio de esta solución es que los módulos dentro de la Plataforma de SAVi 700 y la Pasarela de SAVi 2020 que son responsables de la comunicación/S1s no se requiere que comprendan los contenidos de la información de control de la Aplicación y por lo tanto las hojas de ruta de los diferentes módulos de SW (es decir, Aplicación e interfaz S1s) serán independientes.
Cuando se inicializa una Aplicación la Plataforma de SAVi 700 registra la aplicación con la Pasarela de SAVi 2020 y se establece una conexión S1s asociada con la Aplicación, todo tráfico futuro entre las Aplicaciones iguales fluye transparentemente sobre la interfaz S1s.
(18.1.5) Plantillas de Aplicación - uso de plantillas para controlar el encadenamiento de servicio dentro de la Plataforma de SAVi para un UE específico
Sección: 4.3.3.1, Funciones de cada entidad implicada
La información de abonado de HSS se puede actualizar para incluir alguna información de Política de SAVi específica, que se pasaría a la MME 2010 como parte del proceso normal de Insertar Datos de Abonado desde el HSS 36.
La información de Política de SAVi identifica la lista de las Aplicaciones aplicables al UE10, y una plantilla referencia reglas configuradas previamente en la Plataforma de SAVi 700 lo que permite que la Plataforma de SAVi 700 construya una tabla de encaminamiento para paquetes de este UE10 entre las Aplicaciones alojadas.
4.3.4.2, Funciones de cada entidad implicada
Los registros de Abonado en el HSS 36 se actualizan para incluir un nuevo identificador de UE, que se pasa a la MME 2010 con la información de Abonado existente cuando el dispositivo se une a la red.
La MME 2010 se mejora para incluir el identificador de UE y la información de APN asociada con el dispositivo y sus portadores de Radio establecidos en señalización existente en la interfaz S1-c como parte del establecimiento de portador de Radio y señalización de traspaso basada en S1.
El eNB 2000 indica a la Plataforma de SAVi 700 que ha llegado un nuevo UE10 en una celda controlada por el eNB 2000, y proporciona el Identificador de UE y la información de APN para cada portador activado.
La Plataforma de SAVi 700 registra la información de UE10 y de APN con la Pasarela de SAVi 2020 con la que el eNB 2000 se configura para comunicarse.
Si la Pasarela de SAVi 2020 no tiene una política asociada con el UE10 registrado, la Pasarela de SAVi 2020 recupera la información necesaria del HSS36 (para elementos de política de SAVi estáticos y dinámicos) y potencialmente de la PCRF9 (camino alternativo para elementos de política dinámicos), almacena un enlace entre el UE10 y la Plataforma de SAVi 700 y proporciona la información de política a la Plataforma de SAVi 700 donde se almacena.
La información de Política de UE de SAVi identifica la lista de las Aplicaciones aplicables al UE10, y una plantilla (cadena de servicio de aplicación) referencia reglas configuradas previamente en la Plataforma de SAVi 700 lo que permite que la Plataforma de SAVi 700 construya una tabla de encaminamiento para paquetes de este UE entre las Aplicaciones alojadas.
Cuando la política de UE relacionada con SAVi cambia en los Sistemas Centrales 2030, se informa a la Pasarela de SAVi 2020. La Pasarela de SAVi 2020 recupera una lista de qué Plataformas de SAVi 700 tienen un registro activo para este UE10 y distribuye la política actualizada a estas.
La Plataforma de SAVi 700 puede alojar muchas aplicaciones. Este aspecto concierne a qué ruta entre las aplicaciones debería tomar un paquete.
Como se muestra en la Figura 14, se propone que la Plataforma de SAVi 700 se configure con Plantillas de Aplicación, definiendo el orden en el que se deberían atravesar las aplicaciones para un paquete específico.
a. Plantilla de Aplicación configurada en la Plataforma de SAVi indica el orden en que un paquete pasaría a través de las Aplicaciones alojadas
Figure imgf000019_0001
b. La Plataforma de SAVi también se puede configurar con los Filtros de Tráfico de Aplicación que indican qué tipo de tráfico es de interés para cada aplicación, por ejemplo:
Figure imgf000019_0002
Donde el tipo de paquete se podría describir sobre una base de número de puerto, protocolo, estado, etc., el ejemplo mostrado anteriormente sobre una base de servicio para un ejemplo sencillo.
1. La lista de Aplicaciones Permitidas para un UE se pasaría como parte del perfil de UE a las Plataformas de SAVi:
Figure imgf000019_0003
Figure imgf000020_0003
2. El perfil de UE de SAVi se actualizará para incluir una referencia/puntero de Plantilla para identificar a la Plataforma de SAVi cuál de las Plantillas de Aplicación instaladas se debería usar para el UE.
La plataforma de SAVi 700 crea las reglas de encaminamiento específicas para un UE10 entre las Aplicaciones alojadas a partir de la mezcla de la Plantilla de Aplicación referenciada y la lista de las Aplicaciones de SAVi permitidas para el UE como se define en la política/perfil de UE; para crear el subconjunto de la Plantilla de Aplicación para el UE.
Por ejemplo, si el Perfil de UE indica que la Plantilla de Aplicación 3 se debería usar:
Figure imgf000020_0001
La Plataforma de SAVi 700 podría realizar esto sobre una base de servicio si están presentes los Filtros de Tráfico de Aplicación, por ejemplo:
Figure imgf000020_0002
Según un aspecto particularmente preferido, se puede proporcionar un método de aplicación o encadenamiento de servicio dentro de una plataforma que proporciona aplicaciones o servicios en una red de acceso por radio. El método comprende recibir un paquete de datos, identificar el tipo de paquete a partir de un conjunto predefinido de tipos, comprobar el tipo frente a una plantilla que define el orden en el que el paquete debería pasar a través de una pluralidad de aplicaciones (siendo la plantilla opcionalmente específica al equipo de usuario respectivo asociado con el paquete) y pasar el paquete a través de las aplicaciones en el orden definido por la plantilla.
(18.1.6) Entorno de GW de SAVi - Estructura de la GW de SAVi
Sección 14.4, Pasarela de SAVi
Se requieren unos medios para proporcionar la Plataforma de SAVi con el Identificador de Cliente e información de APN. Una solución es que para esta información se proporcione por la MME mejorada de SAVi.
Se requieren identificadores únicos de Cliente y Portador para permitir una comunicación inequívoca acerca de un cliente o portador entre la Plataforma de SAVi 700 y la Pasarela de SAVi 2020, por ejemplo, para exponer información recogida en la Plataforma de SAVi o para recuperar información de Política para el cliente y aplicaciones alojadas en la Plataforma de SAVi.
La GW de SAVi se puede descomponer en una serie de constituyentes: S1s-AP, entorno de alojamiento de Servicios y Aplicación del plano de usuario, Registro de UE. Un modelo de ejemplo de la Pasarela de SAVi se muestra en la Figura 15.
Las Aplicaciones alojadas podrían soportar la funcionalidad de tarificación basada en la aplicación, funcionalidad de de recuperación/analítica de información, funcionalidad de recuperación de posicionamiento de contenido y contenido que se podría necesitar en la Pasarela de SAVi.
Como se muestra en la Figura 15, la GW de SAVi 2020 se puede descomponer en una serie de constituyentes: S1-s, entorno de alojamiento de Servicios y Aplicación del plano de usuario, Registro de UE.
(18.1.7) Posicionamiento previo de contenido - Estructura y concepto de archivos de índice con indicadores de Restricción de Contenido
Sección: 9.3.1.1, Visión general de Pasarela de SAVi
La Pasarela de SAVi 2020 informa a la Plataforma de SAVi 700 que el nuevo contenido está disponible para la descarga a la plataforma para una aplicación específica enviando un URL de un archivo de descripción a la Plataforma de SAVi. La Plataforma de SAVi 700 descarga el archivo de descripción de un Servidor de Archivos 2050. El archivo de descripción se estructura de la siguiente manera:
Figure imgf000021_0001
Estructura del archivo de descripción
La Plataforma de SAVi 700 saca objetos del Servidor de Archivos según la prioridad de Descarga y el DSCP de los paquetes de IP asociados con cada GET de HTTP solicita que sea marcado un objeto según el parámetro de Prioridad de Transporte incluido dentro del archivo de descripción. El Servidor de Archivos marca paquetes de enlace descendente para la entrega a la Plataforma de SAVi 700 según el DSCP del mensaje GET de HTTP recibido.
La Figura 16 muestra el Posicionamiento de Contenido a través de la Arquitectura de Pasarela de SAVi.
Según este aspecto, la introducción de SAVI en la Red de Acceso permite nuevos casos de uso tales como Almacenamiento de caché de Contenido. Para maximizar el beneficio de rendimiento de usuario, el contenido necesitará estar disponible antes de que se solicite por el cliente.
Se define un esquema por el que una aplicación de caché de contenido central, después de recuperar información de una aplicación de analítica central, crea un archivo de descripción de contenido que enumera los objetos de contenido que se requiere que sean obtenidos por la Plataforma de SAVi 700 y frente a cada (uno o más de): a) la clasificación de tipo de contenido
b) la aplicación para la que se destina el contenido
c) el orden de prioridad de descarga y/o el tiempo de programación de descarga
d) Una prioridad de transporte,
e) prioridad de servicio para la transmisión a un usuario final.
f) Tiempo de vida del contenido
g) Una indicación de si los objetos son para un individuo, un grupo de clientes (por ejemplo, adultos) o todos los clientes,
h) El enlace entre diferentes objetos,
i) La ubicación de cada uno en la caché central.
Se notifica a la Plataforma de SAVi 700 que el archivo de Descripción de Contenido está preparado en una ubicación específica y la Plataforma 700 descarga el archivo.
La Plataforma de SAVi 700 analiza el archivo y descarga cada uno de los objetos según su prioridad. La Plataforma de SAVi 700 marca cada solicitud según la prioridad de transporte. El Servidor de Archivos 2050 sirve los objetos a la Plataforma de SAVi 700, estableciendo la prioridad de los paquetes de carga útil a la prioridad de la solicitud de la Plataforma de SAVi 700.
La Plataforma de SAVi 700 carga estos objetos en la caché local junto con la información asociada, por ejemplo, las restricciones asociadas con su uso, por ejemplo, restricciones de contenido para adultos.
(18.1.8) Mediación de recuperación de información por la GW de SAVi - flujos y lógica para la mediación por la GW de SAVi
Sección 8, Recuperación de información
Una categoría importante de las anteriores aplicaciones es la notificación a través de las API, de eventos de red de la Plataforma de SAVi 700 a otros sistemas y aplicaciones que se pueden situar en la red de recomendaciones o externamente. Es posible definir interfaces específicas entre la Plataforma de SAVi 700 y otros servicios centrales o externos pero a medida que crece el número de aplicaciones de SAVi, esto se debería gestionar a través de un único mecanismo por simplicidad.
La solución propuesta aquí se soporta por una Pasarela de SAVi 2020.
Requisitos específicos
El alcance de la solución es la transferencia de información que no es tráfico de usuario. Puede ser informes de mediciones, eventos de red, KPI de radio o información calculada o derivada en base a información en la Plataforma de SAVi 700. En consecuencia, no hay un requisito de aplicar LI a esta información.
La solución cumple con los siguientes requisitos:
• La Plataforma de SAVi 700 no debe tener una conexión directa a un sistema alojado fuera de la red de telecomunicaciones.
• Debe ser posible hacer anónima cualquier información específica a un usuario.
Es posible para un servicio central/externo establecer y actualizar reglas acerca de la información a ser recuperada de la Plataforma de SAVi 700.
Caso o casos de uso
1) KPI de radio proporcionados a la plataforma de optimización central
2) Información de geolocalización proporcionada para un servicio empresarial externo
3) KPI por abonado proporcionados al motor de analítica de la red de telecomunicación, donde es posible actualizar el conjunto de reglas asociadas con los KPI.
Descripción de la solución
Pasarela de SAVi
Visión general
La Plataforma de SAVi 2020 es responsable de interconectar con las Plataformas de SAVi 700 y de recuperar selectivamente información que se está produciendo por la Plataforma de SAVi 700 o una aplicación alojada en la Plataforma 700 y de entregarla a otros servicios alojados centralmente 2070. Esta información puede ser específica de celda, de usuario o de aplicación.
La Figura 17 muestra la Recuperación de Información a través de la Arquitectura de Pasarela de SAVi.
Funciones de cada entidad implicada
Cuando se inicializa la funcionalidad de Analítica 2060 en la Plataforma de SAVi 700, la Plataforma de SAVi registra la funcionalidad con la Pasarela de SAVi 2020 y se establece una conexión asociada con Aplicación de S1s entre la Plataforma de SAVi 700 y la Pasarela de SAVi 2020. La Plataforma 700 envía un mensaje de Actualización de Analítica que proporciona una lista de Temas de Información a los que la Pasarela de SAVi 2020 se puede suscribir más tarde. Los Temas pueden ser acerca de Celdas, acerca de UE que se conectan a la Plataforma y Aplicaciones que se alojan en la Plataforma.
Cuando la funcionalidad de Analítica 2060 cambia la lista de Temas o la lista de Aplicaciones, la funcionalidad de Analítica 2060 envía el mensaje de Actualización de Analítica incluyendo la nueva lista de Temas que están disponibles. El mensaje se pasa a la Plataforma de SAVi 700 y la Plataforma de SAVi 700 pasa el mensaje a la Pasarela de SAVi 2020 en el mensaje de INFO DE UL DE APLICACIÓN DE SAVI en la conexión Asociada con la Aplicación de S1s.
Cuando un UE10 llega a una celda alojada por un eNB mejorado de SAVi 2000, la Plataforma de SAVi 700 se informa sobre la API. La Plataforma de SAVi 700 registra la existencia del UE10 en la Plataforma 700 con la Pasarela de SAVi 2020. La Pasarela de SAVi 2020 puede suscribirse entonces para recibir información acerca del UE10, de la lista de temas disponibles de los que se ha avisado a la Plataforma 700 en el mensaje de Actualización de Analítica.
La Pasarela de SAVi 2020 se suscribe a temas alojados en la Plataforma de SAVi 700 usando el protocolo de MQTT. Los temas se definirían en formato “CategoríaVTemaVSubtema”:
Figure imgf000023_0001
Temas de suscripción en la Plataforma de SAVi para la recuperación de información
Cualquier aplicación en la Plataforma de SAVi 700 que desee publicar datos fuera de la Plataforma de SAVi 700 comunicaría con la funcionalidad de analítica 2060 alojada en cada Plataforma de SAVi 700 y solicitaría que se ponga a disposición su Tema fuera de la Plataforma de SAVi 700. Si la Aplicación de SAVi está autorizada para exportar información, la funcionalidad de analítica contactaría con la Pasarela de SAVi 2020 para advertir de la disponibilidad del Tema en nombre de la Aplicación de SAVi. Todas las suscripciones al Tema y toda la información que fluye posteriormente sobre el Tema desde la Aplicación de SAVi, se media a través de la funcionalidad de analítica en la Plataforma de SAVi 700.
Aplicación al caso o casos de uso
La Figura 18 muestra el Flujo para la recuperación de información a través de la Pasarela de SAVi.
Cuando la funcionalidad de Analítica se inicia en la Plataforma de SAVi 700, la Plataforma de SAVi 700 registra la funcionalidad con la Pasarela de SAVi 2020 y proporciona una lista de servicios/temas a la que la funcionalidad de Analítica puede proporcionar información, si esta lista cambia la Plataforma de SAVi 700 actualiza la Pasarela de SAVi 2020.
1) Cuando un UE10 tiene una conexión de RRC establecida con el eNB 2000, el eNB 2000 proporciona la información necesaria acerca del UE10 para que la Plataforma de SAVi 700 inicie el procedimiento de Registro de UE con la Pasarela de SAVi 2020. La Pasarela de SAVi mantiene una lista de qué UE se registran a través de qué Plataformas de SAVi 700.
2) Cuando un Servicio 2070 requiere información acerca de un UE (u otro tema), el Servicio 2070 envía un mensaje de Suscripción de MQTT a la Pasarela de SAVi 2020 solicitando información específica acerca del UE, se suscribe a un servicio de Información de la funcionalidad de Analítica dentro de la Pasarela de SAVi 2020. 3) La funcionalidad de Analítica dentro de la Pasarela de SAVi 2020 interroga a una base de datos local para determinar qué Plataforma de SAVi 700 está sirviendo actualmente al UE10 y qué Información se está solicitando ya para este UE10. Si la información adecuada ya está disponible, la funcionalidad de Analítica en la Pasarela de SAVi 2020 cumple la solicitud con esta información.
4) Si la funcionalidad de Analítica en la Pasarela de SAVi 2020 no tiene la información necesaria, la Pasarela de SAVi 2020 se suscribe a un Tema específico de UE disponible a partir de la funcionalidad de Analítica 2060 alojada en la Plataforma de SAVi 700 enviando el mensaje de Suscripción de MQTT a la Plataforma de SAVi 700.
5) La funcionalidad de Analítica en la Plataforma de SAVi 700 acepta la Suscripción con el mensaje de Suback.
6) La Pasarela de SAVi 2020 acepta a su vez la Suscripción del Servicio con el mensaje de Suback.
7) Cuando está disponible la nueva información para la suscripción, la funcionalidad de Analítica 2060 en la Plataforma de SAVi 700 envía el mensaje de Publicación.
8) La funcionalidad de Analítica en la Pasarela de SAVi 2020 distribuye los datos Publicados a cada Servicio con una suscripción activa para este tema usando el mensaje de Publicación.
9) La funcionalidad de Analítica en la Pasarela de SAVi 2020 acusa recibo del mensaje de Publicación con el mensaje de Puback.
10) El Servicio acusa recibo a su vez del mensaje de Publicación con el mensaje de Puback.
Solicitudes a suministradores
Figure imgf000024_0001
Según este aspecto, se observa que la introducción de la Plataforma de SAVi 700 en el eNB 2000 permite que se pueda recoger información de funciones de red de radio y las aplicaciones alojadas para mejorar la experiencia del cliente o permitir nuevos servicios.
Para evitar problemas de escalabilidad en la Plataforma de SAVi 700 y el sistema, se propone que se incluya una función de mediador dentro de la Pasarela de SAVi 2020 para gestionar las interacciones con la Plataforma de SAVi 700.
El papel de la función de mediador incluye uno o más de los siguientes:
a) Quedarse entre medias los servicios remotos 2070 y las Plataformas de SAVi 700, ocultando la necesidad de que los servicios remotos descubran la Plataforma de SAVi 700 para un UE10 específico.
b) Gestión de suscripción de Servicios para temas específicos, evitando que la Plataforma de SAVi 700 tenga que gestionarse.
c) Almacenar en caché los datos publicados de enlace ascendente para temas específicos, para datos a servirse inmediatamente a un Servicio que se suscribe a un Tema, sin requerir que la Plataforma de SAVi 700 reenvíe o espere a la siguiente aparición de cambio/periodo.
d) Agregación de datos publicados para crear diferentes periodos/tendencias promedio, etc.
e) Selección de Temas reportados/granularidad de Tema para asegurar que el procesamiento de la Plataforma de SAVi 700 se minimiza, el mediador selecciona el menor común divisor de Temas a ser proporcionados.
f) Hacer anónimos los datos cuando se requiera.
(18.1.9) Consolidación de tarificación en la Plataforma de SAVi
Sección: 7.3.1.1 (véase anteriormente)
Sección: 7.3.1.2, Aplicación al caso o casos de uso
La Figura 19 muestra el Flujo de tarificación de aplicaciones de SAVi a través de la Pasarela de SAVi.
Si el UE10 está accediendo a contenido alojado por una Aplicación de terceros 740 en la Plataforma de SAVi 700:
1) Para otros casos de uso) La Aplicación de SAVi 700 proporciona material de Tarificación a la funcionalidad de Tarificación de SAVi de la Plataforma de SAVi 700 sobre la API de Tarificación de SAVi definida.
2) (Para este caso de uso) La funcionalidad de Tarificación de SAVi de la Plataforma de SAVi 700 es responsable de generar los CDR asociados con el volumen o eventos. La funcionalidad de Tarificación de SAVi agrega este material con el material de Tarificación recibido de diferentes aplicaciones.
3) El material de Tarificación se coloca dentro del mensaje de Información de Tarificación que se transporta en el mensaje de Información de UL de Aplicación de SAVi en la conexión de señalización asociada con la función de Tarificación de SAVi en la interfaz S1s.
4) La Pasarela de SAVi 2020 recupera el mensaje de la Conexión de Señalización asociada con la Aplicación y pasa a la funcionalidad de Tarificación de SAVi, que desempaqueta el material de Tarificación del mensaje de Información de Tarificación e interconecta esta información con los sistemas de Tarificación 2080.
En este caso de uso, los datos de tarificación se requieren que sean de tasa cero por los mecanismos de tarificación de P-GW existentes, la funcionalidad de Copia de la Plataforma de SAVi 700 incluye información adicional dentro del paquete de Datos de Copia de SAVi, o bien un ID de Aplicación, un ID de Evento o bien una indicación explicita de que se debería aplicar tarificación de tasa cero. El ID de Aplicación o ID de Evento correspondería a una regla de Tarificación específica definida en la P-GW para este UE.
Según este aspecto, se prevé que haya múltiples fuentes de registros de tarificación dentro de la Plataforma de SAVi 700, por ejemplo, diferentes instancias de aplicación o información de volumen/evento generada por la funcionalidad de Tarificación de la Plataforma de SAVi.
Se introduce una función de consolidación de Tarificación que es responsable de agregar información recibida de las aplicaciones alojadas y la funcionalidad de Tarificación de la plataforma y de entregarla a la función de Tarificación 2080 en la Pasarela de SAVi 2070.
Cuando se instala una aplicación, la aplicación se acompaña por un archivo de configuración.
En la GW de SAVi 2020 hay otra función de consolidación de Tarificación, que es responsable de recoger los datos de múltiples Plataformas de SAVi, proporcionado una vista consolidada de los sistemas de tarificación.
(18.1.10) Control de la tarificación de P-GW por la Plataforma de SAVi
Para SAVi, se ha propuesto que la tarificación se mantenga en la P-GW, reutilizando el túnel de GTP-U existente del UE entre el eNB y la P-GW a través de la S-GW.
Se propone que se añadan esquemas de tarificación adicionales/complementarios a la Plataforma de SAVi 700, en cuyo caso existe el reto de cómo sincronizar la tarificación ente la P-GW y la Aplicación de SAVi 740.
Las reglas de tarificación de un cliente se basan en detectar la dirección de destino del flujo de datos y de tasa cero (donde se requiera) en lugar de tarificar por Evento,
Se propone que los datos de COPIA pasados a la P-GW se marquen con:
a) ID de Aplicación/Evento, para permitir que la P-GW procese los datos de COPIA y enlace con reglas de tarificación específicas para el cliente o Aplicación, es decir, si se suscribe entonces se tarificará un evento en lugar del volumen de datos.
b) ID de Aplicación/Evento, para permitir que la P-GW procese los datos de COPIA y enlace para generar nuevos Registros de Tarificación para Aplicaciones en lugar del UE. Estos Registros de Tarificación se usarían por los sistemas de Tarificación para crear facturas para el proveedor de Aplicaciones; y tasar cero el tráfico de cliente.
c) Indicación específica de que los paquetes de IP/tráfico específico se deberían tasar cero por la P-GW. La funcionalidad de Tarificación en la Plataforma de SAVi 700 es responsable de crear registros de tarificación paralelos para o bien: eventos o bien volumen y para o bien usuarios o bien aplicaciones y los sistemas de Tarificación serían responsables de agregar.
18.1.11 Múltiples enlaces ascendentes/enlaces descendentes de S1-u - y reglas de filtrado asociadas en la S-GW Dentro del sistema del 3GPP, la función de la S-GW se queda en la conexión del plano de Usuario entre el eNB 2000 y la P-GW y es responsable de ocultar los eventos de movilidad del UE desde la P-GW.
La conexión del plano de usuario entre la S-GW y el eNB 2000 está compuesta de un túnel de GTP-U de enlace ascendente y uno de enlace descendente, donde el ID de Punto final de Túnel de la S-GW actúa como punto de pivote en eventos de movilidad. Solamente existe 1 túnel de enlace ascendente y 1 de enlace descendente para el UE/Portador en cualquier momento.
Cuando el UE se mueve entre los eNB cuando está en estado conectado de RRC, el nuevo eNB se dota con la dirección de IP de la S-GW así como el TEID y cualquier tráfico de enlace ascendente recibido desde el UE por el nuevo eNB se puede enviar directamente a la S-GW sin ninguna señalización explícita. En la dirección de enlace descendente, el túnel se conmuta del antiguo eNB al nuevo eNB cuando se informa a la S-GW por la MME que conmute el punto final del túnel. La S-GW marca el último paquete de enlace descendente enviado al antiguo eNB con un marcador de punto final.
Cuando se introduce SAVi y una aplicación alojada en la Plataforma de SAVi 700 recoge paquetes del UE10 a una tasa más rápida que los paquetes que se envía a la P-GW, algunos paquetes se almacenarían aún en la Plataforma de SAVi 700 si el UE se traspasa a otra celda.
A) Separación de conexiones de RRc/S1c y S1-u, procedimientos de liberación alternativos a través de la MME, marcador de final de GTP-U de UL
Se propone por lo tanto permitir múltiples conexiones para el UE/portador con la S-GW, la conexión del nuevo en; y también mantener la conexión al antiguo eNB.
En el enlace ascendente, se requiere la S-GW para correlacionar múltiples túneles de GTP-U de enlace ascendente desde múltiples eNB en un único túnel de GTP-U a la P-GW.
B) En el enlace descendente, se propone que se incluya una función de filtrado en la S-GW para seleccionar qué paquetes de enlace descendente se envían en la conexión de GTP-U al antiguo eNB y cuales se envían en la conexión al nuevo eNB.
18.1.12 Movilidad de Red de SAVi - repositorio de información de Movilidad de Aplicación en la GW de SAVi Sección 11.2.3, Descripción de la solución
Visión general
Cuando un UE se mueve entre celdas en la red (alojada por diferentes nodos de RAN), los caminos de usuario y control del 3GPP puede que ya no pasen a través de la Plataforma de SAVi anterior donde se alojan u optimizan contenido o servicios.
Hay dos escenarios principales que necesitamos considerar para la Movilidad, entre los eNB habilitados por SAVi y entre los nodos de RAN habilitados por SAVi y no habilitados por SAVi y las arquitecturas se describirán por separado por simplicidad.
La Figura 20 muestra un Diagrama de Arquitectura para Movilidad de SAVi a SAVi.
La Figura 21 muestra un Diagrama de Arquitectura para Movilidad de SAVi a no SAVi.
Funciones de cada entidad implicada
Cuando un UE comienza el uso de una Aplicación alojada en la Plataforma de SAVi, donde la aplicación requiere continuidad de servicio siguiendo a un evento de movilidad a otro emplazamiento de radio, la Plataforma de SAVi de Origen 700A es responsable de registrar el uso de la Aplicación con la Pasarela de SAVi 2020 y de proporcionar una plantilla de tráfico asociada. La plantilla de Tráfico identifica las direcciones IP, números de puertos, protocolos, etc., que se pueden usar para identificar tráfico futuro asociado con una aplicación; y los detalles de la Plataforma de SAVi de Origen 700A que está alojando la Aplicación.
Para la movilidad de SAVi a SAVi, la plataforma de SAVi de Destino 700B es responsable de registrarse con la Pasarela de SAVi 2020 y de recuperar una lista de aplicaciones que están actualmente registradas para soporte de movilidad y sus plantillas de tráfico asociadas.
Para la movilidad de SAVi a no SAVi, una Plataforma de SAVi Virtual alojada centralmente 700C es responsable de replicar algunos de los servicios que la Plataforma de SAVi de Origen 700A está entregando al cliente, asegurando la continuidad de servicio cuando el UE abandona un área de SAVi. Como la Plataforma de SAVi Virtual es también responsable de registrarse con la Pasarela de SAVi 2020 en nombre de un UE y de recuperar la lista de aplicaciones que están registradas actualmente para soporte de movilidad y sus plantillas de tráfico asociadas. El registro del UE por la Plataforma de SAVi Virtual 700C se desencadenaría por el primer paquete de enlace ascendente enviado por el UE por la P-GW 2090 para cualquier servicio, requiriendo que la Plataforma de SAVi Virtual determine el Identificador de Cliente de UE de la dirección de IP y la LAN de GI desde la que se recibió el paquete de UE.
Mientras que una Aplicación se mantiene registrada para movilidad, cualquier Plataforma de SAVi de Destino 700B futura es responsable de establecer una conexión con la Plataforma de SAVi de Origen 700A que aloja la aplicación y del puenteo de tráfico de UE que coincide con la plantilla de Tráfico. Para el caso donde el UE se mueve a la Plataforma de SAVi Virtual alojada centralmente, el encaminamiento de paquetes en un nivel de transporte puede ser a través de la Pasarela de SAVi 2020.
Cuando la Aplicación ya no requiere movilidad o la plantilla de Tráfico cambia, la Plataforma de SAVi (de Origen) de alojamiento 700A informa a la Pasarela de SAVi, que informa a otras Plataformas de SAVi (de Destino) 700B registradas.
Aplicación al caso o casos de uso
La Figura 22 muestra el flujo para la movilidad de capa de red de SAVi. Ocurren los siguientes flujos:
1) Un UE comienza usando una aplicación alojada en la Plataforma de SAVi de Origen 700A.
2) También, la Aplicación de SAVi indica a la Plataforma de SAVi de Origen 700A que se requiere Movilidad para la sesión en curso entre la Aplicación y el UE (es decir, en base a conocimientos del contenido, el comportamiento histórico del UE);
O la Plataforma de SAVi de Origen 700A conoce implícitamente que se requiere la movilidad para la sesión de UE, por ejemplo, la Plataforma de SAVi se configura para proporcionar soporte de movilidad para cualquier sesión a una aplicación específica.
3) La Plataforma de SAVi de Origen 700A actualiza el Registro del UE en la Pasarela de SAVi 2020 a través del mensaje de ACTUALIZACIÓN DE REGISTRO DE UE DE SAVI, para indicar que el UE tiene una sesión en curso con una aplicación específica que requiere soporte de movilidad de SAVi. Este mensaje proporciona los detalles de la plantilla de tráfico de aplicación para permitir que una Plataforma de SAVi (de Destino) 700B futura identifique el tráfico, así como los detalles de la Plataforma de SAVi (de Origen) 700A que aloja la Aplicación. El registro de la Aplicación por la Plataforma de SAVi (de Origen) 700A puede ser dependiente del estado de movilidad del UE y la posición relativa del UE al límite de celda.
4) La Pasarela de SAVi 2020 acusa recibo del Registro con el mensaje de RESPUESTA DE ACTUALIZACIÓN DE REGISTRO DE UE DE SAVI.
En un tiempo posterior, si el UE se mueve a una celda no controlada por la Plataforma de SAVi de Origen 700: 5) La Plataforma de SAVi de Destino 700B se da cuenta de que ha llegado un nuevo UE y se proporcionan los detalles básicos del UE. Esto puede ser desde el UE (como se representa) o si ésta es la Plataforma de SAVi Virtual 700C, puede ser el flujo de tráfico desde un UE a una dirección de IP específica.
6) La Plataforma de SAVi de Destino 700B registra la llegada del UE con el mensaje de REGISTRO DE UE DE SAVI.
7) La Pasarela de SAVi 2020 acepta el Registro con el mensaje de TRANSFERENCIA DE PERFIL DE UE DE SAVI que incluye el Perfil de UE de SAVi. Este perfil indica que hay un Registro de Aplicación Activo para el UE en otra Plataforma de SAVi (de Origen) 700A e incluye la Plantilla de Tráfico e información acerca de cómo contactar con la Plataforma de SAVi (de Origen) 700A que aloja la aplicación (del paso 3).
8) La Plataforma de SAVi de Destino 700B establece un túnel a la Plataforma de SAVi de Origen 700B.
9) La Plataforma de SAVi de Origen 700A responde al establecimiento y se establece un túnel bidireccional entre las dos Plataformas de SAVi.
10) El tráfico de UE de enlace descendente o de enlace ascendente asociado con la Aplicación puede fluir entre las Plataformas de SAVi. La Plataforma de SAVi de Destino 700B identifica el tráfico de Enlace ascendente a ser enviado a la Plataforma de SAVi de Origen 700A mediante el uso de la plantilla de Tráfico.
En otro momento, cuando la Aplicación ya no requiere movilidad para la sesión:
11) La Aplicación de SAVi 740 indica a la Plataforma de SAVi de Origen 700B que ya no se requiere movilidad.
12) La Plataforma de SAVi de Origen 700A da de baja la Aplicación con la Pasarela de SAVi 2020 con el mensaje de ACTUALIZACIÓN DE REGISTRO DE UE DE SAVI. Si ésta es la última Aplicación que requiere soporte de movilidad, la Plataforma de SAVi envía el mensaje de BAJA DE UE DE SAVI.
13) La Pasarela de SAVi 2020 informa a la Plataforma de SAVi (de Destino) 700B actual que ya no se requiere Movilidad para esta Aplicación para el UE actualizando el perfil de UE de SAVi del UE a través del mensaje de TRANSFERENCIA DE PERFIL DE UE DE SAVI.
14) La Pasarela de SAVi 2020 acusa recibo del cambio en el Registro a la Plataforma de SAVi de Origen 700A.
15) Se libera el Túnel entre las Plataformas de SAVi. El Túnel entre las Plataformas de SAVi se liberaría también cuando el UE realice un traspaso posterior a otro eNB, o si se libera la conexión de RRC para el UE.
Para el escenario donde el UE libera la conexión de RRC durante una sesión de Aplicación y restablece la conexión de RRC en otro eNB, se aplicaría el mismo mecanismo, la instancia de la Aplicación se podría mantener en la Plataforma de SAVi durante una serie de minutos antes de que la inactividad desencadene que la instancia de la Aplicación se depure por la Plataforma de SAVi. Cuando la instancia de Aplicación se depura por la Plataforma de SAVi que aloja la Aplicación, la Plataforma de SAVi dará de baja el requisito de soporte de movilidad de Aplicación con la Pasarela de SAVi para este Usuario.
Según este aspecto, se observa que dentro del sistema del 3GPP se pasa información de radio entre el eNB de Origen 2000A y el eNB de destino 2000B en el traspaso a través de la MME 2010 o directamente entre los eNB. Con la inclusión de SAVi, las Aplicaciones se añaden en el camino de los datos entre el UE y la P-GW 2090. Cuando el UE cambia de celda alojada por diferentes eNB, el camino de los datos del usuario ya no pasa a través de la ubicación donde se aloja la aplicación.
Se requieren unos medios para permitir que la aplicación acceda al camino de los datos del UE en un emplazamiento diferente.
Se propone que la Plataforma de SAVi 700B en el eNB de Destino 2000B sea responsable de acceder al camino de los datos y extraer o inyectar tráfico relacionado con la aplicación.
La Plataforma de SAVi 700B en el eNB de Destino 2000B requiere información para permitirle:
A. Crear un túnel a la Plataforma de SAVi 700A que aloja la Aplicación 740.
B. Identificar qué paquetes recibidos desde el UE se deberían enviar en el túnel a la Aplicación 740.
La identificación de paquetes se puede completar enviando el ID de Aplicación asociado con la aplicación, que informa implícitamente a la Plataforma de SAVi de destino 700B de las reglas de filtrado de Aplicación.
Para evitar la condición de carrera en el traspaso, la propuesta es que las reglas estén disponibles antes de que se reciba el primer paquete de enlace ascendente en la nueva Plataforma de SAVi 700B.
El procedimiento de Traspaso entre el eNB de origen y de destino se usa como un desencadenador para que la Plataforma de SAVi 700B en el nuevo eNB 2000B registre el UE con la Pasarela de SAVi 2020 y recupere el perfil de UE.
Se propone que el perfil de UE almacenado en la Pasarela de SAVi 2020 se actualice por la Plataforma de SAVi 700A en el eNB de origen 2000A cuando el UE inicia una aplicación que requiere soporte de movilidad y la aplicación no se puede reubicar en la nueva Plataforma de SAVi 700B. La Pasarela de SAVi 2020 está dotada con las reglas de filtrado asociadas con la aplicación de manera que el tráfico asociado con la aplicación específica se puede identificar por el nuevo Enb 2000B.
Cuando la aplicación ha terminado, la Plataforma de SAVi 700A da de baja el UE de la Pasarela de SAVi 2020, que a su vez informa a la nueva Plataforma de SAVi 700B, que desconecta el túnel y descarta las reglas/filtro de encaminamiento. Cualquier paquete futuro se maneja de la forma normal en la plataforma de SAVi 700.
18.1.13 Movilidad de red de SAVi - Señalización basada en X2
Dentro del sistema del 3GPP, se pasa información de radio entre el eNB de Origen 2000A y el eNB de destino 2000B en un traspaso a través de la MME 2010 o directamente entre los eNB.
Con la inclusión de SAVi, se añaden aplicaciones en el camino de los datos entre el UE y la P-GW 2090. Cuando el UE cambia de celda alojada por diferentes eNB, el camino de los datos del usuario ya no pasa a través de la ubicación donde se aloja la aplicación.
Se requieren unos medios para permitir que la aplicación acceda al camino de datos del UE en un emplazamiento diferente.
Se propone que la Plataforma de SAVi 700B en el eNB de destino 2000B sea responsable de acceder al camino de los datos y extraer o inyectar tráfico relacionado con la aplicación.
La Plataforma de SAVi 700B en el eNB de Destino 2000B requiere información para permitirle:
A. Crear un túnel a la Plataforma de SAVi 700A que aloja la Aplicación.
B. Identificar qué paquetes recibidos desde el UE se deberían enviar en el túnel a la Aplicación.
La identificación de paquetes se puede completar enviando el ID de Aplicación asociado con la aplicación, que informa implícitamente a la Plataforma de SAVi de destino 700B de las reglas de filtrado de Aplicación.
Se propone que esta información se adjunte a la señalización de Traspaso que se pasa sobre las interfaces S1 y X2. La Plataforma de SAVi de Destino 700B como parte de la fase de preparación de traspaso puede establecer el túnel de Plataforma de SAVi a Plataforma de SAVi a la Plataforma de Origen. Una vez se ejecuta el Traspaso, el eNB de Origen 2000A informa a la Plataforma de SAVi de Origen 700A que el traspaso se ha desencadenado y los futuros paquetes de enlace descendente se encaminan en el túnel de SAVi a SAVi.
La Plataforma de SAVi de Destino 700B invocará las reglas de filtrado de enlace ascendente tan pronto como llega el UE a la celda de destino; encaminando los paquetes seleccionados de vuelta a la Plataforma de SAVi de Origen 700A.
a) Alternativa basada en X2
Una alternativa es manejar el encapsulado de los paquetes específicos de la Aplicación sobre una extensión a la interfaz X2. En este caso, la Plataforma de SAVi de Origen 700A informa al eNB de Origen 2000A de la información de Movilidad de SAVi (ID de Aplicaciones y reglas de filtrado de paquetes asociadas con la Aplicación).
El eNB de Origen 2000A incluye la Aplicación en los mensajes de Traspaso al eNB de Destino 2000B y la interfaz entre las plataformas de eNB se usa para encaminar paquetes asociados con la Aplicación. Esta interfaz se puede basar en GTP-U. Esto requiere que las plataformas de eNB realicen el filtrado y encaminamiento en el enlace ascendente y el enlace descendente.
Cuando una Aplicación ya no requiere el soporte de Movilidad entre los eNB, el eNB de Origen 2000A marca un paquete de enlace descendente que se pasa al Enb de Destino 2000B, donde se comprende su significado y el eNB de destino libera la conexión para esta aplicación.
Si el UE se traspasa de nuevo desde el eNB de destino 2000B a un nuevo eNB de destino; el primer destino es responsable de reenviar la información recibida desde el eNB de origen 2000A (sobre la Aplicación) al nuevo eNB de destino; y se inicia el procedimiento para establecer una conexión entre el nuevo eNB de destino y el origen.
(18.1.14) Movilidad - pasando contexto de máquina de estado de Aplicación/TCP entre Plataformas de SAVi durante la movilidad, incluyendo la negociación de Aplicación entre el eNB de Origen y de Destino
Sección 11.3.4, Transferencia de Contexto de Aplicación
Visión general
Cuando un UE10 hace una transición entre dos eNB, la máquina de estado (o instancia) de las Aplicaciones en la Plataforma de SAVi de origen 700A se empaqueta y pasa a la Plataforma de SAVi de destino 700B, donde se inicia una copia de las mismas Aplicaciones con las máquinas de estado/información recibidas.
La entrega de la máquina de estado/información como se describe a continuación se realiza a través de extensiones a procedimientos de señalización del 3GPP existentes sobre la interfaz X2; no obstante, se podrían proporcionar a través de un nuevo esquema de señalización entre las Plataformas de SAVi o a través de la Pasarela de SAVi 2020. El reto principal de este planteamiento es que el diseño de la Aplicación necesitaría incorporar el concepto de Transferencia de Contexto de Aplicación y puede ser solamente aplicable a aplicaciones más simples.
Caso o casos de uso
1) Un servicio de web básico alojado en la Plataforma de SAVi es recoger información de un Usuario acerca de una nueva suscripción y las transacciones perduran. Cuando el Usuario se mueve a una nueva Plataforma de SAVi durante la sesión, se requiere que la sesión continúe sin problemas.
Aplicación al caso o casos de uso
La Figura 23 muestra un flujo de transferencia de contexto de aplicación:
Cuando el UE10 está comunicando con un servicio/Aplicación 740 alojada en una Plataforma de SAVi 700A en el eNB 2000A y el UE se mueve a una ubicación donde el eNB necesita desencadenar un procedimiento de Traspaso con un eNB 2000B colindante:
1) El ENB de Origen 2000A envía un mensaje de Solicitud de Traspaso al eNB de Destino para solicitar que se reserven recursos en el eNB de Destino 2000B para el UE10. Este mensaje se actualiza para incluir la política de SAVi Básica incluyendo el identificador de cliente, la información de APN y una indicación de si se permite SAVi para este cliente. Se podría mejorar además para incluir un contenedor con la lista de Aplicaciones de SAVi o contenido que el cliente esté usando actualmente, proporcionada por la Plataforma de SAVi.
2) El eNB de Destino 2000B acepta la solicitud de traspaso y envía la información de configuración de Radio que el UE10 debería usar en el eNB de destino 2000B después de realizar el traspaso junto con una indicación de que la Aplicación o Contenido que se usa por el cliente está disponible en la Plataforma de SAVi 700B del eNB de Destino 2000b.
3) El eNB de Origen 2000A indica a la Plataforma de SAVi 700A que el Comando de Traspaso está a punto de ser enviado a un UE específico, permitiendo que la Plataforma de SAVi 700A congele el estado de las Aplicaciones/Contenido para el UE que están disponibles en el eNB de Destino 2000B y empaquete la información de estado/contexto. Las Aplicaciones no disponibles en el eNB de Destino 2000B se pueden soportar a través de una solución de Movilidad de Capa de Red de SAVi.
4) El eNB de Origen 2000A envía el Comando de Traspaso al UE10 que proporciona la configuración de Radio a ser usada en la celda del eNB del Objetivo 2000B.
5) La Plataforma de SAVi 700A proporciona la información de Estado/Contexto de las aplicaciones específicas que requieren soporte de movilidad al Enb de Origen 2000b.
6) El ENB de Origen 2000A envía el mensaje de Transferencia de Estado de SN (esto requiere que el mensaje de Transferencia de Estado de SN se desencadene para el flujo de SAVi, en lugar de solo para el flujo Reconocido de RLC) al eNB de Destino 2000B incluyendo un contenedor con la información de Estado/Contexto de SAVi.
7) El ENB de Destino 2000B reenvía esta información a la Plataforma de SAVi 700B, que inicia las Aplicaciones 740B para el UE10 con la información de Estado/Contexto de SAVi.
Si el traspaso se completa con éxito el eNB de Origen 2000A informa a la Plataforma de SAVi 700A asociada que puede retirar cualquier información almacenada acerca del UE10 que ya no se requiere. Si el traspaso falla, el eNB de Origen 2000A informa a la Plataforma de SAVi 700A y a las Aplicaciones para que se pueden reiniciar el UE10. Para Aplicaciones que requieren que la Instancia/Contexto de Aplicación se reubique como parte del procedimiento de traspaso, en el escenario donde la conexión de RRC del UE se libera temporalmente durante una sesión de Aplicación, el eNB de Origen 2000A transfiere la Instancia/Contexto de Aplicación a una ubicación central. Cuando el UE10 aparece en un nuevo eNB 2000B y restablece la conexión de RRC, la Plataforma de SAVi 700B en el nuevo eNB 2000B se desencadena en el perfil del UE10 para descargar la copia almacenada centralmente de la Instancia/Contexto de Aplicación para la inicialización en la Plataforma de SAVi 700B.
Según este aspecto, se observa que, dentro del sistema del 3GPP, cuando un UE10 está usando un modo de acuse de recibo o una conexión de VoIP, hay una máquina de estado en el eNB para gestionar el estado del protocolo de RLC/PDCP entre el eNB y el UE, como la RoHC (compresión de cabecera de IP).
Cuando hay un evento de movilidad, que hace que el eNB del UE cambie, la máquina de estado en el eNB de Origen 2000A se transfiere al eNB de Destino 2000B y se reinicializa.
Para SAVi, se requiere un concepto similar, pero en lugar de ser para el túnel/protocolos de radio que se ejecutan entre el UE y el eNB; se requiere para la conexión de Transporte (por ejemplo, TCP) y la Aplicación en sí misma (es decir, las capas más altas de la pila de protocolo).
La máquina de estado del Transporte de Aplicación y de la Aplicación en sí misma se congelarían en el eNB de Origen 2000A, se empaquetarían y se pasarían al eNB de Destino 2000B como parte de la señalización de Traspaso, donde se reinicializa. La congelación de la máquina de estado se puede implementar empaquetando la memoria usada por la instancia de la aplicación, y la memoria del eNB de destino 2000B se podría inicializar con esta información empaquetada.
Para Aplicaciones/contextos complicados, el eNB de Origen 2000A puede empaquetar la información y almacenarla en un servidor de archivos local; y el eNB de Origen 2000B solamente incluye el URL de esta información de máquina de estado empaquetada en los mensajes de Traspaso. Cuando el eNB de Destino 2000B recibe la mensajería de Traspaso con el URL, el Destino abre una conexión con el Origen y recupera la información empaquetada.
(18.1.15) Aplicaciones “durmientes” - almacenamiento central o local de información/contexto de Aplicación; cuando el UE libera la conexión de RRC
Cuando las Aplicaciones se alojan centralmente dentro de una red, el estado de conexión del UE (por ejemplo, RRC) y el estado de movilidad del UE se ocultan de la Aplicación. Cuando la conexión de RRC se restablece después de un evento de movilidad, el UE puede continuar las comunicaciones con la aplicación como si la conexión por Radio no se hubiese liberado ni hubiese habido un cambio en el camino de los datos del canal de comunicación UE-APLICACIÓN.
Alojar una Aplicación en la RAN a través de SAVi significa que cuando el UE restablece la conexión por Radio en una nueva celda, la Plataforma de SAVi ya no está en el camino de los datos del UE y por lo tanto no pueden ocurrir comunicaciones entre el UE y la Aplicación.
La nueva Plataforma de SAVi en el camino de los datos del cliente puede soportar cualquier nueva solicitud/interacción con el UE, pero no tendrá ninguna información acerca de las comunicaciones en curso que ocurrieron recientemente (a la instancia de la Aplicación en el camino de los datos antiguo).
Se propone por lo tanto que cuando una conexión de RRC de un dispositivo se libere cuando una Aplicación alojada en la plataforma de SAVi está activa para el UE, la información de contexto de Aplicación se almacena localmente en un Registro y también se pasa centralmente una copia para ser almacenada en un registro central.
Cuando la información de contexto de Aplicación se recupera del almacén central, el almacén central informa a la Plataforma de SAVi antigua y el contexto se depura del almacén local. Cuando el UE siguiente tiene una conexión de RRC en este eNB, la Plataforma de SAVi asociada descarga cualquier información de contexto almacenada centralmente del Registro Central a todas las aplicaciones en la plataforma.
Diagrama de los pasos
Figure imgf000031_0001
Figure imgf000032_0001
(18.1.16) Control de UE de spool de enlace ascendente de la Plataforma de SAVi (pequeña extensión a existente) Para el caso de uso anterior que define el concepto de contenido de UE que se almacena en caché en la Plataforma de SAVi 700 (después de la transmisión del UE10), antes de que se envíe a la nube central.
El almacén de contenido en este ejemplo se vería como una extensión del almacenamiento del UE, y el UE10 es responsable de desencadenar la carga del contenido a la red. Sujeto a aprobación local, el contenido solamente se sometería a LI una vez el contenido se libere del almacenamiento. No obstante, la tarificación se basa en la transmisión del contenido pero de manera más importante en el momento en que el contenido se almacena en la plataforma 700.
(18.1.8) Optimización de enlace ascendente
En el escenario donde un UE está cargando un archivo al almacenamiento de la nube alojado en Internet, el tiempo de ida y vuelta entre el UE y el servidor de almacenamiento puede ser considerable. El gran tiempo de ida y vuelta puede causar problemas de rendimiento de la conexión, particularmente con respecto al inicio de conexión lento, y largos tiempos de recuperación que siguen a la pérdida de paquetes.
Las funciones de intermediario de TCP, donde la conexión de TCP de extremo a extremo se descompone en dos caminos separados es la solución normal, y en este escenario, el intermediario de TCP se incluye en la Plataforma de SAVi de manera que pueda optimizar completamente la conexión para condición/contención de radio variable. Cuando la conexión entre la Plataforma de SAVi y el servidor de Internet es muy escasa (por ejemplo, cuando la conexión de enlace de retroceso de emplazamiento es sobre un enlace por satélite), algunos datos se pueden acumular en la Plataforma de SAVi mientras que espera a pasarlos al servidor de Internet.
Una vez el UE ha terminado de transmitir el archivo al intermediario de TCP y el UE no tiene datos adicionales que enviar, el eNB puede decidir liberar la conexión de RRC del UE. Si todavía hay datos que están esperando transmisión a la red, el eNB se puede configurar para retardar la liberación del túnel del plano de usuario de conexión S1, mientras que se libera la conexión de RRC en la radio.
El eNB puede entonces liberar más tarde la conexión S1 cuando todos los datos restantes se hayan enviado al servidor de Internet.
Caso básico:
Si el UE10 cambia de eNB durante una carga de archivo, la conexión de TCP fallaría en el nuevo eNB 2000B, tras experimentar un fallo en la conexión de TCP, el UE10 necesitaría desencadenar la transferencia de fallo de nuevo en la nueva celda.
Esta funcionalidad puede ser adecuada para pequeñas transferencias de archivos y dispositivos estacionarios donde la movilidad entre eNB es muy improbable.
Mejora adicional:
Esta solución se podría mejorar además para mantener la conexión S1 al antiguo eNB 2000A incluso después de que el UE10 cambie de celda.
a) Cuando el UE10 está en sesión de datos entregando datos a un servidor de Internet que se optimiza en la Plataforma de SAVi 700A y se desencadena el traspaso después de que se haya terminado la transmisión de datos desde el UE10, pero los datos de enlace ascendente entre la Plataforma de SAVi 700A y el servidor de Internet todavía se tienen que entregar.
Cuando el UE10 cambia de eNB, la arquitectura del 3GPP como parte de los procedimientos de traspaso vuelve a conectar las conexiones del plano de Usuario y de Control de S1 para el UE10 de entre el eNB 2000A original y la Red Central 2030 (MME2010/S-GW2100), a entre el nuevo eNB 2000B y la Red Central (MME/S-GW). Todos los paquetes de Usuario para el UE10 después del traspaso se encaminan a través de la nueva conexión del plano de usuario de S1.
El intermediario de TCP en el eNB 2000A original ya no tendría conectividad al Servidor de Internet para el UE10, y por lo tanto se propone que la red se mejore para soportar múltiples conexiones S1 para un UE (portador).
Para el enlace ascendente, la S-GW 2100 puentearía las dos conexiones S1 de los dos eNB a una única conexión S5/8 a la P-GW202090, de cuya forma se oculta la existencia de múltiples conexiones desde la P-GW 2090.
Para los paquetes de enlace descendente, la S-GW 2100 necesitaría saber a qué conexión S1 encaminar cada paquete de enlace descendente recibido en el túnel S5/8, se propone que la S-GW 2100 se mejore para incluir una función de encaminamiento de IP por la que la S-GW 2100 interrogaría a la dirección de IP de origen del tráfico de carga útil y usar esto para determinar el túnel de S1 adecuado. Se propone que el eNB 2000A Original en el traspaso envíe un nuevo mensaje de control de encaminamiento a la S-GW 2100 sobre la interfaz S1 que proporciona las reglas de encaminamiento a la S-GW 2100.
Cuando ya no se requiere la conexión S1 al eNB 2000A Original, es decir, todos los datos almacenados temporalmente en el intermediario de TCP se han enviado, la Plataforma de SAVi 700A en el eNB 2000A Original envía un paquete especialmente marcado en la conexión S1 de enlace ascendente a la S-GW 2100. Este paquete especialmente marcado indica a la S-GW 2100 que se puede liberar la conexión S1 asociada.
b) En el caso donde la Plataforma de SAVi 700A se informa por el eNB 2000A, a través de las API, que un Traspaso es inminente, el Intermediario de TCP puede modificar la conexión de TCP al UE10 y la conexión de TCP al servidor de Internet para devolver a ambos a un estado sincronizado anterior a que se iniciase el Traspaso.
Una implementación específica:
El dispositivo de M2M (UE10) comunica con la Aplicación de M2M local donde la Aplicación de M2M Principal saca datos agregados del almacenamiento de datos de Spool a través de la Plataforma de SAVi 700A después de que el abonado complete la transmisión donde puede estar en modo inactivo. Los siguientes procedimientos (véase la Figura 25) se definen como una posible solución:
1. El UE10 envía datos de enlace ascendente directamente a la Aplicación de Borde de M2M 2120 alojada en la plataforma de SAVi 700A por la aplicación principal de M2M 2140.
2. Un cliente 2110 de la plataforma 700A permite que la Aplicación de Borde de M2M 2120 almacene estos datos junto con la identidad de abonado, tiempo de carga, opcionalmente los CDR generados por el Cliente 2110 y otra información asociada en el almacenamiento de datos de Spool de enlace ascendente 2130. En este punto, la Pasarela de S-P no ve tráfico en el enlace ascendente o enlace descendente asociado con este flujo de información.
3. Durante la transmisión de enlace ascendente, la Aplicación de Borde de M2M 2120 comprueba el estado del almacenamiento de datos de Spool del usuario único y combinado con los otros criterios definidos (por ejemplo, información de carga) determina que el almacenamiento de datos de Spool 2130 está “Lleno” para un usuario específico y preparado para ser exportado a la aplicación Principal 2140. La Aplicación de Borde 2120 envía un mensaje al eNodo-B 2000A a través del Cliente 2110 o NinfoS para exportar datos de Spool de enlace ascendente y se pone en alerta para la Liberación de la Conexión de RRC por el UE10.
4. Después de que el UE10 complete la transmisión de datos, el eNodo-B 2000A espera a la inactividad del usuario y completa la conexión de liberación de RRC con la causa de liberación “Spool de enlace ascendente”. En este punto, el eNodo-B 2000B entra en un estado de espera, que impactará en el software del eNodo-B normal y lo más importante no libera el contexto S1 hacia la GW de S-P (solamente TEID de enlace ascendente). Se debería observar que el UE10 puede estar en modo o bien inactivo o bien activo. Después, la Aplicación de Borde de M2M 2120 empieza a exportar la agregación de todos los datos de Spool de enlace ascendente de vuelta al ordenador principal asociado con este abonado a través del Cliente y la Pasarela de S-P dentro de la interfaz de GTP-u S1 de enlace ascendente para realizar funciones de Tarificación y de LI. Se describen dos procedimientos alternativos:
a. El eNB 2000A no debería liberar la conexión a menos que se señale por el UE10. Si el UE10 libera la conexión usará la causa ‘Spool de enlace ascendente’ para indicar que el contenido ahora se almacena en el eNB de SAVi 2000A. Si el UE10 libera la conexión por cualquier otra razón, incluyendo traspaso, el spool se debe suspender para evitar cualquier conflicto con un contexto de S1 posterior a la red. Bajo estas otras causas de liberación, el UE10 debe reintentar el spool en otro momento.
b. Si la S-GW 2100 y la P-GW 2090 pueden soportar múltiples conexiones S1 entonces la conexión del UE10 se libera por el eNB 2000A con la causa de liberación ‘Spool de enlace ascendente’ pero más importante la Liberación de Contexto de UE de S1 no se envía a la S-GW 2100.
5. Una vez que los datos de spool de enlace ascendente completan la exportación, la aplicación de M2M de Borde 2120 envía entonces un mensaje de “Spool de Enlace Ascendente Completo” al Cliente 2110. El Cliente 2110 ordena al eNodo-B 2000A que responda finalmente a la liberación del portador de acceso.
6. El eNodo-B 2000A decide entonces, con excepción, por ejemplo, de otros portadores y sesiones activas, enviar una Solicitud de Liberación de Contexto a la MME 2010 y una Liberación de Conexión de RRC al UE10, a menos que no se haya liberado ya, con la causa ‘Spool de Enlace ascendente Completo’. Esto es importante porque informa al UE10 que el spool está completo y además puede iniciar otra solicitud de servicio si no se soportan múltiples conexiones S1 por la GW de S-P. Si la conexión de RRC no se ha liberado ya, el eNodo-B 2000A envía otro mensaje de Liberación de Conexión de RRC al UE10.
La Figura 25 muestra un spool de enlace ascendente del plano de usuario de SAVi a través de un diagrama de flujo de Portador de EPS.
Las siguientes características soportan este caso de uso:
1. La Aplicación de Borde Local M2M 2120 y el Almacenamiento de Datos de Spool de Enlace Ascendente 2130.
2. La Función de Soporte de Plataforma de Servicio (SPSF) 2150 se integra a la Aplicación Principal de M2M 2140.
3. El eNodo-B 2000A para exponer eventos de RRC e invocar procedimientos (de MME) de S1-C ordenados por el Cliente o NinfoS 2110.
4. La función de spool del UE no debe desencadenar otra solicitud de servicio para evitar conflictos en la red a menos que se soporte conectividad de S1 múltiples por la S-GW 2100.
5. El eNB 2000A solamente puede confirmar que un spool se (a) almacena (b) carga con éxito al ordenador principal con la recepción de las causas de liberación correctas: (a) Spool de Enlace Ascendente, (b) Spool de Enlace Ascendente Completo.
Si el UE10 realiza un traspaso desde el eNB de origen 2000A durante una carga de archivo, la conexión de TCP fallaría en el eNB de destino 2000b, tras experimentar fallo de conexión de TCP el UE10 necesitaría intentar recuperar y desencadenar la transferencia de archivos de nuevo en la nueva celda.
Esta funcionalidad puede ser adecuada para pequeñas transferencias de archivos y dispositivos estacionarios donde la movilidad entre eNB es muy improbable.
Soluciones de optimización de enlace ascendente alternativas adicionales:
Solución 1. Mantener el E-RAB
La Solicitud de Modificación de E-RAB (eNB->MME) con parámetros de ID de E-RAB. El E-RAB se mantiene activo entre el eNB 2000A y MME 2010, pero se libera del usuario. Si el usuario solicita un nuevo E-RAB, se vuelve a correlacionar de nuevo con este portador original. Para cualquier comunicación adicional para este usuario, en usuarios particulares se mantiene todavía la aplicación de SAVi, Tarificación y LI. Por ejemplo, se sacan datos almacenados de la red 12 horas más tarde, el E-RAB se mantiene todavía, aunque la fiabilidad y coste son un inconveniente importante y no se recomienda.
Solución 2. E-RAB iniciado por la Red
El E-RAB se solicita por una aplicación principal central donde comunica con un dispositivo de M2M pero saca datos de la plataforma de SAVi. Los siguientes procedimientos se elaboran como parte de esta solución:
a) El UE10 envía datos a la plataforma de SAVi 700A en el enlace ascendente, con alguna señalización previa para permitir spool de UL, donde el Cliente 2110 intercepta estos datos de enlace ascendente, los almacena en la plataforma de SAVi 700A y retira todos los datos en la dirección de enlace ascendente hacia la Red 2 Central 2030. El eNodo-B 2000A retarda la liberación del portador durante el spool de enlace ascendente.
b) Más tarde, la aplicación de spool Principal 2140 inicia un mensaje de búsqueda a través de la MME 2010 para iniciar la creación de una nueva sesión. El UE10 solicita los datos a los que se va a hacer spool de vuelta a la red sin ninguna transmisión de datos del plano de usuario del abonado. El Cliente 2110 llega a ser consciente de esta solicitud y empieza a cargar datos a la aplicación de spool principal donde se reenvían los datos a través de la Pasarela de SAE para realizar la LI y Tarificación correctamente.
Obsérvese que otra mejora es exportar información de carga de enlace ascendente de API de acceso para programar el E-RAB iniciado por la red.
Solución 3. Mejorar la actualización de ubicación con el E-RAB
En la Actualización de Ubicación, se activa la aplicación de SAVi y desencadena la comunicación para sacar datos del almacenamiento a través de la red Central 2030. El E-RAB se establece al dispositivo de M2M donde se sacan los datos de la Plataforma de SAVi 700A donde se hace una comunicación mínima entre el Dispositivo de M2M, pero donde se copian los datos de vuelta a la Pasarela de SAE por motivos de Tarificación y de Li. Menos impacto en la señalización reduce la carga de búsqueda pero puede restringir a la aplicación de SAVi de coordinar cuando se recuperan los datos del almacenamiento de múltiples dispositivos de M2M.
(18.2) Detalles de mantenimiento del registro de política de SAVi
P-GW mejorada con SAVi
Reasignación de política durante modo inactivo a través de Actualización de Unión o TAU
El siguiente flujo de la Figura 26 describe la señalización de NAS entre el UE10 y la Red Central 2030, que se usa por la Plataforma de SAVi 700 para extender el registro con la red para recibir servicios que requieren que se implique a la P-GW mejorada por SAVi 2100.
La Figura 26 es un Diagrama de Flujo de una Unión o TAU de un abonado de política de eNB de origen que persiste a través de la P-GW.
1. Política instalada en el eNB de Origen 2000A de SAVi de una transmisión previa.
El UE10 entra en Modo Inactivo de ECM debido a inactividad. Se establece el estado de la Plataforma de SAVi 700A en Modo Inactivo de ECM con el Temporizador de Área de Seguimiento Periódico de registro de Política establecido en T3412, es decir, 60 minutos basado en coincidir con el temporizador de actualización de LI como parámetro definido por la MME 2010. Se requiere alinear entre la MME 2010 y la Plataforma de SAVi los parámetros de temporizador de actualización mediante la configuración e implementación de manera que el temporizador de Actualización de TA periódico se realice antes de que se depure una política.
2. El UE10 inicia el mensaje de Actualización de Unión o TA al eNB 2000A bajo una variedad de condiciones, por ejemplo, expiración de temporizador, nueva TAI identificada. Este mensaje se reenvía a la Plataforma de SAVi 700A sin protección de integridad para asegurar que las claves de seguridad se mantienen en el entorno seguro del eNB 2000A. El cliente asocia inicialmente el UE10 con el elemento de información de GUTI Antiguo coincidente y la última TAI registrada visitada que se enlaza a un registro de política. Si se hace una coincidencia en GUTI y TAI la política se marca pero no se reinstala completamente ya que o bien la solicitud se podría reenviar a una nueva MME 2010 o tener una S-GW 2100 reasignada que podría invalidar la política. Si la última TAI no coincide con la información de registro de política se actualiza.
Obsérvese que el GUTI se puede haber reasignado a otro UE iniciado por la MME (T3450). En este caso, la Política no se puede reinstalar o actualizar a menos que el UE10 esté en modo conectado donde la política se puede refrescar. Los mecanismos entre el tiempo de vida válido de unos temporizadores de actualización de GUTI y de TA necesitan ser configurados para coincidir con (T3450 y T3412) con el fin de evitar una depuración innecesaria de política.
Si la P-TMSI se usa en el procedimiento de Unión se hace una correlación con el RAI al GUTI.
Si el UE10 usa una IMSI, en el caso de un GUTI o P-TMSI no válido, entonces éste se usa para enlazar con la política persistente.
3. La MME 2010 recibe del UE10 a través del eNB 2000A un mensaje de Solicitud de Unión o de Actualización de Área de Seguimiento, bajo la condición de que el contexto de UE anterior todavía sea válido, donde se devuelve una Aceptación de Unión después de una Actualización de Ubicación exitosa en e1HSS 36. El mensaje de Aceptación de Unión puede contener el GUTI y se extra por la Plataforma de SAVi 700A para confirmar finalmente el registro de política persistente si el antiguo GUTI coincide. Si se ha asignado un nuevo GUTI por la MME 2010, entonces siempre que el antiguo GUTI se pueda referenciar al nuevo GUTI, se puede reinstalar la política.
El temporizador de política se reinicia para hacer coincidir con el temporizador de actualización de TA periódica (T3412) extraído del mensaje de Aceptación de Unión.
Si no se acepta una Unión, Rechazo de Unión, por la red se depura la política.
Reasignación de política durante solicitud de servicio de gestión de sesión
Estos casos de uso cubren procedimientos de gestión de sesión que analizan cómo se maneja la información de política durante la transición entre los procedimientos de modo ECM-INACTIVO y ECM-CONECTADO.
La Figura 27 es un Diagrama de Flujo de la reinstalación de Política después de la nueva solicitud de servicio a través de la P-GW 2090:
1. La Política se instala y mantiene en el ENB de Origen 2000A de una sesión previa. Las transiciones de Liberación de RRC y el UE de ECM-CONECTADO a ECM-INACTIVO bajo la iniciación del eNB 2000A (es decir, la inactividad de usuario típicamente establecida en 10 segundos) o MME 2010, accionarán la S-GW 2100 para liberar toda la información relacionada con (S1-C) AP de S1 de UE de eNB a la MME 2010 (direcciones y los TEID). La MME 2010 elimina toda la información relacionada con el eNB del contexto de MME del IE, pero retendrá, con el requisito de reutilizar, toda la información de configuración de enlace ascendente de S1-U de S-GW (direcciones y los TEID).
2. El UE10 inicia una nueva solicitud de servicio donde no se ha alcanzado el temporizador de inactividad de usuario por la MME 2010. Se envían mensajes de Configuración de Contexto Inicial entre el eNB 2000A y la MME 2010. Este mensaje se reenvía al Cliente sin protección de integridad para asegurar que las claves de seguridad se mantienen en el entorno seguro del eNB 2000A. El cliente es consciente del ID de portador y puede iniciar la asociación con la política antigua.
Reasignación de política durante el modo inactivo a través de procedimiento de liberación de gestión de sesión La Figura 28 es un Diagrama de Flujo de la reinstalación de Política después del procedimiento de Liberación de S1.
1. La transición de ECM-CONECTADO a ECM-INACTIVO sigue a un procedimiento de Liberación de S1 bajo iniciación del eNB 2000A (es decir, la inactividad de usuario típicamente establecida en 10 segundos) o la MME 2010 (no ilustrada) accionarán la S-GW 2100 para liberar toda la información relacionada con (S1-C) AP de S1 de UE de eNB a la MME 2010 (direcciones y los TEID). La MME 2010 elimina toda la información relacionada con el eNB del contexto de MME del UE, pero retendrá, con el propósito de reutilizar, toda la información de configuración de enlace ascendente de S1-U de S-GW (direcciones y los TEID). Todos los portadores de EPS no GBR establecidos para el UE se preservan en la MME 2010 y en la S-GW 2100.
2. El evento de Configuración de Contexto Inicial de S1 Completo se envía por el eNB 2000A a la MME 2010 donde se inicia el temporizador de ECM-INACTIVO. Este mensaje se reenvía al Cliente sin protección de integridad para asegurar que las claves de seguridad se mantienen en el entorno seguro del eNB.
3. Finalmente, el temporizador de ECM-INACTIVO expira y se depura la política.
Reasociación de política durante devolución de traspaso
El propósito de este procedimiento es definir un método de mantenimiento y depuración de la política a medida que un abonado hace un traspaso entre los eNB. Este procedimiento minimiza la señalización de la P-GW 2090 de la Plataforma de SAVi para traspasos de ping pong. Aunque el modo conectado no está en el alcance, el foco está en cómo se gestionan las políticas después del traspaso y cuando el abonado finalmente vuelve al modo de ECM-INACTIVO.
La Figura 29 es un Diagrama de Flujo de la reinstalación de Política en el eNB de Origen original en devolución de Traspaso desde el eNB de Destino.
1. El eNB de Origen 2000A tiene instalada la política de abonado.
2. El abonado realiza la Solicitud de Traspaso de X2, Respuesta al eNB de Destino 2000B. Este mensaje contiene información de portador, direcciones de IP y los TEID asignados para reenviar paquetes al eNB de Destino 2000B.
3. La S-GW 2100 en traspaso envía un Marcador Final de GTP-u como se indica en el mensaje de cabecera al eNB de Origen 2000A para liberar recursos. Se modifica entonces la información de estado de UE de Política en el eNB de Origen 2000A en base a este paquete donde el estado de UE de política se establece en “Traspaso intra-RAT”, se reinicia el Temporizador, el eNB de Origen 2000A se establece en su propio TAI+ECGI (Identificador Global de Celda de E-UTRAN), el eNB de Destino 2000B se establece en el valor extraído del ID de Celda de destino de la Solicitud de Traspaso. La Liberación de Contexto de UE de X2 del eNB de Destino 2000B al eNB de Origen 2000A se libera después de que la MME 2010 modifique el portador y la S-GW 2100 realice una conmutación de camino.
Para la solución de la P-GW 2090 la política se descarga al eNB de destino 2000B a través de la P-GW 2090 pero requiere que el paquete o bien de UL o bien de DL desencadene este evento. Alternativamente, si la Solicitud de Conmutación de Camino es consciente de este mensaje, la P-GW 2090 podría usar éste para desencadenar una descarga de política.
Para la solución de MME 2010, la política se puede insertar en el mensaje de Acuse de Recibo de Solicitud de Conmutación de Camino hacia el eNB de destino 2000B.
Una solución alternativa a este caso de uso es exportar la política del eNB de origen 2000A al eNB de destino 2000B a través de la interfaz X2 en este punto del mensaje de Solicitud de Traspaso.
4. Después, el abonado 10 realiza un traspaso (devolución) al eNB de Origen 2000A original, ahora el eNB de Destino 2050B, con un mensaje de Solicitud de Traspaso de X2 con información de Portador de direcciones IP y asignación de los TEID para reenviar desde el eNB de Destino 2000B antes de que expire el temporizador. El Cliente en el eNB de Origen 2000A asocia el UE10 al ID de E-RAB, Direcciones iP de UL y DL de S-GW, TEID de UL y DL coincidentes para reinstalar el antiguo registro de Política. El Temporizador de Traspaso en el eNB de Origen 2000A original (ahora el eNB de Destino) se establece en mulo y cuenta con propósitos de información de movilidad.
5. Si la información de estado de UE de Política se reanuda de vuelta al Modo de ECM-Conectado en el eNB de Origen 2000A original, ahora el eNB de Destino, la información de política antigua ahora está instalada y es válida. Obsérvese de manera importante que la Plataforma de SAVi 700A entonces salta el Sondeo/Respuesta de GTP a la P-GW 2090 para descargar la política para este abonado.
6. El UE10 asentado en el eNB de Origen 2000A pasa al modo de ECM-INACTIVO y finalmente el Temporizador de Traspaso expira en el último eNB de Origen, que era el eNB de Destino 2000A, y se depura la política.
MME mejorado por SAVi
Reasociacion de Política durante el modo inactivo a través de la Actualización de Unión o TAU
Esta sección es similar a la de la descripción de la solución de la P-GW anterior con una excepción. En esta solución no hay necesidad de que la política salga de una transmisión anterior. El abonado 10 realiza un procedimiento de Unión o TAU donde la política se coloca en un contenedor del mensaje de Aceptación de Unión de la MME 2010 en base al mensaje de Respuesta de Crear Sesión de la P-GW 2090.
Reasociación de Política durante la nueva solicitud de servicio
La Figura 30 es un Diagrama de Flujo de la Política de Movilidad después o durante una nueva solicitud de servicio a través de la MME.
Consúltese la descripción de la solución de la P-GW anterior donde la solución es similar. Con las siguientes excepciones:
• En el caso de la solución de MME en la Figura 30 anterior, la política se coloca en un contenedor en el mensaje de Configuración de Contexto Inicial de la MME 2010 en el caso en que la política no haya cambiado dentro de la PCRF.
• En el caso en que la política se haya actualizado durante la solicitud de modificar el portador, Figura 30, se requiere que se señalen la Modificación de Contexto y el Acuse de Recibo entre la MME 2010 y el eNB 2000A y la Plataforma de SAVi 700A.
Reasociación de Política durante devolución de traspaso
Esta solución es similar a la de la descripción de la solución de la P-GW anterior con las siguientes excepciones:
• Paso-3: para la solución de MME la política se puede insertar en el mensaje de Acuse de Recibo de Solicitud de Conmutación de Camino hacia el eNB de destino 2000B.
Realización preferida de la Invención - Política
Esta realización se puede combinar con cualquiera de las combinaciones de los aspectos mencionados anteriormente.
5 Intercepción legal
Los operadores de redes de telecomunicaciones celulares deben continuar cumpliendo las obligaciones de Intercepción Legal existentes para el tráfico entregado a través de SAVi a los clientes, en particular asegurando el soporte de LI para el tráfico generado, modificado o terminado por la Plataforma de SAVi 700. Una solución se soporta por la P-GW mejorada de SAVi 2090.
Cualquier diseño debería asegurar que los mecanismos de Intercepción Legal continúen cumpliendo los requisitos existentes, incluyendo:
• El punto de Intercepción Legal ve el mismo tráfico que el usuario ve de una manera oportuna
• No se permite una modificación o eliminación deliberada de datos, pero se permiten pérdidas debidas al comportamiento/rendimiento de la red, por ejemplo, paquetes caídos debido a malas condiciones de radio o congestión.
• La especificación TS 33.108 del 3GPP, “[Handover interface for Lawful Interception (LI)]”, sección 6.2 proporciona niveles mínimos de fiabilidad esperada
Se supone que todo el tráfico inyectado (por ejemplo, contenido disponible localmente en el borde), modificado (por ejemplo, optimización o mejora del contenido en el borde) o terminado (por ejemplo, en una aplicación alojada) en la Plataforma de SAVi necesita ser copiado en el punto de Intercepción Legal, que actualmente está típicamente en la P-GW 2090 para el tráfico del plano de usuario.
Una solución sigue los principios de diseño que se enumeran a continuación. Estos son principios generales y no todos pueden ser relevantes para SAVi.
• La Intercepción Legal es una condición de obtención de licencia en la mayoría de los países y debe estar disponible en un sistema estandarizado y compatible (por ejemplo, ETSI/3GPP, CALEA, SORM) sujeto a requisitos especiales locales.
• La Intercepción Legal de un abonado objetivo no tendrá lugar fuera de las fronteras de la nación que está imponiendo el mandato, es decir, la intercepción legal transfronteriza no es una opción. De manera similar, ni la información del objetivo ni el producto de intercepción se almacenarán ni estarán en tránsito fuera de la nación de intercepción.
• Los mandatos de intercepción solamente se pueden proporcionar por el gobierno nacional en cuyo país está operando una red, es decir, la red no puede aceptar o procesar una solicitud de intercepción de un país/entidad externa.
• Cifrar datos de LI (las identidades de los objetivos de LI, el contenido de llamadas (CC) interceptadas y los datos relacionados con la intercepción (IRI)) mientras que están fuera de las fronteras nacionales, no es una solución alternativa aceptable.
• Obsérvese que algunos nodos que no manejan tráfico (incluyendo, pero no limitados a, HLR, HSS) también son sensibles a la ubicación desde el punto de vista de la Intercepción Legal.
• El tráfico de los objetivos no se manejará de una manera diferente al tráfico normal de ninguna forma que pudiera permitir que una persona no autorizada deduzca la identidad de cualquier objetivo interceptado. • Cualquier gestión de red relacionada con la funcionalidad y seguridad de LI se separará de y será inaccesible a la operación y administración normales. Los nodos que se gestionan desde fuera de las fronteras nacionales no tendrán implementada la capacidad de LI (este software se debería eliminar en lugar de simplemente desactivar).
• La solución de LI debe ser capaz de funcionar en un escenario de múltiples proveedores, en el peor de los casos, todos los tipos de nodos son de diferentes proveedores.
• La solución de LI no degradará el rendimiento de la red en las condiciones de capacidad máxima.
• Si el tráfico se cifra por una función del aparato fuera del control del usuario y luego se descifra en la red de Vodafone, el OpCo a través del cual pasa el tráfico cifrado debe asegurar que la LEA o bien reciba el tráfico descifrado o bien se dote con los medios para descifrar el tráfico.
• La solución de Intercepción Legal será capaz de comenzar la intercepción inmediatamente que el ID del objetivo alcance el nodo de intercepción si ya está en curso una sesión de comunicación, por ejemplo, contexto de PDP o llamada de SIP, que implica al objetivo. No debería ser necesario esperar a que se inicie una nueva sesión.
• Las interfaces de Intercepción Legal: X1 (administración interna), X2 (mediación interna para IRI), el tráfico de HI1 y HI2 deben estar cifrados en todo momento. HI3 para voz de CS no suele estar cifrada. X3 y HI3 para tráfico de PS deben estar cifradas. Esto incluye VoIP, excepto después del punto en que se convierte a TDM para compatibilidad hacia atrás para la LEMF, si es aplicable.
• No se permite ninguna funcionalidad de LI en la Red de Acceso por Radio (RAN) y no se hará nada en otra parte de la red que permitiese que los objetivos de LI sean identificados observando el tráfico que pasa a través de un nodo RAN.
No todos los principios son relevantes para esta actividad. No obstante, es importante comprenderlos, en la medida que reflejan la importancia de la solución propuesta.
Caso o casos de uso
1) Alojamiento de Contenido de Borde: el contenido de correlación de Alta Definición (HD) se almacena localmente en la Plataforma de SAVi y se sirve directamente a los usuarios
2) Alojamiento de Aplicación de Borde: el tráfico de usuario termina en una aplicación alojada en la Plataforma de SAVi
3) Alojamiento de Optimización de Borde: el tráfico de enlace ascendente de usuario se modifica y/o reenvía fuera de banda a un repositorio de contenido central o aplicación por la Plataforma de SAVi 700 y se inyecta la respuesta por la Plataforma de SAVi en el tráfico de enlace descendente de usuario por la Plataforma de SAVi . Descripción de la solución
P-GW mejorada de SAVi
Visión general
Como no está permitido introducir capacidades de LI directamente en un eNB 2000, es necesario copiar el tráfico de usuario de enlace ascendente y de enlace descendente para el contenido generado, terminado o modificado en la Plataforma de SAVi 700 a la red central 2030 para su procesamiento por los sistemas de LI 2200 existentes.
La política de SAVi para una aplicación 740 o la política de SAVi para cada usuario indicará si el tráfico de usuario necesita ser copiado para esa aplicación. Como no se permite que la Plataforma de SAVi 700 conozca la identidad de los objetivos de LI, el procedimiento descrito a continuación se aplica a todos los usuarios.
La Figura 31 muestra LI soportada por la Arquitectura de P-GW Mejorada de SAVi.
Funciones de cada entidad implicada
Para el tráfico generado, modificado o terminado por las aplicaciones 740 en la Plataforma de SAVi 700, el tráfico de usuario de enlace ascendente y de enlace descendente necesita estar disponible en la red central 2030 para el mantenimiento de LI (y Tarificación). La funcionalidad de copia, introducida en la Plataforma de SAVi 700, es responsable de copiar el tráfico de usuario de enlace ascendente y de enlace descendente asociado y de inyectarlo en la sesión de GTP-U de enlace ascendente del Usuario/E-RAB asociado. Se añade información adicional dentro de la trama de GTP-U para distinguir éste del tráfico de enlace ascendente de usuario normal.
La funcionalidad de copia de la P-GW mejorada de SAVi 2090 recupera los datos copiados de la sesión de GTP-U para su uso por el sistema de LI 2200. La información adicional incluida dentro de la trama de GTP-U instruye a las funciones relacionadas con SAVi en la P-GW 2090 para manejar los paquetes en consecuencia y descartarlos después del procesamiento por el sistema de LI 2200.
(18.1.17) Interfaz de LI genérica
Como se ha mencionado anteriormente, dentro de la arquitectura del 3GPP actual, los datos que fluyen desde el eNB 2000 a la red central 2030 se encapsulan en tramas de GTP-U para permitir la movilidad. Las tramas de GTP-U se usan como una solución ligera para proporcionar movilidad a la capa de IP, en lugar de usar la tecnología de IP móvil, por la que cada portador de cada UE se encapsula en una conexión separada entre el eNB 2000 y la P-GW 2090, a través de la S-GW 2090. La conexión separada permite que la P-GW 2090 realice LI/Tarificación para este tráfico sobre una base por portador/por usuario.
Cuando se introduce SAVi, alojando aplicaciones o funciones en el camino de datos entre la P-GW 2090 y el UE10, se interrumpe la movilidad proporcionada por la arquitectura del 3GPP. Por lo tanto, si necesita ser proporcionada movilidad a través de otros medios para este tráfico, no hay necesidad de continuar con la encapsulación de GTP para este tráfico sobre la interfaz S1.
La introducción de conceptos de Telecomunicaciones sobre la nube, como se muestra en la Figura 32, donde el software de la red central 2030 está virtualizado y alojado en la nube/Internet 2210, permite que se realicen nuevas arquitecturas de una manera rentable.
Los conceptos de Telecomunicaciones sobre la nube se describen en “Telco over Cloud Architecture Blueprint”, v3.0, 28 de noviembre de 2013 y “Telco over Cloud Architectural Design (Virtualization layer based on VMware)”, v3.0, 6 de diciembre de 2013.
Según la realización, la solución existente basada en GTP-U para conectividad sobre una base por usuario/portador se complementa con otra conexión ligera entre el eNB 2000 y la Nube 2210. Se introduce un nuevo bloque de carga de trabajo/software 2220 dentro de la Nube 2210 que es responsable de realizar LI 2200/Tarificación 2250 del tráfico generado en el eNB 2000 donde la movilidad para el servicio no se proporciona por el marco de encapsulación de GTP-U. Para los datos que aún requieren soporte de movilidad, el marco de encapsulación de GTP-U y la P-GW 2090 aún se usan para este tráfico.
Por lo tanto, el eNB2000/Plataforma de SAVi 700 tiene dos conjuntos de interfaces del plano de usuario, la conexión existente basada en GTP-U por usuario/por portador y una nueva solución encapsulada de IP genérica entre el eNB 2000 y el bloque de carga de trabajo/software 2220 alojado en la Nube 2210. La solución de encapsulación de IP incluye una nueva cabecera formateada especialmente que incluye el ID de UE, la Identidad de Portador, la Identidad de Aplicación y una marca de tiempo, la dirección de flujo (hacia/desde el UE), la información de tarificación y luego la carga útil de IP completa, como se muestra en la Figura 33.
La plataforma de SAVi 700 está configurada de una manera que permita que ciertos tipos de tráfico/aplicaciones se pasen en la conexión de encapsulación de GTP-U 2230 y otros tipos de tráfico/aplicaciones se pasen en la conexión de encapsulación de IP 2240.
El bloque de carga de trabajo/software 2220 alojado en la nube 2220 es responsable de analizar el tráfico recibido en la nueva conexión 2240 y de soportar los servicios de LI 2200/Tarificación 2250 para este tráfico.
Cuando el UE se mueve a una nueva celda, las mejoras de SAVi a la arquitectura de red proporcionan movilidad de vuelta a la ubicación de alojamiento de la aplicación, y hay una opción en la implementación en la que la Plataforma de SAVi pasa los datos al bloque de carga de trabajo/software alojado 2220, la Plataforma de SAVi que aloja la Aplicación/función relevante, o la Plataforma de SAVi/eNB que está sirviendo al UE.

Claims (10)

REIVINDICACIONES
1. Una red de telecomunicaciones móviles que incluye:
una red de acceso por radio que tiene medios de radio (2000) para comunicación inalámbrica con una pluralidad de terminales (10) registrados con la red de telecomunicaciones y la red de telecomunicaciones que tiene medios de control (700) operables para proporcionar servicios a los usuarios de los terminales conectados a la misma; un núcleo (2030) que tiene medios de procesamiento de contenido (2200, 2250) operables para proporcionar un servicio central con relación al contenido; en donde el núcleo (2030) es operable para proporcionar el servicio central con relación al contenido sobre una base por usuario/por portador, usando una conexión basada en GTP-U; y
unos medios de procesamiento de contenido alojados en la nube (2210) (2220) operables para proporcionar un servicio basado en la nube con relación al contenido correspondiente al servicio central;
en donde los medios de control (700) son operables para transmitir datos a los medios de procesamiento de contenido alojados en la nube (2220) para la ejecución del servicio basado en la nube sobre los mismos; en donde los medios de control (700) son operables para seleccionar si el contenido se envía a los medios de procesamiento (2200, 2250) del núcleo (2030) o a los medios de procesamiento de contenido alojados en la nube (2210) (2220), en donde el servicio basado en la nube incluye al menos una de tarificación de contenido e intercepción legal, en donde el contenido que requiere soporte de movilidad sobre una base por usuario/por portador se envía a los medios de procesamiento (2200, 2250) del núcleo (2030) y en donde el contenido para el cual no se proporciona movilidad por un marco de encapsulación de GTP-U se envía a los medios de procesamiento de contenido alojados en la nube (2210) (2220) para realizar al menos una de tarificación de contenido e intercepción legal.
2. La red de telecomunicaciones de la reivindicación 1, en donde los medios de control (700) y los medios de procesamiento de contenido alojados en la nube (2220) son operables para crear una conexión de encapsulación de IP entre los mismos.
3. La red de telecomunicaciones de la reivindicación 2, en donde los medios de control (700) son operables para transmitir datos en la conexión de encapsulación de IP en un paquete de datos que incluye el contenido, o una indicación del contenido, y al menos uno de: ID de terminal, Identidad de portador, identidad de aplicación, marca de tiempo, dirección del flujo e información de tarificación.
4. La red de telecomunicaciones de la reivindicación 3, en donde los medios de procesamiento de contenido alojados en la nube (2220) son operables para recibir el paquete de datos y para realizar al menos una de las funciones de tarificación de contenido e intercepción legal sobre los mismos.
5. La red de telecomunicaciones de una cualquiera de las reivindicaciones 1 a 4, en donde la red de acceso por radio y el núcleo (2030) son operables para crear una conexión de Protocolo de Tunelización de GPRS, GTP, entre los mismos para proporcionar el servicio central con relación al contenido.
6. Un método de operación de una red de telecomunicaciones móviles que incluye:
una red de acceso por radio que tiene medios de radio (2000) para comunicación inalámbrica con una pluralidad de terminales (10) registrados con la red de telecomunicaciones y la red de telecomunicaciones que tiene medios de control (700) operables para proporcionar servicios a los usuarios de los terminales conectados a la misma; un núcleo (2030) que tiene medios de procesamiento de contenido (2200, 2250) operables para proporcionar un servicio central con relación al contenido; en donde el núcleo (2030) proporciona el servicio central con relación al contenido sobre una base por usuario/por portador, usando una conexión basada en GTP-U; y
unos medios de procesamiento de contenido alojados en la nube (2210) (2220) operables para proporcionar un servicio basado en la nube con relación al contenido correspondiente al servicio central;
en donde los medios de control (700) transmiten datos a los medios de procesamiento de contenido alojados en la nube (2220) y los medios de procesamiento de contenido alojados en la nube (2220) realizan el servicio basado en la nube sobre los mismos;
en donde los medios de control (700) seleccionan si el contenido se envía a los medios de procesamiento (2200, 2250) del núcleo o a los medios de procesamiento de contenido alojados en la nube (2210) (2220), en donde el servicio basado en la nube incluye al menos una de tarificación de contenido e intercepción legal, en donde el contenido que requiere soporte de movilidad sobre una base por usuario/por portador se envía a los medios de procesamiento (2200, 2250) del núcleo (2030) y en donde el contenido para el cual la movilidad no se proporciona por un marco de encapsulación de GTP-U se envía a los medios de procesamiento de contenido alojados en la nube (2210) (2220) para realizar al menos una de tarificación de contenido e intercepción legal.
7. El método de la reivindicación 6, en donde los medios de control (700) y los medios de procesamiento de contenido alojados en la nube (2220) crean una conexión de encapsulación de IP entre los mismos.
8. El método de la reivindicación 7, en donde los medios de control (700) transmiten datos en la conexión de encapsulación de IP en un paquete de datos que incluye el contenido o una indicación del contenido, y al menos uno de: ID de terminal, Identidad de portador, identidad de aplicación, marca de tiempo, dirección de flujo e información de tarificación.
9. El método de la reivindicación 8, en donde los medios de procesamiento de contenido alojados en la nube (2220) reciben el paquete de datos y realizan al menos una de las funciones de tarificación de contenido e intercepción legal sobre los mismos.
10. El método de una cualquiera de las reivindicaciones 6 a 9, en donde la red de acceso por radio y el núcleo (2030) crean una conexión de Protocolo de Tunelización de GPRS, GTP, entre los mismos para proporcionar el servicio central con relación al contenido.
ES15700913T 2014-01-08 2015-01-08 Redes de telecomunicaciones Active ES2833410T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB1400302.4A GB201400302D0 (en) 2014-01-08 2014-01-08 Telecommunications network
PCT/GB2015/050028 WO2015104548A1 (en) 2014-01-08 2015-01-08 Telecommunications networks

Publications (1)

Publication Number Publication Date
ES2833410T3 true ES2833410T3 (es) 2021-06-15

Family

ID=50191064

Family Applications (2)

Application Number Title Priority Date Filing Date
ES15700913T Active ES2833410T3 (es) 2014-01-08 2015-01-08 Redes de telecomunicaciones
ES15700911T Active ES2827682T3 (es) 2014-01-08 2015-01-08 Redes de telecomunicaciones

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES15700911T Active ES2827682T3 (es) 2014-01-08 2015-01-08 Redes de telecomunicaciones

Country Status (5)

Country Link
US (3) US10362583B2 (es)
EP (3) EP3092834B1 (es)
ES (2) ES2833410T3 (es)
GB (1) GB201400302D0 (es)
WO (3) WO2015104546A1 (es)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB201400302D0 (en) 2014-01-08 2014-02-26 Vodafone Ip Licensing Ltd Telecommunications network
US20150200972A1 (en) * 2014-01-16 2015-07-16 Qualcomm Incorporated Methods and systems for facilitating decoding of application defined or proprietary protocols in lawful intercepts
JP6514321B2 (ja) 2014-08-11 2019-05-15 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． データ・サービスを実装するためのデバイス及び方法
US10616947B1 (en) * 2015-05-29 2020-04-07 Akamai Technologies, Inc. TCP performance over cellular mobile networks
US10064112B2 (en) * 2015-05-29 2018-08-28 Apple Inc. Apparatus, systems and methods for switching between radio access technologies
WO2016192804A1 (en) * 2015-06-04 2016-12-08 Telefonaktiebolaget Lm Ericsson (Publ) Controlling communication mode of a mobile terminal
US10637834B2 (en) * 2015-07-12 2020-04-28 Qualcomm Incorporated Network architecture and security with simplified mobility procedure
EP3145269A1 (en) * 2015-09-16 2017-03-22 Alcatel Lucent Method, devices and system for a hybrid bearer service
US10148588B1 (en) * 2015-09-30 2018-12-04 EMC IP Holding Company LLC Partitioned performance: using resource account aggregates to throttle at the granular level
JP6123009B1 (ja) * 2015-11-05 2017-04-26 株式会社Ｎｔｔドコモ ユーザ装置、基地局、及び接続確立方法
US10498764B2 (en) 2015-12-08 2019-12-03 Jpu.Io Ltd Network routing and security within a mobile radio network
EP3405877B1 (en) * 2016-01-22 2022-09-21 Nokia Solutions and Networks Oy Application relocation between clouds
EP3206359B1 (en) * 2016-02-15 2019-03-06 Wipro Limited Methods and systems for performing lawful interception (li) in communication networks involving content adulteration with colluding agents
EP3236617B1 (en) * 2016-04-20 2021-06-30 Deutsche Telekom AG Method for an improved processing of network communication between a telecommunications network and at least one user equipment by means of realizing, within the telecommunications network, network functions virtualization, telecommunications network, program and computer program product
US10931793B2 (en) * 2016-04-26 2021-02-23 Cisco Technology, Inc. System and method for automated rendering of service chaining
JP6683399B2 (ja) * 2016-05-25 2020-04-22 ホアウェイ・テクノロジーズ・カンパニー・リミテッド データサービス制御方法および関連するデバイス
US10270815B1 (en) * 2016-06-07 2019-04-23 Amazon Technologies, Inc. Enabling communications between a controlling device and a network-controlled device via a network-connected device service over a mobile communications network
WO2017220158A1 (en) * 2016-06-24 2017-12-28 Nokia Solutions And Networks Oy Policy control of mobile edge applications
US11296946B2 (en) * 2016-07-13 2022-04-05 Telefonaktiebolaget Lm Ericsson (Publ) Methods and servers for managing traffic steering policies
US10104177B2 (en) * 2016-09-30 2018-10-16 Hughes Network Systems, Llc Distributed gateways with centralized data center for high throughput satellite (HTS) spot beam network
WO2018132468A1 (en) * 2017-01-10 2018-07-19 Nokia Technologies Oy Short message service interworking
US10917290B2 (en) * 2017-02-22 2021-02-09 Nokia Technologies Oy Interface for a cloud radio access network
US10225355B2 (en) * 2017-04-04 2019-03-05 Facebook, Inc. Methods and systems for abuse detection of zero-rated data
US10693918B2 (en) 2017-06-15 2020-06-23 Palo Alto Networks, Inc. Radio access technology based security in service provider networks
US11050789B2 (en) 2017-06-15 2021-06-29 Palo Alto Networks, Inc. Location based security in service provider networks
US10812532B2 (en) 2017-06-15 2020-10-20 Palo Alto Networks, Inc. Security for cellular internet of things in mobile networks
US10834136B2 (en) 2017-06-15 2020-11-10 Palo Alto Networks, Inc. Access point name and application identity based security enforcement in service provider networks
US10721272B2 (en) 2017-06-15 2020-07-21 Palo Alto Networks, Inc. Mobile equipment identity and/or IOT equipment identity and application identity based security enforcement in service provider networks
US10708306B2 (en) 2017-06-15 2020-07-07 Palo Alto Networks, Inc. Mobile user identity and/or SIM-based IoT identity and application identity based security enforcement in service provider networks
US10327175B2 (en) * 2017-07-18 2019-06-18 Oracle International Corporation Methods, systems, and computer readable media for operating a telecommunications network using an on-premises computing system and an off-premises cloud computing system
US10405373B2 (en) * 2017-08-03 2019-09-03 Nec Corporation Distributed core architecture for implementing wireless communication networks
DE102017007663B4 (de) 2017-08-14 2022-12-29 Rodenstock Gmbh Verfahren und Vorrichtung zum Berechnen oder zum Bewerten eines Brillenglases für ein Auge eines Brillenträgers unter Berücksichtigung eines Visusmodells, entsprechendes Computerprogrammerzeugnis sowie Verfahren und Vorrichtung zum Herstellen eines Brillenglases
US10673649B2 (en) * 2017-10-24 2020-06-02 Cisco Technology, Inc. Method and device for quality of service regulation
CA3093714A1 (en) * 2018-03-12 2019-09-19 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method and apparatus for updating ue policy, and computer storage medium
CN108833280B (zh) * 2018-03-19 2020-02-04 新华三信息安全技术有限公司 一种用户管理表项下发方法、装置及控制面设备
CN110381535B (zh) 2018-04-12 2022-04-29 中兴通讯股份有限公司 传输控制方法及装置
CN111083790B (zh) * 2018-10-19 2022-09-09 成都鼎桥通信技术有限公司 一种调度控制方法和装置
US20220007277A1 (en) * 2018-11-06 2022-01-06 Zte Corporation A method and apparatus for attaching user equipment to a network slice
US11159945B2 (en) * 2018-12-31 2021-10-26 T-Mobile Usa, Inc. Protecting a telecommunications network using network components as blockchain nodes
US10959137B2 (en) 2019-02-07 2021-03-23 Cisco Technology, Inc. Procedures for interaction between the radio controller and the subordinated base station
US11909594B2 (en) * 2019-04-12 2024-02-20 T-Mobile Usa, Inc. Purging IoT devices in a cellular network
US11388615B2 (en) * 2019-08-14 2022-07-12 Cisco Technology, Inc. Interaction between radio controller platform and third party applications
DE102021133152A1 (de) 2021-12-14 2023-06-15 Rodenstock Gmbh Verfahren, Vorrichtung und Computerprogrammprodukt zum Bestimmen einer Sensitivität zumindest eines Auges eines Probanden

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10046344C2 (de) * 2000-09-19 2003-07-24 Siemens Ag Zugangsnetz und Verfahren zu dessen Betrieb
FR2843450B1 (fr) * 2002-08-07 2006-05-12 Denso Corp Dispositif de transport de chaleur a ecoulement oscillant en mode de contre-courant
US7971232B2 (en) * 2006-10-30 2011-06-28 Microsoft Corporation Setting group policy by device ownership
WO2009006630A1 (en) 2007-07-05 2009-01-08 Starent Networks, Corp System and method for reducing latency in call setup and teardown
CN101754064A (zh) 2008-12-02 2010-06-23 华为技术有限公司 通信网络和通信方法
EP2454858B1 (en) 2009-07-17 2014-01-29 Koninklijke KPN N.V. Congestion Control in a Telecommunications Network
US20110072487A1 (en) 2009-09-23 2011-03-24 Computer Associates Think, Inc. System, Method, and Software for Providing Access Control Enforcement Capabilities in Cloud Computing Systems
US8982738B2 (en) * 2010-05-13 2015-03-17 Futurewei Technologies, Inc. System, apparatus for content delivery for internet traffic and methods thereof
US20120025057A1 (en) * 2010-05-20 2012-02-02 Jawad Sahloul Body- mounted portable viewing system for electronic devices
EP2583211B1 (en) 2010-06-15 2020-04-15 Oracle International Corporation Virtual computing infrastructure
EP3748907B1 (en) * 2010-07-02 2023-08-30 Vodafone IP Licensing limited Charging in telecommunications networks
US8873498B2 (en) 2010-07-02 2014-10-28 Telefonaktiebolaget L M Ericsson (Publ) Network sharing in an evolved packet core network
FR2962848B1 (fr) * 2010-07-15 2014-04-25 Soitec Silicon On Insulator Substrat temporaire, procede de transfert et procede de fabrication
US20120039175A1 (en) * 2010-08-11 2012-02-16 Alcatel-Lucent Usa Inc. Enabling a distributed policy architecture with extended son (extended self organizing networks)
KR101663012B1 (ko) * 2010-11-15 2016-10-06 삼성전자 주식회사 Ｓｉｍ 기반 데이터 통신 설정 제어 방법 및 이를 지원하는 휴대 단말기
US8488494B2 (en) * 2011-03-31 2013-07-16 Alcatel Lucent Rules system versions
US8873398B2 (en) 2011-05-23 2014-10-28 Telefonaktiebolaget L M Ericsson (Publ) Implementing EPC in a cloud computer with openflow data plane
US9154327B1 (en) * 2011-05-27 2015-10-06 Cisco Technology, Inc. User-configured on-demand virtual layer-2 network for infrastructure-as-a-service (IaaS) on a hybrid cloud network
US8693401B2 (en) 2011-07-20 2014-04-08 Connectem Inc. Method and system for optimized handling of context using hierarchical grouping (for machine type communications)
US9019990B2 (en) * 2012-07-13 2015-04-28 Telefonaktiebolaget L M Ericsson (Publ) Using encapsulation headers to indicate internet protocol packet fragmentation in cellular networks
EP2873268B1 (en) 2012-07-14 2018-01-17 Tekelec, Inc. Methods, systems, and computer readable media for dynamically controlling congestion in a radio access network
US9160606B2 (en) 2012-12-04 2015-10-13 John D. Almon Remote access system for using scientific algorithms in local data processing
US9775099B2 (en) * 2013-05-02 2017-09-26 Nokia Solutions And Networks Oy Methods and apparatus for access network selection
US9241305B2 (en) * 2013-10-28 2016-01-19 At&T Intellectual Property I, L.P. Access network discovery and selection function enhancement with cell-type management object
GB201400302D0 (en) 2014-01-08 2014-02-26 Vodafone Ip Licensing Ltd Telecommunications network

Also Published As

Publication number Publication date
WO2015104546A1 (en) 2015-07-16
GB201400302D0 (en) 2014-02-26
EP3092833A1 (en) 2016-11-16
EP3092835B1 (en) 2020-08-26
EP3092835A1 (en) 2016-11-16
ES2827682T3 (es) 2021-05-24
EP3092834A1 (en) 2016-11-16
EP3092834B1 (en) 2020-01-01
US10362583B2 (en) 2019-07-23
US10194448B2 (en) 2019-01-29
EP3092833B1 (en) 2020-08-05
WO2015104548A1 (en) 2015-07-16
US20160330610A1 (en) 2016-11-10
US20160330330A1 (en) 2016-11-10
WO2015104545A1 (en) 2015-07-16
US20160330748A1 (en) 2016-11-10

Similar Documents

Publication Publication Date Title
ES2833410T3 (es) Redes de telecomunicaciones
US11064370B2 (en) Telecommunication networks
US10085185B2 (en) Telecommunications network with optimisation of content delivery
US8929292B2 (en) Mobility support in a mobile data network
US9794856B2 (en) Telecommunication networks
US8942174B2 (en) Reducing packet loss in a mobile data network with data breakout at the edge
US10298750B2 (en) Telecommunication networks for content delivery and lawful interception, content filtering and further content services using a SAVI platform
US9253683B2 (en) Utilizing stored data to reduce packet data loss in a mobile data network with data breakout at the edge