BR112020002580A2

BR112020002580A2 - dipositivo sem fio e entidade ou função de rede núcleo para prover controle de gap de serviço e métodos de operação relacionados

Info

Publication number: BR112020002580A2
Application number: BR112020002580-1A
Authority: BR
Inventors: Hans Bertil Rönneke; Mikael Wass
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-08-10
Filing date: 2018-06-20
Publication date: 2020-07-28
Also published as: EP4117342A1; US20220256440A1; US11405854B2; KR20200033325A; CN110999522A; KR20210109047A; ES2927540T3; RU2749750C1; KR102294686B1; EP3485696A1; EP3485696B1; RU2021116467A; CN110999522B; US20210136658A1; WO2019029883A1; PL3485696T3

Abstract

No presente documento é revelado um método de operação de um dispositivo sem fio (12) para prover controle de gap de serviço em um sistema de comunicação sem fio (10), compreendendo: receber 100 no dispositivo sem fio (12) um parâmetro de gap de serviço a partir de uma entidade de rede em uma mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade, o parâmetro de gap de serviço sendo indicativo de um valor para um temporizador de gap de serviço para o dispositivo sem fio (12); e impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) em uma camada de estrado de não acesso. Também é aqui revelado um método de operação de uma entidade de rede núcleo em uma rede núcleo de um sistema de comunicação sem fio (10) para prover controle de gap de serviço, compreendendo: obter (200) pela entidade de rede núcleo, um parâmetro de gap de serviço para um dispositivo sem fio (12), o parâmetro de gap de serviço sendo indicativo de um valor para um temporizador de gap de serviço para o dispositivo sem fio (12); e enviar (202) pela entidade de rede núcleo, o parâmetro de gap de serviço para o dispositivo sem fio (12) via uma mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade.

Description

CONTROLE DE GAP DE SERVIÇO PARA UM DISPOSITIVO SEM FIO CAMPO DA TÉCNICA

[001] As modalidades aqui apresentadas referem-se a métodos, dispositivos de comunicação sem fio, programas de computador e um produto de programa de computador para prover um controle de gap de serviço referente a um dispositivo sem fio em um sistema de comunicação sem fio.

ANTECEDENTES

[002] O gap de serviço tem sido discutido há um certo tempo (vide Ericsson et al., “S2-171904: Update of APN rate control to support small data allowance plans,” SA WG2 Reunião #120, 27-31 de Março de 2017, Busan, Coreia do Sul; , Nokia et al., “S2-174300: Update of back-off timer to support Service Gap for small data,” SA WG2 Reunião #122, 26-30 de junho de 2017, San José del Cabo, México; e Ericsson et al., “S2-174731: Proposed TEI15 discussion on support for small data allowance plans,” TSG SA WG2 Reunião #122, 26-30 de junho de 2017, San José del Cabo, México.

[003] A intenção é colocar um limite na frequência com que os recursos de rede são usados para um Dispositivo de Equipamento de Usuário (UE) ou, mais especificamente, a frequência das solicitações de conexão de dados originados de terminais móveis (MO), tais como, por exemplo dados do Plano do Usuário (UP) MO, Dados de plano de Controle (CP) MO (Dados sobre Estrado de Não Acesso (NAS) (“DoNAS”)) e Serviço de Mensagem Curta (SMS) MO. Isso significa que a carga de um grande número de dispositivos CIoT podem ser nivelados e que a contribuição para a carga de pico de rede de tais dispositivos CIoT pode ser reduzida. Isto é, os recursos de rede são usados de um modo mais ideal. O gap de serviço seria tipicamente usado para “planos para a permissão de pequenos dados” para Assinaturas CloT que são de baixo rendimento e onde as aplicações são tolerantes para latência de serviço em potencial. Com o controle de gap de serviço é possível para um operador adicionar um grande número de dispositivos CIoT de baixo rendimento sem ter que ser preocupar com grandes investimentos para capacidade de sinalização de rede.

SUMÁRIO

[004] Soluções existentes no S2-174300 acima mencionadas pela Nokia et al. tentam prover controle de gap de serviço ao passar um parâmetro de gap de serviço na camada de Gerenciamento de Sessão (SM) para o UE. A parte de modem do UE seria então apenas um transporte transparente de informações do temporizador para a parte de aplicação do UE. A aplicação no UE não tem absolutamente nenhuma informação sobre as transições conectado-ocioso no modem. Como as pressuposições acordadas estão no S2-174731 Ericsson et al. acima, são as transições ocioso-conectado que devem ser uma base para o recurso de gap de serviço.

[005] Modalidades da presente revelação propõem passar um parâmetro de gap de serviço na subcamada de Gerenciamento de Mobilidade (MM) na camada NAS para o UE, em vez de um parâmetro (por exemplo um parâmetro PCO) dentro da subcamada SM, conforme indicado em S2-174300. O parâmetro de gap de serviço é um valor ou uma indicação de um valor para um temporizador de gap de serviço para o UE. Por exemplo, o parâmetro de gap de serviço pode especificar o tempo mínimo entre duas solicitações consecutivas de conexão de dados MO. Pode ser usado, por exemplo, para iniciar um temporizador de gap de serviço no UE se o parâmetro tiver sido recebido na Aceitação de Vinculação (Attach Accept) ou Aceitação TAU. O parâmetro de gap de serviço pode ser recebido de HSS. Por exemplo, o parâmetro de gap de serviço pode especificar um Temporizador de Gap de Serviço, que, por exemplo pode indicar o tempo de expiração para um temporizador de gap de serviço iniciado. A parte de modem do UE (a camada NAS) seria, então, tanto o receptor quanto o usuário das informações de temporizador de gap de serviço no UE. Soluções existentes no S2-174300 apenas passam o parâmetro de gap de serviço para a camada de aplicação (fora da camada NAS), cuja camada de aplicação poderia até ser implementada em um chip diferente da camada NAS no UE. Isto é, onde não há nenhum conhecimento de transições de OCIOSO para CONECTADO na camada de aplicação.

[006] Note que a camada NAS é distinta da camada de aplicação que transporta mensagens de camada de aplicação e distinta da camada de estrado de acesso que transporta mensagens relacionadas a acesso. O NAS é uma camada funcional, por exemplo, o UMTS e LTE, pilhas de protocolo entre a rede núcleo e o UE. A camada NAS é responsável por gerenciar o estabelecimento de sessões de comunicação e para manter comunicação contínua com o UE à medida que se move. A subcamada MM é uma subcamada da camada NAS que, por exemplo, tem a funcionalidade de prover serviços de mobilidade para o UE (por exemplo, solicitação de vincular, desvincular, solicitação de serviço, etc.). Conforme aqui descrito, é preferível que a subcamada MM, dentre outras coisas, transporte mensagens NAS que contenham o parâmetro de gap de serviço.

[007] A subcamada MM no UE tem controle de quantas tentativas para se mover do modo OCIOSO para CONECTADO são feitas. Isso chega à camada NAS como solicitações da aplicação no UE. A camada NAS pode, então, manter um temporizador de gap de serviço e, caso não tenha expirado, a camada NAS não irá permitir qualquer transição para o modo CONECTADO para habilitar a transmissão de dados do usuário. Isto é, o gap de serviço pode ser imposto no UE.

[008] Também, o controle de transmissão de dados CP (DoNAS) pode ser feito (por exemplo, o estabelecimento da CONEXÃO de Controle de Recurso de Rádio (RRC) na camada de Estrado de acesso (camada AS) ), uma vez que é a camada NAS que solicita o estabelecimento da CONEXÃO RRC na camada AS. Isto é, a imposição da gap de serviço é possível.

[009] A camada NAS mantém o temporizador de gap de serviço e irá reiniciar o temporizador de gap de serviço quando ocorrer uma transição CONECTADO para OCIOSO. Para controlar os dados DoNAS, a camada NAS também reinicia o temporizador de gap de serviço toda vez que a CONEXÃO RRC for liberada depois que os dados CP/DoNAS tiverem sido enviados.

[010] Os sistemas e métodos aqui revelados proveem uma série de vantagens. Por exemplo, o gap de serviço pode ser manipulado e controlado dentro da parte de modem de um UE (por exemplo, a camada NAS/subcamada MM do UE). A parte de modem do UE seria, então, tanto o receptor quanto o usuário das informações do temporizador da gap de serviço. O temporizador de gap de serviço pode, então, ser controlado e iniciado com base nas informações conhecidas nessa parte do UE, por exemplo, as transições CONECTADO-PARA- OCIOSO, radiolocalização para eventos Finalizados em Móvel (MT) e outras sinalizações NAS/MM.

[011] Gap de serviço controlada dentro da camada NAS/subcamada MM torna possível permitir a sinalização MM NAS normal, tal como Atualização de Área de Rastreamento (TAU), realocação de Identificador Temporário Único Global (ID) (GUTI), etc., quando uma gap de serviço é mantida, por exemplo enquanto um temporizador de gap de serviço está em execução. A camada NAS/subcamada MM é também responsável pela radiolocalização originada na rede que possibilita tornar o gap de serviço seletivo apenas para as solicitações MO.

[012] Uma interface simplificada para a parte de aplicação do UE é possível, por exemplo “notificação quando iniciar a enviar dados” e “notificação quando-parar de enviar dados” baseado no início e na parada do temporizador de gap de serviço.

[013] Para um UE que suporta o recurso de controle de gap de serviço, não há necessidade de usar o recurso de temporizador de backoff de MM que pode requerer sinalização adicional quando as solicitações são rejeitadas. (NOTA: Para os UEs de não suporte, o recurso de temporizador de backoff de MM ainda pode ser aplicado).

BREVE DESCRIÇÃO DOS DESENHOS

[014] As figuras dos desenhos em anexo incorporadas e que formam uma parte do presente relatório descritivo ilustram vários aspectos da revelação e, juntamente com a descrição, servem para explicar os princípios da revelação.

[015] As figuras 1A a 1D ilustram um procedimento de vinculação de acordo com algumas modalidades da presente revelação;

[016] As figuras 2A e 2B ilustram um procedimento TAU de acordo com algumas modalidades da presente revelação;

[017] A figura 3 ilustra um procedimento de solicitação de serviço de acordo com algumas modalidades da presente revelação;

[018] A Figura 4 ilustra um procedimento de retomada de conexão de acordo com algumas modalidades da presente revelação;

[019] A Figura 5 ilustra um exemplo de um sistema de comunicação sem fio no qual as modalidades da presente revelação podem ser implementadas;

[020] A Figura 6 é um fluxograma que ilustra a operação de um dispositivo de comunicação sem fio de acordo com algumas modalidades da presente revelação;

[021] A Figura 7 é um fluxograma que ilustra a operação de um nó de rede de acordo com algumas modalidades da presente revelação;

[022] As figuras 8 e 9 ilustram modalidades exemplificativas de um dispositivo de comunicação sem fio; e

[023] As figuras 10 a 12 ilustram modalidades exemplificativas de um nó de rede.

DESCRIÇÃO DETALHADA

[024] As modalidades estabelecidas abaixo representam informações para permitir que os versados na técnica pratiquem as modalidades e ilustrem o melhor modo de praticar as modalidades. Ao ler a descrição a seguir face às figuras dos desenhos em anexo, os versados na técnica irão entender os conceitos da revelação e reconhecer as aplicações desses conceitos não particularmente abordados aqui. Deve-se entender que esses conceitos e aplicações estão dentro do escopo da revelação.

[025] Nó de rádio: Conforme aqui usado, um “nó de rádio” é ou um nó de Acesso via Rádio ou um dispositivo sem fio.

[026] Nó de Acesso via Rádio: Conforme aqui usado, um “nó de Acesso via Rádio” ou “nó de rede de rádio” é qualquer nó em uma rede de Acesso via Rádio de uma rede de comunicações celular que opera para transmitir e/ou receber sinais sem fio. Alguns exemplos de um nó de Acesso via Rádio incluem, mas não se limitam a, uma estação base (por exemplo, uma estação base (gNB) Novo Rádio (NR) em uma rede NR de Quinta Geração (5G) 3GPP ou um Nó B (eNB) aperfeiçoado ou evoluído em uma rede LTE 3GPP), uma estação base de potência elevada ou macro estação base, uma estação base de baixa potência (por exemplo, uma micro estação base, uma pico estação base, uma eNB Doméstica (HeNB), ou similar), e um nó de relé.

[027] Nó de Rede núcleo: Conforme aqui usado, um “nó de rede núcleo” é qualquer tipo de nó em uma rede núcleo. Alguns exemplos de um nó de rede núcleo incluem, por exemplo, uma entidade MM (MME), um Gateway (P-GW) de Rede de Dados de Pacote (PDN), uma Função de Exposição de Capabilidade de Serviço (SCEF), ou similar.

[028] Dispositivo sem fio: Conforme aqui usado, um “dispositivo sem fio” é qualquer tipo de dispositivo que tem acesso a (por exemplo, é servido por) uma rede de comunicações celular ao transmitir e/ou receber, de modo sem fio, os sinais para um nó/nós de Acesso via Rádio. Alguns exemplos de um dispositivo sem fio incluem, mas não são limitados O UE em uma rede 3GPP, um dispositivo MTC e um dispositivo CIoT.

[029] Nó de rede: Conforme aqui usado, um “nó de rede” é qualquer nó que ou é parte da rede de Acesso via Rádio ou da rede núcleo de uma rede/um sistema de comunicações celulares.

[030] Função de Rede: Conforme aqui usado, uma “função de rede” é qualquer função de rede que é ou parte da rede de Acesso via Rádio ou da rede núcleo de uma rede/um sistema de comunicações celulares.

[031] Entidade de Rede: Conforme aqui usado, ou pode ser um nó de rede ou uma função de rede, por exemplo um nó de rede núcleo ou uma função de rede núcleo.

[032] Note que o foco da descrição feita aqui é o sistema de comunicações celulares 3GPP e, como tal, a terminologia 3GPP, ou terminologia similar à terminologia 3GPP é muitas vezes usada. Porém, os conceitos aqui revelados não se limitam a um sistema 3GPP.

[033] Note que, na presente descrição, referência pode ser feita ao termo “célula;” porém, particularmente com relação aos conceitos 5G NR, feixes podem ser usados em lugar de células e, como tal, é importante observar que os conceitos aqui descritos são igualmente aplicáveis tanto a células quanto a feixes.

[034] O controle de gap de serviço é um recurso destinado principalmente para dispositivos CIoT para controlar que um tempo mínimo tenha decorrido após os dados do usuário MO terem sido comunicados com um

UE (por exemplo, dados de UP MO, dados CP MO ou MO SMS). A intenção é colocar um limite na frequência com que os recursos de rede são usados para um UE. Isso significa que a carga de um grande número de dispositivos CIoT pode ser nivelada e que a contribuição para a carga de pico de rede de tais dispositivos CIoT pode ser reduzida. Isto é, os recursos de rede são usados de uma forma mais ideal. o gap de serviço seria tipicamente usado para "planos de permissão de pequenos dados” para assinaturas CloT que são de baixo rendimento e onde as aplicações são tolerantes à latência de serviço em potencial.

[035] Gap de serviço é, em algumas modalidades, um parâmetro de assinatura. o gap de serviço é imposta em um nível por UE (por exemplo, comum a todas as conexões PDN ) no UE e na MME, ou entidade de gerenciamento de mobilidade similar Um parâmetro de gap de serviço é passado na subcamada MME e tratado dentro da camada NAS no UE e MME ou similar, conforme descrito em detalhes abaixo. A MME ou similar passa o parâmetro de gap de serviço para o UE na mensagem de aceitação de vinculação e/ou mensagem de aceitação TAU. Em algumas modalidades, a MME ou similar passa o parâmetro de gap de serviço para o UE na mensagem de aceitação de vinculação e/ou mensagem de aceitação TAU para o UE que indicou no UE as capabilidades da rede que suportam o gap do recurso de serviço.

[036] A gap de serviço se aplica ao modo ocioso, por exemplo, requer que o UE permaneça um tempo mínimo no modo ECM-OCIOSO. Se não estiver em execução, o temporizador de gap de serviço deve ser iniciado cada vez que um UE se move do ECM-CONECTADO para ECM-OCIOSO. As únicas exceções são quando a conexão foi iniciada após uma radiolocalização de um evento MT, ou após a sinalização TAU MO sem qualquer flag ativa definida (por exemplo, flag ativa ou flag ativa de sinalização), que não deve disparar o início de um novo intervalo de gap de serviço. Em outras palavras, conforme discutido acima, a

MME ou similar passa o parâmetro de gap de serviço (por exemplo, o valor para o temporizador de gap de serviço) para o UE, e o UE usa o parâmetro de gap de serviço na camada NAS/subcamada MM. Os estados e transições de ECM- OCIOSO para ECM-CONECTADO, radiolocalização e TAU são todos partes da camada NAS/subcamada MM.

[037] Como uma modalidade alternativa, a MME ou similar pode ser uma Função de Acesso e Função MM (AMF) em uma rede núcleo 5G.

[038] Como uma modalidade alternativa, a decisão de reiniciar e iniciar o temporizador de gap de serviço pode ser baseada no motivo usado para estabelecer a conexão de sinalização, por exemplo, a causa do estabelecimento de RRC, que indica se o estabelecimento da conexão é solicitado para a sinalização MO ou dados MO.

[039] A desvinculação deve ser permitida a qualquer momento. Quando a desvinculação é feita em ECM-CONECTADO (parte da camada NAS/subcamada MM), o temporizador de gap de serviço deve ser iniciado na desvinculação. Exceções são quando a conexão foi iniciada após uma radiolocalização de um evento MT, ou após a sinalização TAU MO sem qualquer flag ativa definida (por exemplo, flag ativa ou flag ativa de sinalização), que não deve disparar o início de um novo intervalo de gap de serviço. A desvinculação em ECM-OCIOSO não afeta o temporizador de gap de serviço.

[040] O UE deve impor o gap de serviço ao não permitir os dados de UP MO MO, dados CP MO e solicitações de conexão MO SMS e solicitações de vinculação quando um temporizador de gap de serviço está em execução (na camada NAS/subcamada MM no UE). Em algumas modalidades, a aplicação no UE deve ser informada pela camada NAS quando os dados podem ser enviados, por exemplo notificados quando o temporizador de gap de serviço é iniciado e parado. Detalhes são deixados para a implementação (vide Especificação Técnica

(TS) 24.301 para Projeto de Parceria para a 3ª Geração (3GPP).

[041] A MME ou similar deve impor o gap de serviço ao rejeitar dados de UP MO, dados CP MO e solicitações de conexão MO SMS e solicitações de vinculação quando um temporizador de gap de serviço está em execução (na camada NAS/subcamada MM na MME). Em algumas modalidades, ao rejeitar as solicitações de conexão de dados MO, a MME ou similar deve incluir um temporizador de backoff MM que corresponde ao tempo que resta da gap de serviço atual. Em outras palavras, em algumas modalidades, além do que o UE faz, a MME também irá enviar um temporizador de backoff MM quando o temporizador de gap de serviço está em execução se as solicitações de conexão de dados MO são recebidas na MME. NOTA: Para um UE com um bom comportamento e suporte, isso não deve acontecer. Mas com um UE com comportamento precário e que não provê suporte, isso pode acontecer.

[042] Em uma modalidade alternativa, o temporizador de backoff pode ser um novo temporizador de backoff de dados MO. Tal temporizador de backoff teria efeito (por exemplo, parada) nos dados de UP MO, nos dados de CP MO e MO SMS. O temporizador de backoff de dados MO não afetaria outra sinalização NAS, tal como TAU MOs periódico ou de mobilidade (sem flag ativa e sem flag ativa de sinalização – uma vez que as flags ativas podem indicar que os dados serão transmitidos). Uma exceção é que o temporizador de backoff de dados MO afetaria (por exemplo, pararia) as solicitações de vinculação após a desvinculação ou ciclo de potência (o ciclo de potência no UE pode ocorrer na MME ou similar como uma nova solicitação de vinculação a um UE que já está registrado como vinculado na rede). A vantagem desse novo temporizador de backoff de dados MO comparado a um temporizador de backoff de MM é que permitiria que a MM continuasse a trabalhar quando o temporizador de backoff estivesse em execução (A desvantagem é que iria requerer que os UEs dessem suporte, por exemplo não é possível usar em todos os UEs).

[043] Quando a MME ou similar inicia o temporizador de gap de serviço, a MME deve preferivelmente usar um valor que é alguns segundos mais curtos do que o parâmetro de gap de serviço recebido do Serviço de Assinantes Domésticos (HSS) nas informações de assinatura (por exemplo, usadas pelo UE). Isso garante que a MME não rejeite quaisquer solicitações de UE logo antes de o temporizador de gap de serviço expirar, por exemplo, devido a temporizadores UE e MME ligeiramente dessincronizados.

[044] Aspectos preferíveis Adicionais de gap de serviço: - O gap de serviço se aplica a casos de roaming e não roaming. - O gap de serviço se aplica aos dados MO (por exemplo, dados CP MO, dados de UP MO e MO SMS). - Quando o temporizador de gap de serviço está em execução e o UE recebe a radiolocalização, o UE deve responder como normal. - O controle de gap de serviço se aplica a relatório de baixa prioridade (Tolerante a retardo), de tráfego normal e relatório de exceção (para NB-IoT).

[045] NOTA: o gap de serviço não deve ser usado para assinaturas com aplicações sensíveis à latência de serviço por exemplo, quando o relatório de exceção for usado ou UEs usando serviços de emergência. - O controle de gap de serviço deve ser eficaz para dispositivos que realizam desvinculação/revinculação ou ciclo de potência total. Isto é, um temporizador de gap de serviço em execução no UE e a MME devem sobreviver à desvinculação ou ciclo de potência. - TAU com flag ativa ou flag ativa de sinalização não é permitido quando um temporizador de gap de serviço está em execução. - A vinculação durante um temporizador de gap de serviço que permanece em execução não é permitida. A seleção da gap de serviço em Rede Móvel

Terrena Pública (PLMN): a) Revinculação ao mesmo PLMN: O temporizador de gap de serviço sobrevive e controla a revinculação. b) Vinculação ou TAU para um PLMN diferente com o mesmo Módulo de Identidade de Assinante Universal (USIM): O temporizador de gap de serviço sobrevive e controla a vinculação/TAU ao novo PLMN. c) Troca de USIM: O temporizador de gap de serviço é interrompido e o gap de serviço é reiniciado. - Múltiplos pacotes de enlace ascendente e pacotes de enlace descendente são permitidos durante uma conexão RRC para o UE que opera dentro de seus limites de controle de taxa de Nome de Ponto de Acesso (APN).

[046] Os seguintes procedimentos são considerados “solicitações de conexão de dados MO” e são submetidos ao controle de gap de serviço: - Vinculação inicial à Rede de Acesso via Rádio Terrestre Universal Evoluída (E-UTRAN), vide 3GPP TS 23.401 V15.0.0, cláusula 5.3.2.1; - Procedimentos TAU, vide cláusulas sob 3GPP TS 23.401 V15.0.0, cláusula

5.3.3; - Solicitação de serviço disparado UE, vide 3GPP TS 23.401 V15.0.0, cláusula

5.3.4.1; - Solicitação de retomada de contexto S1-AP UE, vide 3GPP TS 23.401 V15.0.0, cláusula 5.3.5A; - Mensagem UE inicial S1-AP com uma Unidade de Dados de Protocolo de Dados NAS (PDU), vide 3GPP TS 23.401 V15.0.0, cláusula 5.3.4B.2; - Procedimento de Entrega de Dados de Protocolo de Não Internet MO (NIDD), vide 3GPP TS 23.682, cláusula 5.13.4; - Mensagem curta MO, vide 3GPP TS 23.040, cláusula 10.2. Procedimento de Vinculação

Vinculação Inicial E-UTRAN

[047] Conforme ilustrado nas Figuras 1A-1D, um UE precisa se registrar na rede para receber serviços que requerem registro. Esse registro é descrito como vinculação à rede. A conectividade permanente no Protocolo da Internet (IP) Para o UE/usuários do Sistema de Pacote Evoluído (EPS)pode ser habilitada ao se estabelecer um transportador EPS padrão (default)durante a vinculação à rede as regras de Controle de Política e Carregamento (PCC) aplicadas à transportador EPS padrão pode ser predefinida no P-GW e são ativadas na vinculação pelo próprio P-GW . O procedimento de vinculação pode disparar um ou múltiplos procedimentos de estabelecimento de transportador dedicado para estabelecer transportadores EPS dedicados para esse UE. Durante o procedimento de vinculação, o UE pode solicitar uma alocação de endereço IP. Os terminais que utilizam apenas mecanismos baseados em uma Força Tarefa de Engenharia de Internet (IETF) para a alocação de endereço IP também recebem suporte.

[048] Durante o procedimento de vinculação inicial, a identidade de Equipamento Móvel (ME) é obtida do UE. O operador MME pode checar a identidade ME com um Registro de Identidade de Equipamento (EIR). A MME passa a identidade ME (Versão de Software de Identificação Internacional de Equipamento Móvel (IMEISV)) para o HSS e para o P-GW.

[049] Durante o procedimento inicial de vinculação, se a MME suporta a Continuidade de Chamada de Voz de Rádio Único (SRVCC) e se qualquer uma das condições descritas na etapa 8 nas Figures 1A a 1D são satisfeitas, a MME informa ao HSS com a capabilidade UE SRVCC , por exemplo, quanto a outro registro de Subsistema Multimídia IP (IMS).

[050] O procedimento de vinculação inicial E-UTRAN é usado para vinculação de emergência pelos UEs que precisam realizar serviços de emergência, mas não podem ganhar serviços normais da rede. Esses UEs estão em condição de serviço limitado, conforme definido em 3GPP TS 23.122. Também, os UEs que fizeram vinculação para serviços normais e não têm transportadores de emergência estabelecidos e estão acampados em uma célula em estado de serviço limitado (por exemplo, Área de Rastreamento Restrita (TA) ou Grupo Fechado de Assinante não permitido (CSG)) deve iniciar os procedimentos de vinculação indicando que a vinculação irá receber os serviços de emergência. Os UEs acampados normalmente em uma célula, por exemplo UEs que não estão em estado de serviço limitado, devem iniciar a vinculação inicial normal quando ainda não estiverem vinculados, e devem iniciar o procedimento de conectividade de PDN solicitada por UE para receber os serviços de transportador EPS de emergência. - NOTA 1: O UE que é vinculada de emergência realiza o procedimento inicial de vinculação antes de ser capaz de obter serviços normais.

[051] Para limitar a carga na rede, apenas ao realizar uma vinculação E- UTRAN com um novo PLMN (por exemplo, não o PLMN registrado ou um PLMN (ePLMN)equivalente do PLMN registrado), um UE configurado para realizar a vinculação coma Identidade do Assinante Móvel Internacional (IMSI) na mudança de PLM (vide 3GPP TS 24.368) deve se identificar por seu IMSI em vez de qualquer identificador temporário armazenado.

[052] Esse procedimento também é usado para estabelecer a primeira conexão PDN via E-UTRAN quando o UE tem conexões ativas PDN por meio de uma rede de acesso 3GPP e quer estabelecer conexões PDN simultâneas para diferentes APNs por meio de múltiplos acessos. - NOTA 2: Para um Móvel Proxy IPv6 (PMIP) -baseado em S5/S8, as etapas de procedimento (A), (B), e (C) são definidas em 3GPP TS 23.402. Etapas 7, 10, 13, 14, 15, e 23A/B referem-se ao Protocolo de tunelamento de serviço geral de rádio de pacote (GTP) baseado em S5/S8. - NOTA 3: Os Gateways de Serviço (S-GWs) e P-GWs envolvidos nas etapas 7 e/ou 10 podem ser diferentes dos das etapas 13-15. - NOTA 4: As etapas em (D) são executadas apenas no handover de acesso não 3GPP ou, se estiver presente, as informações da área de relatório forem recebidas de MME. - NOTA 5: Mais detalhes sobre as etapas de procedimento (E) são definidas nas etapas de procedimento (B) na cláusula 5.3.8.3. - NOTA 6: Mais detalhes das etapas de procedimento (F) são definidos nas etapas de procedimento (B) na cláusula 5.3.8.4.

[053] As Figuras 1A-1D ilustram o procedimento de vinculação. As etapas do procedimento de vinculação ilustradas nas Figuras 1A a 1D serão agora descritas como revelado em 3GPP TS 23.401 V15.0.0, acrescido do fato de que o recurso de gap de serviço da presente revelação foi incluído.

[054] Etapa 1: O UE, acampado em uma célula E-UTRAN, lê a difusão das informações do sistema relacionada.

[055] Uma célula E-UTRAN para um PLMN que suporta os aperfeiçoamentos de CIoT deve difundir: - Para o caso NB-IoT: o Se pode se conectar a um MME que suporta a vinculação EPS sem a conectividade PDN. - Para o caso de Banda larga E-UTRAN (WB-E-UTRAN): o Se suporta a otimização CP CIoT EPS e pode se conectar a uma MME que suporta a otimização CP CIoT EPS. o Se suporta a otimização de UP CIoT EPS e pode se conectar a uma MME que suporta a otimização de UP CIoT EPS. o Se pode se conectar a um MME que suporta a vinculação de EPS sem a conectividade PDN.

[056] Se o PLMN não anuncia o suporte da vinculação EPS sem a conectividade PDN e o UE só pode vincular sem a conectividade PDN, então o UE não deve vincular ao PLMN nessa célula e deve prosseguir conforme especificado em 3GPP TS 23.122.

[057] No caso de WB-E-UTRAN, se o PLMN não suporta a otimização CP CIoT EPS e o UE apenas suporta a otimização de CP CIoT EPS e não pode, de outra forma, vincular, então o UE não deve prosseguir com a vinculação de PLMN nessa célula e deve prosseguir conforme especificado em 3GPP TS 23.122.

[058] Caso um temporizador de gap de serviço esteja em execução no UE (vide cláusula 4.3.x abaixo), então o UE não deve vincular a PLMN ou qualquer outro PLMN enquanto o temporizador estiver em execução. NOTE que “cláusula

4.3.x” é uma referência a uma nova cláusula ainda não nomeada que a Solicitação de Mudança introduz (vide abaixo). Provavelmente será nomeada como 4.3.30 na próxima versão de 3GPP TS 23.401.

[059] Se o UE pode prosseguir para vincular, este inicia o procedimento de vinculação pela transmissão, para o eNB, de uma solicitação de vinculação (IMSI ou GUTI antigo, tipo GUTI antigo, identidade TA que visitou pela última vez (TAI) (caso esteja disponível), capabilidade de rede núcleo de UE, parâmetros de Recepção Descontínua específica de UE (DRX) , parâmetros DRX de modo ocioso estendido, tipo de vinculação, contêiner de mensagem de Gerenciamento de Sessão de Sistema de Pacote Evoluído (ESM) (tipo de solicitação, tipo de PDN, opções de configuração de protocolo, flag de transferência de opções cifradas, configuração de compressão de cabeçalho), Entidade de Gerenciamento de Segurança de Acesso de Identificador de Conjunto chave (KSIASME), número de sequência NAS, Controle de Acesso ao Meio (MAC) NAS, GUTI adicional, Assinatura de Identidade de Assinante Móvel Temporário de Pacote (P-TMSI),

mensagem de preferência de domínio de voz e configuração do uso do UE, comportamento preferível de rede, capabilidade de rede de Estação Móvel (MS), suporte para restrição de uso de cobertura aperfeiçoada) juntamente com parâmetros RRC que indicam a rede selecionada e o identificador MME globalmente único(GUMMEI).

[060] Na sinalização de estabelecimento de conexão RR associada à solicitação de vinculação, o UE indica seu suporte de otimizações CIoT EPS, relevantes para a seleção de MME.

[061] Se UE se identifica com o GUTI antigo, o UE deve definir o antigo tipo de GUTI para indicar se o GUTI antigo é um GUTI nativo ou se é mapeado de um P-TMSI e Identificação de Área de Roteamento (RAI). O GUTI antigo pode ser derivado de um P-TMSI e RAI. O IMSI deve ser incluído se o UE não tem um GUTI válido ou um P-TMSI válido disponível, ou se o UE é configurado para realizar a vinculação com IMSI na mudança de PLMN e está acessando um novo PLMN. O UE armazena a Identidade Temporária (TIN) em um estado desvinculado. Se os TIN de UE's indicam "GUTI" ou " TMSI relacionado a RAT” e o UE mantém um GUTI válido, então o GUTI antigo indica esse GUT válido. Se o TIN dos US indica "P-TMSI” e o UE contém um P-TMSI válido e relacionado a RAI, então esses dois elementos são indicados como o GUTI antigo. O mapeamento de P-TMSI e RAI a um GUTI é especificado em 3GPP TS 23.003. Se o UE contém um GUTI válido e o GUTI antigo indica um GUTI mapeado de um P-TMSI e RAI, então o UE indica o GUTI como GUTI adicional. Se o GUTI antigo indica um GUTI mapeado de um P-TMSI e RAI e o UE tem a assinatura P-TMSI válida associada ao mesmo, a assinatura P-TMSI deve ser incluída. O UE estabelece a preferência de domínio de voz e a configuração do uso de UE de acordo com sua configuração, conforme descrito em 3GPP TS 23.401 V15.0.0 cláusula 4.3.5.9.

[062] Alternativamente, quando um UE apenas suporta E-UTRAN, se o UE tem um GUTI disponível e o UE está acessando o mesmo PLMN (ou ePLMN), então se identifica com o GUTI antigo e define o antigo tipo GUTI como “nativo,” de outra forma a configuração UE determina se o UE se identifica com o IMSI ou o GUTI antigo.

[063] O UE inclui o elemento de informações de parâmetros DRX de modo ocioso estendido se o UE precisa habilitar o modo ocioso estendido DRX.

[064] Caso esteja disponível, o TAI visitado por último deve ser incluído a fim de ajudar a MME a produzir uma boa lista de TAIs para qualquer mensagem de aceitação de vinculação subsequente. A rede selecionada indica a PLMN que é selecionada para fins de compartilhamento de rede. O parâmetro RRC "antigo GUMMEI” tira seu valor do "GUTI antigo” contido na solicitação de vinculação. A capabilidade de rede UE é descrita nas capabilidades UE, vide 3GPP TS 23.401 V15.0.0 cláusula 5.11.

[065] Se o UE tem parâmetros de segurança válidos, a mensagem de solicitação de vinculação deve ser protegida em sua integridade por NAS-MAC a fim de permitir a validação do UE pela MME. KSIASME, número de sequência NAS e NAS-MAC são incluídos se o UE tem parâmetros de segurança EPS válidos. O número de sequência NAS indica o número sequencial da mensagem NAS. Se o UE não tem uma associação de segurança EPS válida, então a mensagem de solicitação de vinculação não é protegida em sua integridade. Nesse caso, a associação de segurança é estabelecida na etapa 5A. As capabilidades de rede UE também indicam NAS e os algoritmos de segurança AS suportados.

[066] O tipo de PDN indica a versão IP solicitada (IPv4, IPv4/IPv6, IPv6).Para um UE que suporta as otimizações CIoT EPS, o tipo de PDN pode também ser Opções de Configuração de Protocolo “não IP” (PCOs) são usados para transferir parâmetros entre o UE e o P-GW, e são enviados de modo transparente através da MME e do S-GW. Os PCOs podem incluir a preferência de alocação de endereço que indica que o UE prefere obter um endereço IPv4 apenas após a ativação de transportador padrão por meio da Versão 4(DHCPv4) do Protocolo de Configuração de Servidor Dinâmico. Se o UE pretende enviar os PCOs que requerem cifragem (por exemplo, nomes do usuário e senha do Protocolo de Autenticação de Senha (PAP) / Protocolo de Autenticação por Desafio Handshake (CHAP) ou enviar um APN, ou ambos, o UE deve definir a flag de transferência de opções cifradas e enviar PCO ou APN ou ambos apenas após a autenticação e preparação de segurança NAS ter sido concluída (vide abaixo). - NOTA 7: Os operadores de rede externa que querem usar PAP para autenticação são advertidos que o PAP é um protocolo obsoleto de um ponto de vista de segurança. O CHAP provê uma segurança maior do que o PAP.

[067] O UE deve incluir no PCO o status de UE de dados comutados por pacote (PS) 3GPP desligados que indica se o usuário ativou ou desativou os dados 3GPP os desligados.

[068] Se o UE tem capabilidades de Rede de Acesso de Rádio Terrestre Universal (UTRAN) ou Rede de Acesso de Rádio de Taxas de Dados Aperfeiçoadas para Sistema Global para Comunicações Móveis de Sistema Global para Comunicações Móveis (GERAN), deve enviar o UE de Suporte de Solicitação de Rede (NRSU) no PCO para indicar o suporte do controle de transportador solicitado de rede na UTRAN/GERAN. O UE envia o UE de Suporte de Modelo de Fluxo de Tráfego (TFT) Estendido (ETFTU) no PCO para indicar o suporte do formato de filtro TFT estendido. O tipo de solicitação é incluído no contêiner de mensagem ESM e indica "handover” quando o UE já tem um P-GW/ Agente Doméstico (HA) ativado devido à mobilidade com acessos não 3GPP.

[069] Se um UE indica suporte de otimizações CIoT na mensagem RRC, pode omitir o contêiner de mensagem ESM. Se o contêiner da mensagem ESM é omitido, a MME não deve estabelecer uma conexão PDN como parte do procedimento de vinculação. Nesse caso, as etapas 6, 12 a 16, e 23 a 26 não são executadas. Além disso, para o caso de UEs se vinculando à otimização CP CIoT EPS sem nenhum estabelecimento de UP, as etapas 17 a 22 são substituídas por transporte NAS S1-AP e mensagens de transferência direta RRC que apenas transportam as mensagens de aceitação de vinculação e conclusão de vinculação NAS.

[070] Tipo de vinculação indica se é uma vinculação EPS ou uma vinculação combinada EPS/IMSI ou uma vinculação de emergência. A vinculação de emergência não será indicada quando o UE estiver usando NB-IoT. Ao usar as otimizações C-IoT EPS, o UE pode indicar vinculação EPS e solicitar SMS ao definir a flag "transferência de SMS sem a vinculação combinada” no Elemento de Informações (IE) de comportamento de rede preferível.

[071] Se um UE inclui um comportamento de rede preferível, isso define o comportamento da rede que o UE está esperando ficar disponível na rede, conforme definido em 3GPP TS 23.401 V15.0.0 cláusula 4.3.5.10.

[072] Se um UE indicou a otimização CP CIoT EPS suportada no comportamento de rede preferível e o UE incluiu o contêiner de mensagem ESM e o tipo de PDN era IPv4 ou IPv6 ou IPv4v6, e o UE suporta compressão de cabeçalho, deve incluir a configuração de compressão de cabeçalho. A configuração de compressão de cabeçalho inclui as informações necessárias para o preparação do canal de Compressão de Cabeçalho Robusto (ROHC) Opcionalmente, a configuração de compressão de cabeçalho pode incluir parâmetros adicionais de preparação de contexto de compressão de cabeçalho se o UE já tem informações de tráfego de aplicação , por exemplo, o endereço IP do servidor de destino.

[073] Para uma vinculação de emergência, o UE deve definir tanto o tipo de vinculação e o tipo de solicitação para “emergência” e o IMSI deve ser incluído se o UE não tiver um GUTI válido ou um P-TMSI válido disponível. A Identificação Internacional de Equipamento Móvel (IMEI) deve ser incluída quando o UE não tem IMSI, não tem GUTI válido e não tem P-TMSI.

[074] Etapa 2: O eNB deriva o endereço MME dos parâmetros RRC que portam o antigo GUMMEI, a rede selecionada indicada e o RAT (NB-IoT ou WB- E-UTRAN). Se esse MME não estiver associado ao eNB ou o GUMMEI antigo não estiver disponível, o eNB seleciona um MME, conforme descrito em 3GPP TS

23.401 V15.0.0 cláusula 4.3.8.3 em "função de seleção de MME.” O eNB encaminha a solicitação de mensagem de vinculação em uma mensagem de controle S1-MME (mensagem UE inicial) juntamente com a rede selecionada, modo de acesso CSG, ID CSG, endereço do Gateway Local (L-GW), TAI + ID Global de Célula de Rede de Acesso de Rádio Terrestre Universal Evoluída (ECGI) da célula de onde recebeu a mensagem para a nova MME. A ID CSG é provida se o UE vincula via uma célula CSG ou célula híbrida. O modo de acesso CSG é provido se o UE vincula via uma célula híbrida. Se o modo de acesso CSG não é provido, mas uma ID CSG é provida, a MME deve considerar a célula como uma célula CSG. Se um eNB tem um L-GW justaposta, inclui o endereço L-GW na mensagem UE inicial para a MME.

[075] Se a MME não estiver configurada para suportar a vinculação de emergência, a MME deve rejeitar qualquer solicitação de vinculação que indica tipo de vinculação de “emergência”.

[076] Se o UE incluiu o comportamento de rede preferível, e o que o UE indicou que ele suporta em um comportamento de rede preferível é incompatível com o suporte da rede, por exemplo o UE indicou apenas para a otimização de CP CIoT EPS e a MME apenas suporta a otimização de UP CIoT EPS, a MME deve rejeitar a solicitação de vinculação com um valor de causa apropriado (por exemplo, um que evita novas tentativas em PLMN).

[077] Para ajudar os serviços de localização, o eNB indica para os UE's o nível de cobertura para a MME.

[078] Etapa 3: Se o UE se identifica com o GUTI e a MME mudou desde a desvinculação, a nova MME determina o tipo do antigo nó , por exemplo MME ou Nó de Suporte de Serviço de Rádio de Pacote Geral de Serviço (SGSN), conforme especificado em 3GPP TS 23.401 V15.0.0 cláusula 4.3.19, usa o GUTI recebido do UE para derivar o antigo endereço MME/SGSN e envia uma solicitação de identificação (GUTI antigo, mensagem de solicitação de vinculação concluída) para o antigo MME/SGSN para solicitar o IMSI. Se a solicitação é enviada para uma antiga MME, a antiga MME primeiro verifica a mensagem de solicitação de vinculação por NAS MAC e, então, responde com resposta de identificação (IMSI, contexto MM). Se a solicitação é enviada para um antigo SGSN, o antigo SGSN primeiro verifica a mensagem de solicitação de vinculação pela assinatura do P-TMSI e, então, responde com a resposta de identificação (contexto MM). Se o UE não é conhecido no antigo MME/SGSN, ou se a verificação de integridade ou verificação de assinatura P-TMSI para a mensagem de solicitação de vinculação falhar, o antigo MME/SGSN responde com uma causa de erro apropriada. O contexto MM contém informações relacionadas à segurança, assim como outros parâmetros (incluindo IMSI), conforme descrito em 3GPP TS 23.401 V15.0.0 cláusula 5.7.2 (armazenamento de informações para MME).

[079] o GUTI adicional na mensagem de solicitação de vinculação permite que a nova MME encontre qualquer contexto de UE já existente armazenado no nova MME quando o GUTI antigo indica um GUTI mapeado de uma P-TMSI e RAI.

[080] Para uma vinculação de emergência, se o UE se identifica com a identidade temporária que não é conhecida para a MME, a MME imediatamente solicita a IMSI do UE. Se o UE se identifica com a IMEI, deve-se pular a solicitação de IMSI. - NOTA 8: Um SGSN sempre responde com os parâmetros de segurança do Sistema Universal Móvel de Telecomunicações (UMTS) e a MME pode armazená- lo para uso posterior.

[081] Etapa 4: Se o UE é desconhecido tanto em antigo MME/SGSN quanto na nova MME, a nova MME envia uma solicitação de identidade para o UE para solicitar a IMSI. O UE responde com a resposta de identidade (IMSI).

[082] Etapa 5A: Se não existe nenhum contexto de UE para o UE em lugar algum na rede, se a solicitação de vinculação (enviada na etapa 1) não foi protegida na integridade, ou se a verificação de integridade falhou, então a preparação de autenticação e de segurança NAS para ativar a proteção de integridade e a cifragem de NAS são mandatórias. De outra forma, é opcional. Se o algoritmo de segurança NAS vai ser mudado, a preparação de segurança NAS é realizada nessa etapa. As funções de preparação de autenticação e segurança NAS são definidas em 3GPP TS 23.401 V15.0.0 cláusula 5.3.10 na “função de segurança”.

[083] Se a MME for configurada para suportar vinculação de emergência para IMSIs não autenticados e o UE indicou o tipo de vinculação de “emergência,” a MME pula a preparação de autenticação e segurança ou a MME aceita que a autenticação pode falhar e continua o procedimento de vinculação.

[084] Após a etapa 5A, todas as mensagens NAS deverão ser protegidas pelas funções de segurança (integridade e cifragem) NAS indicadas pela MME, a menos que UE seja vinculado de emergência e não autenticado com sucesso.

[085] Etapa 5B: A identidade ME (IMEISV) deve ser recuperada de UE. A identidade ME deve ser transferida criptografada, a menos que UE realize vinculação de emergência e não possa ser autenticado.

[086] Para uma vinculação de emergência, o UE pode ter incluído a IMEI na vinculação de emergência. Caso o tenha feito, pula-se a recuperação da identidade ME.

[087] Para minimizar os atrasos de sinalização, a recuperação da identidade ME pode ser combinada com a preparação de segurança NAS na etapa 5A. A MME pode enviar a solicitação de verificação de identidade ME (identidade ME, IMSI) para o EIR. O EIR deve responder com a Reconhecimento de verificação de identidade ME (ACK) (resultado). Dependendo do resultado, a MME decide se continua com esse procedimento de vinculação ou se rejeita o UE.

[088] Para uma vinculação de emergência, a verificação de IMEI para o EIR pode ser feita. Se a IMEI é bloqueada, as políticas do operador determinam se o procedimento de vinculação de emergência continua ou é parado.

[089] Etapa 6: Se o UE definiu a flag de transferência de opções cifradas na mensagem de solicitação de vinculação, as opções cifradas, por exemplo PCO ou APN, ou ambas, serão agora recuperadas do UE.

[090] Para lidar com situações em que o UE pode ter assinaturas para vários PDNs, se as opções de configuração de protocolo contêm credenciais do usuário (por exemplo, nome/senha do usuário dentro dos parâmetros PAP ou CHAP), então o UE também deve enviar o APN para a MME.

[091] Etapa 7: Se há contextos de transportador ativo na nova MME para esse UE em particular (por exemplo, o UE é revinculado à mesma MME sem ter se desvinculado adequadamente antes), a nova MME exclui esses contextos de transportador ao enviar mensagens de solicitação de sessão de exclusão (Mensagens ID de transportador vinculado (LBI)) para os gateways envolvidos. Os gateways reconhecem com a mensagem de resposta (causa) de sessão de exclusão. Se uma Função de Regras de Política e Carregamento (PCRF) é implementada, o P-GW emprega um procedimento de término de sessão de Rede de Acesso de Conectividade IP (IP-CAN) para indicar que os recursos foram liberados.

[092] Etapa 8: se há um contexto de assinatura válido para o UE na MME com um temporizador de gap de serviço em execução, a MME rejeita a solicitação de vinculação do UE com uma causa apropriada e com um temporizador de backoff de MM definido para o tempo de gap de serviço restante.

[093] Se a MME mudou desde a última desvinculação, ou se não há contexto de assinatura válido para o UE na MME, ou se o UE provê um IMSI ou o UE provê um GUTI antigo que não se refere a um contexto válido na MME, ou para algum cenário de compartilhamento de rede (por exemplo, Rede núcleo de gateway (GWCN)) se o PLMN-ID do TAI suprido pelo eNB for diferente do GUTI no contexto de UE, a MME envia uma mensagem de solicitação de atualização de localização (Identidade MME, IMSI, identidade ME (IMEISV), capabilidades da MME, flags de Solicitação de Atualização de Localização (ULR) , suporte homogêneo de voz sobre IMS de sessões PS, capabilidade de UE SRVCC, lista PLMN equivalente) para o HSS. As capabilidades de MME indicam o suporte dos MME's para a funcionalidade de restrições de acesso regional. As flags ULR indicam o “indicador de vinculação inicial”, uma vez que esse é um procedimento de vinculação. A inclusão da lista equivalente de PLMN indica que a MME suporta o handover de inter PLMN para uma célula CSG em um PLMN equivalente usando as informações de assinatura do PLMN de destino. A indicação de “suporte homogêneo de voz sobre IMS de sessões PS” (vide 3GPP TS 23.401 V15.0.0 cláusula 4.3.5.8A) não deve ser incluída, a menos que a MME tenha completado sua avaliação do suporte de “voz sobre IMS de sessão PS”, conforme especificado em 3GPP TS 23.401 V15.0.0 cláusula 4.3.5.8.

- NOTA 9: Nessa etapa, a MME pode não ter todas as informações necessárias para determinar o estabelecimento da indicação suportada pela voz sobre IMS de sessão PS para esse UE (vide 3GPP TS 23.401 V15.0.0 cláusula

4.3.5.8). Portanto, a MME pode enviar o “suporte homogêneo de voz sobre IMS de sessões PS” posteriormente neste procedimento.

[094] Se UE realiza vinculação inicial ou vinculação de handover em um roaming CSG autônomo de suporte PLMN Visitado (VPLMN) e o PLMN doméstico (HPLMN) permitiu o roaming CSG autônomo no VPLMN (via contrato de nível de serviço) e a MME precisa recuperar as informações de assinante de CSG do UE do Servidor de Assinante de Grupo Fechado (CSS), a MME inicia o procedimento de atualização de localização CSG com CSS, conforme descrito em 3GPP TS

23.401 V15.0.0 cláusula 5.3.12.

[095] Se a MME determina que apenas a capabilidade UE SRVCC mudou, a MME envia uma solicitação de notificação para o HSS para informar sobre a capabilidade mudada de UE SRVCC.

[096] Para uma vinculação de emergência em que o UE não foi autenticado de modo bem-sucedido, a MME não deve enviar uma solicitação de atualização de localização para o HSS.

[097] Etapa 9: O HSS envia localização de cancelamento (IMSI, tipo de cancelamento) para a antiga MME. A antiga MME reconhece com o ACK de local de cancelamento (IMSI) e remove os contextos de MM e transportador. Se as flags ULR indicam “indicador de vinculação inicial” e o HSS tem o registro SGSN, então o HSS envia a localização de cancelamento (IMSI, tipo de cancelamento) para o antigo SGSN. O tipo de cancelamento indica o antigo MME/SGSN para liberar o antigo recurso S-GW.

[098] Etapa 10: Se há contextos de transportador ativo no antigo MME/SGSN para esse UE em particular, o antigo MME/SGSN exclui esses contextos de transportador ao enviar mensagens de solicitação de sessão de exclusão (LBI) para os gateways envolvidos. Os gateways retornam a mensagem de resposta (causa) de sessão de exclusão para o antigo MME/SGSN. Se um PCRF for implementado, o P-GW emprega um procedimento de término de sessão IP- CAN, conforme definido em 3GPP TS 23.203 para indicar que recursos foram liberados.

[099] Etapa 11: O HSS reconhece a mensagem de atualização de localização ao enviar uma mensagem ACK de atualização de localização (IMSI, dados de assinatura) para a nova MME. Os dados de assinatura contêm um ou mais contextos de assinatura PDN. Cada contexto de assinatura PDN contém um “Perfil de Qualidade de Serviço(QoS) Assinado EPS” e a Taxa de Bit Máximo de Agregado APN assinado (AMBR) (vide 3GPP TS 23.401 V15.0.0 cláusula 4.7.3) e a indicação de descarregamento de Rede de área local sem fio (WLAN) (vide 3GPP TS 23.401 V15.0.0 cláusula 4.3.23). a nova MME valida a presença dos UE's na (nova) TA. Se devido a restrições regionais de assinatura ou restrições de acesso (por exemplo, Restrições CSG) não se permite que o UE vincule na TA, ou se a verificação de assinatura falhar por outras razões, a nova MME rejeita a solicitação de vinculação com uma causa apropriada. Se todas as verificações forem bem-sucedidas, então a nova MME constrói um contexto para o UE. Se o APN provido pelo UE não é permitido por assinatura, ou a atualização da localização for rejeitada pelo HSS, a nova MME rejeita a solicitação de vinculação do UE com uma causa apropriada.

[0100] Os dados de assinatura podem conter informações de assinatura CSG para a PLMN registrada e para a lista de ePLMN solicitada pela MME na etapa 8.

[0101] Os dados de assinatura podem conter um parâmetro restrito de cobertura aperfeiçoada. Se recebido do HSS, a MME armazena esse parâmetro restrito de cobertura aperfeiçoada no contexto MME MM.

[0102] Os dados de assinatura podem conter um parâmetro de gap de serviço. Se recebido do HSS, a MME armazena esse parâmetro de gap de serviço no contexto MME MM e o passa para o UE na mensagem de aceitação de vinculação.

[0103] Se o UE que fez a provisão de APN está autorizado para o Acesso IP Local (LIPA) de acordo com a assinatura do usuário, a MME deve usar os dados de assinatura do CSG para autorizar a conexão.

[0104] Para uma vinculação de emergência, a MME não deve verificar as restrições de acesso, restrições regionais, restrições de assinatura (por exemplo, restrições CSG). Para uma vinculação de emergência, a MME deve ignorar qualquer resposta de atualização de localização que não foi bem-sucedida do HSS e continuar com o procedimento de vinculação.

[0105] Etapa 12: Se um contêiner ESM não foi incluído na solicitação de vinculação, pulam-se as etapas 12, 13, 14, 15, e 16. Se o tipo de vinculação não é definido para “emergência,” e o contêiner ESM foi incluído na solicitação de vinculação, e o UE indicou suporte para vinculação sem conectividade PDN e a restrição de conexão PDN é definida nos dados do assinante, então a nova MME não deve estabelecer a conexão PDN, pulando-se as etapas 12, 13, 14, 15, e 16.

[0106] Para uma vinculação de emergência, a MME aplica os parâmetros dos dados de configuração de emergência MME para o estabelecimento do transportador de emergência realizado nessa etapa, e quaisquer dados IMSI potencialmente armazenados de assinatura relacionada a IMSI são ignorados pela MME.

[0107] Se o UE realiza a vinculação de handover ou vinculação inicial via uma CSG célula e não há nenhuma assinatura para esse CSG, ou a assinatura CSG expirou, a MME deve rejeitar a solicitação de vinculação com uma causa apropriada. Se o UE tem esse ID CSG e PLMN associada em sua lista CSG permitida, o UE deve remover o ID CSG ID e PLMN associada da lista ao receber essa causa de rejeição.

[0108] Se um endereço PDN assinado é alocado para o UE para esse APN, o contexto de assinatura PDN contém o endereço dos UE's IPv4 e/ou o prefixo IPv6 e, opcionalmente, a identidade P-GW. Se o contexto de assinatura PDN contém um endereço IPv4 assinado e/ou prefixo IPv6, a MME o indica no endereço PDN. Para o tipo de solicitação que indica “solicitação inicial,” se o UE não provê um APN, a MME deve usar o P-GW correspondente ao APN padrão para a ativação de transportador padrão. Se o UE provê um APN, esse APN deve ser empregado para ativação de transportador padrão. Para o tipo de solicitação que indica “handover,” se o UE provê um APN, a MME deve usar o P-GW correspondente ao APN provido para a ativação de transportador padrão, se o UE não provê um APN, e o contexto de assinatura de HSS contém uma Identidade P-GW correspondente ao padrão APN, a MME deve usar o P-GW correspondente ao padrão APN para ativação de transportador padrão. O caso em que o tipo de solicitação indica “handover” e o UE não provê um APN, e o contexto de assinatura de HSS não contém a identidade P-GW correspondente ao padrão APN constitui um caso de erro. Se o tipo de solicitação indica “solicitação inicial” e o contexto de assinatura PDN selecionado não contém nenhuma Identidade P-GW, a nova MME seleciona um P-GW conforme descrito em 3GPP TS 23.401 V15.0.0 cláusula 4.3.8.1 na função de seleção P-GW (acessos 3GPP). Se o contexto de assinatura PDN contém uma identidade P-GW dinamicamente alocada e o tipo de solicitação não indica “handover,” a MME pode selecionar um novo P-GW, conforme descrito na cláusula função de seleção P-GW, por exemplo para alocar um P-GW que permite um roteamento mais eficaz.

[0109] Para vinculação inicial de emergência e de handover, a MME usa a função de seleção P-GW definida em 3GPP TS 23.401 V15.0.0 cláusula 4.3.12.4 para selecionar um P-GW.

[0110] Se o contexto de assinatura não indica que o APN é para uma conexão PDN para um SCEF, a nova MME seleciona um S-GW conforme descrito em 3GPP TS 23.401 V15.0.0 cláusula 4.3.8.2 na função de seleção S-GW e aloca uma identidade transportador EPS para o transportador padrão associado ao UE. Então envia uma mensagem de solicitação de criação de sessão (IMSI, Rede Digital de Serviços integrados do Assinante Móvel (MSISDN), ID de Ponto de Extremidade de Túnel MME (TEID) para CP, endereço P-GW, endereço PDN , APN, tipo de RAT , QoS de transportador padrão EPS, tipo de PDN, APN-AMBR, identidade de transportador EPS, PCOs, indicação de handover, identidade ME (IMEISV), informações de localização do usuário (ECGI), Fuso Horário do UE , informações do CSG do usuário, indicação de suporte de relatório de mudança de informações MS, modo de seleção, características de carregamento, referência de rastreamento, tipo de rastreamento, disparar ID, Identidade de Centro de Operações e Manutenção (OMC, restrição máxima APN, flag de transportador de endereço duplo, o tipo de protocolo via S5/S8, rede servidora) para o S-GW selecionado. Caso a otimização CP CIoT EPS se aplica, então a MME deve também indicar o tunelamento de S11-U de dados de usuário de NAS e envia seu próprio endereço S11-U IP e enlace descendente TEID de MME para dados de enlace descendente enviando pelo S-GW. As informações CSG do usuário incluem ID CSG, modo de acesso e indicação de filiação de CSG.

[0111] Para o tipo de PDN "não IP" quando as otimizações de CP CIoT EPS são habilitadas para o UE, se os dados de assinatura APN indicam que uma conexão SCEF precisa ser usada, então a MME aloca uma identidade transportador EPS para o transportador padrão associado ao UE e estabelece uma conexão com o endereço SCEF indicado em dados de assinatura quanto ao 3GPP TS23.682 e as etapas 12, 13, 14, 15, e 16 não são executadas. O resto das interações com o UE se aplicam como especificado abaixo.

[0112] Se a MME determina que a conexão PDN só deve usar a otimização CP CIoT EPS, a MME deve incluir um indicador de conexão PDN com apenas um CP na solicitação de criação de sessão.

[0113] Se o tipo de solicitação indica “emergência,” não deve ser realizado controle máximo de restrição APN.

[0114] Para os UE vinculados de emergência, a IMSI é incluída se estiver disponível e se a IMSI não puder ser autenticada, então a IMSI deve ser marcada como não autenticada.

[0115] O tipo de Tecnologia de Acesso via Rádio (RAT) é provido nessa mensagem para a decisão PCC posterior. O tipo RAT tipo deve distinguir entre os tipos NB-IoT e WB-E-UTRA. O APN-AMBR assinado para o APN é também provido nessa mensagem. A MSISDN é incluída se provida nos dados de assinatura de HSS. A indicação de handover é incluída se o tipo de solicitação indicar handover. O modo de seleção indica se um APN assinado foi selecionado, ou um APN não assinado enviado pelo UE foi selecionado. Características de carregamento indicam que tipo de contexto de carregamento pelo qual o transportador é responsável. A MME pode mudar o tipo de PDN solicitada de acordo com os dados de assinatura para esse APN, conforme descrito em 3GPP TS 23.401 V15.0.0 cláusula 5.3.1.1. A MME deve definir a flag de transportador de endereço duplo quando o tipo de PDN é definido para IPv4v6 e todos os SGSNs que o UE possam ter sido submetidos a handover são a versão 8 ou endereço duplo de suporte acima, que é determinado com base na pré-configuração do nó pelo operador. O tipo de protocolo através de S5/S8 é provido para o S-GW, cujo protocolo deve ser usado através da interface S5/S8.

[0116] As características de carregamento para a assinatura de PS e APN e individualmente assinados, assim como o modo de lidar com as características de carregamento e se enviá-las ou não para o P-GW é definido em 3GPP TS

32.251. A MME deve incluir referência de rastreamento, tipo de rastreamento, disparar ID, e a identidade OMC se S-GW e/ou rastreamento de P-GW estiverem ativados. A MME deve copiar a referência de rastreamento, o tipo de rastreamento e a identidade OMC das informações de rastreamento recebidas do Registro de Assinantes Domésticos (HLR) ou OMC.

[0117] A restrição máxima de APN denota a restrição mais rígida, conforme requerido por qualquer contexto de transportador já ativo. Se não há contextos de transportador já ativos, esse valor é definido para o tipo menos restritivo (vide cláusula 15.4 de 3GPP TS 23.060). Se o P-GW recebe a restrição máxima APN, então o P-GW deve verificar se o valor máximo de restrição APN não conflita com o valor de restrição APN associado com essa solicitação de contexto de transportador. Se não há conflito, a solicitação deve ser permitida, de outro modo, a solicitação deve ser rejeitada ao se enviar uma causa de erro apropriada para o UE.

[0118] Se a MME requer que o eNB verifique se as capabilidades de rádio UE são compatíveis com a configuração de rede (por exemplo, se o SRVCC ou suporte de frequência pelo UE corresponde ao da rede) para que sejam capaz de definir a indicação suportada de voz sobre IMS de sessão PS (vide 3GPP TS

23.401 V15.0.0 cláusula 4.3.5.8), então a MME pode enviar uma solicitação de correspondência de capabilidade de rádio UE para o eNB, conforme definido em 3GPP TS 23.401 V15.0.0 cláusula 5.3.14.

[0119] Etapa 13: O S-GW cria uma nova entrada em sua tabela de transportador EPS e envia uma mensagem de solicitação de criação de sessão (IMSI, MSISDN, APN, endereço S-GW para o UP, S-GW TEID do UP, S-GW TEID do

CP, tipo RAT ,QoS de transportador EPS padrão, tipo de PDN , endereço PDN, APN-AMBR assinada, identidade de transportador EPS, PCOs, indicação de handover, identidade ME, informações de localização de usuário(ECGI), Fuso Horário UE, informações CSG de usuário, indicação de suporte de relatório de mudança de informações MS, indicação de suporte de pausa de carregamento PDN, modo de seleção, características de carregamento, referência de rastreamento, tipo de rastreamento, disparar ID, identidade OMC, restrição máxima de APN, flag de transportador de endereço duplo, flag de transportador, rede de serviço) para o P-GW indicado pelo endereço P-GW recebido na etapa anterior. Após essa etapa, o S-GW armazena em buffer temporariamente quaisquer pacotes de enlace descendente que possa receber do P-GW sem enviar uma mensagem de notificação de dados de enlace descendente para a MME até que receba a mensagem de solicitação de modificação de transportador na etapa 23 abaixo. A MSISDN é incluída se recebida da MME.

[0120] Se o S-GW recebeu o indicador de conexão de PDN apenas de CP na etapa 12, o S-GW informa ao P-GW essas informações na solicitação de criação de sessão. O S-GW e o P-GW devem indicar o uso de CP apenas em seus Registros de Dados de Carregamento (CDRs).

[0121] O P-GWs não deve realizar quaisquer verificações de restrição de APN máxima se a solicitação de criação de transportador padrão inclui a APN de emergência.

[0122] Para o UEs vinculados de emergência, a IMSI é incluída se disponível e, se a IMSI não pode ser autenticada, então a IMSI dever ser marcada como não autenticada.

[0123] No caso de vinculação de handover, e se o P-GW detecta que os dados PS 3GPP desligados de UE mudaram de status, o P-GW deve indicar esse evento para o sistema de carregamento para carregamento online e offline.

[0124] Etapa 14: Se for implementado o PCC dinâmico e a indicação de handover não estiver presente, o P-GW realiza um procedimento de estabelecimento de sessão IP-CAN, conforme definido em 3GPP TS 23.203 e, desse modo, obtém as regras do padrão PCC para o UE. Isso pode levar ao estabelecimento de um número de transportadores dedicados em seguida aos procedimentos definidos em 3GPP TS 23.401 V15.0.0 cláusula 5.4.1 em associação com o estabelecimento do transportador padrão, que é descrita no Anexo F.

[0125] O endereço IMSI, APN, UE IP, informações de localização de usuário(ECGI), Fuso Horário UE, rede servidora, tipo de RAT, APN-AMBR, QoS de transportador EPS padrão, ETFTU (se o ETFTU não é provido significa que UE e/ou P-GW não suportam o formato de filtro TFT estendido) são providos para o PCRF pelo P-GW, se recebido pela mensagem anterior. As informações de localização de usuário e a Fuso Horário UE são usadas para carregamento baseado em localização. Para o UEs vinculados por emergência que são não autenticados, o P-GW provê a IMEI como a identidade UE em vez de IMSI, para o PCRF. Se o PCRF decide que a conexão PDN pode usar o formato de filtro TFT estendido, deve retornar ao indicador da Rede de Suporte de Modelo de Fluxo de Tráfego Estendido (ETFTN) para o P-GW para inclusão nas opções de configuração de protocolo que retornaram para o UE.

[0126] A PCRF pode modificar o APN-AMBR e os parâmetros QoS (ID de Qualidade de Classe de Serviço (QCI) eARP) associados à transportador padrão na resposta ao P-GW, conforme definido em 3GPP TS 23.203.

[0127] Se o PCC é configurado para suportar os serviços de emergência e se o PCC dinâmico for implementado, o PCRF, baseado na emergência APN, define as regras ARP das regras PCC para um valor que é reservado para serviços de emergência e a autorização das regras dinâmicas PCC, conforme descrito em

3GPP TS 23.203. Se o PCC não for implementado, o P-GW usa o ARP do transportador EPS de emergência padrão para qualquer transportador EPS de emergência dedicado potencialmente iniciado. O P-GW determina que os serviços de emergência são solicitados baseados no APN de emergência recebido na mensagem de solicitação de criação de sessão. - NOTA 10: Enquanto a Função de Execução de Política e Carregamento P- GW/ (PCEF) pode ser configurada para ativar as regras PCC predefinidas para o transportador padrão, a interação com a PCRF ainda é requerida para prover, por exemplo, as informações de endereço IP UE padrão para a PCRF. - NOTA 11: Se o endereço não estiver disponível quando o P-GW realizar o procedimento de estabelecimento da sessão IP-CAN com a PCRF, o P-GW inicia um procedimento de modificação de sessão IP-CAN para informar a PCRF sobre um endereço IP alocado assim que o endereço estiver disponível. Nessa versão do relatório descritivo, isso é aplicável apenas à alocação de endereço IPv4.

[0128] Se o PCC dinâmico é implantado e a indicação de handover está presente, o P-GW executa um procedimento de modificação de sessão PCEF iniciada por IP-CAN com a PCRF conforme especificado em 3GPP TS 23.203 para relatar o novo tipo de IP-CAN. Dependendo das regras ativas de PCC , o estabelecimento de transportadores dedicados para o UE pode ser requerido. O estabelecimento desses transportadores deve ocorrer em combinação com a ativação de transportador padrão, conforme descrito no Anexo F. Esse procedimento pode continuar sem esperar uma resposta de PCRF. Caso sejam requeridas mudanças para as regras de PCC ativas, a PCRF pode provê-las após o procedimento de handover ter sido concluído.

[0129] Em ambos os casos (a indicação de handover estar presente ou não), se o PCC dinâmico não está implantado, o P-GW pode aplicar a política de QoS local. Isso pode levar ao estabelecimento de uma série de transportadores dedicados para o UE seguindo os procedimentos definidos em 3GPP TS 23.401 V15.0.0 cláusula 5.4.1 em combinação com o estabelecimento do transportador padrão, que é descrito no Anexo F.

[0130] Se os disparos de relatório de informações CSG são recebidos do PCRF, o P-GW deve definir, por conseguinte, a ação do relatório de informações.

[0131] O comportamento adicional do P-GW para os dados PS 3GPP desligados é definido em 3GPP TS 23.203.

[0132] Etapa 15: O P-GW cria uma nova entrada em sua tabela de contexto de transportador EPS e gera um ID de carregamento para o transportador padrão. A nova entrada permite que o P-GW faça o roteamento do UP PDUs entre o S-GW e a rede de dados de pacote e inicie o carregamento. O modo com que o P-GW manipula as características de carregamento que possa ter recebido é definido em 3GPP TS 32.251.

[0133] O P-GW retorna uma resposta de criação de sessão (endereço P- GW para o UP, P-GW TEID do UP, P-GW TEID do CP, tipo de PDN, endereço PDN , identidade de transportador EPS, QoS de transportador EPS, PCOs, ID de carregamento, compressão de carga útil proibida, restrição APN, causa, ação de relatório de mudança de informações MS (início) (se o P-GW decide receber as informações de localização dos UE's durante a sessão), ação de relatório de informações CSG (início) (se o P-GW decide receber as informações CSG do usuário das UE's durante a sessão), ação de área de relatório de presença (se o P-GW decide receber as notificações sobre uma mudança na presença de UE na área de relato de presença), mensagem de indicação habilitada de pausa de carregamento PDN (se o P-GW escolheu habilitar a função), APN-AMBR, conexão Tolerante a atraso para o S-GW.

[0134] O P-GW considera o tipo de PDN recebido, a flag de transportador de endereço duplo e as políticas do operador quando o P-GW seleciona o tipo de PDN a ser usado como a seguir. Se o tipo de PDN recebido é IPv4v6 e tanto o endereçamento IPv4 quanto IPv6 são possíveis no PDN, mas a flag de transportador de endereço duplo não está definido, ou apenas um endereçamento de versão IP única IP para esse APN é possível no PDN, o P-GW seleciona uma única versão IP (ou IPv4 ou IPv6). Se o tipo de PDN recebido é IPv4 ou IPv6 ou “não IP,” o P-GW usa o tipo de PDN recebido se for suportado no PDN, de outro modo uma causa de erro apropriada será retornada. Para IPv4, IPv6 e IPv4v6, o P-GW aloca um endereço de PDN de acordo com um tipo de PDN selecionado. Se o P-GW selecionou um tipo de PDN diferente do tipo PDN recebido, o P-GW indica juntamente com o tipo IE de PDN uma causa do motivo para o UE por que o tipo de PDN foi modificado, conforme descrito em 3GPP TS

23.401 V15.0.0 cláusula 5.3.1.1. O P-GW deve ou aceitar ou rejeitar (mas não modificar) o tipo de PDN se o tipo de PDN é definido para “não IP.” O endereço PDN pode conter um endereço IPv4 para IPv4 e/ou um prefixo IPv6 e uma interface ID, ou ser omitido para o tipo PDN “não IP.” Se o PDN foi configurado pelo operador de modo que os endereços PDN para a APN solicitada sejam alocados por meio da utilização apenas de DHCPv4, ou se o P-GW permite que o UE use DHCPv4 para alocação de endereço de acordo com a preferência da alocação de endereço recebido do UE, o endereço PDN deve ser definido para

0.0.0.0, indicando que o endereço IPv4 PDN deve ser negociado pelo UE com DHCPv4 após a conclusão do procedimento de ativação de transportador padrão. Para um endereçamento externo PDN para IPv6, o P-GW obtém o prefixo IPv6 do PDN externo usando ou a função do cliente de RADIUS ou diameter. No campo de endereço PDN da resposta de criação de sessão, o P-GW inclui a ID de interface e o prefixo IPv6. O P-GW envia aviso do roteador para o UE após o estabelecimento de transportador padrão com as informações de prefixo IPv6 para todos os casos.

[0135] Se o endereço PDN estiver contido na solicitação de criação de sessão, o P-GW deve alocar o endereço IPv4 e/ou prefixo IPv6 contido no endereço PDN para o UE. Os detalhes da alocação de endereço IP são descritos em 3GPP TS 23.401 V15.0.0 cláusula 5.3.1 em “Alocação de endereço IP.” The P-GW deriva o BCM baseado no NRSU e política do operador. O P-GW deriva se o formato de filtro TFT estendido for usado baseado no ETFTU, ETFTN recebido de PCRF, e política do operador. Os PCOs contêm o Modo de Controle de Transportador (BCM), ETFTN, assim como parâmetros PDN opcionais que o P- GW pode transferir para o UE. Esses parâmetros opcionais PDN podem ser solicitados pelo UE, ou podem ser enviados sem solicitação pelo P-GW. Opções de configuração de protocolo são enviadas transparentemente através da MME.

[0136] O P-GW inclui uma indicação de conexão Tolerante a atraso indicação se o P-GW suporta receber uma causa de rejeição do S-GW indicando que o UE não é temporariamente alcançável devido a procedimentos de finalização de retenção e economia de energia de terminais móveis, até que o P-GW receba a mensagem indicando que o UE é disponível para sinalização de extremidade a extremidade.

[0137] Quando a indicação de handover está presente, o P-GW não envia ainda os pacotes de enlace descendente para o S-GW; o trajeto de enlace descendente vai ser comutado na etapa 23A.

[0138] Se o P-GW for um L-GW, não encaminha os pacotes de enlace descendente para o S-GW. Os pacotes só serão encaminhados para o HeNB na etapa 20 via o trajeto de UP direto.

[0139] Etapa 16: The S-GW retorna uma mensagem de resposta de criação de sessão (tipo de PDN , endereço de PDN , endereço S-GW para UP, S-GW TEID para S1-U UP, S-GW TEID para CP, Identidade de transportador EPS, QoS de transportador EPS, Endereços P-GW e TEIDs ( S5/S8 baseado em GTP) ou chaves

GRE ( S5/S8 baseado em PMIP) no P-GW(s) para tráfego de enlace ascendente, PCOs, compressão de carga útil proibida, restrição APN , causa, ação de relatório de mudança de informações MS (início), ação de área de relatório de presença, ação de relatório de informações CSG (início), APN-AMBR, conexão Tolerante a atraso) para a nova MME. Para otimização CP CIoT EPS, o endereço S-GW para S11-U UP e S-GW TEID são usados pela MME para encaminhar dados de enlace ascendente para o S-GW. Se o status de dados PS 3GPP desligados (3GPP PS Data off) de UE estavam presentes na solicitação de criação de sessão PCO e o P-GW suporta o recurso de dados PS 3GPP desligados, o P-GW deve incluir a indicação de suporte de dados PS 3GPP desligados na resposta de criação de sessão PCO.

[0140] Etapa 17: Se uma restrição de APN for recebida, então a MME deve armazenar esse valor para o contexto de transportador e a MME deve verificar esse valor recebido com o valor armazenado para a restrição APN máxima para garantir que não haja conflito entre valores. Se o contexto de transportador é aceito, a MME deve determinar um (novo) valor para a restrição APN máxima. Se não há valor previamente armazenado para a restrição APN máxima, então a restrição APN máxima deve ser definida para o valor da restrição APN recebida. A MME não deve desativar transportador(es) com Prioridade de Alocação e Retenção de emergência (ARP), se estiver presente, para manter a combinação da restrição APN válida.

[0141] O P-GW deve ignorar a restrição APN máxima se a solicitação inclui o APN de emergência.

[0142] Se a ação de relatório de mudança de informação MS (início) e/ou a ação de relato de informações CSG (início) são recebidas para esse contexto de transportador, então a MME deve armazenar isso para o contexto de transportador e a MME deve reportar para esse P-GW via o S-GW sempre que uma localização de UE's e/ou mudança de informações CSG ocorrer que atenda à solicitação P-GW, conforme descrito na cláusula 15.1.1a de 3GPP TS 23.060. Se a ação de área de relatório de presença for recebida para esse contexto de transportador, a MME deve armazenar essas informações para o contexto de transportador e deve relatar para esse P-GW via o S-GW sempre que uma mudança da presença de UE em uma área de relato da presença for detectada, conforme descrito em 3GPP TS 23.401 V15.0.0 cláusula 5.9.2.2.

[0143] A MME determina o UE AMBR a ser usado pelo eNB baseado no UE- AMBR assinado e o APN-AMBR para o padrão APN, vide 3GPP TS 23.401 V15.0.0 cláusula 4.7.3.

[0144] Para vinculação de emergência, a MME determina o UE-AMBR a ser usado pelo eNB do APN AMBR recebido de S-GW.

[0145] Se uma nova MME não tiver recebido, da etapa 12, o indicador de correspondência de suporte de voz para o UE do eNB, então, baseado em implementação, a MME pode definir a indicação suportada de voz sobre IMS de sessão PS e atualizá-la em um estágio posterior.

[0146] A nova MME envia uma mensagem de aceitação de vinculação (GUTI, lista TAI , solicitação de gerenciamento de sessão (APN, tipo de PDN, endereço de PDN, Identidade de transportador EPS, PCOs, configuração de compressão de cabeçalho , indicador apenas de CP), número de sequência NAS, NAS-MAC, indicação suportada de voz sobre IMS de sessão PS, indicador de suporte de serviço de emergência, indicação de suporte de Serviço de Localização (LCS), comportamento de rede suportada, gap de serviço) para o eNB. GUTI é incluído se a nova MME aloca um novo GUTI. O tipo de PDN e o endereço de PDN são omitidos se a solicitação de vinculação (etapa 1) não continha um contêiner de mensagem de ESM. A MME indica as otimizações CIoT EPS que aceita nas informações de comportamento de rede suportada,

conforme definido em 3GPP TS 23.401 V15.0.0 cláusula 4.3.5.10. O parâmetro de gap de serviço é incluído se o gap de serviço está presente nas informações de assinatura (etapa 11) e o UE indicou a capabilidade de gap de serviço na capabilidade de rede UE. Essa mensagem está contida em uma solicitação de preparação de contexto inicial de mensagem de controle S1_MME, a menos que a MME tenha selecionado usar a otimização CP CIoT EPS, ou o UE não incluiu o contêiner de mensagem ESM na solicitação de vinculação (etapa 1), em cujo caso uma mensagem de transporte de enlace descendente NAS S1-AP é usada. A mensagem de solicitação de preparação de contexto inicial S1-AP também inclui as informações de contexto de segurança AS para o UE, a lista de restrição de handover, o QoS de transportador EPS , a identidade de transportador UE- AMBR, EPS, assim como o TEID no S-GW usado para o UP e o endereço do S-GW para UP e se a otimização de UP CIoT EPS é permitida para o UE. Se o tipo de PDN é definido para “não IP”, a MME inclui na solicitação de preparação de contexto S1-AP inicial, de modo que o eNB desabilite a compressão de cabeçalho. Além disso, se a conexão PDN for estabelecida para LIPA, a mensagem inicial de solicitação de preparação de contexto correspondente S1 inclui uma correlação ID para habilitar o trajeto direto de U entre o HeNB e o L- GW. Se a conexão PDN for estabelecida para descarregamento de tráfego IP Selecionado (SIPTO) na rede local com uma função L-GW justaposta com o (H)eNB, a mensagem de solicitação de preparação de contexto inicial S1-AP inclui uma ID de correlação SIPTO para habilitar o trajeto UP direto entre o (H)eNB e o L-GW. LIPA e SIPTO não se aplicam à otimização CP CIoT EPS. - NOTA 12: Nessa versão da especificação 3GPP, o ID de correlação e SIPTOID de correlação é definido igual para o UP P-GW TEID (S5 baseado em GTP) ou chave GRE (S5 baseado em PMIP) que a MME recebeu na etapa 16.

[0147] Se a otimização CP CIoT EPS se aplica para uma conexão IP PDN e o

UE enviou, na solicitação de vinculação, a configuração de compressão de cabeçalho, e a MME suporta os parâmetros de compressão de cabeçalho, a MME deve incluir a configuração de compressão de cabeçalho na mensagem de aceitação de conectividade PDN. A MME também vincula os canais de enlace ascendente e descendente ROHC para suportar a sinalização de feedback de compressão de cabeçalho. Se o UE incluiu os parâmetros de preparação de contexto de compressão de cabeçalho na configuração de compressão de cabeçalho na solicitação de vinculação, a MME pode reconhecer os parâmetros de preparação de contexto de compressão de cabeçalho. Se o contexto ROHC não é estabelecido durante o procedimento de vinculação para a conexão PDN, antes de usar o formato comprimido para enviar os dados, o UE e a MME precisam estabelecer o contexto ROHC com o pacote ROHC IR baseado em configuração de compressão de cabeçalho.

[0148] Se a MME baseada em política local determina que a conexão PDN só deve usar a otimização CP CIoT EPS, a MME deve incluir um indicador apenas de CP na solicitação de gerenciamento de sessão. Para as conexões PDN com um SCEF, a MME deve sempre incluir o indicador apenas de CP. Um UE que recebe o indicador apenas de CP para uma conexão PDN deve apenas usar a otimização de CP CIoT EPS para essa conexão PDN.

[0149] Se o contêiner ESM não foi incluído na solicitação de vinculação na etapa 1, então a mensagem de aceitação de vinculação não deve incluir parâmetros relacionados a PDN, e a mensagem de transferência de enlace descendente de NAS S1-AP não deve incluir informações relacionadas ao contexto AS, mas pode incluir informações relacionadas a CSG.

[0150] Se o tipo de vinculação não for definido para “emergência,” e o contêiner ESM foi incluído na solicitação de vinculação na etapa 1, e o suporte indicado de UE de vinculação sem conexão PDN na solicitação de vinculação, e a

MME suporta a vinculação sem conexão PDN, e a restrição de conexão PDN é definida nos dados do assinante, então a MME deve descartar o contêiner ESM na solicitação de mensagem de vinculação, e não deve incluir parâmetros relacionados a PDN na aceitação de vinculação, mas pode incluir informações relacionadas a CSG.

[0151] Na mensagem de aceitação de vinculação, a MME não inclui o prefixo IPv6 dentro do endereço PDN. A MME inclui o QCI do parâmetro QoS do transportador EPS e o APN-AMBR na solicitação de gerenciamento de sessão. Além disso, se o UE tem as capabilidades UTRAN ou GERAN e a rede suporta a mobilidade para UTRAN ou GERAN, a MME usa as informações QoS do transportador EPS para derivar os correspondentes parâmetros de contexto de Protocolo de Dados de Pacote (PDP) negociados QoS (perfil R99 QoS), prioridade de rádio, ID de fluxo de pacote e Identificador de Transação (TI) e os inclui na solicitação de gerenciamento de sessão. Se o UE indicado na capabilidade de rede UE não suporta os procedimentos de fluxo de pacote do Sistema de Estação base (BSS), então a MME não deve incluir o ID de fluxo de pacote. A lista de restrição de handover é descrita em 3GPP TS 23.401 V15.0.0 cláusula 4.3.5.7 “restrições de mobilidade.” A MME define a indicação suportada de voz sobre IMS de sessão PS, conforme descrito em 3GPP TS 23.401 V15.0.0 cláusula 4.3.5.8. A indicação de suporte LCS indica se a rede suporta a Solicitação de Localização (LR)MO do Núcleo de Pacote Evoluído (EPC) e/ou Comutado por Circuito (CS) MO-LR, conforme descrito em 3GPP TS 23.271. A MME pode incluir uma indicação se é permitido que o tráfego dessa conexão PDN seja descarregado para WLAN, conforme descrito em 3GPP TS 23.401 V15.0.0 cláusula 4.3.23.

[0152] Se o UE inicia o procedimento de vinculação em uma célula híbrida, a MME deve verificar se o ID CSG está contido na assinatura CSG assinatura e não expirou. A MME deve enviar uma indicação se o UE é um membro da CSG para a Rede de Acesso via Rádio (RAN) juntamente com a mensagem de controle S1-MME. Baseado nessas informações, a RAN pode realizar tratamento diferenciado para os membros e não membros CSG e-CSG.

[0153] Se a MME ou P-GW mudou o tipo PDN, uma apropriada causa do motivo deve ser retornada para o UE, conforme descrito em 3GPP TS 23.401 V15.0.0 cláusula 5.3.1.1. Se o UE indicou o tipo PDN “não IP,” a MME e o P-GW não devem mudar o tipo PDN.

[0154] Para um UE vinculado de emergência, por exemplo para os UEs que têm apenas transportadores EPS estabelecidos, não há informações de contexto de segurança AS incluídas nas mensagens de controle S1 e não há nenhuma segurança de nível NAS quando o UE não pode ser autenticado. O indicador de suporte de serviço de emergência informa ao UE que os serviços de transportador de emergência são suportados, por exemplo é permitido que o UE solicite a conectividade PDN para serviços de emergência.

[0155] Se o UE incluiu estendeu o elemento de informações de parâmetros DRX do modo ocioso, o UE inclui o elemento de informações de parâmetros DRX no modo ocioso estendido se decide habilitar o DRX do modo ocioso estendido.

[0156] Se o UE incluiu suporte para restrição de uso de cobertura aperfeiçoada, a MME envia parâmetro restrito de cobertura aperfeiçoada para o eNB na mensagem de solicitação de preparação de contexto inicial S1-AP. A MME também envia parâmetro restrito de cobertura aperfeiçoada para o UE na mensagem de aceitação de vinculação.

[0157] Etapa 18: Se o eNB recebeu uma solicitação de preparação de contexto inicial S1-AP, o eNB envia a mensagem de reconfiguração de conexão RRC incluindo a identidade do transportador de rádio EPS para o UE, e a mensagem de aceitação de vinculação ou similar será enviada juntamente para o UE. Em algumas modalidades, o parâmetro de gap de serviço (c.f etapas 11 e

17) é compreendido pela mensagem de reconfiguração da conexão RRC e/ou pela mensagem de aceitação de vinculação.

[0158] Se o eNB recebeu uma mensagem de transporte NAS de enlace descendente S1-AP (por exemplo, contendo a mensagem de aceitação de vinculação), o eNB envia uma mensagem de transferência de RRC direta para o UE. Em algumas modalidades, o parâmetro de gap de serviço (c.f etapas 11 e 17) é compreendido pela mensagem de transferência direta de RRC.

[0159] O UE deve armazenar o QoS negociado, a prioridade de rádio, o ID e TI de fluxo de pacote que recebeu na solicitação de gerenciamento de sessão, para uso ao acessar via GERAN ou UTRAN. O APN é provido para o UE para notificá-lo do APN para o qual o transportador padrão ativado é associado. Para maiores detalhes, veja 3GPP TS 36.331. O UE pode prover parâmetros QoS de transportador EPS para o handling de aplicações do fluxo de tráfego O uso da aplicação QoS do transportador EPS depende da implementação. O UE não deve rejeitar a reconfiguração da conexão RRC com base nos parâmetros QoS do transportador EPS contidos na solicitação de gerenciamento de sessão.

[0160] Se o UE recebe o parâmetro restrito de cobertura aperfeiçoada na mensagem de aceitação de vinculação ou similar, o UE deve armazenar essas informações e deve usar o valor do parâmetro restrito de cobertura aperfeiçoada para determinar se o recurso de cobertura aperfeiçoada deve ser usado ou não. Se o UE recebe uma gap de serviço na mensagem de aceitação de vinculação ou similar, o UE deve armazenar esse parâmetro e aplicar controle de gap de serviço para as solicitações de conexão de dados MO (vide cláusula

4.3.x abaixo).

[0161] Se o procedimento de vinculação é iniciado por meio da seleção manual CSG e ocorre via uma célula CSG, o UE, ao receber a aceitação de vinculação, deve verificar se a ID CSG e associada PLMN da célula para onde o

UE enviou a mensagem de solicitação de vinculação está contida nessa lista permitida de CSG. Se o ID CSG e o PLMN associado não estão na lista CSG permitida nos UE's, o UE deve acrescentar ID CSG e associada PLMN à sua lista CSG permitida. A seleção manual de CSG não é suportada quando um serviço de emergência foi iniciado. - NOTA 13: Se o UE recebe uma mensagem de aceitação de vinculação via uma célula híbrida, o UE não adiciona o correspondente ID CSG e associada PLMN à sua lista CSG permitida. O acréscimo de um ID CSG e associada PLMN à lista CSG permitida local de UE’s para uma célula híbrida é realizado apenas pelos procedimentos de gerenciamento de dispositivo (DM) Pelo Ar (OTA) ou Aliança Móvel Aberta (OMA).

[0162] Ao receber a mensagem de aceitação de vinculação, o UE deve definir seu TIN para “GUTI”, uma vez que nenhum ISR ativado é indicado.

[0163] Se o UE recebe um endereço IPv4 definido para 0.0.0.0, pode negociar o endereço IPv4 com DHCPv4, conforme especificado em 3GPP TS

29.061. Se o UE recebe uma interface ID IPv6, pode esperar o anúncio do roteador com as informações de prefixo IPv6 ou pode enviar uma solicitação de roteador, se necessário. - NOTA 14: Os detalhes da alocação de endereço IP são descritos em 3GPP TS 23.401 V15.0.0 cláusula 5.3.1 na “Alocação de endereço IP”.

[0164] Se a otimização CP CIoT EPS se aplica ou o UE não incluiu o contêiner de mensagem ESM na solicitação de vinculação na etapa 1, então as etapas 19 e 20 não são executadas.

[0165] Etapa 19: O UE envia a mensagem de conclusão de reconfiguração da conexão RRC para o eNB. Para maiores detalhes, vide 3GPP TS 36.331.

[0166] Etapa 20: O eNB envia a mensagem de resposta de contexto inicial para o nova MME. Essa mensagem de resposta de contexto inicial inclui o TEID do eNB e o endereço do eNB usado para tráfego de enlace descendente no ponto de referência S1_U.

[0167] A MME deve ser preparada para receber essa mensagem ou antes ou após vincular a mensagem completa (enviada na etapa 22).

[0168] Se a correlação ID ou a correlação ID de SIPTO foi incluída na mensagem inicial de solicitação de preparação de contexto, o eNB deve usar as informações incluídas para estabelecer o trajeto de UP direto com os dados L- GW e enviar os dados de enlace ascendente para o acesso IP local ou SIPTO na rede local com a função L-GW justaposta, de modo correspondente, com o (H)eNB.

[0169] Etapa 21: O UE envia uma mensagem de transferência direta para o eNB, que inclui a mensagem de conclusão de vinculação (Identidade de transportador EPS, número de sequência NAS, NAS-MAC. Se o UE omitiu o contêiner de mensagem ESM da mensagem de solicitação de vinculação na etapa 1, então a Identidade transportador EPS é omitida da mensagem de conclusão de vinculação.

[0170] Etapa 22: O eNB encaminha a mensagem de conclusão de vinculação para a nova MME em uma mensagem de transporte NAS de enlace ascendente.

[0171] Se o contêiner de mensagem ESM foi incluído na etapa 1, após a mensagem de aceitação de vinculação e uma vez que o UE obteve (se aplicável ao tipo PDN ) um endereço PDN, o UE pode, então, enviar os pacotes de enlace ascendente em direção ao eNB que serão, então, tunelizados para o S-GW e P- GW. Se as otimizações CP CIoT EPS se aplicam, os dados de enlace ascendente são enviados conforme especificado em 3GPP TS 23.401 V15.0.0 cláusula 5.3.4B. Se o UE solicitou um endereço duplo do tipo PDN (IPv4v6) para um determinado APN e foi concedido um único endereço do tipo PDN (IPv4 ou IPv6) pela rede com uma causa do motivo indicando que é permitido enviar apenas uma versão única IP por conexão PDN juntamente com o tipo PDN, o UE deve solicitar a ativação de uma conexão PDN paralela para o mesmo APN com um único endereço do tipo PDN (IPv4 ou IPv6) diferente do que já foi ativado. Se o UE não recebe causa do motivo na etapa 18 em resposta a um IPv4v6 do tipo PDN e recebe uma interface IPv6 ID à parte o endereço IPv4 ou 0.0.0.0 no campo de endereço PDN, este considera que a solicitação para um endereço duplo PDN foi bem-sucedida. Pode esperar pelo aviso do roteador da rede com as informações do prefixo IPv6 ou pode enviar a solicitação do roteador, se necessário.

[0172] Etapa 23: Ao receber tanto a mensagem de resposta de contexto inicial na etapa 20 quanto as mensagens de conclusão de vinculação na etapa 22, a nova MME envia uma mensagem de solicitação de modificação de transportador (identidade de transportador EPS, endereço eNB, eNB TEID, indicação de handover, informações de área de relatório de presença ) para o S- GW. Se a otimização de CP CIoT EPS se aplica e a conexão PDN não é servida por um SCEF, e se a MME não precisa relatar uma mudança da presença de UE na Área de Relatório de Presença (PRA), pula-se o envio de solicitação de modificação de transportador e pulam-se as etapas 23A, 23B, e 24; de outro modo, se a conexão PDN é servida por SCEF, as etapas 23, 24, 25 e 26 não são executadas. Se a MME foi solicitada para relatar uma mudança da presença de UE em PRA, a MME inclui nessa mensagem as informações PRA que compreendem o(s) identificador(es) e a(s) indicação(s) PRA se o UE está dentro ou fora da(s) área(s). Ao receber a solicitação para relatar a mudança da presença de UE em PRA, e a MME decide não ativar o relato da presença de UE em um ou mais do(s) PRA(s) recebido(s), a MME relata também o(s) PRA(s) inativo(s) nessa mensagem.

[0173] Etapa 23A: Se a indicação de handover é incluída na etapa 23, o S-

GW envia uma mensagem de solicitação de modificação de transportador (indicação de handover)para o P-GW para levar o P-GW a tunelizar pacotes de acesso não 3GPP IP para sistema de acesso 3GPP e imediatamente iniciar os pacotes de roteamento para o S-GW para o transportador padrão e quaisquer transportadores dedicados EPS estabelecidas. Se as informações PRA estiverem incluídas na etapa 23, o S-GW envia uma mensagem de solicitação de modificação de transportador (informações PRA) para o P-GW. - NOTA 15: Espera-se que o P-GW lide com os pacotes de enlace ascendente enviados pelo UE via acesso 3GPP após a etapa 22, mesmo se chegarem antes da troca de caminho na etapa 23. - NOTA 16: O P-GW encaminha as informações PRA para o PCRF, para o Sistema de Carregamento Online (OCS) ou para ambos, conforme definido em 3GPP TS 23.203.

[0174] Etapa 23B: O P-GW reconhece ao enviar a Resposta de modificação de transportador para o S-GW.

[0175] Etapa 24: O S-GW reconhece ao enviar a resposta de mensagem de modificação do transportador (identidade de transportador EPS para a nova MME. O S-GW pode, então, enviar seus pacotes de enlace descendente armazenados em buffer.

[0176] Se há um evento de monitoração de “disponibilidade após falha de DDN” ou um evento de monitoração de “alcançabilidade de UE” configurado para o UE no contexto EPS MM (EMM) de MME, a MME envia uma notificação de evento (vide TS 23.682 para maiores informações).

[0177] Etapa 25: Após a MME receber a mensagem de resposta de modificação do transportador (Identidade de transportador EPS), se o tipo de solicitação não indica handover e um transportador EPS foi estabelecido e os dados de assinatura indicam que é permitido ao usuário realizar handover para os acessos não 3GPP, e se a MME selecionou um P-GW que é diferente da Identidade P-GW que foi indicada pelo HSS no contexto de assinatura PDN, a MME deve enviar uma solicitação de notificação incluindo a identidade APN e Identidade P-GW para o HSS para mobilidade com os acessos não 3GPP. A mensagem deve incluir informações que identificam o PLMN no qual o P-GW é localizado.

[0178] Se a identidade ME do UE mudou e a etapa 8 não foi realizada, a MME envia uma mensagem de solicitação de notificação (identidade ME) para informar o HSS da identidade ME atualizada.

[0179] Para um UE não autenticado, ou em roaming, se o tipo de solicitação do UE que solicitou procedimento de conectividade indica “emergência”, a MME não deve enviar qualquer solicitação de notificação para uma HSS. Para um UE de não roaming, autenticado, baseado em configuração de operador (por exemplo, se a voz sobre WLAN é suportada ou não pelo operador, ou se o operador usa um P-GW fixo para chamadas de emergência, etc.,), se o tipo de solicitação indica “emergência,” a MME pode enviar uma solicitação de notificação para o HSS incluindo o “P-GW atualmente em uso para serviços de emergência,” que compreende o endereço P-GW e uma indicação que a conexão PDN é para serviços de emergência. O HSS deve armazená-lo como parte do contexto de UE para serviços de emergência.

[0180] Após a etapa 8, e em paralelo com qualquer uma das etapas precedentes, a MME deve enviar uma mensagem de solicitação de notificação (suporte homogêneo de voz sobre IMS de sessões PS) para o HSS: - Se a MME avaliou o suporte de voz sobre IMS de sessões PS, vide 3GPP TS

23.401 V15.0.0 cláusula 4.3.5.8, e - Se a MME determina que precisa atualizar o suporte homogêneo de voz sobre IMS de sessões PS vide 3GPP TS 23.401 V15.0.0 cláusula 4.3.5.8A.

[0181] Etapa 26: No caso de serviços de não emergência, o HSS armazena o APN e o par de identidade P-GW. No caso de serviços de emergência, o HSS armazena o “P-GW atualmente em uso para serviços de emergência.” O HSS então, envia uma resposta de notificação para a MME. - NOTA 17: Para handover de acesso não 3GPP, o P-GW inicia o procedimento de desativação de alocação de recurso no acesso não 3GPP confiável/não confiável, conforme especificado em 3GPP TS 23.402. O Procedimento TAU P com mudança S-GW - NOTA 1: Para um S5/S8 baseado em PMIP, as etapas de procedimento (A) e (B) são definidas em 3GPP TS 23.402. As etapas 9 e 10 referem-se a S5/S8 baseado em GTP. - NOTA 2: No caso de TAU sem mudança MME, pula-se a sinalização nas etapas 4, 5, 7 e etapas 12-17.

[0182] As Figuras 2A e 2B ilustram o procedimento TAU com mudança S- GW. As etapas ilustradas nas Figuras 2A-2B serão agora descritas. Todas as referências são para 3GPP TS 23.401 V15.0.0.

[0183] Etapa 1: Ocorre um dos disparos descritos no TS 23.401 V15.0.0 cláusula 5.3.3.0 para iniciar o procedimento TAU.

[0184] Etapa 2: O UE inicia o procedimento TAU ao enviar, para o eNB, uma mensagem de solicitação TAU (capabilidade de rede núcleo de UE, capabilidade de rede de MS, comportamento preferível de rede, suporte para restrição de uso de cobertura aperfeiçoada, GUTI antigo, tipo antigo de GUTI, TAI visitado por último, flag ativa, flag ativa de sinalização, status de transportador EPS, assinatura P-TMSI, GUTI adicional, ID de Conjunto de Chave Evoluído (eKSI), Número de sequência NAS, NAS-MAC, ID de conjunto de chave (KSI), preferência de domínio de voz e estabelecimento de uso dos UE's) juntamente com os parâmetros RRC que indicam a rede selecionada e o antigo

GUMMEI. Uma exceção é que, se o TAU foi disparado para fins de rebalanceamento de carga (consulte TS 23.401 V15.0.0 cláusula 4.3.7.3), o antigo GUMMEI não está incluído nos parâmetros RRC. O UE deve definir o antigo tipo GUTI tipo para indicar se o GUTI antigo é um GUTI nativo ou é mapeado de um P-TMSI e RAI.

[0185] Se o TIN dos UE's indica “GUTI” ou “TMSI relacionado com RAT” e o UE contém um GUTI válido, então o GUTI antigo indica esse GUTI válido. Se o TIN dos UE's indica “P-TMSI” e o UE contém um P-TMSI válido e RAI relacionado, então esses dois elementos são indicados como o GUTI antigo. O mapeamento de um P-TMSI e RAI para um GUTI é especificado no Anexo H. Quando o UE está no modo conectado (por exemplo, em URA_PCH) quando este resseleciona para E-UTRAN, o UE deve definir seu TIN para “P-TMSI.

[0186] Se o UE contém um GUTI válido e o GUTI antigo indica um GUTI mapeado de um P-TMSI e RAI, então o UE indica o GUTI como GUTI adicional. Se o GUTI antigo indica um GUTI mapeado de um P-TMSI e RAI, e o UE tem uma assinatura P-TMSI válida, a assinatura P-TMSI deve ser incluída.

[0187] O GUTI adicional na mensagem de solicitação TAU permite que a nova MME encontre qualquer contexto armazenado já existente na nova MME quando o GUTI antigo indica um valor mapeado de uma P-TMSI e RAI.

[0188] Alternativamente, quando um UE apenas suporta E-UTRAN, este se identifica com o GUTI antigo e define o antigo tipo GUTI como “nativo”.

[0189] O parâmetro RRC "antigo GUMMEI" tira seu valor do identificador que é sinalizado como o GUTI antigo de acordo com as regras acima. Para um combinado MME/SGSN, o eNB é configurado para fazer o roteamento do(s) código(s) MME desse nó combinado para o mesmo nó combinado. Esse eNB também é configurado para fazer o roteamento do(s) código(s) MME dos GUTIs que são gerados pelo mapeamento dos UEs dos P-TMSIs alocados pelo nó combinado. Tal configuração eNB pode também ser usada para separar nós para evitar a mudança de nós no agrupamento causado pela intermobilidade RAT.

[0190] O TAI visitado pela última vez deve ser incluído para ajudar a MME a produzir uma boa lista de TAIs para qualquer mensagem de aceitação TAU subsequente. A rede selecionada indica a rede que é selecionada. A flag ativa é uma solicitação pelo UE para ativar o rádio e os transportadores S1 para todos os transportadores ativos EPS pelo procedimento TAU quando o UE estiver em um estado ECM-OCIOSO. A sinalização da flag ativa é uma solicitação do UE usando a otimização CP CIoT EPS para manter a conexão de sinalização NAS depois que o procedimento TAU estiver concluído para transmitir dados pendentes usando o transporte de dados na otimização CP CIoT EPS ou na sinalização NAS. O status de transportador EPS indica cada transportador EPS que é ativo no UE. A mensagem de solicitação TAU deve ser protegida na integridade pelo NAS-MAC, conforme descrito em 3GPP TS 33.401. eKSI, número de sequência NAS e NAS-MAC são incluídos se UE tem parâmetros de segurança EPS válidos. O número de sequência NAS indica o número sequencial da mensagem NAS. KSI é incluído se o UE indica um GUTI mapeado de um P-TMSI no elemento de informações “GUTI antigo”.

[0191] Para o UE que usa a otimização CIoT EPS sem qualquer conexão PDN ativada não há flag ativa ou status de transportador EPS incluído na mensagem de solicitação TAU. Para um UE com um temporizador de gap de serviço em execução no UE, a flag ativa e a flag ativa de sinalização não devem ser definidos na mensagem de solicitação TAU (vide cláusula 4.3.x abaixo).

[0192] Se o UE tem conexão PDN do tipo PDN “"não IP,” o UE deve indicar o status de transportador EPS incluído na mensagem de solicitação TAU.

[0193] O UE estabelece a preferência de domínio de voz e o estabelecimento do uso dos UE's de acordo com sua configuração, conforme descrito em TS 23.401 V15.0.0 cláusula 4.3.5.9.

[0194] O UE inclui elemento de informações de parâmetros DRX de modo ocioso estendido se precisa habilitar o modo ocioso estendido DRX, mesmo se os parâmetros DRX do modo ocioso estendido já tiverem sido negociados antes.

[0195] Se um UE inclui um comportamento de rede preferido, isso define o comportamento de rede que o UE espera que esteja disponível na rede, conforme definido em TS 23.401 V15.0.0 cláusula 4.3.5.10.

[0196] Etapa 3: O eNB deriva o endereço MME dos parâmetros RRC que portam o antigo GUMMEI, a rede indicada selecionada e o RAT (NB-IoT ou WB- E-UTRAN). Se essa MME não estiver associada ao eNB ou o GUMMEI não estiver disponível ou o UE indicar que o procedimento TAU foi disparado por rebalanceamento de carga, o eNB seleciona uma MME conforme descrito em TS

23.401 V15.0.0 cláusula 4.3.8.3 em “função de seleção MME”.

[0197] O eNB encaminha a mensagem de solicitação de TAU juntamente com o modo de acesso CSG, CSG ID, TAI + ECGI da célula de onde recebeu a mensagem e com a rede selecionada para a nova MME. ID CSG é provido por RAN se o UE envia a mensagem de solicitação TAU via uma célula CSG ou uma célula híbrida. O modo de acesso CSG é provido se o UE envia a mensagem de solicitação TAU via uma célula híbrida. Se o modo de acesso CSG não é provido, mas o ID CSG ID é provido, a MME deve considerar a célula como uma célula CSG. Para SIPTO na rede local com arquitetura GW autônomo, o eNB inclui O ID da rede doméstica local na mensagem UE inicial e na mensagem de transporte NAS de enlace ascendente se a célula de destino estiver em uma rede doméstica local.

[0198] Para ajudar os serviços locais, o eNB indica o nível de cobertura dos UE's para a MME.

[0199] Etapa 4: A nova MME diferencia o tipo do nó antigo , por exemplo

MME ou SGSN, conforme especificado em TS 23.401 V15.0.0 cláusula 4.3.19, usa o GUTI recebido do UE para derivar o endereço antigo MME/S4 SGSN e envia uma mensagem de solicitação de contexto (GUTI antigo, mensagem de solicitação de conclusão de TAU, assinatura P-TMSI , endereço MME, UE validado, indicação de suporte de otimização CIoT EPS) para a antiga MME/antigo S4 SGSN para recuperar as informações do usuário. O UE validado indica que a nova MME validou a proteção de integridade da mensagem TAU, por exemplo baseado no contexto de segurança EPS nativo para o UE. Para validar a solicitação de contexto, a antiga MME usa a mensagem de solicitação de conclusão de TAU e o antigo S4 SGSN usa a assinatura P-TMSI e responde com um erro apropriado se a verificação de integridade falhar na antiga MME/antigo S4 SGSN. Isso deve iniciar as funções de segurança na nova MME. Se as funções de segurança autenticam o UE corretamente, a nova MME deve enviar uma solicitação de contexto (IMSI, mensagem de solicitação de conclusão de TAU, endereço MME, UE validado) para a antiga MME/antigo S4 SGSN com o UE validado definido. Se a nova MME indica que autenticou o UE ou se a antiga MME/antigo S4 SGSN validou corretamente o UE, então a antiga MME/antigo S4 SGSN iniciam um temporizador.

[0200] Se o UE com transportadores de emergência não for autenticado na antiga MME/antigo S4 SGSN (em uma rede que suporta UEs não autenticados), a antiga MME/antigo S4 SGSN continua o procedimento com o envio de uma resposta de contexto e inicia o temporizador também quando não pode validar a solicitação de contexto.

[0201] Se a nova MME suporta a otimização de CIoT EPS, a indicação de suporte de otimização CIoT EPS é incluída no suporte de indicação de solicitação de contexto para várias otimizações de CIoT EPS (por exemplo, suporte para compressão de cabeçalho para otimização de CP, etc.).

[0202] Etapa 5: Se a solicitação de contexto é enviada para uma antiga MME, a antiga MME responde com uma mensagem de resposta de contexto (IMSI, identidade ME (IMEISV), contexto MM, contexto(s) de transportador EPS, endereço de sinalização S-GW e TEID(s), Redução de Sinalização de Estado Ocioso (ISR) suportado, ação de relatório de mudança de informações MS (se disponível), ação de relatório de informações CSG (se disponível), Fuso Horário UE, capabilidade de rede núcleo de UE, mensagem de UE, parâmetros específicos DRX UE) Se a nova MME suporta a otimização de CIoT EPS e o uso da compressão de cabeçalho tiver sido negociado entre o UE e a antiga MME, a resposta de contexto também inclui a configuração de compressão de cabeçalho que inclui as informações necessárias para a configuração do canal ROHC, mas não o próprio contexto RoHC.

[0203] Se a solicitação de contexto é enviada para um antigo S4 SGSN, o antigo S4 SGSN responde com uma resposta de contexto (contexto MM, contexto(s) de transportador EPS, endereço de sinalização S-GW e TEID(s), ISR suportado, ação de relatório de mudança de informações MS (se disponível), ação de relatório de informações CSG (se disponível), Fuso Horário UE, capabilidade de suporte de rede UE, parâmetros DRX específicos de UE). Se a MME de origem ainda não tiver relatado um contador de dados de exceção MO para o P-GW, a resposta de contexto também inclui o contador de dados de exceção MO, conforme descrito, descrito em 3GPP TS 29.274.

[0204] o contexto MM contém informações relacionadas à segurança, assim como outros parâmetros (incluindo identidade IMSI e ME (se disponível)), conforme descrito em TS 23.401 V15.0.0 cláusula 5.7.2 (armazenamento de informações para MME). Os quintetos de autenticação não usados no contexto MM são também mantidos no SGSN. 3GPP TS 33.401 dá outros detalhes na transferência de informações relacionadas à segurança.

[0205] Se o contexto MM recebido com a mensagem de resposta de contexto não incluiu IMEISV e a MME ainda não armazenou o IMEISV do UE, a MME deve recuperar a identidade ME (IMEISV) do UE.

[0206] O endereço P-GW e TEID(s) (para S5/S8 baseado em GTP) ou chaves de Encapsulamento de Roteamento Genérico (GRE) ( S5/S8 baseado em PMIP no P-GW(s) para tráfego de enlace ascendente) e o(s) TI(s), é parte do contexto de transportador EPS. Se o UE não é conhecido na antiga MME/antigo S4 SGSN ou se a verificação de integridade para a mensagem de solicitação TAU falhar, a antiga MME/antigo S4 SGSN responde com uma causa de erro apropriada. A ISR suportada é indicada se a antiga MME/antigo S4 SGSN e S-GW associado são capazes de ativar a ISR para o UE.

[0207] Se o UE recebe os serviços de transportador de emergência da antiga MME/antigo S4 SGSN e o UE é desprovido de Cartão de Circuito Integrado Universal, o IMSI não pode ser incluído na resposta de contexto. Para o UEs vinculados de emergência, se o IMSI não pode ser autenticado, então o IMSI deve ser marcado como não autenticado. Também, nesse caso, os parâmetros de segurança são incluídos apenas se disponíveis.

[0208] Se SIPTO na rede local é ativo para uma conexão PDN na arquitetura com gateway autônomo, a antiga MME/antigo S4 SGSN deve incluir o ID da rede doméstica local da antiga célula no contexto de transportador EPS correspondente ao SIPTO na conexão PDN da rede local.

[0209] Para o UE que usa a otimização CIoT EPS sem qualquer conexão ativada PDN, não há contexto(s) de transportador EPS incluído na mensagem de resposta de contexto.

[0210] Baseado na indicação de suporte de otimização CIoT EPS, a antiga MME apenas transfere o(s) contexto(s) de transportador EPS que a nova MME suporta. Se a nova MME não suporta a otimização CIoT EPS, o(s) contexto(s) do transportador EPS da conexão PDN não IP não é transferido para a nova MME. Se o(s) contexto(s) do transportador EPS de uma conexão PDN não foi transferido, a antiga MME deve considerar todos os transportadores dessa conexão PDN como tendo falhado e liberar aquela conexão PDN ao disparar o procedimento MME de desconexão PDN solicitado especificado em TS 23.401 V15.0.0 cláusula 5.10.3. Os dados armazenados em buffer na antiga MME são descartados após o recebimento do contexto ACK.

[0211] Etapa 6: Se a verificação de integridade da mensagem de solicitação TAU (enviada na etapa 2) falhar, então a autenticação é mandatória. As funções da autenticação são definidas em TS 23.401 V15.0.0 cláusula 5.3.10 em “função de segurança.” Os procedimentos de cifragem são descritos em TS 23.401 V15.0.0 cláusula 5.3.10 em “função de segurança.” Se a alocação de GUTI vai ser feita e a rede suporta a cifragem, as mensagens NAS devem ser cifradas.

[0212] Se essa solicitação TAU é recebida para um UE que já está em estado ECM_CONECTADO e a PLMN-ID do TAI enviada pelo eNB na etapa 3 é diferente daquela da GUTI, incluída na mensagem de solicitação TAU, a MME deve atrasar a autenticação de UE até após a etapa 21 (mensagem de conclusão de TAU )). - NOTA 3: A MME atrasa a autenticação de modo tal que o UE primeiro atualiza seu PLMN-ID registrado para a nova PLMN-ID selecionada pelo RAN durante o handover. O novo PLMN- ID é provido pela MME para o UE como parte do GUTI na mensagem de aceitação TAU na etapa 20. O fato de fazer isso garante que o mesmo PLMN-ID seja usado na derivação da chave Kasme tanto pela rede quanto pelo UE.

[0213] Se a nova MME é configurada para permitir serviços de transportador de emergência para o UE não autenticado, a nova MME se comporta como a seguir: - quando um UE tem apenas serviços de transportador de emergência, a

MME ou pula o procedimento de autenticação e segurança ou aceita que a autenticação pode falhar e continua o procedimento TAU; ou - quando um UE tem tantos serviços de transportador de emergência e serviços de transportador de não emergência e a autenticação falha, a MME continua o procedimento TAU e desativa todas as conexões PDN de não emergência, conforme especificado em TS 23.401 V15.0.0 cláusula 5.10.3.

[0214] Etapa 7: A MME (se a MME mudou, então é a nova MME) determina relocar o S-GW. O S-GW é relocado quando o antigo S-GW não pode continuar a servir o UE. A MME (se a MME mudou, então é a nova MME) pode também decidir realocar o S-GW caso se espere que um novo S-GW sirva o UE por mais tempo e/ou com um UE mais ideal para o trajeto P-GW, ou se um novo S-GW pode ser justaposto ao P-GW. A seleção de um novo S-GW é realizada de acordo com TS 23.401 V15.0.0 cláusula 4.3.8.2 em “função de seleção S-GW”.

[0215] Se a MME mudou, a nova MME envia uma mensagem de ACK de contexto (indicação de mudança de S-GW) para a antiga MME/antigo S4 SGSN. A indicação de mudança S-GW indica que um novo S-GW foi selecionado. A antiga MME/antigo S4 SGSN marca em seu contexto de UE que as informações nos gateways são inválidas. E, se o antigo nó é uma MME, a antiga MME marca em seu contexto de UE que as informações no HSS são inválidas. Isso garante que a antiga MME/antigo S4 SGSN atualiza os gateways, e a antiga MME atualiza o HSS, se o UE inicia um procedimento TAU ou RAU de volta para a antiga MME/antigo S4 SGSN antes de concluir o procedimento TAU contínuo. - NOTA 4: A atualização dos gateways refere-se à exclusão da(s) sessão(ões) no S-GW seguido pela recriação da sessão(ões) no S-GW. A recriação da sessão(ões) no S-GW irá resultar no restabelecimento bem-sucedido do túnel S5/S8 entre o S-GW e o P-GW selecionado.

[0216] Se as funções de segurança não autenticam o UE corretamente,

então o TAU deverá ser rejeitado, e o nova MME irá enviar uma indicação de rejeição para a antiga MME/antigo S4 SGSN. A antiga MME/antigo S4 SGSN devem continuar como se a identificação e a solicitação de contexto nunca tenham sido recebidas.

[0217] ISR não é indicado no contexto ACK uma vez que ISR não é ativado devido à mudança de S-GW.

[0218] Para o UE que usa a otimização de CIoT EPS sem qualquer conexão PDN ativada, as etapas 8, 9, 10, 11, 18, e 19 são puladas.

[0219] Etapa 8: Se a MME mudou, a nova MME verifica o status de transportador EPS recebido do UE com os contextos do transportador recebidos da antiga MME/antigo S4 SGSN. Se a MME não mudou, a MME verifica o status de transportador EPS do UE com os contextos do transportador disponível no contexto MM. A MME libera quaisquer recursos de rede referentes às transportadores EPS que não estão ativos no UE. Se não há absolutamente nenhum contexto de transportador, a MME rejeita a solicitação TAU.

[0220] Se a MME selecionou um novo S-GW , esta envia uma mensagem de solicitação de criação de sessão (IMSI, contextos de transportadores, endereço de MME e TEID, tipo, o tipo de protocolo através de S5/S8, tipo de RAT, rede servidora, Fuso Horário UE, contador de dados de exceção de MO) por conexão de PDN para o novo S-GW selecionado. O endereço P-GW e TFT (para S5/S8 baseado em PMIP) são indicados nos contextos do transportador. Tipo indica para o S-GW enviar a solicitação de modificação de transportador para o P-GW. O tipo de protocolo através de S5/S8 é provido para o S-GW, cujo protocolo deve ser usado através da interface S5/S8. O tipo RAT indica uma mudança no Acesso via Rádio. Se é uma mobilidade de um SGSN para uma MME e se a MME suporta o relatório da mudança de informações de localização, a MME deve incluir as informações de localização de usuário(de acordo com a granularidade suportada) na solicitação de criação de sessão, independente de se o relatório de mudança de informações de localização foi solicitado no RAT anterior pelo P-GW. Se é uma MME de intermobilidade e se o P-GW solicitou relatório de mudança de localização, a MME inclui as informações de localização de usuário IE nessa mensagem se for diferente comparadas às informações previamente enviadas. Se o P-GW solicitou informações CSG do usuário, a MME também inclui as informações IE de CSG nessa mensagem. Se a otimização CP CIoT EPS se aplica, a MME pode também indicar o tunelamento S11-U dos dados do usuário NAS e enviar seu próprio endereço S11-U IP e TEID de enlace descendente de MME para dados de enlace descendente encaminhados pelo S- GW. A MME deve incluir o contador de dados de exceção MO se tiver recebido o contador para a causa RRC “dados de exceção MO” na mensagem de resposta de contexto.

[0221] Se apenas a otimização CP CIoT EPS é usada, a MME deve incluir um indicador de conexão PDN apenas de CP na solicitação de criação de sessão.

[0222] Se a nova MME recebe o contexto de transportador EPS com SCEF, então a nova MME atualiza o SCEF conforme definido em 3GPP TS 23.682.

[0223] Etapa 9: O S-GW informa o(s) P-GW(s) sobre a mudança, por exemplo, do tipo RAT que, por exemplo, pode ser usado para carregar, ao enviar a solicitação de modificação de transportador (endereço S-GW e TEID, tipo de RAT , rede servidora, indicação de suporte de pausa de carregamento PDN) por conexão de PDN ao P-GW(s) em questão. Informações de localização de usuário IE e/ou UE Fuso Horário IE e/ou informações de CSG do usuário IE e/ou contador de dados de exceção MO são também incluídos se estiverem presentes na etapa

8. O S-GW e P-GW indicam cada uso da causa de estabelecimento de RRC “dados de exceção MO” pelo contador relacionado em seu CDR.

[0224] Se o S-GW recebeu o indicador de conexão PDN apenas CP na etapa

8, o S-GW indica o uso de apenas CP em seu CDR.

[0225] Etapa 9A: Se for implantada a dinâmica PCC e as informações do tipo RAT precisam ser conduzidas do P-GW para o PCRF, então o P-GW deve enviar informações do tipo RAT para o PCRF por meio de um procedimento de modificação de sessão IP-CAN, conforme definido em 3GPP TS 23.203. - NOTA 5: O P-GW não precisa esperar pela resposta PCRF, mas continua na próxima etapa. Se a resposta de PCRF levar a uma modificação do transportador EPS, o P-GW deve iniciar um procedimento de atualização de transportador.

[0226] Etapa 10: O P-GW atualiza seus contextos de transportador e retorna uma mensagem de Resposta de modificação de transportador (MSISDN, ID de carregamento, indicação habilitada de pausa de carregamento PDN (se P- GW escolheu habilitar a função). A MSISDN é incluída se o P-GW a armazenou em seu contexto de UE. Se houve uma mudança RAT em direção ao E-UTRAN e o relatório de mudança de informações de localização é requerido e suportado na MME de destino, o P-GW deve prover a ação de relatório de mudança de informações MS na resposta modificação de transportador.

[0227] Se o S-GW é realocado, o P-GW deve enviar um ou mais “pacotes de marcador de extremidade” no antigo trajeto imediatamente após trocar o trajeto para ajudar na função de reordenação no eNB de destino. Se S-GW não tem UP de enlace descendente estabelecido, o S-GW deve descartar o “marcador de extremidade” recebido do P-GW e não deve enviar notificação de dados de enlace descendente. De outro modo, o S-GW deve encaminhar os pacotes de “marcador de extremidade” para a eNB de origem ou S4 SGSN de origem.

[0228] Etapa 11: O S-GW atualiza seu contexto de transportador. Isso permite que o S-GW faça o roteamento do transportador PDUs para o P-GW quando recebido de eNB.

[0229] O S-GW retorna uma mensagem de resposta de criação de sessão (endereço S-GW e TEID para UP e CP e P-GW TEIDs (para S5/S8 baseado em GTP) ou chaves GRE ( S5/S8 baseado em PMIP) para tráfego de enlace ascendente e CP, ação de relatório de mudança de informações MS) para a nova MME. Se a otimização CP CIoT EPS se aplica, o endereço S-GW para S11-U UP e S-GW TEID são usados pela MME para encaminhar dados de enlace ascendente para o S- GW.

[0230] Quando a MME recebe a mensagem de resposta de criação de sessão, a MME verifica se há um evento de monitoração de “disponibilidade após falha de Notificação de Dados de Enlace Descendente (DDN) ”ou um evento de monitoração de "Alcançabilidade de UE" configurado para o UE na MME , em tal caso, envia uma notificação de evento (vide 3GPP TS 23.682 para maiores informações).

[0231] Etapa 12: A nova MME verifica se contém dados de assinatura para o UE identificado pelo GUTI, o GUTI adicional ou pelo IMSI recebido com os dados de contexto do antigo nó de rede núcleo.

[0232] Caso não haja nenhum dado de assinatura na nova MME para esse UE, ou para algum cenário de compartilhamento de rede (por exemplo, GWCN) se o ID PLMN-do TAI suprido pelo eNB é diferente daquele do GUTI no contexto de UE's, então a nova MME envia uma solicitação de atualização de localização (Identidade MME, IMSI, flags ULR , capabilidades de MME, suporte homogêneo de voz sobre IMS de sessões PS, capabilidades UE SRVCC, lista PLMN equivalente, mensagem de identidade ME (IMEISV)) para o HSS. As flags ULR indicam que a atualização da localização é enviada de uma MME e o registro da MME deve ser atualizado em HSS. O HSS não cancela nenhum registro SGSN. As capabilidades de MME indicam o suporte das MMEs para a funcionalidade de restrições de acesso regional. A inclusão da lista de PLMN equivalente indica que a MME suporta o handover inter PLMN para uma célula CSG em um ePLMN usando as informações de assinatura do PLMN de destino. A indicação de “suporte homogêneo de voz sobre IMS de sessões PS” (vide TS 23.401 V15.0.0 cláusula 4.3.5.8A) não deve ser incluída, a menos que a MME tenha completado sua avaliação do suporte de “voz sobre IMS de sessão PS”, conforme especificado em TS 23.401 V15.0.0 cláusula 4.3.5.8. A identidade ME é incluída se a etapa 5 fez com que a MME recupere o IMEISV do UE. - NOTA 6: Nessa etapa, a MME pode não ter todas as informações necessárias para determinar o estabelecimento da indicação suportada de voz sobre IMS de sessão PS para esse UE (vide TS 23.401 V15.0.0 cláusula 4.3.5.8). Portanto, a MME pode enviar “o suporte homogêneo de voz sobre IMS de sessões PS” posteriormente neste procedimento.

[0233] Se UE inicia o procedimento TAU em um roaming CSG de suporte autônomo VPLMN e o HPLMN habilitou o roaming CSG no VPLMN (via contrato de nível de serviço) e a MME precisa recuperar as informações de assinatura CSG do UE do CSS, a MME inicia o procedimento de atualização da localização CSG com CSS conforme descrito em TS 23.401 V15.0.0 cláusula 5.3.12.

[0234] Se a MME determina que apenas as capabilidades UE SRVCC mudaram, a MME envia uma solicitação de notificação para o HSS para informar sobre a capabilidade de UE SRVCC mudada.

[0235] Se todos os transportadores EPS do UE têm valor de emergência ARP, a nova MME pode pular o procedimento de atualização de localização ou prosseguir mesmo se a atualização da localização falhar.

[0236] Etapa 13: O HSS envia a mensagem de cancelamento de localização (IMSI, tipo de cancelamento) para a antiga MME como o tipo de cancelamento definido para o procedimento de atualização.

[0237] Etapa 14: Se o temporizador iniciado na etapa 4 não estiver em execução, a antiga MME remove o contexto MM. De outro modo, os contextos são removidos quando o temporizador expira. Também garante que o contexto MM seja mantido na antiga MME para o caso de o UE iniciar outro procedimento TAU antes de concluir o procedimento contínuo TAU para a nova MME. A antiga MME reconhece com a mensagem de ACK de cancelamento de localização (IMSI).

[0238] Etapa 15: Quando o antigo S4 SGSN recebe a mensagem de Reconhecimento de contexto e se o UE está CONECTADO em lu, o antigo S4 SGSN envia uma mensagem de comando de liberação lu para o RNC após o temporizador que iniciou na etapa 4 expirar.

[0239] Etapa 16: O RNC responde com uma mensagem de conclusão de liberação de lu.

[0240] Etapa 17: O HSS reconhece a mensagem de solicitação de atualização de localização ao enviar uma mensagem de ACK de atualização de localização (IMSI, dados de assinatura) para a nova MME. Os dados de assinatura podem conter os dados de assinatura CSG para a PLMN registrado e para a lista de PLMN equivalente solicitada por MME na etapa 12.

[0241] Os dados de assinatura podem conter parâmetros restritos de cobertura aperfeiçoada. Se recebido do HSS, a MME armazena esse parâmetro restrito de cobertura aperfeiçoada no contexto MME MM.

[0242] Os dados de assinatura podem conter parâmetro de gap de serviço. Se recebido do HSS, a MME armazena esse parâmetro de gap de serviço no contexto MME MM e o passa para o UE na mensagem de Aceitação de atualização de área de rastreamento.

[0243] Se a atualização da localização é rejeitada pelo HSS, a nova MME rejeita a solicitação TAU do UE com uma causa apropriada. Em tais casos, a nova

MME libera quaisquer contextos locais MME EPS do transportadores para esse UE particular e adicionalmente exclui os recursos de transportador EPS no novo S-GW ao enviar as mensagens de solicitação da sessão de exclusão (causa, indicação de operação) para o novo S-GW. A flag de indicação de operação não deve ser definida. Portanto, o novo S-GW que recebe essa solicitação não deve iniciar um procedimento de exclusão para o P-GW.

[0244] Se o UE inicia o procedimento TAU em uma célula CSG, a nova MME deve verificar se a ID CSG e associada PLMN estão contidas na assinatura CSG e não expirou. Se o ID CSG e associada PLMN não estão presentes, ou expiraram, a MME deve enviar uma mensagem de rejeição TAU para o UE com um valor de causa apropriada. O UE deve remover o CSG ID e associada PLMN de sua lista permitida de CSG, caso esteja presente. Se o UE tem serviços contínuos de transportador de emergência no controle de acesso CSG, nenhum controle de acesso deve ser feito.

[0245] Se todas as verificações são bem-sucedidas, então a nova MME constrói um contexto para o UE.

[0246] Etapa 18: Se a MME mudou, quando o temporizador iniciado na etapa 4 expira, a antiga MME/antigo S4 SGSN libera quaisquer recursos de transportador local MME ou SGSN e, adicionalmente, a antiga MME/antigo S4 SGSN elimina os recursos de transportador EPS ao enviar a mensagem de solicitação de sessão de exclusão (causa, indicação de operação) para o antigo S-GW caso tenha recebido a indicação de mudança na mensagem de Reconhecimento de contexto na etapa 7. Quando a flag de indicação de operação não estiver definida, isso indica para o antigo S-GW que o antigo S-GW não deve iniciar um procedimento de exclusão em direção ao P-GW. Se ISR for ativado, a causa indica para o antigo S-GW que o antigo S-GW deve excluir os recursos de transportador no outro nó de rede núcleo antigo ao enviar a mensagem de solicitação de exclusão de transportador para aquele nó de rede núcleo.

[0247] Se a MME não mudou, a etapa 11 dispara a liberação dos recursos de transportador EPS no antigo S-GW.

[0248] Etapa 19: O S-GW reconhece as mensagens de resposta (causa) de sessão de exclusão. O S-GW descarta quaisquer pacotes armazenados em buffer para o UE.

[0249] Etapa 20: Se, devido a restrições regionais de assinatura ou restrições de acesso (por exemplo, restrições CSG) não é permitido ao UE acessar a TA: - A MME rejeita a solicitação TAU com uma causa apropriada para o UE. - Para UEs com transportadores EPS de emergência, por exemplo, pelo menos um transportador EPS tem um valor ARP reservado para serviços de emergência, a nova MME aceita a solicitação TAU e desativa todas as conexões PDN de não emergência, conforme especificado em TS 23.401 V15.0.0 cláusula

5.10.3. Se o procedimento TAU é iniciado em estado ECM-OCIOSO, todos os transportadores EPS de não emergência são desativadas pelo procedimento TAU sem a sinalização de desativação de transportador entre o UE e a MME.

[0250] A MME envia uma mensagem de aceitação de TAU (GUTI, lista TAI, status de transportador EPS, número de sequência NAS, NAS-MAC, voz sobre IMS de sessão PS suportado, serviço de emergência, indicador de suporte, indicação LCS, comportamento de rede suportado, gap de serviço) para o UE. Se a flag ativa está definida, a MME pode prover o eNB com lista de restrição de handover. GUTI é incluída se a MME aloca um novo GUTI. Se a flag ativa está definido na mensagem de solicitação de TAU, o procedimento de preparação de UP pode ser ativado juntamente com a mensagem de aceitação de TAU. Se o tempo de expiração de dados armazenados em buffer de enlace descendente para o UE na MME não tiver expirado, o procedimento de preparação de UP é ativado mesmo se a MME não recebeu a flag ativa na mensagem de solicitação de TAU. Se a nova MME recebe a mensagem de notificação de dados de enlace descendente ou quaisquer mensagens de sinalização de enlace descendente enquanto o UE ainda está conectado, o procedimento de preparação de UP pode ser ativado mesmo se a nova MME não recebeu a flag ativa na mensagem de solicitação de TAU. O procedimento é descrito em detalhes em 3GPP TS 36.300. A sequência de mensagem deve ser a mesma para o procedimento de solicitação de serviço disparado UE especificado em TS 23.401 V15.0.0 cláusula 5.3.4.1 da etapa quando MME estabelece o transportador(es). A MME indica o status do transportador EPS IE para o UE. O UE remove quaisquer recursos internos relacionados os transportadores que não estão marcados ativos no status recebido do transportador EPS. Se as informações do status do transportador EPS estavam na solicitação de TAU, a MME deve indicar o status do transportador EPS para o UE. A lista de restrição de handover está descrita em TS 23.401 V15.0.0 cláusula 4.3.5.7 “Restrições de mobilidade.” A MME estabelece a voz sobre IMS de sessão PS suportado, conforme descrito em TS

23.401 V15.0.0 cláusula 4.3.5.8.

[0251] Para o UE que usa a otimização CIoT EPS sem qualquer conexão PDN ativada, não há status do transportador EPS incluído na mensagem de aceitação TAU.

[0252] A MME indica as otimizações CIoT que suporta e prefere nas informações de comportamento de rede suportada, conforme definido em TS

23.401 V15.0.0 cláusula 4.3.5.10.

[0253] Se houver um temporizador de gap de serviço em execução para o UE na MME, a flag ativa e a flag ativa de sinalização recebidas na mensagem de Solicitação de TAU devem ser ignoradas e nenhuma ação disparada pela flag ativa ou flag ativa de sinalização nesse procedimento deve ser realizada.

[0254] O parâmetro de gap de serviço está incluído na mensagem de aceitação TAU se o UE indicou capabilidade de gap de serviço na capabilidade de rede UE e ou se o gap de serviço foi recebida na etapa 17 de HSS nas informações de assinatura ou se o gap de serviço nas informações de assinatura foi anteriormente atualizada pelo gerenciamento de perfil do usuário HSS usuário (por exemplo, o procedimento de dados de inserção do assinante em TS 23.401 V15.0.0 cláusula 5.3.9.2). Observe que a MME pode incluir o temporizador de gap de serviço mesmo sem indicações explícitas de suporte.

[0255] Se UE incluiu suporte para restrição de uso de cobertura aperfeiçoada, a MME envia parâmetro restrito de cobertura aperfeiçoada para o eNB na mensagem S1-AP, conforme definido em TS 23.401 V15.0.0 cláusula

4.3.28. A MME também envia o parâmetro restrito de cobertura aperfeiçoada para o UE na mensagem de aceitação de TAU. O UE deve armazenar parâmetro restrito de cobertura aperfeiçoada e deve usar o valor de parâmetro restrito de cobertura aperfeiçoada para determinar se o recurso de cobertura aperfeiçoada deve ser usado ou não.

[0256] Se a MME obteve de forma bem-sucedida os parâmetros de configuração de compressão de cabeçalho na etapa 5 isso indica o uso continuado de configuração anteriormente negociada para o UE no status de contexto de compressão de cabeçalho para cada transportador EPS do UE. Quando o status de contexto de compressão de cabeçalho indica que a configuração negociada anteriormente não pode mais ser usada para alguns transportadores EPS, o UE deve parar de realizar compressão e descompressão de cabeçalho quando enviar ou receber dados usando a otimização de CP CIoT EPS nesses transportadores EPS.

[0257] Se a MME não recebeu o indicador de correspondência de suporte de voz no contexto MM, então a MME pode enviar uma solicitação de correspondência de capabilidade de rádio UE para o eNB, conforme descrito em TS 23.401 V15.0.0 cláusula 5.3.14. Se a MME não tiver recebido indicador de correspondência de suporte de voz do eNB então, baseado na implementação, a MME pode definir a indicação suportada de voz sobre IMS de sessão PS e atualizá-la em um estágio posterior. Após a etapa 12, e em paralelo a qualquer uma das etapas anteriores, a MME deve enviar uma mensagem de solicitação de notificação (suporte homogêneo de voz sobre IMS de sessões PS) para o HSS: - Se a MME avaliou o suporte de voz sobre IMS de sessões PS, vide TS 23.401 V15.0.0 cláusula 4.3.5.8, e - Se a MME determina que precisa atualizar o suporte homogêneo de voz sobre IMS de sessões PS, vide TS 23.401 V15.0.0 cláusula 4.3.5.8A.

[0258] O indicador de suporte de serviço de emergência informa ao UE que serviços de transportador de emergência são suportados. A indicação de suporte LCS indica se a rede suporta o EPC-MO-LR e/ou CS-MO-LR conforme descrito em 3GPP TS 23.271.

[0259] Se o UE incluiu elemento de informações de parâmetros DRX de modo ocioso, a MME inclui elemento de informações de parâmetros DRX de modo ocioso estendido se decide habilitar o modo ocioso estendido DRX.

[0260] Quando recebe a mensagem de aceitação de TAU e não há indicação ISR Ativada, o UE deve definir seu TIN para “GUTI.”

[0261] Para uma mudança S-GW, a ISR Ativada não é nunca indicada pela MME, uma vez que precisa de Atualização de Área de Roteamento (RAU) com o mesmo primeiro S-GW para ativar ISR. Para uma mudança de MME, a ISR não é ativada pela nova MME para evitar procedimentos de transferência de contexto com dois antigos nós de rede núcleo.

[0262] Se o procedimento TAU é iniciado por seleção manual de CSG e ocorre via uma célula CSG, o UE, ao receber a mensagem de aceitação de TAU, deve acrescentar ID CSG ID ePLMN associada à sua lista permitida de CSG se já não estiver presente. A seleção manual de CSG não é suportada se o UE tem transportadores de emergência estabelecidos.

[0263] Se a preparação de UP é realizada juntamente com a mensagem de aceitação de TAU e a TAU é realizada via uma célula híbrida, então a MME deve enviar uma indicação se o UE é um membro CSG para o RAN juntamente com a mensagem de controle de S1-MME. Baseado nessas informações, a RAN pode realizar tratamento diferenciado para membros e não membros de CSG. - NOTA 7: Se o UE recebe uma mensagem de aceitação de TAU via a célula híbrida, o UE não adiciona o correspondente ID CSG e associada PLMN à sua lista permitida de CSG. Adicionar uma ID CSG e associada PLMN à lista CSG permitida local de UE's para uma célula híbrida é uma operação realizada apenas por procedimentos OTA ou OMA DM.

[0264] Se o UE recebe o gap de serviço na mensagem de aceitação de TAU, o UE deve armazenar esse parâmetro e aplicar controle de gap de serviço para solicitações de conexão de dados MO (vide cláusula 4.3.x abaixo).

[0265] Etapa 21: Se GUTI foi incluída na aceitação de TAU, o UE reconhece a mensagem recebida ao retornar uma mensagem de conclusão de TAU para a MME.

[0266] Quando a “flag ativa” não é definida na mensagem de solicitação de TAU e o TAU não foi iniciado no estado de ECM-CONECTADO, a nova MME libera a conexão de sinalização com o UE, de acordo com TS 23.401 V15.0.0 cláusula 5.3.5. Para um UE que usa otimização CP CIoT EPS, quando a “flag ativa de sinalização” é definida, a nova MME não deve liberar a conexão de sinalização NAS com o UE imediatamente após o procedimento TAU estar concluído. - NOTA 8: A nova MME pode iniciar o estabelecimento de Transportador de Acesso via Rádio E-UTRAN (E-RAB) (vide 3GPP TS 36.413) após a execução das funções de segurança, ou esperar até a conclusão do procedimento de atualização TA. Para o UE, o estabelecimento de E-RAB pode ocorrer a qualquer momento após a solicitação de atualização de TA ser enviada.

[0267] No caso de uma operação de TAU rejeitada, devido à assinatura regional, restrições de roaming ou restrições de acesso (vide 3GPP TS 23.221 e 3GPP TS 23.008), a nova MME não deve construir um contexto MM para o UE. No caso de receber os dados do assinante de HSS, a nova MME pode construir um contexto MM e armazenar os dados do assinante para o UE para otimizar a sinalização entre a MME e o HSS. A rejeição deve ser retornada para o UE com uma causa apropriada e a conexão S1 deve ser liberada. Ao retornar para ocioso, o UE deve agir de acordo com 3GPP TS 23.122.

[0268] A nova MME deve determinar a restrição máxima APN baseada na restrição APN recebida de cada contexto de transportador na mensagem de resposta de contexto e, então, armazenar o novo valor de restrição APN máximo.

[0269] Os contextos do transportador devem ser priorizados pela nova MME. Se a nova MME não for capaz de suportar o mesmo número de contextos ativos do transportador, conforme recebido do antigo MME/SGSN, a priorização é usada para decidir qual contexto de transportador manter ativo e qual excluir. De qualquer modo, a nova MME deve primeiro atualizar todos os contextos em um ou mais P-GWs e, então, desativar o(s) contexto(s) do transportador que não pode manter, como descrito na cláusula “procedimento de desativação de transportador MME dedicada iniciada.” Isso não deve fazer com que MME rejeite o TAU.

[0270] A nova MME não deve desativar o serviço de emergência relacionado aos transportadores EPS, por exemplo transportadores EPS com valor ARP reservado para serviços de emergência.

- NOTA 9: Se MS (UE) estava em um estado PMM-CONECTADO, os contextos do transportador são enviados já na mensagem de solicitação de realocação encaminhada, conforme descrito na cláusula "Procedimentos de realocação de RNS Servidor” de 3GPP TS 23.060.

[0271] Se o procedimento TAU falha um número máximo permissível de vezes, ou se a MME retorna uma mensagem de rejeição de TAU (causa), o UE deve entrar no estado EMM ANULADO.

[0272] Se a nova MME identifica que o tipo RAT mudou, a MME verifica as informações de assinatura para identificar para cada APN se mantém a conexão PDN, desconecta a conexão PDN com uma solicitação de reativação, ou se desconecta a conexão PDN sem solicitação de reativação. Se a MME decide desativar uma conexão PDN, esta realiza um procedimento de desativação de conexão PDN iniciada por MME após o procedimento TAU ser concluído, mas antes de a conexão da interface S1/RRC ser liberada. Os valores de causa de ESM existente, como especificado em 3GPP TS 24.301 (por exemplo #39, “reativação solicitada;” #66 “ APN solicitada não suportada na RAT atual e combinação de PLMN;” e para um transportador dedicado, possivelmente #37 “ QoS EPS não aceita”), são usados para causar um comportamento UE previsível. Se todas as conexões PDN são desconectadas e o UE não suporta “vinculação sem conectividade PDN,” a MME deve solicitar para O UE a desvinculação e revinculação. Procedimentos de Solicitação de Serviço Solicitação de Serviço Disparado por UE

[0273] O procedimento de solicitação de serviço nessa clausula é disparado pelo UE no status ECM-OCIOSO para estabelecer transportadores de rádio de UP para o UE.

[0274] O UE no estado ECM-OCIOSO pode também usar esse procedimento para estabelecer transportadores de rádio de UP mesmo se o UE aplica otimização CP CIoT EPS quando o UE e a MME suportam transferência de dados S1-U ou otimização de UP EPS além da otimização CP CIoT EPS.

[0275] Se o UE tem um temporizador de gap de serviço em execução e a solicitação de serviço não é uma resposta a uma radiolocalização MT, o UE não deve iniciar esse procedimento (vide cláusula 4.3.x abaixo). - NOTA 1: Para um S5/S8 baseado em PMIP, as etapas de procedimento (A) são definidas no 3GPP TS 23.402. Etapas 9 e 11 referem-se a S5/S8 baseado em GTP.

[0276] A figura 3 ilustra o procedimento de solicitação de serviço disparado por UE. As etapas desse procedimento ilustrado na Figura 3 serão agora descritas. Todas as referências são para 3GPP TS 23.401 V15.0.0.

[0277] Etapa 1: O UE envia mensagem de solicitação de serviço NAS para a MME encapsulado em uma mensagem RRC para o eNB. A(s) mensagem(ns) RRC que pode ser usada para transportar o S-TMSI e essa mensagem NAS são descritas em 3GPP TS 36.300.

[0278] Etapa 2: O eNB encaminha a mensagem NAS para MME. A mensagem NAS é encapsulada em uma mensagem UE inicial S1-AP: (Mensagem NAS, TAI + ECGI da célula servidora, S-TMSI, CSG ID, modo de acesso CSG, causa de estabelecimento RRC). Detalhes dessa etapa estão descritos em 3GPP TS 36.300. Se a MME não pode lidar com a solicitação de serviço, irá rejeitá-lo. O ID CSG é provido se o UE enviar a mensagem de solicitação de serviço via uma célula CSG ou a célula híbrida. O modo de acesso CSG é provido se o UE envia a mensagem de solicitação de serviço via uma célula híbrida. Se o modo de acesso CSG não é provido, mas o ID CSG é provido, a MME deve considerar a célula como uma célula CSG.

[0279] Se um ID CSG é indicado e o modo de acesso CSG não é provido e não há dados de assinatura para esse ID CSG e a PLMN associada, ou a assinatura CSG expirou, a MME rejeita a solicitação de serviço com uma causa apropriada. O UE deve remover o ID CSG e associada PLMN da célula onde o UE iniciou o procedimento de solicitação de serviço da lista permitida de CSG, se estiver presente.

[0280] Para o UEs com transportadores EPS de emergência, por exemplo, pelo menos um transportador EPS tem um valor de ARP reservado para serviços de emergência, se as restrições de acesso CSG não permitem que o UE receba serviços normais, a MME deve desativar todos os transportadores de não emergência e aceitar a solicitação de serviço.

[0281] Se o LIPA está ativo para uma conexão PDN e se a célula acessada pelo UE não está ligada ao L-GW onde o UE iniciou a conexão LIPA PDN, a MME não deve solicitar o estabelecimento de transportadores da conexão LIPA PDN do eNB na etapa 4 e deve solicitar desconexão da conexão LIPA PDN de acordo com TS 23.401 V15.0.0 cláusula 5.10.3. Se o UE não tem outra conexão PDN, então a MME deve rejeitar a solicitação de serviço com um valor de causa apropriada resultando na desvinculação de UE, pular as seguintes etapas do procedimento e iniciar a liberação dos recursos da rede núcleo com o implícito procedimento de desvinculação iniciado por MME de acordo com TS 23.401 V15.0.0 cláusula 5.3.8.3.

[0282] Se houver um evento de monitoração de “disponibilidade após falha de DDN” ou um evento de monitoração de "alcançabilidade de UE" configurado para o UE na MME, a MME envia uma notificação de evento (vide 3GPP TS 23.682 para maiores informações).

[0283] Para ajudar os serviços de localização, o eNB indica o nível de cobertura de UE's para a MME.

[0284] Etapa 3: Podem ser realizados procedimentos de autenticação/segurança NAS conforme definido em TS 23.401 V15.0.0 cláusula

5.3.10 em "função de segurança".

[0285] Etapa 4: Se há um temporizador de gap de serviço em execução no contexto MME MM para o UE e a solicitação de serviço não é uma resposta para uma radiolocalização MT precedente, a MME rejeita a solicitação de serviço com uma causa apropriada e (por exemplo, opcionalmente) com um temporizador de backoff (por exemplo, um temporizador de backoff de MM) definido para o tempo restante da gap de serviço .

[0286] A MME exclui informações relacionadas a S11-U no contexto de UE, se houver alguma, incluindo TEID(DL) para o S11-U para a otimização de CP CIoT EPS se o armazenamento em buffer de dados estiver no contexto MME, ROHC para a otimização de CP CIoT EPS, etc., mas não a configuração de compressão de cabeçalho. A MME envia a solicitação de preparação de contexto inicial S1- AP (endereço S-GW, S1-TEID(s) (enlace ascendente), QoS(s) de transportador EPS, contexto de segurança, conexão de sinalização ID MME, lista de restrição de handover, indicação de associação de CSG) mensagem para o eNB. Se há uma conexão PDN estabelecida para LIPA, essa mensagem inclui um ID de correlação para habilitar o trajeto de UP direto entre o HeNB e L-GW. Se há uma conexão PDN estabelecida para SIPTO na rede local com a função L-GW justaposta ao (H)eNB, essa mensagem inclui uma ID de correlação SIPTO para habilitar o trajeto de UP direto entre o (H)eNB e o L-GW. Essa etapa ativa o transportador de rádio e o transportador de S1 para todos os transportadores EPS ativos. O eNB armazena o contexto de segurança, a conexão de sinalização ID MME, a QoS(s) de transportador EPS, e S1-TEID(s) no contexto de UE RAN. A etapa é descrita em detalhes em 3GPP TS 36.300. A lista de restrição de handover é descrita em TS 23.401 V15.0.0 cláusula 4.3.5.7 “Restrições de mobilidade”. - NOTA 2: Nessa liberação da especificação 3GPP, a ID de correlação e a ID de correlação SIPTO é definida igual para o UP P-GW TEID ( S5 baseado em GTP) ou chave GRE ( S5 baseado em PMIP) que é especificado em TS 23.401 V15.0.0 cláusula 5.3.2.1 e cláusula 5.10.2.

[0287] Se o UE incluiu suporte para restrição de uso de cobertura aperfeiçoada, a MME envia parâmetro restrito de cobertura aperfeiçoada para o eNB na mensagem S1-AP.

[0288] A MME deve apenas solicitar o estabelecimento de transportador EPS de emergência caso não se permita que o UE acesse a célula onde o UE iniciou o procedimento de solicitação de serviço devido à restrição de acesso CSG

[0289] Se a solicitação de serviço for realizada via uma célula híbrida, a indicação de associação de CSG indicando se o UE é um membro CSG deve ser incluída na mensagem S1-AP da MME para o RAN. Baseado nessas informações, a RAN pode realizar tratamento diferenciado para membros CSG e não membros CSG.

[0290] Etapa 5: O eNB realiza o procedimento de estabelecimento de transportador de rádio. A segurança de UP é estabelecida nessa etapa, que é descrita em detalhes em 3GPP TS 36.300. Quando os transportadores de rádio de UP são preparados. A sincronização do estado do transportador EPS é feita entre o UE e a rede, por exemplo o UE deve remover localmente qualquer transportador EPS para o qual nenhum transportador de rádio é configurado e, se o transportador de rádio para um transportador EPS padrão não é estabelecido, o UE deve localmente desativar todos os transportadores EPS associados ao transportador EPS padrão.

[0291] Etapa 6: Os dados de enlace ascendente do UE podem agora ser encaminhados pelo eNB para o S-GW. O eNB envia os dados de enlace ascendente para o endereço S-GW e TEID providos na etapa 4. O S-GW encaminha os dados de enlace ascendente para o P-GW.

[0292] Etapa 7: O eNB envia uma conclusão da preparação de contexto inicial da mensagem S1-AP (endereço eNB, lista de transportadores EPS, lista de transportadores EPS rejeitados, S1 TEID(s) (enlace descendente)) para a MME. Essa etapa é descrita em detalhes em 3GPP TS 36.300. Se a ID de correlação ou ID de correlação SIPTO é incluída na etapa 4, a eNB deve usar as informações incluídas para estabelecer um trajeto de UP direto para o L-GW e encaminhar os dados de enlace ascendente para o LIPA ou SIPTO na rede local, portanto, com função L-GW justaposta ao (H)eNB .

[0293] Etapa 8: A MME envia uma mensagem de solicitação de modificação de transportador (endereço eNB, S1 TEID(s) (enlace descendente) para os transportadores EPS aceitos, solicitação de notificação de pacote de enlace descendente com atraso, tipo RAT, contador de dados de exceção MO) por conexão PDN para o S-GW. Se o S-GW suporta o procedimento de solicitação de modificação de transportadores de acesso e se não há necessidade de o S- GW enviar sinalização para o P-GW, a MME pode enviar a solicitação de modificação de transportadores de acesso (endereço(s) eNB(es) e TEIDs de UP de enlace descendente para os transportadores EPS aceitos, solicitação de notificação de pacote de enlace descendente de atraso) por UE para o S-GW para otimizar a sinalização. O S-GW é agora capaz de transmitir dados de enlace descendente em direção ao UE. O uso de solicitação de notificação de pacote de enlace descendente de atraso IE é especificado em TS 23.401 V15.0.0 cláusula

5.3.4.2 abaixo. Se o P-GW solicitou informações de localização de UE's e/ou informações de CSG de usuário, informações e a localização de UE e/ou informações CSG do usuário mudaram, a MME também inclui as informações IE de localização de usuário e/ou informações IE de CSG do usuário nessa mensagem. Se a ISR é ativada ou se o IE da rede servidora mudou comparado ao último IE da rede servidora relatado, então a MME também inclui o IE da rede servidora nessa mensagem. Se a Fuso Horário UE mudou comparado à última Fuso Horário do UE relatado, então a MME deve incluir o IE da Fuso Horário UE nessa mensagem. Se a rede pendente da flag interna que iniciou a sinalização de PDN conexão sinalização é definida, a MME indica o UE disponível para sinalização de extremidade a extremidade na mensagem de solicitação de modificação de transportador e redefine a flag.

[0294] A MME apenas inclui o contador de dados de exceção MO se a causa do estabelecimento de RRC é definida para “dados de exceção MO” e o UE está acessando via o NB-IoT RAT. A MME mantém o contador de dados de exceção MO para servir as finalidades de controle de taxa PLMN (vide TS 23.401 V15.0.0 cláusula 4.7.7.2). Para que o P-GW aplique adequadamente o controle da taxa APN aos dados de exceção MO, a MME pode imediatamente enviar o contador de dados de exceção MO para o S-GW. Alternativamente, para reduzir a sinalização, a MME pode enviar o contador de dados de exceção MO para o S- GW, conforme descrito em 3GPP TS 29.274.

[0295] A MME e o S-GW limpam o tempo de expiração da memória temporária de dados de enlace descendente em seus contextos UE, caso tenha sido definido, para lembrar que qualquer armazenamento temporário de dados de enlace descendente para um UE que usa funções de economia de energia foi entregue e para evitar qualquer preparação de UP desnecessária juntamente com uma TAU posterior.

[0296] Se um transportador EPS padrão não é aceito pelo eNB, todos os transportadores EPS associados a esse transportador padrão devem ser tratados como transportadores não aceitos. A MME libera os transportadores não aceitos disparando o procedimento de liberação de transportador, conforme especificado em TS 23.401 V15.0.0 cláusula 5.4.4.2. Se o S-GW recebe um pacote de enlace descendente para um transportador não aceito, o S-GW descarta o pacote de enlace descendente e não envia uma notificação de dados de enlace descendente para a MME.

[0297] Etapa 9: Se o tipo RAT mudou comparado ao último tipo RAT relatado ou se a localização dos UE's e/ou informações IEs e/ou Fuso Horário UE e/ou se ISR não é ativado e o ID da rede servidora e/ou a indicação de UE disponível para a sinalização de extremidade para extremidade estão presentes na etapa 8, o S-GW deve enviar a mensagem de solicitação de modificação de transportador (tipo RAT , Contador de dados de exceção MO ) por conexão da PDN com o P-GW. IE de Informações de localização de usuário e/ou IE de informações de usuário CSG e/ou IE de rede servidora e/ou Fuso Horário UE e/ou a indicação de UE disponível para sinalização de extremidade a extremidade são também incluídos se estiverem presentes na etapa 8.

[0298] Se a mensagem de solicitação de modificação de transportador não for enviada devido aos motivos acima, e o carregamento P-GW for pausado, então o S-GW deve enviar uma mensagem de solicitação de modificação de transportador com indicação de pausa de carregamento de PDN para informar o P-GW que o carregamento não está mais pausado. Outros IEs não estão incluídos nessa mensagem.

[0299] Se a mensagem de solicitação de modificação de transportador não é enviada devido aos motivos acima, mas a MME indicou o contador de dados de exceção MO, então o S-GW deve notificar o P-GW que essa causa de estabelecimento de RRC foi usada pelo contador de dados de exceção MO (vide 3GPP TS 29.274). O S-GW indica cada uso dessa causa de estabelecimento RRC pelo contador relatado em seu CDR.

[0300] Etapa 10: Se o PCC dinâmico é implantado, o P-GW interage com o PCRF para obter as regras PCC de acordo com o tipo RAT por meio de um procedimento de modificação de sessão IP-CAN iniciada por PCEF, conforme definido em 3GPP TS 23.203. Se o PCC dinâmico não é implantado, o P-GW pode aplicar a política QoS local.

[0301] O P-GW indica cada uso da causa de estabelecimento RRC “dados de exceção MO” pelo contador relatado em seu CDR.

[0302] Etapa 11: O P-GW envia a Resposta de modificação de transportador para o S-GW.

[0303] Etapa 12: O S-GW deve retornar uma Resposta de modificação de transportador (endereço S-GW e TEID para tráfego de enlace ascendente) para a MME como uma resposta para uma mensagem de solicitação de modificação de transportador, ou uma resposta de modificação de acesso de transportadores (endereço S-GW e TEID para tráfego de enlace ascendente) como uma resposta para uma mensagem de solicitação de modificação de transportadores de acesso. Se o S-GW não pode servir a solicitação de MME na mensagem de solicitação de modificação de transportadores de acesso sem sinalização S5/S8 a não ser liberar a pausa no carregamento no P-GW ou sem sinalização Gxc correspondente quando PMIP é usado via a interface S5/S8 , deve responder a MME indicando que as modificações não são limitadas às transportadores S1-U e a MME deve repetir sua solicitação de modificação de transportador usando uma mensagem de solicitação de modificação de transportador por conexão PDN.

[0304] Se o SIPTO na rede local está ativo para uma conexão PDN com implantação de gateway autônomo e o ID de rede doméstica local para acesso autônomo pelo UE difere do ID de rede doméstica local onde o UE iniciou a conexão SIPTO@LN PDN, a MME deve solicitar desconexão do SIPTO na conexão da rede local PDN (s) com o valor de causa de “reativação solicitada” de acordo com TS 23.401 V15.0.0 cláusula 5.10.3. Se o UE não tem outra conexão PDN, a MME iniciou um procedimento de “desvinculação explícita com revinculação requerida” de acordo com TS 23.401 V15.0.0 cláusula 5.3.8.3.

[0305] Se o SIPTO na rede local é ativo para uma conexão com PDN com implementação de L-GW justaposto e o endereço de nível L-GW CN da célula acessada pelo UE difere do endereço L-GW CN da célula onde o UE iniciou o SIPTO na conexão com a PDN local, a MME deve solicitar a desconexão do SIPTO na rede local com conexão(ões) PDN com o valor de causa da “reativação solicitada”, de acordo com TS 23.401 V15.0.0 cláusula 5.10.3. Se o UE não tem outra conexão com PDN, a MME iniciou o procedimento de “desvinculação explícita com a revinculação requerida”, de acordo com TS 23.401 V15.0.0 cláusula 5.3.8.3. Procedimento de Retomada de Conexão

[0306] Esse procedimento é usado pelo UE para retomar a conexão ECM se O UE e a otimização do CIoT EPS do UP de suporte de rede e o UE armazenaram as informações necessárias para realizar o procedimento de retomada de conexão (vide 3GPP TS 36.300) ,de outro modo os procedimentos de solicitação de serviços são usados, vide cláusula 5.3.4.

[0307] Se UE tem um temporizador de gap de serviço em execução e o procedimento de retomada de conexão não é uma resposta a uma radiolocalização MT, o UE não deve iniciar esse procedimento (vide cláusula 4.3.x abaixo).

[0308] A Figura 4 ilustra o procedimento de retomada de conexão. As etapas desse procedimento ilustradas na Figura 4 serão agora descritas. Todas as referências são para 3GPP TS 23.401 V15.0.0.

[0309] Etapa 1: O UE dispara o procedimento de acesso aleatório para o eNB, vide 3GPP TS 36.300.

[0310] Etapa 2: O UE dispara o procedimento de retomada de conexão RRC, incluindo informações que o eNB necessita para acessar o contexto AS armazenado de UE's, vide 3GPP TS 36.300. O E-UTRAN realiza verificações de segurança. A sincronização do estado do transportador EPS é realizada entre o UE e a rede, por exemplo, o UE deve remover localmente qualquer transportador EPS para a qual nenhum transportador de rádio é definida e que não é um transportador CP CIoT EPS. Se o transportador de rádio para um transportador EPS padrão não é estabelecido, o UE deve localmente desativar todos os transportadores EPS associados à transportador EPS padrão.

[0311] Etapa 3: O eNB notifica a MME que a conexão RRC dos UE’s é retomada na mensagem de solicitação de retomada de contexto S1-AP UE que inclui uma causa de retomada de RRC. Se o eNB não é capaz de admitir todos os transportadores suspensos, o eNB deve indicar isso na lista de transportadores EPS rejeitados, vide TS36.413. Se há um temporizador de gap de serviço em execução no contexto na MME MM para o UE e a MME não está esperando uma resposta de radiolocalização de MT do UE e a solicitação de retomada de conexão não é um TAU potencial (derivado baseado no parâmetro de causa de estabelecimento de RRC equivale à sinalização MO), a MME rejeita a solicitação de retomada de contexto com uma causa apropriada e (por exemplo, opcionalmente) com um temporizador de backoff definido para o tempo restante de gap de serviço. O eNB deve liberar a conexão RRC com um tempo de espera estendido que equivale ao tempo de backoff.

[0312] A MME entra no estado ECM-CONECTADO. A MME identifica que o UE retorna ao eNB para o qual a MME armazenou dados relativos à associação S1AP , contexto de UE e contexto de transportador incluindo o(s) TEID(s) de enlace descendente, necessário para retomar a conexão, vide procedimento suspenso de conexão em TS 23.401 V15.0.0 cláusula 5.3.4A.

[0313] Se um transportador EPS padrão não é aceito pelo eNB, todos os transportadores EPS associados a esse transportador padrão devem ser tratados como transportadores não aceitos. A MME libera os transportadores não aceitos e não estabelecidos ao disparar o procedimento de liberação de transportador, conforme, especificado em TS 23.401 V15.0.0 cláusula 5.4.4.2.

[0314] Para ajudar os serviços locais, o eNB indica o nível de cobertura dos UE's para a MME.

[0315] Etapa 3A: Se a conexão S1-U é retomada e o UE está acessando via o NB-IoT RAT com a causa da retomada de RRC definida para “dados de exceção MO,” a MME deve notificar o S-GW de cada uso dessa causa de estabelecimento pelo contador de dados de exceção MO. A MME mantém o contador de dados de exceção MO e o envia para o S-GW, conforme indicado em 3GPP TS 29.274.

[0316] Etapa 3B: O S-GW deve notificar o P-GW se a causa do estabelecimento de RRC “dados de exceção MO” foi usada pelo contador de dados de exceção MO (vide TS 29.274). O S-GW indica cada uso dessa causa de estabelecimento de RRC pelo contador relacionado em seu CDR.

[0317] Etapa 3C: O P-GW indica cada uso da causa de estabelecimento de RRC “dados de exceção MO” pelo contador relacionado em seu CDR.

[0318] Etapa 4: A MME reconhece a retomada de conexão na mensagem de resposta de retomada de contexto S1-AP UE. Se a MME não pode admitir todos os E-RABs suspensos, a MME deve indicar isso no E-RABs que não conseguiu retomar a lista IE.

[0319] Etapa 5: Se a MME incluiu na etapa 4 uma lista de E-RABs que não conseguiram retomar, o eNB reconfigura os transportadores de rádio.

[0320] Etapa 6: Os dados de enlace ascendente do UE podem agora ser encaminhados pelo eNB para o S-GW. O eNB envia os dados de enlace ascendente para o endereço S-GW e TEID armazenado durante o procedimento de suspensão de conexão, vide TS 23.401 V15.0.0 cláusula 5.3.4A. O S-GW encaminha os dados de enlace ascendente para o P-GW.

[0321] Etapa 7: A MME envia uma mensagem de solicitação de modificação de transportador (endereço eNB, S1 TEID(s) (enlace descendente) para os transportadores EPS aceitos, solicitação de notificação de pacote de enlace descendente de atraso, tipo RAT) por conexão com PDN ao S-GW. Se o S-GW suporta o procedimento de solicitação de modificação de transportadores de acesso e se não há necessidade de o S-GW enviar a sinalização para o P-GW, a MME pode enviar solicitação de modificação de transportadores de acesso (endereço (s)eNB e TEIDs para UP de enlace descendente para os transportadores aceitas EPS , solicitação de notificação de pacote de enlace descendente de atraso) por UE para o S-GW para otimizar a sinalização. O S-GW é agora capaz de transmitir dados de enlace descendente em direção ao UE.

[0322] A MME e o S-GW removem o tempo de expiração do armazenamento temporário de enlace ascendente em seus contextos UE, caso tenha sido definido, para lembrar que quaisquer dados de enlace descendente armazenados em buffer para um UE usando funções de economia de energia foram entregues e para evitar quaisquer preparação de UP desnecessária juntamente com um TAU posterior.

[0323] Etapa 8: O S-GW deve retornar uma Resposta de modificação de transportador (endereço S-GW e TEID para tráfego de enlace ascendente) para a MME como uma resposta a uma mensagem de solicitação de modificação de transportador (endereço S-GW e TEID para tráfego de enlace ascendente) como uma resposta a uma mensagem de modificação de transportadores de acesso. Se o S-GW não pode servir a solicitação de MME na mensagem de solicitação de modificação de transportadores de acesso sem sinalização S5/S8 que não seja liberar a pausa de carregamento no P-GW ou sem sinalização Gxc correspondente quando PMIP é usadas via a interface S5/S8 , deve responder para a MME indicando que as modificações não são limitadas às transportadores

S1-U , e a MME deve repetir sua solicitação usando uma mensagem de solicitação de modificação de transportador por conexão PDN.

[0324] Se a SIPTO na rede local está ativa para uma conexão PDN com implantação de GW autônomo e a ID da rede doméstica local para acesso autônomo pelo UE difere da ID da rede doméstica onde o UE iniciou a conexão SIPTO@LN PDN, a MME deve solicitar desconexão do SIPTO na conexão da rede local da(s) conexão(ões) PDN com o valor de causa de “reativação solicitada” de acordo com TS 23.401 V15.0.0 cláusula 5.10.3. Se o UE não tem outra conexão PDN, a MME iniciou o procedimento “desvinculação explícita com revinculação requerida”, de acordo com TS 23.401 V15.0.0 cláusula 5.3.8.3.

[0325] Se SIPTO na rede local é ativo para uma conexão PDN com implantação de L-GW justaposto e o endereço de rede núcleo L-GW da célula acessada pelo UE difere do endereço da rede núcleo L-GW da célula onde o UE iniciou o SIPTO na conexão PDN da rede local, a MME deve solicitar a desconexão do SIPTO na(s) conexão(ões) PDN da rede local com a o valor da causa de “reativação solicitada”, de acordo com TS 23.401 V15.0.0 cláusula

5.10.3. Se o UE não tem outra conexão PDN, a MME iniciou a “desvinculação explícita com o procedimento de revinculação requerida”, de acordo com a cláusula 5.3.8.3.

[0326] EXEMPLOS ADICIONAIS DE COMO AS EXIGÊNCIAS SÃO IMPLEMENTADAS NOS SEGUINTES PROCEDIMENTOS: - Mensagem UE inicial S1-AP UE com uma PDU com dados NAS, vide cláusula 5.3.4B.2; - Procedimento MO NIDD. Vide TS 23.682, cláusula 5.13.4; - Mensagem curta MO, vide TS 23.040, cláusula 10.2.

[0327] Lida-se com o gap de serviço dentro da camada NAS/subcamada MM que é tanto o receptor quanto o usuário das informações de temporizador de gap de serviço.

[0328] Possível basear o controle de gap de serviço nas transições CONECTADO-A-OCIOSO que são mecanismos existentes dentro da camada NAS/subcamada MM, mas também usa entrada adicional disponível dentro da camada NAS/subcamada MM tal como lidar com radiolocalização nos eventos MT que não sejam sinalização NAS/MM, tal como MM, etc. Sistema de Exemplo e Modalidades de Dispositivo

[0329] A Figura 5 ilustra um exemplo de um sistema de comunicação sem fio 10 em que as modalidades da presente revelação podem ser implementadas. Nesse exemplo, o sistema de comunicação sem fio 10 é uma rede de comunicações de celular e, em particular, é uma rede de comunicações de celular 3GPP LTE ou NR que suporta, por exemplo, dispositivos CIoT.

[0330] Conforme ilustrado, o sistema de comunicação sem fio 10 inclui uma série de dispositivos sem fio 12 (por exemplo, dispositivos de comunicação sem fio 12). Além disso, o sistema de comunicação sem fio 10 inclui um RAN que inclui uma série de nós de Acesso via Rádio 14 (por exemplo, eNBs ou gNBs) que servem áreas de cobertura correspondentes 16. Os nós de Acesso via Rádio 14 estão CONECTADOS a uma rede núcleo 18, que inclui uma série de nós de rede núcleo (não mostrados) tais como, por exemplo, MME(s), SGSN(s), S-GW(s), P- GW(s), PCRF(s), HSS(s), EIR(s), e/ou similares.

[0331] Em algumas modalidades, o dispositivo sem fios 12, os nós de Acesso via Rádio 14 e os nós de rede núcleo operam de acordo com qualquer uma das modalidades descritas acima para prover controle de gap de serviço na camada NAS/subcamada MM.

[0332] A Figura 6 é um fluxograma que ilustra a operação do dispositivo sem fio 12 de acordo com pelo menos algumas das modalidades reveladas aqui. Conforme ilustrado, o dispositivo sem fio 12 recebe um parâmetro de gap de serviço de um nó de rede (por exemplo, uma MME ou similar) em uma mensagem NAS de subcamada MM (por exemplo, uma mensagem de solicitação de vinculação ou a mensagem de aceitação TAU) (etapa 100). Por exemplo, vide etapa 18 da Figura 1C e etapa 20 da Figura 2B). O dispositivo sem fio 12 então impõe o parâmetro de gap de serviço no dispositivo sem fio 12 na camada NAS (etapa 102).

[0333] Por exemplo, conforme descrito acima: - em uma primeira modalidade, o dispositivo sem fio 12 pode não permitir que o dispositivo sem fio 12 se vincule a qualquer PLMN enquanto o temporizador de gap de serviço estiver em execução, - em uma segunda modalidade, o dispositivo sem fio 12 pode, além disso, ou como uma alternativa à primeira modalidade, não definir a flag ativa, ou a flag ativa de sinalização em qualquer mensagem TAU enquanto o temporizador de gap de serviço estiver em execução, - em uma terceira modalidade, o dispositivo sem fio 12 pode, além de ou como uma alternativa à primeira e/ou à segunda modalidade, não permitir que o dispositivo sem fio 12 inicie um procedimento de solicitação de serviço (por exemplo, enviar uma solicitação de serviço) enquanto o temporizador de gap de serviço estiver em execução (e, em algumas modalidades, a solicitação de serviço não é uma resposta a uma radiolocalização de MT), e/ou - o dispositivo sem fio 12 pode não permitir que o dispositivo sem fio 12 inicie um procedimento de retomada de conexão (por exemplo, enviar uma solicitação de retomada de conexão) enquanto o temporizador de gap de serviço estiver em execução (e, em algumas modalidades, a solicitação de serviço não é uma resposta a uma radiolocalização MT).

[0334] A Figura 7 é um fluxograma que ilustra a operação de um nó de rede de acordo com pelo menos algumas das modalidades reveladas aqui. Etapas opcionais são indicadas por linhas tracejadas. Aqui, presume-se que o nó de rede seja a MME ou similar, mas não se limita à mesma. Conforme ilustrado, o nó de rede obtém um parâmetro de gap de serviço para um dispositivo sem fio 12 (etapa 200). Por exemplo, o nó de rede pode obter ou receber o parâmetro de gap de serviço para o dispositivo sem fio 12 de HSS, por exemplo, conforme descrito acima com referência à etapa 11 na Figura 1B e/ou etapa 17 na Figura 2B. O nó de rede envia o parâmetro de gap de serviço para o dispositivo sem fio 12 em uma mensagem NAS de subcamada MM (por exemplo, uma mensagem de aceitação de vinculação ou uma mensagem de aceitação TAU) por exemplo, como na etapa 18 na Figura 1C e/ou na etapa 20 na Figura 2B (etapa 202). Opcionalmente, o nó de rede impõe o parâmetro de gap de serviço no nó de rede na camada NAS (etapa 204). Por exemplo, conforme descrito acima, o nó de rede pode rejeitar as solicitações de vinculação do dispositivo sem fio 12 enquanto o temporizador de gap de serviço para o dispositivo sem fio 12 estiver em execução, e/ou deixar de realizar quaisquer ações disparadas pela flag ativa ou a flag ativa de sinalização em uma mensagem TAU do dispositivo sem fio enquanto o temporizador de gap de serviço para o dispositivo sem fio 12 estiver em execução, e/ou rejeitar solicitações de serviço do dispositivo sem fio 12 enquanto o temporizador de gap de serviço para o dispositivo sem fio 12 estiver em execução (e, em algumas modalidades, a solicitação de serviço não é uma resposta a uma radiolocalização MT ), e/ou rejeitar as solicitações de retomada de conexão do dispositivo sem fio 12 enquanto o temporizador de gap de serviço para o dispositivo sem fio 12 estiver em execução (e, em algumas modalidades, a solicitação de serviço não é uma resposta a uma radiolocalização MT).

[0335] A Figura 8 é um diagrama em bloco esquemático do dispositivo de comunicação sem fio 12, ou UE, de acordo com algumas modalidades da presente revelação. Conforme ilustrado, o serviço de comunicação sem fio 12 inclui conjunto de circuito 20 que compreende um ou mais processadores 22 (por exemplo, Unidades de Processamento Central (CPUs), Circuitos Integrados de Aplicação Específica (ASICs), Arranjos de Portas Programáveis em Campo (FPGAs), Processadores de Sinal Digital (DSPs), e/ou similar) e memória 24. O dispositivo de comunicação sem fio 12 também inclui um ou mais transceptores 26, cada um incluindo ou mais transmissores 28 e um ou mais receptores 30 acoplados a uma ou mais antenas 32. Em algumas modalidades, a funcionalidade do dispositivo de comunicações sem fio 12 aqui descrita pode ser implementada em hardware (por exemplo, via hardware dentro do conjunto de circuito 20 e/ou dentro do processador(es) 22) ou ser implementada em uma combinação de hardware e software (por exemplo, total ou parcialmente implementada em software que é, por exemplo, armazenado na memória 24 e executado pelo processador(es) 22).

[0336] Em algumas modalidades, um programa de computador incluindo instruções que, quando executadas por pelo menos um processador 22, faz com que o pelo menos um processador 22 realize pelo menos algumas das funcionalidades do dispositivo de comunicação sem fio 12, de acordo com qualquer uma das modalidades aqui descritas é provido. Em algumas modalidades, uma portadora contendo produto de programa de computador acima mencionado é provido. A portadora é uma dentre um sinal eletrônico, um sinal óptico, um sinal de rádio, ou um meio de armazenamento legível por computador (por exemplo, um meio não transitório legível por computador, tal como memória).

[0337] A figura 9 é um diagrama em bloco esquemático do dispositivo de comunicação sem fio 12, ou UE, de acordo com algumas outras modalidades da presente revelação. O dispositivo de comunicação sem fio 12 inclui um ou mais módulos 34, cada um dos quais é implementado em software. O(s) módulo(s)

34 provê a funcionalidade do dispositivo de comunicação sem fio 12 descrito aqui (por exemplo, conforme descrito com relação às Figuras 1A a 1D, Figuras 2A e 2B, Figura 3, Figura 4, e/ou Figura 6).

[0338] A Figura 10 é um diagrama em bloco esquemático de um nó de rede 36 (por exemplo, um nó de Acesso via Rádio 14 tal como, por exemplo, um eNB ou gNB ou um nó de rede núcleo tal como, por exemplo, uma MME) de acordo com algumas modalidades da presente revelação. Conforme ilustrado, o nó de rede 36 inclui um sistema de controle 38 que inclui conjunto de circuito que compreende um ou mais processadores 40 (e.g., CPUs, ASICs, DSPs, FPGAs e/ou similar) e memória 42. O sistema de controle 38 também inclui uma interface de rede 44. Nas modalidades em que o nó de rede 36 é um nó de Acesso via Rádio 14, o nó de rede 36 também inclui uma ou mais unidades de rádio 46, sendo que cada uma delas inclui um ou mais transmissores 48 e um ou mais receptores 50 acoplados a uma ou mais antenas 52. Em algumas modalidades, a funcionalidade do nó de rede 36 (por exemplo, a funcionalidade da MME, S- GW, P-GW, SGSN, PCRF, ou HSS) descrito acima pode ser total ou parcialmente implementada em software que é, por exemplo, armazenado na memória 42 e executado pelo(s) processador(es) 40.

[0339] A Figura 11 é um diagrama em bloco esquemático que ilustra uma modalidade virtualizada do nó de rede 36 (´por exemplo, o nó de Acesso via Rádio 14 ou um nó de rede núcleo) de acordo com algumas modalidades da presente revelação. Conforme aqui usado, um nó de rede “virtualizado” 36 é um nó de rede 36 no qual pelo menos uma parte da funcionalidade do nó de rede 36 é implementada como um componente virtual (por exemplo, via uma máquina virtual (s) que executa em um nó (nós)de processamento (s) físico em uma rede). Conforme ilustrado, o nó de rede 36 opcionalmente inclui o sistema de controle 38, conforme descrito com relação à Figura 10. Além disso, se o nó de rede 36 é o nó de Acesso via Rádio 14, o nó de rede 36 também inclui a uma ou mais unidade de rádio 46, conforme descrito com relação à Figura 10. O sistema de controle 38 (se estiver presente) é conectado a um, ou mais de um, nó de processamento s 54 acoplado a ou incluído como parte de uma rede) 56 via a interface de rede 44. Alternativamente, se o sistema de controle 38 não estiver presente, a uma ou mais unidade de rádio 46 (se estiver presente) é conectada a um ou mais nó de processamento 54 via uma interface de rede. Alternativamente, toda a funcionalidade do nó de rede 36 descrita aqui pode ser implementada no nó de processamento 54. Cada nó de processamento 54 inclui um ou mais processadores 58 (por exemplo, CPUs, ASICs, DSPs, FPGAs e/ou similar), memória 60 e uma interface de rede 62.

[0340] Nesse exemplo, as funções 64 do nó de rede 36 (por exemplo, as funções do eNB, RNC, MME, S-GW, P-GW, HSS, ou PCRF) descritas aqui são implementadas em um ou mais nós de processamento 54 ou distribuídas através do sistema de controle 38 (se estiver presente) e o um ou mais nó de processamento 54 de qualquer modo desejado . Em algumas modalidades particulares, algumas ou todas as funções 64 do nó de rede 36 descrito aqui são implementadas como componentes virtuais executadas por uma ou mais máquinas virtuais implementadas em um ambiente virtual(s) hospedado pelo nó de processamento (s) 54. Como será observado por uma pessoa versada na técnica, a sinalização ou comunicação adicional entre o nó de processamento (s) 54 e o sistema de controle 38 (caso esteja presente) ou alternativamente a unidade de rádio(s) 46 (caso esteja presente) é usada para realizar pelo menos algumas das funções desejadas. Notavelmente, em algumas modalidades, o sistema de controle 38 pode não ser incluído, em cujo caso a unidade de rádio(s) 46 (caso esteja presente) se comunica diretamente com o nó de processamento (s) 54 via uma apropriada interface de rede(s).

[0341] Em algumas modalidades particulares, uma funcionalidade de camada mais elevada (por exemplo, camada 3 e acima e, possivelmente, alguma dentre a camada 2 da pilha de protocolo) do nó de rede 36 pode ser implementada no nó de processamento (s) 54 como componentes virtuais (por exemplo, implementados “na nuvem”) ao passo que a funcionalidade da camada mais baixa (por exemplo, camada 1 e possivelmente alguma dentre a camada 2 da pilha de protocolo) pode ser implementada na unidade de rádio(s) 46 e, possivelmente no sistema de controle 38.

[0342] Em algumas modalidades, um programa de computador incluindo instruções que, quando executadas por pelo menos um processador 40, 58, faz com que o pelo menos um processador 40, 58 realize a funcionalidade do nó de rede 36 ou do nó de processamento 54 de acordo com qualquer uma das modalidades aqui descritas é provido. Em algumas modalidades, uma portadora contendo o produto de programa de computador acima mencionado é provido. A portadora é uma dentre um sinal eletrônico, um sinal óptico, um sinal de rádio ou um meio de armazenamento legível por computador (por exemplo, um meio não transitório legível por computador, tal como a memória 42, 60).

[0343] A figura 12 é diagrama em bloco esquemático do nó de rede 36 de acordo com algumas outras modalidades da presente revelação. O nó de rede 36 inclui um ou mais módulos 66, cada um dos quais é implementado no software. O(s) módulo(s) 66 proveem a funcionalidade do nó de rede 36 descrito aqui (por exemplo, a funcionalidade de um nó correspondente dentre os nós de redes descritos em relação às figuras 1A a 1D, Figuras 2A e 2B, Figura 3, Figura 4, e/ou Figura 7).

[0344] Algumas das modalidades descritas acima podem ser adicional ou alternativamente descritas como na cláusula abaixo: 4.3.7.4 controle de sobrecarga de MME, 4.3.x Controle de Gap de Serviço, 5.3.2 Procedimento de vinculação, 5.3.4 Procedimentos de solicitação de serviço, 5.3.5A Procedimento de Retomada de Conexão, 5.3.4A Procedimento de Suspensão de Conexão , 5.3.5 Procedimento de Liberação S1 , 5.10.2 conectividade Solicitada de PDN , 5.7.1 HSS, 5.7.2 MME e 5.7.5 UE.

4.3.7.4 Controle de sobrecarga de MME

4.3.7.4.1 Geral A MME deve conter mecanismos para evitar e manipular situações de sobrecarga. Esses podem incluir o uso de sinalização de NAS para rejeitar solicitações de NAS de UEs. Além disso, sob circunstâncias atípicas, a MME deve restringir a carga que seus eNodeBs estão gerando na mesma, caso esteja configurada para possibilitar a restrição de sobrecarga. Isso pode ser alcançado por meio da MME que invoca o procedimento de sobrecarga de interface S1 (consulte TS 36.300 [5] e TS 36.413 [36]) para todos ou para uma proporção dos eNodeBs com os quais a MME tem conexões de interface S1. Para refletir a quantidade de carga que a MME deseja reduzir, a MME pode ajustar a proporção de eNodeBs para os quais são enviadas mensagem OVERLOAD START de interface S1, e o conteúdo da mensagem OVERLOAD START. A MME deve selecionar os eNodeBs aleatoriamente (de modo que, caso duas MMEs dentro de uma área de agrupamento estejam sobrecarregadas, as mesmas não enviem, ambas, mensagens OVERLOAD START exatamente para o mesmo conjunto de eNodeBs). A MME pode incluir, de modo opcional, uma Indicação de Redução de Carga de Tráfego na mensagem OVERLOAD START. Nesse caso, o eNodeB deve reduzir, caso suporte, o tipo de tráfego indicado de acordo com o percentual solicitado (consulte TS 36.413 [36]). NOTA 1: A implantação de MME pode precisar considerar o fato de que eNodeBs compatíveis com a Versão 9 e versão anterior das especificações não suportam o percentual de indicação de sobrecarga.

Uma MME que suporta Otimização de CIoT EPS de Plano de Controle pode incluir uma indicação na mensagem OVERLOAD START que indica sobrecarga de transferências de dados por meio de Otimização de CIoT EPS de Plano de Controle.

Com o uso da mensagem OVERLOAD START, a MME pode solicitar ao eNodeB para que: - rejeite as solicitações de conexão de RRC que são para serviços originados em terminal móvel de prioridade não alta, de relatório de não exceção e de não emergência; ou NOTA 2: Isso bloqueia serviço de PS e serviço fornecido por MSC seguindo um procedimento de vinculação de EPS/IMSI. - rejeite novas solicitações de conexão de RRC para sinalização de Gerenciamento de Mobilidade de EPS (por exemplo, para Atualizações de TA) para aquela MME; - apenas permita solicitações de conexão de RRC para sessões de emergência e serviços finalizados em móvel para aquela MME.

Isso bloqueia solicitações de sessão de emergência de UEs com USIMs fornecidos com Acesso Classes 11 e 15 quando os mesmos estão em seus HPLMN/EHPLMN e de UEs com USIMs fornecidos com Acesso Classes 12, 13 e 14 quando os mesmos estão em seu país de origem (definido como a parte de MCC da IMSI, consulte TS 22.011 [67]); ou.

NOTA 3: A MME pode restringir o número de respostas a radiolocalização não enviando mensagens de radiolocalização para uma proporção dos eventos que iniciam radiolocalização.

Como parte desse processo, a MME pode fornecer preferência por radiolocalizar UEs com Serviços de Transportador de Emergência e terminações associadas a MPS ARP. - apenas permita solicitações de conexão de RRC para sessões de alta prioridade, relatório de exceção e serviços finalizados em móvel para aquela MME; - rejeite novas solicitações de conexão de RRC de UEs que acessam a rede com baixa prioridade de acesso; - não aceite solicitações de conexão de RRC com causa de estabelecimento de RRC "mo-data" ou "Tolerante a atraso" de UEs que suportam apenas Otimização de CIoT EPS de Plano de Controle.

NOTA 4: As solicitações de conexão de RRC listadas nessa cláusula também incluem a solicitação para Retomada de Conexão de RRC.

Ao rejeitar uma solicitação de conexão de RRC por razões de sobrecarga, o eNodeB indica ao UE um valor de temporizador apropriado que limita solicitações de conexão de RRC adicionais por um tempo.

Um eNodeB suporta rejeição de estabelecimentos de conexão de RRC para determinados UEs, conforme especificado em TS 36.331 [37]. Adicionalmente, um eNodeB fornece suporte para o bloqueio de UEs configurados para Bloqueio de Acesso Estendido, conforme descrito em TS 22.011 [67]. Esses mecanismos são especificados, adicionalmente, em TS 36.331 [37]. Caso o UE esteja acampado em NB-IoT, Bloqueio de Acesso Estendido não se aplica.

Um eNodeB pode iniciar Bloqueio de Acesso Estendido quando: - todas as MMEs conectadas a esse eNB solicitarem a restrição da carga Para o UEs que acessam a rede com baixa prioridade de acesso; ou - solicitado por O&M.

Caso uma MME invoque o procedimento de sobrecarga de interface S1 para restringir a carga Para o UEs que acessam a rede com baixa prioridade de acesso, a MME deve selecionar todos os eNodeBs com os quais a MME tem conexões de interface S1. Alternativamente, os eNodeBs selecionados podem ser limitados a um subconjunto dos eNodeBs com os quais a MME tem conexão de interface S1 (por exemplo, área de localização particular ou onde dispositivos do tipo destinatários são registrados). Durante uma situação de sobrecarga, a MME deve tentar manter suporte para serviços de transportador de emergência (consulte a cláusula 4.3.12) e para MPS (consulte a cláusula 4.3.18). Quando a MME está se recuperando, a MME pode: - enviar mensagens OVERLOAD START com novo valor percentual que permite que mais tráfego seja portado, ou - a MME envia mensagens OVERLOAD STOP. para alguns ou todos os eNodeB(s). Além disso, para proteger a rede de sobrecarga, a MME tem a opção de rejeitar mensagens de solicitação de NAS que incluem o indicador de baixa prioridade de acesso antes de rejeitar mensagens de solicitação de NAS sem o indicador de baixa prioridade de acesso (consulte a cláusula 4.3.7.4.2 para mais informações). NOTA 5: Não se pode garantir que serviços de voz estejam disponíveis para chamadas finalizadas em terminal móvel enquanto o temporizador de backoff de Gerenciamento de Mobilidade estiver em execução. Recomenda-se que UEs que exigem serviços de voz não sejam configurados para baixa prioridade de acesso. Além disso, para suportar o recurso de Gap de Serviço (consulte a cláusula

4.3.x abaixo), que é projetado para controlar a carga de CIoT UEs com um parâmetro de Gap de Serviço em suas Informações de Assinatura de HSS, a MME pode usar o temporizador de backoff de Gerenciamento de Mobilidade ao rejeitar solicitações de conexão de dados MO (consulte a cláusula 4.3.7.4.2.1 para mais informações).

4.3.7.4.2 Controle de congestionamento de nível de NAS

4.3.7.4.2.1 Geral O controle de congestionamento de nível de NAS contém as funções: “controle de congestionamento com base em APN" e "controle de Gerenciamento de Mobilidade de nível de NAS Geral". O uso do controle de congestionamento com base em APN é para evitar e manipular congestionamento de sinalização de EMM e ESM associado O UEs com um APN particular. Tanto UEs quanto rede devem suportar as funções para fornecer controle de congestionamento de EMM e ESM com base em APN. A MME pode detectar o congestionamento de sinalização de NAS associado ao APN e iniciar e interromper a realização do controle de congestionamento com base em APN, com base em critérios, tais como: - Número máximo de transportadores de EPS ativos por APN; - Taxa máxima de ativações de Transportador de EPS por APN; - Um ou múltiplos PDN GWs de um APN não são acessíveis ou indicaram congestionamento à MME; - Taxa máxima de solicitações de sinalização de MM e SM associadas aos dispositivos de um grupo particular e um APN assinado particular; e/ou - Definição em gerenciamento de rede. A MME pode detectar o congestionamento de sinalização de NAS associado aos UEs que pertencem a um grupo particular. A MME pode iniciar e interromper a realização do controle de congestionamento de nível de NAS específico de grupo com base em critérios, tais como: - Taxa máxima de solicitações de sinalização de MM e SM associadas aos dispositivos de um grupo particular; e/ou - Definição em gerenciamento de rede.

A MME pode detectar o congestionamento de sinalização de NAS associado aos UEs que pertencem a um grupo particular e são assinados em um APN particular. A MME pode iniciar e interromper a realização do controle de congestionamento de nível de NAS específico de grupo e APN com base em critérios, tais como: - Número máximo de transportadores de EPS ativos por grupo e APN; - Taxa máxima de solicitações de sinalização MM e SM associadas aos dispositivos de um grupo particular e um APN assinado particular; e/ou - Definição em gerenciamento de rede. A MME não deve aplicar controle de congestionamento de nível de NAS para serviços de emergência e acesso de alta prioridade. Com controle de Gerenciamento de Mobilidade de nível de NAS Geral, a MME também pode usar a rejeição de solicitações de sinalização de Gerenciamento de Mobilidade de nível de NAS sob condições de congestionamento gerais, tais como detecção de congestionamento de um ou diversos DCNs em uma MME que serve múltiplos DCNs. Para suportar o recurso de Gap de Serviço (consulte a cláusula 4.3.x abaixo), a MME deve retornar um temporizador de backoff de Gerenciamento de Mobilidade para o UE em respostas a solicitações em que a intenção é enviar dados MO (isto é, solicitações de conexão para dados de plano de usuário MO, dados de plano de controle MO e MO SMS) quando o temporizador de gap de Serviço estiver sendo executado para o UE.

4.3.x controle de Gap de Serviço O controle de Gap de Serviço é um recurso opcional destinado a dispositivos CIoT quando a frequência de comunicação de dados deve ser controlada. Ou seja, para controlar para que um tempo mínimo decorra após dados de usuário Originados em terminal Móvel terem sido comunicados com um UE (isto é,

dados de plano de usuário MO, dados de plano de controle MO ou MO SMS). A intenção é colocar um limite na frequência com que recursos de rede são usados para um UE.

Isso significa que a carga de uma grande quantidade de dispositivos CIoT pode ser uniformizada e que a contribuição para a carga de pico de rede de tais dispositivos CIoT pode ser reduzida.

Ou seja, recursos de rede são usados de um modo mais ideal. o gap de Serviço será tipicamente usado para “planos de permissão de pequenos dados" para assinaturas de CIoT que são de baixo rendimento e quando as aplicações são tolerantes à latência de serviço potencial.

A gap de serviço é um parâmetro de assinatura e imposto em um nível por UE (isto é, comum para todas as conexões de PDN) no UE e na MME.

A MME passa o parâmetro de gap de serviço para o UE na mensagem de Aceitação de vinculação e/ou mensagem de Aceitação de Atualização de Área de Rastreamento Para o UE que foi indicado nas Capacidades de Rede de UE que suporta o recurso de gap de serviço.

O controle de gap de serviço deve ser aplicado para um UE quando um parâmetro de gap de serviço é armazenado no contexto de UE no UE e no contexto de MM na MME.

A gap de serviço se aplica ao modo ocioso, isto é, exige que o UE permaneça um tempo mínimo em modo ECM-OCIOSO.

O temporizador de gap de serviço deve ser iniciado cada vez que um UE muda de ECM-CONECTADO para ECM- OCIOSO.

Únicas exceções são quando a conexão foi iniciada após uma radiolocalização de um evento de MT, ou após sinalização de TAU MO sem qualquer conjunto de flag ativa (isto é, flag ativa ou flag ativa de sinalização), que não deve disparar um intervalo de gap de serviço novo ou estendido.

Desvinculação deve ser permitida em qualquer momento.

Quando a Desvinculação é feita em ECM-CONECTADO, o temporizador de gap de serviço deve ser iniciado na Desvinculação.

As exceções são quando a conexão foi iniciada após uma radiolocalização de um evento de MT, ou após sinalização de TAU MO sem qualquer conjunto de flag ativa (isto é, flag ativa ou flag ativa de sinalização), que não deve disparar um intervalo de gap de serviço novo ou estendido.

Desvinculação em ECM-OCIOSO não afeta o temporizador de gap de serviço.

O UE deve impor o gap de serviço não permitindo solicitações de conexão de dados de plano de usuário MO, dados de plano de controle MO e MO SMS e Solicitações de Vinculação quando um temporizador de gap de serviço estiver sendo executado.

A aplicação no UE deve ser informada pela camada de NAS quando dados podem ser enviados, isto é, notificado quando o temporizador de gap de serviço é iniciado e interrompido.

Os detalhes são deixados para implantação (consulte TS 24.301 [46]). A MME deve impor o gap de serviço rejeitando-se solicitações de conexão de dados de plano de usuário MO, dados de plano de controle MO e MO SMS e Solicitações de Vinculação quando um temporizador de gap de serviço estiver sendo executado.

Ao rejeitar solicitações de conexão de dados MO, a MME deve incluir um temporizador de backoff de Gerenciamento de Mobilidade que corresponde ao tempo restante da gap de serviço atual.

Quando a MME inicia o temporizador de gap de serviço, a MME deve usar um valor que é alguns segundos a menos do que o parâmetro de gap de serviço recebido de HSS nas informações de assinatura (isto é, usado pelo UE). Isso garante que a MME não rejeite quaisquer solicitações de UE imediatamente antes de o temporizador de gap de serviço expirar, por exemplo, devido a temporizadores de UE e MME um pouco dessincronizados.

Aspectos adicionais de gap de serviço: - A gap de serviço se aplica em casos de roaming e não roaming. - A gap de serviço se aplica a dados MO (isto é, dados de plano de controle

MO, dados de plano de usuário MO e MO SMS). - Quando o temporizador de gap de serviço estiver sendo executado e o UE receber radiolocalização, o UE deve responder de modo habitual. - O controle de gap de serviço se aplica à baixa prioridade (Tolerante a atraso), tráfego normal e relatório de exceção (para NB-IoT). NOTA: o gap de serviço não deve ser usado para assinaturas com aplicações sensíveis à latência de serviço, por exemplo, quando relatório de exceção é usado ou UEs que usam serviços de emergência. - O controle de gap de serviço deve ser eficaz para dispositivos que realizam desvinculação/revinculação ou ciclo de potência total.

Ou seja, um temporizador de gap de serviço em execução no UE e na MME deve permanecer após desvinculação ou ciclo de potência. - A atualização de Área de Rastreamento com flag ativa ou flag ativa de sinalização não é permitida quando um temporizador de gap de serviço estiver sendo executado. - Vinculação durante um temporizador de gap de serviço em execução contínuo não é permitida. o gap de serviço em seleção de PLMN: a) Revinculação no mesmo PLMN: O temporizador de gap de serviço permanece e controla a revinculação. b) Vinculação ou Atualização de Área de Rastreamento em uma PLMN diferente com o mesmo USIM: O temporizador de gap de serviço permanece e controla a Vinculação/Atualização de Área de Rastreamento na nova PLMN. c) Alternância de USIM: O temporizador de gap de serviço é interrompido e o gap de serviço é redefinido. - Múltiplos pacotes de enlace ascendente e pacotes de enlace descendente são permitidos durante uma conexão de RRC Para o UE que opera dentro de seus limites de Controle de Taxa de APN.

Os seguintes procedimentos estão sujeitos a controle de gap de serviço: - Vinculação Inicial de E-UTRAN, consulte a cláusula 5.3.2.1; - Procedimentos de Atualização de Área de Rastreamento, consulte as cláusulas sob 5.3.3; - Solicitação de Serviço Disparada por UE, consulte a cláusula 5.3.4.1; - Solicitação de Retomada de Contexto de UE de S1-AP, consulte a cláusula

5.3.5A; - Mensagem de UE Inicial de S1-AP com uma PDU de Dados de NAS, consulte a cláusula 5.3.4B.2; - Procedimento de MO NIDD. Consulte TS 23.682 [74], cláusula 5.13.4; - MO de mensagem curta, consulte TS 23.040, cláusula 10.2.

5.3.2 Procedimento de Vinculação

5.3.2.1 Vinculação Inicial de E-UTRAN Um UE/usuário precisa registrar na rede para receber serviços que exigem registro. Esse registro é descrito como Vinculação à Rede. A conectividade de IP sempre ativa Para o UE/usuários do EPS pode ser habilitada estabelecendo-se um transportador de EPS padrão durante Vinculação de Rede. As regras de PCC aplicadas à transportador de EPS padrão podem ser predefinidas no PDN GW e ativadas na vinculação pelo próprio PDN GW. O procedimento de Vinculação pode disparar um ou múltiplos procedimentos de Estabelecimento de Transportador dedicado para estabelecer transportador(es) de EPS dedicado para aquele UE. Durante o procedimento de vinculação, o UE pode solicitar uma alocação de endereço de IP. Terminais que utilizam apenas mecanismos com base em IETF para alocação de endereço de IP também são suportados. Durante o procedimento de Vinculação Inicial, a Identidade de Equipamento Móvel é obtida do UE. O operador de MME pode verificar a Identidade de ME com um EIR. A MME passa a Identidade de ME (IMEISV) para o HSS e para o PDN GW.

Durante o procedimento de Vinculação Inicial, caso a MME suporte SRVCC e caso qualquer uma dentre as condições descritas na etapa 8 na Figura 5.3.2.1- 1 seja satisfeita, a MME informa o HSS com a capacidade de UE SRVCC, por exemplo, para registro de IMS adicional.

O procedimento de Vinculação Inicial de E-UTRAN é usado para Vinculação de Emergência por UEs que precisam realizar serviços de emergência, mas não podem ganhar serviços normais da rede.

Esses UEs estão em estado de serviço limitado, conforme definido em TS 23.122 [10]. Além disso, UEs que vincularam para serviços normais e não têm transportadores de emergência estabelecidos e estão acampados em uma célula em estado de serviço limitado (por exemplo, Área de Rastreamento restrita ou CSG não permitido) devem iniciar os procedimentos de Vinculação que indicam que a vinculação é para receber serviços de emergência.

UEs que acampam normalmente em uma célula, isto é, UEs que não estão em estado de serviço limitado, devem iniciar vinculação inicial normal quando ainda não estiverem vinculados e devem iniciar o procedimento de Conectividade de PDN Solicitada por UE para receber serviços de transportador de EPS de emergência.

NOTA 1: Um UE que é vinculado como emergência realiza procedimento de vinculação inicial antes de ter a capacidade de obter serviços normais.

A fim de limitar carga na rede, apenas ao realizar uma Vinculação de E- UTRAN com uma nova PLMN (isto é, não a PLMN registrada ou uma PLMN equivalente da PLMN registrada), um UE configurado para realizar Vinculação com IMSI em mudança de PLMN (consulte TS 24.368 [69]) deve se identificar por meio de sua IMSI em vez de qualquer identificador temporário armazenado.

Esse procedimento também é usado para estabelecer a primeira conexão de PDN por E-UTRAN quando o UE já tem conexões de PDN ativas através de uma rede de acesso não 3GPP e deseja estabelecer conexões de PDN simultâneas com diferentes APNs através de múltiplos acessos.

UE eNodeB Nova MME Antigo GW Servidor PDN GW PCRF HSS MME/SGSN

1. Solicitação de Vinculação

EIR

2. Solicitação de Vinculação 3. Solicitação de Identificação

3. Resposta de Identificação

4. Solicitação de Identidade

4. Resposta de Identidade 5a. Autenticação/Segurança 5b. Solicitação/Resposta de Identidade 5b. Verificação de

6. Solicitação de Opções Cifradas Identidade de ME

6. Resposta de Opções Cifradas

7. Solicitação de Exclusão de Sessão 7. Término de Sessão de IP-CAN iniciada por PCEF (E) 7. Resposta de Exclusão de Sessão (A)

8. Solicitação de atualização de Localização

9. Cancelamento de Localização

9. Ack de Cancelamento de Localização

10. Solicitação de Exclusão de Sessão 10. Término de Sessão de IP-CAN iniciada por PCEF (F) 10. Resposta de Exclusão de Sessão (B)

11. Ack de Atualização de Localização

12. Solicitação de Criação de Sessão

13. Solicitação de Criação de Sessão

14. Modificação/Estabelecimento de Sessão de IP-CAN iniciada por PCEF (C)

15. Resposta de Criação de Sessão Primeiros Dados de Enlace Descendente (se não handover)

16. Resposta de Criação de Sessão

17. Solicitação de Preparação de Contexto Inicial ou transporte de NAS de Enlace Descendente com Aceitação de Vinculação

18. Reconfiguração de Conexão de RRC ou Transferência Direta de RRC

19. Conclusão de Reconfiguração de conexão de RRC

20. Resposta de Preparação de Contexto Inicial

21. Transferência Direta

22. Conclusão de Vinculação Primeiros Dados de Enlace Ascendente

23. Solicitação de Modificação de Transportador 23a. Solicitação de Modificação de Transportador 23b. Solicitação de Modificação de Transportador (D)

24. Resposta de Modificação de Transportador Primeiros Dados de Enlace Ascendente

25. Solicitação de Notificação

26. Resposta de Notificação Figura 5.3.2.1-1: Procedimento de Vinculação (Attach Procedure)

NOTA 2: Para um S5/S8 com base em PMIP, as etapas de procedimento (A), (B) e (C) são definidas em TS 23.402 [2]. As etapas 7, 10, 13, 14, 15 e 23a/b se referem a S5/S8 com base em GTP. NOTA 3: Os GWs servidores e PDN GWs envolvidos nas etapas 7 e/ou 10 podem ser diferentes daqueles nas etapas 13-15. NOTA 4: As etapas em (D) são executadas apenas mediante handover de acesso não 3GPP, ou caso Informações de Área de Relatório de Presença sejam recebidas da MME. NOTA 5: Mais detalhes das etapas de procedimento (E) são definidos nas etapas de procedimento (B) na cláusula 5.3.8.3. NOTA 6: Mais detalhes das etapas de procedimento (F) são definidos nas etapas de procedimento (B) na cláusula 5.3.8.4.

1. Um UE, acampado em uma célula de E-UTRAN, lê a Difusão de Informações de Sistema relacionada. Uma célula de E-UTRAN para uma PLMN que suporta aperfeiçoamentos de CIoT deve difundir: Para o caso de NB-IoT: - Se pode se conectar a uma MME que suporta Vinculação de EPS sem Conectividade de PDN. Para o caso de WB-E-UTRAN: - Se suporta Otimização de CIoT EPS de Plano de Controle e pode se conectar a uma MME que suporta Otimização de CIoT EPS de Plano de Controle. - Se suporta Otimização de CIoT EPS de Plano de Usuário e pode se conectar a uma MME que suporta Otimização de CIoT EPS de Plano de Usuário. - Se pode se conectar a uma MME que suporta Vinculação de EPS sem Conectividade de PDN. Caso a PLMN não comunique suporte de vinculação de EPS sem conectividade de PDN e o UE só possa vincular sem conectividade de PDN, então, o UE não deve vincular à PLMN nessa célula e deve prosseguir, conforme especificado em TS 23.122 [10]. No caso de WB-E-UTRAN, caso a PLMN não suporte Otimização de CIoT EPS de Plano de Controle, e o UE suporte apenas Otimização de CIoT EPS de Plano de Controle e não possa vincular de outro modo, então, o UE não deve prosseguir com a Vinculação na PLMN nessa célula e deve prosseguir, conforme especificado em TS 23.122 [10]. No caso de um temporizador de Gap de Serviço sendo executado no UE (consulte a cláusula 4.3.x), então, o UE não deve vincular a essa PLMN ou qualquer outra PLMN desde que o temporizador esteja sendo executado.

Caso o UE possa prosseguir para vinculação, o mesmo inicia o procedimento de Vinculação por meio da transmissão, para o eNodeB, de uma mensagem de Solicitação de Vinculação (IMSI ou GUTI antigo, tipo de GUTI antigo, TAI visitada por último (caso disponível), Capacidade de Rede núcleo de UE, parâmetros de DRX Específicos de UE, parâmetros de DRX de modo ocioso estendido, Tipo de Vinculação, contêiner de mensagem de ESM (Tipo de Solicitação, Tipo de PDN, Opções de Configuração de Protocolo, Flag de Transferência de Opções Cifradas, Configuração de Compressão de Cabeçalho), KSIASME, número de sequência de NAS, NAS-MAC, GUTI adicional, assinatura de P-TMSI, preferência de domínio de Voz e definição de uso de UE, comportamento de Rede Preferencial, Capacidade de Rede de MS, Suporte para restrição de uso de Cobertura Aprimorada) em conjunto com parâmetros de RRC que indicam a Rede Selecionada e a GUMMEI antiga.

Na sinalização de estabelecimento de conexão de RRC associada à Solicitação de Vinculação, o UE indica seu suporte das Otimizações de CIoT EPS, relevantes para seleção de MME.

Caso o UE se identifique com o GUTI antigo, o UE deve definir o Tipo de GUTI antigo para indicar se o GUTI antigo é um GUTI nativo ou é mapeado de uma P-TMSI e RAI.

O GUTI antigo pode ser derivado de uma P-TMSI e RAI.

IMSI deve ser incluída caso o UE não tenha um GUTI válido ou uma P-TMSI válida disponível, ou caso o UE seja configurado para realizar Vinculação com IMSI em mudança de PLMN e esteja acessando uma nova PLMN.

O UE armazena a TIN em estado desvinculado.

Caso a TIN de UE indique "GUTI" ou “TMSI relacionada à RAT" e o UE mantém um GUTI válido, então, o GUTI antigo indica esse GUTI válido.

Caso a TIN de UE indique "P-TMSI" e o UE mantenha uma P-TMSI válida e RAI relacionada, então, esses dois elementos são indicados como o GUTI antigo.

O mapeamento de uma P-TMSI e RAI para um GUTI é especificado em TS 23.003 [9]. Caso o UE mantenha um GUTI válido e o GUTI antigo indique um GUTI mapeado de uma P-TMSI e RAI, então, o UE indica o GUTI como GUTI adicional.

Caso o GUTI antigo indique um GUTI mapeado de uma P-TMSI e RAI e o UE tenha uma assinatura de P-TMSI válida associada ao mesmo, a assinatura de P-TMSI deve ser incluída.

O UE define a preferência de domínio de voz e definição de uso de UE de acordo com a sua configuração, conforme descrito na cláusula 4.3.5.9. Alternativamente, quando um UE suporta apenas E-UTRAN, caso o UE tenha um GUTI disponível e o UE esteja acessando a mesma PLMN (ou ePLMN), então, o mesmo se identifica com o GUTI antigo e define o Tipo de GUTI antigo para “nativo”, de outro modo, a configuração de UE determina se o UE se identifica com sua IMSI ou com o GUTI antigo.

O UE inclui o elemento de informações de parâmetros de DRX de modo ocioso estendido caso o UE precise habilitar DRX de modo ocioso estendido.

Caso disponível, a TAI visitada por último deve ser incluída a fim de ajudar a MME a produzir uma boa lista de TAIs para qualquer mensagem Aceitação de vinculação subsequente.

Rede Selecionada indica a PLMN que é selecionada para propósitos de compartilhamento de rede.

O parâmetro de RRC “GUMMEI antiga" obtém seu valor do “GUTI antigo" contido na Solicitação de Vinculação.

Capacidade de Rede de UE é descrita em capacidades de UE, consulte a cláusula 5.11. Caso o UE tenha parâmetros de segurança válidos, a mensagem de Solicitação de Vinculação deve ter a integridade protegida pelo NAS-MAC a fim de permitir validação do UE pela MME.

KSIASME, número de sequência de NAS e NAS-MAC são incluídos caso o UE tenha parâmetros de segurança de EPS válidos.

O número de sequência de NAS indica o número sequencial da mensagem de NAS.

Caso o UE não tenha uma associação de segurança de EPS válida, então, a mensagem de Solicitação de Vinculação não tem integridade protegida.

Nesse caso, a associação de segurança é estabelecida na etapa 5a.

As capacidades de rede de UE também indicam os algoritmos de segurança de NAS e AS suportados.

O tipo de PDN indica a versão de IP solicitada (IPv4, IPv4/IPv6, IPv6). Para um UE que suporta otimizações de CIoT EPS, o tipo de PDN também pode ser Opções de Configuração de Protocolo (PCO) de "Não IP “são usadas para transferir parâmetros entre o UE e o PDN GW, e são enviados de modo transparente através da MME e do GW Servidor.

As Opções de Configuração de Protocolo podem incluir a Preferência de Alocação de Endereço que indica que o UE prefere obter um endereço de IPv4 somente após a ativação de transportador padrão por meio de DHCPv4. Caso o UE pretenda enviar PCO que exigem cifragem (por exemplo, nomes de usuário e senhas PAP/CHAP) ou enviar um APN, ou ambos, o UE deve definir a flag de Transferência de Opções Cifradas e enviar PCO ou APN ou ambos somente após autenticação e preparação de segurança de NAS terem sido concluídas (consulte abaixo).

NOTA 7: Os operadores de rede externa que desejam usar PAP para autenticação são informados de que PAP é um protocolo obsoleto de um ponto de vista de segurança.

CHAP fornece segurança mais forte do que PAP.

O UE deve incluir nas PCO o Status de UE de Desligamento de Dados PS de 3GPP, que indica se o usuário ativou ou desativou Desligamento de Dados PS de 3GPP.

Caso o UE tenha capacidades UTRAN ou GERAN, o mesmo deve enviar a NRSU nas PCO para indicar o suporte do controle de transportador solicitado por rede em UTRAN/GERAN.

O UE envia o ETFTU nas PCO para indicar o suporte do formato de filtro de TFT estendido.

Tipo de Solicitação está incluído no contêiner de mensagem de ESM e indica "Handover" quando o UE já tiver um PDN GW/HA ativado devido à mobilidade com acessos não 3GPP.

Caso um UE indique suporte de Otimizações de CIoT na mensagem de RRC, o mesmo pode omitir o contêiner de mensagem de ESM.

Caso o contêiner de mensagem de ESM seja omitido, a MME não deve estabelecer uma conexão de PDN como parte do procedimento de Vinculação.

Nesse caso, as etapas 6, 12 a 16 e 23 a 26 não são executadas.

Além disso, para o caso de UEs que vinculam com Otimização de CIoT EPS de Plano de Controle sem estabelecimento de plano de usuário, as etapas 17 a 22 são substituídas por mensagens de Transporte de NAS de AP S1 e de Transferência Direta de RRC que apenas transportam as mensagens de Aceitação de vinculação de NAS e Conclusão de Vinculação de NAS.

Tipo de Vinculação indica se é uma vinculação de EPS ou uma vinculação de EPS/IMSI combinada ou uma Vinculação de Emergência.

Vinculação de Emergência não deve ser indicada quando o UE estiver usando NB-IoT.

Ao usar otimizações de C-IoT EPS, o UE pode indicar vinculação de EPS e solicitar SMS definindo-se a flag “Transferência de SMS sem Vinculação Combinada” no IE de

Comportamento de Rede Preferencial. Caso um UE inclua um Comportamento de Rede Preferencial, isso define o Comportamento de Rede que o UE está esperando que esteja disponível na rede, conforme definido na cláusula 4.3.5.10. Caso um UE tenha indicado otimização de CIoT EPS de Plano de Controle suportada em Comportamento de Rede Preferencial, e o UE tenha incluído o contêiner de mensagem de ESM, e o tipo de PDN foi IPv4 ou IPv6 ou IPv4v6, e o UE suporte compressão de cabeçalho, o mesmo deve incluir a Configuração de Compressão de Cabeçalho. A Configuração de Compressão de Cabeçalho inclui as informações necessárias para a preparação de canal de ROHC. De modo opcional, a Configuração de Compressão de Cabeçalho pode incluir parâmetros de preparação de contexto de compressão de cabeçalho adicionais caso o UE já tenha as informações de tráfego de aplicação, por exemplo, o endereço de IP de servidor de destino. Para uma Vinculação de Emergência, o UE deve definir tanto o Tipo de Vinculação quanto o Tipo de Solicitação para "Emergência" e a IMSI deve estar incluída caso o UE não tenha um GUTI válido ou uma P-TMSI válida disponível. A IMEI deve estar incluída quando o UE não tem IMSI, nem GUTI válido e nem P- TMSI válida.

2. O eNodeB deriva o endereço de MME dos parâmetros de RRC que portam a GUMMEI antiga, a Rede Selecionada indicada e a RAT (NB-IoT ou WB- E-UTRAN). Caso essa MME não seja associada ao eNodeB ou a GUMMEI antiga não esteja disponível, o eNodeB seleciona uma MME, conforme descrito na cláusula 4.3.8.3 em “função de seleção de MME". O eNodeB encaminha a mensagem de Solicitação de Vinculação em uma mensagem de controle de S1- MME (mensagem de UE inicial) em conjunto com a Rede Selecionada, modo de acesso de CSG, CSG ID, endereço de L-GW, TAI+ECGI da célula de onde recebeu a mensagem para a nova MME. ID de CSG é fornecido caso o UE vincule por meio de uma célula de CSG ou célula híbrida. O modo de acesso de CSG é fornecido caso o UE vincule por meio de uma célula híbrida. Caso o modo de acesso de CSG não seja fornecido, mas o ID de CSG seja fornecido, a MME deve considerar a célula como uma célula de CSG. Caso o eNodeB tenha um L-GW justaposto, o mesmo inclui o endereço de L-GW na mensagem de UE inicial para a MME. Caso a MME não seja configurada para suportar Vinculação de Emergência, a MME deve rejeitar qualquer Solicitação de Vinculação que indique Tipo de Vinculação "Emergência". Caso o UE tenha incluído o Comportamento de Rede Preferencial, e o que o UE indicou o mesmo suporta em Comportamento de Rede Preferencial é incompatível com o suporte de rede, por exemplo, o UE indicou suporte apenas para otimização de CIoT EPS de Plano de Controle e a MME apenas suporta Otimização de CIoT EPS de Plano de Usuário, a MME deve rejeitar a Solicitação de Vinculação com um valor de causa apropriado (por exemplo, um que evita repetições nessa PLMN). Para auxiliar Serviços de Localização, o eNB indica o Nível de Cobertura de UE à MME.

3. Caso o UE se identifique com GUTI e a MME tenha mudado desde desvinculação, a nova MME determina o tipo do nó antigo, isto é, MME ou SGSN, conforme especificado na cláusula 4.3.19, usa o GUTI recebido do UE para derivar o endereço de antigo MME/SGSN, e envia uma Solicitação de Identificação (GUTI antigo, mensagem de Solicitação de Vinculação de conclusão) para o antigo MME/SGSN para solicitar a IMSI. Caso a solicitação seja enviada a uma antiga MME, a antiga MME primeiro verifica a mensagem de Solicitação de Vinculação por NAS MAC e, então, responde com Resposta de Identificação (IMSI, Contexto de MM). Caso a solicitação seja enviada a um antigo SGSN, o antigo SGSN primeiro verifica a mensagem de Solicitação de Vinculação pela assinatura de P-TMSI e, então, responde com Resposta de Identificação (Contexto de MM). Caso o UE não seja conhecido em antigo MME/SGSN ou caso a verificação de integridade ou verificação de assinatura de P-TMSI para a mensagem de Solicitação de Vinculação falhe, o antigo MME/SGSN responde com uma causa de erro apropriada. O contexto de MM contém informações relacionadas à segurança bem como outros parâmetros (incluindo IMSI), conforme descrito na cláusula 5.7.2 (Armazenamento de Informações para MME). O GUTI adicional na mensagem de Solicitação de Vinculação permite que a nova MME encontre qualquer contexto de UE já existente armazenado na nova MME quando o GUTI antigo indicar um GUTI mapeado de uma P-TMSI e RAI. Para uma Vinculação de Emergência caso o UE se identifique com uma identidade temporária que não é conhecida pela MME, a MME solicita, imediatamente, a IMSI do UE. Caso o UE se identifique com IMEI, a solicitação de IMSI deve ser pulada. NOTA 8: Um SGSN sempre responde com os parâmetros de segurança de UMTS e a MME pode armazenar os mesmos para uso posterior.

4. Caso o UE seja desconhecido tanto em antigo MME/SGSN quanto Nova MME, a Nova MME envia uma Solicitação de Identidade ao UE para solicitar a IMSI. O UE responde com Resposta de Identidade (IMSI). 5a. Caso não exista contexto de UE para o UE em nenhum local na rede, caso a Solicitação de Vinculação (enviada na etapa 1) não tenha integridade protegida, ou caso a verificação da integridade tenha falhado, então, autenticação e preparação de segurança de NAS para ativar a proteção de integridade e cifragem de NAS são obrigatórias. De outro modo, isso é opcional. Caso algoritmo de segurança de NAS deva ser mudado, a preparação de segurança de NAS é realizada nessa etapa.

As funções de autenticação e preparação de segurança de NAS são definidas na cláusula 5.3.10 em "Função de Segurança". Caso a MME seja configurada para suportar Vinculação de Emergência para IMSIs não autenticadas e o UE tenha indicado Tipo de Vinculação "Emergência", a MME omite a autenticação e preparação de segurança ou a MME aceita que a autenticação pode falhar e continua o procedimento de vinculação.

Após a etapa 5a, todas as mensagens de NAS devem ser protegidas pelas funções de segurança de NAS (integridade e cifragem) indicadas pela MME, a menos que o UE seja vinculado como emergência e não autenticado de maneira bem-sucedida. 5b.

A Identidade de ME (IMEISV) deve ser recuperada do UE.

A Identidade de ME deve ser transferida criptografada, a menos que o UE realize Vinculação de Emergência e não possa ser autenticado.

Para uma Vinculação de Emergência, o UE pode ter incluído a IMEI na Vinculação de Emergência.

Caso positivo, a recuperação de Identidade de ME é pulada.

A fim de minimizar atrasos de sinalização, a recuperação da Identidade de ME pode ser combinada com preparação de segurança de NAS na etapa 5a.

A MME pode enviar a Solicitação de Verificação de Identidade de ME (Identidade de ME, IMSI) para o EIR.

O EIR deve responder com Reconhecimento de Verificação de Identidade de ME (Resultado). Dependendo do Resultado, a MME decide continuar com esse procedimento de Vinculação ou rejeitar o UE.

Para uma Vinculação de Emergência, a verificação de IMEI para o EIR pode ser realizada.

Caso a IMEI seja bloqueada, políticas de operador determinam se o procedimento de Vinculação de Emergência continua ou é interrompido.

6. Caso o UE tenha definido a flag de Transferência de Opções Cifradas na mensagem de Solicitação de Vinculação, as Opções Cifradas, isto é, PCO ou APN ou ambos, devem ser, agora, recuperadas do UE. A fim de manipular situações em que o UE pode ter assinaturas para múltiplos PDNs, caso as Opções de Configuração de Protocolo contenham credenciais de usuário (por exemplo, nome de usuário/senha dentro de parâmetros PAP ou CHAP) então, o UE também deve enviar o APN à MME.

7. Caso haja contextos de transportadores ativos na nova MME para esse UE particular (isto é, o UE revincula para a mesma MME sem ter desvinculado antes de maneira apropriada), a nova MME exclui esses contextos de transportador enviando-se mensagens de Solicitação de Exclusão de Sessão (LBI) aos GWs envolvidos. Os GWs reconhecem com mensagem de Resposta de Exclusão de Sessão (Causa). Caso uma PCRF seja implementada, o PDN GW emprega um procedimento de Terminação de Sessão de IP-CAN para indicar que recursos foram liberados.

8. Caso haja um contexto de assinatura válido para o UE na MME com um temporizador de Gap de Serviço sendo executado, a MME rejeita a Solicitação de Vinculação do UE com uma causa apropriada e com um Temporizador de Backoff de Gerenciamento de Mobilidade definido para o tempo de Gap de Serviço remanescente. Caso a MME tenha mudado desde a última desvinculação, ou caso não haja contexto de assinatura válido para o UE na MME, ou caso o UE forneça uma IMSI ou o UE forneça um GUTI antigo que não se refere a um contexto válido na MME ou, para algum cenário de compartilhamento de rede (por exemplo, GWCN), caso o PLMN-ID da TAI fornecido pelo eNodeB seja diferente daquele do GUTI no contexto de UE, a MME envia uma mensagem de Solicitação de Atualização de Localização (Identidade de MME, IMSI, Identidade de ME (IMEISV),

Capacidades de MME, Flags de ULR, Suporte Homogêneo de Voz sobre IMS de sessões PS, capacidade de UE SRVCC, lista de PLMN equivalente) ao HSS.

As capacidades de MME indicam o suporte de MME para funcionalidade de restrições de acesso regional.

As Flags de ULR indicam "Indicador de Vinculação Inicial", visto que esse é um procedimento de vinculação.

A inclusão da lista de PLMN equivalente indica que a MME suporta o handover entre PLMNs para uma célula de CSG em uma PLMN equivalente com o uso das informações de assinatura da PLMN de destino.

A indicação de "Suporte Homogêneo de Voz sobre IMS de sessões PS” (consulte a cláusula 4.3.5.8A) não deve estar incluída, a menos que a MME tenha concluído sua avaliação do suporte de “Voz sobre IMS de sessão PS", conforme especificado na cláusula 4.3.5.8. NOTA 9: Nessa etapa, a MME pode não ter todas as informações necessárias para determinar a definição da indicação de Voz sobre IMS de sessão PS Suportada para esse UE (consulte a cláusula 4.3.5.8). Portanto, a MME pode enviar o "Suporte Homogêneo de Voz sobre IMS de sessões PS" posteriormente nesse procedimento.

Caso o UE realize Vinculação de Handover ou Inicial em uma VPLMN que suporta Roaming de CSG Autônomo e a HPLMN tenha habilitado Roaming de CSG Autônomo na VPLMN (por meio de Acordo de Nível de Serviço) e a MME precise recuperar as informações de assinatura de CSG do UE a partir do CSS, a MME inicia o Procedimento de Atualização de Localização de CSG com CSS, conforme descrito na cláusula 5.3.12. Caso a MME determine que apenas a capacidade de UE SRVCC mudou, a MME envia uma Solicitação de Notificação ao HSS para informar sobre a capacidade de UE SRVCC alterada.

Para uma Vinculação de Emergência em que o UE não foi autenticado de maneira bem-sucedida, a MME não deve enviar uma Solicitação de Atualização de Localização ao HSS.

9. O HSS envia Cancelamento de Localização (IMSI, Tipo de Cancelamento) à antiga MME. A antiga MME reconhece com Reconhecimento de Cancelamento de Localização (IMSI) e remove os contextos de transportador e MM. Caso as Flags de ULR indiquem "Indicador de Vinculação Inicial" e o HSS tenha o registro de SGSN, então, o HSS envia Cancelar Localização (IMSI, Tipo de Cancelamento) ao antigo SGSN. O Tipo de Cancelamento indica à antigo MME/SGSN para liberar o recurso de GW Servidor antigo.

10. Caso haja contextos de transportadores ativos em antigo MME/SGSN para esse UE particular, o antigo MME/SGSN exclui esses contextos de transportador enviando-se mensagens de Solicitação de Exclusão de Sessão (LBI) aos GWs envolvidos. Os GWs retornam a mensagem Resposta de Exclusão de Sessão (Causa) à antigo MME/SGSN. Caso uma PCRF seja implementada, o PDN GW emprega um procedimento de Terminação de Sessão de IP-CAN, conforme definido em TS 23.203 6] para indicar que recursos foram liberados.

11. O HSS reconhece a mensagem de Atualização de Localização enviando-se uma mensagem de Reconhecimento de Atualização de Localização (IMSI, Dados de Assinatura) à nova MME. Os Dados de Assinatura contêm um ou mais contextos de assinatura de PDN. Cada contexto de assinatura de PDN contém um “perfil de QoS de EPS assinado” e o APN-AMBR assinado (consulte a cláusula 4.7.3) e a indicação de capacidade de descarregamento de WLAN (consulte a cláusula 4.3.23). A nova MME valida a presença de UE na (nova) TA. Caso, devido às restrições de assinatura regionais ou restrições de acesso (por exemplo, restrições de CSG), não seja permitido que o UE vincule na TA ou, devido a falhas de verificação de assinatura por outras razões, a nova MME rejeita a Solicitação de Vinculação com uma causa apropriada. Caso todas as verificações sejam bem-sucedidas, então, a nova MME constrói um contexto para o UE. Caso o APN fornecido pelo UE não seja permitido por assinatura, ou a Atualização de Localização seja rejeitada pelo HSS, a nova MME rejeita a Solicitação de Vinculação do UE com uma causa apropriada. Os Dados de Assinatura podem conter informações de assinatura de CSG para a PLMN registrada e para a lista de PLMN equivalente solicitada pela MME na etapa 8. Os Dados de Assinatura podem conter parâmetro de Cobertura Aprimorada Restrita. Caso recebido do HSS, MME armazena esse parâmetro de Cobertura Aprimorada Restrita no contexto de MME MM. Os dados de assinatura podem conter parâmetro de gap de serviço. Caso recebido do HSS, MME armazena esse parâmetro de gap de serviço no contexto de MME MM e passa o mesmo para o UE na mensagem de Aceitação de vinculação. Caso o APN fornecido por UE seja autorizado para LIPA de acordo com a assinatura de usuário, a MME deve usar os Dados de Assinatura de CSG para autorizar a conexão. Para uma Vinculação de Emergência, a MME não deve verificar restrições de acesso, restrições regionais ou restrições de assinatura (por exemplo, restrições de CSG). Para uma Vinculação de Emergência, a MME deve ignorar qualquer Resposta de Atualização de Localização malsucedida de HSS e continuar com o procedimento de Vinculação.

12. Caso um contêiner de ESM não tenha sido incluído na Solicitação de Vinculação, as etapas 12, 13,14,15,16 são puladas. Caso o tipo de vinculação não seja definido para "Emergência", e o contêiner de ESM tenha sido incluído na Solicitação de Vinculação, e o UE tenha indicado suporte para Vinculação sem Conectividade de PDN, e a rede suporte Vinculação sem Conectividade de PDN, e a Restrição de Conexão de PDN seja definida nos dados de assinante, então, a nova MME não deve estabelecer conexão de PDN, e as etapas 12, 13, 14, 15 e 16 são puladas.

Para uma Vinculação de Emergência, a MME aplica os parâmetros de Dados de Configuração de Emergência de MME para o estabelecimento de transportador de emergência realizado nessa etapa e quaisquer dados de assinatura relacionados à IMSI potencialmente armazenados são ignorados pela MME.

Caso o UE realize Vinculação Inicial ou Handover por meio de uma célula de CSG e não haja assinatura para aquele CSG ou a assinatura de CSG está expirada, a MME deve rejeitar a Solicitação de Vinculação com uma causa apropriada.

Caso o UE tenha esse ID de CSG e PLMN associada em sua lista de CSG Permitido, o UE deve remover o ID de CSG e PLMN associada da lista ao receber essa causa de rejeição.

Caso um endereço de PDN assinado seja alocado para o UE para esse APN, o contexto de assinatura de PDN contém o endereço de IPv4 e/ou o prefixo de IPv6 de UE e, de modo opcional, a identidade de PDN GW.

Caso o contexto de assinatura de PDN contenha um endereço de IPv4 e/ou prefixo de IPv6 assinado, a MME indica isso no endereço de PDN.

Para Tipo de Solicitação que indica "Solicitação inicial", caso o UE não forneça um APN, a MME deve usar o PDN GW que corresponde ao APN padrão para ativação de transportador padrão.

Caso o UE forneça um APN, esse APN deve ser empregado para ativação de transportador padrão.

Para Tipo de Solicitação que indica "Handover", caso o UE forneça um APN, a MME deve usar o PDN GW que corresponde ao APN fornecido para ativação de transportador padrão, caso o UE não forneça um APN, e o contexto de assinatura de HSS contenha uma identidade de PDN GW que corresponde ao APN padrão, a MME deve usar o PDN GW que corresponde ao APN padrão para ativação de transportador padrão.

O caso em que o Tipo de

Solicitação indica "Handover" e o UE não fornece um APN, e o contexto de assinatura de HSS não contém uma identidade de PDN GW que corresponde ao APN padrão constitui um caso de erro.

Caso o Tipo de Solicitação indique "Solicitação inicial" e o contexto de assinatura de PDN selecionado não contenha identidade de PDN GW, a nova MME seleciona um PDN GW, conforme descrito na cláusula 4.3.8.1 na função de seleção de PDN GW (acessos de 3GPP). Caso o contexto de assinatura de PDN contenha uma identidade de PDN GW dinamicamente alocada e o Tipo de Solicitação não indique "Handover", a MME pode selecionar um novo PDN GW, conforme descrito na cláusula função de seleção de PDN GW, por exemplo, para alocar um PDN GW que permite roteamento mais eficiente.

Para Vinculação de Emergência inicial e handover, a MME usa a função de seleção de PDN GW definida na cláusula 4.3.12.4 para selecionar um PDN GW.

Caso o contexto de assinatura não indique que o APN é para uma conexão de PDN com uma SCEF, a nova MME seleciona um GW Servidor, conforme descrito na cláusula 4.3.8.2 na função de seleção de GW Servidor e aloca uma Identidade de Transportador de EPS para o transportador padrão associado ao UE.

Então, a mesma envia uma mensagem de Solicitação de Criação de Sessão (IMSI, MSISDN, MME TEID para plano de controle, endereço de PDN GW, Endereço de PDN, tipo de APN, RAT, QoS de Transportador de EPS Padrão, Tipo de PDN, APN-AMBR, Identidade de Transportador de EPS, Opções de Configuração de Protocolo, Indicação de Handover, Identidade de ME (IMEISV), Informações de Localização de Usuário (ECGI), Fuso Horário de UE, Informações de CSG de Usuário, indicação de suporte de Relatório de Mudança de Info de MS, Modo de Seleção, Características de Carregamento, Referência de Rastreio, Tipo de Rastreio, Id de Disparo, Identidade de OMC, Restrição Máxima de APN, Flag de Transportador de Endereço Duplo, o Tipo de Protocolo em S5/S8, Rede

Servidora) ao GW Servidor selecionado.

Caso Otimização de CIoT EPS de Plano de Controle se aplique, então, a MME também deve indicar tunelamento de S11- U de dados de usuário de NAS e enviar seu próprio endereço de S11-U IP e MME DL TEID para dados de DL encaminhados pelo SGW.

As informações de CSG de usuário incluem ID de CSG, modo de acesso e indicação de membro de CSG.

Para tipo de PDN "não IP", quando otimizações de CIoT EPS de plano de controle são habilitadas para o UE, caso dados de assinatura de APN indiquem que uma conexão de SCEF precisa ser usada, então, a MME aloca uma Identidade de Transportador de EPS para o transportador padrão associado ao UE e estabelece uma conexão com o endereço de SCEF indicado em dados de assinatura, conforme TS 23.682 [74] e as etapas 12,13,14,15,16 não são executadas.

O restante das interações com o UE se aplica, conforme especificado abaixo.

Caso a MME determine que a conexão de PDN deve usar apenas a Otimização de CIoT EPS de Plano de Controle, a MME deve incluir um Indicador de Conexão de PDN Apenas de Plano de Controle em Solicitação de Criação de Sessão.

Caso o Tipo de Solicitação indique "Emergência", controle de restrição máxima de APN não deve ser realizado.

Para o UEs vinculados como emergência, IMSI é incluída, caso disponível, e caso a IMSI não possa ser autenticada, então, a IMSI deve ser marcada como não autenticada.

O tipo de RAT é fornecido nessa mensagem para a decisão de PCC posterior.

O tipo de RAT deve distinguir entre os tipos NB-IoT e WB-E-UTRA.

A APN-AMBR assinada para o APN também é fornecida nessa mensagem.

A MSISDN é incluída caso fornecida nos dados de assinatura do HSS.

A Indicação de Handover é incluída caso o Tipo de Solicitação indique handover.

O Modo de

Seleção indica se um APN assinado foi selecionado, ou se um APN não assinado enviado pelo UE foi selecionado.

As Características de Carregamento indicam por qual tipo de carregamento o contexto de transportador é responsável.

A MME pode mudar o tipo de PDN solicitado de acordo com os dados de assinatura para esse APN, conforme descrito na cláusula 5.3.1.1. A MME deve definir a flag de Transportador de Endereço Duplo quando o tipo de PDN é definido para IPv4v6 e todos os SGSNs para os quais o UE pode ser submetido a handover são Versão 8 ou acima que suporta endereçamento duplo, que é determinado com base em pré-configuração de nó pelo operador.

O Tipo de Protocolo em S5/S8 é fornecido para GW Servidor cujo protocolo deve ser usado em interface S5/S8. As características de carregamento para a assinatura PS e APNs individualmente assinados bem como o modo de manipular Características de Carregamento e a possibilidade de enviar ou não os mesmos para o P-GW são definidos em TS 32.251 [44]. A MME deve incluir Referência de Rastreio, Tipo de Rastreio, Id de Disparo e Identidade de OMC, caso o rastreio de S-GW e/ou P-GW seja ativado.

A MME deve copiar Referência de Rastreio, Tipo de Rastreio e Identidade de OMC das informações de rastreio recebidas do HLR ou OMC.

A Restrição Máxima de APN denota a restrição mais rigorosa, conforme exigido por qualquer contexto de transportador já ativo.

Caso não haja contextos de transportador já ativos, esse valor é definido para o tipo menos restritivo (consulte a cláusula 15.4 de TS 23.060 [7]). Caso o P-GW receba a Restrição Máxima de APN, então, o P-GW deve verificar se a Restrição Máxima de APN valor não entra em conflito com o valor de restrição de APN associado a essa solicitação de contexto de transportador.

Caso não haja conflito, a solicitação deve ser permitida, de outro modo, a solicitação deve ser rejeitada com o envio de uma causa de erro apropriada para o UE.

Caso a MME exija que o eNB verifique se as capacidades de rádio de UE são compatíveis com a configuração de rede (por exemplo, se a SRVCC ou frequência suportada pelo UE corresponde àquela da rede) para ter a capacidade de definir a Indicação de Voz sobre IMS de sessão PS Suportada (consulte a cláusula 4.3.5.8), então, a MME pode enviar uma Solicitação de Correspondência de Capacidade de Rádio de UE para o eNB, conforme definido na cláusula 5.3.14.

13. O GW Servidor cria uma nova entrada em sua tabela de Transportador de EPS e envia uma mensagem de Solicitação de Criação de Sessão (IMSI, MSISDN, APN, Endereço de GW Servidor para o plano de usuário, TEID de GW Servidor do plano de usuário, TEID de GW Servidor do plano de controle, tipo de RAT, QoS de Transportador de EPS Padrão, Tipo de PDN, Endereço de PDN, APN-AMBR assinada, Identidade de Transportador de EPS, Opções de Configuração de Protocolo, Indicação de Handover, Identidade de ME, Informações de Localização de Usuário (ECGI), Fuso Horário de UE, Informações de CSG de Usuário, indicação de suporte de Relatório de Mudança de Info de MS, indicação de Suporte de Pausa de Carregamento de PDN, Modo de Seleção, Características de Carregamento, Referência de Rastreio, Tipo de Rastreio, Id de Disparo, Identidade de OMC, Restrição Máxima de APN, Flag de Transportador de Endereço Duplo, Rede Servidora) ao PDN GW indicado pelo endereço de PDN GW recebido na etapa anterior. Após essa etapa, o GW Servidor armazena em buffer quaisquer pacotes de enlace descendente que o mesmo pode receber do PDN GW sem enviar uma mensagem Notificação de Dados de Enlace Descendente para a MME até que receba a mensagem de Solicitação de Modificação de Transportador na etapa 23 abaixo. A MSISDN é incluída, caso recebida da MME. Caso o GW Servidor tenha recebido o Indicador de Conexão de PDN Apenas de Plano de Controle, na etapa 12, o GW Servidor informa o PGW dessas informações na Solicitação de Criação de Sessão. O GW Servidor e PDN GW devem indicar o uso de CP apenas em seus CDRs. PDN GWs não devem realizar quaisquer verificações de Restrição Máxima de APN caso a Solicitação de Criação de Transportador Padrão inclua o APN de emergência. Para o UEs vinculados como emergência, IMSI é incluída, caso disponível, e caso a IMSI não possa ser autenticada, então, a IMSI deve ser marcada como não autenticada. No caso de vinculação de handover, e caso o PGW detecte que o Status de UE de Desligamento de dados PS de 3GPP mudou, o PGW deve indicar esse evento ao sistema de carregamento para carregamento offline e online.

14. Caso PCC dinâmico seja implementado e a Indicação de Handover não esteja presente, o PDN GW realiza um procedimento de Estabelecimento de Sessão de IP-CAN, conforme definido em TS 23.203 [6], e obtém, desse modo, as regras de PCC padrão para o UE. Isso pode levar ao estabelecimento de um número de transportadores dedicados seguindo os procedimentos definidos na cláusula 5.4.1 em associação ao estabelecimento do transportador padrão, que é descrito no Anexo F. A IMSI, APN, endereço de IP de UE, Informações de Localização de Usuário (ECGI), Fuso Horário de UE, Rede Servidora, tipo de RAT, APN-AMBR, QoS de Transportador de EPS Padrão, ETFTU (caso ETFTU não seja fornecido, significa que UE e/ou o PDN GW não suporta o formato de filtro de TFT estendido) são fornecidos à PCRF pelo PDN GW, caso recebidos pela mensagem anterior. As Informações de Localização de Usuário e Fuso Horário de UE são usados para carregamento com base em localização. Para o UEs vinculados como emergência que não são autenticados, o PDN GW fornece a IMEI como a Identidade de UE em vez de IMSI, à PCRF. Caso a PCRF decida que a conexão de PDN pode usar o formato de filtro de TFT estendido, a mesma deve retornar o indicador de ETFTN ao PDN GW para inclusão nas Opções de Configuração de Protocolo que retornaram ao UE.

A PCRF pode modificar a APN-AMBR e os parâmetros de QoS (QCI e ARP) associados à transportador padrão na resposta ao PDN GW, conforme definido em TS 23.203 [6]. Caso o PCC seja configurado para suportar serviços de emergência e caso PCC dinâmico seja implementado, a PCRF, com base no APN de emergência, define a ARP das regras de PCC para um valor que é reservado para serviços de emergência e a autorização de regras de PCC dinâmico, conforme descrito em TS 23.203 [6]. Caso PCC dinâmico não seja implementado, o PDN GW usa a ARP do transportador de EPS de emergência padrão para qualquer transportador de EPS de emergência dedicada potencialmente iniciada.

O P-GW determina que serviços de emergência sejam solicitados com base no APN de emergência recebido na mensagem de Solicitação de Criação de Sessão.

NOTA 10: Embora o PDN GW/PCEF possa ser configurado para ativar regras de PCC predefinidas para o transportador padrão, a interação com a PCRF ainda é exigida para fornecer, por exemplo, as informações de endereço de IP de UE à PCRF.

NOTA 11: Caso o endereço de IP não esteja disponível quando o PDN GW realiza o procedimento de Estabelecimento de Sessão de IP-CAN com a PCRF, o PDN GW inicia um procedimento de Modificação de Sessão de IP-CAN para informar à PCRF sobre um endereço de IP alocado assim que o endereço estiver disponível.

Nessa versão da especificação, isso é aplicável apenas à alocação de endereço de IPv4. Caso PCC dinâmico seja implementado e a Indicação de Handover esteja presente, o PDN GW executa um procedimento de Modificação de Sessão de IP-CAN iniciada por PCEF com a PCRF, conforme especificado em TS 23.203 [6]

para relatar o novo tipo de IP-CAN. Dependendo das regras de PCC ativo, o estabelecimento de transportadores dedicados para o UE pode ser exigido. O estabelecimento daqueles transportadores deve ocorrer em combinação com a ativação de transportador padrão, conforme descrito no Anexo F. Esse procedimento pode continuar sem esperar por uma resposta de PCRF. Caso mudanças nas regras de PCC ativo sejam necessárias, a PCRF pode fornecer as mesmas após o procedimento de handover ser concluído. Em ambos os casos (Indicação de Handover está presente ou não), caso PCC dinâmico não seja implementado, o PDN GW pode aplicar política de QoS local. Isso pode levar ao estabelecimento de um número de transportadores dedicados para o UE seguindo os procedimentos definidos na cláusula 5.4.1 em combinação com o estabelecimento do transportador padrão, que é descrito no Anexo F. Caso os disparos de relatório de informações de CSG sejam recebidos da PCRF, o PDN GW deve definir o IE de Ação de Relatório de Informações de CSG em conformidade. O comportamento adicional do PGW para Desligamento de Dados PS de 3GPP é definido em TS 23.203 [6].

15. O P-GW cria uma nova entrada em sua tabela de contexto de transportador de EPS e gera um Id de Carregamento para o transportador Padrão. A nova entrada permite que o P-GW realize roteamento de PDUs de plano de usuário entre o S-GW e a rede de dados de pacote, e inicie carregamento. O modo que o P-GW manipula Características de Carregamento que o mesmo pode ter recebido é definido em TS 32.251 [44]. O PDN GW retorna uma mensagem de Resposta de Criação de Sessão (Endereço de PDN GW para o plano de usuário, PDN GW TEID do plano de usuário, PDN GW TEID do plano de controle, Tipo de PDN, Endereço de PDN,

Identidade de Transportador de EPS, QoS de Transportador de EPS, Opções de Configuração de Protocolo, Id de Carregamento, Compressão de Carga Útil Proibida, Restrição de APN, Causa, Ação de Relatório de Mudança de Info de MS (Início) (caso o PDN GW decida receber informações de localização de UE durante a sessão), Ação de Relatório de Informações de CSG (Início) (caso o PDN GW decida receber informações de CSG de Usuário de UE durante a sessão), Ação de Área de Relatório de Presença (caso o PDN GW decida receber notificações sobre uma mudança de presença de UE em Área de Relatório de Presença), indicação de Pausa de Carregamento de PDN Habilitada (caso PDN GW tenha escolhido habilitar a função), APN-AMBR, Conexão Tolerante a atrasos) ao GW Servidor.

O PDN GW leva em consideração o tipo de PDN recebido, a flag de Transportador de Endereço Duplo e as políticas de operador quando o PDN GW seleciona o tipo de PDN a ser usado conforme a seguir.

Caso o tipo de PDN recebido seja IPv4v6 e tanto endereçamento de IPv4 quanto de IPv6 sejam possíveis na PDN, mas a flag de Transportador de Endereço Duplo não seja definida, ou apenas endereçamento de única versão de IP para esse APN seja possível na PDN, o PDN GW seleciona uma única versão de IP (IPv4 ou IPv6). Caso o tipo de PDN recebido seja IPv4 ou IPv6 ou "Não IP", o PDN GW usa o tipo de PDN recebido caso seja suportado na PDN, de outro modo, uma causa de erro apropriada será retornada.

Para IPv4, IPv6 e IPv4v6, o PDN GW aloca um Endereço de PDN de acordo com o tipo de PDN selecionado.

Caso o PDN GW tenha selecionado um tipo de PDN diferente do tipo de PDN recebido, o PDN GW indica, em conjunto com o IE de tipo de PDN, uma causa para o UE pela qual o tipo de PDN foi modificado, conforme descrito na cláusula 5.3.1.1. O PDN GW deve aceitar ou rejeitar (mas não modificar) o tipo de PDN, caso o tipo de PDN seja definido para "Não IP". O Endereço de PDN pode conter um endereço de

IPv4 para IPv4 e/ou um prefixo de IPv6 e um Identificador de Interface, ou ser omitido para tipo de PDN "Não IP". Caso o PDN tenha sido configurado pelo operador de modo que os endereços de PDN para o APN solicitado devam ser alocados através de uso de DHCPv4 apenas, ou caso o PDN GW permita que o UE use DHCPv4 para alocação de endereço de acordo com a Preferência de Alocação de Endereço recebida do UE, o endereço de PDN deve ser definido para

0.0.0.0, que indica que o endereço de PDN IPv4 deve ser negociado pelo UE com DHCPv4 após conclusão do procedimento de Ativação de Transportador Padrão. Para endereçamento de PDN externo para IPv6, o PDN GW obtém o prefixo de IPv6 do PDN externo tanto com o uso de função de cliente diameter ou RADIUS. No campo de Endereço de PDN da Resposta de Criação de Sessão, o PDN GW inclui o Identificador de Interface e prefixo de IPv6. O PDN GW envia Anúncio de Roteador para o UE após estabelecimento de transportador padrão com as informações de prefixo de IPv6 para todos os casos. Caso o endereço de PDN esteja contido na Solicitação de Criação de Sessão, o PDN GW deve alocar o endereço de IPv4 e/ou prefixo de IPv6 contido no endereço de PDN para o UE. Os detalhes de alocação de endereço de IP são descritos na cláusula 5.3.1 em "Alocação de Endereço de IP". O PDN GW deriva o BCM com base no NRSU e política de operador. O PDN GW deriva se o formato de filtro de TFT estendido deve ser usado com base no ETFTU, ETFTN recebido da PCRF e política de operador. As Opções de Configuração de Protocolo contêm o BCM, ETFTN bem como parâmetros de PDN opcionais que o P-GW pode transferir para o UE. Esses parâmetros de PDN opcionais podem ser solicitados pelo UE, ou podem ser enviados sem solicitação pelo P-GW. As Opções de Configuração de Protocolo são enviadas de modo transparente através da MME. O PDN GW inclui uma indicação de Conexão Tolerante a atrasos caso o PDN GW suporte o recebimento de uma causa de rejeição do SGW que indica que o UE está temporariamente inacessível devido à economia de energia e procedimentos terminados em terminal móvel em espera, até que o PDN GW receba uma mensagem que indica que o UE está disponível para sinalização de extremidade a extremidade. Quando a Indicação de Handover está presente, o PDN GW não envia ainda pacotes de enlace descendente ao S-GW; a trajetória de enlace descendente deve ser comutada na etapa 23a. Caso o PDN GW seja um L-GW, o mesmo não encaminha pacotes de enlace descendente para o S-GW. Os pacotes serão encaminhados para o HeNB apenas na etapa 20 por meio da trajetória de plano de usuário direta.

16. O GW Servidor retorna uma mensagem de Resposta de Criação de Sessão (Tipo de PDN, Endereço de PDN, Endereço de GW Servidor para Plano de Usuário, TEID de GW Servidor para Plano de Usuário S1-U, TEID de GW Servidor para plano de controle, Identidade de Transportador de EPS, QoS de Transportador de EPS, endereços de PDN GW e TEIDs (S5/S8 com base em GTP) ou chaves de GRE (S5/S8 com base em PMIP) no PDN GW(s) para tráfego de enlace ascendente, Opções de Configuração de Protocolo, Compressão de Carga Útil Proibida, Restrição de APN, Causa, Ação de Relatório de Mudança de Info de MS (Início), Ação de Área de Relatório de Presença, Ação de Relatório de Informações de CSG (Início), APN-AMBR, Conexão Tolerante a atrasos) para a nova MME. Para otimização de CIoT EPS de Plano de Controle, o endereço de GW Servidor para Plano de Usuário de S11-U e TEID de GW Servidor são usados pela MME para encaminhar dados de UL ao SGW. Caso o Status de UE de Desligamento de Dados PS de 3GPP esteja presente nas PCO de Solicitação de Criação de Sessão e o PGW suporte recurso de Desligamento de Dados PS de 3GPP, o PGW deve incluir a indicação de Suporte de Desligamento de Dados PS de 3GPP nas PCO de Resposta de Criação de Sessão.

17. Caso uma Restrição de APN seja recebida, então, a MME deve armazenar esse valor para o Contexto de Transportador e a MME deve verificar esse valor recebido com o valor armazenado para a Restrição Máxima de APN para garantir que não haja conflitos entre valores.

Caso o Contexto de Transportador seja aceito, a MME deve determinar um (novo) valor para a Restrição Máxima de APN.

Caso não haja valor previamente armazenado para a Restrição Máxima de APN, então, a Restrição Máxima de APN deve ser definida para o valor da Restrição de APN recebida.

A MME não deve desativar transportador(es) com ARP de emergência, caso presente, para manter combinação de restrição de APN válido.

O P-GW deve ignorar Restrição Máxima de APN, caso a solicitação inclua o APN de Emergência.

Caso a Ação de Relatório de Mudança de Info de MS (Início) e/ou a Ação de Relatório de Informações de CSG (Início) sejam recebidas para esse contexto de transportador, então, a MME deve armazenar as mesmas para o contexto de transportador e a MME deve relatar àquele P-GW por meio do S-GW sempre que uma mudança de localização de UE e/ou informações de CSG de usuário ocorrer que satisfaz a solicitação de P-GW, conforme descrito na cláusula 15.1.1a de TS 23.060 [7]. Caso a Ação de Área de Relatório de Presença seja recebida para esse contexto de transportador, a MME deve armazenar essas informações para o contexto de transportador e deve relatar àquele P-GW por meio do S-GW sempre que uma mudança de presença de UE em uma Área de Relatório de Presença é detectada, conforme descrito na cláusula 5.9.2.2. A MME determina O UE AMBR a ser usada pelo eNodeB com base no UE- AMBR assinada e na APN-AMBR para o APN padrão, consulte a cláusula 4.7.3. Para a vinculação de emergência, a MME determina O UE-AMBR a ser usada pelo eNodeB da APN AMBR recebida do S-GW.

Caso a nova MME não tenha recebido, na etapa 12, Indicador de Correspondência de Suporte de Voz para o UE do eNB, então, com base em implantação, a MME pode definir Indicação de Voz sobre IMS de sessão PS suportada e atualizar a mesma em um estágio posterior.

A nova MME envia uma mensagem de Aceitação de vinculação (GUTI, Lista de TAI, Solicitação de Gerenciamento de Sessão (APN, Tipo de PDN, Endereço de PDN, Identidade de Transportador de EPS, Opções de Configuração de Protocolo, Configuração de Compressão de Cabeçalho, Indicador apenas de Plano de Controle), número de sequência de NAS, NAS-MAC, indicação de Voz sobre IMS de sessão PS suportada, indicador de Suporte de Serviço de Emergência, Indicação de Suporte de LCS, Comportamento de Rede Suportada, Gap de Serviço) ao eNodeB.

GUTI é incluído caso a nova MME aloque um novo GUTI.

Tipo de PDN e Endereço de PDN são omitidos caso a Solicitação de Vinculação (etapa 1) não contenha um contêiner de mensagem de ESM.

A MME indica as otimizações de CIoT EPS que a mesma aceita nas Informações de Comportamento de Rede Suportadas, conforme definido na cláusula 4.3.5.10. O parâmetro de Gap de Serviço é incluído, caso Gap de Serviço esteja presente nas informações de assinatura (etapa 11) e o UE tenha indicado capacidade de Gap de Serviço na capacidade de rede de UE.

Essa mensagem está contida em uma Solicitação de Preparação de contexto Inicial de mensagem de controle de S1_MME, a menos que a MME tenha selecionado o uso da otimização de CIoT EPS de Plano de Controle, ou, o UE não tenha incluído o contêiner de mensagem de ESM na Solicitação de Vinculação (etapa 1), em qualquer um dos casos, uma mensagem de transporte de NAS de Enlace Descendente de S1-AP é usada.

A mensagem de Solicitação de Preparação de contexto Inicial de S1-AP também inclui as informações de contexto de segurança de AS para o UE, a Lista de Restrição de Handover, a QoS de Transportador de EPS, O UE-AMBR, Identidade de transportador de EPS, bem como o TEID no GW Servidor usado para plano de usuário e o endereço do GW Servidor para plano de usuário e se Otimização de CIoT EPS de Plano de Usuário é permitida para o UE.

Caso o tipo de PDN seja definido para "Não IP", a MME inclui o mesmo na Solicitação de Preparação de contexto Inicial de S1-AP de modo que o eNodeB desabilite compressão de cabeçalho.

Além disso, caso a conexão de PDN seja estabelecida para Acesso de IP Local, a mensagem de Solicitação de Preparação de contexto Inicial de S1 correspondente inclui um ID de Correlação para habilitar a trajetória de plano de usuário direta entre o HeNB e o L-GW.

Caso a conexão de PDN seja estabelecida para SIPTO na Rede Local com função de L-GW justaposta ao (H)eNB, a mensagem de Solicitação de Preparação de contexto Inicial de S1-AP correspondente inclui um ID de Correlação de SIPTO para habilitar a trajetória de plano de usuário direta entre o (H)eNB e o L-GW.

LIPA e SIPTO não se aplicam à Otimização de CIoT EPS de Plano de Controle.

NOTA 12: Nessa versão da especificação de 3GPP, o ID de Correlação e ID de Correlação de SIPTO são definidos de modo igual ao PDN GW TEID de plano de usuário (S5 com base em GTP) ou chave de GRE (S5 com base em PMIP) que a MME recebeu na etapa 16. Caso otimização de CIoT EPS de Plano de Controle se aplique para uma conexão de PDN de IP, e o UE tenha enviado na Solicitação de Vinculação a Configuração de Compressão de Cabeçalho, e a MME suporte os parâmetros de compressão de cabeçalho, a MME deve incluir a Configuração de Compressão de Cabeçalho na mensagem de Aceitação de Conectividade de PDN.

A MME também liga os canais ROHC de enlace ascendente e enlace descendente para suportar sinalização de realimentação de compressão de cabeçalho.

Caso o UE tenha incluído parâmetros de preparação de contexto de compressão de cabeçalho em Configuração de Compressão de Cabeçalho na Solicitação de

Vinculação, a MME pode reconhecer os parâmetros de preparação de contexto de compressão de cabeçalho.

Caso o contexto de ROHC não seja estabelecido durante o procedimento de vinculação para a conexão de PDN, antes de usar o formato comprimido para enviar os dados, o UE e a MME precisam estabelecer o contexto de ROHC com pacote de ROHC IR com base em Configuração de Compressão de Cabeçalho.

Caso a MME, com base em política local, determine que a conexão de PDN deve usar apenas a Otimização de CIoT EPS de Plano de Controle, a MME deve incluir um Indicador Apenas de Plano de Controle na Solicitação de Gerenciamento de Sessão.

Para conexões de PDN com uma SCEF, a MME deve incluir sempre o Indicador Apenas de Plano de Controle.

Um UE que recebe o Indicador Apenas de Plano de Controle, para uma conexão de PDN, deve usar apenas a otimização de CIoT EPS de Plano de Controle para essa conexão de PDN.

Caso o contêiner de ESM não esteja incluído na Solicitação de Vinculação na etapa 1, então, a mensagem de Aceitação de vinculação não deve incluir parâmetros relacionados à PDN, e a mensagem de S1-AP de transferência de NAS de Enlace Descendente não deve incluir informações relacionadas a contexto de estrato de acesso, mas pode incluir informações relacionadas a CSG.

Caso o tipo de vinculação não seja definido para "Emergência", e o contêiner de ESM esteja incluído na Solicitação de Vinculação na etapa 1, e o UE tenha indicado suporte de Vinculação sem Conexão de PDN na Solicitação de Vinculação, e a MME suporte Vinculação sem Conexão de PDN, e restrição de conexão de PDN seja definida em dados de assinante, então, a MME deve descartar o contêiner de ESM na mensagem de Solicitação de Vinculação, e não deve incluir parâmetros relacionados à PDN na Aceitação de vinculação, mas pode incluir informações relacionadas a CSG.

Na mensagem de Aceitação de vinculação, a MME não inclui o prefixo de

IPv6 dentro do Endereço de PDN.

A MME inclui o parâmetro de QoS de Transportador de EPS QCI e APN-AMBR na Solicitação de Gerenciamento de Sessão.

Além disso, caso o UE tenha capacidades de UTRAN ou GERAN e a rede suporte mobilidade para UTRAN ou GERAN, a MME usa as informações de QoS de transportador de EPS para derivar os parâmetros de contexto de PDP correspondentes QoS Negociada (perfil de QoS de R99), Prioridade de Rádio, Id de Fluxo de Pacote e TI e inclui os mesmos na Solicitação de Gerenciamento de Sessão.

Caso o UE tenha indicado na Capacidade de Rede de UE que o mesmo não suporta procedimentos de fluxo de pacote de BSS, então, a MME não deve incluir o Id de Fluxo de Pacote.

A Lista de Restrição de Handover é descrita na cláusula 4.3.5.7 "Restrições de Mobilidade". A MME define a indicação suportada de Voz sobre IMS de sessão PS, conforme descrito na cláusula 4.3.5.8. A Indicação de Suporte de LCS indica se a rede suporta o EPC-MO-LR e/ou CS- MO-LR, conforme descrito em TS 23.271 [57]. A MME pode incluir uma indicação da possibilidade de se permitir que o tráfego dessa Conexão de PDN seja descarregado para WLAN, conforme descrito na cláusula 4.3.23. Caso o UE inicie o procedimento de Vinculação em uma célula híbrida, a MME deve verificar se o ID de CSG está contido na assinatura de CSG e não está expirado.

A MME deve enviar uma indicação da possibilidade de o UE ser um membro de CSG na RAN em conjunto com a mensagem de controle de S1-MME.

Com base nessas informações, a RAN pode realizar tratamento diferenciado para membros CSG e não CSG.

Caso a MME ou PDN GW tenha mudado o Tipo de PDN, uma causa apropriada deve retornar ao UE, conforme descrito na cláusula 5.3.1.1. Caso o UE tenha indicado tipo de PDN "Não IP", a MME e PDN GW não devem mudar tipo de PDN.

Para um UE vinculado como emergência, isto é, Para o UEs que têm apenas transportadores de EPS de emergência estabelecidos, não há informações de contexto de segurança de AS incluídas nas mensagens de controle de S1 e não há segurança de nível de NAS quando o UE não pode ser autenticado. O indicador de Suporte de Serviço de Emergência informa o UE que serviços de transportador de emergência são suportados, isto é, permite-se que o UE solicite conectividade de PDN para serviços de emergência. Caso o UE tenha incluído elemento de informações de parâmetros de DRX de modo ocioso estendido, a MME inclui elemento de informações de parâmetros de DRX de modo ocioso estendido caso decida habilitar DRX de modo ocioso estendido. Caso o UE tenha incluído suporte para restrição de uso de Cobertura Aprimorada, a MME envia parâmetro de Cobertura Aprimorada Restrita ao eNB na mensagem de Solicitação de Preparação de contexto Inicial de S1-AP. A MME também envia parâmetro de Cobertura Aprimorada Restrita ao UE na mensagem de Aceitação de vinculação.

18. Caso o eNodeB tenha recebido uma Solicitação de Preparação de contexto Inicial de S1-AP, o eNodeB envia a mensagem de Reconfiguração de Conexão de RRC que inclui a Identidade de Transportador de Rádio de EPS ao UE, e a mensagem de Aceitação de vinculação será enviada ao UE. Caso o eNodeB tenha recebido uma mensagem de Transporte de NAS de Enlace Descendente de S1-AP (por exemplo, contendo a mensagem de Aceitação de vinculação), o eNode B envia uma mensagem de Transferência Direta de RRC ao UE. O UE deve armazenar a QoS Negociada, Prioridade de Rádio, Id de Fluxo de Pacote e TI, que o mesmo recebeu na Solicitação de Gerenciamento de Sessão, para uso ao acessar por meio de GERAN ou UTRAN. O APN é fornecido ao UE para notificar o mesmo do APN ao qual o transportador padrão ativado é associado.

Para detalhes adicionais, consulte TS 36.331 [37]. O UE pode fornecer parâmetros de QoS de Transportador de EPS à aplicação que manipula o fluxo(s) de tráfego.

O uso de aplicação do QoS de Transportador de EPS é dependente de implantação.

O UE não deve rejeitar a Reconfiguração de Conexão de RRC com base nos parâmetros de QoS de Transportador de EPS contidos na Solicitação de Gerenciamento de Sessão.

Caso o UE receba parâmetro de Cobertura Aprimorada Restrita na mensagem de Aceitação de vinculação, o UE deve armazenar essas informações e deve usar o valor de parâmetro de Cobertura Aprimorada Restrita para determinar se recurso de Cobertura Aprimorada deve ou não ser usado.

Caso o UE receba uma Gap de Serviço na mensagem de Aceitação de vinculação, o UE deve armazenar esse parâmetro e aplicar controle de gap de serviço para solicitações de conexão de dados originadas em terminal móvel (consulte a cláusula 4.3.x acima). Caso o procedimento de vinculação seja iniciado por seleção de CSG manual e ocorra por meio de uma célula de CSG, o UE, mediante recepção da aceitação de vinculação, deve verificar se o ID de CSG e PLMN associada da célula para onde o UE enviou a mensagem de Solicitação de Vinculação estão contidos em sua lista de CSG Permitido.

Caso o ID de CSG e PLMN associada não estejam na lista de CSG Permitido de UE, o UE deve adicionar o ID de CSG e PLMN associada à sua lista de CSG Permitido.

A seleção de CSG Manual não é suportada quando um serviço de emergência tiver sido iniciado.

NOTA 13: Caso o UE receba uma mensagem de Aceitação de vinculação por meio de uma célula híbrida, o UE não adiciona o ID de CSG correspondente e PLMN associada à sua lista de CSG Permitido.

A adição de um ID de CSG e PLMN associada à lista de CSG Permitido local de UE para uma célula híbrida é realizada apenas por procedimentos de DM OTA ou OMA.

Ao receber a mensagem de Aceitação de vinculação, o UE deve definir seu TIN para "GUTI", visto que nenhum ISR Ativado é indicado. Caso o UE receba um endereço de IPv4 definido para 0.0.0.0, o mesmo pode negociar o endereço de IPv4 com DHCPv4, conforme especificado em TS 29.061 [38]. Caso o UE receba um Identificador de Interface de IPv6, o mesmo pode aguardar o Anúncio de Roteador da rede com as informações de prefixo de IPv6 ou o mesmo pode enviar uma Solicitação de Roteador, caso necessário. NOTA 14: Os detalhes de alocação de endereço de IP são descritos na cláusula 5.3.1 em "Alocação de Endereço de IP". Caso Otimização de CIoT EPS de Plano de Controle se aplique ou o UE não tenha incluído o contêiner de mensagem de ESM na Solicitação de Vinculação na etapa 1, então, as etapas 19 e 20 não são executadas.

19. O UE envia a mensagem de Conclusão de Reconfiguração de Conexão de RRC ao eNodeB. Para detalhes adicionais, consulte TS 36.331 [37].

20. O eNodeB envia a mensagem de Resposta de Contexto Inicial para a nova MME. Essa mensagem de Resposta de Contexto Inicial inclui o TEID do eNodeB e o endereço do eNodeB usado para tráfego de enlace descendente no ponto de referência de S1_U. A MME deve ser preparada para receber essa mensagem antes ou após a mensagem de Conclusão de Vinculação (enviada na etapa 22). Caso o ID de Correlação ou ID de Correlação de SIPTO tenha sido incluído na mensagem de Solicitação de Preparação de contexto Inicial, o eNodeB deve usar as informações incluídas para estabelecer trajetória de plano de usuário direta com o L-GW e encaminhar dados de enlace ascendente para Acesso de IP Local ou SIPTO na Rede Local com função de L-GW justaposta ao (H)eNB em conformidade.

21. O UE envia uma mensagem de Transferência Direta ao eNodeB, que inclui a mensagem de Conclusão de Vinculação (Identidade de Transportador de EPS, número de sequência de NAS, NAS-MAC). Caso o UE tenha omitido o contêiner de mensagem de ESM da mensagem de Solicitação de Vinculação na etapa 1, então, a Identidade de Transportador de EPS é omitida da mensagem de Conclusão de Vinculação.

22. O eNodeB encaminha a mensagem de Conclusão de Vinculação para a nova MME em uma mensagem de Transporte de NAS de Enlace Ascendente. Caso o contêiner de mensagem de ESM tenha sido incluído na etapa 1, após a mensagem de Aceitação de vinculação e uma vez que o UE tiver obtido (caso aplicável ao tipo de PDN) um endereço de PDN, o UE pode enviar, então, pacotes de enlace ascendente para o eNodeB que serão, então, tunelados para o GW Servidor e PDN GW. Caso Otimizações de CIoT EPS de Plano de Controle se apliquem, dados de UL são enviados, conforme especificado na cláusula 5.3.4B. Caso o UE tenha solicitado um tipo de PDN de endereço duplo (IPv4v6) para um determinado APN e tenha sido concedido um tipo de PDN de endereço único (IPv4 ou IPv6) pela rede com uma causa que indica que apenas versão de único IP por conexão de PDN é permitida, enviado em conjunto com o tipo de PDN, o UE deve solicitar a ativação de uma conexão de PDN paralela ao mesmo APN com um tipo de PDN de endereço único (IPv4 ou IPv6) diferente do já ativado. Caso o UE não receba causa na etapa 18 em resposta a um tipo de PDN IPv4v6 e receba um Identificador de Interface de IPv6 além do endereço de IPv4 ou 0.0.0.0 no campo de Endereço de PDN, o mesmo considera que a solicitação de uma PDN de endereço duplo foi bem-sucedida. O mesmo pode esperar pelo Anúncio de Roteador da rede com as informações de prefixo de IPv6 ou pode enviar Solicitação de Roteador, caso necessário.

23. Mediante recepção de ambas, a mensagem de Resposta de

Contexto Inicial na etapa 20 e a mensagem de Conclusão de Vinculação na etapa 22, a nova MME envia uma mensagem de Solicitação de Modificação de Transportador (Identidade de Transportador de EPS, endereço de eNodeB, TEID de eNodeB, Indicação de Handover, Informações de Área de Relatório de Presença) ao GW Servidor.

Caso a otimização de CIoT EPS de Plano de Controle se aplique e a conexão de PDN não seja servida por uma SCEF e caso a MME não precise relatar uma mudança de presença de UE em Área de Relatório de Presença, o envio de Solicitação de Modificação de Transportador e as etapas 23a, 23b e 24 são pulados; de outro modo, caso a conexão de PDN seja servida pela SCEF, as etapas 23,24, 25 e 26 não são executadas.

Caso a MME tenha sido solicitada para relatar uma mudança de presença de UE em Área de Relatório de Presença, a MME inclui, nessa mensagem, as Informações de Área de Relatório de Presença que compreendem o identificador(es) de PRA e indicação(ões) da possibilidade de o UE estar dentro ou fora da área(s). Ao receber a solicitação para relatar mudança de presença de UE em Área de Relatório de Presença, e a MME decidir não ativar relatório de presença de UE em uma ou mais dentre a Área(s) de Relatório de Presença recebida, a MME relata também a Área(s) de Relatório de Presença inativa nessa mensagem. 23a.

Caso a Indicação de Handover esteja incluída na etapa 23, o GW Servidor envia uma mensagem de Solicitação de Modificação de Transportador (Indicação de Handover) ao PDN GW para alertar ao PDN GW para que realize tunelamento de pacotes de sistema de acesso de IP não 3GPP para sistema de acesso 3GPP e inicie imediatamente o roteamento de pacotes para o GW Servidor para o padrão e quaisquer transportadores de EPS dedicados estabelecidas.

Caso Informações de Área de Relatório de Presença estejam incluídas na etapa 23, o GW Servidor envia uma mensagem de Solicitação de Modificação de Transportador (Informações de Área de Relatório de Presença)

ao PDN GW. NOTA 15: Espera-se que o PDN GW manipule os pacotes de enlace ascendente enviados pelo UE por meio de acesso 3GPP após a etapa 22, mesmo se os mesmos chegarem antes de comutação de trajetória na etapa 23. NOTA 16: O PDN GW encaminha as Informações de Área de Relatório de Presença à PCRF, ao OCS ou a ambos, conforme definido em TS 23.203 [6]. 23b. O PDN GW reconhece enviando-se Resposta de modificação de transportador ao GW Servidor.

24. O GW Servidor reconhece enviando-se mensagem de Resposta de modificação de transportador (Identidade de Transportador de EPS) à nova MME. O GW Servidor pode enviar, então, seus pacotes de enlace descendente armazenados em buffer. Caso haja um evento de monitoramento de "Disponibilidade após Falha de DDN” ou um evento de monitoramento de “Acessibilidade de UE” configurado para o UE no Contexto de EMM da MME, a MME envia uma notificação de evento (consulte TS 23.682 [74] para informações adicionais).

25. Após a MME receber a mensagem de Resposta de modificação de transportador (Identidade de Transportador de EPS), caso Tipo de Solicitação não indique handover e um transportador de EPS tenha sido estabelecida e os dados de assinatura indiquem que o usuário tem permissão para realizar handover para acessos não 3GPP e, caso a MME tenha selecionado um PDN GW que seja diferente da identidade de PDN GW que foi indicada pelo HSS no contexto de assinatura de PDN, a MME deve enviar uma Solicitação de Notificação que inclui o APN e identidade de PDN GW ao HSS para mobilidade com acessos não 3GPP. A mensagem deve incluir informações que identificam a PLMN onde o PDN GW está localizado. Caso a Identidade de ME do UE tenha mudado e a etapa 8 não tenha sido realizada, a MME envia uma mensagem de Solicitação de Notificação (Identidade de ME) para informar ao HSS da identidade de ME atualizada. Para um UE não autenticado ou roaming, caso o Tipo de Solicitação do procedimento de conectividade solicitado por UE indique "Emergência", a MME não deve enviar qualquer Solicitação de Notificação a um HSS. Para um UE não roaming autenticado, com base em configuração de operador (por exemplo, na possibilidade de voz sobre WLAN ser suportada ou não pelo operador, na possibilidade de o operador usar um PDN GW fixo para chamadas de emergência, etc.), caso o Tipo de Solicitação indique "Emergência", a MME pode enviar uma Solicitação de Notificação ao HSS que inclui o "PDN GW atualmente em uso para serviços de emergência", que compreende o endereço de PDN GW e uma indicação de que a conexão de PDN é para serviços de emergência. O HSS deve armazenar as informações como parte do contexto de UE para serviços de emergência. Após a etapa 8 e paralelamente a qualquer uma dentre as etapas antecedentes, a MME deve enviar uma mensagem de Solicitação de Notificação (Suporte Homogêneo de Voz sobre IMS de sessões PS) ao HSS: - Caso a MME tenha avaliado o suporte de Voz sobre IMS de sessões PS, consulte a cláusula 4.3.5.8, e - Caso a MME determine que a mesma precisa atualizar o Suporte Homogêneo de Voz sobre IMS de sessões PS, consulte a cláusula 4.3.5.8A.

26. No caso de serviços de não emergência, o HSS armazena o APN e par de identidade de PDN GW. No caso de serviços de emergência, o HSS armazena o "PDN GW atualmente em uso para serviços de emergência". O HSS envia, então, uma Resposta de Notificação à MME. NOTA 17: Para handover de acesso não 3GPP, o PDN GW inicia procedimento de desativação de alocação de recurso no acesso de IP não 3GPP confiável/não confiável, conforme especificado em TS 23.402 [2].

5.3.3.1 Procedimento de Atualização de Área de Rastreamento com mudança de GW Servidor Antigo GW Antiga Novo GW UE eNodeB RNC Nova MME MME/Antigo Servidor Servidor PDN GW HSS S4 SGSN

1. Disparo para Iniciar o procedimento de TAU PCRF

2. Solicitação de TAU 3. Solicitação de TAU

4. Solicitação de Contexto

5. Resposta de Contexto

6. Autenticação/Segurança

7. Confirmação de Contexto

8. Solicitação de Criação de Sessão

9. Solicitação de Modificação de Transportador 9a. Modificação de sessão de P-CAN iniciada por PCEF

10. Resposta de Modificação Transportador (A)

11. Resposta de Criação de Sessão

12. Atualização de Localização

13. Cancelamento de Localização

14. ACK de Cancelamento de Localização

15. Comando de Liberação de lu

16. Conclusão de Liberação de lu

17. ACK de Atualização de Localização

18. Solicitação de Exclusão de Sessão

20. Aceitação de TAU (B)

19. Resposta de Exclusão de Sessão

21. Conclusão de TAU Figura 5.3.3.1-1: Procedimento de Atualização de Área de Rastreamento com mudança de GW Servidor NOTA 1: Para um S5/S8 com base em PMIP, as etapas de procedimento (A) e (B) são definidas em TS 23.402 [2]. As etapas 9 e 10 se referem a S5/S8 com base em GTP. NOTA 2: No caso de Atualização de Área de Rastreamento sem mudança de MME, a sinalização nas etapas 4, 5, 7 e etapas 12 a 17 é pulada.

1. Um dos disparos descritos na cláusula 5.3.3.0 ocorre para iniciar o procedimento de TAU.

2. O UE inicia o procedimento de TAU enviando-se, ao eNodeB, uma mensagem de Solicitação de TAU (Capacidade de Rede núcleo de UE, Capacidade de Rede de MS, comportamento de Rede Preferencial, Suporte para restrição de uso de Cobertura Aprimorada, GUTI antigo, tipo de GUTI antigo, TAI visitada por último, flag ativa, flag ativa de sinalização, status de transportador de EPS, Assinatura de P-TMSI, GUTI adicional, eKSI, número de sequência de NAS, NAS- MAC, KSI, preferência de domínio de voz e definição de uso de UE) em conjunto com parâmetros de RRC que indicam a Rede Selecionada e o GUMMEI antigo.

Uma exceção é que, caso a TAU tenha sido disparada com a finalidade de reequilíbrio de carga (consulte a cláusula 4.3.7.3), o GUMMEI antigo não é incluído nos parâmetros de RRC.

O UE deve definir o Tipo de GUTI antigo para indicar se o GUTI antigo é um GUTI nativo ou é mapeado de uma P-TMSI e RAI.

Caso a TIN de UE indique "GUTI" ou "TMSI relacionada à-RAT" e o UE mantenha um GUTI válido, então, o GUTI antigo indica esse GUTI válido.

O mapeamento de uma P-TMSI e RAI para um GUTI é especificado no Anexo H.

Quando o UE está no modo conectado (por exemplo, em URA_PCH) quando o mesmo seleciona novamente para E-UTRAN, o UE deve definir seu TIN para "P-TMSI". Caso o UE mantenha um GUTI válido e o GUTI antigo indique um GUTI mapeado de uma P-TMSI e RAI, então, o UE indica o GUTI como GUTI adicional.

Caso o GUTI antigo indique um GUTI mapeado de uma P-TMSI e RAI e o UE tenha uma assinatura de P-TMSI válida, a assinatura de P-TMSI deve ser incluída.

O GUTI adicional na mensagem de Solicitação de Atualização de Área de Rastreamento permite que a nova MME encontre qualquer contexto de UE já existente armazenado na nova MME quando o GUTI antigo indica um valor mapeado de uma P-TMSI e RAI.

Alternativamente, quando um UE suporta apenas E-UTRAN, o mesmo se identifica com o GUTI antigo e define o Tipo de GUTI antigo para “nativo”. O parâmetro de RRC “GUMMEI antigo" obtém seu valor do identificador que é sinalizado como o GUTI antigo, de acordo com as regras acima.

Para um MME/SGSN combinado, o eNodeB é configurado para rotear o código(s) de MME desse nó combinado para o mesmo nó combinado.

Esse eNodeB também é configurado para rotear código(s) de MME de GUTIs que são gerados pelo mapeamento de UE das P-TMSIs alocadas pelo nó combinado.

Tal configuração de eNodeB também pode ser usada para nós separados para evitar mudança de nós no agrupamento causada por mobilidade entre RATs.

A TAI visitada por último deve ser incluída a fim de ajudar a MME a produzir uma boa lista de TAIs para qualquer mensagem de Aceitação de TAU subsequente.

A Rede Selecionada indica a rede que é selecionada.

A flag ativa é uma solicitação de UE para ativar o rádio e transportadores S1 para todos os transportadores de EPS ativos por meio do procedimento de TAU quando o UE está em estado ECM-OCIOSO.

A flag ativa de sinalização é uma solicitação de UE que usa Otimização de CIoT EPS de Plano de Controle para manter a conexão de sinalização de NAS após Procedimento de Atualização de Área de Rastreamento ser concluído a fim de transmitir Dados pendentes com o uso do Transporte de Dados em Otimização de CIoT EPS de Plano de Controle ou sinalização de NAS.

O status de transportador de EPS indica cada transportador de EPS que está ativo no UE.

A mensagem de Solicitação de TAU deve ter integridade protegida pelo NAS-MAC, conforme descrito em TS 33.401 [41]. eKSI, número de sequência de NAS e NAS-MAC são incluídos caso o UE tenha parâmetros de segurança de EPS válidos.

O número de sequência de NAS indica o número sequencial da mensagem de NAS.

KSI é incluído caso o UE indique um GUTI mapeado de uma

P-TMSI no elemento de informações “GUTI antigo". Para o UE que usa Otimização de CIoT EPS sem qualquer conexão de PDN ativada, não há flag ativa ou status de transportador de EPS incluído na mensagem de Solicitação de TAU. Para um UE com um temporizador de Gap de Serviço sendo executado no UE, a flag ativa e a flag ativa de sinalização não devem ser definidos na mensagem de solicitação de TAU (consulte a cláusula

4.3.x acima). Caso o UE tenha conexão de PDN de Tipo de PDN "não IP", UE deve indicar status de transportador de EPS incluído na mensagem de Solicitação de TAU. O UE define a preferência de domínio de voz e definição de uso de UE de acordo com a sua configuração, conforme descrito na cláusula 4.3.5.9. O UE inclui elemento de informações de parâmetros DRX de modo ocioso estendidos caso precise habilitar DRX de modo ocioso estendido, até mesmo se parâmetros DRX de modo ocioso estendidos já tiverem sido negociados antes. Caso um UE inclua um Comportamento de Rede Preferencial, isso define o Comportamento de Rede que o UE está esperando que esteja disponível na rede, conforme definido na cláusula 4.3.5.10.

3. O eNodeB deriva o endereço de MME dos parâmetros de RRC que portam o GUMMEI antigo, a Rede Selecionada indicada e a RAT (NB-IoT ou WB- E-UTRAN). Caso essa MME não seja associada àquele eNodeB ou o GUMMEI não esteja disponível ou o UE indique que o procedimento de TAU foi disparado por reequilíbrio de carga, o eNodeB seleciona uma MME, conforme descrito na cláusula 4.3.8.3 em “Função de Seleção de MME". O eNodeB encaminha a mensagem de Solicitação de TAU em conjunto com o modo de acesso de CSG, ID de CSG, TAI+ECGI da célula de onde o mesmo recebeu a mensagem e com a Rede Selecionada para a nova MME. O ID de CSG é fornecido pela RAN caso o UE envie a mensagem de Solicitação de TAU por meio de uma célula de CSG ou uma célula híbrida. O modo de acesso de CSG é fornecido caso o UE envie a mensagem de Solicitação de TAU por meio de uma célula híbrida. Caso o modo de acesso de CSG não seja fornecido, mas o ID de CSG seja fornecido, a MME deve considerar a célula como uma célula de CSG. Para SIPTO na Rede Local com arquitetura de GW autônomo, o eNodeB inclui o ID de Rede Doméstica Local na Mensagem de UE Inicial e na mensagem de Transporte de NAS de Enlace Ascendente caso a célula de destino esteja em uma Rede Doméstica Local. Para auxiliar Serviços de Localização, o eNB indica o Nível de Cobertura de UE à MME.

4. A nova MME diferencia o tipo do nó antigo, isto é, MME ou SGSN, conforme especificado na cláusula 4.3.19, usa o GUTI recebido do UE para derivar o endereço de antigo MME/S4 SGSN, e envia uma mensagem de Solicitação de Contexto (GUTI antigo, mensagem de Solicitação de TAU de conclusão, Assinatura de P-TMSI, Endereço de MME, UE validado, indicação de suporte de Otimização de CIoT EPS) para a antiga MME/antigo S4 SGSN para recuperar informações de usuário. UE Validado indica que a nova MME validou a proteção de integridade da mensagem de TAU, por exemplo, com base em contexto de segurança de EPS nativo para o UE. Para validar a Solicitação de Contexto, a antiga MME usa a mensagem de Solicitação de TAU de conclusão e o antigo S4 SGSN usa a Assinatura de P-TMSI e responde com um erro apropriado, caso a verificação de integridade falhe em antigo MME/S4 SGSN. Isso deve iniciar as funções de segurança na nova MME. Caso as funções de segurança autentiquem o UE corretamente, a nova MME deve enviar uma mensagem de Solicitação de Contexto (IMSI, mensagem de Solicitação de TAU de conclusão, Endereço de MME, UE Validado) para a antiga MME/antigo S4 SGSN com o UE Validado definido. Caso a nova MME indique que a mesma autenticou o UE ou caso a antiga MME/antigo S4 SGSN valide corretamente o UE, então, a antiga MME/antigo S4 SGSN inicia um temporizador. Caso o UE com transportadores de emergência não seja autenticado na antiga MME/antigo S4 SGSN (em uma rede que suporta UEs não autenticados), a antiga MME/antigo S4 SGSN continua o procedimento com o envio de uma Resposta de Contexto e início do temporizador também quando não puder validar a Solicitação de Contexto. Caso a nova MME suporte Otimização de CIoT EPS, indicação de suporte de Otimização de CIoT EPS é incluída na Solicitação de Contexto que indica suporte para várias Otimizações de CIoT EPS (por exemplo, suporte para compressão de cabeçalho para otimização de CP, etc.).

5. Caso a Solicitação de Contexto seja enviada a uma antiga MME, a antiga MME responde com uma mensagem de Resposta de Contexto (IMSI, Identidade de ME (IMEISV), Contexto de MM, Contexto(s) de Transportador de EPS, Endereço de Sinalização de GW Servidor e TEID(s), ISR Suportada, Ação de Relatório de Mudança de Info de MS (caso disponível), Ação de Relatório de Informações de CSG (caso disponível), Fuso Horário de UE, Capacidade de Rede núcleo de UE, Parâmetros DRX Específicos de UE). Caso a nova MME suporte Otimização de CIoT EPS e o uso de compressão de cabeçalho tenha sido negociado entre o UE e a antiga MME, a Resposta de Contexto também inclui a Configuração de Compressão de Cabeçalho que inclui as informações necessárias para a preparação de canal de ROHC, mas não o contexto de RoHC em si. Caso a Solicitação de Contexto seja enviada a um antigo S4 SGSN, o antigo S4 SGSN responde com uma mensagem de Resposta de Contexto (Contexto de MM, Contexto(s) de Transportador de EPS, Endereço de Sinalização de GW Servidor e TEID(s), ISR Suportada, Ação de Relatório de Mudança de Info de MS

(caso disponível), Ação de Relatório de Informações de CSG (caso disponível), Fuso Horário de UE, Capacidade de Rede núcleo de UE, Parâmetros DRX Específicos de UE). Caso a MME de origem ainda não tenha relatado um Contador de Dados de Exceção MO diferente de zero ao PGW, a Resposta de Contexto também inclui o Contador de Dados de Exceção MO, conforme descrito em TS 29.274 [43]. O Contexto de MM contém informações relacionadas à segurança, bem como outros parâmetros (que incluem IMSI e Identidade de ME (caso disponível)), conforme descrito na cláusula 5.7.2 (Armazenamento de Informações para MME). Os Quintetos de Autenticação não usados no Contexto de MM também são mantidos no SGSN.

TS 33.401 [41] fornece detalhes adicionais sobre a transferência de informações relacionadas à segurança.

Caso o Contexto de MM recebido com a mensagem de Resposta de Contexto não tenha incluído IMEISV e a MME ainda não armazene a IMEISV do UE, a MME deve recuperar a Identidade de ME (IMEISV) do UE.

O Endereço de PDN GW e TEID(s) (para S5/S8 com base em GTP) ou Chaves de GRE (S5/S8 com base em PMIP nos PDN GW(s) para tráfego de enlace ascendente) e o TI(s), são parte do Contexto de Transportador de EPS.

Caso o UE não seja conhecido na antiga MME/antigo S4 SGSN ou caso a verificação de integridade para a mensagem de Solicitação de TAU falhe, a antiga MME/antigo S4 SGSN responde com uma causa de erro apropriada.

A ISR Suportada é indicada caso a antiga MME/antigo S4 SGSN e GW Servidor associado tenham a capacidade de ativar ISR para o UE.

Caso o UE receba serviços de transportador de emergência da antiga MME/antigo S4 SGSN e o UE seja desprovido de UICC, a IMSI não pode ser incluída na Resposta de Contexto.

Para o UEs vinculados como emergência, caso a IMSI não possa ser autenticada, então, a IMSI deve ser marcada como não autenticada. Além disso, nesse caso, os parâmetros de segurança são incluídos apenas caso estejam disponíveis. Caso SIPTO, na Rede Local, esteja ativo para uma conexão de PDN na arquitetura com GW autônomo, a antiga MME/antigo S4 SGSN deve incluir o ID de Rede Doméstica Local da célula antiga no contexto de Transportador de EPS que corresponde ao SIPTO na conexão de PDN de Rede Local. Para o UE que usa Otimização de CIoT EPS sem qualquer conexão de PDN ativada, não há Contexto(s) de Transportador de EPS incluído na mensagem de Resposta de Contexto. Com base na indicação de suporte de Otimização de CIoT EPS, a antiga MME apenas transfere o(s) Contexto(s) de Transportador de EPS que a nova MME suporta. Caso a nova MME não suporte Otimização de CIoT EPS, o(s) Contexto(s) de Transportador de EPS de conexão de PDN não IP não são transferidos para a nova MME. Caso o(s) Contexto(s) de Transportador de EPS de uma conexão de PDN não tenha sido transferido, a antiga MME deve considerar todos os transportadores daquela conexão de PDN como que falharam e liberar aquela conexão de PDN disparando-se o procedimento de desconexão de PDN solicitada por MME, conforme especificado na cláusula 5.10.3. Os dados armazenados em buffer na antiga MME são descartados após recepção de Reconhecimento de Contexto.

6. Caso a verificação de integridade de mensagem de Solicitação de TAU (enviada na etapa 2) tenha falhado, então, a autenticação é obrigatória. As funções de autenticação são definidas na cláusula 5.3.10 em "Função de Segurança". Os procedimentos de cifragem são descritos na cláusula 5.3.10 em "Função de Segurança". Caso a alocação de GUTI seja feita e a rede suporte cifragem, as mensagens de NAS devem ser cifradas. Caso essa solicitação de TAU seja recebida para um UE que já esteja no estado ECM_CONECTADO e o PLMN-ID da TAI enviada pelo eNodeB na Etapa 3 seja diferente daquele do GUTI, incluído na mensagem de Solicitação de TAU, a MME deve atrasar a autenticação do UE até depois da etapa 21 (mensagem de Conclusão de TAU). NOTA 3: A MME atrasa a autenticação de modo que o UE primeiro atualize seu PLMN-ID registrado para o novo PLMN-ID selecionado pela RAN durante handover. O novo PLMN-ID é fornecido pela MME ao UE como parte do GUTI na mensagem de aceitação de TAU, na Etapa 20. Ao realizar isso, garante- se que o mesmo PLMN-ID seja usado na derivação da chave Kasme tanto pela rede quanto pelo UE. Caso a nova MME seja configurada para permitir serviços de transportador de emergência Para o UE não autenticado, a nova MME se comporta da seguinte forma: - quando um UE tem apenas serviços de transportador de emergência, a MME omite a autenticação e procedimento de segurança ou aceita que a autenticação pode falhar e continua o procedimento de Atualização de Área de Rastreamento; ou - quando um UE tem serviços de transportador tanto de emergência quanto de não emergência e a autenticação falha, a MME continua o procedimento de Atualização de Área de Rastreamento e desativa todas as conexões de PDN de não emergência, conforme especificado na cláusula 5.10.3.

7. A MME (caso a MME tenha mudado, então, é a nova MME) determina realocar o GW Servidor. O GW Servidor é realocado quando o GW Servidor antigo não pode continuar a servir o UE. A MME (caso a MME tenha mudado, então, é a nova MME) também pode decidir realocar o GW Servidor caso um novo GW Servidor seja esperado servir o UE por tempo mais longo e/ou com um UE mais ideal para trajetória de PDN GW, ou caso um novo GW Servidor possa ser justaposto ao PDN GW. A seleção de um novo GW Servidor é realizada de acordo com a cláusula 4.3.8.2 em “Função de seleção de GW Servidor". Caso a MME tenha mudado, a nova MME envia uma mensagem de Reconhecimento de Contexto (indicação de mudança de GW Servidor) para a antiga MME/antigo S4 SGSN. A indicação de mudança de GW Servidor indica que um novo GW Servidor foi selecionado. A antiga MME/antigo S4 SGSN marca em seu contexto de UE que as informações nos GWs são inválidas. E, caso o nó antigo seja uma MME, a antiga MME marca em seu contexto de UE que as informações no HSS são inválidas. Isso garante que a antiga MME/antigo S4 SGSN atualize os GWs, e a antiga MME atualiza o HSS, caso o UE inicie um procedimento de TAU ou RAU de volta à antiga MME/antigo S4 SGSN antes de concluir o procedimento de TAU em andamento. NOTA 4: Atualizar os GWs se refere à exclusão de sessão(ões) no GW Servidor seguido de recriação de sessão(ões) no GW Servidor. A recriação de sessão(ões) no GW Servidor resultará em restabelecimento bem-sucedido do túnel de S5/S8 entre o GW Servidor selecionado e o PDN GW. Caso as funções de segurança não autentiquem o UE corretamente, então, a TAU deve ser rejeitada, e a nova MME deve enviar uma indicação de rejeição à antiga MME/antigo S4 SGSN. A antiga MME/antigo S4 SGSN deve continuar como se a Identificação e Solicitação de Contexto nunca tivessem sido recebidos. ISR não é indicada na Reconhecimento de Contexto, visto que a ISR não é ativada devido à mudança de S-GW. Para o UE que usa Otimização de CIoT EPS sem qualquer conexão de PDN ativada, as etapas 8, 9, 10, 11, 18 e 19 são puladas.

8. Caso a MME tenha mudado, a nova MME verifica o status de transportador de EPS recebido do UE com os contextos de transportador recebidos da antiga MME/antigo S4 SGSN. Caso a MME não tenha mudado, a

MME verifica status de transportador de EPS do UE com os contextos de transportador disponíveis no contexto de MM.

A MME libera quaisquer recursos de rede relacionados os transportadores de EPS que não estão ativos no UE.

Caso não haja contexto de transportador algum, a MME rejeita a Solicitação de TAU.

Caso a MME tenha selecionado um novo GW Servidor, a mesma envia uma mensagem de Solicitação de Criação de Sessão (IMSI, contextos de transportador, Endereço de MME e TEID, Tipo, o Tipo de Protocolo em S5/S8, Tipo de RAT, Rede Servidora, Fuso Horário de UE, contador de Dados de Exceção MO) por conexão de PDN para o novo GW Servidor selecionado.

O endereço de PDN GW e TFT (para S5/S8 com base em PMIP) são indicados nos Contextos de transportador.

Tipo indica ao GW Servidor para enviar a Solicitação de Modificação de Transportador ao PDN GW.

O Tipo de Protocolo em S5/S8 é fornecido para GW Servidor cujo protocolo deve ser usado em interface S5/S8. Tipo de RAT indica uma mudança em Acesso via Rádio.

Caso seja uma mobilidade de um SGSN para uma MME e caso a MME suporte relatório de mudança de informações de localização, a MME deve incluir as Informações de Localização de Usuário (de acordo com a granularidade suportada) na Solicitação de Criação de Sessão, independentemente de o relatório de mudança de informações de localização ter sido solicitado na RAT anterior pelo PGW.

Caso seja uma mobilidade entre MMEs e caso o PDN GW tenha solicitado relatório de mudança de informações de localização, a MME inclui o IE de Informações de Localização de Usuário nessa mensagem, caso seja diferente quando comparado às informações previamente enviadas.

Caso o PDN GW tenha solicitado informações de CSG de usuário, a MME também inclui o IE de Informações de CSG de Usuário nessa mensagem.

Caso Otimização de CIoT EPS de Plano de Controle se aplique, a MME também pode indicar tunelamento de S11-U de dados de usuário de NAS e enviar seu próprio endereço de S11-U IP e MME DL

TEID para dados de DL encaminhados pelo SGW. A MME deve incluir o contador de dados de Exceção MO, caso a mesma tenha recebido o contador para causa de RRC "Dados de Exceção MO" na mensagem de Resposta de Contexto. Caso apenas a Otimização de CIoT EPS de Plano de Controle seja usada, a MME deve incluir um Indicador de Conexão de PDN Apenas de Plano de Controle na Solicitação de Criação de Sessão. Caso a nova MME receba o contexto de transportador de EPS com SCEF, então, a nova MME atualiza a SCEF, conforme definido em TS 23.682 [74].

9. O GW Servidor informa o PDN GW(s) da mudança, por exemplo, do tipo de RAT que, por exemplo, pode ser usado para carregamento, enviando-se a mensagem de Solicitação de Modificação de Transportador (Endereço de GW Servidor e TEID, Tipo de RAT, Rede Servidora, Indicação de Suporte de Pausa de Carregamento de PDN) por conexão de PDN ao PDN GW(s) em questão. O IE de Informações de Localização de Usuário e/ou IE de Fuso Horário de UE e/ou IE de Informações de CSG de Usuário e/ou contador de dados de Exceção MO também são incluídos, caso os mesmos estejam presentes na etapa 8. O GW Servidor e PDN GW indicam cada uso da causa de estabelecimento de RRC de "Dados de Exceção MO" pelo contador relacionado em seu CDR. Caso o GW Servidor tenha recebido o Indicador de Conexão de PDN Apenas de Plano de Controle na etapa 8, o GW Servidor indica o uso de CP apenas em seu CDR. 9a. Caso PCC dinâmico seja implementado, e informações de tipo de RAT precisem ser transportadas do PDN GW para a PCRF, então, o PDN GW deve enviar informações de tipo de RAT à PCRF por meio de um procedimento de modificação de sessão de IP-CAN, conforme definido em TS 23.203 [6]. NOTA 5: O PDN GW não precisa esperar pela resposta de PCRF, mas continua na próxima etapa. Caso a resposta de PCRF leve a uma modificação de transportador de EPS, o PDN GW deve iniciar um procedimento de atualização de transportador.

10. O PDN GW atualiza seus contextos de transportador e retorna uma mensagem de Resposta de modificação de transportador (MSISDN, Id de Carregamento, indicação habilitada de Pausa de Carregamento de PDN (caso PDN GW tenha escolhido habilitar a função)). A MSISDN é incluída caso o PDN GW tenha o mesmo armazenado em seu contexto de UE. Caso tenha havido uma mudança de RAT para E-UTRAN e relatório de mudança de informações de localização seja necessário e suportado na MME de destino, o PGW deve fornecer Ação de Relatório de Mudança de Info de MS na Resposta de modificação de transportador. Caso o GW Servidor seja realocado, o PDN GW deve enviar um ou mais pacotes de "marcador de extremidade” na trajetória antiga imediatamente após comutar a trajetória a fim de auxiliar a função de reordenação no eNodeB de destino. Caso o GW Servidor não tenha plano de usuário de enlace descendente estabelecido, o GW Servidor deve descartar o "marcador de extremidade" recebido do PDN GW e não deve enviar Notificação de Dados de Enlace Descendente. De outro modo, o GW Servidor deve encaminhar os pacotes "marcador de extremidade” para o eNodeB de origem ou S4 SGSN de origem.

11. O GW Servidor atualiza seu contexto de transportador. Isso permite que o GW Servidor realize roteamento de PDUs de transportador para o PDN GW quando recebidas do eNodeB. O GW Servidor retorna uma mensagem de Resposta de Criação de Sessão (endereço de GW Servidor e TEID para plano de usuário e plano de controle e PDN GW TEIDs (para S5/S8 com base em GTP) ou chaves GRE (para S5/S8 com base em PMIP) para tráfego de enlace ascendente e plano de controle, Ação de Relatório de Mudança de Info de MS) à nova MME. Caso a otimização de CIoT

EPS de Plano de Controle se aplique, o endereço de GW Servidor para Plano de Usuário de S11-U e TEID de GW Servidor são usados pela MME para encaminhar dados de UL ao SGW. Quando a MME recebe a mensagem de Resposta de Criação de Sessão, a MME verifica se há um evento de monitoramento de "Disponibilidade após Falha de DDN” ou um evento de monitoramento “Acessibilidade de UE” configurado para o UE na MME e, em tal caso, envia uma notificação de evento (consulte TS 23.682 [74] para informações adicionais).

12. A nova MME verifica se mantém dados de assinatura para o UE identificado pelo GUTI, pelo GUTI adicional ou pela IMSI recebida com os dados de contexto do nó de CN antigo. Caso não haja dados de assinatura na nova MME para esse UE, ou para algum cenário de compartilhamento de rede (por exemplo, GWCN) caso o PLMN-ID da TAI fornecido pelo eNodeB seja diferente daquele do GUTI no contexto de UE, então, a nova MME envia uma mensagem de Solicitação de Atualização de Localização (Identidade de MME, IMSI, Flags de ULR, Capacidades de MME, Suporte Homogêneo de Voz sobre IMS de sessões PS, capacidade de UE SRVCC, lista de PLMN equivalente, Identidade de ME (IMEISV)) ao HSS. Flags de ULR indicam que atualização de localização é enviada de uma MME e o registro de MME deve ser atualizado em HSS. O HSS não cancela qualquer registro de SGSN. As capacidades de MME indicam o suporte de MME para funcionalidade de restrições de acesso regionais. A inclusão da lista de PLMN equivalente indica que a MME suporta o handover entre PLMNs para uma célula de CSG em uma PLMN equivalente com o uso das informações de assinatura da PLMN de destino. A indicação de "Suporte Homogêneo de Voz sobre IMS de sessões PS” (consulte a cláusula 4.3.5.8A) não deve estar incluída, a menos que a MME tenha concluído sua avaliação do suporte de “Voz sobre IMS de sessão

PS", conforme especificado na cláusula 4.3.5.8. A Identidade de ME é incluída caso a etapa 5 tenha feito com que a MME recupere a IMEISV do UE. NOTA 6: Nessa etapa, a MME pode não ter todas as informações necessárias para determinar a definição da indicação de Voz sobre IMS de sessão PS Suportada para esse UE (consulte a cláusula 4.3.5.8). Portanto, a MME pode enviar o "Suporte Homogêneo de Voz sobre IMS de sessões PS" posteriormente nesse procedimento. Caso o UE inicie o procedimento de TAU em uma VPLMN que suporta Roaming de CSG Autônomo e a HPLMN tenha habilitado Roaming de CSG Autônomo na VPLMN (por meio de Acordo de Nível de Serviço) e a MME precise recuperar as informações de assinatura de CSG do UE do CSS, a MME inicia o Procedimento de Atualização de Localização de CSG com CSS, conforme descrito na cláusula 5.3.12. Caso a MME determine que apenas a capacidade de UE SRVCC mudou, a MME envia uma Solicitação de Notificação ao HSS para informar sobre a capacidade de UE SRVCC alterada. Caso todos os transportadores de EPS do UE tenham valor de ARP de emergência, a nova MME pode omitir o procedimento de atualização de localização ou prosseguir até mesmo se a atualização de localização falhar.

13. O HSS envia a mensagem de Cancelamento de Localização (IMSI, Tipo de Cancelamento) à antiga MME com Tipo de Cancelamento definido para Atualização de Procedimento.

14. Caso o temporizador iniciado na etapa 4 não esteja sendo executado, a antiga MME remove o contexto de MM. De outro modo, os contextos são removidos quando o temporizador expira. Também garante que o contexto de MM seja mantido na antiga MME para o caso de o UE iniciar outro procedimento de TAU antes de concluir o procedimento de TAU em andamento na nova MME. A antiga MME reconhece com a mensagem Reconhecimento de Cancelamento de Localização (IMSI).

15. Quando o antigo S4 SGSN recebe a mensagem de Reconhecimento de Contexto e caso o UE esteja conectado em lu, o antigo S4 SGSN envia uma mensagem de Comando de Liberação de lu ao RNC após o temporizador iniciado na etapa 4 ter expirado.

16. O RNC responde com uma mensagem de Conclusão de Liberação de lu.

17. O HSS reconhece a mensagem de Solicitação de Atualização de Localização enviando-se uma mensagem de Ack de Atualização de Localização (IMSI, Dados de Assinatura) à nova MME. Os Dados de Assinatura podem conter os dados de assinatura de CSG para a PLMN registrada e para a lista de PLMN equivalente solicitada pela MME na etapa 12. Os dados de assinatura podem conter parâmetro de Cobertura Aprimorada Restrita. Caso recebido do HSS, MME armazena esse parâmetro de Cobertura Aprimorada Restrita no contexto de MME MM. Os dados de assinatura podem conter parâmetro de gap de serviço. Caso recebido do HSS, MME armazena esse parâmetro de gap de serviço no contexto de MME MM e passa o mesmo para o UE na mensagem de Aceitação de Atualização de Área de Rastreamento. Caso a Atualização de Localização seja rejeitada pelo HSS, a nova MME rejeita a Solicitação de TAU do UE com uma causa apropriada. Em tais casos, a nova MME libera quaisquer contextos de Transportador de EPS de MME local para esse UE particular e, adicionalmente, exclui os recursos de transportador de EPS no novo GW Servidor enviando-se as mensagens de Solicitação de Exclusão de Sessão (Causa, Indicação de Operação) para o novo GW Servidor. A flag de Indicação de Operação não deve ser definida. Portanto, o novo GW

Servidor que recebe essa solicitação não deve iniciar um procedimento de exclusão para o PDN GW. Caso o UE inicie o procedimento de TAU em uma célula de CSG, a nova MME deve verificar se o ID de CSG e PLMN associada estão contidos na assinatura de CSG e não estão expirados. Caso o ID de CSG e PLMN associada não estejam presentes ou expirados, a MME deve enviar uma mensagem de rejeição de Atualização de Área de Rastreamento ao UE com um valor de causa apropriado. O UE deve remover o ID de CSG e PLMN associada de sua lista de CSG Permitido, caso presente. Caso o UE tenha serviços de transportador de emergência em andamento, nenhum controle de acesso de CSG deve ser realizado. Caso todas as verificações sejam bem-sucedidas, então, a nova MME constrói um contexto para o UE.

18. Caso a MME tenha mudado, quando o temporizador iniciado na etapa 4 expira, a antiga MME/antigo S4 SGSN libera quaisquer recursos de transportador de MME ou SGSN local e, adicionalmente, a antiga MME/antigo S4 SGSN exclui os recursos de transportador de EPS enviando-se as mensagens de Solicitação de Exclusão de Sessão (Causa, Indicação de Operação) ao antigo GW Servidor caso tenha recebido a indicação de mudança de GW Servidor na mensagem de Reconhecimento de Contexto na etapa 7. Quando a flag de Indicação de Operação não é definida, isso indica ao antigo GW Servidor que o antigo GW Servidor não deve iniciar um procedimento de exclusão no PDN GW. Caso ISR seja ativada, a causa indica ao antigo S-GW que o antigo S-GW deve excluir os recursos de transportador no outro nó de CN antigo enviando-se mensagem(ns) de Solicitação de Exclusão de Transportador àquele nó de CN. Caso a MME não tenha mudado, a etapa 11 dispara a liberação dos recursos de transportador de EPS no antigo GW Servidor.

19. O GW Servidor reconhece com mensagens de Resposta de Exclusão de Sessão (Causa). O GW Servidor descarta quaisquer pacotes armazenados em buffer para o UE.

20. Caso, devido a restrições de assinatura regionais ou restrições de acesso (por exemplo, restrições de CSG) o UE não tenha permissão para acessar a TA: - A MME rejeita a Solicitação de Atualização de Área de Rastreamento com uma causa apropriada para o UE. - Para o UEs com transportadores de EPS de emergência, isto é, pelo menos um transportador de EPS tem um valor de ARP reservado para serviços de emergência, a nova MME aceita a Solicitação de Atualização de Área de Rastreamento e desativa todas as conexões de PDN de não emergência, conforme especificado na cláusula 5.10.3. Caso o procedimento de Atualização de Área de Rastreamento seja iniciado em estado ECM-OCIOSO, todos os transportadores de EPS de não emergência são desativadas pelo procedimento de Atualização de Área de Rastreamento sem sinalização de desativação de transportador entre o UE e a MME. A MME envia uma mensagem de Aceitação de TAU (GUTI, lista de TAI, status de transportador de EPS, número de sequência de NAS, NAS-MAC, Voz sobre IMS de sessão PS suportada, indicador de Suporte de Serviço de Emergência, Indicação de Suporte de LCS, Comportamento de Rede Suportada, Gap de Serviço) ao UE. Caso a flag ativa seja definida, a MME pode fornecer, ao eNodeB, Lista de Restrição de Handover. O GUTI é incluído caso a MME aloque um novo GUTI. Caso a flag ativa seja definida na mensagem de Solicitação de TAU, o procedimento de preparação de plano de usuário pode ser ativado em conjunto com a mensagem de Aceitação de TAU. Caso o Tempo de Expiração de Armazenamento em buffer de Dados de DL para o UE na MME não tenha expirado, o procedimento de preparação de plano de usuário é ativado até mesmo se a MME não tiver recebido a flag ativa na mensagem de Solicitação de TAU.

Caso a nova MME receba a mensagem Notificação de Dados de Enlace Descendente ou qualquer mensagem de sinalização de enlace descendente enquanto o UE ainda estiver conectado, o procedimento de preparação de plano de usuário pode ser ativado até mesmo se a nova MME não tiver recebido a flag ativa na mensagem de Solicitação de TAU.

O procedimento é descrito em detalhes em TS 36.300 [5]. A sequência de mensagem deve ser igual à do procedimento de Solicitação de Serviço disparado por UE especificado na cláusula 5.3.4.1 da etapa em que MME estabelece o transportador(es). A MME indica o IE de status de transportador de EPS ao UE.

O UE remove quaisquer recursos internos relacionados os transportadores que não são marcados como ativos no status de transportador de EPS recebido.

Caso as informações de status de transportador de EPS estivessem na Solicitação de TAU, a MME deve indicar o status de transportador de EPS ao UE.

A Lista de Restrição de Handover é descrita na cláusula 4.3.5.7 "Restrições de Mobilidade". A MME define a voz sobre IMS de sessão PS suportada, conforme descrito na cláusula 4.3.5.8. Para o UE que usa Otimização de CIoT EPS sem qualquer conexão de PDN ativada, não há status de transportador de EPS incluído na mensagem de Aceitação de TAU.

A MME indica as otimizações de CIoT que suporta e prefere nas informações de Comportamento de Rede Suportada, conforme definido na cláusula 4.3.5.10. Caso haja um temporizador de Gap de Serviço sendo executado para o UE na MME, a flag ativa e flag ativa de sinalização recebidas na mensagem de Solicitação de TAU devem ser ignoradas e quaisquer ações disparadas pela flag ativa ou flag ativa de sinalização nesse procedimento não devem ser realizadas.

O parâmetro de Gap de Serviço é incluído na mensagem de Aceitação de TAU caso o UE tenha indicado capacidade de Gap de Serviço na capacidade de rede de UE e caso Gap de Serviço tenha sido recebida na etapa 17 de HSS nas informações de assinatura ou caso o gap de Serviço nas informações de assinatura tenha sido atualizada por gerenciamento de Perfil de Usuário de HSS (isto é, o procedimento de Inserção de Dados de Assinante na cláusula 5.3.9.2) visto que o procedimento de TAU foi previamente executado.

Caso o UE tenha incluído suporte para restrição de uso de Cobertura Aprimorada, a MME envia parâmetro de Cobertura Aprimorada Restrita ao eNB na mensagem de S1-AP, conforme definido na cláusula 4.3.28. A MME também envia o parâmetro de Cobertura Aprimorada Restrita ao UE na mensagem de Aceitação de TAU.

O UE deve armazenar parâmetro de Cobertura Aprimorada Restrita e deve usar o valor de parâmetro de Cobertura Aprimorada Restrita para determinar se o recurso de cobertura aprimorada deve ou não ser usado.

Caso a MME tenha obtido, de maneira bem-sucedida, parâmetros de Configuração de Compressão de Cabeçalho na etapa 5, isso indica o uso continuado de configuração previamente negociada ao UE no Status de Contexto de Compressão de Cabeçalho para cada transportador de EPS do UE.

Quando o Estado de Contexto de Compressão de Cabeçalho indicar que a configuração previamente negociada não pode mais ser usada para alguns transportadores de EPS, o UE deve interromper a realização de compressão e descompressão de cabeçalho, ao enviar ou receber dados com o uso de otimização de CIoT EPS de Plano de Controle nesses transportadores de EPS.

Caso a MME não tenha recebido o Indicador de Correspondência de Suporte de Voz no Contexto de MM, então, a MME pode enviar uma Solicitação de Correspondência de Capacidade de Rádio de UE ao eNB, conforme descrito na cláusula 5.3.14. Caso a MME não tenha recebido Indicador de

Correspondência de Suporte de Voz do eNB, então, com base em implantação, a MME pode definir indicação de Voz sobre IMS de sessão PS suportada e atualizar a mesma um estágio posterior.

Após a etapa 12 e paralelamente a qualquer uma dentre as etapas antecedentes, a MME deve enviar uma mensagem de Solicitação de Notificação (Suporte Homogêneo de Voz sobre IMS de sessões PS) ao HSS: - Caso a MME tenha avaliado o suporte de Voz sobre IMS de sessões PS, consulte a cláusula 4.3.5.8, e - Caso a MME determine que a mesma precisa atualizar o Suporte Homogêneo de Voz sobre IMS de sessões PS, consulte a cláusula 4.3.5.8A.

O indicador de Suporte de Serviço de Emergência informa o UE de que serviços de transportador de Emergência são suportados.

A Indicação de Suporte de LCS indica se a rede suporta o EPC-MO-LR e/ou CS-MO-LR, conforme descrito em TS 23.271 [57]. Caso o UE tenha incluído elemento de informações de parâmetros de DRX de modo ocioso estendido, a MME inclui elemento de informações de parâmetros de DRX de modo ocioso estendido caso decida habilitar DRX de modo ocioso estendido.

Ao receber a mensagem de Aceitação de TAU e não houver indicação de ISR Ativada, o UE deve definir sua TIN para "GUTI". Para uma mudança de S-GW, ISR Ativada nunca é indicada pela MME, visto que precisa de uma RAU com o mesmo S-GW primeiro para ativar ISR.

Para uma mudança de MME, ISR não é ativada pela nova MME para evitar procedimentos de transferência de contexto com dois nós de CN antigos.

Caso o procedimento de TAU seja iniciado por seleção de CSG manual e ocorra por meio de uma célula de CSG, o UE, mediante recepção da mensagem de Aceitação de TAU, deve adicionar o ID de CSG e PLMN associada à sua lista de

CSG Permitido caso ainda não estejam presentes. A seleção de CSG manual não é suportada caso o UE tenha transportadores de emergência estabelecidos. Caso a preparação de plano de usuário seja realizada em conjunto com a mensagem de Aceitação de TAU e a TAU seja realizada por meio de uma célula híbrida, então, a MME deve enviar uma indicação da possibilidade de o UE ser um membro de CSG à RAN em conjunto com a mensagem de controle de S1- MME. Com base nessas informações, a RAN pode realizar tratamento diferenciado para membros de CSG e de não CSG. NOTA 7: Caso o UE receba uma mensagem de Aceitação de TAU por meio de uma célula híbrida, o UE não adiciona o ID de CSG correspondente e PLMN associada à sua lista de CSG Permitido. A adição de um ID de CSG e PLMN associada à lista de CSG Permitido local de UE para uma célula híbrida é realizada apenas por procedimentos de DM OTA ou OMA. Caso o UE receba uma Gap de Serviço na mensagem de Aceitação de TAU, o UE deve armazenar esse parâmetro e aplicar controle de gap de serviço para solicitações de conexão de dados originadas em terminal móvel (consulte a cláusula 4.3.x acima).

21. Caso GUTI tenha sido incluído na Aceitação de TAU, o UE reconhece a mensagem recebida retornando-se uma mensagem de Conclusão de TAU à MME. Quando a "flag ativa" não é definido na mensagem de Solicitação de TAU e a Atualização de Área de Rastreamento não foi iniciada em estado ECM- CONECTADO, a nova MME libera a conexão de sinalização com UE, de acordo com a cláusula 5.3.5. Para um UE que usa Otimização de CIoT EPS de Plano de Controle, quando a "flag ativa de sinalização” é definida, a nova MME não deve liberar a conexão de sinalização de NAS com o UE imediatamente após o procedimento de TAU ser concluído.

NOTA 8: A nova MME pode iniciar estabelecimento de E-RAB (consulte TS 36.413 [36]) após execução das funções de segurança, ou aguardar até a conclusão do procedimento de atualização de TA.

Para o UE, o estabelecimento de E-RAB pode ocorrer a qualquer momento após a solicitação de atualização de TA ser enviada.

No caso de uma operação de atualização de área de rastreamento rejeitada, devido à assinatura regional, restrições de roaming ou restrições de acesso (consulte TS 23.221 [27] e TS 23.008 [28]) a nova MME não deve construir um contexto de MM para o UE.

No caso de recepção dos dados de assinante de HSS, a nova MME pode construir um contexto de MM e armazenar os dados de assinante para o UE para otimizar a sinalização entre a MME e o HSS.

Uma rejeição deve ser retornada ao UE com uma causa apropriada e a conexão de S1 deve ser liberada.

Mediante retorno para ocioso, o UE deve agir de acordo com TS 23.122 [10]. A nova MME deve determinar a restrição Máxima de APN com base na Restrição de APN recebida de cada contexto de transportador na mensagem de Resposta de Contexto e, então, armazenar o novo valor de Restrição máxima de APN.

Os contextos de transportador devem ser priorizados pela nova MME.

Caso a nova MME não tenha a capacidade de suportar o mesmo número de contextos de transportadores ativos que o recebido de antigo MME/SGSN, a prioridade é usada para decidir quais contextos de transportador manter ativos e quais excluir.

Em qualquer caso, a nova MME deve primeiro atualizar todos os contextos em um ou mais P-GWs e, então, desativar o(s) contexto(s) de transportador que não puder manter, conforme descrito na cláusula “Procedimento de Desativação de Transportador dedicado Iniciada por MME". Isso não deve fazer com que a MME rejeite a atualização de área de rastreamento.

A nova MME não deve desativar transportadores de EPS relacionadas a serviço de emergência, isto é, transportadores de EPS com valor de ARP reservado para serviços de emergência.

NOTA 9: Caso MS (UE) esteja em estado PMM-CONECTADO, os contextos de transportador são enviados já na mensagem de Solicitação de Encaminhamento de Realocação, conforme descrito na cláusula "Procedimentos de realocação de RNS Servidor" de TS 23.060 [7]. Caso o procedimento de atualização de área de rastreamento falhe um número de vezes máximo permissível, ou caso a MME retorne uma mensagem de Rejeição de Atualização de Área de Rastreamento (Causa), o UE deve entrar em estado EMM DESCADASTRADO.

Caso a nova MME identifique que o tipo de RAT mudou, a MME verifica as informações de assinatura para identificar para cada APN a possibilidade de manter a conexão de PDN, desconectar a conexão de PDN com uma solicitação de reativação ou desconectar a conexão de PDN sem solicitação de reativação.

Caso a MME decida desativar uma conexão de PDN, a mesma realiza procedimento de Desativação de Conexão de PDN iniciada por MME após o procedimento de atualização de área de rastreamento ser concluído, mas antes de a conexão de interface de S1/RRC ser liberada.

Os valores de causa de ESM existentes, conforme especificado em TS 24.301 [46] (por exemplo, #39, "reativação solicitada"; #66 “APN solicitado não suportado em RAT atual e combinação de PLMN"; e para um transportador dedicado, possivelmente #37 "EPS QoS não aceito") são usados para causar comportamento de UE previsível.

Caso todas as conexões de PDN sejam desconectadas e o UE não suporte "vinculação sem conectividade de PDN", a MME deve solicitar ao UE para que desvincule e revincule.

5.3.3.2 Atualização de Área de Rastreamento de E-UTRAN sem Mudança de S-GW RNC Antiga MME/ PDN

GW BSC MME Antigo S4 GW PCRF HSS UE eNodeB Servidor

SGSN

1. Disparo para Iniciar Procedimento de TAU

2. Solicitação de Atualização de Área de Rastreamento

3. Solicitação de Atualização de Área de Rastreamento

4. Solicitação de Contexto

5. Resposta de Contexto

6. Autenticação / Segurança

7. Confirmação de Contexto

9. Solicitação de Modificação de Transportador

10. Solicitação de Modificação de Transportador

11. Modificação de sessão de IP-CAN iniciada por PCEF

12. Resposta de Modificação de Transportador (A)

13. Resposta de Modificação de Transportador

14. Solicitação de Atualização de Localização

15. Cancelamento de Localização

16. Ack de Cancelamento de Localização

17. Comando de Liberação de lu

18. Conclusão de Liberação de lu

19. Ack de Atualização de Localização

20. Aceitação de Atualização de Área de Rastreamento

21. Conclusão de atualização de área de rastreamento Figura 5.3.3.2-1: Atualização de Área de Rastreamento de E-UTRAN sem mudança de S-GW NOTA 1: Para um S5/S8 com base em PMIP, as etapas de procedimento (A) são definidas em TS 23.402 [2]. As etapas 12 e 14 se referem a S5/S8 com base em GTP. NOTA 2: No caso de Atualização de Área de Rastreamento sem mudança de MME, a sinalização nas etapas 4, 5, 7 e etapas 9 a 19 é pulada. Uma mudança de Fuso Horário de UE, informações de CSG de usuário ou Rede Servidora é sinalizada na próxima Solicitação de Serviço. Caso mudança de TAI precise ser relatada ao PGW, o procedimento de relatório de mudança de informações de localização, descrito na cláusula 5.9.2, é realizado. NOTA 3: Relatório Diferido de Fuso Horário de UE ou Rede Servidora por NOTA 2 pode falhar quando mobilidade entre MME/SGSN ocorrer antes de um UE enviar SOLICITAÇÃO DE SERVIÇO e o MME/SGSN de destino (por exemplo, pré-lançamento 10) não suportar a flag "Mudar para Relatar".

2. O UE inicia um procedimento de TAU enviando-se, ao eNodeB, uma mensagem de Solicitação de Atualização de Área de Rastreamento (Capacidade de Rede núcleo de UE, Capacidade de Rede de MS, comportamento de Rede Preferencial, Suporte para restrição de uso de Cobertura Aprimorada, flag ativa, flag ativa de sinalização, status de transportador de EPS, GUTI antigo, Tipo de GUTI antigo, TAI visitada por último, assinatura de P-TMSI, GUTI adicional, KSISGSN, KSIASME, número de sequência de NAS, NAS-MAC, preferência de domínio de voz e definição de uso de UE) em conjunto com parâmetros de RRC que indicam a Rede Selecionada e o GUMMEI antigo. Uma exceção é que, caso a TAU tenha sido disparada com a finalidade de reequilíbrio de carga (consulte a cláusula 4.3.7.3), o GUMMEI antigo não é incluído nos parâmetros de RRC. O UE deve definir o Tipo de GUTI antigo para indicar se o GUTI antigo é um GUTI nativo ou é mapeado de uma P-TMSI e RAI. Caso a TIN de UE indique "GUTI" ou "TMSI relacionada à-RAT" e o UE mantenha um GUTI válido, então, o GUTI antigo indica esse GUTI válido.

O mapeamento de uma P-TMSI e RAI para um GUTI é especificado no Anexo H.

Quando o UE está em modo conectado (por exemplo, em URA_PCH) quando o mesmo seleciona novamente para E-UTRAN, o UE deve definir sua TIN para "P-TMSI". Caso o UE mantenha um GUTI válido e o GUTI antigo indique um GUTI mapeado de uma P-TMSI e RAI, então, o UE indica o GUTI como GUTI adicional.

Tal configuração de eNodeB também pode ser usada para nós separados para evitar a mudança de nós no agrupamento causada por mobilidade entre RATs.

A TAI visitada por último deve ser incluída a fim de ajudar a MME a produzir uma boa lista de TAIs para qualquer mensagem de Aceitação de TAU subsequente. A Rede Selecionada indica a rede que é selecionada. A flag ativa é uma solicitação de UE para ativar o rádio e transportadores S1 para todos os transportadores de EPS ativos por meio do procedimento de TAU. A flag ativa de sinalização é uma solicitação de UE que usa Otimização de CIoT de Plano de Controle para manter a conexão de sinalização de NAS após Procedimento de Atualização de Área de Rastreamento ser concluído a fim de transmitir Dados pendentes com o uso do Transporte de Dados em Otimização de CIoT EPS de Plano de Controle ou sinalização de NAS. A capacidade de ISR de UE é incluída no elemento de Capacidade de Rede núcleo de UE. O status de transportador de EPS indica cada transportador de EPS que está ativo no UE. A mensagem de Solicitação de TAU deve ter integridade protegida pelo NAS-MAC, conforme descrito em TS 33.401 [41]. KSIASME é incluído caso o UE tenha parâmetros de segurança válidos. O número de sequência de NAS indica o número sequencial da mensagem de NAS. Para o UE que usa Otimização de CIoT EPS sem qualquer conexão de PDN ativada, não há flag ativa ou status de transportador de EPS incluído na mensagem de Solicitação de TAU. Para um UE com um temporizador de Gap de Serviço sendo executado no UE, a flag ativa e a flag ativa de sinalização não devem ser definidos na mensagem de solicitação de TAU (consulte a cláusula

4.3.x acima). Caso o UE tenha conexão de PDN de Tipo de PDN "não IP", o UE deve indicar status de transportador de EPS incluído na mensagem de Solicitação de TAU. KSISGSN é incluído caso o UE indique um GUTI mapeado de uma P-TMSI no elemento de informações “GUTI antigo". O UE define a preferência de domínio de voz e definição de uso de UE de acordo com a sua configuração, conforme descrito na cláusula 4.3.5.9.

O UE inclui elemento de informações de parâmetros DRX de modo ocioso estendidos caso precise habilitar DRX de modo ocioso estendido, até mesmo se parâmetros DRX de modo ocioso estendidos já tiverem sido negociados antes. Caso um UE inclua um Comportamento de Rede Preferencial, isso define o Comportamento de Rede que o UE está esperando que esteja disponível na rede, conforme definido na cláusula 4.3.5.10.

3. O eNodeB deriva o endereço de MME dos parâmetros de RRC que portam o GUMMEI antigo, a Rede Selecionada indicada e a RAT (NB-IoT ou WB- E-UTRAN). Caso esse GUMMEI não seja associado ao eNodeB ou o GUMMEI não esteja disponível ou o UE indique que o procedimento de TAU foi disparado por reequilíbrio de carga, o eNodeB seleciona a MME, conforme descrito na cláusula

4.3.8.3 em “Função de Seleção de MME". O eNodeB encaminha a mensagem de Solicitação de TAU em conjunto com o modo de acesso de CSG, ID de CSG, TAI+ECGI da célula de onde o mesmo recebeu a mensagem e com a Rede Selecionada para a MME. O ID de CSG é fornecido pela RAN caso o UE envie a mensagem de Solicitação de TAU por meio de uma célula de CSG ou uma célula híbrida. O modo de acesso de CSG é fornecido caso o UE envie a mensagem de Solicitação de TAU por meio de uma célula híbrida. Caso o modo de acesso de CSG não seja fornecido, mas o ID de CSG seja fornecido, a MME deve considerar a célula como uma célula de CSG. Para SIPTO na Rede Local com arquitetura de GW autônomo, o eNodeB inclui o ID de Rede Doméstica Local na Mensagem de UE Inicial e na mensagem de Transporte de NAS de Enlace Ascendente caso a célula de destino esteja em uma Rede Doméstica Local. Para auxiliar Serviços de Localização, o eNB indica o Nível de Cobertura de UE à MME.

4. A nova MME diferencia o tipo do nó antigo, isto é, MME ou SGSN, conforme especificado na cláusula 4.3.19, usa o GUTI recebido do UE para derivar o endereço de antigo MME/S4 SGSN e envia uma mensagem de Solicitação de Contexto (GUTI antigo, endereço de MME, UE Validado, mensagem de Solicitação de TAU de conclusão, Assinatura de P-TMSI, indicação de suporte de Otimização de CIoT EPS) aa antiga MME/antigo S4 SGSN para recuperar as informações de usuário. UE Validado indica que a nova MME validou a proteção de integridade da mensagem de TAU, por exemplo, com base em contexto de segurança de EPS nativo para o UE. Para validar a Solicitação de Contexto, a antiga MME usa a mensagem de Solicitação de TAU de conclusão e o antigo S4 SGSN usa a Assinatura de PTMSI e responde com um erro apropriado, caso a verificação de integridade falhe em antigo MME/S4 SGSN. Isso deve iniciar as funções de segurança na nova MME. Caso as funções de segurança autentiquem o UE corretamente, a nova MME deve enviar uma mensagem de Solicitação de Contexto (IMSI, mensagem de Solicitação de TAU de conclusão, Endereço de MME, UE Validado) para a antiga MME/antigo S4 SGSN com o UE Validado definido. Caso a nova MME indique que a mesma autenticou o UE ou caso a antiga MME/antigo S4 SGSN autentique o UE, a antiga MME/antigo S4 SGSN inicia um temporizador. Caso o UE com transportadores de emergência não seja autenticado na antiga MME/antigo S4 SGSN (em uma rede que suporte UEs não autenticados), a antiga MME/antigo S4 SGSN continua o procedimento com o envio de uma Resposta de Contexto e início do temporizador também quando não puder validar a Solicitação de Contexto. Caso a nova MME suporte Otimização de CIoT EPS, a indicação de suporte de Otimização de CIoT EPS é incluída na Solicitação de Contexto que indica suporte para várias Otimizações de CIoT EPS (por exemplo, suporte para compressão de cabeçalho para otimização de CP, etc.).

5. Caso a Solicitação de Contexto seja enviada a uma antiga MME, a antiga MME responde com uma mensagem de Resposta de Contexto (IMSI, Identidade de ME (IMEISV), Vetores de Autenticação de EPS não usados, KSIASME, KASME, Contexto(s) de Transportador de EPS, Endereço de sinalização de GW Servidor e TEID(s), Ação de Relatório de Mudança de Info de MS (caso disponível), Ação de Relatório de Informações de CSG (caso disponível), Fuso Horário de UE, Capacidade de Rede núcleo de UE, Parâmetros de DRX Específicos de UE, Mudança para Relato (caso presente)). Caso a nova MME suporte Otimização de CIoT EPS e o uso de compressão de cabeçalho tenha sido negociado entre o UE e antiga MME, a Resposta de Contexto também inclui a Configuração de Compressão de Cabeçalho que inclui as informações necessárias para a preparação de canal de ROHC, mas não o contexto de RoHC em si.

Caso a Solicitação de Contexto seja enviada a um antigo S4 SGSN, o antigo S4 SGSN responde com uma mensagem de Resposta de Contexto (IMSI, Identidade de ME (caso disponível), Quintetos de Autenticação não usados, CK, IK, KSISGSN, Contexto(s) de Transportador de EPS, Endereço de sinalização de GW Servidor e TEID(s), ISR Suportada, Ação de Relatório de Mudança de Info de MS (caso disponível), Ação de Relatório de Informações de CSG (caso disponível), Fuso Horário de UE, Capacidade de Rede núcleo de UE, Parâmetros de DRX Específicos de UE, Mudança para Relatar (caso presente)). Os Quintetos de Autenticação são mantidos pelo antigo S4 SGSN.

A flag mudança para Relatar é incluída pela antiga MME ou pelo antigo S4 SGSN caso o relatório de mudança de Fuso Horário de UE, ou Rede Servidora, ou ambos em GW Servidor / PDN GW tenha sido diferido pela antiga MME ou antigo S4 SGSN.

Caso a mensagem de Resposta de Contexto não tenha incluído IMEISV e a

MME ainda não armazene a IMEISV do UE, a MME deve recuperar a Identidade de ME (IMEISV) do UE.

O Endereço de PDN GW e TEID(s) (para S5/S8 com base em GTP) ou Chaves de GRE (S5/S8 com base em PMIP no PDN GW(s) para tráfego de enlace ascendente e o TI(s), são parte do Contexto de Transportador de EPS.

A ISR Suportada é indicada caso o antigo SGSN e GW Servidor associado tenham a capacidade de ativar ISR para o UE.

A nova MME deve ignorar a Capacidade de Rede núcleo de UE contida na Resposta de Contexto apenas quando tiver previamente recebido uma Capacidade de Rede núcleo de UE na Solicitação de Atualização de Área de Rastreamento.

Caso o Tempo de Expiração de Armazenamento em buffer de Dados de DL para o UE não tenha expirado (consulte comunicação de alta latência na cláusula 4.3.17.7), o MME/S4-antigo SGSN indica Espera de Dados de DL Armazenados em buffer na Resposta de Contexto.

Quando isso é indicado, a nova MME deve preparar o plano de usuário em conjunto com o procedimento de TAU para entrega dos dados de DL armazenados em buffer.

Para o UEs vinculados como emergência, caso a IMSI não possa ser autenticada, então, a IMSI deve ser marcada como não autenticada.

Além disso, nesse caso, os parâmetros de segurança são incluídos apenas caso estejam disponíveis.

Caso SIPTO, na Rede Local, esteja ativo para uma conexão de PDN na arquitetura com GW autônomo, a antiga MME/antigo S4 SGSN deve incluir o ID de Rede Doméstica Local da célula antiga no contexto de Transportador de EPS que corresponde ao SIPTO na conexão de PDN de Rede Local. Para o UE que usa Otimização de CIoT EPS sem qualquer conexão de PDN ativada, não há Contexto(s) de Transportador de EPS incluído na mensagem de Resposta de Contexto. Com base na indicação de suporte de Otimização de CIoT EPS, a antiga MME apenas transfere o(s) Contexto(s) de Transportador de EPS que a nova MME suporta. Caso a nova MME não suporte Otimização de CIoT EPS, o(s) Contexto(s) de Transportador de EPS de conexão de PDN não IP não são transferidos para a nova MME. Caso o(s) Contexto(s) de Transportador de EPS de uma conexão de PDN não tenha sido transferido, a antiga MME deve considerar todos os transportadores daquela conexão de PDN como que falharam e liberar aquela conexão de PDN disparando-se o procedimento de desconexão de PDN solicitada por MME, conforme especificado na cláusula 5.10.3. Os dados armazenados em buffer na antiga MME são descartados após recepção de Reconhecimento de Contexto.

6. Caso a verificação de integridade de mensagem de Solicitação de TAU (enviada na etapa 2) tenha falhado, então, a autenticação é obrigatória. As funções de autenticação são definidas na cláusula 5.3.10 em "Função de Segurança". Os procedimentos de cifragem são descritos na cláusula 5.3.10 em "Função de Segurança". Caso a alocação de GUTI seja feita e a rede suporte cifragem, as mensagens de NAS devem ser cifradas. Caso essa solicitação de TAU seja recebida para um UE que já esteja no estado ECM_CONECTADO e o PLMN-ID da TAI enviada pelo eNodeB na Etapa 3 seja diferente daquele do GUTI, incluído na mensagem de Solicitação de TAU, a MME deve atrasar a autenticação do UE até depois da Etapa 21 (mensagem de Conclusão de TAU).

NOTA 4: A MME atrasa a autenticação de modo que o UE primeiro atualize seu PLMN-ID registrado para o novo PLMN-ID selecionado pela RAN durante handover. O novo PLMN-ID é fornecido pela MME ao UE como parte do GUTI na mensagem de aceitação de TAU, na Etapa 20. Ao realizar isso, garante-se que o mesmo PLMN-ID seja usado na derivação da chave Kasme tanto pela rede quanto pelo UE. Caso a nova MME seja configurada para permitir serviços de transportador de emergência Para o UE não autenticado, a nova MME se comporta da seguinte forma: - quando um UE tem apenas serviços de transportador de emergência, a MME omite a autenticação e procedimento de segurança ou aceita que a autenticação pode falhar e continua o procedimento de Atualização de Área de Rastreamento; ou - quando um UE tem serviços de transportador tanto de emergência quanto de não emergência e a autenticação falha, a MME continua o procedimento de Atualização de Área de Rastreamento e desativa todas as conexões de PDN de não emergência, conforme especificado na cláusula 5.10.3.

7. Caso o nó antigo seja uma antiga MME, a nova MME envia uma mensagem de Reconhecimento de Contexto à antiga MME. A antiga MME marca, em seu contexto, que as informações no GW e no HSS são inválidas. Isso garante que a MME atualize os GWs e o HSS caso o UE inicie um procedimento de TAU de volta para MME antes de concluir o procedimento de TAU em andamento. NOTA 5: A atualização dos GWs se refere à modificação de sessão(ões) no GW Servidor. Isso resultará em restabelecimento bem-sucedido do túnel de S11/S4 entre o MME/SGSN e o GW Servidor. Caso o nó antigo seja um antigo S4 SGSN, a MME envia uma mensagem de Reconhecimento de Contexto (ISR Ativada) para o antigo SGSN. A menos que ISR Ativada seja indicada pela MME, o antigo S4 SGSN marca em seu contexto que as informações nos GWs são inválidas. Isso garante que o antigo S4 SGSN atualize os GWs caso o UE inicie um procedimento de RAU de volta ao antigo S4 SGSN antes de concluir o procedimento de TAU em andamento. Caso ISR ativada seja indicada ao antigo S4 SGSN, isso indica que o antigo S4 SGSN deve manter seu contexto de UE incluindo quintetos de autenticação e interromper o temporizador iniciado na etapa 4. Nesse caso, se o temporizador de Desvinculação Implícita estiver sendo executado, o antigo S4 SGSN deve reiniciar o mesmo com um valor um pouco maior do que o temporizador de ISR de Desativação de GERAN/UTRAN de UE. Além disso, nesse caso, se o antigo SGSN tiver mantido o endereço de GW Servidor para plano de usuário e S4 GTP-U TEID, o antigo SGSN deve remover endereço de GW Servidor para plano de usuário e S4 GTP-U TEID localmente. Quando ISR ativada não é indicada e esse temporizador expirar, o antigo SGSN exclui todos os recursos de transportador daquele UE. Visto que a Reconhecimento de Contexto da MME não inclui qualquer mudança de S-GW, o S4 SGSN não envia qualquer mensagem de Solicitação de Exclusão de Sessão ao S-GW. A MME não deve ativar ISR caso o GW Servidor associado não suporte ISR. Caso as funções de segurança não autentiquem o UE corretamente, então, a TAU deve ser rejeitada, e a MME deve enviar uma indicação de rejeição à antiga MME/antigo S4 SGSN. A antiga MME/antigo S4 SGSN deve continuar como se a Identificação e Solicitação de Contexto nunca tivessem sido recebidas. Para o UE que usa Otimização de CIoT EPS sem qualquer conexão de PDN ativada, as etapas 9, 10, 11, 12 e 13 são puladas.

8. Vazio.

9. Caso a MME tenha mudado, a nova MME adota os contextos de transportador recebidos do antigo MME/SGSN como os contextos de transportador de EPS de UE a serem mantidos pela nova MME.

A MME estabelece o(s) transportador(es) de EPS na ordem indicada.

A MME desativa os transportadores de EPS que não podem ser estabelecidos.

A MME verifica o status de transportador de EPS recebido do UE com os contextos de transportador de EPS que a mesma mantém e libera quaisquer recursos de rede relacionados os transportadores de EPS que não estão ativos no UE.

Caso a MME tenha mudado, a nova MME envia uma mensagem de Solicitação de Modificação de Transportador (novo endereço de MME e TEID, ISR Ativada, tipo de RAT) por conexão de PDN ao GW Servidor.

Caso não haja necessidade para que o SGW envie a sinalização ao PDN GW, a MME pode enviar Solicitação de Modificação de Transportadores de Acesso (novo endereço de MME e TEID) por UE ao GW Servidor para otimizar a sinalização.

O Endereço de PDN GW é indicado nos contextos de transportador.

Caso indicado, as informações ISR Ativada indicam que ISR está ativada.

Caso seja uma mobilidade de um SGSN para uma MME e caso a MME suporte relatório de mudança de informações de localização, a MME deve incluir as Informações de Localização de Usuário (de acordo com a granularidade suportada) na Solicitação de Modificação de Transportador, independentemente de o relatório de mudança de informações de localização ter sido solicitado na RAT anterior pelo PGW.

Caso o Fuso Horário de UE ou relatório de mudança de Fuso Horário de UE pendente indicado por mensagem de Resposta de Contexto tenha mudado (por meio de sinalizador Mudança para Relato), a MME inclui o IE de Fuso Horário de UE nessa mensagem.

Caso a Rede Servidora ou relatório de mudança de Rede Servidora pendente indicado por mensagem de Resposta de Contexto tenha mudado (por meio de flag de Mudança para Relato), a MME inclui o novo IE de Rede Servidora nessa mensagem.

Em cenários de compartilhamento de rede, Rede Servidora denota a rede núcleo servidora.

Caso o nó antigo seja uma antiga MME em uma Atualização de Área de Rastreamento com uma mudança de MME, ISR Ativada não deve ser indicada.

NOTA 6: O IE de informações de CSG de usuário é apenas enviado na etapa 9 caso a "flag ativa" seja definido na mensagem de Solicitação de TAU.

Quando a Solicitação de Modificação de Transportadores de Acesso ou Solicitação de Modificação de Transportador não indica ISR Ativada, o S-GW exclui quaisquer recursos de ISR enviando-se uma Solicitação de Exclusão de Transportador para o outro nó de CN que tem recursos de transportador no S-GW reservado.

Caso a nova MME receba o contexto de transportador de EPS com SCEF, então, a nova MME atualiza a SCEF, conforme definido em TS 23.682 [74]. Para otimização de CIoT EPS de Plano de Controle, caso os dados de DL sejam armazenados em buffer no GW Servidor, e caso essa seja uma Atualização de Área de Rastreamento sem mudança de MME e o Tempo de Expiração de Armazenamento em buffer de Dados de DL no contexto de MM para o UE na MME não tenha expirado, ou caso essa seja uma Atualização de Área de Rastreamento com mudança de MME e a antiga MME/S4-antigo SGSN tenha indicado Espera de Dados de DL Armazenados em buffer na Resposta de Contexto, na etapa 5, a MME também deve indicar tunelamento de S11-U de dados de usuário de NAS e incluir seu próprio endereço de S11-U IP e MME DL TEID para dados de DL encaminhados pelo SGW na Solicitação de Modificação de Transportador. A MME também pode realizar isso sem dados de DL armazenados em buffer no SGW.

10. Caso o tipo de RAT tenha mudado, ou o GW Servidor tenha recebido o IE de Informações de Localização de Usuário ou o IE de Fuso Horário de UE ou IE de Informações de CSG de usuário e/ou o IE de Rede Servidora da MME, na etapa 9, o GW Servidor informa o PDN GW(s) dessas informações que, por exemplo, podem ser usadas para carregamento, enviando-se a mensagem de Solicitação de Modificação de Transportador (tipo de RAT) por conexão de PDN ao PDN GW(s) em questão. O IE de Informações de Localização de Usuário e/ou IE de Fuso Horário de UE e/ou IE de Informações de CSG de Usuário e/ou IE de Rede Servidora também estão incluídos, caso os mesmos estejam presentes na etapa 9. Caso a mensagem de Solicitação de Modificação de Transportador não seja enviada devido às razões acima e o carregamento de PDN GW esteja em pausa, então, o SGW deve enviar mensagem de Solicitação de Modificação de Transportador com Indicação de Interrupção de Pausa de Carregamento de PDN para informar o PDN GW de que o carregamento não está mais em pausa. Outros IEs não estão incluídos nesta mensagem.

11. Caso PCC dinâmico seja implementado, e informações de tipo de RAT ou informações de localização de UE precisem ser transportadas do PDN GW para a PCRF, então, o PDN GW deve enviar essas informações à PCRF por meio de um procedimento de Modificação de Sessão de IP-CAN, conforme definido em TS 23.203 [6]. NOTA 7: O PDN GW não precisa esperar pela resposta de PCRF, mas continua na próxima etapa. Caso a resposta de PCRF leve a uma modificação de transportador de EPS, o PDN GW deve iniciar um procedimento de atualização de transportador.

12. O PDN GW atualiza seu campo de contexto para permitir que DL PDUs sejam roteadas para o GW Servidor correto. PDN GW retorna uma Resposta de modificação de transportador (MSISDN) ao GW Servidor. A MSISDN é incluída caso o PDN GW tenha a mesma armazenada em seu contexto de UE. Caso tenha havido uma mudança de RAT para E-UTRAN e relatório de mudança de informações de localização seja necessário e suportado na MME de destino, o PGW deve fornecer Ação de Relatório de Mudança de Info de MS na Resposta de modificação de transportador.

13. O GW Servidor atualiza seu contexto de transportador. Caso ISR Ativada seja indicada na etapa 9 e Tipo de RAT recebido na etapa 9 indique E-UTRAN, então, o GW Servidor apenas atualiza o Endereço de Plano de Controle de MME armazenado localmente e mantém as informações relacionadas ao SGSN inalteradas. Além disso, nesse caso, se o GW Servidor tiver mantido o endereço de SGSN para plano de usuário e S4 GTP-U TEID, o GW Servidor remove o endereço de SGSN para plano de usuário e S4 GTP-U TEID localmente. De outro modo, o GW Servidor deve atualizar todas as informações armazenadas localmente para esse UE com as informações relacionadas recebidas da MME. Isso permite que o GW Servidor realize roteamento de PDUs de Transportador para o PDN GW quando recebidas do eNodeB. O GW Servidor deve retornar uma mensagem de Resposta de modificação de transportador (endereço de GW Servidor e TEID para tráfego de enlace ascendente, Ação de Relatório de Mudança de Info de MS) à nova MME como uma resposta a uma mensagem de Solicitação de Modificação de Transportador, ou uma Resposta de transportador de modificações de Acesso (endereço de GW Servidor e TEID para tráfego de enlace ascendente) como uma resposta a uma mensagem de Solicitação de

Modificação de Transportadores de Acesso. Caso o GW Servidor não possa servir a Solicitação de MME na mensagem de Solicitação de Modificação de Transportadores de Acesso sem sinalização de S5/S8 em vez de retirar a pausa de carregamento no PDN GW ou sem sinalização de Gxc correspondente quando PMIP é usado através da interface S5/S8, o mesmo deve responder à MME com a indicação de que as modificações não são limitadas o transportadores S1-U, e a MME deve repetir sua solicitação com o uso da mensagem de Solicitação de Modificação de Transportador por conexão de PDN. Quando a MME recebe a mensagem de Resposta de modificação de transportador ou de Resposta de transportador de modificações de acesso, a MME verifica se há um evento de monitoramento de "Disponibilidade após Falha de DDN” ou um evento de monitoramento de “Acessibilidade de UE” configurado para o UE na MME e, em tal caso, envia uma notificação de evento (consulte TS 23.682 [74] para informações adicionais). Para otimização de CIoT EPS de Plano de Controle, caso o endereço de MME e MME DL TEID sejam fornecidos na etapa 9, o GW Servidor inclui endereço de GW Servidor e TEID de UL de GW Servidor na mensagem de Resposta de modificação de transportador. Os dados de DL são enviados à MME do GW Servidor. Os dados de DL armazenados em buffer são enviados ao UE, conforme descrito nas etapas 12 a 14 da cláusula 5.3.4B.3.

14. A nova MME verifica se mantém dados de assinatura para o UE identificado pelo GUTI, pelo GUTI adicional ou pela IMSI recebida com os dados de contexto do nó de CN antigo. Caso não haja dados de assinatura na nova MME para esse UE, ou para algum cenário de compartilhamento de rede (por exemplo, GWCN) caso o PLMN-ID da TAI fornecido pelo eNodeB seja diferente daquele do GUTI no contexto de UE, então, a nova MME informa o HSS da mudança de MME enviando-se uma mensagem de Solicitação de Atualização de Localização (Id de MME, IMSI, Flags de ULR, Capacidades de MME, Suporte Homogêneo de Voz sobre IMS de sessões PS, capacidade de UE SRVCC, lista de PLMN equivalente, Identidade de ME (IMEISV)) ao HSS.

Flags de ULR indicam que atualização de localização é enviada de uma MME e o registro de MME deve ser atualizado em HSS.

O HSS não cancela qualquer registro de SGSN.

A indicação de "Suporte Homogêneo de Voz sobre IMS de sessões PS” (consulte a cláusula 4.3.5.8A) não deve estar incluída, a menos que a MME tenha concluído sua avaliação do suporte de “Voz sobre IMS de sessão PS", conforme especificado na cláusula 4.3.5.8. A Identidade de ME é incluída caso a etapa 5 tenha feito com que a MME recupere a IMEISV do UE.

NOTA 8: Nessa etapa, a MME pode não ter todas as informações necessárias para determinar a definição da indicação de Voz sobre IMS de sessão PS Suportada para esse UE (consulte a cláusula 4.3.5.8). Portanto, a MME pode enviar o "Suporte Homogêneo de Voz sobre IMS de sessões PS" posteriormente nesse procedimento.

Caso o UE inicie o procedimento de TAU em uma VPLMN que suporta Roaming de CSG Autônomo e a HPLMN tenha habilitado Roaming de CSG Autônomo na VPLMN (por meio de Acordo de Nível de Serviço) e a MME precise recuperar as informações de assinatura de CSG do UE do CSS, a MME inicia o Procedimento de Atualização de Localização de CSG com CSS, conforme descrito na cláusula 5.3.12.

Caso a MME determine que apenas a capacidade de UE SRVCC mudou, a MME envia uma Solicitação de Notificação ao HSS para informar sobre a capacidade de UE SRVCC alterada. Caso todos os transportadores de EPS do UE tenham valor de ARP de emergência, a nova MME pode omitir o procedimento de atualização de localização ou prosseguir até mesmo se a atualização de localização falhar.

15. O HSS envia uma mensagem de Cancelamento de Localização (IMSI, Tipo de Cancelamento) à antiga MME com um Tipo de Cancelamento definido para Procedimento de Atualização.

16. Ao receber uma mensagem de Cancelamento de Localização e o temporizador iniciado na etapa 4 não estiver sendo executado, a antiga MME remove os contextos de transportador e MM. De outro modo, os contextos são removidos quando o temporizador expira. Isso também garante que o contexto de MM seja mantido na antiga MME para o caso de o UE iniciar outro procedimento de TAU antes de concluir o procedimento de TAU em andamento para a nova MME. A antiga MME reconhece com uma mensagem de Ack de Cancelamento de Localização (IMSI). NOTA 9: ISR Ativada nunca é indicada da Nova MME para antiga. Então, uma antiga MME exclui todos os recursos de transportador do UE em qualquer caso, quando o temporizador iniciado na etapa 4 expira, que é independente de recepção de uma mensagem de Cancelamento de Localização.

17. Ao receber a mensagem de Reconhecimento de Contexto e, caso o UE esteja conectado em lu, o antigo SGSN envia uma mensagem de Comando de Liberação de lu ao RNC após o temporizador iniciado na etapa 4 ter expirado.

18. O RNC responde com uma mensagem de Conclusão de Liberação de lu.

19. O HSS reconhece a Solicitação de Atualização de Localização retornando-se uma mensagem de Ack de Atualização de Localização (IMSI, Dados de Assinatura) à nova MME após o cancelamento do contexto de antiga MME ter terminado. Caso todas as verificações sejam bem-sucedidas, a MME constrói um contexto de MM para o UE. Os Dados de Assinatura podem conter os dados de assinatura de CSG para a PLMN registrada e para a lista de PLMN equivalente solicitada pela MME na etapa 14. Os Dados de Assinatura podem conter parâmetro de Cobertura Aprimorada Restrita. Caso recebido do HSS, a MME armazena esse parâmetro de Cobertura Aprimorada Restrita no contexto de MME MM. Os dados de assinatura podem conter parâmetro de gap de serviço. Caso recebido do HSS, MME armazena esse parâmetro de gap de serviço no contexto de MME MM e passa o mesmo para o UE na mensagem de Aceitação de Atualização de Área de Rastreamento. Caso o UE inicie o procedimento de TAU em uma célula de CSG, a nova MME deve verificar se o ID de CSG e PLMN associada estão contidos na assinatura de CSG e não estão expirados. Caso o ID de CSG e PLMN associada não estejam presentes ou expirados, a MME deve enviar uma mensagem de rejeição de Atualização de Área de Rastreamento ao UE com um valor de causa apropriado. O UE deve remover o ID de CSG e PLMN associada de sua lista de CSG Permitido, caso presente. Caso a Atualização de Localização seja rejeitada pelo HSS, a nova MME rejeita a Solicitação de TAU do UE com uma causa apropriada enviada na mensagem de Rejeição de TAU ao UE. Em tais casos, a nova MME libera quaisquer contextos de Transportador de EPS de MME local para esse UE particular.

20. Caso, devido a restrições de assinatura regionais ou restrições de acesso (por exemplo, restrições de CSG) o UE não tenha permissão para acessar a TA: - A MME rejeita a Solicitação de Atualização de Área de Rastreamento com uma causa apropriada para o UE. - Para o UEs com transportadores de EPS de emergência, isto é, pelo menos um transportador de EPS tem um valor de ARP reservado para serviços de emergência, a nova MME aceita a Solicitação de Atualização de Área de Rastreamento e desativa todas as conexões de PDN de não emergência, conforme especificado na cláusula 5.10.3. Caso o procedimento de Atualização de Área de Rastreamento seja iniciado em estado ECM-OCIOSO, todos os transportadores de EPS de não emergência são desativadas pelo procedimento de Atualização de Área de Rastreamento sem sinalização de desativação de transportador entre o UE e a MME.

A MME responde ao UE com uma mensagem de Aceitação de Atualização de Área de Rastreamento (GUTI, lista de TAI, status de transportador de EPS, número de sequência de NAS, NAS-MAC, ISR Ativada, Voz sobre IMS de sessão PS suportada, indicador de Suporte de Serviço de Emergência, Indicação de Suporte de LCS, Comportamento de Rede Suportada, Gap de Serviço). Caso a flag ativa seja definida, a Lista de Restrição de Handover pode ser enviada ao eNodeB, visto que eNodeB manipula as restrições de roaming e restrições de acesso no caso Intra E-UTRAN.

Caso a flag ativa seja definida na mensagem de Solicitação de TAU, o procedimento de preparação de plano de usuário é ativado em conjunto com a mensagem de Aceitação de TAU.

Caso essa seja uma Atualização de Área de Rastreamento sem mudança de MME e o Tempo de Expiração de Armazenamento em buffer de Dados de DL no contexto de MM para o UE na MME não tenha expirado, ou caso essa seja uma Atualização de Área de Rastreamento com mudança de MME e a antiga MME/S4-antigo SGSN tenha indicado Espera de Dados de DL Armazenados em buffer na Resposta de

Contexto, na etapa 5, o procedimento de preparação de plano de usuário é ativado até mesmo se a MME não tiver recebido a flag ativa na mensagem de Solicitação de TAU.

O procedimento é descrito em detalhes em TS 36.300 [5]. A sequência de mensagem deve ser igual à do procedimento de Solicitação de Serviço disparado por UE especificado na cláusula 5.3.4.1 da etapa em que MME estabelece o(s) transportador(es). O status de transportador de EPS indica os transportadores ativos na rede.

O UE remove quaisquer recursos internos relacionados os transportadores não marcados como ativos no status de transportador de EPS recebido.

Caso ISR ativada seja indicada ao UE, isso indica que sua P-TMSI e RAI devem permanecer registradas na rede e devem permanecer válidas no UE.

Em uma Atualização de Área de Rastreamento com uma mudança de MME, ISR Ativada não deve ser indicada.

Em uma Atualização de Área de Rastreamento sem uma mudança de MME, caso ISR seja ativada para o UE quando a MME recebe a Solicitação de Atualização de Área de Rastreamento, a MME deve manter ISR indicando-se ISR Ativada na mensagem de Aceitação de Atualização de Área de Rastreamento.

A Lista de Restrição de Handover é descrita na cláusula 4.3.5.7 "Restrições de Mobilidade". A MME define a voz sobre IMS de sessão PS suportada, conforme descrito na cláusula 4.3.5.8. Para o UE que usa Otimização de CIoT EPS sem qualquer conexão de PDN ativada, não há status de transportador de EPS incluído na mensagem de

Aceitação de TAU.

O parâmetro de Gap de Serviço é incluído na mensagem de Aceitação de TAU caso o UE tenha indicado capacidade de Gap de Serviço na capacidade de rede de UE e caso Gap de Serviço tenha sido recebida na etapa 19 de HSS nas informações de assinatura ou caso o gap de Serviço nas informações de assinatura tenha sido atualizada por gerenciamento de Perfil de usuário de HSS (isto é, o procedimento de Inserção de Dados de Assinante na cláusula 5.3.9.2) visto que o procedimento de TAU foi previamente executado.

Caso a MME tenha obtido, de maneira bem-sucedida, parâmetros de Configuração de Compressão de Cabeçalho, na etapa 5, isso indica o uso continuado de configuração previamente negociada ao UE no Status de Contexto de Compressão de Cabeçalho para cada transportador de EPS do UE.

Quando o Status de Contexto de Compressão de Cabeçalho indicar que a configuração previamente negociada não pode mais ser usada para algum os transportadores de EPS, o UE deve interromper a realização de compressão e descompressão de cabeçalho, ao enviar ou receber dados com o uso de otimização de CIoT EPS de Plano de Controle nesses transportadores de EPS.

A MME verifica se há um evento de monitoramento de "Disponibilidade após Falha de DDN” ou um evento de monitoramento de “Acessibilidade de UE” configurado para o UE na MME para a qual uma notificação de evento ainda não foi enviada.

Em tal caso, uma notificação de evento é enviada (consulte TS 23.682 [74] para informações adicionais). Caso a MME não tenha recebido o Indicador de correspondência de suporte de voz no Contexto de MM, então, a MME pode enviar uma Solicitação de Correspondência de Capacidade de Rádio de UE ao eNB, conforme descrito na cláusula 5.3.14. Caso a MME não tenha recebido Indicador de correspondência de suporte de voz do eNB, então, com base em implantação, a MME pode definir Indicação de Voz sobre IMS de sessão PS suportada e atualizar a mesma um estágio posterior.

Após a etapa 14 e paralelamente a qualquer uma dentre as etapas antecedentes, a MME deve enviar uma mensagem de Solicitação de Notificação (Suporte Homogêneo de Voz sobre IMS de sessões PS) ao HSS: - Caso a MME tenha avaliado o suporte de Voz sobre IMS de sessões PS, consulte a cláusula 4.3.5.8, e - Caso a MME determine que a mesma precisa atualizar o Suporte Homogêneo de Voz sobre IMS de sessões PS, consulte a cláusula 4.3.5.8A.

A Indicação de Suporte de LCS indica se a rede suporta o EPC-MO-LR e/ou CS-MO-LR, conforme descrito em TS 23.271 [57].

Ao receber a mensagem de Aceitação de TAU e não houver indicação de ISR Ativada, o UE deve definir sua TIN para "GUTI". Quando ISR ativada é indicada e a TIN de UE indica "GUTI", a TIN de UE não deve ser mudada.

Quando ISR ativada é indicada e a TIN é "P-TMSI" ou “TMSI-relacionada à RAT", o UE deve definir sua TIN para “TMSI-relacionada à RAT". Para uma mudança de MME, ISR não é ativada pela nova MME para evitar procedimentos de transferência de contexto com dois nós de CN antigos.

Para um UE vinculado como emergência, ISR de emergência não é ativada.

Caso o procedimento de TAU seja iniciado por seleção de CSG manual e ocorra por meio de uma célula de CSG, o UE, mediante recepção de mensagem de Aceitação de TAU, deve adicionar o ID de CSG e PLMN associada à sua lista de CSG Permitido, caso ainda não estejam presentes.

A seleção de CSG manual não é suportada caso o UE tenha transportadores de emergência estabelecidos.

Caso o UE tenha incluído elemento de informações de parâmetros de DRX de modo ocioso estendido, a MME inclui elemento de informações de parâmetros de DRX de modo ocioso estendido na aceitação de TAU, caso decida habilitar DRX de modo ocioso estendido.

Caso a configuração de plano de usuário seja realizada em conjunto com a mensagem de Aceitação de TAU e a TAU seja realizada por meio de uma célula híbrida, então, a MME deve enviar uma indicação da possibilidade de o UE ser um membro de CSG à RAN em conjunto com a mensagem de controle de S1- MME.

NOTA 10: Caso o UE receba uma mensagem de Aceitação de TAU por meio de uma célula híbrida, o UE não adiciona o ID de CSG correspondente e PLMN associada à sua lista de CSG Permitido.

A adição de um ID de CSG e PLMN associada à lista de CSG Permitido local de UE para uma célula híbrida é realizada apenas por procedimentos de DM OTA ou OMA. Caso o UE receba uma Gap de Serviço na mensagem de Aceitação de TAU, o UE deve armazenar esse parâmetro e aplicar controle de gap de serviço para solicitações de conexão de dados originadas em terminal móvel (consulte a cláusula 4.3.x acima).

21. Caso o GUTI tenha sido mudado, o UE reconhece o novo GUTI retornando-se uma mensagem de Conclusão de Atualização de Área de Rastreamento para a MME. Quando a "flag ativa" não é definido na mensagem de Solicitação de TAU e a Atualização de Área de Rastreamento não foi iniciada em estado ECM- CONECTADO, a MME libera a conexão de sinalização com UE, de acordo com a cláusula 5.3.5. Para um UE que usa Otimização de CIoT EPS de Plano de Controle, quando a "flag ativa de sinalização” é definida, a nova MME não deve liberar a conexão de sinalização de NAS com o UE imediatamente após o procedimento de TAU ser concluído. NOTA 11: A nova MME pode iniciar estabelecimento de E-RAB (consulte TS 36.413 [36]) após execução das funções de segurança, ou aguardar até a conclusão do procedimento de atualização de TA. Para o UE, o estabelecimento de E-RAB pode ocorrer a qualquer momento após a solicitação de atualização de TA ser enviada. No caso de uma operação de atualização de área de rastreamento rejeitada, devido à assinatura regional, restrições de roaming ou restrições de acesso (consulte TS 23.221 [27] e TS 23.008 [28]), a nova MME não deve construir um contexto de MM para o UE. No caso de recepção dos dados de assinante de HSS, a nova MME pode construir um contexto de MM e armazenar os dados de assinante para o UE para otimizar a sinalização entre a MME e o HSS. Uma rejeição deve ser retornada ao UE com uma causa apropriada e a conexão de S1 deve ser liberada.

Mediante retorno para ocioso, o UE deve agir de acordo com TS 23.122 [10]. Caso a nova MME não tenha a capacidade de atualizar o contexto de transportador em um ou mais P-GWs, a nova MME deve desativar os contextos de transportador correspondentes, conforme descrito na cláusula "Procedimento de Desativação de Transportador dedicado Iniciado por MME". Isso não deve fazer com que a MME rejeite a Atualização de Área de Rastreamento.

A nova MME deve determinar a restrição Máxima de APN com base na Restrição de APN recebida de cada contexto de transportador na mensagem de Resposta de Contexto e, então, armazenar o novo valor de Restrição máxima de APN.

Os contextos de transportador devem ser priorizados pela nova MME.

Em qualquer caso, a nova MME deve primeiro atualizar todos os contextos em um ou mais P-GWs e, então, desativar o(s) contexto(s) que a mesma não puder manter, conforme descrito na cláusula "Procedimento de Desativação de Transportador dedicado Iniciado por MME". Isso não deve fazer com que a MME rejeite a Atualização de Área de Rastreamento.

NOTA 12: Caso MS (UE) esteja em estado PMM-CONECTADO, os contextos de transportador são enviados já na mensagem de Solicitação de Encaminhamento de Realocação, conforme descrito na cláusula "Procedimentos de realocação de RNS Servidor" de TS 23.060 [7]. Caso o procedimento de atualização de área de rastreamento falhe um número de vezes máximo permissível, ou caso a MME retorne uma mensagem de Rejeição de Atualização de Área de Rastreamento (Causa), o UE deve entrar em estado EMM DESCADASTRADO. Caso a nova MME identifique que o tipo de RAT mudou, a MME verifica as informações de assinatura para identificar para cada APN a possibilidade de manter a conexão de PDN, desconectar a conexão de PDN com uma solicitação de reativação ou desconectar a conexão de PDN sem solicitação de reativação. Caso a MME decida desativar uma conexão de PDN, a mesma realiza procedimento de Desativação de Conexão de PDN iniciada por MME após o procedimento de atualização de área de rastreamento ser concluído, mas antes de a conexão de interface de S1/RRC ser liberada. Os valores de causa de ESM existentes, conforme especificado em TS 24.301 [46] (por exemplo, #39, "reativação solicitada"; #66 “APN solicitado não suportado em RAT atual e combinação de PLMN"; e para um transportador dedicado, possivelmente #37 "EPS QoS não aceito") são usados para causar comportamento de UE previsível. Caso todas as conexões de PDN sejam desconectadas e o UE não suporte "vinculação sem conectividade de PDN", a MME deve solicitar ao UE para que desvincule e revincule.

5.3.4 Procedimentos de Solicitação de Serviço

5.3.4.1 Solicitação de Serviço Disparada por UE

UE eNodeB MME GW Servidor PDN GW PCRF HSS

1. NAS: Solicitação de Serviço

2. NAS: Solicitação de Serviço

3. Autenticação/Segurança

4. S1-AP: Solicitação de Preparação de Contexto Inicial

5. Estabelecimento de Transportador de Rádio

6. Dados de Enlace Ascendente

7. S1-AP: Initial Context Setup Complete

8. Solicitação de Modificação de Transportador

9. Solicitação de Modificação de Transportador

10. Modificação de sessão de IP-CAN Iniciada por SCEF (A)

11. Resposta de Modificação de Transportador

12. Resposta de Modificação de Transportador Figura 5.3.4.1-1: Procedimento de Solicitação de Serviço Disparada por UE O procedimento de Solicitação de Serviço, nesta cláusula, é disparado pelo UE em status ECM-OCIOSO para estabelecer transportadores de rádio de plano de usuário para o UE. O UE em estado ECM-OCIOSO também pode usar esse procedimento para estabelecer transportadores de rádio de plano de usuário até mesmo se o UE aplicar otimização de CIoT EPS de Plano de Controle, quando o UE e MME suportam transferência de dados de S1-U ou otimização de EPS de Plano de Usuário além da otimização de CIoT EPS de Plano de Controle. Caso o UE tenha um temporizador de Gap de Serviço sendo executado e a Solicitação de Serviço não seja uma resposta a uma radiolocalização de MT, o UE não deve iniciar esse procedimento (consulte a cláusula 4.3.x acima). NOTA 1: Para um S5/S8 com base em PMIP, as etapas de procedimento (A) são definidas em TS 23.402 [2]. As etapas 9 e 11 se referem a S5/S8 com base em GTP.

1. O UE envia mensagens de NAS Solicitação de Serviço para a MME encapsulada em uma mensagem de RRC ao eNodeB. A mensagem(s) de RRC que pode ser usada para portar a S-TMSI e essa mensagem de NAS são descritas em TS 36.300 [5].

2. O eNodeB encaminha mensagem de NAS para MME. A mensagem de NAS é encapsulada em um S1-AP: A Mensagem de UE Inicial (mensagem de NAS, TAI+ECGI da célula servidora, S-TMSI, ID de CSG, Modo de acesso de CSG, causa de estabelecimento de RRC). Os detalhes dessa etapa são descritos em TS 36.300 [5]. Caso a MME não possa manipular a Solicitação de Serviço, a MME rejeitará a mesma. O ID de CSG é fornecido caso o UE envie a mensagem de Solicitação de Serviço por meio de uma célula de CSG ou uma célula híbrida. O modo de acesso de CSG é fornecido caso o UE envie a mensagem de Solicitação de Serviço por meio de uma célula híbrida. Caso o modo de acesso de CSG não seja fornecido, mas o CSG ID seja fornecido, a MME deve considerar a célula como uma célula de CSG. Caso um CSG ID seja indicado e modo de acesso de CSG não seja fornecido, e não haja dados de assinatura para esse CSG ID e PLMN associada ou a assinatura de CSG esteja expirada, a MME rejeita a Solicitação de Serviço com uma causa apropriada. O UE deve remover o CSG ID e PLMN associada da célula onde o UE iniciou o procedimento de solicitação de serviço da lista de CSG Permitido, caso presente. Para o UEs com transportadores de EPS de emergência, isto é, pelo menos um transportador de EPS tem um valor de ARP reservado para serviços de emergência, caso restrições de acesso de CSG não permitam que o UE obtenha serviços normais, a MME deve desativar todos os transportadores de não emergência e aceitar a Solicitação de Serviço. Caso LIPA esteja ativo para uma conexão de PDN e caso a célula acessada pelo UE não realize enlace com o L-GW em que o UE iniciou a Conexão de LIPA PDN, a MME não deve solicitar o estabelecimento dos transportadores da conexão de LIPA PDN ao eNodeB, na etapa 4, e deve solicitar a desconexão da conexão de LIPA PDN, de acordo com a cláusula 5.10.3. Caso o UE não tenha outra conexão de PDN, então, a MME deve rejeitar a Solicitação de Serviço com um valor de causa apropriado que resulta no UE que se desvincula, pula as etapas seguintes do procedimento e inicia a liberação dos recursos de rede núcleo com o procedimento de Desvinculação iniciado por MME implícito, de acordo com a cláusula 5.3.8.3. Caso haja um evento de monitoramento de "Disponibilidade após Falha de DDN” ou um evento de monitoramento de “Acessibilidade de UE” configurado para o UE na MME, a MME envia uma notificação de evento (consulte TS 23.682 [74] para informações adicionais). Para auxiliar Serviços de Localização, o eNB indica o Nível de Cobertura de UE à MME.

3. Os procedimentos de autenticação de NAS/segurança, conforme definido na cláusula 5.3.10 em "Função de Segurança" podem ser realizados.

4. Caso haja um temporizador de Gap de Serviço sendo executado no Contexto de MME MM para o UE e a MME não esteja esperando uma resposta de radiolocalização de MT do UE, a MME rejeita a Solicitação de Serviço com uma causa apropriada e com um Temporizador de Backoff de Gerenciamento de Mobilidade definido para o tempo de Gap de Serviço remanescente. A MME exclui informações relacionadas a S11-U em contexto de UE, caso haja algum, incluindo TEID(DL) para o S11-U para otimização de CIoT EPS de Plano de Controle, caso armazenamento em buffer de dados estejam na MME, contexto de ROHC para otimização de CIoT EPS de Plano de Controle, etc., mas não a Configuração de Compressão de Cabeçalho. A MME envia mensagem de

Solicitação de Preparação de contexto Inicial de S1-AP (endereço de GW Servidor, S1-TEID(s) (UL), QoS(s) de Transportador de EPS, Contexto de Segurança, Id de Conexão de Sinalização de MME, Lista de Restrição de Handover, Indicação de Membro de CSG) ao eNodeB.

Caso haja uma conexão de PDN estabelecida para Acesso de IP Local, essa mensagem inclui um ID de Correlação para habilitar a trajetória de plano de usuário direta entre o HeNB e o L-GW.

Caso haja uma conexão de PDN estabelecida para SIPTO na Rede Local com função de L-GW justaposta ao (H)eNB, essa mensagem inclui um ID de Correlação de SIPTO para habilitar a trajetória de plano de usuário direta entre o (H)eNB e o L-GW.

Essa etapa ativa os transportadores de rádio e S1 para todos os transportadores de EPS ativos.

O eNodeB armazena o Contexto de Segurança, Id de Conexão de Sinalização de MME, QoS(s) de Transportador de EPS e S1- TEID(s) no contexto de UE RAN.

A etapa é descrita em detalhes em TS 36.300 [5]. A Lista de Restrição de Handover é descrita na cláusula 4.3.5.7 "Restrições de Mobilidade". NOTA 2: Nessa versão da especificação de 3GPP, o ID de Correlação e ID de Correlação de SIPTO são definidos de modo igual ao PDN GW TEID de plano de usuário (S5 com base em GTP) ou chave de GRE (S5 com base em PMIP) que é especificado na cláusula 5.3.2.1 e na cláusula 5.10.2. Caso o UE tenha incluído suporte para restrição de uso de Cobertura Aprimorada, a MME envia parâmetro de Cobertura Aprimorada Restrita ao eNB na mensagem S1-AP.

A MME deve apenas solicitar o estabelecimento de Transportador de EPS de Emergência caso o UE não tenha permissão para acessar a célula em que o UE iniciou o procedimento de solicitação de serviço devido à restrição de acesso de CSG.

Caso a Solicitação de Serviço seja realizada por meio de uma célula híbrida,

a Indicação de Membro de CSG que indica se o UE é um membro de CSG deve ser incluída na mensagem S1-AP da MME para a RAN. Com base nessas informações, a RAN pode realizar tratamento diferenciado para membros CSG e não CSG.

5. O eNodeB realiza o procedimento de estabelecimento de transportador de rádio. A segurança de plano de usuário é estabelecida nessa etapa, que é descrita em detalhes em TS 36.300 [5]. Quando os transportadores de rádio de plano de usuário são preparados. A sincronização de estado de transportador de EPS é realizada entre o UE e a rede, isto é, o UE deve remover, localmente, qualquer transportador de EPS para a qual nenhum transportador de rádio é preparado e, caso o transportador de rádio para um transportador de EPS padrão não seja estabelecido, o UE deve desativar, localmente, todos os transportadores de EPS associados àquele transportador de EPS padrão.

6. Os dados de enlace ascendente do UE podem ser, agora, encaminhados pelo eNodeB para o GW Servidor. O eNodeB envia os dados de enlace ascendente para o endereço de GW Servidor e TEID fornecidos na etapa

4. O GW Servidor encaminha os dados de enlace ascendente para o PDN GW.

7. O eNodeB envia uma mensagem S1-AP de Conclusão de Preparação de contexto Inicial (endereço eNodeB, Lista de transportadores de EPS aceitos, Lista de transportadores de EPS rejeitadas, S1 TEID(s) (DL)) à MME. Essa etapa é descrita em detalhes em TS 36.300 [5]. Caso o ID de Correlação ou ID de Correlação de SIPTO seja incluído na etapa 4, o eNodeB deve usar as informações incluídas para estabelecer uma trajetória de plano de usuário direta para o L-GW e encaminhar dados de enlace ascendente para Acesso de IP Local ou SIPTO na Rede Local com função de L-GW justaposta ao (H)eNB em conformidade.

8. A MME envia uma mensagem de Solicitação de Modificação de Transportador (endereço de eNodeB, S1 TEID(s) (DL) para os transportadores de

EPS aceitos, Solicitação de Notificação de Pacote de Enlace Descendente de Atraso, Tipo de RAT, contador de Dados de Exceção MO) por conexão de PDN ao GW Servidor.

Caso o GW Servidor suporte procedimento de Solicitação de Modificação de Transportadores de Acesso e caso não haja necessidade de que o GW Servidor envie a sinalização ao PGW, a MME pode enviar Solicitação de Modificação de Transportadores de Acesso (endereço(s) de eNodeB e TEIDs para plano de usuário de enlace descendente para os transportadores de EPS aceitos, Solicitação de Notificação de Pacote de Enlace Descendente de Atraso) por UE ao GW Servidor para otimizar a sinalização.

O GW Servidor agora tem a capacidade de transmitir dados de enlace descendente para o UE.

O uso do Elemento de Informações de Solicitação de Notificação de Pacote de Enlace Descendente de Atraso é especificado na cláusula 5.3.4.2 abaixo.

Caso a localização de UE e/ou informações de CSG de Usuário solicitadas por PDN GW e a localização de UE e/ou informações de CSG de Usuário tenham mudado, a MME também inclui o IE de Informações de Localização de Usuário e/ou IE de Informações de CSG de Usuário nessa mensagem.

Caso ISR esteja ativada ou caso o IE de Rede Servidora tenha mudado quando comparado ao IE de Rede Servidora relatado por último, então, a MME também inclui o IE de Rede Servidora nessa mensagem.

Caso o Fuso Horário de UE tenha mudado quando comparado ao Fuso Horário de UE relatado por último, então, a MME deve incluir o IE de Fuso Horário de UE nessa mensagem.

Caso a flag interna Sinalização de Conexão de PDN Iniciada por Rede Pendente seja definida, a MME indica o UE disponível para sinalização de extremidade a extremidade na mensagem de Solicitação de Modificação de Transportador e redefine a flag.

A MME apenas inclui o contador de dados de exceção MO se a causa de estabelecimento de RRC for definida para "Dados de Exceção MO" e o UE estiver acessando por meio da NB-IoT RAT.

A MME mantém o Contador de Dados de

Exceção MO para fins de Controle de Taxa de PLMN Servidora (consulte a cláusula 4.7.7.2). A fim de que o P-GW aplique, apropriadamente, Controle de Taxa de APN a Dados de Exceção MO, a MME pode enviar, imediatamente, o Contador de Dados de Exceção MO ao GW Servidor. Alternativamente, a fim de reduzir a sinalização, a MME pode enviar o Contador de Dados de Exceção MO ao GW Servidor, conforme descrito em TS 29.274 [43]. A MME e o GW Servidor limpam o Tempo de Expiração de Armazenamento Temporário de dados de DL em seus contextos de UE caso esteja definido, para lembrar que quaisquer dados de DL armazenados em buffer para um UE que usa funções de economia de energia foram entregues e para evitar qualquer configuração de plano de usuário desnecessária em conjunto com uma TAU posterior. Caso um transportador de EPS padrão não seja aceito pelo eNodeB, todos os transportadores de EPS associados àquele transportador padrão devem ser tratados como transportadores não aceitos. A MME libera os transportadores não aceitos disparando-se o procedimento de liberação de transportador, conforme especificado na cláusula 5.4.4.2. Caso o GW Servidor receba um pacote de DL para um transportador não aceito, o GW Servidor descarta o pacote de DL e não envia uma Notificação de Dados de Enlace Descendente à MME.

9. Caso o tipo de RAT tenha mudado quando comparado ao Tipo de RAT relatado por último ou caso a localização de UE e/ou IEs de Info e/ou Fuso Horário de UE e/ou caso ISR não esteja ativada e id de Rede Servidora e/ou o UE de indicação disponível para sinalização de extremidade a extremidade estejam presentes na etapa 8, o GW Servidor deve enviar a mensagem de Solicitação de Modificação de Transportador (Tipo de RAT, contador de Dados de Exceção MO) por conexão de PDN ao PDN GW. IE de Informações de Localização de Usuário e/ou IE de Informações de CSG de Usuário e/ou IE de Rede Servidora e/ou Fuso Horário de UE e/ou o UE de indicação disponível para sinalização de extremidade a extremidade também são incluídos, caso os mesmos estejam presentes na etapa 8. Caso a mensagem de Solicitação de Modificação de Transportador não seja enviada devido às razões acima e o carregamento de PDN GW esteja em pausa, então, o SGW deve enviar uma mensagem de Solicitação de Modificação de Transportador com Indicação de Interrupção de Pausa de Carregamento de PDN para informar o PDN GW de que o carregamento não está mais em pausa. Outros IEs não estão incluídos nesta mensagem. Caso a mensagem de Solicitação de Modificação de Transportador não seja enviada devido às razões acima, mas a MME tenha indicado o contador de dados de Exceção MO, então, o Gateway Servidor deve notificar o PDN GW de que essa causa de estabelecimento de RRC foi usada pelo Contador de Dados de Exceção MO (consulte TS 29.274 [43]). O GW Servidor indica cada uso dessa causa de estabelecimento de RRC pelo contador relacionado em seu CDR.

10. Caso PCC dinâmico seja implementado, o PDN GW interage com a PCRF para obter a regra(s) de PCC de acordo com o Tipo de RAT por meio de um procedimento de Modificação de Sessão de IP-CAN iniciado por PCEF, conforme definido em TS 23.203 [6]. Caso PCC dinâmico não seja implementado, o PDN GW pode aplicar política de QoS local. O PDN GW indica cada uso da causa de estabelecimento de RRC "Dados de Exceção MO" pelo contador relacionado em sua CDR.

11. O PDN GW envia a Resposta de modificação de transportador ao GW Servidor.

12. O GW Servidor deve retornar uma Resposta de modificação de transportador (endereço de GW Servidor e TEID para tráfego de enlace ascendente) à MME como uma resposta a uma mensagem de Solicitação de Modificação de Transportador, ou uma Resposta de transportador de modificações de Acesso (endereço de GW Servidor e TEID para tráfego de enlace ascendente) como uma resposta a uma mensagem de Solicitação de Modificação de Transportadores de Acesso.

Caso o GW Servidor não possa servir a Solicitação de MME na mensagem de Solicitação de Modificação de Transportadores de Acesso sem sinalização de S5/S8 em vez de remover a pausa de carregamento no PDN GW ou sem sinalização de Gxc correspondente quando PMIP é usado através da interface S5/S8, o mesmo deve responder à MME com a indicação de que as modificações não são limitadas o transportadores S1-U, e a MME deve repetir sua solicitação com o uso de uma mensagem de Solicitação de Modificação de Transportador por conexão de PDN.

Caso SIPTO na Rede Local esteja ativo para uma conexão de PDN com implementação de GW autônomo e o ID de Rede Doméstica Local para acesso autônomo pelo UE difira do ID de Rede Doméstica Local em que o UE iniciou a Conexão PDN SIPTO@LN, a MME deve solicitar desconexão do SIPTO na conexão(ões) de PDN de rede local com o valor de causa "reativação solicitada”, de acordo com a cláusula 5.10.3. Caso o UE não tenha outra conexão PDN, a MME inicia procedimento "desvinculação explícita com revinculação exigida”, de acordo com a cláusula 5.3.8.3. Caso SIPTO na Rede Local esteja ativo para uma conexão PDN com implementação de LGW justaposta e o endereço de L-GW CN da célula acessada pelo UE difira do endereço de L-GW CN da célula em que o UE iniciou o SIPTO na Conexão PDN de Rede Local, a MME deve solicitar desconexão do SIPTO na conexão(ões) de PDN de rede local com o valor de causa "reativação solicitada”, de acordo com a cláusula 5.10.3. Caso o UE não tenha outra conexão de PDN, a MME inicia procedimento "desvinculação explícita com revinculação exigida”, de acordo com a cláusula 5.3.8.3.

5.3.5A Procedimento de Retomada de Conexão Esse procedimento é usado pelo UE para retomar a ECM-conexão caso o UE e a rede suportem Otimização de CIoT EPS de Plano de Usuário e o UE tenha armazenado as informações necessárias para conduzir o procedimento de Retomada de Conexão (consulte TS 36.300 [5]), de outro modo, os procedimentos de Solicitação de Serviço são usados, consulte a cláusula 5.3.4. O UE não deve iniciar esse procedimento caso o UE tenha um temporizador de Gap de Serviço sendo executado (consulte a cláusula 4.3.x acima) e o procedimento de Retomada de Conexão não seja para responder a uma radiolocalização de MT e o procedimento de Retomada de Conexão não seja para enviar uma Atualização de Área de Rastreamento. UE eNodeB MME GW Servidor PDN GW

1. Acesso aleatório

2. Retomada de Conexão RRC

3. Solicitação de Retomada de Contexto de S1-AP UE

4. Resposta de Retomada de Contexto S1-AP UE

5. Reconfiguração de RRC

6. Dados de Enlace Ascendente

7. Solicitação de Modificação de Transportador

8. Resposta de Modificação de Transportador Figura 5.3.5A-1: Procedimento de Retomada de Conexão Iniciada por UE

1. O UE dispara o procedimento de Acesso Aleatório para o eNodeB, consulte TS 36.300 [5].

2. O UE dispara o procedimento de Retomada de Conexão de RRC incluindo informações necessárias pelo eNodeB para acessar o contexto de AS armazenado em UE, consulte TS 36.300 [5]. A E-UTRAN realiza verificações de segurança. A sincronização de estado de transportador de EPS é realizada entre o UE e a rede, isto é, o UE deve remover, localmente, qualquer transportador de EPS para a qual nenhum transportador de rádio é preparado e que não seja um transportador de EPS CIoT de Plano de Controle. Caso o transportador de rádio para um transportador de EPS padrão não seja estabelecido, o UE deve desativar, localmente, todos os transportadores de EPS associados àquele transportador de EPS padrão.

3. O eNodeB notifica a MME de que a conexão de RRC de UE é retomada na mensagem de Solicitação de Retomada de Contexto de S1-AP UE que inclui uma causa de retomada de RRC. Caso o eNodeB não tenha a capacidade de admitir todos os transportadores suspensas, o eNodeB deve indicar isso na lista de transportadores de EPS rejeitadas, consulte TS 36.413 [36]. Caso haja um temporizador de Gap de Serviço em execução no Contexto de MME MM para o UE e a MME não esteja esperando uma resposta de radiolocalização de MT do UE e a Solicitação de Retomada de Conexão não seja uma Atualização de Área de Rastreamento potencial (derivada com base no parâmetro de Causa de Estabelecimento de RRC igual a Sinalização-mo), a MME rejeita a Solicitação de Retomada de Contexto com uma causa apropriada e com um temporizador de backoff definido para o tempo de Gap de Serviço remanescente. O eNodeB deve liberar a conexão de RRC com um tempo de espera estendido igual ao tempo de backoff. A MME entra no estado ECM-CONECTADO. A MME identifica que o UE retorna ao eNodeB para o qual a MME armazenou dados relacionados à associação de S1AP, Contexto de UE e contexto de transportador incluindo o DL TEID(s), necessário para retomar a conexão, consulte o procedimento de Suspensão de Conexão na cláusula 5.3.4A. Caso um transportador de EPS padrão não seja aceito pelo eNodeB, todos os transportadores de EPS associados àquele transportador padrão devem ser tratados como transportadores não aceitos. A MME libera os transportadores não aceitos e não estabelecidas disparando-se o procedimento de liberação de transportador, conforme especificado na cláusula 5.4.4.2. Para auxiliar Serviços de Localização, o eNB indica o Nível de Cobertura de UE à MME. 3a. Caso a conexão de S1-U seja retomada e o UE esteja acessando por meio da NB-IoT RAT com a causa de retomada de RRC definida para "Dados de Exceção MO", a MME deve notificar o Gateway Servidor de cada uso dessa causa de estabelecimento pelo Contador de Dados de Exceção MO. A MME mantém o Contador de Dados de Exceção MO e envia o mesmo ao GW Servidor, conforme indicado em TS 29.274 [43]. 3b. O Gateway Servidor deve notificar o PDN GW se a causa de estabelecimento de RRC "Dados de Exceção MO" tiver sido usada pelo Contador de Dados de Exceção MO (consulte TS 29.274 [43]). O GW Servidor indica cada uso dessa causa de estabelecimento de RRC pelo contador relacionado em seu CDR. 3c. O PDN GW indica cada uso da causa de estabelecimento de RRC "Dados de Exceção de MO" pelo contador relacionado em sua CDR.

4. A MME reconhece a retomada de conexão em mensagem de Resposta de Retomada de Contexto de S1-AP UE. Caso a MME não tenha a capacidade de admitir todas as E-RABs suspensas, a MME deve indicar isso no IE de Lista de E-RABs que Falharam na Retomada.

5. Caso a MME tenha incluído, na etapa 4, uma lista de E-RABs que falharam na retomada, o eNodeB reconfigura os transportadores de rádio.

6. Os dados de enlace ascendente do UE podem ser, agora, encaminhados pelo eNodeB para o GW Servidor. O eNodeB envia os dados de enlace ascendente ao endereço de GW Servidor e TEID armazenados durante o procedimento de Suspensão de Conexão, consulte a cláusula 5.3.4A. O GW Servidor encaminha os dados de enlace ascendente para o PDN GW.

7. A MME envia uma mensagem de Solicitação de Modificação de Transportador (endereço de eNodeB, S1 TEID(s) (DL) para os transportadores de EPS aceitos, Solicitação de Notificação de Pacote de Enlace Descendente de Atraso, Tipo de RAT) por conexão PDN ao GW Servidor. Caso o GW Servidor suporte procedimento de Solicitação de Modificação de Transportadores de Acesso e caso não haja necessidade de que o GW Servidor envie a sinalização ao PDN GW, a MME pode enviar Solicitação de Modificação de Transportadores de Acesso (endereço(s) de eNodeB e TEIDs para plano de usuário de enlace descendente para os transportadores de EPS aceitos, Solicitação de Notificação de Pacote de Enlace Descendente de Atraso) por UE ao GW Servidor para otimizar a sinalização. O GW Servidor agora tem a capacidade de transmitir dados de enlace descendente para o UE. A MME e o GW Servidor limpam o Tempo de Expiração de Armazenamento em buffer de dados de DL em seus contextos de UE caso esteja definido, para lembrar que quaisquer dados de DL armazenados em buffer para um UE que usa funções de economia de energia foram entregues e para evitar qualquer configuração de plano de usuário desnecessária em conjunto com uma TAU posterior.

8. O GW Servidor deve retornar uma Resposta de modificação de transportador (endereço de GW Servidor e TEID para tráfego de enlace ascendente) à MME como uma resposta a uma mensagem de Solicitação de Modificação de Transportador, ou uma Resposta de transportador de modificações de Acesso (endereço de GW Servidor e TEID para tráfego de enlace ascendente) como uma resposta a uma mensagem de Solicitação de

Modificação de Transportadores de Acesso. Caso o GW Servidor não possa servir a Solicitação de MME na mensagem de Solicitação de Modificação de Transportadores de Acesso sem sinalização de S5/S8 em vez de remover a pausa carregamento no PDN GW ou sem sinalização de Gxc correspondente quando PMIP é usado através da interface S5/S8, o mesmo deve responder à MME com a indicação de que as modificações não são limitadas o transportadores S1-U, e a MME deve repetir sua solicitação com o uso de uma mensagem de Solicitação de Modificação de Transportador por conexão PDN. Caso SIPTO na Rede Local esteja ativo para uma conexão de PDN com implementação de GW autônomo e o ID de Rede Doméstica Local para acesso autônomo pelo UE difira do ID de Rede Doméstica Local em que o UE iniciou a Conexão PDN SIPTO@LN, a MME deve solicitar desconexão do SIPTO na conexão(ões) de PDN de rede local com o valor de causa "reativação solicitada”, de acordo com a cláusula 5.10.3. Caso o UE não tenha outra conexão de PDN, a MME inicia procedimento "desvinculação explícita com revinculação exigida”, de acordo com a cláusula 5.3.8.3. Caso SIPTO na Rede Local esteja ativo para uma conexão de PDN com implementação de LGW justaposta e o endereço de L-GW CN da célula acessada pelo UE difira do endereço de L-GW CN da célula em que o UE iniciou o SIPTO na Conexão de PDN de Rede Local, a MME deve solicitar desconexão do SIPTO na conexão(ões) de PDN de rede local com o valor de causa "reativação solicitada”, de acordo com a cláusula 5.10.3. Caso o UE não tenha outra conexão de PDN, a MME inicia procedimento "desvinculação explícita com revinculação exigida”, de acordo com a cláusula 5.3.8.3.

5.3.4A Procedimento de Suspensão de Conexão Esse procedimento é usado pela rede para suspender a conexão, caso o UE e a rede suportem Otimização de CIoT EPS de Plano de Usuário (consulte

TS 36.300 [5]). UE eNodeB MME GW Servidor

1. S1-AP: Solicitação de Suspensão de Contexto de UE

2. Solicitação de Liberação de Transportadores de Acesso

3. Resposta de Liberação de Transportadores de Acesso

4. S1-AP: Resposta de Suspensão de Contexto de UE

5. Suspensão de Conexão de RRC Figura 5.3.4A-1: Procedimento de Suspensão de Conexão iniciado por eNodeB

1. O eNodeB inicia o procedimento de Suspensão de Conexão com a MME, consulte TS 36.413 [36]. O eNodeB indica à MME que a conexão de RRC de UE deve ser suspensa e, mediante a indicação, a MME entra em ECM-OCIOSO. Os dados relacionados à associação de S1AP, Contexto de UE e contexto de transportador, necessários para retomar a conexão são mantidos no eNB, UE e na MME. O eNodeB pode incluir as Informações Sobre Células Recomendadas E eNBs Para Radiolocalização na mensagem de Solicitação de Suspensão de Contexto de S1 UE. Caso disponível, a MME deve armazenar essas informações para serem usadas ao radiolocalizar o UE. O eNB inclui Informações para Cobertura Aprimorada, caso disponível, na mensagem de Solicitação de Suspensão de Contexto de S1 UE. Caso controle de gap de serviço deva ser aplicado para o UE (consulte a cláusula 4.3.x), o temporizador de gap de serviço deve ser iniciado na MME ao entrar em ECM-OCIOSO, exceto quando a conexão tiver sido iniciada após uma Radiolocalização de um evento de MT, ou após a sinalização de TAU MO sem qualquer flag ativa definida (isto é, flag ativa ou flag ativa de sinalização).

2. A MME envia uma mensagem de Solicitação de Liberação de Transportadores de Acesso ao GW Servidor que solicita a liberação de todos os transportadores de S1-U para o UE.

3. O GW Servidor libera todas as informações relacionadas a eNodeB (endereço e TEIDs de enlace descendente) para o UE e responde com uma mensagem de Resposta de Liberação de Transportadores de Acesso à MME. Outros elementos do contexto de GW Servidor de UE não são afetados. Caso pacotes de enlace descendente cheguem para o UE, o GW Servidor inicia armazenamento temporário de pacotes de enlace descendente recebidos para o UE e começo do procedimento de "Solicitação de Serviço Disparada por Rede", descrito na cláusula 5.3.4.3. NOTA: Com base em política de operador, qualquer Indicação recebida de "Liberação Anormal de Enlace de Rádio” pode ser usada por GW Servidor em decisões subsequentes para disparar pausa de carregamento de PDN, caso o recurso tenha sido habilitado naquela PDN. O GW Servidor informa a MME na mensagem de Resposta de Liberação de Transportador de Acesso sobre a liberação de transportadores de S1-U.

4. A MME envia um S1AP: Mensagem de Resposta de Suspensão de Contexto de UE ao eNB para terminar, de maneira bem-sucedida, o procedimento de Suspensão de Conexão iniciado pelo eNB, consulte TS 36.413 [36].

5. O eNodeB envia mensagem de RRC para suspender a Conexão de RRC com o UE, consulte TS 36.300 [5]). Caso controle de gap de serviço deva ser aplicado para o UE (consulte a cláusula 4.3.x), o temporizador de gap de serviço deve ser iniciado no UE ao entrar em ECM-OCIOSO, exceto quando a conexão tiver sido iniciada como uma resposta à radiolocalização de um evento de MT, ou após a sinalização de TAU MO sem qualquer flag ativa definida (isto é, flag ativa ou flag ativa de sinalização).

5.3.5 Procedimento de liberação de S1 Esse procedimento é usado para liberar a conexão de sinalização de S1-AP lógica (pela S1-MME) e todos os transportadores S1 (em S1-U) para um UE. Esse Procedimento libera o transportador de S11-U em otimização de CIoT EPS de Plano de Controle (exceto no caso de armazenamento temporário em MME), em vez do transportador de S1-U. O procedimento moverá o UE de ECM- CONECTADO para ECM-OCIOSO tanto no UE quanto na MME, e todas as informações de contexto relacionadas O UE são excluídas no eNodeB. Quando a conexão de sinalização de S1-AP é perdida, por exemplo, devido à perda do transporte de sinalização ou devido a uma falha de eNodeB ou MME, o procedimento de liberação de S1 é realizado, localmente, pelo eNodeB e pela MME. Quando o procedimento de liberação de S1 é realizado localmente pelo eNodeB ou pela MME, cada nó realiza, localmente, suas ações, conforme descrito no fluxo de procedimento abaixo sem usar ou depender de qualquer sinalização mostrada diretamente entre eNodeB e MME. Caso controle de gap de serviço deva ser aplicado para o UE (consulte a cláusula 4.3.x acima), o temporizador de gap de serviço deve ser iniciado em MME e UE ao entrar em ECM-OCIOSO, exceto quando a conexão tiver sido iniciada após uma Radiolocalização de um evento de MT, ou após a sinalização de TAU MO sem qualquer flag ativa definida (isto é, flag ativa ou flag ativa de sinalização). A iniciação de procedimento de Liberação de S1 é:

- iniciada por eNodeB com causa, por exemplo, Intervenção de O&M, Falha Não Especificada, Inatividade de Usuário, sinalização de RRC repetida Falha de Verificação de Integridade, Liberação devido à liberação de conexão de sinalização gerada por UE, retirada de CS disparado, Redirecionamento entre RATs, etc. conforme definido em TS 36.413 [36]; ou - iniciada por MME com causa, por exemplo, falha de autenticação, desvinculação, célula de CSG não permitida (por exemplo, o ID de CSG da célula de CSG atualmente usada expira ou é removido dos dados de assinatura de CSG), etc. Os procedimentos de liberação tanto iniciado por eNodeB quanto iniciado por MME S1 são mostrados na Figura 5.3.5-1. UE eNodeB MME GW Servidor

1. Liberação de Conexão de RRC

1. S1-AP: Solicitação de Liberação de Contexto de S1 UE

2. Solicitação de Liberação de Transportadores de Acesso

3. Resposta de Liberação de Transportadores de Acesso

4. S1-AP: Comando de Liberação de Contexto de S1 UE

5. Liberação de Conexão de RRC

6. S1-AP: Conclusão de Liberação de Contexto de S1 UE Figura 5.3.5-1: Procedimento de Liberação de S1 1a. Em determinados casos, o eNodeB pode liberar a conexão de sinalização de UE antes ou em paralelo à solicitação da MME para liberar o contexto de S1, por exemplo, o eNodeB inicia uma Liberação de Conexão de RRC para retirada de CS por meio de redirecionamento. 1b. Caso o eNodeB detecte uma necessidade de liberar a conexão de sinalização de UE e todos os transportadores de rádio para o UE, o eNodeB envia uma mensagem de Solicitação de Liberação de Contexto de S1 UE (Causa) à MME. Causa indica a razão para a liberação (por exemplo, intervenção de O&M, falha não especificada, inatividade de usuário, falha de verificação de integridade repetida ou liberação devido à liberação de conexão de sinalização gerada por UE). NOTA 1: A Etapa 1 é apenas realizada quando o procedimento de liberação de S1 iniciado por eNodeB é considerado. A Etapa 1 não é realizada e o procedimento inicia com a Etapa 2 quando o procedimento de liberação de S1 iniciado por MME é considerado. Para otimização de CIoT EPS de Plano de Controle com armazenamento em buffer de dados na MME, a etapa 2 e a etapa 3 são puladas.

2. A MME envia uma mensagem de Solicitação de Liberação de Transportadores de Acesso (Liberação Anormal de Indicação de Enlace de Rádio) ao S-GW que solicita a liberação de todos os transportadores S1-U para o UE, ou a S11-U em otimização de CIoT EPS de Plano de Controle caso armazenamento temporário seja no S-GW. Essa mensagem é disparada tanto por uma mensagem de Solicitação de Liberação de S1 do eNodeB ou por outro evento de MME. A Liberação Anormal de Indicação de Enlace de Rádio é incluída caso o procedimento de liberação de S1 seja devido a uma liberação anormal do enlace de rádio.

3. Caso o S-GW tenha recebido uma Solicitação de Liberação de Transportadores de Acesso, o S-GW libera todas as informações relacionadas a eNodeB (endereço e TEIDs), ou as informações relacionadas a MME TEIDs em otimização de CIoT EPS de Plano de Controle (endereço e TEIDs), para o UE e responde com uma mensagem de Resposta de Liberação de Transportadores de Acesso à MME. Outros elementos do contexto de S-GW de UE não são afetados. O S-GW retém a configuração de S1-U que o S-GW alocou para os transportadores de UE. O S-GW inicia armazenamento em buffer de pacotes de enlace descendente recebidos para o UE e começo do procedimento de "Solicitação de Serviço Disparada por Rede", descrito na cláusula 5.3.4.3, caso pacotes de enlace descendente cheguem para o UE. Em otimização de CIoT EPS de Plano de Controle, dados de enlace descendente disparam transporte de Dados Terminados em Terminal Móvel em sinalização de NAS definida na cláusula 5.3.4B.3. NOTA 2: Com base em política de operador, qualquer Indicação recebida de "Liberação Anormal de Enlace de Rádio” pode ser usada por GW Servidor em decisões subsequentes para disparar pausa de carregamento de PDN, caso o recurso tenha sido habilitado naquela PDN.

4. A MME libera S1 enviando-se a mensagem de Comando de Liberação de Contexto de S1 UE (Causa) ao eNodeB.

5. Caso a conexão de RRC não esteja ainda liberada, o eNodeB envia uma mensagem de Liberação de Conexão de RRC ao UE em Modo Reconhecido. Uma vez que a mensagem é reconhecida pelo UE, o eNodeB exclui o contexto de UE.

6. O eNodeB confirma a Liberação de S1 retornando-se uma mensagem de Conclusão de Liberação de Contexto de UE de S1 (ECGI, TAI) à MME. Com isso, a conexão de sinalização entre a MME e o eNodeB para aquele UE é liberada. Essa etapa deve ser realizada imediatamente após a etapa 4, por exemplo, não deve ser atrasada em situações em que o UE não reconhece a Liberação de Conexão de RRC. O eNodeB pode incluir as Informações Sobre Células Recomendadas E eNodeBs Para Radiolocalização na mensagem de Conclusão de Liberação de Contexto de S1 UE. Caso disponível, a MME deve armazenar essas informações para serem usadas ao radiolocalizar o UE.

O eNB inclui Informações para Cobertura Aprimorada, caso disponível, na mensagem de Conclusão de Liberação de Contexto de S1 UE.

A MME exclui quaisquer informações relacionadas a eNodeB (“Endereço de eNodeB em Uso para S1-MME", "MME S1 UE AP ID" e "eNB S1 UEAP ID") do contexto de MME de UE, mas, retém o restante do contexto de MME de UE que inclui as informações de configuração de S1-U de S-GW (endereço e TEIDs). Todos os transportadores de EPS de não GBR estabelecidas para o UE são preservadas na MME e no GW Servidor.

Se a causa de liberação de S1 for devido à inatividade de Usuário I, Redirecionamento entre RATs, a MME deve preservar os transportadores de GBR.

Se a causa de liberação de S1 for devido a retirada de CS disparado, detalhes adicionais sobre manipulação de transportador são descritos em TS 23.272 [58]. De outro modo, por exemplo, Conexão de Rádio Com UE Perdido, conexão de sinalização de S1 perdida, falha de eNodeB, a MME deve disparar o procedimento de Desativação de Transportador dedicado Iniciado por MME (cláusula 5.4.4.2) para o(s) transportador(es) de GBR do UE após o procedimento de Liberação de S1 ser concluído.

NOTA 3: EPC não suporta o recurso de preservação de GPRS com a definição da MBR para transportadores de GBR para zero.

NOTA 4: A MME pode deferir a desativação de transportadores de GBR por um período curto (na ordem de segundos) mediante recepção de uma Solicitação de Liberação de Contexto de S1 UEAP devido a razões de rádio, de modo a permitir que o UE restabeleça os transportadores de rádio e S1-U correspondentes e, desse modo, evite desativação dos transportadores de GBR.

Caso LIPA esteja ativo para uma conexão PDN, o HeNB informa o L-GW justaposto através de sinalização interna para liberar a trajetória de plano de usuário direta para o HeNB.

Após a trajetória de plano de usuário direta ser liberada, caso pacotes de enlace descendente cheguem para o UE, o L-GW encaminha o primeiro pacote no túnel de S5 para o S-GW para iniciar o procedimento "Solicitação de Serviço Disparada por Rede”, conforme descrito na cláusula 5.3.4.3.

5.3.4B.2 Transporte de Dados Originados em Terminal Móvel em otimização de CIoT EPS de Plano de Controle com conectividade de P-GW O UE não deve iniciar esse procedimento caso o UE tenha um temporizador de Gap de Serviço em execução (consulte cláusula 4.3.x acima). UE eNodeB MME S-GW P-GW

0. UE está ECM Ocioso

1. Estabelecimento de conexão de RRC (NAS DATA PDU com EBI) 1b. Recuperar contexto de UE

2. Mensagem de UE Inicial de S1-AP (PDU de Dados de NAS com EBI)

3. Verificação de Integridade e descriptação de dados

4. Solicitação de Modificação de Transportador 5. Solicitação de modificação de Transportador

7. Resposta de modificação 6. Resposta de modificação de transportador de transportador

8. Dados de Enlace 8. Dados de Enlace Ascendente Ascendente

9. Dados de Enlace 9. Dados de Enlace Descendente Descendente

10. Criptografia de dados e Proteção de integridade

11. msg. de S1-AP de enlace descendente

11. Comando de liberação de contexto de S1-AP UE

12. Mensagem de DL de RRC (PDU de Dados NAS com EBI)

13. Notificação de Entrega de

NAS

14. Nenhuma atividade adicional detectada

15. procedimento de liberação de S1 (consulte a clausula 5.3.5) Figura 5.3.4B.2-1: Transporte de Dados MO em NAS PDU

0. O UE está ECM-OCIOSO.

1. O UE estabelece uma conexão de RRC e envia, como parte da mesma, uma NAS PDU com integridade protegida. A NAS PDU porta o ID de

Transportador de EPS e criptografa Dados de Enlace Ascendente. O UE também pode indicar, em Informações de Auxílio à Liberação na NAS PDU, se transmissões adicionais de Dados de Enlace Ascendente ou Enlace Descendente são esperadas, ou apenas uma única transmissão de dados de enlace descendente (por exemplo, Reconhecimento ou resposta a Dados de enlace ascendente) subsequente a essa transmissão de dados de enlace ascendente é esperada. 1b. No caso de NB-IoT, o eNB, com base em configuração, pode recuperar o perfil de QoS negociado por EPS da MME, caso não seja previamente recuperado. O Código de MME dentro da S-TMSI na mensagem RRCConnectionRequest é usado para identificar a MME. O eNB pode aplicar priorização entre solicitações de diferentes UEs antes de disparar a etapa 2 e ao longo da conexão de RRC. O eNB pode recuperar parâmetros adicionais (por exemplo, Capacidades de Rádio de UE - consulte TS 36.413 [36]).

2. A NAS PDU enviada na etapa 1 é retransmitida para a MME pelo eNodeB com o uso de uma mensagem de UE Inicial de S1-AP com uma indicação caso o eNodeB suporte reconhecimentos para PDUs de dados de NAS de enlace descendente. Para auxiliar Serviços de Localização, o eNB indica o Nível de Cobertura de UE à MME.

3. Caso haja um temporizador de Gap de Serviço em execução no Contexto de MME MM para o UE e a MME não esteja esperando uma resposta de Radiolocalização de MT do UE, a MME rejeita a solicitação descartando-se a PDU de dados de NAS e enviando-se uma mensagem de Rejeição de Serviço ao UE com uma causa apropriada e com um Temporizador de Backoff de Gerenciamento de Mobilidade definido para o tempo de Gap de Serviço remanescente, seguido de execução da etapa 15.

A MME verifica a integridade da NAS PDU de entrada e descriptografa os dados contidos na mesma.

A MME deve descomprimir o cabeçalho de IP caso compressão de cabeçalho se aplique à conexão PDN.

A MME realiza (e o UE responde) quaisquer procedimentos de EMM ou ESM, caso necessário, por exemplo, os procedimentos relacionados à segurança.

As etapas 4 a 9 podem continuar paralelamente a isso, entretanto, as etapas 10 e 11 devem aguardar conclusão de todos os procedimentos de EMM e ESM. 4a.

Caso a conexão de S11-U não seja estabelecida, a MME envia uma mensagem de Solicitação de Modificação de Transportador (endereço de MME, MME TEID DL, Solicitação de Notificação de Pacote de Enlace Descendente de Atraso, Tipo de RAT, contador de dados de Exceção MO) para cada conexão PDN ao GW Servidor.

O uso do Elemento de Informações de Solicitação de Notificação de Pacote de Enlace Descendente de Atraso é especificado na cláusula 5.3.4.2 com referência ao procedimento de solicitação de serviço iniciado por UE, mas se aplica igualmente nesse caso.

A MME deve indicar tunelamento de S11-U de dados de usuário de NAS e enviar seu próprio endereço de S11-U IP e MME DL TEID para dados de DL encaminhados pelo SGW.

Além disso, independentemente de a S11-U já estar estabelecida: - Caso a localização de UE e/ou informações de CSG de Usuário solicitadas por PDN GW e a localização de UE e/ou informações de CSG de usuário tenham mudado, a MME deve enviar a mensagem de Solicitação de Modificação de Transportador e também incluir o IE de Informações de Localização de Usuário e/ou IE de Informações de CSG de Usuário nessa mensagem. - Caso o IE de Rede Servidora tenha mudado quando comparado ao IE de Rede Servidora relatado por último, então, a MME deve enviar a mensagem de

Solicitação de Modificação de Transportador e também incluir o IE de Rede Servidora nessa mensagem. - Caso o Fuso Horário de UE tenha mudado quando comparado ao Fuso Horário de UE relatado por último, então, a MME deve enviar a mensagem de Solicitação de Modificação de Transportador e incluir o IE de Fuso Horário de UE nessa mensagem.

Caso a RAT atualmente usada seja NB-IOT, isso deve ser relatado como diferente de outros tipos de E-UTRA.

A MME apenas inclui contador de dados de exceção MO se a causa de estabelecimento de RRC for definida para "Dados de Exceção MO" e o UE estiver acessando por meio da NB-IoT RAT.

O GW Servidor indica cada uso dessa causa de estabelecimento de RRC pelo contador relacionado em seu CDR.

A MME mantém o Contador de Dados de Exceção de MO para fins de Controle de Taxa de PLMN Servidora (consulte a cláusula 4.7.7.2). A fim de que o P-GW aplique, apropriadamente, Controle de Taxa de APN a Dados de Exceção MO, a MME pode enviar, imediatamente, o Contador de Dados de Exceção MO ao GW Servidor.

Alternativamente, a fim de reduzir a sinalização, a MME pode enviar o Contador de Dados de Exceção MO ao GW Servidor, conforme indicado em TS 29.274 [43]. 4b.

Caso a conexão de S11-U seja estabelecida e o UE esteja acessando por meio da NB-IoT RAT com a causa de estabelecimento de RRC definida para "Dados de Exceção MO", a MME deve notificar o Gateway Servidor.

A MME mantém o Contador de Dados de Exceção MO para fins de Controle de Taxa de PLMN Servidora (consulte a cláusula 4.7.7.2). A fim de que o P-GW aplique, apropriadamente, Controle de Taxa de APN a Dados de Exceção MO, a MME pode enviar, imediatamente, o Contador de Dados de Exceção MO ao GW Servidor.

Alternativamente, a fim de reduzir a sinalização, a MME pode enviar o Contador de Dados de Exceção de MO ao GW Servidor, conforme indicado em TS 29.274 [43].

5. Caso o Tipo de RAT tenha mudado quando comparado ao Tipo de RAT relatado por último ou caso a Localização de UE e/ou IEs de Info e/ou Fuso Horário de UE e id de Rede Servidora estejam presentes na etapa 4, o GW Servidor deve enviar a mensagem de Solicitação de Modificação de Transportador (Tipo de RAT, contador de dados de Exceção MO) ao PDN GW. IE de Informações de Localização de Usuário e/ou IE de Informações de CSG de Usuário e/ou IE de Rede Servidora e/ou Fuso Horário de UE também são incluídos, caso os mesmos estejam presentes na etapa 4. Caso a mensagem de Solicitação de Modificação de Transportador não seja enviada devido às razões acima e o carregamento de PDN GW esteja em pausa, então, o SGWS-GW deve enviar uma mensagem de Solicitação de Modificação de Transportador com Indicação de Interrupção de Pausa de Carregamento de PDN para informar o PDN GW de que o carregamento não está mais em pausa. Outros IEs não estão incluídos nesta mensagem. Caso a mensagem de Solicitação de Modificação de Transportador não seja enviada devido às razões acima, mas a MME tenha indicado contador de dados de Exceção MO, então, o Gateway Servidor deve notificar o PDN GW de que essa causa de estabelecimento de RRC foi usada pela indicação do Contador de Dados de Exceção MO (consulte TS 29.274 [43]). O GW Servidor indica cada uso dessa causa de estabelecimento de RRC pelo contador relacionado em seu CDR.

6. O PDN GW envia a Resposta de modificação de transportador ao GW Servidor. O PDN GW indica cada uso da causa de estabelecimento de RRC "Dados de Exceção de MO" pelo contador relacionado em sua CDR.

7. Caso uma mensagem de Solicitação de Modificação de Transportador tenha sido enviada na etapa 4, o GW Servidor deve retornar uma Resposta de modificação de transportador (endereço de GW Servidor e TEID para tráfego de enlace ascendente) à MME como uma resposta a uma mensagem de Solicitação de Modificação de Transportador. O endereço de GW Servidor para Plano de Usuário de S11-U e TEID de GW Servidor são usados pela MME para encaminhar dados de UL ao SGW.

8. A MME envia dados de Enlace Ascendente para o P-GW por meio do S-GW.

9. Caso nenhum dos Dados de Enlace Descendente seja esperado com base nas Informações de Auxílio à Liberação do UE na etapa 1, isso significa que todas as trocas de dados de camada de aplicação foram concluídas com a transferência de dados de UL e, portanto, a menos que a MME esteja ciente de tráfego de MT pendente e, a menos que transportadores S1-U sejam estabelecidas, a MME libera imediatamente a conexão e, portanto, a etapa 14 é executada. De outro modo, dados de enlace descendente podem chegar no P-GW e o P-GW envia os mesmos à MME por meio do S-GW. Caso nenhum dos dados seja recebido, as etapas 10 a 12 são puladas e o eNB pode disparar a etapa 14 após a etapa 13 não detectar nenhuma atividade. Enquanto a conexão de RRC está ativa, o UE ainda pode enviar dados de enlace ascendente e pode receber dados de enlace descendente em NAS PDUs que são portadas em mensagens de enlace ascendente ou (respectivamente) enlace descendente de S1AP (não mostradas na Figura). A qualquer momento que o UE não tenha transportadores de plano de usuário estabelecidas, o mesmo pode fornecer Informações de Auxílio à Liberação com os dados de enlace ascendente. Nesse caso, para auxiliar Serviços de Localização, o eNB pode indicar, caso necessário, o Nível de

Cobertura de UE para a MME.

10. Caso dados de enlace descendente sejam recebidos na etapa 9, a MME criptografa e protege a integridade dos dados de enlace descendente.

11. Caso a etapa 10 seja executada, então, dados de enlace descendente são encapsulados em uma NAS PDU e enviados ao eNB em uma Mensagem de Enlace Descendente de S1-AP. Caso o eNodeB suporte reconhecimentos de PDUs de dados de NAS de enlace descendente e, caso reconhecimentos de PDUs de dados de NAS de enlace descendente sejam habilitadas nas informações de assinatura para o UE, a MME indica, na mensagem de S1-AP de enlace descendente, que Reconhecimento é solicitada pelo eNodeB. Para conexões de PDN do tipo IP PDN configuradas para suportar Compressão de Cabeçalho, a MME deve aplicar compressão de cabeçalho antes de encapsular dados na mensagem de NAS. Caso a etapa 10 não seja executada, a MME envia mensagem de Indicação de Estabelecimento de Conexão ao eNB. A Capacidade de Rádio de UE pode ser fornecida da MME para o eNB na mensagem de Indicação de Estabelecimento de Conexão, e o eNB deve armazenar as informações de Capacidade de Rádio de UE recebidas. Caso as Informações de Auxílio à Liberação tenham sido recebidas com dados de enlace ascendente e tenham indicado que dados de enlace descendente eram esperados, isso significa que o próximo pacote de enlace descendente após o envio das Informações de Auxílio à Liberação é o último pacote da troca de dados de camada de aplicação, então, para esse caso, a menos que a MME esteja ciente de tráfego de MT pendente adicional e, a menos que transportadores de S1-U sejam estabelecidos, a MME envia um Comando de Liberação de Contexto de S1 UE imediatamente após a mensagem de S1-AP que inclui os dados de enlace descendente encapsulados em NAS PDU como uma indicação de que o eNodeB deve liberar a conexão de RRC prontamente após enviar, de maneira bem-sucedida, dados ao UE. Caso o UE esteja acessando por meio de uma célula de NB-IoT, ou caso esteja acessando por meio de uma célula de WB-E-UTRAN e tenha a capacidade de modo de CE B, para determinar a estratégia de retransmissão de NAS PDU, a MME deve considerar o atraso de transmissão da NAS PDU e, quando aplicável, o modo de CE, isto é, definir os temporizadores de NAS com tempo longo o suficiente de acordo com o pior atraso de transmissão (consulte TS 24.301 [46]).

12. O eNB envia uma mensagem de dados de enlace descendente de RRC que inclui os dados de enlace descendente encapsulados em NAS PDU. Caso, na etapa 11, a mensagem de S1-AP com a NAS DATA PDU seja seguida por um Comando de Liberação de Contexto de S1 UE, a etapa 15 é concluída prontamente após a transmissão de Dados de Enlace Descendente da NAS PDU ao UE e a Reconhecimento para MME na etapa 13 foi concluída no eNB, e o eNB não precisa entrar na etapa 14. Caso compressão de cabeçalho tenha sido aplicada à PDN, o UE realizará descompressão de cabeçalho para reconstruir o cabeçalho de IP.

13. O eNodeB envia uma indicação de Entrega de NAS para a MME, caso solicitado. Caso o eNodeB relate uma entrega malsucedida com uma Indicação de Não Entrega de S1-AP NAS, a MME deve aguardar algum tempo até que o UE tenha potencialmente mudado de célula e restabelecido contato com a MME, por meio do qual a MME deve reenviar a mensagem de S1-AP de enlace descendente ao eNodeB, de outro modo, a MME relata uma entrega malsucedida à SCEF no caso de procedimento de T6a (consulte TS 23.682 [74], cláusula 5.13.3). Caso o eNodeB relate uma entrega bem-sucedida com uma Indicação de Entrega de S1-AP NAS e, caso os dados de enlace descendente sejam recebidos pela interface T6a, a MME deve responder à SCEF (consulte TS 23.682 [74], cláusula 5.13.3). Caso o eNodeB não suporte indicações de entrega de S1-AP NAS, a MME indica um código de causa “Entrega Não Reconhecida Bem-sucedida” à SCEF, de outro modo, “Entrega Reconhecida Bem- sucedida”, para que a SCEF saiba se entrega confiável foi ou não possível.

14. Caso não exista nenhuma atividade de NAS PDU durante um tempo, o eNB inicia uma liberação de S1 na etapa 15.

15. Um procedimento de liberação de S1, de acordo com a cláusula 5.3.5 disparado pelo eNodeB ou MME. Alternativamente, caso a MME, na etapa 11, tenha enviado Comando de Liberação de Contexto de S1 UE, então, o procedimento inicia com a etapa 5 na cláusula 5.3.5, ou Procedimento de Suspensão de Conexão definido na cláusula 5.3.4A.

5.3.4B.3 Transporte de Dados Finalizado em Móvel em otimização de EPS de CIoT UE eNodeB MME S-GW P-GW

0. UE está ECM Ocioso 1. Dados de Enlace Descendente

2. Notificação de Dados de Enlace Descendente

2. ACK de Notificação de Dados de

3. Radiolocalização Enlace Descendente

4. Radiolocalização

5. Estabelecimento de Conexão de RRC (Solicitação de Serviço de Plano 5b. Recuperar Contexto de UE de Controle de NAS)

6. Mensagem de UE inicial de S1-AP (Solicitação de Serviço de Plano de 8. Solicitação de Modificação Controle de NAS) 7. Solicitação de Modificação de de Transportador Transportador

9. Resposta de Modificação de

10. Resposta de Modificação de Transportador Transportador

11. Dados de Enlace Descendente

12. Encriptação de Dados e proteção de integridade

13. msg de S1-AP de Enlace Descendente

14. msg de DL de RRC (NAS DATA PDU com EBI) (NAS PDU com dados)

15. Notificação de Entrega de NAS

16. msg de UL de RRC (NAS PDU com dados)

17. msg de S1-AP de UL (NAS DATA PDU com EBI)

18. Verificação de Integridade e descriptação de dados

19. Dados de Enlace Ascendente

20. Nenhuma atividade adicional detectada

21. Procedimento de liberação de S1 (consulte a cláusula 5.3.5)

de Plano de Controle com conectividade de P-GW Figura 5.3.4B.3-1: Transporte de Dados de MT em NAS PDUs

0. O UE é vinculado em EPS e em modo ECM-OCIOSO.

1. Quando o S-GW recebe uma sinalização de controle/pacote de dados de enlace descendente para um UE, caso os dados de contexto de S- GW não indiquem TEID de plano de usuário de enlace descendente para a MME), o mesmo armazena em buffer o pacote de dados de enlace descendente e identifica qual MME está servindo aquele UE. Caso aquele MME tenha solicitado ao GW Servidor para acelerar tráfego de baixa prioridade de enlace descendente e, caso o pacote de dados de enlace descendente seja recebido em um transportador de baixa prioridade para ser acelerado (consulte a cláusula 4.3.7.4.1a), o S-GW descarta os dados de enlace descendente. As etapas abaixo não são executadas. Caso aquela MME tenha solicitado ao S-GW para que atrase o envio da Notificação de Dados de Enlace Descendente (consulte a cláusula 5.3.4.2 em "Manipulação de condições anormais em Solicitação de Serviço disparada por UE"), o GW Servidor armazena em buffer os dados de enlace descendente e aguarda até que o temporizador expire antes de continuar com a etapa 2. Caso o DL-TEID e endereço MME para aquele UE sejam recebidos antes do término do temporizador, o temporizador deve ser cancelado e o procedimento de transporte de Dados Finalizados em Móvel progride da etapa 11 visto que dados de enlace descendente são enviados ao UE. Caso o GW Servidor receba sinalização de controle/ pacotes de dados de enlace descendente adicionais para esse UE antes do término do temporizador, o GW Servidor não reinicia esse temporizador.

2. Caso o GW Servidor esteja armazenando em buffer dados na etapa 1, o GW Servidor envia uma mensagem de Notificação de Dados de Enlace

Descendente (ARP, ID de Transportador de EPS) à MME para a qual o mesmo tem conectividade de plano de controle para o determinado UE.

A ARP e ID de Transportador de EPS são sempre definidos em Notificação de Dados de Enlace Descendente.

A MME responde ao S-GW com uma mensagem de Reconhecimento de Notificação de Dados de Enlace Descendente.

Uma MME detecta que o UE está em um estado de economia de energia (por exemplo, Modo de Economia de energia) e não pode ser acessado por Radiolocalização no momento de recepção de notificação de dados de Enlace Descendente, deve invocar armazenamento em buffer estendido dependendo de configuração de operador, exceto para casos descritos nos próximos parágrafos.

A MME deriva o tempo esperado para que transportadores de rádio sejam estabelecidas no UE.

A MME indica, então, Armazenamento em buffer de Enlace Descendente Solicitado ao GW Servidor na mensagem de Reconhecimento de Notificação de Dados de Enlace Descendente e inclui um tempo de Duração de Armazenamento em buffer de Enlace Descendente e, de modo opcional, uma Contagem de Pacote Sugerida por Armazenamento em buffer de Enlace Descendente.

A MME armazena um novo valor para o Tempo de Expiração de buffer de Dados de Enlace Descendente no contexto de MM para o UE com base no tempo de Duração de Armazenamento em buffer de Enlace Descendente e omite as etapas remanescentes desse procedimento.

O Tempo de Expiração de buffer de Dados de Enlace Descendente é usado Para o UEs que usam estado de economia de energia e indica que há dados armazenados em buffer no GW Servidor e que o procedimento de preparação de plano de usuário é necessário quando o UE realiza sinalização com a rede.

Quando o Tempo de Expiração de buffer de Dados de Enlace Descendente tiver expirado, a MME considera que não há Dados de enlace descendente a serem armazenados em buffer e nenhuma indicação de Dados de Enlace Descendente

Armazenados em buffer em Espera é enviada durante transferências de contexto em procedimentos de TAU.

Caso haja um evento de monitoramento de "Disponibilidade após Falha de DDN” configurado para o UE na MME, a MME não invoca armazenamento em buffer estendido.

Em vez disso, a MME define a flag Notify-on-available-after- DDN-failure para lembrar de enviar uma notificação de "Disponibilidade após Falha de DDN" quando o UE se torna disponível.

Caso haja um evento de monitoramento “Acessibilidade de UE” configurado para o UE na MME, a MME não invoca armazenamento em buffer estendido.

NOTA 1: Quando eventos de monitoramento "Disponibilidade após falha de DDN" e “acessibilidade de UE” são usados para um UE, supõe-se que o servidor de aplicação envie dados apenas quando o UE está acessível, portanto, armazenamento em buffer estendido não é necessário.

Caso haja múltiplos servidores de aplicação, as notificações de evento e armazenamento em buffer estendido podem ser necessários de modo simultâneo.

Supõe-se que isso seja manipulado através de informações adicionais com base em SLA, conforme descrito no próximo parágrafo.

A MME pode usar informações adicionais com base em um SLA com o usuário de MTC para quando invocar armazenamento em buffer estendido, por exemplo, apenas invocar o mesmo para um determinado APN, não invocar o mesmo para determinados assinantes, invocar armazenamento em buffer estendido em conjunto com eventos de monitoramento "Disponibilidade após falha de DDN" e “Acessibilidade de UE”, etc.

Um GW Servidor que recebe uma indicação de Armazenamento em buffer de Enlace Descendente Solicitado em uma mensagem de Ack de Notificação de Dados de Enlace Descendente armazena um novo valor para o Tempo de Expiração de buffer de Dados de Enlace Descendente com base no tempo de

Duração de Armazenamento em buffer de Enlace Descendente e não envia qualquer Notificação de Dados de Enlace Descendente adicional caso pacotes de dados de enlace descendente subsequentes sejam recebidos no GW Servidor antes de o tempo de buffer Tempo de Expiração de buffer de Dados de Enlace Descendente expirar para o UE.

Caso o GW Servidor, enquanto aguarda o plano de usuário ser estabelecido, seja disparado para enviar uma segunda Notificação de Dados de Enlace Descendente para um transportador com prioridade mais alta (isto é, nível de prioridade de ARP) do que aquela do transportador para a qual a primeira Notificação de Dados de Enlace Descendente foi enviada, o S-GW envia uma nova mensagem de Notificação de Dados de Enlace Descendente que indica a prioridade mais alta para a MME.

Caso o GW Servidor receba pacotes de dados de enlace descendente adicionais para um transportador com prioridade igual ou mais baixa do que aquela para qual a primeira Notificação de Dados de Enlace Descendente foi enviada, ou caso o GW Servidor tenha enviado a segunda mensagem de Notificação de Dados de Enlace Descendente que indica a prioridade mais alta e receba pacotes de dados de enlace descendente adicionais para esse UE, o GW Servidor armazena em buffer esses pacotes de dados de enlace descendente e não envia uma nova Notificação de Dados de Enlace Descendente.

Caso o GW Servidor, enquanto aguarda o plano de usuário ser estabelecido, receba uma mensagem de Solicitação de Modificação de Transportador de uma MME diferente daquela para a qual o mesmo enviou uma mensagem de Notificação de Dados de Enlace Descendente, o GW Servidor reenvia a mensagem de Notificação de Dados de Enlace Descendente, mas apenas para a nova MME da qual o mesmo recebeu a mensagem de Solicitação de Modificação de Transportador.

Mediante recepção de uma mensagem de Ack de Notificação de Dados de Enlace Descendente com uma indicação de que a mensagem de Notificação de Dados de Enlace Descendente foi temporariamente rejeitada e, caso a Notificação de Dados de Enlace Descendente seja disparada pela chegada de pacotes de dados de enlace descendente no GW Servidor, o GW Servidor pode iniciar um temporizador de guarda localmente configurado e armazenar em buffer todos os pacotes de usuário de enlace descendente recebidos no determinado UE e esperar chegar uma mensagem de Solicitação de Modificação de Transportador.

Mediante recepção de uma mensagem de Solicitação de Modificação de Transportador, o GW Servidor reenvia a mensagem de Notificação de Dados de Enlace Descendente, mas apenas para a nova MME da qual o mesmo recebeu a mensagem de Solicitação de Modificação de Transportador.

De outro modo, o GW Servidor libera pacotes de usuário de enlace descendente armazenados em buffer mediante expiração do temporizador de guarda ou mediante recepção da mensagem de Solicitação de Exclusão de Sessão de MME.

Caso a S11-U já esteja estabelecida (armazenamento em buffer está na MME), a etapa 2 não é executada e a etapa 11 é imediatamente executada.

As etapas 7, 8, 9 e 10 são executadas apenas se condições forem satisfeitas quando a solicitação de serviço de plano de controle de NAS é recebida na etapa 6, conforme mencionado abaixo nas respectivas cláusulas.

Uma MME que detecta que o UE está em um estado de economia de energia (por exemplo, Modo de Economia de Energia) e não pode ser acessado por Radiolocalização no momento de recepção de Dados de Enlace Descendente, deve iniciar armazenamento em buffer estendido dependendo de configuração de operador, exceto para casos descritos nos parágrafos seguintes.

A MME deriva o tempo esperado para que transportadores de rádio sejam estabelecidas no UE, armazena um novo valor para o Tempo de Expiração de buffer de Dados de Enlace Descendente no contexto de MM para o UE e pula as etapas remanescentes desse procedimento. Quando o Tempo de Expiração de buffer de Dados de Enlace Descendente tiver expirado, a MME não considera dados de enlace descendente para serem armazenados em buffer. Também para o caso de armazenamento em buffer na MME, o evento de monitoramento "Disponibilidade após Falha de DDN” pode ser configurado para o UE, embora a DDN real não seja recebida e os dados de enlace descendente sejam recebidos. O evento de monitoramento “Acessibilidade de UE” também pode ser configurado. O armazenamento em buffer estendido também pode ser configurado conforme descrito acima nessa etapa do procedimento para o caso de armazenamento em buffer em S-GW.

3. Caso o UE seja registrado na MME e considerado acessível, a MME envia uma mensagem de Radiolocalização (NAS ID para Radiolocalização, TAI(s), índice de DRX com base em identidade de UE, comprimento de DRX de Radiolocalização, lista de CSG IDs para Radiolocalização, indicação de Prioridade de Radiolocalização) para cada eNodeB que pertence à área(s) de rastreamento em que o UE é registrado. A indicação de prioridade de Radiolocalização é incluída apenas: - Caso a MME receba uma Notificação de Dados de Enlace Descendente (ou um Pacote de enlace descendente para um transportador de EPS, para o caso de armazenamento em buffer em MME) com um nível de prioridade de ARP associado a serviços de prioridade, conforme configurado pelo operador. - Um nível de Prioridade de Radiolocalização pode ser usado para múltiplos valores de nível de prioridade de ARP. O mapeamento de valores de nível de prioridade de ARP para nível (ou níveis) de Prioridade de Radiolocalização é configurado por política de operador.

Durante uma situação de congestionamento, o eNodeB pode priorizar a radiolocalização de UEs, de acordo com as indicações de Prioridade de Radiolocalização.

Caso a MME, enquanto espera por uma resposta de UE para a mensagem de Solicitação de Radiolocalização enviada sem indicação de Prioridade de Radiolocalização, receba uma Notificação de Dados de Enlace Descendente (ou um pacote de enlace descendente para um transportador de EPS, para o caso de armazenamento em buffer em MME) que indica um nível de prioridade de ARP associado a serviços de prioridade, conforme configurado pelo operador, a MME deve enviar outra mensagem de radiolocalização com a Prioridade de Radiolocalização adequada.

Quando a MME é configurada para suportar otimização de radiolocalização de CSG na CN, a MME deve evitar o envio de mensagens de Radiolocalização para aqueles eNodeB(s) com células de CSG para as quais o UE não tem uma assinatura de CSG.

Quando a MME é configurada para suportar otimização de radiolocalização de CSG no Subsistema de HeNB, a lista de CSG IDs para radiolocalização é incluída na mensagem de Radiolocalização.

Para otimização de radiolocalização de CSG, os CSG IDs de assinaturas de CSG expiradas e assinaturas de CSG válidas são, ambos, incluídos na lista.

Caso o UE tenha serviço de transportador de emergência, a MME não deve realizar a otimização de radiolocalização de CSG.

NOTA 2: Uma assinatura de CSG expirada indica que o UE não é permitido serviço no CSG.

Entretanto, visto que a remoção do CSG do UE está pendente, é possível que o UE acampe naquele CSG e, portanto, o UE ainda está radiolocalizado para o CSG.

NOTA 3: O eNodeB relata à MME o CSG ID suportado.

Para mais detalhes desse procedimento, consulte TS 36.413 [36].

As estratégias de radiolocalização podem ser configuradas na MME.

As estratégias de radiolocalização podem incluir: - esquema de retransmissão de radiolocalização (por exemplo, com que frequência a radiolocalização é repetida ou com que intervalo de tempo); - determinar o envio da mensagem de Radiolocalização para os eNodeBs durante determinadas condições de carga alta de MME; - a possibilidade de aplicar radiolocalização com base em subárea (por exemplo, primeiro radiolocalizar no último ECGI conhecido ou TA e retransmissão em todas as TAs registradas). NOTA 4: A prioridade de Radiolocalização na mensagem de Radiolocalização é definida com base em nível de prioridade do IE de ARP recebido em mensagem de Notificação de Dados de Enlace Descendente ou de Solicitação de Criação/Atualização de Transportador e é independente de qualquer estratégia de radiolocalização.

A MME e a E-UTRAN podem suportar otimizações de radiolocalização adicionais a fim de reduzir a carga de sinalização e os recursos de rede usados para radiolocalizar, de maneira bem-sucedida, um UE por meio de um ou diversos dos seguintes meios: - pela MME que implanta estratégias de radiolocalização específicas (por exemplo, a mensagem de Radiolocalização de S1 é enviada ao eNB que serviu o UE por último); - pela MME que considera Informações Sobre Células Recomendadas E eNodeBs fornecidas pela E-UTRAN na transição para ECM OCIOSO.

A MME considera a parte relacionada ao eNB dessas informações para determinar os eNBs a serem radiolocalizados, e fornece as informações sobre células recomendadas dentro da mensagem de Radiolocalização de S1 para cada um desses eNBs;

- pela E-UTRAN que considera as Informações de Contagem de Tentativas de Radiolocalização fornecidas pela MME em radiolocalização. Ao implantar tais otimizações/estratégias, a MME deve considerar qualquer temporizador ativo de PSM e o intervalo de DRX para o UE. Caso a Capacidade de Rádio de UE para Informações de Radiolocalização esteja disponível na MME, a MME adiciona a Capacidade de Rádio de UE para Informações de Radiolocalização na mensagem de Radiolocalização de S1 ao eNB. Caso as Informações Sobre Células Recomendadas E ENBs Para Radiolocalização estejam disponíveis na MME, a MME deve considerar essas informações para determinar os eNBs para radiolocalização e, ao radiolocalizar um eNB, a MME pode transportar, de modo transparente, as informações sobre células recomendadas ao eNB. A MME pode incluir, na mensagem(s) de Radiolocalização de S1AP, as informações de contagem de tentativa de radiolocalização. As informações de contagem de tentativa de radiolocalização devem ser iguais para todos os eNBs selecionados pela MME para radiolocalização. Caso a MME tenha Informações para Cobertura Aprimorada armazenada e Cobertura Aprimorada não seja restrita, então, a MME deve incluir Informações para Cobertura Aprimorada na mensagem de Radiolocalização para todos os eNBs selecionados pela MME para radiolocalização.

4. Caso eNodeBs recebam mensagens de radiolocalização da MME, o UE é radiolocalizado pelos eNodeBs.

5. Visto que o UE está no estado ECM-OCIOSO, mediante recepção de indicação de radiolocalização, o UE envia mensagem de NAS de Solicitação de Serviço de Plano de Controle (conforme definido em TS 24.301 [46]) através de solicitação de Conexão de RRC e mensagem inicial de S1-AP. O eNodeB indica,

no UE Inicial de S1-AP, se o eNodeB suporta reconhecimentos para PDUs de dados de NAS de enlace descendente. A mensagem de NAS de Solicitação de Serviço de Plano de Controle, quando otimização de Plano de Controle de C-IoT se aplica, não dispara estabelecimento de transportador de rádio de dados pela MME e a MME pode enviar, imediatamente, Dados de Enlace Descendente que a mesma recebe com o uso de uma NAS PDU ao eNodeB. A MME supervisiona o procedimento de radiolocalização com um temporizador. Caso a MME não receba resposta do UE para a mensagem de Solicitação de Radiolocalização, a mesma pode repetir a radiolocalização de acordo com qualquer estratégia de radiolocalização aplicável descrita na etapa 3. 5b. No caso de NB-IoT, o eNB, com base em configuração, pode recuperar o perfil de QoS negociado por EPS da MME, caso não seja previamente recuperado. O Código de MME dentro da S-TMSI na mensagem RRCConnectionRequest é usado para identificar a MME. O eNB pode aplicar priorização entre solicitações de diferentes UEs antes de disparar a etapa 6 e ao longo da conexão de RRC. O eNB pode recuperar parâmetros adicionais (por exemplo, Capacidades de Rádio de UE - consulte TS 36.413 [36]).

6. Caso a MME não receba resposta do UE após esse procedimento de repetição de radiolocalização, a mesma deve usar a mensagem de Rejeição de Notificação de Dados de Enlace Descendente para notificar o GW Servidor sobre a falha de radiolocalização (ou, de modo equivalente, caso o armazenamento em buffer esteja na MME, a MME simplesmente descarta dados para o UE localmente), a menos que a MME esteja ciente de um procedimento de MM em andamento que impede que o UE responda, isto é, a MME recebeu uma mensagem de Solicitação de Contexto que indica que o UE realiza TAU com outra MME. Quando uma mensagem de Rejeição de Notificação de Dados de Enlace Descendente é recebida, o GW Servidor exclui o pacote(s) armazenado em buffer. O GW Servidor pode invocar o procedimento Pausa de PGW de Carregamento (cláusula 5.3.6A) caso UE esteja em ECM OCIOSO e o PDN GW tenha habilitado recurso de "pausa de carregamento de PDN". Caso armazenamento em buffer esteja na MME, Pausa de Carregamento é disparada pela MME por meio de uma Solicitação de Liberação de Transportador de Acesso ao S-GW (não mostrada na Figura 5.3.4B.3-1) que inclui uma causa de "Liberação Anormal de Enlace de Rádio", que libera a S11-U. NOTA 5: O GW Servidor (ou MME, no caso de armazenamento em buffer na MME) pode iniciar o procedimento Pausa de P-GW de Carregamento a qualquer momento antes da etapa 5, caso o UE esteja em ECM OCIOSO e o P- GW tenha indicado que o recurso é habilitado para essa PDN. Consulte a cláusula 5.3.6A.0. Para auxiliar Serviços de Localização, o eNB indica o Nível de Cobertura de UE à MME. A MME realiza (e o UE responde) quaisquer procedimentos de EMM ou ESM, caso necessário, por exemplo, os procedimentos relacionados à segurança. As etapas 7 a 11 podem continuar paralelamente a isso, entretanto, as etapas 12 e 13 devem aguardar conclusão de todos os procedimentos de EMM e ESM.

7. Caso a S11-U não seja estabelecida, a MME envia uma mensagem de Solicitação de Modificação de Transportador (endereço de MME, MME TEID DL, Solicitação de Notificação de Pacote de Enlace Descendente de Atraso, Tipo de RAT) para cada conexão PDN ao GW Servidor. O GW Servidor agora tem a capacidade de transmitir dados de enlace descendente para o UE. O uso do Elemento de Informações de Solicitação de Notificação de Pacote de Enlace Descendente de Atraso é especificado na cláusula 5.3.4.2 com referência ao procedimento de solicitação de serviço iniciado por UE, mas se aplica igualmente nesse caso. A MME deve indicar tunelamento de S11-U de dados de usuário de

NAS e enviar seu próprio endereço de S11-U IP e MME DL TEID para dados de DL encaminhados pelo SGW. Além disso, independentemente de a S11-U já estar estabelecida: - Caso a localização de UE e/ou informações de CSG de Usuário solicitadas por P-GW e a localização de UE e/ou informações de CSG de usuário tenham mudado, a MME deve enviar a mensagem de Solicitação de Modificação de Transportador e também incluir o IE de Informações de Localização de Usuário e/ou IE de Informações de CSG de Usuário nessa mensagem. - Caso o IE de Rede Servidora tenha mudado quando comparado ao IE de Rede Servidora relatado por último, então, a MME deve enviar a mensagem de Solicitação de Modificação de Transportador e também incluir o IE de Rede Servidora nessa mensagem. - Caso o Fuso Horário de UE tenha mudado quando comparado ao Fuso Horário de UE relatado por último, então, a MME deve enviar a mensagem de Solicitação de Modificação de Transportador e incluir o IE de Fuso Horário de UE nessa mensagem. Caso a RAT atualmente usada seja NB-IOT, isso deve ser relatado como diferente de outros tipos de E-UTRA.

8. Caso o Tipo de RAT tenha mudado quando comparado ao Tipo de RAT relatado por último ou caso a Localização de UE e/ou IEs de Info e/ou Fuso Horário de UE e id de Rede Servidora estejam presentes na etapa 7, o GW Servidor deve enviar a mensagem de Solicitação de Modificação de Transportador (Tipo de RAT) ao P-GW. IE de Informações de Localização de Usuário e/ou IE de Informações de CSG de Usuário e/ou IE de Rede Servidora e/ou Fuso Horário de UE também são incluídos, caso os mesmos estejam presentes na etapa 7. Caso a mensagem de Solicitação de Modificação de Transportador não seja enviada devido às razões acima e o carregamento de PDN GW esteja em pausa, então, o S-GW deve enviar uma mensagem de Solicitação de Modificação de Transportador com Indicação de Interrupção de Pausa de Carregamento de PDN para informar o PDN GW de que o carregamento não está mais em pausa. Outros IEs não estão incluídos nesta mensagem.

9. O PDN GW envia a Resposta de modificação de transportador ao GW Servidor.

10. Caso uma mensagem de Solicitação de Modificação de Transportador tenha sido enviada na etapa 7, o GW Servidor deve retornar uma Resposta de modificação de transportador (endereço de GW Servidor e TEID para tráfego de enlace ascendente) à MME como uma resposta a uma mensagem de Solicitação de Modificação de Transportador. O endereço de GW Servidor para Plano de Usuário de S11-U e TEID de GW Servidor são usados pela MME para encaminhar dados de UL ao SGW.

11. Os dados de Enlace Descendente Armazenados em buffer (caso S11-U não seja estabelecida) são enviados pelo S-GW à MME. 12 a 13. A MME criptografa e protege a integridade de dados de enlace descendente e envia os mesmos ao eNodeB com o uso de uma NAS PDU portada por uma mensagem de S1-AP de Enlace Descendente. Caso o eNodeB suporte reconhecimentos de PDUs de dados de NAS de enlace descendente e, caso reconhecimentos de PDUs de dados de NAS de enlace descendente sejam habilitadas nas informações de assinatura para o UE, a MME indica, na mensagem de S1-AP de enlace descendente, que Reconhecimento é solicitada pelo eNodeB. Para conexões de PDN do tipo IP PDN configuradas para suportar Compressão de Cabeçalho, a MME deve aplicar compressão de cabeçalho antes de encapsular dados na mensagem de NAS. Alternativamente e, caso a MME decida que transportadores S1-U precisam ser estabelecidos no caso de o UE e

MME aceitarem Otimização de EPS de Plano de Usuário ou transferência de dados de S1-U, as etapas 4 a 12 da cláusula 5.3.4.1 são sucedidas. Caso o UE esteja acessando por meio de uma célula de NB-IoT, ou caso esteja acessando por meio de uma célula de WB-E-UTRAN e tenha a capacidade de modo de CE B, para determinar a estratégia de retransmissão de NAS PDU, a MME deve considerar o atraso de transmissão da NAS PDU e, quando aplicável, o modo de CE, isto é, definir os temporizadores de NAS com tempo longo o suficiente de acordo com o pior atraso de transmissão (consulte TS 24.301 [46]).

14. A NAS PDU com dados é entregue ao UE por meio de uma mensagem de RRC de Enlace Descendente. Isso é considerado pelo UE como Reconhecimento implícita da mensagem de Solicitação de Serviço enviada na etapa 5. Caso compressão de cabeçalho tenha sido aplicada à PDN, o UE deve realizar descompressão de cabeçalho para reconstruir o cabeçalho de IP.

15. O eNodeB envia uma indicação de Entrega de NAS para a MME, caso solicitado. Caso o eNodeB relate uma entrega malsucedida com uma Indicação de Não Entrega de S1-AP NAS, a MME deve aguardar algum tempo até que o UE tenha potencialmente mudado de célula e restabelecido contato com a MME, por meio do qual a MME deve reenviar a mensagem de S1-AP de enlace descendente ao eNodeB, de outro modo, a MME relata uma entrega malsucedida à SCEF no caso de procedimento de T6a (consulte TS 23.682 [74], cláusula 5.13.3). Caso o eNodeB relate uma entrega bem-sucedida com uma Indicação de Entrega de S1-AP NAS e, caso os dados de enlace descendente sejam recebidos pela interface T6a, a MME deve responder à SCEF (consulte TS 23.682 [74], cláusula 5.13.3). Caso o eNodeB não suporte indicações de entrega de S1-AP NAS, a MME indica um código de causa “Entrega Não Reconhecida Bem-sucedida” à SCEF, de outro modo, “Entrega Reconhecida Bem- sucedida”, para que a SCEF saiba se entrega confiável foi ou não possível.

16. Enquanto a conexão de RRC ainda estiver ativa, dados de Enlace Ascendente e de Enlace Descendente adicionais podem ser transferidos com o uso de NAS PDUs. Na etapa 17, uma transferência de dados de enlace ascendente é mostrada com o uso de uma mensagem de RRC de enlace ascendente que encapsula uma NAS PDU com dados. A qualquer momento que o UE não tenha transportadores de plano de usuário estabelecidos, o UE pode fornecer Informações de Auxílio à Liberação com dados de enlace ascendente na NAS PDU. Para conexões de PDN do tipo IP PDN configuradas para suportar Compressão de Cabeçalho, o UE deve aplicar compressão de cabeçalho antes de encapsular dados na mensagem de NAS.

17. A NAS PDU com dados é enviada à MME em uma mensagem de S1- AP de enlace ascendente. Para auxiliar Serviços de Localização, o eNB pode indicar, caso tenha mudado, o Nível de Cobertura de UE à MME.

18. Os dados têm a integridade verificada e são descriptografados. Caso a compressão de cabeçalho tenha sido aplicada à PDN, a MME deve realizar descompressão de cabeçalho para reconstruir o cabeçalho de IP.

19. A MME envia dados de enlace ascendente ao PGW por meio do S- GW e executa qualquer ação relacionada à presença de Informações de Auxílio à Liberação da seguinte forma: - para o caso em que as informações de auxílio à liberação indicarem que não há dados de enlace descendente para seguir os dados de enlace ascendente, então, a menos que a MME esteja ciente de tráfego de MT pendente e, a menos que transportadores de S1-U existam, a MME libera, imediatamente a conexão e, portanto, a etapa 21 é executada. - para o caso em que as informações de auxílio à liberação indicarem que dados de enlace descendente seguirão a transmissão de enlace ascendente, então, a menos que a MME esteja ciente de tráfego de MT pendente adicional e, a menos que transportadores de S1-U existam, a MME envia um Comando de Liberação de Contexto de S1 UE ao eNodeB imediatamente após a mensagem de S1-AP que inclui os dados de enlace descendente encapsulados em NAS PDU.

20. Caso não exista nenhuma atividade de NAS durante um tempo, o eNB detecta inatividade e executa a etapa 21.

21. O eNB inicia um procedimento de liberação de S1 iniciado por eNodeB, de acordo com a cláusula 5.3.5 ou Procedimento de Suspensão de Conexão definido na cláusula 5.3.4A.

5.3.9.2 Procedimento de Inserção de Dados de Assinante O procedimento de Inserção de Dados de Assinante é ilustrado na Figura 5.3.9.2-1.

MME HSS

1. Inserção de Dados de Assinante

2. Ack de Inserção de Dados de Asssintante Figura 5.3.9.2-1: Procedimento de Inserção de Dados de Assinante

1. O HSS envia uma mensagem de Inserção de Dados de Assinante (IMSI, Dados de Assinatura) à MME.

2. A MME atualiza os Dados de Assinatura armazenados e reconhece a mensagem de Inserção de Dados de Assinante retornando-se uma mensagem de Reconhecimento de Inserção de Dados de Assinante (IMSI) ao HSS. O resultado de atualização deve estar contido na mensagem de Ack. A MME inicia ação apropriada de acordo com os dados de assinante alterados (por exemplo, MME inicia desvinculação caso o UE não tenha permissão para roam nessa rede). Para contextos de assinatura de PDN recebidos que não têm conexão PDN ativa relacionada na MME, nenhuma ação adicional é necessária exceto armazenamento na MME. De outro modo, caso o Perfil de QoS assinada tenha sido modificado e o UE esteja em estado ECM- CONECTADO ou em estado ECM-OCIOSO quando ISR não está ativada, mas o UE é acessível pela MME, o procedimento de Modificação de QoS Assinada Iniciado por HSS, conforme descrito na Figura 5.4.2.2-1, é invocado da etapa 2a. Quando ISR não está ativada e o UE está em estado ECM OCIOSO e não é acessível pela MME, por exemplo, quando o UE está suspenso, quando o UE tiver entrado no modo de economia de energia ou quando a PPF é removida na MME, o procedimento de Modificação de QoS Assinada Iniciado por HSS, conforme descrito na Figura 5.4.2.2-1, é invocado da etapa 2a na próxima transição de ECM OCIOSO para ECM CONECTADO. Caso o UE esteja em estado ECM-OCIOSO e a ISR esteja ativada, esse procedimento é invocado na próxima transição de ECM- OCIOSO para ECM-CONECTADO. Caso o UE esteja em estado ECM-OCIOSO e a ISR não esteja ativada e, caso a mudança de assinatura não permita mais a conexão PDN, o procedimento de desconexão de PDN iniciado por MME, na cláusula 5.10.3, é usado para excluir a conexão PDN em questão. Caso o UE esteja em estado ECM-CONECTADO e conectado por meio de um CSG ou célula híbrida, a MME deve verificar os Dados de Assinatura de CSG recebidos. Caso a MME detecte que o membro de CSG para aquela célula mudou ou expirou, a MME inicia o procedimento na cláusula 5.16. Caso a MME tenha recebido um parâmetro de Gap de Serviço alterado nos dados de assinatura atualizados, a MME deve fornecer o novo valor de Gap de Serviço ao UE em uma mensagem de Aceitação de Atualização de Área de Rastreamento em 24 horas ou a MME deve iniciar uma desvinculação com revinculação exigida do UE.

5.10.2 Conectividade de PDN solicitada por UE

O procedimento de conectividade de PDN solicitado por UE para uma E- UTRAN é retratado na Figura 5.10.2-1. O procedimento permite que o UE solicite conectividade a uma PDN adicional pela E-UTRAN que inclui alocação de um transportador padrão, caso o UE já tenha conexões de PDN ativas pela E-UTRAN.

Esse procedimento também pode ser usado quando um UE tiver definido "Vinculação sem Conectividade de PDN é suportada" no comportamento de Rede Preferencial no momento de vinculação e a rede tiver Reconhecido seu suporte ao UE.

Caso afirmativo, o UE pode permanecer vinculado sem uma conexão PDN padrão e, a qualquer momento, solicitar que uma conexão PDN seja estabelecida.

Esse procedimento também é usado para solicitar conectividade a uma PDN adicional pela E-UTRAN, caso o UE seja conectado simultaneamente à E-UTRAN e a um acesso não 3GPP e o UE já tenha conexões de PDN ativas através de ambos os acessos.

O procedimento de conectividade de PDN pode disparar um ou múltiplos procedimentos de Estabelecimento de Transportador dedicado para estabelecer transportador(es) de EPS dedicado para aquele UE.

Caso o UE tenha um temporizador de Gap de Serviço sendo executado e a Solicitação de Conectividade de PDN não seja uma resposta a uma radiolocalização de MT, o UE não deve iniciar esse procedimento (consulte a cláusula 4.3.x acima). Um UE vinculado como emergência não deve iniciar qualquer procedimento de Solicitação de Conectividade de PDN.

Um UE vinculado de maneira normal deve solicitar uma conexão PDN para serviços de emergência quando Serviço de Emergência for necessário e uma conexão PDN de emergência ainda não estiver ativa.

UE eNodeB MME GW Servidor PDN GW PCRF HSS

1. Solicitação de Conectividade de PDN

2. Solicitação de Criação de Sessão

3. Solicitação de Criação de Sessão (A)

4. Modificação/Estabelecimento de Sessão de IP-CAN

5. Resposta de Criação de Sessão Primeiros Dados de Enlace Descendente

6. Resposta de Criação de Sessão

7. Solicitação de Preparação de Transportador ou Transporte de NAS de Enlace Descendente com Aceitação de Conectividade de PDN

8. Reconfiguração de Conexão de RRC ou Transferência Direta de RRC

9. Conclusão de Reconfiguração de Conexão de RRC

10. Resposta de Preparação de Transportador

11. Transferência Direta

12. Conclusão de Conectividade de PDN Primeiros Dados de Enlace Ascendente

13. Solicitação de Modificação de Transportador 13 .a Solicitação de Modificação de Transportador (B)

13.b Resposta de Modificação de Transportador

14. Resposta de Modificação de Transportador Primeiros Dados de Enlace Descendente

15. Solicitação de Notificação

16. Resposta de Notificação Figura 5.10.2-1: Conectividade de PDN solicitada por UE NOTA 1: Para um S5/S8 com base em PMIP, as etapas de procedimento (A) são definidas em TS 23.402 [2]. As etapas 3, 4, 5 e 13a/b se referem a S5/S8 com base em GTP. NOTA 2: O UE também usa esse procedimento para solicitar restabelecimento de conectividade de PDN existente mediante handover de acessos não 3GPP. NOTA 3: As etapas em (B) são executadas apenas mediante handover de acesso não 3GPP ou, caso Informações de Área de Relatório de Presença sejam recebidas da MME.

NOTA 4: Ao usar a Otimização de CIoT EPS de Plano de Controle, as etapas 7 e 8 são modificadas e 9 e 10 são puladas.

1. O UE inicia o procedimento de PDN Solicitado por UE pela transmissão de uma mensagem de Solicitação de Conectividade de PDN (APN, Tipo de PDN, Opções de Configuração de Protocolo, Tipo de Solicitação, Configuração de Compressão de Cabeçalho). Caso o UE esteja no modo ECM- OCIOSO, essa mensagem de NAS é precedida pelo procedimento de Solicitação de Serviço caso qualquer uma dentre as conexões de PDN existentes esteja usando o Plano de Usuário sem otimização de EPS C-IoT ou, caso o plano de usuário seja usado apenas com otimizações de C-IoT de plano de usuário, em vez disso, um Procedimento de Retomada de Conexão é executado. O tipo de PDN indica a versão de IP solicitada (IPv4, IPv4v6, IPv6, Não IP). A MME verifica que o APN fornecido por UE é permitido por assinatura. Caso o UE não tenha fornecido um APN, a MME deve usar o APN do contexto de assinatura de PDN padrão, e, usar esse APN para o restante desse procedimento. As Opções de Configuração de Protocolo (PCO) são usadas para transferir parâmetros entre o UE e a Rede e são enviadas, de modo transparente, através da MME e do GW Servidor. As Opções de Configuração de Protocolo podem incluir a Preferência de Alocação de Endereço que indica que o UE prefere obter um endereço de IPv4 somente após a ativação de transportador padrão por meio de DHCPv4. Caso o UE tenha capacidades UTRAN ou GERAN, o mesmo deve enviar a NRSU nas PCO para indicar o suporte do controle de transportador solicitado por rede em UTRAN/GERAN. O UE envia o ETFTU nas PCO para indicar o suporte do formato de filtro de TFT estendido. O Tipo de Solicitação indica "solicitação inicial" caso o UE solicite nova conectividade de PDN adicional através da rede de acesso 3GPP para múltiplas conexões de PDN, o Tipo de Solicitação indica "handover" quando o UE está realizando um handover de acesso não 3GPP e o UE já tiver estabelecido conectividade com o PDN através do acesso não 3GPP. O UE deve indicar Tipo de Solicitação "Emergência" quando o mesmo solicita uma conexão PDN para serviços de emergência. Caso a mensagem esteja sendo enviada por meio de um HeNB que tem um L-GW justaposto, a mesma inclui o endereço de L-GW na mensagem de transporte de NAS de enlace ascendente para a MME. Caso um UE tenha indicado otimização de CIoT EPS de Plano de Controle suportada em Comportamento de Rede Preferencial e suporte compressão de cabeçalho, o mesmo deve incluir a Configuração de Compressão de Cabeçalho, a menos que tipo de PDN "Não IP" seja indicado. A Configuração de Compressão de Cabeçalho inclui as informações necessárias para a preparação de canal de ROHC. De modo opcional, a Configuração de Compressão de Cabeçalho também pode incluir parâmetros de preparação de contexto de compressão de cabeçalho adicionais, caso o UE já tenha as informações de tráfego de aplicação, por exemplo, o endereço de IP de servidor de destino. O UE deve incluir nas PCO o Status de UE de Desligamento de Dados PS de 3GPP, que indica se o usuário ativou ou desativou Desligamento de Dados PS de 3GPP.

2. Caso haja um temporizador de Gap de Serviço sendo executado no Contexto de MME MM para o UE e a MME não esteja esperando uma resposta de radiolocalização de MT do UE, a MME rejeita a Solicitação de Conectividade de PDN com uma causa apropriada e com um Temporizador de Backoff de Gerenciamento de Mobilidade definido para o tempo de Gap de Serviço remanescente. Caso a MME receba uma Solicitação de Conectividade de PDN de um UE vinculado como emergência ou a Solicitação de Conectividade de PDN seja para serviços normais e as restrições de acesso ou mobilidade não permitam que o

UE acesse serviços normais, a MME deve rejeitar essa solicitação.

Caso o Tipo de Solicitação indique "Emergência" e a MME não seja configurada para suportar conexões de PDN para serviços de emergência, a MME deve rejeitar a Solicitação de Conectividade de PDN com uma causa de rejeição apropriada.

Caso o Tipo de Solicitação não seja definido para "Emergência", e o UE tenha indicado suporte para Vinculação sem Conectividade de PDN, e a rede suporte Vinculação sem Conectividade de PDN, e a Restrição de Conexão PDN seja definida nos dados de assinante, então, a MME deve rejeitar a Solicitação de Conectividade de PDN com um valor de causa apropriado.

Caso o Tipo de Solicitação indique "Emergência", a MME deriva um PDN GW dos Dados de Configuração de Emergência de MME ou a MME seleciona um PDN GW conforme descrito na cláusula 4.3.12.4 em Função de Seleção de PDN GW (acessos 3GPP) de acordo com o APN de Emergência nos Dados de Configuração de Emergência de MME.

Essa seleção deve fornecer um PDN GW de PLMN visitada apenas.

Caso o Tipo de Solicitação indique "Emergência" e a MME seja configurada para suportar conexões de PDN para serviços de emergência, a mesma usa os Dados de Configuração de Emergência de MME para o estabelecimento de transportador nessa etapa e ignora qualquer limitação de dados de assinatura.

Caso o Tipo de Solicitação indique "Handover", a MME usa o PDN GW armazenado nos Dados de Assinatura recuperados pela MME durante a Atualização de Localização realizada na vinculação.

Caso o Tipo de Solicitação indique "solicitação inicial", a MME seleciona um PDN GW, conforme descrito na cláusula 4.3.8.1 em Função de Seleção de PDN GW (acessos 3GPP). Caso o APN fornecido por UE seja autorizado para LIPA de acordo com a assinatura de usuário, a MME deve usar os Dados de Assinatura de CSG para autorizar a conexão.

Caso o contexto de assinatura não indique que o APN é para uma conexão PDN com uma SCEF, a MME aloca um Id de Transportador, e envia uma mensagem de Criação de Solicitação de Sessão (IMSI, MSISDN, MME TEID para plano de controle, tipo de RAT, endereço de PDN GW, Endereço de PDN, QoS de Transportador de EPS Padrão, Tipo de PDN, APN-AMBR assinada, APN, Id de Transportador de EPS, Opções de Configuração de Protocolo, Indicação de Handover, Identidade de ME, Informações de Localização de Usuário (ECGI), Fuso Horário de UE, Informações de CSG de Usuário, indicação de suporte de Relatório de Mudança de Info de MS, Modo de Seleção, Características de Carregamento, Referência de Rastreio, Tipo de Rastreio, Id de Disparo, Identidade de OMC, Restrição Máxima de APN, Flag de Transportador de Endereço Duplo) ao GW Servidor.

Caso Otimização de CIoT EPS de Plano de Controle se aplique, então, a MME também deve indicar tunelamento de S11-U de dados de usuário de NAS e enviar seu próprio endereço de S11-U IP e MME DL TEID para dados de DL encaminhados pelo SGW.

Caso a MME determine que a conexão PDN deve usar apenas a Otimização de CIoT EPS de Plano de Controle, a MME deve incluir um Indicador de Conexão PDN Apenas de Plano de Controle em Solicitação de Criação de Sessão.

Para tipo de PDN "não IP", caso os dados de assinatura de APN indiquem que uma conexão de SCEF precisa ser usada, então, a MME aloca uma Identidade de Transportador de EPS para o transportador padrão associado ao UE e estabelece conexão com o endereço de SCEF indicado em dados de assinatura, de acordo com TS 23.682 [74] e as etapas 2, 3, 4, 5 e 6 não são executadas.

O restante das interações com o UE se aplica, conforme especificado abaixo.

O tipo de RAT é fornecido nessa mensagem para a decisão de PCC posterior.

O tipo de RAT deve habilitar NB-IoT e WB-E-UTRAN para ser diferenciado pelo

PDN-GW.

A MSISDN é incluída caso a MME tenha a mesma armazenada para aquele UE.

A Indicação de Handover é incluída caso o Tipo de Solicitação indique “handover”. O Modo de Seleção indica se um APN assinado foi selecionado, ou se um APN não assinado enviado pelo UE foi selecionado.

O P-GW pode usar Modo de Seleção ao decidir aceitar ou rejeitar a ativação de transportador padrão.

Por exemplo, caso um APN exija assinatura, o P-GW é configurado para aceitar apenas a ativação de transportador padrão que solicita um APN assinado, conforme indicado por Modo de Seleção.

As características de carregamento para a assinatura PS e APNs individualmente assinados bem como o modo de manipular Características de Carregamento e a possibilidade de enviar ou não os mesmos para o P-GW são definidos em TS 32.251 [44]. A MME deve incluir Referência de Rastreio, Tipo de Rastreio, Id de Disparo e Identidade de OMC, caso o rastreio de S-GW e/ou P-GW seja ativado.

Caso o contexto de assinatura de PDN contenha um endereço de IPv4 e/ou prefixo de IPv6 assinado, a MME indica isso no endereço de PDN. A MME pode mudar o tipo de PDN solicitado de acordo com os dados de assinatura para esse APN, conforme descrito na cláusula 5.3.1.1. A MME deve definir a flag de Transportador de Endereço Duplo quando o tipo de PDN é definido para IPv4v6 e todos os SGSNs para os quais o UE pode ser submetido a handover são Versão 8 ou acima que suporta endereçamento duplo, que é determinado com base em pré-configuração de nó pelo operador.

3. O GW Servidor cria uma nova entrada em sua tabela de Transportador de EPS e envia uma mensagem de Solicitação de Criação de Sessão (IMSI, MSISDN, Endereço de GW Servidor para o plano de usuário, TEID de GW Servidor do plano de usuário, TEID de GW Servidor do plano de controle, tipo de RAT, QoS de Transportador de EPS Padrão, Tipo de PDN, Endereço de PDN, APN-AMBR assinada, APN, Id de Transportador, Opções de Configuração de Protocolo, Indicação de Handover, Identidade de ME, Informações de Localização de Usuário (ECGI), Fuso Horário de UE, Informações de CSG de Usuário, indicação de suporte de Relatório de Mudança de Info de MS, indicação de Suporte de Pausa de Carregamento de PDN, Modo de Seleção, Características de Carregamento, Referência de Rastreio, Tipo de Rastreio, Id de Disparo, Identidade de OMC, Restrição Máxima de APN, Flag de Transportador de Endereço Duplo) ao PDN GW indicado no endereço de PDN GW recebido na etapa anterior. Após essa etapa, o GW Servidor armazena em buffer quaisquer pacotes de enlace descendente que possa receber do PDN GW até receber a mensagem na etapa 13 abaixo. A MSISDN é incluída, caso recebida da MME. Caso a Indicação de Handover seja incluída, o GW Servidor inclui a mesma na mensagem de Solicitação de Criação de Sessão. Caso o GW Servidor tenha recebido o Indicador de Conexão PDN Apenas de Plano de Controle, na etapa 2, o GW Servidor informa o PGW dessas informações na Solicitação de Criação de Sessão. O GW Servidor e PDN GW devem indicar o uso de CP apenas em seus CDRs. P-GWs não devem realizar quaisquer verificações de Restrição Máxima de APN caso a Solicitação de Criação de Transportador Padrão inclua APN de emergência. Caso o PGW detecte que o Status de UE de Desligamento de Dados PS de 3GPP mudou, o PGW deve indicar esse evento ao sistema de carregamento para carregamento offline e online.

4. Caso PCC dinâmico seja implementado e a Indicação de Handover não esteja presente, o PDN GW pode empregar um procedimento de Estabelecimento de Sessão de IP-CAN, conforme definido em TS 23.203 [6] com a PCRF para obter as regras de PCC padrão para o UE. Isso pode levar ao estabelecimento de um número de transportadores dedicados seguindo os procedimentos definidos na cláusula 5.4.1 em associação ao estabelecimento do transportador padrão, que é descrito no Anexo F. O tipo de RAT é fornecido à PCRF pelo PDN GW, caso recebido pela mensagem anterior. Caso o PDN GW/PCEF seja configurado para ativar regras de PCC predefinidas para o transportador padrão, a interação com a PCRF não é necessária (por exemplo, operador pode configurar para fazer isso) no momento. O ETFTU é fornecido à PCRF pelo PDN GW, caso recebido na PCO do UE e o PDN GW suporta o formato de filtro de TFT estendido. Caso a PCRF decida que a conexão PDN pode usar filtros de TFT estendidos, a mesma deve retornar o indicador de ETFTN ao PDN GW para inclusão nas Opções de Configuração de Protocolo que retornaram ao UE. A PCRF pode modificar a APN-AMBR e os parâmetros de QoS (QCI e ARP) associados à transportador padrão na resposta ao PDN GW, conforme definido em TS 23.203 [6]. Caso o PCC seja configurado para suportar serviços de emergência e caso PCC dinâmico seja implementado, a PCRF, com base no APN de Emergência, define a ARP das regras de PCC para um valor que é reservado para serviços de emergência e a autorização de regras de PCC dinâmico, conforme descrito em TS 23.203 [6]. Caso PCC dinâmico não seja implementado, o PDN GW é configurado para definir a ARP para um valor que é reservado para serviços de emergência.

Caso PCC dinâmico seja implementado e a Indicação de Handover esteja presente, o PDN GW executa um procedimento de Modificação de Sessão de IP-CAN Iniciado por PCRF-com a PCRF, conforme especificado em TS 23.203 [6], para relatar o novo tipo de IP-CAN.

Dependendo das regras de PCC ativo, o estabelecimento de transportador dedicado para o UE pode ser exigido.

O estabelecimento daqueles transportadores deve ocorrer em combinação com a ativação de transportador padrão, conforme descrito no Anexo F.

Esse procedimento pode continuar sem esperar por uma resposta de PCRF.

Caso mudanças nas regras de PCC ativo sejam necessárias, a PCRF pode fornecer as mesmas após o procedimento de handover ser concluído.

Em ambos os casos (Indicação de Handover está presente ou não), caso PCC dinâmico não seja implementado, o PDN GW pode aplicar política de QoS local.

Isso pode levar ao estabelecimento de um número de transportadores dedicados para o UE seguindo os procedimentos definidos na cláusula 5.4.1 em combinação com o estabelecimento do transportador padrão, que é descrito no Anexo F.

Caso os disparos de relatório de informações de CSG sejam recebidos da PCRF, o PDN GW deve definir o IE de Ação de Relatório de Informações de CSG em conformidade.

Caso o Status de UE de Desligamento de Dados PS de 3GPP indique que Desligamento de Dados PS de 3GPP está ativado para o UE, o PGW deve impor as regras de PCC para tráfego de enlace descendente a serem usadas quando Desligamento de Dados PS de 3GPP está ativado.

5. O P-GW cria uma nova entrada em sua tabela de contexto de transportador de EPS e gera um Id de Carregamento para o transportador Padrão. A nova entrada permite que o P-GW realize roteamento PDUs de plano de usuário entre o S-GW e a rede de dados de pacote, e inicie carregamento. O modo que o P-GW manipula Características de Carregamento que o mesmo pode ter recebido é definido em TS 32.251 [44]. O PDN GW retorna uma mensagem de Resposta de Criação de Sessão (Endereço de PDN GW para o plano de usuário, PDN GW TEID do plano de usuário, PDN GW TEID do plano de controle, Tipo de PDN, Endereço de PDN, Id de Transportador de EPS, QoS de Transportador de EPS, Opções de Configuração de Protocolo, Id de Carregamento, Compressão de Carga Útil Proibida, Restrição de APN, Causa, Ação de Relatório de Mudança de Info de MS (Início) (caso o PDN GW decida receber informações de localização de UE durante a sessão), Ação de Relatório de Informações de CSG (Início) (caso o PDN GW decida receber informações de CSG de Usuário de UE durante a sessão), Ação de Área de Relatório de Presença (caso o PDN GW decida receber notificações sobre uma mudança de presença de UE em Área de Relatório de Presença), indicação de Pausa de Carregamento de PDN Habilitada (caso PDN GW tenha escolhido habilitar a função), APN-AMBR, Conexão Tolerante a atrasos) ao GW Servidor. O PDN GW leva em consideração o tipo de PDN recebido, a flag de Transportador de Endereço Duplo e as políticas de operador quando o PDN GW seleciona o tipo de PDN a ser usado conforme a seguir. Caso o tipo de PDN recebido seja IPv4v6 e tanto endereçamento de IPv4 quanto de IPv6 sejam possíveis na PDN, mas a flag de Transportador de Endereço Duplo não seja definida, ou apenas endereçamento de versão de único IP para esse APN seja possível na PDN, o PDN GW seleciona uma única versão de IP (IPv4 ou IPv6). Caso o tipo de PDN recebido seja IPv4 ou IPv6, o PDN GW usa o tipo de PDN caso seja suportado na PDN, de outro modo, uma causa de erro apropriada será retornada.

O PDN GW aloca um Endereço de PDN de acordo com o Tipo de PDN selecionado caso o PDN GW tenha selecionado um tipo de PDN diferente do Tipo de PDN recebido, o PDN GW indica, em conjunto com o IE de tipo de PDN, uma causa para o UE pela qual o tipo de PDN foi modificado, conforme descrito na cláusula 5.3.1.1. O Endereço de PDN pode conter um endereço de IPv4 para IPv4 e/ou um prefixo de IPv6 e um Identificador de Interface.

Caso o PDN tenha sido configurado pelo operador de modo que os endereços de PDN para o APN solicitado devam ser alocados através de uso de DHCPv4 apenas, ou caso o PDN GW permita que o UE use DHCPv4 para alocação de endereço de acordo com a Preferência de Alocação de Endereço recebida do UE, o Endereço de PDN deve ser definido para 0.0.0.0, que indica que o endereço de IPv4 deve ser negociado pelo UE com DHCPv4 após conclusão do procedimento de Ativação de Transportador Padrão.

Para endereçamento de PDN externo para IPv6, o PDN GW obtém o prefixo de IPv6 do PDN externo tanto com o uso de função de cliente Diameter ou RADIUS.

No campo de Endereço de PDN da Resposta de Criação de Sessão, o PDN GW inclui o Identificador de Interface e prefixo de IPv6. O PDN GW envia Anúncio de Roteador para o UE após estabelecimento de transportador padrão com as informações de prefixo de IPv6 para todos os casos.

Caso o endereço de PDN esteja contido na Solicitação de Criação de Sessão, o PDN GW deve alocar o endereço de IPv4 e/ou prefixo de IP6 contido no endereço de PDN para o UE.

Caso Indicação de Handover indique "Handover", as Informações de Endereço de PDN devem conter o mesmo endereço de IP que o UE obteve durante estabelecimento de conectividade de PDN através do acesso não 3GPP. O PDN GW deriva o BCM com base no NRSU e política de operador. O PDN GW deriva se o formato de filtro de TFT estendido deve ser usado com base no ETFTU, ETFTN recebido da PCRF e política de operador. As Opções de Configuração de Protocolo contêm o BCM, ETFTN bem como parâmetros de PDN opcionais que o P-GW pode transferir para o UE. Esses parâmetros de PDN opcionais podem ser solicitados pelo UE, ou podem ser enviados sem solicitação pelo P-GW. As Opções de Configuração de Protocolo são enviadas de modo transparente através da MME. Caso o tipo de PDN seja Não IP, o PDN-GW usa o APN e IMSI para determinar quais ações locais realizar antes de responder ao GW Servidor. O PDN GW inclui uma indicação de Conexão Tolerante a atrasos, caso o PDN GW suporte o recebimento de uma causa de rejeição do SGW que indica que o UE está temporariamente inacessível devido à economia de energia e procedimentos finalizados em móvel em espera, até que o PDN GW receba uma mensagem que indica que o UE está disponível para sinalização de extremidade a extremidade. Quando a Indicação de Handover está presente, o PDN GW não envia ainda pacotes de enlace descendente ao S-GW; a trajetória de enlace descendente deve ser comutada na etapa 13a. Caso o PDN GW seja um L-GW, o mesmo não encaminha pacotes de enlace descendente para o S-GW. Os pacotes serão apenas encaminhados ao HeNB na etapa 10 por meio da trajetória de plano de usuário direta para Acesso de IP Local.

6. O GW Servidor retorna uma mensagem de Resposta de Criação de Sessão (Tipo de PDN, Endereço de PDN, Endereço de GW Servidor para Plano de Usuário, TEID de GW Servidor para Plano de Usuário, TEID de GW Servidor para plano de controle, Id de Transportador de EPS, QoS de Transportador de EPS, endereço de PDN GW e TEID (S5/S8 com base em GTP) ou chave de GRE (S5/S8 com base em PMIP) no PDN GW para tráfego de enlace ascendente, Opções de Configuração de Protocolo, Compressão de Carga Útil Proibida, Restrição de APN, Causa, Ação de Relatório de Mudança de Info de MS (Início), Ação de Relatório de Informações de CSG, Ação de Área de Relatório de Presença, APN- AMBR, DTC) para a MME. O DL TFT para S5/S8 com base em PMIP é obtido de interação entre o GW Servidor e a PCRF, conforme descrito na cláusula 5.6.1 de TS 23.402 [2], quando PCC é implementado; de outro modo, o DL TFT IE é curinga, que corresponde a qualquer tráfego de enlace descendente. Caso o UE indique o Tipo de Solicitação como "Handover", essa mensagem também serve como uma indicação à MME de que a preparação e atualização de transportador S5/S8 foram bem-sucedidos. Nessa etapa, o túnel (ou túneis) de GTP através de S5/S8 é estabelecido. Para otimização de CIoT EPS de Plano de Controle, o endereço de GW Servidor para Plano de Usuário de S11-U e TEID de GW Servidor são usados pela MME para encaminhar dados de UL ao SGW. Caso o Status de UE de Desligamento de Dados PS de 3GPP esteja presente nas PCO de Solicitação de Criação de Sessão, o PGW deve incluir a Indicação de Suporte de Desligamento de Dados PS de 3GPP nas PCO de Resposta de Criação de Sessão.

7. Caso uma Restrição de APN seja recebida, então, a MME deve armazenar esse valor para o Contexto de Transportador e a MME deve verificar esse valor recebido com o valor armazenado para a Restrição Máxima de APN para garantir que não haja conflitos entre valores. Caso a consequência desses resultados de verificação na conectividade de PDN seja rejeitada, a MME deve iniciar uma Desativação de Transportador e retornar uma causa de erro apropriada. Caso a Solicitação de Conectividade de PDN seja aceita, a MME deve determinar um (novo) valor para a Restrição Máxima de APN. Caso não haja valor previamente armazenado para a Restrição Máxima de APN, então, a Restrição Máxima de APN deve ser definida para o valor da Restrição de APN recebida.

Para serviço de emergência, MME não deve desativar transportador(es), caso presente, para manter combinação de restrição de APN válida.

Caso a Ação de Relatório de Mudança de Info de MS (Início) e/ou a Ação de Relatório de Informações de CSG (Início) sejam recebidas para esse contexto de transportador, então, a MME deve armazenar as mesmas para o contexto de transportador e a MME deve relatar àquele P-GW por meio do S-GW sempre que uma mudança de Informações de Localização de UE e/ou Informações de CSG de Usuário ocorrer que satisfaz a solicitação de P-GW, conforme descrito na cláusula 15.1.1a de TS 23.060 [7]. Caso a Ação de Área de Relatório de Presença seja recebida para esse contexto de transportador, a MME deve armazenar essas informações para o contexto de transportador e deve relatar àquele P-GW por meio do S-GW sempre que uma mudança de presença de UE em uma Área de Relatório de Presença é detectada, conforme descrito na cláusula 5.9.2.2. A MME pode precisar modificar O UE AMBR, que foi atribuída ao eNodeB, com base no UE-AMBR assinada e no conjunto atualizado de APN-AMBRs em uso.

Os princípios para determinar O UE-AMBR são descritos na cláusula 4.7.3. A MME envia mensagem de Solicitação de Gerenciamento de Sessão de Aceitação de Conectividade de PDN (APN, Tipo de PDN, Endereço de PDN, Id de Transportador de EPS, Opções de Configuração de Protocolo, Configuração de Compressão de Cabeçalho, Indicador Apenas de Plano de Controle) ao UE.

Caso a conexão PDN use o plano de usuário através do rádio, essa mensagem está contida em uma mensagem de controle de S1_MME de Solicitação de preparação de transportador (QoS de Transportador de EPS, UE-AMBR,

Aceitação de Conectividade de PDN, S1-TEID) ao eNodeB.

Entretanto, caso otimização de CIoT EPS de Plano de Controle se aplique à conexão PDN, uma mensagem de Transporte de NAS de Enlace Descendente de S1-AP é usada.

A mensagem de Solicitação de Preparação de contexto Inicial de S1-AP inclui o TEID no GW Servidor usado para plano de usuário e o endereço do GW Servidor para plano de usuário.

Além disso, caso a conexão PDN seja estabelecida para Acesso de IP Local, a mensagem de Solicitação de Preparação de contexto Inicial de S1 correspondente inclui um ID de Correlação para habilitar a trajetória de plano de usuário direta entre o HeNB e o L-GW.

Caso a conexão PDN seja estabelecida para SIPTO na Rede Local com função de L-GW justaposta ao (H)eNB, a Solicitação de Preparação de contexto Inicial de S1-AP correspondente inclui um ID de Correlação de SIPTO para habilitar a trajetória de plano de usuário direta entre o (H)eNB e o L-GW.

LIPA e SIPTO não se aplicam à Otimização de CIoT EPS de Plano de Controle.

NOTA 5: Nessa versão da especificação de 3GPP, o ID de Correlação e ID de Correlação de SIPTO são definidos de modo igual ao PDN GW TEID de plano de usuário (S5 com base em GTP) ou chave de GRE (S5 com base em PMIP) que a MME recebeu na etapa 6. Na mensagem de Aceitação de Conectividade de PDN, a MME não inclui o prefixo de IPv6 dentro do Endereço de PDN.

A MME inclui a APN-AMBR e o parâmetro de QoS de Transportador de EPS QCI na Solicitação de Gerenciamento de Sessão.

Além disso, caso o UE tenha capacidades de UTRAN ou GERAN e a rede suporte mobilidade para UTRAN ou GERAN, a MME usa os parâmetros de QoS de transportador de EPS para derivar os parâmetros de contexto de PDP correspondentes de QoS Negociada (perfil de QoS de R99), Prioridade de Rádio,

Id de Fluxo de Pacote e TI e inclui os mesmos na Solicitação de Gerenciamento de Sessão.

Caso o UE tenha indicado, na Capacidade de Rede de UE, que o mesmo não suporta procedimentos de fluxo de pacote de BSS, então, a MME não deve incluir o Id de Fluxo de Pacote.

A MME não enviará a mensagem de Solicitação de preparação de Transportador de S1 até que qualquer mensagem de Resposta de preparação de Transportador de S1 pendente para o mesmo UE tenha sido recebida ou atingido o limite de tempo.

Caso a APN-AMBR tenha mudado, a MME pode atualizar O UE-AMBR, caso apropriado.

A MME pode incluir uma indicação da possibilidade de se permitir que o tráfego dessa Conexão PDN seja descarregado para WLAN, conforme descrito na cláusula 4.3.23. Caso o UE tenha indicado tipo de PDN "Não IP", a MME e PDN GW não devem mudar tipo de PDN.

Caso a MME ou PDN GW tenha mudado o Tipo de PDN, uma causa apropriada deve retornar ao UE, conforme descrito na cláusula 5.3.1.1. Caso a otimização de CIoT EPS de Plano de Controle se aplique para uma conexão PDN de IP, e o UE tenha enviado, na Solicitação de Conectividade de PDN, a Configuração de Compressão de Cabeçalho, a MME deve incluir a Configuração de Compressão de Cabeçalho na mensagem de Aceitação de Conectividade de PDN.

A MME também liga os canais de ROHC de enlace ascendente e enlace descendente para suportar sinalização de realimentação de compressão de cabeçalho.

Caso o UE tenha incluído parâmetros de preparação de contexto de ROHC em Configuração de Compressão de Cabeçalho na Solicitação de Conectividade de PDN, a MME pode reconhecer os parâmetros de preparação de contexto de ROHC.

Caso o contexto de ROHC não seja estabelecido durante o procedimento de estabelecimento de conexão PDN, antes de usar o formato comprimido para enviar os dados, o UE e a MME precisam estabelecer o contexto de ROHC com pacote de ROHC IR com base em

Configuração de Compressão de Cabeçalho. Caso a MME, com base em política local, determine que a conexão PDN deve usar apenas a Otimização de EPS de Plano de Controle, a MME deve incluir um Indicador Apenas de Plano de Controle na Solicitação de Gerenciamento de Sessão. Para conexões de PDN com uma SCEF, a MME deve sempre incluir o Indicador Apenas de Plano de Controle. Caso haja uma conexão SGi PDN existente para esse UE para o qual a MME incluiu um Indicador Apenas de Plano de Controle, a MME deve incluir o mesmo também para a conexão SGi PDN adicional. Caso a MME não tenha incluído um Indicador Apenas de Plano de Controle para qualquer uma dentre as conexões de SGi PDN existentes desse UE, a MME não deve incluir o mesmo para a conexão SGi PDN adicional. Um UE que recebe o Indicador Apenas de Plano de Controle, para uma conexão PDN, deve usar apenas a otimização de CIoT EPS de Plano de Controle para essa conexão PDN. NOTA 6: A decisão de MME de incluir ou não um Indicador Apenas de Plano de Controle para uma conexão SGi PDN para um UE que não tinha previamente conexões de SGi impactará outras conexões de SGi PDN subsequentes potenciais para aquele UE.

8. Caso o eNodeB tenha recebido uma Solicitação de Preparação de contexto Inicial de S1-AP, o eNodeB envia Reconfiguração de Conexão de RRC ao UE que inclui a mensagem de Aceitação de Conectividade de PDN. Caso o eNodeB tenha recebido uma mensagem de Transporte de NAS de Enlace Descendente de S1-AP contendo a mensagem de Aceitação de Conectividade de PDN de NAS o eNodeB envia uma mensagem de Transferência Direta de RRC ao UE e as etapas 9 e 10 não são executadas. O UE deve armazenar a QoS Negociada, Prioridade de Rádio, Id de Fluxo de Pacote e TI, que o mesmo recebeu no IE de Solicitação de Gerenciamento de

Sessão, para uso ao acessar por meio de GERAN ou UTRAN. O UE pode fornecer parâmetros de QoS de Transportador de EPS à aplicação que manipula o fluxo de tráfego. O uso de aplicação do QoS de Transportador de EPS é dependente de implantação. O UE não deve rejeitar a Reconfiguração de Conexão de RRC com base nos parâmetros de QoS de Transportador de EPS contidos na Solicitação de Gerenciamento de Sessão. Caso o UE receba um endereço de IPv4 definido para 0.0.0.0, o mesmo pode negociar o endereço de IPv4 com DHCPv4, conforme especificado em TS 29.061 [38], Caso o UE receba um identificador de interface de IPv6, o mesmo pode esperar o Anúncio de Roteador da rede com as informações de prefixo de IPv6 ou pode enviar uma Solicitação de Roteador, caso necessário. NOTA 7: Os detalhes de alocação de endereço de IP são descritos na cláusula 5.3.1 em "Alocação de Endereço de IP".

9. O UE envia a Conclusão de Reconfiguração de Conexão de RRC ao eNodeB.

10. O eNodeB envia uma Resposta de preparação de Transportador de S1-AP à MME. A mensagem de S1-AP inclui o TEID do eNodeB e o endereço do eNodeB usado para tráfego de enlace descendente no ponto de referência de S1_U. Caso o ID de Correlação ou ID de Correlação de SIPTO seja incluído na Solicitação de preparação de Transportador, o eNodeB deve usar as informações incluídas para estabelecer uma trajetória de plano de usuário direta para o L-GW e encaminhar dados de enlace ascendente para Acesso de IP Local ou SIPTO na Rede Local com função de L-GW justaposta ao (H)eNB em conformidade.

11. A camada de NAS de UE constrói uma mensagem de Conclusão de Conectividade de PDN que inclui Identidade de Transportador de EPS. O UE envia, então, uma mensagem de Transferência Direta (Conclusão de

Conectividade de PDN) ao eNodeB.

12. O eNodeB envia uma mensagem de Transporte de NAS de Enlace Ascendente (Conclusão de Conectividade de PDN) à MME. Após a mensagem de Aceitação de Conectividade de PDN e, uma vez que o UE (caso aplicável ao tipo de PDN) tiver obtido Informações de Endereço de PDN, o UE pode enviar, então, pacotes de enlace ascendente para o eNodeB que podem, então, ser tunelados pela MME para o GW Servidor e PDN GW, ou transferidos pela MME para uma SCEF (consulte TS 23.682 [74]), conforme informações de assinatura relacionadas ao APN discutidas acima na etapa 2. Caso o UE tenha solicitado um tipo de PDN de endereço duplo (IPv4v6) para um determinado APN e tenha sido concedido um tipo de PDN de endereço único (IPv4 ou IPv6) pela rede com uma causa que indica que apenas versão de único IP por conexão PDN é permitida, o UE deve solicitar a ativação de uma conexão PDN paralela para o mesmo APN com um tipo de PDN de endereço único (IPv4 ou IPv6) diferente do já ativado. Caso o UE não receba causa na etapa 8 em resposta a um tipo de PDN IPv4v6 e receba um Identificador de Interface de IPv6 além do endereço de IPv4 ou 0.0.0.0 no campo de Endereço de PDN, o mesmo considera que a solicitação de uma PDN de endereço duplo foi bem-sucedida. O mesmo pode esperar pelo Anúncio de Roteador da rede com as informações de prefixo de IPv6 ou pode enviar Solicitação de Roteador, caso necessário.

13. Mediante recepção da mensagem de Resposta de preparação de Transportador, na etapa 10, e da mensagem de Conclusão de Conectividade de PDN, na etapa 12, a MME envia uma mensagem de Solicitação de Modificação de Transportador (Identidade de Transportador de EPS, endereço de eNodeB, TEID de eNodeB, Indicação de Handover, Informações de Área de Relatório de Presença) ao GW Servidor. Caso a otimização de CIoT EPS de Plano de Controle se aplique e a conexão PDN não seja servida por meio de um tipo de SCEF de conectividade, as etapas 13 e 14 são executadas apenas caso a MME precise relatar uma mudança de presença de UE na Área de Relatório de Presença, de outro modo, caso a conexão PDN seja servida por SCEF, as etapas 13,14, 15 e 16 não são executadas.

Caso Tipo de Solicitação indique "handover", a Indicação de Handover também é incluída.

Caso a MME tenha sido solicitada para relatar uma mudança de presença de UE em Área de Relatório de Presença, a MME inclui, nessa mensagem, as Informações de Área de Relatório de Presença que compreendem o identificador(es) de PRA e indicação(ões) da possibilidade de o UE estar dentro ou fora da área(s). Ao receber a solicitação para relatar mudança de presença de UE em Área de Relatório de Presença, e a MME decidir não ativar relatório de presença de UE em uma ou mais dentre a Área(s) de Relatório de Presença recebida, a MME relata também a Área(s) de Relatório de Presença inativa nessa mensagem. 13a.

Caso a Indicação de Handover esteja incluída na etapa 13, o GW Servidor envia uma mensagem de Solicitação de Modificação de Transportador (Indicação de Handover) ao PDN GW para alertar ao PDN GW para que realize tunelamento de pacotes de sistema de acesso de IP não 3GPP para sistema de acesso 3GPP e inicie imediatamente o roteamento de pacotes para o GW Servidor para o padrão e quaisquer transportadores de EPS dedicados estabelecidas.

Caso Informações de Área de Relatório de Presença estejam incluídas na etapa 13, o GW Servidor envia uma mensagem de Solicitação de Modificação de Transportador (Informações de Área de Relatório de Presença) ao PDN GW.

NOTA 8: O PDN GW encaminha as Informações de Área de Relatório de Presença à PCRF, ao OCS ou a ambos, conforme definido em TS 23.203 [6]. 13b.

O PDN GW reconhece enviando-se Resposta de modificação de transportador ao GW Servidor.

14. O GW Servidor reconhece enviando-se Resposta de modificação de transportador (Identidade de Transportador de EPS) à MME. O GW Servidor pode enviar, então, seus pacotes de enlace descendente armazenados em buffer.

15. Após a MME receber Resposta de modificação de transportador, na etapa 14, caso Tipo de Solicitação não indique handover e um transportador de EPS tenha sido estabelecida e, caso os dados de assinatura indiquem que o usuário tem permissão para realizar handover para acessos não 3GPP e, caso essa seja a primeira conexão PDN associada a esse APN e, caso a MME tenha selecionado um PDN GW que é diferente da identidade de PDN GW que foi previamente indicada pelo HSS no contexto de assinatura de PDN, a MME deve enviar uma Solicitação de Notificação que inclui o endereço de PDN GW e o APN ao HSS para mobilidade com acessos não 3GPP. A mensagem deve incluir informações que identificam a PLMN onde o PDN GW está localizado. Para um UE não autenticado ou roaming, caso o Tipo de Solicitação do procedimento de conectividade solicitado por UE indique "Emergência", a MME não deve enviar qualquer Solicitação de Notificação ao HSS. Para um UE autenticado não roaming, com base em configuração de operador (por exemplo, se voz sobre WLAN é suportada ou não pelo operador), caso o Tipo de Solicitação indique "Emergência", a MME pode enviar uma Solicitação de Notificação ao HSS que inclui o "PDN GW atualmente em uso para serviços de emergência", que compreende o endereço de PDN GW e uma indicação de que a conexão PDN é para serviços de emergência. O HSS deve armazenar as informações como parte do contexto de UE para serviços de emergência.

16. No caso de serviços de não emergência, o HSS armazena a identidade de PDN GW e o APN associado. No caso de serviços de emergência, o HSS armazena o "PDN GW atualmente em uso para serviços de emergência".

Então, o HSS envia uma Resposta de Notificação à MME. NOTA 9: Para handover de acesso não 3GPP, o PDN GW inicia procedimento de desativação de alocação de recurso no acesso de IP não 3GPP confiável/não confiável, conforme especificado em TS 23.402 [2].

5.7.1 HSS IMSI é a chave principal para os dados armazenados no HSS. Os dados mantidos no HSS são definidos na Tabela 5.7.1-1 abaixo. A tabela abaixo é aplicável à E-UTRAN em operação autônoma apenas. Tabela 5.7.1-1: Dados de HSS Campo Descrição IMSI A IMSI é a principal chave de referência. A MSISDN básica do UE (Presença de MSISDN é

MSISDN opcional). Identificação Internacional de Equipamento IMEI / IMEISV Móvel - Número de Versão de Software Identificador(es) Externo usado na rede(s) Lista de Identificador externa para se referir à assinatura. Consulte Externo TS 23.682 [74] para mais informações. A identidade da MME que serve atualmente Identidade de MME esse UE. Indica as capabilidades da MME em relação à Capabilidades de MME funcionalidade Núcleo, por exemplo, restrições de acesso regional. MS PS Purgada a partir Indica que os contextos de EMM e ESM do UE de EPS são excluídos da MME.

Campo Descrição Indicam que o status do bloqueio determinado Parâmetros de ODB por operador Indica as informações de assinatura de restrição de acesso.

As mesmas podem incluir diferentes valores para HPLMN e caso de roaming.

Restrição de Acesso Incluem definições separadas para WB-E-UTRAN e NB-IoT.

Incluem informações de restrição sobre o uso de NR como uma RAT secundária para conectividade de plano de usuário.

Características de As características de carregamento para o UE, Carregamento de EPS por exemplo, assinatura normal, pré-paga, taxa fixa Assinado e/ou de hot billing.

Identifica uma gravação ou uma coleção de Referência de Rastreio gravações para um rastreio particular.

Indica o tipo de rastreio, por exemplo, rastreio Tipo de Rastreio de HSS e/ou rastreio de MME/ GW Servidor / PDN GW.

Identifica o OMC que deve receber a Identidade de OMC gravação(ões) de rastreio.

As MBRs de enlace ascendente e enlace descendente agregadas máximas a serem AMBR de UE Assinada compartilhadas através de todos os transportadores Não GBR, de acordo com a assinatura do usuário.

Campo Descrição Indica o nome de domínio para substituir o APN OI ao construir o PDN GW FQDN mediante o qual realizar uma resolução de DNS.

Essa substituição se Substituição de APN-OI aplica para todos os APNs no perfil de assinante.

Consulte TS 23.003 [9] cláusula 9.1.2 para mais informações sobre o formato de nomes de domínio que são permitidos nesse campo.

Um índice para configuração de RRM específica Índice de RFSP na E-UTRAN Parâmetro de Solicitação de Acessibilidade de URRP-MME UE que indica que notificação de atividade de UE de MME foi solicitada pelo HSS.

Os Dados de Assinatura de CSG são uma lista de IDs de CSG por PLMN e, para cada ID de CSG, de modo opcional, uma data de expiração associada que indica o ponto no tempo em que a assinatura do Dados de Assinatura de ID de CSG expira; uma data de expiração ausente CSG indica assinatura ilimitada.

Para um ID de CSG que pode ser usado para acessar PDNs específicas por meio de Acesso de IP Local, a entrada de ID de CSG inclui o APN(s) correspondente.

Especifica, por PLMN, se o UE tem permissão VPLMN LIPA Permitido para usar LIPA.

Indica a lista de PLMN equivalente para a PLMN Lista de EPLMN registrada de UE.

Campo Descrição Temporizador de Indica um valor de Temporizador de RAU/TAU RAU/TAU Periódico Periódico assinado Assinado Comprimento de ciclo Indica um valor de comprimento de ciclo de de DRX de modo ocioso DRX de modo ocioso estendido assinado. estendido Indica que o UE está assinado no serviço de Prioridade de MPS CS prioridade eMLPP ou 1x RTT no domínio de CS.

Capabilidade de UE- Indica se o UE tem ou não capabilidade para SRVCC UTRAN/GERAN SRVCC.

Indica que o UE está assinado em MPS no Prioridade de MPS EPS domínio de EPS.

Indica as características de uso do UE para uso Tipo de Uso de UE com Redes Núcleo Dedicadas (consulte a cláusula 4.3.25). Lista do grupo(s) assinado ao qual o UE Lista de ID de Grupo pertence Indica, por UE, os Padrões de Comunicação e Padrões de seu tempo de validade correspondente, conforme Comunicação especificado em TS 23.682 [74]. Os Padrões de Comunicação não são fornecidos ao SGSN.

Dados de Informações Descrevem as informações de configuração de de Evento de evento de monitoramento.

Consulte TS 23.682 [74] Monitoramento para mais informações.

Campo Descrição Restrição de Conexão Indica se o estabelecimento da conexão PDN é PDN restrito para o UE.

Cobertura Aprimorada Especifica PLMN(s) com restrições de Restrita Cobertura Aprimorada.

Indicam se Reconhecimento de PDUs de dados Reconhecimentos de de NAS de enlace descendente para Otimização de PDUs de dados de NAS CIoT de Plano de Controle está desabilitada para de enlace descendente esse UE (habilitada por padrão). Gap de serviço é um parâmetro que especifica o tempo mínimo entre duas solicitações de conexão Gap de Serviço de dados MO consecutivas (consulte a cláusula 4.3.x acima). Cada perfil de assinatura contém um ou mais contextos de assinatura de PDN: Identificador de Índice do contexto de assinatura de PDN (Nota Contexto 8). Endereço de PDN Indica endereço(s) de IP assinado.

Indica o Tipo de PDN assinado (IPv4, IPv6, Tipo de PDN IPv4v6, Não IP)

Campo Descrição Substituição de APN-OI de nível de APN que tem mesma função que Substituição de APN-OI de nível de UE, mas com prioridade mais alta do que Substituição de APN-OI Substituição de APN-OI de nível de UE.

Esse é um parâmetro opcional.

Quando disponível, deve ser usado para construir o PDN GW FQDN em vez de Substituição de APN-OI de nível de UE.

Um rótulo de acordo com convenções de Nome de Ponto de nomeação de DNS que descreve o ponto de acesso Acesso (APN) para a rede de dados de pacote (ou um curinga) (NOTA 6). Invocar Seleção de Indica se esse APN é usado para estabelecer SCEF conexão PDN com a SCEF Indica o FQDN ou endereço de IP da SCEF que deve ser selecionado para esse APN.

É necessário ID de SCEF caso indicador “Invocar Seleção de SCEF” seja definido.

Indica se o tráfego associado a esse APN é proibido para SIPTO, permitido para SIPTO excluindo Permissões de SIPTO SIPTO na rede local, permitido para SIPTO incluindo SIPTO na rede local ou permitido para SIPTO na rede local apenas (NOTA 7). Indica se a PDN pode ser acessada por meio de Permissões de LIPA Acesso de IP Local.

Possíveis valores são: LIPA- proibido, LIPA-apenas e LIPA-condicional.

Campo Descrição Indica se o tráfego associado a esse APN tem permissão para ser descarregado em WLAN com o Descarregamento de uso do recurso de Interligação de Rádio WLAN/3GPP WLAN ou se deve ser mantido em acesso 3GPP (consulte a cláusula 4.3.23). A indicação pode conter valores separados por RAT (E-UTRA e UTRA). Os valores de parâmetro de QoS de nível de Perfil de QoS de EPS transportador para aquele transportador padrão de assinado APN (QCI e ARP) (consulte a cláusula 4.7.3). As MBRs de enlace ascendente e enlace descendente agregadas máximas a serem AMBR de APN assinada compartilhadas por todos os transportadores Não GBR, que são estabelecidas para esse APN.

As características de carregamento desse Características de contexto de PDN Assinada para o UE, por exemplo, Carregamento de EPS assinatura normal, pré-paga, taxa fixa e/ou fatura a PDN Assinada qualquer momento (hot billing). As características de carregamento são associadas a esse APN.

Especifica, por VPLMN se, para esse APN, o UE Endereço de VPLMN tem permissão de usar o PDN GW no domínio da Permitido HPLMN apenas ou, adicionalmente, o PDN GW no domínio da VPLMN.

A identidade do PDN GW usado para esse APN.

A identidade de PDN GW pode ser um FQDN ou um Identidade de PDN GW endereço de IP.

A identidade de PDN GW se refere a um PDN GW específico.

Campo Descrição Indica se o PDN GW está alocado de modo Tipo de Alocação de estático ou selecionado de modo dinâmico por PDN GW outros nós. Um PDN GW alocado de modo estático não é alterado durante seleção de PDN GW. Fornece, para esse APN, como manipular uma conexão PDN quando o UE se move entre "banda larga" (WB-E-UTRAN e UTRAN) e "banda estreita" Continuidade de PDN (NB-IoT, GPRS, EC-GSM-IoT). Possíveis valores são: em mobilidade entre manter a conexão PDN; desconectar a conexão PDN

RAT com uma solicitação de reativação; desconectar a conexão PDN sem solicitação de reativação; ou deixar para política de VPLMN local. Identifica a PLMN em que o PDN GW PLMN de PDN GW selecionado de modo dinâmico está localizado. Indica, por UE e MME, se "Voz sobre IMS de sessões PS" são suportadas de maneira homogênea Suporte Homogêneo de em todas as TAs na MME servidora ou não Voz sobre IMS de suportadas de maneira homogênea, ou suporte é sessões PS para MME não homogêneo/desconhecido, consulte a cláusula 4.3.5.8A. Lista de relações de APN - PDN GW ID (para contexto de assinatura de PDN com APN curinga):

Campo Descrição O APN e a identidade do PDN GW alocado de modo dinâmico de uma conexão PDN que é Relação de APN - P-GW autorizada pelo contexto de assinatura de PDN com #n o APN curinga. A identidade de PDN GW pode ser um FQDN ou um endereço de IP. A identidade de PDN GW se refere a um PDN GW específico.

NOTA 1: IMEI e SVN são armazenados em HSS quando o recurso de Detecção de Dispositivo Automática é suportado, consulte a cláusula 15.5 de TS 23.060 [7]. NOTA 2: O “perfil de QoS de EPS assinado” armazenado em HSS é complementar ao “perfil de QoS de GPRS assinado” herdado. NOTA 3: Vazio. NOTA 4: A maneira como indicar qual dentre os contextos de assinatura de PDN armazenados no HSS é o padrão para o UE é definida no estágio 3. NOTA 5: Para ajudar na seleção de um PDN GW e GW Servidor justapostos ou topologicamente apropriados, a identidade de PDN GW deve ser na forma de um FQDN. NOTA 6: O campo "Nome de Ponto de Acesso (APN)”, na tabela acima, contém a parte de APN-NI do APN. NOTA 7: Neste relatório descritivo, os valores "proibido para SIPTO" e "permitido para SIPTO excluindo SIPTO na rede local" correspondem aos pré- valores Rel-12 "proibido para SIPTO" e "permitido para SIPTO". Codificação real desses valores pertence a domínio de Estágio 3. NOTA 8: Pode haver, no máximo, dois APNs padrão para um determinado usuário. Um APN padrão pode pertencer a qualquer um dentre os três tipos de PDN de "IPv4", "IPv6" ou "IPv4v6", e outro APN padrão pode pertencer a um tipo de PDN de "Não IP". Uma assinatura de CSG expirada não deve ser removida dos dados de assinatura de HSS antes de ser removida da lista de CSG Permitido ou lista de CSG de Operador de UE. Quando uma assinatura de CSG é cancelada, a mesma deve ser manipulada como uma assinatura expirada em dados de assinatura de HSS para permitir a remoção da mesma primeiro da lista de CSG Permitido ou lista de CSG de Operador de UE. Um (e apenas um) dentre os contextos de assinatura de PDN armazenados no HSS pode conter um APN curinga (consulte TS 23.003 [9]) no campo de Nome de Ponto de Acesso. O contexto de assinatura de PDN marcado como o padrão não deve conter um APN curinga. O contexto de assinatura de PDN com um APN curinga não deve conter um PDN GW alocado de modo estático. Caso as flags de permissão de LIPA e permissão de SIPTO sejam, ambas, incluídas para um APN particular, os mesmos devem ser definidos de um modo consistente, por exemplo, caso a permissão de LIPA seja definida para LIPA- apenas ou LIPA-condicional, a permissão de SIPTO deve ser definida para SIPTO- proibido. De modo contrário, caso a permissão de SIPTO indique que o APN é um APN com SIPTO-permitido, a permissão de LIPA deve ser definida para LIPA- proibido. Um APN com SIPTO-permitido é um APN para o qual a permissão de SIPTO é definida para permitido para SIPTO excluindo SIPTO na rede local, permitido para SIPTO incluindo SIPTO na rede local ou permitido para SIPTO na rede local apenas.

5.7.2 MME

A MME mantém informações de contexto de MM e contexto de transportador de EPS Para o UEs nos estados ECM-OCIOSO, ECM-CONECTADO e EMM-DESCADASTRADO. A Tabela 5.7.2-1 mostra os campos de contexto para um UE. Tabela 5.7.2-1: Contextos de MME MM e transportador de EPS Campo Descrição IMSI (Identificação Internacional de Acesso

IMSI Móvel) é a identidade permanente de assinante. Indicador não Esse é um indicador de IMSI para mostrar que autenticado de IMSI a IMSI não é autenticada. A MSISDN básica do UE. A presença é ditada

MSISDN por seu armazenamento no HSS. Estado de gerenciamento de mobilidade ECM- Estado de MM OCIOSO, ECM-CONECTADO, EMM- DESCADASTRADO. GUTI Identidade Temporária Globalmente Única. Identidade de Equipamento Móvel – (por Identidade de ME exemplo, IMEI/IMEISV) Número de Versão de Software Lista de Área de Lista Atual de Área de Rastreamento Rastreamento TAI da TA em que a última Atualização de Área TAI de última TAU de Rastreamento foi iniciada. Identidade Global de Última célula de E-UTRAN conhecida Célula de E-UTRAN

Campo Descrição Tempo decorrido desde que a última Idade de Identidade Identidade Global de Célula de E-UTRAN foi de Célula de E-UTRAN adquirida Último CSG ID conhecido quando o UE estava

CSG ID ativo Último membro de CSG conhecido do UE Membro de CSG quando o UE estava ativo Modo de acesso de último ECGI conhecido Modo de acesso quando o UE estava ativo Autenticação temporária e dados de acordo de chaves que possibilita que uma MME se envolva em AKA com um usuário particular. Um Vetor de Autenticação de EPS consiste em quatro elementos: Vetor de Autenticação a) desafio de rede RAND, b) uma resposta esperada XRES, c) Chave KASME, d) um token de autenticação de rede AUTN. Capabilidades de Acesso via Rádio de UE Capabilidade de incluindo capacidades para WB-E-UTRAN, mas não Acesso via Rádio de UE capacidades para NB-IoT. Capabilidade de Capabilidades de Acesso via Rádio de UE Acesso via Rádio de UE específicas de NB-IoT. específica de NB-IoT

Campo Descrição Classmark de rede núcleo de domínio de CS MS Classmark 2 GERAN/UTRAN (usado caso a MS suporte SRVCC para GERAN ou UTRAN) Classmark de rede de rádio de domínio de MS Classmark 3 GERAN CS (usado caso a MS suporte SRVCC para GERAN) Lista de codecs suportados no domínio CS Codecs suportados (usada caso a MS suporte SRVCC para GERAN ou UTRAN) Capabilidades de rede de UE que incluem Capabilidade de Rede algoritmos de segurança e funções de derivação de de UE chave suportadas pelo UE Para um UE com capabilidade para GERAN Capabilidade de Rede e/ou UTRAN, esse contém informações necessárias de MS pelo SGSN.

Parâmetros de DRX Parâmetros de DRX específicos de UE para Específicos de UE modo A/Gb, modo lu e modo-S1 Valor de Tempo ativo específico de UE alocado Valor de Tempo Ativo por MME para manipulação de modo de economia para PSM de energia.

Parâmetros de DRX de Parâmetros de DRX de modo ocioso estendido modo ocioso negociado para modo S1. estendido Algoritmo de NAS Algoritmo de segurança de NAS selecionado Selecionado

Campo Descrição Identificador de Conjunto de Chaves para a chave principal KASME. Também indica se o UE está eKSI usando chaves de segurança derivadas de associação de segurança de UTRAN ou E-UTRAN Chave principal para hierarquia de chave de E- KASME UTRAN com base em CK, IK e identidade de rede servidora. Chaves de NAS e KNASint, K_NASenc e parâmetro NAS COUNT.

COUNT Identidade de operador de rede núcleo Id de operador de CN selecionada (para suportar compartilhamento de selecionado rede, conforme definido em TS 23.251 [24]). Indica se o HSS está realizando recuperação de Recuperação banco de dados. As informações de assinatura de restrição de acesso. Para essa finalidade, WB-E-UTRAN e NB-IoT são RATs separadas. Além disso, incluem Restrição de Acesso informações de restrição sobre o uso de NR como RAT secundária para conectividade de plano de usuário. ODB para parâmetros Indica que o status do bloqueio determinado de PS por operador para serviços orientados por pacote.

Campo Descrição Indica o nome de domínio para substituir o APN-OI ao construir o PDN GW FQDN mediante o qual realizar uma resolução de DNS. Essa Substituição de APN- substituição se aplica para todos os APNs no perfil

OI de assinante. Consulte TS 23.003 [9] cláusula 9.1.2 para mais informações sobre o formato de nomes de domínio que são permitidos nesse campo. Endereço de MME IP Endereço de MME IP para a interface de S11 para S11 (usada por S-GW) Identificador de Ponto Final de Túnel de MME MME TEID para S11 para interface S11. Endereço de S-GW IP Endereço de S-GW IP para as interfaces S11 e para S11/S4 S4 S-GW TEID para Identificador de Ponto Final de Túnel de S-GW S11/S4 para as interfaces S11 e S4. Endereço de SGSN IP para a interface S3 (usado Endereço de SGSN IP caso ISR esteja ativada para o UE com capacidade para S3 para GERAN e /ou UTRAN) Identificador de Ponto Final de Túnel de SGSN SGSN TEID para S3 para interface S3 (usado caso ISR esteja ativada para o UE com capacidade para E-UTRAN) Endereço de eNodeB O endereço de IP do eNodeB atualmente usado em Uso para S1-MME para S1-MME. eNB S1 UEAP ID Identidade exclusiva do UE dentro de eNodeB. MME S1 UEAP ID Identidade exclusiva do UE dentro de MME.

Campo Descrição Os valores de MBR de enlace ascendente e enlace descendente Agregados Máximos a serem UE-AMBR Assinada compartilhados através de todos os transportadores Não GBR, de acordo com a assinatura do usuário.

Os valores de MBR de enlace ascendente e enlace descendente Agregados Máximos UE-AMBR atualmente usados para serem compartilhados por todos os transportadores Não GBR.

Características de As características de carregamento para o UE, Carregamento de EPS por exemplo, normal, pré-pago, taxa fixa e/ou Assinado fatura a qualquer momento (hot billing). Índice de RFSP Um índice para configuração de RRM Assinada específico na E-UTRAN que é recebido do HSS.

Um índice para configuração de RRM Índice de RFSP em Uso específico na E-UTRAN que está atualmente em uso.

Tipo de Rastreio Indica o tipo de rastreio Id de Disparo Identifica a entidade que iniciou o rastreio Identifica o OMC que deve receber a Identidade de OMC gravação(ões) de rastreio.

URRP-MME que indica que o HSS solicitou para URRP-MME que a MME notifique o HSS em relação à acessibilidade de UE na MME

Campo Descrição Quando armazenamento em buffer estendido Tempo de Expiração de dados de DL tiver sido invocado Para o UEs que de buffer de Dados de usam funções de economia de energia, por DL exemplo, PSM, esse momento é quando o buffer expirará no GW Servidor.

Número sugerido de Número sugerido de pacotes de enlace pacotes de enlace descendente armazenados em buffer em descendente armazenamento em buffer estendido.

Esse é um armazenados em parâmetro opcional. buffer Os Dados de Assinatura de CSG são listas associadas de IDs de CSG para a PLMN visitante e as PLMNs equivalentes da PLMN visitante e, para cada ID de CSG, de modo opcional, uma data de expiração associada que indica o ponto no tempo Dados de Assinatura em que a assinatura do ID de CSG expira; uma data de CSG de expiração ausente indica assinatura ilimitada.

Especifica se o UE tem permissão para usar LIPA Permitido LIPA nessa PLMN.

Temporizador de Indica um valor de Temporizador de RAU/TAU RAU/TAU Periódico Periódico assinado Assinado

Campo Descrição Indica que o UE está assinado no serviço de Prioridade de MPS CS prioridade eMLPP ou 1x RTT no domínio de CS.

Indica que o UE está assinado em MPS no Prioridade de MPS EPS domínio de EPS.

Uma indicação da possibilidade de as capacidades de rádio de UE serem compatíveis com Indicador de a configuração de rede (por exemplo, se o SRVCC e Correspondência de frequência suportada pelo UE corresponde àquelas Suporte de Voz em que a rede depende para cobertura de voz). A MME usa isso como uma entrada para definir a Indicação de Voz sobre IMS de sessão PS Suportada.

Indica, por UE, se "Voz sobre IMS de sessões PS" são suportadas de maneira homogênea em Suporte Homogêneo todas as TAs na MME servidora ou não suportadas de Voz sobre IMS de de maneira homogênea, ou suporte é não sessões PS homogêneo/desconhecido, consulte a cláusula 4.3.5.8A.

Capacidade de Rádio Informações usadas pelo eNB para aprimorar a de UE para radiolocalização no UE (consulte a cláusula 5.11.4). Informações de A Capacidade de Rádio de UE para Informações de Radiolocalização Radiolocalização é definida em TS 36.413 [36].

Campo Descrição Informações enviadas pelo eNB, e usadas pela MME ao radiolocalizar o UE para ajudar a Informações Sobre determinar os eNBs a serem radiolocalizados bem Células Recomendadas como fornecer as informações em células E ENBs Para recomendadas para cada um dentre esses eNBs, a Radiolocalização fim de otimizar a probabilidade de radiolocalização bem-sucedida enquanto minimiza a carga de sinalização na trajetória de rádio.

Informações fornecidas pela MME e usadas Contagem de pelo eNB para otimizar carga de sinalização e o uso Tentativa de de recursos de rede para radiolocalizar, de maneira Radiolocalização bem-sucedida, um UE.

Informações para nível de Cobertura Informações para Aprimorada e ID de célula fornecidas pelo último Cobertura Aprimorada eNB ao qual o UE foi conectado.

Cobertura Aprimorada Especifica se o UE é restrito ou não para usar Restrita recurso de cobertura aprimorada.

Indica as características de uso do UE para uso Tipo de Uso de UE com Redes Núcleo Dedicadas (consulte a cláusula 4.3.25). Lista do grupo(s) assinado ao qual o UE Lista de ID de Grupo pertence Dados de Informações Descrevem as informações de configuração de de Evento de evento de monitoramento.

Consulte TS 23.682 [74] Monitoramento para mais informações.

Campo Descrição Indica que a conexão PDN é Tolerante a atrasos de modo que o PDN GW suporte holding do procedimento, após receber uma rejeição com uma Conexão Tolerante a causa que indica que UE está temporariamente atrasos inacessível devido à economia de energia, até o PDN GW receber uma mensagem que indica que o UE está disponível para sinalização de extremidade a extremidade Restrição de Conexão Indica se o estabelecimento da conexão de PDN PDN é restrito para o UE.

Reconhecimentos de Indicam se Reconhecimento de PDUs de dados PDUs de dados de NAS de NAS de enlace descendente para Otimização de de enlace CIoT de Plano de Controle está desabilitada para descendente esse UE (habilitada por padrão). Gap de serviço é um parâmetro de assinatura recebido de HSS que especifica o tempo mínimo Gap de Serviço entre duas solicitações de conexão de dados MO consecutivas (consulte a cláusula 4.3.x acima). O temporizador de Gap de Serviço contém o tempo de expiração para um temporizador de gap Temporizador de Gap de serviço iniciado.

Um temporizador de gap de de Serviço serviço em execução deve ser transferido para a nova MME em mobilidade entre MME.

Para cada conexão PDN ativa:

Campo Descrição O APN atualmente usado.

Esse APN deve ser composto do Identificador de Rede de APN e do Identificador de Operador de APN padrão, APN em Uso conforme especificado em TS 23.003 [9], cláusula 9.1.2. Qualquer valor recebido no campo de Substituição de APN OI não é aplicado neste documento.

Denota a restrição na combinação de tipos de Restrição de APN APN para o APN associado a esse Contexto de transportador de EPS.

APN Assinado O APN assinado recebido do HSS.

Tipo de PDN IPv4, IPv6, r IPv4v6 ou Não IP O endereço de IP da SCEF atualmente sendo ID de SCEF usada para fornecer conexão PDN à SCEF.

Endereço de IPv4 e/ou prefixo de IPv6 NOTA: A MME pode não ter informações sobre o endereço de IPv4 alocado.

Endereço(s) de IP Alternativamente, seguindo mobilidade que envolve um SGSN de pré-lançamento 8, esse endereço de IPv4 pode não ser o alocado para o UE.

Características de As características de carregamento dessa Carregamento de EPS conexão PDN, por exemplo, normal, pré-pago, taxa PDN fixa e/ou hot billing.

Campo Descrição Substituição de APN-OI de nível de APN que tem mesma função que Substituição de APN-OI de nível de UE, mas com prioridade mais alta do que Substituição de APN- Substituição de APN-OI de nível de UE. Esse é um

OI parâmetro opcional. Quando disponível, deve ser usado para construir o PDN GW FQDN em vez de Substituição de APN-OI de nível de UE. Indica se o tráfego associado a esse APN é proibido para SIPTO, permitido para SIPTO Permissões de SIPTO excluindo SIPTO na rede local, permitido para SIPTO incluindo SIPTO na rede local ou permitido para SIPTO na rede local apenas. Caso SIPTO@LN esteja habilitado para essa ID de Rede Doméstica conexão PDN, isso indica a identidade da Rede Local Doméstica Local à qual o (H)eNB pertence. Indica se a PDN pode ser acessada por meio de Permissões de LIPA Acesso de IP Local. Possíveis valores são: LIPA- proibido, LIPA-apenas e LIPA-condicional. Indica se o tráfego associado a essa Conexão PDN tem permissão para ser descarregado em WLAN com o uso do recurso de Interligação de Descarregamento de Rádio WLAN/3GPP ou se deve ser mantido em

WLAN acesso 3GPP (consulte a cláusula 4.3.23). A indicação pode conter valores separados por RAT (E- UTRA e UTRA).

Campo Descrição Especifica se o UE tem permissão para usar o Endereço de VPLMN APN no domínio da HPLMN apenas ou, Permitido adicionalmente, o APN no domínio da VPLMN.

Endereço de PDN GW O endereço de IP do PDN GW atualmente em Uso (plano de usado para enviar sinalização de plano de controle. controle) PDN GW TEID para Identificador de Ponto Final de Túnel de PDN S5/S8 (plano de GW para a interface de S5/S8 para o plano de controle) controle. (Para S5/S8 com base em GTP apenas). Ação de Relatório de Precisa comunicar mudança em Informações Mudança de Info de de Localização de Usuário ao PDN GW com esse MS Contexto de transportador de EPS.

Precisa comunicar mudança em Informações de CSG de Usuário ao PDN GW com esse Contexto de transportador de EPS.

Esse campo denota, separadamente, se o Ação de Relatório de MME/SGSN são solicitados para enviar mudanças Informações de CSG em Informações de CSG de Usuário para (a) células de CSG, (b) células híbridas em que o assinante é um membro de CSG e (c) células híbridas em que o assinante não é um membro de CSG.

Campo Descrição Precisa comunicar uma mudança de presença de UE em Área de Relatório de Presença.

Esse campo denota, separadamente, o identificador(es) de PRA, e a lista(s) dos elementos de Área de Ação de Área de Relatório de Presença (caso fornecidos pelo PDN Relatório de Presença GW). O status (isto é, ativo ou inativo) para cada Área de Relatório de Presença é armazenado na MME quando recurso dinâmico que manipula Área de Relatório de Presença é configurado na MME.

Os valores de parâmetro de QoS de nível de Perfil de QoS de EPS transportador para aquela transportador padrão de assinado APN (QCI e ARP) (consulte a cláusula 4.7.3). Os valores de MBR de enlace ascendente e enlace descendente Agregados Máximos a serem APN-AMBR assinada compartilhados por todos os transportadores de Não GBR, que são estabelecidas para esse APN, de acordo com a assinatura do usuário.

Os valores de MBR de enlace ascendente e enlace descendente agregados máximos a serem APN-AMBR compartilhados por todos os transportadores Não GBR, que são estabelecidas para esse APN, conforme decidido pelo PDN GW.

Chave de PDN GW Chave de GRE atribuída a PDN GW para a GRE para tráfego de interface de S5/S8 para o plano de usuário para enlace ascendente tráfego de enlace ascendente. (Para S5/S8 com base (plano de usuário) em PMIP apenas)

Campo Descrição Identifica o Id de Transportador de EPS do Transportador padrão transportador padrão dentro da determinada conexão PDN. Indica que o UE solicitou baixa prioridade de acesso quando a conexão PDN estava aberta. baixa prioridade de NOTA: O indicador de baixa prioridade de acesso acesso é apenas armazenado com o intuito de ser incluído em gravações de carregamento. Indica, por UE, os Padrões de Comunicação e Padrões de seu tempo de validade correspondente, conforme Comunicação especificado em TS 23.682 [74]. Os Padrões de Comunicação não são fornecidos ao SGSN. Fornece, para esse APN, como manipular uma conexão de PDN quando o UE se move entre "banda larga" (WB-E-UTRAN e UTRAN) e "banda estreita" Continuidade de PDN (NB-IoT, GPRS, EC-GSM-IoT). Possíveis valores são: em mobilidade entre manter a conexão de PDN; desconectar a conexão

RAT de PDN com uma solicitação de reativação; desconectar a conexão de PDN sem solicitação de reativação; ou deixar para política de VPLMN local. Para cada transportador dentro da conexão PDN: Uma identidade de transportador de EPS ID de Transportador identifica, exclusivamente, um transportador de EPS de EPS para um UE que acessa por meio de E-UTRAN. TI Identificador de Transação

Campo Descrição Endereço de IP do S-GW para as interfaces de Endereço de S-GW IP S1-u/S11-u.

A interface de S11-u é usada para para S1-u/S11-u otimização de CIoT EPS de Plano de Controle.

Identificador de Ponto Final de Túnel do S-GW S-GW TEID para S1- para a interface de S1-u/S11-u.

A interface de S11-u u/S11-u é usada para otimização de CIoT EPS de Plano de Controle.

Endereço de MME IP para a interface de S11-u Endereço de MME IP (usada pelo S-GW). A interface de S11-u é usada para S11-u para otimização de CIoT EPS de Plano de Controle.

Identificador de Ponto Final de Túnel de MME para a interface de S11-u (usada pelo S-GW). A MME TEID para S11-u interface de S11-u é usada para otimização de CIoT EPS de Plano de Controle.

Identificador de Ponto Final de Túnel de P-GW para a interface de S5/S8 para o plano de usuário. (Usado para mudança de S-GW apenas). PDN GW TEID para NOTA: O PDN GW TEID é necessário em S5/S8 (plano de contexto de MME visto que realocação de S-GW é usuário) disparada sem interação com o S-GW de origem, por exemplo, quando ocorre uma TAU.

O S-GW de destino exige esse Elemento de Informações, então, precisa ser armazenado pela MME.

Campo Descrição Endereço de P GW IP para plano de usuário para a interface de S5/S8 para o plano de usuário. (Usado para mudança de S-GW apenas). NOTA: O endereço de PDN GW IP para plano Endereço de PDN GW de usuário é necessário em contexto de MME visto IP para S5/S8 (plano que realocação de S-GW é disparada sem interação de usuário) com o S-GW de origem, por exemplo, quando ocorre uma TAU. O S GW de destino exige esse Elemento de Informações, então, precisa ser armazenado pela MME. QoS de transportador QCI e ARP de modo opcional: GBR e MBR para de EPS transportador de GBR Modelo de Fluxo de Tráfego. (Para S5/S8 com

TFT base em PMIP apenas) O Controle de Taxa de PLMN Servidora limita o número máximo de PDUs de Dados de NAS por hora Controle de Taxa de decimal enviado por direção (enlace PLMN Servidora ascendente/enlace descendente) com o uso da Otimização de CIoT EPS de Plano de Controle para uma conexão PDN.

Tabela 5.7.2-2: Dados de Configuração de Emergência de MME Os Dados de Configuração de Emergência de MME são usados em vez de dados de assinatura de UE recebidos do HSS, para todos os serviços de transportador de emergência que são estabelecidos por uma MME em solicitação de UE.

Campo Descrição Uma etiqueta de acordo com convenções de Nome de Ponto de nomeação de DNS que descreve o ponto de acesso Acesso de Emergência usado para conexão PDN de Emergência (curinga (em APN) não permitido). Os valores de parâmetro de QoS de nível de Perfil de QoS de transportador para transportador padrão de APN de emergência Emergência (QCI e ARP). A ARP é um valor de ARP reservado para transportadores de emergência. Os valores de MBR de enlace ascendente e enlace descendente agregados máximos a serem APN-AMBR de compartilhados por todos os transportadores Não Emergência GBR, que são estabelecidos para o APN de Emergência, conforme decidido pelo PDN GW. A identidade configurada de modo estático do Identidade de PDN PDN GW usado para APN de emergência. A GW de Emergência identidade de PDN GW pode ser um FQDN ou um endereço de IP. A identidade configurada de modo estático do Identidade de PDN PDN GW usado para APN de emergência quando GW de Emergência uma PLMN suporta handover para acesso não 3GPP. Não 3GPP HO A identidade de PDN GW pode ser um FQDN ou um endereço de IP. (NOTA 1) NOTA-1: O FQDN sempre decide por um PDN GW.

NOTA: QCI para transportador padrão de APN de Emergência é definido por configuração de operador.

5.7.5 UE O UE mantém as informações de contexto a seguir. A Tabela 5.7.5-1 mostra os campos de contexto. Um UE com capacidade para GERAN ou UTRAN mantém, além disso, as informações de contexto, conforme descrito em uma tabela de contexto de UE similar em TS 23.060 [7]. Tabela 5.7.5-1: Contexto de UE Campo Descrição IMSI (Identificação Internacional de Acesso

IMSI Móvel) é a identidade permanente de assinante.

Estado de gerenciamento de mobilidade Estado de EMM EMM-REGISTERED, EMM-DESCADASTRADO. GUTI Identidade Temporária Globalmente Única. Identidade de Equipamento Móvel – (por Identidade de ME exemplo, IMEI/IMEISV) Número de Versão de Software Lista de Área de Lista Atual de Área de Rastreamento. Rastreamento Uma TAI que está contida na lista de TA que o TAI visitada por último UE registrou na rede e que identifica a área de rastreamento visitada por último pelo UE. Algoritmo de NAS Algoritmo de segurança de NAS selecionado. Selecionado Algoritmo de AS Algoritmos de segurança de AS selecionados. selecionado

Campo Descrição Identificador de Conjunto de Chaves para a chave principal KASME. Também indica se o UE eKSI está usando chaves de segurança derivadas de associação de segurança de UTRAN ou E-UTRAN Chave principal para hierarquia de chave E- KASME UTRAN com base em CK, IK e identidade de rede servidora. Chaves de NAS e KNASint, KNASenc e parâmetro NAS COUNT.

COUNT Esse parâmetro é usado internamente pelo UE Identidade para memorizar o ID temporário que o mesmo tem Temporária usada em para indicar na Solicitação de Vinculação e Próxima atualização Solicitação de RAU/TAU, conforme especificado na (TIN) cláusula 4.3.5.6. Parâmetros de DRX Comprimento de ciclo de DRX de E-UTRAN Específicos de UE preferencial Valor de Tempo Ativo específico de UE Valor de Tempo Ativo alocado por MME para manipulação de modo de para PSM economia de energia. Parâmetros de DRX de Parâmetros de DRX de modo ocioso estendido modo ocioso recebidos da MME. estendido

Campo Descrição A lista de CSG Permitido, que está sob controle tanto de usuário quanto de operador, Lista de CSG Permitido indica a lista de IDs de CSG e a PLMN associada em que o UE é um membro.

A lista de CSG de Operador, que está sob Lista de CSG de controle exclusivo de Operador, indica a lista de IDs Operador de CSG e a PLMN associada em que o UE é um membro.

Gap de serviço, um parâmetro que especifica o tempo mínimo entre duas solicitações de conexão de dados MO consecutivas (consulte a Gap de Serviço cláusula 4.3.x acima). Usada para iniciar um temporizador de Gap de serviço no UE caso o parâmetro tenha sido recebido em Aceitação de vinculação ou Aceitação de TAU.

Para cada conexão PDN ativa: O APN atualmente usado.

Esse APN deve ser composto do Identificador de Rede de APN e do APN em Uso Identificador de Operador de APN padrão, conforme especificado em TS 23.003 [9], cláusula 9.1.2. A MBR de enlace ascendente e enlace descendente agregada máxima a ser compartilhada APN-AMBR por todos os transportadores Não GBR, que são estabelecidas para esse APN.

Campo Descrição O Tipo de PDN atribuído pela rede (IPv4, IPv6, Tipo de PDN Atribuído IPv4v6 ou Não IP). Endereço(s) de IP Endereço de IPv4 e/ou prefixo de IPv6 Identifica o transportador padrão dentro da conexão de PDN por seu Id de Transportador de Transportador Padrão EPS. o transportador padrão é um que é estabelecido primeiro dentro da conexão de PDN. Indica se o tráfego associado a essa Conexão PDN tem permissão para ser descarregado em WLAN com o uso do recurso de Interligação de Descarregamento de Rádio WLAN/3GPP ou se deve ser mantido em

WLAN acesso 3GPP (consulte a cláusula 4.3.23). A indicação pode conter valores separados por RAT (E-UTRA e UTRA). O Controle de Taxa de APN limita o número máximo de mensagens de enlace ascendente por uma unidade de tempo específica (por exemplo, Controle de Taxa de minuto, hora, dia, semana) para esse APN. Inclui

APN uma indicação da possibilidade de Relatórios de exceção ainda poderem ser enviados quando o limite tiver sido atingido. O Controle de Taxa de PLMN Servidora limita o número máximo de PDUs de Dados de NAS por Controle de Taxa de hora decimal enviado em enlace ascendente com o PLMN Servidora uso da Otimização de CIoT EPS de Plano de Controle para uma conexão de PDN.

Campo Descrição Para cada transportador de EPS dentro da conexão de PDN Uma identidade de transportador de EPS ID de Transportador identifica, exclusivamente, um transportador de de EPS EPS para um UE que acessa por meio de E-UTRAN. TI Identificador de Transação QoS de transportador GBR e MBR para transportador de GBR. de EPS TFT Modelo de Fluxo de Tráfego.

[0345] Embora sem caráter limitativo, algumas modalidades exemplificativas descritas acima podem ser resumidas da seguinte maneira:

1. Um método de operação de um dispositivo sem fio (12) para prover controle de gap de serviço em um sistema de comunicação sem fio (10), compreendendo: receber (100) no dispositivo sem fio (12) um parâmetro de gap de serviço a partir de entidade de rede (por exemplo nó ou função de Rede de Acesso via Rádio (RAN), ou um nó ou função de rede núcleo) em uma mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade, o parâmetro de gap de serviço sendo indicativo de um valor para um temporizador de gap de serviço para o dispositivo sem fio (12); e impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) em um estrado de camada de não acesso.

2. O método da modalidade 1, em que a mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade é uma mensagem de aceitação de vinculação.

3. O método da modalidade 1, em que a mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade é uma mensagem de aceitação de atualização de área de rastreamento.

4. O método de qualquer uma das modalidades 1 a 3, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende iniciar o temporizador de gap de serviço quando o dispositivo sem fio (12) transita para o modo ocioso.

5. O método de qualquer uma das modalidades 1 a 3, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende iniciar o temporizador de gap de serviço toda vez que o dispositivo sem fio (12) transita para o modo ocioso que não seja por uma ou mais exceções.

6. O método da modalidade 5, em que uma ou mais exceções compreende uma exceção em que o temporizador de gap de serviço já está em execução.

7. O método de qualquer uma das modalidades 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir dados de usuário originados em terminal móvel, dados de plano de controle originados em terminal móvel, e/ou solicitações de conexão SMS originadas de terminal móvel e/ou solicitações de vinculação quando o temporizador de gap de serviço estiver em execução.

8. O método de qualquer uma das modalidades 1 a 6 em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir que dispositivo sem fio (12) se vincule a uma PLMN quando o temporizador de gap de serviço estiver em execução.

9. O método de qualquer uma das modalidades 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende transmitir uma mensagem de atualização de área de rastreamento na qual uma flag ativa e uma flag ativa de sinalização não são definidos se o temporizador de gap de serviço estiver em execução.

10. O método de qualquer uma das modalidades 1 a 6 em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir que o dispositivo sem fio (12) inicie um procedimento de solicitação de serviço enquanto o temporizador de gap de serviço estiver em execução.

11. O método, de qualquer uma das modalidades 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir que o dispositivo sem fio (12) inicie um procedimento de solicitação de serviço de plano de controle enquanto o temporizador de gap de serviço estiver em execução.

12. O método, de qualquer uma das modalidades 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir que o dispositivo sem fio (12) inicie um procedimento de retomada de conexão enquanto o temporizador de gap de serviço estiver em execução.

13. O método, de qualquer uma das modalidades 1 a 12, em que o sistema de comunicação sem fio (10) é um sistema 3GPP LTE ou 3GPP NR.

14. Um dispositivo sem fio (12) que provê controle de gap de serviço em um sistema de comunicação sem fio (10), o dispositivo sem fio (12) adaptado para realizar o método de qualquer uma das modalidades 1 a 13.

15. Um dispositivo sem fio (12) que provê controle de gap de serviço em um sistema de comunicação sem fio (10), compreendendo: um ou mais transceptores (26); e conjunto de circuito (20) conectado a um ou mais transceptores (26), o conjunto de circuito (20) operável para fazer com que o dispositivo sem fio (12) realize o método de qualquer uma das modalidades 1 a 13.

16. Um dispositivo sem fio (12) que provê controle de gap de serviço em um sistema de comunicação sem fio (10), compreendendo: um ou mais módulos (34) operáveis para realizar o método de qualquer uma das modalidades 1 a 13.

17. Um método de operação de uma entidade de rede núcleo (por exemplo um nó de rede núcleo ou uma função de rede núcleo) em uma rede núcleo de um sistema de comunicação sem fio (10) para prover controle de gap de serviço compreendendo: obter (200) pela entidade de rede núcleo um parâmetro de gap de serviço para um dispositivo sem fio (12), o parâmetro de gap de serviço sendo indicativo de um valor para um temporizador de gap de serviço para o dispositivo sem fio (12); e enviar (202), pela entidade de rede núcleo, o parâmetro de gap de serviço para o dispositivo sem fio (12) via uma mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade.

18. O método da modalidade 17, em que a mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade é uma mensagem de aceitação de vinculação.

19. O método da modalidade 17 ou 18, em que a mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade é uma mensagem de aceitação de atualização de área de rastreamento.

20. O método de qualquer uma das modalidades 17 a 19 compreendendo ainda impor (204) o parâmetro de gap de serviço no nó de rede em uma camada de estrado de não acesso.

21. O método da modalidade 20, em que impor (204) o parâmetro de gap de serviço no nó de rede compreende rejeitar os dados de plano do usuário originados de terminal móvel, dados de plano de controle originados de terminal móvel, e/ou solicitações de conexão SMS originadas de terminal móvel e/ou solicitações de vinculações para o dispositivo sem fio (12) quando o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

22. O método da modalidade 20, em que impor (204) o parâmetro de gap de serviço no nó de rede compreende: receber uma solicitação de vinculação para o dispositivo sem fio (12); e rejeitar a solicitação de vinculação se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

23. O método da modalidade 22 em que rejeitar a solicitação de vinculação compreende enviar uma mensagem de rejeição de vinculação ao dispositivo sem fio (12), a mensagem de rejeição de vinculação compreendendo uma causa apropriada e/ou temporizador de backoff definido para um valor restante do temporizador de gap de serviço para o dispositivo sem fio (12).

24. O método da modalidade 20 em que impor (204) o parâmetro de gap de serviço no nó de rede compreende: receber uma mensagem de atualização de área de rastreamento do dispositivo sem fio (12); e deixar de realizar qualquer ação disparada por uma flag ou uma flag ativa de sinalização compreendida na mensagem de atualização de área de rastreamento se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

25. O método da modalidade 20, em que impor (204) o parâmetro de gap de serviço no nó de rede compreende: receber uma solicitação de serviço para o dispositivo sem fio (12); e rejeitar a solicitação de serviço se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

26. O método da modalidade 20 em que impor (204) o parâmetro de gap de serviço no nó de rede compreende: receber uma solicitação de serviço de plano de controle para o dispositivo sem fio (12); e rejeitar a solicitação de serviço se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

27. O método da modalidade 20 em que impor (204) o parâmetro de gap de serviço no nó de rede compreende: receber uma solicitação de serviço ou solicitação de serviço de plano de controle para o dispositivo sem fio (12); e rejeitar a solicitação de serviço ou solicitação de serviço de plano de controle se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução e se a solicitação de serviço ou solicitação de serviço de plano de controle não for uma a resposta para uma radiolocalização precedente Finalizada em Móvel.

28. O método de qualquer uma das modalidades 25 a 27 em que rejeitar a solicitação de serviço compreende rejeitar a solicitação de serviço ou solicitação de serviço de plano de controle com uma causa apropriada e/ou com um timer de backoff definido para um valor restante do temporizador de gap de serviço para o dispositivo sem fio (12).

29. O método da modalidade 20 em que impor (204) o parâmetro de gap de serviço no nó de rede compreende: receber uma solicitação de retomada de conexão para o dispositivo sem fio (12); e rejeitar a solicitação de retomada da conexão se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

30. O método da modalidade 20 em que impor (204) o parâmetro de gap de serviço no nó de rede compreende: receber uma solicitação de retomada de conexão para o dispositivo sem fio (12); e rejeitar a solicitação de retomada de conexão se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução e se a solicitação de retomada de conexão não for uma resposta a uma radiolocalização precedente Finalizada em Móvel.

31. O método da modalidade 29 ou 30, em que rejeitar a solicitação de retomada de conexão compreende rejeitar a solicitação de retomada de conexão com uma causa apropriada e/ou com um temporizador de backoff definido para um valor restante do temporizador de gap de serviço para o dispositivo sem fio (12).

32. O método de qualquer uma das modalidades 17 a 31 em que obter (200) o parâmetro de gap de serviço para o dispositivo sem fio (12) compreende: enviar uma solicitação de atualização de localização para um HSS; e receber dados de assinatura do HSS em uma Reconhecimento de atualização de localização, os dados de assinatura compreendendo o parâmetro de gap de serviço para o dispositivo sem fio (12).

33. O método de qualquer uma das modalidades 17 a 32 em que o nó de rede é uma MME ou AMF.

34. O método de qualquer uma das modalidades 17 a 33, em que o sistema de comunicação sem fio (10) é um sistema 3GPP LTE ou NR.

35. Um nó de rede núcleo ou função de rede núcleo em uma rede núcleo de um sistema de comunicação sem fio (10) para prover controle de gap de serviço, o nó de rede núcleo ou função de rede núcleo adaptados para realizar o método de qualquer uma das modalidades 17 a 34.

36. Um nó de rede núcleo ou função de rede núcleo para uma rede núcleo de um sistema de comunicação sem fio (10) para prover controle de gap de serviço, compreendendo: uma interface de rede (44, 62);

Um ou mais processadores (40, 58); e memória (42, 60) compreendendo instruções executáveis pelo um ou mais processadores (40, 58) em que o nó de rede ou função de rede é operável para realizar o método de qualquer uma das modalidades 17 a 34.

37. Um nó de rede núcleo ou função de rede núcleo para uma rede núcleo de um sistema de comunicação sem fio (10) para prover controle de gap de serviço, compreendendo: um ou mais módulos (66) operáveis para realizar o método de qualquer uma das modalidades 17 a 34.

[0346] Os seguintes acrônimos são usados por toda essa revelação. 3GPP Projeto de Parceria para a 3ª Geração 5G Quinta Geração ACK Reconhecimento AMBR Taxa Máxima de BIT Agregado AMF Função de Gerenciamento de Acesso e Mobilidade APN Nome de Ponto de Acesso ARP Prioridade de Alocação e Retenção AS Estrado de acesso ASIC Circuitos Integrados de Aplicação Específica BCM Modo de Controle de Transportador BSS Sistema de Estação Base CDR Registro de Dados de Carregamento CHAP Protocolo de Autenticação por desafio Handshake CIoT Internet das Coisas via Celular CP Plano de Controle CPU Unidade de Processamento Central CSG Grupo de Assinante Fechado

CS Comutado por Circuito CSS Servidor de Assinante de Grupo de Assinante Fechado DDN Notificação de Dados de Enlace Descendente DHCPv4 Versão 4 de Protocolo de Configuração de Servidor Dinâmico DM Gerenciamento de Dispositivo DoNAS Dados Sobre Estrado de Não Acesso DRX Recepção Descontínua DSP Processador de Sinal Digital ECGI Identificador Global de Célula de Rede de Acesso de Rádio Terrestre Universal Evoluída EIR Registro de Identidade de Equipamento eKSI Identificador de Conjunto de Chave Evoluído EMM Gerenciamento de Mobilidade de Sistema de Pacote Evoluído eNB Nó B Aperfeiçoado ou Evoluído EPC Núcleo de Pacote Evoluído ePLMN Rede Móvel Terrestre Pública Equivalente EPS Sistema de Pacote Evoluído E-RAB Transportador de Acesso de Rádio de Rede de Acesso de Rádio Terrestre Universal Evoluída ESM Gerenciamento da Sessão de Sistema de Pacote Evoluído ETFTN Rede Suporte de Modelo de Fluxo de Tráfego Estendido ETFTU Equipamento de Usuário de Suporte de Modelo de Fluxo de Tráfego Evoluído E-UTRAN Rede de Acesso de Rádio Terrestre Universal Evoluída FPGA Arranjo de Porta Programável em Campo GERAN Rede de Acesso de Rádio de Taxas de Dados aperfeiçoadas para Sistema Global para Comunicações Móveis de Sistema

Global para Comunicações Móveis gNB Nova Estação Base de Rádio GRE Encapsulamento de Roteamento Genérico GTP Protocolo de Tunelamento de Serviço de Rádio de Pacote Geral GUMMEI Identificador de Entidade de Gerenciamento de Mobilidade Globalmente Único GUTI Identificador Temporário Único Global GWCN Rede núcleo de Gateway HA Agente Doméstico HeNB Nó B Evoluído ou Aperfeiçoado Doméstico HLR Registro de Assinantes Domésticos HPLMN Rede Móvel Terrestre Pública Local HSS Serviço de Assinantes Domésticos ID Identificador IE Elemento de Informações IETF Força Tarefa de Engenharia de Internet IMEI Identificação Internacional de Equipamento Móvel IMEISV Identificação Internacional de Equipamento Móvel Versão de Software IMS Subsistema Multimídia de Protocolo de Internet IMSI Identificação Internacional de Acesso Móvel IoT Internet das Coisas IP Protocolo de Internet IP-CAN Rede de Acesso de Conectividade de Protocolo de Internet ISR Redução de Sinalização de Estado Ocioso KSI Identificador de Conjunto de Chave

LBI Identificador de Transportador Vinculado LCS Serviço de Localização L-GW Gateway Local LIPA Acesso de Protocolo de Internet Local LR Solicitação de Localização LTE Evolução de Longo Prazo M2M Máquina à Máquina MAC Controle de Acesso ao Meio ME Equipamento Móvel MM Gerenciamento de Mobilidade MME Entidade de Gerenciamento de Mobilidade MO Originado de terminal Móvel MS Estação Móvel MSISDN Rede Digital de Serviços Integrados de Assinante Móvel MT Finalizado em Móvel MTC Comunicação de tipo de máquina NAS Estrado de Não Acesso NB-IoT Internet das Coisas de Banda Estreita NIDD Entrega de Dados de Protocolo de Não Internet NR Novo Rádio NRSU Equipamento de Usuário de Suporte de Solicitação de Rede OCS Sistema de Carregamento online OMA Aliança Móvel Aberta OMC Centro de Operações e Manutenção OTA Pelo Ar PAP Protocolo de Autenticação de Senha PCC Controle de Política e Carregamento

PCEF Função de imposição de Política e Carregamento PCO Opção de Configuração de Protocolo PCRF Função de Política e Regras de Carregamento PDN Rede de Dados de Pacote PDP Protocolo de Dados de Pacote PDU Unidade de Dados de Protocolo P-GW Gateway de Rede de Dados de Pacote PLMN Rede Móvel Terrestre Pública PMIP Versão 6 de Protocolo de Internet Móvel Proxy PRA Área de Relatório de Presença PS Comutação de Pacote P-TMSI Assinatura de Identidade de Assinante Móvel Temporário de Pacote QCI Identificador de Classe de Qualidade de Serviço QoS Qualidade de Serviço RAI Identificação de Área de Roteamento RAN Rede de Acesso via Rádio RAT Tecnologia de Acesso via Rádio RAU Atualização de Área de Roteamento ROHC Compressão de cabeçalho Robusta RRC Controle de Recurso de Rádio SCEF Função de Exposição de Capabilidade de Serviço SGSN Nó de Suporte de Serviço de Rádio de Pacote Geral Servidor S-GW Gateway Servidor SIPTO Descarregamento de Tráfego de Protocolo de Internet Selecionado SM Gerenciamento de Sessão

SMS Serviço de Mensagem Curta SRVCC Continuidade de Chamada de Voz de Rádio Único TA Área de Rastreamento TAI Identidade de Área de Rastreamento TAU Atualização de Área de Rastreamento TEID Identificador de Ponta de Extremidade de Túnel TFT Modelo de Fluxo de Tráfego TI Identificador de Transação TIN Identidade temporária TS Especificação Técnica UE Equipamento de Usuário UICC Cartão de Circuito Integrado Universal ULR Solicitação de Atualização de Localização UMTS Sistema Universal Móvel de Telecomunicações UP Plano de Usuário USIM Módulo de Identidade de Assinante Universal UTRAN Rede de Acesso via Rádio Terrestre Universal Evoluída (E-UTRAN) VPLMN Rede Móvel Terrestre Pública Visitada WB-E-UTRAN Rede de Acesso de Rádio Terrestre Universal Evoluída de Banda Larga WLAN Rede de área local sem fio

[0347] Os versados na técnica irão reconhecer aperfeiçoamentos e modificações às modalidades da presente revelação. Todos esses aperfeiçoamentos e modificações são considerados dentro do escopo dos conceitos aqui revelados.

Claims

REIVINDICAÇÕES

1. Um método de operação de um dispositivo sem fio (12) para prover controle de gap de serviço em um sistema de comunicação sem fio (10), compreendendo: receber (100) no dispositivo sem fio (12) um parâmetro de gap de serviço a partir de uma entidade de rede em uma mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade, o parâmetro de gap de serviço sendo indicativo de um valor para um temporizador de gap de serviço para o dispositivo sem fio (12); e impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) em uma camada de estrado de não acesso.

2. O método de acordo com a reivindicação 1, em que a mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade é uma mensagem de aceitação de vinculação.

3. O método de acordo com reivindicação 1, em que a mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade é uma mensagem de aceitação de atualização de área de rastreamento.

4. O método de acordo com qualquer uma das reivindicações 1 a 3, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende iniciar o temporizador de gap de serviço quando o dispositivo sem fio (12) transita para o modo ocioso.

5. O método de acordo com qualquer uma das reivindicações 1 a 3, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende iniciar o temporizador de gap de serviço toda vez que o dispositivo sem fio (12) transita para o modo ocioso que não seja por uma ou mais exceções.

6. O método de acordo com reivindicação 5, em que uma ou mais exceções compreende uma exceção em que o temporizador de gap de serviço já está em execução.

7. O método de acordo com qualquer uma das reivindicações 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir dados de usuário originados de terminal móvel, dados de plano de controle originados em terminal móvel, e/ou solicitações de conexão SMS originadas de terminal móvel e/ou solicitações de vinculação quando o temporizador de gap de serviço estiver em execução.

8. O método de acordo com qualquer uma das reivindicações 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir que o dispositivo sem fio (12) se vincule a uma PLMN enquanto o temporizador de gap de serviço estiver em execução.

9. O método de acordo com qualquer uma das reivindicações 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende transmitir uma mensagem de atualização de área de rastreamento na qual uma flag ativa e uma flag ativa de sinalização não são definidos se o temporizador de gap de serviço estiver em execução.

10. O método de acordo com qualquer uma das reivindicações 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir que o dispositivo sem fio (12) inicie um procedimento de solicitação de serviço enquanto o temporizador de gap de serviço estiver em execução.

11. O método de acordo com qualquer uma das reivindicações 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir que o dispositivo sem fio (12) inicie um procedimento de solicitação de serviço de plano de controle enquanto o temporizador de gap de serviço estiver em execução.

12. O método de acordo com qualquer uma das reivindicações 1 a 6, em que impor (102) o parâmetro de gap de serviço no dispositivo sem fio (12) compreende não permitir que o dispositivo sem fio (12) inicie um procedimento de retomada de conexão enquanto o temporizador de gap de serviço estiver em execução.

13. O método de acordo com qualquer uma das reivindicações 1 a 12, em que o sistema de comunicação sem fio (10) é um sistema 3GPP LTE ou 3GPP NR.

14. Um dispositivo sem fio (12) que provê controle de gap de serviço em um sistema de comunicação sem fio (10), o dispositivo sem fio (12) adaptado para realizar o método de acordo com qualquer uma das reivindicações 1 a 13.

15. Um dispositivo sem fio (12) que provê controle de gap de serviço em um sistema de comunicação sem fio (10), compreendendo: um ou mais transceptores (26); e conjunto de circuito (20) conectado ao um ou mais transceptores (26), o conjunto de circuito (20) operável para fazer com que o dispositivo sem fio (12) realize o método de acordo com qualquer uma das reivindicações 1 a 13.

16. Um dispositivo sem fio (12) que provê controle de gap de serviço em um sistema de comunicação sem fio (10), compreendendo: um ou mais módulos (34) operáveis para realizar o método de acordo com qualquer uma das reivindicações 1 a 13.

17. Um método de operação a partir de uma entidade de rede núcleo em uma rede núcleo de um sistema de comunicação sem fio (10) para prover controle de gap de serviço, compreendendo: obter (200) pela entidade de rede núcleo um parâmetro de gap de serviço para um dispositivo sem fio (12), o parâmetro de gap de serviço sendo indicativo de um valor para um temporizador de gap de serviço para o dispositivo sem fio (12); e enviar (202) pela entidade de rede núcleo o parâmetro de gap de serviço para o dispositivo sem fio (12) via uma mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade.

18. O método de acordo com a reivindicação 17, em que a mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade é uma mensagem de aceitação de vinculação.

19. O método de acordo com reivindicação 17 ou 18, em que a mensagem de estrado de não acesso de subcamada de gerenciamento de mobilidade é uma mensagem de aceitação de atualização de área de rastreamento.

20. O método de acordo com qualquer uma das reivindicações 17 a 19, compreendendo ainda impor (204) o parâmetro de gap de serviço na entidade de rede em uma camada de estrado de não acesso.

21. O método de acordo com reivindicação 20, em que impor (204) o parâmetro de gap de serviço na entidade de rede compreende rejeitar os dados de plano do usuário originados de terminal móvel, dados de plano de controle originados de terminal móvel e/ou solicitações de conexão SMS originadas de terminal móvel e/ou solicitações de vinculação para o dispositivo sem fio (12) quando o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

22. O método de acordo com a reivindicação 20, em que impor (204) o parâmetro de gap de serviço na entidade de rede compreende: receber uma solicitação de vinculação para o dispositivo sem fio (12); e rejeitar a solicitação de vinculação se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

23. O método de acordo com reivindicação 22, em que rejeitar a solicitação de vinculação compreende enviar uma mensagem de rejeição de vinculação para o dispositivo sem fio (12), a mensagem de rejeição de vinculação compreendendo uma causa apropriada e/ou um temporizador de backoff definido para um valor restante do temporizador de gap de serviço para o dispositivo sem fio (12).

24. O método de acordo com a reivindicação 20, em que impor (204) o parâmetro de gap de serviço na entidade de rede compreende: receber uma mensagem de atualização de área de rastreamento a partir do dispositivo sem fio (12); e deixar de realizar qualquer ação disparada por uma flag ativa ou uma flag ativa de sinalização compreendida na mensagem de atualização de área de rastreamento se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

25. O método de acordo com a reivindicação 20, em que impor (204) o parâmetro de gap de serviço na entidade de rede compreende: receber uma solicitação de serviço para o dispositivo sem fio (12); e rejeitar a solicitação de serviço se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

26. O método de acordo com a reivindicação 20, em que impor (204) o parâmetro de gap de serviço na entidade de rede compreende: receber uma solicitação de serviço de plano de controle para o dispositivo sem fio (12); e rejeitar a solicitação de serviço se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

27. O método de acordo com a reivindicação 20, em que impor (204) o parâmetro de gap de serviço na entidade de rede compreende: receber uma solicitação de serviço ou solicitação de serviço de plano de controle para o dispositivo sem fio (12); e rejeitar uma solicitação de serviço ou solicitação de serviço de plano de controle se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução e se a solicitação de serviço ou solicitação de serviço de plano de controle não for uma resposta para uma radiolocalização precedente finalizada em terminal móvel.

28. O método de acordo com qualquer uma das reivindicações 25 a 27, em que rejeitar a solicitação de serviço compreende rejeitar a solicitação de serviço ou solicitação de serviço de plano de controle com uma causa apropriada e/ou com um temporizador de backoff definido para um valor restante do temporizador de gap de serviço para o dispositivo sem fio (12).

29. O método de acordo com reivindicação 20, em que impor (204) o parâmetro de gap de serviço na entidade de rede compreende: receber uma solicitação de retomada de conexão para o dispositivo sem fio (12); e rejeitar a solicitação de retomada de conexão se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução.

30. O método de acordo com a reivindicação 20, em que impor (204) o parâmetro de gap de serviço na entidade de rede compreende: receber uma solicitação de retomada de conexão para o dispositivo sem fio (12); e rejeitar a solicitação de retomada de conexão se o temporizador de gap de serviço para o dispositivo sem fio (12) estiver em execução e se a solicitação de retomada da conexão não for uma resposta a uma radiolocalização precedente finalizada em terminal móvel.

31. O método de acordo com reivindicação 29 ou 30, em que rejeitar a solicitação de retomada de conexão compreende rejeitar a solicitação de retomada de conexão com uma causa apropriada e/ou com um temporizador de backoff definido para um valor restante do temporizador de gap de serviço para o dispositivo sem fio (12).

32. O método de acordo com qualquer uma das reivindicações 17 a 31, em que obter (200) o parâmetro de gap de serviço para o dispositivo sem fio (12) compreende: enviar uma solicitação de atualização de localização para um HSS; e receber dados de assinatura do HSS em uma confirmação de atualização de localização, os dados de assinatura compreendendo o parâmetro de gap de serviço para o dispositivo sem fio (12).

33. O método de acordo com qualquer uma das reivindicações 17 a 32, em que a entidade de rede é uma MME ou AMF.

34. O método de acordo com qualquer uma das reivindicações 17 a 33, em que o sistema de comunicação sem fio (10) é um sistema 3GPP LTE ou NR.

35. Uma entidade de rede núcleo ou função de rede núcleo em uma rede núcleo de um sistema de comunicação sem fio (10) para prover controle de gap de serviço, a entidade de rede núcleo ou função de rede núcleo adaptada para realizar o método de qualquer uma das reivindicações 17 a 34.

36. Uma entidade de rede núcleo ou função de rede núcleo para uma rede núcleo de um sistema de comunicação sem fio (10) para prover controle de gap de serviço, compreendendo: uma interface de rede (44, 62); um ou mais processadores (40, 58); e memória (42, 60) compreendendo instruções executáveis pelo um ou mais processadores (40, 58), em que a entidade de rede ou função de rede é operável para realizar o método de qualquer uma das reivindicações 17 a 34.

37. Uma entidade de rede núcleo ou função rede núcleo para uma rede núcleo de um sistema de comunicação sem fio (10) para prover controle de gap de serviço, compreendendo: um ou mais módulos (66) operáveis para realizar o método de qualquer uma das reivindicações 17 a 34.