BRPI0807057B1 - Método e transceptor para uso em um sistema de comunicações celular - Google Patents

Abstract

MÉTODO E TRANSCEPTOR PARA USO EM UM SISTEMA DE COMUNICAÇÃO CELULAR. A invenção expõe um método (700) para um sistema celular (100), no qual trafego pode ser trocado entre primeiro (110, 120) e segundo (110, 120) transceptores. O trafego é enviado em unidades de dados, a cada uma das quais é dado um identificador, e quais unidades de dados podem ser divididas em segmentos. Um transceptor receptor (110, 120) pode enviar informação de estado em quadros de dados ou unidades de dados (200, 300) sobre unidades de dados corretamente recebidas, parcialmente recebidas, ou não recebidas a um transceptor remetente, isto 6, 0 transceptor do qual os dados foram enviados. No caso (705) de unidades de dados parcialmente ou não recebidas, a informação de estado inclui (710) informação sobre se anuidade ou unidades de dados eram não recebidas ou parcialmente recebidas, e no caso de uma ou mais unidades de dados parcialmente recebidas (715), partes dessas unidades de dados que não eram recebidas.

Description

CAMPO TÉCNICO

[001] A presente invenção expõe um método para uso em um sistema de comunicações celular, no qual tráfego de sistema pode ser trocado entre um primeiro e um segundo transceptores. O tráfego é enviado em unidades de dados, a cada uma das quais é dado um identificador e que pode ser dividida em segmentos. Um transceptor receptor pode enviar informação de estado em quadros de dados ou unidades de dados sobre unidades de dados transmitidas para um transceptor transmissor, isto é, para o transceptor do qual os dados eram transmitidos.

FUNDAMENTO

[002] No projeto de 3GPP LTE (Projeto de Sociedade de 3a geração, Evolução a Longo Prazo) para sistemas de comunicação celulares, um protocolo de RLC (Controle de Ligação de Rádio) é usado para comunicação entre usuários em uma célula e o nó controlador da célula, isto é, o denominado eNodeB, "NodeB evoluído".

[003] No RLC, tráfego é enviado como denominadas PDUs, isto é, Unidades de Dados de Protocolo, que são identificadas sendo dados números de sequência. Em resposta a PDUs de uma parte transmissora, a parte receptora envia denominadas PDUs de estado de RLC para a parte transmissora, com denominados ACKs e/ou NACKS, isto é, reconhecimentos (ACK) que dados foram recebidos corretamente, ou informação (NACK) que dados não foram recebidos corretamente, isto é, recebidos só parcialmente ou de modo algum. Os ACKs e NACKs nas PDUs de estado de RLC são enviados como números de sequência de PDU a fim de identificar a PDU em questão.

[004] Em sistemas de LTE, PDUs de RLC podem ser segmentadas, que tem como uma consequência que haverá dois ou mais segmentos de PDU com o mesmo número de sequência, desde que o número de sequência é uma propriedade da PDU. O processo de segmentar PDUs também é denotado como re-segmentação.

[005] Por causa da re-segmentação em LTE, os números de sequência não bastarão para identificar os dados para quais ACK ou NACK é enviado.

SUMÁRIO

[006] Como emergiu da explicação acima, há uma necessidade por uma solução por meio da qual ACKs e NACKs que são transmitidos por uma parte receptora para uma parte remetente em sistemas de 3G LTE podem ser identificados, com respeito aos segmentos de dados para quais eles são enviados em resposta.

[007] Além disso, outra necessidade que deveria ser tratada pela solução em questão é que deveria ser possível enviar um número variável de NACKs.

[008] Esta necessidade é tratada pela presente invenção visto que ela expõe um método para uso em um sistema de comunicações celular, no qual tráfego de sistema pode ser trocado entre um primeiro e um segundo transceptores. O tráfego no sistema é enviado em unidades de dados, a cada uma das quais é dado um identificador. As unidades de dados podem ser divididas em segmentos, e um transceptor receptor pode enviar informação de estado em quadros de dados ou unidades de dados sobre unidades de dados corretamente recebidas, parcialmente recebidas, ou não recebidas a um transceptor remetente, isto é, para o transceptor do qual os dados foram enviados.

[009] De acordo com o método da invenção, no caso de uma ou mais unidades de dados parcialmente ou não recebidas, a informação de estado que é enviada ao transceptor remetente inclui informação sobre se as unidades de dados foram não recebidas ou parcialmente recebidas, e no caso de uma unidade de dados parcialmente recebida, que partes das unidades de dados que não foram recebidas.

[0010] Assim, por meio da invenção, se torna possível para o transceptor receptor identificar distintamente partes de unidades de dados não recebidas ao transceptor remetente, assim habilitando por sua vez o transceptor remetente retransmitir essas partes.

[0011] Também, a invenção torna possível identificar mais ou menos qualquer quantidade de dados não recebidos, que era outra das necessidades a serem tratadas pela invenção.

[0012] Em uma concretização da invenção, a informação sobre se ou não uma unidade de dados foi não recebida ou parcialmente recebida é incluída como um indicador em ditos quadros de dados ou unidades de dados.

[0013] Em outra concretização, a informação sobre a cujas partes de uma unidade de dados que foram não recebidas é incluída nos quadros de dados ou unidades de dados como informação que indica uma primeira e uma última parte dos dados não recebidos.

[0014] Em ainda outro aspecto da presente invenção, no caso que um quadro de dados ou unidade do transceptor remetente foi segmentada e um ou mais últimos segmentos não alcançaram o transceptor receptor, isto pode ser indicado pelo transceptor receptor.

[0015] Em uma concretização adicional da invenção, a informação sobre cujas partes de uma unidade de dados que foram não recebidas é incluída nos quadros de dados ou unidades de dados como informação que indica o identificador da unidade de dados, como também informação sobre o começo dos dados não recebidos em dita unidade de dados, e a quantidade de dados não recebidos.

[0016] Estes e outros aspectos e vantagens da presente invenção serão explicadas em mais detalhe na explicação detalhada dada abaixo.

[0017] A invenção também expõe um transceptor para uso em um sistema da invenção.

BREVE DESCRIÇÃO DOS DESENHOS

[0018] A invenção será descrita em mais detalhe no seguinte, com referência aos desenhos anexos, em que: Figura 1 mostra uma vista esquemática de um sistema no qual a invenção pode ser aplicada; e Figuras 2-6 mostram várias concretizações da invenção; e Figura 7 mostra um fluxograma esquemático de um método da invenção; e Figura 8 mostra um diagrama de bloco de um transceptor da invenção.

DESCRIÇÃO DETALHADA

[0019] Figura 1 mostra uma vista esquemática de um sistema 100 no qual a invenção pode ser aplicada. Como mencionado previamente, a invenção é planejada principalmente para sistemas do tipo de 3GPP LTE, isto é, sistemas do Projeto de Sociedade de Terceira Geração, Evolução a Longo Prazo, às vezes também referido somente como sistemas de LTE, mas oficialmente em 3GPP conhecido como UTRAN evoluído ou E-UTRAN. Estes nomes serão usados intercambiavelmente ao longo desta descrição.

[0020] Como mostrado na Figura 1, um sistema de LTE 100 pode incluir várias denominadas células, uma das quais é mostrada como 130 na Figura 1. Cada célula em um sistema de LTE pode acomodar vários usuários, às vezes chamados genericamente UEs, Equipamentos de Usuário. Na Figura 1, um UE é mostrado simbolicamente, com a número de referência 120.

[0021] Sistemas de LTE como o 100 na Figura 1 também incluirão um denominado "eNodeB", NodeB evoluído, para cada célula. Uma das funções do eNodeB de uma célula é controlar o tráfego para e de usuários em uma célula. Na Figura 1, um eNodeB 110 é mostrado como o eNodeB para a célula 130.

[0022] Tráfego do eNodeB para um UE é chamado tráfego de ligação inferior, ou simplesmente tráfego de DL, e tráfegos dos UEs ao eNodeB é conhecido como tráfego de ligação superior, ou simplesmente tráfego de UL.

[0023] Em sistemas de LTE, um protocolo de RLC. Controle de Ligação de Rádio, é usado para comunicação entre o eNodeB e os UEs em uma célula.

[0024] De acordo com RLC, em sistemas de LTE, tráfego entre dois transceptores, isto é, um UE e seu eNodeB é enviado em denominadas PDUs, Unidades de Dados de Protocolo. De acordo com RLC, a cada PDU é nomeada um identificador, um denominado número de sequência, que permite ambas a parte remetente e a receptora identificarem uma PDU.

[0025] Na descrição abaixo, será assumido que PDUs de dados são enviadas pelo eNodeB, isto é, em DL, e que PDUs de estado são enviadas por um UE, isto é, em UL. Porém, deveria ser mostrado que isto é somente um exemplo pretendido para facilitar o entendimento do leitor da invenção, a invenção pode ser aplicada igualmente bem na outra direção, isto é, PDUs de Dados em UL e PDUs de Estado em DL. Pode ser mencionado aqui que E- UTRAN RLC pode operar em modos diferentes, configurados pelo eNodeB, isto é Modo Reconhecido (AM), Modo Não Reconhecido (UM) e modo transparente (TM). As PDUs de estado são usadas no momento só em AM.

[0026] Se o eNodeB 110 enviar uma PDU que contém dados ao UE 120, isto é, uma denominada PDU de dados, o UE pode responder com uma denominada PDU de estado, isto é, uma PDU que indica ao eNodeB o estado de recepção dos dados na PDU de dados que foi enviada do eNodeB.

[0027] Na PDU de estado para o eNodeB, unidades de dados que são recebidas corretamente pelo UE são reconhecidas pelo UE por meio de denominadas mensagens de ACK ou indicadores, e unidades de dados que são recebidas erroneamente, isto é, só recebidas em parte, ou não recebidas de modo algum são indicadas pelo UE por meio de um denominado ACK negativo, um NACK. Se o eNodeB do qual os dados se originam receber um NACK em troca para dados transmitidos, o eNodeB saberá assim que esta informação deveria ser retransmitida, normalmente até que um ACK seja recebido. No caso de dados de tráfego de DL, um UE assim enviará PDUs de estado com ACKs e/ou NACKs para o eNodeB em resposta a PDUs de dados do eNodeB.

[0028] Os ACKs provêem informação sobre até qual número de sequência PDUs foram recebidas corretamente. Isto tanto pode ser feito tanto provendo o número mais alto de uma PDU recebida com sucesso, ou o primeiro número de uma PDU não recebida.

[0029] Em E-UTRAN RLC, PDUs de dados podem ser re- segmentadas, isto é, a carga útil de uma PDU de RLC previamente criada pode, na hora de retransmissão, ser dividida em segmentos que são enviados separadamente.

[0030] Em LTE, é planejado que segmentos de PDU de RLC deveriam ser identificados por meio do número de sequência da PDU de RLC original, como também uma denominada compensação de segmentação, SO, que indica o começo dos segmentos na PDU de RLC original. Um ACK ou um NACK é enviado na forma do número de sequência da PDU de RLC original, mas desde que re-segmentação pode ocorrer, os segmentos aos quais o ACK ou NACK do UE se referem não podem ser identificados exclusivamente no eNodeB por meio do número de sequência, e nem mesmo por meio da SO, devido ao fato que a segmentação pode ocorrer em várias "gerações", isto é, múltiplas re-segmentações podem ocorrer, e o eNodeB não sabe à qual geração os ACK/NACKs se referem.

[0031] É este problema, isto é, identificação de dados de PDU de RLC ACK/NACK:ed que a invenção pretende tratar.

[0032] Casos diferentes podem ser discernidos quando vem a PDUs de estado: a. Uma PDU de estado só com um ACK, e nenhum NACK. b. Uma PDU de estado com um ACK e um ou mais NACKs, que tem dois subcasos: i. Um ou mais do NACKs são "NACKs de segmento". ii. Todos os NACKs são NACKs de não segmento.

[0033] A fim de tratar o caso "a" anterior, a invenção propõe uma PDU de estado que é mostrada na Figura 2 com o número de referência 200. Como mostrado na Figura 2, a PDU de estado 200 inclui um campo de D/C 210, que indica se a PDU 200 é uma PDU de dados ou de controle. Como será entendido, uma PDU de estado é uma PDU de controle.

[0034] Além disso, a PDU de estado 200 inclui um campo de ACK 220, com o ACK sendo provido na forma do número de sequência, SN, da PDU de RLC à qual o ACK se refere. A PDU de estado 200 também inclui um indicador, por exemplo uma indicação ou bit, mostrado na Figura 2 como um "bit E" 230, que é usado para indicar a presença ou ausência de NACKs na PDU de estado 200.

[0035] No caso de ausência de NACKs na PDU de estado, isto é, o caso mostrado na Figura 2, denominado "enchimento" ou "bits falsos" podem ser usados a fim de alcançar alinhamento correto dos conteúdos da PDU de estado 200. Um exemplo de tal alinhamento é o denominado "alinhamento de octeto", isto é, alinhamento que é usado se a PDU de estado for dividida em octetos de dados. O enchimento é mostrado como 240 na Figura 2.

[0036] Retornando agora ao caso identificado como "b-i" acima, isto é, onde um ou mais do NACKs se referem a unidades de dados segmentadas, em outras palavras, o caso no qual os NACKs indicam que uma unidade de dados foi recebida parcialmente, um conceito usado pela invenção será introduzido agora. Este conceito é chamado aqui "pares de Compensação de Segmento" ou "pares SO", isto é, um par de dados, um dos quais é usado para indicar o primeiro octeto de dados não recebido da PDU à qual o NACK se refere, e o outro de qual é usado para indicar o último octeto de dados não recebidos ao qual o NACK se refere. Pode ser acrescentado aqui que embora octetos sejam usados para exemplificar a invenção, desde que octetos são usados em LTE RLC, a invenção pode ser usada naturalmente se dados forem enviados em outros tamanhos igualmente.

[0037] Um exemplo de um formato de PDU de estado 300 que pode operar caso "b-i" acima é mostrado na Figura 3. Em semelhança ao formato de PDU de Estado 200 da Figura 2, o formato de PDU de Estado 300 inclui um campo que indica se a PDU 300 é uma PDU de dados ou de controle, e um campo de ACK com o ACK sendo provido na forma do número de sequência, SN, da PDU de RLC à qual o ACK se refere.

[0038] A PDU de estado 300 também inclui um indicador, por exemplo uma indicação ou bit, mostrado na Figura 3 como um "bit E", que é usado para indicar a presença ou ausência de NACKs na PDU de estado 300.

[0039] Se um ou mais NACKs forem incluídos, como na Figura 3, cada NACK é seguido por um bit "E" ou indicação e um bit "F" ou indicação, onde o bit/indicação E indica se outro NACK está presente ou não, e o bit/indicação F indica se um par SO está incluído para o NACK particular ou não. Em outras palavras, o bit/indicação F pode ser dito indicar se a unidade de dados à qual o NACK se refere foi segmentada ou não, desde que é o único caso quando pares SO são usados.

[0040] Também pode ser mencionado que o caso de (por exemplo) duas partes perdidas, que, mas não consecutivas de uma e a mesma PDU podem ser operadas pela presente invenção visto que um e o mesmo NACK SN ocorrerá duas vezes, mas com pares SO diferentes.

[0041] Em semelhança à concretização da Figura 2, os ACKs e NACKs da PDU de estado 300 são providos da Figura 3 na forma do número de sequência, SN, da PDU de RLC à qual o ACK ou NACK se refere, por qual razão os ACK/NACKs são mostrados como ACK_SN ou NACK_SN. Depois do último NACK da PDU de estado 300 na Figura 3, os pares SO são incluídos para os NACKs para quais as indicações/bits "F" eram fixados. Assim, o par SO mostrado como SO11 e SO12 "pertencem" a NACK1_SN, e o par SO mostrado como SO21 e SO22 "pertencem" a NACK2_SN. Também, como mostrado na Figura 3, "enchimento", PAD, pode ser usado na PDU de estado 300 da Figura 3 a fim de obter alinhamento de octeto ou algum propósito semelhante.

[0042] Retornando agora à informação incluída nos pares SO, o primeiro SO em um par SO indica o primeiro octeto de dados perdidos da PDU, e o último SO em um par indica o último octeto de dados perdidos na PDU.

[0043] Deveria ser mostrado que se os dados nas PDUs recebidas, isto é, as PDUs às quais os ACK/NACKs se referem, forem arranjados em grupos diferentes de octetos, a invenção pode certamente também ser aplicada a tais sistemas. Os pares SO então indicariam de modo semelhante àquele descrito acima o começo e o fim dos dados na PDU à qual o NACK se refere.

[0044] Também pode ser acrescentado que as PDUs de estado da invenção também podem ser expandidas por meio de um campo depois do campo de D/C, que indica a natureza da PDU de estado, por exemplo, se PDUs de controle de RLC diferentes de PDUs de ESTADO são usadas. Este campo é incluído no exemplo mostrado na Figura 3, indicado como "tipo de PDU". O mesmo princípio, isto é, tipo de PDU, pode ser aplicado na versão mostrada na Figura 2.

[0045] Com referência continuada às PDUs de estado da invenção, também deveria ser mostrado que a ordem dos campos de dados nas PDUs de estado mostradas nas Figuras 2 e 3 são somente exemplos de concretizações adequadas, os campos de dados na PDU de estado da invenção pode ser movidos para outras posições na PDU de estado sem afetar a funcionalidade da invenção, por exemplo a fim de alcançar alinhamento de octeto. Como um exemplo, no caso com só um ACK e nenhum NACKs, isto é, a concretização mostrada na Figura 2, a PDU de estado 200 poderia começar com um campo de D/C seguido por um bit E, seguido por enchimento e finalmente o ACK com seu número de sequência.

[0046] Retornando agora ao caso mostrado como b-ii acima, isto é, um ou mais NACKs se referem a PDUs de dados não recebidos, ao invés de unidades de dados parcialmente recebidas, isto é operado da maneira seguinte: o indicador F correspondendo àqueles NACKs indica que nenhum par SO está incluído na PDU de estado para esses NACKs.

[0047] Um caso especial que também é tratado pela invenção é quando o último segmento de PDU de uma PDU de RLC não foi recebido pelo UE (ainda assumindo o caso de dados PDUS em DL). Assuma um exemplo onde uma PDU de RLC com número de sequência 10 foi segmentada em 3 PDUs de RLC, com os segmentos de PDU contendo octetos 1-10, 11-25 e 26-40, respectivamente.

[0048] Considere agora o caso no qual o UE recebeu os primeiros dois segmentos de PDU de RLC 10, isto é, octetos 1-10 e 11-25, e também recebeu a PDU de RLC seguinte, isto é, PDU de RLC 11, em sua totalidade, mas o UE não recebeu o último segmento de PDU de RLC 10, isto é, octetos 26-40.

[0049] Neste caso, o UE sabe que um segmento de RLC foi perdido, mas não sabe seu comprimento, assim o UE não pode fixar o segundo valor de compensação de segmentação no par SO correspondente na PDU de estado. Uma solução para isto que é proposta pela invenção é deixar um valor especial de um SO indicar que o fim do segmento NACK:ed não é conhecido. Assim, quando o eNodeB recebe um NACK para PDU de RLC 10, um primeiro SO é fixado a 26 e o segundo SO correspondente é fixado ao valor especial que conta ao eNodeB que todos os octetos de dados de 26 e adiante para PDU de RLC 10 precisam ser retransmitidos.

[0050] Em alguns casos, um par SO não é sempre necessário para obter o efeito desejado. Como será mostrado no seguinte, usando dois bits no campo "F", uma identificação completa dos dados não recebidos pode ser alcançada.

[0051] Isto é mostrado no exemplo da Figura 4, no qual todas as quatro combinações de dois bits no campo de F são ilustradas, isto é, 00, 01, 10 e 11. Os significados de cada uma destas combinações também são indicados na Figura 4, como segue: Campo F Significado 00 O NACK se refere à PDU de RLC inteira, assim nenhum SO é necessário. 01 O NACK se refere a uma primeira parte da PDU de RLC, 1 SO é precisado a fim de os últimos grupos de dados não recebidos, tal como, por exemplo, um octeto. 10 O NACK se refere a uma última parte da PDU de RLC, 1 SO é precisado a fim de indicar o primeiro grupo de dados não recebidos, tal como, por exemplo, um octeto. 11 O NACK se refere a uma parte mediana da PDU de RLC, 2 SOs são precisados a fim de indicar o primeiro e o último grupo de dados não recebidos, tal como, por exemplo, um octeto.

[0052] Deveria ser mostrado que no caso mostrado na Figura 4, em semelhança às concretizações mostradas previamente, um "campo de tipo" pode ser precisado a fim de separar PDUs de RLC de estado de outras PDUs de controle de RLC.

[0053] Em outra concretização da presente invenção, PDUs de dados de RLC de DL parcialmente recebidas são indicadas ao eNodeB pelo UE em uma PDU de RLC estado de UL de uma maneira ligeiramente diferente daquela mostrada acima, isto é, os pares SO. Na concretização em questão, a PDU de estado de RLC 500 de qual é mostrado na Figura 5 a PDU de RLC de estado de UL do UE inclui um campo de NACK, mostrado como 510, e um campo de número de sequência, SN, mostrado como 520, que indica o número de sequência da PDU de dados de RLC de DL à qual o NACK se refere. Naturalmente, na concretização 500, o SN também pode ser incluído junto com o NACK, como mostrado em concretizações prévias.

[0054] Em semelhança às concretizações prévias, a concretização 500 também inclui o uso de um campo "E", mostrado como 530 na Figura 5. Porém, a significação do campo E, isto é, um bit ou uma indicação, difere ligeiramente daquela das concretizações prévias: na concretização 500 da Figura 5, o campo E é usado para significar se o NACK 510 se refere a uma PDU de dados de RLC inteira ou a dados dentro de uma PDU de dados de RLC. Por exemplo, se o campo E igualar zero, E=0, isto poderia significar que o NACK 510 se refere à PDU de dados de RLC inteira que é identificada pelo SN 520.

[0055] Reciprocamente, se E=0 significar uma PDU inteira, então E=1 significa que o NACK 510 se refere a dados dentro da PDU identificada pelo SN 520. Neste caso, informação é incluída na PDU de estado 500 a fim de que o eNodeB seja capaz de identificar os dados em questão. Esta informação relativa a dados na concretização 500 inclui um valor de compensação de segmento, SO, mostrado como 540 na Figura 5. O SO 540 indica a compensação de byte ou o começo dos dados de DL não recebidos. Porém, ao invés das concretizações prévias, a concretização 500 não usa pares SO para indicar a totalidade dos dados não recebidos. Ao invés, a concretização 500 utiliza um Campo de Comprimento, LF, 550, o valor de qual indica o começo dos dados não recebidos, a partir do valor SO 540, até o último byte dos dados não recebidos.

[0056] Como pode ser percebido, nesta concretização da invenção, isto é, a mostrada na Figura 5, a fim de alcançar retransmissão eficiente do remetente original dos dados, o número exato de bytes que deveriam ser retransmitidos precisa ser indicado ao remetente. Desde que PDUs de RLC LTE podem ser bastante grandes (por exemplo 32767 bytes), os campos (isto é, SO e LF) precisados para indicação dos segmentos de PDU de RLC precisariam ser bastante grandes igualmente. Porém, como também será percebido, em muitos casos o tamanho teórico máximo dos campos SO e LF não precisará ser utilizado, que assim conduziria a um desperdício de espaço de dados se o tamanho desses campos fosse feito estático.

[0057] Em uma concretização da presente invenção, os inventores propõem aliviar este problema, isto é, uso ineficiente de espaço de dados para os campos de SO e LF. Esta concretização será descrita no seguinte.

[0058] Neste aspecto da invenção, um princípio básico é que os tamanhos de campo de SO e LF na PDU de estado de RLC sejam feitos adaptáveis às necessidades da PDU de estado de RLC atual. Obviamente, é possível usar dois tamanhos diferentes para SO e LF, por exemplo 6 bits para RSO e 4 bits para RSL. Porém, na descrição subsequente, será assumido que o tamanho é o mesmo.

[0059] Se, como proposto neste aspecto da presente invenção, um campo de comprimento dinâmico para SO e LF for usado, o eNodeB (no caso de dados em DL e mensagens de estado em UL) deve conhecer este tamanho de campo de comprimento a fim de ser capaz de ler a mensagem de estado.

[0060] Um primeiro modo de realizar isto é ter um campo adicional no cabeçalho de mensagem de PDU de estado de RLC que é indicativo do tamanho dos campos de SO e LF. Por exemplo, poderia haver um campo que indica que todos os campos de comprimento na mensagem atual são 6 bits. Este tamanho poderia diferir de mensagem de estado de PDU de RLC para mensagem de estado.

[0061] Se a SO e LF fossem dados valores de tamanho diferentes, dois tais campos de comprimento seriam precisados, ou uso poderia ser feito de uma relação predefinida entre eles, por exemplo SO sempre é x bits mais longo/mais curto que LF. Porém, desde que SO e LF são tipicamente da mesma ordem, esta otimização poderia não ser requerida.

[0062] De acordo com um aspecto alternativo da invenção, a indicação explícita do tamanho dos campos de SO e LF é supérflua, devido a um rearranjo na mensagem de estado de PDU de RLC. Neste aspecto da invenção, é proposto mover os "campos de comprimento" SO e LF para o fim da mensagem de estado de PDU de RLC, que será descrita com referência à Figura 6.

[0063] Na concretização mostrada na Figura 6, a informação de estado para todas as PDUs incluídas é provida primeiro, isto é, SN (número de segmento), RF (Indicação de Re-segmentação) e um bit de extensão, "E". Deste modo, será possível também incluir PDUs completas, onde nenhuma informação de segmento específica precisa ser enviada. Para PDUs onde re- segmentação ocorreu, o RF é usado para indicar esse local de segmento e informação de comprimento segue, e SO e LF são anexados ao quadro de mensagem.

[0064] Assim, na concretização da Figura 6, a parte "dinâmica" da mensagem de estado, isto é, SO e LF, ocorre depois do último bit de extensão E, isto é, depois do primeiro bit E com um valor que indica que é o último, tal como por exemplo o valor "0". Desde que o tamanho de mensagem global nesta concretização precisa ser conhecido, por exemplo de um cabeçalho de MAC ou RLC, o receptor sabe quantos bits são deixados para os campos de SO e LF. Também sabe quantos pares de SO e LF seguirão depois do último bit de extensão. Assim, o receptor pode calcular os tamanhos dos campos de SO e LF.

[0065] Se for uma exigência que a PDU de estado de RLC deveria estar alinhada em byte, uma etapa adicional tem que ser executada, visto que o número de bits restantes também é dividido pelo número de campos de segmento indicados. O resultado de inteiro é usado como comprimento, enquanto os bits restantes não são usados. Como um exemplo, se o comprimento restante for 51 bits, e alinhamento de byte (8 bits) for usado, nós obtemos o cálculo 51/8 = 6 mod 3. Assim, neste exemplo, 3 bits ao término da PDU de estado não serão usados.

[0066] No exemplo acima, o LF é usado para determinar o fim de um segmento de PDU de RLC. Porém, seria possível dentro da extensão da presente invenção usar uma compensação absoluta, em semelhança ao SO. Em tal caso, a compensação apontaria à posição original do último byte no segmento de PDU de RLC.

[0067] O conteúdo de mensagem de estado poderia descrever os dados que são ACK:ed ou NACK:ed. Também, uma mistura de ACKs e NACKs poderia ser incluída, com um ou mais bits adicionais para prover um indicador de ACK/NACK adequado.

[0068] A mensagem de estado descrita da Figura 6 somente deveria ser vista como um exemplo, campos adicionais como indicações de tipo para indicar se a PDU contém dados ou um estado, campos de comprimento adicionais e assim por diante poderiam ser requeridos em algumas aplicações, e estaria dentro da extensão desta invenção.

[0069] Informação de estado explícita também pode ser adicionada aos relatórios de estado, especialmente no caso que o padrão ou implementação permite múltiplos tipos de estados serem informados, por exemplo NACK e ACK.

[0070] Uma indicação explícita de um estado também pode ser necessária se o sistema de LTE for configurado para trocar um relatório de estado de um único tipo, por exemplo só NACKs. Alternativamente, a entidade remetente de relatório de estado pode receber da entidade remetente de PDU um pedido para um relatório de estado de um certo tipo (por exemplo só NACK) e assim geraria o relatório de estado só para o subconjunto de segmentos recebidos que não foram recebidos.

[0071] Em um aspecto adicional da invenção, poderia ser idealizado enviar a mensagem de estado de PDU de RLC como um PDU separada, ou anexada com outra PDU.

[0072] Figura 7 mostra um fluxograma aproximado de um método 700 da invenção. Etapas que são opções ou alternativas são mostradas com linhas tracejadas.

[0073] Como foi indicado na descrição acima, o método da invenção é planejado para uso em um sistema de comunicações celular tal como o 100 da Figura 1, isto é, um sistema no qual tráfego pode ser trocado entre um primeiro e um segundo transceptores tal como o UE 120 e o eNodeB 120.

[0074] O tráfego no sistema 100 é enviado em unidades de dados, e a cada uma destas unidades de dados é dado um identificador. As unidades de dados podem ser divididas em segmentos, e um transceptor receptor pode enviar informação de estado em quadros de dados ou unidades de dados sobre unidades de dados corretamente recebidas, parcialmente recebidas ou não recebidas ao transceptor remetente, isto é, para o transceptor do qual os dados foram enviados.

[0075] De acordo com o método inventivo 700, como indicado na etapa 705, no caso de uma ou mais unidade ou unidades de dados parcialmente ou não recebidas, a informação de estado que é enviada ao transceptor remetente inclui, como mostrado na etapa 710, informação sobre se a unidade de ou unidades dados eram não recebidas ou parcialmente recebidas, e nesse caso, como mostrado na etapa 715, no caso de um ou mais unidades de dados parcialmente recebidas, cujas partes dessas unidades de dados que não eram recebidas.

[0076] Em uma concretização da invenção, como mostrada na etapa 720, a informação sobre se ou não uma unidade de dados era parcialmente ou não recebida é incluída como uma indicação em ditos quadros de dados ou unidades de dados.

[0077] Como indicado na etapa 725, em uma concretização adicional da invenção, a informação sobre cujas partes de uma unidade de dados que não eram recebidas é incluída em ditos quadros de dados ou unidades de dados como informação que indica uma primeira e uma última parte da unidade de dados recebida.

[0078] Etapa 730 indica que em um aspecto da invenção, se um quadro ou unidade de dados do transceptor remetente foi segmentada ou re- segmentada, e um último segmento não alcançou o transceptor receptor, isto pode ser indicado pelo transceptor receptor ao transceptor remetente, adequadamente por meio de um valor predefinido especial para a informação sobre a última parte dos segmentos não recebidos.

[0079] Etapa 735 indica que em uma concretização da invenção, se um quadro ou unidade de dados do transceptor remetente foi segmentada e um último segmento não alcançou o transceptor receptor, isto pode ser indicado pelo transceptor receptor ao transceptor remetente.

[0080] Como foi indicado previamente nesta descrição, e como mostrado na etapa 740, o método 700 da invenção pode ser aplicado adequadamente a um sistema de LTE, Evolução a Longo Prazo, tal como o 100 que é mostrado esquematicamente na Figura 1.

[0081] Se o método inventivo 700 for aplicado a um sistema de LTE, as PDUs de dados podem ser enviadas em DL e as PDUs de estado correspondentes serão enviadas então em UL, como indicado na etapa 750, em qual caso o "transceptor remetente" mencionado acima é o eNodeB de uma célula de LTE, e o "transceptor receptor" é um Equipamento de Usuário, UE, da célula de LTE.

[0082] Reciprocamente, a invenção pode ser aplicada igualmente bem de forma que as PDUs de dados possam ser enviadas em UL e as PDUs de estado correspondentes então serão enviadas em DL, como indicado na etapa 745, em qual caso o "transceptor remetente" mencionado acima é o UE de uma célula de LTE, e o transceptor receptor é o eNodeB da célula de LTE.

[0083] Com referência à PDU de estado 300 mostrada na Figura 3, pode ser mostrado que a informação do transceptor receptor para o transceptor remetente pode ser enviada como uma mensagem que tem a possibilidade de incluir um ou mais do seguinte: Informação (D/C) sobre a natureza da mensagem, por exemplo mensagem de dados ou controle; Informação (tipo de PDU) sobre o tipo de mensagem dentro de dita natureza, por exemplo uma mensagem de estado no caso de mensagem de controle; Dados (ACK) reconhecendo corretamente unidades ou quadros de dados recebidos na forma de um certo número de sequência; Um primeiro indicador de extensão (E); Dados (NACK) relativos a uma unidade ou quadro de dados não ou parcialmente recebido na forma de um certo número de sequência (SN) de dita unidade ou quadro de dados; Um segundo indicador de extensão (F); Informação sobre o começo (SO11, SO21) e fim (SO12, SO22) de dados não recebidos.

[0084] Na PDU de estado exemplar mostrada na Figura 3, o primeiro indicador de extensão, E, indica a ausência ou presença de um conjunto incluindo outro do primeiro, e segundo indicadores de extensão, isto é, E e F, e dados, NACK, relativo a uma unidade ou quadro de dados parcialmente ou não recebido, na forma do identificador, SN, da unidade ou quadro de dados. O segundo indicador de extensão, F, indica a ausência ou presença de informação sobre o começo, SO11, SO21, e fim, SO21, SO22, de dados não recebidos.

[0085] A invenção também expõe um transceptor para uso em um sistema no qual a invenção é aplicada. Como emergiu da descrição acima, a invenção pode ser aplicada tanto quando PDUs de dados são enviadas em DL e as PDUs de estado correspondentes são enviadas em UL, em qual caso o transceptor remetente de dados (no caso de aplicações de E-UTRAN) é o eNodeB e o transceptor receptor, isto é, o transceptor que transmite PDUs de estado é o UE, ou reciprocamente, quando PDUs de dados são enviadas em UL e as PDUs de estado correspondentes são enviadas em DL, em qual caso o transceptor remetente de dados é o UE e o transceptor receptor, isto é, o transceptor que transmite PDUs de estado é o eNodeB. SO, o transceptor da invenção pode ser tanto um eNodeB de E-UTRAN ou um UE de E-UTRAN.

[0086] Um diagrama de bloco esquemático de um transceptor inventivo genérico 800 para uso como um eNodeB de E-UTRAN ou um UE de E-UTRAN é mostrado na Figura 8. Como indicado na Figura 8, o transceptor 800 incluirá uma antena, mostrada como bloco 810, e também incluirá uma parte de recepção 820 e uma parte de transmissão 830. Além disso, o transceptor 800 também inclui um meio de controle 840 tal como um microprocessador, como também uma memória 850. Além disso, se o transceptor 800 for para ser usado como um eNodeB, o transceptor 800 também inclui uma interface 860 para outros componentes no sistema à parte dos UEs. Desde que a interface pode não estar presente se o transceptor 800 for um UE, a interface 860 é mostrada com linhas tracejadas.

[0087] O transceptor 800 pode usar a antena 810, a parte de recepção 820 e a parte de transmissão 830 para enviar tráfego e receber tráfego de um segundo transceptor no sistema, e o transceptor 800 pode usar o meio de controle 840 junto com a memória 850 para enviar dito tráfego em unidades de dados.

[0088] O meio de controle 840 também pode ser usado e a memória 850 para dar a cada uma das unidades de dados um identificador, tal como por exemplo um número de sequência, e os mesmos meios, isto é, blocos 840 e 850 podem ser usados para dividir as unidades de dados em segmentos.

[0089] O transceptor inventivo 800 também usa o meio de controle 840, a memória 850, o transmissor 830 e a antena 810 para enviar informação em quadros de dados ou unidades de dados sobre unidades de dados corretamente recebidas, parcialmente recebidas ou não recebidas ao segundo transceptor, isto é, para o transceptor do qual os dados foram enviados.

[0090] Além disso, o transceptor 800 pode usar o meio de controle 840 e a memória 850 para, no caso de uma ou mais unidades de dados não recebidas ou parcialmente recebidas, incluir informação na informação de estado sobre se a unidade ou unidades de dados eram não recebidas ou parcialmente recebidas, e no caso de uma ou mais unidades de dados parcialmente recebidas, cujas partes dessas unidades de dados eram não recebidas.

[0091] Em uma concretização, os meios 840 e 850 são usados pelo transceptor 800 para incluir a informação sobre se ou não uma unidade de dados era parcialmente ou não recebida como uma indicação em ditos quadros de dados ou unidades de dados.

[0092] Além disso, em uma concretização adicional, os blocos 840 e 850 são usados pelo transceptor para incluir a informação sobre cujas partes de uma unidade de dados eram não recebidas em ditos quadros de dados ou unidades de dados como informação que indica uma primeira e uma última parte da unidade de dados não recebida.

[0093] Em outro aspecto da invenção, o meio de controle 840, a memória 850, o transmissor 830, junto com a antena 810 pode ser usados pelo transceptor 800 para indicar a um transceptor remetente se um quadro ou unidade de dados do transceptor remetente foi segmentada, e um último segmento não alcançou o transceptor 800.

[0094] A indicação sobre um segmento perdido é executada adequadamente por meio de usar um valor predefinido especial para a informação sobre a última parte do segmento perdido.

[0095] Em uma concretização, o meio de controle 840 e a memória 850 podem ser usadas pelo transceptor 800 para incluir a informação sobre cujas partes de uma unidade de dados parcialmente recebida não eram recebidas em ditos quadros de dados ou unidades de dados como informação que indica o identificador da unidade de dados, como também informação sobre o começo dos dados não recebidos em dita unidade de dados, e a quantidade de dados não recebidos.

[0096] Além disso, a antena 810, o transmissor 830, o meio de controle 840 e a memória 850 podem ser usados pelo transceptor inventivo para enviar informação de estado para um transceptor remetente como uma mensagem, tal como o 300 da Figura 3, que pode incluir um ou mais do seguinte: Informação (D/C) sobre a natureza da mensagem, por exemplo mensagem de dados ou controle; Informação sobre o tipo de mensagem dentro de dita natureza, por exemplo uma mensagem de estado no caso de uma mensagem de controle; Dados (ACK) reconhecendo unidades ou quadros de dados recebidos corretamente na forma de um certo número de sequência; Um primeiro indicador de extensão (E); Dados (NACK) relativos a uma unidade ou quadro de dados não recebido ou parcialmente recebido, na forma de um certo número de sequência; Um segundo indicador de extensão (F); Informação sobre o começo (SO11, SO21) e fim (SO12, SO22) de dados não recebidos.

[0097] Convenientemente, o primeiro indicador de extensão (E) indica a ausência ou presença de um conjunto incluindo outro de dito primeiro (E) e segundo (F) indicadores de extensão e dados (NACK) relativos a uma unidade ou quadro parcialmente ou não recebido na forma do identificador (SN) de dita unidade ou quadro de dados, e dito segundo indicador de extensão (F) indica a ausência ou presença de informação sobre o começo (SO11, SO21) e fim (SO12, SO22) de dados não recebidos.

[0098] A invenção não está limitada aos exemplos de concretizações descritos acima e mostrados nos desenhos, mas pode ser variada livremente dentro da extensão das reivindicações anexas.

Claims (22)

1. Método (700) para uso em um sistema de comunicações celular (100), caracterizado pelo fato de que o tráfego de sistema pode ser trocado entre um primeiro (110, 120) e um segundo (110, 120) transceptores, dito tráfego sendo enviado em unidades de dados, a cada uma das quais unidade de dados é dado um identificador, e quais unidades de dados podem ser divididas em segmentos, em cujo sistema (100) um transceptor receptor (110, 120) pode enviar informação de estado em quadros de dados ou unidades de dados (200, 300) sobre unidades de dados corretamente recebidas, parcialmente recebidas, ou não recebidas a um transceptor remetente, isto é, para o transceptor do qual os dados foram enviados, e que no caso (705) de uma ou mais unidade ou unidades de dados não recebidas ou parcialmente recebidas, a informação de estado que é enviada ao transceptor remetente é enviada como uma mensagem (300) compreendendo: dados (ACK) reconhecendo unidades ou quadros de dados recebidos corretamente na forma de um certo número de sequência; um primeiro indicador de extensão (E); dados (NACK) relativos a uma unidade ou quadro de dados não recebidos ou parcialmente recebidos, na forma de um certo número de sequência; um segundo indicador de extensão (F), indicando se a unidade ou unidades de dados foram não recebidas ou parcialmente recebidas; e no caso de uma ou mais unidades de dados parcialmente recebidas, cujas partes (715) dessas unidades de dados eram não recebidas, e que dito primeiro indicador de extensão (E) indica a ausência ou presença de um conjunto incluindo outro de dito primeiro (E) e segundo (F) indicadores de extensão e dados (NACK) relativos a uma unidade ou quadro de dados parcialmente ou não recebido na forma do identificador (SN) de dita unidade ou quadro de dados, e dito segundo indicador de extensão (F) indica a ausência ou presença de informação sobre um começo (SO11, SO21) e fim (SO12, SO22) de dados não recebidos.

2. Método (700, 720) de acordo com a reivindicação 1, caracterizado pelo fato de que a informação sobre se ou não uma unidade de dados era parcialmente ou não recebida é incluída como uma indicação em ditos quadros de dados ou unidades de dados.

3. Método (700, 725) de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que a informação sobre cujas partes de uma unidade de dados que não eram recebidas é incluída em ditos quadros de dados ou unidades de dados como informação que indica uma primeira e uma última parte da unidade de dados não recebida.

4. Método (700, 730) de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que, se um quadro ou unidade de dados do transceptor remetente foi segmentada e um último segmento não alcançou o transceptor receptor, isto pode ser indicado pelo transceptor receptor (110, 120) para o transceptor remetente (110, 120).

5. Método (700, 730) de acordo com a reivindicação 3 ou 4, caracterizado pelo fato de que dita indicação sobre um segmento perdido é executada por meio de um valor predefinido especial para a informação sobre a última parte do segmento perdido.

6. Método (700, 735) de acordo com a reivindicação 1, caracterizado pelo fato de que a informação sobre cujas partes de uma unidade de dados parcialmente recebida que não eram recebidas é incluída em ditos quadros de dados ou unidades de dados como informação que indica o identificador da unidade de dados, como também informação sobre o começo dos dados não recebidos em dita unidade de dados, e a quantidade de dados não recebidos.

7. Método (700, 740) de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de ser aplicado a um sistema de E-UTRAN (100).

8. Método de acordo com a reivindicação 7, caracterizado pelo fato de que dita unidade de dados é uma PDU de RLC, de forma que ditos segmentos são segmentos de PDU de RLC.

9. Método (700, 750) de acordo com a reivindicação 8, caracterizado pelo fato de que o transceptor remetente é o eNodeB (110) de uma célula de E-UTRAN (130), e o transceptor receptor é um UE (120), Equipamento de Usuário, da célula de E-UTRAN (130).

10. Método (700, 745) de acordo com a reivindicação 8, caracterizado pelo fato de que o transceptor remetente é o UE de uma célula de E-UTRAN, e o transceptor receptor é o eNodeB da célula de E-UTRAN (130).

11. Método (700) de acordo com qualquer uma das reivindicações 1 a 10, caracterizado pelo fato de que a informação de estado do transceptor receptor (110, 120) para o transceptor remetente (110, 120) é enviada como uma mensagem (300) que tem a possibilidade de incluir um ou mais do seguinte: informação (D/C) sobre a natureza da mensagem, por exemplo mensagem de dados ou controle; informação sobre o tipo de mensagem dentro de dita natureza, por exemplo uma mensagem de estado no caso de uma mensagem de controle; informação sobre o começo (SO11, SO21) e fim (SO12, SO22) de dados não recebidos.

12. Transceptor (800) para uso em um sistema de comunicações celular (100), o transceptor sendo equipado com meios (810, 820, 830) para enviar tráfego e receber tráfego de um segundo transceptor no sistema, o transceptor (800) sendo equipado com meios (840, 850) para enviar dito tráfego em unidades de dados, e meios (840, 850) para dar a cada uma de ditas unidades de dados um identificador, como também meios (840, 850) para dividir ditas unidades de dados em segmentos, dito transceptor (800) também sendo equipado com meios (840, 850, 830, 810) para enviar informação de estado em quadros de dados ou unidades de dados (200, 300) sobre unidades de dados corretamente recebidas, parcialmente recebidas ou não recebidas para dito segundo transceptor, isto é, para o transceptor do qual os dados foram enviados, o transceptor (800) sendo caracterizado pelo fato de que é equipado adicionalmente com meios (840, 850) para, no caso de uma ou mais unidades de dados não recebidas ou parcialmente recebidas, enviar a informação do estado como uma mensagem (300) compreendendo: dados (ACK) reconhecendo unidades ou quadros de dados recebidos corretamente na forma de um certo número de sequência; um primeiro indicador de extensão (E); dados (NACK) relativos a uma unidade ou quadro de dados não recebidos ou parcialmente recebidos, na forma de um certo número de sequência; um segundo indicador de extensão (F), indicando se a unidade ou unidades de dados foram não recebidas ou parcialmente recebidas; e no caso de uma ou mais unidades de dados parcialmente recebidas, cujas partes (715) dessas unidades de dados eram não recebidas, em que que dito primeiro indicador de extensão (E) indica a ausência ou presença de um conjunto incluindo outro de dito primeiro (E) e segundo (F) indicadores de extensão e dados (NACK) relativos a uma unidade ou quadro de dados parcialmente ou não recebido na forma do identificador (SN) de dita unidade ou quadro de dados, e dito segundo indicador de extensão (F) indica uma ausência ou presença de informação sobre um começo (SO11, SO21) e fim (SO12, SO22) de dados não recebidos.

13. Transceptor (800) de acordo com a reivindicação 12, caracterizado pelo fato de ser equipado com meios (840, 850) para incluir a informação sobre se ou não uma unidade de dados era parcialmente ou não recebida como uma indicação em ditos quadros de dados ou unidades de dados.

14. Transceptor (800) de acordo com a reivindicação 12 ou 13, caracterizado pelo fato de ser equipado com meios (840, 850) para incluir a informação sobre cujas partes de uma unidade de dados que eram não recebidas em ditos quadros de dados ou unidades de dados como informação que indica uma primeira e uma última parte da unidade de dados não recebida.

15. Transceptor (800) de acordo com qualquer uma das reivindicações 12 a 14, caracterizado pelo fato de ser equipado com meios (840, 850, 830, 810) para, se um quadro ou unidade de dados do transceptor remetente foi segmentada e um último segmento não alcançou o transceptor receptor, indicar isto ao transceptor remetente (110, 120).

16. Transceptor (800) de acordo com a reivindicação 14 ou 15, caracterizado pelo fato de que dita indicação sobre um segmento perdido é executada por meio de usar um valor predefinido especial para a informação sobre a última parte do segmento perdido.

17. Transceptor (800) de acordo com a reivindicação 12, caracterizado pelo fato de ser equipado com meios (840, 850) para incluir a informação sobre informação sobre cujas partes de uma unidade de dados parcialmente recebida que não eram recebidas em ditos quadros de dados ou unidades de dados como informação que indica o identificador da unidade de dados, como também informação sobre o começo dos dados não recebidos em dita unidade de dados, e a quantidade de dados não recebidos.

18. Transceptor (800) de acordo com qualquer uma das reivindicações 12 a 17, caracterizado pelo fato de ser um transceptor em um sistema de E-UTRAN (100).

19. Transceptor de acordo com a reivindicação 18, caracterizado pelo fato de que dita unidade de dados é uma PDU de RLC, de forma que segmentos ditos são segmentos de PDU de RLC.

20. Transceptor (800) de acordo com a reivindicação 18 ou 19, caracterizado pelo fato de ser um eNodeB (110) do sistema de E-UTRAN.

21. Transceptor (800) de acordo com a reivindicação 18 ou 19, caracterizado pelo fato de ser um UE (120), Equipamento de Usuário, do sistema de E-UTRAN.

22. Transceptor (800) de acordo com qualquer uma das reivindicações 12 a 21, caracterizado pelo fato de ser equipado com meios (810, 830, 840, 850) para enviar informação de estado para um transceptor remetente (110, 120) como uma mensagem (300) que tem a possibilidade de incluir um ou mais do seguinte: informação (D/C) sobre a natureza da mensagem, por exemplo mensagem de dados ou controle;24. informação sobre o tipo de mensagem dentro de dita natureza, por exemplo uma mensagem de estado no caso de uma mensagem de controle; informação sobre o começo (SO11, SO21) e fim (SO12, SO22) de segmentos não recebidos.