MÉTODO PARA PROVER O ELEMENTO DE REDE DA REDE DE COMUNÍCAÇÃO, REDE DE COMUNICAÇÃO, CONTROLADOR E ELEMENTO DE REDE PARA A REDE DE COMUNICAÇÃO” Campo da invenção A invenção relaciona a um método para promover um elemento de rede, por exemplo, o Nó B, da rede de comunicação, por exemplo, a UTRAN (Rede de Acesso do Rádio Terrestre do Sistema de Telecomunicação Móvel Universal) com os dados, por exemplo, os dados relacionados ao HSDPA {High Speed Downllnk Packeí Access/ Acesso de Pacote de Enlace Descendente de Alta Velocidade), requeridos no elemento de rede.
Por outro lado, a invenção relaciona mais especificamente a um método para transmitir os dados do usuário dentro da rede de comunicação, por exemplo, os dados do usuário relacionados ao HSDPA, do computador para o elemento de rede sobre a interface, por exemplo, a interface fub, Por outro lado, a invenção relaciona mais específicamente a um método para prover um elemento de rede, por exemplo, um Nó S, da rede de comunicação, por exemplo, a UTRAN, com os parâmetros de controle, por exemplo, os parâmetros de controle relacionados ao HSDPA, disponíveis no controlador da rede de controle, por exemplo, um RNC, cujo controlador é conectado ao elemento de rede através de uma interface, por exemplo, a interface lub. A invenção iguafmente relaciona às redes de comunicação correspondentes, aos elementos de rede e aos controladores, Qeserjçà O HSDPA é um conceito que foi introduzido as arquiteturas UTRAN como um aperfeiçoamento ao conceito do canal compartilhado no 3GPP (3rd Oeneration Parfnership Project/ Projeto de Parceiros da 3â Geração).
No UMTS, a UTRAN controla todas as funcionalidades relacionada a rádio, Para este próposifo, a UTRAN compreende um ou mais RNCs, e conectado a cada RNC um ou mais Nós Bs, OS RNCs da UTRAN sao conectados à rede núcleo através da Interface lu. Os RNCs da UTRAN podem ser interconeotados em adição através da interface Iur. Nas transmissões de enlace descendente, o RNC recebe os dados do usuário da rede núcleo, possivelmente através de outro RNC, e direciona este através de uma interface Iub para o Nó B. O Nó B então transmite os dados para o equipamento do usuário UE endereçado através da interface Uu.
Os RNCs da UTRAN podem ter diferentes regras. O RNC de controle (CRNC) pode ser definido, por exemplo, com relação a um grupo específico de Nós Bs. Existe apenas um CRNC para qualquer Nó B. O CRNC tem o controle total sobre os recursos lógicos dos seus Nós Bs. O RNC de serviço (SRNC) pode ser definido com relação a uma conexão específica entre o EU e a UTRAN. Existe um SRNC para cada EU que tenha uma conexão para a UTRAN. O SRNC é encarregado da conexão de controle de recurso de rádio (RRC - Radio Resource Control) entre o UE e a UTRAN. O RNC de serviço também termina a Iu para este UE.
No conceito do canal compartilhado na UTRAN para o modo FDD, o DSCH (Downlink Shared Channel/ Canal Compartilhado de Enlace Descendente) é definido como um canal de transporte de enlace descendente, que é compartilhado dinamicamente entre vários UEs. O DSCH é montado no CRNC e transmitido através do Nó B para o UE, como descrito, por exemplo, na especificação técnica 3GPP TS 25.301 V3.6.0 (2000-09): “Projeto de Parceiros da 3a Geração; Especificação Técnica da Rede de Acesso do Grupo de Rádio; Arquitetura do Protocolo de Interface de Rádio (Edição 1999)”. A idéia básica do HSDPA é oferecer canais compartilhados de transmissões de enlace descendente de alta velocidade com uma taxa de dados elevada e um mecanismo de retransmissão mais rápido já do Nó B. Os canais de alta velocidade compartilhados compreendem o HS-DSCH (High Speed Downlink Shared Channel/ Canal Compartilhado de Enlace Descendente de Alta Velocidade) como canal de transporte e o DPCH (Dedicated Physical Channel/ Canal Físico Dedicado), combinado com o canal de controle físico compartilhado separado em combinação com o HS-PDSCH (High Speed Physical Downlink Shared Channel/ Canal Físico Compartilhado de Enlace Descendente de Alta Velocidade). O mecanismo de retransmissão rápida a ser implementado no Nó B é o HARQ (Hybrid Automatic Repeat reQuest/ Pedido de Retransmissão Automática Híbrido). O DSCH atualmente usado pode também suportar altas taxas de dados, mas a retransmissão é sempre fornecida pela camada RLC (Radio Link Control/ Controle de Enlace de Rádio) no RNC, que reduz a velocidade da transação.
De forma a suportar as novas capacidades, especialmente o HARQ, uma nova entidade MAC (Médium Access Control/Controle de Acesso ao Meio) foi introduzida no relatório técnico 3GPP TR 25.855 VI.0.0 (2001-06): “Projeto de Parceiros da 3a Geração; Especificação Técnica da Rede de Acesso do Grupo de Rádio; Acesso de Pacote de Enlace Descendente de Alta Velocidade; Descrição Global da UTRAN (Edição 5)”, que é incorporado aqui por referência. A nova entidade MAC é denominada de MAC-hs e é sempre localizada no Nó B. Nas edições anteriores do 3GPP, todas as entidades UTRAN MAC capazes de controlar também os dados do plano do usuário eram sempre localizadas exclusivamente nos RNCs. A MAC-hs existe apenas quando a célula é configurada para suportar o conceito HSDPA, e esta é conectada à MAC -c/sh localizada no RNC através da interface Iub. A camada MAC é usada para mapear os canais lógicos para os canais de transporte. O canal lógico é um tipo de canal que é definido entre o controle de enlace de rádio (RLC) em um RNC e na camada MAC. Cada canal lógico define o tipo de dados a ser transmitido através deste. No caso do HSDPA, os canais lógicos sempre localizam no SRNC. O canal de transporte é um tipo de canal que é definido entre a camada MAC e a LI (Layer 1/Camadal). Esta descreve como os dados serão transmitidos através do enlace de rádio. No conceito DSCH, o canal de transporte é visto na interface Iub, considerando que no conceito HSDPA o canal de transporte é um canal interno no Nó B. A conexão dos diferentes MACs de uma UTRAN para o HSDPA é ilustrada na Figura 1, que foi retirada do relatório técnico TR 25.855 citado acima. A Figura 1 descreve um MAC-hs 1 localizado no Nó B, e em adição um MAC -c/sh 2 e um MAC -d 3 localizados em um ou mais RNCs. O MAC -hs 1 é conectado ao MAC -c/sh 2 através da interface Iub, enquanto que a MAC -c/sh 2 é conectada à MAC -d 3 através da interface Iur, neste caso elas são localizadas em um RNC diferente, caso contrário, as MACs 2, 3 são interconectadas localmente. A MAC de controle tem acesso a cada um dos MACs 1-3. Tais canais lógicos como o PCH (Paging Channel/Canal de Paginação) e o BCCH (Broadcast Control Channel/Canal de Controle de Radiodifusão) são diretamente mapeados para a MAC -c/sh 2 sem intervir na MAC -d 3. Contudo, tais canais lógicos como o DCCH (Dedicated Control Channel/Canal de Controle Dedicado) e o DTCH (Dedicated Traffic Channel/ Canal de Tráfego Dedicado) são sempre conectados à MAC -d 3, que direciona os pacotes de dados recebidos para a MAC -c/sh 2, se o UE tiver acesso direto ao canal(s) comum ou ao canal(s) compartilhado(s). A MAC -c/sh 2 e a MAC -d 3 mapeiam os diferentes tipos de canais lógicos nos canais de transporte, como o PCH (Paging Channel/Canal de Paginação), FACH (Forward Access Channel/ Canal de Acesso Direto), DCH (Dedicated Channel/Canal Dedicado) etc., para transmissão para o UE através do Nó B. Os dados relacionados ao HSDPA recebido são fornecidos através da MAC -d 3 através da MAC -c/sh 2 sem mapear para a MAC -hs 1 do Nó B para transmissão no HS DSCHs para o UE. Para os detalhes da Figura 1, esta é referenciada ao relatório técnico TR 25.855.
Alternativamente, o MAC -hs poderia ser conectado diretamente na MAC -d.
Uma vez que as funcionalidades previamente implementadas apenas nos RNCs tem agora de serem fornecidas também nos Nós Bs, como na seleção do TFC (Transport Format Combination/Combinação do Formato de Transporte), a divisão funcional entre o Nó B e o RNC tem sido re-organizada. A nova distribuição de funcionalidades é apresentada nas Figuras 2 e 3, que foram igualmente retiradas do relatório técnico TR 25.855, e que apresentam em maiores detalhes algumas das funções fornecidas pela MAC -c/sh 2 e a MAC -hs 1, respectivamente.
As funções de reorganização, programação/controle de prioridade e de seleção TFC têm sido removidas da MAC -c/sh 2 do RNC na Figura 2 para as transmissões de enlace descendente relacionadas ao HSDPA e adicionadas à MAC -hs 1 do Nó B na Figura 3. Assim, a programação final e o controle de tráfego em tempo real não sob controle RNC e não mais para o HSDPA. Adequadamente, na MAC -c/sh 2 na Figura 2, os dados recebidos relacionados ao HSDPA da MAC -d são passados para a MAC -hs 1 da Figura 3 sem qualquer programação, controle de prioridade ou seleção TFC e etc. sendo executados como para outros dados de enlace descendente. Previamente, estas funções foram sempre de cuidado do SRNC quando o Nó B foi conectado diretamente a um SRNC, ou no CRNC quando o Nó B foi conectado ao CRNC. Em adição, o HARQ é implementado na nova MAC -hs 1 da Figura 3. Para os detalhes das Figuras 2 e 3, estes são referenciados no relatório técnico TR 25.855 citado acima. A reorganização das funcionalidades implica que as transmissões conhecidas dos dados do usuário de enlace descendente e da informação de controle requerida de um RNC para o Nó B tenham de ser adaptadas.
Para a transmissão dos dados do usuário de enlace descendente, foi proposto que a camada RLC não seja alterada. Isto significa que a RLC armazena como antes os PDUs RLC (Protocol Data Units/Unidades de Dados de Protocolo) nas memórias RNC, e que a RLC submete os dados para a camada inferior apenas após o pedido da camada MAC localizada no RNC, isto é, a MAC -d 3. Conseqüentemente, as transações suportam a transmissão de dados entre a entidade MAC no RNC e a MAC -hs 1 no Nó B, que são atualmente definidas apenas no nível alto, mas os detalhes ainda são perdidos. Por estas definições de nível alto, a funcionalidade do fluxo de controle é definida entre a MAC -c/sh 2 e a MAC -hs 1 como uma nova característica, como indicado na Figura 3, de forma a controlar o fluxo de dados do RNC para o Nó B.
Para suportar as transmissões de dados atuais na interface-Iub, a camada de Protocolo do Quadro HS-DSCH (DS-DSCH FP) foi incluída abaixo da MAC -c/sh e acima da MAC -hs. Esta camada é indicada na Figura 4, que foi novamente retirada do relatório técnico TR 25.855. A Figura 4 apresenta a arquitetura do protocolo de interface de rádio do HSDPA, e mais especificamente as camadas dos elementos de rede cujos elementos de rede são, da esquerda para a direita, o equipamento do usuário UE conectado através da interface Uu ao Nó B, que é também conectado através da interface Iub ao primeiro RNC, que é finalmente conectado através da interface Iur ao segundo RNC. Cada um dos Nós B, o primeiro e o segundo RNCs compreendem em adição à entidade MAC respectiva um HS-DSCH FP. Este HS-DSCH FP é entendido para transmitir não apenas os pacotes de dados do RNC para o Nó B, mas também a informação de controle relacionada. Tal protocolo FP é proposto sem quaisquer detalhes para as transmissões de dados no enlace descendente em ambas, a interface Iub e a Iur, cujas transmissões estão usando o serviço da L2 (Layer 2/ Camada 2) da MAC e da RLC. Para os detalhes da Figura 4, é referenciado o relatório técnico TR 25.855 citado acima.
Nenhuma das estruturas de quadro FP amais definidas para a interface Iub, contudo, são aplicáveis para o HSDPA. Em particular a estrutura de quadro FP usada para os DSCHs, dos quais os propósitos DSCHs para o HSDPA procedem, não é adequado para as transmissões de dados HSDPA, uma vez que o quadro DSCH FP contêm os campos dos quais os valores podem apenas serem definidos quando a programação ou a seleção TFC já tiver sido feita. Como mencionado acima, estas funções foram deslocadas para as transmissões relacionadas ao HSDPA para o Nó B. Além disso, o quadro DSCH FP não contém todas as informações que são requeridas para o HSDPA, para suportar o controle de fluxo entre o RNC e o Nó B.
Em adição aos dados do usuário relacionados ao HSDPA, a informação de controle também tem de estar disponível no Nó B, de forma que o Nó B possa estabelecer e re-configurar os canais HS-DSCH para as transmissões.
Devido à reorganização funcional, os procedimentos do protocolo de aplicação amai na Iub para o estabelecimento e re-configuração DSCH, descrito, por exemplo, na especificação técnica 3GPP TS 25.433 V3.4.1 (2000-12): “Projeto de Parceiros da 3a Geração; Especificação Técnica da Rede de Acesso do Grupo de Rádio; Interface Iub UTRAN de Sinalização NBAP (Edição 1999)”, não podem ser usados para o HS-DSCH. Por exemplo, no caso do HSDPA não é necessário prover os parâmetros de codificação de canal durante o estabelecimento do enlace de rádio (RL - Radio Link) como para o DSCH, uma vez que estes parâmetros de codificação de canal são decididos sob o Nó B. Por outro lado, alguns dos parâmetros que não foram requeridos pelo Nó B para o DSCH deveríam ser fornecidos para o Nó B para o HSDPA durante o procedimento de estabelecimento da célula, de forma que o Nó B possa configurar os atributos HS-DSCH na célula. Deveria também ser possível modificar estes parâmetros baseados-célula, preferivelmente de uma maneira semi-estática.
Resumo da Invenção É um objeto da invenção habilitar a transmissão de dados dentro da rede de comunicação, cujos dados são requeridos no elemento de rede da rede de comunicação. É também um objeto da invenção habilitar o uso do HSDPA pela UTRAN, e mais especificamente habilitar o RNC da UTRAN para prover ao Nó B da UTRAN os dados relacionados ao HSDPA. É em particular um objeto da invenção habilitar o RNC para prover um Nó B de uma forma adequada com os dados do usuário relacionados ao HSDPA e com os parâmetros de controle relevantes ao HSDPA na NBAP (Node B Application Part/Parte de Aplicação do Nó B).
Um primeiro aspecto da invenção é direcionado à transmissão de dados do usuário, enquanto o segundo aspecto da invenção é direcionado à transmissão dos parâmetros de controle.
Para o primeiro aspecto da invenção, um método é proposto para transmitir os dados do usuário dentro da rede de comunicação do controlador para o elemento de rede sobre a interface. A rede de comunicação pode ser em particular uma UTRAN, o controlador o RNC, o elemento de rede o Nó B e a interface uma interface Iub. O controlador usa ao menos uma estrutura de quadro dedicada, em particular uma estrutura de quadro HSDPA FP dedicada, para montagem dos quadros de dados com os dados do usuário. Os quadros de dados são então transmitidos através da interface para o elemento de rede. A estrutura de quadro inclui ao menos uma seção de cabeçalho para receber a informação requerida no elemento de rede para processar os dados do usuário.
Para o primeiro aspecto da invenção, em adição à rede de comunicação, em particular uma UTRAN, o controlador, em particular o RNC, e o elemento de rede, em particular o Nó B, são propostos e os quais compreendem meios para realizar o método proposto.
Referenciando ao primeiro aspecto, a invenção procede da idéia de que a transmissão da informação requerida para o processamento dos dados do usuário relacionados ao HSDPA deveria ser similar às soluções usadas para outros canais compartilhados, mas ainda serem otimizadas para os requerimentos do HSDPA. A estrutura de quadro dedicada proposta permite remover todos os campos empregados nas estruturas para o DSCH que não são mais necessárias para o HSDPA, e para inserir os campos na informação requerida adicionalmente para o HSDPA. Assim, uma transmissão otimizada da informação requerida para os dados do usuário relacionados ao HSDPA através da interface lub é habilitada. As mesmas considerações podem ser aplicadas em outras redes de comunicação, elementos de rede e situações.
Para o segundo aspecto da invenção, é proposto um método para proporcionar um elemento de rede de uma rede de comunicação com os parâmetros de controle disponíveis no controlador da rede de comunicação, cujo controlador é conectado ao elemento de rede através de uma interface. A rede de comunicação pode ser, em particular uma UTRAN, o controlador o RNC, o elemento de rede o Nó B e a interface uma interface lub. O método compreende empregar um protocolo de aplicação de interface que habilita a inserção de pelo menos um parâmetro de controle, em particular um parâmetro de controle relacionado ao HSDPA, em ao menos um tipo de mensagem de controle transmitida do controlador para o elemento de rede sobre a interface.
Ainda para o segundo aspecto da invenção, além da rede de comunicação, em particular uma UTRAN, o controlador, em particular o RNC, e de um elemento de rede, em particular o Nó B, os quais são propostos para compreenderem meios para realizar o método proposto.
Referindo ao segundo aspecto, a invenção procede da idéia de que o modo mais eficiente para proporcionar um Nó B com os parâmetros de controle requeridos para estabelecer a re-configuração dos canais HS DSCH é incluir os parâmetros nas mensagens de controle transmitidos de um RNC para o Nó B. Uma vez que o RNC e o Nó B são conectados um ao outro através da interface lub, é então proposto modificar o protocolo de aplicação lub adequadamente. Como resultado, o Nó B é, por exemplo, capaz de estabelecer e de re-configurar os canais HS-DSCH baseados nos parâmetros de controle recebidos. O Nó B então pode ser configurado pelo RNC para suportar os dados relacionados ao HSDPA para o equipamento do usuário na célula. As mesmas considerações podem ser aplicadas em outras redes de comunicações, elementos de rede e situações.
Ambos os aspectos da invenção têm em comum que eles incluem uma implementação específica HSDPA das especificações gerais usadas para transmitir os dados do RNC para o Nó B através da interface Iub, isto é, por um lado, a implementação das estruturas de quadro dedicadas e, por outro lado, a implementação do protocolo de aplicação Iub com os procedimentos específicos HSDPA.
As incorporações preferidas da invenção tomam-se aparentes através das reivindicações dependentes.
Em uma incorporação preferida do primeiro aspecto da invenção, a estrutura de quadro também compreende uma seção de carga útil para receber ao menos uma SDU para a qual os dados do usuário relacionados ao HSDPA foram distribuídos pelo controlador, onde a seção de cabeçalho recebe a informação requerida no elemento de rede para processar os dados do usuário relacionados ao HSDPA. Assim, as informações requeridas para o Nó B para processar os dados do usuário relacionados ao HSDPA podem ser transmitidas de forma vantajosa em um único quadro junto com os dados do usuário. As SDUs são em particular MAC -d SDUs e/ou MAC -c/sh SDUs.
Para o primeiro aspecto da invenção será observado que a estrutura de quadro HSDPA FP proposta pode ser projetada para receber qualquer número de informação, cuja informação pode ser predeterminada arbitrariamente de acordo com as exigências.
Em adição, não deveria ser obrigatório que a seção de carga útil contivesse quaisquer dados em um quadro montado de acordo com a estrutura de quadro dedicada, de forma que a mesma estrutura possa ser usada para transmitir a informação apenas na seção de cabeçalho, por exemplo, a informação para o controle de fluxo HSDPA.
Em particular, diferentes estruturas de quadro FP podem ser providas para os casos onde a multiplexação MAC/FP UE-ID é ou não permitida no RNC. A multiplexagem UE-ID é um tipo de multiplexação, na qual diferentes UEs são multiplexados sobre o mesmo canal de transporte e podem ser executados na camada MAC ou na camada FP de um RNC. No caso da multiplexação FP UE-ID, o cabeçalho do quadro FP deveria sempre conter a identificação do UE-ID. Esta identificação pode ser, por exemplo, RNTI, ou esta pode ser uma nova identificação definida para este propósito apenas e então ser mais curta que a RNTI atual. No caso da multiplexação MAC UE-ID, o campo UE-ID é usado no cabeçalho da MAC, isto é, o RNTI é adicionado no cabeçalho da MAC, e nenhuma identificação necessariamente é requerida no quadro FP. O Nó B pode ir buscar a informação do UE-ID ao ler o cabeçalho da MAC. Então, se for desejado novamente que o quadro FP contenha o campo UE-ID apesar da adição do RNTI no cabeçalho da MAC, o UE-ID usado pode ser, por exemplo, o RNTI, ou pode ser uma nova identificação definida para este propósito apenas e então ser mais curta que o RNTI atual.
Existem diferentes alternativas de como a multiplexação pode ser executada, e o método de multiplexação usado pode ter de ser considerado ao determinar a estrutura mais adequada do quadro FP. O tipo de multiplexação usado pode em particular ter um impacto no número de campos do mesmo tipo fornecido em um quadro FP. Uma alternativa para a multiplexação é a multiplexação com base na divisão de tempo, o que significa que um quadro de dados FP pode carregar os dados, que pertencem a um UE apenas. Em uma outra alternativa é possível carregar os dados que pertencem a diferentes UEs em um quadro FP. Em adição, a multiplexação poderia ser levada ao cuidado de permitir que uma entidade FP envie apenas um quadro FP dentro de um TTI, e este quadro poderia ser dedicado a apenas um UE ou este poderia transmitir os dados para vários UEs. A multiplexação também poderia significar que uma entidade FP poderia enviar mais de um quadro FP dentro de um TTI, que são todos designados para um UE, ou cada quadro FP poderia carregar os dados que são significados para diferentes UEs.
Igualmente, diferentes estruturas de quadro FP podem ser providas para os casos onde a identificação do equipamento do usuário tem ou não tem de ser transmitida do RNC para o Nó B. O tamanho dos quadros baseado na estrutura de quadro predeterminada pode ser feito variável, ao permitir que alguma informação na seção de cabeçalho do campo dedicado para cada equipamento do usuário ou para cada memória RNC, da qual os dados foram obtidos. A estrutura de campo também pode de ser generalizada ao realizar a inserção de alguma informação opcional.
Algumas das informações que são levadas em conta por uma estrutura de quadro específica podem ser relacionadas à memória RNC ou a armazenagem empregada na transmissão de dados HSDPA para a armazenagem dos dados do usuário no RNC. Será observado que o termo armazenagem RNC ou memória RNC é usada para indicar a capacidade de armazenagem no RNC sem identificar a localização exata da memória. Então, a armazenagem pode ser provida, por exemplo, na camada RLC e/ou na camada MAC.
No primeiro aspecto da invenção, a informação específica do equipamento do usuário pode ser incluída na seção do cabeçalho da estrutura de quadro proposta, ou em uma seção do cabeçalho de um SDU respectivo inserido na seção de carga útil da estrutura de quadro proposta.
No segundo aspecto da invenção, o protocolo de aplicação Iub pode permitir a inclusão de qualquer tipo adequado e de um número de parâmetros em qualquer tipo adequado de mensagem de acordo com as exigências.
Existem duas classes de parâmetros de controle que poderíam ser providas do RNC para o Nó B de acordo com o segundo aspecto da invenção. O RNC decide o valor exato de um parâmetro e o Nó B tem que seguir esta decisão, ou o RNC provê um limiar de possíveis escolhas. No último caso, o Nó B pode decidir o valor de acordo com as suas próprias condições dentro do limiar fornecido. Assim, o conteúdo de cada parâmetro de controle ou é um valor fixo, uma indicação de uma gama para o valor, ou um grupo de valores permitidos para serem usados através do Nó B.
Os parâmetros de controle do segundo aspecto da invenção podem ser, em particular, os parâmetros específicos da célula requeridos no Nó B, por exemplo, para o estabelecimento e/ou a re-configuração de uma célula, ou um parâmetro específico do enlace de rádio requerido no Nó B, por exemplo, para o estabelecimento e/ou a re-configuração do enlace de rádio. Este pode então ser determinado através do protocolo de aplicação Iub, cujos parâmetros serão incluídos nas mensagens de controle relativas ao estabelecimento ou a re-configuração da célula ou respectivamente em uma mensagem de controle relativa ao estabelecimento ou a re-configuração RL.
Ambos, os parâmetros específicos da célula e os parâmetros específicos RL podem ser providos como valor específico ou como salto de escolhas.
Para incluir os parâmetros de controle do segundo aspecto da invenção em uma mensagem de controle, preferivelmente um ou mais elementos de informação (IE) ou um grupo de IEs é definido. Cada IE pode então incluir um campo para cada parâmetro requerido para uma situação específica. Os IEs podem ser adicionados em uma mensagem de controle que tem de ser transmitida nesta situação específica. Em adição, os IEs definidos para DSCH ou os IEs correspondentes poderíam ser usados, até onde os parâmetros exigidos forem os mesmos para algumas situações. É também possível definir conjuntos de IEs e/ou grupos de IEs para as situações específicas que serão adicionadas em alguma mensagem de controle para a respectiva situação.
Breve Descrição das Figuras A seguir, a invenção é explicada em maiores detalhes com referência aos desenhos, nos quais: Figura 1 - apresenta a estrutura global da MAC da parte-UTRAN conhecida definida para o HSDPA;
Figura 2 - apresenta os detalhes da MAC -c/sh conhecida do RNC;
Figura 3 - apresenta os detalhes da MAC -hs conhecido do nó B;
Figura 4 - apresenta a arquitetura do protocolo de interface de rádio definido para o HSDPA;
Figura 5 - apresenta um modelo para a Iub, quando nenhuma multiplexação do nível MAC é permitida no RNC;
Figura 6 - apresenta um modelo para a Iub, quando a multiplexação do nível MAC é permitida no RNC;
Figura 7 - apresenta uma estrutura de quadro DSCH FP conhecida;
Figura 8 - apresenta a primeira incorporação da estrutura de quadro HDSPA FP de acordo com a invenção;
Figura 9 - apresenta a segunda incorporação da estrutura de quadro HDSPA FP de acordo com a invenção;
Figura 10 - apresenta a terceira incorporação da estrutura de quadro HDSPA FP de acordo com a invenção;
Figura 11 - ilustra a estrutura MAC PDU;
Figura 12 - apresenta o primeiro exemplo dos valores do campo do cabeçalho do quadro FP para a incorporação da Figura 10;
Figura 13 - apresenta o segundo exemplo dos valores do campo do cabeçalho do quadro FP para a incorporação da Figura 10;
Figura 14 - é uma tabela apresentando um grupo de IEs específicos da célula para uma incorporação do segundo aspecto da invenção;
Figura 15 - é uma tabela apresentando um IE específico da célula RL para uma incorporação do segundo aspecto da invenção;
Figura 16 - é uma tabela apresentando o primeiro grupo de IEs específicos da célula RL para uma incorporação do segundo aspecto da invenção;
Figura 17 - é uma tabela apresentando o segundo grupo de IEs específicos da célula RL para uma incorporação do segundo aspecto da invenção; e Figura 18 - é uma tabela ilustrando uma modificação de um TFS conhecido para uma incorporação do segundo aspecto da invenção.
Descrição Detalhada da Invenção Primeiro, as três incorporações de uma estrutura de dados HSDPA FP de acordo com o primeiro aspecto da invenção será apresentado.
As respectivas estruturas de quadro serão usadas para transmitir o HSDPA relacionado aos dados do usuário dentro da UTRAN da MAC -c/sh do RNC através de uma interface Iub para a MAC -hs do Nó B. O UE para o qual os dados do usuário são endereçados é conectado a este Nó B.
Ao determinar uma estrutura de quadro adequada, as exigências e as capacidades dos elementos de rede, isto é, o RNC e o Nó B, deveríam ser considerados. Um fator que deveria ser considerado, por exemplo, é a multiplexação MAC/FP UE-ID que pode ser permitida no RNC ou não, como será explicado a seguir.
No primeiro modelo que é ilustrado na Figura 5, o RNC não é permitido para executar a multiplexação do nível MAC/FP UE-ID. A Figura 5 esquematicamente apresenta o RNC 4 e o Nó B 5 interconectados através de uma interface Iub. O RNC 4 inclui o RLC 6, a MAC -d e a MAC -c/sh 2,3 e uma entidade FP 7. O Nó B 5 compreende igualmente uma entidade FP 8, e a MAC -hs 1. Na situação atual, três portadoras RB de rádio w, z e v são designadas para o primeiro equipamento do usuário UEx, enquanto as duas portadoras RB de rádio adicionais m e n são designadas para o segundo equipamento do usuário UEy. As RBs do UEy e igualmente a RB v do UEx são passadas sem multiplexação do RLC 6 nos canais lógicos através da MAC -d e da MAC -c/sh 2,3 e da entidade FP 7, da interface Iub e da entidade FP 8 do Nó B 5 para o MAC -hs 1. As RBs w e z do UEx são multiplexadas C/T na camada MAC do RNC 4 e transmitidas em uma única conexão de transporte através das mesmas entidades para o Nó B 5. A multiplexação C/T significa a multiplexação de diferentes RBs, isto é, as quais usam diferentes canais lógicos, que são todos nomeados para o mesmo UE no mesmo canal de transporte. A MAC -hs 1 então mapeia os canais lógicos recebidos nos canais de transporte.
Se a multiplexação C/T é permitida para ser executada entre as portadoras de rádio (RB), as quais todas são designadas para o mesmo UE, o número mínimo de conexões de transmissão Iub requerido é igual ao número de UEs que tem acesso ao HS-DSCH. A multiplexação C/T pode ser usada pelo RNC, por exemplo, apenas para algumas RBs de alguns UEs, como na Figura 5, ou para todas as RBs de todos os UEs.
Alternativamente, a multiplexação C/T das diferentes portadoras de rádio RB na mesma conexão de transmissão Iub pode não ser permitida no RNC 4 da Figura 5. A multiplexação C/T pode nem mesmo ser permitida para prover, por exemplo, os diferentes níveis de prioridade, se todas as portadoras de rádio forem designadas para o mesmo UE. Neste caso, o número de conexões de transporte na interface Iub é igual ao número de portadoras de rádio que estão usando o método de transporte do tipo HSDPA.
No segundo modelo que é ilustrado na Figura 6, o RNC 4 é permitido em contraste com à execução da multiplexação UE-ID do nível MAC. A Figura 6 apresenta esquematicamente a mesma estrutura do RNC 4 e do Nó B 5 interconectados através de uma interface Iub como na Figura 5. Apenas neste caso, a MAC -d 3 e a MAC-c/sh 2 separadas são descritas. Além disso, as mesmas portadoras RB de rádio w, z, v, m e n são designadas para os mesmos equipamentos do usuário UEx, UEy como na Figura 5. As portadoras de Rádio RB w e RB z são novamente multiplexadas C/T na camada MAC, mais especificamente pela MAC -d 3. Em adição, a saída de multiplexação C/T e as três outras portadoras de rádio RB v, m e n são UE-ID multiplexadas pela MAC -c/sh 2 para uma única conexão de transporte para transmissão para a MAC -hs 1 pela camada FP 7 do RNC 4, da interface Iub e da camada FP 8 do Nó B 5. A MAC -hs 1 executa primeiro a demultiplexação, e então o mapeamento dos canais lógicos nos canais de transporte.
No Nó B 5, a camada MAC correspondentemente demultiplexa a informação recebida, antes de mapear esta para os HS-DSCHs e também para o HS-PDSCH como na Figura 5.
Podería também haver mais de uma conexão de transporte usada na multiplexação. A idéia geral na multiplexação é que é possível que todos os UEs que preenchem os mesmos critérios possam usar os mesmos recursos de transporte. A multiplexação pode ser baseada, por exemplo, no número de células no Nó B. Isso significa que, se o Nó B suportar mais de uma célula, uma conexão de transporte é fornecida por célula. Alternativamente, a multiplexação poderia ser baseada nos níveis de prioridade designados para os canais lógicos, isto é, em uma conexão de transporte que é provida por prioridade. Em adição, apenas uma única conexão de transporte poderia ser provida para o Nó-B. A multiplexação também poderia ser baseada no número HSDPA relacionado aos canais físicos na interface de Rádio.
No segundo modelo, a multiplexação MAC/FP UE-ID não é restrita de qualquer forma, o que significa que é possível a todos os UEs serem permitidos o uso da mesma conexão de transporte na interface Iub. O segundo modelo pode ser provido também ao dispor a multiplexação UE-ID para a camada FP. Em ambos os casos, se o RNTI for usado no cabeçalho MAC, nenhum UE-ID é obrigatório no quadro FP, e se nenhuma identificação for incluída no cabeçalho, mas a multiplexação MAC for permitida, então o cabeçalho FP também deveria conter o campo(s) UE-ID.
Quando a multiplexação MAC/FP UE-ID é permitida, a estrutura de quadro deveria ser definida, de modo que o receptor seja capaz de extrair a informação que pertence aos diferentes UEs corretamente do quadro HSDPA recebido.
As Figuras 7 a 10 agora apresentam uma estrutura de quadro DSCH FP convencional definida para a interface Iub apresentada para comparação, a primeira incorporação da estrutura de quadro HSDPA FP para o caso quando nenhuma multiplexação UE-ID é permitida e a segunda e a terceira incorporação da estrutura de quadro HSDPA FP para o caso, onde a multiplexação UE-ID é permitida. A estrutura de quadro DSCH FP da Figura 7 foi retirada da especificação técnica 3GPP TS 25.435, V3.5.0 (2000-12): “ Projeto de Parceiros da 3a Geração; Especificação Técnica da Rede de Acesso do Grupo de Rádio; Os Protocolos do Plano da Interface do usuário Iub UTRAN para os Fluxos de Dados do Canal de Transporte Comum (Edição 1999)”. Esta é composta de uma seção de carga útil e de uma seção de cabeçalho, cada qual dividida em colunas de 0-7 de 8 bits. A seção de carga útil inclui primeiro o último TBs (Transport Blocks/blocos de transporte), uma “Extensão de Reserva”, e um CRC de Carga útil”(CRC/ Cyclic Redundancy Check - Verificação de Redundância Cíclica). A seção do cabeçalho inclui os campos do “Cabeçalho CRC”, “FT”, “CFN”, “TFI”, “Compensação de Potência”, “Número de Código”, “SF” e “Info MC”. O campo “CFN” é usado para indicar o número de quadro da conexão (CFN - Connection Frame Number), onde os dados de um quadro deveríam ser transmitidos através da interface de rádio. No conceito HSDPA, o valor deste campo é apenas conhecido pelo Nó B após a programação dos dados correspondentes para a interface de rádio, e então o RNC não pode prover este campo para o Nó B. O campo “TFI” é usado para indicar o formato de transporte válido (TF -Transport Format) para os dados no quadro. No conceito HSDPA, a seleção TFC é executada no Nó B, e então o RNC não pode submeter tal informação ao Nó B. O campo “Compensação de Potência” é usado para indicar o nível de potência solicitado para a transmissão dos dados do quadro FP correspondente. Este campo é necessário no caso do DSCH, porque para o DSCH um controle de potência de laço fechado é fornecido. No caso do HSDPA, nenhum controle de potência de laço fechado é fornecido, e então nenhuma informação de controle de potência é requerida do RNC. O campo “Número de Código” indica o código usado para o DSCH. No caso do HSDPA, a seleção de código é feita no Nó B, e então nenhuma informação é requerida do RNC. O campo “SF” identifica o fator de dispersão (SF - Spreading Factor) a ser usado no PDSCH para os pacotes de dados correspondentes no quadro. No conceito HSDPA, o SF é definido no Nó B, e então nenhuma informação é requerida do RNC. O campo “Info MC” é usado para indicar o número de códigos do PDSCH paralelos nos quais os dados DSCH serão carregados. No conceito HSDPA, este tipo de informação é definida no Nó B, e então nenhuma informação é requerida do RNC.
Assim, nenhum dos campos da seção de cabeçalho exceto o campo “Cabeçalho CRC” e o campo “FT” (Frame Type/tipo de armação) são requeridos para o HSDPA, e estes campos podem ser removidos ao designar uma estrutura de quadro HSDPA FP. Mas por outro lado, se os campos forem simplesmente removidos, o Nó B não recebe informação suficiente para extrair o quadro FP recebido. Então, novos campos são requeridos para garantir que os mecanismos de controle de fluxo trabalhem como a nova entidade MAC MAC -hs que é localizada no Nó B. A Figure 8 apresenta uma estrutura de quadro HSDPA que inclui novos campos para o caso em que nenhuma multiplexação MAC/FP UE-ID é permitida. Este é composto novamente de uma seção de carga útil e de uma seção de cabeçalho, cada qual dividida em colunas de 8 bits. Similar a estrutura de quadro DSCH, a seção de carga útil inclui primeiro a última MAC -c/sh SDUs (Service Data Units/unidades de dados de serviço), uma “Extensão de Reserva”, e a “CRC da Carga Útil”. A estrutura de uma SDU MAC com um cabeçalho variável é conhecida do estado da técnica como PDU MAC, e será descrita abaixo com referência à Figura 11. A seção do cabeçalho agora inclui os campos referenciados para “Cabeçalho CRC”, “FT”, “NumOfSDUs”, o “Tamanho da Memória do Usuário”, “tipo de UE-ID”, e “CMCH-PI”. Em particular uma introdução dos últimos dois campos é opcional. O campo “NumOfSDUs” é usado para indicar o número das SDUs MAC -c/hs no quadro. O comprimento do campo pode ser selecionado adequadamente. O campo “Tamanho da Memória do Usuário” é usado para indicar o status da memória designada para o respectivo UE nas memórias RNC (por exemplo, em bytes). Este campo informa ao Nó B quantos dados pertencem ao mesmo fluxo de dados e quantos são ainda deixados no RNC. Uma quantidade de dados carregada no quadro de dados FP correspondente pode ser excluída ou incluída no campo de informação do tamanho da memória do usuário. O Nó B pode usar esta informação na programação, por exemplo, de forma que o fluxo de dados que tem a prioridade mais alta e, a maioria dos dados na memória RNC adquira o acesso ao canal HSDPA antes do fluxo de dados que tem uma prioridade mais baixa e uma quantidade menor de dados na memória RNC. Diferentes significações possíveis do termo memória RNC serão explicados abaixo com referência às Figuras 12 e 13. O comprimento do campo pode ser selecionado adequadamente. O campo “Tipo UE Id” é usado, para indicar o tipo de RNTI, isto é, o c-RNTI ou o U-RNTI, o MAC -hs do Nó que B deveria adicionar ao cabeçalho MAC. O tipo U-RNTI (UTRAN Radio NetWork Temporary Identity/Identidade Temporária da Rede de Rádio UTRAN) pode ser usado no cabeçalho MAC da PDU MAC, onde a parte da carga útil contém as mensagens de sinalização L3 específicas (RRC) quando o uso do U-RNTI é obrigatório. Este tipo de situação é informado através da RRC ao enviar o comando para a L2 (camada MAC através da camada RLC) para usar U-RNTI em vez do C-RNTI no cabeçalho MAC. O tipo C-RNTI (Cell Radio NetWork Temporary Identity/Identidade Temporária da Célula da Rede de Rádio) é usado no DTCH e no DSCH no modo FDD (Frequency Division Duplex/Duplex por Divisão de Freqüência), e pode ser usado no cabeçalho MAC, quando nenhum pedido para usar U-RNTI é recebido das camadas superiores (RRC). O campo “tipo UE ID” é requerido apenas se o RNTI é especificado para ser adicionado ao Nó B. Se o RNTI for especificado para ser adicionado em um SRNC ou se nenhum RNTI é usado para as transmissões de dados HSDPA, tal campo não é requerido no quadro de dados HSDPA FP. O comprimento do campo é de um bit. O campo “indicador de prioridade do canal de transporte comum” (CMCH-PI - Common Transport Channel Priority Indicator) é usado para indicar a prioridade relativa do quadro de dados e/ou das SDUs incluídas. Para as transmissões de dados HSDPA o uso deste campo pode ser introduzido, mas a prioridade da RB quando nenhuma multiplexação é provida podería ser introduzida no momento da conexão de transporte correspondente sobre o Iub ser configurada.
Nesta primeira incorporação de uma estrutura de quadro HSDPA FP, não ê necessário que o campo para a informação de tamanho SDU MAC seja incluído, porque para o HSDPA tem sido definido que os tamanhos TB semi-estáticos serão usados, onde a SDU MAC é de um tamanho fixo, no caso de nenhuma multiplexação ser permitida. A Figura 9 apresenta uma estrutura de quadro HSDPA que inclui novos campos para o caso da multiplexação MAC/FP UE-ID ser permitida. Esta é composta novamente de uma seção de carga útil e de uma seção de cabeçalho, cada qual dividida em colunas de 8 bits. Similar a estrutura de quadro DSCH FP e a primeira incorporação da estrutura de quadro HSDPA FP, a seção de carga útil inclui primeiro a última SDUs MAC -c/sh (Service Data Units/Unidades de Dados de Serviço), uma “Extensão de Reserva”, e uma “Carga útil CRC”. A seção do cabeçalho agora inclui os campos referenciados por “Cabeçalho CRC”, “FT”, “NumOfSDUs”, “NumOfBuff”, “Tamanho da SDU MAC”, “Tamanho da Memória do Usuário” 1-N, “tipo UE-ID”, e “CMCH-PI”. Também para “NumOfSDUs”, “NumOfBuff2”, “Tamanho da MAC SDU”, e “CMCH-PI” pode haver vários campos, embora apenas um campo para cada parâmetro seja indicado na figura. O campo “NumOfSDUs” é usado para identificar o número das SDUs MAC -c/sh que foi retirado da memória RNC. O comprimento do campo pode ser estabelecido adequadamente. O número deste tipo de campo é igual ao número dos campos “NumOfBuff”. O campo “NumOfBuff” indica quantos dados de memória RNC tem sido fornecidos para este quadro FP. Será observado que este campo não descreve o número das memórias RNC, das quais os dados poderiam ser fornecidos. O comprimento do campo pode ser fixado adequadamente. O campo “Tamanho da MAC SDU” é introduzido, porque a multiplexação da MAC não é uma característica obrigatória, isto é, é possível que mesmo se a multiplexação MAC/FP UE-ID for permitida, alguns dos operadores não queiram usar isto. Então, para suportar o caso de múltiplos-vendedores quando a multiplexação MAC/FP UE-ID é permitida, o campo “tamanho da MAC SDU” define o tamanho das SDUs no respectivo quadro. A princípio, o TB tem sempre um tamanho fixo no HSDPA, mas uma vez que o cabeçalho MAC é de comprimento variável, o qual depende se a multiplexação MAC/FP UE-ID é suportada ou não, então o tamanho da SDU MAC pode variar dependendo do conteúdo ou da existência do cabeçalho MAC. Esta informação é requerida no lado do receptor para extrair as SDUs do quadro de dados HSDPA corretamente. O comprimento do campo pode ser fixado adequadamente. O campo “Tamanho da Memória do Usuário” é usado para indicar o status da memória designado para um UE nas memórias RNC em bytes. O comprimento do campo pode ser fixado adequadamente. O número de campos deste tipo em um quadro é igual ao número de campos “NumOfBuff”. O campo “CMCH-PI” poderia ser usado para prover uma informação sobre a prioridade dos dados quando a multiplexação MAC/FP UE-ID for permitida. Se for permitido multiplexar os dados com diferentes níveis de prioridade, então o número de campos deste tipo deve ser igual ao número do campo “NumOfBuffer”, mas se nenhuma multiplexação for permitida, é suficiente prover um campo “CMCH-PI” por quadro.
Será observado que mesmo se a multiplexação MAC/FP UE-ID for permitida, o número da multiplexação respectivo relacionado aos campos “NumOfSDUs”, “Tamanho da Memória do Usuário”, “Tamanho da MAC SDUs” e “CMCH-PI” pode ser diminuído, se uma restrição for identificada que um quadro HSDPA FP pode conter apenas os dados que pertencem a um UE ou RB. Neste caso, a multiplexação MAC/FP UE-ID é realizada baseada em um método de divisão de tempo.
Uma outra modificação da estrutura de quadro HSDPA FP apresentada como a terceira incorporação relaciona a uma identificação do equipamento do usuário no HSDPA relacionado nas transmissões de dados.
Se nenhuma identificação do UE for requerida no Nó B, e nenhuma multiplexação MAC/FP UE-ID for permitida no RNC, a identificação do EU não é incluída no RNC nem no Nó B. Os dados são mais bem identificados usando outros métodos.
Contudo, se uma identificação do UE for requerida, os lugares onde esta informação pode ser acoplada com os dados são o MAC -c/sh em um CRNC ou o MAC -hs em um Nó B. No primeiro caso, a identificação do UE poderia ser atualmente usada no RNTI ou este pode ser uma identificação nova do UE que é definida apenas para a transmissão de dados sobre a interface Iub.
Se o RNTI for usado, a informação de identificação UE pode ser incluída nos cabeçalhos MAC -c/sh SDU, que já têm os campos para este propósito, ou na seção de cabeçalho do respectivo quadro de dados HSDPA FP. Se for incluído no cabeçalho MAC -c/sh SDU, o Nó B tem que extrair esta parte de cabeçalho para descobrir a identidade do UE. Se a identidade do UE for incluída na seção de cabeçalho de uma estrutura de quadro HSDPA FP, nenhuma extração é requerida.
Para a estrutura de quadro da Figura 9 foi assumido que se a identificação do UE for requerida, a identificação é RNTI e é incluída no cabeçalho MAC SDU no CRNC ou no Nó B.
Para o caso de nenhuma RNTI ser desejada na interface aérea, mas ainda a identificação do UE ser desejada na Iub, uma terceira incorporação da estrutura de quadro é apresentada e ilustrada na Figura 10. A estrutura de quadro da Figura 10 novamente suporta a multiplexação MAC/FP UE-ID e inclui todos os campos presentes na estrutura de quadro da Figura 9. Este inclui os campos adicionais “UE-id 1” para “UE-id N” para identificar os UEs para os quais os dados são incluídos na MAC -c/sh SDUs na seção de carga útil. Nesta figura, existe também N campos diferentes “NumOfBuff”, “NumOfSDUs”, “Tamanho da MAC SDU”, e “CMCH-PI”, respectivamente, indicados explicitamente. O conteúdo do campo de identificação UE “UE-id” pode ser o RNTI, mas de forma a armazenar a capacidade de transmissão na interface Iub, uma nova identificação mais curta poderia ser definida. O comprimento deste campo depende do tipo de identificação selecionado. O número do campo “UE-id” depende se um quadro HSDPA pode conter dados para diferentes UEs. Se isto for permitido, o número dos campos deve ser igual ao número do campo “NumOfBuff”. Contudo, se a multiplexação MAC/FP UE-ID for permitida, isto é, mais de um UE estiver usando a mesma conexão de transporte na interface Iub, então um quadro HSDPA FP pode conter dados apenas de uma memória RNC, o número dos campos de identificação UE requerido é 1. A Figura 11 apresenta a estrutura MAC PDU quando o DTCH ou o DCCH é mapeado para o DSCH e quando o DTCH ou o DCCH é apenas um canal lógico, os quais também podem ser empregados para o HSDPA. A figura foi retirada da especificação técnica 3GPP TS 25.321 V3.6.0 (2000-12): “Projeto de Parceiros de 3a Geração; Especificação Técnica da Rede de Acesso do Grupo de Rádio; e a especificação do protocolo MAC (Edição 1999)”. O MAC PDU na Figura 11 é composto de um MAC SDU e de um cabeçalho MAC. O cabeçalho inclui um campo “tipo UE-id”, um campo “UE-id” e um campo “C/T”. Os campos “tipo UE-id” e “UE-id” são incluídos no cabeçalho MAC para o modo FDD apenas. O campo “UE-id” provê um identificador do UE nos canais de transporte comum. O campo “Tipo UE-id” é necessário para assegurar uma correta decodificação do campo UE-id nos Cabeçalhos MAC. O campo “C/T” é incluído no cabeçalho MAC se a multiplexação C/T no MAC for aplicada. O campo “C/T” provê a identificação do exemplo do canal lógico quando múltiplos canais lógicos são transportados no mesmo canal de transporte. O campo “C/T” é também usado para prover uma identificação do tipo de canal lógico nos canais de transporte dedicados e no FACH (Forward Access Channel/Canal de Acesso Direto) e, no RACH (Random Access Channel/Canal de Acesso Randômico) quando usado para transmissão de dados do usuário. O tamanho do campo “C/T” é fixado em 4 bits tanto para os canais de transporte comum quanto para os canais de transporte dedicados.
Para o primeiro aspecto da invenção, finalmente um exemplo é apresentado de como os valores do campo do cabeçalho do quadro FP de acordo com a estrutura de quadro na Figura 10 podem ser estabelecidos para os dois modelos diferentes para as memórias RNC. O primeiro modelo de memória é ilustrado na Figura 12. Nesta alternativa, as últimas memórias RNC antes das memórias do Nó B são localizadas na camada RLC no RNC. A Figura 12 apresenta cinco destas memórias RNC 9, a memória RLC z, h, k y e u. A memória RLC z é designada para os dados para o equipamento do usuário UEx, mais especificamente para a portadora de rádio RBz usada para este UE. Esta produz dados com um nível de prioridade r para uso em uma PDU RLC. As memórias RLC h e k são designadas, respectivamente, para as portadoras de rádio RBh e RBk, que são ambas usadas para o equipamento do usuário UEy. Apenas a memória k, contudo, produz os dados para a distribuição para PDUs RLC. Mais especificamente, dois canais lógicos são fornecidos da camada RLC pela memória k. Para os dados, um nível m de prioridade é designado, e os dados são distribuídos para as duas PDUs RLC. As memórias RLC y e u são designadas, respectivamente, para as portadoras de rádio RBy e RBu, que são ambas usadas para o equipamento do usuário UEz. A memória v produz os dados com um nível r de prioridade para uso na PDU RLC. A memória u produz os dados com um nível m de prioridade, cujos dados são distribuídos para as três PDUs RLC. Cada PDU RLC será usada a camada MAC como base para uma SDU MAC -c/sh em um quadro HSDPA FP montado.
No modelo da Figura 12, o valor do campo “NumOfBuff” pode ser definido baseado nas RBs. Isso significa que, o valor do campo “NumOfBuff” é igual ao número de RBs, e também o número da memória RLC 9, que provêem os dados para o quadro HSDPA FP. Assim, no exemplo apresentado, o valor do campo “NumOfBuff” do quadro de dados baseado na estrutura de quadro da Figura 10 é estabelecido para 4, uma vez que os dados são extraídos de quatro das memórias RNC, isto é, das memórias RLC z, k,y e u. O valor do campo “NumOfSDUs” para a memória RLC z é estabelecido para 1, uma vez que apenas os dados para a PDU RLC foram extraídos desta memória para o quadro atual. Para a memória RLC k, o valor do campo “NumOfSDUs” é estabelecido para 2, uma vez que os dados para as duas PDUs RLC foram extraídos desta memória para o quadro atual. Para a memória v RLC, o valor do campo “NumOfSDUs” é novamente estabelecido para 1, uma vez que apenas os dados para a PDU RLC foram extraídos desta memória para o quadro atual. Para a memória RLC u, o valor do campo “NumOfSDUs” é estabelecido para 3, uma vez que os dados para três PDUs RLC foram extraídos desta memória para o quadro atual. O valor dos campos “SizeOfSDUs” e “Tamanho da Memória do Usuário” é estabelecido para os valores aplicáveis respectivamente. No exemplo descrito, o equipamento do usuário UEy tem uma entidade RLC, da qual são providos dois canais lógicos diferentes para camada MAC, como indicado na figura. Tal configuração é possível no modo RLC reconhecido. Mesmo se os dados forem recebidos de dois canais lógicos, a informação do tamanho da memória necessita ser combinada, o que significa que o campo “Tamanho da Memória do Usuário” contém a informação sobre o status da memória RLC k. O valor do campo “UE-id” para a memória RLC z é estabelecido para x, uma vez que os dados nesta memória são significativos para UE x. O valor do campo “UE-id” para a camada RLC k é estabelecido para y, uma vez que os dados nesta memória são significativos para UE y. O valor do campo “UE-id” para as memórias RLC y e u é estabelecido para z, uma vez que os dados nesta memória são significativos para UE z. O valor do campo “CMCH-PI” para a memória RLC z e a memória RLC v respectivamente é fixado em r, uma vez que o nível de prioridade para os dados destas duas memórias foi estabelecido para r. O valor do campo “CMCH-PI” para a memória RLC k e a memória RLC u respectivamente é fixado em m, uma vez que o nível de prioridade para os dados destas duas memórias é fixado em m.
Outro modo para realizar as memórias RNC é localizar as últimas memórias antes das memórias do Nó B para a camada MAC do RNC, por exemplo, para a MAC -c/sh que é ilustrada na Figura 13. A Figura 13 apresenta novamente as cinco memórias da camada RLC 10 do RNC, as memórias RLC z, h, k, v e u. Neste caso, porém, em adição, quatro memórias da camada MAC 11 estão presentes, as memórias MAC z , h, k, e uv. A memória RLC z é designada novamente para uma portadora de rádio RBz usada para o equipamento do usuário UEx. A memória RLC z produz os dados com um nível p de prioridade para a memória MAC z, onde a MAC produz os dados para uso em uma SDU MAC. As memórias RLC h e k são designadas novamente e respectivamente para as portadoras de rádio RBh e RBk, que são ambas usadas através do equipamento do usuário UEy. A memória RLC h é conectada a memória MAC h e a memória RLC k para a memória MAC k, mas apenas a memória RLC k direciona os dados para a memória MAC k com um nível de prioridade designado por m. A memória MAC k produz os dados que serão distribuídos para as duas SDUs MAC. As memórias RLC ve« são novamente designadas, respectivamente para as portadoras de rádio RBy e RBu, que são ambas usadas para o equipamento do usuário UEz. Ambas, a memória RLC v e a memória RLC u, direcionam os dados recebidos com o mesmo nível r de prioridade para a memória MAC uv. A memória MAC uv produz os dados que serão distribuídos para as quatro SDUs MAC.
No modelo de armazenagem de acordo com a Figura 13, o valor do campo “NumOfBuff” define o número da memória de nível MAC 11, do qual os dados são providos para o quadro de dados HSDPA FP correspondente. Assim, no exemplo apresentado, o valor do campo “NumOfBuff” do quadro de dados baseado na estrutura de quadro da Figura 10 é estabelecido para 3, uma vez que os dados são extraídos das três memórias MAC, isto é, as memórias MAC z, k, e vu. O valor do campo “NumOfSDUs” para a memória MAC z é estabelecido para 1, uma vez que apenas os dados para uma SDU MAC foram extraídos desta memória para o quadro atual. Para a memória MAC k, o valor do campo “NumOfSDUs” é fixado em 2, uma vez que os dados para as duas SDUs MAC foram extraídos desta memória para o quadro atual. Para a memória MAC uv, o valor do campo “NumOfSDUs” é fixado em 4, uma vez que os dados para as quatro SDUs MAC foram extraídos desta memória para o quadro atual.
Os valores dos campos “SizeOfSDUs” e “Tamanho da Memória do Usuário” é fixado para os valores respectivamente aplicáveis. O valor do campo “UE-id” para a memória MAC z é fixado em λ:, uma vez que os dados nesta memória são significados para UEx. O valor do campo “UE-id” para a memória MAC k é fixado em y, uma vez que os dados nesta memória é significado para UEy. O valor do campo “UE-id” para a memória MAC uv é fixado em z, uma vez que os dados nesta memória são significados para UEz. O valor do campo “CMCH-PI” para a memória MAC z é fixado em p, uma vez que o nível de prioridade para os dados fornecidos para esta memória é estabelecido em p. O valor do campo “CMCH-PI” para a memória MAC k é fixado em m, uma vez que o nível de prioridade para os dados fornecidos para esta memória é fixado em m. O valor do campo “CMCH-PI” para a memória MAC uv é fixado em r, uma vez que o nível de prioridade para os dados fornecidos para esta memória é fixado em r.
No exemplo da Figura 13, as várias RBs designadas para o mesmo UE podem usar a memória MAC comum 11, por exemplo, se elas tiverem um valor de prioridade comum. Também seria possível usar a memória MAC comum 11 para todas as RBs que tem um valor de prioridade comum para a informação do UE transmitida, indiferente do UE para o qual as RBs são designadas. Isto tornaria o controle de fluxo muito mais complexo.
No todo, diferentes estruturas de quadro HSDPA FP de acordo com o primeiro aspecto da invenção foram apresentadas, as quais podem ser empregadas vantajosamente para diferentes situações, para transmitir os dados do usuário relacionados ao HSDPA junto com a informação adicional requerida do RNC para o Nó B da UTRAN. As estruturas de quadro podem ser modificadas de qualquer modo adequado, para prover uma ótima adaptação aos requerimentos específicos.
Agora, uma incorporação do segundo aspecto da invenção será apresentada para uma UTRAN apta ao HSDPA que inclui um RNC e um Nó B interconectados por uma interface Iub. Nesta incorporação, o protocolo de aplicação Iub é fornecido, o qual define vários IEs que podem ser adicionados pelo RNC às mensagens de controle selecionadas transmitidas pela interface Iub ao Nó B, para permitir ao Nó B configurar o HSDPA. A Figura 14 apresenta uma tabela com um novo grupo de IEs semi-estáticos “Informação HS DSCH” compreendendo uma célula relacionada aos parâmetros com a informação relacionada ao HS-DSCH que pode ser usada pelo Nó B para configurar o HSDPA em uma célula e as características do HARQ implementado. A tabela tem o formato de tabelas usado pelo 3GPP para definir os IEs, por exemplo, na especificação técnica TS 25.433 acima citada. Estas tabelas incluem uma respectiva coluna para o IE/Nome do Grupo/, as exigências na presença do IE, uma gama, um tipo IE e uma referência, uma descrição semântica, uma análise crítica, e uma análise crítica designada. Na Figura 14 apenas a coluna “IE/Nome do Grupo” é usada. As outras colunas podem ser completadas de acordo com as respectivas exigências. O primeiro IE no grupo da tabela da Figura 14 é denominado de “Grupo MCS”. Este compreende os grupos do esquema de codificação e de modulação (MCS -Modulation and Coding Schemes), do qual o Nó B pode escolher cada TTI para as transmissões. O segundo IE neste grupo é chamado de “Nível de Potência HS_DSCH”. Este IE define a relação entre o nível de potência de código do HS-DSCH e do CPICH (Common Pilot Channel/Canal Piloto Comum) no caso do NQAM (N-symbol Quadrature Amplitude Modulation/Modulação de Amplitude em Quadratura de N-símbolo). O terceiro IE neste grupo é denominado de “NumOfCodes” que define o número de canais de código que serão designados ao HS-DSCHs. O RNC pode designar o número de canais de código para uma célula para habilitar a configuração das características do HS-DSCH. O quarto IE neste grupo é denominado de “Seleção TTI”. A “Seleção TTI” inclui a informação sobre o comprimento do TTI que o Nó B usará.
Também, na tabela é incluído “Informação HARQ” que é um grupo de IE que poderia incluir vários HARQ IEs específicos, cujos IEs dependem da implementação do HARQ selecionado. O grupo “Informação HARQ” define a informação para configurar HARQ no Nó B. Os parâmetros deste grupo permitem ao RNC restringir a capacidade do Nó B. Na Figura 14, o grupo IE “Informação HARQ” inclui os IEs “NumOfChannel”, “MaxAttempt” e “RedudancyVer”. No caso de um n-canal SAW-HARQ ser usado, o IE “NumOfChannel” pode ser incluído para permitir ao RNC configurar o número de canais. Assumindo também que o Nó B pode rejeitar o pedido de retransmissão UE após uma quantidade certa de tentativas, a inclusão do IE “MaxAttempt” permite ao RNC proporcionar ao Nó B um número máximo de tentativas, e o Nó B pode então decidir rejeitar ou não rejeitar o pedido sob esta limitação de acordo com as suas próprias condições. Finalmente, no caso de um método de redundância incrementai ser usado, ao invés de um método de combinação soft/chaise, o IE “RedundancyVer” pode definir a restrição das versões de redundância, a qual o Nó B pode escolher.
Especialmente o IE “NumOfCodes” e o IEs que pertencem ao grupo IE “Informação HARQ” são fornecidos limites para o Nó B, cujo Nó B pode selecionar o próprio valor dinamicamente de dentro do grupo fixo. Também seria possível classificar estes parâmetros alternativamente como um valor fixo e/ou como valores específicos RL.
Os IEs descritos específicos da célula podem ser adicionados ao procedimento ESTABELECER CÉLULA e ao procedimento RECONFIGURAR CÉLULA e serem incluídos pelo RNC no HSDPA relacionado às mensagens PEDIDO DE ESTABELECIMENTO DA CÉLULA e as mensagens PEDIDO DE RECONFIGURAÇÃO transmitidas pelo RNC ao Nó B.
As Figuras 15 a 17 apresentam cada qual uma tabela com um grupo de IEs que inclui os parâmetros relacionados ao RL, que podem ser usados pelo Nó B para o estabelecimento e a re-configuração dos canais HS-DSCH. Os IEs podem ser adicionados no procedimento ESTABELECER ENLACE DE RÁDIO e no procedimento PREPARAÇÃO DE RECONFIGURAÇÃO DO ENLACE DE RÁDIO SINCRONIZADO. As tabelas têm o mesmo formato da Tabela da Figura 14. A Tabela da Figura 15 apenas contém um IE “HSDSCH ID”. Este IE identifica exclusivamente o HS-DSCH dentro do Contexto de Comunicação do Nó B. A Tabela da Figura 16 inclui os IEs “Resposta de Informação HS DSCH” que provê a informação para os HS-DSCHs que foram estabelecidos ou modificados. A gama de entradas para cada IE é de 1 ao número máximo de HS-DSCHS para um UE. O primeiro IE neste gmpo é novamente o IE “HS DSCH ID” já mencionado que deveria ser obrigatoriamente incluído. O segundo IE neste grupo é denominado de “ID de Enlace”, e pode ser opcionalmente incluído. A “ID de Enlace” é um identificador do fluxo de dados do usuário. Este é alocado ao Nó B e é único para cada portadora de transporte sob estabelecimento para ou do Nó B. O significado é então igual como para o DSCH. O terceiro IE neste grupo é denominado de “Endereço da Camada de Transporte” e também pode ser opcionalmente incluído. Este IE define o endereço de transporte do Nó B. O significado é então igual ao do DSCH.
Os IEs da Tabela da Figura 16 podem ser incluídos nas mensagens RESPOSTA DE ESTABELECIMENTO DE RÁDIO e nas mensagens RECONFIGURAÇÃO PRONTA DO ENLACE DE RÁDIO. A Tabela da Figura 17 inclui os IEs “Informação HS_DSCH FDD”que proveem a informação para o HS-DSCHs que será estabelecido. A gama de entradas para cada IE é novamente de 1 para um número máximo HS-DSCHS para o UE. O primeiro IE neste grupo é novamente o IE acima mencionado “HSDSCH ID”. O segundo IE neste grupo é denominado de “UE_ID” e é empregado para permitir ao Nó B distinguir entre UEs diferentes. Este IE será usado para preencher o cabeçalho MAC. Este pode ser o RNTI ou qualquer outra coisa, por exemplo, um novo tipo de indicação da identidade do equipamento do usuário que poderia ser transparente para o UE. O terceiro IE neste grupo é denominado de “Grupo do Formato de Transporte”. O “Grupo do Formato de Transporte” é definido como um grupo de formatos de transporte associado ao Canal de Transporte, por exemplo, HS-DSCH. O quarto IE neste grupo é denominado de “Prioridade de Alocação/Retenção”. Este parâmetro indica o nível de prioridade na alocação e na retenção dos recursos internos do Nó B. O significado é então igual ao do DSCH. O quinto IE deste grupo é denominado de “Prioridade de Controle de Quadro”. Este parâmetro indica o nível de prioridade a ser usado durante a vida-útil do HS-DSCH para as restrições temporárias dos recursos alocados devido à razão de sobrecarga. O significado é então o mesmo do DSCH. O sexto IE deste grupo é denominado de “ToAWE”. O parâmetro “ToAWE” é o tempo de chegada do ponto-final da janela. Os quadros de dados de enlace descendentes são esperados para serem recebidos antes deste ponto-final da janela. O significado é então igual ao do DSCH. O sétimo IE deste grupo é denominado de “ToAWS”. O parâmetro “ToAWS” é o tempo de chegada do ponto-inicial da janela. Os quadros de dados de enlace descendentes são esperados para serem recebidos após este ponto-inicial da janela. O significado é então igual ao do DSCH. O oitavo IE deste grupo é denominado de “NumOfCodes” e já foi mencionado como possível parâmetro baseado na célula. O RNC poderia selecionar o valor paras este parâmetro de acordo com a respectiva capacidade do UE. O nono IE deste grupo é denominado de “BufferStatus” e indica o status atual da memória RNC. Este parâmetro pode ser usado no começo da conexão para o controle de fluxo. É também incluído no grupo “Capacidade HARQ” que é um grupo de IE que pode incluir vários IEs específicos HARQ idênticos a estes do grupo “Informação HARQ” na tabela da Figura 14. Mas embora os nomes dos IEs sejam idênticos no caso específico-célula e específico-RL, os significados são ligeiramente diferentes, uma vez que no caso específico-célula a “Informação HARQ” restringe a capacidade da célula, enquanto no caso específico-RL a “Capacidade HARQ” reflete o QoS (Qualidade de Serviço) do enlace de rádio ou a capacidade do UE. O IEs desta tabela podem ser incluídos nas mensagens PEDIDO DE ESTABELECIMENTO DE ENLACE DE RÁDIO e nas mensagens PREPARAR RECONFIGURAÇÃO DE ENLACE DE RÁDIO.
Um outro grupo específico HSDPA de IEs é definido para a Informação HS-DSCH que será modificada. Este grupo inclui um sub-grupo do grupo “informação HS-DSCH FDD”. Mais especificamente, este inclui o IEs “HS-DSCH ID”, “Grupo do Formato de Transporte”, “Prioridade de Alocação/Retenção”, “Prioridade de Controle de Quadro”, “ToAWS”, “ToAWE”, e “NumOfCodes”, e possivelmente os IEs do grupo “Capacidade HARQ”. Os IEs deste grupo também podem ser incluídos nas mensagens PREPARAR RECONFIGURAÇÃO DE ENLACE DE RÁDIO.
Muitos dos RL relacionados aos IEs têm um significado correspondente ao do DSCH relacionado aos IEs apresentados, por exemplo, na especificação técnica TS 25.433 citada acima, que é aqui incorporada através de referência e a qual refere a outros detalhes. Não é conhecido para o DSCH o grupo IE “Capacidade HARQ”, que denota as características HARQ de um RL, e que poderia também refletir as capacidades UE e/ou QoS do RL.
Além disso, o IE “UE ID” foi adicionado como um novo parâmetro para ajudar a completar o cabeçalho MAC no Nó B. Se nenhuma ID for incluída ou necessária no cabeçalho MAC, este parâmetro pode ser usado alternativamente na camada FP para o mesmo propósito. O IE “Grupo do Formato de Transporte” é bem parecido ao IE correspondente do DSCH, mas para alguns IEs serão definidos novos valores para suportar o HS-DSCH. Este é indicado na Figura 18, que apresenta uma tabela para o grupo do formato de transporte DSCH extraída da especificação TS 25.433 citada acima com algumas modificações sublinhadas.
Mais especificamente, alguns valores mais possíveis são adicionados ao IE “Intervalo do Tempo de Transmissão”, isto é “lslot”, “3slot”, “5slot” e “15slot”. Estes valores serão usados para o HS-DSCH apenas e nenhum outro valor é para ser aplicável ao HS-DSCH. Em adição, o valor “Convolucional” não deveria ser usado no IE “Tipo de codificação de canal” para o HSDPA.
Assim, na incorporação apresentada do segundo aspecto da invenção, os IEs básicos são definidos, os quais podem ser fornecidos durante o estabelecimento e a re-configuração da célula e o estabelecimento e a re-configuração do RL para suportar o HSDPA. Os grupos descritos dos IEs e os próprios IEs podem ser modificados de qualquer modo adequado para ser adaptado às exigências específicas. Igualmente, outros grupos dos IEs podem ser definidos no protocolo de aplicação Iub para habilitar qualquer transferência requerida da informação de controle relacionada ao HSDPA.