BRPI0606057B1 - método, equipamento de usuário e rede umts para a redução do consumo de bateria - Google Patents

Abstract

MÉTODO E APARELHO PARA O CONTROLE DE RECURSO DE RÁDIO DIRIGIDO POR UM EQUIPAMENTO DE USUÁRIO EM UMA REDE DE UMTS. Um método e um aparelho para uma performance melhorada de bateria de equipamento de usuário em uma rede sem fio que tem múltiplos estados de controle de recurso de rádio (RRC), o método compreendendo as etapas de: monitoração, no equipamento de usuário, de uma troca de dados de aplicativo; determinar quando não se espera que nenhum aplicativo no equipamento de usuário troque dados; e iniciar, a partir do equipamento de usuário, uma transição para um estado ou modo de controle de recurso de rádio demandando menos bacteria.

Description

O presente pedido se refere a um controle de recurso de rádio entre um Equipamento de Usuário (UE) e uma Rede de Acesso por Rádio Terrestre Universal (UTRAN) e, em particular, à transição entre modos e estados em uma rede de UMTS.

Um Sistema de Telecomunicação Móvel Universal (UMTS) é um sistema baseado em pacote de banda larga para a transmissão de texto, voz digitalizada, vídeo e multimídia. Ela é altamente apoiada para padronização para a terceira geração e, geralmente, é baseada em um Acesso Múltiplo de Divisão de Código de Banda Larga (W-CDMA).

Em uma rede de UMTS, uma parte de Controle de Recurso de Rádio (RRC) da pilha de protocolo é responsável pela atribuição, pelo estabelecimento e pela liberação de recursos de rádio entre o UE e a UTRAN. Este protocolo de RRC é descrito em detalhes nas especificações 3GPP TS 25.331. Dois modos básicos em que o UE pode estar são definidos como "modo inativo" e "modo conectado de UTRA". UTRA significa Acesso por Rádio Terrestre de UMTS. Em um modo inativo, é requerido que o UE requisite uma conexão de RRC sempre que desejar enviar quaisquer dados de usuário ou em resposta a uma radiochamada, sempre que a UTRAN ou o Nó de Suporte de GPRS de Serviço (SGGN) enviar uma radiochamada para ela para receber dados a partir de uma rede de dados externa, tal como um servidor "push". Os comportamentos de modo inativo e conectado são descritos em detalhes nas especificações de 3GPP TS 25.304 e TS 25.331.

Quando em um modo conectado de RRC de UTRA, o dispositivo pode estar em um de quatro estados. Estes são: CELL-DCH: um canal dedicado é alocado à UE em enlace ascendente e em enlace descendente neste estado, para a troca de dados. O UE deve realizar ações conforme esboçado em 3GPP 25.331.

CELL_FACH: nenhum canal dedicado é alocado ao equipamento de usuário neste estado. Ao invés disso, canais comuns são usados para a troca de uma pequena quantidade de dados em rajadas. 0 UE deve realizar ações conforme esboçado em 3GPP 25.331, as quais incluem o processo de seleção de célula conforme definido em 3GPP TS 25.304.

CELL_PCH: o UE usa uma Recepção Descontinua (DRX) para a monitoração de mensagens de difusão e radiochamadas através de um Canal de Indicador de Envio de Radiochamada (PICH). Nenhuma atividade de enlace ascendente é possivel. O UE deve realizar ações conforme esboçado em 3GPP 25.331, o que inclui o processo de seleção de célula conforme definido em 3GPP TS 25.304. 0 UE deve realizar o procedimento CELL UPDATE após uma resseleção de célula.

URA_PCH: o UE usa uma Recepção Descontinua (DRX) para a monitoração de mensagens de difusão e radiochamadas através de um Canal de Indicador de Envio de Radiochamada (PICH). Nenhuma atividade de enlace ascendente é possivel. O UE deve realizar ações conforme esboçado em 3GPP 25.331, incluindo o processo de seleção de célula conforme definido em 3GPP TS 25.304. Este estado é similar a CELL_PCH, exceto pelo fato de que o procedimento URA UPDATE é disparado apenas através de uma resseleção de Área de Registro de UTRAN (URA).

A transição de um modo inativo para o conectado e vice-versa é controlada pela UTRAN. Quando um UE em modo inativo requisita uma conexão de RRC, a rede decide se é para mover o UE para o estado CELL_DCH ou CELL_FACH. Quando o UE está em um modo conectado de RRC, novamente é a rede que decide quando liberar a conexão de RRC. A rede também move o UE de um estado de RRC para um outro, antes da liberação da conexão. As transições de estado tipicamente são disparadas por uma atividade de dados ou inatividade entre o UE e a rede. Uma vez que a rede não pode saber quando o UE completou a troca de dados, tipicamente, mantém a conexão de RRC por algum tempo em antecipação de mais dados para / do UE. Isto tipicamente é feito para a redução da latência de estabelecimento de chamada e estabelecimento de portadora de rádio (radio bearer). A mensagem de liberação de conexão de RRC pode ser enviada apenas pela UTRAN. Esta mensagem libera a conexão de enlace de sinal e todas as portadoras de rádio entre o UE e a UTRAN. O problema com o dito acima é que, mesmo se um aplicativo no UE tiver completado sua transação de dados e não estiver esperando qualquer troca adicional de dados, ele ainda espera que a rede o mova para o estado correto. A rede pode não estar mesmo ciente do fato de que o aplicativo no UE tiver completado sua troca de dados. Por exemplo, um aplicativo no UE pode usar seu próprio protocolo baseado em reconhecimento para troca de dados com seu servidor de aplicativo o qual é conectado à rede de núcleo de UMTS. Os exemplos são aplicativos que rodam por UDP/IP implementando seu próprio envio garantido. Nesse caso, o UE sabe se o servidor de aplicativo enviou ou recebeu todos os pacotes de dados ou não e está em uma posição melhor para determinar se qualquer troca de dados adicional for para ocorrer e dai decidir quando terminar a conexão de RRC. Uma vez que a UTRAN controla quando o estado conectado de RRC é mudado para um estado diferente, menos intensivo na bateria, ou para um modo inativo, e o fato de que a UTRAN não está ciente do status do envio de dados entre o UE e o servidor externo, o UE é forçado a ficar em uma taxa de dados mais alta e um estado de bateria intensivo do que o estado ou modo requerido, desse modo drenando a vida da bateria e perdendo recursos de rede. Os presentes sistema e método eliminam certas deficiências da técnica anterior pela provisão da transição de um modo conectado de RRC para um estado ou modo mais eficiente de bateria. Em particular, os presentes métodos e aparelho preferencialmente provêem uma transição com base no UE iniciando uma terminação de uma conexão de sinalização para um dominio de rede de núcleo especifica ou indicando para a UTRAN que uma transição deve ocorrer de um estado conectado para um outro.

Em particular, se um aplicativo no UE determinar que isto é feito com a troca de dados, ele preferencialmente envia uma indicação de "feito" para o componente de "gerenciador de conexão de RRC" do software de UE. O gerenciador de conexão de RRC mantém um acompanhamento de todos os aplicativos existentes (incluindo aqueles provendo um serviço por um ou múltiplos protocolos), contextos de Protocolo de Dados de Pacote (PDP) associados, portadoras de rádio de pacote comutado (PS) associadas e portadoras de rádio de circuito comutado (CS) associadas. Um contexto de PDP é uma associação lógica entre um UE e uma PDN (Rede de Dados Pública) rodando através de uma rede de núcleo de UMTS. Um ou múltiplos aplicativos (por exemplo, um aplicativo de e-mail e um aplicativo navegador) no UE podem ser associados a um contexto de PDP. Em alguns casos, um aplicativo no UE está associado a um contexto de PDP primário e múltiplos aplicativos podem estar ligados a contextos de PDP secundários. O Gerenciador de Conexão de RRC recebe indicações de "feito" de diferentes aplicativos nos UE que estão simultaneamente ativos. Por exemplo, o usuário pode receber um e-mail de um servidor push enquanto navega pela web. Após o aplicativo de e-mail ter enviado um reconhecimento, ele pode indicar que completou sua transação de dados, embora o aplicativo navegador possa não enviar essa indicação. Com base em um status compósito dessas indicações de aplicativos ativos, o software de UE pode decidir quanto tempo esperar antes de poder iniciar uma liberação de conexão de sinalização do dominio de serviço de pacote de rede de núcleo. Um atraso neste caso pode ser introduzido para se garantir que o aplicativo tenha verdadeiramente terminado a troca de dados e não requeira uma conexão de RRC. O atraso pode ser dinâmico, com base no histórico de tráfego e/ou em perfis de aplicativo. Sempre que o gerenciador de conexão de RRC determinar com alguma probabilidade não se espera que nenhum aplicativo troque quaisquer dados, ele pode enviar um procedimento de indicação de liberação de conexão de sinalização para o dominio apropriado (por exemplo, o domínio de PS). Alternativamente, ele pode enviar uma requisição por uma transição de estado no modo conectado para UTRAN.

A decisão acima também pode levar em consideração se a rede suporta o estado URA_PCH e o comportamento de transição para este estado.

A transição iniciada por UE para o modo inativo pode acontecer a partir de qualquer estado do modo conectado de RRC e terminar tendo a rede liberando a conexão de RRC e se movendo para o modo inativo. O UE estando no modo inativo, conforme será apreciado por aqueles versados na técnica, é muito menos intensivo quanto à bateria do que o UE estando em um estado conectado. O presente pedido, portanto, preferencialmente provê um método para uma performance melhorada de bateria de equipamento de usuário em uma rede sem fio tendo múltiplos estados de controle de recurso de rádio (RRC), compreendendo as etapas de: monitoração, no equipamento de usuário, de uma troca de dados de aplicativo; determinar quando não se espera que nenhum aplicativo no equipamento de usuário troque dados; e iniciar, a partir do equipamento de usuário, uma transição para um estado ou modo de controle de recurso de rádio demandando menos bateria. O presente pedido ainda provê preferencialmente um equipamento de usuário adaptado para redução do consumo de bateria em uma rede de UMTS, o equipamento de usuário tendo um subsistema de rádio incluindo um rádio adaptado para comunicação com a rede de UMTS; um processador de rádio tendo um processador de sinal digital e adaptado para interagir com o referido subsistema de rádio; uma memória; uma interface de usuário; um processador adaptado para rodar aplicativos de usuário e interagir com a memória, o rádio e a interface de usuário adaptados para rodarem aplicativos, o equipamento de usuário caracterizado por ter meios para: a monitoração, no equipamento de usuário, de uma troca de dados de aplicativo; determinar quando não se espera que nenhum aplicativo no equipamento de usuário troque dados; e iniciar, a partir do equipamento de usuário, uma transição para um estado ou modo de controle de recurso de rádio demandando menos bateria.

BREVE DESCRIÇÃO DOS DESENHOS

O presente aplicativo será mais bem compreendido com referência aos desenhos, nos quais: a Figura 1 é um diagrama de blocos que mostra estados e transições de RRC; a Figura 2 é um esquema de uma rede de UMTS que mostra várias células de UMTS e uma URA; a Figura 3 é um diagrama de blocos que mostra os vários estágios em um estabelecimento de conexão de RRC; a Figura 4A é um diagrama de blocos de uma transição de exemplo entre um estado de modo conectado CELL_DCH e um modo inativo iniciado pela UTRAN de acordo com o método atual; a Figura 4B é um diagrama de blocos que mostra uma transição de exemplo entre uma transição de modo conectado de estado CELL_DCH para um modo inativo de acordo com os presentes método e aparelho; a Figura 5A é um diagrama de blocos de uma transição de exemplo entre uma inatividade de CELL_DCH para uma inatividade para um modo inativo iniciado pela UTRAN de acordo com o método atual; a Figura 5B é um diagrama de blocos de uma transição de exemplo entre inatividade de CELL_DCH e um modo inativo de acordo com o presente método; a Figura 6 é um diagrama de blocos de uma pilha de protocolo de UMTS; a Figura 7 é um UE de exemplo que pode ser usado em associação com o presente método; e a Figura 8 é uma rede de exemplo para uso em associação com os presentes método e aparelho.

DESCRIÇÃO DE MODALIDADES PREFERIDAS

A referência é feita, agora, à Figura 1. A Figura 1 é um diagrama de blocos que mostra os vários modos e estados para a porção de controle de recurso de rádio de uma pilha de protocolo em uma rede de UMTS. Em particular, o RRC pode estar em um estado inativo de RRC 110 ou um estado conectado de RRC 120.

Conforme será apreciado por aqueles versados na técnica, uma rede de UMTS consiste em dois segmentos de rede baseados em terra. Estes são o Rede de Núcleo (CN) e a Rede de Acesso por Rádio Terrestre Universal (UTRAN) (conforme ilustrado na Figura 8). A Rede de Núcleo é responsável pela comutação e pelo roteamento de chamadas de dados e de conexões de dados para as redes externas, enquanto a UTRAN lida com todas as funcionalidades relacionadas a rádio.

No modo inativo 110, o UE deve requisitar uma conexão de RRC para o estabelecimento do recurso de rádio, sempre que dados precisarem ser trocados entre o UE e a rede. Isto pode ser como resultado de um aplicativo no UE requerendo uma conexão para o envio de dados, ou como resultado do UE monitorando um canal de envio de radiochamada para indicar se a UTRAN ou o SGSN enviou uma radiochamada para o UE para o recebimento de dados a partir de uma rede de dados externa, tal como um servidor push. Além disso, o UE também requisita uma conexão de RRC sempre que precisar enviar uma mensagem de sinalização de Gerenciamento de Mobilidade, tal como uma Atualização de Área de Localização.

Uma vez que o UE tenha enviado uma requisição para a UTRAN para o estabelecimento de uma conexão de rádio, a UTRAN escolhe um estado para a conexão de RRC estar. Especificamente, o modo conectado de RRC 120 inclui quatro estados separados. Estes são o estado CELL_DCH 122, o estado CELL_FACH 124, o estado CELL_PCH 126 e o estado URA_PCH 128.

A partir do modo inativo 110, o estado conectado de RRC pode ir para o estado de Canal Dedicado de Célula (CELL_DCH) 122 ou o estado de Canal de Acesso de Emissão de Célula (CELL_FACH) 124.

No estado CELL_DCH 122, um canal dedicado é alocado ao UE para um enlace ascendente e para um enlace descendente para uma troca de dados. Este estado, uma vez que tem um canal fisico dedicado alocado ao UE, tipicamente requer a maior potência de bateria do UE.

Alternativamente, a UTRAN pode se mover do modo inativo 110 para um estado CELL_FACH 124. Em um estado CELL_FACH, nenhum canal dedicado é alocado ao UE. Ao invés disso, canais comuns são usados para o envio de uma sinalização em uma quantidade pequena de dados em rajada. Contudo, o UE ainda tem de monitorar continuamente o FACH e, portanto, ele consume potência de bateria.

No modo conectado de RRC 120, o estado de RRC pode ser mudado a critério da UTRAN. Especificamente, se uma inatividade de dados for detectada para uma quantidade especifica de tempo ou uma produção de dados abaixo de um certo limite for detectada, a UTRAN pode se mover do estado de RRC do estado CELL_DCH 122 para o estado CELL_FACH 124, o estado CELL_PCH 126 ou o estado URA_PCH 128. De modo similar, se a carga útil for detectada como estando acima de um certo limite, então, o estado de RRC pode ser movido de estado CELL_FACH 124 para estado CELL_DCH 122.

A partir do estado CELL_FACH 124, se uma inatividade de dados for detectada por um tempo predeterminado em algumas redes, a UTRAN pode mover o estado de RRC de estado CELL_FACH 124 para um estado de canal de envio de radiochamada (PCH) Isto pode ser o estado CELL_PCH 126 ou o estado URA_PCH 128.

A partir do estado CELL_PCH 126 ou do estado URA_PCH 128, o UE deve se mover para o estado CELL_FACH 124, de modo a iniciar um procedimento de atualização para requisição de um canal dedicado. Este é a única transição de estado que o UE controla. O estado CELL_PCH 126 e o estado URA_PCH 128 usam um ciclo de recepção descontinuo (DRX) para a monitoração de mensagens de difusão e radiochamadas por um Canal Indicador de Envio de Radiochamada (PICH). Nenhuma atividade de enlace ascendente é possivel.

A diferença entre o estado CELL_PCH 126 e o estado URA_PCH 128 é que o estado URA_PCH apenas dispara um procedimento de Atualização de URA se a área atual de registro de UTRAN (URA) dos UEs não estiver dentre a lista de identidades de URA presentes na célula atual. Especificamente, uma referência é feita à Figura 2. A Figura 2 mostra uma ilustração de várias células de UMTS 210, 212 e 214. Todas estas células requerem um procedimento de atualização de célula, se resselecionadas para um estado CELL_PCH. Contudo, em uma área de registro de UTRAN, cada uma estará na mesma área de registro de UTRAN 220 e, assim, um procedimento de atualização de URA não é disparado quando se movendo entre 210, 212 e 214, quando em um modo de URA_PCH.

Conforme visto na Figura 2, outras células 218 estão fora da URA 220, e podem ser parte de uma URA separada ou não ser de nenhuma URA.

Conforme será apreciado por aqueles versados na técnica, a partir de uma perspectiva de vida de bateria, o estado inativo provê o uso de bateria mais baixo, se comparado com os estados acima. Especificamente, devido ao fato de ser requerido que o UE monitore o canal de envio de radiochamada apenas em intervalos, o rádio não precisa estar continuamente ativo, mas, ao invés disso, pode despertar periodicamente. A transigência para isto é a latência para o envio de dados. Contudo, se esta latência não for grande demais, as vantagens de estar no modo inativo e de economizar potência de bateria pesam mais do que as desvantagens da latência de conexão.

Uma referência é feita novamente à Figura 1. Vários fornecedores de infra-estrutura de UMTS se movem entre os estados 122, 124, 126 e 128 com base em vários critérios. As infra-estruturas de exemplo são esboçadas abaixo.

Em uma primeira infra-estrutura de exemplo, o RRC se move entre um modo inativo e um estado Cell_DCH diretamente. No estado Cell_DCH, se dois segundos de inatividade forem detectados, o estado de RRC mudará para um estado CELL_FACH 124. Se no estado CELL_FACH 124, dez segundos de inatividade forem detectados, então, o estado de RRC mudará para o estado PCH 126. Quarenta e cinco minutos de inatividade nos estados CELL_PCH 126 resultará no estado de RRC se mover de volta para o modo inativo 110.

Em uma segunda infra-estrutura de exemplo, uma transição de RRC pode ocorrer entre um modo inativo 110 e um modo conectado 120, dependendo de um limite de carga útil. Na segunda infra-estrutura, se a carga útil estiver abaixo de um certo limite, então, a UTRAN moverá o estado de RRC para o estado CELL_FACH 124. Inversamente, se os dados estiverem acima de um certo limite de carga útil, então, a UTRAN moverá o estado de RRC para um estado CELL_DCH 122. Na segunda infra-estrutura, se dois minutos de inatividade forem detectados no estado CELL_DCH 122, a UTRAN moverá o estado de RRC para um estado CELL_FACH 124. Após cinco minutos de inatividade no estado CELL_FACH 124, a UTRAN move o estágio de RRC para o estado CELL_PCH 12 6. No estado CELL_PCH 126, duas horas de inatividade são requeridas antes de se mover de volta para o modo inativo 110.

Em uma terceira infra-estrutura de exemplo, um movimento entre um modo inativo e um modo conectado 120 é sempre para o estado CELL_DCH 122. Após cinco segundos de inatividade no estado CELL_DCH 122, a UTRAN move o estado de RRC para o estado CELL FACH 12 4. Trinta segundos de inatividade no estado CELL_FACH 124 resultam no movimento de volta para o modo inativo 110.

Em uma quarta infra-estrutura de exemplo, o RRC transita de um modo inativo para um modo conectado diretamente para um estado CELL_DCH 122. Na quarta infra- estrutura de exemplo, o estado CELL_DCH 122 inclui dois subestados. 0 primeiro inclui um subestado o qual tem uma alta taxa de dados, e um segundo subestado inclui uma taxa de dados mais baixa, mas ainda no estado CELL_DCH. Na quarta infra-estrutura de exemplo, o RRC transita do modo inativo 110 diretamente para o subestado CELL_DCH de alta taxa de dados. Após 10 segundos de inatividade, o estado de RRC transita para um estado CELL_DCH de taxa de dados baixa. Dezessete segundos de inatividade a partir do estado CELL_DCH de dados baixa 122 resultam no estado de RRC mudá- lo para o modo inativo 110.

As quatro infra-estruturas de exemplo acima mostram como vários fornecedores de infra-estrutura de UMTS estão implementando os estados. Conforme será apreciado por aqueles versados na técnica, em cada caso, se o tempo gasto na troca de dados reais (tal como um e-mail) for significativamente curto, se comparado com o tempo que é requerido para se ficar nos estados CELL_DCH ou CELL_FACH, isto causa um dreno de corrente desnecessário, o qual torna a experiência do usuário em redes de geração mais nova, tal como a UMTS, pior do que nas redes de geração anterior, tal como GPRS.

Ainda, embora o estado CELL_PCH seja melhor do que o estado CELL_FACH de uma perspectiva de vida de bateria, o ciclo de DRX em um estado CELL PCH tipicamente é regulado para um valor mais baixo do que o modo inativo 110. Como resultado, é requerido que o UE desperte mais frequentemente no estado CELL_PCH do que em um modo inativo. O estado URA_PCH com um ciclo de DRX similar àquele do estado inativo é provavelmente a transigência entre vida de bateria e latência para conexão. Contudo, URA_PCH atualmente não é suportado na UTRAN. Portanto, é desejável transitar rapidamente para o modo inativo tão rapidamente quanto possivel, após um aplicativo ter terminado a troca de dados de uma perspectiva de vida de bateria.

Uma referência é feita, agora, à Figura 3. Quando transitando de um modo inativo para um modo conectado, várias conexões de sinalização e de dados precisam ser feitas. Com referência à Figura 3, o primeiro item que precisa ser realizado é um estabelecimento de conexão de RRC. Conforme indicado acima, este estabelecimento de conexão de RRC pode ser destruido apenas pela UTRAN.

Uma vez que o estabelecimento de conexão de RRC 310 seja realizado, um estabelecimento de conexão de sinalização 312 é começado.

Uma vez que o estabelecimento de sinalização 312 tenha terminado, um estabelecimento de codificação e integridade 314 é começado. Mediante a conclusão disto, um estabelecimento de portadora de rádio 316 é realizado. Neste ponto, os dados podem ser trocados entre o UE e a UTRAN.

A destruição da conexão é realizada de forma similar na ordem inversa, em geral. O estabelecimento de portadora de rádio 316 é derrubado e, então, o estabelecimento de conexão de RRC 310 é derrubado. Neste ponto, o RRC se move para o modo inativo 110, conforme ilustrado na Figura 1.

Embora a especificação 3GPP de corrente não permita que o UE libere a conexão de RRC ou indique sua preferência por um estado de RRC, o UE ainda pode indicar a terminação de uma conexão de sinalização para um dominio de rede de núcleo especificado, como o dominio de Pacote Comutado (PS) usado por aplicativos de pacote comutado. De acordo com a seção 8.1.14.1 de 3GPP TS 25.331: O procedimento de indicação de liberação de conexão de sinalização é usado pelo UE para indicar para a UTRAN que uma de suas conexões de sinalização foi liberada. Este procedimento, por sua vez, pode iniciar um procedimento de liberação de conexão de RRC.

Assim, estando nas especificações 3GPP de corrente, a liberação de conexão de sinalização pode ser iniciada mediante a destruição do estabelecimento de conexão de sinalização 312. Está na capacidade do UE destruir o estabelecimento de conexão de sinalização 312, e isto, por sua vez, de acordo com a especificação "pode" iniciar a liberação de conexão de RRC.

Conforme será apreciado por aqueles versados na técnica, se um estabelecimento de conexão de sinalização 312 for destruido, a UTRAN também precisará limpar o estabelecimento de decodificação e integridade 312 e o estabelecimento de portadora de rádio 316, após o estabelecimento de conexão de sinalização 312 ter sido destruido.

Se um estabelecimento de conexões de sinalização 312 for destruído, o estabelecimento de conexão de RRC é desarticulado pela rede para as infra-estruturas de fornecedor atuais.

Usando o dito acima, se o UE determinar que terminou com a troca de dados, por exemplo, se um componente de "gerenciador de conexão de RRC" do software de UE for provido com uma indicação de que a troca de dados está completa, então, o gerenciador de conexão de RRC pode determinar se é ou não para destruir o estabelecimento de conexão de sinalização 312. Por exemplo, um aplicativo de e-mail no dispositivo envia uma indicação de que ele recebeu um reconhecimento do servidor de e-mail de push de que o e-mail de fato foi recebido pelo servidor push. O gerenciador de RRC pode manter um acompanhamento de todos os aplicativos existentes, contextos de PDP associados, portadoras de rádio de PS associadas e portadoras de rádio de circuito comutado (CS) associadas. Um atraso neste caso pode ser introduzido para se garantir que o aplicativo tenha verdadeiramente acabado com a troca de dados e não possa mais requerer uma conexão de RRC, mesmo após ter enviado a indicação de "feito". Este atraso é equivalente a uma expiração de inatividade associada ao aplicativo. Cada aplicativo pode ter sua própria expiração de inatividade. Por exemplo, um aplicativo de e-mail pode ter uma expiração de inatividade de cinco segundos, ao passo que um aplicativo navegador ativo pode ter uma expiração de sessenta segundos. Com base em um status compósito de todas essas indicações dos aplicativos ativos, o software de UE decide quanto deve esperar antes de poder iniciar uma liberação de conexão de sinalização da rede de núcleo apropriada (por exemplo, Dominio de PS).

A expiração de inatividade pode ser feita com base em um histórico de padrão de tráfego e/ou em um perfil de aplicativo.

Sempre que o gerenciador de conexão de RRC determinar com alguma probabilidade que não se espera que nenhum aplicativo troque dados, ele pode enviar um procedimento de indicação de liberação de conexão de sinalização para o dominio apropriado.

A transição iniciada por UE acima para o modo inativo pode ocorrer em qualquer estágio do modo conectado de RRC 120, conforme ilustrado na Figura 1, e termina tendo a liberação da rede da conexão de RRC e se movendo para um modo inativo 110, conforme ilustrado na Figura 1. Isto também é aplicável quando o UE estiver executando quaisquer serviços de dados de pacote durante uma chamada de voz. Neste caso, apenas o dominio de PS é liberado, mas o dominio de CS permanece conectado.

Conforme será apreciado por aqueles versados na técnica, em alguns casos pode ser mais desejável estar no estado de modo conectado URA_PCH do que no modo inativo. Por exemplo, se for requerido que a latência por conexão para os estados de modo conectado CELL_DCH ou CELL_FACH seja baixa, é preferível estar em um estado de PCH de modo conectado. Há duas formas de se realizar isso. A primeira é pela mudança das especificações 3GPP para se permitir que o UE requisite que a UTRAN o mova para um estado especifico, neste caso, o estado URA_PCH 128.

Alternativamente, o gerenciador de conexão de RRC pode levar em consideração outros fatores, tal como em que estado a conexão de RRC está atualmente. Se, por exemplo, a conexão de RRC estiver no estado URA_PCH, ele pode decidir que é desnecessário se mover para o modo inativo 110 e, assim, nenhum procedimento de liberação de conexão de Sinalização é iniciado.

Uma referência é feita à Figura 4. A Figura 4A mostra uma implementação de UMTS atual de acordo com o exemplo de infra-estrutura "quatro" acima. Conforme ilustrado na Figura 4, o tempo é através dos eixos geométricos horizontais. O UE começa no modo inativo de RRC 110 e, com base nos dados locais precisando ser transmitidos ou em uma radiochamada recebida a partir da UTRAN, começa o estabelecimento de uma conexão de RRC.

Conforme ilustrado na Figura 4A, o estabelecimento de conexão de RRC 310 ocorre primeiramente, e o estado de RRC é um estado de conexão 410 durante este tempo.

Em seguida, o estabelecimento de conexões de sinalização 312, o estabelecimento de codificação e integridade 314 e um estabelecimento de portadora de rádio 316 ocorrem. 0 estado de RRC é o estado CELL_DCH 122 durante isto. Conforme ilustrado na Figura 4A, o tempo para se mover de RRC inativo até o tempo em que a portadora de rádio é estabelecida é de aproximadamente dois segundos, neste exemplo.

Os dados em seguida são trocados. No exemplo da Figura 4A, isto é obtido em torno de dois a quatro segundos e é conforme ilustrado pela etapa 420.

Após os dados serem trocados na etapa 420, nenhum dado está sendo trocado, exceto pelo PDU de sinalização de RLC intermitente, conforme requerido, e, assim, a portadora de rádio é reconfigurada pela rede para se mover para um estado DCH de taxa de dados mais baixa após aproximadamente dez segundos. Isto é ilustrado nas etapas 422 e 424.

No estado DCH de taxa de dados mais baixa, nada é recebido por dezessete segundos, em cujo ponto a conexão de RRC é liberada pela rede na etapa 428.

Uma vez que a conexão de RRC seja iniciada na etapa 428, o estado de RRC prossegue para um estado de desconexão 430 por aproximadamente quarenta milissegundos, após o que o UE está em um estado inativo de RRC 110.

Também ilustrado na Figura 4A, o consumo de corrente de UE é ilustrado pelo periodo no qual o RRC está no estado CELL_DCH 122. Conforme visto, o consumo de corrente é de aproximadamente 200 a 300 miliampères pela duração inteira do estado CELL_DCH. Enquanto desconectado e inativo, em torno de 3 miliampères são utilizados, assumindo-se um ciclo de DRX de 1,28 segundos. Contudo, os 35 segundos de consumo de potência a de 200 a 300 miliampères estão drenando a bateria.

Uma referência é feita agora à Figura 4B. A Figura 4B utiliza a mesma infra-estrutura de exemplo "quatro" a partir de acima, apenas agora implementando a liberação de conexão de sinalização.

Conforme ilustrado na Figura 4B, as mesmas etapas de estabelecimento 310, 312, 314 e 316 ocorrem, e isto leva a mesma quantidade de tempo quando se move entre o estado inativo de RRC 110 e o estado CELL_DCH de RRC 122.

Ainda, a troca de PDU de dados de RRC para o e-mail de exemplo da Figura 4A também é feita na Figura 4B, e isto leva aproximadamente de dois a quatro segundos.

O UE no exemplo da Figura 4B tem uma expiração de inatividade especifica de aplicativo, a qual, no exemplo da Figura 4B, é de dois segundos e é ilustrada pela etapa 440. Após o gerenciador de conexão de RRC ter determinado que há inatividade pela quantidade de tempo especificada, o UE libera o estabelecimento de conexão de sinalização na etapa 442 e a conexão de RRC é liberada pela rede na etapa 428.

Conforme ilustrado na Figura 4B, o consumo de corrente durante a etapa de CELL_DCH 122 ainda é de em torno de 200 a 300 miliampères. Contudo, o tempo de conexão é de apenas em torno de oito segundos. Conforme será apreciado por aqueles versados na técnica, uma quantidade de tempo consideravelmente mais curta do que o móvel fica no estado CELL_DCH 122 resulta em economias de bateria significativas para um dispositivo de UE sempre ativo.

Uma referência é feita agora à Figura 5. A Figura 5 mostra um segundo exemplo usando a infra-estrutura indicada acima como a infra-estrutura "três". Como com as Figuras 4A e 4B, um estabelecimento de conexão ocorre, o qual leva aproximadamente dois segundos. Isto requer o estabelecimento de conexão de RRC 310, o estabelecimento de conexão de sinalização 312, o estabelecimento de codificação e integridade 314 e o estabelecimento de portadora de rádio 316.

Durante este estabelecimento, o UE se move do modo inativo de RRC 110 para um estado CELL_DCH 122 com uma etapa de conexão de estado de RRC 410 entre eles.

Conforme com a Figura 4A, na Figura 5A, uma troca de PDU de dados de RLC ocorre e, no exemplo da Figura 5A, leva de dois a quatro segundos.

De acordo com a infra-estrutura três, a troca de PDU de dados de RLC não recebe nenhum dado e, assim, está inativa por um periodo de cinco segundos na etapa 422, exceto pelo PDU de sinalização de RLC intermitente, conforme requerido, em cujo ponto a portadora de rádio reconfigura a rede para se mover para um estado CELL_FACH 124 a partir do estado CELL_DCH 122. Isto é feito na etapa 450.

No estado CELL_FACH 124, a troca de PDU de sinalização de RLC descobre que não há nenhum dado exceto pelo PDU de sinalização de RLC intermitente, conforme requerido, por uma quantidade de tempo predeterminada, neste caso trinta segundos, em cujo ponto uma liberação de conexão de RRC pela rede é realizada na etapa 428.

Conforme visto na Figura 5A, isto move o estado de RRC para o modo inativo 110.

Conforme visto adicionalmente na Figura 5A, o consumo de corrente durante o modo de DCH está entre 200 e 300 miliampères. Quando se movendo para o estado CELL_FACH 124, o consumo de corrente diminui para aproximadamente de 120 a 180 miliampères. Após o conector de RRC ser liberado e o RRC se mover para o modo inativo 110, o consumo de potência é de aproximadamente 3 miliampères. O estado de Modo Conectado de RRC de utra sendo estado CELL_DCH 122 ou estado CELL_FACH 124 dura por aproximadamente quarenta segundos no exemplo da Figura 5A.

Uma referência é feita agora à Figura 5B. A Figura 5B ilustra a mesma infra-estrutura "três" conforme na Figura 5A, com o mesmo tempo de conexão de em torno de dois segundos para se obterem o estabelecimento de conexão de RRC 310, o estabelecimento de conexão de sinalização 312, o estabelecimento de codificação e integridade 314 e o estabelecimento de portadora de rádio 316. Ainda, a troca de PDU de dados de RLC 42 0 ocorre em aproximadamente de dois a quatro segundos.

Como com a Figura 4B, o aplicativo de UE detecta uma expiração de inatividade especifica na etapa 440, em cujo ponto o procedimento de indicação de liberação de conexão de Sinalização é iniciado pelo UE e, como uma consequência, a conexão de RRC é liberada pela rede na etapa 448.

Conforme pode ser visto adicionalmente na Figura 5B, o RRC começa em um modo inativo 110, se move para o estado CELL_DCH 122, sem prosseguir para o estado CELL_FACH.

Conforme será visto adicionalmente na Figura 5B, um consumo de corrente é de aproximadamente 200 a 300 miliampères no momento em que o estágio de RRC está no estado CELL_DCH 122, o qual, de acordo com o exemplo da Figura 5, é de aproximadamente oito segundos.

Portanto, uma comparação entre as Figuras 4A e 4B e as Figuras 5A e 5B mostra que uma quantidade significativamente de consumo de corrente é eliminada, desse modo se estendendo a vida da bateria do UE significativamente. Conforme será apreciado por aqueles versados na técnica, o dito acima ainda pode ser usado no contexto de especificações de 3GPP atuais.

Uma referência é feita agora à Figura 6. A Figura 6 ilustra uma pilha de protocolo para uma rede de UMTS.

Conforme visto na Figura 6, a UMTS inclui um plano de controle de CS 610, um plano de controle de PS 611 e um plano de usuário de PS 630.

Nestes três planos, uma porção de estrato não de acesso (NAS) 614 e uma porção de estrato de acesso 616 existem.

A porção de NAS 614 no plano de controle de CS 610 inclui um controle de chamada (CC) 618, serviços suplementares (SS) 620 e um serviço de mensagem curta (SMS) 622.

A porção de NAS 614 no plano de controle de PS 611 inclui um gerenciamento de mobilidade (MM) e um gerenciamento de mobilidade de GPRS (GMM) 626. Ela ainda inclui SM / RABM 624 e GSMS 628. O CC 618 provê uma sinalização de gerenciamento de chamada para serviços de circuito comutado. A porção de gerenciamento de sessão de SM / RABM 624 provê a ativação de contexto de PDP, a desativação e uma modificação. O SM / RABM 624 também provê uma negociação de qualidade de serviço.

A função principal da porção de RABM do SM / RABM 624 é conectar um contexto de PDP a uma Portadora de Acesso por Rádio. Assim, o SM / RABM 624 é responsável pelo estabelecimento, pela modificação e pela liberação de portadoras de rádio. O plano de controle de CS 610 e o plano de controle de PS 611 no estrato de acesso 616 fazem parte do controle de recurso de rádio (RRC) 617.

A porção de NAS 614 no plano de usuário de PS 630 inclui uma camada de aplicativo 638, uma camada de TCP/UDP 636 e uma camada de PDP 634. A camada de PDP 634 pode incluir, por exemplo, um protocolo de internet (IP). O estrato de acesso 616 no plano de usuário de PS 630 inclui um protocolo de convergência de dados de pacote (PDCP) 632. O PDCP 632 é projetado para tornar o protocolo de WCDMA adequado para portar um protocolo de TCP/IP entre o UE e um RNC (conforme visto na Figura 8) e, opcionalmente, é para compressão e descompressão de cabeçalho de protocolo de tráfego de IP.

As camadas de Controle de Enlace por Rádio (RLC) de UMTS 640 e de Controle de Acesso a Meio (MAC) 650 formam as subcamadas de enlace de dados da interface de rádio de UMTS e residem no nó de RNC e no Equipamento de Usuário.

A camada de UMTS de Camada 1 (Ll) (camada fisica 650) está abaixo das camadas de RLC/MAC 640 e 650. Esta camada é a camada fisica para comunicações.

Embora o dito acima possa ser implementado em uma variedade de dispositivos móveis, um exemplo de um dispositivo móvel e esboçado abaixo com respeito à Figura 7. Uma referência é feita agora à Figura 7. O UE 1100 preferencialmente é um dispositivo de comunicação sem fio de duas vias que tem pelo menos capacidades de comunicação de voz e de dados. O UE 1100 preferencialmente tem a capacidade de se comunicar com outros sistemas de computador na Internet. Dependendo da funcionalidade exata provida, o dispositivo sem fio pode ser referido como um dispositivo de envio de mensagem de dados, um equipamento de radiochamada de duas vias, um dispositivo de e-mail sem fio, um telefone celular com capacidades de envio de mensagem de dados, uma ferramenta de Internet sem fio, ou um dispositivo de comunicação de dados, como exemplos.

Quando o UE 1100 está habilitado para uma comunicação de duas vias, ele incorporará um subsistema de comunicação 1111, incluindo um receptor 1112 e um transmissor 1114, bem como componentes associados, tais como um ou mais, preferencialmente embutidos ou internos, elementos de antena 116 e 118, osciladores locais (LOs) 1113, e um módulo de processamento, tal como um processador de sinal digital (DSP) 1120. Conforme será evidente para aqueles versados no campo de comunicações, o projeto em particular do subsistema de comunicação 1111 será dependente da rede de comunicação na qual se pretende que o dispositivo opere. Por exemplo, o UE 1100 pode incluir um subsistema de comunicação 1111 projetado para operar na rede de GPRS ou na rede de UMTS.

As exigências de acesso de rede também variação, dependendo do tipo de rede 1119. Por exemplo, em redes de UMTS e GPRS, o acesso de rede está associado a um assinante ou usuário de UE 1100. Por exemplo, um dispositivo móvel de GPRS, portanto, requer um cartão de módulo de inserção de assinante (SIM) de modo a operar em uma rede de GPRS. Em UMTS, um módulo de USIM ou SIM é requerido, em CDMA, um cartão de RUIM ou módulo pode ser requerido. Estes serão referidos aqui como uma interface de UIM aqui. Sem uma interface de UIM válida, um dispositivo móvel não pode estar plenamente funcional. As funções de comunicação local ou não de rede, bem como funções legalmente requeridas (Se houver) , tal como uma chamada de emergência, podem estar disponíveis, mas o dispositivo móvel 1100 será incapaz de realizar quaisquer outras funções envolvendo comunicações pela rede 1100. A interface de UIM 1144 normalmente é similar a um slot de cartão no qual um cartão pode ser inserido e ejetado como um disquete ou um cartão PCMCIA. 0 cartão de UIM pode ter aproximadamente 64K de memória e manter muitas configurações chaves 1151, e uma outra informação 1153, tal como uma identificação, e uma informação relacionada a assinante.

Quando os procedimentos requeridos de registro ou ativação de rede tiverem sido completados, o UE 1100 pode enviar e receber sinais de comunicação pela rede 1119. Os sinais recebidos pela antena 1116 através da rede de comunicação 1119 são introduzidos no receptor 1112, o qual pode realizar funções comuns de receptor, tais como amplificação de sinal, conversão para baixo de freqüência, filtração, seleção de canal e similares, e, no sistema de exemplo mostrado na Figura 7, uma conversão de analógico para digital (A/D) . A conversão A/D de um sinal recebido permite que funções de comunicação mais complexas, tais como demodulação e decodificação sejam realizadas no DSP 1120. De uma maneira similar, os sinais a serem transmitidos são processados, incluindo modulação e codificação, por exemplo, pelo DSP 1120 e introduzidos no transmissor 1114, para conversão de digital para analógico, conversão para cima de freqüência, filtração, amplificação e transmissão pela rede de comunicação 1119 através da antena 1118. O DSP 1120 não apenas processa sinais de comunicação, mas também provê um controle de receptor e transmissor. Por exemplo, os ganhos aplicados aos sinais e comunicação no receptor 1112 e no transmissor 1114 podem ser controlados de forma adaptativa através de algoritmos de controle de ganho automáticos implementados no DSP 1120.

A rede 1119 ainda pode se comunicar com múltiplos sistemas, incluindo um servidor 1160 e outros elementos (não mostrados). Por exemplo, a rede 1119 pode se comunicar com um sistema de empresa e um sistema cliente da web, de modo a acomodar vários clientes com vários niveis de serviço. O UE 1110 preferencialmente inclui um microprocessador 1138, o qual controla a operação geral do dispositivo. Funções de comunicação, incluindo pelo menos comunicações de dados, são realizadas através do subsistema de comunicação 1111. O microprocessador 1138 também interage com subsistemas de dispositivo adicionais, tais como o visor 1122, a memória flash 1124, a memória de acesso randômico (RAM) 1126, os subsistemas de entrada / saida auxiliares (I/O) 1128, a porta serial 1130, o teclado 1132, o alto-falante 1134, o microfone 1136, um subsistema de comunicações de faixa curta 1140 e quaisquer outros subsistemas de dispositivo geralmente designados como 1142.

Alguns dos subsistemas mostrados na Figura 7 realizam funções relacionadas à comunicação, ao passo que outros subsistemas podem prover funções "residentes" ou no dispositivo. Notadamente, alguns subsistemas, tais como o teclado 1132 e o visor 1122, por exemplo, podem ser usados para funções relacionadas à comunicação, tal como a entrada de uma mensagem de texto para transmissão por uma rede de comunicação, e funções residentes em dispositivo, tal como uma calculadora ou uma lista de tarefas. O software de sistema operacional usado pelo microprocessador 1138 preferencialmente é armazenado em um armazenamento persistente, tal como a memória flash 1124, a qual ao invés disso pode ser uma memória apenas de leitura (ROM) ou um elemento de armazenamento similar (não mostrado). Aqueles versados na técnica apreciarão que o sistema operacional, os aplicativos específicos de dispositivo ou partes dos mesmos podem ser temporariamente carregados em uma memória volátil, tal como a RAM 1126. Os sinais de comunicação recebidos também podem ser armazenados na RAM 1126. Ainda, um identificador único também é armazenado preferencialmente na memória apenas de leitura.

Conforme mostrado, a memória flash 1124 pode ser segregada em diferentes áreas para programas de computador 1158 e armazenamento de dados de programa 1150, 1152, 1154 e 1156. Estes tipos diferentes de armazenamento indicam que cada programa pode alocar uma porção da memória flash 1124 para suas próprias exigências de armazenamento de dados. O microprocessador 1138, além de suas funções de sistema operacional, preferencialmente permite a execução de aplicativos de software no dispositivo móvel. Um conjunto predeterminado de aplicativos que controla as operações básicas, incluindo pelo menos aplicativos de comunicação de dados e voz, por exemplo, normalmente será instalado no UE 1100 durante a fabricação. Um aplicativo de software preferido pode ser um aplicativo de gerenciador de informação pessoal (PIM) tendo a capacidade de organizar e gerenciar itens e dados relativos ao usuário do dispositivo móvel, tais como, mas não limitando, e-mail, eventos de calendário, correios de voz, compromissos e itens de tarefa. Naturalmente, um ou mais armazenamentos de memória estariam disponíveis no dispositivo móvel para facilitação do armazenamento de itens de dados de PIM. Esse aplicativo de PIM preferencialmente teria a capacidade de enviar e receber itens de dados, através da rede sem fio 1119. Em uma modalidade preferida, os itens de dados de PIM são integrados sem emendas, sincronizados e atualizados, através da rede sem fio 1119, com os itens de dados correspondentes do usuário de dispositivo móvel armazenados ou associados a um sistema de computador principal. Outros aplicativos também podem ser carregados no dispositivo móvel 1100 através da rede 1119, de um subsistema de I/O auxiliar 1128, da porta serial 1130, do subsistema de comunicações de faixa curta 1140 ou de gualguer outro subsistema adequado 1142, e instalados por um usuário na RAM 1126 ou, preferencialmente, em um armazenamento não volátil (não mostrado) para execução pelo microprocessador 1138. Essa flexibilidade na instalação de aplicativo aumenta a funcionalidade do dispositivo e pode prover funções melhoradas no dispositivo, funções relacionadas à comunicação ou ambas. Por exemplo, aplicativos de comunicação segura podem permitir que funções de comércio eletrônico e outras transações financeiras como essas sejam realizadas usando-se o UE 1100. Estes aplicativos, contudo, de acordo com o dito acima, em muitos casos, precisarão ser aprovados pela concessionária.

Em um modo de comunicação de dados, um sinal recebido, tal como uma mensagem de texto ou uma página da web transferida, será processado pelo subsistema de comunicação 1111 e introduzido no microprocessador 1138, o qual preferencialmente ainda processa o sinal recebido para extração para o visor 1122 ou, alternativamente, para um dispositivo de I/O auxiliar 1128. Um usuário do UE 1100 também pode compor itens de dados, tais como mensagens de e-mail, por exemplo, usando o teclado 1132, o qual preferencialmente é um teclado alfanumérico completo ou um teclado tipo de telefone, em conjunto com o visor 1122 e, possivelmente, um dispositivo de I/O auxiliar 1128. Esses itens compostos então podem ser transmitidos por uma rede de comunicação através do subsistema de comunicação 1111.

Para comunicações de voz, a operação geral do UE 1100 é similar, exceto pelo fato de que os sinais recebidos preferencialmente seriam extraídos para um alto-falante 1134 e os sinais para transmissão seriam gerados por um meio de indicação de violação 1136. Subsistemas alternativos de I/O de voz ou áudio, tal como um subsistema de gravação de mensagem de voz, também podem ser implementados no UE 1110. Embora uma extração de sinal de voz ou áudio preferencialmente seja realizada primariamente através do alto-falante 1134, o visor 1122 também pode ser usado para a provisão de uma indicação da identidade de uma parte chamando, da duração de uma chamada de voz ou de uma outra chamada de voz relacionada a uma informação, por exemplo.

A porta serial 1130 na Figura 7 normalmente seria implementada em um dispositivo móvel do tipo de assistente digital pessoal (PDA) para o qual uma sincronização com um computador de mesa de usuário (não mostrado) pode ser desejável. Uma porta como essa 1130 permitiria que um usuário estendesse as capacidades do dispositivo móvel 1100 pela provisão de outras transferências de informação ou de software para o UE 1100 além de através de uma rede de comunicação sem fio. O caminho de transferência alternativo pode ser usado, por exemplo, para o carregamento de uma chave de encriptação no dispositivo através de uma conexão direta e, assim, confiável e garantida para, desse modo, se habilitar uma comunicação de dispositivo segura.

Alternativamente, a porta serial 1130 poderia ser usada para outras comunicações e poderia incluir uma porta de barramento serial universal (USB). Uma interface está associada à porta serial 1130.

Outros subsistemas de comunicações 1140, tal como um subsistema de comunicações de faixa curta, é um componente opcional adicional, o qual pode prover comunicação entre o UE 1100 e diferentes sistemas ou dispositivos, os quais não precisam necessariamente ser dispositivos similares. Por exemplo, o subsistema 1140 pode incluir um dispositivo de infravermelho e circuitos associados e componentes ou um módulo de comunicação por Bluetooth™ para a provisão de comunicação com sistemas e dispositivos habilitados de forma similar.

Uma referência é feita agora à Figura 8. A Figura 8 é um diagrama de blocos de um sistema de comunicação 800 o qual inclui um UE 802, o qual se comunica através de uma rede de comunicação sem fio. O UE 802 se comunica de forma sem fio com um de múltiplos Nós Bs 806. Cada Nó B 806 é responsável por um processamento de interface de ar e algumas funções de gerenciamento de recurso de rádio. 0 Nó B 806 provê uma funcionalidade similar a uma Estação Base Transceptora em redes de GSM/ GPRS. O enlace sem fio mostrado no dispositivo de comunicação 800 da Figura 8 representa um ou mais canais diferentes, tipicamente canais de freqüência de rádio diferente (RF), e protocolos associados usados entre a rede sem fio e o UE 802. Uma interface de ar Uu 804 é usada entre o UE 802 e o Nó B 806.

Um canal de RF é um recurso limitado que deve ser conservado, tipicamente devido a limites na largura de banda geral e uma potência de bateria limitada do UE 802. Aqueles versados na técnica apreciarão que uma rede sem fio na prática real pode incluir centenas de células dependendo da expansão geral desejada de cobertura de rede. Todos os componentes pertinentes podem ser conectados por múltiplos comutadores e roteadores (não mostrados) , controlados por múltiplos controladores de rede.

Cada Nó B 806 se comunica com um controlador de rede de rádio (RNC) 810. O RNC 810 é responsável pelo controle dos recursos de rádio nesta área. Um RNC 810 controla múltiplos Nós Bs 806. O RNC 810 nas redes de UMTS provê funções equivalentes às funções de Controlador de Estação Base (BSC) em redes de GSM / GPRS. Contudo, um RNC 810 inclui mais inteligência, incluindo, por exemplo, gerenciamento de transferências autônomas sem o envolvimento de MSCs e SGSNs.

A interface usada entre o Nó B 806 e o RNC 810 é uma interface de lub 808 . Um protocolo de sinalização de NBAP (parte de aplicativo de Nó B) é primariamente usado, conforme definido em 3GPP TS 25.433 V3.11.0 (2002-09) e 3GPP TS 25.433 V5.7.0 (2004-01).

A Rede de Acesso por Rádio Terrestre Universal (UTRAN) 820 compreende o RNC 810, o Nó B 806 e a interface de ar Uu O tráfego de circuito comutado é roteado para o Centro de Comutação de Móvel (MSC) 830. O MSC 830 é o computador que faz as chamadas, e toma e recebe dados do assinante ou da PSTN (não mostrada). O tráfego entre o RNC 810 e o MSC 830 usa a interface lu-CS 828. A interface lu-CS 828 é uma conexão de circuito comutado para o transporte (tipicamente) de tráfego de voz e sinalização entre a UTRAN 820 e a rede de voz de núcleo. O protocolo de sinalização principal usado é RANAP (Parte de Aplicativo de Rede de Acesso por Rádio). O protocolo de RANAP é usado em uma sinalização de UMTS entre a Rede de Núcleo 821, a qual pode ser um MSC 830 ou uma SSGN 850 (definida em maiores detalhes abaixo) e a UTRAN 820. O protocolo de RANAP é definido em 3GPP TS 25.413 V3.11.1 (2002-09) e TS 25.413 V5.7.0 (2004-01).

Para todos os UEs 820 registrados em uma operadora de rede, dados permanentes (tal como o perfil de usuário de UE 102), bem como dados temporários (tal como a localização atual dos UEs 802) são armazenados em um registro de localização doméstica (HLR) 838. No caso de uma chamada de voz para o UE 802, o HLR 838 é consultado para se determinar a localização atual do UE 802. Um Receptor de Localização de Visitante (VLR) 836 de MSC 830 é responsável por um grupo de áreas de localização, e armazena os dados daquelas estações móveis que estão atualmente em sua área de responsabilidade. Isto inclui pares dos dados de estação móvel permanentes, que foram transmitidos a partir do HLR 838 para o VLR 836 para um acesso mais rápido. Contudo, o VLR 836 do MSC 830 também pode atribuir e armazenar dados locais, tais como identificações temporárias. O UE 802 também pode ser autenticado em um acesso de sistema pelo HLR 838. Os dados de pacote são roteados através do Nó de Suporte de GPRS de Serviço (SGSN) 850. O SGSN 850 é o gateway entre o RNC e a rede de núcleo em uma rede de GPRS / UMTS, e é responsável pelo envio de pacotes de dados a partir de e para os UEs em sua área geográfica de serviço. A interface de lu-PS 848 é usada entre o RNC 810 e o SGSN 850, e é a conexão de pacote comutado para o transporte (tipicamente) de tráfego de dados e sinalização entre a UTRAN 820 e a rede de dados de núcleo. O protocolo de sinalização principal usado é RANAP (descrito acima). O SGSN 850 se comunica com o Nó de Suporte de GPRS de Gateway (GGSN) 860. O GGSN 860 é a interface entre a rede de UMTS / GPRS e outras redes, tais como a internet ou redes privadas. O GGSN 860 é conectado a uma rede de dados pública PDN 870 por uma interface Gi.

Aqueles versados na técnica apreciarão que a rede sem fio pode ser conectada a outros sistemas, possivelmente incluindo outras redes, não mostradas explicitamente na Figura 8. Uma rede normalmente estará transmitindo no mínimo algum tipo de informação de envio de radiochamada e de sistema em uma base em andamento, mesmo se não houver dados reais de pacote trocados. Embora a rede consista em muitas partes, essas partes trabalham em conjunto para resultarem em certos comportamentos no enlace sem fio.

As modalidades descritas aqui são exemplos de estruturas, sistemas ou métodos tendo elementos correspondentes a elementos das técnicas deste pedido. Esta descrição por escrito pode permitir que aqueles versados na técnica façam e usem modalidades tendo elementos alternativos que, da mesma forma, correspondem aos elementos das técnicas deste pedido. 0 escopo pretendido 5 das técnicas deste pedido assim inclui outras estruturas, sistemas ou métodos que não diferem das técnicas deste pedido, conforme descrito aqui, e ainda inclui outras estruturas, sistemas ou métodos com diferenças substanciais das técnicas deste pedido, conforme descrito aqui.

Claims (29)

1. Método para melhorar a performance de um equipamento móvel de usuário (1100) usado com uma rede sem fio (1119) que tem múltiplos estados de controle de recurso de rádio (RRC) (110, 120), o equipamento de usuário (1100) sendo capaz de concomitantemente executar uma pluralidade de aplicativos diferentes (1154), cada um dos quais sendo capaz de trocar dados com a rede sem fio (1119), o método sendo caracterizado por compreender as etapas de, no equipamento de usuário: receber uma indicação de conclusão de troca de dados a partir de cada aplicativo da pluralidade de aplicativos diferentes que trocaram dados com a rede sem fio (1119) enquanto em um estado RRC (122, 124, 126, 128); com base nas indicações de conclusão de troca de dados recebidas a partir dos aplicativos que trocaram dados no estado RRC (122, 124, 126, 128), determinar quando não se espera que nenhum aplicativo no equipamento de usuário troque dados; e iniciar uma transição (422) a partir do estado RRC (122, 124, 126, 128) para outro estado ou modo RRC (124, 126, 128, 110) que demande menos bateria se for feita uma determinação de que não se espera que nenhum aplicativo no equipamento de usuário troque dados.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato da etapa de iniciação compreender a destruição de um estabelecimento de conexão de sinalização entre o equipamento de usuário (1100) e a rede sem fio (1119).

3. Método, de acordo com a reivindicação 2, caracterizado pelo fato da etapa de destruição fazer com que a rede (1119) libere uma conexão de sinalização entre o referido equipamento de usuário e a rede sem fio.

4. Método, de acordo com uma das reivindicações 1 a 3, caracterizado pelo fato da rede sem fio (1119) ser uma rede de Sistema de Telecomunicação Móvel Universal (UMTS).

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato do estado RRC ser um estado CELL_DCH (122) ou CELL_FACH (124) .

6. Método, de acordo com a reivindicação 4, caracterizado pelo fato do estado RRC ser um estado CELL_PCH (122) ou LTRA_PCH (128).

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato da referida etapa de iniciação compreender ainda o envio de uma mensagem para a rede sem fio (1119) solicitando transição para outro estado ou modo RRC que demanda menos bateria.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato do outro estado ou modo RRC que demanda menos bateria ser um dentre um estado CELL_FACH (124), um estado CELL_PCH (126), um estado URA_PCH (128) ou um estado inativo.

9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de cada aplicativo da pluralidade de aplicativos diferentes que trocaram dados com a rede sem fio (1119) enquanto no estado RRC ser um aplicativo ativo.

10. Método, de acordo com qualquer uma das reivindicações 1 a 9, caracterizado pelo fato do equipamento de usuário ainda compreender um Gerenciador de Conexão de RRC que executa as referidas etapas de receber, determinar e iniciar.

11. Método, de acordo com a reivindicação 10, caracterizado pelo fato da referida etapa de determinação compreender determinar quando se espera que nenhum aplicativo no equipamento de usuário troque dados com base em um estado composto das indicações de conclusão de troca de dados recebidos a partir dos aplicativos que trocaram dados no estado RRC.

12. Método, de acordo com a reivindicação 1, caracterizado pelo fato de determinar quando se espera que nenhum aplicativo no equipamento de usuário troque dados ser ainda baseado em um atraso para garantir que os aplicativos que trocaram dados no estado RRC não necessitam mais de uma conexão RRC.

13. Método, de acordo com a reivindicação 12, caracterizado pelo fato do atraso ser uma composição de uma pluralidade de periodos de expiração de inatividade, cada periodo de expiração de inatividade correspondendo a um aplicativo respectivo que trocou dados com a rede sem fio enquanto no estado RRC.

14. Método, de acordo com a reivindicação 1, caracterizado pelo fato de compreender ainda acompanhar cada aplicativo da pluralidade de aplicativos diferentes que trocaram dados com a rede sem fio enquanto em um estado RRC.

15. Método, de acordo com a reivindicação 14, caracterizado pelo fato da etapa de acompanhamento compreender ainda o acompanhamento de contextos associados de Protocolo de Dados de Pacote (PDP), portadoras de acesso por rádio de pacote comutado (PS), portadoras de rádio de PS para o referido equipamento de usuário.

16. Método, de acordo com a reivindicação 12 ou 13, caracterizado pelo fato do referido atraso ser dinâmico com base no histórico de padrão de tráfego e/ou perfis de aplicativo.

17. Método, de acordo com a reivindicação 13 ou 14, caracterizado por compreender ainda a etapa de bloqueio da referida etapa de iniciação, se o referido estado de RRC for um estado URA_PCH.

18. Equipamento de usuário (1100) adaptado para a redução do consumo de bateria em uma rede sem fio (1119), o equipamento de usuário tendo um subsistema de rádio (1111) que compreende um rádio adaptado para se comunicar com a rede sem fio (1119); um processador de rádio que tem um processador de sinal digital (1120) e adaptado para interagir com o referido subsistema de rádio (1111); uma memória (1124, 1126); uma interface de usuário (1144, 1122, 1136); um processador (1138) adaptado para concomitantemente executar uma pluralidade de aplicativos diferentes (1158), cada um dos quais sendo capaz de trocar dados com a rede sem fio (1119), o equipamento de usuário caracterizado pelo fato de ter: um gerenciador de conexão RRC que é adaptado e configurado para: receber uma indicação de conclusão troca de dados a partir de cada aplicativo da pluralidade de aplicativos diferentes que trocaram dados com a rede sem fio enquanto no estado RRC e, com base nas indicações de conclusão de troca de dados recebidas a partir dos aplicativos que trocaram dados no estado RRC, determinar quando não se espera que nenhum aplicativo no dispositivo de usuário troque dados; e iniciar uma transição a partir do estado RRC para outro estado ou modo demandando menos bateria se uma determinação for feita que se espera que nenhum aplicativo no dispositivo de usuário troque dados.

19. Equipamento de usuário (1100), de acordo com a reivindicação 18, caracterizado pelo fato do gerenciador de conexão RRC ser adaptado para destruir um estabelecimento de conexão de sinalização entre o equipamento de usuário e a rede sem fio.

20. Equipamento de usuário (1100), de acordo com a reivindicação 19, caracterizado pelo fato do gerenciador de conexão RRC ser adaptado para fazer com que a rede (1119) libere uma conexão de sinalização entre o equipamento de usuário e a rede sem fio pela destruição de um estabelecimento de conexão de sinalização.

21. Equipamento de usuário (1100), de acordo com qualquer uma das reivindicações 18 a 20, caracterizado pelo fato da rede sem fio (1119) ser uma de Sistema de Telecomunicação Móvel Universal (UMTS).

22. Equipamento de usuário (1100), de acordo com a reivindicação 21, caracterizado pelo fato do estado RRC ser um estado CELL_DCH (122) ou um estado CELL_FACH (124).

23. Equipamento de usuário, de acordo com a reivindicação 22, caracterizado pelo fato do estado RRC ser um estado CELL_PCH (12 6) ou um estado URA_PCH (128) .

24. Equipamento de usuário (1100), de acordo com a reivindicação 18, caracterizado pelo fato do gerenciador de conexão RRC ser configurado e ajustado para enviar uma mensagem para a rede sem fio (1119) que solicita uma transição para outro estado ou modo RRC (124, 126, 128, 110) que demanda menos bateria.

25. Equipamento de usuário (1100), de acordo com a reivindicação 18, caracterizado pelo fato do referido outro estado ou modo RRC que demanda menos bateria ser um dentre um estado CELL_FACH (124), um estado CELL_PCH (126), um estado URA_PCH (128) ou um estado inativo (110).

26. Equipamento de usuário (1100), de acordo com a reivindicação 18, caracterizado pelo fato de cada aplicativo da pluralidade de aplicativos diferentes que trocaram dados com a rede sem fio (1119) enquanto no estado RRC ser um aplicativo ativo.

27. Equipamento de usuário (1100), de acordo com a reivindicação 18, caracterizado pelo fato do referido gerenciador de conexão RRC ser adaptado para determinar quando se espera que nenhum aplicativo no equipamento de usuário troque dados com base em um estado composto das indicações de conclusão de troca de dados recebidos a partir dos aplicativos que trocaram dados no estado RRC.

28. Equipamento de usuário (1100), de acordo com a reivindicação 18, caracterizado pelo fato do referido gerenciador de conexão RRC ser adaptado para determinar quando se espera que nenhum aplicativo no equipamento de usuário troque dados com base em um atraso para garantir que os aplicativos que trocaram dados no estado RRC não necessitam mais de uma conexão RRC.

29. Rede de Sistema de Telecomunicação Móvel Universal (UMTS) (1119), caracterizada por compreender uma pluralidade de equipamentos de usuário (1100) conforme definido em qualquer uma das reivindicações 18 a 28.

Images