ES2380526A1

ES2380526A1 - Métodos y sistema para negociar y autorizar la capacidad de servicio Ethernet.

Info

Publication number: ES2380526A1
Application number: ES201090076A
Authority: ES
Inventors: Nanjian Qian; Cancan Huang; Yingzhe Wu
Original assignee: ZTE USA Inc
Current assignee: ZTE USA Inc
Priority date: 2008-05-30
Filing date: 2009-05-29
Publication date: 2012-05-16
Anticipated expiration: 2029-05-29
Also published as: WO2009155120A3; RU2010154288A; WO2009155120A2; MX2010012919A; ES2380526B1

Abstract

Métodos y sistema para negociar y autorizar la capacidad de servicio Ethernet.Se describen métodos y sistemas para negociar y autorizar uno o más servicios Ethernet y/o IP elegidos entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico. En una realización, una entidad de red de servicio transmite datos de capacidad de servicio Ethernet a una entidad de servicio de conectividad de origen. Opcionalmente, los datos de capacidad de servicio Ethernet pueden incluir datos de capacidad de servicio Ethernet asociados a una entidad de servicio de conectividad visitada. A continuación, la entidad de servicio de conectividad de origen determina que servicios Ethernet y/o IP están autorizados a una estación móvil particular asociada a la entidad de red de servicios de acceso en función de los datos de capacidad de servicio Ethernet recibidos, de un perfil de abonado y de una política de red de origen.

Description

Métodos y sistema para negociar y autorizar la capacidad de servicio Ethernet.

Referencias a solicitudes relacionadas

La presente solicitud reivindica la prioridad de la solicitud provisional de patente estadounidense Nº 61/057766, titulada “MÉTODO PARA NEGOCIAR Y AUTORIZAR LA CAPACIDAD DE SERVICIO ETHERNET”, cuyo contenido queda incorporado en su totalidad al presente documento por referencia.

Campo de la invención

La presente invención se refiere en general a redes de comunicaciones inalámbricas, y más concretamente, a un método y un sistema para negociación del servicio Ethernet y su autorización entre diversas entidades de red.

Antecedentes de la invención

Debido a la creciente popularidad de los dispositivos móviles, es necesario permitir a los usuarios conectarse a diversos dominios, en función de su emplazamiento actual. Un usuario puede precisar acceder a los recursos proporcionados por una red visitada distinta de su propia red de origen. La necesidad de un servicio prestado por una red visitada requiere, en muchos modelos, una negociación y autorización entre el dispositivo móvil y la red visitada.

Más concretamente, en la actualidad es necesario proporcionar un método y un sistema para negociar y autorizar la capacidad de servicio Ethernet entre diversas entidades de red. Además, es necesario aprovechar el proceso de autenticación y autorización del acceso a la red para negociar el adecuado servicio Ethernet entre las diferentes entidades de red que utilizan protocolos de autorización remota.

Sumario de la invención

Las realizaciones que se describen en este documento están orientadas a la resolución de uno o más de los problemas que presenta la técnica anterior, y que se han descrito anteriormente, además de proporcionar características adicionales que se apreciarán fácilmente haciendo referencia a la siguiente descripción detallada, estudiada en conjunción con las figuras adjuntas.

Un ejemplo de la presente invención se refiere a un método para negociar y autorizar uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico. En una realización, el método comprende transmitir una primera señal desde un primer dispositivo de red a un segundo dispositivo de red, estando la primera señal adaptada para indicar los datos de capacidad de servicio Ethernet asociados al primer dispositivo de red; recibir en el primer dispositivo de red una segunda señal procedente del segundo dispositivo de red, estando adaptada la segunda señal para indicar un conjunto de servicios Ethernet autorizados a una estación móvil adaptada para comunicarse con el primer dispositivo de red; y almacenar los datos en el primer dispositivo de red, estando los datos adaptados para indicar el conjunto de servicios Ethernet autorizados correspondientes a la estación móvil.

En una segunda realización, el método comprende: recibir en un segundo dispositivo de red una primera señal procedente de un primer dispositivo de red, estando la primera señal adaptada para indicar los datos de capacidad de servicio Ethernet asociados al primer dispositivo de red; determinar un conjunto de servicios Ethernet autorizados a una estación móvil adaptada para comunicarse con el primer dispositivo de red, a partir, al menos parcialmente, de los datos de capacidad de servicio Ethernet; y transmitir una segunda señal procedente del segundo dispositivo de red al primer dispositivo de red, estando la segunda señal adaptada para indicar el conjunto de servicios Ethernet autorizados a la estación móvil.

En una tercera realización, el método comprende: recibir en un dispositivo intermedio de red un conjunto de datos de capacidad, estando adaptado el conjunto de datos de capacidad para indicar los datos de capacidad de servicio Ethernet asociados al primer dispositivo de red; añadir los datos de capacidad Ethernet asociados al dispositivo de red intermedio al conjunto de datos de capacidad; transmitir el conjunto de datos de capacidad a un segundo dispositivo de red, estando el segundo dispositivo de red adaptado para generar un conjunto de datos de autorización que indiquen un conjunto de servicios Ethernet autorizados para una estación móvil que se comunica con el primer dispositivo de red, en el que el conjunto de datos de autorización está basado, al menos parcialmente, en el conjunto de datos de capacidad;

De este modo, las realizaciones descritas en el presente documento proporcionan un método y un sistema para negociar y autorizar la capacidad de servicio Ethernet entre diversas entidades de red. Debe entenderse que tanto la descripción general que antecede como la siguiente descripción detallada constituyen meros ejemplos y pretenden explicar más detalladamente el asunto objeto de las reivindicaciones.

Las características, naturaleza y ventajas de la presente invención serán más evidentes gracias a la siguiente descripción detallada, en conjunción con las figuras, en las que las mismas referencias identifican a los elementos correspondientes, y en las cuales:

La figura 1 es una ilustración, mediante un diagrama de bloques, de un ejemplo de arquitectura de un sistema de comunicación inalámbrico de acuerdo con una realización de la presente invención.

La figura 2 es una ilustración, mediante un diagrama de bloques, de un ejemplo de estación móvil de una red de comunicación inalámbrica, de acuerdo con una realización de la presente invención.

La figura 3 es una ilustración, mediante un diagrama de bloques, de un ejemplo de red de servicio de acceso, de acuerdo con una realización de la presente invención.

La figura 4 es una ilustración, mediante un diagrama de bloques, de un ejemplo de una red de servicio de conectividad, de acuerdo con una realización de la presente invención.

La figura 5 es un diagrama de flujo que muestra un ejemplo de un método para negociar el servicio Ethernet e IP de acuerdo con una realización de la presente invención.

La figura 6 es un organigrama que muestra un ejemplo de método para negociar y autorizar uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, de acuerdo con una realización de la presente invención.

La figura 7 es un organigrama que muestra un ejemplo de método para negociar y autorizar uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, de acuerdo con una realización de la presente invención.

La figura 8 es un organigrama que muestra un ejemplo de método para negociar y autorizar uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, de acuerdo con una realización de la presente invención.

La figura 9 es un diagrama de un ejemplo de mensaje RADIUS, que indica la capacidad WiMAX de acuerdo con una realización de la invención.

La figura 10 es un diagrama de un ejemplo de definición RADIUS TLV para indicar diversas capacidades de servicio de la ASN y la V-CSN, de acuerdo con una realización de la invención.

La figura 11 es un diagrama de un ejemplo de mensaje RADIUS que proporciona la dirección IPv4 de VCSN HA para MIP4, de acuerdo con una realización de la invención.

La figura 12 es un diagrama de un ejemplo de mensaje RADIUS, que proporciona la dirección IPv6 del HA utilizado para MIP6, de acuerdo con una realización de la invención.

La figura 13 es un diagrama de un ejemplo de mensaje RADIUS, en el que se establece la dirección IPv4 de un servidor V-CSN DHCP para ser utilizada para asignar la dirección IPv4, de acuerdo con una realización de la invención.

La figura 14 es un diagrama de un ejemplo de mensaje RADIUS, en el que se establece la dirección IPv6 de un servidor V-CSN DHCP para ser utilizada para asignar la dirección IPv6, de acuerdo con una realización de la invención.

La figura 15 es un ejemplo de mensaje RADIUS, en el que se proporciona la dirección IPv4 del V-CSN LMA para su utilización para la asignación de la dirección IPv4, de acuerdo con una realización de la invención.

La figura 16 es un diagrama de un ejemplo de mensaje RADIUS, en el que se proporciona la dirección IPv4 del H-CSN LMA para su utilización para la asignación de la dirección IPv4, de acuerdo con una realización de la invención.

La figura 17 es un diagrama de un ejemplo de mensaje RADIUS, en el que se establece la dirección IPv4 del V-CSN LMA para su utilización para la asignación de la dirección IPv6, de acuerdo con una realización de la invención.

La figura 18 es un diagrama de un ejemplo de mensaje RADIUS, en el que se establece la dirección IPv4 del H-CSN LMA para su utilización para la asignación de la dirección IPv6, de acuerdo con una realización de la invención.

La figura 20 es un diagrama de un ejemplo de mensaje RADIUS, en el que se establece la dirección IPv4 del H-CSN CR para su utilización para la asignación de la dirección IPv4, de acuerdo con una realización de la invención.

La figura 21 es un diagrama de un ejemplo de mensaje RADIUS, en el que se establece la dirección IPv4 del V-CSN CR para su utilización para la asignación de la dirección IPv6, de acuerdo con una realización de la invención.

La figura 22 es un diagrama de un ejemplo de mensaje RADIUS, en el que se establece la dirección IPv4 del H-CSN CR para su utilización para la asignación de la dirección IPv6, de acuerdo con una realización de la invención.

Descripción detallada de los ejemplos de realización de la invención

En la siguiente descripción de los ejemplos de realización se hará referencia a las figuras adjuntas que forman parte de la misma, y en las que se muestran a modo de ejemplo realizaciones específicas en las que puede llevarse a la práctica la invención. Debe entenderse que pueden utilizarse otras realizaciones y que pueden introducirse cambios estructurales sin apartarse del alcance de la presente invención.

Según se utiliza en el presente documento, el término “red de servicio de acceso” (ASN) incluye sin limitación cualquier conjunto de funciones de red que proporcionen acceso radioeléctrico a una estación móvil.

Según se utiliza en el presente documento, el término “estación base” (BS) incluye sin limitación un conjunto generalizado de equipos que proporciona conectividad, gestión y control de una estación de abonado (MSS).

Según se utiliza en el presente documento, el término “red de servicio de conectividad” (CSN) incluye sin limitación cualquier conjunto de funciones de red que proporcionen servicios de conectividad IP a una estación móvil que disponga de capacidad para conectividad IP.

Según se utiliza en el presente documento, el término “estación móvil” (MS) incluye sin limitación una estación con servicio móvil diseñada para su utilización en movimiento o durante paradas efectuadas en puntos no especificados.

Según se utiliza en el presente documento, el término “punto de referencia” (RP) incluye sin limitación un enlace conceptual que conecta dos grupos de funciones que residen en diferentes entidades funcionales de una ASN, CSN o MSS. Obsérvese que no es estrictamente necesario que un “punto de referencia” sea un interfaz físico.

Según se utiliza en el presente documento, el término “punto de referencia R3” incluye sin limitación un conjunto de protocolos de plano de control entre una ASN y una CSN para soportar la implementación de la política de autenticación, autorización y contabilización (AAA) y las capacidades de gestión de la movilidad. También puede incluir los métodos de plano de portadora (por ejemplo, canalización) para transferencia de datos IP entre una ASN y una CSN.

Según se utiliza en el presente documento, el término “agente propio” (HA) incluye sin limitación un router de una red de origen de nodos móviles que canaliza un mensaje de datos para su entrega al nodo móvil cuando está alejado de su origen. También puede mantener la actual información de ubicación del nodo móvil.

Según se utiliza en el presente documento, el término, el término “agente propio de servicio Ethernet” (eHA) incluye sin limitación un módulo con las funciones habituales de un agente propio, así como la función de puente. Por lo tanto, este módulo puede enviar, anclar, clasificar, y canalizar tramas puras de Ethernet en lugar de paquetes IP.

Según se utiliza en el presente documento, el término “agente externo” (FA) incluye sin limitación un router de una red visitada que pueda canalizar o eliminar la canalización de un mensaje de datos para su entrega al nodo móvil cuando este se encuentra alejado de su origen. El agente externo también puede mantener la información de canalización correspondiente al nodo móvil.

Según se utiliza en el presente documento, el término “agente externo del servicio Ethernet” (eFA) incluye sin limitación un módulo con las funciones habituales de un agente externo, así como la capacidad de recibir, clasificar y canalizar tramas Ethernet puras en lugar de paquetes IP.

Según se utiliza en el presente documento, el término “anclaje de movilidad local” (LMA) incluye sin limitación un agente propio de un nodo móvil en el dominio IPv6 móvil del Proxy. El anclaje de movilidad local puede

Según se utiliza en el presente documento, el término “pasarela de acceso móvil” (MAG) incluye sin limitación una entidad en la que reside la función de agente móvil del Proxy.

Según se utiliza en el presente documento, el término servicio simple de Ethernet” incluye sin limitación un servicio que utiliza entidades funcionales no basadas en MIP (es decir, un puente Ethernet en una CSN) para proporcionar servicios Ethernet a través de una red WiMAX. El puente vinculado a la CSN puede proporcionar un puerto de puente dedicado para cada una de las estaciones móviles ancladas a la CSN.

Según se utiliza en el presente documento, el término “Servicio Ethernet basado en MIP” incluye sin limitación un servicio que despliega la IP móvil para proporcionar una configuración de túnel dinámica en RD de forma que se encargue de la itinerancia de área amplia y de la movilidad los terminales basados en Ethernet-CS. Debido a su comportamiento dinámico, el interfaz R3 puede definirse por completo para servicios Ethernet basados en MIP.

Según se utiliza en el presente documento, el término “red WiMAX” incluye sin limitación una arquitectura de red basada la norma inalámbrica IEEE 802.16 d/e.

Según se utiliza en el presente documento, el término “router de acceso” (AR) incluye sin limitación un primer router de salto situado en una ASN que se utiliza para proporcionar servicios de canalización del tráfico IP simple.

Según se utiliza en el presente documento, el término “función de envío de acceso de servicio Ethernet” (eAFF) incluye sin limitación una primera ubicación de la función de envío de salto en una ASN utilizada para el envío de tráfico del servicio Simple Ethernet. La eAFF podría utilizarse dentro de un router para canalizar una trama pura de Ethernet hacia el otro extremo de un punto de canalización.

Según se utiliza en el presente documento, el término “router principal” (CR) incluye sin limitación un router de conexión situado en una CSN y que se utiliza para la canalización del tráfico IP simple. Un router principal puede ser la contrapartida de un router de acceso.

Según se utiliza en el presente documento, el término “función principal de envío del Servicio Ethernet” (eCFF) incluye sin limitación una función de envío de paquetes de Ethernet que se encuentra situada en una CSN y que se utiliza para el tráfico del servicio Ethernet simple. La eCFF puede ser la contrapartida de una eAFF. También puede hacer referencia a una función de puente.

El término “ejemplo” se utiliza en el presente documento de forma que signifique “sirve como ejemplo o ilustración”. Cualquier aspecto o diseño descrito en el presente documento como “ejemplo” no debe interpretarse necesariamente como preferido o ventajoso frente a otros aspectos o diseños.

A continuación se hará referencia en detalle a diversos aspectos de la tecnología del objeto de la invención, mostrándose ejemplos en las figuras adjuntas, en las que los mismos números de referencia corresponden a elementos similares.

Debe entenderse que el orden o jerarquía específicos de las etapas de los procesos descritos en el presente documento constituye un ejemplo de métodos de ejemplificación. En función de las preferencias de diseño, debe entenderse que el orden específico o la jerarquía de las etapas de los procesos puede reconfigurarse, siempre que siga incluido dentro del alcance de la presente invención. Las reivindicaciones del método adjuntas presentan elementos de las diversas etapas en un orden de ejemplo, y no significa que se limiten al orden o jerarquía específicos que se presentan.

Una red WiMAX, por ejemplo, puede proporcionar a un usuario final servicios IP y Ethernet en función de los requisitos comerciales del proveedor del servicio, los perfiles del abonado, la arquitectura de la red y la información sobre la capacidad de la entidad de red. Como se describirá de forma más detallada más adelante, para proporcionar una sesión de servicio de usuario fructífera, pueden participar diversas entidades de red principales, comprendiendo una red de servicios de acceso (ASN), una red de servicios de conectividad de origen (H-CSN) y/o una red de servicios de conectividad visitada (V-CSN). Cada entidad de red puede ser capaz de proporcionar múltiples servicios Ethernet e IP. Entre las capacidades que pueden asociarse con una ASN se encuentran, por ejemplo, la transmisión DHCPv4, la transmisión DHCPv6, el Proxy DHCPv4, el Proxy DHCPv6, FA, el cliente PMIP, AR con transporte IPv4, AR con transporte IPv6, eAFF con transporte IPv4, y eAFF con transporte IPv6. Entre las funciones que pueden asociarse a una V-CSN se encuentran, por ejemplo, las de servidor v-DHCPv4, servidor vDHCPv6, MIP-HAv4, MIP-HAv6, MIP-eHAv4, y MIP-eHAv6. Teniendo en cuenta que cada entidad de red puede tener diferentes funciones de servicio Ethernet y de servicio IP varias de las realizaciones de la presente invención se refieren a un nuevo método para negociar y autorizar capacidad de servicio entre las diversas entidades de red.

La figura 1 ilustra un ejemplo de arquitectura de un sistema de comunicación inalámbrico, de acuerdo con una realización de la presente invención. La red de comunicaciones inalámbricas puede ser una red WiMAX que se ajuste al protocolo del sistema de comunicación del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) 802.16. No obstante, la presente invención no se limita a ningún tipo de red específico, y pueden implementarse diversas tecnologías de red que realizan negociaciones de la capacidad de servicio, sin apartarse por ello del alcance de la presente invención.

De acuerdo con la realización descrita en la figura 1, una red de comunicación inalámbrica incluye una estación móvil 100. Una ASN 120 asociada a un proveedor de acceso a la red (NAP) 150 puede proporcionar un conjunto de funciones de red que soporten el acceso radioeléctrico a la estación móvil 100. De este modo, cuando la estación móvil 100 se encuentra muy cerca de una ASN 120, la estación móvil 110 puede tratar de adquirir servicios Ethernet y/o IP a la ASN 120.

En algunas realizaciones, la ASN 120 puede negociar y determinar qué servicios de Internet y/o IP van a proporcionarse a la estación móvil 100 después de que dichos servicios hayan sido autorizados por la H-CSN 130. La red inalámbrica de comunicaciones de la figura 1 puede también incluir una V-CSN 140, que puede actuar como proxy de la H-CSN 130. Es decir, que la ASN 120 puede transferir datos IP a la H-CSN 130 "canalizándolos" a través de la V-CSN 140 utilizando las conexiones R3 y R5. Obsérvese que a los efectos de este ejemplo, la V-CSN 140 y la H-CSN pueden existir dentro del proveedor de acceso de la red visitada (NSP) 160 y del NSP de origen 170, respectivamente. Adicionalmente, tanto la V-CSN 140 como la H-CSN 130 pueden ser capaces de facilitar acceso a las respectivas redes del proveedor de servicio de aplicaciones (ASP) o a Internet 141 y 131.

Como se muestra en la figura 1, la conexión R2 muestra un punto de referencia entre la estación móvil 100 y las entidades de red del servicio de conectividad (V-CSN 140 y H-CSN 130). Para implementar la configuración de la red, la estación móvil 100 puede estar físicamente conectada a la ASN 120 mediante una conexión por cable o inalámbrica a través de la conexión Rl. La ASN 120 puede conectarse de forma inalámbrica o de otra forma a una o más ASNs 121, a través de la conexión R4. Por supuesto, la arquitectura descrita anteriormente constituye tan sólo un ejemplo ilustrativo, y pueden incluirse otras diversas entidades de red y combinaciones de las mismas, sin apartarse del alcance de la presente invención.

La figura 2 es una ilustración de un ejemplo de estación móvil 100 en una red de comunicación inalámbrica, de acuerdo con una realización de la presente invención. En un ejemplo de realización, la estación móvil 100 puede ser una agenda digital personal (PDA), tal como un dispositivo “Blackberry”, un reproductor MP3 u otro dispositivo portátil similar. De acuerdo con varias realizaciones, la estación móvil 100 puede ser un ordenador personal inalámbrico, tal como un ordenador “notebook” inalámbrico o un ordenador inalámbrico “palmtop”.

Como se muestra en la figura 2, el ejemplo de estación móvil 100 puede incluir un módulo transmisor-receptor 200, configurado para que soporte protocolos alternativos o adicionales de comunicaciones de datos inalámbricas. Estos protocolos incluyen, sin limitación, las futuras variaciones de IEEE 802.16 (como 802.16e, 802.16m, etc.).

Por lo general, el módulo transmisor-receptor 200 suele permitir la comunicación bidireccional entre la estación móvil 100 y diversas entidades de red a través de la antena 230. Obsérvese que el módulo transmisor-receptor 200 puede configurarse para soportar tráfico de Internet o WiMAX, y para proporcionar un interfaz Ethernet

802.3.

En algunas realizaciones, la estación móvil 100 incluye un módulo procesador 210, configurado para realizar las funciones, técnicas y tareas de procesamiento asociadas con el funcionamiento de la estación móvil 100. El módulo procesador 210 puede incluir cualquier número de dispositivos o combinaciones de dispositivos conocidos en la técnica. Estos incluyen, por ejemplo, procesadores de uso general, módulos de memoria de contenido direccionable, procesadores de señales digitales, circuitos integrados específicos de la aplicación, matrices de puerta programables, matrices lógicas programables, lógicas discretas de puerta o transistor, u otros componentes electrónicos de ese tipo.

Además, las etapas de un método o algoritmo descrito en relación con las realizaciones descritas en el presente documento pueden realizarse directamente en un módulo de hardware, firmware o software ejecutado por el módulo procesador 210 o en cualquier combinación práctica de los mismos. Un módulo de software puede residir en un dispositivo de almacenamiento legible por ordenador 220, que puede realizarse como una memoria RAM, una memoria flash, una memoria ROM, una memoria EPROM, una memoria EEPROM, registros, un disco duro, un disco portátil, un CD-ROM o cualquier otro tipo de soporte de almacenamiento conocido en la técnica. A este respecto, el dispositivo de almacenamiento legible por ordenador 220 puede acoplarse al módulo procesador 210, de forma que el módulo 210 pueda leer información y escribir información en el dispositivo de almacenamiento legible por ordenador 220. En algunas realizaciones, el dispositivo de almacenamiento legible por ordenador 220 incluye una memoria caché para almacenar variables temporales u otra información intermedia durante la ejecución de las instrucciones que han de ser ejecutadas por el módulo procesador 210. En algunas realizaciones, el dispositivo de almacenamiento legible por ordenador 220 incluye también una memoria no volátil.

El dispositivo de almacenamiento legible por ordenador 220 puede incluir una base de datos de estructura de trama (no mostrada) de acuerdo con algunas realizaciones de la presente invención. Esta base de datos de parámetros de la estructura de trama se puede configurar para almacenar, mantener y proporcionar los datos necesarios para soportar la funcionalidad de un sistema de comunicación inalámbrico. Además, la base de datos de estructura de trama puede incluir una tabla de búsquedas a fin de almacenar los parámetros de la estructura de trama. Obsérvese que la base de datos de estructura de la trama puede consistir en una base de datos local (por ejemplo, acoplada al módulo procesador 210) o en una base de datos remota (por ejemplo, una base de datos de red centralizada).

La figura 3 muestra un ejemplo de red ASN 120, de acuerdo con una realización de la presente invención. La ASN 120 puede incluir un módulo transmisor-receptor 300 acoplado a una antena 340, así como un módulo procesador 310 y un dispositivo de almacenamiento legible por ordenador 320. El módulo transmisor-receptor 300, el módulo procesador 310 y el dispositivo de almacenamiento legible por ordenador 320 pueden configurarse de forma similar a la del módulo transmisor-receptor 200, el módulo procesador 210 y el dispositivo de almacenamiento legible por ordenador 220 descritos anteriormente, haciendo referencia a la figura 2. La ASN 120 puede incluir adicionalmente un módulo de autenticación 330 para transmitir datos de capacidad de servicio asociadas con la ASN 120 a un módulo remoto a través del módulo transmisor-receptor 300. Estos datos de capacidad de servicio pueden ser utilizados por la CSN 130 para determinar un conjunto de servicios Ethernet y/o IP autorizados a la estación móvil 100.

La figura 4 muestra un ejemplo de red CSN (por ejemplo, H-CSN 130 o V-CSN 140), de acuerdo con una realización de la presente invención. La CSN 130 o 140 puede incluir un módulo transmisor-receptor 400, acoplado de forma que pueda comunicarse con una antena 440, y un dispositivo de almacenamiento legible por ordenador 420, cuyas funcionalidades son similares a las descritas anteriormente en relación con el módulo transmisor-receptor 200 y el dispositivo de almacenamiento legible por ordenador 220 de la figura 2. La CSN 130 o 140 incluye adicionalmente un módulo procesador módulo / servidor 410, que puede ser, por ejemplo, un procesador de autenticación, autorización y contabilización (AAA) en una H-CSN 130. Obsérvese que el módulo procesador/módulo servidor 410 puede implementarse de forma similar al módulo procesador 210 descrito anteriormente haciendo referencia a la figura 2.

Si la CSN comprende una V-CSN 140, también se puede incluir un módulo de autenticación del proxy 430. En una realización, el módulo de autenticación del proxy 430 está adaptado para transmitir datos de capacidad de servicio ASN 120 y datos de capacidad de servicio V-CSN 140 a la H-CSN 130. La H-CSN puede transmitir a continuación datos de autorización al módulo de autenticación del Proxy V-CSN al determinar un conjunto de servicios autorizados Ethernet y/o servicios IP para la estación móvil 100. A continuación, estos datos pueden ser enviados por el módulo de autenticación del proxy 430 a la ASN 120 para su almacenamiento a nivel local.

Por supuesto, cualquier persona versada en la materia se dará cuenta de que la CSN 130 o 140 descrita anteriormente, constituye tan solo un ejemplo, pudiendo incluirse diversas combinaciones de componentes, así como otros componentes adicionales, sin alejarse del ámbito de la presente invención.

La figura 5 es un diagrama de flujo que muestra un ejemplo de método de negociación de servicio Ethernet e IP de acuerdo con una realización de la presente invención. Esta secuencia se puede producir después de que la estación móvil 100 busque servicios Ethernet y/o IP desde la ASN 20.

Como se muestra en la figura 5, la ASN 120 envía inicialmente una petición AAA 502(1) a un servidor HAAA (no mostrado) que se encuentra en el interior de la H-CSN 130. de acuerdo con una serie de realizaciones, la petición AAA 502(1) incluirá datos de capacidad de servicio Ethernet ASN, así como datos de capacidad de acceso IP ASN asociados a la ASN 120.

Si una V-CSN 140 está utilizándose como proxy para el servidor H-AAA, la petición AAA 502(1) puede enviarse a la V-CSN 140 en lugar de hacerlo directamente a la H-CSN 130. En algunas realizaciones, después de que la V-CSN 140 reciba el mensaje de petición AAA 502(1) desde la ASN 120, la V-CSN puede añadir a estos datos otros datos de capacidad de servicio Ethernet de la V-CSN y de capacidad de acceso IP de la V-CSN. La solicitud resultante AAA 502(2) puede enviarse entonces a la H-CSN 130.

El servidor H-AAA puede entonces autentificar y autorizar un conjunto de servicios Ethernet y/o IP correspondientes a la estación móvil 100 a partir de una política de red de origen, de un perfil de abonado asociado a la estación móvil 100, y de los datos de capacidad incluidos en la petición AAA 502. A continuación, una vez que el servidor H-AAA ha autentificado y autorizado satisfactoriamente un conjunto de servicios para la estación móvil 100, el servidor H-AAA puede devolver una respuesta AAA 504 a la ASN 120. Obsérvese que la respuesta AAA puede canalizarse a través de la V-CSN 140 si la V-CSN 140 está utilizándose como proxy del servidor H-AAA.

A continuación, la ASN 120 puede extraer servicios Ethernet autorizados y/o IP a la estación móvil 100. Esta información puede almacenarse a nivel local y ponerse disponible para su utilización por parte de las correspondientes entidades funcionales del servicio Ethernet y del servicio IP de la ASN 120. En función del resultado del proceso de autenticación y autorización, la ASN 120 puede ofrecer servicios Ethernet y/o IP a la

La figura 6 es un organigrama que muestra un ejemplo de método para negociar y autorizar uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, de acuerdo con una realización de la presente invención. El método puede utilizarse, por ejemplo, para permitir que una ASN 120 proporcione un conjunto de servicios autorizados a la estación móvil 100 que lo solicita.

En el bloque 602 se recibe inicialmente una petición de servicios desde una estación móvil 100. Los servicios Ethernet e IP que pueden prestarse a la estación móvil 100 se determinan entonces en el bloque 604 (obsérvese que aunque la figura 6 describe en general un proceso de gestión de solicitudes de servicios Ethernet y/o IP relacionados, debe entenderse que la presente invención no se limita estrictamente a los servicios relacionados con de Ethernet y/o IP, y puede ampliarse fácilmente también a otros servicios).

En el bloque 606, los datos de capacidad de servicio se transmiten a una CSN (por ejemplo, a través de una V-CSN 140 o de una H-CSN 130). En algunas realizaciones, los datos de capacidad de servicio se transmiten como una petición AAA 502 que incluye cuatro atributos del servicio RADIUS (Remote Authentication Dial-In User Service [servicio de usuario de identificación a distancia]): (i) capacidad de servicio Ethernet ASN; (ii) capacidad de servicio IP de la ASN; (iii) capacidad de servicio Ethernet de la V-CSN; y (iv) capacidad de servicio IP de la V-CSN. De este modo, una ASN 120 puede definir los dos primeros atributos, a saber: (i) capacidad de servicio Ethernet de la ASN y (ii) Capacidad de servicio IP de la ASN, aunque una V-CSN define los dos últimos atributos: (iii) capacidad de servicio Ethernet de la V-CSN y (iv) capacidad de servicio IP de la V-CSN. Obsérvese que en algunas realizaciones puede utilizarse un protocolo AAA diferente como alternativa (por ejemplo, un protocolo DIAMETER).

Una vez determinado que se han recibido los datos de autorización de una CSN (bloque 608), los datos de autorización pueden almacenarse en el bloque 610. En algunas realizaciones, los datos se pueden almacenar a nivel local, por ejemplo, en un servidor de acceso a la red (NAS) situado en la ASN 120. En otras realizaciones, los datos se pueden almacenar a nivel remoto y accederse a ellos a nivel local. A continuación, los datos pueden ponerse a disposición de las entidades funcionales de servicios Ethernet y/o IP de la ASN 120. En la etapa 612, la petición de la estación móvil puede procesarse en función de que se haya determinado si se han autorizado los servicios solicitados.

A continuación se describe un ejemplo del conjunto de normas que rigen el comportamiento del NAS en un entorno WiMAX. Obsérvese que las siguientes reglas son tan sólo ejemplos de una realización específica de la presente invención. No obstante, ha de entenderse que se pueden definir innumerables reglas y comportamientos de los dispositivos para permitir la negociación de la capacidad de servicio Ethernet e IP de acuerdo con el alcance de la presente invención.

De este modo, en una realización, el NAS incluirá atributos del servicio Ethernet y de capacidad de Servicio IP de la ASN dentro de la VSA de capacidad WiMAX en el mensaje de petición de autenticación AAA 502 y remitirá este mensaje 502 a la H-AAA de la H-CSN 130 a través de un Proxy AAA en una V-CSN 140 (en el caso de que se utilice una V-CSN 140). La información sobre la capacidad puede ser transportada por distintos bits de un tipo, longitud, valor (TLV) o por diferentes TLVs. Si el NAS recibe el atributo de servicio IP y servicio Ethernet autorizado en la VSA de capacidad WiMAX del mensaje de respuesta de autenticación AAA 504, el NAS almacenará esta información a nivel local y la utilizará para indicar qué servicios Ethernet y/o IP han sido autorizados a la estación móvil 100. Si el NAS recibe un mensaje de respuesta de autenticación AAA 504 que requiere que la ASN 120 proporcione un servicio Ethernet o IP que no puede soportar, el NAS considerará el mensaje de respuesta de autenticación AAA 504 tal como una denegación de acceso.

Si el NAS recibe una autorización IPv4 simple a través del atributo de servicio IP/Ethernet autorizado en la VSA de capacidad WiMAX de acceso-aceptación RADIUS, el NAS almacenará esta información a nivel local y hará que esté disponible para su posterior utilización para un servicio simple IPv4 anclado de acuerdo con la sub-TLV de ubicación de anclaje autorizada. Si el NAS recibe una autorización simple IPv6 a través del atributo de servicio IP/Ethernet autorizado de la la VSA de capacidad WiMAX de acceso-aceptación RADIUS, el NAS almacenará esta información a nivel local y hará que esté disponible para su posterior utilización para un servicio simple IPv6 anclado de acuerdo con la sub-TLV de ubicación de anclaje autorizada. Si el NAS recibe una autorización simple de servicio Ethernet a través del atributo de servicio autorizado IP/Ethernet del mensaje de respuesta de autenticación AAA de la VSA de capacidad WiMAX, el NAS almacenará esta información a nivel local y hará que esté disponible para su posterior utilización para un servicio Ethernet simple anclado de acuerdo con la sub-TLV de ubicación de anclaje autorizada.

Si el NAS recibe atributos vHA-IP-MIP4 o hHA-IP-MIP4 en el mensaje de respuesta de autenticación AAA 504, el NAS almacenará estos atributos HAv4 a nivel local y hará que esté disponible para su posterior utilización con servicios Ethernet basados en CMIPv4, PMIPv4, o MIP por parte de la estación móvil 100. Si el NAS recibe atributos a través de vHA-IP-MIP6 y/o hHA-IP-MIP6 en el mensaje de respuesta de autenticación AAA, el NAS almacenará estos atributos HAv6 a nivel local y hará que estén disponibles para su posterior utilización para servicios CMIPv6 por parte de la estación móvil 100.

Si el NAS recibe atributos de servidor vDHCP o hDHCP en el mensaje de respuesta de autenticación AAA 504, el NAS almacenará estos atributos a nivel local y hará que estén disponible para su posterior utilización en una posterior operación de señalización DHCP. Estos atributos también pueden indicar que la función de transmisión DHCP está habilitada para la estación móvil 100. Si el NAS no recibe atributos del servidor DHCP en el mensaje de respuesta de autenticación AAA, esto indica que la funcionalidad de Proxy DHCP está habilitada para la estación móvil 100. El NAS puede entonces almacenar a nivel local los atributos de configuración de IP y Host, poniéndolos disponibles para su utilización en una posterior operación de señalización DHCP. Estos atributos también pueden indicar que la funcionalidad de Proxy DHCP está habilitada para la estación móvil 100.

Si el NAS recibe atributos vLMA o hLMA en el mensaje de respuesta de autenticación AAA 504, el NAS almacenará estos atributos a nivel local y los pondrá como disponibles para su utilización en posteriores servicios PMIP v6 o servicios Ethernet MIP por parte de la estación móvil 100. Si el NAS recibe atributos vCR, hCR, veCFF, o heCFF en un mensaje de respuesta de autenticación AAA 504, el NAS almacenará estros atributos a nivel local y los pondrá como disponibles para su utilización en posteriores servicios IPv4 simple, IPv6 simple, o Ethernet simple por parte de la estación móvil 100.

Por último, si el NAS recibe atributos del servidor DHCP en el mensaje de respuesta de autenticación AAA 504, el NAS almacenará estos atributos a nivel local y los pondrá como disponibles para su posterior utilización en una operación de señalización DHCP. Estos atributos pueden indicar que la función de transmisión DHCP está habilitada para la estación móvil 100. Si el NAS no recibe atributos del servidor DHCP en el mensaje de respuesta de autenticación AAA 504, esto puede indicar que la función del Proxy DHCP está habilitada para la estación móvil

100.

La figura 7 es un organigrama que muestra un ejemplo de método para negociar y autorizar uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, de acuerdo con una realización de la presente invención. El método puede utilizarse, por ejemplo, para permitir que una H-CSN 130 transmita un conjunto de servicios Ethernet y/o IP autorizados a una estación móvil 100.

En el bloque 702 se reciben los datos de capacidad de servicio. En ciertas realizaciones, los datos de capacidad de servicio incluyen un conjunto de cuatro atributos: (i) capacidad de servicio Ethernet de la ASN; (ii) capacidad de servicio IP de la ASN; (iii) capacidad de servicio Ethernet de la V-CSN; y (iv) capacidad de servicio IP de la V-CSN. Los datos pueden estar contenidos en un mensaje de petición de autorización AAA 502 que se rige mediante un protocolo AAA (por ejemplo, RADIUS, DIAMETER, etc.), o pueden adoptar otro formato en función de las realizaciones de la presente invención.

En el bloque 704 se determina un conjunto de servicios Ethernet e IP autorizados a la estación móvil 100 que efectúa la solicitud. El conjunto de servicios autorizados puede basarse en un perfil de abonado asociado a la estación móvil 100, en una política de red de origen, en los datos de capacidad de servicio recibidos, o en cualquier combinación de los mismos.

En el bloque 706, el conjunto de servicios autorizados se trasmite a la ASN 706. El conjunto de servicios autorizados puede residir en un mensaje de respuesta de autorización AAA 504 que se rige por un protocolo AAA (por ejemplo, RADIUS, DIAMETER, etc.), o pueden adoptar otro formato en función de las realizaciones de la presente invención. Obsérvese que si una V-CSN 140 está sirviendo de Proxy para un servidor H-AAA, el mensaje puede transmitirse a la V-CSN 140 antes de ser enviado a la ASN 120.

A continuación se describe un ejemplo del juego de reglas que rigen el comportamiento de la H-CSN 140 y una H-AAA correspondiente. Obsérvese que las siguientes reglas constituyen tan sólo ejemplos ilustrativos de una realización concreta de la presente invención. No obstante, debe entenderse que se pueden definir innumerables reglas y comportamientos de los dispositivos para permitir la negociación de la capacidad de servicio Ethernet e IP de acuerdo con el alcance de la presente invención.

En una realización, si la H-CSN 130 recibe un mensaje de petición de autenticación AAA, la H-CSN 130 autorizará los correspondientes servicios Ethernet e IP para una estación móvil determinada 100 en función del perfil de abonado asociado a la estación móvil 100, de una política de red de origen, y de los datos recibidos de capacidad de servicio (por ejemplo, capacidad de servicio IP de la ASN, capacidad de servicio Ethernet de la ASN, capacidad de servicio IP de la V-CSN y capacidad de servicio Ethernet de la V-CSN). El H-AAA de la H-CSN 130 enviará un mensaje de respuesta de autenticación AAA hacia el NAS en la ASN 130 (obsérvese que el mensaje de respuesta de autenticación AAA pasará a través de una V-CSN 140 en caso que la estación móvil 100 se encuentre en itinerancia).

En una realización, el H-AAA incluirá los atributos del servicio Ethernet e IP autorizados para indicar los servicios IP/Ethernet para los que está autorizada la estación móvil 100. El H-AAA no autorizará un servicio IP o Ethernet que no pueda ser soportado por la H-CSN 130 y la ASN 120.

Si el H-AAA tiene autorizado un servicio CMIPv4 o PMPv4, el HAAA incluirá atributos vHA-IP-MIP4 o hHAIP-MIP4 en el mensaje de respuesta de autenticación AAA 504. Si el H-AAA ha autorizado el servicio MIP de Ethernet, el H-AAA incluirá atributos vHA-IP-MIP4, hHA-IP-MIP4, vHA-IP-MIP6, o hHA-IP-MIP6 en el mensaje de

Si el H-AAA incluye atributos del Servidor DHCP V-CSN 140 o H-CSN 130, el H-AAA indicará que ha autorizado el uso de la función de transmisión DHCP en la ASN 120. El H-AAA debería autorizar la función Proxy DHCP tan sólo en el caso de que la ASN 120 hubiese indicando anteriormente el correspondiente soporte. Sin embargo, si el H-AAA no incluye atributos del servidor DHCP V-CSN 140 o H-CSN 130, el H-AAA indicará el uso autorizado de la funcionalidad de Proxy DHCP en la ASN 120. El H-AAA debería autorizar la funcionalidad del Proxy DHCP tan sólo si la ASN hubiese indicado anteriormente el correspondiente soporte.

La figura 8 es un organigrama que muestra un ejemplo de método para negociar y autorizar uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, de acuerdo con una realización de la presente invención. El método puede utilizarse, por ejemplo, para permitir que una V-CSN 140 transmita un conjunto de servicios autorizados a una estación móvil 100 que lo ha solicitado.

En el bloque 802, lo datos de capacidad de servicio se reciben desde una ASN 120. Los datos de capacidad de servicio pueden estar incluidos en un mensaje de petición de autorización AAA 502 que se rige por un protocolo AAA (por ejemplo, RADIUS, DIAMETER, etc.), o pueden adoptar otro formato, en función de las realizaciones de la presente invención. En algunas realizaciones, los datos de capacidad de servicio contienen cuatro atributos: (i) capacidad de servicio Ethernet de la ASN; (ii) capacidad de servicio IP de la ASN; (iii) capacidad de servicio Ethernet de la V-CSN; y (iv) capacidad de servicio IP de la V-CSN. De este modo, las capacidades asociadas a la ASN 120 pueden ser aportadas por los dos primeros atributos, mientras que las capacidades asociadas a la V-CSN 140 pueden añadirse a los dos últimos atributos. El proceso de anexión de servicios V-CSN a los datos de capacidad de servicio se muestran en el bloque 804.

En el bloque 806, los datos de capacidad de servicio se transmiten a la H-CSN 130. A continuación, la HCSN 130 puede calcular un conjunto de servicios autorizados a la estación móvil 100 a partir, al menos parcialmente, de los datos de capacidad de servicio. Una vez que los datos de autorización se han recibido desde la H-CSN 130 en el bloque 808, estos datos pueden transmitirse entonces a la ASN 120 en el bloque 810. La ASN 120 puede entonces facilitar a la estación móvil 100 tan sólo aquello servicios que aparecen indicados como autorizados.

A continuación se describe un ejemplo del juego de reglas que rigen el comportamiento de la V-CSN 140. Obsérvese que las siguientes reglas constituyen tan sólo ejemplos ilustrativos de una realización concreta de la presente invención. No obstante, debe entenderse que se pueden definir innumerables reglas y comportamientos de los dispositivos para permitir la negociación de la capacidad de servicio Ethernet e IP de acuerdo con el alcance de la presente invención.

De este modo, en una realización, si el Proxy AAA de la V-CSN 140 recibe un mensaje de petición de autenticación AAA 502 procedente del NAS en la ASN 120, la V-CSN 140 adjuntará su propio servicio Ethernet de la V-CSN atributos de capacidad de servicio IP de la V-CSN al mensaje original de solicitud de acceso RADIUS enviado desde la ASN 120. Posteriormente, la V-CSN 140 enviará este mensaje al H-AAA en la H-CSN 130.

La V-CSN 140 adjuntará una dirección de servidor V-HA/V-eHA y/o vDHCP (v4 o v6) al mensaje de petición de autenticación AAA 502 y lo enviará al H-AAA en la H-CSN 130 si la V-CSN 140 es capaz de prestar estos servicios. La V-CSN no proporcionará un servicio IP que no esté autorizado en el menaje de respuesta de autenticación AAA 504. Igualmente, la V-CSN 140 no proporcionará un servicio Ethernet que no esté autorizado en el mensaje de respuesta de autenticación AAA 504. Si la V-CSN 140 recibe un mensaje que exige que preste soporte a un servicio Ethernet o a un servicio IP que no puede soportar, la V-CSN 140 considerará el mensaje de respuesta de autenticación AAA 504 como una denegación de acceso.

Las figuras 9 a 22, así como las correspondientes tablas, muestran ejemplos de definiciones Tipo-Longitud-Valor (TLV) de los atributos RADIUS específicos del vendedor, de acuerdo con una realización de la presente invención. Por supuesto, el protocolo RADIUS se utiliza meramente con fines de ejemplo, pudiendo utilizarse otros protocolos sin apartarse del ámbito de la presente invención.

Obsérvese que el RADIUS Tipo 26 se describe a través de las figuras 9 a 22. No obstante, pueden incluirse otros atributos específicos del vendedor, así como las diversas longitudes y las IDs del vendedor. Los atributos específicos del vendedor (por ejemplo, RADIUS tipo 26, Longitud e Id del Vendedor), de acuerdo con lo mostrado en las figuras 9 a 22, puede representarse mediante cualquier valor común por lo que no se describe en las tablas siguientes. Las siguientes tablas incluyen atributos específicos de WiMAX, como el tipo WiMAX (WType-ID), así como las correspondientes longitudes y los valores de máscara binaria. Se muestran a título de ejemplo máscaras binarias de 4 octetos; no obstante, pueden utilizarse otras longitudes dentro del alcance de la presente invención.

La figura 9 muestra un ejemplo de la definición TLV de RADIUS para indicar la capacidad WiMAX, mientras que las tablas 1 y 2 muestran ejemplos de Tipo-Longitud-Valor (TLV)de la capacidad Ethernet e IP de la ASN 120/Vcsn 140 para una definición del servicio Ethernet /IP autorizado de acuerdo con una realización de la presente invención. Obsérvese que los parámetros indicados tienen un carácter meramente ejemplar; los parámetros reales se pueden definir de múltiples formas en función del alcance de la presente invención. Por ejemplo, en algunas realizaciones, la capacidad ASN y V-CSN puede estar integrada en un solo TLV, utilizando diferentes bits para identificar la capacidad Ethernet, la capacidad IP y/u otras capacidades de servicio. En algunas realizaciones, el servicio Ethernet autorizado y el TLV de servicio autorizado pueden integrarse en un solo TLV, con diferentes bits que identifican diferentes informaciones de servicio.

Tabla 1

WType-ID: 1 para el atributo de capacidad WiMAX

Descripción: En una solicitud de acceso, el atributo identifica las capacidades WiMAX soportadas por la ASN o el HA. En un proceso de acceso-aceptación, el atributo identifica las opciones seleccionadas por el servidor RADIUS.

Longitud: 6 + 3 + TLVs

Continuación: C-bit = 0

Valor: Uno o más de lo siguientes valores sub-TLV (véase más adelante)

Tabla 2

ID TLV: Nombre TLV Bits de longitud AR AA AC R

1: Versión WiMAX 6 1 0 0 0

2: Capacidad de contabilización 3 1 1 0 0

3: Capacidad de línea directa 3 0-1[a] 0 0 0

4: Capacidad de notificación en modo inactivo 3 0-1[b] 0-1[c] 0 0

5: Capacidad de servicio IP de la ASN 6 1[d], [f] 0 0 0

6: Capacidad de servicio IP de la VCSN 6 0-1[e], [f] 0 0 0

7: Servicios IP autorizados 6 0 1[f] 0 0

8: Ubicaciones de anclaje autorizadas 3 0 1[f] 0 0

9: Capacidades de servicio Ethernet de la ASN 6 1[d],[f] 0 0 0

10: Capacidades de servicio Ethernet de la VCSN 6 0-1[e],[f] 0 0 0

11: Servicios Ethernet autorizados 6 0 1[F] 0 0

Obsérvese que en la tabla 2 se han facilitado unas notaciones adicionales [a]-[f]. La notación [a] indica que

10 la ausencia de esta sub-TLV en una solicitud de acceso (AR) significa que el NAS o el HA no soportan la capacidad de línea directa. La notación [b] indica que la ausencia de esta sub-TLV en una solicitud de acceso (AR) significa que el NAS no soporta la notificación en modo inactivo. Esta sub-TLV no aparece en una solicitud de acceso con origen en un HA. El H-AAA ignorará en silencio esta sub-TLV en los mensajes procedentes de un HA. La notación

[c] indica que la ausencia de esta sub-TLV en una aceptación de acceso (AA) significa que el H-AAA no requiere la

15 notificación en modo de inactividad. El HAAA no enviará esta sub-TLV a un HA. Un HA ignorará en silencio esta sub-TLV. La notación [d] indica que esta sub-TLV ha sido incluida por la ASN para indicar sus capacidades de servicio IP soportadas. La notación [e] indica que esta sub-TLV debería estar presente cuando la estación móvil se acopla a la red visitada, y es incluida por la V-CSN para indicar sus capacidades de servicio IP soportadas. La notación [f] indica que esta TLV no se incluirá en ninguna versión de WiMAX anterior a la versión 1.5.

20 La figura 10 muestra un ejemplo de la definición TLV de RADIUS que se puede utilizar para indicar diversas capacidades de servicio de ASN y V-CSN (por ejemplo, capacidades de servicio Ethernet e IP) de acuerdo con una realización de la presente invención. Obsérvese que puede identificarse un número o un código con WType-ID (Véase la tabla 3 más adelante). No obstante, con fines de ejemplo, se muestra una "?" en las tablas siguientes.

Tabla 3

WType-ID: ? Capacidad de servicio ASN IP

Descripción: Este atributo puede incluirse en un mensaje RADIUS de petición de acceso al servidor RADIUS e indica capacidades de servicio IP relacionadas con la red ASN

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

Valor: Máscara binaria de 4 octetos con los siguientes valores: 0x00000001 = Transmisión DHCP 0x00000002 = Proxy DHCP 0x00000004 = FA 0x00000008 = Cliente PMIP 0x00000010 = MAG con transporte Ipv4 0x00000020 = MAG con transporte Ipv6 0x00000040 = AR con transporte Ipv4 0x00000080 = AR con transporte Ipv6 Los bits restantes se encuentran reservados

La tabla 4 resume el ejemplo de información de un mensaje RADIUS que puede utilizarse para indicar la capacidad de servicio Ethernet de la ASN:

Tabla 4

WType-ID: ? Capacidad de servicio Ethernet de la ASN

Descripción: Este atributo puede incluirse en un mensaje RADIUS de petición de acceso al servidor RADIUS e indica capacidades de servicio Ethernet relacionadas con la red ASN

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

Valor: Máscara binaria de 4 octetos con los siguientes valores: 0x00000001 = eAFF con Transporte IPv4 0x00000002 = eAFF con Transporte IPv6 0x00000004 = eFA Los bits restantes se encuentran reservados

La tabla 5 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la capacidad de servicio IP de la V-CSN:

WType-ID: ? Capacidad de servicio IP de V-CSN

Descripción: Este atributo puede incluirse en un mensaje RADIUS de petición de acceso al servidor RADIUS e indica capacidades de servicio IP relacionadas con la red V-CSN

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

Valor: Máscara binaria de 4 octetos con los siguientes valores: 0x00000001 = Servidor DHCPv4 0x00000002 = Servidor DHCPv6 0x00000004 = HAv4 0x00000008 = HAv6 0x00000010 = LMA con transporte Ipv4 0x00000020 = LMA con transporte Ipv6 0x00000040 = CR con transporte Ipv4 0x00000080 = CR con transporte Ipv6 El resto de bits quedan reservados

La tabla 6 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la capacidad de servicio Ethernet de la V-CSN:

Tabla 6

WType-ID: ? Capacidad de servicio Ethernet de V-CSN

Descripción: Este atributo puede incluirse en un mensaje RADIUS de petición de acceso al servidor RADIUS e indica capacidades de servicio Ethernet relacionadas con la red V-CSN

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

Valor: Máscara binaria de 4 octetos con los siguientes valores: 0x00000001 = eCFF con Transporte IPv4 0x00000002 = eCFF con Transporte IPv6 0x00000004 = eHAv4 0x00000008 = eHAv6 El resto de bits quedan reservados

Las figuras 11 a 22, que se describen a continuación, proporcionan ejemplos de TLVs de RADIUS que definen los valores de otros parámetros, como la dirección IP de vHA-IPv4, la dirección IP de vLMA, etc. Las TLVs

La figura 11 muestra un ejemplo de definición TLV RADIUS, que establece que las capacidades de servicio IP de la ASN 120 y/o la V-CSN 140 incluyen vHA-IP-MIP4, de acuerdo con una realización de la invención. Por supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 7 se resume la información de ejemplo contenida en el mensaje RADIUS de la figura 11:

Tabla 7

WType-ID: ? para vHA-IP-MIP4

Descripción: La dirección IPv4 de V-CSN HA para MIP4.

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

Valor: Cadena de octetos que contiene una dirección IPv4 (en primer lugar, el bit más significativo)

La figura 12 muestra un ejemplo de definición TLV RADIUS, que establece que las capacidades de servicio

10 IP de la ASN 120 y/o la V-CSN 140 incluyen vHA-IP-MIP6, de acuerdo con una realización de la invención. Por supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 8 se resume la información de ejemplo contenida en el mensaje RADIUS de la figura 12:

Tabla 8

WType-ID: ? para vHA-IP-MIP6

Descripción: La dirección IPv6 de V-CSN HA para MIP6.

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

Valor: Cadena de octetos que contiene una dirección IPv6 (en primer lugar, el bit más significativo)

La figura 13 muestra un ejemplo de definición TLV RADIUS, que establece la dirección de un servidor

vDHCPv4, de acuerdo con una realización de la invención. Por supuesto, en un mensaje RADIUS pueden incluirse

otras informaciones. En la tabla 9 se resume la información de ejemplo contenida en el mensaje RADIUS de la figura

13:

Tabla 9

WType-ID: ? para el servidor vDHCPv4

Descripción: La dirección IPv4 del servidor DHCP de V-CSN a utilizar para la asignación de la dirección IPv4.

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La figura 14 muestra un ejemplo de definición TLV RADIUS, que establece la dirección IPv6 de un servidor DHCPv6, de acuerdo con una realización de la invención. Por supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 10 se resume la información de ejemplo contenida en el mensaje RADIUS de la figura 14:

WType-ID: ? para servidor vDHCPv6

Descripción: La dirección IPv6 del servidor DHCP de V-CSN a utilizar para la asignación de la dirección IPv6.

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

La figura 15 muestra un ejemplo de definición TLV RADIUS, que establece la dirección IPv4 de la LMA de V-CSN para su utilización para la asignación de la dirección IPv4, de acuerdo con una realización de la invención. Por supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 11 se resume la información de ejemplo contenida en el mensaje RADIUS de la figura 15:

Tabla 11

WType-ID: ? para vLMA con transporte IPv4

Descripción: La dirección IPv4 de la LMA de V-CSN utilizada para la asignación de la dirección IPv4.

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La figura 16 muestra un ejemplo de definición TLV RADIUS, que establece la dirección IPv4 de la LMA de H-CSN para su utilización para la asignación de la dirección IPv4, de acuerdo con una realización de la invención. 10 Por supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 12 se resume la información

de ejemplo contenida en el mensaje RADIUS de la figura 16:

Tabla 12

WType-ID: ? para hLMA con transporte IPv4

Descripción: La dirección IPv4 de la LMA de H-CSN utilizada para la asignación de la dirección IPv4.

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La figura 17 muestra un ejemplo de definición TLV RADIUS, que establece la dirección IPv6 de la LMA de

15 V-CSN para su utilización para la asignación de la dirección IPv6, de acuerdo con una realización de la invención. Por supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 13 se resume la información de ejemplo contenida en el mensaje RADIUS de la figura 17:

WType-ID: ? para vLMA con transporte IPv6

Descripción: La dirección IPv4 de la LMA de V-CSN utilizada para la asignación de la dirección IPv6.

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

La figura 18 muestra un ejemplo de definición TLV RADIUS, que establece la dirección IPv6 de la hLMA de H-CSN para su utilización para la asignación de la dirección IPv6, de acuerdo con una realización de la invención. Por supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 14 se resume la información de ejemplo contenida en el mensaje RADIUS de la figura 18:

Tabla 14

WType-ID: ? para hLMA con transporte IPv6

Descripción: La dirección IPv4 de la LMA de H-CSN utilizada para la asignación de la dirección IPv6.

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

La figura 19 muestra un ejemplo de definición TLV RADIUS, que establece la dirección IPv4 de la CR de VCSN para su utilización para la asignación de la dirección IPv4, de acuerdo con una realización de la invención. Por 10 supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 15 se resume la información de

ejemplo contenida en el mensaje RADIUS de la figura 19:

Tabla 11

WType-ID: ? para vCR con transporte IPv4

Descripción: La dirección IPv4 de la CR de V-CSN utilizada para la asignación de la dirección IPv4.

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La figura 20 muestra un ejemplo de definición TLV RADIUS, que establece la dirección IPv4 de la CR de H

15 CSN para su utilización para la asignación de la dirección IPv4, de acuerdo con una realización de la invención. Por supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 16 se resume la información de ejemplo contenida en el mensaje RADIUS de la figura 20:

WType-ID: ? para hCR con transporte IPv4

Descripción: La dirección IPv4 de la CR de H-CSN utilizada para la asignación de la dirección IPv4.

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La figura 21 muestra un ejemplo de definición TLV RADIUS, que establece la dirección IPv6 de la CR de VCSN para su utilización para la asignación de la dirección IPv4, de acuerdo con una realización de la invención. Por supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 17 se resume la información de ejemplo contenida en el mensaje RADIUS de la figura 21:

Tabla 17

WType-ID: ? para vCR con transporte IPv6

Descripción: La dirección IPv4 de la CR de V-CSN utilizada para la asignación de la dirección IPv6.

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

La figura 22 muestra un ejemplo de definición TLV RADIUS, que establece la dirección IPv6 de la CR de HCSN para su utilización para la asignación de la dirección IPv6, de acuerdo con una realización de la invención. Por 10 supuesto, en un mensaje RADIUS pueden incluirse otras informaciones. En la tabla 18 se resume la información de

ejemplo contenida en el mensaje RADIUS de la figura 22:

Tabla 18

WType-ID: ? para hCR con transporte IPv6

Descripción: La dirección IPv4 de la CR de H-CSN utilizada para la asignación de la dirección IPv6.

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

Adicionalmente, la tabla 19 resume un ejemplo de información correspondiente a una TLV que indica los 15 servicios IP autorizados, mientras que la tabla 20 resume un ejemplo de información de una TLV, indicando los Servicios Ethernet Autorizados.

TLV-ID: ? para servicios IP autorizados

Descripción: Esta TLV está incluida en un mensaje RADIUS de aceptación de acceso dirigido al NAS e indica las capacidades de servicio IP relacionadas que la ASN está autorizada a soportar.

Longitud: 2 + 4 octetos

Valor: Máscara binaria de 4 octetos con los siguientes valores: 0x00000001 = CMIP4 0x00000002 = PMIP4 0x00000004 = Ipv4 simple 0x00000008 = CMIP6 0x00000010 = PMIP6 0x00000020 = Ipv6 simple Los bits restantes se encuentran reservados

Tabla 20

TLV-ID: ? para servicios Ethernet autorizados

Descripción: Esta TLV se utiliza para indicar las capacidades de servicio Ethernet relacionadas que la ASN está autorizada a soportar.

Longitud: 2 + 4 octetos

Valor: Máscara binaria de 4 octetos con los siguientes valores: 0x00000001 = Servicio Ethernet simple 0x00000002 = Servicio Ethernet MIP 0x00000004 = Ipv4 simple Los bits restantes se encuentran reservados

Las tablas 21 y 22 muestran ejemplos de Tipo-Longitud-Valor (TLV) de la capacidad Ethernet e IP de la ASN 120/V-CSN 140 para una definición del servicio Ethernet /IP autorizado de acuerdo con otra realización de la 5 presente invención. Obsérvese que los parámetros indicados tienen un carácter meramente ejemplar; los parámetros reales se pueden definir de múltiples formas en función del alcance de la presente invención. Por ejemplo, en algunas realizaciones, la capacidad ASN y V-CSN puede estar integrada en una sola TLV, utilizando diferentes bits para identificar la capacidad Ethernet, la capacidad IP y/u otras capacidades de servicio. En algunas realizaciones, el Servicio Ethernet autorizado y el TLV de servicio autorizado pueden integrarse en un solo TLV, con

10 diferentes bits que identifican diferentes informaciones de servicio.

Tabla 21

WType-ID: 1 para el Atributo de capacidad WiMAX

Descripción: En una solicitud de acceso, el atributo identifica las capacidades WiMAX soportadas por la ASN o el HA. En una Aceptación de acceso, el atributo identifica las opciones seleccionadas por el servidor RADIUS.

Longitud: 6 + 3 + TLVs

Continuación: C-bit = 0

Valor: Uno o más de lo siguientes valores sub-TLV (véase más adelante)

ID TLV: Nombre TLV Bits de longitud AR AA AC R

1: Versión WiMAX 6 1 0 0 0

2: Capacidad de contabilización 3 1 1 0 0

3: Capacidad de línea directa 3 0-1[a] 0 0 0

4: Capacidad de notificación en modo inactivo 3 0-1[b] 0-1[c] 0 0

5: Capacidad de servicio de la ASN 6 1[d], [f] 0 0 0

6: Capacidad de servicio de la VCSN 6 0-1[e], [f] 0 0 0

7: Servicios autorizados 6 0 1[f] 0 0

8: Ubicaciones de anclaje autorizadas 3 0 1[f] 0 0

Obsérvese que en la tabla 22 se han facilitado unas notaciones adicionales [a]-[f]. La notación [a] indica que la ausencia de esta sub-TLV en una solicitud de acceso (AR) significa que el NAS o el HA no soportan la capacidad 5 de línea directa. La notación [b] indica que la ausencia de esta sub-TLV en una solicitud de acceso (AR) significa que el NAS no soporta la notificación en modo inactivo. Esta sub-TLV no aparece en una solicitud de acceso con origen en un HA. El H-AAA ignorará en silencio esta sub-TLV en los mensajes procedentes de un HA. La notación

[c] indica que la ausencia de esta sub-TLV en una aceptación de acceso (AA) significa que el H-AAA no requiere la notificación en modo de inactividad. El HAAA no enviará esta sub-TLV a un HA. Un HA ignorará en silencio esta sub

10 TLV. La notación [d] indica que esta sub-TLV ha sido incluida por la ASN para indicar sus capacidades de servicio soportadas, comprendiendo el servicio IP, el servicio Ethernet, etc. La notación [e] indica que esta sub-TLV debería estar presente cuando la estación móvil se acopla a la red visitada, y es incluida por la V-CSN para indicar sus capacidades de servicio soportadas, es decir, IP, Ethernet, etc. La notación [f] indica que esta TLV no se incluirá en ninguna versión de WiMAX anterior a la versión 1.5.

15 En la tabla 23 se resume el ejemplo de información del mensaje RADIUS que puede utilizarse para indicar la capacidad de servicio de la ASN (por ejemplo, Ethernet, IP u otro servicio) de acuerdo con una realización de la presente invención. Obsérvese que en la figura 10 ya se ha mostrado un ejemplo de definición de TLV RADIUS que se puede utilizar para indicar las capacidades de servicio de la ASN.

Tabla 23

WType-ID: ? Capacidad de servicio ASN

Descripción: Este atributo puede incluirse en un mensaje RADIUS de petición de acceso al servidor RADIUS e indica capacidades de servicio relacionadas con la red ASN, es decir, IP, Ethernet o futuros servicios aplicables.

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

Valor: Máscara binaria de 4 octetos con los siguientes valores: 0x00000001 = Transmisión DHCP 0x00000002 = Proxy DHCP 0x00000004 = FA 0x00000008 = Cliente PMIP 0x00000010 = MAG con transporte Ipv4 0x00000020 = MAG con transporte Ipv6 0x00000040 = AR con transporte Ipv4 0x00000080 = AR con transporte Ipv6 0x00000100 = eAFF con transporte IPv4 0x00000200 = eAFF con transporte IPv6 0x00000400 = eFA Los bits restantes se encuentran reservados

La tabla 24 resume el ejemplo de información de un mensaje RADIUS que puede utilizarse para indicar la capacidad de servicio de la V-CSN (por ejemplo, Ethernet, IP u otro servicio) de acuerdo con una realización de la presente invención. Obsérvese que en la figura 10 ya se ha mostrado un ejemplo de definición de TLV RADIUS que se puede utilizar para indicar las capacidades de servicio de la V-CSN:

Tabla 24

WType-ID: ? Capacidad de servicio Ethernet de la V-CSN

Descripción: Este atributo puede incluirse en un mensaje RADIUS de petición de acceso al servidor RADIUS e indica capacidades de servicio relacionadas con la red V-CSN, es decir, IP, Ethernet, etc.

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

Valor: Máscara binaria de 4 octetos con los siguientes valores: 0x00000001 = Servidor DHCPv4 0x00000002 = Servidor DHCPv6 0x00000004 = HAv4 0x00000008 = HAv6 0x00000010 = LMA con transporte Ipv4 0x00000020 = LMA con transporte Ipv6 0x00000040 = CR con transporte Ipv4 0x00000080 = CR con transporte Ipv6 0x00000100 = eCFF con Transporte IPv4 0x00000200 = eCFF con Transporte IPv6 0x00000400 = eHAv4 0x00000800 = eHAv6 Los bits restantes se encuentran reservados

La tabla 25 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la

dirección IPv4 de un V-CSN HA para MIP4 de acuerdo con una realización de la presente invención. Obsérvese que

en la figura 11 ya se ha mostrado un ejemplo de definición de TLV RADIUS que puede utilizarse para indicar el vHA

10 IP-MIP4:

WType-ID: ? para vHA-IP-MIP4

Descripción: La dirección IPv4 de V-CSN HA para MIP4.

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La tabla 26 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la dirección IPv6 de un HA para MIP6 de acuerdo con una realización de la presente invención. Obsérvese que en la figura 12 ya se ha mostrado un ejemplo de definición de TLV RADIUS que puede utilizarse para indicar el vHA-IPMIP6:

Tabla 26

WType-ID: ? para vHA-IP-MIP6

Descripción: La dirección IPv6 de HA utilizada para para MIP6.

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

La tabla 27 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la

10 dirección IPv4 de un servidor V-CSN DHCP para la asignación de la dirección IPv4 de acuerdo con una realización de la presente invención. Obsérvese que ya se ha mostrado en la figura 13 un ejemplo de definición de TLV RADIUS que puede utilizarse para indicar el Servidor vDHCPv4:

Tabla 27

WType-ID: ? para el servidor vDHCPv4

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La tabla 28 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la dirección IPv6 de un servidor DHCP para la asignación de la dirección IPv6 de acuerdo con una realización de la presente invención. Obsérvese que ya se ha mostrado en la figura 14 un ejemplo de definición de TLV RADIUS que puede utilizarse para indicar el Servidor vDHCPv6:

WType-ID: ? para servidor vDHCPv6

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

La tabla 29 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la dirección IPv4 del V-CSN LMA para la asignación de la dirección IPv4 de acuerdo con una realización de la presente invención. Obsérvese que ya se ha mostrado en la figura 15 un ejemplo de definición de TLV RADIUS que puede utilizarse para indicar vLMA con Transporte IPv4:

Tabla 29

WType-ID: ? para vLMA con transporte IPv4

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La tabla 30 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la dirección IPv4 del H-CSN LMA para la asignación de la dirección IPv4 de acuerdo con una realización de la presente 10 invención. Obsérvese que ya se ha mostrado en la figura 16 un ejemplo de definición de TLV RADIUS que puede

utilizarse para indicar hLMA con transporte IPv4:

Tabla 30

WType-ID: ? para hLMA con transporte IPv4

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La tabla 31 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la

15 dirección IPv4 del V-CSN LMA para la asignación de la dirección IPv6 de acuerdo con una realización de la presente invención. Obsérvese que ya se ha mostrado en la figura 17 un ejemplo de definición de TLV RADIUS que puede utilizarse para indicar vLMA con transporte IPv6:

WType-ID: ? para vLMA con transporte IPv6

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

La tabla 32 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la dirección IPv4 del H-CSN LMA para la asignación de la dirección IPv6 de acuerdo con una realización de la presente invención. Obsérvese que ya se ha mostrado en la figura 18 un ejemplo de definición de TLV RADIUS que puede utilizarse para indicar hLMA con transporte IPv6:

Tabla 32

WType-ID: ? para hLMA con transporte IPv6

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

La tabla 33 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la dirección IPv4 del V-CSN CR para la asignación de la dirección IPv4 de acuerdo con una realización de la presente 10 invención. Obsérvese que ya se ha mostrado en la figura 19 un ejemplo de definición de TLV RADIUS que puede

utilizarse para indicar vCR con transporte IPv4:

Tabla 33

WType-ID: ? para vCR con transporte IPv4

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La tabla 34 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la

15 dirección IPv4 del H-CSN CR para la asignación de la dirección IPv4 de acuerdo con una realización de la presente invención. Obsérvese que ya se ha mostrado en la figura 20 un ejemplo de definición de TLV RADIUS que puede utilizarse para indicar hCR con transporte IPv4:

WType-ID: ? para hCR con transporte IPv4

Longitud: 6 + 3 + 4

Continuación: C-bit = 0

La tabla 35 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la dirección IPv4 del V-CSN CR para la asignación de la dirección IPv6 de acuerdo con una realización de la presente invención. Obsérvese que ya se ha mostrado en la figura 21 un ejemplo de definición de TLV RADIUS que puede utilizarse para indicar vCR con transporte IPv6:

Tabla 35

WType-ID: ? para vCR con transporte IPv6

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

La tabla 36 resume el ejemplo de información de un mensaje RADIUS que se puede utilizar para indicar la dirección IPv4 del H-CSN CR para la asignación de la dirección IPv6 de acuerdo con una realización de la presente 10 invención. Obsérvese que ya se ha mostrado en la figura 22 un ejemplo de definición de TLV RADIUS que puede

utilizarse para indicar hCR con transporte IPv6:

Tabla 36

WType-ID: ? para hCR con transporte IPv6

Longitud: 6 + 3 + 16

Continuación: C-bit = 0

Adicionalmente, la tabla 37 resume un ejemplo de información correspondiente a una TLV que indica los 15 servicios autorizados.

TLV-ID: ? para servicios autorizados

Descripción: Esta TLV está incluida en un mensaje RADIUS de aceptación de acceso dirigido al NAS e indica las capacidades de servicio relacionadas (es decir, IP, Ethernet, etc.) que la ASN está autorizada a soportar.

Longitud: 2 + 4 octetos

Valor: Máscara binaria de 4 octetos con los siguientes valores: 0x00000001 = CMIP4 0x00000002 = PMIP4 0x00000004 = Ipv4 simple 0x00000008 = CMIP6 0x00000010 = PMIP6 0x00000020 = Ipv6 simple 0x00000040 = Servicio Ethernet simple 0x00000080 = Servicio Ethernet MIP Los bits restantes se encuentran reservados

De este modo, los métodos y sistemas descritos en este documento permiten negociar y autorizar la capacidad de servicio Ethernet y/o IP entre diferentes entidades de red. Además, las realizaciones de la presente 5 invención son capaces de aprovechar el proceso de autenticación y autorización de acceso a red para negociar el

servicio Ethernet y/o IP apropiado entre diversas entidades de red, utilizando protocolos de autenticación remota.

Aunque la presente invención se ha descrito en su totalidad en relación con realizaciones de la misma,

haciendo referencia a las figuras adjuntas, debe señalarse que las personas versadas en la materia observarán

diversos cambios y modificaciones. Debe entenderse que dichos cambios y modificaciones se encuentran incluidos

10 en el alcance de la presente invención, según lo definido en las reivindicaciones adjuntas.

Los términos y frases utilizados en el presente documento, así como sus variaciones, a menos que se indique en otro sentido, deberán interpretarse de forma amplia y no limitativa. Como ejemplos de cuanto antecede, el término “comprendiendo” debería entenderse como “comprendiendo, sin limitación”, o similares; el término “ejemplo” se utiliza para facilitar ejemplos del elemento que se está discutiendo, y no una relación exhaustiva o limitativa; y los

15 adjetivos como “convencional, “tradicional”, “normal”, “estándar” “conocido” y otros términos con similar significado no deberían interpretarse de forma que limiten el elemento descrito a un período de tiempo limitado o a un elemento disponible en un momento dado, sino que deberían entenderse de forma incluyan tecnologías convencionales, tradicionales, normales o estándar que pudieran estar disponibles o que se conociesen en la actualidad o en cualquier momento del futuro. Igualmente, un grupo de elementos vinculados a la conjunción “y” no debería leerse

20 de forma que exija que todos y cada uno de dichos elementos se encuentren presentes en el grupo, sino que debería interpretarse como “y/o”, a menos que se indique en otro sentido. Igualmente, un grupo de elementos vinculados a la conjunción “o” no debería interpretarse de forma que exija una exclusividad mutua en dicho grupo, sino que debería interpretarse como “y/o”, a menos que se indique en otro sentido. Asimismo, aunque los elementos componentes de la invención pueden describirse o reivindicarse en singular, contemplándose el plural dentro del

25 ámbito de la misma, a menos que se indique explícitamente la limitación al singular. La presencia de palabras y frases clarificadoras, como “uno o más”, “al menos”, “pero sin limitarse a” u otras frases similares en ciertos casos no se interpretará como que se exige o se precisa la interpretación más estrecha en los casos en los que no se den dichas frases.

Claims

REIVINDICACIONES

1. Método para negociar y autorizar la capacidad de servicio Ethernet respecto de uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, que comprende:

transmitir una primera señal desde un primer dispositivo de red a un segundo dispositivo de red, estando la primera señal adaptada para indicar los datos de capacidad de servicio Ethernet asociados al primer dispositivo de red;

recibir en el primer dispositivo de red una segunda señal procedente del segundo dispositivo de red, estando la segunda señal adaptada para indicar un conjunto de servicios Ethernet autorizados a una estación móvil adaptada para comunicarse con el primer dispositivo de red; y

almacenar los datos en el primer dispositivo de red, estando los datos adaptados para indicar el conjunto de servicios Ethernet autorizados a la estación móvil.
2.

Método según la reivindicación 1, en el que el sistema de comunicación inalámbrico comprende un sistema de comunicación WiMAX.
3.

Método según la reivindicación 1, en el que la primera señal está adicionalmente adaptada para indicar los datos de capacidad de servicio IP asociados al primer dispositivo de red, en el que la segunda señal está además adaptada para indicar un conjunto de servicios IP autorizados a la estación móvil, y en el que los datos están además adaptados para indicar el conjunto de servicios IP autorizados a la estación móvil
4.

Método según la reivindicación 1, en el que la primera señal comprende un mensaje de petición de autenticación AAA.
5.

Método según la reivindicación 1, en el que el primer dispositivo de red comprende una entidad de red de servicio de acceso.
6.

Método según la reivindicación 5, en el que la primera señal comprende al menos un atributo RADIUS adaptado para indicar la capacidad de servicio de Internet de la entidad de red de servicio de acceso.
7.

Método según la reivindicación 1, en el que el segundo dispositivo de red comprende una entidad de red de servicios de conectividad visitada.
8.

Método según la reivindicación 1, en el que el segundo dispositivo de red comprende una entidad de red de servicio de conectividad de origen.
9.

Método según la reivindicación 1, en el que la segunda señal comprende un mensaje de respuesta de autenticación AAA.
10. Método según la reivindicación 1, que adicionalmente comprende:

recibir una tercera señal en el primer dispositivo de red, transmitiéndose dicha tercera señal desde la estación móvil que está adaptada para indicar un servicio Ethernet solicitado; y

determinar en el primer dispositivo de red si el conjunto de servicios Ethernet autorizados incluye el servicio Ethernet solicitado.
11. Método para negociar y autorizar la capacidad de servicio Ethernet respecto de uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, que comprende:

recibir en un segundo dispositivo de red una primera señal procedente de un primer dispositivo de red, estando la primera señal adaptada para indicar los datos de capacidad de servicio Ethernet asociados al primer dispositivo de red;

determinar un conjunto de servicios Ethernet autorizados a una estación móvil adaptada para comunicarse con el primer dispositivo de red, a partir, al menos en parte de los datos de capacidad de servicio Ethernet; y

transmitir una segunda señal desde el segundo dispositivo de red al primer dispositivo de red, estando la segunda señal adaptada para indicar el conjunto de servicios Ethernet autorizados a la estación móvil.
12.

Método según la reivindicación 11, en el que el sistema de comunicación inalámbrico comprende un sistema de comunicación WiMAX.
13.

Método según la reivindicación 11, en el que la primera señal está adaptada para indicar los datos de capacidad de servicio IP asociados al primer dispositivo de red, en el que dicha determinación de un conjunto de servicios Ethernet autorizados a una estación móvil incluye también determinar un conjunto de servicios IP
14.

Método según la reivindicación 11, en el que la primera señal comprende un mensaje de petición de autenticación AAA.
15.

Método según la reivindicación 1, en el que el primer dispositivo de red comprende una entidad de acceso a la red de servicio.
16.

Método según la reivindicación 15, en el que el primer dispositivo de red comprende una entidad de red de servicio de conectividad visitada.
17.

Método según la reivindicación 11, en el que dicha determinación de un conjunto de servicios Ethernet autorizados a una estación móvil se basa, al menos parcialmente, en un perfil de abonado asociado a la estación móvil.
18.

Método según la reivindicación 11, en el que dicha determinación de un conjunto de servicios Ethernet autorizados a una estación móvil se basa al menos parcialmente en una política de red de origen.
19.

Método según la reivindicación 11, en el que el segundo dispositivo de red comprende una entidad de red de servicios de conectividad de origen.
20.

Método según la reivindicación 1, en el que la segunda señal comprende un mensaje de respuesta de autenticación AAA.
21.

Método para negociar y autorizar la capacidad de servicio Ethernet respecto de uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, que comprende:

recibir en un dispositivo de red intermedio un conjunto de datos de capacidad, estando adaptado el conjunto de datos de capacidad para indicar los datos de capacidad Ethernet asociados a un primer dispositivo de red;

añadir los datos de capacidad Ethernet asociados al dispositivo de red intermedio al conjunto de datos de capacidad;

transmitir el conjunto de datos de capacidad a un segundo dispositivo de red, estando adaptado el segundo dispositivo de red para generar un conjunto de datos de autorización para indicar un conjunto de servicios Ethernet autorizados a una estación móvil que se comunica con el primer dispositivo de red, en el que el conjunto de datos de autorización se basa, al menos parcialmente, en el conjunto de datos de capacidad;

recibir el conjunto de datos de autorización en el dispositivo intermedio de red; y

transmitir el conjunto de datos de autorización al primer dispositivo de red, estando el primer dispositivo de red adaptado para prestar servicios Ethernet a la estación móvil, a partir, al menos en parte, del conjunto de datos de autorización.
22.

Método según la reivindicación 21, en el que el sistema de comunicación inalámbrico comprende un sistema de comunicación WiMAX.
23.

Método según la reivindicación 21, en el que el conjunto de datos de capacidad recibidos en el dispositivo de red intermedio, está adaptado para indicar los datos de capacidad de servicio IP asociados al primer dispositivo de red, en el que dichos datos de capacidad Ethernet añadidos asociados al dispositivo de red intermedio, comprenden adicionalmente el añadir los datos de capacidad IP asociados al dispositivo de red intermedio, en el que los datos de autorización se encuentran además adaptados para indicar un conjunto de servicios IP autorizados a la estación móvil, y en el que el primer dispositivo de red está además adaptado para proporcionar servicios Ethernet a la estación móvil, a partir, al menos en parte, del conjunto de datos de autorización.
24.

Método según la reivindicación 21, en el que el primer dispositivo de red comprende una entidad de red de servicios de conectividad de acceso.
25.

Método según la reivindicación 21, en el que el dispositivo intermedio de red comprende una entidad de red de servicios de conectividad visitada.
26.

Método según la reivindicación 21, en el que el segundo dispositivo de red comprende una entidad de red de servicios de conectividad de origen.
27.

Sistema para negociar y autorizar la capacidad de servicio Ethernet respecto de uno o más servicios Ethernet entre una pluralidad de entidades de red en un sistema de comunicación inalámbrico, que comprende:

medios para recibir en el primer dispositivo de red una segunda señal procedente del segundo dispositivo de red, estando la segunda señal adaptada para indicar un conjunto de servicios Ethernet autorizados a una estación móvil adaptada para comunicar con el primer dispositivo de red; y

medios para almacenar los datos en el primer dispositivo de red, en el que los datos se encuentran adaptados para indicar el conjunto de servicios Ethernet autorizados a la estación móvil.
28.

Sistema según la reivindicación 27, en el que el sistema de comunicación inalámbrico comprende un sistema de comunicación WiMAX.
29.

Sistema según la reivindicación 27, en el que la primera señal está además adaptada para indicar datos de capacidad de servicio IP asociados al primer dispositivo de red, en el que la segunda señal además está adaptada para indicar un conjunto de servicios IP autorizados a la estación móvil, y en el que los datos están además adaptados para indicar el conjunto de servicios IP autorizados a la estación móvil.
30.

Sistema según la reivindicación 27, en el que la primera señal comprende un mensaje de petición de autenticación AAA.
31.

Sistema según la reivindicación 27, en el que el primer dispositivo de red comprende una entidad de red de servicio de acceso.
32.

Sistema según la reivindicación 31, en el que la primera señal comprende al menos un atributo RADIUS adaptado para indicar la capacidad de servicio ethernet de la entidad de red de servicio de acceso.
33.

Sistema según la reivindicación 27, en el que el segundo dispositivo de red comprende una entidad de red de servicios de conectividad visitada.
34.

Sistema según la reivindicación 27, en el que el segundo dispositivo de red comprende una entidad de red de servicios de conectividad de origen.
35.

Sistema según la reivindicación 27, en el que la segunda señal comprende un mensaje de respuesta de autenticación AAA.