BR112017010802B1

BR112017010802B1 - Localização por referência para uma chamada de emergência do tipo over-the-top

Info

Publication number: BR112017010802B1
Application number: BR112017010802-0A
Authority: BR
Inventors: Stephen William Edge; Randall Coleman Gellens; Farrokh Khatibi
Original assignee: Qualcomm Incorporated
Priority date: 2014-11-24
Filing date: 2015-11-10
Publication date: 2023-10-24
Also published as: BR112017010802A2; AU2015354710A1; CN107005802B; EP3225041A1; KR20170091598A; AU2015354710B2; US10085142B2; EP3225041B1; KR102409866B1; US10097979B2; WO2016085648A1; JP6805143B2; CN107005802A; US20170339543A1; JP2017539161A; US20160249193A1

Abstract

localização por referência para uma chamada de emergência do tipo over-the-top. são revelados métodos e aparelhos para fornecer suporte para chamadas de localização e emergência para um provedor de serviço (sp) do tipo over-the-top (ott). um nó de rede de acesso recebe uma primeira mensagem a partir de um ue, determina uma referência de localização para o ue, e envia uma segunda mensagem que inclui a referência de localização para o ue. o próprio nó de rede de acesso pode determinar a referência de localização no lugar de um servidor de localização ou pode solicitar que o servidor de localização atribua e devolva a referência de localização. o nó de rede de acesso pode servir como um proxy e evitar a interação entre o ue e o servidor de localização. o servidor de localização pode receber posteriormente uma solicitação de localização para o ue a partir de uma entidade de rede em que a solicitação de localização inclui a referência de localização. o servidor de localização pode localizar o ue com o uso da referência de localização e devolver a localização de ue para a entidade de rede.

Description

REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS

[0001] O presente Pedido de Patente reivindica o benefício do Pedido de Patente Provisório no U.S. 62/083.768, intitulado "LOCATION BY REFERENCE FOR AN OVER- THE-TOP EMERGENCY CALL", depositado em 24 de novembro de 2014, e do Pedido de Patente Provisório no U.S. 62/101.974, intitulado "LOCATION TRANSFER ALTERNATIVES TO AN OVER-THE- TOP SERVICE PROVIDER", depositado em 9 de janeiro de 2015, atribuídos à presente cessionária e expressamente incorporados no presente documento a título de referência em sua totalidade.

INTRODUÇÃO

[0002] As modalidades da revelação se referem ao fornecimento de uma localização por referência para uma chamada de emergência do tipo over-the-top (OTT).

[0003] Os sistemas de comunicação sem fio foram desenvolvidos ao longo de diversas gerações, o que inclui um serviço de telefone sem fio analógico de primeira geração (1G), um serviço de telefone sem fio digital de segunda geração (2G) (o que inclui redes 2.5G provisórias) e serviços sem fio com capacidade para dados/Internet de alta velocidade de terceira geração (3G) e quarta geração (4G).

[0004] Como parte da evolução 4G, a Evolução a Longo Prazo (LTE) foi desenvolvida pelo Projeto de Parceria de 3a Geração (3 GPP) como uma tecnologia de rede de acesso de rádio para comunicação sem fio de dados de alta velocidade para telefones móveis e outros terminais de dados. O LTE evoluiu do Sistema Global para Comunicações Móveis (GSM) e de derivados do GSM, como taxas de Dados Aprimorados para Evolução de GSM (EDGE), Sistema de Telecomunicações Móvel Universal (UMTS) e Acesso de Pacote de Alta Velocidade (HSPA).

[0005] Na América do Norte, os sistemas de comunicações sem fio, como aqueles que suportam GSM, UMTS e LTE, que são empregados por operadores de rede pública, usam uma solução para 911 Aprimorado, ou E911, que liga autores de chamada de emergência aos recursos públicos apropriados. A solução tenta associar automaticamente o autor de chamada, isto é, o equipamento de usuário (UE) do autor de chamada, a uma localização específica, como um endereço físico ou coordenadas geográficas. Localizar automaticamente o autor de chamada com alta precisão (por exemplo, a um erro de distância de 50 metros ou menos) e fornecer a localização a um Ponto de Resposta de Segurança Público (PSAP) pode aumentar a velocidade com a qual o lado de segurança pública pode responder durante emergências, especialmente quando o autor de chamada possa estar incapacitado de comunicar sua localização ou não souber sua localização. Além disso, saber a localização aproximada de um autor de chamada de emergência (por exemplo, a célula de rede particular que o dispositivo do autor de chamada acessa) pode ser essencial para rotear uma chamada de emergência para o PSAP correto para a localização do autor de chamada.

[0006] Certos outros fornecedores, conhecidos como fornecedores de serviço (SPs) do tipo Over-the-Top (OTT), também podem fornecer serviços relacionados a voz e dados a usuários de dispositivos sem fio, mas sem necessariamente possuir ou operar uma rede sem fio pública ou atuar como um Operador de Rede Virtual Móvel (MVNO). Um usuário com um dispositivo sem fio pode acessar, então, recursos de SP OTT (por exemplo, um ou mais servidores) por meio de algum outro SP de rede sem fio - por exemplo, um SP com uma rede UMTS ou LTE - e possivelmente também por meio da Internet. O acesso é tipicamente transparente ao SP de rede sem fio de serviço (o acesso improvável a uma rede sem fio domiciliar ou MVNO) e pode ocorrer tipicamente acima dos níveis de rede e de protocolo de IP - o que leva ao nome "do tipo Over-the-Top". Nesse caso, o SP OTT pode fornecer a um usuário a capacidade de fazer chamadas de voz e dados (ou sessões), e, em alguns casos, com a capacidade de fazer uma chamada de emergência.

[0007] Entretanto, um SP OTT pode ter mais dificuldade que um operador de rede sem fio pública na obtenção de uma localização precisa e confiável para um autor de chamada de emergência devido ao acesso restrito a informações relacionadas à localização e falta de recursos com capacidade de localização. Por exemplo, enquanto uma rede sem fio de serviço puder ter acesso a informações relacionadas a células para um autor de chamada sem fio (por exemplo, uma ID de célula de serviço para o autor de chamada sem fio) e pode ter infraestrutura de rede que pode ser usada para obter uma localização precisa para um autor de chamada sem fio (por exemplo, estações-base que podem medir sinais provenientes de um dispositivo do autor de chamada sem fio ou cujos sinais possam ser medidos pelo dispositivo do autor de chamada sem fio e um servidor de localização para transformar tais medições em uma estimativa de localização), um SP OTT pode ter um pouco ou nada dessa infraestrutura ou dessas informações. Isso pode impedir um SP OTT de rotear uma chamada de emergência de um autor de chamada sem fio para o PSAP correto e/ou fornecer uma localização precisa do autor de chamada sem fio a um PSAP, o que pode impedir um SP OTT de fornecer serviços de emergência confiáveis. Dessa forma, pode existir benefícios na melhora do suporte de localização para chamadas de emergência feitas por meio de um SP OTT.

SUMÁRIO

[0008] O seguinte apresenta um sumário simplificado relacionado a um ou mais aspectos e/ou modalidades associadas aos mecanismos revelados no presente documento para fornecer uma localização por referência para uma chamada de emergência do tipo Over-the-Top (OTT). Como tal, o sumário a seguir não deve ser considerado uma visão geral extensiva relacionada a todos os aspectos e/ou modalidades previstos, tampouco deve-se considerar que o sumário a seguir identifique elementos vitais ou cruciais relacionados a todos os aspectos e/ou modalidades previstos ou a delinear o escopo associado a qualquer aspecto e/ou modalidade particular. Consequentemente, o sumário a seguir tem o único propósito de apresentar determinados conceitos relacionados a um ou mais aspectos e/ou modalidades relacionados aos mecanismos revelados no presente documento em uma forma simplificada a fim de preceder a descrição detalhada apresentada abaixo.

[0009] São revelados métodos e aparelhos para fornecer suporte para chamadas de localização e emergência para um provedor de serviço (SP) de OTT. Um método de localização de um equipamento de usuário (UE) realizado por um nó de rede de acesso que atende ao UE inclui o nó de rede de acesso que recebe uma primeira mensagem do UE, que determina uma referência de localização para o UE, em que a referência de localização é para uma servidor de localização que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado, e que envia uma segunda mensagem ao UE, em que a segunda mensagem compreende a referência de localização.

[0010] Um método de localização de um UE realizado em um servidor de localização inclui receber uma solicitação para uma referência de localização para o UE a partir de um nó de rede de acesso que atende ao UE, enviar a referência de localização para o UE ao nó de rede de acesso, receber uma solicitação de localização para uma localização do UE a partir de uma entidade de rede que não seja o nó de rede de acesso, sendo que a solicitação de localização inclui a referência de localização para o UE, determinar uma estimativa de localização para o UE, e enviar a estimativa de localização para o UE à entidade de rede.

[0011] Um método de localização de um UE realizado em um servidor de localização inclui receber uma solicitação de localização para uma localização do UE a partir de uma entidade de rede que não seja um nó de rede de acesso que atende ao UE, sendo que a solicitação de localização inclui uma referência de localização para o UE, em que a referência de localização compreende uma referência de UE para o UE, autenticar a referência de localização para o UE, determinar uma estimativa de localização para o UE com base na referência de UE na referência de localização para o UE, e enviar a estimativa de localização para o UE à outra entidade de rede.

[0012] Um método de localização de um UE que faz uma chamada realizada pelo UE inclui enviar uma primeira mensagem a um nó de rede de acesso que atende ao UE, receber uma segunda mensagem do nó de rede de acesso que compreende uma referência de localização para o UE, em que a referência de localização é para um servidor de localização que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado para a chamada, receber uma solicitação para a chamada a partir de um usuário do UE, e enviar uma solicitação para a chamada a um provedor de serviço do tipo Over-the-Top (SP) (OTT), sendo que a solicitação para a chamada inclui a referência de localização para o UE.

[0013] Um aparelho para localizar um UE realizado por um nó de rede de acesso que atende ao UE inclui pelo menos um processador e um transceptor acoplado ao pelo menos um processador, o pelo menos um processador e o transceptor configurados para receber uma primeira mensagem do UE, para determinar uma referência de localização para o UE, em que a referência de localização é para um servidor de localização que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado, e para enviar uma segunda mensagem ao UE, em que a segunda mensagem compreende a referência de localização.

[0014] Um aparelho para localizar um UE realizado em um servidor de localização inclui pelo menos um processador e um transceptor acoplados ao pelo menos em processador, o pelo menos um processador e o transceptor configurados para receber uma solicitação para uma referência de localização para o UE a partir de um nó de rede de acesso que atende ao UE, para enviar a referência de localização para o UE até o nó de rede de acesso, para receber uma solicitação de localização para uma localização do UE a partir de uma entidade de rede que não seja o nó de rede de acesso, sendo que a solicitação de localização inclui a referência de localização para o UE, para determinar uma estimativa de localização para o UE, e para enviar a estimativa de localização para o UE até a entidade de rede.

[0015] Um aparelho para localizar um UE realizado em um servidor de localização inclui pelo menos um processador e um transceptor acoplado ao pelo menos um processador, o pelo menos um processador e o transceptor configurados para receber uma solicitação de localização para uma localização do UE a partir de uma entidade de rede que não seja um nó de rede de acesso que atende ao UE, sendo que a solicitação de localização inclui uma referência de localização para o UE, em que a referência de localização compreende uma referência de UE para o UE, para autenticar a referência de localização para o UE, para determinar uma estimativa de localização para o UE com base na referência de UE na referência de localização para o UE, e para enviar a estimativa de localização para o UE até a outra entidade de rede.

[0016] Um aparelho para localizar um UE que faz uma chamada realizada pelo UE inclui pelo menos um processador e um transceptor acoplados ao pelo menos um processador, o pelo menos um processador e o transceptor configurados para enviar uma primeira mensagem a um nó de rede de acesso que atende ao UE, para receber uma segunda mensagem do nó de rede de acesso que compreende uma referência de localização para o UE, em que a referência de localização é para um servidor de localização que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado para a chamada, para receber uma solicitação para a chamada de um usuário do UE, e para enviar uma solicitação para a chamada até um SP OTT, sendo que a solicitação para a chamada inclui a referência de localização para o UE.

[0017] Um aparelho para localizar um UE realizado por um nó de rede de acesso que atende ao UE inclui meios para receber uma primeira mensagem do UE, meios para determinar uma referência de localização para o UE, em que a referência de localização é para um servidor de localização que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado, e meios para enviar uma segunda mensagem ao UE, em que a segunda mensagem compreende a referência de localização.

[0018] Um aparelho para localizar de um UE realizado em um servidor de localização inclui meios para receber uma solicitação para uma referência de localização para o UE a partir de um nó de rede de acesso que atende ao UE, meios para enviar a referência de localização para o UE ao nó de rede de acesso, meios para receber uma solicitação de localização para uma localização do UE a partir de uma entidade de rede que não seja o nó de rede de acesso, sendo que a solicitação de localização inclui a referência de localização para o UE, meios para determinar uma estimativa de localização para o UE, e meios para enviar a estimativa de localização para o UE à entidade de rede.

[0019] Um aparelho para localizar um UE realizado em um servidor de localização inclui meios para receber uma solicitação de localização para uma localização do UE a partir de uma entidade de rede que não seja um nó de rede de acesso que atende ao UE, sendo que a solicitação de localização inclui uma referência de localização para o UE, em que a referência de localização compreende uma referência de UE para o UE, meios para autenticar a referência de localização para o UE, meios para determinar uma estimativa de localização para o UE com base na referência de UE na referência de localização para o UE, e meios para enviar a estimativa de localização para o UE à outra entidade de rede.

[0020] Um aparelho para localizar um UE que faz uma chamada realizada pelo UE inclui enviar uma primeira mensagem a um nó de rede de acesso que atende ao UE, meios para receber uma segunda mensagem do nó de rede de acesso que compreende uma referência de localização para o UE, em que a referência de localização é para um servidor de localização que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado para a chamada, meios para receber uma solicitação para a chamada a partir de um usuário do UE, e meios para enviar uma solicitação para a chamada a um SP OTT, sendo que a solicitação para a chamada inclui a referência de localização para o UE.

[0021] Um meio legível por computador não transitório para localizar um UE realizado por um nó de rede de acesso que atende ao UE inclui pelo menos uma instrução para receber uma primeira mensagem do UE, pelo menos uma instrução para determinar uma referência de localização para o UE, em que a referência de localização é para um servidor de localização que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado, e pelo menos uma instrução para enviar uma segunda mensagem ao UE, em que a segunda mensagem compreende a referência de localização.

[0022] Um meio legível por computador não transitório para localizar um UE realizado em um servidor de localização inclui pelo menos uma instrução para receber uma solicitação para uma referência de localização para o UE a partir de um nó de rede de acesso que atende ao UE, pelo menos uma instrução para enviar a referência de localização para o UE até o nó de rede de acesso, pelo menos uma instrução para receber uma solicitação de localização para uma localização do UE a partir de uma entidade de rede que não seja o nó de rede de acesso, sendo que a solicitação de localização inclui a referência de localização para o UE, pelo menos uma instrução para determinar uma estimativa de localização para o UE, e pelo menos uma instrução para enviar uma estimativa de localização para o UE até a entidade de rede.

[0023] Um meio legível por computador não transitório para localizar um UE realizado em um servidor de localização inclui pelo menos uma instrução para receber uma solicitação de localização para uma localização do UE a partir de uma entidade de rede que não seja um nó de rede de acesso que atende ao UE, sendo que a solicitação de localização inclui uma referência de localização para o UE, em que a referência de localização compreende uma referência de UE para o UE, pelo menos uma instrução para autenticar a referência de localização para o UE, pelo menos uma instrução para determinar uma estimativa de localização para o UE com base na referência de UE na referência de localização para o UE, e pelo menos uma instrução para enviar a estimativa de localização para o UE até a outra entidade de rede.

[0024] Um meio legível por computador não transitório para localizar um UE que faz uma chamada realizada pelo UE inclui pelo menos uma instrução para enviar uma primeira mensagem a um nó de rede de acesso que atende ao UE, pelo menos uma instrução para receber uma segunda mensagem do nó de rede de acesso que compreende uma referência de localização para o UE, em que a referência de localização é para um servidor de localização que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado para a chamada, pelo menos uma instrução para receber uma solicitação para a chamada a partir de um usuário do UE, e pelo menos uma instrução para enviar uma solicitação para a chamada até um SP OTT, sendo que a solicitação para a chamada inclui a referência de localização para o UE.

[0025] Outros objetivos e vantagens associados aos mecanismos revelados no presente documento ficarão evidentes para as pessoas versadas na técnica com base nos desenhos anexos e na descrição detalhada.

BREVE DESCRIÇÃO DOS DESENHOS

[0026] Uma apreciação mais completa das modalidades da revelação e muitas das vantagens concomitantes das mesmas será prontamente obtida à medida que os mesmos se tornem melhor compreendidos através de referência à descrição detalhada a seguir, quando considerada em conexão com os desenhos anexos que são apresentados unicamente para ilustração, e não para limitação da revelação, e em que:

[0027] A Figura 1A ilustra uma arquitetura de sistema de alto nível de um sistema de comunicações sem fio de acordo com pelo menos um aspecto da revelação.

[0028] A Figura 1B ilustra uma configuração exemplificativa da arquitetura de sistema na Figura 1A para acesso sem fio de Evolução a Longo Prazo (LTE) de acordo com pelo menos um aspecto da revelação.

[0029] A Figura 2A ilustra interações específicas das entidades de rede ilustradas na Figura 1A para fornecer uma localização por referência de acordo com pelo menos um aspecto a revelação.

[0030] A Figura 2B ilustra interações específicas das entidades de rede ilustradas na Figura 1B para fornecer uma localização por referência de acordo com pelo menos um aspecto a revelação.

[0031] A Figura 3 ilustra uma arquitetura exemplificativa para fornecer serviços de emergência de acordo com pelo menos um aspecto da revelação.

[0032] A Figura 4 ilustra uma arquitetura exemplificativa para a localização por referência do suporte de acordo com pelo menos um aspecto da revelação.

[0033] A Figura 5 ilustra uma arquitetura exemplificativa para o suporte do Subsistema de Multimídia (IMS) do Protocolo de Internet (IP) para serviços de emergência de acordo com pelo menos um aspecto da revelação.

[0034] A Figura 6 ilustra outra arquitetura exemplificativa para suporte de IMS para serviços de emergência de acordo com pelo menos um aspecto da revelação.

[0035] A Figura 7 ilustra um fluxo de chamada exemplificativo para localização por valor e localização por referência de acordo com pelo menos um aspecto da revelação.

[0036] A Figura 8 ilustra um fluxo de chamada exemplificativo adicional para o suporte de IMS de uma chamada de emergência de acordo com pelo menos um aspecto da revelação.

[0037] A Figura 9 ilustra outro fluxo de chamada exemplificativo para o Suporte de IMS de uma chamada de emergência de acordo com pelo menos um aspecto da revelação.

[0038] A Figura 10 é um diagrama de blocos simplificado de diversos aspectos de amostra dos componentes configurados para suportar comunicação conforme ensinado no presente documento.

[0039] A Figura 11 ilustra um exemplo de um equipamento de usuário (UE) de acordo com pelo menos um aspecto da revelação.

[0040] A Figura 12 ilustra um dispositivo de comunicação que inclui componentes estruturais para realizar a funcionalidade descrita no presente documento.

[0041] A Figura 13 ilustra um servidor de acordo com uma modalidade da revelação.

[0042] As Figuras 14 a 20 ilustram fluxos exemplificativos para localizar um UE de acordo com diversos aspectos da revelação.

[0043] As Figuras 21 a 27 são outros diagramas de blocos simplificados de diversos aspectos de amostra dos aparelhos configurados para suportar comunicação conforme ensinado no presente documento.

[0044] É observado que nos fluxos de mensagens e chamada mostrados nas Figuras 2A, 2B, 7, 8 e 9, mensagens e ações individuais são indicadas por rótulos numéricos que são referidos às vezes na descrição como operações, blocos ou etapas.

DESCRIÇÃO DETALHADA

[0045] São revelados métodos e aparelhos para fornecer suporte para chamadas de localização e emergência para um provedor de serviço (SP) do tipo over-the-top (OTT). Um nó de rede de acesso recebe uma primeira mensagem a partir de um UE, determina uma referência de localização para o UE, e envia uma segunda mensagem que inclui a referência de localização para o UE. O próprio nó de rede de acesso pode determinar a referência de localização no lugar de um servidor de localização ou pode solicitar que o servidor de localização atribua e devolva a referência de localização. O nó de rede de acesso pode servir como um proxy e evitar a interação entre o UE e o servidor de localização. O servidor de localização pode receber posteriormente uma solicitação de localização para o UE a partir de uma entidade de rede em que a solicitação de localização inclui a referência de localização. O servidor de localização pode localizar o UE com o uso da referência de localização e devolver a localização de UE para a entidade de rede. A entidade de rede pode ser um SP OTT e a localização do UE pode ser para suportar uma chamada de emergência a partir do UE enviada para o SP OTT.

[0046] Esses e outros aspectos da revelação são revelados na descrição a seguir e desenhos relacionados direcionados a modalidades específicas da revelação. As modalidades alternativas podem ser concebidas sem se afastar do escopo da revelação. Adicionalmente, elementos bem conhecidos da revelação não serão descritos em detalhes ou serão omitidos de modo a não obscurecer os detalhes relevantes da revelação.

[0047] As palavras "exemplificativo" e/ou "exemplo" são usadas no presente documento para atribuir o significado de "servir como um exemplo, uma situação ou ilustração”. Qualquer modalidade descrita no presente documento como "exemplificativa" e/ou "exemplo" não deve necessariamente ser interpretada como preferencial ou vantajosa sobre outras modalidades. Da mesma forma, o termo "modalidades da revelação" não necessita que todas as modalidades da revelação incluem a característica, vantagem ou modo discutido de operação.

[0048] Adicionalmente, muitas modalidades são descritas em termos de sequências de ações a serem realizadas por, por exemplo, elementos de um dispositivo de computação. Será reconhecido que diversas ações descritas no presente documento podem ser realizadas por circuitos específicos (por exemplo, circuitos integrados para aplicação específica (ASICs)), por instruções de programa que são executadas por um ou mais processadores, ou por uma combinação de ambos. Adicionalmente, essas sequências de ações descritas no presente documento podem ser consideradas como estando incorporadas inteiramente dentro de qualquer forma de meio de armazenamento legível por computador que tenha armazenado no mesmo um conjunto correspondente de instruções de computador que, mediante execução, fariam com que um processador associado realizasse a funcionalidade descrita no presente documento. Dessa forma, os diversos aspectos da revelação podem ser incorporados de inúmeras formas diferentes, todas as quais forma contempladas para estarem dentro do escopo da matéria reivindicada. Além disso, para cada uma das modalidades descritas no presente documento, a forma correspondente de quaisquer tais modalidades pode ser descrita no presente documento como, por exemplo, "lógica configurada para" realizar a ação descrita.

[0049] A Tabela 1 fornece um glossário de termos e abreviações usados nessa revelação: TABELA 1 - GLOSSÁRIO DE TERMOS E ABREVIAÇÕES

[0050] Um dispositivo de cliente, chamado, no presente documento, de um equipamento de usuário (UE), pode ser móvel ou estacionário, e pode se comunicar com uma rede de acesso por rádio (RAN). Conforme usado no presente documento, o termo "UE" pode ser referido de modo intercambiável como um "terminal de acesso" ou "AT", um "dispositivo sem fio", um "terminal sem fio", um "dispositivo de assinante", um "terminal de assinante", uma "estação de assinante", um "terminal de usuário" ou "UT", um "terminal móvel", uma "estação móvel", um "terminal", um "dispositivo", um "dispositivo de usuário" e variações dos mesmos. Geralmente, os UEs podem se comunicar com uma rede de núcleo através de uma RAN e, através da rede de núcleo, os UEs podem ser conectados a redes externas, tais como a Internet. Obviamente, outros mecanismos de conexão à rede de núcleo e/ou à Internet também são possíveis para os UEs, tal como redes de acesso por fio, redes WiFi (por exemplo, com base em IEEE 802.11, etc.), e assim por diante. Os UEs podem ser incorporados por qualquer dentre inúmeros tipos de dispositivos, o que inclui, mas sem limitações, placas de PC, dispositivos flash compactos, modems externos ou internos, telefones com linha ou sem fio, smartphones, computadores do tipo tablet, computadores do tipo laptop e assim por diante. Um enlace de comunicação através do qual os UEs podem enviar sinais para a RAN é chamado de um canal de enlace ascendente (por exemplo, um canal de tráfego reverso, um canal de controle reverso, um canal de acesso, etc.). Um enlace de comunicação através do qual a RAN pode enviar sinais para UEs é chamado de um enlace descendente ou canal de enlace direto (por exemplo, um canal de paginação, um canal de controle, um canal de difusão, um canal de tráfego direto, etc.). Conforme usado no presente documento, o termo canal de tráfego (TCH) pode se referir ou a um enlace ascendente / canal de tráfego reverso ou a um enlace descendente / canal de tráfego direto.

[0051] A Figura 1A ilustra uma arquitetura de sistema de alto nível de um sistema de comunicações sem fio 100A de acordo com uma modalidade da revelação. O sistema de comunicações sem fio 100A contém uma quantidade N de UEs rotulados 1...N. Os UEs 1...N podem incluir telefones celulares, assistentes digitais pessoais (PDAs), pagers, um computador do tipo laptop, um computador do tipo desktop, e assim por diante. Por exemplo, na Figura 1A, os UEs 1...2 são ilustrados como telefones celulares de chamada, os UEs 3...5 são ilustrados como telefones celulares de tela sensível ao toque ou smartphones, e o UE N é ilustrado como um computador do tipo desktop ou PC.

[0052] Com referência à Figura 1A, os UEs 1...N são configurados para se comunicarem com uma rede de acesso (por exemplo, a RAN 120, um ponto de acesso 125, etc.) por uma interface ou camada de comunicações física, mostrada na Figura 1A como interfaces aéreas 104, 106, 108 e/ou uma conexão com fio direta 102. As interfaces sem fio 104 e 106 podem cumprir com um dado protocolo de comunicações celular (por exemplo, Acesso por Múltiplas Divisões de Código (CDMA), Dados de Evolução Otimizados (EVDO), Dados em Pacote de Taxa Alta Aprimorados (eHRPD), Sistema Global para Comunicações Móveis (GSM), Taxas de Dados Aprimorados para Evolução de GSM (EDGE), CDMA de Banda Larga (WCDMA), Evolução a Longo Prazo (LTE), etc.), enquanto a interface sem fio 108 pode cumprir com um protocolo de rede de área local sem fio (WLAN) (por exemplo, IEEE 802.11, Bluetooth®, etc.). Conforme será descrito adicionalmente abaixo, a RAN 120 inclui uma pluralidade de pontos de acesso que servem UEs por meio de interfaces aéreas, tais como as interfaces aéreas 104 e 106. Os pontos de acesso na RAN 120 podem ser chamados de nós de acesso (ANs), pontos de acesso (APs), estações-base (BSs), Nós B, Nós B evoluídos (eNobdeBs) e assim por diante. Esses pontos de acesso podem ser pontos de acesso terrestre (ou estações em solo), ou pontos de acesso via satélite. A RAN 120 é configurada para se conectar a uma rede principal (CN) 140, que também pode ser referida como uma Rede Principal de Pacote (PCN) ou Núcleo de Pacote Evoluído (EPC), que pode realizar uma diversidade de funções, o que inclui rotear e conectar chamadas comutadas por circuito (CS) entre UEs servidos pela RAN 120 e outros UEs ou outras entidades de não UE servidos pela RAN 120 ou uma RAN diferente ou rede diferente (não RAN) juntas, e também pode mediar uma troca de dados comutados por pacote (PS) com outras entidades por meio de redes externas como a Internet 175. A RAN 120 mais a CN 140 podem atuar como uma rede sem fio de serviço para um ou mais dos UEs 1 a N. O termo rede sem fio é usado no presente documento de modo intercambiável com o termo operador de rede móvel (MNO) para se referir a uma rede sem fio e a infraestrutura dentro da rede sem fio (por exemplo, a RAN 120 e a CN 140).

[0053] A Internet 175 inclui inúmeros agentes de roteamento e agentes de processamento (não mostrados na Figura 1A para propósitos de conveniência). Na Figura 1A, o UE N é mostrado como conectado à Internet 175 diretamente (isto é, de modo separado da rede principal 140, como por meio de um DSL ou SP de cabo em pacote, e que pode ser por meio do próprio ponto de acesso 125 em um exemplo (por exemplo, por um roteador de WiFi)). A Internet 175 pode funcionar, portanto, para rotear comunicações de dados comutados por pacote entre o UE N e outros UEs que acessam a Internet 175 (por exemplo, por meio da rede principal 140).

[0054] Também é mostrado na Figura 1A o ponto de acesso 125 que é separado da RAN 120. O ponto de acesso 125 pode ser conectado à Internet 175 independentemente da Rede Principal (CN) 140 (por exemplo, através de um sistema de comunicação óptico tal como FiOS, um modem a cabo, etc.). A interface aérea 108 pode servir o UE 4 ou o UE 5 por uma conexão sem fio local, tal como IEEE 802.11 ou Bluetooth em um exemplo.

[0055] Com referência à Figura 1A, um servidor de localização 170 é mostrado como conectado à Internet 175, à CN 140, ou ambas. O servidor de localização 170 pode ser implantado como uma pluralidade de servidores estruturalmente separados ou, alternativamente, pode corresponder a um único servidor. Conforme será descrito abaixo em mais detalhes, o servidor de localização 170 é configurado para suportar um ou mais serviços de localização (por exemplo, serviços de posicionamento, posição por serviços de referência, etc.) para UEs que podem se conectar ao servidor de localização 170 por meio da CN 140 e/ou por meio da Internet 175.

[0056] A Figura 1A ilustra adicionalmente um Fornecedor de Serviço (SP) do tipo Over-the-Top (OTT) 150. Um SP OTT pode transferir áudio, vídeo e/ou outro conteúdo de mídia para e/ou a partir de um ou mais dos UEs 1 para N pela Internet 175 e possivelmente pela RAN 120 e pela CN 140 se um modo que seja parcial ou completamente transparente à Internet 175, à RAN 120 e à CN 140. Um SP OTT tipicamente se refere a um provedor de terceiros, como Skype™, Hulu, Netflix, Google etc. O SP OTT 150 pode se comunicar com os UEs 1...N pela Internet 175, pela CN 140, pela RAN 120 e/ou pelo ponto de acesso 125. Embora apenas um único SP OTT 150 seja ilustrado na Figura 1A, conforme é aparente, pode haver qualquer quantidade de SPs OTT 150 conectados à Internet 175, sendo que cada um corresponde a uma SP OTT diferente. O SP OTT 150 pode ter um ou mais servidores, rotear proxies e/ou outras entidades (não mostradas na Figura 1A) que podem realizar as diversas funções descritas no presente documento para SP OTT 150. O mesmo se aplica para outros SPs OTT referidos posteriormente no presente documento como SP OTT 350, 450, 550, 650, 750, 850 e 950.

[0057] Além disso, é ilustrada na Figura 1A é uma Rede de IP de Serviços de Emergência (ESInet) e/ou Roteador Seletivo (SR) 160. O ESInet 160 pode ter capacidade para rotear chamadas de emergência com base em IP feitas por qualquer um dos UEs 1 a N e recebidas por meio da Internet 175, da CN 140 ou do SP OTT 150 até um Ponto de Resposta de Segurança Público (PSAP) adequado, como PSAP 180. De modo similar, o SR 160 pode ter capacidade para rotear uma chamada de emergência Comutada por Circuito (CS) feita por qualquer um dos UEs 1 a N e recebida por meio de CN 140 a um PSAP, como o PSAP 180. Em algumas modalidades, qualquer um dos UEs 1 a N pode originar uma chamada de emergência com base em IP, que pode ser transformada por CN 140 ou por SP OTT 150 em uma chamada de emergência CS e enviada para o SR 160 (por exemplo, por meio da Rede de Telefone Comutada Pública, não mostrada na Figura 1A) para rotear a um PSAP com capacidade CS 180. Isso pode ocorrer quando houver um SR 160, mas não ESInet 160 e/ou quando o PSAP 180 suportar chamadas de emergência de CS, mas não chamadas de emergência com base em IP. Deve ser entendido que, nas descrições do estabelecimento de chamada de emergência por meio de um SP OTT 150 posteriormente no presente documento, a chamada de emergência pode começar como uma chamada de emergência com base em IP a partir de um UE (por exemplo, qualquer um dos UEs 1 a N), mas pode ser convertida em uma chamada de emergência CS pelo SP OTT 150 e roteada para o PSAP 180 por meio de um SR 160 e não por meio de um ESInet 160.

[0058] Os UEs 1...N na Figura 1A podem ter capacidade para fazer chamadas de emergência de voz, texto, vídeo ou outros dados por meio da Internet 175. Por exemplo, os UEs 1...N podem ter capacidade para fazer tal chamada de emergência por meio do SP OTT 150, conforme descrito adicionalmente abaixo. O ESInet/SR 160 pode entregar essas chamadas de emergência de voz, texto, vídeo e dados ao PSAP 180, que pode ser, por exemplo, um centro de chamada de emergência. O protocolo usado para entregar essas chamadas de emergência pode ser o Protocolo de Iniciação de Sessão (SIP) definido pela Força Tarefa de Engenharia de Internet (IETF). Além disso, as chamadas de emergência com base em SIP podem ser entregues com o uso do Subsistema de Multimídia de IP (IMS) definido pelo 3GPP, que suporta o uso de SIP e pode ser suportado pela CN 140.

[0059] Um exemplo de uma implantação específica de protocolo para a RAN 120 e a CN 140 é fornecido abaixo em relação à Figura 1B para ajudar a explicar o sistema de comunicações sem fio 100A em mais detalhes no caso de suporte de acesso de LTE pela RAN 120. Em particular, os componentes da RAN 120 e da CN 140 correspondem a componentes associados ao suporte de comunicações comutadas por pacote (PS), pelas quais os componentes herdados comutados por circuito (CS) também podem estar presentes nessas redes, mas não são mostrados de modo explícito na Figura 1B.

[0060] Especificamente, a Figura 1B ilustra uma configuração exemplificativa 100B da RAN 120 e da CN 140 com base em um Sistema de Pacote Evoluído (EPS) que suporta acesso de LTE sem fio, de acordo com uma modalidade da revelação. No exemplo da Figura 1B, a RAN 120 na rede de EPS/LTE é configurada com uma pluralidade de Nós B evoluídos (eNodeBs ou eNBs) 122, 124 e 126. A CN 140 inclui uma pluralidade de Entidades de Gerenciamento de Mobilidade (MMEs) 142 e 144, um Centro de Localização Móvel de Serviço Aprimorado (E-SMLC) 172, uma Porta de Comunicação de Serviço (S-GW) 146 e uma Porta de Comunicação de Rede de Dados em Pacote (PDG) 148. No exemplo da Figura 1B, o servidor de localização 170 é um Centro de Localização Móvel de Porta de Comunicação (GMLC) que suporta a solução de localização de plano de controle de LTE ou uma Plataforma de Localização (SLP) da Localização de Plano de Usuário Segura (SUPL) 170 que suporta a solução de SUPL de localização definida pela Aliança Móvel Aberta (OMA). Em algumas modalidades, o servidor de localização 170 pode ser uma Função de Recuperação de Localização (LRF) com uma conexão ou associação com um GMLC e/ou um SLP. As interfaces de rede entre esses componentes, a RAN 120 e a Internet 175 são ilustradas na Figura 1B e são definidas na Tabela 2. TABELA 2

[0061] Uma descrição de alto nível dos componentes mostrados na RAN 120 e na CN 140 da Figura 1B será descrita agora. Entretanto, alguns desses componentes são bem conhecidos na técnica a partir de diversas Especificações Técnicas (TSs) de 3GPP, e a descrição contida no presente documento não está destinada a ser uma descrição minuciosa de toda a funcionalidade realizada por esses componentes.

[0062] Com referência à Figura 1B, os MMEs 142 e 144 são configurados para gerenciar a sinalização de plano de controle para os portadores de EPS e para suportar a mobilidade para UEs que acessam a CN 140. As funções de MME incluem: sinalização de Estrato de Não Acesso (NAS), segurança de sinalização de NAS, gerenciamento de Mobilidade para entregas inter- e intratecnologia, seleção de PDG e S-GW, e seleção de MME para entregas com mudança de MME.

[0063] A S-GW 146 é a porta de comunicação que encerra a interface em direção à RAN 120 para a sinalização de plano de usuário. Para cada UE anexado à CN 140 para um sistema com base em EPS, em um dado ponto no tempo, existe uma única S-GW. As funções da S-GW 146, para o S5/S8 com base em IPv6 Móvel de Proxy (PMIP), incluem: O ponto de âncora de mobilidade, roteamento e encaminhamento de Pacote, e a definição do Ponto de Código DiffServ (DSCP) com base em um Identificador de Classe de QoS (QCI) do portador de EPS associado.

[0064] Com referência à Figura 1B, a PDG 148 é a porta de comunicação que encerra a interface de SGi em direção à Rede de Dados de Pacote (PDN), por exemplo, a Internet 175. Se um UE acessar múltiplas PDNs, pode haver mais de uma PDG para aquele UE. As funções de PDG 148 incluem: filtrar o pacote (por inspeção de pacote profunda), alocação de endereço de IP do UE, definir o DSCP com base nas QCI do portador de EPS associado, considerar o carregamento interoperador, vinculação de portador de enlace ascendente (UL) e enlace descendente (DL) conforme definido em 3GPP TS 23.203, e a verificação de vinculação de portador de UL conforme definido em 3GPP TS 23.203. A PDG 148 fornece conectividade de PDN a Rede de Acesso por Rádio de GSM/EDGE (GERAN) / UEs de apenas UTRAN e UEs com capacidade de LTE com o uso de uma RAN 120 que pode ser qualquer uma dentre E-UTRAN, GERAN ou UTRAN. A PDG 148 fornece conectividade de PDN a UEs com capacidade de LTE com o uso de uma RAN 120 que compreende eNBs como mostrado na Figura 1B (que é referido como uma E-UTRAN) pela interface de S5/S8.

[0065] Com referência à Figura 1B, o GMLC/SLP 170 é mostrado como conectado à MME 142, à PDG 148 na CN 140 e/ou à Internet 175. O GMLC/SLP 170 pode ser um GMLC ou um SLP ou pode ser uma LRF com uma conexão ou associação com um GMLC ou SLP. Um GMLC 170 (ou uma LRF 170 com um GMLC associado ou conectado) suporta a solução de localização de plano de controle de LTE enquanto um SLP 170 (ou uma LRF 170 com um SLP associado ou conectado) suporta a solução de SUPL de localização. No caso de GMLC/SLP 170 ser um GMLC, mas não um SLP, o GMLC/SLP 170 pode se conectar à MME 142 e a um ou ambos dentre a PDG 148 e a Internet 175. No caso de GMLC/SLP 170 se um SLP, mas não um GMLC, o GMLC/SLP 170 pode se conectar ou não a um MME 142 e pode se conectar a um ou ambos dentre a PDG 148 e a Internet 175. O GMLC/SLP 170 pode permitir que uma entidade externa, como o SP OTT 150, o ESInet 160 ou PSAP 180, envie uma solicitação de localização para o GMLC/SLP 170 para qualquer um dos UEs 1 a N na Figura 1A, possa coordenar uma determinação de localização para esse UE com o uso da solução de localização de plano de controle de 3GPP no caso de um GMLC, ou SUPL no caso de um SLP, e pode devolver a localização determinada para a entidade externa solicitante. O E-SMLC 172 ilustrado na Figura 1B é conectado à MME 142 e é outro servidor de localização usado para obter uma estimativa de localização de UE com o uso da solução de localização de plano de controle de LTE.

[0066] Em uma solução de localização de plano de controle, um servidor de localização (por exemplo, o servidor de localização 170 na Figura 1A ou o GMLC/SLP 170 na Figura 1B) é acessado por outros elementos, o que inclui UEs, por meio de interfaces de sinalização existentes em uma rede. Toda a sinalização relacionada à localização de um UE é transportada de modo explícito como sinalização em todas as interfaces. No caso do acesso de LTE, a solução de localização de plano de controle é definida em 3GPP TSs 23.271 e 36.305.

[0067] Em uma solução de localização de plano de usuário, como a solução de SUPL, um UE e um servidor de localização como GMLC/SLP 170 na Figura 1B se comunicam pela troca de dados a partir da perspectiva da rede, como por meio de IP ou TCP/IP. No caso da solução de SUPL, o GMLC/SLP 170 seria um SLP e pode ser usado para obter uma localização ao invés de usar o E-SMLC 172. Em alguns casos, uma rede pode empregar tanto uma solução de localização de plano de controle quanto uma solução de localização de plano de usuário, como SUPL. Nesse caso, o E-SMLC 172 pode estar presente e o GMLC/SLP 170 pode compreender tanto um GMLC quanto um SLP. O GMLC e a SLP para GMLC/SLP 170 também podem ser combinados (por exemplo, na mesma entidade física) ou podem ser conectados entre si em ordem para permitir que ambas as soluções sejam usadas para localizar um UE. Conforme já mencionado, o GMLC/SLP 170 também pode compreender uma LRF com uma associação ou conexão a um GMLC e/ou um SLP. Um LRF 170 conectado ou associado a um GMLC pode suportar localização de plano de controle de modo similar a um GMLC em que uma LRF 170 conectado ou associado a um SLP pode suportar localização de plano de usuário de SUPL de modo similar a uma SLP.

[0068] A Aliança para Soluções da Indústria de Telecomunicações (ATIS) investiga modos de suportar chamadas da próxima geração 9-1-1 (NG911) que são estabelecidas por um UE por meio de um provedor de serviço OTT, por exemplo, Skype™. Um problema principal é a obtenção e o fornecimento de uma localização precisa e confiável de um autor de chamada de 911 para permitir o roteamento de uma chamada de NG911 pelo SP OTT para ou em direção ao PSAP correto e permitir o despacho pelo PSAP do suporte de segurança pública para a localização do usuário que faz a chamada. Devido ao fato de um SP OTT, como o SP OTT 150, frequentemente ter poucas ou nenhuma informação em relação à rede de acesso usada pelo UE que faz a chamada, pode ser difícil para que o SP OTT use métodos de posicionamento com base terrestre (como WiFi, ID de Célula Aprimorada (E-CID), e a diferença de tempo observada de chegada (OTDOA)) para localizar diretamente o UE que faz a chamada. Ademais, quando um UE que faz uma chamada estiver em ambiente interno, a localização do UE com o uso de um Sistema de Posicionamento por Satélite (SPS) como o Sistema de Posicionamento Global (GPS), algum outro Sistema de Satélite de Navegação Global (GNSS) ou por meio de GPS Assistido (A-GPS) ou GNSS assistido (A-GNSS) pelo SP OTT também pode ser não confiável devido a uma dificuldade inerente no uso de localização em ambiente interno de SPS e/ou devido à falta de um capacidade por um SP OTT de controlar e/ou auxiliar o uso da localização de SPS.

[0069] Uma solução que pode ser usada por um SP OTT 150 para obter a localização de um UE que instigou uma chamada de emergência por meio do SP OTT 150 envolve o SP OTT 150 que consulta um servidor de localização na rede de acesso (como o servidor de localização 170 na Figura 1A ou o GMLC/SLP 170 na Figura 1B) para obter a localização do UE que faz a chamada, se o SP OTT 150 puder ser dotado ou inferir o endereço desse servidor de localização. Em outra solução, o UE que instiga a chamada de emergência pode fornecer sua localização diretamente ao SP OTT 150 (por exemplo, em um CONVITE DE SIP usado para estabelecer a chamada de NG911). O UE que fornece sua localização diretamente a um SP OTT 150 pode ser uma solução atrativa devido ao fato de (a) os novos impactos aos padrões (por exemplo, padrões 3 GPP) podem ser restringidos, (b) os impactos de implantação às redes de RAN e CN de operador de rede móvel (MNO) podem ser baixos ou zero, (c) os UEs tipicamente suportam uma capacidade de localização independentemente de qualquer forma (por exemplo, uma solução auxiliada por um vendedor de sistema operacional de UE ou vendedor de chip de UE), e (d) a solução pode ser um bom encaixe com padrões de NG911 existentes que permitem o fornecimento de UE da localização de UE em um CONVITE DE SIP enviado para instigar uma chamada de emergência.

[0070] Uma localização fornecida por UE (por exemplo, incluída em um CONVITE DE SIP) pode ser por valor (por exemplo, o UE fornece suas coordenadas de latitude/longitude diretamente) ou por referência. Para a localização por referência, o UE fornece um Identificador de Recurso Uniforme (URI) (obtido originalmente pelo UE a partir de um servidor de localização e referido no presente documento como um "URI de localização") que contém o nome ou endereço de um servidor de localização, uma referência única ao UE que pode ser atribuída pelo servidor de localização, e uma indicação de um protocolo para usar para obter a localização de UE a partir do servidor de localização. Um "URI de localização" é referido de modo intercambiável no presente documento como uma "referência de localização" e como uma "localização por referência". Um URI de localização pode ser conforme definido pelo IETF na Solicitação de Comentários (RFCs) 3986 e 5808 e pode compreender uma cadeia de caracteres que se conforma a regras em RFC 3986 que codificam a identificação de um nome de esquema ou nome de protocolo como SIP ou HTTP e uma identificação de um recurso que pode compreender a identificação (por exemplo, nome ou endereço da trajetória de Internet) de um servidor de localização mais a identificação de um UE.

[0071] A identificação do UE, também referida no presente documento como uma "referência de UE", "referência de UE local" ou "referência local", pode compreender caracteres que identificam o UE ao servidor de localização mas ocultam a verdadeira identidade do UE de outras entidades e podem ser atribuídos localmente pelo servidor de localização. Um UE pode solicitar e obter um URI de localização a partir de um servidor de localização com o uso de um protocolo de configuração de localização como o protocolo de Entrega de Localização Habilitada por HTTP (HELD) definido em IETF RFC 5985. Um UE pode fornecer um URI de localização à outra entidade, como o SP OTT 150, o ESInet 160 ou o PSAP 180 na Figura 1A e na Figura 1B com o uso de um protocolo de fornecimento de localização, como SIP conforme definido em IETF RFC 6442. A entidade que recebe um URI de localização para um UE (por exemplo, o SP OTT 150, o ESInet 160 ou o PSAP 180 na Figura 1A e na Figura 1B) pode usar um protocolo de deferência de localização, como SIP, HTTP ou HELD, para solicitar e receber a localização do UE (por exemplo, coordenadas geográficas que podem compreender uma latitude e uma longitude (e, possivelmente, altitude) ou uma localização cívica que pode compreender um endereço postal ou endereço de rua (e, possivelmente, um número de andar, número de quarto, número de suíte etc.)) a partir do servidor de localização. Com deferência de localização, a entidade que solicita a localização fornece o URI de localização ao servidor de localização, que identifica o UE a partir do URI de localização, obtém uma localização para o UE, e devolve a localização para a entidade solicitante.

[0072] A localização por solução de referência pode ser mais atrativa que a localização por valor solução devido ao fato de permitir mais tempo para que um UE ou um servidor de localização obtenha uma localização para o UE e possa ser usado para obter mais de uma localização para o UE em diferentes momentos. Por exemplo, a localização por solução de referência pode ser usada por um SP OTT 150 para obter inicialmente uma localização de UE aproximada para auxiliar no roteamento e, em um momento posteriormente, obter uma localização mais precisa de UE para o despacho de PSAP.

[0073] Uma localização por solução de referência pode ter impactos significativos a um UE e a um servidor de localização, que pode precisar suportar (a) um protocolo de configuração de localização, como HELD, pelo qual um UE pode solicitar e um servidor de localização pode fornecer um URI de localização, e (b) um meio para o servidor de localização para autenticar a identidade do UE quando a consulta/resposta em (a) ocorrer. O impacto em (b) pode ser necessário devido ao fato do servidor de localização pode precisar identificar de modo confiável o UE no momento em que um URI de localização for atribuído a fim de localizar o UE correto (por exemplo, e não algum outro UE) em algum momento posterior quando um cliente (por exemplo, um SP OTT 150 ou PSAP 180) solicitar a localização do UE consultando-se o servidor de localização com o URI de localização. Alguns protocolos de configuração de localização como HELD podem não exigir ou suportar normalmente a autenticação em (b) devido ao fato de um endereço de IP do UE, para o qual um URI de localização é fornecido, pode estar disponível a um servidor de localização a partir do UE quando (a) ocorrer e puder ser considerado confiável o bastante para identificar e localizar o UE em um momento posterior quando o URI de localização for desreferenciado posteriormente por um SP OTT 150, o ESInet 160 ou o PSAP 180 (por exemplo, com o uso de HELD).

[0074] Entretanto, um endereço de IP pode ser falsificado. Por exemplo, uma entidade que não é um UE, mas tem capacidade para interceptar a comunicação de IP para e a partir de um UE, pode usar um protocolo de configuração de localização para obter um URI de localização para um UE enviando-se uma solicitação de localização a um servidor de localização que contém o endereço de IP para o UE. A entidade, então, pode ser (i) mascarada como um SP OTT para obter a localização para o UE enviando-se uma solicitação de desreferenciamento ao servidor de localização que contém o URI de localização obtido ou (ii) instigar uma chamada de emergência e fornecer o URI de localização a um SP OTT 150 para causar o despacho de segurança pública à localização do UE mesmo que o UE não faça a chamada de emergência .

[0075] Além disso, mesmo quando um endereço de IP para um UE estiver correto e quando uma entidade que solicita a localização de UE for legítima, um servidor de localização pode exigir uma identidade diferente para o UE a fim de obter a localização do UE e/ou para identificar de modo correto o UE em um momento posterior. Por exemplo, se o servidor de localização empregar uma solução de localização de plano de controle para obter a localização de um UE (por exemplo, a solução de localização de plano de controle de 3GPP para LTE), o servidor de localização pode precisar uma identidade associada sem fio para o UE, como um Número de Assinante Móvel Internacional (IMSI) ou um Número de Assinante Móvel Temporário (TMSI), ao invés do endereço de IP do UE. Além disso, se um UE que está localizado precisar ser identificado posteriormente para propósitos de taxação ou faturamento (por exemplo, para permitir que o SP para o servidor de localização taxe o SP OTT 150) ou para seguir posteriormente se uma localização obtida estava em erro ou para propósitos de estatística ou de contabilidade, então, ode ser necessário que alguma identidade global permanente para o UE pode não seja um endereço de IP. A fim de garantir que o servidor de localização tenha uma identidade correta para o UE e que um URI de localização seja fornecido para o UE correto ao invés de para um mascaramento de entidade como o UE, o impacto de autenticação em (b) acima pode ser necessário. Os impactos duplos de (a) e (b) podem fazer uma localização por solução de referência (por exemplo, conforme definido pelos RFCs de IETF mencionados acima no presente documento) complexa para vendedores de UE e MNOs ou seus vendedores de servidor de localização.

[0076] Uma solução para o problema descrito acima para fazer uso de uma localização por referência seria servir a rede de acesso, ao invés de um servidor de localização, para fornecer a um UE uma localização por referência depois do UE (e sua identidade) foi autenticada pela rede de acesso. A autenticação de um UE por uma rede de acesso é uma parte típica da operação de rede sem fio que é ou pode ser suportada por muitos tipos de redes sem fio (por exemplo, GSM, UMTS, LTE, IEEE 802.11), e, a partir disso, não pode adicionar novos impactos a um UE ou a uma rede de acesso. O fornecimento de uma localização por referência por uma rede de acesso a um UE pode ocorrer (i) imediatamente depois de um UE ter se anexado com sucesso à rede de acesso e sido autenticada, (ii) periodicamente, enquanto o UE for anexado à rede de acesso (por exemplo, para permitir que uma localização por referência anterior seja substituída com base em um servidor de localização diferente e/ou uma referência de UE local diferente), e/ou (iii) na solicitação pelo UE enquanto o UE estiver anexado à rede de acesso.

[0077] Em uma modalidade, uma rede de acesso pode se comunicar com um servidor de localização para obter uma localização por referência para um UE. Nessa modalidade, a rede de acesso pode atuar como um proxy e obter uma localização por referência a partir do servidor de localização no lugar do UE. O UE e o servidor de localização, então, podem não precisar de suporte ao protocolo de configuração de localização para permitir que o UE obtenha uma URI de localização a partir do servidor de localização. Em vez disso, o UE pode obter o URI de localização a partir da rede de acesso e a rede de acesso pode obter o URI de localização a partir do servidor de localização. Embora essa modalidade possa adicionar uma nova rede de acesso-interface de servidor de localização, a mesma pode evitar a necessidade de suportar um protocolo de configuração de localização e autenticação do UE pelo UE e o servidor de localização e pode ser, assim, uma solução mais simples que ter o UE consultando diretamente o servidor de localização com o uso de um protocolo de configuração de localização tradicional.

[0078] Em outra modalidade, uma rede de acesso pode atribuir uma localização por referência a um próprio UE sem o envolvimento de um servidor de localização. Por exemplo, a rede de acesso (por exemplo, a MME 142) pode criar um URI de localização que inclui o endereço conhecido ou a identidade conhecida (por exemplo, um nome de trajetória de Internet conhecido) de um servidor de localização alvo (por exemplo, o servidor de localização 170 na Figura 1A ou o GMLC/SLP 170 na Figura 1B), o esquema ou protocolo a ser usado para consultar o servidor de localização a partir de um cliente, e (como uma extensão ao endereço ou identidade do servidor de localização) uma referência de UE que identifica o UE. Em uma URI de localização normal, a referência de UE pode ser atribuída localmente pelo servidor de localização que cria um URI de localização. Com a modalidade descrita no presente contexto, uma referência de UE pode ser atribuída pela rede de acesso e pode compreender uma identificação de UE global, como o endereço de IP do UE, o IMSI para o UE e/ou uma identidade para o UE conhecido à rede de acesso, como um TMSI, um endereço local para o UE atribuído por um nó de rede de acesso (por exemplo, um MME ou SGSN) e/ou um endereço de um nó de rede de acesso, ou qualquer combinação dos mesmos. A referência de UE pode incluir adicionalmente uma data e/ou momento de atribuição e/ou pode ser cifrada para proteger a privacidade do usuário (por exemplo, em que as chaves de cifra são conhecidas à rede de acesso e ao servidor de localização, mas não às outras partes). No caso da referência de UE compreender um TMSI ou endereço de IP, o ciframento pode não ser necessário devido ao fato da verdadeira identidade do UE (por exemplo, o IMSI do UE) não está incluído na referência de UE e, assim, pode não estar disponível às outras partes. O URI de localização também pode ser assinado de modo digital pela rede de acesso (por exemplo, pode incluir uma assinatura digital) para que um servidor de localização seja consultado com o URI de localização possa saber que o URI de localização foi atribuído pela rede de acesso. Em alguns casos, o URI de localização pode ser cifrado e assinado de modo digital, por exemplo, com o uso do Contador do Instituto Nacional dos Estados Unidos de Padrões e Tecnologia (NIST) com método de Código de Autenticação de Mensagem Encadeado por Bloco de Cifrar (CCM).

[0079] O uso das modalidades acima pode afetar apenas a rede de acesso e o servidor de localização. A partir disso, um MNO pode migrar da segunda modalidade, na qual uma rede de acesso atribui um URI de localização sem o envolvimento de um servidor de localização, à primeira modalidade, na qual uma rede de acesso atua como um proxy para um servidor de localização sem afetar outras entidades (por exemplo, incluindo os UEs). Em alguns casos, a migração de MNO pode ser da primeira modalidade para a segunda modalidade. No caso de a rede de acesso suportar LTE e pertencer a um MNO celular, a localização por referência para um UE pode ser atribuída pelo MME de serviço para o UE, como a MME 142 na Figura 1B. A atribuição pode ocorrer como parte de anexação de rede de LTE pelo UE e/ou como parte de uma atualização da área de rastreamento pelo UE. Tal atribuição pode adicionar um novo parâmetro que contém um URI de localização atribuído a poucas mensagens de Estrato de Não Acesso (NAS) usadas para o suporte de LTE e pode ter um pequeno impacto para o UE e a rede de acesso (por exemplo, a MME). O benefício dessa solução a MNOs e vendedores de UE pode ser que o impacto do suporte à solução pode ser limitado e uma solução de localização flexível pode ser oferecida a SPs OTT que se encaixam a padrões existentes.

[0080] Com referência novamente à Figura 1A e à Figura 1B, a Figura 2A ilustra interações específicas das entidades de rede ilustradas na Figura 1A, e a Figura 1B no caso de acesso de LTE, para fornecer uma localização por referência para uma chamada de emergência OTT de acordo com as modalidades descritas no presente documento. Com referência à Figura 2A, o termo "rede de acesso" se refere à RAN 120 e à CN 140. O nó de rede de acesso 240 pode ser alguma entidade na rede de acesso, como um nó de acesso, um ponto de acesso, uma estação-base, um eNodeB (por exemplo, o eNB 122, 124 ou 126), uma femtocélula, um MME (por exemplo, a MME 142), etc. O nó de rede de acesso pode estar dentro da RAN 120 ou dentro da CN 140.

[0081] Em 202A, um UE 200 (por exemplo, que pode corresponder a qualquer um dos UEs 1 a N na Figura 1A) se anexa à rede de acesso por meio do nó de rede de acesso 240. Em 204A, o usuário do UE 200 faz uma chamada de emergência por meio de um aplicativo OTT, por exemplo, Skype, instalado no UE 200. Em 206A, o UE 200 envia uma solicitação para uma referência de localização ao nó de rede de acesso 240. Em algumas modalidades, o bloco 206A pode ser instigado pelo aplicativo OTT, que pode reconhecer a solicitação de chamada de emergência no bloco 204A e pode solicitar o UE 200 (por exemplo, com o uso de uma Interface de Programação de Aplicativo (API) a um modem no UE 200) para obter uma referência de localização.

[0082] Em 208A, o nó de rede de acesso 240 pode enviar, opcionalmente, uma solicitação de referência de localização ao servidor de localização 170 (por exemplo, o GMLC/SLP 170 ou o E-SMLC 172) para uma referência de localização para o UE 200 e receber de volta uma resposta do servidor de localização 170 em 212A que contém uma referência de localização. Nesse caso, o nó de rede de acesso 240 atua como um proxy para obter a referência de localização do servidor de localização 170 no lugar do UE 200 no bloco 208A. A solicitação/resposta no bloco 208A pode usar uma conexão segura entre o servidor de localização 170 e o nó de rede de acesso 240 que permite que o servidor de localização 170 seja sensível a um nó de rede de acesso, cujo operador pode ser o mesmo que para o servidor de localização 170, solicitar a referência de localização. A conexão segura entre o servidor de localização 170 e o nó de rede de acesso 240 pode fazer uso de uma relação confiável entre o servidor de localização 170 e o nó de rede de acesso 240, por exemplo, uma relação com base no nó de rede de acesso 240 e o servidor de localização 170 que pertence ao mesmo SP e ao mesmo operador de rede - e pode empregar credenciais de segurança pré-configuradas em cada entidade para permitir o estabelecimento da conexão segura. O servidor de localização 170, então, pode atribuir e devolver uma referência de localização no bloco 208A (por exemplo, que pode incluir uma referência de UE que é local ao servidor de localização 170) que pode ser usada posteriormente (por exemplo, pelo SP OTT 150) para obter uma localização para o UE 200 a partir do servidor de localização 170 conforme descrito posteriormente.

[0083] Embora o bloco 208A adicione uma nova interface entre o nó de rede de acesso 240 e o servidor de localização 170, o mesmo impede a necessidade do servidor de localização 170 interagir e autenticar o UE 200. Em algumas modalidades, o nó de rede de acesso 240 e o servidor de localização 170 podem usar um dentre SIP, HELD ou o Protocolo de Localização Móvel (MLP) definido pela Aliança Móvel Aberta (OMA) para solicitar e devolver a referência de localização em 208A. Em 212A, o nó de rede de acesso 240 envia a referência de localização obtida do servidor de localização 170 para o UE 200. Em algumas modalidades, o UE 200 (por exemplo, um modem no UE 200) pode fornecer a referência de localização ao aplicativo OTT.

[0084] Em algumas modalidades, ao invés de consultar o servidor de localização 170 para a referência de localização do UE 200, o nó de rede de acesso 240 pode atribuir a própria referência de localização sem o envolvimento do servidor de localização 170 conforme descrito anteriormente no presente documento. O nó de rede de acesso 240 pode cifrar a porção da referência de UE da referência de localização e/ou assinar de modo digital a referência de localização conforme descrito também no presente documento. Nesse caso, qualquer chave e/ou chaves de cifrador/decifrador para uma assinatura digital pode ser conhecida ao nó de rede de acesso 240 e ao servidor de localização 170, mas não a outras partes.

[0085] As mensagens em 206A, 208A e 212A são ilustradas como opcionais (indicadas pelas linhas tracejadas) na Figura 2A devido ao fato das mesmas não precisarem ocorrer nos momentos específicos ilustrados na Figura 2A. Ao invés disso, como um exemplo, 206A e 212A (e, opcionalmente, 208A) podem ser realizados durante a anexação em 202A e, possivelmente, antes do usuário fazer uma chamada de emergência em 204A, como imediatamente depois do UE 200 ter se anexado de modo bem sucedido ao nó de rede de acesso 240 e ter sido autenticado, ou como parte de uma troca de mensagem de anexação e/ou autenticação entre o UE 200 e o nó de rede de acesso 240. Por exemplo, o UE 200 pode incluir uma solicitação para uma referência de localização em uma mensagem enviada para o nó de rede de acesso 240 para a solicitação, responder ou confirmar a anexação de UE 200 ou autenticação de UE 200. De modo similar, o nó de rede de acesso 240 pode incluir uma referência de localização atribuída em uma mensagem enviada para o UE 200 para solicitar, responder ou confirmar a anexação do UE 200 ou a autenticação do UE 200.

[0086] Como outro exemplo, 206A e 212A (e, opcionalmente, 208A) podem ser realizados periodicamente enquanto o UE 200 estiver anexado ao nó de rede de acesso 240, e não em resposta ao usuário realizar uma chamada de emergência. Por exemplo, 206A, 212A e, possivelmente, 208A podem ser realizados sempre que o UE 200 e o nó de rede de acesso 240 precisarem interagir para suportar a mobilidade para o UE 200. Em outro exemplo, 206A, 212A e, possivelmente, 208A, podem ser realizados sempre que o UE 200 mudar para um novo nó de rede de acesso (por exemplo, muda de um nó de rede de acesso anterior para o nó de rede de acesso 240 ou do nó de rede de acesso 240 para um novo nó de rede de acesso). Conforme ainda em outro exemplo, 206A e 212A podem corresponder a alguma outra interação existente entre o UE 200 e o nó de rede de acesso 240, como uma atualização de área de rastreamento para o LTE ou uma atualização de área de roteamento para GPRS e/ou UMTS. Alternativamente, conforme ilustrado na Figura 2A, 206A e 212A podem compreender novas mensagens usadas apenas para obter a referência de localização.

[0087] Em algumas modalidades, antes de enviar a referência de localização para o UE 200 em 212A, o nó de rede de acesso 240 pode autenticar a identidade do UE 200 (não mostrado na Figura 2A). Tal autenticação pode garantir que a referência de localização seja devolvida em 212A para o UE correto 200. Adicionalmente, tal autenticação de UE 200 pode fazer uma parte normal do suporte de acesso pelo UE 200 a serviços fornecidos pelo nó de rede de acesso 240 (por exemplo, como o suporte de anexação e mobilidade de rede para o UE 200) qualquer um pode não adicionar impactos adicionais ao UE 200 ou ao nó de rede de acesso 240 apenas para o propósito de devolver uma referência de localização em 212A.

[0088] Em 214A, o UE 200 envia uma solicitação de chamada de emergência, que inclui a referência de localização do UE 200, para o SP OTT 150. Em algumas modalidades, a solicitação de chamada de emergência pode ser transferida pelo UE 200 para o SP OTT 150 por meio do nó de rede de acesso 240 e/ou por meio da rede de acesso para o nó de rede de acesso 240. Embora não ilustrado na Figura 2A, o UE 200 pode obter a referência de localização a partir de um nó de rede de acesso 240 para uma primeira rede de acesso que pertence a um primeiro operador de rede (que também pode ser dono do servidor de localização 170) e/ou que se conforma a uma primeira tecnologia de acesso por rádio (RAT), e enviar a solicitação de chamada de emergência que contém a referência de localização ao SP OTT 150 por meio de uma segunda rede de acesso que pertence a um segundo operador de rede e/ou se conforma a uma segunda RAT. Desse modo, a referência de localização pode ser compartilhada entre e/ou pode ser válida para múltiplas redes de acesso, múltiplas RATs e/ou múltiplos operadores de rede e podem permitir que o UE 200 use a mesma referência de localização depois da transferência para uma nova RAT ou para uma nova rede e/ou quando acessar diversas redes ou diversas RATs ao mesmo tempo. Por exemplo, o UE 200 pode obter a referência de localização a partir de uma estação-base ou outo nó de serviço (por exemplo, um MME) que pertence a uma rede de acesso celular que pertence a um operador de rede A, e enviar a solicitação de chamada de emergência, que inclui a referência de localização, a um ponto de acesso de WiFi em uma rede de acesso de WLAN que pertence a um operador de rede B (em que o operador A pode ou não ser o mesmo que o operador B), que pode encaminhar a solicitação de chamada de emergência para o SP OTT 150.

[0089] Em 216A, o SP OTT 150 envia uma solicitação de localização (ou uma solicitação de deferência de localização), que inclui a referência de localização recebida do nó de rede de acesso 240 em 214A, para o servidor de localização 170. O SP OTT 150 pode identificar o servidor de localização 170 (por exemplo, identificar um endereço ou um nome de trajetória para o servidor de localização 170) a partir do conteúdo da referência de localização recebida em 214A. O servidor de localização 170 pode verificar que a referência de localização recebida em 216A é válida verificando-se que a referência de localização corresponde a uma referência de localização atribuída anteriormente pelo servidor de localização 170 (por exemplo, atribuída como parte do bloco 208A, se o bloco 208A ocorrer). Por exemplo, o servidor de localização 170 pode verificar que a referência de UE na referência de localização foi atribuída anteriormente pelo servidor de localização 170 para identificar o UE 200. Alternativamente, se a referência de localização recebida em 216A foi atribuída pelo nó de rede de acesso 240 e não pelo servidor de localização 170 (por exemplo, como ocorre se o bloco 208A não estiver presente), o servidor de localização 170 pode verificar que o nó de rede de acesso 240 atribuiu a referência de localização verificando-se qualquer assinatura digital, caso presente na referência de localização e/ou decifrando-se a porção da referência de UE da referência de localização e verificando-se que a porção da referência de UE se conforma corretamente a quaisquer regras de formatação ou codificação para uma referência de UE válida.

[0090] Em 218A, o servidor de localização 170 (ou um GMLC associado ou conectado ao servidor de localização 170 no caso do servidor de localização 170 ser uma LRF) pode enviar uma solicitação de localização ao nó de rede de acesso 240 para a localização do UE 200 e pode incluir uma identificação para o UE 200 na solicitação de localização que pode ser (i) uma identificação para o UE 200 recebida anteriormente em 208A, se 208A ocorrer, e o servidor de localização 170 tiver atribuído a referência de localização recebida em 216A ou (ii) parte ou toda uma referência de UE ou UE decifrada referida recebida como parte de uma referência de localização em 216A se o nó de rede de acesso 240 ao invés do servidor de localização 170 tiver atribuído a referência de localização. O nó de rede de acesso 240, então, pode obter uma estimativa de localização para o UE 200 (conforme identificado pelo servidor de localização 170 em 218A) a partir de outra entidade (não mostrada na Figura 2A). Por exemplo, o nó de rede de acesso 240 pode solicitar uma estimativa de localização a partir de outro servidor de localização (por exemplo, o E-SMLC 172) ou outra entidade com capacidade de localização (por exemplo, a RAN 120) ou a partir de uma estação-base ou um AP que serve o UE 200. Alternativamente, o nó de rede de acesso 240 já pode ter a informações de localização para o próprio UE 200 (por exemplo, se o nó de rede de acesso 240 é uma estação-base ou AP de WiFi que serve o UE 200). O nó de rede de acesso 240, então, pode devolver a estimativa de localização para o UE 200 ao servidor de localização 170 (ou para um GMLC associado ou conectado ao servidor de localização 170 no caso do servidor de localização 170 ser uma LRF) como parte de 218A. Em algumas modalidades, o bloco 218A pode ocorrer quando o servidor de localização 170 empregar uma solução de localização de plano de controle para obter a localização do UE 200.

[0091] Em vez de, ou além de, consultar o nó de rede de acesso 240 para a localização do UE 200 em 218A, o servidor de localização 170 pode consultar o UE 200 diretamente em 222A. Por exemplo, 222A pode ocorrer se o servidor de localização 170 for uma SLP de SUPL, ou um LRP conectado ou associado a uma SLPP, em que a SLP instiga uma localização de plano de usuário de sessão de SUPL em 222A com o UE 200 a fim de obter as medições relacionadas à localização a partir do UE 200 (por exemplo, medições de GPS ou satélites de GNSS e/ou medições de estações-base e/ou APs na rede de acesso para p UE 200) que o servidor de localização 170 pode se acostumar a determinar uma localização para o UE 200. Por exemplo, o UE 200 pode fornecer GPS e medições da Diferença de Tempo Observada da Chegada (OTDOA) para o servidor de localização 170. A OTDOA é um método de multilateração no qual o UE 200 mede a diferença de tempo entre sinais específicos a partir de pares de estações-base e relata as diferenças de tempo medidas ao servidor de localização 170, que, então, computa a localização do UE 200. Alternativamente, o servidor de localização 170 (ou uma SLP associado ou conectado ao servidor de localização 170 no caso do servidor de localização 170 é uma LRF) pode instigar uma sessão de SUPL com o UE 200 em 222A para obter uma localização de UE 200 a partir do UE 200 em que o UE 200 obtém a localização a partir das medições relacionadas à localização como medições de GPS, GNSS e/ou OTDOA. Em 224A, o servidor de localização 170 envia a localização do UE 200, conforme obtido em 218A e/ou em 222A, ao SP OTT 150. Em algumas modalidades, o SP OTT 150 e o servidor de localização 170 podem empregar um dentre SIP, HELD ou MLP em 216A e 224A para solicitar e devolver a localização do UE 200. Em algumas dessas modalidades em que o SIP ou o HELD é usado, o uso do SIP ou do HELD pode ser definido como parte da referência de localização.

[0092] Os fluxos de mensagens em 216A a 224A podem ocorrer nos momentos ilustrados na Figura 2A para permitir que o SP OTT 150 obtenha a localização do UE 200 para auxiliar o roteamento da chamada de emergência (por exemplo, determinando-se um PSAP 180 com uma cobertura de serviços de emergência que inclui a localização do UE 200) e/ou para fornecer a localização de UE 200 ao ESInet 160 ou ao PSAP 180. Os fluxos de mensagens em 216A a 224A são opcionais devido ao fato dos mesmos poderem, alternativa ou adicionalmente, ocorrer depois da chamada de emergência iniciada em 204A ser definida (isto é, depois de 228A) se o SP OTT 150 recebe a solicitação de localização para o UE 200 a partir do PSAP 180 e precisa consultar o servidor de localização 170 para obter e devolver a localização atual do UE 200 (não mostrado na Figura 2A). Além disso, fluxos de mensagens análogos a 216A a 224A podem ocorrer (em vez ou além dos fluxos de mensagens em 216A a 224A) para permitir que o ESInet 160 ou o PSAP 180 solicite diretamente a localização do UE 200 a partir do servidor de localização 170. Esses fluxos de mensagens análogos podem ser idênticos ou quase idênticos a 216A a 224A, exceto que o ESInet 160 ou o PSAP 180 podem substituir o SP OTT 150 nos fluxos de mensagens em termos de envio da solicitação de localização em 216A e que recebe a resposta de localização em 224A.

[0093] Voltando-se para a chamada de serviço de emergência mostrada na Figura 2A, em 226A, o SP OTT 150 roteia a chamada de emergência para o ESInet apropriado 160, ou possivelmente a um SR 160 se o SP OTT converter a chamada em uma chamada de emergência CS. O ESInet 160 (ou um SR 160) roteia a chamada de emergência ao PSAP apropriado 180. As solicitações de chamada de emergência enviadas em 226A podem incluir a referência de localização do UE 200 obtida em 214A. O SP OTT 150 pode usar a localização do UE 200 obtido em 224A, caso realizado, para rotear a chamada de emergência iniciada em 204A ao ESInet apropriado 160 (ou para o SR 160). O ESInet 160 pode usar a referência de localização do UE 200 recebida na solicitação de chamada de emergência para obter uma localização para o UE 200 a partir do servidor de localização 170 realizando- se as etapas análogas a 216A a 224A conforme já descrito. O ESInet 160, então, pode usar essa localização obtida para rotear a chamada de emergência ao PSAP apropriado 180.

[0094] Em 228A, as diversas entidades de rede (por exemplo, o UE 200, o SP OTT 150, o ESInet 160 e o PSAP 180) realizam o restante do estabelecimento de chamada de emergência. Em 232A, o PSAP 180 envia uma solicitação de localização, que inclui a referência de localização recebida em 226A, ao servidor de localização 170. O servidor de localização 170 usa a referência de localização para consultar a localização do UE 200 (por exemplo, consultar a localização obtida anteriormente em 218A e/ou 222A) e responde com a localização do UE 200. Alternativamente, o servidor de localização 170 pode obter a localização do UE 200 realizando-se etapas (não mostradas na Figura 2A), que são as mesmas que aquelas ilustradas em 218A e/ou 222A.

[0095] Com referência novamente à Figura 1B, a Figura 2B ilustra interações específicas das entidades ilustradas na Figura 1B para fornecer uma localização por referência para uma chamada de emergência OTT de acordo com as modalidades descritas no presente documento. As interações na Figura 2B são similares àquelas descritas para a Figura 2A, mas se referem especificamente a um UE 200 com acesso de LTE. Em contraste, as interações descritas em associação com a Figura 2A podem se aplicar a um UE 200 com qualquer tipo de acesso sem fio ou em linha de fio que inclui, mas não se limita a, o acesso de LTE.

[0096] Em 202B, o UE 200 se anexa a uma rede de serviço com capacidade para LTE e, como parte do procedimento de anexação, envia uma Solicitação de Anexação de NAS à MME de serviço 142. A Solicitação de Anexação de NAS inclui uma solicitação para uma referência de localização em algumas modalidades. Em 204B, a MME 142 pode enviar, opcionalmente, uma solicitação de referência de localização ao GMLC/SLP 170. O GMLC/SLP 170 pode ser um GMLC caso a localização do UE 200 seja obtida com o uso de uma solução de localização de plano de controle, pode ser uma SLP se a localização do UE 200 for obtida com o uso de SUPL, pode ser um GMLC e uma SLP combinados se um ou ambos dentre a localização de plano de controle e SUPL forem usados para obter uma localização para o UE 200, ou pode ser uma LRF com uma conexão ou associação a um GMLC e/ou SLP. Quando o 204B for realizado, a MME 142 atua como um proxy para obter a referência de localização a partir do GMLC/SLP 170 no lugar do UE 200. Embora isso adicione uma nova interface entre a MME 142 e o GMLC/SLP 170, isso impede a necessidade de o UE 200 obter a referência de localização a partir do GMLC/SLP 170 e evitar a necessidade de o GMLC/SLP 170 autenticar o UE 200 como parte de uma solicitação a partir do UE 200 para obter uma referência de localização.

[0097] A solicitação/resposta na etapa 204B pode usar uma conexão segura entre o GMLC/SLP 170 e a MME 142 que permite que o GMLC/SLP 170 seja sensível a um MME (por exemplo, que pertence ao mesmo operador ou SP como para o GMLC/SLP 170) que solicita a referência de localização. A conexão segura entre GMLC/SLP 170 e a MME 142 pode fazer uso de uma relação confiável entre o GMLC/SLP 170 e a MME 142, por exemplo, uma relação com base no MME 142 e no GMLC/SLP 170 que pertence ao mesmo SP ou ao mesmo operador de rede, e pode empregar credenciais de segurança pré-configuradas em cada entidade para permitir o estabelecimento da conexão segura. O GMLC/SLP 170, então, pode atribuir e devolver uma referência de localização (por exemplo, que pode incluir uma referência de UE que é local ao GMLC/SLP 170) que permitirá posteriormente que o GMLC/SLP 170 forneça uma localização para o UE 200 a outra entidade, por exemplo, em blocos 214B e 232B descritos abaixo. Em algumas modalidades, a MME 142 e o GMLC/SLP 170 pode usar um dentre SIP, HELD ou o Protocolo de Localização Móvel (MLP) definido por OMA para solicitar e devolver a referência de localização em 204B.

[0098] Em 206B, a MME 142 envia a referência de localização obtida do GMLC/SLP 170 para o UE 200 em uma mensagem da Aceitação de Anexação de NAS. A Solicitação de Anexação de NAS em 202B e a Aceitação de Anexação de NAS em 206B podem se dar conforme definido em 3 GPP TS 23.401 e TS 24.301, com a adição de um parâmetro de solicitação de referência de localização em uma Solicitação de Anexação de NAS e/ou um parâmetro de referência de localização em uma Aceitação de Anexação de NAS. Em algumas modalidades, os blocos 204B e 206B só podem ser realizados quando a Solicitação de Anexação de NAS em 202B contiver uma solicitação para uma referência de localização. Em outras modalidades, os blocos 204B e 206B podem ser realizados quando a Solicitação de Anexação de NAS em 202B não contiver uma solicitação para uma referência de localização.

[0099] Alternativamente, ao invés de consultar o GMLC/SLP 170 para a referência de localização do UE 200 em 204B, a MME 142 pode atribuir a própria referência de localização sem o envolvimento do GMLC/SLP 170 conforme descrito acima. O MME 142 pode incluir o endereço conhecido do GMLC/SLP 170 na referência de localização, uma identificação para o protocolo a ser usado para consultar o GMLC/SLP 170 a partir de um cliente, e uma referência de UE para identificar o UE 200 (por exemplo, o endereço de IP do UE 200, o IMSI do UE 200, o TMSI do UE 200, um endereço local para o UE 200 atribuído pelo MME 142, um endereço da MME 142, ou qualquer combinação dos mesmos). O MME 142 pode cifrar a referência de UE para proteger a privacidade do usuário. Nesse caso, as chaves de cifra serão conhecidas à MME 142 e ao GMLC/SLP 170, mas não às outras partes. O MME 142 também pode assinar de modo digital a referência de localização para que o GMLC/SLP 170 saiba que a referência de localização foi atribuída pelo MME 142, ou pelo menos foi atribuída por alguma entidade gerenciada pelo operador ou SP para o GMLC/SLP 170.

[0100] Além disso ou em vez de obter a referência de localização em 206B, o UE 200 pode obter a referência de localização depois do usuário do UE 200 iniciar uma chamada de emergência (208B), de modo periódico, enquanto o UE 200 for anexado à MME 142 e/ou durante alguma outra interação entre o UE 200 e a MME 142, conforme discutido acima com referência à Figura 2A.

[0101] Em vez de enviar a Solicitação de Anexação de NAS em 202B e a Aceitação de Anexação de NAS em 206B para obter uma referência de localização, o UE 200 pode enviar uma Solicitação de Atualização de Área de Rastreamento de NAS em 202B e, depois de obter ou atribuir uma referência de localização (por exemplo, em 204B), a MME 142 pode enviar uma Aceitação de Atualização de Área de Rastreamento de NAS em 206B que contém a referência de localização. A Solicitação de Atualização de Área de Rastreamento de NAS em 202B e a Aceitação de Atualização de Área de Rastreamento de NAS em 206B pode ser conforme definido em 3 GPP TS 23.401 e TS 24.301, com a adição de uma solicitação de referência de localização em uma Solicitação de Atualização de Área de Rastreamento de NAS e/ou uma referência de localização em uma Aceitação de Atualização de Área de Rastreamento de NAS.

[0102] Em algumas modalidades, antes de enviar a referência de localização ao UE 200 em uma Aceitação de Anexação de NAS ou Aceitação de Atualização de Área de Rastreamento de NAS em 206B, a MME 142 pode autenticar a identidade do UE 200 (não mostrada na Figura 2B). Tal autenticação pode garantir que a referência de localização seja devolvida em 206B para o UE correto 200. Adicionalmente, tal autenticação do UE 200 pode formar uma parte normal do suporte de uma anexação de UE 200 ou da atualização de área de rastreamento pelo UE 200 e pelo MME 142, qualquer um pode não adicionar impactos adicionais ao UE 200 ou à MME 142 apenas para o propósito de devolver uma referência de localização em 206B.

[0103] Para redes de acesso que suportam GSM ou UMTS em vez de LTE, o procedimento na Figura 2B pode ser usado para suportar uma chamada de emergência OTT conforme descrito no presente documento para uma rede de LTE, mas com E-SMLC 172 substituído por um GSM ou RAN de UMTS, e a MME 142 substituída por um Nó de Suporte de GPRS de Serviço (SGSN). Nesse caso, o UE 200 pode enviar tanto uma Solicitação de Anexação de GPRS quanto uma Solicitação de Atualização de Área de Roteamento de GPRS para o SGSN em 202B que pode conter uma solicitação para uma referência de localização, e o SGSN pode responder com uma Aceitação de Anexação de GPRS ou uma Aceitação de Atualização de Área de Roteamento de GPRS, respectivamente, em 206B. Nesse caso, a Solicitação de Anexação de GPRS ou a Solicitação de Atualização de Área de Roteamento de GPRS em 202B e a Aceitação de Anexação de GPRS ou a Aceitação de Atualização de Área de Roteamento de GPRS em 206B podem se dar conforme definido em 3GPP TS 24.008, com a adição de uma solicitação de referência de localização em uma Solicitação de Anexação de GPRS ou Solicitação de Atualização de Área de Roteamento de GPRS e/ou uma referência de localização em uma Aceitação de Anexação de GPRS ou Solicitação de Atualização de Área de Roteamento de GPRS.

[0104] Em 208B, o usuário do UE 200 faz uma chamada de emergência por meio de um aplicativo OTT, como SkypeTM, instalado no UE 200. Em 212B, o UE 200 envia uma solicitação de chamada de emergência, que inclui a referência de localização obtida em 206B, para o SP OTT 150. Por exemplo, o UE 200 pode enviar a solicitação de chamada de emergência para o SP OTT 150 por meio de eNB 124, S-GW 146, PDG 148 e Internet 175. Em uma modalidade, o UE 200 pode obter a referência de localização a partir da MME 142 conforme descrito acima e enviar a solicitação de chamada de emergência que contém a referência de localização ao SP OTT 150 em 212B por meio de uma rede de acesso diferente da rede de acesso que contém a MME 142 e que está associada ao GMLC/SLP 170. Por exemplo, a rede de acesso diferente pode suportar uma RAT diferente para LTE (por exemplo, WiFi). Desse modo, a referência de localização pode ser compartilhada entre diferentes redes de acesso e possivelmente entre diferentes RATs no UE 200. Por exemplo, o UE 200 pode enviar a solicitação de chamada de emergência, que inclui a referência de localização, ao SP OTT 150 por meio de um ponto de acesso de WLAN.

[0105] Em 214B, o SP OTT 150 envia uma solicitação de localização, que inclui a referência de localização obtida em 212B, ao GMLC/SLP 170. O SP OTT 150 pode identificar o GMLC/SLP 170 (por exemplo, identificar um endereço ou um nome de trajetória para o GMLC/SLP 170) a partir do conteúdo da referência de localização recebida em 212B. O GMLC/SLP 170 pode verificar que a referência de localização recebida em 214B é válida verificando-se que a referência de localização corresponde a uma referência de localização atribuída anteriormente pelo GMLC/SLP 170 (por exemplo, atribuída como parte do bloco 204B, se o bloco 204B ocorrer). Por exemplo, o GMLC/SLP 170 pode verificar que a referência de UE na referência de localização foi atribuída anteriormente pelo GMLC/SLP 170 para identificar o UE 200. Alternativamente, se a referência de localização recebida em 214B foi atribuída pelo MME 142 e não pelo GMLC/SLP 170 (por exemplo, como ocorre se o bloco 204B não estiver presente), o GMLC/SLP 170 pode verificar a MME 142 atribuído à referência de localização (i) verificando-se qualquer assinatura digital, caso presente na referência de localização, (ii) decifrando-se a porção de referência de UE da referência de localização e verificando-se que a porção de referência de UE decifrada se conforme corretamente a quaisquer regras de formatação e codificação para uma referência de UE válida e/ou (iii) verificando-se que a referência de localização se conforme a regras de formatação conhecidas (por exemplo, contém uma referência de UE cujo comprimento e/ou conteúdo de caractere se conformam a regras conhecidas).

[0106] Se a solução de localização de plano de controle estiver em utilização (o que significa que o GMLC/SLP 170 é ou contém um GMLC ou é uma LRF conectado ou associado a um GMLC), então, os fluxos de mensagens em 216B a 226B são realizados (conforme indicado pela caixa tracejada). Especificamente, em 216B, o GMLC 170 envia uma solicitação de localização para o UE 200 à MME 142. O GMLC 170 pode determinar o endereço ou identidade de MME 142 a fim de enviar corretamente a solicitação em 216B a partir o conteúdo da referência de UE na referência de localização recebida em 214B (por exemplo, se a MME 142 ou GMLC 170 incluiu o endereço ou identidade de MME 142 na referência de localização). Alternativamente, o GMLC 170 pode consultar um Servidor de Assinante Domiciliar (HSS) para o UE 200 a respeito do endereço da MME 142 (não mostrado na Figura 2B) com o uso de um identificador (por exemplo, o IMSI) para o UE 200 recebido em 214B na porção de referência de UE da referência de localização. O GMLC inclui uma identidade para o UE 200 na solicitação de localização enviada em 216B que estava incluída na porção de referência de UE da referência de localização recebida em 214B ou foi recebida anteriormente em 204B e armazenada pelo GMLC 170 no caso do GMLC 170 atribuir a referência de localização.

[0107] Em 218B, a MME 142 envia uma solicitação de localização para o UE 200 para o E-SMLC 172 e pode incluir qualquer identidade para o UE 200 recebido em 216B ou já conhecido à MME 142. Em 222B, o E-SMLC 172 pode instigar uma sessão de localização do Protocolo de Posicionamento de LTE (LPP) de 3 GPP com o UE 200 e, como parte dessa sessão, pode enviar uma solicitação de localização ao UE 200, que responde às informações de localização. As informações de localização fornecidas pelo UE 200 podem compreender medições de localização de GPS, medições de localização de GNSS, medições de OTDOA, medições de ID de Célula Aprimorada (ECID), medições de localização de WiFi, medições de localização de Bluetooth (BT) ou qualquer combinação desses, ou pode conter uma estimativa de localização para o UE 200 obtido pelo UE 200. Quando as informações de localização compreenderem medições de localização, mas não uma estimativa de localização, o E- SMLC 172 pode computar uma estimativa de localização para o UE 200 a partir dessas medições. Em vez de, ou além de, 222B, o E-SMLC 172 pode enviar uma solicitação de localização (não mostrada na Figura 2B) a um eNB de serviço para o UE 200 (por exemplo, o eNB 124 na Figura 2B) a fim de obter uma estimativa de localização ou medições a partir das quais o E-SMLC 172 pode determinar uma estimativa de localização para o UE 200. Em 224B, o E-SMLC 172 pode enviar uma resposta de localização, que inclui a localização do UE 200, à MME 142. Em 226B, a MME 142 envia uma resposta de localização, que inclui a localização do UE 200 recebido em 224B, ao GMLC 170.

[0108] Alternativamente, se a solução de SUPL de localização de plano de usuário estiver em utilização (o que significa que o GMLC/SLP 170 é ou contém um SLP ou é uma LRF associado ou conectado a um SLP), então, os fluxos de mensagens em 216B a 226B podem não ser realizados, e, em vez disso (ou, possivelmente, além disso), uma sessão de SUPL é estabelecida entre a SLP 170 e o UE 200 em 228B. O SLP 170 pode obter a localização do UE 200 por meio da sessão de SUPL (por exemplo, a partir de medições de GPS, GNSS, OTDOA, ECID, WiFi e/ou BT obtidas pelo UE 200). Os fluxos de mensagens em 216B a 228B são ilustrados com linhas tracejadas devido ao fato de, em algumas modalidades, um dos fluxos de mensagens em 216B a 226B são realizados ou o fluxo de mensagens em 228B é realizado, mas não ambos. Em 232B, o GMLC/SLP 170 envia a estimativa de localização do UE 200 ao SP OTT 150.

[0109] Os fluxos de mensagens em 214B a 232B (por exemplo, (a) 214B a 226B e 232B ou (b) 214B, 228B e 232B) podem ocorrer nos momentos ilustrados na Figura 2B para permitir que o SP OTT 150 obtenha a localização do UE 200 para auxiliar no roteamento da chamada de emergência (por exemplo, determinando-se um PSAP 180 com uma cobertura de serviços de emergência que inclui a localização do UE 200) e/ou para fornecer a localização de UE 200 ao ESInet 160 ou ao PSAP 180. Os fluxos de mensagens em 214B a 232B poderem, alternativa ou adicionalmente, ocorrer depois da chamada de emergência iniciada em 208B ser definida (isto é, depois de 236B) se o SP OTT 150 recebe a solicitação de localização para o UE 200 a partir do PSAP 180 e precisa consultar o GMLC/SLP 170 para obter e devolver a localização atual do UE 200 (não mostrado na Figura 2B). Além disso, fluxos de mensagens análogos a 214B a 232B podem ocorrer (em vez ou além dos fluxos de mensagens em 214B a 232B) para permitir que o ESInet 160 ou o PSAP 180 solicite diretamente a localização do UE 200 a partir do GMLC/SLP 170. Esses fluxos de mensagens análogos podem ser idênticos ou quase idênticos a 214B a 232B, exceto que o ESInet 160 ou o PSAP 180 podem substituir o SP OTT 150 nos fluxos de mensagens em termos de envio da solicitação de localização em 214B e que recebe a resposta de localização em 232B.

[0110] Voltando-se para a chamada de serviço de emergência mostrada na Figura 2B, em 234B, o SP OTT 150 roteia a chamada de emergência para o ESInet apropriado 160, ou possivelmente a um SR 160 se o SP OTT 150 precisar converter a chamada em uma chamada de emergência CS. O ESInet 160 (ou um SR 160), então, roteia a chamada de emergência ao PSAP apropriado 180. Essas solicitações de chamada de emergência enviadas em 234B podem incluir a referência de localização do UE 200 obtida em 212B. O SP OTT 150 pode usar a localização do UE 200 obtido em 232B, caso realizado, para rotear a chamada de emergência iniciada em 208B ao ESInet apropriado 160 (ou o SR 160). O ESInet 160 pode usar a referência de localização do UE 200 recebida na solicitação de chamada de emergência para obter uma localização para o UE 200 a partir do GMLC/SLP 170 realizando-se blocos análogos a 214B a 232B conforme descrito acima. O ESInet 160, então, pode usar essa localização obtida para rotear a chamada de emergência ao PSAP apropriado 180.

[0111] Em 236B, as diversas entidades de rede (por exemplo, o UE 200, o SP OTT 150, o ESInet 160 e o PSAP 180) realizam o restante do estabelecimento de chamada de emergência. Em 238B, o PSAP 180 envia uma solicitação de localização, que inclui a referência de localização recebida em 234B, ao GMLC/SLP 170. O GMLC/SLP 170 usa a referência de localização para consultar a localização do UE 200 (por exemplo, consultar a localização obtida anteriormente em 226B e/ou 228B) e responde com a localização do UE 200. Alternativamente, o GMLC/SLP 170 pode obter a localização do UE 200 realizando-se etapas (não mostradas na Figura 2B) que são as mesmas que aquelas ilustradas em 216B a 226B e/ou 228B.

[0112] A Figura 3 ilustra uma arquitetura exemplificativa para fornecer serviços de emergência por um provedor de serviço OTT que mostra soluções de localização alternativas de acordo com pelo menos um aspecto da revelação. A arquitetura ilustrada na Figura 3 inclui um UE 300 (que pode corresponder o UE 200), uma rede de acesso 320 (que pode corresponder à RAN 120), uma rede principal em pacote 340 (que pode corresponder à rede principal 140), um SP OTT 350 (que pode corresponder ao SP OTT 150), um ESInet/SR 360 (que pode corresponder ao ESInet/SR 160), um servidor de localização de emergência (ELS) 370 (que pode corresponder ao E-SMLC 172, ao GMLC/SLP 170 ou ao servidor de localização 170), uma Rede de IP 375 (que pode corresponder à Internet 175), uma rede domiciliar 385 que pode ser uma rede domiciliar para o UE 300 e um PSAP 380 (que pode corresponder ao PSAP 180).

[0113] A Figura 3 mostra diversas soluções alternativas, rotuladas S1, S2, S3, S3a, S3b, S4 e S5, para transferir a localização de um UE 300 que invocou um serviço de emergência (por exemplo, chamada de voz de emergência, sessão de mensagem de texto de emergência) para ou a partir de um SP OTT 350. Para cada solução, o SP OTT pode ser responsável pela invocação e roteamento de uma chamada de serviço de emergência nos serviços de emergência rede (por exemplo, a um ESInet ou diretamente a um PSAP).

[0114] Para a solução S1, o UE 300 pode forçar uma localização adequada para rotear (e, possivelmente, despachar) ao SP OTT 350. A localização pode ser uma localização por valor (LbyV) ou uma localização por referência (LbyR) e pode ser obtida a partir de um servidor de localização (por exemplo, o ELS 370) ou pode ser determinada apenas pelo UE 300 no caso de localização por valor. No caso de localização por referência, o UE 300 pode enviar uma solicitação para uma referência de localização ao servidor de localização, e, então, enviar a referência de localização recebida (na forma de um URI de localização) ao SP OTT 350. O SP OTT 350 pode realizar, então, o desreferenciamento (por exemplo, com o uso de HELD) solicitando-se um valor de localização a partir do servidor de localização (por exemplo, o ELS 370) que atribuiu o URI de localização.

[0115] Com a solução S2, o SP OTT 350 pode consultar o UE 300 para a localização do UE 300, por exemplo, depois de receber uma invocação de chamada de serviço de emergência a partir do UE 300 em uma mensagem de CONVITE DE SIP. A consulta pode usar sinalização em serviço (por exemplo, uma solicitação por meio de uma mensagem de INFO de SIP) ou sinalização fora de serviço (por exemplo, uma solicitação por meio de dados ou trajetória de sinalização separados). O UE 300 pode devolver a localização ao SP OTT 350 com o uso de meios análogos à solicitação, por exemplo, sinalização em chamada se a solicitação usou sinalização em chamada. As informações de localização que são devolvidas podem ser as mesmas que para a solução S1, por exemplo, LByV ou LbyR.

[0116] Com a solução S3, depois de receber uma invocação de chamada de serviço de emergência a partir do UE 300 (por exemplo, em um CONVITE DE SIP), o SP OTT 350 pode consultar o ELS 370 que pode estar em ou ser associado à rede de acesso 320 ou PCN 340, por exemplo. O SP OTT 350 pode determinar, em alguns casos, a rede de acesso 320, a PCN 340 e/ou o ELS 370 com o uso do endereço de IP do UE ou um identificador para a rede de acesso 320 ou a PCN 340 fornecidos pelo UE 300 ao SP OTT 350. Por exemplo, no caso do endereço de IP, faixas conhecidas de endereços de IP ou subcampos particulares em um endereço de IP podem ser configuradas pelo SP OTT 350 (por exemplo, em um servidor de chamada) e mapeadas a redes de acesso particulares e PCNs. Nas variantes S3a e S3b da solução S3, o SP OTT 350 pode enviar uma solicitação de localização para o UE 300 à rede de acesso 320 e PCN 340, respectivamente, para encaminhamento adiante a um servidor de localização (por exemplo, o ELS 370).

[0117] Com a solução S4, depois de receber uma invocação de chamada de serviço de emergência a partir do UE 300 (por exemplo, em um CONVITE DE SIP), o SP OTT 350 pode consultar um servidor de localização ou serviço de localização na Rede Domiciliar 385 para o UE 300. O UE 300 pode ser referenciado ao uso de uma identidade pública global (por exemplo, URI de SIP, MSISDN, etc.). O SP OTT 350 pode determinar a Rede Domiciliar 385 e o servidor de localização ou serviço de localização na Rede Domiciliar 385 com o uso da identidade pública global. A Rede Domiciliar 385 pode conhecer a localização geral do UE 300 (por exemplo, a partir das informações recebidas da PCN 340 para suportar roaming) e/ou pode localizar o UE 300 diretamente (por exemplo, com o uso de SUPL).

[0118] Com a solução S5, um PSAP 380 ou o ESInet/SR 360 pode consultar o SP OTT 350 para uma localização do UE 300 necessário para rotear ou despachar. O SP OTT 350 pode usar uma das outras alternativas de solução (S1, S2, S3, S3a, S3b, S4) para obter uma localização por valor (por exemplo, localização geográfica ou localização cívica) para o UE 300 ou uma localização por referência para o UE 300 e pode devolver, então, isso para o PSAP 380 ou o ESInet/SR 360. Se uma localização por referência for devolvida, o PSAP 380 ou o ESInet/SR 360 podem precisar consultar o servidor de localização (por exemplo, o ELS 370) que atribuiu a localização por referência na rede de acesso 320 ou o PCN 340 para obter a localização do UE 300.

[0119] As soluções de localização por referência descritas anteriormente em associação com as Figuras 1A, 1B, 2A e 2B podem ser empregadas em combinação com as soluções S1, S2 e S5 descritas anteriormente para a Figura 3. Essas soluções de localização por referência podem reduzir impactos a um UE como o UE 200 e o UE 300 e a um servidor de localização como o servidor de localização 170 e o ELS 370 para obter uma referência de localização conforme descrito anteriormente. Entretanto, as soluções podem não abordar outros aspectos do suporte de chamada de emergência por um SP OTT 150 ou SP OTT 350 como o roteamento de uma chamada de emergência a um PSAP (por exemplo, o PSAP 180 ou o PSAP 380) e permitir que um PSAP solicite e obtenha uma localização para um UE 200 ou UE 300 que pode ser usado para o despacho do PSAP. Para abordar esses outros aspectos do suporte de chamada de emergência, são descritas soluções de localização adicionais em seguida, que podem se diferenciar em alguns aspectos a partir das soluções de localização descritas em associação com as Figuras 1A a 2B. Essas soluções de localização adicionais podem fornecer extensões às soluções S1 e S2 descritas anteriormente - por exemplo, que podem permitir que informações relacionadas à localização sejam fornecidas ao SP OTT 350 além ou em vez de um LbyV ou um LByR. Para as soluções S1 e S2 da Figura 3, presume-se que o servidor de localização (ELS) 370 seja usado para fornecer uma localização por valor ou localização por referência para o UE 300. O ELS 370 pode corresponder a um dentre diversos servidores de localização diferentes em arquiteturas de rede diferentes (por exemplo, o ELS 370 pode ser um E-SMLC 172, um GMLC 170, um SLP 170 ou uma LRF). A associação do ELS 370 a uma LRF pode ser particularmente útil, visto que uma LRF é definida para suportar uma interface externa para a deferência de localização (por exemplo, em 3GPP TS 23.167 e no padrão ATIS ATIS-0700015) e pode ter acesso à capacidade de determinação de localização dentro da PCN 340 e/ou AN 320 com o uso de uma solução de localização de plano de controle e/ou solução de localização de plano de usuário.

[0120] As soluções S1 e S2 da Figura 3 podem ser consideradas complementares entre si e ambas podem ser suportadas. Por exemplo, a solução S1 pode ser usada quando o UE 300 detectar que um usuário invoca uma chamada de emergência e tem tempo para obter algumas informações de localização antes de enviar uma solicitação de chamada de emergência ao SP OTT 350. A solução S2 pode ser usada quando o UE 300 não detectar que um usuário invoca uma chamada de emergência ou não tem tempo bastante para obter informações de localização antes de enviar uma solicitação de serviço de emergência ao SP OTT 350.

[0121] Os aprimoramentos para as soluções S1 e S2 da Figura 3 podem precisar resolver diversos conjuntos de problemas quando a suportar a localização e o roteamento por um MNO de serviço no lugar de uma chamada de emergência que foi enviada inicialmente por um UE 300 a um SP OTT 350. Esses diversos conjuntos de problemas são descritos e exemplificados a seguir.

[0122] Conjunto de Problemas 1: PSAPS Herdado

[0123] Podem existir problemas associados ao suporte de localização e roteamento para uma chamada de emergência que precisa ser enviada para um PSAP herdado 380, quando o PSAP herdado 380 não for suportado por um ESInet 360 (por exemplo, mas pode ser, em vez disso, suportado por um SR 360). Um problema pode ser que um PSAP herdado 380 pode não ter capacidade para recuperar uma localização para um UE 300 a partir de um SP OTT 350 com o uso da interface de E2 definida no J-STD- padrão conjunto TIA e ATIS 036, que pode ocorrer se o SP OTT 350 estiver em um país diferente do UE 300 e do PSAP 380 ou se o PSAP 380 não tiver uma relação de comunicações com o SP OTT 350. Deve ser observado que a interface de E2 é usada normalmente para a recuperação de localização por um PSAP herdado no caso de uma chamada de emergência instigada por meio de uma rede sem fio pública na América do Norte em que a chamada de emergência é roteada para um PSAP herdado. Um segundo problema pode ser que não seja possível que um SP OTT 350 envie um LbyV a um PSAP herdado 380 como parte da sinalização de chamada (por exemplo, se a chamada de emergência para um UE 300 for roteada através de um SR 360 que usa um tronco de MF para alcançar o PSAP 380). Um terceiro problema pode ser que um PSAP herdado 380 (ou um ALI associado a um PSAP herdado 380) não possa suportar normalmente a deferência de um LbyR no caso do SP OTT 350 fornecer um LbyR ao invés de LbyV ao PSAP 380.

[0124] Os três problemas acima podem significar que qualquer aprimoramento das soluções S1 e S2 com base apenas no fornecimento de um LbyV ou LbyR a um SP OTT 350 pode não suportar o fornecimento de uma localização despachável a um PSAP herdado 380, quando o PSAP herdado 380 não for suportado por um ESInet 360 (por exemplo, mas for apenas suportado por um SR 360).

[0125] Conjunto de Problemas 2: Localização de Plano de Controle em um MNO de Serviço

[0126] Com a solução de localização de plano de controle de 3GPP para acesso de LTE ou HSPA (por exemplo, conforme definido em 3 GPP TSs 23.271, 25.305 e 36.305) , a identidade da MME de serviço atual ou do SGSN de serviço, para um UE 300 que faz uma chamada de emergência, precisa ser conhecida em uma LRF ou GMLC a fim de rotear uma solicitação para uma localização do UE 300 à MME de serviço ou SGSN de serviço correto. Para chamadas de emergência que são estabelecidas por um MNO de serviço sem o envolvimento de um SP OTT (por exemplo, conforme descrito em ATIS-0700015), essas informações podem ser mantidas atualizadas na LRF e GMLC (que estão em uso para suportar a localização para o UE que faz a chamada de emergência 300) pela MME de serviço ou SGSN de serviço quando o UE 300 estabelecer uma conexão de PDN de emergência ou contexto de PDP de emergência (por exemplo, como parte do estabelecimento da chamada de emergência), e pela MME ou SGSN nova ou anterior quando ocorrer a entrega. Entretanto, para uma chamada de emergência que é estabelecida através de um SP OTT 350, o MNO de serviço pode não ser sensível à chamada de emergência e, assim, a LRF (e o GMLC) podem não ser mantidos atualizados com a identidade da MME de serviço ou do SGSN de serviço. Sem essas informações, um GMLC pode não ter capacidade para rotear uma solicitação de localização à MME de serviço ou SGSN de serviço corretos. Isso significa que, quando atender uma solicitação de deferência de localização para um UE 300 a partir de um SP OTT 350, um ELS 370 (por exemplo, LRF) pode não ter capacidade para usar uma solução de plano de controle para obter a localização do UE 300 - exceto, possivelmente, no caso de um assinante domiciliar quando o ELS 370 tiver informações suficientes para consultar essas informações a partir de um HSS.

[0127] Conjunto de Problemas 3: Localização de Plano de Usuário em um MNO de Serviço

[0128] Quando um UE 300 acessar um SP OTT 350 por meio de uma VPN que é intermediária entre o MNO de serviço (por exemplo, a PCN 340) e o SP OTT 350, o endereço de IP do UE 300 que é visto pelo SP OTT 350 pode ter sido assinado pelo VPN e pode diferir, assim, de quaisquer endereços de IP atribuídos ao UE pelo MNO de serviço (por exemplo, PCN 340). Se um SLP no MNO de serviço (por exemplo, o ELS 370) só aceitar solicitações de localização de entrada no lugar de UEs com endereços de IP conhecidos ou atribuídos pelo MNO de serviço, isso pode impedir o uso da localização de SUPL pelo MNO de serviço se a endereço de IP atribuído pela VPN estiver incluído em uma solicitação de localização enviada ao MNO de serviço (por exemplo, enviado ao ELS 370) pelo SP OTT 350. Um problema similar pode ocorrer para um UE de roaming 300 cujo endereço de IP é atribuído pela rede domiciliar 385 (por exemplo, em que a Porta de Comunicação de PDN para o acesso de LTE está na rede domiciliar 385). Entretanto, nesse caso, um MNO de serviço (por exemplo, um SLP no MNO de serviço) pode ser configurado com os endereços de IP (por exemplo, faixas de endereço) atribuídos com a realização de roaming em parceria, como a rede domiciliar 385, em tal caso, o uso da localização do plano de usuário (por exemplo, SUPL) pode continuar a ser possível.

[0129] Conjunto de Problemas 4: Roteamento de uma Chamada de Emergência a um PSAP

[0130] Embora um SP OTT 350 possa ter capacidade para rotear uma chamada de emergência de um UE 300 para um PSAP 380 (por exemplo, por meio de uma Rede de IP 375 ou por meio da PSTN) se o endereço ou identidade corretos para o PSAP 380 for conhecido (por exemplo, um URL de SIP ou DN de telefone), alguns SPs OTT 350 podem não ter a capacidade de mapear uma localização geográfica para um UE 300 no endereço ou identidade de um PSAP 380 cuja área de serviço inclui a localização do endereço de UE 300. Por exemplo, essa falta de capacidade pode ocorrer se o SP OTT 350 estiver em um país diferente do UE 300 e o PSAP 380 não tiver uma capacidade de obter informações de roteamento para PSAPs em outros países - por exemplo, com o uso do protocolo de LoST definido por IETF. Em alguns casos, mesmo se o endereço ou a identidade de PSAP 380 for conhecido por um SP OTT 350, pode não ser possível que o SP OTT 350 encaminhe uma chamada de emergência para um UE 300 ao PSAP 380 devido a restrições no ingresso de chamada de emergência no lado do PSAP 380.

[0131] Os conjuntos de problemas 1 a 4 descritos e exemplificados acima podem ser resolvidos por aprimoramentos particulares às soluções S1 e S2 referidas anteriormente conforme descrito a seguir.

[0132] A Figura 4 ilustra uma arquitetura exemplificativa para a localização por suporte de referência para serviços de emergência por um provedor de serviço OTT de acordo com pelo menos um aspecto da revelação. A arquitetura ilustrada na Figura 4 inclui um UE 400 (que pode corresponder ao UE 200 ou ao UE 300), uma rede de acesso 420 (que pode corresponder à RAN 120 ou à AN 320), um IMS 440 (que pode corresponder a parte da rede principal 140 ou parte da PCN 340), um SP OTT 450 (que pode corresponder ao SP OTT 150 ou ao SP OTT 350), um ESInet com capacidade de i3 de NENA 460 (que pode corresponder ao ESInet 160 ou ao ESInet 360), uma ESN Herdada 462, a Internet 475, uma PSTN 485 e um a MNO de serviço 490 (que pode corresponder à CN 140 combinada com a AN 120 ou à PCN 340 combinada com a AN 320). O IMS 440 inclui uma LRF 448 (que pode corresponder ao servidor de localização 170 ou ELS 370), um MGCF 441, um P-CSCF 442, um E-CSCF 443, um IBCF 444 e um S-CSCF 445. O LRF 448 pode ser conectado a um RDF 446 e um LS 470 (que pode corresponder ao servidor de localização 170 ou GMLC/SLP 170). O ESInet de i3 460 inclui um BCF 464, um ESRP 466, um ECRF 468 e um PSAP com capacidade de i3 de NENA 480 (que pode corresponder ao PSAP 180 ou ao PSAP 380). A ESN Herdada 462 inclui uma ALI 461, um SR 463 (que pode corresponder ao SR 160 ou ao SR 360), e um PSAP Herdado 482 (que pode corresponder ao PSAP 180 ou ao PSAP 380). As diversas entidades mostradas na Figura 4 são bem conhecidas na técnica e são definidas em 3 GPP TSs (por exemplo, TSs 23.401, 23.167, 23.228), no padrão ATIS 0700015, e no padrão i3 de NENA.

[0133] Com o suporte de LbyR normal, mostrado na Figura 4 para a solução S1, o UE 400 envia uma solicitação de chamada de emergência 401 ao SP OTT 450 que contém um LbyR. O SP OTT 450, então, desreferencia o LbyR enviando-se uma consulta de localização 402 a um ELS (por exemplo, a LRF 448 no MNO de serviço 490) indicado pelo LbyR recebido na solicitação de chamada de emergência 401. O ELS (mostrado como uma LRF 448 na Figura 4) obtém uma localização para o UE 400 e devolve a localização e/ou as informações de roteamento ao SP OTT 450. O SP OTT 450, então, roteia a chamada de emergência ao PSAP (o PSAP herdado 482 na mensagem 403A ou o PSAP com capacidade de i3 de NENA 480 na mensagem 403B) com base nas informações de roteamento ou na localização recebida da LRF 448 e que contém o LByR recebido originalmente. O PSAP 480 / 482, então, pode enviar uma consulta 404A (para o PSAP 482) ou 404B (para o PSAP 480) ao ELS (por exemplo, a LRF 448) em um momento posterior para uma localização despachável com o uso do LByR recebido. Conforme discutido para o Conjunto de Problemas 1 acima, uma consulta de localização 404A pode não ser possível para um PSAP herdado 482 a não ser que o PSAP seja suportado por um ESInet.

[0134] A solução de LbyR básica descrita acima em associação à Figura 4 pode ser aprimorada para as soluções S1 e S2 da Figura 3 para superar os problemas descritos acima para os conjuntos de problemas 2 e 3. Especificamente, um URI de localização que é atribuído pelo MNO de serviço 490 (por exemplo, pela LRF 448) como um LbyR para um UE 400 pode ser formatado para conter as seguintes informações: a) um local endereço de IP para o UE 400 se o MNO de serviço 490 usar a localização do plano de usuário para localizar o UE 400 e se um local endereço de IP for atribuído ao UE 400 pelo MNO de serviço 490; b) uma identidade local de um MME de serviço (por exemplo, a MME 142) ou SGSN de serviço se o MNO de serviço 490 usar a localização de plano de controle para localizar o UE 400; e c) uma identidade para o UE 400 (por exemplo, um MSISDN, um IMSI ou uma ID local atribuída à MME de serviço ou SGSN) se o MNO de serviço 490 usar a localização de plano de controle para localizar o UE 400.

[0135] As informações acima em (a), (b) e (c) podem ser incluídas como a parte do LbyR usado normalmente como uma referência local para o UE 400, e podem permitir a atribuição de LbyR pela AN 420 ou uma PCN no MNO de serviço 490 em vez de um ELS, como a LRF 448 (por exemplo, conforme descrito anteriormente em associação com as Figuras 1A a 2B), que pode simplificar a implantação. A formatação dessas informações pode ser específica ao MNO de serviço 490 (por exemplo, pode não ser padronizada). Um ELS (por exemplo, a LRF 448) no MNO de serviço 490 que recebe tal URI de localização em uma solicitação de desreferenciamento, como a solicitação 402, para um LbyR a partir de um SP OTT 450 e conhece as regras de formatação para que o LbyR possa extrair as informações em (a) a (c) acima e usam o mesmo para invocar o plano de controle ou a localização do plano de usuário do UE 400. Um benefício adicional é que o ELS não precisa manter informações para a chamada de emergência proveniente do UE 400 e pode responder a cada solicitação de desreferenciamento (por exemplo, a solicitação 402) com base apenas nas informações incluídas em cada uma das tais solicitações.

[0136] O aprimoramento acima, conforme descrito em associação à Figura 4, é referido no presente documento como "LbyR aprimorado" e é ilustrado posteriormente no presente documento com o uso de Figuras adicionais, mas pode não solucionar todos os problemas no Conjunto de Problemas 2 acima. Por exemplo, mesmo que o LbyR para o UE 400 possa conter a identidade da MME de serviço atual ou do SGSN de serviço atual para o UE 400, as informações podem ficar desatualizadas quando o UE 400 for transferido para um novo MME ou SGSN de serviço, a não ser que o UE 400 envie novas informações (por exemplo, um novo LbyR) ao SP OTT 450 (por exemplo, em uma INFO de SIP), que, então, encaminha isso ao PSAP 480 ou 482.

[0137] O suporte de IMS é outro aprimoramento às soluções S1 e S2 da Figura 3 que pode ser usado para resolver todos os problemas descritos acima para os conjuntos de problemas 1, 2, 3 e 4. Com o suporte de IMS, o MNO de serviço pode oferecer suporte como uma LRF, conforme descrito a seguir em associação com a Figura 5, ou como um E-CSCF, conforme descrito posteriormente em associação com a Figura 6.

[0138] A Figura 5 ilustra uma arquitetura exemplificativa para suporte de LRF de IMS para serviços de emergência por um provedor de serviço OTT de acordo com pelo menos um aspecto da revelação. De modo similar à arquitetura ilustrada na Figura 4, a arquitetura ilustrada na Figura 5 inclui um UE 500 (que pode corresponder ao UE 200, ao UE 300 ou ao UE 400), uma rede de acesso 520 (que pode corresponder à RAN 120, à AN 320 ou à AN 420), um IMS 540 (que pode corresponder a parte da rede principal 140, parte da PCN 340 ou IMS 440), um SP OTT 550 (que pode corresponder ao SP OTT 150, ao SP OTT 350 ou ao SP OTT 450), um ESInet com capacidade de i3 de NENA 560 (que pode corresponder ao ESInet 160, ao ESInet 360 ou ao ESInet 460), uma ESN Herdada 562, a Internet 575, uma PSTN 585 e um a MNO de serviço 590 (que pode corresponder à CN 140 combinada com a AN 120, à PCN 340 combinada à AN 320 ou ao MNO 490). O IMS 540 inclui uma LRF 548 (que pode corresponder ao servidor de localização 170, ao ELS 370 ou à LRF 448), um MGCF 541, um P-CSCF 542, um E-CSCF 543, um IBCF 544 e um S-CSCF 545. O LRF 548 pode ser conectado a um RDF 546 e um LS 570 (que pode corresponder ao servidor de localização 170, o GMLC/SLP 170 ou o LS 470). O ESInet de i3 560 inclui um BCF 564, um ESRP 566, um ECRF 568 e um PSAP com capacidade de i3 de NENA 580 (que pode corresponder ao PSAP 180, o PSAP 380 ou ao PSAP 480). A ESN Herdada 562 inclui uma ALI 561, um SR 563 (que pode corresponder ao SR 160, o SR 360 ou ao SR 463), e um PSAP Herdado 582 (que pode corresponder ao PSAP 180, o PSAP 380 ou ao PSAP 482). Como para a Figura 4, as diversas entidades mostradas na Figura 5 são bem conhecidas na técnica.

[0139] Com o suporte de LRF, mostrado na Figura 5 para a solução S1 da Figura 3, uma chamada de emergência do UE 500 para o PSAP 580 ou PSAP 582 pode ser estabelecida de modo similar à chamada de emergência do UE 400 para o PSAP 480 ou PSAP 482 descrito em associação com a Figura 4, e com as mensagens 401, 402, 403A, 403B, 404A e 404B na Figura 4 que correspondem às mensagens 501, 502A, 503A, 503B, 504A e 504B, respectivamente, na Figura 5. Entretanto, no caso do suporte de LRF mostrado na Figura 5, a interação entre o SP OTT 550 e a LRF 548 na consulta 502A e na resposta 502B não usa deferência de localização como na Figura 4, mas, em vez disso, faz uso da capacidade de LRF de suportar a recuperação de localização e o roteamento de uma chamada de emergência. O SP OTT 550 recebe inicialmente um endereço da LRF 548 no MNO de serviço 590 a partir do UE 500 na solicitação de chamada de emergência 501 (que o UE 500 pode obter a partir da AN de MNO de serviço 520 ou uma PCN no MNO de serviço 590, por exemplo, na anexação de rede). O SP OTT 550, então, se comporta de modo similar a um E-CSCF (por exemplo, para o padrão ATIS- 0700015) e encaminha a solicitação de chamada de emergência na forma de um CONVITE DE SIP 502A à LRF 548, que obtém a localização e as informações de roteamento de modo similar àquelas descritas para uma LRF em ATIS-00700015 para a interface de M1. O LRF 548, então, devolve a localização e as informações de roteamento para o SP OTT 550 na forma de um SIP 300 com Múltiplas Escolhas 502B (por exemplo, conforme ocorre na interface de M1 em ATIS-0700015). O SP OTT 550, então, roteia a solicitação de chamada de emergência ao PSAP (o PSAP herdado 582 na solicitação 503A ou o PSAP com capacidade de i3 de NENA 580 na solicitação 503B) com o uso das informações de roteamento e que contém as informações de localização recebidas na resposta 502B. As informações de localização recebidas na resposta 502B pode conter um LbyV, um LbyR, um ESRK ou um ESRD mais um MSISDN e pode corresponder ao identificador de referência definido em ATIS-0700015. Para as últimas três alternativas (isto é, LbyR, ESRK ou ESRD mais MSISDN), o PSAP 580/582 pode enviar tipicamente uma consulta 504A (para o PSAP 582) ou uma consulta 504B (para o PSAP 580) à LRF 548 em um momento posterior para uma localização despachável para o UE 500.

[0140] A Figura 5 mostra a trajetória e a direção da mensagem inicial de solicitação de chamada de emergência (por exemplo, um CONVITE DE SIP) 501 a partir do UE 500 para o SP OTT 550, a trajetória à LRF 548 (para o CONVITE DE SIP encaminhado 502A) e de volta para o SP OTT 550 (para o SIP 300 de Múltiplas Escolhas 502B) e a trajetória e a direção do SP OTT 550 para o PSAP 580/582 para a solicitação de chamada de emergência encaminhada 503A e 503B. A Internet 575 pode ser usada para fornecer a solicitação de chamada inicial 501 do MNO de serviço 590 para o SP OTT 550 e para fornecer a solicitação de chamada encaminhada 503B do SP OTT 550 para o ESInet 560, enquanto a PSTN 585 pode ser usada para fornecer uma solicitação de chamada de CS 503A do SP OTT 550 para o SR 563 para alcançar o PSAP herdado 582. A Figura 5 também mostra uma trajetória e uma direção para uma solicitação de localização 504A ou 504B para o UE 500 enviado pelo PSAP herdado 582 ou o PSAP de i3 de NENA 580, respectivamente, à LRF 548.

[0141] A Figura 6 ilustra uma arquitetura exemplificativa para suporte de E-CSCF de IMS para serviços de emergência por um provedor de serviço OTT de acordo com pelo menos um aspecto da revelação. De modo similar à arquitetura ilustrada nas Figuras 4 e 5, a arquitetura ilustrada na Figura 6 inclui um UE 600 (que pode corresponder ao UE 200, ao UE 300, ao UE 400 ou ao UE 500), uma rede de acesso 620 (que pode corresponder à RAN 120, à AN 320, à AN 420 ou à AN 520), um IMS 640 (que pode corresponder a parte da rede principal 140, parte da PCN 340, o IMS 440 ou o IMS 540), um SP OTT 650 (que pode corresponder ao SP OTT 150, ao SP OTT 350, ao SP OTT 450 ou ao SP OTT 550), um ESInet com capacidade de i3 de NENA 660 (que pode corresponder ao ESInet 160, ao ESInet 360, ao ESInet 460 ou ao ESInet 560), uma ESN Herdada 662, a Internet 675, uma PSTN 685 e um a MNO de serviço 690 (que pode corresponder à CN 140 combinada com a AN 120, à PCN 340 combinada à AN 320, ao MNO 490 ou ao MNO 590). O IMS 640 inclui uma LRF 648 (que pode corresponder ao servidor de localização 170, ao ELS 370, à LRF 448 ou à LRF 548), um MGCF 641, um P-CSCF 642, um E-CSCF 643, um IBCF 644 e um S- CSCF 645. O LRF 648 pode ser conectado a um RDF 646 e um LS 670 (que pode corresponder ao servidor de localização 170, o GMLC/SLP 170, o LS 470 ou o LS 570). O ESInet de i3 660 inclui um BCF 664, um ESRP 666, um ECRF 668 e um PSAP com capacidade de i3 de NENA 680 (que pode corresponder ao PSAP 180, ao PSAP 380, ao PSAP 480 ou ao PSAP 580). A ESN Herdada 662 inclui uma ALI 661, um SR 663 (que pode corresponder ao SR 160, ao SR 360, ao SR 463 ou ao SR 563), e um PSAP Herdado 682 (que pode corresponder ao PSAP 180, ao PSAP 380, ao PSAP 482 ou ao PSAP 582). Como para as Figuras 4 e 5, as diversas entidades mostradas na Figura 6 são bem conhecidas na técnica.

[0142] Com o suporte de E-CSCF, mostrado na Figura 6 para a solução S1 da Figura 3, o SP OTT 650 recebe um endereço do E-CSCF 643 no MNO de serviço 690 na solicitação de chamada de emergência 601 enviada do UE 600 (que o UE 600 pode obter da AN ou PCN de MNO de serviço 620 no MNO de serviço 690, por exemplo, na anexação de rede). O SP OTT 650, então, se comporta de modo similar a um S-CSCF e encaminha a solicitação dos serviços de emergência com o uso de um CONVITE DE SIP padrão 602 ao E-CSCF 643, que, então, encaminha a solicitação de chamada 604A ou 604B a um PSAP 680 ou 682, respectivamente, depois de ter enviado uma solicitação 603A à LRF 648 para obter quaisquer informações de roteamento e localização em uma resposta 603B necessária para realizar o encaminhamento. O suporte de E-CSCF exemplificado na Figura 6 pode melhorar a probabilidade de uma transferência de chamada (ou serviço) bem-sucedida a um PSAP 680/682 no custo de envolvimento maior pelo MNO de serviço 690.

[0143] De modo similar à Figura 5, a Figura 6 mostra a trajetória e a direção da mensagem inicial de solicitação de chamada de emergência (por exemplo, um CONVITE DE SIP) 601 do UE 600 para o SP OTT 650, a trajetória da solicitação de chamada encaminhada 602 para o E-CSCF 643, e a trajetória e a direção ao PSAP 680 ou 682 da solicitação de chamada encaminhada 604A ou 604B, respectivamente, com a assistência de localização e roteamento solicitada pelo E-CSCF 643 na solicitação 603A e devolvida pela LRF 648 na resposta 603B. A solicitação 603A à LRF 648 e a resposta 603B da LRF 648 podem se dar conforme definido para a solução em ATIS-0700015 - por exemplo, com a solicitação 603A que compreende um CONVITE DE SIP e a resposta 603B que compreende uma mensagem com múltiplas escolhas de SIP 300. A Figura 6 também mostra uma trajetória e uma direção para uma solicitação de localização 605A ou 605B para o UE 600 enviado pelo PSAP herdado 682 ou o PSAP de i3 de NENA 680, respectivamente, à LRF 648.

[0144] Ambas as soluções de LRF 648 e E-CSCF 643 descritas em associação com as Figuras 5 e 6, respectivamente, podem exigir algumas mudanças a uma LRF e RDF, e a um E-CSCF para a solução de E-CSCF da Figura 6, em comparação à solução de chamada de emergência de IMS definida por 3 GPP (por exemplo, em 3 GPP TS 23.167) e em ATIS-0700015, mas também pode reusar a funcionalidade existente a partir dessas soluções padrão.

[0145] Para cada solução descrita acima com referência às Figuras 5 e 6, um UE (por exemplo, o UE 500 ou o 600) pode fornecer o SP OTT (por exemplo, SP OTT 550 ou 650) com certas informações para (i) permitir o roteamento de chamada de emergência do SP OTT para a entidade correta no MNO de serviço (uma LRF ou E-CSCF) e (ii) permitir que o SP OTT forneça informações o bastante ao MNO de serviço para permitir ou auxiliar o MNO de serviço para obter a localização de UE e para suportar o roteamento de chamada. Algumas das informações fornecidas pelo UE ao SP OTT pode vir do que é normalmente conhecido ao UE enquanto outras informações podem ter que ser fornecidas ao UE pela AN (por exemplo, a AN 520 ou 620) ou pela PCN no MNO de serviço (por exemplo, o MNO 590 ou 690), por exemplo, na anexação de UE, na entrega a um novo MME ou SGSN e/ou sempre que uma área de rastreamento ou atualização de área de roteamento ocorrer a um novo MME ou SGSN. As informações que podem ser fornecidas pelo UE ao SP OTT em uma solicitação de chamada de emergência para o UE são mostradas na Tabela 3 (coluna l) junto com a fonte provável de cada item das informações (coluna 2), aplicabilidade à localização do plano de usuário (UP) ou do plano de controle (CP) para o UE (coluna 3), e possíveis cabeçalhos de SIP que podem ser usados para transferir cada item ao SP OTT (e, a partir disso, ao MNO de serviço) quando o SIP for usado entre o UE e o SP OTT (coluna 4). TABELA 3

[0146] O LRF 548 ou o E-CSCF 643 no MNO de serviço 590 ou 690 pode precisar manter informações de estado depois de receber o CONVITE DE SIP inicial 502A ou 602, respectivamente, a partir do SP OTT 550 ou 650, em associação com a solução na Figura 5 ou na Figura 6, respectivamente, para manter a chamada no caso de um E-CSCF 643 ou para responder a qualquer solicitação de localização subsequente a partir do PSAP 580/582 ou um ESInet 560 no caso de uma LRF 548. No caso da LRF 548, isso significa saber quando a chamada de emergência terminou. Além disso, visto que um MME de serviço ou SGSN de serviço para o UE 500 ou 600 pode mudar, o E-CSCF 643 ou LRF 548 pode precisar conhecer o novo endereço (ou ID) de MME ou SGSN de serviço quando a localização de plano de controle for usada. Para uma LRF 548, esses objetivos podem ser alcançados se a LRF 548 assinar separadamente a notificação de evento a partir do SP OTT 550 para o término de chamada e, quando a localização de plano de controle for usada, para a mudança da MME ou SGSN de serviço. Para um E-CSCF 643, a notificação de uma mudança no endereço de MME ou SGSN de serviço pode ser possível com uma atualização de INFO de SIP a partir do SP OTT 650. O UE 500 ou 600 pode manter o SP OTT 550 ou 650, respectivamente, atualizado com qualquer nova identidade de MME ou SGSN de serviço com o uso de uma INFO de SIP (por exemplo, quando o SP OTT usa a SIP) ou com o uso de alguma mensagem proprietária de SP OTT.

[0147] Ambas as soluções ilustradas nas Figuras 5 e 6 podem transferir as mesmas informações mostradas na Tabela 3 a partir do UE 500 ou UE 600 ao SP OTT 550 ou SP OTT 650, respectivamente, exceto que o endereço no MNO de serviço fornecido ao SP OTT 550 ou 650 pelo UE 500 ou 600, respectivamente, pode ser um endereço para a LRF 548 para a solução de LRF da Figura 5 e um endereço para o E-CSCF 643 para a solução de E-CSCF da Figura 6. Essas informações quase idênticas são transferidas do UE 500 ou 600 para o SP OTT 550 ou 650, respectivamente, podem permitir que ambas as soluções (para as Figuras 5 e 6) sejam suportadas como parte de uma solução comum pelos UEs 500 e 600 e pelos SPs OTT 550 e 650 que podem permitir que um MNO de serviço 590 ou 690 decidam quais das duas soluções deve ser usada e pode suportar a migração de uma solução para a outra sem afetar o suporte pelos UEs 500 e 600 e SPs OTT 550 e 650. As Figuras descritas a seguir exemplificam em mais detalhes a solução com base em LRF da Figura 5 e a solução com base em E-CSCF da Figura 6.

[0148] A Figura 7 ilustra um fluxo de mensagens exemplificativo para localização aprimorada por valor e localização por suporte de referência de acordo com pelo menos um aspecto da revelação. O fluxo de mensagens ilustrado na Figura 7 pode ser realizado nas arquiteturas ilustradas nas Figuras 3 e 4 e podem corresponder e se estender às interações para o suporte de localização por referência descrito em associação com a Figura 4. O fluxo de mensagens na Figura 7 pode ser realizado também ou alternativamente nas arquiteturas ilustradas nas Figuras 1A e 1B e podem complementar e estender as interações descritas em associação com as Figuras 2A e 2B para o suporte de localização por referência. Como uma consequência, o UE 700 na Figura 7 pode corresponder a qualquer um dos UEs 1 a N na Figura 1A, o UE 200, o UE 300 ou o UE 400. De modo similar, o SP OTT 750 pode corresponder ao SP OTT 150, ao SP OTT 350 ou ao SP OTT 450. De modo similar, a AN/PCN 792 pode corresponder à AN 420 mais à porção de PCN do MNO 490, a AN 320 mais PCN 340 ou à AN 120 mais CN 140 e pode incluir o nó de rede de acesso 240. De modo similar, o ELS 794 pode corresponder à LRF 448, ao ELS 370, ao GMLC/SLP 170 ou ao servidor de localização 170. De modo similar, o SR 763 pode corresponder ao SR 463, ao SR 360 ou ao SR 160. De modo similar, o ESInet 760 pode corresponder ao ESInet 460, ao ESInet 360 ou ao ESInet 160. De modo similar, o PSAP de i3 780 pode corresponder ao PSAP de i3 480, ao PSAP 380 ou ao PSAP 180. De modo similar, o PSAP herdado 782 pode corresponder ao PSAP herdado 482, ao PSAP 380 ou ao PSAP 180. De modo similar, o MNO de serviço 790 pode corresponder ao MNO de serviço 490.

[0149] O fluxo de chamada mostrado na Figura 7 pode se aplicar diretamente à solução S1 na Figura 3 - por exemplo, pode fornecer mais detalhes das interações necessárias para suportar a solução S1. Um fluxo de chamada que corresponde à solução S2 na Figura 3 pode ser quase o mesmo que o fluxo de chamada mostrado na Figura 7, exceto que a solicitação de chamada de emergência em 706 não pode portar um LbyV ou LbyR (conforme descrito abaixo para a Figura 7) e o SP OTT 750 pode consultar o UE 700 para um LbyV ou LbyR após 706. Além disso, com a solução S2 na Figura 3, o UE 700 pode não detectar que o usuário instigou uma chamada de emergência em 706 (por exemplo, pode não reconhecer que o usuário discou um número de emergência como "911") e pode enviar uma solicitação de chamada normal ao SP OTT 750 em 706 e não uma solicitação de chamada de emergência. O SP OTT 750 pode reconhecer, então, que a solicitação de chamada enviada em 706 é para uma chamada de emergência (por exemplo, pode reconhecer que os dígitos discados são para um número de emergência como "911") e pode solicitar um LbyR ou LbyV a partir do UE 700 antes de proceder com o 708. As outras operações mostradas na Figura 7, quando a solução S2 da Figura 3 for usada, pode ocorrer, então, conforme descrito abaixo.

[0150] As interações mostradas na Figura 7 se aplicam a um UE 700 que instiga uma chamada de emergência por meio de um SP OTT 750 em circunstâncias em que o UE 700 acessa um MNO de serviço 790 (por exemplo, acessa o SP OTT 850 por meio do MNO de serviço 790). Em 702 na Figura 7, se um LbyR for usado pelo UE 700 para suportar uma chamada de emergência, o UE 700 pode solicitar um LbyR a partir da AN ou PCN de serviço 792. Por exemplo, isso pode ocorrer quando o UE 700 detectar que o usuário instiga uma chamada de emergência ou pode ocorrer quando o UE 700 se anexar ao MNO de serviço 790 ou acessar o MNO de serviço por algum outro motivo (por exemplo, para suportar a mobilidade do UE 700).

[0151] Em 704, em resposta a 702, ou quando certas condições ocorrem (por exemplo, o UE 700 se anexa à AN/PCN 792, realiza uma atualização de rastreamento ou área de roteamento a uma nova MME ou SGSN na AN/PCN 792 ou uma entrega ocorre a uma nova MME ou SGSN), a AN ou PCN 792 envia um LbyR ou um LbyR atualizado ao UE 700. O LbyR pode ser determinado pela AN ou PCN 792 ou obtido de um ELS 794 (por exemplo, uma LRF). Em algumas modalidades, os blocos 702 e 704 podem corresponder ao bloco 202A na Figura 2A ou aos blocos 202B e 206B, respectivamente, na Figura 2B. Nessas modalidades, a própria AN/PCN 792 pode atribuir, o LbyR que foi devolvido ao UE 700 em 704 ou pode obter o LbyR do ELS 794 de modo similar ao bloco 204B na Figura 2B (não mostrado na Figura 7).

[0152] Em 706, em resposta ao UE 700 detectar que o usuário do UE 700 instigou uma chamada de emergência (por exemplo, se o UE 700 detectar que o usuário discou os dígitos "911"), o UE 700 envia uma solicitação de chamada de emergência ao SP OTT 750 e inclui o LbyV ou o LByR obtidos em 704. A solicitação de chamada de emergência pode ser um CONVITE DE SIP ou pode ser uma mensagem para algum outro protocolo específico ao SP OTT 750. O bloco 706 pode corresponder ao bloco 214A na Figura 2A, o bloco 212B na Figura 2B ou ao envio da solicitação de chamada de emergência 401 na Figura 4.

[0153] Em 708, se um LbyR for recebido em 706, o SP OTT 750 desreferencia o LbyR enviando-se uma solicitação de localização (por exemplo, uma solicitação de localização formatada de acordo com o protocolo de HELD se o HELD for referido no LByR) ao ELS 794 e inclui o LbyR na solicitação. O SP OTT 750 pode determinar o ELS 794 (por exemplo, determinar um endereço, FQDN ou URL para o ELS 794) a partir das informações no LbyR recebido em 706. O bloco 708 pode corresponder ao bloco 216A na Figura 2A, ao bloco 214B na Figura 2B ou ao envio de uma consulta de localização 402 na Figura 4.

[0154] Em 710, o ELS 794 usa as informações incluídas no LbyR recebido em 708 (por exemplo, uma identidade de UE local ou global 700 e uma ID de MME/SGSN de serviço para a localização do plano de controle ou um endereço de IP de UE local para a localização do plano de usuário) para obter a localização atual do UE 700 - por exemplo, com o uso de um plano de controle ou solução de localização de plano de usuário. O bloco 710 pode corresponder aos blocos 218A e/ou 222A na Figura 2A ou aos blocos 216B a 226B ou bloco 228B na Figura 2B.

[0155] Em 712, o ELS 794 devolve a localização do UE atual 700 ao SP OTT 750 e/ou devolve informações de roteamento para o UE 700 determinadas a partir da localização do UE 700. O bloco 712 pode corresponder ao bloco 224A na Figura 2A ou ao bloco 232B na Figura 2B. Os blocos 708 a 712 são mostrados como opcionais e podem não ser realizados se o SP OTT 750 receber um LbyV em 706.

[0156] Após 712, se uma localização só foi devolvida para o UE 700 em 712, o SP OTT 750 determina o PSAP de destino com o uso da localização de UE (por exemplo, com o uso de uma consulta de LoST - não mostrada na Figura 7. De outro modo, o SP OTT 750 pode usar quaisquer informações de roteamento devolvidas em 712 para determinar o PSAP. Quando o SP OTT 750 determinar um PSAP herdado 782, o SP OTT 750 pode encaminhar a chamada com o uso de CS enviando-se uma mensagem de ISUP IAM a um SR 763 para o PSAP 782.

[0157] Em 716A, o SR 763 encaminha a chamada ao PSAP herdado 782.

[0158] Em 718A, o restante do estabelecimento de chamada é realizado. Os blocos 714B, 716B e 718B não são realizados então.

[0159] Quando o SP OTT 750 determinar um PSAP de i3 780 em vez de um PSAP herdado 782 após 712, os blocos 714A, 716A e 718A não são realizados. Em vez disso, o SP OTT 750 encaminha a chamada ao ESInet 760 enviando-se um CONVITE DE SIP que contém o LbyV ou o LbyR recebido em 706 e que contém possivelmente qualquer localização para o UE 700 recebido em 712 se o 712 ocorrer.

[0160] Após 714B e antes de 716B, se um LbyR for fornecido em 714B, o ESInet 760 pode consultar o ELS 794 pela localização atual do UE 700 para auxiliar no roteamento (não mostrado na Figura 7). O ESInet 760, então, encaminha a chamada ao PSAP de i3 780 em 716B.

[0161] Em 718B, o restante do estabelecimento de chamada é realizado. Os blocos 714A e 716A e os blocos 714B e 716B podem corresponder ao bloco 226A na Figura 2A, o bloco 234B na Figura 2B ou ao envio de mensagens 403A e 403B, respectivamente, na Figura 4. O bloco 718A e o bloco 718B podem corresponder, cada um, ao bloco 228A na Figura 2A ou ao bloco 236B na Figura 2B.

[0162] Em 720, se um LbyR para o UE 700 foi recebido em 716B, o PSAP de i3 780 desreferencia o LbyR enviando-se uma solicitação de localização ao ELS 794 indicado no LbyR e inclui o LbyR na solicitação. O bloco 720 pode corresponder ao envio da consulta 404B na Figura 4.

[0163] Em 722, o ELS 794 usa as informações incluídas no LbyR recebido em 720 (por exemplo, uma identidade local ou global para o UE 700 e uma ID de MME/SGSN de serviço para a localização do plano de controle ou um endereço de IP de UE local para a localização do plano de usuário) para obter a localização atual do UE 700 - por exemplo, com o uso de um plano de controle ou solução de localização de plano de usuário. O bloco 722 pode ser similar ou igual aos blocos 218A e/ou 222A na Figura 2A ou aos blocos 216B a 226B ou bloco 228B na Figura 2B em termos de determinação de uma localização para o UE 700.

[0164] Em 724, o ELS 794 devolve a localização atual para o UE 700 ao PSAP de i3 780. Os blocos 720 e 724 podem corresponder ao bloco 232A na Figura 2A ou ao bloco 238B na Figura 2B.

[0165] A Figura 8 ilustra um fluxo de chamada exemplificativo para o suporte de LRF de IMS para uma chamada de emergência por meio de um SP OTT conforme descrito acima com referência à Figura 5, de acordo com pelo menos um aspecto da revelação, e pode estender as interações para o suporte de LRF de IMS descrito anteriormente em associação à Figura 5. O fluxo de chamada ilustrado na Figura 8 pode ser realizado com o uso da arquitetura ilustrada na Figura 5, da Figura 3, da Figura 1B ou da Figura 1A. Como uma consequência, o UE 800 na Figura 8 pode corresponder a qualquer um dos UEs 1 a N na Figura 1A, o UE 200, o UE 300 ou o UE 500. De modo similar, o SP OTT 850 pode corresponder ao SP OTT 150, ao SP OTT 350 ou ao SP OTT 550. De modo similar, a AN/PCN 892 pode corresponder à AN 520 mais à porção de PCN do MNO 590, a AN 320 mais PCN 340 ou à AN 120 mais CN 140 e pode incluir o nó de rede de acesso 240. De modo similar, o IMS 894 pode corresponder ao IMS 540, um IMS dentro da PCN 340 ou um IMS dentro da CN 140. De modo similar, o destino de CS intermediário 863 pode corresponder ao SR 563, ao SR 360 ou ao SR 160. De modo similar, o ESInet 860 pode corresponder ao ESInet 560, ao ESInet 360 ou ao ESInet 160. De modo similar, o PSAP de i3 880 pode corresponder ao PSAP de i3 580, ao PSAP 380 ou ao PSAP 180. De modo similar, o PSAP herdado 882 pode corresponder ao PSAP herdado 582, ao PSAP 380 ou ao PSAP 180. De modo similar, o MNO de serviço 890 pode corresponder ao MNO de serviço 590.

[0166] A Figura 9 ilustra um fluxo de chamada exemplificativo para o suporte de E-CSCF de IMS para uma chamada de emergência por meio de um SP OTT conforme descrito acima com referência à Figura 6, de acordo com pelo menos um aspecto da revelação, e pode estender as interações para o suporte de E-CSCF de IMS descrito anteriormente em associação à Figura 6. O fluxo de chamada ilustrado na Figura 9 pode ser realizado com o uso da arquitetura ilustrada na Figura 6, na Figura 3, na Figura 1B ou na Figura 1A. Como uma consequência, o UE 900 na Figura 9 pode corresponder a qualquer um dos UEs 1 a N na Figura 1A, o UE 200, o UE 300 ou o UE 600. De modo similar, o SP OTT 950 pode corresponder ao SP OTT 150, ao SP OTT 350 ou ao SP OTT 650. De modo similar, a AN/PCN 992 pode corresponder à AN 620 mais à porção de PCN do MNO 690, a AN 320 mais PCN 340 ou à AN 120 mais CN 140 e pode incluir o nó de rede de acesso 240. De modo similar, o IMS 994 pode corresponder ao IMS 640, um IMS dentro da PCN 340 ou um IMS dentro da CN 140. De modo similar, o SR 963 pode corresponder ao SR 663, ao SR 360 ou ao SR 160. De modo similar, o ESInet 960 pode corresponder ao ESInet 660, ao ESInet 360 ou ao ESInet 160. De modo similar, o PSAP de i3 980 pode corresponder ao PSAP de i3 680, ao PSAP 380 ou ao PSAP 180. De modo similar, o PSAP herdado 982 pode corresponder ao PSAP herdado 682, ao PSAP 380 ou ao PSAP 180. De modo similar, o MNO de serviço 990 pode corresponder ao MNO de serviço 690.

[0167] Os fluxos de chamada ilustrados nas Figuras 8 e 9 são similares, e a partir da perspectiva de entidades fora do IMS 894/994 (por exemplo, o UE 800/900 e o SP OTT 850/950) podem ser vistos como parte de uma única solução comum. Embora o IMS 894/994 se comporte de modo diferente nos fluxos de chamada nas Figuras 8 e 9, as interações entre o IMS 894/994 e o SP OTT 850/950 em ambos os fluxos de chamada podem estar em conformidade com a definição de IETF do SIP (por exemplo, em RFC de IETF 3261) e pode ser suportada, portanto, por ambos SPs OTT 850/950 que atuam como um proxy de SIP. Nesse caso, o SP OTT 850/950 pode não precisar conhecer de antemão se o MNO de serviço 890/990 (ou o IMS 894/994 no MNO de serviço 890/990) empregará o suporte de LRF de IMS como na Figura 8 ou o suporte de E-CSCF de IMS como na Figura 9. Em vez disso, o SP OTT 850/950 pode simplesmente reagir de acordo com regras de SIP pré-configuradas dependendo de ser p suporte de LRF de IMS ou o suporte de E-CSCF de IMS foi fornecido. Isso pode permitir que o MNO de serviço 890/990 migre do suporte de LRF de IMS para o suporte de E-CSCF de IMS ou vice-versa sem exigir mudanças para o suporte a partir do UE 800/900 ou a partir do SP OTT 850/950. Isso também pode permitir que o SP OTT 850/950 receba o suporte de LRF de IMS de acordo com a Figura 8 a partir de um ou mais MNOs (por exemplo, o MNO 890) e receba o suporte de E- CSCF de IMS de acordo com a Figura 9 a partir de um ou mais outros MNOs (por exemplo, o MNO 990) para chamadas de emergência que podem ser originadas por diferentes UEs (por exemplo, o UE 800 e o UE 900) que acessam o SP OTT 850/950 a partir de um desses MNOs.

[0168] Os fluxos de chamada nas Figuras 8 e 9 se aplicam à solução S1 na Figura 3. Para a solução S2 na Figura 3, os fluxos de chamada podem ser quase os mesmos, exceto que a solicitação de chamada de emergência descrita abaixo em 806/906 em cada fluxo de chamada não incluiria alguns ou todos os dados de UE e/ou dados de MNO. Em vez disso, o SP OTT 850/950 consultaria o UE 800/900 para os dados de UE e/ou os dados de MNO após 806/906 (por exemplo, enviando-se uma INFO de SIP que contém a solicitação ao UE 800/900 e sendo que o UE 800/900 devolve os dados de UE e/ou dados de MNO solicitados em um OK de SIP ou em uma INFO de SIP). Para a solução S2, o SP OTT 850/950 também pode precisar consultar o UE 800/900 para os dados de MNO atualizados que o UE 800/900 envia em 826 na Figura 8 e 112 na Figura 9. Entretanto, essa solicitação pode ser combinada de modo implícito ou explícito com a solicitação (mencionada acima) para os dados de UE e dados de MNO enviados inicialmente ao UE 800/900 após 806/906.

[0169] Além disso, com a solução S2 da Figura 3, o UE 800/900 pode não detectar que o usuário instigou uma chamada de emergência antes de 806/906 nas Figuras 8 e 9 (por exemplo, pode não reconhecer que o usuário discou um número de emergência como "911") e pode enviar uma solicitação de chamada normal ao SP OTT 850/950 em 806/906 nas Figuras 8 e 9 e não uma solicitação de chamada de emergência. O SP OTT 850/950 pode reconhecer, então, que a solicitação de chamada enviada em 806/906 é para uma chamada de emergência (por exemplo, pode detectar que os dígitos discados são para um número de emergência como "911") e pode solicitar dados de MNO e/ou dados de UE a partir do UE 800/900 antes de proceder com 808/908 mostrado nas Figuras 8 e 9. As outras operações nas Figuras 8 e 9 que não são modificados conforme descrito recentemente para a solução S2 da Figura 3 podem ocorrer conforme descrito abaixo.

[0170] As interações mostradas na Figura 8 podem se aplicar a um UE 800 que instiga uma chamada de emergência por meio de um SP OTT 850 em circunstâncias em que o UE 800 acessa um MNO de serviço 890 (por exemplo, acessa o SP OTT 850 por meio do MNO de serviço 890). Em 802 na Figura 8, o UE 800 pode solicitar dados de uma AN ou PCN 892 no MNO de serviço 890 para suportar uma chamada de emergência com o uso de um SP OTT 850. Por exemplo, isso pode ocorrer quando o UE 800 detectar que o usuário instiga uma chamada de emergência. O bloco 802 é opcional e pode nem sempre ocorrer.

[0171] Em 804, em resposta a 802, ou quando certas condições ocorrem (por exemplo, o UE 800 se anexa à AN/PCN 892, realiza uma atualização de área de rastreamento ou área de roteamento a uma nova MME ou SGSN ou a entrega ocorre a uma nova MME ou SGSN), a AN ou PCN 892 envia dados de MNO para o UE 800. Os dados de MNO podem incluir (i) um endereço de IMS para o MNO de serviço 890 (por exemplo, o endereço de uma LRF em IMS 894), (ii) se a localização de plano de controle puder ser usada, uma identidade para uma MME de serviço atual ou SGSN de serviço atual para o UE 800, (iii) se a localização do plano de usuário puder ser usada, um endereço de IP atribuído pelo MNO para o UE 800 e/ou (iv) uma identidade global (por exemplo, IMSI ou MSISDN) para o UE 800 ou uma identidade local para o UE 800 atribuída pela MME de serviço ou SGSN de serviço para o UE 800.

[0172] Em 806, em resposta ao UE 800 detectar que o usuário do UE 800 instigou uma chamada de emergência (por exemplo, se o UE 800 detectar que o usuário discou os dígitos "911"), o UE 800 envia uma solicitação de chamada de emergência ao SP OTT 850 e inclui os Dados de MNO obtidos em 804 e, possivelmente, dados de UE adicionais conhecidos ao UE 800. Os dados de UE podem incluir uma identidade global para o UE 800 (por exemplo, um IMSI ou MSISDN) e possivelmente um endereço de IP atribuído por MNO para o UE 800 se não for recebido em 804. A solicitação de chamada de emergência em 806 pode ser um CONVITE DE SIP ou pode ser uma mensagem para algum outro protocolo específico ao SP OTT 850. O bloco 806 pode corresponder ao envio da solicitação de chamada de emergência 501 na Figura 5.

[0173] Em 808, com base no recebimento de 806 de um endereço de IMS no MNO de serviço 890 (por exemplo, em que o endereço de IMS pode ser parte dos dados de MNO recebidos em 806 e podem ser um endereço de LRF incluído no cabeçalho de Rota de um CONVITE DE SIP enviado em 806), o SP OTT 850 envia um CONVITE DE SIP ao IMS 894 (por exemplo, a uma LRF no IMS 894) indicado pelo endereço de IMS no MNO de serviço 890. O CONVITE DE SIP inclui os dados de MNO e quaisquer dados de UE recebidos em 806, indica uma chamada de emergência e inclui a identidade e possivelmente a localização (por exemplo, país) do SP OTT 850. O CONVITE DE SIP pode ser uma cópia parcial ou completa de qualquer CONVITE DE SIP recebido em 806. O bloco 808 pode corresponder ao envio do CONVITE de SIP 502A na Figura 5.

[0174] Em alguns casos, o CONVITE DE SIP enviado em 808 pode ser recebido primeiro em uma função de controle de borda (por exemplo, um IBCF) no IMS de MNO de serviço 894 para segurança antes de ser encaminhado para uma LRF no IMS 894 (não mostrado na Figura 8). O IMS 894 (por exemplo, uma LRF ou IBCF no IMS 894) pode verificar primeiro que o CONVITE DE SIP enviado em 808 vem de um SP OTT válido, por exemplo, com o uso de dados pré- configurados com base em alguma relação de negócios entre o MNO de serviço 890 e o SP OTT 850, e, possivelmente, com o uso de uma conexão de IP segura entre o SP OTT 850 e o IMS de MNO de serviço 894 para transferir o CONVITE DE SIP em 808. Em alguns casos em 810, o IMS 894 (por exemplo, uma LRF em IMS 894) usa os dados de MNO e quaisquer dados de UE enviados em 808 para obter uma localização para o UE 800, por exemplo, com o uso de um plano de controle ou solução de localização de plano de usuário. Em alguns outros casos, o bloco 810 não ocorre e o IMS 894 podem determinar uma localização (por exemplo, uma localização aproximada) para o UE 900 a partir de outros dados recebidos no CONVITE DE SIP em 808 como um LbyV incluído pelo UE 800 na solicitação de chamada de emergência enviada em 806 e transferida pelo SP OTT 850 ao IMS 894 em 808.

[0175] O IMS 894 (por exemplo, um RDF no IMS 894), então, determina um PSAP de destino 880/882, ou uma rota em direção a um PSAP de destino 880/882, que corresponde à localização para o UE 800 e deriva um URI de roteamento (que também pode ser referido a um URI de rota) para permitir o roteamento de chamada a partir do SP OTT 850 para ou em direção ao PSAP de destino 880/882. O URI de roteamento pode incluir o endereço ou identidade do PSAP 880/882 ou de um destino intermediário 863 (por exemplo, um SR no caso de um PSAP herdado 882 ou um ponto de ingresso a um ESInet 860 para um PSAP com capacidade de i3 880) e pode depender da identidade do SP OTT 850 e/ou a localização do SP OTT 850 (por exemplo, se a localização está no mesmo país que o MNO de serviço 890 ou está em um país diferente). O IMS 894 (por exemplo, uma LRF no IMS 894) também determina um identificador (ID) de referência para permitir uma solicitação de localização subsequente para o UE 800 a partir de um ESInet 860 ou a partir do PSAP 880/882 em um momento posterior. A ID de referência pode ser (i) um ESRK ou (ii) um ESRD mais MSISDN no caso de um PSAP herdado 882, ou pode ser (iii) um URI de localização no caso de um PSAP com capacidade de i3 880.

[0176] Em 812, o IMS 894 (por exemplo, uma LRF no IMS 894) devolve o URI de roteamento e a ID de referência ao SP OTT 850 em uma mensagem de Múltiplas Escolhas de SIP 300. Deve ser observado que o IMS 894 pode não devolver uma localização (por exemplo, LbyV) ao SP OTT 850 se a identidade do SP OTT 850 não estiver completamente validada, ou se a relação de negócios com o SP OTT 850 só possibilita o suporte de roteamento pelo MNO de serviço 890. O bloco 812 pode corresponder ao envio de SIP 300 de Múltiplas Escolhas 502B na Figura 5.

[0177] Em 814, se o IMS 894 (por exemplo, uma LRF no IMS 894) precisar usar a localização de plano de controle, o IMS 894 envia uma mensagem de ASSINATURA DE SIP para o SP OTT 850 para assinar a notificação de mudanças nos dados de MNO (por exemplo, mudança do endereço de MME de serviço ou SGSN de serviço). O IMS 894 também pode enviar uma mensagem de ASSINATURA DE SIP separada para o SP OTT 850 para assinar a notificação de término de chamada (não mostrado na Figura 8).

[0178] Em 816, se 814 ocorrer, o SP OTT 850 devolve 200 uma mensagem de OK (não mostrada na Figura 8) para o IMS 894 e, então, uma mensagem de NOTIFICAR para cada mensagem de ASSINAR recebida que porta os dados de MNO atuais no caso de assinatura aos dados de MNO em 814 e/ou estado de chamada atual no caso de assinatura ao término de chamada.

[0179] Após 812 (e possivelmente após 816, se 816 ocorrer), o SP OTT 850 determina se o PSAP de destino é um PSAP herdado 882 ou um PSAP com capacidade de i3 880 a partir do conteúdo de URI de roteamento ou da ID de referência devolvida em 812. No caso de um PSAP herdado 882, o SP OTT 850 pode encaminhar a chamada com o uso de CS para ou em direção ao PSAP 882. Em uma modalidade, o SP OTT 850 envia uma mensagem de ISUP IAM em 818A a um destino de CS intermediário 863 (por exemplo, um SR) indicado no URI de rota recebido em 812. O SP OTT 850 também inclui qualquer ESRK ou ESRD mais MSISDN na ID de referência recebida em 812 na ISUP IAM. O bloco 818A pode corresponder ao envio da solicitação 503 A na Figura 5.

[0180] Em 820A, o destino de CS intermediário 863 encaminha a chamada ao PSAP herdado 882 e inclui o ESRK ou ESRD mais MSISDN recebido em 818A.

[0181] Em 822A, o restante do estabelecimento de chamada é realizado. Os blocos 818B, 820B e 822B não são realizados então.

[0182] Quando o SP OTT 850 determinar um PSAP de i3 880 em vez de um PSAP herdado 882 após 812, os blocos 818A, 820A e 822A não são realizados. Em vez disso, o SP OTT 850 encaminha a chamada para ou em direção ao PSAP 880. Em uma modalidade, o SP OTT 850 encaminha a chamada em 818B a um ESInet 860 indicado pelo URI de roteamento recebido em 812 enviando-se um CONVITE DE SIP que contém o URI de localização recebido na ID de referência em 812. O bloco 818B pode corresponder ao envio da solicitação 503B na Figura 5.

[0183] Em 820B, o ESInet 860 encaminha a chamada ao PSAP de i3 880 e inclui o URI de localização recebido em 818B.

[0184] Em 822B, o restante do estabelecimento de chamada é realizado.

[0185] Em 824, se houver uma mudança nos dados de MNO (por exemplo, o UE 800 é entregue a uma nova SGSN ou MME) e se o MNO de serviço 890 puder usar a localização de plano de controle para o UE 800, a AN ou PCN 892 envia novos dados de MNO ao UE 800 (por exemplo, a identidade para um novo MME ou SGSN para o UE 800 e uma nova identidade local para o UE 800 no novo MME de serviço ou SGSN). O envio dos novos dados de MNO em 824 pode ser automático sempre que os dados de MNO mudarem (por exemplo, sem conhecimento pelo AN ou PCN 892 no MNO de serviço 890 que uma chamada de emergência para UE 800 por meio de um SP OTT 850 está em progresso), ou pode ser disparado pelo UE 800 que enviou uma solicitação para dados de MNO anteriormente em 802.

[0186] Em 826, o UE 800 encaminha os novos dados de MNO ao SP OTT 850, por exemplo, com o uso de uma mensagem de INFO de SIP quando SIP for usado entre o UE 800 e o SP OTT 850.

[0187] Em 828, se o IMS 894 assinado à notificação de mudanças em dados de MNO em 814, o SP OTT 850 envia os novos dados de MNO ao IMS 894 (por exemplo, uma LRF no IMS 894) em uma mensagem de NOTIFICAR de SIP. Os novos dados de MNO são armazenados para uso futuro pelo IMS 894. Por exemplo, os novos dados de MNO podem ser usados posteriormente no bloco 832A ou no bloco 832B para ajudar a obter uma localização para o UE 800.

[0188] Em 830A, no caso de um PSAP herdado 882, o PSAP 882 ou uma entidade associada ao PSAP 882 como um ALI (por exemplo, o ALI 561) pode enviar uma mensagem de ESPOSREQ de interface de E2 (por exemplo, conforme definido em J-STD-036 de padrão conjunto TIA/ATIS) ao IMS 894 (por exemplo, uma LRF) indicado pelo ESR ou ESRD recebido em 820A para solicitar a localização do UE 800 e inclui o ESRK ou o ESRD mais MSISDN recebido em 820A. O bloco 830A pode corresponder ao envio da consulta 504A na Figura 5.

[0189] Em 832A, o IMS 894 (por exemplo, uma LRF) usa o ESRK ou MSISDN recebido em 830A para identificar o UE 800 e usa quaisquer dados de UE recebidos em 808 e/ou os dados de MNO recebidos em 808 ou 828, se 828 ocorrer, para obter uma localização para o UE 800 com o uso de um plano de controle ou solução de localização de plano de usuário.

[0190] Em 834A, o IMS 894 (por exemplo, uma LRF) devolve a localização ao PSAP 882 (ou a uma entidade associada ao PSAP 882 como um ALI).

[0191] Em 830B, no caso de um PSAP com capacidade de i3 880, o PSAP de i3 880 desreferencia o URI de localização recebido em 820B enviando-se uma solicitação de localização ao IMS 894 (por exemplo, uma LRF no IMS 894) indicado no URI de localização e que porta o Bloco de URL de localização 830B pode corresponder ao envio da consulta 504B na Figura 5.

[0192] Em 832B, o IMS 894 (por exemplo, uma LRF) usa o URI de localização recebido em 830B para identificar o UE 800 e usa quaisquer dados de UE recebidos em 808 e/ou os dados de MNO recebidos em 808 ou 828, se 828 ocorrer, para obter uma localização para o UE 800 com o uso de um plano de controle ou solução de localização de plano de usuário.

[0193] Em 834B, o IMS 894 (por exemplo, uma LRF) devolve a localização ao PSAP 880.

[0194] Os blocos similares ou iguais a 830B, 832B e 834B podem ocorrer após 818B para permitir que o ESInet 860 obtenha uma localização para o UE 800 a partir de IMS 894 (por exemplo, a partir de uma LRF no IMS 894) e, com base na localização, rotear a chamada de emergência em 820B ao PSAP correto 880. Nesse caso, o ESInet 860 (por exemplo, um ESRP no ESInet 860 como ESRP 566) pode enviar uma solicitação de localização para o UE 800 até o IMS 894 em um bloco similar ou igual a 830B e pode receber uma localização para o UE 800 a partir do IMS 894 em um bloco similar ou igual a 834B.

[0195] As interações mostradas na Figura 9 podem se aplicar a um UE 900 que instiga uma chamada de emergência por meio de um SP OTT 850 em circunstâncias em que o UE 900 acessa um MNO de serviço 990 (por exemplo, acessa o SP OTT 850 por meio do MNO de serviço 990). Em 802 na Figura 9, o UE 900 pode solicitar dados de uma AN ou PCN 992 no MNO de serviço 990 para suportar uma chamada de emergência com o uso de um SP OTT 950. Por exemplo, isso pode ocorrer quando o UE 900 detectar que o usuário instiga uma chamada de emergência. A operação 902 é opcional e pode nem sempre ocorrer.

[0196] Em 904, em resposta a 902, ou quando certas condições ocorrem (por exemplo, o UE 900 se anexa à AN/PCN 992, realiza uma atualização de área de rastreamento ou área de roteamento a uma nova MME ou SGSN na AN/PCN 992 ou uma entrega ocorre a uma nova MME ou SGSN), a AN ou PCN 992 envia dados de MNO para o UE 900. Os dados de MNO podem incluir (i) um endereço de IMS para o MNO de serviço 990 (por exemplo, o endereço de um E-CDCF no IMS 994), (ii) se a localização de plano de controle puder ser usada, uma identidade para uma MME de serviço atual ou SGSN de serviço atual para o UE 900, (iii) se a localização do plano de usuário puder ser usada, um endereço de IP atribuído pelo MNO para o UE 900 e/ou (iv) uma identidade global (por exemplo, IMSI ou MSISDN) para o UE 900 ou uma identidade local para o UE 900 atribuída pela MME de serviço ou SGSN para o UE 900.

[0197] Em 906, em resposta ao UE 900 detectar que o usuário do UE 900 instigou uma chamada de emergência (por exemplo, se o UE 900 detectar que o usuário discou os dígitos "911"), o UE 900 envia uma solicitação de chamada de emergência ao SP OTT 950 e inclui os Dados de MNO obtidos em 904 e, possivelmente, dados de UE adicionais conhecidos ao UE 900. Os dados de UE podem incluir uma identidade global para o UE 900 (por exemplo, um IMSI ou MSISDN) e possivelmente um endereço de IP atribuído por MNO para o UE 900 se não for recebido em 904. A solicitação de chamada de emergência em 906 pode ser um CONVITE DE SIP ou pode ser uma mensagem para algum outro protocolo específico ao SP OTT 950. O bloco 906 pode corresponder ao envio da solicitação de chamada de emergência 601 na Figura 6.

[0198] Em 908, com base no recebimento de um endereço de IMS como parte dos dados de MNO recebidos em 906 (por exemplo, em que o endereço de IMS é um endereço de E-CSCF em um cabeçalho de Rota de um CONVITE DE SIP recebido em 906), o SP OTT 950 envia um CONVITE DE SIP ao IMS 994 (por exemplo, a um E-CSCF no IMS 994) indicado pelo endereço de IMS no MNO de serviço 990. O CONVITE DE SIP enviado em 980 inclui os dados de MNO e quaisquer dados de UE recebidos em 906, indica uma chamada de emergência e inclui a identidade e possivelmente a localização (por exemplo, o país) do SP OTT 950. O CONVITE DE SIP enviado em 908 pode ser uma cópia parcial ou completa de qualquer CONVITE DE SIP recebido em 906. O bloco 908 pode corresponder ao envio do CONVITE de SIP 602A na Figura 6.

[0199] Em alguns casos, o CONVITE DE SIP enviado em 908 pode ser recebido primeiro em uma função de controle de borda (por exemplo, um IBCF) no IMS de MNO de serviço 994 para segurança antes de ser encaminhado para um E-CSCF no IMS 994 (não mostrado na Figura 9). O IMS 994 (por exemplo, um E-CSCF ou IBCF no IMS 994) pode verificar que o CONVITE DE SIP enviado em 908 vem de um SP OTT válido 950, por exemplo, com o uso de dados pré-configurados com base em alguma relação de negócios entre o MNO de serviço 990 e o SP OTT 950, e, possivelmente, com o uso de uma conexão de IP segura entre o SP OTT 950 e o IMS de MNO de serviço 994 para transferir o CONVITE DE SIP em 908. Em alguns casos em 910, o IMS 994 (por exemplo, uma LRF em IMS 994) pode usar os dados de MNO e quaisquer dados de UE recebidos em 908 para obter uma localização para o UE 900, por exemplo, com o uso de um plano de controle ou solução de localização de plano de usuário. Em alguns outros casos, o bloco 910 não ocorre e o IMS 994 podem determinar uma localização (por exemplo, uma localização aproximada) para o UE 900 a partir de outros dados recebidos no CONVITE DE SIP em 908 como um LbyV incluído pelo UE 900 na solicitação de chamada de emergência enviada em 906 e transferida pelo SP OTT 950 ao IMS 994 em 908.

[0200] Em 911, que pode seguir 908 ou 910, se 910 ocorrer, o IMS 994 (por exemplo, um RDF no IMS 994) determina um PSAP de destino 980/982, ou uma rota em direção a um PSAP de destino 980/982, correspondente à localização do UE 900 (por exemplo, conforme obtido em 910) e determina um URI de roteamento (também referido como um URI de rota) para permitir o roteamento de chamada a partir do IMS 994 para ou em direção ao PSAP de destino 980/982. O URI de roteamento pode indicar (i) o endereço ou a identidade do PSAP 980/982 ou (ii) o endereço ou a identidade de um destino intermediário como um SR 963 no caso de um PSAP herdado 982 ou um ponto de ingresso a um ESInet 960 no caso de um PSAP com capacidade de i3 980. Como parte da determinação de um PSAP de destino 980/982 em 911, ou uma rota em direção a um PSAP de destino 980/982, o IMS 994 (por exemplo, uma LRF no IMS 994) determina um identificador de referência (ID) para permitir uma solicitação de localização subsequente para o UE 900 a partir de um ESInet 960 ou o PSAP 980/982 em um momento posterior. A ID de referência pode ser (i) um ESR ou (ii) um ESRD mais MSISDN no caso de um PSAP herdado 982, ou (iii) um URI de localização no caso de um PSAP com capacidade de i3 980. O IMS 994 (por exemplo, um E-CSCF no IMS 994) também determina em 911 se o PSAP de destino é um PSAP herdado 982 ou um PSAP com capacidade de i3 980 (por exemplo, a partir do conteúdo do URI de roteamento ou da ID de referência que foi determinada em 911).

[0201] Em algumas implantações, a localização do UE 900 em 910, quando 910 ocorrer, e a determinação de um PSAP de destino, ou uma rota em direção a um PSAP de destino, em 911, que inclui determinar o URI de roteamento e a ID de referência em 911, pode ser realizada por uma LRF (por exemplo, a LRF 648), possivelmente auxiliado por um RDF (por exemplo, o RDF 646), no IMS 994 (por exemplo, se o IMS 994 corresponder ao IMS 640 na Figura 6). Nessas implantações, o CONVITE DE SIP enviado em 908 pode ser recebido por um E-CSCF (por exemplo, o E-CSCF 643) no IMS 994 e, então, encaminhado para a LRF (por exemplo, a LRF 648) no IMS 994 pelo E-CSCF. O LRF (por exemplo, LRF 648) no IMS 994, então, pode obter uma localização para o UE 900 em 910, se 910 ocorrer, determinar um PSAP de destino em 911 que inclui determinar o URI de roteamento e a ID de referência e devolver o URI de roteamento determinado e a ID de referência de volta para o E-CSCF (por exemplo, o E- CSCF 643) no IMS 994 em uma mensagem de Múltiplas Escolhas de SIP 300. Embora não seja mostrado na Figura 9, essa interação entre um E-CSCF (por exemplo, E-CSCF 643) e uma LRF (por exemplo, a LRF 648) no IMS 994 pode corresponder ao envio da solicitação 603A e a resposta 603B entre E-CSCF 643 e LRF 648 que forma descritos em associação com a Figura 6.

[0202] No caso da determinação de um PSAP herdado 982 em 911, o IMS 994 (por exemplo, um MGCF no IMS 994) pode encaminhar a chamada com o uso de CS em 912A para ou em direção ao PSAP 982. Em uma modalidade, o IMS 994 envia uma mensagem de ISUP I AM em 912A para um SR 963 indicado no URI de roteamento determinado após 908 ou 910 (se 910 ocorrer). O IMS 994 também inclui no ISUP I AM qualquer ESR ou ESRD mais MSISDN indicado na ID de referência determinada em 911.

[0203] Em 914A, o SR 963 encaminha a chamada ao PSAP herdado 982 e inclui o ESRK ou ESRD mais MSISDN recebido em 912A.

[0204] Em 916A, o restante do estabelecimento de chamada é realizado entre o UE 900, o SP OTT 950, o IMS 994, o SR 963 e o PSAP herdado 982. Os blocos 912B, 914B e 916B não são realizados então.

[0205] Quando o IMS 994 determinar um PSAP de i3 980 em vez de um PSAP herdado 982 em 911, os blocos 912A, 914A e 916A não são realizados. Em vez disso, em 912B, o IMS 994 (por exemplo, um E-CSCF no IMS 994) encaminha a chamada de emergência para ou em direção ao PSAP 980. Em uma modalidade, o IMS 994 encaminha a chamada de emergência para um ESInet 960 indicado pelo URI de roteamento determinado em 911 enviando-se um CONVITE DE SIP que contém o URI de localização a partir da ID de referência determinada em 911.

[0206] Em 914B, o ESInet 960 encaminha a chamada de emergência ao PSAP de i3 980 e inclui o URI de localização recebido em 912B.

[0207] Em 916B, o restante do estabelecimento de chamada é realizado entre o UE 900, o SP OTT 950, o IMS 994, o ESInet 960 e o PSAP de i3 980.

[0208] Em 918, se houver uma mudança nos dados de MNO (por exemplo, o UE 900 é entregue a uma nova SGSN ou MME no MNO de serviço 990) e se o MNO de serviço 990 puder usar a localização de plano de controle para o UE 900, a AN ou PCN 992 fornece novos dados de MNO ao UE 900 (por exemplo, a identidade para um novo MME de serviço ou novo SGSN de serviço para o UE 900 e uma identidade local para o UE 900 no novo MME de serviço ou SGSN). O envio desses novos dados de MNO pode ser automático sempre que os dados de MNO mudarem (por exemplo, sem conhecimento pelo AN ou PCN 992 no MNO de serviço 990 que uma chamada de emergência para UE 900 por meio de um SP OTT 950 está em progresso), ou pode ser disparado pelo UE 900 que enviou uma solicitação anteriormente em 902.

[0209] Em 920, o UE 900 encaminha os novos dados de MNO ao SP OTT 950, por exemplo, com o uso de uma mensagem de INFO de SIP quando SIP for usado entre o UE 900 e o SP OTT 950.

[0210] Em 922, o SP OTT 950 encaminha os novos dados de MNO para o IMS 994 (por exemplo, para um E-CSCF no IMS 994), por exemplo, com o uso de uma mensagem de INFO de SIP. Os dados de MNO são armazenados para uso futuro pelo IMS 994 (por exemplo, por uma LRF no IMS 994).

[0211] Em 924A, no caso de um PSAP herdado 982, o PSAP 982 ou uma entidade associada ao PSAP 982 (por exemplo, um ALI como o ALI 661) pode enviar uma mensagem de ESPOSREQ de interface de E2 (por exemplo, conforme definido em J-STD-036 padrão TIA/ATIS) ao IMS 994 (por exemplo, uma LRF no IMS 994) conforme indicado pelo ESR ou ESRD recebido em 914A para solicitar a localização do UE 900 e inclui o ESRK ou o ESRD mais MSISDN recebido em 914A. O bloco 924A pode corresponder ao envio da solicitação de localização 605A na Figura 6.

[0212] Em 926A, o IMS 994 (por exemplo, uma LRF no IMS 994) usa o ESRK ou MSISDN recebido em 924A para identificar o UE 900 e usa quaisquer dados de UE recebidos em 908 e/ou os dados de MNO recebidos em 908 ou 922, se 922 ocorrer, para obter uma localização para o UE 900 com o uso de um plano de controle ou solução de localização de plano de usuário.

[0213] Em 928A, o IMS 994 (por exemplo, uma LRF no IMS 994) devolve a localização para o UE 900 ao PSAP herdado 982 (ou a uma entidade associada ao PSAP 982 como um ALI).

[0214] Em 924B, no caso de um PSAP com capacidade de i3 980, o PSAP de i3 980 desreferencia o URI de localização recebido em 914B enviando-se uma solicitação de localização ao IMS 994 (por exemplo, uma LRF no IMS 994) indicado no URI de localização e que executa o URI de localização. O bloco 924B pode corresponder ao envio da solicitação de localização 605B na Figura 6.

[0215] Em 926B, o IMS 994 (por exemplo, uma LRF no IMS 994) usa o URI de localização recebido em 924B para identificar o UE 900 e usa quaisquer dados de UE recebidos em 908 e/ou os dados de MNO recebidos em 908 ou 922, se 922 ocorrer, para obter uma localização para o UE 900 com o uso de um plano de controle ou solução de localização de plano de usuário.

[0216] Em 928B, o IMS 994 (por exemplo, uma LRF no IMS 994) devolve a localização para o UE 900 ao PSAP com capacidade de i3 980.

[0217] Os blocos similares ou iguais a 924B, 926B e 928B podem ocorrer após 912B para permitir que o ESInet 960 obtenha uma localização para o UE 900 a partir de IMS 994 (por exemplo, a partir de uma LRF no IMS 994) e, com base na localização, rotear a chamada de emergência em 914B ao PSAP correto 980. Nesse caso, o ESInet 960 (por exemplo, um ESRP no ESInet 860 como ESRP 666) pode enviar uma solicitação de localização para o UE 900 até o IMS 994 em um bloco similar ou igual a 924B e pode receber uma localização para o UE 900 a partir do IMS 994 em um bloco similar ou igual a 928B.

[0218] Deve ser observado que o procedimentos e as técnicas descritos em associação com Figuras 4 a 9 pode ter base no UE que instigou a chamada de emergência que envia quaisquer atualizações a um LbyR (por exemplo, para as Figuras 4 e 7) ou quaisquer atualizações a dados de MNO (por exemplo, como em 826 na Figura 8 e 112 na Figura 9) ao SP OTT para o UE para permitir que o SP OTT encaminhe a atualização a um PSAP ou a uma entidade de IMS, como uma LRF (por exemplo, como em 828 na Figura 8) ou um E-CSCF (por exemplo, como em 922 na Figura 9). Entretanto, em modalidades alternativas, um LbyR atualizado ou dados de MNO atualizados (por exemplo, que pode resultar após o UE que instigou a chamada de emergência é entregue a uma nova SGSN ou novo MME) pode ser enviado a um PSAP ou a uma entidade de IMS no MNO de serviço (como uma LRF ou E-CSCF) pela AN ou PCN no MNO de serviço (por exemplo, por um MME ou SGSN na AN ou PCN) ao invés de pelo UE. Isso pode ocorrer, por exemplo, se uma entidade de IMS no MNO de serviço para o UE que instigou a chamada de emergência ou uma entidade associada a isso (por exemplo, um GMLC) envia uma solicitação para qualquer LbyR atualizado ou Dados de MNO atualizados a uma entidade no AN de MNO de serviço ou PCN (por exemplo, a um MME ou SGSN) depois de detectar que o UE instiga uma chamada de emergência (por exemplo, após 708, 808 e 908 em cada uma das Figuras 7, 8 e 9, respectivamente). Com essas modalidades alternativas, o LbyR atualizado ou os dados de MNO atualizados podem não precisar ser enviados pelo UE que instigou a chamada de emergência ao SP OTT e pelo SP OTT a um PSAP ou a uma entidade de IMS como uma LRF ou E-CSCF.

[0219] A Figura 10 ilustra diversos componentes exemplificativos (representados por blocos correspondentes) que podem ser incorporados em um aparelho 1002, um aparelho 1004 e um aparelho 1006 (correspondente, por exemplo, a um dispositivo de usuário, como o UE 200, 300, 400, 500, 600, 700, 800 ou 900, um nó de rede de acesso, como o nó de rede de acesso 240 e uma entidade de rede, como o SP OTT 150, o servidor de localização 170, etc., respectivamente) para suportar as operações conforme ensinado no presente documento. Será observado que esses componentes podem ser implantados em tipos diferentes de aparelhos em implantações diferentes (por exemplo, em um ASIC, em um SoC, etc.). Os componentes ilustrados também podem ser incorporados em outros aparelhos em um sistema de comunicação. Por exemplo, outros aparelhos em um sistema podem incluir componentes semelhante àqueles descritos para fornecer funcionalidade semelhante. Ademais, um determinado aparelho pode conter um ou mais dentre os componentes. Por exemplo, um aparelho pode incluir múltiplos componentes de transceptor que permitem que o aparelho opere em múltiplas portadoras e/ou se comunique por meio de tecnologias diferentes.

[0220] O aparelho 1002 e o aparelho 1004 incluem, cada um, pelo menos um dispositivo de comunicação sem fio (representado pelos dispositivos de comunicação 1008 e 1014 (e o dispositivo de comunicação 1020 se o aparelho 1004 for uma retransmissão)) para comunicação com outros nós por meio de pelo menos uma RAT designada. Cada dispositivo de comunicação 1008 inclui pelo menos um transmissor (representado pelo transmissor 1010) para transmitir e codificar sinais (por exemplo, mensagens, indicações, informações e assim por diante) e pelo menos um receptor (representado pelo receptor 1012) para receber e decodificar sinais (por exemplo, mensagens, indicações, informações, pilotos, e assim por diante). De modo semelhante, cada dispositivo de comunicação 1014 inclui pelo menos um transmissor (representado pelo transmissor 1016) para transmitir sinais (por exemplo, mensagens, indicações, informações, pilotos, e assim por diante) e pelo menos um receptor (representado pelo receptor 1018) para receber sinais (por exemplo, mensagens, indicações, informações, e assim por diante). Se o aparelho 1004 for uma estação de retransmissão, cada dispositivo de comunicação 1020 pode incluir pelo menos um transmissor (representado pelo transmissor 1022) para transmitir sinais (por exemplo, mensagens, indicações, informações, pilotos, e assim por diante) e pelo menos um receptor (representado pelo receptor 1024) para receber sinais (por exemplo, mensagens, indicações, informações, e assim por diante).

[0221] Um transmissor e um receptor podem compreender um dispositivo integrado (por exemplo, incorporado como um circuito transmissor e um circuito receptor de um único dispositivo de comunicação) em algumas implantações, podem compreender um dispositivo transmissor separado e um dispositivo receptor separado em algumas implantações, ou podem ser incorporados em outras formas em outras implantações. Um dispositivo de comunicação sem fio (por exemplo, um dos múltiplos dispositivos de comunicação sem fio) do aparelho 1004 também podem compreender um Módulo de Escuta de Rede (NLM) ou similares para realizar diversas medições.

[0222] O aparelho 1006 (e o aparelho 1004 se o mesmo não for uma estação de relé) inclui pelo menos um dispositivo de comunicação (representado pelo dispositivo de comunicação 1026 e, opcionalmente, 1020) para se comunicar com outros nós. Por exemplo, o dispositivo de comunicação 1026 pode compreender uma interface de rede que é configurada para se comunicar com uma ou mais entidades de rede por meio de uma conexão ponto-a-ponto com base em fio ou sem fio. Em alguns aspectos, o dispositivo de comunicação 1026 pode ser implantado como um transceptor configurado para suportar comunicação de sinal com base em fio ou sem fio. Essa comunicação pode envolver, por exemplo, enviar e receber: mensagens, parâmetros, ou outros tipos de informações. Consequentemente, no exemplo da Figura 10, o dispositivo de comunicação 1026 é mostrado como compreendendo um transmissor 1028 e um receptor 1030. De modo similar, se o aparelho 1004 não for uma estação de relé, o dispositivo de comunicação 1020 pode compreender uma interface de rede que é configurada para se comunicar com uma ou mais entidades de rede por meio de uma conexão ponto-a-ponto com base em fio ou sem fio. Como com o dispositivo de comunicação 1026, o dispositivo de comunicação 1020 é mostrado como compreendendo um transmissor 1022 e um receptor 1024.

[0223] Os aparelhos 1002, 1004 e 1006 também incluem outros componentes que podem ser usados em conjunto com o SP OTT e operações relacionadas à localização de UE conforme ensinado no presente documento. O aparelho 1002 inclui um sistema de processamento 1032 e um módulo de posicionamento 1054 para fornecer funcionalidade relacionada, por exemplo, a operações do dispositivo de usuário para suportar SP OTT e operações relacionadas à localização de UE conforme ensinado no presente documento, e para fornecer outra funcionalidade de processamento. O aparelho 1004 inclui um sistema de processamento 1034 e um módulo de posicionamento 1056 para fornecer funcionalidade relacionada, por exemplo, a operações do nó de rede de acesso para suportar SP OTT e operações relacionadas à localização de UE conforme ensinado no presente documento, e para fornecer outra funcionalidade de processamento. O aparelho 1006 inclui um sistema de processamento 1036 e um módulo de posicionamento 1058 para fornecer funcionalidade relacionada, por exemplo, a operações da rede para suportar SP OTT e operações relacionadas à localização de UE conforme ensinado no presente documento, e para fornecer outra funcionalidade de processamento.

[0224] Os aparelhos 1002, 1004 e 1006, incluem adicionalmente componentes de memória 1038, 1040 e 1042 (por exemplo, cada um inclui um dispositivo de memória), respectivamente, para manter informações (por exemplo, informações indicativas de recursos reservados, limiares, parâmetros, e assim por diante). Além disso, os aparelhos 1002, 1004 e 1006 incluem dispositivos de interface de usuário 1044, 1046 e 1048, respectivamente, para fornecer indicações (por exemplo, indicações audíveis e/ou visuais) para um usuário e/ou para receber entrada de usuário (por exemplo, mediante atuação de usuário de um dispositivo de captação tal como um teclado, uma tela sensível ao toque, um microfone, e assim por diante).

[0225] Para conveniência, os aparelhos 1002, 1004 e/ou 1006 são mostrados na Figura 10 como incluindo diversos componentes que podem ser configurados de acordo com os diversos exemplos descritos no presente documento. Será observado, entretanto, que os blocos ilustrados podem ter funcionalidade diferente em modelos diferentes.

[0226] Os componentes da Figura 10 podem ser implantados em várias formas. Em algumas implantações, os componentes da Figura 10 podem ser implantados em um ou mais circuitos tais como, por exemplo, um ou mais processadores e/ou um ou mais ASICs (que podem incluir um ou mais processadores). Aqui, cada circuito pode usar e/ou incorporar pelo menos um componente de memória para armazenar informações ou código executável usados pelo circuito para fornecer essa funcionalidade. Por exemplo, parte ou todas dentre as funcionalidades representadas pelos blocos 1008, 1032, 1038, 1044 e 1054 podem ser implantadas pelo componente de processador e memória (ou componentes de processador e memória) do aparelho 1002 (por exemplo, pela execução de código apropriado e/ou pela configuração apropriada de componentes de processador). De modo semelhante, parte ou todas dentre as funcionalidades representadas pelos blocos 1014, 1020, 1034, 1040, 1046 e 1056 podem ser implantadas pelo componente de processador e memória (ou componentes de processador e memória) do aparelho 1004 (por exemplo, pela execução de código apropriado e/ou pela configuração apropriada de componentes de processador). Também, parte ou todas dentre as funcionalidades representadas pelos blocos 1026, 1036, 1042, 1048 e 1058 podem ser implantadas pelo componente de processador e memória (ou componentes de processador e memória) do aparelho 1006 (por exemplo, pela execução de código apropriado e/ou pela configuração apropriada de componentes de processador). Por exemplo, os módulos de posicionamento 1054, 1056 e 1058 podem ser módulos executáveis armazenados na memória, ou podem ser componentes de hardware/firmware acoplados aos sistemas de processamento 1032, 1034 e 1036.

[0227] A Figura 11 é um diagrama de blocos que ilustra componentes exemplificativos de um UE 1100 de acordo com pelo menos um aspecto da revelação. O UE 1100 pode corresponder ou representar qualquer um dos UEs 1 a N na Figura 1A, o UE 200, o UE 300, o UE 400, o UE 500, o UE 600, o UE 700, o UE 800 ou o UE 900. Os diversas recursos e funções ilustrados no diagrama de caixas da Figura 11 podem ser conectados juntos com o uso de um barramento comum (não mostrado na Figura 11) ou podem ser conectados (conforme mostrado na Figura 11) por meio do processador (ou processadores) 1130. As pessoas versadas na técnica reconhecerão que outras conexões, mecanismos, recursos, funções, ou similares, podem ser fornecidos e adaptados conforme necessário para se acoplar de modo operativo e configurar um dispositivo sem fio portátil real. Adicionalmente, também é reconhecido que um ou mais dos recursos ou funções ilustrados no exemplo da Figura 11 podem ser subdivididos ainda mais ou dois ou mais dos recursos ou funções ilustrados na Figura 11 podem ser combinados.

[0228] O UE 1100 pode incluir um ou mais transceptores Bluetooth 1114a que podem ser conectados a uma ou mais antenas 1112. O transceptor Bluetooth 1114a compreende dispositivos, hardware e/ou software adequados para se comunicar e/ou detectar sinais para/a partir do ponto de acesso Bluetooth (por exemplo, AP 125 na Figura 1A). Adicional ou alternativamente, o UE 1100 pode incluir um ou mais transceptores sem fio de rede de área ampla (WAN) 1114b que podem ser conectados a uma ou mais antenas 1112. O transceptor (ou transceptores) de WAN 1114b compreende dispositivos, hardware e/ou software adequados para se comunicar e/ou detectar sinais para/a partir de WAPs de WAN (pontos de acesso sem fio), e/ou diretamente com outros dispositivos sem fio dentro de uma rede (por exemplo, dispositivos na RAN 120 na Figura 1A). Em um aspecto, o transceptor (ou transceptores) de WAN 1114b pode ser adequado para se comunicar com um sistema de LTE, sistema de WCDMA, sistema de CDMA2000, TDMA, GSM ou qualquer outro tipo de tecnologias de rede sem fio de área ampla. Adicional ou alternativamente, o UE 1100 pode incluir um ou mais transceptores de WLAN 1114c que podem ser conectados a uma ou mais antenas 1112. O transceptor (ou transceptores) de WLAN 1114c compreende dispositivos, hardware e/ou software adequados para se comunicar e/ou detectar sinais para/a partir de WAPs de WLAN, e/ou diretamente com outros dispositivos sem fio dentro de uma rede (por exemplo, um AP de WiFi 125 na Figura 1A). Em um aspecto, o transceptor (ou transceptores) de WLAN 1114c pode compreender um sistema de comunicação de Wi-Fi (802.11x) adequado para se comunicar com um ou mais pontos de acesso sem fio; entretanto em outros aspectos, o transceptor de WLAN 1114c pode compreender outro tipo de rede de área local ou rede de área pessoal. Adicional ou alternativamente, o UE 1100 pode incluir um receptor de SPS 1114d. O receptor de SPS 1114d pode ser conectado às uma ou mais antenas 1112 para receber sinais de satélite (por exemplo, para o GPS ou algum outro GNSS). O receptor de SPS 1114d pode compreender qualquer hardware e/ou software adequado para receber e processar sinais de SPS. O receptor de SPS 1114d solicita informações e operações conforme apropriado a partir dos outros sistemas, e realiza os cálculos necessários para determinar a posição para o dispositivo móvel 1100 com o uso de medições obtidas por qualquer algoritmo de SPS adequado. Adicional ou alternativamente, qualquer outro tipo de tecnologias de rede sem fio pode ser usado, por exemplo, Ultra Banda Larga, ZigBee, USB sem fio, etc.

[0229] O UE 1100 pode incluir um ou mais sensores 1120. Os um ou mais sensores 1120 podem coletar dados sobre o usuário, o que inclui dados sobre a posição, movimento, orientação, ambiente, atividade ou biometria do usuário. Os sensores podem incluir, por exemplo, sensores virtuais como um pedômetro 1122a e sensores físicos como um acelerômetro 1122b, um giroscópio 1122c, um sensor biométrico 1120d e/ou qualquer quantidade de sensores mistos 1122n (por exemplo, termômetro, barômetro, higrômetro).

[0230] O UE 1100 inclui um ou mais processadores 1130. O processador (ou processadores) 1130 pode ser conectado ao transceptor (ou transceptores) Bluetooth 1114a, ao transceptor (ou transceptores) de WAN 1114b, ao transceptor (ou transceptores) de WLAN 1114c, ao receptor de SPS 1114d e aos um ou mais sensores 1120. O processador 1130 pode ser um processador com múltiplos núcleos e, embora ilustrado como uma unidade única, pode incluir um ou mais microprocessadores, microcontroladores e/ou processadores de sinal digital que fornecem funções de processamento, assim como outra funcionalidade de cálculo e controle.

[0231] O processador (ou processadores) 1130 pode ser acoplado à memória 1140, que armazena dados e instruções de software para executar a funcionalidade programada dentro do UE 1100. A memória 1140 pode ser embutida no processador (ou processadores) 1130 (por exemplo, dentro do mesmo pacote de circuitos integrado) e/ou a memória 1140 pode ser uma memória externa ao processador (ou processadores) 1130 e acoplada de modo funcional sobre um barramento de dados. A memória 1140 pode incluir qualquer quantidade de módulos de aplicação nativos 1142a...1142n e uma quantidade de módulos abastecidos externamente por atualização sem fio ou quaisquer outros meios e qualquer quantidade de módulos de dados 1144a...1144n. Deve ser observado que a organização do conteúdo de memória conforme mostrado na Figura 11 é meramente exemplificativo, e tal funcionalidade dos módulos e/ou estruturas de dados pode ser combinada, separada e/ou ser estruturada de modos diferentes dependendo da implantação do UE 1100. A memória 1140 pode armazenar o código de programa (por exemplo, em um ou mais dos módulos de aplicação 1142a a 1142n) que podem ser executados no processador (ou processadores) 1130 para permitir que o UE 1100 realize alguns ou todos os diversos procedimentos e técnicas descritos no presente documento.

[0232] O UE 1100 também pode incluir um módulo de posicionamento 1180 configurado para realizar operações do dispositivo de usuário para suportar localização relacionada ao SP OTT e ao UE, conforme descrito no presente documento. O módulo de posicionamento 1180 pode ser um módulo executável armazenado na memória 1140 e executado no processador (ou processadores) 1130, ou pode ser um componente de hardware ou firmware acoplado ao processador (ou processadores) 1130.

[0233] Embora os módulos mostrados na Figura 11 sejam ilustrados no exemplo como estando contidos na memória 1140, é reconhecido que, em certas implantações, tais procedimentos podem ser fornecidos para ou dispostos operacionalmente de outro modo com o uso outros mecanismos ou mecanismos adicionais. Por exemplo, qualquer um dos módulos de aplicação 1142a...1142n pode ser fornecido em firmware. O processador (ou processadores) 1130 pode incluir qualquer forma de lógica adequada para realizar pelo menos as técnicas fornecidas no presente documento. Por exemplo, o processador (ou processadores) 1130 pode ser configurável de modo operacional com base em instruções na memória 1140 para iniciar de modo seletivo uma ou mais rotinas que exploram os dados de movimento para uso em outras porções do UE 1100.

[0234] O UE 1100 pode incluir uma interface de usuário 1150 que fornece quaisquer sistemas de interface adequados, como um microfone/viva-voz 1152, um touchpad 1153, um teclado numérico 1154, um visor 1156, uma câmera 1158 e sensores de proximidade 1159 que permitem a interação do usuário com o UE 1100. O microfone/viva-voz 1152 possibilita o reconhecimento de voz e/ou serviços de comunicação de voz com o uso do transceptor (ou transceptores) de WAN 1114b e/ou do transceptor (ou transceptores) de WLAN 1114c. O teclado numérico 1154 compreende quaisquer botões adequados para a entrada de usuário. O visor 1156 compreende qualquer visor adequado, como, por exemplo, um visor de LCD de contraluz, e pode incluir adicionalmente um visor de tela sensível ao toque para modos de entrada de usuário adicionais. Ademais, qualquer funcionalidade de entrada como a funcionalidade demonstrada pelo microfone/viva-voz 1152, pela câmera 1158 ou pelo teclado numérico 1154 também pode ser considerada uma entrada de sensor análoga às entradas dos um ou mais sensores 1120.

[0235] O UE 1100 inclui adicionalmente uma fonte de alimentação 1160, por exemplo, uma bateria, para abastecer potência aos diversos componentes do UE 1100. Entretanto, será apreciado que o UE 1100 pode não incluir todos os elementos ilustrados e mais provavelmente incluirá apenas um subconjunto de elementos com base nas exigências do dispositivo e considerações de projeto.

[0236] Conforme observado acima, os um ou mais sensores 1120 podem colear dados sobre o usuário, o que inclui dados sobre a posição, orientação, movimento, ambiente, atividade ou biometria do usuário. Os sensores podem incluir, por exemplo, um pedômetro 1122a (que pode ser um dispositivo discreto ou um módulo funcional com base em dados provenientes de outros sensores), um acelerômetro 1122b, um giroscópio 1122c, um sensor biométrico 1120d e/ou qualquer quantidade de sensores mistos 1122n. Ademais, os transceptor (ou transceptores) Bluetooth 1114a, o transceptor (ou transceptores) de WAN 1114b, o transceptor (ou transceptores) de WLAN 1114c e/ou o receptor de SPS 1114d podem ser utilizados como sensores à medida em que os mesmos podem ser usados para gerar dados sobre a posição, movimento, ambiente e/ou atividade do usuário. Consequentemente, quando a presente revelação se referir aos um ou mais sensores 1120 em geral, ou a leituras de sensores ou dados de sensor, deve ser entendido que o transceptor (ou transceptores) Bluetooth 1114a, o transceptor (ou transceptores) de WAN 1114b, o transceptor (ou transceptores) de WLAN 1114c e/ou o receptor de SPS 1114d podem ser considerados sensores, e os dados obtidos a partir dos mesmos podem ser considerados leituras de sensores ou dados de sensor.

[0237] Em uma modalidade, o sensor biométrico 1122d inclui um sensor para identificar um usuário. Por exemplo, o sensor biométrico 1122d pode ser um sensor para reconhecimento de voz, reconhecimento de digital, reconhecimento de impressão de palma da mão, reconhecimento de face ou reconhecimento de íris. O sensor biométrico 1122d pode ser um sensor dedicado projetado especificamente para reconhecimento de voz, reconhecimento de digital, reconhecimento de impressão de palma da mão, reconhecimento de face e/ou reconhecimento de íris. Em outro cenário possível, o microfone/viva-voz 1152 é usado como um sensor para reconhecimento de voz. Em outro cenário possível, o teclado numérico 1154 é usado como um sensor para reconhecimento de digital e/ou reconhecimento de impressão de palma da mão. Em ainda outro cenário possível, a câmera 1158 é usada como um sensor para o reconhecimento de face e/ou o reconhecimento de íris.

[0238] Conforme observado acima, o processador (ou processadores) 1130 pode ser acoplado à memória 1140, que armazena dados e instruções de software para executar a funcionalidade programada dentro do UE 1100. A memória 1140 pode incluir qualquer quantidade de módulos de aplicação 1142a...1142n e qualquer quantidade de módulos de dados 1144a... l l44n. Em uma modalidade, um ou mais dos módulos de aplicação 1142a... l l42n, por exemplo, o módulo de aplicação 1142a, utiliza dados detectados reunidos a partir de um ou mais dentre o pedômetro 1122a, o acelerômetro 1122b, o giroscópio 1122c, sensores biométricos 1120d e/ou sensores mistos 1122n. Os dados detectados podem ser armazenados em um ou mais dentre os módulos de dados 1144a... módulo de dados 1144n, por exemplo, o módulo de dados 1144a.

[0239] Consequentemente, uma modalidade da revelação pode incluir um UE (por exemplo, o UE 1100) que inclui a capacidade de realizar as funções descritas no presente documento. Conforme será entendido por aqueles versados na técnica, os vários elementos lógicos podem ser incorporados em elementos distintos, módulos de software executados em um processador ou qualquer combinação de software e hardware para alcançar a funcionalidade revelada no presente documento. Por exemplo, o processador 1130, a memória 1140, a interface de usuário 1150 e o módulo de posicionamento 1180 podem, todos, ser usados cooperativamente para carregar, armazenar e executar as várias funções reveladas no presente documento e, desse modo, a lógica para realizar essas funções pode ser distribuída sobre vários elementos. Alternativamente, a funcionalidade pode ser incorporada em um componente distinto. Portanto, os recursos do UE 1100 na Figura 11 devem ser considerados simplesmente como ilustrativos e a revelação não se limita aos recursos ou disposição ilustrados.

[0240] A comunicação sem fio entre o UE 1100 e a RAN 120/MME 120 pode ter base em diferentes tecnologias, tal como LTE, CDMA, W-CDMA, acesso múltiplo por divisão de tempo (TDMA), acesso múltiplo por divisão de frequência (FDMA), multiplexação de divisão de frequência ortogonal (OFDM), GSM, ou outros protocolos que podem ser usados em uma rede de comunicações sem fio ou uma rede de comunicações de dados. Conforme discutido no supracitado, e conhecido na técnica, transmissão e/ou dados de voz podem ser transmitidos aos UEs 1100 a partir da RAN 120 com o uso de uma variedade de redes e configurações. Em conformidade, as ilustrações fornecidas no presente documento não se destinam a limitar as modalidades da revelação e são meramente para auxiliar na descrição de aspectos de modalidades da revelação.

[0241] A Figura 12 ilustra um dispositivo de comunicação 1200 que inclui componentes estruturais para realizar funcionalidade. O dispositivo de comunicação 1200 pode corresponder a qualquer um dos dispositivos de comunicação observados acima, incluindo, mas não imitado ao UE 1100, qualquer componente da RAN 120 (por exemplo, os eNodeBs 122 a 126), qualquer componente da rede principal 140 (por exemplo, a MME 142 ou 144, o E-SMLC 172, a S-GW 146, a PDG 148, o ELS 370/794, o E-CSCF 443/543/643, a LRF 448/548/648), quaisquer componentes acoplados à rede principal 140 e/ou à Internet 175 (por exemplo, o servidor de localização 170, o GMLC/SLP 170, o ESInet 160, o PSAP 180), e assim por diante. Desse modo, o dispositivo de comunicação 1200 pode corresponder a qualquer dispositivo eletrônico que é configurado para se comunicar com (ou facilitar a comunicação com) uma ou mais outras entidades através do sistema de comunicações sem fio 100A da Figura 1A ou usar a configuração particular 100B da Figura 1B.

[0242] Com referência à Figura 12, o dispositivo de comunicação 1200 inclui um conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205. Em um exemplo, caso o dispositivo de comunicação 1200 corresponda a um dispositivo de comunicações sem fio (por exemplo, o UE 1100, um dos eNBs 122a 126, etc.), o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 pode incluir uma interface de comunicações sem fio (por exemplo, Bluetooth, WiFi, 2G, CDMA, W-CDMA, 3G, 4G, LTE, etc.), tal como um transceptor sem fio e hardware associado (por exemplo, uma antena de RF, um MODEM, um modulador e/ou demodulador, etc.). Em outro exemplo, o conjunto de circuitos de transceptor para receber e/ou transmitir informações 1205 pode corresponder a uma interface de comunicações com fio (por exemplo, uma conexão em série, uma conexão USB ou Firewire, uma conexão por Ethernet através da qual a Internet 175 pode ser acessada, etc.). Dessa forma, se o dispositivo de comunicação 1200 corresponder a algum tipo de servidor com base em rede (por exemplo, a S-GW 146, a PDG 148, a MME 142/144, o E-SMLC 172, o servidor de localização 170, o ELS 370/794, o E-CSCF 443/543/643, a LRF 448/548/648, etc.), o conjunto de circuitos de transceptor configurado para receber e/ou transmitir as informações 1205 pode corresponder a um cartão Ethernet, em um exemplo, que conecta o servidor com base em rede a outras entidades de comunicação por meio de um protocolo de Ethernet. Em um exemplo adicional, o conjunto de circuitos de transceptor para receber e/ou transmitir informações 1205 pode incluir hardware sensorial ou de medição através do qual o dispositivo de comunicação 1200 pode monitorar o próprio ambiente local (por exemplo, um acelerômetro, um sensor de temperatura, um sensor de iluminação, uma antena para monitorar sinais de RF local, etc.). O conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 também pode incluir software que, quando executado, permite que o hardware associado do conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 realize sua função (ou funções) de recebimento e/ou transmissão. Entretanto, o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 não corresponde somente a software, e o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 depende, pelo menos em parte, de hardware estrutura para alcançar a própria funcionalidade.

[0243] Com referência à Figura 12, o dispositivo de comunicação 1200 inclui adicionalmente pelo menos um processador configurado para processar informações 1210. Exemplos de implantações do tipo de processamento que podem ser realizadas por pelo menos um conjunto de circuitos de transceptor configurado para processar informações 1210 incluem, mas sem limitações, realizar determinações, estabelecer conexões, fazer seleções entre diferentes opções de informações, realizar avaliações relacionadas a dados, interagir com sensores acoplados ao dispositivo de comunicação 1200 para realizar operações de medição, converter informações de um formato para outro (por exemplo, entre diferentes protocolos, tal como .wmv para .avi, etc.), e assim por diante. Por exemplo, o pelo menos um processador configurado para processar informações 1210 pode incluir um processador para propósitos gerais, um DSP, um ASIC, uma matriz de porta programável em campo (FPGA) ou outro dispositivo lógico programável, lógica de transistor ou porta distinta, componentes de hardware distintos ou qualquer combinação dos mesmos projetada para realizar as funções descritas no presente documento. Um processador de propósito geral pode ser um microprocessador, mas, na alternativa, o pelo menos um processador configurado para processar as informações 310 pode ser qualquer processador, controlador, microcontrolador ou máquina de estado convencional. Um processador também pode ser implantado como uma combinação dos dispositivos de computação, por exemplo, uma combinação de um DSP e um microprocessador, uma pluralidade de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo de DSP ou qualquer outra configuração. O pelo menos um processador configurado para processar informações 1210 também pode incluir um software que, quando executado, permite que o hardware associado do pelo menos um processador configurado processe informações 1210 para realizar sua função (ou funções) de processamento. Entretanto, o pelo menos um processador configurado para processar informações 1210 não corresponde somente a software, e o pelo menos um processador configurado para processar informações 1210 depende, pelo menos em parte, de hardware estrutural para alcançar a própria funcionalidade.

[0244] Com referência à Figura 12, o dispositivo de comunicação 1200 inclui adicionalmente uma memória configurada para armazenar informações 1215. Em um exemplo, a memória configurada para armazenar informações 1215 pode incluir pelo menos uma memória não transitória e hardware associado (por exemplo, um controlador de memória, etc.). Por exemplo, a memória não transitória incluída na memória configurada para armazenar informações 1215 pode corresponder à memória RAM, à memória flash, à memória de apenas leitura (ROM), à ROM programável apagável (EEPROM), a cadastradores, a um disco rígido, a um disco removível, a um CD-ROM ou a qualquer outra forma de meio de armazenamento conhecido na técnica. A memória configurada para armazenar informações 1215 também pode incluir software que, quando executado, permite que o hardware associado da memória configurada para armazenar informações 1215 realize sua função (ou funções) de armazenamento. Entretanto, a memória configurada para armazenar informações 1215 não corresponde somente a software, e a memória configurada para armazenar informações 1215 depende, pelo menos em parte, de hardware estrutural para alcançar a própria funcionalidade.

[0245] Com referência à Figura 12, o dispositivo de comunicação 1200 inclui adicionalmente, opcionalmente, um conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220. Em um exemplo, o conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 pode incluir pelo menos um dispositivo de saída e hardware associado. Por exemplo, o dispositivo de saída pode incluir um dispositivo de saída de vídeo (por exemplo, uma tela de exibição, uma porta que pode transportar informações de vídeo, tal como USB, HDMI, etc.), um dispositivo de saída de áudio (por exemplo, alto- falantes, uma porta que pode transportar informações de áudio, tal como uma tomada de microfone, USB, HDMI, etc.), um dispositivo de vibração e/ou qualquer outro dispositivo através do qual informações podem ser formatadas para saída ou, de fato, emitidas por um usuário ou operador do dispositivo de comunicação 1200. Por exemplo, caso o dispositivo de comunicação 1200 corresponda ao UE 1100, conforme mostrado na Figura 11, o conjunto de circuitos de saída de interface de usuário configurado para apresentar as informações 1220 pode incluir o visor 1056 e/ou o viva- voz 1052. Em um exemplo adicional, o conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 pode ser omitido para determinados dispositivos de comunicação, como dispositivos de comunicação em rede que não têm um usuário local (por exemplo, comutadores ou roteadores de rede, servidores remotos). O conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 também pode incluir um software que, quando executado, permite que o hardware associado do conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 realize sua função (ou funções) de apresentação. Entretanto, o conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 não corresponde apenas ao software, e o conjunto de circuitos de saída de interface de usuário configurado para apresentar as informações 1220 tem base, pelo menos em parte, em hardware estrutural para alcançar essa funcionalidade.

[0246] Com referência à Figura 12, o dispositivo de comunicação 1200 ainda inclui, opcionalmente, o conjunto de circuitos de entrada de interface de usuário configurado para receber entrada de usuário local 1225. Em um exemplo, o conjunto de circuitos de entrada de interface de usuário configurado para receber a entrada de usuário local 325 pode incluir pelo menos um dispositivo de entrada de usuário e hardware associado. Por exemplo, o dispositivo de entrada de usuário pode incluir botões, um visor de tela sensível ao toque, um teclado, uma câmera, um dispositivo de entrada de áudio (por exemplo, um microfone ou uma porta que pode transportar informações de áudio, tal como uma tomada de microfone, etc.), e/ou qualquer outro dispositivo através do qual informações podem ser recebidas de um usuário ou operador do dispositivo de comunicação 1200. Por exemplo, caso o dispositivo de comunicação 1200 corresponda ao UE 1100, conforme mostrado na Figura 11, o conjunto de circuitos de entrada de interface de usuário configurado para receber entrada de usuário local 1225 pode incluir um touchpad 1153, um teclado numérico 1154, o microfone 1152, etc. Em um exemplo adicional, o conjunto de circuitos de entrada de interface de usuário configurado para receber a entrada de usuário local 1225 pode ser omitido para certos dispositivos de comunicação, como dispositivos de comunicação em rede que não têm um usuário local (por exemplo, comutadores ou roteadores de rede, servidores remotos, etc.). O conjunto de circuitos de entrada de interface de usuário configurado para receber entrada de usuário local 1225 também pode incluir software que, quando executado, permite que o hardware associado do conjunto de circuitos de entrada de interface de usuário configurado para receber entrada de usuário local 1225 realize sua função (ou funções) de recebimento de entrada. No entanto, o conjunto de circuitos de entrada de interface de usuário configurado para receber entrada de usuário local 1225 não corresponde somente a software, e o conjunto de circuitos de entrada de interface de usuário configurado para receber entrada de usuário local 1225 depende, pelo menos em parte, de hardware estrutural para alcançar a própria funcionalidade.

[0247] Com referência à Figura 12, embora os componentes estruturais de 1205 a 1225 sejam mostrados como blocos separados ou distintos na Figura 12, que são acoplados entre si por meio de um barramento de comunicação associado 1230, será apreciado que o hardware e/ou software pelo qual os respectivos componentes estruturais configurados de 1205 a 1225 realiza sua respectiva funcionalidade pode se sobrepor em parte. Por exemplo, qualquer software usado para facilitar a funcionalidade dos componentes estruturais configurados de 305 a 1225 pode ser armazenado na memória não transitória associada à memória configurada para armazenar as informações 1215, de modo que cada um dos componentes estruturais de 1205 a 1225 realize sua respectiva funcionalidade (isto é, nesse caso, execução de software) com base, em parte, na operação de software armazenada pela memória configurada para armazenar as informações 1215. Da mesma forma, o hardware que está diretamente associado a um dos componentes estruturais configurados de 1205 a 1225 pode ser emprestado ou usado por outros componentes estruturais configurados de 1205 a 1225 de tempo em tempo. Por exemplo, o pelo menos um processador configurado para processar informações 1210 pode formatar dados em um formato apropriado antes de serem transmitidos pelo conjunto de circuitos de transceptor configurado para receber e/ou transmitir as informações 1205, de modo que o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 realize sua funcionalidade (isto é, nesse caso, transmissão de dados) com base, em parte, na operação de hardware estrutural associado a pelo menos um processador lógica configurado para processar as informações 1210.

[0248] Consequentemente, os diversos componentes estruturais de 1205 a 1225 estão destinados a invocar um aspecto que é implantado pelo menos parcialmente com hardware estrutural, e não estão destinados a mapear as implantações apenas de software que são independentes de hardware e/ou para interpretações funcionais não estruturais. Outras interações ou cooperação entre os componentes estruturais de 1205 a 1225 ficarão evidentes para uma pessoa de conhecimento comum na técnica a partir de uma revisão das modalidades descritas abaixo em detalhes adicionais.

[0249] As diversas modalidades podem ser implantadas em qualquer dentre uma variedade de dispositivos servidores comercialmente disponíveis, como o servidor 1300 ilustrado na Figura 13. Em um exemplo, o servidor 1300 pode corresponder a uma configuração exemplificativa da MME 142, o SP OTT 150/350/450/550/650/750/850/950, o ESInet 160, o E-SMLC 172, o servidor de localização/GMLC/SLP 170, o ELS 370/794, o E-CSCF 443/543/643, a LRF 448/548/648 e o PSAP 180 descritos acima. Na Figura 13, o servidor 1300 inclui um processador 1301 acoplado à memória volátil 1302 e uma memória não volátil de grande capacidade, tal como uma unidade de disco 1303. O servidor 1300 também pode incluir uma unidade de disquete, unidade de disco compacto (CD) ou DVD 1306 acoplada ao processador 1301. O servidor 1300 também pode incluir portas de acesso à rede 1304 acopladas ao processador 1301 para estabelecer conexões de dados com uma rede 1307, como uma rede de área local acoplada a outros computadores e servidores de sistema de difusão ou à Internet. Em contexto com a Figura 12, será entendido que o servidor 1300 da Figura 13 ilustra um exemplo de implantação do dispositivo de comunicação 1200, através do qual a lógica configurada para transmitir e/ou receber informações 1205 corresponde às portas de acesso à rede 1304 usadas pelo servidor 1300 para se comunicar com a rede 1307, a lógica configurada para processar informações 1210 corresponde ao processador 1301 e a lógica configuração para armazenar informações 1215 corresponde a qualquer combinação da memória volátil 1302, a unidade de disco 1303 e/ou a unidade de disco 1306. A lógica opcional configurada para apresentar informações 1220 e a lógica opcional configurada para receber entrada de usuário local 1225 não são mostradas explicitamente na Figura 13 e podem ou não ser incluídas na mesma. Desse modo, a Figura 13 ajuda a demonstrar que o dispositivo de comunicação 1200 pode ser implantado como um servidor, além de uma implantação de UE, conforme na Figura 11. Consequentemente, uma modalidade da revelação pode incluir um servidor (por exemplo, o servidor 1300) que inclui a capacidade de realizar as funções descritas no presente documento, como as funções descritas com referência à MME 142, ao SP OTT 150, ao ESInet 160, ao E-SMLC 172, ao servidor de localização / GMLC / SLP 170, ao ELS 370/794, ao E-CSCF 443/543/643, à LRF 448/548/648 e ao PSAP 180, por exemplo.

[0250] A Figura 14 ilustra um fluxo exemplificativo para localizar um UE realizado por um nó de rede de acesso que atende ao UE, como qualquer componente da RAN 120 ou da CN 140 nas Figuras 1A e 1B. Por exemplo, o nó de rede de acesso pode corresponder a MME 142.

[0251] Em 1410, o nó de rede de acesso recebe uma primeira mensagem do UE, como em 206A da Figura 2A ou 202B da Figura 2B. Por exemplo, quando o nó de rede de acesso corresponder a uma MME que suporta LTE, as primeiras mensagens podem ser uma Solicitação de Anexação de NAS ou uma Solicitação de Atualização de Área de Rastreamento de NAS. Quando o nó de rede de acesso corresponder a um SGSN que suporta UMTS, a primeira mensagem pode ser uma Solicitação de Anexação de GPRS ou uma Solicitação de Atualização de Área de Roteamento de GPRS.

[0252] Em 1420, o nó de rede de acesso determina uma referência de localização para o UE. A referência de localização pode ser para um servidor de localização, como o servidor de localização 170 na Figura 1A ou o GMLC/SLP 170 na Figura 1B, que pertence a um operador para o nó de rede de acesso, e permite que o UE seja localizado. A referência de localização para o UE pode incluir o endereço do servidor de localização e uma referência de UE do UE. A referência de UE pode ser atribuída pelo servidor de localização e pode incluir um endereço de IP, um IMSI, um TMSI, um endereço do nó de rede de acesso, ou qualquer combinação dos mesmos. A referência de UE também pode ser cifrada.

[0253] Conforme discutido acima com referência a 208A da Figura 2A ou 204B da Figura 2B, a determinação em 1420 pode incluir enviar uma solicitação para a referência de localização para o UE ao servidor de localização e receber a referência de localização para o UE a partir do servidor de localização. Alternativamente, conforme discutido acima, o nó de rede de acesso pode gerar a referência de localização para o próprio UE. Nesse caso, o nó de rede de acesso pode assinar de modo digital a referência de localização para que o UE indique que a referência de localização para o UE foi gerada pelo nó de rede de acesso para o operador.

[0254] Em 1430, o nó de rede de acesso envia uma segunda mensagem ao UE, como em 212A da Figura 2A ou 206B da Figura 2B. A segunda mensagem pode incluir a referência de localização. Quando o nó de rede de acesso corresponder a uma MME que suporta LTE, as segundas mensagens podem ser uma Aceitação de Anexação de NAS ou uma Aceitação de Atualização de Área de Rastreamento de NAS. Quando o nó de rede de acesso corresponder a um SGSN que suporta UMTS, as segundas mensagens podem ser uma Aceitação de Anexação de GPRS ou uma Aceitação de Atualização de Área de Roteamento de GPRS.

[0255] O UE pode incluir a referência de localização para o UE em uma solicitação de chamada de serviços de emergência enviada a um SP OTT, como SP OTT 150. O UE pode enviar a solicitação de chamada de serviços de emergência para o SP OTT por meio de uma rede de acesso diferente da rede de acesso do nó de rede de acesso. O SP OTT pode obter a localização do UE a partir do servidor de localização com base na referência de localização.

[0256] Embora não mostrado, o fluxo ilustrado na Figura 14 pode incluir adicionalmente autenticar o UE antes de enviar a segunda mensagem. Adicionalmente, o fluxo ilustrado na Figura 14 pode incluir adicionalmente determinar de modo periódico uma nova referência de localização para o UE enquanto o UE estiver anexado ao nó de rede de acesso e enviar a nova referência de localização ao UE.

[0257] A Figura 15 ilustra um fluxo exemplificativo para localizar um UE realizado em um servidor de localização, como o servidor de localização 170 na Figura 1A ou o GMLC/SLP 170 na Figura 1B.

[0258] Em 1510, o servidor de localização recebe uma solicitação para uma referência de localização para o UE a partir de um nó de rede de acesso que atende ao UE, como em 208A da Figura 2A ou 204B da Figura 2B.

[0259] Em 1520, o servidor de localização envia a referência de localização para o UE ao nó de rede de acesso, como em 208A da Figura 2A ou 204B da Figura 2B. A referência de localização pode incluir um endereço do servidor de localização e uma referência local para o UE.

[0260] Em 1530, o servidor de localização recebe uma solicitação de localização para uma localização do UE de uma entidade de rede que não seja o nó de rede de acesso, como em 216A da Figura 2A ou 214B da Figura 2B. A solicitação de localização pode incluir a referência de localização para o UE. A outra entidade de rede pode ser uma entidade de rede que pertence a um SP OTT, um provedor de ESInet ou um PSAP, por exemplo.

[0261] Em 1540, o servidor de localização pode determinar uma estimativa de localização para o UE, como em 218A da Figura 2A ou 216B a 226B ou 228B da Figura 2B. Quando o servidor de localização corresponder a um SLP, determinar a estimativa de localização para o UE pode incluir estabelecer uma sessão de SUPL com o UE. Quando o servidor de localização corresponder a um GMLC, determinar a estimativa de localização para o UE pode incluir determinar a estimativa de localização com o uso de uma solução de localização de plano de controle. Nesse caso, determinar a estimativa de localização com o uso da solução de localização de plano de controle pode incluir enviar uma solicitação de localização ao nó de rede de acesso e receber uma resposta de localização do nó de rede de acesso que contém a estimativa de localização, como em 218A da Figura 2A ou 216B a 226B da Figura 2B.

[0262] Em 1550, o servidor de localização envia a estimativa de localização para o UE à entidade de rede, como em 224A da Figura 2A ou 232B da Figura 2B.

[0263] O UE inclui a referência de localização em uma solicitação de chamada de serviços de emergência enviada a um SP OTT. Em uma modalidade, o UE pode enviar a solicitação de chamada de serviços de emergência ao SP OTT por meio de uma rede de acesso para um operador diferente do operador para o servidor de localização.

[0264] A Figura 16 ilustra um fluxo exemplificativo para localizar um UE realizado em um servidor de localização, como o servidor de localização 170 na Figura 1A ou o GMLC/SLP 170 na Figura 1B.

[0265] Em 1610, o servidor de localização recebe uma solicitação de localização para uma localização do UE de uma entidade de rede que não seja um nó de rede de acesso que atende ao UE, como em 216A da Figura 2A ou 214B da Figura 2B. A solicitação de localização pode incluir uma referência de localização para o UE. A referência de localização pode incluir uma referência de UE para o UE. A referência de UE pode ser um endereço de IP, um IMSI, um TMSI, um endereço do nó de rede de acesso, ou qualquer combinação dos mesmos. A outra entidade de rede pode ser uma entidade de rede que pertence a um SP OTT, um provedor de ESInet ou um PSAP, por exemplo.

[0266] Em 1620, o servidor de localização autentica a referência de localização para o UE. A referência de localização pode incluir uma assinatura digital, em tal caso, autenticar a referência de localização pode incluir autenticar a assinatura digital.

[0267] Em 1630, o servidor de localização determina uma estimativa de localização para o UE com base na referência de UE na referência de localização para o UE, como em 218A da Figura 2A ou 216B a 226B ou 228B da Figura 2B. Em uma modalidade, a referência de UE pode ser cifrada, em qual caso, determinar uma estimativa de localização para o UE pode incluir decifrar a referência de UE cifrada. Quando o servidor de localização corresponder a um SLP, determinar a estimativa de localização para o UE pode incluir estabelecer uma sessão de SUPL com o UE. Quando o servidor de localização corresponder a um GMLC, determinar a estimativa de localização para o UE pode incluir determinar a estimativa de localização com o uso de uma solução de localização de plano de controle. Nesse caso, determinar a estimativa de localização com o uso da solução de localização de plano de controle pode incluir enviar uma solicitação de localização ao nó de rede de acesso e receber uma resposta de localização do nó de rede de acesso que contém a estimativa de localização, como em 218A da Figura 2A ou 216B a 226B da Figura 2B.

[0268] Em 1640, o servidor de localização envia a estimativa de localização para o UE à outra entidade de rede, como em 224A da Figura 2A ou 232B da Figura 2B.

[0269] O UE pode incluir a referência de localização para o UE em uma solicitação de chamada de serviços de emergência enviada a um SP OTT, como SP OTT.

[0270] A Figura 17 ilustra um fluxo exemplificativo para localizar um UE que faz uma chamada realizada pelo UE, como o UE 1100. A chamada pode ser uma chamada de emergência.

[0271] Em 1710, o UE envia uma primeira mensagem a um nó de rede de acesso que serve o UE; Quando o nó de rede de acesso corresponder a uma MME que suporta LTE, as primeiras mensagens podem ser uma Solicitação de Anexação de NAS ou uma Solicitação de Atualização de Área de Rastreamento de NAS. Quando o nó de rede de acesso corresponder a um SGSN que suporta UMTS, a primeira mensagem pode ser uma Solicitação de Anexação de GPRS ou uma Solicitação de Atualização de Área de Roteamento de GPRS.

[0272] Em 1720, o UE recebe uma segunda mensagem do nó de rede de acesso que inclui uma referência de localização para o UE. A referência de localização pode ser para um servidor de localização, como o servidor de localização 170 na Figura 1A ou o GMLC/SLP 170 na Figura 1B, que pertence a um operador para o nó de rede de acesso e pode permitir que o UE seja localizado para a chamada. A referência de localização para o UE pode incluir o endereço do servidor de localização e uma referência de UE do UE. Quando o nó de rede de acesso corresponder a uma MME que suporta LTE, as primeiras mensagens podem ser uma Solicitação de Anexação de NAS ou uma Solicitação de Atualização de Área de Rastreamento de NAS. Quando o nó de rede de acesso corresponder a um SGSN que suporta UMTS, a primeira mensagem pode ser uma Solicitação de Anexação de GPRS ou uma Solicitação de Atualização de Área de Roteamento de GPRS. Embora não ilustrado na Figura 17, o fluxo pode incluir adicionalmente autenticar o UE ao nó de rede de acesso antes de receber a segunda mensagem.

[0273] Em 1730, o UE recebe uma solicitação para a chamada a partir de um usuário do UE.

[0274] Em 1740, o UE envia uma solicitação para a chamada a um SP OTT, como o SP OTT 150. A solicitação para a chamada pode incluir a referência de localização para o UE. Em uma modalidade, a solicitação de chamada é enviada pelo UE ao SP OTT por meio de uma rede de acesso diferente da rede de acesso para o nó de rede de acesso.

[0275] Embora não ilustrado na Figura 17, o fluxo pode incluir adicionalmente receber, de modo periódico, uma nova referência de localização para o UE a partir do nó de rede de acesso enquanto o UE estiver anexado ao nó de rede de acesso.

[0276] A Figura 18 ilustra um fluxo exemplificativo para suportar chamadas de emergência em um provedor de serviço OTT, como SP OTT 150. Em uma modalidade, o fluxo ilustrado na Figura 18 pode ser realizado, ou se fazer realizar, pelo módulo de posicionamento 1058.

[0277] Em 1810, o SP OTT 150 recebe uma primeira mensagem que compreende uma solicitação de chamada de emergência a partir de um UE, como qualquer um dos UEs 200, 300, 400, 500, 600, 700, 800, 900, 1002 e 1100, como em 806 e 906. A primeira mensagem é transferida para o SP OTT 150 por meio de um MNO de serviço para o UE, como o MNO de serviço 790, 890 ou 990. A primeira mensagem inclui um endereço para um IMS, como o IMS 894 ou 994, para o MNO de serviço.

[0278] Em 820, o SP OTT 150 envia uma segunda mensagem para o IMS com base no endereço, como em 808 e 908. A segunda mensagem pode ser uma solicitação para a chamada de emergência. A primeira mensagem, a segunda mensagem, ou ambas as mensagens podem ser um CONVITE DE SIP.

[0279] Embora não ilustrado na Figura 18, o fluxo pode incluir adicionalmente receber uma terceira mensagem a partir do IMS que compreende informações de roteamento para um PSAP de destino, como em 812, e enviar uma quarta mensagem para ou em direção ao PSAP com base nas informações de roteamento. A terceira mensagem pode ser uma mensagem de Múltiplas Escolhas de SIP 300, e a quarta mensagem pode ser uma solicitação para a chamada de emergência. O endereço para o IMS pode ser para uma LRF. As informações de roteamento podem incluir uma ID de referência, em tal caso, o fluxo pode incluir adicionalmente a ID de referência na quarta mensagem, em que a ID de referência permite que o PSAP obtenha uma localização para o UE a partir da LRF.

[0280] O IMS pode enviar uma quinta mensagem para ou em direção a um PSAP de destino, em que a quinta mensagem pode ser uma solicitação de chamada de emergência para o UE. O endereço para o IMS pode ser para um E-CSCF. O IMS inclui um identificador de referência na quinta mensagem, em que o identificador de referência permite que o PSAP obtenha uma localização para o UE a partir do IMS.

[0281] A Figura 19 ilustra um fluxo exemplificativo para suportar chamadas de emergência em uma entidade de IMS, como IMS 894 ou 994, para um MNO de serviço, como o MNO de serviço 890 ou 990. Em um aspecto, a entidade de IMS pode ser uma LRF. Em uma modalidade, o fluxo ilustrado na Figura 19 pode ser realizado, ou se fazer realizar, pelo módulo de posicionamento 1058.

[0282] Em 1910, a entidade de IMS recebe uma primeira mensagem enviada por um provedor de serviço OTT, como o SP OTT 150, como em 808 e 908, sendo que a primeira mensagem compreende uma solicitação de chamada de emergência para um UE. A solicitação de chamada de emergência inclui dados de MNO para o UE. A primeira mensagem pode ser uma mensagem de CONVITE DE SIP.

[0283] Em 1920, a entidade de IMS determina informações de roteamento para um PSAP de destino com base nos dados de MNO, como em 911 da Figura 9.

[0284] Embora não ilustrado na Figura 19, em uma modalidade, o fluxo pode incluir adicionalmente enviar uma segunda mensagem ao provedor de serviço OTT que compreende as informações de roteamento, em que as informações de roteamento permitem que o provedor de serviço OTT roteiem a chamada de emergência para ou em direção ao PSAP de destino. Nesse caso, as informações de roteamento podem ser uma ID de referência e o endereço ou identidade do PSAP ou um destino intermediário. A segunda mensagem pode ser uma mensagem de Múltiplas Escolhas de SIP 300.

[0285] Em uma modalidade, o fluxo pode incluir adicionalmente receber uma terceira mensagem que compreende a ID de referência a partir de outra entidade, identificar o UE com base na ID de referência, obter uma localização para o UE, e enviar uma quarta mensagem à outra entidade que compreende a localização. A ID de referência pode ser um ESRK, um ESRD mais um MSISDN ou uma URL de localização. A localização do UE pode ser obtida com o uso de uma solução de localização de plano de controle ou uma solução de localização de plano de usuário. Em um aspecto, a outra entidade pode ser o PSAP, um ALI ou um ESInet.

[0286] Em uma modalidade, o fluxo pode incluir adicionalmente enviar uma segunda mensagem para ou em direção ao PSAP com base nas informações de roteamento, em que a segunda mensagem compreende uma solicitação para a chamada de emergência. Nesse caso, a entidade de IMS pode ser um CSCF de Emergência.

[0287] A Figura 20 ilustra um fluxo exemplificativo para suportar chamadas de emergência em um UE, como qualquer um dos UEs 200, 300, 400, 500, 600, 700, 800, 900, 1002 e 1100. Em uma modalidade, o fluxo ilustrado na Figura 20 pode ser realizado, ou se fazer realizar, pelo módulo de posicionamento 1054.

[0288] Em 2010, o UE recebe uma solicitação para uma chamada de emergência a partir de um usuário do UE.

[0289] Em 2020, o UE obtém dados de MNO para um MNO de serviço para o UE, como em 802/804 e 902/904.

[0290] Em 2030, o UE envia uma primeira mensagem que compreende uma solicitação para a chamada de emergência a um provedor de serviço OTT, como SP OTT 150, como em 806 e 906. A solicitação para a chamada de emergência inclui os dados de MNO. Os dados de MNO podem incluir um endereço para um IMS para o MNO de serviço, uma identidade para uma entidade de gerenciamento de mobilidade de serviço atual ou SGSN para o UE, um endereço de IP atribuído ao MNO de serviço para o UE, uma identidade global ou identidade local para o UE ou alguma combinação dos mesmos.

[0291] O provedor de serviço OTT envia uma segunda mensagem ao IMS com base no endereço para o IMS, em que a segunda mensagem compreende uma solicitação para a chamada de emergência e inclui os dados de MNO. O IMS determina informações de roteamento para a chamada de emergência com base nos dados de MNO. Nessa modalidade, o fluxo inclui adicionalmente receber uma solicitação para uma estimativa de localização ou para medições de localização de acordo com uma solução de localização de plano de usuário ou uma solução de localização de plano de controle, em que a estimativa de localização ou as medições de localização permitem que o IMS obtenha uma localização para o UE, em que a localização para o UE permite que o IMS determine as informações de roteamento ou forneça ao PSAP a localização.

[0292] O IMS pode enviar uma terceira mensagem ao provedor de serviço OTT que compreende as informações de roteamento. O provedor de serviço OTT envia uma quarta mensagem para ou em direção a um PSAP de destino, em que o PSAP é determinado com base nas informações de roteamento. Nesse caso, o endereço para um IMS é um endereço para uma LRF.

[0293] O IMS pode enviar uma quinta mensagem para ou em direção a um PSAP de destino, em que a quinta mensagem compreende uma solicitação para a chamada de emergência e em que o PSAP é determinado com base nas informações de roteamento. O endereço para o IMS pode ser um endereço para um E-CSCF.

[0294] A Figura 21 ilustra um exemplo de aparelho de nó de rede de acesso 2100 representado como uma série de módulos funcionais inter-relacionados. Um módulo para receber 2110 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1014 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1034, opcionalmente em conjunto com o módulo de posicionamento 1056, conforme discutido no presente documento. Um módulo para determinar 2120 pode corresponder, pelo menos em alguns aspectos, a, por exemplo, um sistema de processamento, como o sistema de processamento 1034, opcionalmente, em conjunto com o módulo de posicionamento 1056, conforme discutido no presente documento. Um módulo para enviar 2130 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1014 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1034, opcionalmente em conjunto com o módulo de posicionamento 1056, conforme discutido no presente documento.

[0295] A Figura 22 ilustra um exemplo de aparelho de servidor de localização 2200 representado como uma série de módulos funcionais inter-relacionados. Um módulo para receber 2210 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1026 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento. Um módulo para enviar 2220 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1026 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento. Um módulo para receber 2230 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1026 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento. Um módulo para determinar 2240 pode corresponder, pelo menos em alguns aspectos, a, por exemplo, um sistema de processamento, como o sistema de processamento 1036, opcionalmente, em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento. Um módulo para enviar 2250 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1026 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento.

[0296] A Figura 23 ilustra um exemplo de aparelho de servidor de localização 2300 representado como uma série de módulos funcionais inter-relacionados. Um módulo para receber 2310 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1026 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento. Um módulo para autenticar 2320 pode corresponder, pelo menos em alguns aspectos, a, por exemplo, um sistema de processamento, como o sistema de processamento 1036, opcionalmente, em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento. Um módulo para determinar 2330 pode corresponder, pelo menos em alguns aspectos, a, por exemplo, um sistema de processamento, como o sistema de processamento 1036, opcionalmente, em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento. Um módulo para enviar 2340 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1026 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento.

[0297] A Figura 24 ilustra um exemplo de aparelho de equipamento de usuário exemplificativo 2400 representado como uma série de módulos funcionais inter- relacionados. Um módulo para enviar 2410 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1008 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme discutido no presente documento. Um módulo para receber 2420 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1008 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme discutido no presente documento. Um módulo para receber 2430 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comuni cação, como o dispositivo de comunicação 1008 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme discutido no presente documento. Um módulo para enviar 2440 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1008 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme discutido no presente documento.

[0298] A Figura 25 ilustra um exemplo de aparelho provedor de serviço OTT exemplificativo 2500 representado como uma série de módulos funcionais inter- relacionados. Um módulo para receber 2510 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1026 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento. Um módulo para enviar 2520 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1026 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento.

[0299] A Figura 26 ilustra um exemplo de aparelho de entidade de IMS exemplificativo 2600 representado como uma série de módulos funcionais inter- relacionados. Um módulo para receber 2610 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 102 6 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento. Um módulo para determinar 2620 pode corresponder, pelo menos em alguns aspectos, a, por exemplo, um sistema de processamento, como o sistema de processamento 1036, opcionalmente, em conjunto com o módulo de posicionamento 1058, conforme discutido no presente documento.

[0300] A Figura 27 ilustra um exemplo de aparelho de equipamento de usuário exemplificativo 2700 representado como uma série de módulos funcionais inter- relacionados. Um módulo para receber 2710 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1008 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme discutido no presente documento. Um módulo para obter 2720 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comunicação, como o dispositivo de comunicação 1008 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme discutido no presente documento. Um módulo para enviar 2730 pode corresponder pelo menos em alguns aspectos a, por exemplo, um dispositivo de comuni cação, como o dispositivo de comunicação 1008 na Figura 10, ou um sistema de processamento, como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme discutido no presente documento.

[0301] A funcionalidade dos módulos das Figuras 21 a 27 pode ser implantada de várias maneiras consistentes com os ensinamentos no presente documento. Em alguns modelos, a funcionalidade desses módulos pode ser implantada como um ou mais componentes elétricos. Em alguns designs, a funcionalidade desses blocos pode ser implantada como um sistema de processamento que inclui um ou mais componentes de processador. Em alguns designs, a funcionalidade desses módulos pode ser implantada com o uso de, por exemplo, de pelo menos uma porção de um ou mais circuitos integrados (por exemplo, um ASIC). Conforme discutido no presente documento, um circuito integrado pode incluir um processador, software, outros componentes relacionados, ou alguma combinação dos mesmos. Desse modo, a funcionalidade de diferentes módulos pode ser implantada, por exemplo, como diferentes subconjuntos de um circuito integrado, como diferentes subconjuntos de um conjunto de módulos de software ou uma combinação dos mesmos. Também, será entendido que um determinado subconjunto (por exemplo, de um circuito integrado e/ou de um conjunto de módulos de software) pode fornecer pelo menos uma porção da funcionalidade para mais de um módulo.

[0302] Além disso, os componentes e funções representados pela Figura 21 a 27, assim como outros componentes e funções descritos no presente documento, podem ser implantados com o uso de quaisquer meios adequados. Tais meios também podem ser implantados, pelo menos em parte, com o uso de estrutura correspondente conforme ensinado no presente documento. Por exemplo, os componentes descritos acima em combinação com os componentes de "módulo para" da Figura 21 a 27 também podem corresponder à funcionalidade de "meios para" atribuída de modo semelhante. Desse modo, em alguns aspectos um ou mais de tais meios podem ser implantados com o uso de um ou mais dentre componentes de processador, circuitos integrados ou outra estrutura adequada, conforme ensinado no presente documento.

[0303] As pessoas versadas na técnica entenderão que as informações e sinais podem ser representados com o uso de quaisquer dentre uma variedade de técnicas e tecnologias diferentes. Por exemplo, dados, instruções, comandos, informações, sinais, bits, símbolos, e chips que podem ser referenciados por toda a descrição acima podem ser representados por tensões, correntes, ondas eletromagnéticas, partículas ou campos magnéticos, partículas ou campos ópticos ou qualquer combinação dos mesmos.

[0304] Adicionalmente, as pessoas versadas na técnica entenderão que os vários blocos lógicos ilustrativos, módulos, circuitos e etapas de algoritmo descritos em conexão com as modalidades reveladas no presente documento podem ser implantados como hardware eletrônico, software de computador ou combinações de ambos. Para ilustrar claramente essa intercambialidade de hardware e software, vários componentes, blocos, módulos, circuitos e etapas ilustrativos foram descritos acima geralmente em termos de funcionalidade dos mesmos. Se tal funcionalidade deve ser implantada como hardware ou software, depende das restrições de projeto e aplicação particulares impostas no sistema geral. As pessoas versadas na técnica podem implantar a funcionalidade descrita em modos variáveis para cada aplicação em particular, porém, tais decisões de implantação não devem ser interpretadas como um afastamento do escopo da presente revelação.

[0305] Os vários blocos lógicos, módulos e circuitos ilustrativos descritos em conexão com as modalidades reveladas no presente documento podem ser implantados ou realizados com um processador para propósitos gerais, um processador de sinal digital (DSP), um circuito integrado para aplicação específica (ASIC), uma matriz de portas programável em campo (FPGA) ou outro dispositivo lógico programável, lógica de transistor ou porta distinta, componentes de hardware distintos ou qualquer combinação dos mesmos projetada para realizar as funções descritas no presente documento. Um processador de propósito geral pode ser um microprocessador, porém alternativamente, o processador pode ser qualquer processador, controlador, microcontrolador ou máquina de estado convencional. Um processador também pode ser implementado como uma combinação de dispositivos de computação, por exemplo, uma combinação de um DSP e um microprocessador, uma pluralidade de microprocessadores, um ou mais microprocessadores em conjunto com um DSP núcleo ou qualquer outra tal configuração.

[0306] Os métodos, sequências e/ou algoritmos descritos em conexão com as modalidades reveladas no presente documento podem ser incorporados diretamente em hardware, em um módulo de software executado por um processador ou em uma combinação dos dois. Um módulo de software pode residir na memória RAM, memória flash, memória ROM, memória EPROM, memória EEPROM, registros, um disco rígido, um disco removível, um CD-ROM ou qualquer outra forma de meio de armazenamento conhecido na técnica. Um meio de armazenamento exemplificativo é acoplado ao processador de modo que o processador possa ler as informações, e escrever informações, a partir do meio de armazenamento. Na alternativa, o meio de armazenamento pode ser integral ao processador. O processador e o meio de armazenamento podem residir em um ASIC. O ASIC pode residir em um terminal de usuário (por exemplo, o UE). Na alternativa, o processador e o meio de armazenamento podem residir como componentes distintos em um terminal de usuário.

[0307] Em uma ou mais modalidades exemplificativas, as funções descritas podem ser implantadas em hardware, software, firmware ou qualquer combinação dos mesmos. Caso implantadas em software, as funções podem ser armazenadas ou transmitidas como uma ou mais instruções ou código em um meio legível por computador. Os meios legíveis por computador incluem tanto meios de armazenamento de computador quanto meios de comunicação, incluindo qualquer mídia que facilite a transferência de um programa de computador de um local para outro. Um meio de armazenamento pode ser qualquer meio disponível que pode ser acessado por um computador. A título de exemplo, e não de limitação, tais meios de armazenamento legíveis por computador podem compreender RAM, ROM, EEPROM, CD-ROM, ou outro armazenamento de disco óptico, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser usado para carregar ou armazenar o código de programa desejado na forma de instruções ou estruturas de dados, e que possa ser acessado por um computador. Também, qualquer conexão pode ser propriamente denominada um meio legível por computador. Por exemplo, caso as instruções sejam transmitidas a partir de um site da web, servidor ou outra fonte remota com o uso de um cabo coaxial, cabo de fibra óptica, para trançado, linha de inscrição digital (DSL) ou tecnologias sem fio, tais como, infravermelho, rádio e micro-onda, então, o cabo coaxial, o cabo de fibra óptica, o para trançado, a DSL ou as tecnologias sem fio, tais como, infravermelho, rádio e micro-onda, estão incluídos na definição de mídia. Disco magnético e disco óptico, conforme usado no presente documento, incluem disco compacto (CD), disco laser, disco óptico, disco versátil digital (DVD), disquete e disco Blu- ray, em que os discos magnéticos reproduzem frequentemente os dados de modo magnético, ao passo que os discos ópticos reproduzem os dados de modo óptico com lasers. As combinações dos supracitadas também devem ser abrangidas pelo escopo de meios legíveis por computador.

[0308] Embora a revelação supracitada mostre modalidades ilustrativas da revelação, deve-se verificar que várias mudanças e modificações podem ser realizadas no presente documento sem se afastar do escopo da revelação conforme definido pelas reivindicações anexas. As funções, etapas e/ou ações das reivindicações de método, de acordo com as modalidades da revelação descritas no presente documento, não precisam ser realizadas em qualquer ordem específica. Além disso, embora elementos da revelação possam ser descritos ou reivindicados no singular, o plural é previsto a menos que a limitação ao singular seja explicitamente declarada.

Claims

1. Método de localização de um equipamento de usuário (200), UE, realizado por um nó de rede de acesso (142) que serve o UE, o método caracterizado pelo fato de que compreende: receber (1410) uma primeira mensagem (202B) a partir do UE, em que a primeira mensagem compreende uma solicitação para que o UE se anexe ao nó de rede de acesso; em resposta ao recebimento da primeira mensagem, determinar (1420) uma referência de localização para o UE, em que a referência de localização é para um servidor de localização (170) que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado, e em que a referência de localização compreende uma identificação de um protocolo, um endereço do servidor de localização e uma referência de UE para o UE; e enviar (1430) uma segunda mensagem (206B) ao UE, em que a segunda mensagem compreende uma aceitação da solicitação para que o UE se anexe ao nó de rede de acesso, e em que a segunda mensagem compreende a referência de localização, e em que a referência de localização é configurada para ser incluída pelo UE em uma solicitação de chamada para um provedor de serviços, SP, over-the-top, OTT.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que determinar (1420) a referência de localização para o UE compreende: enviar uma solicitação para a referência de localização para o UE (200) ao servidor de localização (170); e receber a referência de localização para o UE a partir do servidor de localização.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a referência de UE compreende um endereço de protocolo de Internet, IP, um Identificador de Assinante Móvel Internacional, IMSI, um Identificador de Assinante Móvel Temporário, TMSI, um endereço local do UE, um endereço do nó de rede de acesso, ou qualquer combinação destes.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que determinar a referência de localização para o UE compreende: gerar a referência de localização para o UE no nó de rede de acesso, e assinar digitalmente a referência de localização para que o UE indique que a referência de localização para o UE foi gerada pelo nó de rede de acesso para o operador.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o nó de rede de acesso compreende uma Entidade de Gerenciamento de Mobilidade, MME, que suporta Evolução de Longo Prazo, LTE, em que a primeira mensagem compreende uma Solicitação de Anexação de Estrato de Não Acesso, NAS, ou uma Solicitação de Atualização de Área de Rastreamento de NAS, e em que a segunda mensagem compreende uma Aceitação de Anexação de NAS ou uma Aceitação de Atualização de Área de Rastreamento de NAS, e/ou em que o nó de rede de acesso compreende um Nó de Suporte, SGSN, de Serviços de Rádio de Pacote Geral de Servidor, GPRS, que suporta Sistema de Telecomunicações Móvel Universal, UMTS, em que a primeira mensagem compreende uma Solicitação de Anexação de GPRS ou uma Solicitação de Atualização de Área de Roteamento de GPRS, e em que a segunda mensagem compreende uma Aceitação de Anexação de GPRS ou uma Aceitação de Atualização de Área de Roteamento de GPRS, e/ou em que o servidor de localização compreende um Centro de Localização Móvel de Porta de Comunicação, GMLC, uma Plataforma de Localização, SLP, de Localização de Plano de Usuário Segura, SUPL, ou uma Função de Recuperação de Localização, LRF.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação de chamada compreende uma solicitação de chamada de serviços de emergência, em que o UE (200) envia a solicitação de chamada de serviços de emergência para o SP OTT por meio de uma rede de acesso diferente da rede de acesso para o nó de rede de acesso, e/ou em que o SP OTT obtém uma localização do UE (200) a partir do servidor de localização com base na referência de localização.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente autenticar o UE (200) antes de enviar a segunda mensagem.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: determinar periodicamente uma nova referência de localização para o UE enquanto o UE estiver anexado ao nó de rede de acesso; e enviar a nova referência de localização para o UE.

9. Método de localização de um equipamento de usuário (200), UE, realizado em um servidor de localização (170), o método caracterizado pelo fato de que compreende: receber (1510) uma solicitação (204B) para uma referência de localização para o UE a partir de um nó de rede de acesso (142) que serve o UE; enviar (1520) a referência de localização para o UE ao nó de rede de acesso, em que a referência de localização para o UE compreende uma identificação de um protocolo, um endereço do servidor de localização e uma referência de UE para o UE; receber (1530) uma solicitação (212B) de localização para uma localização do UE a partir do dito nó de rede de acesso ou de uma entidade de rede que não seja o nó de rede de acesso, sendo que a solicitação de localização inclui a referência de localização para o UE; determinar (1540) uma estimativa de localização para o UE; e enviar (1550) a estimativa de localização para o UE ao dito nó de acesso de rede ou à entidade de rede.

10. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que a entidade de rede compreende uma entidade de rede que pertence a um provedor de serviços over-the-top, OTT, um provedor de rede de IP de Serviços de Emergência, ESInet, ou um Ponto de Resposta de Segurança Público, PSAP, e/ou em que o servidor de localização (170) compreende uma Plataforma de Localização, SLP, de Localização de Plano de Usuário Segura, SUPL, ou uma Função de Recuperação de Localização associada ou conectada a uma SLP, e em que determinar a estimativa de localização para o UE compreende determinar a estimativa de localização com o uso de uma solução de localização de plano de usuário, e/ou em que o servidor de localização (170) compreende um Centro de Localização Móvel de Porta de Comunicação, GMLC, ou uma Função de Recuperação de Localização, LRF, associada ou conectada a um GMLC, e em que determinar a estimativa de localização para o UE compreende determinar a estimativa de localização com o uso de uma solução de localização de plano de controle, e/ou em que a referência de localização compreende uma identificação de um protocolo, um endereço do servidor de localização e uma referência de UE para o local de UE ao servidor de localização.

11. Método de localização de um equipamento de usuário (200), UE, que faz uma chamada realizada pelo UE, o método caracterizado pelo fato de que compreende: enviar (1710) uma primeira mensagem (202B) a um nó de rede de acesso (142) que serve o UE, em que a primeira mensagem compreende uma solicitação para que o UE se anexe ao nó de rede de acesso; receber (1720) uma segunda mensagem (206B) a partir do nó de rede de acesso que compreende uma referência de localização para o UE, em que a segunda mensagem compreende uma aceitação da solicitação para que o UE se anexe ao nó de rede de acesso, em que a referência de localização é para um servidor de localização (170) que pertence a um operador para o nó de rede de acesso, e em que a referência de localização permite que o UE seja localizado para a chamada; e em que a referência de localização para o UE compreende uma identificação de um protocolo, um endereço do servidor de localização e uma referência de UE para o local de UE ao servidor de localização; receber (1730) uma solicitação (208B) para a chamada a partir de um usuário do UE; e enviar (1740) uma solicitação (212B) para a chamada a um provedor de serviços, SP (150), over-the-top, OTT, sendo que a solicitação para a chamada inclui a referência de localização para o UE.

12. Método, de acordo com a reivindicação 11, caracterizado pelo fato de que a referência de localização para o UE (200) compreende uma identificação de um protocolo, o endereço do servidor de localização e uma referência de UE do local de UE ao servidor de localização.

13. Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende adicionalmente autenticar a identidade de UE (200) ao nó de rede de acesso antes de receber a segunda mensagem.

14. Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende adicionalmente receber periodicamente uma nova referência de localização para o UE a partir do nó de rede de acesso enquanto o UE estiver anexado ao nó de rede de acesso.

15. Método, de acordo com a reivindicação 11, caracterizado pelo fato de que a chamada compreende uma chamada de serviços de emergência, e/ou em que o UE envia a solicitação para a chamada ao SP (150) OTT por meio de uma rede de acesso diferente da rede de acesso para o nó de rede de acesso.