BRPI0913427B1

BRPI0913427B1 - codificação e compartimento quando se recebe um indicador de sessão de emergência de ims a partir de uma fonte autorizada

Info

Publication number: BRPI0913427B1
Application number: BRPI0913427-1A
Authority: BR
Inventors: Jan Hendrik Lucas Bakker; Adrian Buckley; Andrew Allen
Original assignee: Blackberry Limited
Priority date: 2008-06-02
Filing date: 2009-06-02
Publication date: 2020-11-10
Also published as: US8305210B2; CN102113294B; ES2392141T3; JP5499147B2; EP2615795A2; EP2255510B1; HK1150915A1; JP2011524673A; EP2615795B1; US20110095886A1; CA2726555A1; BRPI0913427A2; EP2518975B1; EP2892204A3; EP2518975A1; JP2014099908A; KR20110014694A; JP5689989B2; CA2726555C; JP2014099909A

Abstract

CODIFICAÇÃO E COMPARTIMENTO QUANDO SE RECEBE UM INDICADOR DE SESSÃO DE EMERGÊNCIA DE IMS A PARTIR DE UMA FONTE AUTORIZADA. É provido um método para um equipamento de usuário (UE) 110 responder a uma mensagem relacionada à emergência enviada para o UE 110. O método compreende o UE 110 receber uma primeira mensagem 150 contendo um indicador 160 que indica que uma requisição relacionada à emergência foi feita, o UE 110 reconhecer o indicador 160 como uma indicação que a requisição relacionada à emergência está relacionada a uma emergência, e o UE enviar uma segunda mensagem 170 contendo uma informação relacionada à emergência 180 sobre si mesmo.

Description

ANTECEDENTES

O subsistema de multimídia de IP (protocolo de internet) (IMS) é uma arquitetura padronizada para a provisão de serviços de multimídia e chamadas de voz por IP para um equipamento de usuário móvel e fixo (UE). O protocolo de iniciação de sessão (SIP) foi padronizado e governado primariamente pela Força-Tarefa de Engenharia da Internet (IETF) como um protocolo para o estabelecimento e o gerenciamento de chamadas baseadas em IMS. Conforme usado aqui, o termo "UE" pode se referir a dispositivos móveis, tais como telefones móveis, assistentes digitais pessoais, computadores portáteis e laptop, e dispositivos similares que têm capacidades de telecomunicações. Um UE como esse poderia consistir em um dispositivo sem fio e sua placa de circuito impresso universal (UICC) associada, que inclui um aplicativo de módulo de identidade de assinante (SIM), um aplicativo de módulo de identidade de assinante universal (USIM) ou um aplicativo de módulo de identidade de usuário removível (R-UIM), ou poderia consistir no dispositivo em si, sem essa placa. 0 termo "UE" também pode se referir a dispositivos que tenham capacidades similares, mas que não sejam transportáveis, tais como telefones de linha fixa, computadores de mesa ou set-top boxes. O termo "UE" também pode se referir a qualquer componente de hardware ou software que possa terminar uma sessão de SIP.

SUMÁRIO

Em uma modalidade, é provido um método para um UE responder a uma mensagem relacionada à emergência enviada para o UE. O método compreende o UE receber uma primeira mensagem contendo um indicador que indica que uma chamada relacionada à emergência foi feita, o UE reconhecer o indicador como uma indicação que a chamada relacionada à emergência está relacionada a uma emergência e o UE enviar uma segunda mensagem contendo uma informação relacionada à emergência sobre si mesmo.

Em uma outra modalidade, é provido um UE, que inclui um processador configurado para reconhecer uma chamada de IMS como uma chamada relacionada à emergência mediante o recebimento de uma primeira mensagem contendo um indicador. O processador ainda é configurado para reconhecer o indicador como uma indicação que a chamada relacionada à emergência está relacionada a uma emergência, e para enviar uma segunda mensagem contendo uma informação relacionada à emergência sobre o UE.

Em uma outra modalidade, é provido um método para um componente de rede responder a uma chamada relacionada à emergência a partir de um UE. O método compreende o componente de rede colocar em uma primeira mensagem para o UE um indicador indicando que a chamada era uma chamada relacionada à emergência, e o componente de rede receber a partir do UE uma segunda mensagem contendo uma informação relacionada à emergência sobre o UE.

Em uma outra modalidade, um componente de rede é provido, que inclui um processador configurado para, mediante o componente de rede receber uma chamada de emergência a partir de uma UE, colocar em uma primeira mensagem para o UE um indicador indicando que a chamada era uma chamada de emergência. O processador ainda é configurado para receber uma segunda mensagem a partir do UE contendo a informação relacionada à emergência sobre o UE.

BREVE DESCRIÇÃO DOS DESENHOS

Para um entendimento mais completo desta exposição, uma referência é feita, agora, à breve descrição a seguir, tomada em relação aos desenhos associados e à descrição detalhada, onde números de referência iguais representam partes iguais. A Figura 1 é um diagrama de uma rede de IP ilustrativa incluindo um UE e um PSAP de acordo com uma modalidade da exposição. A Figura 2 é um diagrama de uma rede de IP ilustrativa incluindo um UE e um PSAP de acordo com uma outra modalidade da exposição. A Figura 3 é um diagrama que ilustra um método para um UE responder a uma mensagem relacionada à emergência de acordo com uma modalidade da exposição. A Figura 4 é um diagrama de um sistema de comunicações sem fio incluindo um equipamento de usuário operável para algumas das várias modalidades da exposição. A Figura 5 é um diagrama de blocos de equipamento de usuário operável para algumas das várias modalidades da exposição. A Figura 6 é um diagrama de um ambiente de software que pode ser implementado em um equipamento de usuário operável para algumas das várias modalidades da exposição. A Figura 7 é um sistema de computação ilustrativo adequado para algumas das várias modalidades da exposição.

DESCRIÇÃO DETALHADA

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

Em uma modalidade, é provido um método para o UE responder a uma mensagem relacionada à emergência enviada para o UE. O método compreende o UE receber uma primeira mensagem contendo um indicador indicando que uma chamada relacionada à emergência foi feita, o UE reconhecer o indicador como uma indicação que a chamada relacionada à emergência está relacionada a uma emergência, o UE invocar uma funcionalidade que a chamada relacionada à emergência está relacionada à emergência, e/ou se o UE estiver engajado em quaisquer outras sessões ou serviços estes serão suspensos, terminados ou mantidos rodando, mas colocados em uma prioridade mais baixa, isto é, uma QoS mudada ou caída, já que a chamada de emergência ou um retorno de chamada de PSAP tem prioridade mais alta, e/ou o UE enviar uma segunda mensagem contendo uma informação relacionada à emergência sobre si mesmo.

Em uma outra modalidade, um UE é provido, que inclui um processador configurado para reconhecer uma chamada de IMS como uma chamada relacionada à emergência originada por um PSAP, mediante o recebimento de uma primeira mensagem contendo um indicador. 0 processador é adicionalmente configurado para reconhecer o indicador como uma indicação que a chamada relacionada à emergência está relacionada a uma emergência, para invocar uma funcionalidade que a chamada relacionada à emergência está relacionada à emergência, e/ou se o UE estiver engajado em quaisquer outras sessões ou serviços estes serão suspensos, terminados ou mantidos rodando, mas colocados em uma prioridade mais baixa, isto é, uma QoS mudada ou caída, já que a chamada de emergência ou um retorno de chamada de PSAP tem prioridade mais alta, e/ou enviar uma segunda mensagem contendo uma informação relacionada à emergência sobre si mesmo.

Em uma outra modalidade, é provido um método para um componente de rede responder a uma chamada relacionada à emergência a partir de um UE. O método compreende o componente de rede colocar em uma primeira mensagem para o UE um indicador indicando que a chamada foi uma chamada relacionada à emergência, e o componente de rede receber a partir do UE uma segunda mensagem contendo uma informação relacionada à emergência sobre o UE.

Em uma outra modalidade, um componente de rede é provido, que inclui um processador configurado para, mediante o componente de rede receber uma chamada de emergência a partir de um UE, colocar em uma primeira mensagem para o UE um indicador indicando que a chamada era uma chamada de emergência. O processador ainda é configurado para receber uma segunda mensagem a partir do UE contendo uma informação relacionada à emergência sobre o UE.

Um usuário de um UE, tal como um UE capaz de IMS, tipicamente pode fazer uma chamada de emergência ao discar 911 (na América do Norte) , 112 (na maioria da Europa) , 999 (no Reino Unido), 110, 118 ou 119 (no Japão), ou algum outro número específico para emergência. Uma chamada como essa pode ser manipulada por um ponto de resposta de segurança pública (PSAP), o qual poderia ser uma central de chamada de emergência ou um sistema que pudesse coordenar uma resposta apropriada à emergência. Qualquer chamada feita para um PSAP pode ser referida aqui como uma chamada de emergência. Neste documento, um PSAP também poderia ser uma central de emergência ou centrais de emergência.

Em alguns casos, um UE poderia não estar ciente que uma chamada que ele fez era uma chamada de emergência. Por exemplo, um UE fabricado para uso na América do Norte poderia ser programado para reconhecer que uma chamada para 911 é uma chamada de emergência. Se esse UE fosse levado para um país em que um outro número além de 911 é usado para chamadas de emergência, e o usuário do UE discasse aquele outro número de emergência, o UE poderia não reconhecer a chamada como uma chamada de emergência. Resultados indesejáveis podem ocorrer, se o eu não reconhecer que uma chamada é uma chamada de emergência. Por exemplo, o UE poderia falhar em prover uma informação relevante para o PSAP, o UE poderia tratar a chamada como uma chamada regular e colocá-la em suspenso ou em espera de chamada, a chamada poderia ser bloqueada, ou o UE de outra forma poderia falhar em tratar a chamada apropriadamente.

Além disso, a rede pode não aplicar um tratamento especial, por exemplo, em uma rede ou célula congestionada, e a chamada de emergência não reconhecida pode não ser submetida a procedimentos de chamada de emergência (por exemplo, pode não receber prioridade).

A presente exposição provê uma indicação para um UE que uma chamada que o UE fez era uma chamada de emergência de IMS pela inclusão em uma mensagem para o UE de um indicador que a chamada era uma chamada de emergência. 0 indicador poderia ser incluído em uma mensagem de SIP que poderia ser, mas não está limitada a uma mensagem de SIP 2xx ou SIP Ixx enviada para o UE em resposta a uma requisição de SIP inicial para um diálogo ou uma transação independente, ou um método desconhecido (por exemplo, uma requisição SIP INVITE), ou uma mensagem similar, que o UE envia ao tentar estabelecer a chamada de emergência. A partir deste ponto, o termo "mensagem de SIP" pode se referir a uma requisição de SIP (incluindo, por exemplo, uma requisição re-INVITE ou uma requisição de atualização de alvo para um diálogo ou uma requisição de SIP inicial para um diálogo ou uma transação independente, ou um método desconhecido) ou uma resposta de SIP. Deve ser notado que a requisição de método de re-INVITE pode apenas ser enviada quando condições documentadas na Requisição para Comentários (RFC) 3261 da Força-Tarefa de Engenharia da Internet (IETF) forem satisfeitas. A mensagem de SIP que inclui o indicador poderia ser enviada pelo PSAP ou por um componente de uma rede através da qual o PSAP e o UE se comunicam um com o outro. Os exemplos desses componentes são P-CSCF e E-CSCF.

O indicador relacionado à emergência pode ser codificado em SIP usando-se as alternativas a seguir: a) corpos de SIP tais como "application/3gpp-ims+xml", têm sido usados em IMS para indicação de uma informação adicional ou diretivas para UAs de recebimento. Também pode ser estendido para indicar para o UE que, mediante o recebimento de uma requisição INVITE ou similar, a requisição é para ser tomada como uma chamada de emergência ou um retorno de PSAP e que a funcionalidade associada às chamadas desse tipo deve ser invocada. Esta funcionalidade pode incluir, mas não está limitada a alertar ao usuário por métodos visuais, audíveis ou outros, bem como incluir uma informação de localização na resposta. Um valor de campo de cabeçalho de disposição de conteúdo novo pode precisar ser definido. B) Um novo cabeçalho de SIP poderia ser definido ou um cabeçalho de SIP existente poderia ser melhorado. O PSAP em si ou a S-CSCF lidando com o retorno de PSAP em nome do PSAP ou um outro elemento de rede tal como um gateway de sinalização pode introduzir um indicador. C) O indicador poderia ser um campo de cabeçalho de SIP novo, d) O indicador poderia ser um valor de campo de cabeçalho de SIP novo, por exemplo, um SIP URN padronizado indicando a função de PSAP (por exemplo, resgate em montanha ou guarda costeira ou 911 geral) ou uma função de central de emergência ou uma função de equipe de emergência, e) O indicador poderia ser um campo de URI novo, f) O indicador poderia ser um valor de campo de URI novo, por exemplo, user = psap, onde 'user' é um campo de SIP URI e 'psap' é um novo valor que poderia ser colocado no campo de cabeçalho de Contato (Contact) . G) o SIP URN padronizado poderia ser colocado na P-Asserted-Identity pelo domínio de confiança no qual o PSAP ou a central de emergência ou a equipe de emergência reside. H) O indicador poderia estar contido no valor de campo de cabeçalho FROM e o valor de campo de cabeçalho FROM poderia ser avaliado de acordo com a RFC 4474 ou a RFC 3893. Esta solução é com base em certificados.

Conforme identificado acima, várias possibilidades poderiam ser usadas para se indicar que uma sessão é de fato uma sessão de emergência. Foi destacado que o PSAP poderia estar em uma rede visitada, tal como uma HPLMN (rede móvel em terra pública doméstica). Assumindo que este seja o caso quando o UE está estabelecendo uma sessão de espaço radial, o UE não reconhece ou quando recebendo uma requisição terminada móvel contendo uma indicação na mensagem de SIP (por exemplo, respostas Ixx ou 2xx ou uma requisição de atualização de alvo de SIP ou uma mensagem similar) que a requisição é um retorno de PSAP, o PSAP ou a rede também poderiam enviar de volta uma ficha que o UE armazenaria. A rede poderia prover esta ficha quando o UE se registrasse junto ao subsistema de rede de núcleo (CN) de IM. A ficha poderia ser armazenada na memória, a qual poderia ser interna ou removível. No caso de a chamada de emergência do UE ser desconectada ou o UE precisar ser informado que está requisitando uma sessão de emergência, a rede ou o PSAP poderia incluir esta ficha. Mediante o recebimento da ficha a partir da rede, o eu pode compará-la com a ficha compartilhada. Se as fichas não combinarem, o UE saberá que a chamada não está relacionada a uma emergência.

O campo de cabeçalho "priority" (prioridade) de SIP regulado para "emergency" (emergência) até agora não tem sido usado como um indicador de confiança para uma chamada de emergência [RFC 3261] . A base instalada de SIP UAs terá um tratamento diferente e divergente para este cabeçalho, se tiver qualquer tratamento.

No caso em que a resposta de retorno de chamada de PSAP ou de sinalização de chamada de emergência é recebida por uma rede de circuito comutado, a solução pode permitir o mapeamento entre um campo Calling-Party-Category apropriado, o qual às vezes é usado para portar a indicação de uma chamada de emergência em sistemas baseados em ISUP/TUP (parte de usuário de ISDN / parte de usuário de telefone). Tipicamente, a informação de sinalização de ISUP / TUP não permite uma granular idade tão fina quanto os identificadores de emergência urn:service:sos definidos na RFC 5031.

A Figura 1 ilustra um sistema 10 que inclui um ou mais componentes associados a uma rede de IMS 120. Um UE 110 pode ser qualquer dispositivo de usuário final ou sistema que possa se conectar à rede de IMS 120. Os exemplos do UE 110 podem incluir, mas não estão limitados a telefones móveis, telefones de linha fixa, dispositivos sem fio móveis (incluído dispositivos digitais, celulares ou dispositivos de modo duplo), assistentes digitais pessoais, computadores laptop / tablet / notebook, e computadores de mesa. O UE 110 pode se comunicar através da rede de IMS 120 com um PSAP 130, o qual pode ser um sistema de 911 ou uma outra central ou sistema de chamada de emergência.

A rede de IMS 120 poderia incluir qualquer conjunto bem conhecido de componentes, tais como estações bases e outro equipamento de transmissão e recepção de rádio, que pudesse promover uma conexão baseada em IMS entre o UE 110 e o PSAP 130. Outros componentes que poderiam estar presentes na rede de IMS 12 0, mas que não são mostrados incluem uma P-CSCF (função de controle de sessão de chamada de proxy) que pode ser o primeiro ponto de contato para o UE 110; uma S-CSCF (CSCF de serviço) que pode realizar um controle de sessão, uma transferência (via download) e uma transferência (via upload) de perfis de usuário, e outras funções; uma E-CSCF (CSCF de emergência) que pode prover funções de controle de sessão para o PSAP 130; e outros componentes bem conhecidos para iniciação e manutenção de sessões baseadas em IMS.

Para se fazer uma chamada de emergência, o UE 110 poderia enviar uma requisição de SIP inicial para um diálogo ou uma transação independente, ou um método desconhecido (por exemplo, uma requisição de SIP INVITE) 14 0, ou uma mensagem de convite similar, para o PSAP 13 0 através da rede de IMS 120. O PSAP 130 tipicamente responde à mensagem de convite com uma mensagem de resposta SIP Ixx ou SIP 2xx (por exemplo, SIP 200 OK) 150, ou uma mensagem de resposta similar. Alternativamente, o PSAP 130 poderia transmitir uma requisição de renovação de alvo (por exemplo, uma requisição re-INVITE). Os procedimentos padronizados de SIP então poderiam ser seguidos para o estabelecimento da chamada de emergência entre o UE 110 e o PSAP 130.

Em uma modalidade, a mensagem de resposta 150 inclui um indicador 160 que indica que a chamada feita pelo UE 110 era uma chamada de emergência. O indicador 160 pode ser um bit, um indicador tipo de flag, ou algum outro elemento de dados que seja reconhecível pelo usuário como uma designação que uma chamada feita pelo UE 110 era uma chamada de emergência (por exemplo, URNs de serviço de emergência, conforme especificado na RFC 5031, tal como urn:service:sos, urn:service:sos.animal-control, ou urn:service:sos.police, caso seja determinado que a chamada que foi feita pode ser categorizada, por exemplo, como uma chamada de urn: service: sos, uma chamada de API de urn:service:sos.animal-control, ou uma chamada de urn:service:sos.police). Quando o UE 110 recebe a mensagem de resposta 150 que inclui o arranjo magnético 260, o UE 110 identifica que a chamada que ele fez era uma chamada de emergência de IMS e, então, pode tomar medidas apropriadas e invocar uma funcionalidade para uma chamada de emergência. Uma medida que o UE 110 poderia tomar é indicar para o usuário do UE a natureza da chamada original. Isto é, o UE 110 poderia alertar ao usuário que a chamada era uma chamada de emergência. O alerta poderia ser uma mensagem que aparecesse na tela do visor do UE 110, um alerta visual ou audível, ou algum outro tipo de condição ambiental ou indicação da natureza da chamada. Outras medidas tomadas pelo UE 110 podem envolver a transmissão de uma mensagem de requisição de SIP 170, tal como uma mensagem SIP ACK ou SIP PRACK ou qualquer parte de requisição de SIP subseqüente do diálogo (incluindo requisições de atualização de alvo) ou uma requisição para um novo diálogo, onde a requisição para o diálogo usa o campo de cabeçalho SIP Target-Dialog com um valor regulado idêntico ao valor de identificador de diálogo correspondente para a sessão de emergência. No caso de envio de uma requisição para uma nova mensagem de diálogo 170 com o campo de cabeçalho SIP Target-Dialog regulado, ele pode indicar para o destinatário que o remetente está ciente de um diálogo existente com o destinatário, porque o remetente está no outro lado daquele diálogo, ou porque ele tem acesso aos identificadores de diálogo, o destinatário então pode autorizar a requisição com base nesta ciência. Sujeito a limitações de SIP, qualquer uma destas mensagens pode incluir uma informação na requisição como parte da informação disponível para o PSAP 130, se o destinatário for o PSAP 130. Conforme mencionado, a mensagem 170 poderia ser uma requisição de atualização de alvo de SIP, uma SIP UPDATE, uma mensagem SIP re-INVlTE 170, ou uma mensagem similar (reconhecimento) (por exemplo, SIP PRACK). A mensagem 170 pode incluir uma informação 180 sobre o UE 110, a ser descrita em maiores detalhes abaixo. Devido a limitações no protocolo de SIP, a informação 180 pode ser difundida por várias mensagens de SIP, por exemplo, alguma informação pode ser em requisições de SIP PRACK, algumas em respostas a requisições originadas por PSAP ou rede ou requisições de SIP UPDATE, e algumas em outras requisições de atualização de alvo de SIP. A informação 180 poderia ser pretendida para o PSAP 13 0 ou para um ou mais componentes na rede de IMS 120. A informação 180 opcionalmente poderia incluir um indicador tipo de flag ou outro indicador que indicasse que certa informação relacionada à emergência, tais como uma identificação, acesso a rede e informação de localização, não é para ser compartilhada (por exemplo, com o PSAP 130). Se um ou mais indicadores de privacidade forem regulados, a rede ainda poderia ser capaz de usar a informação relacionada à emergência para fins de roteamento ou para a provisão de um retorno de chamada anônimo.

Em uma outra modalidade, uma política poderia ser armazenada no UE 110. A política ou as políticas podem ser usadas para se determinar se a inclusão de um ou mais indicadores para requisição de privacidade quando se requisitarem sessões de emergência é permitida, ou se uma informação relacionada à emergência é provida quando um PSAP fizer um retorno de chamada, ou se é permitido requisitar privacidade quando uma informação relacionada à emergência for provida em resposta a um retorno de PSAP. A política poderia ser consultada quando o UE 110 quisesse divulgar uma informação que é sensível quanto à privacidade, tal como, mas não limitando, a localização. A política poderia ser provida por usuário, provida por operadora, ou ambos. Quando a informação é provida por usuário e provida por operadora, a operadora poderia prover uma política padrão, mas o usuário poderia ser capaz de suprimir esta política, caso assim o desejasse. A política pode ser armazenada em uma memória que é interna ou externa para o dispositivo.

É possível que a política / preferência pudesse ser estabelecida de forma tal que fosse contra as exigências regulamentares de PSAP. Por exemplo, o UE 110 poderia vir de um país em que ele pode escolher se é ou não para prover uma informação relacionada a usuário ou relacionada a evento, e a política / preferência pode ser regulada de modo que a informação não seja provida. Alternativamente, a política / preferência pode ser regulada de modo que a informação possa ser provida (por exemplo, para fins de determinação do PSAP mais próximo), mas uma requisição poderia ser feita que a informação não seja liberada. O UE 110 pode subsequentemente ir para um país em que por lei uma informação de localização deve ser provida, caso disponível. Nesses casos, a rede poderia sinalizar para o UE 110 que a política / preferência é suprimida e que a informação deve ser provida. Esta notificação de supressão poderia ser sinalizada como uma ficha em uma mensagem a partir da rede. Por exemplo, uma mensagem de SIP poderia conter uma ficha que fosse codificada como um novo tal de recurso, um novo parâmetro de URI, um corpo em XML, um parâmetro de SDP, ou um recurso de codificação similar. A ficha também poderia precisar da propriedade de ela poder ser de confiança para o UE 110.

O que vem a seguir ilustra uma modalidade possível de como o UE 110 pode se comportar.

O procedimento básico será Política / preferência regulada Mensagem recebida a partir de rede contendo ficha de supressão

Consultar preferência / política

Permitir prover informação de localização Não permitido determinar se ficha é recebida Ficha recebida avaliar autenticação de ficha e, caso válida, prover informação de localização

Ficha recebida, falsa, prover indicação para rede de ficha falsa recebida, não prover informação de localização.

A ficha poderia ser portada em um retorno de chamada do PSAP 130, tal como um SIP INVITE. Alternativamente, a ficha poderia ser provida no momento em que o UE 110 fizesse um registro junto à rede 120, de modo que em IMS a ficha pudesse ser provida em uma mensagem SIP 200 OK, se a ficha fosse codificada como um novo tag de mensagem, um novo parâmetro de URI, ou um corpo em XML, a ficha poderia ser uma ficha segura. Em uma rede de LTE/SAE, a mensagem 200 OK poderia ser transmitida em resposta a uma requisição para afixação à rede ou como parte da sequência de autenticação do UE 110.

Uma outra modalidade é que a política de VPLMN poderia ser difundida em uma mensagem de sistema indicando o comportamento do UE, caso ele receba um retorno de chamada de emergência.

O aprovisionamento da política pode ser realizado, mas não está limitado a uma das formas a seguir: OMA, DM, CP, OTA, proprietária ou outra. Quando é aprovisionada, qualquer um dos transportes a seguir poderia ser usado: difusão de célula, SMS, USSD, MBMS, tubo de IP genérico, ou outro.

A política poderia ser armazenada em uma memória interna ou externa. Uma memória externa poderia ser, mas não está limitada a Placa de PC PCMCIA, CompactFlash I CF- I, CompactFlash II CF-II, SmartMedia SM/SMC, Memory Stick MS, Memory Stick Duo MSD, Memory Stick PRO Duo MSPD, Memory Stick PRO-HG Duo MSPDX, Memory Stick Micro M2, Placa de Multimídia MMC, Placa de Multimídia RS-MMC, placa MMCmicro, cartão digital seguro SD, SxS SxS, Armazenamento Flash Universal UFS, cartão miniSD, cartão microSD, placa xD- Picture xD, Stick Inteligente iStick, Módulo Flash Serial SFM, microplaca pcard, placa de NT NT+, USIM, R-UIM, etc.

Em uma modalidade da informação de política, haveria um arquivo na memória removível consistindo em oito bits para cada arquivo. O bit 1 (o bit menos significativo) poderia ser regulado para 1 para indicar que uma informação de localização é para ser provida, ou para 0 para indicar que uma informação de localização não é para ser provida. Todos os sete bits remanescentes poderiam ser reservados (RFU) . O arquivo de preferência de usuário poderia estar sob controle de PIN (isto é, o usuário poderia, após introduzir o PIN, controlar o conteúdo do arquivo), e o arquivo de operadora poderia estar sob um controle ADM (administrativo), impedindo que qualquer outra parte, além do administrador (o emissor de cartão, usualmente a concessionária) alterasse o conteúdo do arquivo.

Em várias modalidades, a política pode ser implementada em formatos diferentes. Um exemplo de um formato para a política é provido abaixo, mas os formatos não devem ser limitados por este exemplo, já que outros formatos são contemplados. /<X>/ Política de localização de emergência mediante retorno de chamada de PSAP/

A folha de política de localização de emergência indica se o UE provê uma informação de emergência ou não para um retorno de chamada de emergência. • Ocorrência: uma • Formato: booleano • Tipos de Acesso: Get, Replace • Valores: 0, 1 0 - o UE provê uma informação de emergência. 1 - o UE não provê uma informação de emergência. <Node> <NodeName> Emergency Location policy </NodeName> <DFProperties > <AccessType> <Get/> <Replace/> </AccessType> <DFFormat> <bool/> </DFFormat> <Occurrence> <0ne/> </Occurrence> <DFTitle> Emergency Location policy </DFTitle> <DFType> <MIME>text/plain</MIME> </DFType> </DFProperties> </Node

Conforme mencionado previamente, quando o UE 110 recebe a mensagem de resposta 150 que inclui o indicador 160, o UE 110 poderia transmitir uma informação 180 sobre si mesmo para o PSAP 130. Se a política permitir, um pedaço da informação 180 que o UE 110 poderia incluir na mensagem de requisição de SIP 170 é aquele das identidades de usuário públicas de UE (tal como Tel URI, SIP URI, ou número ISDN internacional de estação móvel (MSISDN)), ou algum outro símbolo de identificação. A inclusão dessa informação poderia estar sujeita à política ou poderia ser realizada por um indicador que uma informação privada não é compartilhada com o PSAP ou a central de emergência ou elementos de rede não de confiança. As identidades de usuário públicas poderiam ser no formato GRUU ou poderiam conter uma informação suficiente para que uma tecnologia de retorno de chamada por comutador de circuito seja possível, por exemplo, no formato Tel URI. O PSAP 13 0 pode usar o identificador para fazer um retorno de chamada para o UE 110, se necessário, conforme descrito abaixo. Um outro pedaço de informação 180 que o UE 110 poderia transmitir na mensagem de reconhecimento 170 é o tipo de acesso que o UE 110 está usando. Por exemplo, se a chamada de emergência fosse feita por uma rede de área local (LAN) sem fio, o UE 110 poderia incluir esse fato na informação 180, bem como um ID de célula, um ID de linha e/ou um ID de nó de acesso de LAN sem fio. Durante o diálogo, os pontos de anexação à rede de acesso de conectividade de IP (IP-CAN) do UE podem mudar (por exemplo, o usuário se conecta a células diferentes). O UE pode preencher o cabeçalho P-Access- Network-Info com qualquer requisição ou resposta em um diálogo para o qual uma transmissão dessa informação é suportada (por exemplo, excluindo requisições de ACK e requisições e respostas de CANCEL), com o ponto de anexação atual à IP-CAN (por exemplo, a informação sobre a célula atual).

Se o UE 110 estiver ciente de sua localização geográfica, por exemplo, através do uso de um sistema de posicionamento global (GPS), o UE 110 poderá incluir sua localização como um outro pedaço da informação 180, tais como, mas não limitando, uma identidade global de célula (CGI), um identificador de regulagem de serviço (SSID), pontos de espera, tais como marcos geográficos, e a intensidade de sinal de células adjacentes com CGIs correspondentes. Se o UE 110 não estiver ciente de sua localização geográfica, dados relacionados à localização não serão incluídos na informação 180. Se um URI (identificador de recurso uniforme) de GRUU (UA (agente de usuário) roteável globalmente) estiver associado ao UE 110, o GRUU de UE poderá ser incluído como um outro pedaço da informação 180. Dependendo das regulagens de privacidade do usuário, o GRUU poderá ser um P-GRUU ou um T-GRUU, embora um GRUU público (P-GRUU) seja preferido em relação a um GRUU temporário (T-GRUU).

Outros itens que podem ser incluídos na informação 180 poderiam incluir as capacidades do sistema de acompanhamento de uso de material 100, a tecnologia de acesso por rádio sendo usada pelo UE 110, a vida da bateria do UE 110, a intensidade do sinal e a identidade de rede (por exemplo, CGI, SSID, SID) . 0 UE 110 também poderia invocar o que é comumente conhecido como uma funcionalidade ecall a ser enviada para o PSAP 130.

Antes de a requisição de emergência alcançar o PSAP 130, ela poderia ser manipulada por um ou mais componentes na rede de IMS 120. Um desses componentes é a P-CSCF. Um componente de rede de IMS pode inspecionar todas as requisições, de modo a determinar se elas estão relacionadas a emergências. Se uma requisição for determinada como estando relacionada a uma emergência, com base em configurações e políticas reguladoras, o componente de rede poderá determinar que é para rejeitar ou reformatar a requisição ou incluir o indicador de chamada de emergência 160 em uma resposta de SIP que é enviada para o UE 110. Uma reformatação da requisição poderia ser feita se o UE provesse um T-GRUU e as regulagens de política de operadora de rede (por exemplo, na P-CSCF) indicassem que as identidades de usuário públicas devem ser providas. Nesse caso, a T-GRUU pode ser substituída pela GRUU. Além disso, uma reformatação das mensagens a serem roteadas para os PSAPs poderia ser feita se a mensagem contivesse campos de cabeçalho P-Preferred-Service, campos de cabeçalho P- Asserted-Service, campos de cabeçalho Accept-Contact contendo um valor de identificador de serviço de comunicação de IMS (ICSI) (codificado conforme especificado no subitem 7.2A.8.2 na 3GPP TS 24.229) e zero ou mais valores de identificador de referência de aplicação de IMS (IARI) (codificados conforme especificado no subitem 7.2A.9.2 na 3GPP TS 24.229) que estão relacionados à requisição em um tag de recurso g.3gpp.app_ref. Os campos de cabeçalho P-Preferred-Service, os campos de cabeçalho P- Asserted-Service não devem ser encaminhados para o PSAP ou a central de emergência. Os campos de cabeçalho Accept- Contact devem ser arrumados para valores de ICSI e valores de IARI, já que eles podem causar interações quando da seleção de um agente. Se o campo de cabeçalho Accept- Contact contiver tags de performance de mídia g.3gpp.app_ref, eles e seus valores deverão ser removidos.

Em outras palavras, o que é denominado "reformatação" pode incluir mudar o GRUU a partir de um GRUU temporário para um GRUU público. Isto é feito porque um GRUU temporário é inválido, se o UE for desconectado e tiver que se registrar de novo. Um PSAP não pode fazer um retorno de chamada para um GRUU temporário, após o UE sair de registro e se registrar de novo. Os GRUUs públicos, por outro lado, têm a propriedade de eles serem roteáveis, mesmo após o UE sair de registro e se registrar de novo (tornando um retorno de chamada de PSAP para aquele GRUU público com maior probabilidade de se completar). Uma "reformatação" também pode incluir uma não propagação de tags de recurso de ICSI ou IARI, os campos de cabeçalho P-Preferred-Service e/ou os campos de cabeçalho P-Asserted-Service. A presença desses tags ou campos poderia distorcer a manipulação da requisição no PSAP e fazer com que a requisição fosse roteada com base em serviços suportados no UE, ao invés de, por exemplo, na proximidade geográfica e no tipo de serviço requisitado. Uma vez que tipicamente há uma S-SCSF no percurso de sessão entre o UE, a P-CSCF, a E-CSCF e o PSAP, estes serviços que o UE supostamente suporta tipicamente não são ativados durante a chamada de emergência. Assim, uma sinalização dele como parte de uma requisição de emergência (mesmo quando o UE não percebeu que é uma requisição de chamada e incluir tags de recurso de ICSI ou IARI, campos de cabeçalho P-Preferred-Service e/ou os campos de cabeçalho P-Asserted-Service, porque ele acredita que a requisição que ele faz é uma requisição normal) não serve a qualquer finalidade e pode apenas prejudicar / resultar em um roteamento das requisições para outros PSAPs além daqueles determinados com base em localização, tipo de serviço requisitado e procedimentos da RFC 3261. Em um caso de pior cenário, se uma operadora de PSAP registrar seu suporte para os referidos serviços, ela poderá receber uma carga mais alta de requisições de serviço de emergência do que as outras operadoras de PSAP, possivelmente levando a um atraso na resposta de emergência.

Em modalidades em que um componente na rede de IMS 120 rejeita a requisição de serviço de emergência, ele pode responder com uma mensagem SIP 3xx, tal como 300 (escolhas múltiplas), 3 01 (movido permanentemente) , 3 02 (movido temporariamente), 380 (serviço alternativo) ou uma resposta SIP 4xx ou uma resposta SIP 6xx. Uma SIP 380 (serviço alternativo) é usada preferencialmente para indicar que o UE deve tentar uma outra tecnologia de acesso, tal como CS, ou usar / criar um outro contexto / registro seguro, tal como o contexto criado pelo registro de emergência. A mensagem também pode ser usada para informar ao UE para não usar o presente contexto (o qual poderia ter sido criado como resultado de um registro de emergência).

O que vem a seguir são casos em que a rede pode ser configurada para rejeitar a requisição: a) a rede não é capaz de lidar com sessões de emergência; b) o subsistema de CN de IM ao qual a P-CSCF pertence não é capaz de lidar com sessões de emergência; c) devido à política local, a rede não lida com sessões de emergência; d) a rede apenas lida com certos tipos de requisições de sessão de emergência; e) o UE está em roaming; f) a P-CSCF está em uma rede diferente que não a rede da operadora doméstica do UE; g) a rede não suporta sessões de emergência para a localização geográfica em que o UE está localizado ou a IP- CAN à qual o UE está anexado.

Deve ser notado que uma resposta de redirecionamento 3xx pode ser válida ou roteável na rede anexada atualmente apenas. Por exemplo, urn:service:sos.animal-control pode ser válido no catálogo de endereços apenas para algumas redes às / junto às quais o UE 110 pode se anexar / registrar. O uso de um endereço no catálogo de endereços pode ser condicional à operadora ou à região na qual o UE 110 está anexado / registrado. Uma resposta 3xx forçando o UE a usar um outro endereço para esta requisição relacionada à emergência ou uma requisição determinada como não estando relacionada a uma emergência não deve ser seguida simplesmente pela mudança da entrada correspondente do catálogo de endereços, caso presente, no catálogo de endereços.

Dois exemplos ilustram os casos em que a rede rejeita a requisição porque o tipo de requisição de sessão de emergência não é suportado. No primeiro exemplo, a RFC 5031 define urn:service:sos.animal-control como se segue: o controle de animais tipicamente faz cumprir leis e posturas eferentes a controle e administração de animais, investiga casos de abusos a animais, educa a comunidade quanto a uma propriedade responsável de animais de estimação e cuidados com a vida selvagem, e provê alojamento e cuidados para animais abandonados, dentre outros serviços relacionados a animais. Em algumas jurisdições, uma requisição para urn:service:sos.animal-control pode ser classificada como uma emergência no sentido que está sujeita a procedimentos de emergência de rede e operadora (por exemplo, habilitar ou desabilitar uma requisição para urn:service:sos.animal- control quando o UE não se registrou ou tem credenciais insuficientes). Se for configurada assim, a rede poderia rejeitar uma indicação que a chamada não é realmente uma emergência ou poderia rejeitar com uma indicação que a chamada não é uma emergência e oferecer medidas alternativas a serem executadas, tais como a oferta de um URI diferente a contatar e/ou um endereço de rede de CS diferente, tal como uma seqüência de dígitos. Note que, uma vez que as URNs de serviço de emergência não são roteáveis e não são números E.164, o UE pode não ser capaz de prosseguir carecendo de conhecimento de endereços ou números roteáveis. Nessas jurisdições, seria impróprio se o UE executasse procedimentos de emergência (conforme especificado na 3GPP TS 24.008) e um UE não deve contatar automaticamente, por exemplo, "911" ou "112" ao receber uma rejeição quando contatando, por exemplo, urn:service:sos.animal-control.

Note que é possível que um UE habilitado para CS tenha recebido uma lista de números de emergência de CS locais (por exemplo, recebido um resultado do procedimento Location-Update (Atualização de Localização)). Um UE poderia indicar o tipo requisitado de serviço de emergência em uma requisição de emergência de CS e ser conectado ao PSAP requisitado usando procedimentos na 3GPP TS 24.008. Por exemplo, existe a tabela a seguir: Tabela 10.5.135d/3GPP TS 24.008: Elemento de Informação de Categoria de Serviço

Contudo, no presente, nenhum mapeamento para 25 urn:service:sos.animal-control existe. Um mapeamento para alguns outros serviços de emergência, conforme definido em RFC 5031 (por exemplo, urn: service: sos .police) pode ser feito pela regulagem do bit correspondente no valor de categoria de emergência (por exemplo, 3 0 urn: service: sos .police se mapeia para o Bit 1 do valor de categoria de serviço de emergência, urn: service: sos. ambulance se mapeia para o Bit 2 do valor de categoria de serviço de emergência, urn:service:sos.fire se mapeia para o Bit 3 do valor de categoria de serviço de emergência, urn:service:sos.marine se mapeia para o Bit 4 do valor de categoria de serviço de emergência, urn:service:sos.mountain se mapeia para o Bit 5 do valor de categoria de serviço de emergência). urn:service:sos.animal-control, urn:service:sos.physician, urn:service:sos.poison, urn:service:sos.gas, e outros poderiam se mapear para urn valor de categoria de serviço de emergência sem bits regulados para "1", fazendo com que a chamada fosse roteada para uma central de emergência padronizada definida por operadora. Alternativamente, para requisições para as quais nenhum PSAP é suportado na rede, o UE poderia ser instruído para fazer uma requisição de SIP normal (usando procedimentos em 3GPP TS 24.228) ou estabelecer uma chamada de CS normal (usando procedimentos em 3GPP TS 24.008) . A rede poderia realizar isso ao não indicar um endereço alternativo que não pode ser mapeado para um valor de categoria de serviço de emergência (isto é, não um dos URNs urn: service: sos para os quais um mapeamento é padronizado). Quando uma requisição de emergência é recebida pelo PSAP, mas o PSAP não pode lidar com a requisição e retorna uma SIP 380 ou uma mensagem similar, se um mapeamento existir no UE a partir do dado urn para um valor de categoria de serviço de emergência, uma deverá ser estabelecida para aquele número E.164 de PSAP de CS automaticamente.

No segundo exemplo: a P-CSCF pode determinar que a requisição de emergência é feita para urn:service:sos.police. Contudo, por exemplo, nos Países Baixos, contatar a polícia por definição não garante a ativação de procedimentos de emergência. Ao invés disso, um número especial diferente de "112" é configurado: 0900- 8844. Outros exemplos são "19" Polícia (Albânia), "100" (Polícia e Corpo de bombeiros (cidades gregas)), "100" (Ambulância e Corpo de bombeiros (Bélgica)), "112" (Polícia e Ambulância (Itália)), "112" (chamada de emergência geral, todas as categorias (Suécia)), "115" (Corpo de bombeiros (Itália)), "144" (Ambulância (Áustria)), "*377" (delegacia de polícia local ou departamento de escritório de segurança pública, assistência não de emergência em estradas no Texas) . Um número como esse pode ser um serviço especial. Ele poderia ser impróprio se o UE automaticamente contatasse, por exemplo, "911" ou "112", se a rede rejeitasse a chamada para to urn:service:sos.police, e poderia ser imprópria se a rede automaticamente contatasse, por exemplo, 0900-8844 como uma chamada regular, já que o usuário, sem percebê-lo, pode automaticamente, então, receber cobranças especiais. A P-CSCF poderia prover medidas alternativas, tal como prover uma sequência de dígitos, por exemplo, 0900-8844, em uma resposta SIP 3xx. Contudo, a seqüência de dígitos deve ser exibida e/ou uma mensagem textual deve ser exibida, para indicar a natureza da chamada que foi feita e a natureza do número provido.

Em uma modalidade, a P-CSCF tem listas configuráveis com identificadores de serviço de emergência de parceiros em roaming, os quais indicam por identificador de serviço de emergência o manuseio. Quando rejeita a requisição, uma lista configurável de URIs de serviço de emergência alternativo pode ser incluída na resposta, por exemplo, sinalizada como parte do campo de cabeçalho SIP Contact. Estes serviços de emergência alternativos podem ser anotados com uma informação alfanumérica que pode ser exibida, por exemplo, quando sinalizada como parte do campo de cabeçalho SIP Contact. Os serviços de emergência alternativos também podem ser identificados, usando-se um corpo em XML com elementos em XML e atributos em XML, conforme sendo exibido apenas se requerido.

Em ainda uma outra modalidade, o P-CSCF não rejeitará a requisição por um tipo de serviço de emergência não suportado (tal como urn:service:sos.poison), mas o preparará para encaminhamento para a S-CSCF de rede doméstica de usuário usando procedimentos normais (em oposição ao encaminhamento dela para um E-CSCF). A S-CSCF de rede doméstica de usuário então deve ser configurada para lidar com o valor de URI de requisição não roteável. A rede de IMS também pode ser configurada para se levarem em consideração usuários em roaming requisitando uma sessão com urn:service:sos.police, de modo que o serviço requisitado por um UE, ò qual pode estar do outro lado do mundo, ainda possa ser manipulado de uma maneira tempestiva e efetiva. A rede de IMS poderia prover uma indicação em uma mensagem de SIP para o UE que a chamada foi determinada como não sendo uma chamada de emergência e que sua manipulação será diferente. A indicação poderia ser um indicador tipo de flag e/ou uma informação alfanumérica. Possíveis codificações deste tipo de indicador são dadas neste documento.

Retornando ao caso em que um componente de rede de IMS determina que o UE 110 iniciou uma chamada de emergência sem reconhecê-la como tal, em algumas modalidades, a rede de IMS 120 inclui o indicador de chamada de emergência 160 em uma resposta de SIP que é enviada para o UE 110. Neste caso, o indicador 160 é provido durante a fase de sinalização de estabelecimento de chamada. Em outras modalidades, o indicador de chamada de emergência 160 é incluído em uma mensagem que se origina no PSAP 130. A rede de IMS 120 então transfere a mensagem do PSAP 130 para o UE 110.

Em outras modalidades, se um componente da rede de IMS 120 incluir o indicador de chamada de emergência 160 na resposta de SIP que é enviada para o UE 110, o UE 110 pode abortar a sinalização atual e iniciar procedimentos de estabelecimento de chamada de emergência regulares, o que pode envolver originar uma chamada por uma rede de circuito comutado, se capaz e disponível, ou após iniciar procedimentos de registro de emergência, ou enviar uma requisição de SIP INVITE contendo um indicador que indica que a requisição de SIP INVITE é uma requisição de chamada relacionada à emergência e contendo uma informação relacionada à emergência sobre si mesmo.

Uma informação que é similar à informação 180 que o UE 110 inclui na mensagem de requisição de SIP 170 poderia ser incluída pelo UE 110 em uma mensagem enviada sob circunstâncias diferentes. Isto é ilustrado na Figura 2, onde o UE 110, a rede de IMS 120 e o PSAP 130 estão presentes de novo. Contudo, neste caso, o PSAP 130 inicia um retorno de chamada para o UE 110. Conforme é bem conhecido na técnica, após uma chamada de emergência ser terminada, o PSAP 130 pode fazer um retorno de chamada para o UE 110 por várias razões. Por exemplo, se a chamada de emergência parecesse ter terminado de forma anormal, o PSAP 130 poderia chamar o UE 110 de novo para determinar se o usuário do UE deseja levar qualquer informação adicional. Alternativamente, o PSAP 130 poderia chamar o usuário de volta para perguntar por uma informação que não foi requisitada inadvertidamente na chamada inicial. Outras razões para um retorno de chamada a partir do PSAP 130 para uma parte chamando em emergência após o término de uma chamada de emergência podem ser familiares para alguém de conhecimento na técnica.

O PSAP 130 poderia iniciar o retorno de chamada pelo envio de uma mensagem SIP INVITE 210, ou uma mensagem similar, para o UE 110 através da rede de IMS 120. Em uma modalidade, a mensagem SIP INVITE 210 contém um indicador 220 que indica que a mensagem SIP INVITE 210 está relacionada a um retorno de chamada de emergência. O indicador 220 poderia ser substancialmente similar ao indicador 160 da Figura 1 ou poderia ser algum outro tipo de indicador. O UE 110 pode reconhecer que o indicador 220 é uma indicação de um retorno de chamada de emergência a partir do PSAP 130, e pode responder ao indicador 220 apropriadamente ao invocar uma funcionalidade de retorno de chamada de emergência, sujeito às políticas. Em uma modalidade, a resposta da UE 110 ao recebimento do indicador 220 é substancialmente similar à resposta que o UE 110 teve ao receber o indicador 160 da Figura 1.

Por exemplo, uma ação que o UE 110 poderia tomar ao reconhecer o indicador 220 seria indicar de forma visual ou audível a natureza da sessão para o usuário. Isto é, o UE 110 poderia alertar ao usuário que a chamada entrando é um retorno de chamada de emergência. O alerta poderia ser uma mensagem que aparecesse na tela de visor do UE 110, ou algum outro tipo de indicação da natureza da chamada. Outras ações feitas pelo UE 110 podem envolver a transmissão de uma resposta SIP 2xx ou Ixx (por exemplo, uma resposta SIP 200 (OK)) 230, ou uma mensagem similar, que inclua uma informação 240 sobre o UE 110, sujeita às políticas. Alternativamente, devido a limitações na SIP, a informação 240 pode ser transmitida por várias mensagens de SIP ou mensagens de rede (por exemplo, uma informação de identidade de IP-CAN provida por UE pode não ser completamente confiável e, daí, um mecanismo com base em provisão de rede (por exemplo, usando-se um controle de política e cobrança (PCC)) pode prover essa informação) ou em uma requisição de atualização de alvo, tal como uma requisição de SIP re-INVITE ou uma requisição de UPDATE ou parcialmente em uma requisição de SIP PRACK. A informação 240 poderia ser substancialmente similar à informação 180 que o UE 110 proveu mediante o recebimento do indicador 160 da Figura 1.

Um pedaço da informação 24 0 que o UE 110 poderia enviar para o PSAP 130 é a identidade de usuário pública de UE ou algum outro símbolo de identificação. Um outro pedaço de informação 240 que o UE poderia transmitir na mensagem de SIP 200 OK 230 é o tipo de acesso que o UE 110 usou para a chamada de emergência original. Por exemplo, se a chamada de emergência fosse feita por uma LAN sem fio, o UE 110 poderia incluir esse fato na informação 240, bem como um ID de célula, um ID de linha e/ou um ID de nó de acesso de LAN sem fio.

Se o UE 110 estiver ciente de sua localização geográfica, por exemplo, através do uso de um sistema de GPS, o UE 110 poderá incluir sua localização como um outro pedaço da informação 240. Se o UE 110 não estiver ciente de sua localização geográfica, dados relacionados à localização não serão incluídos na informação 240. Se um GRUU estiver associado ao UE 110, o GRUU de UE poderá ser incluído como um outro pedaço da informação 240.

Em uma modalidade alternativa, o PSAP 130 poderia estabelecer uma chamada de circuito comutado (CS) e um gateway de CS poderia então converter a chamada e a sinalização em uma tecnologia de pacote comutado, se a chamada de CS for roteada para o gateway de CS. Disparado pela chamada entrando a partir do PSAP 130, o gateway de CS poderia iniciar o retorno de chamada pela tecnologia de pacote comutado pelo envio de uma mensagem SIP INVITE 210, ou uma mensagem similar, para o UE 110 através da rede de IMS 120.

A Figura 3 ilustra uma modalidade de um método 300 para um UE responder a uma mensagem relacionada à emergência enviada para o UE. No bloco 310, o UE recebe uma mensagem contendo um indicador que indica que uma chamada relacionada à emergência foi feita. Em alguns casos, a chamada relacionada à emergência pode ter sido feita pelo UE sem o UE estar ciente que a chamada estava relacionada a uma emergência. Em outros casos, a chamada relacionada à emergência poderia ser um retorno de chamada de um PSAP para o UE em resposta a uma chamada de emergência prévia a partir do UE. No bloco 320, o UE reconhece o indicador como uma indicação que sua primeira mensagem (requisição de SIP inicial para um diálogo ou uma transação independente, ou 5 um método desconhecido ou uma mensagem similar) está relacionada a uma emergência. Opcionalmente, no bloco 330, o UE provê uma indicação visual, audível ou outra para o usuário do UE que a chamada relacionada à emergência está relacionada a uma emergência. No bloco 34 0, o UE envia uma 10 mensagem contendo uma informação relacionada a uma emergência sobre si mesmo.

A exposição descrita aqui poderia ser implementada como uma ou mais modificações para a especificação técnica (TS) do projeto de parceria de terceira geração (3GPP) 15 24.229 "Internet Protocol (IP) Multimedia Call Control

Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". Adições propostas e modificações na TS 24.229, de acordo com várias modalidades da presente exposição, são providas abaixo. 20 A adição a seguir à 3GPP TS 24.229 aplica-se à requisição INVITE inicial no caso de origem em UE de uma iniciação de chamada:

No caso em que o UE recebe uma resposta 380 (Serviço Alternativo) a uma requisição de INVITE, a resposta 25 contendo um corpo em XML que inclui um elemento alternative service> com o atributo "alternate" do elemento filho <type> contendo um ou mais URIs de serviço de emergência, o UE pode tentar uma chamada normal, conforme descrito no subitem 5.1.3.1, usando um URI de 30 serviço de emergência ou usando um estabelecimento de chamada de acordo com o procedimento descrito em 3GPP TS 24.008 [8]. O comportamento do UE é específico de implementação se o atributo "alternate" do elemento filho <type> estiver ausente ou não contiver nenhum URI de serviço de emergência.

A modificação a seguir na 3GPP TS 24.229 se aplica ao serviço de emergência geral: A P-CSCF deve armazenar uma lista configurável de identificadores de serviço de emergência local, por exemplo, números de emergência e o URN de serviço de emergência, os quais são válidos para a operadora à qual a P-CSCF pertence. Além disso, a P-CSCF deve armazenar uma lista configurável de identificadores de serviço de emergência de parceiros de roaming. As listas configuráveis com identificadores de serviço de emergência de parceiros locais e de roaming devem indicar um manuseio por identificador de serviço de emergência. Quando o manuseio indica que a requisição deve ser rejeitada, uma lista configurável de URIs de serviço de emergência alternativos pode ser incluída na resposta.

A adição a seguir à 3GPP TS 24.229 se aplica ao tratamento geral para todos os diálogos e transações independentes, excluindo-se o método REGISTER após um registro de emergência: Se a P-CSCF detectar que o Request-URI da requisição inicial para um diálogo ou uma transação independente, ou um método desconhecido combinar com um tipo não suportado de emergência nos identificadores de serviço de emergência de VPLMN ou HPLMN, a P-CSCF deve: - responder à requisição INVITE com uma resposta 380 (Serviço Alternativo); - assumir que o UE suporta uma versão 1 do esquema de XML para um corpo em XML de subsistema de IM CN, caso um suporte para o corpo em XML de IMS de 3GPP no cabeçalho Accept não seja indicado; e - incluir na resposta 380 (Serviço Alternativo): - um campo de cabeçalho Content-Type com o valor regulado para o tipo de MIME associado do corpo em XML de IMS de 3GPP, conforme descrito no subitem 7.6.1. O corpo deve conter: a) um elemento <alternative-service>, regulado para os parâmetros do serviço alternativo; b) se o cabeçalho Accept indicar um suporte para a versão 2 do esquema de XML para o corpo em XML de subsistema de IM CN - então, um elemento filho <type> com um atributo "alternate" regulado para uma lista de URIs de serviço de emergência alternativo, - caso contrário, um elemento filho <type>, regulado para "emergency "; c) um elemento filho <reason>, regulado para uma razão configurável por operadora.

A adição alternativa a seguir à 3GPP TS 24.229 se aplica ao tratamento geral para todos os diálogos e transações independentes, excluindo-se o método REGISTER após um registro de emergência:

Se a P-CSCF detectar que o Request-URI da requisição inicial para um diálogo ou uma transação independente, ou um método desconhecido combinar com um tipo não suportado de emergência nos identificadores de serviço de emergência de VPLMN ou HPLMN, a P-CSCF deve: - responder à requisição INVITE com uma resposta 380 (Serviço Alternativo) ; - assumir que o UE suporta uma versão 1 do esquema de XML para um corpo em XML de subsistema de IM CN, caso um suporte para o corpo em XML de IMS de 3GPP no cabeçalho Accept não seja indicado; e - incluir na resposta 380 (Serviço Alternativo): - um campo de cabeçalho Content-Type com o valor regulado para o tipo de MIME associado do corpo em XML de IMS de 3GPP, conforme descrito no subitem 7.6.1. O corpo deve conter: a) um elemento <alternative-service>, regulado para os parâmetros do serviço alternativo; b) um elemento filho <type> com um atributo "alternate" regulado para uma lista de URIs de serviço de emergência alternativo, c) um elemento filho <reason>, regulado para uma razão configurável por operadora.

A modificação a seguir à 3GPP TS 24.229 se aplica ao tratamento geral para todos os diálogos e transações independentes, excluindo-se o método REGISTER para um registro não de emergência:

Se a P-CSCF receber uma requisição inicial para um diálogo, ou uma transação independente, ou um método desconhecido, para um usuário registrado, a P-CSCF deve inspecionar o URI de requisição independentemente de valores de possíveis entradas nos cabeçalhos Route recebidos para identificadores de serviço de emergência conhecidos, isto é, números de emergência e o URN de serviço de emergência a partir destas listas configuráveis. Se a P-CSCF detectar que o Request-URI da requisição inicial para um diálogo, ou uma transação independente, ou um método desconhecido, combina com um dos identificadores de serviço de emergência em qualquer uma destas listas, a P-CSCF deve: 0) determinar a localização geográfica do UE. Procedimentos específicos de tecnologia de acesso são descritos em cada anexo específico de tecnologia de acesso. Se a P-CSCF não for capaz de lidar com sessões de emergência ou devido a uma política local não lida com sessões de emergência ou apenas lida com um certo tipo de requisição de sessão de emergência ou a IP-CAN à qual o UE é anexado ou o UE está em roaming, ou a P- CSCF está em uma rede diferente da rede de operadora doméstica do UE, então, a P-CSCF: - deve rejeitar a requisição ao retornar uma resposta 380 (Serviço Alternativo) para o UE; - deve assumir que o UE suporta uma versão 1 do esquema de XML para um corpo em XML de subsistema de IM CN, caso um suporte para o corpo em XML de IMS de 3GPP no cabeçalho Accept não seja indicado; e - deve incluir na resposta 380 (Serviço Alternativo) .- - um campo de cabeçalho Content-Type com o valor regulado para o tipo de MIME associado do corpo em XML de IMS de 3GPP, conforme descrito no subitem 7.6.1. O corpo deve conter: a) um elemento <alternative-service>, regulado para os parâmetros do serviço alternativo; b) se o cabeçalho Accept indicar um suporte para a versão 2 do esquema de XML para o corpo em XML de subsistema de IM CN - então, um elemento filho <type> com um atributo "alternate" regulado para uma lista de URIs de serviço de emergência alternativo, e - se a requisição inicial para um diálogo, ou transação independente, ou método desconhecido foi para um tipo suportado de emergência, o elemento filho <type> será regulado para "emergency", para indicar que ele foi uma chamada de emergência suportada, - caso contrário, um elemento filho <type>, regulado para "emergency"; c) um elemento filho <reason>, regulado para uma razão configurável por operadora; e d) um elemento filho <action> regulado para " emergency - registration", se a requisição incluísse um URN de serviço de emergência no Request-URI. NOTA 1: Roaming é quando o UE está em uma área geográfica que está fora da área geográfica de serviço do subsistema de CN de IM doméstico. NOTA la: "sip: 911@example. com; user=phone " poderia ser um URI de serviço de emergência alternativo. "urn: service: sos. animal-control" poderia ser um tipo não suportado de chamada de emergência. NOTA 2: um URN de serviço de emergência no request-URI indica para a rede que a tentativa de chamada de emergência é reconhecida pelo UE. A modificação alternativa a seguir para a 3GPP TS 24.229 se aplica ao tratamento geral para todos os diálogos e transações independentes, excluindo-se o método REGISTER para um registro não de emergência: Se a P-CSCF receber uma requisição inicial para um diálogo, ou uma transação independente, ou um método desconhecido, para um usuário registrado, a P-CSCF deve inspecionar o URI de requisição independentemente de valores de possíveis entradas nos cabeçalhos Route recebidos para identificadores de serviço de emergência conhecidos, isto é, números de emergência e o URN de serviço de emergência a partir destas listas configuráveis. Se a P-CSCF detectar que o Request-URI da requisição inicial para um diálogo, ou uma transação independente, ou um método desconhecido, combina com um dos identificadores de serviço de emergência em qualquer uma destas listas, a P-CSCF deve: 0) determinar a localização geográfica do UE. Procedimentos específicos de tecnologia de acesso são descritos em cada anexo específico de tecnologia de acesso. Se a P-CSCF não for capaz de lidar com sessões de emergência ou devido a uma política local não lida com sessões de emergência ou apenas lida com um certo tipo de requisição de sessão de emergência ou a IP-CAN â qual o UE é anexado ou o UE está em roaming, ou a P- CSCF está em uma rede diferente da rede de operadora doméstica do UE, então, a P-CSCF: - deve rejeitar a requisição ao retornar uma resposta 380 (Serviço Alternativo) para o UE; - deve assumir que o UE suporta uma versão 1 do esquema de XML para um corpo em XML de subsistema de IM CN, caso um suporte para o corpo em XML de IMS de 3GPP no cabeçalho Accept não seja indicado; e - deve incluir na resposta 380 (Serviço Alternativo): - um campo de cabeçalho Content-Type com o valor regulado para o tipo de MIME associado do corpo em XML de IMS de 3GPP, conforme descrito no subitem 7.6.1. O corpo deve conter: a) um elemento <alternative-service>, regulado para os parâmetros do serviço alternativo; b) um elemento filho <type> com um atributo "alternate" regulado para uma lista de URIs de serviço de emergência alternativo, e - se a requisição inicial para um diálogo, ou transação independente, ou um método desconhecido foi para um tipo suportado de emergência, o elemento filho <type> será regulado para "emergency", para indicar que ele foi uma chamada de emergência suportada, c) um elemento filho <reason>, regulado para uma razão configurável por operadora; e d) um elemento filho <action> regulado para "emergency- registration", se a requisição incluísse um URN de serviço de emergência no Request-URI. NOTA 1: Roaming é quando o UE está em uma área geográfica que está fora da área geográfica de serviço do subsistema de CN de IM doméstico. NOTA 2: um URN de serviço de emergência no request-URI indica para a rede que a tentativa de chamada de emergência é reconhecida pelo UE. A modificação a seguir para a 3GPP TS 24.229 se aplica a casos anormais: Se o subsistema de CN de IM ao qual a P-CSCF pertence não for capaz de lidar com sessões de emergência ou devido a uma política local não lidar com sessões de emergência ou apenas lidar com certo tipo de requisição de sessão de emergência ou não suportar sessões de emergência pela localização geográfica em que o UE está localizado ou a IP- CAN à qual o UE está anexado, a P-CSCF não deve encaminhar a requisição INVITE. A P-CSCF: - deve responder à requisição INVITE com uma resposta 380 (Serviço Alternativo); - deve assumir que o UE suporta uma versão 1 do esquema de XML para um corpo em XML de subsistema de IM CN, caso um suporte para o corpo em XML de IMS de 3GPP no cabeçalho Accept não seja indicado; e - deve incluir na resposta 380 (Serviço Alternativo): - um campo de cabeçalho Content-Type com o valor regulado para o tipo de MIME associado do corpo em XML de IMS de 3GPP, conforme descrito no subitem 7.6.1. O corpo deve conter: a) um elemento alternative-service>, regulado para os parâmetros do serviço alternativo; b) se o cabeçalho Accept indicar um suporte para a versão 2 do esquema de XML para o corpo em XML de subsistema de IM CN - então, um elemento filho <type> com um atributo "alternate" regulado para uma lista de URIs de serviço de emergência alternativo, e - se a requisição inicial para um diálogo, ou transação independente, ou método desconhecido foi para um tipo suportado de emergência, o elemento filho <type> será regulado para "emergency", para indicar que ele foi uma chamada de emergência suportada, - caso contrário, um elemento filho <type>, regulado para "emergency" ; c) um elemento filho <reason>, regulado para uma razão configurável por operadora; e d) um elemento filho <action> regulado para "emergencyregistration" , se a requisição incluísse um URN de serviço de emergência no Request-URI. NOTA 1: um URN de serviço de emergência no request-URI indica para a rede que a tentativa de chamada de emergência é reconhecida pelo UE. NOTA la: "sip: 911@example. com;user=phone" poderia ser um URI de serviço de emergência alternativo, "urn: service: sos. animal-control " poderia ser um tipo não suportado de chamada de emergência. NOTA 2: algumas redes podem permitir requisições de sessão com um Request-URI contendo um URN de serviço de emergência, isto é, um URN de serviço com um tipo de serviço de nível de topo de "sos", conforme especificado em draft-ietf-ecrit-service- urn [69] . A modificação alternativa a seguir na 3GPP TS 24.229 se aplica a casos anormais: Se o subsistema de CN de IM ao qual a P-CSCF pertence não for capaz de lidar com sessões de emergência ou devido a uma política local não lidar com sessões de emergência ou apenas lidar com certo tipo de requisição de sessão de emergência ou não suportar sessões de emergência pela localização geográfica em que o UE está localizado ou a IP- CAN à qual o UE está anexado, a P-CSCF não deve encaminhar a requisição INVITE. A P-CSCF: - deve responder à requisição INVITE com uma resposta 380 (Serviço Alternativo); - deve assumir que o UE suporta uma versão 1 do esquema de XML para um corpo em XML de subsistema de IM CN, caso um suporte para o corpo em XML de IMS de 3GPP no cabeçalho Accept não seja indicado; e - deve incluir na resposta 380 (Serviço Alternativo): - um campo de cabeçalho Content-Type com o valor regulado para o tipo de MIME associado do corpo em XML de IMS de 3GPP, conforme descrito no subitem 7.6.1. O corpo deve conter: a) um elemento alternative-service>, regulado para os parâmetros do serviço alternativo; b) um elemento filho <type> com um atributo "alternate" regulado para uma lista de URIs de serviço de emergência alternativo; - se a requisição inicial para um diálogo, ou transação independente, ou método desconhecido foi para um tipo suportado de emergência, o elemento filho <type> será regulado para "emergency", para indicar que ele foi uma chamada de emergência suportada, c) um elemento filho <reason>, regulado para uma razão configurável por operadora; e d) um elemento filho <action> regulado para "emergency- registration", se a requisição incluísse um URN de serviço de emergência no Request-URI. NOTA 1: um URN de serviço de emergência no request-URI indica para a rede que a tentativa de chamada de emergência é reconhecida pelo UE. NOTA 2: algumas redes podem permitir requisições de sessão com um Request-URI contendo um URN de serviço de emergência, isto é, um URN de serviço com um tipo de serviço de nível de topo de "sos", conforme especificado em draft-ietf-ecrit-service- urn [69]. A modificação a seguir poderia ser feita no Esquema de XML de corpo em XML de subsistema de CN de IM de 3GPP para a implementação de uma ou mais das modalidades mostradas aqui:

0 elemento <action> contém o atributo "alternate" e apenas o valor "emergency-registration" no presente documento. O atributo "alternate" pode ser regulado para uma lista de URIs de serviço de emergência alternativo. As duas adições a seguir à 3GPP TS 24.229 se aplicam a procedimentos genéricos aplicáveis a todos os métodos, excluindo-se o método REGISTER: Mediante a geração de uma requisição inicial para um diálogo, ou uma transação independente, ou um método desconhecido, excluindo ACK e CANCEL, o UE deve incluir o cabeçalho Accept com "application/sdp", o tipo de MIME associado ao corpo em XML de IMS de 3GPP (veja o subitem 7.6.1) e qualquer outro tipo de mime que o UE estiver desejando e for capaz de aceitar. No caso em que o UE recebe uma resposta 380 (Serviço Alternativo) a uma requisição inicial para um diálogo, ou uma transação independente, ou um método desconhecido, a resposta incluindo um corpo em XML de CN de IM, conforme descrito no subitem 7.6, que inclui um elemento <alternative service> com o elemento filho <type> regulado para "emergency", o UE deve tentar uma chamada de emergência, conforme descrito no subitem 5.1.6. Se uma resposta Ixx ou 2xx a uma requisição inicial para um diálogo, ou uma transação independente, ou um método desconhecido, contiver um indicador de sessão de emergência, então, o UE deverá enviar um método de requisição de re-INVITE, de acordo com RFC 3261 [26], e: 1) o UE deve indicar a natureza da sessão par ao usuário; NOTA 17: o UE não muda o cabeçalho From para incluir uma identidade de usuário pública ou o tel URI associado ã identidade de usuário pública, nesta versão da especificação. 2) caso disponível para o UE e caso definido para o tipo de acesso conforme especificado no subitem 7.2A.4, o UE deve incluir um cabeçalho P-Access-Network-Info, e ele deve conter um identificador de localização, tal como o id de célula, o id de linha ou a identidade do nô de acesso de I-WLAN; NOTA 18: A especificação de emergência de IMS em 3GPP TS 23.167 [4B] descreve vários métodos sobre como o UE pode obter sua informação de localização a partir da rede de acesso ou de um servidor. Esses métodos não estão no escopo desta especificação. 3) o UE deve inserir um P-Preferred-Identity que inclui a identidade de usuário pública ou o tel URI associado à identidade de usuário pública, conforme descrito no subitem 4.2; 4) caso o UE tenha sua informação de localização disponível, então, o UE deve incluí-la da forma a seguir: - se o UE estiver ciente do URI que aponta para onde a localização de UE é armazenada, incluir o URI no cabeçalho Geolocation de acordo com draft-ietf-sip- location-conveyance [89] ; ou - se a informação de localização geográfica do UE estiver disponível para o UE, incluir sua informação de localização geográfica como um objeto de localização de PIDF, de acordo com a RFC 4119 [90], e incluir o objeto de localização em um corpo de mensagem com o tipo de conteúdo application/pidf+XML, de acordo com draft-ietf-sip-location- conveyance [89]. O cabeçalho Geolocation ê regulado para um Content ID de acordo com draft-ietf-sip- location-conveyance [89]; e 5) se o UE não tiver uma informação de localização geográfica disponível, o UE não deve incluir qualquer informação de localização geográfica, conforme especificado em draft-ietf-sip-location- conveyance [89]; e 6) se um valor de GRUU público (pub-gruu) tiver sido salvo associado à identidade de usuário pública e o UE não indicar privacidade de P-Asserted-Identity, então, o UE deve inserir o valor de GRUU público (pub-gruu) no cabeçalho Contact, conforme especificado em draft-ietf- sip-gruu [93]; caso contrário, o UE deve incluir a porta de servidor no endereço no cabeçalho Contact. NOTA 19: de acordo com a RFC 3261 [26], uma requisição de re-INVITE não pode ser enviada enquanto uma outra transação INVITE estiver em andamento em qualquer direção. NOTA 20: não é necessário que esta requisição re-INVITE mude os parâmetros de sessão. NOTA 21: é sugerido que os UEs apenas usem a opção de prover um URI quando a parte de domínio pertencer ao provedor atual de P-CSCF ou S-CSCF. Isto é uma questão sobre a qual a operadora de rede precisa prover uma recomendação para o usuário final. Um URI que é resolvível apenas para o UE o qual está fazendo a chamada de emergência não é desejável. NOTA 22: durante o diálogo, os pontos de anexação para a IP-CAN do UE podem mudar (por exemplo, o usuário se conecta a células diferentes) . O UE preencherá o cabeçalho P-Access-Network-Info em qualquer requisição (exceto em requisições de ACK e requisições de CANCEL) ou resposta (exceto respostas de CANCEL) em um diálogo com o ponto atual de anexação â IP-CAN (por exemplo, a informação de célula atual).

A aplicação de privacidade, incluindo a remoção de informação de localização e rede de acesso, se o PSAP estiver no domínio de confiança da rede, pode ser realizada pelos elementos de rede de IMS, tais como E-CSCF, IBCF e outros. Pode ser preferido que a privacidade da "sessão" seja requisitada (isto é, o campo de cabeçalho Privacy regulado para incluir o valor "session", uma vez que o campo de cabeçalho P-Access-Network-Info está presente na maioria das mensagens de SIP). Pode ser preferido que a E- CSCF receba uma localização, de modo que possa determinar o PSAP mais aplicável e usá-lo no roteamento da requisição para o PSAP ou a central de resposta à emergência. As exigências de privacidade de acordo com a RFC 4244 também podem se aplicar, mas, no presente, nenhum procedimento prevê a inclusão de uma informação de histórico em uma requisição de serviços de emergência. As duas adições a seguir à 3GPP TS 24.229 se aplicam aos Procedimentos na E- CSCF:

Quando a E-CSCF recebe uma requisição para um diálogo requisitando privacidade ou uma transação independente requisitando privacidade ou qualquer requisição ou resposta relacionada a um diálogo originado em UE requisitando privacidade ou uma transação independente requisitando privacidade, e se a política de operadora local permitir uma requisição de usuário para supressão de identificadores de usuário públicos e uma informação de localização, a E-CSCF deve: aplicar qualquer privacidade requerida pela RFC 3323 [33] com relação à privacidade e a RFC 3325 [34] ao cabeçalho P-Asserted-Identity; se presente, remover o campo de cabeçalho P-ACCESS- NETWORK-INFO; se presente, remover o objeto de localização do corpo de mensagem e remover o tipo de conteúdo application/pidf+xml do campo de cabeçalho Content- Type; se presente, remover o campo de cabeçalho Geolocation. NOTA: políticas de operadora (por exemplo, exigências para suporte de comunicações de emergência) podem suprimir a requisição de usuário para supressão. 6) selecionar, com base em uma informação de localização e opcionalmente um tipo de serviço de emergência: - um PSAP conectado à rede de subsistema de CN de IM e adicionar o URI de PSAP ao cabeçalho Route mais no topo; ou NOTA 3: se o usuário não requisitou privacidade, a E-CSCF portará o cabeçalho P-Access-Network-Info contendo o identificador de localização, se definido para o tipo de acesso conforme especificado no subitem 7.2A.4, para o PSAP. - um PSAP na PSTN, adicionar URI de BGCF ao cabeçalho Route mais de topo e adicionar um URI de PSAP em formato tel URI ao Request-URI com uma entrada usada no domínio de PSTN/CS para endereçar o PSAP; NOTA 4: Se o usuário não requisitou privacidade, a E-CSCF porta o cabeçalho P-Access-Network-Info contendo o identificador de localização, se definido para o tipo de acesso, conforme o subitem 7.2A.4, para a MGCF. A MGCF pode traduzir a informação de localização, caso incluída em INVITE (isto, a informação de localização geográfica em PIDF-LO e o identificador de localização no cabeçalho P-Access- Network-Info) para uma sinalização de ISUP, veja a 3GPP TS 29.163 [11B] . NOTA 5: A E-CSCF pode requisitar uma informação de localização e uma informação de roteamento a partir da LRF. A E-CSCF pode enviar, por exemplo, o identificador de localização para a LRF e a LRF mapear o identificador de localização na informação de localização geográfica correspondente que a LRF envia para a E-CSCF. A LRF pode invocar uma RDF para converter a informação de localização em um URI apropriado de PSAP/EC. A informação de localização e o URI de PSAP são retornados para a E-CSCF. NOTA 6: A forma pela qual a E-CSCF determina o próximo endereço de salto quando o endereço de PSAP ê um tel URI é dependente de implementação. 7) Se o usuário não requisitou privacidade e se a E-CSCF receber um número de referência a partir da LRF, a E- CSCF deverá incluir o número de referência no cabeçalho P-Asserted-Identity; NOTA 7: o número de referência é usado na comunicação entre o PSAP e a LRF.

A Figura 4 ilustra um sistema de comunicações sem fio que inclui uma modalidade do UE 110. O UE 110 é operável para a implementação de aspectos da exposição, mas a exposição não deve ser limitada a estas implementações. Embora ilustrado como um telefone móvel, o UE 110 pode assumir várias formas, incluindo um aparelho sem fio, um equipamento de radiochamada, um assistente digital pessoal (PDA), um computador portátil, um computador tablet, ou um computador laptop. Muitos dispositivos adequados combinam algumas ou todas estas funções. Em algumas modalidades da exposição, o UE 110 não é um dispositivo de computação de finalidade geral, como um computador portátil, laptop ou tablet, mas, ao invés disso, é um dispositivo de comunicações de finalidade geral, tal como um telefone móvel, um aparelho sem fio, um equipamento de radiochamada, um PDA, ou um dispositivo de telecomunicações instalado em um veículo. Em uma outra modalidade, o UE 110 pode ser um dispositivo de computação portátil, laptop ou outro. O UE 110 pode suportar atividades especializadas, tais como jogos, controle de inventário, controle de serviço, e/ou funções de gerenciamento de tarefa, e assim por diante.

O UE 110 inclui um visor 402. O UE 110 também inclui uma superfície sensível ao toque, um teclado ou outras teclas de entrada geralmente referidas como 404 para entrada por um usuário. O teclado pode ser um teclado alfanumérico completo ou reduzido, tal como QWERTY, Dvorak, AZERTY, e tipos sequenciais, ou um miniteclado numérico tradicional com as letras do alfabeto associadas a um miniteclado de telefone. As teclas de entrada podem incluir um botão circular direcional ("trackwheel"), uma tecla de saída ou escape, um trackball, e outras teclas de navegação ou funcionais, as quais podem ser pressionadas para dentro para a provisão de uma função de entrada adicional. O UE 110 pode apresentar opções para o usuário selecionar, controles para o usuário atuar e/ou cursores ou outros indicadores para o usuário dirigir. O UE 110 ainda pode aceitar uma entrada de dados a partir do usuário, incluindo números a discar ou vários valores de parâmetro para configuração da operação do UE 110. O UE 110 ainda pode executar um ou mais aplicativos de software ou de firmware em resposta a comandos de usuário. Estes aplicativos podem configurar o UE 110 para a realização de várias funções personalizadas em resposta a uma interação de usuário. Adicionalmente, o UE 110 pode ser programado e/ou configurado pelo ar, por exemplo, a partir de uma estação base sem fio, um ponto de acesso sem fio, ou um UE de par 110.

Dentre os vários aplicativos executáveis pelo UE 110 está um navegador da web, o que permite que o visor 402 mostre uma página da web. A página da web pode ser obtida através de comunicações sem fio com um nó de acesso de rede sem fio, uma torre de celular, um UE de par 110, ou qualquer outra rede ou outro sistema de comunicação sem fio 400. A rede 400 é acoplada a uma rede com fio 408, tal como a Internet. Através do enlace sem fio e da rede com fio, o UE 110 tem acesso a uma informação em vários servidores, tal como um servidor 410. O servidor 410 pode prover um conteúdo que pode ser mostrado no visor 402. Alternativamente, o UE 110 pode acessar a rede 400 através de um UE de par 110 atuando como um intermediário, em um tipo de retransmissão ou um tipo de salto de conexão.

A Figura 5 mostra um diagrama de blocos do UE 110. Embora uma variedade de componentes conhecidos de UEs 110 seja descrita, em uma modalidade, um subconjunto dos componentes listados e/ou de componentes adicionais não listados pode ser incluído no UE 110. O UE 110 inclui um processador de sinal digital (DSP) 502, e uma memória 504. Conforme mostrado, o UE 110 ainda pode incluir uma unidade de antena e de front end 506, um transceptor de freqüência de rádio (RF) 508, uma unidade de processamento de banda base analógica 510, um microfone 512, um alto-falante de fone de ouvido 514, uma porta para fone com microfone 516, uma interface de entrada / saída 518, um cartão de memória removível 520, uma porta de barramento serial universal (USB), um subsistema de comunicação sem fio de alcance curto 524, um alerta 526, um teclado 528, um visor de cristal líquido (LCD), o qual pode incluir uma superfície sensível ao toque 520, um controlador de LCD 532, uma câmera de dispositivo de carga acoplada (CCD) 534, um controlador de câmera 536, e um sensor de sistema de posicionamento global (GPS) 538. Em uma modalidade, o UE 110 pode incluir um outro tipo de visor que não provê uma tela sensível ao toque. Em uma modalidade, o DSP 502 pode se comunicar diretamente com a memória 504 sem passar através da interface de entrada / saída 518.

O DSP 502 ou alguma outra forma de controlador ou unidade de processamento central opera para controlar os vários componentes do UE 110 de acordo com um software ou software armazenado na memória 504 ou armazenado em uma memória contida no DSP 502 em si. Além do software ou firmware embutido, o DSP 502 pode executar outros aplicativos armazenados na memória 504, ou tornados disponíveis através de uma mídia portadora de informação, tal como uma mídia de armazenamento de dados portátil, como o cartão de memória removível 520, ou através de comunicações de rede com fio ou sem fio. O software aplicativo pode compreender um conjunto compilado de instruções que podem ser lidas em máquina que configuram o DSP 502 para a provisão da funcionalidade desejada, ou o software aplicativo pode ser com instruções de software de nível alto a serem processadas por um intérprete ou compilador para a configuração de forma indireta do DSP 502.

A unidade de antena e de front end 506 pode ser provida para uma conversão entre sinais sem fio e sinais elétricos, permitindo que o UE 110 envie e receba uma informação a partir de uma rede celular ou outra rede de comunicações sem fio disponível ou a partir de um UE de par 110. Em uma modalidade, a unidade de antena e de front end 506 pode incluir múltiplas antenas para o suporte de uma formação de feixe e/ou operações de entrada múltipla e saída múltipla (MIMO). Conforme é conhecido na técnica, as operações de MIMO podem prover diversidade espacial, o que pode ser usado para se suplantarem condições difíceis de canal e/ou aumentar o ritmo de transferência de canal. A unidade de antena e de front end 506 pode incluir componentes de sintonização de antena e/ou de combinação de impedância, amplificadores de potência de RF e/ou amplificadores de ruído baixo.

O transceptor de RF 508 provê um deslocamento de freqüência, convertendo os sinais de RF recebidos em banda base e convertendo os sinais de transmissão de banda base em RF. Em algumas descrições, um transceptor de rádio ou um transceptor de RF pode ser entendido como incluindo uma outra funcionalidade de processamento de sinal, tal como modulação / demodulação, codificação / decodificação, entrelaçamento, desentrelaçamento, difusão / concentração, transformada de Fourier rápida inversa (IFFT) / transformada de Fourier rápida (FFT), anexação / remoção de prefixo cíclico, e outras funções de processamento de sinal. Para fins de clareza, a descrição aqui separa a descrição deste processamento de sinal do estágio de RF e/ou de rádio e conceitualmente aloca o processamento de sinal para a unidade de processamento de banda base analógica 510 e/ou o DSP 502 ou uma outra unidade de processamento central. Em algumas modalidades, o transceptor de RF 508, porções da antena e front end 506 e a unidade de processamento de banda base analógica 510 podem ser combinadas em uma ou mais unidades de processamento e/ou circuitos integrados específicos de aplicação (ASICs).

A unidade de processamento de banda base analógica 510 pode prover um processamento variado analógico de entradas e saídas, por exemplo, um processamento analógico de exemplo de entradas a partir do microfone 512 e do fone com microfone 516 e saídas para o fone de ouvido 514 e o fone com microfone 516. Para essa finalidade, a unidade de processamento de banda base analógica 510 pode ter portas para conexão ao microfone embutido 512 e ao alto-falante de fone de ouvido 514 que permitem que o UE 110 seja usado como um telefone celular. A unidade de processamento de banda base analógica 510 ainda pode incluir uma porta para conexão a um fone com microfone ou outra configuração de microfone sem as mãos e alto-falante. A unidade de processamento de banda base analógica 510 pode prover uma conversão de digital para analógico em uma direção de sinal e uma conversão de analógico para digital na direção oposta de sinal. Em algumas modalidades, pelo menos parte da funcionalidade da unidade de processamento de banda base analógica 510 pode ser provida por componentes de processamento digital, por exemplo, pelo DSP 502 ou por outras unidades de processamento central.

O DSP 502 pode realizar modulação / demodulação, codificação / decodificação, entrelaçamento, desentrelaçamento, difusão / concentração, transformada de Fourier rápida inversa (IFFT) / transformada de Fourier rápida (FFT), anexação / remoção de prefixo cíclico, e outras funções de processamento de sinal associadas a comunicações sem fio. Em uma modalidade, por exemplo, em uma aplicação de tecnologia de acesso múltiplo com divisão de código (CDMA) para uma função de transmissor, o DSP 502 pode realizar uma modulação, uma codificação, um entrelaçamento e uma difusão, e, para uma função de receptor, o DSP 502 pode realizar uma concentração, um desentrelaçamento, uma decodificação e uma demodulação. Em uma outra modalidade, por exemplo, em uma aplicação de tecnologia de acesso múltiplo de divisão de freqüência ortogonal (OFDMA) , para a função de transmissor, o DSP 502 pode realizar uma modulação, uma codificação, um entrelaçamento, uma transformada de Fourier rápida inversa e uma anexação de prefixo cíclico, e para uma função de receptor, o DSP 502 pode realizar uma remoção de prefixo cíclico, uma transformada de Fourier rápida, um desentrelaçamento, uma decodificação e uma demodulação. Em outras aplicações de tecnologia, adicionalmente outras funções de processamento de sinal e combinações de funções de processamento de sinal podem ser realizadas pelo DSP 502.

O DSP 502 pode se comunicar com uma rede sem fio através da unidade de processamento de banda base analógica 510. Em algumas modalidades, a comunicação pode prover uma conectividade de Internet, permitindo que o usuário ganhe acesso ao conteúdo na Internet e envie e receba mensagens de e-mail ou de texto. A interface de entrada / saída 518 interconecta o DSP 502 e várias memórias e interfaces. A memória 504 e o cartão de memória removível 520 podem prover software e dados para configuração da operação do DSP 502. Dentre as interfaces, pode haver a interface USB 522 e o subsistema de comunicação sem fio de alcance curto 524. A interface USB 522 pode ser usada para carregamento do UE 110 e também pode permitir que o UE 110 funcione como um dispositivo periférico para troca de informação com um computador pessoal ou outro sistema de computador. O subsistema de comunicação sem fio de alcance curto 524 pode incluir uma porta de infravermelho, uma interface Bluetooth, uma interface sem fio em conformidade com IEEE 802.11, ou qualquer outro subsistema de comunicação sem fio de alcance curto, o qual pode permitir que o UE 110 se comunique de forma sem fio com outros dispositivos móveis e/ou estações bases sem fio.

A interface de entrada / saída 518 ainda pode conectar o DSP 502 ao alerta 526 que, quando disparado, faz com que o UE 110 proveja uma notificação para o usuário, por exemplo, ao tocar um som, executar uma melodia ou vibrar. O alerta 526 pode servir como um mecanismo para alertar o usuário para qualquer um de vários eventos, tais como uma chamada entrando, uma nova mensagem de texto, e um lembrete de compromisso ao vibrar silenciosamente ou ao tocar uma melodia pré-atribuída específica para uma parte chamando em particular.

O teclado 528 se acopla ao DSP 502 através da interface 518 para a provisão de um mecanismo para o usuário fazer seleções, introduzir uma informação e prover de outra forma uma entrada para o UE 110. O teclado 528 pode ser um teclado alfanumérico completo ou reduzido, tal como QWERTY, Dvorak, AZERTY, e tipos sequenciais, ou um miniteclado numérico tradicional com as letras do alfabeto associadas a um miniteclado de telefone. As teclas de entrada podem incluir um botão circular direcional ("trackwheel"), uma tecla de saída ou escape, um trackball, e outras teclas de navegação ou funcionais, as quais podem ser pressionadas para dentro para a provisão de uma função de entrada adicional. Um outro mecanismo de entrada pode ser o LCD 530, o qual pode incluir uma capacidade de tela de toque e também exibir textos e/ou itens gráficos para o usuário. 0 controlador de LCD 532 acopla o DSP 502 ao LCD 530.

A câmera de CCD 534, caso equipada, permite que o UE 110 faça fotos digitais. O DSP 502 se comunica com a câmera de CCD 534 através do controlador de câmera 536. Em uma outra modalidade, uma câmera operando de acordo com uma outra tecnologia além de câmeras de dispositivo de carga acoplada pode ser empregada. 0 sensor de GPS 538 é acoplado ao DSP 502 para a decodificação de sinais de sistema de posicionamento global, desse modo se permitindo que o UE 110 determine sua posição. Vários outros periféricos também podem ser incluídos para a provisão de funções adicionais, por exemplo, recepção de rádio e televisão.

A Figura 6 ilustra um ambiente de software 602 que pode ser implementado pelo DSP 502. O DSP 502 executa drivers de sistema operacional 604 que provêem uma plataforma a partir da qual o restante do software opera. Os drivers de sistema operacional 604 provêem drivers para o hardware de dispositivo sem fio com interfaces padronizadas que são acessíveis para o software aplicativo. Os drivers de sistema operacional 604 incluem serviços de gerenciamento de aplicativo ("AMS") 606, que transferem o controle entre os aplicativos rodando no UE 110. Também são mostrados na Figura 12 um aplicativo de navegador da web 608, um aplicativo de tocador de mídia 610 e miniaplicativos Java 612. O aplicativo de navegador da web 608 configura o UE 110 para operar como um navegador da web, permitindo que o usuário introduza uma informação em formulários e selecione enlaces para a recuperação e a visualização de páginas da web. O aplicativo de tocador de mídia 610 configura o UE 110 para recuperar e tocar áudio ou mídia audiovisual. Os miniaplicativos Java 612 configuram o UE 110 para a provisão de jogos, utilitários e outra funcionalidade. Um componente 614 poderia prover uma funcionalidade relacionada ao gerenciamento de sinal de controle.

O sistema descrito acima pode ser implementado em qualquer computador de finalidade geral com potência de processamento suficiente, recursos de memória e capacidade de transferência de rede para lidar com a carga útil necessária imposta a ele. A Figura 7 ilustra um sistema 1300 que inclui um componente de processamento 1310 adequado para a implementação de uma ou mais modalidades mostradas aqui. Além do processador 1310 (o qual pode ser referido como uma unidade de processamento central ou CPU) , o sistema 1300 poderia incluir uma memória de acesso randômico (RAM) 1330, uma memória apenas de leitura (ROM) 1340, um armazenamento secundário 1350, e dispositivos de entrada / saída (I/O) 1360. Em alguns casos, alguns destes componentes podem estar presentes ou podem ser combinados em várias combinações uns com os outros ou com outros componentes não mostrados. Estes componentes poderiam estar localizados em uma entidade física única ou em mais de uma entidade física. Quaisquer ações descritas aqui como sendo feitas pelo processador 1310 poderiam ser executadas pelo processador 1310 sozinho ou pelo processador 1310 em conjunto com um ou mais componentes mostrados ou não mostrados nos desenhos.

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

Os dispositivos de conectividade de rede 1320 podem assumir a forma de modems, bancos de modem, placas de Ethernet, placas de interface de barramento serial universal (USB), interfaces seriais, cartões de token ring (redes em anel), placas de interface de dados distribuídos de fibra (FDDI) , placas de rede de área local sem fio (WLAN), placas de transceptor de rádio, tais como placas de transceptor de rádio de acesso múltiplo com divisão de código (CDMA) e/ou sistema global para comunicações móveis (GSM), e outros dispositivos de rede bem conhecidos. Estes dispositivos de conectividade de rede 1320 podem permitir que o processador 1310 se comunique com a Internet ou uma ou mais redes de telecomunicações ou outras redes a partir das quais o processador 1310 poderia receber uma informação ou para a qual o processador 1310 poderia extrair uma informação.

Os dispositivos de conectividade de rede 1320 também poderiam incluir um ou mais componentes de transceptor 1325 capazes de transmitirem e/ou receberem dados de forma sem fio na forma de ondas eletromagnéticas, tais como sinais de freqüência de rádio ou sinais de freqüência de microondas. Alternativamente, os dados podem se propagar em ou na superfície de condutores elétricos, em cabos coaxiais, em guias de onda, em meios óticos, tal como fibra ótica, ou em outros meios. O componente de transceptor 1325 poderia incluir unidades separadas de recepção e transmissão ou um transceptor único. Uma informação transmitida ou recebida pelo transceptor 1325 pode incluir dados que foram processados pelo processador 1310 ou instruções que devem ser executadas pelo processador 1310. Uma informação como essa pode ser recebida a partir de e introduzida na rede na forma, por exemplo, de um sinal de banda base de dados de computador ou um sinal concretizado em uma onda portadora. Os dados podem ser ordenados de acordo com diferentes seqüências, conforme puder ser desejável para o processamento ou a geração dos dados ou a transmissão ou a recepção dos dados. 0 sinal de banda base, o sinal concretizado na onda portadora, ou outros tipos de sinais atualmente usados ou desenvolvidos mais tarde podem ser referidos como o meio de transmissão e podem ser gerados de acordo com vários métodos bem conhecidos por alguém versado na técnica. gerado pelos dispositivos de conectividade de rede 592 pode se propagar em ou sobre a superfície de condutores elétricos, em cabos coaxiais, em guias de onda, em mídia ótica, por exemplo, fibra ótica, ou no ar ou espaço livre. A informação contida no sinal de banda base ou no sinal embutido na onda portadora pode ser ordenada de acordo com diferentes seqüências, conforme puder ser desejável para processamento ou geração da informação ou transmissão ou recepção da informação. O sinal de banda base ou sinal embutido na onda portadora, ou outros tipos de sinal atualmente usados ou desenvolvidos mais tarde referidos aqui como meio de transmissão podem ser gerados de acordo com vários métodos bem conhecidos por alguém versado na técnica.

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

Os dispositivos de I/O 1360 podem incluir impressoras, monitores de vídeo, visores de cristal líquido (LCDs), visores de tela de toque, teclados, miniteclados, comutadores, discos, mouses, trackballs, reconhecedores de voz, leitoras de cartão, leitoras de tira de papel, e outros dispositivos de entrada bem conhecidos. Também, o transceptor 1325 poderia ser considerado como sendo um componente dos dispositivos de I/O 1360, ao invés de ou além de ser um componente dos dispositivos de conectividade de rede 1320. Alguns ou todos os dispositivos de I/O 1360 podem ser similares substancialmente a vários componentes descritos no desenho descrito previamente do UE 110, tal como o visor 402 e a entrada 404.

A Especificação Técnica (TS) do Projeto de Parceria de Terceira Geração (3GPP) é incorporada aqui como referência: TS 24.229 V7.8.0 (2007-12).

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

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

Claims

1. Método para um equipamento de usuário (UE) (110) responder a uma mensagem (150) relacionada à emergência, caracterizado pelo fato de compreender: o recebimento de uma mensagem de resposta (150) de protocolo de iniciação de sessão (SIP) contendo um indicador (160) que indica que uma mensagem de requisição de SIP para um diálogo (140), enviada pelo UE (110) , é uma requisição relacionada à emergência; e o envio de uma mensagem de requisição de SIP dentro do diálogo (170), a mensagem de requisição de SIP dentro do diálogo (170) contendo uma informação relacionada à emergência (180) associada ao UE (110) , onde, antes de receber a mensagem de resposta (150) SIP, o UE (110) não está ciente que a mensagem de requisição de SIP para um diálogo (140) é uma requisição relacionada à emergência.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de, mediante o recebimento da mensagem de resposta (150) SIP, o método ainda compreender: a provisão de uma indicação de usuário que a mensagem de requisição de SIP para um diálogo (140) está em uma requisição relacionada à emergência.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de a informação relacionada à emergência (180) associada ao UE (110) contida na mensagem de requisição de SIP dentro do diálogo (170) compreender pelo menos uma de: identidade de UE; uma localização de UE; ou uma informação de rede de acesso UE.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de a mensagem de resposta SIP (150) ser uma de uma resposta SIP lxx ou 200 (OK).

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de a mensagem de requisição de SIP dentro do diálogo (170) ser uma dentre: uma SIP ACK; uma SIP PRACK; uma atualização de alvo de SIP; uma SIP UPDATE; e uma requisição de SIP RE-INVITE.

6. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que, quando a informação relacionada à emergência (180) compreende uma identidade UE, em que a identidade de UE ser um identificador de recurso uniforme de agente de usuário roteável globalmente ("GRUU").

7. Método, de acordo com a reivindicação 3, caracterizado pelo fato de ainda compreender a inclusão em um campo de cabeçalho de geolocalização da mensagem de requisição de SIP no diálogo (170) um identificador de recurso uniforme ("URI") que aponta para a localização do UE.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de ainda compreender, se a informação de localização geográfica do UE (110) estiver disponível para o UE (110) , a inclusão da informação de localização geográfica como um objeto de localização PIDF em um corpo de mensagem da mensagem de requisição de SIP no diálogo (170).

9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de ainda incluir em um campo de cabeçalho de contato da mensagem de requisição de SIP no diálogo (170), se um valor de GRUU público associado a uma identidade de usuário pública.

10. Método, de acordo com a reivindicação 3, caracterizado pelo fato de a informação de rede de acesso de UE ser incluída em um campo de cabeçalho P-Access- Network-Info na mensagem de requisição de SIP no diálogo (170) e compreender um dentre um identificador de localização, um identificador de célula ou uma identidade de um nó de acesso de I-WLAN.

11. Equipamento de usuário (UE) (110), caracterizado pelo fato de compreender: um componente configurado de modo que o UE (110) receba uma mensagem de resposta SIP (150) contendo um indicador (160) que indica que uma mensagem de requisição de SIP para um diálogo (140), enviada pelo UE (110), é uma requisição relacionada à emergência, e de modo que o UE (110) envie, em resposta à mensagem de resposta SIP (150) , uma requisição de SIP no diálogo (170) , a mensagem de requisição de SIP no diálogo (170) contendo uma informação relacionada à emergência (180) associada ao UE (110), onde o UE(110), antes de receber a mensagem de resposta SIP (150), não está ciente que a mensagem de requisição de SIP para um diálogo (140) é uma requisição relacionada à emergência.

12. UE (110), de acordo com a reivindicação 11, caracterizado pelo fato de que o UE (110) é configurado para, mediante o recebimento da mensagem de resposta SIP (150), prover uma indicação de usuário que a mensagem de requisição de SIP para um diálogo (140) é uma requisição relacionada à emergência.

13. UE (110), de acordo com a reivindicação 11, caracterizado pelo fato de a informação relacionada à emergência (180) associada ao UE (110) contida na mensagem de requisição de SIP no diálogo (170) compreender pelo menos um de: uma identidade de UE; uma localização de UE; ou uma informação de rede de acesso UE.

14. UE (100), de acordo com a reivindicação 11, caracterizado pelo fato de a mensagem de resposta SIP (150) ser uma dentre uma resposta de SIP lxx ou 200 (OK).

15. UE (100), de acordo com a reivindicação 11, caracterizado pelo fato de que a mensagem de requisição de SIP no diálogo (170) ser uma dentre: uma SIP ACK; uma SIP PRACK; uma atualização de alvo de SIP; uma SIP UPDATE; e uma requisição de SIP RE-INVITE.

16. UE (110), de acordo com a reivindicação 13, caracterizado pelo fato de que quando a informação relacionada à emergência (180) compreende uma identidade de UE, em que a identidade de UE é um identificador de recurso uniforme de agente de usuário roteável globalmente ("GRUU").

17. UE (110), de acordo com a reivindicação 13, caracterizado pelo fato de compreender ainda em um campo de cabeçalho de geolocalização da mensagem de requisição de SIP no diálogo (170) um identificador de recurso uniforme ("URI") que aponta para a localização do UE.

18. UE (110), de acordo com a reivindicação 11, caracterizado pelo fato de ainda compreender, se a informação de localização geográfica do UE (110), estiver disponível para o UE (110), o UE inclui a informação de localização geográfica como um objeto de localização PIDF em um corpo de mensagem da mensagem de requisição de SIP no diálogo (170).

19. UE (110), de acordo com a reivindicação 11, caracterizado pelo fato de ainda incluir em um campo de cabeçalho de contato da mensagem de requisição de SIP no diálogo (170), um valor de GRUU público associado com uma identidade de usuário pública.

20. UE (110), de acordo com a reivindicação 13, caracterizado pelo fato de a informação de rede de acesso de UE ser incluída em um campo de cabeçalho P-Access- Network-Info na mensagem de requisição de SIP no diálogo (170) e compreender um dentre um identificador de localização, um identificador de célula ou uma identidade de um nó de acesso de I-WLAN.