"SISTEMA PARA ESTABELECER UMA CONEXÃO EM UMA REDE DE COMUNICAÇÃO, MÉTODO PARA SELECIONAR U M ENDEREÇO EM UMA REDE DE COMUNICAÇÃO, EQUIPAM ENTO DE USUÁRIO, SISTEMA, CONTROLADOR, E, ELEMENTO DE REDE’.
Campo da Invenção A presente invenção refere-se a um sistema de e processo para estabelecer uma conexão em uma rede de comunicações. A rede de comunicações pode ser uma rede somente de dados, uma rede para transmitir dados e/ou outro tipo de informações tal como voz ou pode ser uma rede exclusivamente reservada para informações de não-dados, A rede pode ser uma rede de circuito comutado, uma rede comutada por pacotes tal como uma GPRS ou rede UMTS, ou pode consistir em uma combinação de redes de diferentes tipos.
Fundamentos da Invenção Ao estabelecer uma conexão em uma rede de comunicações, usualmente vários elementos de rede são envolvidos, inclusive o elemento de rede originário da conexão, o elemento de rede de terminação da conexão e/ou mais elementos de rede intermediários tal como uma estação base, uma estação transceptora base, um controlador de estação base e/ou um mais Nós de suporte tratando da sinalização e/ou tráfego de usuário. A título de exemplo, em uma rede baseada em GPRS ou baseada em UMTS, na conexão (p.ex, urna chamada) originária de, ou terminando em, um equipamento de usuário tal como uma estação móvel (MS) é estabelecida com um equipamento terminador ou originador de conexão utilizando um controlador de rede de rádio (RNC) que comunica-se com um SGSN (Nó de Suporte GPRS Servidor) e possivelmente um OGSN (Nó de Suporte GPRS de Porta). O equipamento de terminação ou originário da conexão pode scr localizado na mesma ou em uma rede diferente. Particularmente, no caso de equipamentos de usuário móvel, a sua locação efetiva é definida com uma resolução de uma área de roteamento (p.ex. em um estado inativo) ou com uma resolução mais fina de uma célula (p.ex. ao tratar de uma conexão tal como uma chamada). Observe-se que área/zona de roteamento (RA) é um termo padrão usado em conjunção com GPRS, área de roteamento (enquanto os sistemas de Circuito Comutado GSM e UMTS usam o termo Zona/área de Locação (LA). Em ambos os casos, a zona está se reportando à zona onde uma estação móvel está registrada no nó servidor (p.ex. SGSN ou MSC/VLR), e onde eventualmente o nó servidor busca a estação móvel para estabelecer conexão de enlace descendente. No presente pedido, o termo área será usado para se reportar à zona de posição e/ou a área de roteamento. A área de cobertura de uma rede inteira é usualmente dividida em várias áreas (RA ou LA), com uma área (em uma rede baseada em GPRS ou UMTS) sendo alocada a um nó servidor (um nó servidor tipicamente atendendo a muitas áreas). Ao ter informações sobre a área onde o equipamento de usuário está presentemente localizado, o nó servidor a cargo de estabelecer uma conexão para ou deste equipamento de usuário é precisamente definido.
Por exemplo, em GSM e UMTS, esta correlação de um para um entre áreas de roteamento ou de posição e os SGSNs alocados podem, todavia, ser desvantajosa no caso de uma interrupção de um SGSN ou operações de manutenção necessárias tal como atualização de software. Neste caso, a área de roteamento tem de ser completamente paralisada e está pelo menos temporariamente fora de uso para estabelecer conexões.
Esta situação pode ser significativamente aperfeiçoada ao alterar a estrutura de rede de tal maneira que pelo menos dois nós servidores tais como dois SGSNs estão capacitados de tratar da mesma área de roteamento. Neste caso, p.ex. um controlador de estação base (BSC) ou controlador de rede de rádio (RNC) pode utilizar diferentes interfaces tais como Iu e/ou Gb. Vários tipos de estações móveis podem ser suportados pela utilização de duas interfaces de rádio e proporcionar somente uma única estação transceptora base (BTS). O fornecimento de dois ou mais nós de suporte servindo a mesma área de roteamento proporciona várias vantagens tal como resiliência habilitando um RNC (possivelmente tendo uma lista de SGSNs disponíveis) para usar outro SGSN se o SGSN previamente usado vir a se tomar sobrecarregado ou fora de operação. Além disso, operações de manutenção tais como atualizações de software podem ser efetuadas sem paralisação da área. Além disso, a sinalização de rede causada pela transferência entre SGSNs pode ser reduzida.
Como um exemplo, várias SGSNs podem ser previstas para cobrir uma área metropolitana tal como a área de Londres, e uma estação móvel circulando pela cidade pode sempre usar seu SGSN original para estabelecer conexões.
Por exemplo, uma rede IP pode ser introduzida em uma interface tal como interface Iu que atualmente é principalmente usada como uma interface Iu ponto a ponto entre a RNC e o SGSN. Ao introduzir uma rede IP ou rede de algum outro tipo apropriado sobre a interface Iu, um RNC pode ser conectado com vários SGSNs.
Em um caso onde um elemento de rede (que p.ex. está encarregada de controlar a conexão de rádio com um equipamento de usuário) está capacitado a conectar com diferentes nós de suporte sendo altemativamente providos, existe um problema no determinar e selecionar um nó de suporte apropriado, por exemplo um SGSN a ser usado para uma conexão de sinalização. Esta conexão de sinalização pode p.ex. ser usada para transferir mensagens L3 (camada 3) (tal como gerência de mobilidade MM e gerência de sessão SM) entre o equipamento de usuário (p.ex. MS) e os nós de suporte tal como SGSN. Outrossim, no caso de transferência de nó inter-suporte, o novo nó de suporte se beneficiaria do encontro do nó de suporte antigo que estava servindo o equipamento de usuário até a transferência.
Sumário da Invenção A presente invenção oferece uma solução para resolver ou pelo menos aliviar os problemas acíma quer parcíalmente quer inteiramente.
De acordo com um aspecto a invenção apresenta um sistema conforme definido na Reivindicação I. O presente sistema pode consistir em uma rede inteira, pode ser somente uma parte de uma rede ou pode compreender duas ou mais redes.
De acordo com um outro aspecto, a invenção proporciona um processo como definido na reivindicação independente do processo. A invenção adicionalmente apresenta, de acordo com um outro aspecto, um ou mais elementos de rede equipados de modo a implementar a estrutura ou funções de hardware utilizáveis em uma rede ou processo de conexão ou seleção como definido nas reivindicações e/ou descrito no presente relatório descritivo. A presente invenção oferece uma solução para permitir que um primeiro elemento de rede tal como um controlador de rede de rádio ou controlador de estação base decidir qual nó de suporte utilizar para uma conexão (p.ex. conexão de sinalização ou conexão dc tráfego dc usuário).
Uma conexão de sinalização é provida para transferir mensagens tais como mensagens L3, p.ex., MM e SM, entre um elemento de rede tal como o equipamento de um usuário, p.ex. MS. e o nó de suporte. Assim, o primeiro elemento de rede pode ser alternativamente conectado com diferentes nós de suporte servindo, p.ex. a mesma área de roteamento. Uma implementação deste tipo proporciona as vantagens acima mencionadas. A invenção também apresentando, no caso de uma transferência de uma conexão entre diferentes nós de suporte tais como SGSNs, uma estrutura e processo habilitando o novo nó de suporte a encontrar o nó de suporte antigo que até agora servia ao equipamento de usuário.
De acordo com a invenção, um identificador de área tal como 'Identidade de Área de Roteamento (RAI)" pode ser usado pelo primeiro elemento de rede ( p.ex.RNC) para derivar uma lista de segundos elementos de rede altemativamente selecionáveis tais como nós de suporte. Nesta lista diferentes nós de suporte são identificados pelos seus endereços. Esta lista pode ser pré-configurada dentro do RNC. De acordo com outra concretização, o primeiro elemento de rede pode enviar uma mensagem ou solicitação contendo o identificador (p.ex. RAI) para outro elemento de rede tal como um servidor DNS (Sistema de Nome de Domínio) para receber, como uma resposta uma lista de possíveis segundos elementos de rede servindo a área de roteamento indicada pela RAI. Isto evita a necessidade de lista pré-configurada, e o DNS é particularmente conveniente se a lista de possíveis segundos elementos de rede contém endereços IP. O outro elemento de rede de preferência contém ou coopera com, uma memória armazenando a lista (tabela) de possíveis segundos elementos de rede, e pode enviar esta lista como uma lista rolante ou distribuída para espalhar a carga. A lista pode por exemplo ser transmitida na forma de várias partes, cada parte indicando somente um ou dois (ou mais) segundos elementos de rede selecionáveis. A lista pode ser escalonada em uma ordem definida, por exemplo baseada sobre o endereço do primeiro elemento de rede que expediu a solicitação de lista ou indicando primeiro um segundo elemento de rede default para esta área. O escalonamento pode ser tal que o primeiro dos segundos elementos de rede indicado na lista seja sempre o mais próximo do primeiro elemento de rede, o segundo dos segundos elementos de rede sendo o segundo mais próximo do primeiro elemento de rede, etc. A ordem de listagem dos segundos elementos de rede na lista também pode, em uma concretização, ser baseada sobre informações sobre a carga atual ou prévia de cada segundo elemento de rede listado. Como uma alternativa, a ordem de listagem dos segundos elementos de rede pode ser mantida inalterada, porém informações adicionais são afixadas à lista indicando a condição da carga atual ou prévia dos segundos elementos de rede listados. Neste caso, o primeiro elemento de rede é adaptado para testar as informações de condição de carga igualmente, e selecionar um dos segundos elementos de rede tendo a menor carga ou pelo menos sendo um dos segundos elementos de rede de carga mais leve. A modificação da ordem da listagem dos segundos elementos 10 de rede levando em conta a carga, ou a afixação das informações de carga à lista, de preferência é realizada pelo sistema de operação e manutenção (O&M) provido para a rede.
De acordo com uma possível implementação da invenção, um segundo elemento de rede para o qual uma operação de manutenção tal como uma atualização de software é planejada, pode ser extraído da lista (a ser transmitida para um primeiro elemento de rede solicitante) algum tempo tal como algumas horas antes da atualização do software. Desta maneira, pode- se assegurar que nenhuma ou pelo menos não muitas conexões ou contextos serão ainda tratados por este segundo elemento de rede.
De acordo com uma possível implementação da invenção, se um segundo elemento de rede não está respondendo, outro segundo elemento de rede pode ser selecionado da lista.
De acordo com uma possível implementação, o identificador tal como um Identificador de CN (Rede de Núcleo) pode ser adicionado a uma mensagem, p.ex. mensagem RRC (Controle de Recurso de Rádio) que é usada para iniciar uma conexão e/ou conduzir uma mensagem tal como uma mensagem 3 (p.ex. Solicitação Afixada, Solicitação de Atualização de Área de Roteamento ou Solicitação de Serviço). O primeiro elemento de rede (p.ex. RNC) testa o identificador (p.ex. Identificador de CN) da mensagem RRC.
Além disso, o primeiro elemento de rede também pode ser adaptado para reduzir o identificador de área tal como RAI da célula onde o equipamento de usuário está efetivamente localizado. A combinação de identificador de área e Identificador de CN identifica claramente o nó servidor. O primeiro elemento de rede deriva o endereço de nó servidor de uma lista. Em uma concretização, o primeiro elemento de rede utiliza o identificador de área e/ou o identificador de CN para solicitar ao elemento de rede transmissor de lista tal como um servidor DNS para transmitir uma lista de segundos elementos de rede alocados ao identificador transmitido.
Determinados sistemas, tais como sistemas GSM ou UMTS têm diferentes tipos de nós servidores (p.ex. SGSN e MSC/VLR) servindo a mesma área. No sistema UMTS, a sinalização RRC contém um parâmetro (identidade de domínio CN) identificando o tipo CN. No GSM, o tipo CN é identificador implicitamente a partir do tipo de canal estabelecido.
Nos sistemas dessa natureza, a indicação de tipo CN adicional à combinação de identificador de área e Identificador de CN pode ser necessária para identificar claramente o nó servidor.
De acordo com uma possível implementação da invenção um dos segundos elementos de rede pode ser estabelecido como um segundo elemento de rede default servindo a área de roteamento na qual o equipamento de terminação ou de originador de conexão tal como MS está presentemente localizado. O primeiro elemento de rede será configurado para utilizar este segundo elemento de rede default para processar uma conexão enquanto nenhum outro segundo elemento de rede seja selecionado (isto é, o identificador de CN não é transmitido pelo MS).
De acordo com uma concretização da invenção, a seleção de um dos segundos elementos de rede disponíveis cobrindo uma determinada área de roteamento pode ser realizada na dependência de informações provenientes de outro elemento de rede tal como o equipamento de um usuário. Se o equipamento de usuário deseja estabelecer uma conexão p.ex. uma conexão de sinalização, com um determinado nó de suporte (segundo elemento de rede) que por exemplo havia previamente processado a conexão para e deste equipamento de usuário, o equipamento de usuário de preferência é adaptado para transmitir informação adicional tal como identificador de CN para p.ex. o primeiro elemento de rede que pode ser um RNC. A título de exemplo, o equipamento de usuário havia estabelecido uma conexão de sinalização com um determinado nó de suporte, p.ex. SGSN, após o que a conexão de sinalização havia sido liberada e o equipamento de usuário deseja estabelecer a conexão de sinalização mais uma vez com o mesmo nó de suporte.
De acordo com um aspecto da invenção, o equipamento de usuário pode então adicionar uma informação de identificação tal como identificador de CN a uma mensagem que, por ex., pode ser usada para conduzir ✓ uma mensagem L3 (p.ex. uma Solicitação de Atualização de Area de Roteamento ou Solicitação de Serviço). Se a MS se deslocar para uma nova área que não pode ser atendida pelo nó servidor prévio no qual está registrada, RNC seleciona um novo nó servidor, e o novo nó servidor será suscetível de derivar o endereço de nó servidor antigo utilizando a combinação de um Identificador de CN (adicionado de acordo com esta concretização à Solicitação de Atualização de Area de Roteamento) e o RAI antigo (transmitido na Solicitação de Atualização de Area de Roteamento em GSM e UMTS). Além disso, ou como uma alternativa, o primeiro elemento de rede (p.ex. RNC) pode testar a informação de Identificador de CN proveniente da mensagem L3. O novo nó servidor deve transmitir seu identificador de CN em p.ex. em aceitação de Atualização de Area de Roteamento, ou afixar a aceitação para o MS. A invenção além disso oferece uma possibilidade de determinar e selecionar um nó de suporte antigo (p.ex. SGSSN antigo) por um novo nó de suporte, particularmente após transferência inter-nós. Observe-se que em uma estrutura na qual o SGSN antigo pode ser encontrado como RAI antigo (quando somente um SGSN serve uma área de roteamento específica designada por RAI), inexiste problema no determinar o SGSN antigo. Todavia, em uma situação onde uma área de roteamento é coberta por vários nós de suporte em paralelo, será vantajoso se o novo nó de suporte é suscetível de detectar o nó de suporte antigo de maneira p.ex. a copiar informações de contexto para processar a conexão tais como informações de contexto PDP (Protocolo de Dados em Pacote).
De acordo com um aspecto da invenção, o elemento de rede armazenando a lista de segundos elementos de rede (isto é, nós de suporte) cobrindo uma determinada área tal como R.A (Área de Roteamento) ou LA (Área de Posição) pode adicionalmente armazenar, para cada nó de suporte, um identificador de CN identificando este nó de suporte. Este identificador pode ser transmitido como um novo Elemento de Informação (isto é, é transmitido explicitamente) ou pode ser codificado com parte de outro Elemento de Informação tal como uma identidade temporária (isto é, é transmitido implicitamente). Como um exemplo de transmitir o identificador de CN implicitamente, o identificador de CN pode ser formado por alguns bits (p.ex. 4 últimos bits) de PTMSI (Identidade de Estação Móvel Temporária de Pacote). O elemento de rede armazenando a lista de segundos elementos de rede disponíveis para as respectivas áreas (p.ex. RA ou LA). Pode ser um servidor DNS, e de preferência armazena a lista de nós de suporte mapeada com os respectivos indicadores de área tais como RAls (Identidades de Área de Posição). Este elemento de rede pode retomar, em resposta a um indicador de área transmitido para o mesmo, não somente se os endereços IP de cada nó de suporte (segundo elemento de rede) alocado à respectiva área (p.ex. RAI), porém adicionalmente também os identificadores de elemento de rede alocados a estes nós de suporte, e eventualmente o tipo de nó de suporte. O elemento de rede a cargo de selecionar o segundo elemento de rede para processar a conexão (p.ex. conexão de sinalização) pode então selecionar aquele segundo elemento de rede que tem um identificador de elemento de rede correspondente ao identificador de elemento de rede transmitido p.ex., pelo equipamento de usuário como critério de seleção.
Como uma alternativa, o elemento de rede que armazena a lista pode ser consultado com ambos identificadores de CN e identificador de área, de forma que somente o endereço do nó de suporte correto seja retomado. O tipo de nó de suporte pode ser usado p.ex. em uma rede compreendendo ambos 2G e 3G SGSN. Neste caso um RNC (3G somente) pode somente selecionar um nó de suporte indicado como um nó de suporte 3G baseado sobre o tipo de nó de suporte indicado. O segundo elemento de rede conforme definido nas reivindicações pode de preferência manter informações de estado acerca do equipamento de usuário (p.ex. locação, dados de assinante, etc.). As informações de estado permitem manter a conexão com o mesmo nó servidor, p.ex. mesmo SGSN. Sem informações de estado, o equipamento de usuário podería mudar o nó servidor, p.ex. SGSN, em cada conexão. A conexão de preferência é mantida nos mesmos segundos elementos de rede quando a MS está se deslocando dentro da área CN.
De maneira a evitar problemas de processamento, de acordo com um aspecto da invenção um dos segundos elementos de rede (p.ex. SGSN) disponível para uma área de roteamento pode ser um elemento de rede mestre que, se não processando ele próprio as informações de contexto tal como contexto PDP, pode atuar como um relé, e pode determinar o segundo elemento de rede antigo baseado, p.ex. sobre o identificador transmitido por exemplo equipamento de usuário conjuntamente com PTMSI. Neste caso, o identificador pode ter sido transmitido do nó de suporte antigo para o equipamento de usuário juntamente com PTMSI durante (p.ex. ao início ou término) do período de tempo durante o qual esteve a carga para processar a conexão para o equipamento de usuário. O equipamento de usuário assim conhece o elemento de rede de suporte tal como o nó de suporte que processou suas conexões. Esta concretização pode ser particularmente aplicável se o SGSN para onde a M S se deslocou não foi atualizado para encontrar o SGSN antigo (isto é, prévio) apropriado.
Os segundos elementos de rede também podem ser MSCs (Centros de Comutação Móveis) ou outros tipos de elementos servidores, p.ex. em redes por comutação de circuitos.
As soluções propostas pela presente invenção são além disso aplicáveis em um caso onde elementos de rede de diferente geração (tal como 2G SGSN e uma 3G SGSN) são fornecidas que processam as conexões para a mesma área de roteamento. A seleção do nó de suporte pode ser feita dependendo do tipo da conexão estabelecida e/ou solicitada, ou sobre o tipo de equipamento de usuário. A título de exemplo, a invenção pode ser empregada em um sistema GERAN (rede de acesso de rádio GSM/EDGE). A presente invenção permite uma adaptação eficaz de uma rede celular sendo pelo menos parcialmente baseada em IP. As redes IP são essencialmente estruturadas par a par ao passo que as redes celulares convencionais tais como GSM, UMTS, etc. são tipicamente baseadas sobre uma arquitetura hierárquica na qual uma rede de acesso de rádio (RAN) ou, em maior detalhe, um controlador controlando o acesso de rádio tal como um RNC, RNS, BTS, BSS e semelhantes, é atendido por um único nó servidor (p.ex., MSC/VLR; SGSN;....). A invenção genericamente propõe uma estrutura e processo nos quais um elemento de rede proporcionando p.ex. acesso de rádio (p.ex. RAN) ao equipamento de um usuário é conectada com muitos nós servidores tais como nós de rede de núcleo (CN). Isto reduz o número de procedimentos de atualização de área inter-CN-nó e aumenta a confiabilidade. A invenção assim propõe uma nova arquitetura para um sistema celular no qual uma rede de acesso de rádio (ou o elemento de rede proporcionando ou controlando o acesso de rádio) assim como uma área de locação (LA) ou área de roteamento (RA) pode ser tratada por muitos nós servidores do mesmo tipo. Uma função de roteamento para decidir com qual nó servidor a conexão deve ser estabelecida, de preferência está localizada na rede de acesso de rádio (RAN) ou no respectivo elemento de rede proporcionando ou controlando o acesso de rádio, e não está localizada entre a rede de acesso de rádio e o nó servidor, ou no nó servidor. A função de roteamento localizada na RAN adicionalmente proporciona ou compreende um processo para a seleção do nó servidor com o qual conectar-se.
Outrossim, o processo e sistema de acordo com a invenção pode ser usado para detectar o nó onde o equipamento de um usuário está atualmente registrado, um dos elementos de rede tendo uma lista de nós servidores servindo a presente área de localização (ou área de roteamento) do equipamento de usuário. De preferência esta lista inclui um nó servidor default. O nó servidor a ser usado para estabelecer a conexão é de preferência determinado da seguinte maneira: Quando o equipamento de usuário não transmitiu um identificador tal como um identificador de rede de núcleo (CN), o nó servidor default, se definido, será selecionado da lista. Se o equipamento de usuário emitiu um identificador tal como um identificador de CN, um nó servidor correspondente a este identificador será selecionado. O nó servidor default pode ser definido para ser o nó servidor mencionado em uma posição específica da lista para a área de locação ou de roteamento, p.ex. o primeiro nó servidor mencionado na lista. Quando nenhum Identificador é emitido pelo equipamento de usuário, o nó servidor mencionado no local especifico, p.ex., o nó servidor primeiramente mencionado, é selecionado pela RAN da lista, Este processo e estrutura pode ser usado pela rede de acesso de rádio (ou nó ou componente controlador de RAN) para determinar o nó servidor a ser usado. De modo idêntico, este processo e estrutura podem ser usados pelo novo nó servidor para determinar o nó servidor anterior com o qual o equipamento de usuário estava registrado, ou pode ser usado pelo novo nó servidor para determinar o MSC/VLR com o qual o equipamento de usuário estava registrado, particularmente em um caso quando é usada a interface Gs.
Dc acordo com um aspecto da invenção, o equipamento de um usuário tal como uma M SS pode ser adaptado para selecionar um nó servidor usando um identificador de CN. O identificador de CN pode ser o identificador mais recentemente usado, ou pode ser um pré-configurado, isto é, identificador de CN predeterminado que é armazenado no equipamento de usuário, p.ex. em um cartão SIM do mesmo. Este aspecto é reivindicado nas reivindicações 48 a 52.
Além disso, o processo e sistema de acordo com a invenção pode ser usado para permitir muitos operadores (cada um possuindo seu próprio nó servidor) a compartilhar uma Rede dc Acesso de Rádio (possuída por outro operador). Se cada operador utiliza um. identificador diferente CN, e se as MS são configuradas para sempre usar o mesmo identificador de CN (mesm.o na primeira solicitação de afíxação) baseado sobre informações de assinatura tipicamente lidas de um cartão SIM, então a MS será sempre conectada com uma SGSN de propriedade deste operador (do qual adquiriu o cartão SIM). A invenção assim igualmente proporciona um sistema conforme definido nas Reivindicações 53 a 55, e/ou elementos de rede conforme definidos nas demais reivindicações.
Descrição Sucinta das Figuras A fig. I mostra uma estrutura básica de uma concretização de um sistema de acordo coin a invenção; A fig. 2 ilustra o flu.xo de mensagem para estabelecer uma conexão entre o equipamento de um usuário e um nó servidor; A fig. 3 mostra um processo para selecionar um nó servidor desejado; A fig. 4 ilustra um fluxo de mensagem em um sistema e processo de acordo com uma outra concretização da invenção; A Fig, 5 mostra detalhes de uma tabela armazenada em um servidor DNS; A fig. 6 ilustra as etapas de processo conduzidas em um Procedimento de Atualização de Área de Roteamento de acordo com uma concretização da invenção relacionada com UMTS; A fig. 7 mostras etapas realizadas em um Procedimento de Relocaçáo SNRS e Atualização URA/Célula Combinado de acordo com outra concretização da invenção; A fig. 8 ilustra um fluxo de mensagem em um sistema e processo de acordo com outra concretização da invenção; e A fig, 9 mostra um fluxo de mensagem em um sistema e processo de acordo com outra concretização da invenção.
Descrição Detalhada de Concretizações Preferenciais da Invenção. A figura 1 mostra a estrutura básica de uma concretização de um sistema de acordo com a invenção. O sistema é implementado como uma rede 1, ou forma parle da mesma, cuja rede 1 compreende pelo menos um, ou usualmente uma pluralidade de, equipamentos de usuário 2 que, na presente concretização, são implementados como estações móveis MS. Os equipamentos de usuário também podem ser de qualquer outro tipo de equipamentos tais como terminais estacionários. Embora somente um equipamento de usuário 2 seja mostrado, vários equipamentos de usuário são afixados à rede I e representam equipamentos de originar ou terminar conexões.
No caso de conexão, ou estabelecimento de conexão, com outro equipamento formador de parte de rede 1 ou de outra rede, uma conexão de rádio com o equipamento de usuário 2 é provida e processada por uma rede de acesso de rádio (RAN). A RAN compreende, nesta concretização um controlador de rede de rádio (RNC) 3 que é parte de, ou representa, a rede de acesso de rádio para radio conexão com equipamento de usuário 2. Usualmente, várias redes e controladores de acesso de rádio 3 serão previstas na rede 1 para cobertura de rádio das diferentes áreas da rede. O RNC 3 (primeiro elemento de rede) pode ser seletivamente conectado com diferentes nós servidores que, na presente concretização, são implementados como SGSN 4 e 6. A rede pode compreender nós servidores adicionais ou alternativos tais como centros de comutação móveis (MSCs) que normalmente serão combinados com registros de localização de visitante (VLRs). Os nós servidores 4, 6 podem ser conectados, se necessário, com um nó (porta) entre redes 5 que aqui é um GGSN e oferece a possibilidade de conexão com outras redes.
Além disso, um servidor DNS (Sistema de Nome de Domínio) 7 é provido que pode fomlar parte de rede 1 ou pode ser componente externo de rede. O servidor DNS 7 pode ser acessado pelo RNC 3, e usualmente também por outros componentes de rede tais como nós servidores 4, 6 e/ou nó (porta) entre redes 5. As possibilidades de comunicação são indicadas na fig. 1 como setas de cabeça dupla. O servidor DNS 7 compreende, ou tem possibilidade de acesso à uma memória (não mostrada) armazenando listas (tabelas) de nós servidores disponíveis para altemativamente cobrir áreas de roteamento ou áreas de locação da rede 1. A fig. 5 mostra um exemplo de uma tabela armazenada na memória. De acordo com este exemplo, a tabela conténl várias colunas e fileiras. A colina esquerda "SGSN" relaciona os nós servidores disponíveis. SGSN1 pode corresponder a SGSN 4, SGSN2 pode corresponder a SGSN 6, e SGSN3, SGSN4 pode corresponder a outros nós servidores não mostrados na fig. 1 e cobrindo outras áreas de roteamento ou locação da rede 1. A tabela além disso contém uma coluna "endereço IP de SGSN" listando os endereços IP dos nós servidores disponíveis individuais. A coluna "nome de SGSN" ou "(identificador de SGSN)" lista os identificadores identificando os nós servidores individuais.
Neste exemplo o tipo do nó (2G ou 3G) é incorporado no identificador. A coluna ✓ "Area de Roteamento" lista as áreas de roteamento ou de localização sendo cobertas pelos nós servidores individuais. Como um exemplo, os nós servidores SGSN1, SGSN2, SGSN3 e SGSN4 são disponíveis para cobrir a mesma primeira área de roteamento RAI ao passo que os nós servidores SGSNI, SGSN2, SGSN3 e SGSNS são disponíveis para altemativamente cobrir uma segunda área de roteamento RA2 são disponíveis para altemativamente cobrir uma segunda área de roteamento RA2 na qual uma estação móvel pode estar localizada, p.ex. após se transferir para a mesma a partir da área de roteamento RA1.
Dependendo dos detalhes de implementação de concretizações da invenção a lista armazenada não contém indispensavelmente todas as colunas mostradas na fig. 5 . Por exemplo, a coluna " SGSN” e/ou "Área de Roteamento" (se todas RAs processadas por RNC utilizam o mesmo identificador de CN e a lista é específica por RNC) pode ser omitida. De modo alternativo, a lista também pode conter informações adicionais, úteis para selecionar um nó servidor apropriado. Por exemplo, uma coluna "tipo de nó servidor e/ou uma coluna indicando nós default para algumas ou todas as respectivas áreas pode ser adicionada.
Genericamente, a arquitetura de uma rede ou sistema de acordo com a invenção compreende dois ou mais CN (Rede Núcleo) do mesmo tipo (p.ex. MSC e/ou SGSN.) que são conectadas com a mesma rede de acesso de rádio ou nó RAN (p.ex. BSS "subsistema estação base"; UTRAN "Rede de Rádio Acesso Terrestre UMTS; GERAN ("Rede de Rádio Acesso GSM/EDGE") e alocada à mesma área de locação ( LA ) e/ou área de roteamento (RA). Uma ou mais das RANs providas contém, ou são suscetíveis de baixar de um elemento de rede tal como o servidor DNS 7, uma lista pré-configurada tal como o servidor DNS 7, uma lista pré- configurada de nós CN. De preferência, os nós CN são associados com um identificador de CN que é singular para pelo menos para a LA/RA alocada. O sistema e processo de acordo com as concretizações preferenciais da invenção são de preferência de tal maneira estruturadas que cada vez que o equipamento de um usuário se registra em um local ou área de roteamento (por exemplo, realizando um procedimento de Afixação ou Atualização de área), o no CN que trata do registro retoma o seu identificador de CN ao equipamento de usuário, p.ex. na sinalização MM (Gerência de Mobilidade). O equipamento de usuário é adaptado para armazenar um identificador de CN recebido representando o nó servidor atualmente processando uma conexão. Outrossim, o equipamento de usuário pode ser projetado para indicar o identificador de CN se conhecido e/ou se um restabelecimento da conexão com um CN previamente usado é desejado), se desejado. Quando o equipamento de usuário estabelece unia conexão com a rede de rádio. O identificador de CN pode ser indicado por exemplo na rádio sinalização p.ex. durante estabelecimento de conexão RRC.
De modo a estabelecer compatibilidade retrograda, o novo elemento de informação (identificador tal como identificador de CN) é um elemento de informação opcional transmitido em sinalização tanto MM e RRC (se um elemento de informação explicito é usado para ambos os protocolos). Isto assegura que os equipamentos de usuário que não suportam esta característica não obstante trabalharão com novos elementos de rede. Como equipamento de usuário deste tipo nunca está transmitindo o identificador de CN. é sempre conectado com um nó CN que é estabelecido como um nó default a ser selecionado quando não recebendo qualquer identificador de CN. De modo idêntico quando o equipamento de usuário deve passar para uma R.AN não suportando esta característica o RNC é estruturado para ignorar qualquer identificador de CN e estabelecer a conexão sempre com o único nó CN com o qual está conectado.
Se o nó CN não suportar esta característica, nenhum identificador de CN será retomado ao equipamento de usuário. O equipamento de usuário pode ser configurado para apagar o identificador de CN previamente armazenado, para que da próxima vez seja conectado com o nó default. Neste são o equipanlento de usuário é incapaz de transmitir qualquer identificador de CN na solicitação de conexão seguinte e assim será conectado com o nó CN default previsto para esta área. Em todos estes casos, o resultado é similar aos sistemas existentes.
Se um nó CN não está suportando estas características, ele deve ser configurado como o nó CN default.
Quando um acesso (conexão) de rádio GSM é usado em uma rede baseada em GPRS ou outro tipo de rede baseado em pacotes, o TLLI (Identificador de Enlace Lógico Temporário) é transmitido para o controlador de estação base BSC com cada transferência de pacote. Ao considerar a adição de um identificador de CN separado, uma pesada carga de rádio resultaria pois o identificador de CN teria de ser transmitido com cada transferência de pacote igualmente. De acordo com uma concretização da invenção, o identificador de CN será transmitido implicitamente, isto é, codificado dentro do TLLI. Deve ser observado que TLLI é sempre derivado de PTMSI alterando os três primeiros bits. Esta codificação pode ser efetuada codificando a identidade temporária (PTMSI e TLLI) de uma maneira definida, por exemplo, usando os 4 últimos bits para indicar o identificador DN. Esta solução não aumenta a carga nem de rádio nem de sinalização. Ao transmitir uma mensagem de Atualização de Área de Roteamento (RAU) e/ou Solicitação de Afixação, o equipamento de usuário automaticamente transmite o TLLI anterior. O novo PTMSI codificado de modo a conter o identificador de CN do elemento de rede servidor servindo a conexão, é transmitido de retorno na mensagem de resposta de RAU/Afixação ao nível de sinalização de rádio. Assim, esta característica de transmitir um identificador de CN pode ser introduzida em uma rede baseada em GPRS sem trocas dos protocolos. Porém requer que o BSC implemente o processo descrito na presente invenção para selecionar o SGSN correto para cada transferência de pacote.
Em uma rede UMTS, a solução acima é igualmente aplicável porém exigiría o RNC a ler o PTMSI transmitido em mensagens L3MM, que são atualmente somente retransmitidas pelo RNC. Aqui, todavia, há preferência em introduzir um novo elemento de infomlação (isto é transmitir o identificador de CN explicitamente) para identificar o nó servidor a cargo da conexão com o equipamento de usuário. Em uma rede UMTS, o RNC mantém o contexto RRC. Por conseguinte, ao incluir o identificador de CN no contexto RRC, não é necessário transmitir o identificador de CN frequentemente.
Em uma rede GPRS (tanto GSM como UMTS), existe um problema adicional ocorrendo durante uma Atualização de Área de Roteamento inter-SGSN. Durante a transferência em questão, o novo SGSN necessita determinar o SGSN anterior que processou a conexão com o equipamento de usuário até agora. Por exemplo, as informações de contexto PDP (protocolo de Dados de Pacote) tem de ser transferidas do SGSN anterior para o novo SGSN.
De acordo com uma concretização da invenção, o equipamento de usuário de preferência inclui o identificador de CN na mensagem de Solicitação de Atualização de RA (área de Roteamento), e o servidor DNS 5 retoma, mediante uma respectiva consulta do RNC 3 indicando o identificador de área de roteamento precedente, uma lista de endereços IP de SGSN a cargo da área de roteamento. Um identificador de CN é implicitamente ou explicitamente associado com cada endereço IP, tal como mostrado na fíg. 5. O identificador CN é implicitamente indicado se a posição na lista indica o identificador de CN. Neste caso, é desnecessário transmitir separadamente o indicador de CN (p.ex. SGSN). Quando, na lista de exemplo mostrada na fig. 5, o identificador de área de roteamento designa a área de roteamento RA 1, uma lista é retomada do servidor DNS 7 ao RNC 3 contendo SGSN1 e SGSN2 e indicando os seus endereços IP.
Ao transmitir explicitamente os identificadores CN, os identificadores associados “2G_SGSN IDENTIFIER_13” e “3G_SGSN IDENTIFIER 14” são transmitidos associados com os endereços IP. Especificamente o nome Canônico associado com o endereço IP é retomado pelo servidor DNS7 ao RNC 3 que representa o valor do identificador de CN. Este conceito efetivamente utiliza a estrutura do DNS que é baseada sobre o nome Canônico (CNAME) ou alcunha, conforme definida p.ex. em RFC 1034 e 1035. Por conseguinte, como parte da resposta do DNS, é transmitida uma lista de endereços IP e nomes canônicos (CNAME), como indicado na fig. 5 pelas duas colunas centrais e as fileiras associadas com a mesma área de roteamento (p.ex. RA1), respectivamente.
Com esta característica, o RNC ou BSC pode facilmente selecionar o SGSN apropriado na base da tecnologia usada pelo equipamento de usuário e do identificador SGSN, que pode ser identificado de p.ex. TLLI e, GPRS, e identificador de CN estendido em UMTS, como acima mencionado.
Quando o identificador de CN é somente implicitamente indicado, é representado pela posição na lista. Por exemplo, quando não transmitido o identificador SGSN NAME, o primeiro SGSN1 é determinado como o SGSN a ser usado para processar a conexão do equipamento de usuário na área de roteamento 1. Este SGSN assim serve p.ex. como um nó servidor default a ser usado para processamento de conexão quando nenhum identificador CN (identificador SGSN) é indicado.
De outro modo, o SGSN tendo um identificador de CN alocado que corresponde ao identificador de CN indicado pelo equipamento de usuário 2, será selecionado como SGSN para processar a conexão, ou para transmitir as informações de contexto para a nova SGSN prévia na base do identificador de CN e o identificador de área que identifica a SGSN prévia e foi transmitido (explicitamente ou implicitamente para identificador de CN) pelo equipamento de usuário em subsequente mensagens, p.ex. juntamente com PTMSI. A RAN ou nova SGSN pode por conseguinte detectar p.ex. o endereço IP da SGSN prévia ao transmitir uma consulta para o servidor DNS7.
Alternativamente, um SGSN mestre pode ser prevista que, quando não tratando do contexto PDP propriamente dito, atua como um retransmissor e determina a SGSN prévia baseada sobre p.ex. o identificador SN. O servidor DNS 7 ou altemativamente ou adicionalmente, o SGSN mestre pode ter uma lista de SGSN mapeada para as R.A.I (RA 1, RA2 na coluna "ÁREA DE ROTEAMENTO" da fig. 5). Neste último caso, não é indispensavelmente necessário munir o servidor DNS de uma lista deste tipo SGSNs mapeados para as RAIs.
Esta informação sobre o SGSN prévio ou antigo pode ser usada pelo novo SGSN para alterar todos os contextos PDP contidos no SGSN antigo para o novo SGSN para um equipamento de usuário ou mesmo para todos os equipamentos de usuário, particularmente ao pretender realizar operações de manutenção do SGSN antigo tal como atualização de software. A lista de endereços SGSN e identificadores de SGSN pode ser modificada no caso de necessitar usar outro SGSN para servir um ou mais identificadores de SGSN. Subsequentes conexões de sinalização serão então estabelecidas com esta outra SGSN ao transmitir estes identificadores de SGSN. Isto também requer a atualização de túneis GTP para os contextos PDP existentes, etc. A fig. 2 refere-se a um caso, no qual o controlador de rede de acesso de raio tal como RNC 3 utilizou o processo proposto para determinar qual SGSN usar para processar uma conexão com um equipamento de usuário MS 2. Em uma etapa 1.), MS 2 transmite uma solicitação, p.ex. uma mensagem de conexão RRC, opcionalmente incluindo o identificador de CN identificando o nó servidor no qual a MS 2 pode estar registrada. O RNC 3 detectar a nova RAI diretamente a partir da célula onde a MS está localizada. A seguir o RNC seleciona a SGN usando uma lista como representada na figura 5 e o processo proposto. Esta lista pode ser pré-configurada no RNC ou recuperada de outro elemento de rede como mostrado pelas etapas 2) e 3).
Em uma etapa 2), o RNC transmite uma solicitação para o servidor DNS 7 solicitando uma lista de SGSNs disponíveis para a área de roteamento. Esta solicitação indica a identidade de área de roteamento RAI. O servidor DNS 7testa a memória de tabela contendo a lista de SGSN tal como mostrada na fig. 5 selecionando somente aquelas SGSNs correspondentes à área de roteamento indicada. Enlunia etapa 3.) o servidor DNS 7 retoma a lista de SGSNs selecionados para o RNC 3.
Como uma alternativa às etapas 2). e 3.), o RNC 3 também pode transmitir, na etapa 2.) adicionalmente, ou somente, o identificador de CN recebido da MS 2, para o servidor DNS 7. O servidor DNS 7 é, neste caso, de preferência adaptado para usar o identificador de CN para seleção do SGSN apropriado da lista, e retoma, na etapa 3.) meramente o endereço IP do SGSN apropriado. O RNC 3 então estabelecerá, nas etapas 4.) a 6.), uma conexão utilizando este único endereço IP recebido da SGSN desejada. O RNC 3 seleciona uma SGSN de acordo com o seguinte processo proposto: Se a CN Id é ou foi transmitida na sinalização, o RNC utiliza a CN Id como uma chave e a área para selecionar para selecionar o nó servidor correto.
Observe-se que a área não necessita ser usada no caso especial onde ais área/s processada pelo RNC tem a mesma configuração (p.ex. RNC processa somente uma RA).
Além disso, o RNC pode testar o tipo do nó servidor. Em um sistema UMTS, um RNC ao processar uma conexão de pacote, necessita selecionar um nó servido do tipo SGSN (e não MSC/VRL). Além disso, se existirem tipos diferentes de SGSN (p.ex. 2G e 3G), o RNC necessita selecionar um SGSN apropriado, isto é, um 3G SGSN para um RNC.
Caso o RNC encontrar um nó servidor adequado, usará o endereço de nó servidor indicado na lista para estabelecer a conexão.
Se o RNC não encontra um nó adequado, poderia selecionar qualquer nó servidor do tipo apropriado para suportar esta área. Esta seleção pode ser feita aleatoriamente para distribuir a carga, baseado sobre nós servidores preferenciais (p.ex. localizados próximo ao RNC), ou baseado sobre informações conhecidas da respectiva carga de nós carregadores (p.ex. da operação e manutenção ou sistema DNS) para selecionar o nó servidor sob menor carga, ou uma combinação dos acima.
Se a CN Id não foi transmitida na sinalização, o RNC poderia selecionar o nó servidor de acordo com qualquer uma das seguintes concretizações: Em uma primeira concretização preferencial onde todas as MS são presumidas suportar a emissão de um identificador de CN (p.ex. um sistema GPRS o identificador de CNN está implicitamente codificado como parte do TLLI), o RNC poderia selecionar qualquer nó servidor do tipo apropriado suportando esta área. Esta seleção pode ser feita aleatoriamente para distribuir a carga baseado sobre nós servidores preferidos (p.ex. localizados próximos ao RNC), ou baseado sobre informações conhecidas da respectiva carga de nós carregadores (p.ex. dos procedimentos de operação e manutenção, ou sistema DNS) para selecionar o nó servidor sob menor carga ou uma combinação dos acima. Se algumas das informações acima são implicitamente indicadas pela ordem da lista (p.ex., nós servidores escalonados de menos carregados para mais carregados) o RNC 3 de preferência é adaptado para selecionar um SGSN indicado em um local especifico da lista.
Em uma segunda concretização preferencial onde algumas MS (tipicamente legadas) são presumidas não suportar a emissão de identificador de CN (p.ex. terminais móveis UMTS da primeira geração não emitirão identificador de CN como parte de sinalização RRC), o RNC tem de selecionar um nó servidor default para esta área. Isto é necessário para assegurar que da próxima vez uma conexão seja estabelecida do mesmo terminal móvel (ainda não indicado pelo seu identificador de CN), o mesmo nó é selecionado mais uma vez. Naturalmente quando o nó servidor default é único por área, um novo nó servidor pode ser selecionado quando a área muda (similar ao comportamento existente). Além disso quando o nó servidor muda, no sistema tal como GPRS, o novo nó servidor necessita encontrar o nó servidor antigo. O novo nó servidor necessitará também usar o nó servidor default processando a área antiga quando nenhum identificador de CN é emitido. Desta maneira o endereço do nó servidor antigo pode ser sempre recuperado claramente. O RNC 3 subsequentemente executa, de maneira conhecida, as etapas necessárias para estabelecer a conexão entre o MS 2 e o SGSN 4 selecionado.
Além disso, ou como uma alternativa, a lista de SGSNs transmitida em resposta 3.) pode conter informações adicionais tais como informações de carga a serem testadas pelo RNC 3 para determinar sobre o SGSN a ser selecionado. A conexão com o SGSN selecionado pode falhar, neste caso o RNC pode fazer nova tentativa com outro nó servidor do tipo apropriado em apoio desta área.
Se o SGSN selecionado (e a falha da conexão) foi o SGN default de acordo com a segunda concretização preferencial um novo SGSN pode ser selecionado como o default, tipicamente um default secundário. Neste caso, quando o nó servidor está mudando, o novo nó servidor tentará primeiramente conectar-se com o default (como previamente). Se o SGSN default está indisponível ou desconhecedor do usuário, o novo SGSN deve fazer nova tentativa usando o nó servidor default secundário que trata da área precedente quando nenhum identificador de CN é emitido. Desta maneira o endereço do nó servidor antigo pode sempre ser recuperado positivamente.
Quando um SGSN é programado para operação e procedimentos de manutenção de preferência será excluído da lista emitida de volta em resposta a 3.) um certo ou determinado intervalo de tempo tal como de várias horas antes do ponto de tempo de manutenção programado de modo a evitar conexões a serem novamente estabelecidas com este SGSN. Neste caso, o servidor DNS 7 será informado pelos sistemas de operação e manutenção sobre os SGSN (s) programados para operações de manutenção, e quer não irá mais selecionar tal SGSN da lista, quer excluirá o mesmo, ao ter recuperado os SGSN da memória, da transmissão para o RNC 3. Por conseguinte, quando o SGSN é desativado para procedimentos de operação e manutenção, o número de usuários registrados neste SGSN é mínimo. Estas conexões de usuário podem apenas ser perdidas, ou elas podem ser emitidas para um novo SGSN configurado para usar para esta área o mesmo identificador de CN que a SGSN sendo desativado.
As etapas 4.) a 6.) mostradas na fig. 2 para estabelecer a conexão entre MS 2 e SGSN 4 são as costumeiras e por conseguinte não explanadas em detalhe. A fig. 3 refere-se a um caso onde o MS 2 está pretendendo ser IO conectado com um determinado SGSN 6, p.ex. ao restabelecer uma conexão. Neste caso, o MS 2 transmite uma solicitação tal como uma mensagem RRC que inclui um identificador SGSN identificando o SGSN 6 desejado. Na solicitação 1.), a identidade da área de roteamento (RAI) ou identidade da área de posição (LAI) podem ser adicionalmente indicadas.
Como uma alternativa, o RNC 3 pode deduzir a área de roteamento (ou posição), e assim a identidade da área de roteamento (ou posição), de outros parâmetros. Similar à etapa 2.) da fig. 2, o RNC 3 solicita, em uma etapa 2.) da fig. 3, o servidor DNS 7 para emitir de retomo uma lista de SGSNs indicando a posição do local tal como RAI como um critério de seleção. O servidor DNS 7 recupera da lista de nó servidor tal como mostrada na fig. 5 uma sub-lista de endereços IP e identificadores de SGSNs correspondentes a, e sendo suscetíveis de servir, a área de local indicada. O servidor DNS 7 retoma está sub-lista ao RNC 3uma resposta na etapa 3.). O RNC 3 seleciona aquele SG SN (aqui: SGSN 6) da sub-lista recebida na etapa 3.) que corresponde ao identificador de SGSN indicado pelo MS 2 na etapa L), e executa as etapas de conexão conhecidas 4.) a 6.) para estabelecer a conexão entre MS 2 e a SGSN 6 desejada.
Como uma alternativa às etapas 2.) e 3.), o RNC 3 pode também emitir, na etapa 2.) adicionalmente, ou somente, o identificador SGSN recebido do MS 2, para o servidor DNS 7. O servidor DNS 7 é, neste caso, de preferência adaptado para usar o identificador de SGSN para seleção do SGSN apropriado da lista, e retomar, na etapa 3.) meramente o endereço IP do SGSN apropriado. O RNC 3 estabelecerá então, nas etapas 4.) a 6.), uma conexão utilizando este único endereço IP recebido do SGSN desejado. A fig. 4 mostra uma função alternativa ou adicional da mesma ou outra concretização do método e sistema de acordo com a invenção. Conforme a fig. 4, um dos SGSNs, aqui o SGSN 4, é ajustado como um SGSN nominal para uma área de roteamento específica. Similarmente à etapa 1.) das fgs. 2 e 3 a etapa 1.) da fig. 4 consiste em enviar uma mensagem tal como um pedido de conexão RRC, desde a MS 2 para RNC 3, indicando o identificador de área de roteamento RAI. O RNC 3 reconhece a partir da ausência de qualquer identificador SGSN solicitando uma conexão para um SGSN específico a possibilidade de selecionar o SGSN nominal para a área de roteamento indicada. O RNC 3. então inquire, na etapa 2.), uma base de dados 8 para retomar o endereço do SGSN nominal 4 e indica a identidade da área de roteamento na mensagem de inquirição. A base de dados S pode ser estruturada similarmente à tabela mostrada na fig. 5 e pode estar contida em, um ser acessível por um servidor DNS 7, ou um outro servidor. A base de dados 8 retoma, em resposta a 3.), o endereço do SGSN nominal, endereço este que é usado pelo RNC 3 da maneira costumeira para estabelecer uma conexão entre MS 2 o o SDSN nominal 4 como representado pelas etapas 4.) a 6.). A fig. 6 mostra as etapas de um procedimento de atualização de área de roteamento em uma implementação preferida da invenção, relacionada com UMTS. Algumas das nlOdificações desta concretização, como comparadas à especificações, são enfatizadas usados letras em negrito.
Uma atualização de área de roteamento tem lugar quando uma MS anexa detecta que ela lançou uma nova RA ou quando o temporizador de atualização de RA periódica expirou. O SGSN detecta que esta é uma atualização de área de roteamento intra SGSN notando que ele também processa a antiga RA. Neste caso, o SGSN tem a informação necessária a respeito da MS e não há necessidade de informar os GSSNs ou o HLR acerca da nova localização da MS. Uma atualização de RA periódica é sempre uma atualização de área de roteamento intra SGSN. Se a rede operar no modo 1, então uma MS que é ligada tanto ao GPRS quanto ao IMSI deve realizar os procedimentos combinados de atualização RA/LA.
No UMTS, uma atualização RA é uma atualização quer intra- IO SGSN quer inter-SGSN RA, quer atualização RA / LA combinada quer somente atualização RA, quer iniciada por um MS em estado PMM-CONECTADO quer em estado PMM-INATIVO. Todos os casos de atualização de RA são contidos no procedimento ilustrado na fig. 6.
As etapas mostradas na fig. 6 para realizar um Procedimento de Atualização de R.A UMTS serão descritas utilizando a numeração de etapas da fig. 6. 1) A conexão RRC é estabelecida, caso já não tenha sido realizada. O MS emite uma mensagem de Solicitação de Atualização de Area de Roteamento (P-TMSI, RAI antiga, Assinatura P-TMSI antiga, Tipo de Atualização, solicitação de acompanhamento, identificador de CN) para a nova SGSN usando na interface de rádio uma mensagem RRC (transferência direta inicial ou transferência direta de enlace ascendente) inclusive o identificador CN se armazenado no MS. O identificador de CN e o RAI antigo é usado pelo novo SGSN para determinar o SGSN antigo. A solicitação de acompanhamento será estabelecida pelo MS se houver tráfego de enlace ascendente pendente (dados de sinalização ou de usuário). A SGSN pode usar, como uma opção de implementação, a indicação de solicitação de acompanhamento para liberar ou manter a conexão Iu após a conclusão do procedimento de atualização de RA. O Tipo de Atualização deverá indicar: Atualização de R..A. se a Atualização de RA é acionada por mudança de RA;
Atualização de RA periódica se a atualização de RA é acionada pela temporização vencida de temporização de Atualização de RA Periódica;
Atualização Combinada de RA I LA se o IMSI é também IMSI afixado e a atualização de LA deve ser realizada no modo I de operação de rede (ver subcláusula "Interações Entre SGSN e MSCNLR"); ou - Atualização Combinada de RA / LA com afixação de IMSI solicitada se o MS deseja realizar uma afixação de IMSI no modo de operação de rede 1. O SNRC deve emitir a solicitação para o SGSN correspondente ao identificador de CN emitido pelo MS de acordo com uma lista pré-configurada no RNC. Se nenhum Identificador de CN foi transmitido, os SGNSS default para esta área devem ser selecionados (de maneira a suportar o MS legado).
Obs.: Se este RNC não está conectado com o SGSN prévio, um novo SGNS deve ser selecionado. O SGSN tendo nesta área o mesmo Identificador de CN que o antigo será selecionado, ou caso inexistente, outro. O SRNC deve adicionar a Identidade de Área de Roteamento inclusive o RAC e LAC da área onde o MS está localizado antes de encaminhar a mensagem para o 3G-SGSN. Esta Identidade RA corresponde à RAI nas informações de sistema MM transmitidas pelo SRNC para o MS.
Obs.: A transmissão da mensagem de Solicitação de Atualização de Area de Roteamento para o SGSN aciona o estabelecimento de uma conexão de sinalização entre UTRAN e SGSN para o 1\1S envolvido.
2) Se a atualização de RA é uma atualização de área de Roteamento Inter-SGSN e se o MS se encontrava no estado PMM-INATIVO, o novo SGSN transmite a mensagem Solicitação Contexto SGSN (P-TMSI antigo, RAI antigo, Assinatura P-TMSI antiga) para o SGSN antigo para obter os contextos MM e PDP para o MS. O SGSN antigo valida a Assinatura P-TMSI antiga e responde com uma causa de erro apropriada se não casar com o valor armazenado no SGSN antigo. Isto deve iniciar as funções de segurança no novo SGSN. Se as funções de segurança autenticarem o MS corretamente, o novo SGNS deve emitir uma mensagem Solicitação Contexto SGSN (IMSI, RAI antiga, MS validados) para o SGSN antigo. MS Validado indica que o novo SGSN autenticou o MS. Se a Assinatura P-TMSI antiga foi válida ou se o novo SGSN indicar que autenticou o MS, o S G SN antigo responde com a Resposta Contexto SGSN (Causa, IM SI, Contexto MM, contextos PDP). Se o M S não é conhecido no SGSN antigo, o SGSN antigo responde com uma causa de erro apropriada. O SGSN antigo ativa um temporizador. 3) Funções de segurança podem ser executadas. Estes procedimentos são definidos na subcláusula "Função de Segurança". Se as funções de segurança não autenticarenl o MS corretamente, então a atualização de área de roteamento deve ser rejeitada, e o novo SGSN deve emitir uma indicação de rejeição para o SGSN antigo. O SGSN antigo deve continuar como se a Solicitação de Contexto SGSN nunca foi recebida. 4) Se a atuação de RA é unia atuação de Área de Roteamento Inter-SGSN, o novo SGSN transmite uma mensagem Confirmar Contexto SGSN para o SGSN antigo. O SGSN antigo marca no seu contexto que a associação MSC/VLR e a informação no GGSNs e o HLR são inválidas. Isto aciona o MSC/VLR, os GGSNs, e o HLR para serem atualizados se o MS inicia um procedimento de atualização de área de roteamento de retomo ao antigo SGSN antes de completar o procedimento de atualização de área de roteamento em andamento. 5) Se a atualização de RA é uma Atualização Inter-SGSN e se o MS se encontrava no estado PMM-INATNO, o novo SGSN emite uma Solicitação de Atualização de Contexto PDP (novo Endereço SGSN QoS Negociado, Identificador de Ponto Final de Túnel) para os GGSNs envolvidos.
Os GGSNs atualizam seus campos de contexto PDP e retomam uma Resposta Contexto PDP Atualizado (Identificador Ponto Final de Túnel). Obs.: Se a atuação de RA é unia atualização de área de roteamento Inter-SGSN iniciada por um MS no estado PMM-CONECTADO, então a mensagem de Solicitação de Contexto PDP Atualizado é transmitida conforme descrito na subcláusula de especificação "Serving RNS RelocationlO Procedures". 6) Se a atualização de RA é uma Atualização de RA lnter- SGSN, o novo SGSN infomla o HLR da mudança de SGSN emitindo Atualização de Local (Número SGSN, Endereço SGSN, IMSI) para o HLR. 7) Se a atuação de RA é unia Atualização de RA lnter-SGSN, o HLR emite Cancelar Local (IMSI, Tipo de Cancelamento) para o SGSN antigo com o Tipo de Cancelamento estabelecido parta Procedimento de Atualização. Se o temporizador descrito na etapa 2 não está em operação, então o SGSN antigo remove o contexto MM. Caso contrário, os contextos são removidos somente quando o temporizador expira. Tambénl assegura que o contexto MM seja mantido no SGSN antigo no caso do MS iniciar outra atualização de área de roteamento SGSN antes de completar a atuação de área de roteamento em andamento para o novo SGSN. O SGSN antigo confirma c.onlConf. Cancelar Local (IMSI). 8) Se a atualização de RA é uma Atualização de RA Inter-SGSN o HLR emite Inserir Dados de Assinante (IMSI dados de assinatura) para o novo SGSN. O novo SGSN valida a presença de MS no (novo ) RA. Se devido à restrições de assinatura regional o MS não é permitido a ser afixado no RA. o SGSN rejeita a Solicitação de Atualização de Área de Roteamento com uma causa apropriada, e pode retomar uma mensagem Conf. Inserir Dados de Assinante (IMSI, Área Restrita SGSN) para o HLR. Se todos os testes são proveitosos então o SGSN constrói um contexto MM para o MS e retoma uma mensagem Conf. Inserir Dados de Assinante (IMSI) para o HLR. 9) Se a atualização de RA é uma Atualização de RA lnter-SGSN, o HLR confirma a Atualização de Local emitindo Conf. Atualização Local (IMSI) para o novo SGSN. 10) Se o Tipo de Atualização indicar atualização de RAILA combinada com afixação de IMSI solicitada, ou se a LA mudou com a atualização de área de roteamento, então a associação tem de ser estabelecida, e o novo SGSN emite uma Solicitação Atualizar Local (novo LAI, IMSI, Número SGSN, Tipo de Atualização Local) para o VLR. O Tipo de Atualizar Local deve indicar afixar IMSI se o Tipo de Atualização na etapa 1 indicado combinou atualização de RA/LA com afixação de ISI solicitada. Caso contrário, o Tipo de Atualizar Local deve indicar atualização de local normal. O número VLR é traduzido da RAI via uma tabela no SGSN. O SGSN inicia o procedimento de atualização de local no sentido do novo MSC/VLR mediante a recepção da primeira mensagem Inserir Dados de Assinante do HLR na etapa 8). O VLR cria ou atualiza associação com o SGSN armazenando o Número de SGSN. 11) Se os dados de assinante no VLR são marcados como não confirmados pelo HLR, o novo VLR informa o HLR. O HLR cancela o VLR antigo e insere dados de assinante no novo VLR (esta sinalização não é modificada em relação à sinalização GSM existente e é aqui incluída para fins ilustrativos): a) O novo VLR emite um Atualizar Local (novo VLR) para o HLR. b) o HLR cancela os dados no VLR antigo transmitindo Cancelar Local (IMSI) para o VLR antigo. c) O VLR antigo confirma com Conf. Cancelamento Local. d) O HLR emite Inserir Dados de Assinante (IMSI, dados de assinante GSM ) para o novo VLR. e) O novo VLR confirma com Conf. Inserção Dados Assinante (IMSI) f) O HLR responde com Conf. Atualização Local (IMSI) para o novo VLR. 12) O novo VLR aloca um novo TMSI e responde Atualização Local Aceita (VLR RMSI) para o SGSN. VLR TMSI é opcional caso o VLR não tenha se alterado. 13) O novo SGSN valida a presença do MS no novo RA. Se devido à restrições de deslocamento o MS não é permitido a ser afixado na SGSN, ou se o teste de assinatura falha, então o SGSN rejeita a atualização de área de roteamento com uma causa apropriada. Se todos os testes são proveitosos então o novo SGSN estabelece contexto MM para o MS. O novo SGSN responde ao MS com Atualização de Área de Roteamento Aceita (P- TMSI, VLR TMSI. Assinatura P-TMSI, novo Identificador de CN). 14) O MS confirma a realocação dos TMSI retomando uma mensagem Atualização de Área de Roteamento Completa para o SGSN. 15) O novo SGSN emite uma mensagem Realocação TMSI Completa para o novo VLR se o VLR RMSI é confirmado pelo MS.
Observação: As etapas 11, 12 e 15 são realizadas somente se a etapa 9 é executada.
Observação: O presente caso presume inalteração na interface Gs, e corresponde ao caso onde um LA e ainda tratado por um único MSCNLR. Assim SGSN deriva o endereço MSC/VLR do LAI (solução corrente).
No caso onde muitos MSC/VLRs processariam o mesmo LA, e a interface Gs é usada, a solução apresentada acima deve ser aperfeiçoada adicionando o Identificador de CN (eventualmente associado com um CS indicando tipo CN) à mensagem 13 (Atualização de Área de Roteamento Aceita). Além disso o identificador de CN deve ser adicionado na interface Gs à mensagenlO (Solicitação de Atualização de Local) e à mensagem 12 (Atualização de Local Aceita). Isto presume que o SGSN é capaz de derivar endereço MSC de LAI e Identificador de CN, ou pelo menos de somente LAI (enquanto um SGSN sempre selecionar o mesmo endereço MSC para o mesmo LA, nenhuma atualização de local inter MSC/VLR desnecessária é efetuada se o SGSN não se altera).
Outro exemplo de um procedimento onde o processo para selecionar nó servidor baseado sobre Identificador de CN pode ser usado, é um Procedinlento Atualização de Célula / URA Combinado e Re-localização de SRNS.
Este procedimento é somente executado para um MS no estado PMM-CONECTADO, onde o Iur conduz sinalização de controle porém sem dados de usuário. O procedimento de Atualização Combinada de Célula / URA e Re-localização de SRNS é usado para mover o ponto de conexão de UTRAN com CN no lado UTRA da fonte SRNC para o RNC alvo, enquanto realizando uma resseleção de célula no UTRAN. No procedimento, os enlaces Iu são re-localizados. Se o RNC alvo está conectado com o mesmo SGSN que a fonte SRNC, um procedimento de Re-Localização Intra SGSN SRNS é executado. Se a área de roteamento é alterada, então este procedimento é sucedido por um procedimento de Atualização de Área de Roteamento Intra SGSN. O SGSN detecta que se trata de uma atualização de roteamento intra-SGSN observando que também processa o RA antigo. Neste caso, o SGSN tem as informações necessárias acerca do MS e não há necessidade de informar o HLR acerca do novo local de MS.
Antes da Atualização Combinada de Célula / URA e Re-Localização de SRNS e da Atualização de Área de Roteamento o MS é registrado no SGSN antigo. A fonte RNC está atuando como RNC servidor.
Após a Atualização Combinada de Célula / URA e Re-Localização de SRNS e Atualização da Área de Roteamento, o MS é registrado no novo SGSN. O 1\1S está no estado PMM-CONECTADO no sentido do novo SGSN, e o RNC alvo está atuando como RNC servidor. O procedimento de Atualização Combinada de Célula / URA e Re-Localização de SRNS para o domínio OS é ilustrado na fig. 7. A sequência é válida tanto para re-localização intra-SGSN SRNS como para re- localização inter-SGSN SRNS. As etapas serão descritas reportando-se à numeração mostrada na figura 7. 1) O MS transmite uma mensagem Atualizar Célula/Atualizar URA para o UTRAN após ter efetuado a resseleção de célula. Mediante a recepção da mensagem, o RNC alvo encaminha a mensagem recebida no sentido do SRNC fonte via Iur. A fonte SRNC decide efetuar uma atuação combinada de célula/URA e relocação de SRNS no sentido do RNC alvo. 2) A fonte SRNC inicia o procedimento de preparação de relocação emitindo uma mensagem Relocação Requerida (Tipo de Relocação, Causa, ID Fonte, ID Alvo, RNC Fonte para o Recipiente Transparente RNC Alvo) para o SGSN antigo. A fonte SRNC deve estabelecer Tipo de Relocação para '"UE não envolvido". A fonte RNC para Recipiente Transparente de RNC Alvo inclui as informações necessárias para coordenação de Relocação, funcionalidade de segurança, e informações de contexto de protocolo (inclusive Faculdades de UE). 3) O SGSN antigo determina a partir de ID Alvo se a Relocação de SRNS é relocação intra SGSN SRNS ou relocação inter SGSN SRNS. No caso de relocação inter SGSN SRNS o SGSN antigo inicia o procedimento de alocação de recurso de relocação emitindo uma mensagem Encaminhar Solicitação de Relocação (IMSI, Sinalização Identificadora Ponto Final Túnel, Contexto MM, Contexto PDP, Identificação Alvo, Recipiente Transparente UTRAN, Causa RANAP) para a nova SGSN. O endereço da nova SGSN é derivado da ID alvo e o identificador de CN que foi previamente transmitido para o MS. Ao mesmo tempo um temporizador é iniciado sobre os contextos MM e PDP na SGSN antiga, ver procedimento de Atualização de Área de Roteamento na sub-cláusula "Procedimentos de Gerenciamento de Locação (UMTS Somente)". A mensagem Encaminhar Solicitação de Re locação é aplicável somente no caso de relocação inter SGSN SRNS. 4) A nova SGSN emite uma mensagem Solicitação de Relocação (Identidade NAS UE Permanente, Causa, Indicador Domínio CN, Fonte RNC para Recipiente Transparente RNC Alvo, RABs a ser estabelecida) para o RNC alvo. Para cada RAB solicitada a ser estabelecida, RABs A Ser Estabelecida deve conter informações tais como ID RAB, parâmetros de RAB, Endereço da Camada de Transporte, e Associação Transporte Iu. O elemento de informação ID RAB contém o valor NSAPI, e o elemento de informação parâmetros de RAB contém o valor NSAPI, e o elemento de informação parâmetros de RAB dá o perfil QoS. O Endereço de Camada de Transporte é o Endereço SGSN para dados de usuário, e a Associação de Transporte Iu corresponde aos Dados Identificador de Ponto Final de Túnel.
Após todos os recursos necessários para RABs aceitas inclusive o plano de usuário Iu serem proveitosamente alocados, o RNC alvo deve emitir a mensagem de Confirmação de Solicitação de Relocação (RABs estabelecidos, R.ABs não estabelecidos por falha) para a nova SGSN. O RNC Alvo para cada RAB a ser estabelecido (definido por um Endereço IP e um Identificador de Ponto Final de Túnel) recebe tanto PDUs a jusante encaminhados pela SRNC fonte como PDUs a jusante provenientes da nova SGSN. 5) Quando recursos para a transmissão de dados de usuário entre o RNC alvo e a nova SGSN tiverem sido alocados e a nova SGSN está pronta para relocação de SRNS, a mensagem Encaminhar Resposta de Relocação (Causa, Causa RANAP, e Informações de RNC Alvo) é transmitida pela nova SGSN para a SGSN antiga. Esta mensagem indica que a nova SGSN e o RNC alvo estão prontos para receber da SRNC fonte os pacotes a jusante ainda não confirmados pela MS, isto é, o procedimento de alocação de recurso de relocação é terminado proveitosamente. Causa RANAP é a informação do RNC alvo a ser encaminhada para o RNC fonte. A informação de RNC Alvo, um elemento de informação para cada RAB a ser estabelecida, contém o Identificador de Ponto Final de Túnel RNC e endereço RNC IP para encaminhamento de dados da SRNC fonte para a RNC alvo. A mensagem Encaminhar Resposta de Relocação é aplicável somente no caso de relocação inter SGSN SRNS. 6) A SGSN antiga continua a relocação de SRNS emitindo uma mensagem Comando de Relocação (RABs a serem liberadas, e RABs sujeitas a encaminhamento de dados ) para a SRNC fonte. A SSGSN antiga decide os RABs sujeitos a encaminhamento de dados baseado sobre QoS, e aqueles RABs devem ser contidos nos RABs sujeitos a encaminhamento de dados. Para cada RAB sujeito a encaminhamento de dados, o elemento de informação deve conter RAB ID, Endereço Camada de Transporte, e Associação Transporte Iu. O Endereço Camada de Transporte e Associação Transporte Iu é usado para encaminhar de DL N-PDU do RNC fonte para o RNC alvo. 7) Com a recepção da mensagem Comando de Relocação do domínio OS, o RNC fonte deve ativar o temporizador de encaminhamento de dados. Quando o procedimento de preparação de relocação é terminado proveitosamente e quando o SRNC fonte está pronto, o SRNC fonte deve ativar a execução de relocação de SRNS transmitindo uma mensagem Restabelecer Relocação (Contextos SRNSJ para o RNC alvo. A finalidade deste procedimento é transferir contextos de SRNS do RNC fonte para o RNC alvo. Contextos de SRNS são transmitidos para cada RAB envolvido e contém os números de sequência do GTP-PDUs imediatos a serem transmitidos nas direções de enlace ascendente e de enlace descendente e os números de sequência PDCP seguintes que teriam sido usados para transmitir e receber dados do MS. Para conexões utilizando o modo RLC não confirmado, os números de sequência PDCP não são usados. 8) Após ter transmitido a mensagem Restabelece Relocação, o SRNC fonte inicia o encaminhamento de dados para os RABs sujeitos a encaminhamento de dados. O encaminhamento de dados na relocação SRNS deve ser executado através da interface Iu, significando os dados trocados entre SRNC fonte e o RNC alvo são suplicados no SRNC fonte e roteados na camada IP no sentido do RNC alvo. 9) O RNC alvo deve transmitir uma mensagem Detectar Relocação para o novo SGSN quando o disparo de execução de relocação é recebido. Para o tipo de relocação SRNS "UE não envolvido", o disparo de execução de relocação é a recepção da mensagem Restabelecer Relocação da interface Iur. Quando a mensagem Detectar Relocação é transmitida, o RNC alvo deve iniciar a operação de SRNC. 10) Após ter transmitido a mensagem Detectar Relocação, o SRNC alvo responde ao MS emitindo uma mensagem Atualização Célula Confirmada/ Atualização URA Confirmada. Ambas as mensagens contém elementos de informação UE e elementos de informação CN. Os elementos de informação UE incluem entre outros nova identidade de SRNC e S-RNTI.
Os elementos de informação CN contém entre outros Identificação de Área de Locação e Identificação de Área de Roteamento. O procedimento deve ser coordenado em todas as conexões de sinalização Iu existentes para o MS. 11) Com a recepção da mensagem Detectar Relocação, CN pode comutar o plano de usuário do RNC fonte para o SRNC alvo. Se a Relocação SRNS é uma relocação inter SGSN SRNS, o novo SGSN emite mensagens Solicitar Atualização Contexto PDP (Endereço novo SGSN, Identificador Ponto Final Túnel SGSN, QoS Negociado) para os GGSNs envolvidos. Os GGSNs atualizam seus campos de contexto PDP e retomam uma mensagem Resposta Contexto PDP Atualizado (Identificador Ponto Final Túnel GGSN). 12) Quando o MS tiver efetuado sua própria reconfiguração, ele emite a mensagem Realocação RNTI Completada para o SRNC alvo. 13) Quando o SRNC alvo recebe a mensagem Realocação RNTI Completa, isto é, a nova SRNC-ID + S-RNTI são proveitosamente intercambiadas com a UE pelos protocolos de rádio, o SRNC alvo deve iniciar o procedimento de Relocação Completa emitindo a mensagem Relocação Completa para o novo SGSN. A finalidade do procedimento Relocação Completa é indicar pelo SRNC alvo a conclusão de relocação SRNS para a CN.Caso o plano de usuário não tiver sido comutado no Detectar Relocação, a CN deve mediante a recepção da mensagem Relocação Completa comutar o plano de usuário do RNC fonte para o SRNC alvo. Caso a Relocação de SRNC é uma relocação inter SGSN SRNS, a nova SGSN sinaliza para o SGSN antigo a conclusão do procedimento de relocação SRNS emitindo uma mensagem Encaminhar Relocação Completa. 14) Ao receber a mensagem Relocação Completa ou se é um Relocação inter SGSN SRNS; a mensagem Encaminha Relocação Completa, o SGSN antigo transmite uma mensagem de Comando Liberar Iu para o RNC fonte. Quando o temporizador de encaminhamento de dados RNC tiver expirado o RNC fonte responde com uma Liberação Iu Completa. 15) Após o MS ter completado o procedimento de atualização de Célula /URA e realocação de RNTI e se a nova Identificação de Área de ✓ Roteamento é diferente da antiga, o MS inicia o procedimento Atualizar Area de Roteamento. Ver sub-cláusula "Procedimentos de Gerenciamento de Locação (UMTS Somente)”. Observe-se que se é somente um subconjunto do procedimento de atualização de RA que é realizado, uma vez que o MS está no estado PMM-CONECTADO.
Observe-se que quando o procedimento RAU é realizado, o MS indica o mesmo identificador CN conforme usado pelo SGSN antigo para encontrar o novo SGSN, de forma que o SGSN que é selecionado pelo novo SRNC, é o mesmo daquele que já foi selecionado pelo SGSN antigo.
Uma solução alternativa seria a de que o SGSN antigo selecionar qualquer um dos SGSN suscetível de conectar-se com o RNC alvo baseado sobre a ID alvo. A seguir o novo SGSN transmite o seu identificador CN para o MS, p.ex. adicionando o CN identificador na mensagem 4 (Solicitação de Relocação) e IO (mensagem Confirmar Atualização Célula / Confirmar Atualização URA). Então o MS usa a CN Id para a seleção atualizada do SGSN correto.
Em uma implementação preferencial, a codificação do identificador CN é otimizada para permitir que suficientes nós servidores tratem da mesma área, porém não para aumentar demasiadamente a sinalização de rádio. A codificação de preferência por conseguinte é utilizar 4 bits, proporcionando 16 nós servidores porém não demasiadas atividades de suporte.
Também para simplificar a implementação, um código dado (p.ex. 0000) deve indicar o nó servidor default para todas as áreas. E outro código (p.ex. 0001) deve indicar o nó servidor default secundário. Esta implementação reduziría a necessidade de configurar um parâmetro adicional como default. Além disso, quando um nó (p.ex. RNC) seleciona o default, ele pode ser implementado p.ex. usando o valor default conhecido de identificador CN (p.ex. 0000) para consultar a lista e recuperar o endereço de nó servidor (default).
Com relação à interface Gs e uma simultânea afixação OS/CS, se uma associação entre o SGSN e o MSC é criada (p.ex. o UE (equipamento de usuário) realiza uma afixação OS I CS combinada) o SGSN é provido de ou tem acesso a, uma tabela de tradução para derivar o endereço MSC da RAI. Alterações são necessárias para a tabela de tradução se múltiplos MSCs podem controlar a mesma área de locação. Um identificador adicional, o Identificador de MS, pode ser provido para encontrar um MSC específico controlando uma área de locação. A figura 8 ilustra um fluxo de mensagem em um sistema e processo de acordo com uma concretização adicional da invenção. Esta IO concretização refere-se a um MVNO (Operador de Rede Virtual Móvel) tendo pelo menos um elemento de rede de núcleo própria (CN) 6, IO, 11 tal como um MSC/VLR (Centro de Comutação Móvel/Registro de Locação de Visitante) e/ou SGSN 6.
Apresente concretização de preferência tem como alvo porém não exclusivamente, GPRS, e sistemas UMTS futuros especialmente em um caso onde múltiplos elementos CN tal como SGSN/MSC podem ser conectados com o mesmo RNC. Nesta concretização os diferentes elementos CN podem pertencer a diferentes operadores. O MS 2 pode de preferência armazenar os CN Ids (Identificadores) sobre o SIM inserido ou inserível no MS 2.
As concretizações das figs. 8 e 9 incluem a característica de usar a ID de um operador para selecionar um nó CN pertencente ao operador MVNO correto ao conectar-se com a rede. Dois processos são apresentados: (I) A ID de Operador é objeto de difusão para o MS 2 e o MS 2 efetua a decisão; (2) A ID de Operador é transmitida do MS 2 para RNC 3 e RNC 3 seleciona a ID de CN. A concretização de acordo com a fig. 8 é dirigida para o primeiro processo ao passo que a concretização da fig. 9 implementa o segundo processo. Com ambos os processos, um operador MVNO pode ter mais de um nó tal como SGSN cobrindo a mesma área. O primeiro processo mostrado na fig. 8 inclui a etapa 1. de efetuar a difusão das informações para o MS 2 indicando o mapeamento entre um determinado operador de MVNO e a ID de CN usada nesta área. O MS 2 então realiza uma seleção etapa 2 para selecionar seu operador favorito (isto é, MVNO) de acordo com os critérios de seleção internos armazenados. A correspondente ID de CN (como recebida na etapa 1. ou como armazenada dentro de MS 2) do operador selecionado é inserida como parte da mensagem de solicitação de conectar RRC 3. transmitida para RNC 3. Como descrito acima com relação às concretizações precedentes, o RNC 3 então estabelecerá a conexão com o correspondente elemento CN 6, 10, ou 11 identificado pela Id de CN transmitida, como indicado pelas etapas 4. a 6.
De preferência, a Id de CN do MSC/VLR e SGSN do mesmo operador é a mesma para limitar a quantidade de informações objeto de difusão.
Além disso, a disponibilidade de SGSN e/ou MSC/VLR para este MVNO pode ser indicada na mensagem de difusão da etapa 1.
Em uma implementação desta concretização, somente parte da ID de CN é difundida na etapa 1. (p.ex. 2 primeiros bits)ao passo que os demais bits necessários, p.ex. os dois últimos bits são selecionados arbitrariamente pelo M S 2. Isto permite que o MNVO tenha múltiplos elementos CN por RAN.
As informações objeto de difusão podem por exemplo ser: CN Id 11 <-► 03343 (mnc033 mcc43) CN Id 03340 (mnc033 mcc40) 25 CN Id 03345 (mnc033 mcc45) (mnc, Código Rede Móvel; mcc, Código País Móvel) Caso o MS 2 não tenha preferência (ou não suporte a característica), ele não transmite a Id CN na etapa 3 e é então de preferência conectado com um elemento CN default.
Em uma concretização preferencial, operadores globais têm uma ID de operador global. Uma maneira prática é alocar as Ids de operador global a partir da gama de um código de país não usado p.ex.: 99901 - Orange 99902 -Vodafone 99903 - Virgin Observe-se que o mesmo ensinamento é aplicável a GPRS, onde a Id de CN é transmitida para BSC de preferência como parte de TLLI Aleatório (nenhuma mudança para protocolos de rádio necessária).
Uma implementação alternativa é evitar a rádio difusão de qualquer parâmetro, porém permitir que o MS 2 transmita na primeira mensagem RCC (conjuntamente ou em vez de Id CN) o identificador do operador. Esta alternativa é implementada na concretização de acordo com a fig. 9. O identificador de operador de preferência é mnc/mcc (mais fácil pois está no SIM) porém também pode ser a ID de um operador global (ver acima) ou outro tipo de identificador. A fig. 9 mostra um fluxo de mensagem em um sistema e processo de acordo com esta concretização da invenção. Esta concretização relaciona-se igualmente com um MVNO (Operador de Rede Virtual Móvel) tendo pelo menos um elemento de rede de núcleo próprio 6, 10, 11 tal como um MSC/VLR (Centro de Comutação Móvel/Registro de Locação de Visitante) e/ou SGSN 6.
Uma implementação preferencial desta alternativa é que um MS 2 não tendo armazenado uma Id de CN, adiciona o identificador de seu operador na mensagem de solicitação de Conexão 1. quando o MS 2 realiza a primeira conexão RRC. O RNC 3 tem meios (p.ex. acesso a uma base de dados configurável) para testar se uma das Ids de CN disponíveis corresponde ao identificador de operador. Este teste ou seleção é representado pela etapa 2. Se uma das Ids de CN disponíveis corresponde ao identificador de operador transmitido pelo MS 2, esta Id de CN é selecionada e a conexão é estabelecida com o nó CN 6,10, ou 11 correspondente à Id CN selecionada. O nó CN indicará em sinalização MM o identificador de CN selecionado (CN Id ) para o MS 2. A conexão é estabelecida de uma maneira conhecida de acordo com as etapas 3. a 5. da fig. 9.
Em uma implementação alternativa, o MVNO utiliza o mesmo identificador de CN através do PLMN central completo (isto é, MVNO utiliza o mesmo identificador de CN através das diferentes LÃS (ou RAs)). Isto significa que quando o MS se transfere de um área CN para outra, o mesmo identificador de CN corresponde a um nó do mesmo MVNO na nova área de CN. Observe-se que uma área CN é a inteira área alcançável a partir de um nó CN, e é composta de uma ou muitas Área de Locação LA (ou Área de Roteamento RA). Em uma pequena rede pode cobrir o país inteiro. Também uma pequena MVNO pode ter um nó CN para o inteiro pais, ao passo que outro MVNO pode ter muitos nós CN.
Neste caso, o MS irá em subsequentes mensagens de estabelecimento de conexão RRC transmitir somente a Id de CN e não o identificador de operador, enquanto permanecer na mesma PLMN.
Se o MS efetuar uma resseleção de PLMN, então de preferência transmite tanto a Id de CN como o identificador de operador na mensagem de estabelecimento de primeira conexão RRC. O novo RNC então usa o identificador de operador para selecionar a nova Id de CN. A Id de CN pode ser usada baseada sobre a configuração e é útil no caso onde uma MVNO tem um acordo com uma operadora transnacional (o mesmo nó de CN pode cobrir mais de um país/PLMN).
Em outro caso, o MVNO pode usar diferente identificador de CN através das diferentes Las(ou RAs) (porém dentro de uma LA (ou RA)) o identificador de CN é único). Isto significa que quando o MS se transfere de uma LA (ou RA) para outra, um CN diferente pode ser usado pelo mesmo MVNO na nova LA (ou RA).
Neste caso, o MS em subsequentes mensagens de estabelecimento de conexão RRC irá transmitir somente a ID de CN e não identificador de operador, enquanto permanecer na mesma LA (ou RA).
Se o MS mudar de LA (o RA), então de preferência transmite tanto a Id de CN como o identificador de operador na mensagem de primeiro estabelecimento de conexão RRC. O novo RNC pode então usar o identificador de operador para selecionar a nova Id de CN. Aqui mais uma vez, a ID de CN pode ser usada baseada sobre a configuração e é útil em um caso onde a MVNO tem um acordo com uma operadora transnacional (o mesmo nó CN pode cobrir mais de um país/PLMN, e/ou o MVNO pode ter dois ou mais nós CN por área.
Observe-se que o mesmo princípio pode ser aplicado com GPRS rádio, porém requer modificar a solicitação de TBF (Fluxo em Bloco Temporário), pois é improvável que o identificador de operador caiba no espaço de codificação TLLI.
Quando o MVNO tem mais de um nó por área, a seguinte implementação tem preferência: O RNC incluirá, ou terá acesso a, uma lista de Ids de CN correspondente a um identificador de operador. Se somente o identificador de operador é transmitido para o RNC 3 pelo MSS 2, o RNC 3 pode selecionar qualquer um destes nós (p.ex. baseado sobre disponibilidade, proximidade, carga compartilhada ...). Se o identificador de operador e a Id de CN é transmitida pelo MS 2 então o RNC 3 de preferência seleciona a mesma Id de CN se faz parte da lista. - Se a ID de um operador não pertencente à lista é transmitida, uma Id de CN default e selecionada.
Id de Operador:—»Id CN 99901 (= Orange) —>1; 2; 3 (em ordem de preferência) 99902 (= Vodafone) —>11; 12; 13; 14 (Usar Rodízio) 99903 (= Virgin) —>7; 8 (em ordem de preferência) Default (central pode ser Voda) —>11; 12; 13; 14 (Usar Rodízio) A invenção de acordo com as concretizações das figs. 8, 9 supera o problema de modificar o cartão SIM. Muitos operadores preferem manter o mesmo cartão SIM para evitar o custo de trocar o cartão SIM antigo.
Além disso, a difusão de informações através do raio ou emissão de Id de Operador (p.ex. lida sobre SIM) pelo MS 2 é mais flexível.
Diferentes Ids de CN podem ser usadas em diferentes regiões. Por exemplo se Orange é MVNO em toda a Europa, o SIM não necessita saber qual Id de CN é usada em que país. A invenção de acordo com as figs. Sm, 9 cobre o campo de MNVO. Tira vantagem da característica de múltiplas CNs por rede de rádio oferece uma solução para a mesma.
Embora concretizações preferenciais tenham sido descritas acima, a invenção não está limitada às mesmas e também pode ser implementada em redes de diferentes tipos usando nós servidores de diferente estrutura tal como MSC/VLR.
Também as reivindicações devem ser tomadas no seu sentido amplo, de forma que a ID alvo que identifica um elemento tratando de uma área, pode na realidade ser considerado como o identificador de uma área, isto é, a área tratada por este elemento.