BRPI0614520B1 - Suporte de chamada de emergência voip - Google Patents

Abstract

suporte de chamada de emergencia voip. técnicas para suportar chamadas de voz sobre protocolo internet (voip) de emergência são descritas. as técnicas podem ser usadas para várias redes 3gpp e 3gpp2, várias arquiteturas de localização, e vários tipos de equipamento de usuário (ue) um ue comunica com uma rede visitada para enviar uma solicitação para estabelecer uma chamada voip de emergência. o ue interage com o servidor de localização instruído pela rede visitada para obter uma primeira estimativa de posição para o ue. o ue realizaestabelecimento de chamada através da rede visitada para estabelecer a chamada voip de emergência com um psap, o qual pode ser selecionado com base na primeira estimativa de posição. o ue pode então realizar posicionamento com o servidor de localização para obter uma estimativa de posição atualizada para o ue, por exemplo, se solicitado pelo psap.

Description

Campo da Invenção

A presente descrição refere, geralmente, à comunicação, e mais especificamente, a técnicas para suportar chamadas de emergência.

Descrição da Técnica Anterior

As redes de comunicação sem fio são amplamente empregadas para prover vários serviços de comunicação tais como voz, video, dados de pacote, troca de mensagens, broadcast, e assim por diante. Essas redes sem fio podem ser redes de acesso múltiplo capazes de suportar comunicação para múltiplos usuários mediante compartilhamento de recursos disponíveis da rede. Exemplos de tais redes de acesso múltiplo incluem redes de Acesso Múltiplo por Divisão de Código (CDMA), Redes de

Acesso Múltiplo por Divisão de Tempo (TDMA), Redes de

Acesso Múltiplo por Divisão de Freqüência (FDMA) , e Redes FDMA Ortogonais (OFDMA).

As redes sem fio, tipicamente, suportam comunicação para usuários sem fio que têm assinaturas de serviço com estas redes. Uma assinatura de serviço pode ser associada com informação para segurança, roteamento, qualidade de serviço (QoS), tarifação, e assim por diante. A informação relacionada à assinatura pode ser usada para estabelecer chamadas com uma rede sem fio.

Um dos serviços mais básicos providos pelas redes sem fio para seus usuários é a capacidade de enviar e receber chamadas de voz. Um aperfeiçoamento recente deste serviço é a capacidade de enviar e receber chamadas de Voz sobre Protocolo Internet (VoIP). Uma chamada VoIP é uma chamada de voz na qual dados de voz são enviados em pacotes que são encaminhados como outros dados de pacotes em vez de em um canal de tráfego dedicado.

Um usuário sem fio pode estabelecer uma chamada

2/76 de voz de emergência ou outra chamada de midia com uma rede sem fio que pode ou não ser a rede de origem com a qual o usuário tem assinatura de serviço. Tal chamada pode usar VoIP. Um desafio principal é o de encaminhar a chamada de emergência para um Ponto de Resposta de Segurança Pública (PSAP) apropriado que pode atender à chamada. Isso pode requerer a obtenção de uma estimativa de posição provisória para o usuário e a determinação de um PSAP adequado com base na estimativa de posição provisória. O problema é composto se o usuário estiver em deslocamento e/ou não tiver assinatura de serviço com qualquer rede.

Existe, portanto, a necessidade na arte de técnicas para suportar chamadas de emergência e chamadas VoIP de emergência.

Resumo da Invenção

Técnicas para suportar chamadas de Voz sobre Protocolo Internet (VoIP) de emergência são descritas aqui. As técnicas podem ser usadas para várias redes 3GPP e 3GPP2, várias arquiteturas de localização, e Equipamentos de Usuário (UEs) com e sem assinatura de serviço.

Em uma modalidade, um UE comunica com uma rede visitada para enviar uma solicitação para estabelecer uma chamada VoIP de emergência. O UE interage com um servidor de localização instruído pela rede visitada para obter uma primeira estimativa de posição para o UE. O UE realiza o estabelecimento de chamada por intermédio da rede visitada para estabelecer a chamada VoIP de emergência com um PSAP, o qual pode ser selecionado com base na estimativa de posição inicial. 0 UE pode então realizar posicionamento com o servidor de localização para obter uma estimativa de posição atualizada para o UE, por exemplo, se solicitado pelo PSAP. Vários detalhes da chamada VoIP de emergência são descritos abaixo.

3/76

Vários aspectos e modalidades da descrição são também descritos em maiores detalhes abaixo.

Breve Descrição das Figuras

Aspectos e modalidades da descrição serão mais evidentes a partir da descrição detalhada apresentada abaixo quando considerada em conjunto com os desenhos nos quais os mesmos caracteres de referência identificam correspondentemente os mesmos elementos em todo o relatório.

Fiqura 1 - mostra um emprego que suporta chamadas VoIP de emergência.

Figura 2 - mostra uma arquitetura de rede 3GPP.

Fiqura 3 - mostra uma arquitetura de rede 3GPP2.

Figuras 4 e 5 - mostram uma arquitetura de rede e um fluxo de mensagem, respectivamente, para chamada VoIP de emergência com localização SUPL.

Figuras 6 e 7 - mostram uma arquitetura de rede e um fluxo de mensagem, respectivamente, para chamada VoIP de emergência com localização de plano de controle 3GPP.

Figuras 8 e 9 - mostram uma arquitetura de rede e um fluxo de mensagem, respectivamente, para chamada VoIP de emergência com localização X.S0024.

Figuras 10 e 11 - mostram uma arquitetura de rede e um fluxo de mensagem, respectivamente, para chamada VoIP de emergência para um UE sem assinatura de serviço.

Figura 12 - mostra um diagrama em blocos de várias entidades nas Figuras 1 a 3.

Descrição Detalhada da Invenção

O termo exemplar é usado aqui significando servindo como um exemplo, ocorrência, ou ilustração. Qualquer modalidade ou projeto descrito aqui como exemplar não deve necessariamente ser considerado como preferido ou vantajoso em relação às outras modalidades ou

4/76 projetos.

Técnicas para suportar chamadas VoIP de emergência são descritas aqui. Uma chamada VoIP de emergência é uma chamada VoIP ou uma chamada comutada por pacotes para serviços de emergência. Uma chamada VoIP de emergência pode ser identificada como tal e pode ser distinguida de uma chamada VoIP normal de várias maneiras, como descrito abaixo. Uma chamada VoIP de emergência pode ser associada a várias características que são diferentes de uma chamada VoIP comum tal como, por exemplo, obter uma estimativa de posição adequada para um usuário, encaminhar a chamada VoIP de emergência para um PSAP apropriado, assim por

Uma estimativa de posição é também referenciada como uma estimativa de localização, uma determinação de posição, e assim por diante.

A Figura 1 mostra um emprego 100 que suporta chamadas VoIP de emergência. Um Equipamento de Usuário (UE)

110 comunica com uma rede de acesso 120 para obter serviços de comunicação IP básicos. 0 UE 110 pode ser estacionário ou móvel e pode também ser chamado de estação móvel (MS) , terminal, unidade de assinante, estação, ou alguma outra terminologia. O UE 110 pode ser um telefone celular, um assistente digital pessoal (PDA), um dispositivo sem fio, um computador laptop, um dispositivo de telemetria, um dispositivo de rastreamento, e assim por diante. O UE 110 pode comunicar com uma ou mais estações base e/ou um ou mais pontos de acesso na rede de acesso 120. O UE 110 pode também receber sinais de um ou mais satélites 190, os quais podem ser parte do Sistema de Posicionamento Global (GPS), sistema Europeu Galileu, sistema Russo GLONASS, ou qualquer sistema de satélite de navegação global (GNSS) . 0 UE 110 pode medir os sinais das estações base na rede de acesso 120 e/ou os sinais dos satélites 190 e pode obter medições

5/76 pseudo-alcance para os satélites e/ou medições de temporização para as estações base. As medições de pseudoalcance e/ou as medições de temporização podem ser usadas para derivar uma estimativa de posição para o UE 110 utilizando um dos métodos de posicionamento ou uma combinação destes conhecidos na técnica tal como GPS assistido (A-GPS), GPS autônomo, Trilateração Avançada de Link Direto (A-FLT), Diferença de Tempo Observada Aperfeiçoada (E-OTD), Diferença de Tempo de Chegada Observada (OTDOA), ID de Célula Aperfeiçoada, e assim por diante.

A rede de acesso 120 provê radiocomunicação para os UEs localizados dentro da área de cobertura da rede de acesso. A rede de acesso 120 pode incluir estações base, controladores de rede, e/ou outras entidades, como descrito abaixo. Uma rede visitada 130, a qual é também chamada de Rede Móvel Terrestre Pública Visitada (V-PLMN), é uma rede atualmente servindo o UE 110. Uma rede de origem 160, a qual é também chamada de PLMN de origem (H-PLMN) , é uma rede com a qual o UE 110 tem assinatura. A rede de acesso 120 é associada com a rede visitada 130. A rede visitada 130 e a rede de origem 160 podem ser as mesmas ou diferentes redes. A rede visitada 130 e a rede de origem 160 podem ou não ter acordo para roaming. As redes 130 e 160 podem individualmente compreender entidades que proporcionam conectividade de dados, serviços de localização, e/ou outras funcionalidades e serviços.

Uma rede 170 pode incluir uma Rede de Telefonia Comutada Pública (PSTN) , a Internet, e/ou outras redes de dados e voz. Uma PSTN suporta comunicação para serviço de telefonia de plano antigo convencional (POTS). Um PSAP 180 é uma entidade responsável por responder às chamadas de emergência (por exemplo, para serviços de policia, incêndio

6/76 e médicos) e pode ser referenciada também como um Centro de Emergência (EC). Tais chamadas podem ser iniciadas quando o usuário disca um número conhecido determinado tal como 911 nos Estados Unidos ou 112 na Europa. PSAP 180 é tipicamente operado ou é de propriedade de uma agência governamental, por exemplo, condado ou cidade. PSAP 180 pode suportar conectividade IP para chamadas VoIP e então suportar Protocolo de Iniciação de Sessão (SIP), o qual é um protocolo de sinalização para iniciar, modificar e terminar sessões de usuário interativas com base em IP tal como VoIP. Alternativamente ou adicionalmente, PSAP 180 pode suportar comunicação com a PSTN 170.

As técnicas aqui descritas podem ser usadas para chamadas VoIP de emergência originadas de redes de linhas de fios tais como DSL e cabo e para chamadas VoIP de emergência originadas das redes de área remota sem fio (WWANs), redes de área local sem fio (WLANs), redes metropolitanas sem fio (WMANs), e redes sem fio com cobertura WWAN e WLAN. As WWANs podem ser CDMA, TDMA, FDMA, OFDMA e/ou outras redes. Uma rede CDMA pode implementar uma ou mais tecnologias de rádio tal como CDMA de Banda Larga (W-CDMA), cdma2000, e assim por diante. cdma2000 abrange os padrões IS-2000, IS-856, e IS-95 e inclui as revisões Ev-DO para otimizar suporte IP. Uma rede TDMA pode implementar uma ou mais tecnologias de rádio tal como Sistema Global para Comunicação Móvel (GSM), Sistema de Telefonia Móvel Avançado Digital (D-AMPS), e assim por diante. D-AMPS abrange IS-248 e IS-54. W-CDMA e GSM são descritos nos documentos provenientes de uma organização denominada Projeto de Parceiros de 3^a Geração (3GPP). cdma2000 é descrito nos documentos provenientes de uma organização denominada 2 Projeto de Parceiros de 3^a Geração (3GPP2). Os documentos 3GPP e 3GPP2 estão publicamente disponíveis.

7/76

Uma WLAN pode implementar uma tecnologia de rádio tal como IEEE 802.11. Uma WMAN pode implementar uma tecnologia de rádio tal como .IEEE 802.16. Estas várias tecnologias e padrões de rádio são conhecidos na técnica.

A Figura 2 mostra uma arquitetura de rede 3GPP. O UE 110 pode obter acesso de rádio por intermédio da rede de acesso 3GPP 120a ou uma rede de acesso WLAN 120b. A rede de acesso 3GPP 120a pode ser uma Rede de Acesso de Rádio EDGE GSM (GERAM), uma Rede de Acesso de Rádio Terrestre (UTRAN), uma UTRAN desenvolvida (E-UTRAN), ou alguma outra rede de acesso. A rede de acesso 3GPP 120a inclui as estações base 210, um subsistema de estação base (BSS)/Controlador de Rede de Rádio (RNC) 212, e outras entidades não mostradas na Figura 2. Uma estação base é também referenciada como um Nó B, um Nó B aperfeiçoado (Nó B-e) , uma Estação Base Transceptora (BTS), um ponto de acesso (AP), ou alguma outra terminologia. Uma WLAN 120b inclui pontos de acesso 214 e pode ser qualquer WLAN.

Uma V-PLMN 130a é uma modalidade da rede visitada 130 na Figura 1 e inclui uma rede núcleo V-PLMN 230a e entidades de localização V-PLMN 270a. A rede núcleo V-PLMN 230a inclui um Nó de Suporte GPRS de Serviço (SGSN) 232a, um Nó de Suporte GPRS de Porta de Comunicação (GGSN) 232b, uma Porta de Comunicação de Acesso WLAN (WAG) 234, e uma Porta de Comunicação de Dados de Pacote (PDG) 236. SGSN 232a e a GGSN 232b constituem parte de uma rede núcleo de Serviço de Rádio Pacote Geral (GPRS) e proporcionam serviços comutados por pacote para os UEs que comunicam com a rede de acesso 3GPP 120a. WAG 234 e PDG 236 constituem parte de uma rede núcleo WLAN de Interconexão 3GPP (I-WLAN) e proporcionam serviços comutados por pacote para os UEs que comunicam com a WLAN 120b.

A rede núcleo V-PLMN 230a também inclui um

8/76

Servidor de Assinante de Origem (HSS) 250 e várias entidades de Subsistema de Multimídia IP (IMS) incluindo uma Função de Controle de Sessão de Chamada Proxy (P-CSCF) 252, uma CSCF de Emergência (E-CSCF) 254, uma CSCF de Interrogação (I-CSCF) 256, e uma Função de Controle de Porta de Comunicação de Midia (MGCF) 258. P-CSCF 252, ECSCF 254, I-CSCF 256 e MGCF 258 suportam os serviços IMS, por exemplo, chamadas VoIP, e constituem parte de uma rede IMS V-PLMN. P-CSCF 252 aceita solicitações dos UEs e atende estas solicitações internamente ou envia as solicitações para outras entidades, possivelmente após translação. ECSCF 254 realiza serviços de controle de sessão para os UEs e mantém o estado de sessão usado para suportar os serviços de emergência IMS. E-CSCF 254 também suporta chamadas VoIP de emergência. MGCF 258 direciona a conversão de sinalização entre SIP/IP e a PSTN (por exemplo, SS7 ISUP) e é usada sempre que uma chamada VoIP de um usuário segue para um usuário da PSTN. HSS 250 armazena informação relacionada à assinatura para os UEs para os quais a V-PLMN 130a é a rede de origem.

Entidades de localização V-PLMN 270a podem incluir uma Plataforma de Localização SUPL de Serviços de Emergência (E-SLP) 272 e uma SLP Visitante (V-SLP) 274, que suportam Localização de Plano de Usuário Seguro OMA (SUPL). V-SLP 27 4 pode estar dentro da, ou associada com uma rede diferente da V-PLMN 130a e/ou pode estar geograficamente mais próximo do UE 110. Alternativamente ou adicionalmente, as entidades de localização V-PLMN 270a podem incluir um centro de Localização Móvel de Porta de Comunicação (GMLC) 276, o qual é parte da localização de plano de controle 3GPP. E-SLP 272, V-SLP 274 e GMLC 276 proporcionam serviços de localização para os UEs em comunicação com V-PLMN 130a.

Uma H-PLMN 160a é uma modalidade da rede de

9/76 origem 160 na Figura 1 e inclui uma rede núcleo H-PLMN 260. A rede núcleo H-PLMN 260 inclui uma HSS 266 e inclui ainda entidades IMS tal como uma I-CSCF 262 e uma CSCF de Serviço (S-CSCF) 264 que suporta IMS para a rede de origem 160. ICSCF 262 e S-CSCF 264 constituem parte de uma rede IMS HPLMN.

A Figura 3 mostra uma arquitetura de rede 3GPP2. O UE 110 pode obter acesso via rádio por intermédio de uma rede de acesso 3GPP2 120c ou através de uma rede de acesso WLAN 120d. A rede de acesso 3GPP2 120c pode ser uma rede CDMA2000 IX, uma rede CDMA2000 lxEv-DO, ou alguma outra rede de acesso. A rede de acesso 3GPP2 120c inclui estações base 220, uma Função de Controle de Pacote/Controle de Recurso de Rádio (RRC/PCF) 222, e outras entidades não mostradas na Figura 3. RRC pode ser também chamada de Controlador de Rede de Rádio (RNC) ou estação base. A rede de acesso 3GPP2 120c também pode ser chamada de Rede de Acesso de Rádio (RAN). WLAN 120d inclui pontos de acesso 224 e pode ser qualquer WLAN associada a uma rede 3GPP2.

Uma V-PLMN 130b é outra modalidade da rede visitada 130 na Figura 1 e inclui uma rede núcleo V-PLMN 230b e entidades de localização 3GPP2 270b. A rede núcleo V-PLMN 230b inclui um Nó de Serviço de Dados de Pacote (PDSN) 242, uma Função de Interconexão de Dados de Pacote (PDIF) 244, e um servidor de Autenticação, Autorização e Contabilidade (AAA) 246. PDSN 242 e PDIF 244 proporcionam serviços comutados por pacote para os UEs que comunicam com a rede de acesso 3GPP2 120c e WLAN 120d, respectivamente. A rede núcleo V-PLMN 230a inclui também IMS ou entidades de Domínio de Multimídia (MMD) tais como P-CSCF 252, E-CSCF 254, I-CSCF 256 e MGCF 258. E-CSCF 254 pode ter também outros nomes tal como ES-AM (Gerenciador de Aplicação de Serviços de Emergência) .

10/76

As entidades de localização 3GPP2 270b podem incluir E-SLP 272 e V-SLP 274 para SUPL. Alternativamente ou adicionalmente, as entidades de localização 3GPP2 270b podem incluir um Servidor de Posição de Serviços de Emergência (E-PS) 282 e um Servidor de Posição Visitada (VPS)/Entidade de Determinação de Posição (PDE) 284, as quais constituem parte da localização X.S0024 para as redes cdma2000. E-PS 282 pode ser também referenciada como um Servidor de Posição Substituto (S-PS). E-SLP 272, V-SLP 274, E-PS 282, e V-PS/PDE 284 proporcionam serviços de localização para os UEs em comunicação com a V-PLMN 130b.

Para simplicidade, as Figuras 2 e 3, mostram apenas algumas das entidades no 3GPP e 3GPP2, que são referenciadas na descrição abaixo. As redes 3GPP e 3GPP2 podem incluir outras entidades definidas por 3GPP e 3GPP2, respectivamente.

Na descrição a seguir, a rede 3GPP refere às redes e subsistemas de rede (por exemplo, subsistemas de rede de acesso) definidos por 3GPP assim como outras redes e subsistemas de rede (por exemplo, WLAN) operados em conjunto com as redes 3GPP. As redes 3GPP e os subsistemas de rede podem incluir GERAN, ÜTRAN, E-UTRAN, rede núcleo GPRS, rede IMS, I-WLAN 3GPP, e assim por diante. As redes 3GPP2 referem às redes e subsistemas de redes definidos por 3GPP2 assim como outras redes e subsistemas de rede operados em conjunto com as redes 3GPP2. As redes 3GPP2 incluem CDMA2000 IX, CDMA2000 lxEv-DO, rede núcleo cdma2000, IMS 3GPP2 ou subsistema de rede MMD, WLAN associada a 3GPP2, e assim por diante. Para simplicidade, WLAN 3GPP refere a uma WLAN associada a uma rede 3GPP, e WLAN 3GPP2 refere a uma WLAN associada a uma rede 3GPP2.

Na descrição a seguir, acesso GPRS refere ao acesso à rede núcleo GPRS através da GERAN, UTRAN, ou

11/76 alguma outra rede de acesso 3GPP. Acesso WLAN 3GPP refere ao acesso a uma rede núcleo 3GPP através da WLAN. Acesso cdma2000 refere ao acesso à rede núcleo cdma2000 através da rede CDMA2000 IX, CDMA2000 lxEv-DO, ou alguma outra rede de acesso 3GPP2. Acesso WLAN 3GPP2 refere ao acesso à rede núcleo WLAN 3GPP2 através da WLAN.

Para 3GPP, o UE 110 pode ou não ser equipado com um Cartão de Circuito Integrado Universal (UICC). Para 3GPP2, o UE 110 pode ou não ser equipado com um Módulo de Identidade de Usuário (UIM) . Um UICC ou UIM é tipicamente especifico para um assinante e pode armazenar informação pessoal, informação de assinatura, e/ou outra informação. Um UE sem-UICC é um UE sem UICC, e um UE sem-UIM é um UE sem UIM. Um UE sem-UICC/UIM não tem assinatura, nenhuma rede de origem, e nenhuma credencial de autenticação (por exemplo, nenhuma chave secreta) para verificar qualquer identidade reivindicada, o que torna os serviços de localização mais propensos a riscos.

As técnicas descritas aqui podem ser usadas por várias arquiteturas de localização tal como arquiteturas de plano de controle e plano de usuário. Um piano de controle (o qual é também chamado de plano de sinalização) é um mecanismo para transportar sinalização para aplicações de camada superior e é tipicamente implementado com protocolos específicos de rede, mensagens de sinalização e interfaces. Um plano de usuário é um mecanismo para transportar sinalização para aplicações de camada superior, porém empregando uma portadora de plano de usuário, o qual é implementado tipicamente com protocolos tal como o Protocolo de Datagrama de Usuário (UDP), Protocolo de Controle de Transmissão (TCP), e Protocolo Internet (IP), todos os quais são conhecidos na arte. As mensagens suportando serviços de localização e posicionamento são

12/76 conduzidas como parte da sinalização em uma arquitetura de plano de controle e como parte de dados (de uma perspectiva da rede) em uma arquitetura de plano de usuário. 0 conteúdo das mensagens, contudo, pode ser o mesmo ou similar em 5 ambas as arquiteturas.

As técnicas podem ser usadas para várias arquiteturas/soluções de localização tais como estas relacionadas na Tabela 1. SUPL e pré-SUPL são descritos nos documentos provenientes da Aliança Móvel Aberta (OMA). 0 plano de controle 3GPP é descrito no 3GPP TS 23.271, TS

43.059, e TS 25.305. O plano de controle 3GPP2 é descrito no IS-881 e 3GPP2 X.S0002. O plano de usuário 3GPP2 é descrito no 3GPP2 X.S0024.

Tabela 1

Arquitetura de Localização	Tipo de Arquitetura	Aplicável a ...
Pré-SUPL	Plano de usuário	Redes 3GPP
SUPL	Plano de usuário	Redes 3GPP e 3GPP2
Plano de controle 3GPP	Plano de controle	Redes 3GPP
Plano de controle 3GPP2	Plano de controle	Redes 3GPP2
X.S0024	Plano de usuário	Redes 3GPP2

	Um	UE pode suportar zero, uma ou	múltiplas
soluções	de	localização	(por	exemplo, SUPL, ou	plano de
controle	3GPP, ou SUPL e	plano	de controle 3GPP,	ou SUPL e
X.S0024)	para chamadas	VoIP	de emergência. 0	UE pode
informar	à	rede sobre	suas	capacidades de localização

0 quando uma chamada é feita, por exemplo, em uma mensagem

CONVITE SIP e/ou REGISTRO SIP. Essa informação pode ser

13/76 armazenada em um servidor local (por exemplo, um servidor de localização) para recuperação pela rede.

As técnicas aqui descritas podem suportar os recursos a seguir.

(a) Suportar chamadas VoIP de emergência para usuários móveis, fixos e nômades.

(b) Aplicável às chamadas VoIP utilizando acesso GPRS, acesso WLAN 3GPP, acesso cdma2000, acesso WLAN 3GPP2.

(c) Suportam conectividade IP de extremo-a-extremo para PSAPs com capacidade SIP/IP.

(d) Suportam conectividade para os PSAPs com capacidade PSTN, que podem ser locais em relação aos UEs chamadores, mas geograficamente distantes dos servidores de chamada SIP, por exemplo, quando um provedor de serviço VoIP está distante do UE.

(e) Suportam roteamento de chamada para um PSAP adequado utilizando uma estimativa de posição provisória.

(f) Provisão de localização exata do UE para o PSAP.

(g) Suporte de localização inicial e atualizada utilizando várias arquiteturas de localização.

(h) Suportam chamadas VoIP de emergência dos UEs sem UICC/UIM e UEs cujas H-PLMNs não têm acordos de roaming com as V-PLMNs.

(i) Suportam rechamada de um PSAP para um UE sem um UICC/UIM e/ou sem acordo de roaming em uma V-PLMN.

(j) Compatíveis com uma solução IETF Ecrit e soluções

NENA tal como Arquitetura VoIP Provisória para Serviços Aperfeiçoados 9-1-1 (i2), também conhecidos como solução NENA 12.

14/76 (k) Poucas exigências e impactos para H-PLMN.

Rechamada PSAP refere a uma chamada de um PSAP de volta para um UE, por exemplo, porque a chamada de emergência foi interrompida ou liberada muito prematuramente. Uma estimativa de posição provisória refere tipicamente a uma posição aproximada usada para roteamento, e uma estimativa de posição inicial refere tipicamente primeira estimativa de posição exata. Em alguns casos, estimativa de inicial pode ser obtida após estimativa de posição provisória. Em outros casos, as estimativas de posição provisória e inicial podem ser as mesmas.

Em ainda alguns outros casos, a estimativa de posição provisória e/ou estimativa de posição inicial podem não ser usadas.

Para SUPL, um SLP na H-PLMN 160 pode ser ignorado, e um ou mais V-SLPs e/ou

E-SLPs na VPLMN 130 ou associada a esta podem ser usados para localização. Para X.S0024, um PS de Origem (H-PS) na H-PLMN

160 pode ser ignorado, e um ou mais V-PSs e/ou E-PSs na VPLMN 130 ou associado a esta podem ser usados para localização.

Isto implica em algumas mudanças no SUPL e

X.S0024, por exemplo, o H-SLP ou H-PS configurado no UE 110 pode ser sobrescrito para localização durante uma chamada de emergência. 0 uso na V-PLMN 130 pode ser desejável pelas razões a seguir:

(a) Suporte de chamada de emergência especializado em regiões ou países específicos deve utilizar suporte apenas das redes nestas regiões e não em outras redes.

(b) Um UE sem um UICC/UIM pode não ter H-PLMN e pode basear em um SLP ou um PS na V-PLMN.

(c) Para um UE com um UICC/UIM, a H-PLMN pode não ter

15/76 acordos de roaming com a V-PLMN, e pode ser difícil utilizar o H-SLP ou H-PS.

(d) O H-SLP ou H-PS pode não suportar uma solicitação de localização de um PSAP remoto (por exemplo, em outro país) devido às diferenças de sinalização e falha de registro.

(e) O H-SLP ou H-PS pode não ser capaz de obter uma boa estimativa de posição (por exemplo, se o H-SLP ou H-PS estiver distante do UE) sem auxílio de um V-SLP ou V-PS na V-PLMN.

(f) O H-SLP ou H-PS pode não suportar uma interface (por exemplo, uma interface Li ou LCS-i) usada pelo E-SLP ou E-PS para suportar serviços de chamada de emergência.

E-SLP 272 ou E-PS 282 pode realizar posicionamento para UE 110 no SUPL e X.S0024, respectivamente. Alternativamente, um V-SLP, V-PS, ou PDE pode ser selecionado para realizar posicionamento para UE 110, por exemplo, se E-SLP 272 ou E-PS 282 não for capaz de realizar esta função. Um V-SLP, V-PS, ou PDE pode ser útil, por exemplo, se um servidor de chamada SIP (por exemplo, ECSCF 254) estiver distante do UE 110 e selecionar um E-SLP ou E-PS que também está distante, o que pode ocorrer quando um operador utiliza um pequeno número de servidores de chamada para atender a uma grande região ou um país inteiro. E-SLP 272 ou E-PS 282 pode selecionar um V-SLP apropriado, V-PS, ou PDE utilizando qualquer um dos mecanismos a seguir:

(a) O UE 110 descobre um endereço IP ou nome de um V-

SLP ou V-PS ao conectar a uma rede de acesso ou estabelecer conectividade IP, por exemplo, a rede de acesso provê ao endereço V-SLP ou V-PS para o

16/76

UE 110. O UE 110 pode também descobrir o endereço V-SLP ou V-PS por intermédio de uma consulta DNS após estabelecer conectividade IP. Isto pode ser aplicável se um servidor DNS usado pelo UE 110 estiver mais próximo do UE 110 do que o E-CSCF 254. O UE 110 pode incluir o endereço V-SLP ou VPS em um REGISTRO SIP inicial enviado ao IMS e em qualquer re-REGISTRO subseqüente após handover para uma nova rede de acesso. IMS (por exemplo, E-CSCF 254) pode transferir o endereço V-SLP ou V-PS para E-SLP 272 ou E-PS 282.

(b) E-SLP 272 ou E-PS 282 determina o endereço V-SLP ou V-PS com base na informação de localização provida pelo UE 110 no CONVITE SIP inicial.

(c) E-SLP 272 ou E-PS 282 determina o endereço V-SLP ou V-PS com base na informação de localização recebida do UE 110 em COMEÇAR SUPL.

Em geral, a informação de localização provida pelo UE 110 pode ser qualquer informação que pode ser usada para determinar a posição do UE 110. A informação, de localização pode compreender coordenadas geográficas, GSM, UMTS, ou identidade de célula cdma2000 (ID), informação de célula de serviço cdma2000, identidade de nome de acesso WLAN, endereço WLAN MAC, e assim por diante. A informação de localização pode também compreender medições que podem ser usadas para determinar a posição do UE 110.

Para SUPL e X.S0024, E-SLP 272 ou E-PS 282 podem enviar um INICIAR SUPL para o UE 110 para iniciar uma sessão SUPL. INICIAR SUPL pode ser enviado utilizando um Push WAP ou SMS, o qual pode resultar em retardo mais longo. Em uma modalidade, para reduzir o retardo, INICIAR SUPL pode ser enviado ao UE 110 por intermédio de IMS (por

17/76 exemplo, P-CSCF 252 e E-CSCF 254) utilizando uma mensagem Imediata IMS, alguma outra mensagem IMS, uma resposta SIP lxx (por exemplo, um Progresso de Sessão 183), ou alguma outra mensagem. O uso de associações existentes (possivelmente seguras) entre o IMS e o UE 110 permite transferência rápida e também evita retardo adicional para estabelecer novas associações e/ou transferir a mensagem através de entidades adicionais (por exemplo, um centro de serviço SMS). Esta modalidade pode ser também usada quando o UE 110 não está registrado na H-PLMN, por exemplo, não tem UICC ou UIM. Em outra modalidade, para reduzir retardo, INICIAR SUPL pode ser enviado ao UE 110 utilizando IP ou UDP/IP móvel terminado. Neste caso, uma porta de comunicação IP servindo o UE 110 (por exemplo, GGSN 232b, PDG 236, PDSN 242, ou PDIF 244) pode ser pré-administrada com o endereço (s) IP do E-SLP 272 para não filtrar os pacotes IP do E-SLP 272 para o UE 110. O UE 110 pode ser configurado para suportar uma porta TCP e/ou porta UDP usada para SUPL (e registrado com IANA) para recebimento do INICIAR SUPL.

Chamadas VolP de emergência podem ser suportadas com SUPL 1.0 e a versão inicial de X.S0024 (3GPP2 X.S0024-0) como a seguir.

(a) Se o UE 110 estiver na H-PLMN 160, então E-SLP 272 é o H-SLP ou E-PS 282 é o H-PS para o UE e invoca uma solicitação de localização iniciada pela rede X.S0024-0 ou SUPL 1.0. INICIAR SUPL pode ser enviado para o UE 110 utilizando SMS ou Push WAP.

(b) Se o UE 110 não estiver na H-PLMN 160, mas estiver registrado com a V-PLMN 130, então o E-SLP 272 pode invocar uma solicitação de localização SUPL 1.0 ao atuar como um SLP Solicitante (R-SLP) e

18/76 enviar a solicitação de localização para o H-SLP para o UE 110 de acordo com o procedimento no SUPL 1.0 e OMA RLP. Similarmente, E-PS 282 pode invocar uma solicitação de localização X.S0024 do H-PS para o UE 110 utilizando, por exemplo, o protocolo

OMA RLP.

(c) Se o UE 110 não está na H-PLMN 160 e não está registrado na V-PLMN 130 (por exemplo, nenhum acordo de roaming entre a V-PLMN 130 e H-PLMN 160) 10 ou se o UE 110 não tem UICC ou UIM, então localização SUPL 1.0 ou X.S0024-0 não é suportada. Contudo, E-SLP 272 ou E-PS 282 podem ser ainda capazes de obter uma estimativa de posição para o UE 110 utilizando informação de localização T5 provida pelo UE 110 em um CONVITE SIP inicial para uma chamada de emergência.

1· Chamada VoIP de Emergência com SUPL

A Figura 4 mostra um diagrama em blocos de uma modalidade de uma arquitetura de rede 400 para chamada VoIP 20 de emergência com localização SUPL. A arquitetura de rede

400 é aplicável a ambas as redes 3GPP e 3GPP2. Para simplicidade, a Figura 4 mostra apenas as interfaces e entidades relevantes para suporte das chamadas VoIP de emergência utilizando SUPL.

O UE 110 é referenciado como um terminal com capacidade SUPL (SET) em SUPL. A rede de acesso 120 pode ser uma rede de acesso 3GPP, uma rede de acesso 3GPP2, uma WLAN, ou alguma outra rede. A rede de acesso 120 e/ou VPLMN 130 inclui entidades que suportam chamadas comutadas por pacote, por exemplo, como mostrado nas Figuras 2 e 3.

Para 3GPP2, IP simples e/ou IP móvel pode ser usado para chamadas VoIP de emergência. Na descrição a seguir, IMS

19/76 pode referenciar a P-CSCF 252, E-CSCF 254 e/ou MGCF 258.

E-SLP 272 pode incluir um Centro de Localização SUPL (E-SLC) 412 que realiza várias funções para serviços de localização e um Centro de Posicionamento SUPL (E-SPC) 414 que suporta posicionamento para os UEs. V-SLP 274 pode incluir similarmente uma V-SLC 422 e uma V-SPC 424. E-SLP 272 pode substituir um H-SLP na H-PLMN 160 no caso de localização para chamadas de emergência. As entidades no SUPL são descritas no documento OMA-AD-SUPL-V2_0-20060704D, intitulado Secure User Plane Location Architecture, Minuta Versão 4.0, 4 de julho de 2006, e no documento OMATS-ULP-V2_0-20060721-D, intitulado User Plane Location Protocol, Minuta Versão 2.0, 21 de julho de 2006, que estão publicamente disponíveis da OMA.

SUPL suporta dois modos de comunicação entre um SET e um SLP para posicionamento com um SPC. Em um modo proxy, o SPC não tem comunicação direta com o SET, e o SLP atua como um proxy entre o SET e o SPC. Em um modo nãoproxy, o SPC tem comunicação direta com o SET.

PSTN/Internet 170 pode incluir entidades (por exemplo, roteadores) que suportam roteamento de pacotes e um Roteador Seletivo (S/R) 292 que encaminha uma chamada de emergência para um PSAP. S/R 292 pode pertencer ao PSAP 180 ou pode ser compartilhado por, e conectado com um conjunto de PSAPs individuais. O UE 110 pode comunicar com o PSAP 180 através do P-CSCF 252 e E-CSCF 254 para uma chamada VoIP se o PSAP 180 suportar SIP. O UE 110 pode também comunicar com o PSAP 180 por intermédio de P-CSCF 252, ECSCF 254, MGCF 258 e S/R 292 se PSAP 180 não suportar SIP. Neste caso, um Portal de Mídia (MGW) controlado pela MGCF 258 realiza conversão no modo de circuito VoIP para PCM para a chamada de emergência.

A Figura 4 mostra as interfaces entre várias

20/76 entidades. As interfaces relacionadas à chamada entre o UE 110, P-CSCF 252, E-CSCF 254, MGCF 258 podem ser SIP. As interfaces relacionadas à chamada entre MGCF 258, S/R 292 e PSAP 180 podem ser MF/ISUP. A interface relacionada à localização entre PSAP 180 e E-SLP 272 pode ser uma interface E2 definida em J-STD-036 rev. B se PSAP 180 for capacitada para PSTN ou uma extensão da interface E2 se PSAP 180 for capacitada para SIP. A interface relacionada à localização entre PSAP 180 e E-SLP 272 pode ser em vez disso uma interface MLP definida no Protocolo de Localização Móvel OMA ou LIF ou alguma outra interface, por exemplo, interface HTTP. A interface relacionada à localização entre o UE 110 e V-SLP 274 e E-SLP 272 pode ser SUPL ULP.

Uma interface entre E-CSCF 254 e E-SLP 272 é usada para conduzir informação sobre o UE 110 para E-SLP 272 e para instigar o posicionamento SUPL. Esta interface pode ser uma interface LCS IMS (por exemplo, Li) e pode utilizar um Protocolo de Localização IMS (ILP) ou algum outro protocolo. A interface Li/ILP pode ser similar a uma interface de Protocolo de Localização Roaming (RLP) OMA entre os SLPs. A interface Li/ILP pode ser usada como qualquer entidade IMS (por exemplo, um S-CSCF ou Servidor de Aplicação) e E-SLP 272 para suportar outros recursos associados com os serviços baseados em IMS e IP tais como:

(a) Tarifação dependente da localização para chamadas baseadas em VoIP ou outras chamadas baseadas em IP, (b) Provisão da localização de uma parte em uma chamada para uma ou mais outras partes, e (c) Serviços suplementares baseados na localização do usuário, por exemplo, envio

21/76 de chamada dependente de localização, bloqueio de chamada dependente da localização.

A interface entre E-SLP 272 e E-CSCF 254 pode ser também uma interface v2 definida em Draft NENA Standards for VoIP/Packet Migration i2 Solutions ou em ínterim VoIP Architecture for Enhanced 9-1-1 Services (i2) (a seguir, a solução NENA 12) , a qual está sendo considerada para suporte VoIP E911 nos Estados Unidos, ou alguma outra interface.

A arquitetura de rede 400 pode incluir outras entidades para suportar VoIP e/ou localização, por exemplo, os elementos descritos na solução NENA 12 ou soluções da minuta NENA 12.5 e 13.

1.1. Estabelecimento de Chamada

A Figura 5 mostra uma modalidade de um fluxo de mensagem 500 para estabelecimento de chamada VoIP de emergência utilizando SUPL. Para clareza, as entidades que são menos relevantes (por exemplo, rede de acesso 120, PCSCF 252, S/R 292) são omitidas da Fiqura 5, mas são incluídas nas descrições abaixo. O fluxo de mensagens 500 pode ser usado para as redes 3GPP e 3GPP2. 0 fluxo de mensagem 500 assume que o UE 110 tem um UICC ou UIM e que existe acordo de roaming entre a H-PLMN 160 e a V-PLMN 130.

Na etapa 1, o UE 110 descobre uma rede de acesso (AN) , por exemplo, uma rede de acesso 3GPP, uma rede de acesso 3GPP2, uma WLAN 802.11, etc. O UE 110 realiza qualquer conexão de baixo nível (por exemplo, associação 802.11) e conecta à rede de acesso (por exemplo, através de conexão GPRS ou procedimento AAA WLAN para 3GPP) . 0 UE 110 estabelece conectividade IP e pode descobrir um endereço de

22/76 servidor SIP local. Na descrição abaixo, P-CSCF 252 é o servidor SIP local descoberto pelo UE 110. A etapa 1 pode ser realizada de maneiras diferentes para diferentes redes e é descrita em maiores detalhes abaixo.

Na etapa 2, o UE 110 envia um REGISTRO SIP para o P-CSCF 252, o qual é o servidor SIP local descoberto na etapa 1. O REGISTRO SIP pode incluir uma indicação de serviços de emergência, um ID de usuário público de emergência (por exemplo, como descrito no 3GPP TR 23.867 e no 3GPP TS 23.167), um ID de usuário privado, um nome de dominio H-PLMN, e um endereço IP UE obtido na etapa 1. O REGISTRO SIP pode também incluir informação de localização para o UE 110, as capacidades de localização do UE 110, e/ou outra informação. As capacidades de localização do UE podem compreender as soluções de localização suportadas pelo UE 110 (por exemplo, SUPL, plano de controle 3GPP, X.S0024, etc.), os métodos de posicionamento suportados pelo UE 110, e/ou outra informação. Devido à presença da indicação de serviços de emergência ou o ID de usuário público de emergência, P-CSCF 252 envia o REGISTRO SIP para o E-CSCF 254 na mesma rede, e não para o I-CSCF 262 na HPLMN 160 como nos casos de não-emergência.

Na etapa 3, E-CSCF 254 na V-PLMN 130 envia o REGISTRO SIP para S-CSCF 264 na H-PLMN 160 onde ocorre registro IMS normal. As razões para registro na H-PLMN 160 são (1) para autenticar a identidade de usuário, (2) para obter um número de rechamada verificado de S-CSCF 264, (3) para alertar a H-PLMN 160 sobre a chamada de emergência de modo que um tratamento especial (por exemplo, prioridade, restrição de serviços suplementares) possa ser empregado se o PSAP 180 posteriormente tornar a chamar o UE 110 através da H-PLMN 160. Para registro IMS, o S-CSCF 264 na H-PLMN 160 trata o E-CSCF 254 na V-PLMN 130 como um P-CSCF. Um TEL

23/76

URI de usuário público (por exemplo, derivado de uma MSISDN no 3GPP ou uma MIN no 3GPP2) pode ser registrado implicitamente com o ID de usuário público de emergência para o UE 110 e pode ser utilizado para rechamada PSAP de uma PSTN. H-PLMN 160 pode não suportar o registro adicional do ID de usuário público de emergência, por exemplo, se o UE 110 já tiver registrado um ID de usuário público normal ou se o ID de usuário público de emergência não for suportada pela H-PLMN 160. E-CSCF 254 pode manter uma lista das H-PLMNs para as quais a etapa 3 pode ser saltada. Se a etapa 3 for saltada, a re-chamada do PSAP 180 pode ainda ser possível utilizando o ID de usuário público normal do UE 110, o qual deve ser registrado pelo UE 110 separadamente. E-CSCF 254 pode também atribuir um ID de usuário público temporário ao UE 110, como descrito abaixo, para permitir a re-chamada do PSAP 180 diretamente através da V-PLMN 130 e não através da H-PLMN 160. Este ID de usuário público temporário pode ser especialmente útil para um UE em roaming externo uma vez que tanto o retardo como a confiabilidade da rechamada podem ser aperfeiçoados. Se o registro na H-PLMN 160 não for realizado, então o UE 110 não é autenticado e uma conexão IP segura entre o UE 110 e o E-CSCF 254 na V-PLMN 130 pode não ser estabelecida, o que pode degradar a segurança para localização subsequente do UE 110 pelo E-SLP 272.

Na etapa 4, o E-CSCF 254 (por exemplo, após receber um SIP 200 OK da PLMN 160) retorna 200 OK para o UE 110. Após estabelecimento da chamada de emergência, se o UE 110 for transferido dentro da mesma V-PLMN para uma SGSN diferente (para acesso GPRS), uma WLAN diferente (para acesso WLAN), ou uma PCF diferente ou PDSN (para acesso cdma2000), então o UE 110 pode re-registrar mediante repetição das etapas 2 a 4 para atualizar a informação de

24/76 localização e V-SLP. Se o UE 110 re-registrar utilizando seu ID de usuário público de emergência, então o E-CSCF 254 pode transferir qualquer nova informação de localização para o E-SLP 272. O re-registro permite que um V-SLP diferente seja escolhido se o UE 110 tiver se deslocado para fora da área geográfica suportada pelo V-SLP anterior.

Para acesso 3GPP2 WLAN, um procedimento de handoff pode ser realizado se o UE 110 se deslocar de uma WLAN para outra WLAN ou de uma WLAN para uma rede cdma2000. O procedimento de handoff pode estabelecer um novo túnel para a PIDF anterior, da nova WLAN (para handoff de uma WLAN para outra WLAN) ou de uma nova PSDN (para handoff de uma WLAN para uma rede cdma2000) para continuar a utilizar o endereço IP associado ao PDIF anterior e para evitar disrupção para a chamada VoIP de emergência. Para handoff de uma rede cdma2000 para uma WLAN, o PDIF associado à nova WLAN pode emular uma PDSN alvo para suportar fast handoff para a PDSN de serviço anterior. Após o handoff, o UE 120 pode re-registrar para prover ao E-CSCF 254 uma nova informação de localização relevante para seleção V-SLP.

	Em	uma	modalidade	alternativa das etapas 2,	3 e
4,	após o	UE	110	enviar	um	REGISTRO SIP para o P-CSCF	252
na	etapa	2,	o	P-CSCF	252	pode enviar o REGISTRO	SIP
diretamente para	S-CSCF	264	na H-PLMN 160 ou para I-	CSCF

262 na H-PLMN 160 e ignorar o E-CSCF 254 na V-PLMN 130. Neste caso, SIP 200 OK da H-PLMN 160 seria retornado ao PCSCF 252 mais propriamente do que para o E-CSCF 254, e o PCSCF 252 retornaria 200 OK para o UE 110 na etapa 4. Esta modalidade alternativa pode reduzir ou evitar impactos especiais para P-CSCF 252 para suportar chamadas de emergência VoIP porque as ações do P-CSCF 252 são então similares a estas para o registro normal.

Na etapa 5, o UE 110 envia um CONVITE SIP para P

25/76

CSCF 252. O CONVITE SIP pode incluir um SIP URL global ou TEL URI indicando uma chamada de emergência (por exemplo, sos@local-domain ou 911 proposto pela IETF Ecrit) e o tipo de serviço de emergência solicitado. O CONVITE SIP pode também incluir informação relacionada à localização do UE, a qual está disponível para o UE 110 (por exemplo, um GPRS ou ID de célula cdma2000, um endereço WLAN AP MAC, etc.), capacidades de localização do UE 110 se não forem providos durante registro, informação de contato para rechamada, e/ou outra informação. A informação de rechamada pode incluir um TEL URI (por exemplo, derivado da 3GPP MSISDN ou 3GPP2 MDN) e possivelmente um SIP URL (por exemplo, o ID de usuário público de emergência usado na etapa 2). Um campo de cabeçalho suportado do REGISTRO SIP ou CONVITE SIP pode também ser usado para transportar as capacidades de localização do UE. As capacidades de localização podem ser também incluídas como parte da informação de localização provida pelo UE (por exemplo, no objeto IETF Geopriv pidf-lo) ou de alguma outra maneira no CONVITE SIP. P-CSCF 252 pode enviar o CONVITE SIP para outro servidor SIP, o qual pode enviar o CONVITE SIP para um proxy de roteamento (por exemplo, um Servidor de Aplicação) dedicado às chamadas de emergência. Na Figura 5, E-CSCF 254 é o servidor SIP que controla as chamadas de emergência.

Na etapa 6, E-CSCF 254 pode determinar explicitamente ou implicitamente se o UE 110 suporta SUPL e envia uma Solicitação de Roteamento (ou uma Solicitação de Localização de Emergência) para E-SLP 272. A Solicitação de Roteamento pode incluir as identidades públicas UE (por exemplo, o ID de usuário público de emergência da etapa 5, o TEL URI, etc.), qualquer informação de localização recebida pelo E-CSCF 254, e o endereço IP UE se o IP

26/76 terminado móvel (ou UDP/IP) for usado na etapa 8. E-SLP 272 pode estar na mesma rede que E-CSCF 254 ou em alguma outra rede. E-SLP 272 pode ser selecionado porque este abrange uma área geográfica que inclui uma localização aproximada do UE 110. E-CSCF 254 pode selecionar E-SLP 272, um servidor de localização genérico capaz de atuar como um ESLP, ou alguns outros tipos de servidores, por exemplo, GMLC 276. O servidor de localização selecionado pode optar por utilizar SUPL com base nas capacidades de localização do UE transferidas pelo E-CSCF 254 (ou simplesmente mediante suposição). E-CSCF 254 pode solicitar informação de localização do E-SLP 272 e/ou seleção de um PSAP correspondendo à informação de localização disponível e tipo de serviço de emergência.

E-SLP 272 prossegue para a etapa 12 se a informação de localização provida na etapa 6 possibilitar E-SLP 272 derivar uma estimativa de posição para o UE 110 que é exata o suficiente para preencher a solicitação na etapa 6 (por exemplo, determinar unicamente um PSAP de destino). Caso contrário, as etapas 7 a 11 serão realizadas para obter uma estimativa de posição adequada para o UE 110.

Na etapa 7, E-SLP 272 determina da informação de localização recebida se utiliza um V-SLP separado para auxiliar com a localização. Se sim, então um V-SLP (por exemplo, V-SLP 274) pode ser selecionado com base na informação de localização recebida do E-CSCF 254. E-SLP 272 atua como um H-SLP na realização de localização SUPL subsequente utilizando procedimentos que podem ser similares a estes usados para (a) suporte à realização de roaming SUPL 1.0 se um V-SLP foi selecionado ou (b) nãosuporte a roaming SUPL 1.0 se um V-SLP não foi selecionado. No caso de roaming, E-SLP 272 pode trocar alguma

27/76 sinalização RLP preliminar com V-SLC 422, a qual não é mostrada na Figura 5. E-SLP 272 então gera uma INICIAR SUPL para instigar um procedimento de localização iniciado pela rede com o UE 110 utilizando os modos proxy ou não-proxy em SUPL. E-SLP 272 pode enviar o INICIAR SUPL diretamente ao UE 110 utilizando IP terminado móvel ou UDP/IP, neste caso a etapa 8 pode ser saltada. E-SLP 272 pode também enviar o INICIAR SUPL dentro de uma mensagem Imediata (por exemplo, uma Mensagem Imediata IMS ou alguma outra mensagem IMS ou SIP) para E-CSCF 254. Em qualquer um dos casos, o INICIAR SUPL pode incluir um endereço IP de um SPC usado para posicionamento (o qual pode ser E-SPC 414 ou V-SPC 424 se o modo não-proxy for usado) , exigências de retardo/exatidão de qualidade de posição (QoP) para uma estimativa de posição provisória rápida, uma indicação de modo proxy/nãoproxy, dados de autenticação e/ou outra informação. O INICIAR SUPL pode também incluir um endereço IP de E-SLP 272, por exemplo, se o UE 110 não estiver em sua rede de origem, se E-SLP 272 não for o H-SLP para o UE 110, ou se E-SLP 272 foro H-SLP, mas optar por não se comportar como o H-SLP (por exemplo, para evitar suportar mais do que um procedimento para chamadas de emergência). INICIAR SUPL pode também incluir uma indicação de chamada de emergência, por exemplo, em um parâmetro de notificação INICIAR SUPL.

Na etapa 8, E-CSCF 254 envia INICIAR SUPL para o UE 110 através do P-CSCF 252 utilizando uma mensagem Imediata IMS, alguma outra mensagem IMS, uma resposta SIP Ixx (por exemplo, um Progresso de Sessão 183), ou alguma outra mensagem baseada em IP que utiliza associações IP seguras entre E-CSCF 254, P-CSCF 252 e o UE 110 estabelecido nas etapas 2 a 4.

Na etapa 9, o UE 110 estabelece uma conexão IP segura (por exemplo, TCP/IP segura) com o E/SLP 272, o qual

28/76 pode ser o H-SLP para o UE 110 ou pode ter incluído seu endereço no INICIAR SUPL enviado na etapa 7. Para o modo não-proxy, o UE 110 obtém os dados de autenticação do E-SLP 272 (não mostrado) e estabelece uma conexão IP segura com o E-SPC 414 ou V-SPC 424 com autenticação mútua. E-SLC 412 também conduz informação para o E-SPC 414 ou V-SPC 424 para o modo não-proxy (não mostrado na Figura 5). O UE 110 pode obter medições relacionadas à localização (por exemplo, níveis de sinal e/ou temporização de células vizinhas) ou uma estimativa de posição (por exemplo, utilizando GPS autônomo) consistente com o QoP recebido. O UE 110 então retorna um INICIAR POS SUPL para o E-SLP 272 (para o modo proxy) ou para o E-SPC 414 ou V-SPC 424 (para o modo nãoproxy, o qual não é mostrado na Figura 5) . INICIAR POS SUPL pode incluir um código hash usado para autenticação no modo proxy, as capacidades de posicionamento do UE, uma estimativa de posição ou uma solicitação para dados de assistência A-GPS (que também podem ser incluídos em uma mensagem POS SUPL embutida para IS-801) . INICIAR POS SUPL pode também incluir medições relacionadas à localização para auxiliar na derivação de uma estimativa de posição provisória rápida e evitar sinalização POS SUPL adicional. Para 3GPP, as medições podem compreender níveis de sinal de estações base ou pontos de acesso vizinhos, antecipação de temporização GPRS, diferença de tempo Rx-Tx WCDMA, etc. Para 3GPP2, as medições podem compreender medições relacionadas à localização relevantes para WLAN cdma2000 ou 3GPP2.

Na etapa 10, E-SLP 272, E-SPC 414 ou V-SPC 424 pode trocar mensagens POS SUPL adicionais com o UE 110 se uma estimativa de posição adequada (ou medições de localização) não foi recebida na etapa 9. Cada mensagem POS SUPL pode incluir uma mensagem de posicionamento embutida

29/76

RRLP, RRC ou IS-801. Essa troca de mensagens continua até que medições de posicionamento adequadas ou uma estimativa de posição tenha sido provida para E-SLP 272, E-SPC 414 ou V-SPC 424. Na etapa 11, TERMINAR SUPL é retornado ao UE 110 para encerrar a transação SUPL.

Na etapa 12, E-SLP 272, E-SPC 414 ou V-SPC 424 computa uma estimativa de posição provisória para o UE 110 da informação de localização recebida na etapa 9 ou na etapa 10. Para o modo não-proxy, E-SPC 414 ou V-SPC 424 transporta a estimativa de posição para E-LSC 412. Com base na estimativa de posição, e se solicitado pelo E-CSCF 254 na etapa 6, E-SLP 272 seleciona um PSAP. A descrição seguinte supõe que PSAP 180 é o PSAP selecionado. Se PSAP 180 é acessivel/capacitado para PSTN, então E-SLP 272 obtém (a) um número de diretório não-discado de Dígito de Roteamento de Serviços de Emergência (ESRD) que pode ser usado para encaminhar o PSAP 18 0 e (b) um número de diretório não-discado de Chave de Roteamento de Serviços de Emergência (ESRK) que identifica o PSAP 180, E-SLP 272 e, temporariamente, o UE 110. Cada PSAP pode ser associado a um ESRD assim como a um grupo de ESRKs que identificam ESLP 272 e este PSAP. Para cada chamada de emergência por um UE para esse PSAP, um ESRK do grupo pode ser atribuído ao UE pela duração da chamada de emergência. Algumas destas funções (por exemplo, gerenciamento ESRD/ESRK) podem não ser consideradas como parte do SUPL e pode ser suportada em uma entidade física ou lógica separada que pode ser consultada por E-SLP 272 (por exemplo, como descrito na solução NENA 12) . ESRD e ESRK correspondem aos mesmos números de diretório citados usados para suporte de chamada de emergência no modo de circuito (por exemplo, J-STD-036). ESRD e ESRK também correspondem ao ESRN e ESQK, respectivamente, descritos na solução NENA 12.

30/76

Na etapa 13, E-SLP 272 retorna para E-CSCF 254 uma Resposta de Roteamento (ou uma Resposta de Localização de Emergência) que pode incluir (a) a identidade PSAP (a qual pode ser um SIP URL ou um endereço IP) se o PSAP 180 for capacitado para IP ou (b) o ESRD e ESRK se o PSAP 180 for capacitado para PSTN. A Resposta de Roteamento pode também incluir a estimativa de posição provisória para o UE 110 se solicitado pelo E-CSCF 254. E-SLP 272 pode armazenar para o UE 110 um reqistro de chamada contendo toda a informação coletada para o UE.

As etapas 14a e 15a são realizadas se o PSAP 180 for capacitado para IP. Na etapa 14a, E-CSCF 254 encaminha o CONVITE SIP (recebido na etapa 5) para o PSAP 180. O CONVITE SIP pode incluir uma estimativa de posição provisória e possivelmente a identidade ou endereço do UE 110 e o endereço IP ou nome do E-SLP 272. Na etapa 15a, sinalização SIP adicional pode ser trocada para estabelecer a chamada de emergência.

As etapas 14b, 14c e 15b são realizadas se PSAP

180 for capacitado para PSTN. Na etapa 14b, E-CSCF 254 envia o CONVITE SIP por intermédio de uma Função de Controle de Portal de Interrupção (BGCF) para o MGCF 258. O CONVITE SIP pode incluir o número de rechamada (por exemplo, MSISDN ou MDN) para o UE 110 e/ou pode incluir o ESRD e ESRK (mas possivelmente não uma estimativa de posição provisória). Na etapa 14c, MGCF 258 encaminha a chamada de emergência para o PSAP 180 por intermédio da PSTN, possivelmente por intermédio de um roteador seletivo, utilizando SS7 ISUP e/ou sinalização MF. O ESRD ou ESRK pode ser usado como números de roteamento e o ESRK e/ou o número de rechamada são passados para o PSAP 180 (por exemplo, por intermédio de sinalização MF CAMA) como a identidade do UE 110 e como uma chave para obter mais

31/76 informação. Na etapa 15b, sinalização SIP adicional pode ser trocada e a interconexão com SS7 ISUP e/ou MF no MGCF 258 pode ocorrer para estabelecer a chamada de emergência.

O percurso de chamada para um PSAP com capacidade IP e um PSAP com capacidade PSTN é estabelecido separadamente. Para um PSAP com capacidade PSTN, interconexão entre VoIP (por exemplo, RTP/IP) e o modo de circuito (por exemplo, PCM) ocorre em um Portal de Midia (MGW) controlado pelo MGCF 258. Para um PSAP com capacidade IP, o percurso de chamada seria IP de extremo-a-extremo e seguiría entre o UE 110 e o PSAP 180, possivelmente e parcialmente por intermédio da Internet pública ou uma rede IP privada, porém saltaria qualquer MGW.

Na etapa 16, após a chamada ser estabelecida, o PSAP 180 pode enviar uma Solicitação de Localização para o E-SLP 272, a qual pode ser identificada por um endereço ou nome IP obtido na etapa 14a ou um ESRK obtido na etapa 14c. PSAP 180 identifica o UE 110 utilizando o endereço de usuário público do UE (se o PSAP 180 for capacitado para IP) ou um número de rechamada ou outro endereço (por exemplo, MSISDN ou MDN) ou ESRK (se o PSAP 180 for capacitado para PSTN). A Solicitação de Localização indica uma exiqência para uma estimativa de posição exata. Para uma chamada VoIP de emergência nos Estados Unidos, a Solicitação de Localização pode ser idêntica a uma Solicitação de Posição de Serviço de Emergência no J-STD036 se o PSAP 180 for capacitado para PSTN e pode ser uma extensão para essa mensagem se PSAP 180 for capacitado para IP. Para uma chamada VoIP de emergência em algumas outras regiões do mundo, a Solicitação de Localização pode ser idêntica a uma Solicitação Imediata de Localização de Emergência definida para OMA MLP.

Na etapa 17, E-SLP 272 pode selecionar um V-SLP

32/76 se as capacidades de localização do E-SLP 272 não estender até a área geográfica onde a última posição conhecida do UE 110 foi informada ou se utilizando V-SLP puder prover localização mais exata e confiável. E-SLP 272 pode derivar um endereço V-SLP da posição mais recente do UE 110 e/ou do endereço V-SLP mais recente provido pelo E-CSCF 254. Para garantir o V-SLP correto, o E-SLP 272 pode consultar a localização do UE 110 e/ou o endereço V-SLP do E-CSCF 254 (não mostrado na Figura 5) se o E-CSCF 254 não transferir automaticamente essa informação após qualquer re-registro do UE 110 na etapa 4. E-SLP 272 pode então abrir uma nova transação SUPL com o UE 110 mediante envio de um INICIAR SUPL diretamente para o UE utilizando IP terminado móvel ou UDP-IP (em cujo caso a etapa 18 pode ser saltada) ou mediante envio de uma mensagem Imediata contendo o INICIAR SUPL para o E-CSCF 254. INICIAR SUPL pode incluir os parâmetros descritos acima para a etapa 7.

Na etapa 18, E-CSCF 254 transfere para o UE 110 o INICIAR SUPL dentro de uma mensagem Imediata IMS, alguma outra mensagem IMS, uma mensagem SIP (por exemplo, uma reCONVITE), ou alguma outra mensagem baseada em IP que utiliza as associações IP seguras entre E-CSCF 254, P-CSCF 252 e UE 110.

Na etapa 19, UE 110 estabelece uma conexão IP segura com E-SLP 272. 0 UE 110 pode então trocar as mensagens SUPL com E-SLP 272 para o modo proxy ou com o ESPC 414 ou V-SPC 424 para o modo não-proxy (similar às etapas 9, 10 e 11) para obter uma estimativa de posição exata para o UE.

Na etapa 20, E-SLP 272 envia a estimativa de posição exata para o UE 110 em uma Resposta de Localização para PSAP 180. Para uma chamada de emergência nos Estados Unidos, a Resposta de Localização pode ser idêntica a uma

33/76 mensagem de Resposta de Posição de Serviços de Emergência em J-STD-036 para a interface E2 se PSAP 180 for capacitado para PSTN (e desse modo pode incluir informação adicional tal como a MSISDN do UE 110). Para uma chamada de emergência em algumas outras regiões do mundo, a Resposta de Localização pode ser idêntica a uma Resposta Imediata de Localização de Emergência definida para OMA MLP.

O UE 110 pode então comunicar com o PSAP 180 para a chamada VoIP de emergência. Quando a chamada é posteriormente liberada, E-CSCF 254 pode enviar uma indicação para E-CLP 272, o qual pode então liberar qualquer registro da chamada. E-CSCF 254 ou o UE 110 pode também cancelar o registro do ID de usuário público de emergência, o qual foi registrado nas etapas 2 a 4. Alternativamente, E-CSCF 254, E-SLP 272 e o UE 110 podem permitir que o registro e as gravações de chamada persistam por algum período de tempo para suportar possível rechamada posterior do PSAP 180 para o UE 110 e/ou solicitações adicionais de localização.

1.2 Acesso

Para a etapa 1, o UE 110 pode conectar a uma rede de acesso através do acesso GPRS, acesso cdma2000 ou acesso WLAN. Etapa 1 pode ser realizada de diferentes maneiras para diferentes tipos de acesso.

Para acesso GPRS, o UE 110 pode realizar o acoplamento GPRS para acoplar a uma rede de acesso 3GPP e pode realizar ativação de contexto de Protocolo de Dados de Pacote GPRS (PDP) para estabelecer conectividade IP no SGSN 232a e GGSN 232b, como descrito no 3GPP TR 23.867 e TS 23.060. Uma indicação de emergência pode ser usada no acoplamento GPRS e/ou um Nome de Ponto de Acesso global (APN) para serviços de emergência pode ser usado para

34/76 ativação de contexto PDP, o que pode garantir provisão de uma GGSN e de um P-CSCF na V-PLMN 130. P-CSCF 252 pode ser um P-CSCF em um GPRS PLMN de serviço como provido durante ativação de contexto PDP.

Para acesso 3GPP WLAN, o UE 110 pode realizar um procedimento AAA WLAN para anexar a uma WLAN e pode realizar estabelecimento de túnel I-WLAN para conectividade IP para PDG 236. 0 UE 110 pode selecionar o serviço da ν'PLMN 130 mediante uso de um Identificador de Acesso de Rede (ΝΆΙ) em roaming que indica ambos, H-PLMN 160 e V-PLMN 130 na solicitação para autenticação e autorização. O NAI em roaming é descrito no 3GPP TS 23.234 e TS 23.003. Isso garante que o UE 110 possa obter o acesso IP para serviços IMS do PDG 236 na V-PLMN 130 mais propriamente do que a partir de um PDG na H-PLMN 160 (o qual pode limitar o acesso PSAP se H-PLMN 17 0 estiver remoto) . Um ΆΡΝ WLAN global (W-APN) para serviços de emergência pode ser usado para descoberta PDG e estabelecimento de túnel. Este serviço pode usar um identificador de rede externo único global (para suportar serviços de emergência) e a identidade V-PLMN. P-CSCF 252 pode ser um P-CSCF em uma VPLMN associada a uma WLAN e pode ser descoberto através de uma consulta DNS na W-APN.

Para acesso cdma2000, o UE 110 obtém um endereço IP único mais propriamente do que um endereço IP móvel, uma vez que o serviço é obtido da V-PLMN 130 e não da H-PLMN 160. Alternativamente, o UE 110 pode obter um endereço IP móvel da V-PLMN 130 mais propriamente do que da H-PLMN 160 como é mais normal para um endereço IP móvel. Um endereço IP pode ser um endereço IPv4 ou um endereço IPv6. Se o UE 110 não tiver estabelecido conectividade (por exemplo, não tiver um endereço IP atribuído), então o UE 110 pode estabelecer uma sessão de Protocolo Ponto-a-Ponto (PTP) e

35/76 realizar qualquer autenticação e autorização com PDSN 242 na V-PLMN 130, como descrito no 3GPP2 X.P0011D e TIA-835-D. O UE 110 pode obter um endereço IP único, por exemplo, utilizando o Protocolo de Controle de Protocolo Internet PPP (IPCP). Se o UE 110 já tiver estabelecido conectividade IP e tiver uma sessão PPP para PDSN 242, mas for atribuído endereço(s) IP móvel na H-PLMN 160 em vez de endereço(s) IP único, então o UE 110 pode terminar quaisquer sessões de pacote associadas a estes endereços IP assim como qualquer registro IMS se o UE 110 não puder suportar endereços IP únicos e endereços IP móveis simultâneos, que é uma capacidade opcional, porém uma capacidade UE não obrigatória no TIA-835d. 0 UE 110 pode então obter um endereço IP único como descrito no TIA-835d. Se o UE 110 puder suportar endereços IP únicos e móveis simultâneos, então o UE 110 pode apenas obter um endereço IP único se ele já não tiver um deles.

Para acesso cdma2000, o UE 110 pode descobrir um endereço P-CSCF na V-PLMN 130 mediante (a) uso de DHCP ou IPCP para obter um nome de domínio P-CSCF e um endereço DNS do servidor DHCP ou PDSN 242 e então (b) utilizar DNS para obter um ou mais endereços IP P-CSCF do servidor DNS. Se o UE 110 move e acessa uma nova RAN, então V-PLMN 130 e o UE 110 podem empregar um procedimento de fast handoff descrito no TIA-835-D se uma nova PDSN alvo for necessária e uma chamada VoIP de emergência já estiver estabelecida. Isto evita a necessidade de terminar e restabelecer a chamada.

Para acesso 3GPP2 WLAN, o UE 110 pode realizar procedimento de acesso WLAN existente incluindo AAA, aquisição de endereço IP, e diretório de um roteador IP padrão e endereço de servidor DNS (por exemplo, através do DHCP). O UE 110 pode então acessar uma PDIF em uma PLMN que suporta chamadas de emergência da localização geográfica da

36/76

WLAN acessada pelo UE 110. A WLAN pode avisar redes cdma2000 associadas de tal modo que as PLMNs de suporte de chamada de emergência possam ser distinguidas. Este aviso pode ser alcançado, por exemplo, mediante envio de Identificadores de Conjunto de Serviços associados (SSIDs) em quadros de sinalização IEEE 802.11 ou através de respostas aos quadros de solicitação de sondagem do UE. As PLMNs podem ser priorizadas pela ordem na qual elas são avisadas, através do uso de um indicador para cada PLMN avisada, ou ao assegurar (por exemplo, exigir) que todas as PLMNs avisadas suportem chamadas de emergência. Para acesso inicial de WLAN, ΆΆΆ, e aquisição de endereço IP, o UE 110 pode escolher uma PLMN (por exemplo, um SSID) que é implícito ou indicado para suportar chamadas de emergência.

Após acesso WLAN inicial, AAA, aquisição de endereço IP, e descoberta de um roteador default e endereço de servidor DNS, o UE 110 pode criar um nome de domínio totalmente qualificado (FQDN) que indica o serviço IMS e utiliza um domínio associado a uma das PLMNs anunciadas pela WLAN que suporta chamadas de emergência. O UE 110 pode então usar a FQDN para descobrir o endereço(s) IP de uma ou mais PDIFs do servidor DNS. O UE pode escolher um PDIF e estabelecer um túnel IPsec a este utilizando o procedimento descrito no 3GPP2 X.S0028-200. Isto proporciona ao UE 110 um segundo endereço IP interno, o qual pode ser usado para procedimentos relacionados a IMS subsequentes.

Após estabelecimento de túnel para um PDIF de uma WLAN, o UE 110 pode descobrir um endereço P-CSCF da mesma forma como um UE acessando uma PDSN de uma rede de acesso cdma2000 (por exemplo, através de DHCP para obter um endereço de servidor DNS e um nome de domínio e então através do DNS para obter o endereço IP P-CSCF) . Neste caso, o PDIF pode atuar como um agente de retransmissão

37/76

DHCP em vez da PDSN. A descoberta do PIDF e dos endereços P-CSCF através do DNS pode incluir uma indicação (por exemplo, no nome provido ao servidor DNS) que suporte a chamada de emergência é necessário.

Se o UE 110 já tem uma associação (por exemplo, um túnel) a um PDIF em uma PLMN inadequada e se o UE 110 não suporta túneis para diferentes PDIFs simultaneamente, então o UE 110 pode liberar quaisquer sessões de pacote suportadas através do PDIF atual e liberar o túnel para o PDIF antes de selecionar e estabelecer um túnel para um novo PDIF em uma nova PLMN adequada.

Após conexão de rede de acesso WLAN ou cdma2000, o UE 110 pode descobrir um endereço SUPL V-SLP utilizando uma consulta DNS com um nome de domínio V-PLMN conhecido e identificação V-SLP (por exemplo, supl_vslp@domain_name).

O fluxo de mensagens 500 tem as seguintes adições de recursos relacionadas à versão 1.0 OMA SUPL.

(a) Adição de um endereço E-SLP em INICIAR SUPL, que sobrescreve e substitui um endereço H-SLP configurado no UE 110.

(b) Interface entre o lado IMS (por exemplo, E-CSCF 254) e o lado de localização (por exemplo, E-SLP 272) .

(c) Uso de V-SLP 274 e descoberta do endereço V-SLP.

(d) Transporte de um SUPL utilizando sinalização SIP ou IMS, UDP-IP, IP terminado móvel, em vez de SMS

	ou Push WAP, para	reduzir	retardo.
(e)	Adição de uma indicação de	: serviços	de emergência
	no INICIAR SUPL.
(f)	Preferência para	adição	de novas	medições de
	localização em um	INICIAR	POS SUPL.
(g)	Uso do protocolo	ILP entre E-CSCF	254 e E-SLP

38/76

272, que pode ser similar ao RLP existente.

(h) Segurança.

Chamada VoIP de

com Plano de

Controle 3GPP

A Figura 6 mostra um diagrama em blocos de uma modalidade de uma arquitetura de rede 600 aplicável para localização de plano de controle 3GPP. Para simplicidade, a Figura 6 mostra apenas as entidades e interfaces relevantes para suporte de chamadas VoIP de emergência com localização de plano de controle 3GPP e acesso GPRS.

A rede de acesso 12 0 pode ser uma GERAN ou uma UTRAN. V-PLMN 130 pode incluir P-CSCF 252, E-CSCF 254 e MGCF 258 para suportar IMS (por exemplo, VoIP), SGSN/GGSN 232 para serviços comutados por pacote, e GMLC 27 6 para serviços de localização. GMLC 276 substitui E-SLP 272 e é uma versão aperfeiçoada do GMLC descrito no 3GPP 23.271, Edição 6. V-PLMN 130 pode incluir também E-SLP 272 e V-SLP 274 para serviços de localização (não mostrados na Figura 6) .

Em uma modalidade, GMLC 27 6 comunica com E-CSCF 254 através da interface Li e comunica com PSAP 180 através da interface J-STD-036 E2' . O uso da mesma interface Li para GMLC 276 e E-SLP 272 pode ocultar diferenças de arquitetura de localização entre o plano de controle 3GPP e SUPL do E-CSCF 254. Similarmente, o uso da mesma interface J-STD-036 E2' para GMLC 276 e E-SLP 272 pode ocultar diferenças de arquitetura de localização do PSAP 180. As outras interfaces na Figura 6 são conhecidas na técnica.

2.1. Estabelecimento de Chamada

A Figura 7 mostra uma modalidade de um fluxo de

39/76 mensagem 700 para estabelecimento de chamada VoIP de emergência utilizando plano de controle 3GPP. Para clareza, as entidades que são menos relevantes (por exemplo, redes de acesso 120, P-CSCF 252, S/R 292) são omitidas da Figura 7, mas são incluídas na descrição abaixo. O fluxo de mensagens 700 supõe que o UE 110 tem um UICC e que existe um acordo de roaming entre a H-PLMN 160 e V-PLMN 130.

Na etapa 1, o UE 110 realiza o acoplamento GPRS com uma indicação de serviços de emergência, se o UE ainda não for GPRS acoplado. O acoplamento GPRS pode requerer a obtenção de acesso a SGSN 232a, realizando qualquer autenticação e transferência de dados de assinatura do HLR/HSS 266 na H-PLMN 160 para SGSN 232a, e assim por diante. Na etapa 2, o UE 110 realiza ativação de contexto PDP utilizando a APN global para serviços de emergência. O contexto PDP é atribuído a um GGSN local na V-PLMN 130 (por exemplo, e não a um GGSN na H-PLMN 160). O UE 110 obtém um endereço IP e pode descobrir um endereço de servidor SIP local (por exemplo, P-CSCF 252) durante ativação de contexto PDP.

Na etapa 3, SGSN 232 toma conhecimento da iniciação de uma chamada de emergência com base na indicação de emergência na etapa 1 ou a APN global para serviços de emergência na etapa 2. SGSN 232a pode então iniciar uma Solicitação de Localização Induzida por Rede Comutada por Pacotes (PS-NI-LR) descrita no 3GPP TS 23.271 para obter uma estimativa de posição provisória ou uma estimativa de posição mais exata para o UE 110. A PS-NI-LR provê uma resposta mais rápida do que se SGSN 232 esperasse por uma solicitação para obter a estimativa de posição (por exemplo, através de um MAP PSL na etapa 17) do GMLC 276. A PS-NI-LR pode ser realizada por um SGSN inicial. Se o UE 110 for transferido para um novo SGSN, então o novo SGSN

40/76 não necessita realizar outra PS-NI-RL. Na etapa 4, quando uma estimativa de posição para o UE 110 é obtida, SGSN 232 pode determinar um endereço GMLC (por exemplo, do ID de célula atual) e pode enviar para GMLC 276 um Relatório de Localização de Assinante MAP (SLR) contendo a estimativa de posição, a identidade UE, e/ou outra informação. A identidade UE pode ser uma Identidade de Assinante Móvel Internacional (IMSI), um número ISDN de Assinante Móvel (MSISDN), uma Identidade de Equipamento Móvel Internacional (IMEI), um Número Serial Eletrônico (ESN), um Identificador de Equipamento Móvel (MEID), ou alguma outra identidade. Se a etapa 4 for realizada, então as etapas 10 e 11 podem ser saltadas.

Na etapa 5, o UE 110 envia um REGISTRO SIP para o P-CSCF 252, o qual foi descoberto na etapa 2. O REGISTRO SIP pode incluir a informação descrita acima para a etapa 2 na Figura 5 e pode incluir também o endereço SGSN se as etapas 10 e 11 forem realizadas. Devido à presença da indicação de serviços de emergência ou do ID de usuário público de emergência, o P-CSCF 252 envia o REGISTRO SIP para o E-CSCF 254 na mesma rede. A etapa 5 pode ser executada em paralelo com a etapa 3. Na etapa 6, E-CSCF 254 envia o REGISTRO SIP para H-PLMN 160 onde ocorre registro IMS normal, similar à etapa 3 na Figura 5.

Na etapa 7, após H-PLMN 160 retornar 200 OK para E-CSCF 254, 200 OK é retornado para o UE 110. O UE 110 também pode re-registrar se houver um handoff para um SGSN diferente dentro da V-PLMN 130. Se o UE 110 re-registrar utilizando seu ID de usuário público de emergência, E-CSCF 254 pode transferir qualquer nova informação de localização e/ou qualquer novo endereço SGSN para GMLC 276.

Como na Figura 5, em uma modalidade alternativa das etapas 5, 6 e 7, após o UE 110 enviar um REGISTRO SIP

41/76 para P-CSCF 252 na etapa 5, P-CSCF 252 pode enviar o REGISTRO SIP diretamente para S-CSCF 264 ou I-CSCF 262 na H-PLMN 160 e ignorar o E-CSCF 254 na V-PLMN 130. Neste caso, um SIP 200 OK da H-PLMN 160 seria retornado para PCSCF 252 mais propriamente do que para E-CSCF 254, e P-CSCF 252 retornaria o 200 OK para o UE 110 na etapa 7. Esta modalidade alternativa pode reduzir ou evitar impactos especiais para P-CSCF 252 para suportar chamadas de emergência VoIP porque as ações de P-CSCF 252 são então similares a estas para o registro normal.

Na etapa 8, o UE 110 envia para P-CSCF 252 um CONVITE SIP que pode incluir a informação descrita acima para a etapa 5 na Figura 5. P-CSCF 252 envia o CONVITE SIP para E-CSCF 254.

Na etapa 9, com base no suporte UE do plano de controle 3GPP pra o modo de pacote, E-CSCF 254 envia uma Solicitação de Roteamento para GMLC 276 indicada pela célula de serviço ou outra informação de localização recebida na etapa 8. A Solicitação de Roteamento pode incluir a informação descrita na etapa 6 da Figura 5 assim como o endereço SGSN se provido durante registro. E-CSCF 254 pode selecionar GMLC 276, um servidor de localização genérico capaz de atuar como um GMLC, ou alguns outros tipos de servidor (por exemplo, um SLP) . O servidor de localização selecionado pode optar por usar o plano de controle 3GPP com base nas capacidades de localização do UE transferidas pelo E-CSCF 254. E-CSCF 254 pode solicitar informação de localização do GMLC 27 6 e/ou selecionar um PSAP correspondendo à informação de localização disponível e o tipo de serviço de emergência sendo solicitado.

GMLC 27 6 prossegue para a etapa 12 se a informação de localização provida na etapa 9 permite ao GMLC 27 6 derivar uma estimativa de posição para o UE 110

42/76 que é exata o suficiente para atender à solicitação na etapa 9. GMLC 276 pode também esperar até receber o MAP SLR do SGSN 232 na etapa 4 e, se uma estimativa de posição adequada for obtida, prossequir para a etapa 12. Caso contrário, as etapas 10 e 11 são executadas para obter uma estimativa de posição adequada para o UE 110.

Na etapa 10, GMLC 276 envia para o SGSN 232 Prover Localização de Assinante (PSL) MAP contendo exatidão/retardo QoP para uma estimativa de posição provisória rápida. Se a etapa 4 não for realizada, então o GMLC 27 6 pode determinar o SGSN 232 de qualquer endereço explicito ou informação de localização (por exemplo, ID de célula) recebida na etapa 9. Se nenhuma informação foi recebida ou se o SGSN inicialmente escolhido está incorreto (resposta de erro recebida na etapa 11), então o GMLC 276 pode consultar um HSS indicado pelo IMSI UE ou pseudo IMSI ou MSISDN para obter o endereço SGSN. Na etapa 11, SGSN 232 pode retornar uma estimativa de posição obtida na etapa 3, esperar até a etapa 3 estar concluída e então retornar à estimativa de posição, ou obter uma estimativa de posição da RAN e então retornar a estimativa de posição para GMLC 276.

Na etapa 12, GMLC 276 seleciona um PSAP com base na estimativa de posição. A descrição a seguir supõe que o PSAP 180 é o PSAP selecionado. Se o PSAP 180 for capacitado para PSTN, então o GMLC 27 6 obtém um número de diretório não-discado ESRD que pode ser usado para encaminhar para PSAP 180 e um número de diretório não-discado ESRK que identifica o PSAP 180, GMLC 276 e, temporariamente, o UE 110.

Na etapa 13, GMLC 276 retorna para E-CSCF 254 uma Resposta de Roteamento que pode incluir a informação descrita acima para a etapa 13 na Figura 5. Na etapa 14, a

43/76 chamada de emergência é enviada para o PSAP 18 0, como descrito para as etapas 14a, 14b e 14c na Figura 5. Na etapa 15, o restante do estabelecimento de chamada de emergência prossegue como descrito para as etapas 15a e 15b na Figura 5. Na etapa 16, o PSAP 180 envia uma solicitação de localização para GMLC 276, o qual é indicado na etapa 14 por um endereço/nome IP ou um ESRK, como descrito para etapa 16 na Figura 5.

Na etapa 17, o GMLC 276 envia um MAP PSL para o SGSN 232 solicitando uma localização exata. GMLC 27 6 pode obter o endereço SGSN da informação de localização mais recente para o UE 110 ou de uma atualização do endereço SGSN do E-CSCF 254. GMLC 27 6 pode também consultar o endereço SGSN do E-CSCF 254 se este endereço for recebido nas mensagens re-REGISTRO, mas não transferido. GMLC 276 também pode consultar o endereço SGSN do HSS indicado pelo IMSI do UE ou pseudo IMSI ou MSISDN. Na etapa 18, SGSN 232 instiga o posicionamento do UE 110 pela RAN. Na etapa 19, SGSN 232 retorna à estimativa de posição para GMLC 276. Na etapa 20, GMLC 276 retorna a estimativa de posição para PSAP 180, como descrito para a etapa 20 na Figura 5.

O UE 110 pode a seguir comunicar com PSAP 180 para a chamada VoIP de emergência. Quando a chamada é posteriormente liberada, E-CSCF 254 pode enviar uma indicação para GMLC 276, a qual pode então liberar qualquer registro da chamada. E-CSCF 254 ou UE 110 também pode cancelar o registro do ID de usuário público de emergência, o qual é registrado nas etapas 5 a 7. Alternativamente, ECSCF 224, GMLC 276 e o UE 110 podem permitir que o registro e as gravações de chamada persistam por algum período de tempo para suportar possível rechamada posterior do PSAP 180 para o UE 110 e/ou solicitações de localização adicionais.

44/76

O fluxo de mensagens 700 realiza estabelecimento de chamada e localização para o UE 110 de maneira coordenada e tem as características a seguir.

(a) SGSN 232 pode obter a localização do UE e empurrar este para GMLC 276 sempre que o contexto PDP for ativado e/ou se solicitado por GMLC 276.

(b) GMLC 276 pode receber um endereço SIP-URI público para o UE 110 do E-CSCF 254.

(c) Se PSAP 180 é habilitado para PSTN, GMLC 2726 e E-CSCF 254 podem transferir para PSAP 180 a informação (por exemplo, um ESRK de 10 dígitos) usada para identificar ambos, a chamada e o GLMC 276. Essa informação permite que o PSAP 180 extraia a localização e outra informação (por exemplo, MSISDN, SIP URI) do GMLC 276.

(d) A interface Li entre o E-CSCF 254 e o servidor de localização (por exemplo, E-SLP 272) pode ser usada para suportar chamadas de emergência de uma I-WLAN quando SUPL é usado como o método de posição. 0 uso da mesma interface Li para UMTS, GPRS e I-WLAN permite que IMS (por exemplo, E-CSCF 254) opere sem ter que tomar conhecimento da solução de localização, o que pode simplificar o controle IMS.

(e) Se o UE 110 não suporta localização pela RAN (por exemplo, suporta SUPL, mas não o plano de controle 3GPP) então o SGSN 232 pode saltar a PNI-LR.

(f) PSAP 180 pode ter exigências de localização específicas que podem não ser conhecidas do SGSN 232, por exemplo, exatidão específica ou até mesmo nenhum suporte para coordenadas de localização (por exemplo, se PSAP 180 suporta

45/76

Ε911 fase 0 ou 1). Tais exigências são suportadas no GMLC 276 para chamadas de emergência comutadas por circuito.

A interface Li pode ser usada para obter as características relacionadas acima. Suporte da interface Li externamente pode não ser necessário se as funções E-CSCF e GMLC forem suportadas pela mesma plataforma. A interface Li pode ser estendida para utilização entre qualquer entidade IMS e o GMLC para suportar outras características associadas aos serviços baseados em IP e IMS, como descrito acima para SUPL.

SGSN 232 pode ser selecionada com base em uma estimativa de posição provisória (por exemplo, célula de serviço) para o UE 110. GMLC 276 pode ser selecionado pelo E-CSCF 254 com base na mesma estimativa de posição provisória. A estimativa de posição provisória pode ser empurrada do SGSN 232 para GMLC 276 ou puxada pelo GMLC 276 do SGSN 232. Uma entidade pode determinar a outra entidade como a seguir.

SGSN	232 pode	empurrar a estimativa	de posição
provisória	para GMLC	276. SGSN 232 pode	obter essa
estimativa	de	posição	provisória através dc	> PS-NI-LR,
determinar	um	endereço	GMLC de acordo com a	localização
atual do	UE	(por exemplo, ID de célula	atual), e

enviar/empurrar a estimativa de posição para GMLC 276 utilizando um Relatório de Localização de Assinante MAP (SLR). E-CSCF 254 pode consultar GMLC 276 para um endereço PSAP para encaminhar a chamada de emergência. GMLC 276 pode

esperar (se necessário)	pelo	MAP	SLR do SGSN	232 para
determinar o endereço	PSAP	da	estimativa de	posição
provisória.

GMLC 276 pode extrair a estimativa de posição

46/76 provisória do SGSN 232. SGSN 232 pode ainda realizar a PSNI-LR, mas não enviaria a estimativa de posição para GMLC 276 até que o GMLC consulte a estimativa de posição através de uma solicitação ΜΆΡ PSL. GMLC 27 6 pode determinar o endereço SGSN utilizando um dos a seguir.

(a) GMLC 276 consulta o endereço SGSN do HSS 266 na H-PLMN 160 (se o UE 180 tem UICC e roaming suportado na V-PLMN 130) ou HSS 250 na V-PLMN 130 (se o UE 18 0 não tem UICC ou nenhum acordo de roaming na V-PLMN 130) .

(b) O UE 110 inclui o endereço SGSN atual ou informação de localização (por exemplo, um ID de célula GPRS) do qual o endereço SGSN pode ser derivado em cada mensagem REGISTRO e re-REGISTRO enviada para o IMS ou em cada mensagem CONVITE SIP enviada para IMS para uma chamada de emergência. E-CSCF 254 então transfere o endereço SGSN ou informação de localização para GMLC 276.

O UE 110 re-registra no IMS após qualquer handover inter-SGSN.

3. Chamada VoIP de Emergência com X.S0024

A Figura 8 mostra um diagrama em blocos de uma modalidade de uma arquitetura de rede 800 aplicável para localização X.S0024 para redes cdma2000. A rede de acesso 120 pode compreender uma rede CDMA2000 lx, uma rede CDMA2000 lxEV-DO, WLAN 3GPP2, e assim por diante. V-PLMN 130 pode incluir P-CSCF 252, E-CSCF 254 e MGCF 258 para suportar IMS (por exemplo, VoIP) e PDSN 242 para serviços comutados por pacote (não mostrados). V-PLMN 130 pode incluir E-PS 282 e V-PS/PDE 284 (como mostrado) e pode incluir também E-SLP 272 e V-SLP 274 (não mostrado) para

47/76 serviços de localização. E-PS 282 substitui um H-PS em termos de localização de chamadas de emergência. E-PS 282 e V-PS/PDE 284 podem residir em outras redes.

Em uma modalidade, o UE 110 comunica com E-PS 282 através de uma interface LCS-x e comunica com V-PS/PDE 284 por intermédio de uma interface LCS-y. E-PS 282 comunica com V-PS/PDE 284 por intermédio de uma interface LCS-z, comunica com E-CSCF 254 por intermédio de uma interface LCS-i, e comunica com PSAP 180 por intermédio da interface J-STD-036 E2'. A interface LCS-i pode ser similar a RLP ou Li/ILP para SUPL, a interface v2 na solução NENA 12, ou alguma outra interface. O protocolo para a interface LCS-i pode ser ILP usado para SUPL. As interfaces LCS-x, LCS-y e LCS-z são descritas no X.S0024.

3.1. Estabelecimento de Chamada

A Figura 9 mostra uma modalidade de um fluxo de mensagem 900 para estabelecimento de chamada VoIP de emergência utilizando X.S0024. Na etapa 1, o UE 110 descobre e conecta a uma rede de acesso, estabelece conectividade IP, e pode descobrir um servidor SIP local (por exemplo, P-CSCF 252), como descrito acima para a etapa 1 na Figura 5. Após conexão de rede de acesso, o UE 110 pode descobrir um endereço V-PS utilizando uma consulta DNS com um nome de domínio V-PLMN conhecido e identificação VPS (por exemplo, xs0024_vps@domain_name).

Na etapa 2, o UE 110 envia um REGISTRO SIP para P-CSCF 252, que envia a mensagem para E-CSCF 254. Na etapa 3, E-CSCF 254 envia o REGISTRO SIP para H-PLMN 160 onde ocorre o registro IMS normal. Na etapa 4, E-CSCF 254 (por exemplo, após receber um 200 OK da H-PLMN 160) retorna 200 OK ao UE 110. O UE 110 pode re-registrar se transferido para um PCF diferente, PDSN ou WLAN dentro da mesma V-PLMN.

48/76

Em uma modalidade alternativa das etapas 2, 3 e 4, após o UE 110 enviar um REGISTRO SIP para P-CSCF 252 na etapa 2, P-CSCF 252 pode enviar o REGISTRO SIP diretamente para S-CSCF 264 ou I-CSCF 262 na H-PLMN 160 e ignorar ECSCF 254 na V-PLMN 130. Neste caso, um SIP 200 OK da H-PLMN 160 seria retornado para P-CSCF 252 mais propriamente do que para E-CSCF 254, e P-CSCF 252 retornaria 200 OK para o UE 110 na etapa 4. Esta modalidade alternativa pode reduzir ou evitar impactos especiais para P-CSCF 252 para suportar chamadas de emergência VoIP porque as ações de P-CSCF 252 são então similares a estas do registro normal.

Na etapa 5, o UE 110 envia um CONVITE SIP para PCSCF 252 (não mostrado) , o qual envia o CONVITE SIP para ECSCF 254. Na etapa 6, E-CSCF 254 pode determinar se o UE 110 suporta X.S0024 e envia uma Solicitação de Roteamento para E-PS 282 na mesma rede ou em rede diferente. A Solicitação de Roteamento pode incluir a informação descrita acima para a etapa 6 na^!Figura 5 e o endereço V-PS é obtido durante registro.

E-PS 282 prossegue para a etapa 12 se a informação de localização provida na etapa 6 permite ao EPS 282 derivar uma estimativa de posição suficientemente exata para o UE 110. Caso contrário, as etapas 7 a 11 são realizadas para obter uma estimativa de posição adequada para o UE 110. Na etapa 7, E-PS 282 atua como um H-PS na realização de localização X.S0024 subseqüente utilizando procedimentos similares a estes para (a) suporte de roaming X.S0024 se um V-PS foi selecionado ou (b) não-suporta roaming X.S0024 se um V-PS não foi selecionado. E-PS 282 gera um X.S0024 INICIAR SUPL para instigar um procedimento de localização iniciado pela rede com o UE 110. E-PS 282 pode enviar o INICIAR SUPL diretamente para o UE 110 utilizando IP terminado móvel ou UDP/IP, em cujo caso a

49/76 etapa 8 é saltada. E-PS 282 pode também enviar o INICIAR SUPL dentro de uma mensagem Imediata para E-CSCF 254. Em qualquer um dos casos, INICIAR SUPL pode incluir o modo de posicionamento, exatidão/retardo QoP para uma estimativa de posição provisória rápida, um endereço IP E-PS, uma indicação de chamada de emergência, e assim por diante. Qualquer endereço E-PS conduzido no INICIAR SUPL sobrescreve qualquer endereço H-PS configurado no UE 110.

Na etapa 8, E-CSCF 254 envia o INICIAR SUPL para o UE 110 através do P-CSCF 252 utilizando sinalização SIP ou IMS. Na etapa 9, o UE 110 estabelece uma conexão IP segura com E-PS 282, o qual pode ser o H-PS para o UE 110 ou pode ter incluido seu endereço IP no INICIAR SUPL na etapa 7. 0 UE 110 também envia ao E-PS 110 um COMEÇAR SUPL que pode incluir as capacidades de localização do UE, informação de localização para o UE 110, uma estimativa de posição para o UE 110 (se disponível), e assim por diante. O E-PS 282 pode prosseguir para a etapa 12 e terminar a transação de localização com o UE 110 mediante envio de um TERMINAR SUPL se uma estimativa de posição com exatidão suficiente para determinar um PSAP for recebida do UE 110 na etapa 9.

Na etapa 10, E-PS 282 determina um PDE local adequado ou um V-PS remoto adequado para realizar posicionamento com base na informação de localização recebida na etapa 9 ou outra informação de localização recebida na etapa 6. E-PS 282 também decide se usa o modo proxy ou não-proxy. E-PS 282 então interage com o V-PS ou PDE para posicionamento e envia para o UE 110 uma RESPOSTA SUPL X.S0024 que pode incluir um endereço IP PDE se o modo não-proxy for selecionado. Na etapa 11, o UE 110 troca mensagens POS SUPL com o PDE para o modo não-proxy ou com E-PS 282 para o modo proxy para continuar e completar o

50/76 posicionamento como descrito no 3GPP2 X.S0024-0. As mensagens POS SUPL podem carregar mensagens IS-801 embutidas. O posicionamento provê uma estimativa de posição para o UE 110, o qual é passado para E-PS 282.

Na etapa 12, E-PS 282 seleciona um PSAP (por exemplo, PSAP 180) e obtém um ESRD e um ESRK se PSAP 180 estiver capacitado para PSTN. Na etapa 13, E-PS 282 retorna para E-CSCF 254 uma Resposta de Roteamento que pode incluir uma identidade PSAP se PSAP 180 for capacitado para IP, o ESRD e ESRK se PSAP 180 for capacitado para PSTN, e uma estimativa de posição para o UE 110 se solicitado por ECSCF 254. E-PS 282 pode armazenar para o UE 110 uma gravação de chamada contendo toda a informação coletada para o UE. As etapas 14a e 15a são realizadas se o PSAP 180 for habilitado para IP. As etapas 14b, 14c e 15b são realizadas se PSAP 180 for capacitado para PSTN. Na etapa 16, após a chamada ser estabelecida, o PSAP 180 pode enviar uma Solicitação de Localização para uma estimativa de posição exata para o E-PS 282, o qual pode ser identificado por um endereço IP ou nome obtido na etapa 14a ou um ESRK obtido na etapa 14c.

Na etapa 17, E-PS 282 pode abrir uma nova transação X.S0024 com o UE 110 mediante envio de um INICIAR SUPL diretamente para o UE 110 utilizando IP terminado móvel ou UDP/IP (em cujo caso a etapa 18 é saltada) ou mediante envio para E-CSCF 254 de uma mensagem Imediata contendo um INICIAR SUPL X.S0024 com os parâmetros descritos na etapa 7 exceto por uma exatidão/retardo QoP para uma estimativa de posição precisa. Na etapa 18, E-CSCF 254 transfere o INICIAR SUPL dentro de uma mensagem Imediata IMS, uma mensagem SIP ou alguma outra mensagem para o UE 110. Na etapa 19, o UE 110 estabelece uma conexão IP (por exemplo, uma conexão IP segura) com o E-PS 282 e

51/76 retorna um COMEÇAR SUPL para o E-PS 282. E-PS 282 determina um PDE adequado ou V-PS para posicionamento com base em qualquer informação de localização no COMEÇAR SUPL e em qualquer outra informação de localização para o UE 110. EPS 282 então começa o posicionamento mediante retorno de uma RESPOSTA SUPL para o UE 110. O UE 110 pode então trocar mensaqens POS SUPL com E-PS 282, um PDE local, e/ou um PDE remoto para realizar posicionamento e obter uma estimativa de posição exata para o UE 110. Na etapa 20, E-PS 282 envia a estimativa de posição exata para o UE 110 em uma Resposta de Localização para PSAP 180.

O UE 110 pode a sequir comunicar com PSAP 180 para a chamada VoIP de emerqência. Quando a chamada é posteriormente liberada, E-CSCF 254 pode enviar uma indicação para E-PS 282, a qual pode então liberar qualquer gravação da chamada. E-CSCF 254 ou o UE 110 também pode cancelar o registro do ID de usuário público de emergência, o qual foi registrado nas etapas 2 a 4. Alternativamente, E-CSCF 254, E-PS 282 e o UE 110 podem permitir que o registro e as gravações de chamada persistam por certo período de tempo para suportar possível rechamada posterior do PSAP 180 para o UE 110 e/ou solicitações adicionais de localização.

Detalhes adicionais para as etapas 1 a 8 e etapas

12 a 20 da Figura 9 são descritas	para as etapas 1 a	8 e
etapas	12 a 20, respectivamente, da	Figura 5.
	0 fluxo de mensagens 500	tem as características a
seguir	relacionadas ao X.S0024.
(a)	Adição de um endereço	E-PS em INICIAR	SUPL
	X.S0024, o qual sobrescreve e substitui	um
	endereço H-PS configurado	no UE 110 ou UIM.

(b) Interface entre o lado IMS (por exemplo, E-CSCF

254) e o lado de localização (por exemplo, E-PS

52/76

282) .

(c) Uso de V-PS 284 e descoberta do endereço V-PS.

(d) Transporte de um INICIAR SUPL X.S0024 utilizando IP terminado móvel, UDP/IP, sinalização SIP ou sinalização IMS.

(e) Adição de uma indicação de serviços de emergência no INICIAR SUPL X.S0024.

(f) Uso de um novo protocolo entre E-CSCF 254 e E-PS 282, o qual pode ser similar a OMA RLP ou protocolo PS-PS na interface LCS-z no X.S0024.

(g) Segurança.

4. Suporte dos UEs sem UIC/UIM e/ou acordo de

A descrição acima assume que o UE 110 tem um UICC ou UIM e que H-PLMN 160 e V-PLMN 130 tem acordo de roaming, o qual permite reqistro do UE na V-PLMN 130 e subseqüente acesso à chamada de emergência para PSAP 180. Se este não for o caso, então o UE 110 pode acessar e registrar na VPLMN 130 e pode completar o estabelecimento de chamada para PSAP 180 e possível rechamada do PSAP 180 como descrito abaixo. Rechamada do PSAP 180 no caso sem UICC/UIM é possível para VoIP, mas geralmente não é possível para acesso de emergência comutado por circuito devido à incapacidade de paging um UE não-registrado.

A Figura 10 mostra um diagrama em blocos de uma modalidade de uma arquitetura de rede 1000 suportando estabelecimento de chamada VoIP de emergência e rechamada PSAP para um UE sem um UICC/UIM. A arquitetura de rede 1000 inclui algumas das entidades mostradas nas Figuras 2 e 3. Arquitetura de rede 1000 inclui também um servidor de localização 286, o qual pode ser um SLP, um GMLC, um PS, ou alguma outra entidade de localização.

53/76

4.1. Acesso

UE 110 pode obter acesso GPRS, acesso 3GPP WLAN, ou acesso IMS sem um UICC. O UE 110 pode obter acesso cdma2000, acesso 3GPP2 WLAN, ou acesso IMS sem um UIM. O UE 110 pode realizar diferentes procedimentos para diferentes tipos de acesso.

Para acesso GPRS, o UE 110 pode realizar ativação de contexto PDP para serviços de emergência sem um UICC e/ou sem acordo de roaming na V-PLMN 130 como descrito no 3GPP TR 23.867. 0 acoplamento GPRS pode ser conseguida utilizando um pseudo IMSI, o qual pode registrar o UE 110 no HSS 250 na V-PLMN 130, que por sua vez pode ajudar a suportar handover inter-SGSN. Se o UE 110 não tiver UICC, então o pseudo IMSI pode ser criado com uma combinação MCCMNC única e dígitos de uma IMEI. Se o UE 110 tem um UICC, mas não tem acesso a roaming para V-PLMN 130, então o pseudo IMSI pode ser criado com dígitos do IMSI mais propriamente do que IMEI, o que pode evitar duplicar os pseudos IMSIs se todos os dígitos

IMSI forem utilizados.

acoplamento GPRS pode também ser conseguido utilizando

IMEI como uma identificação.

Para acesso 3GPP WLAN, o UE 110 pode criar um pseudo NAI de um pseudo IMSI (por exemplo, o mesmo pseudo

IMSI usado para anexação GPRS), como a seguir:

Pseudo NAI = ntpseudo IMSI>@V-PLMN__network_domain onde n é um dígito fixo na faixa de 2 a 9 indicando o uso de um pseudo NAI não-autenticável para uma chamada de emergência (0 ou 1 já são considerados para NAIs normais). O UE 110 pode utilizar o pseudo NAI para acesso inicial e procedimento ΆΑΆ.

A WLAN pode informar as V-PLMNs capazes de

54/76 suportar ΆΆΆ utilizando o pseudo ΝΑΙ para serviços de emergência ou pode apresentar os V-PLMNs em uma ordem priorizada indicando capacidade e vontade de suportar isto. V-PLMN 130 pode tratar o UE 110 como um assinante de origem temporário e pode saltar AAA ou garantir que este seja bemsucedido (por exemplo, mediante uso de chaves conhecidas para garantir que a autenticação seja bem-sucedida). Pode ser desejável seguir os procedimentos normais tanto quanto for possível e registrar o UE 110 no HSS 250 para melhor suportar a re-seleção e handover de WLAN.

Para acesso cdma2000, o UE 110 pode estabelecer uma sessão PPP com PDSN 242 e pode rejeitar a autenticação durante estabelecimento PPP ao retornar de uma Rejeição de Configuração de Protocolo de Controle de Link (LCP) em resposta a uma Solicitação de Configuração LCP do PDSN 242, por exemplo, como descrito no IETF RFC 1661. PDSN 242 pode suportar chamadas de emergência para os UEs nãoautenticados ou sem UIM e pode continuar o estabelecimento da sessão PPP sem autenticar o UE 110. PDSN 242 pode atribuir um endereço IP único ao UE 110 e pode aplicar filtragem de pacote IP para restringir as entidades com as quais o UE 110 pode comunicar. Por exemplo, PDSN 242 pode restringir o UE 110 para comunicar com os servidores locais (por exemplo, um servidor DHCP, um servidor DNS, e P-CSCF 252) e com entidades associadas com acesso PSAP, mas não com acesso aberto à Internet.

PDSN 242 pode ser informada sobre uma chamada de emergência de diversas formas. Em uma modalidade, o UE 110 envia para a PDSN 242 uma Solicitação de Configuração IPCP contendo um endereço IP único que é definido globalmente para indicar uma solicitação de endereço IP para uma chamada de emergência. Em outras modalidades, indicações podem ser usadas no estabelecimento PPP, ou PDSN 242 pode

55/76 receber uma indicação de uma solicitação de chamada de emergência da RN (RRC/PCF 222) através da interface A10 cdma2000. Em qualquer caso, PDSN 242 pode atribuir um endereço IP único a um UE não-autenticado para uma chamada de emergência e pode empregar filtragem especial como descrito acima. Esta atribuição de endereço IP pode ser conseguida através de um melhoramento para o PPP IPCP descrito no IETF RFC 1332. Se o UE 110 não indicar uma chamada de emergência, então PDSN 242 pode não permitir o estabelecimento PPP e atribuição de endereço IP.

Em vez de rejeitar a autenticação, o UE 110 pode permitir que a autenticação prossiga utilizando um Protocolo de Autenticação de Senha (PAP) ou um Protocolo de Autenticação de Handshake de Desafio (CHAP), os quais são descritos no IETF RFC 1334 e RFC 1994, respectivamente. O UE 110 pode receber uma solicitação de autenticação PAP ou um Desafio CHAP e pode enviar uma resposta que inclui uma identidade que indica uma chamada de emergência de um UE sem UIM. Esta identidade pode ser o pseudo IMSI usado para acesso 3GPP2 WLAN. Se a identidade indicou V-PLMN 130 como o domínio para o UE 110, então a autenticação PAP ou CHAP pode prosseguir na forma normal da perspectiva da PDSN 242 para o servidor AAA 246 na V-PLMN 130. O servidor AAA 246 pode reconhecer o pseudo IMSI como indicando acesso de chamada de emergência e pode abster da autenticação normal ou pode realizar a autenticação utilizando chaves conhecidas. O servidor AAA 246 pode garantir que a filtragem restrita seja usada pela PDSN 242 para restringir o acesso IP, por exemplo, para permitir uma chamada VolP de emergência, mas não outros tipos de acesso.

PDSN 242 pode construir um NAI para contabilidade e/ou manutenção de registro. PDSN 242 pode usar a identidade internacional única do UE (uma IMSI, MIN, ou MIN

56/76 de Roaming Internacional - IRM) se o UE 110 tiver um UIM. PDSN 242 pode também usar uma ESN ou outra identificação para o UE 110.

Para acesso 3GPP2 WLAN, após o US 110 acessar a WLAN, um ponto de acesso ou uma entidade de autenticação pode iniciar a autenticação do UE 110 e pode enviar uma Solicitação de Protocolo de Autenticação Extensível (EAP) ou alguma outra solicitação para a identidade do UE 110. O UE 110 pode responder ao retornar uma Resposta EAP ou alguma outra resposta contendo a identidade do UE, por exemplo, na forma de usergdomain onde o domínio identifica a H-PLMN do UE 110. Se o UE 110 não tem UIM ou nenhum acordo de roaming na V-PLMN 130, então o UE 110 pode retornar uma pseudo-identidade que pode ser a mesma, ou similar, a pseudo NAI usada para 3GPP WLAN. Por exemplo, a parte do usuário (por exemplo, pseudo IMSI) da pseudoidentidade pode conter dígitos da identidade internacional única do

UE (por exemplo, um IMSI,

MIN ou IRM) se o UE 110 tiver um

UIM ou dígitos do ID de terminal único (por exemplo, uma ESN) caso contrário.

A parte de usuário pode também conter um prefixo único (por exemplo, um dígito único) para indicar que esta é uma pseudo-identidade para chamadas de emergência. A parte de domínio da pseudo identidade pode indicar V-PLMN 130.

O ponto de acesso ou a entidade de autenticação pode continuar a autenticação utilizando um servidor AAA local, por exemplo, servidor AAA 246. A autenticação pode rodar normalmente utilizando chaves conhecidas ou pode ser truncada uma vez que a autenticação genuína não ocorre. Quando a pseudo-autenticação é concluída, o ponto de acesso ou o roteador associado pode empregar filtragem de pacote para limitar acesso pelo UE 110, como descrito acima.

O UE 110 pode acessar a WLAN, realizar pseudo

57/76 autenticação, e descobrir um PDIF. O UE 110 pode então se identificar para o PDIF (ou o servidor AAA local) utilizando uma pseudo-identidade, por exemplo, em vez de uma NAI usada para autenticação cdma2000 UE-PIDF. A pseudoidentidade pode ser idêntica ou similar a esta usada para autenticação WLAN. Autenticação normal e estabelecimento de túnel podem então prosseguir (por exemplo, como descrito no 3GPP2 X.P0028-200) utilizando o servidor AAA local e empregando chaves conhecidas para obter alguma transparência para o PDIF. Alternativamente, a autenticação pode ser truncada ou abortada. Após autenticação, o PDIF pode empregar filtragem de pacote para limitar acesso pelo UE 110.

A WLAN pode informar as V-PLMNs capazes de suportar os procedimentos acima ou pode apresentar as VPLMNs em uma ordem priorizada indicando capacidade e vontade de suportar isto.

Para acesso IMS,' o registro SIP pode ser saltado se o UE 110 não tiver UICC/UIM e/ou nenhum acordo de roaming na V-PLMN 130, como descrito no 3GPP TR 23.867 e 3GPP2 X.P0013-002A. Isto possibilita estabelecimento de chamada de emergência para um PSAP, mas não suporta rechamada. Alternativamente, o UE 110 pode registrar ao enviar um REGISTRO SIP contendo um nome de dominio V-PLMN e um ID de usuário privado de emergência, o qual pode ser criado utilizando o nome de dominio V-PLMN e um pseudoIMSI. Este REGISTRO SIP seria reconhecido no E-CSCF 254 e HSS 250, mas poderia ser transparente para outras entidades.

O procedimento de registro pode então prosseguir tanto quanto a condução do REGISTRO SIP do UE 110 para ECSCF 254 (ou outro servidor IMS) na V-PLMN 130. Registro na H-PLMN 160 não é realizado, mas E-CSCF 254 registraria o UE

58/76

110 no HSS 250 na V-PLMN 130. HSS 250 pode atribuir um TEL URI temporário e/ou um SIP URI temporário (a partir de um grupo no HSS 250) como identidades de usuário públicas temporárias. O TEL URI pode ser transportado para PSAP 180 no estabelecimento da chamada se a sinalização fosse através da PSTN, e o SIP URI pode ser conduzido para estabelecimento de chamada SIP. O URI permitiría rechamada do PSAP 180 se o registro IMS e a conectividade IP fossem mantidos por ambos V-PLMN 130 e UE 110 por algum período após término da chamada de emergência. O TEL URI e SIP URI são reconhecidos pelo PSAP 180 como endereços temporários devido às diferenças a partir de endereços permanentes normais, uma vez que eles não são usados para identificar globalmente o UE 110. HSS 250 pode colocar em quarentena os endereços temporários retornados das chamadas de emergência completadas e não reatribuir estes endereços por um período de tempo para evitar que rechamadas PSAP sejam equivocadamente encaminhadas aos UEs errados.

Rechamada PSAP pode ser suportada de diversas maneiras. Se o UE 110 é registrado na H-PLMN 160, então a rechamada do PSAP 17 pode usar a identidade de usuário pública SIP URI ou TEL URI do UE 110 e pode ser encaminhada inicialmente para H-PLMN 160, como descrito no 3GPP TS 23.228 ou 3GPP2 X.P0013. Para um PSAP capacitado para SIP, o CONVITE SIP pode ser encaminhado para I-CSCF 2 62 na HPLMN 160 (com base no nome de domínio H-PLMN no SIP URI do UE) . I-CSCF 262 pode consultar HSS 250 para S-CSCF 264 na H-PLMN 160 e pode então encaminhar a chamada para S-CSCF 264. S-CSCF 264 pode então encaminhar a chamada para E-CSCF 254 ou P-CSCF 252 na V-PLMN 130 com base na informação de registro anterior. No caso anteriormente mencionado, E-CSCF 254 pode ser tratado pela S-CSCF 264 como um P-CSCF e pode encaminhar a chamada através do P-CSCF 252 para o UE 110.

59/76

No último caso, P-CSCF 252 pode encaminhar a chamada para o UE 110. Para um PSAP com capacidade PSTN, a chamada pode ser encaminhada através da PSTN para um MGCF na H-PLMN 160 com base no TEL URI do UE 110. O MGCF pode inter-operar entre a PSTN e sinalização SIP e pode enviar um CONVITE SIP para I-CSCF 262 na H-PLMN 160. O roteamento de chamada do I-CSCF 262 para o UE 110 prosseguiria então da mesma maneira como para o PSAP com capacidade SIP.

Se o UE 110 não for registrado na H-PLMN 160 (por exemplo, devido a não ter UICC/UIM e/ou nenhum acordo de roaming com V-PLMN 130), então o UE 110 pode ser registrado em HSS 250 na V-PLMN 130. HSS 250 pode atribuir um TEL URI temporário ou identidade de usuário pública SIP URI para o UE 110. Rechamada do PSAP pode então ser encaminhada ou para I-CSCF 256 ou para um PSAP com capacidade SIP ou MGCF 258 para um PSAP com capacidade PSTN, sem envolver H-PLMN 160.

4.2. Estabelecimento de Chamada

A Figura 11 mostra uma modalidade de um fluxo de mensagens 1100 para estabelecimento de chamada VoIP de emergência para um UE sem um UICC/UIM. O fluxo de mensagem 1100 pode ser usado para localização de plano de controle 3GPP, SUPL, e X.S0024.

Na etapa 1, o UE 110 descobre e conecta a uma rede de acesso, estabelece conectividade IP, e pode descobrir um servidor SIP local (por exemplo, P-CSCF 252), como descrito acima. 0 UE 110 pode empregar um pseudo IMSI para acesso cdma2000 ou GPRS, uma pseudo NAI para acesso WLAN, uma pseudo-identidade para acesso 3GPP2 WLAN. O UE 110 pode registrar no HSS 250 na V-PLMN 130 utilizando a pseudo-identidade (por exemplo, uma pseudo IMSI).

Na etapa 2, o UE 110 tenta registrar na rede V60/76

PLMN IMS ao enviar um REGISTRO SIP para P-CSCF 252, o qual foi descoberto na etapa 1. Para UICC/UIM ausente ou não roaming,

REGISTRO SIP pode incluir uma indicação de serviços de emergência, o nome de domínio

V-PLMN, o endereço

IP do UE obtido na etapa 1, um ID de usuário privado de emergência criado utilizando o nome de domínio

V-PLMN e o pseudo IMSI (para GPRS) ou pseudo-identidade

REGISTRO SIP pode incluir ainda um ID de usuário público temporário atribuído no registro inicial. Devido à presença da indicação dos serviços de emergência ou o ID de usuário privado de emergência (o qual pode indicar a

V-PLMN 130 como a rede de origem para

REGISTRO SIP para E-CSCF

254, que suporta chamadas de mesma rede. O REGISTRO SIP enviado pode incluir informação de localização para o UE 110. O REGISTRO SIP pode incluir também um endereço SGSN ou V-SLP (para 3GPP) ou um endereço V-SLP, PDSN ou PIDF (para 3GPP2).

Na etapa 3, como o ID de usuário privado de emergência para o UE 110 refere a V-PLMN 130, E-CSCF 254 envia a informação de registro para HSS 250, por exemplo, em um Cx-Put/Cx-Pull. Na etapa 4, HSS 250 verifica se o ID de usuário privado de emergência já está registrado, por exemplo, se o UE 110 já registrou ou outro UE registrou com o mesmo ID de usuário privado. HSS 250 pode usar o ID de usuário público temporário, se provida, para distinguir os UEs que tem o mesmo ID de usuário privado de emerqência devido aos dígitos de entidade do UE comum (por exemplo, dígitos ESN ou IMEI comuns) e para distinguir um registro inicial (sem nenhum usuário público temporário atribuído) a partir de um re-registro. Para um registro inicial, HSS 250 armazena o ID de usuário privado de emergência e o endereço

61/76

E-CSCF e atribui um SIP URI de usuário público temporário e/ou TEL URI, que são retornados ao E-CSCF 254.

Na etapa 5, E-CSCF 254 retorna um 200 OK para o UE 110 através do P-CSCF 252. O 200 OK pode incluir os IDs de usuários públicos temporários atribuídos pelo HSS 250. O UE 110 pode re-registrar se transferido para um SGSN diferente (para acesso GPRS), um PCF diferente ou PDSN (para acesso cdma2000), uma WLAN diferente (para acesso WLAN) dentro da V-PLMN 130. Na etapa 6, o UE 110 envia para o P-CSCF 252 um CONVITE SIP que pode incluir um SIP URL global ou TEL URI indicando uma chamada de emergência, o tipo de serviço de emergência necessário, e os IDs de usuário públicos temporários recebidos na etapa 5 se o UE 110 não tiver UICC/UIM e/ou não-acesso roaming a V-PLMN 130. P-CSCF 252 envia o CONVITE SIP para E-CSCF 254. Na etapa 7, E-CSCF 254 interage com o servidor de localização 286 para obter informação de roteamento PSAP para a chamada (por exemplo, PSAP SIP URI, ou ESRD e ESRK), como descrito para as etapas 6 a 13 das Figuras 5 e 9 e etapas 9 a 13 da Figura 7.

As etapas 8a e 9a são realizadas se o PSAP 180 for habilitado para IP. Na etapa 8a, E-CSCF 254 encaminha o CONVITE SIP para PSAP 180 utilizando um SIP URI. O CONVITE SIP pode incluir qualquer estimativa de posição provisória para o UE 110, o endereço IP ou nome do servidor de localização 286, e o SP URI de usuário público temporário atribuído ao UE 110. Na etapa 9a, a sinalização SIP adicional pode ser trocada para estabelecer a chamada de emergência.

As	etapas 8b, 8c	e	9b são	realizadas se	PSAP 180
for habilitado para PSTN.	Na	etapa	8b, E-CSCF 254	envia	o
CONVITE SIP	através de uma	BGCF	para uma MGCF	258 .	0

CONVITE SIP pode incluir o ESRD e ESRK e possivelmente um

62/76

TEL URI de usuário público temporário atribuído ao UE 110. Na etapa 8c, MGCF 258 encaminha a chamada para PSAP 180 através da PSTN, possivelmente através de um roteador seletivo, utilizando SS7 ISUP e/ou sinalização MF. O ESRD ou ESRK são usados como números de roteamento e o ESRK é passado para PSAP 180 como a identidade do UE 110 e como uma chave para obter mais informação. Um número E.164 de usuário público temporário também pode ser passado para o PSAP 180 se permitido pelas capacidades de sinalização. E.164 é um padrão ITU-T que define o sistema internacional de numeração telefônica, e um número E.164 é composto de um código de país acrescido de um número nacional. Na etapa 9b, a sinalização SIP adicional pode ser trocada e a interconexão com SS7 ISUP e/ou MF no MGCF 258 pode ocorrer para estabelecer a chamada.

Na etapa 10, PSAP 180 pode obter uma estimativa de posição exata para o UE 110 ao consultar o servidor de localização 286, o qual pode ser indicado pelo SIP URI ou ESRK no estabelecimento da chamada. A resposta do servidor de localização 286 pode incluir qualquer número E.164 de usuário público temporário atribuído ao UE 110, se o PSAP

180 for habilitado para PSTN e se este número não foi passado para o PSAP 180 no estabelecimento da chamada. A chamada pode ser liberada em algum tempo posterior, por exemplo, interrompida devido perda temporária da cobertura de rádio. E-CSCF 254 pode então esperar por um período de tempo antes de informar ao servidor de localizaçao para suportar a localização do UE

110 mediante PSAP 180 para uma rechamada subseqüente.

PSAP

180 tenta chamar de volta o

UE

110 utilizando seu ID de usuário público temporário.

A etapa

11a é realizada para um PSAP com capacidade SIP.

Na etapa

11a, o PSAP 180 envia um CONVITE SIP para I-CSCF 258, o

63/76 qual pode ser indicado pela parte de domínio de rede do SIP URI de usuário público temporário atribuído ao UE 110. As etapas 11b e 11c são realizadas para um PSAP com capacidade PSTN. Na etapa 11b, PSAP 180 envia um ISUP IAM (ou estabelecimento de chamada MF) para MGCF 258, o qual pode ser indicado pelos primeiros dígitos no número E.164 de usuário público temporário atribuído ao UE 110. Na etapa 11c, MGCF 258 envia ao I-CSCF 258 um CONVITE SIP contendo um TEL URI construído a partir do número E.164 recebido na etapa 11b.

Na etapa 12, I-CSCF 258 envia para o HSS 250 uma consulta de localização que pode incluir um SIP URI de usuário público temporário recebido na etapa 11a ou o TEL URI de usuário público temporário recebido na etapa 11c. Na etapa 13, HSS 250 encontra a informação de registro do UE e retorna o endereço de E-CSCF 254 para I-CSCF 258. Na etapa 14, I-CSCF 258 envia o CONVITE ' SIP para E-CSCF 254. Na etapa 15, E-CSCF 254 localiza o endereço P-CSCF e envia o CONVITE SIP através do P-CSCF 252 para o UE 110. Na etapa 16, o estabelecimento de chamada continua como em um caso normal.

O UE 110 pode posteriormente comunicar com PSAP 180. Quando ou algum tempo depois a chamada é posteriormente liberada, o E-CSCF 254 pode enviar uma indicação para o servidor de localização 286, o qual pode então liberar qualquer registro da chamada.

5. Suporte de PSAP legado geograficamente remoto

Em alguns casos, o V-PLMN e/ou o servidor SIP (por exemplo, E-CSCF 254) pode estar geograficamente distante do UE 110. Em tais casos, pode não ser possível encaminhar a chamada através de um MGCF local para um PSAP

64/76 com capacidade PSTN se a PSTN nao suportar acesso aos PSAPs remotos. O que se segue pode ser usado para lidar com estes casos.

Em uma modalidade, a chamada de emergência é redirecionada para uma V-PLMN diferente. Mais cedo no processamento do CONVITE SIP, um E-CSCF ou um servidor de localização (por exemplo, um E-SLP, um GMLC, etc.) pode determinar que a chamada deve ser redirecionada para um servidor de chamada em outra rede. Neste caso, a resposta Redirecionar SIP 3xx (por exemplo, utilização de proxy 305) contendo o SIP URI(s) do servidor(s) alternativo preferido pode ser retornada ao UE 110. O UE 110 pode então tentar outra vez os procedimentos de chamada como descrito acima, embora o acesso e os procedimentos de conectividade IP possam ser saltados se a mesma rede de acesso ainda puder ser usada. Se o procedimento de estabelecimento de chamada tiver avançado até o ponto de determinar uma estimativa de posição provisória e/ou o PSAP correto (por exemplo, endereço IP ou ESRD, SIP URI), então o E-CSCF pode incluir estes na resposta de redirecionar. O UE 110 pode então incluir a informação no CONVITE SIP enviado para a nova PLMN, a qual pode evitar retardo extra para obter a mesma informação e permitir o uso das PLMNs sem a capacidade de obter esta informação. O E-CSCF original pode notificar o servidor de localização (por exemplo, E-SLP ou GMLC), o qual pode então remover o registro da chamada para o UE 110 .

Em outra modalidade, o E-CSCF envia a chamada para um servidor SIP em outra rede (ou na mesma rede) mais próxima de um PSAP de onde a chamada pode ser melhor encaminhada para a PSTN. A V-PLMN pode continuar a suportar todas as funções previamente descritas incluindo as funções de localização e suporte para os UEs sem UICC ou UIM. O

65/76

CONVITE SIP enviado pode incluir a identidade PSAP (por exemplo, SIP URI ou ESRD) , qualquer ESRK atribuído pelo servidor de localização e quaisquer IDs de usuários públicos temporários para um UE sem UICC. 0 PSAP pode continuar a consultar o servidor de localização na V-PLMN para informação de localização e qualquer rechamada pode ser enviada através da H-PLMN para a V-PLMN para o caso normal, ou direcionada para a V-PLMN no caso de ausência de

UICC. O suporte contínuo destas funções na V-PLMN evita demandas no servidor SIP subseqüente e deve possibilitar que um maior número de outras redes suporte o serviço de envio.

Em ainda outra modalidade, a Portabilidade de Número Local pode ser usada, por exemplo, na América do Norte. Além de retornar o ESRD e ESRK, o servidor de localização (por exemplo, E-SLP ou GMLC) pode retornar um LRN (Número de Roteamento de Localização) para a rede IMS (por exemplo, E-CSCF) que corresponde a um roteador seletivo PSAP ou troca de LEC a partir do qual o PSAP pode ser alcançado diretamente. Como uma alternativa, a rede IMS (por exemplo, E-CSCF ou MGCF) pode obter a LRN do ESRD. O LRN é incluído na informação enviada ao MGCF (se não for obtido pelo MGCF) , e o MGCF envia à PSTN um ISUP IAM contendo os seguintes parâmetros:

Número da Parte Chamada = LRN,

Parâmetro de Endereço Genérico (GAP) = ESRD,

Bit M de parâmetro FCI ajustado para número convertido,

Número de Parte Chamadora = UE MSISDN ou ESRK, e

Categoria da Parte Chamadora ajustada para chamada de serviço de emergência (opcional).

Devido ao suporte de portabilidade de número pelas PSTNs (por exemplo, em todos os Estados Unidos), a

66/76 chamada (ISUP IAM) pode ser corretamente encaminhada para o LEC CO pretendido ou SS7 provido pelo roteador seletivo mais propriamente do que troncos MF podem ser usados no todo. O LEC CO de destino ou o roteador seletivo pode suportar portabilidade de número e pode reconhecer o LRN como sendo o seu próprio ao receber a chamada e pode obter o número da parte chamada verdadeiro (ESRD) do GAP. Singularidade do ESRD ou a configuração da Categoria da Parte Chamadora pode informar o LEC CO ou roteador seletivo que esta é uma chamada de emergência. Neste ponto, a chamada pode ser encaminhada ao PSAP como se esta tivesse sido originada localmente. Esta modalidade evita novos impactos para comutações interurbanas PSTN (por exemplo, nenhuma mudança de roteamento), mas pode afetar os LEC COs e roteadores seletivos.

· Segurança para SUPL e X.S0024

Para SUPL, os procedimentos de segurança podem ser estabelecidos para suportar E-SLP 272 substituindo o HSLP para posicionamento para cenários de roaming e não-roaming e com modo proxy ou não-proxy. Procedimentos de segurança SUPL existentes geralmente são baseados em chaves compartilhadas tanto no UE 110 como no H-SLP e/ou baseados em outra informação aprovisionada no UE 110 com relação ao H-SLP (por exemplo, nome de domínio totalmente qualificado, certificado de chave pública X.509 de raiz, etc.). Tal informação pode não estar disponível para E-SLP 272. Para E-SLP 272, a autenticação para os modos proxy e não-proxy pode ser suportada como descrito abaixo.

Para X.S0024, os procedimentos de segurança podem ser também estabelecidos para suportar E-PS 282 substituindo o H-PS para posicionamento. Procedimentos de segurança X.S0024 existentes são descritos no 3GPP2

67/76

X.S0024-0 e no 3GPP2 S.P0110-0. Esses procedimentos fazem uso de uma chave raiz comum provisionada em ambos, H-PS para um usuário e no UIM do usuário. Chaves adicionais podem ser derivadas da chave raiz aprovisionada como a seguir:

(a) Chave para suportar Encapsulamento de Envio e Armazenamento Seguro (S-SAFE) na qual uma INICIAR

SUPL é enviada para o UE 110 utilizando Push WAP ou SMS e é autenticada (como proveniente do H-PS) e opcionalmente cifrada.

(b) Chave para suportar uma conexão IP segura entre o UE 110 e o H-PS no qual as mensagens X.S0024 são enviadas entre o UE 110 e o H-PS com cifragem e autenticação.

(c) Chave para suportar uma conexão IP segura entre o UE 110 e um PDE para o modo não-proxy no qual as mensagens X.S0024 são enviadas entre o UE 110 e o PDE com cifragem e autenticação.

Cada uma das três chaves descritas acima é fixa no sentido de que existe um valor deterministico para qualquer valor da chave raiz. Contudo, de cada uma dessas chaves fixadas, chaves adicionais podem ser derivadas para cifragem e autenticação cujos valores dependem de números aleatórios providos para uma sessão de posicionamento especifica pelo UE e H-PS ou PDE. Essa derivação de chave e os procedimentos de segurança acompanhantes fazem uso do procedimento de Segurança de Camada de Transporte (TLS) descrito no IETF RFC 2246 e a variante PSK-TLS desta descrita na minuta IETF Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Se X.S0024 for usado para posicionamento em uma chamada VoIP de emergência e E-PS 282 não é o H-PS, então não é mais possível basear em uma chave

68/76 raiz pré-configurada comum em ambos, UE 110 e E-PS 282 para autenticação e cifragem mútua.

Para SUPL, o UE 110 pode autenticar o E-SLP 272 para evitar acesso não-autorizado à localização do UE mesmo 5 durante uma chamada de emergência. Para X.S0024, o UE 110 e o E-PS 282 podem realizar autenticação mútua. A Tabela 2 relaciona cinco métodos de autenticação, designados como métodos A, B, C, D e E, e as características de cada método.

Tabela 2 - Métodos de Autenticação

Característica	Método A	Método B	Método C	Método D	Método E
Autenticar E-SLP	Não	Sim	Sim	Sim	Sim
Autenticar UE	Não	Limitada	Sim	Sim	Sim
Suportar roaming	Sim	Sim	Sim	Sim	Não
Impacto H-PLMN	Não	Não	Não	Sim	Sim
Conexão UE segura para IMS necessária	Não	Não	Sim	Não	Não
Suporte sem UICC/UIM	Sim	Sim (nota 1)	Limitada	Não	Não

Nota 1: assume que certificados raiz de chave pública são aprovisionados em um Equipamento Móvel (ME).

O método A provê uma autenticação mínima. O UE

110 permite SUPL iniciado pela rede ou localização X.S0024 de um E-SLP não-autenticado ou E-PS se a mensagem INICIAR

SUPL indicar localização para uma sessão de emergência e o

UE 110 estiver atualmente participando de uma sessão de emergência. A restrição para a sessão de emergência provê alguma proteção. Para SUPL, o UE 110 pode selecionar o

69/76 método Ά, mas não invocar os procedimentos de segurança com E-SLP 272. Neste caso, E-SLP 272 pode ainda verificar a identidade do UE, até um ponto limitado, através de um código hash INICIAR SUPL contido em um INICIAR POS SUPL. Além disso, o endereço IP do UE 110 provido ao E-SLP 272 pelo E-CSCF 254 pode prover alguma garantia adicional da identidade correta do UE. Para X.S0024 e SUPL, a transferência do INICIAR SUPL através do IMS ou SIP (se a transferência direta através do IP terminado móvel ou UDP/IP não for usada) pode prover alguma confiança adicional na autenticidade do UE, uma vez que a transferência IMS e SIP se baseia no suporte e verificação da V-PLMN 130 e/ou H-PLMN 160.

O método B é para autenticação de chave pública TLS. O UE 110 e E-SLP 272 ou E-PS 282 suportam autenticação de chave pública utilizando TLS como descrito na RFC 2246 IETF e como também descrito em um mecanismo de autenticação de cliente alternativo no OMA SUPL 1.0, Secure User Plane Location Architecture. Esse mecanismo suporta autenticação de H-SLP ou E-PS pelo UE utilizando TLS com os certificados de chave pública X.509 ITU enviados pelo H-SLP ou E-PS para o UE durante uma fase de handshake TLS. Os certificados de chave pública proporcionam uma cadeia de assinaturas digitais, cada assinatura autenticando a próxima, de tal modo que o UE possa autenticar a chave pública do E-SLP ou E-PS desde que o UE seja aprovisionado com a chave pública de pelo menos uma autoridade de certificação de raiz. O procedimento TLS de autenticação de chave pública suporta transferência de chaves simétricas para uso na cifragem e autenticação subseqüentes da sinalização, por exemplo, para mensagens SUPL subseqüentes. Autenticação e cifragem entre o UE 110 e um SPC ou PDE para o modo não-proxy podem ser também suportadas com estas chaves ou ao derivar chaves

70/76 adicionais a partir destas chaves. O método B baseia na certificação da chave(s) pública E-PS ou E-SLP por uma ou mais autoridades de certificação de raiz (por exemplo, definida por OMA) e aprovisionamento da chave(s) nos UEs suportando SUPL ou X.S0024 para chamadas VoIP de emergência. Isto garante autenticação do E-SLP 272 ou E-PS 282 pelo UE 110 e, para SUPL, autenticação limitada do UE 110 pelo E-SLP 272 através de um hash INICIAR SUPL de 64 bits incluído em um INICIAR POS SUPL e enviado pelo UE 110 para o E-SLP 272.

Para o método B, o UE 110 (por exemplo, UICC ou UIM) pode ser aprovisionado com um ou mais certificados de chave pública de raiz permitindo ao UE verificar a chave(s) pública do E-SLP 272 ou E-PS 282. O UE 110 e o E-SLP 272 ou E-PS 282 pode estabelecer uma chave de cífragem compartilhada e uma chave de código de autenticação de mensagem (MAC) utilizando os procedimentos TLS descritos na RFC 2246 e um ou mais procedimentos de transferência de chave pública segura, por exemplo, RSA, DSS, ou DiffieHellman. A cifragem e a autenticação das mensagens X.S0024 ou SUPL podem ser realizadas após o estabelecimento de uma conexão TLS segura. Para o modo não-proxy, o método definido para o modo não-proxy 3GPP2 no SUPL 1.0 pode ser usado para gerar uma chave compartilhada para autenticação e cifragem, e de acordo com PSK-TLS IETF, entre o UE 110 e um V-SPC ou H-SPC na SUPL ou entre o UE 110 e um PDE no X.S0024.

O método C é para autenticação PSK-TLS. O UE 110 e o E-SLP 272 ou E-PS 282 suportam PSK-TLS (por exemplo, como descrito no SUPL 1.0 para 3GPP2 SETs ou 3GPP2 X.S00240 e S.P0110-0) de acordo com a minuta IETF Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Uma chave pré-compartilhada (PSK) pode ser gerada a partir da (a)

71/76 informação (por exemplo, informação aleatória) contribuída pelo UE 110, a rede IMS (por exemplo, E-CSCF 254) e/ou ESLP 272 ou E-PS 282, (b) informação (por exemplo, parâmetros SIP) enviada pelo ou para o UE 110 durante estabelecimento SIP da chamada de emergência, (c) informação de segurança já presente no P-CSCF 252 e no UE 110 para suportar acesso IMS seguro do UE 110 (por exemplo, utilizando IPsec, PSK-TLS, TLS), e/ou (d) outra informação. A informação de segurança em (c) pode estar disponível se o UE 110 se registrar junto à rede H-PLMN IMS por intermédio da V-PLMN 130.

O PSK ou a informação usada para derivar este pode ser disponibilizado ao UE 110 e E-SLP 272 ou E-PS 282 durante registro SIP e/ou iniciação de uma chamada de emergência SIP e pode ser usado para SUPL ou localização X.S0024 utilizando PSK-TLS. A relação de confiança estabelecida durante registro e estabelecimento de chamada SIP entre estas entidades é usada para obter um PSK seguro ou informação comum do qual uma chave segura pode ser derivada. Para SUPL, autenticação mútua do UE 110 e E-SLP 272 pode então ser suportada utilizando PSK-TLS quando o UE estabelece uma conexão IP (PSK-TSL) para E-SLP 272 após transferência do INICIAR SUPL do E-SLP 272 para o UE 110. Para X.S0024, o PSK seguro pode ser usado como uma chave raiz da qual a informação de segurança restante pode ser derivada como descrito no 3GPP2 X.S0024-0 e S.P0110-0.

O método C se baseia em uma conexão segura entre o UE 110 e IMS durante registro SIP e/ou estabelecimento de chamada SIP, o qual implica em registro do UE 110 na V-PLMN 130 e H-PLMN 160 e autenticação mútua do UE 110 e V-PLMN 130. Se o UE 110 não tem um UICC/UIM ou se não existe acordo de roaming entre a V-PLMN 130 e H-PLMN 160, autenticação mútua de, e transmissão segura entre V-PLMN

72/76

130 e o UE 110 pode não ser conseguida durante registro SIP e estabelecimento de chamada SIP, e qualquer PSK gerada proporcionará proteção mais limitada.

método D é para autenticação com uma Arquitetura de Auto-carregamento Genérica (GBA) descrita no 3GPP TS 33.220 ou 3GPP2 TSG-S minuta S.P0109. O UE 110 e o E-SLP 272 ou E-PS 282 suportam GBA. Isto permite que o UE 110 e o E-SLP 272 ou E-PS 282 obtenham uma chave compartilhada segura da H-PLMN 160. Para SUPL, esta chave pode ser usada para suportar autenticação mútua PSK-TLS entre o UE 110 e E-SLP 272, como descrito no 3GPP TS 33.222 ou 3GPP2 TSG-S minuta S.P0114. Este método é usado no SUPL

1.0 para suportar o modo proxy 3GPP. A chave também pode ser usada para suportar TLS com autenticação de Compilação HTTP (por exemplo, como descrito no 3GPP TS 33.222), apenas autenticação de Compilação HTTP entre o UE 110 e E-SLP 272 (por exemplo, como descrito no 3GPP2 TSG-S minuta S.P0114), ou outras formas de autenticação. Para X.S0024, esta chave pode ser usada como uma chave raiz da qual a informação de segurança restante pode ser derivada.

O método D se baseia no suporte de GBA na H-PLMN 160 assim como na V-PLMN 130 e o acordo de roaming entre VPLMN 130 e H-PLMN 160 para possibilitar a transferência de informação chave a partir da Função de Serviço de Autocarregamento (BSF) na

H-PLMN

160 para uma Função de

Rede E-SLP (NAF) na

V-PLMN 130.

método é para

SUPL 1.0 ou autenticação

X.S0024. Para SUPL, se o UE 110 está na H-PLMN 160, então

E-SLP 272 pode ser o H-SLP, e mecanismos de autenticação existentes definidos na SUPL 1.0 podem ser usados. Para

X.S0024, se UE 110 estiver na H-PLMN 160, então E-PS 282 pode ser o H-PS, e mecanismos de autenticação existentes definidos no X.S0024 podem ser usados.

73/76

A Figura 12 mostra um diagrama em blocos de uma modalidade do UE 110, rede de acesso 120, E-CSCF 254, e servidor de localização 286. 0 servidor de localização 286 pode ser E-SLP 272, GMLC 276, E-PS 282, e/ou alguma outra entidade. Para simplicidade, a Figura 12 mostra apenas um processador 1210, uma unidade de memória 1212, e um transceptor 1214 para o UE 110, apenas um processador 1220, uma unidade de memória 1222, um transceptor 1224, e uma unidade de comunicação (Comm) 1226 para rede de acesso 120, apenas um processador 1230, uma unidade de memória 1232, e uma unidade de comunicação 1234 para E-CSCF 254, e apenas um processador 1240, uma unidade de memória 1242, e uma unidade de comunicação 1244 para o servidor de localização 286. Em geral, cada entidade pode incluir qualquer número de processadores, unidades de memória, transceptores, unidades de comunicação, controladores, e assim por diante.

No downlink, as estações base e/ou os pontos de acesso na rede de acesso 120 transmitem dados de tráfego, sinalização, e piloto para os UEs dentro de suas áreas de cobertura. Estes vários tipos de dados são processados pelo processador 1220 e condicionados pelo transceptor 1224 para gerar um sinal de downlink, o qual é transmitido através de uma antena. No UE 110, os sinais de downlink das estações base e/ou pontos de acesso são recebidos através de uma antena, condicionados pelo transceptor 1214, e processados pelo processador 1210 para obter vários tipos de informação para localização, VoIP, e outros serviços. Por exemplo, o processador 1210 pode decodificar as mensagens usadas para os fluxos de mensagem descritos acima. Unidades de memória 1212 e 1222 armazenam códigos de programa e dados para o UE 110 e rede de acesso 120, respectivamente. No uplink, o UE 110 pode transmitir dados de tráfego, sinalização, e piloto para as estações base e/ou pontos de acesso na rede de

4/76 acesso 120. Estes vários tipos de dados são processados pelo processador 1210 e condicionados pelo transceptor 1214 para gerar uni sinal de uplink, o qual é transmitido através da antena UE. Na rede de acesso 120, os sinais de uplink do UE 110 e outros UEs são recebidos e condicionados pelo transceptor 1224 e também processados pelo processador 1220 para obter vários tipos de informação (por exemplo, dados, sinalização, relatórios, e assim por diante) . A rede de acesso 120 comunica com o E-CSCF 254 e outras entidades através da unidade de comunicação 1226.

Dentro do

E-CSCF 254, o processador 1230 realiza processamento para o E-CSCF, unidade de memória 1232 armazena códigos de programa e dados para o E-CSCF, e a unidade de comunicação 1234 permite ao E-CSCF comunicar com outras entidades. 0 processador

1230 pode realizar processamento para E-CSCF 254 para os fluxos de mensagem descritos acima.

Dentro do servidor de processador 1240 realiza processamento de posicionamento para o servidor de localização, a unidade de memória 1242 armazena códigos de programa e dados para o servidor de localização, e a unidade de comunicação 1244 permite ao servidor de localização comunicar com outras entidades. O processador 1240 pode realizar o processamento para o servidor de localização para os fluxos de mensagem descritos acima.

As técnicas descritas aqui podem ser implementadas por vários meios, por exemplo, estas técnicas podem ser implementadas em hardware, firmware, software, ou uma combinação destes. Para uma implementação em hardware, as unidades de processamento usadas para realizar as técnicas podem ser implementadas dentro de um ou mais circuitos integrados de aplicação específica (ASICs),

75/76 processadores de sinal digital (DSPs), dispositivos de processamento de sinal digital (DSPDs), dispositivos lógicos programáveis (PLDs), matrizes de portas programáveis em campo (FPGAs), processadores, controladores, microcontroladores, microprocessadores, dispositivos eletrônicos, outras unidades eletrônicas projetadas para realizar as funções aqui descritas, ou uma combinação destas.

Para uma implementação de firmware e/ou software, as técnicas podem ser implementadas com módulos (por exemplo, procedimentos, funções, e assim por diante) que realizam as funções aqui descritas. Os códigos de firmware e/ou software podem ser armazenados em uma memória (por exemplo, memória 1212, 1222, 1232, e/ou 1242 na Figura 12) e executadas por um processador (por exemplo, processador 1210, 1220, 1230, e/ou 1240) . A memória pode ser implementada dentro do processador ou externa ao processador.

Os cabeçalhos são aqui incluídos para referência e para auxiliar na localização de certas sessões. Estes cabeçalhos não têm o propósito de limitar o escopo dos conceitos aqui descritos, e estes conceitos podem ter aplicabilidade em outras sessões ao longo de todo o relatório descritivo.

A descrição anterior das modalidades descritas é provida para possibilitar que os versados na técnica realizem ou utilizem a descrição. Várias modificações a estas modalidades serão evidentes para os versados na técnica, e os princípios genéricos aqui definidos podem ser aplicados a outras modalidades sem se afastar do conceito inventivo e escopo da descrição. Deste modo, a descrição não pretende ser limitada às modalidades aqui mostradas, mas deve ser concedido o escopo mais amplo compatível com

Ί8/Ί6 os princípios e novas características descritos.

1/5

Claims (15)

1. REIVINDICAÇÕES

   1. Método realizado por um equipamento de usuário (110), caracterizado pelo fato de que compreende:

   comunicar com um Subsistema Multimídia de Protocolo de Internet (254, 254, 256, 258) de rede visitada (130) para enviar uma solicitação para estabelecer uma chamada de voz sobre Protocolo Internet de emergência, em que a solicitação compreende informação de localização para o equipamento de usuário (110);

   caso a informação de localização não seja suficiente para determinar um Ponto de Resposta de Segurança Pública unicamente, receber instruções a partir do Subsistema Multimídia de Protocolo de Internet (252, 254, 256, 258) de rede visitada para obter e enviar, a um servidor de localização (272), uma primeira estimativa de posição para o equipamento de usuário (110), em que a primeira estimativa de posição é suficientemente precisa para permitir que o servidor de localização (272) determine um Ponto de Resposta de Segurança Pública (180) unicamente; e estabelecer a chamada de voz sobre Protocolo de Internet de emergência entre o equipamento de usuário (110) e o Ponto de Resposta de Segurança Pública (180), sobre a rede visitada (130).
2. 2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente:

   utilizar Protocolo de Iniciação de Sessão para a chamada de voz sobre Protocolo de Internet de emergência;

   enviar um REGISTRO SIP para registro com uma rede de origem (160) ou a rede visitada para a chamada de voz sobre Protocolo de Internet de emergência; e enviar um CONVITE SIP como a solicitação para estabelecer a chamada voz sobre Protocolo de Internet de

   Petição 870190020904, de 28/02/2019, pág. 6/11

   2/5 emergência.
3. 3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente:

   receber do Ponto de Resposta de Segurança Pública uma solicitação para uma estimativa de posição atualizada para o equipamento de usuário; e realizar posicionamento com o servidor de localização para obter a estimativa de posição atualizada.
4. 4. Equipamento de usuário (110) caracterizado pelo fato de que é configurado para:

   comunicar com um Subsistema Multimídia de Protocolo de Internet (252, 254, 256, 258) de rede visitada (130) para enviar uma solicitação para estabelecer uma chamada de voz sobre Protocolo Internet de emergência, em que a solicitação compreende informação de localização para o equipamento de usuário (110), caso a informação de localização não seja suficiente para determinar um Ponto de Resposta de Segurança Pública unicamente, receber instruções a partir do Subsistema Multimídia de Protocolo de Internet (252, 254, 256, 258) de rede visitada para obter e enviar, para um servidor de localização (272), uma primeira estimativa de posição para o equipamento de usuário (110), em que a primeira estimativa de posição é suficientemente precisa para permitir que o servidor de localização (272) determine um Ponto de Resposta de Segurança Pública (180) unicamente, e estabelecer a chamada VoIP de emergência entre o equipamento de usuário (110) e o Ponto de Resposta de Segurança Pública (180), em que o Ponto de Resposta de Segurança Pública é sobre a rede visitada (130).
5. 5. Equipamento de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que é

   Petição 870190020904, de 28/02/2019, pág. 7/11

   3/5 configurado adicionalmente para utilizar Protocolo de

   Iniciação de Sessão para a chamada voz sobre Protocolo de

   Internet de emergência.
6. 6. Equipamento de usuário, de acordo com a reivindicação 5, caracterizado pelo fato de que é configurado adicionalmente para enviar um REGISTRO SIP para registro com uma rede de origem para a chamada de voz sobre Protocolo de Internet de emergência.
7. 7. Equipamento de usuário, de acordo com a reivindicação 5, caracterizado pelo fato de que é configurado adicionalmente para enviar um REGISTRO SIP para registro com a rede visitada para a chamada de voz sobre Protocolo de Internet de emergência.
8. 8. Equipamento de usuário, de acordo com a reivindicação 7, caracterizado pelo fato de que o REGISTRO SIP compreende um identificador de usuário privado de emergência formado com um nome de domínio para a rede

   visitada e uma pseudo Identidade de Assinante Móvel Internacional ^. 9. Equipamento de usuário, de acordo com a reivindicação 7, caracterizado pelo fato de que é configurado adicionalmente para receber uma resposta para o REGISTRO SIP com um identificador de usuário público temporário. 10. Equipamento de usuário, de acordo com a reivindicação 5, caracterizado pelo fato de que é

   configurado adicionalmente para enviar um CONVITE SIP como a solicitação para estabelecer a chamada de voz sobre Protocolo de Internet de emergência.
9. 11. Equipamento de usuário, de acordo com a reivindicação 10, caracterizado pelo fato de que é configurado adicionalmente para enviar informação de localização para o equipamento de usuário no CONVITE SIP, e

   Petição 870190020904, de 28/02/2019, pág. 8/11

   4/5 em que a primeira estimativa de posição para o equipamento de usuário é obtida com base na informação de localização.
10. 12. Equipamento de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que é configurado adicionalmente para enviar capacidades de localização do equipamento de usuário na solicitação para estabelecer a chamada de voz sobre Protocolo de Internet de emergência, e em que o servidor de localização é selecionado com base nas capacidades de localização do

    equipamento de usuário. 13. Equipamento de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que o servidor de localização é selecionado com base na informação de localização. 14. Equipamento de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que é

    configurado adicionalmente para receber a partir do Ponto de Resposta de Segurança Pública uma solicitação para uma estimativa de posição atualizada para o equipamento de usuário, e para realizar posicionamento com o servidor de localização para obter a estimativa de posição atualizada.
11. 15. Equipamento de usuário, de acordo com a reivindicação 14, caracterizado pelo fato de que é configurado adicionalmente para realizar posicionamento com o servidor de localização de acordo com a Localização de Plano de Usuário Seguro.
12. 16. Equipamento de usuário, de acordo com a reivindicação 14, caracterizado pelo fato de que é configurado adicionalmente para realizar posicionamento com o servidor de localização de acordo com a localização X.S0024.
13. 17. Equipamento de usuário, de acordo com a reivindicação 14, caracterizado pelo fato de que é

    Petição 870190020904, de 28/02/2019, pág. 9/11

    5/5 configurado adicionalmente para realizar posicionamento com uma rede de acesso de rádio (120) de acordo com a localização de plano de controle 3GPP.
14. 18. Equipamento de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que é configurado adicionalmente para acessar uma rede de acesso de rádio (120), para estabelecer conectividade de Protocolo de Internet com a rede visitada por intermédio da rede de acesso de rádio, e para descobrir um endereço de Protocolo de Internet de um servidor local (252) para a chamada de voz sobre Protocolo de Internet de emergência.
15. 19. Equipamento de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que é configurado adicionalmente para acessar uma rede de área local sem fio (120) utilizando um identificador de acesso de rede indicando a rede visitada, para estabelecer conectividade de Protocolo de Internet com a rede visitada por intermédio da rede de área local sem fio, e para

    descobrir um endereço de Protocolo de Internet de um servidor local (252) para a chamada de voz sobre Protocolo de Internet de emergência. 20. Equipamento de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que é

    configurado adicionalmente para realizar autenticação com o servidor de localização.