BRPI0712095B1 - método para transmissão de retorno para uma primeira unidade de bitmaps de aviso de recebimento/aviso de não recebimento ack/nack - Google Patents

método para transmissão de retorno para uma primeira unidade de bitmaps de aviso de recebimento/aviso de não recebimento ack/nack Download PDF

Info

Publication number
BRPI0712095B1
BRPI0712095B1 BRPI0712095-8A BRPI0712095A BRPI0712095B1 BR PI0712095 B1 BRPI0712095 B1 BR PI0712095B1 BR PI0712095 A BRPI0712095 A BR PI0712095A BR PI0712095 B1 BRPI0712095 B1 BR PI0712095B1
Authority
BR
Brazil
Prior art keywords
rlc
ack
mac
block
nack
Prior art date
Application number
BRPI0712095-8A
Other languages
English (en)
Inventor
Parolari Sergio
Original Assignee
Nokia Siemens Networks Spa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=36992773&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=BRPI0712095(B1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Nokia Siemens Networks Spa filed Critical Nokia Siemens Networks Spa
Publication of BRPI0712095A2 publication Critical patent/BRPI0712095A2/pt
Publication of BRPI0712095B1 publication Critical patent/BRPI0712095B1/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1614Details of the supervisory signal using bitmaps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1664Details of the supervisory signal the supervisory signal being transmitted together with payload signals; piggybacking

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Production Of Multi-Layered Print Wiring Board (AREA)
  • Dot-Matrix Printers And Others (AREA)

Abstract

método para a transmissão segura de bitmaps de ack/nack curtos em processo arq dentro de sistemas em conformidade com edge. a presente invenção refere-se a um aperfeiçoamento às propostas mais recentes sobre um mecanismo arq rápido a ser operado logo dentro dos sistemas de rádio móveis geran 3gpp. o arq rápido avalia os bitmaps curtos, abrangendo apenas poucos octetos, piggybacked na carga útil do bloco mac/rlc que porta a sinalização ack/nack relevante. o aperfeiçoamento principal é que para se mudar o bitmap curto a partir dos dados de carga útil para o cabeçalho do mesmo bloco mac/rlc transmitido na direção de uplink ou downlink, indiferentemente. isso permite que o bitmap curto seja codificado juntamente com o cabeçalho, levando vantagem da mesma codificação que é perceptivelmente mais robusta do que a utilizada para a carga útil. a sincronização entre os quadros de transmissão e recepção é solicitada no reporte com bitmaps curtos. a retransmissão corrigida de blocos de rádio recebidos de forma ruim precisa do conhecimento do retardo fixo (expresso como um número de períodos de bloco mac/rlc) entre o momento de transmissão de um bloco de rádio e o momento de recepção do bitmap curto. um segundo aperfeiçoamento é alocar o bitmap curto em uma nova zona localizada imediatamente depois do cabeçalho dos blocos mac/rlc, e codificar os mesmos independentemente da carga útil utilizando uma codificação mais robusta contra os erros do que a robustez do mcs utilizado na parte de dados de carga útil.

Description

Relatório Descritivo da Patente de Invenção para MÉTODO PARA TRANSMISSÃO DE RETORNO PARA UMA PRIMEIRA UNIDADE DE BITMAPS DE AVISO DE RECEBIMENTO/AVISO DE NÃO RECEBIMENTO ACK/NACK.
Campo da Invenção [1] A presente invenção refere-se ao campo de redes de rádio móveis dentro da transmissão de dados em pacote, e mais precisamente a um método de transmissão segura UL/DL de bitmaps ACK/NACK curtos nos sistemas em conformidade com EDGE dentro do processo ARQ (acrônimos são fornecidos no final da descrição). Antecedentes da Técnica [2] A sinalização ARQ por meio dos chamados sinais de aviso de recebimento (ACK) e de não recebimento (NACK) é normal nos protocolos de telecomunicação. Tal tipo de sinalização ACK/NACK é descrito, por exemplo, em 3GPP TS 44.060 V7.3.0 (ex GERAN 04.60). Dentro de EDGE existem nove MCSs, conhecidos como: MCS1,...MCS9.
[3] Na figura 1, um primeiro tipo de bloco de dados GERAN é constituído de um primeiro campo como cabeçalho e um segundo campo como carga útil. O cabeçalho inclui ambos os campos BSN e TFI. O último também é designado como bloco RLC. Os blocos codificados MCS1 a MCS6 são caracterizados por esses dois campos. Para os blocos codificados MCS7 a MCS9, três campos são utilizados, um primeiro campo para o cabeçalho, um segundo campo para a carga útil, conhecido como bloco RLC1, e um terceiro campo também para a carga útil, conhecido como bloco RLC2. O cabeçalho inclui TFI, um primeiro campo BSN1 designado para o bloco RLC1, e um segundo campo BSN2 designado para o bloco RLC2.
[4] As funções ARQ RLC disponíveis em GERAN suportam três modos de operação: modo de aviso de recebimento RLC, modo
Petição 870190071787, de 26/07/2019, pág. 4/29
2/20 sem aviso de recebimento RLC e modo não-persistente RLC. A operação do modo de aviso de recebimento RLC utiliza a retransmissão de blocos de dados RLC para alcançar alta confiabilidade. A operação do modo sem aviso de recebimento RLC não utiliza a retransmissão dos blocos de dados RLC. A operação do modo não-persistente RLC utiliza a retransmissão não-exaustiva dos blocos de dados RLC.
[5] ARQ convencional com mensagens de retorno ACK/NACK, tal como PDAN ou PUAN, reportam bitmaps que ocupam todo um bloco de rádio. Toda vez que existe uma solicitação de pesquisa transmitida na direção de downlink (DL) pela estação de base para o recebimento de uma mensagem PDAN em retorno transmitida pelo móvel na direção de uplink (UL) para acusar ou não o recebimento dos blocos RLC recebidos em downlink, os recursos de uplink são utilizados apenas para enviar PDAN de mensagem de sinalização em uplink. Esse recurso de uplink, portanto, não pode ser utilizado para o envio de dados. Conclusões duplas para o desperdício de recursos de downlink devem ser tiradas para uma mensagem PUAN emitida pela estação de base em downlink para acusar ou não o recebimento dos blocos RLC transmitidos pela MS em uplink. Conseqüentemente, a transmissão de dados pode ser severamente atingida pelas mensagens ACK/NACK transmitidas com freqüência, especialmente no caso de transmissão através de poucas partições de tempo.
[6] O pedido de patente europeu N° 05023668.6 depositado em 28.10.2005 no nome do mesmo requerente descreve um método para ACK/NACK a sinalização que precisa ser considerado sob o Artigo 54(3)EPC. De acordo com a citação relevante:
[7] uma primeira unidade (BS) transmite uma solicitação de pesquisa em um momento no tempo para a segunda unidade (MS) e a solicitação de pesquisa inicializa um exame de ACK/NACK dos blocos RLC recebidos. A segunda unidade examina os blocos RLC recebidos,
Petição 870190071787, de 26/07/2019, pág. 5/29
3/20 que são designados para um número dedicado de partições de tempo no portador, e o exame é realizado para todas as partições de tempo do conjunto.
[8] Durante o exame um bit binário é utilizado para indicar, se um bloco RLC considerado mostrar erros ou não. Os bits de indicação são utilizados para formar um bitmap curto e o bitmap curto é transmitido a partir da segunda unidade para a primeira unidade como sinal ACK/NACK.
[9] A primeira unidade analisa o bitmap curto e identifica os blocos RLC com erros com relação à temporização de transmissão dos blocos RLC entre a primeira e a segunda unidades, com relação ao conjunto designado de partições de tempo e com relação ao momento no tempo no qual a solicitação de pesquisa foi enviada, cada um dos fatos sendo conhecido na primeira unidade.
[10] No caso da transmissão de dados na direção de uplink, o bitmap curto será parte de um bloco de dados de uplink normal. Devido a esse fato, existe a possibilidade de se adicionar e transmitir carga útil normal dentro do bloco de dados, juntamente com o bloco de bitmap curto. Essa característica é apresentada no bloco RLC de uplink da figura 2.
[11] Se não houver qualquer transmissão de dados na direção de uplink o bitmap curto será enviado na direção de uplink em uma chamada rajada de acesso. A transmissão e a recepção desse tipo de rajada são normalmente realizadas sem perturbações, a transmissão do bitmap curto é portanto salva. Se a rajada de acesso portar o bitmap curto, então a potência de bateria na estação móvel pode ser salva. Devido à repetição de transmissão mais lenta da rajada de acesso, é possível se reduzir a interferência dentro do sistema/sistema GERAN.
[12] Sob o método citado a transmissão dos números de se
Petição 870190071787, de 26/07/2019, pág. 6/29
4/20 qüência de bloco como parte do sinal ACK/NACK não é necessária. Ao invés de um reporte ACK/NACK com base em número de seqüência de bloco, um reporte com base em tempo é utilizado. A estação de base, e, dessa forma, a estação móvel, conhecem o tempo de transmissão e a temporização de um bloco de rádio dedicado com exatidão, de forma que a designação de uma indicação ACK/NACK recebida para um bloco de rádio enviado anteriormente seja possível. Por exemplo, se uma indicação de pesquisa for recebida em um número de quadro N, a MS enviará de volta um bitmap curto para ACK/NACK, indicando a situação de todos os blocos de rádio recebidos nas partições de tempo designadas durante o número de quadro N, N-1, e assim por diante. Isso depende do tamanho do bitmap curto e do número de partições de tempo designadas. Na maioria dos casos um bitmap muito curto é suficiente para a sinalização ACK/NACK. Se for considerada uma estação móvel com 4 partições de tempo designadas na direção de downlink e um período de pesquisa de 40 ms, haverá um máximo de 4x2=8 blocos de rádio portando um máximo de 16 blocos RLC submetidos durante duas pesquisas sucessivas.
[13] Visto que pode haver dois blocos de dados RLC por bloco de rádio (no caso de MCS 7, 8, 9), no máximo dois bits por bloco de rádio são necessários no bitmap. Para cada bloco de rádio recebido nas partições de tempo designadas, o receptor deve configurar o par de bits no bitmap curto como descrito pela tabela de regra de codificação da citação ilustrada na figura 3.
[14] No caso de múltiplos TBFs alocados no mesmo móvel, o bitmap pode englobar a informação para todos os TBFs. Nesse caso os bits seriam configurados para 1 para os blocos RLC corretamente recebidos com qualquer um dos TFIs DL designados. Isso otimizaria adicionalmente o procedimento visto que o retorno para todos os TBFs poderia ser fornecido ao mesmo tempo. A figura 4 ilustra como as re
Petição 870190071787, de 26/07/2019, pág. 7/29
5/20 gras de codificação da figura 3 são aplicadas para a geração de um bitmap curto. Na figura um TBF DL é alocado nas partições de tempo 0, 1,2 e 3 (TBF1) e multiplexados em tempo com outros TBFs (TBF2 e TBF3) alocados no mesmo portador que o TBF1. O comprimento do bitmap curto (relevante para o TBF1 apenas) é considerado como sendo de 2 octetos (lidos seqüencialmente) cada um abrangendo um período de 20 ms de um bloco de rádio. À medida que a pesquisa é recebida pela MS no quadro N, o primeiro par de bits circulados no bitmap curto deve se referir ao bloco de rádio recebido na primeira partição de tempo designada no quadro N, o segundo par de bits deve se referir ao bloco de rádio recebido na segunda partição de tempo designada no quadro N, etc. Visto que ainda existe um espaço livre no bitmap, o próximo par de bits deve se referir ao bloco de rádio recebido na primeira partição de tempo designada no quadro N-1 e assim por diante.
Problema Técnico Destacado [15] O método da aplicação citada pode ser utilizado para repor- te ACK/NACK tanto para transmissões em uplink quanto para transmissões em downlink, de forma indiferente, apesar de a mensagem PDAN ser a única descrita e explicitamente reivindicada. O momento da transmissão PDAN é programado pela estação de base com uma solicitação de pesquisa (RRBP) emitida no cabeçalho de um bloco RLC transmitido em downlink. Não existem razões para um móvel pesquisar a rede (estação de base) para transmissão de um retorno para suas próprias transmissões de uplink, visto que a rede é o mestre da programação no canal de downlink. Começando com o reporte em uplink ACK/NACK rápido para transmissões em downlink, algumas outras questões precisam ser consideradas a fim de se adaptar o protocolo MAC mais rápido às transmissões de dados em uplink. Em primeiro lugar, um critério deve ser implementado para informar o móvel de que
Petição 870190071787, de 26/07/2019, pág. 8/29
6/20 um bitmap curto é utilizado ao invés do tradicional estendido com uma mensagem PUAN.
[16] O método da aplicação citada indica um critério de coexistência entre os bitmaps estendidos e curtos válido para o reporte ACK/NACK apenas configurado na direção de uplink. Os critérios avaliam uma redefinição substancial de ambos os campos RRBP e ES/P conhecidos nos cabeçalhos dos blocos de dados de downlink EGPRS. Além disso, a fim de que o receptor de estação de base saiba se ou não um bitmap ACK/NACK curto é piggybacked no bloco de dados de uplink RLC, um bit sobressalente no cabeçalho MAC/RLC UL é utilizado. Um bit sobressalente existe em todos os três tipos de cabeçalho UL EGPRS e será utilizado para esse caso.
[17] O espaço para reporte de downlink é preenchido pelo documento 3GPP temporário TSG GERAN#29, Tdoc GP-060755, San Jose Del Cabo, México, 24-28, abril de 2006 que sugere:
[18] reporte ACK/NACK configurado na direção de uplink:
[19] o bit sobressalente no cabeçalho MAC/RLC UL é utilizado. O reporte do móvel com o bitmap curto ou estendido é sinalizado pela rede pela utilização da pesquisa (RRBP) e campos USF na direção de downlink.
[20] Reporte ACK/NACK configurado na direção de downlink:
[21] o bit sobressalente no cabeçalho MAC/RLC DL é utilizado. O mesmo critério da aplicação citada para o reporte ACK/NACK na direção de uplink é utilizado para o reporte em downlink. Isto é, ambos os campos RRBP e ES/P no cabeçalho dos blocos de dados de downlink EGPRS são redefinidos para esse objetivo.
[22] O reporte ACK/NACK como resulta do ensinamento combinado de ambos os documentos de prioridade é, não-obstante, aquém do ideal pelos motivos abaixo:
[23] uma possibilidade residual de erro existe mesmo com a de
Petição 870190071787, de 26/07/2019, pág. 9/29
7/20 codificação do bitmap curto com CRC separada. Isso depende basicamente do MCS selecionado de forma adaptativa para a carga útil e, dessa forma, para o bitmap curto incluído.
[24] Um mecanismo muito rígido para o reporte ACK/NACK na direção de downlink que considera o reporte para um TBF apenas, sem considerar a eventualidade dos reportes adicionais de outras MSs compartilhando as mesmas partições de tempo dentro da janela de reporte predeterminada.
Sumário e Vantagens da Invenção [25] Em vista do estado da técnica destacado, é um objetivo da presente invenção fornecer um método sem as limitações sublinhadas.
[26] A invenção alcança o dito objetivo pelo fornecimento de um método para a transmissão segura de volta para uma primeira unidade de bitmaps ACK/NACK curtos gerados por uma segunda unidade no contexto de sinalização AQ dentro de um sistema de rádio móvel, onde as transmissões programadas para um fluxo de bloco temporário, chamado de TBF, avalia pelo menos um portador acessado em divisão de tempo durante as partições de tempo dos quadros seqüenciais para portar os blocos de rádio MAC/RLC, cada um constituído de um cabeçalho e uma parte de dados de carga útil distribuídos em um conjunto de partições de tempo alocadas intercaladas entre um número predeterminado de quadros, onde o bitmap ACK/NACK curto inclui tanto bits quanto os blocos MAC/RLC recebidos em uma janela de tempo abrangendo um ou mais períodos de bloco predeterminados antes de um ponto de partida do tempo conhecido das primeira e segunda unidades, o valor lógico de cada bit indicando blocos MAC/RLC decodificados corretamente ou com erro, de modo a permitir a retransmissão pela primeira unidade dos blocos mapeados como decodificados com erro pela segunda unidade; o dito bitmap curto sendo codificado pela segunda unidade de forma independente do código de redundância da parte de
Petição 870190071787, de 26/07/2019, pág. 10/29
8/20 dados de carga útil, utilizando um esquema de modulação e codificação para o bitmap curto geralmente mais robusto contra erros do que a robustez do esquema de modulação e codificação utilizado na parte de dados de carga útil, como descrito na reivindicação 1. Características vantajosas adicionais são descritas nas reivindicações dependentes.
[27] De acordo com uma primeira modalidade preferida da invenção válida para ambos o reporte em uplink e downlink, o bitmap curto é alocado no cabeçalho do bloco MAC/RLC utilizado para portar o mesmo, de forma a ser codificado com o cabeçalho.
[28] De acordo com uma segunda modalidade preferida da invenção válida para o reporte em downlink apenas, o bitmap curto alocado no cabeçalho é adicionalmente alocado em uma nova zona do bloco MAC/RLC codificada independentemente com relação a ambos o cabeçalho e a parte de dados; a nova zona portando informação de difusão e multidifusão que é acessada por todas as estações móveis alocadas nas mesmas partições de tempo. De forma proveitosa a nova zona é localizada imediatamente depois da parte de cabeçalho.
[29] De acordo com uma terceira modalidade preferida da invenção válida para os bitmaps curtos transmitidos em downlink, o bitmap curto é alocado apenas na dita nova zona de difusão/multidifusão.
[30] De acordo com uma quarta modalidade preferida da invenção válida para o reporte em uplink, o bitmap curto é alocado nem no cabeçalho nem na carga útil, mas em uma nova zona adicional.
[31] O método da invenção, independentemente da modalidade utilizada, torna a transmissão de bitmaps ACK/NACK curtos no processo ARQ mais confiável. O método implementado de acordo com a segunda ou a terceira modalidade preferida, é melhor de acordo com a oportunidade de difusão/multidifusão oferecida no canal de downlink com relação à transmissão ponto a ponto em uplink. De forma proveitosa, um bitmap curto alocado na zona de difusão/multidifusão se res
Petição 870190071787, de 26/07/2019, pág. 11/29
9/20 ponsabiliza por mais de um usuário programado na mesma janela de tempo, mesmo diferente do destinatário da carga útil do bloco de rádio. A vantagem é que todos os móveis programados dentro do mesmo período de bloco podem ser informados com igual rapidez sobre a situação ACK/NACK de suas transmissões recentes.
[32] O método implementado de acordo com a quarta modalidade preferida permite uma solução mais confiável do que a alocação do bitmap na carga útil, visto que a codificação da nova zona pode ser tornada mais robusta, e mais flexível do que a primeira modalidade preferida da invenção, visto que o bitmap curto pode ser evitado quando não for necessário, de forma que os dados possam ser enviados em uplink.
[33] Em conclusão, um mecanismo de retorno rápido e confiável pode ser realizado enviando-se de volta para o transmissor uma informação de retorno em cada ocasião possível, sem consumir completamente a largura de banda no canal de retorno. Isto é possível por piggybacking de bitmaps curtos em diferentes partes dos blocos de rádio para ambos os links de avanço e reverso. A implementação dos serviços sensíveis a retardo em GERAN, com VoIP, é aperfeiçoada de forma apreciável.
Breve Descrição dos Desenhos [34] As características da presente invenção que são consideradas como sendo novas são apresentadas com particularidade nas reivindicações em anexo. A invenção e suas vantagens podem ser compreendidas com referência à descrição detalhada a seguir de uma modalidade da mesma levada em consideração em conjunto com os desenhos em anexo fornecidos para fins de explicação não-limitadora apenas e em que:
[35] a figura 1, já descrita, ilustra a estrutura geral de dois tipos de blocos de rádio utilizados dentro de um sistema GERAN da técnica
Petição 870190071787, de 26/07/2019, pág. 12/29
10/20 conhecida;
[36] a figura 2, já descrita, ilustra uma estrutura ilustrativa de um bloco de dados RLC da técnica anterior utilizada na direção de uplink;
[37] a figura 3, já descrita, inclui uma tabela ilustrando as regras de codificação utilizadas para construir um bitmap curto incluído na parte de dados do bloco de dados RLC da figura 2;
[38] a figura 4, já descrita, ilustra o mecanismo de sinalização ARQ ACK/NACK de Pesquisa/Reporte implementado para reporte em uplink com bitmaps curtos dentro de um sistema GERAN da técnica conhecida;
[39] a figura 5 ilustra a arquitetura funcional de uma rede GSM/EDGE adequada para implementar um protocolo MAC/RLC modificado de acordo com o método da invenção;
[40] as figuras de 6 a 12 ilustram a estrutura de alguns blocos MAC/RLC ilustrativos modificados de acordo com o método da invenção.
Descrição Detalhada de uma Modalidade da Invenção [41] Com referência à figura 5, a arquitetura funcional GSM/EDGE apresentada inclui os seguintes blocos funcionais: MSs (TE e MT), BSS (ambos BTSs e BSC), SGSN, GGSN, EIR, MSC/VLR, HLR, SMS-GMSC, SMS-IWMSC e SM-SC. Dentro da MS o primeiro bloco funcional TE é conectado ao segundo bloco funcional MT através de uma conexão indicada por um ponto de referência R, tipicamente suportando uma interface serial padrão. As interfaces a seguir são previstas: Um, A-bis, A, Gb, Gi, GP, Gn, GP, Gf, Gs, Gr, Gd, D, E, C, cuja conectividade entre os blocos relevantes é diretamente visível na figura.
[42] Cada MS (MT) é conectada a sua BTS servidora através de uma interface de rádio Um para permuta de serviços de voz e dados e sinalização relevante. A BSS inclui uma pluralidade de BTS conecta
Petição 870190071787, de 26/07/2019, pág. 13/29
11/20 das a um BSC através de uma interface A-bis respectiva. O BSC é conectado à rede de núcleo, basicamente incluindo MSC e SGSN, através das interfaces A e Gb que se responsabilizam pelo domínio permutado por circuito (CS) e domínio permutado por pacote (PS), respectivamente. BSSs anteriores evoluíram em GERANs a fim de permitir maiores rendimentos de dados e redundância incrementada quando blocos de dados errados são retransmitidos. Adicionalmente, a interface Gn conecta dois nós GSN no mesmo sistema PLMN, enquanto a interface GP conecta dois nós GSN pertencentes a diferentes sistemas PLMN.
[43] Em operação, nas interfaces Um e A-bis vários protocolos são empilhados na camada física, em particular: SNDCP, LLC, RLC e MAC. O protocolo SNDCP controla a transferência de unidades de protocolo de rede (N-PDUs) entre o móvel MS e o nó SGSN. As funções principais do protocolo SNDCP são:
[44] Multiplexação de protocolos de dados de pacote, por exemplo IP.
[45] Compressão/descompressão de pacotes de dados de usuário.
[46] Compressão/descompressão de informação de controle de protocolo.
[47] Segmentação de NPDUs dentro de quadros LLC e remontagem dos quadros LLC em NPDUs.
[48] Para realizar essas funções o protocolo SNDCP avalia um NSAPI para identificar no móvel MS o ponto de acesso para um protocolo de dados de pacote PDP, enquanto nos nós SGSN e GGSN identifica o contexto associado com um endereço do protocolo PDP mencionado acima.
[49] RLC fornece um link de rádio confiável e mapeia os quadros LLC dentro dos canais GSM físicos. RLC/MAC avalia os seguin
Petição 870190071787, de 26/07/2019, pág. 14/29
12/20 tes canais GPRS: PBCCH, PCCCH, PACCH e PDTCH portados no PDCH. O pacote MAC/RLC é mapeado em blocos de rádio do multiquadro GSM. Um bloco de rádio é transportado por quatro rajadas normais consecutivas. Na camada física as quatro rajadas normais são intercaladas em quatro quadros TDMA consecutivos de 4,615 ms de duração. O protocolo de camada de link física é responsável pelo código de bloco FEC que permite a detecção e correção de erro no receptor. Quatro esquemas de codificação de convolução (CS1, ..., CS4) são previstos para GPRS, e nove esquemas de modulação e codificação (CS1,...,CS9) para EGPRS, gerando taxas de bits diferentes.
[50] Os procedimentos de sinalização para acessar o canal de rádio são controlados por MAC, que também governa a alocação dinâmica dos recursos (solicitação e concessão). Alocação dinâmica significa que um recurso de transmissão em particular, consistindo, por exemplo, de um canal PDCH em uma partição de tempo física, é compartilhado por divisão de tempo entre mais móveis MS, cada um dos quais sendo engajado em uma sessão ativa de transferência de dados, ou sinalização, através do mesmo recurso de transmissão designado em conjunto. Para o objetivo específico de alocação dinâmica, o BSC inclui uma PCU implementando um algoritmo de programação proprietário.
[51] O subconjunto de procedimentos MAC que governa a multiplexação das transmissões nos canais compartilhados, fornece a MS a designação temporária de recursos, chamada de TBFs, na camada física para sustentar a transmissão única. Um TBF pode incluir armazenamento de memória para alojar as filas dos blocos MAC/RLC. Cada designação TBF permite a transferência unidirecional dos blocos de rádio (para dados de carga útil e sinalização) dentro de uma célula entre a rede e uma estação móvel MS ou vice-versa. As mensagens de controle para o estabelecimento/abatimento de uma conexão entre os
Petição 870190071787, de 26/07/2019, pág. 15/29
13/20 pontos de serviço e a alocação/desalocação dos recursos físicos suportados relevantes, por exemplo, os armazenadores TBF, contemplam diferentes oportunidades capazes de cobrir toda a pesquisa prevista no modo de transferência de pacote da subcamada RR. Por motivos de simplicidade, é descrita aqui uma pesquisa muito limitada de estabelecimento/abatimento das conexões TBF e dos modos de operação relevantes. Pode-se começar com o estabelecimento de uma conexão de uplink TBF seguindo uma Transferência de Pacote originada pelo móvel. Nesse caso o móvel exige a designação de um canal GPRS enviando uma mensagem de SOLICITAÇÃO DE CANAL DE PACOTE incluindo os recursos TBF solicitados para a transferência de pacotes para a rede. No caso de recepção, a rede responde com uma mensagem de DESIGNAÇÃO DE UPLINK DE PACOTE no canal de controle alocando para o móvel os recursos solicitados para a transferência em uplink dos pacotes. O recursos incluem um ou mais canais PDCH, isto é, pelo menos um portador e uma partição de tempo, e um valor TFI. A rede não designa qualquer armazenador temporário na direção de uplink (o armazenador temporário reside no móvel). A rede exige simplesmente conhecer o número de blocos que um MS móvel pretende transmitir. Pode-se prosseguir agora com o exame da designação de um downlink TBF seguindo uma Transferência de Pacote encerrada na direção do móvel. Nesse caso, no final do procedimento de rádio localização, a rede envia para o móvel uma mensagem de DESIGNAÇÃO DE DOWNLINK DE PACOTE no estado Pronto no canal de controle, com a lista de canais PDCH alocados para a transferência em downlink. Um armazenador temporário, relevante para TBF em downlink, é propositalmente alocado para conter os blocos MAC/RLC a serem enviados.
[52] Na maior parte dos casos um TBF é mantido vivo apenas para a transferência de uma ou mais unidades de protocolo LLC, para
Petição 870190071787, de 26/07/2019, pág. 16/29
14/20 a finalidade de transferência dos blocos MAC/RLC correspondentes. A rede designa para cada TBF seu próprio identificador temporário, chamado de TFI (Identidade de Fluxo Temporário). O móvel deve considerar que o valor TFI é singular dentre os competidores TBF em cada direção, uplink ou downlink. Um bloco de dados MAC/RLC é identificado para o TBF ao qual está associado através de seu próprio campo onde a TFI do identificador é escrita, e outro campo para indicar a direção de uplink e downlink do bloco. No caso de o bloco MAC/RLC ser referido como uma mensagem de controle, um campo é previsto para indicar a direção e o tipo de transmissão de mensagem. No caso de alocação dinâmica, o cabeçalho de cada bloco MAC/RLC transmitido em um canal PDCH na direção de downlink inclui um campo adicional chamado USF, que é utilizado pela rede na forma de um indicador para controlar a multiplexação por divisão de tempo de diferentes estações móveis em um canal físico PDCH na direção de uplink. Pode-se qualificar melhor agora a mensagem de DESIGNAÇÃO DE UPLINK DE PACOTE já mencionada, enviada pela rede na direção dos móveis, mencionando que inclui: uma TFI de identificador do armazenador TBF/downlink contendo o bloco de controle que porta essa mensagem, a lista de canais PDCH alocados (partições de tempo), e um valor USF correspondente para cada canal alocado (partição de tempo). Um USF é programado para a transmissão de um bloco de rádio. Três bits são previstos para o campo USF que permite se discriminar de forma não ambígua até oito usuários compartilhando uma partição de tempo, também no caso de limite no qual o armazenador TBF único é associado com oito partições de tempo de um quadro TDMA.
[53] De acordo com 3GPP TS 44.060 V7.3.0, subcláusula
9.1.8.1, a mensagem de ACK/NACK de pacote contém um número de seqüência inicial (SSN) e um bitmap de bloco recebido (RBB). A men
Petição 870190071787, de 26/07/2019, pág. 17/29
15/20 sagem ACK/NACK de pacote é enviada pelo receptor RLC e é recebida pelo transmissor RLC. SSN e RBB são determinados como definido nessa subcláusula e transmitidos nos modos de RLC de recebimento acusado, RLC de recebimento não-acusado e RLC não-persistente. SSN e RBB podem ser ignorados pelo transmissor RLC no modo de recebimento não acusado. RBB é definido como um conjunto de valor binário de elementos WS, onde o índice de cada elemento assume o valor de 0, 1, 2,..., WS-1 na ordem fornecida, respectivamente. Os valores BSN especificados em RBB são interpretados pela subtração da posição de bit no bitmap a partir da SNS de módulo do número de seqüência inicial (SSN).
[54] A presença do reporte com bitmaps pequenos pode ser comunicada pela rede para os móveis através da difusão de Informação de Sistema no Canal Comum lido pelos móveis periodicamente, ou alternativamente por meio de um elemento de informação dedicado durante o estabelecimento de um novo TBF. A pesquisa de legado ainda é necessária a fim de suportar as finalidades de MSs e LQC de legado para o móvel que suporta o reporte ACK/NACK rápido. O resultado seria uma taxa de repetição de pesquisa de legado substancialmente reduzida sendo aplicada para as MSs que suportam o reporte ACK/NACK rápido em comparação com as MSs que só suportam o esquema de reporte ACK/NACK de pacote de legado. A taxa de repetição da pesquisa de legado precisa também ser escolhida para lidar com o caso quando o bitmap curto move para fora da janela de mapa de bit curto com erros.
[55] Para a co-existência entre o reporte de legado rápido e estendido é necessário se considerar: a) reporte de ACK/NACK enviado na direção de uplink; b) reporte ACK/NACK enviado na direção de downlink.
[56] Caso a) - O reporte ACK/NACK enviado na direção de
Petição 870190071787, de 26/07/2019, pág. 18/29
16/20 uplink. O objetivo é manter a rede em controle de com que freqüência uma MS pode enviar reportes ACK/NACK. O reporte é comandado utilizando os campos de pesquisa (RRBP) e USF na direção de downlink como descrito em GP-060755 - Anexo A, subcláusula 10.2.1.5.2 já mencionada na introdução.
[57] Caso b) - O reporte ACK/NACK enviado na direção de downlink. A fim de que a estação móvel determine que um reporte ACK/NACK está incluído no bloco de dados, o receptor precisa saber isso, se possível sem qualquer decodificação dupla. Uma redefinição dos campos RRBP e ES/P no cabeçalho dos blocos de dados DL EGPRS pode ser utilizada como descrito em GP-060755 - Anexo A, subcláusula 10.2.1.5.3 já mencionada na introdução.
[58] Com referência à figura 6, observa-se uma nova estrutura de bloco MAC/RLC UL/DL modificada de modo a incluir um bitmap curto no cabeçalho. Os detalhes do novo cabeçalho para um bloco de downlink EGPRS é reportado na figura 10, enquanto para um bloco de uplink EGPRS é reportado na figura 11, os campos além do bitmap curto são descritos em 3GPP TS 44.060 V7.3.0. O bitmap curto é completado utilizando-se as regras de codificação reportadas na tabela da figura 3. A sincronização entre a transmissão e a recepção é necessária para se implementar a retransmissão com base nos bitmaps curtos ao invés de BSNs assíncronas. O espaço mínimo reservado de dois octetos é responsável pelo número máximo de blocos programados dentro da janela de tempo dos últimos 20 ms únicos, para, digamos, dois blocos de dados RLC EGPRS para cada um das oito partições de tempo do quadro. O rótulo TS1,1 significa o bloco de dados RLC EGPRS 1 na partição de tempo 1, e assim por diante. Espaço adicional pode ser fornecido no cabeçalho para estender a janela de reporte. Nesse caso, dois octetos podem ser adicionados para cada período de observação de 20 ms adicional. Alternativamente, o espaço
Petição 870190071787, de 26/07/2019, pág. 19/29
17/20 reservado no cabeçalho para o bitmap curto é apenas o efetivamente necessário com base na programação real.
[59] Na figura 7, observa-se a estrutura de um novo bloco MAC/RLC de downlink, modificado de modo a incluir um bitmap curto no cabeçalho e também em uma nova zona de difusão/multidifusão (B/M), alocada de forma proveitosa entre o cabeçalho e a parte de dados.
[60] Na figura 8, o bitmap curto é alocado apenas na zona B/M do bloco MAC/RLC de downlink. A estrutura de bloco representada na figura 8 é detalhada na figura 12.
[61] Na figura 9, observa-se a estrutura de um novo bloco MAC/RLC de uplink, modificada de modo a incluir um bitmap curto em uma nova zona, alocada de forma proveitosa entre o cabeçalho e a parte de dados.
[62] Em operação, o tipo de bloco MAC/RLC de downlink visível na figura 7 e na figura 8 para o transporte do bitmap curto é comunicado pela rede para as MSs. Para todos os tipos de novo bloco MAC/RLC contendo o bitmap curto na dita zona nova como nas figuras 7 a 9, o comprimento da nova zona é comunicado no cabeçalho do bloco MAC/RLC.
[63] Com referência à figura 12, a estação de base prepara um bitmap curto fornecendo retorno para todos os TBFs de todas as estações móveis alocadas nas mesmas partições de tempo, para uma janela de reporte de um ou mais períodos de bloco. O conhecimento do retardo fixo entre o bloco de rádio de uplink anterior considerado na janela de reporte e o bloco de rádio real que porta a parte B/M, permite automaticamente que os móveis retransmitam os blocos de rádio com erro mapeados na sinalização ACK/NACK recebida de volta, começando com o primeiro. A zona B/M é codificada de forma mais robusta do que a robustez utilizada para a codificação adaptativa da parte de
Petição 870190071787, de 26/07/2019, pág. 20/29
18/20 dados restantes. Considerando que a zona B/M entre o cabeçalho e a parte de dados já contém a informação ACK/NACK para todos os TBFs, o bitmap curto incluído no cabeçalho do bloco MAC/RLC de downlink da figura 7 pode ser reduzido ou eliminado.
[64] Com base na descrição acima algumas modificações po- dem ser introduzidas na modalidade ilustrativa pelos versados na técnica sem se distanciar do escopo da invenção. É, dessa forma contemplado que a presente invenção engloba toda e qualquer modalidade coberta pelas reivindicações a seguir.
Acrônimos Utilizados
3GPP Programa de parceria de 3a. geração
ACK Aviso de recebimento (modo)
ARQ solicitação de repetição automática
BCCH Canal de controle de difusão
BS estação de base
BSC controlador de estação de base
BSN número de seqüência de bloco
BSS subsistema de estação de base
BTS estação transceptora de base
CCCH canal de controle comum
CRC verificação de redundância cíclica
CS esquema de codificação comutado por circuito
DL downlink
E bit de extensão
EDGE taxas de dados melhoradas para evolução GSM
EGPRS GPRS melhorado
ES/P pesquisa estendida/suplementar
FACCH canal de controle associado rápido
FBP primeiro bitmap parcial
GERAN rede de acesso de rádio GSM/EDGE
Petição 870190071787, de 26/07/2019, pág. 21/29
19/20
GGSN GSN de circuito de acesso
GMSC MSC de circuito de acesso
GPRS serviço de rádio de pacote geral
GSM sistema global para comunicações móveis
IP protocolo internet
IWMSC MSC de InterTrabalho
LI Indicador de comprimento
LLC controle de link lógico
LQC controle de qualidade de link
MAC protocolo de acesso a meio
MBMS serviço de multidifusão de difusão de multimídia
MCS esquema de modulação e codificação
MS estação móvel
MSC centro de comutação de mensagem
MT móvel terminado
NACK não aviso de recebimento (modo)
NPB próximo bitmap parcial
NPDU PDU de rede
NSAPI SAPI de rede
PACCH canal de controle associado de pacote
PBCCH canal de controle de difusão de pacote
PCCCH canal de controle comum de pacote
PCU unidade de controle de pacote
PDAN ACK/NACK de downlink de pacote
PDTCH canal de tráfego de dados de pacote
PDCH canal de dados de pacote
PDU unidade de dados de protocolo
PFI identificador de fluxo de pacote
PLMN rede móvel terrestre pública
PS Pacote comutado
Petição 870190071787, de 26/07/2019, pág. 22/29
20/20
PUAN ACK/NACK de uplink de pacote
RAN rede de acesso de rádio
RBB bitmap de bloco recebido
RLC controle de link de rádio
RRBP período de bloco reservado relativo
RTT tempo de percurso de ida e volta
RTTI TTI reduzida
SAPI identificador de ponto de acesso de serviço
SGSN nó de suporte GPRS de serviço
SMS serviço de mensagem curta
SNS espaço de número de seqüência
SNDCP protocolo de convergência dependente de subrede
TBF fluxo de bloco temporário
TFI identificador TBF
TLLI indicador de link lógico temporário
TTI intervalo de tempo de transmissão
UL uplink
USF indicador de estado de uplink
VLR registro de localização de visitante
VoIP voz através de IP
WS tamanho de janela
Petição 870190071787, de 26/07/2019, pág. 23/29

Claims (3)

  1. REIVINDICAÇÕES
    1. Método para transmissão de retorno para uma primeira unidade de bitmaps de Aviso de recebimento/Aviso de não recebimento, ACK/NACK gerados por uma segunda unidade (BTS, MS) no contexto de sinalização de solicitação de repetição automática, ARQ dentro de um sistema de rádio móvel, em que as transmissões programadas para um fluxo em bloco temporário, chamadas TBF, se beneficiam de pelo menos um portador acessado na divisão de tempo durante partições de tempo de quadros seqüenciais para o transporte de blocos de rádio de controle de link de rádio/controle de acesso a meio, RLC/MAC, cada um constituído de um cabeçalho e uma parte de dados de carga útil distribuídos em um conjunto de partições de tempo alocados intercalados entre um número predeterminado de quadros, em que o bitmap ACK/NACK inclui tantos bits quantos blocos RLC/MAC recebidos em uma janela de tempo abrangendo um ou mais períodos de blocos predeterminados antes de um ponto de tempo inicial conhecido da primeira e segunda unidades, o valor lógico de cada bit indicando blocos RLC/MAC decodificados com erro ou corretamente, de modo a permitir a retransmissão pela primeira unidade dos blocos mapeados como decodificados com erro pela segunda unidade, o dito bitmap ACK/NACK sendo codificado pela segunda unidade independentemente do código de redundância da parte de dados de carga útil, utilizando um esquema de modulação e codificação para o bitmap ACK/NACK mais robusto contra erros do que a robustez do esquema de modulação e codificação utilizado na parte de dados de carga útil caracterizado pelo fato de que dito bitmap ACK/NACK é alocado em uma terceira parte (B/M) do dito bloco RLC/MAC transmitido em downlink por uma segunda unidade configurada como uma estação de base (BTS) na direção de uma pluralidade de primeiras unidades configuradas como estações móveis (MS), a dita terceira parte (B/M) sendo co
    Petição 870190071787, de 26/07/2019, pág. 24/29
  2. 2/2 dificada independentemente com relação a ambos o cabeçalho e a parte de dados de carga útil do dito bloco RLC/MAC e sendo acessada por todas as estações móveis (MS) alocadas nas mesmas partições de tempo.
    2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a presença e o comprimento da dita terceira parte são comunicados no cabeçalho do bloco RLC/MAC.
  3. 3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a dita terceira parte (B/M) do bloco RLC/MAC transmitido em downlink fornece informação de retorno para todos os TBFs de todas as estações móveis alocadas nas mesmas partições de tempo, para uma janela de reporte de um ou mais períodos de bloco.
BRPI0712095-8A 2006-05-16 2007-05-15 método para transmissão de retorno para uma primeira unidade de bitmaps de aviso de recebimento/aviso de não recebimento ack/nack BRPI0712095B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP06425330A EP1858190B1 (en) 2006-05-16 2006-05-16 Method for safely transmitting short ACK/NACK bitmaps in ARQ process inside edge compliant systems
EP06425330.5 2006-05-16
PCT/EP2007/004303 WO2007131768A1 (en) 2006-05-16 2007-05-15 Method for safely transmitting short ack/nack bitmaps in arq process inside edge compliant systems

Publications (2)

Publication Number Publication Date
BRPI0712095A2 BRPI0712095A2 (pt) 2012-03-06
BRPI0712095B1 true BRPI0712095B1 (pt) 2019-11-12

Family

ID=36992773

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0712095-8A BRPI0712095B1 (pt) 2006-05-16 2007-05-15 método para transmissão de retorno para uma primeira unidade de bitmaps de aviso de recebimento/aviso de não recebimento ack/nack

Country Status (9)

Country Link
US (1) US8176377B2 (pt)
EP (1) EP1858190B1 (pt)
CN (1) CN101444031B (pt)
AT (1) ATE541378T1 (pt)
BR (1) BRPI0712095B1 (pt)
ES (1) ES2380787T3 (pt)
PL (1) PL1858190T3 (pt)
RU (1) RU2430477C2 (pt)
WO (1) WO2007131768A1 (pt)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4410282B2 (ja) * 2006-01-18 2010-02-03 パナソニック株式会社 無線送信装置および無線送信方法
EP2158714B1 (en) 2007-05-04 2019-08-21 Nokia Solutions and Networks Oy Aggregated harq report
TWI444001B (zh) 2007-05-08 2014-07-01 Interdigital Tech Corp 搭載正確認/負確認欄位指示器及輪詢指示器提供方法及裝置
KR101454482B1 (ko) * 2007-05-17 2014-10-27 삼성전자주식회사 무선 통신 시스템에서 공통 제어 정보 송수신 시스템 및방법
US8995422B2 (en) * 2007-06-21 2015-03-31 Interdigital Technology Corporation Signaling in a wireless communication system
EP2654233A3 (en) * 2007-10-01 2017-09-06 Interdigital Patent Holdings, Inc. Method and apparatus for configuration of EGPRS time-based acknowledgement
US20100027503A1 (en) * 2008-07-31 2010-02-04 Qualcomm Incorporated Method and apparatus for reducing data loss during handover in a wireless communication system
KR101421740B1 (ko) 2008-09-23 2014-07-24 엘지전자 주식회사 비정상적 상황을 처리하는 이동국
WO2010108257A1 (en) 2009-03-23 2010-09-30 Research In Motion Limited Systems and methods for allocating and transmitting uplink data block transmissions with piggy-backed ack/nack bitmap
WO2010108259A1 (en) 2009-03-23 2010-09-30 Research In Motion Limited Systems and methods for allocating and transmitting uplink data block transmissions
RU2495531C2 (ru) * 2009-05-12 2013-10-10 Хуавэй Текнолоджиз Ко., Лтд. Способы, системы и устройства для получения, интерпретации и подтверждения состояния приема данных
US8897252B2 (en) * 2009-06-17 2014-11-25 Htc Corporation Method for transmitting data in a wireless communication system and system thereof
GB2474006B (en) * 2009-08-11 2012-05-02 Samsung Electronics Co Ltd Network element, wireless communication units and methods for scheduling communications
CN101997641B (zh) * 2009-08-18 2013-10-16 中兴通讯股份有限公司 一种提高分组传输速率的方法及系统
US20110069669A1 (en) * 2009-09-11 2011-03-24 Research In Motion Limited System and methods for sending and receiving pan (piggy-backed ack/nack) so as to avoid decoding confusion
CN102577212B (zh) * 2009-10-30 2015-06-17 三星电子株式会社 无线通信系统中产生自动重传请求反馈消息的装置及方法
KR101883425B1 (ko) 2011-08-01 2018-07-31 삼성전자주식회사 휴대 단말기를 이용하는 위폐 감별법
CN103220248B (zh) * 2012-01-18 2016-03-02 电信科学技术研究院 一种数据传输方法和设备
US9608789B2 (en) 2012-05-11 2017-03-28 Interdigital Patent Holdings, Inc. Method and apparatus for transmitting acknowledgements in response to received frames
DE102012210816A1 (de) 2012-06-26 2014-01-02 Siemens Aktiengesellschaft Datenpaket für eine bidirektionale Übertragung von Datenpaketen bei einer Datenübertragung zwischen einem ersten und einem zweiten Kommunikationsgerät sowie Verfahren zum Übertragen eines solchen Datenpaketes
WO2014077764A1 (en) * 2012-11-13 2014-05-22 Telefonaktiebolaget L M Ericsson (Publ) Extension of radio link control transmit window
US9451417B2 (en) * 2013-11-27 2016-09-20 Qualcomm Incorporated System and method for multicast communications in Wi-Fi networks
CN103944690B (zh) * 2014-04-28 2017-05-17 南京熊猫电子股份有限公司 一种rlc数据重传系统中的位图压缩方法
US20160212749A1 (en) * 2015-01-19 2016-07-21 Qualcomm Incorporated Systems and methods for use of multiple modulation and coding schemes in a physical protocol data unit
KR101755224B1 (ko) * 2015-06-09 2017-07-11 한국철도기술연구원 인덱스 코딩과 통계적 특성을 이용한 데이터 재전송 시스템 및 방법
CN105119695A (zh) * 2015-09-17 2015-12-02 清华大学 一种基于快速否定应答的空间文件传输方法
EP4016893B1 (en) * 2017-06-28 2024-10-16 Telefonaktiebolaget LM ERICSSON (PUBL) Operation of a user equipment and a receiving radio node based on a harq codebook, configured by a configuring radio node
US10707995B2 (en) * 2017-06-29 2020-07-07 Qualcomm Incorporated Method and apparatus for downlink retransmission under unreliable code block group (CBG) level feedback
WO2019028703A1 (zh) * 2017-08-09 2019-02-14 Oppo广东移动通信有限公司 一种反馈应答信息的长度确定方法及相关产品
US11582638B2 (en) 2019-01-03 2023-02-14 Qualcomm Incorporated Selective relay of data packets
CN112866956B (zh) * 2019-11-27 2023-05-02 成都鼎桥通信技术有限公司 语音数据的传输方法、装置、设备及存储介质
US11750324B2 (en) * 2021-11-30 2023-09-05 Analog Devices International Unlimited Company Methods for adaptive error avoidance to increase re-transmission reliability in time-slotted communication links
CN115816338B (zh) * 2023-01-09 2023-05-02 无锡万奈特测量设备有限公司 一种汽车减震塔多点自动测量定位设备
WO2025234734A1 (ko) * 2024-05-09 2025-11-13 엘지전자 주식회사 무선 통신 시스템에서 단말에 의해 개시되는 보고를 수행하는 방법 및 장치

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6975582B1 (en) * 1995-07-12 2005-12-13 Ericsson Inc. Dual mode satellite/cellular terminal
US5828677A (en) * 1996-03-20 1998-10-27 Lucent Technologies Inc. Adaptive hybrid ARQ coding schemes for slow fading channels in mobile radio systems
US6778558B2 (en) * 1998-02-23 2004-08-17 Lucent Technologies Inc. System and method for incremental redundancy transmission in a communication system
EP0996248A1 (en) * 1998-10-21 2000-04-26 Telefonaktiebolaget L M Ericsson (Publ) ARQ protocol with packet-based reliability level setting
US6772215B1 (en) * 1999-04-09 2004-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Method for minimizing feedback responses in ARQ protocols
US7000174B2 (en) * 1999-12-20 2006-02-14 Research In Motion Limited Hybrid automatic repeat request system and method
FR2821505B1 (fr) * 2001-02-23 2003-06-13 Nortel Networks Ltd Procede de transmission de donnees en mode acquitte entre une unite de controle et un terminal, et unite de controle mettant en oeuvre un tel procede
US6665280B2 (en) * 2002-03-22 2003-12-16 Nokia Corporation Method and apparatus providing multiple temporary block flow (TBF) mapping to upper layer when operating in GSM/EDGE radio access network (GERAN) A/Gb mode
EP2755345B1 (en) * 2003-03-31 2020-04-29 Apple Inc. A radio telecommunications system and method of operating the same with polling
MXPA05011936A (es) 2003-05-22 2006-02-02 Kimberly Clark Co Metodo para evaluar el rendimiento de un producto usando un medio ambiente virtual.
WO2005070031A2 (en) * 2004-01-22 2005-08-04 The Regents Of The University Of California Systems and methods for resource allocation of multiple antenna arrays
FI116114B (fi) * 2004-01-27 2005-09-15 Nokia Corp Kuittausviestien käsittely päätelaitteessa
FR2868646B1 (fr) * 2004-03-31 2006-07-14 Evolium Sas Soc Par Actions Si Dispositif et procede perfectionnes de gestion de transmission de blocs de donnees dans un canal descendant de type hs-dsch d'un reseau de communications mobile
JP4012172B2 (ja) * 2004-05-28 2007-11-21 株式会社東芝 無線通信装置及び無線通信方法
WO2006016745A1 (en) * 2004-08-12 2006-02-16 Samsung Electronics Co., Ltd. Method and apparatus for transmitting ack frame
KR100678943B1 (ko) * 2004-08-24 2007-02-07 삼성전자주식회사 블록 ack 프레임 전송방법 및 장치
CA2590856C (en) * 2004-12-27 2013-06-11 Lg Electronics Inc. Allocating data bursts and supporting hybrid auto retransmission request in orthogonal frequency division multiplexing access radio access system

Also Published As

Publication number Publication date
WO2007131768A1 (en) 2007-11-22
EP1858190B1 (en) 2012-01-11
PL1858190T3 (pl) 2012-06-29
RU2008149507A (ru) 2010-06-27
US8176377B2 (en) 2012-05-08
EP1858190A1 (en) 2007-11-21
US20100011273A1 (en) 2010-01-14
BRPI0712095A2 (pt) 2012-03-06
CN101444031B (zh) 2012-08-08
ATE541378T1 (de) 2012-01-15
CN101444031A (zh) 2009-05-27
ES2380787T3 (es) 2012-05-18
RU2430477C2 (ru) 2011-09-27

Similar Documents

Publication Publication Date Title
BRPI0712095B1 (pt) método para transmissão de retorno para uma primeira unidade de bitmaps de aviso de recebimento/aviso de não recebimento ack/nack
US8582538B2 (en) Scheduling grant information signaling in wireless communication system
US9198192B2 (en) Method for transmitting short language signaling in MAC-e PDU
JP3955462B2 (ja) データの送信方法
WO2007112698A1 (fr) Procédé et appareil d'envoi d'accusé de réception ou non (ack/nack)
US8144703B2 (en) Method to reduce the transmission latency in GSM/EDGE delay-sensitive applications
CN102349346A (zh) 无线通信系统中的资源分配
US12452003B2 (en) Hybrid automatic repeat request codebook generation in wireless communication systems
EP2777316A1 (en) Methods and devices for providing tfi
TWI321922B (en) Method for ack/nack signalisation
KR20090109042A (ko) 수신긍정확인 채널 할당방법
US20070249343A1 (en) Method and system of communications
JP2009534917A (ja) 無線通信システムにおける肯定確認応答と否定確認応答とを送信する方法、通信エンティティ、及びシステム
WO2007118703A1 (en) Method to reduce the transmission latency in gsm/edge delay-sensitive applications
EP2060072B1 (en) High-speed data packet transmission scheme
CN101304599B (zh) 一种改进快速应答时解读短位图的方法,装置及终端
CN101174928A (zh) 短位图上报方法、系统及设备

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06T Formal requirements before examination [chapter 6.20 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 12/11/2019, OBSERVADAS AS CONDICOES LEGAIS. (CO) 10 (DEZ) ANOS CONTADOS A PARTIR DE 12/11/2019, OBSERVADAS AS CONDICOES LEGAIS