MX2008015859A - Mejoramientos de operacion de protocolo de transferencia independiente de medios eficiente. - Google Patents

Abstract

La presente invención modifica el formato de trama de la MIHF (función de MIH (transferencia independiente de medios)) como se define por el estándar IEEE 802.21. En una modalidad, la carga variable de la trama de la MIHF se modifica para eliminar el encabezado variable de la MIHF mediante la definición del campo de identificación (ID) de la MIHF y el campo de ID de la sesión como campos fijos en el encabezado fijo de la MIHF. De este modo, la carga variable de la MIHF solamente está constituida por la carga útil de la MIHF. En otra modalidad, un campo tal como un elemento de información (lE), un encabezado, o dato de servicio de MIH tal como una orden o un evento, está representado por un campo de tipo, un campo de longitud y un campo de valor (TLV). La longitud del campo de valor es exactamente de 128 octetos, y el campo de longitud solamente ocupa un octeto.

Description

MEJORAMIENTOS DE OPERACIÓN DE PROTOCOLO DE TRANSFERENCIA INDEPENDIENTE DE MEDIOS EFICIENTE CAMPO DE LA INVENCIÓN La presente invención se refiere a comunicaciones inalámbricas. Más particularmente, la presente invención se refiere a un formato de trama de función de transferencia independiente de medios (MIHF) utilizado para transmitir y recibir inalámbricamente mensajes de transferencia independiente de medios (MIH) .

ANTECEDENTES La Figura 1 muestra la representación de valor de longitud tipo (TLV) actual de un IE 100 que incluye un campo de tipo 105, un campo de longitud 110 y un campo de valor 115, como se especifica por el estándar IEEE 802.21. Alternativamente, los campos de TLV pueden representar otros campos tales como un encabezado, o datos de servicio de MIH tal como una orden o un evento. El campo de tipo 105 indica el tipo del IE y tiene valores de identificación (ID) definidos en el estándar IEEE 802.21. El campo de valor 115 contiene la carga útil o el valor de IE 100. En un primer escenario, si el número de octetos ocupados por el campo de valor 115 es menor o igual a 127, el tamaño del campo de longitud 110 siempre es de un (1) octeto y el bit más significativo (MSB) 120 del octeto se establece al valor "0". En un segundo escenario, si el número de octetos ocupados por el campo de valor 115 es mayor a 127, entonces el tamaño del campo de longitud 110 es de al menos "x" octetos, en donde "x" es mayor o igual a dos (2) . En este caso, el MSB 125 del primer octeto del campo de longitud 110 se establece al valor "1" y los 7 bits remanentes del primer octeto indican el número de octetos adicionales que están anexos al primer octeto. El número representado por el segundo octeto del campo de longitud 110 indica el tamaño total del campo de valor 115. Existe un problema con la explicación del campo de longitud como se especifica en IEEE 802.21. Específicamente, en el segundo escenario de la interpretación del campo de longitud, el estándar IEEE 802.21 especifica que el número representado por el segundo octeto del campo de longitud indica el tamaño total del campo de valor. Esto es impreciso debido a que el número representado por el segundo octeto no indica la longitud del campo de valor. Más bien, el número representado por los octetos anexos adicionales, comenzando a partir del segundo octeto, indica la longitud del campo de valor.

Además, el valor de los octetos adicionales debe representar la longitud del campo de valor en octetos en oposición a bits. De este modo, el campo de longitud no se utiliza eficientemente. La Figura 2 muestra el formato actual de una trama de MIHF 200 especificada por el estándar IEEE 802.21. El estándar IEEE 802.21 especifica que la trama de MIHF 200 está compuesta de un encabezado fijo de MIHF 205 y una carga variable de MIHF 210. La carga variable de MIHF 210 está compuesta de un encabezado variable de MIHF 215 y una carga útil de MIHF 220. El estándar IEEE 802.21 especifica que el encabezado fijo de MIHF 205 es obligatorio. La Tabla 1 siguiente muestra los contenidos del encabezado fijo de MIHF 205 como se especifica en IEEE 802.21: Tabla 1 - Descripción de Encabezado Fijo de MIHF Nombre de Campo Tamaño Descripción (bits) Versión 4 Este campo se utiliza para especificar la versión del protocolo utilizado. La importancia de esto se observa en el manejo de la compatibilidad hacia abajo en el futuro. ACK- eq 1 Este campo se utiliza para solicitar una confirmación para el mensaje. ACK-Rsp 1 Este campo se utiliza para responder a la solicitud de una confirmación para el mensaje. Reservado 4 Este campo se mantiene reservado intencionalmente . En el caso sin utilizar, todos los bits de este campo se establecen en "0".

ID de mensaje de Combinación de los siguientes 3 campos (MID) Identificador Identifica los servicios diferentes Servicio (SID) MIH, los valores posibles son: 1 Manejo del Sistema Servicio de Evento Servicio de Orden Servicio de Información Código de Operación Tipo de operación que se va a realizar (Opcode) con respecto al SID, los valores posibles son: 1: Solicitud 2: Respuesta 3: Indicación Identificador de Esto indica la acción que se va a tomar Acción (AID) con respecto al SID. Número de Indica el número de identificadores de Identificadores de encabezado (TLV para cada uno) Encabezado incluidos en la parte de encabezado Adicionales variable de MIHF. ID de Transacción 16 Este campo se utiliza para comparación de Solicitud y Respuesta asi como comparación de Solicitud, Respuesta e Indicación para una ACK. Longitud de Carga 16 Indica la longitud total de la carga Variable variable incrustada en la trama de MIHF y es la suma de la longitud del encabezado variable de MIHF y la longitud de la carga útil de MIHF. NO está incluida la longitud del encabezado fijo de MIHF.

Como se especifica actualmente en el IEEE 802.21, el encabezado variable de MIHF 215 contiene identificadores adicionales que ayudan a analizar y coordinar la carga útil que está incrustada. Estos identificadores también se representan en formato de TLV. Algunos valores posibles para el campo de tipo (del TLV) de estos identificadores especificados en IEEE 802.21 incluyen ID de transacción (para comparar solicitudes y respuestas) , ID de Función de MIH / ID de Sesión (para identificar los pares de comunicación) , e información de sincronización (para identificar la marca cronológica del mensaje recibido) . El campo de carga útil de MIHF 220 contiene TLV específicos de servicio que actúan como la carga útil de un mensaje. La comparación del encabezado fijo de MIHF 205 en la Figura 2 (formato de trama de MIHF) y la descripción de sus campos en la Tabla 1 (descripción de encabezado fijo de MIHF) , debe notar que el campo de "número de identificadores adicionales de encabezado" que se muestra en la Tabla 1 no existe en la trama de MIHF 200 de la Figura 2. El campo de longitud de carga variable 225 del encabezado fijo de MIHF 205 se representa por 16 bits. El campo de longitud de carga variable 225 (como se especifica en IEEE 802.21) indica que la longitud total de la carga variable incrustada en la trama de MIHF 200 es la suma de la longitud del encabezado variable de MIHF 215 y la longitud de la carga útil de MIHF 220. La longitud del encabezado fijo de MIHF 205 no está incluida. El campo de longitud de carga variable 225 no es necesario debido a que la longitud del encabezado variable de MIHF 210 se puede calcular y los 16 bits utilizados para su representación se deben economizar. El encabezado fijo de MIHF 205 define un campo de solicitud de confirmación (ACK-req) 230 para solicitar una confirmación, y un campo de respuesta de confirmación (ACK— rsp) 235 para la confirmación de la recepción de un mensaje. Como se especifica en IEEE 802.21, los mensajes de confirmación están anexos ("superpuestos") o se envían solos en un paquete de respuesta. No obstante, el estándar IEEE 802.21 no especifica cómo indicar que una trama de respuesta no tiene carga útil y sirve solamente como confirmación. De este modo, si un par recibe un mensaje con el bit de AC -rsp establecido en "1", éste tendría que verificar si existe o no carga útil. Esto es ineficiente debido a que si no existe carga útil, el campo de carga variable de MIHF 210 contendría bits ficticios que se podrían interpretar como bits válidos por el receptor. De este modo, es necesario tener un campo que identifique mensajes de confirmación pura y la trama de MIHF 200 no debería tener campo de carga variable de MIHF 210. Actualmente no existe tal campo definido. El estándar IEEE 802.21 define tres identificadores de protocolo de MIHF que incluyen un ID de MIHF, un ID de sesión y un ID de transacción 240. El ID de MIHF identifica el transmisor desde donde se originó la trama de MIHF 200. El ID de sesión es un identificador único generado por el originador de una sesión. El ID de transacción 240 se utiliza para comparar solicitudes y respuestas, así como para comparar solicitud, respuesta e indicación para una ACK (ver Tabla 1 anterior) . De este modo, todos los tres identificadores de protocolo de IHF (conjuntamente) únicamente identifican una trama (o mensaje) de MIHF. No obstante, solamente se muestra el ID de transacción 240 en el encabezado fijo de MIHF 205, mientras que el ID de MIHF, el ID de sesión, y el ID de transacción 240 se supone que van a estar representados en el formato de TLV y se especifican para residir en el encabezado variable de MIHF 215 (que es parte de la carga variable de MIHF 210) . El problema es que utilizar un TLV para representar a cada uno del ID de MIHF y el ID de sesión desperdiciará bits y complicará la descodificación de la trama de MIHF 200. Además, el ID de transacción 240 ya tiene permitido un campo fijo en el encabezado fijo de MIHF 205 y ahí no se necesita representarlo en formato TLV en el encabezado variable de MIHF 215.

BREVE DESCRIPCIÓN La presente invención incluye un grupo de modificaciones al formato de trama de MIHF existente en el estándar IEEE 802.21. La presente invención modifica el formato existente de trama de MIHF como se define por el estándar IEEE 802.21. En una modalidad, la carga variable de la trama de MIHF se modifica para eliminar el encabezado variable de MIHF mediante la definición del campo de ID de MIHF y el campo de ID de sesión como campos fijos en el encabezado fijo de MIHF. De este modo, la carga variable de MIHF solamente está constituida de la carga útil de MIHF. En otra modalidad, un campo tal como un IE, una orden o un encabezado está representado por un campo de tipo, un campo de longitud y un campo de valor (TLV) . La longitud del campo de valor es exactamente de 128 octetos, y el campo de longitud solamente ocupa un octeto.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Se puede tener una comprensión más detallada de la invención a partir de la siguiente descripción de una modalidad preferida, dada a manera de ejemplo y para comprenderse en conjunto con los dibujos anexos, en donde: La Figura 1 muestra la representación del formato de TLV actual de un IE como se especifica por el estándar IEEE 802.21; La Figura 2 muestra el formato de trama de MIHF del IEEE 802.21 actual; La Figura 3 muestra el formato de TLV actual especificado por IEEE 802.21; La Figura 4 muestra una trama de TLV con un campo de valor que tiene una longitud mayor a 128 octetos; La Figura 5 muestra una trama de TLV con un campo de valor que tiene una longitud de exactamente 128 octetos de acuerdo con la presente invención; La Figura 6 muestra un formato de trama de MIHF configurado de acuerdo con la presente invención; La Figura 7 muestra una trama de solicitud de MIHF ejemplar para solicitar un IE de acuerdo con la presente invención; La Figura 8 muestra una trama de respuesta de MIHF ejemplar que proporciona un IE en respuesta a la trama de solicitud de MIHF de acuerdo con la presente invención; La Figura 9 muestra una representación de TLV ejemplar para una IE de identificador de operador de acuerdo con la presente invención; La Figura 10 muestra una trama de MIHF con un mensaje de confirmación de acuerdo con la presente invención; y La Figura 11 muestra un sistema de comunicación configurado de acuerdo con la presente invención.

DESCRIPCIÓN DETALLADA DE LAS MODALIDADES PREFERIDAS Cuando se. indique de aquí en adelante, la terminología "unidad transmisora/receptora inalámbrica (WTRU)" incluye sin restricción un equipo de usuario (UE) , una estación móvil, una unidad de suscriptor fija o móvil, un localizador, un teléfono celular, un asistente digital personal (PDA), una computadora, o cualquier otro tipo de dispositivo de usuario con la capacidad de operar en un ambiente inalámbrico. Cuando de aquí en adelante se indique, la terminología "estación base" incluye sin restricción un Nodo B, un controlador de sitio, un punto de acceso (AP) , o cualquier otro tipo de dispositivo de interconexión que tenga la capacidad de operar en un ambiente inalámbrico. La Figura 3 muestra la Representación de formato de TLV actual de un IE como se define en IEEE 802.21, similar al formato del IE 100 mostrado en la Figura 1. La presente invención es aplicable a la interpretación del campo de longitud del TLV cuando la longitud del campo de valor es mayor a 127 octetos. Como se muestra con detalle por la Figura 4, si el número de octetos ocupados por el campo de valor es mayor a 128 octetos, entonces el MSB del primer octeto del campo de longitud se establece en "1". El resto de los siete bits indican el número de octetos (de nuevos campos de longitud) que están anexos adicionalmente al primer octeto (del campo de longitud) . La longitud del campo de valor es entonces de 128 más el número representado por los otros octetos del campo de longitud anexo comenzando desde el segundo octeto. La presente invención define un tercer caso que aplica cuando la longitud del campo de valor es exactamente de 128 octetos como se muestra en la Figura 5. Si la longitud del campo de valores exactamente de 128 octetos, entonces el MSB del campo de longitud se establece en "1" y los restantes siete bits se establecen en "0". De acuerdo con el estándar IEEE 802.21 actual, si la longitud es mayor a 127 octetos, como se muestra en la Figura 1, se deben agregar octetos "x" extra para indicar totalmente la longitud del campo de valor. Incluso si la longitud es exactamente de 128 octetos, el estándar IEEE 802.21 actual requiere un octeto extra para cumplir con el valor exacto de 128 octetos. De este modo, existe un desperdicio de un octeto extra. La presente invención no requiere octetos adicionales para indicar la longitud del campo de valor en octetos, cuando la longitud del campo de valor es exactamente de 128 octetos. La Figura 6 muestra un formato de trama de MIHF 600 configurado de acuerdo con la presente invención. El formato de trama de MIHF 600 incluye un encabezado fijo de MIHF 605 y una carga variable de MIHF 610. No obstante, el encabezado variable de MIHF (que es parte de la carga variable de MIHF de la trama de MIHF del IEEE 802.21 actual), se ha eliminado. Esto se debe a que el ID de MIHF y el ID de sesión que se representaron previamente en TLVs y que estuvieron contenidos en el encabezado variable de MIHF, ahora se definen como campos fijos en el encabezado fijo de MIHF 605 de acuerdo con la presente invención. De este modo, la carga variable de MIHF 610 solamente está constituida de la carga útil de MIHF. Los nombres de campo del encabezado fijo de MIHF 605 que se muestran en la Figura 6 son nuevos campos que están definidos o campos antiguos que han sido modificados de acuerdo con la presente invención. El campo Reservado 615 ha sido modificado. Este se representó inicialmente por 10 bits y ahora se debe representar por 9 bits. El otro bit se utiliza para definir un campo de "bandera" 620 de acuerdo con la presente invención. Existen dos escenarios de cómo se puede utilizar este campo. En un primer escenario, cuando existe carga útil en el campo de carga útil variable de MIHF (de la trama de MIHF), el campo de bandera 620 se establece en "1". En este escenario, la longitud total de la trama de MIHF debe ser: { [longitud de encabezado fijo de MIHF (siempre de 15 octetos)] + [longitud de carga variable de MIHF]} octetos = {15 + [longitud del campo de tipo (siempre de 4 octetos)] + [el número de octetos utilizados para representar el campo de longitud] + [la longitud del campo de valor como se indica por el campo de Longitud] octetos. Esto se puede utilizar para anexar ("superponer") una confirmación para un mensaje recibido previamente. De este modo, una indicación de que existe una confirmación de "superpuestos" en la trama que también contiene carga útil ocurre cuando la ACK rsp y los bits de bandera se establecen en "1". En un segundo escenario, cuando no existe carga útil en el campo de carga útil variable de MIHF (de la trama de MIHF) , entonces el campo de bandera 620 se establece en "0". En este caso, la longitud total de la trama de MIHF seria: [longitud del encabezado fijo de MIHF (siempre de 15 octetos) ] . Esto es particularmente útil si un par necesita enviar una trama de MIHF que contenga solamente un mensaje de confirmación. El estándar IEEE 802.21 actual no distingue mensajes de confirmación autónomos. Más bien, el estándar IEEE 802.21 actual siempre utiliza mensajes de confirmación anexos ("superpuestos") . De este modo, si un par envía una trama de MIHF que contenga un mensaje de confirmación solamente, la ACK-rsp se establece en "1" y el bit de bandera se establece en "0". En este escenario, la carga variable de MIHF no lleva datos y por lo tanto no existe. Por consiguiente, solamente la trama de MIHF incluye el encabezado fijo de MIHF, y el receptor no intenta verificar ninguna carga útil. El campo de ID de MIHF 625 juega el mismo papel como ya se especificó en el ID de MIHF del IEEE 802.21 del transmisor desde donde se originó la trama de MIHF. No obstante, este campo no está contenido en el encabezado fijo de MIHF actual en IEEE 802.21. La significancia de tener este campo en este encabezado es que siempre se necesitarán para identificación única de cada mensaje que se envía. De este modo, si se representan en formato TLV, ocuparán bits extras que se podrían utilizar para otros fines. Además, la representación de TLV introduciría más esfuerzo y sobrecarga mientras se descodifica un mensaje. El ID de sesión 630 tiene la misma función que la que se especificó en IEEE 802.21 - un identificador único generado por el que originó una sesión. No obstante, para definir únicamente un transmisor de un mensaje, se necesita el ID de Sesión. Similarmente, teniendo este ID en el encabezado fijo de MIHF economiza bits y mejora la descodificación de mensajes de manera contraria a representarlo en formato de TLV. El campo de longitud de carga variable se elimina del encabezado fijo de MIHF. El papel de este campo es indicar la longitud del campo de carga útil variable de MIHF y se constituyó de 16 bits. No obstante, incluso en ausencia de la longitud de carga variable, la longitud del campo de carga útil variable de MIHF todavía se puede calcular como sigue: {[longitud del campo del Tipo (siempre de 4 octetos) ] + [el número de octetos utilizados para representar el campo de Longitud] + [la longitud del campo de valor como se indica por el campo de Longitud]} octetos. De este modo, los 16 bits se pueden economizar sin perder ninguna información tal como la longitud de la carga útil variable de MIHF. El resto de los campos del encabezado fijo de MIHF se describe por la Tabla 1 anterior. La parte de carga variable de MIHF del formato de trama de MIHF contiene solamente TLVs específicos de servicio. Ésta ya no contiene el encabezado variable de MIHF. Lo siguiente es una implementación ejemplar de la trama de MIHF de la presente invención. Para recuperar IEs específicos, por ejemplo, el cliente envía una solicitud de información (es decir, consulta) a un punto de servicio de MIH (PoS) . La solicitud de información contiene una consulta para IEs. El PoS de MIH envía una respuesta de información que contiene la respuesta de la solicitud de información de regreso al cliente. La Figura 7 muestra una trama de solicitud de MIHF ejemplar 700 para solicitar un IE. Un IEEE 802.21 hace posible que la entidad solicite un IE específico tal como una lista de operadores (por ejemplo, utilizando IE DE TIPO DE LISTA DE OPERADORES SOLICITADO (TYPE_IE_LIST_OF_OPERATORS_REQUEST) ) . La trama de solicitud de MIHF 700 incluye un encabezado fijo de IHF 705 y una carga variable de MIHF 710. El "xxx" contenido por los campos del encabezado fijo de MIHF 705 de la trama de solicitud de MIHF 700 mostrado en la Figura 7 simplemente implica que los bits pueden tener cualquier valor sin afectar la implementación de la trama de solicitud 700. El campo de ID de mensaje de MIH 715 es una combinación de un campo de ID de servicio 720, un campo de código de operación (opcode) 725 y un campo de ID de acción 730. El campo de ID de servicio 720 identifica los diferentes servicios de MIH y tiene los siguientes valores: 1 = Manejo del Sistema; 2 = Servicio de Evento; 3 = Servicio de Orden; y 4 = Servicio de Información. Como se muestra en la Figura 7, el campo de ID de servicio 720 tiene un valor decimal de 4 que se representa en los bits binarios "0100". Este valor indica que la carga útil llevada en la carga variable de MIHF 710 está relacionada al servicio de información. El campo de código de operación (opcode) 725 indica un tipo de operación que se va a realizar con respecto al ID de servicio 720 y tiene los siguientes valores : 1 = Solicitud; 2 = Responder; y 3 = Indicación. Como se muestra, el campo de código de operación (opcode) 725 está representado por un valor de 1 para indicar que la carga útil es una solicitud para el ID de servicio en cuestión. El campo de ID de acción 730 indica la acción que se va a emprender con respecto al campo de ID de servicio 720. El campo de bandera 735 como se muestra se establece en "1" indicando que la carga variable de MIHF contiene datos. La carga variable de MIHF 710 de la parte de mensaje de solicitud de la trama de MIHF 700 contiene la representación del TLV para la solicitud de IE definida por un campo de tipo 740, . un campo de longitud 745 y un campo de valor 750. El campo de tipo 740 contiene el valor para el tipo de IE. En el ejemplo mostrado en la Figura 7, el campo de tipo 740 está representado en notación hexadecimal con un valor de "Ox 10000003" (4 octetos) como se especifica en IEEE 802.21. Esto significa que el tipo de IE en cuestión es la lista de operadores para un tipo de enlace especifico, el cual se especifica en el campo de valor del TLV ("xxx...'). El campo de longitud 745 tiene su MSB establecido en "0" lo que significa que la longitud del campo de valor es menor a 128 octetos. La longitud exacta del campo de valor está representada por el resto de los siete bits que tienen un valor decimal de 4. Por lo tanto, la longitud del campo de valor es de 4 octetos. El campo de valor 750 contiene el tipo de enlace especifico para el cual se requiere obtener la lista de operadores. El campo de valor 750 puede ser de longitud fija o variable, dependiendo del IE en cuestión. Para este ejemplo, se especifica en IEEE 802.21 que la longitud de este campo está fija en 4 octetos. Ésta se representa por "xxx...' porque puede representar cualquier valor definido. La Figura 8 muestra una trama de respuesta de MIHF ejemplar 800 que proporciona un IE en respuesta a la trama de solicitud de MIHF 700. Se asume que el receptor del mensaje de solicitud descodifica la trama de MIHF consiguientemente y responde (por ejemplo, utilizando TYPE_IE_LIST_OF_OPERATORS_RESPONSE) . La trama de respuesta de MIHF 800 incluye un encabezado fijo de MIHF 805 y una carga variable de MIHF 810. La trama de respuesta de MIHF 800 muestra la respuesta a la solicitud para la lista de operadores IE (para un tipo de enlace especifico) . El "xxx" contenido por los campos del encabezado fijo de MIHF 805 de la trama de respuesta de MIHF 800 mostrada en la Figura 8 simplemente implica que los bits pueden tener cualquier valor, sin afectar la implementación de la trama de respuesta 800. El campo de ID del mensaje de MIH 815 es una combinación de un campo de ID de servicio 820, un campo de código de operación (opcode) 825 y un campo de ID de acción 830. El campo ACK-req 835 tiene un bit que se establece en "1" indicando que el par debe confirmar la recepción de este mensaje (como se especifica en IEEE 802.21) . El campo de bandera 840 tiene un bit que se establece en "1" indicando que la carga variable de MIHF contiene datos. El bit de ID de servicio 820 tiene un valor decimal de 4 que se representa en bits. Este valor implica que la carga útil llevada en la trama de MIHF está relacionada al servicio de información. El campo de código de operación (opcode) 825 está representado por un valor decimal de 2 para indicar que la carga útil es una respuesta para el ID de servicio en cuestión . El campo de ID de acción 830 indica la acción que se va a emprender con respecto al campo de ID de servicio 820. La carga variable de MIHF 810 del campo de mensaje de respuesta tiene tres campos que se explican enseguida . El campo de tipo 845 contiene el valor para el tipo de IE. En este ejemplo, se representa en notación hexadecimal con un valor de Ox 10000003 (4 octetos) como se especifica en IEEE 802.21. Esto significa que el tipo de IE en cuestión es la lista de operadores para un tipo de enlace especifico (el cual se especificó en el campo de valor del TLV del mensaje de solicitud) . El campo de longitud 850 tiene su MSB establecido en "1" significando que la longitud del campo de valor es mayor a 128 octetos. El resto de los siete bits del primer octeto de este campo indica que dos octetos de campo de longitud se anexan además (16 bits). El valor decimal representado por estos 16 bits es de 403. Por lo tanto, la longitud total del campo de valor es de 128 + 403 = 531 octetos . El campo de valor 855 contiene la carga útil. De acuerdo a la especificación del IEEE 802.21, este campo está formado de dos partes: el número de operadores (para el tipo de enlace especifico) seguido por el o los identificadores de operador.

El número de campo de operadores 860 está representado por 4 octetos como se especifica en IEEE 802.21. Para fines de este ejemplo, el número de operadores para el tipo de enlace en cuestión se elige que sea de 2. Este valor se muestra como los primeros cuatro octetos en el campo de valor 915 de la carga variable de MIHF mostrada en la Figura 9. Los identificadores de operador se representan en formato de TLV. Cada uno se trata como un IE separado que primero está constituido y luego se agrega al campo de valor después del número de identificadores de operador. De este modo, están presentes dos TLVs de identificador de operador independiente 865 y 870. Los TLVs 865 y 870 son similares en estructura, pero pueden variar en contenido y longitud. Nótese que se asume esto debido a que el nombre del operador aún no está definido. Los dos TLVs 865 y 870 se anexan al número de operadores en el campo de valor 855 (que está en la carga variable de MIHF 810) . Cada TLV 865 y 870 tiene el mismo valor para el campo de tipo, pero el campo de longitud y el campo de valor pueden variar. De este modo, se puede sugerir que el campo de tipo de los TLVs 865 y 870 anexos se elimine. El campo de valor 855 de la trama de respuesta 800 de este modo contendría 4 octetos para el número de operadores, un campo de longitud para el primer TLV de identificador de operador 865 seguido por su campo de valor, y un campo de longitud para el segundo TLV de identificador de operador 870 seguido por su campo de valor. Nótese que esto no se puede realizar para todas las solicitudes o respuestas de IE porque algunas veces los TLVs que se van a anexar son diferentes y por lo tanto su campo de tipo se requiere. La Figura 9 muestra una representación de TLV ejemplar de un IE de identificador de operador 900. El campo de tipo 905 contiene el valor para el tipo de IE. En este ejemplo, se representa en notación hexadecimal con un valor de Ox 10000004 (4 octetos) como se especifica en IEEE 802.21. Esto significa que el tipo de IE en cuestión es el identificador del operador. El campo de longitud 910 tiene su MSB establecido en "1", indicando que la longitud del campo de valor 915 es mayor a 128 octetos. El resto de los siete bits del primer octeto del campo de longitud 910 indica que un octeto de campo de longitud está anexo además (8 bits) . El valor decimal representado por estos 8 bits es de 126. Por lo tanto, la longitud total del campo de valor 915 es de 128 + 126 = 254 octetos. El campo de valor 915 incluye un campo de espacio del nombre del operador 920 seguido por un campo de nombre de operador 925. El campo de espacio del nombre del operador 920 tiene una longitud de 1 octeto como se especifica en IEEE 802.21. El campo de nombre del operador 925 contiene el valor del nombre del operador en cuestión. El campo del nombre del operador 925 es una hilera que termina no en cero cuya longitud no excederá 253 octetos (como se especifica por el estándar IEEE 802.21). El campo 925 se muestra como que incluye "??.,.??", que se utiliza para representar cualquier valor, ya que los valores posibles no están definidos aún en el estándar IEEE 802.21. De este modo, el campo de nombre del operador 925 se asume que tiene la longitud máxima, es decir, 253 octetos, justo para los fines del ejemplo. Cuando un receptor recibe un mensaje de respuesta de MIHF, el receptor descodifica la trama consiguientemente y notifica que el bit de ACK-req se estableció en "1" por el par. De acuerdo con la presente invención, entonces el receptor envía una trama que incluye un mensaje de confirmación 1000, el cual solamente incluye un encabezado fijo de MIHF 1005, como se muestra en la Figura 10. En el encabezado fijo de MIHF 1005, un bit de ACK-rsp 1010 se establece en "1" indicando que esta trama contiene una confirmación para un mensaje previo. Además, un bit de bandera 1015 se establece en "0" indicando que no existe carga útil en la carga variable de MIHF (que está ausente) . De este modo, esta trama contiene un mensaje de confirmación solamente. El resto de los campos, y los valores que deben contener, se especifican por el estándar IEEE 802.21. De este modo, el receptor puede distinguir mensajes de confirmación pura al verificar el bit de bandera 1015. La Figura 11 muestra un sistema de comunicación inalámbrica 1100 que incluye un primer transceptor 1105 y un segundo transceptor 1110 configurados de acuerdo con la presente invención. El primer transceptor 1105 y el segundo transceptor 1110 pueden ser una unidad transmisora/receptora inalámbrica (WTRU) , una estación base y similar. Alternativamente, se puede implementar un sistema de comunicación cableado, por ejemplo, utilizando Ethernet como la conexión física. Como se muestra en la Figura 11, el primer transceptor 1105 incluye . una primera antena 1115 y el segundo transceptor 1110 incluye una segunda antena 1120. El primer transceptor 1105 envía una trama de solicitud de MIHF 1125 al segundo transceptor 1110 por medio de la primera antena 1115. La trama de solicitud de MIHF 1125 incluye un encabezado fijo de MIHF y una carga variable de MIHF. La carga variable de MIHF en la trama de solicitud de MIHF 1125 no incluye un encabezado variable de MIHF. El segundo transceptor 1110 envía una trama de respuesta de MIHF 1130 al primer transceptor 1105 por medio de la segunda antena 1120 en respuesta a la recepción de la trama de solicitud de MIHF 1125. La trama de respuesta de MIHF 1130 incluye un encabezado fijo de MIHF y una carga variable de MIHF. La carga variable de MIHF en la trama de respuesta de MIHF 1130 no incluye un encabezado variable de MIHF. El transceptor 1105 incluye además un transmisor 1135 para enviar tramas de solicitud de MIHF 1125 y tramas de respuesta de MIHF 1130, un receptor 1140 para recibir tramas de solicitud de MIHF 1125 y tramas de respuesta de MIHF 1130, y un procesador 1145 para generar tramas de solicitud de MIHF 1125 y tramas de respuesta de MIHF 1130. El transceptor 1110 incluye además un transmisor 1150 para enviar tramas de solicitud de MIHF 1125 y tramas de respuesta de MIHF 1130, un receptor 1155 para recibir tramas de solicitud de MIHF 1125 y tramas de respuesta de MIHF 1130, y un procesador 1160 para generar tramas de solicitud de MIHF 1125 y tramas de respuesta de MIHF 1130.

MODALIDADES 1. En un sistema de comunicación que incluye un primer transceptor y un segundo transceptor, un método de comunicación de mensajes de transferencia independiente de medios (MIH) que comprende el primer transceptor que envía una trama de solicitud de función de MIH (MIHF) al segundo transceptor, la trama de solicitud de MIHF incluye un encabezado fijo y una carga variable, en donde la carga variable no incluye un encabezado variable. 2. El método de la modalidad 1, que comprende además : el segundo transceptor que envía una trama de respuesta de MIHF al primer transceptor en respuesta a la recepción de la trama de solicitud de MIHF. 3. El método según cualquiera de las modalidades 1 y 2, en donde el encabezado fijo incluye un campo de identificación (ID) de MIHF. 4. El método según cualquiera de las modalidades 1-3 en donde el encabezado fijo incluye un campo de identificación (ID) de sesión. 5. El método según cualquiera de las modalidades 1-4 en donde el encabezado fijo incluye un campo de bandera. 6. El método de la modalidad 5, que comprende además : establecer el campo de bandera en uno para indicar que existe una confirmación superpuesta en la trama de solicitud de MIHF que contiene una carga útil. 7. El método de la modalidad 5, que comprende además : establecer el campo de bandera en cero para indicar que no existe carga útil en un campo de carga útil variable . 8. El método según cualquiera de las modalidades 1-7, en donde la carga variable incluye un campo de tipo, un campo de longitud y un campo de valor. 9. El método de la modalidad 8, en donde el campo de valor incluye un tipo de enlace especifico para obtener una lista de operadores. 10. El método según cualquiera de las modalidades 1-9, en donde el sistema de comunicación es un sistema de comunicación inalámbrica, el primer transceptor es una unidad transmisora/receptora inalámbrica (WTRU) y el segundo transceptor es una estación base. 11. El método según cualquiera de las modalidades 1-10, en donde el sistema de comunicación es un sistema de comunicación inalámbrica, el primer transceptor es una estación base y el segundo transceptor es una unidad transmisora/receptora inalámbrica (WTRU). 12. El método según cualquiera de las modalidades 1-10, en donde el sistema de comunicación es un sistema de comunicación cableada que utiliza Ethernet para proporcionar una conexión física. 13. En un sistema de comunicación que incluye un primer transceptor y un segundo transceptor, un método de comunicación de mensajes de transferencia independiente de medios (MIH) que comprende: el primer transceptor que envía una trama de solicitud de función de MIH (MIHF) al segundo transceptor; y el segundo transceptor que envía una trama de respuesta de MIHF al primer transceptor en respuesta a la recepción de la trama de solicitud de MIHF, la trama de respuesta de MIHF incluye un encabezado fijo y una carga variable, en donde la carga variable no incluye un encabezado variable. 14. El método de la modalidad 13, en donde el encabezado fijo incluye un campo de identificación (ID) de MIHF. 15. El método según cualquiera de las modalidades 13 y 14, en donde el encabezado fijo incluye un campo de identificación (ID) de sesión. 16. El método según cualquiera de las modalidades 13-15, en donde el encabezado fijo incluye un campo de bandera. 17. El método de la modalidad 16, que comprende además : establecer el campo de bandera en uno para indicar que la carga variable contiene datos. 18. El método de la modalidad 16, que comprende además : establecer el campo de bandera en cero para indicar que la carga variable no contiene datos. 19. El método según cualquiera de las modalidades 13-18, en donde la carga variable incluye un campo de tipo, un campo de longitud y un campo de valor. 20. El método de la modalidad 19, en donde el campo de valor incluye un tipo de enlace especifico para obtener una lista de operadores. 21. El método según cualquiera de las modalidades 13-20, en donde el sistema de comunicación es un sistema de comunicación inalámbrica, el primer transceptor es una unidad transmisora/receptora inalámbrica (WTRU) y el segundo transceptor es una estación base. 22. El método según cualquiera de las modalidades 13-20, en donde el sistema de comunicación es un sistema de comunicación inalámbrica, el primer transceptor es una estación base y el segundo transceptor es una unidad transmisora/receptora inalámbrica (WTRU) . 23. El método según cualquiera de las modalidades 13-20, en donde el sistema de comunicación es un sistema de comunicación cableada que utiliza Ethernet para proporcionar una conexión física. 24. En un sistema de comunicación que incluye un primer transceptor y un segundo transceptor, un método de comunicación de mensajes de transferencia independiente de medios (MIH) que comprende el primer transceptor que genera una trama de función de MIH ( IHF) que incluye datos de servicio de MIH o un encabezado variable representado por un campo de tipo, un campo de longitud y un campo de valor, en donde la longitud del campo de valor es exactamente de 128 octetos, y el campo de longitud solamente ocupa un octeto; y el primer transceptor envía la trama de MIHF al segundo transceptor. 25. El método de la modalidad 24, en donde un bit más significativo (MSB) del octeto ocupado por el campo de longitud se establece a un valor de uno y siete bits remanentes del octeto ocupado por el campo de longitud que sigue al MSB se establecen en un valor de cero. 26. Un transceptor que comprende: un receptor; un transmisor; y un procesador acoplado al receptor y al transmisor, el procesador está configurado para generar una trama de solicitud de función de transferencia independiente de medios (MIHF) , la trama de solicitud de MIHF incluye un encabezado fijo y una carga variable, en donde la carga variable no incluye un encabezado variable y el transmisor transmite la trama de solicitud de MIHF generada por el procesador. 27. El transceptor de la modalidad 26, en donde el encabezado fijo incluye un campo de identificación (ID) de MIHF. 28. El transceptor según cualquiera de las modalidades 26 y 27, en donde el encabezado fijo incluye un campo de identificación (ID) de sesión. 29. El transceptor según cualquiera de las modalidades 26-28, en donde el encabezado fijo incluye un campo de bandera. 30. El transceptor de la modalidad 29, en donde el procesador establece el campo de bandera en uno para indicar que existe una confirmación superpuesta en la trama de solicitud de MIHF que contiene una carga útil. 31. El transceptor según cualquiera de las modalidades 26-30, en donde el procesador establece el campo de bandera en cero para indicar que no existe carga útil en un campo de carga útil variable. 32. El transceptor según cualquiera de las modalidades 26-31, en donde la carga variable incluye un campo de tipo, un campo de longitud y un campo de valor. 33. El transceptor de la modalidad 32, en donde el campo de valor incluye un tipo de enlace especifico para obtener una lista de operadores. 34. El transceptor según cualquiera de las modalidades 26-33, en donde el transceptor es una unidad transmisora/receptora inalámbrica (WTRU) . 35. El transceptor según cualquiera de las modalidades 26-33, en donde el transceptor es una unidad transmisora/receptora cableada. 36. El transceptor según cualquiera de las modalidades 26-33, en donde el transceptor es una estación base . 37. Un transceptor que comprende: un receptor configurado para recibir una trama de solicitud de función de transferencia independiente de medios (MIHF) ; un transmisor; y un procesador acoplado al receptor y al transmisor, el procesador está configurado para generar una trama de respuesta de MIHF en respuesta al receptor que recibe la trama de solicitud de MIHF, la trama de respuesta de MIHF incluye un encabezado fijo y una carga variable, en donde la carga variable no incluye un encabezado variable y el transmisor transmite la trama de respuesta de MIHF generada por el procesador. 38. El transceptor de la modalidad 37, en donde el encabezado fijo incluye un campo de identificación (ID) de MIHF. 39. El transceptor según cualquiera de las modalidades 37 y 38, en donde el encabezado fijo incluye un campo de identificación (ID) de sesión. 40. El transceptor según cualquiera de las modalidades 37-39 en donde el encabezado fijo incluye un campo de bandera. 41. El transceptor de la modalidad 40, en donde el procesador establece el campo de bandera en uno para indicar que existe una confirmación superpuesta en la trama de solicitud de MIHF que contiene una carga útil. 42. El transceptor de la modalidad 41, en donde el procesador establece el campo de bandera en cero para indicar que no existe carga útil en un campo de carga útil variable . 43. El transceptor según cualquiera de las modalidades 37-42, en donde la carga variable incluye un campo de tipo, un campo de longitud y campo de valor. 44. El transceptor de la modalidad 43, en donde el campo de valor incluye un tipo de enlace especifico para obtener una lista de operadores. 45. El transceptor según cualquiera de las modalidades 37-44, en donde el transceptor es una unidad transmisora/receptora inalámbrica (WRTU) . 46. El transceptor según cualquiera de las modalidades 37-44, en donde el transceptor es una unidad transmisora/receptora cableada. 1 47. El transceptor según cualquiera de las modalidades 37-44, en donde el transceptor es una estación base . 48. Un transceptor que comprende: un receptor; un transmisor; y un procesador acoplado al receptor y al transmisor, el procesador está configurado para generar una trama de función de transferencia independiente de medios (MIHF) que incluye datos de servicio o un encabezado variable representado por un campo de tipo, un campo de longitud y un campo de valor, en donde la longitud del campo de valor es exactamente de 128 octetos, y el campo de longitud solamente ocupa un octeto, en donde el transmisor transmite la trama de MIHF generada por el procesador. 49. El transceptor de la modalidad 48, en donde un bit más significativo (MSB) del octeto ocupado por el campo de longitud se establece a un valor de uno y siete bits remanentes del octeto ocupado por el campo de longitud que sigue al MSB se establecen a un valor de cero. Aunque las características y elementos de la presente invención se describen en las modalidades preferidas en combinaciones particulares, cada característica o elemento se puede utilizar solo sin las otras características y elementos de las modalidades preferidas o en varias combinaciones, con o sin otras características y elementos de la presente invención. Los métodos o diagramas de flujo proporcionados en la presente invención se pueden implementar en un programa de computadora, software, o firmware ejemplificado tangiblemente en un medio de almacenamiento legible en computadora para la ejecución por una computadora o un procesador de uso general. Ejemplos de medios de almacenamiento legibles en computadora incluyen una memoria de sólo lectura (ROM) , una memoria de acceso aleatorio (RAM) , un registro, memoria caché, dispositivos de memoria de semiconductores, medios magnéticos tales como discos duros internos y discos extraibles, medios magneto-ópticos, y medios ópticos tales como discos CD-ROM, y discos versátiles digitales (DVDs) . Procesadores adecuados incluyen, a manera de ejemplo, un procesador de uso general, un procesador de uso especial, un procesador convencional, un procesador de señales digitales (DSP), una pluralidad de microprocesadores, uno o varios microprocesadores en asociación con un núcleo DSP, un controlador, un microcontrolador, Circuitos Integrados Específicos de Aplicación (ASICs) , Circuitos Arreglos de Puerto Programable por Campo (FPGAs) , y otro tipo de circuito integrado (IC), y/o una máquina de estado. Un procesador en asociación con software se puede utilizar para implementar un transceptor de radiofrecuencia para utilizarse en una unidad transmisora/receptora inalámbrica ( TRU) , equipo de usuario (UE) , terminal, estación base, controlador de radio red (RNC) , o cualquier computadora principal. La WTRU se puede utilizar en conjunto con módulos, implementados en hardware y/o software, tales como una cámara, un módulo de cámara de video, un videoteléfono, un teléfono con altavoz, un dispositivo de vibración, un altavoz, un micrófono, un transceptor de televisión, una diadema de manos libres, un teclado, un módulo Bluetooth®, una unidad radioeléctrica de frecuencia modulada (FM), una unidad de visualización de pantalla de cristal liquido (LCD) , una unidad de visualización de diodo emisor de luz orgánico (OLED) , un reproductor de música digital, un reproductor de medios, un módulo reproductor de juegos de video, un buscador de Internet, y/o cualquier módulo de red de área local inalámbrica (WLAN) .

Claims (5)

REIVINDICACIONES

1. Método de comunicación de mensajes de transferencia independiente de medios (MIH) , el método comprende: generar una trama de MIH (MIH) que incluye datos de servicio de MIH o un encabezado variable representado por un campo de tipo, un campo de longitud y un campo de valor; en donde el campo de valor es de exactamente 128 octetos, el campo de longitud es de un octeto, y un bit más significativo (MSB) del campo de longitud se establece a un valor de uno y siete bits remanentes del campo de longitud que siguen al MSB se establecen a un valor de cero; y transmitir la trama de MIH.

2. Unidad transmisora/receptora inalámbrica (WTRU) que comprende: un procesador configurado para generar una trama de transferencia independiente de medios (MIH) que incluye datos de servicio o un encabezado variable representado por un campo de tipo, un campo de longitud y un campo de valor, en donde una longitud del campo de valor es de exactamente 128 octetos, y el campo de longitud solamente ocupa un octeto, y un bit más significativo (MSB) del octeto ocupado por el campo de longitud se establece a un valor de uno y siete bits remanentes del octeto ocupado por el campo de longitud que sigue al MSB se establecen a un valor de cero; y un transmisor configurado para transmitir la trama de MIH generada por el procesador.

3. Método de creación de elementos de información (IEs) de transferencia independiente de medios (MIH) que tienen un campo de tipo, un campo de longitud, y un campo de valor, el método comprende: determinar un número de octetos de datos que se van a incluir en el campo de valor de IE; establecer el campo de longitud del IE, en donde cuando el número de octetos de datos es menor de 128 octetos, el campo de longitud es de un octeto de largo y un bit más significativo (MSB) del campo de longitud se establece a un valor de cero y siete bits remanentes del campo de longitud que siguen al MSB indican el número de octetos de datos en el campo de valor del IE; cuando el número de octetos de datos es exactamente de 128 octetos, el campo de longitud es de un octeto de largo y el MSB del campo de longitud se establece a un valor de uno y siete bits remanentes del campo de longitud que siguen al MSB se establecen a un valor de cero; y cuando el número de octetos de datos es mayor a 128 octetos, el campo de longitud es mayor a un octeto y el MSB de un primer octeto del campo de longitud se establece a un valor de uno y siete bits remanentes del primer octeto del campo de longitud indican un número de octetos adicionales del campo de longitud, y los octetos adicionales del campo de longitud, cuando se agregan a un valor de 128, indican el número de octetos de datos en el campo de valor del IE.

4. Unidad transmisora/receptora inalámbrica que comprende: un procesador configurado para establecer un campo de longitud del elemento de información (IE) de transferencia independiente de medios (MIH) a un octeto de largo y un bit más significativo (MSB) del campo de longitud a un valor de cero y siete bits remanentes del campo de longitud que siguen al MSB indican un número de octetos de datos en un campo de valor del IE, cuando el número de octetos de datos es menor a 128 octetos; establecer el campo de longitud del IE de MIH en un octeto de largo y el MSB del campo de longitud a un valor de uno y siete bits remanentes del campo de longitud que siguen al MSB a un valor de cero, cuando el número de octetos de datos es de exactamente 128 octetos; y establecer el campo de longitud de IE de MIH para que sea mayor a un octeto y el MSB de un primer octeto del campo de longitud a un valor de uno y siete bits remanentes del primer octeto del campo de longitud indican un número de octetos adicionales del campo de longitud, y los octetos adicionales del campo de longitud, cuando se agregan a un valor de 128, indican el número de octetos de datos en el campo de valor del IE, cuando el número de octetos de datos es mayor a 128 octetos .

5. WTRU según la reivindicación 4, qu comprende además: un transmisor acoplado al procesador configurado para transmitir el IE de MIH.