BR112016021655B1 - Método em um nó para uma rede celular, método em um equipamento de usuário, nó para uma rede celular, e, equipamento de usuário para suportar mobilidade na rede de celular - Google Patents

Abstract

OTIMIZAÇÃO DE ROBUSTEZ DE MOBILIDADE EM UMA REDE CELULAR. Trata-se de um método em um nó, eNB, de uma rede celular para suportar mobilidade, um método em um equipamento de usuário para suportar mobilidade na rede celular, e dispositivos correspondentes, a saber, equipamento de usuário e nó. De acordo com um aspecto, um método para suportar mobilidade em uma rede celular é fornecido. O método é executado em um nó, eNB, para a rede celular. De acordo com o método, o nó recebe, a partir de um equipamento de usuário, informações de uma falha de link de rádio de um link de rádio entre o equipamento de usuário e a rede celular, e o nó recebe informações relacionadas a uma mobilidade, por exemplo, expiração do temporizador T312, do equipamento de usuário. Com base nas informações recebidas, o nó ajusta pelo menos um parâmetro de mobilidade para aumentar a robustez de mobilidade. A presente invenção aprimora a robustez das funções de mobilidade em uma rede celular.

Description

CAMPO DA TÉCNICA

[001] Trata-se de um método em um nó em uma rede celular para suportar a mobilidade, de um método em um equipamento de usuário para suportar a mobilidade na rede celular, e de dispositivos correspondentes.

FUNDAMENTOS

[002] Em uma rede celular típica, também chamada de sistema de comunicação sem fio, os Equipamentos de Usuário (UEs), se comunicam por meio de uma Rede de Acesso de Rádio (RAN) a uma ou mais Redes de Núcleo (CNs).

[003] Um equipamento de usuário é um terminal móvel através do qual um assinante pode acessar os serviços oferecidos por uma rede de núcleo do operador. Os equipamentos de usuário podem, por exemplo, ser dispositivos de comunicação como telefones móveis, telefones celulares, computadores do tipo laptop ou tablet, algumas vezes chamados de placas de navegação, com capacidade sem fio. Os equipamentos de usuário podem ser portáteis, armazenáveis no bolso, de mão, compreendidos em computador, ou dispositivos móveis montados em veículo, habilitados para comunicar voz e/ou dados, por meio da rede de acesso de rádio, com outra entidade, como outra estação móvel ou servidor.

[004] Os equipamentos de usuário são habilitados para se comunicar de modo sem fio na rede celular. A comunicação pode ser realizada, por exemplo, entre dois equipamentos de usuário, entre um equipamento de usuário e um telefone comum e/ou entre o equipamento de usuário e um servidor por meio da rede de acesso de rádio e, possivelmente, uma ou mais redes de núcleo, compreendidas na rede celular.

[005] A rede celular cobre uma área geográfica que é dividida em áreas de célula. Cada área de célula servida por uma estação base, por exemplo, uma Estação base de Rádio, RBS, que algumas vezes pode ser chamada de, por exemplo, “eNB”, “eNodeB”, “NodeB”, “nó B”, ou BTS (Estação Transceptora Base), dependendo da tecnologia e terminologia usadas.

[006] As estações base podem ser de classes diferentes como, por exemplo, macro eNodeB, eNodeB domiciliar ou estação base pico, com base na potência de transmissão e, assim, também no tamanho de célula.

[007] Uma célula é a área geográfica em que a cobertura de rádio é fornecida pela estação base em um sítio de estação base. Uma estação base, situada no sítio de estação base, pode servir uma ou várias células. Adicionalmente, cada estação base pode suportar uma ou várias tecnologias de comunicação. As estações base se comunicam através da interface aérea que opera em radiofrequências com os equipamentos de usuário dentro do alcance das estações base.

[008] Em algumas redes de acesso de rádio, várias estações base podem ser conectadas, por exemplo, por linhas terrestres ou micro-ondas, a um controlador de rede de rádio, por exemplo, um Controlador de Rede de Rádio (RNC) no Sistema de Telecomunicações Móvel Universal (UMTS), e/ou entre si. O controlador de rede de rádio, também chamado algumas vezes de Controlador de Estação base (BSC), por exemplo, em GSM, pode supervisionar e coordenar várias atividades das várias estações base conectadas ao mesmo. GSM é uma abreviação para Sistema Global para Comunicações Móveis (originalmente: Groupe Spécial Mobile).

[009] Na Evolução de Longo Prazo (LTE) do Projeto de Parceria da 3a Geração (3GPP), estações base, que podem ser chamadas de eNodeBs ou eNBs, podem ser conectadas diretamente a uma ou mais redes de núcleo.

[0010] UMTS é um sistema de comunicação móvel de terceira geração, 3G, que evoluiu a partir do sistema de comunicação móvel GSM de segunda geração, 2G, e é destinado a fornecer serviços de comunicação móvel aprimorados com base na tecnologia de acesso Banda Larga de Acesso Múltiplo por Divisão de Código (WCDMA). A Rede de Acesso de Rádio Terrestre de UMTS (UTRAN) é, essencialmente, uma rede de acesso de rádio que usa banda larga de acesso múltiplo por divisão de código para os equipamentos de usuário. A proposta do 3GPP é evoluir adicionalmente as tecnologias de rede de acesso de rádio à base de UTRAN e GSM.

[0011] As redes de comunicação de telefonia celular evoluem para taxas de dados superiores, juntamente com cobertura e capacidade aprimoradas. No 3GPP, tecnologias de corpo de padronização como GSM, HSPA e LTE foram e são atualmente desenvolvidas.

[0012] Para proporcionar mobilidade na rede celular, a rede celular deve realizar várias funções de mobilidade como handovers quando o equipamento de usuário se move de uma célula para outra. Um handover significa que há uma mudança da célula de serviço para o equipamento de usuário a partir de uma assim chamada célula-fonte para uma assim chamada célula-alvo. Existem mecanismos na rede celular para identificar quais células são células-alvo candidatas para handover. Tipicamente, o equipamento de usuário realiza com regularidade medições para monitorar quais células fornecem cobertura em sua localização atual. O resultado de medição é enviado para uma estação base de serviço da célula-fonte nos assim chamados relatórios de medição. Esses relatórios de medição podem ser usados para disparar um handover para a célula-alvo no devido tempo antes de o equipamento de usuário se mover para fora da cobertura da célula-fonte.

[0013] Se o handover for disparado de modo muito precoce, o equipamento de usuário pode não ter a capacidade de se conectar à célula- alvo e há uma alta probabilidade de handovers oscilantes.

[0014] Se o handover for disparado muito tarde, a estação base de serviço da célula-fonte pode não receber o relatório de medição usado para o disparo de handover, ou o equipamento de usuário pode não ter a capacidade de receber um comando de handover a partir da estação base de serviço da célula-fonte. Devido a isso, o handover pode não ser realizado, o que pode levar eventualmente à saída do equipamento de usuário da cobertura da célula-fonte, detectando uma falha de link de rádio e perdendo sua conexão de link de rádio à rede celular, fazendo com que, por exemplo, uma chamada em curso ou uma transferência por download termine prematuramente.

[0015] Em redes heterogêneas, estações base de alta potência e estações base de baixa potência com o uso da mesma frequência são implementadas na mesma área de modo que sua cobertura, ou células, na rede celular se sobreponham.

[0016] Particularmente, em tais ambientes muitos handovers podem ocorrer.

[0017] Em vista do supracitado, há uma necessidade de aprimorar a robustez das funções de mobilidade em uma rede celular, em particular a robustez dos handovers.

SUMÁRIO

[0018] De acordo com uma modalidade da invenção, um método para suportar a mobilidade em uma rede celular é fornecido. O método é para uso em um nó para a rede celular. De acordo com o método, o nó recebe a partir de um equipamento de usuário, informações de uma falha de link de rádio de um link de rádio entre o equipamento de usuário e a rede celular e o nó recebem informações relacionadas a uma mobilidade do equipamento de usuário. Com base nas informações recebidas, o nó ajusta pelo menos um parâmetro de mobilidade para aumentar a robustez de mobilidade.

[0019] De acordo com uma modalidade adicional, um método em um equipamento de usuário para suportar mobilidade em uma rede celular é fornecido. De acordo com o método, o equipamento de usuário detecta uma falha de um link de rádio entre o equipamento de usuário e a rede celular; o equipamento de usuário envia para um nó da rede celular, informações da falha de link de rádio de um link de rádio entre o equipamento de usuário e a rede celular; e o equipamento de usuário envia informações relacionadas a uma mobilidade do equipamento de usuário para o nó.

[0020] De acordo com uma modalidade adicional, um nó para uma rede celular suportar mobilidade na rede celular é fornecido. O nó compreende pelo menos uma interface; e pelo menos um processador. O pelo menos um processador é configurado para receber a partir de um equipamento de usuário, informações de uma falha de link de rádio de um link de rádio entre o equipamento de usuário e a rede celular, para receber informações relacionadas a uma mobilidade do equipamento de usuário, e com base nas informações recebidas, ajustar pelo menos um parâmetro de mobilidade para aumentar a robustez da mobilidade.

[0021] De acordo com uma modalidade adicional, um equipamento de usuário para suportar mobilidade em uma rede celular é fornecido. O equipamento de usuário compreende pelo menos uma interface e pelo menos um processador. O pelo menos um processador é configurado para detectar uma falha de um link de rádio entre o equipamento de usuário e a rede celular, para enviar para um nó da rede celular informações de uma falha de link de rádio de um link de rádio entre o equipamento de usuário e a rede celular, e para enviar informações relacionadas a uma mobilidade do equipamento de usuário ao nó.

[0022] De acordo com uma modalidade adicional, um programa de computador ou um produto de programa de computador é fornecido, o qual compreende um código de programa a ser executado por pelo menos um processador de um nó para uma rede celular, em que a execução do código de programa faz com que o pelo menos um processador realize etapas do método em um nó para uma rede celular suportar mobilidade.

[0023] De acordo com uma modalidade adicional, um programa de computador ou um produto de programa de computador é fornecido, o qual compreende um código de programa a ser executado por pelo menos um processador de um equipamento de usuário, em que a execução do código de programa faz com que o pelo menos um processador realize etapas do método em um equipamento de usuário para suportar mobilidade em uma rede celular.

[0024] Detalhes de tais modalidades e modalidades adicionais serão evidentes a partir das seguintes descrições detalhadas das modalidades.

BREVE DESCRIÇÃO DOS DESENHOS

[0025] A Figura 1 mostra um diagrama de sinalização para ilustrar esquematicamente um exemplo de um procedimento de handover.

[0026] A Figura 2 mostra potências de sinal recebido e regiões de handover em um cenário de rede celular exemplificativo.

[0027] A Figura 3 mostra um diagrama de temporização para ilustrar esquematicamente um exemplo de um procedimento para detectar uma falha de link de rádio na base de temporizadores.

[0028] A Figura 4A mostra um diagrama de sinalização para ilustrar esquematicamente um exemplo de relatório de informações entre um UE e uma rede celular.

[0029] A Figura 413 mostra um diagrama de sinalização para ilustrar esquematicamente um exemplo de indicação de uma falha de link de rádio de um nó para o outro.

[0030] A Figura 4C mostra um diagrama de sinalização que ilustra esquematicamente um exemplo de relatório de um handover.

[0031] A Figura 5 mostra extrações de um código de ASN da Especificação Técnica TS 36.331, V12.0.0 do 3GPP.

[0032] A Figura 6 mostra um diagrama de sinalização para ilustrar esquematicamente um cenário exemplificativo que tem função(ões) de Otimização de Robustez de Mobilidade, MRO.

[0033] A Figura 7 ilustra esquematicamente uma arquitetura de rede exemplificativa, em que os conceitos da invenção podem ser aplicados.

[0034] A Figura 8 mostra um fluxograma para ilustrar um método, de acordo com uma modalidade da invenção, que pode ser implantado em uma rede celular.

[0035] A Figura 9A mostra extrações de um código de ASN para ilustrar uma modalidade da invenção.

[0036] A Figura 913 mostra extrações de um código de ASN para ilustrar uma modalidade da invenção.

[0037] A Figura 9C mostra extrações de um código de ASN de TS 36.331, V12.0.0 do 3GPP.

[0038] A Figura 10 mostra um fluxograma para ilustrar um método, de acordo com uma modalidade da invenção, que pode ser usado para implantar uma função de suporte de mobilidade em um nó de uma rede celular.

[0039] A Figura 11 mostra um fluxograma para ilustrar um método, de acordo com uma modalidade da invenção, que pode ser usado para implantar uma função de suporte de mobilidade em um equipamento de usuário.

[0040] A Figura 12 ilustra, esquematicamente, estruturas exemplificativas de um nó para uma rede celular, de acordo com uma modalidade da invenção.

[0041] A Figura 13 ilustra, esquematicamente, estruturas exemplificativas de um equipamento de usuário, de acordo com uma modalidade da invenção.

[0042] A Figura 14 mostra uma tabela que descreve um temporizador T312.

[0043] A Figura 15 mostra potências de sinal recebido e regiões de handover em uma rede celular exemplificativa e proporciona exemplos de manipulação de falhas de link de rádio, de acordo com as modalidades da invenção.

DESCRIÇÃO DETALHADA

[0044] Na descrição a seguir, para propósitos de explicação e sem limitação, os detalhes específicos são estabelecidos como arquiteturas particulares, interfaces, técnicas, etc. a fim de fornecer um entendimento completo de vários conceitos da invenção. No entanto, será evidente àqueles versados na técnica vários conceitos que podem ser praticados em outras modalidades que se afastam desses detalhes específicos. Isto é, os indivíduos versados na técnica serão capazes de inferir várias disposições que, embora não sejam descritas ou mostradas explicitamente no presente documento, incorporam os conceitos desta revelação. Em alguns exemplos, as descrições detalhadas de dispositivos, circuitos e métodos bem conhecidos são omitidas de modo a não obscurecer a descrição da revelação com detalhes desnecessários. Todas as afirmações no presente documento que enumeram princípios, aspectos e modalidades, bem como exemplos específicos dos mesmos, são destinadas a abranger equivalentes tanto estruturais como funcionais dos mesmos. Adicionalmente, pretende-se que tais equivalentes incluam tanto os equivalentes conhecidos atualmente como os equivalentes desenvolvidos no futuro, isto é, quaisquer elementos desenvolvidos que realizem a mesma função, independente da estrutura.

[0045] Os conceitos ilustrados se referem ao suporte de mobilidade e/ou robustez de mobilidade em uma rede celular. Especificamente, os conceitos se referem ao suporte de handovers e robustez de handover em uma rede celular. A rede celular pode, por exemplo, ter por base uma ou mais tecnologias de rádio, por exemplo, uma tecnologia de rádio de telefone celular como a tecnologia de LTE. Embora os exemplos explicados a seguir se refiram a uma rede celular com base na tecnologia de LTE, deve ser compreendido que os conceitos ilustrados também poderiam ser aplicados com outras tecnologias de comunicação, por exemplo, outras tecnologias de rádio de telefonia celular, como a tecnologia de UMTS (Sistema de Telecomunicações Móvel Universal), ou uma tecnologia de rádio de WiFi, ou até mesmo tecnologias à base de fio.

[0046] Para otimizar a robustez de mobilidade em uma rede celular, os parâmetros de handover podem ser definidos e adaptados para as circunstâncias locais para os handovers entre cada uma das células. A Otimização de Robustez de Mobilidade (MRO) foi introduzida em 3GPP para automatizar uma configuração dinâmica dos parâmetros de handover. De acordo com conceitos discutidos no presente documento, propõe-se estender tal funcionalidade, por exemplo, para combinar informações de falha do procedimento de handover e o procedimento de falha de link de rádio para adotar com precisão os parâmetros de handover a fim de otimizar a robustez de mobilidade.

[0047] A mobilidade em redes de celular é subsequentemente discutida: A discussão se refere em determinadas partes ao contexto de LTE, isto é, E-UTRAN. Deve ser compreendido que os problemas e soluções descritos no presente documento são igualmente aplicáveis a redes de acesso sem fio e equipamentos de usuário (UEs) que implantam outros padrões e tecnologias de acesso. A LTE é usada como uma tecnologia exemplificativa em que as modalidades são adequadas, e com o uso da LTE na descrição é, portanto, particularmente útil para a compreensão do problema e soluções que resolvam o problema.

[0048] A especificação de protocolo Controle de Recurso de Rádio de LTE do 3GPP, RRC, especificação de protocolo como TS 36.331 V12.0.0 do 3GPP define um protocolo de sinalização principal para configurar, reconfigurar e manipulação de conexão geral na rede de acesso de rádio de LTE que também é conhecida como UTRAN. O RRC controla muitas funções como instalação da conexão, mobilidade, medições, falha de link de rádio e recuperação de conexão. Essas funções são de relevância para a presente revelação, e são, portanto, descritas em alguns detalhes adicionais abaixo.

[0049] Um UE na LTE pode estar em dois estados de RRC: RRC_CONNECTED e RRC_IDLE. No estado RRC_CONNECTED, a mobilidade é controlada pela rede com base, por exemplo, nas medições fornecidas pelo UE. Isto é, a rede decide quando e em qual célula um UE deve realizar o handover, com base, por exemplo, nas medições fornecidas pelo UE. A rede, isto é, a estação base de rádio de LTE (chamada de eNB em E-UTRAN) configura vários eventos de medição, limitares, etc. com base nos quais o UE envia, então, relatórios para a rede, de modo que a rede possa fazer uma decisão sensata de realizar o handover do UE para uma célula com maior intensidade conforme o UE se move na direção oposta à presente célula.

[0050] Em RRC_IDLE, a mobilidade é gerenciada pela seleção de célula à base de UE, em que um UE nômade seleciona a “melhor” célula para se estabelecer, com base, por exemplo, em vários critérios e parâmetros especificados que são difundidos nas células. Por exemplo, várias células ou camadas de frequência poderiam ser priorizadas em relação a outras, de modo que o UE tente se estabelecer em uma célula desde que a qualidade medida de um radiofarol ou piloto naquela célula seja um limite melhor do que algum outro radiofarol ou piloto recebido de outras células.

[0051] A presente revelação está focando principalmente em problemas associados à mobilidade controlada por rede conforme descrito acima, isto é, para um UE de LTE no estado RRC_CONNECTED. Os problemas associados à falha de handovers são descritos em maiores detalhes abaixo.

[0052] Em uma situação normal, e quando um UE de RRC_CONNECTED estiver se movendo para fora da cobertura de uma primeira célula (também chamada de célula-fonte), deve-se realizar handover do mesmo para uma célula vizinha (também chamada de célula-alvo ou segunda célula) antes de perder a conexão para a primeira célula. Isto é, é desejável que a conexão seja mantida sem ou com perturbação mínima durante todo o handover, de modo que o usuário final não esteja ciente do handover em curso. Para ser bem sucedido com isso, é necessário que o relatório de medição que indica a necessidade por mobilidade seja transmitido pelo UE e recebido pelo eNB Fonte, e o eNB Fonte tem tempo suficiente para preparar o handover para a célula-alvo (solicitando-se, dentre outras coisas, um handover a partir do eNB Alvo que controla a célula-alvo), e o UE recebe a mensagem de comando de handover a partir da rede, conforme preparado pelo eNB Alvo em controle da célula-alvo e enviado por meio da célula-fonte para o UE.

[0053] A Figura 1 mostra um diagrama de sinalização que ilustra esquematicamente um exemplo de um procedimento de handover, em que se realiza um handover do UE 101 a partir de um eNB Fonte 102 para um eNB Alvo 103. O procedimento ilustrado é uma ilustração simplificada de um procedimento de handover de LTE, HO. Deve ser notado que um comando de HO 104 é, na realidade, preparado no eNB Alvo 103, mas a mensagem é transmitida por meio do eNB Fonte 102, isto é, o UE 101 nota que a mensagem é proveniente do eNB Fonte 102.

[0054] Além disso, e para o handover ser bem sucedido, é preciso que o UE 101, finalmente, consiga estabelecer uma conexão com a célula-alvo, que no LTE requer uma solicitação de acesso aleatório bem sucedida na célula-alvo, e uma mensagem completa de HO subsequente. (Deve ser notado que as especificações podem diferir de alguma forma na nomeação das mensagens. Isso não limita a aplicabilidade da presente revelação).

[0055] Portanto, é evidente que para conseguir tudo isso, é necessário que a sequência de eventos que levam a um handover bem sucedido seja iniciada com antecipação suficiente, de modo que o link de rádio para a primeira célula (através do qual essa sinalização acontece) não deteriore demais antes da conclusão da sinalização. Se tal deterioração acontecer antes de a sinalização de handover ser concluída na célula-fonte (isto é primeira célula), então é provável que o handover falhe. Tais falhas de handover são claramente não desejáveis. A especificação de RRC atual fornece, portanto, vários disparadores, temporizadores e limiares a fim de configurar adequadamente as medições, de modo que a necessidade por handovers possa ser detectada de modo confiável, e com antecipação suficiente.

[0056] Na Figura 1, um relatório de medição 105 exemplificado é disparado por um evento de medição 106 (por exemplo, assim chamado de evento A3: em suma: Nota-se que uma célula vizinha é um desvio melhor do que a célula de serviço atual). Deve ser notado que existem múltiplos eventos que podem disparar um relatório.

[0057] Pode ocorrer que um UE perde cobertura para célula à qual o UE está atualmente conectado. Isso poderia ocorrer em uma situação em que um UE entra em um declive de desvanecimento, ou que um handover foi necessário conforme descrito acima, mas o handover falhou por um ou outro motivo. Isso é particularmente verdade se a “região de handover” for muito pequena. Monitorando-se constantemente a qualidade de link de rádio, por exemplo, na camada física conforme descrito em TS 36.300 V12.0.0 e TS 36.331 V12.0.0 do 3GPP, o próprio UE tem a capacidade de declarar uma falha de link de rádio e iniciar autonomamente um procedimento de restabelecimento de RRC. Se o restabelecimento for bem-sucedido (o que depende, dentre outras coisas, de se a célula selecionada e o eNB que controla aquela célula foram preparados para manter a conexão ao UE), então a conexão entre o UE e o eNB pode ser retomada. Uma falha de um restabelecimento significa que o UE vai para RRC_ IDLE e a conexão é liberada. Para continuar a comunicação, uma nova conexão de RRC deve, então, ser solicitada e estabelecida.

[0058] Os conceitos relacionados a handover e robustez de falha de link de rádio são discutidos a seguir: A aceitação rápida e recente de Banda Larga Móvel levou a uma necessidade de aumentar a capacidade das redes de telefonia celular. Uma solução para alcançar tal aumento de capacidade é usar redes mais densas que consiste em várias “camadas” de células com “tamanhos” diferentes: As macrocélulas asseguram uma grande cobertura com células que abrangem áreas grandes, enquanto micro-, pico- e até mesmo femtocélulas são implementadas em áreas de ponto de acesso em que existe uma grande demanda por capacidade. Aquelas células fornecem, tipicamente, conectividade em uma área muito menor, mas adicionando células adicionais (e estações base de rádio que controlam aquelas células) a capacidade é aumentada conforme as novas células descarregam as macros.

[0059] As diferentes “camadas” de células podem ser implementadas na mesma portadora (isto é, em um modo reuse-1), as células pequenas poderiam ser implementadas em uma portadora diferente, e as células diferentes nas várias camadas poderiam até mesmo ser implementadas com o uso de tecnologias diferentes (por exemplo, 3H/HSPA na macro- e micro- camada, e LTE na pico-camada como um exemplo não exclusivo).

[0060] Atualmente, há um grande interesse em investigar o potencial de tais Redes Heterogêneas, e operadores estão interessando em tais implementações. Entretanto, constatou-se também que tais Redes Heterogêneas podem resultar em uma taxa maior de falhas de handover, conforme discutido brevemente acima. Um motivo é que a região de handover nas Redes Heterogêneas pode ser muito curta, significando que o handover pode falhar visto que o UE perdeu cobertura para a célula-fonte antes de o handover para uma célula-alvo poder ser concluído. Por exemplo, quando um UE deixa uma pico-célula, pode acontecer de a margem de cobertura da pico ser tão definida, que o UE não recebe qualquer comando de handover para uma macro antes de perder cobertura para a pico. Consulte a Figura 2 para explicação adicional. A Figura 2 mostra Potência Recebida de Sinal de Referência (RSRP) para handovers entre Macro e Pico.

[0061] Em particular, a Figura 2 mostra potências de sinal recebido (RSRP) como uma função da distância em um cenário de rede celular exemplificativo. O cenário de rede celular compreende uma macro estação base 201, uma pico estação base 202, e uma macro estação base adicional 203. As curvas 204, 205 e 206 mostram a RSRP que um UE recebe a partir da macro estação base 201, pico estação base 202 e macro estação base 203, respectivamente, como uma função da distância a partir do respectivo nó. Uma região de handover 207 para um handover entre macro estação base 201 e pico estação base 202 e uma região de handover 208 para um handover entre a macro estação base 201 e a macro estação base 203 são indicadas na Figura 2.

[0062] Um problema também poderia ocorrer quando um UE conectado a uma macro subitamente entrar em uma pico na mesma portadora: Agora poderia acontecer de os canais de controle da pico interferirem com os sinais que o UE precisa receber a partir da macro a fim de completar o handover, e o handover, desse modo, falha.

[0063] A fim de investigar as consequências das falhas de handover aumentadas e soluções para atenuar as mesmas, 3GPP está trabalhando atualmente em avaliações e soluções técnicas para emendas, como descrito em TR 36.839 V11.1.0 do 3GPP.

[0064] Os conceitos de monitoramento de link de rádio, RLM, são discutidos subsequentemente: Para detectar falhas de link de rádio (RLFs) o UE pode implantar um mecanismo de monitoramento de link de rádio (RLM), que é descrito em TS 36.331 V12.0.0 do 3GPP. Os parâmetros de RLM são configurados por RRC. Para esse propósito o UE avalia o link de rádio e mediante indicações consecutivas de "fora de sincronismo" por N310 recebidas a partir das camadas inferiores (consulte TR 36.133 V12.2.0 do 3GPP para detalhes), o UE inicia o temporizador T310. O temporizador pode ser interrompido mediante as indicações consecutivas de "em sincronismo" por N311. Após a expiração de T310 o UE declarará a RLF a ser detectada e iniciará o procedimento de restabelecimento de RRC. Uma falha de link de rádio detectada durante o procedimento de handover leva a uma anulação do procedimento de handover, isto é, o handover não é bem sucedido.

[0065] A Figura 3 ilustra esquematicamente um exemplo de detecção de uma falha de link de rádio com base nos temporizadores. Mediante a detecção de um problema de PHY (Camada Física) um temporizador de RLF T310 é iniciado, consulte o ponto 301. Mediante a expiração de T312, um procedimento de restabelecimento pode ser iniciado, consulte o ponto 302. Quando T310 estiver em execução após um evento de medição 303 e um Tempo para Disparo subsequente (TTT) 304 o temporizador de RLF de handover T312 é iniciado. Mediante a expiração um procedimento de restabelecimento pode ser iniciado até mesmo antes de o temporizador de RLF T310 ter expirado, consulte o ponto 305.

[0066] Subsequentemente, a recuperação de RLF Rápida com temporizador T312 de RLF de Handover em Rel-12 do 3GPP é discutida. Como um aperfeiçoamento para a detecção de falha de link de rádio um assim chamado temporizador de “RLF de Handover” T312 será introduzido em Rel- 12 do 3GPP conforme descrito na solicitação de mudança R2-140923, intitulada ‘Recuperação de RLF Rápida’. O temporizador T312 é um exemplo de um temporizador de handover. A ideia é disparar a RLF mais rápido, isto é, reduzir o tempo de interrupção de serviço para o usuário, no caso daquela RLF ser detectada enquanto o handover ainda está em curso: o temporizador T312 de RLF de Handover descrito é iniciado quando um determinado evento de medição tiver disparado (indicando o início do procedimento de handover) e quando ao mesmo tempo o temporizador de RLF herdado T310 já estiver em execução. O uso de T312 por evento de medição bem como a extensão do temporizador é configurável. Em outras palavras, T312 pode ser iniciado se T310 estiver em execução e após um evento de medição ter acontecido.

[0067] Como mencionado acima, na Figura 3, o uso do temporizador T312 de RLF de Handover é ilustrado. Na expiração de um disparo de evento de medição (para cujo Id de medição, o uso desse temporizador é configurado) o temporizador T312 será iniciado, se o temporizador de RLF T310 já estiver em execução. Presumindo que T312 é mais curto do que T310, o procedimento de restabelecimento pode ser inicializado antes, o que reduz seu tempo de interrupção de serviço. O temporizador T312 será interrompido com as mesmas condições que T310, isto é, mediante a recuperação cada camada PHY (após indicações de PHY em sincronismo por N311). Um valor de temporizador para T312 de 0 ms levará a uma terminação precoce de T310, isto é, iniciar diretamente o restabelecimento. Ademais, em, por exemplo, R2-140562 e em R2-140923 propõe-se incluir um sinalizador que indica a RLF devido à expiração de T312 no relatório de RLF como será discutido adicionalmente abaixo. A contribuição em R2-141023 também se refere a um contexto do temporizador T312.

[0068] Subsequentemente, uma Otimização de Robustez de Mobilidade, MIRO, é descrita. Configurando todos os parâmetros de HO manualmente para evitar os problemas supracitados como falha de link de rádio é muito dispendioso e pode ser muito desafiador. Como tal, a Otimização de Robustez de Mobilidade (MIRO) foi introduzida em 3GPP para automatizar a configuração dinâmica dos parâmetros de handover.

[0069] Essencialmente, a MIRO tenta identificar as seguintes três situações, e com base na ocorrência estatística das mesmas, tenta ajustar os parâmetros de HO.

[0070] HO Muito Tardia: realiza-se um handover do UE para a célula-alvo, de modo que o link para a célula-fonte seja rompido antes de completar o handover.

[0071] HO Muito Precoce: realiza-se um handover do UE para uma célula candidata de modo muito precoce, resultando em uma falha de link de rádio ou handover na célula-alvo. O UE retorna logo para a célula-fonte por meio dos procedimentos de restabelecimento.

[0072] Handover para a célula errada: realiza-se um handover do UE para uma célula-alvo, mas a mesma experimenta uma RLF dentro de um curto período de tempo após aquilo na célula-alvo e o UE restabelece a conexão em outra célula. Uma definição de parâmetro adequada teria muito provavelmente levado à realização de handover do UE para a última célula- alvo, inicialmente.

[0073] A MIRO pode tentar coletar estatísticas sobre a ocorrência de HOs Muito Tardios, HOs Muito Precoces e HO para a célula errada, e essas estatísticas são usadas para ajustar os parâmetros de handover.

[0074] Uma lista não exaustiva de parâmetros de handover que controlam o relatório conduzido por evento do UE e que pode ser ajustada pela MIRO é relatada abaixo: Um limite que indica quão superior ou inferior o sinal de referência de uma determinada célula candidata precisa ser antes de ser relatada para a célula de serviço; um limite que indica quão superior ou inferior o sinal de referência da célula de serviço precisa ser antes de um evento de mobilidade poder ser disparado; um coeficiente de filtro aplicado à medição antes de a avaliação ser disparada são considerados; um tempo para disparo que significa a janela de tempo dentro da qual a condição de disparo precisa ser satisfeita continuamente a fim de disparar o evento de relatório no UE.

[0075] Por exemplo, uma razão de ‘handover muito precoce’ superior ao desejado pode ser neutralizada aumentando-se o limite da célula-alvo candidata, por exemplo, atrasando o disparo de um evento de A3. Outro exemplo poderia ser resolução de uma razão de ‘handover para a célula errada’ superior ao desejado aumentando-se o limite para a primeira célula- alvo indesejada.

[0076] Três mensagens principais, a saber, relatório de RLF inclusas no RRC: mensagem de UEInformationResponse (entre o UE e eNBs), X2: INDICAÇÃO DE RLF (entre eNBs) e X2: RELATÓRIO DE HANDOVER (entre eNBs) são usadas por MRO para comunicar/coletar informações relacionadas o Handover Muito Precoce, Handover Muito Tardio e Handover para a célula errada. Consulte, por exemplo, TS 36.300 V12.0.0, TS 36.331 V12.0.0 e TS 36.423 V12.0.0 do 3GPP.

[0077] A Figura 4A ilustra esquematicamente um exemplo de relatório de informações entre um UE 402 e uma rede celular EUTRAN 401. O eNB ao qual o UE está se reconectando, através de um restabelecimento de RRC bem-sucedido ou por meio de RRCConnectionSetup após o modo OCIOSO, pode pedir por informações mais detalhadas sobre a falha após a conexão ser completada. Isso é feito por meio do procedimento de Solicitação de Informações de UE, em que o eNB pode pedir pelo Relatório de RLF, como mostrado na Figura 4A, consulte a TS 36.331 V12.0.0 do 3GPP. Consequentemente, a EUTRAN 401 envia uma mensagem de UEInformationRequest 403 para o UE 402

[0078] O UE 402 responde enviando-se uma mensagem de UEInformationResponse 404 com um relatório de RLF detalhado que pode incluir informações como (consulte a TS 36.331 V12.0.0 do 3GPP): O resultado de medição da última célula servida antes de RLF; Resultado de medição das células vizinhas realizada antes da RLF; Informações de localização, que podem incluir as últimas coordenadas bem como velocidade do UE quando a RLF foi detectada; E-CGI (e se a mesma não estiver disponível ID de Célula Física (PCI) ) da célula em que RLF ocorreu; E-CGI da célula em que a tentativa de restabelecimento foi feita; Se o RLF ocorresse após o recebimento de um comando de HO (isto é, mensagem de RRCConnectionReconfiguration que inclui mobilityControlInfo): A E-CGI em que essa mensagem foi recebida, Tempo a partir do recebimento do Comando de HO até a ocorrência da RLF; O tempo decorrido a partir da ocorrência de RLF até a sinalização pelo UE do relatório de RLF; Tipo de falha: isto é, se é uma falha de link de rádio normal ou uma falha de handover; Causa para a RLF: isto é, se a RLF aconteceu devido ao número máximo de retransmissão de RLC, expiração do temporizador T310, falha de acesso de RACH; C-RNTI do UE na última célula de serviço; e Informações sobre as últimas células de serviço e restabelecimento de UTRAN, para casos de mobilidade de LTE-UTRAN.

[0079] Com o uso das informações acima o eNB pode deduzir se, por exemplo, a RLF aconteceu devido a parâmetros de HO incorretos (muito tardio, muito precoce, HO para a célula errada), devido a um furo de cobertura (nenhuma célula com intensidade de sinal suficiente) ou devido à seleção inadequada de alvo de handover dado as condições de UE, por exemplo, velocidade de UE.

[0080] A Figura 4B ilustra esquematicamente um exemplo de indicação de uma falha de link de rádio a partir de um nó para outro. No mesmo, uma mensagem de INDICAÇÃO DE RLF 405 é enviada a partir do eNB2 para o eNB1. Conforme declarado em TS 36.423 V12.0.0 do 3GPP, o propósito do procedimento de Indicação de Falha de Link de Rádio é habilitar o aprimoramento de robustez de mobilidade em E-UTRAN passando-se informações sobre um evento de falha através da interface X2.

[0081] Quando uma solicitação de restabelecimento for recebida ou uma falha de conexão relatada após a instalação de conexão de RRC ou um handover bem sucedido de entrada, o eNB usa os identificadores de célula fornecidos pelo UE para identificar a célula/eNB de serviço potencialmente anterior. O eNB que recebeu as informações sobre a falha envia uma mensagem de INDICAÇÃO DE RLF para o(s) eNB(s) em questão. O eNB de serviço anterior pode, então, corresponder ao contexto correto, ou usar as informações disponíveis no relatório de RLF, se inclusos na mensagem de INDICAÇÃO DE RLF, para analisar a possível causa raiz da falha.

[0082] O eNB2 inicia o procedimento enviando-se a mensagem de INDICAÇÃO DE RLF para o eNB1 após a sinalização de um relatório de RLF ou de uma tentativa de restabelecimento a partir de um UE no eNB2, quando o eNB2 considera que o UE pode ter sido servido anteriormente por uma célula controlada pelo eNB1. Dentre outros parâmetros a Indicação de RLF pode conter o relatório de RLF sinalizado pelo UE para o eNB2.

[0083] A Figura 4C ilustra esquematicamente um exemplo do relatório de um handover. Na mesma, RELATÓRIO DE HANDOVER 406 é enviado a partir do eNB1 para o eNB2. Conforme especificado na TS 36.423 V12.0.0 do 3GPP, o procedimento de Relatório de Handover é usado para passar informações conectadas à análise de uma RLF que ocorre logo após um handover bem sucedido.

[0084] O eNB em que a RLF ocorreu (eNB-alvo original) envia uma mensagem de RELATÓRIO DE HANDOVER para o eNB-fonte original, identificando a célula-fonte, a célula-alvo e a célula em que o restabelecimento aconteceu.

[0085] Se um eNB receber uma mensagem de INDICAÇÃO DE RLF a partir de um eNB vizinho, o eNB pode responder ao eNB enviando a Indicação de RLF ou para um terceiro eNB que servia anteriormente o UE (caso do HO para a célula errada) enviando-se uma mensagem de RELATÓRIO DE HANDOVER que indica o Handover Muito Precoce ou HO para a célula errada, como mostrado na Figura 4C.

[0086] Dentre outros parâmetros o RELATÓRIO DE HANDOVER pode conter o relatório de RLF recebido anteriormente por meio da INDICAÇÃO DE RLF. O RELATÓRIO DE HANDOVER também pode ser usado para indicar eventos de Ping-Pong Inter-RAT entre eNBs.

[0087] A Figura 5 mostra extrações de um código de ASN. Em particular, um Relatório de VARRLF é mostrado. O relatório de VARRLF variável de UE é parte do RRC: Mensagem de UEInformationResponse e inclui as informações de falha de link de rádio ou informações de falha de handover. Isso é definido em TS 36.331 V12.0.0 do 3GPP e é mostrado na Figura 5.

[0088] A Figura 6 ilustra esquematicamente um cenário exemplificativo que tem função(ões) de Otimização de Robustez de Mobilidade, MRO. Na Figura 6 um cenário de MRO típico é ilustrado. Um UE 601 é no início conectado a um eNB-Fonte 602 e passa por um handover bem sucedido para um eNB de Falha 603. A conexão ao eNB de Falha 603 falha e o UE 601 se restabelece em um eNB de Restabelecimento 604. Então, o UE 601 pode enviar o relatório de RLF 605 para o eNB de Restabelecimento 604, que encaminha o mesmo com informações adicionais dentro da indicação de RLF 606 para o eNB de Falha 603. Os mecanismos de MRO podem ser aplicados nesse eNB 603. No caso de a conexão do UE 601 ter falhado rapidamente após o handover para o eNB de Falha 603, é adicionalmente benéfico informar ao eNB Fonte 602 sobre isso com o relatório de Handover 607 que também inclui o relatório de RLF. Além disso, nesse caso, o eNB-Fonte 602 aplicará mecanismos de MRO. Em algumas partes da revelação, tanto o eNB Fonte 602 e o eNB de Falha 603 são denotados como “entidades de rede de aplicação de MRO”. Isso não exclui que aqueles mecanismos de MRO possam ser parcialmente aplicados em nós de rede adicionais (por exemplo, nós de OAM, veja abaixo), que podem influenciar as definições de parâmetro nos eNBs-Fonte e eNB de Falha. Tal mecanismo de MRO pode ser implantado em qualquer nó de uma rede celular. Pode-se também se referir aos elementos de rede como nó de rede.

[0089] A Figura 7 ilustra esquematicamente uma arquitetura de rede exemplificativa em que os conceitos da invenção podem ser aplicados. A arquitetura de rede exemplificativa compreende um sistema de gerenciamento. Os elementos de nó (NE), também chamados de eNodeB, são gerenciados por um gerente de domínio (DM), também chamado de sistema de suporte e operação (OSS). Um DM pode, adicionalmente, ser gerenciado por um gerente de rede (NM). Realiza-se a interface de dois NEs através de um X2, considerando que a interface entre dois DMs é chamada de Itf-P2P. O sistema de gerenciamento pode configurar os elementos de rede, bem como receber observações associadas aos recursos nos elementos de rede. Por exemplo, o DM observa e configura NEs, enquanto o NM observa e configura DM, bem como NE por meio de DM. Qualquer função que otimiza automaticamente os parâmetros de mobilidade pode, em princípio, ser executado no NE, DM, ou no NMS (Sistema de Gerenciamento de Rede).

[0090] De acordo com um conceito, propõe-se suportar informações combinadas de um procedimento de handover e um procedimento de monitoramento de link de rádio, por exemplo, em LTE. Isso se aplica especificamente ao temporizador T312 de RLF de Handover. Tal esquema de MRO aprimora um de desempenho de handover e reduz as falhas discutidas acima. Um esquema de MRO tem como objetivo aumentar a robustez de mobilidade.

[0091] Um operador de rede celular pode configurar um UE (por meio de célula de serviço) com uma determinada configuração de RLM (por exemplo, T310) e temporizador combinado de RLF de Handover T312 (introduzido em Rel-12). Essa configuração também pode ser adaptada, dependendo, por exemplo, do tipo de célula (como definido em TS 36.423 V12.0.0 do 3GPP, IE de tipo de Célula indica o tamanho de uma célula), então não é necessariamente igual dentre as células. A configuração bem como os potenciais motivos de falha detalhados e temporização da também podem ser considerados em MRO, isto é, essas informações podem ser consideradas na célula que é considerada para aplicar mudanças aos parâmetros de mobilidade a fim de evitar que falhas ocorram novamente. A configuração, motivos de falha e temporização deverão ser considerados a fim de ponderar o ajuste dos parâmetros de handover entre as duas células, por exemplo, o desvio individual de célula (CIO).

[0092] Em um exemplo, se um T310 e/ou T312 bastante baixo fossem configurados no UE, RLF devido à expiração de T310 ou T312 seria mais provável, portanto, o ajuste do CIO pode requerer que mais casos de falha sejam atuados ou pode ser aplicado em pequenas etapas. Por outro lado, para T310 e/ou T312 superior, RLF é menos provável, portanto, o motivo para, por exemplo, um handover muito tardio dever ficar em um CIO subideal, que deveria ser ajustado após menos casos de falha e com etapas de ajuste superiores.

[0093] Em outro exemplo, se uma RLF ocorrer devido à expiração de T312 ao invés da expiração de T310 é evidente que um relatório de medição foi disparado (portanto, uma potencial célula-alvo identificada) e o procedimento de handover inicializado antes de a RLF ter sido detectada. No mínimo uma RLF devido à expiração de T312 indica que um relatório de medição foi enviado pelo UE. Esses critérios também deveriam ser considerados em MRO quando se decide como modificar os parâmetros de mobilidade. Por exemplo, quando são modificados, as mudanças de CIO para esse parâmetro podem ser feitas em maiores etapas para casos em que nenhum relatório de medição foi enviado quando a RLF foi detectada. De modo semelhante, se o eNB ainda mantiver o contexto de UE no momento em que as informações de falha são recebidas, uma RLF devido à expiração de T312 combinada com o recebimento malsucedido de um relatório de medição no eNB de serviço pode ainda implicar que ajustes enérgicos, por exemplo, no CIO precisam ser aplicados.

[0094] Vale a pena notar que MRO também pode agir mediante o TTT (Tempo Para Disparo), por exemplo, no caso de uma HO muito tardia esse parâmetro poderia ser encurtado. Entretanto, a capacidade de MRO de ajustar o TTT em sistema herdados é muito limitada devido à carência de informações sobre se a RLF ocorreu após um relatório de medição ter sido disparado.

[0095] Para automatizar essa MRO ciente de RLM a configuração de RLM e motivos de RLF de Handover detalhados podem ser incluídos no relatório de RLF sob determinadas circunstâncias, conforme descrito adicionalmente abaixo.

[0096] A Figura 8 mostra um fluxograma de um método, de acordo com uma modalidade da invenção, que pode ser implantado em uma rede celular. Em uma etapa S801, um UE experimenta uma falha de link de rádio, RLF. Em uma etapa S802, um nó de rede recebe um relatório de RLF. O relatório de RLF é tipicamente enviado a partir do UE para o nó de rede. O relatório de RLF deverá compreender informações de handover e RLF combinadas do UE. Um exemplo de tais informações combinadas é a expiração de T312 em, por exemplo, um relatório de RLF. Em uma etapa S803, o nó de rede considera o relatório de RLF e deduz o handover e configuração de RLM do UE para analisar a causa raiz de RLF no mecanismo de MRO para otimizar a robustez de mobilidade adaptando-se o handover e parâmetros de RLM nas células afetadas.

[0097] Subsequentemente, um mecanismo de MRO é discutido. As relações de célula para handover, isto é, os limiares de handover e outros parâmetros entre as células podem ser configurados em uma base por UE. Um parâmetro importante para configurar o limite de handover é o parâmetro de desvio individual de célula (CIO). Se um handover é disparado mais cedo ou mais tarde entre duas células depende dos parâmetros de CIO das respectivas células. Os handovers mal sucedidos podem se referir a handovers muito precoces e muito tardios e podem ser aprimoradas adaptando-se a definição de CIO. Os parâmetros adicionais podem influenciar o limite de handover: Por exemplo, um desvio de evento de handover para disparar o relatório de medição, por exemplo, desvio de A3; um tempo para disparo (TTT) para os eventos de medição de handover também pode ser adaptado para iniciar o procedimento de handover mais cedo ou mais tarde. De modo semelhante à adaptação de CIO, a adaptação de TTT também pode ser feita em uma base de relação por célula (isto é, configurada por célula-alvo); uma configuração de evento de handover em geral; eventos de medição de handover que iniciam um procedimento de handover podem ser configurados ou desconfigurados, por exemplo, evento A3, A5; o registro em listra negra de determinada células ou células em determinadas frequências portadoras; o tempo entre o recebimento de relatório de medição na rede e a transmissão de comando de handover; o tempo entre o recebimento de relatório de medição e solicitação de handover para outro nó de rede para iniciar o procedimento de handover na rede; No caso de um handover muito tardio, o limite de handover será reduzido, por exemplo, a diferença de CIO entre a CIO da célula-alvo e a CIO da célula-fonte será reduzida. Essa redução pode ser ponderada com base em considerações adicionais, conforme descrito abaixo. No caso de handover muito precoce o limite de handover deve, em geral, ser maior. No caso de handover para célula errada, as relações de limite de handover de pelo menos três células precisam ser consideradas e adaptadas.

[0098] Os conceitos da invenção se referem à adaptação da aplicação de MRO, isto é, se deve adaptar o limite de handover, qual limite de handover, ou como ponderar a adaptação daqueles limiares com base nas informações de handover e informações de falha de link de rádio combinadas, que são descritas nas seções subsequentes. Os exemplos de tais informações combinadas podem ser a expiração de T312, por exemplo, em um relatório de RLF ou informações de RLF combinadas com informações de se um relatório de medição foi enviado.

[0099] As informações de handover e falha de link de combinadas são discutidas subsequentemente. Para a análise de se a causa raiz da falha de link de rádio se deve a um furo de cobertura ou, por exemplo, handover muito tardio, a transmissão de informações sobre o relatório de medição (que inicia o procedimento de handover) fornece uma função da detecção de causa raiz. Em uma modalidade, essas informações são utilizadas em MRO. As informações de handover representam um exemplo das informações relacionadas à mobilidade.

[00100] Em particular, para esse propósito, como parte do IE de RLF- causa-r11 existente, um valor extra como, por exemplo, mostrado nas Figuras 9A e 913 abaixo pode ser incluído (Conceito da Figura 913 é proposto na minuta R2-140562 do 3GPP, intitulada ‘Fast RLF recovery’).

[00101] A Figura 9A mostra extrações de um código de ASN de acordo com uma modalidade desta invenção. A Figura 913 mostra extrações de outro código de ASN de acordo com uma modalidade desta invenção. Em uma alternativa adicional a causa de RLF pode ser codificada em um elemento de informações diferente dentro do relatório de RLF.

[00102] A inclusão desse valor de causa permite determinar se a falha ocorreu após um relatório de medição ter sido enviado pelo UE (visto que as condições de entrada de T312 são tanto transmissão de relatório de medição bem como estado de falha de link de rádio, a expiração de T312 somente é, portanto, possível se ambas as condições se mantiverem). Essas informações são muito importantes devido ao fato de que indica ao eNB de falha que as condições para disparar o handover forem satisfeitas, mas que uma RLF ocorreu antes de um Comando de HO poder ser recebido pelo UE. Por conseguinte, a partir dessas informações pode ser deduzido que o UE pode ter se movido para fora da cobertura de célula de serviço logo após relatar um relatório de medição. No caso de casos suficientes de falhas que incluem tais informações serem gravadas, o algoritmo de MRO (ou qualquer outro algoritmo com o uso dessas informações, por exemplo, em OAM, Manutenção e Administração de Operação) pode, portanto, inferir que um ajuste possível para evitar tal falha poderia ser para antecipar a sinalização do relatório de medição, isto é, para antecipar a condição de entrada para o(s) evento(s) de mobilidade, possivelmente disparando relatórios de medição. O último pode ser alcançado, por exemplo, aumentando-se o limite no sinal de célula de serviço; ou reduzindo-se o limite no sinal de célula-alvo; ou modificando-se os valores de histerese de modo a antecipar o relatório de evento; ou reduzindo o tempo para disparo a fim de iniciar os procedimentos de handover (isto é, disparar a sinalização de comando de HO); ou partes ou todos os acima.

[00103] Essas informações podem ser combinadas com a possibilidade de recuperar o contexto de UE por meio das informações no relatório de RLF. Na realidade, desde a Release 11, o relatório de RLF contém o c-RNTI do UE usado no último eNB de serviço. O último eNB de serviço que recebe o relatório de RLF (por meio de indicação de RLF ou Relatório de Handover) pode ainda ter o contexto de UE associado ao c-RNTI no relatório de RLF armazenado. Se o contexto ainda estiver disponível, o último eNB de serviço também teria a capacidade de compreender se o Relatório de Medição foi recebido (expiração de T312 somente indica que o relatório de medição foi enviado pelo UE). O anterior é outro pedaço de informações importantes devido ao fato de que indica que antes de a RLF ser declarada o UE estava em condições de canal com a capacidade de enviar e receber um relatório de medição. Como mencionado anteriormente, essas informações seriam úteis na escolha de como dimensionar o ajuste dos limiares de handover (por exemplo, CIO) para as potenciais células-alvo de handover.

[00104] Explicação adicional: De acordo com a TS 36.331 V12.0.0 do 3GPP, o relatório de RLF inclui o tempo de falha em relação à última Reconfiguração de RRC com controle de mobilidade; e também o tempo entre a falha e sinalização do relatório de RLF, então a rede sabe o tempo absoluto de quando a falha aconteceu. Entretanto, não sabe se houve uma tentativa de enviar o relatório de medição; somente sabe os valores medidos a partir do relatório de RLF. Adicionalmente, não sabe a relação de tempo entre o disparo de evento de medição e RLF. Conforme declarado acima, pode ser considerado bem interessante para, por exemplo, adaptação de limite de handover, especialmente considerando que o relatório de medição falha é um motivo de falha comum, por exemplo, em redes heterogêneas. Incluindo o motivo de falha de expiração de T312 no relatório, a rede poderia deduzir se o relatório de medição foi disparado anteriormente para RLF e, também, quando foi disparado, visto que o valor de T312 é configurável.

[00105] Desse modo, a fim de adaptar o valor de T312 configurado, seria bom se o motivo de falha fosse considerado explicitamente no relatório de RLF. Por exemplo: Se várias falhas relacionadas a T312 forem observadas em comparação às falhas relacionadas a T310 a rede pode aumentar o valor de T312 ou desconfigurar o uso de T312 inteiramente. Alternativa ou adicionalmente, se o relatório de medição foi disparado pelo UE também poderia ser indicado explicitamente no relatório de RLF. Um sinalizador poderia indicar se o relatório de medição foi enviado, ou uma lista de células que satisfizeram as condições de disparo de relatório de medição (antes ou após o TTT) poderia ser incluída no relatório de RLF. Além disso, o UE poderia incluir no relatório de RLF as informações de se o UE recebeu uma ACK de RLC para o relatório de medição. Isso seria uma indicação de que o relatório de medição também foi recebido com sucesso pela rede.

[00106] Adicionalmente, visto que os múltiplos eventos de medição possíveis (IDs de medição) podem ser configurados para usar T312, não está claro para a rede quais daqueles eventos de medição dispararam o início de T312 (como o primeiro evento). Para esse propósito, as informações sobre o evento de medição que dispararam T312 (como o primeiro evento) deverão ser incluídas no relatório de RLF. Essa inclusão pode ser condicional, somente no caso de a causa de falha ser T312. Até mesmo no caso de T312 não ser usado é benéfico incluir o ID de medição do evento de medição que disparou um relatório de medição.

[00107] Habilitando-se o IE de “timeSinceFailure-r11” existente ou outro elemento de informações para também indicar o tempo desde que o T312 disparou RLF também é possível saber o tempo absoluto que a RLF de T312 ocorreu. Isso é útil a fim de filtrar os eventos de falha que foram relatados após as mudanças de parâmetro de mobilidade já terem sido aplicadas.

[00108] Um sinalizador que indica explicitamente quanto tempo passou desde que o relatório de medição foi enviado para a ocorrência de RLF (por exemplo, nos casos em que a expiração de T312 não é o motivo de RLF ou não é usada) pode ajudar a compreender se a ação de enviar um comando de HO deverá ser antecipada. Essas informações de tempo podem ser dadas em um nível por ID de medição no caso de múltiplos eventos de medição. Adicionalmente, essas informações podem ser usadas para aplicar ajustes dos limiares de handover, por exemplo, tempo para disparo, ou valor de T310 configurado.

[00109] Em outra modalidade, o período de tempo durante o qual T310 estava em execução quando a RLF foi disparada (por exemplo, pela expiração de T312) pode ser incluído no relatório de RLF. Essas informações podem ser utilizadas para otimizar a definição de T310 e T312 e limiares de handover. Exemplo: No caso em que o T310 está em execução por bastante tempo quando a RLF é disparada, limiares de handover deverão ser reduzidas para a célula-alvo no caso de a RLF poder ser identificada como relacionada a um handover ao invés de um furo de cobertura.

[00110] Subsequentemente, uma utilização da configuração de monitoramento de link de rádio é discutida. Em uma modalidade, a extensão configurada de T310 e/ou T312 possivelmente em combinação com uma indicação de se um relatório de medição foi enviado e/ou recebido pelo UE (considerando a seção anterior) é utilizada para a adaptação dos limiares de handover.

[00111] Dependendo da extensão de T310 e/ou T312 e com qual frequência a RLF foi disparada antes ou após a transmissão de um relatório de medição, a adaptação de limite de handover deveria ser influenciado (exemplo: ponderação da redução de CIO menos significativa no caso de o T312 ter sido escolhido curto e várias falhas terem ocorrido).

[00112] A entidade de rede de aplicação de MRO pode tomar as seguintes medidas possíveis no que se refere ao ajuste de limite de handover: quanto menor é o T310 e/ou T312 menos significativa é a ponderação do evento de falha em uma decisão de mudar (antecipar) o limite de handover. A ponderação de cada falha pode se tornar zero se os limiares de T310 e/ou T312 forem configurados abaixo de um dado valor no eNB de falha.

[00113] Exemplo: se um T310 e/ou T312 bem baixo for configurado no UE, RLF seria mais provável, portanto o ajuste do CIO não deveria ser muito intenso. Por outro lado, para T310 e/ou T312 superior, RLF é menos provável, portanto, o motivo para, por exemplo, um handover muito tardio dever ficar em um CIO subideal, que deveria ser ajustado com mais intensidade.

[00114] A entidade de rede que recebe o relatório de RLF e que executa a MRO é ciente da configuração de RLM do UE no caso de o contexto de UE ainda estar disponível. Dado que o UE pode ir ao estado Ocioso e após a sinalizar o Relatório de RLF, o contexto de UE pode ser perdido no eNB de falha, a configuração de RLM pode ser desconhecida na rede. Devido ao fato de que o temporizador T310 e/ou T312 é configurável em uma base por UE, sua duração pode ser perdida uma vez que o contexto de UE é excluído e as informações sobre quanto tempo antes da RLF o relatório de medição foi enviado também serão perdidas. Por conseguinte, as informações de RLM, por exemplo, configuração, deveriam ser armazenadas no relatório de RLF. Adicionalmente, aperfeiçoamentos do relatório de RLF descritos na seção anterior também podem ser necessários para propósitos de adaptação.

[00115] Subsequentemente, uma utilização da estimativa de estado de mobilidade (MSE) é discutida. A rede dota o UE de parâmetros para dimensionar TTT com base na velocidade estimada. A própria estimativa de velocidade é, entretanto, deixada para a implantação de UE, de modo que a rede não possa saber qual valor de TTT foi usado pelo UE.

[00116] Em uma modalidade, quando se adapta limiares de handover em um mecanismo de MRO, a estimativa de estado de mobilidade do UE deveria, então, também ser considerado.

[00117] Portanto, a Estimativa de Estado de Mobilidade juntamente com as informações de RLF disparadas por T312, conforme descrito acima, pode ser incluída no relatório de RLF.

[00118] Uma adição da Estimativa de Estado de Mobilidade foi proposta em 3GPP, consulte a contribuição R3-140130 do 3GPP, intitulada "MRO and TTT scaling". Entretanto, deve ser notado que ter informações sobre a MSE, que permitem compreender o nível de dimensionamento de TTT realizado pelo UE, sem ter informações sobre se um relatório de medição foi disparado antes de a RLF ter ocorrido é de pouca utilidade e poderia, na realidade, levar a ações incorretas como modificação do TTT quando as falhas ocorrem até mesmo sem que os relatórios de medição tenham sido disparados.

[00119] De acordo com um conceito da invenção, propõe-se relatar a MSE e avaliar o dimensionamento produzido pela MSE no TTT face às informações de se uma RLF disparada por T312 ocorreu. Se uma RLF disparada por T312 tiver ocorrido, então uma avaliação sobre se deve modificar o TTT ou se deve descartar o evento de falha das estatísticas (por exemplo, devido à estimativa de estado de mobilidade inesperada pelo UE) pode ser feita.

[00120] O tempo decorrido a partir do tempo de relatório de medição, porém a MSE poderia proporcionar uma ideia de se o UE dimensionou o TTT de modo muito agressivo e se o comando de HO foi enviado muito tarde. Isso poderia acarretar, por exemplo, na filtragem de falhas para os UEs que “parecem” estimar a MSE de modo imprevisível ou levaria à redução de tempo a partir do relatório de medição e comando de HO.

[00121] Subsequentemente, uma interação com o sistema de OAM é discutida. Em outra modalidade, as informações aperfeiçoadas em eventos de falha, por exemplo, os relatórios de RLF aperfeiçoados ou partes das informações incluídas no mesmo, coletadas por eNBs podem ser encaminhadas para o sistema de OAM e analisadas no mesmo. Com base nas estatísticas de falha de mobilidade sinalizadas pelo eNB para a OAM, o sistema de OAM pode tomar decisões sobre como modificar os parâmetros de mobilidade semelhantes àqueles descritos nas modalidades acima. O sistema de OAM pode, então, sinalizar para os eNBs com necessidade de modificação dos parâmetros de mobilidade, ou, em geral, da configuração otimizada, novos parâmetros calculados com base nas estatísticas relatadas. Por exemplo, a OAM pode sinalizar novos valores dos Desvios Individuais de Célula em relação a uma ou mais relações de células vizinhas.

[00122] Os conceitos apresentados no presente documento habilitam uma mobilidade mais robusta em redes de telefonia celular como a LTE por mecanismos de MIRO aperfeiçoados que utilizam as informações de procedimento de handover e procedimento de falha de link de rádio combinadas. Especialmente em redes heterogêneas, em que configurações diferentes para os UEs em tipos de célula diferentes são aplicadas e handover/falha de link de rádio são mais frequentes, se torna importante considerar essas configurações de handover e falha de link de rádio e informações observadas em MIRO.

[00123] A Figura 10 mostra um fluxograma para ilustrar um método 1000 em um nó para uma rede celular para suportar a mobilidade na rede celular, que pode ser usada para implantar uma função de suporte de mobilidade em um nó de uma rede celular. Se uma implantação à base de processador do nó for usada, as etapas do método podem ser realizadas por um ou mais processadores do nó. Para esse propósito, o(s) processador(es) pode(m) executar um código de programa configurado correspondentemente. Adicionalmente, pelo menos algumas das funcionalidades correspondentes podem ser integradas no(s) processador(es). O método pode ser implantado em uma função de Otimização de Robustez de Mobilidade, MIRO, do nó. Determinados aspectos da MIRO foram discutidos acima.

[00124] O nó de uma rede celular pode ser um eNodeB, um NodeB, um RNC, um BSC, um nó de gerenciamento de rede ou nó de gerenciamento de domínio como um OSS ou uma combinação de alguns desses nós.

[00125] Na etapa S1001, o nó recebe, a partir de um equipamento de usuário, informações de uma falha de link de rádio de um link de rádio entre o equipamento de usuário e a rede celular. As informações podem ser recebidas de modo direto ou indireto. As informações podem ser recebidas em um relatório de Falha de Link de Rádio, RLF. Determinados aspectos do relatório de RLF foram discutidos acima.

[00126] Na etapa S1002, o nó recebe informações relacionadas a uma mobilidade do equipamento de usuário.

[00127] Na etapa S1003, o nó ajusta, com base nas informações recebidas, pelo menos um parâmetro de mobilidade para aumentar a robustez de mobilidade. Com base nas informações recebidas, o nó pode determinar uma causa raiz da falha de link de rádio. Tal determinação pode suportar o ajuste do pelo menos um parâmetro de mobilidade. O ajuste pode acontecer em uma célula-fonte ou uma célula-alvo do handover ou em uma célula para a qual o link falhou ou em uma célula de restabelecimento. O ajuste pode compreender enviar uma indicação do parâmetro de handover ajustado para um equipamento de usuário.

[00128] O nó pode receber informações a partir de mais de um equipamento de usuário. Com base nas informações recebidas o nó pode determinar uma situação de handover para um ou mais UEs como ‘HO muito tardia’, ‘HO muito precoce’ ou ‘HO para a célula errada’ ou ‘falha devido ao furo de cobertura’ conforme discutido acima. Tais informações ou estatística sobre tais informações pode ser uma base para ajustar determinados parâmetros de mobilidade. O ajuste de um parâmetro de mobilidade pode ser aumentando-se ou reduzindo-se um parâmetro através de uma determinada etapa. Vários exemplos de parâmetros de mobilidade diferentes e formas de ajustá-los foram, por exemplo, discutidos acima.

[00129] Em uma etapa opcional S1004, o nó envia o parâmetro de mobilidade ajustado para um equipamento de usuário. O parâmetro de mobilidade ajustado pode ser enviado de modo direto ou indireto.

[00130] O nó pode enviar o parâmetro de mobilidade ajustado para o equipamento de usuário a partir do qual as informações são recebidas e/ou para outro equipamento de usuário. O parâmetro de mobilidade ajustado também pode ser enviado para todos ou um subconjunto de todos os equipamentos de usuário de uma célula, como uma célula de serviço, uma célula-alvo ou uma célula de restabelecimento.

[00131] As informações relacionadas à mobilidade do equipamento de usuário compreendem informações de pelo menos um dentre: uma configuração de handover; um temporizador de handover como uma definição do temporizador T312; um temporizador de falha de link de rádio como uma definição do temporizador T310); se o equipamento de usuário enviou um relatório de medição, por exemplo, o relatório de medição enviado em um procedimento de handover; se a rede recebeu um relatório de medição a partir do equipamento de usuário; uma causa de falha, por exemplo, um motivo que causou a falha ou a expiração do temporizador T312; expiração de um temporizador de handover, por exemplo, o temporizador T312; expiração de um temporizador de falha de link de rádio, por exemplo, o temporizador T310; se um temporizador de handover expirou; uma lista de células que satisfazem as condições de disparo de um relatório de medição; um evento de medição, por exemplo, um ID de medição ou o evento de medição que disparou um temporizador de handover; um período de tempo desde que um temporizador de handover foi disparado; um período de tempo entre o envio de um relatório de medição e a ocorrência de uma falha de link de rádio; um período de tempo desde que um temporizador de handover está em execução; e um período de tempo desde que um temporizador de falha de link está em execução. Tais parâmetros são discutidos em maiores detalhes acima.

[00132] Em uma etapa opcional S1005 o nó determina, a partir das informações relacionadas à mobilidade, (por exemplo, a partir da expiração de um temporizador de handover) se um relatório de medição foi enviado pelo equipamento de usuário. Em um exemplo, pode ser determinado que um relatório de medição foi enviado antes de a falha de link de rádio ser detectada. Tal relatório de medição pode iniciar um handover, que não é bem sucedido devido à falha de link de rádio. Então, uma falha de link de rádio pode ter ocorrido antes de um procedimento de handover ter sido finalizado, por exemplo, antes de um Comando de HO ter sido recebido pelo UE. Em outras palavras, o relatório de medição que foi enviado pode se referir a um relatório de medição que inicia um procedimento de handover que falhou devido à falha de link de rádio. Tal conceito e outros são discutidos adicionalmente acima, em particular, em relação à expiração do temporizador T312.

[00133] O nó pode ajustar o pelo menos um parâmetro de mobilidade para aumentar a robustez da mobilidade também com base nessa determinação.

[00134] O nó também pode ou alternativamente determinar a partir das informações relacionadas à mobilidade se um comando de handover foi recebido pelo equipamento de usuário. O nó também pode ou alternativamente determinar quando um relatório de medição foi disparado. O nó pode ajustar o pelo menos um parâmetro de mobilidade para aumentar a robustez da mobilidade também com base nessa(s) determinação(ões). Tais conceitos são discutidos em maiores detalhes acima.

[00135] Em um exemplo, um desvio individual de célula, CIO, pode ser aumentado ou reduzido por um tamanho de etapa maior no caso em que nenhum relatório de medição foi enviado e/ou CIO pode ser aumentado ou reduzido por um tamanho de etapa menor no caso em que um relatório de medição foi enviado.

[00136] Em uma etapa opcional S1006, o nó recebe informações sobre uma configuração de monitoramento de link de rádio, RLM. A configuração de RLM pode compreender informações sobre pelo menos um dentre um temporizador de falha de link de rádio com uma duração ou definição do temporizador de falha de link de rádio (por exemplo, temporizador T310) e um temporizador de handover como uma duração ou definição de um temporizador de handover (por exemplo, temporizador T312). As informações sobre a configuração de RLM também são um exemplo de informações relacionadas à mobilidade do equipamento de usuário.

[00137] Em uma etapa opcional S1007, o nó pode ajustar pelo menos um parâmetro de mobilidade para aumentar robustez de mobilidade que também tem por base um contexto do equipamento de usuário. Tal contexto de UE pode estar em um relatório de RLF ou pode estar disponível ou ser recebido no nó.

[00138] Em uma etapa opcional S1008, o nó ajusta pelo menos um parâmetro de mobilidade para aumentar a robustez de mobilidade também com base em uma estimativa de estado de mobilidade, MSE, do equipamento de usuário. O nó pode receber a MSE a partir do equipamento de usuário. Tais utilizações de estimativas de estado de mobilidade são discutidas em maiores detalhes acima.

[00139] Tipicamente, o ajuste é feito em um nível por célula. Por exemplo, o ajuste pode ser feito em uma célula de serviço, uma célula-alvo, uma célula de restabelecimento e assim por diante. Os parâmetros de mobilidade em tal célula podem ser ajustados para todos os equipamentos de usuário ou para um subconjunto de equipamentos de usuário nessa célula.

[00140] O nó pode receber a partir do UE algumas ou todas as informações recebidas. As informações podem ser recebidas de modo direto ou indireto. Por exemplo, algumas ou todas as informações recebidas são recebidas em um relatório como um relatório de RLF.

[00141] O pelo menos um parâmetro de mobilidade é pelo menos um dentre: um desvio individual de célula, CIO; um limite de handover; um parâmetro indicativo de um limite de intensidade de sinal de uma célula-alvo necessário para disparar um evento de mobilidade (como o relatório de medições de potência para disparar um handover); um parâmetro indicativo de uma intensidade de sinal limite de uma célula de serviço necessário para disparar um evento de mobilidade (como um comando de handover); um coeficiente a ser aplicado a uma medição utilizada para disparar um evento de mobilidade (como o relatório de medição, por exemplo, como parte de um procedimento de handover ou um comando de handover); um parâmetro indicativo de um período de tempo durante o qual uma condição de disparo deve ser satisfeita para realmente disparar um evento de mobilidade; um temporizador de handover (por exemplo, o temporizador T312), um temporizador de falha de link de rádio (por exemplo, T310); um desvio de evento de handover (por exemplo, um desvio para disparar um relatório de medição ou um desvio de A3); um Tempo Para Disparar, TTT, (por exemplo, TTT um evento de mobilidade tal como iniciar um procedimento de handover); uma configuração de evento de handover; uma indicação para remover uma célula de uma frequência portadora; e um período de tempo entre o recebimento de um relatório de medição e a transmissão de uma solicitação de handover. Tais parâmetros e utilizações exemplificativas são discutidos em maiores detalhes acima.

[00142] A ordem das etapas na Figura 10 pode ser realizada em qualquer ordem razoável. Tipicamente, a etapa S1003 de ajustar pelo menos um parâmetro de mobilidade é realiza após as informações relevantes serem recebidas ou determinadas.

[00143] A Figura 11 mostra um fluxograma para ilustrar um método 1100 em um equipamento de usuário para suportar a mobilidade em uma rede celular, que pode ser usada para implantar uma função de suporte de mobilidade em um equipamento de usuário. Se uma implantação à base de processador do equipamento de usuário for usada, as etapas do método podem ser realizadas por um ou mais processadores do equipamento de usuário. Para esse propósito, o(s) processador(es) pode(m) executar um código de programa configurado correspondentemente. Adicionalmente, pelo menos algumas das funcionalidades correspondentes podem ser integradas no(s) processador(es).

[00144] Em uma etapa S1101, o equipamento de usuário detecta uma falha de um link de rádio entre o equipamento de usuário e a rede celular. A detecção pode ter por base o monitoramento de link de rádio, RLM, que é discutido em maiores detalhes acima.

[00145] Em uma etapa S1102, o equipamento de usuário envia para um nó da rede celular, as informações de uma falha de link de rádio de um link de rádio entre o equipamento de usuário e a rede celular. As informações podem ser enviadas de modo direto ou indireto. As informações podem ser enviadas em um relatório de RLF.

[00146] Em uma etapa S1103, o equipamento de usuário envia informações relacionadas a uma mobilidade do equipamento de usuário para o nó. O envio pode ser direito ou indireto. O envio indireto pode compreender que as informações são enviadas primeiro para pelo menos um outro nó que encaminha as informações para o nó. O envio direto pode compreender enviar em um link direto, por exemplo, sem um nó adicional entre o UE e o nó.

[00147] Em uma etapa opcional S1104, o equipamento de usuário recebe pelo menos um parâmetro de mobilidade ajustado a partir do nó. O equipamento de usuário, então, tipicamente ajusta o parâmetro de mobilidade correspondentemente. Os exemplos de parâmetros de mobilidade foram listados acima. O recebimento pode ser direito ou indireto.

[00148] Conforme declarado acima, as informações relacionadas à mobilidade do equipamento de usuário compreendem informações de pelo menos um dentre: uma configuração de handover; um temporizador de handover como uma definição do temporizador T312; um temporizador de falha de link de rádio como uma definição do temporizador T310; se o equipamento de usuário enviou um relatório de medição, por exemplo, o relatório de medição enviado em um procedimento de handover; se a rede recebeu um relatório de medição a partir do equipamento de usuário; uma causa de falha, por exemplo, um motivo que causou a falha ou a expiração do temporizador T312; expiração de um temporizador de handover, por exemplo, o temporizador T312; expiração de um temporizador de falha de link de rádio, por exemplo, o temporizador T310; se um temporizador de handover expirou; uma lista de células que satisfazem as condições de disparo de um relatório de medição; um evento de medição, por exemplo, um ID de medição ou o evento de medição que disparou um temporizador de handover; um período de tempo desde que um temporizador de handover foi disparado; um período de tempo entre o envio de um relatório de medição e a ocorrência de uma falha de link de rádio; um período de tempo desde que um temporizador de handover está em execução; e um período de tempo desde que um temporizador de falha de link está em execução.

[00149] Em uma etapa opcional S1005, o equipamento de usuário envia informações sobre uma configuração de monitoramento de link de rádio, RLM. Essas informações podem ser enviadas direta ou indiretamente para o nó. Conforme declarado acima, a configuração de RLM pode compreender informações sobre pelo menos um dentre um temporizador de falha de link de rádio com uma duração ou definição do temporizador de falha de link de rádio (por exemplo, temporizador T310) e um temporizador de handover como uma duração ou definição de um temporizador de handover (por exemplo, temporizador T312). As informações sobre a configuração de RLM também são um exemplo de informações relacionadas à mobilidade do equipamento de usuário.

[00150] O equipamento de usuário pode enviar algumas ou todas as informações a serem recebidas pelo nó. Essas informações podem ser enviadas direta ou indiretamente para o nó. Algumas ou todas as informações recebidas são recebidas pelo nó em um relatório como um relatório de RLF.

[00151] Conforme declarado acima, o pelo menos um parâmetro de mobilidade ajustado é pelo menos um dentre: um desvio individual de célula, CIO; um limite de handover; um parâmetro indicativo de um limite de intensidade de sinal de uma célula-alvo necessário para disparar um evento de mobilidade (como o relatório de medições de potência para disparar um handover); um parâmetro indicativo de uma intensidade de sinal limite de uma célula de serviço necessário para disparar um evento de mobilidade (como um comando de handover); um coeficiente a ser aplicado a uma medição utilizada para disparar um evento de mobilidade (como o relatório de medição, por exemplo, como parte de um procedimento de handover ou um comando de handover); um parâmetro indicativo de um período de tempo durante o qual uma condição de disparo deve ser satisfeita para realmente disparar um evento de mobilidade; um temporizador de handover (por exemplo, o temporizador T312), um temporizador de falha de link de rádio (por exemplo, T310 ); um desvio de evento de handover (por exemplo, um desvio para disparar um relatório de medição ou um desvio de A3); um Tempo Para Disparar, TTT, (por exemplo, TTT um evento de mobilidade como iniciar um procedimento de handover); uma configuração de evento de handover; uma indicação para remover uma célula de uma frequência portadora; e um período de tempo entre o recebimento de um relatório de medição e a transmissão de uma solicitação de handover.

[00152] Deve ser compreendido que os métodos das Figuras 10 e 11 podem ser combinados em um sistema que inclui um ou mais nós para uma rede celular que opera de acordo com o método da Figura 10 e um ou mais equipamento(s) de usuário que opera(m) de acordo com o método da Figura 11.

[00153] A Figura 12 ilustra, esquematicamente, estruturas exemplificativas para implantar um nó para uma rede celular que opera de acordo com os conceitos acima. No exemplo ilustrado, o nó inclui uma primeira interface de tráfego 1203 para a comunicação com um ou mais UEs e uma segunda interface de tráfego 1204 para a comunicação com outros nós de rede. Se o nó for implantado como um eNodeB, a primeira interface de tráfego 1203 pode corresponder a uma interface de rádio. Adicionalmente, o nó inclui uma interface de gerenciamento (MGMT) 1202, que pode ser usada para a comunicação para propósitos de gerenciamento. A interface de gerenciamento 1202 pode, por exemplo, ser usada para receber ou transmitir as informações supracitadas. Adicionalmente, o nó inclui uma interface de rede 1204, por exemplo, para a comunicação a outros nós de rede, por exemplo, eNodeBs.

[00154] Adicionalmente, o nó inclui um ou mais processador(es) 1205 acoplado(s) às interfaces 1202, 1203 e 1204, e a uma memória 1206 acoplada ao(s) processador(es) 1205. A memória 1206 pode incluir uma memória de somente leitura (ROM), por exemplo, uma ROM flash, uma memória de acesso aleatório (RAM), por exemplo, uma RAM dinâmica (DRAM) ou RAM estática (SRAM), um armazenamento em massa, por exemplo, um disco rígido ou disco de estado sólido, ou similares. A memória 1206 inclui módulos de código de programa configurados adequadamente a serem executados pelo(s) processador(es) 1205 com a finalidade de implantar as funcionalidades supracitadas do nó, por exemplo, correspondente às etapas do método da Figura 10. Mais especificamente, os módulos de código de programa na memória 1206 podem incluir um módulo de controle 1207 com a finalidade de implantar as funcionalidades supracitadas de ajuste de pelo menos um parâmetro de mobilidade. Adicionalmente, os módulos de código de programa na memória 1206 podem incluir um módulo de comunicação 1208 com a finalidade de implantar as funcionalidades supracitadas de recebimento de informações de uma falha de link de rádio e informações relacionadas à mobilidade.

[00155] Deve ser compreendido que as estruturas como ilustradas na Figura 12 são meramente esquemáticas e que o nó pode, na realidade, incluir componentes adicionais que, a título de clareza, não foram ilustrados, por exemplo, interfaces adicionais ou processadores adicionais. Além disso, deve ser compreendido que a memória 1206 pode incluir tipos adicionais de módulos de código de programa, que não foram ilustrados, por exemplo, módulos de código de programa para implantar funcionalidade conhecidas de um nó, como um eNodeB, um NodeB, um RNC, um BSC, um nó de gerenciamento de rede. Em algumas implantações, além disso, um programa de computador pode ser fornecido para implantar funcionalidades de um nó, por exemplo, na forma de um meio físico que armazena os módulos de código de programa a serem armazenados na memória 1106 ou disponibilizando-se tal código de programa para transferência por download ou transmissão contínua.

[00156] A Figura 13 ilustra, esquematicamente, estruturas exemplificativas para implantar o equipamento de usuário que opera de acordo com os conceitos acima. No exemplo ilustrado, o equipamento de usuário 1301 inclui uma interface de rádio 1302 para realizar a transmissão de dados para ou a partir da rede celular. Deve ser compreendido que para implantar funcionalidades de recebimento (RX) a interface de rádio 1302 pode incluir um ou mais módulos de RX 1304, e para implantar funcionalidades de transmissão (TX) a interface de rádio 1302 pode incluir um ou mais módulos de TX 1303.

[00157] Adicionalmente, o equipamento de usuário inclui um ou mais processador(es) 1305 acoplado(s) à interface de rádio 1302 e uma memória 1306 acoplada ao(s) processador(es) 1305. A memória 1306 pode incluir uma Memória de Somente Leitura (ROM), por exemplo, uma ROM flash, uma Memória de Acesso Aleatório (RAM), por exemplo, uma RAM dinâmica (DRAM) ou RAM estática (SRAM), um armazenamento em massa, por exemplo, um disco rígido ou disco de estado sólido, ou similares. A memória 1306 inclui módulos configurados adequadamente do código de programa a ser executado pelo(s) processador(es) 1305 com a finalidade de implantar as funcionalidades supracitadas. Mais especificamente, a memória 1306 pode incluir um módulo de controle 1308 com a finalidade de implantar funcionalidades supracitadas como a detecção de uma falha de link de rádio. Adicionalmente, os módulos de código de programa na memória 1305 podem incluir um módulo de comunicação 1309 com a finalidade de implantar as funcionalidades supracitadas como o envio de informações de uma falha de link de rádio e informações relacionadas à mobilidade do equipamento de usuário.

[00158] Deve ser compreendido que as estruturas como ilustradas na Figura 13 são meramente esquemáticas e que o equipamento de usuário pode, na realidade, incluir componentes adicionais que, a título de clareza, não foram ilustrados, por exemplo, interfaces, sensores, atuadores, dispositivos de saída adicionais ou processadores adicionais. Além disso, deve ser compreendido que a memória 1306 pode incluir tipos adicionais de módulos de código de programa, que ainda não foram ilustrados. Por exemplo, a memória 1306 pode incluir módulos de código de programa para implantar funcionalidades típicas de um equipamento de usuário ou módulos de código de programa de um ou mais aplicativos a serem executados pelo(s) processador(es) 1305. De acordo com algumas implantações, além disso, um programa de computador pode ser fornecido para implantar funcionalidades do equipamento de usuário, por exemplo, na forma de um meio físico que armazena os módulos de código de programa a serem armazenados na memória 1306 (como os módulos 1308 e 1309) ou disponibilizando-se tal código de programa para transferência por download ou transmissão contínua.

[00159] As modificações e outras modalidades de todas as modalidades reveladas virão à mente de um indivíduo versado na técnica que tem o benefício dos ensinamentos apresentados nas descrições anteriores e nos desenhos associados. Portanto, deve ser compreendido que as modalidades não devem ser limitadas às modalidades específicas reveladas e que modificações e outras modalidades destinam-se a ser incluídas no escopo desta revelação. Embora termos específicos possam ser empregados no presente documento, os mesmos são usados somente em um sentido genérico e descritivo e não para propósitos de limitação.

[00160] Determinados aspectos e suporte adicional da invenção são apresentados e discutidos adicionalmente a seguir: Na contribuição R2- 141023, intitulada “Introduction of T312”, concordou-se adicionar um novo temporizador de detecção de RLF à especificação de protocolo TS36.331 de RRC, tal temporizador de detecção é denominado T312.

[00161] A Figura 14 mostra uma definição de um temporizador T312. O temporizador T312 pode ser iniciado mediante o disparo de um relatório de medição para uma identidade de medição para a qual o T312 foi configurado, enquanto T310 está em execução. O temporizador T312 pode ser interrompido mediante ou recebimento de indicações de sincronismo consecutivas de N311 a partir das camadas inferiores, mediante o disparo do procedimento de handover, mediante o início do procedimento de restabelecimento de conexão, e mediante a expiração de T310. Na expiração do Temporizador T312, está previsto ir para RRC_IDLE, se a segurança não estiver ativada, então está previsto iniciar o procedimento de restabelecimento de conexão.

[00162] A saber, é um temporizador que começa no disparo de relatório de medição pelo UE, enquanto T310 ainda está em execução, isto é, o T312 somente é iniciado se problemas ao longo da camada física forem identificados e tiverem disparado o T310.

[00163] No presente contexto é explicado o porquê seria benéfico reportar uma RLF disparada pela expiração de T312 no Relatório de RLF, como parte de outros valores de causa de RLF existentes. A princípio, a importância de saber os eventos de RLF de T312 em RAN é discutida adicionalmente.

[00164] Como parte do Item de Trabalho (WI) de Aperfeiçoamentos de mobilidade de HetNet (Rede Heterogênea) decidido em RAN2 do 3GPP, concordou-se com o temporizador T312 para disparar eventos de RLF rápidos (consulte R2-141023). O temporizador T312 dispara a RLF enquanto o T310 está em execução, isto é, quando os problemas de camada física já foram detectados pelo UE.

[00165] Uma configuração típica de T312 seria fazer esse temporizador expirar mais cedo do que T310, de um modo que as RLFs que seguem os relatórios de medição já disparados (isto é, RLFs provavelmente imputáveis para definições de mobilidade subideais) possam ser declaradas mais cedo e restabelecimentos mais precoces possam ser disparados.

[00166] A Figura 3 ilustra um temporizador T312 de RLF de Handover e explica como o temporizador T312 poderia funcionar.

[00167] No Relatório de RLF atual (por exemplo, de acordo com a TS 36.331 V12.0.0) sinalizado pelo UE como parte da solução de MRO, diversos valores de causa de RLF já estão incluídos. O motivo para a inclusão de tais causas é permitir que a RAN tenha uma melhor compreensão da causa raiz da falha e tenha a capacidade de aplicar os ajustes corretos dependendo da causa declarada. Os valores de causa de RLF atualmente relatáveis no Relatório de RLF são listados na Figura 9C (consulte a TS36.331 V12.0.0).

[00168] Incluindo-se a causa de Expiração de T312 à lista de valores de causa de RLF atual, ou, alternativamente, adicionando-se um IE adicional que sinaliza tal evento, será possível deixar a RAN saber se falha ocorreu uma vez que um relatório de medição foi disparado pelo UE. A saber, a RAN teria a capacidade de saber se as condições de evento de mobilidade (por exemplo, eventos A3, A2) foram encontradas pelo UE antes de a RLF ser declarada.

[00169] As informações anteriores são muito importantes devido ao fato de que permitem distinguir melhor as falhas devido a, por exemplo, sinais de desvanecimento rápidos, furos de cobertura, condições de zona de sombra ou definições de parâmetros de mobilidade altamente subideais de falhas devido a parâmetros de mobilidade mal configurados com necessidade de ajuste relativamente pequeno. Nos cenários de Rede Heterogênea o anterior é muito importante, como explicado na Figura 3.

[00170] A Figura 15 mostra potências de sinal recebido (RSRP) como uma função da distância em um cenário de rede celular exemplificativo. O cenário de rede celular compreende uma macro estação base 1501 e uma pico estação base 1502. As curvas 1503 e 1504 mostram a RSRP que um UE recebe a partir da macro estação base 1501 e pico estação base 1502, respectivamente, como uma função da distância a partir do nó em questão. Uma RLF devido a uma queda de sinal de macro estação base é indicada em uma situação 1505. Uma falha em uma região de handover para um handover entre a pico estação base 1501 e a macro estação base 1502 ou uma falha devido a parâmetros de mobilidade subideais é indicada na situação 1506.

[00171] A Figura 15 proporciona exemplos de RLFs em que o conhecimento de Disparo de Relatório de Medição pode ser útil de acordo com uma modalidade da invenção. Na Figura 15 três falhas possíveis são mostradas. A primeira é uma devido a problemas de cobertura, isto é, RLF disparada por T312 não ocorreria devido fato de que o sinal de célula vizinha não é tal para disparar um relatório de handover. Nesse caso, é improvável que a causa raiz de falha seja abordada pela modificação de parâmetros de mobilidade.

[00172] A segunda falha é um caso em que o UE está na região de HO entre macro e pico. O anterior seria deduzível pela presença da causa de expiração de T312. Nesse caso, o fato de que um relatório de medição foi enviado pelo UE é indicativo da possibilidade de abordar a falha através do ajuste fino das definições de parâmetros de mobilidade.

[00173] A terceira falha é um caso em que o UE está na região de HO entre macro e pico, mas um relatório de medição não foi disparado pelo UE. O anterior seria deduzível pelas medições relatadas no Relatório de RLF. Nesse caso, o fato de que um relatório de medição não foi enviado pelo UE é indicativo de uma configuração muito insatisfatória dos eventos de mobilidade, que pode precisar ser ajustada com grandes mudanças delta.

[00174] Com explicado adicionalmente a seguir, permitindo-se a inclusão de causas de Expiração de T312 no Relatório de RLF não somente seria possível saber que um relatório de medição foi disparado pelo UE, mas desde que o contexto de UE ou parte dessas informações esteja disponível no eNB-fonte, pode-se, também, saber o seguinte: Se o Relatório de Medição foi recebido pelo eNB até mesmo durante as janelas de tempo de T310: na realidade, uma condição frequente é que o Relatório de Medição é enviado pelo UE, mas não é recebido pelo eNB. É útil saber que o relatório de medição pode ser recebido enquanto T310 está em execução, isto é, até mesmo nas condições problemáticas de DL.

[00175] Recuperando-se a duração do temporizador T312 definida para o UE falho e verificando-se as medições relatadas no Relatório de RLF, é possível ter uma estimativa de quanto o disparo de relatório de medição deveria ser antecipado: se T312 for relativamente curto e o sinal de célula- fonte não for muito baixo, uma etapa relativamente pequena na antecipação do ponto de disparo de HO é necessária para permitir que o relatório de medição seja recebido pelo eNB e, consequentemente, para permitir o recebimento de comando de HO bem-sucedido no UE.

[00176] Os aperfeiçoamentos possíveis permitidos pelo relatório de Expiração de T312 são considerados aqui. Como discutido com a discussão relacionada à Importância de saber os eventos de RLF de T312 em RAN, novas informações sobre o evento de falha são deduzíveis a partir do conhecimento de que a RLF é causada por uma expiração de T312.

[00177] No presente contexto está uma lista de parâmetros que podem ser mais bem ajustados relatando-se eventos de RLF causados pela Expiração de T312:

[00178] Conhecimento da expiração de T312 permite ajustar o Tempo Para Disparar (TTT): Dependendo da duração de T312 e de se um relatório de medição foi recebido pelo eNB-fonte, o TTT poderia ser otimizado (por exemplo, reduzido) para permitir um disparo mais rápido dos eventos de mobilidade.

[00179] O conhecimento da expiração de T312 permite um melhor ajuste da CIO: se a RLF for devido à expiração de T312 significa que o ponto de disparo de HO precisa ser antecipado por uma quantidade relativamente pequena, para permitir a entrega com sucesso do Comando de HO.

[00180] O conhecimento da expiração de T312 permite um melhor ajuste do time entre o recebimento de relatório de medição e a transmissão de Comando de HO: se a RLF for devido à expiração de T312 e se o relatório de medição for recebido no eNB-fonte, uma RLF pode ser devido à transmissão atrasada do Comando de HO.

[00181] O conhecimento da expiração de T312 permite detectar melhor os casos de furos de cobertura e efeitos de desvanecimento rápido: o Relatório de RLF já contém medições de células vizinhas que indicam a intensidade de sinal de células vizinhas. Isso, algumas vezes, não é suficiente para compreender as situações de furos de cobertura ou sinais de desvanecimento rápido. O conhecimento de se um relatório de medição foi disparado antes da RLF fornece informações sobre se as células vizinhas eram candidatas de HO potenciais ou se o UE está em uma zona de cobertura insatisfatória sem quaisquer células candidatas de HO satisfatórias.

[00182] O conhecimento da expiração de T312 permite ganhar uma melhor compreensão sobre as medições incluídas no Relatório de RLF. Essas medições seriam, na realidade, muito recentes, já que o Relatório de Medição é enviado enquanto o T310 já está em execução.

[00183] O relatório de informações de eventos de RLF em que o relatório de medição foi enviado pelo UE pode ajudar a ajustar a duração do T312. Esse temporizador tem, na realidade, o propósito de permitir o disparo de restabelecimento mais rápido e pode ser ajustado para acelerar a declaração de RLF nos casos em que é deduzido (por exemplo, por medições relatadas no Relatório de RLF) que uma queda súbita no sinal de célula de serviço e sinal de célula vizinha suficientemente satisfatório é detectada.

[00184] Nessa discussão adicional da invenção, as vantagens de se relatar a Expiração de T312 como parte do Relatório de RLF foram explicadas no contexto de Otimização de Robustez de Mobilidade. Destacou-se que seria benéfico adicionar tal nova causa de RLF ao Relatório de RLF para completar a faixa de valores de causa de RLF relatada já presentes. Propõe-se relatar a expiração de T312 no Relatório de RLF. Propõe-se adicionalmente incluir uma causa de Expiração de T312 no Relatório de RLF.

ABREVIAÇÕES

[00185] ACK Confirmação ARFCN Número de Canal de Radiofrequência Absoluto CGI Identificador Global de Célula CIO Desvio Individual de Célula eNB Nó evoluído B FDD Duplexação por Divisão de Frequência HO Handover HSPA Acesso de Pacote em Alta Velocidade LTE Evolução em Longo Prazo MRO Otimização de Robustez de Mobilidade MSE Estimativa de Estado de Mobilidade PCI Identidade de Célula Física PHY Camada Física PLMN Rede Móvel Terrestre Pública RACH Canal de Acesso Aleatório RAN Rede de Acesso de Rádio RAT Tecnologia de Acesso de Rádio RLC Controle de Link de Rádio RLF Falha de Link de Rádio RLM Monitoramento de Link de Rádio RNTI Identidade Temporária de Rede de Rádio RRC Controle de Recurso de Rádio RSRP Potência Recebida de Sinal de Referência RSRQ Qualidade Recebida de Sinal de Referência TDD Duplexação de Divisão por Tempo TTT Tempo Para Disparo UTRAN Rede de Acesso de Rádio Terrestre Universal X2APX2 Protocolo de Aplicação

Claims (18)

1. Método (1000) em um nó (1201) para uma rede celular para suportar mobilidade na rede celular, caracterizado pelo fato de que compreende as etapas: o nó (1201) recebe (S1001), a partir de um equipamento de usuário (1301), informações de uma falha de link de rádio de um link de rádio entre o equipamento de usuário e a rede celular; o nó (1201) recebe (S1002), a partir do equipamento de usuário (1301), informações relacionadas a uma mobilidade do equipamento de usuário (1301), em que as informações relacionadas a uma mobilidade do equipamento de usuário compreendem informações sobre uma expiração de um temporizador de handover, em que o temporizador de handover é um temporizador T312; e com base nas informações recebidas, o nó (1201) ajusta (S1003) pelo menos um parâmetro de mobilidade para aumentar a robustez de mobilidade, em que o pelo menos um parâmetro de mobilidade é pelo menos um dentre: um desvio individual de célula, CIO; um limite de handover; um temporizador de falha de link de rádio; e um Tempo para Disparo, TTT.

2. Método (1000), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende a etapa: o nó (1201) envia (S1004) o parâmetro de mobilidade ajustado para um equipamento de usuário (1301).

3. Método (1000), de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que as informações relacionadas à mobilidade do equipamento de usuário compreendem informações de pelo menos um dentre: uma configuração de handover; um temporizador de handover; um temporizador de falha de link de rádio; se o equipamento de usuário enviou um relatório de medição; se a rede recebeu um relatório de medição a partir do equipamento de usuário; uma causa de falha; expiração de um temporizador de falha de link de rádio; se um temporizador de handover expirou; uma lista de células que satisfazem as condições de disparo de relatório de medição; um evento de medição; um período de tempo desde que um temporizador de handover foi disparado; um período de tempo entre o envio de um relatório de medição e a ocorrência de uma falha de link de rádio; um período de tempo desde que um temporizador de handover está em execução; e um período de tempo desde que um temporizador de falha de link de rádio está em execução.

4. Método (1000), de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que compreende adicionalmente as etapas de: o nó (1201) determina (S1005) a partir das informações relacionadas à mobilidade se um relatório de medição foi enviado pelo equipamento de usuário (1301); o nó (1201) ajusta o pelo menos um parâmetro de mobilidade para aumentar a robustez de mobilidade que também tem por base a determinação de se um relatório de medição foi enviado.

5. Método (1000), de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de que compreende adicionalmente a etapa: o nó (1201) recebe (S1006) informações sobre uma configuração de monitoramento de link de rádio, RLM, em que a configuração de RLM compreende informações sobre pelo menos um dentre um temporizador de falha de link de rádio e um temporizador de handover.

6. Método (1000), de acordo com qualquer uma das reivindicações 1 a 5, caracterizado pelo fato de que compreende adicionalmente a etapa: o nó (1201) ajusta pelo menos um parâmetro de mobilidade para aumentar a robustez de mobilidade que também tem por base pelo menos um de um contexto do equipamento de usuário (1301) e uma estimativa de estado de mobilidade do equipamento de usuário.

7. Método (1000), de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de que o ajuste é feito em um nível por célula.

8. Método (1000), de acordo com qualquer uma das reivindicações 1 a 7, caracterizado pelo fato de que as informações recebidas são recebidas em um relatório de falha de link de rádio, RLF.

9. Método (1000), de acordo com qualquer uma das reivindicações 1 a 8, caracterizado pelo fato de que o pelo menos um parâmetro de mobilidade é pelo menos um dentre: um parâmetro indicativo de uma intensidade de sinal limite de uma célula alvo necessária para disparar um evento de mobilidade; um parâmetro indicativo de uma intensidade de sinal limite de uma célula de serviço necessária para disparar um evento de mobilidade; um coeficiente a ser aplicado a uma medição utilizado para disparar um evento de mobilidade; um parâmetro indicativo de um período de tempo durante o qual uma condição de disparo deve ser satisfeita para realmente disparar um evento de mobilidade; um temporizador de handover; um desvio de evento de handover; uma configuração de evento de handover; uma indicação para remover uma célula de uma frequência portadora; e um período de tempo entre o recebimento de um relatório de medição e a transmissão de uma solicitação de handover.

10. Método (1100) em um equipamento de usuário (1301) para suportar mobilidade na rede celular, caracterizado pelo fato de que compreende as etapas: o equipamento de usuário (1301) detecta (S1101) uma falha de um link de rádio entre o equipamento de usuário (1301) e a rede celular; o equipamento de usuário (1301) envia (S1102) para um nó (1201) da rede celular informações da falha de link de rádio de um link de rádio entre o equipamento de usuário (1301) e a rede celular; o equipamento de usuário (1301) envia (S1103) informações relacionadas a uma mobilidade do equipamento de usuário (1301) para o nó (1201), em que as informações relacionadas a uma mobilidade do equipamento de usuário (1301) compreendem informações sobre uma expiração de um temporizador de handover, que o temporizador de handover é um temporizador T312; e o equipamento de usuário (1301) recebe (S1104) pelo menos um parâmetro de mobilidade ajustado do nó (1201), em que o pelo menos um parâmetro de mobilidade ajustado é pelo menos um dentre: um desvio individual de célula, CIO; um limite de handover; um temporizador de falha de link de rádio; um Tempo para Disparo, TTT.

11. Método (1100), de acordo com a reivindicação 10, caracterizado pelo fato de que as informações relacionadas à mobilidade do equipamento de usuário compreendem informações de pelo menos um dentre: uma configuração de handover; um temporizador de handover; um temporizador de falha de link de rádio; se o equipamento de usuário enviou um relatório de medição; se a rede recebeu um relatório de medição a partir do equipamento de usuário; uma causa de falha; expiração de um temporizador de falha de link de rádio; se um temporizador de handover expirou; uma lista de células que satisfazem as condições de disparo de relatório de medição; um evento de medição; um período de tempo desde que um temporizador de handover foi disparado; um período de tempo entre o envio de um relatório de medição e a ocorrência de uma falha de link de rádio; um período de tempo desde que um temporizador de handover está em execução; e um período de tempo desde que um temporizador de falha de link de rádio está em execução.

12. Método (1100), de acordo com a reivindicação 10 ou 11, caracterizado pelo fato de que compreende adicionalmente a etapa: o equipamento de usuário (1301) envia informações sobre uma configuração de monitoramento de link de rádio, RLM, em particular, em que a configuração RLM compreende informação sobre pelo menos um temporizador de falha de link de rádio e um temporizador de handover.

13. Método (1100), de acordo com qualquer uma das reivindicações 10 a 12, caracterizado pelo fato de que as informações enviadas são enviadas em um relatório de falha de link de rádio, RLF.

14. Método (1100), de acordo com qualquer uma das reivindicações 10 a 13, caracterizado pelo fato de que o pelo menos um parâmetro de mobilidade ajustado é pelo menos um dentre: um parâmetro indicativo de uma intensidade de sinal limite de uma célula alvo necessária para disparar um evento de mobilidade; um parâmetro indicativo de uma intensidade de sinal limite de uma célula de serviço necessária para disparar um evento de mobilidade; um coeficiente a ser aplicado a uma medição utilizado para disparar um evento de mobilidade; um parâmetro indicativo de um período de tempo durante o qual uma condição de disparo deve ser satisfeita para realmente disparar um evento de mobilidade; um temporizador de handover; um desvio de evento de handover; uma configuração de evento de handover; uma indicação para remover uma célula de uma frequência portadora; e um período de tempo entre o recebimento de um relatório de medição e a transmissão de uma solicitação de handover.

15. Nó (1201) para uma rede de celular e para suportar mobilidade na rede celular, o nó caracterizado pelo fato de que compreende: pelo menos uma interface (1202, 1203, 1204); e pelo menos um processador (1205), o pelo menos um processador (1205) sendo configurado para: receber, a partir de um equipamento de usuário (1301), informações de uma falha de link de rádio de um link de rádio entre o equipamento de usuário (1302) e a rede celular, receber, a partir de um equipamento de usuário (1301), informações relacionadas a uma mobilidade do equipamento de usuário (1301), em que a informação relacionada a uma mobilidade do equipamento de usuário compreende informações sobre a expiração de um temporizador de handover, em que o temporizador de handover é um temporizador T312, e com base na informação recebida, para ajustar pelo menos um parâmetro de mobilidade para aumentar a robustez de mobilidade, em que o pelo menos um parâmetro de mobilidade é pelo menos um dentre: um desvio individual de célula, CIO; um limite de handover; um temporizador de falha de link de rádio; e um Tempo para Disparo, TTT.

16. Nó de acordo com a reivindicação 15, caracterizado pelo fato de que o pelo menos um processadoor (1205) é configurado para realizar as etapas do método como definido em qualquer uma das reivindicações 2 a 9.

17. Equipamento de usuário (1301) para suportar mobilidade na rede celular, o equipamento de usuário (1301) caracterizado pelo fato de que compreende: pelo menos uma interface (1302); e pelo menos um processador (1305), o pelo menos um processador (1305) sendo configurado para: detectar uma falha de um link de rádio entre o equipamento de usuário e a rede celular; enviar para um nó (1201) da rede celular, uma informação de uma falha de link de rádio entre o equipamento de usuário (1301) e a rede celular; e enviar informação relacionada a uma mobilidade do equipamento de usuário (1301) para o nó (1201), em que a informação relacionada a uma mobilidade do equipamento de usuário (1301) compreende informação sobre uma expiração de um temporizador de handover, em que o temporizador de handover é um temporizador T312; e receber pelo menos um parâmetro de mobilidade ajustado a partir do nó (1201), em que o pelo menos um parâmetro de mobilidade ajustado é pelo menos um dentre: um desvio individual de célula, CIO; um limite de handover; um temporizador de falha de link de rádio; e um Tempo para Disparo, TTT.

18. Equipamento de usuário (1301), de acordo com a reivindicação 17, caracterizado pelo fato de que o pelo menos um processador (1305) é configurado para realizar as etapas do método conforme definido em qualquer uma das reivindicações 10 a 14.