ES2384200T3 - Procedimiento para el reconocimiento de paquetes de datos específicos de función - Google Patents

Abstract

Procedimiento para el reconocimiento de paquetes de datos específicos de función, que son generados por unterminal emisor y enviados a través de una red de líneas de datos a un terminal receptor, presentando los paquetesde datos una cabecera ("header") y un área de datos ("payload"), teniendo los paquetes de datos asignados unservicio especial y siendo los mismos generados por una función adecuada, realizada en el terminal emisor, en elque se adjunta a los paquetes de datos un marcado específico generado en el terminal por medio de la cual unafunción filtrante ("función de carga por servicio") dispuesta en la red de líneas de datos reconoce los paquetes dedatos marcados y los asigna a la funcionalidad específica, sin que haya pérdidas en el contenido de información,caracterizado porque el marcado es aplicado por una función cargada en el terminal, y porque como marcado seaplica una firma electrónica específica para el servicio.

Description

Procedimiento para el reconocimiento de paquetes de datos especificos de funci6n

5 La presente invenci6n se refiere a un procedimiento para el reconocimiento de paquetes de datos especificos de funci6n, en especial con el objetivo de la posterior facturaci6n, siendo los paquetes de datos generados por un terminal emisor y enviados a traves de una red de lineas de datos, en especial por Internet, a un terminal receptor, presentando los paquetes de datos una cabecera ("header") y un area de datos ("payload"), teniendo los paquetes de datos asignados una funcionalidad especifica, en especial un servicio particular, y siendo generados por una funci6n adecuada, realizada en el terminal emisor. Ademas, la invenci6n se refiere a un dispositivo para llevar a cabo este procedimiento. Para el "billing", es decir la facturaci6n de servicios de telecomunicaci6n, se conocen diferentes modelos: Hay modelos que estan basados en la comunicaci6n ("session") en los que se factura la comunicaci6n de una de las

15 partes, normalmente de la parte llamante. Pero a veces, la comunicaci6n se factura a la parte llamada como es el caso, por ejemplo, de los numeros "0800" conocidos en Alemania. En algunos casos aislados incluso existe la posibilidad, vease "peterzahlt.de", de que una tercera parte corre con los gastos de la comunicaci6n. La financiaci6n se realiza entonces especialmente a traves de inserciones de publicidad. Desde hace algun tiempo se conoce tambien los denominados modelos "de tarifa plana", en los que la parte llamante abona una suma global de acuerdo con un contrato firmado con el proveedor que cubre todos los servicios de telecomunicaciones salientes que pueden utilizar, ademas de la red telef6nica, tambien Internet. Ademas, se conocen modelos que dependen del volumen en los que la facturaci6n se realiza basandose en el

25 volumen de datos transferidos. Algo similar se puede decir para los modelos en los que la facturaci6n se realiza basandose en la utilizaci6n de un formato de datos especifico, es decir en un modo de transmisi6n determinado como los SMS y MMS, siendo esta facturaci6n independiente del volumen de datos transferidos. Sin embargo, los modelos de facturaci6n conocidos actualmente estan limitados en sus posibilidades de tarificaci6n de prestaciones o servicios especificos. En especial para el cliente, resulta a veces dificil poder evaluar cuanto volumen de datos requiere un servicio determinado y cuanto cuesta realmente la utilizaci6n del servicio. Esta incertidumbre afecta precisamente la atractividad de los servicios m6viles presuntamente costosos. Estos se siguen aceptando s6lo con reservas. Una facturaci6n mas transparente aumentaria la aceptaci6n, especialmente de estos servicios m6viles. Sin embargo, una condici6n para la facturaci6n basada en el servicio es que el proveedor

35 reconozca primero la utilizaci6n del servicio por el cliente. El reconocimiento de la utilizaci6n es sencillo para el operador de red en aquellos casos en los que el servicio se proporciona por el lado de la red, es decir especialmente por el mismo operador de red. En este caso, el trafico de datos s6lo ha de ser examinado referente a la medida en que la direcci6n IP del servidor es utilizada como direcci6n de destino con trafico de datos entrante o como direcci6n de origen con trafico de datos saliente. Igual de facil resulta el reconocimiento tambien, cuando se utiliza una infraestructura tecnica especial para la utilizaci6n del servicio, tal como es el caso, por ejemplo, de los SMS y MMS. Sin embargo, resulta dificil en aquellos casos en los que el servicio se pone a disposici6n en un terminal individual. Un ejemplo para esta aplicaci6n que se realiza substancialmente sin infraestructura del lado de la red y que utiliza la red s6lo para la transmisi6n es "skype.com"

45 donde se ha de descargar el correspondiente programa en el terminal antes de utilizar el servicio. Una posibilidad de reconocer el trafico de datos generado por estos servicios la proporcionaria el "Protocolo de Iniciaci6n de Sesi6n" (Session Initiation Protocol, SIP) mediante el correspondiente "Protocolo de Descripci6n de Sesi6n" (Session Description Protocol, SDP), segun RFC 3261. En este caso, se describe el tipo de sesi6n en el SDP. Pero si se utiliza un tipo de sesi6n "barato" referente a los volumenes de datos, por ejemplo el "videostreaming", no se podra asegurar que este servicio realmente sea utilizado en los terminales en cuesti6n. Puede ocurrir perfectamente que el "videostreaming" sea simulado por los terminales y que en realidad son servicios totalmente diferentes los que aprovechan para si este "modo barato".

55 Ademas, resultan problematicas las marcaciones de servicios basadas en SIP ya que las sesiones de SIP estan formadas generalmente por el trafico de datos de senalizaci6n y el trafico de datos de transporte. Esto significa que dentro de la red se han de hacer coincidir eventuales marcaciones de servicio en la senalizaci6n SIP con los correspondientes traficos de datos de transporte. Esto conlleva un considerable gasto tecnico. Ademas, un marcado de servicio basado en SIP va ligado a servicios basados en SIP. El documento "Policy and charging control architecture" ("Politicas y arquitectura de control de cargas") 3GPP TS23.203V8.0.0 (2007-12) describe filtros o identificadores antepuestos en el lado de red, entre otros, que asocian en una red de telefonia m6vil los paquetes de datos enviados en la red a un servicio de datos especifico por medio de la cabecera que contiene la direcci6n.

65 En el documento "Telecommunication management; Charging management; Charging architecture and principles"

3GPP TS 32.240 V8.2.0 (2008-03) se describe un estandar para el desarrollo de sistemas de pago en redes de telefonia m6vil.

Del documento EP 1 746 772 A1 se desprende un procedimiento y un sistema para la tarificaci6n de aplicaciones y/o el trafico de datos asociado a las mismas en un sistema de comunicaci6n por radio, en el que hay una funci6n antepuesta en el lado de la red.

El documento WO 2005/004390 A1 se refiere a un procedimiento para la tarificaci6n de datos de trafico con la ayuda de clases de IP. Los datos de trafico se marcan de acuerdo con una norma de asignaci6n como pertenecientes a una clase de direcci6n IP. Una unidad de red a lo largo de la ruta de envio de los datos de trafico evalua los datos de trafico en cuanto a su clase de IP para su tarificaci6n, y transmite el resultado de la evaluaci6n a otra unidad de red.

El objetivo de la presente invenci6n consiste en dar transparencia al usuario y facilitar al operador de red de modo sencillo y seguro la tramitaci6n a traves de su red tambien de aquellos servicios que se inician en terminales y utilizan la estructura de red solamente para la transferencia de datos. El control ha de servir especialmente para los fines de la posterior facturaci6n. Ademas, la invenci6n tambien tiene el objetivo de proponer un sistema para llevar a cabo el procedimiento.

Estos objetivos se consiguen mediante el procedimiento con las caracteristicas de la reivindicaci6n 1 y el sistema segun la reivindicaci6n 8. Las realizaciones ventajosas se indican en las correspondientes reivindicaciones dependientes.

La idea fundamental de la invenci6n consiste en el hecho de que los paquetes de datos son dotados en el terminal emisor de un marcado asimismo generado por el terminal, por medio del cual cada paquete de datos puede ser asignado a un determinado servicio mediante una funci6n filtrante ("funci6n de cargo por servicio") dispuesta en la red de lineas de datos. Un marcado de este tipo se lleva a cabo por una funci6n adecuada, instalada en el terminal, sin que haya perdidas en el contenido de la informaci6n. Esa funci6n puede ser cargada ("upload") en el terminal del cliente por el operador de red o bien el cliente se la puede descargar ("download") de la red. El marcado puede estar formado por una firma que se adjunta al paquete de datos. De acuerdo con la idea fundamental de la invenci6n, los flujos de datos son dotados del marcado especifico para cada servicio sin modificar la informaci6n de cabecera de los paquetes de datos individuales, pudiendo ser adaptada adecuadamente la suma de comprobaci6n.

Para este tipo de marcado se pueden utilizar procedimientos de firma electr6nica conocidos por el estado de la tecnica, por ejemplo segun el principio de clave publica (Public Key). Como marcado, se aplica de esta manera una firma electr6nica que se sirve especialmente de claves privadas y publicas. Por medio de los flujos de datos marcados, el operador de red puede reconocer la utilizaci6n de servicios que se han generado fuera de su acceso, pero que utilizan su red. La invenci6n consiste, por lo tanto, de cierta manera en un marcado o encriptaci6n especifico para cada servicio en la que la clave es, en especial, especifica de la aplicaci6n.

Resulta ventajoso que la firma se extienda a lo largo de toda el area de datos (Payload) o, como minimo, a lo largo de partes esenciales de la misma. Tambien puede extenderse a traves de otras informaciones que complementan el area de datos, tal como la identificaci6n del usuario, el ID del terminal y/o similares.

Una ventaja esencial es el reconocimiento especifico del servicio y la posibilidad de realizar la correspondiente facturaci6n o tambien el descuento. De esta manera, resultan ventajas esenciales con respecto a procedimientos que se refieren, por ejemplo, a la descripci6n de servicio descrita anteriormente en el marco de SIP/SDP. Otra ventaja esencial consiste en el reconocimiento de servicio a nivel del protocolo de Internet ("nivel de IP"). De esta manera, el modo de proceder, segun la invenci6n, puede ser aplicado a todos los protocolos que estan basados en IP, de manera que la facturaci6n especifica de servicio es posible para aplicaciones que estan basadas en SIP, http, RTP o IP.

Del reconocimiento resultan, ademas, otras ventajas. Durante un "streaming" a traves de un terminal m6vil se puede, por ejemplo, aumentar el ancho de banda o los parametros de QoS de forma especifica para cada servicio. Desde el punto de vista de una empresa de telecomunicaciones resulta ventajoso que a partir de ahora se pueden controlar y facturar tambien los servicios generados en terminales. De esta manera, las aplicaciones mencionadas tal como Skype se vuelven valiosas tambien para las empresas de telecomunicaciones con infraestructura de red. En este caso, tambien es posible que la red o el proveedor del servicio adquiera mejores condiciones de transmisi6n del operador de red para su servicio adecuadamente marcado, especialmente un ancho de banda mas amplio o garantizado, menos "jitter", es decir menos cambios bruscos e indeseados de la caracteristica de senal y/o reducidos tiempos de latencia.

Ademas, el modo de proceder, segun la invenci6n, facilita el desplazamiento de la generaci6n del servicio a terminales, en especial m6viles, cada vez mas pequenos y mas rapidos. Esto ocurre porque con el procedimiento de la invenci6n el proveedor del servicio y el proveedor de la red de transporte tienen a disposici6n un medio con el que se pueden reconocer servicios generados en el lado del terminal. Debido a que ahora, por un lado, se pueden facturar los servicios que se habian utilizado hasta el momento de forma gratuita y que, por otro lado, se puede

ofrecer un compromiso de calidad de servicio especifico del servicio para la transmisi6n, se produce una situaci6n win-win para el operador de red y para el proveedor de servicios implementados en el lado del terminal. El modo de proceder, segun la invenci6n, ofrece al cliente una facturaci6n justa, transparente y basada en el volumen de utilizaci6n referida al servicio.

La invenci6n tambien hace posible la via inversa. Las funciones instaladas por los operadores de red en los terminales de sus clientes hacen posible que un determinado tipo de transferencia de datos no sea recogido por la facturaci6n. Ademas, tambien se pueden enlazar funciones que miden continuamente los parametros de calidad de servicio de la red o determinan la ubicaci6n actual y transmiten estos parametros al operador de red. En total, la flexibilidad queda mejorada con respecto a una facturaci6n basada en las direcciones de origen y de destino por el hecho de que las direcciones IP pueden ser modificadas por los servicios, sin que ello influya sobre la facturaci6n.

Ademas, se puede garantizar una protecci6n contra la utilizaci6n de la aplicaci6n en redes ajenas. Finalmente, las aplicaciones modificadas de acuerdo con el procedimiento mostrado aqui no se pueden utilizar sin mas en redes ajenas, a no ser que la red ajena ponga a disposici6n la aplicaci6n y las claves. Desde el punto de vista del operador de red las aplicaciones estan acopladas a la red en el lado del cliente.

El modo de proceder mostrado es facilmente escalable y se deja representar como componente en elementos de redes de acceso, por ejemplo, como parte de un "controlador de frontera de sesi6n" (Session �order Controller).

A continuaci6n, se explicara la invenci6n con mas detalle haciendo referencia a las figuras 1 y 2. Estas muestran:

Figura 1 un grafico de la "funci6n de desarrollo de servicios" y

Figura 2 un grafico del desarrollo del procedimiento, segun la invenci6n.

Los sistemas para llevar a cabo el procedimiento, segun la invenci6n, presentan especialmente los siguientes componentes: Primero se preven los terminales necesarios para la utilizaci6n del servicio que estan conectados a la red del proveedor de telecomunicaciones. Los terminales tienen instaladas las funciones que prestan el servicio. En la misma red esta dispuesta una funci6n de cargo por servicio (Service Charge Function, SCF) como funci6n de red que reconoce y registra el trafico de datos marcado especificamente. Ademas, en la red esta dispuesta una funci6n de desarrollo del servicio (Service Deployment Function, SDF) con la que se pueden configurar las funciones y cargarlas e instalarlas en los terminales como "bundles" o fajos. El procedimiento, segun la invenci6n, puede ser dividido en tres etapas:

Etapa A: Preparaci6n de las funciones y carga ("Deployment")

La preparaci6n de las funciones y su "deployment" o desarrollo en el terminal se llevan a cabo por la funci6n de desarrollo de servicio SDS 1 mostrada en la figura 1: Primero la empresa de telecomunicaciones edita una clave privada 2, necesaria para crear la firma, para el transporte de datos y la entrega junto con la aplicaci6n. Conjuntamente con el c6digo de servicio (Service Code) 3 codificado, por ejemplo en �ava, se genera un c6digo fuente (Source Code) 4 parametrizado con la clave destinada al transporte de datos. La clave es parte integral del paquete de instalaci6n que se instala en el terminal. Todos los datos que saldran posteriormente de la aplicaci6n a las redes de la empresa de telecomunicaciones son firmadas por el terminal con esta clave. La clave privada, asi como el c6digo de la aplicaci6n pueden ser ofuscados 5 con las medidas adecuadas tales como, por ejemplo, mediante compilaci6n o con ofuscadores.

Para asegurar la integridad de la aplicaci6n y de la clave del transporte de datos 2 la empresa de telecomunicaciones firma los paquetes de instalaci6n con una clave adecuada 6, siendo esta diferente de la clave 2 para el transporte de datos. Esta firma del paquete de instalaci6n 7 garantiza la originalidad de la aplicaci6n e impide que intrusos (troyanos) puedan robar la identidad de la aplicaci6n.

Mediante mecanismos de gesti6n remota de dispositivos (Remote Device Management) se instalan los paquetes de instalaci6n 7 en el terminal 9 especificado por el juego de datos 8 en un entorno de ejecuci6n 11 adecuadamente seguro, siendo senaladas las funciones instaladas con el numeral 10. Adicionalmente, se modifica la clave privada en intervalos regulares y se actualiza mediante actualizaci6n remota en los terminales afectados, repitiendose las etapas representadas.

Las claves utilizadas pueden ser depositadas para su posterior verificaci6n durante el transporte de datos por la SCF en bancos de datos adecuados, por ejemplo, de forma global en un banco de datos 12 para claves validas o de forma especifica para cada usuario y/o terminal en un banco de datos de perfil de usuario 13.

Etapa �: Marcado de servicio

En la figura 2 se muestra el terminal designado 9, con el entorno de ejecuci6n seguro y la funcionalidad, segun la invenci6n, de las funciones instaladas 10. Con la funcionalidad 10, segun la invenci6n, se codifica todo el trafico

saliente, generado por una aplicaci6n (servicio) que se ejecuta en el terminal 9, a nivel del area de datos del paquete. A tal efecto, un paquete de datos 14 generado inicialmente por la aplicaci6n esta compuesto de una cabecera ("header") 15 y un area de datos ("payload") 16. En la cabecera 15 estan depositadas especialmente la direcci6n de destino del paquete de datos asi como las informaciones acerca de la integridad del paquete de datos. Durante el marcado, segun la invenci6n, cada paquete de datos 14 es transformado en un nuevo paquete de datos

17:

A traves del paquete de datos original 14 se crea una firma 19 con la ayuda de la clave 18 que corresponde a la clave 2, y con esta firma se genera una nueva area de datos 20. Esta resulta de la cabecera original 15�, el area de datos original 16� y por anteponer la firma 19. Para la creaci6n de la firma se utilizan procedimientos habituales utilizando sistemas asimetricos de clave publica. En la pr6xima etapa se forma una nueva cabecera 21 que resulta de la cabecera original 15, siendo la suma de comprobaci6n de la cabecera 21 adaptada a la nueva situaci6n. Exceptuando la direcci6n de destino que es adaptada con el fin de desviar los paquetes de datos 17 a la direcci6n de la funci6n de cargo por servicio (SCF) 22, todo lo demas queda igual que antes.

En el caso de que la longitud total del paquete de datos 17 sobrepase la longitud maxima, este puede ser fragmentado y el area de datos puede ser distribuido en dos paquetes de datos. En esta forma se enviara el paquete de datos 17 de direcci6n a la direcci6n de destino, senalando esta direcci6n de destino a la SCF, tal como se ha descrito anteriormente.

Etapa C: Identificaci6n y demarcaci6n

En la etapa � se ha modificado la direcci6n de destino del paquete de datos 17 a la de la SCF 22, de manera que es dirigido alli a traves de la red 23. La SCF 22 verifica mediante su clave publica la autenticidad del paquete de datos. Si la verificaci6n se realiza con exito, se comunica este hecho a los sistemas dispuestos detras 24 que gestionan, por ejemplo, la facturaci6n de manera que se puede llevar a cabo una tarificaci6n correcta en funci6n del servicio. A tal efecto, se parte primero del caso de que ambos participantes en la comunicaci6n estan conectados directamente a la red 23 de la empresa de telecomunicaciones. De esta manera, se tienen en cuenta todos los participantes, uno para el trafico de datos salientes, el otro para los entrantes.

Si la verificaci6n no se lleva a cabo con exito, el paquete de datos 17 sera descartado. En su caso, la funcionalidad 24 puede realizar una "detecci6n de fraude" (Fraud Detection) para investigar la causa, por ejemplo un intento de pirateria. Dado que las claves son cambiadas regularmente, la SCF 22 puede verificar por medio del banco de datos 12 si, eventualmente, las claves publicas utilizadas son obsoletas. Tambien se puede llevar a cabo una comparaci6n con el banco de datos de perfiles de usuarios 13. Si no se puede enmendar el error por medio de las verificaciones, el paquete de datos sera descartado.

Una vez identificado el paquete de datos 17 se realiza su demarcaci6n deshaciendo los pasos que se han realizado en la etapa �. Esto significa que se restablece el paquete de datos original 14 con la cabecera original 15, el area de datos original 16 y la correspondiente direcci6n original, y el mismo es enviado a traves de la red 25 al destinatario 26 al que estaba destinado inicialmente. Sin el "desvio", segun la invenci6n, este hubiera sido contactado directamente por la via 27 a traves de la red no mostrada.

Claims (9)

1. REIVINDICACIONES

   1. Procedimiento para el reconocimiento de paquetes de datos especificos de funci6n, que son generados por un terminal emisor y enviados a traves de una red de lineas de datos a un terminal receptor, presentando los paquetes 5 de datos una cabecera ("header") y un area de datos ("payload"), teniendo los paquetes de datos asignados un servicio especial y siendo los mismos generados por una funci6n adecuada, realizada en el terminal emisor, en el que se adjunta a los paquetes de datos un marcado especifico generado en el terminal por medio de la cual una funci6n filtrante ("funci6n de carga por servicio") dispuesta en la red de lineas de datos reconoce los paquetes de datos marcados y los asigna a la funcionalidad especifica, sin que haya perdidas en el contenido de informaci6n,

   10 caracterizado porque el marcado es aplicado por una funci6n cargada en el terminal, y porque como marcado se aplica una firma electr6nica especifica para el servicio.
2. 2. Procedimiento, segun la reivindicaci6n 1, caracterizado�porque la carga de la funci6n la lleva a cabo el operador

   de la red. 15

3. 3.

   Procedimiento, segun la reivindicaci6n 1 6 2, caracterizado porque la firma se sirve de claves privadas y publicas.

4. 4.

   Procedimiento, segun una de las reivindicaciones anteriores, caracterizado porque durante el marcado se

   20 escribe una nueva direcci6n en la cabecera de los paquetes de datos mediante la cual se desvian los mismos a la funci6n de cargo por servicio ("SCF").
5. 5. Procedimiento, segun una de las reivindicaciones anteriores, caracterizado porque dentro de la SCF se elimina

   el marcado y los paquetes de datos adquieren otra vez su forma inicial. 25

6. 6.

   Procedimiento, segun una de las reivindicaciones anteriores, caracterizado porque el filtrado por SCF se utiliza para los fines de la facturaci6n, en especial de la utilizaci6n de la red.

7. 7.

   Procedimiento, segun una de las reivindicaciones anteriores, caracterizado porque los paquetes de datos son

   30 enviados de acuerdo con un protocolo basado en IP, siendo posible en especial una facturaci6n especifica de servicio para aplicaciones que estan basadas en SIP, http, RTP o IP.
8. 8. Procedimiento, segun una de las reivindicaciones anteriores, caracterizado porque durante el reconocimiento de

   los paquetes de datos marcados se inicia un aumento del ancho de banda o de los parametros QoS. 35
9. 9. Sistema que lleva a cabo el procedimiento, segun una de las reivindicaciones anteriores.