BR112017010777B1 - Métodos e aparelho para suportar chamadas de emergência - Google Patents
Métodos e aparelho para suportar chamadas de emergência Download PDFInfo
- Publication number
- BR112017010777B1 BR112017010777B1 BR112017010777-5A BR112017010777A BR112017010777B1 BR 112017010777 B1 BR112017010777 B1 BR 112017010777B1 BR 112017010777 A BR112017010777 A BR 112017010777A BR 112017010777 B1 BR112017010777 B1 BR 112017010777B1
- Authority
- BR
- Brazil
- Prior art keywords
- location
- ott
- message
- ims
- psap
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 50
- 230000004044 response Effects 0.000 claims abstract description 29
- 238000005259 measurement Methods 0.000 claims description 24
- 230000004807 localization Effects 0.000 claims description 17
- 108010007100 Pulmonary Surfactant-Associated Protein A Proteins 0.000 claims description 16
- 102100027773 Pulmonary surfactant-associated protein A2 Human genes 0.000 claims description 16
- 208000020832 chronic kidney disease Diseases 0.000 claims description 10
- 201000000523 end stage renal failure Diseases 0.000 claims description 10
- 230000000977 initiatory effect Effects 0.000 claims description 4
- 101150002602 Psap gene Proteins 0.000 abstract 1
- 239000000243 solution Substances 0.000 description 109
- 238000004891 communication Methods 0.000 description 105
- 238000012545 processing Methods 0.000 description 57
- 239000013260 porous coordination network Substances 0.000 description 44
- 230000006870 function Effects 0.000 description 31
- 230000003993 interaction Effects 0.000 description 20
- 230000011664 signaling Effects 0.000 description 12
- 230000008569 process Effects 0.000 description 11
- 238000012546 transfer Methods 0.000 description 11
- 235000015854 Heliotropium curassavicum Nutrition 0.000 description 10
- 244000301682 Heliotropium curassavicum Species 0.000 description 10
- 238000005516 engineering process Methods 0.000 description 10
- YOETUEMZNOLGDB-UHFFFAOYSA-N 2-methylpropyl carbonochloridate Chemical compound CC(C)COC(Cl)=O YOETUEMZNOLGDB-UHFFFAOYSA-N 0.000 description 7
- 230000008901 benefit Effects 0.000 description 7
- 230000007246 mechanism Effects 0.000 description 7
- 230000008859 change Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 230000001413 cellular effect Effects 0.000 description 5
- 238000013461 design Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000004422 calculation algorithm Methods 0.000 description 4
- 238000001514 detection method Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000033001 locomotion Effects 0.000 description 4
- 239000012088 reference solution Substances 0.000 description 4
- 241000700159 Rattus Species 0.000 description 3
- 230000007774 longterm Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 241000760358 Enodes Species 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000005012 migration Effects 0.000 description 2
- 238000013508 migration Methods 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 239000004165 Methyl ester of fatty acids Substances 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000010267 cellular communication Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000009486 pneumatic dry granulation Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 239000012086 standard solution Substances 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/029—Location-based management or tracking services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/18—Selecting a network or a communication service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
- H04W60/02—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration by periodical registration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/50—Connection management for emergency connections
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Public Health (AREA)
- Environmental & Geological Engineering (AREA)
- Emergency Management (AREA)
- Health & Medical Sciences (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
métodos para suportar chamadas de localização e emergência para provedor de serviços over-the-top. são revelados métodos e equipamentos para suportar chamadas de localização e emergência para um provedor de serviços over-the-top (ott). um ue pode enviar uma solicitação de chamada de emergência a um provedor de serviços ott e pode incluir dados de operadora de rede móvel (mno) para uma mno servidora para o ue. o provedor de serviços ott pode emitir a solicitação da chamada de emergência para um subsistema multimídia de protocolo internet (ip)(ims). o ims pode determinar informações de roteamento para a chamada de emergência e ou devolver as informações de roteamento ao provedor de serviços ott para permitir que o provedor de serviços roteie a chamada de emergência para um ponto de resposta de segurança pública (psap) ou possa rotear a chamada de emergência propriamente dita para o psap. a solicitação de chamada roteada pelo ims ou pelo provedor de serviços ott pode incluir um identificador de referência que pode permitir que o psap obtenha do ims uma localização para o ue.
Description
[0001] O presente pedido de patente reivindica o benefício do pedido provisório norte-americano No. 62/083 768, intitulado “LOCALIZAÇÃO POR REFERÊNCIA PARA CHAMADA DE EMERGÊNCIA OVER-THE-TOP” depositado a 24 de novembro de 2014, e do pedido provisório norte-americano No. 62/101 974, intitulado “ALTERNATIVAS DE TRENAFERÊNCIA DE LOCALIZAÇÃO PARA PROVEDOR DE SERVIÇOS OVER-THE-TOP”, depositado a 9 de janeiro de 2015, cedidos ao cessionário deste e expressamente aqui incorporados em sua totalidade à guisa de referência.
[0002] As modalidades da revelação referem-se ao fornecimento de suporte para chamadas de localização e emergência para um provedor de serviços (SP) over-the-top (OTT).
[0003] Os sistemas de comunicação têm se desenvolvido através de diversas gerações, inclusive um serviço telefônico sem fio analógico de primeira geração (1G), um serviço telefônico sem fio digital de segunda geração (2G)(que inclui redes 2,5G interinas) e serviços sem fio de dados de alta-velocidade/capazes de Internet de terceira geração (3G) e quarta geração (4G).
[0004] Como parte da evolução 4G, a Evolução de Longo Prazo (LTE) foi desenvolvida pelo Projeto de Parcerias de 3a Geração (3GPP) como uma tecnologia de rede de rádio-acesso para comunicação sem fio de dados de alta velocidade para telefones móveis e outros terminais de dados. A LTE evoluiu do Sistema Global para Comunicações Móveis (GSM) e de derivados do GSM, tais como Taxas de Dados Aperfeiçoadas para Evolução de GSM (EDGE), o Sistema Universal de Telecomunicações Móveis (UMTS) e o Acesso a Pacotes de Alta Velocidade (HSPA).
[0005] Na América do Norte, os sistemas de comunicação sem fio, tais como os que suportam GSM, UMTS e LTE que são utilizados por operadoras de redes públicas utilizam uma solução para 911 Aperfeiçoado, ou E911, que conecta chamadores de emergência com os recursos públicos apropriados. A solução associar automaticamente o chamador, isto é, o equipamento de usuário (UE) do chamador a uma localização específica, tal como um endereço físico ou coordenadas geográficas. A localização automática do chamador com alta exatidão (com um erro de distância de 50 metros ou menos, por exemplo), e o fornecimento da localização a um Ponto de Resposta de Segurança Pública (PSAP) podem aumentar a velocidade com a qual o lado da segurança pública pode responder durante emergências, especialmente no caso de o chamador ser incapaz de comunicar sua localização ou não conhecer esta localização. Além disto, o conhecimento da localização aproximada de um chamador de emergência (a célula de rede específica que o aparelho do chamador está acessando, por exemplo) pode ser essencial ao roteamento de uma chamada de emergência para o PSAP correto para a localização do chamador.
[0006] Determinados outros provedores, conhecidos como provedores de serviços (SPs) over-the-top (OTT) podem prover também serviços relacionados com voz e dados ao usuário de aparelhos sem fio, mas sem necessariamente possuir ou acionar uma rede sem fio pública ou atuar como uma Operadora de Rede Virtual Móvel (MVNO). Um usuário com um aparelho sem fio pode acessar então recursos SP OTT (um ou mais servidores, por exemplo) por meio de algum outro SP de rede sem fio - 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 servidor (ao contrário do acesso a uma rede sem fio nativa ou MVNO) e pode ocorrer tipicamente acima dos níveis de rede e protocolo IP - levando ao nome “over-the-top”. Neste caso, o SP OTT pode proporcionar ao usuário a capacidade de fazer chamadas de voz e dados, chamadas (ou sessões de voz e dados) e em alguns casos a capacidade de fazer uma chamada de emergência.
[0007] Entretanto um SP OTT pode ter mais dificuldade do que uma operadora de rede sem fio pública de obter a localização precisa e segura para um chamador de emergência devido ao acesso restrito a informações relacionadas com localização e à falta de recursos capazes de localização. Por exemplo, enquanto uma rede sem fio servidora pode ter acesso a informações relacionadas com células para um chamador sem fio (um ID de célula servidora para o chamador sem fio, por exemplo) e pode ter infra- estrutura de rede que pode ser utilizada para obter uma localização precisa para um chamador sem fio (estações base que podem medir sinais de um aparelho do chamador sem fio ou cujos sinais podem ser medidos pelo aparelho do chamador sem fio e um servidor de localização para transformar tais medições em uma estimativa de localização, por exemplo), um SP OTT pode ter poucas ou nenhuma desta infra-estrutura ou informação. Isto pode impedir que um SP OTT roteie uma chamada de emergência de um chamador sem fio para o PSAP correto e/ou forneça uma localização precisa do chamador sem fio a um PSAP, o que pode impedir que um SP OTT proveja serviços de emergência seguros. Além disto, um SP OTT pode não ter sempre o dispositivo de comunicação para emitir uma chamada de emergência para um PSAP de destino, mesmo quando o PSAP pode ser conhecido, ou responder a uma consulta de um PSAP para a localização do chamador - no caso de a SP OTT faltar a conectividade necessária com o PSAP ou faltar autorização para emitir chamadas de emergência ou fornecer localização do chamador. Pode haver, portanto, benefícios no aperfeiçoamento do suporte de chamadas de serviço de localização e emergência para um SP OTT.
[0008] Em seguida é apresentado um sumário simplificado referente a um ou mais aspectos e/ou modalidades associados ao mecanismos aqui revelado para proporcionar alternativas de transferência de localização para um provedor de serviços over-the-top (OTT). Sendo assim, o sumário seguinte não deve ser considerado uma vista panorâmica extensiva referente a todos os aspectos e/ou modalidades contemplados, nem deve ser o sumário seguinte ser considerado como identificando elementos chave ou essenciais referentes a todos os aspectos e/ou modalidades contemplados ou como delineando o alcance associado a qualquer aspecto e/ou modalidade específico. Por conseguinte, o sumário seguinte tem a única finalidade de apresentar determinados conceitos referentes a um ou mais aspectos e/ou modalidades referentes aos mecanismos aqui revelados sob uma forma simplificada para preceder a descrição detalhada apresentada em seguida.
[0009] São revelados métodos e equipamento para suportar chamadas de localização e emergência para um provedor de serviços OTT. Um método para suportar chamadas de emergência em um provedor de serviços OTT inclui receber uma primeira mensagem que compreende uma solicitação de chamada de emergência de um equipamento de usuário (UE), no qual a primeira mensagem é transferida para o provedor de serviços OTT por meio de uma operadora de rede móvel servidora (MNO) para o UE e no qual a primeira mensagem inclui um endereço para um subsistema multimídia de protocolo Internet (IP)(IMS) para a MNO servidora, e enviar uma segunda mensagem ao IMS com base no endereço, no qual a segunda mensagem compreende uma solicitação da chamada de emergência.
[0010] Um método para suportar chamadas de emergência em uma entidade de IMS para uma MNO servidora inclui receber uma primeira mensagem enviada por um provedor de serviços OTT que compreende uma solicitação de chamada de emergência para um UE, no qual a solicitação de chamada de emergência inclui dados de MNO para o UE, e determinar informações de roteamento para um Ponto de Resposta de Segurança Pública (PSAP) de destino com base nos dados de MNO.
[0011] Um método para suportar chamadas de emergência em um UE inclui receber uma solicitação de chamada de emergência de um usuário do UE, obter dados de MNO para uma MNO servidora para o UE, e enviar uma primeira mensagem que compreende uma solicitação da chamada de emergência a um provedor de serviços OTT, no qual a solicitação de chamada de emergência inclui os dados de MNO.
[0012] Um equipamento para sustentar chamadas de emergência em um provedor de serviços OTT inclui pelo menos um processador e um transceptor, o transceptor configurado para receber uma primeira mensagem que compreende uma solicitação de chamada de emergência de um UE, no qual a primeira mensagem é transferida para o provedor de serviços OTT por meio de uma MNO servidora para o UE, e no qual a primeira mensagem inclui um endereço para um IMS para a MNO servidora, e para enviar uma 22 mensagem ao IMS com base no endereço, no qual a segunda mensagem compreende uma solicitação de chamada de emergência.
[0013] Um equipamento para suportar chamadas de emergência em uma entidade de IMS para uma MNO servidora inclui pelo menos um processador e um transceptor, o transceptor configurado para receber uma primeira mensagem enviada por um provedor de serviços OTT que compreende uma solicitação de chamada de emergência para um UE, no qual a solicitação de chamada de emergência inclui dados de MNO para o UE, e no qual o pelo menos um processador é configurado para determinar informações de roteamento para um PSAP de destino com base nos dados de MNO.
[0014] Um equipamento para suportar chamadas de emergência em um UE inclui pelo menos um processador e um transceptor, o transceptor configurado para redes de receber uma solicitação de chamada de emergência de um usuário do UE para obter dados de MNO para uma MNO servidora para o UE, e para enviar uma primeira mensagem que compreende uma solicitação de chamada de emergência a um provedor de serviços OTT, no qual a solicitação da chamada de emergência inclui os dados de MNO.
[0015] Um equipamento para suportar chamadas de emergência em um provedor de serviços OTT inclui um dispositivo para receber uma primeira mensagem que compreende uma solicitação da chamada de emergência de um UE, no qual a primeira mensagem é transferida para o provedor de serviços OTT por meio de uma MNO servidora para o UE e no qual a primeira mensagem inclui um endereço para IMS para a MNO servidora e um dispositivo para enviar uma segunda mensagem ao IMS com base no endereço, no qual a segunda mensagem compreende a solicitação da chamada de emergência.
[0016] Um equipamento para suportar chamadas de emergência em uma entidade de IMS para uma MNO servidora inclui um dispositivo para receber uma primeira mensagem enviada por um provedor de serviços OTT que compreende uma solicitação da chamada de emergência para um UE, no qual a solicitação da chamada de emergência inclui dados de MNO para o UE, e um dispositivo para determinar informações de roteamento para um PSAP de destino com base nos dados de MNO.
[0017] Um equipamento para suportar chamadas de emergência em um UE inclui um dispositivo para receber uma solicitação da chamada de emergência de um usuário do UE, um dispositivo para obter dados de MNO para uma MNO servidora para o UE, e um dispositivo para enviar uma primeira mensagem que compreende uma solicitação da chamada de emergência a um provedor de serviços OTT, no qual a solicitação da chamada de emergência inclui os dados de MNO.
[0018] Um meio passível de leitura por computador não transitório para suportar chamadas de emergência em um provedor de serviços OTT inclui pelo menos uma instrução para receber uma primeira mensagem que compreende uma solicitação da chamada de emergência de um UE, no qual a primeira mensagem é transferida para o provedor de serviços OTT por meio de uma MNO servidora para o UE, e no qual a primeira mensagem inclui um endereço para um IMS para MNO servidora, e pelo menos uma instrução para enviar uma segunda mensagem ao IMS com base no endereço, no qual a segunda mensagem compreende uma solicitação da chamada de emergência.
[0019] O meio passível de leitura por computador não transitório para suportar chamadas de emergência em uma entidade de IMS para uma MNO servidora inclui pelo menos uma instrução para receber uma primeira mensagem enviada por um provedor de serviços OTT que compreende uma solicitação da chamada de emergência para um UE, no qual a solicitação da chamada de emergência inclui dados de MNO para o UE, e pelo menos uma instrução para determinar informações de roteamento para um PSAP de destino com base nos dados de MNO.
[0020] Um meio passível de leitura por computador não transitório para suportar chamadas de emergência em um UE inclui pelo menos uma instrução para receber uma solicitação de chamada de emergência de um usuário do UE, pelo menos uma instrução para obter dados de MNO para uma MNO servidora para o UE, e pelo menos uma instrução para enviar uma primeira mensagem que compreende uma solicitação da chamada de emergência a um provedor de serviços OTT, no qual a solicitação da chamada de emergência inclui os dados de MNO.
[0021] Outros objetos e vantagens associados aos mecanismos aqui revelados serão evidentes aos versados na técnica com base nos desenhos anexos e na detecção detalhada.
[0022] Um entendimento mais completo das modalidades da revelação e de muitas das vantagens decorrentes delas será prontamente obtido à medida que a mesma se torne mais bem entendida por referência à descrição detalhada seguinte quando considerada em conexão com os dos anexos, que são apresentados unicamente para exemplificação e não limitação da revelação, e nos quais:
[0023] A Figura 1A mostra a arquitetura de sistema de alto nível de um sistema de comunicação sem fio de acordo com pelo menos um aspecto da revelação.
[0024] A Figura 1B mostra uma configuração exemplar da arquitetura de sistema da Figura 1A para acesso sem fio da Evolução de Longo Prazo (LTE) de acordo com pelo menos um aspecto da revelação.
[0025] A Figura 2A mostra interações específicas das entidades de rede mostradas na Figura 1A de modo a se obter uma localização por referência de acordo com pelo menos um aspecto da revelação.
[0026] A Figura 2B mostra interações específicas das entidades de rede mostradas na Figura 1B de modo a se obter uma localização por referência de acordo com pelo menos um aspecto da revelação.
[0027] A Figura 3 mostra uma arquitetura exemplar para prover serviços de emergência de acordo com pelo menos um ascendente da revelação.
[0028] A Figura 4 mostra uma arquitetura exemplar para localização por suporte de referência de acordo com pelo menos um aspecto da revelação.
[0029] A Figura 5 mostra uma arquitetura exemplar para suporte do Subsistema multimídia de protocolo Internet (IP)(IMS) para serviços de emergência de acordo com pelo menos um aspecto da revelação.
[0030] A Figura 6 mostra outra arquitetura exemplar para suporte de IMS para serviços de emergência de acordo com pelo menos um aspecto da revelação.
[0031] A Figura 7 mostra um fluxo de chamadas exemplar para localização por valor e localização por referência de acordo com pelo menos um aspecto da revelação.
[0032] A Figura 8 mostra outro fluxo de chamadas exemplar para suporte de IMS de uma chamada exemplar de acordo com pelo menos um aspecto da revelação.
[0033] A Figura 9 mostra outro fluxo de chamadas exemplar para suporte de IMS de uma chamada de emergência de acordo com pelo menos um aspecto da revelação.
[0034] A Figura 10 é um diagrama de blocos simplificado de vários aspectos de amostra de componentes configurados para suportar comunicação conforme aqui ensinado.
[0035] A Figura 11 mostra um exemplo de equipamento de usuário (UE) de acordo com pelo menos um aspecto da revelação.
[0036] A Figura 12 mostra um aparelho de comunicação que inclui componentes estruturais para executar a funcionalidade aqui descrita.
[0037] A Figura 13 mostra um servidor de acordo com uma modalidade da revelação.
[0038] As Figuras 14-20 mostras fluxos exemplares para localizar um UE de acordo com diversos aspectos da revelação.
[0039] As Figuras 21-27 são outros diagramas de blocos simplificados de vários aspectos de amostras de equipamentos configurados para suportar comunicação conforme aqui ensinado.
[0040] Nota-se que nos fluxos de mensagens e chamadas métodos nas Figuras 2A, 2B, 7, 8 e 9, mensagens e ações individuais são indicadas por rótulos numéricos que são às vezes referidos na descrição como operações ou etapas.
[0041] São revelados métodos e equipamentos para suportar chamadas de localização e emergência para um provedor de serviços over-the-top (OTT). Um equipamento de usuário (UE) pode enviar uma solicitação da chamada de emergência a um provedor de serviços OTT e pode incluir na solicitação dados de operadora de rede móvel (MNO) para uma MNO servidora para o UE. Os dados de MNO podem incluir o endereço de um Subsistema multimídia IP (IMS) para a MNO servidora. O provedor de serviços OTT pode emitir a solicitação da chamada de emergência para o IMS pode determinar informações de roteamento para a chamada de emergência e/ou pode devolver as informações de roteamento ao provedor de serviços OTT de modo a permitir que o provedor de serviços OTT roteie a chamada de emergência para um Ponto de Resposta de Segurança Pública (PSAP) ou pode rotear a chamada de emergência propriamente dita para o PSAP. A solicitação de chamada roteada pelo IMS ou pelo provedor de serviços OTT pode incluir um identificador de referência que pode permitir que o PSAP obtenha a localização para o UE do IMS.
[0042] Estes e outros aspectos da revelação são revelados na descrição seguinte e nos desenhos conexos referentes a modalidades específicas da revelação. Modalidades alternativas podem ser concebidas sem que abandone o alcance da revelação. Além disto, elementos notoriamente conhecidos da revelação não serão descritos em detalhe ou serão omitidos de modo a não se obscurecer os detalhes relevantes da revelação.
[0043] As palavras “exemplar” e/ou “exemplo” são aqui utilizadas como significando “que serve como exemplo, ocorrência ou ilustração”. Qualquer modalidade aqui descrita como “exemplar” e/ou “exemplo” não deve ser necessariamente interpretada como preferida ou vantajosa comparada com outras modalidades. Da mesma maneira, o termo “modalidades da revelação” não exige que todas as modalidades da revelação incluam o recurso, vantagem ou modo de funcionamento discutido.
[0044] Além disto, muitas modalidades são descritas em termo de sequências de ações a serem executadas por, por exemplo, elementos de um aparelho de computação. Deve se reconhecer que diversas ações aqui descritas podem ser executadas por circuitos específicos (circuitos integrados específicos de aplicativo (ASICs), por exemplo) por instruções de programa que são executadas por um ou mais processadores ou por uma combinação de ambos. Além disto, estas sequências de ações aqui descritas podem ser consideradas como sendo corporificadas inteiramente dentro de qualquer forma de meio de armazenamento passível de leitura por computador que tenha armazenado nele um conjunto correspondente de instruções de computador que, ao serem executadas, fariam com que um processador conexo executasse a funcionalidade aqui descrita. Assim, os diversos aspectos da revelação podem ser corporificados sob várias formas diferentes, todas elas tendo sido contempladas como estando dentro do alcance do objeto reivindicado. Além disto, para cada uma das modalidades aqui descritas, a forma correspondente de qualquer de tais modalidades pode ser aqui descrita como, por exemplo, “lógica configurada para” executar a ação descrita.
[0045] A Tabela 1 apresenta um glossário de termos e abreviaturas utilizados nesta revelação:
Tabela 1 - Glossário de Termos e Abreviaturas
[0046] Um aparelho de usuário, aqui referido como equipamento de usuário (UE), pode ser móvel ou estacionário e pode comunicar-se com uma rede de rádio-acesso (RAN). Conforme aqui utilizado, o termo “UE” pode ser referido de maneira intercambiável como “terminal de acesso” ou “AT”, aparelho sem fio, “terminal sem fio”, “aparelho de assinante”, “terminal de assinante”, “estação de assinante”, “terminal de usuário” ou “UT”, “terminal móvel”, “estação móvel”, “terminal”, “aparelho”, “aparelho de usuário” e variações dele. Geralmente, os UEs podem comunicar-se com uma rede básica por meio de uma RAN, e, através da rede básica, os UEs podem ser conectados com redes externas, tais como a Internet. Evidentemente, outros mecanismos de conexão com a rede básica e/ou a Internet são também possíveis para os UEs, tais como através de redes de acesso cabeadas, redes WiFi (como, por exemplo, baseadas no IEEE 802.11, etc.) e assim por diante. Os UEs podem ser corporificados por qualquer um dos vários tipos de aparelho, que inclui, mas não se limitam a cartões de PC, aparelhos flash compactos, modens externos ou internos, telefones sem fio ou de linha de fios elétricos, telefones inteligentes, computadores tablet, computadores laptop, e assim por diante. Um link de comunicação através do qual os UEs podem enviar sinais à RAN é chamado de canal de uplink (como, por exemplo, um canal de tráfego reverso, um canal de controle reverso, um canal de acesso, etc.). Um link de comunicação através do qual a RAN pode enviar sinais aos UEs é chamado de canal de downlink ou de link direto (como, por exemplo, um canal de paging, um canal de controle, um canal de broadcast, um canal de tráfego direto, etc.). Conforme aqui utilizado, o termo canal de tráfego (TCH) pode refere-se ou a um canal de uplink/reverso ou a um canal de tráfego de downlink/de tráfego direto.
[0047] A Figura 1A mostra uma arquitetura de sistema de alto nível de um sistema de comunicação sem fio 100A de acordo com uma modalidade da revelação. O sistema de comunicação sem fio 100A contém um número N de UEs rotulados como 1... N. Os UEs 1... N podem incluir telefones celulares, assistentes digitais pessoais (PDAs), rádio transmissores, um computador laptop, um computador de mesa e assim por diante. Na Figura 1A, por exemplo, os UEs 1... 2 são mostrados como telefones de chamada celulares, os UEs 3... 5 são mostrados como telefones com tela sensível ao toque celulares ou telefones inteligentes ou UE N é mostrado como um computador de mesa ou PC.
[0048] Com referência à Figura 1A, os UEs 1... N são configurados para comunicar-se com uma rede de acesso (como, por exemplo, a RAN 120, um ponto de acesso 125, etc.) através de uma interface ou cada de comunicação física mostrada na Figura 1A como interfaces aéreas 104, 106, 108 e/ou como conexão cabeada direta 102. As interfaces aéreas 104 e 106 podem conformar-se com um dado protocolo de comunicação celular (como, por exemplo, o Acesso Múltiplo por Divisão de Código (CDMA), Evolução Dados Otimizados (EVDO) Dados em Pacotes de Taxa Elevada Aperfeiçoados (eHRPD), Sistema Global Para Comunicações Móveis (GSM), Taxas de Dados Aperfeiçoadas para Evolução de GSM (EDGE), CDMA de Banda Larga (WCDMA), Evolução de Longo Prazo (LTE), etc.), enquanto a interface aérea pode conformar-se com um protocolo de rede de área local sem fio (WLAN)(como, por exemplo, o IEEE 802.11, o Bluetooth®, etc.). Conforme será descrito mais adiante, a RAN 120 inclui uma série de pontos de acesso que serve UEs através de interfaces aéreas, tais como as interfaces áreas 104 e 106. Os podem ser na RAN 120 podem ser referidos como nós de acesso (ANs), pontos de acesso (APs), estações base (BSs), Nós B evoluídos (eNósb) e assim por diante. Esses pontos de acesso podem ser pontos de acesso terrestres (ou estações conectadas à terra) ou pontos de acesso por satélite. A RAN 120 é configurada para conectar-se a uma rede básica (CN) 140, que pode ser também referida como Rede Básica de Pacotes) PCN, ou Núcleo de Pacotes Evoluída (EPC), que pode desempenhar diversas funções, inclusive rotear e conectar chamadas comutadas por circuito (CS) entre UEs servidos pela RAN 120 e/ou outros UEs ou algumas entidades não UE servidas pela RAN 120 ou por uma RAN diferente ou rede diferente (não RAN) completamente e pode também mediar uma troca de dados comutados por pacote (PS) com outras entidades por meio de redes externas (tais como a Internet 175). A RAN 120 mais a CN 140 podem atuar como uma rede sem fio servidora para um ou mais dos UEs de 1 NA. O termo rede sem fio é utilizado de maneira intercambiável com o termo operadora de rede móvel (MNO) para referir-se a uma rede sem fio e à infra-estrutura dentro da rede sem fio (a RAN 120 e a CN 140, por exemplo).
[0049] A Internet 175 inclui vários agentes de roteamento e agentes de processamento (não mostrados na Figura 1A por conveniência). Na Figura 1A o UE N é mostrado como conectando-se à Internet 175 diretamente (isto é, separadamente da rede básica 140, tal como por meio de uma DSL ou SP a cabo de pacote e que pode ser por meio do ponto de acesso 125 propriamente dito em um exemplo (para um roteador WiFi, por exemplo)). A Internet 175 pode funcionar assim para rotear comunicações de dados comutadas por pacote entre o UE N e outros UEs que acessam a Internet 175 (por meio da rede básica 140, por exemplo).
[0050] É 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 Básica (CN) 140 (como, por exemplo, por meio de um sistema de comunicação ótico tal como FiOS, um modem a cabo, etc. A interface aérea 108 pode servir o UE 4 ou UE 5 através de uma conexão sem fio local, tal como o IEEE 802.11 ou Bluetooth, em um exemplo.
[0051] Com referência à Figura 1A, um servidor de localização 170 é mostrado como conectado à Internet 175, à CN 140 ou a ambas. O servidor de localização 170 pode ser implementado como uma série de servidores estruturalmente separados ou alternativamente como corresponder a um único servidor. Conforme será descrito em seguida mais detalhadamente, o servidor de localização 170 é configurado para suportar um ou mais serviços de localização (como, por exemplo, serviços de posicionamento, serviços de posição por referência, etc.) para UEs que podem conectar-se ao servidor de localização 170 por meio da CN 140 e/ou por meio da Internet 175.
[0052] A Figura 1A mostra também um Provedor de Serviços (SP) over-the-top de (OTT) 150. UM SP OTT pode transferir conteúdo de áudio, vídeo e/ou de outros meios e/ou um ou mais dos UEs 1A N através da Internet 175 e possivelmente através da RAN 120 e da CN 140 de uma maneira que é parcial ou completamente transparente à Internet 175, à RAN 120 e à CN 140. Um SP OTT refere-se tipicamente a um provedor de terceira parte, tal como o SkypeTM, Hulu, Netflix, Google, etc. O SP OTT 150 pode comunicar-se com os UEs 1... N através da Internet 175, da CN 140, da RAN 120 e/ou do ponto de acesso 125. Embora apenas um único SP OTT 150 seja mostrado na Figura 1A conforme é evidente que pode haver qualquer número de SPs OTT 150 conectados à Internet 175 cada um deles correspondendo a um SP OTT diferente. O SP OTT 150 pode ter um ou mais servidores, proxys de roteamento e/ou outras entidades (não mostradas na Figura 1A) que podem desempenhar as diversas funções aqui descritas para o SP OTT 150. O mesmo pode aplicar-se a outros SPs OTT aqui referidos mais adiante, tais como o SP OTT 350, 450, 550, 650, 750, 850 e 950.
[0053] É também mostrada na Figura 1A uma Rede IP de Serviços de Emergência (ESInet) e/ou Roteador Seletivo (SR) 160. A ESInet 160 é capaz de rotear chamadas de emergência baseadas 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 para um Ponto de Resposta de Segurança Pública (PSAP) adequado, tal como o PSAP 180. Da mesma maneira, o SR 160 é capaz de rotear uma chamada de emergência Comutada por Circuito (CS) feita por qualquer um dos UEs 1 a N e recebida por meio da CN 140 para um PSAP, tal como o PSAP 180. Em algumas modalidades, qualquer um dos UEs 1 a N pode originar uma chamada de emergência baseada em IP, que pode ser transformada pela CN 140 ou pelo SP OTT em uma chamada de emergência CS e enviada ao SR 160 (por meio da Rede Telefônica Comutada Pública, não mostrada na Figura 1A, por exemplo) para roteamento para um PSAP capaz de CS 180. Isto pode ocorrer quando houver um SR 160, mas nenhuma ESInet e/ou quando o PSAP 180 suporta chamadas de emergência CS, mas não chamadas de emergência baseadas em IP. Deve ficar entendido que, nas descrições de estabelecimento de chamadas de emergência por meio de um SP OTT 150 aqui mais adiante, a chamada de emergência pode começar como uma chamada de emergência baseada em IP de um UE (qualquer um dos UEs 1 a N, por exemplo), mas pode ser convertida em uma chamada de emergência CS pelo SP OTT 150 e roteadas para o PSAP 180 por meio do SR 160 e não por meio da ESInet 160.
[0054] Os UEs 1... N da Figura 1A são capazes de fazer chamadas de voz, textos, vídeo ou outras chamadas de dados por meio da Internet 175. Por exemplo, os UEs 1... N são capazes de fazer uma chamada de emergência por meio do SP OTT 150, conforme descrito mais adiante. A ESInet/SR 160 pode entregar estas chamadas de voz, texto, vídeo e de dados de emergência ao PSAP 180, que pode ser, por exemplo, um centro de chamadas de emergência. O protocolo utilizado para entregar estas chamadas de emergência pode ser o Protocolo de Início de Sessão (SIP) definidos pela Força Tarefa de Engenharia da Internet (IETF). Além disto, compreender baseadas em SIP podem ser entregues utilizando- se o Subsistema Multimídia IP (IMS) definido pelo 3GPP, que suporta a utilização do SIP que pode ser suportado pela CN 140.
[0055] Um exemplo de implementação específica de protocolo para RAN 120 e CN 140 é apresentado em seguida com relação à Figura 1B para ajudar a explicar o sistema de comunicação sem fio 100A mais detalhadamente no caso de acesso pela LTE pela RAN 120. Em particular, os componentes da RAN 120 e da CN 140 correspondem aos componentes associados ao suporte de comunicações comutadas por pacote (PS) pelo que os componentes comutados por circuito O (CS) legados podem estar também presentes nestas redes, mas não são mostrados explicitamente na Figura 1B.
[0056] Especificamente, a Figura 1B mostra uma configuração 100B exemplar da RAN 120 e da CN 140 baseada no suporte, pelo Sistema de Pacotes Evoluído (EPS), de acesso sem fio à LTE, de acordo com uma modalidade da revelação. No exemplo da Figura 1B, a RAN 120 na rede EPS/LTE é configurada com uma série de Nós B evoluídos (eNósb ou eNBs) 122, 124 e 126. A CN 140 inclui uma série de Entidades de Gerenciamento de Mobilidade (MMEs) 142 e 144, um Centro de Localização Móvel Servidor Aperfeiçoado (e-SMLC) 172, um Gateway Servidor (S-GW) 146 e um Gateway de Rede de Dados em Pacotes (PDG) 148. No exemplo da Figura 1B, o servidor de localização 170 é ou um Centro de Localização Móvel de Gateway (GMLC) que suporta a solução de localização no plano de controle LTE ou uma Plataforma de Localização no Plano de Usuário Segura (SLP)(SUPL) que suporta a solução de localização SUPL 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 com ou associação com um HMLC e/ou uma SLP. Interfaces de rede entre estes componentes, a RAN 120 e a Internet 175 são mostradas na Figura 1B e são definidas na Tabela 2.
Tabela 2
[0057] Será agora apresentada uma descrição de alto nível dos componentes mostrados na RAN 120 e na CN 140 da Figura 1B. Entretanto, alguns destes componentes são notoriamente conhecidos na técnica a partir de diversas Especificações Técnicas (TSs) 3GPP, e a descrição aqui contida não pretende ser uma descrição exaustiva de toda funcionalidade executada por estes componentes.
[0058] Com referência à Figura 1B, as MMEs 142 e 144 são configuradas para gerenciar a sinalização no plano de controle para o EPS e para suportar mobilidade para os UEs que acessam a SN 140. As funções de MME incluem: sinalização de Estrato de Não Acesso (NAS), Segurança de Sinalização NAS, Gerenciamento de Mobilidade para handovers inter- e intra- tecnologia, seleção de PDGs e S-GW e seleção de MMEs para handovers com alteração de MME.
[0059] O S-WG 146 é o Gateway que termina a interface na direção da RAN 120 para sinalização no plano de usuário. Para cada UE anexado à CN 140 para um sistema baseado em EPS, em um dado ponto do tempo, há um único S- GW. As funções do S-GE 146 para S5/S8 baseado em Ipv6 Móvel Proxy (PMIP), incluem: ponto de âncora de Mobilidade, roteamento e emissão de Pacotes e estabelecimento do Ponto de código DiffServ (DSCP) baseado em um Identificador de classe QoS (QCI) da portadora EPS conexa.
[0060] Com referência à Figura 1B, o PDG 148 é p Gateway que termina a interface SGi na direção da Rede de Dados em Pacotes (PDN), como, por exemplo, a Internet 175. Se um UE estiver acessando várias PDNs pode haver mais de um PDG para esse UE. As funções do PDG 148 incluem: filtragem de Pacotes (por inspeção profunda de pacotes), alocação de endereços IP de UE, configuração do DS baseada na QCI na portadora EPS conexa, contabilidade para cobrança inter-operadora, vinculação de portadoras de uplink (UL) e downlink (DL), conforme definido no TS 23.203 do 3GPP e verificação de vinculação de portadoras UL conforme definido no TS 23.203 do 3GPP. O PDG 148 proporciona conectividade de PDN tanto com UEs exclusivos de Rede da Rádio-Acesso GSM/EDGE (GERAN)/UTRAN quanto com UEs capazes de LTE que utilizam uma RAN 120, que pode ser qualquer uma das E-UTRAN, GERAN ou UTRAN. O PDG 148 proporciona conectividade de PDN com UEs capazes de LTE que utilizam uma RAN que compreende eNBs, tal como a mostrada na Figura 1B (que é referida como E-UTRAN) através da interface S5/S8.
[0061] Com referência à Figura 1B, o GMLC/SLP 170 é mostrado como conectado à MME 142, ao PDG 148 na CN 140 e/ou à Internet 175. O GMLC/SLP 170 pode ser ou um GMLC ou um SLP ou pode ser um LRF com uma conexão ou associação com um GMLC ou SLP. Um GLMC 170 (ou um LRF 170 com um GLMC conexo ou conectado) suporta solução de localização no plano de controle LTE, enquanto um SLP 170 (ou um RLF 170 com um SLP conexo ou conectado) suporta a solução de localização SUPL. No caso de o GMLC/SLP 170 ser um GMLC, mas não um SLP, o GMLC/SLP 170 pode conectar-se a MME 142 e a um ou a ambos os PDG 148 e Internet 175. O GMLC/SLP 170 pode permitir que uma entidade externa, tal como o SP OTT 150, a ESInet 160 ou o PSAP 180, envie uma solicitação de localização ao GMLC/SLP para qualquer um dos UEs 1 a N na Figura 1A, pode coordenar determinação de localização para este UE utilizando a solicitação de localização no plano de controle 3GPP no caso de um GMLC ou SUPL no caso de um SLP e pode devolver a localização determinada à entidade externa solicitante. O E-SMLC 172 mostrado na Figura 1B é conectado à MME 142 e é outro servidor de localização utilizado para obter uma estimativa de localização de UE utilizando a solução de localização no plano de controle LTE.
[0062] Em uma solução de localização no plano de controle, um servidor de localização (o servidor de localização 170 da Figura 1A ou GMLC/SLP 170 da Figura 1B, por exemplo) é acessado por outros elementos, inclusive UEs, por meio de interfaces de sinalização existentes em uma rede. Toda a sinalização relacionada com a localização de um UE é explicitamente transportada como sinalização em todas as interfaces. No caso de acesso à LTE, a solução de localização no plano de controle é definida nos PSs 23.271 e 36.305 do 3GPP.
[0063] Em uma solução de localização no plano de usuário, tal como a solução SUPL, um UE de um servidor de localização tal como o GMLC/SLP 170 da Figura 1B se comunicam trocando dados da perspectiva da rede, tal como por meio do IP ou do TCP-IP. No caso da solução SUPL o GMLC/SLP 170 seria um SLP e seria utilizado para obter uma localização e não utilizar o E-SMLC 172. Em alguns casos, uma rede pode utilizar tanto uma solução de localização no plano de controle quanto uma solução de localização no plano de usuário, tal como SUPL. Neste caso, o E-SMLC 172 pode estar presente e o GMLC/SLP 170 pode compreender tanto um GMLC quanto um SLP. O GMLC e o SLP para o GMLC/SLP 170 podem ser também combinados (na mesma entidade física, por exemplo) ou podem ser conectados um ao outro, de modo a permitir que ambas as soluções sejam utilizadas para localizar um UE. Conforme já mencionado, o GMLC/SLP 170 pode corresponder também um RLF com associação ou conexão com um GMLC e/ou um SLP. UM RLF 170 conectado ou associado a um GMLC pode suportar localização no plano de controle de maneira semelhante a um GMLC, ao passo que um RLF 170 conectado ou associado a um SLP pode suportar localização no plano de usuário SUPL de maneira semelhante a um SLP.
[0064] A Aliança para Soluções Industriais de Telecomunicação (ATIS) está investigando maneiras de suportar chamadas 9-1-1 da próxima geração (NG911) que são estabelecidas por um UE por meio de um provedor de serviços OTT, como, por exemplo, o Skype®. Um problema principal é o de obter e fornecer uma localização precisa e confiável de um chamador 911 para permitir o roteamento de uma chamada NG911 pelo SP OTT ou na direção do PSAP correto e para permitir despacho pelo PSAP de suporte de segurança física para o local do usuário chamador. Uma vez que um SP OTT, tal como o SP OTT 150 terão frequentemente pouca ou nenhuma informação referente à rede de acesso utilizada pelo UE chamador, pode ser difícil para o SP OTT utilizar métodos de posicionamento terrestre (tais como WiFi, ID de Célula Aperfeiçoada (E-SID) e diferença de chegada observada (OTDOA) para localizar diretamente o UE chamador. Além do mais, quando um UE chamador está em ambiente interno, a localização do UE utilizando-se um Sistema de Posicionamento por Satélite (SPS), tal como o Sistema Global de Posicionamento (SPS), algum outro Sistema Global de Satélite de Navegação (GNSS) ou por meio de GPS Assistido (A-GPS) ou GNSS assistido (A-GNSS) pelo SP OTT pode ser também não confiável devido a uma dificuldade inerente na utilização de localização SPS em ambiente interno e/ou devido à falta de habilidade pelo SP OTT de controlar e/ou auxiliar a utilização da localização SPS.
[0065] Uma solução que pode ser utilizada por um SP OTT 150 para obter a localização de um UE que tem instigado uma chamada de emergência por meio do SP OTT 150 envolve a consulta pelo SP OTT 150 de um servidor de localização na rede de acesso (tal como o servidor de localização 170 da Figura 1A ou o GMLC/SLP 170 da Figura 1B) para obter a localização do UE chamador, se SP OTT 150 for fornecido ou puder inferir o endereço deste 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 (em um CONVITE de SIP utilizado para estabelecer a chamada NG 911, por exemplo), o fornecimento pelo UE de sua localização diretamente ao SP OTT 150 pode ser uma solução atraente, uma vez que: a) os novos impactos nos padrões (padrões 3GPP, por exemplo) podem ser restritos; b) os impactos de implementação na redes RAN e CN de operadora de rede móvel (MNO) podem ser baixos ou zero; c) os UEs suportam tipicamente uma capacidade de localização independente de qualquer maneira (uma solução auxiliada por um vendedor de sistema operacional de UE ou vendedor de chips de UE, por exemplo) e, d) a solução pode ser um bom encaixe com padrões NG 911 existentes que permitem o fornecimento pelo UE da localização de UE em um CONVITE enviada para instigar uma chamada de emergência.
[0066] A localização fornecida pelo UE (incluída em um CONVITE de SIP, por exemplo) pode ser por valor (o UE fornece suas coordenadas de latitude e longitude diretamente, por exemplo) ou por referência. Para localização por referência, o UE fornece um Identificador de Recursos Uniformes (URI)(originalmente obtido pelo UE de um servidor de localização e aqui referido como “URI de localização” que contém o nome e o endereço de um servidor de localização, uma referência única ao UE que pode ser atribuído pelo servidor de localização e uma indicação do protocolo a ser utilizado para obter a localização do UE do servidor de localização. Um “URI de localização” é aqui referido de maneira intercambiável como “referência de localização” e como “localização com referência”. Um “URI de localização” pode ser conforme definido pelo IETF na Solicitação de Comentário (RF) 3986 e 5808 e pode compreender uma cadeia de caracteres que se conforma a regras na RFC 3986 que codificam a identificação de um nome de esquema ou nome de protocolo tal como o SIP ou HTTP e uma identificação de um recurso que pode compreender a identificação (nome ou endereço de percurso da Internet, por exemplo) de um servidor de localização mais a identificação de um UE.
[0067] A identificação do UE, também aqui referida como “referência de UE”, “referência de um UE local” ou “referência local” pode compreender caracteres que identificam o UE para o servidor de localização, mas oculta a identidade verdadeira do UE de outras entidades e pode ser atribuído localmente pelo servidor de localização. Um UE pode solicitar e obter um URI de localização de um servidor de localização utilizando um protocolo de configuração de localização tal como o protocolo de Entrega de Localização Habilitada pelo HTTP (HELD) definido no documento IETF RFC 5985. Um UE pode transmitir um URI de localização para outra entidade, tal como o SP OTT 150, a ESInet 160 ou PSAP 180 na Figura 1A e na Figura 1B utilizando um protocolo de transmissão de localização, tal como um SIP definido no documento IETF RFC 6442. A entidade que recebe um URI de localização para um UE (o SP OTT 150, a ESInet 160 ou PSAP 180 da Figura 1A e da Figura 1B, por exemplo) pode utilizar um protocolo de referência de localização, tal como o SIP, o HTTP ou o HELD, para solicitar e receber a localização do UE (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 um endereço de rua (e possivelmente um número de andar, um número de quarto, número de suíte, etc., por exemplo)) do servidor de localização. Com referências 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 à entidade solicitante.
[0068] A solução de localização com referência pode ser mais atraente que a solução de localização por valor uma vez que permite mais tempo para um UE ou um servidor de localização obter a localização para o UE e pode ser utilizada para obter mais de uma localização para o UE em tempos diferentes. Por exemplo, a solução de localização por referência pode ser utilizada pelo SP OTT 150 para obter inicialmente uma localização de UE aproximada para auxiliar o roteamento e em um momento posterior ter uma localização de UE mais precisa para o despacho do PSAP.
[0069] Uma solução de localização por referência pode ter impactos significativos em um UE e em um servidor de localização, que podem precisar ambos, suportar (a) um protocolo de configuração de localização, tal como HELD pelo qual um UE pode solicitar e um servidor de localização pode fornecer um URI de localização e (b) um dispositivo para o servidor de localização aumentar a identidade do UE quando a consulta/resposta em (a) ocorre. O impacto em (b) pode ser necessário uma vez que o servidor de localização pode precisar identificar de maneira segura o UE no momento em que um URI de localização é atribuído de modo a se localizar o UE correto (e não algum outro UE, por exemplo) em algum momento posterior quando um cliente (o SP OTT 150 ou PSAP 180, por exemplo) solicita a localização do UE consultando o servidor de localização com o URI de localização. Alguns protocolos de configuração de localização como o HELD pode exigir ou suportar normalmente a autenticação em (b) uma vez que o endereço IP do UE para o qual um URI de localização é fornecido pode estar disponível a um servidor de localização do UE quando (a) ocorre e pode ser considerado se confiável o bastante para identificar e localizar o UE em um momento posterior quando o URI de localização tem a sua referência anulada posteriormente pelo SP OTT 150, pela ESInet 160 ou PSAP 180 (utilizando HELD, por exemplo).
[0070] Entretanto, um endereço IP pode ser falsificado. Por exemplo, uma entidade que não é um UE, mas é capaz de interceptar comunicações IP para e de UE pode utilizar um protocolo de configuração de localização para obter um URI de localização para um UE enviando uma solicitação de localização para um servidor de localização que contém o endereço IP para o UE. A entidade pode então ou (i) mascarar-se como um SP OTT 150 para obter a localização do UE enviando uma solicitação de anulação de referência ao servidor de localização contendo o URI de localização obtido ou (ii) instigar uma chamada de emergência e fornecer o URI de localização a SP OTT 150 para provocar o despacho de segurança pública para a localização do UE embora o UE não tenha feito a chamada de emergência.
[0071] Além disso, mesmo quando o endereço IP para um UE está correto e quando a entidade que solicita a local do UE é legítima, um servidor de localização pode exigir uma identidade diferente para o UE de modo a obter a localização do UE e/ou identificar corretamente o UE posteriormente. Por exemplo, se o servidor de localização utilizar uma solução de localização do plano de controle para obter a localização de um UE (a solução de localização no plano de controle 3GPP para LTE, por exemplo), o servidor de localização pode precisar de uma identidade conexa sem fio para o UE, tal como um Número Internacional de Assinante Móvel (IMSM) ou um Número Temporário de Assinante Móvel (TMSI), em vez do endereço IP do UE. Além disto, se for necessário identificar posteriormente um UE para fins de cobrança ou tarifação (para permitir que o SP para o servidor de localização cobre do SP OTT 150, por exemplo) ou acompanhamento posterior se a localização obtida estiver incorreta ou para fins estatísticos e de contabilidade, então alguma identidade global permanente para o UE pode ser necessária, mas que não seja um endereço IP. De modo a assegurar que o servidor de localização tenha a identidade correta para o UE e que o URI de localização esteja sendo fornecido ao UE correto e não a uma entidade que se mascara como o UE. O impacto de autenticação entre o (b) pode ser necessário. Os impactos duplos de (a) e (b) podem tornar a solução de localização por referência (definida pelos documentos IETF RFCs mencionados aqui acima, por exemplo) complexa tanto para vendedores de UE IMNOs ou seus vendedores de servidor de localização.
[0072] Uma solução para o problema descrito acima para utilização de uma referência seria a de que uma rede de acesso servidora, e não um servidor de localização fornecesse a um UE uma localização por referência de pois que o UE (e sua identidade) tiver sido autenticado pela rede de acesso. A autenticação de um UE pela rede de acesso é uma parte típica da operação de rede sem fio que é ou pode ser suportada para muitos tipos de rede sem fio (GSM, UMTS, LTE, IEEE 802.11) e consequentemente pode não acrescentar impactos novos 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 correr (i) imediatamente depois que um UE tiver se anexado com sucesso à rede de acesso e tiver sido autenticado (ii) periodicamente, enquanto o UE é anexado à rede de acesso (para permitir que uma localização anterior por referência seja substituída com base em um servidor de localização diferente e/ou uma referência de UE local diferente) e/ou (iii) sob solicitação pelo UE enquanto o UE é anexado à rede de acesso.
[0073] Em uma modalidade, uma rede de acesso pode comunicar-se com um servidor de localização de modo a obter uma localização por referência para um UE. Nesta modalidade, a rede de acesso pode atuar como um proxy e obter uma localização por referência do servidor de localização em favor do UE. O UE e o servidor de localização não precisariam então suportar um protocolo de configuração de localização para permitir que o UE obtenha um URI de localização do servidor de localização. Em vez disso, o UE obteria o URI de localização da rede de acesso e a rede de acesso obteria o URI de localização do servidor de localização. Embora esta modalidade possa adicionar uma interface de rede de acesso-servidor de localização, ela pode evitar a necessidade de suportar um protocolo de configuração de localização e autenticação do UE tanto pelo UE quanto pelo servidor de localização e pode ser assim uma solução mais simples do que ter o UE consultando diretamente o servidor de localização utilizando um protocolo de configuração de localização tradicional.
[0074] Em outra modalidade, uma rede de acesso pode atribuir uma localização por referência a um UE propriamente dito sem envolvimento de um servidor de localização. Por exemplo, a rede de acesso (a MME 142, por exemplo) pode criar um URI de localização que inclui o endereço conhecido ou identidade conhecida (um nome de percurso de Internet, por exemplo) de um servidor de localização-alvo (o servidor de localização 170 na Figura 1A ou GMLC/SLP 170 na Figura 1B, por exemplo), o esquema ou protocolo a ser utilizado para consultar o servidor de localização a partir de um cliente e (como uma extensão do endereço ou identidade do servidor de localização) uma referência de UE que identifica o UE. Em um 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 aqui descrita, uma referência de UE pode ser atribuída pela rede de acesso e pode compreender uma identificação de UE global, tal como o endereço IP do UE, a IMSI para o UE e/ou uma entidade para o UE conhecida da rede de acesso, tal como uma TMSI, um endereço local para o UE atribuído por um nó de rede de acesso (uma MME ou SGSN, por exemplo) e/ou o endereço de um nó de rede de acesso ou qualquer combinação deles. A referência de UE pode incluir também a data e a hora da atribuição e/ou pode ser cifrada para proteger a privacidade do usuário (no caso de as teclas de cifra serem conhecidas da rede de acesso e do servidor de localização, mas não de outras partes, por exemplo). No caso de a referência de UE compreender um TMSI ou endereço IP, a cifragem pode não ser necessária uma vez que a verdadeira identidade do UE (O IMSI do UE, por exemplo) não é incluída na referência de UE e assim pode não estar disponível para outras partes. O URI de localização pode ser também digitalmente assinado pela rede de acesso (pode incluir uma assinatura digital, por exemplo) de modo que o servidor de localização que é 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 tanto cifrado quanto assinado digitalmente, por exemplo, utilizando-se o Contador do Instituto Nacional Norte- Americano de Padrões e Tecnologia (NIST) com um método de Encadeamento de Blocos de Cifragem/Código de Autenticação de Mensagens (CCM).
[0075] A utilização das modalidades acima pode afetar apenas a rede de acesso e o servidor de localização.Consequentemente, uma MNO pode migrar da segunda modalidade, na qual uma rede de acesso atribui um URI de localização sem envolvimento de um servidor de localização, para a primeira modalidade na qual uma rede de acesso atua como um proxy para um servidor de localização sem afetar outras entidades (inclusive UEs, por exemplo). Em alguns casos, a migração da MNO pode ser da primeira modalidade para a segunda modalidade. No caso de a rede de acesso suportar a LTE e pertencer a uma MNO celular, a localização por referência por um UE pode ser atribuída a uma MNE servidora para o UE, tal como a MNE 142 da Figura 1B. A atribuição pode ocorrer como parte da anexação da rede LTE pelo UE e/ou como parte de uma atualização de á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 algumas mensagens de Estrato de Não-Acesso (NAS) utilizadas para suporte LTE e pode ter um impacto pequeno tanto para UE quanto para rede de acesso (MMEE, por exemplo). O benefício desta solução para MNOs e vendedores de UE pode ser que os impactos para suportar a solução podem ser limitados e uma solução de localização flexível pode ser oferecida a SPs OTTs que se encaixa com padrões existentes.
[0076] Novamente com referência às Figuras 1A e 1B, a Figura 2A mostra interações específicas das entidade de rede mostradas na Figura 1A e na Figura 1B. No caso de acesso à LTE, de modo a se obter uma localização por referência para uma chamada de emergência OTT de acordo com as modalidades aqui descritas. Com referência à Figura 2S, o termo “rede de acesso” refere-se à RAN 120 e à CN 140. O nó de rede de acesso 140 pode ser alguma entidade na rede de acesso, tal como um nó de acesso, um ponto de acesso, uma estação base, um eNóB (122, 124 ou 126, por exemplo) uma femto-célula, uma MME (a MME 142, por exemplo), etc.O nó de rede de acesso pode estar dentro da RAN 120 ou dentro da CN 140.
[0077] Em 202A, um UE 200 (que pode corresponder a qualquer um dos UEs 1 a N da Figura 1, por exemplo) 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, como, por exemplo, Skype, instalado no UE 200. Em 206A, o UE 200 envia uma solicitação de 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 que o UE 200 (utilizando uma Interface de Programação de Aplicativo (API) com um modem no UE 200, por exemplo) obtenha uma referência de localização.
[0078] 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 (o GMLC/SLP 170 ou UE-SMLC 172, por exemplo) para uma referência de localização para o UE 200 e receber de volta um resposta do servidor de localização 170 em 212A que contém uma referência de localização. Neste caso, o nó de rede de acesso 140 atua como um proxy de modo a obter a referência de localização do servidor de localização 170 em favor do UE 200 no bloco 208A. A solicitação/resposta no bloco 208A pode utilizar uma conexão segura entre o servidor de localização 170 e o (N-M) de rede de acesso 240 que permite que o servidor de localização 170 esteja ciente de que um nó de rede de acesso, cuja operadora pode ser a mesma do servidor de localização 170 , está solicitando a referência de localização. A conexão segura entre o servidor de localização e o nó de rede de acesso 240 pode utilizar uma relação de confiança entre o servidor de localização 170 e o nó de rede de acesso, como, por exemplo, uma relação baseada no pertencimento do nó de rede de acesso 240 e do servidor de localização 170 ao mesmo SP ou à mesma operadora de rede, e pode utilizar credenciais de segurança pré-configuradas em cada entidade para permitir o estabelecimento da conexão segura. O servidor de localização 170 podem então atribuir e devolver uma referência de localização no bloco 208A (que pode incluir uma referência de UE que é local ao servidor de localização 170, por exemplo) que pode ser posteriormente utilizada (pelo SP OTT 150, por exemplo) para obter uma localização para o UE 200 do servidor de localização 170, conforme descrito mais adiante.
[0079] Embora o bloco 208A adicione uma nova interface entre o nó de rede de acesso 240 e o servidor de localização 170, ele evita a necessidade de o servidor de localização 170 interagir com o e autenticar o UE 200. Em algumas modalidades, o nó de rede de acesso 240 e o servidor de localização 170 pode utilizar um de 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 ao UE 200. Em algumas modalidades, o UE 200 (um modem no UE 200, por exemplo) pode fornecer a referência de localização ao aplicativo OTT.
[0080] Em algumas modalidades, em vez de consultar o servidor de localização 170 quanto à referência de localização do UE 200, o nó de rede de acesso 240 pode atribuir a referência de localização propriamente dita sem envolvimento do servidor de localização 170, conforme aqui descrito anteriormente. O nó de rede de acesso 240 pode cifrar a parte de referência de UE da referência de localização e/ou assinar digitalmente a referência de localização conforme aqui também descrito. Neste caso, quaisquer teclas de cifragem/decifração /e teclas para uma assinatura digital podem ser conhecidas tanto do nó de rede de acesso 240 quanto do servidor de localização 170 mas não de outras partes.
[0081] As mensagens em 206A, 208A e 212A são mostradas como opcionais (indicadas pelas linhas tracejadas) na Figura 2A uma vez que não precisam ocorrer nos tempos específicos mostrados na Figura 2A. Em vez disso, como exemplo, 206A e 212A (e opcionalmente 208A) podem ser executados durante a anexação em 202A, e possivelmente antes de o usuário fazer uma chamada de emergência em 204A, tal como imediatamente depois que o UE 200 tiver se anexado com sucesso ao nó de rede de acesso 240 e tiver sido autenticado, ou como parte de uma troca de mensagens 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 de referência de localização em uma mensagem enviada ao nó de rede de acesso 240 para solicitar, responder a ou confirmar a anexação do UE 200 ou autenticação do UE 200. Da mesma maneira, o nó de rede de acesso 240 pode incluir uma referência de localização atribuída em uma mensagem enviada ao UE 200 para solicitar, responder a ou confirmar a anexação do UE ou a autenticação do UE 200.
[0082] Como outro exemplo, 206A e 212A (e opcionalmente 208A) podem ser executados periodicamente enquanto o UE 200 é anexado ao nó de rede de acesso 240 e não em resposta a execução de uma chamada de emergência pelo usuário. Por exemplo, 206A, 212A e possivelmente 208A podem ser executados sempre que o UE 200 e o nó de rede de acesso 240 precisarem interagir para suportar mobilidade para o UE 200. Em outro exemplo, 206A, 212A e possivelmente 208A podem ser executados quando sempre que o UE 200 mude para um novo nó de rede de acesso (mude de um nó de rede de acesso anterior para um nó de rede de acesso 240 ou do nó de rede de acesso 240 para um novo nó de rede de acesso, por exemplo). Como ainda outra exemplo, 206A e 212A podem corresponder a alguma outra interação existente entre o UE 200 e o nó de rede de acesso 240, tal como uma atualização de área de rastreamento para LTE ou uma atualização de área de roteamento para GPRS e/ou UMTS. Alternativamente, conforme mostrado na Figura 2A, 206 e 212A podem compreender novas mensagens utilizadas para obter a referência de localização.
[0083] Em algumas modalidades, antes de enviar a referência de localização ao 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 assegurar que a referência de localização seja devolvida em 212A ao UE 200 correto. Além disto, tal autenticação do UE 200 pode formar uma parte normal do suporte de acesso pelo UE 200 a serviços providos pelo nó de rede de acesso 240, tal como o suporte de anexação e mobilidade de rede para o UE 200, por exemplo, e pode não adicionar impactos adicionais ao UE 200 ou ao nó de rede de acesso 240 unicamente para fins de devolver uma referência de localização de 212A.
[0084] Em 214A, o UE 200 envia ao SP OTT 150 uma solicitação da chamada de emergência, e inclui a referência de localização do UE 200. Em algumas modalidades, a solicitação da chamada de emergência pode ser transferida pelo UE 200 para o SP OTT 150 por meio do nó de rede de acesso 240 ou por meio da rede de acesso para um nó de rede de acesso 240. Embora não mostrado na Figura 2A, o UE 200 pode obter a referência de localização de um nó de rede de acesso 240 para uma primeira rede de acesso pertencente a uma primeira operadora de rede (que pode possuir também o servidor de localização 170) e/ou que se conforma a uma primeira tecnologia de rádio-acesso (RAT) e enviar a solicitação da 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 pertencente a uma segunda operadora de rede e/ou que se conforma a uma segunda RAT. Dessa maneira, a referência de localização pode ser compartilhada e/ou pode ser válida para várias redes de acesso, várias RATs e/ou várias operadoras de rede e pode permitir que o UE 200 utilize a mesma referência de localização depois do handoff para uma nova RAT ou para uma nova rede e/ou quando acessa várias redes ou várias RATs ao mesmo tempo. Por exemplo, o UE 200 pode obter a referência de localização de uma estação base ou de outro nó servidor (uma MME, por exemplo) pertencente a uma rede de acesso celular pertencente a uma operadora de rede A, e enviar a solicitação da chamada de emergência, que inclui a referência de localização, a um ponto de acesso WiFi em uma rede de acesso WLAN pertencente a uma operadora de rede B (onde a operadora A pode ser ou não idêntica à operadora B), que emitiria a solicitação de chamada de emergência para o SP OTT 150.
[0085] Em 216A, o SP OTT 150 envia uma solicitação de localização (ou uma solicitação para anular a referência de localização), que inclui a referência de localização recebida do nó de rede de acesso 240 em 214A, ao servidor de localização 170. O SP OTT 150 170 pode identificar o servidor de localização 170 (identificar um endereço ou um nome de percurso para o servidor de localização 170, por exemplo) 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 que a referência de localização corresponde a uma referência de localização atribuída anteriormente ao servidor de localização 170 (atribuída como parte do bloco 208A se o bloco 208A ocorrer, por exemplo. 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 tiver sido atribuída pelo nó de rede de acesso 240 e não pelo servidor de localização 170 (tal como ocorre se o bloco 208A não estiver presente, por exemplo), o servidor de localização 170 pode verificar que o nó de rede de acesso 240 atribuiu à referência de localização verificando qualquer assinatura digital, se presente na referência de localização e/ou decifrando a parte de referência de UE da referência de localização e verificando que a parte de referência de UE decifrada se conforma corretamente a quaisquer regras de formatação ou codificação para uma referência de UE válida.
[0086] Em 218A, o servidor de localização 170 (um GMLC associado ou conectado ao servidor de localização 170 no caso de o 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 tinha atribuído à referência de localização recebida em 216A ou (ii) parte ou toda de uma referência de UE ou referência de UE decifrada recebida como parte de uma referência de localização em 216A se o nó de rede de acesso 240, e não o servidor de localização 170 tiver atribuído à referência de localização. O nó de nó de rede de acesso 240 pode obter então uma estimativa de localização para o UE 200 (identificado pelo servidor de localização 170 em 218A) se outra entidade (não mostrada na Figura 2A). Por exemplo, o nó de rede de acesso 240 pode solicitar uma estimativa de localização de outro servidor de localização (o E-SMLC 172, por exemplo) ou de outra entidade capaz de localização (a RAN 120, por exemplo) ou de uma estação base ou um AP que serve ao UE 200. Alternativamente, o nó de rede de acesso 240 já pode ter informações de localização para o UE 200 propriamente dito (se o nó de rede de acesso 240 for uma estação base ou AP WiFi que serve o UE 200, por exemplo). O nó de rede de acesso 240 pode devolver então a estimativa de localização para o UE 200 ao servidor de localização 170 (ou a um GMLC associado ou conectado a um servidor de localização 170 no caso de o 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 utiliza uma solução de localização no plano de controle de modo a obter a localização do UE 200.
[0087] Em vez ou além de consultar o nó de rede de acesso 240 quanto à 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 um SLP SUPL ou uma RFL conectada ou associada a um SLP, onde o SLP instiga uma sessão de localização no plano de usuário SUPL em 222A com o UE 200 de modo a obter medições relacionadas com localização do UE 200 (medições de GPS ou satélites GNSS e/ou medições de estações base e/ou APs na rede de acesso para o UE 200, por exemplo) que o servidor de localização 170 pode utilizar para determinar a localização para o UE 200. Por exemplo, o UE 200 pode fornecer medições de GPS e diferença de tempo de chamada observada (OTDOA) ao servidor de localização. A OTDOA é um método de multilateração no qual o UE 200 mede a diferença de tempo entre sinais específicos de pares de estações base e relata as diferenças de tempo medidas ao servidor de localização 170, que computem então a localização do UE 200. Alternativamente, o servidor de localização 170 (ou um SLP associado ou conectado ao servidor de localização 170 no caso de o servidor de localização 170 ser uma LRF) pode instigar uma sessão de SUPL com o UE 200 em 222A de modo a obter a localização do UE 200, em que o UE 200 obtém a localização de medições relacionadas com localização, tais como medições de GPS, GNSS e/ou OTDOA. Em 224A, o servidor de localização 170 envia a localização do UE 200, obtida 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 utilizar um de SIP, HELD ou MLP em 216A e 224A para solicitar e devolver a localização do UE 200. Em alguma destas modalidades nas quais o SIP ou HELD é utilizado, a utilização do SIP ou HELD pode ser definida como parte da referência de localização.
[0088] Os fluxos de mensagens em 216A a 2224A podem ocorrer nos tempos mostrados na Figura 2A para permitir que o SP OTT 150 obtenha a localização do UE 200 de modo a auxiliar o roteamento da chamada de emergência (determinando um PSAP 180, por exemplo) com uma cobertura de serviços de emergência que inclui a localização do UE 200, por exemplo) e/ou de modo a fornecer a localização do UE 200 à ESInet 160 ou ao PSAP 180. Os fluxos de mensagens em 216A a 224A são opcionais, uma vez que eles podem ocorrer, alternativa ou adicionalmente, depois que a chamada de emergência iniciada em 204 é estabelecida (isto é, depois de 228A) se o SP OTT 150 receber uma servidor de localização para o UE 200 do PSAP 180 e precisar consultar o servidor de localização 170 de modo a obter e devolver a localização atual do UE 200 (não mostrado na Figura 2A). Além disto, fluxos de mensagens análogos à 216A a 224A podem ocorrer (em vez ou além dos fluxos de mensagens em 216A a 224A) para permitir que a ESInet 160 ou o PSAP 180 solicite diretamente a localização do UE 200 do servidor de localização 170. Estes fluxos de mensagens análogos podem ser idênticos ou quase idênticos à 216A a 224A, exceto pelo fato de que a ESInet 160 ou o PSAP 180 pode substituir o SP OTT 150 nos fluxos de mensagens em termos do envio da servidor de localização em 216A e de recebimento da resposta de localização em 224A.
[0089] Voltando à chamada de serviço de emergência mostrada na Figura 2A, em 226A, o SP OTT 150 roteia a chamada de emergência para a ESInet 160 apropriada ou possivelmente SR 160 se pelo SP OTT a chamada em uma chamada de emergência CS. A ESInet 160 (ou um SR 160) roteia a chamada de emergência para o PSAP 180 apropriado. 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 utilizar a localização do UE 200 obtida em 224A, se executado para rotear a chamada de emergência iniciada em 204A para a ESInet 260 apropriada (ou para o SR 160). A ESInet 160 pode utilizar a referência de localização do UE 200 recebida na solicitação de chamada de emergência para obter a localização para o UE 220 do servidor de localização 170 executando etapas análogas a 216A a 224A, conforme já descrito. A ESInet 160 pode utilizar então a localização obtida para rotear a chamada de emergência para o PSAP 160 apropriado.
[0090] Em 228A, as diversas entidades de rede (o UE 200, o SP OTT 150, a ESInet 160 e o PSAP 180, por exemplo, executam o restante o 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 utiliza a referência de localização para buscar a localização do UE 200 (buscar a localização obtida anteriormente em 218A e/ou 222A, por exemplo) e responde com a localização do UE 200. Alternativamente, o servidor de localização 170 pode obter a localização do UE 200 executando etapas (não mostradas na Figura 2A) que são idênticas às mostradas em 218A e/ou 222A.
[0091] Novamente com referência à Figura 1B, a Figura 2B mostra interações específicas das entidades mostradas na Figura 1B de modo a se obter uma localização por referência para uma chamada de emergência OTT de acordo com as modalidades aqui descritas. As interações da Figura 2B são semelhantes às descritas para a Figura 2A, mas referem-se especificamente a um UE 200 com acesso à LTE. Em contraste, as interações descritas em associação com a Figura 2A podem aplicar-se a um UE 200 com qualquer tipo de acesso sem fio ou de linha de fios elétricos, inclusive, mas não limitado a, acesso à LTE.
[0092] Em 202B, o UE 200 se anexa a uma rede servidora capaz de LTE e, como parte do procedimento de anexação, envia uma Solicitação de Anexação NAS ao MME Servidora 142. A Solicitação de Anexação NAS inclui uma solicitação de referência de localização em algumas modalidades. Em 204B, a MME 242 pode enviar opcionalmente uma solicitação de referência de localização ao GMLC/SLP 170. O GMLC/SLP 170 pode ser um GMLC se a localização do UE 200 vier a ser obtida utilizando-se uma solução de localização no plano de controle, pode ser um SLP se a localização do UE 200 for obtida utilizando-se SUPL pode ser um GMLC e um SLP combinados se ou uma ou outra ou ambas a localização no plano de controle e a SUPL forem utilizadas para obter a localização para o UE 200, ou pode ser uma LRF com uma conexão ou associação com um GMLC e/ou um SLP. Quando 204B é executado, a MME 142 atua como um proxy para obter a referência de localização com GMLC/SLP 170 em favor do UE 200. Embora isto adicione uma nova interface entre a MME 142 e o GMLC/SLP 170, evita a necessidade do UE 200 para obter a referência de localização do GMLC/SLP 170 e evita a necessidade do GMLC/SLP 170 para autenticar o UE 200 como parte de uma solicitação do UE 200 para obter uma referência de localização.
[0093] Uma solicitação/resposta no bloco 204B pode utilizar uma conexão segura entre o GMLC/SLP 170 e a MME 142 que permite que o GMLC/SLP 170 esteja ciente de que uma MME (pertencente à mesma operadora ou SP do GMLC/SLP 170, por exemplo) está solicitando a referência de localização. A conexão segura entre o GMLC/SLP 170 e a MME 142 pode utilizar uma relação de confiança entre o GMLC/SLP 170 e a MME 142, por exemplo, uma relação baseada no pertencimento da MME 142 e do GMLC/SLP ao mesmo SP ou à mesma operadora de rede, e pode utilizar credenciais de segurança pré-configuradas em cada entidade para permitir o estabelecimento da conexão segura. O GMLC/SLP 170 pode atribuir e devolver então uma referência de localização (que pode incluir uma referência de UE que é local ao GMLC/SLP, por exemplo) que permitira posteriormente que o GMLC/SLP 170 forneça a localização do UE 200 a outra entidade, por exemplo, nos blocos 214B e 232B descritos em seguida. Em algumas modalidades, a MME 142 e o GMLC/SLP 170 podem utilizar um do SIP, HELD ou o protocolo de localização móvel (MLP) definida pela OMA para solicitar e devolver a referência de localização em 204B.
[0094] Em 206B, a MME 142 envia a referência de localização obtida do GMLC/SLP 170 ao UE 200 em uma mensagem de Aceitação de Anexação NAS. A Solicitação de Anexação NAS em 202B e Aceitação de Anexação NAS em 206B podem ser conforme definidas no documento TS 23.401 e no documento TS 24.301 do 3GPP, com o acréscimo de um parâmetro de solicitação de referência de localização em uma Solicitação de Anexação NAS e/ou um parâmetro de referência de localização em uma Aceitação de Anexação NAS. Em algumas modalidades, os blocos 204B e 206B só podem ser executados quando a Solicitação de Anexação NAS e, 202B contiver uma solicitação de referência de localização. Em outros modalidades, os blocos 204B e 206B podem ser executados quando a Solicitação de Anexação NAS em 202B não contiver uma solicitação de referência de localização.
[0095] Alternativamente, em vez de consultar GMLC/SLP 170 quanto à referência de localização do UE 200 em 204B, a MME 142 pode atribuir a referência de localização propriamente dita sem envolvimento do GMLC/SLP 170, conforme descrito acima. A 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 utilizado para consultar o GMLC/SLP 170 de um cliente, e uma referência de UE para identificar o UE 200 (o endereço IP do UE 200, o MSI do UE 200, o TMSI do UE 200, o endereço local para o UE 200 atribuído pela MME 142, um endereço da MME 142 ou qualquer combinação deles, por exemplo). A MME 142 pode cifrar a referência de UE para proteger a privacidade do usuário. Neste caso, as teclas de cifragem serão conhecidas da MME 142 e do GMLC/SLP 170, mas não de outras partes. A MME 142 pode também assinar digitalmente a referência de localização de modo que o GMLC/SLP 170170 saiba que a referência de localização foi atribuída pela MME 142 ou pelo menos foi atribuída por alguma entidade gerenciada pela operadora ou SP para o GMLC/SLP 170.
[0096] Além 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 que os usuário do UE 200 iniciar uma chamada de emergência (208B), periodicamente enquanto o UE estiver 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.
[0097] Em vez de enviar a Solicitação de Anexação NAS em 202B e a Aceitação de Anexação NAS 206B de modo a obter a referência de localização, o UE 200 pode enviar uma Solicitação de Atualização de Área de Rastreamento NAS em 202B e, depois de obter ou atribuir uma referência de localização (em 204B, por exemplo), a MME 142 pode enviar uma Aceitação de Atualização de Área de Rastreamento NAS em 206B contendo a referência de localização. A Solicitação de Atualização de Área de Rastreamento NAS em 202B e a Aceitação de Atualização de Área de Rastreamento NAS em 206B podem ser conforme definidas nos documentos TS 23.401 e TS 24.301 do 3GPP com o acréscimo de uma solicitação de referência de localização em uma Solicitação de Atualização de Área de Rastreamento NAS e/ou de uma referência de localização em uma Aceitação de Atualização de Área de Rastreamento NAS.
[0098] Em algumas modalidades, antes de enviar a referência de localização ao UE 200 em uma Aceitação de Anexação NAS ou Aceitação de Atualização de Área de Rastreamento NAS em 206B, a MME 242 pode identificar a identidade do UE 200 (não mostrado na Figura 2B). Tal autenticação pode assegurar que a referência de localização seja devolvida em 206B ao UE 200 correto. Além disto, tal autenticação do UE 200 pode formar uma parte normal do suporte à anexação do UE 200 ou da atualização da área de rastreamento do UE 200 pelo UE 200 e pela MME 142 e pode não acrescentar impactos adicionais ao UE 200 ou à MME 142 unicamente para fins de devolver a referência de localização em 206B.
[0099] Para redes de acesso que suportam GSM ou UMTS em vez de LTE, o procedimento na Figura 2B pode ser utilizado para suportar uma chamada de emergência OTT conforme aqui descrito para uma rede LTE com o E-SMLC 172 substituído por uma RAN GSM ou UMTS e com a MME 142 substituída por um Nó de Suporte de GPRS Servidor (SGSN). Nesse caso, o UE 200 enviaria ou uma solicitação de anexação GPRS ou uma solicitação de atualização de área de roteamento GPRS ao SGSN em 202B que pode conter uma solicitação de referência de localização, e o SGSN responderia ou com uma aceitação de anexação GPRS ou Aceitação de Atualização de Área de Roteamento GPRS, respectivamente, em 206B. Neste caso, a Solicitação de Anexação GPRS ou Solicitação de Atualização de Área de Roteamento GPRS em 202B e a Aceitação de Anexação GPRS ou Aceitação de Atualização de Área de Roteamento GPRS em 206B podem ser conforme definidas no documento TS 24.008 do 3GPP, com o acréscimo de uma solicitação de referência de localização em uma Solicitação de Anexação GPRS ou Solicitação de Atualização de Área de Roteamento GPRS e/ou de uma referência de localização em uma Aceitação de Anexação GPRS ou Solicitação de Atualização de Área de Roteamento GPRS.
[0100] Em 208B, o usuário do UE 200 faz uma chamada de emergência por meio de um aplicativo OTT, tal como o Skype® instalado no UE 200. Em 212 B, o UE 200 envia uma solicitação da chamada de emergência, que inclui a referência de localização obtida em 206B ao SP OTT 150. Por exemplo, o UE 200 pode enviar a solicitação da chamada de emergência ao SP OTT 150 por meio do eNB 124 do S-GW 146, do PDG 148 e da Internet 175. Em uma modalidade, o UE 200 pode obter a referência de localização da MME 142, conforme descrito acima, e enviar a solicitação da chamada de emergência que contém a referência de localização ao SP OTT 150 em 212 B 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 da LTE (WiFi, por exemplo). Dessa maneira, a referência de localização pode ser compartilhada entre redes de acesso diferentes e possivelmente entre RATs diferentes no UE 200. Por exemplo, o UE 200 pode enviar a solicitação da chamada de emergência que inclui a referência de localização ao SP OTT 150 por meio de um ponto de acesso WLAN.
[0101] 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 (identificar o endereço ou um nome de percurso para o GMLC/SLP 170, por exemplo) 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 que a referência de localização corresponde à referência de localização atribuída anteriormente pelo GMLC/SLP 170 (atribuída como parte do bloco 204B se o bloco 204B ocorrer, por exemplo). 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 215B tiver sido atribuída pela MME 142 e não pelo GMLC/SLP 170 (tal como ocorre se o bloco 204B não estiver presente, por exemplo) o GMLC/SLP 170 pode verificar que a MME 142 atribuiu a referência de localização (i) verificando qualquer assinatura digital, se presente na referência de localização, (ii) decifrando a parte de referência de UE da referência de localização e verificando que a parte de referência de UE decifrada se conforma corretamente a quaisquer regras de formatação ou codificação para uma referência de UE válida e/ou (iii) verificando que a referência de localização se conforma com regras de formatação conhecidas (contém um referência de UE cujo comprimento e conteúdo em caracteres se conforma a regras conhecidas, por exemplo).
[0102] Se a solução de localização no plano de controle estiver sendo utilizada ( o que significa que o GMLC/SLP 170 é ou contém um GMLC/SLP 170 ou é uma LRF conectada ou associada a um GMLC) então os fluxos de mensagens em 216B a 226B são executados (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 da MME 142 de modo a enviar corretamente a solicitação em 216B do conteúdo da referência de UE na referência de localização recebida em 214B (se a MME 142 ou o GMLC 170 tiver incorporado o endereço ou identidade da MME 142 na referência de localização, por exemplo). Alternativamente, o GMLC 170 pode consultar um sob Servidor de Assinante Nativo (HSS) para o UE 200 quanto ao endereço da MME 142 (não mostrado na Figura 2B) utilizando um identificador (IMSI, por exemplo) para o UE 200 recebido em 214B na parte 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 foi ou incluída na parte de referência de UE na referência de localização recebida em 214B ou foi recebida anteriormente em 204B e armazenada pelo GMLC 170 no caso de o GMLC 170 atribuir a referência de localização.
[0103] Em 218B, a MME 142 envia uma solicitação de localização para o UE 200 ao E-SMLC 172e pode incluir qualquer identidade para o UE 200 recebida em 216B ou já conhecida da MME 142. Em 222B o E-SMLC 172 pode instigar uma sessão de localização do protocolo de posicionamento LTE (LPP) do 3GPP com o UE 200 e como parte desta sessão pode enviar uma solicitação de localização ao UE 200, que responde com informações de localização. As informações de localização fornecidas pelo UE 200 podem compreender medições de localização GPS, medições de localização GNSS, medições OTDOA, medições de ID de Célula Aperfeiçoado (EECID), medições de localização WiFi, medições de localização Bluetooth (BT) ou qualquer combinações destas, ou pode conter uma estimativa de localização para o UE 200 a partir destas medições. Em vez de, ou além de, 222B o E-SMLC 172 pode enviar uma solicitação de localização (não mostrado na Figura 2B) a um eNB servidor para o UE 200 (o eNB 124 da Figura 2B, por exemplo) de modo a obter uma estimativa ou medições de localização 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 recebida em 224B ao GMLC 170.
[0104] Alternativamente, se a solução de localização no plano de usuário SUPL estiver sendo utilizada ( o que significa que o GMLC/SLP 170 é ou contém um SLP ou é uma RLF associada ou conectada a um SLP) então os feixes de mensagens de 216B a 226B podem não ser executados e, em vez disso (ou possivelmente), uma sessão de SUPL é estabelecida entre o SLP 170 e o UE 200 em 228B. O SLP 170 pode obter a localização do UE por meio da sessão de SUPL (a partir de medições de GPS, GNSS, OTDOA, ECID, efetue e/ou BT obtidas pelo UE 200, por exemplo). Os fluxos de mensagens 216B a 228B são mostrados com linhas tracejadas, uma vez que algumas modalidades, ou os fluxos de mensagens em 216B a 226B são executados ou fluxos de mensagens em 228B é executado, mas não ambos. Em 232B, o GMLC/SLP 170 envia a estimativa de localização do UE 200 ao SP OTT 150.
[0105] Os fluxos de mensagens em 214B a 232B (ou (a) 214B a 226B e 232B ou (b) 214B, 222B e 232B, por exemplo) podem ocorrer nos tempos mostrados na Figura 2B para permitir que o SP OTT 150 obtenha a localização do UE para ajudar a rotear a chamada de emergência determinando- se um PSAP 180 com uma cobertura de serviços de emergência que inclui a localização do UE 200, por exemplo) e/ou para fornecer a localização do UE 200 à ESInet ou ao PSAP 180. Os fluxos de mensagens em 214B a 232B podem ocorrer, alternativa ou adicionalmente depois que a chamada de emergência iniciada em 208B é estabelecida (depois de 236B), se o SP OTT 150 receber uma solicitação de localização para o UE 200 do PSAP 180 e precisar consultar o GMLC/SLP 170 para obter e devolver a localização atual do UE 200 (não mostrado na Figura 2B). Além disto, 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 a ESInet 160 ou PSAP 180 solicite diretamente a localização do UE 200 do GMLC/SLP 170. Estes fluxos de mensagens análogos podem ser idênticos ou quase idênticos a 214B a 232B, exceto pelo fato de que a ESInet 160 ou PSAP 180 pode substituir o SP OTT 150 nos fluxos de mensagens em termos de envio da solicitação de localização em 214B e de recebimento da resposta de localização em 232B.
[0106] Voltando à chamada de serviço de emergência mostrada na Figura 2B, em 234B, o SP OTT 150 roteia a chamada de emergência para a ESInet 160 apropriada ou possivelmente a um SR 160 se o SP OTT 150 precisar converter a chamada em uma chamada de emergência CS. A ESInet 160 (ou um SR 160) roteia então a chamada de emergência para o PSAP 180 apropriado. estas 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 utilizar a localização do UE 200 obtida em 232B, se executado, para rotear a chamada de emergência iniciada em 208B para a ESInet 160 apropriada (ou SR 160). A ESInet 160 pode utilizar a referência de localização do UE 200 recebida na solicitação da chamada de emergência para obter a localização do GMLC/SLP 170 executando blocos análogos a 214B a 232B conforme descrito acima. A ESInet 160 pode utilizar então esta localização obtida para rotear a chamada de emergência para o PSAP 180.
[017] Em 233B, as diversas entidades de rede (o UE 200) o SP OTT 150, a ESInet 160 e o PSAP (executam 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 utiliza a referência de localização para buscar a localização do UE 200 (buscar a localização obtida anteriormente em 226B e/ou 228B, por exemplo), e responde com a localização do UE 200. Alternativamente, o GMLC/SLP 170 pode obter a localização do UE 200 executando blocos (não mostrados) na Figura 2B) que são idênticos aos mostrados em 216B a 226B e/ou 228B.
[0108] A Figura 3 mostra uma arquitetura exemplar para prover serviços de emergência através de um provedor de serviços OTT que mostra soluções de localização alternativas de acordo com pelo menos um aspecto da revelação. A arquitetura mostrada na Figura 3 inclui um UE 300 (que pode corresponder ao UE 200) uma rede de acesso 320 (que pode corresponder à RAN 120), uma rede básica de pacotes 340 (que pode corresponder rede básica 140), um SP OTT 350 (que pode corresponder ao SP OTT 150), uma ESInet/SR 360 (que pode corresponder à 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 IP 375 (que pode corresponder à Internet 175) uma rede nativa 385 que pode ser uma rede nativa para o UE 300 e um PSAP 380 (que pode corresponder ao PSAP 180).
[0109] A Figura 3 mostra diversas soluções alternativas, rotuladas como S1, S2, S3, S3a, S3b, S4 e S5, para transferir a localização do UE 300 que chamou um serviço de emergência (chamada de voz de emergência, sessão de mensagem de texto de emergência, por exemplo) para ou de um SP OTT 350. Para cada solução, o SP OTT pode ser responsável pela chamada e roteamento de uma chamada de serviço de emergência para a rede de serviços de emergência (para uma ESInet ou diretamente para um PSAP, por exemplo).
[0110] Para a solução S1, o UE 300 pode adicionar uma localização adequada para roteamento (e possivelmente despacho) ao SP OTT 350, A localização pode ser ou uma localização por valor (LbyV) ou uma localização por referência (LbyR) e pode ser obtida de um servidor de localização (ULRS 370, por exemplo) ou pode ser determinada unicamente 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 de referência de localização ao servidor de localização e em seguida enviar a referência de localização recebida sob a forma de um URI de localização ao SP OTT 350. O SP OTT 350 pode efetuar então a anulação de referência (utilizando um HELD, por exemplo) ao solicitar um valor de localização do servidor de localização (UELS 370, por exemplo) que atribui o URI de localização.
[0111] Com a solução S2, o SP OTT 350 pode consultar o UE 300 quanto à localização do UE 300, por exemplo, depois de receber uma chamada de chamada de serviço de emergência dôo UE 300 com uma chamada de CONVITE SIP. A consulta pode utilizar sinalização em serviço (uma solicitação por meio de uma mensagem INFO SIP, por exemplo) ou sinalização fora de serviço (uma solicitação por meio de um percurso de dados ou sinalização separado, por exemplo). O UE 300 pode devolver a localização ao SP OTT 350 utilizando dispositivos análogos à solicitação, como, por exemplo, sinalização em chamada se a solicitação tiver utilizado sinalização em chamada. As informações de localização que são devolvidas podem ser as mesmas para a solução S1, por exemplo) ou uma LbyV ou uma LbyR.
[0112] Com a solução S3 depois de receber uma chamada de chamada de serviço de emergência do UE 300 (com um CONVITE SIP, por exemplo) o SP OTT 350 pode consultar o ELS 370 que pode estar na ou associado à rede de acesso 320 ou PCN 340, por exemplo). O SP OTT 350 pode em alguns casos determinar a rede de acesso 320, a PCN 340 e/ou o ELS 370 utilizando o endereço IP do UE ou identificador para rede de acesso 320 ou para a PCN 340 fornecido pelo UE 300 ao SP OTT 350. Por exemplo, no caso do endereço IP (faixas conhecidas de endereços IP ou sub-campos específicos em um endereço IP podem ser configuradas pelo SP OTT 350 (em um servidor de chamada de emergências, por exemplo) e mapeadas em redes de acesso e PCNs específicas. 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 emissão progressiva para um servidor de localização (ELS 370, por exemplo).
[0113] Com a solução S4, depois de receber uma chamada de chamada de serviço de emergência do UE 300 (em um CONVITE SIP) o SP OTT 350 pode consultar um servidor de localização ou serviço de localização na Rede Nativa 385 para o UE 300. O UE 300 pode ser referido utilizando-se uma entidade pública global (como, por exemplo, URI SIP, MSIS DN, etc.). O SP OTT 350 pode determinar a Rede Nativa 385 e o servidor de localização ou serviço de localização na Rede Nativa 385 a identidade pública global. A Rede Nativa 385 pode conhecer a localização geral do UE 300 (a partir de informações recebidas da PCN 340 para suportar roaming) e/ou pode localizar o UE 300 diretamente (utilizando SUPL, por exemplo).
[0114] Com a solução S5, um PSAP 380 ou a ESInet/SR 760 pode consultar o SP OTT 350 quanto à localização do UE 300 necessária para roteamento ou despacho. O SP OTT 350 pode utilizar uma das soluções alternativas (S1, S2, S3, S3a, S3b e S4) para obter uma localização por valor (localização geográfica ou localização cívica, por exemplo) para o UE 300 ou uma localização por referência para o UE 300 e pode devolver então isto ao PSAP 380 ou à ESInet/SR 360. Se uma localização por referência for devolvida, o PSAP 380 ou a ESInet/SR 360 precisariam consultar o servidor de localização (o ELS 370, por exemplo) que atribuiu a localização por referência na rede de acesso 320 ou PCN 340 para obter a localização do UE 300.
[0115] As soluções de localização por referência descritas anteriormente em associação com as Figuras 1A, 1B, 2A e 2B podem ser utilizadas em combinação com as soluções S1, S2 e S5 descritas anteriormente para a Figura 3. Estas soluções de localização por referência podem reduzir os impactos em um UE, tal como o UE 200 e/ou UE 300 e em um servidor de localização tal como o servidor de localização 170 e o ELS 370 de modo a se obter a referência de localização conforme descrito anteriormente. As soluções podem não resolver outros aspectos do suporte de chamada de emergência por um SP OTT 150 ou SP OTT 350 tais como rotear uma chamada de emergência para um PSAP (o PSAP 180 ou o PSAP 380, por exemplo) e permitir que um PSAP solicite e obtenha uma localização para um UE 200 ou UE 300 que possa ser utilizada para despacho do PSAP. Para resolver estes outros aspectos do suporte de chamadas de emergência, são descritas em seguida outras soluções de localização que podem diferir sob alguns aspectos, das soluções de localização descritas em associação com as Figuras 1A-2B, Estas outras soluções de localização podem constituir extensões para as soluções S1 e S2 descritas anteriormente - o que pode permitir que informações relacionadas a localização sejam fornecidas ao SP OTT 350 além de ou em vez de uma LbyV ou LbyR. Para as soluções S1 e S2 da Figura 3, supõe-se que o servidor de localização (ELS) 370 seja utilizado para fornecer uma localização por valor ou localização por referência para o UE 300. O ELS 370 pode corresponder a um de vários servidores de localização diferentes em arquiteturas de rede diferentes (o ELS 370 pode ser um E-SMLC 172, um GMLC 170, um SLP 170 ou uma LRF, por exemplo). A associação do ELS 370 com uma LRF pode ser particularmente útil, uma vez que uma LRF é definida como suportando uma interface externa para anulação de referência de localização (no documento TS 23.167 do 3GPP e no padrão ATIS-070015, por exemplo) e pode ter acesso à capacidade de determinação de localização no interior da PCN 340 ou da NA 320 utilizando uma solução de localização no plano de controle e/ou uma solução de localização no plano de usuário.
[0116] As soluções S1 e S2 da Figura 3 podem ser consideradas como mutuamente complementares e podem ser ambas suportadas. Por exemplo, a solução S1 pode ser utilizada quando o UE 300 detectar quando um usuário está chamando 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 utilizada quando o UE 300 não detectar que um usuário está chamando uma chamada de emergência ou não tiver tempo suficiente para obter informações de localização antes enviar uma solicitação de serviço de emergência ao SP OTT 350.
[0117] Pode ser necessário que os aperfeiçoamentos para soluções S1 e S2 da Figura 3 solucionem vários conjuntos de problema quando suportam localização e roteamento por um MNO servidora em favor de uma chamada de emergência que foi inicialmente enviada por um UE 300 a um SP OTT 350. Estes diversos conjuntos de problema são descrito e exemplificados em seguida.
[0118] Conjunto de Problemas 1: PSPAS Legados
[0119] Pode haver problemas associados ao suporte de localização e roteamento para uma chamada de emergência que é necessário enviar a um PSAP legado 380, quando o PSAP legado 380 não for suportado por uma ESInet 360 (mas pode em vez disso ser suportado por um SR 360, por exemplo). Um problema pode ser que um PSAP legado 380 pode não ser capaz de recuperar uma localização para um UE 300 de um SP OTT 350 utilizando a interface E2 definida no padrão TIA e ATTS conjunto J-STD-036, o que pode ocorrer se o SP OTT 350 estiver em um país diferente do pais do UE 300 ou do PSAP 380 ou se o PSAP 380 não tiver uma relação de comunicação com o SP OTT 350. Observe-se que a interface E2 é comumente utilizada para recuperação de localização por um PSAP legado no caso de uma chamada de emergência instigada por meio de uma rede sem fio pública na América do Norte, onde a chamada de emergência é roteada por um PSAP legado. Um segundo problema pode ser o de que pode não ser possível para um SP OTT 350 enviar uma LbyV a um PSAP legado 380 como parte da sinalização de chamada (se a chamada de emergência para um UE 300 for roteada através de um SR 360 que utiliza um tronco MF para atingir o PSAP 380, por exemplo). Um terceiro problema pode ser o de que um PSAP legado 380 (ou uma ALI associada a um PSAP legado 380 pode não suportar normalmente anulação de referência de uma LbyR no caso do o SP OTT 350 fornecer uma LbyR em vez de uma LbyV ao PSAP 380.
[0120] Os três problemas acima podem significar que qualquer aperfeiçoamento das soluções S1 e S2 com base apenas no fornecimento de uma LbyV ou LbyR a um SP OTT 350 pode não suportar o fornecimento de uma localização despachada a um PSAP legado 380, quando o PSAP legado 380 não for suportado por uma ESInet 350 (mas for suportado somente por um SR 360, por exemplo).
[0121] Conjunto de Problemas 2: Localização no Plano de Controle em uma MNO servidora
[0122] Com a solução de localização no plano de controle 3GPP para acesso a LTE ou HSPA (conforme definido nos documentos TSs 23.271, 25.305 e 36.305 do 3GPP, por exemplo). A identidade da MME servidora ou do SGSM servidor atual para um UE 300 está fazendo uma chamada de emergência precisa ser conhecida em uma RLF ou um GMLC de modo a se rotear uma solicitação de localização do UE 300 para a MME servidora ou GCSN servidor correto. Para chamadas de emergência que são estabelecidas por uma MNO servidora sem envolvimento de um SP OTT (conforme descrito em ATIS-0700015, por exemplo). Esta informação pode ser mantida atualizada na LRF e no GMLC (que estão sendo utilizados para suportar localização para o UE 300 chamador de emergência) pela MME servidora ou pelo GSM servidor quando o UE 300 estabelece uma conexão de PDN de emergência ou um contexto PDP de emergência (como parte do estabelecimento da chamada de emergência, por exemplo) e pela nova ou anterior MME ou SGSN quando o handover ocorre. Entretanto, para uma chamada de emergência que é estabelecida através de um SP OTT 350, a MNO servidora pode não estar ciente da chamada de emergência e, portanto, a RLF e o GSMC) pode não ser mantida atualizada com a índice da MME servidora ou do SGSM servidor. Sem esta informação um GCSM pode não ser capaz de rotear uma solicitação de localização para a MME servidora ou SGSN servidor correto. Isto significa que, quando serve uma solicitação de anulação de referência de localização para um UE 300 de um SP OTT 350 um ELS 370 (LRF, por exemplo) pode não ser capaz de utilizar uma solução no plano de controle para obter a localização do UE 300 - exceto possivelmente no caso de um assinante nativo quando o ELS 370 tiver informações para consultar as informações de um HSS.
[0123] Conjunto de Problemas 3: Localização no Plano de Usuário em uma MNO Servidora
[0124] Quando o UE 300 acessa um SP OTT 350 por meio de uma VPN que é intermediária entre a MNO servidora (A PCN 340, por exemplo) e o SP OTT 350, o endereço IP do UE que é enviado pelo SP OTT 350 pode ter sido atribuído pela VPN e pode portanto, diferir de qualquer endereço IP atribuído ao UE pela MNO servidora (a PCN 340, por exemplo). Se um SLP na MNO servidora (o ELS 370, por exemplo) aceitar somente soluções de localização entrantes em favor de UEs com endereços IP conhecidos da ou atribuídos da MNO servidora, isto pode prevenir a utilização de localização SUPL pela MNO servidora se o endereço IP abo pela VPN for incorporado em uma solicitação de localização enviada à MNO servidora (enviada ao ELS 370, por exemplo) pelo SP OTT 350. Um problema semelhante pode ocorrer para um UE roaming, cujo endereço IP pela rede nativa 385. No caso de o Gateway de PDN para acesso à LTE estar na Rede Nativa 385, por exemplo. Neste caso, contudo, uma MNO servidora (um SLP na MNO servidora, por exemplo) pode ser configurada com o endereço IP (faixas de endereço, por exemplo) atribuídos por parceiros roaming, tais como a Rede Nativa 385, e neste caso a utilização de localização no plano de usuário (SUPL) pode ser ainda possível.
[0125] Conjunto de problemas 4: Roteamento de uma Chamada de Emergência para um PSAP
[0126] Embora o SP OTT 350 seja capaz de rotear uma chamada de emergência de um UE 300 para um PSAP 380 (por meio de uma Rede IP 375 ou por meio da PSTN, por exemplo), se o endereço ou identidade correta para o PSAP 380 for conhecida (o RL SIP ou DN telefônico, por exemplo), a alguns SPs OTT 350 pode faltar a capacidade de mapear uma localização geográfica do UE 300 no endereço ou identidade de um PSAP 380 cuja área de serviço inclui a localização do endereço do UE 300. Por exemplo, esta falta de capacidade pode ocorrer se o SP OTT 350 estiver em um país diferente tanto no país do UE 300 quanto do país do PSAP 380 e não tem a capacidade de obter informações de roteamento para PSAPs em outros paises - utilizando o protocolo LoST definido por IETF. Em alguns casos, mesmo se o endereço ou identidade do PSAP 380 for conhecido pelo SP OTT 350, pode não ser possível para o SP OTT 350 emitir uma chamada de emergência para um UE 300 para o PSAP 380 devido a restrições ao ingresso de chamadas de emergência no lado do PSAP 380.
[0127] Os conjuntos de problema de 1 a 4 descritos e exemplificados acima podem ser resolvidos por aperfeiçoamentos específicos nas soluções S1 e S2 referidas anteriormente, conforme descrito em seguida.
[0128] A Figura 4 mostra uma arquitetura exemplar para suporte de localização por referência para serviços de emergência através de um provedor de serviços OTT de acordo com pelo menos um aspecto da revelação. A arquitetura mostrada na Figura 4 inclui um UE 400 (que pode corresponder ao UE 200 ou a o UE 300, uma rede de acesso 420 que pode corresponder à RAN ou à NA 320), um IMS 440 (que pode corresponder a parte da rede básica 140 ou parte da PCN 340), um SP OTT 450 (que pode corresponder ao SP OTT 150 ou ao SP OTT 350), uma ESInet 460 capaz de NENA i3 (que pode corresponder à ESInet/SR 160 ou à ESInet 360), Uma ESN Legada 462, uma Internet 475, uma PSTN 485 e uma MNO servidora 490 (que pode corresponder CN 140 combinada com NA 120 ou à PCN 340 combinada com à NA 320). O IMS 440 inclui uma LRF 448 (que pode corresponder ao servidor de localização 170 ou ao ELS 370), uma MGCF 441, uma P-CSCF 442, uma E-CF 443, uma IBCF 444, uma S-CSCF 445. A LRF 448 pode ser conectada a uma RDF 446 e a uma LS 470 (que pode corresponder ao servidor de localização 170 ou ao GMLC/SLP 170. A ESInet i3 460 inclui uma BCF 464, um ESRP 466, uma ECRF 468 e um PSAP 480 capaz de NENA i3 (que pode corresponder ao PSAP 180 e ao PSAP 380). A ESN Legada 462 inclui uma ALI 561, um SR 463 (que pode corresponder ao SR 160 ou ao SR 360) e um PSAP Legado 482 (que pode corresponder ao PSAP 180 ou ao PSAP 380). As diversas entidades mostradas na Figura 4 são notoriamente conhecidas na técnica e são definidas nos documentos TS 3GPP (TS 23.401, 23.167, 23.228, por exemplo), no padrão ATIS 0700015 e no padrão NENA i3.
[0129] Com suporte de LbyR normal, mostrado na Figura 4 para a solução S1, o UE 400 envia uma solicitação da chamada de emergência 401 ao SP OTT 450 que contém uma LbyR. O SP OTT 450 em seguida anula a referência a LbyR enviando uma consulta de localização 402 a um ELS (a LRF 448 na MNO servidora 490, por exemplo) indicado pelo LbyR recebida na solicitação da chamada de emergência 401. O ELS mostrado LRF na Figura 4 obtém uma localização para o UE 400 e devolve a localização e/ou informações de roteamento ao SP OTT 450. O SP OTT 450 roteia então a chamada de emergência para o PSAP (ou o PSAP Legado 482 na mensagem 403A ou o PSAP 480 capaz de NENA i3 na mensagem 403B) com base na informações de roteamento ou na localização recebida da RLF 448 e que contém a LbyR originalmente recebida. O PSAP 480/482 pode enviar então uma consulta 404A (para o PSAP 482) ou 404B (para o PSAP 480) ao ELS (a ERF 448, por exemplo) posteriormente para uma localização para um local despachável utilizando a LbyR recebida. Conforme discutido para o Conjunto de Problemas 1, a consulta de localização 404A pode não ser possível para um PSAP Legado 482 a menos que o PSAP seja suportado por uma ESInet.
[0130] A solução de LbyR básica descrita acimaem associação com a Figura 4 pode ser aperfeiçoada apara as soluções S1 e S2 da Figura 3 para superação dos problemas descritos acima para os conjuntos de problemas 2 e 3. Especificamente, o URI de localização que é atribuído à MNO servidora 490 (pela LRF 448, por exemplo) como uma LbyR para um UE 400 pode ser formatado de modo a conter as informações seguintes: a) um endereço IP local para o UE 400 se a MNO servidora 490 vier a utilizar sua localização no plano do usuário para localizar o UE 400 e se o endereço local tiver sido atribuído pelo UE 400 pela MNO servidora 490; b) uma identidade local de uma MME servidora (a MME 142, por exemplo) ou de uma SGSN servidora se a MNO servidora 490 vier a utilizar localização no plano de controle para localizar o UE 400 e c) uma identidade para o UE 400 (um MSISDN, e MSI ou o ID local atribuído pela MME ou SGSN servidor, por exemplo) se a MNO servidora 490 vier a utilizar localização no plano de controle para localizar o UE 400.
[0131] As informações acima em (a) e (b) e (c) podem ser incluídas como a parte da LbyR normalmente utilizada como referência local para o UE 400 que permitiriam a atribuição da LbyR pela NA 420 ou por uma PCN na MNO servidora 490, e não por ELS tal como a LRF 448 (conforme descrito anteriormente em associação com as Figuras 1A-2B, por exemplo), o que pode simplificar a implementação. A formatação destas informações pode ser específica da MNO servidora 490 (pode não ser padronizada, por exemplo). Um ELS (A LRF 448, por exemplo) na MNO servidora 490 que recebe tal URI de localização em uma solução de anulação de referência, tal como a solução 402, de uma LbyR do SP OTT 450 e conhece as regras de formatação para a LbyR pode extrair as informações em (a)-(c) acima e utiliza-las para chamar a localização no plano de controle ou a localização no plano do usuário do UE 400. Um benefício adicional é que o ELS não precisa manter informações seja para chamada de emergência do UE 400 ou do UE 400 e pode responder a tal solicitação de anulação de referência (a solicitação 402, por exemplo) com base unicamente nas informações incluídas em cada uma de tais solicitações.
[0132] O aperfeiçoamento acima descrito em associação com a Figura 4, é aqui referido como “LbyR aperfeiçoada” e é aqui mostrado mais adiante utilizando-se figuras adicionais, mas pode não resolver todos os problemas no Conjunto de Problemas 2 acima. Por exemplo, embora a LbyR para o UE 400 possa conter a identidade da MME servidora atual ou do SGAS servidora atual para o UE 400, as informações pode tornar-se desatualizadas quando o UE 400 for transferido para uma nova MME ou SGSN a menos que o UE 400 envie novas informações (uma nova LbyR, por exemplo) ao SP OTT 450 (em uma INFO SIP, por exemplo) que as emite então para o PSAP 480 ou 482.
[0133] O suporte de IMS é outro aperfeiçoamento para as soluções S1 e S2 da Figura 3 que pode ser utilizado para solucionar todos os problemas descritos acima para os conjuntos de problemas 1, 2, 3 e 4. Com suporte de IMS a MNO servidora pode suporte ou como uma RLF, conforme descrito em seguida, em associação com a Figura 5, ou como uma E-CSCF, cadeia RF descrito mais adiante em associação com a Figura 6.
[0134] A Figura 5 mostra uma arquitetura exemplar para suporte de LRF IMS para serviços de emergência através um provedor de serviços OTT de acordo com pelo menos um aspecto da revelação. Semelhante arquitetura mostrada na Figura 4, a arquitetura mostrada na Figura 5 inclui um UE (que pode corresponder ao UE 200, ao UE 300 ou ao UE 400), uma rede de acesso 520 (que pode corresponder à RAN 120, à NA 320 ou à NA 420), um IMS 540 (que pode corresponder a parte da rede básica 140, parte da PCN 340 ou do IMS 440), um SP OTT 550 (que pode corresponder ao SP OTT 150, ao SP OTT 350 ou ao SP OTT 450), uma ESInet 560 capaz de NENA i3 (que pode corresponder à ESInet 160, à ESInet 360 ou ESInet 460), uma ESN legada 562, a Internet 575, uma PSTN 585 e uma MNO servidora 590 (que pode corresponder à CN 140 combinada com a NA 120, à PCN 340 combinada com NA 320 ou MNO 490). O IMS 540 inclui uma LRF 548 (que pode corresponder ao servidor de localização 170, ao ELS 370 ou à LRF 448), uma MGCF 541, uma P-CSCF 542, uma E-CSCF 543, um IBCF 544 e uma S-CSCF 545. A LRF 548 pode ser conectada a uma RBF 546 e a um LS 570 (que pode corresponder ao servidor de localização 170, ao GMLC/SLP 170 ou LS 470). A ESInet i3 560 inclui uma BCF 564, um ESRP 566, uma ECRF 568 e um PSAP 580 capaz de NENA i3 (que pode corresponder ao PSAP 180, ao PSAP 380 ou ao PSAP 480). A ESN legada 562 inclui uma ALI 561, um SR 563 (que pode corresponder ao SR 160, ao SR 360 ou ao SR 463) e um PSAP Legado 582 (que pode corresponder ao PSAP 180, ao PSAP 380 ou ao PSAP legado 482). Quanto à Figura 4, as diversas entidades mostradas na Figura 5 são notoriamente conhecidas na técnica.
[0136] A Figura 5 mostra o percurso e a direção da mensagem se solicitação de chamada de emergência inicial (um Convite SIP, por exemplo) 501 do UE 500 até o SP OTT 550, o percurso até a LRF 548 (para o CONVITE SIP 502A emitido) e de volta até o SP OTT 550 (para as 300 Múltiplas Escolhas 502B do SIP) e o percurso e a direção do SP OTT 550 até o PSAP 580/582 para a solicitação de chamada de emergência 503A e 503B emitida. A Internet 575 pode ser utilizada para transmitir a solicitação de chamada inicial 501 da MNO servidora 590 para a SP OTT 550 e para transmitir a solicitação de chamada 503B emitida do SP OTT 550 para a ESInet 560, ao passo que a PSTN 585 pode ser utilizada para transmitir uma solicitação da chamada CS 503A do SP OTT 550 para o SR 563 de modo a atingir o PSAP Legado 582. A Figura 5 mostra também o percurso e a direção para uma solicitação de localização 504A ou 504B para o UE 500 enviada pelo PSAP Legado 582 ou o PSAP NENA i3, respectivamente, à LRF 548.
[0137] A Figura 6 mostra uma arquitetura exemplar para suporte de E-CSCF IMS para serviços de emergência através de um provedor de serviços OTT, de acordo com pelo menos um aspecto da revelação. Semelhante à arquitetura mostrada nas Figuras 4 e 5, a arquitetura mostrada na Figura 6 inclui um UE 600 (que pode corresponder ao UE 200, ao UE 300 ou ao UE 400 ou ao UE 500), uma rede de acesso 620 (que pode corresponder à RAN 120, à NA 320, à NA 420 ou à NA 520), um IMS 640 (que pode corresponder a parte da rede básica 140, parte da PCN 340, do IMS 440 ou IMS 540), um SP OTT 650 (que pode corresponder ao SP OTT 150, ao SP OTT 350, ao SP OTT 450 ou a SP OTT 550), uma ESInet 660 capaz de NENA i3 (que pode corresponder à ESInet 160, à ESInet 360, ESInet 460 ou à ESInet 560), uma ESN legada 662, a Internet 675, uma PSTN 685 e uma MNO servidora 690 (que pode corresponder à CN 140 combinada com a NA 120, à PCN 340 combinada com NA 320 ou MNO 490 ou MNO 590). O IMS 640 inclui uma LRF 648 (que pode corresponder ao servidor de localização 170, ao ELS 370 ou à LRF 448 ou à LRF 548), uma MGCF 641, uma P-CSCF 642, uma E-CSCF 643, um IBCF 644 e uma S-CSCF 645. A LRF 648 pode ser conectada a uma RBF 646 e a um LS 670 (que pode corresponder ao servidor de localização 170, ao GMLC/SLP 170 ou LS 470 ou LS 570). A ESInet i3 660 inclui uma BCF 664, um ESRP 666, uma ECRF 668 e um PSAP 680 capaz de NENA i3 (que pode corresponder ao PSAP 180, ao PSAP 380 ou ao PSAP 480 ou ao PSAP 580). A ESN legada 662 inclui uma ALI 661, um SR 663 (que pode corresponder ao SR 160, ao SR 360 ou ao SR 463 ou ao SR 563) e um PSAP Legado 682 (que pode corresponder ao PSAP 180, ao PSAP 380 ou ao PSAP legado 482 ou ao PSAP Legado 582). Quanto às Figuras 4 e 5, as diversas entidades mostradas na Figura 6 são notoriamente conhecidas na técnica.
[0138] Com suporte de E-CSCF, mostrado na Figura 6 para a solução S1 da Figura 3, o SP OTT 650 recebe um endereço da E-CSCF 643 na MNO servidora 690 na solicitação da chamada de emergência 601 enviada do UE 600 (que o UE 600 pode obter da NA MNO 620 ou PCN da MNO servidora 690, por exemplo, em anexação à rede). O SP OTT 650 se comporta então de maneira semelhante a uma S-CF e emite a solicitação de serviços de emergência utilizando um CONVITE SIP 602 padrão para a AE-CF 643, depois de ter enviado uma solicitação 603A à LRF 648 de modo a obter qualquer informação de roteamento e localização em uma resposta 603B necessária para efetuar a emissão. O suporte de E-CSCF exemplificado na Figura 6 pode aperfeiçoar a probabilidade de transferência de chamada (ou serviço bem sucedida para um PSAP 680/682 as custas de maior envolvimento da MNO servidora 690.
[0139] Semelhante à Figura 5, a Figura 6 mostra o percurso e a direção da mensagem de solicitação da chamada de emergência inicial (um CONVITE SIP, por exemplo) 601 do UE 600 para o SP OTT 650, o percurso da solicitação de chamada emitida até a E-CSCF 643 e o percurso e a direção até o PSAP 680 ou 682 da solicitação de chamada 604A ou 604B emitida, respectivamente, com assistência de localização e roteamento solicitada pela E-CSCF 643 a 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 ser conforme definidas para a solução em ATIS-0700015 - com a solicitação 603A compreendendo um CONVITE SIP e a resposta 603B compreendendo uma mensagem de 300 múltiplas escolhas SIP, por exemplo. A Figura 6 mostra também o percurso e a direção para uma solicitação de localização 605A ou 605B para o UE 600 enviada pelo PSAP Legado 682 ou pelo PSAP 608 NENA i3, respectivamente, à LRF 648.
[0140] As soluções tanto da LRF 648 quanto da E-CSCF descritas em associação com as Figuras 5 e 6, respectivamente, podem exigir algumas alterações na RLF e na RDF e na E-CSCF para solução de E-CSCF da Figura 6, em comparação com a solução de chamada de emergência IMS definida pelo 3GPP (no documento 3GPP TS 23. 167, por exemplo) e em ATIS 0700015, mas podem re-utilizar também a funcionalidade existente destas soluções padrão.
[0141] Para cada solução descrita acima com referência às Figuras 5 e 6, um UE (o UE 500 ou 600, por exemplo) forneceria ao SP OTT (o SP OTT 550 ou 650, por exemplo) determinadas informações para (i) permitir roteamento de chamadas de emergência do SP OTT para a entidade correta na MNO servidora (ou uma LRF ou uma E- CSCF) e (ii) permitir que o SP OTT forneça informações suficientes à MNO servidora para permitir à ou ajudar MNO servidora a obter a localização do UE e para suportar roteamento de chamadas. Algumas das informações fornecidas pelo UE ao SP OTT podem vir do que é normalmente conhecido do UE, ao passo que outras informações podem ter que ser fornecidas ao UE pela NA (a NA 520 ou 620, por exemplo) ou pela PCN na MNO servidora (a MNO 590 ou 690, por exemplo), por exemplo, em uma anexação ao UE, quando de um handover para uma nova MME ou SGSN. As informações que podem ser fornecidas ao UE pelo SP OTT em uma solicitação da chamada de emergência para o UE são mostradas na Tabela 3 (coluna 1) juntamente com a fonte provável de cada item de informação (coluna 2) aplicabilidade à localização no plano de usuário (UP) ou no plano de controle para o UE (coluna 3), e possíveis cabeçalhos SIP que podem ser utilizados para transferir cada item para o SP OTT (e daí para a MNO servidora) quando o SIP é utilizado entre o UE e o SP OTT (coluna 4).
Tabela 3
[0142] A LRF 548 ou a E-CSCF 643 na MNO servidora 590 ou 690 pode precisar manter informações sobre estado depois de receber o CONVITE SIP inicial 502A ou 602, respectivamente, do SP OTT 550 ou 650, em associação com a solução da Figura 5 ou da Figura 6, respectivamente, de modo a manter a chamada no caso de uma E-CSCF 643 ou de modo a responder a qualquer solicitação de localização subsequente do PSAP 580/582 ou de uma ESInet 560 no caso de uma LRF 548. No caso da LRF 548, isto significa saber quando a chamada de emergência terminou. Além disto, uma vez que uma MME servidora ou um SGSM servidor para o UE 500 ou 600 pode alterar-se, a E-CSCF 643 ou a LRF 548 pode precisar conhecer o novo endereço da MME ou SGSN servidor (ou ID) quando a localização no plano de controle é utilizada. Para um LRF 548, estes objetivos podem ser alcançados se a LRF 548 assinar separadamente a notificação de eventos do SP OTT 550 para terminação de chamadas e, quando a localização no plano de controle é utilizada para alteração da MME ou SGSN servidor. Para uma E-CSCF 643, a notificação de uma alteração no endereço da MME ou SGSN servidor é possível com uma atualização de INFO SIP do SP OTT 650. O UE 500 ou 600 pode manter o SP OTT 550 ou 650, respectivamente, atualizado com qualquer identidade de MME ou SGSN servidor utilizando uma INFO SIP (quando o SP OTT utiliza o SIP, por exemplo) ou utilizando alguma mensagem de SP OTT patenteada.
[0143] Ambas as soluções mostradas nas Figuras 5 e 6 podem transferir as mesmas informações mostradas na Tabela 3 do UE 500 ou do UE 600 para o SP OTT 550 ou SP OTT 650, exceto pelo fato de que o endereço na MNO servidora fornecido ao SP OTT 550 ou 650 pelo UE 500 ou 600, respectivamente, pode ser um endereço para a RLF 548 para a solução de LRF da Figura 5 e um endereço para a E-CSCF 643 para a solução de E-CSCF da Figura 6. Esta transferência de informações quase idêntica do UE 500 ou 600 para o SP OTT 550 ou 650, respectivamente, pode 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, o que pode permitir que uma MNO servidora 590 ou 690 decida qual das duas soluções utilizar e pode suportar migração de uma solicitação para a outra sem afetar o suporte pelos UEs 500 e 600 e pelos SPs OTT 550 e 650. As Figuras descritas em seguida exemplificam mais detalhadamente a solução baseada em LRF da Figura 5 e a solução baseada em E-CSCF da Figura 6.
[0144] A Figura 7 mostra um fluxo de mensagens exemplar para localização por valor e localização aperfeiçoada por suporte de referência de acordo com pelo menos um aspecto da revelação. O fluxo de mensagens mostrado na Figura 7 pode ser executado na arquitetura mostrada nas Figuras 3 e 4 e pode corresponder à e estender as interações para suporte de localização por referência descritas em associação com a Figura 4. O fluxo de mensagens na Figura 7 pode ser também ou em vez disso executado nas arquiteturas mostradas nas Figuras 1A e 1B e pode complementar e estender as interações descritas em associação com as Figuras 2A e 2B para suporte de localização por referência. Consequentemente, o UE 700 da Figura 7 pode corresponder a qualquer um dos UEs 1 a N da Figura 1A, ao UE 200, ao UE 300 ou ao UE 400. Da mesma maneira, o SP OTT 750 pode corresponder ao SP OTT 150, ao SP OTT 350 ou ao SP OTT 450. Da mesma maneira, a AN-PCN 792 pode corresponder à AN 420 mais a parte de PCN de MNO 440, à AN 320 mas a PSN 340 ou à AN 120 mais a SN 140 e pode incluir um nó de rede de acesso 240. Da mesma maneira, a LRF 448, ao LRS 370, ao GMLC-SLP 170 ou a servidor de localização 170. Da mesma maneira, o SR 763 pode corresponder ao SR 463, ao SR 360 ou ao SR 160. Da mesma maneira, a ESInet 760 pode corresponder à ESInet 460, à ESInet 360 ou à ESInet 160. Da mesma maneira, o PSAP i3 780 pode corresponder ao PSAP i3 480, ao PSAP 380 ou ao PSAP 180. Da mesma maneira, o PSAP Legado 782 pode corresponder ao PSAP Legado 482, ao PSAP 380 ou ao PSAP 180. Da mesma maneira, a MNO servidora 790 pode corresponder à MNO servidora 490.
[0145] O fluxo de chamadas mostrado na Figura 7 pode aplicar-se diretamente a solução S1 da Figura 3 - pode fornecer mais detalhes das interações necessárias para suportar a solução S1, por exemplo. Um fluxo de chamadas correspondentes à solução S2 da Figura 3 pode ser quase idêntico ao fluxo de chamadas mostrado na Figura 7, exceto pelo fato de que a solicitação da chamada de emergência em 706 não portaria uma LbyV ou LbyR, (conforme descrito em seguida para a Figura 7) e o SP OTT 750 consultaria o UE 700 a respeito de uma LbyV ou LbyR após 706. Além disto, com a solução S2 da Figura 3, o UE 700 pode não detectar que o usuário instigou uma chamada de emergência em 706 (pode não reconhecer que o usuário discou um número de emergência, tal como “911”, por exemplo) e pode enviar uma solicitação de chamada normal ao SP OTT 750 em 706 e não uma solicitação da chamada de emergência. O SP OTT 750 pode reconhecer então a solicitação da chamada enviada em 706 é de uma chamada de emergência (pode reconhecer que os dígitos discados são para um número de emergência, tal como “911”, por exemplo) e pode solicitar uma LbyV ou LbyR do UE 700 antes de prosseguir com 708. As outras operações mostradas na Figura 7, quando a solução S2 da Figura 3 é utilizada, pode ocorrer então conforme descrito em seguida.
[0146] As interações mostradas na Figura 7 aplicam-se a um UE 700 que instigam uma chamada de emergência por meio de um SP OTT 750 em circunstancias nas quais o SP OTT 750 está acessando uma MNO servidora 790 está acessando o SP OTT 750 por meio de MNO servidora 790, por exemplo. Em 702 da Figura 7, se uma LbyR vier a ser utilizada pelo UE 700 para suportar uma chamada de emergência, o UE 700 pode solicitar uma LbyR da AN ou PSN servidora 792. Por exemplo, isto pode ocorrer quando o UE 700 quando o usuário está instigando uma chamada de emergência ou pode ocorrer quando o UE 70 se anexa à MNO servidora 790 ou acessa a MNO servidora por alguma outra razão (para suportar a mobilidade do UE 700, por exemplo).
[0147] Em 704, em resposta a 702, ou quando ocorre determinadas condições (ou o UE 700 se anexa à AN/PCN 792 efetua uma atualização de área de rastreamento ou roteamento para uma nova MME ou SGSN na AN/PCN 792 ou um handover ocorre para uma nova MME ou SGSN, por exemplo), a AN ou PCN 792 envia uma LbyV ou LbyR atualizada ao UE 700. A LbyR pode ser determinada pela AN ou PCN 792 ou obtida de um ELS 794 (uma LRF, por exemplo). Em algumas modalidades, os blocos 702 e 704 pode corresponder ao bloco 202A da Figura 2A ou aos blocos 202B e 206B, respectivamente da Figura 2B. Nestas modalidades, a AN-PCN 792 pode ela mesma atribuir a LbyR que é devolvida ao UE 700 em 704 ou pode obter a LbyR do ELS 794 de maneira semelhante ao bloco 704 da Figura 2B (não mostrado na Figura 7).
[0148] Em 706, em resposta à detecção, pelo UE 700, de que o usuário do UE 700 instigou uma chamada de emergência (se o UE 700 detectar que o usuário discou os dígitos “911”, por exemplo) o UE 700 envia uma solicitação de chamada de emergência ao SP OTT 750 e inclui a LbyV ou LbyR obtida em 704. A solicitação da chamada de emergência pode ser um CONVITE SIP ou pode ser uma mensagem algum outro protocolo específico do SP OTT 750. O bloco 706 pode corresponder ao bloco 214A da Figura 2A, ao bloco 212B da Figura 2B ou ao envio da solicitação de chamada de emergência 401 da Figura 4.
[0149] Em 708, se uma LbyR for recebida em 706, o SP OTT 750 anula a referência da LbyR enviando uma solicitação de localização (uma solicitação de localização formatada de acordo com opcionalmente HELD se o HELD for referido na LbyR, por exemplo) ao ELS 794 e inclui a LbyR na solicitação. O SP OTT 750 pode determinar o ELS 794 (determinar um endereço FQDN ou URI para o ELS 794, por exemplo) a partir de informações na LbyR recebida em 706. O bloco 708 pode corresponder ao bloco 216A da Figura 2A, ao bloco 214B na Figura 2B ou ao enviado de uma consulta de localização 402 da Figura 4.
[0150] Em 710, o ELS 794 utiliza as informações incluídas na LbyR recebida em 708 (uma identidade de UE local ou global e um ID de MME/SGSN servidor para localização no plano de controle ou um endereço IP de UE local para localização no plano do usuário, por exemplo) para obter a localização atual do UE 700 - utilizando uma solução de localização no plano de controle ou no plano do usuário, por exemplo. O bloco 710 pode corresponder aos blocos 218A e/ou 222A da Figura 2A ou aos blocos 216B a 226B ou ao bloco 228B da Figura 2B.
[0151] Em 712, o ELS 794 devolve a localização atual do UE 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 da Figura 2A ou ao bloco 232B da Figura 2B. Os blocos 708-712 são mostrados como opcionais e podem não ser executados se o SP OTT 750 receber uma LbyV em 706.
[0152] Em seguida a 712 se uma localização apenas tiver sido devolvida para o UE 700 em 712, o SP OTT 750 determina o PSAP de destino utilizando a localização do UE (utilizando uma consulta perdida - não mostrada na Figura 7, por exemplo). Caso contrário, o SP OTT 750 pode utilizar qualquer informação de roteamento devolvida em 712 de modo a determinar o PSAP. Quando o SP OTT 750 determina um PSAP Legado 782, o SP OTT 750 pode emitir a chamada utilizando CS pelo envio de uma mensagem de IAM ISUP a um SR 763 para o PSAP 782.
[0153] Em 716A, o SR 763 emite a chamada para o PSAP legado 782.
[0154] Em 718A, o restante do estabelecimento de chamada é executado. Os blocos 714B, 716B e 718B não são então executados.
[0155] Quando o SP OTT 750 determina um PSAP i3 780 em vez de um PSAP Legado 782 em seguida a 712, os blocos 714A, 716A e 718A não são executados. Em vez disso, o SP OTT 750 emite a chamada para a ESInet 760 enviando um CONVITE SIP que contém a LbyV ou LbyR recebida em 706 esqui contém possivelmente qualquer localização para o UE 700 recebida em 715 se 712 ocorrer.
[0156] Em seguida a 714B e antes de 716B, se uma LbyR é fornecida em 714B, a ESInet 760 pode consultar o ELS 794 quanto à localização atual do UE 700 para ajudar no roteamento (não mostrado na Figura 7). A ESInet 760 emite a chamada para o PSAP i3 780 em 716B.
[0157] Em 718B, é executado o restante do estabelecimento de chamada. Os blocos 714A e 716A e os blocos 714A e 716B podem corresponder ao bloco 226A da Figura 2A ao bloco 234B da Figura 2B ou ao envio das mensagens 403A e 403B, respectivamente, da Figura 4. O bloco 718A e o bloco 718B podem corresponder, cada um, ao bloco 228A da Figura 2A ou ao bloco 236B da Figura 2B.
[0158] Em 720, se uma LbyR para o UE 700 tiver sido recebida em 716B, o PSAP i3 780 anula a referência da LbyR enviando uma solicitação de localização ao ELS 794 indicada na LbyR e inclui a LbyR na solicitação. O bloco 720 pode corresponder ao envio da consulta 404B da Figura 4.
[00159] Em 722, o ELS 794 utiliza as informações incluídas na LbyR recebida em 720 (uma identidade local ou global para o UE 700 e um ID de MME/SGSN para localização no plano de controle ou um endereço IP de UE local para localização no plano do usuário, por exemplo) de modo a obter a localização atual do UE 700 - utilizando uma solicitação de localização no plano de controle ou no plano do usuário, por exemplo. O bloco 722 pode ser semelhante ou idêntico aos blocos 218 ou 222A da Figura 2A ou aos blocos 216 a 226B ou ao bloco 228B na Figura 2B em termos de determinação de uma localização para o UE 700.
[0160] Em 724, o ELS 794 devolve a localização atual do UE 700 ao PSAP i3 780. Os blocos 720 e 724 podem corresponder ao bloco 732A da Figura 2A ou ao bloco 238B da Figura 2B.
[0161] A Figura 8 mostra um fluxo de chamadas exemplar para suporte de RLS 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 suporte de RLF IMS descritas anteriormente em associação com a Figura 5. O fluxo de chamadas mostrado na Figura 8 pode ser efetuado utilizando-se a arquitetura mostrada na Figura 5, na Figura 3 ma Figura 1B ou na Figura 1A. Consequentemente, o UE 800 da Figura 8 pode corresponder a qualquer um dos UEs 1 a N da Figura 1A, ao UE 200 ao UE 300 ou ao UE 500. Da mesma maneira, o SP OTT 850 pode corresponder ao SP OTT 150, ao SP OTT 350 ou ao SP OTT 550. Da mesma maneira, a AN-PCN 892 pode corresponder à AN 520 mais a parte de PCN de MNO 590, à AN 320, mas a PSN 340 ou à AN 120 mais a CN 140 e pode incluir um nó de rede de acesso 240. Da mesma maneira, o IMS 894 pode corresponde ao IMS 540, a um IMS dentro da PCN 340 ou a um IMS dentro da CN 140. DA mesma maneira, o destino 863 da CS intermediária pode corresponder ao SR 563, ao SR 360 ou SR 160. Da mesma maneira, a ESInet 860 pode corresponder à ESInet 460, à ESInet 360 ou à ESInet 160. Da mesma maneira, o PSAP i3 880 pode corresponder ao PSAP i3 580, ao PSAP 380 ou ao PSAP 180. Da mesma maneira, o PSAP Legado 882 pode corresponder ao PSAP Legado 582, ao PSAP 380 ou ao PSAP 180. Da mesma maneira, a MNO servidora 890 pode corresponder à MNO servidora 590.
[0162] Figura 9 mostra um fluxo de chamadas exemplar para suporte de E-CSCF 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 suporte de E-CSCF IMS descritas anteriormente em associação com a Figura 6. O fluxo de chamadas mostrado na Figura 9 pode ser efetuado utilizando-se a arquitetura mostrada na Figura 6, na Figura 3 ma Figura 1B ou na Figura 1A. Consequentemente, o UE 900 da Figura 9 pode corresponder a qualquer um dos UEs 1 a N da Figura 1A, ao UE 200 ao UE 300 ou ao UE 600. Da mesma maneira, o SP OTT 950 pode corresponder ao SP OTT 150, ao SP OTT 350 ou ao SP OTT 650. Da mesma maneira, a AN-PCN 992 pode corresponder à AN 620 mais a parte de PCN de MNO 690, à AN 320, mas a PSN 340 ou à AN 120 mais a CN 140 e pode incluir um nó de rede de acesso 240. Da mesma maneira, o IMS 994 pode corresponder ao IMS 640, a um IMS dentro da PCN 340 ou a um IMS dentro da CN 140. Da mesma maneira, o SR 963 pode corresponder ao SR 663, ao SR 360 ou SR 160. Da mesma maneira, a ESInet 960 pode corresponder à ESInet 660, à ESInet 360 ou à ESInet 160. Da mesma maneira, o PSAP i3 980 pode corresponder ao PSAP i3 680, ao PSAP 380 ou ao PSAP 180. Da mesma maneira, o PSAP Legado 982 pode corresponder ao PSAP Legado 682, ao PSAP 380 ou ao PSAP 180. Da mesma maneira, a MNO servidora 990 pode corresponder à MNO servidora 690.
[0163] Os fluxos de chamadas mostrados nas Figuras 8 e 9 são semelhantes e, da perspectiva de entidades fora do IMS 894/994 (o UE 800/900 e o SP OTT 850/950, por exemplo) podem ser vistos como parte de uma única solução comum. Embora o IMS894/994 se comporte de maneira diferente nos fluxos de chamadas das Figuras 8 e 9, as interações entre o IMS 894/994 e/ou o SP OTT 850/950 em ambos os fluxos de chamadas podem ser em conformidade com a definição IETF do SIP (em IETF RFC 3261) e podem ser, portanto, ambas reportadas por um SP OTT 850/950 que atua como um proxy de SIP. Nesse caso, pode não ser necessário que o SP OTT 850/950 saiba de antemão se a MNO servidora 890/990 (ou IMS 894/994 na MNO servidora 890/990) utilizará suporte de LRF IMS como na Figura 8 ou suporte de E-CSCF MS 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 se é fornecido suporte de LRF IMS ou E-CSCF IMS. E isto pode permitir que a MNO servidora 890/990 migre do suporte de LRF IMS para o suporte de E- CSCF MS ou vice-versa sem necessidade de alterações no suporte do UE 800/900 ou do SP OTT 850/950. Pode permitir também que o SP OTT 850/950 receba suporte de LRF IMS de acordo com a Figura 8 de um ou mais MNOs (a MNO 890, por exemplo) e receba suporte de E-CSCF IMS de acordo com a Figura 9 de uma ou mais outras MNOs (a MNO 990, por exemplo) para chamadas de emergência que podem ser originadas por UEs diferentes (o UE 800 ou o UE 900, por exemplo) que acessam o SP OTT 850/950 de uma destas MNOs.
[0164] Os fluxos de chamadas das Figuras 8 e 9 aplicam-se à solução S1 da Figura 3. A solução S2 da Figura 3, os fluxos de chamadas podem ser quase os mesmos, exceto pelo fato de que a solicitação da chamada de emergência descrita em seguida em 806/906 em cada fluxo de chamadas não incluiria alguns ou todos os dados do UE e/ou os dados da MNO. Em vez disso, o SP OTT 850/950 consultaria o UE 800/900 quanto aos dados do UE e/ou os dados da MNO em seguida a 806/906 (enviando uma INFO SIP contendo a solicitação ao UE 800/900 e com o UE 800/900 devolvendo os dados do UE e/ou os dados da MNO solicitados em um OK SIP ou em uma INFO SIP. Para a solução S2 o SP OTT 850/950 pode precisar também consultar o UE 800/900 quanto aos dados da MNO atualizados que o UE 800/900 envia em 426 na Figura 8 e 920 na Figura 9. Entretanto, esta solicitação pode ser combinada implícita ou explicitamente com a solicitação (mencionada acima) dos dados do UE e dos da MNO enviados inicialmente ao UE 800/900 depois 806/906.
[0165] 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 pode não reconhecer que o usuário discou um número de emergência (tal como “911” por exemplo) 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 da chamada de emergência. O SP OTT 850/950 pode reconhecer então que a solicitação de chamada enviada em 806/906 é uma chamada de emergência (pode detectar que os dígitos discados são de um número de emergência, tal como “911”, por exemplo) e pode solicitar dados da MNO e/ou dados do UE 800/900 antes de prosseguir com 808/908 mostrados nas Figuras 8 e 9. As outras operações nas Figuras 8 e 9 que na são modificadas conforme acaba de ser descrito para a solução S2 da Figura 3 podem ocorrer conforme descrito em seguida.
[0166] As interações mostradas na Figura 8 podem aplicar-se a um UE 800 que instiga uma chamada de emergência por meio de um SP OTT 850/950 em circunstancias nas quais o UE 800 está acessando uma MNO servidora (está acessando o SP OTT 850 por meio da MNO servidora 890, por exemplo). Em 802 na Figura 8, o UE 800 pode solicitar dados da AN ou PCN 892 na MNO servidora 890 para suportar uma chamada de emergência utilizando um SP OTT 850. Por exemplo, isto pode ocorrer quando o UE 800 detectada que o usuário está instigando uma chamada de emergência. O bloco 802 é opcional e pode nem sempre correr.
[0167] Em 804, em resposta a 802, ou quando determinadas condições ocorrerem (o UE 800 se anexa à AN/PCN 892, efetua uma atualização de área de rastreamento ou área de roteamento para uma nova MME ou SGSN ou um handover ocorre para uma nova MME ou SGSN, por exemplo) a AN u PCN 892 envia dados da MNO ao UE 800. Os dados da MNO podem incluir (i) um endereço de IMS para uma MNO servidora 890 (o endereço de uma LRF no IMS 894, por exemplo), (ii) se a localização no plano de controle puder ser utilizada, uma identidade para a MME servidora atual ou SGSN atual para o UE 800 ou (iii) se a localização no plano do usuário puder ser utilizada, um endereço IP atribuído pela MNO para o UE 800 e/ou (iv) ou uma identidade global (IMSI ou MSISDN, por exemplo) para o UE 800 ou uma identidade local para o UE 800 atribuída pela MME servidora ou pelo SGSN servidor para o UE 800.
[0168] Em 806, em resposta à detecção pelo UE 800, de que o usuário do UE 800 instigou uma chamada de emergência (se o UE 800 detectar que o usuário discou os dígitos “911”, por exemplo), o UE 800 envia uma solicitação da chamada de emergência ao SP OTT 850 e inclui os dados da MNO obtidos em 804 e possivelmente dados do UE adicionais conhecidos do UE. Os dados do UE podem incluir uma identidade global para o UE 800 (um IMSI ou MSISDN, por exemplo) e possivelmente um endereço IP abo pela MNO para o UE 800 senão recebido em 804. A solicitação da chamada de emergência em 806, alguma SIP ou pode ser uma mensagem para algum outro protocolo específico do SP OTT 850. O bloco 806 pode corresponder ao envio da solicitação da chamada de emergência 501 da Figura 5.
[0169] Em 808, com base no recebimento em 806 de um endereço de IMS na MNO servidora 890 (onde o endereço de IMS pode ser parte dos dados da MNO recebidos 806 e pode ser um endereço de RLF incluído no cabeçalho de roteamento de um CONVITE SIP enviado em 806, por exemplo), o SP OTT 850 envia um CONVITE SIP ao IMS 894 (a uma LRF no IMS 894, por exemplo) indicado pelo endereço de IMS na MNO servidora 890. O CONVITE SIP inclui os dados da MNO e quaisquer dados do UE recebidos em 808 indica uma chamada de emergência e inclui a identidade e possivelmente a localização (país, por exemplo) do SP OTT 850. O CONVITE SIP pode ser uma cópia parcial ou completa de qualquer CONVITE SIP recebido em 806. O bloco 808 pode corresponder ao enviado do CONVITE SIP 502A da Figura 5.
[0170] Em alguns casos o CONVITE SIP enviado em 808 pode ser primeiro recebido em uma função de controle de fronteira (uma IBCF, por exemplo) no IMS 894 da MNO servidora para segurança antes de ser emitido para uma RLF no IMS 894 (não mostrado na Figura 8). O IMS 894 (uma RLF ou IBCF no IMS 894, por exemplo) pode primeiro verificar que o CONVITE SIP enviado em 808 se origina de um SP OTT válido, por exemplo, utilizando dados pré-configurados baseados em alguma relação comercial entre a MNO servidora 890 e o SP OTT 850 e possivelmente utilizando uma conexão IP segura entre o SP OTT 850 e o IMS 894 da MNO servidora de modo a transferir o CONVITE SIP em 808. Em alguns casos, em 810, o IMS 894 (uma LRF no IMS 894, por exemplo) utiliza os dados da MNO e quaisquer dados do UE enviados em 808 para obter a localização do UE 800, por exemplo, utilizando uma solução de localização no plano de controle ou no plano do usuário. Em alguns outros casos, o bloco 810 não ocorre e o IMS 894 pode determinar a localização (a localização aproximada, por exemplo) para o UE 800 de outros dados recebidos no CONVITE SIP em 808, tais como uma LbyV incluída pelo UE 800 na solicitação de chamada de emergência enviada em 806 e transferida pelo SP OTT 850 para o IMS 894 em 808.
[0171] O IMS 894 (uma RDF no IMS 894, por exemplo) determina então um PSAP de destino 880/882 ou uma rota na direção do PSAP de destino 880/882, que corresponde à localização do UE 800 e deriva um URI de roteamento (que pode ser também referido como URI de rota) para permitir roteamento de chamadas do SP OTT 850 para o ou na direção do 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 (um SR no caso de um PSAP Legado 882 ou de um ponto de ingresso em uma ESInet 860 para um PSAP capaz de i3 880, por exemplo) e pode depender da identidade do SP OTT 850 e/ou da localização do SP OTT 850 (se a localização for no mesmo país da MNO servidora 890 ou for em um país diferente, por exemplo). O IMS 894 (uma LRF no IMS 894, por exemplo) determina também um identificador (ID) de referência para permitir uma solicitação de localização subsequente para o UE 800 de uma ESInet 860 ou do PSAP 880/882 posteriormente. O ID de referência pode ser ou (i) um ESRK ou (ii) um SRD mais MSISDN no caso de um PSAP Legado 882, ou pode ser (iii) um URI de localização no caso de um PSAP capaz de (iii) 880.
[0172] Em 812, o IMS 894 (uma LRFV no IMS 894, por exemplo) devolve o URI de roteamento e o ID de referência ao SP OTT 850 em uma mensagem de 300 Múltiplas Escolhas SIP. Observe-se que o IMS 894 pode não devolver a localização (LbyV, por exemplo) ao SP OTT 850 se a identidade do SP OTT 850 não tiver sido completamente validade ou se a relação comercial com o SP OTT 850 só proporcionar suporte de roteamento pela MNO servidora 890. O bloco 812 pode corresponder ao envio das 300 Múltiplas Escolhas SIP 502B da Figura 5.
[0173] Em 814, se o IMS 894 (uma LRF no IMS 894, por exemplo) precisar utilizar localização no plano de controle, o IMS 894 envia uma mensagem de ASSINATURA SIP ao SP OTT 850 para assinar notificação de alterações nos dados da MNO (alteração do endereço da MME servidora ou do SGSN servidor, por exemplo). O IMS 894 pode enviar também uma mensagem de ASSINATURA SIP para o SP OTT 850 para assinar notificação de término de chamada (não mostrado na Figura 8).
[0174] Em 816, se 814 ocorrer, o SP OTT 850 devolve uma mensagem de OK 200 (não mostrada na Figura 8) ao IMS 894 e em seguida uma mensagem de notificação para cada mensagem de assinatura recebida que porta os dados da MNO atuais no caso de assinatura dos dados da MNO em 814 e/ou o estado de chamada atual no caso de assinatura do término de chamadas.
[0175] Em seguida ao 812 (e possivelmente em seguida a 816 se 816 ocorrer), o SP OTT 850 determina se o PSAP de destino é um PSAP Legado 882 ou um PSAP capaz de i3 880 a partir do conteúdo do URI de roteamento ou do ID de referência devolvido em 812. No caso de um PSAP Legado 882, o SP OTT 850 pode emitir a chamada utilizando CS para ou na direção do PSAP 882. Em uma modalidade, o SP OTT 850 envia uma mensagem IAM ISUP em 818A a um destino CS intermediário 863 (um SR, por exemplo) indicado no URI de roteamento recebido em 812. O SP OTT 850 inclui também qualquer ESRK ou ESRD mais MSISDN no ID de referência recebido em 802 no IAM ISUP. O bloco 818A pode corresponder ao envio da solicitação 503A da Figura 5.
[0176] Em 820A o destino CSA intermediário 863 emite a chamada para o PSAP Legado 882 e inclui o SRK ou ESRD mais MSISIDM recebido em 818A.
[0177] Em 822A é executado o restante do estabelecimento de chamada. Os blocos 818B e 820B e 822B não são então executados.
[0178] Quando o SP OTT 850 determina um PSAP i3 880 em vez de um PSAP Legado 882 depois de 812, os blocos 818A, 820A e 822A não são executados. Em vez disso, o SP OTT 850 emite a chamada para ou na direção do PSAP 880. Em uma modalidade o SP OTT 850 emite a chamada em 818B para uma ESInet 860 indicada pelo URI de roteamento recebido em 812 enviando um CONVITE SIP que contém o URI de localização recebido no ID de referência em 812. O bloco 818 pode corresponder ao envio da solicitação 503B da Figura 5.
[0179] No bloco 820B, a ESInet 860 emite a chamada para o PSAP i3 880 e inclui o URI de localização recebido em 818B.
[0180] Em 822B é executado o restante do estabelecimento de chamada.
[0181] Em 824 se houver uma alteração nos dados da MNO (o UE 800 é transferido para um novo SGSN ou MME, por exemplo) e se a MNO servidora 890 puder utilizar localização no plano de controle para o UE 800, a AN ou PCN 892 envia novos dados da MNO ao UE 800 (a identidade de uma nova MME ou SGSN servidor para o UE 800 e uma identidade local para o UE 800 na nova MME ou SGSN servidor, por exemplo). O envio dos novos dados da MNO em 824 pode ser automático sempre que os dados da MNO se alterarem (sem conhecimento pela AN ou PCN 892 sem conhecimento pela AN ou PCN 892 na MNO servidora 890 de que uma chamada de emergência para o UE 800 por meio de um SP OTT 850 está em progresso, por exemplo) ou pode ser acionado pelo fato de o UE 800 ter enviado anteriormente uma solicitação de dados da MNO em 802.
[0182] Em 826, o UE 800 emite os novos dados da MNO para o SP OTT 850, por exemplo, utilizando uma mensagem de INFO SIP quando o SIP é utilizado entre o UE 800 e o SP OTT 850.
[0183] Em 828, se o IMS 894 tiver assinado notificação de alterações nos dados da MNO em 814, o SP OTT 850 envia os novos dados da MNO ao IMS 894 (uma LRF no IMS 894, por exemplo) em uma mensagem de NOTIFICAÇÃO SIP. Os novos dados da MNO são armazenados para utilização futura pelo IMS 894. Por exemplo, os novos dados da MNO podem ser utilizados posteriormente no bloco 832A ou no bloco 832B para ajudar a obter a localização para o UE 800.
[0184] Em 830A, no caso de um PSAP Legado 882, o PSAP 882 ou uma entidade associada ao PSAP 882, tal como uma ALI (a ALI 561, por exemplo) pode enviar uma mensagem de ESPOSREQ de interface (cadeia RF definido no padrão conjunto TIA-ATIS J-STD-036, por exemplo) ao INSTRUÇÕES 894 (uma LRF, por exemplo) indicada pelo ESRK ou ESRD recebido em 820A de modo a solicitar A localização DO UE 800 E inclui ou o ESRK ou o ESRD mais MSISDN recebido em 820A. O bloco 830A pode corresponder ao envio da consulta 804 da Figura 5.
[0185] Em 832A, o IMS 894 (uma LRF, por exemplo) utiliza o ESRK ou MSISDN recebido em 830A para identificar o UE 800 e utiliza quaisquer dados do UE recebidos em 808 e/ou os dados da MNO recebidos em 808 ou 828, se 828 ocorrer, para obter a localização do UE 800 utilizando uma solução de localização no plano de controle ou no plano do usuário.
[0186] Em 834A, o IMS 894 (uma LRF, por exemplo) devolve a localização ao PSAP 882 (ou a uma entidade associada ao PSAP 882, tal como uma ALI.
[0187] Em 830B, no caso de um PSAP capaz de i3 880, o PSAP i3 880 anula a referência do URI de localização recebido em 820B enviando uma solicitação de localização ao IMS 894 (uma LRF no IMS 894, por exemplo) indicada no URI de localização e que porta o URI de localização. O bloco 830B pode corresponder ao envio da consulta 504B da Figura 5.
[0188] Em 832B, o IMS 894 (uma LRF, por exemplo) utiliza no URI de localização recebido em 830B para identificar o UE 800 e utiliza quaisquer dados do UE recebidos em 808 e/ou os dados da MNO recebidos em 808 ou 828, se 828 ocorrer, para obter a localização do UE 800 utilizando uma solução de localização no plano de controle ou no plano do usuário.
[0189] Em 834B, o IMS 894 (uma LRF, por exemplo) devolve a localização ao PSAP 880.
[0190] Blocos semelhantes ou idênticos a 830B, 832B e 834B podem ocorrer em seguida a 818B para permitir que a ESInet 860 obtenha a localização para o UE 800 do IMS 894 (de uma LRF no IMS 894, por exemplo) e, com base na localização, roteie a chamada de emergência em 820B para o PSAP 880 correto. Nesse caso, a ESInet 860 (um SRP na ESInet 860, tal como o ESRP 666, por exemplo) pode enviar uma solicitação de localização do UE 800 ao IMS 894 em um bloco semelhante ou idêntico a 830B e pode receber uma localização para o UE 800 para do IMS 894 em um bloco semelhante ou idêntico a 834B.
[0191] As interações mostradas na Figura 9 aplicam-se a um UE 900 que instigam uma chamada de emergência por meio de um SP OTT 950 em circunstâncias nas quais o UE 900 está acessando uma MNO servidora 990 (está acessando o SP OTT 950 por meio de MNO servidora 790, por exemplo). Em 902 da Figura 9, o UE 900 pode solicitar dados da AN ou PSN 992 na MNO servidora 990 para suportar uma chamada de emergência utilizando um SP OTT 950. Por exemplo, isto pode ocorrer quando o UE 900 detectar que o usuário está instigando uma chamada de emergência. A operação 902 é opcional e pode nem sempre ocorrer.
[0192] Em 904, em resposta a 902, ou quando determinadas condições ocorrerem (o UE 900 se anexa à AN/PCN 992, efetua uma atualização de área de rastreamento ou área de roteamento para uma nova MME ou SGSN na AN/PCN 992 ou um handover ocorre para uma nova MME ou SGSN, por exemplo) a AN ou PCN 992 envia dados da MNO ao UE 900. Os dados da MNO podem incluir (i) um endereço de IMS para uma MNO servidora 990 (o endereço de uma E-CSCF no IMS 994, por exemplo), (ii) se a localização no plano de controle puder ser utilizada, uma identidade para a MME servidora atual ou SGSN atual para o UE 900 ou (iii) se a localização no plano do usuário puder ser utilizada, um endereço IP atribuído pela MNO para o UE 900 e/ou (iv) ou uma identidade global (IMSI ou MSISDN, por exemplo) para o UE 900 ou uma identidade local para o UE 900 atribuída pela MME servidora ou pelo SGSN servidor para o UE 900.
[0193] Em 906, em resposta à detecção pelo UE 900, de que o usuário do UE 900 instigou uma chamada de emergência (se o UE 900 detectar que o usuário discou os dígitos “911”, por exemplo), o UE 900 envia uma solicitação da chamada de emergência ao SP OTT 950 e inclui os dados da MNO obtidos em 904 e possivelmente dados do UE adicionais conhecidos do UE 900. Os dados do UE podem incluir uma identidade global para o UE 900 (um IMSI ou MSISDN, por exemplo) e possivelmente um endereço IP atribuído pela MNO para o UE 900 senão recebido em 904. A solicitação da chamada de emergência em 906, pode ser um CONVITE SIP ou pode ser uma mensagem para algum outro protocolo específico do SP OTT 950. O bloco 906 pode corresponder ao envio da solicitação da chamada de emergência 601 da Figura 6.
[0194] Em 908, com base no recebimento de um endereço de IMS como parte dos dados da MNO recebido em 906 (onde o endereço de IMS é um endereço de E-CSCF em um cabeçalho de roteamento de um CONVITE SIP recebido em 906, por exemplo), o SP OTT 950 envia um CONVITE SIP ao IMS 994 a uma E-CSCF 904, 994, por exemplo, indicado pelo endereço de IMS na MNO servidora 990. O CONVITE SIP enviado em 980 inclui os dados da MNO e quaisquer dados do UE recebido em 906, crítica uma chamada de emergência e inclui a identidade e possivelmente a localização (ou país, por exemplo), do SP OTT 950. O CONVITE SIP enviado em 908 pode ser uma cópia parcial ou completa de qualquer CONVITE SIP recebido em 906. O bloco 908 pode corresponder ao envio do CONVITE SIP 602 da Figura 6.
[0195] Em alguns casos o CONVITE SIP enviado em 908 pode ser primeiro recebido em uma função de controle de fronteira (uma IBCF, por exemplo) no IMS 994 da MNO servidora para segurança antes de ser emitido para uma E- CSCF no IMS 994 (não mostrado na Figura 9). O IMS 994 (uma E-CSCF ou IBCF no IMS 994, por exemplo) pode verificar que o CONVITE SIP enviado em 908 se origina de um SP OTT 950 válido, por exemplo, utilizando dados pré-configurados baseados em alguma relação comercial entre a MNO servidora 990 e o SP OTT 950 e possivelmente utilizando uma conexão IP segura entre o SP OTT 950 e o IMS 994 da MNO servidora de modo a transferir o CONVITE SIP em 908. Em alguns casos, em 910, o IMS 994 (uma LRF no IMS 994, por exemplo) utiliza os dados da MNO e quaisquer dados do UE recebidos em 908 para obter a localização do UE 900, por exemplo, utilizando uma solução de localização no plano de controle ou no plano do usuário. Em alguns outros casos, o bloco 910 não ocorre e o IMS 994 pode determinar a localização (a localização aproximada, por exemplo) para o UE 900 de outros dados recebidos no CONVITE SIP em 908, tais como uma LbyV incluída pelo UE 900 na solicitação de chamada de emergência enviada em 906 e transferida pelo SP OTT 950 para o IMS 994 em 908.
[0196] Em 911, que pode seguir-se a 908 ou 910 se 910 ocorrer, o IMS 994 (uma RDF no IMS 994, por exemplo) determina um PSAP de destino 980/982 ou uma rota na direção de um PSAP de destino 980/982 (que corresponde à localização do UE 900 obtida em 910, por exemplo) e determina um URI de roteamento (também referido como URI de rota) para permitir o roteamento de chamadas do 994 para o ou na direção do PSAP de destino 980/982. O URI de roteamento pode indicar (i) o endereço ou identidade do PSAP 980/982 ou (ii) o endereço ou identidade de um destino intermediário tal como um SR 863 no caso de um PSAP Legado 982 ou um ponto de ingresso para uma ESInet 960 no caso de um PSAP capaz de i3 980. Como parte da determinação de um PSAP de destino 980/982 em 911, ou uma rota na direção de um PSAP de destino 980/982, o IMS 994 (uma RLF no IMS 994, por exemplo) determina um identificador (ID) de referência para permitir uma solicitação de localização subsequente para o UE 900 de uma ESInet 960 ou do PSAP 980/982 posteriormente. O ID de referência pode ser ou (i) um ESRK ou (ii) um SRD mais MSISDN no caso de um PSAP Legado 982 ou (iii) um URI de localização no caso de um PSAP capaz de i3 980. O IMS 994 (uma E-CSCF 994, por exemplo) determina também em 911 se o PSAP de destino é um PSAP Legado ou PSAP capaz de i3 980 (a partir do URI de roteamento ou do ID de referência que foram determinados em 911, por exemplo).
[0197] Em algumas implementações, a localização do UE 900 em 910 quando 910 ocorre e a determinação de um PSAP de destino ou de uma rota na direção de um PSAP de destino, em 911, que inclui a determinação do URI de roteamento e do ID de referência em 911, podem ser executadas por uma LRF (a LRF 648, por exemplo), possivelmente auxiliada por uma RDF (A RDF 646, por exemplo), o IMS 994 (se o IMS 994 corresponder ao IMS 640 da Figura 6, por exemplo). Nestas implementações, o CONVITE SIP enviado em 908 pode ser recebido por uma E-CSCF (a E-CSCF 643, por exemplo) no IMS 994 e em seguida emitido para a LRF (a LRF 648, por exemplo) no IMS 994 pela E-CSCF.A LRF (a LRF 648, por exemplo) no IMS 994 pode obter então a 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 o ID de referência e devolver e o ID de referência determinados de volta à E-CSCF (a E-CSCF 643, por exemplo) no IMS 994 em uma mensagem de 300 Múltiplas Escolhas SIP. Embora não mostrada na Figura 9, esta interação entre a E-CSCF (a E-CSCF 643, por exemplo) e uma RLF (a RLF 648, por exemplo) no IMS pode corresponder ao enviado da solicitação 603A e da resposta 603B entre a E- CSCF 643 a LRF 648 que foram descritas em associação com a Figura 6.
[0198] No caso da determinação de um PSAP Legado 982 em 911, o IMS 994 (uma MGCF no IMS 994, por exemplo) pode emitir a chamada utilizando CS em 912A para o ou na direção do PSAP 982. Em uma modalidade, o IMS 994 envia uma mensagem IAM ISUP em 912A para a um SR 963 indicado no URI de roteamento determinado depois de 908 ou 910 (se 910 ocorrer). O IMS 994 incluem na IAM ISUP qualquer ESRK ou ESRD mais MSISDN indicado no ID de referência determinado em 911.
[0199] Em 914A, o SR 963 emite a chamada para o PSAP Legado e inclui o ESRK ou ESRD mais MSISDN recebido em 912A.
[0200] Em 916A é executado o restante do estabelecimento de chamada entre o UE 900, o SP OTT 950, o IMS, o SR 963 e o PSAP Legado 982. Os blocos 912B, 914B e 916B não são então executados.
[0201] Quando o IMS 994 determina um PSAP i3 980 em vez de um PSAP Legado 982 em 911, os blocos 912A, 914A e 916A não são executados. Em vez disso, em 912B, o IMS 994 (uma E-CSCF no IMS 994, por exemplo) emite a chamada de emergência para o ou na direção do PSAP 980. Em uma modalidade, o IMS 994 emite a chamada de emergência para uma ESInet 960 indicada como URI de roteamento determinado em 911 enviando um CONVITE SIP que contém o URI de localização a partir do ID de referência determinado em 911.
[0202] Em 916B, é executado o restante do estabelecimento de chamada entre o UE 900, o SP OTT 950, o IMS 994, a ESInet 960 e o PSAP i3.
[0204] Em 918, se houver uma alteração nos dados da MNO (o UE 900 é transferido para um novo SGSN ou MME na MNO servidora 990, por exemplo) e se a MNO servidora 990 puder utilizar localização no plano de controle para o UE 900, a AN ou PCN 992 fornece novos dados da MNO ao UE 900 (a identidade para uma nova MME servidora ou um novo SGSN servidor para o UE 900 e uma identidade local para o UE 900 na nova MME ou SGSN servidor, por exemplo). O envio destes novos dados da MNO pode ser automático sempre que os dados da MNO se altere (sem conhecimento pela AN ou PCN 992 na MNO servidora 990 de que uma chamada de emergência para o UE 900 por meio de um SP OTT 950 está em progresso, por exemplo) ou pode ser acionado pelo fato de o UE 900 ter enviado anteriormente uma solicitação em 902.
[0205] Em 920 o UE 900 em 920, o UE 900 emite os novos dados da MNO para o SP OTT 950, por exemplo, utilizando uma mensagem de INFO SIP quando o SIP é utilizado entre o UE 900 e o SP OTT 950.
[0206] Em 922, o SP OTT 950 emite os novos dados da MNO para o IMS 994 (para uma E-CSCF no IMS 994, por exemplo), utilizando uma mensagem de INFO SIP. Os dados da MNO são armazenados para utilização futura pelo IMS 994 (por uma RLF no IMS 994, por exemplo).
[0207] Em 924A, no caso de um PSAP Legado 982, o PSAP 982 ou uma entidade associada ao PSAP 982 (uma ALI tal como a ALI 661, por exemplo) pode enviar uma mensagem de ESPOSREQ de interface E2 (definida no padrão TIA/ATIS J- STD-036, por exemplo) ao IMS 994 (uma LRF no IMS 994, por exemplo) conforme indicado pelo ESRK ou ESRD recebido em 914A para solicitar a localização do UE 900 que inclui ou o ESRK ou o ESRD, mas MSISDN recebido em 914A. O bloco 924 pode corresponder ao envio da solicitação de localização 605A da Figura 6.
[0208] Em 926A, o IMS 994 (uma LRF no IMS 994 , por exemplo) utiliza o ESRK ou MSISDN recebido em 924A para identificar o UE 900 e utiliza quaisquer dados do UE recebidos em 908 e/ou os dados da MNO recebidos em 908 ou 922, se 922 ocorrer, para obter a localização do UE 900 utilizando uma solução de localização no plano de controle ou no plano do usuário.
[0209] Em 928A, o IMS 994 (uma LRF no IMS 994, por exemplo) devolve à localização do UE 900 ao PSAP Legado 982 (ou a uma entidade associada ao PSAP 882, tal como uma ALI).
[0210] Em 924B, no caso de um PSAP capaz de i3 980, o PSAP i3 980 anula a referência do URI de localização recebido em 914B enviando uma solicitação de localização ao IMS 994 (uma RLF no IMS 994, por exemplo) indicada no URI de localização e que porta o URI de localização. O bloco 924B pode corresponder ao envio da solicitação de localização 665B da Figura 6.
[0211] Em 926B, o IMS 924 (uma LRF no IMS 994, por exemplo) utiliza o URI de localização recebido em 924B para identificar o UE 900 e utiliza quaisquer dados do UE recebidos em 908 e/ou os dados da MNO recebidos em 908 ou 922, se 922 ocorrer para obter a localização do UE 900 utilizando uma solução de localização no plano de controle ou no plano do usuário.
[0212] Em 928B, o IMS 994 (uma RLF no IMS 994,por exemplo) devolve a localização do UE 900 ao PSAP capaz de i3 980.
[0213] Blocos semelhantes ou idênticos a 924B, 926B e 928B podem ocorrer em seguida a 912B para permitir que a ESInet 960 obtenha a localização para o UE 8900 do IMS 994 (de uma LRF no IMS 994, por exemplo) e, com base na localização, roteie a chamada de emergência em 914B para o PSAP 980 correto. Nesse caso, a ESInet 960 (um SRP na ESInet 960, tal como o ESRP 666, por exemplo) pode enviar uma solicitação de localização do UE 900 ao IMS 994 em um bloco semelhante ou idêntico a 924B e pode receber uma localização para o UE 900 do IMS 994 em um bloco semelhante ou idêntico a 928B.
[0214] Deve-se observar que os procedimentos e técnicas descritos em associação com as Figuras 4-9 podem contar com o UE que instigou a chamada de emergência enviando quaisquer atualizações para uma LbyR (para as Figuras 4 e 7, por exemplo) ou quaisquer atualizações nos dados da MNO (como em 826 na Figura 8 e 920 na Figura 9, por exemplo) ao SP OTT ao UE de modo a permitir que o SP OTT emita a atualização para um PSAP ou para uma entidade de IMS, tal como uma RLF (como em 828, na Figura 8, por exemplo), ou uma E-CSCF como em 922 na Figura 9, por exemplo. Em modalidades alternativas, contudo, uma LbyR atualizada ou dados da MNO atualizados (que podem resultar depois que o UE que instigou a chamada de emergência for transferido para um novo SGSN ou uma nova MME, por exemplo) podem ser enviados a um PSAP ou a um entidade de IMS na MNO servidora (tal como uma RLF ou E-CSCF) pela AN ou PCN na MNO servidora (por uma MME ou SGSN na AN ou PCN, por exemplo) e não pelo UE. Isto pode ocorrer, por exemplo, se uma entidade de IMS na MNO servidora para o UE que instigou a chamada de emergência ou uma entidade associada com esta (GMLC, por exemplo) enviar uma solicitação de qualquer LbyR atualizada ou de dados de MNO atualizados a uma entidade na AN ou PCN da MNO servidora (a uma MME ou SGSN, por exemplo) depois de detectar que o UE está instigando uma chamada de emergência (depois de 708, 808 e 908 em cada uma das Figuras 7, 8 e 9, respectivamente, por exemplo). Com estas modalidades alternativas pode não ser necessário, a LbyR atualizada ou os dados da MNO atualizados 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, tal como uma LRF ou E- CSCF.
[0215] A Figura 10 mostra vários components de amostra (representados por blocos correspondentes) que podem ser incorporados a um equipamento 1002, a um equipamento 1004 e a um equipamento 1006 (que correspondem, por exemplo, a um aparelho de usuário, tal como o UE 200, 300, 400, 500, 600, 700, 800 ou 900, a um nó de rede de acesso, tal como o nó de rede de acesso 240 e a uma entidade de rede, tal como o SP OTT 150, o servidor de localização 170, etc., respectivamente, para suportar as operações aqui ensinadas. Deve ficar entendido que estes componentes podem ser implementados em tipos diferentes de equipamento em implementações diferentes (em um ASIC, em um SoC, etc.). Os componentes mostrados podem ser também incorporados a outros equipamentos em um sistema de comunicação. Por exemplo, outros equipamentos em um sistema podem incluir componentes semelhantes aos descritos de modo a se obter funcionalidade semelhante. Além disto, um dado equipamento pode conter um ou mais dos componentes. Por exemplo, um equipamento pode incluir vários equipamentos de transceptor que permitem que o equipamento funcione em várias portadoras e se comunique por meio de tecnologias diferentes.
[0216] O equipamento 1002 e o equipamento 1004 incluem, cada um, pelo menos um aparelho de comunicação sem fio (representado pelos aparelhos de comunicação 1008 e 1014 (e pelo aparelho de comunicação 1020, se o equipamento 1004 for um retransmissor)) para comunicação com outros nós por meio de pelo menos uma RAT designada. Cada aparelho de comunicação 1008 inclui pelo menos um transmissor (representado pelo transmissor 1010) para transmitir e codificar sinais (como, por exemplo, mensagens, indicações, informações e assim por diante) e pelo menos um receptor (representado pelo representar 1012) para receber e decodificar sinais (como, por exemplo, mensagens, indicações, informações, pilotos e assim por diante). Da mesma maneira, cada aparelho de comunicação 1014 inclui pelo menos um transmissor (representado pelo transmissor 1016) para transmitir sinais (como, por exemplo, mensagens, indicações, informações, pilotos e assim por diante) e pelo menos um receptor (representado pelo receptor 1018) para receber sinais (como, por exemplo, mensagens, indicações, informações e assim por diante). Se o equipamento 1004 for uma estação retransmissora, cada aparelho de comunicação 1020 pode incluir pelo menos um transmissor (representado pelo transmissor 1022) para transmitir sinais (como, por exemplo, mensagens, indicações, informações, pilotos e assim por diante) e pelo menos um receptor (representado pelo receptor 1024) para receber sinais (como, por exemplo, mensagens, informações e assim por diante).
[0217] Um transmissor e um receptor podem compreender um aparelho integrado (corporificado como um circuito de transmissor e um circuito de receptor de um único aparelho de comunicação, por exemplo), em algumas implementações, podem compreender um aparelho transmissor separado, e um aparelho receptor separado em algumas implementações ou podem ser corporificados de outras maneiras em outras implementações. Um aparelho de comunicação sem fio (um de vários aparelhos de comunicação sem fio, por exemplo) do equipamento 1004 pode compreender também um Módulo de Escuta de Rede (NLM) ou semelhantes para efetuar diversas medições.
[0218] O Equipamento 1006 (e o equipamento 1004 se não for uma estação retransmissora) inclui pelo menos um aparelho de comunicação (representado pelo aparelho de comunicação 1026 e opcionalmente 1020) para comunicação com outros nós. O aparelho de comunicação 1026 pode compreender uma interface de rede que é configurada para comunicar-se com uma ou mais entidades de rede por meio de um canal de transporte de retorno cabeado ou sem fio. Sob alguns aspectos, o aparelho de comunicação 1026 pode ser implementado como um transceptor configurado para suportar comunicação de sinais cabeados ou sem fio. Esta comunicação pode envolver, por exemplo, enviar e receber: mensagens, parâmetros ou outros tipos de informação. Por conseguinte, no exemplo da Figura 10, o aparelho de comunicação 1026 é mostrado como compreendendo um transmissor 1028 e um receptor 1030. Da mesma maneira, se o equipamento 1004 não for uma estação retransmissora, o aparelho de comunicação 1020 pode compreender uma interface de rede que é configurada para comunicar-se com uma ou mais entidades de rede por meio de um canal de transporte de retorno cabeado ou sem fio,. Como ocorre com o aparelho de comunicação 1026, o aparelho de comunicação 1020 é mostrado como compreendendo um transmissor 1022 e um receptor 1024.
[0219] Os equipamentos 1002, 1004 e 1006 incluem também outros componentes que podem ser utilizados em conjunto com operações relacionadas com localização de SP OTT e UE aqui ensinadas. O equipamento 1002 inclui um sistema de processamento 1032 e um módulo de posicionamento 1054 para proporcionar funcionalidade referente a, por exemplo, operações do aparelho de usuário para suportar operações relacionadas com localização de SP OTT e UE aqui ensinadas e para proporcionar outra funcionalidade de processamento. O equipamento 1004 inclui um sistema de processamento 1034 e um módulo de posicionamento 1056 para proporcionar funcionalidade referente a, por exemplo, operações de nó de rede de acesso para suportar operações relacionadas com localização de SP OTT e UE aqui ensinadas e para proporcionar outra funcionalidade de processamento. O equipamento 1006 inclui um sistema de processamento 1036 e um módulo de posicionamento 1059 para proporcionar funcionalidade referente a, por exemplo, operações de rede para suportar operações relacionadas com localização de SP OTT e UE aqui ensinadas e para proporcionar outra funcionalidade de processamento.
[0220] Os equipamentos 1002, 1004, 1006 incluem também componentes de memória 1038, 1040 e 1042 (cada um incluindo um aparelho de memória, por exemplo), respectivamente, para manter informações (como, por exemplo, informações indicativas de recursos reservados, limites, parâmetros e assim por diante). Além disso, os equipamentos 1002, 1004 e 1006 incluem aparelhos de interface de usuário 1034, 1046 e 1048, respectivamente, para fornecer indicam (indicações audíveis e/ou visuais, por exemplo) ao usuário e/ou para receber entrada de usuário (como, por exemplo, mediante a atuação pelo usuário de um aparelho detector, tal como um teclado, uma tela sensível ao toque, um microfone, e assim por diante).]
[0221] Por conveniências, os equipamentos 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 aqui descritos. Deve ficar entendido que os blocos mostrados podem ter funcionalidade diferente em desenhos diferentes.
[0222] Os componentes da Figura 10 podem ser implementados de diversas maneiras. Em algumas implementações, os componentes da Figura 10 podem ser implementados em um ou mais circuitos, tais como um ou mais processadores e um ou mais ASICs (que podem incluir um ou mais processadores). Aqui, cada circuito pode utilizar e/ou incorporar pelo menos um componente de memória para armazenar informações ou código executável utilizados pelo circuito para proporcionar esta funcionalidade. Por exemplo, alguma ou toda funcionalidade representada pelos blocos 1008, 1032, 1038, 1044 e 1054 pode ser implementada por componentes de processador e memória do equipamento 1002 (por execução de código apropriado e/ou por configuração apropriada de componentes de processador, por exemplo). Da mesma maneira, alguma ou toda funcionalidade representada pelos blocos 1026, 1036, 1042, 1048 e 1058 pode ser implementada por componentes de processador e memória do equipamento 1006 (por execução de código apropriado e/ou por configuração apropriada de componentes de processador, por exemplo). Por exemplo, os módulos de posicionamento 1054, 1056 e 1058 podem ser módulos executáveis armazenados em memória ou podem ser componentes de hardware/firmware acoplados aos sistemas de processamento 1032, 1034 e 1036.
[0223] A Figura 11 é um diagrama de blocos que mostra componentes exemplares de um UE 1100, de acordo com pelo menos um aspecto da revelação. O UE 1100 pode corresponder a ou representar qualquer um dos UEs 1 a N da 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 diversos recursos e funções mostrados no diagrama de caixas da Figura 11 podem ser conectados entre si utilizando-se um barramento comum (não mostrado na Figura 11) ou podem ser conectados (conforme mostrado na Figura 11), por meio de processadores 1130. Os versados na técnica reconhecerão que outras conexões, mecanismos, recursos, funções ou semelhantes podem ser apresentados e adaptados conforme necessário para acoplar e configurar operacionalmente um aparelho sem fio portátil real. Além disto, deve-se reconhecer também que um ou mais recursos ou funções mostrados no exemplo da Figura 11 podem ser também subdivididos ou dois ou mais dos recursos ou funções mostrados na Figura 11 podem ser combinados.
[0224] O UE 1100 pode incluir um ou mais Bluetooth 1114a que podem ser conectados a uma ou mais antena 1112. O transceptor Bluetooth compreende aparelhos, hardware e/ou software adequados para comunicação com e/ou detectar sinais para/de um ponto de acesso Bluetooth (o AP 125 da Figura 1A, por exemplo). Além disto, ou alternativamente, o UE 1100 pode incluir um ou mais transceptores sem fio de rede de área estendida (WAN) 1114, que podem ser conectados a uma ou mais antenas 1112. Os transceptores WAN 1114b compreendem aparelhos, hardware e/ou software adequados para comunicar-se com e/ou detectar sinais para/de WAN-WAPs (pontos de acesso sem fio) e/ou diretamente com outros aparelhos sem fio dentro de uma rede (aparelhos na RAN 120 da Figura 1A, por exemplo). Sob um aspecto, os transceptores WAN 1114b podem ser adequados para comunicar-se com um sistema LTE, um sistema WCDMA, um sistema CDMA2000, TDMA, GSM ou qualquer outro tipo de tecnologia de funcionamento em rede sem fio de área estendida. Além disto, ou alternativamente, o UE 1100 pode incluir um ou mais transceptores WLAN 1114c que podem ser conectados a uma ou mais antenas 1112. Os transceptores WLAN 1114c compreendem aparelhos, hardware e/ou software adequados para comunicação com e/ou detectar sinais para/de WLAN/WAPs e/ou diretamente com outros aparelhos sem fio dentro de uma rede (um AP WiFi 125 na Figura 1A, por exemplo). Sob um aspecto, os transceptores WLAN 1114c podem compreender um sistema de comunicação WiFi (802.11x) adequado para comunicação com um ou mais pontos de acesso sem fio. Sob outros aspectos, o transceptor WLAN 1114c pode compreender outro tipo de rede de área local ou rede de área pessoal. Além disto, ou alternativamente, um UE 1100 pode incluir um receptor SPS 1114d. O receptor SPS 1114d pode ser conectado a uma ou mais antenas 1112 para receber sinais de satélite (para GPS ou algoritmo outro GNSS, por exemplo). O receptor SPS 1114d pode compreender qualquer hardware e/ou software adequado para receber e processar sinais SPS. O receptor SPS 1114d solicita informações e operações conforme apropriado dos outros sistemas e efetua os cálculos necessários para determinar a posição do aparelho móvel 1100 utilizando medições obtidas por qualquer algoritmo SPS adequado. Além disto, ou alternativamente, pode ser utilizada qualquer outro tipo de tecnologia de funcionamento de rede sem fio, como, por exemplo, a Banda Ultra-Larga, ZigBee, USB, etc.
[0225] O UE 1100 pode incluir um ou mais sensores 1120. O sensor ou sensores 1120 podem coletar dados sobre o usuário, inclusive dados sobre a posição, movimento, orientação, ambiente, atividades ou dados biométricos do usuário. Os sensores podem incluir, por exemplo, por exemplo sensores virtuais, tais como um pedômetro 1122a e, sensores físicos, tais como um acelerômetro 1122b, um giroscópio 1122c, um sensor biométrico 1120d e/ou qualquer número de sensores mistos 1122n (termômetro, barômetro, higrômetro, por exemplo).
[0226] O UE 1100 inclui um ou mais processadores 1130. Os processadores 1130 podem ser conectados aos transceptores Bluetooth 1114a, aos transceptores WAN 1114b, aos transceptores WLAN 1114c, ao receptor SPS 1114d e aparelho de origem sensor ou sensores 1120. O processador 1130 pode ser um processador de vários núcleos, e, embora mostrada como uma única unidade, pode incluir um ou mais microprocessadores, micro-controladores e/ou processadores de sinais digitais que executam funções de processamento assim como outras funcionalidades de calculo e controle.
[0227] Os processadores 1130 podem ser acessos à memória 1140, que zona dados e instruções de software para executar funcionalidade programada dentro do UE 1100. A memória 1140 pode estar a bordo dos processadores 1130 (dentro do mesmo pacote de circuitos integrados, por exemplo), e/ou a memória 1140 pode ser uma memória externa aos processadores 1130 e funcionalmente acoplada através de um barramento de dados. A memória 1140 pode incluir qualquer número de módulos de aplicativos nativos 1142a ... 1142n e vários módulos fornecidos externamente através da atualização aérea os quaisquer outros dispositivos e qualquer número de módulos de dados 1144a ... 1144n. Deve- se entender que a organização dos conteúdos de memória mostrada na Figura 11 é meramente exemplar, e, como tal, a funcionalidade dos módulos e/ou estrutura de dados pode ser combinada, separada e/ou ser estruturada de maneiras diferentes dependendo da implementação do UE 1100. A memória 1140 pode armazenar código de programa (em um ou mais dos módulos de aplicativo 1142a a 1142n, por exemplo) que pode rodar nos processadores 1130 para permitir que o UE 1100 execute algumas ou todos os diversos procedimentos e técnicas aqui descritos.
[0228] O UE 1100 pode incluir também um módulo de posicionamento 1180 configurado para executar operações do aparelho de usuário para suportar localização relacionada com SP OTT e UE, conforme aqui descrita, o módulo de posicionamento 1180 pode ser um módulo executáveis armazenado na memória 1140 e que roda nos processadores 1130 ou pode ser um componente de hardware ou firmware acoplado aos processadores 1130.
[0229] Embora os módulos mostrados na Figura 11 sejam mostrados no exemplo como estando contidos na memória 1140, deve-se reconhecer, em determinadas implementações, tais procedimentos podem ser proporcionados ou senão operacionalmente dispostos utilizando-se outros mecanismos ou mecanismos adicionais. Por exemplo, qualquer um dos módulos de aplicativo 1142a ... 1142n pode ser apresentado em firmware. Os processadores 1130 podem incluir qualquer forma de lógica adequada para executar pelo menos as técnicas aqui apresentadas. Por exemplo, os processadores 1130 podem ser operacionalmente configuráveis com base em instruções na memória 1140 para iniciar seletivamente uma ou mais rotinas que explorem dados de movimento para utilização em outras parte do UE 1100.
[0230] O UE 1100 pode incluir uma interface de usuário 1150 que proporciona quaisquer sistemas de interface adequados, tais como um microfone/alto-falante 1152, um dispositivo sensível ao toque 1153, um teclado 1154, um monitor 1156, uma câmera 1158 e sensores de proximidade 1159 que permitem interação do usuário com o UE 1100. O microfone/alto-falante 1152 provê serviços reconhecimento de voz e/ou comunicação de voz que utilizam os transceptores WAN 1114b e/ou os transceptores WLAN 1114c. O teclado 1154 compreende quaisquer botões adequados para entrada de usuário. O monitor 1156 compreende qualquer monitor adequado, tal como, por exemplo, um monitor de LCD iluminado por trás que pode incluir também um monitor com tela sensível ao toque para modos de entrada de usuário adicionais. Além do mais, qualquer funcionalidade de entrada, tal como a funcionalidade demonstrada pelo microfone/alto-falante 1152, pela câmera 1158 ou pelo teclado 1154, pode ser também considerada uma entrada de sensor análoga às entradas do sensor ou sensores 1120.
[0232] Conforme observado acima, o sensor ou sensores 1120 podem coletar dados sobre o usuário, inclusive dados sobre posição, movimento, orientação, ambiente, atividades ou dados biométricos do usuário. Os sensores podem incluir, por exemplo, um pedômetro 1122a (que pode ser um aparelho discreto ou um módulo funcional baseado em dados de outros sensores), um acelerômetro 1122b, um giroscópio 1122c, um sensor biométrico 1120d e/ou qualquer número de sensores mistos 1122. Além do mais, os transceptores Bluetooth 1114a, os transceptores 1111b, os transceptores WLAN 1114c e/ou o receptor SPS 1114d podem ser utilizados como sensores à medida que possam ser utilizados para gerar dados sobre a posição, movimento, ambiente e/ou atividades do usuário. Por conseguinte, quando a presente revelação se refere ao sensor ou sensors 1120 de maneira geral, ou a leituras de sensores ou a dados de sensor, deve ficar entendido que os transceptores Bluetooth 1114a, os transceptores WAN 1114b, os transceptores WLAN 1114c e/ou o receptor SPS 1114d podem ser considerados sensores e os dados obtidos deles podem ser considerados leituras de sensores ou dados de sensor.
[0233] Em uma modalidade, o sensor biométrico 1122d inclui um sensor para identificar o usuário. Por exemplo, o sensor biométrico 1122d pode ser um sensor para reconhecimento de voz, reconhecimento de impressões digitais, reconhecimento de impressão da palma da mão, reconhecimento de rosto ou reconhecimento de íris. O sensor biométrico 1122d pode ser um sensor dedicado especificamente recomendado para reconhecimento de voz, reconhecimento de impressões digitais, reconhecimento de impressão da palma da mão, reconhecimento de rosto e/ou reconhecimento de íris. Em outro cenário possível, o microfone/alto-falante 1152 utilizado como um sensor para reconhecimento de voz. Em outro cenário possível, o teclado 1154 é utilizado como sensor para reconhecimento de impressão digital ou reconhecimento de impressão da palma da mão. Em ainda outro cenário possível, a câmera 1158 é utilizada como sensor para reconhecimento de rosto e/ou reconhecimento de íris.
[0234] Conforme observado acima, os processadores 1130 podem ser acoplados à memória 1140, que armazena dados e instruções de software para executar funcionalidade programada dentro do UE 1100. A memória 1140 pode incluir qualquer número de módulos de aplicativo 1142a ... 1142n e qualquer número de módulos de dados 1144a ... 1144n. Em uma modalidade, um ou mais dos módulos de aplicativo 1142a... 1142n, por exemplo, um módulo de aplicativo 1142a, utilizam dados detectador reunidos a partir de um ou mais do pedômetro 1122a, do acelerômetro 1122b, do giroscópio 1122c, dos sensores biométricos 1120b e/ou dos sensores mistos 1122n. Os dados detectados podem ser armazenados em um ou mais dos módulos de dados 1144a... módulo de dados 1144n, por exemplo, módulo de dados 1144a.
[0235] Por conseguinte, uma modalidade da revelação pode incluir um UE (o UE 1100, por exemplo) que inclui a capacidade de executar as funções aqui descritas. Conforme entendido pelos versados na técnica, os diversos elementos lógicos podem ser corporificados em elementos separados, módulos de software executados em um processador ou qualquer combinação de software e hardware para obter a funcionalidade aqui revelada. Por exemplo, o processador 1130, a memória 1140, a interface de usuário 1150 e o módulo de posicionamento 1180 podem ser todos utilizados de maneira cooperante para carregar, armazenar e executar as diversas funções aqui reveladas e, portanto, a lógica para desempenhar estas funções podem ser distribuídas através de diversos elementos.Alternativamente, a funcionalidade pode ser incorporada a um componente separado. Portanto, os recursos do UE 1100 da Figura 11 devem ser considerados meramente exemplificativos, e a revelação não está limitada aos recursos ou disposição mostrados.
[0236] A comunicação sem fio entre o UE 1100 e a RAN 1120/MME 142 pode ser baseada em tecnologias diferentes, tais como LTE CDMA, WCDMA, Acesso Múltiplo por Divisão de Tempo (TDMA), Acesso Múltiplo por Divisão de Frequência (FDMA), multiplexação por divisão de frequência ortogonal (OFDM), GSM ou outros protocolos que podem ser utilizados em uma rede de comunicações sem fio ou em uma rede de comunicações de dados. Conforme discutido no que foi exposto acima e conhecido na técnica, a transmissão de voz e/ou dados pode ser feita para os UEs 1100 da RAN 120 utilizando-se diversas redes e configurações. Por conseguinte, as ilustrações aqui apresentadas não se destinam a limitar as modalidades da revelação que servem meramente para ajudar na descrição de aspectos das modalidades da revelação.
[0237] A Figura 12 mostra um aparelho de comunicação 1200 que inclui componentes estruturais para executar funcionalidade. O aparelho de comunicação 1200 pode corresponder a qualquer um dos aparelhos de comunicação acima observados, inclusive, mas não limitado a o UE 1100, qualquer componente da RAN 120 (os eNósb 122, 126, por exemplo), qualquer componente da rede básica (MME 142 ou 144), E-CSCF 172, E-GW 156, PDG 148, ELS 370/794, E- CSCF 443/543/643, LRF 448/548/648, por exemplo), quaisquer componentes acoplados à rede básica 140 e/ou à Internet 175, como, por exemplo, o servidor de localização 170, o GMLC/SLP 170, a ESInet 180, e assim por diante. Assim, o aparelho de comunicação 1200 pode corresponder a qualquer aparelho eletrônico que seja configurado para comunicar-se com (ou facilitar comunicação com) uma ou mais outras entidades através do sistema de comunicação sem fio 100A da Figura 1A ou utilizando a configuração 100B específica da Figura 1B.
[0238] Com referência à Figura 12, o aparelho de comunicação 1200 inclui um conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205. Em um exemplo, se o aparelho de comunicação 1200 corresponder a um aparelho de comunicação sem fio (como, por exemplo, o UE 1100, um dos eNBs 122-126, etc.), o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 pode incluir uma interface de comunicação sem fio (como, por exemplo, Bluetooth WiFi, 2G, CDMA, WCDMA, 3G, 4G, LTE, etc.), tal como um transceptor sem fio e hardware conexo (como, por exemplo, por exemplo, uma antena RF, um modem, um modulador e/ou demodulador, etc.). Em outro exemplo, o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 pode corresponder a uma interface de comunicação cabeada (como, por exemplo, uma conexão serial, um USB ou conexão Fireware, uma conexão de Ethernet através da qual a Internet 175 pode ser acessada, etc.). Assim, se o aparelho de comunicação 1200 corresponder a algum tipo de servidor baseado em rede (como, por exemplo, US-GW 146, o PDG 148, a MME 142/144, o E-LMC 172, o servidor de localização 170, o ELS 370/794, a E-CSCF 443/543/643, a LRF 448, 558/648. etc.), o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1305 pode corresponder a um cartão de Ethernet, em um exemplo, que conecta o servidor baseado em rede a outras entidades de comunicação por meio de um protocolo Ethernet. Em outro exemplo, o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 pode incluir hardware sensório ou de medição pelo qual o aparelho de comunicação 1200 pode monitorar seu ambiente local (como, por exemplo, um acelerômetro, um sensor de temperatura, um sensor de luz, uma antena para monitorar sinais RF locais, etc.). O conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 pode incluir também um software que, quando executado, permite que o hardware conexo do conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 execute suas funções de recepção e/ou transmissão. Entretanto, o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 não corresponde ao software sozinho, e/ou o conjunto de circuitos de transceptor configurado para receber e/ou transmitir informações 1205 conta, pelo menos em parte, com hardware estrutural para obter sua funcionalidade.
[0239] Com referência à Figura 12, o aparelho de comunicação 1200 inclui também pelo menos um processador configurado para processar informações 1210. Implementações exemplares do tipo de processamento que pode ser executado pelo menos um processador configurado para processar informações 1210 inclui, mas não se limitam a, efetuar determinações, estabelecer conexões, fazer seleções entre opções de informações diferentes, efetuar avaliações relacionadas com dados, interagir com sensores acoplados ao aparelho de comunicação 1200 para executar operações de medições, converter informações de um formato em outro (como, por exemplo, entre protocolos diferentes tais 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 de propósito geral, um DSP, um ASIC, um arranjo de portas programável no campo (FPGA) ou outro aparelho lógico programável, porta discreta ou lógica de transistor, componentes de hardware discretos ou qualquer combinação deles projetada para executar as funções aqui descritas. Um processador de propósito geral pode ser um microprocessador, mas, alternativamente o pelo menos um processador configurado para processar informações 310 pode ser qualquer processador, controlador, micro- controlador ou máquina de estados convencional. Um processador pode ser também implementado como uma combinação de aparelhos de computação (uma combinação de DSP e microprocessador, uma série de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo de DSP ou qualquer outra configuração que tal, por exemplo). O pelo menos um processador configurado para processar informações 1210 pode incluir também um software que, quando executado, permite que o hardware conexo no pelo menos um processador configurado para processar informações 1210 execute suas funções de processamento. Entretanto, o pelo menos um processador configurado para processar informações 1210 não corresponde ao software sozinho, e o pelo menos um processador configurado para processar informações 1210 conta, pelo menos em parte, com hardware estrutural para obter sua funcionalidade.
[0240] Com referência à Figura 12, o aparelho de comunicação 1200 inclui também 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 de hardware conexo (como, 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 a uma RAM, memória flash, memória exclusiva de leitura (ROM), ROM programável apagável (EPROM), ROM programável eletricamente programável (EEPROM), registradores, disco rígido, um disco removível, um CD-ROM ou qualquer outra forma de meio de armazenamento conhecida na técnica. A memória configurada para armazenar informações 1215 pode incluir também um software que, quando executado, permite que o hardware conexo da memória configurada para armazenar informações 1215 execute suas funções de armazenamento. Entretanto, a memória configurada para armazenar informações 1215 não corresponde a um software sozinho, e a memória configurada para armazenar informações 1215 conta, pelo menos em parte com hardware estrutural para obter suas funcionalidade.
[0241] Com referência à Figura 12, o aparelho de comunicação 1200 inclui também 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 aparelho de saída de hardware conexo. Por exemplo, o aparelho de saída pode incluir um aparelho de saída de vídeo (como, por exemplo, uma tela de exibição, uma porta que pode portar informações de vídeo, tal como USB, HDMI, etc.), um aparelho de saída de áudio (como, por exemplo, alto-falantes, uma porta que pode portar informações de áudio, tal como uma tomada de microfone, USB, HDMI, etc.), um aparelho de vibração ou qualquer outro aparelho pelo qual informações possam ser formatadas para saída ou realmente transmitidas pelo usuário ou operador do aparelho de comunicação 1200. Se o aparelho de comunicação 1200 corresponder ao UE 1100 conforme mostrado na Figura 11, o conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 pode incluir um monitor 1056 e/ou o alto-falante 1052. Em outro exemplo, o conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 pode ser omitido para determinados aparelhos de comunicação, tais como aparelhos de comunicação de rede que não têm um usuário local (como, por exemplo, comutadores ou roteadores de rede, servidores remotos, etc.). O conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 pode incluir também um software que, quando executado, permite que o hardware conexo do conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 execute suas 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 a um software sozinho, e o conjunto de circuitos de saída de interface de usuário configurado para apresentar informações 1220 conta, pelo menos em parte, com hardware estrutural para obter sua funcionalidade.
[0242] Com referência à Figura 12, o aparelho de comunicação 1200 inclui também opcionalmente um conjunto de circuitos de saída de interface de usuário configurado para receber entrada de usuário local 1225. Em um exemplo o conjunto de circuitos de saída de interface de usuário configurado para receber entrada de usuário local 325 pode incluir pelo menos um aparelho de entrada de usuário e hardware conexão. Por exemplo, o aparelho de entrada de usuário, pode incluir botões, um monitor com tela sensível ao toque, um teclado, uma câmera, um aparelho de entrada de áudio (como, por exemplo, um microfone ou uma porta que possa portar informações de áudio, tal como uma tomada de microfone, etc.), e/ou qualquer outro aparelho pelo qual informações possam ser recebidas do usuário ou operador do aparelho de comunicação 1200. Se o aparelho de comunicação 1200 corresponder ao UE 1100 mostrado na Figura 11, o conjunto de circuitos de saída de interface de usuário configurado para receber entrada de usuário local 1225 pode incluir o dispositivo sensível ao toque 1153, o teclado 1154, o microfone 1152, etc. Em outro exemplo, o conjunto de circuitos de saída de interface de usuário configurado para receber entrada de usuário local 1225 pode ser omitido para determinados aparelhos de comunicação, tais como, aparelhos de comunicação em rede que não têm um usuário local (como, por exemplo, comutadores ou roteadores de rede, servidores remotos, etc.). O conjunto de circuitos de saída de interface de usuário configurado para receber entrada de usuário local 1225 pode incluir também um software que, quando executado, permite que o hardware conexo do conjunto de circuitos de saída de interface de usuário configurado para receber entrada de usuário local 1225 execute suas funções de recepção de entrada. Entretanto, o conjunto de circuitos de saída de interface de usuário configurado para receber entrada de usuário local 1225 não corresponde a um software sozinho. E o conjunto de circuitos de saída de interface de usuário configurado para receber entrada de usuário local 1225, conta, pelo menos em parte, com hardware estrutural para obter sua funcionalidade.
[0243] Com referência à Figura 12, embora os componentes configurados 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 conexo 1230, deve ficar entendido que o hardware e/ou o software pelos quais os respectivos componentes estruturais configurados de 1205 a 1225 executam sua respectiva funcionalidade pode superpor-se em parte. Por exemplo, qualquer software utilizado para facilitar a funcionalidade dos componentes estruturais configurados de 1205 a 1225 pode ser armazenado na memória não transitória associada à memória configurada para armazenar informações 1215, de modo que os componentes estruturas configurados de 1205 a 1225 executem, cada um, sua respectiva funcionalidade (isto é, neste caso, execução de software) com base, em parte, no funcionamento do software armazenado pela memória configurada para armazenar informações 1215. Da mesma maneira, o hardware que está diretamente associado a um dos componentes estruturais configurados 1205 a 1225 pode ser tomado emprestado ou utilizado por outros componentes estruturais configurados de 1205 a 1225 ocasionalmente. 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 informações 1205 . De modo que o conjunto de circuitos de transceptor configurado para receber e transmitir 1205 execute sua funcionalidade (isto é, neste caso, transmissão de dados, com base, em parte, no funcionamento de hardware estrutural associado ao pelo menos um processador configurado para processar informações 1210.
[0244] Por conseguinte, nos diversos componentes estruturais de 1205 a 1225 se destinam a chamar um aspecto que é pelo menos em parte implementado com hardware estrutural, e não são destinados a mapear em implementações exclusivas de software que são independentes de hardware e/ou em interpretações funcionais não estruturais. Outras interações ou cooperações entre os componentes estruturais entre 1205 a 1225 se tornarão claras aos versados na técnica a partir de um exame dos aspectos descritos em seguida mais detalhadamente.
[0245] As diversas modalidades podem ser implementadas em qualquer um de diversos aparelhos de servidor comercialmente disponíveis, tais como o servidor 1300 mostrado na Figura 13. Em um exemplo, os servidor 1300 pode corresponder a uma configuração exemplar da MME 142, do SP OTT 150/350/450/550/650/750/850/950, da ESInet 160, do E-SMLC 172, do servidor de localização/GMLC/SLP 170, do ELS 370/794, da E-CSCF 443/543/653, da LRF 448/548/648 e do PSAP 180 descritos acima. Na Figura 13, o servidor 1300 inclui um processador 1301 acoplado à memória volátil 1302 e a uma memória não volátil de grande capacidade, tal como uma unidade de disco 1303. O servidor 1300 pode incluir também uma unidade de disco flexível, uma unidade de disco compacto (CD) ou de disco DVD 1306 acoplada ao processador 1301. O servidor 1300 pode incluir também portas de acesso de rede 1304 acopladas ao processador 1301 para estabelecer conexões de dados com uma rede 1307, tal como uma rede de área local acoplada a outros computadores e servidores de sistema de broadcast ou à Internet. No contexto da Figura 12, deve ficar entendido que o servidor 1300 da Figura 13 mostra uma implementação exemplar do aparelho de comunicação 1200, pelo que a lógica configurada para transmitir e/ou receber informações 1205 corresponde às portas de acesso a rede 1304 utilizadas pelo servidor 1300 para comunicar-se com a rede 1307, a lógica, configurada para processar informações 1210 corresponde ao processador 1301 e a lógica configurada para armazenar informações 1215 corresponde a qualquer combinação da memória volátil 1302, da unidade de disco 1303 ou da 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 nela. Assim, a Figura 13 ajuda a demonstrar que o aparelho de comunicação 1200 pode ser implementado como um servidor, além de uma implementação de UE como na Figura 11. Por conseguinte, uma modalidade da revelação pode incluir um servidor (o servidor 1300, por exemplo) que inclui a capacidade de executar as funções aqui descritas, tais como as funções descritas com referência à MME 142, ao SP OTT 150, à ESInet 160, ao E-SMLC 172, ao servidor de localização/GLMC/SLP 170, ao ELS 370/794, à E-CSCF 443/543/643 à RLF 448/548/648 e ao PSAP 180, por exemplo.
[0246] A Figura 14 mostra um fluxo exemplar para localizar um UE executado por um nó de rede de acesso que serve o UE, tal 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.
[0247] Em 1410, o nó de rede de acesso recebe uma primeira mensagem do UE, tal como em 206A da Figura 2A ou 202B da Figura 2B. Por exemplo, no caso de o nó de rede de acesso corresponder a uma MME que suporta LTE, a primeira mensagem pode ser uma Solicitação de Anexação NAS ou uma Solicitação de Atualização de Área de Rastreamento NAS. No caso de a rede de acesso corresponder a um GSN que suporta o MTS, a primeira mensagem pode ser a Solicitação de Anexação GPRS ou uma Solicitação de Atualização de Área de Roteamento GPRS.
[0248] 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, tal como o servidor de localização 170 na Figura 1A ou o GMLS/SLP 170 da Figura 1B, pertencente a uma operadora 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 IP, um IMSI, um TMSI, um endereço do nó de rede de acesso ou qualquer combinação deles. A referência de UE pode ser também cifrada.
[0249] Conforme descrito acima com referência a 208A da Figura 2A ou a 204B da Figura 2B determinar em 1420 pode incluir enviar uma solicitação da referência de localização para o UE do servidor de localização e receber para o UE 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 UE propriamente dito. Nesse caso, o nó de rede de acesso pode assinar digitalmente a referência a referência de localização para o UE de modo a indicar que a referência de localização para o UE foi gerada pelo nó de rede de acesso para o operador.
[0250] Em 1430, o nó de rede de acesso envia uma segunda mensagem ao UE, tal como em 212A da Figura 2A ou 206B da Figura 2B. A segunda mensagem pode incluir a referência de localização. No caso de o nó de rede de acesso corresponder a uma MME que suporta LTE, a segunda mensagem pode ser uma Aceitação de Anexação NAS ou uma Aceitação de Atualização de Área de Rastreamento NAS. No caso de o nó de rede de acesso corresponder a um GSN que suporta o MTS, a segunda mensagem pode ser uma Aceitação de Anexação GPRS ou uma Aceitação de Atualização de Área de Roteamento GPRS.
[0251] 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, tal como o SP OTT 150. 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 diferente da rede de acesso do nó de rede de acesso. O SP OTT pode obter a localização do UE do servidor de localização com base na referência de localização.
[0252] Embora não mostrado, o fluxo mostrado na Figura 14 pode incluir também autenticar o UE antes do envio da segunda mensagem. Além disto, o fluxo mostrado na Figura 14 pode incluir também determinar periodicamente uma nova referência de localização para o UE enquanto o UE está anexado ao nó de rede de acesso e enviar a nova referência de localização ao UE.
[0253] A Figura 15 mostra um fluxo exemplar para localizar um UE executado em um servidor de localização, tal como o servidor de localização 170 da Figura 1A ou o GMLC/SLP 170 da Figura 1B.
[0254] Em 1510, o servidor de localização recebe uma solicitação de referência de localização para o UE de um nó de rede de acesso que serve o UE, tal como em 208A da Figura 2A ou 204B da Figura 2B.
[0255] Em 1520, o servidor de localização envia a referência de localização para o UE ao nó de rede de acesso tal 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.
[0256] Em 1530, o servidor de localização recebe uma solicitação de localização da localização do UE de uma entidade de rede que não o nó de acesso de rede, tal 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 pertencente a um SP OTT, um provedor de ESInet ou um PSAP, por exemplo.
[0257] Em 1240, o servidor de localização pode determinar uma estimativa de localização para o UE, tal como em 218A da Figura 2A ou 216B-226B ou 228B da Figura 2B. No caso de 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. No caso de 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 utilizando- se uma solução de localização no plano de controle. Neste caso, determinar a estimativa de localização utilizando-se a solução de localização no plano de controle pode incluir enviar uma solução de localização ao nó de rede de acesso e receber do nó de rede de acesso uma resposta de localização que contém a estimativa de localização, como em 218A da Figura 2A ou 216B-226B da Figura 2B.
[0258] Em 1550, o servidor de localização envia a estimativa de localização para o UE à entidade de rede, tal como em 224A da Figura 2A ou 232B da Figura 2B.
[0259] 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 chamadas de serviços de emergência ao SP OTT por meio de uma rede de acesso para uma operadora diferente da operadora para o servidor de localização.
[0260] A Figura 16 mostra um fluxo exemplar para localizar um UE executado em um servidor de localização tal como o servidor de localização 170 da Figura 1A ou o GMLC/SLP 170 da Figura 1B.
[0261] Em 1610, o servidor de localização recebe uma solicitação de localização da localização do UE de uma entidade de rede que não um nó de rede de acesso que serve o UE, tal 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 IP, um IMSI, um TMSI, um endereço do nó de rede de acesso ou qualquer combinação deles, a outra entidade de rede pode ser uma entidade de rede pertencente a um SP OTT, o provedor de ESInet ou um PSAP por exemplo.
[0262] 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, e neste caso autenticar a referência de localização pode incluir autenticar a assinatura digitalmente.
[0263] 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, tal como em 218A da Figura 2A ou 216B-226B da Figura 2B ou 228B da Figura 2B. Em uma modalidade, a referência de UE pode ser cifrada, e neste caso determinar uma estimativa de localização para o UE pode incluir decifrar a referência de UE cifrada. No caso de o servidor de localização responder a um SLP, determinar a estimativa de localização para o UE pode incluir estabelecer uma sessão de SUPL com o UE. No caso de 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 utilizando- se uma solução de localização no plano de controle. Nesse caso, determinar a estimativa de localização utilizando-se a solicitação de localização no plano de controle pode incluir enviar uma solicitação de localização ao nó de rede de acesso e receber do nó de rede de acesso uma resposta de localização que contém a estimativa de localização, como em 218A da Figura 2A ou 216B-226B da Figura 2B.
[0264] Em 1640, o servidor de localização envia a estimativa de localização para o UE à outra entidade de rede, tal como em 224A da Figura 2A ou 232B da Figura 2B.
[0265] 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, tal como o SP OTT 150.
[0266] A Figura 17 mostra um fluxo exemplar para localizar um UE que faz uma chamada efetuada pelo UE, tal como o UE 1100. A chamada pode ser uma chamada de emergência.
[0267] Em 1710, o UE envia uma primeira mensagem ao nó de rede de acesso que serve o UE. No caso de o nó de rede de acesso corresponder a uma MME que suporta LTE, a primeira mensagem pode ser uma Solicitação de Anexação NAS ou uma Solicitação de Atualização de Ares de Rastreamento NAS. No caso de o nó de rede de acesso corresponder a um SGSN que suporta UMTS, a primeira mensagem pode ser uma Solicitação de Anexação GPRS ou uma Solicitação de Área de Roteamento GPRS.
[0268] Em 1720, o UE recebe do nó de rede de acesso uma segunda mensagem 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, tal como o servidor de localização 170 da Figura 1A ou GMLC/SLP 170 da Figura 1B, pertencente à operadora do nó de rede de acesso e pode permitir a localização do UE 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. No caso de o nó de rede de acesso corresponder a uma MME que suporta LTE, a primeira mensagem pode ser uma ou uma Solicitação de Atualização de Área de Rastreamento NAS. No caso de o nó de rede de acesso corresponder a um SGSM que suporta UMTS, a primeira mensagem pode ser uma Solicitação de Anexação GPRS ou uma Solicitação de Atualização de Área de Roteamento GPRS. Embora não mostrado na Figura 17, o fluxo pode incluir também autenticar o UE para o nó de rede de acesso antes do recebimento da segunda mensagem.
[0269] Em 1730, o UE recebe uma solicitação da chamada de um usuário do UE.
[0270] Em 1740, o UE envia uma solicitação da chamada a um SP OTT, tal como o SP OTT 150 . A solicitação da 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.
[0271] Embora não mostrado na Figura 17, o fluxo pode incluir também receber periodicamente uma nova referência de localização para o UE do nó de rede de acesso enquanto o UE está anexado ao nó de rede de acesso.
[0272] A Figura 18 mostra uma fluxo exemplar para suportar chamadas de emergência em um provedor de serviços OTT, tal como o SP OTT 150. Em uma modalidade, o fluxo mostrado na Figura 18 pode ser executado pelo, ou levado a ser executado pelo módulo de posicionamento 1058.
[0273] Em 1810, o SP OTT 150 recebe uma primeira mensagem que compreende uma solicitação de chamada de emergência de um UE, tal 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 uma MNO servidora para o UE, tal como a MNO servidora 790, 890 ou 990. A primeira mensagem inclui o endereço de um IMS (tal como o IMS 894 ou 994, para a MNO servidora).
[0274] Em 820, o SP OTT 150 envia uma segunda mensagem ao IMS com base no endereço, como em 808 e 908. A segunda mensagem pode ser uma solicitação da chamada de emergência. A primeira mensagem, a segunda mensagem ou ambas as mensagens podem ser um CONVITE SIP.
[0275] Embora não mostrado na Figura 18, o fluxo pode incluir também receber do IMS uma terceira mensagem que compreende informações de roteamento para um PSAP de destino, como em 812, e enviar uma quarta mensagem ao ou na direção do PSAP com base nas informações de roteamento. A terceira mensagem pode ser uma mensagem de 300 Múltiplas Escolhas SIP, e a quarta mensagem pode ser uma solicitação da chamada de emergência. O endereço para o IMS pode ser para uma RLF. As informações de roteamento podem incluir um ID de referência, e neste caso o fluxo pode incluir também incluir o ID de referência na quarta mensagem, onde o ID de referência permite que o PSAP obtenha da RLF uma localização para o UE.
[0276] O IMS pode enviar uma quinta mensagem a ou na direção de um PSAP de destino, onde 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 uma E-CSCF. O IMS inclui um identificador de referência na quinta mensagem, onde o identificador de referência permite que o PSAP obtenha do IMS uma localização para o UE.
[0277] A Figura 19 mostra um DRX exemplar para suportar chamadas de emergência em uma entidade de IMS, tal como o IMS 894 ou 994 para uma MNO servidora, tal como a MNO servidora 890 ou 990. Sob um aspecto, a entidade de IMS pode ser uma LRF. Em uma modalidade, o fluxo mostrado na Figura 19 pode ser executado pelo, ou levado a ser executado pelo, módulo de posicionamento 1058.
[0278] Em 1210, a entidade de IMS recebe uma primeira mensagem enviada por um provedor de serviços OTT, tal como o SP OTT 150, como em 808 e 908, a primeira mensagem compreendendo 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 SIP.
[0279] Em 1220, a entidade de IMS determina informações de roteamento para um PSAP de destino com base nos dados de MNO, como em 911.
[0280] Embora não mostrado na Figura 19, em uma modalidade, o fluxo pode incluir também enviar para o provedor de serviços OTT uma segunda mensagem que compreende as informações de roteamento, onde as informações de roteamento permitem que o provedor de serviços OTT roteie a chamada de emergência para o ou na direção do PSAP de destino. Nesse caso, as informações de roteamento podem ser um ID de referência e o endereço ou identidade ou do PSAP ou de um destino intermediário. A segunda mensagem pode ser uma mensagem de Múltiplas Escolhas SIP.
[0281] Em uma modalidade, o fluxo pode incluir também receber uma terceira mensagem que compreende um ID de referência de outra entidade, identificar o UE com base no ID de referência, obter a localização para o UE e enviar uma quarta mensagem à outra entidade que compreende a localização. O ID de referência pode ser um ESRK, um ESRD, mas um MSISDN ou um URI de localização. A localização do UE pode ser obtida utilizando-se uma solução de localização no plano de controle ou uma solução de localização no plano do usuário. Sob um aspecto, a outra entidade pode ser o PSAP, uma ALI ou uma ESInet.
[0282] Em uma modalidade, o fluxo pode incluir também enviar uma mensagem ao ou na direção do PSAP com base nas informações de roteamento onde a segunda mensagem compreende uma solicitação da chamada de emergência. Neste caso, a entidade de IMS pode ser uma CSCF de emergência.
[0283] A Figura 20 mostra um fluxo exemplar para suportar chamadas de emergência em um UE, tal como qualquer um dos UEs 200, 300, 400, 500, 600, 700, 800, 900, 1002 e 1100. Em uma modalidade, o fluxo mostrado na Figura 20 pode ser executada pelo ou levado a ser executado pelo módulo de posicionamento 1054.
[0284] Em 2010, o UE recebe uma solicitação da chamada de emergência do usuário do UE.
[0285] Em 2020, o UE obtém dados de MNO para uma MNO servidora para o UE, como em 802/804 e 902/904.
[0286] Em 2030, o UE envia uma primeira mensagem que compreende uma solicitação da chamada de emergência a um provedor de serviços OTT, tal como o SP OTT 150 como em 806 e 906. A solicitação da chamada de emergência inclui os dados de MNO. Os dados de MNO podem incluir um endereço para um IMS para a MNO servidora, uma identidade para uma entidade de gerenciamento de mobilidade servidora atual ou SGSM para o UE, um endereço IP atribuído pela MNO servidora para o UE, uma identidade global ou identidade local para o UE ou alguma combinação deles.
[0287] O provedor de serviços OTT envia uma segunda mensagem ao IMS com base no endereço para o IMS, onde a segunda mensagem compreende uma solicitação da 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. Nesta modalidade, o fluxo inclui também receber uma solicitação de estimativa de localização ou de medições de localização de acordo com uma solução de localização no plano do usuário ou uma solução de localização no plano de controle, onde a estimativa de localização de localização ou as medições de localização permitem que 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.
[0288] O IMS pode enviar ao provedor de serviços OTT uma terceira mensagem que compreende as informações de roteamento. O provedor de serviços OTT envia uma quarta mensagem a ou na direção de um PSAP de destino onde o PSAP é determinado com base nas informações de roteamento. Neste caso, o endereço para o IMS é um endereço para uma RLF.
[0289] O IMS pode enviar uma quinta mensagem a ou na direção de um PSAP de destino, onde a quinta mensagem compreende uma solicitação da chamada de emergência e onde o PSAP é determinado com base nas informações de roteamento. O endereço para o IMS pode ser um endereço para uma E-CSCF.
[0290] A Figura 21 mostra um equipamento de nó de rede de acesso 2100 exemplar representado como uma série de módulos funcionais inter-relacionados. Um módulo para receber 2110 pode corresponder, pelo menos sob alguns aspectos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1014 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1034, opcionalmente em conjunto o módulo de posicionamento 1056, conforme aqui discutido. Um módulo para determinar 2120 pode corresponder, pelo menos sob alguns aspectos, a um sistema de processamento, tal como o sistema de processamento 1034 opcionalmente em conjunto com o módulo de posicionamento 1056, conforme aqui discutido. Um módulo para enviar 2130 pode corresponde, pelo menos sob alguns aspectos, a um aparelho de comunicação, tal como o aparelho de comunicação 1014 da Figura 10 ou a um sistema d processamento, tal como o sistema de processamento 1034, opcionalmente, em conjunto com o módulo de posicionamento 1056, conforme aqui discutido.
[0291] A Figura 22 mostra um equipamento de servidor de localização 2200 exemplar representado como uma série de módulos funcionais inter-relacionados. O módulo para receber 2210 pode corresponder pelo menos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1026 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido. Um módulo para enviar 2220 pode corresponder, pelo menos sob alguns aspectos a, por exemplo, um aparelho de comunicação tal como o aparelho comunicação 1026 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido. O módulo para receber 2230 pode corresponder sob alguns aspectos pelo menos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1026 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido. Um módulo para determinar 2240 pode corresponder, pelo menos sob alguns aspectos a, por exemplo, um sistema de processamento tal como o sistema de processamento 1036 opcionalmente em conjunto opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido. Um módulo para enviar 2250 pode corresponder sob alguns aspectos pelo menos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1026 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido.
[0292] A Figura 23 mostra um equipamento de servidor de localização 2300 exemplar representado como uma série de módulos funcionais inter-relacionados. O módulo para receber 2310 pode corresponder sob alguns aspectos pelo menos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1026 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido. Um módulo para autenticar 2320 pode corresponder, pelo menos sob alguns aspectos a, por exemplo, um sistema de processamento tal como o sistema de processamento 1036 opcionalmente em conjunto em conjunto com o módulo de posicionamento 1058, conforme aqui discutido. O módulo para determinar 2330 pode corresponder pelo menos sob alguns aspectos a, por exemplo, um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido. Um módulo para enviar 2340 pode corresponder, pelo menos sob alguns aspectos a, por exemplo, um aparelho de comunicação tal como o aparelho de comunicação 1026 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido.
[0293] A Figura 24 mostra um equipamento de equipamento de usuário 2400 exemplar representado como uma série de módulos funcionais inter-relacionados. O módulo para enviar 2410 pode corresponder sob pelo menos alguns aspectos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1006 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme aqui discutido. Um módulo para receber 2420 pode corresponder, pelo menos sob alguns aspectos a, por exemplo, um aparelho de comunicação tal como o aparelho de comunicação 1008 da Figura 10 ou a um sistema de processamento, tal como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme aqui discutido. O módulo para enviar 2440 pode corresponder pelo menos sob alguns aspectos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1008 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme aqui discutido.
[0294] A Figura 25 mostra um equipamento de provedor de serviços OTT 2500 exemplar representado como uma série de módulos funcionais inter-relacionados. O módulo para enviar 2510 pode corresponder sob pelo menos alguns aspectos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1026 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido. Um módulo para enviar 2520 pode corresponder, pelo menos sob alguns aspectos a, por exemplo, um aparelho de comunicação tal como o aparelho de comunicação 1026 da Figura 10 ou a um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido.
[0295] A Figura 26 mostra um equipamento de entidade de IMS 2600 exemplar representado como uma série de módulos funcionais inter-relacionados. O módulo para receber 2610 pode corresponder sob pelo menos alguns aspectos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1026 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido. Um módulo para determinar 2620 pode corresponder, pelo menos sob alguns aspectos a, por exemplo, um sistema de processamento tal como o sistema de processamento 1036, opcionalmente em conjunto com o módulo de posicionamento 1058, conforme aqui discutido.
[0296] A Figura 27 mostra um equipamento de equipamento usuário 2700 exemplar representado como uma série de módulos funcionais inter-relacionados. O módulo para receber 2710 pode corresponder sob pelo menos alguns aspectos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1008 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme aqui discutido. Um módulo para obter 2720 pode corresponder, pelo menos sob alguns aspectos a, por exemplo, um aparelho de comunicação tal como o aparelho de comunicação 1008 da Figura 10 ou a um sistema de processamento, tal como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme aqui discutido. O módulo para enviar 2730 pode corresponder pelo menos sob alguns aspectos a, por exemplo, um aparelho de comunicação, tal como o aparelho de comunicação 1008 da Figura 10, ou a um sistema de processamento, tal como o sistema de processamento 1032, opcionalmente em conjunto com o módulo de posicionamento 1054, conforme aqui discutido.
[0297] A funcionalidade dos módulos das Figuras 21-27 pode ser implementada de diversas maneiras compatíveis com os presentes ensinamentos. Em alguns desenhos, a funcionalidade destes módulos pode ser implementada como um ou mais componentes elétricos. Em alguns desenhos, a funcionalidade destes blocos pode ser implementada como um sistema de processamento que inclui um ou mais componente de processador. Em alguns desenhos a funcionalidade destes módulos pode ser implementada utilizando-se por exemplo, pelo menos uma parte de um ou mais circuitos integrados (um ASIC, por exemplo). Conforme aqui discutido, um circuito integrado pode incluir um processador, software, outros componentes conexos ou alguma combinação deles. Assim, a funcionalidade de módulos diferentes pode ser implementada, por exemplo, como subconjuntos diferentes de um circuito integrado.
[0298] Além disso, os componentes e funções representados pelas Figuras 21-27, assim como outros componentes e funções aqui descritos, podem ser implementados utilizando-se quaisquer dispositivos adequados. Tais dispositivos podem ser também implementados, pelo menos em parte, utilizando-se estrutura correspondente, conforme aqui ensinado. Por exemplo, os componentes descritos acima em conjunto com os componentes de “módulo para” das Figuras 21-27 podem também corresponder à funcionalidade de “dispositivo para” designada de maneira semelhante. Assim, sob alguns aspectos, um ou mais de tais dispositivos podem ser implementados utilizando-se um ou mais de componente de processador, circuitos integrados ou outra estrutura adequada aqui ensinada.
[0299] Os versados na técnica entenderão que os diversos blocos, módulos, circuitos e etapas de algoritmos lógicos ilustrativos descritos em conexão com as modalidades aqui reveladas podem ser implementados como hardware eletrônico, software de computador ou em combinações de ambos. Para ilustrar claramente esta intercambialidade de hardware e software, foram descritos acima diversos componentes, módulos, circuitos e etapas ilustrativos geralmente em termos da sua funcionalidade. Se tal funcionalidade é implementada como hardware ou software depende da aplicação específica e das restrições de desenho impostas ao sistema como um todo. Os versados na técnica podem implementar a funcionalidade descrita de maneiras variáveis para cada aplicação específica, mas tais decisões de implementação não devem ser interpretadas como provocando um afastamento do alcance da presente revelação.
[0301] Os diversos blocos, módulos e circuitos lógicos ilustrativos descritos em conexão com as modalidades aqui reveladas, podem ser implementados ou executados com um processador de propósito geral, um processador de sinais digitais (DSP), um circuito integrado específico de aplicativo (ASIC), um arranjo de portas programável no campo (FPGA) ou outro aparelho lógico programável (PLD), porta discreta ou lógica de transistor, componentes de hardware discretos ou qualquer combinação deles projetada para desempenhar as funções aqui descritas. Um processador de propósito geral pode ser um microprocessador, mas alternativamente, o processador pode ser qualquer processador, controlador, micro-controlador ou máquina de estado convencional. Um processador pode ser também implementado como uma combinação de aparelhos de computação, como, por exemplo, uma combinação de DSP e microprocessador, uma série de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo de DSP ou qualquer outra configuração que tal.
[0302] Os métodos, sequência e ou algoritmos descritos em conexão com as modalidades aqui reveladas podem ser corporificados 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 em uma memória RAM, memória flash, memória ROM, memória EPROM, EEPROM, em registradores, disco rígido, disco removível, CD-ROM ou qualquer outra forma de meio de armazenamento conhecida na técnica. Um meio de armazenamento exemplar é acoplado ao processador de modo que o processador possa ler informações do, e gravar informações no, meio de armazenamento. Alternativamente, o meio de armazenamento pode ser integrante com o processador. O processador e o meio de armazenamento podem residir em um ASIC. O ASIC pode residir em um terminal de usuário (UE, por exemplo). Alternativamente, o processador e o meio de armazenamento podem residir como componentes separados em um terminal de usuário.
[0303] Em uma ou mais modalidades exemplares, as funções descritas podem ser implementadas em software, hardware, firmware ou qualquer combinação deles. Se implementadas em software, as funções podem ser armazenadas ou transmitidas como um ou mais instruções ou código em um meio passível de leitura por computador. Os meios passíveis de leitura por computador incluem tantos meios de armazenamento em computador quanto meios de comunicação que incluem qualquer meio que facilite a transferência de um programa de computador de um lugar para outro. Um meio de armazenamento pode ser qualquer meio disponível que possa ser acessado por um computador. A título de exemplo e não de limitação, tais meios passíveis de leitura por computador podem compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco ótico, em disco magnético ou outros aparelhos de armazenamento magnético ou qualquer outro meio que possa ser utilizado para portar ou armazenar código de programa desejado sob a forma de instruções ou estruturas de dados e que possa ser acessado por um computador. Além disto, qualquer conexão é apropriadamente denominada de meio passível de leitura por computador. Por exemplo, se o software for transmitido de um site da Web, servidor ou outra fonte remota utilizando-se um cabo coaxial, cabo de fibra ótica, par trançado, linha de assinante digital (DSL) ou tecnologias sem fio, tais como infra-vermelho (IR), rádio e microonda, então o cabo coaxial, o cabo de fibra ótica, o par trançado, a DSL ou tecnologias sem fio tais como infravermelho, rádio e microonda são incluídos na definição de meio. Disco, conforme aqui utilizado, inclui disco compacto (CD), disco de laser, disco ótico, disco versátil digital (DVD), disco flexível e disco Blu-ray onde discos (disks) reproduzem usualmente dados magneticamente, enquanto discos (discs) reproduzem dados oticamente com lasers. Combinações dos elementos acima devem ser também incluídas dentro do alcance dos meios passíveis de leitura por computador.
[0304] Embora a revelação precedente mostre modalidades ilustrativas da revelação, deve-se observar que várias alterações e modificações podem ser feitas nelas sem que se abandone o alcance da revelação conforme definido pelas reivindicações anexas. As funções, etapas e/ou alocações das reivindicações de método de acordo com as modalidades da revelação aqui descritas não precisam ser executadas em qualquer ordem específica. Além disto, embora elementos da revelação possam ser descritos ou reivindicado no singular, o plural é contemplado a menos que a limitação ao singular seja afirmada explicitamente.
Claims (15)
1. Método para suportar chamadas de emergência em um provedor de serviços over-the-top (850), OTT, caracterizado pelo fato de que compreende: receber (1810) uma primeira mensagem (214A, 806) que compreende uma solicitação de chamada de emergência a partir de um equipamento de usuário (800), UE, em que a primeira mensagem é transferida para o provedor de serviços OTT por meio de uma operadora de rede móvel (890), MNO, servidora para o UE, e em que a primeira mensagem inclui um endereço para um Subsistema Multimídia de Protocolo de Internet (894), IP IMS, para a MNO servidora; e enviar (1820) uma segunda mensagem (808) ao IMS com base no endereço, em que a segunda mensagem compreende uma solicitação para uma chamada de emergência.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a primeira mensagem, a segunda mensagem, ou ambas as mensagens compreendem uma mensagem de Convite de Protocolo de Início de Sessão (808), SIP.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: receber uma terceira mensagem (812) a partir do IMS (894) que compreende informações de roteamento para um Ponto de Resposta de Segurança Pública (880), PSAP, de destino; e enviar uma quarta mensagem para ou na direção do PSAP com base nas informações de roteamento, em que a quarta mensagem compreende uma solicitação para uma chamada de emergência.
4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que a terceira mensagem compreende uma mensagem de 300 Múltiplas Escolhas de Protocolo de Início de Sessão, SIP; e/ou em que o endereço para o IMS (894) é para uma Função de Recuperação de Localização, RLF; em que as informações de roteamento incluem um identificador, ID, de referência, e em que o método compreende adicionalmente: incluir o ID de referência na quarta mensagem, em que o ID de referência permite que o PSAP obtenha uma localização para o UE (800) a partir da RLF.
5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o IMS (894) envia uma quinta mensagem para ou na direção de um PSAP de destino, em que a quinta mensagem compreende uma solicitação de chamada de emergência para o UE (800); em que o endereço para o IMS (894) é para uma Função de Controle de Sessão de Chamada de Emergência, E- CSCF; e/ou em que o IMS (894) 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 (800) a partir do IMS.
6. Método para suportar chamadas de emergência em uma entidade de Subsistema Multimídia de IP (894), IMS, para uma operadora de rede móvel (890), MNO, servidora, caracterizado pelo fato de que compreende: receber (1910) uma primeira mensagem (808) enviada por um provedor de serviços over-the-top (850), OTT, que compreende uma solicitação de chamada de emergência para um equipamento de usuário (800), UE, em que a solicitação de chamada de emergência inclui dados de MNO para o UE; e determinar (1920) informações de roteamento para um Ponto de Resposta de Segurança Pública (880), PSAP, de destino com base nos dados de MNO.
7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende adicionalmente: enviar uma segunda mensagem (812) ao provedor de serviços OTT (850) que compreende as informações de roteamento, em que as informações de roteamento permitem que o provedor de serviços OTT roteie a chamada de emergência para ou na direção do PSAP (880) de destino; em que a segunda mensagem (812) compreende uma mensagem de 300 Múltiplas Escolhas de Protocolo de Início de Sessão, SIP; e/ou em que a entidade de IMS é uma Função de Recuperação de Localização, RLF; e/ou em que as informações de roteamento compreendem um identificador, ID, de referência e o endereço ou identidade do PSAP (880) ou de um destino intermediário, e, neste caso, o método compreendendo adicionalmente: receber uma terceira mensagem que compreende o ID de referência a partir de outra entidade; identificar o UE com base no ID de referência; obter uma localização para o UE; e enviar uma quarta mensagem à outra entidade que compreende a localização, em que o ID de referência compreende uma Tecla de Roteamento de Serviços de Emergência, ESRK, Dígitos de Roteamento de Serviços de Emergência, ESRD, mais um Número de Diretório de Assinantes Internacional de Estação Móvel, MSISDN, ou um Identificador Universal de Recursos (URI) de localização; e/ou em que a localização do UE (800) é obtida utilizando uma solução de localização de plano de controle ou uma solução de localização de plano do usuário, em que a outra entidade é o PSAP (880), uma Identificação de Localização Automática, ALI, ou uma rede de IP de Serviços de Emergência (860), ESInet.
8. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende adicionalmente: enviar uma segunda mensagem para ou na direção do PSAP com base nas informações de roteamento, em que a segunda mensagem compreende uma solicitação para a chamada de emergência, em que a entidade de IMS (894) é uma Função de Controle de Sessão de Chamada de Emergência, CSCF.
9. Método para suportar chamadas de emergência em um equipamento de usuário (800), UE, caracterizado pelo fato de que compreende: receber (2010) uma solicitação para uma chamada de emergência a partir de um usuário do UE (800); obter (2020) dados de operadora de rede móvel, MNO, para uma MNO (890) servidora para o UE; e enviar (2030) uma primeira mensagem (806) que compreende uma solicitação para a chamada de emergência a um provedor de serviços over-the-top (850), OTT, em que a solicitação para a chamada de emergência inclui os dados de MNO.
10. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que os dados de MNO compreendem um endereço para um Subsistema Multimídia de Protocolo de Internet (894), IP IMS, para a MNO servidora, uma identidade para uma entidade de gerenciamento de mobilidade servidora atual ou nó de suporte de serviço de rádio de pacote geral de servidora, SGSN, para o UE, um endereço de IP atribuído pela MNO servidora para o UE, uma identidade global ou identidade local para o UE ou qualquer combinação destes.
11. Método, de acordo com a reivindicação 10, caracterizado pelo fato de que o provedor de serviços OTT (850) envia uma segunda mensagem (808) 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.
12. Método, de acordo com a reivindicação 11, caracterizado pelo fato de que o IMS (894) determina informações de roteamento para a chamada de emergência com base nos dados de MNO.
13. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que compreende 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 para o UE; e/ou em que o IMS envia uma terceira mensagem ao provedor de serviços OTT que compreende as informações de roteamento, em que o provedor de serviços OTT envia uma quarta mensagem para ou na direção de um ponto de resposta de segurança pública, PSAP (880), de destino, em que o PSAP é determinado com base nas informações de roteamento; e/ou em que o endereço para o IMS é um endereço para uma Função de Recuperação de Localização, LRF.
14. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que o IMS (894) envia uma quinta mensagem para ou na direção de 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.
15. Aparelho (2500) para suportar chamadas de emergência em um provedor de serviços over-the-top (850), OTT, caracterizado pelo fato de que compreende: pelo menos um processador; e um transceptor (2510; 2520) acoplado ao pelo menos um processador e configurado para: receber uma primeira mensagem (806) que compreende uma solicitação de chamada de emergência a partir de um equipamento de usuário, UE, em que a primeira mensagem é transferida para o provedor de serviços OTT por meio de uma operadora de rede móvel, MNO, servidora para o UE, e em que a primeira mensagem inclui um endereço para um Subsistema Multimídia de Protocolo de Internet, IP IMS, para a MNO servidora; e enviar uma segunda mensagem (808) ao IMS com base no endereço, em que a segunda mensagem compreende uma solicitação para a chamada de emergência.
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201462083768P | 2014-11-24 | 2014-11-24 | |
| US62/083,768 | 2014-11-24 | ||
| US201562101974P | 2015-01-09 | 2015-01-09 | |
| US62/101,974 | 2015-01-09 | ||
| US14/863,751 US9756664B2 (en) | 2014-11-24 | 2015-09-24 | Methods of supporting location and emergency calls for an over-the-top service provider |
| US14/863,751 | 2015-09-24 | ||
| PCT/US2015/059998 WO2016085647A1 (en) | 2014-11-24 | 2015-11-10 | Methods of supporting location and emergency calls for an over-the-top service provider |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| BR112017010777A2 BR112017010777A2 (pt) | 2018-01-09 |
| BR112017010777B1 true BR112017010777B1 (pt) | 2023-10-17 |
Family
ID=56011640
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BR112017010777-5A BR112017010777B1 (pt) | 2014-11-24 | 2015-11-10 | Métodos e aparelho para suportar chamadas de emergência |
Country Status (11)
| Country | Link |
|---|---|
| US (2) | US9756664B2 (pt) |
| EP (1) | EP3225042B1 (pt) |
| JP (1) | JP6374110B2 (pt) |
| KR (1) | KR101825898B1 (pt) |
| CN (1) | CN107113566B (pt) |
| AU (1) | AU2015354709B2 (pt) |
| BR (1) | BR112017010777B1 (pt) |
| DK (1) | DK3225042T3 (pt) |
| ES (1) | ES2775501T3 (pt) |
| HU (1) | HUE047306T2 (pt) |
| WO (1) | WO2016085647A1 (pt) |
Families Citing this family (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016043728A1 (en) * | 2014-09-17 | 2016-03-24 | Nokia Technologies Oy | Emergency call handling using over-the-top services |
| US10097979B2 (en) | 2014-11-24 | 2018-10-09 | Qualcomm Incorporated | Location by reference for an over-the-top emergency call |
| US9756664B2 (en) | 2014-11-24 | 2017-09-05 | Qualcomm Incorporated | Methods of supporting location and emergency calls for an over-the-top service provider |
| US10278100B1 (en) | 2016-03-16 | 2019-04-30 | Sprint Communications Company L.P. | Long term evolution (LTE) mobility management entity (MME) management of an internet protocol multimedia subsystem (IMS) media session service level for a user equipment (UE) |
| US9706351B1 (en) * | 2016-04-29 | 2017-07-11 | Peerless Network, Inc. | Emergency call over a data network |
| EP3453208B1 (en) * | 2016-05-03 | 2024-09-18 | Telefonaktiebolaget LM Ericsson (publ) | Methods and network nodes for providing ue location for vowifi calls |
| WO2018045501A1 (zh) * | 2016-09-07 | 2018-03-15 | 华为技术有限公司 | 本地分组数据网络的动态创建方法、装置及系统 |
| US11165833B2 (en) * | 2016-11-02 | 2021-11-02 | T-Mobile Usa, Inc. | Network routing based on terminal's media path |
| US20210297380A1 (en) | 2017-03-03 | 2021-09-23 | Mararlee Pty Ltd | System and method for delivery and receipt of electronic communications |
| US11641381B2 (en) | 2017-03-09 | 2023-05-02 | T-Mobile Usa, Inc. | Call setup timer triggered by network response |
| US10694364B2 (en) * | 2017-03-24 | 2020-06-23 | Apple Inc. | Providing a local address while roaming |
| US10111077B1 (en) * | 2017-04-19 | 2018-10-23 | Qualcomm Incorporated | System and method for enabling mobile device location services during an emergency call |
| EP3665916A4 (en) * | 2017-08-09 | 2021-10-06 | Nokia Solutions and Networks Oy | EMERGENCY VOICE SERVICE SUPPORT INDICATIONS |
| GB2567980B (en) | 2017-08-30 | 2020-01-01 | Metaswitch Networks Ltd | Establishing a telephony session |
| KR102422619B1 (ko) * | 2018-02-14 | 2022-07-20 | 삼성전자 주식회사 | 위급한 상황에 처한 사용자의 위치 정보를 제공하는 전자 장치 및 방법 |
| JP6992906B2 (ja) * | 2018-03-28 | 2022-01-13 | 日本電気株式会社 | ユーザ装置のための方法及びユーザ装置 |
| US20190335040A1 (en) * | 2018-04-26 | 2019-10-31 | Microsoft Technology Licensing, Llc | Prioritized routing during a regional event |
| US10999422B2 (en) * | 2018-05-11 | 2021-05-04 | Sony Corporation | Confirming geolocation of a device |
| CN110677844B (zh) * | 2018-07-03 | 2022-04-08 | 中国电信股份有限公司 | 呼叫方法、信息交互方法、通信设备和交互平台 |
| CN111131997B (zh) * | 2018-10-12 | 2021-08-06 | 大唐移动通信设备有限公司 | 一种上行到达时间差定位方法及其装置 |
| CN112335294B (zh) * | 2019-01-31 | 2022-04-22 | 华为技术有限公司 | 一种紧急呼叫方法及用户终端 |
| US11277450B2 (en) * | 2019-02-04 | 2022-03-15 | Verizon Patent And Licensing Inc. | Over-the-top client with native calling quality of service |
| US11526826B2 (en) | 2019-11-07 | 2022-12-13 | Nokia Solutions And Networks Oy | Remote definition of metrics |
| CN115053504A (zh) * | 2019-12-06 | 2022-09-13 | 瑞典爱立信有限公司 | 互通独立非公共网络-ims |
| US11689367B2 (en) * | 2020-09-24 | 2023-06-27 | Huawei Technologies Co., Ltd. | Authentication method and system |
| US11330103B1 (en) * | 2021-01-05 | 2022-05-10 | T-Mobile Usa, Inc. | Call state notification for emergency call processing |
| US11477632B2 (en) | 2021-02-17 | 2022-10-18 | Qualcomm Incorporated | Systems and techniques to support cell identification for satellite wireless access |
| WO2022177859A1 (en) * | 2021-02-17 | 2022-08-25 | Qualcomm Incorporated | Systems and techniques to support cell identification for satellite wireless access |
| US11617059B1 (en) | 2021-05-28 | 2023-03-28 | T-Mobile Usa, Inc. | Mobile device geographic location determination for emergency services |
| US12003664B2 (en) | 2021-12-16 | 2024-06-04 | T-Mobile Usa, Inc. | Automatic redirecting of enhanced 911 calls |
| US11924514B2 (en) * | 2022-03-17 | 2024-03-05 | Charter Communications Operating, Llc | Caller identification for a destination wireless user equipment |
| US20230328478A1 (en) * | 2022-04-12 | 2023-10-12 | At&T Intellectual Property I, L.P. | Guidance to a target location |
Family Cites Families (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| MX2007012683A (es) * | 2005-04-12 | 2008-01-11 | Telecomm Systems Inc | Portal de numeracion electronica temporal. |
| US20070086382A1 (en) | 2005-10-17 | 2007-04-19 | Vidya Narayanan | Methods of network access configuration in an IP network |
| US20070153986A1 (en) * | 2006-01-03 | 2007-07-05 | Sony Ericsson Mobile Communications Ab | Method and Apparatus for Routing Emergency Calls in a VoIP System |
| US7463880B2 (en) * | 2006-01-13 | 2008-12-09 | Kyocera Wireless Corp. | E911 behavior with GSRM in a wireless communication device |
| US8493267B2 (en) | 2006-11-10 | 2013-07-23 | Qualcomm Incorporated | Method and apparatus for position determination with extended SPS orbit information |
| US9185216B2 (en) * | 2007-06-15 | 2015-11-10 | Blackberry Limited | System and method for indicating emergency call back to user equipment |
| US7991382B1 (en) * | 2007-11-08 | 2011-08-02 | Sprint Spectrum L.P. | Method for communicating indoor location to an emergency service system |
| US20090154397A1 (en) * | 2007-12-17 | 2009-06-18 | Nortel Networks Limited | System and method for providing quality of service enablers for third party applications |
| US8254877B2 (en) | 2008-01-04 | 2012-08-28 | Qualcomm Incorporated | Method and apparatus for extended call establishment for IMS emergency calls |
| US9208293B1 (en) | 2008-01-28 | 2015-12-08 | Sprint Communications Company L.P. | Authentication for tag-based content delivery |
| US8369822B2 (en) * | 2009-05-28 | 2013-02-05 | At&T Intellectual Property I, Lp | Systems and methods for providing emergency callback procedures |
| US8594015B2 (en) * | 2009-07-29 | 2013-11-26 | T-Mobile Usa, Inc. | System and method for providing emergency service in an IP-based wireless network |
| US20110026687A1 (en) * | 2009-07-31 | 2011-02-03 | Vladimir Smelyansky | Emergency 911 services with just-in-time provisioning for voip customers |
| US8270574B2 (en) * | 2009-09-08 | 2012-09-18 | Verizon Patent And Licensing Inc. | Emergency calls in internet protocol multimedia subsystem (IMS) over evolved packet core (EPC) networks |
| CN102036204B (zh) | 2009-09-24 | 2015-06-03 | 中兴通讯股份有限公司 | 一种实现紧急定位的方法及系统 |
| US8315589B2 (en) * | 2009-09-30 | 2012-11-20 | Verizon Patent And Licensing Inc. | Emergency calls for internet protocol multimedia subsystem (IMS) over packet switched code division multiple access (CDMA) networks |
| US9065908B2 (en) | 2010-02-12 | 2015-06-23 | Broadcom Corporation | Method and system for ensuring user and/or device anonymity for location based services (LBS) |
| US8774836B2 (en) | 2010-03-11 | 2014-07-08 | Broadcom Corporation | Method and system for optimized transfer of location database information |
| US8565714B2 (en) * | 2011-01-14 | 2013-10-22 | Interdigital Patent Holdings, Inc. | Identifying public safety answering point (PSAP) callbacks in internet protocol (IP) multimedia subsystem (IMS) emergency services |
| US8929855B2 (en) * | 2011-12-02 | 2015-01-06 | Maple Acquisition Llc | Enabling location determination of user device originating emergency service call |
| US8848666B2 (en) * | 2012-01-27 | 2014-09-30 | Telefonaktiebolaget L M Ericsson (Publ) | Handover of emergency calls from a circuit switched to a packet switched access network |
| US9467907B2 (en) | 2012-03-12 | 2016-10-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Handover of user-equipment (UE) undetected emergency calls |
| US9161196B2 (en) | 2012-08-07 | 2015-10-13 | Google Technology Holdings LLC | Apparatus and method for secure private location information transfer |
| CN104685935B (zh) | 2012-09-27 | 2019-01-15 | 交互数字专利控股公司 | 虚拟化网络中的端到端架构、api框架、发现以及接入 |
| US20140031003A1 (en) | 2012-10-02 | 2014-01-30 | Bandwidth.Com, Inc. | Methods and systems for providing emergency calling |
| US9609497B2 (en) * | 2012-11-16 | 2017-03-28 | Verizon Patent And Licensing Inc. | Intelligent emergency session handling |
| EP2932680A1 (en) | 2012-12-12 | 2015-10-21 | Interdigital Patent Holdings, Inc. | Independent identity management systems |
| US9426833B2 (en) * | 2013-03-01 | 2016-08-23 | T-Mobile Usa, Inc. | Systems and methods for emergency call route failover |
| US9516689B2 (en) | 2014-02-21 | 2016-12-06 | Apple Inc. | Mitigating no-service delays for LTE capable wireless devices without LTE access permission |
| WO2016043728A1 (en) * | 2014-09-17 | 2016-03-24 | Nokia Technologies Oy | Emergency call handling using over-the-top services |
| WO2016080880A1 (en) * | 2014-11-20 | 2016-05-26 | Telefonaktiebolaget L M Ericsson (Publ) | Method and arrangement for retrieving geographic location |
| US9756664B2 (en) | 2014-11-24 | 2017-09-05 | Qualcomm Incorporated | Methods of supporting location and emergency calls for an over-the-top service provider |
| US10097979B2 (en) | 2014-11-24 | 2018-10-09 | Qualcomm Incorporated | Location by reference for an over-the-top emergency call |
-
2015
- 2015-09-24 US US14/863,751 patent/US9756664B2/en active Active
- 2015-11-10 HU HUE15801038A patent/HUE047306T2/hu unknown
- 2015-11-10 KR KR1020177013846A patent/KR101825898B1/ko active IP Right Grant
- 2015-11-10 AU AU2015354709A patent/AU2015354709B2/en active Active
- 2015-11-10 WO PCT/US2015/059998 patent/WO2016085647A1/en active Application Filing
- 2015-11-10 BR BR112017010777-5A patent/BR112017010777B1/pt active IP Right Grant
- 2015-11-10 DK DK15801038.9T patent/DK3225042T3/da active
- 2015-11-10 EP EP15801038.9A patent/EP3225042B1/en active Active
- 2015-11-10 CN CN201580062079.3A patent/CN107113566B/zh active Active
- 2015-11-10 ES ES15801038T patent/ES2775501T3/es active Active
- 2015-11-10 JP JP2017527555A patent/JP6374110B2/ja active Active
-
2017
- 2017-09-04 US US15/694,965 patent/US10165395B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| AU2015354709B2 (en) | 2018-10-04 |
| EP3225042B1 (en) | 2020-01-01 |
| KR20170091600A (ko) | 2017-08-09 |
| HUE047306T2 (hu) | 2020-04-28 |
| BR112017010777A2 (pt) | 2018-01-09 |
| US10165395B2 (en) | 2018-12-25 |
| CN107113566A (zh) | 2017-08-29 |
| JP6374110B2 (ja) | 2018-08-15 |
| JP2017536768A (ja) | 2017-12-07 |
| CN107113566B (zh) | 2018-11-02 |
| ES2775501T3 (es) | 2020-07-27 |
| US20160150574A1 (en) | 2016-05-26 |
| DK3225042T3 (da) | 2020-02-10 |
| EP3225042A1 (en) | 2017-10-04 |
| US9756664B2 (en) | 2017-09-05 |
| US20180014338A1 (en) | 2018-01-11 |
| KR101825898B1 (ko) | 2018-02-05 |
| AU2015354709A1 (en) | 2017-05-04 |
| WO2016085647A1 (en) | 2016-06-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10165395B2 (en) | Methods of supporting location and emergency calls for an over-the-top service provider | |
| US10085142B2 (en) | Location by reference for an over-the-top emergency call | |
| US8971840B2 (en) | Method and apparatus for supporting emergency calls and location for FEMTO access points | |
| ES2765676T3 (es) | Encaminamiento basado en localización de llamadas de emergencia VoIP | |
| BRPI0616074B1 (pt) | suporte de chamada em modo circuito de emergência | |
| BRPI0614520B1 (pt) | Suporte de chamada de emergência voip | |
| US10560570B2 (en) | Method, system and device for providing a setup of an enhanced call via a wireless local area network | |
| US12022536B2 (en) | Method, system and device for providing a setup of an enhanced call via a wireless local area network | |
| WO2017121566A1 (en) | Location determination of a wireless device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B15K | Others concerning applications: alteration of classification |
Ipc: H04W 4/00 (2018.01), H04W 12/08 (2009.01), H04W 48 |
|
| B06U | Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette] | ||
| B09A | Decision: intention to grant [chapter 9.1 patent gazette] | ||
| B16A | Patent or certificate of addition of invention granted [chapter 16.1 patent gazette] |
Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 10/11/2015, OBSERVADAS AS CONDICOES LEGAIS |