BR112016001410B1 - Estação base mestre configurada para encaminhar pacotes de dados destinados a uma estação móvel, estação de base secundária configurada para encaminhar pacotes de dados recebidos de uma estação base mestre e destinados a uma estação móvel para a estação móvel, método implementado em uma estação base mestre para encaminhar pacotes de dados destinados a uma estação móvel, e método implementado em uma estação base secundária para encaminhar pacotes de dados recebidos de uma estação base mestre e destinados a uma estação móvel para uma estação móvel - Google Patents

Abstract

MÉTODO PARA DESCARTAR PACOTES DE DADOS DESTINADOS PARA UMA ESTAÇÃO MÓVEL, ESTAÇÃO BASE MESTRE PARA EN CAMINHAR PACOTES DE DADOS DESTINADOS PARA UMA ESTAÇÃO MÓVEL, E ESTAÇÃO BASE SECUNDÁRIA PARA ENCAMINHAR PACOTES DE DADOS A UMA ESTAÇÃO MÓVEL. A invenção se refere a um método para descartar eficientemente os pacotes de dados destinados a uma estação móvel conectada tanto a uma estação base mestre quanto a uma estação base secundária. A estação base mestre configura uma função secundária de descarte em uma camada inferior da estação base secundária, com base na função mestre de descarte na camada mais alta da estação base mestre . A estação base mestre encaminha o pacote de dados da camada mais alta à parte inferior da estação base secundária. A função secundária de descarte da camada inferior na estação base secundária descarta o pacote de dados recebido na expiração do temporizador secundário iniciado pela camada inferior no recebimento do pacote de dados da camada mais alta na estação base mestre.

Description

CAMPO DA PRESENTE REVELAÇÃO

[001] A presente revelação se refere a métodos para descartar pacotes de dados para uma estação móvel conectada à duas estações base ao mesmo tempo. A presente revelação também está provendo as estações base para realizar os métodos aqui descritos.

HISTÓRICO DA INVENÇÃO EVOLUÇÃO DE LONGO PRAZO (LTE, LONG TERM EVOLUTION)

[002] Os sistemas móveis de terceira geração (3G) com base na tecnologia de acesso por rádio WCDMA estão sendo implementados em larga escala no mundo todo. Um primeiro passo para melhorar ou evoluir essa tecnologia implica na introdução do HighSpeed Downlink Packet Access (HSDPA) e em um uplink melhorado, também referido como High Speed Uplink Packet Access (HSUPA), fornecendo uma tecnologia de acesso de rádio que é altamente competitiva.

[003] Para estar preparado para futuras demandas crescentes de usuários e ser competitivo em relação a novas tecnologias de acesso de rádio, o 3GPP introduziu um novo sistema de comunicação móvel que é chamado de Evolução de Longo Prazo (LTE, Long Term Evolution). A LTE é projetada para atender as necessidades da transportadora de dados em alta velocidade e transporte de mídia, assim como suporte de voz de alta capacidade para a próxima década. A habilidade de prover taxas altas de bit é uma medida chave para a LTE.

[004] A especificação do item de trabalho (Wl) na Evolução de Longo Prazo (LTE, Long Term Evolution) chamada de Evolved UMTS Terrestrial Radio Access (UTRA) e UMTS Terrestrial Radio Access Network (UTRAN) é finalizada como Versão 8 (LTE Rel. 8). O sistema LTE representa um acesso por rádio com base nos pacotes e redes de acesso de rádio que proveem funcionalidades completas com base no IP com baixa latência e baixo custo. Na LTE, larguras de banda de transmissão escalável múltiplas são especificadas tais como 1 .4, 3.0, 5.0, 10.0, 15.0, e 20.0 MHz, para conseguir a implementação de um sistema flexível usando um dado espectro. No downlink, o acesso por rádio com base na Multiplexação por Divisão de Frequências Ortogonais (OFDM, Orthogonal Frequency Division Multiplexing) foi adotado por conta de sua imunidade inerente à interferência multicaminhos (MPI) devido a uma baixa taxa de símbolos, o uso de um prefixo cíclico (CP) e sua afinidade a diferentes disposições de largura de banda de transmissão. O acesso por rádio com base no acesso múltiplo de divisão de frequências de uma só transportadora (SC-FDMA, Single-carrier frequency division multiple access) foi adotado no uplink, já que o provisionamento de cobertura de uma ampla área foi priorizado em relação à melhoria na taxa de dados de pico, considerando a energia de transmissão restrita do equipamento do usuário (UE, user equipment). Muitas técnicas de acesso por rádio do pacote chave são empregadas, incluindo técnicas de transmissão de canal de múltiplas saídas, múltiplas entradas (MIMO) e uma estrutura de sinalização de controle altamente eficiente é conseguida em LTE Rel. 8/9.

ARQUITETURA LTE

[005] A arquitetura geral é mostrada na figura 1 e uma representação mais detalhada da arquitetura E-UTRAN é dada na figura 2. A E-UTRAN consiste de um eNodeB, provendo o encerramento de protocolo de plano de controle (RRC) e plano de usuário (PDCP/RLC/MAC/PHY) E-UTRA na direção do equipamento do usuário (UE). O eNodeB (eNB) hospeda as camadas Física (PHY, Physical), Controle de Acesso Médio (MAC, Medium Access Control), Controle de Link de Rádio (RLC, Radio Link Control) e Protocolo de Controle de Dados de Pacote (PDCP, Packet Data Control Protocol) que incluem a funcionalidade de compressão e criptografia do cabeçalho de plano do usuário. Ela também oferece a funcionalidade de Controle de Recursos de Rádio (RRC, Radio Resource Control) correspondente ao plano de controle. Ela realiza muitas funções, incluindo o gerenciamento de recursos de rádio, controle de admissão, agendamento, execução de Qualidade de Serviço (QoS, Quality of Service) de uplink negociada, transmissão de informações celulares, cifragem/decifragem de dados do usuário e plano de controle e compressão/descompressão dos cabeçalhos do pacote do plano do usuário de downlink/uplink. Os eNodeBs estão interconectados uns com os outros por meio de uma interface X2.

[006] Os eNodeBs também estão conectados por meio de uma interface S1 ao EPC (Evolved Packet Core, Núcleo de Pacote Melhorado), mais especificamente a MME (Mobility Management Entity, Entidade de Gerenciamento de Mobilidade) pode meio de S1 -MME e ao Serving Gateway (SGW) por meio de S1 -U. A interface S1 suporta uma relação de muitos para muitos entre MMEs/Serving Gateways e eNodeBs. O SGW direciona o caminho e encaminha os pacotes de dados do usuário, enquanto também age como âncora de mobilidade para o plano de usuário durante transferências inter-eNodeB e como âncora para a mobilidade entre LTE e outras tecnologias 3GPP (encerrando a interface S4 e retransmitindo o tráfego entre os sistemas 2G/3G e PDN GW). Para equipamentos de usuário em estado ocioso, o SGW encerra o caminho de dados de downlink aciona o paginamento quando os dados de downlink chegarem para o equipamento do usuário. Ele gerencia e armazena contextos de equipamento do usuário, por exemplo, parâmetros do serviço da transportadora do IP, informações de roteamento interno de rede. Ele também realiza a replicação do tráfego do usuário em caso de interceptação legítima.

[007] O MME é o nó de controle chave para a rede de acesso LTE. Ele é responsável pelo rastreamento do equipamento do usuário em modo ocioso e pelo procedimento de paginação, incluindo retransmissões. Ele está envolvido no processo de ativação/desativação da transportadora e também é responsável por selecionar o SGW para um equipamento do usuário no anexo inicial e no momento da transferência intra- LTE envolvendo a relocação do nó da Rede do Núcleo (CN, Core Network). Ele é responsável por autenticar o usuário (pela interação com o HSS). A sinalização da Camada sem Acesso (NAS, Non-Access Stratum) encerra no MME e também é responsável pela geração e alocação de identidades temporárias aos equipamentos do usuário. Ele verifica a autorização do equipamento do usuário para estacionar a chamada na Rede Móvel Terrestre Pública (PLMN, Public Land Mobile Network) do provedor de serviços e executa as restrições de roaming do equipamento. O MME é o ponto de encerramento na rede para proteção de cifragem/integridade para sinalização NAS e trabalha o gerenciamento da chave de segurança. A interceptação legítima da sinalização também é suportada pela MME. A MME também provê a função de plano de controle para mobilidade entre as redes de acesso LTE e 2G/3G com a interface S3 encerrando em MME a partir de SGSN. O MME também encerra a interface S6a em direção ao HSS inicial para roaming dos equipamentos do usuário.

[008] Estrutura do Transportador de Componentes no LTE (Versão 8)

[009] O transportador de componente de downlink de um sistema 3GPP LTE é subdividido no domínio de tempo- frequência nos chamados subframes. No 3GPP LTE cada subframe é dividido em dois slots de downlink como mostrado na figura 3, em que o primeiro slot de downlink compreende a região de canal de controle (região PDCCH) dentro dos primeiros símbolos OFDM. Cada subframe consiste de um dado número de símbolos OFDM no domínio de tempo (12 ou 14 símbolos OFDM no 3GPP LTE (Versão 8)), em que cada símbolo OFDM abrange toda a largura de banda do transportador de componente. Os símbolos OFDM, portanto, cada um consiste de um número de símbolos de modulação transmitidos nas respectivas subtransportadoras NRB X NS™ como também mostrado na figura 4.

[010] Considerando um sistema de comunicação multi-transportador, por exemplo, empregando OFDM, como por exemplo utilizado na Evolução de Longo Prazo (LTE, Long Term Evolution) 3GPP, a menor unidade de recursos que possa ser atribuída pelo agendador é um “bloco de recurso”. Um bloco de recurso físico (PRB) é definido como símbolos OFDM consecutivos RB no domínio de tempo (por exemplo, 7 símbolos OFDM) e subtransportadores consecutivos Nsc no domínio de frequência como exemplificado na figura 4 (por exemplo, 12 subtransportadores para um transportador de componente). Na 3GPP LTE (Versão 8), um bloco de recursos físicos, portanto, consiste de N*nb x N™ elementos de recurso, correspondendo a um slot no domínio de tempo e 180 kHz no domínio de frequência (para mais detalhes sobre a grade de recursos de downlink, veja, por exemplo, 3GPP TS 36.21 1 , “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels e Modulation (Release 8) (Acesso Melhorado por Rádio Terrestre Universal (E-UTRA); Canais Físicos e Modulação (Versão 8))”, seção 6.2, disponível em http://www.3gpp.org e aqui incorporados por referência).

[011] Um subframe consiste de dois slots, tal que haja 14 símbolos OFDM em um subframe quando um dito CP “normal” (prefixo cíclico) for utilizado, e 12 símbolos OFDM em um subframe quando um dito CP “estendido” for utilizado. Para fins de terminologia, nos seguintes recursos RB de frequência de tempo equivalentes aos mesmos subtransportadores consecutivos Nsc abranger um subframe completo é chamado um “par de bloco de recursos”, ou “par RB” ou “par PRB” equivalente.

[012] O termo “transportador de componente” refere-se a uma combinação de vários blocos de recurso no domínio de frequência. Em versões futuras da LTE, o termo “transportador de componente” não é mais utilizado; ao invés disso, a terminologia é alterada para “célula”, que se refere a uma combinação de downlink e opcionalmente recursos de uplink. A vinculação entre a frequência da transportadora dos recursos de downlink e a frequência da transportadora dos recursos de uplink está indicada nas informações do sistema transmitidas nos recursos de downlink.

[013] Suposições similares para a estrutura do transportador de componente se aplicam também a versões posteriores.

[014] Agregação do transportador na LTE-A para suporte de uma largura de banda mais ampla.

[015] O espectro de frequência para o IMT- Advanced foi decidido na Conferência Mundial de Comunicação de Rádio 2007 (WRC-07). Ainda que o espectro de frequência geral para IMT-Advanced tenha sido decidido, a largura de banda da frequência real disponível é diferente de acordo com cada região ou país. Seguindo a decisão do perfil do espectro de frequência disponível, entretanto, a padronização de uma interface de rádio iniciada no Projeto de Parceria de 3a Geração (3GPP, 3rd Generation Partnership Project). Na 39a reunião do 3GPP TSG RAN, a descrição do item de estudo em “Further Advancements for E-UTRA (LTE) (Melhorias Avançadas para o E-UTRA (LTE))” foi aprovada. O item de estudo cobre componentes de tecnologia a serem considerados para a evolução do E-UTRA, por exemplo, para preencher os requisitos do IMT-Advanced.

[016] A largura de banda que o sistema LTE- Advanced é capaz de suportar é de 100 MHz, enquanto um sistema LTE pode suportar apenas 20 MHz. Hoje em dia, a falta de espectro do rádio tornou-se um gargalo do desenvolvimento de redes sem fio e, como resultado, é difícil encontrar uma banda de espectro que seja ampla o suficiente para o sistema LTE-Advanced. Consequentemente, é urgente encontrar uma maneira de ganhar uma banda de espectro de rádio mais ampla, na qual uma resposta possível seja a funcionalidade de agregação do transportador.

[017] Na agregação do transportador, dois ou mais transportadores de componentes (transportadores de componentes) são agregados para suportar larguras de banda de transmissão mais amplas até 100MHz. Várias células no sistema LTE são agregadas em um canal mais amplo no sistema LTE- Advanced que é amplo o suficiente para 100 MHz ainda que essas células estejam em frequências de bandas diferentes.

[018] Todos os transportadores de componentes podem ser configurados para ser compatíveis com a versão 8/9 LTE, ao menos quando os números agregados dos transportadores de componentes no uplink e downlink forem os mesmos. Nem todos os transportadores de componentes agregados por um equipamento do usuário podem ser necessariamente compatíveis com a versão 8/9. Mecanismos existentes (por exemplo, barramento) podem ser utilizados para evitar equipamentos do usuário versão 8/9 estacionarem a chamada em um transportador de componente.

[019] Um equipamento do usuário pode receber simultaneamente ou transmitir um ou múltiplos transportadores de componentes (correspondendo às células de serviço múltiplas) dependendo de suas capacidades. Um equipamento do usuário LTE-A versão 10 com capacidades de recepção e/ou transmissão para agregação do transportador pode simultaneamente receber e/ou transmitir múltiplas células de serviço, enquanto um equipamento do usuário LTE versão 8/9 pode receber e transmitir em uma única célula de desde que a estrutura do transportador de componente siga as especificações da versão 8/9.

[020] A agregação do transportador é suportado por ambos, transportadores de componentes contíguos e não contíguos, com cada transportador de componente limitado a um máximo de 1 10 Blocos de Recurso no domínio de frequência usando a numerologia 3GPP LTE (Versão 8/9).

[021] É possível configurar um equipamento do usuário compatível com 3GPP LTE-A (Versão 10) para agregar um número de transportadores de componentes originando do mesmo eNodeB (estação base) e de, possivelmente, larguras de banda diferentes no uplink e downlink. O número de transportadores de componentes de downlink que podem ser configurados depende da capacidade de agregação de downlink do UE. Por outro lado, o número de transportadores de componentes de uplink que podem ser configurados depende da capacidade de agregação de uplink do UE. Pode não ser possível configurar um terminal móvel com mais transportadores de componentes de uplink do que transportadores de componentes de downlink.

[022] Em uma implantação TDD típica, o número de transportadores de componentes e a largura de banda de cada transportador de componente no uplink e downlink é a mesma. Transportadores componentes originários do mesmo eNodeB não precisam prover a mesma cobertura.

[023] O espaçamento entre frequências de centro de transportadores de componentes agregados contiguamente deve ser um múltiplo de 300 kHz. Isso é para ser compatível com um raster de frequência 100 kHz de 3GPP LTE (Versão 8/9) e ao mesmo tempo preserva a ortogonalidade dos subtransportadores com espaçamento 15 kHz. Dependendo do cenário de agregação, o espaçamento n x 300 kHz pode ser facilitado inserindo um número baixo de subtransportadores não utilizados entre transportadores de componentes contíguos.

[024] A natureza da agregação de transportadores múltiplos é apenas exposta à camada MAC. Para ambos, uplink e downlink, há uma entidade HARQ requerida no MAC para cada transportador de componente agregado. Há (na ausência de SU-MIMO para o uplink) no máximo um bloco de transporte por transportador de componente. Um bloco de transporte e suas potenciais retransmissões HARQ precisam ser mapeadas no mesmo transportador de componente.

[025] A estrutura da Camada 2 com a agregação do transportador ativado está mostrada na figura 5 e figura 6 para o downlink e uplink respectivamente.

[026] Quando a agregação do transportador está configurada, o terminal móvel apenas tem uma conexão RRC com a rede. No estabelecimento/re-estabelecimento da conexão RRC, uma célula prove a entrada de segurança (um ECGI, um PCI e um ARFCN) e as informações de mobilidade da camada sem acesso (por exemplo, TAI) similarmente a LTE versão 8/9. Após estabelecimento/re-estabelecimento da conexão RRC, o transportador de componente correspondente àquela célula é referido como Célula primária de downlink (PCell, Primary Cell). Há sempre uma e apenas uma PCell de downlink (DL PCell) e uma PCell de uplink (UL PCell) configurado por equipamento do usuário em estado conectado. Dentro do conjunto configurado de transportadores de componentes, outras células são referidas como Células Secundárias (SCells, Secondary Cells); com transportadores da SCell sendo o Transportador de Componente Secundário de Downlink (DL SCC) e Transportador de Componente Secundário de Uplink (UL SCC). As características da PCell de downlink e uplink são: 1. . Para cada SCell, o uso de recursos de uplink pelo UE, além dos de downlink é configurável; o número de DL SCCs configurados é, portanto, sempre maior ou igual ao número de UL SCCs, e nenhuma SCell pode ser configurada para uso de recursos de uplink apenas 2. A PCell de uplink é utilizada para transmissão das informações de controle de uplink da Camada 1 3. A PCell de downlink não pode ser desativada, ao contrário das SCells 4. Da perspectiva do UE, cada recurso de uplink apenas pertence a uma célula de serviço 5. O número de células de serviço que podem ser configuradas depende da capacidade de agregação do UE 6. O re-estabelecimento é acionado quando a PCell de downlink PCell passa por uma atenuação de Rayleigh (RLF), não quando as SCells de downlink passam por RLF 7. A célula PCell de downlink pode alterar com a transferência (isto é, com a alteração da chave de segurança e procedimento RACH) 8. As informações da camada sem acesso são tiradas da PCell de downlink 9. A PCell pode apenas ser alterada com o procedimento de transferência (isto é, com a alteração da chave de segurança e procedimento RACH) 10. A PCell é utilizada para transmissão do PUCCH

[027] A configuração e reconfiguração de transportadores de componentes podem ser realizadas por RRC. A ativação e desativação é feita através de elementos de controle MAC. Na transferência intra-LTE, o RRC também pode adicionar, remover ou reconfigurar as SCells para uso na célula alvo. Ao adicionar uma nova SCell, uma sinalização RRC dedicada é utilizada para enviar as informações do sistema da SCell, sendo as informações necessárias para transmissão / recepção (similarmente a versão 8/9 para transferência).

[028] Quando um equipamento do usuário está configurado com agregação do transportador há um par de transportadores de componentes de uplink e downlink que sempre está ativo. O transportador de componente de downlink desse par também pode ser referido como “transportador de âncora DL”. O mesmo se aplica também para o uplink.

[029] Quando a agregação do transportador está configurada, um equipamento do usuário pode ser agendado por múltiplos transportadores de componentes simultaneamente, mas no máximo um procedimento de acesso aleatório deve estar ocorrendo a qualquer momento. O agendamento transversal da transportadora permite ao PDCCH de um transportador de componente agendar recursos em outro transportador de componente. Para este propósito, um campo de identificação do transportador de componente é introduzido nos formatos DCI respectivos, chamado CIF.

[030] Uma vinculação entre transportadores de componentes de uplink e downlink permite identificar o transportador de componente de uplink para o qual a concessão se aplica quando não há agendamento transversal da transportadora. A vinculação de transportadores de componentes de downlink ao transportador de componente de uplink não precisa necessariamente ser de uma para uma. Em outras palavras, mais de um transportador de componente de downlink pode se vincular ao mesmo transportador de componente de uplink. Ao mesmo tempo, um transportador de componente de downlink pode apenas se vincular a um transportador de componente de uplink.

VISÃO GERAL DA CAMADA OSI

[031] A figura 7 provê uma breve visão geral do modelo OSI no qual a discussão posterior da arquitetura LTE é baseada e, também, com base no qual a invenção será aqui discutida.

[032] O Modelo de Referência de Interconexão de Sistemas Abertos (Open Systems Interconnection Reference Model) (Modelo OSI ou Modelo de Referência OSI) é uma descrição abstrata em camadas para o desenho do protocolo de redes de computador e comunicação. O modelo OSI divide as funções de um sistema em uma série de camadas. Cada camada tem a propriedade que apenas usa as funções da camada abaixo e apenas exporta a funcionalidade para a camada acima. Um sistema que implementa o comportamento do protocolo consistindo de uma série dessas camadas é conhecido como uma “pilha de protocolos” ou “pilha”. Sua principal função está na junção entre camadas, que dita as especificações sobre como uma camada interage com outra. Isso significa que uma camada escrita por um fabricante pode operar com uma camada de outro. Para nosso propósito, apenas as primeiras três camadas serão descritas em mais detalhes abaixo...

[033] A função principal da camada física ou camada 1 é a transferência de informações (bits) por um meio físico específico (por exemplo, cabos coaxiais, de par trançado, fibra óptica, interface aérea, etc.). Ela converte ou modulas dados em sinais (ou símbolos) que são transmitidos por um canal de comunicação.

[034] O propósito da camada de link de dados (ou camada 2) é moldar o fluxo da informação de uma maneira compatível com a camada física específica quebrando os dados de entrada em frames de dados (funções de Segmentação e Recomposição (Segmentation And Re-assembly)SAR)). Além do mais, ela pode detectar e corrigi possíveis erros de transmissão solicitando uma retransmissão de um frame perdido. Ela tipicamente provê um mecanismo de endereçamento e pode oferecer algoritmos de controle de fluxo para alinhar a taxa de dados com a capacidade do receptor. Se um meio compartilhado for utilizado concorrentemente por múltiplos transmissores e receptores, a camada de link de dados tipicamente oferece mecanismos para regular e controlar o acesso ao meio físico.

[035] Como há muitas funções oferecidas pela camada de link de dados, a camada de link de dados é frequentemente subdividida em subcamadas (por exemplo, subcamadas RLC e MAC em UMTS). Exemplos típicos de protocolos de camada 2 são PPP/HDLC, ATM, frame relay para redes de linha fixas e RLC, LLC ou MAC para sistemas sem fio. Informações mais detalhadas sobre as subcamadas PDCP, RLC e MAC da camada 2 serão fornecidas posteriormente.

[036] A camada de rede ou camada 3 provê os meios funcionais e procedurais para transferir pacotes de comprimento variável de uma origem para um destino através de uma ou mais redes enquanto mantém a qualidade do serviço solicitado pela camada de transporte. Tipicamente, os principais propósitos da camada de rede são inter alia para realizar o roteamento da rede, fragmentação da rede e funções de controle de congestão. Os principais exemplos de protocolos de camada de rede são o Protocolo de Internet, IP (Internet Protocol) ou X.25.

[037] Em relação as camadas de 4 a 7, deve-se notar que dependendo da aplicação e serviço, algumas vezes é difícil atribuir uma aplicação ou serviço para uma camada específica do modelo OSI, já que aplicações e serviços operando acima da camada 3 frequentemente implementam uma variedade de funções que devem ser atribuídas a diferentes camadas do modelo OSI. Portanto, especialmente em redes com base em TCP(UDP)/IP, as camadas de 4 e acima são algumas vezes combinadas e formam uma dita “camada de aplicação “.

SERVIÇOS POR CAMADA E TROCA DE DADOS

[038] No seguinte, os termos unidade de dados de serviço (SDU) e unidade de dados de protocolo (PDU) como aqui utilizados são definidos em conexão com a figura 8. Para descrever formalmente de uma maneira genérica a troca de pacotes entre camadas no modelo OSI, as entidades SDU e PDU foram introduzidas. Uma SDU é uma unidade de informações (bloco de informações/dados) transmitida a partir de um protocolo na camada N+1 que solicita um serviço de um protocolo localizado na camada N através de um dito ponto de acesso de serviço (SAP). Uma PDU é uma unidade de informações trocadas entre processos peer no transmissor e no receptor do mesmo protocolo localizado na mesma camada N.

[039] Uma PDU geralmente é formada por uma parte de carga útil consistindo da versão processada da(s) SDU(s) recebidas precedidas por um cabeçalho específico N da camada e opcionalmente encerrado por um trailer. Como não há conexão física direta (exceto pela camada 1) entre esses processos peer, uma PDU é encaminhada para a camada N-1 para processamento. Portanto, uma PDU de camada N é de um ponto de vista de camada N-1, uma SDU. CAMADA 2 LTE - PILHA DE PROTOCOLO DE PLANO DO USUÁRIO

[040] A pilha de protocolo de plano do usuário de camada 2 LTE é composta de três subcamadas como mostrado na figura 9, PDCP, RLC e MAC. Como explicado antes, do lado de transmissão, cada camada recebe uma SDU de uma camada mais alta para a qual a camada provê um serviço e libera uma PDU para a camada abaixo. A camada RLC recebe pacotes da camada de PDCP. Esses pacotes são chamados PDUs de PDCP de um ponto de vista PDCP e representam SDUs de RLC de um ponto de vista RLC. A camada RLC cria pacotes que são providos para a camada abaixo, isto é, a camada MAC. Os pacotes providos pelo RLC para a camada MAC são RLCs de PDU de um ponto de vista RLC e SDUs de MAC de um ponto de vista MAC.

[041] Do lado de recepção, o processo é revertido, com cada camada passando SDUs para a camada acima, onde são recebidos como PDUs.

[042] Enquanto a camada física provê essencialmente um bitpipe, protegido por codificação turbo e uma verificação de redundância cíclica (CRC), os protocolos de camada de link melhoram o serviço para as camadas superiores por confiabilidade aumentada, segurança e integridade. Além disso, a camada de link é responsável pelo acesso do meio multiusuário e agendamento. Um dos principais desafios para o desenho da camada de link LTE é prover os níveis de confiabilidade requeridos e atrasos para os fluxos de dados do Protocolo de Internet (IP) com sua ampla faixa de serviços diferentes e taxas de dados. Em particular, o protocolo geral deve escalar. Por exemplo, é amplamente assumido que fluxos de voz sobre IP (VoIP) podem tolerar atrasos da ordem de 100 ms e perdas de pacote de até 1 por cento. Por outro lado, é bastante sabido que os downloads de arquivo TCP desempenham melhor sobre links com produtos de atraso de baixa largura de banda. Consequentemente, downloads em taxas de dados muito altas (por exemplo, 100 Mb/s) requerem atrasos ainda mais baixos e, além disso, são mais sensíveis a perdas de pacote de IP do que o tráfego VoIP.

[043] Em geral, isso é conseguido pelas três subcamadas da camada de link LTE que está parcialmente interligada.

[044] A subcamada de Protocolo de Convergência de Dados de Pacote (PDCP)(Packet Data Convergence Protocol) é responsável principalmente pela compressão do cabeçalho IP e cifragem. Além disso, ela suporta mobilidade sem perda em caso de transferências inter-eNB e provê proteção de integridade para protocolos de controle de camadas mais alta.

[045] A subcamada de controle de link de rádio(RLC)(radio link control) compreende principalmente a funcionalidade ARQ e suporta segmentação e concatenação de dados. As últimas duas minimizam a suspensão de protocolo, independente da taxa de dados.

[046] Finalmente, a subcamada de controle do acesso médio (MAC) provê HARQ e é responsável pela funcionalidade que é requerida para acesso médio, tal como a operação de agendamento e acesso aleatório. A figura 10 exemplarmente descreve os fluxos de dados de um pacote de IP através dos protocolos de camada de link até a camada física. A figura mostra que cada subcamada de protocolo adiciona seu próprio cabeçalho de protocolo às unidades de dados.

PROTOCOLO DE CONVERGÊNCIA DE DADOS DO PACOTE (PDCP)

[047] Uma camada de PDCP processa mensagens de Controle de Recursos de Rádio (RRC) no plano de controle e pacotes IP no plano de usuário. Dependendo da portadora de rádio, as funções principais da camada de PDCP são: - compressão e descompressão do cabeçalho para dados do plano do usuário FUNÇÕES DE SEGURANÇA: o Cifragem e decifragem para plano do usuário e dados do plano de controle o Proteção de integridade e verificação para dados do plano de controle FUNÇÕES DE SUPORTE À TRANSFERÊNCIA: o Entrega em sequência e reordenamento de PDUs para a camada acima na transferência; o Transferência sem perda para dados do plano de usuário mapeados no Modo Reconhecido RLC (AM) (Acknowledged Mode)

[048] Descarte para dados do plano do usuário devido a tempo esgotado.

[049] A camada de PDCP gerencia fluxos de dados no plano do usuário, assim como no plano de controle, apenas para as portadoras de rádio usando um Canal de Controle Dedicado (DCCH)(Dedicated Control Channel) ou um Canal de Transporte Dedicado (DTCH)(Dedicated Transport Channel). A arquitetura da camada de PDCP difere para os dados do plano do usuário e dados do plano de controle, como mostrado na figura 11 e 12. Dois tipos diferentes de PDUs de PDCP são definidos em LTE: PDUs de Dados PDCP e PDUs de Controle PDCP. As PDUs de Dados PDCP são utilizadas para ambos, controle e dados do plano do usuário. As PDUs de Controle PDCP são apenas utilizadas para transportar as informações de feedback para compressão do cabeçalho e para relatórios de status do PDCP, que são utilizados no caso de transferência e, portanto, são apenas utilizados dentro do plano do usuário.

[050] Devido à baixa relevância com a invenção, as funções de Compressão do Cabeçalho, Segurança e Transferência não são explicadas em detalhes; detalhes relacionados podem ser encontrados em LTE - The UMTS Long Term Evolution FROM THEORY TO PRACTICE, Editado por: Stefania Sesia,

[051] Issam Toufik, Matther Baker, segunda edição, ISBN 978-0-470-66025-6, capítulos 4.2.2, 4.2.3 e 4.2.4 aqui incorporados por referência.

[052] Por outro lado, o descarte de pacotes de dados será explicado no seguinte em detalhes. A camada de PDCP, em geral, e o descarte na camada de PDCP em particular é definido em 3GPP TS 36.323 v1 1.2.0 (2013-03), aqui incorporado por referência.

[053] No contexto dessa invenção o termo “descarte” não deve ser entendido em seu sentido mais estrito como a exclusão do pacote imediatamente, mas deve mais amplamente cobrir o conceito de indicar o pacote (por exemplo, a PDU/SDUs de PDCP) como não senso mais necessário e, portanto, deve ser excluído. O padrão técnico deixa aberto em que ponto particular no tempo a PDU/SDUs de PDCP são realmente excluídos (ele apenas especifica quando devem ser descartados), já que o gerenciamento do buffer é majoritariamente deixado para a implementação técnica. Portanto, após um pacote ser “descartado”, pode ser que, de acordo com uma implementação técnica, o pacote seja excluído imediatamente, ou de acordo com outra implementação técnica, esse buffer seja esvaziado periodicamente pela exclusão pela exclusão desses pacotes que são indicados como descartados. Tipicamente, a taxa de dados que está disponível na interface de rádio é menor do que a taxa de dados disponível nas interfaces de rede. Portanto, quando a taxa de dados de um dado serviço é maior do que a taxa de dados provida pela interface de rádio LTE, o armazenamento em buffer no UE e no eNodeB é o resultado. Esse armazenamento em buffer concede alguma liberdade ao programador na camada MAC para variar a taxa de dados instantânea na camada física para adaptar às condições atuais do canal de rádio. Graças ao armazenamento em buffer, as variações na taxa de dados instantânea são então vistas pela aplicação apenas como flutuações no atraso de transferência.

[054] Entretanto, Quando a taxa de dados provida pela aplicação excede a taxa de dados provida pela interface de rádio por um longo período de tempo, podem resultar grandes quantidades de dados armazenados. Isso pode levar a uma grande perda de dados na transferência, se uma transferência sem perdas não for aplicada à portadora, ou a um atraso excessivo para aplicações em tempo real.

[055] Para, por exemplo, prevenir atraso excessivo, uma função de descarte está inclusa na camada de PDCP para a LTE. Essa função de descarte é com base em um temporizador, onde para cada SDU de PDCP recebido das camadas mais altas no transmissor, um temporizador (“discardTimer”) é iniciado.

[056] Também, a camada de PDCP continua a gerar a PDU de PDCP a partir da camada mais alta SDU de PDCP, e assim que gerado, encaminha a PDU de PDCP gerada para a camada inferior, RLC.

[057] O padrão TS 36.323 capítulo 5.4 descreve que, quando o temporizador expira para uma SDU de PDCP, ou a entrega bem sucedida de um SDU de PDCP é confirmada pelo relatório de status PDCP, o UE deve descartar o SDU de PDCP junto ao PDU de PDCP correspondente.

[058] O relatório de status PDCP é enviado em conexão com uma transferência da estação móvel de uma estação base para outra estação base. Ainda que não explicitamente especificado pela padronização 3GPP e, portanto, deixadas para a implementação técnica, a PDU de PDCP e a SDU também devem ser excluídas pela camada de PDCP após o PDU de PDCP ter sido encaminhado com sucesso para o UE; em particular, após a PDU de PDCP ter sido encaminhada para o RLC e entregue com sucesso para o UE pelo RLC (mais geral, e não em conexão com uma transferência; o que pode ser indicado pela camada RLC), mas antes do término do temporizador. Neste caso, o temporizador que é específico para a SDU de PDCP (e, portanto, à PDU de PDCP) deve ser abortada/excluída/parada.

[059] Entretanto, quanto o temporizador termina para uma SDU de PDCP, uma entrega bem-sucedida da SDU de PDCP para o UE ainda não pode ser conseguida. Como declarado pelo padrão TS 36.323, a camada de PDCP descarta a SDU de PDCP e PDU de PDCP e indica o descarte para PDU de PDCP particular para a camada inferior, RLC.

[060] Quando indicado a partir da camada superior (isto é, PDCP) para descartar uma SDU de RLC particular, o lado de transmissão de uma entidade RLC AM ou a entidade RLC UM de transmissão (veja capítulo posterior) deve descartar a SDU de RLC particular e nenhum segmento da SDU RLC tiver sido mapeada para uma PDU de dados RLC ainda (veja 3GPP TS 36.322 Capítulo 5.3).

[061] Uma camada de PDCP descarta os pacotes com base no “discardTimer”, que pode ser, por exemplo, definido de acordo com certos requisitos de atraso fornecidos pela QdS requerida da portadora de rádio. Por exemplo, um pacote não precisa ser transmitido no caso de que esteja muito atrasado para o serviço. Esse mecanismo de descarte pode, portanto, prevenir atraso excessivo e o enfileiramento no transmissor.

[062] A entidade PDCP peer não é informada já que a camada RLC toma conta da entrega em sequência. A entidade PDCP peer não espera por qualquer pacote PDCP que não tenha sido recebido.

[063] O mecanismo de descarte da camada de PDCP está ilustrado exemplarmente na figura 13, que é um diagrama de fluxo simplificado para o processamento de uma SDU de PDCP e o descarte correspondente da SDU de PDCP e PDU de PDCP com base no discardTimer como definido por 3GPP. Como evidente a partir da presente invenção, a exclusão de PDU/SDUs de PDCP entregue com sucesso é omitida da figura, já que isso é apenas de baixa relevância para o mecanismo de descarte, que é o foco dessa invenção.

[064] As PDUs de PDCP para dados do plano do usuário compreendem um campo “D/C” para distinguir PDUs de Controle e Dados, os formatos que são mostrados nas figuras 14 e 15 respectivamente. As PDUs de Dados PDCP compreendem um número de sequência de 7 ou 12 bits (SN) . As PDUs de Dados PDCP para dados do plano do usuário contém um pacote descomprimido (se a compressão do cabeçalho não for utilizada) ou um pacote de IP comprimido. As PDUs de Dados PDCP para dados do plano de controle (por exemplo, sinalização RRC) compreendem um campo de 32 bits de comprimento MAC-I para proteção de integridade. As PDUs de Dados PDCP para dados do plano de controle contêm uma mensagem RRC completa.

[065] PDUs de Controle de PDCP são utilizadas pelas entidades de PDCP que controlam os dados do plano do usuário. Há dois tipos de PDUs de Controle de PDCP, distinguidos pelo campo do Tipo de PDU no cabeçalho do PDCP. PDUs de Controle de PDCP carregam “Relatórios de Status” do PDCP para o caso de transferência sem perdas ou feedback de ROHC feedback criado pelo protocolo de compressão de cabeçalho ROHC. PDUs de Controle de PDCP que carregam o feedback ROHC são utilizadas para os portadores de rádio do plano do usuário mapeados em RLC UM ou RLC AM, enquanto as PDUs de controle de PDCP que carregam os Relatórios de Status do PDCP são utilizadas apenas para portadores de rádio do plano do usuário mapeados em RLC AM.

[066] Uma PDU de Controle de PDCP que carrega um Relatório de Status do PDCP para o caso de transferência sem perdas é utilizada para impedir a retransmissão das SDU de PDCP já recebidas corretamente e ainda para solicitar a retransmissão de SDUs de PDCP que foram corretamente recebidas, mas para qual descompressão de cabeçalho falhou. Essa PDU de Controle de PDCP contém um bitmap que indica quais SDUs de PDCP precisam ser retransmitidas e um SN de referência, a Primeira SDU Perdida (FMS) . No caso que todas as SDUs de PDCP foram recebidas na sequência, esse campo indica que o próximo SN esperado e nenhum bitmap é incluído.

[067] Controle de Link de Rádio (RLC)

[068] A camada de RLC está localizada entre a camada de PDCP (a camada “superior”, da perspectiva de RLC) e a camada de MAC (a camada “inferior”, da perspectiva de RLC). Essa se comunica com a camada de PDCP através de um Ponto de Acesso de Serviço (SAP) e com a camada de MAC através dos canais lógicos. A camada de RLC reformata as PDUs de PDCP (ou seja, SDUs de RLC) a fim de ajustá-las ao tamanho indicado pela camada de MAC; ou seja, o transmissor de RLC segmenta e/ou coordena as PDUs de PDCP e o receptor de RLC reúne as PDUs de RLC para reconstruir as PDUs de PDCP. Além disso, o RLC reorganiza as PDUs de RLC se elas são recebidas pela sequência devido à operação de HARQ na camada de MAC.

[069] As funções da camada de RLC são realizadas pelas “entidades de RLC”. Uma entidade de RLC é configurada em um dos três modos de transmissão de dados: Modo Transparente (TM), Modo Desconhecido (UM) e Modo Reconhecido (AM). Em AM, as funções especiais são definidas para suportar a retransmissão.

[070] As principais funções de RLC de UM podem ser resumidas como segue: segmentação e concatenação das SDUs de RLC (ou seja, PDUs de PDCP); reorganização ds PDUs de RLC; detecção duplicada das SDUs de RLC; Reconstituição de SDUs de RLC.

[071] As principais funções de RLC de AM podem ser resumidas como segue: Retransmissão de PDUs dos Dados de RLC; Ressegmentação das PDUs dos Dados de RLC retransmitidas; Relatório do Status de Pesquisa; Proibição de Status.

[072] Mais informações sobre o RLC são dadas pelo Capítulo 4.3.1 de LTE - The UMTS Long Term Evolution FROM THEORY TO PRACTICE, Editado por: Stefania Sesia, Issam Toufik, Matther Baker, Segunda Edição, ISBN 978-0-470-660256, incorporado aqui por referência.

[073] Segmentação e concatenação é uma função importante das entidades de RLC de UM e AM. A transmissão da entidade de UM/RLC de AM realiza a segmentação e/ou concatenação nas SDUs de RLC recebidas das camadas superiores, para formar as PDUs de RLC. O tamanho da PDU de RLC em cada oportunidade de transmissão é decidido e notificado pela camada de MAC dependendo das condições do canal de rádio e os recursos de transmissão disponíveis; assim, o tamanho de cada PDU de RLC transmitida pode ser diferente. A entidade de transmissão de UM/RLC de AM inclui SDUs de RLC em uma PDU de RLC na ordem na qual o y chega na entidade de UM/RLC de AM. Assim, uma única PDU de RLC pode conter SDUs de RLC ou segmentos das SDUs de RLC.

[074] Após a segmentação e/ou concatenação das SDUs de RLC, ae entidade de transmissão de UM/RLC de AM inclui cabeçalhos de RLC relevantes na PDU de RLC para indicar o número de sequência da PDU de RLC, e adicionalmente o tamanho e limite de cada SDU de RLC incluída ou segmento da SDU de RLC. Deve-se observar que o número de sequência de RLC é independente do número de sequência adicionado pelo PDCP.

[075] Conforme já mencionado acima, quando indicado da camada superior (ou seja, PDCP) para descartar uma SDU de RLC particular, o lado transmissor de uma entidade do RLC de AM ou a entidade de transmissão de RLC de UM deve descartar a SDU de RLC indicada se nenhum segmento da SDU de RLC foi mapeado em uma PDU de dados de RLC ainda (veja 3GPP TS 36.322 Capítulo 5.3). A decisão se a SDU de RLC já foi “mapeada em uma PDU de dados de RLC” pode ser referida como:

[076] - Recebido na camada de RLC, e

[077] - Informação do cabeçalho relevante adicionada (e submetida/ pronta para ser submetida à camada inferior)

PEQUENAS CÉLULAS

[078] Grandes demandas por dados móveis estão conduzindo mudanças em como os operadores móveis respondem às exigências desafiantes de capacidade mais elevada e Qualidade melhorada da Experiência do Usuário (QoE). Atualmente, os sistemas de acesso sem fio da quarta geração utilizando Evolução de Longo Prazo (LTE) estão sendo implantados por muitos operadores mundialmente a fim de oferecer acesso mais rápido com latência inferior e mais eficiência que o sistema 3G/3.5G. No entanto, o crescimento de tráfego de futuro antecipadp é assim enorme que há uma necessidade amplamente elevada pela densificação da rede para controlar as exigências de capacidade, particularmente em áreas de alto tráfego (áreas principais) que geram o volume de tráfego mais alto. A densificação da ree que aumenta o número de nós de rede, assim trazendo-os fisicamente mais perto aos terminais do usuário, é uma chave para melhorar a capacidade do tráfego e estender as taxas de ddos do usuário alcançáveis de um sistema de comunicação sem fio.

[079] Além da densificação direta de uma implantação de macro, a densificação da rede pode ser obtida pela implantação de nós de pequenas células respectivamente de nós de baixa potência complementares sob a cobertura de uma camada existente de nó de macro. Em tal implantação heterogênea, os nós de baixa potência provêm capacidade de tráfego muito alta e rendimento muito alto do usuário localmente, por exemplo, em posições principais internas e externas. Enquanto isso, a camada de macro garante a disponibilidade do serviço e a QoE sobre toda a área de cobertura. Em outras palavras, a camada contendo os nós de baixa potência podem ainda ser referidos provendo acesso de área local, ao contrário da camada de macro que cobre a área ampla.

[080] A instalação de nós de baixa potência respectivamente as pequenas células bem como as implantações heterogêneas tem sido possível desde a primeira versão de LTE. Com relação a isso, um número de soluções foi especificado nas versões recentes de LTE (ou seja, Versão- 10/11). Mais especificamente, essas versões introduziram ferramentas adicionais para controlar a interferência entre camadas em implantações heterogêneas. A fim de otimizar mais o desempenho e prover operação de energia custo eficiente, pequenas células exigem mais melhorias e, em muitos casos, precisam interagir ou complementar com as células macro existentes. Tais soluções serão investigadas durante a evolução adicional de LTE - Versão 12 e além dessa. Em particular, melhorias adicionais relacionadas aos nós de baixa potência e implantações heterogêneas serão consideradas embaixo do guarda-chuva do novo item de estudo Rel-12 (SI) “Study on Small Cell Enhancements for E-UTRA and E-UTRAN”. Algumas dessas atividades focarão em atingir um grau mais elevado de interfuncionamento e camadas de potência inferior, incluindo as diferentes formas de assistência de macro para a camada de potência inferior e conectividade de camada dupla. A conectividade dupla significa que o dispositivo tem conexões simultâneas à camada maior e às camadas de potência inferior.

[081] Alguns cenários de implementação assumidos nesse item de estudo sobre a melhoria de pequenas células serão discutidos abaixo. Nos seguintes cenários, as tecnologias de backhaul categorizadas como um backhaul não ideal em TR 36.932 são assumidas.

[082] Tanto o backhaul ideal (ou seja, rendimento muito alto e backhaul de baixa potência como conexão dedicada de ponto a ponto utilizando fibra óptica) e backhaul não ideal (ou seja, backhaul típico amplamente utilizado no mercado como xDSL, microonda e outros backhauls) devem ser estudados. A compensação desempenho-custo deve ser considerada.

[083] Uma categorização de backhaul não ideal com base nas entradas do operador é listada na tabela abaixo:

[084] O acesso por fibra que pode ser utilizado para implantar as Cabeças de Radio Remoto (RRHs) não é assumido nesse estudo. HeNBs não são excluídos, mas não distinguidos de Pico eNBs em termos de cenários de implementação e desafios embora a potência de transmissão de HeNBs seja inferior que de Pico eNBs. Os seguintes 3 cenários são considerados.

[085] Cenário #1 é ilustrado na figura 16 e é o cenário de implementação onde células pequenas e macro na mesma frequência do transportador (entre frequência) são conectadas através de um backhaul não ideal. Os usuários são distribuídos em externos e internos.

[086] Cenário #2 é ilustrado na figura 17 e 18 e se refere a um cenário de implementação onde as células pequenas e macro em diferentes frequências do transportador (entre frequência) são conectadas através de um backhaul não ideal. Os usuários são distribuídos em externos e internos. Há essencialmente dois cenários #2 diferentes, aqui referidos como 2a e 2b, a diferença sendo que no cenário 2b uma implantação de célula pequena interna é considerada.

[087] Cenário #3 é ilustrado na figura 19 e se refere a um cenário de implementação onde apenas pequenas células sobre uma ou mais frequências do transportador são conectadas através de um link de backhaul não ideal.

[088] Dependendo do cenário de implementação, diferentes desafios/problemas existem precisando ser investigados. Durante a fase de item de estudo desafios foram identificados para os cenários de implementação correspondentes e capturados em TS 36.842; mais detalhes sobre esses desafios/problemas podem ser encontrados aqui.

[089] A fim de solucionar os desafios identificados que são descritos na seção 5 de TS36.842, os seguintes objetos de desenho são considerados para esse estudo além das exigências especificadas em TR 36.932...

[090] Em termos de robustez de mobilidade:

[091] Para UEs em RRC_CONNECTED, o desempenho da mobilidade alcançado pela implantação de pequenas células deve ser comparável com o de uma rede macro apenas.

[092] Em termos de carga de sinalização elevada devido à transferência frequente: - Qualquer nova solução não deveria resultar em aumento excessivo da carga de sinalização em direção à Rede Central. Entretanto, a sinalização adicional e a carga do tráfego do plano de usuário causada pela melhoria de pequena célula deveriam ainda ser considerada.

[093] Em termos de melhoria do rendimento por usuário e capacidade do sistema: - Utilizar os recursos de rádio pelas células pequenas e macro a fim de atingir o rendimento por usuário e a capacidade do sistema similar às implantações do backhaul ideal enquanto considera as exigências de QoS se direcionadas.

CONECTIVIDADE DUPLA

[094] Uma solução promissora aos problemas que estão atualmente em discussão nos grupos de trabalho de 3GPP RAN é o conceito de “conectividade dupla”. O termo “conectividade dupla” é utilizado para se referir a uma operação onde um dado EU consome recursos de rádio providos pelo menos por dois diferentes nós de rede conectados com um backhaul não ideal. Essencialmente, o UE é conectado com uma célula macro (macro eNB) e uma pequena célula (secundária ou pequeno eNB). Além disso, cada eNB envolvido na conectividade dupla para um UE pode assumir diferentes funções. Essas funções não dependem necessariamente da classe de potência do eNB e pode variar entre os UEs.

[095] Visto que o item de estudo está atualmente em um estágio muito precoce, detalhes sobre a conectividade dupla não são descritos ainda. Por exemplo, a arquitetura não foi acordada ainda. Assim, muitas questões/detalhes, por exemplo, melhorias de protocolo, ainda estão atualmente abertos. A figura 20 mostra uma arquitetura exemplar para a conectividade dupla. Deve ser apenas entendida como uma opção potencial; a invenção não está limitada a essa arquitetura específica de rede/protocolo, mas pode ser aplicada de forma geral. As seguintes suposições sobre a arquitetura são feitas aqui: - Por divisão do nível do portador onde servir cada pacote, divisão de plano C/U o Como um exemplo, a sinalização de RRC do UE e os dados de alta QoS como VoLTE podem ser servidos pela célula macro, enquanto os dados de melhor esforço são descarregados na pequena célula. - Nenhum acoplamento entre portadores, assim nenhum PDCP ou RLC comum necessário entre a Célula macro e pequena célula - Coordenação mais leve entre os nós RAN - SeNB não tem conexão a S-GW, ou seja, pacotes são encaminhados por MeNB - Pequena célula é transparente para CN.

[096] Com referências aos dois últimos pontos, deve-se observar que é ainda possível que o SeNB seja conectado diretamente com S-GW, ou seja, S1-U está entre S-GW e SeNB. Essencialmente, há três diferentes opções w.r.t que o portador mapeia/divide: - Opção 1: S1-U ainda termina em SeNB; descrito na figura 21a - Opção 2: S1-U termina em MeNB, nenhum portador dividido em RAN; descrito na figura 21 b - Opção 3: S1-U termina em MeNB, portador dividido em RAN; descrito na figura 21c

[097] As figuras 21a-c descrevem as três opções considerando a direção do downlink para os dados do plano-U como um exemplo. Para finalidade de explicação, a opção 2 é principalmente assumida para essa aplicação e é a base para a figura 20 também.

[098] Arquitetura do plano de usuário para melhoria da pequena célula

[099] Além da discussão sobre a divisão dos dados do plano-U conforme descrito na figura 21a-c, diferentes alternativas foram discutidas para a arquitetura do plano do usuário também.

[0100] Um entendimento comum é que, quando a interface S1-U termina no MeNB, a pilha do protocolo no SeNB deve pelo menos suportar a (re) segmentação de RLC. Isso é devido ao fato que a re(segmentação) de RLC é uma operação que é firmemente acoplada à interface física (por exemplo, camada MAC indicando o tamanho da PDU de RLC, veja acima) e quando um backhaul não ideal é utilizado, a (re)segmentação de RLC deve ocorrer no mesmo nó que o que transmite as PDUs de RLC.

[0101] Com base essa suposição, quatro famílias para as alternativas de plano do usuário são distinguidas na discussão contínua. A. PDCPs independentes: essa opção termina a pilha do protocolo do plano-U da interface de ar atualmente definida completamente por portador, e é ajustada para realizar a transmissão de um portador EPS por um nó, mas poderia ainda suportar a divisão de um único portador EPS para transmissão por MeNB e SeNB com a ajuda de uma camada adicional. A transmissão de diferentes portadores pode ainda acontecer simultaneamente do MeNB e um SeNB. B. PDCPs Mestre-escravo: essa opção supõe que S1-U termina em MeNB com pelo menos parte da camada de PDCP residindo no MeNB. No caso do portador dividido, há um portador de RLC separado e independente, ainda no lado do UE, por eNB configurado para entregar PDUs de PDCP do portador de PDCP, terminado no MeNB. C. RLCs Independentes: essa opção supõe que S1-U termina em MeNB com a camada de PDCP residindo no MeNB. Em caso de portador dividido, há um portador de RLC separado e independente, ainda no lado do UE, por eNB configurado para entregar PDUs de PDCP do portador de PDCP, terminadas no MeNB. D. RLCs Mestres-Escravos: essa opção supõe que S1-U termina em MeNB com a camada de PDCP e parte da camada de RLC residindo no MeNB. Enquanto exige apenas uma entidade de RLC no UE para o portador EPS, no lado da rede a funcionalidade de RLC é distribuída entre os nós envolvidos, com um “RLC escravo” operando no SeNB. No downlink, o RLC escravo cuida da operação de RLC crítica de atraso necessária no SeNB: ele recebe do RLC mestre no MeNB PDUs de RLC prontamente embutidas (com Número de Sequência já atribuído pelo mestre) que o mestre atribuiu a transmissão pelo escravo e transmite ao UE. O ajuste personalizado dessas PDUs em concessões do programador MAC é obtido pela reutilização do mecanismo de ressegmentação atualmente definido.

[0102] Com base nisso, diferentes arquiteturas seção propostas, sendo ilustradas nas figuras 22a-i; essas são consideradas do Email Discussion Report on U-Plane Alternatives, 3GPP TSG-RAN WG2 Reunião #82, R2-131621 pela Nokia Siemens Networks (Rapporteur).

[0103] Uma visão geral das características principais das várias alternativas ilustradas nas figuras 22a-i é dada a seguir; onde o portador dividido deve ser entendido como a capacidade de dividir um portador sobre múltiplos eNBs. Como pode ser visto a partir das figuras, dois portadores são supostos sendo indicados para passar a interface S1. - 1A: S1-U termina em SeNB + PDCPs independentes (nenhum portador dividido); - 2A: S1-U termina em MeNB + nenhum portador dividido em MeNB + PDCP independente em SeNB; - 2B: S1-U termina em MeNB + nenhum portador dividido em MeNB + PDCPs mestre-escravo; - S1-U termina em MeNB + nenhum portador dividido em MeNB + RLC independente em SeNB; - 2D: S1-U termina em MeNB + nenhum portador dividido em MeNB + RLC mestre-escravo; - 3A: S1-U termina em MeNB + portador dividido em MeNB + PDCPs independentes para portadores divididos; - 3B: S1-U termina em MeNB + portador dividido em MeNB + PDCPs mestre-escravo para portadores divididos; - 3C: S1-U termina em MeNB + portador dividido em MeNB + RLCs independentes para portadores divididos; - 3D: S1-U termina em MeNB + portador dividido em MeNB + RLC mestre-escravo para portadores divididos.

[0104] Durante a discussão, várias vantagens e desvantagens são identificadas para cada uma das alternativas acima.

[0105] Deficiências da arquitetura do plano do usuário

[0106] Conforme explicado acima, o link de backhaul entre o MeNB e o SeNB poderiam ser lentos e, assim, causariam uma latência unidirecional que poderia ser alta, por exemplo, 60 ms (veja a tabela acima para o backhaul não ideal).

[0107] Ainda, em algumas alternativas da arquitetura do plano do usuário mesmo a parte das camadas de protocolo Access Stratum (por exemplo, PDCP, RLC, MAC) serão distribuídas entre MeNB e SeNB. Correspondentemente, a alta latência tornaria impossível compartilhar a informação em tempo real entre os nós; alguma informação pode ainda ser desatualizada pelo tempo que atinge o outro nó.

[0108] Além disso, a comunicação entre camadas / de camada cruzada aumentaria a sinalização da interface carregada na interface entre os nós (ou seja, interface X2 entre eNB Macro e Pequeno). Ainda deveria ser garantido que a carga nessa interface não é desnecessária.

[0109] Em mais detalhes, a latência introduzida devido à Conectividade Dupla na comunicação entre camadas / de camada cruzada pode ser uma fonte de outros problemas, por exemplo, ao procedimento existente do mecanismo de descarte da SDU/PDU de PDCP.

[0110] Conforme explicado em conexão com a figura 13, na técnica anterior os trabalhos de descarte da SDU de PDCP com base no discardTimer, na expiração da SDU de PDCP correspondente ao longo da PDU de PDCP correspondente (se já gerada) são descartados. Se a PDU de PDCP correspondente já foi submetida à camada inferior, o descarte deve ser indicado à camada inferior.

[0111] O mecanismo de descarte de PDCP da figura 13 pode ser aplicado ao cenário onde o PDCP e as camadas de RLC são distribuídas entre MeNB e SeNB, e em particular onde o PDCP (ou pelo menos o mecanismo de descarte da SDU de PDCP) não está no SeNB; isso é ilustrado na figura 23. Isso é verdadeiro para pelo menos as arquiteturas do plano do usuário atualmente discutidas das Alternativas 2C, 2D, 3C, 3D; e possivelmente para as Alternativas 2B e 3B, dependendo de como as camadas de PDCP Mestre-Escravo em MeNB e SeNB são divididas, em particular como a funcionalidade de descarte de SDU/PDU de PDCP conforme discutido está localizada no MeNB ou no SeNB.

[0112] Como pode ser visto da figura 23, assume- se que a camada de PDCP e em particular a função de descarte de PDCP, está localizada no MeNB, enquanto que a camada de RLC está localizada no SeNB.

[0113] Para dados a ser transmitidos noe downlink do MeNB/SeNB ao UE, a camada de PDCP inicia um discardTimer para cada SDU de PDCP que recebe, e verifica continuamente se o temporizador para a SDU de PDCP expira. Além disso, a camada de PDCP ainda realiza sua função comum de gerar uma PDU de PDCP da SDU de PDCP (por exemplo, Compressão de Cabeçalho, Cifragem, Proteção de Integridade, adicionar cabeçalho de PDCP, veja a figura 11) e encaminhar a PDU de PDCP à camada de RLC. Na expiração do discardTimer para uma SDU de PDCP particular, a PDU de PDCP e SDU de PDCP devem ser descartadas. Além disso, a camada de PDCP no MeNB verifica se a PDU de PDCP correspondentemente gerada já foi encaminhada à camada inferior, RLC ou não. Se não, nenhuma indicação em direção à camada de RLC é necessária. Se a PDU de PDCP já foi encaminhada ao RLC (“Sim”), embora a PDU de PDCP e a SDU na camada de PDCP sejam descartadas, é ainda necessário instruir o RLC para descartar a PDU de PDCP correspondente também. A camada de RLC no SeNB, por sua vez, verifica se já procedeu para mapear a PDU de PDCP (ou um segmento dela) em uma PDU de RLC, neste caso o descarte da PDU de PDCP na camada de RLC não é mais possível. Se, entretanto, a PDU de PDCP ainda não foi processada pela camada de RLC em uma PDU de RLC, então a PDU de PDCP pode ser descartada na camada de RLC também.

[0114] Deve-se observar que a PDU de PDCP é da perspectiva de RLC de uma SDU de RLC; isso se aplica para a maioria das alternativas da figura 22. Entretanto, onde a camada de RLC é dividida entre o MeNB e SeNB (veja as Alternativas 2D e 3D), a terminologia é de alguma forma ambígua, pois a camada de RLC no MeNB recebe a PDU de PDCP, realiza as funções particulares nela (que ainda não estão definidas) em então, encaminha o “pacote” resultante à camada de RLC do SeNB. Da perspectiva da camada de RLC do SeNB, pode ser dito que ela recebe uma PDU de RLC ou uma SDU de RLC, dependendo se as funções da camada de RLC no MeNB ajá foram consideradas para formar a PDU de RLC ou não. Na seguinte descrição da invenção, assume-se para finalidades de ilustração e para simplicidade que apenas a camada de RLC no SeNB recebe uma SDU de RLC do MeNB (seja da camada de PDCP ou da camada de RLC Mestre no MeNB); que deveria, entretanto, não restringir a invenção e o escopo a essa terminologia, o uso da terminologia “PDU de RLC” pode ser utilizado equivalentemente nessa conexão.

[0115] Conforme mencionado, o MeNB indica o descarte da PDU de PDCP(s) à camada de RLC no SeNB. Isso pode resultar em informação de descarte por pacote sendo enviada na interface X2. Primeiramente, isso é um desperdício de recursos, pois essa informação precisa ser carregada para cada PDU de PDCP que pode precisar ser descartada.

[0116] Outro problema é que devido à latência da interface X2, é possível que no meio tempo, o SeNB de fato iniciado transmita a PDU de PDCP (ou pelo menos um segmento da PDU de PDCP), ou seja, formando a PDU de RLC; com o resultado do SeNB deve completar a transmissão bem-sucedida de PDU, que não seria necessária de outra forma. Assim, devido à possível alta latência na interface X2, a funcionalidade de descarte pode realmente não funcionar para transmissões de downlink.

SUMÁRIO DA INVENÇÃO

[0117] Um objeto da invenção é prover um método melhorado para descartar dados de downlink na forma de SDUs/PDUs de PDCPem um cenário de conectividade dupla. Um objeto mais específico da invenção é melhorar a função de descarte da camada de PDCP e a inter-relação correspondente com a camada de RLC, nos casos onde a dita função de descarte de PDCP está localizada na estação base mestre (mas não na estação base secundária) e a camada de RLC está na estação base secundária.

[0118] O objeto é solucionado pelo assunto das reivindicações independentes. Realizações vantajosas são submetidas às reivindicações dependentes.

[0119] Para o primeiro aspecto da invenção, assume-se que a estação móvel está em conectividade dupla e, assim, conectada a uma estação base mestre e uma estação base secundária através dos respectivos links de comunicação. A estação móvel está pelo menos recebendo pacotes de dados que são encaminhados da estação base mestre através da estação base secundária à estação móvel. Uma pilha do protocolo, incluindo uma camada mais alta (por exemplo, camada de PDCP) com uma função mestre de descarte está localizada na estação base mestre, mas não na estação base secundária. A estação base secundária ainda tem uma pilha do protocolo, mas ao invés de ter a dita camada mais alta da estação base mestre particular, ela tem uma camada inferior, que é a camada abaixo da camada mais alta da estação base mestre, (por exemplo, camada de RLC). Correspondentemente, os pacotes de dados são encaminhados da camada da estação base mestre mais alta (por exemplo, PDCP) à camada na estação base secundária mais baixa (por exemplo, RLC).

[0120] A função mestre de descarte da camada mais alta (por exemplo, PDCP) na estação base mestre permite descartar esses pacotes de dados que não são (após processamento correto na dita camada mais alta) ainda encaminhados com sucesso à estação móvel. Para a dita finalidade, um temporizador mestre da função mestre de descarte é iniciado para cada pacote de dados (por exemplo, SDU de PDCP), no recebimento do mesmo. A camada mais alta processa o pacote de dados recebido (por exemplo, SDU de PDCP) corretamente, por exemplo, gerando um pacote de dados processado (por exemplo, PDU de PDCP) a ser encaminhado à camada inferior (por exemplo, RLC).

[0121] O temporizador mestre pode ser interrompido se o pacote de dados foi encaminhado com sucesso à estação móvel; o que poderia, por exemplo, ser noticiado pela camada inferior. Nesse caso, os pacotes de dados recebidos e processados podem ser eventualmente excluídos na camada mais alta, pois eles não são mais necessários, assim esvaziando o buffer na estação base mestre. Se, entretanto, o temporizador mestre expirar (ou seja, antes de encaminhamento do pacote de dados ser com sucesso concluído), o pacote de dados (por exemplo, SDU de PDCP) e os pacote de dados processados (por exemplo, PDU de PDCP) são descartados na camada mais alta (por exemplo, PDCP).

[0122] Além disso, assume-se que uma função secundária de descarte é configurada na dita camada inferior na estação base secundária, que em alguma extensão reflete a função mestre de descarte na estação base mestre. Para a dita finalidade, a estação base mestre configura a função secundária de descarte com base na função mestre de descarte na camada mais alta; que pode incluir transmitir uma mensagem de configuração da estação base mestre à estação base secundária, a mensagem de configuração pelo menos compreendendo um valor do temporizador a ser utilizado em conexão com o temporizador secundário da função secundária de descarte. O valor do temporizador na mensagem de configuração pode ser tanto o valor do temporizador do temporizador mestre, quanto alternativamente pode ser já um valor inferior para compensar o(s) atraso(s) incorridos devido ao link de comunicação entre a estação base mestre e secundária e/ou o atraso de processamento para o controle de fluxo gasto em todo o processo de transmissão do pacote de dados da estação base mestre à secundária. Ainda alternativamente, a adaptação do valor do temporizador secundário pode ser ainda realizada pela estação base secundária, de modo que a mensagem de configuração seja utilizada pela estação base secundária que inclui o valor do temporizador mestre, que, entretanto, é ajustado pela estação base secundária para compensar os vários atrasos entre a recepção do pacote de dados na camada mais alta da estação base mestre e a recepção dos dados (após o processamento pela camada mais alta) na camada inferior da estação base secundária. Assim, o temporizador mestre e o temporizador secundário para um pacote de dados particular devem expirar essencialmente ao mesmo tempo.

[0123] Além disso, para facilitar a sincronização dos dois temporizadores, temporizador mestre e secundário, a informação de registro de hora pode ser provida da estação base mestre à secundária, como segue. Toda vez que um pacote de dados é recebido na camada mais alta na estação base mestre, a estação base mestre pode adicionalmente gerar um registro de hora para o dito pacote de dados, o registro de hora indicando o tempo de recepção no qual o pacote de dados foi de fato recebido na camada mais alta, por exemplo, em qual período o temporizador mestre foi acionado, ou indicando o tempo de expiração do temporizador mestre remanescente para o pacote de dados. Em qualquer caso, o registro de hora é provido à estação base secundária, além do pacote de dados real (por exemplo, como parte do cabeçalho do pacote de dados), e assim pode ser utilizado pela estação base secundária para configurar o temporizador secundário para corresponder o temporizador mestre para o pacote de dados particular.

[0124] O temporizador secundário é iniciado toda vez que um pacote de dados (por exemplo, PDU de PDCP) for recebido na camada inferior da camada mais alta na estação base mestre. Correspondentemente, na expiração do temporizador secundário, o pacote de dados recebido (por exemplo, PDU de PDCP) é descartado na camada inferior da estação base secundária.

[0125] Como um resultado, quando um pacote de dados, a ser encaminhado à estação móvel, é recebido na estação base mestre e em particular na camada mais alta (por exemplo, PDCP) da pilha do protocolo da estação base mestre, o temporizador mestre da função mestre de descarte é iniciado e a camada mais alta da estação base mestre processa o pacote de dados (por exemplo, para gerar uma PDU de PDCP da SDU de PDCP recebida).

[0126] Primeiro, assume-se para finalidades de ilustração que o pacote de dados processados (por exemplo, PDU de PDCP) não pode ser encaminhado à camada inferior na estação base secundária, antes do temporizador mestre expirar. Correspondentemente, o pacote de dados processados (por exemplo, PDU de PDCP) bem como o pacote de dados recebido (por exemplo, SDU de PDCP) são descartados pela camada mais alta da estação base mestre.

[0127] Ao assumir que o pacote de dados processados (por exemplo, PDU de PDCP) é de fato encaminhado à camada inferior na estação base secundária, o temporizador secundário da função secundária de descarte na estação base secundária é iniciado no recebimento do pacote de dados processados (por exemplo, PDU de PDCP; pode ser denominada SDU de RLC) na camada inferior da estação base secundária. Entretanto, assume-se que a camada inferior na estação base secundária não pode (por qualquer razão) encaminhar o pacote de dados mais em direção à estação móvel.

[0128] Correspondentemente, o temporizador mestre na estação base mestre (que ainda está operando, visto que o pacote de dados ainda não foi com sucesso transmitido à UE) expira eventualmente e, assim, aciona o descarte do pacote de dados recebido e do pacote de dados processados correspondentes (por exemplo, SDU e PDU de PDCP) na camada mais alta da estação base mestre. Do mesmo modo, o temporizador secundário da função secundária de descarte na estação base secundária expirará para esse pacote de dados também e, assim, aciona o descarte do pacote de dados correspondente na camada inferior da estação base secundária.

[0129] Deve-se observar que vantajosamente, na expiração do temporizador secundário na estação base secundária, a estação base secundária verifica se o pacote de dados (ou pelo menos parte dele) já foi processado pela camada inferior para gerar um pacote de dados adicional específico à camada inferior, pronto para ser transmitido da camada inferior na estação base secundária em direção à estação móvel; na realização mais específica pertencente ao PDCP e à camada de RLC, a estação base secundária verifica se a PDU de PDCP (ou um segmento da mesma) já foi mapeada em uma PDU de RLC. No caso positivo (ou seja, pacote de dados da camada inferior gerada; PDU de RLC gerada), o descarte do pacote de dados na camada inferior não é realizado. No caso negativo, o descarte do pacote de dados na camada inferior é realizado.

[0130] Um segundo aspecto alternativo da invenção ainda soluciona o(s) problema(s) subjacente(s) mencionado(s) acima da invenção, entretanto evita ter uma função secundária de descarte na estação base secundária para simplificar o desenho da estação base secundária. Um cenário similar é assumido para o primeiro aspecto, assim, assumindo uma estação móvel que é conectada a uma estação base mestre e secundária através dos respectivos links de comunicação. A estação móvel pelo menos recebe os pacotes de dados que são encaminhados da estação base mestre através da estação base secundária à estação móvel. Uma pilha do protocolo, incluindo uma camada mais alta (por exemplo, camada de PDCP) com uma função mestre de descarte está localizada na estação base mestre, mas não na estação base secundária. A estação base secundária ainda tem uma pilha do protocolo, mas ao invés de ter a dita camada mais alta da estação base mestre particular, ela tem uma camada inferior, que é a camada abaixo da camada mais alta da estação base mestre (por exemplo, camada de RLC). Correspondentemente, os pacotes de dados são encaminhados da camada da estação base mestre mais alta (por exemplo, PDCP) à camada na estação base secundária mais baixa (por exemplo, RLC), antes de serem encaminhados à estação móvel.

[0131] Como com o primeiro aspecto da invenção, a função mestre de descarte da camada mais alta (por exemplo, PDCP) na estação base mestre permite descartar esses pacotes de dados que não são ainda encaminhados com sucesso à estação móvel. Um temporizador mestre da função mestre de descarte correspondente é iniciado para cada pacote de dados (por exemplo, SDU de PDCP) recebido pela camada mais alta. A camada mais alta (por exemplo, PDCP) processa o pacote de dados recebido (por exemplo, SDU de PDCP) corretamente, por exemplo, gerando um pacote de dados processados (por exemplo, PDU de PDCP) a ser encaminhado à camada inferior (por exemplo, RLC).

[0132] Na expiração do temporizador mestre, o pacote de dados e o pacote de dados processados (por exemplo, SDU e PDU de PDCP respectivamente) são descartados pela camada mais alta.

[0133] Ao contrário da função de descarte conforme explicado na seção da técnica anterior, nenhuma verificação é realizada para saber se o pacote de dados já foi encaminhado à camada inferior ou não. Independentemente, a estação base mestre e, em particular, sua camada mais alta (por exemplo, PDCP), não informa a camada inferior (por exemplo, RLC) sobre o descarte do pacote de dados particular.

[0134] Ao contrário do primeiro aspecto da invenção, ainda nenhuma função secundária de descarte é implementada na estação base secundária que corresponde com a função mestre de descarte descrita na estação base mestre. Ao invés disso, a camada inferior (por exemplo, RLC) da estação base secundária não aprende sobre o descarte do pacote de dados na estação base mestre, mas continua a realizar o processamento da camada inferior para o pacote de dados recebido (por exemplo, transmissão do pacote de dados à estação móvel).

[0135] A camada inferior (por exemplo, RLC) na estação secundária mantém a transmissão do pacote de dados (por exemplo, PDU de PDCP; como uma ou mais PDUs de RLC) à estação móvel e na entrega bem-sucedida do pacote de dados (por exemplo, PDU de PDCP) à estação móvel, a camada inferior (por exemplo, RLC) na estação secundária pode descartar o pacote de dados (por exemplo, PDU de PDCP) recebido da camada mais alta na estação base mestre. Certamente, o segundo aspecto provê esse esquema de descarte que envolve menos processamento na estação base mestre e secundária, bem como uma estação base secundária simplificada.

[0136] De acordo com um terceiro aspecto da invenção, o valor do temporizador mestre da função mestre de descarte é considerado quando a estação móvel decide utilizar o portador para a estação base secundária ou mestre para transmitir dados. Em mais detalhes, um cenário é assumido onde a estação móvel é conectada à estação base mestre e secundária através dos respectivos links de comunicação. Na conectividade dupla, é possível que os mesmos portadores sejam servidos pela estação base mestre e secundária (veja a figura 21 c EPS portador #2); ou seja, alguns pacotes do portador #2 particular são transmitidos através da estação base mestre e outros são transmitidos através da estação base secundária. Isso pode depender das condições do rádio ou outros critérios.

[0137] Esse terceiro aspecto da invenção pode ser utilizado de modo adicional ou alternativo ao primeiro e segundo aspectos descritos acima da invenção. Sugere-se que o tempo remanescente do temporizador mestre da função mestre de descarte seja considerado pela estação móvel ao decidir se transmitir um pacote de dados através da estação base secundária ou mestre, especialmente para o pacote que já sofreu um longo atraso ou tem um curto temporizador de descarte.

[0138] Uma primeira realização da invenção provê um método para descartar pacotes de dados destinados para uma estação móvel conectada tanto a uma estação base mestre quanto a uma estação base secundária. Os pacotes de dados são encaminhados da estação base mestre através da estação base secundária à estação móvel. Uma camada mais alta com uma função mestre de descarte está localizada na estação base mestre, mas não na estação base secundária. A função mestre de descarte descarta pacotes de dados na expiração de um temporizador mestre iniciado no recebimento de cada pacote de dados. A estação base mestre configura uma função secundária de descarte em uma camada inferior da estação base secundária, com base na função mestre de descarte na camada mais alta da estação base mestre. A estação base mestre encaminha o pacote de dados da camada mais alta à camada inferior da estação base secundária. A função secundária de descarte da camada inferior na estação base secundária descarta o pacote de dados recebido na expiração do temporizador secundário iniciado pela camada inferior no recebimento do pacote de dados da camada mais alta na estação base mestre.

[0139] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo ao acima.

[0140] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a camada mais alta na estação base mestre é uma camada de PDCP, a camada inferior na estação base secundária é uma camada de RLC e o pacote de dados é recebido pela camada de PDCP como uma SDU de PDCP e encaminhado à camada de RLC como uma PDU de PDCP, gerada pela camada de PDCP da SDU de PDCP recebida. Assim, a função secundária de descarte da camada de RLC na estação base secundária descarta a PDU de PDCP recebida na expiração do temporizador secundário iniciado pela camada de RLC no recebimento da PDU de PDCP da camada de PDCP na estação base mestre.

[0141] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, na expiração do temporizador secundário iniciado pela camada de RLC, determinar pela camada de RLC na estação base secundária, se a PDU de PDCP ou qualquer segmento da PDU de PDCP já foi utilizado para gerar uma PDU de RLC. A dita etapa de descarte da PDU de PDCP recebida pela função secundária de descarte da camada de RLC na estação base secundária é apenas realizada quando a PDU de PDCP ou qualquer segmento da PDU de PDCP ainda não foi utilizado para gerar uma PDU de RLC.

[0142] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a dita etapa de configurar a função secundária de descarte compreende a etapa de transmitir uma mensagem de configuração da estação base mestre à estação base secundária, incluindo a informação no temporizador secundário, pelo menos incluindo um valor do tempo de expiração a ser utilizado para configurar o temporizador secundário da função secundária de descarte. A estação base secundária configura a função secundária de descarte com base na informação recebida no temporizador secundário pelo menos incluindo o valor do tempo de expiração para o temporizador secundário...

[0143] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, o valor do tempo de expiração do temporizador secundário da camada de RLC para uma PDU de PDCP, incluído na mensagem de configuração, é o mesmo que um valor do tempo de expiração do temporizador mestre da camada de PDCP para uma SDU de PDCP. Ou, o valor do tempo de expiração do temporizador secundário da camada de RLC para uma PDU de PDCP, incluído na mensagem de configuração, é menor que um valor do tempo de expiração do temporizador mestre da camada de PDCP para uma SDU de PDCP pelo tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária. Ou, o valor do tempo de expiração do temporizador secundário da camada de RLC para uma PDU de PDCP, incluído na mensagem de configuração, é o mesmo que um valor do tempo de expiração do temporizador mestre da camada de PDCP para uma SDU de PDCP e a estação base secundária configura a função secundária de descarte da camada de RLC com base na informação recebida pelo menos incluindo o valor do tempo de expiração do temporizador secundário reduzido pelo tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária.

[0144] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, o valor do tempo de expiração do temporizador secundário da camada de RLC, incluído na mensagem de configuração, é menor que um valor do tempo de expiração do temporizador mestre da camada de PDCP pelo tempo de atraso utilizado pelo controle de fluxo dos pacotes de dados entre a estação base mestre e a estação base secundária.

[0145] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a estação base mestre gera informação de registro de hora no tempo de recepção da SDU de PDCP na camada de PDCP da estação base mestre. Ou, a estação base mestre gera a informação de registro de hora no tempo de expiração do temporizador mestre da função mestre de descarte remanescente para a SDU de PDCP. Então, a estação base mestre transmite a informação de registro de hora gerada à estação base secundária, preferivelmente dentro de um cabeçalho da PDU de PDCP encaminhado pela camada de PDCP da estação base mestre à camada de RLC da estação base secundária. E, a dita etapa de descartar a PDU de PDCP recebida pela função secundária de descarte da camada de RLC na estação base secundária é ainda com base na informação recebida de registro de hora referente à SDU de PDCP, pela qual a PDU de PDCP é gerada.

[0146] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, receber uma SDU de PDCP na camada de PDCP na estação base mestre, no recebimento da SDU de PDCP, a camada de PDCP na estação base mestre inicia o temporizador mestre da função mestre de descarte para a SDU de PDCP recebida. A camada de PDCP na estação base mestre gera a PDU de PDCP da SDU de PDCP recebida. Sob recebimento pela estação base mestre uma indicação que a PDU de PDCP gerada foi encaminhada com sucesso à estação móvel, a camada de PDCP na estação base mestre descarta a SDU de PDCP recebida e a PDU de PDCP gerada.

[0147] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a indicação recebida é transmitida pela estação base secundária à estação base mestre e inclui informação sobre uma ou mais PDUs de PDCP encaminhadas com sucesso pela estação base secundária à estação móvel; a indicação pode, por exemplo, adicionalmente compreender a informação sobre uma ou mais PDUs de PDCP encaminhadas sem sucesso pela estação base secundária à estação móvel. Por exemplo, essa indicação é transmitida pela estação base secundária para cada PDU de PDCP encaminhada com sucesso à estação móvel; ou essa indicação compreende um bitmap para uma pluralidade de PDUs de PDCP; ou essa indicação indica a PDU de PDCP que foi mais recentemente encaminhada com sucesso à estação móvel.

[0148] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a estação base mestre monitora o valor do tempo de expiração do temporizador secundário para determinar quando o temporizador secundário na estação base secundária expirará. No caso em que a estação base mestre não recebe da estação base secundária a indicação que uma PDU de PDCP foi encaminhada com sucesso à estação móvel no prazo onde a estação base mestre determina que o temporizador secundário é suportado para expirar, a estação base mestre transmite a PDU de PDCP, para a qual nenhuma indicação foi recebida, à estação móvel, antes do temporizador mestre para a dita PDU de PDCP expirar.

[0149] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a estação base secundária transmite uma indicação descartada à estação base mestre para informar a estação base mestre sobre o descarte de uma ou mais PDUs de PDCP que são descartadas pela estação base secundária, pois a estação base secundária não poderia encaminhá-las com sucesso à estação móvel. Por exemplo, a indicação descartada é transmitida pela estação base secundária para cada PDU de PDCP encaminhada sem sucesso à estação móvel.

[0150] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, quando a estação base mestre recebe a indicação descartada da estação base secundária para uma PDU de PDCP, a estação base mestre transmite a dita PDU de PDCP à estação móvel.

[0151] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a estação base secundária consulta a estação móvel para transmitir um Relatório de Status de RLC à estação base secundária para receber o relatório de status de RLC antes da expiração do temporizador secundário.

[0152] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a estação base mestre considera o valor do temporizador de expiração configurado para a função mestre de descarte para estabelecer links de comunicação com a estação móvel, de modo que os links de comunicação configurados com pequenos valores do temporizador de expiração para a função mestre de descarte são estabelecidas diretamente com a estação móvel e não através da estação base secundária.

[0153] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, uma mensagem é transmitida à estação móvel incluindo informação sobre o tempo de atraso do link de comunicação entre a estação base mestre e s estação base secundária. Ou, a estação móvel estima o tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária, com base nos diferentes tempos de recepção de PDUs de PDCP subsequentes recebidas da estação base mestre e da estação base secundária. Subsequentemente, se um tempo de expiração remanescente de um temporizador de descarte na camada de PDCP da estação móvel para uma SDU de PDCP a ser transmitida à estação base secundária é igual ou menor que o tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária, a SDU de PDCP e a PDU de PDCP, geradas da SDU de PDCP, são descartadas pela estação móvel ou a PDU de PDCP é transmitida pela estação móvel diretamente à estação base mestre através de um link de comunicação entre a estação móvel e a estação base mestre.

[0154] Uma segunda realização da invenção provê um método para descartar dados na forma de uma PDU de PDCP destinada para uma estação móvel conectada a uma estação base mestre e uma estação base secundária. Os dados são encaminhados da estação base mestre através da estação base secundária à estação móvel. Uma camada de PDCP com uma função mestre de descarte está localizada na estação base mestre, mas não na estação base secundária. Uma SDU de PDCP é recebida na camada de PDCP na estação base mestre. No recebimento da SDU de PDCP, a camada de PDCP na estação base mestre inicia o temporizador mestre da função mestre de descarte da camada de PDCP para a SDU de PDCP recebida. A camada de PDCP na estação base mestre gera a PDU de PDCP da SDU de PDCP recebida. A PDU de PDCP gerada é encaminhada pela camada de PDCP na estação base mestre à camada de RLC na estação base secundária. Ao encaminhar a PDU de PDCP gerada pela estação base mestre à camada de RLC na estação base secundária, a camada de PDCP na estação base mestre descarta a SDU de PDCP recebida e a PDU de PDCP geradas. Na expiração do temporizador mestre da função mestre de descarte da camada de PDCP na estação base mestre para a SDU de PDCP recebida, a camada de PDCP determina se a PDU de PDCP, gerada da SDU de PDCP, já foi encaminhada pela camada de PDCP na estação base mestre à camada de RLC na estação base secundária. No caso positivo, a camada de PDCP não instrui a camada de RLC para descartar a PDU de PDCP, encaminhada à camada de RLC.

[0155] Uma terceira realização da invenção provê uma estação móvel para transmitir dados a uma estação base, a estação móvel sendo conectada a uma estação base mestre e uma estação base secundária. Uma camada mais alta com uma função mestre de descarte está localizada na estação base mestre, mas não na estação base secundária. A função mestre de descarte que descarta pacotes de dados na expiração de um temporizador mestre iniciado no recebimento de cada pacote de dados. Um receptor da estação móvel recebe uma mensagem da estação base mestre incluindo a informação sobre o tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária; ou, um processador da estação móvel estima o tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária, com base nos diferentes tempos de recepção das PDUs de PDCP subsequentes recebida da estação base mestre e da estação base secundária. Um processador da estação móvel determina se um tempo de expiração remanescente de um temporizador de descarte na camada de PDCP da estação móvel para uma SDU de PDCP a ser transmitida à estação base secundária é igual ou menor que o tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária. No caso positivo, o processador descarta a SDU de PDCP e a PDU de PDCP, geradas da SDU de PDCP, ou um transmissor da estação móvel transmite a PDU de PDCP diretamente à estação base mestre através de um link de comunicação entre a estação móvel e a estação base mestre. A primeira realização da invenção provê uma estação base mestre para encaminhar pacotes de dados destinados para uma estação móvel. Uma estação móvel é conectada tanto à estação base mestre quanto a uma estação base secundária. Os pacotes de dados são encaminhados da estação base mestre através da estação base secundária à estação móvel. Uma camada mais alta com uma função mestre de descarte está localizada na estação base mestre, mas não na estação base secundária, a função mestre de descarte que descarta pacotes de dados na expiração de um temporizador mestre iniciado no recebimento de cada pacote de dados. Um processador e transmissor da estação base mestre configuram uma função secundária de descarte em uma camada inferior da estação base secundária, com base na função mestre de descarte na camada mais alta da estação base mestre, de modo que a função secundária de descarte da camada inferior na estação base secundária descarte um pacote de dados recebido na expiração do temporizador secundário iniciado pela camada inferior no recebimento do pacote de dados recebido da camada mais alta na estação base mestre. O transmissor encaminha o pacote de dados da camada mais alta à camada inferior da estação base secundária.

[0156] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a camada mais alta na estação base mestre é uma camada de PDCP, a camada inferior na estação base secundária é uma camada de RLC e o pacote de dados é recebido pela camada de PDCP como uma SDU de PDCP e encaminhado à camada de RLC como uma PDU de PDCP, geradas pela camada de PDCP da SDU de PDCP recebida, de modo que a função secundária de descarte da camada de RLC na estação base secundária descarte a PDU de PDCP recebida na expiração do temporizador secundário iniciado pela camada de RLC no recebimento da PDU de PDCP da camada de PDCP na estação base mestre.

[0157] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a configuração da função secundária de descarte compreende que o transmissor transmite uma mensagem de configuração à estação base secundária, incluindo a informação no temporizador secundário, pelo menos incluindo um valor do tempo de expiração a ser utilizado para configurar o temporizador secundário da função secundária de descarte.

[0158] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, o valor do tempo de expiração do temporizador secundário da camada de RLC para uma PDU de PDCP, incluído na mensagem de configuração, é o mesmo que um valor do tempo de expiração do temporizador mestre da camada de PDCP para uma SDU de PDCP; ou, o valor do tempo de expiração do temporizador secundário da camada de RLC para uma PDU de PDCP, incluído na mensagem de configuração, é menor que um valor do tempo de expiração do temporizador mestre da camada de PDCP para uma SDU de PDCP pelo tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária; ou, o valor do tempo de expiração do temporizador secundário da camada de RLC, incluído na mensagem de configuração, é menor que um valor do tempo de expiração do temporizador mestre da camada de PDCP pelo tempo de atraso utilizado pelo controle de fluxo do pacotes de dados entre a estação base mestre e a estação base secundária.

[0159] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, o processador gera informação de registro de hora no tempo de recepção da SDU de PDCP na camada de PDCP da estação base mestre, ou informação de registro de hora no tempo de expiração do temporizador mestre da função mestre de descarte remanescente para a SDU de PDCP. O transmissor transmite a informação de registro de hora gerada à estação base secundária, preferivelmente dentro de um cabeçalho da PDU de PDCP encaminhado pela camada de PDCP da estação base mestre à camada de RLC da estação base secundária.

[0160] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a estação base mestre considera o valor do temporizador de expiração configurado para a função mestre de descarte para estabelecer links de comunicação com a estação móvel, de modo que os links de comunicação configurado com pequenos valores do temporizador de expiração para a função mestre de descarte sejam estabelecidos diretamente com a estação móvel e não através da estação base secundária.

[0161] A primeira realização da invenção provê uma estação base secundária para encaminhar os pacotes de dados a uma estação móvel, em que uma estação móvel é conectada tanto a uma estação base mestre quanto à estação base secundária. Os pacotes de dados são encaminhados da estação base mestre através da estação base secundária à estação móvel. Uma camada mais alta com uma função mestre de descarte está localizada na estação base mestre, mas não na estação base secundária, a função mestre de descarte que descarta pacotes de dados na expiração de um temporizador mestre iniciado no recebimento de cada pacote de dados. Um processador da estação base secundária configura uma função secundária de descarte em uma camada inferior da estação base secundária, com base na função mestre de descarte na camada mais alta da estação base mestre. Um receptor da estação base secundária recebe na camada inferior da estação base secundária o pacote de dados da camada mais alta da estação base mestre. Um processador da estação base secundária descarta pela função secundária de descarte da camada inferior na estação base secundária o pacote de dados recebido na expiração do temporizador secundário iniciado pela camada inferior no recebimento do pacote de dados da camada mais alta na estação base mestre.

[0162] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, a camada mais alta na estação base mestre é uma camada de PDCP, a camada inferior na estação base secundária é uma camada de RLC e o pacote de dados é recebido pela camada de PDCP como uma SDU de PDCP e encaminhado à camada de RLC como uma PDU de PDCP, gerada pela camada de PDCP da SDU de PDCP recebida, de modo que a função secundária de descarte da camada de RLC na estação base secundária descarte a PDU de PDCP recebida na expiração do temporizador secundário iniciado pela camada de RLC no recebimento da PDU de PDCP da camada de PDCP na estação base mestre.

[0163] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, na expiração do temporizador secundário iniciado pela camada de RLC, o processador determina pela camada de RLC na estação base secundária, se a PDU de PDCP ou qualquer segmento da PDU de PDCP já foi utilizada para gerar uma PDU de RLC. A dita etapa de descarte da PDU de PDCP recebida pela função secundária de descarte da camada de RLC na estação base secundária é apenas realizada quando a PDU de PDCP ou qualquer segmento da PDU de PDCP ainda não foi utilizada para gerar uma PDU de RLC.

[0164] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, o receptor recebe uma mensagem de configuração da estação base mestre, incluindo a informação no temporizador secundário, pelo menos incluindo um valor do tempo de expiração a ser utilizado para configurar o temporizador secundário da função secundária de descarte. O processador configura a função secundária de descarte com base na informação recebida no temporizador secundário pelo menos incluindo o valor do tempo de expiração para o temporizador secundário.

[0165] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, o valor do tempo de expiração do temporizador secundário da camada de RLC para uma PDU de PDCP, incluído na mensagem de configuração, é o mesmo que um valor do tempo de expiração do temporizador mestre da camada de PDCP para uma SDU de PDCP; ou o valor do tempo de expiração do temporizador secundário da camada de RLC para uma PDU de PDCP, incluído na mensagem de configuração, é menor que um valor do tempo de expiração do temporizador mestre da camada de PDCP para uma SDU de PDCP pelo tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária; ou, o valor do tempo de expiração do temporizador secundário da camada de RLC, incluído na mensagem de configuração, é menor que um valor do tempo de expiração do temporizador mestre da camada de PDCP pelo tempo de atraso utilizado pelo controle de fluxo do pacotes de dados entre a estação base mestre e a estação base secundária; ou, o valor do tempo de expiração do temporizador secundário da camada de RLC para uma PDU de PDCP, incluído na mensagem de configuração, é o mesmo que um valor do tempo de expiração do temporizador mestre da camada de PDCP para uma SDU de PDCP e o processador da estação base secundária configura a função secundária de descarte da camada de RLC com base na informação recebida pelo menos incluindo o valor do tempo de expiração do temporizador secundário reduzido pelo tempo de atraso do link de comunicação entre a estação base mestre e a estação base secundária...

[0166] De acordo com uma variante vantajosa da primeira realização da invenção que pode ser utilizada de modo adicional ou alternativo à acima, o receptor recebe a informação de registro de hora da estação base mestre incluindo tanto a informação no tempo de recepção da SDU de PDCP na camada de PDCP da estação base mestre quanto a informação no tempo de expiração do temporizador mestre da função mestre de descarte remanescente para a SDU de PDCP. O processador descarta a PDU de PDCP recebida pela função secundária de descarte da camada de RLC com base na informação recebida de registro de hora referente à SDU de PDCP, pela qual a PDU de PDCP é gerada.

[0167] Benefícios e vantagens adicionais das realizações reveladas serão evidentes a partir do relatório descritivo e das figuras. Os benefícios e/ou vantagens podem ser individualmente providos pelas várias realizações e recursos da revelação do relatório descritivo e desenhos e não precisam ser todos providos a fim de obter um ou mais dos mesmos.

BREVE DESCRIÇÃO DAS FIGURAS

[0168] As seguintes realizações exemplares são descritas em mais detalhes com referência às figuras e desenhos anexos.

[0169] A figura 1 mostra uma arquitetura exemplar de um sistema 3GPP LTE,

[0170] A figura 2 mostra uma visão geral exemplar de toda a arquitetura E-UTRAN de 3GPP LTE,

[0171] A figura 3 mostra limites de subframe exemplares em um transportador de componente de downlink conforme definido para 3GPP LTE (Versão 8/9),

[0172] A figura 4 mostra uma grade de recursos de downlink exemplar de um slot de downlink conforme definido para 3GPP LTE (Versão 8/9),

[0173] As figuras 5 e 6 mostram a estrutura da Camada 2 de 3GPP LTE-A (Versão 10) com agregação do transportador ativado para o downlink e o uplink, respectivamente,

[0174] A figura 7 ilustra o modelo OSI com as diferentes camadas para comunicação,

[0175] A figura 8 ilustra a relação de uma unidade de dados de protocolo (PDU) e uma unidade de dados de serviço (SDU) bem como a troca entre camadas da mesma,

[0176] A figura 9 ilustra o usuário da camada 2 e pilha do protocolo do plano de controle compostos por três subcamadas, PDCP, RLC e MAC,

[0177] A figura 10 fornece uma visão geral das diferentes funções no PDCP, RLC e camadas MAC bem como ilustra exemplarmente o processamento de SDUs/PDUs pelas várias camadas,

[0178] A figura 11 ilustra a arquitetura da camada de PDCP para os dados do plano do usuário,

[0179] A figura 12 ilustra a arquitetura da camada de PDCP para os dados do plano de controle,

[0180] A figura 13 é um fluxograma para ilustrar em uma forma simplificada as etapas relevantes relacionadas à função de descarte na camada de PDCP e a inter-relação com o descarte na camada de RLC,

[0181] As figuras 14 e 15 ilustram uma PDU de Dados e Controle respectivamente,

[0182] A figura 16 ilustra um cenário de implementação para melhoria de pequena célula, onde células grandes e pequenas estão na mesma frequência do transportador,

[0183] As figuras 17 e 18 ilustram outros cenários de implementação para melhoria de pequena célula onde as células grandes e pequenas estão em diferentes frequências do transportador, a pequena célula sendo respectivamente externa e interna,

[0184] A figura 19 ilustra um cenário de implementação adicional para a melhoria da pequena célula com apenas pequenas células,

[0185] A figura 20 fornece uma visão geral da arquitetura do sistema de comunicação para conectividade dupla com eNBs macro e pequenos conectados à rede central, onde a interface S1-U termina no eNB Macro e nenhuma divisão do portador é feita em RAN,

[0186] As figuras 21 a-c ilustram as diferentes opções para ter dois portadores EPS separados entre SGW e UE,

[0187] As figuras 22a-i ilustram as diferentes alternativas de arquitetura do plano do usuário atualmente discutidas em conexão com a conectividade dupla no MeNB e SeNB,

[0188] A figura 23 é um fluxograma para ilustrar em uma forma simplificada as etapas relevantes relacionadas à função de descarte na camada de PDCP e a inter-relação com o descarte na camada de RLC, como na figura 13, quando aplicado às arquiteturas do plano do usuário onde a função de descarte de PDCP está localizada no MeNB enquanto a camada de RLC está no SeNB,

[0189] A figura 24 é um fluxograma para ilustrar a função de descarte melhorada de acordo com uma primeira realização exemplar,

[0190] As figuras 25 e 26 são um diagrama de sinalização que ilustra uma melhoria à primeira realização de acordo com a qual o MeNB pode determinar se ou não transmitir uma retransmissão adicional diretamente ao UE para PDUs de PDCP particulares que o SeNB não poderia transmitir com sucesso ao UE,

[0191] A figura 27 é um diagrama de sinalização exemplarmente que ilustra uma melhoria de acordo com o qual uma Indicação de Descarte é transmitida do SeNB ao MeNB, para as PDUs de PDCP que não poderiam ser transmitidas pelo SeNB ao UE,

[0192] A figura 28 é um fluxograma para ilustrar a função melhorada de descarte de acordo com uma segunda realização exemplar, e

[0193] A figura 29 é um fluxograma para ilustrar a função melhorada de descarte entre SeNB e MeNB de acordo com uma quinta realização exemplar.

DESCRIÇÃO DETALHADA

[0194] Os seguintes parágrafos descreverão as várias realizações exemplares. Para finalidades exemplares apenas, a maioria das realizações são descritas em relação a um esquema de acesso por rádio de acordo com os sistemas de comunicação móvel 3GPP LTE (Versão 8/9) e LTE-A (Versão 10/11), parcialmente discutidos na seção cima de Histórico da Invenção. Deve-se observar que as realizações podem ser vantajosamente utilizadas, por exemplo, em um sistema de comunicação móvel como sistemas de comunicação 3GPP LTE-A (Versão 10/11/12) conforme descrito na seção acima de Histórico da Invenção, mas as realizações não são limitadas a seu uso nessas redes de comunicação exemplares particulares.

[0195] Uma estação móvel ou nó móvel é uma entidade física com uma rede de comunicação. Um nó pode ter várias entidades funcionais. Uma entidade funcional se refere a um módulo de software ou hardware que implementa e/ou oferece um conjunto predeterminado de funções a outras entidades funcionais de um nó ou a rede. Os nós podem ter uma ou mais interfaces que fixam o nó em uma instalação de comunicação ou meio no qual os nós podem se comunicar. De forma simular, uma entidade da rede pode ter uma interface lógica que fixa a entidade funcional em uma instalação de comunicação ou meio no qual pode se comunicar com outras entidades funcionais ou nós correspondentes.

[0196] O termo “estação base mestre” utilizada nas reivindicações pode ainda ser chamado de estação base macro, ou eNB mestre/macro de acordo com a Conectividade Dupla de 3GPP.

[0197] O termo “estação base secundária” utilizada nas reivindicações pode ainda ser chamado de estação base escrava, ou eNB secundário/escravo de acordo com a Conectividade Dupla de 3GPP.

[0198] O termo “descarte” é utilizado nas reivindicações e na descrição em conexão com o discardTimer (Temporizador de Descarte) e o descarte de, por exemplo, SDU/PDU de PDCP que devem ser descartadas na expiração do temporizador. Entretanto, “descarte” não deve ser restrito especificamente a apenas exclusão, mas deve ainda ser de forma mais geral entendido como o processo para definir uma SDU/PDU de PDCP como não sendo necessária mais e, assim, conforme definido a ser excluído. Quando a exclusão real ocorre, ela pode ser com base na implementação, por exemplo, pode ser feita por paciente e, assim, basicamente, logo na indicação de uma SDU de PDCP/PDU conforme descartado ou pode ser periódica em uma forma que a cada, por exemplo, 100ms o buffer seja limpo de dados descartados (PDUs/SDUs).

[0199] A seguir, várias realizações exemplares serão explicadas em detalhes. Essas são suportas serem implementadas no amplo relatório descritivo conforme fornecido pelos padrões de 3GPP, com os recursos principais particulares conforme explicado a seguir pertencendo às várias realizações.

[0200] As explicações não devem ser entendidas como limitadoras, mas como um mero exemplo das realizações para melhor entender a presente revelação. Um técnico no assunto deve estar ciente que os princípios gerais da presente revelação conforme estabelecido nas reivindicações podem ser aplicados em diferentes cenários e em formas que não são explicitamente descritas na presente invenção. Correspondentemente, os seguintes cenários assumidos para finalidades explanatórias das várias realizações não devem limitar a invenção como tal.

PRIMEIRA REALIZAÇÃO

[0201] A seguir, um primeiro conjunto de realizações será explicado. Para simplificar a ilustração dos princípios da primeira realização, várias suposições são feitas; entretanto, deve-se observar que essas suposições não devem ser interpretadas como limitadoras do escopo do presente pedido, conforme amplamente definido pelas reivindicações.

[0202] A primeira realização será descrita com referência à figura 24, que é um fluxograma ilustrando as várias etapas, conforme realizado para uma primeira realização particular. Um cenário de conectividade dupla em um ambiente de pequena célula é assumido, onde o UE é conectado a MeNB e SeNB, e pelo menos recebe dados que são encaminhados do SGW ao MeNB, e finalmente através do SeNB ao UE, ou seja, ilustrado exemplarmente na figura 21b, 21c como portador EPS #2. Conforme indicado, o portador EPS #2 pode ser dividido no MeNB de modo que o portador possa ser transmitido através de ambos os eNBs conforme necessário (figura 21c) ou não é dividido no MeNB, mas separadamente encaminhado do portador EPS #1 (figura 21b).

[0203] De acordo com a discussão da pequena célula em 3GPP, diferentes arquiteturas do plano do usuário estavam sob discussão conforme explicado na seção de histórico com referência à figura 22. Para a primeira realização assume-se que a arquitetura do plano do usuário de MeNB e SeNB é tal camada de PDCP com a função de descarte que está localizada no MeNB, mas não no SeNB; além disso, a camada de RLC inferior deve estar localizada no SeNB e pode ou não estar localizada no MeNB. Correspondentemente, a primeira realização atual pode se referir a qualquer uma das arquiteturas do plano do usuário discutidas da figura 22c, 22d, 22e, 22g, 22h, 22i. Nas arquiteturas do plano do usuário da figura 22c (Alternativa 2B) e 22g (Alternativa 3B), onde a camada de PDCP é dividida entre MeNB e SeNB, não está claro quais funções são de fato localizadas no MeNB e quais no SeNB; o que é relevante para a primeira realização é que a funcionalidade de descarte do PDCP está localizada no MeNB e, assim, longe da funcionalidade de descarte da camada de RLC, tornando-a necessária na técnica anterior para ter a comunicação entre camadas que passa entre o MeNB e o SeNB (veja a descrição das limitações, conforme explicado no final da Seção Histórico).

[0204] A funcionalidade de PDCP e RLC, que na primeira realização está respectivamente localizada no MeNB e SeNB, deve permanecer na maioria a mesma, conforme explicado na seção de histórico (por exemplo, com referência à figura 10, 11, 12) e conforme definido pelos padrões atuais de 3GPP; exceto para as seguintes mudanças que se referem à primeira realização. A primeira realização sugere um mecanismo melhorado da funcionalidade de descarte entre o PDCP e camada de RLC, e assim entre o MeNB e o SeNB nos cenários mencionados acima.

[0205] A funcionalidade de descarte na camada de PDCP do MeNB é configurada pelas camadas mais altas do MeNB, como RRC. Assim, o calor do discardTimer no MeNB é configurado e definido pelas camadas mais altas. Deve-se observar que as camadas mais altas que configuram a funcionalidade de descarte no MeNB não estão presentes no SeNB. De acordo com a primeira realização, as camadas mais altas, como RRC, do MeNB devem configurar a funcionalidade de descarte do SeNB sobre a interface X2, para basicamente ter uma funcionalidade de descarte adicional na camada de RLC no SeNB de acordo com a funcionalidade de descarte de PDCP do MeNB.

[0206] No geral, o valor do temporizador de descarte utilizado pela função de descarte no SeNB pode ser idêntico ao valor do temporizador de descarte utilizado pela função de descarte no MeNB. Ou, o valor do temporizador de descarte utilizado pela função de descarte no SeNB é com base no valor do temporizador de descarte utilizado pela função de descarte no MeNB, mas ajustado para compensar os vários atrasos incorridos pelos dados do tempo que atinge a camada de PDCP no MeNB na forma de uma SDU de PDCP para acionar o temporizador de descarte de PDCP até o tempo dos dados atingir a camada de RLC no SeNB na forma de uma PDU de PDCP (também denominada SDU de RLC e excepcionalmente a PDU de RLC em outros casos como aqueles com um RLC dividido como na figura 22e, 22i) para acionar o temporizador de descarte do RLC da primeira realização.

[0207] Uma mensagem de configuração correspondente deve ser transmitida do MeNB ao SeNB que permite que a camada de RLC do SeNB configure um temporizador de descarte correspondente para sua funcionalidade de descarte. A mensagem de configuração pode incluir um valor a ser utilizado pelo SeNB para definir o temporizador de descarte da camada de RLC no SeNB. O valor pode ser o mesmo valor que o utilizado para o temporizador de descarte da função de descarte de PDCP no MeNB, ou pode ser ajustado para outro fator nos vários atrasos dos dados.

[0208] Em mais detalhes, esse atraso total pode ser referido como sendo composto pelo atraso de backhaul que é inerente à tecnologia de comunicação utilizada para o link de backhaul entre o MeNB e o SeNB (como até 60 ms para Acesso DSL) e o atraso do controle de fluxo incorrido para o processamento de dados no MeNB na interface X2 até ser de fato transmitida sobre o backhaul ao SeNB. Esse controle de fluxo pode ser, por exemplo, quando o MeNB não pode transmitir pacotes na interface X2 ao SeNB, pois a interface X2 estava congestionada (muitos UEs, tráfego, etc.) e/ou SeNB teve alguns problemas de capacidade, por exemplo, atraso no processamento, capacidade do buffer ou ainda congestionamento de rádio etc. O atraso do link de backhaul pode ser determinado no MeNB bem como no SeNB visto que é de alguma forma inerentemente estável devido à natureza do link físico entre o MeNB e o SeNB e um dado resultado no backhaul. Por outro lado, o atraso incorrido pelo controle de fluxo de dados pode variar consideravelmente, assim tornando-o difícil de prover um tempo preciso para o atraso do controle de fluxo. Independentemente, é ainda possível para o MeNB e/ou o SeNB determinar um atraso médio ou mínimo do controle de fluxo que pode ser considerado ao determinar o valor do temporizador a ser transmitido na mensagem de configuração ao SeNB para configurar o temporizador de descarte no SeNB.

[0209] Consequentemente, a função de descarte no MeNB e a função de descarte no SeNB sofrem atrasos incorridos, assim resultando em um mecanismo de descarte ineficiente. Isso pode ser evitado pelo ajuste do temporizador para a função de descarte no SeNB de modo que os atrasos sejam compensados. Por exemplo, assumir que o temporizador de descarte no MeNB é definido como 200 ms e o atraso de backhaul é 50 ms, um valor do temporizador mais preciso, e então vantajoso, para o temporizador de descarte (pode ser denominado effective-discardTimer) no SeNB seria 150 ms (assume-se para esse exemplo que o atraso do controle de fluxo é desconsiderado). Tanto o valor na mensagem de configuração já está definido pelo MeNB para 150ms, quanto o valor na mensagem de configuração está definido para 200ms (o valor do temporizador do temporizador de descarte no MeNB) e o próprio SeNB ajusta o valor do temporizador de modo que configure seu próprio temporizador de descarte a ser definido como 150ms.

[0210] Semelhantemente, o effective-discardTimer no SeNB pode adicionalmente (ou alternativamente) - com relação ao ajuste por causa do atraso do link de backhaul - ser ajustado para compensar o atraso do controle de fluxo. Ao assumir que o atraso do controle de fluxo é um mínimo ou média de 20 ms, então o effective-discardTimer no SeNB pode ser definido como 200ms-50ms-20ms (ou 200ms-20ms, se apenas compensar o atraso do controle de fluxo). Tanto o valor na mensagem de configuração já está ajustado quanto a mensagem de configuração inclui o valor do temporizador não ajustado para o temporizador de descarte no MeNB e o próprio SeNB ajusta o valor do temporizador recebido para fator no atraso do controle de fluxo e/ou no atraso do link de backhaul. O SeNB pode saber a quantidade de atraso do controle de fluxo através do link X2 (duração de congestionamento em X2) ou pode determinar o próprio atraso do controle de fluxo, por exemplo, para a duração que para de receber os pacotes através/ de X2 devido a seus próprios problemas de capacidade, por exemplo, atraso no processamento, capacidade do buffer ou ainda congestionamento de rádio etc.

[0211] Correspondentemente, a função de descarte na camada de RLC no SeNB é definida de modo que o temporizador de descarte associado seja iniciado no recebimento de uma PDU de PDCP da camada de PDCP do MeNB e expire após um tempo conforme configurado pelo MeNB/SeNB de acordo com uma das formas acima.

[0212] A implementação exata de como as camadas mais altas no MeNB configuram a função de descarte da camada de RLC no SenB poderia variar. Por exemplo, a transmissão da mensagem de configuração pode ser obtida por meios proprietários, por exemplo, utilizando O&M (operação e manutenção) ou poderia ser especificada na interface X2 utilizando uma mensagem de configuração do tipo RRC na interface X2 que configura a camada de RLC no SeNB. Com essa configuração o SeNB é informado do temporizador de descarte aplicável para cada portador que ele suporta em direção à estação móvel. Essa configuração pode ser provida pela camada de RRC no MeNB ao SeNB através do link X2 ou pode ser configurado por uma camada mais alta em uma entidade de RRC que se ajusta no SeNB através X2 ou utilizando uma interface proprietária e através, por exemplo, de O&M.

[0213] Após definir as funcionalidades de descarte no MeNB e no SeNB, o encaminhamento do pacote será explicado a seguir em conexão com a figura 24. Assume-se que os dados são transmitidos no downlink através do MeNB, SeNB ao UE, e para finalidades exemplares que a arquitetura do plano do usuário da figura 22d ou da figura 22h (Alternativa 2C ou 3C) é utilizada.

[0214] Quando SDU de PDCP é recebida na camada de PDCP das camadas mais altas, o discardTimer de PDCP correspondente é iniciado para a SDU de PDCP e uma PDU de PDCP é gerada da SDU de PDCP de acordo com os mecanismos usuais no PDCP. A PDU de PDCP então gerada é encaminhada à camada de RLC no SeNB através da interface X2. Ainda deve ser observado, entretanto, que a camada de PDCP no MeNB não pode de fato encaminhar a PDU de PDCP à camada de RLC no SeNB em tempo hábil antes do temporizador de descarte no MeNB expirar; isso pode ser devido ao atraso no processamento no MeNB, congestionamento no link X2 etc

[0215] No recebimento da PDU de PDCP na camada de RLC do SeNB (da perspectiva do RLC uma SDU de RLC), o discardTimer correspondente (ou discardTimer efetivo) na camada de RLC é iniciado para a PDU de PDCP recebida. Além disso, a camada de RLC do SeNB processa a SDU de RLC na forma comum para gerar uma ou mais PDUs de RLC, que podem ser enviadas à camada inferior, ou seja, a camada de MAC, para transporte adicional ao UE (não ilustrado na figura 24) para simplicidade.

[0216] Correspondentemente, o temporizador de descarte no MeNB e o temporizador de descarte no SeNB estão operando para os dados na SDU de PDCP.

[0217] Primeiro, assume-se que os dados da SDU de PDCP são com sucesso transmitidos pelo SeNB ao UE. Nesse caso, a camada de RLC no SeNB é informada pelas camadas inferiores no SeNB (por exemplo, MAC) que a(s) PDU(s) de RLC correspondente(s) que carregam os dados da PDU de PDCP foram corretamente recebidas e reconhecidas pelo UE. Correspondentemente, o discardTimer na camada de RLC pode ser parado/interrompido e os dados da PDU de PDCP (ou seja, SDU de RLC) podem ser descartados pela camada de RLC no SeNB. Além disso, a camada de RLC do SeNB informa a camada de PDCP no MeNB sobre a transmissão bem-sucedida da PDU de PDCP ao UE (pela transmissão, por exemplo, de uma Indicação de Entrega Bem-Sucedida, veja abaixo). Por sua vez, a camada de PDCP pode parar/interromper seu próprio temporizador de descarte para a dita PDU de PDCP com sucesso-transmitida (mais precisamente a SDU de PDCP) e, então, pode ainda eventualmente descartar a SDU e PDU de PDCP de PDCP. Como uma consequência, o MeNB terá o discardTimer operando algumas SDUs de PDCP (remanescentes) para as quais não foi informado sobre as PDUs de PDCP correspondentes que foram transmitida com sucessos pelo SeNB ao UE. A expiração de tal discardTimer pode ainda ser indicada pelo MeNB ao SeNB; pois há agora poucos discardTimers operando, a Indicação de Descarte correspondente do MeNB ao SeNB é então apenas enviada para as PDUs de PDCP que não são ainda com sucesso entregues ao UE, ou seja, para as PDUs de PDCP nas quais o UE ainda não transmitiu a Indicação de Entrega Bem-Sucedida de modo que a sinalização na interface X2 será ainda atenuada. Isso evita sinalização de X2 desnecessária por descarte da PDU de PDCP não exigindo indicar o descarte por PDU, mas apenas para as PDUs de PDCP que foram, de fato, não entregues pelo SeNB ao UE.

[0218] Por outro lado, agora assume-se que a camada de RLC no SeNB não poderia transmitir os dados de PDU de PDCP recebidos ao UE por qualquer razão. Nesse caso, os dois temporizadores no MeNB e SeNB eventualmente expirarão. No MeNB, quando o temporizador de descarte iniciado para a SDU de PDCP expirar, a camada de PDCP descarta a SDU de PDCP (associada com o temporizador de descarte expirado) e a PDU de PDCP gerada pela dita SDU de PDCP. Do mesmo modo, na camada de RLC no SeNB, quando o temporizador de descarte iniciado no recebimento da PDU de PDCP (ou seja, SDU de RLC) expirar, a PDU de PDCP recebida deve ser descartada.

[0219] Além disso, em uma implementação vantajosa da primeira realização, a camada de RLC pode, antes de realmente descartar a PDU de PDCP, verificar se os dados da PDU de PDCP (ou qualquer segmento dessa) já foram mapeados em pelo menos uma PDU de RLC, para transmissão ao UE. A fim de não perturbar o mecanismo de transmissão de RLC da camada de RLC para a PDU de PDCP, um descarte da PDU de PDCP na camada de RLC é apenas realizado quando a PDU de PDCP ainda não foi mapeada em uma PDU de RLC (veja a ramificação “Não” na figura 24).

[0220] Conforme está evidente a partir da explicação acima e ao comparar a mesma com o processamento conforme explicado em conexão com a figura 23, uma vantagem é que na expiração do temporizador de descarte de PDCP no MeNB, não é mais necessário indicar o descarte da SDU/PDU de PDCP à camada de RLC (no SeNB), assim atenuando a sinalização no X2 e ainda garantindo que o mecanismo de descarte de fato trabalha mesmo quando o atraso de backhaul no X2 pode ser mais longo / comparável com o valor do temporizador de descarte, pois a camada de RLC no SeNB opera um temporizador separado na sincronização básica com o temporizador de descarte na camada de PDCP do MeNB para permitir o descarte da PDU de PDCP.

[0221] Ainda, não há necessidade de verificação mais se a PDU de PDCP já foi encaminhada à camada de RLC ou não, que assim simplifica o protocolo PDCP no MeNB...

[0222] Detalhes e melhorias adicionais à primeira realização são explicados a seguir.

[0223] Conforme foi explicado anteriormente, a camada de RLC do SeNB pode informar a camada de PDCP no MeNB sobre a transmissão bem-sucedida da PDU de PDCP ao UE. Uma indicação correspondente (chamada a seguir de Indicação de Entrega Bem-Sucedida) informando o MeNB pode ser implementada de várias formas. No geral, o SeNB pode ser configurado pelo MeNB como e quando transmitir tal Indicação de Entrega Bem- Sucedida, ou seja, quando iniciar e parar de informar. Por exemplo, o MeNB pode pedir ao SeNB (em X2) para iniciar a informar a Indicação de Entrega Bem-Sucedida para um portador particular e pode pedir ao SeNB (no X2) para parar de informar os portadores particulares.

[0224] Por exemplo, a Indicação de Entrega Bem- Sucedida poderia ser transmitida continuamente do SeNB ao MeNB, para cada PDU de PDCP que é recebida no SeNB no X2 e é subsequentemente transmitida com sucesso ao UE. Esse termo tem a vantagem que o MeNB será informado assim que possível e o MeNB aprenderá inequivocamente sobre quais PDUs de PDCP foram recebidas pelo UE e quais não. Entretanto, esse tem a vantagem de uma sinalização significante carregada na interface X2. Além disso, nesse caso, se a PDU de PDCP N-1 e N+1 foram com sucesso entregues ao UE, isso é correspondentemente informado como tal ao MeNB; mas, quando assume-se que a PDU de PDCP N ainda não com sucesso entregue ao UE e está ainda em retransmissão de RLC, o MeNB não pode concluir o status da PDU N (realmente descartada no SeNB ou pode ainda ser com sucesso entregue ao UE. Certamente, isso pode não ser o problema significante, pois o MeNB pode reter a PDU de PDCP N até ela receber a Indicação de Entrega Bem- Sucedida para a PDU N também, ou até o Temporizador de Descarte Mestre para a PDU N expirar. Ainda, uma alternativa seria informar o MeNB sobre cada PDU de PDCP recebida na interface X2 e ter a mesma com sucesso entregue ao UE na sequência.

[0225] Alternativamente, o Número de Sequência mais alto entre uma pluralidade dessas PDUs de PDCP entregue com sucessos pode ser transmitida ao MeNB para mitigar a sinalização carregada na interface X2. Entretanto, isso pode ser enganador, conforme será explicado a seguir.

[0226] Assume-se que por uma sequência de 10 PDUs de PDCP com números de sequência 11 a 20, PDUs com números de sequência 13 e 15 são perdidas sendo transmitidas do MeNB ao SeNB, e PDUs com números de sequência 17 e 19 não são transmitidas com sucessos do SeNB ao UE. No caso que uma Indicação de Entrega Bem-Sucedida indica apenas uma última PDU de PDCP transmitida com sucesso com número de sequência 20, o MeNB assumiria que todo SN até 20 foi entregue com sucesso e, assim, descarta-los; uma oportunidade para a retransmissão é então perdida. Tal Indicação de Entrega Bem- Sucedida não indicará quais PDUs de PDCP caíram no X2 (PDUs com SN 13 e 15, no exemplo acima) e fornecerá uma figura incorreta de PDUs de PDCP com um número de sequência menor que o número de sequência mais alto entregue com sucesso que não foram ainda com sucesso recebidos no UE (PDUs com SN 17 e 19 no exemplo acima).

[0227] Entretanto, essa desvantagem pode não ser muito significante visto que o número de PDUs não entregues com sucesso de PDCP deveria ser mínimo de qualquer forma e, assim, sua retransmissão pode cuidada por outras camadas mais altas (por exemplo, TCP), se necessário. No entanto, para superar essa desvantagem, a Indicação de Entrega Bem-Sucedida incluindo o número de sequência mais alto entre uma pluralidade de PDUs de PDCP entregues com sucesso (não informadas antes), pode ser melhorado incluindo o(s) número(s) de sequência da(s) PDU(s) de PDCP que poderiam não ser transmitidas pelo SeNB com sucesso ao UE. Por exemplo, supondo que as PDUs de PDCP 101-200 ainda estão no buffer do MeNB (PDUs de PDCP 0-100 já foram informadas pelo SeNB), a Indicação de Entrega Bem-Sucedida pode então indicar o ACK_SN = 150 e adicionalmente NACK_SN1 = 140, NACK_SN2=145. Em resposta a essa Indicação de Entrega Bem-Sucedida, o MeNB descartaria as PDUs de PDCP com números de sequência 101-150, exceto para aqueles com números de sequência 140 e 145. Conforme será explicado posteriormente, uma melhoria adicional então permitiria que o MeNB decidisse se ou não transmitir as PDUs de PDCP 140 e 145 diretamente ao UE (veja abaixo em conexão com figura 25 e 26).

[0228] Como outra alternativa, a Indicação de Entrega Bem-Sucedida pode compreender um bitmap, de acordo com o qual ACK_SN está incluído para a PDU de PDCP mais recente ou mais antiga ainda não informada que foi entregue com sucesso ao UE com a informação de 1 bit para cada PDUs de PDP subsequentes ou precedentes. Por exemplo, a Indicação de Entrega Bem-Sucedida pode ser composto como segue:

[0229] Começando com a PDU de PDCP mais antiga que foi entregue com sucesso E o sucesso da entrega para essa PDU não foi indicado ao MeNB antes; e

[0230] Finalizando com a PDU de PDCP entregue com sucesso mais recentemente.

[0231] Todas as PDUs entregues com sucesso são indicadas por “1” e outras por “0”; ou vice-versa.

[0232] Essa alternativa pode causar menos sinalização de X2 do que as alternativas anteriores, entretanto, podem se tornar ineficiente visto que uma atualização de um relatório anterior pode se tornar necessário. Por exemplo, uma PDU de PDCP particular foi informada que não foi transmitida com sucesso (no momento da Indicação de Entrega Bem-Sucedida anterior), mas no meio tempo foi transmitida com sucesso, com o resultado que o bitmap subsequente da Indicação de Entrega Bem-Sucedida inclui parte da mesma informação que a primeira Indicação de Entrega Bem-Sucedida.

[0233] Outras possibilidades poderiam combinar uma ou mais das alternativas anteriores para a Indicação de Entrega Bem-Sucedida, por exemplo, indicando a PDU de PDCP mais antiga (ou mais recente) que foi entregue com sucesso (ou não entregue com sucesso) e adicionalmente transmitir um bitmap correspondente, conforme apresentado acima.

[0234] Longe do formato e conteúdo da Indicação de Sucesso da Entrega, o tempo para quando a Indicação de Entrega Bem-Sucedida é transmitida do SeNB ao MeNB deve ser definido e pode ser, por exemplo, um dos seguintes.

[0235] Evento Acionado, por exemplo, com base nos eventos como:

[0236] Receber o Relatório de Status (RLC) no SeNB do UE;

[0237] MeNB pedindo a Indicação de Sucesso da Entrega (por exemplo, quando os buffers de MeNB estão excedendo um certo nível, temporizador com base etc.)

[0238] Tamanho do Bitmap é fixo e o bitmap é completamente utilizado (de modo que se o bitmap tem um tamanho 'n' então 'n' é o número de informação de feedback da PDU de PDCP que está sendo de fato carregada)

[0239] De modo alternativo ou adicional, a Indicação de Entrega Bem-Sucedida pode ser transmitida periodicamente, onde a periodicidade pode ser, por exemplo, configurável.

[0240] Outra melhoria adicional será explicada em conexão com as figuras 25 e 26, que são diagramas esquematicamente que ilustram as várias etapas realizadas no SeNB, MeNB e UE focando na melhoria adicional que será explicada a seguir. Deve-se observar que as figuras 25 e 26 são simplificadas para melhor ilustrar a melhoria adicional. De acordo com essa melhoria, o MeNB é provido com a possibilidade de adicionalmente transmitir uma PDU de PDCP diretamente ao UE, no caso o SeNB não continua a transmissão dessa PDU de PDCP ao UE, por exemplo, utilizando a janela de tempo entre a expiração do temporizador secundário no SeNB e a expiração do Temporizador mestre no MeNB para uma transmissão direta ao UE. Conforme explicado antes em conexão com a Primeira Realização, o Temporizador secundário no SeNB pode ser configurado de modo que fatore em alguns - mas na realidade nem todos - dos atrasos incorridos pela PDU de PDCP que atinge o SeNB e aciona o Temporizador secundário (quando comparado ao valor do Temporizador mestre acionado pela recepção da SDU de PDCP). Consequentemente, o Temporizador secundário deve expirar antes do Temporizador mestre correspondente no MeNB para a mesma SDU/PDU de PDCP.

[0241] Em mais detalhes, assume-se que o MeNB ainda monitora o tempo conforme configurado para o temporizador secundário no SeNB, de modo que o MeNB sabe em qual tempo o temporizador secundário no SeNB para uma PDU particular de PDCP expirará. Além disso, o MeNB pode ainda fatorar no tempo que a Indicação de Entrega Bem-Sucedida acontece para atingir o MeNB, de modo que o tempo monitorado no MeNB precisa ser um bit mais longo para poder receber a Indicação de Entrega Bem-Sucedida correspondente do SeNB; em outras palavras, o MeNB sabe qual tempo uma Indicação de Entrega Bem-Sucedida para uma PDU particular de PDCP deveria ter sido recebida por último. Nas figuras 25 e 26, qualquer uma das variantes acima é delimitada como “Temporizador secundário para SN_X expirou?”. Em uma implementação, o MeNB inicia o monitoramento do tempo do Temporizador secundário ao transmitir a PDU de PDCP (SN_X) ao SeNB, conforme exemplificado nas figuras 25 e 26. Em qualquer caso, o MeNB monitora o valor de tempo do Temporizador secundário, que termina antes do Temporizador mestre para a PDU de PDCP expirar. Em outra implementação não mostrada nas figuras, o MeNB monitora o valor do temporizador do Temporizador mestre (considerando os vários atrasos), para determinar em qual tempo do Temporizador mestre o Temporizador secundário provavelmente terá expirado.

[0242] A figura 25 mostra o caso onde o SeNB pode transmitir com sucesso a PDU de PDCP ao UE. Correspondentemente, o SeNB transmite uma Indicação de Entrega Bem-Sucedida ao MeNB com relação à PDU de PDCP e descarta a PDU de PDCP correspondente. O MeNB no recebimento da Entrega com Sucesso para o Temporizador mestre correspondente para a SDU de PDCP (SN_X) e descarta a SDU/PDU de PDCP (SN_X). A figura 26 mostra o caso inverso onde o SeNB não pode transmitir com sucesso a PDU de PDCP ao UE. Consequentemente, o Temporizador secundário no SeNB para a PDU de PDCP (SN_X) expira eventualmente e o SeNB descarta a PDU de PDCP (SN_X); correspondentemente, nenhuma Indicação de Entrega Bem-Sucedida é transmitida pelo SeNB ao MeNB para essa PDU de PDCP. Conforme explicado para essa melhoria, o MeNB ainda monitora o tempo conforme configurado para o Temporizador secundário no SeNB (com o possível ajuste para os atrasos incorridos pela Indicação de Entrega Bem-Sucedida a ser recebida no MeNB), e assim, sabe quando o MeNB deveria ter recebido por último a Indicação de Entrega Bem-Sucedida para a PDU de PDCP (SN_X). Quando o MeNB determina que uma Indicação de Entrega Bem-Sucedida não fio nem será mais recebida do SeNB (“Temporizador secundário para SN_X? YES) e antes do Temporizador mestre expirar (ou seja, o Temporizador mestre ainda está operando e não expirou), o MeNB pode decidir transmitir diretamente a PDU de PDCP (SN_X) ao UE. Brevemente depois, o Temporizador mestre no MeNB para essa PDU de PDCP (SN_X) expirará ou será parado pelo MeNB, e a SDU de PDCP (SN_X) correspondente e PDU de PDCP (SN_X) serão descartadas no MeNB.

[0243] Alternativamente, a Indicação de Entrega Bem-Sucedida pode incluir o NACK_SN(s) de PDUs de PDCP, em resposta ao qual o MeNB pode decidir transmitir as PDUs de PDCP correspondentes ao UE.

[0244] Para essa melhoria ser mais vantajosa, o Temporizador mestre deve ser menor que o temporizador de reorganização do valor do PDCP no UE. Se não for o caso, ou seja, a reorganização do temporizador no UE é configurada menor que o Temporizador mestre no MeNB, então as transmissões diretas pelo MeNB podem ser recebidas após a reorganização do temporizador para PDU expirar no UE, cujo caso o UE, mesmo após receber o pacote com sucesso, descartará simplesmente. Entretanto, visto que o MeNB está configurando a reorganização do temporizador ao UE (ou se o mesmo é especificado), MeNB pode garantir que o Temporizador mestre é menor que o temporizador de reorganização que opera no UE.

[0245] Para essa melhoria é vantajoso, embora não estritamente necessário, se a Indicação de Entrega Bem- Sucedida é transmitida ao MeNB em um curto período de tempo após transmitir com sucesso a PDU de PDCP ao UE. Caso contrário, visto que o MeNB não receberá a Indicação de Entrega Bem-Sucedida até aproximadamente o momento em que Temporizador secundário expira, o MeNB pode assumir de forma errada que o SeNB não poderia transmitir a PDU de PDCP ao UE e, em consequência transmitirá em sua própria PDU de PDCP ao UE (veja figura 26). Em qualquer caso, o UE deveria ser preparado para descartar PDUs de PDCP duplicadas, caso tenha recebido a mesma PDU de PDCP de ambos eNBs (SeNB e MeNB)

[0246] Para uma melhoria adicional da primeira realização, que pode ser considerada como uma alternativa (ou adição) à melhoria anterior, conforme explicado em conexão com as figuras 25 e 26, uma Indicação de Descarte entre o SeNB e o MeNB é sugerida, que informará o MeNB sobre qualquer PDU de PDCP que não foi transmitida com sucesso pelo SeNB ao UE. Novamente, o SeNB pode ser configurado pelo MeNB como e quando transmitir tal Indicação de Descarte, ou seja, quando iniciar e parar o relatório. Por exemplo, o MeNB pode pedir ao SeNB (no X2) para iniciar a informar a Indicação de Descarte para um portador particular e pode pedir ao SeNB (no X2) para parar de informar o(s) portador(es) particular(es).

[0247] Um exemplo dessa melhoria será explicado a seguir com referência à figura 27. Assume-se que SeNB no recebimento de uma PDU de PDCP do MeNB inicia um Temporizador secundário para a PDU de PDCP recebida. Na expiração do Temporizador secundário, o SeNB descarta a PDU de PDCP (SDU de RLC), aborta a transmissão (por exemplo, se a dita PDU de PDCP já não foi mapeada em uma PDU de RLC) e informa o MeNB sobre o descarte, por exemplo, utilizando uma Indicação de Descarte conforme explicado a seguir. O MeNB em resposta pode decidir transmitir a PDU de PDCP ao UE caso o Temporizador Mestre ainda esteja operando para essa PDU de PDCP; isso provavelmente será o caso, em vista do que o Temporizador secundário expira antes do Temporizador mestre quando é configurado para ajustar alguns, mas nem todos os vários atrasos incorridos entre o acionamento do Temporizador mestre e o acionamento do Temporizador secundário.

[0248] O SeNB pode ainda decidir descartar uma PDU particular de PDCP, antes da expiração do temporizador secundário, por exemplo, quando a PDU particular de PDCP já foi (re)transmitida muitas vezes pelo RLC do SeNB.

[0249] A Indicação de Descarte conforme utilizada nessa melhoria pode ser implementada de várias formas, similar à acima que introduziu a Indicação de Entrega Bem-Sucedida. Por exemplo, a Indicação de Descarte pode ser transmitida do SeNB ao MeNB para cada PDU de PDCP que não poderia ser transmitida com sucesso ao UE (por exemplo, no qual o Temporizador secundário expirou ou onde o número máximo de retransmissões foi atingido). Esse termo tem a vantagem que o MeNB será informado assim que possível (e, assim, antes da expiração do Temporizador mestre correspondente no MeNB), e o MeNB inequivocamente aprenderá sobre quais PDUs de PDCP não foram recebidas pelo UE. A sinalização carregada na interface X2 provavelmente não será muito alta, considerando que tal Indicação de Descarte do SeNB ao MeNB será apenas necessária para um número muito pequeno de PDUs de PDCP (na ordem de 106 após a retransmissão de RLC).

[0250] Com relação à quando enviar a Indicação de Descarte, há ainda várias implementações, algumas das quais já foram discutidas com relação à Indicação de Entrega Bem-Sucedida. Por exemplo, a transmissão da Indicação de Descarte pode ser acionada por evento, por exemplo, quando pelo menos um Temporizador secundário para uma PDU de PDCP expirar ou quando o número de entregas bem-sucedidas exceder um certo limite como a cada 50 entregas bem-sucedidas; (o SeNB pode enviar uma Indicação de Descarte ao MeNB contendo 1 ACK_SN e zero ou mais NACK_SN(s)). Alternativamente, a transmissão da Indicação de Descarte pode ser periódica; nesse tipo de relatório uma Indicação de Descarte é permitida para indicar descarte NULO, quando nenhuma das PDUs de PDCP são descartadas no SeNB (ou seja, todas as PDUs de PDCP nesse período de relatório foram transmitidas com sucesso ao UE antes do Temporizador secundário correspondente expirar). Esse descarte NULO pode ser indicado, por exemplo, incluindo apenas o 1 ACK_SN conforme previamente descrito ou com a ajuda de um campo especial indicando, por exemplo, que todas as PDUs recebidas no X2 foram entregues até o momento.

[0251] No entanto, ainda outras implementações da Indicação de Descarte e quando a transmitir são possíveis se considerado apropriado, como aquelas discutidas para a Indicação de Entrega Bem-Sucedida (por favor, consulte a explicação acima, por exemplo, com relação ao número de sequência mais alto).

[0252] Em resumo, o MeNB pode realizar uma retransmissão diretamente ao UE se considerado vantajoso (efetivamente, isso pode ser feito apenas se o Temporizador mestre ainda estiver operando; a PDU de PDCP ainda está disponível no MeNB). O PDCP do EU deve descartar a PDU de PDCP duplicada, para os casos onde é recebida a mesma PDU de PDCP do SeNB e do MeNB. Assim, a DPU de PDCP pode ser adicionalmente retransmitida ao UE utilizando um atraso de link mais curto, quando necessário.

[0253] A Indicação de Descarte pode ser enviada periodicamente pelo SeNB ao MeNB, mesmo para indicar apenas um ACK_SN e zero ou mais NACK_SN(s), para permitir um apuramento do tempo do buffer de PDCP do MeNB.

[0254] A fim de evitar envio desnecessário da Indicação de Descarte ao MeNB, um Novo Disparo de Consulta pode ser utilizado pelo SeNB e pelo UE. O novo Disparo de Consulta deveria estar associado com a expiração do Temporizador secundário (por exemplo, logo antes ou após o mesmo) ou qualquer outro mecanismo de descarte no SeNB (por exemplo, com base no contador de entrega, conforme explicado antes). A consulta é feita incluindo um biy de Consulta e no recebimento da Consulta, o UE deve imediatamente enviar pelo Relatório de Status de RLC ao SeNB. Correspondentemente, o SeNB ainda atualiza a Indicação de Descarte com base nessa informação, por exemplo, não envia a Indicação de Descarte para as PDUs de PDCP que são agora confirmadas como recebidas no UE com base no Relatório de Status de RLC consultado.

[0255] O mecanismo de descarte, conforme explicado acima em conexão com a figura 24 pode se tornar ainda mais preciso provendo a camada de RLC no SeNB com informação de registro de hora referente à SDU/PDU de PDCP como segue. De acordo com uma opção, quando a SDU de PDCP é recebida na camada de PDCP do MeNB e aciona o temporizador de descarte correspondente no PDCP para essa SDU de PDCP, um registro de hora é gerado indicando o tempo de recepção da SDU de PDCP; por exemplo, temporizador do GPS, hora UTC, número de frame, número de subframe etc. Correspondentemente, quando a PDU de PDCP (gerada dessa SDU de PDCP) é transmitida à camada de RLC no SeNB, esse registro de hora gerado (referente à SDU/PDU de PDCP) é ainda provido ao SeNB. Por exemplo, a informação de registro de hora pode ser incluída no cabeçalho da PDU de PDCP correspondente encaminhada sobre a interface X2 ao SeNB. No recebimento da informação de registro de hora e da PDU de PDCP, a camada de RLC pode determinar exatamente quando o temporizador de descarte na camada de PDCP expirará com base no valor do temporizador de descarte do SeNB previamente configurado (especialmente quando configurado o mesmo que o temporizador de descarte na camada de PDCP do MenB) e a informação do tempo de recepção recebida do registro de hora.

[0256] De acordo com outra opção, a informação de registro de hora pode incluir informação sobre quanto tempo resta antes do temporizador de descarte de PDCP expirar e, assim, acionar a camada de PDCP para descartar a SDU e PDU de PDCP. O conteúdo do registro de hora difere com base em qual entidade gera o registro de hora e em qual momento. Por exemplo, no caso 76 ms resta para o temporizador de descarte antes da expiração no tempo que o protocolo X2 recebe o pacote do MeNB. Essa informação está incluída no registro de hora. Novamente, essa informação é provida à camada de RLC no SeNB e, assim, pode ser utilizada pelo SeNB para determinar o ponto exato no tempo quando o temporizador de descarte na camada de RLC do SeNB deve descartar a PDU de PDCP recebida.

[0257] Como um resultado, o mecanismo de descarte configurado na camada de RLC do SeNB pode ser ainda mais precisamente sincronizado com o temporizador de descarte da camada de PDCP de MeNB. Nesse caso particular, não é mais necessário ajustar o temporizador de descarte da camada de RLC de SeNB de alguma forma menor que o valor do temporizador de descarte do temporizador de descarte de PDCP de MeNB para compensar os atrasos envolvidos para transmitir os dados da SDU de PDCP do MeNB ao SeNB. Ao invés disso, o temporizador de descarte na camada de RLC de SeNB pode ser definido como exatamente o mesmo valor que o temporizador de descarte na camada de PDCP de MeNB.

[0258] De acordo com a melhoria adicional que poderia ser utilizada junto ou ou alternativamente à acima, o MeNB é motivado para transmitir portadores / pacotes associados com um curto temporizador de descarte, ao invés de transmitir tais pacotes através do SeNB e, assim, incorrer o atraso do link de backhaul/congestionamento. Isso poderia prover uma entrada fundamental ao selecionar quais portadores / pacotes devem ser servidos pelo MeNB ou SeNB. Em particular, quando os links de comunicação como portadores são estabelecidos entre o MeNB, SeNB e o UE, portadores associados com pacotes tendo um pequeno valor do temporizador de descarte são estabelecidos pelo MeNB diretamente com o UE (ou seja, não passando através do SeNB), enquanto que outros portadores podem ser estabelecidos entre o MeNB e o UE ou entre o MeNB, SeNB e UE na forma comum.

SEGUNDA REALIZAÇÃO

[0259] A segunda realização lida com o mesmo problema que a primeira realização, entretanto provê de alguma forma uma solução diferente e alternativa conforme será explicado em conexão com a figura 28. Basicamente, as mesmas suposições são feitas em conexão com a primeira realização explicada acima. Em particular, um cenário de conectividade dupla em um ambiente de pequena célula é assumido, onde o UE é conectado ao MeNB e ao SeNB, e pelo menos recebe dados que são encaminhados do SGW ao MeNB, e finalmente através do SeNB ao UE, ou seja, ilustrado exemplarmente nas figuras 21b, 21c como portador EPS #2. Conforme indicado, o portador EPS #2 pode ser dividido no MeNB de modo que o portador pode ser transmitido através de ambos eNBs conforme necessário (figura 21c) ou não é dividido no MeNB, mas separadamente encaminhado do portador EPS #1 (figura 21b).

[0260] De acordo com a discussão da pequena célula em 3GPP, diferentes arquiteturas do plano do usuário estavam em discussão conforme explicado na seção de histórico com referência à figura 22. Para a segunda realização assume- se que a arquitetura do plano do usuário de MeNB e SeNB é de modo que a camada de PDCP com a função de descarte está localizada no MeNB, mas não no SeNB; além disso, a camada de RLC inferior deve estar localizada no SeNB e pode ou não estar localizada no MeNB. Correspondentemente, a presente segunda realização pode referir a qualquer uma das arquiteturas do plano do usuário discutidas da figura 22c, 22d, 22e, 22g, 22h, 22i. Nas arquiteturas do plano do usuário da figura 22c (Alternativa 2B) e 22g (Alternativa 3B), onde a camada de PDCP é dividia entre o MeNB e o SeNB, não está claro quais funções estão de fato localizadas no MeNB e qual função no SeNB; o que é relevante para a segunda realização é que a funcionalidade de descarte do PDCP está localizada no MeNB e, assim, longe da funcionalidade de descarte da camada de RLC, tornando-a necessária na técnica anterior para ter comunicação entre camadas que passa entre o MeNB e o SeNB (veja a descrição do problema)...

[0261] A funcionalidade de PDCP e RLC, que na primeira realização está respectivamente localizada no MeNB e SeNB, deve permanecer a mesma conforme explicado na seção de histórico (por exemplo, com referência à figura 10, 11, 12) e conforme definido pelos padrões atuais de 3GPP; exceto para as seguintes mudaças que se referem à segunda realização. Ainda, a segunda realização sugere um mecanismo melhorado da funcionalidade de descarte entre o PDCP e a camada de RLC, ou seja, entre MeNB e SeNB.

[0262] Como na técnica anterior e para a primeira realização, a camada de PDCP no MeNB implementa um mecanismo de descarte que permite o descarte dessas SDUs de PDCP (e PDUs de PDCP correspondentes), cuja transmissão não é mais necessária, pois o temporizador de PDCP correspondente expirou. Entretanto, diferente do mecanismo de descarte da técnica anterior e similar à primeira realização, o mecanismo de descarte na camada de PDCP do MeNB de acordo com a segunda realização não verifica se uma PDU de PDCP foi encaminhada à camada de RLC e não indica o descarte da SDU de PDCP à camada inferior, RLC, no SeNB. Além disso, para simplificar o SeNB, um mecanismo de descarte separado conforme sugerido pela primeira realização não é implementado no SeNB.

[0263] Assim, quando a camada de PDCP no MeNB recebe uma SDU de PDCP, ela iniciará um temporizador de descarte correspondente para a dita SDU de PDCP e ainda processará a SDU de PDCP na forma comum para gerar uma PDU de PDCP, que então será encaminhada à camada de RLC do SeNB para transmissão adicional ao UE. Quando a camada de RLC do SeNB recebe a PDU de PDCP através da interface X2 da camada de PDCP no MeNB, ela não iniciará particularmente e o temporizador de descarte adicional como com a primeira realização, mas apenas continuará com a operação normal de RLC de segmentação, concatenação de dados recebidos nas PDUs de RLC, que são então encaminhados às camadas inferiores (por exemplo, MAC) para transmissão adicional. Ainda, a camada de RLC no SeNB não terá a funcionalidade para receber uma indicação da camada de PDCP no MeNB para descartar uma PDU de PDCP previamente recebida. Como uma consequência, mesmo se o temporizador de descarte de PDCP expirou no MeNB, a camada de RLC continuará seu processo comum de gerar PDU(s) de RLC para transmissão ao UE. Assim, ainda pode ser que a camada de RLC informará à camada de PDCP na recepção com sucesso do MeNB no UE, para PDUs de PDCP que já foram descartadas pela camada de PDCP no MeNB.

[0264] Certamente, a camada de RLC pode ou não ter outro temporizador de descarte interno (diferente do temporizador da primeira realização) garantindo que o RLC no SeNB não tentará encaminhar com sucesso encaminhar os dados da PDU de PDCP recebidos (na forma de uma ou mais PDUs de RLC) ao UE por um longo período até realmente atingir o sucesso.

[0265] Conforme exemplarmente ilustrado na figura 28, a camada de RLC no SeNB terá rotinas normais para limpar os seus buffers descartando as PDUs de PDCP (ou seja, SDUs de RLC, e possivelmente as PDUs de RLC) que foi transmitida com sucesso ao UE e, assim, não precisar ser mantidas para uso posterior.

[0266] Esse mecanismo de descarte da segunda realização é simples de um ponto de vista de implementação e, assim, permite tornar o SeNB mais simples e menos caro, pois não precisa controlar os vários temporizadores simultaneamente (especialmente para aplicações de alta taxa de dados), um por PDU de PDCP e ainda visto que RLC agora tem o mesmo comportamento para todas as PDUs de PDCP que recebe no X2. A segunda realização ainda tem a vantagem de não exigir a sinalização por pacote (PDU de PDCP) para informar o temporizador de descarte ao SeNB e ainda qualquer configuração/ reconfiguração de tal funcionalidade/ valor do temporizador é evitada. Ainda, uma verificação correspondente no MeNB, para ser os dados já foram encaminhados à camada de RLC de SeNB ou não, não é mais necessária.

[0267] Uma melhoria para a segunda realização permite a possibilidade do MeNB transmitir a PDU de PDCP diretamente ao UE, para cobrir o caso que o SeNB não pôde transmitir a PDU de PDCP com sucesso ao UE (por exemplo, antes da expiração de um temporizador de descarte interno; similar à melhoria para a primeira realização descrita em conexão com a figura 25 e 26). Conforme já explicado para a segunda realização, a camada de RLC informará à camada de PDCP no MeNB a transmissão bem-sucedida das PDUs de PDCP ao UE. Isso pode ser feito de forma similar conforme descrito para a primeira realização com relação à Indicação de Entrega Bem-Sucedida. Assim, é abstido a partir dos vários possíveis formatos, conteúdos e exemplos de transmissão possíveis para tal Indicação de Entrega Bem-Sucedida; certamente, é aqui referido às passagens correspondentes para a primeira realização que são igualmente aplicáveis para informar pela camada de RLC no SeNB a camada de PDCP do MeNB sobre uma transmissão bem-sucedida de uma (ou mais) PDUs de PDCP ao UE.

[0268] De acordo com essa melhoria da segunda realização, o MeNB determina se ou não uma Indicação de Entrega Bem-Sucedida correspondente foi recebida para uma PDU particular de PDCP até um certo ponto no tempo (mas antes da expiração do Temporizador mestre correspondente no MeNB para essa mesma PDU de PDCP). No caso em que a Indicação de Entrega Bem-Sucedida não foi recebida no MeNB até esse certo ponto no tempo, pode devidir transmitir a PDU de PDCP ao UE diretamente.

TERCEIRA REALIZAÇÃO

[0269] A terceira realização lida com uma melhoria ao processamento de EU e, assim, pode ser implementada independentemente ou adicionalmente à primeira e à segunda realização.

[0270] Tipicamente, o link do SeNB terá latência mais alta visto que o pacote enviado do UE ao SeNB terá que passar ao MeNB através da interface X2, passando assim pelo menos pela latência do link de backhaul. Isso se aplica menos ao modo de conectividade dupla da figura 21b onde os diferentes portadores são servidos por diferentes eNBs; mas no modo de conectividade dupla da figura 21c, o mesmo portador #2 é servido por eNBs, de modo que alguns pacotes do portador são enviados através do MeNB e outro através do SeNB no uplink e downlink. A decisão através de qual rota o pacote deverá ser enviado pode, por exemplo, depender da carga no tempo real, situação do rádio, etc.

[0271] De acordo com a terceira realização, a decisão pelo UE se transmitir uma PDU de PDCP diretamente ao MeNB ou transmitir o pacote ao SeNB (para ser encaminhado ao MeNB) deve considerar o temporizador de descarte na camada de PDCP do UE.

[0272] O EU pode não saber sobre a latência nominal do link de backhaul e/ou atraso do controle de fluxo entre MeNB e SeNB. Essa informação pode ser sinalizada pela rede diretamente ao UE, ou o UE pode tentar estimar esse valor sobre um período, por exemplo, observando a diferença no tempo de recepção de, por exemplo, PDUs de PDCP subsequentes recebidas através de diferentes nós. Uma média de tal diferença deveria representar o atraso nominal de backhaul e o UE pode utilizar esse valor, vantajosamente com alguma permissão para um erro de estimativa.

[0273] Assim, o UE tem a informação necessária sobre o atraso de backhaul (opcionalmente ainda o atraso do controle de fluxo).

[0274] Em particular, o UE poderia, por exemplo, decidir utilizar as oportunidades de transmissão no Macro link ao MeNB para pacotes que já sofreram um atraso mais longo (por exemplo, devido a paralisação da janela, falta de concessão ou outras razões).

[0275] O UE compara o tempo de descarte remanescente para uma PDU de PDCP contra o atraso de backhaul e/ou atraso do controle de fluxo e decide transmitir aPDU de PDCP diretamente ao MeNB para evitar o desvio através do SeNB no caso o tempo de descarte remanescente ser comparável ou menor que o atraso do link de backhaul e/ou atraso do controle de fluxo.

[0276] Ou, o UE pode decidir não transmitir os pacotes mo link do SeNB ao SeNB no caso do tempo remanescente de descarte ser comparável ou menor que o atraso do link de backhaul (opcionalmente além do atraso do controle de fluxo; veja a discussão acima para a primeira realização).

[0277] Consequentemente, se não houver oportunidade/concessão de transmissão disponível no macro link, então o UE pode guardar uma oportunidade / concessão de transmissão disponível no macro link para transmitir a PDU de PDCP e pode ter então que descartar a PDU de PDCP na expiração do temporizador de descarte no caso em que a oportunidade / concessão de transmissão no macro link estava disponível no tempo.

QUARTA REALIZAÇÃO

[0278] Ainda, a quarta realização melhora a funcionalidade de descarte da camada de PDCP, em casos onde o PDCP mecanismo de descarte está localizada no SeNB. Em conexão com a primeira realização, o effectivediscardTimer da camada de RLC no SeNB foi explicado compensando os vários atrasos incorridos por um pacote de dados sendo transmitido do MeNB ao SeNB.

[0279] Semelhantemente, a quarta realização sugere utilizar um effectivediscardTimer para a funcionalidade de descarte de PDCP no SeNB. Consequentemente, quando as camadas mais altas do MeNB configuram a funcionalidade de descarte da camada de PDCP no SeNB, um valor do temporizador de descarte será determinado compensando o(s) atraso(s), como o atraso do link de backhaul e o atraso do controle de fluxo (veja a primeira realização para explicação de atraso do link de backhaul e atraso do controle de fluxo).

[0280] Certamente, essa quarta realização se aplica às arquiteturas do plano do usuário onde a camada de PDCP e, em particular, o mecanismo de descarte, está localizada no SeNB também; como Alternativa 2A e 3A (veja a figura 22b e 22f) e possivelmente as Alternativas 2B e 3B no caso em que a camada de PDCP no SeNB (não no MeNB) inclui a funcionalidade de descarte (veja a figura 22c e 22g).

[0281] Para os modos de conectividade dupla onde um portador é serivdo por SeNB e MeNB e a arquitetura do plano do usuário correspondente, uma camada de PDCP está localizada no MeNB bem como no SeNB (veja a figura 3A). De acordo com a presente quarta realização, o temporizador de descarte na camada de PDCP do MeNB para o portador particular é diferente (ou seja, valor do temporizador mais alto) que o temporizador de descarte na camada de PDCP do SeNB para o mesmo portador particular; ou seja, o valor do temporizador de descarte na camada de PDCP do SeNB é inferior pela quantidade de atraso que deverá ser considerada, por exemplo, o atraso do link de backhaul e/ou o atraso do controle de fluxo.

[0282] Essa tem a vantagem que o pacote atraso no X2 é anulado devido ao backhaul lento e/ou ao atraso do controle de fluxo que significa que a funcionalidade de descarte em PDCP funciona exatamente conforme desejado e o descarte de PDCP acontece na mesma linha do tempo (como em MeNB) da camada mais alta/ perspectiva da aplicação. Se o temporizador de descarte no SeNB tem o mesmo valor que em MeNB, então a Camada de Acesso continuará tentando transmitir o pacote mesmo quando a camada mais alta/ aplicação já parar de esperar.

QUINTA REALIZAÇÃO

[0283] Essa quinta realização tem uma diferente abordagem para a funcionalidade de descarte da camada de PDCP no MeNB. Como com a primeira realização, um Temporizador secundário é configurado no SeNB (por exemplo, de acordo com uma da pluralidade de variantes reveladas em conexão com a primeira realização descrita acima). Por outro lado, a camada de PDCP não tem temporizador mestre definido, contrário às realizações anteriores; consequentemente, a camada de PDCP não aciona o Temporizador mestre no recebimento de uma SDU de PDCP.

[0284] O mecanismo de descarte no MeNB é controlado por uma Indicação de Descarte recebida do SeNB, informando o MeNB sobre a PDU de PDCP (e seu SN) que não poderia ser entregue com sucesso pelo SeNB ao UE. A Indicação de Descarte e várias implementações dessa já foram discutidas em detalhes em conexão com uma melhoria da primeira realização e não serão completamente repetidas aqui, pois é aplicável à essa quinta realização na mesma forma.

[0285] Consequentemente, no recebimento de uma Indicação de Descarte para uma ou mais PDUs de PDCP particulares, o MeNB pode deduzir qual delas foram ou não corretamente recebidas pelo UE. Correspondentemente, o MeNB pode descartar as PDUs de PDCP nessa base e não precisa mais do Temporizador mestre para as SDUs de PDCP.

[0286] Por exemplo, a Indicação de Descarte do SeNB pode ser implementada como incluindo o número de sequência mais alto de PDUs de PDCP entregue com sucessos ao UE, por exemplo, além de NACK SNs dessas PDUs de PDCP que poderiam ser entregues com sucessos ao UE.

[0287] Alternativamente, a Indicação de Descarte pode ser implementada utilizando um bitmap, exemplarmente como segue. O bitmap inicia com a PDU de PDCP descartada mais velha para a qual o “Temporizador secundário” expirou E o descarte para essa PDU não foi indicado ao MeNB antes E outro tempo (por exemplo, denominado ReportingTimerA) não expirou. Esse ReportingTimerA pode ser iniciado com o Temporizador secundário e tem um valor menor que o temporizador de renderização do PDCP do EU, mas mais alto que o Temporizador secundário. O ReportingTimerA deve controlar o tempo da transmissão do bitmap da Indicação de Descarte. O bitmap da Indicação de Descarte termina com a PDU de PDCP Descartada mais recentemente, ou seja, para a qual o Temporizador secundário expirou. Todas as PDUs descartadas no bitmap podem ser indicadas por “1 “ e todas entregue com sucessos por “0”, ou vice-versa.

[0288] Ao invés de utilizar um bitmap, a Indicação de Descarte ainda poderia ser uma lista de PDUs descartadas de PDCP (por exemplo, NACK SN(s)) para a qual o Temporizador secundário expirou, mas não o ReportingTimerA E o descarte para essa PDU foi indicado ao MeNB antes. Em um outro exemplo, um ACK_SN da PDU de PDCP mais alta entregue com sucesso é adicionalmente informada ao MeNB, de modo que o MeNB possa limpar seu buffer corretamente. O SeNB então informaria ao MeNB que os NACK_SN(s) com um ACK_SN da PDU de PDCP mais alta entregue com sucesso.

[0289] O envio da Indicação de Descarte pode ser acionado por qualquer evento, como a expiração de pelo menos um Temporizador secundário, ou pode ser periódico.

[0290] Como uma melhoria adicional (similar à melhoria da primeira realização correspondente, veja figura 27), o MeNB pode, no recebimento da Indicação de Descarte, decidir se ou não transmitir diretamente a PDU de PDCP, que não foi transmitida com sucesso ao UE pelo SeNB, ao UE. Isso tem a vantagem de uma retransmissão adicional feita pelo MeNB no lugar do SeNB para a PDU de PDCP, para a qual a transmissão ao UE feita pelo SeNB falhou.

[0291] Isso é descrito na figura 29, que ilustra que o mecanismo de descarte no MeNB está operando sem um temporizador mestre, mas principalmente com base na Indicação de Descarte recebida do SeNB. Por exemplo, no caso em que o MeNB recebe a Indicação de Descarte indicando um NACK para PDU de PDCP SN_X; em resposta o MeNB pode descartar as PDUs de PDCP até SN= X-1. O MeNB pode então decidir transmitir diretamente a PDU de PDCP SN_X ao UE e fazendo isso com sucesso pode ainda descartar a PDU de PDCP com SN_X.

[0292] Implementação de Hardware e Software da presente revelação

[0293] Outras realizações exemplares se refere à implementação das várias realizações descritas acima utilizando hardware e software. Nessa conexão, um equipamento do usuário (mobile terminal) e a eNodeB (estação base) são providos. O equipamento de usuário é adaptado para realizar os métodos aqui descritos.

[0294] É ainda reconhecido que as várias realizações podem ser implementadas ou realizadas utilizando dispositivos de computação (processadores). Um dispositivo de computação ou processador pode, por exemplo, ser processadores para fins gerais, processadores de sinal digital (DSP), circuitos integrados específicos de aplicação (ASIC), matrizes de campo de portas programáveis (FPGA) ou outros dispositivos lógicos programáveis, etc. As várias realizações podem ainda ser realizadas ou incorporadas por uma combinação desses dispositivos.

[0295] Ainda, as várias realizações podem ainda ser implementadas por meios de módulos de software, que são executados por um processador ou diretamente em hardware. Ainda, uma combinação dos módulos de software e uma implementação de hardware podem ser possíveis. Os módulos de software podem ser armazenados em qualquer tipo de meios de armazenamento legíveis por computador, por exemplo RAM, EPROM, EEPROM, memória flash, registros, discos rígidos, CD- ROM, DVD, etc.

[0296] Deve ser observado que os recursos individuais das diferentes realizações podem individualmente ou em combinação arbitrária ser assunto em outra realização.

[0297] Seria observado por um técnico no assunto que as variações e/ou modificações podem ser feitas à presente revelação, conforme mostrado nas realizações específicas. As presentes realizações são, então, consideradas em todos os aspectos como ilustrativas e não restritivas.

Claims (8)

1. ESTAÇÃO BASE MESTRE CONFIGURADA PARA ENCAMINHAR PACOTES DE DADOS DESTINADOS A UMA ESTAÇÃO MÓVEL, caracterizada por ser conectável tanto à estação base mestre, quanto a uma estação base secundária, via estação base secundária para a estação móvel, compreendendo: um transmissor que, em operação, encaminha pacotes de dados como PDU de PDCP (Protocolo de Controle de Pacote de Dados, Unidades de Protocolo de Dados) para uma camada RLC (Controle de Link de Rádio) da estação base secundária; e um receptor que, em operação, recebe uma indicação da estação base secundária, a indicação sendo para um portador particular e incluindo uma primeira informação na PDU de PDCP encaminhada pela estação base mestre e entregue com sucesso pela estação base secundária à estação móvel, e uma segunda informação no PDU de PDCP encaminhada pela estação base mestre e entregue sem sucesso pela estação base secundária à estação móvel, em que a primeira informação inclui apenas um número de sequência mais elevado do PDU de PDCP entregue com sucesso pela estação base secundária à estação móvel, em que a estação base mestre remove, a partir de um buffer da estação base mestre, PDU de PDCP armazenado em buffer até o número de sequência mais elevado dos PDUs de PDCP, exceto pelos PDUs de PDCP entregues sem sucesso à estação móvel, de acordo com a primeira informação no número de sequência mais elevado de PDU de PDCP entregue com sucesso à estação móvel e de acordo com a segunda informação.

2. ESTAÇÃO, de acordo com a reivindicação 1, caracterizada pela segunda informação incluir uma lista de números de sequência dos PDUs de PDCP que não foram entregues com sucesso à estação móvel.

3. ESTAÇÃO DE BASE SECUNDÁRIA CONFIGURADA PARA ENCAMINHAR PACOTES DE DADOS RECEBIDOS DE UMA ESTAÇÃO BASE MESTRE E DESTINADOS A UMA ESTAÇÃO MÓVEL PARA A ESTAÇÃO MÓVEL, caracterizada por ser conectável tanto à estação base mestre, quanto à estação base secundária, compreendendo: um receptor que, em operação, recebe, em uma camada RLC (Controle de Link de Rádio) da estação base secundária, pacotes de dados como PDU de PDCP (Protocolo de Controle de Pacote de Dados, Unidades de Protocolo de Dados) da estação base mestre; um controlador que, em operação, gera uma indicação que é para um portador particular e inclui uma primeira informação na PDU de PDCP recebida da estação base mestre e entregue com sucesso pela estação base secundária à estação móvel, e uma segunda informação na PDU de PDCP recebida da estação base mestre e entregue sem sucesso pela estação base secundária à estação móvel; e um transmissor que, em operação, transmite a indicação para a estação base mestre, em que a primeira informação inclui apenas um número de sequência mais elevado da PDU de PDCP entregue com sucesso pela estação base secundária à estação móvel, em que a estação base secundária remove, a partir de um buffer da estação base secundária, PDU de PDCP armazenado em buffer até o número de sequência mais elevado dos PDUs de PDCP, exceto pelos PDUs de PDCP entregues sem sucesso à estação móvel, de acordo com a primeira informação no número de sequência mais elevado de PDU de PDCP entregue com sucesso à estação móvel e de acordo com a segunda informação.

4. ESTAÇÃO, de acordo com a reivindicação 3, caracterizada pela segunda informação incluir uma lista de números de sequência dos PDUs de PDCP que não foram entregues com sucesso à estação móvel.

5. MÉTODO IMPLEMENTADO EM UMA ESTAÇÃO BASE MESTRE PARA ENCAMINHAR PACOTES DE DADOS DESTINADOS A UMA ESTAÇÃO MÓVEL, que é conectável tanto à estação base mestre, quanto a uma estação base secundária, via estação base secundária para a estação móvel, caracterizado por compreender: encaminhar pacotes de dados como PDU de PDCP (Protocolo de Controle de Pacote de Dados, Unidades de Protocolo de Dados) a uma camada RLC (Controle de Link de Rádio) da estação base secundária; e receber uma indicação da estação base secundária, a indicação incluindo uma primeira informação na PDU de PDCP encaminhada pela estação base mestre e entregue com sucesso pela estação base secundária à estação móvel, e uma segunda informação na PDU de PDCP encaminhada pela estação base mestre e entregue sem sucesso pela estação base secundária à estação móvel, em que a primeira informação inclui apenas um número de sequência mais elevado da PDU de PDCP entregue com sucesso pela estação base secundária à estação móvel, em que o método compreende ainda: remover, a partir de um buffer da estação base mestre, PDU de PDCP armazenada em buffer até o número de sequência mais elevado dos PDUs de PDCP, exceto pelos PDUs de PDCP entregues sem sucesso à estação móvel, de acordo com a primeira informação no número de sequência mais elevado de PDU de PDCP entregue com sucesso à estação móvel e de acordo com a segunda informação.

6. MÉTODO, de acordo com a reivindicação 5, caracterizada pela segunda informação incluir uma lista de números de sequência dos PDUs de PDCP que não foram entregues com sucesso à estação móvel.

7. MÉTODO IMPLEMENTADO EM UMA ESTAÇÃO BASE SECUNDÁRIA PARA ENCAMINHAR PACOTES DE DADOS RECEBIDOS DE UMA ESTAÇÃO BASE MESTRE E DESTINADOS A UMA ESTAÇÃO MÓVEL PARA UMA ESTAÇÃO MÓVEL, que é conectável tanto à estação base mestre, quanto à estação base secundária, caracterizado por compreender: receber, em uma camada RLC (Controle de Link de Rádio) da estação base secundária, pacotes de dados como PDU de PDCP (Protocolo de Controle de Pacote de Dados, Unidades de Protocolo de Dados) da estação base mestre; gerar uma indicação, que é para um portador particular e incluir uma primeira informação na PDU de PDCP recebida da estação base mestre e entregue com sucesso pela estação base secundária à estação móvel, e uma segunda informação na PDU de PDCP recebida da estação base mestre e entregue sem sucesso pela estação base secundária à estação móvel; e transmitir a indicação para a estação base mestre, em que a primeira informação inclui apenas um número de sequência mais elevado da PDU de PDCP entregue com sucesso pela estação base secundária à estação móvel, em que o método compreende ainda: remover, a partir de um buffer da estação base secundária, PDU de PDCP armazenada em buffer até o número de sequência mais elevado dos PDUs de PDCP, exceto pelos PDUs de PDCP entregues sem sucesso à estação móvel, de acordo com a primeira informação no número de sequência mais elevado de PDU de PDCP entregue com sucesso à estação base móvel e de acordo com a segunda informação.

8. MÉTODO, de acordo com a reivindicação 7, caracterizada pela segunda informação incluir uma lista de números de sequência dos PDUs de PDCP que não foram entregues com sucesso à estação móvel.