BRPI0712002A2 - aprimoramentos de operação de protocolo de entrega independente de meios eficiêntes - Google Patents
aprimoramentos de operação de protocolo de entrega independente de meios eficiêntes Download PDFInfo
- Publication number
- BRPI0712002A2 BRPI0712002A2 BRPI0712002-8A BRPI0712002A BRPI0712002A2 BR PI0712002 A2 BRPI0712002 A2 BR PI0712002A2 BR PI0712002 A BRPI0712002 A BR PI0712002A BR PI0712002 A2 BRPI0712002 A2 BR PI0712002A2
- Authority
- BR
- Brazil
- Prior art keywords
- field
- value
- length
- mihf
- octets
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/005—Control or signalling for completing the hand-off involving radio access media independent information, e.g. MIH [Media independent Hand-off]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/14—Reselecting a network or an air interface
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
Abstract
APRIMORAMENTO DE OPERAçãO DE PROTOCOLO DE ENTREGA INDEPENDENTE DE MEIOS EFICIENTE. A presente invenção modifica um formato de quadro de função de entrega independente de meios (MIH) (MIHF) existente conforme definido pelo padrão IEEE 802.21. Em uma realização, a carga variável do quadro MIHF é modificada para eliminar o cabeçalho variável de MIHF por meio de definição do campo de identificação (ID) de MIHF e do campo de ID de sessão como campos fixos no cabeçalho fixo de MIHF. Desta forma, a carga variável de MIHF somente é composta do payload de MIHF. Em uma outra realização, um campo tal como um elemento de informação (IE), um cabeçalho ou dados de serviço de MIH tais como um comando ou um evento é representado por um campo de tipo, campo de comprimento e campo de valor (TLV). O comprimento do campo de valor é de exatamente 128 octetos e o campo de comprimento ocupa apenas um octeto.
Description
Aprimoramentos de operação de protocolo de entrega independente de meios
eficiente.
A presente invenção refere-se a sistemas de comunicação sem fio. Mais especificamente, a presente invenção refere-se a um formato de quadro de função de entrega independente de meios (MIHF) utilizado para transmitir e receber sem fios mensagens de entrega independente de meios (MIH). Antecedentes
A Figura 1 exibe a representação de valor, comprimento e tipo (TLV) atual de um IE 100 que inclui um campo de tipo 105, um campo de comprimento 110 e um campo de valor 115, conforme especificado por meio do padrão IEEE 802.21. Alternativamente, os campos TLV podem representar outros campos, tais como um cabeçalho ou dados de serviço de MIH tais como um comando ou evento.
O campo ds tipo 105 indica o tipo do IE e possui valores de identificação (ID) definidos no padrão IEEE 802.21. O campo de valor 115 contém o payload ou o valor do IE 100. Em um primeiro cenário, caso a quantidade de octetos ocupados pelo campo de valor 115 seja menor ou igual a 127, o tamanho do campo de comprimento 110 é sempre 1 (um) octeto e o bit mais significativo (MSB) 120 do octeto é definido no valor "0". Em um segundo cenário, caso o número de octetos ocupados pelo campo de valor 115 seja maior que 127, o tamanho do campo de comprimento 110 é de pelo menos "x" octetos, em que "x" é maior ou igual a 2 (dois). Neste caso, o MSB 125 do primeiro octeto do campo de comprimento 110 é definido como o valor "1" e os sete bits restantes do primeiro octeto indicam a quantidade de octetos adicionais que são anexados ao primeiro octeto. O número representado pelo segundo octeto do campo de comprimento 110 indica o tamanho total do campo de valor 115.
Existe um problema com a explicação de campo de comprimento conforme especificado em IEEE 802.21. Especificamente, no segundo cenário de interpretação de campo de comprimento, o padrão IEEE 802.21 especifica que o número representado pelo segundo octeto do campo de comprimento indica o tamanho total do campo de valor. Isso é impreciso porque o número representado pelo segundo octeto não indica o comprimento do campo de valor. Por outro lado, o número representado pelos octetos anexos adicionais, a partir do segundo octeto, indica o comprimento do campo de valor. Além disso, o valor dos octetos adicionais deverá representar o comprimento do campo de valor em octetos e não em bits. Desta forma, o campo de comprimento não é utilizado eficientemente.
A Figura 2 exibe o formato atual de um quadro de MIHF 200 especificado pelo padrão IEEE 802.21. O padrão IEEE 802.21 especifica que o quadro de MIHF 200 é composto de um cabeçalho fixo de MIHF 205 e uma carga variável de MIHF 210. A carga variável de MIHF 210 é composta de um cabeçalho variável de MIHF 215 e um payload de MIHF 220.
O padrão IEEE 802.21 especifica que o cabeçalho fixo de MIHF 205 é obrigatório. A Tabela 1 abaixo exibe o conteúdo do cabeçalho fixo de MIHF 205 conforme especificado em IEEE 802.21.
Tabela 1
Descrição de Cabeçalho Fixo de MIHF
<table>table see original document page 3</column></row><table> <table>table see original document page 4</column></row><table>
Conforme especificado atualmente em IEEE 802.21, o cabeçalho variável de MIHF 215 contém identificadores adicionais que ajudam a analisar e coordenar o payload que é embutido. Estes identificadores também são representados em formato TLV. Alguns valores possíveis para o campo de tipo (do TLV) destes identificadores especificados em IEEE 802.21 incluem a ID da transação (para coincidir solicitações e respostas), ID da função de MIH/ID da sessão (para identificar os parceiros de comunicação) e informações de sincronização (para identificar a marca de tempo da mensagem recebida).
O campo de payload de MIHF 220 contém TLVs específicos de serviço que agem como payload de uma mensagem. Comparando-se o cabeçalho fixo de MIHF 205 na Figura 2 (formato de quadro MIHF) e a descrição dos seus campos na Tabela 1 (descrição de cabeçalho fixo de MIHF), dever-se-á observar que o campo "quantidade de identificadores de cabeçalho adicionais" que é exibido na Tabela 1 não existe no quadro de MIHF 200 da Figura 2.
O campo de comprimento de carga variável 225 do cabeçalho fixo de MIHF 205 é representado por 16 bits. O campo de comprimento de carga variável 225 (conforme especificado em IEEE 802.21) indica que o comprimento total da carga variável embutida no quadro MIHF 200 é a soma do comprimento do cabeçalho variável de MIHF 215 e do comprimento do payload de MIHF 220. O comprimento do cabeçalho fixo de MIHF 205 não é incluído.
O campo de comprimento de carga variável 225 não é necessário, pois o comprimento do cabeçalho variável de MIHF 210 pode ser calculado e os dezesseis bits utilizados para a sua representação deverão ser economizados.
O cabeçalho fixo de MIHF 205 define um campo de solicitação de reconhecimento (ACK-req) 230 para solicitar um reconhecimento e um campo de resposta de reconhecimento (ACK-rsp) 235 para acusar recebimento de uma mensagem. Conforme especificado em IEEE 802.21, as mensagens de reconhecimento são anexadas ("acumuladas") ou enviadas isoladamente em um pacote de resposta. O padrão IEEE 802.21, entretanto, não especifica como indicar que um quadro de resposta não possui payload e serve apenas como reconhecimento. Desta forma, caso um parceiro receba uma mensagem com o bit ACK-rsp definido em "1", ele necessitaria verificar se há payload ou não. Isso não é eficiente porque, se não houver payload, o campo de carga variável de MIHF 210 conteria bits falsos que poderiam ser interpretados como bits válidos pelo receptor. Desta forma, é necessário ter um campo que identifique mensagens de reconhecimento puro e o quadro MIHF 200 não deverá ter um campo de carga variável de MIHF 210. Atualmente, não há esse campo definido.
O padrão IEEE 802.21 define três identificadores de protocolo MIHF que incluem uma ID de MIHF, uma ID de sessão e uma ID de transação 240. A ID de MIHF identifica o remetente de quem originou-se o quadro de MIHF 200. A ID da sessão é um identificador exclusivo gerado pela origem de uma sessão. A ID de transação 240 é utilizada para coincidir solicitações e respostas, bem como coincidir solicitação, resposta e indicação para um ACK (vide Tabela 1 acima).
Desta forma, todos os três identificadores de protocolo MIHF (juntos) identificam exclusivamente um quadro de MIHF (ou mensagem). Apenas a ID da transação 240, entretanto, é exibida no cabeçalho fixo de MIHF 205, enquanto a ID de MIHF, a ID de sessão e a ID de transação 240 são supostamente representadas em formato TLV e são especificadas como residindo no cabeçalho variável de MIHF 215 (que é uma parte da carga variável de MIHF 210). O problema é que o uso de um TLV para representar cada uma dentre a ID de MIHF e a ID de sessão desperdiçará bits e complicará a decodificação do quadro de MIHF 200. Além disso, a ID da transação 240 já recebeu um campo fixo no cabeçalho fixo de MIHF 205 e não há necessidade de representá-lo novamente em formato de TLV no cabeçalho variável de MIHF 215.
Resumo da Invenção
A presente invenção inclui um conjunto de modificações do formato de quadro de MIHF existente no padrão IEEE 802.21. A presente invenção modifica o formato de quadro de MIHF existente conforme definido pelo padrão IEEE 802.21. Em uma realização, a carga variável do quadro de MIHF é modificada para eliminar o cabeçalho variável de MIHF por meio de definição do campo de ID de MIHF e do campo ID de sessão como campos fixos no cabeçalho fixo de MIHF. Desta forma, a carga variável de MIHF somente é composta do payload de MIHF. Em uma outra realização, um campo tal como IE, comando ou cabeçalho é representado por um campo de tipo, campo de comprimento e campo de valor (TLV). O comprimento do campo de valor é de exatamente 128 octetos e o campo de comprimento ocupa apenas um octeto.
Breve Descrição das Figuras
Pode ser obtida uma compreensão mais detalhada da presente invenção a partir da descrição de uma realização preferida a seguir, fornecida como forma de exemplo e a ser compreendida em conjunto com as figuras anexas, nas quais:
- a Figura 1 exibe a representação de formato de TLV atual de um IE conforme especificado pelo padrão IEEE 802.21;
- a Figura 2 exibe o formato de quadro de MIHF IEEE 802.21 atual;
- a Figura 3 exibe o formato de TLV atual especificado por IEEE 802.21; - a Figura 4 exibe um quadro de TLV com um campo de valor que possui um valor de mais de 128 octetos;
- a Figura 5 exibe um quadro de TLV com um campo de valor que possui um comprimento de exatamente 128 octetos conforme a presente invenção;
- a Figura 6 exibe um formato de quadro de MIHF configurado conforme a presente invenção;
- a Figura 7 exibe um exemplo de quadro de solicitação de MIHF para solicitar um IE conforme a presente invenção;
- a Figura 8 exibe um exemplo de quadro de resposta de MIHF que fornece um IE em resposta ao quadro de solicitação de MIHF conforme a presente invenção;
- a Figura 9 exibe um exemplo de representação de TLV para um IE de identificador de operador conforme a presente invenção;
- a Figura 10 exibe um quadro de MIHF com uma mensagem de reconhecimento conforme a presente invenção; e
- a Figura 11 exibe um sistema de comunicação configurado conforme a presente invenção.
Descrição Detalhada das Realizações Preferidas
Quando indicado a seguir, a terminologia "unidade de transmissão e recepção sem fio (WTRU)" inclui, mas sem limitar-se a um equipamento de usuário (EU), uma estação móvel, uma unidade de assinante fixa ou móvel, pager, telefone celular, assistente digital pessoal (PDA), computador ou qualquer outro tipo de dispositivo de usuário capaz de operar em um ambiente sem fio. Quando indicado a seguir, a terminologia "estação base" inclui, mas sem limitar-se a um Nó B, controlador de local, ponto de acesso (AP) ou qualquer outro tipo de dispositivo de interface capaz de operar em um ambiente sem fio.
A Figura 3 exibe a Representação de formato de TLV atual de um IE conforme definido em IEEE 802.21, similar ao formato do IE 100 exibido na Figura 1. A presente invenção é aplicável à interpretação do campo de comprimento do TLV quando o comprimento do campo de valor for de mais de 127 octetos.
Conforme exibido em detalhes pela Figura 4, caso o número de octetos ocupados pelo campo de valor seja de mais de 128 octetos, o MSB do primeiro octeto do campo de comprimento é definido como "1". O restante dos sete bits indica a quantidade de octetos (de novos campos de comprimento) que são adicionalmente anexados ao primeiro octeto (do campo de comprimento). O comprimento do campo de valor é, portanto, de 128 mais o número representado pelos outros octetos de campo de comprimento anexados a partir do segundo octeto.
A presente invenção define um terceiro caso que se aplica quando o comprimento do campo de valor for de exatamente 128 octetos conforme exibido na Figura 5. Caso o comprimento do campo de valor seja de exatamente 128 octetos, o MSB do campo de comprimento é definido como "1" e os sete bits restantes são definidos como "0". Segundo o padrão IEEE 802.21 atual, caso o comprimento seja de mais de 127 octetos, conforme exibido na Figura 1, "x" octetos extra devem ser adicionados para indicar completamente o comprimento do campo de valor. Mesmo se o comprimento for de exatamente 128 octetos, o padrão IEEE 802.21 atual necessita de um octeto adicional para atingir o valor exato de 128 octetos. Desta forma, existe um desperdício de um octeto adicional. A presente invenção não necessita de octetos adicionais para indicar o comprimento do campo de valor em octetos quando o comprimento do campo de valor for de exatamente 128 octetos.
A Figura 6 exibe um formato de quadro de MIHF 600 configurado conforme a presente invenção. O formato de quadro de MIHF 600 inclui um cabeçalho fixo de MIHF 605 e uma carga variável de MIHF 610. O cabeçalho variável de MIHF (que é uma parte da carga variável de MIHF do quadro de MIHF IEEE 802.21 atual), entretanto, foi removido. Isso acontece porque a ID de MIHF e a ID da sessão que foram representadas anteriormente em TLVs e que estavam contidas no cabeçalho variável de MIHF agora são definidas como campos fixos no cabeçalho fixo de MIHF 605 conforme a presente invenção. Desta forma, a carga variável de MIHF 610 é composta somente do payload de MIHF.
Os nomes de campos do cabeçalho fixo de MIHF 605 que são exibidos na Figura 6 são campos novos que são definidos ou campos velhos que foram modificados conforme a presente invenção.
O campo Reservado 615 foi modificado. Ele foi representado inicialmente por dez bits e agora deverá ser representado por nove bits. O outro bit é utilizado para definir um campo de "marca" 620 conforme a presente invenção. Existem dois cenários de como este campo pode ser utilizado.
Em um primeiro cenário, quando existe payload no campo de payload variável de MIHF (do quadro MIHF), o campo de marca 620 é definido como "1". Neste cenário, o comprimento total do quadro de MIHF seria: {[comprimento de cabeçalho fixo de MIHF (sempre 15 octetos)] + [comprimento de carga variável de MIHF]} octetos = {15 + [comprimento do campo de tipo (sempre quatro octetos)] + [número de octetos utilizados para representar o campo de comprimento] + [comprimento do campo de valor conforme indicado pelo campo de comprimento] octetos. Este pode ser utilizado para conectar ("acumular") um reconhecimento para uma mensagem recebida anteriormente. Desta forma, ocorre uma indicação de que existe um reconhecimento "acumulado" no quadro que também contém payload quando os bits de marca e ACK-rsp são definidos como "1".
Em um segundo cenário, quando não há payload no campo de payload variável de MIHF (do quadro de MIHF), o campo de marca 620 é definido como "0". Neste caso, o comprimento total do quadro de MIHF seria: [comprimento de cabeçalho fixo de MIHF (sempre quinze octetos)]. Isso é particularmente útil caso um parceiro necessite enviar um quadro de MIHF que contenha apenas uma mensagem de reconhecimento.
O padrão IEEE 802.21 atual não diferencia mensagens de reconhecimento isoladas. Ao contrário, o padrão IEEE 802.21 sempre utiliza formação de mensagens de reconhecimento anexadas ("acumuladas"). Desta forma, caso um parceiro envie um quadro de MIHF que contém apenas uma mensagem de reconhecimento, o ACK-rsp é definido como "1" e o bit de marca é definido como "0".
Neste cenário, a carga variável de MIHF não conduz dados e, portanto, não existe. O quadro de MIHF, portanto, inclui apenas o cabeçalho fixo de MIHF e o receptor não tenta verificar nenhum payload.
O campo de ID de MIHF 625 desempenha o mesmo papel já especificado em IEEE 802.21 - a ID de MIHF do remetente do qual originou-se o quadro de MIHF. Este campo, entretanto, não está contido no cabeçalho fixo de MIHF atual em IEEE 802.21. O significado de ter este campo neste cabeçalho é que ele sempre será necessário para identificação exclusiva de todas as mensagens enviadas. Desta forma, caso seja representado em formato TLV, ele ocupará bits adicionais que podem ser utilizados para outros propósitos. Além disso, a sua representação de TLV introduziria mais esforços e payload ao decodificar uma mensagem.
A ID da sessão 630 possui a mesma função já especificada em IEEE 802.21 - um identificador exclusivo gerado pela origem de uma sessão. Para definir exclusivamente o remetente de uma mensagem, entretanto, é necessária a ID da sessão. De forma similar, ter esta ID no cabeçalho fixo de MIHF economiza bits e garante a decodificação de mensagens, ao contrário de representá-la em formato de TLV.
O campo de comprimento de carga variável é removido do cabeçalho fixo de MIHF. O papel deste campo é indicar o comprimento do campo de payload variável de MIHF e foi composto de 16 bits. Mesmo na ausência do comprimento de carga variável, entretanto, o comprimento do campo de payload variável de MIHF pode ainda ser calculado conforme segue: {[comprimento do campo de tipo (sempre quatro octetos)] + [número de octetos utilizados para representar o campo de comprimento] + [comprimento do campo de valor conforme indicado pelo campo de comprimento]} octetos. Desta forma, os 16 bits podem ser economizados sem a perda de nenhuma informação tal como o comprimento do payload variável de MIHF. O restante dos campos do cabeçalho fixo de MIHF é descrito pela Tabela 1 acima.
A parte de carga variável de MIHF do formato de quadro de MIHF contém apenas TLVs específicas de serviço. Ela não contém mais o cabeçalho variável de MIHF. A seguir encontra-se um exemplo de implementação do quadro de MIHF conforme a presente invenção.
Para recuperar IEs específicos, por exemplo, o cliente envia uma solicitação de informação (ou seja, consulta) para um ponto de serviço (PoS) de MIH. A solicitação de informação contém uma consulta para os IEs. O PoS de MIH envia uma resposta de informação que contém a resposta da solicitação de informação de volta para o cliente.
A Figura 7 exibe um exemplo de quadro de solicitação de MIHF 700 para solicitar um IE. Uma entidade capacitada para IEEE 802.21 solicita um IE específico tal como uma lista de operadores (utilizando, por exemplo, TYPE_lE_LIST_0F_0PERATORS_REQUEST). O quadro de solicitação de MIHF 700 inclui um cabeçalho fixo de MIHF 705 e uma carga variável de MIHF 710.
O "xxx" contido pelos campos do cabeçalho fixo de MIHF 705 do quadro de solicitação de MIHF 700 exibido na Figura 7 indica simplesmente que os bits podem possuir qualquer valor sem afetar a implementação do quadro de solicitação 700. O campo de ID de mensagem de MIH 715 é uma combinação de um campo de ID de serviço 720, um campo de código de operação (opcode) 725 e um campo de ID de ação 730.
O campo de ID de serviço 720 identifica os diferentes serviços de MIH e possui os valores a seguir:
1 = Administração de Sistema;
2 = Serviço de Evento;
3 = Serviço de Comando; e
4 = Serviço de Informação.
Conforme exibido na Figura 7, o campo de ID de serviço 720 possui um valor decimal de 4 que é representado nos bits binários "0100". Este valor indica que o payload conduzido na carga variável de MIHF 710 está relacionado com o serviço de informação.
O campo de código de operação (opcode) 725 indica um tipo de operação a ser realizado com relação à ID de serviço 720 e possui os valores a seguir:
1 = Solicitação;
2 = Resposta; e
3 = Indicação.
Conforme exibido, o campo de código de operação (opcode) 725 é representado por um valor 1 para indicar que o payload é uma solicitação para a ID de serviço em questão. O campo de ID de ação 730 indica a ação a ser tomada com relação ao campo ID de serviço 720.
O campo de marca 735 conforme exibido é definido em "1", o que indica que a carga variável de MIHF contém dados.
A carga variável de MIHF 710 da parte de mensagem de solicitação do quadro de MIHF 700 contém a representação de TLV para a solicitação de IE definida por um campo de tipo 740, um campo de comprimento 745 e um campo de valor 750.
O campo de tipo 740 contém o valor para o tipo de IE. No exemplo exibido na Figura 7, o campo de tipo 740 é representado em notação hexadecimal com um valor de "Ox 10000003" (quatro octetos), conforme especificado em IEEE 802.21. Isso significa que o tipo de IE em questão é a lista de operadores para um tipo de link específico, que é especificado no campo de valor do TLV ("xxx...").
O campo de comprimento 745 possui o seu MSB definido como "0", o que significa que o comprimento do campo de valor é de menos de 128 octetos. O comprimento exato do campo de valor é representado pelo resto dos sete bits que possuem valor decimal de 4. O comprimento do campo de valor é, portanto, de quatro octetos.
O campo de valor 750 contém o tipo de link específico para o qual é necessário obter a lista de operadores. O campo de valor 750 pode possuir um comprimento fixo ou variável, dependendo do IE em questão. Para este exemplo, especifica-se em IEEE 802.21 que o comprimento deste campo é fixado em quatro octetos. Ele é representado por "xxx..." pois pode representar qualquer valor definido.
A Figura 8 exibe um exemplo de quadro de resposta de MIHF 800 que fornece um IE em resposta ao quadro de solicitação de MIHF 700. Considera-se que o receptor da mensagem de solicitação decodifica o quadro de MIHF e responde (utilizando, por exemplo, TYPE_IE_LIST_OF_OPERATORS_RESPONDE). O quadro de resposta de MIHF 800 inclui um cabeçalho fixo de MIHF 805 e uma carga variável de MIHF 810. O quadro de resposta de MIHF 800 exibe a resposta à solicitação da lista de operadores IE (para um tipo de link específico).
O "xxx" contido pelos campos do cabeçalho fixo de MIHF 805 do quadro de resposta de MIHF 800 exibido na Figura 8 indica simplesmente que os bits podem possuir qualquer valor sem afetar a implementação do quadro de resposta 800. O campo de ID de mensagem de MIH 815 é uma combinação de um campo de ID de serviço 820, um campo de código de operação (opcode) 825 e um campo de ID de ação 830.
O campo ACK-req 835 contém um bit que é definido como "1", o que indica que o parceiro deverá acusar o recebimento desta mensagem (conforme especificado em IEEE 802.21).
O campo de marca 840 possui um bit que é definido como "1", o que indica que a carga variável de MIHF contém dados.
O bit de ID de serviço 820 possui um valor decimal de 4 que é representado em bits. Este valor indica que o payload conduzido no quadro de MIHF refere-se ao serviço de informações.
O campo de código de operação (opcode) 825 é representado por um valor decimal de 2 para indicar que o payload é uma resposta para a ID de serviço em questão.
O campo de ID de ação 830 indica a ação a ser tomada com relação ao campo de ID de serviço 820.
A carga variável de MIHF 810 do campo de mensagem de resposta contém três campos que são explicados abaixo.
O campo de tipo 845 contém o valor do tipo de IE. Neste exemplo, ele é representado em notação hexadecimal com um valor de Ox 10000003 (quatro octetos) conforme especificado em IEEE 802.21. Isso significa que o tipo de IE em questão é a lista de operadores para um tipo de link específico (que foi especificado no campo de valor do TLV da mensagem de solicitação).
O campo de comprimento 850 possui o seu MSB definido como "1", o que significa que o comprimento do campo de valor é de mais de 128 octetos. O restante dos sete bits do primeiro octeto deste campo indica que dois octetos de campo de comprimento são adicionalmente anexados (16 bits). O valor decimal representado por esses 16 bits é de 403. O comprimento total do campo de valor é, portanto, de 128 + 403 = 531 octetos.
O campo de valor 855 contém o payload. Segundo a especificação do IEEE 802.21, este campo é composto de duas partes: o número de operadores (para o tipo de link específico) seguido pelo(s) identificador(es) do(s) operador(es).
O campo de número de operadores 860 é representado por quatro octetos, conforme especificado em IEEE 802.21. Como esclarecimento deste exemplo, o número de operadores para o tipo de link em questão é selecionado como sendo de 2. Este valor é exibido como os primeiros quatro octetos no campo de valor 915 da carga variável de MIHF exibida na Figura 9.
Os identificadores de operadores são representados em formato TLV. Cada um é tratado como um IE separado que é construído em primeiro lugar e adicionado em seguida ao campo de valor após a quantidade de identificadores de operadores. Desta forma, dois TLVs identificadores de operadores independentes 865 e 870 estão presentes. Os TLVs 865 e 870 possuem estrutura similar, mas podem variar de conteúdo e comprimento. Observe-se que se considera isso porque o nome do operador ainda não é definido. Os dois TLVs 865 e 870 são anexados ao número de operadores no campo de valor 855 (que se encontra na carga variável de MIHF 810). Casa TLV 865 e 870 possui o mesmo valor para o campo de tipo, mas o campo de comprimento e o campo de valor podem variar. Poder-se-á sugerir, portanto, que o campo de tipo dos TLVs anexados 865 e 870 seja removido. O campo de valor 855 do quadro de resposta 800 conteria, portanto, quatro octetos para a série de operadores, um campo de comprimento para o primeiro TLV de identificador de operador 865 seguido pelo seu campo de valor e um campo de comprimento para o segundo TLV de identificador de operador 870 seguido pelo seu campo de valor. Observe-se que isso não pode ser realizado para todas as solicitações ou respostas de IE porque às vezes os TLVs a serem anexados são diferentes e, portanto, o seu campo de tipo é necessário.
A Figura 9 exibe um exemplo de representação de TLV de um identificador de operador IE 900. O campo de tipo 905 contém o valor do tipo de IE. Neste exemplo, ele é representado em notação hexadecimal com um valor de Ox 10000004 (quatro octetos) conforme especificado em IEEE 802.21. Isso significa que o tipo de IE em questão é o identificador de operador. O campo de comprimento 910 possui o seu MSB definido como "1", o que indica que o comprimento do campo de valor 915 é de mais de 128 octetos. Os sete bits restantes do primeiro octeto do campo de comprimento 910 indicam que um octeto de campo de comprimento é adicionalmente anexado (oito bits). O valor decimal representado por esses oito bits é de 126. O comprimento total do campo de valor 915, portanto, é de 128 + 126 = 254 octetos.
O campo de valor 915 inclui um campo de espaço de nome de operador 920 seguido por um campo de nome de operador 925. O campo de nome de operador 925 contém o valor do nome do operador em questão. O campo de nome de operador 925 é um conjunto terminal não nulo cujo comprimento não deverá exceder 253 octetos (conforme especificado por meio do padrão IEEE 802.21). O campo 925 é exibido como incluindo "xx....xx", que é utilizado para representar qualquer valor, pois os valores possíveis ainda não são definidos no padrão IEEE 802.21. Desta forma, o campo de nome de operador 925 é considerado como contendo o comprimento máximo, ou seja, 253 octetos, apenas como forma de exemplo.
Quando um receptor recebe uma mensagem de resposta de MIHF, o receptor decodifica o quadro e observa que o bit ACK-req foi definido como "1" pelo parceiro. Segundo a presente invenção, o receptor envia em seguida um quadro que inclui uma mensagem de reconhecimento 1000, que inclui apenas um cabeçalho fixo de MIHF 1005, conforme exibido na Figura 10. No cabeçalho fixo de MIHF 1005, um bit ACK-rsp 1010 é definido como "1", o que indica que esse quadro contém um reconhecimento para uma mensagem anterior. Além disso, um bit de marca 1015 é definido como "0", o que indica que não há payload na carga variável de MIHF (que é ausente). Desta forma, este quadro contém apenas uma mensagem de reconhecimento.
O restante dos campos e os valores que eles deverão conter são especificados pelo padrão IEEE 802.21. Desta forma, o receptor pode diferenciar mensagens de reconhecimento puro ao verificar o bit de marca 1015.
A Figura 11 exibe um sistema de comunicação sem fio 1100 que inclui um primeiro transceptor 1105 e um segundo transceptor 1110 configurado conforme a presente invenção. O primeiro transceptor 1105 e o segundo transceptor 1110 podem ser uma unidade de transmissão e recepção sem fio (WTRU), uma estação base e similares. Alternativamente, pode ser implementado um sistema de comunicação com fios, utilizando, por exemplo, Ethernet como a conexão física.
Conforme exibido na Figura 11, o primeiro transceptor 1105 inclui uma primeira antena 1115 e o segundo transceptor 1110 inclui uma segunda antena 1120. O primeiro transceptor 1105 envia um quadro de solicitação de MIHF 1125 para o segundo transceptor 1110 por meio da primeira antena 1115. O quadro de solicitação de MIHF 1125 inclui um cabeçalho fixo de MIHF e uma carga variável de MIHF. A carga variável de MIHF no quadro de solicitação de MIHF 1125 não inclui um cabeçalho variável de MIHF. O segundo transceptor 1110 envia um quadro de resposta de MIHF 1130 para o primeiro transceptor 1105 por meio da segunda antena 1120 em resposta ao recebimento do quadro de solicitação de MIHF 1125. O quadro de resposta de MIHF 1130 inclui um cabeçalho fixo de MIHF e uma carga variável de MIHF. A carga variável de MIHF no quadro de resposta de MIHF 1130 não inclui um cabeçalho variável de MIHF.
O transceptor 1105 inclui ainda um transmissor 1135 para enviar quadros de solicitação de MIHF 1125 e quadros de resposta de MIHF 1130, um receptor 1140 para receber quadros de solicitação de MIHF 1125 e quadros de resposta de MIHF 1130 e um processador 1145 para gerar quadros de solicitação de MIHF 1125 e quadros de resposta de MIHF 1130.
O transceptor 1110 inclui adicionalmente um transmissor 1150 para enviar quadros de solicitação de MIHF 1125 e quadros de resposta de MIHF 1130, um receptor 1155 para receber quadros de solicitação de MIHF 1125 e quadros de resposta de MIHF 1130 e um processador 1160 para gerar quadros de solicitação de MIHF 1125 e quadros de solicitação de MIHF 1130.
Realizações
1. Em um sistema de comunicação que inclui um primeiro transceptor e um segundo transceptor, método de comunicação de mensagens de entrega independente de meios (MIH) que compreende o envio pelo primeiro transceptor de um quadro de solicitação de função de MIH (MIHF) para o segundo transceptor, em que o quadro de solicitação de MIHF inclui um cabeçalho fixo e uma carga variável, em que a carga variável não inclui um cabeçalho variável.
2. Método conforme a realização 1, que compreende adicionalmente o envio pelo segundo transceptor de um quadro de resposta de MIHF para o primeiro transceptor em resposta ao recebimento do quadro de solicitação de MIHF.
3. Método conforme qualquer das realizações 1 e 2, em que o cabeçalho fixo inclui um campo de identificação (ID) de MIHF.
4. Método conforme qualquer das realizações 1 a 3, em que o cabeçalho fixo inclui um campo de identificação (ID) de sessão.
5. Método conforme qualquer das realizações 1 a 4, em que o cabeçalho fixo inclui um campo de marca.
6. Método conforme a realização 5, que compreende adicionalmente a definição do campo de marca como um para indicar que existe um reconhecimento acumulado no quadro de solicitação de MIHF que contém um payload.
7. Método conforme a realização 5, que compreende adicionalmente a definição do campo de marca como zero para indicar que não existe payload em um campo de payload variável.
8. Método conforme qualquer das realizações 1 a 7, em que a carga variável inclui um campo de tipo, um campo de comprimento e um campo de valor.
9. Método conforme a realização 8, em que o campo de valor inclui um tipo de link específico para obtenção de uma lista de operadores.
10. Método conforme qualquer das realizações 1 a 9, em que o sistema de comunicação é um sistema de comunicação sem fio, o primeiro transceptor é uma unidade de transmissão e recepção sem fio (WTRU) e o segundo transceptor é uma estação base.
11. Método conforme qualquer das realizações 1 a 10, em que o sistema de comunicação é um sistema de comunicação sem fio, em que o primeiro transceptor é uma estação base e o segundo transceptor é uma unidade de transmissão e recepção sem fio (WTRU).
12. Método conforme qualquer das realizações 1 a 10, em que o sistema de comunicação é um sistema de comunicação com fios que utiliza Ethernet para fornecer uma conexão física.
13. Em um sistema de comunicação que inclui um primeiro transceptor e um segundo transceptor, método de comunicação de mensagens de entrega independente de meios (MIH) que compreende:
- envio pelo primeiro transceptor de um quadro de solicitação de função de MIH (MIHF) para o segundo transceptor; e
- envio pelo segundo transceptor de um quadro de resposta de MIHF para o primeiro transceptor em resposta ao recebimento do quadro de solicitação de MIHF, em que o quadro de resposta de MIHF inclui um cabeçalho fixo e uma carga variável, em que a carga variável não inclui um cabeçalho variável.
14. Método conforme a realização 13, em que o cabeçalho fixo inclui um campo de identificação (ID) de MIHF.
15. Método conforme qualquer das realizações 13 e 14, em que o cabeçalho fixo inclui um campo de identificação (ID) de sessão.
16. Método conforme qualquer das realizações 13 a 15, em que o cabeçalho fixo inclui um campo de marca.
17. Método conforme a realização 16, que compreende adicionalmente a definição do campo de marca como um para indicar que a carga variável contém dados.
18 Método conforme a realização 16, que compreende adicionalmente a definição do campo de marca como zero para indicar que a carga variável não contém dados.
19. Método conforme qualquer das realizações 13 a 18, em que a carga variável inclui um campo de tipo, um campo de comprimento e um campo de valor.
20. Método conforme a realização 19, em que o campo de valor inclui um tipo de link específico para obter uma lista de operadores.
21. Método conforme qualquer das realizações 13 a 20, em que o sistema de comunicação é um sistema de comunicação sem fio, o primeiro transceptor é uma unidade de transmissão e recepção sem fio (WTRU) e o segundo transceptor é uma estação base.
22. Método conforme qualquer das realizações 13 a 20, em que o sistema de comunicação é um sistema de comunicação sem fio, o primeiro transceptor é uma estação base e o segundo transceptor é uma unidade de transmissão e recepção sem fio (WTRU).
23. Método conforme qualquer das realizações 13 a 20, em que o sistema de comunicação é um sistema de comunicação com fios que utiliza Ethernet para fornecer uma conexão física.
24. Em um sistema de comunicação que inclui um primeiro transceptor e um segundo transceptor, método de comunicação de mensagens de entrega independente de meios (MIH) que compreende a geração pelo primeiro transceptor de um quadro de função de MIH (MIHF) que inclui dados de serviços de MIH ou um cabeçalho variável representado por um campo de tipo, um campo de comprimento e um campo de valor, em que o comprimento do campo de valor é exatamente de 128 octetos e o campo de comprimento ocupa apenas um octeto; e envio pelo primeiro transceptor do quadro de MIHF para o segundo transceptor.
25. Método conforme a realização 24, em que um bit mais significativo (MSB) do octeto ocupado pelo campo de comprimento é definido como um valor de um e sete bits remanescentes do octeto ocupado pelo campo de comprimento que seguem o MSB são configurados em um valor de zero.
26. Transceptor que compreende:
- um receptor;
- um transmissor; e
- um processador acoplado ao receptor e ao transmissor, em que o processador é configurado para gerar um quadro de solicitação de função de entrega independente de meios (MIHF), o quadro de solicitação de MIHF inclui um cabeçalho fixo e uma carga variável, em que a carga variável não inclui um cabeçalho variável e o transmissor emite o quadro de solicitação de MIHF gerado pelo processador.
27. Transceptor conforme a realização 26, em que o cabeçalho fixo inclui um campo de identificação (ID) de MIHF.
28. Transceptor conforme qualquer das realizações 26 e 27, em que o cabeçalho fixo inclui um campo de identificação (ID) de sessão.
29. Transceptor conforme qualquer das realizações 26 a 28, em que o cabeçalho fixo inclui um campo de marca.
30. Transceptor conforme a realização 29, em que o processador define o campo de marca como um para indicar que existe um reconhecimento acumulado no quadro de solicitação de MIHF que contém um payload.
31. Transceptor conforme qualquer das realizações 26 a 30, em que o processador define o campo de marca como zero para indicar que não há payload em um campo de payload variável.
32. Transceptor conforme qualquer das realizações 26 a 31, em que a carga variável inclui um campo de tipo, um campo de comprimento e um campo de valor.
33. Transceptor conforme a realização 32, em que o campo de valor inclui um tipo de link específico para a obtenção de uma lista de operadores.
34. Transceptor conforme qualquer das realizações 26 a 33, em que o transceptor é uma unidade de transmissão e recepção sem fio (WTRU).
35. Transceptor conforme qualquer das realizações 26 a 33, em que o transceptor é uma unidade de transmissão e recepção com fio.
36. Transceptor conforme qualquer das realizações 26 a 33, em que o transceptor é uma estação base.
37. Transceptor que compreende:
- um receptor configurado para receber um quadro de solicitação de função de entrega independente de meios (MIHF);
- um transmissor; e
- um processador acoplado ao receptor e ao transmissor, em que o processador é configurado para gerar um quadro de resposta de MIHF em resposta ao recebimento pelo receptor do quadro de solicitação de MIHF, o quadro de resposta de MIHF inclui um cabeçalho fixo e uma carga variável, em que a carga variável não inclui um cabeçalho variável e o transmissor emite o quadro de resposta de MIHF gerado pelo processador.
38. Transceptor conforme a realização 37, em que o cabeçalho fixo inclui um campo de identificação (ID) de MIHF.
39. Transceptor conforme qualquer das realizações 37 e 38, em que o cabeçalho fixo inclui um campo de identificação (ID) de sessão.
40. Transceptor conforme qualquer das realizações 37 a 39, em que o cabeçalho fixo inclui um campo de marca.
41. Transceptor conforme a realização 40, em que o processador define o campo de marca como um para indicar que existe um reconhecimento acumulado no quadro de solicitação de MIHF que contém um payload.
42. Transceptor conforme a realização 41, em que o processador define o campo de marca como zero para indicar que não existe payload em um campo de payload variável.
43. Transeeptor conforme qualquer das realizações 37 a 42, em que a carga variável inclui um campo de tipo, um campo de comprimento e um campo de valor.
44. Transceptor conforme a realização 43, em que o campo de valor inclui um tipo de link específico para obtenção de uma lista de operadores.
45. Transceptor conforme qualquer das realizações 37 a 44, em que o transceptor é uma unidade de transmissão e recepção sem fio (WTRU).
46. Transceptor conforme qualquer das realizações 37 a 44, em que o transceptor é uma unidade de transmissão e recepção com fio.
47. Transceptor conforme qualquer das realizações 37 a 44, em que o transceptor é uma estação base.
48. Transceptor que compreende:
- um receptor;
- um transmissor; e
- um processador acoplado ao receptor e ao transmissor, em que o processador é configurado para gerar um quadro de função de entrega independente de meios (MIHF) que inclui dados de serviço ou um cabeçalho variável representado por um campo de tipo, um campo de comprimento e um campo de valor, em que o comprimento do campo de valor é de exatamente 128 octetos e o campo de comprimento ocupa apenas um octeto, em que o transmissor emite o quadro de MIHF gerado pelo processador.
49. Transceptor conforme a realização 48, em que um bit mais significativo (MSB) do octeto ocupado pelo campo de comprimento é definido como um valor de um e sete bits remanescentes do octeto ocupado pelo campo de comprimento que segue o MSB são definidos como um valor de zero.
Embora as características e os elementos da presente invenção sejam descritos nas realizações preferidas em combinações específicas, cada característica ou elemento pode ser utilizado isoladamente, sem as demais características e elementos das realizações preferidas ou em várias combinações com ou sem outras características e elementos da presente invenção. Os métodos ou gráficos de fluxo fornecidos na presente invenção podem ser implementados em um programa de computador, software ou firmware em realização tangível em um meio de armazenagem legível por computador para execução por um processador ou computador para uso geral. Exemplos de meios de armazenagem legíveis por computador incluem memória somente de leitura (ROM), memória de acesso aleatório (RAM), registro, memória de cache, dispositivos de memória semicondutores, meios magnéticos tais como discos rígidos internos e discos removíveis, meios magnetoóticos e meios óticos tais como discos CD-ROM e discos versáteis digitais (DVDs).
Processadores apropriados incluem, por exemplo, um processador para uso geral, processador para fins especiais, processador convencional, processador de sinais digitais (DSP), uma série de microprocessadores, um ou mais microprocessadores em associação com um núcleo de DSP, controlador, microcontrolador, Circuitos Integrados Específicos de Aplicação (ASICs), circuitos de Conjuntos de Portal Programáveis de Campo (FPGAs), qualquer outro tipo de circuito integrado (IC) e/ou máquina de estado.
Um processador em associação com software pode ser utilizado para implementar um transceptor de rádio freqüência para uso em uma unidade de transmissão e recepção sem fio (WTRU), equipamento de usuário (UE), terminal, estação base, controlador de rede de rádio (RNC) ou qualquer computador host. A WTRU pode ser utilizada em conjunto com módulos, implementada em hardware e/ou software, tal como uma câmera, módulo de câmera de vídeo, videofone, fone de ouvido, dispositivo de vibração, alto-falante, microfone, transceptor de televisão, fone de ouvido para mãos livres, teclado, módulo Bluetooth®, unidade de rádio em freqüência modulada (FM), unidade de visor de cristal líquido (LCD), unidade de visor de diodo emissor de luz orgânico (OLED), aparelho de música digital, aparelho de mídia, módulo de vídeo game, navegador da Internet e/ou qualquer módulo de rede de área local sem fio (WLAN).
Claims (5)
1. Método de comunicação de mensagens de entrega independente de meios (MIH)1 em que o método é caracterizado por compreender: - geração de um quadro de MIH (MIH[[F]]) que inclui dados de serviços de MIH ou um cabeçalho variável representado por um campo de tipo, um campo de comprimento e um campo de valor, em que o campo de valor é exatamente de 128 octetos, o campo de comprimento é de apenas um octeto e um bit mais significativo (MSB) do campo de comprimento é definido como um valor de um e sete bits remanescentes do campo de comprimento que se seguem ao MSB são definidos como um valor de zero.
2. Unidade de transmissão e recepção sem fio (WTRU) que é caracterizada por compreender: - um processador configurado para gerar um quadro de de entrega independente de meios (MIH[[F]]) que inclui dados de serviço ou um cabeçalho variável representado por um campo de tipo, um campo de comprimento e um campo de valor, em que um comprimento do campo de valor é de exatamente 128 octetos, o campo de comprimento ocupa apenas um octeto e um bit mais significativo (MSB) do octeto ocupado pelo campo de comprimento é definido como um valor de um e sete bits remanescentes do octeto ocupado pelo campo de comprimento que se segue ao MSB são definidos como um valor de zero; e - um transmissor configurado para emitir o quadro de MIH gerado pelo processador.
3. Método de criação de elementos de informação (IEs) de entrega independente de meios (MIH) que possuem um campo de tipo, um campo de comprimento e um campo de valor, em que o método é caracterizado por compreender: - determinação de um número de octetos de dados a serem incluídos no campo de valor do IE; - definição do campo de comprimento do IE1 em que: - quando o número de octetos de dados for de menos de 128 octetos, o campo de comprimento possui um octeto de comprimento e um bit mais significativo (MSB) do campo de comprimento é definido como um valor de zero e sete bits remanescentes do campo de comprimento que se seguem ao MSB indicam o número de octetos de dados no campo de dados do IE; - quando o número de octetos de dados for de exatamente 128 octetos, o campo de comprimento possui um octeto de comprimento e o MSB do campo de comprimento é definido como um valor de um e sete bits remanescentes do campo de comprimento que se seguem ao MSB são definidos como um valor de zero; e - quando o número de octetos de dados for maior que 128 octetos, o campo de comprimento é maior que um octeto, o MSB de um primeiro octeto do campo de comprimento é definido como um valor de um sete bits remanescentes do primeiro octeto do campo de comprimento indicam um número de octetos adicionais do campo de comprimento e os octetos adicionais do campo de comprimento, quando adicionados a um valor de 128, indicam o número de octetos de dados no campo de valor do IE.
4. Unidade de transmissão de recepção sem fio que é caracterizada por compreender: - um processador configurado para: - definir um campo de comprimento de elemento de informação (IE) de entrega independente de meios (MIH) como um octeto de comprimento e um bit mais significativo (MBS) do campo de comprimento como um valor de zero e sete bits remanescentes do campo de comprimento que se seguem ao MSB indicam um número de octetos de dados em um campo de valor do IE1 quando o número de octetos de dados for menor que 128 octetos; - definir o campo de comprimento de IE MIH como um octeto de comprimento e o MSB do campo de comprimento como um valor de um e sete bits remanescentes do campo de comprimento que seguem o MSB como um valor de zero, quando o número de octetos de dados é de exatamente 128 octetos; e - definir o campo de comprimento de IE MIH como mais de um octeto e o MSB de um primeiro octeto do campo de comprimento como um valor de um, sete bits remanescentes do primeiro octeto do campo de comprimento indicam um número de octetos adicionais do campo de comprimento e os octetos adicionais do campo de comprimento, quando adicionados a um valor de 128, indicam o número de octetos de dados no campo de valor do IE, quando o número de octetos de dados for maior que 128 octetos.
5. WTRU conforme a reivindicação 4 que é caracterizada por compreender adicionalmente um transmissor acoplado ao processador e configurado para transmitir o IE MIH.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US81355006P | 2006-06-14 | 2006-06-14 | |
| US60/813,550 | 2006-06-14 | ||
| PCT/US2007/013421 WO2007146064A2 (en) | 2006-06-14 | 2007-06-07 | Efficient media independent handover protocol operation enhancements |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0712002A2 true BRPI0712002A2 (pt) | 2012-02-14 |
Family
ID=38669351
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0712002-8A BRPI0712002A2 (pt) | 2006-06-14 | 2007-06-07 | aprimoramentos de operação de protocolo de entrega independente de meios eficiêntes |
Country Status (15)
| Country | Link |
|---|---|
| US (1) | US8331313B2 (pt) |
| EP (1) | EP2036391B1 (pt) |
| JP (1) | JP5038406B2 (pt) |
| KR (2) | KR101391902B1 (pt) |
| CN (2) | CN101467473A (pt) |
| AR (1) | AR061457A1 (pt) |
| AU (1) | AU2007258544B2 (pt) |
| BR (1) | BRPI0712002A2 (pt) |
| CA (1) | CA2654906C (pt) |
| DE (1) | DE202007008260U1 (pt) |
| IL (1) | IL195744A (pt) |
| MX (1) | MX2008015859A (pt) |
| RU (1) | RU2009100925A (pt) |
| TW (3) | TWI444004B (pt) |
| WO (1) | WO2007146064A2 (pt) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8165088B2 (en) * | 2006-09-13 | 2012-04-24 | Toshiba America Research, Inc. | MIH protocol state machine |
| KR100933163B1 (ko) * | 2006-12-19 | 2009-12-21 | 삼성전자주식회사 | 통신 시스템에서 핸드오버 장치 및 방법 |
| KR20080064699A (ko) * | 2007-01-05 | 2008-07-09 | 삼성전자주식회사 | 이동 정보를 가지는 네트워크 장치 및 네트워크 장치 간이동 정보 교환 방법 |
| EP2151132A4 (en) * | 2007-05-11 | 2011-07-27 | Toshiba Kk | DATA TYPE CODING FOR MEDIA-INDEPENDENT HANDOVER |
| KR101461948B1 (ko) * | 2007-06-06 | 2014-11-14 | 엘지전자 주식회사 | 무선 접속 시스템에서 mih 프로토콜 메시지 전송방법 |
| US20090154446A1 (en) * | 2007-12-14 | 2009-06-18 | Infineon Technologies Ag | Data frame, telegram, method for controlling an rf-transceiver and mobile communication system |
| KR101181624B1 (ko) | 2008-09-10 | 2012-09-10 | 한국전자통신연구원 | 광대역 고주파수 무선 시스템에서 가변 길이 헤더 정보 보호를 위한 프레임 생성 장치 및 방법 |
| US8630309B2 (en) | 2008-09-10 | 2014-01-14 | Electronics And Telecommunications Research Institute | Frame generation apparatus and method of protecting protocol header information over wideband high frequency wireless system |
| US20100185734A1 (en) * | 2009-01-19 | 2010-07-22 | Moxa Inc. | Method for processing response messages |
| CN102843345B (zh) * | 2011-06-24 | 2015-07-22 | 中磊电子(苏州)有限公司 | 远程沟通方法及其计算机程序产品 |
| US9923808B2 (en) * | 2012-10-09 | 2018-03-20 | Netscout Systems, Inc. | System and method for real-time load balancing of network packets |
| CN104782179B (zh) * | 2013-09-25 | 2019-12-06 | 华为技术有限公司 | 切换方法及装置 |
| CN106922035B (zh) * | 2015-12-28 | 2019-04-16 | 华为技术有限公司 | 一种传输机会控制方法及装置 |
| TWI618399B (zh) * | 2016-03-17 | 2018-03-11 | 夏普股份有限公司 | 用於接收一浮水印訊息之方法以及含經組態以接收一浮水印訊息之一處理器之裝置 |
| GB201817781D0 (en) * | 2018-10-31 | 2018-12-19 | V Nova Int Ltd | Mehods, apparatuses, computer programs and computer-readable media |
| US11516320B2 (en) | 2020-12-23 | 2022-11-29 | Itron, Inc. | Frame compatibility across network protocol versions |
| CN113179119B (zh) * | 2021-04-25 | 2022-04-19 | 广州爱浦路网络技术有限公司 | 天地一体化融合网络系统、消息传输方法和核心网系统 |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6377809B1 (en) | 1997-09-16 | 2002-04-23 | Qualcomm Incorporated | Channel structure for communication systems |
| US6397259B1 (en) | 1998-05-29 | 2002-05-28 | Palm, Inc. | Method, system and apparatus for packet minimized communications |
| FI106504B (fi) * | 1998-10-06 | 2001-02-15 | Nokia Networks Oy | Datan segmentointimenetelmä tietoliikennejärjestelmässä |
| GB9919851D0 (en) | 1999-08-20 | 1999-10-27 | Lucent Technologies Inc | Core network allocation for gsm/umts |
| DE10117628A1 (de) * | 2001-04-07 | 2002-10-10 | Alcatel Sa | Verfahren zum Betreiben eines funkbasierten Telekommunikationssystems |
| MXPA03005133A (es) | 2001-11-14 | 2004-04-02 | Matsushita Electric Industrial Co Ltd | Dispositivo de codificacion, dispositivo de decodificacion y sistema de los mismos. |
| US7483984B1 (en) | 2001-12-19 | 2009-01-27 | Boingo Wireless, Inc. | Method and apparatus for accessing networks by a mobile device |
| US7647421B2 (en) | 2002-08-20 | 2010-01-12 | Nokia Corporation | Extension header compression |
| DE60223806T2 (de) * | 2002-09-16 | 2008-10-30 | Agilent Technologies, Inc. - a Delaware Corporation -, Santa Clara | Messung von Netzwerkparametern wie sie von nicht künstlichem Netzwerkverkehr wahrgenommen werden |
| US7496364B2 (en) | 2004-11-05 | 2009-02-24 | Freescale Semiconductor, Inc. | Media-independent handover (MIH) method featuring a simplified beacon |
| KR100755691B1 (ko) | 2005-06-28 | 2007-09-05 | 삼성전자주식회사 | 이동 노드의 핸드오버 수행 방법 및 이를 위한 네트워크 시스템 |
-
2007
- 2007-06-06 US US11/758,712 patent/US8331313B2/en not_active Expired - Fee Related
- 2007-06-07 KR KR1020097001232A patent/KR101391902B1/ko not_active Expired - Fee Related
- 2007-06-07 CA CA2654906A patent/CA2654906C/en not_active Expired - Fee Related
- 2007-06-07 RU RU2009100925/09A patent/RU2009100925A/ru not_active Application Discontinuation
- 2007-06-07 KR KR1020087031986A patent/KR100990922B1/ko not_active Expired - Fee Related
- 2007-06-07 BR BRPI0712002-8A patent/BRPI0712002A2/pt not_active IP Right Cessation
- 2007-06-07 MX MX2008015859A patent/MX2008015859A/es active IP Right Grant
- 2007-06-07 EP EP07809385.3A patent/EP2036391B1/en not_active Not-in-force
- 2007-06-07 WO PCT/US2007/013421 patent/WO2007146064A2/en not_active Ceased
- 2007-06-07 JP JP2009515426A patent/JP5038406B2/ja not_active Expired - Fee Related
- 2007-06-07 TW TW099121322A patent/TWI444004B/zh not_active IP Right Cessation
- 2007-06-07 TW TW096120609A patent/TWI433499B/zh not_active IP Right Cessation
- 2007-06-07 CN CNA2007800215745A patent/CN101467473A/zh active Pending
- 2007-06-07 TW TW096209401U patent/TWM324358U/zh not_active IP Right Cessation
- 2007-06-07 AU AU2007258544A patent/AU2007258544B2/en not_active Ceased
- 2007-06-13 DE DE202007008260U patent/DE202007008260U1/de not_active Expired - Lifetime
- 2007-06-14 AR ARP070102605A patent/AR061457A1/es unknown
- 2007-06-14 CN CNU2007201525498U2007201525498U patent/CN201097448Y/zh not_active Expired - Fee Related
-
2008
- 2008-12-04 IL IL195744A patent/IL195744A/en not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| CN201097448Y (zh) | 2008-08-06 |
| EP2036391A2 (en) | 2009-03-18 |
| CA2654906A1 (en) | 2007-12-21 |
| KR101391902B1 (ko) | 2014-05-07 |
| CA2654906C (en) | 2013-07-30 |
| WO2007146064A2 (en) | 2007-12-21 |
| JP5038406B2 (ja) | 2012-10-03 |
| TWI433499B (zh) | 2014-04-01 |
| EP2036391B1 (en) | 2013-11-06 |
| DE202007008260U1 (de) | 2007-11-22 |
| AU2007258544B2 (en) | 2011-05-26 |
| TWI444004B (zh) | 2014-07-01 |
| US8331313B2 (en) | 2012-12-11 |
| TWM324358U (en) | 2007-12-21 |
| JP2009540749A (ja) | 2009-11-19 |
| US20080008131A1 (en) | 2008-01-10 |
| IL195744A0 (en) | 2009-09-01 |
| KR20090031429A (ko) | 2009-03-25 |
| CN101467473A (zh) | 2009-06-24 |
| IL195744A (en) | 2013-06-27 |
| TW200746726A (en) | 2007-12-16 |
| TW201123781A (en) | 2011-07-01 |
| RU2009100925A (ru) | 2010-07-20 |
| MX2008015859A (es) | 2009-01-26 |
| WO2007146064A3 (en) | 2008-04-03 |
| KR20090026168A (ko) | 2009-03-11 |
| AU2007258544A1 (en) | 2007-12-21 |
| AR061457A1 (es) | 2008-08-27 |
| KR100990922B1 (ko) | 2010-11-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0712002A2 (pt) | aprimoramentos de operação de protocolo de entrega independente de meios eficiêntes | |
| ES2619302T3 (es) | Operación de unidades de datos de protocolo de control en protocolo de convergencia de datos de paquetes | |
| CN104247513B (zh) | 用于高效服务发现的方法、装置 | |
| RU2010105049A (ru) | Состыковывание mip/pmip, когда используется перекрывающееся адресное пространство | |
| CN106982473A (zh) | 传输通道的建立方法、移动性管理实体、网元设备及系统 | |
| JP4235178B2 (ja) | 多重パケット・データ・サービス接続をサポートするための方法及び装置 | |
| TW200830731A (en) | Message compression methods and apparatus | |
| EP3804407B1 (en) | Methods and nodes for facilitating non-ip ue-to-ue communications | |
| JP2011508551A (ja) | 複数の無線ネットワークに同時にアクセスするための装置及び方法 | |
| CN101569157A (zh) | 移动接入 | |
| JP5362732B2 (ja) | マルチホーミング・プロトコルのためのサポート | |
| ATE333179T1 (de) | Verfahren und system zur bereitstellung von netzwerkdiensten | |
| WO2014166078A1 (zh) | 数据发送处理方法及路由器 | |
| TW200807988A (en) | Configuring a host device by way of MMP | |
| CN101204111A (zh) | 用以发现802.21远程事件和信息服务的机制 | |
| CN119054409B (zh) | 通信方法、装置、设备、存储介质、芯片、产品及程序 | |
| JP3676347B2 (ja) | Ipアドレス管理装置及びipアドレス管理方法、コンピュータプログラム | |
| KR101221596B1 (ko) | 무선 네트워크에서 액세스 라우터에 ip 어드레스를공지하기 위한 휴대 단말기 및 방법 | |
| KR20090128224A (ko) | 통신 네트워크에서 메시지 송수신 방법 및 시스템 | |
| HK1129984A (en) | Efficient media independent handover protocol operation enhancements | |
| KR20060107413A (ko) | 무선 통신 시스템에서 연결된 프레임을 송신하는 방법 및장치 | |
| KR200419293Y1 (ko) | 무선 통신 시스템에서 연결된 프레임을 송신하는 장치 | |
| KR20070008437A (ko) | 인터넷 프로토콜 버전6 기반의 저전력 무선 개인 영역네트워크를 위한 심플 서비스 로케이션 프로토콜 시스템 및그 구현방법 | |
| WO2009137994A1 (zh) | 接入网关绑定建立方法和系统 | |
| JP2007300466A (ja) | 無線通知システム、無線通知装置、無線通知方法、コンピュータプログラム及び記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B25G | Requested change of headquarter approved |
Owner name: INTERDIGITAL TECHNOLOGY CORPORATION (US) |
|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE A 9A ANUIDADE. |
|
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |
Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2385 DE 20-09-2016 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013. |