BRPI1006836B1 - equipamento de agente de usuário e método implementado em um computador para operação em um sistema de pacote evoluído (eps), e meio legível por computador - Google Patents

Abstract

sistema e método para determinar causas de estabelecimento um agente de usuário (ua), um dispositivo de rede de núcleo (cn) e um método para um serviço de restauração de emergência de circuito comutado (cs) em um sistema de pacote evoluído (eps). em uma modalidade, o ua ou a cn inclui uma camada de protocolo que tem um estrato não de acesso (nas). um processador do ua ou da cn é configurado para a promoção dos nas para processamento da requisição de serviço estendido tendo um tipo de serviço com um valor de decodificação. o valor de decodificação identifica uma causa de estabelecimento (ec) de controle de recurso de rádio (rrc) definida para eps.

Description

REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS

O presente pedido reivindica prioridade para o pedido de patente provisória U.S. N° 61/144.992, depositado em 15 de janeiro de 2009, de Chen-Ho Chin, intitulado “Determining RRC Establishment Causes of EPS NAS Procedures” (34841-US-PRV-4214-15000) e pedido de patente provisória U.S. N° 61/147.396, depositado em 26 de janeiro de 2009, de Chen-Ho Chin, intitulado “System and Method for Determining Establishment Causes” (34841-US-PRV), os quais são incorporados como referência aqui, como se reproduzidos em sua totalidade.

ANTECEDENTES

Conforme usado aqui, os termos “agente de usuário” e “UA” poderiam se referir, em alguns casos, a dispositivos móveis, tais como telefones móveis, assistentes digitais pessoais, computadores portáteis ou laptop, e dispositivos similares que tenham capacidades de telecomunicações. Um UA como esse poderia consistir em um UA e seu módulo de memória móvel associado, tal como, mas não limitado, uma placa de circuito integrado universal (UICC) que inclui um aplicativo de módulo de identidade de assinante (SIM), um aplicativo de módulo de identidade de assinante universal (USIM) ou um aplicativo de módulo de identidade de usuário removível (R-UIM). Alternativamente, um UA como esse poderia consistir no dispositivo em si, sem um módulo como esse. Em outros casos, o termo “UA” poderia se referir a dispositivos que teriam capacidades similares, mas que não

seriam transportáveis, tais como computadores de mesa, set top boxes ou aparelhagens de rede. O termo “UA” também pode se referir a qualquer componente de hardware ou de software que pode terminar uma sessão de comunicação para um usuário. Também, os termos “agente de usuário”, “UA”, “equipamento de usuário”, “UE”, “dispositivo de usuário” e “nó de usuário” poderiam ser usados de forma sinônima aqui.

Conforme a tecnologia evoluiu, um equipamento mais avançado de rede foi introduzido, que pode prover serviços que não eram possíveis previamente. Este equipamento de acesso de rede poderia incluir sistemas e dispositivos que são melhoramentos do equipamento equivalente em um sistema de telecomunicações sem fio tradicional. Esse equipamento avançado ou de próxima geração pode ser incluído em padrões de telecomunicações sem fio evoluindo, tal como uma evolução de longo prazo (LTE). Por exemplo, um sistema de LTE poderia incluir um Nó B melhorado (eNB), um ponto de acesso sem fio, ou um componente similar, ao invés de uma estação base tradicional. Conforme usado aqui, o termo “nó de acesso” referir-se-á a qualquer componente da rede sem fio, tal como uma estação base tradicional, um ponto de acesso sem fio, ou um eNB de LTE, que cria uma área geográfica de cobertura de recepção e de transmissão, permitindo que um UA ou um nó de retransmissão acesse outros componentes em um sistema de telecomunicações. Neste documento, o termo “nó de acesso” pode compreender uma pluralidade de hardware e de software.

Um sistema de LTE pode incluir protocolos, tal como um protocolo de controle de recurso de rádio (RRC), o qual é responsável pela atribuição, configuração e liberação de recursos de rádio entre um UA e um nó de acesso ou um nó de retransmissão ou outro equipamento de LTE. O protocolo de RRC é descrito em detalhes na Especificação Técnica (TS) de projeto de parceria de terceira geração (3GPP) 36.331. De acordo com o protocolo de RRC, os dois modos básicos de RRC para um UA são definidos como “modo inativo” e “modo conectado”. Durante o modo ou estado conectado, o usuário pode trocar sinais com a rede e realizar outras operações relacionadas, enquanto durante o modo ou estado inativo, o UA pode parar pelo menos parte de suas operações de modo conectado. Os comportamentos de modo inativo e conectado são descritos em detalhes na TS 36.304 e na TS 36.331 do 3GPP.

Os sinais que podem portar dados entre UAs, nós de retransmissão e nós de acesso podem ter frequência, tempo e parâmetros de codificação e outras características que poderiam ser especificados por um nó de rede. Uma conexão entre qualquer um destes elementos que tenha um conjunto específico dessas características pode ser referida como um recurso. Os termos “recurso”, conexão de comunicações”, “canal” e “enlace de comunicações” poderiam ser usados de forma sinônima aqui. Um nó de rede tipicamente estabelece um recurso diferente para cada UA ou outro nó de rede com o qual esteja em comunicação em qualquer tempo em particular.

BREVE DESCRIÇÃO DOS DESENHOS

Para um entendimento mais completo desta exposição, uma referência é feita, agora, à breve descrição a seguir, tomada em relação aos desenhos associados e à descrição detalhada, onde números de referência iguais representam partes iguais.

A Figura 1 é um diagrama de blocos que ilustra como um UA se comunica com uma rede de núcleo através de uma rede de acesso por rádio, de acordo com uma modalidade da exposição.

A Figura 2 é um diagrama de blocos que ilustra um percurso tomado por um bloco de dados a partir de um UA para uma rede de núcleo, de acordo com uma modalidade da exposição.

A Figura 3 é um diagrama de blocos de um plano de controle entre um agente de usuário, uma rede de acesso por rádio e uma rede de núcleo, de acordo com uma modalidade da exposição.

A Figura 4 é um diagrama de blocos de um plano de controle entre um agente de usuário, uma rede de acesso por rádio e uma rede de núcleo, de acordo com uma modalidade da exposição.

A Figura 5 é uma tabela que ilustra um mapeamento estrito entre um serviço de telefônica invocado de restauração de emergência de CS e uma causa de estabelecimento de RRC de EPS, de acordo com uma modalidade da exposição.

A Figura 6 é um fluxograma que ilustra um processo de determinação de uma causa de estabelecimento de RRC de um procedimento de NAS de EPS durante uma comunicação de restauração de emergência de CS, de acordo com uma modalidade da exposição.

A Figura 7 é um fluxograma que ilustra um processo de determinação de uma causa de estabelecimento de RRC de um procedimento de NAS de EPS durante uma comunicação de restauração de emergência de CS, de acordo com uma modalidade da exposição.

A Figura 8 é um fluxograma que ilustra um processo de determinação de uma causa de estabelecimento de RRC de um procedimento de NAS de EPS durante uma comunicação para a realização de um serviço de restauração de emergência de CS, de acordo com uma modalidade da exposição.

A Figura 9 ilustra um processador e componentes relacionados adequados para a implementação das várias modalidades da presente exposição.

DESCRIÇÃO DETALHADA

Deve ser entendido no começo que, embora implementações ilustrativas de uma ou mais modalidades da presente exposição sejam providas abaixo, os sistemas e/ou métodos expostos podem ser implementados usando-se qualquer número de técnicas, atualmente conhecidas ou em existência. A exposição não deve ser limitada de forma alguma às implementações ilustrativas, desenhos e técnicas ilustrados abaixo, incluindo os projetos e as implementações de exemplo ilustradas e descritas aqui, mas pode ser modificada no escopo das reivindicações em apenso juntamente com seu pleno escopo de equivalentes.

Conforme usado aqui, os acrônimos a seguir têm as definições a seguir.

“AS” é definido como um “estrato de acesso”, o qual é uma camada em uma pilha de protocolo em uma rede de acesso por rádio (RAN) de agente de usuário (UA).

“CN” é definido como “rede de núcleo”, o que se refere a dispositivos e um software para processamento de mensagens e dados a partir de agentes de usuário (UAs) enviados através de redes de acesso por rádio (RANs).

“CS” é definido como “circuito comutado”, o que se refere a um procedimento convencional para comunicação de uma chamada telefônica ou para a conexão de dispositivos para transferência de dados por uma conexão por rádio permanente ou semipermanente, tal como, por exemplo, uma linha telefônica.

“Recuperação de emergência de CS” se refere a um procedimento no qual, quando da implementação de uma comunicação, um dispositivo habilitado para um sistema de pacote evoluído (EPS) “se recupera de uma emergência” para um procedimento de comunicação de circuito comutado (CS).

“EC” é definido como “causa de estabelecimento”, o que se refere a dados que informam as camadas de protocolo intervenientes, bem como dispositivos e software em uma rede de acesso por rádio (RAN), quanto à “causa” ou à “razão” pela qual uma comunicação é para ser estabelecida.

“eNB” é definido como um “nó B melhorado”, o qual é um exemplo de um tipo de dispositivo usado em uma rede de acesso por rádio (RAN) para ajudar no estabelecimento de uma comunicação entre um UA e uma CN.

“EPC” é definido como “rede de pacote evoluída”, a qual se refere à rede de núcleo (CN) com a qual uma rede de rádio de evolução de longo prazo (LTE) se comunica.

“EPS” é definido como “sistema de pacote evoluído”, o que se refere à EPC e um conjunto de sistemas de acesso - EPS representa o sistema que pode ter a LTE como uma rede de rádio e a EPC como sua rede de núcleo.

“E-UTRAN” é definido como “UTRAN evoluída”, o que se refere a uma “RAN terrestre de UMTS evoluída”, o que, por sua vez, refere-se a uma “rede de acesso por rádio terrestre de sistema universal de telecomunicações móveis evoluído”; E-UTRAN se refere à rede de “eNBs” (“nós B melhorados”) e controladores de rede de rádio em um sistema de comunicações de evolução de longo prazo (LTE).

“LTE” é definido como “evolução de longo prazo”, o que se refere a um sistema mais novo de comunicações móveis de alta velocidade e infraestrutura.

“NAS” é definido como um “estrato não de acesso”, o que é uma camada em uma pilha de protocolo em um UA e uma rede de núcleo (CN), mas pode não estar em uma pilha de protocolo de uma rede de acesso por rádio (RAN).

“MAC” é definido como “controle de acesso a meio”, o que é uma camada de protocolo em um UA, uma RAN e uma CN.

“Dados de MO” é definido como “dados de origem em móvel”, o que é um tipo de causa de estabelecimento usada em sistemas habilitados para EPS.

“Sinalização de MO” é definido como uma “sinalização de origem em móvel”, o que é um tipo de causa de estabelecimento usada em sistemas habilitados para EPS.

“Acesso de MT” é definido como “acesso de terminação em móvel”, o que é um tipo de causa de estabelecimento usada em sistemas habilitados para EPS.

“RAN” é definido como “rede de acesso por rádio”, o que se refere a uma rede de nós de comutação entre um UA e uma CN.

“TS” é definido como “especificações técnicas”, as quais são especificações de comunicações móveis pedidas pelo 3GPP (projeto de parceira de terceira geração) para a implementação de um sistema de LTE.

Outros acrônimos que podem aparecer aqui são usados e definidos de acordo com as especificações dos padrões do 3GPP.

Em uma modalidade, a presente exposição se refere à regulagem de causas de estabelecimento (ECs) no contexto de um procedimento de recuperação de emergência de CS em dispositivos habilitados para EPS. Como um auxílio não limitativo no entendimento da presente exposição, uma EC ou uma “causa de estabelecimento” se refere a dados que informam camadas de protocolo intervenientes, bem como dispositivos e um software em uma rede de acesso por rádio (RAN) e/ou uma rede de núcleo (CN), quanto à “causa” ou “razão” pela qual uma comunicação é para ser estabelecida. A “razão” para a comunicação pode ser usada para o gerenciamento de novas comunicações e das estabelecidas, e para a atribuição de recursos de comunicação para comunicações individuais, de acordo com prioridades desejadas. Assim, por exemplo, se uma comunicação em particular tiver uma causa de estabelecimento (EC) de “chamada de emergência”, então, os dispositivos e o software no EPS poderão proporcionar uma prioridade mais alta àquela chamada, possivelmente excluindo outras comunicações pendentes ou existentes em favor da chamada de emergência. Outros exemplos não limitativos de ECs em um EPS incluem “acesso de prioridade alta”, “acesso de MT”, “sinalização de MO”, “dados de MO”, e, possivelmente, outros.

Uma EC é útil para a eficiência de um sistema de comunicação móvel, porque um EC impede que muitas camadas de pilha de protocolo intervenientes em dispositivos individuais, bem como camadas de pilha de protocolo adicionais em dispositivos de RAN intervenientes, tenham que decodificar um bloco de dados para a descoberta da razão para a comunicação. Ao invés disso, a EC pode informar a uma ou mais camadas de pilha de protocolo intervenientes, em um dispositivo iniciando uma comunicação, mas, de forma mais importante, em dispositivos de RAN e dispositivos de CN, a razão para a comunicação sem as camadas de pilha de protocolo intervenientes terem de decodificar um bloco de dados. Devido ao fato de um bloco de dados ser decodificado menos frequentemente conforme ele negocia com as camadas de pilha de protocolo de vários dispositivos no EPS, a transferência do bloco de dados pode ocorrer de forma mais rápida e eficiente. A decodificação de um bloco de dados menos frequentemente também diminui os custos de implementação daqueles dispositivos.

Com este entendimento de ECs, um entendimento de um procedimento de restauração de emergência de CS é um procedimento no qual, quando da implementação de uma comunicação, um dispositivo habilitado para sistema de pacote evoluído (EPS) “é restaurado devido a uma emergência” para um procedimento de comunicação de circuito comutado (CS). O procedimento de “restauração de emergência de CS” frequentemente é usado quando um dispositivo habilitado para EPS tenta estabelecer uma comunicação de voz por uma rede de CS móvel tradicional, em oposição a uma comunicação de dados.

Os detalhes de como um procedimento de comunicação de CS opera em sistemas de comunicação móveis antes de LTE / EPS - tal como UMTS - são conhecidos, e outra coisa além daquilo descrito aqui não é necessário para um entendimento da presente exposição. Contudo, deve ser entendido que ambos os procedimentos de comunicação de CS e os procedimentos de comunicação de EPS usam ECs. Também deve ser entendido que as ECs para comunicações de CS em UMTS são inteiramente diferentes das ECs de comunicações de EPS. Em UMTS, uma chamada de comunicações pode ter uma de muitas ECs (mais de uma dúzia). As comunicações de EPS pedem cinco ECs, deixando três ECs vagas para definição e uso posterior - para um total de oito ECs possíveis. Para procedimentos de comunicação futuros, um problema similar pode surgir pelo fato de números diferentes ou tipos diferentes de ECs poderem existir, que não podem ser prontamente mapeados para ECs definidas para procedimentos de comunicação mais antigos. Assim, as modalidades descritas aqui não estão necessariamente limitadas à especificação de ECs para procedimentos de restauração de emergência de CS em sistemas de EPS, para as oito ECs atualmente disponíveis, ou para outros ECs que podem estar disponíveis. Ainda, as ECs disponíveis em UMTS não são todas para comunicações de CS; ao invés disso, estas ECs são para todos os tipos de comunicações em UMTS, do que as comunicações de CS são uma técnica.

Para as razões descritas adicionalmente abaixo, as ECs para comunicações de CS não podem simplesmente ser mapeadas para comunicações de EPS. Assim, previamente, quando um UA desejava implementar uma comunicação usando um procedimento de CS, nenhum mecanismo existia para o dispositivo habilitado para EPS, para a regulagem da EC definida para restauração de emergência de CS apropriada. A presente exposição é dirigida a esta questão e resolve este problema em algumas modalidades.

Em particular, a presente exposição provê três ou mais soluções ou técnicas para a resolução desta questão. Em uma primeira modalidade, um mapeamento estrito é provido entre um procedimento de restauração de emergência de CS e uma EC de EPS. Em uma segunda modalidade, um tipo de serviço da mensagem de EXTENDED SERVICE REQUEST (REQUISIÇÃO DE SERVIÇO ESTENDIDO) transmitida por um dispositivo habilitado para EPS tem um valor que regula a EC de CS apropriada. Em uma terceira modalidade, uma das três ECs vagas no procedimento de comunicação de EPS é usada para a regulagem da EC de EPS. Outras modalidades e variações existem, conforme descrito abaixo, e conforme apreciado por aqueles versados na técnica.

As Figuras 1 e 2 descrevem um procedimento de exemplo de como um UA estabelece comunicação com uma CN em um EPS. As Figuras 3 e 4 descrevem detalhes de exemplo das pilhas de protocolo em um UA, um dispositivo de RAN e um dispositivo habilitado para EPS. As Figuras 5 a 8 descrevem soluções de exemplo para as questões descritas com respeito às Figuras 1 a 4, embora soluções de exemplo para estas questões também sejam entendidas no contexto das Figuras 1 a 4.

Voltando-nos, agora, para as Figuras 1 e 2, a Figura 2 é um diagrama de blocos que ilustra um UA em comunicação com uma rede de núcleo através de uma rede de acesso por rádio, de acordo com uma modalidade da exposição. De modo similar, a Figura 2 é um diagrama de blocos que ilustra um percurso tomado por um bloco de dados a partir de um UA para uma rede de núcleo, de acordo com uma modalidade da exposição. As Figuras 1 e 2 têm componentes similares que têm funções similares; assim, as Figuras 1 e 2 compartilham números de referência similares e são descritas em conjunto.

Em uma modalidade ilustrativa, um UA 100 tenta estabelecer uma conexão com uma CN 102. Uma tentativa como essa pode ser referida como uma chamada de origem em móvel, ou MO, porque um UA inicia a tentativa de conexão. Contudo, os processos a seguir também podem se aplicar a uma chamada de terminação em móvel (MT), onde a CN 102 inicia a tentativa de conexão.

Para se iniciar a tentativa de conexão, o NAS de UA 104 envia uma mensagem de requisição, por exemplo, uma REQUISIÇÃO DE SERVIÇO (SERVICE REQUEST) ou REQUISIÇÃO DE SERVIÇO ESTENDIDO (EXTENDED SERVICE REQUEST) para o NAS de CN 106 através de uma rede de acesso por rádio (RAN) 108. O NAS de UA 104 inicia a requisição e, no UA 100, transmite a requisição para o estrato de acesso (AS) de UA 110. Por sua vez, o AS 110 transmite a requisição por uma camada física, tal como ondas de rádio, conforme mostrado pela seta 112, para a RAN 108.

O AS de RAN 114 recebe a requisição, e aloca os recursos preliminares para o UA 100 e, então, comunica a requisição para as funções de intertrabalho 116 da RAN 108. As funções de intertrabalho podem incluir o gerenciamento da requisição em relação às outras requisições, bem como outras funções. As funções de intertrabalho 116 também se comunicam com os controladores de CN para RAN 118, os quais controlam as comunicações entre a RAN 108 e o CN 102. A comunicação real da requisição entre a RAN 108 e o CN 102 é transmitida ao longo de uma camada física, a qual pode ser de fios ou cabos, por exemplo, conforme mostrado pela seta 120. A camada física 120 também pode ser implementada como um backhaul sem fio.

Na CN 102, os controladores de CN para RAN 122 recebem a requisição e transmitem a requisição para o NAS de CN 106. O NAS de CN 106 então decodifica os dados na requisição, e toma uma ação apropriada para a alocação de recursos móveis adicionais ou necessários para o UA 100 para aquela comunicação sem fio. O NAS de CN 106 transmite essa informação para o UA 100 através da RAN 108 de uma maneira similar aos processos descritos acima, mas na outra direção.

Em uma outra modalidade, a CN inicia uma chamada de MT (terminação em móvel). O processo descrito acima ocorre a partir do NAS de CN 106 para o NAS de UA 104 em um processo similar àquele descrito acima.

A Figura 2 mostra o mesmo processo em maiores detalhes, de modo a descrever o uso de uma EC em uma comunicação de EPS de acordo com uma modalidade. De novo, em uma modalidade, o NAS de UA 104 inicia uma comunicação com o NAS de CN 106.

A EC 204 é de dados que informam camadas de protocolo intervenientes, bem como dispositivos e um software na RAN 108 e na CN 102, quanto à “causa” ou “razão” pela qual uma comunicação é para ser estabelecida. A EC 204 permite que essas camadas de protocolo intervenientes saibam a razão para a transmissão do bloco de dados 200, sem se ter que decodificar ou abrir o bloco de dados 200.

No número 1 202, o NAS de UA 104 transmite um bloco de dados 200 com a EC 204 para o AS de UA 110, com o destino pretendido final do bloco de dados 200 sendo o NAS de CN 106. O AS de UA 110 então começa o trabalho de transmissão do bloco de dados 200. De novo, o AS de UA 110 não decodifica o bloco de dados 200, mas, ao invés disso, usa a EC 204 para saber a razão para a transmissão do bloco de dados 200.

No número 2 206, o AS de UA 110 transmite uma REQUISIÇÃO DE CONEXÃO DE RRC e a EC 204 para o AS de RAN 114. O AS de RAN 114 responde com um comando de ESTABELECIMENTO DE CONEXÃO DE RRC. Conhecendo a EC 204, o AS de RAN 114 aloca recursos preliminares iniciais para o UA 100, conforme mostrado no número 3 208. Caso bem sucedido, o AS de UA 110 responde com um sinal de ESTABELECIMENTO DE CONEXÃO DE RRC COMPLETADO, em conjunto com o bloco de dados 200, conforme mostrado no número 4 210. Como resultado, o bloco de dados 200 é transmitido a partir do AS 110 para o AS de RAN 114.

No número 5 212, o AS de RAN 114 transmite o bloco de dados 200 e a EC 204 para as funções de intertrabalho 116 da RAN 108. As funções de intertrabalho 116 priorizam o processamento do bloco de dados 200, bem como realizam outras funções. Neste ponto, uma transmissão adicional da EC é opcional. Adicionalmente, a EC pode não ter sido transmitida após a execução do número 3.

Quando o processamento está completado, as funções de intertrabalho 116 transmitem o bloco de dados 200 e, também, opcionalmente, proveem a EC 204 para os controladores de CN para RAN 118, conforme mostrado no número 6 214. Por sua vez, conforme mostrado no número 7 216, os controladores de CN para RAN 118 transmitem o bloco de dados 200, opcionalmente com a EC 204, se disponível a partir do número 6 214, e uma REQUISIÇÃO DE CONEXÃO para os controladores de CN para RAN 122 da rede de núcleo. Os controladores de CN para RAN 122 então transmitem o bloco de dados 200 e, opcionalmente, a EC, se disponível, a partir do número 7 216 para o NAS de CN 106, conforme mostrado no número 8 218.

Através de 202, 206, 208, 210, 212, 214, 216 e 218, nenhum dos dispositivos intervenientes e software das camadas de protocolo entre o AS de UA 110 e os controladores de CN para RAN 122 decodificou o bloco de dados 200 para determinar o conteúdo do bloco de dados 200 ou para determinar uma causa para a comunicação do bloco de dados 200. Contudo, algumas ou todas estas camadas de pilha de protocolo intervenientes em um ou mais dentre o UA 100, a RAN 108 e a CN 102 usou a EC 204 para ajudar na determinação da prioridade e no processamento para aplicação ao bloco de dados 200. Contudo, no estágio final, o NAS de CN 106 decodifica o bloco de dados 200 e processa os dados contidos ali.

Em uma modalidade, o NAS de CN 106 decodifica o bloco de dados 200 e encontra que o bloco de dados 200 compreende uma REQUISIÇÃO DE SERVIÇO ou uma REQUISIÇÃO DE SERVIÇO ESTENDIDO. Estas requisições indicam para o NAS de CN 106 que o UA 100 deseja recursos de comunicação móvel para o estabelecimento de uma comunicação com algum outro dispositivo através da CN 102.

Após o processamento dos dados no bloco de dados 200, o NAS de CN 106 determina uma resposta apropriada, tal como alocar os recursos de comunicação móveis para o UA 100. O NAS de CN 106 então transmite os dados com referência a esses recursos de volta para o UA 100 usando um processo similar àquele descrito acima, exceto que na direção oposta.

Declarado de outra forma, o NAS de UA 104 está comunicando uma REQUISIÇÃO DE SERVIÇO ou uma REQUISIÇÃO DE SERVIÇO ESTENDIDO para o NAS de CN 106. A sinalização e os controladores de protocolo que permitem esta comunicação são implementados como camadas de protocolo. Par cada camada, entidades de par a par sinalizam e se comunicam com cada outra, para se permitir a realização de funções, de modo que o serviço possa ser provido. Estes conceitos são explicados em maiores detalhes nas Figuras 3 e 4.

A Figura 3 é um diagrama de blocos de um plano de controle entre um agente de usuário, uma rede de acesso por rádio e uma rede de núcleo, de acordo com uma modalidade da exposição. De modo similar, a Figura 4 é um diagrama de blocos de um plano de controle entre um agente de usuário, uma rede de acesso por rádio e uma rede de núcleo, de acordo com uma modalidade da exposição. As Figuras 3 e 4 têm componentes similares que têm funções similares; assim, as Figuras 3 e 4 compartilham números de referência similares e são descritas em conjunto. As Figuras 3 e 4 mostram detalhes adicionais na relação dentre as camadas de pilha de protocolo dentre o UA 100, a RAN 108 e a CN 102. A descrição da comunicação de dados do UA 100 para a CN 102 e de volta de novo é provida com respeito às Figuras 1 e 2, o que também se aplica às Figuras 3 e 4.

Conforme descrito acima, um ou mais dentre a sinalização de camada de rede e os controladores de protocolo do AS 110, da RAN 108 e do NAS de CN 106 podem se comunicar uns com os outros através de enlaces de comunicações estabelecidos pelos controladores de RAN subjacentes. Nas terminologias de UMTS e 3GPP, a camada de rede entre o UA 100 e a CN 102 é denominada um estrato não de acesso (NAS). O UA 100 tem o NAS de UA 104 e a CN 102 tem o NAS de CN 106; contudo, a RAN 108 pode não ter um NAS nas modalidades descritas aqui.

As camadas de acesso por rádio no UA 100 e na RAN 108 são denominadas o estrato de acesso (AS). O AS de UA 110 inclui várias camadas de protocolo no UA 100, e o AS de RAN 114 inclui várias camadas de protocolo na RAN 108, conforme mostrado na Figura 4.

Em cada pilha de protocolo, uma camada subjacente provê serviços para a camada acima. Assim, por exemplo, o AS de UA 110 de UA 100 provê serviços para o NAS de UA 104. Um dos serviços providos pelo AS de UA 110 é o estabelecimento de uma conexão de sinalização para o NAS de UA 104 do UA 100. A conexão de sinalização permite que o NAS de UA 104 se comunique com o NAS de CN 106. Em redes de LTE / SAE (evolução de arquitetura de sistema) / EPS, o NAS de CN 106 pode ser referido como o núcleo de pacote melhorado (EPC). O processo de estabelecimento de uma conexão de sinalização é descrito com respeito às Figuras 1 e 2. Maiores detalhes referentes à conexão de sinalização podem ser encontrados na TS 36.331 de 3GPP e na TS 25.331 de 3GPP.

Como parte do estabelecimento da conexão de sinalização, o RRC do UA 100 provê ao AS de RAN 114 uma indicação da razão para a requisição da conexão. Esta EC é construída no protocolo de sinalização de RRC, conforme descrito adicionalmente em TS 36.331 de 3GPP.

Também conforme descrito acima com respeito às Figuras 1 e 2, a EC serve para fins de indicação para os nós de destino, tal como o eNB / a E-UTRAN e, talvez, mesmo para a EPC, a razão para o estabelecimento da conexão de sinalização. Assim, estes dispositivos e um software podem alocar recursos apropriados para a conexão de sinalização, e um uso subsequente da conexão de sinalização. A EC também pode ser usada para discriminação ou determinação de quanto cobrar de um usuário do UA 100 pelo uso do serviço de comunicação móvel.

Em UMTS e, agora, em EPS, a EC que o RRC provê para a rede em uma MENSAGEM DE REQUISIÇÃO DE CONEXÃO DE RRC é tomada a partir da requisição entre camadas a partir do NAS de UA 104. Veja, por exemplo, as descrições de campo de REQUISIÇÃO DE CONEXÃO DE RRC em TS 36.331 do 3GPP.

Em UMTS, as ECs podem assumir um de muitos valores. Os valores possíveis para as ECs em UMTS são dados em TS 25.331 do 3GPP. Atualmente, mais de 20 valores possíveis existem para ECs em UMTS.

Em resumo, então, a EC de RRC que o AS 110 provê na REQUISIÇÃO DE CONEXÃO DE RRC vem do NAS de UA 104. O NAS de UA 104 também determina a EC a ser usada. Em UMTS, o NAS de UA 104 escolhe a EC de acordo com as regras providas no Anexo L de UMTS da TS 24.008 do 3GPP. Estas regras registram o mapeamento do procedimento de NAS para a EC de RRC.

Com a descrição acima de como as comunicações móveis operam, as soluções e técnicas a seguir providas pela presente exposição agora podem ser apropriadamente entendidas. Em EPS, a lista equivalente e ECs para UMTS (descrita na TS 36.331 do 3GPP) não está disponível. Ao invés disso, foram estabelecidas cinco ECs reguladas e três ECs vagas. As cinco ECs reguladas são “chamada de emergência”, “acesso de prioridade alta”, “acesso de terminação em móvel (MT)”, “sinalização de origem em móvel (MO)” e “dados de MO”. As ECs vagas não foram definidas, mas foram reservadas para definição posterior.

Assim, em EPS, quando o NAS de UA 104 tenta estabelecer uma conexão de RRC, o NAS de UA 104 regulará uma das cinco ECs descritas acima. Este procedimento pode ser usado na maioria das, se não em todas as comunicações de EPS.

Contudo, para alguns tipos de comunicações, em particular chamadas de voz, o uso do sistema de UMTS convencional pode ser desejável. Assim, foi implementado um procedimento em que um dispositivo habilitado para EPS pode usar os procedimentos, dispositivos e software de UMTS convencional. Este procedimento é conhecido como “restauração de emergência de CS”, o que significa “restauração de emergência de circuito comutado”.

O dispositivo habilitado para EPS é programado para uso das ECs de EPS quando da transmissão de dados por uma rede de EPS, e a rede de EPS espera ver ECs de EPS. Contudo, as ECs de EPS têm que ser usadas quando o dispositivo habilitado para EPS, enquanto no EPS, deseja iniciar um serviço de restauração de emergência de CS que levará ao uso dos procedimentos de UMTS. As EPCs devem ser usadas nesta circunstância, porque o NAS de UA 104 inicia uma restauração de emergência de CS como essa no EPS.

Em uma primeira olhada rápida, pode parecer que se poderia herdar as ECs de UMTS a partir da TS 24.008 de 3GPP na especificação de NAS de EPS. Contudo, os procedimentos de NAS de EPS mudaram, e funcionalidades melhoradas foram implementadas, de modo que um mapeamento de UMTS convencional não pode se aplicar. Mais ainda, as ECs de RRC indicadas para EPS são bastante diferentes daquelas usadas em UMTS; assim, de novo, uma cópia pelas ECs de UMTS, ou um mapeamento de um para um, não é possível. Mais ainda, muito poucas ECs são usadas no EPS, em relação aos sistemas de UMTS. Mais ainda, alguns procedimentos de NAS de EPS realizados pelas novas mensagens de NAS não existem em UMTS. Por exemplo, o NAS no EPS usa uma mensagem de REQUISIÇÃO DE SERVIÇO ou uma mensagem de REQUISIÇÃO DE SERVIÇO ESTENDIDO, mas a REQUISIÇÃO DE SERVIÇO ESTENDIDO não é usada em UMTS.

A questão de mapeamento de ECs relacionadas a EPS para ECs relacionadas a UMTS foi considerado, parcialmente apenas, com respeito a um mapeamento geral de procedimentos de NAS para uma EC de RRC de EPS. Veja, por exemplo, o documento C1-083834 promulgado por CT1, o qual é incorporado desse modo como referência. Contudo, esta solução proposta não se dirige a todas as questões descritas acima. Em particular, esta solução proposta não funciona no caso de uma comunicação de restauração de emergência de CS porque, em sistemas de EPS, o procedimento de requisição de serviço também é usado para a realização de comunicações de restauração de emergência de CS.

Adicionalmente, através de um procedimento de restauração de emergência de CS, o UA pode iniciar uma chamada de emergência no domínio de CS. Mais ainda, a existência em EPS da mensagem de REQUISIÇÃO DE SERVIÇO ESTENDIDO como uma mensagem de sinalização do procedimento de requisição de serviço não é considerada na documentação existente, tal como a C1-083834. As figuras a seguir e a descrição proveem soluções e técnicas nesse sentido.

A Figura 5 é uma tabela que ilustra um mapeamento estrito entre um serviço de telefonia invocado de restauração de emergência de CS e uma causa de estabelecimento de RRC de EPS, de acordo com uma modalidade da exposição. A tabela 500 ilustra uma modalidade de endereçamento às limitações descritas com respeito às Figuras 1 a 4.

As modalidades descritas na Figura 5 proveem um mapeamento estrito entre o serviço de telefonia invocado de restauração de emergência de CS, tal como uma chamada de MO, uma chamada de MT ou uma chamada de emergência, para uma EC de RRC de EPS. Este mapeamento estrito pode ser, por exemplo, na forma provida na Figura 5, embora outros mapeamentos pudessem ser usados.

A linha 502 mostra os títulos para as colunas, incluindo “Serviço de telefonia para o qual uma restauração de emergência de CS é iniciada”, e “Causa de estabelecimento de RRC a usar”. As linhas 504, 506 e 508 mostram os mapeamentos a serem usados por linha. Assim, conforme mostrado na linha 504, para um procedimento de requisição de serviço disparado pela restauração de emergência de CS iniciar uma chamada de MO de CS, a EC de

EPS “sinalização de MO” pode ser usada. Alternativamente, os “dados de MO” de EC de EPS podem ser usados. Conforme mostrado na linha 506, para um procedimento de requisição de serviço disparado pela restauração de emergência de CS para receber uma chamada de MT de CS, a “sinalização de MO” de EC de EPS pode ser usada. Alternativamente, o “acesso de MT” de EC de EPS pode ser usado. Em ainda uma outra modalidade, os “dados de MO” de EC de EPS podem ser usados. Conforme mostrado na linha 508, para um procedimento de requisição de serviço disparado pela restauração de emergência de CS para iniciar uma chamada de MO de CS, a “chamada de emergência” de EC de EPS pode ser usada.

Em uma modalidade, um processador pode ser configurado para regular uma causa de estabelecimento (EC) para “sinalização de MO”, se uma REQUISIÇÃO DE SERVIÇO requisitar recursos para uma sinalização de UL (enlace ascendente). Em uma outra modalidade, um processador pode ser configurado para regular uma causa de estabelecimento para “dados de MO”, se uma REQUISIÇÃO DE SERVIÇO requisitar recursos de rádio de plano de usuário. Em ainda uma outra modalidade, um processador configurado pode ser configurado para regular uma causa de estabelecimento para “acesso de MT”, se um indicador de domínio de CN for regulado para PS (de pacote comutado).

A Figura 6 é um fluxograma que ilustra um processo de determinação de uma causa de estabelecimento de RRC de um procedimento de NAS de EPS durante uma comunicação de restauração de emergência de CS, de acordo com uma modalidade da exposição. O processo mostrado na Figura 6 é uma outra técnica provida para se dirigir às questões descritas com respeito às Figuras 1 a 4. O processo mostrado na Figura 6 pode ser implementado inteiramente em um UA, mas pode ser iniciado em um UA e, então, adicionalmente processado em parte em uma RAN. Em modalidades opcionais adicionais, o processo mostrado na Figura 6 pode ser implementado inteiramente em um CN, mas pode ser iniciado em uma CN e, então, adicionalmente processado em parte em uma RAN. Em ainda outras modalidades opcionais, o processo mostrado na Figura 6 pode ser iniciado em uma RAN e, então, processado no UA ou na CN, embora, neste caso, o dispositivo de RAN deva ter uma camada de NAS ou alguma outra funcionalidade para a geração da EC.

Especificamente, a Figura 6 tira vantagem da mensagem de REQUISIÇÃO DE SERVIÇO ESTENDIDO usada em comunicações de EPS. A Figura 6 mostra especificamente o uso de um elemento de informação associado à REQUISIÇÃO DE SERVIÇO ESTENDIDO, conhecido como “tipo de serviço”. O tipo de serviço pode ser provido com um ou mais valores de decodificação que podem refletir uma causa para a REQUISIÇÃO DE SERVIÇO ESTENDIDO que está sendo tentada. Assim, nesta modalidade, o valor de decodificação ou os valores do tipo de serviço usado na REQUISIÇÃO DE SERVIÇO ESTENDIDO são usados para a provisão do mapeamento com o qual a EC de RRC é para ser usado.

Em uma modalidade, o processo começa com um processador iniciando um serviço de restauração de emergência de circuito comutado (CS) por um dispositivo tangível de um sistema de pacote evoluído (EPS) (bloco 600). O dispositivo tangível pode ser um UA ou, opcionalmente, uma CN. No caso de um UA ou de uma CN, o dispositivo tangível ainda compreende uma camada de protocolo que tem um estrato não de acesso (NAS).

Após o início do serviço de restauração de emergência de CS, o NAS processa uma REQUISIÇÃO DE SERVIÇO ESTENDIDO que tem um tipo de serviço com um valor de decodificação (bloco 602). O valor de decodificação pode ser usado para a identificação de uma causa de estabelecimento (EC) de controle de recurso de rádio (RRC) definida por EPS (bloco 604). Para qualquer que seja o UA ou a CN que iniciou a comunicação, os vários dispositivos e camadas de protocolo no sistema de EPS então suam a EC de RRC definida por EPS durante o processamento do serviço de restauração de emergência de CS (bloco 606). O processo termina depois disso.

O processo descrito na Figura 6 também pode ser expandido. Por exemplo, em uma modalidade, o NAS pode gerar a REQUISIÇÃO DE SERVIÇO ESTENDIDO. Neste caso, o NAS do UA determina o valor de codificação e faz com que a REQUISIÇÃO DE SERVIÇO ESTENDIDO seja transmitida para a realização do serviço de restauração de emergência de CS. Em contraste, o NAS do UA poderia receber a REQUISIÇÃO DE SERVIÇO ESTENDIDO. Neste caso, um estrato de acesso (AS) do dispositivo tangível processa o valor de decodificação.

Vários exemplos específicos de tipos de serviço e ECs de RRC correspondentes são providos aqui. Em um primeiro exemplo, o tipo de serviço compreende “restauração de emergência de CS de origem em móvel (MO)”. Neste caso, a EC de RRC compreende um dentre “sinalização de MO” e “dados de MO”. Em um segundo exemplo, o tipo de serviço compreende “restauração de emergência de CS de terminação em móvel (MT)”. Neste caso, a EC de RRC compreende um dentre “acesso de MT” ou “sinalização de origem em móvel (MO)” ou “dados de MO”. Em um terceiro exemplo, o tipo de serviço compreende uma “chamada de emergência de restauração de emergência de CS de origem em móvel (MO)”. Neste caso, a EC de RRC compreende uma “chamada de emergência”.

Em uma modalidade, outras mensagens além da mensagem de REQUISIÇÃO DE SERVIÇO ESTENDIDO podem ter um elemento de informação de tipo de serviço. Este elemento de informação de tipo de serviço pode indicar o tipo de serviço requisitado. Assim, uma EC pode ser determinada com base no tipo de serviço associado em outras mensagens além da mensagem de REQUISIÇÃO DE SERVIÇO ESTENDIDO. Por exemplo, um sistema futuro pode ter um serviço de socialização de rede de vídeo. A EC baseada em tipo de serviço pode ser associada à mensagem de requisição e pode indicar que um serviço de vídeo é necessário.

A Figura 7 é um fluxograma que ilustra um processo de determinação de uma causa de estação rádio base de RRC de um procedimento de NAS de EPS durante uma comunicação de restauração de emergência de CS, de acordo com uma modalidade da exposição. O processo mostrado na Figura 7 ainda é uma outra forma de endereçamento às questões descritas com respeito às Figuras 1 a 4. O processo mostrado na Figura 7 pode ser implementado em um dispositivo tangível habilitado para um serviço de restauração de emergência de circuito comutado (CS) em um sistema de pacote evoluído (EPS). O dispositivo tangível pode ser um UA ou, opcionalmente, uma CN. No caso de um UA ou de uma CN, o dispositivo tangível ainda compreende uma camada de protocolo que tem um estrato não de acesso (NAS).

O processo começa conforme o NAS gera uma causa de estabelecimento (EC) de controle de recurso de rádio (RRC) definido por EPS (bloco 700). O NAS define a EC de RRC de EPS para um dado tipo de serviço de restauração de emergência de CS (bloco 702). O processo termina depois disso.

Em uma modalidade, todas as ECs de RRC definidas por EPS incluem cinco ECs de RRC definidas e três ECs de RRC vagas. Neste caso, a EC de RRC definida para o dado tipo de serviço de restauração de emergência de CS substitui uma das três ECs de RRC vagas. Em uma modalidade, a EC de RRC substituída pode ser “serviços de restauração de emergência de CS”. Em uma outra modalidade, a EC de RRC substituída pode ser “chamada de emergência de CS”. Em ainda uma outra modalidade, duas das três ECs de RRC vagas podem ser substituídas, uma primeira sendo de “serviços de restauração de emergência de CS” e uma segunda sendo uma “chamada de emergência de CS”. Em modalidades diferentes, nomes diferentes para estas ECs de RRC anteriormente vagas podem ser usados, enquanto as funções das ECs de RRC anteriormente vagas permanecem substancialmente as mesmas. As funções incluem a indicação que a requisição de conexão de RRC é para serviços de restauração de emergência de CS, ou, se apropriado ou desejado, uma chamada de emergência de CS.

A Figura 8 é um fluxograma que ilustra um processo de determinação de uma causa de estabelecimento de RRC de um procedimento de NAS de EPS durante uma comunicação para a realização de um serviço de restauração de emergência de CS, de acordo com uma modalidade da exposição. O processo mostrado na Figura 8 ainda é uma outra técnica para a resolução das questões descritas com respeito às Figuras 1 a 4. O processo mostrado na Figura 8 corresponde à solução descrita com respeito à Figura 5.

O processo começa conforme um serviço de restauração de emergência de circuito comutado (CS) é iniciado em um dispositivo habilitado para sistema de pacote evoluído (EPS) (bloco 800). O dispositivo habilitado para EPS inclui uma camada de protocolo que tem um estrato não de acesso (NAS). O dispositivo habilitado para EPS então identifica um tipo requisição de serviço de restauração de emergência de CS que é iniciada (bloco 802). O NAS do dispositivo habilitado para EPS então processa uma causa de estabelecimento (EC) que controle de recurso de rádio (RRC) definida para EPS que corresponde ao tipo de serviço de restauração de emergência de CS (bloco 804). O termo “corresponde a” significa que um tipo em particular de serviço de restauração de emergência de CS tem uma EC de RRC em particular correspondente. O processo termina depois disso. Este processo pode ser realizado durante a geração da EC de RRC ou durante o recebimento da EC de RRC.

O mapeamento de tipos de requisições de serviço de restauração de emergência de CS para ECs de RRC definidas para EPS pode assumir diferentes formas. Em um primeiro exemplo, quando o tipo de requisição de serviço de restauração de emergência de CS compreende uma chamada de origem em móvel (MO) de CS, a EC de RRC correspondente pode ser uma dentre “sinalização de MO” ou “dados de MO”. Em um segundo exemplo, quando o tipo de requisição de serviço de restauração de emergência de CS compreende uma chamada de terminação em móvel (MT) de CS, a EC de RRC correspondente pode ser uma dentre “sinalização de origem em móvel” ou “dados de MO” ou “acesso de MT”. Em um terceiro exemplo, quando o tipo de requisição de serviço de restauração de emergência de CS compreende uma chamada de emergência de origem em móvel, a EC de RRC correspondente pode ser uma “chamada de emergência”.

O UA e outros componentes descritos acima poderiam incluir um componente de processamento que fosse capaz de executar instruções relacionadas às ações descritas acima. A Figura 9 ilustra um exemplo de um sistema 900 que inclui um componente de processamento 910 adequado para a implementação de uma ou mais modalidades mostradas aqui. Além do processador 910 (o qual pode ser referido como uma unidade de processador central ou CPU), o sistema 900 poderia incluir dispositivos de conectividade de rede 920, uma memória de acesso randômico (RAM) 930, uma memória apenas de leitura (ROM) 940, um armazenamento secundário 950 e dispositivos de entrada / saída (I/O) 960. Estes componentes poderiam se comunicar uns com os outros através de um barramento 970. Em alguns casos, alguns destes componentes podem não estar presentes ou podem ser combinados em várias combinações uns com os outros ou com outros componentes não mostrados. Estes componentes poderiam estar localizados em uma única entidade física ou em mais de uma entidade física. Quaisquer ações descritas aqui como sendo feitas pelo processador 910 poderiam ser feitas pelo processador 910 sozinho ou pelo processador 910 em conjunto com um ou mais componentes mostrados ou não mostrados nos desenhos, tal como um processador de sinal digital (DSP) 902. Embora o DSP 902 seja mostrado como um componente em separado, o DSP 902 poderia ser incorporado no processador 910.

O processador 910 executa instruções, códigos, programas de computador ou scripts que ele poderia acessar a partir dos dispositivos de conectividade de rede 920, da RAM 930, da ROM 940 ou do armazenamento secundário 950 (o qual poderia incluir vários sistemas baseados em disco, tal como um disco rígido, um disco flexível ou um disco ótico). Embora apenas uma CPU 910 seja mostrada, múltiplos processadores podem estar presentes. Assim, embora as instruções possam ser discutidas como sendo executadas por um processador, as instruções podem ser executadas simultaneamente, de forma serial ou de outra forma por um ou múltiplos processadores. O processador 910 pode ser implementado como um ou mais chips de CPU.

Os dispositivos de conectividade de rede 920 podem assumir a forma de modems, bancos de modem, placas de Ethernet, placas de interface de barramento serial universal (USB), interfaces seriais, cartões de token ring (redes em anel), placas de interface de dados distribuídos de fibra (FDDI), placas de rede de área local sem fio (WLAN), placas de transceptor de rádio, tais como placas de transceptor de rádio de acesso múltiplo com divisão de código (CDMA) e/ou sistema global para comunicações móveis (GSM), dispositivos de interoperabilidade mundial para acesso por micro-ondas (WiMAX), e/ou outros dispositivos bem conhecidos para conexão a redes. Estes dispositivos de conectividade de rede 920 podem permitir que o processador 910 se comunique com a Internet ou uma ou mais redes de telecomunicações ou outras redes a partir das quais o processador 910 poderia receber uma informação ou da qual o processador 910 poderia extrair uma informação. Os dispositivos de conectividade de rede 920 também poderiam incluir um ou mais componentes transceptores 925 capazes de transmitirem e/ou receberem dados de forma sem fio.

A RAM 930 poderia ser usada para o armazenamento de dados voláteis e, talvez, para o armazenamento de instruções que são executadas pelo processador 910. A ROM 940 é um dispositivo de memória não volátil que tipicamente tem uma capacidade de memória menor do que a capacidade de memória do armazenamento secundário 950. A ROM 940 poderia ser usada para o armazenamento de instruções e, talvez, dados, que são lidos durante uma execução das instruções. O acesso à RAM 930 e à ROM 940 é tipicamente mais rápido do que ao armazenamento secundário 950. O armazenamento secundário 950 tipicamente é compreendido por uma ou mais unidades de disco ou unidades de fita, e poderia ser usado para o armazenamento não volátil de dados e como um dispositivo de armazenamento de dados de estouro para cima, caso a RAM 930 não seja grande o bastante para manter todos os dados de trabalho. O armazenamento secundário 950 pode ser usado para o armazenamento de programas os quais são carregados na RAM 930, quando esses programas forem selecionados para execução.

Os dispositivos de I/O 960 podem incluir visores de cristal líquido (LCDs), visores de tela de toque, teclados, miniteclados, comutadores, discos, mouses, trackballs, reconhecedores de voz, leitoras de cartão, leitoras de tira de papel, impressoras, monitores de vídeo ou outros dispositivos de entrada bem conhecidos. Também, o transceptor 925 poderia ser considerado como sendo um componente dos dispositivos de I/O 960, ao invés de ou além de ser um componente dos dispositivos de conectividade de rede 920.

O que vem a seguir é incorporado aqui como referência para todas as finalidades: especificações técnicas (TS) do Projeto de Parceria de Terceira Geração (3GPP) TS 24.008, 25.331, 24.301, 23.272, 36.331, 36.813 e TS 36.814 do 3GPP, bem como apêndices, A e B, os quais acompanham este relatório descritivo e são considerados parte deste relatório descritivo.

Assim, as modalidades proveem um agente de usuário, um dispositivo de rede de núcleo e um método para indicação de um serviço de restauração de emergência de circuito comutado (CS) em um sistema de pacote evoluído (EPS). No caso de um UA, o UA ainda compreende uma camada de protocolo que tem um estrato não de acesso (NAS). Um processador do dispositivo de UA ainda é configurado para promover o NAS para processamento de uma REQUISIÇÃO DE SERVIÇO ESTENDIDO tendo um tipo de serviço com um valor de decodificação. O valor de decodificação identifica uma causa de estabelecimento (EC) de controle de recurso de rádio (RRC) definido para EPS. Em modalidades alternativas, um processo similar pode ser implementado em uma CN, e, possivelmente, em uma RAN.

As modalidades também proveem um agente de usuário, um dispositivo de rede de núcleo e um método para indicação de um serviço de restauração de emergência de circuito comutado (CS) em um sistema de pacote evoluído (EPS). No caso de um UA, o UA inclui uma camada de protocolo que tem um estrato não de acesso (NAS). Um processador do UA é configurado para promover o NAS para gerar uma causa de estabelecimento (EC) de controle de recurso de rádio (RRC) definido para EPS. A EC de RRC é definida pelo NAS para um dado tipo de serviço de restauração de emergência de CS. Em modalidades alternativas, um processo similar pode ser implementado em uma CN, e, possivelmente, em uma RAN.

As modalidades também proveem um agente de usuário, um dispositivo de rede de núcleo e um método para indicação de um serviço de restauração de emergência de circuito comutado (CS) em um sistema de pacote evoluído (EPS). No caso de um UA, o dispositivo de UA inclui uma camada de protocolo que tem um estrato não de acesso (NAS). Um processador do UA é configurado para identificar uma requisição de tipo de serviço para a qual o serviço de restauração de emergência de CS é iniciado. O processador ainda é configurado para fazer com que o NAS processe uma causa de estabelecimento (EC) de controle de recurso de rádio (RRC) definido para EPS que está associada ao tipo. Em modalidades alternativas, um processo similar pode ser implementado em uma CN, e, possivelmente, em uma RAN.

As modalidades ainda proveem um UA que inclui um processador configurado para a regulagem de uma causa de estabelecimento (EC) com base em um tipo de serviço. O processador ainda pode ser configurado para regular a causa de estabelecimento para “dados de MO”, se o tipo de serviço for regulado para “restauração de emergência de CS de origem em móvel”. O processador pode ser configurado, ainda, para a regulagem da causa de estabelecimento para “acesso de MT”, se o tipo de serviço for regulado para “restauração de emergência de CS de terminação em móvel”. O processador ainda pode ser configurado para a regulagem da causa de estabelecimento para “chamada de emergência”, se o tipo de serviço for regulado para “chamada de emergência de restauração de emergência de CS de origem em móvel”.

As modalidades ainda proveem um processador que pode ser configurado para a regulagem de uma causa de estabelecimento (EC) para “sinalização de MO”, se uma REQUISIÇÃO DE SERVIÇO requisitar recursos para uma sinalização de UL. Em uma outra modalidade, um processador pode ser configurado para a regulagem de uma causa de estabelecimento para “dados de MO”, se uma REQUISIÇÃO DE SERVIÇO requisitar recursos de rádio de plano de usuário. Em ainda uma outra modalidade, um processador pode ser configurado para a regulagem de uma causa de estabelecimento para “acesso de MT”, se um indicador de domínio de CN for regulado para PS (pacote comutado).

Embora várias modalidades tenham sido providas na presente exposição, deve ser entendido que os sistemas e métodos mostrados podem ser concretizados de muitas outras formas específicas, sem que se desvie do espírito ou do escopo da presente exposição. Os presentes exemplos devem ser considerados como ilustrativos e não restritivos, e a intenção não é estar limitado aos detalhes dados aqui. Por exemplo, os vários elementos ou componentes podem ser combinados ou integrados em um outro sistema, ou certos recursos podem ser omitidos, ou não implementados.

Também, técnicas, sistemas, síntese de sinal e métodos descritos aqui e ilustrados nas várias modalidades como discretos ou separados podem ser combinados ou integrados com outros sistemas, módulos, técnicas ou métodos, sem que se desvie do escopo da presente exposição. Outros itens mostrados ou discutidos como acoplados ou acoplados diretamente ou em comunicação com cada outro podem ser acoplados indiretamente ou se comunicar através de alguma interface, dispositivo ou componente intermediário, seja de forma elétrica, mecânica ou de outra forma. Outros exemplos de mudanças, substituições e alterações são averiguáveis por alguém versado na técnica e poderiam ser feitos sem que se desviassem do espírito e do escopo mostrados aqui.

Claims (17)

1. Equipamento de agente de usuário para operação em um sistema de pacote evoluído (EPS), caracterizado pelo fato de que compreende: uma camada de protocolo de estrato não de acesso (NAS) configurada para gerar uma mensagem de requisição de serviço de NAS compreendendo uma REQUISIÇÃO DE SERVIÇO ESTENDIDO e identificando um tipo de serviço relacionado à restauração de emergência de circuito comutado (CS); e uma camada de protocolo de estrato de acesso (AS) configurada para a regulagem de uma causa de estabelecimento (EC) de controle de recurso de rádio (RRC) de uma mensagem de REQUISIÇÃO DE CONEXÃO DE RRC, a EC com base no tipo de serviço relacionado à restauração de emergência de CS identificada pela mensagem de requisição de serviço de NAS, em que quando o tipo de serviço é “restauração de emergência de CS de origem em móvel (MO)”, a EC de RRC é regulada para “dados de MO”.

2. Equipamento de agente de usuário, de acordo com a reivindicação 1, caracterizado pelo fato de que quando o tipo de serviço é “restauração de emergência de CS de terminação em móvel (MT)”, a EC de RRC é regulada para “acesso de MT”, “sinalização de origem em móvel (MO)” e “dados de MO”.

3. Equipamento de agente de usuário, de acordo com a reivindicação 1, caracterizado pelo fato de que quando o tipo de serviço é “chamada de emergência de restauração de emergência de CS de origem em móvel (MO)”, a EC de RRC é regulada para “chamada de emergência”.

4. Equipamento de agente de usuário, de acordo com a reivindicação 1, caracterizado pelo fato de que a EC de RRC corresponde a um dado tipo de serviço de restauração de emergência de CS.

5. Equipamento de agente de usuário, de acordo com a reivindicação 1, caracterizado pelo fato de que mediante o equipamento de agente de usuário iniciar um serviço de restauração de emergência de circuito comutado (CS), a camada de protocolo de NAS é configurada para identificar um tipo de serviço de restauração de emergência de CS sendo iniciado e determinar a EC de RRC com base no tipo de restauração de emergência de CS iniciado.

6. Equipamento de agente de usuário, de acordo com a reivindicação 1, caracterizado pelo fato de que a camada de protocolo de NAS é ainda configurada para determinar a EC de RRC com base no tipo de serviço, e fornecer a EC de RRC para a camada de protocolo de AS.

7. Equipamento de agente de usuário, de acordo com a reivindicação 6, caracterizado pelo fato de que a EC de RRC com base no tipo de serviço é determinada de acordo com um mapeamento de procedimentos de NAS para ECs de RRC.

8. Equipamento de agente de usuário, de acordo com a reivindicação 1, caracterizado pelo fato de que a mensagem de requisição de serviço de NAS é uma mensagem de REQUISIÇÃO DE SERVIÇO ESTENDIDO.

9. Método implementado em um computador em um sistema de pacote evoluído (EPS), caracterizado pelo fato de compreender: gerar, em uma camada de protocolo de estrato não de acesso (NAS), uma mensagem de requisição de serviço de NAS compreendendo uma REQUISIÇÃO DE SERVIÇO ESTENDIDO e identificar um tipo de serviço relacionado à restauração de emergência de circuito comutado (CS); e regular, em uma camada de protocolo de estrato de acesso (AS), uma causa de estabelecimento (EC) de controle de recurso de rádio (RRC) de uma mensagem de REQUISIÇÃO DE CONEXÃO DE RRC, a EC com base no tipo de serviço relacionado à restauração de emergência de CS identificada pela mensagem de requisição de serviço de NAS, em que quando um tipo de serviço de “restauração de emergência de CS de origem em móvel (MO)” é gerado, regular a EC de RRC para “dados de MO”.

10. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que quando um tipo de serviço de “restauração de emergência de CS de terminação em móvel (MT)” é gerado, regular a EC de RRC para “acesso de MT”, “sinalização de origem em móvel (MO)”, ou “dados de MO”.

11. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que quando um tipo de serviço de “chamada de emergência de restauração de emergência de CS de origem em móvel (MO)” é gerado, regular a EC de RRC para “chamada de emergência”.

12. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que a EC de RRC corresponde a um dado tipo de serviço de restauração de emergência de CS.

13. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que: mediante iniciação de um serviço de restauração de emergência de circuito comutado (CS), identificar, na camada de protocolo de NAS, um tipo de serviço de restauração de emergência de CS sendo iniciado e determinar a EC de RRC com base no tipo de restauração de emergência de CS sendo iniciado.

14. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que ainda compreende determinar, 5 na camada de protocolo de NAS, a EC de RRC com base no tipo de serviço, e fornecer a EC de RRC para a camada de protocolo de AS.

15. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que determinar a EC de RRC é com 10 base no tipo de serviço de acordo com um mapeamento de procedimentos de NAS para ECs de RRC.

16. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que gerar a mensagem de requisição de serviço de NAS compreende gerar uma mensagem 15 de REQUISIÇÃO DE SERVIÇO ESTENDIDO.

17. Meio legível por computador, caracterizado pelo fato de conter instruções que, quando executadas por um processador, realiza as etapas do método conforme definido em qualquer uma das reivindicações 9 a 16.

Images