BRPI0807851B1

BRPI0807851B1 - Solicitações de recursos para um sistema de comunicação sem fio

Info

Publication number: BRPI0807851B1
Application number: BRPI0807851-3A
Authority: BR
Inventors: Rajat Prakash; Fatih Ulupinar; Arnab Das; Mohammad Jaber Borran; Alexei Gorokhov
Original assignee: Qualcomm Incorporated
Priority date: 2007-01-30
Filing date: 2008-01-30
Publication date: 2020-03-03
Also published as: JP4988865B2; EP2111723A2; CN105636123A; TWI479900B; AU2008210413B2; MX2009008072A; JP2010517490A; RU2437254C2; BRPI0807851A2; CN101595750A; US8743774B2; US20080186931A1; TW200850025A; EP2111723B1; CA2675577C; KR101079994B1; IL199824A0; WO2008095042A3; AU2008210413A1; CA2675577A1

Abstract

solicitações de recursos para um sistema de comunicação sem fio técnicas para enviar solicitações de recursos em um sistema se comunicação sem fio são descritas. múltiplos tipos de informações de qualidade de serviço (qos) podemser suportados para solicitações de recursos e podem incluir classe qos e prazo de latência. um terminal pode possuir dados a enviar no link reverso e pode determinar informações de qos para os dados. as informações de qos podem incluir pelo menos um tipo de qos, que pode ser dependente de uma configuração selecionada para uso ao enviar solicitações de recursos. o terminal também pode determinar informações de nível de backlog indicativas da quantidade de dados a enviar. o terminal pode gerar uma solicitação de recursos com o nível de backlog e informações de qos. a solicitação de recursos pode incluir informações de nível de backlog e informações de classe qos, as informações de nível de backlog e ou informações de classe qos ou informações de prazo de latência, as informações de nível de backlog e informações de prazo de latência, ou algumas outras combinações de informações.

Description

“SOLICITAÇÕES DE RECURSOS PARA UM SISTEMA DE COMUNICAÇÃO SEM FIO”

CAMPO DA INVENÇÃO [0001] A presente revelação diz respeito, de forma geral, a comunicação, e mais especificamente a técnicas para solicitar por recursos de rádio em um sistema de comunicação sem fio.

DESCRIÇÃO DA TÉCNICA ANTERIOR [0002] Sistemas de comunicação sem fio são amplamente aplicados para proverem vários conteúdos de comunicação tais como, voz, vídeo, pacotes de dados, troca de mensagens, difusão (broadcast), etc. Estes sistemas sem fio podem ser sistemas de acesso múltiplo capazes de suportar múltiplos usuários pela divisão dos recursos de sistema disponíveis. Exemplos de tais sistemas de múltiplo acesso incluem sistemas de Acesso Múltiplo por Divisão de Código (CDMA), sistemas de Acesso Múltiplo por Divisão de Tempo (TDMA), sistemas de Acesso Múltiplo por Divisão de Frequência (FDMA), sistemas de FDMA Ortogonal (OFDMA), e sistemas FDMA de Portadora Única (SC-FDMA).

[0003] Um sistema de comunicação sem fio pode incluir muitas estações base que podem suportar comunicação para muitos terminais nos links reverso e direto. O link direto (ou downlink) se refere ao link de comunicação a partir das estações base para os terminais, e o link reverso (ou uplink) se refere ao link de comunicação a partir dos terminais para as estações base. O sistema pode utilizar um esquema de atribuição de recursos no qual um terminal pode enviar uma solicitação por recurso de rádio sempre que o terminal possui dados para enviar no link reverso. Em geral, recursos de rádio podem incluir tempo, frequência, código, potência, e/ou outros tipos de recursos utilizáveis para transmissão. Uma estação base pode processar a

Petição 870190114871, de 08/11/2019, pág. 6/45

2/33 solicitação de recursos a partir do terminal e pode enviar uma concessão de recursos de rádio para o terminal. O terminal pode então transmitir dados no link reverso usando os recursos concedidos. Recursos de link reverso são consumidos para enviar solicitações de recursos. Existe, portanto, uma necessidade no estado da arte por técnicas para enviar de forma eficiente solicitações de recursos.

RESUMO DA INVENÇÃO [0004] Técnicas para enviar solicitações de recursos em um sistema de comunicação sem fio são descritas aqui. Em um aspecto, múltiplos tipos de informações de Qualidade de Serviço (QoS) podem ser suportados para solicitações de recursos e podem incluir classe QoS e prazo de latência. Um terminal pode possuir dados para enviar no link reverso e pode determinar informações de QoS para os dados. As informações de QoS podem compreender pelo menos um tipo de QoS, o qual pode ser dependente de uma configuração selecionada para uso ao enviar solicitações de recursos. O terminal também pode determinar informações de nível de backlog indicativas da quantidade de dados a enviar. O terminal pode gerar e enviar uma solicitação de recursos compreendendo as informações de nível de backlog e as informações de QoS. Em um modelo, a solicitação de recursos pode incluir (i) as informações de nível de backlog e informações de classe QoS para uma primeira configuração, (ii) as informações de nível de backlog e tanto informações de classe QoS quanto informações de prazo de latência para uma segunda configuração, ou (iii) as informações de nível de backlog e informações de prazo de latência para uma terceira configuração. A solicitação de recursos pode também incluir alguma outra combinação de informações para outros modelos.

Petição 870190114871, de 08/11/2019, pág. 7/45

3/33 [0005] Em outro aspecto, múltiplos formatos podem ser suportados para solicitações de recursos. Um terminal pode determinar pelo menos um tipo de informações para enviar em uma solicitação de recurso. O terminal pode determinar um formato a usar para a solicitação de recursos dentre múltiplos formatos com base no pelo menos um tipo de informações para envio. Os múltiplos formatos podem incluir um primeiro formato para informações de QoS e de nível de backlog e um segundo formato para somente nível de backlog. O terminal pode gerar a solicitação de recursos compreendendo pelo menos um tipo de informações no formato determinado. Em um modelo, a solicitação de recursos pode possuir um número fixo de bits (por exemplo, 6 bits) para todos os formatos, o primeiro formato pode corresponder a uma primeira faixa de valores (por exemplo, de 0 a 47), e o segundo formato pode corresponder a uma segunda faixa de valores (por exemplo, 48 a 63).

[0006] Vários aspectos e características da revelação são descritos em maiores detalhes abaixo.

BREVE DESCRIÇÃO DAS FIGURAS [0007] Figura 1 mostra um sistema de comunicação sem fio.

[0008] Figura 2 mostra um modelo de superquadro.

[0009] Figura 3 mostra um modelo de uma solicitação de recursos.

[0010] Figura 4 mostra outra representação da solicitação de recursos.

[0011] Figuras 5 e 6 mostram um processo e um equipamento, respectivamente, para enviar solicitações de recursos com informações de QoS.

[0012] Figuras 7 e 8 mostram um processo e um equipamento, respectivamente, para enviar solicitações de recursos com formatos diferentes.

Petição 870190114871, de 08/11/2019, pág. 8/45

4/33 [0013] Figuras 9 e 10 mostram outro processo e outro equipamento, respectivamente, para enviar solicitações de recursos com informações de QoS.

[0014] Figuras 11 e 12 mostram um processo e um equipamento, respectivamente, para enviar solicitações de recursos considerando eficiência espectral.

[0015] Figuras 13 e 14 mostram um processo e um equipamento, respectivamente, para enviar mensagens de controle com recuo.

[0016] Figura 15 mostra um diagrama de blocos de uma estação base e um terminal.

DESCRIÇÃO DETALHADA DA INVENÇÃO [0017] A Figura 1 mostra um sistema de comunicação sem fio 100, que também pode ser referido como uma rede de acesso (NA). Sistema 100 pode incluir múltiplas estações base 110. Uma estação base é uma estação que se comunica com os terminais e também pode ser referida como um ponto de acesso, um nó B, um nó B expandido, etc. Cada estação base provê cobertura de comunicação para uma área geográfica em particular. Um controlador de sistema 130 pode se acoplar a estações base 110 e prover coordenação e controle para essas estações base.

[0018] Terminais 120 podem ser dispersos por todo o sistema, e cada terminal pode ser estacionário ou móvel. Um terminal também pode ser referido como um terminal de acesso (AT), uma estação móvel, um equipamento de usuário, uma estação de assinante, uma estação, etc. Um terminal pode ser um telefone celular, um assistente digital pessoal (PDA), um dispositivo de comunicação sem fio, um modem sem fio, um dispositivo portátil, um computador laptop, um telefone sem fio, etc. Um terminal pode se comunicar com zero, uma, ou múltiplas estações base no link direto e/ou no link reverso em qualquer dado momento.

Petição 870190114871, de 08/11/2019, pág. 9/45

5/33 [0019] As técnicas descritas aqui podem ser usadas para vários sistemas de comunicação sem fio, tais como sistemas CDMA, TDMA, FDMA, OFDMA e SC-FDMA. Os termos sistemas e rede são frequentemente usados de forma intercambiável. Um sistema CDMA pode implementar uma tecnologia de radio, tal como cdma2000, Rádio-Acesso Terrestre Universal (UTRA), etc. Um sistema OFDMA pode implementar uma tecnologia de rádio, tal como Banda Larga Ultra Móvel (UMB), UTRA evoluída (E-UTRA), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM®, etc. A UTRA e E-UTRA são descritas em documentos de uma organização chamada 3rd Generation Partnership Project (3GPP). O cdma2000 e UMB são descritos em documentos de uma organização chamada 3rd Generation Partnership Project 2 (3GPP2) . Essas várias tecnologias de rádio e padrões são bem conhecidas na técnica.

[0020] Para maior clareza, certos aspectos das técnicas são descritos abaixo para UMB, e terminologia UMB é usada em grande parte da descrição abaixo. UMB utiliza uma combinação de Multiplexação por Divisão de Frequência Ortogonal (OFDM) e Multiplexação por Divisão de Código (CDM). UMB é descrita no 3GPP2 C.S0084-001, intitulada Camada Física para Especificação de Interface aérea de Banda larga Ultra Móvel (UMB), C.S0084-002, intitulada Camada de Controle de Acesso ao Meio para Especificação de Interface Aérea de Banda Larga Ultra Móvel (UMB) e C.S0084-003, intitulada Camada de Link de Rádio para Especificação de Interface Aérea de Banda Larga Ultra Móvel (UMB), todas datadas de agosto de 2007 e publicamente disponíveis.

[0021] A Figura 2 mostra um modelo de uma estrutura de superquadro 200 que pode ser usado para o link reverso. A linha de tempo de transmissão pode ser particionada em

Petição 870190114871, de 08/11/2019, pág. 10/45

6/33 unidades de superquadros. Cada superquadro pode abranger uma duração de tempo particular, que pode ser fixa ou configurável. Cada superquadro pode ser particionado em quadros de M camadas físicas (PHY), onde em geral M > 1. Em um modelo, M = 25, e aos 25 quadros PHY em cada superquadro são atribuídos índices de 0 até 24. Cada quadro PHY pode cobrir N períodos de símbolos OFDM, onde em geral N > 1 e em um modelo N = 8.

[0022] Figura 2 também mostra uma estrutura de subportadora. A largura de banda do sistema pode ser particionada em múltiplas (K) subportadoras ortogonais, que também pode ser referida como tons, faixas (bins), etc. O espaçamento entre subportadoras adjacentes pode ser fixo, e o número de subportadoras pode ser dependente da largura de banda do sistema. Por exemplo, podem ter 128, 256, 512, 1024 ou 2048 subportadoras para largura de banda do sistema de 1,25, 2,5, 5, 10 ou 20 MHz, respectivamente.

[0023] A Figura 2 também mostra um modelo de um segmento CDMA que pode suportar transmissão de piloto, sinalização, e alguns dados de tráfego no link reverso. O segmento CDMA pode suportar um ou mais canais físicos, tais como, um Canal de Controle Dedicado CDMA Reverso (RCDCCH). O R-CDCCH pode transportar um ou mais canais lógicos, tais como, um canal de solicitação de link reverso (r-reqch). O segmento CDMA pode ocupar um bloco de recursos de freqüência e tempo que pode ser de qualquer dimensão. Em um modelo, o segmento CDMA pode incluir C subsegmentos CDMA, onde, em geral C ã 1. Cada subsegmento CDMA pode cobrir S subportadoras contíguas em N períodos de símbolos OFDM em um quadro PHY, onde S = 128 em um modelo.

[0024] No modelo mostrado na Figura 2, o segmento CDMA é enviado em todos os Q quadros PHY, onde em geral Q ã 1 e

Petição 870190114871, de 08/11/2019, pág. 11/45

7/33 como alguns exemplos Q = 4, 6, 8, etc. O segmento CDMA pode saltar através da largura de banda do sistema ao longo do tempo (como mostrado na Figura 2) ou pode ser enviado em um conjunto fixo de subportadoras (não mostrado na Figura 2). Múltiplos terminais podem dividir o segmento CDMA para piloto, sinalização, etc.

[0025] A um terminal pode ser atribuído um recurso de link reverso para um Canal de Dados OFDMA Reverso (RODCH). Em um modelo, os recursos alocados podem ser dados em unidades de tiles. Um tile pode ser um bloco de recursos de frequência e tempo e pode cobrir um número predeterminado de subportadoras em um número predeterminado de períodos de símbolos. Em um modelo, um tile cobre 16 subportadoras em 8 períodos de símbolos de um quadro PHY e pode ser usado para enviar até 128 símbolos. Os tiles atribuídos podem saltar através da largura de banda do sistema com base em um padrão de saltos, como mostrado na Figura 2. O terminal pode transmitir dados e/ou sinalizar em banda nos tiles alocados.

[0026] O terminal pode se comunicar com a rede de acesso para configurar um ou mais fluxos. Cada fluxo pode ser uma coleção de uma ou mais correntes. Cada corrente pode ser uma coleção de uma ou mais aplicações de camadas maiores e pode transportar dados e/ou informações de controle para uma ou mais aplicações. Cada aplicação pode ser associada a uma reserva, a qual pode compreender um conjunto de filtros de pacote para identificar pacotes para aquela aplicação. Por exemplo, aplicações diferentes, tais como, Protocolo de Transferência de Hipertexto (HTTP), Protocolo de Transferência de Arquivo (FTP), voz, e vídeo podem ser mapeados para uma ou mais correntes transportadas por um ou mais fluxos. Cada aplicação pode

Petição 870190114871, de 08/11/2019, pág. 12/45

8/33 possuir certos requisitos. O terminal pode relatar os requisitos de aplicações ativadas usando perfis ou blobs de QoS. A rede de acesso pode determinar os requisitos de QoS para cada fluxo com base nos perfis ou blobs de QoS relatados para todas as aplicações mapeadas para aquele fluxo. Cada fluxo pode pertencer a uma classe QoS particular, a qual pode ser associada a um conjunto de requisitos de QoS para aquele fluxo. Diferentes classes QoS podem ser associadas a diferentes conjuntos de requisitos de QoS.

[0027] Em um modelo, múltiplas configurações podem ser suportadas para fluxos. Em uma primeira configuração de fluxo, até oito fluxos podem ser suportados, e cada fluxo pode estar associado a uma classe QoS diferente. Em uma segunda configuração de fluxo, até quatro fluxos podem ser suportados, e cada fluxo pode estar associado a uma classe QoS diferente. Uma configuração de fluxo adequada pode ser selecionada (por exemplo, pela rede de acesso) com base nos perfis ou blobs de QoS relatados para todas as aplicações ativas no terminal.

[0028] O terminal pode enviar dados para cada corrente no R-ODCH sempre que houver dados para enviar. O R-ODCH pode ser programado por um programador para uma estação base. O terminal pode enviar uma solicitação de recursos no canal de solicitação sempre que houver dados a enviar para qualquer corrente. O programador pode atribuir recursos no R-ODCH para o terminal em resposta a solicitação de recursos. Pode ser desejável que a solicitação de recursos proveja informações pertinentes com relação aos dados a serem enviados pelo terminal para suportar programação eficiente e atribuição de recursos.

[0029] Em um aspecto, uma solicitação de recursos pode incluir informações indicativas da quantidade de dados a

Petição 870190114871, de 08/11/2019, pág. 13/45

9/33 enviar, bem como informações de QoS para os dados. As informações indicativas da quantidade de dados a enviar também podem ser referidas como nível de backlog, tamanho de buffer, tamanho de fila, tamanho de carga útil, etc. Para maior clareza, o nível de backlog é usado em grande parte da descrição abaixo. As informações de QoS podem ser providas de várias maneiras, como descrito abaixo. As informações de nível de backlog e as informações de QoS podem ser usadas pelo programador para decidir qual terminal programar para transmissão de dados no link reverso e/ou quantos recursos alocar para cada terminal programado.

[0030] Uma solicitação de recursos pode possuir um tamanho fixo e pode ser enviada com um número fixo de bits. É desejável utilizar os bits disponíveis para conduzir tantas informações quanto possível para os dados a enviar. Em geral qualquer número de bits pode ser usado para uma solicitação de recursos. Para maior clareza, grande parte da descrição a seguir é para um modelo no qual uma solicitação de recursos é enviada com seis bits.

[0031] A Figura 3 mostra um modelo de uma solicitação de recursos, que também pode ser referido como um relato de solicitação, um REQReport, um REQCHReport, etc. Neste modelo, a solicitação de recursos é enviada com seis bits e possui um valor dentro de uma faixa total de 0 a 63. No modelo mostrado na Figura 3, a faixa total é particionada em duas faixas para dois formatos de solicitação. A primeira faixa de 0 a 47 é usada para formato de solicitação 1, e a segunda faixa de 48 a 63 é usada para formato de solicitação 2. Para formato de solicitação 1, tanto informações de nível de backlog quanto informações de tipo de backlog são enviadas na solicitação de recursos. As informações de tipo de backlog compreendem

Petição 870190114871, de 08/11/2019, pág. 14/45

10/33 informações de QoS para os dados a enviar. No modelo mostrado na Figura 3, as informações de nível de backlog compreendem um de seis valores possíveis, as informações de tipo de backlog compreendem um de oito valores possíveis, e uma de 48 combinações possíveis pode ser enviada na solicitação de recursos usando o formato de solicitação 1. Para formato de solicitação 2, apenas informações de nível de backlog são enviadas na solicitação de recursos, e as informações de tipo de backlog são omitidas. As informações de nível de backlog compreendem um de 16 valores possíveis.

[0032] Figura 4 mostra outra representação da solicitação de recursos para o modelo mostrado na Figura 3. Os três primeiros bits (por exemplo, os três bits mais significativos (MSBs)) da solicitação de recursos possuem oito valores possíveis ‘000' até ‘111' (binário), como mostrado na Figura 4. Os primeiros seis valores '000' até '101' são para formato de solicitação 1, e os últimos dois valores ‘110' e ‘111' são para formato de solicitação 2. Para formato de solicitação 1, os primeiros três bits proporcionam um de seis valores possíveis '000' até '101' para nível de backlog, e os últimos três bits provêem um de oito valores possíveis '000' até '111' para tipo de backlog. Para formato de solicitação 2, os seis bits provêem um de 16 valores possíveis '110000' até '111111' para o tipo de backlog. Os valores para nível de backlog e tipo de backlog são descritos abaixo.

[0033] Em geral, a faixa total de valores para uma solicitação de recursos pode ser particionada em qualquer número de faixas para qualquer número de formatos de solicitação. Cada faixa pode cobrir qualquer número de valores e pode possuir um tamanho determinado com base na quantidade de informações a enviar usando o formato de

Petição 870190114871, de 08/11/2019, pág. 15/45

11/33 solicitação associado. Cada formato de solicitação pode incluir um tipo de informações e pode usar qualquer formato de mensagem para todos os tipos de informações a enviar usando aquele formato de solicitação. Para maior clareza, grande parte da descrição a seguir é para os dois formatos de solicitação mostrados na Figura 3.

[0034] Em um modelo, as informações de nível de backlog são dadas por uma quantidade que leva em consideração eficiência espectral (SE) alcançável pelo terminal. A eficiência espectral pode ser dada pelo número de bits de informações que podem ser enviados em uma subportadora em um período de símbolo e pode ser dependente da taxa de código e ordem de modulação usada para dados de transmissão. Por exemplo, uma eficiência espectral de 1 pode ser alcançada com taxa de código de 1/2 e QPSK. Eficiência espectral pode ser dependente de condições de canal, de modo que maior eficiência espectral pode ser alcançável sob boas condições de canal e menor eficiência espectral pode ser alcançável sob condições de canal ruins. Para uma dada quantidade de recursos, mais dados podem ser transmitidos com maior eficiência espectral, e vice versa. Levando-se em consideração eficiência espectral, a quantidade de dados a enviar pode ser quantizada mais apropriadamente, e as informações de nível

de	backlog	podem	conduzir melhor a	quantidade	solicitada
de	recursos	. A eficiência espectral	para	uso	em	determinar
as	informações de	nível de backlog	pode	ser	a	eficiência
espectral	para	a última atribuição	de	recursos, a

eficiência espectral usada para a última transmissão de dados no link reverso, a eficiência espectral indicada por um indicador de qualidade de canal (CQI) enviado pelo terminal, etc.

Petição 870190114871, de 08/11/2019, pág. 16/45

12/33 [0035] Tabela 1 mostra dois modelos para prover informações de nível de backlog. Em um primeiro modelo, as informações de nível de backlog indicam o número de tiles base sendo solicitados, o qual é dado na segunda coluna da Tabela 1. Neste modelo, o terminal pode computar primeiro o número t de tiles necessários para os dados a enviar. O terminal pode determinar um fator g com base na eficiência espectral. Este fator pode ser igual a 5 para eficiência espectral de 0,2, igual a 2 para eficiência espectral de 0,5, e igual a 1 para eficiência espectral de 1 ou mais. O número m de tiles base pode então ser computado como m = t/g. Em um segundo modelo, as informações de nível de backlog indicam o número de bytes de dados a enviar. Para eficiência espectral de 1 ou menos, o número de bytes pode ser dado como mostrado na terceira coluna da Tabela 1. Para eficiência espectral maior que 1, o número de bytes pode ser graduado pela eficiência espectral e dado como mostrado na quarta coluna da Tabela 1. Por exemplo, um valor de nível de

backlog	de 2	indicaria	128	bytes	para eficiência
espectral	de 1	ou	menos,	256	bytes	para eficiência
espectral	de 2,	384	bytes para eficiênci	a espectral de 3,

etc. As informações de nível de backlog também podem ser providas de outras maneiras.

Tabela 1

	Eficiência Espectral d 1	Eficiência Espectral > 1
Nível de Backlog	Número de Tiles base		Número de Bytes de Backlog	Número de Bytes de Backlog
0	1		34	34*SE

Petição 870190114871, de 08/11/2019, pág. 17/45

13/33

1	2	64	64*SE
2	4	128	128*SE
3	8	256	256*SE
4	16	512	512*SE
5	>16	>512	>512*SE

[0036] Em um modelo, múltiplos modos ou configurações de solicitação podem ser suportados pelas informações de tipo de backlog enviadas no formato de solicitação 1 e podem ser usados para prover diferentes tipos de informações de QoS. Em um modelo, uma configuração de solicitação pode ser selecionada para uso pela rede de acesso e enviada para o terminal, por exemplo, em um parâmetro REQConfig enviado através de sinalização de camada superior. Em um modelo, cada configuração de solicitação pode permitir que as informações de tipo de backlog sejam dadas em termos de classe QoS ou prazo de latência. Prazo de latência pode ser o tempo restante antes de um pacote expirar e pode ser dependente do tempo de chegada de pacote e da latência máxima para o pacote. Classe QoS também pode ser referida como classe de fluxo. Diferentes fluxos podem pertencer a diferentes classes QoS, que podem ser associadas a diferentes requisitos de QoS como descrito acima.

[0037] Em um modelo, cada corrente pode ser associada a uma sinalização de tipo de latência ou de tipo de classe QoS para solicitações de recursos. Para cada corrente de tipo de latência, a rede de acesso pode atribuir um prazo de latência que indica a quantidade máxima de tempo que um pacote para aquela corrente pode esperar antes de expirar. Para cada corrente de tipo de classe QoS, a rede de acesso pode atribuir uma classe QoS para o fluxo ao qual a corrente pertence. Solicitações de recursos para cada

Petição 870190114871, de 08/11/2019, pág. 18/45

14/33 corrente podem incluir (i) informações de classe QoS se a corrente está associada a uma classe QoS ou (ii) informações de prazo de latência se a corrente está associada a um prazo de latência. O terminal pode determinar informações de classe QoS ou de prazo de latência para dados a enviar para uma corrente e pode prover estas informações de classe QoS ou de prazo de latência em uma solicitação de recurso.

[0038] Em um modelo, três configurações de solicitação podem ser suportadas para as informações de tipo de backlog e podem ser identificadas pelas REQConfig = 1, 2 e 3. Em um modelo, a primeira configuração de solicitação com REQConfig = 1 suporta relatar um de oito valores de classe QoS possíveis, como mostrado na Tabela 2. Nesta configuração, cada corrente pode ser associada a um valor de classe QoS Cfg 1 que pode ser indicado por um atributo de corrente. Uma solicitação de recursos para uma dada corrente NN (onde NN é um ID de corrente) pode incluir o valor de classe QoS Cfg1 para esta corrente como as informações de tipo de backlog. A primeira configuração de solicitação pode ser usada para sinalizar um nível de buffer associado a uma de várias classes QoS.

Tabela 2 - REQConfig = 1

Tipo de Backlog	Interpretação
0 a 7	Classe QoS Cfg1

[0039] Em um modelo, a segunda configuração de solicitação com REQConfig = 2 suporta relatar tanto qualquer um de quatro valores de classe QoS possíveis quanto um de quatro valores de prazos de latência possíveis, como mostrado na Tabela 3. Nesta configuração, cada corrente pode ser associada a um valor de classe QoS Cfg2 que pode ser indicado por um atributo de corrente. Uma

Petição 870190114871, de 08/11/2019, pág. 19/45

15/33 solicitação de recursos para uma dada corrente NN pode incluir o valor de classe QoS Cfg2 para esta corrente como as informações de tipo de backlog. Alternativamente, a solicitação de recursos pode incluir um valor de prazo de latência para a corrente NN como as informações de tipo de backlog.

Tabela 3 - REQConfig = 2

Tipo de Backlog	Interpretação
0 a 3	Cfg1QoSClass
4		20
5	Prazo de Latência em	40
6	milissegundos (ms)	80
7		120

[0040] Em um modelo, a terceira configuração de solicitação com REQConfig = 3 suporta relatar um de oito valores de prazo de latência possíveis, como mostrado na Tabela 4. Nesta configuração, uma solicitação de recursos para uma dada corrente NN pode incluir o prazo de latência para esta corrente como as informações de tipo de backlog. A terceira configuração de solicitação pode ser usada para sinalizar um nível de buffer associado a um de vários prazos de latência. As informações de nível de backlog enviadas na solicitação de recursos podem indicar a

quantidade	agregada	de	dados	a enviar	para	todas	as
correntes	que possuem	o	prazo	de latência	sinali	zado.	Por
exemplo, se corrente	1	possui	100 bytes	com um	prazo	de

latência de 20 ms, corrente 2 possui 200 bytes com um prazo de latência de 20 ms, e corrente 3 possui 150 bytes com um prazo de latência de 40 ms, então o terminal pode enviar

Petição 870190114871, de 08/11/2019, pág. 20/45

16/33 uma solicitação de recursos de 300 bytes com um prazo de latência de 20 ms para correntes 1 e 2.

Tabela 4 - REQConfig = 3

Tipo de backlog	Prazo de Latência (ms)
0	20
1	40
2	60
3	80
4	100
5	120
6	160
7	200

[0041] Tabelas de 2 a 4 mostram modelos exemplares de três configurações de solicitação para as informações de tipo de backlog. Em geral, qualquer número de configurações de solicitação pode ser suportado, e cada configuração de solicitação pode proporcionar qualquer tipo de informações de QoS.

[0042] Formato de solicitação 1 pode ser usado para prover tanto informações de tipo de backlog quanto de nível de backlog para uma ou mais correntes pertencentes a mesma classe QoS ou possuindo o mesmo prazo de latência. As informações de tipo de backlog podem compreender uma classe QoS específica ou um prazo de latência específico para as uma ou mais correntes. Informações de tipo de backlog e de nível de backlog para correntes pertencentes a diferentes classes QoS ou possuindo diferentes prazos de latência podem ser enviadas em múltiplas solicitações de recursos, por exemplo, uma solicitação de recursos para cada conjunto

Petição 870190114871, de 08/11/2019, pág. 21/45

17/33 de uma ou mais correntes possuindo a mesma classe QoS ou o mesmo prazo de latência.

[0043] Formato de solicitação 2 pode ser usado para prover nível de backlog total para todas as correntes e pode também ser usado quando informações de QoS não são especificadas para uma corrente. Os níveis de backlog para todas as correntes podem ser somadas para obter o nível de backlog total. Em um modelo, o nível de backlog total é dado com uma quantidade que leva em consideração a eficiência espectral alcançável pelo terminal. A Tabela 5 mostra dois modelos para prover informações de nível de backlog total. Em um primeiro modelo, as informações de nível de backlog total indicam o número de tiles base que estão sendo solicitados, que é dado na segunda coluna da Tabela 5. O terminal pode computar o número de tiles base como descrito acima para a tabela 1. Em um segundo modelo, as informações de nível de backlog total indicam o número total de bytes de dados graduados pela eficiência espectral e é dado na quarta coluna da Tabela 5, onde K representa 1024 bytes.

Tabela 5 - Nível de backlog Total para Formato de

Solicitação 2

Valor de r-reqch	Número de Tiles	Número de Bytes de Backlog
‘110000'	4	64*SE
‘110001'	8	128*SE
‘110010'	12	256*SE
‘110011'	16	384*SE
‘110100'	32	512*SE
‘110101'	48	1024*SE
‘110110'	64	1536*SE
‘110111'	80	2K*SE

Petição 870190114871, de 08/11/2019, pág. 22/45

18/33

‘111000'	96	4K*SE
‘111001'	128	6K*SE
‘111010'	160	8K*SE
‘111011'	224	12K*SE
‘111100'	288	16K*SE
‘111101'	352	32K*SE
‘111110'	416	48K*SE
‘111111'	>416	64K*SE

[0044] Para gerar uma solicitação de recursos, o terminal pode primeiro determinar o número de bytes de backlog, que pode incluir os dados a enviar, overhead tal como uma Checagem de Redundância Cíclica (CRC) , qualquer sinalização em banda com os dados, etc. O terminal pode mapear o número de bytes de backlog para um valor de nível de backlog com base em um mapeamento que pode ser dependente do formato de solicitação selecionado assim como da eficiência espectral. Esta eficiência espectral pode ser a eficiência espectral da última atribuição de link reverso, a eficiência espectral alcançável atual, uma eficiência espectral default (por exemplo, se o terminal não recebeu qualquer atribuição de link reverso a partir do programador), etc. O terminal pode então gerar a solicitação de recursos com base nas informações de nível de backlog e informações de QoS/tipo de backlog (se aplicável).

[0045] O terminal pode enviar uma solicitação de recursos para prover o programador com informações de nível de backlog e possivelmente informações de QoS com relação ao estado dos buffers no terminal. O terminal pode enviar a solicitação de recursos como sinalização fora de banda no r-reqch, o qual pode ser enviado no R-CDCCH em um subsegmento CDMA. O terminal também pode enviar a

Petição 870190114871, de 08/11/2019, pág. 23/45

19/33 solicitação de recursos como sinalização em banda junto a dados no R-ODCH.

[0046] Em um modelo, o terminal pode enviar solicitações de recursos como sinalização em banda no R-ODCH como segue. O terminal pode enviar uma solicitação de recursos em um pacote e pode iniciar um temporizador de solicitação em banda quando o pacote é enviado. O terminal pode interromper o temporizador de solicitação em banda se o pacote é decodificado com erro e pode reiniciar o temporizador se o pacote é decodificado corretamente. Enquanto o temporizador de solicitação em banda está ativo, o terminal pode enviar outra solicitação de recursos apenas se o terminal possuir novas informações de backlog que não foram consideradas na última solicitação de recursos em banda. O temporizador de solicitação em banda pode ser usado para prevenir utilização do canal de controle quando as mesmas informações já foram enviadas em banda. Isto pode reduzir carga no canal de controle. O terminal pode enviar solicitações de recursos em banda no fluxo com maior prioridade, nos pacotes de latência mais baixos, em pacotes maiores que um tamanho predeterminado, etc.

[0047] Em um modelo, o terminal pode enviar solicitações de recursos como sinalização fora de banda no R-CDCCH no subsegmento CDMA com base em um esquema de recuo. O terminal pode iniciar um temporizador de recuo após enviar uma solicitação de recursos no r-reqch. Enquanto o temporizador de recuo está ativo, o terminal pode deixar de enviar solicitações de recursos exceto por (i) uma solicitação de recursos para uma corrente com uma prioridade maior que a prioridade mais alta de toda(s) a(s) corrente(s) na última solicitação de recursos ou (ii) uma solicitação de recursos para indicar o menor requisito de latência (de 20 ms no modelo acima) ou menos, que não foi

Petição 870190114871, de 08/11/2019, pág. 24/45

20/33 indicado na última solicitação de recursos. O terminal pode ajustar o temporizador para um valor pseudo-aleatório entre 0 e W e pode aumentar (por exemplo, dobrar) W sempre que uma solicitação de recursos é enviada e uma atribuição de recursos não é recebida em um período de tempo predeterminado. O terminal pode registrar o temporizador de recuo para zero após um handoff, por exemplo, a partir de um setor servidor para outro setor servidor. Este esquema de recuo pode prevenir sobrecarga do subsegmento CDMA e também pode ser aplicado a outros canais de controle, por exemplo, um canal CQI. O terminal pode enviar uma solicitação de recursos no R-CDCCH (ao contrário do RCDCCH) se estiver disponível em F quadros PHY, onde F pode ser igual a 4, 8, 12, etc.

[0048] Figura 5 mostra um projeto de um processo 500 para enviar solicitações de recursos com informações QoS. Processo 500 pode ser realizado por um terminal ou alguma outra entidade. O terminal pode determinar ou receber uma configuração selecionada para uso ao enviar solicitações de recursos dentre múltiplas configurações múltiplas (bloco 512). Cada configuração pode ser associada a pelo menos um de múltiplos tipos de QoS possíveis. Em um modelo, os múltiplos tipos de QoS possíveis compreendem classe QoS e prazo de latência. O terminal pode determinar pelo menos um tipo de QoS para enviar em solicitações de recursos com base na configuração selecionada (bloco 514).

[0049] O terminal pode possuir dados para enviar e pode determinar informações de QoS para os dados (bloco 516). As informações de QoS podem compreender pelo menos um tipo de QoS para a configuração selecionada. O terminal também pode determinar informações de nível de backlog para os dados a enviar (bloco 518). As informações de nível de backlog podem compreender um de uma pluralidade de valores de

Petição 870190114871, de 08/11/2019, pág. 25/45

21/33 níveis de backlog, os quais podem ser aplicáveis para todas as configurações. O terminal pode gerar e enviar uma solicitação de recursos compreendendo as informações de nível de backlog e as informações de QoS (bloco 520).

[0050] Em um modelo, a solicitação de recursos pode incluir (i) a informações de nível de backlog e as informações de classe QoS se uma primeira configuração é selecionada, (ii) as informações de nível de backlog e ou informações de classe QoS ou informações de prazo de latência se uma segunda configuração é selecionada, ou (iii) as informações de nível de backlog e informações de prazo de latência se uma terceira configuração é selecionada. A solicitação de recursos também pode compreender outras combinações de informações em outros modelos. Em um modelo, a solicitação de recursos pode incluir um de oito valores de classe QoS possíveis para a primeira configuração ou um de quatro valores de classe QoS possíveis para a segunda configuração. Em um modelo, a solicitação de recursos pode incluir um de quatro prazos de latência possíveis para a segunda configuração ou um de oito valores de prazo de latência possíveis para a terceira configuração. A primeira configuração pode ser selecionada para um primeiro número de fluxos (por exemplo, oito fluxos), e a segunda configuração pode ser selecionada para um segundo número de fluxos (por exemplo, quatro fluxos). A solicitação de recursos pode compreender um número fixo de bits (por exemplo, seis bits) para todas as configurações.

[0051] Figura 6 mostra um modelo de um equipamento 600 para enviar solicitações de recursos com informações de QoS. Equipamento 600 inclui elementos para determinar ou receber uma configuração selecionada para uso ao enviar solicitações de recursos (módulo 612), elementos para determinar pelo menos um tipo de QoS para enviar em

Petição 870190114871, de 08/11/2019, pág. 26/45

22/33 solicitações de recursos com base na configuração selecionada (módulo 614), elementos para determinar informações de QoS para dados a enviar, com a informações de QoS compreendendo pelo menos um tipo de QoS para a configuração selecionada (módulo 616), elementos para determinar informações de nível de backlog para os dados a enviar (módulo 618), e elementos para gerar uma solicitação de recursos compreendendo as informações de nível de backlog e as informações de QoS (módulo 620).

[0052] Figura 7 mostra um modelo de um processo 700 para enviar solicitações de recursos com diferentes formatos. Processo 700 pode ser realizado por um terminal ou alguma outra entidade. O terminal pode determinar pelo menos um tipo de informações a enviar em uma solicitação de recursos (bloco 712). O terminal pode determinar um formato a usar para solicitação de recursos dentre múltiplos formatos com base no pelo menos um tipo de informações a enviar (bloco 714). Os múltiplos formatos podem compreender um primeiro formato para informações de nível de backlog e informações de QoS e um segundo formato para somente informações de nível de backlog. O terminal pode usar o primeiro formato se o pelo menos um tipo de informações compreende informações de nível de backlog e informações de QoS. O terminal pode usar o segundo formato se o pelo menos um tipo de informações compreende somente informações de nível de backlog. O terminal pode usar o primeiro formato se a solicitação de recursos for para uma corrente específica e pode usar o segundo formato se a solicitação de recursos for para múltiplas correntes. O terminal pode usar o primeiro formato para uma corrente associada a informações de QoS e pode usar o segundo formato para uma corrente associada a nenhuma informação de QoS ou para múltiplas correntes com informações de QoS variáveis. O terminal pode

Petição 870190114871, de 08/11/2019, pág. 27/45

23/33 também selecionar o primeiro ou segundo formato com base em outros critérios.

[0053] O terminal pode gerar a solicitação de recursos compreendendo o pelo menos um tipo de informações no formato determinado (bloco (716). A solicitação de recursos pode compreender um número fixo de bits (por exemplo, seis bits) para todos os múltiplos formatos. O primeiro formato pode corresponder a uma primeira faixa de valores (por exemplo, de 0 a 47) para a solicitação de recurso, e o segundo formato pode corresponder a uma segunda faixa de valores (por exemplo, 48 a 63).

[0054] Figura 8 mostra um modelo de um equipamento 800 para enviar solicitações de recursos com diferentes formatos. Equipamento 800 inclui elementos para determinar pelo menos um tipo de informações para enviar em uma solicitação de recursos (módulo 812), elementos para determinar um formato a usar para a solicitação de recursos dentre múltiplos formatos com base no pelo menos um tipo de informações a enviar (módulo 814), e elementos para gerar a solicitação de recursos compreendendo o pelo menos um tipo de informações no formato determinado (módulo 816).

[0055] A Figura 9 mostra um modelo de um processo 900 para enviar solicitações de recursos com informações de QoS. Processo 900 pode ser realizado por um terminal ou alguma outra entidade. O terminal pode determinar informações de classe QoS ou informações de prazo de latência para dados a enviar (bloco 912). O terminal pode determinar informações de nível de backlog para os dados a enviar (bloco 914). O terminal pode gerar uma solicitação de recursos compreendendo as informações de nível de backlog em um primeiro campo e as informações de classe QoS ou a informações de prazo de latência em um segundo campo (bloco 916).

Petição 870190114871, de 08/11/2019, pág. 28/45

24/33 [0056] Em um modelo de bloco 912, o terminal pode identificar pelo menos uma corrente para a qual os dados a enviar pertencem e pode determinar se a pelo menos uma corrente está associada a classe QoS ou prazo de latência. O terminal pode então determinar (i) as informações de classe QoS para a pelo menos uma corrente se associadas a classe QoS ou (ii) as informações de prazo de latência para a pelo menos uma corrente se associada ao prazo de latência.

[0057] Em um modelo de bloco 916, o terminal pode (i) mapear as informações de classe QoS para uma primeira faixa de valores para o segundo campo ou (ii) mapear as informações de prazo de latência em uma segunda faixa de valores para o segundo campo. Em um modelo, o segundo campo pode incluir três bits, e o terminal pode (i) mapear as informações de classe QoS em um de quatro possíveis valores para o segundo campo ou (ii) mapear as informações de prazo de latência em um de quatro valores possíveis diferentes para o segundo campo.

[0058] A Figura 10 mostra um modelo de um equipamento 1000 para enviar solicitações de recursos com informações de QoS. O equipamento 1000 inclui elementos para determinar informações de classe QoS ou informações de prazo de latência para dados a enviar (módulo 1012), elementos para determinar informações de nível de backlog para os dados a enviar (módulo 1014), e elementos para gerar uma solicitação de recursos compreendendo as informações de nível de backlog em um primeiro campo e as informações de classe QoS ou as informações de prazo de latência em um segundo campo (módulo 1016).

[0059] A Figura 11 mostra um modelo de um processo 1100 para enviar solicitações de recursos pela consideração de eficiência espectral. Processo 1100 pode ser realizado por

Petição 870190114871, de 08/11/2019, pág. 29/45

25/33 um terminal ou alguma outra entidade. O terminal pode determinar informações de nível de backlog com base em uma quantidade de dados a enviar e eficiência espectral (bloco 1112) . O terminal pode determinar a eficiência espectral com base na mais recente atribuição de recursos, a mais recente CQI, etc. O terminal pode gerar uma solicitação de recursos compreendendo as informações de nível de backlog (bloco 1114).

[0060] Em um modelo, o terminal pode selecionar um de múltiplos valores de nível de backlog correspondendo a diferentes números de bytes graduados pela eficiência espectral, por exemplo, como mostrado na Tabela 1 ou 5. Em outro modelo, o terminal pode selecionar um de múltiplos valores de nível de backlog correspondendo a (i) diferentes números de bytes graduados pela eficiência espectral se a eficiência espectral for maior que um valor limite ou (ii) diferentes números de bytes se a eficiência espectral é igual ou menor que o valor limite, por exemplo, como mostrado na Tabela 1. Em ainda outro modelo, o terminal pode selecionar um de múltiplos valores de nível de backlog correspondendo a diferentes números de tiles determinados com base na eficiência espectral, por exemplo, como mostrado na Tabela 1 ou 5. O terminal pode também selecionar um de múltiplos valores de nível de backlog de outras maneiras. Para todos os modelos, o terminal pode gerar a solicitação de recursos compreendendo o valor de nível de backlog selecionado.

[0061] Figura 12 mostra um modelo de um equipamento 1200 para enviar solicitações de recursos considerando eficiência espectral. Equipamento 1200 inclui elementos para determinar informações de nível de backlog com base em quantidade de dados a enviar e eficiência espectral (módulo 1212) e elementos para gerar uma solicitação de recursos

Petição 870190114871, de 08/11/2019, pág. 30/45

26/33 compreendendo as informações de nível de backlog (módulo 1214) .

[0062] Figura 13 mostra um modelo de um processo 1300 para enviar mensagens de controle com recuo. O processo 1300 pode ser realizado por um terminal ou alguma outra entidade. O terminal pode enviar uma primeira mensagem de controle, por exemplo, uma solicitação de recursos para dados a enviar, uma solicitação de handoff, um relato de CQI, etc. (bloco 1312) . O terminal pode selecionar um primeiro valor pseudo-aleatório dentro de uma janela (bloco 1314) e pode ajustar um temporizador de recuo para o primeiro valor pseudo-aleatório ao enviar a primeira mensagem de controle (bloco 1316).

[0063] O terminal pode determinar se deve enviar uma segunda mensagem de controle com base no temporizador de recuo (bloco 1318). Em um modelo, o terminal pode enviar a segunda mensagem de controle se uma resposta não é recebida para a primeira mensagem de controle (por exemplo, uma atribuição não é recebida para a solicitação de recursos) e o temporizador de recuo expira. O terminal pode aumentar a janela após enviar a segunda mensagem de controle, selecionar um segundo valor pseudo-aleatório dentro da janela maior e ajustar o temporizador de recuo para o segundo valor pseudo-aleatório ao enviar a segunda mensagem de controle. O terminal pode então determinar se deve enviar outra mensagem de controle com base no temporizador de recuo.

[0064] Em um modelo, as mensagens de controle são solicitações de recursos, e o terminal pode enviar a segunda solicitação de recursos para uma corrente antes do temporizador de recuo expirar se (i) a corrente possuir prioridade maior que a prioridade mais alta de pelo menos uma corrente sinalizada na primeira solicitação de

Petição 870190114871, de 08/11/2019, pág. 31/45

27/33 recursos, (ii) a corrente possuir um prazo de latência mais curto e o prazo de latência menor não for sinalizado na primeira solicitação de recurso, ou (iii) algum outro critério for satisfeito.

[0065] Figura 14 mostra um modelo de um equipamento 1400 para enviar mensagens de controle com recuo. O equipamento 1400 inclui elementos para enviar uma primeira mensagem de controle, por exemplo, uma solicitação de recursos para dados a enviar (módulo 1412), elementos para selecionar um primeiro valor pseudo-aleatório dentro de uma janela (módulo 1414), elementos para ajustar um temporizador de recuo para o primeiro valor pseudo-aleatório ao enviar a primeira mensagem de controle (módulo 1416), e elementos para determinar se deve enviar uma segunda mensagem de controle com base no temporizador de recuo (módulo 1418).

[0066] Os módulos nas Figuras 6, 8, 10, 12 e 14 podem compreender processadores, dispositivos eletrônicos, dispositivos de hardware, componentes eletrônicos, circuitos lógicos, memórias, etc., ou qualquer combinação dos mesmos.

[0067] Figura 15 mostra um diagrama de bloco de um modelo de estação base 110 e terminal 120, que são uma das estações base e um dos terminais na Figura 1. Neste modelo, o terminal 120 é equipado com T antenas 1534a até 1534t, e estação base 110 é equipada com R antenas 1552a até 1552r, onde em geral T > 1 e R > 1.

[0068] No terminal 120, um processador de controle e dados de transmissão (TX) 1520 pode receber dados de tráfego a partir de uma fonte de dados 1512, processar os dados de tráfego (por exemplo, codificar, intercalar, embaralhar e mapear em símbolos), e prover símbolos de dados. O processador 1520 pode também receber informações de controle (por exemplo, solicitações de recursos) a

Petição 870190114871, de 08/11/2019, pág. 32/45

28/33 partir de um controlador/processador 1540, processar as informações de controle e prover símbolos de controle. Processador 1520 também pode gerar e multiplexar símbolos piloto com os símbolos de controle e dados. Um processador MIMO TX 1530 pode processar (por exemplo, precodificar) os símbolos a partir do processador 1520 e prover T correntes de símbolos de saída para T moduladores (MOD) 1532a até 1532t. Processador MIMO TX pode ser omitido se terminal 120 for equipado com uma única antena. Cada modulador 1532 pode processar sua corrente de símbolos de saída (por exemplo, para OFDM, CDM, etc.) para obter uma corrente de chips de saída. Cada modulador 1532 pode adicionalmente condicionar sua corrente de chips de saída (por exemplo, converter para analógico, filtrar, amplificar e converter ascendentemente) a corrente de chips de saída para gerar um sinal de link reverso. Os sinais de link reverso a partir de moduladores 1532a até 1532t pode ser transmitido através de T antenas 1534a até 1534t, respectivamente.

[0069] Na estação base 110, antenas 1552a até 1552r podem receber os sinais de link reverso a partir do terminal 120 e/ou outros terminais. Cada antena 1552 pode prover um sinal recebido para um demodulador respectivo (DEMOD) 1554. Cada demodulador 1554 pode condicionar (por exemplo, filtrar, amplificar, converter descendentemente e digitalizar) seu sinal recebido para obter amostras e pode adicionalmente processar as amostras (por exemplo, OFDM, CDM, etc.) para obter símbolos demodulados. Um processador MIMO RX 1560 pode realizar detecção MIMO nos símbolos demodulados a partir de todos os R demoduladores 1554a até 1554r e prover símbolos detectados. Um processador de controle e dados de recepção (RX) 1570 pode processar os símbolos detectados (por exemplo, demodular, deintercalar e decodificar), prover dados decodificados para um depósito

Petição 870190114871, de 08/11/2019, pág. 33/45

29/33 de dados 1572, e prover informações de controle decodificadas (por exemplo, solicitações de recursos) para um controlador/processador 1590. Em geral, o processamento pelos processadores 1560 e 1570 é complementar ao processamento pelos processadores 1530 e 1520, respectivamente, no terminal 120.

[0070] Estação base 110 pode transmitir informações de controle e/ou dados de tráfego no link direto para terminal 120. Dados de tráfego a partir de uma fonte de dados 1578 e/ou informações de controle (por exemplo, atribuições de recursos) a partir de um controlador/processador 1590 pode ser processada por um processador de controle e dados TX 1580 e adicionalmente processados por um processador MIMO TX 1582 para obter R correntes de símbolos de saída. Os R moduladores 1554a até 1554r podem processar as R correntes de símbolos de saída (por exemplo, para OFDM) para obter R correntes de chips de saída e pode adicionalmente condicionar as correntes de chips de saída para obter R sinais de link direto, que podem ser transmitidos através de R antenas 1552a até 1552r. No terminal 120, os sinais de link direto a partir da estação base 110 podem ser recebidos por antenas 1534a até 1534r, condicionados e processados por demoduladores 1532a até 1532t, e adicionalmente processados por um processador MIMO RX 1536 (se aplicável) e um processador de controle e dados RX 1538 para recuperar as informações de controle e os dados de tráfego enviados para terminal 120. Os dados de tráfego podem ser providos para um depósito de dados 1539.

[0071] Processadores/Controladores 1540 e 1590, podem orientar a operação no terminal 120 e estação base 110 respectivamente. Memórias 1542 e 1592 podem armazenar dados códigos de programa para terminal 120 e estação base 110, respectivamente. Um programador 1594 pode programar

Petição 870190114871, de 08/11/2019, pág. 34/45

30/33 terminais para transmissão de dados o link reverso e/ou direto e pode atribuir recursos para os terminais programados.

[0072] Aqueles versados na técnica compreenderão que informações e sinais podem ser representados usando qualquer de uma variedade de diferentes tecnologias e técnicas. Por exemplo, dados, instruções, comandos, informações, sinais, bits, símbolos e chips podem ser referenciados por toda a descrição acima e podem ser representados por tensões, correntes elétricas, ondas eletromagnéticas, campos magnéticos ou partículas, campos óticos ou partículas, ou qualquer combinação dos mesmos.

[0073] Aqueles versados na técnica apreciarão adicionalmente que os vários blocos lógicos, módulos, circuitos e etapas de algoritmo ilustrativos descritos em conexão com a revelação aqui presente podem ser implementados como hardware eletrônico, software de computador ou combinação de ambos. Para ilustrar claramente esta intercambialidade de hardware e software, vários componentes, blocos, módulos, circuitos e etapas ilustrativos foram descritos acima geralmente em termos de suas funcionalidades. Se tal funcionalidade é implementada como hardware ou software dependerá da aplicação particular e restrição de modelo impostas no sistema como um todo. Os técnicos versados podem implementar a funcionalidade descrita de várias formas para cada aplicação particular, mas tais decisões de implementação não devem ser interpretadas como causando um afastamento do escopo da presente revelação.

[0074] Os vários blocos lógicos, módulos, e circuitos ilustrativos descritos em conexão com a revelação aqui presente podem ser implementados ou realizados com um processador de propósito geral, um processador de sinais

Petição 870190114871, de 08/11/2019, pág. 35/45

31/33 digitais (DSP), um circuito integrado de aplicação específica (ASIC), arranjos de porta programáveis em campo (FPCA) ou outros dispositivos lógicos programáveis, lógica de transistor ou porta discreta, componentes de hardware discretos, ou qualquer combinação dos mesmos, modelada para realizar as funções aqui descritas. Um processador de propósito geral pode ser um microprocessador, mas como alternativa, o processador pode ser qualquer processador, controlador, microcontrolador ou máquina de estado convencional. Um processador também pode ser implementado como uma combinação de dispositivos de computação, por exemplo, uma combinação de um DSP e um microprocessador, uma pluralidade de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo DSP, ou qualquer outra configuração.

[0075] As etapas de um método ou algoritmo descrito em conexão com a revelação aqui presente podem ser incorporadas diretamente em hardware, em um módulo de software executado por um processador, ou em uma combinação dos dois. Um módulo de software pode residir em memória RAM, memória flash, memória ROM, memória EPROM, memória EEPROM, registradores, disco rígido, um disco removível, um CD-ROM, ou qualquer outra forma de meio de armazenamento conhecido na técnica. Um meio de armazenamento exemplar é acoplado ao processador tal que o processador possa ler informações a partir de, e escrever informações no, meio de armazenamento. Na alternativa, o meio de armazenamento pode ser integrado ao processador. O processador e o meio de armazenamento podem residir em um ASIC. O ASIC pode residir em um terminal de usuário. Na alternativa, o processador e o meio de armazenamento podem residir como componentes discretos em um terminal de usuário.

Petição 870190114871, de 08/11/2019, pág. 36/45

32/33 [0076] Em um ou mais modelos exemplares, as funções descritas podem ser implementadas em hardware, software, firmware, ou qualquer combinação dos mesmos. Se implementadas no software, as funções podem ser armazenadas no, ou transmitidas sobre, como uma ou mais instruções ou códigos em um meio legível por computador. Mídia legível por computador inclui tanto mídia de armazenamento de computador quanto mídia de comunicação incluindo qualquer meio que facilite transferência de um programa de computador de um local para o outro. Uma mídia de armazenamento pode ser qualquer mídia disponível que possa ser acessada por um computador de propósito especial ou de propósito geral. Para fins de exemplo, e não limitação, tal mídia legível de computador pode compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento de disco ótico, armazenamento de disco magnético ou outros dispositivos de armazenamento de magnético, ou qualquer outro meio que possa ser usado para transportar ou armazenar elementos de código de programa desejado na forma de instruções ou estruturas de dados e que possam ser acessados por um computador de propósito geral ou de propósito especial, ou um processador de propósito geral ou de propósito especial. Além disso, qualquer conexão é propriamente denominada um meio legível por computador. Por exemplo, se o software é transmitido a partir de um website, servidor, ou outra fonte remota usando um cabo coaxial, cabo de fibra ótica, par trançado, linha de assinatura digital (DSL), ou tecnologias sem fio, tais como, infravermelho, rádio e microondas, então o cabo coaxial, cabo de fibra ótica, par trançado, DSL ou tecnologias sem fio, tais como, infravermelho, rádio, e microondas são incluídos na definição de meio. Disco, como usado aqui, inclui disco compacto (CD), disco laser, disco ótico, disco versátil

Petição 870190114871, de 08/11/2019, pág. 37/45

33/33 digital (DVD), disquete e disco Blue-ray onde discos geralmente reproduzem dados magneticamente, enquanto discos reproduzem dados oticamente com lasers. Combinações do definido acima pode também podem ser incluídas dentro do escopo de mídia legível por computador.

[0077] A descrição anterior da revelação é provida para habilitar qualquer pessoa versada na técnica a realizar ou usar a revelação. Várias modificações da revelação serão prontamente aparentes para aqueles versados na técnica, e os princípios genéricos definidos aqui podem ser aplicados para outras variações sem se afastarem do espírito ou escopo da revelação. Desse modo, a revelação não pretende ser limitada aos exemplos e modelos descritos aqui, mas deve estar de acordo com o escopo mais amplo consistente com os princípios e aspectos novos descritos aqui.

Claims

REIVINDICAÇÕES

1. Método (700) para comunicação sem fio, caracterizado por compreender:

determinar (712) determinar pelo menos um tipo de informações a enviar em uma solicitação de recursos;

determinar (714) um formato a usar para a solicitação de recursos dentre múltiplos formatos com base no pelo menos um tipo de informações a enviar;

em que os múltiplos formatos compreendem um primeiro formato para informações de nível de backlog e informações de Qualidade de Serviço, QoS, e em que determinar (714) o formato compreende usar o primeiro formato se o pelo menos um tipo de informações compreende informações de nível de backlog e informações de QoS;

em que os múltiplos formatos compreendem adicionalmente um segundo formato para somente informações de nível de backlog, e em que determinar (714) o formato compreende usar o segundo formato se o pelo menos um tipo de informações compreende somente informações de nível de backlog; e gerar (716) uma solicitação de recursos compreendendo as informações de QoS;

em que gerar a solicitação de recursos compreende determinar um valor para a solicitação de recursos dentro de uma primeira faixa de valores para o primeiro formato e dentro de uma segunda faixa de valores para o segundo formato.
2. Método (700), de acordo com a reivindicação 1, caracterizado por compreender ainda usar o primeiro formato se a solicitação de recursos for para uma corrente específica, e usar o segundo formato se a solicitação de recursos for para múltiplas correntes.

Petição 870190114871, de 08/11/2019, pág. 39/45

2/5
3. Método (700), de acordo com a reivindicação 1, caracterizado por compreender ainda em que o pelo menos um processador é configurado para usar o primeiro formato para uma corrente associada a informações de QoS, e para usar o segundo formato para uma corrente não associada a informações de QoS ou para múltiplas correntes com informações de QoS variadas.
4. Método (700), de acordo com a reivindicação 1, caracterizado pela solicitação de recursos compreender um número fixo de bits para todos os múltiplos formatos.
5. Método (700), de acordo com a reivindicação 1, caracterizado pela solicitação de recursos compreende seis bits, em que o primeiro formato corresponde a uma primeira faixa de 0 a 47, e em que o segundo formato corresponde a uma segunda faixa de 48 a 63.
6. Método (700), de acordo com a reivindicação 1, caracterizado por compreender ainda:

determinar informações de nível de backlog com base em quantidade de dados a enviar e eficiência espectral; e gerar a solicitação de recursos compreendendo as informações de nível de backlog.
7. Método (700), de acordo com a reivindicação

6, caracterizado por determinar as informações de nível de backlog compreender selecionar um dentre múltiplos valores de backlog correspondendo a diferentes números de bytes graduados pela eficiência espectral, e em que gerar a solicitação de recursos compreende gerar a solicitação de recursos compreendendo o valor de nível de backlog selecionado.
8. Método (700), de acordo com a reivindicação 7, caracterizado por determinar as informações de nível de backlog compreender selecionar um dentre múltiplos valores

Petição 870190114871, de 08/11/2019, pág. 40/45

3/5 de nível de backlog correspondendo a diferentes números de bytes graduados pela eficiência espectral se a eficiência espectral for maior que um valor limite, e selecionar um dentre múltiplos valores de nível de backlog correspondendo a diferentes números de bytes se a eficiência espectral for igual ou menor que valor limite, e em que gerar a solicitação de recursos compreende gerar a solicitação de recursos compreendendo o valor de nível de backlog selecionado.
9. Método (700), de acordo com a reivindicação 6, caracterizado por determinar a eficiência espectral ser com base em uma atribuição de recursos mais recente.
10. Método (700), de acordo com a reivindicação

6, caracterizado por compreender ainda:

determinar um número de tiles para cada um dentre múltiplos valores de nível de backlog com base na eficiência espectral, e para selecionar um dentre os múltiplos valores de nível de backlog com base na

quantidade de dados a enviar.
11. Equipamento (800) para comunicação sem fio, caracterizado por compreender:

meios para determinar (812) pelo menos um tipo de informações a enviar em uma solicitação de recursos;

meios para determinar (814) um formato a usar para a solicitação de recursos dentre múltiplos formatos com base no pelo menos um tipo de informações a enviar;

em que os múltiplos formatos compreendem um primeiro formato para informações de nível de backlog e informações de Qualidade de Serviço, QoS, e em que os meios para determinar (814) o formato compreendem usar o primeiro formato se o pelo menos um tipo de informações compreende informações de nível de backlog e informações de QoS;

Petição 870190114871, de 08/11/2019, pág. 41/45

4/5 em que os múltiplos formatos compreendem adicionalmente um segundo formato para somente informações de nível de backlog, e em que os meios para determinar (814) o formato compreendem usar o segundo formato se o pelo menos um tipo de informações compreende somente informações de nível de backlog; e meios para gerar (816) uma solicitação de recursos compreendendo as informações de QoS;

em que os meios para gerar (816) a solicitação de recursos compreende determinar um valor para a solicitação de recursos dentro de uma primeira faixa de valores para o primeiro formato e dentro de uma segunda faixa de valores para o segundo formato..

12. Equipamento (800), de acordo com a reivindicação 11, caracterizado por compreender ainda meios para usar o primeiro formato se a solicitação de recursos for para uma corrente específica, e para usar o segundo formato se a solicitação de recur sos for para múltiplas

correntes.

13. Equipamento (800), de acordo com a reivindicação 11, caracterizado pela solicitação de recursos compreender um número fixo de bits para todos os múltiplos formatos. 14. Equipamento (800), de acordo com a

reivindicação 11, caracterizado pelos meios para determinar (812) pelo menos um tipo de informações, os meios para determinar (814) um formato a usar para a solicitação de recursos e os meios para gerar (816) uma solicitação de recursos compreenderem pelo menos um processador e uma memória acoplada ao pelo menos um processador.
15. Memória caracterizada por compreender instruções executáveis por computador para implementar o

Petição 870190114871, de 08/11/2019, pág. 42/45

5/5 método conforme definido em qualquer uma das reivindicações

1 a 10.