BRPI0924885B1

BRPI0924885B1 - Método para modificar alocação de funções de controle de sessão de chamada de serviço a um usuário de uma rede de subsistema de multimídia de ip, e, função de controle de sessão de chamada de serviço

Info

Publication number: BRPI0924885B1
Application number: BRPI0924885-4A
Authority: BR
Inventors: Fredrik Lindholm; Hubert Przybysz
Original assignee: Telefonaktiebolaget Lm Ericsson(Publ)
Priority date: 2009-03-19
Filing date: 2009-03-19
Publication date: 2020-09-24
Also published as: CN102356617A; WO2010105643A1; JP5363643B2; JP2012521115A; BRPI0924885A2; US20110320581A1; CN102356617B; US9560084B2; EP2409469A1; EP2409469B1

Abstract

método para modificar alocação de funções de controle de sessão de chamada de serviço a um usuário de uma rede de subsistema de multimídia de ip, e, função de controle de sessão de chamada de serviço a invenção relaciona-se a um método para modificar a alocação de funções de controle de sessão de chamada de serviço (scscfs) a um usuário de uma rede de ims. o usuário está sendo provido de serviços através de uma primeira s-cscf alocado ao usuário. o método inclui implementar uma instrução de realocação na primeira s-cscf. a instrução de realocação inclui critérios para desalocação do usuário da primeira s-cscf. a s-cscf determina se os critérios são satisfeitos; e se os critérios são satisfeitos, desaloca o usuário.

Description

MÉTODO PARA MODIFICAR ALOCAÇÃO DE FUNÇÕES DE CONTROLE DE SESSÃO DE CHAMADA DE SERVIÇO A UM USUÁRIO DE UMA REDE DE SUBSISTEMA DE MULTIMÍDIA DE IP, E, FUNÇÃO DE CONTROLE DE SESSÃO DE CHAMADA DE SERVIÇO

Campo Técnico

A presente invenção relaciona-se a realocação de função proxy de serviço ou Função de Controle de Sessão de Chamada de Serviço (S-CSCF) em um Subsistema de Multimídia de IP (IMS).

Fundamentos

Subsistema de Multimídia de IP (IMS) é a tecnologia definida no Projeto de Parceria de Terceira Geração (3GPP) e grupo ETSI TISPAN para prover serviços Multimídia IP através de redes de comunicação móvel. (Esta tecnologia é descrita em vários documentos técnicos, alguns dos quais são referenciados na descrição a seguir e incluem 3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 e TS 29.329, Emissões 5 a 7 e TS 24.173 Emissão 7). IMS provê características chave para enriquecer a experiência de comunicação pessoa a pessoa do assinante final, através do uso de Habilitadores de Serviço IMS padronizados, o que facilita novos serviços ricos de comunicação pessoa a pessoa (cliente a cliente), bem como serviços de pessoa a conteúdo (cliente a servidor) de redes com base em IP.

IMS faz uso do Protocolo de Iniciação de Sessão (SIP) para estabelecer e controlar chamadas ou sessões entre terminais de assinante (ou terminais de assinante e servidores de aplicativo). Enquanto SIP foi criado como um protocolo de assinante a assinante, IMS permite que operadores e provedores de serviço controlem o acesso de assinante a serviços e cobrem dos assinantes de acordo.

A título de exemplo, Figura 1 ilustra esquematicamente como o IMS se ajusta na arquitetura de rede móvel no caso de uma rede de acesso GPRS/PS (IMS pode naturalmente operar através de outras redes de acesso). Funções de Controle de Chamada/Sessão (CSCFs) operam como proxies SIP dentro do IMS. A arquitetura 3GPP define três tipos de CSCFs; o Proxy CSCF (P-CSCF) que é o primeiro ponto de contato dentro do IMS para um terminal SIP; o CSCF de Serviço (S-CSCF) que provê serviços ao assinante e o CSCF Interrogativo (I-CSCF) cujo papel é identificar a S-CSCF correto e enviar a esta S-CSCF uma requisição recebida de um terminal SIP, via um P- CSCF.

Dentro da rede de serviço de IMS, Servidores de aplicativo (ASs) são providos para implementar funcionalidade de serviço de IMS. Servidores de aplicativo provêem serviços a usuários finais em um sistema IMS, e podem ser conectados a pontos de extremidade através de interface Mr definida por 3GPP ou “conectados” por uma S-CSCF através da interface ISC definida por 3GPP.

A S-CSCF é o nó central do plano de sinalização. É um servidor SIP, porém executa igualmente controle de sessão. Este usa Diâmteros de interfaces Cx e Dx para transferir e carregar perfis de usuário para/a partir de Servidor de Assinante Doméstico (HSS) do usuário. S-CSCF processa registros SIP e é o caminho de todas as mensagens de sinalização, de tal modo que pode inspecionar cada mensagem em uma sessão. Decide a qual(is) servidor(es) de aplicativo a mensagem SIP será enviada para a provisão de serviços, e provê serviços de roteamento. A maioria das redes de IMS incluirá S-CSCFs múltiplos para assegurar a disponibilidade de serviços a usuário e distribuir a carga de sinalização. Estas S-CSCFs podem ser localizados ao longo de uma área geográfica extensa.

De acordo com os padrões atuais (ver 3GPP TS 23.380) se uma S-CSCF falha, o estado de registro da S-CSCF com falha pode ser restaurado em uma outra S-CSCF, de tal modo que as operações podem continuar. Entretanto, quando o equipamento de usuário (UE) que foi alocado à S-CSCF com falha foi realocado à nova S-CSCF, esta nova S-CSCF pode ser localizada em uma região diferente do país que o UE. Por exemplo, o UE e a S-CSCF originalmente alocado a ele podem estar na região da Costa Oeste dos USA, ao passo que a nova S-CSCF está na região da Costa Leste. É claramente menos eficiente direcionar sinais através de grandes distâncias, porém enquanto a S-CSCF original estiver fora de ação, isto pode ser aceitável. É preferível comutar o usuário de volta para sua S-CSCF original (que pode estar geograficamente próximo) quando a S-CSCF originalmente alocado ao usuário estiver novamente disponível.

Várias propostas têm sido feitas para comutar um usuário para a S-CSCF “ótima”. Uma proposta é usar procedimentos de Desregistro Administrativo de acordo com 3GPP TS 29.228. Entretanto, isto sempre terminará quaisquer sessões e diálogos existentes que existam na S-CSCF. Isto significa que, se o usuário estiver em uma chamada, a chamada será finalizada.

Uma outra proposta é usar procedimentos de nova seleção iniciados pelo I-CSCF. Neste caso, o I-CSCF detecta primeiramente que a S-CSCF atual não é ótimo e necessita ser novamente selecionado, e em segundo lugar testa a S-CSCF atual para verificar se há sessões ativas na S-CSCF atual, e caso negativo seleciona uma nova S-CSCF “mais ótima”. (Ver 3GPP TR 23.812 e até que a última versão deste relatório técnico esteja disponível, ver SA2 contribuição S2-091406). Uma deficiência com esta proposta é que a realocação pode apenas ser feita durante um procedimento de registro. Em adição, nova funcionalidade necessita ser introduzida para detectar que a S-CSCF necessita ser trocada e efetuar nova seleção. Adicionalmente, a solução proposta introduzirá um novo comportamento de ramificação no I-CSCF (isto é, tentar primeiramente a S-CSCF atual e então tentar a nova S-CSCF). Isto toma o I-CSCF monitorador e modifica o princípio fundamental da funcionalidade I-CSCF. Estas mudanças no I-CSCF seriam bastante dispendiosas para implementar. Finalmente, condições de disputa podem surgir se dois UEs tentarem se registrar ao mesmo tempo.

Em adição, nenhuma das soluções propostas descritas acima leva em consideração que, mesmo quando um UE não está registrado no IMS, uma S-CSCF pode ainda estar alocado a um usuário para serviços não registrados.

Sumário

De acordo com um primeiro aspecto da invenção, é provido um método para variar a alocação de S-CSCFs a um usuário de uma rede de IMS. O usuário está sendo provido de serviços via uma primeira S-CSCF alocado ao usuário. O método compreende: implementar um procedimento de realocação na primeira S-CSCF, com base em uma instrução de realocação e incluindo critérios para desalocação do usuário da primeira S-CSCF; determinar se os critérios são satisfeitos; e, se os critérios são satisfeitos, desalocar o usuário da primeira S-CSCF.

A alocação de uma S-CSCF a um usuário pode compreender registro do usuário na S-CSCF ou designação da S-CSCF ao usuário para provisão de serviços não registrados. A desalocação pode compreender desregistro do usuário ou retirada da designação da S-CSCF do usuário. Os critérios para desalocação podem compreender critérios de desalocação em que um usuário registrado deve ser desregistrado, ou a S-CSCF designada ao usuário deve ter sua designação retirada, se os critérios forem satisfeitos. Os critérios podem incluir critérios de desregistro ou retirada de designação de uma sessão não ativa, onde o usuário deve ser desregistrado ou retirada a designação de sua S-CSCF se o usuário não estiver engajado em uma sessão de IMS ativa. Alternativamente, os critérios podem incluir critérios de desregistro ou retirada de designação específicos da sessão, onde o usuário não deve ser desregistrado ou retirada a designação da S-CSCF, se o usuário estiver engajado em um ou mais de certos tipos de sessão e/ou diálogo.

O método pode compreender adicionalmente enviar a instrução de realocação juntamente com critérios associados a partir do HSS do usuário para a primeira S-CSCF, via interface Cx.

Alternativamente, a instrução de realocação e critérios associados podem ser recebidos de uma entidade de sistema de rede diferente do HSS do usuário ou da primeira S-CSCF. Por exemplo, a entidade de sistema de rede pode compreender uma função de balanceamento de carga. Alternativamente, a instrução de realocação pode ser gerada por lógica local dentro da primeira S-CSCF.

O método pode compreender adicionalmente enviar uma resposta ao HSS do usuário para confirmar que a desalocação da primeira S-CSCF foi completada.

O método pode adicionalmente compreender alocação de uma segunda S-CSCF ao usuário, para provisão dos serviços.

O método pode compreender adicionalmente enviar uma mensagem de erro ao HSS do usuário para indicar que os critérios de desalocação não foram satisfeitos.

A instrução de alocação e os critérios de desalocação podem ser providos à primeira S-CSCF em diferentes instantes.

É uma vantagem que a realocação das S-CSCFs não envolve fazer quaisquer modificações na funcionalidade do I-CSCF, ou outras entidades de rede. O impacto das modificações requeridas é pequeno, limitado apenas à interface Cx e alguma funcionalidade dentro da S-CSCF. Esta é uma opção pouco dispendiosa e simples, comparada com outras soluções propostas, e evita adicionar grande complexidade a redes de IMS. Em adição, o controle da realocação e as decisões sobre quando e qual S-CSCF realocar pode ser todo feito pelo sistema de gerenciamento de rede através do HSS do usuário. E uma vantagem adicional que os procedimentos habilitam realocação onde um usuário estiver registrado no IMS e onde a S-CSCF estiver somente designado a um usuário para provisão de serviços não registrados.

De acordo com um segundo aspecto, a invenção provê uma S-CSCF para uma rede de IMS. A S-CSCF é configurada para implementar um procedimento de realocação com base em uma instrução de realocação e critérios de desalocação em relação a um usuário sendo provido de serviços via S-CSCF. Se os critérios são satisfeitos, a S-CSCF desaloca a si próprio como um provedor de serviço para o usuário.

A instrução de realocação e critérios associados pode ser incluída em uma ou mais mensagens recebidas via uma interface Cx da S-CSCF. Alternativamente, a S-CSCF pode ser adicionalmente configurado para gerar a instrução de realocação dentro de lógica local na S-CSCF.

Breve Descrição dos Desenhos

Figura 1 ilustra esquematicamente a integração de um subsistema de Multimídia de IP em um sistema de comunicações móveis 3G;
Figura 2 é uma ilustração esquemática mostrando uma S-CSCF e certas interfaces associadas a outras entidades;
Figura 3 é um diagrama de fluxo de sinal mostrando os sinais básicos para implementar uma realocação das S-CSCFs;
Figura 4 é um diagrama de fluxo de sinal ilustrando os sinais básicos quando a realocação conforme mostrado na Figura 3 não pode ser executada; e
Figura 5 é um diagrama de fluxo ilustrando a funcionalidade requerida para implementação da realocação das S-CSCFs.

Descrição Detalhada

Na discussão abaixo, o termo “alocação” de uma S-CSCF é usado para se referir à situação em que um UE está registrado com uma S-CSCF e onde o usuário não está registrado no IMS, mas ainda possui uma S-CSCF designado para provisão de serviços não registrados. Então, a solução descrita habilita a realocação de uma S-CSCF quando o usuário é registrado e onde um usuário não registrado possui uma S-CSCF designada, e necessita ser mudado para uma outra S-CSCF.

Consequentemente, onde a realocação envolve desalocar uma S-CSCF, então isto pode envolver desregistro, que é o procedimento de desregistrar ativamente o usuário (com todas suas identidades) da S-CSCF. Isto envolve os procedimentos para notificar os UEs e ASs de que podem estar subscritos para notificação do estado de registro, de que o usuário está sendo desregistrado. Como resultado do desregistro, um UE pode decidir iniciar um novo registro de acordo com procedimentos padrão.

A desalocação pode, de outro modo, envolver retirar a designação de uma S-CSCF, o que é um procedimento de interromper o estado na S-CSCF ativo mantendo o usuário, sem efetuar qualquer notificação ao usuário. Este procedimento seria equivalente a falha da S-CSCF e automaticamente solicitaria procedimentos de restauração que restaurariam o estado em uma nova S-CSCF.

Referindo-se à Figura 2, é mostrada uma representação esquemática de uma S-CSCF 20, que é conectado a outras entidades da rede de IMS via várias interfaces. Estas incluem a interface Cx 201 e a interface Dx 202, através de cujos sinais comunicam entre a S-CSCF 20 e um HSS 24. A S-CSCF 20 usa o protocolo Diameter para estes sinais, para transferência e carregamento de perfis de usuário.

A S-CSCF 20 também determina a qual(is) AS(s) a mensagem SIP será enviada, no sentido de prover seus serviços. A interface ISC 203 é usada para trocar mensagens entre a S-CSCF 20 e um AS.

Sinais entre os CSCFs são trocados através da interface Mw 204. Estes incluem sinais para e a partir de um UE de usuário 22, que acessa o IMS através de um P-CSCF 28, via interface Gm 205.

Figura 3 ilustra o fluxo de sinalização básico para o procedimento de realocação de uma S-CSCF. As entidades de rede e UE 22 levam os mesmos numerais de referência conforme mostrado na Figura 2. Conforme mostrado no início (etapa 301), uma primeira S-CSCF 20, S-CSCF1, é alocada a um usuário 22, que não é ótimo (por exemplo, conforme descrito acima, o usuário 22 pode ter sido movido para S-CSCF 1 20 como resultado de uma S-CSCF alocado originalmente “cair”). Ao invés disso, a S-CSCF2 24 seria o proxy preferido para uso (por exemplo, devido a sua localização geográfica/proximidade do usuário 22). Conforme explicado acima, a alocação da S-CSCF 1 20 ao usuário 22 pode ser devido ao usuário 22 estar registrado com a S-CSCF 1 20 ou porque a S-CSCF 1 20 foi designada ao usuário para provisão de serviços não registrados.

Em algum ponto no tempo, é decidido modificar a alocação, de tal modo que a S-CSCF2 24, que é visto como a S-CSCF ótima, é alocada ao usuário 22. No exemplo ilustrado na Figura 13, na etapa 302, o HSS 26 do usuário emite uma instrução para realocação, que é enviada à S-CSCF 1 20 através da interface Cx. Notar que a decisão de modificar, precisa não ter sido feita pelo próprio HSS 26, mas pode ser originada em algum lugar diferente na rede de IMS. Por exemplo, uma função de balanceamento de carga pode ser empregada, a qual monitoraria a carga em cada S-CSCF e seria programada para redistribuir a carga no caso de um desequilíbrio detectado. Um exemplo deste tipo de função é descrito em 3GPP TR 23.812. Uma outra possibilidade é que a lógica local possa ser empregada na S-CSCF, a qual habilita-o a determinar que um usuário alocado a ele deveria ser movido para uma outra S-CSCF.

A instrução de realocação na etapa 302 disparará a desalocação (isto é, o desregistro do usuário 22 da S-CSCF 1 20, ou a retirada da designação da S-CSCF 1 20 do usuário 22). Entretanto, a instrução inclui critérios que precisam ser satisfeitos antes da desalocação ser implementada. De uma forma simples, a instrução e critérios poderiam consistir de uma requisição de Desregistro Administrativo com um novo valor declarando DE-REGISTER-IF-NO-ACTIVE-SESSIONS. Critérios mais avançados poderiam incluir levar em conta diferentes tipos de sessão e/ou diálogos que possam existir. Por exemplo, os critérios poderiam indicar que a S-CSCF deveria apenas desregistrar o usuário se não existissem sessões SIP INVITE, ou se não existem sessões de serviço MMTEL SIP INVITE.

Na realização mostrada na Figura 3, a instrução e os critérios de desalocação são enviados conjuntamente à S-CSCF 1 20 na etapa 302. Entretanto, é possível que, por exemplo, uma determinação deva ser feita em um estágio anterior em que a S-CSCF 1 20 não é ótima, porém os critérios para desalocar a S-CSCF 1 20 do usuário poderiam depender de outros fatores (tal como a quantidade de tráfego de sinal, ou a disponibilidade de outras S-CSCFs, etc.). Nesse caso, o HSS 26 poderia aguardar um instante mais tarde, antes de enviar os critérios de desalocação à S-CSCF 1 20. Uma outra possibilidade é que o HSS 26 poderia aguardar até que surgisse um novo evento que o fizesse enviar um sinal à S-CSCF 1 20 (tal como desregistro ou término de uma sessão pelo usuário) e o HSS 26 enviar os critérios à S-CSCF1 20 naquele estágio. Alternativamente, a ordem poderia ser reversa de tal modo que os critérios de desalocação fossem enviados primeiro à S-CSCF1 20, e a instrução de desalocação real fosse enviada mais tarde, por exemplo, quando surgisse um novo evento.

Disparado pela instrução de realocação, na etapa 303, a S-CSCF1 20 avalia se os critérios de desalocação são ou não satisfeitos. No cenário ilustrado na Figura 3, é suposto que os critérios são satisfeitos, porém referir-se à discussão das Figuras 4 e 5 abaixo para outros cenários. Então, na etapa 304, a S-CSCF 1 20 realiza a desalocação, desregistrando o usuário 22 (se o usuário estiver registrado com ele), ou redesignando a S-CSCF 1 20 do usuário 22 se este tiver sido designada ao usuário para provisão de serviços não registrados.

Na etapa 305, a S-CSCF1 20 envia uma resposta de reconhecimento ao HSS 26 do usuário para indicar que o desregistro/eliminação de designação requisitado foi completado.

Neste ponto, as duas coisas podem acontecer. Se o usuário 22 foi desregistrado, tentará se registrar novamente com o IMS. A nova S-CSCF preferida (S-CSCF2 24), supondo que este esteja disponível, será alocado de acordo com procedimentos padrão (ver TS 23.228/TS 29.228). Por outro lado, se a S-CSCF 1 somente se eliminou a designação da usuário 22, então procedimentos de restauração de acordo com TS 23.380 alocarão a nova S-CSCF2 24 a ser designado ao usuário para continuar a provisão de serviços não registrados. A seleção da S-CSCF2 24 (isto é, a determinação de que este é a S-CSCF ótima para o usuário) pode ser com base em tráfego de origem ou término. Alternativamente, a S-CSCF 2 poderia ser selecionada como um resultado de um novo registro por um UE do usuário 22.

Figura 4 ilustra os fluxos de sinal básicos para a situação em que a S-CSCF 1 20 determina que os critérios de desalocação não são satisfeitos. As entidades de rede e os sinais nas etapas 301 e 302 são os mesmos descritos acima, e levam os mesmos numerais de referência da Figura 3. Entretanto, neste caso, ao invés de determinar que os critérios de desalocação são satisfeitos (como na etapa 303 na Figura 3), na etapa 307, a S-CSCF 1 20 determina que os critérios de desalocação não são satisfeitos. Como consequência, a S-CSCF 1 20 não desaloca (desregistra o usuário ou desfaz a designação, ele próprio) porém, ao invés disso, na etapa 308, responde enviando um sinal de erro ao HSS 26 do usuário. A S-CSCF 1 20 permanece alocada ao usuário conforme mostrado na etapa 309.

Figura 5 detalha a lógica de alto nível da S-CSCF para implementar procedimentos de realocação mostrados em na Figura 3 e na Figura 4. Na etapa 501, a S-CSCF está servindo a um usuário registrado ou foi designado para prover serviços não registrados ao usuário. Na etapa 502, a S-CSCF recebe uma instrução de disparo, juntamente com critérios associados, para desalocação, seja desregistrando o usuário ou retirando a designação, ele próprio, do usuário. Na etapa 503, a S-CSCF determina se os critérios são satisfeitos, e caso afirmativo avança para a etapa 504 onde desregistra o usuário ou retira a designação dele próprio, após o que envia um reconhecimento ao HSS do usuário.

Se, na etapa 503, a S-CSCF determina que os critérios não são satisfeitos, este avança para a etapa 505. Aqui, é feita uma determinação adicional, que depende da política da operadora de rede. A política pode requerer que a S-CSCF continUE tentando, de tal modo que a desalocação possa ocorrer quando os critérios forem satisfeitos. Nesse caso, a S-CSCF avança para aguardar um instante especificado, conforme mostrado na etapa 506 e então retomar a etapa 503 para determinar se os critérios são satisfeitos. Por exemplo, se os critérios especificam não desregistrar o usuário se este estiver engajado em uma sessão ativa, e na etapa 503 a S-CSCF determinar que o usuário está engajado numa chamada, então, se a política requer isto, na etapa 505 a S-CSCF pode aguardar, digamos por cinco ou dez minutos na etapa 506, antes de tentar novamente verificar se a sessão foi terminada. Entretanto, se na etapa 505 não há tal exigência de política, a S-CSCF avança para a etapa 507, onde aborta a desalocação e, se aplicável, envia uma mensagem de erro ao HSS, como na etapa 308 na Figura 4.

Será visto que os procedimentos descritos acima não envolvem efetuar quaisquer modificações na funcionalidade do I-CSCF ou outras entidades de rede. Em adição, o controle da realocação e as decisões sobre quando e a qual S-CSCF realocar, podem todas ser tomadas pelo sistema de gerenciamento de rede através do HSS do usuário. Ainda mais, os procedimentos habilitam realimentação onde um usuário tiver se registrado com o IMS e onde a S-CSCF estiver somente designada a um usuário para provisão de serviços não registrados.

Claims

Método para modificar alocação de S-CSCFs para um usuário (22) de uma rede IMS, em que o usuário (22) está sendo provido com serviços através de uma primeira S-CSCF (20) alocada ao usuário (22), o método caracterizado pelo fato de compreender:
receber na primeira S-CSCF (20) critérios que devem ser atendidos antes que a primeira S-CSCF (20) seja desalocada do usuário (22);
receber na primeira S-CSCF (20) uma instrução de desalocação (302);
em resposta ao recebimento da instrução de desalocação, a primeira S-CSCF (20) determinar se os critérios são atendidos (303); e
se os critérios são satisfeitos, a primeira S-CSCF (20) se desalocará do usuário (304).
Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a alocação de uma S-CSCF a um usuário (22) compreende ou registro do usuário (22) na S-CSCF ou designação da S-CSCF ao usuário (22) para a provisão de serviços não registrados, e em que desalocação compreende desregistrar o usuário (22) ou retirar a designação da S-CSCF do usuário(22).
Método, de acordo com a reivindicação 2, caracterizado pelo fato de que os critérios para desalocação compreendem critérios de desalocação, em que um usuário (22) registrado deve ser desregistrado ou a S-CSCF designada ao usuário (22) deve ser retirada da designação, se os critérios são satisfeitos.
Método, de acordo com a reivindicação 3, caracterizado pelo fato de que inclui critérios de desregistro ou de retirada de designação de sessão não ativa, em que o usuário (22) deve ser desregistrado ou ter retirada a designação de sua S-CSCF, se o usuário (22) não estiver engajado em uma sessão de IMS ativa.
Método, de acordo com a reivindicação 3, caracterizado pelo fato de que inclui critérios de desregistro ou de retirada de designação específicos de sessão, em que o usuário (22) não deve ser desregistrado ou ter retirada a designação de sua S-CSCF, se o usuário (22) estiver engajado em um ou mais de certos tipos de sessão e/ou diálogo.
Método, de acordo com qualquer uma das reivindicações 1 a 5, caracterizado pelo fato de que compreende adicionalmente enviar a instrução de realocação e critérios associados do HSS (26) do usuário (22) para a primeira S-CSCF (20), via interface Cx (201).
Método, de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de que a instrução de realocação e critérios associados são recebidos de uma entidade de sistema de rede diferente do HSS (26) do usuário (22) ou primeira S-CSCF (20).
Método, de acordo com a reivindicação 7, caracterizado pelo fato de que a entidade de sistema de rede compreende uma função de balanceamento de carga.
Método, de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de que a instrução de realocação é gerada pela lógica local dentro da primeira S-CSCF (20).
Método, de acordo com qualquer uma das reivindicações 1 a 9, caracterizado pelo fato de que compreende adicionalmente enviar uma resposta ao HSS (26) do usuário (22) para confirmar que a desalocação da primeira S-CSCF (20) foi completada.
Método, de acordo com qualquer uma das reivindicações 1 a 10, caracterizado pelo fato de que compreende adicionalmente alocar uma segunda S-CSCF (24) ao usuário (22) para provisão de serviços.
Método, de acordo com qualquer uma das reivindicações 1 a 9, caracterizado pelo fato de que compreende adicionalmente enviar uma mensagem de erro ao HSS (26) do usuário (22), para indicar que os critérios para desalocação não foram satisfeitos.
Método, de acordo com qualquer uma das reivindicações 1 a 12, caracterizado pelo fato de que a instrução de realocação e os critérios de desalocação são providos à primeira S-CSCF (20) em instantes diferentes.
S-CSCF (20) para uma rede IMS, configurada para implementar um procedimento de realocação em relação a um usuário (22) sendo provido de serviços através da S-CSCF (20), caracterizada pelo fato de que:
a S-CSCF (20) é adaptada para ser fornecida com critérios que devem ser satisfeitos antes que a S-CSCF (20) seja desalocada de usuário (22);
a S-CSCF (20) é adaptada para receber uma instrução de desalocação (302);
em resposta ao recebimento da instrução de desalocação, a S-CSCF (20) é adaptada para determinar se os critérios são atendidos (303); e
se os critérios são atendidos, a S-CSCF (20) é adaptada para se desalocar como um provedor de serviços ao usuário (304).
S-CSCF (20), de acordo com a reivindicação 14, caracterizada pelo fato de que a instrução de realocação e critérios de desalocação são incluídos em uma ou mais mensagens recebidas através de uma interface Cx (201) da S-CSCF (20).
S-CSCF (20), de acordo com a reivindicação 14, caracterizada pelo fato de que é adicionalmente configurada para gerar a instrução de realocação dentro da lógica local na S-CSCF (20).